diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/ABI/testing/debugfs-pktcdvd | 5 | ||||
-rw-r--r-- | Documentation/ABI/testing/sysfs-class-pktcdvd | 2 | ||||
-rw-r--r-- | Documentation/DocBook/gadget.tmpl | 4 | ||||
-rw-r--r-- | Documentation/DocBook/kernel-api.tmpl | 3 | ||||
-rw-r--r-- | Documentation/DocBook/stylesheet.xsl | 1 | ||||
-rw-r--r-- | Documentation/DocBook/usb.tmpl | 6 | ||||
-rw-r--r-- | Documentation/auxdisplay/cfag12864b | 105 | ||||
-rw-r--r-- | Documentation/auxdisplay/cfag12864b-example.c | 282 | ||||
-rw-r--r-- | Documentation/auxdisplay/ks0108 | 55 | ||||
-rw-r--r-- | Documentation/cdrom/packet-writing.txt | 2 | ||||
-rw-r--r-- | Documentation/feature-removal-schedule.txt | 7 | ||||
-rw-r--r-- | Documentation/filesystems/relay.txt | 9 | ||||
-rw-r--r-- | Documentation/ioctl-number.txt | 3 | ||||
-rw-r--r-- | Documentation/kernel-doc-nano-HOWTO.txt | 39 | ||||
-rw-r--r-- | Documentation/kernel-parameters.txt | 2 | ||||
-rw-r--r-- | Documentation/local_ops.txt | 163 | ||||
-rw-r--r-- | Documentation/rbtree.txt | 192 | ||||
-rw-r--r-- | Documentation/rtc.txt | 46 | ||||
-rw-r--r-- | Documentation/sysrq.txt | 44 |
19 files changed, 917 insertions, 53 deletions
diff --git a/Documentation/ABI/testing/debugfs-pktcdvd b/Documentation/ABI/testing/debugfs-pktcdvd index 03dbd883cc41..bf9c16b64c34 100644 --- a/Documentation/ABI/testing/debugfs-pktcdvd +++ b/Documentation/ABI/testing/debugfs-pktcdvd | |||
@@ -1,6 +1,6 @@ | |||
1 | What: /debug/pktcdvd/pktcdvd[0-7] | 1 | What: /debug/pktcdvd/pktcdvd[0-7] |
2 | Date: Oct. 2006 | 2 | Date: Oct. 2006 |
3 | KernelVersion: 2.6.19 | 3 | KernelVersion: 2.6.20 |
4 | Contact: Thomas Maier <balagi@justmail.de> | 4 | Contact: Thomas Maier <balagi@justmail.de> |
5 | Description: | 5 | Description: |
6 | 6 | ||
@@ -11,8 +11,7 @@ The pktcdvd module (packet writing driver) creates | |||
11 | these files in debugfs: | 11 | these files in debugfs: |
12 | 12 | ||
13 | /debug/pktcdvd/pktcdvd[0-7]/ | 13 | /debug/pktcdvd/pktcdvd[0-7]/ |
14 | info (0444) Lots of human readable driver | 14 | info (0444) Lots of driver statistics and infos. |
15 | statistics and infos. Multiple lines! | ||
16 | 15 | ||
17 | Example: | 16 | Example: |
18 | ------- | 17 | ------- |
diff --git a/Documentation/ABI/testing/sysfs-class-pktcdvd b/Documentation/ABI/testing/sysfs-class-pktcdvd index c4c55edc9a5c..b1c3f0263359 100644 --- a/Documentation/ABI/testing/sysfs-class-pktcdvd +++ b/Documentation/ABI/testing/sysfs-class-pktcdvd | |||
@@ -1,6 +1,6 @@ | |||
1 | What: /sys/class/pktcdvd/ | 1 | What: /sys/class/pktcdvd/ |
2 | Date: Oct. 2006 | 2 | Date: Oct. 2006 |
3 | KernelVersion: 2.6.19 | 3 | KernelVersion: 2.6.20 |
4 | Contact: Thomas Maier <balagi@justmail.de> | 4 | Contact: Thomas Maier <balagi@justmail.de> |
5 | Description: | 5 | Description: |
6 | 6 | ||
diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index a34442436128..e7fc96433408 100644 --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl | |||
@@ -482,13 +482,13 @@ slightly. | |||
482 | <para>Gadget drivers | 482 | <para>Gadget drivers |
483 | rely on common USB structures and constants | 483 | rely on common USB structures and constants |
484 | defined in the | 484 | defined in the |
485 | <filename><linux/usb_ch9.h></filename> | 485 | <filename><linux/usb/ch9.h></filename> |
486 | header file, which is standard in Linux 2.6 kernels. | 486 | header file, which is standard in Linux 2.6 kernels. |
487 | These are the same types and constants used by host | 487 | These are the same types and constants used by host |
488 | side drivers (and usbcore). | 488 | side drivers (and usbcore). |
489 | </para> | 489 | </para> |
490 | 490 | ||
491 | !Iinclude/linux/usb_ch9.h | 491 | !Iinclude/linux/usb/ch9.h |
492 | </sect1> | 492 | </sect1> |
493 | 493 | ||
494 | <sect1 id="core"><title>Core Objects and Methods</title> | 494 | <sect1 id="core"><title>Core Objects and Methods</title> |
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 3fa0c4b4541e..0bb90237e230 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl | |||
@@ -316,6 +316,9 @@ X!Earch/i386/kernel/mca.c | |||
316 | <sect1><title>DMI Interfaces</title> | 316 | <sect1><title>DMI Interfaces</title> |
317 | !Edrivers/firmware/dmi_scan.c | 317 | !Edrivers/firmware/dmi_scan.c |
318 | </sect1> | 318 | </sect1> |
319 | <sect1><title>EDD Interfaces</title> | ||
320 | !Idrivers/firmware/edd.c | ||
321 | </sect1> | ||
319 | </chapter> | 322 | </chapter> |
320 | 323 | ||
321 | <chapter id="security"> | 324 | <chapter id="security"> |
diff --git a/Documentation/DocBook/stylesheet.xsl b/Documentation/DocBook/stylesheet.xsl index 3ccce886c349..974e17ccf106 100644 --- a/Documentation/DocBook/stylesheet.xsl +++ b/Documentation/DocBook/stylesheet.xsl | |||
@@ -4,4 +4,5 @@ | |||
4 | <param name="funcsynopsis.style">ansi</param> | 4 | <param name="funcsynopsis.style">ansi</param> |
5 | <param name="funcsynopsis.tabular.threshold">80</param> | 5 | <param name="funcsynopsis.tabular.threshold">80</param> |
6 | <!-- <param name="paper.type">A4</param> --> | 6 | <!-- <param name="paper.type">A4</param> --> |
7 | <param name="generate.section.toc.level">2</param> | ||
7 | </stylesheet> | 8 | </stylesheet> |
diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl index 143e5ff7deb8..a2ebd651b05a 100644 --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl | |||
@@ -187,13 +187,13 @@ | |||
187 | 187 | ||
188 | <chapter><title>USB-Standard Types</title> | 188 | <chapter><title>USB-Standard Types</title> |
189 | 189 | ||
190 | <para>In <filename><linux/usb_ch9.h></filename> you will find | 190 | <para>In <filename><linux/usb/ch9.h></filename> you will find |
191 | the USB data types defined in chapter 9 of the USB specification. | 191 | the USB data types defined in chapter 9 of the USB specification. |
192 | These data types are used throughout USB, and in APIs including | 192 | These data types are used throughout USB, and in APIs including |
193 | this host side API, gadget APIs, and usbfs. | 193 | this host side API, gadget APIs, and usbfs. |
194 | </para> | 194 | </para> |
195 | 195 | ||
196 | !Iinclude/linux/usb_ch9.h | 196 | !Iinclude/linux/usb/ch9.h |
197 | 197 | ||
198 | </chapter> | 198 | </chapter> |
199 | 199 | ||
@@ -574,7 +574,7 @@ for (;;) { | |||
574 | #include <asm/byteorder.h></programlisting> | 574 | #include <asm/byteorder.h></programlisting> |
575 | The standard USB device model requests, from "Chapter 9" of | 575 | The standard USB device model requests, from "Chapter 9" of |
576 | the USB 2.0 specification, are automatically included from | 576 | the USB 2.0 specification, are automatically included from |
577 | the <filename><linux/usb_ch9.h></filename> header. | 577 | the <filename><linux/usb/ch9.h></filename> header. |
578 | </para> | 578 | </para> |
579 | 579 | ||
580 | <para>Unless noted otherwise, the ioctl requests | 580 | <para>Unless noted otherwise, the ioctl requests |
diff --git a/Documentation/auxdisplay/cfag12864b b/Documentation/auxdisplay/cfag12864b new file mode 100644 index 000000000000..3572b98f45b8 --- /dev/null +++ b/Documentation/auxdisplay/cfag12864b | |||
@@ -0,0 +1,105 @@ | |||
1 | =================================== | ||
2 | cfag12864b LCD Driver Documentation | ||
3 | =================================== | ||
4 | |||
5 | License: GPLv2 | ||
6 | Author & Maintainer: Miguel Ojeda Sandonis <maxextreme@gmail.com> | ||
7 | Date: 2006-10-27 | ||
8 | |||
9 | |||
10 | |||
11 | -------- | ||
12 | 0. INDEX | ||
13 | -------- | ||
14 | |||
15 | 1. DRIVER INFORMATION | ||
16 | 2. DEVICE INFORMATION | ||
17 | 3. WIRING | ||
18 | 4. USERSPACE PROGRAMMING | ||
19 | |||
20 | |||
21 | --------------------- | ||
22 | 1. DRIVER INFORMATION | ||
23 | --------------------- | ||
24 | |||
25 | This driver support one cfag12864b display at time. | ||
26 | |||
27 | |||
28 | --------------------- | ||
29 | 2. DEVICE INFORMATION | ||
30 | --------------------- | ||
31 | |||
32 | Manufacturer: Crystalfontz | ||
33 | Device Name: Crystalfontz 12864b LCD Series | ||
34 | Device Code: cfag12864b | ||
35 | Webpage: http://www.crystalfontz.com | ||
36 | Device Webpage: http://www.crystalfontz.com/products/12864b/ | ||
37 | Type: LCD (Liquid Crystal Display) | ||
38 | Width: 128 | ||
39 | Height: 64 | ||
40 | Colors: 2 (B/N) | ||
41 | Controller: ks0108 | ||
42 | Controllers: 2 | ||
43 | Pages: 8 each controller | ||
44 | Addresses: 64 each page | ||
45 | Data size: 1 byte each address | ||
46 | Memory size: 2 * 8 * 64 * 1 = 1024 bytes = 1 Kbyte | ||
47 | |||
48 | |||
49 | --------- | ||
50 | 3. WIRING | ||
51 | --------- | ||
52 | |||
53 | The cfag12864b LCD Series don't have official wiring. | ||
54 | |||
55 | The common wiring is done to the parallel port as shown: | ||
56 | |||
57 | Parallel Port cfag12864b | ||
58 | |||
59 | Name Pin# Pin# Name | ||
60 | |||
61 | Strobe ( 1)------------------------------(17) Enable | ||
62 | Data 0 ( 2)------------------------------( 4) Data 0 | ||
63 | Data 1 ( 3)------------------------------( 5) Data 1 | ||
64 | Data 2 ( 4)------------------------------( 6) Data 2 | ||
65 | Data 3 ( 5)------------------------------( 7) Data 3 | ||
66 | Data 4 ( 6)------------------------------( 8) Data 4 | ||
67 | Data 5 ( 7)------------------------------( 9) Data 5 | ||
68 | Data 6 ( 8)------------------------------(10) Data 6 | ||
69 | Data 7 ( 9)------------------------------(11) Data 7 | ||
70 | (10) [+5v]---( 1) Vdd | ||
71 | (11) [GND]---( 2) Ground | ||
72 | (12) [+5v]---(14) Reset | ||
73 | (13) [GND]---(15) Read / Write | ||
74 | Line (14)------------------------------(13) Controller Select 1 | ||
75 | (15) | ||
76 | Init (16)------------------------------(12) Controller Select 2 | ||
77 | Select (17)------------------------------(16) Data / Instruction | ||
78 | Ground (18)---[GND] [+5v]---(19) LED + | ||
79 | Ground (19)---[GND] | ||
80 | Ground (20)---[GND] E A Values: | ||
81 | Ground (21)---[GND] [GND]---[P1]---(18) Vee · R = Resistor = 22 ohm | ||
82 | Ground (22)---[GND] | · P1 = Preset = 10 Kohm | ||
83 | Ground (23)---[GND] ---- S ------( 3) V0 · P2 = Preset = 1 Kohm | ||
84 | Ground (24)---[GND] | | | ||
85 | Ground (25)---[GND] [GND]---[P2]---[R]---(20) LED - | ||
86 | |||
87 | |||
88 | ------------------------ | ||
89 | 4. USERSPACE PROGRAMMING | ||
90 | ------------------------ | ||
91 | |||
92 | The cfag12864bfb describes a framebuffer device (/dev/fbX). | ||
93 | |||
94 | It has a size of 1024 bytes = 1 Kbyte. | ||
95 | Each bit represents one pixel. If the bit is high, the pixel will | ||
96 | turn on. If the pixel is low, the pixel will turn off. | ||
97 | |||
98 | You can use the framebuffer as a file: fopen, fwrite, fclose... | ||
99 | Although the LCD won't get updated until the next refresh time arrives. | ||
100 | |||
101 | Also, you can mmap the framebuffer: open & mmap, munmap & close... | ||
102 | which is the best option for most uses. | ||
103 | |||
104 | Check Documentation/auxdisplay/cfag12864b-example.c | ||
105 | for a real working userspace complete program with usage examples. | ||
diff --git a/Documentation/auxdisplay/cfag12864b-example.c b/Documentation/auxdisplay/cfag12864b-example.c new file mode 100644 index 000000000000..7bfac354d4c9 --- /dev/null +++ b/Documentation/auxdisplay/cfag12864b-example.c | |||
@@ -0,0 +1,282 @@ | |||
1 | /* | ||
2 | * Filename: cfag12864b-example.c | ||
3 | * Version: 0.1.0 | ||
4 | * Description: cfag12864b LCD userspace example program | ||
5 | * License: GPLv2 | ||
6 | * | ||
7 | * Author: Copyright (C) Miguel Ojeda Sandonis <maxextreme@gmail.com> | ||
8 | * Date: 2006-10-31 | ||
9 | * | ||
10 | * This program is free software; you can redistribute it and/or modify | ||
11 | * it under the terms of the GNU General Public License version 2 as | ||
12 | * published by the Free Software Foundation. | ||
13 | * | ||
14 | * This program is distributed in the hope that it will be useful, | ||
15 | * but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
16 | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
17 | * GNU General Public License for more details. | ||
18 | * | ||
19 | * You should have received a copy of the GNU General Public License | ||
20 | * along with this program; if not, write to the Free Software | ||
21 | * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA | ||
22 | * | ||
23 | */ | ||
24 | |||
25 | /* | ||
26 | * ------------------------ | ||
27 | * start of cfag12864b code | ||
28 | * ------------------------ | ||
29 | */ | ||
30 | |||
31 | #include <string.h> | ||
32 | #include <fcntl.h> | ||
33 | #include <unistd.h> | ||
34 | #include <sys/types.h> | ||
35 | #include <sys/stat.h> | ||
36 | #include <sys/mman.h> | ||
37 | |||
38 | #define CFAG12864B_WIDTH (128) | ||
39 | #define CFAG12864B_HEIGHT (64) | ||
40 | #define CFAG12864B_SIZE (128 * 64 / 8) | ||
41 | #define CFAG12864B_BPB (8) | ||
42 | #define CFAG12864B_ADDRESS(x, y) ((y) * CFAG12864B_WIDTH / \ | ||
43 | CFAG12864B_BPB + (x) / CFAG12864B_BPB) | ||
44 | #define CFAG12864B_BIT(n) (((unsigned char) 1) << (n)) | ||
45 | |||
46 | #undef CFAG12864B_DOCHECK | ||
47 | #ifdef CFAG12864B_DOCHECK | ||
48 | #define CFAG12864B_CHECK(x, y) ((x) < CFAG12864B_WIDTH && \ | ||
49 | (y) < CFAG12864B_HEIGHT) | ||
50 | #else | ||
51 | #define CFAG12864B_CHECK(x, y) (1) | ||
52 | #endif | ||
53 | |||
54 | int cfag12864b_fd; | ||
55 | unsigned char * cfag12864b_mem; | ||
56 | unsigned char cfag12864b_buffer[CFAG12864B_SIZE]; | ||
57 | |||
58 | /* | ||
59 | * init a cfag12864b framebuffer device | ||
60 | * | ||
61 | * No error: return = 0 | ||
62 | * Unable to open: return = -1 | ||
63 | * Unable to mmap: return = -2 | ||
64 | */ | ||
65 | int cfag12864b_init(char *path) | ||
66 | { | ||
67 | cfag12864b_fd = open(path, O_RDWR); | ||
68 | if (cfag12864b_fd == -1) | ||
69 | return -1; | ||
70 | |||
71 | cfag12864b_mem = mmap(0, CFAG12864B_SIZE, PROT_READ | PROT_WRITE, | ||
72 | MAP_SHARED, cfag12864b_fd, 0); | ||
73 | if (cfag12864b_mem == MAP_FAILED) { | ||
74 | close(cfag12864b_fd); | ||
75 | return -2; | ||
76 | } | ||
77 | |||
78 | return 0; | ||
79 | } | ||
80 | |||
81 | /* | ||
82 | * exit a cfag12864b framebuffer device | ||
83 | */ | ||
84 | void cfag12864b_exit(void) | ||
85 | { | ||
86 | munmap(cfag12864b_mem, CFAG12864B_SIZE); | ||
87 | close(cfag12864b_fd); | ||
88 | } | ||
89 | |||
90 | /* | ||
91 | * set (x, y) pixel | ||
92 | */ | ||
93 | void cfag12864b_set(unsigned char x, unsigned char y) | ||
94 | { | ||
95 | if (CFAG12864B_CHECK(x, y)) | ||
96 | cfag12864b_buffer[CFAG12864B_ADDRESS(x, y)] |= | ||
97 | CFAG12864B_BIT(x % CFAG12864B_BPB); | ||
98 | } | ||
99 | |||
100 | /* | ||
101 | * unset (x, y) pixel | ||
102 | */ | ||
103 | void cfag12864b_unset(unsigned char x, unsigned char y) | ||
104 | { | ||
105 | if (CFAG12864B_CHECK(x, y)) | ||
106 | cfag12864b_buffer[CFAG12864B_ADDRESS(x, y)] &= | ||
107 | ~CFAG12864B_BIT(x % CFAG12864B_BPB); | ||
108 | } | ||
109 | |||
110 | /* | ||
111 | * is set (x, y) pixel? | ||
112 | * | ||
113 | * Pixel off: return = 0 | ||
114 | * Pixel on: return = 1 | ||
115 | */ | ||
116 | unsigned char cfag12864b_isset(unsigned char x, unsigned char y) | ||
117 | { | ||
118 | if (CFAG12864B_CHECK(x, y)) | ||
119 | if (cfag12864b_buffer[CFAG12864B_ADDRESS(x, y)] & | ||
120 | CFAG12864B_BIT(x % CFAG12864B_BPB)) | ||
121 | return 1; | ||
122 | |||
123 | return 0; | ||
124 | } | ||
125 | |||
126 | /* | ||
127 | * not (x, y) pixel | ||
128 | */ | ||
129 | void cfag12864b_not(unsigned char x, unsigned char y) | ||
130 | { | ||
131 | if (cfag12864b_isset(x, y)) | ||
132 | cfag12864b_unset(x, y); | ||
133 | else | ||
134 | cfag12864b_set(x, y); | ||
135 | } | ||
136 | |||
137 | /* | ||
138 | * fill (set all pixels) | ||
139 | */ | ||
140 | void cfag12864b_fill(void) | ||
141 | { | ||
142 | unsigned short i; | ||
143 | |||
144 | for (i = 0; i < CFAG12864B_SIZE; i++) | ||
145 | cfag12864b_buffer[i] = 0xFF; | ||
146 | } | ||
147 | |||
148 | /* | ||
149 | * clear (unset all pixels) | ||
150 | */ | ||
151 | void cfag12864b_clear(void) | ||
152 | { | ||
153 | unsigned short i; | ||
154 | |||
155 | for (i = 0; i < CFAG12864B_SIZE; i++) | ||
156 | cfag12864b_buffer[i] = 0; | ||
157 | } | ||
158 | |||
159 | /* | ||
160 | * format a [128*64] matrix | ||
161 | * | ||
162 | * Pixel off: src[i] = 0 | ||
163 | * Pixel on: src[i] > 0 | ||
164 | */ | ||
165 | void cfag12864b_format(unsigned char * matrix) | ||
166 | { | ||
167 | unsigned char i, j, n; | ||
168 | |||
169 | for (i = 0; i < CFAG12864B_HEIGHT; i++) | ||
170 | for (j = 0; j < CFAG12864B_WIDTH / CFAG12864B_BPB; j++) { | ||
171 | cfag12864b_buffer[i * CFAG12864B_WIDTH / CFAG12864B_BPB + | ||
172 | j] = 0; | ||
173 | for (n = 0; n < CFAG12864B_BPB; n++) | ||
174 | if (matrix[i * CFAG12864B_WIDTH + | ||
175 | j * CFAG12864B_BPB + n]) | ||
176 | cfag12864b_buffer[i * CFAG12864B_WIDTH / | ||
177 | CFAG12864B_BPB + j] |= | ||
178 | CFAG12864B_BIT(n); | ||
179 | } | ||
180 | } | ||
181 | |||
182 | /* | ||
183 | * blit buffer to lcd | ||
184 | */ | ||
185 | void cfag12864b_blit(void) | ||
186 | { | ||
187 | memcpy(cfag12864b_mem, cfag12864b_buffer, CFAG12864B_SIZE); | ||
188 | } | ||
189 | |||
190 | /* | ||
191 | * ---------------------- | ||
192 | * end of cfag12864b code | ||
193 | * ---------------------- | ||
194 | */ | ||
195 | |||
196 | #include <stdio.h> | ||
197 | #include <string.h> | ||
198 | |||
199 | #define EXAMPLES 6 | ||
200 | |||
201 | void example(unsigned char n) | ||
202 | { | ||
203 | unsigned short i, j; | ||
204 | unsigned char matrix[CFAG12864B_WIDTH * CFAG12864B_HEIGHT]; | ||
205 | |||
206 | if (n > EXAMPLES) | ||
207 | return; | ||
208 | |||
209 | printf("Example %i/%i - ", n, EXAMPLES); | ||
210 | |||
211 | switch (n) { | ||
212 | case 1: | ||
213 | printf("Draw points setting bits"); | ||
214 | cfag12864b_clear(); | ||
215 | for (i = 0; i < CFAG12864B_WIDTH; i += 2) | ||
216 | for (j = 0; j < CFAG12864B_HEIGHT; j += 2) | ||
217 | cfag12864b_set(i, j); | ||
218 | break; | ||
219 | |||
220 | case 2: | ||
221 | printf("Clear the LCD"); | ||
222 | cfag12864b_clear(); | ||
223 | break; | ||
224 | |||
225 | case 3: | ||
226 | printf("Draw rows formatting a [128*64] matrix"); | ||
227 | memset(matrix, 0, CFAG12864B_WIDTH * CFAG12864B_HEIGHT); | ||
228 | for (i = 0; i < CFAG12864B_WIDTH; i++) | ||
229 | for (j = 0; j < CFAG12864B_HEIGHT; j += 2) | ||
230 | matrix[j * CFAG12864B_WIDTH + i] = 1; | ||
231 | cfag12864b_format(matrix); | ||
232 | break; | ||
233 | |||
234 | case 4: | ||
235 | printf("Fill the lcd"); | ||
236 | cfag12864b_fill(); | ||
237 | break; | ||
238 | |||
239 | case 5: | ||
240 | printf("Draw columns unsetting bits"); | ||
241 | for (i = 0; i < CFAG12864B_WIDTH; i += 2) | ||
242 | for (j = 0; j < CFAG12864B_HEIGHT; j++) | ||
243 | cfag12864b_unset(i, j); | ||
244 | break; | ||
245 | |||
246 | case 6: | ||
247 | printf("Do negative not-ing all bits"); | ||
248 | for (i = 0; i < CFAG12864B_WIDTH; i++) | ||
249 | for (j = 0; j < CFAG12864B_HEIGHT; j ++) | ||
250 | cfag12864b_not(i, j); | ||
251 | break; | ||
252 | } | ||
253 | |||
254 | puts(" - [Press Enter]"); | ||
255 | } | ||
256 | |||
257 | int main(int argc, char *argv[]) | ||
258 | { | ||
259 | unsigned char n; | ||
260 | |||
261 | if (argc != 2) { | ||
262 | printf( | ||
263 | "Sintax: %s fbdev\n" | ||
264 | "Usually: /dev/fb0, /dev/fb1...\n", argv[0]); | ||
265 | return -1; | ||
266 | } | ||
267 | |||
268 | if (cfag12864b_init(argv[1])) { | ||
269 | printf("Can't init %s fbdev\n", argv[1]); | ||
270 | return -2; | ||
271 | } | ||
272 | |||
273 | for (n = 1; n <= EXAMPLES; n++) { | ||
274 | example(n); | ||
275 | cfag12864b_blit(); | ||
276 | while (getchar() != '\n'); | ||
277 | } | ||
278 | |||
279 | cfag12864b_exit(); | ||
280 | |||
281 | return 0; | ||
282 | } | ||
diff --git a/Documentation/auxdisplay/ks0108 b/Documentation/auxdisplay/ks0108 new file mode 100644 index 000000000000..92b03b60c613 --- /dev/null +++ b/Documentation/auxdisplay/ks0108 | |||
@@ -0,0 +1,55 @@ | |||
1 | ========================================== | ||
2 | ks0108 LCD Controller Driver Documentation | ||
3 | ========================================== | ||
4 | |||
5 | License: GPLv2 | ||
6 | Author & Maintainer: Miguel Ojeda Sandonis <maxextreme@gmail.com> | ||
7 | Date: 2006-10-27 | ||
8 | |||
9 | |||
10 | |||
11 | -------- | ||
12 | 0. INDEX | ||
13 | -------- | ||
14 | |||
15 | 1. DRIVER INFORMATION | ||
16 | 2. DEVICE INFORMATION | ||
17 | 3. WIRING | ||
18 | |||
19 | |||
20 | --------------------- | ||
21 | 1. DRIVER INFORMATION | ||
22 | --------------------- | ||
23 | |||
24 | This driver support the ks0108 LCD controller. | ||
25 | |||
26 | |||
27 | --------------------- | ||
28 | 2. DEVICE INFORMATION | ||
29 | --------------------- | ||
30 | |||
31 | Manufacturer: Samsung | ||
32 | Device Name: KS0108 LCD Controller | ||
33 | Device Code: ks0108 | ||
34 | Webpage: - | ||
35 | Device Webpage: - | ||
36 | Type: LCD Controller (Liquid Crystal Display Controller) | ||
37 | Width: 64 | ||
38 | Height: 64 | ||
39 | Colors: 2 (B/N) | ||
40 | Pages: 8 | ||
41 | Addresses: 64 each page | ||
42 | Data size: 1 byte each address | ||
43 | Memory size: 8 * 64 * 1 = 512 bytes | ||
44 | |||
45 | |||
46 | --------- | ||
47 | 3. WIRING | ||
48 | --------- | ||
49 | |||
50 | The driver supports data parallel port wiring. | ||
51 | |||
52 | If you aren't building LCD related hardware, you should check | ||
53 | your LCD specific wiring information in the same folder. | ||
54 | |||
55 | For example, check Documentation/auxdisplay/cfag12864b. | ||
diff --git a/Documentation/cdrom/packet-writing.txt b/Documentation/cdrom/packet-writing.txt index 7715d2247c4d..cf1f8126991c 100644 --- a/Documentation/cdrom/packet-writing.txt +++ b/Documentation/cdrom/packet-writing.txt | |||
@@ -93,7 +93,7 @@ Notes | |||
93 | Using the pktcdvd sysfs interface | 93 | Using the pktcdvd sysfs interface |
94 | --------------------------------- | 94 | --------------------------------- |
95 | 95 | ||
96 | Since Linux 2.6.19, the pktcdvd module has a sysfs interface | 96 | Since Linux 2.6.20, the pktcdvd module has a sysfs interface |
97 | and can be controlled by it. For example the "pktcdvd" tool uses | 97 | and can be controlled by it. For example the "pktcdvd" tool uses |
98 | this interface. (see http://people.freenet.de/BalaGi#pktcdvd ) | 98 | this interface. (see http://people.freenet.de/BalaGi#pktcdvd ) |
99 | 99 | ||
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index fa844fd7bded..8247a4b79d09 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -215,6 +215,13 @@ Who: Jean Delvare <khali@linux-fr.org>, | |||
215 | 215 | ||
216 | --------------------------- | 216 | --------------------------- |
217 | 217 | ||
218 | What: drivers depending on OBSOLETE_OSS | ||
219 | When: options in 2.6.22, code in 2.6.24 | ||
220 | Why: OSS drivers with ALSA replacements | ||
221 | Who: Adrian Bunk <bunk@stusta.de> | ||
222 | |||
223 | --------------------------- | ||
224 | |||
218 | What: IPv4 only connection tracking/NAT/helpers | 225 | What: IPv4 only connection tracking/NAT/helpers |
219 | When: 2.6.22 | 226 | When: 2.6.22 |
220 | Why: The new layer 3 independant connection tracking replaces the old | 227 | Why: The new layer 3 independant connection tracking replaces the old |
diff --git a/Documentation/filesystems/relay.txt b/Documentation/filesystems/relay.txt index d6788dae0349..7fbb6ffe5769 100644 --- a/Documentation/filesystems/relay.txt +++ b/Documentation/filesystems/relay.txt | |||
@@ -157,7 +157,7 @@ TBD(curr. line MT:/API/) | |||
157 | channel management functions: | 157 | channel management functions: |
158 | 158 | ||
159 | relay_open(base_filename, parent, subbuf_size, n_subbufs, | 159 | relay_open(base_filename, parent, subbuf_size, n_subbufs, |
160 | callbacks) | 160 | callbacks, private_data) |
161 | relay_close(chan) | 161 | relay_close(chan) |
162 | relay_flush(chan) | 162 | relay_flush(chan) |
163 | relay_reset(chan) | 163 | relay_reset(chan) |
@@ -251,7 +251,7 @@ static struct rchan_callbacks relay_callbacks = | |||
251 | 251 | ||
252 | And an example relay_open() invocation using them: | 252 | And an example relay_open() invocation using them: |
253 | 253 | ||
254 | chan = relay_open("cpu", NULL, SUBBUF_SIZE, N_SUBBUFS, &relay_callbacks); | 254 | chan = relay_open("cpu", NULL, SUBBUF_SIZE, N_SUBBUFS, &relay_callbacks, NULL); |
255 | 255 | ||
256 | If the create_buf_file() callback fails, or isn't defined, channel | 256 | If the create_buf_file() callback fails, or isn't defined, channel |
257 | creation and thus relay_open() will fail. | 257 | creation and thus relay_open() will fail. |
@@ -289,6 +289,11 @@ they use the proper locking for such a buffer, either by wrapping | |||
289 | writes in a spinlock, or by copying a write function from relay.h and | 289 | writes in a spinlock, or by copying a write function from relay.h and |
290 | creating a local version that internally does the proper locking. | 290 | creating a local version that internally does the proper locking. |
291 | 291 | ||
292 | The private_data passed into relay_open() allows clients to associate | ||
293 | user-defined data with a channel, and is immediately available | ||
294 | (including in create_buf_file()) via chan->private_data or | ||
295 | buf->chan->private_data. | ||
296 | |||
292 | Channel 'modes' | 297 | Channel 'modes' |
293 | --------------- | 298 | --------------- |
294 | 299 | ||
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt index 5a8bd5bd88ef..8f750c0efed5 100644 --- a/Documentation/ioctl-number.txt +++ b/Documentation/ioctl-number.txt | |||
@@ -94,8 +94,7 @@ Code Seq# Include File Comments | |||
94 | 'L' 00-1F linux/loop.h | 94 | 'L' 00-1F linux/loop.h |
95 | 'L' E0-FF linux/ppdd.h encrypted disk device driver | 95 | 'L' E0-FF linux/ppdd.h encrypted disk device driver |
96 | <http://linux01.gwdg.de/~alatham/ppdd.html> | 96 | <http://linux01.gwdg.de/~alatham/ppdd.html> |
97 | 'M' all linux/soundcard.h conflict! | 97 | 'M' all linux/soundcard.h |
98 | 'M' 00-1F linux/isicom.h conflict! | ||
99 | 'N' 00-1F drivers/usb/scanner.h | 98 | 'N' 00-1F drivers/usb/scanner.h |
100 | 'P' all linux/soundcard.h | 99 | 'P' all linux/soundcard.h |
101 | 'Q' all linux/soundcard.h | 100 | 'Q' all linux/soundcard.h |
diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt index 284e7e198e93..2075c0658bf5 100644 --- a/Documentation/kernel-doc-nano-HOWTO.txt +++ b/Documentation/kernel-doc-nano-HOWTO.txt | |||
@@ -101,16 +101,20 @@ The format of the block comment is like this: | |||
101 | 101 | ||
102 | /** | 102 | /** |
103 | * function_name(:)? (- short description)? | 103 | * function_name(:)? (- short description)? |
104 | (* @parameterx: (description of parameter x)?)* | 104 | (* @parameterx(space)*: (description of parameter x)?)* |
105 | (* a blank line)? | 105 | (* a blank line)? |
106 | * (Description:)? (Description of function)? | 106 | * (Description:)? (Description of function)? |
107 | * (section header: (section description)? )* | 107 | * (section header: (section description)? )* |
108 | (*)?*/ | 108 | (*)?*/ |
109 | 109 | ||
110 | The short function description cannot be multiline, but the other | 110 | The short function description ***cannot be multiline***, but the other |
111 | descriptions can be (and they can contain blank lines). Avoid putting a | 111 | descriptions can be (and they can contain blank lines). If you continue |
112 | spurious blank line after the function name, or else the description will | 112 | that initial short description onto a second line, that second line will |
113 | be repeated! | 113 | appear further down at the beginning of the description section, which is |
114 | almost certainly not what you had in mind. | ||
115 | |||
116 | Avoid putting a spurious blank line after the function name, or else the | ||
117 | description will be repeated! | ||
114 | 118 | ||
115 | All descriptive text is further processed, scanning for the following special | 119 | All descriptive text is further processed, scanning for the following special |
116 | patterns, which are highlighted appropriately. | 120 | patterns, which are highlighted appropriately. |
@@ -121,6 +125,31 @@ patterns, which are highlighted appropriately. | |||
121 | '@parameter' - name of a parameter | 125 | '@parameter' - name of a parameter |
122 | '%CONST' - name of a constant. | 126 | '%CONST' - name of a constant. |
123 | 127 | ||
128 | NOTE 1: The multi-line descriptive text you provide does *not* recognize | ||
129 | line breaks, so if you try to format some text nicely, as in: | ||
130 | |||
131 | Return codes | ||
132 | 0 - cool | ||
133 | 1 - invalid arg | ||
134 | 2 - out of memory | ||
135 | |||
136 | this will all run together and produce: | ||
137 | |||
138 | Return codes 0 - cool 1 - invalid arg 2 - out of memory | ||
139 | |||
140 | NOTE 2: If the descriptive text you provide has lines that begin with | ||
141 | some phrase followed by a colon, each of those phrases will be taken as | ||
142 | a new section heading, which means you should similarly try to avoid text | ||
143 | like: | ||
144 | |||
145 | Return codes: | ||
146 | 0: cool | ||
147 | 1: invalid arg | ||
148 | 2: out of memory | ||
149 | |||
150 | every line of which would start a new section. Again, probably not | ||
151 | what you were after. | ||
152 | |||
124 | Take a look around the source tree for examples. | 153 | Take a look around the source tree for examples. |
125 | 154 | ||
126 | 155 | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 25d298517104..d25acd51e181 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -1396,6 +1396,8 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1396 | in <PAGE_SIZE> units (needed only for swap files). | 1396 | in <PAGE_SIZE> units (needed only for swap files). |
1397 | See Documentation/power/swsusp-and-swap-files.txt | 1397 | See Documentation/power/swsusp-and-swap-files.txt |
1398 | 1398 | ||
1399 | retain_initrd [RAM] Keep initrd memory after extraction | ||
1400 | |||
1399 | rhash_entries= [KNL,NET] | 1401 | rhash_entries= [KNL,NET] |
1400 | Set number of hash buckets for route cache | 1402 | Set number of hash buckets for route cache |
1401 | 1403 | ||
diff --git a/Documentation/local_ops.txt b/Documentation/local_ops.txt new file mode 100644 index 000000000000..b0aca0705d1e --- /dev/null +++ b/Documentation/local_ops.txt | |||
@@ -0,0 +1,163 @@ | |||
1 | Semantics and Behavior of Local Atomic Operations | ||
2 | |||
3 | Mathieu Desnoyers | ||
4 | |||
5 | |||
6 | This document explains the purpose of the local atomic operations, how | ||
7 | to implement them for any given architecture and shows how they can be used | ||
8 | properly. It also stresses on the precautions that must be taken when reading | ||
9 | those local variables across CPUs when the order of memory writes matters. | ||
10 | |||
11 | |||
12 | |||
13 | * Purpose of local atomic operations | ||
14 | |||
15 | Local atomic operations are meant to provide fast and highly reentrant per CPU | ||
16 | counters. They minimize the performance cost of standard atomic operations by | ||
17 | removing the LOCK prefix and memory barriers normally required to synchronize | ||
18 | across CPUs. | ||
19 | |||
20 | Having fast per CPU atomic counters is interesting in many cases : it does not | ||
21 | require disabling interrupts to protect from interrupt handlers and it permits | ||
22 | coherent counters in NMI handlers. It is especially useful for tracing purposes | ||
23 | and for various performance monitoring counters. | ||
24 | |||
25 | Local atomic operations only guarantee variable modification atomicity wrt the | ||
26 | CPU which owns the data. Therefore, care must taken to make sure that only one | ||
27 | CPU writes to the local_t data. This is done by using per cpu data and making | ||
28 | sure that we modify it from within a preemption safe context. It is however | ||
29 | permitted to read local_t data from any CPU : it will then appear to be written | ||
30 | out of order wrt other memory writes on the owner CPU. | ||
31 | |||
32 | |||
33 | * Implementation for a given architecture | ||
34 | |||
35 | It can be done by slightly modifying the standard atomic operations : only | ||
36 | their UP variant must be kept. It typically means removing LOCK prefix (on | ||
37 | i386 and x86_64) and any SMP sychronization barrier. If the architecture does | ||
38 | not have a different behavior between SMP and UP, including asm-generic/local.h | ||
39 | in your archtecture's local.h is sufficient. | ||
40 | |||
41 | The local_t type is defined as an opaque signed long by embedding an | ||
42 | atomic_long_t inside a structure. This is made so a cast from this type to a | ||
43 | long fails. The definition looks like : | ||
44 | |||
45 | typedef struct { atomic_long_t a; } local_t; | ||
46 | |||
47 | |||
48 | * How to use local atomic operations | ||
49 | |||
50 | #include <linux/percpu.h> | ||
51 | #include <asm/local.h> | ||
52 | |||
53 | static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0); | ||
54 | |||
55 | |||
56 | * Counting | ||
57 | |||
58 | Counting is done on all the bits of a signed long. | ||
59 | |||
60 | In preemptible context, use get_cpu_var() and put_cpu_var() around local atomic | ||
61 | operations : it makes sure that preemption is disabled around write access to | ||
62 | the per cpu variable. For instance : | ||
63 | |||
64 | local_inc(&get_cpu_var(counters)); | ||
65 | put_cpu_var(counters); | ||
66 | |||
67 | If you are already in a preemption-safe context, you can directly use | ||
68 | __get_cpu_var() instead. | ||
69 | |||
70 | local_inc(&__get_cpu_var(counters)); | ||
71 | |||
72 | |||
73 | |||
74 | * Reading the counters | ||
75 | |||
76 | Those local counters can be read from foreign CPUs to sum the count. Note that | ||
77 | the data seen by local_read across CPUs must be considered to be out of order | ||
78 | relatively to other memory writes happening on the CPU that owns the data. | ||
79 | |||
80 | long sum = 0; | ||
81 | for_each_online_cpu(cpu) | ||
82 | sum += local_read(&per_cpu(counters, cpu)); | ||
83 | |||
84 | If you want to use a remote local_read to synchronize access to a resource | ||
85 | between CPUs, explicit smp_wmb() and smp_rmb() memory barriers must be used | ||
86 | respectively on the writer and the reader CPUs. It would be the case if you use | ||
87 | the local_t variable as a counter of bytes written in a buffer : there should | ||
88 | be a smp_wmb() between the buffer write and the counter increment and also a | ||
89 | smp_rmb() between the counter read and the buffer read. | ||
90 | |||
91 | |||
92 | Here is a sample module which implements a basic per cpu counter using local.h. | ||
93 | |||
94 | --- BEGIN --- | ||
95 | /* test-local.c | ||
96 | * | ||
97 | * Sample module for local.h usage. | ||
98 | */ | ||
99 | |||
100 | |||
101 | #include <asm/local.h> | ||
102 | #include <linux/module.h> | ||
103 | #include <linux/timer.h> | ||
104 | |||
105 | static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0); | ||
106 | |||
107 | static struct timer_list test_timer; | ||
108 | |||
109 | /* IPI called on each CPU. */ | ||
110 | static void test_each(void *info) | ||
111 | { | ||
112 | /* Increment the counter from a non preemptible context */ | ||
113 | printk("Increment on cpu %d\n", smp_processor_id()); | ||
114 | local_inc(&__get_cpu_var(counters)); | ||
115 | |||
116 | /* This is what incrementing the variable would look like within a | ||
117 | * preemptible context (it disables preemption) : | ||
118 | * | ||
119 | * local_inc(&get_cpu_var(counters)); | ||
120 | * put_cpu_var(counters); | ||
121 | */ | ||
122 | } | ||
123 | |||
124 | static void do_test_timer(unsigned long data) | ||
125 | { | ||
126 | int cpu; | ||
127 | |||
128 | /* Increment the counters */ | ||
129 | on_each_cpu(test_each, NULL, 0, 1); | ||
130 | /* Read all the counters */ | ||
131 | printk("Counters read from CPU %d\n", smp_processor_id()); | ||
132 | for_each_online_cpu(cpu) { | ||
133 | printk("Read : CPU %d, count %ld\n", cpu, | ||
134 | local_read(&per_cpu(counters, cpu))); | ||
135 | } | ||
136 | del_timer(&test_timer); | ||
137 | test_timer.expires = jiffies + 1000; | ||
138 | add_timer(&test_timer); | ||
139 | } | ||
140 | |||
141 | static int __init test_init(void) | ||
142 | { | ||
143 | /* initialize the timer that will increment the counter */ | ||
144 | init_timer(&test_timer); | ||
145 | test_timer.function = do_test_timer; | ||
146 | test_timer.expires = jiffies + 1; | ||
147 | add_timer(&test_timer); | ||
148 | |||
149 | return 0; | ||
150 | } | ||
151 | |||
152 | static void __exit test_exit(void) | ||
153 | { | ||
154 | del_timer_sync(&test_timer); | ||
155 | } | ||
156 | |||
157 | module_init(test_init); | ||
158 | module_exit(test_exit); | ||
159 | |||
160 | MODULE_LICENSE("GPL"); | ||
161 | MODULE_AUTHOR("Mathieu Desnoyers"); | ||
162 | MODULE_DESCRIPTION("Local Atomic Ops"); | ||
163 | --- END --- | ||
diff --git a/Documentation/rbtree.txt b/Documentation/rbtree.txt new file mode 100644 index 000000000000..7224459b469e --- /dev/null +++ b/Documentation/rbtree.txt | |||
@@ -0,0 +1,192 @@ | |||
1 | Red-black Trees (rbtree) in Linux | ||
2 | January 18, 2007 | ||
3 | Rob Landley <rob@landley.net> | ||
4 | ============================= | ||
5 | |||
6 | What are red-black trees, and what are they for? | ||
7 | ------------------------------------------------ | ||
8 | |||
9 | Red-black trees are a type of self-balancing binary search tree, used for | ||
10 | storing sortable key/value data pairs. This differs from radix trees (which | ||
11 | are used to efficiently store sparse arrays and thus use long integer indexes | ||
12 | to insert/access/delete nodes) and hash tables (which are not kept sorted to | ||
13 | be easily traversed in order, and must be tuned for a specific size and | ||
14 | hash function where rbtrees scale gracefully storing arbitrary keys). | ||
15 | |||
16 | Red-black trees are similar to AVL trees, but provide faster real-time bounded | ||
17 | worst case performance for insertion and deletion (at most two rotations and | ||
18 | three rotations, respectively, to balance the tree), with slightly slower | ||
19 | (but still O(log n)) lookup time. | ||
20 | |||
21 | To quote Linux Weekly News: | ||
22 | |||
23 | There are a number of red-black trees in use in the kernel. | ||
24 | The anticipatory, deadline, and CFQ I/O schedulers all employ | ||
25 | rbtrees to track requests; the packet CD/DVD driver does the same. | ||
26 | The high-resolution timer code uses an rbtree to organize outstanding | ||
27 | timer requests. The ext3 filesystem tracks directory entries in a | ||
28 | red-black tree. Virtual memory areas (VMAs) are tracked with red-black | ||
29 | trees, as are epoll file descriptors, cryptographic keys, and network | ||
30 | packets in the "hierarchical token bucket" scheduler. | ||
31 | |||
32 | This document covers use of the Linux rbtree implementation. For more | ||
33 | information on the nature and implementation of Red Black Trees, see: | ||
34 | |||
35 | Linux Weekly News article on red-black trees | ||
36 | http://lwn.net/Articles/184495/ | ||
37 | |||
38 | Wikipedia entry on red-black trees | ||
39 | http://en.wikipedia.org/wiki/Red-black_tree | ||
40 | |||
41 | Linux implementation of red-black trees | ||
42 | --------------------------------------- | ||
43 | |||
44 | Linux's rbtree implementation lives in the file "lib/rbtree.c". To use it, | ||
45 | "#include <linux/rbtree.h>". | ||
46 | |||
47 | The Linux rbtree implementation is optimized for speed, and thus has one | ||
48 | less layer of indirection (and better cache locality) than more traditional | ||
49 | tree implementations. Instead of using pointers to separate rb_node and data | ||
50 | structures, each instance of struct rb_node is embedded in the data structure | ||
51 | it organizes. And instead of using a comparison callback function pointer, | ||
52 | users are expected to write their own tree search and insert functions | ||
53 | which call the provided rbtree functions. Locking is also left up to the | ||
54 | user of the rbtree code. | ||
55 | |||
56 | Creating a new rbtree | ||
57 | --------------------- | ||
58 | |||
59 | Data nodes in an rbtree tree are structures containing a struct rb_node member: | ||
60 | |||
61 | struct mytype { | ||
62 | struct rb_node node; | ||
63 | char *keystring; | ||
64 | }; | ||
65 | |||
66 | When dealing with a pointer to the embedded struct rb_node, the containing data | ||
67 | structure may be accessed with the standard container_of() macro. In addition, | ||
68 | individual members may be accessed directly via rb_entry(node, type, member). | ||
69 | |||
70 | At the root of each rbtree is an rb_root structure, which is initialized to be | ||
71 | empty via: | ||
72 | |||
73 | struct rb_root mytree = RB_ROOT; | ||
74 | |||
75 | Searching for a value in an rbtree | ||
76 | ---------------------------------- | ||
77 | |||
78 | Writing a search function for your tree is fairly straightforward: start at the | ||
79 | root, compare each value, and follow the left or right branch as necessary. | ||
80 | |||
81 | Example: | ||
82 | |||
83 | struct mytype *my_search(struct rb_root *root, char *string) | ||
84 | { | ||
85 | struct rb_node *node = root->rb_node; | ||
86 | |||
87 | while (node) { | ||
88 | struct mytype *data = container_of(node, struct mytype, node); | ||
89 | int result; | ||
90 | |||
91 | result = strcmp(string, data->keystring); | ||
92 | |||
93 | if (result < 0) | ||
94 | node = node->rb_left; | ||
95 | else if (result > 0) | ||
96 | node = node->rb_right; | ||
97 | else | ||
98 | return data; | ||
99 | } | ||
100 | return NULL; | ||
101 | } | ||
102 | |||
103 | Inserting data into an rbtree | ||
104 | ----------------------------- | ||
105 | |||
106 | Inserting data in the tree involves first searching for the place to insert the | ||
107 | new node, then inserting the node and rebalancing ("recoloring") the tree. | ||
108 | |||
109 | The search for insertion differs from the previous search by finding the | ||
110 | location of the pointer on which to graft the new node. The new node also | ||
111 | needs a link to its parent node for rebalancing purposes. | ||
112 | |||
113 | Example: | ||
114 | |||
115 | int my_insert(struct rb_root *root, struct mytype *data) | ||
116 | { | ||
117 | struct rb_node **new = &(root->rb_node), *parent = NULL; | ||
118 | |||
119 | /* Figure out where to put new node */ | ||
120 | while (*new) { | ||
121 | struct mytype *this = container_of(*new, struct mytype, node); | ||
122 | int result = strcmp(data->keystring, this->keystring); | ||
123 | |||
124 | parent = *new; | ||
125 | if (result < 0) | ||
126 | new = &((*new)->rb_left); | ||
127 | else if (result > 0) | ||
128 | new = &((*new)->rb_right); | ||
129 | else | ||
130 | return FALSE; | ||
131 | } | ||
132 | |||
133 | /* Add new node and rebalance tree. */ | ||
134 | rb_link_node(data->node, parent, new); | ||
135 | rb_insert_color(data->node, root); | ||
136 | |||
137 | return TRUE; | ||
138 | } | ||
139 | |||
140 | Removing or replacing existing data in an rbtree | ||
141 | ------------------------------------------------ | ||
142 | |||
143 | To remove an existing node from a tree, call: | ||
144 | |||
145 | void rb_erase(struct rb_node *victim, struct rb_root *tree); | ||
146 | |||
147 | Example: | ||
148 | |||
149 | struct mytype *data = mysearch(mytree, "walrus"); | ||
150 | |||
151 | if (data) { | ||
152 | rb_erase(data->node, mytree); | ||
153 | myfree(data); | ||
154 | } | ||
155 | |||
156 | To replace an existing node in a tree with a new one with the same key, call: | ||
157 | |||
158 | void rb_replace_node(struct rb_node *old, struct rb_node *new, | ||
159 | struct rb_root *tree); | ||
160 | |||
161 | Replacing a node this way does not re-sort the tree: If the new node doesn't | ||
162 | have the same key as the old node, the rbtree will probably become corrupted. | ||
163 | |||
164 | Iterating through the elements stored in an rbtree (in sort order) | ||
165 | ------------------------------------------------------------------ | ||
166 | |||
167 | Four functions are provided for iterating through an rbtree's contents in | ||
168 | sorted order. These work on arbitrary trees, and should not need to be | ||
169 | modified or wrapped (except for locking purposes): | ||
170 | |||
171 | struct rb_node *rb_first(struct rb_root *tree); | ||
172 | struct rb_node *rb_last(struct rb_root *tree); | ||
173 | struct rb_node *rb_next(struct rb_node *node); | ||
174 | struct rb_node *rb_prev(struct rb_node *node); | ||
175 | |||
176 | To start iterating, call rb_first() or rb_last() with a pointer to the root | ||
177 | of the tree, which will return a pointer to the node structure contained in | ||
178 | the first or last element in the tree. To continue, fetch the next or previous | ||
179 | node by calling rb_next() or rb_prev() on the current node. This will return | ||
180 | NULL when there are no more nodes left. | ||
181 | |||
182 | The iterator functions return a pointer to the embedded struct rb_node, from | ||
183 | which the containing data structure may be accessed with the container_of() | ||
184 | macro, and individual members may be accessed directly via | ||
185 | rb_entry(node, type, member). | ||
186 | |||
187 | Example: | ||
188 | |||
189 | struct rb_node *node; | ||
190 | for (node = rb_first(&mytree); node; node = rb_next(node)) | ||
191 | printk("key=%s\n", rb_entry(node, int, keystring)); | ||
192 | |||
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt index 7cf1ec5bcdd3..1ef6bb88cd00 100644 --- a/Documentation/rtc.txt +++ b/Documentation/rtc.txt | |||
@@ -149,7 +149,7 @@ RTC class framework, but can't be supported by the older driver. | |||
149 | is connected to an IRQ line, it can often issue an alarm IRQ up to | 149 | is connected to an IRQ line, it can often issue an alarm IRQ up to |
150 | 24 hours in the future. | 150 | 24 hours in the future. |
151 | 151 | ||
152 | * RTC_WKALM_SET, RTC_WKALM_READ ... RTCs that can issue alarms beyond | 152 | * RTC_WKALM_SET, RTC_WKALM_RD ... RTCs that can issue alarms beyond |
153 | the next 24 hours use a slightly more powerful API, which supports | 153 | the next 24 hours use a slightly more powerful API, which supports |
154 | setting the longer alarm time and enabling its IRQ using a single | 154 | setting the longer alarm time and enabling its IRQ using a single |
155 | request (using the same model as EFI firmware). | 155 | request (using the same model as EFI firmware). |
@@ -167,6 +167,28 @@ Linux out of a low power sleep state (or hibernation) back to a fully | |||
167 | operational state. For example, a system could enter a deep power saving | 167 | operational state. For example, a system could enter a deep power saving |
168 | state until it's time to execute some scheduled tasks. | 168 | state until it's time to execute some scheduled tasks. |
169 | 169 | ||
170 | Note that many of these ioctls need not actually be implemented by your | ||
171 | driver. The common rtc-dev interface handles many of these nicely if your | ||
172 | driver returns ENOIOCTLCMD. Some common examples: | ||
173 | |||
174 | * RTC_RD_TIME, RTC_SET_TIME: the read_time/set_time functions will be | ||
175 | called with appropriate values. | ||
176 | |||
177 | * RTC_ALM_SET, RTC_ALM_READ, RTC_WKALM_SET, RTC_WKALM_RD: the | ||
178 | set_alarm/read_alarm functions will be called. To differentiate | ||
179 | between the ALM and WKALM, check the larger fields of the rtc_wkalrm | ||
180 | struct (like tm_year). These will be set to -1 when using ALM and | ||
181 | will be set to proper values when using WKALM. | ||
182 | |||
183 | * RTC_IRQP_SET, RTC_IRQP_READ: the irq_set_freq function will be called | ||
184 | to set the frequency while the framework will handle the read for you | ||
185 | since the frequency is stored in the irq_freq member of the rtc_device | ||
186 | structure. Also make sure you set the max_user_freq member in your | ||
187 | initialization routines so the framework can sanity check the user | ||
188 | input for you. | ||
189 | |||
190 | If all else fails, check out the rtc-test.c driver! | ||
191 | |||
170 | 192 | ||
171 | -------------------- 8< ---------------- 8< ----------------------------- | 193 | -------------------- 8< ---------------- 8< ----------------------------- |
172 | 194 | ||
@@ -237,7 +259,7 @@ int main(int argc, char **argv) | |||
237 | "\n...Update IRQs not supported.\n"); | 259 | "\n...Update IRQs not supported.\n"); |
238 | goto test_READ; | 260 | goto test_READ; |
239 | } | 261 | } |
240 | perror("ioctl"); | 262 | perror("RTC_UIE_ON ioctl"); |
241 | exit(errno); | 263 | exit(errno); |
242 | } | 264 | } |
243 | 265 | ||
@@ -284,7 +306,7 @@ int main(int argc, char **argv) | |||
284 | /* Turn off update interrupts */ | 306 | /* Turn off update interrupts */ |
285 | retval = ioctl(fd, RTC_UIE_OFF, 0); | 307 | retval = ioctl(fd, RTC_UIE_OFF, 0); |
286 | if (retval == -1) { | 308 | if (retval == -1) { |
287 | perror("ioctl"); | 309 | perror("RTC_UIE_OFF ioctl"); |
288 | exit(errno); | 310 | exit(errno); |
289 | } | 311 | } |
290 | 312 | ||
@@ -292,7 +314,7 @@ test_READ: | |||
292 | /* Read the RTC time/date */ | 314 | /* Read the RTC time/date */ |
293 | retval = ioctl(fd, RTC_RD_TIME, &rtc_tm); | 315 | retval = ioctl(fd, RTC_RD_TIME, &rtc_tm); |
294 | if (retval == -1) { | 316 | if (retval == -1) { |
295 | perror("ioctl"); | 317 | perror("RTC_RD_TIME ioctl"); |
296 | exit(errno); | 318 | exit(errno); |
297 | } | 319 | } |
298 | 320 | ||
@@ -320,14 +342,14 @@ test_READ: | |||
320 | "\n...Alarm IRQs not supported.\n"); | 342 | "\n...Alarm IRQs not supported.\n"); |
321 | goto test_PIE; | 343 | goto test_PIE; |
322 | } | 344 | } |
323 | perror("ioctl"); | 345 | perror("RTC_ALM_SET ioctl"); |
324 | exit(errno); | 346 | exit(errno); |
325 | } | 347 | } |
326 | 348 | ||
327 | /* Read the current alarm settings */ | 349 | /* Read the current alarm settings */ |
328 | retval = ioctl(fd, RTC_ALM_READ, &rtc_tm); | 350 | retval = ioctl(fd, RTC_ALM_READ, &rtc_tm); |
329 | if (retval == -1) { | 351 | if (retval == -1) { |
330 | perror("ioctl"); | 352 | perror("RTC_ALM_READ ioctl"); |
331 | exit(errno); | 353 | exit(errno); |
332 | } | 354 | } |
333 | 355 | ||
@@ -337,7 +359,7 @@ test_READ: | |||
337 | /* Enable alarm interrupts */ | 359 | /* Enable alarm interrupts */ |
338 | retval = ioctl(fd, RTC_AIE_ON, 0); | 360 | retval = ioctl(fd, RTC_AIE_ON, 0); |
339 | if (retval == -1) { | 361 | if (retval == -1) { |
340 | perror("ioctl"); | 362 | perror("RTC_AIE_ON ioctl"); |
341 | exit(errno); | 363 | exit(errno); |
342 | } | 364 | } |
343 | 365 | ||
@@ -355,7 +377,7 @@ test_READ: | |||
355 | /* Disable alarm interrupts */ | 377 | /* Disable alarm interrupts */ |
356 | retval = ioctl(fd, RTC_AIE_OFF, 0); | 378 | retval = ioctl(fd, RTC_AIE_OFF, 0); |
357 | if (retval == -1) { | 379 | if (retval == -1) { |
358 | perror("ioctl"); | 380 | perror("RTC_AIE_OFF ioctl"); |
359 | exit(errno); | 381 | exit(errno); |
360 | } | 382 | } |
361 | 383 | ||
@@ -368,7 +390,7 @@ test_PIE: | |||
368 | fprintf(stderr, "\nNo periodic IRQ support\n"); | 390 | fprintf(stderr, "\nNo periodic IRQ support\n"); |
369 | return 0; | 391 | return 0; |
370 | } | 392 | } |
371 | perror("ioctl"); | 393 | perror("RTC_IRQP_READ ioctl"); |
372 | exit(errno); | 394 | exit(errno); |
373 | } | 395 | } |
374 | fprintf(stderr, "\nPeriodic IRQ rate is %ldHz.\n", tmp); | 396 | fprintf(stderr, "\nPeriodic IRQ rate is %ldHz.\n", tmp); |
@@ -387,7 +409,7 @@ test_PIE: | |||
387 | "\n...Periodic IRQ rate is fixed\n"); | 409 | "\n...Periodic IRQ rate is fixed\n"); |
388 | goto done; | 410 | goto done; |
389 | } | 411 | } |
390 | perror("ioctl"); | 412 | perror("RTC_IRQP_SET ioctl"); |
391 | exit(errno); | 413 | exit(errno); |
392 | } | 414 | } |
393 | 415 | ||
@@ -397,7 +419,7 @@ test_PIE: | |||
397 | /* Enable periodic interrupts */ | 419 | /* Enable periodic interrupts */ |
398 | retval = ioctl(fd, RTC_PIE_ON, 0); | 420 | retval = ioctl(fd, RTC_PIE_ON, 0); |
399 | if (retval == -1) { | 421 | if (retval == -1) { |
400 | perror("ioctl"); | 422 | perror("RTC_PIE_ON ioctl"); |
401 | exit(errno); | 423 | exit(errno); |
402 | } | 424 | } |
403 | 425 | ||
@@ -416,7 +438,7 @@ test_PIE: | |||
416 | /* Disable periodic interrupts */ | 438 | /* Disable periodic interrupts */ |
417 | retval = ioctl(fd, RTC_PIE_OFF, 0); | 439 | retval = ioctl(fd, RTC_PIE_OFF, 0); |
418 | if (retval == -1) { | 440 | if (retval == -1) { |
419 | perror("ioctl"); | 441 | perror("RTC_PIE_OFF ioctl"); |
420 | exit(errno); | 442 | exit(errno); |
421 | } | 443 | } |
422 | } | 444 | } |
diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index 61613166981b..452c0f152304 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt | |||
@@ -64,11 +64,6 @@ On all - write a character to /proc/sysrq-trigger. e.g.: | |||
64 | 64 | ||
65 | * What are the 'command' keys? | 65 | * What are the 'command' keys? |
66 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 66 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
67 | 'r' - Turns off keyboard raw mode and sets it to XLATE. | ||
68 | |||
69 | 'k' - Secure Access Key (SAK) Kills all programs on the current virtual | ||
70 | console. NOTE: See important comments below in SAK section. | ||
71 | |||
72 | 'b' - Will immediately reboot the system without syncing or unmounting | 67 | 'b' - Will immediately reboot the system without syncing or unmounting |
73 | your disks. | 68 | your disks. |
74 | 69 | ||
@@ -76,21 +71,37 @@ On all - write a character to /proc/sysrq-trigger. e.g.: | |||
76 | 71 | ||
77 | 'd' - Shows all locks that are held. | 72 | 'd' - Shows all locks that are held. |
78 | 73 | ||
79 | 'o' - Will shut your system off (if configured and supported). | 74 | 'e' - Send a SIGTERM to all processes, except for init. |
80 | 75 | ||
81 | 's' - Will attempt to sync all mounted filesystems. | 76 | 'f' - Will call oom_kill to kill a memory hog process. |
82 | 77 | ||
83 | 'u' - Will attempt to remount all mounted filesystems read-only. | 78 | 'g' - Used by kgdb on ppc platforms. |
84 | 79 | ||
85 | 'p' - Will dump the current registers and flags to your console. | 80 | 'h' - Will display help (actually any other key than those listed |
81 | above will display help. but 'h' is easy to remember :-) | ||
86 | 82 | ||
87 | 't' - Will dump a list of current tasks and their information to your | 83 | 'i' - Send a SIGKILL to all processes, except for init. |
88 | console. | 84 | |
85 | 'k' - Secure Access Key (SAK) Kills all programs on the current virtual | ||
86 | console. NOTE: See important comments below in SAK section. | ||
89 | 87 | ||
90 | 'm' - Will dump current memory info to your console. | 88 | 'm' - Will dump current memory info to your console. |
91 | 89 | ||
92 | 'n' - Used to make RT tasks nice-able | 90 | 'n' - Used to make RT tasks nice-able |
93 | 91 | ||
92 | 'o' - Will shut your system off (if configured and supported). | ||
93 | |||
94 | 'p' - Will dump the current registers and flags to your console. | ||
95 | |||
96 | 'r' - Turns off keyboard raw mode and sets it to XLATE. | ||
97 | |||
98 | 's' - Will attempt to sync all mounted filesystems. | ||
99 | |||
100 | 't' - Will dump a list of current tasks and their information to your | ||
101 | console. | ||
102 | |||
103 | 'u' - Will attempt to remount all mounted filesystems read-only. | ||
104 | |||
94 | 'v' - Dumps Voyager SMP processor info to your console. | 105 | 'v' - Dumps Voyager SMP processor info to your console. |
95 | 106 | ||
96 | 'w' - Dumps tasks that are in uninterruptable (blocked) state. | 107 | 'w' - Dumps tasks that are in uninterruptable (blocked) state. |
@@ -102,17 +113,6 @@ On all - write a character to /proc/sysrq-trigger. e.g.: | |||
102 | it so that only emergency messages like PANICs or OOPSes would | 113 | it so that only emergency messages like PANICs or OOPSes would |
103 | make it to your console.) | 114 | make it to your console.) |
104 | 115 | ||
105 | 'f' - Will call oom_kill to kill a memory hog process. | ||
106 | |||
107 | 'e' - Send a SIGTERM to all processes, except for init. | ||
108 | |||
109 | 'g' - Used by kgdb on ppc platforms. | ||
110 | |||
111 | 'i' - Send a SIGKILL to all processes, except for init. | ||
112 | |||
113 | 'h' - Will display help (actually any other key than those listed | ||
114 | above will display help. but 'h' is easy to remember :-) | ||
115 | |||
116 | * Okay, so what can I use them for? | 116 | * Okay, so what can I use them for? |
117 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 117 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
118 | Well, un'R'aw is very handy when your X server or a svgalib program crashes. | 118 | Well, un'R'aw is very handy when your X server or a svgalib program crashes. |