diff options
Diffstat (limited to 'Documentation')
200 files changed, 8242 insertions, 3302 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 1977fab38656..6de71308a906 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -361,8 +361,6 @@ telephony/ | |||
361 | - directory with info on telephony (e.g. voice over IP) support. | 361 | - directory with info on telephony (e.g. voice over IP) support. |
362 | time_interpolators.txt | 362 | time_interpolators.txt |
363 | - info on time interpolators. | 363 | - info on time interpolators. |
364 | tipar.txt | ||
365 | - information about Parallel link cable for Texas Instruments handhelds. | ||
366 | tty.txt | 364 | tty.txt |
367 | - guide to the locking policies of the tty layer. | 365 | - guide to the locking policies of the tty layer. |
368 | uml/ | 366 | uml/ |
diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index 4bd9ea539129..44f52a4f5903 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block | |||
@@ -26,3 +26,37 @@ Description: | |||
26 | I/O statistics of partition <part>. The format is the | 26 | I/O statistics of partition <part>. The format is the |
27 | same as the above-written /sys/block/<disk>/stat | 27 | same as the above-written /sys/block/<disk>/stat |
28 | format. | 28 | format. |
29 | |||
30 | |||
31 | What: /sys/block/<disk>/integrity/format | ||
32 | Date: June 2008 | ||
33 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
34 | Description: | ||
35 | Metadata format for integrity capable block device. | ||
36 | E.g. T10-DIF-TYPE1-CRC. | ||
37 | |||
38 | |||
39 | What: /sys/block/<disk>/integrity/read_verify | ||
40 | Date: June 2008 | ||
41 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
42 | Description: | ||
43 | Indicates whether the block layer should verify the | ||
44 | integrity of read requests serviced by devices that | ||
45 | support sending integrity metadata. | ||
46 | |||
47 | |||
48 | What: /sys/block/<disk>/integrity/tag_size | ||
49 | Date: June 2008 | ||
50 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
51 | Description: | ||
52 | Number of bytes of integrity tag space available per | ||
53 | 512 bytes of data. | ||
54 | |||
55 | |||
56 | What: /sys/block/<disk>/integrity/write_generate | ||
57 | Date: June 2008 | ||
58 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
59 | Description: | ||
60 | Indicates whether the block layer should automatically | ||
61 | generate checksums for write requests bound for | ||
62 | devices that support receiving integrity metadata. | ||
diff --git a/Documentation/ABI/testing/sysfs-bus-css b/Documentation/ABI/testing/sysfs-bus-css new file mode 100644 index 000000000000..b585ec258a08 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-css | |||
@@ -0,0 +1,35 @@ | |||
1 | What: /sys/bus/css/devices/.../type | ||
2 | Date: March 2008 | ||
3 | Contact: Cornelia Huck <cornelia.huck@de.ibm.com> | ||
4 | linux-s390@vger.kernel.org | ||
5 | Description: Contains the subchannel type, as reported by the hardware. | ||
6 | This attribute is present for all subchannel types. | ||
7 | |||
8 | What: /sys/bus/css/devices/.../modalias | ||
9 | Date: March 2008 | ||
10 | Contact: Cornelia Huck <cornelia.huck@de.ibm.com> | ||
11 | linux-s390@vger.kernel.org | ||
12 | Description: Contains the module alias as reported with uevents. | ||
13 | It is of the format css:t<type> and present for all | ||
14 | subchannel types. | ||
15 | |||
16 | What: /sys/bus/css/drivers/io_subchannel/.../chpids | ||
17 | Date: December 2002 | ||
18 | Contact: Cornelia Huck <cornelia.huck@de.ibm.com> | ||
19 | linux-s390@vger.kernel.org | ||
20 | Description: Contains the ids of the channel paths used by this | ||
21 | subchannel, as reported by the channel subsystem | ||
22 | during subchannel recognition. | ||
23 | Note: This is an I/O-subchannel specific attribute. | ||
24 | Users: s390-tools, HAL | ||
25 | |||
26 | What: /sys/bus/css/drivers/io_subchannel/.../pimpampom | ||
27 | Date: December 2002 | ||
28 | Contact: Cornelia Huck <cornelia.huck@de.ibm.com> | ||
29 | linux-s390@vger.kernel.org | ||
30 | Description: Contains the PIM/PAM/POM values, as reported by the | ||
31 | channel subsystem when last queried by the common I/O | ||
32 | layer (this implies that this attribute is not neccessarily | ||
33 | in sync with the values current in the channel subsystem). | ||
34 | Note: This is an I/O-subchannel specific attribute. | ||
35 | Users: s390-tools, HAL | ||
diff --git a/Documentation/ABI/testing/sysfs-class-regulator b/Documentation/ABI/testing/sysfs-class-regulator new file mode 100644 index 000000000000..79a4a75b2d2c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-regulator | |||
@@ -0,0 +1,315 @@ | |||
1 | What: /sys/class/regulator/.../state | ||
2 | Date: April 2008 | ||
3 | KernelVersion: 2.6.26 | ||
4 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
5 | Description: | ||
6 | Each regulator directory will contain a field called | ||
7 | state. This holds the regulator output state. | ||
8 | |||
9 | This will be one of the following strings: | ||
10 | |||
11 | 'enabled' | ||
12 | 'disabled' | ||
13 | 'unknown' | ||
14 | |||
15 | 'enabled' means the regulator output is ON and is supplying | ||
16 | power to the system. | ||
17 | |||
18 | 'disabled' means the regulator output is OFF and is not | ||
19 | supplying power to the system.. | ||
20 | |||
21 | 'unknown' means software cannot determine the state. | ||
22 | |||
23 | NOTE: this field can be used in conjunction with microvolts | ||
24 | and microamps to determine regulator output levels. | ||
25 | |||
26 | |||
27 | What: /sys/class/regulator/.../type | ||
28 | Date: April 2008 | ||
29 | KernelVersion: 2.6.26 | ||
30 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
31 | Description: | ||
32 | Each regulator directory will contain a field called | ||
33 | type. This holds the regulator type. | ||
34 | |||
35 | This will be one of the following strings: | ||
36 | |||
37 | 'voltage' | ||
38 | 'current' | ||
39 | 'unknown' | ||
40 | |||
41 | 'voltage' means the regulator output voltage can be controlled | ||
42 | by software. | ||
43 | |||
44 | 'current' means the regulator output current limit can be | ||
45 | controlled by software. | ||
46 | |||
47 | 'unknown' means software cannot control either voltage or | ||
48 | current limit. | ||
49 | |||
50 | |||
51 | What: /sys/class/regulator/.../microvolts | ||
52 | Date: April 2008 | ||
53 | KernelVersion: 2.6.26 | ||
54 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
55 | Description: | ||
56 | Each regulator directory will contain a field called | ||
57 | microvolts. This holds the regulator output voltage setting | ||
58 | measured in microvolts (i.e. E-6 Volts). | ||
59 | |||
60 | NOTE: This value should not be used to determine the regulator | ||
61 | output voltage level as this value is the same regardless of | ||
62 | whether the regulator is enabled or disabled. | ||
63 | |||
64 | |||
65 | What: /sys/class/regulator/.../microamps | ||
66 | Date: April 2008 | ||
67 | KernelVersion: 2.6.26 | ||
68 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
69 | Description: | ||
70 | Each regulator directory will contain a field called | ||
71 | microamps. This holds the regulator output current limit | ||
72 | setting measured in microamps (i.e. E-6 Amps). | ||
73 | |||
74 | NOTE: This value should not be used to determine the regulator | ||
75 | output current level as this value is the same regardless of | ||
76 | whether the regulator is enabled or disabled. | ||
77 | |||
78 | |||
79 | What: /sys/class/regulator/.../opmode | ||
80 | Date: April 2008 | ||
81 | KernelVersion: 2.6.26 | ||
82 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
83 | Description: | ||
84 | Each regulator directory will contain a field called | ||
85 | opmode. This holds the regulator operating mode setting. | ||
86 | |||
87 | The opmode value can be one of the following strings: | ||
88 | |||
89 | 'fast' | ||
90 | 'normal' | ||
91 | 'idle' | ||
92 | 'standby' | ||
93 | 'unknown' | ||
94 | |||
95 | The modes are described in include/linux/regulator/regulator.h | ||
96 | |||
97 | NOTE: This value should not be used to determine the regulator | ||
98 | output operating mode as this value is the same regardless of | ||
99 | whether the regulator is enabled or disabled. | ||
100 | |||
101 | |||
102 | What: /sys/class/regulator/.../min_microvolts | ||
103 | Date: April 2008 | ||
104 | KernelVersion: 2.6.26 | ||
105 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
106 | Description: | ||
107 | Each regulator directory will contain a field called | ||
108 | min_microvolts. This holds the minimum safe working regulator | ||
109 | output voltage setting for this domain measured in microvolts. | ||
110 | |||
111 | NOTE: this will return the string 'constraint not defined' if | ||
112 | the power domain has no min microvolts constraint defined by | ||
113 | platform code. | ||
114 | |||
115 | |||
116 | What: /sys/class/regulator/.../max_microvolts | ||
117 | Date: April 2008 | ||
118 | KernelVersion: 2.6.26 | ||
119 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
120 | Description: | ||
121 | Each regulator directory will contain a field called | ||
122 | max_microvolts. This holds the maximum safe working regulator | ||
123 | output voltage setting for this domain measured in microvolts. | ||
124 | |||
125 | NOTE: this will return the string 'constraint not defined' if | ||
126 | the power domain has no max microvolts constraint defined by | ||
127 | platform code. | ||
128 | |||
129 | |||
130 | What: /sys/class/regulator/.../min_microamps | ||
131 | Date: April 2008 | ||
132 | KernelVersion: 2.6.26 | ||
133 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
134 | Description: | ||
135 | Each regulator directory will contain a field called | ||
136 | min_microamps. This holds the minimum safe working regulator | ||
137 | output current limit setting for this domain measured in | ||
138 | microamps. | ||
139 | |||
140 | NOTE: this will return the string 'constraint not defined' if | ||
141 | the power domain has no min microamps constraint defined by | ||
142 | platform code. | ||
143 | |||
144 | |||
145 | What: /sys/class/regulator/.../max_microamps | ||
146 | Date: April 2008 | ||
147 | KernelVersion: 2.6.26 | ||
148 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
149 | Description: | ||
150 | Each regulator directory will contain a field called | ||
151 | max_microamps. This holds the maximum safe working regulator | ||
152 | output current limit setting for this domain measured in | ||
153 | microamps. | ||
154 | |||
155 | NOTE: this will return the string 'constraint not defined' if | ||
156 | the power domain has no max microamps constraint defined by | ||
157 | platform code. | ||
158 | |||
159 | |||
160 | What: /sys/class/regulator/.../num_users | ||
161 | Date: April 2008 | ||
162 | KernelVersion: 2.6.26 | ||
163 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
164 | Description: | ||
165 | Each regulator directory will contain a field called | ||
166 | num_users. This holds the number of consumer devices that | ||
167 | have called regulator_enable() on this regulator. | ||
168 | |||
169 | |||
170 | What: /sys/class/regulator/.../requested_microamps | ||
171 | Date: April 2008 | ||
172 | KernelVersion: 2.6.26 | ||
173 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
174 | Description: | ||
175 | Each regulator directory will contain a field called | ||
176 | requested_microamps. This holds the total requested load | ||
177 | current in microamps for this regulator from all its consumer | ||
178 | devices. | ||
179 | |||
180 | |||
181 | What: /sys/class/regulator/.../parent | ||
182 | Date: April 2008 | ||
183 | KernelVersion: 2.6.26 | ||
184 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
185 | Description: | ||
186 | Some regulator directories will contain a link called parent. | ||
187 | This points to the parent or supply regulator if one exists. | ||
188 | |||
189 | What: /sys/class/regulator/.../suspend_mem_microvolts | ||
190 | Date: May 2008 | ||
191 | KernelVersion: 2.6.26 | ||
192 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
193 | Description: | ||
194 | Each regulator directory will contain a field called | ||
195 | suspend_mem_microvolts. This holds the regulator output | ||
196 | voltage setting for this domain measured in microvolts when | ||
197 | the system is suspended to memory. | ||
198 | |||
199 | NOTE: this will return the string 'not defined' if | ||
200 | the power domain has no suspend to memory voltage defined by | ||
201 | platform code. | ||
202 | |||
203 | What: /sys/class/regulator/.../suspend_disk_microvolts | ||
204 | Date: May 2008 | ||
205 | KernelVersion: 2.6.26 | ||
206 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
207 | Description: | ||
208 | Each regulator directory will contain a field called | ||
209 | suspend_disk_microvolts. This holds the regulator output | ||
210 | voltage setting for this domain measured in microvolts when | ||
211 | the system is suspended to disk. | ||
212 | |||
213 | NOTE: this will return the string 'not defined' if | ||
214 | the power domain has no suspend to disk voltage defined by | ||
215 | platform code. | ||
216 | |||
217 | What: /sys/class/regulator/.../suspend_standby_microvolts | ||
218 | Date: May 2008 | ||
219 | KernelVersion: 2.6.26 | ||
220 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
221 | Description: | ||
222 | Each regulator directory will contain a field called | ||
223 | suspend_standby_microvolts. This holds the regulator output | ||
224 | voltage setting for this domain measured in microvolts when | ||
225 | the system is suspended to standby. | ||
226 | |||
227 | NOTE: this will return the string 'not defined' if | ||
228 | the power domain has no suspend to standby voltage defined by | ||
229 | platform code. | ||
230 | |||
231 | What: /sys/class/regulator/.../suspend_mem_mode | ||
232 | Date: May 2008 | ||
233 | KernelVersion: 2.6.26 | ||
234 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
235 | Description: | ||
236 | Each regulator directory will contain a field called | ||
237 | suspend_mem_mode. This holds the regulator operating mode | ||
238 | setting for this domain when the system is suspended to | ||
239 | memory. | ||
240 | |||
241 | NOTE: this will return the string 'not defined' if | ||
242 | the power domain has no suspend to memory mode defined by | ||
243 | platform code. | ||
244 | |||
245 | What: /sys/class/regulator/.../suspend_disk_mode | ||
246 | Date: May 2008 | ||
247 | KernelVersion: 2.6.26 | ||
248 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
249 | Description: | ||
250 | Each regulator directory will contain a field called | ||
251 | suspend_disk_mode. This holds the regulator operating mode | ||
252 | setting for this domain when the system is suspended to disk. | ||
253 | |||
254 | NOTE: this will return the string 'not defined' if | ||
255 | the power domain has no suspend to disk mode defined by | ||
256 | platform code. | ||
257 | |||
258 | What: /sys/class/regulator/.../suspend_standby_mode | ||
259 | Date: May 2008 | ||
260 | KernelVersion: 2.6.26 | ||
261 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
262 | Description: | ||
263 | Each regulator directory will contain a field called | ||
264 | suspend_standby_mode. This holds the regulator operating mode | ||
265 | setting for this domain when the system is suspended to | ||
266 | standby. | ||
267 | |||
268 | NOTE: this will return the string 'not defined' if | ||
269 | the power domain has no suspend to standby mode defined by | ||
270 | platform code. | ||
271 | |||
272 | What: /sys/class/regulator/.../suspend_mem_state | ||
273 | Date: May 2008 | ||
274 | KernelVersion: 2.6.26 | ||
275 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
276 | Description: | ||
277 | Each regulator directory will contain a field called | ||
278 | suspend_mem_state. This holds the regulator operating state | ||
279 | when suspended to memory. | ||
280 | |||
281 | This will be one of the following strings: | ||
282 | |||
283 | 'enabled' | ||
284 | 'disabled' | ||
285 | 'not defined' | ||
286 | |||
287 | What: /sys/class/regulator/.../suspend_disk_state | ||
288 | Date: May 2008 | ||
289 | KernelVersion: 2.6.26 | ||
290 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
291 | Description: | ||
292 | Each regulator directory will contain a field called | ||
293 | suspend_disk_state. This holds the regulator operating state | ||
294 | when suspended to disk. | ||
295 | |||
296 | This will be one of the following strings: | ||
297 | |||
298 | 'enabled' | ||
299 | 'disabled' | ||
300 | 'not defined' | ||
301 | |||
302 | What: /sys/class/regulator/.../suspend_standby_state | ||
303 | Date: May 2008 | ||
304 | KernelVersion: 2.6.26 | ||
305 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
306 | Description: | ||
307 | Each regulator directory will contain a field called | ||
308 | suspend_standby_state. This holds the regulator operating | ||
309 | state when suspended to standby. | ||
310 | |||
311 | This will be one of the following strings: | ||
312 | |||
313 | 'enabled' | ||
314 | 'disabled' | ||
315 | 'not defined' | ||
diff --git a/Documentation/ABI/testing/sysfs-dev b/Documentation/ABI/testing/sysfs-dev new file mode 100644 index 000000000000..a9f2b8b0530f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-dev | |||
@@ -0,0 +1,20 @@ | |||
1 | What: /sys/dev | ||
2 | Date: April 2008 | ||
3 | KernelVersion: 2.6.26 | ||
4 | Contact: Dan Williams <dan.j.williams@intel.com> | ||
5 | Description: The /sys/dev tree provides a method to look up the sysfs | ||
6 | path for a device using the information returned from | ||
7 | stat(2). There are two directories, 'block' and 'char', | ||
8 | beneath /sys/dev containing symbolic links with names of | ||
9 | the form "<major>:<minor>". These links point to the | ||
10 | corresponding sysfs path for the given device. | ||
11 | |||
12 | Example: | ||
13 | $ readlink /sys/dev/block/8:32 | ||
14 | ../../block/sdc | ||
15 | |||
16 | Entries in /sys/dev/char and /sys/dev/block will be | ||
17 | dynamically created and destroyed as devices enter and | ||
18 | leave the system. | ||
19 | |||
20 | Users: mdadm <linux-raid@vger.kernel.org> | ||
diff --git a/Documentation/ABI/testing/sysfs-devices-memory b/Documentation/ABI/testing/sysfs-devices-memory new file mode 100644 index 000000000000..7a16fe1e2270 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-memory | |||
@@ -0,0 +1,24 @@ | |||
1 | What: /sys/devices/system/memory | ||
2 | Date: June 2008 | ||
3 | Contact: Badari Pulavarty <pbadari@us.ibm.com> | ||
4 | Description: | ||
5 | The /sys/devices/system/memory contains a snapshot of the | ||
6 | internal state of the kernel memory blocks. Files could be | ||
7 | added or removed dynamically to represent hot-add/remove | ||
8 | operations. | ||
9 | |||
10 | Users: hotplug memory add/remove tools | ||
11 | https://w3.opensource.ibm.com/projects/powerpc-utils/ | ||
12 | |||
13 | What: /sys/devices/system/memory/memoryX/removable | ||
14 | Date: June 2008 | ||
15 | Contact: Badari Pulavarty <pbadari@us.ibm.com> | ||
16 | Description: | ||
17 | The file /sys/devices/system/memory/memoryX/removable | ||
18 | indicates whether this memory block is removable or not. | ||
19 | This is useful for a user-level agent to determine | ||
20 | identify removable sections of the memory before attempting | ||
21 | potentially expensive hot-remove memory operation | ||
22 | |||
23 | Users: hotplug memory remove tools | ||
24 | https://w3.opensource.ibm.com/projects/powerpc-utils/ | ||
diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi index 9470ed9afcc0..f27be7d1a49f 100644 --- a/Documentation/ABI/testing/sysfs-firmware-acpi +++ b/Documentation/ABI/testing/sysfs-firmware-acpi | |||
@@ -29,46 +29,46 @@ Description: | |||
29 | 29 | ||
30 | $ cd /sys/firmware/acpi/interrupts | 30 | $ cd /sys/firmware/acpi/interrupts |
31 | $ grep . * | 31 | $ grep . * |
32 | error:0 | 32 | error: 0 |
33 | ff_gbl_lock:0 | 33 | ff_gbl_lock: 0 enable |
34 | ff_pmtimer:0 | 34 | ff_pmtimer: 0 invalid |
35 | ff_pwr_btn:0 | 35 | ff_pwr_btn: 0 enable |
36 | ff_rt_clk:0 | 36 | ff_rt_clk: 2 disable |
37 | ff_slp_btn:0 | 37 | ff_slp_btn: 0 invalid |
38 | gpe00:0 | 38 | gpe00: 0 invalid |
39 | gpe01:0 | 39 | gpe01: 0 enable |
40 | gpe02:0 | 40 | gpe02: 108 enable |
41 | gpe03:0 | 41 | gpe03: 0 invalid |
42 | gpe04:0 | 42 | gpe04: 0 invalid |
43 | gpe05:0 | 43 | gpe05: 0 invalid |
44 | gpe06:0 | 44 | gpe06: 0 enable |
45 | gpe07:0 | 45 | gpe07: 0 enable |
46 | gpe08:0 | 46 | gpe08: 0 invalid |
47 | gpe09:174 | 47 | gpe09: 0 invalid |
48 | gpe0A:0 | 48 | gpe0A: 0 invalid |
49 | gpe0B:0 | 49 | gpe0B: 0 invalid |
50 | gpe0C:0 | 50 | gpe0C: 0 invalid |
51 | gpe0D:0 | 51 | gpe0D: 0 invalid |
52 | gpe0E:0 | 52 | gpe0E: 0 invalid |
53 | gpe0F:0 | 53 | gpe0F: 0 invalid |
54 | gpe10:0 | 54 | gpe10: 0 invalid |
55 | gpe11:60 | 55 | gpe11: 0 invalid |
56 | gpe12:0 | 56 | gpe12: 0 invalid |
57 | gpe13:0 | 57 | gpe13: 0 invalid |
58 | gpe14:0 | 58 | gpe14: 0 invalid |
59 | gpe15:0 | 59 | gpe15: 0 invalid |
60 | gpe16:0 | 60 | gpe16: 0 invalid |
61 | gpe17:0 | 61 | gpe17: 1084 enable |
62 | gpe18:0 | 62 | gpe18: 0 enable |
63 | gpe19:7 | 63 | gpe19: 0 invalid |
64 | gpe1A:0 | 64 | gpe1A: 0 invalid |
65 | gpe1B:0 | 65 | gpe1B: 0 invalid |
66 | gpe1C:0 | 66 | gpe1C: 0 invalid |
67 | gpe1D:0 | 67 | gpe1D: 0 invalid |
68 | gpe1E:0 | 68 | gpe1E: 0 invalid |
69 | gpe1F:0 | 69 | gpe1F: 0 invalid |
70 | gpe_all:241 | 70 | gpe_all: 1192 |
71 | sci:241 | 71 | sci: 1194 |
72 | 72 | ||
73 | sci - The total number of times the ACPI SCI | 73 | sci - The total number of times the ACPI SCI |
74 | has claimed an interrupt. | 74 | has claimed an interrupt. |
@@ -89,6 +89,13 @@ Description: | |||
89 | 89 | ||
90 | error - an interrupt that can't be accounted for above. | 90 | error - an interrupt that can't be accounted for above. |
91 | 91 | ||
92 | invalid: it's either a wakeup GPE or a GPE/Fixed Event that | ||
93 | doesn't have an event handler. | ||
94 | |||
95 | disable: the GPE/Fixed Event is valid but disabled. | ||
96 | |||
97 | enable: the GPE/Fixed Event is valid and enabled. | ||
98 | |||
92 | Root has permission to clear any of these counters. Eg. | 99 | Root has permission to clear any of these counters. Eg. |
93 | # echo 0 > gpe11 | 100 | # echo 0 > gpe11 |
94 | 101 | ||
@@ -97,3 +104,43 @@ Description: | |||
97 | 104 | ||
98 | None of these counters has an effect on the function | 105 | None of these counters has an effect on the function |
99 | of the system, they are simply statistics. | 106 | of the system, they are simply statistics. |
107 | |||
108 | Besides this, user can also write specific strings to these files | ||
109 | to enable/disable/clear ACPI interrupts in user space, which can be | ||
110 | used to debug some ACPI interrupt storm issues. | ||
111 | |||
112 | Note that only writting to VALID GPE/Fixed Event is allowed, | ||
113 | i.e. user can only change the status of runtime GPE and | ||
114 | Fixed Event with event handler installed. | ||
115 | |||
116 | Let's take power button fixed event for example, please kill acpid | ||
117 | and other user space applications so that the machine won't shutdown | ||
118 | when pressing the power button. | ||
119 | # cat ff_pwr_btn | ||
120 | 0 | ||
121 | # press the power button for 3 times; | ||
122 | # cat ff_pwr_btn | ||
123 | 3 | ||
124 | # echo disable > ff_pwr_btn | ||
125 | # cat ff_pwr_btn | ||
126 | disable | ||
127 | # press the power button for 3 times; | ||
128 | # cat ff_pwr_btn | ||
129 | disable | ||
130 | # echo enable > ff_pwr_btn | ||
131 | # cat ff_pwr_btn | ||
132 | 4 | ||
133 | /* | ||
134 | * this is because the status bit is set even if the enable bit is cleared, | ||
135 | * and it triggers an ACPI fixed event when the enable bit is set again | ||
136 | */ | ||
137 | # press the power button for 3 times; | ||
138 | # cat ff_pwr_btn | ||
139 | 7 | ||
140 | # echo disable > ff_pwr_btn | ||
141 | # press the power button for 3 times; | ||
142 | # echo clear > ff_pwr_btn /* clear the status bit */ | ||
143 | # echo disable > ff_pwr_btn | ||
144 | # cat ff_pwr_btn | ||
145 | 7 | ||
146 | |||
diff --git a/Documentation/ABI/testing/sysfs-firmware-memmap b/Documentation/ABI/testing/sysfs-firmware-memmap new file mode 100644 index 000000000000..0d99ee6ae02e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-memmap | |||
@@ -0,0 +1,71 @@ | |||
1 | What: /sys/firmware/memmap/ | ||
2 | Date: June 2008 | ||
3 | Contact: Bernhard Walle <bwalle@suse.de> | ||
4 | Description: | ||
5 | On all platforms, the firmware provides a memory map which the | ||
6 | kernel reads. The resources from that memory map are registered | ||
7 | in the kernel resource tree and exposed to userspace via | ||
8 | /proc/iomem (together with other resources). | ||
9 | |||
10 | However, on most architectures that firmware-provided memory | ||
11 | map is modified afterwards by the kernel itself, either because | ||
12 | the kernel merges that memory map with other information or | ||
13 | just because the user overwrites that memory map via command | ||
14 | line. | ||
15 | |||
16 | kexec needs the raw firmware-provided memory map to setup the | ||
17 | parameter segment of the kernel that should be booted with | ||
18 | kexec. Also, the raw memory map is useful for debugging. For | ||
19 | that reason, /sys/firmware/memmap is an interface that provides | ||
20 | the raw memory map to userspace. | ||
21 | |||
22 | The structure is as follows: Under /sys/firmware/memmap there | ||
23 | are subdirectories with the number of the entry as their name: | ||
24 | |||
25 | /sys/firmware/memmap/0 | ||
26 | /sys/firmware/memmap/1 | ||
27 | /sys/firmware/memmap/2 | ||
28 | /sys/firmware/memmap/3 | ||
29 | ... | ||
30 | |||
31 | The maximum depends on the number of memory map entries provided | ||
32 | by the firmware. The order is just the order that the firmware | ||
33 | provides. | ||
34 | |||
35 | Each directory contains three files: | ||
36 | |||
37 | start : The start address (as hexadecimal number with the | ||
38 | '0x' prefix). | ||
39 | end : The end address, inclusive (regardless whether the | ||
40 | firmware provides inclusive or exclusive ranges). | ||
41 | type : Type of the entry as string. See below for a list of | ||
42 | valid types. | ||
43 | |||
44 | So, for example: | ||
45 | |||
46 | /sys/firmware/memmap/0/start | ||
47 | /sys/firmware/memmap/0/end | ||
48 | /sys/firmware/memmap/0/type | ||
49 | /sys/firmware/memmap/1/start | ||
50 | ... | ||
51 | |||
52 | Currently following types exist: | ||
53 | |||
54 | - System RAM | ||
55 | - ACPI Tables | ||
56 | - ACPI Non-volatile Storage | ||
57 | - reserved | ||
58 | |||
59 | Following shell snippet can be used to display that memory | ||
60 | map in a human-readable format: | ||
61 | |||
62 | -------------------- 8< ---------------------------------------- | ||
63 | #!/bin/bash | ||
64 | cd /sys/firmware/memmap | ||
65 | for dir in * ; do | ||
66 | start=$(cat $dir/start) | ||
67 | end=$(cat $dir/end) | ||
68 | type=$(cat $dir/type) | ||
69 | printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type" | ||
70 | done | ||
71 | -------------------- >8 ---------------------------------------- | ||
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm b/Documentation/ABI/testing/sysfs-kernel-mm new file mode 100644 index 000000000000..190d523ac159 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-mm | |||
@@ -0,0 +1,6 @@ | |||
1 | What: /sys/kernel/mm | ||
2 | Date: July 2008 | ||
3 | Contact: Nishanth Aravamudan <nacc@us.ibm.com>, VM maintainers | ||
4 | Description: | ||
5 | /sys/kernel/mm/ should contain any and all VM | ||
6 | related information in /sys/kernel/. | ||
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-hugepages b/Documentation/ABI/testing/sysfs-kernel-mm-hugepages new file mode 100644 index 000000000000..e21c00571cf4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-mm-hugepages | |||
@@ -0,0 +1,15 @@ | |||
1 | What: /sys/kernel/mm/hugepages/ | ||
2 | Date: June 2008 | ||
3 | Contact: Nishanth Aravamudan <nacc@us.ibm.com>, hugetlb maintainers | ||
4 | Description: | ||
5 | /sys/kernel/mm/hugepages/ contains a number of subdirectories | ||
6 | of the form hugepages-<size>kB, where <size> is the page size | ||
7 | of the hugepages supported by the kernel/CPU combination. | ||
8 | |||
9 | Under these directories are a number of files: | ||
10 | nr_hugepages | ||
11 | nr_overcommit_hugepages | ||
12 | free_hugepages | ||
13 | surplus_hugepages | ||
14 | resv_hugepages | ||
15 | See Documentation/vm/hugetlbpage.txt for details. | ||
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 6caa14615578..1875e502f872 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle | |||
@@ -474,25 +474,29 @@ make a good program). | |||
474 | So, you can either get rid of GNU emacs, or change it to use saner | 474 | So, you can either get rid of GNU emacs, or change it to use saner |
475 | values. To do the latter, you can stick the following in your .emacs file: | 475 | values. To do the latter, you can stick the following in your .emacs file: |
476 | 476 | ||
477 | (defun linux-c-mode () | 477 | (defun c-lineup-arglist-tabs-only (ignored) |
478 | "C mode with adjusted defaults for use with the Linux kernel." | 478 | "Line up argument lists by tabs, not spaces" |
479 | (interactive) | 479 | (let* ((anchor (c-langelem-pos c-syntactic-element)) |
480 | (c-mode) | 480 | (column (c-langelem-2nd-pos c-syntactic-element)) |
481 | (c-set-style "K&R") | 481 | (offset (- (1+ column) anchor)) |
482 | (setq tab-width 8) | 482 | (steps (floor offset c-basic-offset))) |
483 | (setq indent-tabs-mode t) | 483 | (* (max steps 1) |
484 | (setq c-basic-offset 8)) | 484 | c-basic-offset))) |
485 | 485 | ||
486 | This will define the M-x linux-c-mode command. When hacking on a | 486 | (add-hook 'c-mode-hook |
487 | module, if you put the string -*- linux-c -*- somewhere on the first | 487 | (lambda () |
488 | two lines, this mode will be automatically invoked. Also, you may want | 488 | (let ((filename (buffer-file-name))) |
489 | to add | 489 | ;; Enable kernel mode for the appropriate files |
490 | 490 | (when (and filename | |
491 | (setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode) | 491 | (string-match "~/src/linux-trees" filename)) |
492 | auto-mode-alist)) | 492 | (setq indent-tabs-mode t) |
493 | 493 | (c-set-style "linux") | |
494 | to your .emacs file if you want to have linux-c-mode switched on | 494 | (c-set-offset 'arglist-cont-nonempty |
495 | automagically when you edit source files under /usr/src/linux. | 495 | '(c-lineup-gcc-asm-reg |
496 | c-lineup-arglist-tabs-only)))))) | ||
497 | |||
498 | This will make emacs go better with the kernel coding style for C | ||
499 | files below ~/src/linux-trees. | ||
496 | 500 | ||
497 | But even if you fail in getting emacs to do sane formatting, not | 501 | But even if you fail in getting emacs to do sane formatting, not |
498 | everything is lost: use "indent". | 502 | everything is lost: use "indent". |
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 80d150458c80..d8b63d164e41 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt | |||
@@ -298,10 +298,10 @@ recommended that you never use these unless you really know what the | |||
298 | cache width is. | 298 | cache width is. |
299 | 299 | ||
300 | int | 300 | int |
301 | dma_mapping_error(dma_addr_t dma_addr) | 301 | dma_mapping_error(struct device *dev, dma_addr_t dma_addr) |
302 | 302 | ||
303 | int | 303 | int |
304 | pci_dma_mapping_error(dma_addr_t dma_addr) | 304 | pci_dma_mapping_error(struct pci_dev *hwdev, dma_addr_t dma_addr) |
305 | 305 | ||
306 | In some circumstances dma_map_single and dma_map_page will fail to create | 306 | In some circumstances dma_map_single and dma_map_page will fail to create |
307 | a mapping. A driver can check for these errors by testing the returned | 307 | a mapping. A driver can check for these errors by testing the returned |
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt index 6d772f84b477..b768cc0e402b 100644 --- a/Documentation/DMA-attributes.txt +++ b/Documentation/DMA-attributes.txt | |||
@@ -22,3 +22,12 @@ ready and available in memory. The DMA of the "completion indication" | |||
22 | could race with data DMA. Mapping the memory used for completion | 22 | could race with data DMA. Mapping the memory used for completion |
23 | indications with DMA_ATTR_WRITE_BARRIER would prevent the race. | 23 | indications with DMA_ATTR_WRITE_BARRIER would prevent the race. |
24 | 24 | ||
25 | DMA_ATTR_WEAK_ORDERING | ||
26 | ---------------------- | ||
27 | |||
28 | DMA_ATTR_WEAK_ORDERING specifies that reads and writes to the mapping | ||
29 | may be weakly ordered, that is that reads and writes may pass each other. | ||
30 | |||
31 | Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING, | ||
32 | those that do not will simply ignore the attribute and exhibit default | ||
33 | behavior. | ||
diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index 5a8ffa761e09..ea3bc9565e6a 100644 --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl | |||
@@ -524,6 +524,44 @@ These utilities include endpoint autoconfiguration. | |||
524 | <!-- !Edrivers/usb/gadget/epautoconf.c --> | 524 | <!-- !Edrivers/usb/gadget/epautoconf.c --> |
525 | </sect1> | 525 | </sect1> |
526 | 526 | ||
527 | <sect1 id="composite"><title>Composite Device Framework</title> | ||
528 | |||
529 | <para>The core API is sufficient for writing drivers for composite | ||
530 | USB devices (with more than one function in a given configuration), | ||
531 | and also multi-configuration devices (also more than one function, | ||
532 | but not necessarily sharing a given configuration). | ||
533 | There is however an optional framework which makes it easier to | ||
534 | reuse and combine functions. | ||
535 | </para> | ||
536 | |||
537 | <para>Devices using this framework provide a <emphasis>struct | ||
538 | usb_composite_driver</emphasis>, which in turn provides one or | ||
539 | more <emphasis>struct usb_configuration</emphasis> instances. | ||
540 | Each such configuration includes at least one | ||
541 | <emphasis>struct usb_function</emphasis>, which packages a user | ||
542 | visible role such as "network link" or "mass storage device". | ||
543 | Management functions may also exist, such as "Device Firmware | ||
544 | Upgrade". | ||
545 | </para> | ||
546 | |||
547 | !Iinclude/linux/usb/composite.h | ||
548 | !Edrivers/usb/gadget/composite.c | ||
549 | |||
550 | </sect1> | ||
551 | |||
552 | <sect1 id="functions"><title>Composite Device Functions</title> | ||
553 | |||
554 | <para>At this writing, a few of the current gadget drivers have | ||
555 | been converted to this framework. | ||
556 | Near-term plans include converting all of them, except for "gadgetfs". | ||
557 | </para> | ||
558 | |||
559 | !Edrivers/usb/gadget/f_acm.c | ||
560 | !Edrivers/usb/gadget/f_serial.c | ||
561 | |||
562 | </sect1> | ||
563 | |||
564 | |||
527 | </chapter> | 565 | </chapter> |
528 | 566 | ||
529 | <chapter id="controllers"><title>Peripheral Controller Drivers</title> | 567 | <chapter id="controllers"><title>Peripheral Controller Drivers</title> |
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 2510763295d0..084f6ad7b7a0 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl | |||
@@ -219,10 +219,10 @@ | |||
219 | </para> | 219 | </para> |
220 | 220 | ||
221 | <sect1 id="lock-intro"> | 221 | <sect1 id="lock-intro"> |
222 | <title>Three Main Types of Kernel Locks: Spinlocks, Mutexes and Semaphores</title> | 222 | <title>Two Main Types of Kernel Locks: Spinlocks and Mutexes</title> |
223 | 223 | ||
224 | <para> | 224 | <para> |
225 | There are three main types of kernel locks. The fundamental type | 225 | There are two main types of kernel locks. The fundamental type |
226 | is the spinlock | 226 | is the spinlock |
227 | (<filename class="headerfile">include/asm/spinlock.h</filename>), | 227 | (<filename class="headerfile">include/asm/spinlock.h</filename>), |
228 | which is a very simple single-holder lock: if you can't get the | 228 | which is a very simple single-holder lock: if you can't get the |
@@ -240,14 +240,6 @@ | |||
240 | use a spinlock instead. | 240 | use a spinlock instead. |
241 | </para> | 241 | </para> |
242 | <para> | 242 | <para> |
243 | The third type is a semaphore | ||
244 | (<filename class="headerfile">include/linux/semaphore.h</filename>): it | ||
245 | can have more than one holder at any time (the number decided at | ||
246 | initialization time), although it is most commonly used as a | ||
247 | single-holder lock (a mutex). If you can't get a semaphore, your | ||
248 | task will be suspended and later on woken up - just like for mutexes. | ||
249 | </para> | ||
250 | <para> | ||
251 | Neither type of lock is recursive: see | 243 | Neither type of lock is recursive: see |
252 | <xref linkend="deadlock"/>. | 244 | <xref linkend="deadlock"/>. |
253 | </para> | 245 | </para> |
@@ -278,7 +270,7 @@ | |||
278 | </para> | 270 | </para> |
279 | 271 | ||
280 | <para> | 272 | <para> |
281 | Semaphores still exist, because they are required for | 273 | Mutexes still exist, because they are required for |
282 | synchronization between <firstterm linkend="gloss-usercontext">user | 274 | synchronization between <firstterm linkend="gloss-usercontext">user |
283 | contexts</firstterm>, as we will see below. | 275 | contexts</firstterm>, as we will see below. |
284 | </para> | 276 | </para> |
@@ -289,18 +281,17 @@ | |||
289 | 281 | ||
290 | <para> | 282 | <para> |
291 | If you have a data structure which is only ever accessed from | 283 | If you have a data structure which is only ever accessed from |
292 | user context, then you can use a simple semaphore | 284 | user context, then you can use a simple mutex |
293 | (<filename>linux/linux/semaphore.h</filename>) to protect it. This | 285 | (<filename>include/linux/mutex.h</filename>) to protect it. This |
294 | is the most trivial case: you initialize the semaphore to the number | 286 | is the most trivial case: you initialize the mutex. Then you can |
295 | of resources available (usually 1), and call | 287 | call <function>mutex_lock_interruptible()</function> to grab the mutex, |
296 | <function>down_interruptible()</function> to grab the semaphore, and | 288 | and <function>mutex_unlock()</function> to release it. There is also a |
297 | <function>up()</function> to release it. There is also a | 289 | <function>mutex_lock()</function>, which should be avoided, because it |
298 | <function>down()</function>, which should be avoided, because it | ||
299 | will not return if a signal is received. | 290 | will not return if a signal is received. |
300 | </para> | 291 | </para> |
301 | 292 | ||
302 | <para> | 293 | <para> |
303 | Example: <filename>linux/net/core/netfilter.c</filename> allows | 294 | Example: <filename>net/netfilter/nf_sockopt.c</filename> allows |
304 | registration of new <function>setsockopt()</function> and | 295 | registration of new <function>setsockopt()</function> and |
305 | <function>getsockopt()</function> calls, with | 296 | <function>getsockopt()</function> calls, with |
306 | <function>nf_register_sockopt()</function>. Registration and | 297 | <function>nf_register_sockopt()</function>. Registration and |
@@ -515,7 +506,7 @@ | |||
515 | <listitem> | 506 | <listitem> |
516 | <para> | 507 | <para> |
517 | If you are in a process context (any syscall) and want to | 508 | If you are in a process context (any syscall) and want to |
518 | lock other process out, use a semaphore. You can take a semaphore | 509 | lock other process out, use a mutex. You can take a mutex |
519 | and sleep (<function>copy_from_user*(</function> or | 510 | and sleep (<function>copy_from_user*(</function> or |
520 | <function>kmalloc(x,GFP_KERNEL)</function>). | 511 | <function>kmalloc(x,GFP_KERNEL)</function>). |
521 | </para> | 512 | </para> |
@@ -662,7 +653,7 @@ | |||
662 | <entry>SLBH</entry> | 653 | <entry>SLBH</entry> |
663 | <entry>SLBH</entry> | 654 | <entry>SLBH</entry> |
664 | <entry>SLBH</entry> | 655 | <entry>SLBH</entry> |
665 | <entry>DI</entry> | 656 | <entry>MLI</entry> |
666 | <entry>None</entry> | 657 | <entry>None</entry> |
667 | </row> | 658 | </row> |
668 | 659 | ||
@@ -692,8 +683,8 @@ | |||
692 | <entry>spin_lock_bh</entry> | 683 | <entry>spin_lock_bh</entry> |
693 | </row> | 684 | </row> |
694 | <row> | 685 | <row> |
695 | <entry>DI</entry> | 686 | <entry>MLI</entry> |
696 | <entry>down_interruptible</entry> | 687 | <entry>mutex_lock_interruptible</entry> |
697 | </row> | 688 | </row> |
698 | 689 | ||
699 | </tbody> | 690 | </tbody> |
@@ -1310,7 +1301,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>. | |||
1310 | <para> | 1301 | <para> |
1311 | There is a coding bug where a piece of code tries to grab a | 1302 | There is a coding bug where a piece of code tries to grab a |
1312 | spinlock twice: it will spin forever, waiting for the lock to | 1303 | spinlock twice: it will spin forever, waiting for the lock to |
1313 | be released (spinlocks, rwlocks and semaphores are not | 1304 | be released (spinlocks, rwlocks and mutexes are not |
1314 | recursive in Linux). This is trivial to diagnose: not a | 1305 | recursive in Linux). This is trivial to diagnose: not a |
1315 | stay-up-five-nights-talk-to-fluffy-code-bunnies kind of | 1306 | stay-up-five-nights-talk-to-fluffy-code-bunnies kind of |
1316 | problem. | 1307 | problem. |
@@ -1335,7 +1326,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>. | |||
1335 | 1326 | ||
1336 | <para> | 1327 | <para> |
1337 | This complete lockup is easy to diagnose: on SMP boxes the | 1328 | This complete lockup is easy to diagnose: on SMP boxes the |
1338 | watchdog timer or compiling with <symbol>DEBUG_SPINLOCKS</symbol> set | 1329 | watchdog timer or compiling with <symbol>DEBUG_SPINLOCK</symbol> set |
1339 | (<filename>include/linux/spinlock.h</filename>) will show this up | 1330 | (<filename>include/linux/spinlock.h</filename>) will show this up |
1340 | immediately when it happens. | 1331 | immediately when it happens. |
1341 | </para> | 1332 | </para> |
@@ -1558,7 +1549,7 @@ the amount of locking which needs to be done. | |||
1558 | <title>Read/Write Lock Variants</title> | 1549 | <title>Read/Write Lock Variants</title> |
1559 | 1550 | ||
1560 | <para> | 1551 | <para> |
1561 | Both spinlocks and semaphores have read/write variants: | 1552 | Both spinlocks and mutexes have read/write variants: |
1562 | <type>rwlock_t</type> and <structname>struct rw_semaphore</structname>. | 1553 | <type>rwlock_t</type> and <structname>struct rw_semaphore</structname>. |
1563 | These divide users into two classes: the readers and the writers. If | 1554 | These divide users into two classes: the readers and the writers. If |
1564 | you are only reading the data, you can get a read lock, but to write to | 1555 | you are only reading the data, you can get a read lock, but to write to |
@@ -1681,7 +1672,7 @@ the amount of locking which needs to be done. | |||
1681 | #include <linux/slab.h> | 1672 | #include <linux/slab.h> |
1682 | #include <linux/string.h> | 1673 | #include <linux/string.h> |
1683 | +#include <linux/rcupdate.h> | 1674 | +#include <linux/rcupdate.h> |
1684 | #include <linux/semaphore.h> | 1675 | #include <linux/mutex.h> |
1685 | #include <asm/errno.h> | 1676 | #include <asm/errno.h> |
1686 | 1677 | ||
1687 | struct object | 1678 | struct object |
@@ -1913,7 +1904,7 @@ machines due to caching. | |||
1913 | </listitem> | 1904 | </listitem> |
1914 | <listitem> | 1905 | <listitem> |
1915 | <para> | 1906 | <para> |
1916 | <function> put_user()</function> | 1907 | <function>put_user()</function> |
1917 | </para> | 1908 | </para> |
1918 | </listitem> | 1909 | </listitem> |
1919 | </itemizedlist> | 1910 | </itemizedlist> |
@@ -1927,13 +1918,13 @@ machines due to caching. | |||
1927 | 1918 | ||
1928 | <listitem> | 1919 | <listitem> |
1929 | <para> | 1920 | <para> |
1930 | <function>down_interruptible()</function> and | 1921 | <function>mutex_lock_interruptible()</function> and |
1931 | <function>down()</function> | 1922 | <function>mutex_lock()</function> |
1932 | </para> | 1923 | </para> |
1933 | <para> | 1924 | <para> |
1934 | There is a <function>down_trylock()</function> which can be | 1925 | There is a <function>mutex_trylock()</function> which can be |
1935 | used inside interrupt context, as it will not sleep. | 1926 | used inside interrupt context, as it will not sleep. |
1936 | <function>up()</function> will also never sleep. | 1927 | <function>mutex_unlock()</function> will also never sleep. |
1937 | </para> | 1928 | </para> |
1938 | </listitem> | 1929 | </listitem> |
1939 | </itemizedlist> | 1930 | </itemizedlist> |
@@ -2023,7 +2014,7 @@ machines due to caching. | |||
2023 | <para> | 2014 | <para> |
2024 | Prior to 2.5, or when <symbol>CONFIG_PREEMPT</symbol> is | 2015 | Prior to 2.5, or when <symbol>CONFIG_PREEMPT</symbol> is |
2025 | unset, processes in user context inside the kernel would not | 2016 | unset, processes in user context inside the kernel would not |
2026 | preempt each other (ie. you had that CPU until you have it up, | 2017 | preempt each other (ie. you had that CPU until you gave it up, |
2027 | except for interrupts). With the addition of | 2018 | except for interrupts). With the addition of |
2028 | <symbol>CONFIG_PREEMPT</symbol> in 2.5.4, this changed: when | 2019 | <symbol>CONFIG_PREEMPT</symbol> in 2.5.4, this changed: when |
2029 | in user context, higher priority tasks can "cut in": spinlocks | 2020 | in user context, higher priority tasks can "cut in": spinlocks |
diff --git a/Documentation/DocBook/procfs-guide.tmpl b/Documentation/DocBook/procfs-guide.tmpl index 1fd6a1ec7591..8a5dc6e021ff 100644 --- a/Documentation/DocBook/procfs-guide.tmpl +++ b/Documentation/DocBook/procfs-guide.tmpl | |||
@@ -29,12 +29,12 @@ | |||
29 | 29 | ||
30 | <revhistory> | 30 | <revhistory> |
31 | <revision> | 31 | <revision> |
32 | <revnumber>1.0 </revnumber> | 32 | <revnumber>1.0</revnumber> |
33 | <date>May 30, 2001</date> | 33 | <date>May 30, 2001</date> |
34 | <revremark>Initial revision posted to linux-kernel</revremark> | 34 | <revremark>Initial revision posted to linux-kernel</revremark> |
35 | </revision> | 35 | </revision> |
36 | <revision> | 36 | <revision> |
37 | <revnumber>1.1 </revnumber> | 37 | <revnumber>1.1</revnumber> |
38 | <date>June 3, 2001</date> | 38 | <date>June 3, 2001</date> |
39 | <revremark>Revised after comments from linux-kernel</revremark> | 39 | <revremark>Revised after comments from linux-kernel</revremark> |
40 | </revision> | 40 | </revision> |
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index fdd7f4f887b7..df87d1b93605 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl | |||
@@ -21,6 +21,18 @@ | |||
21 | </affiliation> | 21 | </affiliation> |
22 | </author> | 22 | </author> |
23 | 23 | ||
24 | <copyright> | ||
25 | <year>2006-2008</year> | ||
26 | <holder>Hans-Jürgen Koch.</holder> | ||
27 | </copyright> | ||
28 | |||
29 | <legalnotice> | ||
30 | <para> | ||
31 | This documentation is Free Software licensed under the terms of the | ||
32 | GPL version 2. | ||
33 | </para> | ||
34 | </legalnotice> | ||
35 | |||
24 | <pubdate>2006-12-11</pubdate> | 36 | <pubdate>2006-12-11</pubdate> |
25 | 37 | ||
26 | <abstract> | 38 | <abstract> |
@@ -30,6 +42,12 @@ | |||
30 | 42 | ||
31 | <revhistory> | 43 | <revhistory> |
32 | <revision> | 44 | <revision> |
45 | <revnumber>0.5</revnumber> | ||
46 | <date>2008-05-22</date> | ||
47 | <authorinitials>hjk</authorinitials> | ||
48 | <revremark>Added description of write() function.</revremark> | ||
49 | </revision> | ||
50 | <revision> | ||
33 | <revnumber>0.4</revnumber> | 51 | <revnumber>0.4</revnumber> |
34 | <date>2007-11-26</date> | 52 | <date>2007-11-26</date> |
35 | <authorinitials>hjk</authorinitials> | 53 | <authorinitials>hjk</authorinitials> |
@@ -57,20 +75,9 @@ | |||
57 | </bookinfo> | 75 | </bookinfo> |
58 | 76 | ||
59 | <chapter id="aboutthisdoc"> | 77 | <chapter id="aboutthisdoc"> |
60 | <?dbhtml filename="about.html"?> | 78 | <?dbhtml filename="aboutthis.html"?> |
61 | <title>About this document</title> | 79 | <title>About this document</title> |
62 | 80 | ||
63 | <sect1 id="copyright"> | ||
64 | <?dbhtml filename="copyright.html"?> | ||
65 | <title>Copyright and License</title> | ||
66 | <para> | ||
67 | Copyright (c) 2006 by Hans-Jürgen Koch.</para> | ||
68 | <para> | ||
69 | This documentation is Free Software licensed under the terms of the | ||
70 | GPL version 2. | ||
71 | </para> | ||
72 | </sect1> | ||
73 | |||
74 | <sect1 id="translations"> | 81 | <sect1 id="translations"> |
75 | <?dbhtml filename="translations.html"?> | 82 | <?dbhtml filename="translations.html"?> |
76 | <title>Translations</title> | 83 | <title>Translations</title> |
@@ -189,6 +196,30 @@ interested in translating it, please email me | |||
189 | represents the total interrupt count. You can use this number | 196 | represents the total interrupt count. You can use this number |
190 | to figure out if you missed some interrupts. | 197 | to figure out if you missed some interrupts. |
191 | </para> | 198 | </para> |
199 | <para> | ||
200 | For some hardware that has more than one interrupt source internally, | ||
201 | but not separate IRQ mask and status registers, there might be | ||
202 | situations where userspace cannot determine what the interrupt source | ||
203 | was if the kernel handler disables them by writing to the chip's IRQ | ||
204 | register. In such a case, the kernel has to disable the IRQ completely | ||
205 | to leave the chip's register untouched. Now the userspace part can | ||
206 | determine the cause of the interrupt, but it cannot re-enable | ||
207 | interrupts. Another cornercase is chips where re-enabling interrupts | ||
208 | is a read-modify-write operation to a combined IRQ status/acknowledge | ||
209 | register. This would be racy if a new interrupt occurred | ||
210 | simultaneously. | ||
211 | </para> | ||
212 | <para> | ||
213 | To address these problems, UIO also implements a write() function. It | ||
214 | is normally not used and can be ignored for hardware that has only a | ||
215 | single interrupt source or has separate IRQ mask and status registers. | ||
216 | If you need it, however, a write to <filename>/dev/uioX</filename> | ||
217 | will call the <function>irqcontrol()</function> function implemented | ||
218 | by the driver. You have to write a 32-bit value that is usually either | ||
219 | 0 or 1 to disable or enable interrupts. If a driver does not implement | ||
220 | <function>irqcontrol()</function>, <function>write()</function> will | ||
221 | return with <varname>-ENOSYS</varname>. | ||
222 | </para> | ||
192 | 223 | ||
193 | <para> | 224 | <para> |
194 | To handle interrupts properly, your custom kernel module can | 225 | To handle interrupts properly, your custom kernel module can |
@@ -362,6 +393,14 @@ device is actually used. | |||
362 | <function>open()</function>, you will probably also want a custom | 393 | <function>open()</function>, you will probably also want a custom |
363 | <function>release()</function> function. | 394 | <function>release()</function> function. |
364 | </para></listitem> | 395 | </para></listitem> |
396 | |||
397 | <listitem><para> | ||
398 | <varname>int (*irqcontrol)(struct uio_info *info, s32 irq_on) | ||
399 | </varname>: Optional. If you need to be able to enable or disable | ||
400 | interrupts from userspace by writing to <filename>/dev/uioX</filename>, | ||
401 | you can implement this function. The parameter <varname>irq_on</varname> | ||
402 | will be 0 to disable interrupts and 1 to enable them. | ||
403 | </para></listitem> | ||
365 | </itemizedlist> | 404 | </itemizedlist> |
366 | 405 | ||
367 | <para> | 406 | <para> |
diff --git a/Documentation/HOWTO b/Documentation/HOWTO index 619e8caf30db..c2371c5a98f9 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO | |||
@@ -358,7 +358,7 @@ Here is a list of some of the different kernel trees available: | |||
358 | - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net> | 358 | - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net> |
359 | git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git | 359 | git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git |
360 | 360 | ||
361 | - SCSI, James Bottomley <James.Bottomley@SteelEye.com> | 361 | - SCSI, James Bottomley <James.Bottomley@hansenpartnership.com> |
362 | git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git | 362 | git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git |
363 | 363 | ||
364 | - x86, Ingo Molnar <mingo@elte.hu> | 364 | - x86, Ingo Molnar <mingo@elte.hu> |
diff --git a/Documentation/IRQ-affinity.txt b/Documentation/IRQ-affinity.txt index 938d7dd05490..b4a615b78403 100644 --- a/Documentation/IRQ-affinity.txt +++ b/Documentation/IRQ-affinity.txt | |||
@@ -1,17 +1,26 @@ | |||
1 | ChangeLog: | ||
2 | Started by Ingo Molnar <mingo@redhat.com> | ||
3 | Update by Max Krasnyansky <maxk@qualcomm.com> | ||
1 | 4 | ||
2 | SMP IRQ affinity, started by Ingo Molnar <mingo@redhat.com> | 5 | SMP IRQ affinity |
3 | |||
4 | 6 | ||
5 | /proc/irq/IRQ#/smp_affinity specifies which target CPUs are permitted | 7 | /proc/irq/IRQ#/smp_affinity specifies which target CPUs are permitted |
6 | for a given IRQ source. It's a bitmask of allowed CPUs. It's not allowed | 8 | for a given IRQ source. It's a bitmask of allowed CPUs. It's not allowed |
7 | to turn off all CPUs, and if an IRQ controller does not support IRQ | 9 | to turn off all CPUs, and if an IRQ controller does not support IRQ |
8 | affinity then the value will not change from the default 0xffffffff. | 10 | affinity then the value will not change from the default 0xffffffff. |
9 | 11 | ||
12 | /proc/irq/default_smp_affinity specifies default affinity mask that applies | ||
13 | to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask | ||
14 | will be set to the default mask. It can then be changed as described above. | ||
15 | Default mask is 0xffffffff. | ||
16 | |||
10 | Here is an example of restricting IRQ44 (eth1) to CPU0-3 then restricting | 17 | Here is an example of restricting IRQ44 (eth1) to CPU0-3 then restricting |
11 | the IRQ to CPU4-7 (this is an 8-CPU SMP box): | 18 | it to CPU4-7 (this is an 8-CPU SMP box): |
12 | 19 | ||
20 | [root@moon 44]# cd /proc/irq/44 | ||
13 | [root@moon 44]# cat smp_affinity | 21 | [root@moon 44]# cat smp_affinity |
14 | ffffffff | 22 | ffffffff |
23 | |||
15 | [root@moon 44]# echo 0f > smp_affinity | 24 | [root@moon 44]# echo 0f > smp_affinity |
16 | [root@moon 44]# cat smp_affinity | 25 | [root@moon 44]# cat smp_affinity |
17 | 0000000f | 26 | 0000000f |
@@ -21,17 +30,27 @@ PING hell (195.4.7.3): 56 data bytes | |||
21 | --- hell ping statistics --- | 30 | --- hell ping statistics --- |
22 | 6029 packets transmitted, 6027 packets received, 0% packet loss | 31 | 6029 packets transmitted, 6027 packets received, 0% packet loss |
23 | round-trip min/avg/max = 0.1/0.1/0.4 ms | 32 | round-trip min/avg/max = 0.1/0.1/0.4 ms |
24 | [root@moon 44]# cat /proc/interrupts | grep 44: | 33 | [root@moon 44]# cat /proc/interrupts | grep 'CPU\|44:' |
25 | 44: 0 1785 1785 1783 1783 1 | 34 | CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 |
26 | 1 0 IO-APIC-level eth1 | 35 | 44: 1068 1785 1785 1783 0 0 0 0 IO-APIC-level eth1 |
36 | |||
37 | As can be seen from the line above IRQ44 was delivered only to the first four | ||
38 | processors (0-3). | ||
39 | Now lets restrict that IRQ to CPU(4-7). | ||
40 | |||
27 | [root@moon 44]# echo f0 > smp_affinity | 41 | [root@moon 44]# echo f0 > smp_affinity |
42 | [root@moon 44]# cat smp_affinity | ||
43 | 000000f0 | ||
28 | [root@moon 44]# ping -f h | 44 | [root@moon 44]# ping -f h |
29 | PING hell (195.4.7.3): 56 data bytes | 45 | PING hell (195.4.7.3): 56 data bytes |
30 | .. | 46 | .. |
31 | --- hell ping statistics --- | 47 | --- hell ping statistics --- |
32 | 2779 packets transmitted, 2777 packets received, 0% packet loss | 48 | 2779 packets transmitted, 2777 packets received, 0% packet loss |
33 | round-trip min/avg/max = 0.1/0.5/585.4 ms | 49 | round-trip min/avg/max = 0.1/0.5/585.4 ms |
34 | [root@moon 44]# cat /proc/interrupts | grep 44: | 50 | [root@moon 44]# cat /proc/interrupts | 'CPU\|44:' |
35 | 44: 1068 1785 1785 1784 1784 1069 1070 1069 IO-APIC-level eth1 | 51 | CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 |
36 | [root@moon 44]# | 52 | 44: 1068 1785 1785 1783 1784 1069 1070 1069 IO-APIC-level eth1 |
53 | |||
54 | This time around IRQ44 was delivered only to the last four processors. | ||
55 | i.e counters for the CPU0-3 did not change. | ||
37 | 56 | ||
diff --git a/Documentation/Intel-IOMMU.txt b/Documentation/Intel-IOMMU.txt index c2321903aa09..21bc416d887e 100644 --- a/Documentation/Intel-IOMMU.txt +++ b/Documentation/Intel-IOMMU.txt | |||
@@ -48,7 +48,7 @@ IOVA generation is pretty generic. We used the same technique as vmalloc() | |||
48 | but these are not global address spaces, but separate for each domain. | 48 | but these are not global address spaces, but separate for each domain. |
49 | Different DMA engines may support different number of domains. | 49 | Different DMA engines may support different number of domains. |
50 | 50 | ||
51 | We also allocate gaurd pages with each mapping, so we can attempt to catch | 51 | We also allocate guard pages with each mapping, so we can attempt to catch |
52 | any overflow that might happen. | 52 | any overflow that might happen. |
53 | 53 | ||
54 | 54 | ||
@@ -112,4 +112,4 @@ TBD | |||
112 | 112 | ||
113 | - For compatibility testing, could use unity map domain for all devices, just | 113 | - For compatibility testing, could use unity map domain for all devices, just |
114 | provide a 1-1 for all useful memory under a single domain for all devices. | 114 | provide a 1-1 for all useful memory under a single domain for all devices. |
115 | - API for paravirt ops for abstracting functionlity for VMM folks. | 115 | - API for paravirt ops for abstracting functionality for VMM folks. |
diff --git a/Documentation/RCU/NMI-RCU.txt b/Documentation/RCU/NMI-RCU.txt index c64158ecde43..a6d32e65d222 100644 --- a/Documentation/RCU/NMI-RCU.txt +++ b/Documentation/RCU/NMI-RCU.txt | |||
@@ -93,6 +93,9 @@ Since NMI handlers disable preemption, synchronize_sched() is guaranteed | |||
93 | not to return until all ongoing NMI handlers exit. It is therefore safe | 93 | not to return until all ongoing NMI handlers exit. It is therefore safe |
94 | to free up the handler's data as soon as synchronize_sched() returns. | 94 | to free up the handler's data as soon as synchronize_sched() returns. |
95 | 95 | ||
96 | Important note: for this to work, the architecture in question must | ||
97 | invoke irq_enter() and irq_exit() on NMI entry and exit, respectively. | ||
98 | |||
96 | 99 | ||
97 | Answer to Quick Quiz | 100 | Answer to Quick Quiz |
98 | 101 | ||
diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index 39ad8f56783a..9f711d2df91b 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt | |||
@@ -52,6 +52,10 @@ of each iteration. Unfortunately, chaotic relaxation requires highly | |||
52 | structured data, such as the matrices used in scientific programs, and | 52 | structured data, such as the matrices used in scientific programs, and |
53 | is thus inapplicable to most data structures in operating-system kernels. | 53 | is thus inapplicable to most data structures in operating-system kernels. |
54 | 54 | ||
55 | In 1992, Henry (now Alexia) Massalin completed a dissertation advising | ||
56 | parallel programmers to defer processing when feasible to simplify | ||
57 | synchronization. RCU makes extremely heavy use of this advice. | ||
58 | |||
55 | In 1993, Jacobson [Jacobson93] verbally described what is perhaps the | 59 | In 1993, Jacobson [Jacobson93] verbally described what is perhaps the |
56 | simplest deferred-free technique: simply waiting a fixed amount of time | 60 | simplest deferred-free technique: simply waiting a fixed amount of time |
57 | before freeing blocks awaiting deferred free. Jacobson did not describe | 61 | before freeing blocks awaiting deferred free. Jacobson did not describe |
@@ -138,6 +142,13 @@ blocking in read-side critical sections appeared [PaulEMcKenney2006c], | |||
138 | Robert Olsson described an RCU-protected trie-hash combination | 142 | Robert Olsson described an RCU-protected trie-hash combination |
139 | [RobertOlsson2006a]. | 143 | [RobertOlsson2006a]. |
140 | 144 | ||
145 | 2007 saw the journal version of the award-winning RCU paper from 2006 | ||
146 | [ThomasEHart2007a], as well as a paper demonstrating use of Promela | ||
147 | and Spin to mechanically verify an optimization to Oleg Nesterov's | ||
148 | QRCU [PaulEMcKenney2007QRCUspin], a design document describing | ||
149 | preemptible RCU [PaulEMcKenney2007PreemptibleRCU], and the three-part | ||
150 | LWN "What is RCU?" series [PaulEMcKenney2007WhatIsRCUFundamentally, | ||
151 | PaulEMcKenney2008WhatIsRCUUsage, and PaulEMcKenney2008WhatIsRCUAPI]. | ||
141 | 152 | ||
142 | Bibtex Entries | 153 | Bibtex Entries |
143 | 154 | ||
@@ -202,6 +213,20 @@ Bibtex Entries | |||
202 | ,Year="1991" | 213 | ,Year="1991" |
203 | } | 214 | } |
204 | 215 | ||
216 | @phdthesis{HMassalinPhD | ||
217 | ,author="H. Massalin" | ||
218 | ,title="Synthesis: An Efficient Implementation of Fundamental Operating | ||
219 | System Services" | ||
220 | ,school="Columbia University" | ||
221 | ,address="New York, NY" | ||
222 | ,year="1992" | ||
223 | ,annotation=" | ||
224 | Mondo optimizing compiler. | ||
225 | Wait-free stuff. | ||
226 | Good advice: defer work to avoid synchronization. | ||
227 | " | ||
228 | } | ||
229 | |||
205 | @unpublished{Jacobson93 | 230 | @unpublished{Jacobson93 |
206 | ,author="Van Jacobson" | 231 | ,author="Van Jacobson" |
207 | ,title="Avoid Read-Side Locking Via Delayed Free" | 232 | ,title="Avoid Read-Side Locking Via Delayed Free" |
@@ -635,3 +660,86 @@ Revised: | |||
635 | " | 660 | " |
636 | } | 661 | } |
637 | 662 | ||
663 | @unpublished{PaulEMcKenney2007PreemptibleRCU | ||
664 | ,Author="Paul E. McKenney" | ||
665 | ,Title="The design of preemptible read-copy-update" | ||
666 | ,month="October" | ||
667 | ,day="8" | ||
668 | ,year="2007" | ||
669 | ,note="Available: | ||
670 | \url{http://lwn.net/Articles/253651/} | ||
671 | [Viewed October 25, 2007]" | ||
672 | ,annotation=" | ||
673 | LWN article describing the design of preemptible RCU. | ||
674 | " | ||
675 | } | ||
676 | |||
677 | ######################################################################## | ||
678 | # | ||
679 | # "What is RCU?" LWN series. | ||
680 | # | ||
681 | |||
682 | @unpublished{PaulEMcKenney2007WhatIsRCUFundamentally | ||
683 | ,Author="Paul E. McKenney and Jonathan Walpole" | ||
684 | ,Title="What is {RCU}, Fundamentally?" | ||
685 | ,month="December" | ||
686 | ,day="17" | ||
687 | ,year="2007" | ||
688 | ,note="Available: | ||
689 | \url{http://lwn.net/Articles/262464/} | ||
690 | [Viewed December 27, 2007]" | ||
691 | ,annotation=" | ||
692 | Lays out the three basic components of RCU: (1) publish-subscribe, | ||
693 | (2) wait for pre-existing readers to complete, and (2) maintain | ||
694 | multiple versions. | ||
695 | " | ||
696 | } | ||
697 | |||
698 | @unpublished{PaulEMcKenney2008WhatIsRCUUsage | ||
699 | ,Author="Paul E. McKenney" | ||
700 | ,Title="What is {RCU}? Part 2: Usage" | ||
701 | ,month="January" | ||
702 | ,day="4" | ||
703 | ,year="2008" | ||
704 | ,note="Available: | ||
705 | \url{http://lwn.net/Articles/263130/} | ||
706 | [Viewed January 4, 2008]" | ||
707 | ,annotation=" | ||
708 | Lays out six uses of RCU: | ||
709 | 1. RCU is a Reader-Writer Lock Replacement | ||
710 | 2. RCU is a Restricted Reference-Counting Mechanism | ||
711 | 3. RCU is a Bulk Reference-Counting Mechanism | ||
712 | 4. RCU is a Poor Man's Garbage Collector | ||
713 | 5. RCU is a Way of Providing Existence Guarantees | ||
714 | 6. RCU is a Way of Waiting for Things to Finish | ||
715 | " | ||
716 | } | ||
717 | |||
718 | @unpublished{PaulEMcKenney2008WhatIsRCUAPI | ||
719 | ,Author="Paul E. McKenney" | ||
720 | ,Title="{RCU} part 3: the {RCU} {API}" | ||
721 | ,month="January" | ||
722 | ,day="17" | ||
723 | ,year="2008" | ||
724 | ,note="Available: | ||
725 | \url{http://lwn.net/Articles/264090/} | ||
726 | [Viewed January 10, 2008]" | ||
727 | ,annotation=" | ||
728 | Gives an overview of the Linux-kernel RCU API and a brief annotated RCU | ||
729 | bibliography. | ||
730 | " | ||
731 | } | ||
732 | |||
733 | @article{DinakarGuniguntala2008IBMSysJ | ||
734 | ,author="D. Guniguntala and P. E. McKenney and J. Triplett and J. Walpole" | ||
735 | ,title="The read-copy-update mechanism for supporting real-time applications on shared-memory multiprocessor systems with {Linux}" | ||
736 | ,Year="2008" | ||
737 | ,Month="April" | ||
738 | ,journal="IBM Systems Journal" | ||
739 | ,volume="47" | ||
740 | ,number="2" | ||
741 | ,pages="@@-@@" | ||
742 | ,annotation=" | ||
743 | RCU, realtime RCU, sleepable RCU, performance. | ||
744 | " | ||
745 | } | ||
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 42b01bc2e1b4..cf5562cbe356 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt | |||
@@ -13,10 +13,13 @@ over a rather long period of time, but improvements are always welcome! | |||
13 | detailed performance measurements show that RCU is nonetheless | 13 | detailed performance measurements show that RCU is nonetheless |
14 | the right tool for the job. | 14 | the right tool for the job. |
15 | 15 | ||
16 | The other exception would be where performance is not an issue, | 16 | Another exception is where performance is not an issue, and RCU |
17 | and RCU provides a simpler implementation. An example of this | 17 | provides a simpler implementation. An example of this situation |
18 | situation is the dynamic NMI code in the Linux 2.6 kernel, | 18 | is the dynamic NMI code in the Linux 2.6 kernel, at least on |
19 | at least on architectures where NMIs are rare. | 19 | architectures where NMIs are rare. |
20 | |||
21 | Yet another exception is where the low real-time latency of RCU's | ||
22 | read-side primitives is critically important. | ||
20 | 23 | ||
21 | 1. Does the update code have proper mutual exclusion? | 24 | 1. Does the update code have proper mutual exclusion? |
22 | 25 | ||
@@ -39,9 +42,10 @@ over a rather long period of time, but improvements are always welcome! | |||
39 | 42 | ||
40 | 2. Do the RCU read-side critical sections make proper use of | 43 | 2. Do the RCU read-side critical sections make proper use of |
41 | rcu_read_lock() and friends? These primitives are needed | 44 | rcu_read_lock() and friends? These primitives are needed |
42 | to suppress preemption (or bottom halves, in the case of | 45 | to prevent grace periods from ending prematurely, which |
43 | rcu_read_lock_bh()) in the read-side critical sections, | 46 | could result in data being unceremoniously freed out from |
44 | and are also an excellent aid to readability. | 47 | under your read-side code, which can greatly increase the |
48 | actuarial risk of your kernel. | ||
45 | 49 | ||
46 | As a rough rule of thumb, any dereference of an RCU-protected | 50 | As a rough rule of thumb, any dereference of an RCU-protected |
47 | pointer must be covered by rcu_read_lock() or rcu_read_lock_bh() | 51 | pointer must be covered by rcu_read_lock() or rcu_read_lock_bh() |
@@ -54,15 +58,30 @@ over a rather long period of time, but improvements are always welcome! | |||
54 | be running while updates are in progress. There are a number | 58 | be running while updates are in progress. There are a number |
55 | of ways to handle this concurrency, depending on the situation: | 59 | of ways to handle this concurrency, depending on the situation: |
56 | 60 | ||
57 | a. Make updates appear atomic to readers. For example, | 61 | a. Use the RCU variants of the list and hlist update |
62 | primitives to add, remove, and replace elements on an | ||
63 | RCU-protected list. Alternatively, use the RCU-protected | ||
64 | trees that have been added to the Linux kernel. | ||
65 | |||
66 | This is almost always the best approach. | ||
67 | |||
68 | b. Proceed as in (a) above, but also maintain per-element | ||
69 | locks (that are acquired by both readers and writers) | ||
70 | that guard per-element state. Of course, fields that | ||
71 | the readers refrain from accessing can be guarded by the | ||
72 | update-side lock. | ||
73 | |||
74 | This works quite well, also. | ||
75 | |||
76 | c. Make updates appear atomic to readers. For example, | ||
58 | pointer updates to properly aligned fields will appear | 77 | pointer updates to properly aligned fields will appear |
59 | atomic, as will individual atomic primitives. Operations | 78 | atomic, as will individual atomic primitives. Operations |
60 | performed under a lock and sequences of multiple atomic | 79 | performed under a lock and sequences of multiple atomic |
61 | primitives will -not- appear to be atomic. | 80 | primitives will -not- appear to be atomic. |
62 | 81 | ||
63 | This is almost always the best approach. | 82 | This can work, but is starting to get a bit tricky. |
64 | 83 | ||
65 | b. Carefully order the updates and the reads so that | 84 | d. Carefully order the updates and the reads so that |
66 | readers see valid data at all phases of the update. | 85 | readers see valid data at all phases of the update. |
67 | This is often more difficult than it sounds, especially | 86 | This is often more difficult than it sounds, especially |
68 | given modern CPUs' tendency to reorder memory references. | 87 | given modern CPUs' tendency to reorder memory references. |
@@ -123,18 +142,22 @@ over a rather long period of time, but improvements are always welcome! | |||
123 | when publicizing a pointer to a structure that can | 142 | when publicizing a pointer to a structure that can |
124 | be traversed by an RCU read-side critical section. | 143 | be traversed by an RCU read-side critical section. |
125 | 144 | ||
126 | 5. If call_rcu(), or a related primitive such as call_rcu_bh(), | 145 | 5. If call_rcu(), or a related primitive such as call_rcu_bh() or |
127 | is used, the callback function must be written to be called | 146 | call_rcu_sched(), is used, the callback function must be |
128 | from softirq context. In particular, it cannot block. | 147 | written to be called from softirq context. In particular, |
148 | it cannot block. | ||
129 | 149 | ||
130 | 6. Since synchronize_rcu() can block, it cannot be called from | 150 | 6. Since synchronize_rcu() can block, it cannot be called from |
131 | any sort of irq context. | 151 | any sort of irq context. Ditto for synchronize_sched() and |
152 | synchronize_srcu(). | ||
132 | 153 | ||
133 | 7. If the updater uses call_rcu(), then the corresponding readers | 154 | 7. If the updater uses call_rcu(), then the corresponding readers |
134 | must use rcu_read_lock() and rcu_read_unlock(). If the updater | 155 | must use rcu_read_lock() and rcu_read_unlock(). If the updater |
135 | uses call_rcu_bh(), then the corresponding readers must use | 156 | uses call_rcu_bh(), then the corresponding readers must use |
136 | rcu_read_lock_bh() and rcu_read_unlock_bh(). Mixing things up | 157 | rcu_read_lock_bh() and rcu_read_unlock_bh(). If the updater |
137 | will result in confusion and broken kernels. | 158 | uses call_rcu_sched(), then the corresponding readers must |
159 | disable preemption. Mixing things up will result in confusion | ||
160 | and broken kernels. | ||
138 | 161 | ||
139 | One exception to this rule: rcu_read_lock() and rcu_read_unlock() | 162 | One exception to this rule: rcu_read_lock() and rcu_read_unlock() |
140 | may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh() | 163 | may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh() |
@@ -143,9 +166,9 @@ over a rather long period of time, but improvements are always welcome! | |||
143 | such cases is a must, of course! And the jury is still out on | 166 | such cases is a must, of course! And the jury is still out on |
144 | whether the increased speed is worth it. | 167 | whether the increased speed is worth it. |
145 | 168 | ||
146 | 8. Although synchronize_rcu() is a bit slower than is call_rcu(), | 169 | 8. Although synchronize_rcu() is slower than is call_rcu(), it |
147 | it usually results in simpler code. So, unless update | 170 | usually results in simpler code. So, unless update performance |
148 | performance is critically important or the updaters cannot block, | 171 | is critically important or the updaters cannot block, |
149 | synchronize_rcu() should be used in preference to call_rcu(). | 172 | synchronize_rcu() should be used in preference to call_rcu(). |
150 | 173 | ||
151 | An especially important property of the synchronize_rcu() | 174 | An especially important property of the synchronize_rcu() |
@@ -187,23 +210,23 @@ over a rather long period of time, but improvements are always welcome! | |||
187 | number of updates per grace period. | 210 | number of updates per grace period. |
188 | 211 | ||
189 | 9. All RCU list-traversal primitives, which include | 212 | 9. All RCU list-traversal primitives, which include |
190 | list_for_each_rcu(), list_for_each_entry_rcu(), | 213 | rcu_dereference(), list_for_each_rcu(), list_for_each_entry_rcu(), |
191 | list_for_each_continue_rcu(), and list_for_each_safe_rcu(), | 214 | list_for_each_continue_rcu(), and list_for_each_safe_rcu(), |
192 | must be within an RCU read-side critical section. RCU | 215 | must be either within an RCU read-side critical section or |
216 | must be protected by appropriate update-side locks. RCU | ||
193 | read-side critical sections are delimited by rcu_read_lock() | 217 | read-side critical sections are delimited by rcu_read_lock() |
194 | and rcu_read_unlock(), or by similar primitives such as | 218 | and rcu_read_unlock(), or by similar primitives such as |
195 | rcu_read_lock_bh() and rcu_read_unlock_bh(). | 219 | rcu_read_lock_bh() and rcu_read_unlock_bh(). |
196 | 220 | ||
197 | Use of the _rcu() list-traversal primitives outside of an | 221 | The reason that it is permissible to use RCU list-traversal |
198 | RCU read-side critical section causes no harm other than | 222 | primitives when the update-side lock is held is that doing so |
199 | a slight performance degradation on Alpha CPUs. It can | 223 | can be quite helpful in reducing code bloat when common code is |
200 | also be quite helpful in reducing code bloat when common | 224 | shared between readers and updaters. |
201 | code is shared between readers and updaters. | ||
202 | 225 | ||
203 | 10. Conversely, if you are in an RCU read-side critical section, | 226 | 10. Conversely, if you are in an RCU read-side critical section, |
204 | you -must- use the "_rcu()" variants of the list macros. | 227 | and you don't hold the appropriate update-side lock, you -must- |
205 | Failing to do so will break Alpha and confuse people reading | 228 | use the "_rcu()" variants of the list macros. Failing to do so |
206 | your code. | 229 | will break Alpha and confuse people reading your code. |
207 | 230 | ||
208 | 11. Note that synchronize_rcu() -only- guarantees to wait until | 231 | 11. Note that synchronize_rcu() -only- guarantees to wait until |
209 | all currently executing rcu_read_lock()-protected RCU read-side | 232 | all currently executing rcu_read_lock()-protected RCU read-side |
@@ -230,6 +253,14 @@ over a rather long period of time, but improvements are always welcome! | |||
230 | must use whatever locking or other synchronization is required | 253 | must use whatever locking or other synchronization is required |
231 | to safely access and/or modify that data structure. | 254 | to safely access and/or modify that data structure. |
232 | 255 | ||
256 | RCU callbacks are -usually- executed on the same CPU that executed | ||
257 | the corresponding call_rcu(), call_rcu_bh(), or call_rcu_sched(), | ||
258 | but are by -no- means guaranteed to be. For example, if a given | ||
259 | CPU goes offline while having an RCU callback pending, then that | ||
260 | RCU callback will execute on some surviving CPU. (If this was | ||
261 | not the case, a self-spawning RCU callback would prevent the | ||
262 | victim CPU from ever going offline.) | ||
263 | |||
233 | 14. SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu()) | 264 | 14. SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu()) |
234 | may only be invoked from process context. Unlike other forms of | 265 | may only be invoked from process context. Unlike other forms of |
235 | RCU, it -is- permissible to block in an SRCU read-side critical | 266 | RCU, it -is- permissible to block in an SRCU read-side critical |
diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt index 2967a65269d8..a342b6e1cc10 100644 --- a/Documentation/RCU/torture.txt +++ b/Documentation/RCU/torture.txt | |||
@@ -10,23 +10,30 @@ status messages via printk(), which can be examined via the dmesg | |||
10 | command (perhaps grepping for "torture"). The test is started | 10 | command (perhaps grepping for "torture"). The test is started |
11 | when the module is loaded, and stops when the module is unloaded. | 11 | when the module is loaded, and stops when the module is unloaded. |
12 | 12 | ||
13 | However, actually setting this config option to "y" results in the system | 13 | CONFIG_RCU_TORTURE_TEST_RUNNABLE |
14 | running the test immediately upon boot, and ending only when the system | 14 | |
15 | is taken down. Normally, one will instead want to build the system | 15 | It is also possible to specify CONFIG_RCU_TORTURE_TEST=y, which will |
16 | with CONFIG_RCU_TORTURE_TEST=m and to use modprobe and rmmod to control | 16 | result in the tests being loaded into the base kernel. In this case, |
17 | the test, perhaps using a script similar to the one shown at the end of | 17 | the CONFIG_RCU_TORTURE_TEST_RUNNABLE config option is used to specify |
18 | this document. Note that you will need CONFIG_MODULE_UNLOAD in order | 18 | whether the RCU torture tests are to be started immediately during |
19 | to be able to end the test. | 19 | boot or whether the /proc/sys/kernel/rcutorture_runnable file is used |
20 | to enable them. This /proc file can be used to repeatedly pause and | ||
21 | restart the tests, regardless of the initial state specified by the | ||
22 | CONFIG_RCU_TORTURE_TEST_RUNNABLE config option. | ||
23 | |||
24 | You will normally -not- want to start the RCU torture tests during boot | ||
25 | (and thus the default is CONFIG_RCU_TORTURE_TEST_RUNNABLE=n), but doing | ||
26 | this can sometimes be useful in finding boot-time bugs. | ||
20 | 27 | ||
21 | 28 | ||
22 | MODULE PARAMETERS | 29 | MODULE PARAMETERS |
23 | 30 | ||
24 | This module has the following parameters: | 31 | This module has the following parameters: |
25 | 32 | ||
26 | nreaders This is the number of RCU reading threads supported. | 33 | irqreaders Says to invoke RCU readers from irq level. This is currently |
27 | The default is twice the number of CPUs. Why twice? | 34 | done via timers. Defaults to "1" for variants of RCU that |
28 | To properly exercise RCU implementations with preemptible | 35 | permit this. (Or, more accurately, variants of RCU that do |
29 | read-side critical sections. | 36 | -not- permit this know to ignore this variable.) |
30 | 37 | ||
31 | nfakewriters This is the number of RCU fake writer threads to run. Fake | 38 | nfakewriters This is the number of RCU fake writer threads to run. Fake |
32 | writer threads repeatedly use the synchronous "wait for | 39 | writer threads repeatedly use the synchronous "wait for |
@@ -37,6 +44,16 @@ nfakewriters This is the number of RCU fake writer threads to run. Fake | |||
37 | to trigger special cases caused by multiple writers, such as | 44 | to trigger special cases caused by multiple writers, such as |
38 | the synchronize_srcu() early return optimization. | 45 | the synchronize_srcu() early return optimization. |
39 | 46 | ||
47 | nreaders This is the number of RCU reading threads supported. | ||
48 | The default is twice the number of CPUs. Why twice? | ||
49 | To properly exercise RCU implementations with preemptible | ||
50 | read-side critical sections. | ||
51 | |||
52 | shuffle_interval | ||
53 | The number of seconds to keep the test threads affinitied | ||
54 | to a particular subset of the CPUs, defaults to 3 seconds. | ||
55 | Used in conjunction with test_no_idle_hz. | ||
56 | |||
40 | stat_interval The number of seconds between output of torture | 57 | stat_interval The number of seconds between output of torture |
41 | statistics (via printk()). Regardless of the interval, | 58 | statistics (via printk()). Regardless of the interval, |
42 | statistics are printed when the module is unloaded. | 59 | statistics are printed when the module is unloaded. |
@@ -44,10 +61,11 @@ stat_interval The number of seconds between output of torture | |||
44 | be printed -only- when the module is unloaded, and this | 61 | be printed -only- when the module is unloaded, and this |
45 | is the default. | 62 | is the default. |
46 | 63 | ||
47 | shuffle_interval | 64 | stutter The length of time to run the test before pausing for this |
48 | The number of seconds to keep the test threads affinitied | 65 | same period of time. Defaults to "stutter=5", so as |
49 | to a particular subset of the CPUs, defaults to 5 seconds. | 66 | to run and pause for (roughly) five-second intervals. |
50 | Used in conjunction with test_no_idle_hz. | 67 | Specifying "stutter=0" causes the test to run continuously |
68 | without pausing, which is the old default behavior. | ||
51 | 69 | ||
52 | test_no_idle_hz Whether or not to test the ability of RCU to operate in | 70 | test_no_idle_hz Whether or not to test the ability of RCU to operate in |
53 | a kernel that disables the scheduling-clock interrupt to | 71 | a kernel that disables the scheduling-clock interrupt to |
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index e0d6d99b8f9b..e04d643a9f57 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt | |||
@@ -1,3 +1,11 @@ | |||
1 | Please note that the "What is RCU?" LWN series is an excellent place | ||
2 | to start learning about RCU: | ||
3 | |||
4 | 1. What is RCU, Fundamentally? http://lwn.net/Articles/262464/ | ||
5 | 2. What is RCU? Part 2: Usage http://lwn.net/Articles/263130/ | ||
6 | 3. RCU part 3: the RCU API http://lwn.net/Articles/264090/ | ||
7 | |||
8 | |||
1 | What is RCU? | 9 | What is RCU? |
2 | 10 | ||
3 | RCU is a synchronization mechanism that was added to the Linux kernel | 11 | RCU is a synchronization mechanism that was added to the Linux kernel |
@@ -772,26 +780,18 @@ Linux-kernel source code, but it helps to have a full list of the | |||
772 | APIs, since there does not appear to be a way to categorize them | 780 | APIs, since there does not appear to be a way to categorize them |
773 | in docbook. Here is the list, by category. | 781 | in docbook. Here is the list, by category. |
774 | 782 | ||
775 | Markers for RCU read-side critical sections: | ||
776 | |||
777 | rcu_read_lock | ||
778 | rcu_read_unlock | ||
779 | rcu_read_lock_bh | ||
780 | rcu_read_unlock_bh | ||
781 | srcu_read_lock | ||
782 | srcu_read_unlock | ||
783 | |||
784 | RCU pointer/list traversal: | 783 | RCU pointer/list traversal: |
785 | 784 | ||
786 | rcu_dereference | 785 | rcu_dereference |
786 | list_for_each_entry_rcu | ||
787 | hlist_for_each_entry_rcu | ||
788 | |||
787 | list_for_each_rcu (to be deprecated in favor of | 789 | list_for_each_rcu (to be deprecated in favor of |
788 | list_for_each_entry_rcu) | 790 | list_for_each_entry_rcu) |
789 | list_for_each_entry_rcu | ||
790 | list_for_each_continue_rcu (to be deprecated in favor of new | 791 | list_for_each_continue_rcu (to be deprecated in favor of new |
791 | list_for_each_entry_continue_rcu) | 792 | list_for_each_entry_continue_rcu) |
792 | hlist_for_each_entry_rcu | ||
793 | 793 | ||
794 | RCU pointer update: | 794 | RCU pointer/list update: |
795 | 795 | ||
796 | rcu_assign_pointer | 796 | rcu_assign_pointer |
797 | list_add_rcu | 797 | list_add_rcu |
@@ -799,16 +799,36 @@ RCU pointer update: | |||
799 | list_del_rcu | 799 | list_del_rcu |
800 | list_replace_rcu | 800 | list_replace_rcu |
801 | hlist_del_rcu | 801 | hlist_del_rcu |
802 | hlist_add_after_rcu | ||
803 | hlist_add_before_rcu | ||
802 | hlist_add_head_rcu | 804 | hlist_add_head_rcu |
805 | hlist_replace_rcu | ||
806 | list_splice_init_rcu() | ||
803 | 807 | ||
804 | RCU grace period: | 808 | RCU: Critical sections Grace period Barrier |
809 | |||
810 | rcu_read_lock synchronize_net rcu_barrier | ||
811 | rcu_read_unlock synchronize_rcu | ||
812 | call_rcu | ||
813 | |||
814 | |||
815 | bh: Critical sections Grace period Barrier | ||
816 | |||
817 | rcu_read_lock_bh call_rcu_bh rcu_barrier_bh | ||
818 | rcu_read_unlock_bh | ||
819 | |||
820 | |||
821 | sched: Critical sections Grace period Barrier | ||
822 | |||
823 | [preempt_disable] synchronize_sched rcu_barrier_sched | ||
824 | [and friends] call_rcu_sched | ||
825 | |||
826 | |||
827 | SRCU: Critical sections Grace period Barrier | ||
828 | |||
829 | srcu_read_lock synchronize_srcu N/A | ||
830 | srcu_read_unlock | ||
805 | 831 | ||
806 | synchronize_net | ||
807 | synchronize_sched | ||
808 | synchronize_rcu | ||
809 | synchronize_srcu | ||
810 | call_rcu | ||
811 | call_rcu_bh | ||
812 | 832 | ||
813 | See the comment headers in the source code (or the docbook generated | 833 | See the comment headers in the source code (or the docbook generated |
814 | from them) for more information. | 834 | from them) for more information. |
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 118ca6e9404f..f79ad9ff6031 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches | |||
@@ -528,7 +528,33 @@ See more details on the proper patch format in the following | |||
528 | references. | 528 | references. |
529 | 529 | ||
530 | 530 | ||
531 | 16) Sending "git pull" requests (from Linus emails) | ||
531 | 532 | ||
533 | Please write the git repo address and branch name alone on the same line | ||
534 | so that I can't even by mistake pull from the wrong branch, and so | ||
535 | that a triple-click just selects the whole thing. | ||
536 | |||
537 | So the proper format is something along the lines of: | ||
538 | |||
539 | "Please pull from | ||
540 | |||
541 | git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus | ||
542 | |||
543 | to get these changes:" | ||
544 | |||
545 | so that I don't have to hunt-and-peck for the address and inevitably | ||
546 | get it wrong (actually, I've only gotten it wrong a few times, and | ||
547 | checking against the diffstat tells me when I get it wrong, but I'm | ||
548 | just a lot more comfortable when I don't have to "look for" the right | ||
549 | thing to pull, and double-check that I have the right branch-name). | ||
550 | |||
551 | |||
552 | Please use "git diff -M --stat --summary" to generate the diffstat: | ||
553 | the -M enables rename detection, and the summary enables a summary of | ||
554 | new/deleted or renamed files. | ||
555 | |||
556 | With rename detection, the statistics are rather different [...] | ||
557 | because git will notice that a fair number of the changes are renames. | ||
532 | 558 | ||
533 | ----------------------------------- | 559 | ----------------------------------- |
534 | SECTION 2 - HINTS, TIPS, AND TRICKS | 560 | SECTION 2 - HINTS, TIPS, AND TRICKS |
diff --git a/Documentation/accounting/delay-accounting.txt b/Documentation/accounting/delay-accounting.txt index 1443cd71d263..8a12f0730c94 100644 --- a/Documentation/accounting/delay-accounting.txt +++ b/Documentation/accounting/delay-accounting.txt | |||
@@ -11,6 +11,7 @@ the delays experienced by a task while | |||
11 | a) waiting for a CPU (while being runnable) | 11 | a) waiting for a CPU (while being runnable) |
12 | b) completion of synchronous block I/O initiated by the task | 12 | b) completion of synchronous block I/O initiated by the task |
13 | c) swapping in pages | 13 | c) swapping in pages |
14 | d) memory reclaim | ||
14 | 15 | ||
15 | and makes these statistics available to userspace through | 16 | and makes these statistics available to userspace through |
16 | the taskstats interface. | 17 | the taskstats interface. |
@@ -41,7 +42,7 @@ this structure. See | |||
41 | include/linux/taskstats.h | 42 | include/linux/taskstats.h |
42 | for a description of the fields pertaining to delay accounting. | 43 | for a description of the fields pertaining to delay accounting. |
43 | It will generally be in the form of counters returning the cumulative | 44 | It will generally be in the form of counters returning the cumulative |
44 | delay seen for cpu, sync block I/O, swapin etc. | 45 | delay seen for cpu, sync block I/O, swapin, memory reclaim etc. |
45 | 46 | ||
46 | Taking the difference of two successive readings of a given | 47 | Taking the difference of two successive readings of a given |
47 | counter (say cpu_delay_total) for a task will give the delay | 48 | counter (say cpu_delay_total) for a task will give the delay |
@@ -94,7 +95,9 @@ CPU count real total virtual total delay total | |||
94 | 7876 92005750 100000000 24001500 | 95 | 7876 92005750 100000000 24001500 |
95 | IO count delay total | 96 | IO count delay total |
96 | 0 0 | 97 | 0 0 |
97 | MEM count delay total | 98 | SWAP count delay total |
99 | 0 0 | ||
100 | RECLAIM count delay total | ||
98 | 0 0 | 101 | 0 0 |
99 | 102 | ||
100 | Get delays seen in executing a given simple command | 103 | Get delays seen in executing a given simple command |
@@ -108,5 +111,7 @@ CPU count real total virtual total delay total | |||
108 | 6 4000250 4000000 0 | 111 | 6 4000250 4000000 0 |
109 | IO count delay total | 112 | IO count delay total |
110 | 0 0 | 113 | 0 0 |
111 | MEM count delay total | 114 | SWAP count delay total |
115 | 0 0 | ||
116 | RECLAIM count delay total | ||
112 | 0 0 | 117 | 0 0 |
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index 40121b5cca14..3f7755f3963f 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c | |||
@@ -196,14 +196,18 @@ void print_delayacct(struct taskstats *t) | |||
196 | " %15llu%15llu%15llu%15llu\n" | 196 | " %15llu%15llu%15llu%15llu\n" |
197 | "IO %15s%15s\n" | 197 | "IO %15s%15s\n" |
198 | " %15llu%15llu\n" | 198 | " %15llu%15llu\n" |
199 | "MEM %15s%15s\n" | 199 | "SWAP %15s%15s\n" |
200 | " %15llu%15llu\n" | ||
201 | "RECLAIM %12s%15s\n" | ||
200 | " %15llu%15llu\n", | 202 | " %15llu%15llu\n", |
201 | "count", "real total", "virtual total", "delay total", | 203 | "count", "real total", "virtual total", "delay total", |
202 | t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total, | 204 | t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total, |
203 | t->cpu_delay_total, | 205 | t->cpu_delay_total, |
204 | "count", "delay total", | 206 | "count", "delay total", |
205 | t->blkio_count, t->blkio_delay_total, | 207 | t->blkio_count, t->blkio_delay_total, |
206 | "count", "delay total", t->swapin_count, t->swapin_delay_total); | 208 | "count", "delay total", t->swapin_count, t->swapin_delay_total, |
209 | "count", "delay total", | ||
210 | t->freepages_count, t->freepages_delay_total); | ||
207 | } | 211 | } |
208 | 212 | ||
209 | void task_context_switch_counts(struct taskstats *t) | 213 | void task_context_switch_counts(struct taskstats *t) |
diff --git a/Documentation/accounting/taskstats-struct.txt b/Documentation/accounting/taskstats-struct.txt index cd784f46bf8a..e7512c061c15 100644 --- a/Documentation/accounting/taskstats-struct.txt +++ b/Documentation/accounting/taskstats-struct.txt | |||
@@ -6,7 +6,7 @@ This document contains an explanation of the struct taskstats fields. | |||
6 | There are three different groups of fields in the struct taskstats: | 6 | There are three different groups of fields in the struct taskstats: |
7 | 7 | ||
8 | 1) Common and basic accounting fields | 8 | 1) Common and basic accounting fields |
9 | If CONFIG_TASKSTATS is set, the taskstats inteface is enabled and | 9 | If CONFIG_TASKSTATS is set, the taskstats interface is enabled and |
10 | the common fields and basic accounting fields are collected for | 10 | the common fields and basic accounting fields are collected for |
11 | delivery at do_exit() of a task. | 11 | delivery at do_exit() of a task. |
12 | 2) Delay accounting fields | 12 | 2) Delay accounting fields |
@@ -26,6 +26,8 @@ There are three different groups of fields in the struct taskstats: | |||
26 | 26 | ||
27 | 5) Time accounting for SMT machines | 27 | 5) Time accounting for SMT machines |
28 | 28 | ||
29 | 6) Extended delay accounting fields for memory reclaim | ||
30 | |||
29 | Future extension should add fields to the end of the taskstats struct, and | 31 | Future extension should add fields to the end of the taskstats struct, and |
30 | should not change the relative position of each field within the struct. | 32 | should not change the relative position of each field within the struct. |
31 | 33 | ||
@@ -170,4 +172,9 @@ struct taskstats { | |||
170 | __u64 ac_utimescaled; /* utime scaled on frequency etc */ | 172 | __u64 ac_utimescaled; /* utime scaled on frequency etc */ |
171 | __u64 ac_stimescaled; /* stime scaled on frequency etc */ | 173 | __u64 ac_stimescaled; /* stime scaled on frequency etc */ |
172 | __u64 cpu_scaled_run_real_total; /* scaled cpu_run_real_total */ | 174 | __u64 cpu_scaled_run_real_total; /* scaled cpu_run_real_total */ |
175 | |||
176 | 6) Extended delay accounting fields for memory reclaim | ||
177 | /* Delay waiting for memory reclaim */ | ||
178 | __u64 freepages_count; | ||
179 | __u64 freepages_delay_total; | ||
173 | } | 180 | } |
diff --git a/Documentation/arm/Interrupts b/Documentation/arm/Interrupts index 0d3dbf1099bc..c202ed35d7d6 100644 --- a/Documentation/arm/Interrupts +++ b/Documentation/arm/Interrupts | |||
@@ -138,14 +138,8 @@ So, what's changed? | |||
138 | 138 | ||
139 | Set active the IRQ edge(s)/level. This replaces the | 139 | Set active the IRQ edge(s)/level. This replaces the |
140 | SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge() | 140 | SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge() |
141 | function. Type should be one of the following: | 141 | function. Type should be one of IRQ_TYPE_xxx defined in |
142 | 142 | <linux/irq.h> | |
143 | #define IRQT_NOEDGE (0) | ||
144 | #define IRQT_RISING (__IRQT_RISEDGE) | ||
145 | #define IRQT_FALLING (__IRQT_FALEDGE) | ||
146 | #define IRQT_BOTHEDGE (__IRQT_RISEDGE|__IRQT_FALEDGE) | ||
147 | #define IRQT_LOW (__IRQT_LOWLVL) | ||
148 | #define IRQT_HIGH (__IRQT_HIGHLVL) | ||
149 | 143 | ||
150 | 3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type. | 144 | 3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type. |
151 | 145 | ||
diff --git a/Documentation/block/data-integrity.txt b/Documentation/block/data-integrity.txt new file mode 100644 index 000000000000..e9dc8d86adc7 --- /dev/null +++ b/Documentation/block/data-integrity.txt | |||
@@ -0,0 +1,327 @@ | |||
1 | ---------------------------------------------------------------------- | ||
2 | 1. INTRODUCTION | ||
3 | |||
4 | Modern filesystems feature checksumming of data and metadata to | ||
5 | protect against data corruption. However, the detection of the | ||
6 | corruption is done at read time which could potentially be months | ||
7 | after the data was written. At that point the original data that the | ||
8 | application tried to write is most likely lost. | ||
9 | |||
10 | The solution is to ensure that the disk is actually storing what the | ||
11 | application meant it to. Recent additions to both the SCSI family | ||
12 | protocols (SBC Data Integrity Field, SCC protection proposal) as well | ||
13 | as SATA/T13 (External Path Protection) try to remedy this by adding | ||
14 | support for appending integrity metadata to an I/O. The integrity | ||
15 | metadata (or protection information in SCSI terminology) includes a | ||
16 | checksum for each sector as well as an incrementing counter that | ||
17 | ensures the individual sectors are written in the right order. And | ||
18 | for some protection schemes also that the I/O is written to the right | ||
19 | place on disk. | ||
20 | |||
21 | Current storage controllers and devices implement various protective | ||
22 | measures, for instance checksumming and scrubbing. But these | ||
23 | technologies are working in their own isolated domains or at best | ||
24 | between adjacent nodes in the I/O path. The interesting thing about | ||
25 | DIF and the other integrity extensions is that the protection format | ||
26 | is well defined and every node in the I/O path can verify the | ||
27 | integrity of the I/O and reject it if corruption is detected. This | ||
28 | allows not only corruption prevention but also isolation of the point | ||
29 | of failure. | ||
30 | |||
31 | ---------------------------------------------------------------------- | ||
32 | 2. THE DATA INTEGRITY EXTENSIONS | ||
33 | |||
34 | As written, the protocol extensions only protect the path between | ||
35 | controller and storage device. However, many controllers actually | ||
36 | allow the operating system to interact with the integrity metadata | ||
37 | (IMD). We have been working with several FC/SAS HBA vendors to enable | ||
38 | the protection information to be transferred to and from their | ||
39 | controllers. | ||
40 | |||
41 | The SCSI Data Integrity Field works by appending 8 bytes of protection | ||
42 | information to each sector. The data + integrity metadata is stored | ||
43 | in 520 byte sectors on disk. Data + IMD are interleaved when | ||
44 | transferred between the controller and target. The T13 proposal is | ||
45 | similar. | ||
46 | |||
47 | Because it is highly inconvenient for operating systems to deal with | ||
48 | 520 (and 4104) byte sectors, we approached several HBA vendors and | ||
49 | encouraged them to allow separation of the data and integrity metadata | ||
50 | scatter-gather lists. | ||
51 | |||
52 | The controller will interleave the buffers on write and split them on | ||
53 | read. This means that the Linux can DMA the data buffers to and from | ||
54 | host memory without changes to the page cache. | ||
55 | |||
56 | Also, the 16-bit CRC checksum mandated by both the SCSI and SATA specs | ||
57 | is somewhat heavy to compute in software. Benchmarks found that | ||
58 | calculating this checksum had a significant impact on system | ||
59 | performance for a number of workloads. Some controllers allow a | ||
60 | lighter-weight checksum to be used when interfacing with the operating | ||
61 | system. Emulex, for instance, supports the TCP/IP checksum instead. | ||
62 | The IP checksum received from the OS is converted to the 16-bit CRC | ||
63 | when writing and vice versa. This allows the integrity metadata to be | ||
64 | generated by Linux or the application at very low cost (comparable to | ||
65 | software RAID5). | ||
66 | |||
67 | The IP checksum is weaker than the CRC in terms of detecting bit | ||
68 | errors. However, the strength is really in the separation of the data | ||
69 | buffers and the integrity metadata. These two distinct buffers much | ||
70 | match up for an I/O to complete. | ||
71 | |||
72 | The separation of the data and integrity metadata buffers as well as | ||
73 | the choice in checksums is referred to as the Data Integrity | ||
74 | Extensions. As these extensions are outside the scope of the protocol | ||
75 | bodies (T10, T13), Oracle and its partners are trying to standardize | ||
76 | them within the Storage Networking Industry Association. | ||
77 | |||
78 | ---------------------------------------------------------------------- | ||
79 | 3. KERNEL CHANGES | ||
80 | |||
81 | The data integrity framework in Linux enables protection information | ||
82 | to be pinned to I/Os and sent to/received from controllers that | ||
83 | support it. | ||
84 | |||
85 | The advantage to the integrity extensions in SCSI and SATA is that | ||
86 | they enable us to protect the entire path from application to storage | ||
87 | device. However, at the same time this is also the biggest | ||
88 | disadvantage. It means that the protection information must be in a | ||
89 | format that can be understood by the disk. | ||
90 | |||
91 | Generally Linux/POSIX applications are agnostic to the intricacies of | ||
92 | the storage devices they are accessing. The virtual filesystem switch | ||
93 | and the block layer make things like hardware sector size and | ||
94 | transport protocols completely transparent to the application. | ||
95 | |||
96 | However, this level of detail is required when preparing the | ||
97 | protection information to send to a disk. Consequently, the very | ||
98 | concept of an end-to-end protection scheme is a layering violation. | ||
99 | It is completely unreasonable for an application to be aware whether | ||
100 | it is accessing a SCSI or SATA disk. | ||
101 | |||
102 | The data integrity support implemented in Linux attempts to hide this | ||
103 | from the application. As far as the application (and to some extent | ||
104 | the kernel) is concerned, the integrity metadata is opaque information | ||
105 | that's attached to the I/O. | ||
106 | |||
107 | The current implementation allows the block layer to automatically | ||
108 | generate the protection information for any I/O. Eventually the | ||
109 | intent is to move the integrity metadata calculation to userspace for | ||
110 | user data. Metadata and other I/O that originates within the kernel | ||
111 | will still use the automatic generation interface. | ||
112 | |||
113 | Some storage devices allow each hardware sector to be tagged with a | ||
114 | 16-bit value. The owner of this tag space is the owner of the block | ||
115 | device. I.e. the filesystem in most cases. The filesystem can use | ||
116 | this extra space to tag sectors as they see fit. Because the tag | ||
117 | space is limited, the block interface allows tagging bigger chunks by | ||
118 | way of interleaving. This way, 8*16 bits of information can be | ||
119 | attached to a typical 4KB filesystem block. | ||
120 | |||
121 | This also means that applications such as fsck and mkfs will need | ||
122 | access to manipulate the tags from user space. A passthrough | ||
123 | interface for this is being worked on. | ||
124 | |||
125 | |||
126 | ---------------------------------------------------------------------- | ||
127 | 4. BLOCK LAYER IMPLEMENTATION DETAILS | ||
128 | |||
129 | 4.1 BIO | ||
130 | |||
131 | The data integrity patches add a new field to struct bio when | ||
132 | CONFIG_BLK_DEV_INTEGRITY is enabled. bio->bi_integrity is a pointer | ||
133 | to a struct bip which contains the bio integrity payload. Essentially | ||
134 | a bip is a trimmed down struct bio which holds a bio_vec containing | ||
135 | the integrity metadata and the required housekeeping information (bvec | ||
136 | pool, vector count, etc.) | ||
137 | |||
138 | A kernel subsystem can enable data integrity protection on a bio by | ||
139 | calling bio_integrity_alloc(bio). This will allocate and attach the | ||
140 | bip to the bio. | ||
141 | |||
142 | Individual pages containing integrity metadata can subsequently be | ||
143 | attached using bio_integrity_add_page(). | ||
144 | |||
145 | bio_free() will automatically free the bip. | ||
146 | |||
147 | |||
148 | 4.2 BLOCK DEVICE | ||
149 | |||
150 | Because the format of the protection data is tied to the physical | ||
151 | disk, each block device has been extended with a block integrity | ||
152 | profile (struct blk_integrity). This optional profile is registered | ||
153 | with the block layer using blk_integrity_register(). | ||
154 | |||
155 | The profile contains callback functions for generating and verifying | ||
156 | the protection data, as well as getting and setting application tags. | ||
157 | The profile also contains a few constants to aid in completing, | ||
158 | merging and splitting the integrity metadata. | ||
159 | |||
160 | Layered block devices will need to pick a profile that's appropriate | ||
161 | for all subdevices. blk_integrity_compare() can help with that. DM | ||
162 | and MD linear, RAID0 and RAID1 are currently supported. RAID4/5/6 | ||
163 | will require extra work due to the application tag. | ||
164 | |||
165 | |||
166 | ---------------------------------------------------------------------- | ||
167 | 5.0 BLOCK LAYER INTEGRITY API | ||
168 | |||
169 | 5.1 NORMAL FILESYSTEM | ||
170 | |||
171 | The normal filesystem is unaware that the underlying block device | ||
172 | is capable of sending/receiving integrity metadata. The IMD will | ||
173 | be automatically generated by the block layer at submit_bio() time | ||
174 | in case of a WRITE. A READ request will cause the I/O integrity | ||
175 | to be verified upon completion. | ||
176 | |||
177 | IMD generation and verification can be toggled using the | ||
178 | |||
179 | /sys/block/<bdev>/integrity/write_generate | ||
180 | |||
181 | and | ||
182 | |||
183 | /sys/block/<bdev>/integrity/read_verify | ||
184 | |||
185 | flags. | ||
186 | |||
187 | |||
188 | 5.2 INTEGRITY-AWARE FILESYSTEM | ||
189 | |||
190 | A filesystem that is integrity-aware can prepare I/Os with IMD | ||
191 | attached. It can also use the application tag space if this is | ||
192 | supported by the block device. | ||
193 | |||
194 | |||
195 | int bdev_integrity_enabled(block_device, int rw); | ||
196 | |||
197 | bdev_integrity_enabled() will return 1 if the block device | ||
198 | supports integrity metadata transfer for the data direction | ||
199 | specified in 'rw'. | ||
200 | |||
201 | bdev_integrity_enabled() honors the write_generate and | ||
202 | read_verify flags in sysfs and will respond accordingly. | ||
203 | |||
204 | |||
205 | int bio_integrity_prep(bio); | ||
206 | |||
207 | To generate IMD for WRITE and to set up buffers for READ, the | ||
208 | filesystem must call bio_integrity_prep(bio). | ||
209 | |||
210 | Prior to calling this function, the bio data direction and start | ||
211 | sector must be set, and the bio should have all data pages | ||
212 | added. It is up to the caller to ensure that the bio does not | ||
213 | change while I/O is in progress. | ||
214 | |||
215 | bio_integrity_prep() should only be called if | ||
216 | bio_integrity_enabled() returned 1. | ||
217 | |||
218 | |||
219 | int bio_integrity_tag_size(bio); | ||
220 | |||
221 | If the filesystem wants to use the application tag space it will | ||
222 | first have to find out how much storage space is available. | ||
223 | Because tag space is generally limited (usually 2 bytes per | ||
224 | sector regardless of sector size), the integrity framework | ||
225 | supports interleaving the information between the sectors in an | ||
226 | I/O. | ||
227 | |||
228 | Filesystems can call bio_integrity_tag_size(bio) to find out how | ||
229 | many bytes of storage are available for that particular bio. | ||
230 | |||
231 | Another option is bdev_get_tag_size(block_device) which will | ||
232 | return the number of available bytes per hardware sector. | ||
233 | |||
234 | |||
235 | int bio_integrity_set_tag(bio, void *tag_buf, len); | ||
236 | |||
237 | After a successful return from bio_integrity_prep(), | ||
238 | bio_integrity_set_tag() can be used to attach an opaque tag | ||
239 | buffer to a bio. Obviously this only makes sense if the I/O is | ||
240 | a WRITE. | ||
241 | |||
242 | |||
243 | int bio_integrity_get_tag(bio, void *tag_buf, len); | ||
244 | |||
245 | Similarly, at READ I/O completion time the filesystem can | ||
246 | retrieve the tag buffer using bio_integrity_get_tag(). | ||
247 | |||
248 | |||
249 | 6.3 PASSING EXISTING INTEGRITY METADATA | ||
250 | |||
251 | Filesystems that either generate their own integrity metadata or | ||
252 | are capable of transferring IMD from user space can use the | ||
253 | following calls: | ||
254 | |||
255 | |||
256 | struct bip * bio_integrity_alloc(bio, gfp_mask, nr_pages); | ||
257 | |||
258 | Allocates the bio integrity payload and hangs it off of the bio. | ||
259 | nr_pages indicate how many pages of protection data need to be | ||
260 | stored in the integrity bio_vec list (similar to bio_alloc()). | ||
261 | |||
262 | The integrity payload will be freed at bio_free() time. | ||
263 | |||
264 | |||
265 | int bio_integrity_add_page(bio, page, len, offset); | ||
266 | |||
267 | Attaches a page containing integrity metadata to an existing | ||
268 | bio. The bio must have an existing bip, | ||
269 | i.e. bio_integrity_alloc() must have been called. For a WRITE, | ||
270 | the integrity metadata in the pages must be in a format | ||
271 | understood by the target device with the notable exception that | ||
272 | the sector numbers will be remapped as the request traverses the | ||
273 | I/O stack. This implies that the pages added using this call | ||
274 | will be modified during I/O! The first reference tag in the | ||
275 | integrity metadata must have a value of bip->bip_sector. | ||
276 | |||
277 | Pages can be added using bio_integrity_add_page() as long as | ||
278 | there is room in the bip bio_vec array (nr_pages). | ||
279 | |||
280 | Upon completion of a READ operation, the attached pages will | ||
281 | contain the integrity metadata received from the storage device. | ||
282 | It is up to the receiver to process them and verify data | ||
283 | integrity upon completion. | ||
284 | |||
285 | |||
286 | 6.4 REGISTERING A BLOCK DEVICE AS CAPABLE OF EXCHANGING INTEGRITY | ||
287 | METADATA | ||
288 | |||
289 | To enable integrity exchange on a block device the gendisk must be | ||
290 | registered as capable: | ||
291 | |||
292 | int blk_integrity_register(gendisk, blk_integrity); | ||
293 | |||
294 | The blk_integrity struct is a template and should contain the | ||
295 | following: | ||
296 | |||
297 | static struct blk_integrity my_profile = { | ||
298 | .name = "STANDARDSBODY-TYPE-VARIANT-CSUM", | ||
299 | .generate_fn = my_generate_fn, | ||
300 | .verify_fn = my_verify_fn, | ||
301 | .get_tag_fn = my_get_tag_fn, | ||
302 | .set_tag_fn = my_set_tag_fn, | ||
303 | .tuple_size = sizeof(struct my_tuple_size), | ||
304 | .tag_size = <tag bytes per hw sector>, | ||
305 | }; | ||
306 | |||
307 | 'name' is a text string which will be visible in sysfs. This is | ||
308 | part of the userland API so chose it carefully and never change | ||
309 | it. The format is standards body-type-variant. | ||
310 | E.g. T10-DIF-TYPE1-IP or T13-EPP-0-CRC. | ||
311 | |||
312 | 'generate_fn' generates appropriate integrity metadata (for WRITE). | ||
313 | |||
314 | 'verify_fn' verifies that the data buffer matches the integrity | ||
315 | metadata. | ||
316 | |||
317 | 'tuple_size' must be set to match the size of the integrity | ||
318 | metadata per sector. I.e. 8 for DIF and EPP. | ||
319 | |||
320 | 'tag_size' must be set to identify how many bytes of tag space | ||
321 | are available per hardware sector. For DIF this is either 2 or | ||
322 | 0 depending on the value of the Control Mode Page ATO bit. | ||
323 | |||
324 | See 6.2 for a description of get_tag_fn and set_tag_fn. | ||
325 | |||
326 | ---------------------------------------------------------------------- | ||
327 | 2007-12-24 Martin K. Petersen <martin.petersen@oracle.com> | ||
diff --git a/Documentation/bt8xxgpio.txt b/Documentation/bt8xxgpio.txt new file mode 100644 index 000000000000..d8297e4ebd26 --- /dev/null +++ b/Documentation/bt8xxgpio.txt | |||
@@ -0,0 +1,67 @@ | |||
1 | =============================================================== | ||
2 | == BT8XXGPIO driver == | ||
3 | == == | ||
4 | == A driver for a selfmade cheap BT8xx based PCI GPIO-card == | ||
5 | == == | ||
6 | == For advanced documentation, see == | ||
7 | == http://www.bu3sch.de/btgpio.php == | ||
8 | =============================================================== | ||
9 | |||
10 | |||
11 | A generic digital 24-port PCI GPIO card can be built out of an ordinary | ||
12 | Brooktree bt848, bt849, bt878 or bt879 based analog TV tuner card. The | ||
13 | Brooktree chip is used in old analog Hauppauge WinTV PCI cards. You can easily | ||
14 | find them used for low prices on the net. | ||
15 | |||
16 | The bt8xx chip does have 24 digital GPIO ports. | ||
17 | These ports are accessible via 24 pins on the SMD chip package. | ||
18 | |||
19 | |||
20 | ============================================== | ||
21 | == How to physically access the GPIO pins == | ||
22 | ============================================== | ||
23 | |||
24 | The are several ways to access these pins. One might unsolder the whole chip | ||
25 | and put it on a custom PCI board, or one might only unsolder each individual | ||
26 | GPIO pin and solder that to some tiny wire. As the chip package really is tiny | ||
27 | there are some advanced soldering skills needed in any case. | ||
28 | |||
29 | The physical pinouts are drawn in the following ASCII art. | ||
30 | The GPIO pins are marked with G00-G23 | ||
31 | |||
32 | G G G G G G G G G G G G G G G G G G | ||
33 | 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 | ||
34 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 | ||
35 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ||
36 | --------------------------------------------------------------------------- | ||
37 | --| ^ ^ |-- | ||
38 | --| pin 86 pin 67 |-- | ||
39 | --| |-- | ||
40 | --| pin 61 > |-- G18 | ||
41 | --| |-- G19 | ||
42 | --| |-- G20 | ||
43 | --| |-- G21 | ||
44 | --| |-- G22 | ||
45 | --| pin 56 > |-- G23 | ||
46 | --| |-- | ||
47 | --| Brooktree 878/879 |-- | ||
48 | --| |-- | ||
49 | --| |-- | ||
50 | --| |-- | ||
51 | --| |-- | ||
52 | --| |-- | ||
53 | --| |-- | ||
54 | --| |-- | ||
55 | --| |-- | ||
56 | --| |-- | ||
57 | --| |-- | ||
58 | --| |-- | ||
59 | --| |-- | ||
60 | --| |-- | ||
61 | --| O |-- | ||
62 | --| |-- | ||
63 | --------------------------------------------------------------------------- | ||
64 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ||
65 | ^ | ||
66 | This is pin 1 | ||
67 | |||
diff --git a/Documentation/controllers/memory.txt b/Documentation/controllers/memory.txt index 866b9cd9a959..9b53d5827361 100644 --- a/Documentation/controllers/memory.txt +++ b/Documentation/controllers/memory.txt | |||
@@ -242,8 +242,7 @@ rmdir() if there are no tasks. | |||
242 | 1. Add support for accounting huge pages (as a separate controller) | 242 | 1. Add support for accounting huge pages (as a separate controller) |
243 | 2. Make per-cgroup scanner reclaim not-shared pages first | 243 | 2. Make per-cgroup scanner reclaim not-shared pages first |
244 | 3. Teach controller to account for shared-pages | 244 | 3. Teach controller to account for shared-pages |
245 | 4. Start reclamation when the limit is lowered | 245 | 4. Start reclamation in the background when the limit is |
246 | 5. Start reclamation in the background when the limit is | ||
247 | not yet hit but the usage is getting closer | 246 | not yet hit but the usage is getting closer |
248 | 247 | ||
249 | Summary | 248 | Summary |
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index dcec0564d040..5b0cfa67aff9 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt | |||
@@ -122,7 +122,7 @@ around '10000' or more. | |||
122 | show_sampling_rate_(min|max): the minimum and maximum sampling rates | 122 | show_sampling_rate_(min|max): the minimum and maximum sampling rates |
123 | available that you may set 'sampling_rate' to. | 123 | available that you may set 'sampling_rate' to. |
124 | 124 | ||
125 | up_threshold: defines what the average CPU usaged between the samplings | 125 | up_threshold: defines what the average CPU usage between the samplings |
126 | of 'sampling_rate' needs to be for the kernel to make a decision on | 126 | of 'sampling_rate' needs to be for the kernel to make a decision on |
127 | whether it should increase the frequency. For example when it is set | 127 | whether it should increase the frequency. For example when it is set |
128 | to its default value of '80' it means that between the checking | 128 | to its default value of '80' it means that between the checking |
diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index b61cb9564023..bd699da24666 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt | |||
@@ -14,9 +14,8 @@ represent the thread siblings to cpu X in the same physical package; | |||
14 | To implement it in an architecture-neutral way, a new source file, | 14 | To implement it in an architecture-neutral way, a new source file, |
15 | drivers/base/topology.c, is to export the 4 attributes. | 15 | drivers/base/topology.c, is to export the 4 attributes. |
16 | 16 | ||
17 | If one architecture wants to support this feature, it just needs to | 17 | For an architecture to support this feature, it must define some of |
18 | implement 4 defines, typically in file include/asm-XXX/topology.h. | 18 | these macros in include/asm-XXX/topology.h: |
19 | The 4 defines are: | ||
20 | #define topology_physical_package_id(cpu) | 19 | #define topology_physical_package_id(cpu) |
21 | #define topology_core_id(cpu) | 20 | #define topology_core_id(cpu) |
22 | #define topology_thread_siblings(cpu) | 21 | #define topology_thread_siblings(cpu) |
@@ -25,17 +24,10 @@ The 4 defines are: | |||
25 | The type of **_id is int. | 24 | The type of **_id is int. |
26 | The type of siblings is cpumask_t. | 25 | The type of siblings is cpumask_t. |
27 | 26 | ||
28 | To be consistent on all architectures, the 4 attributes should have | 27 | To be consistent on all architectures, include/linux/topology.h |
29 | default values if their values are unavailable. Below is the rule. | 28 | provides default definitions for any of the above macros that are |
30 | 1) physical_package_id: If cpu has no physical package id, -1 is the | 29 | not defined by include/asm-XXX/topology.h: |
31 | default value. | 30 | 1) physical_package_id: -1 |
32 | 2) core_id: If cpu doesn't support multi-core, its core id is 0. | 31 | 2) core_id: 0 |
33 | 3) thread_siblings: Just include itself, if the cpu doesn't support | 32 | 3) thread_siblings: just the given CPU |
34 | HT/multi-thread. | 33 | 4) core_siblings: just the given CPU |
35 | 4) core_siblings: Just include itself, if the cpu doesn't support | ||
36 | multi-core and HT/Multi-thread. | ||
37 | |||
38 | So be careful when declaring the 4 defines in include/asm-XXX/topology.h. | ||
39 | |||
40 | If an attribute isn't defined on an architecture, it won't be exported. | ||
41 | |||
diff --git a/Documentation/edac.txt b/Documentation/edac.txt index a5c36842ecef..8eda3fb66416 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt | |||
@@ -222,74 +222,9 @@ both csrow2 and csrow3 are populated, this indicates a dual ranked | |||
222 | set of DIMMs for channels 0 and 1. | 222 | set of DIMMs for channels 0 and 1. |
223 | 223 | ||
224 | 224 | ||
225 | Within each of the 'mc','mcX' and 'csrowX' directories are several | 225 | Within each of the 'mcX' and 'csrowX' directories are several |
226 | EDAC control and attribute files. | 226 | EDAC control and attribute files. |
227 | 227 | ||
228 | |||
229 | ============================================================================ | ||
230 | DIRECTORY 'mc' | ||
231 | |||
232 | In directory 'mc' are EDAC system overall control and attribute files: | ||
233 | |||
234 | |||
235 | Panic on UE control file: | ||
236 | |||
237 | 'edac_mc_panic_on_ue' | ||
238 | |||
239 | An uncorrectable error will cause a machine panic. This is usually | ||
240 | desirable. It is a bad idea to continue when an uncorrectable error | ||
241 | occurs - it is indeterminate what was uncorrected and the operating | ||
242 | system context might be so mangled that continuing will lead to further | ||
243 | corruption. If the kernel has MCE configured, then EDAC will never | ||
244 | notice the UE. | ||
245 | |||
246 | LOAD TIME: module/kernel parameter: panic_on_ue=[0|1] | ||
247 | |||
248 | RUN TIME: echo "1" >/sys/devices/system/edac/mc/edac_mc_panic_on_ue | ||
249 | |||
250 | |||
251 | Log UE control file: | ||
252 | |||
253 | 'edac_mc_log_ue' | ||
254 | |||
255 | Generate kernel messages describing uncorrectable errors. These errors | ||
256 | are reported through the system message log system. UE statistics | ||
257 | will be accumulated even when UE logging is disabled. | ||
258 | |||
259 | LOAD TIME: module/kernel parameter: log_ue=[0|1] | ||
260 | |||
261 | RUN TIME: echo "1" >/sys/devices/system/edac/mc/edac_mc_log_ue | ||
262 | |||
263 | |||
264 | Log CE control file: | ||
265 | |||
266 | 'edac_mc_log_ce' | ||
267 | |||
268 | Generate kernel messages describing correctable errors. These | ||
269 | errors are reported through the system message log system. | ||
270 | CE statistics will be accumulated even when CE logging is disabled. | ||
271 | |||
272 | LOAD TIME: module/kernel parameter: log_ce=[0|1] | ||
273 | |||
274 | RUN TIME: echo "1" >/sys/devices/system/edac/mc/edac_mc_log_ce | ||
275 | |||
276 | |||
277 | Polling period control file: | ||
278 | |||
279 | 'edac_mc_poll_msec' | ||
280 | |||
281 | The time period, in milliseconds, for polling for error information. | ||
282 | Too small a value wastes resources. Too large a value might delay | ||
283 | necessary handling of errors and might loose valuable information for | ||
284 | locating the error. 1000 milliseconds (once each second) is the current | ||
285 | default. Systems which require all the bandwidth they can get, may | ||
286 | increase this. | ||
287 | |||
288 | LOAD TIME: module/kernel parameter: poll_msec=[0|1] | ||
289 | |||
290 | RUN TIME: echo "1000" >/sys/devices/system/edac/mc/edac_mc_poll_msec | ||
291 | |||
292 | |||
293 | ============================================================================ | 228 | ============================================================================ |
294 | 'mcX' DIRECTORIES | 229 | 'mcX' DIRECTORIES |
295 | 230 | ||
@@ -392,7 +327,7 @@ Sdram memory scrubbing rate: | |||
392 | 'sdram_scrub_rate' | 327 | 'sdram_scrub_rate' |
393 | 328 | ||
394 | Read/Write attribute file that controls memory scrubbing. The scrubbing | 329 | Read/Write attribute file that controls memory scrubbing. The scrubbing |
395 | rate is set by writing a minimum bandwith in bytes/sec to the attribute | 330 | rate is set by writing a minimum bandwidth in bytes/sec to the attribute |
396 | file. The rate will be translated to an internal value that gives at | 331 | file. The rate will be translated to an internal value that gives at |
397 | least the specified rate. | 332 | least the specified rate. |
398 | 333 | ||
@@ -537,7 +472,6 @@ Channel 1 DIMM Label control file: | |||
537 | motherboard specific and determination of this information | 472 | motherboard specific and determination of this information |
538 | must occur in userland at this time. | 473 | must occur in userland at this time. |
539 | 474 | ||
540 | |||
541 | ============================================================================ | 475 | ============================================================================ |
542 | SYSTEM LOGGING | 476 | SYSTEM LOGGING |
543 | 477 | ||
@@ -570,7 +504,6 @@ error type, a notice of "no info" and then an optional, | |||
570 | driver-specific error message. | 504 | driver-specific error message. |
571 | 505 | ||
572 | 506 | ||
573 | |||
574 | ============================================================================ | 507 | ============================================================================ |
575 | PCI Bus Parity Detection | 508 | PCI Bus Parity Detection |
576 | 509 | ||
@@ -604,6 +537,74 @@ Enable/Disable PCI Parity checking control file: | |||
604 | echo "0" >/sys/devices/system/edac/pci/check_pci_parity | 537 | echo "0" >/sys/devices/system/edac/pci/check_pci_parity |
605 | 538 | ||
606 | 539 | ||
540 | Parity Count: | ||
541 | |||
542 | 'pci_parity_count' | ||
543 | |||
544 | This attribute file will display the number of parity errors that | ||
545 | have been detected. | ||
546 | |||
547 | |||
548 | ============================================================================ | ||
549 | MODULE PARAMETERS | ||
550 | |||
551 | Panic on UE control file: | ||
552 | |||
553 | 'edac_mc_panic_on_ue' | ||
554 | |||
555 | An uncorrectable error will cause a machine panic. This is usually | ||
556 | desirable. It is a bad idea to continue when an uncorrectable error | ||
557 | occurs - it is indeterminate what was uncorrected and the operating | ||
558 | system context might be so mangled that continuing will lead to further | ||
559 | corruption. If the kernel has MCE configured, then EDAC will never | ||
560 | notice the UE. | ||
561 | |||
562 | LOAD TIME: module/kernel parameter: edac_mc_panic_on_ue=[0|1] | ||
563 | |||
564 | RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_panic_on_ue | ||
565 | |||
566 | |||
567 | Log UE control file: | ||
568 | |||
569 | 'edac_mc_log_ue' | ||
570 | |||
571 | Generate kernel messages describing uncorrectable errors. These errors | ||
572 | are reported through the system message log system. UE statistics | ||
573 | will be accumulated even when UE logging is disabled. | ||
574 | |||
575 | LOAD TIME: module/kernel parameter: edac_mc_log_ue=[0|1] | ||
576 | |||
577 | RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ue | ||
578 | |||
579 | |||
580 | Log CE control file: | ||
581 | |||
582 | 'edac_mc_log_ce' | ||
583 | |||
584 | Generate kernel messages describing correctable errors. These | ||
585 | errors are reported through the system message log system. | ||
586 | CE statistics will be accumulated even when CE logging is disabled. | ||
587 | |||
588 | LOAD TIME: module/kernel parameter: edac_mc_log_ce=[0|1] | ||
589 | |||
590 | RUN TIME: echo "1" > /sys/module/edac_core/parameters/edac_mc_log_ce | ||
591 | |||
592 | |||
593 | Polling period control file: | ||
594 | |||
595 | 'edac_mc_poll_msec' | ||
596 | |||
597 | The time period, in milliseconds, for polling for error information. | ||
598 | Too small a value wastes resources. Too large a value might delay | ||
599 | necessary handling of errors and might loose valuable information for | ||
600 | locating the error. 1000 milliseconds (once each second) is the current | ||
601 | default. Systems which require all the bandwidth they can get, may | ||
602 | increase this. | ||
603 | |||
604 | LOAD TIME: module/kernel parameter: edac_mc_poll_msec=[0|1] | ||
605 | |||
606 | RUN TIME: echo "1000" > /sys/module/edac_core/parameters/edac_mc_poll_msec | ||
607 | |||
607 | 608 | ||
608 | Panic on PCI PARITY Error: | 609 | Panic on PCI PARITY Error: |
609 | 610 | ||
@@ -614,21 +615,13 @@ Panic on PCI PARITY Error: | |||
614 | error has been detected. | 615 | error has been detected. |
615 | 616 | ||
616 | 617 | ||
617 | module/kernel parameter: panic_on_pci_parity=[0|1] | 618 | module/kernel parameter: edac_panic_on_pci_pe=[0|1] |
618 | 619 | ||
619 | Enable: | 620 | Enable: |
620 | echo "1" >/sys/devices/system/edac/pci/panic_on_pci_parity | 621 | echo "1" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe |
621 | 622 | ||
622 | Disable: | 623 | Disable: |
623 | echo "0" >/sys/devices/system/edac/pci/panic_on_pci_parity | 624 | echo "0" > /sys/module/edac_core/parameters/edac_panic_on_pci_pe |
624 | |||
625 | |||
626 | Parity Count: | ||
627 | |||
628 | 'pci_parity_count' | ||
629 | |||
630 | This attribute file will display the number of parity errors that | ||
631 | have been detected. | ||
632 | 625 | ||
633 | 626 | ||
634 | 627 | ||
diff --git a/Documentation/fb/sh7760fb.txt b/Documentation/fb/sh7760fb.txt new file mode 100644 index 000000000000..c87bfe5c630a --- /dev/null +++ b/Documentation/fb/sh7760fb.txt | |||
@@ -0,0 +1,131 @@ | |||
1 | SH7760/SH7763 integrated LCDC Framebuffer driver | ||
2 | ================================================ | ||
3 | |||
4 | 0. Overwiew | ||
5 | ----------- | ||
6 | The SH7760/SH7763 have an integrated LCD Display controller (LCDC) which | ||
7 | supports (in theory) resolutions ranging from 1x1 to 1024x1024, | ||
8 | with color depths ranging from 1 to 16 bits, on STN, DSTN and TFT Panels. | ||
9 | |||
10 | Caveats: | ||
11 | * Framebuffer memory must be a large chunk allocated at the top | ||
12 | of Area3 (HW requirement). Because of this requirement you should NOT | ||
13 | make the driver a module since at runtime it may become impossible to | ||
14 | get a large enough contiguous chunk of memory. | ||
15 | |||
16 | * The driver does not support changing resolution while loaded | ||
17 | (displays aren't hotpluggable anyway) | ||
18 | |||
19 | * Heavy flickering may be observed | ||
20 | a) if you're using 15/16bit color modes at >= 640x480 px resolutions, | ||
21 | b) during PCMCIA (or any other slow bus) activity. | ||
22 | |||
23 | * Rotation works only 90degress clockwise, and only if horizontal | ||
24 | resolution is <= 320 pixels. | ||
25 | |||
26 | files: drivers/video/sh7760fb.c | ||
27 | include/asm-sh/sh7760fb.h | ||
28 | Documentation/fb/sh7760fb.txt | ||
29 | |||
30 | 1. Platform setup | ||
31 | ----------------- | ||
32 | SH7760: | ||
33 | Video data is fetched via the DMABRG DMA engine, so you have to | ||
34 | configure the SH DMAC for DMABRG mode (write 0x94808080 to the | ||
35 | DMARSRA register somewhere at boot). | ||
36 | |||
37 | PFC registers PCCR and PCDR must be set to peripheral mode. | ||
38 | (write zeros to both). | ||
39 | |||
40 | The driver does NOT do the above for you since board setup is, well, job | ||
41 | of the board setup code. | ||
42 | |||
43 | 2. Panel definitions | ||
44 | -------------------- | ||
45 | The LCDC must explicitly be told about the type of LCD panel | ||
46 | attached. Data must be wrapped in a "struct sh7760fb_platdata" and | ||
47 | passed to the driver as platform_data. | ||
48 | |||
49 | Suggest you take a closer look at the SH7760 Manual, Section 30. | ||
50 | (http://documentation.renesas.com/eng/products/mpumcu/e602291_sh7760.pdf) | ||
51 | |||
52 | The following code illustrates what needs to be done to | ||
53 | get the framebuffer working on a 640x480 TFT: | ||
54 | |||
55 | ====================== cut here ====================================== | ||
56 | |||
57 | #include <linux/fb.h> | ||
58 | #include <asm/sh7760fb.h> | ||
59 | |||
60 | /* | ||
61 | * NEC NL6440bc26-01 640x480 TFT | ||
62 | * dotclock 25175 kHz | ||
63 | * Xres 640 Yres 480 | ||
64 | * Htotal 800 Vtotal 525 | ||
65 | * HsynStart 656 VsynStart 490 | ||
66 | * HsynLenn 30 VsynLenn 2 | ||
67 | * | ||
68 | * The linux framebuffer layer does not use the syncstart/synclen | ||
69 | * values but right/left/upper/lower margin values. The comments | ||
70 | * for the x_margin explain how to calculate those from given | ||
71 | * panel sync timings. | ||
72 | */ | ||
73 | static struct fb_videomode nl6448bc26 = { | ||
74 | .name = "NL6448BC26", | ||
75 | .refresh = 60, | ||
76 | .xres = 640, | ||
77 | .yres = 480, | ||
78 | .pixclock = 39683, /* in picoseconds! */ | ||
79 | .hsync_len = 30, | ||
80 | .vsync_len = 2, | ||
81 | .left_margin = 114, /* HTOT - (HSYNSLEN + HSYNSTART) */ | ||
82 | .right_margin = 16, /* HSYNSTART - XRES */ | ||
83 | .upper_margin = 33, /* VTOT - (VSYNLEN + VSYNSTART) */ | ||
84 | .lower_margin = 10, /* VSYNSTART - YRES */ | ||
85 | .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, | ||
86 | .vmode = FB_VMODE_NONINTERLACED, | ||
87 | .flag = 0, | ||
88 | }; | ||
89 | |||
90 | static struct sh7760fb_platdata sh7760fb_nl6448 = { | ||
91 | .def_mode = &nl6448bc26, | ||
92 | .ldmtr = LDMTR_TFT_COLOR_16, /* 16bit TFT panel */ | ||
93 | .lddfr = LDDFR_8BPP, /* we want 8bit output */ | ||
94 | .ldpmmr = 0x0070, | ||
95 | .ldpspr = 0x0500, | ||
96 | .ldaclnr = 0, | ||
97 | .ldickr = LDICKR_CLKSRC(LCDC_CLKSRC_EXTERNAL) | | ||
98 | LDICKR_CLKDIV(1), | ||
99 | .rotate = 0, | ||
100 | .novsync = 1, | ||
101 | .blank = NULL, | ||
102 | }; | ||
103 | |||
104 | /* SH7760: | ||
105 | * 0xFE300800: 256 * 4byte xRGB palette ram | ||
106 | * 0xFE300C00: 42 bytes ctrl registers | ||
107 | */ | ||
108 | static struct resource sh7760_lcdc_res[] = { | ||
109 | [0] = { | ||
110 | .start = 0xFE300800, | ||
111 | .end = 0xFE300CFF, | ||
112 | .flags = IORESOURCE_MEM, | ||
113 | }, | ||
114 | [1] = { | ||
115 | .start = 65, | ||
116 | .end = 65, | ||
117 | .flags = IORESOURCE_IRQ, | ||
118 | }, | ||
119 | }; | ||
120 | |||
121 | static struct platform_device sh7760_lcdc_dev = { | ||
122 | .dev = { | ||
123 | .platform_data = &sh7760fb_nl6448, | ||
124 | }, | ||
125 | .name = "sh7760-lcdc", | ||
126 | .id = -1, | ||
127 | .resource = sh7760_lcdc_res, | ||
128 | .num_resources = ARRAY_SIZE(sh7760_lcdc_res), | ||
129 | }; | ||
130 | |||
131 | ====================== cut here ====================================== | ||
diff --git a/Documentation/fb/tridentfb.txt b/Documentation/fb/tridentfb.txt index 8a6c8a43e6a3..45d9de5b13a3 100644 --- a/Documentation/fb/tridentfb.txt +++ b/Documentation/fb/tridentfb.txt | |||
@@ -3,11 +3,25 @@ Tridentfb is a framebuffer driver for some Trident chip based cards. | |||
3 | The following list of chips is thought to be supported although not all are | 3 | The following list of chips is thought to be supported although not all are |
4 | tested: | 4 | tested: |
5 | 5 | ||
6 | those from the Image series with Cyber in their names - accelerated | 6 | those from the TGUI series 9440/96XX and with Cyber in their names |
7 | those with Blade in their names (Blade3D,CyberBlade...) - accelerated | 7 | those from the Image series and with Cyber in their names |
8 | the newer CyberBladeXP family - nonaccelerated | 8 | those with Blade in their names (Blade3D,CyberBlade...) |
9 | 9 | the newer CyberBladeXP family | |
10 | Only PCI/AGP based cards are supported, none of the older Tridents. | 10 | |
11 | All families are accelerated. Only PCI/AGP based cards are supported, | ||
12 | none of the older Tridents. | ||
13 | The driver supports 8, 16 and 32 bits per pixel depths. | ||
14 | The TGUI family requires a line length to be power of 2 if acceleration | ||
15 | is enabled. This means that range of possible resolutions and bpp is | ||
16 | limited comparing to the range if acceleration is disabled (see list | ||
17 | of parameters below). | ||
18 | |||
19 | Known bugs: | ||
20 | 1. The driver randomly locks up on 3DImage975 chip with acceleration | ||
21 | enabled. The same happens in X11 (Xorg). | ||
22 | 2. The ramdac speeds require some more fine tuning. It is possible to | ||
23 | switch resolution which the chip does not support at some depths for | ||
24 | older chips. | ||
11 | 25 | ||
12 | How to use it? | 26 | How to use it? |
13 | ============== | 27 | ============== |
@@ -17,12 +31,11 @@ video=tridentfb | |||
17 | 31 | ||
18 | The parameters for tridentfb are concatenated with a ':' as in this example. | 32 | The parameters for tridentfb are concatenated with a ':' as in this example. |
19 | 33 | ||
20 | video=tridentfb:800x600,bpp=16,noaccel | 34 | video=tridentfb:800x600-16@75,noaccel |
21 | 35 | ||
22 | The second level parameters that tridentfb understands are: | 36 | The second level parameters that tridentfb understands are: |
23 | 37 | ||
24 | noaccel - turns off acceleration (when it doesn't work for your card) | 38 | noaccel - turns off acceleration (when it doesn't work for your card) |
25 | accel - force text acceleration (for boards which by default are noacceled) | ||
26 | 39 | ||
27 | fp - use flat panel related stuff | 40 | fp - use flat panel related stuff |
28 | crt - assume monitor is present instead of fp | 41 | crt - assume monitor is present instead of fp |
@@ -31,21 +44,24 @@ center - for flat panels and resolutions smaller than native size center the | |||
31 | image, otherwise use | 44 | image, otherwise use |
32 | stretch | 45 | stretch |
33 | 46 | ||
34 | memsize - integer value in Kb, use if your card's memory size is misdetected. | 47 | memsize - integer value in KB, use if your card's memory size is misdetected. |
35 | look at the driver output to see what it says when initializing. | 48 | look at the driver output to see what it says when initializing. |
36 | memdiff - integer value in Kb,should be nonzero if your card reports | 49 | |
37 | more memory than it actually has.For instance mine is 192K less than | 50 | memdiff - integer value in KB, should be nonzero if your card reports |
51 | more memory than it actually has. For instance mine is 192K less than | ||
38 | detection says in all three BIOS selectable situations 2M, 4M, 8M. | 52 | detection says in all three BIOS selectable situations 2M, 4M, 8M. |
39 | Only use if your video memory is taken from main memory hence of | 53 | Only use if your video memory is taken from main memory hence of |
40 | configurable size.Otherwise use memsize. | 54 | configurable size. Otherwise use memsize. |
41 | If in some modes which barely fit the memory you see garbage at the bottom | 55 | If in some modes which barely fit the memory you see garbage |
42 | this might help by not letting change to that mode anymore. | 56 | at the bottom this might help by not letting change to that mode |
57 | anymore. | ||
43 | 58 | ||
44 | nativex - the width in pixels of the flat panel.If you know it (usually 1024 | 59 | nativex - the width in pixels of the flat panel.If you know it (usually 1024 |
45 | 800 or 1280) and it is not what the driver seems to detect use it. | 60 | 800 or 1280) and it is not what the driver seems to detect use it. |
46 | 61 | ||
47 | bpp - bits per pixel (8,16 or 32) | 62 | bpp - bits per pixel (8,16 or 32) |
48 | mode - a mode name like 800x600 (as described in Documentation/fb/modedb.txt) | 63 | mode - a mode name like 800x600-8@75 as described in |
64 | Documentation/fb/modedb.txt | ||
49 | 65 | ||
50 | Using insane values for the above parameters will probably result in driver | 66 | Using insane values for the above parameters will probably result in driver |
51 | misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or | 67 | misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 46ece3fba6f9..c23955404bf5 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -47,6 +47,30 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org> | |||
47 | 47 | ||
48 | --------------------------- | 48 | --------------------------- |
49 | 49 | ||
50 | What: old tuner-3036 i2c driver | ||
51 | When: 2.6.28 | ||
52 | Why: This driver is for VERY old i2c-over-parallel port teletext receiver | ||
53 | boxes. Rather then spending effort on converting this driver to V4L2, | ||
54 | and since it is extremely unlikely that anyone still uses one of these | ||
55 | devices, it was decided to drop it. | ||
56 | Who: Hans Verkuil <hverkuil@xs4all.nl> | ||
57 | Mauro Carvalho Chehab <mchehab@infradead.org> | ||
58 | |||
59 | --------------------------- | ||
60 | |||
61 | What: V4L2 dpc7146 driver | ||
62 | When: 2.6.28 | ||
63 | Why: Old driver for the dpc7146 demonstration board that is no longer | ||
64 | relevant. The last time this was tested on actual hardware was | ||
65 | probably around 2002. Since this is a driver for a demonstration | ||
66 | board the decision was made to remove it rather than spending a | ||
67 | lot of effort continually updating this driver to stay in sync | ||
68 | with the latest internal V4L2 or I2C API. | ||
69 | Who: Hans Verkuil <hverkuil@xs4all.nl> | ||
70 | Mauro Carvalho Chehab <mchehab@infradead.org> | ||
71 | |||
72 | --------------------------- | ||
73 | |||
50 | What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) | 74 | What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) |
51 | When: November 2005 | 75 | When: November 2005 |
52 | Files: drivers/pcmcia/: pcmcia_ioctl.c | 76 | Files: drivers/pcmcia/: pcmcia_ioctl.c |
@@ -138,24 +162,6 @@ Who: Kay Sievers <kay.sievers@suse.de> | |||
138 | 162 | ||
139 | --------------------------- | 163 | --------------------------- |
140 | 164 | ||
141 | What: find_task_by_pid | ||
142 | When: 2.6.26 | ||
143 | Why: With pid namespaces, calling this funciton will return the | ||
144 | wrong task when called from inside a namespace. | ||
145 | |||
146 | The best way to save a task pid and find a task by this | ||
147 | pid later, is to find this task's struct pid pointer (or get | ||
148 | it directly from the task) and call pid_task() later. | ||
149 | |||
150 | If someone really needs to get a task by its pid_t, then | ||
151 | he most likely needs the find_task_by_vpid() to get the | ||
152 | task from the same namespace as the current task is in, but | ||
153 | this may be not so in general. | ||
154 | |||
155 | Who: Pavel Emelyanov <xemul@openvz.org> | ||
156 | |||
157 | --------------------------- | ||
158 | |||
159 | What: ACPI procfs interface | 165 | What: ACPI procfs interface |
160 | When: July 2008 | 166 | When: July 2008 |
161 | Why: ACPI sysfs conversion should be finished by January 2008. | 167 | Why: ACPI sysfs conversion should be finished by January 2008. |
@@ -222,13 +228,6 @@ Who: Thomas Gleixner <tglx@linutronix.de> | |||
222 | 228 | ||
223 | --------------------------- | 229 | --------------------------- |
224 | 230 | ||
225 | What: i2c-i810, i2c-prosavage and i2c-savage4 | ||
226 | When: May 2008 | ||
227 | Why: These drivers are superseded by i810fb, intelfb and savagefb. | ||
228 | Who: Jean Delvare <khali@linux-fr.org> | ||
229 | |||
230 | --------------------------- | ||
231 | |||
232 | What (Why): | 231 | What (Why): |
233 | - include/linux/netfilter_ipv4/ipt_TOS.h ipt_tos.h header files | 232 | - include/linux/netfilter_ipv4/ipt_TOS.h ipt_tos.h header files |
234 | (superseded by xt_TOS/xt_tos target & match) | 233 | (superseded by xt_TOS/xt_tos target & match) |
@@ -307,11 +306,15 @@ Who: ocfs2-devel@oss.oracle.com | |||
307 | 306 | ||
308 | --------------------------- | 307 | --------------------------- |
309 | 308 | ||
310 | What: asm/semaphore.h | 309 | What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD, |
311 | When: 2.6.26 | 310 | SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD |
312 | Why: Implementation became generic; users should now include | 311 | When: June 2009 |
313 | linux/semaphore.h instead. | 312 | Why: A newer version of the options have been introduced in 2005 that |
314 | Who: Matthew Wilcox <willy@linux.intel.com> | 313 | removes the limitions of the old API. The sctp library has been |
314 | converted to use these new options at the same time. Any user | ||
315 | space app that directly uses the old options should convert to using | ||
316 | the new options. | ||
317 | Who: Vlad Yasevich <vladislav.yasevich@hp.com> | ||
315 | 318 | ||
316 | --------------------------- | 319 | --------------------------- |
317 | 320 | ||
@@ -321,3 +324,23 @@ Why: This option was introduced just to allow older lm-sensors userspace | |||
321 | to keep working over the upgrade to 2.6.26. At the scheduled time of | 324 | to keep working over the upgrade to 2.6.26. At the scheduled time of |
322 | removal fixed lm-sensors (2.x or 3.x) should be readily available. | 325 | removal fixed lm-sensors (2.x or 3.x) should be readily available. |
323 | Who: Rene Herman <rene.herman@gmail.com> | 326 | Who: Rene Herman <rene.herman@gmail.com> |
327 | |||
328 | --------------------------- | ||
329 | |||
330 | What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS | ||
331 | (in net/core/net-sysfs.c) | ||
332 | When: After the only user (hal) has seen a release with the patches | ||
333 | for enough time, probably some time in 2010. | ||
334 | Why: Over 1K .text/.data size reduction, data is available in other | ||
335 | ways (ioctls) | ||
336 | Who: Johannes Berg <johannes@sipsolutions.net> | ||
337 | |||
338 | --------------------------- | ||
339 | |||
340 | What: CONFIG_NF_CT_ACCT | ||
341 | When: 2.6.29 | ||
342 | Why: Accounting can now be enabled/disabled without kernel recompilation. | ||
343 | Currently used only to set a default value for a feature that is also | ||
344 | controlled by a kernel/module/sysfs/sysctl parameter. | ||
345 | Who: Krzysztof Piotr Oledzki <ole@ans.pl> | ||
346 | |||
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 8b22d7d8b991..680fb566b928 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking | |||
@@ -510,6 +510,7 @@ prototypes: | |||
510 | void (*close)(struct vm_area_struct*); | 510 | void (*close)(struct vm_area_struct*); |
511 | int (*fault)(struct vm_area_struct*, struct vm_fault *); | 511 | int (*fault)(struct vm_area_struct*, struct vm_fault *); |
512 | int (*page_mkwrite)(struct vm_area_struct *, struct page *); | 512 | int (*page_mkwrite)(struct vm_area_struct *, struct page *); |
513 | int (*access)(struct vm_area_struct *, unsigned long, void*, int, int); | ||
513 | 514 | ||
514 | locking rules: | 515 | locking rules: |
515 | BKL mmap_sem PageLocked(page) | 516 | BKL mmap_sem PageLocked(page) |
@@ -517,6 +518,7 @@ open: no yes | |||
517 | close: no yes | 518 | close: no yes |
518 | fault: no yes | 519 | fault: no yes |
519 | page_mkwrite: no yes no | 520 | page_mkwrite: no yes no |
521 | access: no yes | ||
520 | 522 | ||
521 | ->page_mkwrite() is called when a previously read-only page is | 523 | ->page_mkwrite() is called when a previously read-only page is |
522 | about to become writeable. The file system is responsible for | 524 | about to become writeable. The file system is responsible for |
@@ -525,6 +527,11 @@ taking to lock out truncate, the page range should be verified to be | |||
525 | within i_size. The page mapping should also be checked that it is not | 527 | within i_size. The page mapping should also be checked that it is not |
526 | NULL. | 528 | NULL. |
527 | 529 | ||
530 | ->access() is called when get_user_pages() fails in | ||
531 | acces_process_vm(), typically used to debug a process through | ||
532 | /proc/pid/mem or ptrace. This function is needed only for | ||
533 | VM_IO | VM_PFNMAP VMAs. | ||
534 | |||
528 | ================================================================================ | 535 | ================================================================================ |
529 | Dubious stuff | 536 | Dubious stuff |
530 | 537 | ||
diff --git a/Documentation/filesystems/bfs.txt b/Documentation/filesystems/bfs.txt index ea825e178e79..78043d5a8fc3 100644 --- a/Documentation/filesystems/bfs.txt +++ b/Documentation/filesystems/bfs.txt | |||
@@ -26,11 +26,11 @@ You can simplify mounting by just typing: | |||
26 | 26 | ||
27 | this will allocate the first available loopback device (and load loop.o | 27 | this will allocate the first available loopback device (and load loop.o |
28 | kernel module if necessary) automatically. If the loopback driver is not | 28 | kernel module if necessary) automatically. If the loopback driver is not |
29 | loaded automatically, make sure that your kernel is compiled with kmod | 29 | loaded automatically, make sure that you have compiled the module and |
30 | support (CONFIG_KMOD) enabled. Beware that umount will not | 30 | that modprobe is functioning. Beware that umount will not deallocate |
31 | deallocate /dev/loopN device if /etc/mtab file on your system is a | 31 | /dev/loopN device if /etc/mtab file on your system is a symbolic link to |
32 | symbolic link to /proc/mounts. You will need to do it manually using | 32 | /proc/mounts. You will need to do it manually using "-d" switch of |
33 | "-d" switch of losetup(8). Read losetup(8) manpage for more info. | 33 | losetup(8). Read losetup(8) manpage for more info. |
34 | 34 | ||
35 | To create the BFS image under UnixWare you need to find out first which | 35 | To create the BFS image under UnixWare you need to find out first which |
36 | slice contains it. The command prtvtoc(1M) is your friend: | 36 | slice contains it. The command prtvtoc(1M) is your friend: |
diff --git a/Documentation/filesystems/configfs/configfs_example.c b/Documentation/filesystems/configfs/configfs_example.c index 25151fd5c2c6..039648791701 100644 --- a/Documentation/filesystems/configfs/configfs_example.c +++ b/Documentation/filesystems/configfs/configfs_example.c | |||
@@ -279,7 +279,7 @@ static struct config_item *simple_children_make_item(struct config_group *group, | |||
279 | 279 | ||
280 | simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); | 280 | simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); |
281 | if (!simple_child) | 281 | if (!simple_child) |
282 | return NULL; | 282 | return ERR_PTR(-ENOMEM); |
283 | 283 | ||
284 | 284 | ||
285 | config_item_init_type_name(&simple_child->item, name, | 285 | config_item_init_type_name(&simple_child->item, name, |
@@ -366,7 +366,7 @@ static struct config_group *group_children_make_group(struct config_group *group | |||
366 | simple_children = kzalloc(sizeof(struct simple_children), | 366 | simple_children = kzalloc(sizeof(struct simple_children), |
367 | GFP_KERNEL); | 367 | GFP_KERNEL); |
368 | if (!simple_children) | 368 | if (!simple_children) |
369 | return NULL; | 369 | return ERR_PTR(-ENOMEM); |
370 | 370 | ||
371 | 371 | ||
372 | config_group_init_type_name(&simple_children->group, name, | 372 | config_group_init_type_name(&simple_children->group, name, |
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 0c5086db8352..80e193d82e2e 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt | |||
@@ -13,72 +13,93 @@ Mailing list: linux-ext4@vger.kernel.org | |||
13 | 1. Quick usage instructions: | 13 | 1. Quick usage instructions: |
14 | =========================== | 14 | =========================== |
15 | 15 | ||
16 | - Grab updated e2fsprogs from | 16 | - Compile and install the latest version of e2fsprogs (as of this |
17 | ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim/ | 17 | writing version 1.41) from: |
18 | This is a patchset on top of e2fsprogs-1.39, which can be found at | 18 | |
19 | http://sourceforge.net/project/showfiles.php?group_id=2406 | ||
20 | |||
21 | or | ||
22 | |||
19 | ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/ | 23 | ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/ |
20 | 24 | ||
21 | - It's still mke2fs -j /dev/hda1 | 25 | or grab the latest git repository from: |
26 | |||
27 | git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git | ||
28 | |||
29 | - Create a new filesystem using the ext4dev filesystem type: | ||
30 | |||
31 | # mke2fs -t ext4dev /dev/hda1 | ||
32 | |||
33 | Or configure an existing ext3 filesystem to support extents and set | ||
34 | the test_fs flag to indicate that it's ok for an in-development | ||
35 | filesystem to touch this filesystem: | ||
22 | 36 | ||
23 | - mount /dev/hda1 /wherever -t ext4dev | 37 | # tune2fs -O extents -E test_fs /dev/hda1 |
24 | 38 | ||
25 | - To enable extents, | 39 | If the filesystem was created with 128 byte inodes, it can be |
40 | converted to use 256 byte for greater efficiency via: | ||
26 | 41 | ||
27 | mount /dev/hda1 /wherever -t ext4dev -o extents | 42 | # tune2fs -I 256 /dev/hda1 |
28 | 43 | ||
29 | - The filesystem is compatible with the ext3 driver until you add a file | 44 | (Note: we currently do not have tools to convert an ext4dev |
30 | which has extents (ie: `mount -o extents', then create a file). | 45 | filesystem back to ext3; so please do not do try this on production |
46 | filesystems.) | ||
31 | 47 | ||
32 | NOTE: The "extents" mount flag is temporary. It will soon go away and | 48 | - Mounting: |
33 | extents will be enabled by the "-o extents" flag to mke2fs or tune2fs | 49 | |
50 | # mount -t ext4dev /dev/hda1 /wherever | ||
34 | 51 | ||
35 | - When comparing performance with other filesystems, remember that | 52 | - When comparing performance with other filesystems, remember that |
36 | ext3/4 by default offers higher data integrity guarantees than most. So | 53 | ext3/4 by default offers higher data integrity guarantees than most. |
37 | when comparing with a metadata-only journalling filesystem, use `mount -o | 54 | So when comparing with a metadata-only journalling filesystem, such |
38 | data=writeback'. And you might as well use `mount -o nobh' too along | 55 | as ext3, use `mount -o data=writeback'. And you might as well use |
39 | with it. Making the journal larger than the mke2fs default often helps | 56 | `mount -o nobh' too along with it. Making the journal larger than |
40 | performance with metadata-intensive workloads. | 57 | the mke2fs default often helps performance with metadata-intensive |
58 | workloads. | ||
41 | 59 | ||
42 | 2. Features | 60 | 2. Features |
43 | =========== | 61 | =========== |
44 | 62 | ||
45 | 2.1 Currently available | 63 | 2.1 Currently available |
46 | 64 | ||
47 | * ability to use filesystems > 16TB | 65 | * ability to use filesystems > 16TB (e2fsprogs support not available yet) |
48 | * extent format reduces metadata overhead (RAM, IO for access, transactions) | 66 | * extent format reduces metadata overhead (RAM, IO for access, transactions) |
49 | * extent format more robust in face of on-disk corruption due to magics, | 67 | * extent format more robust in face of on-disk corruption due to magics, |
50 | * internal redunancy in tree | 68 | * internal redunancy in tree |
51 | 69 | * improved file allocation (multi-block alloc) | |
52 | 2.1 Previously available, soon to be enabled by default by "mkefs.ext4": | 70 | * fix 32000 subdirectory limit |
53 | 71 | * nsec timestamps for mtime, atime, ctime, create time | |
54 | * dir_index and resize inode will be on by default | 72 | * inode version field on disk (NFSv4, Lustre) |
55 | * large inodes will be used by default for fast EAs, nsec timestamps, etc | 73 | * reduced e2fsck time via uninit_bg feature |
74 | * journal checksumming for robustness, performance | ||
75 | * persistent file preallocation (e.g for streaming media, databases) | ||
76 | * ability to pack bitmaps and inode tables into larger virtual groups via the | ||
77 | flex_bg feature | ||
78 | * large file support | ||
79 | * Inode allocation using large virtual block groups via flex_bg | ||
80 | * delayed allocation | ||
81 | * large block (up to pagesize) support | ||
82 | * efficent new ordered mode in JBD2 and ext4(avoid using buffer head to force | ||
83 | the ordering) | ||
56 | 84 | ||
57 | 2.2 Candidate features for future inclusion | 85 | 2.2 Candidate features for future inclusion |
58 | 86 | ||
59 | There are several under discussion, whether they all make it in is | 87 | * Online defrag (patches available but not well tested) |
60 | partly a function of how much time everyone has to work on them: | 88 | * reduced mke2fs time via lazy itable initialization in conjuction with |
89 | the uninit_bg feature (capability to do this is available in e2fsprogs | ||
90 | but a kernel thread to do lazy zeroing of unused inode table blocks | ||
91 | after filesystem is first mounted is required for safety) | ||
61 | 92 | ||
62 | * improved file allocation (multi-block alloc, delayed alloc; basically done) | 93 | There are several others under discussion, whether they all make it in is |
63 | * fix 32000 subdirectory limit (patch exists, needs some e2fsck work) | 94 | partly a function of how much time everyone has to work on them. Features like |
64 | * nsec timestamps for mtime, atime, ctime, create time (patch exists, | 95 | metadata checksumming have been discussed and planned for a bit but no patches |
65 | needs some e2fsck work) | 96 | exist yet so I'm not sure they're in the near-term roadmap. |
66 | * inode version field on disk (NFSv4, Lustre; prototype exists) | ||
67 | * reduced mke2fs/e2fsck time via uninitialized groups (prototype exists) | ||
68 | * journal checksumming for robustness, performance (prototype exists) | ||
69 | * persistent file preallocation (e.g for streaming media, databases) | ||
70 | 97 | ||
71 | Features like metadata checksumming have been discussed and planned for | 98 | The big performance win will come with mballoc, delalloc and flex_bg |
72 | a bit but no patches exist yet so I'm not sure they're in the near-term | 99 | grouping of bitmaps and inode tables. Some test results available here: |
73 | roadmap. | ||
74 | 100 | ||
75 | The big performance win will come with mballoc and delalloc. CFS has | 101 | - http://www.bullopensource.org/ext4/20080530/ffsb-write-2.6.26-rc2.html |
76 | been using mballoc for a few years already with Lustre, and IBM + Bull | 102 | - http://www.bullopensource.org/ext4/20080530/ffsb-readwrite-2.6.26-rc2.html |
77 | did a lot of benchmarking on it. The reason it isn't in the first set of | ||
78 | patches is partly a manageability issue, and partly because it doesn't | ||
79 | directly affect the on-disk format (outside of much better allocation) | ||
80 | so it isn't critical to get into the first round of changes. I believe | ||
81 | Alex is working on a new set of patches right now. | ||
82 | 103 | ||
83 | 3. Options | 104 | 3. Options |
84 | ========== | 105 | ========== |
@@ -222,9 +243,11 @@ stripe=n Number of filesystem blocks that mballoc will try | |||
222 | to use for allocation size and alignment. For RAID5/6 | 243 | to use for allocation size and alignment. For RAID5/6 |
223 | systems this should be the number of data | 244 | systems this should be the number of data |
224 | disks * RAID chunk size in file system blocks. | 245 | disks * RAID chunk size in file system blocks. |
225 | 246 | delalloc (*) Deferring block allocation until write-out time. | |
247 | nodelalloc Disable delayed allocation. Blocks are allocation | ||
248 | when data is copied from user to page cache. | ||
226 | Data Mode | 249 | Data Mode |
227 | --------- | 250 | ========= |
228 | There are 3 different data modes: | 251 | There are 3 different data modes: |
229 | 252 | ||
230 | * writeback mode | 253 | * writeback mode |
@@ -236,10 +259,10 @@ typically provide the best ext4 performance. | |||
236 | 259 | ||
237 | * ordered mode | 260 | * ordered mode |
238 | In data=ordered mode, ext4 only officially journals metadata, but it logically | 261 | In data=ordered mode, ext4 only officially journals metadata, but it logically |
239 | groups metadata and data blocks into a single unit called a transaction. When | 262 | groups metadata information related to data changes with the data blocks into a |
240 | it's time to write the new metadata out to disk, the associated data blocks | 263 | single unit called a transaction. When it's time to write the new metadata |
241 | are written first. In general, this mode performs slightly slower than | 264 | out to disk, the associated data blocks are written first. In general, |
242 | writeback but significantly faster than journal mode. | 265 | this mode performs slightly slower than writeback but significantly faster than journal mode. |
243 | 266 | ||
244 | * journal mode | 267 | * journal mode |
245 | data=journal mode provides full data and metadata journaling. All new data is | 268 | data=journal mode provides full data and metadata journaling. All new data is |
@@ -247,7 +270,8 @@ written to the journal first, and then to its final location. | |||
247 | In the event of a crash, the journal can be replayed, bringing both data and | 270 | In the event of a crash, the journal can be replayed, bringing both data and |
248 | metadata into a consistent state. This mode is the slowest except when data | 271 | metadata into a consistent state. This mode is the slowest except when data |
249 | needs to be read from and written to disk at the same time where it | 272 | needs to be read from and written to disk at the same time where it |
250 | outperforms all others modes. | 273 | outperforms all others modes. Curently ext4 does not have delayed |
274 | allocation support if this data journalling mode is selected. | ||
251 | 275 | ||
252 | References | 276 | References |
253 | ========== | 277 | ========== |
@@ -256,7 +280,8 @@ kernel source: <file:fs/ext4/> | |||
256 | <file:fs/jbd2/> | 280 | <file:fs/jbd2/> |
257 | 281 | ||
258 | programs: http://e2fsprogs.sourceforge.net/ | 282 | programs: http://e2fsprogs.sourceforge.net/ |
259 | http://ext2resize.sourceforge.net | ||
260 | 283 | ||
261 | useful links: http://fedoraproject.org/wiki/ext3-devel | 284 | useful links: http://fedoraproject.org/wiki/ext3-devel |
262 | http://www.bullopensource.org/ext4/ | 285 | http://www.bullopensource.org/ext4/ |
286 | http://ext4.wiki.kernel.org/index.php/Main_Page | ||
287 | http://fedoraproject.org/wiki/Features/Ext4 | ||
diff --git a/Documentation/filesystems/gfs2-glocks.txt b/Documentation/filesystems/gfs2-glocks.txt new file mode 100644 index 000000000000..4dae9a3840bf --- /dev/null +++ b/Documentation/filesystems/gfs2-glocks.txt | |||
@@ -0,0 +1,114 @@ | |||
1 | Glock internal locking rules | ||
2 | ------------------------------ | ||
3 | |||
4 | This documents the basic principles of the glock state machine | ||
5 | internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h) | ||
6 | has two main (internal) locks: | ||
7 | |||
8 | 1. A spinlock (gl_spin) which protects the internal state such | ||
9 | as gl_state, gl_target and the list of holders (gl_holders) | ||
10 | 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other | ||
11 | threads from making calls to the DLM, etc. at the same time. If a | ||
12 | thread takes this lock, it must then call run_queue (usually via the | ||
13 | workqueue) when it releases it in order to ensure any pending tasks | ||
14 | are completed. | ||
15 | |||
16 | The gl_holders list contains all the queued lock requests (not | ||
17 | just the holders) associated with the glock. If there are any | ||
18 | held locks, then they will be contiguous entries at the head | ||
19 | of the list. Locks are granted in strictly the order that they | ||
20 | are queued, except for those marked LM_FLAG_PRIORITY which are | ||
21 | used only during recovery, and even then only for journal locks. | ||
22 | |||
23 | There are three lock states that users of the glock layer can request, | ||
24 | namely shared (SH), deferred (DF) and exclusive (EX). Those translate | ||
25 | to the following DLM lock modes: | ||
26 | |||
27 | Glock mode | DLM lock mode | ||
28 | ------------------------------ | ||
29 | UN | IV/NL Unlocked (no DLM lock associated with glock) or NL | ||
30 | SH | PR (Protected read) | ||
31 | DF | CW (Concurrent write) | ||
32 | EX | EX (Exclusive) | ||
33 | |||
34 | Thus DF is basically a shared mode which is incompatible with the "normal" | ||
35 | shared lock mode, SH. In GFS2 the DF mode is used exclusively for direct I/O | ||
36 | operations. The glocks are basically a lock plus some routines which deal | ||
37 | with cache management. The following rules apply for the cache: | ||
38 | |||
39 | Glock mode | Cache data | Cache Metadata | Dirty Data | Dirty Metadata | ||
40 | -------------------------------------------------------------------------- | ||
41 | UN | No | No | No | No | ||
42 | SH | Yes | Yes | No | No | ||
43 | DF | No | Yes | No | No | ||
44 | EX | Yes | Yes | Yes | Yes | ||
45 | |||
46 | These rules are implemented using the various glock operations which | ||
47 | are defined for each type of glock. Not all types of glocks use | ||
48 | all the modes. Only inode glocks use the DF mode for example. | ||
49 | |||
50 | Table of glock operations and per type constants: | ||
51 | |||
52 | Field | Purpose | ||
53 | ---------------------------------------------------------------------------- | ||
54 | go_xmote_th | Called before remote state change (e.g. to sync dirty data) | ||
55 | go_xmote_bh | Called after remote state change (e.g. to refill cache) | ||
56 | go_inval | Called if remote state change requires invalidating the cache | ||
57 | go_demote_ok | Returns boolean value of whether its ok to demote a glock | ||
58 | | (e.g. checks timeout, and that there is no cached data) | ||
59 | go_lock | Called for the first local holder of a lock | ||
60 | go_unlock | Called on the final local unlock of a lock | ||
61 | go_dump | Called to print content of object for debugfs file, or on | ||
62 | | error to dump glock to the log. | ||
63 | go_type; | The type of the glock, LM_TYPE_..... | ||
64 | go_min_hold_time | The minimum hold time | ||
65 | |||
66 | The minimum hold time for each lock is the time after a remote lock | ||
67 | grant for which we ignore remote demote requests. This is in order to | ||
68 | prevent a situation where locks are being bounced around the cluster | ||
69 | from node to node with none of the nodes making any progress. This | ||
70 | tends to show up most with shared mmaped files which are being written | ||
71 | to by multiple nodes. By delaying the demotion in response to a | ||
72 | remote callback, that gives the userspace program time to make | ||
73 | some progress before the pages are unmapped. | ||
74 | |||
75 | There is a plan to try and remove the go_lock and go_unlock callbacks | ||
76 | if possible, in order to try and speed up the fast path though the locking. | ||
77 | Also, eventually we hope to make the glock "EX" mode locally shared | ||
78 | such that any local locking will be done with the i_mutex as required | ||
79 | rather than via the glock. | ||
80 | |||
81 | Locking rules for glock operations: | ||
82 | |||
83 | Operation | GLF_LOCK bit lock held | gl_spin spinlock held | ||
84 | ----------------------------------------------------------------- | ||
85 | go_xmote_th | Yes | No | ||
86 | go_xmote_bh | Yes | No | ||
87 | go_inval | Yes | No | ||
88 | go_demote_ok | Sometimes | Yes | ||
89 | go_lock | Yes | No | ||
90 | go_unlock | Yes | No | ||
91 | go_dump | Sometimes | Yes | ||
92 | |||
93 | N.B. Operations must not drop either the bit lock or the spinlock | ||
94 | if its held on entry. go_dump and do_demote_ok must never block. | ||
95 | Note that go_dump will only be called if the glock's state | ||
96 | indicates that it is caching uptodate data. | ||
97 | |||
98 | Glock locking order within GFS2: | ||
99 | |||
100 | 1. i_mutex (if required) | ||
101 | 2. Rename glock (for rename only) | ||
102 | 3. Inode glock(s) | ||
103 | (Parents before children, inodes at "same level" with same parent in | ||
104 | lock number order) | ||
105 | 4. Rgrp glock(s) (for (de)allocation operations) | ||
106 | 5. Transaction glock (via gfs2_trans_begin) for non-read operations | ||
107 | 6. Page lock (always last, very important!) | ||
108 | |||
109 | There are two glocks per inode. One deals with access to the inode | ||
110 | itself (locking order as above), and the other, known as the iopen | ||
111 | glock is used in conjunction with the i_nlink field in the inode to | ||
112 | determine the lifetime of the inode in question. Locking of inodes | ||
113 | is on a per-inode basis. Locking of rgrps is on a per rgrp basis. | ||
114 | |||
diff --git a/Documentation/filesystems/nfs-rdma.txt b/Documentation/filesystems/nfs-rdma.txt index d0ec45ae4e7d..44bd766f2e5d 100644 --- a/Documentation/filesystems/nfs-rdma.txt +++ b/Documentation/filesystems/nfs-rdma.txt | |||
@@ -5,7 +5,7 @@ | |||
5 | ################################################################################ | 5 | ################################################################################ |
6 | 6 | ||
7 | Author: NetApp and Open Grid Computing | 7 | Author: NetApp and Open Grid Computing |
8 | Date: April 15, 2008 | 8 | Date: May 29, 2008 |
9 | 9 | ||
10 | Table of Contents | 10 | Table of Contents |
11 | ~~~~~~~~~~~~~~~~~ | 11 | ~~~~~~~~~~~~~~~~~ |
@@ -60,16 +60,18 @@ Installation | |||
60 | The procedures described in this document have been tested with | 60 | The procedures described in this document have been tested with |
61 | distributions from Red Hat's Fedora Project (http://fedora.redhat.com/). | 61 | distributions from Red Hat's Fedora Project (http://fedora.redhat.com/). |
62 | 62 | ||
63 | - Install nfs-utils-1.1.1 or greater on the client | 63 | - Install nfs-utils-1.1.2 or greater on the client |
64 | 64 | ||
65 | An NFS/RDMA mount point can only be obtained by using the mount.nfs | 65 | An NFS/RDMA mount point can be obtained by using the mount.nfs command in |
66 | command in nfs-utils-1.1.1 or greater. To see which version of mount.nfs | 66 | nfs-utils-1.1.2 or greater (nfs-utils-1.1.1 was the first nfs-utils |
67 | you are using, type: | 67 | version with support for NFS/RDMA mounts, but for various reasons we |
68 | recommend using nfs-utils-1.1.2 or greater). To see which version of | ||
69 | mount.nfs you are using, type: | ||
68 | 70 | ||
69 | > /sbin/mount.nfs -V | 71 | $ /sbin/mount.nfs -V |
70 | 72 | ||
71 | If the version is less than 1.1.1 or the command does not exist, | 73 | If the version is less than 1.1.2 or the command does not exist, |
72 | then you will need to install the latest version of nfs-utils. | 74 | you should install the latest version of nfs-utils. |
73 | 75 | ||
74 | Download the latest package from: | 76 | Download the latest package from: |
75 | 77 | ||
@@ -77,22 +79,33 @@ Installation | |||
77 | 79 | ||
78 | Uncompress the package and follow the installation instructions. | 80 | Uncompress the package and follow the installation instructions. |
79 | 81 | ||
80 | If you will not be using GSS and NFSv4, the installation process | 82 | If you will not need the idmapper and gssd executables (you do not need |
81 | can be simplified by disabling these features when running configure: | 83 | these to create an NFS/RDMA enabled mount command), the installation |
84 | process can be simplified by disabling these features when running | ||
85 | configure: | ||
82 | 86 | ||
83 | > ./configure --disable-gss --disable-nfsv4 | 87 | $ ./configure --disable-gss --disable-nfsv4 |
84 | 88 | ||
85 | For more information on this see the package's README and INSTALL files. | 89 | To build nfs-utils you will need the tcp_wrappers package installed. For |
90 | more information on this see the package's README and INSTALL files. | ||
86 | 91 | ||
87 | After building the nfs-utils package, there will be a mount.nfs binary in | 92 | After building the nfs-utils package, there will be a mount.nfs binary in |
88 | the utils/mount directory. This binary can be used to initiate NFS v2, v3, | 93 | the utils/mount directory. This binary can be used to initiate NFS v2, v3, |
89 | or v4 mounts. To initiate a v4 mount, the binary must be called mount.nfs4. | 94 | or v4 mounts. To initiate a v4 mount, the binary must be called |
90 | The standard technique is to create a symlink called mount.nfs4 to mount.nfs. | 95 | mount.nfs4. The standard technique is to create a symlink called |
96 | mount.nfs4 to mount.nfs. | ||
91 | 97 | ||
92 | NOTE: mount.nfs and therefore nfs-utils-1.1.1 or greater is only needed | 98 | This mount.nfs binary should be installed at /sbin/mount.nfs as follows: |
99 | |||
100 | $ sudo cp utils/mount/mount.nfs /sbin/mount.nfs | ||
101 | |||
102 | In this location, mount.nfs will be invoked automatically for NFS mounts | ||
103 | by the system mount commmand. | ||
104 | |||
105 | NOTE: mount.nfs and therefore nfs-utils-1.1.2 or greater is only needed | ||
93 | on the NFS client machine. You do not need this specific version of | 106 | on the NFS client machine. You do not need this specific version of |
94 | nfs-utils on the server. Furthermore, only the mount.nfs command from | 107 | nfs-utils on the server. Furthermore, only the mount.nfs command from |
95 | nfs-utils-1.1.1 is needed on the client. | 108 | nfs-utils-1.1.2 is needed on the client. |
96 | 109 | ||
97 | - Install a Linux kernel with NFS/RDMA | 110 | - Install a Linux kernel with NFS/RDMA |
98 | 111 | ||
@@ -156,8 +169,8 @@ Check RDMA and NFS Setup | |||
156 | this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel | 169 | this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel |
157 | card: | 170 | card: |
158 | 171 | ||
159 | > modprobe ib_mthca | 172 | $ modprobe ib_mthca |
160 | > modprobe ib_ipoib | 173 | $ modprobe ib_ipoib |
161 | 174 | ||
162 | If you are using InfiniBand, make sure there is a Subnet Manager (SM) | 175 | If you are using InfiniBand, make sure there is a Subnet Manager (SM) |
163 | running on the network. If your IB switch has an embedded SM, you can | 176 | running on the network. If your IB switch has an embedded SM, you can |
@@ -166,7 +179,7 @@ Check RDMA and NFS Setup | |||
166 | 179 | ||
167 | If an SM is running on your network, you should see the following: | 180 | If an SM is running on your network, you should see the following: |
168 | 181 | ||
169 | > cat /sys/class/infiniband/driverX/ports/1/state | 182 | $ cat /sys/class/infiniband/driverX/ports/1/state |
170 | 4: ACTIVE | 183 | 4: ACTIVE |
171 | 184 | ||
172 | where driverX is mthca0, ipath5, ehca3, etc. | 185 | where driverX is mthca0, ipath5, ehca3, etc. |
@@ -174,10 +187,10 @@ Check RDMA and NFS Setup | |||
174 | To further test the InfiniBand software stack, use IPoIB (this | 187 | To further test the InfiniBand software stack, use IPoIB (this |
175 | assumes you have two IB hosts named host1 and host2): | 188 | assumes you have two IB hosts named host1 and host2): |
176 | 189 | ||
177 | host1> ifconfig ib0 a.b.c.x | 190 | host1$ ifconfig ib0 a.b.c.x |
178 | host2> ifconfig ib0 a.b.c.y | 191 | host2$ ifconfig ib0 a.b.c.y |
179 | host1> ping a.b.c.y | 192 | host1$ ping a.b.c.y |
180 | host2> ping a.b.c.x | 193 | host2$ ping a.b.c.x |
181 | 194 | ||
182 | For other device types, follow the appropriate procedures. | 195 | For other device types, follow the appropriate procedures. |
183 | 196 | ||
@@ -202,11 +215,11 @@ NFS/RDMA Setup | |||
202 | /vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash) | 215 | /vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash) |
203 | /vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash) | 216 | /vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash) |
204 | 217 | ||
205 | The IP address(es) is(are) the client's IPoIB address for an InfiniBand HCA or the | 218 | The IP address(es) is(are) the client's IPoIB address for an InfiniBand |
206 | cleint's iWARP address(es) for an RNIC. | 219 | HCA or the cleint's iWARP address(es) for an RNIC. |
207 | 220 | ||
208 | NOTE: The "insecure" option must be used because the NFS/RDMA client does not | 221 | NOTE: The "insecure" option must be used because the NFS/RDMA client does |
209 | use a reserved port. | 222 | not use a reserved port. |
210 | 223 | ||
211 | Each time a machine boots: | 224 | Each time a machine boots: |
212 | 225 | ||
@@ -214,43 +227,45 @@ NFS/RDMA Setup | |||
214 | 227 | ||
215 | For InfiniBand using a Mellanox adapter: | 228 | For InfiniBand using a Mellanox adapter: |
216 | 229 | ||
217 | > modprobe ib_mthca | 230 | $ modprobe ib_mthca |
218 | > modprobe ib_ipoib | 231 | $ modprobe ib_ipoib |
219 | > ifconfig ib0 a.b.c.d | 232 | $ ifconfig ib0 a.b.c.d |
220 | 233 | ||
221 | NOTE: use unique addresses for the client and server | 234 | NOTE: use unique addresses for the client and server |
222 | 235 | ||
223 | - Start the NFS server | 236 | - Start the NFS server |
224 | 237 | ||
225 | If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), | 238 | If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in |
226 | load the RDMA transport module: | 239 | kernel config), load the RDMA transport module: |
227 | 240 | ||
228 | > modprobe svcrdma | 241 | $ modprobe svcrdma |
229 | 242 | ||
230 | Regardless of how the server was built (module or built-in), start the server: | 243 | Regardless of how the server was built (module or built-in), start the |
244 | server: | ||
231 | 245 | ||
232 | > /etc/init.d/nfs start | 246 | $ /etc/init.d/nfs start |
233 | 247 | ||
234 | or | 248 | or |
235 | 249 | ||
236 | > service nfs start | 250 | $ service nfs start |
237 | 251 | ||
238 | Instruct the server to listen on the RDMA transport: | 252 | Instruct the server to listen on the RDMA transport: |
239 | 253 | ||
240 | > echo rdma 2050 > /proc/fs/nfsd/portlist | 254 | $ echo rdma 2050 > /proc/fs/nfsd/portlist |
241 | 255 | ||
242 | - On the client system | 256 | - On the client system |
243 | 257 | ||
244 | If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), | 258 | If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in |
245 | load the RDMA client module: | 259 | kernel config), load the RDMA client module: |
246 | 260 | ||
247 | > modprobe xprtrdma.ko | 261 | $ modprobe xprtrdma.ko |
248 | 262 | ||
249 | Regardless of how the client was built (module or built-in), issue the mount.nfs command: | 263 | Regardless of how the client was built (module or built-in), use this |
264 | command to mount the NFS/RDMA server: | ||
250 | 265 | ||
251 | > /path/to/your/mount.nfs <IPoIB-server-name-or-address>:/<export> /mnt -i -o rdma,port=2050 | 266 | $ mount -o rdma,port=2050 <IPoIB-server-name-or-address>:/<export> /mnt |
252 | 267 | ||
253 | To verify that the mount is using RDMA, run "cat /proc/mounts" and check the | 268 | To verify that the mount is using RDMA, run "cat /proc/mounts" and check |
254 | "proto" field for the given mount. | 269 | the "proto" field for the given mount. |
255 | 270 | ||
256 | Congratulations! You're using NFS/RDMA! | 271 | Congratulations! You're using NFS/RDMA! |
diff --git a/Documentation/filesystems/omfs.txt b/Documentation/filesystems/omfs.txt new file mode 100644 index 000000000000..1d0d41ff5c65 --- /dev/null +++ b/Documentation/filesystems/omfs.txt | |||
@@ -0,0 +1,106 @@ | |||
1 | Optimized MPEG Filesystem (OMFS) | ||
2 | |||
3 | Overview | ||
4 | ======== | ||
5 | |||
6 | OMFS is a filesystem created by SonicBlue for use in the ReplayTV DVR | ||
7 | and Rio Karma MP3 player. The filesystem is extent-based, utilizing | ||
8 | block sizes from 2k to 8k, with hash-based directories. This | ||
9 | filesystem driver may be used to read and write disks from these | ||
10 | devices. | ||
11 | |||
12 | Note, it is not recommended that this FS be used in place of a general | ||
13 | filesystem for your own streaming media device. Native Linux filesystems | ||
14 | will likely perform better. | ||
15 | |||
16 | More information is available at: | ||
17 | |||
18 | http://linux-karma.sf.net/ | ||
19 | |||
20 | Various utilities, including mkomfs and omfsck, are included with | ||
21 | omfsprogs, available at: | ||
22 | |||
23 | http://bobcopeland.com/karma/ | ||
24 | |||
25 | Instructions are included in its README. | ||
26 | |||
27 | Options | ||
28 | ======= | ||
29 | |||
30 | OMFS supports the following mount-time options: | ||
31 | |||
32 | uid=n - make all files owned by specified user | ||
33 | gid=n - make all files owned by specified group | ||
34 | umask=xxx - set permission umask to xxx | ||
35 | fmask=xxx - set umask to xxx for files | ||
36 | dmask=xxx - set umask to xxx for directories | ||
37 | |||
38 | Disk format | ||
39 | =========== | ||
40 | |||
41 | OMFS discriminates between "sysblocks" and normal data blocks. The sysblock | ||
42 | group consists of super block information, file metadata, directory structures, | ||
43 | and extents. Each sysblock has a header containing CRCs of the entire | ||
44 | sysblock, and may be mirrored in successive blocks on the disk. A sysblock may | ||
45 | have a smaller size than a data block, but since they are both addressed by the | ||
46 | same 64-bit block number, any remaining space in the smaller sysblock is | ||
47 | unused. | ||
48 | |||
49 | Sysblock header information: | ||
50 | |||
51 | struct omfs_header { | ||
52 | __be64 h_self; /* FS block where this is located */ | ||
53 | __be32 h_body_size; /* size of useful data after header */ | ||
54 | __be16 h_crc; /* crc-ccitt of body_size bytes */ | ||
55 | char h_fill1[2]; | ||
56 | u8 h_version; /* version, always 1 */ | ||
57 | char h_type; /* OMFS_INODE_X */ | ||
58 | u8 h_magic; /* OMFS_IMAGIC */ | ||
59 | u8 h_check_xor; /* XOR of header bytes before this */ | ||
60 | __be32 h_fill2; | ||
61 | }; | ||
62 | |||
63 | Files and directories are both represented by omfs_inode: | ||
64 | |||
65 | struct omfs_inode { | ||
66 | struct omfs_header i_head; /* header */ | ||
67 | __be64 i_parent; /* parent containing this inode */ | ||
68 | __be64 i_sibling; /* next inode in hash bucket */ | ||
69 | __be64 i_ctime; /* ctime, in milliseconds */ | ||
70 | char i_fill1[35]; | ||
71 | char i_type; /* OMFS_[DIR,FILE] */ | ||
72 | __be32 i_fill2; | ||
73 | char i_fill3[64]; | ||
74 | char i_name[OMFS_NAMELEN]; /* filename */ | ||
75 | __be64 i_size; /* size of file, in bytes */ | ||
76 | }; | ||
77 | |||
78 | Directories in OMFS are implemented as a large hash table. Filenames are | ||
79 | hashed then prepended into the bucket list beginning at OMFS_DIR_START. | ||
80 | Lookup requires hashing the filename, then seeking across i_sibling pointers | ||
81 | until a match is found on i_name. Empty buckets are represented by block | ||
82 | pointers with all-1s (~0). | ||
83 | |||
84 | A file is an omfs_inode structure followed by an extent table beginning at | ||
85 | OMFS_EXTENT_START: | ||
86 | |||
87 | struct omfs_extent_entry { | ||
88 | __be64 e_cluster; /* start location of a set of blocks */ | ||
89 | __be64 e_blocks; /* number of blocks after e_cluster */ | ||
90 | }; | ||
91 | |||
92 | struct omfs_extent { | ||
93 | __be64 e_next; /* next extent table location */ | ||
94 | __be32 e_extent_count; /* total # extents in this table */ | ||
95 | __be32 e_fill; | ||
96 | struct omfs_extent_entry e_entry; /* start of extent entries */ | ||
97 | }; | ||
98 | |||
99 | Each extent holds the block offset followed by number of blocks allocated to | ||
100 | the extent. The final extent in each table is a terminator with e_cluster | ||
101 | being ~0 and e_blocks being ones'-complement of the total number of blocks | ||
102 | in the table. | ||
103 | |||
104 | If this table overflows, a continuation inode is written and pointed to by | ||
105 | e_next. These have a header but lack the rest of the inode structure. | ||
106 | |||
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index dbc3c6a3650f..64557821ee59 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt | |||
@@ -296,6 +296,7 @@ Table 1-4: Kernel info in /proc | |||
296 | uptime System uptime | 296 | uptime System uptime |
297 | version Kernel version | 297 | version Kernel version |
298 | video bttv info of video resources (2.4) | 298 | video bttv info of video resources (2.4) |
299 | vmallocinfo Show vmalloced areas | ||
299 | .............................................................................. | 300 | .............................................................................. |
300 | 301 | ||
301 | You can, for example, check which interrupts are currently in use and what | 302 | You can, for example, check which interrupts are currently in use and what |
@@ -380,28 +381,35 @@ i386 and x86_64 platforms support the new IRQ vector displays. | |||
380 | Of some interest is the introduction of the /proc/irq directory to 2.4. | 381 | Of some interest is the introduction of the /proc/irq directory to 2.4. |
381 | It could be used to set IRQ to CPU affinity, this means that you can "hook" an | 382 | It could be used to set IRQ to CPU affinity, this means that you can "hook" an |
382 | IRQ to only one CPU, or to exclude a CPU of handling IRQs. The contents of the | 383 | IRQ to only one CPU, or to exclude a CPU of handling IRQs. The contents of the |
383 | irq subdir is one subdir for each IRQ, and one file; prof_cpu_mask | 384 | irq subdir is one subdir for each IRQ, and two files; default_smp_affinity and |
385 | prof_cpu_mask. | ||
384 | 386 | ||
385 | For example | 387 | For example |
386 | > ls /proc/irq/ | 388 | > ls /proc/irq/ |
387 | 0 10 12 14 16 18 2 4 6 8 prof_cpu_mask | 389 | 0 10 12 14 16 18 2 4 6 8 prof_cpu_mask |
388 | 1 11 13 15 17 19 3 5 7 9 | 390 | 1 11 13 15 17 19 3 5 7 9 default_smp_affinity |
389 | > ls /proc/irq/0/ | 391 | > ls /proc/irq/0/ |
390 | smp_affinity | 392 | smp_affinity |
391 | 393 | ||
392 | The contents of the prof_cpu_mask file and each smp_affinity file for each IRQ | 394 | smp_affinity is a bitmask, in which you can specify which CPUs can handle the |
393 | is the same by default: | 395 | IRQ, you can set it by doing: |
394 | 396 | ||
395 | > cat /proc/irq/0/smp_affinity | 397 | > echo 1 > /proc/irq/10/smp_affinity |
396 | ffffffff | 398 | |
399 | This means that only the first CPU will handle the IRQ, but you can also echo | ||
400 | 5 which means that only the first and fourth CPU can handle the IRQ. | ||
401 | |||
402 | The contents of each smp_affinity file is the same by default: | ||
397 | 403 | ||
398 | It's a bitmask, in which you can specify which CPUs can handle the IRQ, you can | 404 | > cat /proc/irq/0/smp_affinity |
399 | set it by doing: | 405 | ffffffff |
400 | 406 | ||
401 | > echo 1 > /proc/irq/prof_cpu_mask | 407 | The default_smp_affinity mask applies to all non-active IRQs, which are the |
408 | IRQs which have not yet been allocated/activated, and hence which lack a | ||
409 | /proc/irq/[0-9]* directory. | ||
402 | 410 | ||
403 | This means that only the first CPU will handle the IRQ, but you can also echo 5 | 411 | prof_cpu_mask specifies which CPUs are to be profiled by the system wide |
404 | which means that only the first and fourth CPU can handle the IRQ. | 412 | profiler. Default value is ffffffff (all cpus). |
405 | 413 | ||
406 | The way IRQs are routed is handled by the IO-APIC, and it's Round Robin | 414 | The way IRQs are routed is handled by the IO-APIC, and it's Round Robin |
407 | between all the CPUs which are allowed to handle it. As usual the kernel has | 415 | between all the CPUs which are allowed to handle it. As usual the kernel has |
@@ -550,6 +558,49 @@ VmallocTotal: total size of vmalloc memory area | |||
550 | VmallocUsed: amount of vmalloc area which is used | 558 | VmallocUsed: amount of vmalloc area which is used |
551 | VmallocChunk: largest contigious block of vmalloc area which is free | 559 | VmallocChunk: largest contigious block of vmalloc area which is free |
552 | 560 | ||
561 | .............................................................................. | ||
562 | |||
563 | vmallocinfo: | ||
564 | |||
565 | Provides information about vmalloced/vmaped areas. One line per area, | ||
566 | containing the virtual address range of the area, size in bytes, | ||
567 | caller information of the creator, and optional information depending | ||
568 | on the kind of area : | ||
569 | |||
570 | pages=nr number of pages | ||
571 | phys=addr if a physical address was specified | ||
572 | ioremap I/O mapping (ioremap() and friends) | ||
573 | vmalloc vmalloc() area | ||
574 | vmap vmap()ed pages | ||
575 | user VM_USERMAP area | ||
576 | vpages buffer for pages pointers was vmalloced (huge area) | ||
577 | N<node>=nr (Only on NUMA kernels) | ||
578 | Number of pages allocated on memory node <node> | ||
579 | |||
580 | > cat /proc/vmallocinfo | ||
581 | 0xffffc20000000000-0xffffc20000201000 2101248 alloc_large_system_hash+0x204 ... | ||
582 | /0x2c0 pages=512 vmalloc N0=128 N1=128 N2=128 N3=128 | ||
583 | 0xffffc20000201000-0xffffc20000302000 1052672 alloc_large_system_hash+0x204 ... | ||
584 | /0x2c0 pages=256 vmalloc N0=64 N1=64 N2=64 N3=64 | ||
585 | 0xffffc20000302000-0xffffc20000304000 8192 acpi_tb_verify_table+0x21/0x4f... | ||
586 | phys=7fee8000 ioremap | ||
587 | 0xffffc20000304000-0xffffc20000307000 12288 acpi_tb_verify_table+0x21/0x4f... | ||
588 | phys=7fee7000 ioremap | ||
589 | 0xffffc2000031d000-0xffffc2000031f000 8192 init_vdso_vars+0x112/0x210 | ||
590 | 0xffffc2000031f000-0xffffc2000032b000 49152 cramfs_uncompress_init+0x2e ... | ||
591 | /0x80 pages=11 vmalloc N0=3 N1=3 N2=2 N3=3 | ||
592 | 0xffffc2000033a000-0xffffc2000033d000 12288 sys_swapon+0x640/0xac0 ... | ||
593 | pages=2 vmalloc N1=2 | ||
594 | 0xffffc20000347000-0xffffc2000034c000 20480 xt_alloc_table_info+0xfe ... | ||
595 | /0x130 [x_tables] pages=4 vmalloc N0=4 | ||
596 | 0xffffffffa0000000-0xffffffffa000f000 61440 sys_init_module+0xc27/0x1d00 ... | ||
597 | pages=14 vmalloc N2=14 | ||
598 | 0xffffffffa000f000-0xffffffffa0014000 20480 sys_init_module+0xc27/0x1d00 ... | ||
599 | pages=4 vmalloc N1=4 | ||
600 | 0xffffffffa0014000-0xffffffffa0017000 12288 sys_init_module+0xc27/0x1d00 ... | ||
601 | pages=2 vmalloc N1=2 | ||
602 | 0xffffffffa0017000-0xffffffffa0022000 45056 sys_init_module+0xc27/0x1d00 ... | ||
603 | pages=10 vmalloc N0=10 | ||
553 | 604 | ||
554 | 1.3 IDE devices in /proc/ide | 605 | 1.3 IDE devices in /proc/ide |
555 | ---------------------------- | 606 | ---------------------------- |
@@ -880,7 +931,7 @@ group_prealloc max_to_scan mb_groups mb_history min_to_scan order2_req | |||
880 | stats stream_req | 931 | stats stream_req |
881 | 932 | ||
882 | mb_groups: | 933 | mb_groups: |
883 | This file gives the details of mutiblock allocator buddy cache of free blocks | 934 | This file gives the details of multiblock allocator buddy cache of free blocks |
884 | 935 | ||
885 | mb_history: | 936 | mb_history: |
886 | Multiblock allocation history. | 937 | Multiblock allocation history. |
@@ -1423,7 +1474,7 @@ used because pages_free(1355) is smaller than watermark + protection[2] | |||
1423 | normal page requirement. If requirement is DMA zone(index=0), protection[0] | 1474 | normal page requirement. If requirement is DMA zone(index=0), protection[0] |
1424 | (=0) is used. | 1475 | (=0) is used. |
1425 | 1476 | ||
1426 | zone[i]'s protection[j] is calculated by following exprssion. | 1477 | zone[i]'s protection[j] is calculated by following expression. |
1427 | 1478 | ||
1428 | (i < j): | 1479 | (i < j): |
1429 | zone[i]->protection[j] | 1480 | zone[i]->protection[j] |
diff --git a/Documentation/filesystems/relay.txt b/Documentation/filesystems/relay.txt index 094f2d2f38b1..510b722667ac 100644 --- a/Documentation/filesystems/relay.txt +++ b/Documentation/filesystems/relay.txt | |||
@@ -294,6 +294,16 @@ user-defined data with a channel, and is immediately available | |||
294 | (including in create_buf_file()) via chan->private_data or | 294 | (including in create_buf_file()) via chan->private_data or |
295 | buf->chan->private_data. | 295 | buf->chan->private_data. |
296 | 296 | ||
297 | Buffer-only channels | ||
298 | -------------------- | ||
299 | |||
300 | These channels have no files associated and can be created with | ||
301 | relay_open(NULL, NULL, ...). Such channels are useful in scenarios such | ||
302 | as when doing early tracing in the kernel, before the VFS is up. In these | ||
303 | cases, one may open a buffer-only channel and then call | ||
304 | relay_late_setup_files() when the kernel is ready to handle files, | ||
305 | to expose the buffered data to the userspace. | ||
306 | |||
297 | Channel 'modes' | 307 | Channel 'modes' |
298 | --------------- | 308 | --------------- |
299 | 309 | ||
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 7f27b8f840d0..9e9c348275a9 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt | |||
@@ -248,6 +248,7 @@ The top level sysfs directory looks like: | |||
248 | block/ | 248 | block/ |
249 | bus/ | 249 | bus/ |
250 | class/ | 250 | class/ |
251 | dev/ | ||
251 | devices/ | 252 | devices/ |
252 | firmware/ | 253 | firmware/ |
253 | net/ | 254 | net/ |
@@ -274,6 +275,11 @@ fs/ contains a directory for some filesystems. Currently each | |||
274 | filesystem wanting to export attributes must create its own hierarchy | 275 | filesystem wanting to export attributes must create its own hierarchy |
275 | below fs/ (see ./fuse.txt for an example). | 276 | below fs/ (see ./fuse.txt for an example). |
276 | 277 | ||
278 | dev/ contains two directories char/ and block/. Inside these two | ||
279 | directories there are symlinks named <major>:<minor>. These symlinks | ||
280 | point to the sysfs directory for the given device. /sys/dev provides a | ||
281 | quick way to lookup the sysfs interface for a device from the result of | ||
282 | a stat(2) operation. | ||
277 | 283 | ||
278 | More information can driver-model specific features can be found in | 284 | More information can driver-model specific features can be found in |
279 | Documentation/driver-model/. | 285 | Documentation/driver-model/. |
diff --git a/Documentation/filesystems/ubifs.txt b/Documentation/filesystems/ubifs.txt new file mode 100644 index 000000000000..540e9e7f59c5 --- /dev/null +++ b/Documentation/filesystems/ubifs.txt | |||
@@ -0,0 +1,164 @@ | |||
1 | Introduction | ||
2 | ============= | ||
3 | |||
4 | UBIFS file-system stands for UBI File System. UBI stands for "Unsorted | ||
5 | Block Images". UBIFS is a flash file system, which means it is designed | ||
6 | to work with flash devices. It is important to understand, that UBIFS | ||
7 | is completely different to any traditional file-system in Linux, like | ||
8 | Ext2, XFS, JFS, etc. UBIFS represents a separate class of file-systems | ||
9 | which work with MTD devices, not block devices. The other Linux | ||
10 | file-system of this class is JFFS2. | ||
11 | |||
12 | To make it more clear, here is a small comparison of MTD devices and | ||
13 | block devices. | ||
14 | |||
15 | 1 MTD devices represent flash devices and they consist of eraseblocks of | ||
16 | rather large size, typically about 128KiB. Block devices consist of | ||
17 | small blocks, typically 512 bytes. | ||
18 | 2 MTD devices support 3 main operations - read from some offset within an | ||
19 | eraseblock, write to some offset within an eraseblock, and erase a whole | ||
20 | eraseblock. Block devices support 2 main operations - read a whole | ||
21 | block and write a whole block. | ||
22 | 3 The whole eraseblock has to be erased before it becomes possible to | ||
23 | re-write its contents. Blocks may be just re-written. | ||
24 | 4 Eraseblocks become worn out after some number of erase cycles - | ||
25 | typically 100K-1G for SLC NAND and NOR flashes, and 1K-10K for MLC | ||
26 | NAND flashes. Blocks do not have the wear-out property. | ||
27 | 5 Eraseblocks may become bad (only on NAND flashes) and software should | ||
28 | deal with this. Blocks on hard drives typically do not become bad, | ||
29 | because hardware has mechanisms to substitute bad blocks, at least in | ||
30 | modern LBA disks. | ||
31 | |||
32 | It should be quite obvious why UBIFS is very different to traditional | ||
33 | file-systems. | ||
34 | |||
35 | UBIFS works on top of UBI. UBI is a separate software layer which may be | ||
36 | found in drivers/mtd/ubi. UBI is basically a volume management and | ||
37 | wear-leveling layer. It provides so called UBI volumes which is a higher | ||
38 | level abstraction than a MTD device. The programming model of UBI devices | ||
39 | is very similar to MTD devices - they still consist of large eraseblocks, | ||
40 | they have read/write/erase operations, but UBI devices are devoid of | ||
41 | limitations like wear and bad blocks (items 4 and 5 in the above list). | ||
42 | |||
43 | In a sense, UBIFS is a next generation of JFFS2 file-system, but it is | ||
44 | very different and incompatible to JFFS2. The following are the main | ||
45 | differences. | ||
46 | |||
47 | * JFFS2 works on top of MTD devices, UBIFS depends on UBI and works on | ||
48 | top of UBI volumes. | ||
49 | * JFFS2 does not have on-media index and has to build it while mounting, | ||
50 | which requires full media scan. UBIFS maintains the FS indexing | ||
51 | information on the flash media and does not require full media scan, | ||
52 | so it mounts many times faster than JFFS2. | ||
53 | * JFFS2 is a write-through file-system, while UBIFS supports write-back, | ||
54 | which makes UBIFS much faster on writes. | ||
55 | |||
56 | Similarly to JFFS2, UBIFS supports on-the-flight compression which makes | ||
57 | it possible to fit quite a lot of data to the flash. | ||
58 | |||
59 | Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts. | ||
60 | It does not need stuff like ckfs.ext2. UBIFS automatically replays its | ||
61 | journal and recovers from crashes, ensuring that the on-flash data | ||
62 | structures are consistent. | ||
63 | |||
64 | UBIFS scales logarithmically (most of the data structures it uses are | ||
65 | trees), so the mount time and memory consumption do not linearly depend | ||
66 | on the flash size, like in case of JFFS2. This is because UBIFS | ||
67 | maintains the FS index on the flash media. However, UBIFS depends on | ||
68 | UBI, which scales linearly. So overall UBI/UBIFS stack scales linearly. | ||
69 | Nevertheless, UBI/UBIFS scales considerably better than JFFS2. | ||
70 | |||
71 | The authors of UBIFS believe, that it is possible to develop UBI2 which | ||
72 | would scale logarithmically as well. UBI2 would support the same API as UBI, | ||
73 | but it would be binary incompatible to UBI. So UBIFS would not need to be | ||
74 | changed to use UBI2 | ||
75 | |||
76 | |||
77 | Mount options | ||
78 | ============= | ||
79 | |||
80 | (*) == default. | ||
81 | |||
82 | norm_unmount (*) commit on unmount; the journal is committed | ||
83 | when the file-system is unmounted so that the | ||
84 | next mount does not have to replay the journal | ||
85 | and it becomes very fast; | ||
86 | fast_unmount do not commit on unmount; this option makes | ||
87 | unmount faster, but the next mount slower | ||
88 | because of the need to replay the journal. | ||
89 | |||
90 | |||
91 | Quick usage instructions | ||
92 | ======================== | ||
93 | |||
94 | The UBI volume to mount is specified using "ubiX_Y" or "ubiX:NAME" syntax, | ||
95 | where "X" is UBI device number, "Y" is UBI volume number, and "NAME" is | ||
96 | UBI volume name. | ||
97 | |||
98 | Mount volume 0 on UBI device 0 to /mnt/ubifs: | ||
99 | $ mount -t ubifs ubi0_0 /mnt/ubifs | ||
100 | |||
101 | Mount "rootfs" volume of UBI device 0 to /mnt/ubifs ("rootfs" is volume | ||
102 | name): | ||
103 | $ mount -t ubifs ubi0:rootfs /mnt/ubifs | ||
104 | |||
105 | The following is an example of the kernel boot arguments to attach mtd0 | ||
106 | to UBI and mount volume "rootfs": | ||
107 | ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs | ||
108 | |||
109 | |||
110 | Module Parameters for Debugging | ||
111 | =============================== | ||
112 | |||
113 | When UBIFS has been compiled with debugging enabled, there are 3 module | ||
114 | parameters that are available to control aspects of testing and debugging. | ||
115 | The parameters are unsigned integers where each bit controls an option. | ||
116 | The parameters are: | ||
117 | |||
118 | debug_msgs Selects which debug messages to display, as follows: | ||
119 | |||
120 | Message Type Flag value | ||
121 | |||
122 | General messages 1 | ||
123 | Journal messages 2 | ||
124 | Mount messages 4 | ||
125 | Commit messages 8 | ||
126 | LEB search messages 16 | ||
127 | Budgeting messages 32 | ||
128 | Garbage collection messages 64 | ||
129 | Tree Node Cache (TNC) messages 128 | ||
130 | LEB properties (lprops) messages 256 | ||
131 | Input/output messages 512 | ||
132 | Log messages 1024 | ||
133 | Scan messages 2048 | ||
134 | Recovery messages 4096 | ||
135 | |||
136 | debug_chks Selects extra checks that UBIFS can do while running: | ||
137 | |||
138 | Check Flag value | ||
139 | |||
140 | General checks 1 | ||
141 | Check Tree Node Cache (TNC) 2 | ||
142 | Check indexing tree size 4 | ||
143 | Check orphan area 8 | ||
144 | Check old indexing tree 16 | ||
145 | Check LEB properties (lprops) 32 | ||
146 | Check leaf nodes and inodes 64 | ||
147 | |||
148 | debug_tsts Selects a mode of testing, as follows: | ||
149 | |||
150 | Test mode Flag value | ||
151 | |||
152 | Force in-the-gaps method 2 | ||
153 | Failure mode for recovery testing 4 | ||
154 | |||
155 | For example, set debug_msgs to 5 to display General messages and Mount | ||
156 | messages. | ||
157 | |||
158 | |||
159 | References | ||
160 | ========== | ||
161 | |||
162 | UBIFS documentation and FAQ/HOWTO at the MTD web site: | ||
163 | http://www.linux-mtd.infradead.org/doc/ubifs.html | ||
164 | http://www.linux-mtd.infradead.org/faq/ubifs.html | ||
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt index 2d5e1e582e13..bbac4f1d9056 100644 --- a/Documentation/filesystems/vfat.txt +++ b/Documentation/filesystems/vfat.txt | |||
@@ -96,6 +96,14 @@ shortname=lower|win95|winnt|mixed | |||
96 | emulate the Windows 95 rule for create. | 96 | emulate the Windows 95 rule for create. |
97 | Default setting is `lower'. | 97 | Default setting is `lower'. |
98 | 98 | ||
99 | tz=UTC -- Interpret timestamps as UTC rather than local time. | ||
100 | This option disables the conversion of timestamps | ||
101 | between local time (as used by Windows on FAT) and UTC | ||
102 | (which Linux uses internally). This is particuluarly | ||
103 | useful when mounting devices (like digital cameras) | ||
104 | that are set to UTC in order to avoid the pitfalls of | ||
105 | local time. | ||
106 | |||
99 | <bool>: 0,1,yes,no,true,false | 107 | <bool>: 0,1,yes,no,true,false |
100 | 108 | ||
101 | TODO | 109 | TODO |
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index b7522c6cbae3..c4d348dabe94 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt | |||
@@ -143,7 +143,7 @@ struct file_system_type { | |||
143 | 143 | ||
144 | The get_sb() method has the following arguments: | 144 | The get_sb() method has the following arguments: |
145 | 145 | ||
146 | struct file_system_type *fs_type: decribes the filesystem, partly initialized | 146 | struct file_system_type *fs_type: describes the filesystem, partly initialized |
147 | by the specific filesystem code | 147 | by the specific filesystem code |
148 | 148 | ||
149 | int flags: mount flags | 149 | int flags: mount flags |
@@ -895,9 +895,9 @@ struct dentry_operations { | |||
895 | iput() yourself | 895 | iput() yourself |
896 | 896 | ||
897 | d_dname: called when the pathname of a dentry should be generated. | 897 | d_dname: called when the pathname of a dentry should be generated. |
898 | Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay | 898 | Useful for some pseudo filesystems (sockfs, pipefs, ...) to delay |
899 | pathname generation. (Instead of doing it when dentry is created, | 899 | pathname generation. (Instead of doing it when dentry is created, |
900 | its done only when the path is needed.). Real filesystems probably | 900 | it's done only when the path is needed.). Real filesystems probably |
901 | dont want to use it, because their dentries are present in global | 901 | dont want to use it, because their dentries are present in global |
902 | dcache hash, so their hash should be an invariant. As no lock is | 902 | dcache hash, so their hash should be an invariant. As no lock is |
903 | held, d_dname() should not try to modify the dentry itself, unless | 903 | held, d_dname() should not try to modify the dentry itself, unless |
diff --git a/Documentation/ftrace.txt b/Documentation/ftrace.txt index 13e4bf054c38..f218f616ff6b 100644 --- a/Documentation/ftrace.txt +++ b/Documentation/ftrace.txt | |||
@@ -2,8 +2,12 @@ | |||
2 | ======================== | 2 | ======================== |
3 | 3 | ||
4 | Copyright 2008 Red Hat Inc. | 4 | Copyright 2008 Red Hat Inc. |
5 | Author: Steven Rostedt <srostedt@redhat.com> | 5 | Author: Steven Rostedt <srostedt@redhat.com> |
6 | License: The GNU Free Documentation License, Version 1.2 | ||
7 | Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton, | ||
8 | John Kacur, and David Teigland. | ||
6 | 9 | ||
10 | Written for: 2.6.27-rc1 | ||
7 | 11 | ||
8 | Introduction | 12 | Introduction |
9 | ------------ | 13 | ------------ |
@@ -15,10 +19,11 @@ issues that take place outside of user-space. | |||
15 | 19 | ||
16 | Although ftrace is the function tracer, it also includes an | 20 | Although ftrace is the function tracer, it also includes an |
17 | infrastructure that allows for other types of tracing. Some of the | 21 | infrastructure that allows for other types of tracing. Some of the |
18 | tracers that are currently in ftrace is a tracer to trace | 22 | tracers that are currently in ftrace include a tracer to trace |
19 | context switches, the time it takes for a high priority task to | 23 | context switches, the time it takes for a high priority task to |
20 | run after it was woken up, the time interrupts are disabled, and | 24 | run after it was woken up, the time interrupts are disabled, and |
21 | more. | 25 | more (ftrace allows for tracer plugins, which means that the list of |
26 | tracers can always grow). | ||
22 | 27 | ||
23 | 28 | ||
24 | The File System | 29 | The File System |
@@ -32,6 +37,8 @@ To mount the debugfs system: | |||
32 | # mkdir /debug | 37 | # mkdir /debug |
33 | # mount -t debugfs nodev /debug | 38 | # mount -t debugfs nodev /debug |
34 | 39 | ||
40 | (Note: it is more common to mount at /sys/kernel/debug, but for simplicity | ||
41 | this document will use /debug) | ||
35 | 42 | ||
36 | That's it! (assuming that you have ftrace configured into your kernel) | 43 | That's it! (assuming that you have ftrace configured into your kernel) |
37 | 44 | ||
@@ -46,21 +53,20 @@ of ftrace. Here is a list of some of the key files: | |||
46 | that is configured. | 53 | that is configured. |
47 | 54 | ||
48 | available_tracers : This holds the different types of tracers that | 55 | available_tracers : This holds the different types of tracers that |
49 | has been compiled into the kernel. The tracers | 56 | have been compiled into the kernel. The tracers |
50 | listed here can be configured by echoing in their | 57 | listed here can be configured by echoing their name |
51 | name into current_tracer. | 58 | into current_tracer. |
52 | 59 | ||
53 | tracing_enabled : This sets or displays whether the current_tracer | 60 | tracing_enabled : This sets or displays whether the current_tracer |
54 | is activated and tracing or not. Echo 0 into this | 61 | is activated and tracing or not. Echo 0 into this |
55 | file to disable the tracer or 1 (or non-zero) to | 62 | file to disable the tracer or 1 to enable it. |
56 | enable it. | ||
57 | 63 | ||
58 | trace : This file holds the output of the trace in a human readable | 64 | trace : This file holds the output of the trace in a human readable |
59 | format. | 65 | format (described below). |
60 | 66 | ||
61 | latency_trace : This file shows the same trace but the information | 67 | latency_trace : This file shows the same trace but the information |
62 | is organized more to display possible latencies | 68 | is organized more to display possible latencies |
63 | in the system. | 69 | in the system (described below). |
64 | 70 | ||
65 | trace_pipe : The output is the same as the "trace" file but this | 71 | trace_pipe : The output is the same as the "trace" file but this |
66 | file is meant to be streamed with live tracing. | 72 | file is meant to be streamed with live tracing. |
@@ -72,7 +78,7 @@ of ftrace. Here is a list of some of the key files: | |||
72 | file, it is consumed, and will not be read | 78 | file, it is consumed, and will not be read |
73 | again with a sequential read. The "trace" and | 79 | again with a sequential read. The "trace" and |
74 | "latency_trace" files are static, and if the | 80 | "latency_trace" files are static, and if the |
75 | tracer isn't adding more data, they will display | 81 | tracer is not adding more data, they will display |
76 | the same information every time they are read. | 82 | the same information every time they are read. |
77 | 83 | ||
78 | iter_ctrl : This file lets the user control the amount of data | 84 | iter_ctrl : This file lets the user control the amount of data |
@@ -89,12 +95,14 @@ of ftrace. Here is a list of some of the key files: | |||
89 | 95 | ||
90 | trace_entries : This sets or displays the number of trace | 96 | trace_entries : This sets or displays the number of trace |
91 | entries each CPU buffer can hold. The tracer buffers | 97 | entries each CPU buffer can hold. The tracer buffers |
92 | are the same size for each CPU, so care must be | 98 | are the same size for each CPU. The displayed number |
93 | taken when modifying the trace_entries. The number | 99 | is the size of the CPU buffer and not total size. The |
94 | of actually entries will be the number given | 100 | trace buffers are allocated in pages (blocks of memory |
95 | times the number of possible CPUS. The buffers | 101 | that the kernel uses for allocation, usually 4 KB in size). |
96 | are saved as individual pages, and the actual entries | 102 | Since each entry is smaller than a page, if the last |
97 | will always be rounded up to entries per page. | 103 | allocated page has room for more entries than were |
104 | requested, the rest of the page is used to allocate | ||
105 | entries. | ||
98 | 106 | ||
99 | This can only be updated when the current_tracer | 107 | This can only be updated when the current_tracer |
100 | is set to "none". | 108 | is set to "none". |
@@ -107,20 +115,19 @@ of ftrace. Here is a list of some of the key files: | |||
107 | on specified CPUS. The format is a hex string | 115 | on specified CPUS. The format is a hex string |
108 | representing the CPUS. | 116 | representing the CPUS. |
109 | 117 | ||
110 | set_ftrace_filter : When dynamic ftrace is configured in, the | 118 | set_ftrace_filter : When dynamic ftrace is configured in (see the |
111 | code is dynamically modified to disable calling | 119 | section below "dynamic ftrace"), the code is dynamically |
112 | of the function profiler (mcount). This lets | 120 | modified (code text rewrite) to disable calling of the |
113 | tracing be configured in with practically no overhead | 121 | function profiler (mcount). This lets tracing be configured |
114 | in performance. This also has a side effect of | 122 | in with practically no overhead in performance. This also |
115 | enabling or disabling specific functions to be | 123 | has a side effect of enabling or disabling specific functions |
116 | traced. Echoing in names of functions into this | 124 | to be traced. Echoing names of functions into this file |
117 | file will limit the trace to only those files. | 125 | will limit the trace to only those functions. |
118 | 126 | ||
119 | set_ftrace_notrace: This has the opposite effect that | 127 | set_ftrace_notrace: This has an effect opposite to that of |
120 | set_ftrace_filter has. Any function that is added | 128 | set_ftrace_filter. Any function that is added here will not |
121 | here will not be traced. If a function exists | 129 | be traced. If a function exists in both set_ftrace_filter |
122 | in both set_ftrace_filter and set_ftrace_notrace | 130 | and set_ftrace_notrace, the function will _not_ be traced. |
123 | the function will _not_ bet traced. | ||
124 | 131 | ||
125 | available_filter_functions : When a function is encountered the first | 132 | available_filter_functions : When a function is encountered the first |
126 | time by the dynamic tracer, it is recorded and | 133 | time by the dynamic tracer, it is recorded and |
@@ -128,32 +135,31 @@ of ftrace. Here is a list of some of the key files: | |||
128 | lists the functions that have been recorded | 135 | lists the functions that have been recorded |
129 | by the dynamic tracer and these functions can | 136 | by the dynamic tracer and these functions can |
130 | be used to set the ftrace filter by the above | 137 | be used to set the ftrace filter by the above |
131 | "set_ftrace_filter" file. | 138 | "set_ftrace_filter" file. (See the section "dynamic ftrace" |
139 | below for more details). | ||
132 | 140 | ||
133 | 141 | ||
134 | The Tracers | 142 | The Tracers |
135 | ----------- | 143 | ----------- |
136 | 144 | ||
137 | Here are the list of current tracers that can be configured. | 145 | Here is the list of current tracers that may be configured. |
138 | 146 | ||
139 | ftrace - function tracer that uses mcount to trace all functions. | 147 | ftrace - function tracer that uses mcount to trace all functions. |
140 | It is possible to filter out which functions that are | ||
141 | traced when dynamic ftrace is configured in. | ||
142 | 148 | ||
143 | sched_switch - traces the context switches between tasks. | 149 | sched_switch - traces the context switches between tasks. |
144 | 150 | ||
145 | irqsoff - traces the areas that disable interrupts and saves off | 151 | irqsoff - traces the areas that disable interrupts and saves |
146 | the trace with the longest max latency. | 152 | the trace with the longest max latency. |
147 | See tracing_max_latency. When a new max is recorded, | 153 | See tracing_max_latency. When a new max is recorded, |
148 | it replaces the old trace. It is best to view this | 154 | it replaces the old trace. It is best to view this |
149 | trace with the latency_trace file. | 155 | trace via the latency_trace file. |
150 | 156 | ||
151 | preemptoff - Similar to irqsoff but traces and records the time | 157 | preemptoff - Similar to irqsoff but traces and records the amount of |
152 | preemption is disabled. | 158 | time for which preemption is disabled. |
153 | 159 | ||
154 | preemptirqsoff - Similar to irqsoff and preemptoff, but traces and | 160 | preemptirqsoff - Similar to irqsoff and preemptoff, but traces and |
155 | records the largest time irqs and/or preemption is | 161 | records the largest time for which irqs and/or preemption |
156 | disabled. | 162 | is disabled. |
157 | 163 | ||
158 | wakeup - Traces and records the max latency that it takes for | 164 | wakeup - Traces and records the max latency that it takes for |
159 | the highest priority task to get scheduled after | 165 | the highest priority task to get scheduled after |
@@ -166,13 +172,13 @@ Here are the list of current tracers that can be configured. | |||
166 | Examples of using the tracer | 172 | Examples of using the tracer |
167 | ---------------------------- | 173 | ---------------------------- |
168 | 174 | ||
169 | Here are typical examples of using the tracers with only controlling | 175 | Here are typical examples of using the tracers when controlling them only |
170 | them with the debugfs interface (without using any user-land utilities). | 176 | with the debugfs interface (without using any user-land utilities). |
171 | 177 | ||
172 | Output format: | 178 | Output format: |
173 | -------------- | 179 | -------------- |
174 | 180 | ||
175 | Here's an example of the output format of the file "trace" | 181 | Here is an example of the output format of the file "trace" |
176 | 182 | ||
177 | -------- | 183 | -------- |
178 | # tracer: ftrace | 184 | # tracer: ftrace |
@@ -184,14 +190,15 @@ Here's an example of the output format of the file "trace" | |||
184 | bash-4251 [01] 10152.583855: _atomic_dec_and_lock <-dput | 190 | bash-4251 [01] 10152.583855: _atomic_dec_and_lock <-dput |
185 | -------- | 191 | -------- |
186 | 192 | ||
187 | A header is printed with the trace that is represented. In this case | 193 | A header is printed with the tracer name that is represented by the trace. |
188 | the tracer is "ftrace". Then a header showing the format. Task name | 194 | In this case the tracer is "ftrace". Then a header showing the format. Task |
189 | "bash", the task PID "4251", the CPU that it was running on | 195 | name "bash", the task PID "4251", the CPU that it was running on |
190 | "01", the timestamp in <secs>.<usecs> format, the function name that was | 196 | "01", the timestamp in <secs>.<usecs> format, the function name that was |
191 | traced "path_put" and the parent function that called this function | 197 | traced "path_put" and the parent function that called this function |
192 | "path_walk". | 198 | "path_walk". The timestamp is the time at which the function was |
199 | entered. | ||
193 | 200 | ||
194 | The sched_switch tracer also includes tracing of task wake ups and | 201 | The sched_switch tracer also includes tracing of task wakeups and |
195 | context switches. | 202 | context switches. |
196 | 203 | ||
197 | ksoftirqd/1-7 [01] 1453.070013: 7:115:R + 2916:115:S | 204 | ksoftirqd/1-7 [01] 1453.070013: 7:115:R + 2916:115:S |
@@ -201,7 +208,7 @@ context switches. | |||
201 | kondemand/1-2916 [01] 1453.070013: 2916:115:S ==> 7:115:R | 208 | kondemand/1-2916 [01] 1453.070013: 2916:115:S ==> 7:115:R |
202 | ksoftirqd/1-7 [01] 1453.070013: 7:115:S ==> 0:140:R | 209 | ksoftirqd/1-7 [01] 1453.070013: 7:115:S ==> 0:140:R |
203 | 210 | ||
204 | Wake ups are represented by a "+" and the context switches show | 211 | Wake ups are represented by a "+" and the context switches are shown as |
205 | "==>". The format is: | 212 | "==>". The format is: |
206 | 213 | ||
207 | Context switches: | 214 | Context switches: |
@@ -216,7 +223,7 @@ Wake ups are represented by a "+" and the context switches show | |||
216 | 223 | ||
217 | <pid>:<prio>:<state> + <pid>:<prio>:<state> | 224 | <pid>:<prio>:<state> + <pid>:<prio>:<state> |
218 | 225 | ||
219 | The prio is the internal kernel priority, which is inverse to the | 226 | The prio is the internal kernel priority, which is the inverse of the |
220 | priority that is usually displayed by user-space tools. Zero represents | 227 | priority that is usually displayed by user-space tools. Zero represents |
221 | the highest priority (99). Prio 100 starts the "nice" priorities with | 228 | the highest priority (99). Prio 100 starts the "nice" priorities with |
222 | 100 being equal to nice -20 and 139 being nice 19. The prio "140" is | 229 | 100 being equal to nice -20 and 139 being nice 19. The prio "140" is |
@@ -227,7 +234,7 @@ Latency trace format | |||
227 | -------------------- | 234 | -------------------- |
228 | 235 | ||
229 | For traces that display latency times, the latency_trace file gives | 236 | For traces that display latency times, the latency_trace file gives |
230 | a bit more information to see why a latency happened. Here's a typical | 237 | somewhat more information to see why a latency happened. Here is a typical |
231 | trace. | 238 | trace. |
232 | 239 | ||
233 | # tracer: irqsoff | 240 | # tracer: irqsoff |
@@ -255,21 +262,20 @@ irqsoff latency trace v1.1.5 on 2.6.26-rc8 | |||
255 | <idle>-0 0d.s1 98us : trace_hardirqs_on (do_softirq) | 262 | <idle>-0 0d.s1 98us : trace_hardirqs_on (do_softirq) |
256 | 263 | ||
257 | 264 | ||
258 | vim:ft=help | ||
259 | |||
260 | 265 | ||
261 | This shows that the current tracer is "irqsoff" tracing the time | 266 | This shows that the current tracer is "irqsoff" tracing the time for which |
262 | interrupts are disabled. It gives the trace version and the kernel | 267 | interrupts were disabled. It gives the trace version and the version |
263 | this was executed on (2.6.26-rc8). Then it displays the max latency | 268 | of the kernel upon which this was executed on (2.6.26-rc8). Then it displays |
264 | in microsecs (97 us). The number of trace entries displayed | 269 | the max latency in microsecs (97 us). The number of trace entries displayed |
265 | by the total number recorded (both are three: #3/3). The type of | 270 | and the total number recorded (both are three: #3/3). The type of |
266 | preemption that was used (PREEMPT). VP, KP, SP, and HP are always zero | 271 | preemption that was used (PREEMPT). VP, KP, SP, and HP are always zero |
267 | and reserved for later use. #P is the number of online CPUS (#P:2). | 272 | and are reserved for later use. #P is the number of online CPUS (#P:2). |
268 | 273 | ||
269 | The task is the process that was running when the latency happened. | 274 | The task is the process that was running when the latency occurred. |
270 | (swapper pid: 0). | 275 | (swapper pid: 0). |
271 | 276 | ||
272 | The start and stop that caused the latencies: | 277 | The start and stop (the functions in which the interrupts were disabled and |
278 | enabled respectively) that caused the latencies: | ||
273 | 279 | ||
274 | apic_timer_interrupt is where the interrupts were disabled. | 280 | apic_timer_interrupt is where the interrupts were disabled. |
275 | do_softirq is where they were enabled again. | 281 | do_softirq is where they were enabled again. |
@@ -281,14 +287,14 @@ explains which is which. | |||
281 | 287 | ||
282 | pid: The PID of that process. | 288 | pid: The PID of that process. |
283 | 289 | ||
284 | CPU#: The CPU that the process was running on. | 290 | CPU#: The CPU which the process was running on. |
285 | 291 | ||
286 | irqs-off: 'd' interrupts are disabled. '.' otherwise. | 292 | irqs-off: 'd' interrupts are disabled. '.' otherwise. |
287 | 293 | ||
288 | need-resched: 'N' task need_resched is set, '.' otherwise. | 294 | need-resched: 'N' task need_resched is set, '.' otherwise. |
289 | 295 | ||
290 | hardirq/softirq: | 296 | hardirq/softirq: |
291 | 'H' - hard irq happened inside a softirq. | 297 | 'H' - hard irq occurred inside a softirq. |
292 | 'h' - hard irq is running | 298 | 'h' - hard irq is running |
293 | 's' - soft irq is running | 299 | 's' - soft irq is running |
294 | '.' - normal context. | 300 | '.' - normal context. |
@@ -297,13 +303,13 @@ explains which is which. | |||
297 | 303 | ||
298 | The above is mostly meaningful for kernel developers. | 304 | The above is mostly meaningful for kernel developers. |
299 | 305 | ||
300 | time: This differs from the trace output where as the trace output | 306 | time: This differs from the trace file output. The trace file output |
301 | contained a absolute timestamp. This timestamp is relative | 307 | includes an absolute timestamp. The timestamp used by the |
302 | to the start of the first entry in the the trace. | 308 | latency_trace file is relative to the start of the trace. |
303 | 309 | ||
304 | delay: This is just to help catch your eye a bit better. And | 310 | delay: This is just to help catch your eye a bit better. And |
305 | needs to be fixed to be only relative to the same CPU. | 311 | needs to be fixed to be only relative to the same CPU. |
306 | The marks is determined by the difference between this | 312 | The marks are determined by the difference between this |
307 | current trace and the next trace. | 313 | current trace and the next trace. |
308 | '!' - greater than preempt_mark_thresh (default 100) | 314 | '!' - greater than preempt_mark_thresh (default 100) |
309 | '+' - greater than 1 microsecond | 315 | '+' - greater than 1 microsecond |
@@ -322,13 +328,13 @@ output. To see what is available, simply cat the file: | |||
322 | print-parent nosym-offset nosym-addr noverbose noraw nohex nobin \ | 328 | print-parent nosym-offset nosym-addr noverbose noraw nohex nobin \ |
323 | noblock nostacktrace nosched-tree | 329 | noblock nostacktrace nosched-tree |
324 | 330 | ||
325 | To disable one of the options, echo in the option appended with "no". | 331 | To disable one of the options, echo in the option prepended with "no". |
326 | 332 | ||
327 | echo noprint-parent > /debug/tracing/iter_ctrl | 333 | echo noprint-parent > /debug/tracing/iter_ctrl |
328 | 334 | ||
329 | To enable an option, leave off the "no". | 335 | To enable an option, leave off the "no". |
330 | 336 | ||
331 | echo sym-offest > /debug/tracing/iter_ctrl | 337 | echo sym-offset > /debug/tracing/iter_ctrl |
332 | 338 | ||
333 | Here are the available options: | 339 | Here are the available options: |
334 | 340 | ||
@@ -344,7 +350,7 @@ Here are the available options: | |||
344 | 350 | ||
345 | sym-offset - Display not only the function name, but also the offset | 351 | sym-offset - Display not only the function name, but also the offset |
346 | in the function. For example, instead of seeing just | 352 | in the function. For example, instead of seeing just |
347 | "ktime_get" you will see "ktime_get+0xb/0x20" | 353 | "ktime_get", you will see "ktime_get+0xb/0x20". |
348 | 354 | ||
349 | sym-offset: | 355 | sym-offset: |
350 | bash-4000 [01] 1477.606694: simple_strtoul+0x6/0xa0 | 356 | bash-4000 [01] 1477.606694: simple_strtoul+0x6/0xa0 |
@@ -364,7 +370,7 @@ Here are the available options: | |||
364 | user applications that can translate the raw numbers better than | 370 | user applications that can translate the raw numbers better than |
365 | having it done in the kernel. | 371 | having it done in the kernel. |
366 | 372 | ||
367 | hex - similar to raw, but the numbers will be in a hexadecimal format. | 373 | hex - Similar to raw, but the numbers will be in a hexadecimal format. |
368 | 374 | ||
369 | bin - This will print out the formats in raw binary. | 375 | bin - This will print out the formats in raw binary. |
370 | 376 | ||
@@ -380,8 +386,8 @@ Here are the available options: | |||
380 | sched_switch | 386 | sched_switch |
381 | ------------ | 387 | ------------ |
382 | 388 | ||
383 | This tracer simply records schedule switches. Here's an example | 389 | This tracer simply records schedule switches. Here is an example |
384 | on how to implement it. | 390 | of how to use it. |
385 | 391 | ||
386 | # echo sched_switch > /debug/tracing/current_tracer | 392 | # echo sched_switch > /debug/tracing/current_tracer |
387 | # echo 1 > /debug/tracing/tracing_enabled | 393 | # echo 1 > /debug/tracing/tracing_enabled |
@@ -416,8 +422,8 @@ the name of the trace and points to the options. The "FUNCTION" | |||
416 | is a misnomer since here it represents the wake ups and context | 422 | is a misnomer since here it represents the wake ups and context |
417 | switches. | 423 | switches. |
418 | 424 | ||
419 | The sched_switch only lists the wake ups (represented with '+') | 425 | The sched_switch file only lists the wake ups (represented with '+') |
420 | and context switches ('==>') with the previous task or current | 426 | and context switches ('==>') with the previous task or current task |
421 | first followed by the next task or task waking up. The format for both | 427 | first followed by the next task or task waking up. The format for both |
422 | of these is PID:KERNEL-PRIO:TASK-STATE. Remember that the KERNEL-PRIO | 428 | of these is PID:KERNEL-PRIO:TASK-STATE. Remember that the KERNEL-PRIO |
423 | is the inverse of the actual priority with zero (0) being the highest | 429 | is the inverse of the actual priority with zero (0) being the highest |
@@ -432,7 +438,8 @@ The task states are: | |||
432 | 438 | ||
433 | R - running : wants to run, may not actually be running | 439 | R - running : wants to run, may not actually be running |
434 | S - sleep : process is waiting to be woken up (handles signals) | 440 | S - sleep : process is waiting to be woken up (handles signals) |
435 | D - deep sleep : process must be woken up (ignores signals) | 441 | D - disk sleep (uninterruptible sleep) : process must be woken up |
442 | (ignores signals) | ||
436 | T - stopped : process suspended | 443 | T - stopped : process suspended |
437 | t - traced : process is being traced (with something like gdb) | 444 | t - traced : process is being traced (with something like gdb) |
438 | Z - zombie : process waiting to be cleaned up | 445 | Z - zombie : process waiting to be cleaned up |
@@ -442,8 +449,8 @@ The task states are: | |||
442 | ftrace_enabled | 449 | ftrace_enabled |
443 | -------------- | 450 | -------------- |
444 | 451 | ||
445 | The following tracers give different output depending on whether | 452 | The following tracers (listed below) give different output depending |
446 | or not the sysctl ftrace_enabled is set. To set ftrace_enabled, | 453 | on whether or not the sysctl ftrace_enabled is set. To set ftrace_enabled, |
447 | one can either use the sysctl function or set it via the proc | 454 | one can either use the sysctl function or set it via the proc |
448 | file system interface. | 455 | file system interface. |
449 | 456 | ||
@@ -470,13 +477,12 @@ interrupt from triggering or the mouse interrupt from letting the | |||
470 | kernel know of a new mouse event. The result is a latency with the | 477 | kernel know of a new mouse event. The result is a latency with the |
471 | reaction time. | 478 | reaction time. |
472 | 479 | ||
473 | The irqsoff tracer tracks the time interrupts are disabled and when | 480 | The irqsoff tracer tracks the time for which interrupts are disabled. |
474 | they are re-enabled. When a new maximum latency is hit, it saves off | 481 | When a new maximum latency is hit, the tracer saves the trace leading up |
475 | the trace so that it may be retrieved at a later time. Every time a | 482 | to that latency point so that every time a new maximum is reached, the old |
476 | new maximum in reached, the old saved trace is discarded and the new | 483 | saved trace is discarded and the new trace is saved. |
477 | trace is saved. | ||
478 | 484 | ||
479 | To reset the maximum, echo 0 into tracing_max_latency. Here's an | 485 | To reset the maximum, echo 0 into tracing_max_latency. Here is an |
480 | example: | 486 | example: |
481 | 487 | ||
482 | # echo irqsoff > /debug/tracing/current_tracer | 488 | # echo irqsoff > /debug/tracing/current_tracer |
@@ -488,14 +494,14 @@ example: | |||
488 | # cat /debug/tracing/latency_trace | 494 | # cat /debug/tracing/latency_trace |
489 | # tracer: irqsoff | 495 | # tracer: irqsoff |
490 | # | 496 | # |
491 | irqsoff latency trace v1.1.5 on 2.6.26-rc8 | 497 | irqsoff latency trace v1.1.5 on 2.6.26 |
492 | -------------------------------------------------------------------- | 498 | -------------------------------------------------------------------- |
493 | latency: 6 us, #3/3, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2) | 499 | latency: 12 us, #3/3, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2) |
494 | ----------------- | 500 | ----------------- |
495 | | task: bash-4269 (uid:0 nice:0 policy:0 rt_prio:0) | 501 | | task: bash-3730 (uid:0 nice:0 policy:0 rt_prio:0) |
496 | ----------------- | 502 | ----------------- |
497 | => started at: copy_page_range | 503 | => started at: sys_setpgid |
498 | => ended at: copy_page_range | 504 | => ended at: sys_setpgid |
499 | 505 | ||
500 | # _------=> CPU# | 506 | # _------=> CPU# |
501 | # / _-----=> irqs-off | 507 | # / _-----=> irqs-off |
@@ -506,21 +512,19 @@ irqsoff latency trace v1.1.5 on 2.6.26-rc8 | |||
506 | # ||||| delay | 512 | # ||||| delay |
507 | # cmd pid ||||| time | caller | 513 | # cmd pid ||||| time | caller |
508 | # \ / ||||| \ | / | 514 | # \ / ||||| \ | / |
509 | bash-4269 1...1 0us+: _spin_lock (copy_page_range) | 515 | bash-3730 1d... 0us : _write_lock_irq (sys_setpgid) |
510 | bash-4269 1...1 7us : _spin_unlock (copy_page_range) | 516 | bash-3730 1d..1 1us+: _write_unlock_irq (sys_setpgid) |
511 | bash-4269 1...2 7us : trace_preempt_on (copy_page_range) | 517 | bash-3730 1d..2 14us : trace_hardirqs_on (sys_setpgid) |
512 | 518 | ||
513 | 519 | ||
514 | vim:ft=help | 520 | Here we see that that we had a latency of 12 microsecs (which is |
521 | very good). The _write_lock_irq in sys_setpgid disabled interrupts. | ||
522 | The difference between the 12 and the displayed timestamp 14us occurred | ||
523 | because the clock was incremented between the time of recording the max | ||
524 | latency and the time of recording the function that had that latency. | ||
515 | 525 | ||
516 | Here we see that that we had a latency of 6 microsecs (which is | 526 | Note the above example had ftrace_enabled not set. If we set the |
517 | very good). The spin_lock in copy_page_range disabled interrupts. | 527 | ftrace_enabled, we get a much larger output: |
518 | The difference between the 6 and the displayed timestamp 7us is | ||
519 | because the clock must have incremented between the time of recording | ||
520 | the max latency and recording the function that had that latency. | ||
521 | |||
522 | Note the above had ftrace_enabled not set. If we set the ftrace_enabled | ||
523 | we get a much larger output: | ||
524 | 528 | ||
525 | # tracer: irqsoff | 529 | # tracer: irqsoff |
526 | # | 530 | # |
@@ -566,27 +570,26 @@ irqsoff latency trace v1.1.5 on 2.6.26-rc8 | |||
566 | ls-4339 0d..2 51us : trace_hardirqs_on (__alloc_pages_internal) | 570 | ls-4339 0d..2 51us : trace_hardirqs_on (__alloc_pages_internal) |
567 | 571 | ||
568 | 572 | ||
569 | vim:ft=help | ||
570 | |||
571 | 573 | ||
572 | Here we traced a 50 microsecond latency. But we also see all the | 574 | Here we traced a 50 microsecond latency. But we also see all the |
573 | functions that were called during that time. Note that enabling | 575 | functions that were called during that time. Note that by enabling |
574 | function tracing we endure an added overhead. This overhead may | 576 | function tracing, we incur an added overhead. This overhead may |
575 | extend the latency times. But never the less, this trace has provided | 577 | extend the latency times. But nevertheless, this trace has provided |
576 | some very helpful debugging. | 578 | some very helpful debugging information. |
577 | 579 | ||
578 | 580 | ||
579 | preemptoff | 581 | preemptoff |
580 | ---------- | 582 | ---------- |
581 | 583 | ||
582 | When preemption is disabled we may be able to receive interrupts but | 584 | When preemption is disabled, we may be able to receive interrupts but |
583 | the task can not be preempted and a higher priority task must wait | 585 | the task cannot be preempted and a higher priority task must wait |
584 | for preemption to be enabled again before it can preempt a lower | 586 | for preemption to be enabled again before it can preempt a lower |
585 | priority task. | 587 | priority task. |
586 | 588 | ||
587 | The preemptoff tracer traces the places that disables preemption. | 589 | The preemptoff tracer traces the places that disable preemption. |
588 | Like the irqsoff, it records the maximum latency that preemption | 590 | Like the irqsoff tracer, it records the maximum latency for which preemption |
589 | was disabled. The control of preemptoff is much like the irqsoff. | 591 | was disabled. The control of preemptoff tracer is much like the irqsoff |
592 | tracer. | ||
590 | 593 | ||
591 | # echo preemptoff > /debug/tracing/current_tracer | 594 | # echo preemptoff > /debug/tracing/current_tracer |
592 | # echo 0 > /debug/tracing/tracing_max_latency | 595 | # echo 0 > /debug/tracing/tracing_max_latency |
@@ -620,8 +623,6 @@ preemptoff latency trace v1.1.5 on 2.6.26-rc8 | |||
620 | sshd-4261 0d.s1 30us : trace_preempt_on (__do_softirq) | 623 | sshd-4261 0d.s1 30us : trace_preempt_on (__do_softirq) |
621 | 624 | ||
622 | 625 | ||
623 | vim:ft=help | ||
624 | |||
625 | This has some more changes. Preemption was disabled when an interrupt | 626 | This has some more changes. Preemption was disabled when an interrupt |
626 | came in (notice the 'h'), and was enabled while doing a softirq. | 627 | came in (notice the 'h'), and was enabled while doing a softirq. |
627 | (notice the 's'). But we also see that interrupts have been disabled | 628 | (notice the 's'). But we also see that interrupts have been disabled |
@@ -689,16 +690,16 @@ The above is an example of the preemptoff trace with ftrace_enabled | |||
689 | set. Here we see that interrupts were disabled the entire time. | 690 | set. Here we see that interrupts were disabled the entire time. |
690 | The irq_enter code lets us know that we entered an interrupt 'h'. | 691 | The irq_enter code lets us know that we entered an interrupt 'h'. |
691 | Before that, the functions being traced still show that it is not | 692 | Before that, the functions being traced still show that it is not |
692 | in an interrupt, but we can see by the functions themselves that | 693 | in an interrupt, but we can see from the functions themselves that |
693 | this is not the case. | 694 | this is not the case. |
694 | 695 | ||
695 | Notice that the __do_softirq when called doesn't have a preempt_count. | 696 | Notice that __do_softirq when called does not have a preempt_count. |
696 | It may seem that we missed a preempt enabled. What really happened | 697 | It may seem that we missed a preempt enabling. What really happened |
697 | is that the preempt count is held on the threads stack and we | 698 | is that the preempt count is held on the thread's stack and we |
698 | switched to the softirq stack (4K stacks in effect). The code | 699 | switched to the softirq stack (4K stacks in effect). The code |
699 | does not copy the preempt count, but because interrupts are disabled | 700 | does not copy the preempt count, but because interrupts are disabled, |
700 | we don't need to worry about it. Having a tracer like this is good | 701 | we do not need to worry about it. Having a tracer like this is good |
701 | to let people know what really happens inside the kernel. | 702 | for letting people know what really happens inside the kernel. |
702 | 703 | ||
703 | 704 | ||
704 | preemptirqsoff | 705 | preemptirqsoff |
@@ -708,7 +709,7 @@ Knowing the locations that have interrupts disabled or preemption | |||
708 | disabled for the longest times is helpful. But sometimes we would | 709 | disabled for the longest times is helpful. But sometimes we would |
709 | like to know when either preemption and/or interrupts are disabled. | 710 | like to know when either preemption and/or interrupts are disabled. |
710 | 711 | ||
711 | The following code: | 712 | Consider the following code: |
712 | 713 | ||
713 | local_irq_disable(); | 714 | local_irq_disable(); |
714 | call_function_with_irqs_off(); | 715 | call_function_with_irqs_off(); |
@@ -732,7 +733,7 @@ To record this time, use the preemptirqsoff tracer. | |||
732 | 733 | ||
733 | Again, using this trace is much like the irqsoff and preemptoff tracers. | 734 | Again, using this trace is much like the irqsoff and preemptoff tracers. |
734 | 735 | ||
735 | # echo preemptoff > /debug/tracing/current_tracer | 736 | # echo preemptirqsoff > /debug/tracing/current_tracer |
736 | # echo 0 > /debug/tracing/tracing_max_latency | 737 | # echo 0 > /debug/tracing/tracing_max_latency |
737 | # echo 1 > /debug/tracing/tracing_enabled | 738 | # echo 1 > /debug/tracing/tracing_enabled |
738 | # ls -ltr | 739 | # ls -ltr |
@@ -764,12 +765,10 @@ preemptirqsoff latency trace v1.1.5 on 2.6.26-rc8 | |||
764 | ls-4860 0d.s1 294us : trace_preempt_on (__do_softirq) | 765 | ls-4860 0d.s1 294us : trace_preempt_on (__do_softirq) |
765 | 766 | ||
766 | 767 | ||
767 | vim:ft=help | ||
768 | |||
769 | 768 | ||
770 | The trace_hardirqs_off_thunk is called from assembly on x86 when | 769 | The trace_hardirqs_off_thunk is called from assembly on x86 when |
771 | interrupts are disabled in the assembly code. Without the function | 770 | interrupts are disabled in the assembly code. Without the function |
772 | tracing, we don't know if interrupts were enabled within the preemption | 771 | tracing, we do not know if interrupts were enabled within the preemption |
773 | points. We do see that it started with preemption enabled. | 772 | points. We do see that it started with preemption enabled. |
774 | 773 | ||
775 | Here is a trace with ftrace_enabled set: | 774 | Here is a trace with ftrace_enabled set: |
@@ -860,25 +859,25 @@ preemptirqsoff latency trace v1.1.5 on 2.6.26-rc8 | |||
860 | 859 | ||
861 | This is a very interesting trace. It started with the preemption of | 860 | This is a very interesting trace. It started with the preemption of |
862 | the ls task. We see that the task had the "need_resched" bit set | 861 | the ls task. We see that the task had the "need_resched" bit set |
863 | with the 'N' in the trace. Interrupts are disabled in the spin_lock | 862 | via the 'N' in the trace. Interrupts were disabled before the spin_lock |
864 | and the trace started. We see that a schedule took place to run | 863 | at the beginning of the trace. We see that a schedule took place to run |
865 | sshd. When the interrupts were enabled we took an interrupt. | 864 | sshd. When the interrupts were enabled, we took an interrupt. |
866 | On return of the interrupt the softirq ran. We took another interrupt | 865 | On return from the interrupt handler, the softirq ran. We took another |
867 | while running the softirq as we see with the capital 'H'. | 866 | interrupt while running the softirq as we see from the capital 'H'. |
868 | 867 | ||
869 | 868 | ||
870 | wakeup | 869 | wakeup |
871 | ------ | 870 | ------ |
872 | 871 | ||
873 | In Real-Time environment it is very important to know the wakeup | 872 | In a Real-Time environment it is very important to know the wakeup |
874 | time it takes for the highest priority task that wakes up to the | 873 | time it takes for the highest priority task that is woken up to the |
875 | time it executes. This is also known as "schedule latency". | 874 | time that it executes. This is also known as "schedule latency". |
876 | I stress the point that this is about RT tasks. It is also important | 875 | I stress the point that this is about RT tasks. It is also important |
877 | to know the scheduling latency of non-RT tasks, but the average | 876 | to know the scheduling latency of non-RT tasks, but the average |
878 | schedule latency is better for non-RT tasks. Tools like | 877 | schedule latency is better for non-RT tasks. Tools like |
879 | LatencyTop is more appropriate for such measurements. | 878 | LatencyTop are more appropriate for such measurements. |
880 | 879 | ||
881 | Real-Time environments is interested in the worst case latency. | 880 | Real-Time environments are interested in the worst case latency. |
882 | That is the longest latency it takes for something to happen, and | 881 | That is the longest latency it takes for something to happen, and |
883 | not the average. We can have a very fast scheduler that may only | 882 | not the average. We can have a very fast scheduler that may only |
884 | have a large latency once in a while, but that would not work well | 883 | have a large latency once in a while, but that would not work well |
@@ -889,8 +888,8 @@ tasks that are unpredictable will overwrite the worst case latency | |||
889 | of RT tasks. | 888 | of RT tasks. |
890 | 889 | ||
891 | Since this tracer only deals with RT tasks, we will run this slightly | 890 | Since this tracer only deals with RT tasks, we will run this slightly |
892 | different than we did with the previous tracers. Instead of performing | 891 | differently than we did with the previous tracers. Instead of performing |
893 | an 'ls' we will run 'sleep 1' under 'chrt' which changes the | 892 | an 'ls', we will run 'sleep 1' under 'chrt' which changes the |
894 | priority of the task. | 893 | priority of the task. |
895 | 894 | ||
896 | # echo wakeup > /debug/tracing/current_tracer | 895 | # echo wakeup > /debug/tracing/current_tracer |
@@ -921,12 +920,10 @@ wakeup latency trace v1.1.5 on 2.6.26-rc8 | |||
921 | <idle>-0 1d..4 4us : schedule (cpu_idle) | 920 | <idle>-0 1d..4 4us : schedule (cpu_idle) |
922 | 921 | ||
923 | 922 | ||
924 | vim:ft=help | ||
925 | |||
926 | 923 | ||
927 | Running this on an idle system we see that it only took 4 microseconds | 924 | Running this on an idle system, we see that it only took 4 microseconds |
928 | to perform the task switch. Note, since the trace marker in the | 925 | to perform the task switch. Note, since the trace marker in the |
929 | schedule is before the actual "switch" we stop the tracing when | 926 | schedule is before the actual "switch", we stop the tracing when |
930 | the recorded task is about to schedule in. This may change if | 927 | the recorded task is about to schedule in. This may change if |
931 | we add a new marker at the end of the scheduler. | 928 | we add a new marker at the end of the scheduler. |
932 | 929 | ||
@@ -991,13 +988,16 @@ ksoftirq-7 1d..6 49us : sub_preempt_count (_spin_unlock) | |||
991 | ksoftirq-7 1d..4 50us : schedule (__cond_resched) | 988 | ksoftirq-7 1d..4 50us : schedule (__cond_resched) |
992 | 989 | ||
993 | The interrupt went off while running ksoftirqd. This task runs at | 990 | The interrupt went off while running ksoftirqd. This task runs at |
994 | SCHED_OTHER. Why didn't we see the 'N' set early? This may be | 991 | SCHED_OTHER. Why did not we see the 'N' set early? This may be |
995 | a harmless bug with x86_32 and 4K stacks. The need_reched() function | 992 | a harmless bug with x86_32 and 4K stacks. On x86_32 with 4K stacks |
996 | that tests if we need to reschedule looks on the actual stack. | 993 | configured, the interrupt and softirq run with their own stack. |
997 | Where as the setting of the NEED_RESCHED bit happens on the | 994 | Some information is held on the top of the task's stack (need_resched |
998 | task's stack. But because we are in a hard interrupt, the test | 995 | and preempt_count are both stored there). The setting of the NEED_RESCHED |
999 | is with the interrupts stack which has that to be false. We don't | 996 | bit is done directly to the task's stack, but the reading of the |
1000 | see the 'N' until we switch back to the task's stack. | 997 | NEED_RESCHED is done by looking at the current stack, which in this case |
998 | is the stack for the hard interrupt. This hides the fact that NEED_RESCHED | ||
999 | has been set. We do not see the 'N' until we switch back to the task's | ||
1000 | assigned stack. | ||
1001 | 1001 | ||
1002 | ftrace | 1002 | ftrace |
1003 | ------ | 1003 | ------ |
@@ -1036,14 +1036,14 @@ this tracer is a nop. | |||
1036 | [...] | 1036 | [...] |
1037 | 1037 | ||
1038 | 1038 | ||
1039 | Note: It is sometimes better to enable or disable tracing directly from | 1039 | Note: ftrace uses ring buffers to store the above entries. The newest data |
1040 | a program, because the buffer may be overflowed by the echo commands | 1040 | may overwrite the oldest data. Sometimes using echo to stop the trace |
1041 | before you get to the point you want to trace. It is also easier to | 1041 | is not sufficient because the tracing could have overwritten the data |
1042 | stop the tracing at the point that you hit the part that you are | 1042 | that you wanted to record. For this reason, it is sometimes better to |
1043 | interested in. Since the ftrace buffer is a ring buffer with the | 1043 | disable tracing directly from a program. This allows you to stop the |
1044 | oldest data being overwritten, usually it is sufficient to start the | 1044 | tracing at the point that you hit the part that you are interested in. |
1045 | tracer with an echo command but have you code stop it. Something | 1045 | To disable the tracing directly from a C program, something like following |
1046 | like the following is usually appropriate for this. | 1046 | code snippet can be used: |
1047 | 1047 | ||
1048 | int trace_fd; | 1048 | int trace_fd; |
1049 | [...] | 1049 | [...] |
@@ -1052,25 +1052,31 @@ int main(int argc, char *argv[]) { | |||
1052 | trace_fd = open("/debug/tracing/tracing_enabled", O_WRONLY); | 1052 | trace_fd = open("/debug/tracing/tracing_enabled", O_WRONLY); |
1053 | [...] | 1053 | [...] |
1054 | if (condition_hit()) { | 1054 | if (condition_hit()) { |
1055 | write(trace_fd, "0", 1); | 1055 | write(trace_fd, "0", 1); |
1056 | } | 1056 | } |
1057 | [...] | 1057 | [...] |
1058 | } | 1058 | } |
1059 | 1059 | ||
1060 | Note: Here we hard coded the path name. The debugfs mount is not | ||
1061 | guaranteed to be at /debug (and is more commonly at /sys/kernel/debug). | ||
1062 | For simple one time traces, the above is sufficent. For anything else, | ||
1063 | a search through /proc/mounts may be needed to find where the debugfs | ||
1064 | file-system is mounted. | ||
1060 | 1065 | ||
1061 | dynamic ftrace | 1066 | dynamic ftrace |
1062 | -------------- | 1067 | -------------- |
1063 | 1068 | ||
1064 | If CONFIG_DYNAMIC_FTRACE is set, then the system will run with | 1069 | If CONFIG_DYNAMIC_FTRACE is set, the system will run with |
1065 | virtually no overhead when function tracing is disabled. The way | 1070 | virtually no overhead when function tracing is disabled. The way |
1066 | this works is the mcount function call (placed at the start of | 1071 | this works is the mcount function call (placed at the start of |
1067 | every kernel function, produced by the -pg switch in gcc), starts | 1072 | every kernel function, produced by the -pg switch in gcc), starts |
1068 | of pointing to a simple return. | 1073 | of pointing to a simple return. (Enabling FTRACE will include the |
1074 | -pg switch in the compiling of the kernel.) | ||
1069 | 1075 | ||
1070 | When dynamic ftrace is initialized, it calls kstop_machine to make it | 1076 | When dynamic ftrace is initialized, it calls kstop_machine to make |
1071 | act like a uniprocessor so that it can freely modify code without | 1077 | the machine act like a uniprocessor so that it can freely modify code |
1072 | worrying about other processors executing that same code. At | 1078 | without worrying about other processors executing that same code. At |
1073 | initialization, the mcount calls are change to call a "record_ip" | 1079 | initialization, the mcount calls are changed to call a "record_ip" |
1074 | function. After this, the first time a kernel function is called, | 1080 | function. After this, the first time a kernel function is called, |
1075 | it has the calling address saved in a hash table. | 1081 | it has the calling address saved in a hash table. |
1076 | 1082 | ||
@@ -1078,15 +1084,15 @@ Later on the ftraced kernel thread is awoken and will again call | |||
1078 | kstop_machine if new functions have been recorded. The ftraced thread | 1084 | kstop_machine if new functions have been recorded. The ftraced thread |
1079 | will change all calls to mcount to "nop". Just calling mcount | 1085 | will change all calls to mcount to "nop". Just calling mcount |
1080 | and having mcount return has shown a 10% overhead. By converting | 1086 | and having mcount return has shown a 10% overhead. By converting |
1081 | it to a nop, there is no recordable overhead to the system. | 1087 | it to a nop, there is no measurable overhead to the system. |
1082 | 1088 | ||
1083 | One special side-effect to the recording of the functions being | 1089 | One special side-effect to the recording of the functions being |
1084 | traced, is that we can now selectively choose which functions we | 1090 | traced is that we can now selectively choose which functions we |
1085 | want to trace and which ones we want the mcount calls to remain as | 1091 | wish to trace and which ones we want the mcount calls to remain as |
1086 | nops. | 1092 | nops. |
1087 | 1093 | ||
1088 | Two files that contain to the enabling and disabling of recorded | 1094 | Two files are used, one for enabling and one for disabling the tracing |
1089 | functions are: | 1095 | of specified functions. They are: |
1090 | 1096 | ||
1091 | set_ftrace_filter | 1097 | set_ftrace_filter |
1092 | 1098 | ||
@@ -1094,7 +1100,7 @@ and | |||
1094 | 1100 | ||
1095 | set_ftrace_notrace | 1101 | set_ftrace_notrace |
1096 | 1102 | ||
1097 | A list of available functions that you can add to this files is listed | 1103 | A list of available functions that you can add to these files is listed |
1098 | in: | 1104 | in: |
1099 | 1105 | ||
1100 | available_filter_functions | 1106 | available_filter_functions |
@@ -1108,7 +1114,7 @@ pick_next_task_fair | |||
1108 | mutex_lock | 1114 | mutex_lock |
1109 | [...] | 1115 | [...] |
1110 | 1116 | ||
1111 | If I'm only interested in sys_nanosleep and hrtimer_interrupt: | 1117 | If I am only interested in sys_nanosleep and hrtimer_interrupt: |
1112 | 1118 | ||
1113 | # echo sys_nanosleep hrtimer_interrupt \ | 1119 | # echo sys_nanosleep hrtimer_interrupt \ |
1114 | > /debug/tracing/set_ftrace_filter | 1120 | > /debug/tracing/set_ftrace_filter |
@@ -1125,21 +1131,21 @@ If I'm only interested in sys_nanosleep and hrtimer_interrupt: | |||
1125 | usleep-4134 [00] 1317.070111: sys_nanosleep <-syscall_call | 1131 | usleep-4134 [00] 1317.070111: sys_nanosleep <-syscall_call |
1126 | <idle>-0 [00] 1317.070115: hrtimer_interrupt <-smp_apic_timer_interrupt | 1132 | <idle>-0 [00] 1317.070115: hrtimer_interrupt <-smp_apic_timer_interrupt |
1127 | 1133 | ||
1128 | To see what functions are being traced, you can cat the file: | 1134 | To see which functions are being traced, you can cat the file: |
1129 | 1135 | ||
1130 | # cat /debug/tracing/set_ftrace_filter | 1136 | # cat /debug/tracing/set_ftrace_filter |
1131 | hrtimer_interrupt | 1137 | hrtimer_interrupt |
1132 | sys_nanosleep | 1138 | sys_nanosleep |
1133 | 1139 | ||
1134 | 1140 | ||
1135 | Perhaps this isn't enough. The filters also allow simple wild cards. | 1141 | Perhaps this is not enough. The filters also allow simple wild cards. |
1136 | Only the following is currently available | 1142 | Only the following are currently available |
1137 | 1143 | ||
1138 | <match>* - will match functions that begins with <match> | 1144 | <match>* - will match functions that begin with <match> |
1139 | *<match> - will match functions that end with <match> | 1145 | *<match> - will match functions that end with <match> |
1140 | *<match>* - will match functions that have <match> in it | 1146 | *<match>* - will match functions that have <match> in it |
1141 | 1147 | ||
1142 | Thats all the wild cards that are allowed. | 1148 | These are the only wild cards which are supported. |
1143 | 1149 | ||
1144 | <match>*<match> will not work. | 1150 | <match>*<match> will not work. |
1145 | 1151 | ||
@@ -1187,7 +1193,7 @@ This is because the '>' and '>>' act just like they do in bash. | |||
1187 | To rewrite the filters, use '>' | 1193 | To rewrite the filters, use '>' |
1188 | To append to the filters, use '>>' | 1194 | To append to the filters, use '>>' |
1189 | 1195 | ||
1190 | To clear out a filter so that all functions will be recorded again. | 1196 | To clear out a filter so that all functions will be recorded again: |
1191 | 1197 | ||
1192 | # echo > /debug/tracing/set_ftrace_filter | 1198 | # echo > /debug/tracing/set_ftrace_filter |
1193 | # cat /debug/tracing/set_ftrace_filter | 1199 | # cat /debug/tracing/set_ftrace_filter |
@@ -1246,24 +1252,24 @@ ftraced | |||
1246 | 1252 | ||
1247 | As mentioned above, when dynamic ftrace is configured in, a kernel | 1253 | As mentioned above, when dynamic ftrace is configured in, a kernel |
1248 | thread wakes up once a second and checks to see if there are mcount | 1254 | thread wakes up once a second and checks to see if there are mcount |
1249 | calls that need to be converted into nops. If there is not, then | 1255 | calls that need to be converted into nops. If there are not any, then |
1250 | it simply goes back to sleep. But if there is, it will call | 1256 | it simply goes back to sleep. But if there are some, it will call |
1251 | kstop_machine to convert the calls to nops. | 1257 | kstop_machine to convert the calls to nops. |
1252 | 1258 | ||
1253 | There may be a case that you do not want this added latency. | 1259 | There may be a case in which you do not want this added latency. |
1254 | Perhaps you are doing some audio recording and this activity might | 1260 | Perhaps you are doing some audio recording and this activity might |
1255 | cause skips in the playback. There is an interface to disable | 1261 | cause skips in the playback. There is an interface to disable |
1256 | and enable the ftraced kernel thread. | 1262 | and enable the "ftraced" kernel thread. |
1257 | 1263 | ||
1258 | # echo 0 > /debug/tracing/ftraced_enabled | 1264 | # echo 0 > /debug/tracing/ftraced_enabled |
1259 | 1265 | ||
1260 | This will disable the calling of the kstop_machine to update the | 1266 | This will disable the calling of kstop_machine to update the |
1261 | mcount calls to nops. Remember that there's a large overhead | 1267 | mcount calls to nops. Remember that there is a large overhead |
1262 | to calling mcount. Without this kernel thread, that overhead will | 1268 | to calling mcount. Without this kernel thread, that overhead will |
1263 | exist. | 1269 | exist. |
1264 | 1270 | ||
1265 | Any write to the ftraced_enabled file will cause the kstop_machine | 1271 | If there are recorded calls to mcount, any write to the ftraced_enabled |
1266 | to run if there are recorded calls to mcount. This means that a | 1272 | file will cause the kstop_machine to run. This means that a |
1267 | user can manually perform the updates when they want to by simply | 1273 | user can manually perform the updates when they want to by simply |
1268 | echoing a '0' into the ftraced_enabled file. | 1274 | echoing a '0' into the ftraced_enabled file. |
1269 | 1275 | ||
@@ -1274,8 +1280,8 @@ that uses ftrace function recording. | |||
1274 | trace_pipe | 1280 | trace_pipe |
1275 | ---------- | 1281 | ---------- |
1276 | 1282 | ||
1277 | The trace_pipe outputs the same as trace, but the effect on the | 1283 | The trace_pipe outputs the same content as the trace file, but the effect |
1278 | tracing is different. Every read from trace_pipe is consumed. | 1284 | on the tracing is different. Every read from trace_pipe is consumed. |
1279 | This means that subsequent reads will be different. The trace | 1285 | This means that subsequent reads will be different. The trace |
1280 | is live. | 1286 | is live. |
1281 | 1287 | ||
@@ -1305,7 +1311,7 @@ is live. | |||
1305 | bash-4043 [00] 41.267111: select_task_rq_rt <-try_to_wake_up | 1311 | bash-4043 [00] 41.267111: select_task_rq_rt <-try_to_wake_up |
1306 | 1312 | ||
1307 | 1313 | ||
1308 | Note, reading the trace_pipe will block until more input is added. | 1314 | Note, reading the trace_pipe file will block until more input is added. |
1309 | By changing the tracer, trace_pipe will issue an EOF. We needed | 1315 | By changing the tracer, trace_pipe will issue an EOF. We needed |
1310 | to set the ftrace tracer _before_ cating the trace_pipe file. | 1316 | to set the ftrace tracer _before_ cating the trace_pipe file. |
1311 | 1317 | ||
@@ -1314,8 +1320,8 @@ trace entries | |||
1314 | ------------- | 1320 | ------------- |
1315 | 1321 | ||
1316 | Having too much or not enough data can be troublesome in diagnosing | 1322 | Having too much or not enough data can be troublesome in diagnosing |
1317 | some issue in the kernel. The file trace_entries is used to modify | 1323 | an issue in the kernel. The file trace_entries is used to modify |
1318 | the size of the internal trace buffers. The numbers listed | 1324 | the size of the internal trace buffers. The number listed |
1319 | is the number of entries that can be recorded per CPU. To know | 1325 | is the number of entries that can be recorded per CPU. To know |
1320 | the full size, multiply the number of possible CPUS with the | 1326 | the full size, multiply the number of possible CPUS with the |
1321 | number of entries. | 1327 | number of entries. |
@@ -1323,8 +1329,9 @@ number of entries. | |||
1323 | # cat /debug/tracing/trace_entries | 1329 | # cat /debug/tracing/trace_entries |
1324 | 65620 | 1330 | 65620 |
1325 | 1331 | ||
1326 | Note, to modify this you must have tracing fulling disabled. To do that, | 1332 | Note, to modify this, you must have tracing completely disabled. To do that, |
1327 | echo "none" into the current_tracer. | 1333 | echo "none" into the current_tracer. If the current_tracer is not set |
1334 | to "none", an EINVAL error will be returned. | ||
1328 | 1335 | ||
1329 | # echo none > /debug/tracing/current_tracer | 1336 | # echo none > /debug/tracing/current_tracer |
1330 | # echo 100000 > /debug/tracing/trace_entries | 1337 | # echo 100000 > /debug/tracing/trace_entries |
@@ -1333,18 +1340,18 @@ echo "none" into the current_tracer. | |||
1333 | 1340 | ||
1334 | 1341 | ||
1335 | Notice that we echoed in 100,000 but the size is 100,045. The entries | 1342 | Notice that we echoed in 100,000 but the size is 100,045. The entries |
1336 | are held by individual pages. It allocates the number of pages it takes | 1343 | are held in individual pages. It allocates the number of pages it takes |
1337 | to fulfill the request. If more entries may fit on the last page | 1344 | to fulfill the request. If more entries may fit on the last page |
1338 | it will add them. | 1345 | then they will be added. |
1339 | 1346 | ||
1340 | # echo 1 > /debug/tracing/trace_entries | 1347 | # echo 1 > /debug/tracing/trace_entries |
1341 | # cat /debug/tracing/trace_entries | 1348 | # cat /debug/tracing/trace_entries |
1342 | 85 | 1349 | 85 |
1343 | 1350 | ||
1344 | This shows us that 85 entries can fit on a single page. | 1351 | This shows us that 85 entries can fit in a single page. |
1345 | 1352 | ||
1346 | The number of pages that will be allocated is a percentage of available | 1353 | The number of pages which will be allocated is limited to a percentage |
1347 | memory. Allocating too much will produces an error. | 1354 | of available memory. Allocating too much will produce an error. |
1348 | 1355 | ||
1349 | # echo 1000000000000 > /debug/tracing/trace_entries | 1356 | # echo 1000000000000 > /debug/tracing/trace_entries |
1350 | -bash: echo: write error: Cannot allocate memory | 1357 | -bash: echo: write error: Cannot allocate memory |
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index c35ca9e40d4c..18022e249c53 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt | |||
@@ -347,15 +347,12 @@ necessarily be nonportable. | |||
347 | Dynamic definition of GPIOs is not currently standard; for example, as | 347 | Dynamic definition of GPIOs is not currently standard; for example, as |
348 | a side effect of configuring an add-on board with some GPIO expanders. | 348 | a side effect of configuring an add-on board with some GPIO expanders. |
349 | 349 | ||
350 | These calls are purely for kernel space, but a userspace API could be built | ||
351 | on top of them. | ||
352 | |||
353 | 350 | ||
354 | GPIO implementor's framework (OPTIONAL) | 351 | GPIO implementor's framework (OPTIONAL) |
355 | ======================================= | 352 | ======================================= |
356 | As noted earlier, there is an optional implementation framework making it | 353 | As noted earlier, there is an optional implementation framework making it |
357 | easier for platforms to support different kinds of GPIO controller using | 354 | easier for platforms to support different kinds of GPIO controller using |
358 | the same programming interface. | 355 | the same programming interface. This framework is called "gpiolib". |
359 | 356 | ||
360 | As a debugging aid, if debugfs is available a /sys/kernel/debug/gpio file | 357 | As a debugging aid, if debugfs is available a /sys/kernel/debug/gpio file |
361 | will be found there. That will list all the controllers registered through | 358 | will be found there. That will list all the controllers registered through |
@@ -392,11 +389,21 @@ either NULL or the label associated with that GPIO when it was requested. | |||
392 | 389 | ||
393 | Platform Support | 390 | Platform Support |
394 | ---------------- | 391 | ---------------- |
395 | To support this framework, a platform's Kconfig will "select HAVE_GPIO_LIB" | 392 | To support this framework, a platform's Kconfig will "select" either |
393 | ARCH_REQUIRE_GPIOLIB or ARCH_WANT_OPTIONAL_GPIOLIB | ||
396 | and arrange that its <asm/gpio.h> includes <asm-generic/gpio.h> and defines | 394 | and arrange that its <asm/gpio.h> includes <asm-generic/gpio.h> and defines |
397 | three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep(). | 395 | three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep(). |
398 | They may also want to provide a custom value for ARCH_NR_GPIOS. | 396 | They may also want to provide a custom value for ARCH_NR_GPIOS. |
399 | 397 | ||
398 | ARCH_REQUIRE_GPIOLIB means that the gpio-lib code will always get compiled | ||
399 | into the kernel on that architecture. | ||
400 | |||
401 | ARCH_WANT_OPTIONAL_GPIOLIB means the gpio-lib code defaults to off and the user | ||
402 | can enable it and build it into the kernel optionally. | ||
403 | |||
404 | If neither of these options are selected, the platform does not support | ||
405 | GPIOs through GPIO-lib and the code cannot be enabled by the user. | ||
406 | |||
400 | Trivial implementations of those functions can directly use framework | 407 | Trivial implementations of those functions can directly use framework |
401 | code, which always dispatches through the gpio_chip: | 408 | code, which always dispatches through the gpio_chip: |
402 | 409 | ||
@@ -439,4 +446,120 @@ becomes available. That may mean the device should not be registered until | |||
439 | calls for that GPIO can work. One way to address such dependencies is for | 446 | calls for that GPIO can work. One way to address such dependencies is for |
440 | such gpio_chip controllers to provide setup() and teardown() callbacks to | 447 | such gpio_chip controllers to provide setup() and teardown() callbacks to |
441 | board specific code; those board specific callbacks would register devices | 448 | board specific code; those board specific callbacks would register devices |
442 | once all the necessary resources are available. | 449 | once all the necessary resources are available, and remove them later when |
450 | the GPIO controller device becomes unavailable. | ||
451 | |||
452 | |||
453 | Sysfs Interface for Userspace (OPTIONAL) | ||
454 | ======================================== | ||
455 | Platforms which use the "gpiolib" implementors framework may choose to | ||
456 | configure a sysfs user interface to GPIOs. This is different from the | ||
457 | debugfs interface, since it provides control over GPIO direction and | ||
458 | value instead of just showing a gpio state summary. Plus, it could be | ||
459 | present on production systems without debugging support. | ||
460 | |||
461 | Given approprate hardware documentation for the system, userspace could | ||
462 | know for example that GPIO #23 controls the write protect line used to | ||
463 | protect boot loader segments in flash memory. System upgrade procedures | ||
464 | may need to temporarily remove that protection, first importing a GPIO, | ||
465 | then changing its output state, then updating the code before re-enabling | ||
466 | the write protection. In normal use, GPIO #23 would never be touched, | ||
467 | and the kernel would have no need to know about it. | ||
468 | |||
469 | Again depending on appropriate hardware documentation, on some systems | ||
470 | userspace GPIO can be used to determine system configuration data that | ||
471 | standard kernels won't know about. And for some tasks, simple userspace | ||
472 | GPIO drivers could be all that the system really needs. | ||
473 | |||
474 | Note that standard kernel drivers exist for common "LEDs and Buttons" | ||
475 | GPIO tasks: "leds-gpio" and "gpio_keys", respectively. Use those | ||
476 | instead of talking directly to the GPIOs; they integrate with kernel | ||
477 | frameworks better than your userspace code could. | ||
478 | |||
479 | |||
480 | Paths in Sysfs | ||
481 | -------------- | ||
482 | There are three kinds of entry in /sys/class/gpio: | ||
483 | |||
484 | - Control interfaces used to get userspace control over GPIOs; | ||
485 | |||
486 | - GPIOs themselves; and | ||
487 | |||
488 | - GPIO controllers ("gpio_chip" instances). | ||
489 | |||
490 | That's in addition to standard files including the "device" symlink. | ||
491 | |||
492 | The control interfaces are write-only: | ||
493 | |||
494 | /sys/class/gpio/ | ||
495 | |||
496 | "export" ... Userspace may ask the kernel to export control of | ||
497 | a GPIO to userspace by writing its number to this file. | ||
498 | |||
499 | Example: "echo 19 > export" will create a "gpio19" node | ||
500 | for GPIO #19, if that's not requested by kernel code. | ||
501 | |||
502 | "unexport" ... Reverses the effect of exporting to userspace. | ||
503 | |||
504 | Example: "echo 19 > unexport" will remove a "gpio19" | ||
505 | node exported using the "export" file. | ||
506 | |||
507 | GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42) | ||
508 | and have the following read/write attributes: | ||
509 | |||
510 | /sys/class/gpio/gpioN/ | ||
511 | |||
512 | "direction" ... reads as either "in" or "out". This value may | ||
513 | normally be written. Writing as "out" defaults to | ||
514 | initializing the value as low. To ensure glitch free | ||
515 | operation, values "low" and "high" may be written to | ||
516 | configure the GPIO as an output with that initial value. | ||
517 | |||
518 | Note that this attribute *will not exist* if the kernel | ||
519 | doesn't support changing the direction of a GPIO, or | ||
520 | it was exported by kernel code that didn't explicitly | ||
521 | allow userspace to reconfigure this GPIO's direction. | ||
522 | |||
523 | "value" ... reads as either 0 (low) or 1 (high). If the GPIO | ||
524 | is configured as an output, this value may be written; | ||
525 | any nonzero value is treated as high. | ||
526 | |||
527 | GPIO controllers have paths like /sys/class/gpio/chipchip42/ (for the | ||
528 | controller implementing GPIOs starting at #42) and have the following | ||
529 | read-only attributes: | ||
530 | |||
531 | /sys/class/gpio/gpiochipN/ | ||
532 | |||
533 | "base" ... same as N, the first GPIO managed by this chip | ||
534 | |||
535 | "label" ... provided for diagnostics (not always unique) | ||
536 | |||
537 | "ngpio" ... how many GPIOs this manges (N to N + ngpio - 1) | ||
538 | |||
539 | Board documentation should in most cases cover what GPIOs are used for | ||
540 | what purposes. However, those numbers are not always stable; GPIOs on | ||
541 | a daughtercard might be different depending on the base board being used, | ||
542 | or other cards in the stack. In such cases, you may need to use the | ||
543 | gpiochip nodes (possibly in conjunction with schematics) to determine | ||
544 | the correct GPIO number to use for a given signal. | ||
545 | |||
546 | |||
547 | Exporting from Kernel code | ||
548 | -------------------------- | ||
549 | Kernel code can explicitly manage exports of GPIOs which have already been | ||
550 | requested using gpio_request(): | ||
551 | |||
552 | /* export the GPIO to userspace */ | ||
553 | int gpio_export(unsigned gpio, bool direction_may_change); | ||
554 | |||
555 | /* reverse gpio_export() */ | ||
556 | void gpio_unexport(); | ||
557 | |||
558 | After a kernel driver requests a GPIO, it may only be made available in | ||
559 | the sysfs interface by gpio_export(). The driver can control whether the | ||
560 | signal direction may change. This helps drivers prevent userspace code | ||
561 | from accidentally clobbering important system state. | ||
562 | |||
563 | This explicit exporting can help with debugging (by making some kinds | ||
564 | of experiments easier), or can provide an always-there interface that's | ||
565 | suitable for documenting as part of a board support package. | ||
diff --git a/Documentation/i2c/busses/i2c-i810 b/Documentation/i2c/busses/i2c-i810 deleted file mode 100644 index 778210ee1583..000000000000 --- a/Documentation/i2c/busses/i2c-i810 +++ /dev/null | |||
@@ -1,47 +0,0 @@ | |||
1 | Kernel driver i2c-i810 | ||
2 | |||
3 | Supported adapters: | ||
4 | * Intel 82810, 82810-DC100, 82810E, and 82815 (GMCH) | ||
5 | * Intel 82845G (GMCH) | ||
6 | |||
7 | Authors: | ||
8 | Frodo Looijaard <frodol@dds.nl>, | ||
9 | Philip Edelbrock <phil@netroedge.com>, | ||
10 | Kyösti Mälkki <kmalkki@cc.hut.fi>, | ||
11 | Ralph Metzler <rjkm@thp.uni-koeln.de>, | ||
12 | Mark D. Studebaker <mdsxyz123@yahoo.com> | ||
13 | |||
14 | Main contact: Mark Studebaker <mdsxyz123@yahoo.com> | ||
15 | |||
16 | Description | ||
17 | ----------- | ||
18 | |||
19 | WARNING: If you have an '810' or '815' motherboard, your standard I2C | ||
20 | temperature sensors are most likely on the 801's I2C bus. You want the | ||
21 | i2c-i801 driver for those, not this driver. | ||
22 | |||
23 | Now for the i2c-i810... | ||
24 | |||
25 | The GMCH chip contains two I2C interfaces. | ||
26 | |||
27 | The first interface is used for DDC (Data Display Channel) which is a | ||
28 | serial channel through the VGA monitor connector to a DDC-compliant | ||
29 | monitor. This interface is defined by the Video Electronics Standards | ||
30 | Association (VESA). The standards are available for purchase at | ||
31 | http://www.vesa.org . | ||
32 | |||
33 | The second interface is a general-purpose I2C bus. It may be connected to a | ||
34 | TV-out chip such as the BT869 or possibly to a digital flat-panel display. | ||
35 | |||
36 | Features | ||
37 | -------- | ||
38 | |||
39 | Both busses use the i2c-algo-bit driver for 'bit banging' | ||
40 | and support for specific transactions is provided by i2c-algo-bit. | ||
41 | |||
42 | Issues | ||
43 | ------ | ||
44 | |||
45 | If you enable bus testing in i2c-algo-bit (insmod i2c-algo-bit bit_test=1), | ||
46 | the test may fail; if so, the i2c-i810 driver won't be inserted. However, | ||
47 | we think this has been fixed. | ||
diff --git a/Documentation/i2c/busses/i2c-prosavage b/Documentation/i2c/busses/i2c-prosavage deleted file mode 100644 index 703687902511..000000000000 --- a/Documentation/i2c/busses/i2c-prosavage +++ /dev/null | |||
@@ -1,23 +0,0 @@ | |||
1 | Kernel driver i2c-prosavage | ||
2 | |||
3 | Supported adapters: | ||
4 | |||
5 | S3/VIA KM266/VT8375 aka ProSavage8 | ||
6 | S3/VIA KM133/VT8365 aka Savage4 | ||
7 | |||
8 | Author: Henk Vergonet <henk@god.dyndns.org> | ||
9 | |||
10 | Description | ||
11 | ----------- | ||
12 | |||
13 | The Savage4 chips contain two I2C interfaces (aka a I2C 'master' or | ||
14 | 'host'). | ||
15 | |||
16 | The first interface is used for DDC (Data Display Channel) which is a | ||
17 | serial channel through the VGA monitor connector to a DDC-compliant | ||
18 | monitor. This interface is defined by the Video Electronics Standards | ||
19 | Association (VESA). The standards are available for purchase at | ||
20 | http://www.vesa.org . The second interface is a general-purpose I2C bus. | ||
21 | |||
22 | Usefull for gaining access to the TV Encoder chips. | ||
23 | |||
diff --git a/Documentation/i2c/busses/i2c-savage4 b/Documentation/i2c/busses/i2c-savage4 deleted file mode 100644 index 6ecceab618d3..000000000000 --- a/Documentation/i2c/busses/i2c-savage4 +++ /dev/null | |||
@@ -1,26 +0,0 @@ | |||
1 | Kernel driver i2c-savage4 | ||
2 | |||
3 | Supported adapters: | ||
4 | * Savage4 | ||
5 | * Savage2000 | ||
6 | |||
7 | Authors: | ||
8 | Alexander Wold <awold@bigfoot.com>, | ||
9 | Mark D. Studebaker <mdsxyz123@yahoo.com> | ||
10 | |||
11 | Description | ||
12 | ----------- | ||
13 | |||
14 | The Savage4 chips contain two I2C interfaces (aka a I2C 'master' | ||
15 | or 'host'). | ||
16 | |||
17 | The first interface is used for DDC (Data Display Channel) which is a | ||
18 | serial channel through the VGA monitor connector to a DDC-compliant | ||
19 | monitor. This interface is defined by the Video Electronics Standards | ||
20 | Association (VESA). The standards are available for purchase at | ||
21 | http://www.vesa.org . The DDC bus is not yet supported because its register | ||
22 | is not directly memory-mapped. | ||
23 | |||
24 | The second interface is a general-purpose I2C bus. This is the only | ||
25 | interface supported by the driver at the moment. | ||
26 | |||
diff --git a/Documentation/i2c/chips/max6875 b/Documentation/i2c/chips/max6875 index a0cd8af2f408..10ca43cd1a72 100644 --- a/Documentation/i2c/chips/max6875 +++ b/Documentation/i2c/chips/max6875 | |||
@@ -49,7 +49,7 @@ $ modprobe max6875 force=0,0x50 | |||
49 | 49 | ||
50 | The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple | 50 | The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple |
51 | addresses. For example, for address 0x50, it also reserves 0x51. | 51 | addresses. For example, for address 0x50, it also reserves 0x51. |
52 | The even-address instance is called 'max6875', the odd one is 'max6875 subclient'. | 52 | The even-address instance is called 'max6875', the odd one is 'dummy'. |
53 | 53 | ||
54 | 54 | ||
55 | Programming the chip using i2c-dev | 55 | Programming the chip using i2c-dev |
diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539 index 1d81c530c4a5..6aff890088b1 100644 --- a/Documentation/i2c/chips/pca9539 +++ b/Documentation/i2c/chips/pca9539 | |||
@@ -7,7 +7,7 @@ drivers/gpio/pca9539.c instead. | |||
7 | Supported chips: | 7 | Supported chips: |
8 | * Philips PCA9539 | 8 | * Philips PCA9539 |
9 | Prefix: 'pca9539' | 9 | Prefix: 'pca9539' |
10 | Addresses scanned: 0x74 - 0x77 | 10 | Addresses scanned: none |
11 | Datasheet: | 11 | Datasheet: |
12 | http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf | 12 | http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf |
13 | 13 | ||
@@ -23,6 +23,14 @@ The input sense can also be inverted. | |||
23 | The 16 lines are split between two bytes. | 23 | The 16 lines are split between two bytes. |
24 | 24 | ||
25 | 25 | ||
26 | Detection | ||
27 | --------- | ||
28 | |||
29 | The PCA9539 is difficult to detect and not commonly found in PC machines, | ||
30 | so you have to pass the I2C bus and address of the installed PCA9539 | ||
31 | devices explicitly to the driver at load time via the force=... parameter. | ||
32 | |||
33 | |||
26 | Sysfs entries | 34 | Sysfs entries |
27 | ------------- | 35 | ------------- |
28 | 36 | ||
diff --git a/Documentation/i2c/chips/pcf8574 b/Documentation/i2c/chips/pcf8574 index 5c1ad1376b62..235815c075ff 100644 --- a/Documentation/i2c/chips/pcf8574 +++ b/Documentation/i2c/chips/pcf8574 | |||
@@ -4,13 +4,13 @@ Kernel driver pcf8574 | |||
4 | Supported chips: | 4 | Supported chips: |
5 | * Philips PCF8574 | 5 | * Philips PCF8574 |
6 | Prefix: 'pcf8574' | 6 | Prefix: 'pcf8574' |
7 | Addresses scanned: I2C 0x20 - 0x27 | 7 | Addresses scanned: none |
8 | Datasheet: Publicly available at the Philips Semiconductors website | 8 | Datasheet: Publicly available at the Philips Semiconductors website |
9 | http://www.semiconductors.philips.com/pip/PCF8574P.html | 9 | http://www.semiconductors.philips.com/pip/PCF8574P.html |
10 | 10 | ||
11 | * Philips PCF8574A | 11 | * Philips PCF8574A |
12 | Prefix: 'pcf8574a' | 12 | Prefix: 'pcf8574a' |
13 | Addresses scanned: I2C 0x38 - 0x3f | 13 | Addresses scanned: none |
14 | Datasheet: Publicly available at the Philips Semiconductors website | 14 | Datasheet: Publicly available at the Philips Semiconductors website |
15 | http://www.semiconductors.philips.com/pip/PCF8574P.html | 15 | http://www.semiconductors.philips.com/pip/PCF8574P.html |
16 | 16 | ||
@@ -38,12 +38,10 @@ For more informations see the datasheet. | |||
38 | Accessing PCF8574(A) via /sys interface | 38 | Accessing PCF8574(A) via /sys interface |
39 | ------------------------------------- | 39 | ------------------------------------- |
40 | 40 | ||
41 | ! Be careful ! | ||
42 | The PCF8574(A) is plainly impossible to detect ! Stupid chip. | 41 | The PCF8574(A) is plainly impossible to detect ! Stupid chip. |
43 | So every chip with address in the interval [20..27] and [38..3f] are | 42 | So, you have to pass the I2C bus and address of the installed PCF857A |
44 | detected as PCF8574(A). If you have other chips in this address | 43 | and PCF8574A devices explicitly to the driver at load time via the |
45 | range, the workaround is to load this module after the one | 44 | force=... parameter. |
46 | for your others chips. | ||
47 | 45 | ||
48 | On detection (i.e. insmod, modprobe et al.), directories are being | 46 | On detection (i.e. insmod, modprobe et al.), directories are being |
49 | created for each detected PCF8574(A): | 47 | created for each detected PCF8574(A): |
diff --git a/Documentation/i2c/chips/pcf8575 b/Documentation/i2c/chips/pcf8575 index 25f5698a61cf..40b268eb276f 100644 --- a/Documentation/i2c/chips/pcf8575 +++ b/Documentation/i2c/chips/pcf8575 | |||
@@ -40,12 +40,9 @@ Detection | |||
40 | --------- | 40 | --------- |
41 | 41 | ||
42 | There is no method known to detect whether a chip on a given I2C address is | 42 | There is no method known to detect whether a chip on a given I2C address is |
43 | a PCF8575 or whether it is any other I2C device. So there are two alternatives | 43 | a PCF8575 or whether it is any other I2C device, so you have to pass the I2C |
44 | to let the driver find the installed PCF8575 devices: | 44 | bus and address of the installed PCF8575 devices explicitly to the driver at |
45 | - Load this driver after any other I2C driver for I2C devices with addresses | 45 | load time via the force=... parameter. |
46 | in the range 0x20 .. 0x27. | ||
47 | - Pass the I2C bus and address of the installed PCF8575 devices explicitly to | ||
48 | the driver at load time via the probe=... or force=... parameters. | ||
49 | 46 | ||
50 | /sys interface | 47 | /sys interface |
51 | -------------- | 48 | -------------- |
diff --git a/Documentation/i2c/fault-codes b/Documentation/i2c/fault-codes new file mode 100644 index 000000000000..045765c0b9b5 --- /dev/null +++ b/Documentation/i2c/fault-codes | |||
@@ -0,0 +1,127 @@ | |||
1 | This is a summary of the most important conventions for use of fault | ||
2 | codes in the I2C/SMBus stack. | ||
3 | |||
4 | |||
5 | A "Fault" is not always an "Error" | ||
6 | ---------------------------------- | ||
7 | Not all fault reports imply errors; "page faults" should be a familiar | ||
8 | example. Software often retries idempotent operations after transient | ||
9 | faults. There may be fancier recovery schemes that are appropriate in | ||
10 | some cases, such as re-initializing (and maybe resetting). After such | ||
11 | recovery, triggered by a fault report, there is no error. | ||
12 | |||
13 | In a similar way, sometimes a "fault" code just reports one defined | ||
14 | result for an operation ... it doesn't indicate that anything is wrong | ||
15 | at all, just that the outcome wasn't on the "golden path". | ||
16 | |||
17 | In short, your I2C driver code may need to know these codes in order | ||
18 | to respond correctly. Other code may need to rely on YOUR code reporting | ||
19 | the right fault code, so that it can (in turn) behave correctly. | ||
20 | |||
21 | |||
22 | I2C and SMBus fault codes | ||
23 | ------------------------- | ||
24 | These are returned as negative numbers from most calls, with zero or | ||
25 | some positive number indicating a non-fault return. The specific | ||
26 | numbers associated with these symbols differ between architectures, | ||
27 | though most Linux systems use <asm-generic/errno*.h> numbering. | ||
28 | |||
29 | Note that the descriptions here are not exhaustive. There are other | ||
30 | codes that may be returned, and other cases where these codes should | ||
31 | be returned. However, drivers should not return other codes for these | ||
32 | cases (unless the hardware doesn't provide unique fault reports). | ||
33 | |||
34 | Also, codes returned by adapter probe methods follow rules which are | ||
35 | specific to their host bus (such as PCI, or the platform bus). | ||
36 | |||
37 | |||
38 | EAGAIN | ||
39 | Returned by I2C adapters when they lose arbitration in master | ||
40 | transmit mode: some other master was transmitting different | ||
41 | data at the same time. | ||
42 | |||
43 | Also returned when trying to invoke an I2C operation in an | ||
44 | atomic context, when some task is already using that I2C bus | ||
45 | to execute some other operation. | ||
46 | |||
47 | EBADMSG | ||
48 | Returned by SMBus logic when an invalid Packet Error Code byte | ||
49 | is received. This code is a CRC covering all bytes in the | ||
50 | transaction, and is sent before the terminating STOP. This | ||
51 | fault is only reported on read transactions; the SMBus slave | ||
52 | may have a way to report PEC mismatches on writes from the | ||
53 | host. Note that even if PECs are in use, you should not rely | ||
54 | on these as the only way to detect incorrect data transfers. | ||
55 | |||
56 | EBUSY | ||
57 | Returned by SMBus adapters when the bus was busy for longer | ||
58 | than allowed. This usually indicates some device (maybe the | ||
59 | SMBus adapter) needs some fault recovery (such as resetting), | ||
60 | or that the reset was attempted but failed. | ||
61 | |||
62 | EINVAL | ||
63 | This rather vague error means an invalid parameter has been | ||
64 | detected before any I/O operation was started. Use a more | ||
65 | specific fault code when you can. | ||
66 | |||
67 | One example would be a driver trying an SMBus Block Write | ||
68 | with block size outside the range of 1-32 bytes. | ||
69 | |||
70 | EIO | ||
71 | This rather vague error means something went wrong when | ||
72 | performing an I/O operation. Use a more specific fault | ||
73 | code when you can. | ||
74 | |||
75 | ENODEV | ||
76 | Returned by driver probe() methods. This is a bit more | ||
77 | specific than ENXIO, implying the problem isn't with the | ||
78 | address, but with the device found there. Driver probes | ||
79 | may verify the device returns *correct* responses, and | ||
80 | return this as appropriate. (The driver core will warn | ||
81 | about probe faults other than ENXIO and ENODEV.) | ||
82 | |||
83 | ENOMEM | ||
84 | Returned by any component that can't allocate memory when | ||
85 | it needs to do so. | ||
86 | |||
87 | ENXIO | ||
88 | Returned by I2C adapters to indicate that the address phase | ||
89 | of a transfer didn't get an ACK. While it might just mean | ||
90 | an I2C device was temporarily not responding, usually it | ||
91 | means there's nothing listening at that address. | ||
92 | |||
93 | Returned by driver probe() methods to indicate that they | ||
94 | found no device to bind to. (ENODEV may also be used.) | ||
95 | |||
96 | EOPNOTSUPP | ||
97 | Returned by an adapter when asked to perform an operation | ||
98 | that it doesn't, or can't, support. | ||
99 | |||
100 | For example, this would be returned when an adapter that | ||
101 | doesn't support SMBus block transfers is asked to execute | ||
102 | one. In that case, the driver making that request should | ||
103 | have verified that functionality was supported before it | ||
104 | made that block transfer request. | ||
105 | |||
106 | Similarly, if an I2C adapter can't execute all legal I2C | ||
107 | messages, it should return this when asked to perform a | ||
108 | transaction it can't. (These limitations can't be seen in | ||
109 | the adapter's functionality mask, since the assumption is | ||
110 | that if an adapter supports I2C it supports all of I2C.) | ||
111 | |||
112 | EPROTO | ||
113 | Returned when slave does not conform to the relevant I2C | ||
114 | or SMBus (or chip-specific) protocol specifications. One | ||
115 | case is when the length of an SMBus block data response | ||
116 | (from the SMBus slave) is outside the range 1-32 bytes. | ||
117 | |||
118 | ETIMEDOUT | ||
119 | This is returned by drivers when an operation took too much | ||
120 | time, and was aborted before it completed. | ||
121 | |||
122 | SMBus adapters may return it when an operation took more | ||
123 | time than allowed by the SMBus specification; for example, | ||
124 | when a slave stretches clocks too far. I2C has no such | ||
125 | timeouts, but it's normal for I2C adapters to impose some | ||
126 | arbitrary limits (much longer than SMBus!) too. | ||
127 | |||
diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol index 03f08fb491cc..24bfb65da17d 100644 --- a/Documentation/i2c/smbus-protocol +++ b/Documentation/i2c/smbus-protocol | |||
@@ -42,8 +42,8 @@ Count (8 bits): A data byte containing the length of a block operation. | |||
42 | [..]: Data sent by I2C device, as opposed to data sent by the host adapter. | 42 | [..]: Data sent by I2C device, as opposed to data sent by the host adapter. |
43 | 43 | ||
44 | 44 | ||
45 | SMBus Quick Command: i2c_smbus_write_quick() | 45 | SMBus Quick Command |
46 | ============================================= | 46 | =================== |
47 | 47 | ||
48 | This sends a single bit to the device, at the place of the Rd/Wr bit. | 48 | This sends a single bit to the device, at the place of the Rd/Wr bit. |
49 | 49 | ||
diff --git a/Documentation/i2c/upgrading-clients b/Documentation/i2c/upgrading-clients new file mode 100644 index 000000000000..9a45f9bb6a25 --- /dev/null +++ b/Documentation/i2c/upgrading-clients | |||
@@ -0,0 +1,281 @@ | |||
1 | Upgrading I2C Drivers to the new 2.6 Driver Model | ||
2 | ================================================= | ||
3 | |||
4 | Ben Dooks <ben-linux@fluff.org> | ||
5 | |||
6 | Introduction | ||
7 | ------------ | ||
8 | |||
9 | This guide outlines how to alter existing Linux 2.6 client drivers from | ||
10 | the old to the new new binding methods. | ||
11 | |||
12 | |||
13 | Example old-style driver | ||
14 | ------------------------ | ||
15 | |||
16 | |||
17 | struct example_state { | ||
18 | struct i2c_client client; | ||
19 | .... | ||
20 | }; | ||
21 | |||
22 | static struct i2c_driver example_driver; | ||
23 | |||
24 | static unsigned short ignore[] = { I2C_CLIENT_END }; | ||
25 | static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END }; | ||
26 | |||
27 | I2C_CLIENT_INSMOD; | ||
28 | |||
29 | static int example_attach(struct i2c_adapter *adap, int addr, int kind) | ||
30 | { | ||
31 | struct example_state *state; | ||
32 | struct device *dev = &adap->dev; /* to use for dev_ reports */ | ||
33 | int ret; | ||
34 | |||
35 | state = kzalloc(sizeof(struct example_state), GFP_KERNEL); | ||
36 | if (state == NULL) { | ||
37 | dev_err(dev, "failed to create our state\n"); | ||
38 | return -ENOMEM; | ||
39 | } | ||
40 | |||
41 | example->client.addr = addr; | ||
42 | example->client.flags = 0; | ||
43 | example->client.adapter = adap; | ||
44 | |||
45 | i2c_set_clientdata(&state->i2c_client, state); | ||
46 | strlcpy(client->i2c_client.name, "example", I2C_NAME_SIZE); | ||
47 | |||
48 | ret = i2c_attach_client(&state->i2c_client); | ||
49 | if (ret < 0) { | ||
50 | dev_err(dev, "failed to attach client\n"); | ||
51 | kfree(state); | ||
52 | return ret; | ||
53 | } | ||
54 | |||
55 | dev = &state->i2c_client.dev; | ||
56 | |||
57 | /* rest of the initialisation goes here. */ | ||
58 | |||
59 | dev_info(dev, "example client created\n"); | ||
60 | |||
61 | return 0; | ||
62 | } | ||
63 | |||
64 | static int __devexit example_detach(struct i2c_client *client) | ||
65 | { | ||
66 | struct example_state *state = i2c_get_clientdata(client); | ||
67 | |||
68 | i2c_detach_client(client); | ||
69 | kfree(state); | ||
70 | return 0; | ||
71 | } | ||
72 | |||
73 | static int example_attach_adapter(struct i2c_adapter *adap) | ||
74 | { | ||
75 | return i2c_probe(adap, &addr_data, example_attach); | ||
76 | } | ||
77 | |||
78 | static struct i2c_driver example_driver = { | ||
79 | .driver = { | ||
80 | .owner = THIS_MODULE, | ||
81 | .name = "example", | ||
82 | }, | ||
83 | .attach_adapter = example_attach_adapter, | ||
84 | .detach_client = __devexit_p(example_detach), | ||
85 | .suspend = example_suspend, | ||
86 | .resume = example_resume, | ||
87 | }; | ||
88 | |||
89 | |||
90 | Updating the client | ||
91 | ------------------- | ||
92 | |||
93 | The new style binding model will check against a list of supported | ||
94 | devices and their associated address supplied by the code registering | ||
95 | the busses. This means that the driver .attach_adapter and | ||
96 | .detach_adapter methods can be removed, along with the addr_data, | ||
97 | as follows: | ||
98 | |||
99 | - static struct i2c_driver example_driver; | ||
100 | |||
101 | - static unsigned short ignore[] = { I2C_CLIENT_END }; | ||
102 | - static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END }; | ||
103 | |||
104 | - I2C_CLIENT_INSMOD; | ||
105 | |||
106 | - static int example_attach_adapter(struct i2c_adapter *adap) | ||
107 | - { | ||
108 | - return i2c_probe(adap, &addr_data, example_attach); | ||
109 | - } | ||
110 | |||
111 | static struct i2c_driver example_driver = { | ||
112 | - .attach_adapter = example_attach_adapter, | ||
113 | - .detach_client = __devexit_p(example_detach), | ||
114 | } | ||
115 | |||
116 | Add the probe and remove methods to the i2c_driver, as so: | ||
117 | |||
118 | static struct i2c_driver example_driver = { | ||
119 | + .probe = example_probe, | ||
120 | + .remove = __devexit_p(example_remove), | ||
121 | } | ||
122 | |||
123 | Change the example_attach method to accept the new parameters | ||
124 | which include the i2c_client that it will be working with: | ||
125 | |||
126 | - static int example_attach(struct i2c_adapter *adap, int addr, int kind) | ||
127 | + static int example_probe(struct i2c_client *client, | ||
128 | + const struct i2c_device_id *id) | ||
129 | |||
130 | Change the name of example_attach to example_probe to align it with the | ||
131 | i2c_driver entry names. The rest of the probe routine will now need to be | ||
132 | changed as the i2c_client has already been setup for use. | ||
133 | |||
134 | The necessary client fields have already been setup before | ||
135 | the probe function is called, so the following client setup | ||
136 | can be removed: | ||
137 | |||
138 | - example->client.addr = addr; | ||
139 | - example->client.flags = 0; | ||
140 | - example->client.adapter = adap; | ||
141 | - | ||
142 | - strlcpy(client->i2c_client.name, "example", I2C_NAME_SIZE); | ||
143 | |||
144 | The i2c_set_clientdata is now: | ||
145 | |||
146 | - i2c_set_clientdata(&state->client, state); | ||
147 | + i2c_set_clientdata(client, state); | ||
148 | |||
149 | The call to i2c_attach_client is no longer needed, if the probe | ||
150 | routine exits successfully, then the driver will be automatically | ||
151 | attached by the core. Change the probe routine as so: | ||
152 | |||
153 | - ret = i2c_attach_client(&state->i2c_client); | ||
154 | - if (ret < 0) { | ||
155 | - dev_err(dev, "failed to attach client\n"); | ||
156 | - kfree(state); | ||
157 | - return ret; | ||
158 | - } | ||
159 | |||
160 | |||
161 | Remove the storage of 'struct i2c_client' from the 'struct example_state' | ||
162 | as we are provided with the i2c_client in our example_probe. Instead we | ||
163 | store a pointer to it for when it is needed. | ||
164 | |||
165 | struct example_state { | ||
166 | - struct i2c_client client; | ||
167 | + struct i2c_client *client; | ||
168 | |||
169 | the new i2c client as so: | ||
170 | |||
171 | - struct device *dev = &adap->dev; /* to use for dev_ reports */ | ||
172 | + struct device *dev = &i2c_client->dev; /* to use for dev_ reports */ | ||
173 | |||
174 | And remove the change after our client is attached, as the driver no | ||
175 | longer needs to register a new client structure with the core: | ||
176 | |||
177 | - dev = &state->i2c_client.dev; | ||
178 | |||
179 | In the probe routine, ensure that the new state has the client stored | ||
180 | in it: | ||
181 | |||
182 | static int example_probe(struct i2c_client *i2c_client, | ||
183 | const struct i2c_device_id *id) | ||
184 | { | ||
185 | struct example_state *state; | ||
186 | struct device *dev = &i2c_client->dev; | ||
187 | int ret; | ||
188 | |||
189 | state = kzalloc(sizeof(struct example_state), GFP_KERNEL); | ||
190 | if (state == NULL) { | ||
191 | dev_err(dev, "failed to create our state\n"); | ||
192 | return -ENOMEM; | ||
193 | } | ||
194 | |||
195 | + state->client = i2c_client; | ||
196 | |||
197 | Update the detach method, by changing the name to _remove and | ||
198 | to delete the i2c_detach_client call. It is possible that you | ||
199 | can also remove the ret variable as it is not not needed for | ||
200 | any of the core functions. | ||
201 | |||
202 | - static int __devexit example_detach(struct i2c_client *client) | ||
203 | + static int __devexit example_remove(struct i2c_client *client) | ||
204 | { | ||
205 | struct example_state *state = i2c_get_clientdata(client); | ||
206 | |||
207 | - i2c_detach_client(client); | ||
208 | |||
209 | And finally ensure that we have the correct ID table for the i2c-core | ||
210 | and other utilities: | ||
211 | |||
212 | + struct i2c_device_id example_idtable[] = { | ||
213 | + { "example", 0 }, | ||
214 | + { } | ||
215 | +}; | ||
216 | + | ||
217 | +MODULE_DEVICE_TABLE(i2c, example_idtable); | ||
218 | |||
219 | static struct i2c_driver example_driver = { | ||
220 | .driver = { | ||
221 | .owner = THIS_MODULE, | ||
222 | .name = "example", | ||
223 | }, | ||
224 | + .id_table = example_ids, | ||
225 | |||
226 | |||
227 | Our driver should now look like this: | ||
228 | |||
229 | struct example_state { | ||
230 | struct i2c_client *client; | ||
231 | .... | ||
232 | }; | ||
233 | |||
234 | static int example_probe(struct i2c_client *client, | ||
235 | const struct i2c_device_id *id) | ||
236 | { | ||
237 | struct example_state *state; | ||
238 | struct device *dev = &client->dev; | ||
239 | |||
240 | state = kzalloc(sizeof(struct example_state), GFP_KERNEL); | ||
241 | if (state == NULL) { | ||
242 | dev_err(dev, "failed to create our state\n"); | ||
243 | return -ENOMEM; | ||
244 | } | ||
245 | |||
246 | state->client = client; | ||
247 | i2c_set_clientdata(client, state); | ||
248 | |||
249 | /* rest of the initialisation goes here. */ | ||
250 | |||
251 | dev_info(dev, "example client created\n"); | ||
252 | |||
253 | return 0; | ||
254 | } | ||
255 | |||
256 | static int __devexit example_remove(struct i2c_client *client) | ||
257 | { | ||
258 | struct example_state *state = i2c_get_clientdata(client); | ||
259 | |||
260 | kfree(state); | ||
261 | return 0; | ||
262 | } | ||
263 | |||
264 | static struct i2c_device_id example_idtable[] = { | ||
265 | { "example", 0 }, | ||
266 | { } | ||
267 | }; | ||
268 | |||
269 | MODULE_DEVICE_TABLE(i2c, example_idtable); | ||
270 | |||
271 | static struct i2c_driver example_driver = { | ||
272 | .driver = { | ||
273 | .owner = THIS_MODULE, | ||
274 | .name = "example", | ||
275 | }, | ||
276 | .id_table = example_idtable, | ||
277 | .probe = example_probe, | ||
278 | .remove = __devexit_p(example_remove), | ||
279 | .suspend = example_suspend, | ||
280 | .resume = example_resume, | ||
281 | }; | ||
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index d4cd4126d1ad..6b61b3a2e90b 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients | |||
@@ -44,6 +44,10 @@ static struct i2c_driver foo_driver = { | |||
44 | .id_table = foo_ids, | 44 | .id_table = foo_ids, |
45 | .probe = foo_probe, | 45 | .probe = foo_probe, |
46 | .remove = foo_remove, | 46 | .remove = foo_remove, |
47 | /* if device autodetection is needed: */ | ||
48 | .class = I2C_CLASS_SOMETHING, | ||
49 | .detect = foo_detect, | ||
50 | .address_data = &addr_data, | ||
47 | 51 | ||
48 | /* else, driver uses "legacy" binding model: */ | 52 | /* else, driver uses "legacy" binding model: */ |
49 | .attach_adapter = foo_attach_adapter, | 53 | .attach_adapter = foo_attach_adapter, |
@@ -217,6 +221,31 @@ in the I2C bus driver. You may want to save the returned i2c_client | |||
217 | reference for later use. | 221 | reference for later use. |
218 | 222 | ||
219 | 223 | ||
224 | Device Detection (Standard driver model) | ||
225 | ---------------------------------------- | ||
226 | |||
227 | Sometimes you do not know in advance which I2C devices are connected to | ||
228 | a given I2C bus. This is for example the case of hardware monitoring | ||
229 | devices on a PC's SMBus. In that case, you may want to let your driver | ||
230 | detect supported devices automatically. This is how the legacy model | ||
231 | was working, and is now available as an extension to the standard | ||
232 | driver model (so that we can finally get rid of the legacy model.) | ||
233 | |||
234 | You simply have to define a detect callback which will attempt to | ||
235 | identify supported devices (returning 0 for supported ones and -ENODEV | ||
236 | for unsupported ones), a list of addresses to probe, and a device type | ||
237 | (or class) so that only I2C buses which may have that type of device | ||
238 | connected (and not otherwise enumerated) will be probed. The i2c | ||
239 | core will then call you back as needed and will instantiate a device | ||
240 | for you for every successful detection. | ||
241 | |||
242 | Note that this mechanism is purely optional and not suitable for all | ||
243 | devices. You need some reliable way to identify the supported devices | ||
244 | (typically using device-specific, dedicated identification registers), | ||
245 | otherwise misdetections are likely to occur and things can get wrong | ||
246 | quickly. | ||
247 | |||
248 | |||
220 | Device Deletion (Standard driver model) | 249 | Device Deletion (Standard driver model) |
221 | --------------------------------------- | 250 | --------------------------------------- |
222 | 251 | ||
@@ -569,7 +598,6 @@ SMBus communication | |||
569 | in terms of it. Never use this function directly! | 598 | in terms of it. Never use this function directly! |
570 | 599 | ||
571 | 600 | ||
572 | extern s32 i2c_smbus_write_quick(struct i2c_client * client, u8 value); | ||
573 | extern s32 i2c_smbus_read_byte(struct i2c_client * client); | 601 | extern s32 i2c_smbus_read_byte(struct i2c_client * client); |
574 | extern s32 i2c_smbus_write_byte(struct i2c_client * client, u8 value); | 602 | extern s32 i2c_smbus_write_byte(struct i2c_client * client, u8 value); |
575 | extern s32 i2c_smbus_read_byte_data(struct i2c_client * client, u8 command); | 603 | extern s32 i2c_smbus_read_byte_data(struct i2c_client * client, u8 command); |
@@ -578,30 +606,31 @@ SMBus communication | |||
578 | extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command); | 606 | extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command); |
579 | extern s32 i2c_smbus_write_word_data(struct i2c_client * client, | 607 | extern s32 i2c_smbus_write_word_data(struct i2c_client * client, |
580 | u8 command, u16 value); | 608 | u8 command, u16 value); |
609 | extern s32 i2c_smbus_read_block_data(struct i2c_client * client, | ||
610 | u8 command, u8 *values); | ||
581 | extern s32 i2c_smbus_write_block_data(struct i2c_client * client, | 611 | extern s32 i2c_smbus_write_block_data(struct i2c_client * client, |
582 | u8 command, u8 length, | 612 | u8 command, u8 length, |
583 | u8 *values); | 613 | u8 *values); |
584 | extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client, | 614 | extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client, |
585 | u8 command, u8 length, u8 *values); | 615 | u8 command, u8 length, u8 *values); |
586 | |||
587 | These ones were removed in Linux 2.6.10 because they had no users, but could | ||
588 | be added back later if needed: | ||
589 | |||
590 | extern s32 i2c_smbus_read_block_data(struct i2c_client * client, | ||
591 | u8 command, u8 *values); | ||
592 | extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client, | 616 | extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client, |
593 | u8 command, u8 length, | 617 | u8 command, u8 length, |
594 | u8 *values); | 618 | u8 *values); |
619 | |||
620 | These ones were removed from i2c-core because they had no users, but could | ||
621 | be added back later if needed: | ||
622 | |||
623 | extern s32 i2c_smbus_write_quick(struct i2c_client * client, u8 value); | ||
595 | extern s32 i2c_smbus_process_call(struct i2c_client * client, | 624 | extern s32 i2c_smbus_process_call(struct i2c_client * client, |
596 | u8 command, u16 value); | 625 | u8 command, u16 value); |
597 | extern s32 i2c_smbus_block_process_call(struct i2c_client *client, | 626 | extern s32 i2c_smbus_block_process_call(struct i2c_client *client, |
598 | u8 command, u8 length, | 627 | u8 command, u8 length, |
599 | u8 *values) | 628 | u8 *values) |
600 | 629 | ||
601 | All these transactions return -1 on failure. The 'write' transactions | 630 | All these transactions return a negative errno value on failure. The 'write' |
602 | return 0 on success; the 'read' transactions return the read value, except | 631 | transactions return 0 on success; the 'read' transactions return the read |
603 | for read_block, which returns the number of values read. The block buffers | 632 | value, except for block transactions, which return the number of values |
604 | need not be longer than 32 bytes. | 633 | read. The block buffers need not be longer than 32 bytes. |
605 | 634 | ||
606 | You can read the file `smbus-protocol' for more information about the | 635 | You can read the file `smbus-protocol' for more information about the |
607 | actual SMBus protocol. | 636 | actual SMBus protocol. |
diff --git a/Documentation/ia64/kvm.txt b/Documentation/ia64/kvm.txt index bec9d815da33..914d07f49268 100644 --- a/Documentation/ia64/kvm.txt +++ b/Documentation/ia64/kvm.txt | |||
@@ -50,9 +50,9 @@ Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qe | |||
50 | /usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image | 50 | /usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image |
51 | (xx is the number of virtual processors for the guest, now the maximum value is 4) | 51 | (xx is the number of virtual processors for the guest, now the maximum value is 4) |
52 | 52 | ||
53 | 5. Known possibile issue on some platforms with old Firmware. | 53 | 5. Known possible issue on some platforms with old Firmware. |
54 | 54 | ||
55 | If meet strange host crashe issues, try to solve it through either of the following ways: | 55 | In the event of strange host crash issues, try to solve it through either of the following ways: |
56 | 56 | ||
57 | (1): Upgrade your Firmware to the latest one. | 57 | (1): Upgrade your Firmware to the latest one. |
58 | 58 | ||
@@ -65,8 +65,8 @@ index 0b53344..f02b0f7 100644 | |||
65 | mov ar.pfs = loc1 | 65 | mov ar.pfs = loc1 |
66 | mov rp = loc0 | 66 | mov rp = loc0 |
67 | ;; | 67 | ;; |
68 | - srlz.d // seralize restoration of psr.l | 68 | - srlz.d // serialize restoration of psr.l |
69 | + srlz.i // seralize restoration of psr.l | 69 | + srlz.i // serialize restoration of psr.l |
70 | + ;; | 70 | + ;; |
71 | br.ret.sptk.many b0 | 71 | br.ret.sptk.many b0 |
72 | END(ia64_pal_call_static) | 72 | END(ia64_pal_call_static) |
diff --git a/Documentation/ia64/paravirt_ops.txt b/Documentation/ia64/paravirt_ops.txt new file mode 100644 index 000000000000..39ded02ec33f --- /dev/null +++ b/Documentation/ia64/paravirt_ops.txt | |||
@@ -0,0 +1,137 @@ | |||
1 | Paravirt_ops on IA64 | ||
2 | ==================== | ||
3 | 21 May 2008, Isaku Yamahata <yamahata@valinux.co.jp> | ||
4 | |||
5 | |||
6 | Introduction | ||
7 | ------------ | ||
8 | The aim of this documentation is to help with maintainability and/or to | ||
9 | encourage people to use paravirt_ops/IA64. | ||
10 | |||
11 | paravirt_ops (pv_ops in short) is a way for virtualization support of | ||
12 | Linux kernel on x86. Several ways for virtualization support were | ||
13 | proposed, paravirt_ops is the winner. | ||
14 | On the other hand, now there are also several IA64 virtualization | ||
15 | technologies like kvm/IA64, xen/IA64 and many other academic IA64 | ||
16 | hypervisors so that it is good to add generic virtualization | ||
17 | infrastructure on Linux/IA64. | ||
18 | |||
19 | |||
20 | What is paravirt_ops? | ||
21 | --------------------- | ||
22 | It has been developed on x86 as virtualization support via API, not ABI. | ||
23 | It allows each hypervisor to override operations which are important for | ||
24 | hypervisors at API level. And it allows a single kernel binary to run on | ||
25 | all supported execution environments including native machine. | ||
26 | Essentially paravirt_ops is a set of function pointers which represent | ||
27 | operations corresponding to low level sensitive instructions and high | ||
28 | level functionalities in various area. But one significant difference | ||
29 | from usual function pointer table is that it allows optimization with | ||
30 | binary patch. It is because some of these operations are very | ||
31 | performance sensitive and indirect call overhead is not negligible. | ||
32 | With binary patch, indirect C function call can be transformed into | ||
33 | direct C function call or in-place execution to eliminate the overhead. | ||
34 | |||
35 | Thus, operations of paravirt_ops are classified into three categories. | ||
36 | - simple indirect call | ||
37 | These operations correspond to high level functionality so that the | ||
38 | overhead of indirect call isn't very important. | ||
39 | |||
40 | - indirect call which allows optimization with binary patch | ||
41 | Usually these operations correspond to low level instructions. They | ||
42 | are called frequently and performance critical. So the overhead is | ||
43 | very important. | ||
44 | |||
45 | - a set of macros for hand written assembly code | ||
46 | Hand written assembly codes (.S files) also need paravirtualization | ||
47 | because they include sensitive instructions or some of code paths in | ||
48 | them are very performance critical. | ||
49 | |||
50 | |||
51 | The relation to the IA64 machine vector | ||
52 | --------------------------------------- | ||
53 | Linux/IA64 has the IA64 machine vector functionality which allows the | ||
54 | kernel to switch implementations (e.g. initialization, ipi, dma api...) | ||
55 | depending on executing platform. | ||
56 | We can replace some implementations very easily defining a new machine | ||
57 | vector. Thus another approach for virtualization support would be | ||
58 | enhancing the machine vector functionality. | ||
59 | But paravirt_ops approach was taken because | ||
60 | - virtualization support needs wider support than machine vector does. | ||
61 | e.g. low level instruction paravirtualization. It must be | ||
62 | initialized very early before platform detection. | ||
63 | |||
64 | - virtualization support needs more functionality like binary patch. | ||
65 | Probably the calling overhead might not be very large compared to the | ||
66 | emulation overhead of virtualization. However in the native case, the | ||
67 | overhead should be eliminated completely. | ||
68 | A single kernel binary should run on each environment including native, | ||
69 | and the overhead of paravirt_ops on native environment should be as | ||
70 | small as possible. | ||
71 | |||
72 | - for full virtualization technology, e.g. KVM/IA64 or | ||
73 | Xen/IA64 HVM domain, the result would be | ||
74 | (the emulated platform machine vector. probably dig) + (pv_ops). | ||
75 | This means that the virtualization support layer should be under | ||
76 | the machine vector layer. | ||
77 | |||
78 | Possibly it might be better to move some function pointers from | ||
79 | paravirt_ops to machine vector. In fact, Xen domU case utilizes both | ||
80 | pv_ops and machine vector. | ||
81 | |||
82 | |||
83 | IA64 paravirt_ops | ||
84 | ----------------- | ||
85 | In this section, the concrete paravirt_ops will be discussed. | ||
86 | Because of the architecture difference between ia64 and x86, the | ||
87 | resulting set of functions is very different from x86 pv_ops. | ||
88 | |||
89 | - C function pointer tables | ||
90 | They are not very performance critical so that simple C indirect | ||
91 | function call is acceptable. The following structures are defined at | ||
92 | this moment. For details see linux/include/asm-ia64/paravirt.h | ||
93 | - struct pv_info | ||
94 | This structure describes the execution environment. | ||
95 | - struct pv_init_ops | ||
96 | This structure describes the various initialization hooks. | ||
97 | - struct pv_iosapic_ops | ||
98 | This structure describes hooks to iosapic operations. | ||
99 | - struct pv_irq_ops | ||
100 | This structure describes hooks to irq related operations | ||
101 | - struct pv_time_op | ||
102 | This structure describes hooks to steal time accounting. | ||
103 | |||
104 | - a set of indirect calls which need optimization | ||
105 | Currently this class of functions correspond to a subset of IA64 | ||
106 | intrinsics. At this moment the optimization with binary patch isn't | ||
107 | implemented yet. | ||
108 | struct pv_cpu_op is defined. For details see | ||
109 | linux/include/asm-ia64/paravirt_privop.h | ||
110 | Mostly they correspond to ia64 intrinsics 1-to-1. | ||
111 | Caveat: Now they are defined as C indirect function pointers, but in | ||
112 | order to support binary patch optimization, they will be changed | ||
113 | using GCC extended inline assembly code. | ||
114 | |||
115 | - a set of macros for hand written assembly code (.S files) | ||
116 | For maintenance purpose, the taken approach for .S files is single | ||
117 | source code and compile multiple times with different macros definitions. | ||
118 | Each pv_ops instance must define those macros to compile. | ||
119 | The important thing here is that sensitive, but non-privileged | ||
120 | instructions must be paravirtualized and that some privileged | ||
121 | instructions also need paravirtualization for reasonable performance. | ||
122 | Developers who modify .S files must be aware of that. At this moment | ||
123 | an easy checker is implemented to detect paravirtualization breakage. | ||
124 | But it doesn't cover all the cases. | ||
125 | |||
126 | Sometimes this set of macros is called pv_cpu_asm_op. But there is no | ||
127 | corresponding structure in the source code. | ||
128 | Those macros mostly 1:1 correspond to a subset of privileged | ||
129 | instructions. See linux/include/asm-ia64/native/inst.h. | ||
130 | And some functions written in assembly also need to be overrided so | ||
131 | that each pv_ops instance have to define some macros. Again see | ||
132 | linux/include/asm-ia64/native/inst.h. | ||
133 | |||
134 | |||
135 | Those structures must be initialized very early before start_kernel. | ||
136 | Probably initialized in head.S using multi entry point or some other trick. | ||
137 | For native case implementation see linux/arch/ia64/kernel/paravirt.c. | ||
diff --git a/Documentation/input/cs461x.txt b/Documentation/input/cs461x.txt index afe0d6543e09..202e9dbacec3 100644 --- a/Documentation/input/cs461x.txt +++ b/Documentation/input/cs461x.txt | |||
@@ -31,7 +31,7 @@ The driver works with ALSA drivers simultaneously. For example, the xracer | |||
31 | uses joystick as input device and PCM device as sound output in one time. | 31 | uses joystick as input device and PCM device as sound output in one time. |
32 | There are no sound or input collisions detected. The source code have | 32 | There are no sound or input collisions detected. The source code have |
33 | comments about them; but I've found the joystick can be initialized | 33 | comments about them; but I've found the joystick can be initialized |
34 | separately of ALSA modules. So, you canm use only one joystick driver | 34 | separately of ALSA modules. So, you can use only one joystick driver |
35 | without ALSA drivers. The ALSA drivers are not needed to compile or | 35 | without ALSA drivers. The ALSA drivers are not needed to compile or |
36 | run this driver. | 36 | run this driver. |
37 | 37 | ||
diff --git a/Documentation/input/gameport-programming.txt b/Documentation/input/gameport-programming.txt index 14e0a8b70225..03a74fc3b496 100644 --- a/Documentation/input/gameport-programming.txt +++ b/Documentation/input/gameport-programming.txt | |||
@@ -1,5 +1,3 @@ | |||
1 | $Id: gameport-programming.txt,v 1.3 2001/04/24 13:51:37 vojtech Exp $ | ||
2 | |||
3 | Programming gameport drivers | 1 | Programming gameport drivers |
4 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 2 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
5 | 3 | ||
diff --git a/Documentation/input/input.txt b/Documentation/input/input.txt index ff8cea0225f9..686ee9932dff 100644 --- a/Documentation/input/input.txt +++ b/Documentation/input/input.txt | |||
@@ -1,7 +1,6 @@ | |||
1 | Linux Input drivers v1.0 | 1 | Linux Input drivers v1.0 |
2 | (c) 1999-2001 Vojtech Pavlik <vojtech@ucw.cz> | 2 | (c) 1999-2001 Vojtech Pavlik <vojtech@ucw.cz> |
3 | Sponsored by SuSE | 3 | Sponsored by SuSE |
4 | $Id: input.txt,v 1.8 2002/05/29 03:15:01 bradleym Exp $ | ||
5 | ---------------------------------------------------------------------------- | 4 | ---------------------------------------------------------------------------- |
6 | 5 | ||
7 | 0. Disclaimer | 6 | 0. Disclaimer |
diff --git a/Documentation/input/joystick-api.txt b/Documentation/input/joystick-api.txt index acbd32b88454..c507330740cd 100644 --- a/Documentation/input/joystick-api.txt +++ b/Documentation/input/joystick-api.txt | |||
@@ -5,8 +5,6 @@ | |||
5 | 5 | ||
6 | 7 Aug 1998 | 6 | 7 Aug 1998 |
7 | 7 | ||
8 | $Id: joystick-api.txt,v 1.2 2001/05/08 21:21:23 vojtech Exp $ | ||
9 | |||
10 | 1. Initialization | 8 | 1. Initialization |
11 | ~~~~~~~~~~~~~~~~~ | 9 | ~~~~~~~~~~~~~~~~~ |
12 | 10 | ||
diff --git a/Documentation/input/joystick-parport.txt b/Documentation/input/joystick-parport.txt index ede5f33daad3..1c856f32ff2c 100644 --- a/Documentation/input/joystick-parport.txt +++ b/Documentation/input/joystick-parport.txt | |||
@@ -2,7 +2,6 @@ | |||
2 | (c) 1998-2000 Vojtech Pavlik <vojtech@ucw.cz> | 2 | (c) 1998-2000 Vojtech Pavlik <vojtech@ucw.cz> |
3 | (c) 1998 Andree Borrmann <a.borrmann@tu-bs.de> | 3 | (c) 1998 Andree Borrmann <a.borrmann@tu-bs.de> |
4 | Sponsored by SuSE | 4 | Sponsored by SuSE |
5 | $Id: joystick-parport.txt,v 1.6 2001/09/25 09:31:32 vojtech Exp $ | ||
6 | ---------------------------------------------------------------------------- | 5 | ---------------------------------------------------------------------------- |
7 | 6 | ||
8 | 0. Disclaimer | 7 | 0. Disclaimer |
diff --git a/Documentation/input/joystick.txt b/Documentation/input/joystick.txt index 389de9bd9878..154d767b2acb 100644 --- a/Documentation/input/joystick.txt +++ b/Documentation/input/joystick.txt | |||
@@ -1,7 +1,6 @@ | |||
1 | Linux Joystick driver v2.0.0 | 1 | Linux Joystick driver v2.0.0 |
2 | (c) 1996-2000 Vojtech Pavlik <vojtech@ucw.cz> | 2 | (c) 1996-2000 Vojtech Pavlik <vojtech@ucw.cz> |
3 | Sponsored by SuSE | 3 | Sponsored by SuSE |
4 | $Id: joystick.txt,v 1.12 2002/03/03 12:13:07 jdeneux Exp $ | ||
5 | ---------------------------------------------------------------------------- | 4 | ---------------------------------------------------------------------------- |
6 | 5 | ||
7 | 0. Disclaimer | 6 | 0. Disclaimer |
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt index 240ce7a56c40..3bb5f466a90d 100644 --- a/Documentation/ioctl-number.txt +++ b/Documentation/ioctl-number.txt | |||
@@ -117,6 +117,7 @@ Code Seq# Include File Comments | |||
117 | <mailto:natalia@nikhefk.nikhef.nl> | 117 | <mailto:natalia@nikhefk.nikhef.nl> |
118 | 'c' 00-7F linux/comstats.h conflict! | 118 | 'c' 00-7F linux/comstats.h conflict! |
119 | 'c' 00-7F linux/coda.h conflict! | 119 | 'c' 00-7F linux/coda.h conflict! |
120 | 'c' 80-9F asm-s390/chsc.h | ||
120 | 'd' 00-FF linux/char/drm/drm/h conflict! | 121 | 'd' 00-FF linux/char/drm/drm/h conflict! |
121 | 'd' 00-DF linux/video_decoder.h conflict! | 122 | 'd' 00-DF linux/video_decoder.h conflict! |
122 | 'd' F0-FF linux/digi1.h | 123 | 'd' F0-FF linux/digi1.h |
diff --git a/Documentation/ioctl/hdio.txt b/Documentation/ioctl/hdio.txt index c19efdeace2c..91a6ecbae0bb 100644 --- a/Documentation/ioctl/hdio.txt +++ b/Documentation/ioctl/hdio.txt | |||
@@ -508,12 +508,13 @@ HDIO_DRIVE_RESET execute a device reset | |||
508 | 508 | ||
509 | error returns: | 509 | error returns: |
510 | EACCES Access denied: requires CAP_SYS_ADMIN | 510 | EACCES Access denied: requires CAP_SYS_ADMIN |
511 | ENXIO No such device: phy dead or ctl_addr == 0 | ||
512 | EIO I/O error: reset timed out or hardware error | ||
511 | 513 | ||
512 | notes: | 514 | notes: |
513 | 515 | ||
514 | Abort any current command, prevent anything else from being | 516 | Execute a reset on the device as soon as the current IO |
515 | queued, execute a reset on the device, and issue BLKRRPART | 517 | operation has completed. |
516 | ioctl on the block device. | ||
517 | 518 | ||
518 | Executes an ATAPI soft reset if applicable, otherwise | 519 | Executes an ATAPI soft reset if applicable, otherwise |
519 | executes an ATA soft reset on the controller. | 520 | executes an ATA soft reset on the controller. |
diff --git a/Documentation/ioctl/ioctl-decoding.txt b/Documentation/ioctl/ioctl-decoding.txt index bfdf7f3ee4f0..e35efb0cec2e 100644 --- a/Documentation/ioctl/ioctl-decoding.txt +++ b/Documentation/ioctl/ioctl-decoding.txt | |||
@@ -1,6 +1,6 @@ | |||
1 | To decode a hex IOCTL code: | 1 | To decode a hex IOCTL code: |
2 | 2 | ||
3 | Most architecures use this generic format, but check | 3 | Most architectures use this generic format, but check |
4 | include/ARCH/ioctl.h for specifics, e.g. powerpc | 4 | include/ARCH/ioctl.h for specifics, e.g. powerpc |
5 | uses 3 bits to encode read/write and 13 bits for size. | 5 | uses 3 bits to encode read/write and 13 bits for size. |
6 | 6 | ||
@@ -18,7 +18,7 @@ uses 3 bits to encode read/write and 13 bits for size. | |||
18 | 7-0 function # | 18 | 7-0 function # |
19 | 19 | ||
20 | 20 | ||
21 | So for example 0x82187201 is a read with arg length of 0x218, | 21 | So for example 0x82187201 is a read with arg length of 0x218, |
22 | character 'r' function 1. Grepping the source reveals this is: | 22 | character 'r' function 1. Grepping the source reveals this is: |
23 | 23 | ||
24 | #define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct dirent [2]) | 24 | #define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct dirent [2]) |
diff --git a/Documentation/iostats.txt b/Documentation/iostats.txt index 5925c3cd030d..59a69ec67c40 100644 --- a/Documentation/iostats.txt +++ b/Documentation/iostats.txt | |||
@@ -143,7 +143,7 @@ disk and partition statistics are consistent again. Since we still don't | |||
143 | keep record of the partition-relative address, an operation is attributed to | 143 | keep record of the partition-relative address, an operation is attributed to |
144 | the partition which contains the first sector of the request after the | 144 | the partition which contains the first sector of the request after the |
145 | eventual merges. As requests can be merged across partition, this could lead | 145 | eventual merges. As requests can be merged across partition, this could lead |
146 | to some (probably insignificant) innacuracy. | 146 | to some (probably insignificant) inaccuracy. |
147 | 147 | ||
148 | Additional notes | 148 | Additional notes |
149 | ---------------- | 149 | ---------------- |
diff --git a/Documentation/isdn/README.mISDN b/Documentation/isdn/README.mISDN new file mode 100644 index 000000000000..cd8bf920e77b --- /dev/null +++ b/Documentation/isdn/README.mISDN | |||
@@ -0,0 +1,6 @@ | |||
1 | mISDN is a new modular ISDN driver, in the long term it should replace | ||
2 | the old I4L driver architecture for passiv ISDN cards. | ||
3 | It was designed to allow a broad range of applications and interfaces | ||
4 | but only have the basic function in kernel, the interface to the user | ||
5 | space is based on sockets with a own address family AF_ISDN. | ||
6 | |||
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index b8e52c0355d3..0705040531a5 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt | |||
@@ -65,26 +65,26 @@ Install kexec-tools | |||
65 | 65 | ||
66 | 2) Download the kexec-tools user-space package from the following URL: | 66 | 2) Download the kexec-tools user-space package from the following URL: |
67 | 67 | ||
68 | http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing.tar.gz | 68 | http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools.tar.gz |
69 | 69 | ||
70 | This is a symlink to the latest version, which at the time of writing is | 70 | This is a symlink to the latest version. |
71 | 20061214, the only release of kexec-tools-testing so far. As other versions | ||
72 | are released, the older ones will remain available at | ||
73 | http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/ | ||
74 | 71 | ||
75 | Note: Latest kexec-tools-testing git tree is available at | 72 | The latest kexec-tools git tree is available at: |
76 | 73 | ||
77 | git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git | 74 | git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git |
78 | or | 75 | or |
79 | http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=summary | 76 | http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools.git |
77 | |||
78 | More information about kexec-tools can be found at | ||
79 | http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/README.html | ||
80 | 80 | ||
81 | 3) Unpack the tarball with the tar command, as follows: | 81 | 3) Unpack the tarball with the tar command, as follows: |
82 | 82 | ||
83 | tar xvpzf kexec-tools-testing.tar.gz | 83 | tar xvpzf kexec-tools.tar.gz |
84 | 84 | ||
85 | 4) Change to the kexec-tools directory, as follows: | 85 | 4) Change to the kexec-tools directory, as follows: |
86 | 86 | ||
87 | cd kexec-tools-testing-VERSION | 87 | cd kexec-tools-VERSION |
88 | 88 | ||
89 | 5) Configure the package, as follows: | 89 | 5) Configure the package, as follows: |
90 | 90 | ||
@@ -109,7 +109,7 @@ There are two possible methods of using Kdump. | |||
109 | 2) Or use the system kernel binary itself as dump-capture kernel and there is | 109 | 2) Or use the system kernel binary itself as dump-capture kernel and there is |
110 | no need to build a separate dump-capture kernel. This is possible | 110 | no need to build a separate dump-capture kernel. This is possible |
111 | only with the architecutres which support a relocatable kernel. As | 111 | only with the architecutres which support a relocatable kernel. As |
112 | of today i386 and ia64 architectures support relocatable kernel. | 112 | of today, i386, x86_64 and ia64 architectures support relocatable kernel. |
113 | 113 | ||
114 | Building a relocatable kernel is advantageous from the point of view that | 114 | Building a relocatable kernel is advantageous from the point of view that |
115 | one does not have to build a second kernel for capturing the dump. But | 115 | one does not have to build a second kernel for capturing the dump. But |
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index b52f47d588b4..e7bea3e85304 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -87,7 +87,8 @@ parameter is applicable: | |||
87 | SH SuperH architecture is enabled. | 87 | SH SuperH architecture is enabled. |
88 | SMP The kernel is an SMP kernel. | 88 | SMP The kernel is an SMP kernel. |
89 | SPARC Sparc architecture is enabled. | 89 | SPARC Sparc architecture is enabled. |
90 | SWSUSP Software suspend is enabled. | 90 | SWSUSP Software suspend (hibernation) is enabled. |
91 | SUSPEND System suspend states are enabled. | ||
91 | TS Appropriate touchscreen support is enabled. | 92 | TS Appropriate touchscreen support is enabled. |
92 | USB USB support is enabled. | 93 | USB USB support is enabled. |
93 | USBHID USB Human Interface Device support is enabled. | 94 | USBHID USB Human Interface Device support is enabled. |
@@ -147,10 +148,16 @@ and is between 256 and 4096 characters. It is defined in the file | |||
147 | default: 0 | 148 | default: 0 |
148 | 149 | ||
149 | acpi_sleep= [HW,ACPI] Sleep options | 150 | acpi_sleep= [HW,ACPI] Sleep options |
150 | Format: { s3_bios, s3_mode, s3_beep } | 151 | Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig, old_ordering } |
151 | See Documentation/power/video.txt for s3_bios and s3_mode. | 152 | See Documentation/power/video.txt for s3_bios and s3_mode. |
152 | s3_beep is for debugging; it makes the PC's speaker beep | 153 | s3_beep is for debugging; it makes the PC's speaker beep |
153 | as soon as the kernel's real-mode entry point is called. | 154 | as soon as the kernel's real-mode entry point is called. |
155 | s4_nohwsig prevents ACPI hardware signature from being | ||
156 | used during resume from hibernation. | ||
157 | old_ordering causes the ACPI 1.0 ordering of the _PTS | ||
158 | control method, wrt putting devices into low power | ||
159 | states, to be enforced (the ACPI 2.0 ordering of _PTS is | ||
160 | used by default). | ||
154 | 161 | ||
155 | acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode | 162 | acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode |
156 | Format: { level | edge | high | low } | 163 | Format: { level | edge | high | low } |
@@ -271,6 +278,17 @@ and is between 256 and 4096 characters. It is defined in the file | |||
271 | aic79xx= [HW,SCSI] | 278 | aic79xx= [HW,SCSI] |
272 | See Documentation/scsi/aic79xx.txt. | 279 | See Documentation/scsi/aic79xx.txt. |
273 | 280 | ||
281 | amd_iommu= [HW,X86-84] | ||
282 | Pass parameters to the AMD IOMMU driver in the system. | ||
283 | Possible values are: | ||
284 | isolate - enable device isolation (each device, as far | ||
285 | as possible, will get its own protection | ||
286 | domain) | ||
287 | amd_iommu_size= [HW,X86-64] | ||
288 | Define the size of the aperture for the AMD IOMMU | ||
289 | driver. Possible values are: | ||
290 | '32M', '64M' (default), '128M', '256M', '512M', '1G' | ||
291 | |||
274 | amijoy.map= [HW,JOY] Amiga joystick support | 292 | amijoy.map= [HW,JOY] Amiga joystick support |
275 | Map of devices attached to JOY0DAT and JOY1DAT | 293 | Map of devices attached to JOY0DAT and JOY1DAT |
276 | Format: <a>,<b> | 294 | Format: <a>,<b> |
@@ -560,6 +578,8 @@ and is between 256 and 4096 characters. It is defined in the file | |||
560 | 578 | ||
561 | debug_objects [KNL] Enable object debugging | 579 | debug_objects [KNL] Enable object debugging |
562 | 580 | ||
581 | debugpat [X86] Enable PAT debugging | ||
582 | |||
563 | decnet.addr= [HW,NET] | 583 | decnet.addr= [HW,NET] |
564 | Format: <area>[,<node>] | 584 | Format: <area>[,<node>] |
565 | See also Documentation/networking/decnet.txt. | 585 | See also Documentation/networking/decnet.txt. |
@@ -599,6 +619,29 @@ and is between 256 and 4096 characters. It is defined in the file | |||
599 | See drivers/char/README.epca and | 619 | See drivers/char/README.epca and |
600 | Documentation/digiepca.txt. | 620 | Documentation/digiepca.txt. |
601 | 621 | ||
622 | disable_mtrr_cleanup [X86] | ||
623 | enable_mtrr_cleanup [X86] | ||
624 | The kernel tries to adjust MTRR layout from continuous | ||
625 | to discrete, to make X server driver able to add WB | ||
626 | entry later. This parameter enables/disables that. | ||
627 | |||
628 | mtrr_chunk_size=nn[KMG] [X86] | ||
629 | used for mtrr cleanup. It is largest continous chunk | ||
630 | that could hold holes aka. UC entries. | ||
631 | |||
632 | mtrr_gran_size=nn[KMG] [X86] | ||
633 | Used for mtrr cleanup. It is granularity of mtrr block. | ||
634 | Default is 1. | ||
635 | Large value could prevent small alignment from | ||
636 | using up MTRRs. | ||
637 | |||
638 | mtrr_spare_reg_nr=n [X86] | ||
639 | Format: <integer> | ||
640 | Range: 0,7 : spare reg number | ||
641 | Default : 1 | ||
642 | Used for mtrr cleanup. It is spare mtrr entries number. | ||
643 | Set to 2 or more if your graphical card needs more. | ||
644 | |||
602 | disable_mtrr_trim [X86, Intel and AMD only] | 645 | disable_mtrr_trim [X86, Intel and AMD only] |
603 | By default the kernel will trim any uncacheable | 646 | By default the kernel will trim any uncacheable |
604 | memory out of your available memory pool based on | 647 | memory out of your available memory pool based on |
@@ -722,9 +765,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
722 | hd= [EIDE] (E)IDE hard drive subsystem geometry | 765 | hd= [EIDE] (E)IDE hard drive subsystem geometry |
723 | Format: <cyl>,<head>,<sect> | 766 | Format: <cyl>,<head>,<sect> |
724 | 767 | ||
725 | hd?= [HW] (E)IDE subsystem | ||
726 | hd?lun= See Documentation/ide/ide.txt. | ||
727 | |||
728 | highmem=nn[KMG] [KNL,BOOT] forces the highmem zone to have an exact | 768 | highmem=nn[KMG] [KNL,BOOT] forces the highmem zone to have an exact |
729 | size of <nn>. This works even on boxes that have no | 769 | size of <nn>. This works even on boxes that have no |
730 | highmem otherwise. This also works to reduce highmem | 770 | highmem otherwise. This also works to reduce highmem |
@@ -737,8 +777,22 @@ and is between 256 and 4096 characters. It is defined in the file | |||
737 | hisax= [HW,ISDN] | 777 | hisax= [HW,ISDN] |
738 | See Documentation/isdn/README.HiSax. | 778 | See Documentation/isdn/README.HiSax. |
739 | 779 | ||
740 | hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages. | 780 | hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot. |
741 | hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages. | 781 | hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages. |
782 | On x86-64 and powerpc, this option can be specified | ||
783 | multiple times interleaved with hugepages= to reserve | ||
784 | huge pages of different sizes. Valid pages sizes on | ||
785 | x86-64 are 2M (when the CPU supports "pse") and 1G | ||
786 | (when the CPU supports the "pdpe1gb" cpuinfo flag) | ||
787 | Note that 1GB pages can only be allocated at boot time | ||
788 | using hugepages= and not freed afterwards. | ||
789 | default_hugepagesz= | ||
790 | [same as hugepagesz=] The size of the default | ||
791 | HugeTLB page size. This is the size represented by | ||
792 | the legacy /proc/ hugepages APIs, used for SHM, and | ||
793 | default size when mounting hugetlbfs filesystems. | ||
794 | Defaults to the default architecture's huge page size | ||
795 | if not specified. | ||
742 | 796 | ||
743 | i8042.direct [HW] Put keyboard port into non-translated mode | 797 | i8042.direct [HW] Put keyboard port into non-translated mode |
744 | i8042.dumbkbd [HW] Pretend that controller can only read data from | 798 | i8042.dumbkbd [HW] Pretend that controller can only read data from |
@@ -785,7 +839,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
785 | See Documentation/ide/ide.txt. | 839 | See Documentation/ide/ide.txt. |
786 | 840 | ||
787 | idle= [X86] | 841 | idle= [X86] |
788 | Format: idle=poll or idle=mwait | 842 | Format: idle=poll or idle=mwait, idle=halt, idle=nomwait |
789 | Poll forces a polling idle loop that can slightly improves the performance | 843 | Poll forces a polling idle loop that can slightly improves the performance |
790 | of waking up a idle CPU, but will use a lot of power and make the system | 844 | of waking up a idle CPU, but will use a lot of power and make the system |
791 | run hot. Not recommended. | 845 | run hot. Not recommended. |
@@ -793,6 +847,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
793 | to not use it because it doesn't save as much power as a normal idle | 847 | to not use it because it doesn't save as much power as a normal idle |
794 | loop use the MONITOR/MWAIT idle loop anyways. Performance should be the same | 848 | loop use the MONITOR/MWAIT idle loop anyways. Performance should be the same |
795 | as idle=poll. | 849 | as idle=poll. |
850 | idle=halt. Halt is forced to be used for CPU idle. | ||
851 | In such case C2/C3 won't be used again. | ||
852 | idle=nomwait. Disable mwait for CPU C-states | ||
796 | 853 | ||
797 | ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem | 854 | ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem |
798 | Claim all unknown PCI IDE storage controllers. | 855 | Claim all unknown PCI IDE storage controllers. |
@@ -1166,7 +1223,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1166 | or | 1223 | or |
1167 | memmap=0x10000$0x18690000 | 1224 | memmap=0x10000$0x18690000 |
1168 | 1225 | ||
1169 | memtest= [KNL,X86_64] Enable memtest | 1226 | memtest= [KNL,X86] Enable memtest |
1170 | Format: <integer> | 1227 | Format: <integer> |
1171 | range: 0,4 : pattern number | 1228 | range: 0,4 : pattern number |
1172 | default : 0 <disable> | 1229 | default : 0 <disable> |
@@ -1185,6 +1242,14 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1185 | 1242 | ||
1186 | mga= [HW,DRM] | 1243 | mga= [HW,DRM] |
1187 | 1244 | ||
1245 | mminit_loglevel= | ||
1246 | [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this | ||
1247 | parameter allows control of the logging verbosity for | ||
1248 | the additional memory initialisation checks. A value | ||
1249 | of 0 disables mminit logging and a level of 4 will | ||
1250 | log everything. Information is printed at KERN_DEBUG | ||
1251 | so loglevel=8 may also need to be specified. | ||
1252 | |||
1188 | mousedev.tap_time= | 1253 | mousedev.tap_time= |
1189 | [MOUSE] Maximum time between finger touching and | 1254 | [MOUSE] Maximum time between finger touching and |
1190 | leaving touchpad surface for touch to be considered | 1255 | leaving touchpad surface for touch to be considered |
@@ -1208,6 +1273,11 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1208 | mtdparts= [MTD] | 1273 | mtdparts= [MTD] |
1209 | See drivers/mtd/cmdlinepart.c. | 1274 | See drivers/mtd/cmdlinepart.c. |
1210 | 1275 | ||
1276 | mtdset= [ARM] | ||
1277 | ARM/S3C2412 JIVE boot control | ||
1278 | |||
1279 | See arch/arm/mach-s3c2412/mach-jive.c | ||
1280 | |||
1211 | mtouchusb.raw_coordinates= | 1281 | mtouchusb.raw_coordinates= |
1212 | [HW] Make the MicroTouch USB driver use raw coordinates | 1282 | [HW] Make the MicroTouch USB driver use raw coordinates |
1213 | ('y', default) or cooked coordinates ('n') | 1283 | ('y', default) or cooked coordinates ('n') |
@@ -1234,6 +1304,13 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1234 | This usage is only documented in each driver source | 1304 | This usage is only documented in each driver source |
1235 | file if at all. | 1305 | file if at all. |
1236 | 1306 | ||
1307 | nf_conntrack.acct= | ||
1308 | [NETFILTER] Enable connection tracking flow accounting | ||
1309 | 0 to disable accounting | ||
1310 | 1 to enable accounting | ||
1311 | Default value depends on CONFIG_NF_CT_ACCT that is | ||
1312 | going to be removed in 2.6.29. | ||
1313 | |||
1237 | nfsaddrs= [NFS] | 1314 | nfsaddrs= [NFS] |
1238 | See Documentation/filesystems/nfsroot.txt. | 1315 | See Documentation/filesystems/nfsroot.txt. |
1239 | 1316 | ||
@@ -1496,6 +1573,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1496 | Use with caution as certain devices share | 1573 | Use with caution as certain devices share |
1497 | address decoders between ROMs and other | 1574 | address decoders between ROMs and other |
1498 | resources. | 1575 | resources. |
1576 | norom [X86-32,X86_64] Do not assign address space to | ||
1577 | expansion ROMs that do not already have | ||
1578 | BIOS assigned address ranges. | ||
1499 | irqmask=0xMMMM [X86-32] Set a bit mask of IRQs allowed to be | 1579 | irqmask=0xMMMM [X86-32] Set a bit mask of IRQs allowed to be |
1500 | assigned automatically to PCI devices. You can | 1580 | assigned automatically to PCI devices. You can |
1501 | make the kernel exclude IRQs of your ISA cards | 1581 | make the kernel exclude IRQs of your ISA cards |
@@ -1571,6 +1651,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1571 | Format: { parport<nr> | timid | 0 } | 1651 | Format: { parport<nr> | timid | 0 } |
1572 | See also Documentation/parport.txt. | 1652 | See also Documentation/parport.txt. |
1573 | 1653 | ||
1654 | pmtmr= [X86] Manual setup of pmtmr I/O Port. | ||
1655 | Override pmtimer IOPort with a hex value. | ||
1656 | e.g. pmtmr=0x508 | ||
1657 | |||
1574 | pnpacpi= [ACPI] | 1658 | pnpacpi= [ACPI] |
1575 | { off } | 1659 | { off } |
1576 | 1660 | ||
@@ -1975,6 +2059,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1975 | 2059 | ||
1976 | snd-ymfpci= [HW,ALSA] | 2060 | snd-ymfpci= [HW,ALSA] |
1977 | 2061 | ||
2062 | softlockup_panic= | ||
2063 | [KNL] Should the soft-lockup detector generate panics. | ||
2064 | |||
1978 | sonypi.*= [HW] Sony Programmable I/O Control Device driver | 2065 | sonypi.*= [HW] Sony Programmable I/O Control Device driver |
1979 | See Documentation/sonypi.txt | 2066 | See Documentation/sonypi.txt |
1980 | 2067 | ||
@@ -2039,6 +2126,12 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2039 | 2126 | ||
2040 | tdfx= [HW,DRM] | 2127 | tdfx= [HW,DRM] |
2041 | 2128 | ||
2129 | test_suspend= [SUSPEND] | ||
2130 | Specify "mem" (for Suspend-to-RAM) or "standby" (for | ||
2131 | standby suspend) as the system sleep state to briefly | ||
2132 | enter during system startup. The system is woken from | ||
2133 | this state using a wakeup-capable RTC alarm. | ||
2134 | |||
2042 | thash_entries= [KNL,NET] | 2135 | thash_entries= [KNL,NET] |
2043 | Set number of hash buckets for TCP connection | 2136 | Set number of hash buckets for TCP connection |
2044 | 2137 | ||
@@ -2066,13 +2159,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2066 | <deci-seconds>: poll all this frequency | 2159 | <deci-seconds>: poll all this frequency |
2067 | 0: no polling (default) | 2160 | 0: no polling (default) |
2068 | 2161 | ||
2069 | tipar.timeout= [HW,PPT] | ||
2070 | Set communications timeout in tenths of a second | ||
2071 | (default 15). | ||
2072 | |||
2073 | tipar.delay= [HW,PPT] | ||
2074 | Set inter-bit delay in microseconds (default 10). | ||
2075 | |||
2076 | tmscsim= [HW,SCSI] | 2162 | tmscsim= [HW,SCSI] |
2077 | See comment before function dc390_setup() in | 2163 | See comment before function dc390_setup() in |
2078 | drivers/scsi/tmscsim.c. | 2164 | drivers/scsi/tmscsim.c. |
@@ -2106,6 +2192,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2106 | Note that genuine overcurrent events won't be | 2192 | Note that genuine overcurrent events won't be |
2107 | reported either. | 2193 | reported either. |
2108 | 2194 | ||
2195 | unknown_nmi_panic | ||
2196 | [X86-32,X86-64] | ||
2197 | Set unknown_nmi_panic=1 early on boot. | ||
2198 | |||
2109 | usbcore.autosuspend= | 2199 | usbcore.autosuspend= |
2110 | [USB] The autosuspend time delay (in seconds) used | 2200 | [USB] The autosuspend time delay (in seconds) used |
2111 | for newly-detected USB devices (default 2). This | 2201 | for newly-detected USB devices (default 2). This |
@@ -2116,6 +2206,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2116 | usbhid.mousepoll= | 2206 | usbhid.mousepoll= |
2117 | [USBHID] The interval which mice are to be polled at. | 2207 | [USBHID] The interval which mice are to be polled at. |
2118 | 2208 | ||
2209 | add_efi_memmap [EFI; x86-32,X86-64] Include EFI memory map in | ||
2210 | kernel's map of available physical RAM. | ||
2211 | |||
2119 | vdso= [X86-32,SH,x86-64] | 2212 | vdso= [X86-32,SH,x86-64] |
2120 | vdso=2: enable compat VDSO (default with COMPAT_VDSO) | 2213 | vdso=2: enable compat VDSO (default with COMPAT_VDSO) |
2121 | vdso=1: enable VDSO (default) | 2214 | vdso=1: enable VDSO (default) |
diff --git a/Documentation/keys.txt b/Documentation/keys.txt index d5c7a57d1700..b56aacc1fff8 100644 --- a/Documentation/keys.txt +++ b/Documentation/keys.txt | |||
@@ -864,7 +864,7 @@ payload contents" for more information. | |||
864 | request_key_with_auxdata() respectively. | 864 | request_key_with_auxdata() respectively. |
865 | 865 | ||
866 | These two functions return with the key potentially still under | 866 | These two functions return with the key potentially still under |
867 | construction. To wait for contruction completion, the following should be | 867 | construction. To wait for construction completion, the following should be |
868 | called: | 868 | called: |
869 | 869 | ||
870 | int wait_for_key_construction(struct key *key, bool intr); | 870 | int wait_for_key_construction(struct key *key, bool intr); |
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 6877e7187113..a79633d702bf 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt | |||
@@ -172,6 +172,7 @@ architectures: | |||
172 | - ia64 (Does not support probes on instruction slot1.) | 172 | - ia64 (Does not support probes on instruction slot1.) |
173 | - sparc64 (Return probes not yet implemented.) | 173 | - sparc64 (Return probes not yet implemented.) |
174 | - arm | 174 | - arm |
175 | - ppc | ||
175 | 176 | ||
176 | 3. Configuring Kprobes | 177 | 3. Configuring Kprobes |
177 | 178 | ||
diff --git a/Documentation/laptops/acer-wmi.txt b/Documentation/laptops/acer-wmi.txt index 79b7dbd22141..69b5dd4e5a59 100644 --- a/Documentation/laptops/acer-wmi.txt +++ b/Documentation/laptops/acer-wmi.txt | |||
@@ -174,8 +174,6 @@ The LED is exposed through the LED subsystem, and can be found in: | |||
174 | The mail LED is autodetected, so if you don't have one, the LED device won't | 174 | The mail LED is autodetected, so if you don't have one, the LED device won't |
175 | be registered. | 175 | be registered. |
176 | 176 | ||
177 | If you have a mail LED that is not green, please report this to me. | ||
178 | |||
179 | Backlight | 177 | Backlight |
180 | ********* | 178 | ********* |
181 | 179 | ||
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 64b3f146e4b0..02dc748b76c4 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt | |||
@@ -1,7 +1,7 @@ | |||
1 | ThinkPad ACPI Extras Driver | 1 | ThinkPad ACPI Extras Driver |
2 | 2 | ||
3 | Version 0.20 | 3 | Version 0.21 |
4 | April 09th, 2008 | 4 | May 29th, 2008 |
5 | 5 | ||
6 | Borislav Deianov <borislav@users.sf.net> | 6 | Borislav Deianov <borislav@users.sf.net> |
7 | Henrique de Moraes Holschuh <hmh@hmh.eng.br> | 7 | Henrique de Moraes Holschuh <hmh@hmh.eng.br> |
@@ -621,7 +621,8 @@ Bluetooth | |||
621 | --------- | 621 | --------- |
622 | 622 | ||
623 | procfs: /proc/acpi/ibm/bluetooth | 623 | procfs: /proc/acpi/ibm/bluetooth |
624 | sysfs device attribute: bluetooth_enable | 624 | sysfs device attribute: bluetooth_enable (deprecated) |
625 | sysfs rfkill class: switch "tpacpi_bluetooth_sw" | ||
625 | 626 | ||
626 | This feature shows the presence and current state of a ThinkPad | 627 | This feature shows the presence and current state of a ThinkPad |
627 | Bluetooth device in the internal ThinkPad CDC slot. | 628 | Bluetooth device in the internal ThinkPad CDC slot. |
@@ -643,8 +644,12 @@ Sysfs notes: | |||
643 | 0: disables Bluetooth / Bluetooth is disabled | 644 | 0: disables Bluetooth / Bluetooth is disabled |
644 | 1: enables Bluetooth / Bluetooth is enabled. | 645 | 1: enables Bluetooth / Bluetooth is enabled. |
645 | 646 | ||
646 | Note: this interface will be probably be superseded by the | 647 | Note: this interface has been superseded by the generic rfkill |
647 | generic rfkill class, so it is NOT to be considered stable yet. | 648 | class. It has been deprecated, and it will be removed in year |
649 | 2010. | ||
650 | |||
651 | rfkill controller switch "tpacpi_bluetooth_sw": refer to | ||
652 | Documentation/rfkill.txt for details. | ||
648 | 653 | ||
649 | Video output control -- /proc/acpi/ibm/video | 654 | Video output control -- /proc/acpi/ibm/video |
650 | -------------------------------------------- | 655 | -------------------------------------------- |
@@ -1374,7 +1379,8 @@ EXPERIMENTAL: WAN | |||
1374 | ----------------- | 1379 | ----------------- |
1375 | 1380 | ||
1376 | procfs: /proc/acpi/ibm/wan | 1381 | procfs: /proc/acpi/ibm/wan |
1377 | sysfs device attribute: wwan_enable | 1382 | sysfs device attribute: wwan_enable (deprecated) |
1383 | sysfs rfkill class: switch "tpacpi_wwan_sw" | ||
1378 | 1384 | ||
1379 | This feature is marked EXPERIMENTAL because the implementation | 1385 | This feature is marked EXPERIMENTAL because the implementation |
1380 | directly accesses hardware registers and may not work as expected. USE | 1386 | directly accesses hardware registers and may not work as expected. USE |
@@ -1404,8 +1410,12 @@ Sysfs notes: | |||
1404 | 0: disables WWAN card / WWAN card is disabled | 1410 | 0: disables WWAN card / WWAN card is disabled |
1405 | 1: enables WWAN card / WWAN card is enabled. | 1411 | 1: enables WWAN card / WWAN card is enabled. |
1406 | 1412 | ||
1407 | Note: this interface will be probably be superseded by the | 1413 | Note: this interface has been superseded by the generic rfkill |
1408 | generic rfkill class, so it is NOT to be considered stable yet. | 1414 | class. It has been deprecated, and it will be removed in year |
1415 | 2010. | ||
1416 | |||
1417 | rfkill controller switch "tpacpi_wwan_sw": refer to | ||
1418 | Documentation/rfkill.txt for details. | ||
1409 | 1419 | ||
1410 | Multiple Commands, Module Parameters | 1420 | Multiple Commands, Module Parameters |
1411 | ------------------------------------ | 1421 | ------------------------------------ |
diff --git a/Documentation/leds-class.txt b/Documentation/leds-class.txt index 18860ad9935a..6399557cdab3 100644 --- a/Documentation/leds-class.txt +++ b/Documentation/leds-class.txt | |||
@@ -59,7 +59,7 @@ Hardware accelerated blink of LEDs | |||
59 | 59 | ||
60 | Some LEDs can be programmed to blink without any CPU interaction. To | 60 | Some LEDs can be programmed to blink without any CPU interaction. To |
61 | support this feature, a LED driver can optionally implement the | 61 | support this feature, a LED driver can optionally implement the |
62 | blink_set() function (see <linux/leds.h>). If implemeted, triggers can | 62 | blink_set() function (see <linux/leds.h>). If implemented, triggers can |
63 | attempt to use it before falling back to software timers. The blink_set() | 63 | attempt to use it before falling back to software timers. The blink_set() |
64 | function should return 0 if the blink setting is supported, or -EINVAL | 64 | function should return 0 if the blink setting is supported, or -EINVAL |
65 | otherwise, which means that LED blinking will be handled by software. | 65 | otherwise, which means that LED blinking will be handled by software. |
diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c index 82fafe0429fe..b88b0ea54e90 100644 --- a/Documentation/lguest/lguest.c +++ b/Documentation/lguest/lguest.c | |||
@@ -36,11 +36,13 @@ | |||
36 | #include <sched.h> | 36 | #include <sched.h> |
37 | #include <limits.h> | 37 | #include <limits.h> |
38 | #include <stddef.h> | 38 | #include <stddef.h> |
39 | #include <signal.h> | ||
39 | #include "linux/lguest_launcher.h" | 40 | #include "linux/lguest_launcher.h" |
40 | #include "linux/virtio_config.h" | 41 | #include "linux/virtio_config.h" |
41 | #include "linux/virtio_net.h" | 42 | #include "linux/virtio_net.h" |
42 | #include "linux/virtio_blk.h" | 43 | #include "linux/virtio_blk.h" |
43 | #include "linux/virtio_console.h" | 44 | #include "linux/virtio_console.h" |
45 | #include "linux/virtio_rng.h" | ||
44 | #include "linux/virtio_ring.h" | 46 | #include "linux/virtio_ring.h" |
45 | #include "asm-x86/bootparam.h" | 47 | #include "asm-x86/bootparam.h" |
46 | /*L:110 We can ignore the 39 include files we need for this program, but I do | 48 | /*L:110 We can ignore the 39 include files we need for this program, but I do |
@@ -64,8 +66,8 @@ typedef uint8_t u8; | |||
64 | #endif | 66 | #endif |
65 | /* We can have up to 256 pages for devices. */ | 67 | /* We can have up to 256 pages for devices. */ |
66 | #define DEVICE_PAGES 256 | 68 | #define DEVICE_PAGES 256 |
67 | /* This will occupy 2 pages: it must be a power of 2. */ | 69 | /* This will occupy 3 pages: it must be a power of 2. */ |
68 | #define VIRTQUEUE_NUM 128 | 70 | #define VIRTQUEUE_NUM 256 |
69 | 71 | ||
70 | /*L:120 verbose is both a global flag and a macro. The C preprocessor allows | 72 | /*L:120 verbose is both a global flag and a macro. The C preprocessor allows |
71 | * this, and although I wouldn't recommend it, it works quite nicely here. */ | 73 | * this, and although I wouldn't recommend it, it works quite nicely here. */ |
@@ -74,12 +76,19 @@ static bool verbose; | |||
74 | do { if (verbose) printf(args); } while(0) | 76 | do { if (verbose) printf(args); } while(0) |
75 | /*:*/ | 77 | /*:*/ |
76 | 78 | ||
77 | /* The pipe to send commands to the waker process */ | 79 | /* File descriptors for the Waker. */ |
78 | static int waker_fd; | 80 | struct { |
81 | int pipe[2]; | ||
82 | int lguest_fd; | ||
83 | } waker_fds; | ||
84 | |||
79 | /* The pointer to the start of guest memory. */ | 85 | /* The pointer to the start of guest memory. */ |
80 | static void *guest_base; | 86 | static void *guest_base; |
81 | /* The maximum guest physical address allowed, and maximum possible. */ | 87 | /* The maximum guest physical address allowed, and maximum possible. */ |
82 | static unsigned long guest_limit, guest_max; | 88 | static unsigned long guest_limit, guest_max; |
89 | /* The pipe for signal hander to write to. */ | ||
90 | static int timeoutpipe[2]; | ||
91 | static unsigned int timeout_usec = 500; | ||
83 | 92 | ||
84 | /* a per-cpu variable indicating whose vcpu is currently running */ | 93 | /* a per-cpu variable indicating whose vcpu is currently running */ |
85 | static unsigned int __thread cpu_id; | 94 | static unsigned int __thread cpu_id; |
@@ -155,11 +164,14 @@ struct virtqueue | |||
155 | /* Last available index we saw. */ | 164 | /* Last available index we saw. */ |
156 | u16 last_avail_idx; | 165 | u16 last_avail_idx; |
157 | 166 | ||
158 | /* The routine to call when the Guest pings us. */ | 167 | /* The routine to call when the Guest pings us, or timeout. */ |
159 | void (*handle_output)(int fd, struct virtqueue *me); | 168 | void (*handle_output)(int fd, struct virtqueue *me, bool timeout); |
160 | 169 | ||
161 | /* Outstanding buffers */ | 170 | /* Outstanding buffers */ |
162 | unsigned int inflight; | 171 | unsigned int inflight; |
172 | |||
173 | /* Is this blocked awaiting a timer? */ | ||
174 | bool blocked; | ||
163 | }; | 175 | }; |
164 | 176 | ||
165 | /* Remember the arguments to the program so we can "reboot" */ | 177 | /* Remember the arguments to the program so we can "reboot" */ |
@@ -190,6 +202,9 @@ static void *_convert(struct iovec *iov, size_t size, size_t align, | |||
190 | return iov->iov_base; | 202 | return iov->iov_base; |
191 | } | 203 | } |
192 | 204 | ||
205 | /* Wrapper for the last available index. Makes it easier to change. */ | ||
206 | #define lg_last_avail(vq) ((vq)->last_avail_idx) | ||
207 | |||
193 | /* The virtio configuration space is defined to be little-endian. x86 is | 208 | /* The virtio configuration space is defined to be little-endian. x86 is |
194 | * little-endian too, but it's nice to be explicit so we have these helpers. */ | 209 | * little-endian too, but it's nice to be explicit so we have these helpers. */ |
195 | #define cpu_to_le16(v16) (v16) | 210 | #define cpu_to_le16(v16) (v16) |
@@ -199,6 +214,33 @@ static void *_convert(struct iovec *iov, size_t size, size_t align, | |||
199 | #define le32_to_cpu(v32) (v32) | 214 | #define le32_to_cpu(v32) (v32) |
200 | #define le64_to_cpu(v64) (v64) | 215 | #define le64_to_cpu(v64) (v64) |
201 | 216 | ||
217 | /* Is this iovec empty? */ | ||
218 | static bool iov_empty(const struct iovec iov[], unsigned int num_iov) | ||
219 | { | ||
220 | unsigned int i; | ||
221 | |||
222 | for (i = 0; i < num_iov; i++) | ||
223 | if (iov[i].iov_len) | ||
224 | return false; | ||
225 | return true; | ||
226 | } | ||
227 | |||
228 | /* Take len bytes from the front of this iovec. */ | ||
229 | static void iov_consume(struct iovec iov[], unsigned num_iov, unsigned len) | ||
230 | { | ||
231 | unsigned int i; | ||
232 | |||
233 | for (i = 0; i < num_iov; i++) { | ||
234 | unsigned int used; | ||
235 | |||
236 | used = iov[i].iov_len < len ? iov[i].iov_len : len; | ||
237 | iov[i].iov_base += used; | ||
238 | iov[i].iov_len -= used; | ||
239 | len -= used; | ||
240 | } | ||
241 | assert(len == 0); | ||
242 | } | ||
243 | |||
202 | /* The device virtqueue descriptors are followed by feature bitmasks. */ | 244 | /* The device virtqueue descriptors are followed by feature bitmasks. */ |
203 | static u8 *get_feature_bits(struct device *dev) | 245 | static u8 *get_feature_bits(struct device *dev) |
204 | { | 246 | { |
@@ -254,6 +296,7 @@ static void *map_zeroed_pages(unsigned int num) | |||
254 | PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0); | 296 | PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0); |
255 | if (addr == MAP_FAILED) | 297 | if (addr == MAP_FAILED) |
256 | err(1, "Mmaping %u pages of /dev/zero", num); | 298 | err(1, "Mmaping %u pages of /dev/zero", num); |
299 | close(fd); | ||
257 | 300 | ||
258 | return addr; | 301 | return addr; |
259 | } | 302 | } |
@@ -540,69 +583,64 @@ static void add_device_fd(int fd) | |||
540 | * watch, but handing a file descriptor mask through to the kernel is fairly | 583 | * watch, but handing a file descriptor mask through to the kernel is fairly |
541 | * icky. | 584 | * icky. |
542 | * | 585 | * |
543 | * Instead, we fork off a process which watches the file descriptors and writes | 586 | * Instead, we clone off a thread which watches the file descriptors and writes |
544 | * the LHREQ_BREAK command to the /dev/lguest file descriptor to tell the Host | 587 | * the LHREQ_BREAK command to the /dev/lguest file descriptor to tell the Host |
545 | * stop running the Guest. This causes the Launcher to return from the | 588 | * stop running the Guest. This causes the Launcher to return from the |
546 | * /dev/lguest read with -EAGAIN, where it will write to /dev/lguest to reset | 589 | * /dev/lguest read with -EAGAIN, where it will write to /dev/lguest to reset |
547 | * the LHREQ_BREAK and wake us up again. | 590 | * the LHREQ_BREAK and wake us up again. |
548 | * | 591 | * |
549 | * This, of course, is merely a different *kind* of icky. | 592 | * This, of course, is merely a different *kind* of icky. |
593 | * | ||
594 | * Given my well-known antipathy to threads, I'd prefer to use processes. But | ||
595 | * it's easier to share Guest memory with threads, and trivial to share the | ||
596 | * devices.infds as the Launcher changes it. | ||
550 | */ | 597 | */ |
551 | static void wake_parent(int pipefd, int lguest_fd) | 598 | static int waker(void *unused) |
552 | { | 599 | { |
553 | /* Add the pipe from the Launcher to the fdset in the device_list, so | 600 | /* Close the write end of the pipe: only the Launcher has it open. */ |
554 | * we watch it, too. */ | 601 | close(waker_fds.pipe[1]); |
555 | add_device_fd(pipefd); | ||
556 | 602 | ||
557 | for (;;) { | 603 | for (;;) { |
558 | fd_set rfds = devices.infds; | 604 | fd_set rfds = devices.infds; |
559 | unsigned long args[] = { LHREQ_BREAK, 1 }; | 605 | unsigned long args[] = { LHREQ_BREAK, 1 }; |
606 | unsigned int maxfd = devices.max_infd; | ||
607 | |||
608 | /* We also listen to the pipe from the Launcher. */ | ||
609 | FD_SET(waker_fds.pipe[0], &rfds); | ||
610 | if (waker_fds.pipe[0] > maxfd) | ||
611 | maxfd = waker_fds.pipe[0]; | ||
560 | 612 | ||
561 | /* Wait until input is ready from one of the devices. */ | 613 | /* Wait until input is ready from one of the devices. */ |
562 | select(devices.max_infd+1, &rfds, NULL, NULL, NULL); | 614 | select(maxfd+1, &rfds, NULL, NULL, NULL); |
563 | /* Is it a message from the Launcher? */ | 615 | |
564 | if (FD_ISSET(pipefd, &rfds)) { | 616 | /* Message from Launcher? */ |
565 | int fd; | 617 | if (FD_ISSET(waker_fds.pipe[0], &rfds)) { |
566 | /* If read() returns 0, it means the Launcher has | 618 | char c; |
567 | * exited. We silently follow. */ | 619 | /* If this fails, then assume Launcher has exited. |
568 | if (read(pipefd, &fd, sizeof(fd)) == 0) | 620 | * Don't do anything on exit: we're just a thread! */ |
569 | exit(0); | 621 | if (read(waker_fds.pipe[0], &c, 1) != 1) |
570 | /* Otherwise it's telling us to change what file | 622 | _exit(0); |
571 | * descriptors we're to listen to. Positive means | 623 | continue; |
572 | * listen to a new one, negative means stop | 624 | } |
573 | * listening. */ | 625 | |
574 | if (fd >= 0) | 626 | /* Send LHREQ_BREAK command to snap the Launcher out of it. */ |
575 | FD_SET(fd, &devices.infds); | 627 | pwrite(waker_fds.lguest_fd, args, sizeof(args), cpu_id); |
576 | else | ||
577 | FD_CLR(-fd - 1, &devices.infds); | ||
578 | } else /* Send LHREQ_BREAK command. */ | ||
579 | pwrite(lguest_fd, args, sizeof(args), cpu_id); | ||
580 | } | 628 | } |
629 | return 0; | ||
581 | } | 630 | } |
582 | 631 | ||
583 | /* This routine just sets up a pipe to the Waker process. */ | 632 | /* This routine just sets up a pipe to the Waker process. */ |
584 | static int setup_waker(int lguest_fd) | 633 | static void setup_waker(int lguest_fd) |
585 | { | 634 | { |
586 | int pipefd[2], child; | 635 | /* This pipe is closed when Launcher dies, telling Waker. */ |
587 | 636 | if (pipe(waker_fds.pipe) != 0) | |
588 | /* We create a pipe to talk to the Waker, and also so it knows when the | 637 | err(1, "Creating pipe for Waker"); |
589 | * Launcher dies (and closes pipe). */ | ||
590 | pipe(pipefd); | ||
591 | child = fork(); | ||
592 | if (child == -1) | ||
593 | err(1, "forking"); | ||
594 | |||
595 | if (child == 0) { | ||
596 | /* We are the Waker: close the "writing" end of our copy of the | ||
597 | * pipe and start waiting for input. */ | ||
598 | close(pipefd[1]); | ||
599 | wake_parent(pipefd[0], lguest_fd); | ||
600 | } | ||
601 | /* Close the reading end of our copy of the pipe. */ | ||
602 | close(pipefd[0]); | ||
603 | 638 | ||
604 | /* Here is the fd used to talk to the waker. */ | 639 | /* Waker also needs to know the lguest fd */ |
605 | return pipefd[1]; | 640 | waker_fds.lguest_fd = lguest_fd; |
641 | |||
642 | if (clone(waker, malloc(4096) + 4096, CLONE_VM | SIGCHLD, NULL) == -1) | ||
643 | err(1, "Creating Waker"); | ||
606 | } | 644 | } |
607 | 645 | ||
608 | /* | 646 | /* |
@@ -661,19 +699,22 @@ static unsigned get_vq_desc(struct virtqueue *vq, | |||
661 | unsigned int *out_num, unsigned int *in_num) | 699 | unsigned int *out_num, unsigned int *in_num) |
662 | { | 700 | { |
663 | unsigned int i, head; | 701 | unsigned int i, head; |
702 | u16 last_avail; | ||
664 | 703 | ||
665 | /* Check it isn't doing very strange things with descriptor numbers. */ | 704 | /* Check it isn't doing very strange things with descriptor numbers. */ |
666 | if ((u16)(vq->vring.avail->idx - vq->last_avail_idx) > vq->vring.num) | 705 | last_avail = lg_last_avail(vq); |
706 | if ((u16)(vq->vring.avail->idx - last_avail) > vq->vring.num) | ||
667 | errx(1, "Guest moved used index from %u to %u", | 707 | errx(1, "Guest moved used index from %u to %u", |
668 | vq->last_avail_idx, vq->vring.avail->idx); | 708 | last_avail, vq->vring.avail->idx); |
669 | 709 | ||
670 | /* If there's nothing new since last we looked, return invalid. */ | 710 | /* If there's nothing new since last we looked, return invalid. */ |
671 | if (vq->vring.avail->idx == vq->last_avail_idx) | 711 | if (vq->vring.avail->idx == last_avail) |
672 | return vq->vring.num; | 712 | return vq->vring.num; |
673 | 713 | ||
674 | /* Grab the next descriptor number they're advertising, and increment | 714 | /* Grab the next descriptor number they're advertising, and increment |
675 | * the index we've seen. */ | 715 | * the index we've seen. */ |
676 | head = vq->vring.avail->ring[vq->last_avail_idx++ % vq->vring.num]; | 716 | head = vq->vring.avail->ring[last_avail % vq->vring.num]; |
717 | lg_last_avail(vq)++; | ||
677 | 718 | ||
678 | /* If their number is silly, that's a fatal mistake. */ | 719 | /* If their number is silly, that's a fatal mistake. */ |
679 | if (head >= vq->vring.num) | 720 | if (head >= vq->vring.num) |
@@ -821,8 +862,8 @@ static bool handle_console_input(int fd, struct device *dev) | |||
821 | unsigned long args[] = { LHREQ_BREAK, 0 }; | 862 | unsigned long args[] = { LHREQ_BREAK, 0 }; |
822 | /* Close the fd so Waker will know it has to | 863 | /* Close the fd so Waker will know it has to |
823 | * exit. */ | 864 | * exit. */ |
824 | close(waker_fd); | 865 | close(waker_fds.pipe[1]); |
825 | /* Just in case waker is blocked in BREAK, send | 866 | /* Just in case Waker is blocked in BREAK, send |
826 | * unbreak now. */ | 867 | * unbreak now. */ |
827 | write(fd, args, sizeof(args)); | 868 | write(fd, args, sizeof(args)); |
828 | exit(2); | 869 | exit(2); |
@@ -839,7 +880,7 @@ static bool handle_console_input(int fd, struct device *dev) | |||
839 | 880 | ||
840 | /* Handling output for console is simple: we just get all the output buffers | 881 | /* Handling output for console is simple: we just get all the output buffers |
841 | * and write them to stdout. */ | 882 | * and write them to stdout. */ |
842 | static void handle_console_output(int fd, struct virtqueue *vq) | 883 | static void handle_console_output(int fd, struct virtqueue *vq, bool timeout) |
843 | { | 884 | { |
844 | unsigned int head, out, in; | 885 | unsigned int head, out, in; |
845 | int len; | 886 | int len; |
@@ -854,6 +895,21 @@ static void handle_console_output(int fd, struct virtqueue *vq) | |||
854 | } | 895 | } |
855 | } | 896 | } |
856 | 897 | ||
898 | static void block_vq(struct virtqueue *vq) | ||
899 | { | ||
900 | struct itimerval itm; | ||
901 | |||
902 | vq->vring.used->flags |= VRING_USED_F_NO_NOTIFY; | ||
903 | vq->blocked = true; | ||
904 | |||
905 | itm.it_interval.tv_sec = 0; | ||
906 | itm.it_interval.tv_usec = 0; | ||
907 | itm.it_value.tv_sec = 0; | ||
908 | itm.it_value.tv_usec = timeout_usec; | ||
909 | |||
910 | setitimer(ITIMER_REAL, &itm, NULL); | ||
911 | } | ||
912 | |||
857 | /* | 913 | /* |
858 | * The Network | 914 | * The Network |
859 | * | 915 | * |
@@ -861,22 +917,34 @@ static void handle_console_output(int fd, struct virtqueue *vq) | |||
861 | * and write them (ignoring the first element) to this device's file descriptor | 917 | * and write them (ignoring the first element) to this device's file descriptor |
862 | * (/dev/net/tun). | 918 | * (/dev/net/tun). |
863 | */ | 919 | */ |
864 | static void handle_net_output(int fd, struct virtqueue *vq) | 920 | static void handle_net_output(int fd, struct virtqueue *vq, bool timeout) |
865 | { | 921 | { |
866 | unsigned int head, out, in; | 922 | unsigned int head, out, in, num = 0; |
867 | int len; | 923 | int len; |
868 | struct iovec iov[vq->vring.num]; | 924 | struct iovec iov[vq->vring.num]; |
925 | static int last_timeout_num; | ||
869 | 926 | ||
870 | /* Keep getting output buffers from the Guest until we run out. */ | 927 | /* Keep getting output buffers from the Guest until we run out. */ |
871 | while ((head = get_vq_desc(vq, iov, &out, &in)) != vq->vring.num) { | 928 | while ((head = get_vq_desc(vq, iov, &out, &in)) != vq->vring.num) { |
872 | if (in) | 929 | if (in) |
873 | errx(1, "Input buffers in output queue?"); | 930 | errx(1, "Input buffers in output queue?"); |
874 | /* Check header, but otherwise ignore it (we told the Guest we | 931 | len = writev(vq->dev->fd, iov, out); |
875 | * supported no features, so it shouldn't have anything | 932 | if (len < 0) |
876 | * interesting). */ | 933 | err(1, "Writing network packet to tun"); |
877 | (void)convert(&iov[0], struct virtio_net_hdr); | ||
878 | len = writev(vq->dev->fd, iov+1, out-1); | ||
879 | add_used_and_trigger(fd, vq, head, len); | 934 | add_used_and_trigger(fd, vq, head, len); |
935 | num++; | ||
936 | } | ||
937 | |||
938 | /* Block further kicks and set up a timer if we saw anything. */ | ||
939 | if (!timeout && num) | ||
940 | block_vq(vq); | ||
941 | |||
942 | if (timeout) { | ||
943 | if (num < last_timeout_num) | ||
944 | timeout_usec += 10; | ||
945 | else if (timeout_usec > 1) | ||
946 | timeout_usec--; | ||
947 | last_timeout_num = num; | ||
880 | } | 948 | } |
881 | } | 949 | } |
882 | 950 | ||
@@ -887,7 +955,6 @@ static bool handle_tun_input(int fd, struct device *dev) | |||
887 | unsigned int head, in_num, out_num; | 955 | unsigned int head, in_num, out_num; |
888 | int len; | 956 | int len; |
889 | struct iovec iov[dev->vq->vring.num]; | 957 | struct iovec iov[dev->vq->vring.num]; |
890 | struct virtio_net_hdr *hdr; | ||
891 | 958 | ||
892 | /* First we need a network buffer from the Guests's recv virtqueue. */ | 959 | /* First we need a network buffer from the Guests's recv virtqueue. */ |
893 | head = get_vq_desc(dev->vq, iov, &out_num, &in_num); | 960 | head = get_vq_desc(dev->vq, iov, &out_num, &in_num); |
@@ -896,25 +963,23 @@ static bool handle_tun_input(int fd, struct device *dev) | |||
896 | * early, the Guest won't be ready yet. Wait until the device | 963 | * early, the Guest won't be ready yet. Wait until the device |
897 | * status says it's ready. */ | 964 | * status says it's ready. */ |
898 | /* FIXME: Actually want DRIVER_ACTIVE here. */ | 965 | /* FIXME: Actually want DRIVER_ACTIVE here. */ |
899 | if (dev->desc->status & VIRTIO_CONFIG_S_DRIVER_OK) | 966 | |
900 | warn("network: no dma buffer!"); | 967 | /* Now tell it we want to know if new things appear. */ |
968 | dev->vq->vring.used->flags &= ~VRING_USED_F_NO_NOTIFY; | ||
969 | wmb(); | ||
970 | |||
901 | /* We'll turn this back on if input buffers are registered. */ | 971 | /* We'll turn this back on if input buffers are registered. */ |
902 | return false; | 972 | return false; |
903 | } else if (out_num) | 973 | } else if (out_num) |
904 | errx(1, "Output buffers in network recv queue?"); | 974 | errx(1, "Output buffers in network recv queue?"); |
905 | 975 | ||
906 | /* First element is the header: we set it to 0 (no features). */ | ||
907 | hdr = convert(&iov[0], struct virtio_net_hdr); | ||
908 | hdr->flags = 0; | ||
909 | hdr->gso_type = VIRTIO_NET_HDR_GSO_NONE; | ||
910 | |||
911 | /* Read the packet from the device directly into the Guest's buffer. */ | 976 | /* Read the packet from the device directly into the Guest's buffer. */ |
912 | len = readv(dev->fd, iov+1, in_num-1); | 977 | len = readv(dev->fd, iov, in_num); |
913 | if (len <= 0) | 978 | if (len <= 0) |
914 | err(1, "reading network"); | 979 | err(1, "reading network"); |
915 | 980 | ||
916 | /* Tell the Guest about the new packet. */ | 981 | /* Tell the Guest about the new packet. */ |
917 | add_used_and_trigger(fd, dev->vq, head, sizeof(*hdr) + len); | 982 | add_used_and_trigger(fd, dev->vq, head, len); |
918 | 983 | ||
919 | verbose("tun input packet len %i [%02x %02x] (%s)\n", len, | 984 | verbose("tun input packet len %i [%02x %02x] (%s)\n", len, |
920 | ((u8 *)iov[1].iov_base)[0], ((u8 *)iov[1].iov_base)[1], | 985 | ((u8 *)iov[1].iov_base)[0], ((u8 *)iov[1].iov_base)[1], |
@@ -927,11 +992,18 @@ static bool handle_tun_input(int fd, struct device *dev) | |||
927 | /*L:215 This is the callback attached to the network and console input | 992 | /*L:215 This is the callback attached to the network and console input |
928 | * virtqueues: it ensures we try again, in case we stopped console or net | 993 | * virtqueues: it ensures we try again, in case we stopped console or net |
929 | * delivery because Guest didn't have any buffers. */ | 994 | * delivery because Guest didn't have any buffers. */ |
930 | static void enable_fd(int fd, struct virtqueue *vq) | 995 | static void enable_fd(int fd, struct virtqueue *vq, bool timeout) |
931 | { | 996 | { |
932 | add_device_fd(vq->dev->fd); | 997 | add_device_fd(vq->dev->fd); |
933 | /* Tell waker to listen to it again */ | 998 | /* Snap the Waker out of its select loop. */ |
934 | write(waker_fd, &vq->dev->fd, sizeof(vq->dev->fd)); | 999 | write(waker_fds.pipe[1], "", 1); |
1000 | } | ||
1001 | |||
1002 | static void net_enable_fd(int fd, struct virtqueue *vq, bool timeout) | ||
1003 | { | ||
1004 | /* We don't need to know again when Guest refills receive buffer. */ | ||
1005 | vq->vring.used->flags |= VRING_USED_F_NO_NOTIFY; | ||
1006 | enable_fd(fd, vq, timeout); | ||
935 | } | 1007 | } |
936 | 1008 | ||
937 | /* When the Guest tells us they updated the status field, we handle it. */ | 1009 | /* When the Guest tells us they updated the status field, we handle it. */ |
@@ -951,7 +1023,7 @@ static void update_device_status(struct device *dev) | |||
951 | for (vq = dev->vq; vq; vq = vq->next) { | 1023 | for (vq = dev->vq; vq; vq = vq->next) { |
952 | memset(vq->vring.desc, 0, | 1024 | memset(vq->vring.desc, 0, |
953 | vring_size(vq->config.num, getpagesize())); | 1025 | vring_size(vq->config.num, getpagesize())); |
954 | vq->last_avail_idx = 0; | 1026 | lg_last_avail(vq) = 0; |
955 | } | 1027 | } |
956 | } else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) { | 1028 | } else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) { |
957 | warnx("Device %s configuration FAILED", dev->name); | 1029 | warnx("Device %s configuration FAILED", dev->name); |
@@ -960,10 +1032,10 @@ static void update_device_status(struct device *dev) | |||
960 | 1032 | ||
961 | verbose("Device %s OK: offered", dev->name); | 1033 | verbose("Device %s OK: offered", dev->name); |
962 | for (i = 0; i < dev->desc->feature_len; i++) | 1034 | for (i = 0; i < dev->desc->feature_len; i++) |
963 | verbose(" %08x", get_feature_bits(dev)[i]); | 1035 | verbose(" %02x", get_feature_bits(dev)[i]); |
964 | verbose(", accepted"); | 1036 | verbose(", accepted"); |
965 | for (i = 0; i < dev->desc->feature_len; i++) | 1037 | for (i = 0; i < dev->desc->feature_len; i++) |
966 | verbose(" %08x", get_feature_bits(dev) | 1038 | verbose(" %02x", get_feature_bits(dev) |
967 | [dev->desc->feature_len+i]); | 1039 | [dev->desc->feature_len+i]); |
968 | 1040 | ||
969 | if (dev->ready) | 1041 | if (dev->ready) |
@@ -1000,7 +1072,7 @@ static void handle_output(int fd, unsigned long addr) | |||
1000 | if (strcmp(vq->dev->name, "console") != 0) | 1072 | if (strcmp(vq->dev->name, "console") != 0) |
1001 | verbose("Output to %s\n", vq->dev->name); | 1073 | verbose("Output to %s\n", vq->dev->name); |
1002 | if (vq->handle_output) | 1074 | if (vq->handle_output) |
1003 | vq->handle_output(fd, vq); | 1075 | vq->handle_output(fd, vq, false); |
1004 | return; | 1076 | return; |
1005 | } | 1077 | } |
1006 | } | 1078 | } |
@@ -1014,6 +1086,29 @@ static void handle_output(int fd, unsigned long addr) | |||
1014 | strnlen(from_guest_phys(addr), guest_limit - addr)); | 1086 | strnlen(from_guest_phys(addr), guest_limit - addr)); |
1015 | } | 1087 | } |
1016 | 1088 | ||
1089 | static void handle_timeout(int fd) | ||
1090 | { | ||
1091 | char buf[32]; | ||
1092 | struct device *i; | ||
1093 | struct virtqueue *vq; | ||
1094 | |||
1095 | /* Clear the pipe */ | ||
1096 | read(timeoutpipe[0], buf, sizeof(buf)); | ||
1097 | |||
1098 | /* Check each device and virtqueue: flush blocked ones. */ | ||
1099 | for (i = devices.dev; i; i = i->next) { | ||
1100 | for (vq = i->vq; vq; vq = vq->next) { | ||
1101 | if (!vq->blocked) | ||
1102 | continue; | ||
1103 | |||
1104 | vq->vring.used->flags &= ~VRING_USED_F_NO_NOTIFY; | ||
1105 | vq->blocked = false; | ||
1106 | if (vq->handle_output) | ||
1107 | vq->handle_output(fd, vq, true); | ||
1108 | } | ||
1109 | } | ||
1110 | } | ||
1111 | |||
1017 | /* This is called when the Waker wakes us up: check for incoming file | 1112 | /* This is called when the Waker wakes us up: check for incoming file |
1018 | * descriptors. */ | 1113 | * descriptors. */ |
1019 | static void handle_input(int fd) | 1114 | static void handle_input(int fd) |
@@ -1024,16 +1119,20 @@ static void handle_input(int fd) | |||
1024 | for (;;) { | 1119 | for (;;) { |
1025 | struct device *i; | 1120 | struct device *i; |
1026 | fd_set fds = devices.infds; | 1121 | fd_set fds = devices.infds; |
1122 | int num; | ||
1027 | 1123 | ||
1124 | num = select(devices.max_infd+1, &fds, NULL, NULL, &poll); | ||
1125 | /* Could get interrupted */ | ||
1126 | if (num < 0) | ||
1127 | continue; | ||
1028 | /* If nothing is ready, we're done. */ | 1128 | /* If nothing is ready, we're done. */ |
1029 | if (select(devices.max_infd+1, &fds, NULL, NULL, &poll) == 0) | 1129 | if (num == 0) |
1030 | break; | 1130 | break; |
1031 | 1131 | ||
1032 | /* Otherwise, call the device(s) which have readable file | 1132 | /* Otherwise, call the device(s) which have readable file |
1033 | * descriptors and a method of handling them. */ | 1133 | * descriptors and a method of handling them. */ |
1034 | for (i = devices.dev; i; i = i->next) { | 1134 | for (i = devices.dev; i; i = i->next) { |
1035 | if (i->handle_input && FD_ISSET(i->fd, &fds)) { | 1135 | if (i->handle_input && FD_ISSET(i->fd, &fds)) { |
1036 | int dev_fd; | ||
1037 | if (i->handle_input(fd, i)) | 1136 | if (i->handle_input(fd, i)) |
1038 | continue; | 1137 | continue; |
1039 | 1138 | ||
@@ -1043,13 +1142,12 @@ static void handle_input(int fd) | |||
1043 | * buffers to deliver into. Console also uses | 1142 | * buffers to deliver into. Console also uses |
1044 | * it when it discovers that stdin is closed. */ | 1143 | * it when it discovers that stdin is closed. */ |
1045 | FD_CLR(i->fd, &devices.infds); | 1144 | FD_CLR(i->fd, &devices.infds); |
1046 | /* Tell waker to ignore it too, by sending a | ||
1047 | * negative fd number (-1, since 0 is a valid | ||
1048 | * FD number). */ | ||
1049 | dev_fd = -i->fd - 1; | ||
1050 | write(waker_fd, &dev_fd, sizeof(dev_fd)); | ||
1051 | } | 1145 | } |
1052 | } | 1146 | } |
1147 | |||
1148 | /* Is this the timeout fd? */ | ||
1149 | if (FD_ISSET(timeoutpipe[0], &fds)) | ||
1150 | handle_timeout(fd); | ||
1053 | } | 1151 | } |
1054 | } | 1152 | } |
1055 | 1153 | ||
@@ -1098,7 +1196,7 @@ static struct lguest_device_desc *new_dev_desc(u16 type) | |||
1098 | /* Each device descriptor is followed by the description of its virtqueues. We | 1196 | /* Each device descriptor is followed by the description of its virtqueues. We |
1099 | * specify how many descriptors the virtqueue is to have. */ | 1197 | * specify how many descriptors the virtqueue is to have. */ |
1100 | static void add_virtqueue(struct device *dev, unsigned int num_descs, | 1198 | static void add_virtqueue(struct device *dev, unsigned int num_descs, |
1101 | void (*handle_output)(int fd, struct virtqueue *me)) | 1199 | void (*handle_output)(int, struct virtqueue *, bool)) |
1102 | { | 1200 | { |
1103 | unsigned int pages; | 1201 | unsigned int pages; |
1104 | struct virtqueue **i, *vq = malloc(sizeof(*vq)); | 1202 | struct virtqueue **i, *vq = malloc(sizeof(*vq)); |
@@ -1114,6 +1212,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs, | |||
1114 | vq->last_avail_idx = 0; | 1212 | vq->last_avail_idx = 0; |
1115 | vq->dev = dev; | 1213 | vq->dev = dev; |
1116 | vq->inflight = 0; | 1214 | vq->inflight = 0; |
1215 | vq->blocked = false; | ||
1117 | 1216 | ||
1118 | /* Initialize the configuration. */ | 1217 | /* Initialize the configuration. */ |
1119 | vq->config.num = num_descs; | 1218 | vq->config.num = num_descs; |
@@ -1246,6 +1345,24 @@ static void setup_console(void) | |||
1246 | } | 1345 | } |
1247 | /*:*/ | 1346 | /*:*/ |
1248 | 1347 | ||
1348 | static void timeout_alarm(int sig) | ||
1349 | { | ||
1350 | write(timeoutpipe[1], "", 1); | ||
1351 | } | ||
1352 | |||
1353 | static void setup_timeout(void) | ||
1354 | { | ||
1355 | if (pipe(timeoutpipe) != 0) | ||
1356 | err(1, "Creating timeout pipe"); | ||
1357 | |||
1358 | if (fcntl(timeoutpipe[1], F_SETFL, | ||
1359 | fcntl(timeoutpipe[1], F_GETFL) | O_NONBLOCK) != 0) | ||
1360 | err(1, "Making timeout pipe nonblocking"); | ||
1361 | |||
1362 | add_device_fd(timeoutpipe[0]); | ||
1363 | signal(SIGALRM, timeout_alarm); | ||
1364 | } | ||
1365 | |||
1249 | /*M:010 Inter-guest networking is an interesting area. Simplest is to have a | 1366 | /*M:010 Inter-guest networking is an interesting area. Simplest is to have a |
1250 | * --sharenet=<name> option which opens or creates a named pipe. This can be | 1367 | * --sharenet=<name> option which opens or creates a named pipe. This can be |
1251 | * used to send packets to another guest in a 1:1 manner. | 1368 | * used to send packets to another guest in a 1:1 manner. |
@@ -1264,10 +1381,25 @@ static void setup_console(void) | |||
1264 | 1381 | ||
1265 | static u32 str2ip(const char *ipaddr) | 1382 | static u32 str2ip(const char *ipaddr) |
1266 | { | 1383 | { |
1267 | unsigned int byte[4]; | 1384 | unsigned int b[4]; |
1268 | 1385 | ||
1269 | sscanf(ipaddr, "%u.%u.%u.%u", &byte[0], &byte[1], &byte[2], &byte[3]); | 1386 | if (sscanf(ipaddr, "%u.%u.%u.%u", &b[0], &b[1], &b[2], &b[3]) != 4) |
1270 | return (byte[0] << 24) | (byte[1] << 16) | (byte[2] << 8) | byte[3]; | 1387 | errx(1, "Failed to parse IP address '%s'", ipaddr); |
1388 | return (b[0] << 24) | (b[1] << 16) | (b[2] << 8) | b[3]; | ||
1389 | } | ||
1390 | |||
1391 | static void str2mac(const char *macaddr, unsigned char mac[6]) | ||
1392 | { | ||
1393 | unsigned int m[6]; | ||
1394 | if (sscanf(macaddr, "%02x:%02x:%02x:%02x:%02x:%02x", | ||
1395 | &m[0], &m[1], &m[2], &m[3], &m[4], &m[5]) != 6) | ||
1396 | errx(1, "Failed to parse mac address '%s'", macaddr); | ||
1397 | mac[0] = m[0]; | ||
1398 | mac[1] = m[1]; | ||
1399 | mac[2] = m[2]; | ||
1400 | mac[3] = m[3]; | ||
1401 | mac[4] = m[4]; | ||
1402 | mac[5] = m[5]; | ||
1271 | } | 1403 | } |
1272 | 1404 | ||
1273 | /* This code is "adapted" from libbridge: it attaches the Host end of the | 1405 | /* This code is "adapted" from libbridge: it attaches the Host end of the |
@@ -1288,6 +1420,7 @@ static void add_to_bridge(int fd, const char *if_name, const char *br_name) | |||
1288 | errx(1, "interface %s does not exist!", if_name); | 1420 | errx(1, "interface %s does not exist!", if_name); |
1289 | 1421 | ||
1290 | strncpy(ifr.ifr_name, br_name, IFNAMSIZ); | 1422 | strncpy(ifr.ifr_name, br_name, IFNAMSIZ); |
1423 | ifr.ifr_name[IFNAMSIZ-1] = '\0'; | ||
1291 | ifr.ifr_ifindex = ifidx; | 1424 | ifr.ifr_ifindex = ifidx; |
1292 | if (ioctl(fd, SIOCBRADDIF, &ifr) < 0) | 1425 | if (ioctl(fd, SIOCBRADDIF, &ifr) < 0) |
1293 | err(1, "can't add %s to bridge %s", if_name, br_name); | 1426 | err(1, "can't add %s to bridge %s", if_name, br_name); |
@@ -1296,64 +1429,90 @@ static void add_to_bridge(int fd, const char *if_name, const char *br_name) | |||
1296 | /* This sets up the Host end of the network device with an IP address, brings | 1429 | /* This sets up the Host end of the network device with an IP address, brings |
1297 | * it up so packets will flow, the copies the MAC address into the hwaddr | 1430 | * it up so packets will flow, the copies the MAC address into the hwaddr |
1298 | * pointer. */ | 1431 | * pointer. */ |
1299 | static void configure_device(int fd, const char *devname, u32 ipaddr, | 1432 | static void configure_device(int fd, const char *tapif, u32 ipaddr) |
1300 | unsigned char hwaddr[6]) | ||
1301 | { | 1433 | { |
1302 | struct ifreq ifr; | 1434 | struct ifreq ifr; |
1303 | struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr; | 1435 | struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr; |
1304 | 1436 | ||
1305 | /* Don't read these incantations. Just cut & paste them like I did! */ | ||
1306 | memset(&ifr, 0, sizeof(ifr)); | 1437 | memset(&ifr, 0, sizeof(ifr)); |
1307 | strcpy(ifr.ifr_name, devname); | 1438 | strcpy(ifr.ifr_name, tapif); |
1439 | |||
1440 | /* Don't read these incantations. Just cut & paste them like I did! */ | ||
1308 | sin->sin_family = AF_INET; | 1441 | sin->sin_family = AF_INET; |
1309 | sin->sin_addr.s_addr = htonl(ipaddr); | 1442 | sin->sin_addr.s_addr = htonl(ipaddr); |
1310 | if (ioctl(fd, SIOCSIFADDR, &ifr) != 0) | 1443 | if (ioctl(fd, SIOCSIFADDR, &ifr) != 0) |
1311 | err(1, "Setting %s interface address", devname); | 1444 | err(1, "Setting %s interface address", tapif); |
1312 | ifr.ifr_flags = IFF_UP; | 1445 | ifr.ifr_flags = IFF_UP; |
1313 | if (ioctl(fd, SIOCSIFFLAGS, &ifr) != 0) | 1446 | if (ioctl(fd, SIOCSIFFLAGS, &ifr) != 0) |
1314 | err(1, "Bringing interface %s up", devname); | 1447 | err(1, "Bringing interface %s up", tapif); |
1448 | } | ||
1449 | |||
1450 | static void get_mac(int fd, const char *tapif, unsigned char hwaddr[6]) | ||
1451 | { | ||
1452 | struct ifreq ifr; | ||
1453 | |||
1454 | memset(&ifr, 0, sizeof(ifr)); | ||
1455 | strcpy(ifr.ifr_name, tapif); | ||
1315 | 1456 | ||
1316 | /* SIOC stands for Socket I/O Control. G means Get (vs S for Set | 1457 | /* SIOC stands for Socket I/O Control. G means Get (vs S for Set |
1317 | * above). IF means Interface, and HWADDR is hardware address. | 1458 | * above). IF means Interface, and HWADDR is hardware address. |
1318 | * Simple! */ | 1459 | * Simple! */ |
1319 | if (ioctl(fd, SIOCGIFHWADDR, &ifr) != 0) | 1460 | if (ioctl(fd, SIOCGIFHWADDR, &ifr) != 0) |
1320 | err(1, "getting hw address for %s", devname); | 1461 | err(1, "getting hw address for %s", tapif); |
1321 | memcpy(hwaddr, ifr.ifr_hwaddr.sa_data, 6); | 1462 | memcpy(hwaddr, ifr.ifr_hwaddr.sa_data, 6); |
1322 | } | 1463 | } |
1323 | 1464 | ||
1324 | /*L:195 Our network is a Host<->Guest network. This can either use bridging or | 1465 | static int get_tun_device(char tapif[IFNAMSIZ]) |
1325 | * routing, but the principle is the same: it uses the "tun" device to inject | ||
1326 | * packets into the Host as if they came in from a normal network card. We | ||
1327 | * just shunt packets between the Guest and the tun device. */ | ||
1328 | static void setup_tun_net(const char *arg) | ||
1329 | { | 1466 | { |
1330 | struct device *dev; | ||
1331 | struct ifreq ifr; | 1467 | struct ifreq ifr; |
1332 | int netfd, ipfd; | 1468 | int netfd; |
1333 | u32 ip; | 1469 | |
1334 | const char *br_name = NULL; | 1470 | /* Start with this zeroed. Messy but sure. */ |
1335 | struct virtio_net_config conf; | 1471 | memset(&ifr, 0, sizeof(ifr)); |
1336 | 1472 | ||
1337 | /* We open the /dev/net/tun device and tell it we want a tap device. A | 1473 | /* We open the /dev/net/tun device and tell it we want a tap device. A |
1338 | * tap device is like a tun device, only somehow different. To tell | 1474 | * tap device is like a tun device, only somehow different. To tell |
1339 | * the truth, I completely blundered my way through this code, but it | 1475 | * the truth, I completely blundered my way through this code, but it |
1340 | * works now! */ | 1476 | * works now! */ |
1341 | netfd = open_or_die("/dev/net/tun", O_RDWR); | 1477 | netfd = open_or_die("/dev/net/tun", O_RDWR); |
1342 | memset(&ifr, 0, sizeof(ifr)); | 1478 | ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_VNET_HDR; |
1343 | ifr.ifr_flags = IFF_TAP | IFF_NO_PI; | ||
1344 | strcpy(ifr.ifr_name, "tap%d"); | 1479 | strcpy(ifr.ifr_name, "tap%d"); |
1345 | if (ioctl(netfd, TUNSETIFF, &ifr) != 0) | 1480 | if (ioctl(netfd, TUNSETIFF, &ifr) != 0) |
1346 | err(1, "configuring /dev/net/tun"); | 1481 | err(1, "configuring /dev/net/tun"); |
1482 | |||
1483 | if (ioctl(netfd, TUNSETOFFLOAD, | ||
1484 | TUN_F_CSUM|TUN_F_TSO4|TUN_F_TSO6|TUN_F_TSO_ECN) != 0) | ||
1485 | err(1, "Could not set features for tun device"); | ||
1486 | |||
1347 | /* We don't need checksums calculated for packets coming in this | 1487 | /* We don't need checksums calculated for packets coming in this |
1348 | * device: trust us! */ | 1488 | * device: trust us! */ |
1349 | ioctl(netfd, TUNSETNOCSUM, 1); | 1489 | ioctl(netfd, TUNSETNOCSUM, 1); |
1350 | 1490 | ||
1491 | memcpy(tapif, ifr.ifr_name, IFNAMSIZ); | ||
1492 | return netfd; | ||
1493 | } | ||
1494 | |||
1495 | /*L:195 Our network is a Host<->Guest network. This can either use bridging or | ||
1496 | * routing, but the principle is the same: it uses the "tun" device to inject | ||
1497 | * packets into the Host as if they came in from a normal network card. We | ||
1498 | * just shunt packets between the Guest and the tun device. */ | ||
1499 | static void setup_tun_net(char *arg) | ||
1500 | { | ||
1501 | struct device *dev; | ||
1502 | int netfd, ipfd; | ||
1503 | u32 ip = INADDR_ANY; | ||
1504 | bool bridging = false; | ||
1505 | char tapif[IFNAMSIZ], *p; | ||
1506 | struct virtio_net_config conf; | ||
1507 | |||
1508 | netfd = get_tun_device(tapif); | ||
1509 | |||
1351 | /* First we create a new network device. */ | 1510 | /* First we create a new network device. */ |
1352 | dev = new_device("net", VIRTIO_ID_NET, netfd, handle_tun_input); | 1511 | dev = new_device("net", VIRTIO_ID_NET, netfd, handle_tun_input); |
1353 | 1512 | ||
1354 | /* Network devices need a receive and a send queue, just like | 1513 | /* Network devices need a receive and a send queue, just like |
1355 | * console. */ | 1514 | * console. */ |
1356 | add_virtqueue(dev, VIRTQUEUE_NUM, enable_fd); | 1515 | add_virtqueue(dev, VIRTQUEUE_NUM, net_enable_fd); |
1357 | add_virtqueue(dev, VIRTQUEUE_NUM, handle_net_output); | 1516 | add_virtqueue(dev, VIRTQUEUE_NUM, handle_net_output); |
1358 | 1517 | ||
1359 | /* We need a socket to perform the magic network ioctls to bring up the | 1518 | /* We need a socket to perform the magic network ioctls to bring up the |
@@ -1364,28 +1523,56 @@ static void setup_tun_net(const char *arg) | |||
1364 | 1523 | ||
1365 | /* If the command line was --tunnet=bridge:<name> do bridging. */ | 1524 | /* If the command line was --tunnet=bridge:<name> do bridging. */ |
1366 | if (!strncmp(BRIDGE_PFX, arg, strlen(BRIDGE_PFX))) { | 1525 | if (!strncmp(BRIDGE_PFX, arg, strlen(BRIDGE_PFX))) { |
1367 | ip = INADDR_ANY; | 1526 | arg += strlen(BRIDGE_PFX); |
1368 | br_name = arg + strlen(BRIDGE_PFX); | 1527 | bridging = true; |
1369 | add_to_bridge(ipfd, ifr.ifr_name, br_name); | 1528 | } |
1370 | } else /* It is an IP address to set up the device with */ | 1529 | |
1530 | /* A mac address may follow the bridge name or IP address */ | ||
1531 | p = strchr(arg, ':'); | ||
1532 | if (p) { | ||
1533 | str2mac(p+1, conf.mac); | ||
1534 | *p = '\0'; | ||
1535 | } else { | ||
1536 | p = arg + strlen(arg); | ||
1537 | /* None supplied; query the randomly assigned mac. */ | ||
1538 | get_mac(ipfd, tapif, conf.mac); | ||
1539 | } | ||
1540 | |||
1541 | /* arg is now either an IP address or a bridge name */ | ||
1542 | if (bridging) | ||
1543 | add_to_bridge(ipfd, tapif, arg); | ||
1544 | else | ||
1371 | ip = str2ip(arg); | 1545 | ip = str2ip(arg); |
1372 | 1546 | ||
1373 | /* Set up the tun device, and get the mac address for the interface. */ | 1547 | /* Set up the tun device. */ |
1374 | configure_device(ipfd, ifr.ifr_name, ip, conf.mac); | 1548 | configure_device(ipfd, tapif, ip); |
1375 | 1549 | ||
1376 | /* Tell Guest what MAC address to use. */ | 1550 | /* Tell Guest what MAC address to use. */ |
1377 | add_feature(dev, VIRTIO_NET_F_MAC); | 1551 | add_feature(dev, VIRTIO_NET_F_MAC); |
1378 | add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY); | 1552 | add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY); |
1553 | /* Expect Guest to handle everything except UFO */ | ||
1554 | add_feature(dev, VIRTIO_NET_F_CSUM); | ||
1555 | add_feature(dev, VIRTIO_NET_F_GUEST_CSUM); | ||
1556 | add_feature(dev, VIRTIO_NET_F_MAC); | ||
1557 | add_feature(dev, VIRTIO_NET_F_GUEST_TSO4); | ||
1558 | add_feature(dev, VIRTIO_NET_F_GUEST_TSO6); | ||
1559 | add_feature(dev, VIRTIO_NET_F_GUEST_ECN); | ||
1560 | add_feature(dev, VIRTIO_NET_F_HOST_TSO4); | ||
1561 | add_feature(dev, VIRTIO_NET_F_HOST_TSO6); | ||
1562 | add_feature(dev, VIRTIO_NET_F_HOST_ECN); | ||
1379 | set_config(dev, sizeof(conf), &conf); | 1563 | set_config(dev, sizeof(conf), &conf); |
1380 | 1564 | ||
1381 | /* We don't need the socket any more; setup is done. */ | 1565 | /* We don't need the socket any more; setup is done. */ |
1382 | close(ipfd); | 1566 | close(ipfd); |
1383 | 1567 | ||
1384 | verbose("device %u: tun net %u.%u.%u.%u\n", | 1568 | devices.device_num++; |
1385 | devices.device_num++, | 1569 | |
1386 | (u8)(ip>>24),(u8)(ip>>16),(u8)(ip>>8),(u8)ip); | 1570 | if (bridging) |
1387 | if (br_name) | 1571 | verbose("device %u: tun %s attached to bridge: %s\n", |
1388 | verbose("attached to bridge: %s\n", br_name); | 1572 | devices.device_num, tapif, arg); |
1573 | else | ||
1574 | verbose("device %u: tun %s: %s\n", | ||
1575 | devices.device_num, tapif, arg); | ||
1389 | } | 1576 | } |
1390 | 1577 | ||
1391 | /* Our block (disk) device should be really simple: the Guest asks for a block | 1578 | /* Our block (disk) device should be really simple: the Guest asks for a block |
@@ -1550,7 +1737,7 @@ static bool handle_io_finish(int fd, struct device *dev) | |||
1550 | } | 1737 | } |
1551 | 1738 | ||
1552 | /* When the Guest submits some I/O, we just need to wake the I/O thread. */ | 1739 | /* When the Guest submits some I/O, we just need to wake the I/O thread. */ |
1553 | static void handle_virtblk_output(int fd, struct virtqueue *vq) | 1740 | static void handle_virtblk_output(int fd, struct virtqueue *vq, bool timeout) |
1554 | { | 1741 | { |
1555 | struct vblk_info *vblk = vq->dev->priv; | 1742 | struct vblk_info *vblk = vq->dev->priv; |
1556 | char c = 0; | 1743 | char c = 0; |
@@ -1621,6 +1808,64 @@ static void setup_block_file(const char *filename) | |||
1621 | verbose("device %u: virtblock %llu sectors\n", | 1808 | verbose("device %u: virtblock %llu sectors\n", |
1622 | devices.device_num, le64_to_cpu(conf.capacity)); | 1809 | devices.device_num, le64_to_cpu(conf.capacity)); |
1623 | } | 1810 | } |
1811 | |||
1812 | /* Our random number generator device reads from /dev/random into the Guest's | ||
1813 | * input buffers. The usual case is that the Guest doesn't want random numbers | ||
1814 | * and so has no buffers although /dev/random is still readable, whereas | ||
1815 | * console is the reverse. | ||
1816 | * | ||
1817 | * The same logic applies, however. */ | ||
1818 | static bool handle_rng_input(int fd, struct device *dev) | ||
1819 | { | ||
1820 | int len; | ||
1821 | unsigned int head, in_num, out_num, totlen = 0; | ||
1822 | struct iovec iov[dev->vq->vring.num]; | ||
1823 | |||
1824 | /* First we need a buffer from the Guests's virtqueue. */ | ||
1825 | head = get_vq_desc(dev->vq, iov, &out_num, &in_num); | ||
1826 | |||
1827 | /* If they're not ready for input, stop listening to this file | ||
1828 | * descriptor. We'll start again once they add an input buffer. */ | ||
1829 | if (head == dev->vq->vring.num) | ||
1830 | return false; | ||
1831 | |||
1832 | if (out_num) | ||
1833 | errx(1, "Output buffers in rng?"); | ||
1834 | |||
1835 | /* This is why we convert to iovecs: the readv() call uses them, and so | ||
1836 | * it reads straight into the Guest's buffer. We loop to make sure we | ||
1837 | * fill it. */ | ||
1838 | while (!iov_empty(iov, in_num)) { | ||
1839 | len = readv(dev->fd, iov, in_num); | ||
1840 | if (len <= 0) | ||
1841 | err(1, "Read from /dev/random gave %i", len); | ||
1842 | iov_consume(iov, in_num, len); | ||
1843 | totlen += len; | ||
1844 | } | ||
1845 | |||
1846 | /* Tell the Guest about the new input. */ | ||
1847 | add_used_and_trigger(fd, dev->vq, head, totlen); | ||
1848 | |||
1849 | /* Everything went OK! */ | ||
1850 | return true; | ||
1851 | } | ||
1852 | |||
1853 | /* And this creates a "hardware" random number device for the Guest. */ | ||
1854 | static void setup_rng(void) | ||
1855 | { | ||
1856 | struct device *dev; | ||
1857 | int fd; | ||
1858 | |||
1859 | fd = open_or_die("/dev/random", O_RDONLY); | ||
1860 | |||
1861 | /* The device responds to return from I/O thread. */ | ||
1862 | dev = new_device("rng", VIRTIO_ID_RNG, fd, handle_rng_input); | ||
1863 | |||
1864 | /* The device has one virtqueue, where the Guest places inbufs. */ | ||
1865 | add_virtqueue(dev, VIRTQUEUE_NUM, enable_fd); | ||
1866 | |||
1867 | verbose("device %u: rng\n", devices.device_num++); | ||
1868 | } | ||
1624 | /* That's the end of device setup. */ | 1869 | /* That's the end of device setup. */ |
1625 | 1870 | ||
1626 | /*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */ | 1871 | /*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */ |
@@ -1628,11 +1873,12 @@ static void __attribute__((noreturn)) restart_guest(void) | |||
1628 | { | 1873 | { |
1629 | unsigned int i; | 1874 | unsigned int i; |
1630 | 1875 | ||
1631 | /* Closing pipes causes the Waker thread and io_threads to die, and | 1876 | /* Since we don't track all open fds, we simply close everything beyond |
1632 | * closing /dev/lguest cleans up the Guest. Since we don't track all | 1877 | * stderr. */ |
1633 | * open fds, we simply close everything beyond stderr. */ | ||
1634 | for (i = 3; i < FD_SETSIZE; i++) | 1878 | for (i = 3; i < FD_SETSIZE; i++) |
1635 | close(i); | 1879 | close(i); |
1880 | |||
1881 | /* The exec automatically gets rid of the I/O and Waker threads. */ | ||
1636 | execv(main_args[0], main_args); | 1882 | execv(main_args[0], main_args); |
1637 | err(1, "Could not exec %s", main_args[0]); | 1883 | err(1, "Could not exec %s", main_args[0]); |
1638 | } | 1884 | } |
@@ -1663,7 +1909,7 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd) | |||
1663 | /* ERESTART means that we need to reboot the guest */ | 1909 | /* ERESTART means that we need to reboot the guest */ |
1664 | } else if (errno == ERESTART) { | 1910 | } else if (errno == ERESTART) { |
1665 | restart_guest(); | 1911 | restart_guest(); |
1666 | /* EAGAIN means the Waker wanted us to look at some input. | 1912 | /* EAGAIN means a signal (timeout). |
1667 | * Anything else means a bug or incompatible change. */ | 1913 | * Anything else means a bug or incompatible change. */ |
1668 | } else if (errno != EAGAIN) | 1914 | } else if (errno != EAGAIN) |
1669 | err(1, "Running guest failed"); | 1915 | err(1, "Running guest failed"); |
@@ -1691,13 +1937,14 @@ static struct option opts[] = { | |||
1691 | { "verbose", 0, NULL, 'v' }, | 1937 | { "verbose", 0, NULL, 'v' }, |
1692 | { "tunnet", 1, NULL, 't' }, | 1938 | { "tunnet", 1, NULL, 't' }, |
1693 | { "block", 1, NULL, 'b' }, | 1939 | { "block", 1, NULL, 'b' }, |
1940 | { "rng", 0, NULL, 'r' }, | ||
1694 | { "initrd", 1, NULL, 'i' }, | 1941 | { "initrd", 1, NULL, 'i' }, |
1695 | { NULL }, | 1942 | { NULL }, |
1696 | }; | 1943 | }; |
1697 | static void usage(void) | 1944 | static void usage(void) |
1698 | { | 1945 | { |
1699 | errx(1, "Usage: lguest [--verbose] " | 1946 | errx(1, "Usage: lguest [--verbose] " |
1700 | "[--tunnet=(<ipaddr>|bridge:<bridgename>)\n" | 1947 | "[--tunnet=(<ipaddr>:<macaddr>|bridge:<bridgename>:<macaddr>)\n" |
1701 | "|--block=<filename>|--initrd=<filename>]...\n" | 1948 | "|--block=<filename>|--initrd=<filename>]...\n" |
1702 | "<mem-in-mb> vmlinux [args...]"); | 1949 | "<mem-in-mb> vmlinux [args...]"); |
1703 | } | 1950 | } |
@@ -1765,6 +2012,9 @@ int main(int argc, char *argv[]) | |||
1765 | case 'b': | 2012 | case 'b': |
1766 | setup_block_file(optarg); | 2013 | setup_block_file(optarg); |
1767 | break; | 2014 | break; |
2015 | case 'r': | ||
2016 | setup_rng(); | ||
2017 | break; | ||
1768 | case 'i': | 2018 | case 'i': |
1769 | initrd_name = optarg; | 2019 | initrd_name = optarg; |
1770 | break; | 2020 | break; |
@@ -1783,6 +2033,9 @@ int main(int argc, char *argv[]) | |||
1783 | /* We always have a console device */ | 2033 | /* We always have a console device */ |
1784 | setup_console(); | 2034 | setup_console(); |
1785 | 2035 | ||
2036 | /* We can timeout waiting for Guest network transmit. */ | ||
2037 | setup_timeout(); | ||
2038 | |||
1786 | /* Now we load the kernel */ | 2039 | /* Now we load the kernel */ |
1787 | start = load_kernel(open_or_die(argv[optind+1], O_RDONLY)); | 2040 | start = load_kernel(open_or_die(argv[optind+1], O_RDONLY)); |
1788 | 2041 | ||
@@ -1826,10 +2079,10 @@ int main(int argc, char *argv[]) | |||
1826 | * /dev/lguest file descriptor. */ | 2079 | * /dev/lguest file descriptor. */ |
1827 | lguest_fd = tell_kernel(pgdir, start); | 2080 | lguest_fd = tell_kernel(pgdir, start); |
1828 | 2081 | ||
1829 | /* We fork off a child process, which wakes the Launcher whenever one | 2082 | /* We clone off a thread, which wakes the Launcher whenever one of the |
1830 | * of the input file descriptors needs attention. We call this the | 2083 | * input file descriptors needs attention. We call this the Waker, and |
1831 | * Waker, and we'll cover it in a moment. */ | 2084 | * we'll cover it in a moment. */ |
1832 | waker_fd = setup_waker(lguest_fd); | 2085 | setup_waker(lguest_fd); |
1833 | 2086 | ||
1834 | /* Finally, run the Guest. This doesn't return. */ | 2087 | /* Finally, run the Guest. This doesn't return. */ |
1835 | run_guest(lguest_fd); | 2088 | run_guest(lguest_fd); |
diff --git a/Documentation/local_ops.txt b/Documentation/local_ops.txt index 4269a1105b37..f4f8b1c6c8ba 100644 --- a/Documentation/local_ops.txt +++ b/Documentation/local_ops.txt | |||
@@ -36,7 +36,7 @@ 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 | 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 | 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 | 38 | not have a different behavior between SMP and UP, including asm-generic/local.h |
39 | in your archtecture's local.h is sufficient. | 39 | in your architecture's local.h is sufficient. |
40 | 40 | ||
41 | The local_t type is defined as an opaque signed long by embedding an | 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 | 42 | atomic_long_t inside a structure. This is made so a cast from this type to a |
diff --git a/Documentation/md.txt b/Documentation/md.txt index a8b430627473..1da9d1b1793f 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt | |||
@@ -236,6 +236,11 @@ All md devices contain: | |||
236 | writing the word for the desired state, however some states | 236 | writing the word for the desired state, however some states |
237 | cannot be explicitly set, and some transitions are not allowed. | 237 | cannot be explicitly set, and some transitions are not allowed. |
238 | 238 | ||
239 | Select/poll works on this file. All changes except between | ||
240 | active_idle and active (which can be frequent and are not | ||
241 | very interesting) are notified. active->active_idle is | ||
242 | reported if the metadata is externally managed. | ||
243 | |||
239 | clear | 244 | clear |
240 | No devices, no size, no level | 245 | No devices, no size, no level |
241 | Writing is equivalent to STOP_ARRAY ioctl | 246 | Writing is equivalent to STOP_ARRAY ioctl |
@@ -292,6 +297,10 @@ Each directory contains: | |||
292 | writemostly - device will only be subject to read | 297 | writemostly - device will only be subject to read |
293 | requests if there are no other options. | 298 | requests if there are no other options. |
294 | This applies only to raid1 arrays. | 299 | This applies only to raid1 arrays. |
300 | blocked - device has failed, metadata is "external", | ||
301 | and the failure hasn't been acknowledged yet. | ||
302 | Writes that would write to this device if | ||
303 | it were not faulty are blocked. | ||
295 | spare - device is working, but not a full member. | 304 | spare - device is working, but not a full member. |
296 | This includes spares that are in the process | 305 | This includes spares that are in the process |
297 | of being recovered to | 306 | of being recovered to |
@@ -301,6 +310,12 @@ Each directory contains: | |||
301 | Writing "remove" removes the device from the array. | 310 | Writing "remove" removes the device from the array. |
302 | Writing "writemostly" sets the writemostly flag. | 311 | Writing "writemostly" sets the writemostly flag. |
303 | Writing "-writemostly" clears the writemostly flag. | 312 | Writing "-writemostly" clears the writemostly flag. |
313 | Writing "blocked" sets the "blocked" flag. | ||
314 | Writing "-blocked" clear the "blocked" flag and allows writes | ||
315 | to complete. | ||
316 | |||
317 | This file responds to select/poll. Any change to 'faulty' | ||
318 | or 'blocked' causes an event. | ||
304 | 319 | ||
305 | errors | 320 | errors |
306 | An approximate count of read errors that have been detected on | 321 | An approximate count of read errors that have been detected on |
@@ -332,7 +347,7 @@ Each directory contains: | |||
332 | for storage of data. This will normally be the same as the | 347 | for storage of data. This will normally be the same as the |
333 | component_size. This can be written while assembling an | 348 | component_size. This can be written while assembling an |
334 | array. If a value less than the current component_size is | 349 | array. If a value less than the current component_size is |
335 | written, component_size will be reduced to this value. | 350 | written, it will be rejected. |
336 | 351 | ||
337 | 352 | ||
338 | An active md device will also contain and entry for each active device | 353 | An active md device will also contain and entry for each active device |
@@ -381,6 +396,19 @@ also have | |||
381 | 'check' and 'repair' will start the appropriate process | 396 | 'check' and 'repair' will start the appropriate process |
382 | providing the current state is 'idle'. | 397 | providing the current state is 'idle'. |
383 | 398 | ||
399 | This file responds to select/poll. Any important change in the value | ||
400 | triggers a poll event. Sometimes the value will briefly be | ||
401 | "recover" if a recovery seems to be needed, but cannot be | ||
402 | achieved. In that case, the transition to "recover" isn't | ||
403 | notified, but the transition away is. | ||
404 | |||
405 | degraded | ||
406 | This contains a count of the number of devices by which the | ||
407 | arrays is degraded. So an optimal array with show '0'. A | ||
408 | single failed/missing drive will show '1', etc. | ||
409 | This file responds to select/poll, any increase or decrease | ||
410 | in the count of missing devices will trigger an event. | ||
411 | |||
384 | mismatch_count | 412 | mismatch_count |
385 | When performing 'check' and 'repair', and possibly when | 413 | When performing 'check' and 'repair', and possibly when |
386 | performing 'resync', md will count the number of errors that are | 414 | performing 'resync', md will count the number of errors that are |
diff --git a/Documentation/moxa-smartio b/Documentation/moxa-smartio index fe24ecc6372e..5337e80a5b96 100644 --- a/Documentation/moxa-smartio +++ b/Documentation/moxa-smartio | |||
@@ -1,14 +1,22 @@ | |||
1 | ============================================================================= | 1 | ============================================================================= |
2 | 2 | MOXA Smartio/Industio Family Device Driver Installation Guide | |
3 | MOXA Smartio Family Device Driver Ver 1.1 Installation Guide | 3 | for Linux Kernel 2.4.x, 2.6.x |
4 | for Linux Kernel 2.2.x and 2.0.3x | 4 | Copyright (C) 2008, Moxa Inc. |
5 | Copyright (C) 1999, Moxa Technologies Co, Ltd. | ||
6 | ============================================================================= | 5 | ============================================================================= |
6 | Date: 01/21/2008 | ||
7 | |||
7 | Content | 8 | Content |
8 | 9 | ||
9 | 1. Introduction | 10 | 1. Introduction |
10 | 2. System Requirement | 11 | 2. System Requirement |
11 | 3. Installation | 12 | 3. Installation |
13 | 3.1 Hardware installation | ||
14 | 3.2 Driver files | ||
15 | 3.3 Device naming convention | ||
16 | 3.4 Module driver configuration | ||
17 | 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x. | ||
18 | 3.6 Custom configuration | ||
19 | 3.7 Verify driver installation | ||
12 | 4. Utilities | 20 | 4. Utilities |
13 | 5. Setserial | 21 | 5. Setserial |
14 | 6. Troubleshooting | 22 | 6. Troubleshooting |
@@ -16,27 +24,48 @@ Content | |||
16 | ----------------------------------------------------------------------------- | 24 | ----------------------------------------------------------------------------- |
17 | 1. Introduction | 25 | 1. Introduction |
18 | 26 | ||
19 | The Smartio family Linux driver, Ver. 1.1, supports following multiport | 27 | The Smartio/Industio/UPCI family Linux driver supports following multiport |
20 | boards. | 28 | boards. |
21 | 29 | ||
22 | -C104P/H/HS, C104H/PCI, C104HS/PCI, CI-104J 4 port multiport board. | 30 | - 2 ports multiport board |
23 | -C168P/H/HS, C168H/PCI 8 port multiport board. | 31 | CP-102U, CP-102UL, CP-102UF |
24 | 32 | CP-132U-I, CP-132UL, | |
25 | This driver has been modified a little and cleaned up from the Moxa | 33 | CP-132, CP-132I, CP132S, CP-132IS, |
26 | contributed driver code and merged into Linux 2.2.14pre. In particular | 34 | CI-132, CI-132I, CI-132IS, |
27 | official major/minor numbers have been assigned which are different to | 35 | (C102H, C102HI, C102HIS, C102P, CP-102, CP-102S) |
28 | those the original Moxa supplied driver used. | 36 | |
37 | - 4 ports multiport board | ||
38 | CP-104EL, | ||
39 | CP-104UL, CP-104JU, | ||
40 | CP-134U, CP-134U-I, | ||
41 | C104H/PCI, C104HS/PCI, | ||
42 | CP-114, CP-114I, CP-114S, CP-114IS, CP-114UL, | ||
43 | C104H, C104HS, | ||
44 | CI-104J, CI-104JS, | ||
45 | CI-134, CI-134I, CI-134IS, | ||
46 | (C114HI, CT-114I, C104P) | ||
47 | POS-104UL, | ||
48 | CB-114, | ||
49 | CB-134I | ||
50 | |||
51 | - 8 ports multiport board | ||
52 | CP-118EL, CP-168EL, | ||
53 | CP-118U, CP-168U, | ||
54 | C168H/PCI, | ||
55 | C168H, C168HS, | ||
56 | (C168P), | ||
57 | CB-108 | ||
29 | 58 | ||
30 | This driver and installation procedure have been developed upon Linux Kernel | 59 | This driver and installation procedure have been developed upon Linux Kernel |
31 | 2.2.5 and backward compatible to 2.0.3x. This driver supports Intel x86 and | 60 | 2.4.x and 2.6.x. This driver supports Intel x86 hardware platform. In order |
32 | Alpha hardware platform. In order to maintain compatibility, this version | 61 | to maintain compatibility, this version has also been properly tested with |
33 | has also been properly tested with RedHat, OpenLinux, TurboLinux and | 62 | RedHat, Mandrake, Fedora and S.u.S.E Linux. However, if compatibility problem |
34 | S.u.S.E Linux. However, if compatibility problem occurs, please contact | 63 | occurs, please contact Moxa at support@moxa.com.tw. |
35 | Moxa at support@moxa.com.tw. | ||
36 | 64 | ||
37 | In addition to device driver, useful utilities are also provided in this | 65 | In addition to device driver, useful utilities are also provided in this |
38 | version. They are | 66 | version. They are |
39 | - msdiag Diagnostic program for detecting installed Moxa Smartio boards. | 67 | - msdiag Diagnostic program for displaying installed Moxa |
68 | Smartio/Industio boards. | ||
40 | - msmon Monitor program to observe data count and line status signals. | 69 | - msmon Monitor program to observe data count and line status signals. |
41 | - msterm A simple terminal program which is useful in testing serial | 70 | - msterm A simple terminal program which is useful in testing serial |
42 | ports. | 71 | ports. |
@@ -47,8 +76,7 @@ Content | |||
47 | GNU General Public License in this version. Please refer to GNU General | 76 | GNU General Public License in this version. Please refer to GNU General |
48 | Public License announcement in each source code file for more detail. | 77 | Public License announcement in each source code file for more detail. |
49 | 78 | ||
50 | In Moxa's ftp sites, you may always find latest driver at | 79 | In Moxa's Web sites, you may always find latest driver at http://web.moxa.com. |
51 | ftp://ftp.moxa.com or ftp://ftp.moxa.com.tw. | ||
52 | 80 | ||
53 | This version of driver can be installed as Loadable Module (Module driver) | 81 | This version of driver can be installed as Loadable Module (Module driver) |
54 | or built-in into kernel (Static driver). You may refer to following | 82 | or built-in into kernel (Static driver). You may refer to following |
@@ -61,8 +89,8 @@ Content | |||
61 | 89 | ||
62 | ----------------------------------------------------------------------------- | 90 | ----------------------------------------------------------------------------- |
63 | 2. System Requirement | 91 | 2. System Requirement |
64 | - Hardware platform: Intel x86 or Alpha machine | 92 | - Hardware platform: Intel x86 machine |
65 | - Kernel version: 2.0.3x or 2.2.x | 93 | - Kernel version: 2.4.x or 2.6.x |
66 | - gcc version 2.72 or later | 94 | - gcc version 2.72 or later |
67 | - Maximum 4 boards can be installed in combination | 95 | - Maximum 4 boards can be installed in combination |
68 | 96 | ||
@@ -70,9 +98,18 @@ Content | |||
70 | 3. Installation | 98 | 3. Installation |
71 | 99 | ||
72 | 3.1 Hardware installation | 100 | 3.1 Hardware installation |
101 | 3.2 Driver files | ||
102 | 3.3 Device naming convention | ||
103 | 3.4 Module driver configuration | ||
104 | 3.5 Static driver configuration for Linux kernel 2.4.x, 2.6.x. | ||
105 | 3.6 Custom configuration | ||
106 | 3.7 Verify driver installation | ||
107 | |||
108 | |||
109 | 3.1 Hardware installation | ||
73 | 110 | ||
74 | There are two types of buses, ISA and PCI, for Smartio family multiport | 111 | There are two types of buses, ISA and PCI, for Smartio/Industio |
75 | board. | 112 | family multiport board. |
76 | 113 | ||
77 | ISA board | 114 | ISA board |
78 | --------- | 115 | --------- |
@@ -81,47 +118,57 @@ Content | |||
81 | installation procedure in User's Manual before proceed any further. | 118 | installation procedure in User's Manual before proceed any further. |
82 | Please make sure the JP1 is open after the ISA board is set properly. | 119 | Please make sure the JP1 is open after the ISA board is set properly. |
83 | 120 | ||
84 | PCI board | 121 | PCI/UPCI board |
85 | --------- | 122 | -------------- |
86 | You may need to adjust IRQ usage in BIOS to avoid from IRQ conflict | 123 | You may need to adjust IRQ usage in BIOS to avoid from IRQ conflict |
87 | with other ISA devices. Please refer to hardware installation | 124 | with other ISA devices. Please refer to hardware installation |
88 | procedure in User's Manual in advance. | 125 | procedure in User's Manual in advance. |
89 | 126 | ||
90 | IRQ Sharing | 127 | PCI IRQ Sharing |
91 | ----------- | 128 | ----------- |
92 | Each port within the same multiport board shares the same IRQ. Up to | 129 | Each port within the same multiport board shares the same IRQ. Up to |
93 | 4 Moxa Smartio Family multiport boards can be installed together on | 130 | 4 Moxa Smartio/Industio PCI Family multiport boards can be installed |
94 | one system and they can share the same IRQ. | 131 | together on one system and they can share the same IRQ. |
132 | |||
95 | 133 | ||
96 | 3.2 Driver files and device naming convention | 134 | 3.2 Driver files |
97 | 135 | ||
98 | The driver file may be obtained from ftp, CD-ROM or floppy disk. The | 136 | The driver file may be obtained from ftp, CD-ROM or floppy disk. The |
99 | first step, anyway, is to copy driver file "mxser.tgz" into specified | 137 | first step, anyway, is to copy driver file "mxser.tgz" into specified |
100 | directory. e.g. /moxa. The execute commands as below. | 138 | directory. e.g. /moxa. The execute commands as below. |
101 | 139 | ||
140 | # cd / | ||
141 | # mkdir moxa | ||
102 | # cd /moxa | 142 | # cd /moxa |
103 | # tar xvf /dev/fd0 | 143 | # tar xvf /dev/fd0 |
144 | |||
104 | or | 145 | or |
146 | |||
147 | # cd / | ||
148 | # mkdir moxa | ||
105 | # cd /moxa | 149 | # cd /moxa |
106 | # cp /mnt/cdrom/<driver directory>/mxser.tgz . | 150 | # cp /mnt/cdrom/<driver directory>/mxser.tgz . |
107 | # tar xvfz mxser.tgz | 151 | # tar xvfz mxser.tgz |
108 | 152 | ||
153 | |||
154 | 3.3 Device naming convention | ||
155 | |||
109 | You may find all the driver and utilities files in /moxa/mxser. | 156 | You may find all the driver and utilities files in /moxa/mxser. |
110 | Following installation procedure depends on the model you'd like to | 157 | Following installation procedure depends on the model you'd like to |
111 | run the driver. If you prefer module driver, please refer to 3.3. | 158 | run the driver. If you prefer module driver, please refer to 3.4. |
112 | If static driver is required, please refer to 3.4. | 159 | If static driver is required, please refer to 3.5. |
113 | 160 | ||
114 | Dialin and callout port | 161 | Dialin and callout port |
115 | ----------------------- | 162 | ----------------------- |
116 | This driver remains traditional serial device properties. There're | 163 | This driver remains traditional serial device properties. There are |
117 | two special file name for each serial port. One is dial-in port | 164 | two special file name for each serial port. One is dial-in port |
118 | which is named "ttyMxx". For callout port, the naming convention | 165 | which is named "ttyMxx". For callout port, the naming convention |
119 | is "cumxx". | 166 | is "cumxx". |
120 | 167 | ||
121 | Device naming when more than 2 boards installed | 168 | Device naming when more than 2 boards installed |
122 | ----------------------------------------------- | 169 | ----------------------------------------------- |
123 | Naming convention for each Smartio multiport board is pre-defined | 170 | Naming convention for each Smartio/Industio multiport board is |
124 | as below. | 171 | pre-defined as below. |
125 | 172 | ||
126 | Board Num. Dial-in Port Callout port | 173 | Board Num. Dial-in Port Callout port |
127 | 1st board ttyM0 - ttyM7 cum0 - cum7 | 174 | 1st board ttyM0 - ttyM7 cum0 - cum7 |
@@ -129,6 +176,12 @@ Content | |||
129 | 3rd board ttyM16 - ttyM23 cum16 - cum23 | 176 | 3rd board ttyM16 - ttyM23 cum16 - cum23 |
130 | 4th board ttyM24 - ttym31 cum24 - cum31 | 177 | 4th board ttyM24 - ttym31 cum24 - cum31 |
131 | 178 | ||
179 | |||
180 | !!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | ||
181 | Under Kernel 2.6 the cum Device is Obsolete. So use ttyM* | ||
182 | device instead. | ||
183 | !!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | ||
184 | |||
132 | Board sequence | 185 | Board sequence |
133 | -------------- | 186 | -------------- |
134 | This driver will activate ISA boards according to the parameter set | 187 | This driver will activate ISA boards according to the parameter set |
@@ -138,69 +191,131 @@ Content | |||
138 | For PCI boards, their sequence will be after ISA boards and C168H/PCI | 191 | For PCI boards, their sequence will be after ISA boards and C168H/PCI |
139 | has higher priority than C104H/PCI boards. | 192 | has higher priority than C104H/PCI boards. |
140 | 193 | ||
141 | 3.3 Module driver configuration | 194 | 3.4 Module driver configuration |
142 | Module driver is easiest way to install. If you prefer static driver | 195 | Module driver is easiest way to install. If you prefer static driver |
143 | installation, please skip this paragraph. | 196 | installation, please skip this paragraph. |
144 | 1. Find "Makefile" in /moxa/mxser, then run | ||
145 | 197 | ||
146 | # make install | 198 | |
199 | ------------- Prepare to use the MOXA driver-------------------- | ||
200 | 3.4.1 Create tty device with correct major number | ||
201 | Before using MOXA driver, your system must have the tty devices | ||
202 | which are created with driver's major number. We offer one shell | ||
203 | script "msmknod" to simplify the procedure. | ||
204 | This step is only needed to be executed once. But you still | ||
205 | need to do this procedure when: | ||
206 | a. You change the driver's major number. Please refer the "3.7" | ||
207 | section. | ||
208 | b. Your total installed MOXA boards number is changed. Maybe you | ||
209 | add/delete one MOXA board. | ||
210 | c. You want to change the tty name. This needs to modify the | ||
211 | shell script "msmknod" | ||
212 | |||
213 | The procedure is: | ||
214 | # cd /moxa/mxser/driver | ||
215 | # ./msmknod | ||
216 | |||
217 | This shell script will require the major number for dial-in | ||
218 | device and callout device to create tty device. You also need | ||
219 | to specify the total installed MOXA board number. Default major | ||
220 | numbers for dial-in device and callout device are 30, 35. If | ||
221 | you need to change to other number, please refer section "3.7" | ||
222 | for more detailed procedure. | ||
223 | Msmknod will delete any special files occupying the same device | ||
224 | naming. | ||
225 | |||
226 | 3.4.2 Build the MOXA driver and utilities | ||
227 | Before using the MOXA driver and utilities, you need compile the | ||
228 | all the source code. This step is only need to be executed once. | ||
229 | But you still re-compile the source code if you modify the source | ||
230 | code. For example, if you change the driver's major number (see | ||
231 | "3.7" section), then you need to do this step again. | ||
232 | |||
233 | Find "Makefile" in /moxa/mxser, then run | ||
234 | |||
235 | # make clean; make install | ||
236 | |||
237 | !!!!!!!!!! NOTE !!!!!!!!!!!!!!!!! | ||
238 | For Red Hat 9, Red Hat Enterprise Linux AS3/ES3/WS3 & Fedora Core1: | ||
239 | # make clean; make installsp1 | ||
240 | |||
241 | For Red Hat Enterprise Linux AS4/ES4/WS4: | ||
242 | # make clean; make installsp2 | ||
243 | !!!!!!!!!! NOTE !!!!!!!!!!!!!!!!! | ||
147 | 244 | ||
148 | The driver files "mxser.o" and utilities will be properly compiled | 245 | The driver files "mxser.o" and utilities will be properly compiled |
149 | and copied to system directories respectively.Then run | 246 | and copied to system directories respectively. |
150 | 247 | ||
151 | # insmod mxser | 248 | ------------- Load MOXA driver-------------------- |
249 | 3.4.3 Load the MOXA driver | ||
152 | 250 | ||
153 | to activate the modular driver. You may run "lsmod" to check | 251 | # modprobe mxser <argument> |
154 | if "mxser.o" is activated. | ||
155 | 252 | ||
156 | 2. Create special files by executing "msmknod". | 253 | will activate the module driver. You may run "lsmod" to check |
157 | # cd /moxa/mxser/driver | 254 | if "mxser" is activated. If the MOXA board is ISA board, the |
158 | # ./msmknod | 255 | <argument> is needed. Please refer to section "3.4.5" for more |
256 | information. | ||
257 | |||
258 | |||
259 | ------------- Load MOXA driver on boot -------------------- | ||
260 | 3.4.4 For the above description, you may manually execute | ||
261 | "modprobe mxser" to activate this driver and run | ||
262 | "rmmod mxser" to remove it. | ||
263 | However, it's better to have a boot time configuration to | ||
264 | eliminate manual operation. Boot time configuration can be | ||
265 | achieved by rc file. We offer one "rc.mxser" file to simplify | ||
266 | the procedure under "moxa/mxser/driver". | ||
159 | 267 | ||
160 | Default major numbers for dial-in device and callout device are | 268 | But if you use ISA board, please modify the "modprobe ..." command |
161 | 174, 175. Msmknod will delete any special files occupying the same | 269 | to add the argument (see "3.4.5" section). After modifying the |
162 | device naming. | 270 | rc.mxser, please try to execute "/moxa/mxser/driver/rc.mxser" |
271 | manually to make sure the modification is ok. If any error | ||
272 | encountered, please try to modify again. If the modification is | ||
273 | completed, follow the below step. | ||
163 | 274 | ||
164 | 3. Up to now, you may manually execute "insmod mxser" to activate | 275 | Run following command for setting rc files. |
165 | this driver and run "rmmod mxser" to remove it. However, it's | ||
166 | better to have a boot time configuration to eliminate manual | ||
167 | operation. | ||
168 | Boot time configuration can be achieved by rc file. Run following | ||
169 | command for setting rc files. | ||
170 | 276 | ||
171 | # cd /moxa/mxser/driver | 277 | # cd /moxa/mxser/driver |
172 | # cp ./rc.mxser /etc/rc.d | 278 | # cp ./rc.mxser /etc/rc.d |
173 | # cd /etc/rc.d | 279 | # cd /etc/rc.d |
174 | 280 | ||
175 | You may have to modify part of the content in rc.mxser to specify | 281 | Check "rc.serial" is existed or not. If "rc.serial" doesn't exist, |
176 | parameters for ISA board. Please refer to rc.mxser for more detail. | 282 | create it by vi, run "chmod 755 rc.serial" to change the permission. |
177 | Find "rc.serial". If "rc.serial" doesn't exist, create it by vi. | 283 | Add "/etc/rc.d/rc.mxser" in last line, |
178 | Add "rc.mxser" in last line. Next, open rc.local by vi | ||
179 | and append following content. | ||
180 | 284 | ||
181 | if [ -f /etc/rc.d/rc.serial ]; then | 285 | Reboot and check if moxa.o activated by "lsmod" command. |
182 | sh /etc/rc.d/rc.serial | ||
183 | fi | ||
184 | 286 | ||
185 | 4. Reboot and check if mxser.o activated by "lsmod" command. | 287 | 3.4.5. If you'd like to drive Smartio/Industio ISA boards in the system, |
186 | 5. If you'd like to drive Smartio ISA boards in the system, you'll | 288 | you'll have to add parameter to specify CAP address of given |
187 | have to add parameter to specify CAP address of given board while | 289 | board while activating "mxser.o". The format for parameters are |
188 | activating "mxser.o". The format for parameters are as follows. | 290 | as follows. |
189 | 291 | ||
190 | insmod mxser ioaddr=0x???,0x???,0x???,0x??? | 292 | modprobe mxser ioaddr=0x???,0x???,0x???,0x??? |
191 | | | | | | 293 | | | | | |
192 | | | | +- 4th ISA board | 294 | | | | +- 4th ISA board |
193 | | | +------ 3rd ISA board | 295 | | | +------ 3rd ISA board |
194 | | +------------ 2nd ISA board | 296 | | +------------ 2nd ISA board |
195 | +------------------- 1st ISA board | 297 | +------------------- 1st ISA board |
196 | 298 | ||
197 | 3.4 Static driver configuration | 299 | 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x |
300 | |||
301 | Note: To use static driver, you must install the linux kernel | ||
302 | source package. | ||
303 | |||
304 | 3.5.1 Backup the built-in driver in the kernel. | ||
305 | # cd /usr/src/linux/drivers/char | ||
306 | # mv mxser.c mxser.c.old | ||
307 | |||
308 | For Red Hat 7.x user, you need to create link: | ||
309 | # cd /usr/src | ||
310 | # ln -s linux-2.4 linux | ||
198 | 311 | ||
199 | 1. Create link | 312 | 3.5.2 Create link |
200 | # cd /usr/src/linux/drivers/char | 313 | # cd /usr/src/linux/drivers/char |
201 | # ln -s /moxa/mxser/driver/mxser.c mxser.c | 314 | # ln -s /moxa/mxser/driver/mxser.c mxser.c |
202 | 315 | ||
203 | 2. Add CAP address list for ISA boards | 316 | 3.5.3 Add CAP address list for ISA boards. For PCI boards user, |
317 | please skip this step. | ||
318 | |||
204 | In module mode, the CAP address for ISA board is given by | 319 | In module mode, the CAP address for ISA board is given by |
205 | parameter. In static driver configuration, you'll have to | 320 | parameter. In static driver configuration, you'll have to |
206 | assign it within driver's source code. If you will not | 321 | assign it within driver's source code. If you will not |
@@ -222,73 +337,55 @@ Content | |||
222 | static int mxserBoardCAP[] | 337 | static int mxserBoardCAP[] |
223 | = {0x280, 0x180, 0x00, 0x00}; | 338 | = {0x280, 0x180, 0x00, 0x00}; |
224 | 339 | ||
225 | 3. Modify tty_io.c | 340 | 3.5.4 Setup kernel configuration |
226 | # cd /usr/src/linux/drivers/char/ | ||
227 | # vi tty_io.c | ||
228 | Find pty_init(), insert "mxser_init()" as | ||
229 | 341 | ||
230 | pty_init(); | 342 | Configure the kernel: |
231 | mxser_init(); | ||
232 | 343 | ||
233 | 4. Modify tty.h | 344 | # cd /usr/src/linux |
234 | # cd /usr/src/linux/include/linux | 345 | # make menuconfig |
235 | # vi tty.h | ||
236 | Find extern int tty_init(void), insert "mxser_init()" as | ||
237 | 346 | ||
238 | extern int tty_init(void); | 347 | You will go into a menu-driven system. Please select [Character |
239 | extern int mxser_init(void); | 348 | devices][Non-standard serial port support], enable the [Moxa |
240 | 349 | SmartIO support] driver with "[*]" for built-in (not "[M]"), then | |
241 | 5. Modify Makefile | 350 | select [Exit] to exit this program. |
242 | # cd /usr/src/linux/drivers/char | ||
243 | # vi Makefile | ||
244 | Find L_OBJS := tty_io.o ...... random.o, add | ||
245 | "mxser.o" at last of this line as | ||
246 | L_OBJS := tty_io.o ....... mxser.o | ||
247 | 351 | ||
248 | 6. Rebuild kernel | 352 | 3.5.5 Rebuild kernel |
249 | The following are for Linux kernel rebuilding,for your reference only. | 353 | The following are for Linux kernel rebuilding, for your |
354 | reference only. | ||
250 | For appropriate details, please refer to the Linux document. | 355 | For appropriate details, please refer to the Linux document. |
251 | 356 | ||
252 | If 'lilo' utility is installed, please use 'make zlilo' to rebuild | ||
253 | kernel. If 'lilo' is not installed, please follow the following steps. | ||
254 | |||
255 | a. cd /usr/src/linux | 357 | a. cd /usr/src/linux |
256 | b. make clean /* take a few minutes */ | 358 | b. make clean /* take a few minutes */ |
257 | c. make bzImage /* take probably 10-20 minutes */ | 359 | c. make dep /* take a few minutes */ |
258 | d. Backup original boot kernel. /* optional step */ | 360 | d. make bzImage /* take probably 10-20 minutes */ |
259 | e. cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz | 361 | e. make install /* copy boot image to correct position */ |
260 | f. Please make sure the boot kernel (vmlinuz) is in the | 362 | f. Please make sure the boot kernel (vmlinuz) is in the |
261 | correct position. If you use 'lilo' utility, you should | 363 | correct position. |
262 | check /etc/lilo.conf 'image' item specified the path | 364 | g. If you use 'lilo' utility, you should check /etc/lilo.conf |
263 | which is the 'vmlinuz' path, or you will load wrong | 365 | 'image' item specified the path which is the 'vmlinuz' path, |
264 | (or old) boot kernel image (vmlinuz). | 366 | or you will load wrong (or old) boot kernel image (vmlinuz). |
265 | g. chmod 400 /vmlinuz | 367 | After checking /etc/lilo.conf, please run "lilo". |
266 | h. lilo | 368 | |
267 | i. rdev -R /vmlinuz 1 | 369 | Note that if the result of "make bzImage" is ERROR, then you have to |
268 | j. sync | 370 | go back to Linux configuration Setup. Type "make menuconfig" in |
269 | 371 | directory /usr/src/linux. | |
270 | Note that if the result of "make zImage" is ERROR, then you have to | 372 | |
271 | go back to Linux configuration Setup. Type "make config" in directory | 373 | |
272 | /usr/src/linux or "setup". | 374 | 3.5.6 Make tty device and special file |
273 | |||
274 | Since system include file, /usr/src/linux/include/linux/interrupt.h, | ||
275 | is modified each time the MOXA driver is installed, kernel rebuilding | ||
276 | is inevitable. And it takes about 10 to 20 minutes depends on the | ||
277 | machine. | ||
278 | |||
279 | 7. Make utility | ||
280 | # cd /moxa/mxser/utility | ||
281 | # make install | ||
282 | |||
283 | 8. Make special file | ||
284 | # cd /moxa/mxser/driver | 375 | # cd /moxa/mxser/driver |
285 | # ./msmknod | 376 | # ./msmknod |
286 | 377 | ||
287 | 9. Reboot | 378 | 3.5.7 Make utility |
379 | # cd /moxa/mxser/utility | ||
380 | # make clean; make install | ||
381 | |||
382 | 3.5.8 Reboot | ||
288 | 383 | ||
289 | 3.5 Custom configuration | 384 | |
385 | |||
386 | 3.6 Custom configuration | ||
290 | Although this driver already provides you default configuration, you | 387 | Although this driver already provides you default configuration, you |
291 | still can change the device name and major number.The instruction to | 388 | still can change the device name and major number. The instruction to |
292 | change these parameters are shown as below. | 389 | change these parameters are shown as below. |
293 | 390 | ||
294 | Change Device name | 391 | Change Device name |
@@ -306,33 +403,37 @@ Content | |||
306 | 2 free major numbers for this driver. There are 3 steps to change | 403 | 2 free major numbers for this driver. There are 3 steps to change |
307 | major numbers. | 404 | major numbers. |
308 | 405 | ||
309 | 1. Find free major numbers | 406 | 3.6.1 Find free major numbers |
310 | In /proc/devices, you may find all the major numbers occupied | 407 | In /proc/devices, you may find all the major numbers occupied |
311 | in the system. Please select 2 major numbers that are available. | 408 | in the system. Please select 2 major numbers that are available. |
312 | e.g. 40, 45. | 409 | e.g. 40, 45. |
313 | 2. Create special files | 410 | 3.6.2 Create special files |
314 | Run /moxa/mxser/driver/msmknod to create special files with | 411 | Run /moxa/mxser/driver/msmknod to create special files with |
315 | specified major numbers. | 412 | specified major numbers. |
316 | 3. Modify driver with new major number | 413 | 3.6.3 Modify driver with new major number |
317 | Run vi to open /moxa/mxser/driver/mxser.c. Locate the line | 414 | Run vi to open /moxa/mxser/driver/mxser.c. Locate the line |
318 | contains "MXSERMAJOR". Change the content as below. | 415 | contains "MXSERMAJOR". Change the content as below. |
319 | #define MXSERMAJOR 40 | 416 | #define MXSERMAJOR 40 |
320 | #define MXSERCUMAJOR 45 | 417 | #define MXSERCUMAJOR 45 |
321 | 4. Run # make install in /moxa/mxser/driver. | 418 | 3.6.4 Run "make clean; make install" in /moxa/mxser/driver. |
322 | 419 | ||
323 | 3.6 Verify driver installation | 420 | 3.7 Verify driver installation |
324 | You may refer to /var/log/messages to check the latest status | 421 | You may refer to /var/log/messages to check the latest status |
325 | log reported by this driver whenever it's activated. | 422 | log reported by this driver whenever it's activated. |
423 | |||
326 | ----------------------------------------------------------------------------- | 424 | ----------------------------------------------------------------------------- |
327 | 4. Utilities | 425 | 4. Utilities |
328 | There are 3 utilities contained in this driver. They are msdiag, msmon and | 426 | There are 3 utilities contained in this driver. They are msdiag, msmon and |
329 | msterm. These 3 utilities are released in form of source code. They should | 427 | msterm. These 3 utilities are released in form of source code. They should |
330 | be compiled into executable file and copied into /usr/bin. | 428 | be compiled into executable file and copied into /usr/bin. |
331 | 429 | ||
430 | Before using these utilities, please load driver (refer 3.4 & 3.5) and | ||
431 | make sure you had run the "msmknod" utility. | ||
432 | |||
332 | msdiag - Diagnostic | 433 | msdiag - Diagnostic |
333 | -------------------- | 434 | -------------------- |
334 | This utility provides the function to detect what Moxa Smartio multiport | 435 | This utility provides the function to display what Moxa Smartio/Industio |
335 | board exists in the system. | 436 | board found by driver in the system. |
336 | 437 | ||
337 | msmon - Port Monitoring | 438 | msmon - Port Monitoring |
338 | ----------------------- | 439 | ----------------------- |
@@ -353,12 +454,13 @@ Content | |||
353 | application, for example, sending AT command to a modem connected to the | 454 | application, for example, sending AT command to a modem connected to the |
354 | port or used as a terminal for login purpose. Note that this is only a | 455 | port or used as a terminal for login purpose. Note that this is only a |
355 | dumb terminal emulation without handling full screen operation. | 456 | dumb terminal emulation without handling full screen operation. |
457 | |||
356 | ----------------------------------------------------------------------------- | 458 | ----------------------------------------------------------------------------- |
357 | 5. Setserial | 459 | 5. Setserial |
358 | 460 | ||
359 | Supported Setserial parameters are listed as below. | 461 | Supported Setserial parameters are listed as below. |
360 | 462 | ||
361 | uart set UART type(16450-->disable FIFO, 16550A-->enable FIFO) | 463 | uart set UART type(16450-->disable FIFO, 16550A-->enable FIFO) |
362 | close_delay set the amount of time(in 1/100 of a second) that DTR | 464 | close_delay set the amount of time(in 1/100 of a second) that DTR |
363 | should be kept low while being closed. | 465 | should be kept low while being closed. |
364 | closing_wait set the amount of time(in 1/100 of a second) that the | 466 | closing_wait set the amount of time(in 1/100 of a second) that the |
@@ -366,7 +468,13 @@ Content | |||
366 | being closed, before the receiver is disable. | 468 | being closed, before the receiver is disable. |
367 | spd_hi Use 57.6kb when the application requests 38.4kb. | 469 | spd_hi Use 57.6kb when the application requests 38.4kb. |
368 | spd_vhi Use 115.2kb when the application requests 38.4kb. | 470 | spd_vhi Use 115.2kb when the application requests 38.4kb. |
471 | spd_shi Use 230.4kb when the application requests 38.4kb. | ||
472 | spd_warp Use 460.8kb when the application requests 38.4kb. | ||
369 | spd_normal Use 38.4kb when the application requests 38.4kb. | 473 | spd_normal Use 38.4kb when the application requests 38.4kb. |
474 | spd_cust Use the custom divisor to set the speed when the | ||
475 | application requests 38.4kb. | ||
476 | divisor This option set the custom divison. | ||
477 | baud_base This option set the base baud rate. | ||
370 | 478 | ||
371 | ----------------------------------------------------------------------------- | 479 | ----------------------------------------------------------------------------- |
372 | 6. Troubleshooting | 480 | 6. Troubleshooting |
@@ -375,8 +483,9 @@ Content | |||
375 | possible. If all the possible solutions fail, please contact our technical | 483 | possible. If all the possible solutions fail, please contact our technical |
376 | support team to get more help. | 484 | support team to get more help. |
377 | 485 | ||
378 | Error msg: More than 4 Moxa Smartio family boards found. Fifth board and | 486 | |
379 | after are ignored. | 487 | Error msg: More than 4 Moxa Smartio/Industio family boards found. Fifth board |
488 | and after are ignored. | ||
380 | Solution: | 489 | Solution: |
381 | To avoid this problem, please unplug fifth and after board, because Moxa | 490 | To avoid this problem, please unplug fifth and after board, because Moxa |
382 | driver supports up to 4 boards. | 491 | driver supports up to 4 boards. |
@@ -384,7 +493,7 @@ Content | |||
384 | Error msg: Request_irq fail, IRQ(?) may be conflict with another device. | 493 | Error msg: Request_irq fail, IRQ(?) may be conflict with another device. |
385 | Solution: | 494 | Solution: |
386 | Other PCI or ISA devices occupy the assigned IRQ. If you are not sure | 495 | Other PCI or ISA devices occupy the assigned IRQ. If you are not sure |
387 | which device causes the situation,please check /proc/interrupts to find | 496 | which device causes the situation, please check /proc/interrupts to find |
388 | free IRQ and simply change another free IRQ for Moxa board. | 497 | free IRQ and simply change another free IRQ for Moxa board. |
389 | 498 | ||
390 | Error msg: Board #: C1xx Series(CAP=xxx) interrupt number invalid. | 499 | Error msg: Board #: C1xx Series(CAP=xxx) interrupt number invalid. |
@@ -397,15 +506,18 @@ Content | |||
397 | Moxa ISA board needs an interrupt vector.Please refer to user's manual | 506 | Moxa ISA board needs an interrupt vector.Please refer to user's manual |
398 | "Hardware Installation" chapter to set interrupt vector. | 507 | "Hardware Installation" chapter to set interrupt vector. |
399 | 508 | ||
400 | Error msg: Couldn't install MOXA Smartio family driver! | 509 | Error msg: Couldn't install MOXA Smartio/Industio family driver! |
401 | Solution: | 510 | Solution: |
402 | Load Moxa driver fail, the major number may conflict with other devices. | 511 | Load Moxa driver fail, the major number may conflict with other devices. |
403 | Please refer to previous section 3.5 to change a free major number for | 512 | Please refer to previous section 3.7 to change a free major number for |
404 | Moxa driver. | 513 | Moxa driver. |
405 | 514 | ||
406 | Error msg: Couldn't install MOXA Smartio family callout driver! | 515 | Error msg: Couldn't install MOXA Smartio/Industio family callout driver! |
407 | Solution: | 516 | Solution: |
408 | Load Moxa callout driver fail, the callout device major number may | 517 | Load Moxa callout driver fail, the callout device major number may |
409 | conflict with other devices. Please refer to previous section 3.5 to | 518 | conflict with other devices. Please refer to previous section 3.7 to |
410 | change a free callout device major number for Moxa driver. | 519 | change a free callout device major number for Moxa driver. |
520 | |||
521 | |||
411 | ----------------------------------------------------------------------------- | 522 | ----------------------------------------------------------------------------- |
523 | |||
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index a0cda062bc33..688dfe1e6b70 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt | |||
@@ -289,35 +289,73 @@ downdelay | |||
289 | fail_over_mac | 289 | fail_over_mac |
290 | 290 | ||
291 | Specifies whether active-backup mode should set all slaves to | 291 | Specifies whether active-backup mode should set all slaves to |
292 | the same MAC address (the traditional behavior), or, when | 292 | the same MAC address at enslavement (the traditional |
293 | enabled, change the bond's MAC address when changing the | 293 | behavior), or, when enabled, perform special handling of the |
294 | active interface (i.e., fail over the MAC address itself). | 294 | bond's MAC address in accordance with the selected policy. |
295 | 295 | ||
296 | Fail over MAC is useful for devices that cannot ever alter | 296 | Possible values are: |
297 | their MAC address, or for devices that refuse incoming | 297 | |
298 | broadcasts with their own source MAC (which interferes with | 298 | none or 0 |
299 | the ARP monitor). | 299 | |
300 | 300 | This setting disables fail_over_mac, and causes | |
301 | The down side of fail over MAC is that every device on the | 301 | bonding to set all slaves of an active-backup bond to |
302 | network must be updated via gratuitous ARP, vs. just updating | 302 | the same MAC address at enslavement time. This is the |
303 | a switch or set of switches (which often takes place for any | 303 | default. |
304 | traffic, not just ARP traffic, if the switch snoops incoming | 304 | |
305 | traffic to update its tables) for the traditional method. If | 305 | active or 1 |
306 | the gratuitous ARP is lost, communication may be disrupted. | 306 | |
307 | 307 | The "active" fail_over_mac policy indicates that the | |
308 | When fail over MAC is used in conjuction with the mii monitor, | 308 | MAC address of the bond should always be the MAC |
309 | devices which assert link up prior to being able to actually | 309 | address of the currently active slave. The MAC |
310 | transmit and receive are particularly susecptible to loss of | 310 | address of the slaves is not changed; instead, the MAC |
311 | the gratuitous ARP, and an appropriate updelay setting may be | 311 | address of the bond changes during a failover. |
312 | required. | 312 | |
313 | 313 | This policy is useful for devices that cannot ever | |
314 | A value of 0 disables fail over MAC, and is the default. A | 314 | alter their MAC address, or for devices that refuse |
315 | value of 1 enables fail over MAC. This option is enabled | 315 | incoming broadcasts with their own source MAC (which |
316 | automatically if the first slave added cannot change its MAC | 316 | interferes with the ARP monitor). |
317 | address. This option may be modified via sysfs only when no | 317 | |
318 | slaves are present in the bond. | 318 | The down side of this policy is that every device on |
319 | 319 | the network must be updated via gratuitous ARP, | |
320 | This option was added in bonding version 3.2.0. | 320 | vs. just updating a switch or set of switches (which |
321 | often takes place for any traffic, not just ARP | ||
322 | traffic, if the switch snoops incoming traffic to | ||
323 | update its tables) for the traditional method. If the | ||
324 | gratuitous ARP is lost, communication may be | ||
325 | disrupted. | ||
326 | |||
327 | When this policy is used in conjuction with the mii | ||
328 | monitor, devices which assert link up prior to being | ||
329 | able to actually transmit and receive are particularly | ||
330 | susecptible to loss of the gratuitous ARP, and an | ||
331 | appropriate updelay setting may be required. | ||
332 | |||
333 | follow or 2 | ||
334 | |||
335 | The "follow" fail_over_mac policy causes the MAC | ||
336 | address of the bond to be selected normally (normally | ||
337 | the MAC address of the first slave added to the bond). | ||
338 | However, the second and subsequent slaves are not set | ||
339 | to this MAC address while they are in a backup role; a | ||
340 | slave is programmed with the bond's MAC address at | ||
341 | failover time (and the formerly active slave receives | ||
342 | the newly active slave's MAC address). | ||
343 | |||
344 | This policy is useful for multiport devices that | ||
345 | either become confused or incur a performance penalty | ||
346 | when multiple ports are programmed with the same MAC | ||
347 | address. | ||
348 | |||
349 | |||
350 | The default policy is none, unless the first slave cannot | ||
351 | change its MAC address, in which case the active policy is | ||
352 | selected by default. | ||
353 | |||
354 | This option may be modified via sysfs only when no slaves are | ||
355 | present in the bond. | ||
356 | |||
357 | This option was added in bonding version 3.2.0. The "follow" | ||
358 | policy was added in bonding version 3.3.0. | ||
321 | 359 | ||
322 | lacp_rate | 360 | lacp_rate |
323 | 361 | ||
@@ -338,7 +376,8 @@ max_bonds | |||
338 | Specifies the number of bonding devices to create for this | 376 | Specifies the number of bonding devices to create for this |
339 | instance of the bonding driver. E.g., if max_bonds is 3, and | 377 | instance of the bonding driver. E.g., if max_bonds is 3, and |
340 | the bonding driver is not already loaded, then bond0, bond1 | 378 | the bonding driver is not already loaded, then bond0, bond1 |
341 | and bond2 will be created. The default value is 1. | 379 | and bond2 will be created. The default value is 1. Specifying |
380 | a value of 0 will load bonding, but will not create any devices. | ||
342 | 381 | ||
343 | miimon | 382 | miimon |
344 | 383 | ||
@@ -501,6 +540,17 @@ mode | |||
501 | swapped with the new curr_active_slave that was | 540 | swapped with the new curr_active_slave that was |
502 | chosen. | 541 | chosen. |
503 | 542 | ||
543 | num_grat_arp | ||
544 | |||
545 | Specifies the number of gratuitous ARPs to be issued after a | ||
546 | failover event. One gratuitous ARP is issued immediately after | ||
547 | the failover, subsequent ARPs are sent at a rate of one per link | ||
548 | monitor interval (arp_interval or miimon, whichever is active). | ||
549 | |||
550 | The valid range is 0 - 255; the default value is 1. This option | ||
551 | affects only the active-backup mode. This option was added for | ||
552 | bonding version 3.3.0. | ||
553 | |||
504 | primary | 554 | primary |
505 | 555 | ||
506 | A string (eth0, eth2, etc) specifying which slave is the | 556 | A string (eth0, eth2, etc) specifying which slave is the |
@@ -581,7 +631,7 @@ xmit_hash_policy | |||
581 | in environments where a layer3 gateway device is | 631 | in environments where a layer3 gateway device is |
582 | required to reach most destinations. | 632 | required to reach most destinations. |
583 | 633 | ||
584 | This algorithm is 802.3ad complient. | 634 | This algorithm is 802.3ad compliant. |
585 | 635 | ||
586 | layer3+4 | 636 | layer3+4 |
587 | 637 | ||
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 641d2afacffa..297ba7b1ccaf 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt | |||
@@ -186,7 +186,7 @@ solution for a couple of reasons: | |||
186 | 186 | ||
187 | The Linux network devices (by default) just can handle the | 187 | The Linux network devices (by default) just can handle the |
188 | transmission and reception of media dependent frames. Due to the | 188 | transmission and reception of media dependent frames. Due to the |
189 | arbritration on the CAN bus the transmission of a low prio CAN-ID | 189 | arbitration on the CAN bus the transmission of a low prio CAN-ID |
190 | may be delayed by the reception of a high prio CAN frame. To | 190 | may be delayed by the reception of a high prio CAN frame. To |
191 | reflect the correct* traffic on the node the loopback of the sent | 191 | reflect the correct* traffic on the node the loopback of the sent |
192 | data has to be performed right after a successful transmission. If | 192 | data has to be performed right after a successful transmission. If |
@@ -481,7 +481,7 @@ solution for a couple of reasons: | |||
481 | - stats_timer: To calculate the Socket CAN core statistics | 481 | - stats_timer: To calculate the Socket CAN core statistics |
482 | (e.g. current/maximum frames per second) this 1 second timer is | 482 | (e.g. current/maximum frames per second) this 1 second timer is |
483 | invoked at can.ko module start time by default. This timer can be | 483 | invoked at can.ko module start time by default. This timer can be |
484 | disabled by using stattimer=0 on the module comandline. | 484 | disabled by using stattimer=0 on the module commandline. |
485 | 485 | ||
486 | - debug: (removed since SocketCAN SVN r546) | 486 | - debug: (removed since SocketCAN SVN r546) |
487 | 487 | ||
diff --git a/Documentation/networking/dm9000.txt b/Documentation/networking/dm9000.txt new file mode 100644 index 000000000000..65df3dea5561 --- /dev/null +++ b/Documentation/networking/dm9000.txt | |||
@@ -0,0 +1,167 @@ | |||
1 | DM9000 Network driver | ||
2 | ===================== | ||
3 | |||
4 | Copyright 2008 Simtec Electronics, | ||
5 | Ben Dooks <ben@simtec.co.uk> <ben-linux@fluff.org> | ||
6 | |||
7 | |||
8 | Introduction | ||
9 | ------------ | ||
10 | |||
11 | This file describes how to use the DM9000 platform-device based network driver | ||
12 | that is contained in the files drivers/net/dm9000.c and drivers/net/dm9000.h. | ||
13 | |||
14 | The driver supports three DM9000 variants, the DM9000E which is the first chip | ||
15 | supported as well as the newer DM9000A and DM9000B devices. It is currently | ||
16 | maintained and tested by Ben Dooks, who should be CC: to any patches for this | ||
17 | driver. | ||
18 | |||
19 | |||
20 | Defining the platform device | ||
21 | ---------------------------- | ||
22 | |||
23 | The minimum set of resources attached to the platform device are as follows: | ||
24 | |||
25 | 1) The physical address of the address register | ||
26 | 2) The physical address of the data register | ||
27 | 3) The IRQ line the device's interrupt pin is connected to. | ||
28 | |||
29 | These resources should be specified in that order, as the ordering of the | ||
30 | two address regions is important (the driver expects these to be address | ||
31 | and then data). | ||
32 | |||
33 | An example from arch/arm/mach-s3c2410/mach-bast.c is: | ||
34 | |||
35 | static struct resource bast_dm9k_resource[] = { | ||
36 | [0] = { | ||
37 | .start = S3C2410_CS5 + BAST_PA_DM9000, | ||
38 | .end = S3C2410_CS5 + BAST_PA_DM9000 + 3, | ||
39 | .flags = IORESOURCE_MEM, | ||
40 | }, | ||
41 | [1] = { | ||
42 | .start = S3C2410_CS5 + BAST_PA_DM9000 + 0x40, | ||
43 | .end = S3C2410_CS5 + BAST_PA_DM9000 + 0x40 + 0x3f, | ||
44 | .flags = IORESOURCE_MEM, | ||
45 | }, | ||
46 | [2] = { | ||
47 | .start = IRQ_DM9000, | ||
48 | .end = IRQ_DM9000, | ||
49 | .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL, | ||
50 | } | ||
51 | }; | ||
52 | |||
53 | static struct platform_device bast_device_dm9k = { | ||
54 | .name = "dm9000", | ||
55 | .id = 0, | ||
56 | .num_resources = ARRAY_SIZE(bast_dm9k_resource), | ||
57 | .resource = bast_dm9k_resource, | ||
58 | }; | ||
59 | |||
60 | Note the setting of the IRQ trigger flag in bast_dm9k_resource[2].flags, | ||
61 | as this will generate a warning if it is not present. The trigger from | ||
62 | the flags field will be passed to request_irq() when registering the IRQ | ||
63 | handler to ensure that the IRQ is setup correctly. | ||
64 | |||
65 | This shows a typical platform device, without the optional configuration | ||
66 | platform data supplied. The next example uses the same resources, but adds | ||
67 | the optional platform data to pass extra configuration data: | ||
68 | |||
69 | static struct dm9000_plat_data bast_dm9k_platdata = { | ||
70 | .flags = DM9000_PLATF_16BITONLY, | ||
71 | }; | ||
72 | |||
73 | static struct platform_device bast_device_dm9k = { | ||
74 | .name = "dm9000", | ||
75 | .id = 0, | ||
76 | .num_resources = ARRAY_SIZE(bast_dm9k_resource), | ||
77 | .resource = bast_dm9k_resource, | ||
78 | .dev = { | ||
79 | .platform_data = &bast_dm9k_platdata, | ||
80 | } | ||
81 | }; | ||
82 | |||
83 | The platform data is defined in include/linux/dm9000.h and described below. | ||
84 | |||
85 | |||
86 | Platform data | ||
87 | ------------- | ||
88 | |||
89 | Extra platform data for the DM9000 can describe the IO bus width to the | ||
90 | device, whether or not an external PHY is attached to the device and | ||
91 | the availability of an external configuration EEPROM. | ||
92 | |||
93 | The flags for the platform data .flags field are as follows: | ||
94 | |||
95 | DM9000_PLATF_8BITONLY | ||
96 | |||
97 | The IO should be done with 8bit operations. | ||
98 | |||
99 | DM9000_PLATF_16BITONLY | ||
100 | |||
101 | The IO should be done with 16bit operations. | ||
102 | |||
103 | DM9000_PLATF_32BITONLY | ||
104 | |||
105 | The IO should be done with 32bit operations. | ||
106 | |||
107 | DM9000_PLATF_EXT_PHY | ||
108 | |||
109 | The chip is connected to an external PHY. | ||
110 | |||
111 | DM9000_PLATF_NO_EEPROM | ||
112 | |||
113 | This can be used to signify that the board does not have an | ||
114 | EEPROM, or that the EEPROM should be hidden from the user. | ||
115 | |||
116 | DM9000_PLATF_SIMPLE_PHY | ||
117 | |||
118 | Switch to using the simpler PHY polling method which does not | ||
119 | try and read the MII PHY state regularly. This is only available | ||
120 | when using the internal PHY. See the section on link state polling | ||
121 | for more information. | ||
122 | |||
123 | The config symbol DM9000_FORCE_SIMPLE_PHY_POLL, Kconfig entry | ||
124 | "Force simple NSR based PHY polling" allows this flag to be | ||
125 | forced on at build time. | ||
126 | |||
127 | |||
128 | PHY Link state polling | ||
129 | ---------------------- | ||
130 | |||
131 | The driver keeps track of the link state and informs the network core | ||
132 | about link (carrier) availablilty. This is managed by several methods | ||
133 | depending on the version of the chip and on which PHY is being used. | ||
134 | |||
135 | For the internal PHY, the original (and currently default) method is | ||
136 | to read the MII state, either when the status changes if we have the | ||
137 | necessary interrupt support in the chip or every two seconds via a | ||
138 | periodic timer. | ||
139 | |||
140 | To reduce the overhead for the internal PHY, there is now the option | ||
141 | of using the DM9000_FORCE_SIMPLE_PHY_POLL config, or DM9000_PLATF_SIMPLE_PHY | ||
142 | platform data option to read the summary information without the | ||
143 | expensive MII accesses. This method is faster, but does not print | ||
144 | as much information. | ||
145 | |||
146 | When using an external PHY, the driver currently has to poll the MII | ||
147 | link status as there is no method for getting an interrupt on link change. | ||
148 | |||
149 | |||
150 | DM9000A / DM9000B | ||
151 | ----------------- | ||
152 | |||
153 | These chips are functionally similar to the DM9000E and are supported easily | ||
154 | by the same driver. The features are: | ||
155 | |||
156 | 1) Interrupt on internal PHY state change. This means that the periodic | ||
157 | polling of the PHY status may be disabled on these devices when using | ||
158 | the internal PHY. | ||
159 | |||
160 | 2) TCP/UDP checksum offloading, which the driver does not currently support. | ||
161 | |||
162 | |||
163 | ethtool | ||
164 | ------- | ||
165 | |||
166 | The driver supports the ethtool interface for access to the driver | ||
167 | state information, the PHY state and the EEPROM. | ||
diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt index 61b171cf5313..2df71861e578 100644 --- a/Documentation/networking/e1000.txt +++ b/Documentation/networking/e1000.txt | |||
@@ -513,21 +513,11 @@ Additional Configurations | |||
513 | Intel(R) PRO/1000 PT Dual Port Server Connection | 513 | Intel(R) PRO/1000 PT Dual Port Server Connection |
514 | Intel(R) PRO/1000 PT Dual Port Server Adapter | 514 | Intel(R) PRO/1000 PT Dual Port Server Adapter |
515 | Intel(R) PRO/1000 PF Dual Port Server Adapter | 515 | Intel(R) PRO/1000 PF Dual Port Server Adapter |
516 | Intel(R) PRO/1000 PT Quad Port Server Adapter | 516 | Intel(R) PRO/1000 PT Quad Port Server Adapter |
517 | 517 | ||
518 | NAPI | 518 | NAPI |
519 | ---- | 519 | ---- |
520 | NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled | 520 | NAPI (Rx polling mode) is enabled in the e1000 driver. |
521 | or disabled based on the configuration of the kernel. To override | ||
522 | the default, use the following compile-time flags. | ||
523 | |||
524 | To enable NAPI, compile the driver module, passing in a configuration option: | ||
525 | |||
526 | make CFLAGS_EXTRA=-DE1000_NAPI install | ||
527 | |||
528 | To disable NAPI, compile the driver module, passing in a configuration option: | ||
529 | |||
530 | make CFLAGS_EXTRA=-DE1000_NO_NAPI install | ||
531 | 521 | ||
532 | See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI. | 522 | See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI. |
533 | 523 | ||
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 946b66e1b652..d84932650fd3 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt | |||
@@ -551,8 +551,9 @@ icmp_echo_ignore_broadcasts - BOOLEAN | |||
551 | icmp_ratelimit - INTEGER | 551 | icmp_ratelimit - INTEGER |
552 | Limit the maximal rates for sending ICMP packets whose type matches | 552 | Limit the maximal rates for sending ICMP packets whose type matches |
553 | icmp_ratemask (see below) to specific targets. | 553 | icmp_ratemask (see below) to specific targets. |
554 | 0 to disable any limiting, otherwise the maximal rate in jiffies(1) | 554 | 0 to disable any limiting, |
555 | Default: 100 | 555 | otherwise the minimal space between responses in milliseconds. |
556 | Default: 1000 | ||
556 | 557 | ||
557 | icmp_ratemask - INTEGER | 558 | icmp_ratemask - INTEGER |
558 | Mask made of ICMP types for which rates are being limited. | 559 | Mask made of ICMP types for which rates are being limited. |
@@ -1023,11 +1024,23 @@ max_addresses - INTEGER | |||
1023 | autoconfigured addresses. | 1024 | autoconfigured addresses. |
1024 | Default: 16 | 1025 | Default: 16 |
1025 | 1026 | ||
1027 | disable_ipv6 - BOOLEAN | ||
1028 | Disable IPv6 operation. | ||
1029 | Default: FALSE (enable IPv6 operation) | ||
1030 | |||
1031 | accept_dad - INTEGER | ||
1032 | Whether to accept DAD (Duplicate Address Detection). | ||
1033 | 0: Disable DAD | ||
1034 | 1: Enable DAD (default) | ||
1035 | 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate | ||
1036 | link-local address has been found. | ||
1037 | |||
1026 | icmp/*: | 1038 | icmp/*: |
1027 | ratelimit - INTEGER | 1039 | ratelimit - INTEGER |
1028 | Limit the maximal rates for sending ICMPv6 packets. | 1040 | Limit the maximal rates for sending ICMPv6 packets. |
1029 | 0 to disable any limiting, otherwise the maximal rate in jiffies(1) | 1041 | 0 to disable any limiting, |
1030 | Default: 100 | 1042 | otherwise the minimal space between responses in milliseconds. |
1043 | Default: 1000 | ||
1031 | 1044 | ||
1032 | 1045 | ||
1033 | IPv6 Update by: | 1046 | IPv6 Update by: |
diff --git a/Documentation/networking/ixgb.txt b/Documentation/networking/ixgb.txt index 7c98277777eb..a0d0ffb5e584 100644 --- a/Documentation/networking/ixgb.txt +++ b/Documentation/networking/ixgb.txt | |||
@@ -1,7 +1,7 @@ | |||
1 | Linux* Base Driver for the Intel(R) PRO/10GbE Family of Adapters | 1 | Linux Base Driver for 10 Gigabit Intel(R) Network Connection |
2 | ================================================================ | 2 | ============================================================= |
3 | 3 | ||
4 | November 17, 2004 | 4 | October 9, 2007 |
5 | 5 | ||
6 | 6 | ||
7 | Contents | 7 | Contents |
@@ -9,94 +9,151 @@ Contents | |||
9 | 9 | ||
10 | - In This Release | 10 | - In This Release |
11 | - Identifying Your Adapter | 11 | - Identifying Your Adapter |
12 | - Building and Installation | ||
12 | - Command Line Parameters | 13 | - Command Line Parameters |
13 | - Improving Performance | 14 | - Improving Performance |
15 | - Additional Configurations | ||
16 | - Known Issues/Troubleshooting | ||
14 | - Support | 17 | - Support |
15 | 18 | ||
16 | 19 | ||
20 | |||
17 | In This Release | 21 | In This Release |
18 | =============== | 22 | =============== |
19 | 23 | ||
20 | This file describes the Linux* Base Driver for the Intel(R) PRO/10GbE Family | 24 | This file describes the ixgb Linux Base Driver for the 10 Gigabit Intel(R) |
21 | of Adapters, version 1.0.x. | 25 | Network Connection. This driver includes support for Itanium(R)2-based |
26 | systems. | ||
27 | |||
28 | For questions related to hardware requirements, refer to the documentation | ||
29 | supplied with your 10 Gigabit adapter. All hardware requirements listed apply | ||
30 | to use with Linux. | ||
31 | |||
32 | The following features are available in this kernel: | ||
33 | - Native VLANs | ||
34 | - Channel Bonding (teaming) | ||
35 | - SNMP | ||
36 | |||
37 | Channel Bonding documentation can be found in the Linux kernel source: | ||
38 | /Documentation/networking/bonding.txt | ||
39 | |||
40 | The driver information previously displayed in the /proc filesystem is not | ||
41 | supported in this release. Alternatively, you can use ethtool (version 1.6 | ||
42 | or later), lspci, and ifconfig to obtain the same information. | ||
43 | |||
44 | Instructions on updating ethtool can be found in the section "Additional | ||
45 | Configurations" later in this document. | ||
22 | 46 | ||
23 | For questions related to hardware requirements, refer to the documentation | ||
24 | supplied with your Intel PRO/10GbE adapter. All hardware requirements listed | ||
25 | apply to use with Linux. | ||
26 | 47 | ||
27 | Identifying Your Adapter | 48 | Identifying Your Adapter |
28 | ======================== | 49 | ======================== |
29 | 50 | ||
30 | To verify your Intel adapter is supported, find the board ID number on the | 51 | The following Intel network adapters are compatible with the drivers in this |
31 | adapter. Look for a label that has a barcode and a number in the format | 52 | release: |
32 | A12345-001. | 53 | |
54 | Controller Adapter Name Physical Layer | ||
55 | ---------- ------------ -------------- | ||
56 | 82597EX Intel(R) PRO/10GbE LR/SR/CX4 10G Base-LR (1310 nm optical fiber) | ||
57 | Server Adapters 10G Base-SR (850 nm optical fiber) | ||
58 | 10G Base-CX4(twin-axial copper cabling) | ||
59 | |||
60 | For more information on how to identify your adapter, go to the Adapter & | ||
61 | Driver ID Guide at: | ||
62 | |||
63 | http://support.intel.com/support/network/sb/CS-012904.htm | ||
64 | |||
65 | |||
66 | Building and Installation | ||
67 | ========================= | ||
68 | |||
69 | select m for "Intel(R) PRO/10GbE support" located at: | ||
70 | Location: | ||
71 | -> Device Drivers | ||
72 | -> Network device support (NETDEVICES [=y]) | ||
73 | -> Ethernet (10000 Mbit) (NETDEV_10000 [=y]) | ||
74 | 1. make modules && make modules_install | ||
75 | |||
76 | 2. Load the module: | ||
77 | |||
78 | Â Â Â Â modprobe ixgb <parameter>=<value> | ||
79 | |||
80 | The insmod command can be used if the full | ||
81 | path to the driver module is specified. For example: | ||
82 | |||
83 | insmod /lib/modules/<KERNEL VERSION>/kernel/drivers/net/ixgb/ixgb.ko | ||
84 | |||
85 | With 2.6 based kernels also make sure that older ixgb drivers are | ||
86 | removed from the kernel, before loading the new module: | ||
33 | 87 | ||
34 | Use the above information and the Adapter & Driver ID Guide at: | 88 | rmmod ixgb; modprobe ixgb |
35 | 89 | ||
36 | http://support.intel.com/support/network/adapter/pro100/21397.htm | 90 | 3. Assign an IP address to the interface by entering the following, where |
91 | x is the interface number: | ||
37 | 92 | ||
38 | For the latest Intel network drivers for Linux, go to: | 93 | ifconfig ethx <IP_address> |
94 | |||
95 | 4. Verify that the interface works. Enter the following, where <IP_address> | ||
96 | is the IP address for another machine on the same subnet as the interface | ||
97 | that is being tested: | ||
98 | |||
99 | ping <IP_address> | ||
39 | 100 | ||
40 | http://downloadfinder.intel.com/scripts-df/support_intel.asp | ||
41 | 101 | ||
42 | Command Line Parameters | 102 | Command Line Parameters |
43 | ======================= | 103 | ======================= |
44 | 104 | ||
45 | If the driver is built as a module, the following optional parameters are | 105 | If the driver is built as a module, the following optional parameters are |
46 | used by entering them on the command line with the modprobe or insmod command | 106 | used by entering them on the command line with the modprobe command using |
47 | using this syntax: | 107 | this syntax: |
48 | 108 | ||
49 | modprobe ixgb [<option>=<VAL1>,<VAL2>,...] | 109 | modprobe ixgb [<option>=<VAL1>,<VAL2>,...] |
50 | 110 | ||
51 | insmod ixgb [<option>=<VAL1>,<VAL2>,...] | 111 | For example, with two 10GbE PCI adapters, entering: |
52 | 112 | ||
53 | For example, with two PRO/10GbE PCI adapters, entering: | 113 | modprobe ixgb TxDescriptors=80,128 |
54 | 114 | ||
55 | insmod ixgb TxDescriptors=80,128 | 115 | loads the ixgb driver with 80 TX resources for the first adapter and 128 TX |
56 | |||
57 | loads the ixgb driver with 80 TX resources for the first adapter and 128 TX | ||
58 | resources for the second adapter. | 116 | resources for the second adapter. |
59 | 117 | ||
60 | The default value for each parameter is generally the recommended setting, | 118 | The default value for each parameter is generally the recommended setting, |
61 | unless otherwise noted. Also, if the driver is statically built into the | 119 | unless otherwise noted. |
62 | kernel, the driver is loaded with the default values for all the parameters. | ||
63 | Ethtool can be used to change some of the parameters at runtime. | ||
64 | 120 | ||
65 | FlowControl | 121 | FlowControl |
66 | Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx) | 122 | Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx) |
67 | Default: Read from the EEPROM | 123 | Default: Read from the EEPROM |
68 | If EEPROM is not detected, default is 3 | 124 | If EEPROM is not detected, default is 1 |
69 | This parameter controls the automatic generation(Tx) and response(Rx) to | 125 | This parameter controls the automatic generation(Tx) and response(Rx) to |
70 | Ethernet PAUSE frames. | 126 | Ethernet PAUSE frames. There are hardware bugs associated with enabling |
127 | Tx flow control so beware. | ||
71 | 128 | ||
72 | RxDescriptors | 129 | RxDescriptors |
73 | Valid Range: 64-512 | 130 | Valid Range: 64-512 |
74 | Default Value: 512 | 131 | Default Value: 512 |
75 | This value is the number of receive descriptors allocated by the driver. | 132 | This value is the number of receive descriptors allocated by the driver. |
76 | Increasing this value allows the driver to buffer more incoming packets. | 133 | Increasing this value allows the driver to buffer more incoming packets. |
77 | Each descriptor is 16 bytes. A receive buffer is also allocated for | 134 | Each descriptor is 16 bytes. A receive buffer is also allocated for |
78 | each descriptor and can be either 2048, 4056, 8192, or 16384 bytes, | 135 | each descriptor and can be either 2048, 4056, 8192, or 16384 bytes, |
79 | depending on the MTU setting. When the MTU size is 1500 or less, the | 136 | depending on the MTU setting. When the MTU size is 1500 or less, the |
80 | receive buffer size is 2048 bytes. When the MTU is greater than 1500 the | 137 | receive buffer size is 2048 bytes. When the MTU is greater than 1500 the |
81 | receive buffer size will be either 4056, 8192, or 16384 bytes. The | 138 | receive buffer size will be either 4056, 8192, or 16384 bytes. The |
82 | maximum MTU size is 16114. | 139 | maximum MTU size is 16114. |
83 | 140 | ||
84 | RxIntDelay | 141 | RxIntDelay |
85 | Valid Range: 0-65535 (0=off) | 142 | Valid Range: 0-65535 (0=off) |
86 | Default Value: 6 | 143 | Default Value: 72 |
87 | This value delays the generation of receive interrupts in units of | 144 | This value delays the generation of receive interrupts in units of |
88 | 0.8192 microseconds. Receive interrupt reduction can improve CPU | 145 | 0.8192 microseconds. Receive interrupt reduction can improve CPU |
89 | efficiency if properly tuned for specific network traffic. Increasing | 146 | efficiency if properly tuned for specific network traffic. Increasing |
90 | this value adds extra latency to frame reception and can end up | 147 | this value adds extra latency to frame reception and can end up |
91 | decreasing the throughput of TCP traffic. If the system is reporting | 148 | decreasing the throughput of TCP traffic. If the system is reporting |
92 | dropped receives, this value may be set too high, causing the driver to | 149 | dropped receives, this value may be set too high, causing the driver to |
93 | run out of available receive descriptors. | 150 | run out of available receive descriptors. |
94 | 151 | ||
95 | TxDescriptors | 152 | TxDescriptors |
96 | Valid Range: 64-4096 | 153 | Valid Range: 64-4096 |
97 | Default Value: 256 | 154 | Default Value: 256 |
98 | This value is the number of transmit descriptors allocated by the driver. | 155 | This value is the number of transmit descriptors allocated by the driver. |
99 | Increasing this value allows the driver to queue more transmits. Each | 156 | Increasing this value allows the driver to queue more transmits. Each |
100 | descriptor is 16 bytes. | 157 | descriptor is 16 bytes. |
101 | 158 | ||
102 | XsumRX | 159 | XsumRX |
@@ -105,51 +162,49 @@ Default Value: 1 | |||
105 | A value of '1' indicates that the driver should enable IP checksum | 162 | A value of '1' indicates that the driver should enable IP checksum |
106 | offload for received packets (both UDP and TCP) to the adapter hardware. | 163 | offload for received packets (both UDP and TCP) to the adapter hardware. |
107 | 164 | ||
108 | XsumTX | ||
109 | Valid Range: 0-1 | ||
110 | Default Value: 1 | ||
111 | A value of '1' indicates that the driver should enable IP checksum | ||
112 | offload for transmitted packets (both UDP and TCP) to the adapter | ||
113 | hardware. | ||
114 | 165 | ||
115 | Improving Performance | 166 | Improving Performance |
116 | ===================== | 167 | ===================== |
117 | 168 | ||
118 | With the Intel PRO/10 GbE adapter, the default Linux configuration will very | 169 | With the 10 Gigabit server adapters, the default Linux configuration will |
119 | likely limit the total available throughput artificially. There is a set of | 170 | very likely limit the total available throughput artificially. There is a set |
120 | things that when applied together increase the ability of Linux to transmit | 171 | of configuration changes that, when applied together, will increase the ability |
121 | and receive data. The following enhancements were originally acquired from | 172 | of Linux to transmit and receive data. The following enhancements were |
122 | settings published at http://www.spec.org/web99 for various submitted results | 173 | originally acquired from settings published at http://www.spec.org/web99/ for |
123 | using Linux. | 174 | various submitted results using Linux. |
124 | 175 | ||
125 | NOTE: These changes are only suggestions, and serve as a starting point for | 176 | NOTE: These changes are only suggestions, and serve as a starting point for |
126 | tuning your network performance. | 177 | tuning your network performance. |
127 | 178 | ||
128 | The changes are made in three major ways, listed in order of greatest effect: | 179 | The changes are made in three major ways, listed in order of greatest effect: |
129 | - Use ifconfig to modify the mtu (maximum transmission unit) and the txqueuelen | 180 | - Use ifconfig to modify the mtu (maximum transmission unit) and the txqueuelen |
130 | parameter. | 181 | parameter. |
131 | - Use sysctl to modify /proc parameters (essentially kernel tuning) | 182 | - Use sysctl to modify /proc parameters (essentially kernel tuning) |
132 | - Use setpci to modify the MMRBC field in PCI-X configuration space to increase | 183 | - Use setpci to modify the MMRBC field in PCI-X configuration space to increase |
133 | transmit burst lengths on the bus. | 184 | transmit burst lengths on the bus. |
134 | 185 | ||
135 | NOTE: setpci modifies the adapter's configuration registers to allow it to read | 186 | NOTE: setpci modifies the adapter's configuration registers to allow it to read |
136 | up to 4k bytes at a time (for transmits). However, for some systems the | 187 | up to 4k bytes at a time (for transmits). However, for some systems the |
137 | behavior after modifying this register may be undefined (possibly errors of some | 188 | behavior after modifying this register may be undefined (possibly errors of |
138 | kind). A power-cycle, hard reset or explicitly setting the e6 register back to | 189 | some kind). A power-cycle, hard reset or explicitly setting the e6 register |
139 | 22 (setpci -d 8086:1048 e6.b=22) may be required to get back to a stable | 190 | back to 22 (setpci -d 8086:1a48 e6.b=22) may be required to get back to a |
140 | configuration. | 191 | stable configuration. |
141 | 192 | ||
142 | - COPY these lines and paste them into ixgb_perf.sh: | 193 | - COPY these lines and paste them into ixgb_perf.sh: |
143 | #!/bin/bash | 194 | #!/bin/bash |
144 | echo "configuring network performance , edit this file to change the interface" | 195 | echo "configuring network performance , edit this file to change the interface |
196 | or device ID of 10GbE card" | ||
145 | # set mmrbc to 4k reads, modify only Intel 10GbE device IDs | 197 | # set mmrbc to 4k reads, modify only Intel 10GbE device IDs |
146 | setpci -d 8086:1048 e6.b=2e | 198 | # replace 1a48 with appropriate 10GbE device's ID installed on the system, |
147 | # set the MTU (max transmission unit) - it requires your switch and clients to change too! | 199 | # if needed. |
200 | setpci -d 8086:1a48 e6.b=2e | ||
201 | # set the MTU (max transmission unit) - it requires your switch and clients | ||
202 | # to change as well. | ||
148 | # set the txqueuelen | 203 | # set the txqueuelen |
149 | # your ixgb adapter should be loaded as eth1 for this to work, change if needed | 204 | # your ixgb adapter should be loaded as eth1 for this to work, change if needed |
150 | ifconfig eth1 mtu 9000 txqueuelen 1000 up | 205 | ifconfig eth1 mtu 9000 txqueuelen 1000 up |
151 | # call the sysctl utility to modify /proc/sys entries | 206 | # call the sysctl utility to modify /proc/sys entries |
152 | sysctl -p ./sysctl_ixgb.conf | 207 | sysctl -p ./sysctl_ixgb.conf |
153 | - END ixgb_perf.sh | 208 | - END ixgb_perf.sh |
154 | 209 | ||
155 | - COPY these lines and paste them into sysctl_ixgb.conf: | 210 | - COPY these lines and paste them into sysctl_ixgb.conf: |
@@ -159,54 +214,220 @@ sysctl -p ./sysctl_ixgb.conf | |||
159 | # several network benchmark tests, your mileage may vary | 214 | # several network benchmark tests, your mileage may vary |
160 | 215 | ||
161 | ### IPV4 specific settings | 216 | ### IPV4 specific settings |
162 | net.ipv4.tcp_timestamps = 0 # turns TCP timestamp support off, default 1, reduces CPU use | 217 | # turn TCP timestamp support off, default 1, reduces CPU use |
163 | net.ipv4.tcp_sack = 0 # turn SACK support off, default on | 218 | net.ipv4.tcp_timestamps = 0 |
164 | # on systems with a VERY fast bus -> memory interface this is the big gainer | 219 | # turn SACK support off, default on |
165 | net.ipv4.tcp_rmem = 10000000 10000000 10000000 # sets min/default/max TCP read buffer, default 4096 87380 174760 | 220 | # on systems with a VERY fast bus -> memory interface this is the big gainer |
166 | net.ipv4.tcp_wmem = 10000000 10000000 10000000 # sets min/pressure/max TCP write buffer, default 4096 16384 131072 | 221 | net.ipv4.tcp_sack = 0 |
167 | net.ipv4.tcp_mem = 10000000 10000000 10000000 # sets min/pressure/max TCP buffer space, default 31744 32256 32768 | 222 | # set min/default/max TCP read buffer, default 4096 87380 174760 |
223 | net.ipv4.tcp_rmem = 10000000 10000000 10000000 | ||
224 | # set min/pressure/max TCP write buffer, default 4096 16384 131072 | ||
225 | net.ipv4.tcp_wmem = 10000000 10000000 10000000 | ||
226 | # set min/pressure/max TCP buffer space, default 31744 32256 32768 | ||
227 | net.ipv4.tcp_mem = 10000000 10000000 10000000 | ||
168 | 228 | ||
169 | ### CORE settings (mostly for socket and UDP effect) | 229 | ### CORE settings (mostly for socket and UDP effect) |
170 | net.core.rmem_max = 524287 # maximum receive socket buffer size, default 131071 | 230 | # set maximum receive socket buffer size, default 131071 |
171 | net.core.wmem_max = 524287 # maximum send socket buffer size, default 131071 | 231 | net.core.rmem_max = 524287 |
172 | net.core.rmem_default = 524287 # default receive socket buffer size, default 65535 | 232 | # set maximum send socket buffer size, default 131071 |
173 | net.core.wmem_default = 524287 # default send socket buffer size, default 65535 | 233 | net.core.wmem_max = 524287 |
174 | net.core.optmem_max = 524287 # maximum amount of option memory buffers, default 10240 | 234 | # set default receive socket buffer size, default 65535 |
175 | net.core.netdev_max_backlog = 300000 # number of unprocessed input packets before kernel starts dropping them, default 300 | 235 | net.core.rmem_default = 524287 |
236 | # set default send socket buffer size, default 65535 | ||
237 | net.core.wmem_default = 524287 | ||
238 | # set maximum amount of option memory buffers, default 10240 | ||
239 | net.core.optmem_max = 524287 | ||
240 | # set number of unprocessed input packets before kernel starts dropping them; default 300 | ||
241 | net.core.netdev_max_backlog = 300000 | ||
176 | - END sysctl_ixgb.conf | 242 | - END sysctl_ixgb.conf |
177 | 243 | ||
178 | Edit the ixgb_perf.sh script if necessary to change eth1 to whatever interface | 244 | Edit the ixgb_perf.sh script if necessary to change eth1 to whatever interface |
179 | your ixgb driver is using. | 245 | your ixgb driver is using and/or replace '1a48' with appropriate 10GbE device's |
246 | ID installed on the system. | ||
180 | 247 | ||
181 | NOTE: Unless these scripts are added to the boot process, these changes will | 248 | NOTE: Unless these scripts are added to the boot process, these changes will |
182 | only last only until the next system reboot. | 249 | only last only until the next system reboot. |
183 | 250 | ||
184 | 251 | ||
185 | Resolving Slow UDP Traffic | 252 | Resolving Slow UDP Traffic |
186 | -------------------------- | 253 | -------------------------- |
254 | If your server does not seem to be able to receive UDP traffic as fast as it | ||
255 | can receive TCP traffic, it could be because Linux, by default, does not set | ||
256 | the network stack buffers as large as they need to be to support high UDP | ||
257 | transfer rates. One way to alleviate this problem is to allow more memory to | ||
258 | be used by the IP stack to store incoming data. | ||
187 | 259 | ||
188 | If your server does not seem to be able to receive UDP traffic as fast as it | 260 | For instance, use the commands: |
189 | can receive TCP traffic, it could be because Linux, by default, does not set | ||
190 | the network stack buffers as large as they need to be to support high UDP | ||
191 | transfer rates. One way to alleviate this problem is to allow more memory to | ||
192 | be used by the IP stack to store incoming data. | ||
193 | |||
194 | For instance, use the commands: | ||
195 | sysctl -w net.core.rmem_max=262143 | 261 | sysctl -w net.core.rmem_max=262143 |
196 | and | 262 | and |
197 | sysctl -w net.core.rmem_default=262143 | 263 | sysctl -w net.core.rmem_default=262143 |
198 | to increase the read buffer memory max and default to 262143 (256k - 1) from | 264 | to increase the read buffer memory max and default to 262143 (256k - 1) from |
199 | defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables | 265 | defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables |
200 | will increase the amount of memory used by the network stack for receives, and | 266 | will increase the amount of memory used by the network stack for receives, and |
201 | can be increased significantly more if necessary for your application. | 267 | can be increased significantly more if necessary for your application. |
202 | 268 | ||
269 | |||
270 | Additional Configurations | ||
271 | ========================= | ||
272 | |||
273 | Configuring the Driver on Different Distributions | ||
274 | ------------------------------------------------- | ||
275 | Configuring a network driver to load properly when the system is started is | ||
276 | distribution dependent. Typically, the configuration process involves adding | ||
277 | an alias line to /etc/modprobe.conf as well as editing other system startup | ||
278 | scripts and/or configuration files. Many popular Linux distributions ship | ||
279 | with tools to make these changes for you. To learn the proper way to | ||
280 | configure a network device for your system, refer to your distribution | ||
281 | documentation. If during this process you are asked for the driver or module | ||
282 | name, the name for the Linux Base Driver for the Intel 10GbE Family of | ||
283 | Adapters is ixgb. | ||
284 | |||
285 | Viewing Link Messages | ||
286 | --------------------- | ||
287 | Link messages will not be displayed to the console if the distribution is | ||
288 | restricting system messages. In order to see network driver link messages on | ||
289 | your console, set dmesg to eight by entering the following: | ||
290 | |||
291 | dmesg -n 8 | ||
292 | |||
293 | NOTE: This setting is not saved across reboots. | ||
294 | |||
295 | |||
296 | Jumbo Frames | ||
297 | ------------ | ||
298 | The driver supports Jumbo Frames for all adapters. Jumbo Frames support is | ||
299 | enabled by changing the MTU to a value larger than the default of 1500. | ||
300 | The maximum value for the MTU is 16114. Use the ifconfig command to | ||
301 | increase the MTU size. For example: | ||
302 | |||
303 | ifconfig ethx mtu 9000 up | ||
304 | |||
305 | The maximum MTU setting for Jumbo Frames is 16114. This value coincides | ||
306 | with the maximum Jumbo Frames size of 16128. | ||
307 | |||
308 | |||
309 | Ethtool | ||
310 | ------- | ||
311 | The driver utilizes the ethtool interface for driver configuration and | ||
312 | diagnostics, as well as displaying statistical information. Ethtool | ||
313 | version 1.6 or later is required for this functionality. | ||
314 | |||
315 | The latest release of ethtool can be found from | ||
316 | http://sourceforge.net/projects/gkernel | ||
317 | |||
318 | NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support | ||
319 | for a more complete ethtool feature set can be enabled by upgrading | ||
320 | to the latest version. | ||
321 | |||
322 | |||
323 | NAPI | ||
324 | ---- | ||
325 | |||
326 | NAPI (Rx polling mode) is supported in the ixgb driver. NAPI is enabled | ||
327 | or disabled based on the configuration of the kernel. see CONFIG_IXGB_NAPI | ||
328 | |||
329 | See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI. | ||
330 | |||
331 | |||
332 | Known Issues/Troubleshooting | ||
333 | ============================ | ||
334 | |||
335 | NOTE: After installing the driver, if your Intel Network Connection is not | ||
336 | working, verify in the "In This Release" section of the readme that you have | ||
337 | installed the correct driver. | ||
338 | |||
339 | Intel(R) PRO/10GbE CX4 Server Adapter Cable Interoperability Issue with | ||
340 | Fujitsu XENPAK Module in SmartBits Chassis | ||
341 | --------------------------------------------------------------------- | ||
342 | Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 | ||
343 | Server adapter is connected to a Fujitsu XENPAK CX4 module in a SmartBits | ||
344 | chassis using 15 m/24AWG cable assemblies manufactured by Fujitsu or Leoni. | ||
345 | The CRC errors may be received either by the Intel(R) PRO/10GbE CX4 | ||
346 | Server adapter or the SmartBits. If this situation occurs using a different | ||
347 | cable assembly may resolve the issue. | ||
348 | |||
349 | CX4 Server Adapter Cable Interoperability Issues with HP Procurve 3400cl | ||
350 | Switch Port | ||
351 | ------------------------------------------------------------------------ | ||
352 | Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 Server | ||
353 | adapter is connected to an HP Procurve 3400cl switch port using short cables | ||
354 | (1 m or shorter). If this situation occurs, using a longer cable may resolve | ||
355 | the issue. | ||
356 | |||
357 | Excessive CRC errors may be observed using Fujitsu 24AWG cable assemblies that | ||
358 | Are 10 m or longer or where using a Leoni 15 m/24AWG cable assembly. The CRC | ||
359 | errors may be received either by the CX4 Server adapter or at the switch. If | ||
360 | this situation occurs, using a different cable assembly may resolve the issue. | ||
361 | |||
362 | |||
363 | Jumbo Frames System Requirement | ||
364 | ------------------------------- | ||
365 | Memory allocation failures have been observed on Linux systems with 64 MB | ||
366 | of RAM or less that are running Jumbo Frames. If you are using Jumbo | ||
367 | Frames, your system may require more than the advertised minimum | ||
368 | requirement of 64 MB of system memory. | ||
369 | |||
370 | |||
371 | Performance Degradation with Jumbo Frames | ||
372 | ----------------------------------------- | ||
373 | Degradation in throughput performance may be observed in some Jumbo frames | ||
374 | environments. If this is observed, increasing the application's socket buffer | ||
375 | size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help. | ||
376 | See the specific application manual and /usr/src/linux*/Documentation/ | ||
377 | networking/ip-sysctl.txt for more details. | ||
378 | |||
379 | |||
380 | Allocating Rx Buffers when Using Jumbo Frames | ||
381 | --------------------------------------------- | ||
382 | Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if | ||
383 | the available memory is heavily fragmented. This issue may be seen with PCI-X | ||
384 | adapters or with packet split disabled. This can be reduced or eliminated | ||
385 | by changing the amount of available memory for receive buffer allocation, by | ||
386 | increasing /proc/sys/vm/min_free_kbytes. | ||
387 | |||
388 | |||
389 | Multiple Interfaces on Same Ethernet Broadcast Network | ||
390 | ------------------------------------------------------ | ||
391 | Due to the default ARP behavior on Linux, it is not possible to have | ||
392 | one system on two IP networks in the same Ethernet broadcast domain | ||
393 | (non-partitioned switch) behave as expected. All Ethernet interfaces | ||
394 | will respond to IP traffic for any IP address assigned to the system. | ||
395 | This results in unbalanced receive traffic. | ||
396 | |||
397 | If you have multiple interfaces in a server, do either of the following: | ||
398 | |||
399 | - Turn on ARP filtering by entering: | ||
400 | echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter | ||
401 | |||
402 | - Install the interfaces in separate broadcast domains - either in | ||
403 | different switches or in a switch partitioned to VLANs. | ||
404 | |||
405 | |||
406 | UDP Stress Test Dropped Packet Issue | ||
407 | -------------------------------------- | ||
408 | Under small packets UDP stress test with 10GbE driver, the Linux system | ||
409 | may drop UDP packets due to the fullness of socket buffers. You may want | ||
410 | to change the driver's Flow Control variables to the minimum value for | ||
411 | controlling packet reception. | ||
412 | |||
413 | |||
414 | Tx Hangs Possible Under Stress | ||
415 | ------------------------------ | ||
416 | Under stress conditions, if TX hangs occur, turning off TSO | ||
417 | "ethtool -K eth0 tso off" may resolve the problem. | ||
418 | |||
419 | |||
203 | Support | 420 | Support |
204 | ======= | 421 | ======= |
205 | 422 | ||
206 | For general information and support, go to the Intel support website at: | 423 | For general information, go to the Intel support website at: |
207 | 424 | ||
208 | http://support.intel.com | 425 | http://support.intel.com |
209 | 426 | ||
427 | or the Intel Wired Networking project hosted by Sourceforge at: | ||
428 | |||
429 | http://sourceforge.net/projects/e1000 | ||
430 | |||
210 | If an issue is identified with the released source code on the supported | 431 | If an issue is identified with the released source code on the supported |
211 | kernel with a supported adapter, email the specific information related to | 432 | kernel with a supported adapter, email the specific information related |
212 | the issue to linux.nics@intel.com. | 433 | to the issue to e1000-devel@lists.sf.net |
diff --git a/Documentation/networking/mac80211_hwsim/README b/Documentation/networking/mac80211_hwsim/README new file mode 100644 index 000000000000..2ff8ccb8dc37 --- /dev/null +++ b/Documentation/networking/mac80211_hwsim/README | |||
@@ -0,0 +1,67 @@ | |||
1 | mac80211_hwsim - software simulator of 802.11 radio(s) for mac80211 | ||
2 | Copyright (c) 2008, Jouni Malinen <j@w1.fi> | ||
3 | |||
4 | This program is free software; you can redistribute it and/or modify | ||
5 | it under the terms of the GNU General Public License version 2 as | ||
6 | published by the Free Software Foundation. | ||
7 | |||
8 | |||
9 | Introduction | ||
10 | |||
11 | mac80211_hwsim is a Linux kernel module that can be used to simulate | ||
12 | arbitrary number of IEEE 802.11 radios for mac80211. It can be used to | ||
13 | test most of the mac80211 functionality and user space tools (e.g., | ||
14 | hostapd and wpa_supplicant) in a way that matches very closely with | ||
15 | the normal case of using real WLAN hardware. From the mac80211 view | ||
16 | point, mac80211_hwsim is yet another hardware driver, i.e., no changes | ||
17 | to mac80211 are needed to use this testing tool. | ||
18 | |||
19 | The main goal for mac80211_hwsim is to make it easier for developers | ||
20 | to test their code and work with new features to mac80211, hostapd, | ||
21 | and wpa_supplicant. The simulated radios do not have the limitations | ||
22 | of real hardware, so it is easy to generate an arbitrary test setup | ||
23 | and always reproduce the same setup for future tests. In addition, | ||
24 | since all radio operation is simulated, any channel can be used in | ||
25 | tests regardless of regulatory rules. | ||
26 | |||
27 | mac80211_hwsim kernel module has a parameter 'radios' that can be used | ||
28 | to select how many radios are simulated (default 2). This allows | ||
29 | configuration of both very simply setups (e.g., just a single access | ||
30 | point and a station) or large scale tests (multiple access points with | ||
31 | hundreds of stations). | ||
32 | |||
33 | mac80211_hwsim works by tracking the current channel of each virtual | ||
34 | radio and copying all transmitted frames to all other radios that are | ||
35 | currently enabled and on the same channel as the transmitting | ||
36 | radio. Software encryption in mac80211 is used so that the frames are | ||
37 | actually encrypted over the virtual air interface to allow more | ||
38 | complete testing of encryption. | ||
39 | |||
40 | A global monitoring netdev, hwsim#, is created independent of | ||
41 | mac80211. This interface can be used to monitor all transmitted frames | ||
42 | regardless of channel. | ||
43 | |||
44 | |||
45 | Simple example | ||
46 | |||
47 | This example shows how to use mac80211_hwsim to simulate two radios: | ||
48 | one to act as an access point and the other as a station that | ||
49 | associates with the AP. hostapd and wpa_supplicant are used to take | ||
50 | care of WPA2-PSK authentication. In addition, hostapd is also | ||
51 | processing access point side of association. | ||
52 | |||
53 | Please note that the current Linux kernel does not enable AP mode, so a | ||
54 | simple patch is needed to enable AP mode selection: | ||
55 | http://johannes.sipsolutions.net/patches/kernel/all/LATEST/006-allow-ap-vlan-modes.patch | ||
56 | |||
57 | |||
58 | # Build mac80211_hwsim as part of kernel configuration | ||
59 | |||
60 | # Load the module | ||
61 | modprobe mac80211_hwsim | ||
62 | |||
63 | # Run hostapd (AP) for wlan0 | ||
64 | hostapd hostapd.conf | ||
65 | |||
66 | # Run wpa_supplicant (station) for wlan1 | ||
67 | wpa_supplicant -Dwext -iwlan1 -c wpa_supplicant.conf | ||
diff --git a/Documentation/networking/mac80211_hwsim/hostapd.conf b/Documentation/networking/mac80211_hwsim/hostapd.conf new file mode 100644 index 000000000000..08cde7e35f2e --- /dev/null +++ b/Documentation/networking/mac80211_hwsim/hostapd.conf | |||
@@ -0,0 +1,11 @@ | |||
1 | interface=wlan0 | ||
2 | driver=nl80211 | ||
3 | |||
4 | hw_mode=g | ||
5 | channel=1 | ||
6 | ssid=mac80211 test | ||
7 | |||
8 | wpa=2 | ||
9 | wpa_key_mgmt=WPA-PSK | ||
10 | wpa_pairwise=CCMP | ||
11 | wpa_passphrase=12345678 | ||
diff --git a/Documentation/networking/mac80211_hwsim/wpa_supplicant.conf b/Documentation/networking/mac80211_hwsim/wpa_supplicant.conf new file mode 100644 index 000000000000..299128cff035 --- /dev/null +++ b/Documentation/networking/mac80211_hwsim/wpa_supplicant.conf | |||
@@ -0,0 +1,10 @@ | |||
1 | ctrl_interface=/var/run/wpa_supplicant | ||
2 | |||
3 | network={ | ||
4 | ssid="mac80211 test" | ||
5 | psk="12345678" | ||
6 | key_mgmt=WPA-PSK | ||
7 | proto=WPA2 | ||
8 | pairwise=CCMP | ||
9 | group=CCMP | ||
10 | } | ||
diff --git a/Documentation/networking/multiqueue.txt b/Documentation/networking/multiqueue.txt index ea5a42e8f79f..d391ea631141 100644 --- a/Documentation/networking/multiqueue.txt +++ b/Documentation/networking/multiqueue.txt | |||
@@ -3,19 +3,11 @@ | |||
3 | =========================================== | 3 | =========================================== |
4 | 4 | ||
5 | Section 1: Base driver requirements for implementing multiqueue support | 5 | Section 1: Base driver requirements for implementing multiqueue support |
6 | Section 2: Qdisc support for multiqueue devices | ||
7 | Section 3: Brief howto using PRIO or RR for multiqueue devices | ||
8 | |||
9 | 6 | ||
10 | Intro: Kernel support for multiqueue devices | 7 | Intro: Kernel support for multiqueue devices |
11 | --------------------------------------------------------- | 8 | --------------------------------------------------------- |
12 | 9 | ||
13 | Kernel support for multiqueue devices is only an API that is presented to the | 10 | Kernel support for multiqueue devices is always present. |
14 | netdevice layer for base drivers to implement. This feature is part of the | ||
15 | core networking stack, and all network devices will be running on the | ||
16 | multiqueue-aware stack. If a base driver only has one queue, then these | ||
17 | changes are transparent to that driver. | ||
18 | |||
19 | 11 | ||
20 | Section 1: Base driver requirements for implementing multiqueue support | 12 | Section 1: Base driver requirements for implementing multiqueue support |
21 | ----------------------------------------------------------------------- | 13 | ----------------------------------------------------------------------- |
@@ -32,84 +24,4 @@ netif_{start|stop|wake}_subqueue() functions to manage each queue while the | |||
32 | device is still operational. netdev->queue_lock is still used when the device | 24 | device is still operational. netdev->queue_lock is still used when the device |
33 | comes online or when it's completely shut down (unregister_netdev(), etc.). | 25 | comes online or when it's completely shut down (unregister_netdev(), etc.). |
34 | 26 | ||
35 | Finally, the base driver should indicate that it is a multiqueue device. The | ||
36 | feature flag NETIF_F_MULTI_QUEUE should be added to the netdev->features | ||
37 | bitmap on device initialization. Below is an example from e1000: | ||
38 | |||
39 | #ifdef CONFIG_E1000_MQ | ||
40 | if ( (adapter->hw.mac.type == e1000_82571) || | ||
41 | (adapter->hw.mac.type == e1000_82572) || | ||
42 | (adapter->hw.mac.type == e1000_80003es2lan)) | ||
43 | netdev->features |= NETIF_F_MULTI_QUEUE; | ||
44 | #endif | ||
45 | |||
46 | |||
47 | Section 2: Qdisc support for multiqueue devices | ||
48 | ----------------------------------------------- | ||
49 | |||
50 | Currently two qdiscs support multiqueue devices. A new round-robin qdisc, | ||
51 | sch_rr, and sch_prio. The qdisc is responsible for classifying the skb's to | ||
52 | bands and queues, and will store the queue mapping into skb->queue_mapping. | ||
53 | Use this field in the base driver to determine which queue to send the skb | ||
54 | to. | ||
55 | |||
56 | sch_rr has been added for hardware that doesn't want scheduling policies from | ||
57 | software, so it's a straight round-robin qdisc. It uses the same syntax and | ||
58 | classification priomap that sch_prio uses, so it should be intuitive to | ||
59 | configure for people who've used sch_prio. | ||
60 | |||
61 | In order to utilitize the multiqueue features of the qdiscs, the network | ||
62 | device layer needs to enable multiple queue support. This can be done by | ||
63 | selecting NETDEVICES_MULTIQUEUE under Drivers. | ||
64 | |||
65 | The PRIO qdisc naturally plugs into a multiqueue device. If | ||
66 | NETDEVICES_MULTIQUEUE is selected, then on qdisc load, the number of | ||
67 | bands requested is compared to the number of queues on the hardware. If they | ||
68 | are equal, it sets a one-to-one mapping up between the queues and bands. If | ||
69 | they're not equal, it will not load the qdisc. This is the same behavior | ||
70 | for RR. Once the association is made, any skb that is classified will have | ||
71 | skb->queue_mapping set, which will allow the driver to properly queue skb's | ||
72 | to multiple queues. | ||
73 | |||
74 | |||
75 | Section 3: Brief howto using PRIO and RR for multiqueue devices | ||
76 | --------------------------------------------------------------- | ||
77 | |||
78 | The userspace command 'tc,' part of the iproute2 package, is used to configure | ||
79 | qdiscs. To add the PRIO qdisc to your network device, assuming the device is | ||
80 | called eth0, run the following command: | ||
81 | |||
82 | # tc qdisc add dev eth0 root handle 1: prio bands 4 multiqueue | ||
83 | |||
84 | This will create 4 bands, 0 being highest priority, and associate those bands | ||
85 | to the queues on your NIC. Assuming eth0 has 4 Tx queues, the band mapping | ||
86 | would look like: | ||
87 | |||
88 | band 0 => queue 0 | ||
89 | band 1 => queue 1 | ||
90 | band 2 => queue 2 | ||
91 | band 3 => queue 3 | ||
92 | |||
93 | Traffic will begin flowing through each queue if your TOS values are assigning | ||
94 | traffic across the various bands. For example, ssh traffic will always try to | ||
95 | go out band 0 based on TOS -> Linux priority conversion (realtime traffic), | ||
96 | so it will be sent out queue 0. ICMP traffic (pings) fall into the "normal" | ||
97 | traffic classification, which is band 1. Therefore pings will be send out | ||
98 | queue 1 on the NIC. | ||
99 | |||
100 | Note the use of the multiqueue keyword. This is only in versions of iproute2 | ||
101 | that support multiqueue networking devices; if this is omitted when loading | ||
102 | a qdisc onto a multiqueue device, the qdisc will load and operate the same | ||
103 | if it were loaded onto a single-queue device (i.e. - sends all traffic to | ||
104 | queue 0). | ||
105 | |||
106 | Another alternative to multiqueue band allocation can be done by using the | ||
107 | multiqueue option and specify 0 bands. If this is the case, the qdisc will | ||
108 | allocate the number of bands to equal the number of queues that the device | ||
109 | reports, and bring the qdisc online. | ||
110 | |||
111 | The behavior of tc filters remains the same, where it will override TOS priority | ||
112 | classification. | ||
113 | |||
114 | |||
115 | Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com> | 27 | Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com> |
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index db0cd5169581..07c53d596035 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt | |||
@@ -326,7 +326,7 @@ just one call to mmap is needed: | |||
326 | mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); | 326 | mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); |
327 | 327 | ||
328 | If tp_frame_size is a divisor of tp_block_size frames will be | 328 | If tp_frame_size is a divisor of tp_block_size frames will be |
329 | contiguosly spaced by tp_frame_size bytes. If not, each | 329 | contiguously spaced by tp_frame_size bytes. If not, each |
330 | tp_block_size/tp_frame_size frames there will be a gap between | 330 | tp_block_size/tp_frame_size frames there will be a gap between |
331 | the frames. This is because a frame cannot be spawn across two | 331 | the frames. This is because a frame cannot be spawn across two |
332 | blocks. | 332 | blocks. |
diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt index 1e28e2ddb90a..c3d6b4d5d014 100644 --- a/Documentation/networking/s2io.txt +++ b/Documentation/networking/s2io.txt | |||
@@ -52,13 +52,10 @@ d. MSI/MSI-X. Can be enabled on platforms which support this feature | |||
52 | (IA64, Xeon) resulting in noticeable performance improvement(upto 7% | 52 | (IA64, Xeon) resulting in noticeable performance improvement(upto 7% |
53 | on certain platforms). | 53 | on certain platforms). |
54 | 54 | ||
55 | e. NAPI. Compile-time option(CONFIG_S2IO_NAPI) for better Rx interrupt | 55 | e. Statistics. Comprehensive MAC-level and software statistics displayed |
56 | moderation. | ||
57 | |||
58 | f. Statistics. Comprehensive MAC-level and software statistics displayed | ||
59 | using "ethtool -S" option. | 56 | using "ethtool -S" option. |
60 | 57 | ||
61 | g. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings, | 58 | f. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings, |
62 | with multiple steering options. | 59 | with multiple steering options. |
63 | 60 | ||
64 | 4. Command line parameters | 61 | 4. Command line parameters |
diff --git a/Documentation/networking/tc-actions-env-rules.txt b/Documentation/networking/tc-actions-env-rules.txt index 01e716d185f4..dcadf6f88e34 100644 --- a/Documentation/networking/tc-actions-env-rules.txt +++ b/Documentation/networking/tc-actions-env-rules.txt | |||
@@ -4,26 +4,27 @@ The "enviromental" rules for authors of any new tc actions are: | |||
4 | 1) If you stealeth or borroweth any packet thou shalt be branching | 4 | 1) If you stealeth or borroweth any packet thou shalt be branching |
5 | from the righteous path and thou shalt cloneth. | 5 | from the righteous path and thou shalt cloneth. |
6 | 6 | ||
7 | For example if your action queues a packet to be processed later | 7 | For example if your action queues a packet to be processed later, |
8 | or intentionaly branches by redirecting a packet then you need to | 8 | or intentionally branches by redirecting a packet, then you need to |
9 | clone the packet. | 9 | clone the packet. |
10 | |||
10 | There are certain fields in the skb tc_verd that need to be reset so we | 11 | There are certain fields in the skb tc_verd that need to be reset so we |
11 | avoid loops etc. A few are generic enough so much so that skb_act_clone() | 12 | avoid loops, etc. A few are generic enough that skb_act_clone() |
12 | resets them for you. So invoke skb_act_clone() rather than skb_clone() | 13 | resets them for you, so invoke skb_act_clone() rather than skb_clone(). |
13 | 14 | ||
14 | 2) If you munge any packet thou shalt call pskb_expand_head in the case | 15 | 2) If you munge any packet thou shalt call pskb_expand_head in the case |
15 | someone else is referencing the skb. After that you "own" the skb. | 16 | someone else is referencing the skb. After that you "own" the skb. |
16 | You must also tell us if it is ok to munge the packet (TC_OK2MUNGE), | 17 | You must also tell us if it is ok to munge the packet (TC_OK2MUNGE), |
17 | this way any action downstream can stomp on the packet. | 18 | this way any action downstream can stomp on the packet. |
18 | 19 | ||
19 | 3) dropping packets you dont own is a nono. You simply return | 20 | 3) Dropping packets you don't own is a no-no. You simply return |
20 | TC_ACT_SHOT to the caller and they will drop it. | 21 | TC_ACT_SHOT to the caller and they will drop it. |
21 | 22 | ||
22 | The "enviromental" rules for callers of actions (qdiscs etc) are: | 23 | The "enviromental" rules for callers of actions (qdiscs etc) are: |
23 | 24 | ||
24 | *) thou art responsible for freeing anything returned as being | 25 | *) Thou art responsible for freeing anything returned as being |
25 | TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is | 26 | TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is |
26 | returned then all is great and you dont need to do anything. | 27 | returned, then all is great and you don't need to do anything. |
27 | 28 | ||
28 | Post on netdev if something is unclear. | 29 | Post on netdev if something is unclear. |
29 | 30 | ||
diff --git a/Documentation/networking/udplite.txt b/Documentation/networking/udplite.txt index 3870f280280b..855d8da57a23 100644 --- a/Documentation/networking/udplite.txt +++ b/Documentation/networking/udplite.txt | |||
@@ -148,7 +148,7 @@ | |||
148 | getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...); | 148 | getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...); |
149 | 149 | ||
150 | is meaningless (as in TCP). Packets with a zero checksum field are | 150 | is meaningless (as in TCP). Packets with a zero checksum field are |
151 | illegal (cf. RFC 3828, sec. 3.1) will be silently discarded. | 151 | illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded. |
152 | 152 | ||
153 | 4) Fragmentation | 153 | 4) Fragmentation |
154 | 154 | ||
diff --git a/Documentation/nmi_watchdog.txt b/Documentation/nmi_watchdog.txt index 757c729ee42e..90aa4531cb67 100644 --- a/Documentation/nmi_watchdog.txt +++ b/Documentation/nmi_watchdog.txt | |||
@@ -10,7 +10,7 @@ us to generate 'watchdog NMI interrupts'. (NMI: Non Maskable Interrupt | |||
10 | which get executed even if the system is otherwise locked up hard). | 10 | which get executed even if the system is otherwise locked up hard). |
11 | This can be used to debug hard kernel lockups. By executing periodic | 11 | This can be used to debug hard kernel lockups. By executing periodic |
12 | NMI interrupts, the kernel can monitor whether any CPU has locked up, | 12 | NMI interrupts, the kernel can monitor whether any CPU has locked up, |
13 | and print out debugging messages if so. | 13 | and print out debugging messages if so. |
14 | 14 | ||
15 | In order to use the NMI watchdog, you need to have APIC support in your | 15 | In order to use the NMI watchdog, you need to have APIC support in your |
16 | kernel. For SMP kernels, APIC support gets compiled in automatically. For | 16 | kernel. For SMP kernels, APIC support gets compiled in automatically. For |
@@ -22,8 +22,7 @@ CONFIG_X86_UP_IOAPIC is for uniprocessor with an IO-APIC. [Note: certain | |||
22 | kernel debugging options, such as Kernel Stack Meter or Kernel Tracer, | 22 | kernel debugging options, such as Kernel Stack Meter or Kernel Tracer, |
23 | may implicitly disable the NMI watchdog.] | 23 | may implicitly disable the NMI watchdog.] |
24 | 24 | ||
25 | For x86-64, the needed APIC is always compiled in, and the NMI watchdog is | 25 | For x86-64, the needed APIC is always compiled in. |
26 | always enabled with I/O-APIC mode (nmi_watchdog=1). | ||
27 | 26 | ||
28 | Using local APIC (nmi_watchdog=2) needs the first performance register, so | 27 | Using local APIC (nmi_watchdog=2) needs the first performance register, so |
29 | you can't use it for other purposes (such as high precision performance | 28 | you can't use it for other purposes (such as high precision performance |
@@ -63,16 +62,15 @@ when the system is idle), but if your system locks up on anything but the | |||
63 | "hlt", then you are out of luck -- the event will not happen at all and the | 62 | "hlt", then you are out of luck -- the event will not happen at all and the |
64 | watchdog won't trigger. This is a shortcoming of the local APIC watchdog | 63 | watchdog won't trigger. This is a shortcoming of the local APIC watchdog |
65 | -- unfortunately there is no "clock ticks" event that would work all the | 64 | -- unfortunately there is no "clock ticks" event that would work all the |
66 | time. The I/O APIC watchdog is driven externally and has no such shortcoming. | 65 | time. The I/O APIC watchdog is driven externally and has no such shortcoming. |
67 | But its NMI frequency is much higher, resulting in a more significant hit | 66 | But its NMI frequency is much higher, resulting in a more significant hit |
68 | to the overall system performance. | 67 | to the overall system performance. |
69 | 68 | ||
70 | NOTE: starting with 2.4.2-ac18 the NMI-oopser is disabled by default, | 69 | On x86 nmi_watchdog is disabled by default so you have to enable it with |
71 | you have to enable it with a boot time parameter. Prior to 2.4.2-ac18 | 70 | a boot time parameter. |
72 | the NMI-oopser is enabled unconditionally on x86 SMP boxes. | ||
73 | 71 | ||
74 | On x86-64 the NMI oopser is on by default. On 64bit Intel CPUs | 72 | NOTE: In kernels prior to 2.4.2-ac18 the NMI-oopser is enabled unconditionally |
75 | it uses IO-APIC by default and on AMD it uses local APIC. | 73 | on x86 SMP boxes. |
76 | 74 | ||
77 | [ feel free to send bug reports, suggestions and patches to | 75 | [ feel free to send bug reports, suggestions and patches to |
78 | Ingo Molnar <mingo@redhat.com> or the Linux SMP mailing | 76 | Ingo Molnar <mingo@redhat.com> or the Linux SMP mailing |
diff --git a/Documentation/power/00-INDEX b/Documentation/power/00-INDEX index a55d7f1c836d..fb742c213c9e 100644 --- a/Documentation/power/00-INDEX +++ b/Documentation/power/00-INDEX | |||
@@ -1,5 +1,7 @@ | |||
1 | 00-INDEX | 1 | 00-INDEX |
2 | - This file | 2 | - This file |
3 | apm-acpi.txt | ||
4 | - basic info about the APM and ACPI support. | ||
3 | basic-pm-debugging.txt | 5 | basic-pm-debugging.txt |
4 | - Debugging suspend and resume | 6 | - Debugging suspend and resume |
5 | devices.txt | 7 | devices.txt |
@@ -14,8 +16,6 @@ notifiers.txt | |||
14 | - Registering suspend notifiers in device drivers | 16 | - Registering suspend notifiers in device drivers |
15 | pci.txt | 17 | pci.txt |
16 | - How the PCI Subsystem Does Power Management | 18 | - How the PCI Subsystem Does Power Management |
17 | pm.txt | ||
18 | - info on Linux power management support. | ||
19 | pm_qos_interface.txt | 19 | pm_qos_interface.txt |
20 | - info on Linux PM Quality of Service interface | 20 | - info on Linux PM Quality of Service interface |
21 | power_supply_class.txt | 21 | power_supply_class.txt |
diff --git a/Documentation/power/apm-acpi.txt b/Documentation/power/apm-acpi.txt new file mode 100644 index 000000000000..1bd799dc17e8 --- /dev/null +++ b/Documentation/power/apm-acpi.txt | |||
@@ -0,0 +1,32 @@ | |||
1 | APM or ACPI? | ||
2 | ------------ | ||
3 | If you have a relatively recent x86 mobile, desktop, or server system, | ||
4 | odds are it supports either Advanced Power Management (APM) or | ||
5 | Advanced Configuration and Power Interface (ACPI). ACPI is the newer | ||
6 | of the two technologies and puts power management in the hands of the | ||
7 | operating system, allowing for more intelligent power management than | ||
8 | is possible with BIOS controlled APM. | ||
9 | |||
10 | The best way to determine which, if either, your system supports is to | ||
11 | build a kernel with both ACPI and APM enabled (as of 2.3.x ACPI is | ||
12 | enabled by default). If a working ACPI implementation is found, the | ||
13 | ACPI driver will override and disable APM, otherwise the APM driver | ||
14 | will be used. | ||
15 | |||
16 | No, sorry, you cannot have both ACPI and APM enabled and running at | ||
17 | once. Some people with broken ACPI or broken APM implementations | ||
18 | would like to use both to get a full set of working features, but you | ||
19 | simply cannot mix and match the two. Only one power management | ||
20 | interface can be in control of the machine at once. Think about it.. | ||
21 | |||
22 | User-space Daemons | ||
23 | ------------------ | ||
24 | Both APM and ACPI rely on user-space daemons, apmd and acpid | ||
25 | respectively, to be completely functional. Obtain both of these | ||
26 | daemons from your Linux distribution or from the Internet (see below) | ||
27 | and be sure that they are started sometime in the system boot process. | ||
28 | Go ahead and start both. If ACPI or APM is not available on your | ||
29 | system the associated daemon will exit gracefully. | ||
30 | |||
31 | apmd: http://worldvisions.ca/~apenwarr/apmd/ | ||
32 | acpid: http://acpid.sf.net/ | ||
diff --git a/Documentation/power/pm.txt b/Documentation/power/pm.txt deleted file mode 100644 index be841507e43f..000000000000 --- a/Documentation/power/pm.txt +++ /dev/null | |||
@@ -1,257 +0,0 @@ | |||
1 | Linux Power Management Support | ||
2 | |||
3 | This document briefly describes how to use power management with your | ||
4 | Linux system and how to add power management support to Linux drivers. | ||
5 | |||
6 | APM or ACPI? | ||
7 | ------------ | ||
8 | If you have a relatively recent x86 mobile, desktop, or server system, | ||
9 | odds are it supports either Advanced Power Management (APM) or | ||
10 | Advanced Configuration and Power Interface (ACPI). ACPI is the newer | ||
11 | of the two technologies and puts power management in the hands of the | ||
12 | operating system, allowing for more intelligent power management than | ||
13 | is possible with BIOS controlled APM. | ||
14 | |||
15 | The best way to determine which, if either, your system supports is to | ||
16 | build a kernel with both ACPI and APM enabled (as of 2.3.x ACPI is | ||
17 | enabled by default). If a working ACPI implementation is found, the | ||
18 | ACPI driver will override and disable APM, otherwise the APM driver | ||
19 | will be used. | ||
20 | |||
21 | No, sorry, you cannot have both ACPI and APM enabled and running at | ||
22 | once. Some people with broken ACPI or broken APM implementations | ||
23 | would like to use both to get a full set of working features, but you | ||
24 | simply cannot mix and match the two. Only one power management | ||
25 | interface can be in control of the machine at once. Think about it.. | ||
26 | |||
27 | User-space Daemons | ||
28 | ------------------ | ||
29 | Both APM and ACPI rely on user-space daemons, apmd and acpid | ||
30 | respectively, to be completely functional. Obtain both of these | ||
31 | daemons from your Linux distribution or from the Internet (see below) | ||
32 | and be sure that they are started sometime in the system boot process. | ||
33 | Go ahead and start both. If ACPI or APM is not available on your | ||
34 | system the associated daemon will exit gracefully. | ||
35 | |||
36 | apmd: http://worldvisions.ca/~apenwarr/apmd/ | ||
37 | acpid: http://acpid.sf.net/ | ||
38 | |||
39 | Driver Interface -- OBSOLETE, DO NOT USE! | ||
40 | ----------------************************* | ||
41 | |||
42 | Note: pm_register(), pm_access(), pm_dev_idle() and friends are | ||
43 | obsolete. Please do not use them. Instead you should properly hook | ||
44 | your driver into the driver model, and use its suspend()/resume() | ||
45 | callbacks to do this kind of stuff. | ||
46 | |||
47 | If you are writing a new driver or maintaining an old driver, it | ||
48 | should include power management support. Without power management | ||
49 | support, a single driver may prevent a system with power management | ||
50 | capabilities from ever being able to suspend (safely). | ||
51 | |||
52 | Overview: | ||
53 | 1) Register each instance of a device with "pm_register" | ||
54 | 2) Call "pm_access" before accessing the hardware. | ||
55 | (this will ensure that the hardware is awake and ready) | ||
56 | 3) Your "pm_callback" is called before going into a | ||
57 | suspend state (ACPI D1-D3) or after resuming (ACPI D0) | ||
58 | from a suspend. | ||
59 | 4) Call "pm_dev_idle" when the device is not being used | ||
60 | (optional but will improve device idle detection) | ||
61 | 5) When unloaded, unregister the device with "pm_unregister" | ||
62 | |||
63 | /* | ||
64 | * Description: Register a device with the power-management subsystem | ||
65 | * | ||
66 | * Parameters: | ||
67 | * type - device type (PCI device, system device, ...) | ||
68 | * id - instance number or unique identifier | ||
69 | * cback - request handler callback (suspend, resume, ...) | ||
70 | * | ||
71 | * Returns: Registered PM device or NULL on error | ||
72 | * | ||
73 | * Examples: | ||
74 | * dev = pm_register(PM_SYS_DEV, PM_SYS_VGA, vga_callback); | ||
75 | * | ||
76 | * struct pci_dev *pci_dev = pci_find_dev(...); | ||
77 | * dev = pm_register(PM_PCI_DEV, PM_PCI_ID(pci_dev), callback); | ||
78 | */ | ||
79 | struct pm_dev *pm_register(pm_dev_t type, unsigned long id, pm_callback cback); | ||
80 | |||
81 | /* | ||
82 | * Description: Unregister a device with the power management subsystem | ||
83 | * | ||
84 | * Parameters: | ||
85 | * dev - PM device previously returned from pm_register | ||
86 | */ | ||
87 | void pm_unregister(struct pm_dev *dev); | ||
88 | |||
89 | /* | ||
90 | * Description: Unregister all devices with a matching callback function | ||
91 | * | ||
92 | * Parameters: | ||
93 | * cback - previously registered request callback | ||
94 | * | ||
95 | * Notes: Provided for easier porting from old APM interface | ||
96 | */ | ||
97 | void pm_unregister_all(pm_callback cback); | ||
98 | |||
99 | /* | ||
100 | * Power management request callback | ||
101 | * | ||
102 | * Parameters: | ||
103 | * dev - PM device previously returned from pm_register | ||
104 | * rqst - request type | ||
105 | * data - data, if any, associated with the request | ||
106 | * | ||
107 | * Returns: 0 if the request is successful | ||
108 | * EINVAL if the request is not supported | ||
109 | * EBUSY if the device is now busy and cannot handle the request | ||
110 | * ENOMEM if the device was unable to handle the request due to memory | ||
111 | * | ||
112 | * Details: The device request callback will be called before the | ||
113 | * device/system enters a suspend state (ACPI D1-D3) or | ||
114 | * or after the device/system resumes from suspend (ACPI D0). | ||
115 | * For PM_SUSPEND, the ACPI D-state being entered is passed | ||
116 | * as the "data" argument to the callback. The device | ||
117 | * driver should save (PM_SUSPEND) or restore (PM_RESUME) | ||
118 | * device context when the request callback is called. | ||
119 | * | ||
120 | * Once a driver returns 0 (success) from a suspend | ||
121 | * request, it should not process any further requests or | ||
122 | * access the device hardware until a call to "pm_access" is made. | ||
123 | */ | ||
124 | typedef int (*pm_callback)(struct pm_dev *dev, pm_request_t rqst, void *data); | ||
125 | |||
126 | Driver Details | ||
127 | -------------- | ||
128 | This is just a quick Q&A as a stopgap until a real driver writers' | ||
129 | power management guide is available. | ||
130 | |||
131 | Q: When is a device suspended? | ||
132 | |||
133 | Devices can be suspended based on direct user request (eg. laptop lid | ||
134 | closes), system power policy (eg. sleep after 30 minutes of console | ||
135 | inactivity), or device power policy (eg. power down device after 5 | ||
136 | minutes of inactivity) | ||
137 | |||
138 | Q: Must a driver honor a suspend request? | ||
139 | |||
140 | No, a driver can return -EBUSY from a suspend request and this | ||
141 | will stop the system from suspending. When a suspend request | ||
142 | fails, all suspended devices are resumed and the system continues | ||
143 | to run. Suspend can be retried at a later time. | ||
144 | |||
145 | Q: Can the driver block suspend/resume requests? | ||
146 | |||
147 | Yes, a driver can delay its return from a suspend or resume | ||
148 | request until the device is ready to handle requests. It | ||
149 | is advantageous to return as quickly as possible from a | ||
150 | request as suspend/resume are done serially. | ||
151 | |||
152 | Q: What context is a suspend/resume initiated from? | ||
153 | |||
154 | A suspend or resume is initiated from a kernel thread context. | ||
155 | It is safe to block, allocate memory, initiate requests | ||
156 | or anything else you can do within the kernel. | ||
157 | |||
158 | Q: Will requests continue to arrive after a suspend? | ||
159 | |||
160 | Possibly. It is the driver's responsibility to queue(*), | ||
161 | fail, or drop any requests that arrive after returning | ||
162 | success to a suspend request. It is important that the | ||
163 | driver not access its device until after it receives | ||
164 | a resume request as the device's bus may no longer | ||
165 | be active. | ||
166 | |||
167 | (*) If a driver queues requests for processing after | ||
168 | resume be aware that the device, network, etc. | ||
169 | might be in a different state than at suspend time. | ||
170 | It's probably better to drop requests unless | ||
171 | the driver is a storage device. | ||
172 | |||
173 | Q: Do I have to manage bus-specific power management registers | ||
174 | |||
175 | No. It is the responsibility of the bus driver to manage | ||
176 | PCI, USB, etc. power management registers. The bus driver | ||
177 | or the power management subsystem will also enable any | ||
178 | wake-on functionality that the device has. | ||
179 | |||
180 | Q: So, really, what do I need to do to support suspend/resume? | ||
181 | |||
182 | You need to save any device context that would | ||
183 | be lost if the device was powered off and then restore | ||
184 | it at resume time. When ACPI is active, there are | ||
185 | three levels of device suspend states; D1, D2, and D3. | ||
186 | (The suspend state is passed as the "data" argument | ||
187 | to the device callback.) With D3, the device is powered | ||
188 | off and loses all context, D1 and D2 are shallower power | ||
189 | states and require less device context to be saved. To | ||
190 | play it safe, just save everything at suspend and restore | ||
191 | everything at resume. | ||
192 | |||
193 | Q: Where do I store device context for suspend? | ||
194 | |||
195 | Anywhere in memory, kmalloc a buffer or store it | ||
196 | in the device descriptor. You are guaranteed that the | ||
197 | contents of memory will be restored and accessible | ||
198 | before resume, even when the system suspends to disk. | ||
199 | |||
200 | Q: What do I need to do for ACPI vs. APM vs. etc? | ||
201 | |||
202 | Drivers need not be aware of the specific power management | ||
203 | technology that is active. They just need to be aware | ||
204 | of when the overlying power management system requests | ||
205 | that they suspend or resume. | ||
206 | |||
207 | Q: What about device dependencies? | ||
208 | |||
209 | When a driver registers a device, the power management | ||
210 | subsystem uses the information provided to build a | ||
211 | tree of device dependencies (eg. USB device X is on | ||
212 | USB controller Y which is on PCI bus Z) When power | ||
213 | management wants to suspend a device, it first sends | ||
214 | a suspend request to its driver, then the bus driver, | ||
215 | and so on up to the system bus. Device resumes | ||
216 | proceed in the opposite direction. | ||
217 | |||
218 | Q: Who do I contact for additional information about | ||
219 | enabling power management for my specific driver/device? | ||
220 | |||
221 | ACPI Development mailing list: linux-acpi@vger.kernel.org | ||
222 | |||
223 | System Interface -- OBSOLETE, DO NOT USE! | ||
224 | ----------------************************* | ||
225 | If you are providing new power management support to Linux (ie. | ||
226 | adding support for something like APM or ACPI), you should | ||
227 | communicate with drivers through the existing generic power | ||
228 | management interface. | ||
229 | |||
230 | /* | ||
231 | * Send a request to all devices | ||
232 | * | ||
233 | * Parameters: | ||
234 | * rqst - request type | ||
235 | * data - data, if any, associated with the request | ||
236 | * | ||
237 | * Returns: 0 if the request is successful | ||
238 | * See "pm_callback" return for errors | ||
239 | * | ||
240 | * Details: Walk list of registered devices and call pm_send | ||
241 | * for each until complete or an error is encountered. | ||
242 | * If an error is encountered for a suspend request, | ||
243 | * return all devices to the state they were in before | ||
244 | * the suspend request. | ||
245 | */ | ||
246 | int pm_send_all(pm_request_t rqst, void *data); | ||
247 | |||
248 | /* | ||
249 | * Find a matching device | ||
250 | * | ||
251 | * Parameters: | ||
252 | * type - device type (PCI device, system device, or 0 to match all devices) | ||
253 | * from - previous match or NULL to start from the beginning | ||
254 | * | ||
255 | * Returns: Matching device or NULL if none found | ||
256 | */ | ||
257 | struct pm_dev *pm_find(pm_dev_t type, struct pm_dev *from); | ||
diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt index a8686e5a6857..c6cd4956047c 100644 --- a/Documentation/power/power_supply_class.txt +++ b/Documentation/power/power_supply_class.txt | |||
@@ -101,6 +101,10 @@ of charge when battery became full/empty". It also could mean "value of | |||
101 | charge when battery considered full/empty at given conditions (temperature, | 101 | charge when battery considered full/empty at given conditions (temperature, |
102 | age)". I.e. these attributes represents real thresholds, not design values. | 102 | age)". I.e. these attributes represents real thresholds, not design values. |
103 | 103 | ||
104 | CHARGE_COUNTER - the current charge counter (in µAh). This could easily | ||
105 | be negative; there is no empty or full value. It is only useful for | ||
106 | relative, time-based measurements. | ||
107 | |||
104 | ENERGY_FULL, ENERGY_EMPTY - same as above but for energy. | 108 | ENERGY_FULL, ENERGY_EMPTY - same as above but for energy. |
105 | 109 | ||
106 | CAPACITY - capacity in percents. | 110 | CAPACITY - capacity in percents. |
diff --git a/Documentation/power/regulator/consumer.txt b/Documentation/power/regulator/consumer.txt new file mode 100644 index 000000000000..82b7a43aadba --- /dev/null +++ b/Documentation/power/regulator/consumer.txt | |||
@@ -0,0 +1,182 @@ | |||
1 | Regulator Consumer Driver Interface | ||
2 | =================================== | ||
3 | |||
4 | This text describes the regulator interface for consumer device drivers. | ||
5 | Please see overview.txt for a description of the terms used in this text. | ||
6 | |||
7 | |||
8 | 1. Consumer Regulator Access (static & dynamic drivers) | ||
9 | ======================================================= | ||
10 | |||
11 | A consumer driver can get access to it's supply regulator by calling :- | ||
12 | |||
13 | regulator = regulator_get(dev, "Vcc"); | ||
14 | |||
15 | The consumer passes in it's struct device pointer and power supply ID. The core | ||
16 | then finds the correct regulator by consulting a machine specific lookup table. | ||
17 | If the lookup is successful then this call will return a pointer to the struct | ||
18 | regulator that supplies this consumer. | ||
19 | |||
20 | To release the regulator the consumer driver should call :- | ||
21 | |||
22 | regulator_put(regulator); | ||
23 | |||
24 | Consumers can be supplied by more than one regulator e.g. codec consumer with | ||
25 | analog and digital supplies :- | ||
26 | |||
27 | digital = regulator_get(dev, "Vcc"); /* digital core */ | ||
28 | analog = regulator_get(dev, "Avdd"); /* analog */ | ||
29 | |||
30 | The regulator access functions regulator_get() and regulator_put() will | ||
31 | usually be called in your device drivers probe() and remove() respectively. | ||
32 | |||
33 | |||
34 | 2. Regulator Output Enable & Disable (static & dynamic drivers) | ||
35 | ==================================================================== | ||
36 | |||
37 | A consumer can enable it's power supply by calling:- | ||
38 | |||
39 | int regulator_enable(regulator); | ||
40 | |||
41 | NOTE: The supply may already be enabled before regulator_enabled() is called. | ||
42 | This may happen if the consumer shares the regulator or the regulator has been | ||
43 | previously enabled by bootloader or kernel board initialization code. | ||
44 | |||
45 | A consumer can determine if a regulator is enabled by calling :- | ||
46 | |||
47 | int regulator_is_enabled(regulator); | ||
48 | |||
49 | This will return > zero when the regulator is enabled. | ||
50 | |||
51 | |||
52 | A consumer can disable it's supply when no longer needed by calling :- | ||
53 | |||
54 | int regulator_disable(regulator); | ||
55 | |||
56 | NOTE: This may not disable the supply if it's shared with other consumers. The | ||
57 | regulator will only be disabled when the enabled reference count is zero. | ||
58 | |||
59 | Finally, a regulator can be forcefully disabled in the case of an emergency :- | ||
60 | |||
61 | int regulator_force_disable(regulator); | ||
62 | |||
63 | NOTE: this will immediately and forcefully shutdown the regulator output. All | ||
64 | consumers will be powered off. | ||
65 | |||
66 | |||
67 | 3. Regulator Voltage Control & Status (dynamic drivers) | ||
68 | ====================================================== | ||
69 | |||
70 | Some consumer drivers need to be able to dynamically change their supply | ||
71 | voltage to match system operating points. e.g. CPUfreq drivers can scale | ||
72 | voltage along with frequency to save power, SD drivers may need to select the | ||
73 | correct card voltage, etc. | ||
74 | |||
75 | Consumers can control their supply voltage by calling :- | ||
76 | |||
77 | int regulator_set_voltage(regulator, min_uV, max_uV); | ||
78 | |||
79 | Where min_uV and max_uV are the minimum and maximum acceptable voltages in | ||
80 | microvolts. | ||
81 | |||
82 | NOTE: this can be called when the regulator is enabled or disabled. If called | ||
83 | when enabled, then the voltage changes instantly, otherwise the voltage | ||
84 | configuration changes and the voltage is physically set when the regulator is | ||
85 | next enabled. | ||
86 | |||
87 | The regulators configured voltage output can be found by calling :- | ||
88 | |||
89 | int regulator_get_voltage(regulator); | ||
90 | |||
91 | NOTE: get_voltage() will return the configured output voltage whether the | ||
92 | regulator is enabled or disabled and should NOT be used to determine regulator | ||
93 | output state. However this can be used in conjunction with is_enabled() to | ||
94 | determine the regulator physical output voltage. | ||
95 | |||
96 | |||
97 | 4. Regulator Current Limit Control & Status (dynamic drivers) | ||
98 | =========================================================== | ||
99 | |||
100 | Some consumer drivers need to be able to dynamically change their supply | ||
101 | current limit to match system operating points. e.g. LCD backlight driver can | ||
102 | change the current limit to vary the backlight brightness, USB drivers may want | ||
103 | to set the limit to 500mA when supplying power. | ||
104 | |||
105 | Consumers can control their supply current limit by calling :- | ||
106 | |||
107 | int regulator_set_current_limit(regulator, min_uV, max_uV); | ||
108 | |||
109 | Where min_uA and max_uA are the minimum and maximum acceptable current limit in | ||
110 | microamps. | ||
111 | |||
112 | NOTE: this can be called when the regulator is enabled or disabled. If called | ||
113 | when enabled, then the current limit changes instantly, otherwise the current | ||
114 | limit configuration changes and the current limit is physically set when the | ||
115 | regulator is next enabled. | ||
116 | |||
117 | A regulators current limit can be found by calling :- | ||
118 | |||
119 | int regulator_get_current_limit(regulator); | ||
120 | |||
121 | NOTE: get_current_limit() will return the current limit whether the regulator | ||
122 | is enabled or disabled and should not be used to determine regulator current | ||
123 | load. | ||
124 | |||
125 | |||
126 | 5. Regulator Operating Mode Control & Status (dynamic drivers) | ||
127 | ============================================================= | ||
128 | |||
129 | Some consumers can further save system power by changing the operating mode of | ||
130 | their supply regulator to be more efficient when the consumers operating state | ||
131 | changes. e.g. consumer driver is idle and subsequently draws less current | ||
132 | |||
133 | Regulator operating mode can be changed indirectly or directly. | ||
134 | |||
135 | Indirect operating mode control. | ||
136 | -------------------------------- | ||
137 | Consumer drivers can request a change in their supply regulator operating mode | ||
138 | by calling :- | ||
139 | |||
140 | int regulator_set_optimum_mode(struct regulator *regulator, int load_uA); | ||
141 | |||
142 | This will cause the core to recalculate the total load on the regulator (based | ||
143 | on all it's consumers) and change operating mode (if necessary and permitted) | ||
144 | to best match the current operating load. | ||
145 | |||
146 | The load_uA value can be determined from the consumers datasheet. e.g.most | ||
147 | datasheets have tables showing the max current consumed in certain situations. | ||
148 | |||
149 | Most consumers will use indirect operating mode control since they have no | ||
150 | knowledge of the regulator or whether the regulator is shared with other | ||
151 | consumers. | ||
152 | |||
153 | Direct operating mode control. | ||
154 | ------------------------------ | ||
155 | Bespoke or tightly coupled drivers may want to directly control regulator | ||
156 | operating mode depending on their operating point. This can be achieved by | ||
157 | calling :- | ||
158 | |||
159 | int regulator_set_mode(struct regulator *regulator, unsigned int mode); | ||
160 | unsigned int regulator_get_mode(struct regulator *regulator); | ||
161 | |||
162 | Direct mode will only be used by consumers that *know* about the regulator and | ||
163 | are not sharing the regulator with other consumers. | ||
164 | |||
165 | |||
166 | 6. Regulator Events | ||
167 | =================== | ||
168 | Regulators can notify consumers of external events. Events could be received by | ||
169 | consumers under regulator stress or failure conditions. | ||
170 | |||
171 | Consumers can register interest in regulator events by calling :- | ||
172 | |||
173 | int regulator_register_notifier(struct regulator *regulator, | ||
174 | struct notifier_block *nb); | ||
175 | |||
176 | Consumers can uregister interest by calling :- | ||
177 | |||
178 | int regulator_unregister_notifier(struct regulator *regulator, | ||
179 | struct notifier_block *nb); | ||
180 | |||
181 | Regulators use the kernel notifier framework to send event to thier interested | ||
182 | consumers. | ||
diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt new file mode 100644 index 000000000000..c9a35665cf70 --- /dev/null +++ b/Documentation/power/regulator/machine.txt | |||
@@ -0,0 +1,101 @@ | |||
1 | Regulator Machine Driver Interface | ||
2 | =================================== | ||
3 | |||
4 | The regulator machine driver interface is intended for board/machine specific | ||
5 | initialisation code to configure the regulator subsystem. Typical things that | ||
6 | machine drivers would do are :- | ||
7 | |||
8 | 1. Regulator -> Device mapping. | ||
9 | 2. Regulator supply configuration. | ||
10 | 3. Power Domain constraint setting. | ||
11 | |||
12 | |||
13 | |||
14 | 1. Regulator -> device mapping | ||
15 | ============================== | ||
16 | Consider the following machine :- | ||
17 | |||
18 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | ||
19 | | | ||
20 | +-> [Consumer B @ 3.3V] | ||
21 | |||
22 | The drivers for consumers A & B must be mapped to the correct regulator in | ||
23 | order to control their power supply. This mapping can be achieved in machine | ||
24 | initialisation code by calling :- | ||
25 | |||
26 | int regulator_set_device_supply(const char *regulator, struct device *dev, | ||
27 | const char *supply); | ||
28 | |||
29 | and is shown with the following code :- | ||
30 | |||
31 | regulator_set_device_supply("Regulator-1", devB, "Vcc"); | ||
32 | regulator_set_device_supply("Regulator-2", devA, "Vcc"); | ||
33 | |||
34 | This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2 | ||
35 | to the 'Vcc' supply for Consumer A. | ||
36 | |||
37 | |||
38 | 2. Regulator supply configuration. | ||
39 | ================================== | ||
40 | Consider the following machine (again) :- | ||
41 | |||
42 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | ||
43 | | | ||
44 | +-> [Consumer B @ 3.3V] | ||
45 | |||
46 | Regulator-1 supplies power to Regulator-2. This relationship must be registered | ||
47 | with the core so that Regulator-1 is also enabled when Consumer A enables it's | ||
48 | supply (Regulator-2). | ||
49 | |||
50 | This relationship can be register with the core via :- | ||
51 | |||
52 | int regulator_set_supply(const char *regulator, const char *regulator_supply); | ||
53 | |||
54 | In this example we would use the following code :- | ||
55 | |||
56 | regulator_set_supply("Regulator-2", "Regulator-1"); | ||
57 | |||
58 | Relationships can be queried by calling :- | ||
59 | |||
60 | const char *regulator_get_supply(const char *regulator); | ||
61 | |||
62 | |||
63 | 3. Power Domain constraint setting. | ||
64 | =================================== | ||
65 | Each power domain within a system has physical constraints on voltage and | ||
66 | current. This must be defined in software so that the power domain is always | ||
67 | operated within specifications. | ||
68 | |||
69 | Consider the following machine (again) :- | ||
70 | |||
71 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | ||
72 | | | ||
73 | +-> [Consumer B @ 3.3V] | ||
74 | |||
75 | This gives us two regulators and two power domains: | ||
76 | |||
77 | Domain 1: Regulator-2, Consumer B. | ||
78 | Domain 2: Consumer A. | ||
79 | |||
80 | Constraints can be registered by calling :- | ||
81 | |||
82 | int regulator_set_platform_constraints(const char *regulator, | ||
83 | struct regulation_constraints *constraints); | ||
84 | |||
85 | The example is defined as follows :- | ||
86 | |||
87 | struct regulation_constraints domain_1 = { | ||
88 | .min_uV = 3300000, | ||
89 | .max_uV = 3300000, | ||
90 | .valid_modes_mask = REGULATOR_MODE_NORMAL, | ||
91 | }; | ||
92 | |||
93 | struct regulation_constraints domain_2 = { | ||
94 | .min_uV = 1800000, | ||
95 | .max_uV = 2000000, | ||
96 | .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE, | ||
97 | .valid_modes_mask = REGULATOR_MODE_NORMAL, | ||
98 | }; | ||
99 | |||
100 | regulator_set_platform_constraints("Regulator-1", &domain_1); | ||
101 | regulator_set_platform_constraints("Regulator-2", &domain_2); | ||
diff --git a/Documentation/power/regulator/overview.txt b/Documentation/power/regulator/overview.txt new file mode 100644 index 000000000000..bdcb332bd7fb --- /dev/null +++ b/Documentation/power/regulator/overview.txt | |||
@@ -0,0 +1,171 @@ | |||
1 | Linux voltage and current regulator framework | ||
2 | ============================================= | ||
3 | |||
4 | About | ||
5 | ===== | ||
6 | |||
7 | This framework is designed to provide a standard kernel interface to control | ||
8 | voltage and current regulators. | ||
9 | |||
10 | The intention is to allow systems to dynamically control regulator power output | ||
11 | in order to save power and prolong battery life. This applies to both voltage | ||
12 | regulators (where voltage output is controllable) and current sinks (where | ||
13 | current limit is controllable). | ||
14 | |||
15 | (C) 2008 Wolfson Microelectronics PLC. | ||
16 | Author: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
17 | |||
18 | |||
19 | Nomenclature | ||
20 | ============ | ||
21 | |||
22 | Some terms used in this document:- | ||
23 | |||
24 | o Regulator - Electronic device that supplies power to other devices. | ||
25 | Most regulators can enable and disable their output whilst | ||
26 | some can control their output voltage and or current. | ||
27 | |||
28 | Input Voltage -> Regulator -> Output Voltage | ||
29 | |||
30 | |||
31 | o PMIC - Power Management IC. An IC that contains numerous regulators | ||
32 | and often contains other susbsystems. | ||
33 | |||
34 | |||
35 | o Consumer - Electronic device that is supplied power by a regulator. | ||
36 | Consumers can be classified into two types:- | ||
37 | |||
38 | Static: consumer does not change it's supply voltage or | ||
39 | current limit. It only needs to enable or disable it's | ||
40 | power supply. It's supply voltage is set by the hardware, | ||
41 | bootloader, firmware or kernel board initialisation code. | ||
42 | |||
43 | Dynamic: consumer needs to change it's supply voltage or | ||
44 | current limit to meet operation demands. | ||
45 | |||
46 | |||
47 | o Power Domain - Electronic circuit that is supplied it's input power by the | ||
48 | output power of a regulator, switch or by another power | ||
49 | domain. | ||
50 | |||
51 | The supply regulator may be behind a switch(s). i.e. | ||
52 | |||
53 | Regulator -+-> Switch-1 -+-> Switch-2 --> [Consumer A] | ||
54 | | | | ||
55 | | +-> [Consumer B], [Consumer C] | ||
56 | | | ||
57 | +-> [Consumer D], [Consumer E] | ||
58 | |||
59 | That is one regulator and three power domains: | ||
60 | |||
61 | Domain 1: Switch-1, Consumers D & E. | ||
62 | Domain 2: Switch-2, Consumers B & C. | ||
63 | Domain 3: Consumer A. | ||
64 | |||
65 | and this represents a "supplies" relationship: | ||
66 | |||
67 | Domain-1 --> Domain-2 --> Domain-3. | ||
68 | |||
69 | A power domain may have regulators that are supplied power | ||
70 | by other regulators. i.e. | ||
71 | |||
72 | Regulator-1 -+-> Regulator-2 -+-> [Consumer A] | ||
73 | | | ||
74 | +-> [Consumer B] | ||
75 | |||
76 | This gives us two regulators and two power domains: | ||
77 | |||
78 | Domain 1: Regulator-2, Consumer B. | ||
79 | Domain 2: Consumer A. | ||
80 | |||
81 | and a "supplies" relationship: | ||
82 | |||
83 | Domain-1 --> Domain-2 | ||
84 | |||
85 | |||
86 | o Constraints - Constraints are used to define power levels for performance | ||
87 | and hardware protection. Constraints exist at three levels: | ||
88 | |||
89 | Regulator Level: This is defined by the regulator hardware | ||
90 | operating parameters and is specified in the regulator | ||
91 | datasheet. i.e. | ||
92 | |||
93 | - voltage output is in the range 800mV -> 3500mV. | ||
94 | - regulator current output limit is 20mA @ 5V but is | ||
95 | 10mA @ 10V. | ||
96 | |||
97 | Power Domain Level: This is defined in software by kernel | ||
98 | level board initialisation code. It is used to constrain a | ||
99 | power domain to a particular power range. i.e. | ||
100 | |||
101 | - Domain-1 voltage is 3300mV | ||
102 | - Domain-2 voltage is 1400mV -> 1600mV | ||
103 | - Domain-3 current limit is 0mA -> 20mA. | ||
104 | |||
105 | Consumer Level: This is defined by consumer drivers | ||
106 | dynamically setting voltage or current limit levels. | ||
107 | |||
108 | e.g. a consumer backlight driver asks for a current increase | ||
109 | from 5mA to 10mA to increase LCD illumination. This passes | ||
110 | to through the levels as follows :- | ||
111 | |||
112 | Consumer: need to increase LCD brightness. Lookup and | ||
113 | request next current mA value in brightness table (the | ||
114 | consumer driver could be used on several different | ||
115 | personalities based upon the same reference device). | ||
116 | |||
117 | Power Domain: is the new current limit within the domain | ||
118 | operating limits for this domain and system state (e.g. | ||
119 | battery power, USB power) | ||
120 | |||
121 | Regulator Domains: is the new current limit within the | ||
122 | regulator operating parameters for input/ouput voltage. | ||
123 | |||
124 | If the regulator request passes all the constraint tests | ||
125 | then the new regulator value is applied. | ||
126 | |||
127 | |||
128 | Design | ||
129 | ====== | ||
130 | |||
131 | The framework is designed and targeted at SoC based devices but may also be | ||
132 | relevant to non SoC devices and is split into the following four interfaces:- | ||
133 | |||
134 | |||
135 | 1. Consumer driver interface. | ||
136 | |||
137 | This uses a similar API to the kernel clock interface in that consumer | ||
138 | drivers can get and put a regulator (like they can with clocks atm) and | ||
139 | get/set voltage, current limit, mode, enable and disable. This should | ||
140 | allow consumers complete control over their supply voltage and current | ||
141 | limit. This also compiles out if not in use so drivers can be reused in | ||
142 | systems with no regulator based power control. | ||
143 | |||
144 | See Documentation/power/regulator/consumer.txt | ||
145 | |||
146 | 2. Regulator driver interface. | ||
147 | |||
148 | This allows regulator drivers to register their regulators and provide | ||
149 | operations to the core. It also has a notifier call chain for propagating | ||
150 | regulator events to clients. | ||
151 | |||
152 | See Documentation/power/regulator/regulator.txt | ||
153 | |||
154 | 3. Machine interface. | ||
155 | |||
156 | This interface is for machine specific code and allows the creation of | ||
157 | voltage/current domains (with constraints) for each regulator. It can | ||
158 | provide regulator constraints that will prevent device damage through | ||
159 | overvoltage or over current caused by buggy client drivers. It also | ||
160 | allows the creation of a regulator tree whereby some regulators are | ||
161 | supplied by others (similar to a clock tree). | ||
162 | |||
163 | See Documentation/power/regulator/machine.txt | ||
164 | |||
165 | 4. Userspace ABI. | ||
166 | |||
167 | The framework also exports a lot of useful voltage/current/opmode data to | ||
168 | userspace via sysfs. This could be used to help monitor device power | ||
169 | consumption and status. | ||
170 | |||
171 | See Documentation/ABI/testing/regulator-sysfs.txt | ||
diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt new file mode 100644 index 000000000000..a69050143592 --- /dev/null +++ b/Documentation/power/regulator/regulator.txt | |||
@@ -0,0 +1,30 @@ | |||
1 | Regulator Driver Interface | ||
2 | ========================== | ||
3 | |||
4 | The regulator driver interface is relatively simple and designed to allow | ||
5 | regulator drivers to register their services with the core framework. | ||
6 | |||
7 | |||
8 | Registration | ||
9 | ============ | ||
10 | |||
11 | Drivers can register a regulator by calling :- | ||
12 | |||
13 | struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc, | ||
14 | void *reg_data); | ||
15 | |||
16 | This will register the regulators capabilities and operations the regulator | ||
17 | core. The core does not touch reg_data (private to regulator driver). | ||
18 | |||
19 | Regulators can be unregistered by calling :- | ||
20 | |||
21 | void regulator_unregister(struct regulator_dev *rdev); | ||
22 | |||
23 | |||
24 | Regulator Events | ||
25 | ================ | ||
26 | Regulators can send events (e.g. over temp, under voltage, etc) to consumer | ||
27 | drivers by calling :- | ||
28 | |||
29 | int regulator_notifier_call_chain(struct regulator_dev *rdev, | ||
30 | unsigned long event, void *data); | ||
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index 3be84aa38dfe..29d839ce7327 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX | |||
@@ -20,8 +20,6 @@ mpc52xx-device-tree-bindings.txt | |||
20 | - MPC5200 Device Tree Bindings | 20 | - MPC5200 Device Tree Bindings |
21 | ppc_htab.txt | 21 | ppc_htab.txt |
22 | - info about the Linux/PPC /proc/ppc_htab entry | 22 | - info about the Linux/PPC /proc/ppc_htab entry |
23 | SBC8260_memory_mapping.txt | ||
24 | - EST SBC8260 board info | ||
25 | smp.txt | 23 | smp.txt |
26 | - use and state info about Linux/PPC on MP machines | 24 | - use and state info about Linux/PPC on MP machines |
27 | sound.txt | 25 | sound.txt |
diff --git a/Documentation/powerpc/SBC8260_memory_mapping.txt b/Documentation/powerpc/SBC8260_memory_mapping.txt deleted file mode 100644 index e6e9ee0506c3..000000000000 --- a/Documentation/powerpc/SBC8260_memory_mapping.txt +++ /dev/null | |||
@@ -1,197 +0,0 @@ | |||
1 | Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com) | ||
2 | if you have questions, comments or corrections. | ||
3 | |||
4 | * EST SBC8260 Linux memory mapping rules | ||
5 | |||
6 | http://www.estc.com/ | ||
7 | http://www.estc.com/products/boards/SBC8260-8240_ds.html | ||
8 | |||
9 | Initial conditions: | ||
10 | ------------------- | ||
11 | |||
12 | Tasks that need to be perform by the boot ROM before control is | ||
13 | transferred to zImage (compressed Linux kernel): | ||
14 | |||
15 | - Define the IMMR to 0xf0000000 | ||
16 | |||
17 | - Initialize the memory controller so that RAM is available at | ||
18 | physical address 0x00000000. On the SBC8260 is this 16M (64M) | ||
19 | SDRAM. | ||
20 | |||
21 | - The boot ROM should only clear the RAM that it is using. | ||
22 | |||
23 | The reason for doing this is to enhances the chances of a | ||
24 | successful post mortem on a Linux panic. One of the first | ||
25 | items to examine is the 16k (LOG_BUF_LEN) circular console | ||
26 | buffer called log_buf which is defined in kernel/printk.c. | ||
27 | |||
28 | - To enhance boot ROM performance, the I-cache can be enabled. | ||
29 | |||
30 | Date: Mon, 22 May 2000 14:21:10 -0700 | ||
31 | From: Neil Russell <caret@c-side.com> | ||
32 | |||
33 | LiMon (LInux MONitor) runs with and starts Linux with MMU | ||
34 | off, I-cache enabled, D-cache disabled. The I-cache doesn't | ||
35 | need hints from the MMU to work correctly as the D-cache | ||
36 | does. No D-cache means no special code to handle devices in | ||
37 | the presence of cache (no snooping, etc). The use of the | ||
38 | I-cache means that the monitor can run acceptably fast | ||
39 | directly from ROM, rather than having to copy it to RAM. | ||
40 | |||
41 | - Build the board information structure (see | ||
42 | include/asm-ppc/est8260.h for its definition) | ||
43 | |||
44 | - The compressed Linux kernel (zImage) contains a bootstrap loader | ||
45 | that is position independent; you can load it into any RAM, | ||
46 | ROM or FLASH memory address >= 0x00500000 (above 5 MB), or | ||
47 | at its link address of 0x00400000 (4 MB). | ||
48 | |||
49 | Note: If zImage is loaded at its link address of 0x00400000 (4 MB), | ||
50 | then zImage will skip the step of moving itself to | ||
51 | its link address. | ||
52 | |||
53 | - Load R3 with the address of the board information structure | ||
54 | |||
55 | - Transfer control to zImage | ||
56 | |||
57 | - The Linux console port is SMC1, and the baud rate is controlled | ||
58 | from the bi_baudrate field of the board information structure. | ||
59 | On thing to keep in mind when picking the baud rate, is that | ||
60 | there is no flow control on the SMC ports. I would stick | ||
61 | with something safe and standard like 19200. | ||
62 | |||
63 | On the EST SBC8260, the SMC1 port is on the COM1 connector of | ||
64 | the board. | ||
65 | |||
66 | |||
67 | EST SBC8260 defaults: | ||
68 | --------------------- | ||
69 | |||
70 | Chip | ||
71 | Memory Sel Bus Use | ||
72 | --------------------- --- --- ---------------------------------- | ||
73 | 0x00000000-0x03FFFFFF CS2 60x (16M or 64M)/64M SDRAM | ||
74 | 0x04000000-0x04FFFFFF CS4 local 4M/16M SDRAM (soldered to the board) | ||
75 | 0x21000000-0x21000000 CS7 60x 1B/64K Flash present detect (from the flash SIMM) | ||
76 | 0x21000001-0x21000001 CS7 60x 1B/64K Switches (read) and LEDs (write) | ||
77 | 0x22000000-0x2200FFFF CS5 60x 8K/64K EEPROM | ||
78 | 0xFC000000-0xFCFFFFFF CS6 60x 2M/16M flash (8 bits wide, soldered to the board) | ||
79 | 0xFE000000-0xFFFFFFFF CS0 60x 4M/16M flash (SIMM) | ||
80 | |||
81 | Notes: | ||
82 | ------ | ||
83 | |||
84 | - The chip selects can map 32K blocks and up (powers of 2) | ||
85 | |||
86 | - The SDRAM machine can handled up to 128Mbytes per chip select | ||
87 | |||
88 | - Linux uses the 60x bus memory (the SDRAM DIMM) for the | ||
89 | communications buffers. | ||
90 | |||
91 | - BATs can map 128K-256Mbytes each. There are four data BATs and | ||
92 | four instruction BATs. Generally the data and instruction BATs | ||
93 | are mapped the same. | ||
94 | |||
95 | - The IMMR must be set above the kernel virtual memory addresses, | ||
96 | which start at 0xC0000000. Otherwise, the kernel may crash as | ||
97 | soon as you start any threads or processes due to VM collisions | ||
98 | in the kernel or user process space. | ||
99 | |||
100 | |||
101 | Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999: | ||
102 | |||
103 | The user application virtual space consumes the first 2 Gbytes | ||
104 | (0x00000000 to 0x7FFFFFFF). The kernel virtual text starts at | ||
105 | 0xC0000000, with data following. There is a "protection hole" | ||
106 | between the end of kernel data and the start of the kernel | ||
107 | dynamically allocated space, but this space is still within | ||
108 | 0xCxxxxxxx. | ||
109 | |||
110 | Obviously the kernel can't map any physical addresses 1:1 in | ||
111 | these ranges. | ||
112 | |||
113 | |||
114 | Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000: | ||
115 | |||
116 | During the early kernel initialization, the kernel virtual | ||
117 | memory allocator is not operational. Prior to this KVM | ||
118 | initialization, we choose to map virtual to physical addresses | ||
119 | 1:1. That is, the kernel virtual address exactly matches the | ||
120 | physical address on the bus. These mappings are typically done | ||
121 | in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c. Only | ||
122 | absolutely necessary mappings should be done at this time, for | ||
123 | example board control registers or a serial uart. Normal device | ||
124 | driver initialization should map resources later when necessary. | ||
125 | |||
126 | Although platform dependent, and certainly the case for embedded | ||
127 | 8xx, traditionally memory is mapped at physical address zero, | ||
128 | and I/O devices above physical address 0x80000000. The lowest | ||
129 | and highest (above 0xf0000000) I/O addresses are traditionally | ||
130 | used for devices or registers we need to map during kernel | ||
131 | initialization and prior to KVM operation. For this reason, | ||
132 | and since it followed prior PowerPC platform examples, I chose | ||
133 | to map the embedded 8xx kernel to the 0xc0000000 virtual address. | ||
134 | This way, we can enable the MMU to map the kernel for proper | ||
135 | operation, and still map a few windows before the KVM is operational. | ||
136 | |||
137 | On some systems, you could possibly run the kernel at the | ||
138 | 0x80000000 or any other virtual address. It just depends upon | ||
139 | mapping that must be done prior to KVM operational. You can never | ||
140 | map devices or kernel spaces that overlap with the user virtual | ||
141 | space. This is why default IMMR mapping used by most BDM tools | ||
142 | won't work. They put the IMMR at something like 0x10000000 or | ||
143 | 0x02000000 for example. You simply can't map these addresses early | ||
144 | in the kernel, and continue proper system operation. | ||
145 | |||
146 | The embedded 8xx/82xx kernel is mature enough that all you should | ||
147 | need to do is map the IMMR someplace at or above 0xf0000000 and it | ||
148 | should boot far enough to get serial console messages and KGDB | ||
149 | connected on any platform. There are lots of other subtle memory | ||
150 | management design features that you simply don't need to worry | ||
151 | about. If you are changing functions related to MMU initialization, | ||
152 | you are likely breaking things that are known to work and are | ||
153 | heading down a path of disaster and frustration. Your changes | ||
154 | should be to make the flexibility of the processor fit Linux, | ||
155 | not force arbitrary and non-workable memory mappings into Linux. | ||
156 | |||
157 | - You don't want to change KERNELLOAD or KERNELBASE, otherwise the | ||
158 | virtual memory and MMU code will get confused. | ||
159 | |||
160 | arch/ppc/Makefile:KERNELLOAD = 0xc0000000 | ||
161 | |||
162 | include/asm-ppc/page.h:#define PAGE_OFFSET 0xc0000000 | ||
163 | include/asm-ppc/page.h:#define KERNELBASE PAGE_OFFSET | ||
164 | |||
165 | - RAM is at physical address 0x00000000, and gets mapped to | ||
166 | virtual address 0xC0000000 for the kernel. | ||
167 | |||
168 | |||
169 | Physical addresses used by the Linux kernel: | ||
170 | -------------------------------------------- | ||
171 | |||
172 | 0x00000000-0x3FFFFFFF 1GB reserved for RAM | ||
173 | 0xF0000000-0xF001FFFF 128K IMMR 64K used for dual port memory, | ||
174 | 64K for 8260 registers | ||
175 | |||
176 | |||
177 | Logical addresses used by the Linux kernel: | ||
178 | ------------------------------------------- | ||
179 | |||
180 | 0xF0000000-0xFFFFFFFF 256M BAT0 (IMMR: dual port RAM, registers) | ||
181 | 0xE0000000-0xEFFFFFFF 256M BAT1 (I/O space for custom boards) | ||
182 | 0xC0000000-0xCFFFFFFF 256M BAT2 (RAM) | ||
183 | 0xD0000000-0xDFFFFFFF 256M BAT3 (if RAM > 256MByte) | ||
184 | |||
185 | |||
186 | EST SBC8260 Linux mapping: | ||
187 | -------------------------- | ||
188 | |||
189 | DBAT0, IBAT0, cache inhibited: | ||
190 | |||
191 | Chip | ||
192 | Memory Sel Use | ||
193 | --------------------- --- --------------------------------- | ||
194 | 0xF0000000-0xF001FFFF n/a IMMR: dual port RAM, registers | ||
195 | |||
196 | DBAT1, IBAT1, cache inhibited: | ||
197 | |||
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 1d2a772506cf..928a79ceb7aa 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt | |||
@@ -58,6 +58,8 @@ Table of Contents | |||
58 | o) Xilinx IP cores | 58 | o) Xilinx IP cores |
59 | p) Freescale Synchronous Serial Interface | 59 | p) Freescale Synchronous Serial Interface |
60 | q) USB EHCI controllers | 60 | q) USB EHCI controllers |
61 | r) MDIO on GPIOs | ||
62 | s) SPI busses | ||
61 | 63 | ||
62 | VII - Marvell Discovery mv64[345]6x System Controller chips | 64 | VII - Marvell Discovery mv64[345]6x System Controller chips |
63 | 1) The /system-controller node | 65 | 1) The /system-controller node |
@@ -88,10 +90,12 @@ Table of Contents | |||
88 | 3) OpenPIC Interrupt Controllers | 90 | 3) OpenPIC Interrupt Controllers |
89 | 4) ISA Interrupt Controllers | 91 | 4) ISA Interrupt Controllers |
90 | 92 | ||
91 | VIII - Specifying GPIO information for devices | 93 | IX - Specifying GPIO information for devices |
92 | 1) gpios property | 94 | 1) gpios property |
93 | 2) gpio-controller nodes | 95 | 2) gpio-controller nodes |
94 | 96 | ||
97 | X - Specifying device power management information (sleep property) | ||
98 | |||
95 | Appendix A - Sample SOC node for MPC8540 | 99 | Appendix A - Sample SOC node for MPC8540 |
96 | 100 | ||
97 | 101 | ||
@@ -704,7 +708,7 @@ device or bus to be described by the device tree. | |||
704 | In general, the format of an address for a device is defined by the | 708 | In general, the format of an address for a device is defined by the |
705 | parent bus type, based on the #address-cells and #size-cells | 709 | parent bus type, based on the #address-cells and #size-cells |
706 | properties. Note that the parent's parent definitions of #address-cells | 710 | properties. Note that the parent's parent definitions of #address-cells |
707 | and #size-cells are not inhereted so every node with children must specify | 711 | and #size-cells are not inherited so every node with children must specify |
708 | them. The kernel requires the root node to have those properties defining | 712 | them. The kernel requires the root node to have those properties defining |
709 | addresses format for devices directly mapped on the processor bus. | 713 | addresses format for devices directly mapped on the processor bus. |
710 | 714 | ||
@@ -1246,80 +1250,7 @@ descriptions for the SOC devices for which new nodes have been | |||
1246 | defined; this list will expand as more and more SOC-containing | 1250 | defined; this list will expand as more and more SOC-containing |
1247 | platforms are moved over to use the flattened-device-tree model. | 1251 | platforms are moved over to use the flattened-device-tree model. |
1248 | 1252 | ||
1249 | a) MDIO IO device | 1253 | a) PHY nodes |
1250 | |||
1251 | The MDIO is a bus to which the PHY devices are connected. For each | ||
1252 | device that exists on this bus, a child node should be created. See | ||
1253 | the definition of the PHY node below for an example of how to define | ||
1254 | a PHY. | ||
1255 | |||
1256 | Required properties: | ||
1257 | - reg : Offset and length of the register set for the device | ||
1258 | - compatible : Should define the compatible device type for the | ||
1259 | mdio. Currently, this is most likely to be "fsl,gianfar-mdio" | ||
1260 | |||
1261 | Example: | ||
1262 | |||
1263 | mdio@24520 { | ||
1264 | reg = <24520 20>; | ||
1265 | compatible = "fsl,gianfar-mdio"; | ||
1266 | |||
1267 | ethernet-phy@0 { | ||
1268 | ...... | ||
1269 | }; | ||
1270 | }; | ||
1271 | |||
1272 | |||
1273 | b) Gianfar-compatible ethernet nodes | ||
1274 | |||
1275 | Required properties: | ||
1276 | |||
1277 | - device_type : Should be "network" | ||
1278 | - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC" | ||
1279 | - compatible : Should be "gianfar" | ||
1280 | - reg : Offset and length of the register set for the device | ||
1281 | - mac-address : List of bytes representing the ethernet address of | ||
1282 | this controller | ||
1283 | - interrupts : <a b> where a is the interrupt number and b is a | ||
1284 | field that represents an encoding of the sense and level | ||
1285 | information for the interrupt. This should be encoded based on | ||
1286 | the information in section 2) depending on the type of interrupt | ||
1287 | controller you have. | ||
1288 | - interrupt-parent : the phandle for the interrupt controller that | ||
1289 | services interrupts for this device. | ||
1290 | - phy-handle : The phandle for the PHY connected to this ethernet | ||
1291 | controller. | ||
1292 | - fixed-link : <a b c d e> where a is emulated phy id - choose any, | ||
1293 | but unique to the all specified fixed-links, b is duplex - 0 half, | ||
1294 | 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no | ||
1295 | pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. | ||
1296 | |||
1297 | Recommended properties: | ||
1298 | |||
1299 | - phy-connection-type : a string naming the controller/PHY interface type, | ||
1300 | i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii", | ||
1301 | "tbi", or "rtbi". This property is only really needed if the connection | ||
1302 | is of type "rgmii-id", as all other connection types are detected by | ||
1303 | hardware. | ||
1304 | |||
1305 | |||
1306 | Example: | ||
1307 | |||
1308 | ethernet@24000 { | ||
1309 | #size-cells = <0>; | ||
1310 | device_type = "network"; | ||
1311 | model = "TSEC"; | ||
1312 | compatible = "gianfar"; | ||
1313 | reg = <24000 1000>; | ||
1314 | mac-address = [ 00 E0 0C 00 73 00 ]; | ||
1315 | interrupts = <d 3 e 3 12 3>; | ||
1316 | interrupt-parent = <40000>; | ||
1317 | phy-handle = <2452000> | ||
1318 | }; | ||
1319 | |||
1320 | |||
1321 | |||
1322 | c) PHY nodes | ||
1323 | 1254 | ||
1324 | Required properties: | 1255 | Required properties: |
1325 | 1256 | ||
@@ -1347,7 +1278,7 @@ platforms are moved over to use the flattened-device-tree model. | |||
1347 | }; | 1278 | }; |
1348 | 1279 | ||
1349 | 1280 | ||
1350 | d) Interrupt controllers | 1281 | b) Interrupt controllers |
1351 | 1282 | ||
1352 | Some SOC devices contain interrupt controllers that are different | 1283 | Some SOC devices contain interrupt controllers that are different |
1353 | from the standard Open PIC specification. The SOC device nodes for | 1284 | from the standard Open PIC specification. The SOC device nodes for |
@@ -1360,491 +1291,14 @@ platforms are moved over to use the flattened-device-tree model. | |||
1360 | 1291 | ||
1361 | pic@40000 { | 1292 | pic@40000 { |
1362 | linux,phandle = <40000>; | 1293 | linux,phandle = <40000>; |
1363 | clock-frequency = <0>; | ||
1364 | interrupt-controller; | 1294 | interrupt-controller; |
1365 | #address-cells = <0>; | 1295 | #address-cells = <0>; |
1366 | reg = <40000 40000>; | 1296 | reg = <40000 40000>; |
1367 | built-in; | ||
1368 | compatible = "chrp,open-pic"; | 1297 | compatible = "chrp,open-pic"; |
1369 | device_type = "open-pic"; | 1298 | device_type = "open-pic"; |
1370 | big-endian; | ||
1371 | }; | 1299 | }; |
1372 | 1300 | ||
1373 | 1301 | c) CFI or JEDEC memory-mapped NOR flash | |
1374 | e) I2C | ||
1375 | |||
1376 | Required properties : | ||
1377 | |||
1378 | - device_type : Should be "i2c" | ||
1379 | - reg : Offset and length of the register set for the device | ||
1380 | |||
1381 | Recommended properties : | ||
1382 | |||
1383 | - compatible : Should be "fsl-i2c" for parts compatible with | ||
1384 | Freescale I2C specifications. | ||
1385 | - interrupts : <a b> where a is the interrupt number and b is a | ||
1386 | field that represents an encoding of the sense and level | ||
1387 | information for the interrupt. This should be encoded based on | ||
1388 | the information in section 2) depending on the type of interrupt | ||
1389 | controller you have. | ||
1390 | - interrupt-parent : the phandle for the interrupt controller that | ||
1391 | services interrupts for this device. | ||
1392 | - dfsrr : boolean; if defined, indicates that this I2C device has | ||
1393 | a digital filter sampling rate register | ||
1394 | - fsl5200-clocking : boolean; if defined, indicated that this device | ||
1395 | uses the FSL 5200 clocking mechanism. | ||
1396 | |||
1397 | Example : | ||
1398 | |||
1399 | i2c@3000 { | ||
1400 | interrupt-parent = <40000>; | ||
1401 | interrupts = <1b 3>; | ||
1402 | reg = <3000 18>; | ||
1403 | device_type = "i2c"; | ||
1404 | compatible = "fsl-i2c"; | ||
1405 | dfsrr; | ||
1406 | }; | ||
1407 | |||
1408 | |||
1409 | f) Freescale SOC USB controllers | ||
1410 | |||
1411 | The device node for a USB controller that is part of a Freescale | ||
1412 | SOC is as described in the document "Open Firmware Recommended | ||
1413 | Practice : Universal Serial Bus" with the following modifications | ||
1414 | and additions : | ||
1415 | |||
1416 | Required properties : | ||
1417 | - compatible : Should be "fsl-usb2-mph" for multi port host USB | ||
1418 | controllers, or "fsl-usb2-dr" for dual role USB controllers | ||
1419 | - phy_type : For multi port host USB controllers, should be one of | ||
1420 | "ulpi", or "serial". For dual role USB controllers, should be | ||
1421 | one of "ulpi", "utmi", "utmi_wide", or "serial". | ||
1422 | - reg : Offset and length of the register set for the device | ||
1423 | - port0 : boolean; if defined, indicates port0 is connected for | ||
1424 | fsl-usb2-mph compatible controllers. Either this property or | ||
1425 | "port1" (or both) must be defined for "fsl-usb2-mph" compatible | ||
1426 | controllers. | ||
1427 | - port1 : boolean; if defined, indicates port1 is connected for | ||
1428 | fsl-usb2-mph compatible controllers. Either this property or | ||
1429 | "port0" (or both) must be defined for "fsl-usb2-mph" compatible | ||
1430 | controllers. | ||
1431 | - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible | ||
1432 | controllers. Can be "host", "peripheral", or "otg". Default to | ||
1433 | "host" if not defined for backward compatibility. | ||
1434 | |||
1435 | Recommended properties : | ||
1436 | - interrupts : <a b> where a is the interrupt number and b is a | ||
1437 | field that represents an encoding of the sense and level | ||
1438 | information for the interrupt. This should be encoded based on | ||
1439 | the information in section 2) depending on the type of interrupt | ||
1440 | controller you have. | ||
1441 | - interrupt-parent : the phandle for the interrupt controller that | ||
1442 | services interrupts for this device. | ||
1443 | |||
1444 | Example multi port host USB controller device node : | ||
1445 | usb@22000 { | ||
1446 | compatible = "fsl-usb2-mph"; | ||
1447 | reg = <22000 1000>; | ||
1448 | #address-cells = <1>; | ||
1449 | #size-cells = <0>; | ||
1450 | interrupt-parent = <700>; | ||
1451 | interrupts = <27 1>; | ||
1452 | phy_type = "ulpi"; | ||
1453 | port0; | ||
1454 | port1; | ||
1455 | }; | ||
1456 | |||
1457 | Example dual role USB controller device node : | ||
1458 | usb@23000 { | ||
1459 | compatible = "fsl-usb2-dr"; | ||
1460 | reg = <23000 1000>; | ||
1461 | #address-cells = <1>; | ||
1462 | #size-cells = <0>; | ||
1463 | interrupt-parent = <700>; | ||
1464 | interrupts = <26 1>; | ||
1465 | dr_mode = "otg"; | ||
1466 | phy = "ulpi"; | ||
1467 | }; | ||
1468 | |||
1469 | |||
1470 | g) Freescale SOC SEC Security Engines | ||
1471 | |||
1472 | Required properties: | ||
1473 | |||
1474 | - device_type : Should be "crypto" | ||
1475 | - model : Model of the device. Should be "SEC1" or "SEC2" | ||
1476 | - compatible : Should be "talitos" | ||
1477 | - reg : Offset and length of the register set for the device | ||
1478 | - interrupts : <a b> where a is the interrupt number and b is a | ||
1479 | field that represents an encoding of the sense and level | ||
1480 | information for the interrupt. This should be encoded based on | ||
1481 | the information in section 2) depending on the type of interrupt | ||
1482 | controller you have. | ||
1483 | - interrupt-parent : the phandle for the interrupt controller that | ||
1484 | services interrupts for this device. | ||
1485 | - num-channels : An integer representing the number of channels | ||
1486 | available. | ||
1487 | - channel-fifo-len : An integer representing the number of | ||
1488 | descriptor pointers each channel fetch fifo can hold. | ||
1489 | - exec-units-mask : The bitmask representing what execution units | ||
1490 | (EUs) are available. It's a single 32-bit cell. EU information | ||
1491 | should be encoded following the SEC's Descriptor Header Dword | ||
1492 | EU_SEL0 field documentation, i.e. as follows: | ||
1493 | |||
1494 | bit 0 = reserved - should be 0 | ||
1495 | bit 1 = set if SEC has the ARC4 EU (AFEU) | ||
1496 | bit 2 = set if SEC has the DES/3DES EU (DEU) | ||
1497 | bit 3 = set if SEC has the message digest EU (MDEU) | ||
1498 | bit 4 = set if SEC has the random number generator EU (RNG) | ||
1499 | bit 5 = set if SEC has the public key EU (PKEU) | ||
1500 | bit 6 = set if SEC has the AES EU (AESU) | ||
1501 | bit 7 = set if SEC has the Kasumi EU (KEU) | ||
1502 | |||
1503 | bits 8 through 31 are reserved for future SEC EUs. | ||
1504 | |||
1505 | - descriptor-types-mask : The bitmask representing what descriptors | ||
1506 | are available. It's a single 32-bit cell. Descriptor type | ||
1507 | information should be encoded following the SEC's Descriptor | ||
1508 | Header Dword DESC_TYPE field documentation, i.e. as follows: | ||
1509 | |||
1510 | bit 0 = set if SEC supports the aesu_ctr_nonsnoop desc. type | ||
1511 | bit 1 = set if SEC supports the ipsec_esp descriptor type | ||
1512 | bit 2 = set if SEC supports the common_nonsnoop desc. type | ||
1513 | bit 3 = set if SEC supports the 802.11i AES ccmp desc. type | ||
1514 | bit 4 = set if SEC supports the hmac_snoop_no_afeu desc. type | ||
1515 | bit 5 = set if SEC supports the srtp descriptor type | ||
1516 | bit 6 = set if SEC supports the non_hmac_snoop_no_afeu desc.type | ||
1517 | bit 7 = set if SEC supports the pkeu_assemble descriptor type | ||
1518 | bit 8 = set if SEC supports the aesu_key_expand_output desc.type | ||
1519 | bit 9 = set if SEC supports the pkeu_ptmul descriptor type | ||
1520 | bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type | ||
1521 | bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type | ||
1522 | |||
1523 | ..and so on and so forth. | ||
1524 | |||
1525 | Example: | ||
1526 | |||
1527 | /* MPC8548E */ | ||
1528 | crypto@30000 { | ||
1529 | device_type = "crypto"; | ||
1530 | model = "SEC2"; | ||
1531 | compatible = "talitos"; | ||
1532 | reg = <30000 10000>; | ||
1533 | interrupts = <1d 3>; | ||
1534 | interrupt-parent = <40000>; | ||
1535 | num-channels = <4>; | ||
1536 | channel-fifo-len = <18>; | ||
1537 | exec-units-mask = <000000fe>; | ||
1538 | descriptor-types-mask = <012b0ebf>; | ||
1539 | }; | ||
1540 | |||
1541 | h) Board Control and Status (BCSR) | ||
1542 | |||
1543 | Required properties: | ||
1544 | |||
1545 | - device_type : Should be "board-control" | ||
1546 | - reg : Offset and length of the register set for the device | ||
1547 | |||
1548 | Example: | ||
1549 | |||
1550 | bcsr@f8000000 { | ||
1551 | device_type = "board-control"; | ||
1552 | reg = <f8000000 8000>; | ||
1553 | }; | ||
1554 | |||
1555 | i) Freescale QUICC Engine module (QE) | ||
1556 | This represents qe module that is installed on PowerQUICC II Pro. | ||
1557 | |||
1558 | NOTE: This is an interim binding; it should be updated to fit | ||
1559 | in with the CPM binding later in this document. | ||
1560 | |||
1561 | Basically, it is a bus of devices, that could act more or less | ||
1562 | as a complete entity (UCC, USB etc ). All of them should be siblings on | ||
1563 | the "root" qe node, using the common properties from there. | ||
1564 | The description below applies to the qe of MPC8360 and | ||
1565 | more nodes and properties would be extended in the future. | ||
1566 | |||
1567 | i) Root QE device | ||
1568 | |||
1569 | Required properties: | ||
1570 | - compatible : should be "fsl,qe"; | ||
1571 | - model : precise model of the QE, Can be "QE", "CPM", or "CPM2" | ||
1572 | - reg : offset and length of the device registers. | ||
1573 | - bus-frequency : the clock frequency for QUICC Engine. | ||
1574 | |||
1575 | Recommended properties | ||
1576 | - brg-frequency : the internal clock source frequency for baud-rate | ||
1577 | generators in Hz. | ||
1578 | |||
1579 | Example: | ||
1580 | qe@e0100000 { | ||
1581 | #address-cells = <1>; | ||
1582 | #size-cells = <1>; | ||
1583 | #interrupt-cells = <2>; | ||
1584 | compatible = "fsl,qe"; | ||
1585 | ranges = <0 e0100000 00100000>; | ||
1586 | reg = <e0100000 480>; | ||
1587 | brg-frequency = <0>; | ||
1588 | bus-frequency = <179A7B00>; | ||
1589 | } | ||
1590 | |||
1591 | |||
1592 | ii) SPI (Serial Peripheral Interface) | ||
1593 | |||
1594 | Required properties: | ||
1595 | - cell-index : SPI controller index. | ||
1596 | - compatible : should be "fsl,spi". | ||
1597 | - mode : the SPI operation mode, it can be "cpu" or "cpu-qe". | ||
1598 | - reg : Offset and length of the register set for the device | ||
1599 | - interrupts : <a b> where a is the interrupt number and b is a | ||
1600 | field that represents an encoding of the sense and level | ||
1601 | information for the interrupt. This should be encoded based on | ||
1602 | the information in section 2) depending on the type of interrupt | ||
1603 | controller you have. | ||
1604 | - interrupt-parent : the phandle for the interrupt controller that | ||
1605 | services interrupts for this device. | ||
1606 | |||
1607 | Example: | ||
1608 | spi@4c0 { | ||
1609 | cell-index = <0>; | ||
1610 | compatible = "fsl,spi"; | ||
1611 | reg = <4c0 40>; | ||
1612 | interrupts = <82 0>; | ||
1613 | interrupt-parent = <700>; | ||
1614 | mode = "cpu"; | ||
1615 | }; | ||
1616 | |||
1617 | |||
1618 | iii) USB (Universal Serial Bus Controller) | ||
1619 | |||
1620 | Required properties: | ||
1621 | - compatible : could be "qe_udc" or "fhci-hcd". | ||
1622 | - mode : the could be "host" or "slave". | ||
1623 | - reg : Offset and length of the register set for the device | ||
1624 | - interrupts : <a b> where a is the interrupt number and b is a | ||
1625 | field that represents an encoding of the sense and level | ||
1626 | information for the interrupt. This should be encoded based on | ||
1627 | the information in section 2) depending on the type of interrupt | ||
1628 | controller you have. | ||
1629 | - interrupt-parent : the phandle for the interrupt controller that | ||
1630 | services interrupts for this device. | ||
1631 | |||
1632 | Example(slave): | ||
1633 | usb@6c0 { | ||
1634 | compatible = "qe_udc"; | ||
1635 | reg = <6c0 40>; | ||
1636 | interrupts = <8b 0>; | ||
1637 | interrupt-parent = <700>; | ||
1638 | mode = "slave"; | ||
1639 | }; | ||
1640 | |||
1641 | |||
1642 | iv) UCC (Unified Communications Controllers) | ||
1643 | |||
1644 | Required properties: | ||
1645 | - device_type : should be "network", "hldc", "uart", "transparent" | ||
1646 | "bisync", "atm", or "serial". | ||
1647 | - compatible : could be "ucc_geth" or "fsl_atm" and so on. | ||
1648 | - cell-index : the ucc number(1-8), corresponding to UCCx in UM. | ||
1649 | - reg : Offset and length of the register set for the device | ||
1650 | - interrupts : <a b> where a is the interrupt number and b is a | ||
1651 | field that represents an encoding of the sense and level | ||
1652 | information for the interrupt. This should be encoded based on | ||
1653 | the information in section 2) depending on the type of interrupt | ||
1654 | controller you have. | ||
1655 | - interrupt-parent : the phandle for the interrupt controller that | ||
1656 | services interrupts for this device. | ||
1657 | - pio-handle : The phandle for the Parallel I/O port configuration. | ||
1658 | - port-number : for UART drivers, the port number to use, between 0 and 3. | ||
1659 | This usually corresponds to the /dev/ttyQE device, e.g. <0> = /dev/ttyQE0. | ||
1660 | The port number is added to the minor number of the device. Unlike the | ||
1661 | CPM UART driver, the port-number is required for the QE UART driver. | ||
1662 | - soft-uart : for UART drivers, if specified this means the QE UART device | ||
1663 | driver should use "Soft-UART" mode, which is needed on some SOCs that have | ||
1664 | broken UART hardware. Soft-UART is provided via a microcode upload. | ||
1665 | - rx-clock-name: the UCC receive clock source | ||
1666 | "none": clock source is disabled | ||
1667 | "brg1" through "brg16": clock source is BRG1-BRG16, respectively | ||
1668 | "clk1" through "clk24": clock source is CLK1-CLK24, respectively | ||
1669 | - tx-clock-name: the UCC transmit clock source | ||
1670 | "none": clock source is disabled | ||
1671 | "brg1" through "brg16": clock source is BRG1-BRG16, respectively | ||
1672 | "clk1" through "clk24": clock source is CLK1-CLK24, respectively | ||
1673 | The following two properties are deprecated. rx-clock has been replaced | ||
1674 | with rx-clock-name, and tx-clock has been replaced with tx-clock-name. | ||
1675 | Drivers that currently use the deprecated properties should continue to | ||
1676 | do so, in order to support older device trees, but they should be updated | ||
1677 | to check for the new properties first. | ||
1678 | - rx-clock : represents the UCC receive clock source. | ||
1679 | 0x00 : clock source is disabled; | ||
1680 | 0x1~0x10 : clock source is BRG1~BRG16 respectively; | ||
1681 | 0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively. | ||
1682 | - tx-clock: represents the UCC transmit clock source; | ||
1683 | 0x00 : clock source is disabled; | ||
1684 | 0x1~0x10 : clock source is BRG1~BRG16 respectively; | ||
1685 | 0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively. | ||
1686 | |||
1687 | Required properties for network device_type: | ||
1688 | - mac-address : list of bytes representing the ethernet address. | ||
1689 | - phy-handle : The phandle for the PHY connected to this controller. | ||
1690 | |||
1691 | Recommended properties: | ||
1692 | - phy-connection-type : a string naming the controller/PHY interface type, | ||
1693 | i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal | ||
1694 | Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only), | ||
1695 | "tbi", or "rtbi". | ||
1696 | |||
1697 | Example: | ||
1698 | ucc@2000 { | ||
1699 | device_type = "network"; | ||
1700 | compatible = "ucc_geth"; | ||
1701 | cell-index = <1>; | ||
1702 | reg = <2000 200>; | ||
1703 | interrupts = <a0 0>; | ||
1704 | interrupt-parent = <700>; | ||
1705 | mac-address = [ 00 04 9f 00 23 23 ]; | ||
1706 | rx-clock = "none"; | ||
1707 | tx-clock = "clk9"; | ||
1708 | phy-handle = <212000>; | ||
1709 | phy-connection-type = "gmii"; | ||
1710 | pio-handle = <140001>; | ||
1711 | }; | ||
1712 | |||
1713 | |||
1714 | v) Parallel I/O Ports | ||
1715 | |||
1716 | This node configures Parallel I/O ports for CPUs with QE support. | ||
1717 | The node should reside in the "soc" node of the tree. For each | ||
1718 | device that using parallel I/O ports, a child node should be created. | ||
1719 | See the definition of the Pin configuration nodes below for more | ||
1720 | information. | ||
1721 | |||
1722 | Required properties: | ||
1723 | - device_type : should be "par_io". | ||
1724 | - reg : offset to the register set and its length. | ||
1725 | - num-ports : number of Parallel I/O ports | ||
1726 | |||
1727 | Example: | ||
1728 | par_io@1400 { | ||
1729 | reg = <1400 100>; | ||
1730 | #address-cells = <1>; | ||
1731 | #size-cells = <0>; | ||
1732 | device_type = "par_io"; | ||
1733 | num-ports = <7>; | ||
1734 | ucc_pin@01 { | ||
1735 | ...... | ||
1736 | }; | ||
1737 | |||
1738 | |||
1739 | vi) Pin configuration nodes | ||
1740 | |||
1741 | Required properties: | ||
1742 | - linux,phandle : phandle of this node; likely referenced by a QE | ||
1743 | device. | ||
1744 | - pio-map : array of pin configurations. Each pin is defined by 6 | ||
1745 | integers. The six numbers are respectively: port, pin, dir, | ||
1746 | open_drain, assignment, has_irq. | ||
1747 | - port : port number of the pin; 0-6 represent port A-G in UM. | ||
1748 | - pin : pin number in the port. | ||
1749 | - dir : direction of the pin, should encode as follows: | ||
1750 | |||
1751 | 0 = The pin is disabled | ||
1752 | 1 = The pin is an output | ||
1753 | 2 = The pin is an input | ||
1754 | 3 = The pin is I/O | ||
1755 | |||
1756 | - open_drain : indicates the pin is normal or wired-OR: | ||
1757 | |||
1758 | 0 = The pin is actively driven as an output | ||
1759 | 1 = The pin is an open-drain driver. As an output, the pin is | ||
1760 | driven active-low, otherwise it is three-stated. | ||
1761 | |||
1762 | - assignment : function number of the pin according to the Pin Assignment | ||
1763 | tables in User Manual. Each pin can have up to 4 possible functions in | ||
1764 | QE and two options for CPM. | ||
1765 | - has_irq : indicates if the pin is used as source of external | ||
1766 | interrupts. | ||
1767 | |||
1768 | Example: | ||
1769 | ucc_pin@01 { | ||
1770 | linux,phandle = <140001>; | ||
1771 | pio-map = < | ||
1772 | /* port pin dir open_drain assignment has_irq */ | ||
1773 | 0 3 1 0 1 0 /* TxD0 */ | ||
1774 | 0 4 1 0 1 0 /* TxD1 */ | ||
1775 | 0 5 1 0 1 0 /* TxD2 */ | ||
1776 | 0 6 1 0 1 0 /* TxD3 */ | ||
1777 | 1 6 1 0 3 0 /* TxD4 */ | ||
1778 | 1 7 1 0 1 0 /* TxD5 */ | ||
1779 | 1 9 1 0 2 0 /* TxD6 */ | ||
1780 | 1 a 1 0 2 0 /* TxD7 */ | ||
1781 | 0 9 2 0 1 0 /* RxD0 */ | ||
1782 | 0 a 2 0 1 0 /* RxD1 */ | ||
1783 | 0 b 2 0 1 0 /* RxD2 */ | ||
1784 | 0 c 2 0 1 0 /* RxD3 */ | ||
1785 | 0 d 2 0 1 0 /* RxD4 */ | ||
1786 | 1 1 2 0 2 0 /* RxD5 */ | ||
1787 | 1 0 2 0 2 0 /* RxD6 */ | ||
1788 | 1 4 2 0 2 0 /* RxD7 */ | ||
1789 | 0 7 1 0 1 0 /* TX_EN */ | ||
1790 | 0 8 1 0 1 0 /* TX_ER */ | ||
1791 | 0 f 2 0 1 0 /* RX_DV */ | ||
1792 | 0 10 2 0 1 0 /* RX_ER */ | ||
1793 | 0 0 2 0 1 0 /* RX_CLK */ | ||
1794 | 2 9 1 0 3 0 /* GTX_CLK - CLK10 */ | ||
1795 | 2 8 2 0 1 0>; /* GTX125 - CLK9 */ | ||
1796 | }; | ||
1797 | |||
1798 | vii) Multi-User RAM (MURAM) | ||
1799 | |||
1800 | Required properties: | ||
1801 | - compatible : should be "fsl,qe-muram", "fsl,cpm-muram". | ||
1802 | - mode : the could be "host" or "slave". | ||
1803 | - ranges : Should be defined as specified in 1) to describe the | ||
1804 | translation of MURAM addresses. | ||
1805 | - data-only : sub-node which defines the address area under MURAM | ||
1806 | bus that can be allocated as data/parameter | ||
1807 | |||
1808 | Example: | ||
1809 | |||
1810 | muram@10000 { | ||
1811 | compatible = "fsl,qe-muram", "fsl,cpm-muram"; | ||
1812 | ranges = <0 00010000 0000c000>; | ||
1813 | |||
1814 | data-only@0{ | ||
1815 | compatible = "fsl,qe-muram-data", | ||
1816 | "fsl,cpm-muram-data"; | ||
1817 | reg = <0 c000>; | ||
1818 | }; | ||
1819 | }; | ||
1820 | |||
1821 | viii) Uploaded QE firmware | ||
1822 | |||
1823 | If a new firwmare has been uploaded to the QE (usually by the | ||
1824 | boot loader), then a 'firmware' child node should be added to the QE | ||
1825 | node. This node provides information on the uploaded firmware that | ||
1826 | device drivers may need. | ||
1827 | |||
1828 | Required properties: | ||
1829 | - id: The string name of the firmware. This is taken from the 'id' | ||
1830 | member of the qe_firmware structure of the uploaded firmware. | ||
1831 | Device drivers can search this string to determine if the | ||
1832 | firmware they want is already present. | ||
1833 | - extended-modes: The Extended Modes bitfield, taken from the | ||
1834 | firmware binary. It is a 64-bit number represented | ||
1835 | as an array of two 32-bit numbers. | ||
1836 | - virtual-traps: The virtual traps, taken from the firmware binary. | ||
1837 | It is an array of 8 32-bit numbers. | ||
1838 | |||
1839 | Example: | ||
1840 | |||
1841 | firmware { | ||
1842 | id = "Soft-UART"; | ||
1843 | extended-modes = <0 0>; | ||
1844 | virtual-traps = <0 0 0 0 0 0 0 0>; | ||
1845 | } | ||
1846 | |||
1847 | j) CFI or JEDEC memory-mapped NOR flash | ||
1848 | 1302 | ||
1849 | Flash chips (Memory Technology Devices) are often used for solid state | 1303 | Flash chips (Memory Technology Devices) are often used for solid state |
1850 | file systems on embedded devices. | 1304 | file systems on embedded devices. |
@@ -1908,268 +1362,7 @@ platforms are moved over to use the flattened-device-tree model. | |||
1908 | }; | 1362 | }; |
1909 | }; | 1363 | }; |
1910 | 1364 | ||
1911 | k) Global Utilities Block | 1365 | d) 4xx/Axon EMAC ethernet nodes |
1912 | |||
1913 | The global utilities block controls power management, I/O device | ||
1914 | enabling, power-on-reset configuration monitoring, general-purpose | ||
1915 | I/O signal configuration, alternate function selection for multiplexed | ||
1916 | signals, and clock control. | ||
1917 | |||
1918 | Required properties: | ||
1919 | |||
1920 | - compatible : Should define the compatible device type for | ||
1921 | global-utilities. | ||
1922 | - reg : Offset and length of the register set for the device. | ||
1923 | |||
1924 | Recommended properties: | ||
1925 | |||
1926 | - fsl,has-rstcr : Indicates that the global utilities register set | ||
1927 | contains a functioning "reset control register" (i.e. the board | ||
1928 | is wired to reset upon setting the HRESET_REQ bit in this register). | ||
1929 | |||
1930 | Example: | ||
1931 | |||
1932 | global-utilities@e0000 { /* global utilities block */ | ||
1933 | compatible = "fsl,mpc8548-guts"; | ||
1934 | reg = <e0000 1000>; | ||
1935 | fsl,has-rstcr; | ||
1936 | }; | ||
1937 | |||
1938 | l) Freescale Communications Processor Module | ||
1939 | |||
1940 | NOTE: This is an interim binding, and will likely change slightly, | ||
1941 | as more devices are supported. The QE bindings especially are | ||
1942 | incomplete. | ||
1943 | |||
1944 | i) Root CPM node | ||
1945 | |||
1946 | Properties: | ||
1947 | - compatible : "fsl,cpm1", "fsl,cpm2", or "fsl,qe". | ||
1948 | - reg : A 48-byte region beginning with CPCR. | ||
1949 | |||
1950 | Example: | ||
1951 | cpm@119c0 { | ||
1952 | #address-cells = <1>; | ||
1953 | #size-cells = <1>; | ||
1954 | #interrupt-cells = <2>; | ||
1955 | compatible = "fsl,mpc8272-cpm", "fsl,cpm2"; | ||
1956 | reg = <119c0 30>; | ||
1957 | } | ||
1958 | |||
1959 | ii) Properties common to mulitple CPM/QE devices | ||
1960 | |||
1961 | - fsl,cpm-command : This value is ORed with the opcode and command flag | ||
1962 | to specify the device on which a CPM command operates. | ||
1963 | |||
1964 | - fsl,cpm-brg : Indicates which baud rate generator the device | ||
1965 | is associated with. If absent, an unused BRG | ||
1966 | should be dynamically allocated. If zero, the | ||
1967 | device uses an external clock rather than a BRG. | ||
1968 | |||
1969 | - reg : Unless otherwise specified, the first resource represents the | ||
1970 | scc/fcc/ucc registers, and the second represents the device's | ||
1971 | parameter RAM region (if it has one). | ||
1972 | |||
1973 | iii) Serial | ||
1974 | |||
1975 | Currently defined compatibles: | ||
1976 | - fsl,cpm1-smc-uart | ||
1977 | - fsl,cpm2-smc-uart | ||
1978 | - fsl,cpm1-scc-uart | ||
1979 | - fsl,cpm2-scc-uart | ||
1980 | - fsl,qe-uart | ||
1981 | |||
1982 | Example: | ||
1983 | |||
1984 | serial@11a00 { | ||
1985 | device_type = "serial"; | ||
1986 | compatible = "fsl,mpc8272-scc-uart", | ||
1987 | "fsl,cpm2-scc-uart"; | ||
1988 | reg = <11a00 20 8000 100>; | ||
1989 | interrupts = <28 8>; | ||
1990 | interrupt-parent = <&PIC>; | ||
1991 | fsl,cpm-brg = <1>; | ||
1992 | fsl,cpm-command = <00800000>; | ||
1993 | }; | ||
1994 | |||
1995 | iii) Network | ||
1996 | |||
1997 | Currently defined compatibles: | ||
1998 | - fsl,cpm1-scc-enet | ||
1999 | - fsl,cpm2-scc-enet | ||
2000 | - fsl,cpm1-fec-enet | ||
2001 | - fsl,cpm2-fcc-enet (third resource is GFEMR) | ||
2002 | - fsl,qe-enet | ||
2003 | |||
2004 | Example: | ||
2005 | |||
2006 | ethernet@11300 { | ||
2007 | device_type = "network"; | ||
2008 | compatible = "fsl,mpc8272-fcc-enet", | ||
2009 | "fsl,cpm2-fcc-enet"; | ||
2010 | reg = <11300 20 8400 100 11390 1>; | ||
2011 | local-mac-address = [ 00 00 00 00 00 00 ]; | ||
2012 | interrupts = <20 8>; | ||
2013 | interrupt-parent = <&PIC>; | ||
2014 | phy-handle = <&PHY0>; | ||
2015 | fsl,cpm-command = <12000300>; | ||
2016 | }; | ||
2017 | |||
2018 | iv) MDIO | ||
2019 | |||
2020 | Currently defined compatibles: | ||
2021 | fsl,pq1-fec-mdio (reg is same as first resource of FEC device) | ||
2022 | fsl,cpm2-mdio-bitbang (reg is port C registers) | ||
2023 | |||
2024 | Properties for fsl,cpm2-mdio-bitbang: | ||
2025 | fsl,mdio-pin : pin of port C controlling mdio data | ||
2026 | fsl,mdc-pin : pin of port C controlling mdio clock | ||
2027 | |||
2028 | Example: | ||
2029 | |||
2030 | mdio@10d40 { | ||
2031 | device_type = "mdio"; | ||
2032 | compatible = "fsl,mpc8272ads-mdio-bitbang", | ||
2033 | "fsl,mpc8272-mdio-bitbang", | ||
2034 | "fsl,cpm2-mdio-bitbang"; | ||
2035 | reg = <10d40 14>; | ||
2036 | #address-cells = <1>; | ||
2037 | #size-cells = <0>; | ||
2038 | fsl,mdio-pin = <12>; | ||
2039 | fsl,mdc-pin = <13>; | ||
2040 | }; | ||
2041 | |||
2042 | v) Baud Rate Generators | ||
2043 | |||
2044 | Currently defined compatibles: | ||
2045 | fsl,cpm-brg | ||
2046 | fsl,cpm1-brg | ||
2047 | fsl,cpm2-brg | ||
2048 | |||
2049 | Properties: | ||
2050 | - reg : There may be an arbitrary number of reg resources; BRG | ||
2051 | numbers are assigned to these in order. | ||
2052 | - clock-frequency : Specifies the base frequency driving | ||
2053 | the BRG. | ||
2054 | |||
2055 | Example: | ||
2056 | |||
2057 | brg@119f0 { | ||
2058 | compatible = "fsl,mpc8272-brg", | ||
2059 | "fsl,cpm2-brg", | ||
2060 | "fsl,cpm-brg"; | ||
2061 | reg = <119f0 10 115f0 10>; | ||
2062 | clock-frequency = <d#25000000>; | ||
2063 | }; | ||
2064 | |||
2065 | vi) Interrupt Controllers | ||
2066 | |||
2067 | Currently defined compatibles: | ||
2068 | - fsl,cpm1-pic | ||
2069 | - only one interrupt cell | ||
2070 | - fsl,pq1-pic | ||
2071 | - fsl,cpm2-pic | ||
2072 | - second interrupt cell is level/sense: | ||
2073 | - 2 is falling edge | ||
2074 | - 8 is active low | ||
2075 | |||
2076 | Example: | ||
2077 | |||
2078 | interrupt-controller@10c00 { | ||
2079 | #interrupt-cells = <2>; | ||
2080 | interrupt-controller; | ||
2081 | reg = <10c00 80>; | ||
2082 | compatible = "mpc8272-pic", "fsl,cpm2-pic"; | ||
2083 | }; | ||
2084 | |||
2085 | vii) USB (Universal Serial Bus Controller) | ||
2086 | |||
2087 | Properties: | ||
2088 | - compatible : "fsl,cpm1-usb", "fsl,cpm2-usb", "fsl,qe-usb" | ||
2089 | |||
2090 | Example: | ||
2091 | usb@11bc0 { | ||
2092 | #address-cells = <1>; | ||
2093 | #size-cells = <0>; | ||
2094 | compatible = "fsl,cpm2-usb"; | ||
2095 | reg = <11b60 18 8b00 100>; | ||
2096 | interrupts = <b 8>; | ||
2097 | interrupt-parent = <&PIC>; | ||
2098 | fsl,cpm-command = <2e600000>; | ||
2099 | }; | ||
2100 | |||
2101 | viii) Multi-User RAM (MURAM) | ||
2102 | |||
2103 | The multi-user/dual-ported RAM is expressed as a bus under the CPM node. | ||
2104 | |||
2105 | Ranges must be set up subject to the following restrictions: | ||
2106 | |||
2107 | - Children's reg nodes must be offsets from the start of all muram, even | ||
2108 | if the user-data area does not begin at zero. | ||
2109 | - If multiple range entries are used, the difference between the parent | ||
2110 | address and the child address must be the same in all, so that a single | ||
2111 | mapping can cover them all while maintaining the ability to determine | ||
2112 | CPM-side offsets with pointer subtraction. It is recommended that | ||
2113 | multiple range entries not be used. | ||
2114 | - A child address of zero must be translatable, even if no reg resources | ||
2115 | contain it. | ||
2116 | |||
2117 | A child "data" node must exist, compatible with "fsl,cpm-muram-data", to | ||
2118 | indicate the portion of muram that is usable by the OS for arbitrary | ||
2119 | purposes. The data node may have an arbitrary number of reg resources, | ||
2120 | all of which contribute to the allocatable muram pool. | ||
2121 | |||
2122 | Example, based on mpc8272: | ||
2123 | |||
2124 | muram@0 { | ||
2125 | #address-cells = <1>; | ||
2126 | #size-cells = <1>; | ||
2127 | ranges = <0 0 10000>; | ||
2128 | |||
2129 | data@0 { | ||
2130 | compatible = "fsl,cpm-muram-data"; | ||
2131 | reg = <0 2000 9800 800>; | ||
2132 | }; | ||
2133 | }; | ||
2134 | |||
2135 | m) Chipselect/Local Bus | ||
2136 | |||
2137 | Properties: | ||
2138 | - name : Should be localbus | ||
2139 | - #address-cells : Should be either two or three. The first cell is the | ||
2140 | chipselect number, and the remaining cells are the | ||
2141 | offset into the chipselect. | ||
2142 | - #size-cells : Either one or two, depending on how large each chipselect | ||
2143 | can be. | ||
2144 | - ranges : Each range corresponds to a single chipselect, and cover | ||
2145 | the entire access window as configured. | ||
2146 | |||
2147 | Example: | ||
2148 | localbus@f0010100 { | ||
2149 | compatible = "fsl,mpc8272-localbus", | ||
2150 | "fsl,pq2-localbus"; | ||
2151 | #address-cells = <2>; | ||
2152 | #size-cells = <1>; | ||
2153 | reg = <f0010100 40>; | ||
2154 | |||
2155 | ranges = <0 0 fe000000 02000000 | ||
2156 | 1 0 f4500000 00008000>; | ||
2157 | |||
2158 | flash@0,0 { | ||
2159 | compatible = "jedec-flash"; | ||
2160 | reg = <0 0 2000000>; | ||
2161 | bank-width = <4>; | ||
2162 | device-width = <1>; | ||
2163 | }; | ||
2164 | |||
2165 | board-control@1,0 { | ||
2166 | reg = <1 0 20>; | ||
2167 | compatible = "fsl,mpc8272ads-bcsr"; | ||
2168 | }; | ||
2169 | }; | ||
2170 | |||
2171 | |||
2172 | n) 4xx/Axon EMAC ethernet nodes | ||
2173 | 1366 | ||
2174 | The EMAC ethernet controller in IBM and AMCC 4xx chips, and also | 1367 | The EMAC ethernet controller in IBM and AMCC 4xx chips, and also |
2175 | the Axon bridge. To operate this needs to interact with a ths | 1368 | the Axon bridge. To operate this needs to interact with a ths |
@@ -2317,7 +1510,7 @@ platforms are moved over to use the flattened-device-tree model. | |||
2317 | available. | 1510 | available. |
2318 | For Axon: 0x0000012a | 1511 | For Axon: 0x0000012a |
2319 | 1512 | ||
2320 | o) Xilinx IP cores | 1513 | e) Xilinx IP cores |
2321 | 1514 | ||
2322 | The Xilinx EDK toolchain ships with a set of IP cores (devices) for use | 1515 | The Xilinx EDK toolchain ships with a set of IP cores (devices) for use |
2323 | in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range | 1516 | in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range |
@@ -2584,7 +1777,7 @@ platforms are moved over to use the flattened-device-tree model. | |||
2584 | 1777 | ||
2585 | Xilinx uartlite devices are simple fixed speed serial ports. | 1778 | Xilinx uartlite devices are simple fixed speed serial ports. |
2586 | 1779 | ||
2587 | Requred properties: | 1780 | Required properties: |
2588 | - current-speed : Baud rate of uartlite | 1781 | - current-speed : Baud rate of uartlite |
2589 | 1782 | ||
2590 | v) Xilinx hwicap | 1783 | v) Xilinx hwicap |
@@ -2606,211 +1799,12 @@ platforms are moved over to use the flattened-device-tree model. | |||
2606 | Xilinx UART 16550 devices are very similar to the NS16550 but with | 1799 | Xilinx UART 16550 devices are very similar to the NS16550 but with |
2607 | different register spacing and an offset from the base address. | 1800 | different register spacing and an offset from the base address. |
2608 | 1801 | ||
2609 | Requred properties: | 1802 | Required properties: |
2610 | - clock-frequency : Frequency of the clock input | 1803 | - clock-frequency : Frequency of the clock input |
2611 | - reg-offset : A value of 3 is required | 1804 | - reg-offset : A value of 3 is required |
2612 | - reg-shift : A value of 2 is required | 1805 | - reg-shift : A value of 2 is required |
2613 | 1806 | ||
2614 | 1807 | f) USB EHCI controllers | |
2615 | p) Freescale Synchronous Serial Interface | ||
2616 | |||
2617 | The SSI is a serial device that communicates with audio codecs. It can | ||
2618 | be programmed in AC97, I2S, left-justified, or right-justified modes. | ||
2619 | |||
2620 | Required properties: | ||
2621 | - compatible : compatible list, containing "fsl,ssi" | ||
2622 | - cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on | ||
2623 | - reg : offset and length of the register set for the device | ||
2624 | - interrupts : <a b> where a is the interrupt number and b is a | ||
2625 | field that represents an encoding of the sense and | ||
2626 | level information for the interrupt. This should be | ||
2627 | encoded based on the information in section 2) | ||
2628 | depending on the type of interrupt controller you | ||
2629 | have. | ||
2630 | - interrupt-parent : the phandle for the interrupt controller that | ||
2631 | services interrupts for this device. | ||
2632 | - fsl,mode : the operating mode for the SSI interface | ||
2633 | "i2s-slave" - I2S mode, SSI is clock slave | ||
2634 | "i2s-master" - I2S mode, SSI is clock master | ||
2635 | "lj-slave" - left-justified mode, SSI is clock slave | ||
2636 | "lj-master" - l.j. mode, SSI is clock master | ||
2637 | "rj-slave" - right-justified mode, SSI is clock slave | ||
2638 | "rj-master" - r.j., SSI is clock master | ||
2639 | "ac97-slave" - AC97 mode, SSI is clock slave | ||
2640 | "ac97-master" - AC97 mode, SSI is clock master | ||
2641 | |||
2642 | Optional properties: | ||
2643 | - codec-handle : phandle to a 'codec' node that defines an audio | ||
2644 | codec connected to this SSI. This node is typically | ||
2645 | a child of an I2C or other control node. | ||
2646 | |||
2647 | Child 'codec' node required properties: | ||
2648 | - compatible : compatible list, contains the name of the codec | ||
2649 | |||
2650 | Child 'codec' node optional properties: | ||
2651 | - clock-frequency : The frequency of the input clock, which typically | ||
2652 | comes from an on-board dedicated oscillator. | ||
2653 | |||
2654 | * Freescale 83xx DMA Controller | ||
2655 | |||
2656 | Freescale PowerPC 83xx have on chip general purpose DMA controllers. | ||
2657 | |||
2658 | Required properties: | ||
2659 | |||
2660 | - compatible : compatible list, contains 2 entries, first is | ||
2661 | "fsl,CHIP-dma", where CHIP is the processor | ||
2662 | (mpc8349, mpc8360, etc.) and the second is | ||
2663 | "fsl,elo-dma" | ||
2664 | - reg : <registers mapping for DMA general status reg> | ||
2665 | - ranges : Should be defined as specified in 1) to describe the | ||
2666 | DMA controller channels. | ||
2667 | - cell-index : controller index. 0 for controller @ 0x8100 | ||
2668 | - interrupts : <interrupt mapping for DMA IRQ> | ||
2669 | - interrupt-parent : optional, if needed for interrupt mapping | ||
2670 | |||
2671 | |||
2672 | - DMA channel nodes: | ||
2673 | - compatible : compatible list, contains 2 entries, first is | ||
2674 | "fsl,CHIP-dma-channel", where CHIP is the processor | ||
2675 | (mpc8349, mpc8350, etc.) and the second is | ||
2676 | "fsl,elo-dma-channel" | ||
2677 | - reg : <registers mapping for channel> | ||
2678 | - cell-index : dma channel index starts at 0. | ||
2679 | |||
2680 | Optional properties: | ||
2681 | - interrupts : <interrupt mapping for DMA channel IRQ> | ||
2682 | (on 83xx this is expected to be identical to | ||
2683 | the interrupts property of the parent node) | ||
2684 | - interrupt-parent : optional, if needed for interrupt mapping | ||
2685 | |||
2686 | Example: | ||
2687 | dma@82a8 { | ||
2688 | #address-cells = <1>; | ||
2689 | #size-cells = <1>; | ||
2690 | compatible = "fsl,mpc8349-dma", "fsl,elo-dma"; | ||
2691 | reg = <82a8 4>; | ||
2692 | ranges = <0 8100 1a4>; | ||
2693 | interrupt-parent = <&ipic>; | ||
2694 | interrupts = <47 8>; | ||
2695 | cell-index = <0>; | ||
2696 | dma-channel@0 { | ||
2697 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | ||
2698 | cell-index = <0>; | ||
2699 | reg = <0 80>; | ||
2700 | }; | ||
2701 | dma-channel@80 { | ||
2702 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | ||
2703 | cell-index = <1>; | ||
2704 | reg = <80 80>; | ||
2705 | }; | ||
2706 | dma-channel@100 { | ||
2707 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | ||
2708 | cell-index = <2>; | ||
2709 | reg = <100 80>; | ||
2710 | }; | ||
2711 | dma-channel@180 { | ||
2712 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | ||
2713 | cell-index = <3>; | ||
2714 | reg = <180 80>; | ||
2715 | }; | ||
2716 | }; | ||
2717 | |||
2718 | * Freescale 85xx/86xx DMA Controller | ||
2719 | |||
2720 | Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers. | ||
2721 | |||
2722 | Required properties: | ||
2723 | |||
2724 | - compatible : compatible list, contains 2 entries, first is | ||
2725 | "fsl,CHIP-dma", where CHIP is the processor | ||
2726 | (mpc8540, mpc8540, etc.) and the second is | ||
2727 | "fsl,eloplus-dma" | ||
2728 | - reg : <registers mapping for DMA general status reg> | ||
2729 | - cell-index : controller index. 0 for controller @ 0x21000, | ||
2730 | 1 for controller @ 0xc000 | ||
2731 | - ranges : Should be defined as specified in 1) to describe the | ||
2732 | DMA controller channels. | ||
2733 | |||
2734 | - DMA channel nodes: | ||
2735 | - compatible : compatible list, contains 2 entries, first is | ||
2736 | "fsl,CHIP-dma-channel", where CHIP is the processor | ||
2737 | (mpc8540, mpc8560, etc.) and the second is | ||
2738 | "fsl,eloplus-dma-channel" | ||
2739 | - cell-index : dma channel index starts at 0. | ||
2740 | - reg : <registers mapping for channel> | ||
2741 | - interrupts : <interrupt mapping for DMA channel IRQ> | ||
2742 | - interrupt-parent : optional, if needed for interrupt mapping | ||
2743 | |||
2744 | Example: | ||
2745 | dma@21300 { | ||
2746 | #address-cells = <1>; | ||
2747 | #size-cells = <1>; | ||
2748 | compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma"; | ||
2749 | reg = <21300 4>; | ||
2750 | ranges = <0 21100 200>; | ||
2751 | cell-index = <0>; | ||
2752 | dma-channel@0 { | ||
2753 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | ||
2754 | reg = <0 80>; | ||
2755 | cell-index = <0>; | ||
2756 | interrupt-parent = <&mpic>; | ||
2757 | interrupts = <14 2>; | ||
2758 | }; | ||
2759 | dma-channel@80 { | ||
2760 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | ||
2761 | reg = <80 80>; | ||
2762 | cell-index = <1>; | ||
2763 | interrupt-parent = <&mpic>; | ||
2764 | interrupts = <15 2>; | ||
2765 | }; | ||
2766 | dma-channel@100 { | ||
2767 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | ||
2768 | reg = <100 80>; | ||
2769 | cell-index = <2>; | ||
2770 | interrupt-parent = <&mpic>; | ||
2771 | interrupts = <16 2>; | ||
2772 | }; | ||
2773 | dma-channel@180 { | ||
2774 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | ||
2775 | reg = <180 80>; | ||
2776 | cell-index = <3>; | ||
2777 | interrupt-parent = <&mpic>; | ||
2778 | interrupts = <17 2>; | ||
2779 | }; | ||
2780 | }; | ||
2781 | |||
2782 | * Freescale 8xxx/3.0 Gb/s SATA nodes | ||
2783 | |||
2784 | SATA nodes are defined to describe on-chip Serial ATA controllers. | ||
2785 | Each SATA port should have its own node. | ||
2786 | |||
2787 | Required properties: | ||
2788 | - compatible : compatible list, contains 2 entries, first is | ||
2789 | "fsl,CHIP-sata", where CHIP is the processor | ||
2790 | (mpc8315, mpc8379, etc.) and the second is | ||
2791 | "fsl,pq-sata" | ||
2792 | - interrupts : <interrupt mapping for SATA IRQ> | ||
2793 | - cell-index : controller index. | ||
2794 | 1 for controller @ 0x18000 | ||
2795 | 2 for controller @ 0x19000 | ||
2796 | 3 for controller @ 0x1a000 | ||
2797 | 4 for controller @ 0x1b000 | ||
2798 | |||
2799 | Optional properties: | ||
2800 | - interrupt-parent : optional, if needed for interrupt mapping | ||
2801 | - reg : <registers mapping> | ||
2802 | |||
2803 | Example: | ||
2804 | |||
2805 | sata@18000 { | ||
2806 | compatible = "fsl,mpc8379-sata", "fsl,pq-sata"; | ||
2807 | reg = <0x18000 0x1000>; | ||
2808 | cell-index = <1>; | ||
2809 | interrupts = <2c 8>; | ||
2810 | interrupt-parent = < &ipic >; | ||
2811 | }; | ||
2812 | |||
2813 | q) USB EHCI controllers | ||
2814 | 1808 | ||
2815 | Required properties: | 1809 | Required properties: |
2816 | - compatible : should be "usb-ehci". | 1810 | - compatible : should be "usb-ehci". |
@@ -2870,6 +1864,82 @@ platforms are moved over to use the flattened-device-tree model. | |||
2870 | reg = <0xe8000000 32>; | 1864 | reg = <0xe8000000 32>; |
2871 | }; | 1865 | }; |
2872 | 1866 | ||
1867 | r) MDIO on GPIOs | ||
1868 | |||
1869 | Currently defined compatibles: | ||
1870 | - virtual,gpio-mdio | ||
1871 | |||
1872 | MDC and MDIO lines connected to GPIO controllers are listed in the | ||
1873 | gpios property as described in section VIII.1 in the following order: | ||
1874 | |||
1875 | MDC, MDIO. | ||
1876 | |||
1877 | Example: | ||
1878 | |||
1879 | mdio { | ||
1880 | compatible = "virtual,mdio-gpio"; | ||
1881 | #address-cells = <1>; | ||
1882 | #size-cells = <0>; | ||
1883 | gpios = <&qe_pio_a 11 | ||
1884 | &qe_pio_c 6>; | ||
1885 | }; | ||
1886 | |||
1887 | s) SPI (Serial Peripheral Interface) busses | ||
1888 | |||
1889 | SPI busses can be described with a node for the SPI master device | ||
1890 | and a set of child nodes for each SPI slave on the bus. For this | ||
1891 | discussion, it is assumed that the system's SPI controller is in | ||
1892 | SPI master mode. This binding does not describe SPI controllers | ||
1893 | in slave mode. | ||
1894 | |||
1895 | The SPI master node requires the following properties: | ||
1896 | - #address-cells - number of cells required to define a chip select | ||
1897 | address on the SPI bus. | ||
1898 | - #size-cells - should be zero. | ||
1899 | - compatible - name of SPI bus controller following generic names | ||
1900 | recommended practice. | ||
1901 | No other properties are required in the SPI bus node. It is assumed | ||
1902 | that a driver for an SPI bus device will understand that it is an SPI bus. | ||
1903 | However, the binding does not attempt to define the specific method for | ||
1904 | assigning chip select numbers. Since SPI chip select configuration is | ||
1905 | flexible and non-standardized, it is left out of this binding with the | ||
1906 | assumption that board specific platform code will be used to manage | ||
1907 | chip selects. Individual drivers can define additional properties to | ||
1908 | support describing the chip select layout. | ||
1909 | |||
1910 | SPI slave nodes must be children of the SPI master node and can | ||
1911 | contain the following properties. | ||
1912 | - reg - (required) chip select address of device. | ||
1913 | - compatible - (required) name of SPI device following generic names | ||
1914 | recommended practice | ||
1915 | - spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz | ||
1916 | - spi-cpol - (optional) Empty property indicating device requires | ||
1917 | inverse clock polarity (CPOL) mode | ||
1918 | - spi-cpha - (optional) Empty property indicating device requires | ||
1919 | shifted clock phase (CPHA) mode | ||
1920 | |||
1921 | SPI example for an MPC5200 SPI bus: | ||
1922 | spi@f00 { | ||
1923 | #address-cells = <1>; | ||
1924 | #size-cells = <0>; | ||
1925 | compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi"; | ||
1926 | reg = <0xf00 0x20>; | ||
1927 | interrupts = <2 13 0 2 14 0>; | ||
1928 | interrupt-parent = <&mpc5200_pic>; | ||
1929 | |||
1930 | ethernet-switch@0 { | ||
1931 | compatible = "micrel,ks8995m"; | ||
1932 | spi-max-frequency = <1000000>; | ||
1933 | reg = <0>; | ||
1934 | }; | ||
1935 | |||
1936 | codec@1 { | ||
1937 | compatible = "ti,tlv320aic26"; | ||
1938 | spi-max-frequency = <100000>; | ||
1939 | reg = <1>; | ||
1940 | }; | ||
1941 | }; | ||
1942 | |||
2873 | VII - Marvell Discovery mv64[345]6x System Controller chips | 1943 | VII - Marvell Discovery mv64[345]6x System Controller chips |
2874 | =========================================================== | 1944 | =========================================================== |
2875 | 1945 | ||
@@ -2883,7 +1953,7 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. | |||
2883 | 1) The /system-controller node | 1953 | 1) The /system-controller node |
2884 | 1954 | ||
2885 | This node is used to represent the system-controller and must be | 1955 | This node is used to represent the system-controller and must be |
2886 | present when the system uses a system contller chip. The top-level | 1956 | present when the system uses a system controller chip. The top-level |
2887 | system-controller node contains information that is global to all | 1957 | system-controller node contains information that is global to all |
2888 | devices within the system controller chip. The node name begins | 1958 | devices within the system controller chip. The node name begins |
2889 | with "system-controller" followed by the unit address, which is | 1959 | with "system-controller" followed by the unit address, which is |
@@ -3477,8 +2547,8 @@ encodings listed below: | |||
3477 | 2 = high to low edge sensitive type enabled | 2547 | 2 = high to low edge sensitive type enabled |
3478 | 3 = low to high edge sensitive type enabled | 2548 | 3 = low to high edge sensitive type enabled |
3479 | 2549 | ||
3480 | VIII - Specifying GPIO information for devices | 2550 | IX - Specifying GPIO information for devices |
3481 | ============================================== | 2551 | ============================================ |
3482 | 2552 | ||
3483 | 1) gpios property | 2553 | 1) gpios property |
3484 | ----------------- | 2554 | ----------------- |
@@ -3526,119 +2596,151 @@ Example of two SOC GPIO banks defined as gpio-controller nodes: | |||
3526 | gpio-controller; | 2596 | gpio-controller; |
3527 | }; | 2597 | }; |
3528 | 2598 | ||
2599 | X - Specifying Device Power Management Information (sleep property) | ||
2600 | =================================================================== | ||
2601 | |||
2602 | Devices on SOCs often have mechanisms for placing devices into low-power | ||
2603 | states that are decoupled from the devices' own register blocks. Sometimes, | ||
2604 | this information is more complicated than a cell-index property can | ||
2605 | reasonably describe. Thus, each device controlled in such a manner | ||
2606 | may contain a "sleep" property which describes these connections. | ||
2607 | |||
2608 | The sleep property consists of one or more sleep resources, each of | ||
2609 | which consists of a phandle to a sleep controller, followed by a | ||
2610 | controller-specific sleep specifier of zero or more cells. | ||
2611 | |||
2612 | The semantics of what type of low power modes are possible are defined | ||
2613 | by the sleep controller. Some examples of the types of low power modes | ||
2614 | that may be supported are: | ||
2615 | |||
2616 | - Dynamic: The device may be disabled or enabled at any time. | ||
2617 | - System Suspend: The device may request to be disabled or remain | ||
2618 | awake during system suspend, but will not be disabled until then. | ||
2619 | - Permanent: The device is disabled permanently (until the next hard | ||
2620 | reset). | ||
2621 | |||
2622 | Some devices may share a clock domain with each other, such that they should | ||
2623 | only be suspended when none of the devices are in use. Where reasonable, | ||
2624 | such nodes should be placed on a virtual bus, where the bus has the sleep | ||
2625 | property. If the clock domain is shared among devices that cannot be | ||
2626 | reasonably grouped in this manner, then create a virtual sleep controller | ||
2627 | (similar to an interrupt nexus, except that defining a standardized | ||
2628 | sleep-map should wait until its necessity is demonstrated). | ||
2629 | |||
3529 | Appendix A - Sample SOC node for MPC8540 | 2630 | Appendix A - Sample SOC node for MPC8540 |
3530 | ======================================== | 2631 | ======================================== |
3531 | 2632 | ||
3532 | Note that the #address-cells and #size-cells for the SoC node | 2633 | soc@e0000000 { |
3533 | in this example have been explicitly listed; these are likely | ||
3534 | not necessary as they are usually the same as the root node. | ||
3535 | |||
3536 | soc8540@e0000000 { | ||
3537 | #address-cells = <1>; | 2634 | #address-cells = <1>; |
3538 | #size-cells = <1>; | 2635 | #size-cells = <1>; |
3539 | #interrupt-cells = <2>; | 2636 | compatible = "fsl,mpc8540-ccsr", "simple-bus"; |
3540 | device_type = "soc"; | 2637 | device_type = "soc"; |
3541 | ranges = <00000000 e0000000 00100000> | 2638 | ranges = <0x00000000 0xe0000000 0x00100000> |
3542 | reg = <e0000000 00003000>; | ||
3543 | bus-frequency = <0>; | 2639 | bus-frequency = <0>; |
3544 | 2640 | interrupt-parent = <&pic>; | |
3545 | mdio@24520 { | ||
3546 | reg = <24520 20>; | ||
3547 | device_type = "mdio"; | ||
3548 | compatible = "gianfar"; | ||
3549 | |||
3550 | ethernet-phy@0 { | ||
3551 | linux,phandle = <2452000> | ||
3552 | interrupt-parent = <40000>; | ||
3553 | interrupts = <35 1>; | ||
3554 | reg = <0>; | ||
3555 | device_type = "ethernet-phy"; | ||
3556 | }; | ||
3557 | |||
3558 | ethernet-phy@1 { | ||
3559 | linux,phandle = <2452001> | ||
3560 | interrupt-parent = <40000>; | ||
3561 | interrupts = <35 1>; | ||
3562 | reg = <1>; | ||
3563 | device_type = "ethernet-phy"; | ||
3564 | }; | ||
3565 | |||
3566 | ethernet-phy@3 { | ||
3567 | linux,phandle = <2452002> | ||
3568 | interrupt-parent = <40000>; | ||
3569 | interrupts = <35 1>; | ||
3570 | reg = <3>; | ||
3571 | device_type = "ethernet-phy"; | ||
3572 | }; | ||
3573 | |||
3574 | }; | ||
3575 | 2641 | ||
3576 | ethernet@24000 { | 2642 | ethernet@24000 { |
3577 | #size-cells = <0>; | 2643 | #address-cells = <1>; |
2644 | #size-cells = <1>; | ||
3578 | device_type = "network"; | 2645 | device_type = "network"; |
3579 | model = "TSEC"; | 2646 | model = "TSEC"; |
3580 | compatible = "gianfar"; | 2647 | compatible = "gianfar", "simple-bus"; |
3581 | reg = <24000 1000>; | 2648 | reg = <0x24000 0x1000>; |
3582 | mac-address = [ 00 E0 0C 00 73 00 ]; | 2649 | local-mac-address = [ 00 E0 0C 00 73 00 ]; |
3583 | interrupts = <d 3 e 3 12 3>; | 2650 | interrupts = <29 2 30 2 34 2>; |
3584 | interrupt-parent = <40000>; | 2651 | phy-handle = <&phy0>; |
3585 | phy-handle = <2452000>; | 2652 | sleep = <&pmc 00000080>; |
2653 | ranges; | ||
2654 | |||
2655 | mdio@24520 { | ||
2656 | reg = <0x24520 0x20>; | ||
2657 | compatible = "fsl,gianfar-mdio"; | ||
2658 | |||
2659 | phy0: ethernet-phy@0 { | ||
2660 | interrupts = <5 1>; | ||
2661 | reg = <0>; | ||
2662 | device_type = "ethernet-phy"; | ||
2663 | }; | ||
2664 | |||
2665 | phy1: ethernet-phy@1 { | ||
2666 | interrupts = <5 1>; | ||
2667 | reg = <1>; | ||
2668 | device_type = "ethernet-phy"; | ||
2669 | }; | ||
2670 | |||
2671 | phy3: ethernet-phy@3 { | ||
2672 | interrupts = <7 1>; | ||
2673 | reg = <3>; | ||
2674 | device_type = "ethernet-phy"; | ||
2675 | }; | ||
2676 | }; | ||
3586 | }; | 2677 | }; |
3587 | 2678 | ||
3588 | ethernet@25000 { | 2679 | ethernet@25000 { |
3589 | #address-cells = <1>; | ||
3590 | #size-cells = <0>; | ||
3591 | device_type = "network"; | 2680 | device_type = "network"; |
3592 | model = "TSEC"; | 2681 | model = "TSEC"; |
3593 | compatible = "gianfar"; | 2682 | compatible = "gianfar"; |
3594 | reg = <25000 1000>; | 2683 | reg = <0x25000 0x1000>; |
3595 | mac-address = [ 00 E0 0C 00 73 01 ]; | 2684 | local-mac-address = [ 00 E0 0C 00 73 01 ]; |
3596 | interrupts = <13 3 14 3 18 3>; | 2685 | interrupts = <13 2 14 2 18 2>; |
3597 | interrupt-parent = <40000>; | 2686 | phy-handle = <&phy1>; |
3598 | phy-handle = <2452001>; | 2687 | sleep = <&pmc 00000040>; |
3599 | }; | 2688 | }; |
3600 | 2689 | ||
3601 | ethernet@26000 { | 2690 | ethernet@26000 { |
3602 | #address-cells = <1>; | ||
3603 | #size-cells = <0>; | ||
3604 | device_type = "network"; | 2691 | device_type = "network"; |
3605 | model = "FEC"; | 2692 | model = "FEC"; |
3606 | compatible = "gianfar"; | 2693 | compatible = "gianfar"; |
3607 | reg = <26000 1000>; | 2694 | reg = <0x26000 0x1000>; |
3608 | mac-address = [ 00 E0 0C 00 73 02 ]; | 2695 | local-mac-address = [ 00 E0 0C 00 73 02 ]; |
3609 | interrupts = <19 3>; | 2696 | interrupts = <41 2>; |
3610 | interrupt-parent = <40000>; | 2697 | phy-handle = <&phy3>; |
3611 | phy-handle = <2452002>; | 2698 | sleep = <&pmc 00000020>; |
3612 | }; | 2699 | }; |
3613 | 2700 | ||
3614 | serial@4500 { | 2701 | serial@4500 { |
3615 | device_type = "serial"; | 2702 | #address-cells = <1>; |
3616 | compatible = "ns16550"; | 2703 | #size-cells = <1>; |
3617 | reg = <4500 100>; | 2704 | compatible = "fsl,mpc8540-duart", "simple-bus"; |
3618 | clock-frequency = <0>; | 2705 | sleep = <&pmc 00000002>; |
3619 | interrupts = <1a 3>; | 2706 | ranges; |
3620 | interrupt-parent = <40000>; | 2707 | |
2708 | serial@4500 { | ||
2709 | device_type = "serial"; | ||
2710 | compatible = "ns16550"; | ||
2711 | reg = <0x4500 0x100>; | ||
2712 | clock-frequency = <0>; | ||
2713 | interrupts = <42 2>; | ||
2714 | }; | ||
2715 | |||
2716 | serial@4600 { | ||
2717 | device_type = "serial"; | ||
2718 | compatible = "ns16550"; | ||
2719 | reg = <0x4600 0x100>; | ||
2720 | clock-frequency = <0>; | ||
2721 | interrupts = <42 2>; | ||
2722 | }; | ||
3621 | }; | 2723 | }; |
3622 | 2724 | ||
3623 | pic@40000 { | 2725 | pic: pic@40000 { |
3624 | linux,phandle = <40000>; | ||
3625 | clock-frequency = <0>; | ||
3626 | interrupt-controller; | 2726 | interrupt-controller; |
3627 | #address-cells = <0>; | 2727 | #address-cells = <0>; |
3628 | reg = <40000 40000>; | 2728 | #interrupt-cells = <2>; |
3629 | built-in; | 2729 | reg = <0x40000 0x40000>; |
3630 | compatible = "chrp,open-pic"; | 2730 | compatible = "chrp,open-pic"; |
3631 | device_type = "open-pic"; | 2731 | device_type = "open-pic"; |
3632 | big-endian; | ||
3633 | }; | 2732 | }; |
3634 | 2733 | ||
3635 | i2c@3000 { | 2734 | i2c@3000 { |
3636 | interrupt-parent = <40000>; | 2735 | interrupts = <43 2>; |
3637 | interrupts = <1b 3>; | 2736 | reg = <0x3000 0x100>; |
3638 | reg = <3000 18>; | ||
3639 | device_type = "i2c"; | ||
3640 | compatible = "fsl-i2c"; | 2737 | compatible = "fsl-i2c"; |
3641 | dfsrr; | 2738 | dfsrr; |
2739 | sleep = <&pmc 00000004>; | ||
3642 | }; | 2740 | }; |
3643 | 2741 | ||
2742 | pmc: power@e0070 { | ||
2743 | compatible = "fsl,mpc8540-pmc", "fsl,mpc8548-pmc"; | ||
2744 | reg = <0xe0070 0x20>; | ||
2745 | }; | ||
3644 | }; | 2746 | }; |
diff --git a/Documentation/powerpc/bootwrapper.txt b/Documentation/powerpc/bootwrapper.txt new file mode 100644 index 000000000000..d60fced5e1cc --- /dev/null +++ b/Documentation/powerpc/bootwrapper.txt | |||
@@ -0,0 +1,141 @@ | |||
1 | The PowerPC boot wrapper | ||
2 | ------------------------ | ||
3 | Copyright (C) Secret Lab Technologies Ltd. | ||
4 | |||
5 | PowerPC image targets compresses and wraps the kernel image (vmlinux) with | ||
6 | a boot wrapper to make it usable by the system firmware. There is no | ||
7 | standard PowerPC firmware interface, so the boot wrapper is designed to | ||
8 | be adaptable for each kind of image that needs to be built. | ||
9 | |||
10 | The boot wrapper can be found in the arch/powerpc/boot/ directory. The | ||
11 | Makefile in that directory has targets for all the available image types. | ||
12 | The different image types are used to support all of the various firmware | ||
13 | interfaces found on PowerPC platforms. OpenFirmware is the most commonly | ||
14 | used firmware type on general purpose PowerPC systems from Apple, IBM and | ||
15 | others. U-Boot is typically found on embedded PowerPC hardware, but there | ||
16 | are a handful of other firmware implementations which are also popular. Each | ||
17 | firmware interface requires a different image format. | ||
18 | |||
19 | The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and | ||
20 | it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target | ||
21 | image. The details of the build system is discussed in the next section. | ||
22 | Currently, the following image format targets exist: | ||
23 | |||
24 | cuImage.%: Backwards compatible uImage for older version of | ||
25 | U-Boot (for versions that don't understand the device | ||
26 | tree). This image embeds a device tree blob inside | ||
27 | the image. The boot wrapper, kernel and device tree | ||
28 | are all embedded inside the U-Boot uImage file format | ||
29 | with boot wrapper code that extracts data from the old | ||
30 | bd_info structure and loads the data into the device | ||
31 | tree before jumping into the kernel. | ||
32 | Because of the series of #ifdefs found in the | ||
33 | bd_info structure used in the old U-Boot interfaces, | ||
34 | cuImages are platform specific. Each specific | ||
35 | U-Boot platform has a different platform init file | ||
36 | which populates the embedded device tree with data | ||
37 | from the platform specific bd_info file. The platform | ||
38 | specific cuImage platform init code can be found in | ||
39 | arch/powerpc/boot/cuboot.*.c. Selection of the correct | ||
40 | cuImage init code for a specific board can be found in | ||
41 | the wrapper structure. | ||
42 | dtbImage.%: Similar to zImage, except device tree blob is embedded | ||
43 | inside the image instead of provided by firmware. The | ||
44 | output image file can be either an elf file or a flat | ||
45 | binary depending on the platform. | ||
46 | dtbImages are used on systems which do not have an | ||
47 | interface for passing a device tree directly. | ||
48 | dtbImages are similar to simpleImages except that | ||
49 | dtbImages have platform specific code for extracting | ||
50 | data from the board firmware, but simpleImages do not | ||
51 | talk to the firmware at all. | ||
52 | PlayStation 3 support uses dtbImage. So do Embedded | ||
53 | Planet boards using the PlanetCore firmware. Board | ||
54 | specific initialization code is typically found in a | ||
55 | file named arch/powerpc/boot/<platform>.c; but this | ||
56 | can be overridden by the wrapper script. | ||
57 | simpleImage.%: Firmware independent compressed image that does not | ||
58 | depend on any particular firmware interface and embeds | ||
59 | a device tree blob. This image is a flat binary that | ||
60 | can be loaded to any location in RAM and jumped to. | ||
61 | Firmware cannot pass any configuration data to the | ||
62 | kernel with this image type and it depends entirely on | ||
63 | the embedded device tree for all information. | ||
64 | The simpleImage is useful for booting systems with | ||
65 | an unknown firmware interface or for booting from | ||
66 | a debugger when no firmware is present (such as on | ||
67 | the Xilinx Virtex platform). The only assumption that | ||
68 | simpleImage makes is that RAM is correctly initialized | ||
69 | and that the MMU is either off or has RAM mapped to | ||
70 | base address 0. | ||
71 | simpleImage also supports inserting special platform | ||
72 | specific initialization code to the start of the bootup | ||
73 | sequence. The virtex405 platform uses this feature to | ||
74 | ensure that the cache is invalidated before caching | ||
75 | is enabled. Platform specific initialization code is | ||
76 | added as part of the wrapper script and is keyed on | ||
77 | the image target name. For example, all | ||
78 | simpleImage.virtex405-* targets will add the | ||
79 | virtex405-head.S initialization code (This also means | ||
80 | that the dts file for virtex405 targets should be | ||
81 | named (virtex405-<board>.dts). Search the wrapper | ||
82 | script for 'virtex405' and see the file | ||
83 | arch/powerpc/boot/virtex405-head.S for details. | ||
84 | treeImage.%; Image format for used with OpenBIOS firmware found | ||
85 | on some ppc4xx hardware. This image embeds a device | ||
86 | tree blob inside the image. | ||
87 | uImage: Native image format used by U-Boot. The uImage target | ||
88 | does not add any boot code. It just wraps a compressed | ||
89 | vmlinux in the uImage data structure. This image | ||
90 | requires a version of U-Boot that is able to pass | ||
91 | a device tree to the kernel at boot. If using an older | ||
92 | version of U-Boot, then you need to use a cuImage | ||
93 | instead. | ||
94 | zImage.%: Image format which does not embed a device tree. | ||
95 | Used by OpenFirmware and other firmware interfaces | ||
96 | which are able to supply a device tree. This image | ||
97 | expects firmware to provide the device tree at boot. | ||
98 | Typically, if you have general purpose PowerPC | ||
99 | hardware then you want this image format. | ||
100 | |||
101 | Image types which embed a device tree blob (simpleImage, dtbImage, treeImage, | ||
102 | and cuImage) all generate the device tree blob from a file in the | ||
103 | arch/powerpc/boot/dts/ directory. The Makefile selects the correct device | ||
104 | tree source based on the name of the target. Therefore, if the kernel is | ||
105 | built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the | ||
106 | build system will use arch/powerpc/boot/dts/walnut.dts to build | ||
107 | treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build | ||
108 | the simpleImage.virtex405-ml403. | ||
109 | |||
110 | Two special targets called 'zImage' and 'zImage.initrd' also exist. These | ||
111 | targets build all the default images as selected by the kernel configuration. | ||
112 | Default images are selected by the boot wrapper Makefile | ||
113 | (arch/powerpc/boot/Makefile) by adding targets to the $image-y variable. Look | ||
114 | at the Makefile to see which default image targets are available. | ||
115 | |||
116 | How it is built | ||
117 | --------------- | ||
118 | arch/powerpc is designed to support multiplatform kernels, which means | ||
119 | that a single vmlinux image can be booted on many different target boards. | ||
120 | It also means that the boot wrapper must be able to wrap for many kinds of | ||
121 | images on a single build. The design decision was made to not use any | ||
122 | conditional compilation code (#ifdef, etc) in the boot wrapper source code. | ||
123 | All of the boot wrapper pieces are buildable at any time regardless of the | ||
124 | kernel configuration. Building all the wrapper bits on every kernel build | ||
125 | also ensures that obscure parts of the wrapper are at the very least compile | ||
126 | tested in a large variety of environments. | ||
127 | |||
128 | The wrapper is adapted for different image types at link time by linking in | ||
129 | just the wrapper bits that are appropriate for the image type. The 'wrapper | ||
130 | script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and | ||
131 | is responsible for selecting the correct wrapper bits for the image type. | ||
132 | The arguments are well documented in the script's comment block, so they | ||
133 | are not repeated here. However, it is worth mentioning that the script | ||
134 | uses the -p (platform) argument as the main method of deciding which wrapper | ||
135 | bits to compile in. Look for the large 'case "$platform" in' block in the | ||
136 | middle of the script. This is also the place where platform specific fixups | ||
137 | can be selected by changing the link order. | ||
138 | |||
139 | In particular, care should be taken when working with cuImages. cuImage | ||
140 | wrapper bits are very board specific and care should be taken to make sure | ||
141 | the target you are trying to build is supported by the wrapper bits. | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt b/Documentation/powerpc/dts-bindings/fsl/board.txt new file mode 100644 index 000000000000..74ae6f1cd2d6 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/board.txt | |||
@@ -0,0 +1,29 @@ | |||
1 | * Board Control and Status (BCSR) | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | - device_type : Should be "board-control" | ||
6 | - reg : Offset and length of the register set for the device | ||
7 | |||
8 | Example: | ||
9 | |||
10 | bcsr@f8000000 { | ||
11 | device_type = "board-control"; | ||
12 | reg = <f8000000 8000>; | ||
13 | }; | ||
14 | |||
15 | * Freescale on board FPGA | ||
16 | |||
17 | This is the memory-mapped registers for on board FPGA. | ||
18 | |||
19 | Required properities: | ||
20 | - compatible : should be "fsl,fpga-pixis". | ||
21 | - reg : should contain the address and the lenght of the FPPGA register | ||
22 | set. | ||
23 | |||
24 | Example (MPC8610HPCD): | ||
25 | |||
26 | board-control@e8000000 { | ||
27 | compatible = "fsl,fpga-pixis"; | ||
28 | reg = <0xe8000000 32>; | ||
29 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt new file mode 100644 index 000000000000..088fc471e03a --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt | |||
@@ -0,0 +1,67 @@ | |||
1 | * Freescale Communications Processor Module | ||
2 | |||
3 | NOTE: This is an interim binding, and will likely change slightly, | ||
4 | as more devices are supported. The QE bindings especially are | ||
5 | incomplete. | ||
6 | |||
7 | * Root CPM node | ||
8 | |||
9 | Properties: | ||
10 | - compatible : "fsl,cpm1", "fsl,cpm2", or "fsl,qe". | ||
11 | - reg : A 48-byte region beginning with CPCR. | ||
12 | |||
13 | Example: | ||
14 | cpm@119c0 { | ||
15 | #address-cells = <1>; | ||
16 | #size-cells = <1>; | ||
17 | #interrupt-cells = <2>; | ||
18 | compatible = "fsl,mpc8272-cpm", "fsl,cpm2"; | ||
19 | reg = <119c0 30>; | ||
20 | } | ||
21 | |||
22 | * Properties common to mulitple CPM/QE devices | ||
23 | |||
24 | - fsl,cpm-command : This value is ORed with the opcode and command flag | ||
25 | to specify the device on which a CPM command operates. | ||
26 | |||
27 | - fsl,cpm-brg : Indicates which baud rate generator the device | ||
28 | is associated with. If absent, an unused BRG | ||
29 | should be dynamically allocated. If zero, the | ||
30 | device uses an external clock rather than a BRG. | ||
31 | |||
32 | - reg : Unless otherwise specified, the first resource represents the | ||
33 | scc/fcc/ucc registers, and the second represents the device's | ||
34 | parameter RAM region (if it has one). | ||
35 | |||
36 | * Multi-User RAM (MURAM) | ||
37 | |||
38 | The multi-user/dual-ported RAM is expressed as a bus under the CPM node. | ||
39 | |||
40 | Ranges must be set up subject to the following restrictions: | ||
41 | |||
42 | - Children's reg nodes must be offsets from the start of all muram, even | ||
43 | if the user-data area does not begin at zero. | ||
44 | - If multiple range entries are used, the difference between the parent | ||
45 | address and the child address must be the same in all, so that a single | ||
46 | mapping can cover them all while maintaining the ability to determine | ||
47 | CPM-side offsets with pointer subtraction. It is recommended that | ||
48 | multiple range entries not be used. | ||
49 | - A child address of zero must be translatable, even if no reg resources | ||
50 | contain it. | ||
51 | |||
52 | A child "data" node must exist, compatible with "fsl,cpm-muram-data", to | ||
53 | indicate the portion of muram that is usable by the OS for arbitrary | ||
54 | purposes. The data node may have an arbitrary number of reg resources, | ||
55 | all of which contribute to the allocatable muram pool. | ||
56 | |||
57 | Example, based on mpc8272: | ||
58 | muram@0 { | ||
59 | #address-cells = <1>; | ||
60 | #size-cells = <1>; | ||
61 | ranges = <0 0 10000>; | ||
62 | |||
63 | data@0 { | ||
64 | compatible = "fsl,cpm-muram-data"; | ||
65 | reg = <0 2000 9800 800>; | ||
66 | }; | ||
67 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt new file mode 100644 index 000000000000..4c7d45eaf025 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt | |||
@@ -0,0 +1,21 @@ | |||
1 | * Baud Rate Generators | ||
2 | |||
3 | Currently defined compatibles: | ||
4 | fsl,cpm-brg | ||
5 | fsl,cpm1-brg | ||
6 | fsl,cpm2-brg | ||
7 | |||
8 | Properties: | ||
9 | - reg : There may be an arbitrary number of reg resources; BRG | ||
10 | numbers are assigned to these in order. | ||
11 | - clock-frequency : Specifies the base frequency driving | ||
12 | the BRG. | ||
13 | |||
14 | Example: | ||
15 | brg@119f0 { | ||
16 | compatible = "fsl,mpc8272-brg", | ||
17 | "fsl,cpm2-brg", | ||
18 | "fsl,cpm-brg"; | ||
19 | reg = <119f0 10 115f0 10>; | ||
20 | clock-frequency = <d#25000000>; | ||
21 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt new file mode 100644 index 000000000000..87bc6048667e --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt | |||
@@ -0,0 +1,41 @@ | |||
1 | * I2C | ||
2 | |||
3 | The I2C controller is expressed as a bus under the CPM node. | ||
4 | |||
5 | Properties: | ||
6 | - compatible : "fsl,cpm1-i2c", "fsl,cpm2-i2c" | ||
7 | - reg : On CPM2 devices, the second resource doesn't specify the I2C | ||
8 | Parameter RAM itself, but the I2C_BASE field of the CPM2 Parameter RAM | ||
9 | (typically 0x8afc 0x2). | ||
10 | - #address-cells : Should be one. The cell is the i2c device address with | ||
11 | the r/w bit set to zero. | ||
12 | - #size-cells : Should be zero. | ||
13 | - clock-frequency : Can be used to set the i2c clock frequency. If | ||
14 | unspecified, a default frequency of 60kHz is being used. | ||
15 | The following two properties are deprecated. They are only used by legacy | ||
16 | i2c drivers to find the bus to probe: | ||
17 | - linux,i2c-index : Can be used to hard code an i2c bus number. By default, | ||
18 | the bus number is dynamically assigned by the i2c core. | ||
19 | - linux,i2c-class : Can be used to override the i2c class. The class is used | ||
20 | by legacy i2c device drivers to find a bus in a specific context like | ||
21 | system management, video or sound. By default, I2C_CLASS_HWMON (1) is | ||
22 | being used. The definition of the classes can be found in | ||
23 | include/i2c/i2c.h | ||
24 | |||
25 | Example, based on mpc823: | ||
26 | |||
27 | i2c@860 { | ||
28 | compatible = "fsl,mpc823-i2c", | ||
29 | "fsl,cpm1-i2c"; | ||
30 | reg = <0x860 0x20 0x3c80 0x30>; | ||
31 | interrupts = <16>; | ||
32 | interrupt-parent = <&CPM_PIC>; | ||
33 | fsl,cpm-command = <0x10>; | ||
34 | #address-cells = <1>; | ||
35 | #size-cells = <0>; | ||
36 | |||
37 | rtc@68 { | ||
38 | compatible = "dallas,ds1307"; | ||
39 | reg = <0x68>; | ||
40 | }; | ||
41 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/pic.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/pic.txt new file mode 100644 index 000000000000..8e3ee1681618 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/pic.txt | |||
@@ -0,0 +1,18 @@ | |||
1 | * Interrupt Controllers | ||
2 | |||
3 | Currently defined compatibles: | ||
4 | - fsl,cpm1-pic | ||
5 | - only one interrupt cell | ||
6 | - fsl,pq1-pic | ||
7 | - fsl,cpm2-pic | ||
8 | - second interrupt cell is level/sense: | ||
9 | - 2 is falling edge | ||
10 | - 8 is active low | ||
11 | |||
12 | Example: | ||
13 | interrupt-controller@10c00 { | ||
14 | #interrupt-cells = <2>; | ||
15 | interrupt-controller; | ||
16 | reg = <10c00 80>; | ||
17 | compatible = "mpc8272-pic", "fsl,cpm2-pic"; | ||
18 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/usb.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/usb.txt new file mode 100644 index 000000000000..74bfda4bb824 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/usb.txt | |||
@@ -0,0 +1,15 @@ | |||
1 | * USB (Universal Serial Bus Controller) | ||
2 | |||
3 | Properties: | ||
4 | - compatible : "fsl,cpm1-usb", "fsl,cpm2-usb", "fsl,qe-usb" | ||
5 | |||
6 | Example: | ||
7 | usb@11bc0 { | ||
8 | #address-cells = <1>; | ||
9 | #size-cells = <0>; | ||
10 | compatible = "fsl,cpm2-usb"; | ||
11 | reg = <11b60 18 8b00 100>; | ||
12 | interrupts = <b 8>; | ||
13 | interrupt-parent = <&PIC>; | ||
14 | fsl,cpm-command = <2e600000>; | ||
15 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt new file mode 100644 index 000000000000..1815dfede1bc --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt | |||
@@ -0,0 +1,38 @@ | |||
1 | Every GPIO controller node must have #gpio-cells property defined, | ||
2 | this information will be used to translate gpio-specifiers. | ||
3 | |||
4 | On CPM1 devices, all ports are using slightly different register layouts. | ||
5 | Ports A, C and D are 16bit ports and Ports B and E are 32bit ports. | ||
6 | |||
7 | On CPM2 devices, all ports are 32bit ports and use a common register layout. | ||
8 | |||
9 | Required properties: | ||
10 | - compatible : "fsl,cpm1-pario-bank-a", "fsl,cpm1-pario-bank-b", | ||
11 | "fsl,cpm1-pario-bank-c", "fsl,cpm1-pario-bank-d", | ||
12 | "fsl,cpm1-pario-bank-e", "fsl,cpm2-pario-bank" | ||
13 | - #gpio-cells : Should be two. The first cell is the pin number and the | ||
14 | second cell is used to specify optional paramters (currently unused). | ||
15 | - gpio-controller : Marks the port as GPIO controller. | ||
16 | |||
17 | Example of three SOC GPIO banks defined as gpio-controller nodes: | ||
18 | |||
19 | CPM1_PIO_A: gpio-controller@950 { | ||
20 | #gpio-cells = <2>; | ||
21 | compatible = "fsl,cpm1-pario-bank-a"; | ||
22 | reg = <0x950 0x10>; | ||
23 | gpio-controller; | ||
24 | }; | ||
25 | |||
26 | CPM1_PIO_B: gpio-controller@ab8 { | ||
27 | #gpio-cells = <2>; | ||
28 | compatible = "fsl,cpm1-pario-bank-b"; | ||
29 | reg = <0xab8 0x10>; | ||
30 | gpio-controller; | ||
31 | }; | ||
32 | |||
33 | CPM1_PIO_E: gpio-controller@ac8 { | ||
34 | #gpio-cells = <2>; | ||
35 | compatible = "fsl,cpm1-pario-bank-e"; | ||
36 | reg = <0xac8 0x18>; | ||
37 | gpio-controller; | ||
38 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/network.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/network.txt new file mode 100644 index 000000000000..0e4269446580 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/network.txt | |||
@@ -0,0 +1,45 @@ | |||
1 | * Network | ||
2 | |||
3 | Currently defined compatibles: | ||
4 | - fsl,cpm1-scc-enet | ||
5 | - fsl,cpm2-scc-enet | ||
6 | - fsl,cpm1-fec-enet | ||
7 | - fsl,cpm2-fcc-enet (third resource is GFEMR) | ||
8 | - fsl,qe-enet | ||
9 | |||
10 | Example: | ||
11 | |||
12 | ethernet@11300 { | ||
13 | device_type = "network"; | ||
14 | compatible = "fsl,mpc8272-fcc-enet", | ||
15 | "fsl,cpm2-fcc-enet"; | ||
16 | reg = <11300 20 8400 100 11390 1>; | ||
17 | local-mac-address = [ 00 00 00 00 00 00 ]; | ||
18 | interrupts = <20 8>; | ||
19 | interrupt-parent = <&PIC>; | ||
20 | phy-handle = <&PHY0>; | ||
21 | fsl,cpm-command = <12000300>; | ||
22 | }; | ||
23 | |||
24 | * MDIO | ||
25 | |||
26 | Currently defined compatibles: | ||
27 | fsl,pq1-fec-mdio (reg is same as first resource of FEC device) | ||
28 | fsl,cpm2-mdio-bitbang (reg is port C registers) | ||
29 | |||
30 | Properties for fsl,cpm2-mdio-bitbang: | ||
31 | fsl,mdio-pin : pin of port C controlling mdio data | ||
32 | fsl,mdc-pin : pin of port C controlling mdio clock | ||
33 | |||
34 | Example: | ||
35 | mdio@10d40 { | ||
36 | device_type = "mdio"; | ||
37 | compatible = "fsl,mpc8272ads-mdio-bitbang", | ||
38 | "fsl,mpc8272-mdio-bitbang", | ||
39 | "fsl,cpm2-mdio-bitbang"; | ||
40 | reg = <10d40 14>; | ||
41 | #address-cells = <1>; | ||
42 | #size-cells = <0>; | ||
43 | fsl,mdio-pin = <12>; | ||
44 | fsl,mdc-pin = <13>; | ||
45 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt new file mode 100644 index 000000000000..78790d58dc2c --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt | |||
@@ -0,0 +1,58 @@ | |||
1 | * Freescale QUICC Engine module (QE) | ||
2 | This represents qe module that is installed on PowerQUICC II Pro. | ||
3 | |||
4 | NOTE: This is an interim binding; it should be updated to fit | ||
5 | in with the CPM binding later in this document. | ||
6 | |||
7 | Basically, it is a bus of devices, that could act more or less | ||
8 | as a complete entity (UCC, USB etc ). All of them should be siblings on | ||
9 | the "root" qe node, using the common properties from there. | ||
10 | The description below applies to the qe of MPC8360 and | ||
11 | more nodes and properties would be extended in the future. | ||
12 | |||
13 | i) Root QE device | ||
14 | |||
15 | Required properties: | ||
16 | - compatible : should be "fsl,qe"; | ||
17 | - model : precise model of the QE, Can be "QE", "CPM", or "CPM2" | ||
18 | - reg : offset and length of the device registers. | ||
19 | - bus-frequency : the clock frequency for QUICC Engine. | ||
20 | |||
21 | Recommended properties | ||
22 | - brg-frequency : the internal clock source frequency for baud-rate | ||
23 | generators in Hz. | ||
24 | |||
25 | Example: | ||
26 | qe@e0100000 { | ||
27 | #address-cells = <1>; | ||
28 | #size-cells = <1>; | ||
29 | #interrupt-cells = <2>; | ||
30 | compatible = "fsl,qe"; | ||
31 | ranges = <0 e0100000 00100000>; | ||
32 | reg = <e0100000 480>; | ||
33 | brg-frequency = <0>; | ||
34 | bus-frequency = <179A7B00>; | ||
35 | } | ||
36 | |||
37 | * Multi-User RAM (MURAM) | ||
38 | |||
39 | Required properties: | ||
40 | - compatible : should be "fsl,qe-muram", "fsl,cpm-muram". | ||
41 | - mode : the could be "host" or "slave". | ||
42 | - ranges : Should be defined as specified in 1) to describe the | ||
43 | translation of MURAM addresses. | ||
44 | - data-only : sub-node which defines the address area under MURAM | ||
45 | bus that can be allocated as data/parameter | ||
46 | |||
47 | Example: | ||
48 | |||
49 | muram@10000 { | ||
50 | compatible = "fsl,qe-muram", "fsl,cpm-muram"; | ||
51 | ranges = <0 00010000 0000c000>; | ||
52 | |||
53 | data-only@0{ | ||
54 | compatible = "fsl,qe-muram-data", | ||
55 | "fsl,cpm-muram-data"; | ||
56 | reg = <0 c000>; | ||
57 | }; | ||
58 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt new file mode 100644 index 000000000000..6c238f59b2a9 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt | |||
@@ -0,0 +1,24 @@ | |||
1 | * Uploaded QE firmware | ||
2 | |||
3 | If a new firwmare has been uploaded to the QE (usually by the | ||
4 | boot loader), then a 'firmware' child node should be added to the QE | ||
5 | node. This node provides information on the uploaded firmware that | ||
6 | device drivers may need. | ||
7 | |||
8 | Required properties: | ||
9 | - id: The string name of the firmware. This is taken from the 'id' | ||
10 | member of the qe_firmware structure of the uploaded firmware. | ||
11 | Device drivers can search this string to determine if the | ||
12 | firmware they want is already present. | ||
13 | - extended-modes: The Extended Modes bitfield, taken from the | ||
14 | firmware binary. It is a 64-bit number represented | ||
15 | as an array of two 32-bit numbers. | ||
16 | - virtual-traps: The virtual traps, taken from the firmware binary. | ||
17 | It is an array of 8 32-bit numbers. | ||
18 | |||
19 | Example: | ||
20 | firmware { | ||
21 | id = "Soft-UART"; | ||
22 | extended-modes = <0 0>; | ||
23 | virtual-traps = <0 0 0 0 0 0 0 0>; | ||
24 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/par_io.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/par_io.txt new file mode 100644 index 000000000000..60984260207b --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/par_io.txt | |||
@@ -0,0 +1,51 @@ | |||
1 | * Parallel I/O Ports | ||
2 | |||
3 | This node configures Parallel I/O ports for CPUs with QE support. | ||
4 | The node should reside in the "soc" node of the tree. For each | ||
5 | device that using parallel I/O ports, a child node should be created. | ||
6 | See the definition of the Pin configuration nodes below for more | ||
7 | information. | ||
8 | |||
9 | Required properties: | ||
10 | - device_type : should be "par_io". | ||
11 | - reg : offset to the register set and its length. | ||
12 | - num-ports : number of Parallel I/O ports | ||
13 | |||
14 | Example: | ||
15 | par_io@1400 { | ||
16 | reg = <1400 100>; | ||
17 | #address-cells = <1>; | ||
18 | #size-cells = <0>; | ||
19 | device_type = "par_io"; | ||
20 | num-ports = <7>; | ||
21 | ucc_pin@01 { | ||
22 | ...... | ||
23 | }; | ||
24 | |||
25 | Note that "par_io" nodes are obsolete, and should not be used for | ||
26 | the new device trees. Instead, each Par I/O bank should be represented | ||
27 | via its own gpio-controller node: | ||
28 | |||
29 | Required properties: | ||
30 | - #gpio-cells : should be "2". | ||
31 | - compatible : should be "fsl,<chip>-qe-pario-bank", | ||
32 | "fsl,mpc8323-qe-pario-bank". | ||
33 | - reg : offset to the register set and its length. | ||
34 | - gpio-controller : node to identify gpio controllers. | ||
35 | |||
36 | Example: | ||
37 | qe_pio_a: gpio-controller@1400 { | ||
38 | #gpio-cells = <2>; | ||
39 | compatible = "fsl,mpc8360-qe-pario-bank", | ||
40 | "fsl,mpc8323-qe-pario-bank"; | ||
41 | reg = <0x1400 0x18>; | ||
42 | gpio-controller; | ||
43 | }; | ||
44 | |||
45 | qe_pio_e: gpio-controller@1460 { | ||
46 | #gpio-cells = <2>; | ||
47 | compatible = "fsl,mpc8360-qe-pario-bank", | ||
48 | "fsl,mpc8323-qe-pario-bank"; | ||
49 | reg = <0x1460 0x18>; | ||
50 | gpio-controller; | ||
51 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/pincfg.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/pincfg.txt new file mode 100644 index 000000000000..c5b43061db3a --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/pincfg.txt | |||
@@ -0,0 +1,60 @@ | |||
1 | * Pin configuration nodes | ||
2 | |||
3 | Required properties: | ||
4 | - linux,phandle : phandle of this node; likely referenced by a QE | ||
5 | device. | ||
6 | - pio-map : array of pin configurations. Each pin is defined by 6 | ||
7 | integers. The six numbers are respectively: port, pin, dir, | ||
8 | open_drain, assignment, has_irq. | ||
9 | - port : port number of the pin; 0-6 represent port A-G in UM. | ||
10 | - pin : pin number in the port. | ||
11 | - dir : direction of the pin, should encode as follows: | ||
12 | |||
13 | 0 = The pin is disabled | ||
14 | 1 = The pin is an output | ||
15 | 2 = The pin is an input | ||
16 | 3 = The pin is I/O | ||
17 | |||
18 | - open_drain : indicates the pin is normal or wired-OR: | ||
19 | |||
20 | 0 = The pin is actively driven as an output | ||
21 | 1 = The pin is an open-drain driver. As an output, the pin is | ||
22 | driven active-low, otherwise it is three-stated. | ||
23 | |||
24 | - assignment : function number of the pin according to the Pin Assignment | ||
25 | tables in User Manual. Each pin can have up to 4 possible functions in | ||
26 | QE and two options for CPM. | ||
27 | - has_irq : indicates if the pin is used as source of external | ||
28 | interrupts. | ||
29 | |||
30 | Example: | ||
31 | ucc_pin@01 { | ||
32 | linux,phandle = <140001>; | ||
33 | pio-map = < | ||
34 | /* port pin dir open_drain assignment has_irq */ | ||
35 | 0 3 1 0 1 0 /* TxD0 */ | ||
36 | 0 4 1 0 1 0 /* TxD1 */ | ||
37 | 0 5 1 0 1 0 /* TxD2 */ | ||
38 | 0 6 1 0 1 0 /* TxD3 */ | ||
39 | 1 6 1 0 3 0 /* TxD4 */ | ||
40 | 1 7 1 0 1 0 /* TxD5 */ | ||
41 | 1 9 1 0 2 0 /* TxD6 */ | ||
42 | 1 a 1 0 2 0 /* TxD7 */ | ||
43 | 0 9 2 0 1 0 /* RxD0 */ | ||
44 | 0 a 2 0 1 0 /* RxD1 */ | ||
45 | 0 b 2 0 1 0 /* RxD2 */ | ||
46 | 0 c 2 0 1 0 /* RxD3 */ | ||
47 | 0 d 2 0 1 0 /* RxD4 */ | ||
48 | 1 1 2 0 2 0 /* RxD5 */ | ||
49 | 1 0 2 0 2 0 /* RxD6 */ | ||
50 | 1 4 2 0 2 0 /* RxD7 */ | ||
51 | 0 7 1 0 1 0 /* TX_EN */ | ||
52 | 0 8 1 0 1 0 /* TX_ER */ | ||
53 | 0 f 2 0 1 0 /* RX_DV */ | ||
54 | 0 10 2 0 1 0 /* RX_ER */ | ||
55 | 0 0 2 0 1 0 /* RX_CLK */ | ||
56 | 2 9 1 0 3 0 /* GTX_CLK - CLK10 */ | ||
57 | 2 8 2 0 1 0>; /* GTX125 - CLK9 */ | ||
58 | }; | ||
59 | |||
60 | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/ucc.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/ucc.txt new file mode 100644 index 000000000000..e47734bee3f0 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/ucc.txt | |||
@@ -0,0 +1,70 @@ | |||
1 | * UCC (Unified Communications Controllers) | ||
2 | |||
3 | Required properties: | ||
4 | - device_type : should be "network", "hldc", "uart", "transparent" | ||
5 | "bisync", "atm", or "serial". | ||
6 | - compatible : could be "ucc_geth" or "fsl_atm" and so on. | ||
7 | - cell-index : the ucc number(1-8), corresponding to UCCx in UM. | ||
8 | - reg : Offset and length of the register set for the device | ||
9 | - interrupts : <a b> where a is the interrupt number and b is a | ||
10 | field that represents an encoding of the sense and level | ||
11 | information for the interrupt. This should be encoded based on | ||
12 | the information in section 2) depending on the type of interrupt | ||
13 | controller you have. | ||
14 | - interrupt-parent : the phandle for the interrupt controller that | ||
15 | services interrupts for this device. | ||
16 | - pio-handle : The phandle for the Parallel I/O port configuration. | ||
17 | - port-number : for UART drivers, the port number to use, between 0 and 3. | ||
18 | This usually corresponds to the /dev/ttyQE device, e.g. <0> = /dev/ttyQE0. | ||
19 | The port number is added to the minor number of the device. Unlike the | ||
20 | CPM UART driver, the port-number is required for the QE UART driver. | ||
21 | - soft-uart : for UART drivers, if specified this means the QE UART device | ||
22 | driver should use "Soft-UART" mode, which is needed on some SOCs that have | ||
23 | broken UART hardware. Soft-UART is provided via a microcode upload. | ||
24 | - rx-clock-name: the UCC receive clock source | ||
25 | "none": clock source is disabled | ||
26 | "brg1" through "brg16": clock source is BRG1-BRG16, respectively | ||
27 | "clk1" through "clk24": clock source is CLK1-CLK24, respectively | ||
28 | - tx-clock-name: the UCC transmit clock source | ||
29 | "none": clock source is disabled | ||
30 | "brg1" through "brg16": clock source is BRG1-BRG16, respectively | ||
31 | "clk1" through "clk24": clock source is CLK1-CLK24, respectively | ||
32 | The following two properties are deprecated. rx-clock has been replaced | ||
33 | with rx-clock-name, and tx-clock has been replaced with tx-clock-name. | ||
34 | Drivers that currently use the deprecated properties should continue to | ||
35 | do so, in order to support older device trees, but they should be updated | ||
36 | to check for the new properties first. | ||
37 | - rx-clock : represents the UCC receive clock source. | ||
38 | 0x00 : clock source is disabled; | ||
39 | 0x1~0x10 : clock source is BRG1~BRG16 respectively; | ||
40 | 0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively. | ||
41 | - tx-clock: represents the UCC transmit clock source; | ||
42 | 0x00 : clock source is disabled; | ||
43 | 0x1~0x10 : clock source is BRG1~BRG16 respectively; | ||
44 | 0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively. | ||
45 | |||
46 | Required properties for network device_type: | ||
47 | - mac-address : list of bytes representing the ethernet address. | ||
48 | - phy-handle : The phandle for the PHY connected to this controller. | ||
49 | |||
50 | Recommended properties: | ||
51 | - phy-connection-type : a string naming the controller/PHY interface type, | ||
52 | i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal | ||
53 | Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only), | ||
54 | "tbi", or "rtbi". | ||
55 | |||
56 | Example: | ||
57 | ucc@2000 { | ||
58 | device_type = "network"; | ||
59 | compatible = "ucc_geth"; | ||
60 | cell-index = <1>; | ||
61 | reg = <2000 200>; | ||
62 | interrupts = <a0 0>; | ||
63 | interrupt-parent = <700>; | ||
64 | mac-address = [ 00 04 9f 00 23 23 ]; | ||
65 | rx-clock = "none"; | ||
66 | tx-clock = "clk9"; | ||
67 | phy-handle = <212000>; | ||
68 | phy-connection-type = "gmii"; | ||
69 | pio-handle = <140001>; | ||
70 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt new file mode 100644 index 000000000000..9ccd5f30405b --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt | |||
@@ -0,0 +1,37 @@ | |||
1 | Freescale QUICC Engine USB Controller | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : should be "fsl,<chip>-qe-usb", "fsl,mpc8323-qe-usb". | ||
5 | - reg : the first two cells should contain usb registers location and | ||
6 | length, the next two two cells should contain PRAM location and | ||
7 | length. | ||
8 | - interrupts : should contain USB interrupt. | ||
9 | - interrupt-parent : interrupt source phandle. | ||
10 | - fsl,fullspeed-clock : specifies the full speed USB clock source: | ||
11 | "none": clock source is disabled | ||
12 | "brg1" through "brg16": clock source is BRG1-BRG16, respectively | ||
13 | "clk1" through "clk24": clock source is CLK1-CLK24, respectively | ||
14 | - fsl,lowspeed-clock : specifies the low speed USB clock source: | ||
15 | "none": clock source is disabled | ||
16 | "brg1" through "brg16": clock source is BRG1-BRG16, respectively | ||
17 | "clk1" through "clk24": clock source is CLK1-CLK24, respectively | ||
18 | - hub-power-budget : USB power budget for the root hub, in mA. | ||
19 | - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP, | ||
20 | USBRN, SPEED (optional), and POWER (optional). | ||
21 | |||
22 | Example: | ||
23 | |||
24 | usb@6c0 { | ||
25 | compatible = "fsl,mpc8360-qe-usb", "fsl,mpc8323-qe-usb"; | ||
26 | reg = <0x6c0 0x40 0x8b00 0x100>; | ||
27 | interrupts = <11>; | ||
28 | interrupt-parent = <&qeic>; | ||
29 | fsl,fullspeed-clock = "clk21"; | ||
30 | gpios = <&qe_pio_b 2 0 /* USBOE */ | ||
31 | &qe_pio_b 3 0 /* USBTP */ | ||
32 | &qe_pio_b 8 0 /* USBTN */ | ||
33 | &qe_pio_b 9 0 /* USBRP */ | ||
34 | &qe_pio_b 11 0 /* USBRN */ | ||
35 | &qe_pio_e 20 0 /* SPEED */ | ||
36 | &qe_pio_e 21 0 /* POWER */>; | ||
37 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt new file mode 100644 index 000000000000..2ea76d9d137c --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt | |||
@@ -0,0 +1,32 @@ | |||
1 | * Serial | ||
2 | |||
3 | Currently defined compatibles: | ||
4 | - fsl,cpm1-smc-uart | ||
5 | - fsl,cpm2-smc-uart | ||
6 | - fsl,cpm1-scc-uart | ||
7 | - fsl,cpm2-scc-uart | ||
8 | - fsl,qe-uart | ||
9 | |||
10 | Modem control lines connected to GPIO controllers are listed in the gpios | ||
11 | property as described in booting-without-of.txt, section IX.1 in the following | ||
12 | order: | ||
13 | |||
14 | CTS, RTS, DCD, DSR, DTR, and RI. | ||
15 | |||
16 | The gpios property is optional and can be left out when control lines are | ||
17 | not used. | ||
18 | |||
19 | Example: | ||
20 | |||
21 | serial@11a00 { | ||
22 | device_type = "serial"; | ||
23 | compatible = "fsl,mpc8272-scc-uart", | ||
24 | "fsl,cpm2-scc-uart"; | ||
25 | reg = <11a00 20 8000 100>; | ||
26 | interrupts = <28 8>; | ||
27 | interrupt-parent = <&PIC>; | ||
28 | fsl,cpm-brg = <1>; | ||
29 | fsl,cpm-command = <00800000>; | ||
30 | gpios = <&gpio_c 15 0 | ||
31 | &gpio_d 29 0>; | ||
32 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/diu.txt b/Documentation/powerpc/dts-bindings/fsl/diu.txt new file mode 100644 index 000000000000..deb35de70988 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/diu.txt | |||
@@ -0,0 +1,18 @@ | |||
1 | * Freescale Display Interface Unit | ||
2 | |||
3 | The Freescale DIU is a LCD controller, with proper hardware, it can also | ||
4 | drive DVI monitors. | ||
5 | |||
6 | Required properties: | ||
7 | - compatible : should be "fsl-diu". | ||
8 | - reg : should contain at least address and length of the DIU register | ||
9 | set. | ||
10 | - Interrupts : one DIU interrupt should be describe here. | ||
11 | |||
12 | Example (MPC8610HPCD): | ||
13 | display@2c000 { | ||
14 | compatible = "fsl,diu"; | ||
15 | reg = <0x2c000 100>; | ||
16 | interrupts = <72 2>; | ||
17 | interrupt-parent = <&mpic>; | ||
18 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt b/Documentation/powerpc/dts-bindings/fsl/dma.txt new file mode 100644 index 000000000000..86826df00e64 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/dma.txt | |||
@@ -0,0 +1,127 @@ | |||
1 | * Freescale 83xx DMA Controller | ||
2 | |||
3 | Freescale PowerPC 83xx have on chip general purpose DMA controllers. | ||
4 | |||
5 | Required properties: | ||
6 | |||
7 | - compatible : compatible list, contains 2 entries, first is | ||
8 | "fsl,CHIP-dma", where CHIP is the processor | ||
9 | (mpc8349, mpc8360, etc.) and the second is | ||
10 | "fsl,elo-dma" | ||
11 | - reg : <registers mapping for DMA general status reg> | ||
12 | - ranges : Should be defined as specified in 1) to describe the | ||
13 | DMA controller channels. | ||
14 | - cell-index : controller index. 0 for controller @ 0x8100 | ||
15 | - interrupts : <interrupt mapping for DMA IRQ> | ||
16 | - interrupt-parent : optional, if needed for interrupt mapping | ||
17 | |||
18 | |||
19 | - DMA channel nodes: | ||
20 | - compatible : compatible list, contains 2 entries, first is | ||
21 | "fsl,CHIP-dma-channel", where CHIP is the processor | ||
22 | (mpc8349, mpc8350, etc.) and the second is | ||
23 | "fsl,elo-dma-channel" | ||
24 | - reg : <registers mapping for channel> | ||
25 | - cell-index : dma channel index starts at 0. | ||
26 | |||
27 | Optional properties: | ||
28 | - interrupts : <interrupt mapping for DMA channel IRQ> | ||
29 | (on 83xx this is expected to be identical to | ||
30 | the interrupts property of the parent node) | ||
31 | - interrupt-parent : optional, if needed for interrupt mapping | ||
32 | |||
33 | Example: | ||
34 | dma@82a8 { | ||
35 | #address-cells = <1>; | ||
36 | #size-cells = <1>; | ||
37 | compatible = "fsl,mpc8349-dma", "fsl,elo-dma"; | ||
38 | reg = <82a8 4>; | ||
39 | ranges = <0 8100 1a4>; | ||
40 | interrupt-parent = <&ipic>; | ||
41 | interrupts = <47 8>; | ||
42 | cell-index = <0>; | ||
43 | dma-channel@0 { | ||
44 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | ||
45 | cell-index = <0>; | ||
46 | reg = <0 80>; | ||
47 | }; | ||
48 | dma-channel@80 { | ||
49 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | ||
50 | cell-index = <1>; | ||
51 | reg = <80 80>; | ||
52 | }; | ||
53 | dma-channel@100 { | ||
54 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | ||
55 | cell-index = <2>; | ||
56 | reg = <100 80>; | ||
57 | }; | ||
58 | dma-channel@180 { | ||
59 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | ||
60 | cell-index = <3>; | ||
61 | reg = <180 80>; | ||
62 | }; | ||
63 | }; | ||
64 | |||
65 | * Freescale 85xx/86xx DMA Controller | ||
66 | |||
67 | Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers. | ||
68 | |||
69 | Required properties: | ||
70 | |||
71 | - compatible : compatible list, contains 2 entries, first is | ||
72 | "fsl,CHIP-dma", where CHIP is the processor | ||
73 | (mpc8540, mpc8540, etc.) and the second is | ||
74 | "fsl,eloplus-dma" | ||
75 | - reg : <registers mapping for DMA general status reg> | ||
76 | - cell-index : controller index. 0 for controller @ 0x21000, | ||
77 | 1 for controller @ 0xc000 | ||
78 | - ranges : Should be defined as specified in 1) to describe the | ||
79 | DMA controller channels. | ||
80 | |||
81 | - DMA channel nodes: | ||
82 | - compatible : compatible list, contains 2 entries, first is | ||
83 | "fsl,CHIP-dma-channel", where CHIP is the processor | ||
84 | (mpc8540, mpc8560, etc.) and the second is | ||
85 | "fsl,eloplus-dma-channel" | ||
86 | - cell-index : dma channel index starts at 0. | ||
87 | - reg : <registers mapping for channel> | ||
88 | - interrupts : <interrupt mapping for DMA channel IRQ> | ||
89 | - interrupt-parent : optional, if needed for interrupt mapping | ||
90 | |||
91 | Example: | ||
92 | dma@21300 { | ||
93 | #address-cells = <1>; | ||
94 | #size-cells = <1>; | ||
95 | compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma"; | ||
96 | reg = <21300 4>; | ||
97 | ranges = <0 21100 200>; | ||
98 | cell-index = <0>; | ||
99 | dma-channel@0 { | ||
100 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | ||
101 | reg = <0 80>; | ||
102 | cell-index = <0>; | ||
103 | interrupt-parent = <&mpic>; | ||
104 | interrupts = <14 2>; | ||
105 | }; | ||
106 | dma-channel@80 { | ||
107 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | ||
108 | reg = <80 80>; | ||
109 | cell-index = <1>; | ||
110 | interrupt-parent = <&mpic>; | ||
111 | interrupts = <15 2>; | ||
112 | }; | ||
113 | dma-channel@100 { | ||
114 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | ||
115 | reg = <100 80>; | ||
116 | cell-index = <2>; | ||
117 | interrupt-parent = <&mpic>; | ||
118 | interrupts = <16 2>; | ||
119 | }; | ||
120 | dma-channel@180 { | ||
121 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | ||
122 | reg = <180 80>; | ||
123 | cell-index = <3>; | ||
124 | interrupt-parent = <&mpic>; | ||
125 | interrupts = <17 2>; | ||
126 | }; | ||
127 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/gtm.txt b/Documentation/powerpc/dts-bindings/fsl/gtm.txt new file mode 100644 index 000000000000..9a33efded4bc --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/gtm.txt | |||
@@ -0,0 +1,31 @@ | |||
1 | * Freescale General-purpose Timers Module | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : should be | ||
5 | "fsl,<chip>-gtm", "fsl,gtm" for SOC GTMs | ||
6 | "fsl,<chip>-qe-gtm", "fsl,qe-gtm", "fsl,gtm" for QE GTMs | ||
7 | "fsl,<chip>-cpm2-gtm", "fsl,cpm2-gtm", "fsl,gtm" for CPM2 GTMs | ||
8 | - reg : should contain gtm registers location and length (0x40). | ||
9 | - interrupts : should contain four interrupts. | ||
10 | - interrupt-parent : interrupt source phandle. | ||
11 | - clock-frequency : specifies the frequency driving the timer. | ||
12 | |||
13 | Example: | ||
14 | |||
15 | timer@500 { | ||
16 | compatible = "fsl,mpc8360-gtm", "fsl,gtm"; | ||
17 | reg = <0x500 0x40>; | ||
18 | interrupts = <90 8 78 8 84 8 72 8>; | ||
19 | interrupt-parent = <&ipic>; | ||
20 | /* filled by u-boot */ | ||
21 | clock-frequency = <0>; | ||
22 | }; | ||
23 | |||
24 | timer@440 { | ||
25 | compatible = "fsl,mpc8360-qe-gtm", "fsl,qe-gtm", "fsl,gtm"; | ||
26 | reg = <0x440 0x40>; | ||
27 | interrupts = <12 13 14 15>; | ||
28 | interrupt-parent = <&qeic>; | ||
29 | /* filled by u-boot */ | ||
30 | clock-frequency = <0>; | ||
31 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/guts.txt b/Documentation/powerpc/dts-bindings/fsl/guts.txt new file mode 100644 index 000000000000..9e7a2417dac5 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/guts.txt | |||
@@ -0,0 +1,25 @@ | |||
1 | * Global Utilities Block | ||
2 | |||
3 | The global utilities block controls power management, I/O device | ||
4 | enabling, power-on-reset configuration monitoring, general-purpose | ||
5 | I/O signal configuration, alternate function selection for multiplexed | ||
6 | signals, and clock control. | ||
7 | |||
8 | Required properties: | ||
9 | |||
10 | - compatible : Should define the compatible device type for | ||
11 | global-utilities. | ||
12 | - reg : Offset and length of the register set for the device. | ||
13 | |||
14 | Recommended properties: | ||
15 | |||
16 | - fsl,has-rstcr : Indicates that the global utilities register set | ||
17 | contains a functioning "reset control register" (i.e. the board | ||
18 | is wired to reset upon setting the HRESET_REQ bit in this register). | ||
19 | |||
20 | Example: | ||
21 | global-utilities@e0000 { /* global utilities block */ | ||
22 | compatible = "fsl,mpc8548-guts"; | ||
23 | reg = <e0000 1000>; | ||
24 | fsl,has-rstcr; | ||
25 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/i2c.txt b/Documentation/powerpc/dts-bindings/fsl/i2c.txt new file mode 100644 index 000000000000..d0ab33e21fe6 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/i2c.txt | |||
@@ -0,0 +1,32 @@ | |||
1 | * I2C | ||
2 | |||
3 | Required properties : | ||
4 | |||
5 | - device_type : Should be "i2c" | ||
6 | - reg : Offset and length of the register set for the device | ||
7 | |||
8 | Recommended properties : | ||
9 | |||
10 | - compatible : Should be "fsl-i2c" for parts compatible with | ||
11 | Freescale I2C specifications. | ||
12 | - interrupts : <a b> where a is the interrupt number and b is a | ||
13 | field that represents an encoding of the sense and level | ||
14 | information for the interrupt. This should be encoded based on | ||
15 | the information in section 2) depending on the type of interrupt | ||
16 | controller you have. | ||
17 | - interrupt-parent : the phandle for the interrupt controller that | ||
18 | services interrupts for this device. | ||
19 | - dfsrr : boolean; if defined, indicates that this I2C device has | ||
20 | a digital filter sampling rate register | ||
21 | - fsl5200-clocking : boolean; if defined, indicated that this device | ||
22 | uses the FSL 5200 clocking mechanism. | ||
23 | |||
24 | Example : | ||
25 | i2c@3000 { | ||
26 | interrupt-parent = <40000>; | ||
27 | interrupts = <1b 3>; | ||
28 | reg = <3000 18>; | ||
29 | device_type = "i2c"; | ||
30 | compatible = "fsl-i2c"; | ||
31 | dfsrr; | ||
32 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/lbc.txt b/Documentation/powerpc/dts-bindings/fsl/lbc.txt new file mode 100644 index 000000000000..3300fec501c5 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/lbc.txt | |||
@@ -0,0 +1,35 @@ | |||
1 | * Chipselect/Local Bus | ||
2 | |||
3 | Properties: | ||
4 | - name : Should be localbus | ||
5 | - #address-cells : Should be either two or three. The first cell is the | ||
6 | chipselect number, and the remaining cells are the | ||
7 | offset into the chipselect. | ||
8 | - #size-cells : Either one or two, depending on how large each chipselect | ||
9 | can be. | ||
10 | - ranges : Each range corresponds to a single chipselect, and cover | ||
11 | the entire access window as configured. | ||
12 | |||
13 | Example: | ||
14 | localbus@f0010100 { | ||
15 | compatible = "fsl,mpc8272-localbus", | ||
16 | "fsl,pq2-localbus"; | ||
17 | #address-cells = <2>; | ||
18 | #size-cells = <1>; | ||
19 | reg = <f0010100 40>; | ||
20 | |||
21 | ranges = <0 0 fe000000 02000000 | ||
22 | 1 0 f4500000 00008000>; | ||
23 | |||
24 | flash@0,0 { | ||
25 | compatible = "jedec-flash"; | ||
26 | reg = <0 0 2000000>; | ||
27 | bank-width = <4>; | ||
28 | device-width = <1>; | ||
29 | }; | ||
30 | |||
31 | board-control@1,0 { | ||
32 | reg = <1 0 20>; | ||
33 | compatible = "fsl,mpc8272ads-bcsr"; | ||
34 | }; | ||
35 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt b/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt new file mode 100644 index 000000000000..0f766333b6eb --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt | |||
@@ -0,0 +1,17 @@ | |||
1 | Freescale MPC8349E-mITX-compatible Power Management Micro Controller Unit (MCU) | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx". | ||
5 | - reg : should specify I2C address (0x0a). | ||
6 | - #gpio-cells : should be 2. | ||
7 | - gpio-controller : should be present. | ||
8 | |||
9 | Example: | ||
10 | |||
11 | mcu@0a { | ||
12 | #gpio-cells = <2>; | ||
13 | compatible = "fsl,mc9s08qg8-mpc8349emitx", | ||
14 | "fsl,mcu-mpc8349emitx"; | ||
15 | reg = <0x0a>; | ||
16 | gpio-controller; | ||
17 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/msi-pic.txt b/Documentation/powerpc/dts-bindings/fsl/msi-pic.txt new file mode 100644 index 000000000000..b26b91992c55 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/msi-pic.txt | |||
@@ -0,0 +1,36 @@ | |||
1 | * Freescale MSI interrupt controller | ||
2 | |||
3 | Reguired properities: | ||
4 | - compatible : compatible list, contains 2 entries, | ||
5 | first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572, | ||
6 | etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on | ||
7 | the parent type. | ||
8 | - reg : should contain the address and the length of the shared message | ||
9 | interrupt register set. | ||
10 | - msi-available-ranges: use <start count> style section to define which | ||
11 | msi interrupt can be used in the 256 msi interrupts. This property is | ||
12 | optional, without this, all the 256 MSI interrupts can be used. | ||
13 | - interrupts : each one of the interrupts here is one entry per 32 MSIs, | ||
14 | and routed to the host interrupt controller. the interrupts should | ||
15 | be set as edge sensitive. | ||
16 | - interrupt-parent: the phandle for the interrupt controller | ||
17 | that services interrupts for this device. for 83xx cpu, the interrupts | ||
18 | are routed to IPIC, and for 85xx/86xx cpu the interrupts are routed | ||
19 | to MPIC. | ||
20 | |||
21 | Example: | ||
22 | msi@41600 { | ||
23 | compatible = "fsl,mpc8610-msi", "fsl,mpic-msi"; | ||
24 | reg = <0x41600 0x80>; | ||
25 | msi-available-ranges = <0 0x100>; | ||
26 | interrupts = < | ||
27 | 0xe0 0 | ||
28 | 0xe1 0 | ||
29 | 0xe2 0 | ||
30 | 0xe3 0 | ||
31 | 0xe4 0 | ||
32 | 0xe5 0 | ||
33 | 0xe6 0 | ||
34 | 0xe7 0>; | ||
35 | interrupt-parent = <&mpic>; | ||
36 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/pmc.txt b/Documentation/powerpc/dts-bindings/fsl/pmc.txt new file mode 100644 index 000000000000..02f6f43ee1b7 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/pmc.txt | |||
@@ -0,0 +1,63 @@ | |||
1 | * Power Management Controller | ||
2 | |||
3 | Properties: | ||
4 | - compatible: "fsl,<chip>-pmc". | ||
5 | |||
6 | "fsl,mpc8349-pmc" should be listed for any chip whose PMC is | ||
7 | compatible. "fsl,mpc8313-pmc" should also be listed for any chip | ||
8 | whose PMC is compatible, and implies deep-sleep capability. | ||
9 | |||
10 | "fsl,mpc8548-pmc" should be listed for any chip whose PMC is | ||
11 | compatible. "fsl,mpc8536-pmc" should also be listed for any chip | ||
12 | whose PMC is compatible, and implies deep-sleep capability. | ||
13 | |||
14 | "fsl,mpc8641d-pmc" should be listed for any chip whose PMC is | ||
15 | compatible; all statements below that apply to "fsl,mpc8548-pmc" also | ||
16 | apply to "fsl,mpc8641d-pmc". | ||
17 | |||
18 | Compatibility does not include bit assigments in SCCR/PMCDR/DEVDISR; these | ||
19 | bit assigments are indicated via the sleep specifier in each device's | ||
20 | sleep property. | ||
21 | |||
22 | - reg: For devices compatible with "fsl,mpc8349-pmc", the first resource | ||
23 | is the PMC block, and the second resource is the Clock Configuration | ||
24 | block. | ||
25 | |||
26 | For devices compatible with "fsl,mpc8548-pmc", the first resource | ||
27 | is a 32-byte block beginning with DEVDISR. | ||
28 | |||
29 | - interrupts: For "fsl,mpc8349-pmc"-compatible devices, the first | ||
30 | resource is the PMC block interrupt. | ||
31 | |||
32 | - fsl,mpc8313-wakeup-timer: For "fsl,mpc8313-pmc"-compatible devices, | ||
33 | this is a phandle to an "fsl,gtm" node on which timer 4 can be used as | ||
34 | a wakeup source from deep sleep. | ||
35 | |||
36 | Sleep specifiers: | ||
37 | |||
38 | fsl,mpc8349-pmc: Sleep specifiers consist of one cell. For each bit | ||
39 | that is set in the cell, the corresponding bit in SCCR will be saved | ||
40 | and cleared on suspend, and restored on resume. This sleep controller | ||
41 | supports disabling and resuming devices at any time. | ||
42 | |||
43 | fsl,mpc8536-pmc: Sleep specifiers consist of three cells, the third of | ||
44 | which will be ORed into PMCDR upon suspend, and cleared from PMCDR | ||
45 | upon resume. The first two cells are as described for fsl,mpc8578-pmc. | ||
46 | This sleep controller only supports disabling devices during system | ||
47 | sleep, or permanently. | ||
48 | |||
49 | fsl,mpc8548-pmc: Sleep specifiers consist of one or two cells, the | ||
50 | first of which will be ORed into DEVDISR (and the second into | ||
51 | DEVDISR2, if present -- this cell should be zero or absent if the | ||
52 | hardware does not have DEVDISR2) upon a request for permanent device | ||
53 | disabling. This sleep controller does not support configuring devices | ||
54 | to disable during system sleep (unless supported by another compatible | ||
55 | match), or dynamically. | ||
56 | |||
57 | Example: | ||
58 | |||
59 | power@b00 { | ||
60 | compatible = "fsl,mpc8313-pmc", "fsl,mpc8349-pmc"; | ||
61 | reg = <0xb00 0x100 0xa00 0x100>; | ||
62 | interrupts = <80 8>; | ||
63 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/sata.txt b/Documentation/powerpc/dts-bindings/fsl/sata.txt new file mode 100644 index 000000000000..b46bcf46c3d8 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/sata.txt | |||
@@ -0,0 +1,29 @@ | |||
1 | * Freescale 8xxx/3.0 Gb/s SATA nodes | ||
2 | |||
3 | SATA nodes are defined to describe on-chip Serial ATA controllers. | ||
4 | Each SATA port should have its own node. | ||
5 | |||
6 | Required properties: | ||
7 | - compatible : compatible list, contains 2 entries, first is | ||
8 | "fsl,CHIP-sata", where CHIP is the processor | ||
9 | (mpc8315, mpc8379, etc.) and the second is | ||
10 | "fsl,pq-sata" | ||
11 | - interrupts : <interrupt mapping for SATA IRQ> | ||
12 | - cell-index : controller index. | ||
13 | 1 for controller @ 0x18000 | ||
14 | 2 for controller @ 0x19000 | ||
15 | 3 for controller @ 0x1a000 | ||
16 | 4 for controller @ 0x1b000 | ||
17 | |||
18 | Optional properties: | ||
19 | - interrupt-parent : optional, if needed for interrupt mapping | ||
20 | - reg : <registers mapping> | ||
21 | |||
22 | Example: | ||
23 | sata@18000 { | ||
24 | compatible = "fsl,mpc8379-sata", "fsl,pq-sata"; | ||
25 | reg = <0x18000 0x1000>; | ||
26 | cell-index = <1>; | ||
27 | interrupts = <2c 8>; | ||
28 | interrupt-parent = < &ipic >; | ||
29 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/sec.txt b/Documentation/powerpc/dts-bindings/fsl/sec.txt new file mode 100644 index 000000000000..2b6f2d45c45a --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/sec.txt | |||
@@ -0,0 +1,68 @@ | |||
1 | Freescale SoC SEC Security Engines | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | - compatible : Should contain entries for this and backward compatible | ||
6 | SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" | ||
7 | - reg : Offset and length of the register set for the device | ||
8 | - interrupts : the SEC's interrupt number | ||
9 | - fsl,num-channels : An integer representing the number of channels | ||
10 | available. | ||
11 | - fsl,channel-fifo-len : An integer representing the number of | ||
12 | descriptor pointers each channel fetch fifo can hold. | ||
13 | - fsl,exec-units-mask : The bitmask representing what execution units | ||
14 | (EUs) are available. It's a single 32-bit cell. EU information | ||
15 | should be encoded following the SEC's Descriptor Header Dword | ||
16 | EU_SEL0 field documentation, i.e. as follows: | ||
17 | |||
18 | bit 0 = reserved - should be 0 | ||
19 | bit 1 = set if SEC has the ARC4 EU (AFEU) | ||
20 | bit 2 = set if SEC has the DES/3DES EU (DEU) | ||
21 | bit 3 = set if SEC has the message digest EU (MDEU/MDEU-A) | ||
22 | bit 4 = set if SEC has the random number generator EU (RNG) | ||
23 | bit 5 = set if SEC has the public key EU (PKEU) | ||
24 | bit 6 = set if SEC has the AES EU (AESU) | ||
25 | bit 7 = set if SEC has the Kasumi EU (KEU) | ||
26 | bit 8 = set if SEC has the CRC EU (CRCU) | ||
27 | bit 11 = set if SEC has the message digest EU extended alg set (MDEU-B) | ||
28 | |||
29 | remaining bits are reserved for future SEC EUs. | ||
30 | |||
31 | - fsl,descriptor-types-mask : The bitmask representing what descriptors | ||
32 | are available. It's a single 32-bit cell. Descriptor type information | ||
33 | should be encoded following the SEC's Descriptor Header Dword DESC_TYPE | ||
34 | field documentation, i.e. as follows: | ||
35 | |||
36 | bit 0 = set if SEC supports the aesu_ctr_nonsnoop desc. type | ||
37 | bit 1 = set if SEC supports the ipsec_esp descriptor type | ||
38 | bit 2 = set if SEC supports the common_nonsnoop desc. type | ||
39 | bit 3 = set if SEC supports the 802.11i AES ccmp desc. type | ||
40 | bit 4 = set if SEC supports the hmac_snoop_no_afeu desc. type | ||
41 | bit 5 = set if SEC supports the srtp descriptor type | ||
42 | bit 6 = set if SEC supports the non_hmac_snoop_no_afeu desc.type | ||
43 | bit 7 = set if SEC supports the pkeu_assemble descriptor type | ||
44 | bit 8 = set if SEC supports the aesu_key_expand_output desc.type | ||
45 | bit 9 = set if SEC supports the pkeu_ptmul descriptor type | ||
46 | bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type | ||
47 | bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type | ||
48 | |||
49 | ..and so on and so forth. | ||
50 | |||
51 | Optional properties: | ||
52 | |||
53 | - interrupt-parent : the phandle for the interrupt controller that | ||
54 | services interrupts for this device. | ||
55 | |||
56 | Example: | ||
57 | |||
58 | /* MPC8548E */ | ||
59 | crypto@30000 { | ||
60 | compatible = "fsl,sec2.1", "fsl,sec2.0"; | ||
61 | reg = <0x30000 0x10000>; | ||
62 | interrupts = <29 2>; | ||
63 | interrupt-parent = <&mpic>; | ||
64 | fsl,num-channels = <4>; | ||
65 | fsl,channel-fifo-len = <24>; | ||
66 | fsl,exec-units-mask = <0xfe>; | ||
67 | fsl,descriptor-types-mask = <0x12b0ebf>; | ||
68 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/spi.txt b/Documentation/powerpc/dts-bindings/fsl/spi.txt new file mode 100644 index 000000000000..e7d9a344c4f4 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/spi.txt | |||
@@ -0,0 +1,24 @@ | |||
1 | * SPI (Serial Peripheral Interface) | ||
2 | |||
3 | Required properties: | ||
4 | - cell-index : SPI controller index. | ||
5 | - compatible : should be "fsl,spi". | ||
6 | - mode : the SPI operation mode, it can be "cpu" or "cpu-qe". | ||
7 | - reg : Offset and length of the register set for the device | ||
8 | - interrupts : <a b> where a is the interrupt number and b is a | ||
9 | field that represents an encoding of the sense and level | ||
10 | information for the interrupt. This should be encoded based on | ||
11 | the information in section 2) depending on the type of interrupt | ||
12 | controller you have. | ||
13 | - interrupt-parent : the phandle for the interrupt controller that | ||
14 | services interrupts for this device. | ||
15 | |||
16 | Example: | ||
17 | spi@4c0 { | ||
18 | cell-index = <0>; | ||
19 | compatible = "fsl,spi"; | ||
20 | reg = <4c0 40>; | ||
21 | interrupts = <82 0>; | ||
22 | interrupt-parent = <700>; | ||
23 | mode = "cpu"; | ||
24 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt b/Documentation/powerpc/dts-bindings/fsl/ssi.txt new file mode 100644 index 000000000000..d100555d488a --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt | |||
@@ -0,0 +1,38 @@ | |||
1 | Freescale Synchronous Serial Interface | ||
2 | |||
3 | The SSI is a serial device that communicates with audio codecs. It can | ||
4 | be programmed in AC97, I2S, left-justified, or right-justified modes. | ||
5 | |||
6 | Required properties: | ||
7 | - compatible : compatible list, containing "fsl,ssi" | ||
8 | - cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on | ||
9 | - reg : offset and length of the register set for the device | ||
10 | - interrupts : <a b> where a is the interrupt number and b is a | ||
11 | field that represents an encoding of the sense and | ||
12 | level information for the interrupt. This should be | ||
13 | encoded based on the information in section 2) | ||
14 | depending on the type of interrupt controller you | ||
15 | have. | ||
16 | - interrupt-parent : the phandle for the interrupt controller that | ||
17 | services interrupts for this device. | ||
18 | - fsl,mode : the operating mode for the SSI interface | ||
19 | "i2s-slave" - I2S mode, SSI is clock slave | ||
20 | "i2s-master" - I2S mode, SSI is clock master | ||
21 | "lj-slave" - left-justified mode, SSI is clock slave | ||
22 | "lj-master" - l.j. mode, SSI is clock master | ||
23 | "rj-slave" - right-justified mode, SSI is clock slave | ||
24 | "rj-master" - r.j., SSI is clock master | ||
25 | "ac97-slave" - AC97 mode, SSI is clock slave | ||
26 | "ac97-master" - AC97 mode, SSI is clock master | ||
27 | |||
28 | Optional properties: | ||
29 | - codec-handle : phandle to a 'codec' node that defines an audio | ||
30 | codec connected to this SSI. This node is typically | ||
31 | a child of an I2C or other control node. | ||
32 | |||
33 | Child 'codec' node required properties: | ||
34 | - compatible : compatible list, contains the name of the codec | ||
35 | |||
36 | Child 'codec' node optional properties: | ||
37 | - clock-frequency : The frequency of the input clock, which typically | ||
38 | comes from an on-board dedicated oscillator. | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt b/Documentation/powerpc/dts-bindings/fsl/tsec.txt new file mode 100644 index 000000000000..cf55fa4112d2 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/tsec.txt | |||
@@ -0,0 +1,62 @@ | |||
1 | * MDIO IO device | ||
2 | |||
3 | The MDIO is a bus to which the PHY devices are connected. For each | ||
4 | device that exists on this bus, a child node should be created. See | ||
5 | the definition of the PHY node below for an example of how to define | ||
6 | a PHY. | ||
7 | |||
8 | Required properties: | ||
9 | - reg : Offset and length of the register set for the device | ||
10 | - compatible : Should define the compatible device type for the | ||
11 | mdio. Currently, this is most likely to be "fsl,gianfar-mdio" | ||
12 | |||
13 | Example: | ||
14 | |||
15 | mdio@24520 { | ||
16 | reg = <24520 20>; | ||
17 | compatible = "fsl,gianfar-mdio"; | ||
18 | |||
19 | ethernet-phy@0 { | ||
20 | ...... | ||
21 | }; | ||
22 | }; | ||
23 | |||
24 | |||
25 | * Gianfar-compatible ethernet nodes | ||
26 | |||
27 | Properties: | ||
28 | |||
29 | - device_type : Should be "network" | ||
30 | - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC" | ||
31 | - compatible : Should be "gianfar" | ||
32 | - reg : Offset and length of the register set for the device | ||
33 | - local-mac-address : List of bytes representing the ethernet address of | ||
34 | this controller | ||
35 | - interrupts : For FEC devices, the first interrupt is the device's | ||
36 | interrupt. For TSEC and eTSEC devices, the first interrupt is | ||
37 | transmit, the second is receive, and the third is error. | ||
38 | - phy-handle : The phandle for the PHY connected to this ethernet | ||
39 | controller. | ||
40 | - fixed-link : <a b c d e> where a is emulated phy id - choose any, | ||
41 | but unique to the all specified fixed-links, b is duplex - 0 half, | ||
42 | 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no | ||
43 | pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. | ||
44 | - phy-connection-type : a string naming the controller/PHY interface type, | ||
45 | i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii", | ||
46 | "tbi", or "rtbi". This property is only really needed if the connection | ||
47 | is of type "rgmii-id", as all other connection types are detected by | ||
48 | hardware. | ||
49 | - fsl,magic-packet : If present, indicates that the hardware supports | ||
50 | waking up via magic packet. | ||
51 | |||
52 | Example: | ||
53 | ethernet@24000 { | ||
54 | device_type = "network"; | ||
55 | model = "TSEC"; | ||
56 | compatible = "gianfar"; | ||
57 | reg = <0x24000 0x1000>; | ||
58 | local-mac-address = [ 00 E0 0C 00 73 00 ]; | ||
59 | interrupts = <29 2 30 2 34 2>; | ||
60 | interrupt-parent = <&mpic>; | ||
61 | phy-handle = <&phy0> | ||
62 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt new file mode 100644 index 000000000000..84a04d5eb8e6 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt | |||
@@ -0,0 +1,28 @@ | |||
1 | Freescale Localbus UPM programmed to work with NAND flash | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : "fsl,upm-nand". | ||
5 | - reg : should specify localbus chip select and size used for the chip. | ||
6 | - fsl,upm-addr-offset : UPM pattern offset for the address latch. | ||
7 | - fsl,upm-cmd-offset : UPM pattern offset for the command latch. | ||
8 | - gpios : may specify optional GPIO connected to the Ready-Not-Busy pin. | ||
9 | |||
10 | Example: | ||
11 | |||
12 | upm@1,0 { | ||
13 | compatible = "fsl,upm-nand"; | ||
14 | reg = <1 0 1>; | ||
15 | fsl,upm-addr-offset = <16>; | ||
16 | fsl,upm-cmd-offset = <8>; | ||
17 | gpios = <&qe_pio_e 18 0>; | ||
18 | |||
19 | flash { | ||
20 | #address-cells = <1>; | ||
21 | #size-cells = <1>; | ||
22 | compatible = "..."; | ||
23 | |||
24 | partition@0 { | ||
25 | ... | ||
26 | }; | ||
27 | }; | ||
28 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/usb.txt b/Documentation/powerpc/dts-bindings/fsl/usb.txt new file mode 100644 index 000000000000..b00152402694 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/usb.txt | |||
@@ -0,0 +1,59 @@ | |||
1 | Freescale SOC USB controllers | ||
2 | |||
3 | The device node for a USB controller that is part of a Freescale | ||
4 | SOC is as described in the document "Open Firmware Recommended | ||
5 | Practice : Universal Serial Bus" with the following modifications | ||
6 | and additions : | ||
7 | |||
8 | Required properties : | ||
9 | - compatible : Should be "fsl-usb2-mph" for multi port host USB | ||
10 | controllers, or "fsl-usb2-dr" for dual role USB controllers | ||
11 | - phy_type : For multi port host USB controllers, should be one of | ||
12 | "ulpi", or "serial". For dual role USB controllers, should be | ||
13 | one of "ulpi", "utmi", "utmi_wide", or "serial". | ||
14 | - reg : Offset and length of the register set for the device | ||
15 | - port0 : boolean; if defined, indicates port0 is connected for | ||
16 | fsl-usb2-mph compatible controllers. Either this property or | ||
17 | "port1" (or both) must be defined for "fsl-usb2-mph" compatible | ||
18 | controllers. | ||
19 | - port1 : boolean; if defined, indicates port1 is connected for | ||
20 | fsl-usb2-mph compatible controllers. Either this property or | ||
21 | "port0" (or both) must be defined for "fsl-usb2-mph" compatible | ||
22 | controllers. | ||
23 | - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible | ||
24 | controllers. Can be "host", "peripheral", or "otg". Default to | ||
25 | "host" if not defined for backward compatibility. | ||
26 | |||
27 | Recommended properties : | ||
28 | - interrupts : <a b> where a is the interrupt number and b is a | ||
29 | field that represents an encoding of the sense and level | ||
30 | information for the interrupt. This should be encoded based on | ||
31 | the information in section 2) depending on the type of interrupt | ||
32 | controller you have. | ||
33 | - interrupt-parent : the phandle for the interrupt controller that | ||
34 | services interrupts for this device. | ||
35 | |||
36 | Example multi port host USB controller device node : | ||
37 | usb@22000 { | ||
38 | compatible = "fsl-usb2-mph"; | ||
39 | reg = <22000 1000>; | ||
40 | #address-cells = <1>; | ||
41 | #size-cells = <0>; | ||
42 | interrupt-parent = <700>; | ||
43 | interrupts = <27 1>; | ||
44 | phy_type = "ulpi"; | ||
45 | port0; | ||
46 | port1; | ||
47 | }; | ||
48 | |||
49 | Example dual role USB controller device node : | ||
50 | usb@23000 { | ||
51 | compatible = "fsl-usb2-dr"; | ||
52 | reg = <23000 1000>; | ||
53 | #address-cells = <1>; | ||
54 | #size-cells = <0>; | ||
55 | interrupt-parent = <700>; | ||
56 | interrupts = <26 1>; | ||
57 | dr_mode = "otg"; | ||
58 | phy = "ulpi"; | ||
59 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt b/Documentation/powerpc/dts-bindings/gpio/led.txt new file mode 100644 index 000000000000..ff51f4c0fa9d --- /dev/null +++ b/Documentation/powerpc/dts-bindings/gpio/led.txt | |||
@@ -0,0 +1,15 @@ | |||
1 | LED connected to GPIO | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : should be "gpio-led". | ||
5 | - label : (optional) the label for this LED. If omitted, the label is | ||
6 | taken from the node name (excluding the unit address). | ||
7 | - gpios : should specify LED GPIO. | ||
8 | |||
9 | Example: | ||
10 | |||
11 | led@0 { | ||
12 | compatible = "gpio-led"; | ||
13 | label = "hdd"; | ||
14 | gpios = <&mcu_pio 0 1>; | ||
15 | }; | ||
diff --git a/Documentation/powerpc/qe_firmware.txt b/Documentation/powerpc/qe_firmware.txt index 896266432d33..06da4d4b44f9 100644 --- a/Documentation/powerpc/qe_firmware.txt +++ b/Documentation/powerpc/qe_firmware.txt | |||
@@ -217,7 +217,7 @@ Although it is not recommended, you can specify '0' in the soc.model | |||
217 | field to skip matching SOCs altogether. | 217 | field to skip matching SOCs altogether. |
218 | 218 | ||
219 | The 'model' field is a 16-bit number that matches the actual SOC. The | 219 | The 'model' field is a 16-bit number that matches the actual SOC. The |
220 | 'major' and 'minor' fields are the major and minor revision numbrs, | 220 | 'major' and 'minor' fields are the major and minor revision numbers, |
221 | respectively, of the SOC. | 221 | respectively, of the SOC. |
222 | 222 | ||
223 | For example, to match the 8323, revision 1.0: | 223 | For example, to match the 8323, revision 1.0: |
diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt index a83ff23cd68c..28b6ec87c642 100644 --- a/Documentation/rfkill.txt +++ b/Documentation/rfkill.txt | |||
@@ -1,89 +1,540 @@ | |||
1 | rfkill - RF switch subsystem support | 1 | rfkill - RF switch subsystem support |
2 | ==================================== | 2 | ==================================== |
3 | 3 | ||
4 | 1 Implementation details | 4 | 1 Introduction |
5 | 2 Driver support | 5 | 2 Implementation details |
6 | 3 Userspace support | 6 | 3 Kernel driver guidelines |
7 | 3.1 wireless device drivers | ||
8 | 3.2 platform/switch drivers | ||
9 | 3.3 input device drivers | ||
10 | 4 Kernel API | ||
11 | 5 Userspace support | ||
7 | 12 | ||
8 | =============================================================================== | ||
9 | 1: Implementation details | ||
10 | 13 | ||
11 | The rfkill switch subsystem offers support for keys often found on laptops | 14 | 1. Introduction: |
12 | to enable wireless devices like WiFi and Bluetooth. | 15 | |
16 | The rfkill switch subsystem exists to add a generic interface to circuitry that | ||
17 | can enable or disable the signal output of a wireless *transmitter* of any | ||
18 | type. By far, the most common use is to disable radio-frequency transmitters. | ||
13 | 19 | ||
14 | This is done by providing the user 3 possibilities: | 20 | Note that disabling the signal output means that the the transmitter is to be |
15 | 1 - The rfkill system handles all events; userspace is not aware of events. | 21 | made to not emit any energy when "blocked". rfkill is not about blocking data |
16 | 2 - The rfkill system handles all events; userspace is informed about the events. | 22 | transmissions, it is about blocking energy emission. |
17 | 3 - The rfkill system does not handle events; userspace handles all events. | ||
18 | 23 | ||
19 | The buttons to enable and disable the wireless radios are important in | 24 | The rfkill subsystem offers support for keys and switches often found on |
25 | laptops to enable wireless devices like WiFi and Bluetooth, so that these keys | ||
26 | and switches actually perform an action in all wireless devices of a given type | ||
27 | attached to the system. | ||
28 | |||
29 | The buttons to enable and disable the wireless transmitters are important in | ||
20 | situations where the user is for example using his laptop on a location where | 30 | situations where the user is for example using his laptop on a location where |
21 | wireless radios _must_ be disabled (e.g. airplanes). | 31 | radio-frequency transmitters _must_ be disabled (e.g. airplanes). |
22 | Because of this requirement, userspace support for the keys should not be | 32 | |
23 | made mandatory. Because userspace might want to perform some additional smarter | 33 | Because of this requirement, userspace support for the keys should not be made |
24 | tasks when the key is pressed, rfkill still provides userspace the possibility | 34 | mandatory. Because userspace might want to perform some additional smarter |
25 | to take over the task to handle the key events. | 35 | tasks when the key is pressed, rfkill provides userspace the possibility to |
36 | take over the task to handle the key events. | ||
37 | |||
38 | =============================================================================== | ||
39 | 2: Implementation details | ||
40 | |||
41 | The rfkill subsystem is composed of various components: the rfkill class, the | ||
42 | rfkill-input module (an input layer handler), and some specific input layer | ||
43 | events. | ||
44 | |||
45 | The rfkill class provides kernel drivers with an interface that allows them to | ||
46 | know when they should enable or disable a wireless network device transmitter. | ||
47 | This is enabled by the CONFIG_RFKILL Kconfig option. | ||
48 | |||
49 | The rfkill class support makes sure userspace will be notified of all state | ||
50 | changes on rfkill devices through uevents. It provides a notification chain | ||
51 | for interested parties in the kernel to also get notified of rfkill state | ||
52 | changes in other drivers. It creates several sysfs entries which can be used | ||
53 | by userspace. See section "Userspace support". | ||
54 | |||
55 | The rfkill-input module provides the kernel with the ability to implement a | ||
56 | basic response when the user presses a key or button (or toggles a switch) | ||
57 | related to rfkill functionality. It is an in-kernel implementation of default | ||
58 | policy of reacting to rfkill-related input events and neither mandatory nor | ||
59 | required for wireless drivers to operate. It is enabled by the | ||
60 | CONFIG_RFKILL_INPUT Kconfig option. | ||
61 | |||
62 | rfkill-input is a rfkill-related events input layer handler. This handler will | ||
63 | listen to all rfkill key events and will change the rfkill state of the | ||
64 | wireless devices accordingly. With this option enabled userspace could either | ||
65 | do nothing or simply perform monitoring tasks. | ||
66 | |||
67 | The rfkill-input module also provides EPO (emergency power-off) functionality | ||
68 | for all wireless transmitters. This function cannot be overridden, and it is | ||
69 | always active. rfkill EPO is related to *_RFKILL_ALL input layer events. | ||
70 | |||
71 | |||
72 | Important terms for the rfkill subsystem: | ||
73 | |||
74 | In order to avoid confusion, we avoid the term "switch" in rfkill when it is | ||
75 | referring to an electronic control circuit that enables or disables a | ||
76 | transmitter. We reserve it for the physical device a human manipulates | ||
77 | (which is an input device, by the way): | ||
78 | |||
79 | rfkill switch: | ||
80 | |||
81 | A physical device a human manipulates. Its state can be perceived by | ||
82 | the kernel either directly (through a GPIO pin, ACPI GPE) or by its | ||
83 | effect on a rfkill line of a wireless device. | ||
84 | |||
85 | rfkill controller: | ||
86 | |||
87 | A hardware circuit that controls the state of a rfkill line, which a | ||
88 | kernel driver can interact with *to modify* that state (i.e. it has | ||
89 | either write-only or read/write access). | ||
90 | |||
91 | rfkill line: | ||
92 | |||
93 | An input channel (hardware or software) of a wireless device, which | ||
94 | causes a wireless transmitter to stop emitting energy (BLOCK) when it | ||
95 | is active. Point of view is extremely important here: rfkill lines are | ||
96 | always seen from the PoV of a wireless device (and its driver). | ||
97 | |||
98 | soft rfkill line/software rfkill line: | ||
99 | |||
100 | A rfkill line the wireless device driver can directly change the state | ||
101 | of. Related to rfkill_state RFKILL_STATE_SOFT_BLOCKED. | ||
102 | |||
103 | hard rfkill line/hardware rfkill line: | ||
104 | |||
105 | A rfkill line that works fully in hardware or firmware, and that cannot | ||
106 | be overridden by the kernel driver. The hardware device or the | ||
107 | firmware just exports its status to the driver, but it is read-only. | ||
108 | Related to rfkill_state RFKILL_STATE_HARD_BLOCKED. | ||
109 | |||
110 | The enum rfkill_state describes the rfkill state of a transmitter: | ||
111 | |||
112 | When a rfkill line or rfkill controller is in the RFKILL_STATE_UNBLOCKED state, | ||
113 | the wireless transmitter (radio TX circuit for example) is *enabled*. When the | ||
114 | it is in the RFKILL_STATE_SOFT_BLOCKED or RFKILL_STATE_HARD_BLOCKED, the | ||
115 | wireless transmitter is to be *blocked* from operating. | ||
116 | |||
117 | RFKILL_STATE_SOFT_BLOCKED indicates that a call to toggle_radio() can change | ||
118 | that state. RFKILL_STATE_HARD_BLOCKED indicates that a call to toggle_radio() | ||
119 | will not be able to change the state and will return with a suitable error if | ||
120 | attempts are made to set the state to RFKILL_STATE_UNBLOCKED. | ||
121 | |||
122 | RFKILL_STATE_HARD_BLOCKED is used by drivers to signal that the device is | ||
123 | locked in the BLOCKED state by a hardwire rfkill line (typically an input pin | ||
124 | that, when active, forces the transmitter to be disabled) which the driver | ||
125 | CANNOT override. | ||
126 | |||
127 | Full rfkill functionality requires two different subsystems to cooperate: the | ||
128 | input layer and the rfkill class. The input layer issues *commands* to the | ||
129 | entire system requesting that devices registered to the rfkill class change | ||
130 | state. The way this interaction happens is not complex, but it is not obvious | ||
131 | either: | ||
26 | 132 | ||
27 | The system inside the kernel has been split into 2 separate sections: | 133 | Kernel Input layer: |
28 | 1 - RFKILL | ||
29 | 2 - RFKILL_INPUT | ||
30 | 134 | ||
31 | The first option enables rfkill support and will make sure userspace will | 135 | * Generates KEY_WWAN, KEY_WLAN, KEY_BLUETOOTH, SW_RFKILL_ALL, and |
32 | be notified of any events through the input device. It also creates several | 136 | other such events when the user presses certain keys, buttons, or |
33 | sysfs entries which can be used by userspace. See section "Userspace support". | 137 | toggles certain physical switches. |
34 | 138 | ||
35 | The second option provides an rfkill input handler. This handler will | 139 | THE INPUT LAYER IS NEVER USED TO PROPAGATE STATUS, NOTIFICATIONS OR THE |
36 | listen to all rfkill key events and will toggle the radio accordingly. | 140 | KIND OF STUFF AN ON-SCREEN-DISPLAY APPLICATION WOULD REPORT. It is |
37 | With this option enabled userspace could either do nothing or simply | 141 | used to issue *commands* for the system to change behaviour, and these |
38 | perform monitoring tasks. | 142 | commands may or may not be carried out by some kernel driver or |
143 | userspace application. It follows that doing user feedback based only | ||
144 | on input events is broken, as there is no guarantee that an input event | ||
145 | will be acted upon. | ||
39 | 146 | ||
147 | Most wireless communication device drivers implementing rfkill | ||
148 | functionality MUST NOT generate these events, and have no reason to | ||
149 | register themselves with the input layer. Doing otherwise is a common | ||
150 | misconception. There is an API to propagate rfkill status change | ||
151 | information, and it is NOT the input layer. | ||
152 | |||
153 | rfkill class: | ||
154 | |||
155 | * Calls a hook in a driver to effectively change the wireless | ||
156 | transmitter state; | ||
157 | * Keeps track of the wireless transmitter state (with help from | ||
158 | the driver); | ||
159 | * Generates userspace notifications (uevents) and a call to a | ||
160 | notification chain (kernel) when there is a wireless transmitter | ||
161 | state change; | ||
162 | * Connects a wireless communications driver with the common rfkill | ||
163 | control system, which, for example, allows actions such as | ||
164 | "switch all bluetooth devices offline" to be carried out by | ||
165 | userspace or by rfkill-input. | ||
166 | |||
167 | THE RFKILL CLASS NEVER ISSUES INPUT EVENTS. THE RFKILL CLASS DOES | ||
168 | NOT LISTEN TO INPUT EVENTS. NO DRIVER USING THE RFKILL CLASS SHALL | ||
169 | EVER LISTEN TO, OR ACT ON RFKILL INPUT EVENTS. Doing otherwise is | ||
170 | a layering violation. | ||
171 | |||
172 | Most wireless data communication drivers in the kernel have just to | ||
173 | implement the rfkill class API to work properly. Interfacing to the | ||
174 | input layer is not often required (and is very often a *bug*) on | ||
175 | wireless drivers. | ||
176 | |||
177 | Platform drivers often have to attach to the input layer to *issue* | ||
178 | (but never to listen to) rfkill events for rfkill switches, and also to | ||
179 | the rfkill class to export a control interface for the platform rfkill | ||
180 | controllers to the rfkill subsystem. This does NOT mean the rfkill | ||
181 | switch is attached to a rfkill class (doing so is almost always wrong). | ||
182 | It just means the same kernel module is the driver for different | ||
183 | devices (rfkill switches and rfkill controllers). | ||
184 | |||
185 | |||
186 | Userspace input handlers (uevents) or kernel input handlers (rfkill-input): | ||
187 | |||
188 | * Implements the policy of what should happen when one of the input | ||
189 | layer events related to rfkill operation is received. | ||
190 | * Uses the sysfs interface (userspace) or private rfkill API calls | ||
191 | to tell the devices registered with the rfkill class to change | ||
192 | their state (i.e. translates the input layer event into real | ||
193 | action). | ||
194 | * rfkill-input implements EPO by handling EV_SW SW_RFKILL_ALL 0 | ||
195 | (power off all transmitters) in a special way: it ignores any | ||
196 | overrides and local state cache and forces all transmitters to the | ||
197 | RFKILL_STATE_SOFT_BLOCKED state (including those which are already | ||
198 | supposed to be BLOCKED). Note that the opposite event (power on all | ||
199 | transmitters) is handled normally. | ||
200 | |||
201 | Userspace uevent handler or kernel platform-specific drivers hooked to the | ||
202 | rfkill notifier chain: | ||
203 | |||
204 | * Taps into the rfkill notifier chain or to KOBJ_CHANGE uevents, | ||
205 | in order to know when a device that is registered with the rfkill | ||
206 | class changes state; | ||
207 | * Issues feedback notifications to the user; | ||
208 | * In the rare platforms where this is required, synthesizes an input | ||
209 | event to command all *OTHER* rfkill devices to also change their | ||
210 | statues when a specific rfkill device changes state. | ||
211 | |||
212 | |||
213 | =============================================================================== | ||
214 | 3: Kernel driver guidelines | ||
215 | |||
216 | Remember: point-of-view is everything for a driver that connects to the rfkill | ||
217 | subsystem. All the details below must be measured/perceived from the point of | ||
218 | view of the specific driver being modified. | ||
219 | |||
220 | The first thing one needs to know is whether his driver should be talking to | ||
221 | the rfkill class or to the input layer. In rare cases (platform drivers), it | ||
222 | could happen that you need to do both, as platform drivers often handle a | ||
223 | variety of devices in the same driver. | ||
224 | |||
225 | Do not mistake input devices for rfkill controllers. The only type of "rfkill | ||
226 | switch" device that is to be registered with the rfkill class are those | ||
227 | directly controlling the circuits that cause a wireless transmitter to stop | ||
228 | working (or the software equivalent of them), i.e. what we call a rfkill | ||
229 | controller. Every other kind of "rfkill switch" is just an input device and | ||
230 | MUST NOT be registered with the rfkill class. | ||
231 | |||
232 | A driver should register a device with the rfkill class when ALL of the | ||
233 | following conditions are met (they define a rfkill controller): | ||
234 | |||
235 | 1. The device is/controls a data communications wireless transmitter; | ||
236 | |||
237 | 2. The kernel can interact with the hardware/firmware to CHANGE the wireless | ||
238 | transmitter state (block/unblock TX operation); | ||
239 | |||
240 | 3. The transmitter can be made to not emit any energy when "blocked": | ||
241 | rfkill is not about blocking data transmissions, it is about blocking | ||
242 | energy emission; | ||
243 | |||
244 | A driver should register a device with the input subsystem to issue | ||
245 | rfkill-related events (KEY_WLAN, KEY_BLUETOOTH, KEY_WWAN, KEY_WIMAX, | ||
246 | SW_RFKILL_ALL, etc) when ALL of the folowing conditions are met: | ||
247 | |||
248 | 1. It is directly related to some physical device the user interacts with, to | ||
249 | command the O.S./firmware/hardware to enable/disable a data communications | ||
250 | wireless transmitter. | ||
251 | |||
252 | Examples of the physical device are: buttons, keys and switches the user | ||
253 | will press/touch/slide/switch to enable or disable the wireless | ||
254 | communication device. | ||
255 | |||
256 | 2. It is NOT slaved to another device, i.e. there is no other device that | ||
257 | issues rfkill-related input events in preference to this one. | ||
258 | |||
259 | Please refer to the corner cases and examples section for more details. | ||
260 | |||
261 | When in doubt, do not issue input events. For drivers that should generate | ||
262 | input events in some platforms, but not in others (e.g. b43), the best solution | ||
263 | is to NEVER generate input events in the first place. That work should be | ||
264 | deferred to a platform-specific kernel module (which will know when to generate | ||
265 | events through the rfkill notifier chain) or to userspace. This avoids the | ||
266 | usual maintenance problems with DMI whitelisting. | ||
267 | |||
268 | |||
269 | Corner cases and examples: | ||
40 | ==================================== | 270 | ==================================== |
41 | 2: Driver support | ||
42 | 271 | ||
43 | To build a driver with rfkill subsystem support, the driver should | 272 | 1. If the device is an input device that, because of hardware or firmware, |
44 | depend on the Kconfig symbol RFKILL; it should _not_ depend on | 273 | causes wireless transmitters to be blocked regardless of the kernel's will, it |
45 | RKFILL_INPUT. | 274 | is still just an input device, and NOT to be registered with the rfkill class. |
46 | 275 | ||
47 | Unless key events trigger an interrupt to which the driver listens, polling | 276 | 2. If the wireless transmitter switch control is read-only, it is an input |
48 | will be required to determine the key state changes. For this the input | 277 | device and not to be registered with the rfkill class (and maybe not to be made |
49 | layer providers the input-polldev handler. | 278 | an input layer event source either, see below). |
50 | 279 | ||
51 | A driver should implement a few steps to correctly make use of the | 280 | 3. If there is some other device driver *closer* to the actual hardware the |
52 | rfkill subsystem. First for non-polling drivers: | 281 | user interacted with (the button/switch/key) to issue an input event, THAT is |
282 | the device driver that should be issuing input events. | ||
53 | 283 | ||
54 | - rfkill_allocate() | 284 | E.g: |
55 | - input_allocate_device() | 285 | [RFKILL slider switch] -- [GPIO hardware] -- [WLAN card rf-kill input] |
56 | - rfkill_register() | 286 | (platform driver) (wireless card driver) |
57 | - input_register_device() | 287 | |
288 | The user is closer to the RFKILL slide switch plaform driver, so the driver | ||
289 | which must issue input events is the platform driver looking at the GPIO | ||
290 | hardware, and NEVER the wireless card driver (which is just a slave). It is | ||
291 | very likely that there are other leaves than just the WLAN card rf-kill input | ||
292 | (e.g. a bluetooth card, etc)... | ||
293 | |||
294 | On the other hand, some embedded devices do this: | ||
295 | |||
296 | [RFKILL slider switch] -- [WLAN card rf-kill input] | ||
297 | (wireless card driver) | ||
298 | |||
299 | In this situation, the wireless card driver *could* register itself as an input | ||
300 | device and issue rf-kill related input events... but in order to AVOID the need | ||
301 | for DMI whitelisting, the wireless card driver does NOT do it. Userspace (HAL) | ||
302 | or a platform driver (that exists only on these embedded devices) will do the | ||
303 | dirty job of issuing the input events. | ||
304 | |||
305 | |||
306 | COMMON MISTAKES in kernel drivers, related to rfkill: | ||
307 | ==================================== | ||
308 | |||
309 | 1. NEVER confuse input device keys and buttons with input device switches. | ||
310 | |||
311 | 1a. Switches are always set or reset. They report the current state | ||
312 | (on position or off position). | ||
313 | |||
314 | 1b. Keys and buttons are either in the pressed or not-pressed state, and | ||
315 | that's it. A "button" that latches down when you press it, and | ||
316 | unlatches when you press it again is in fact a switch as far as input | ||
317 | devices go. | ||
318 | |||
319 | Add the SW_* events you need for switches, do NOT try to emulate a button using | ||
320 | KEY_* events just because there is no such SW_* event yet. Do NOT try to use, | ||
321 | for example, KEY_BLUETOOTH when you should be using SW_BLUETOOTH instead. | ||
322 | |||
323 | 2. Input device switches (sources of EV_SW events) DO store their current state | ||
324 | (so you *must* initialize it by issuing a gratuitous input layer event on | ||
325 | driver start-up and also when resuming from sleep), and that state CAN be | ||
326 | queried from userspace through IOCTLs. There is no sysfs interface for this, | ||
327 | but that doesn't mean you should break things trying to hook it to the rfkill | ||
328 | class to get a sysfs interface :-) | ||
329 | |||
330 | 3. Do not issue *_RFKILL_ALL events by default, unless you are sure it is the | ||
331 | correct event for your switch/button. These events are emergency power-off | ||
332 | events when they are trying to turn the transmitters off. An example of an | ||
333 | input device which SHOULD generate *_RFKILL_ALL events is the wireless-kill | ||
334 | switch in a laptop which is NOT a hotkey, but a real switch that kills radios | ||
335 | in hardware, even if the O.S. has gone to lunch. An example of an input device | ||
336 | which SHOULD NOT generate *_RFKILL_ALL events by default, is any sort of hot | ||
337 | key that does nothing by itself, as well as any hot key that is type-specific | ||
338 | (e.g. the one for WLAN). | ||
339 | |||
340 | |||
341 | 3.1 Guidelines for wireless device drivers | ||
342 | ------------------------------------------ | ||
343 | |||
344 | 1. Each independent transmitter in a wireless device (usually there is only one | ||
345 | transmitter per device) should have a SINGLE rfkill class attached to it. | ||
346 | |||
347 | 2. If the device does not have any sort of hardware assistance to allow the | ||
348 | driver to rfkill the device, the driver should emulate it by taking all actions | ||
349 | required to silence the transmitter. | ||
350 | |||
351 | 3. If it is impossible to silence the transmitter (i.e. it still emits energy, | ||
352 | even if it is just in brief pulses, when there is no data to transmit and there | ||
353 | is no hardware support to turn it off) do NOT lie to the users. Do not attach | ||
354 | it to a rfkill class. The rfkill subsystem does not deal with data | ||
355 | transmission, it deals with energy emission. If the transmitter is emitting | ||
356 | energy, it is not blocked in rfkill terms. | ||
357 | |||
358 | 4. It doesn't matter if the device has multiple rfkill input lines affecting | ||
359 | the same transmitter, their combined state is to be exported as a single state | ||
360 | per transmitter (see rule 1). | ||
361 | |||
362 | This rule exists because users of the rfkill subsystem expect to get (and set, | ||
363 | when possible) the overall transmitter rfkill state, not of a particular rfkill | ||
364 | line. | ||
365 | |||
366 | Example of a WLAN wireless driver connected to the rfkill subsystem: | ||
367 | -------------------------------------------------------------------- | ||
368 | |||
369 | A certain WLAN card has one input pin that causes it to block the transmitter | ||
370 | and makes the status of that input pin available (only for reading!) to the | ||
371 | kernel driver. This is a hard rfkill input line (it cannot be overridden by | ||
372 | the kernel driver). | ||
373 | |||
374 | The card also has one PCI register that, if manipulated by the driver, causes | ||
375 | it to block the transmitter. This is a soft rfkill input line. | ||
376 | |||
377 | It has also a thermal protection circuitry that shuts down its transmitter if | ||
378 | the card overheats, and makes the status of that protection available (only for | ||
379 | reading!) to the kernel driver. This is also a hard rfkill input line. | ||
380 | |||
381 | If either one of these rfkill lines are active, the transmitter is blocked by | ||
382 | the hardware and forced offline. | ||
383 | |||
384 | The driver should allocate and attach to its struct device *ONE* instance of | ||
385 | the rfkill class (there is only one transmitter). | ||
386 | |||
387 | It can implement the get_state() hook, and return RFKILL_STATE_HARD_BLOCKED if | ||
388 | either one of its two hard rfkill input lines are active. If the two hard | ||
389 | rfkill lines are inactive, it must return RFKILL_STATE_SOFT_BLOCKED if its soft | ||
390 | rfkill input line is active. Only if none of the rfkill input lines are | ||
391 | active, will it return RFKILL_STATE_UNBLOCKED. | ||
392 | |||
393 | Since the device has a hardware rfkill line, it IS subject to state changes | ||
394 | external to rfkill. Therefore, the driver must make sure that it calls | ||
395 | rfkill_force_state() to keep the status always up-to-date, and it must do a | ||
396 | rfkill_force_state() on resume from sleep. | ||
58 | 397 | ||
59 | For polling drivers: | 398 | Every time the driver gets a notification from the card that one of its rfkill |
399 | lines changed state (polling might be needed on badly designed cards that don't | ||
400 | generate interrupts for such events), it recomputes the rfkill state as per | ||
401 | above, and calls rfkill_force_state() to update it. | ||
60 | 402 | ||
403 | The driver should implement the toggle_radio() hook, that: | ||
404 | |||
405 | 1. Returns an error if one of the hardware rfkill lines are active, and the | ||
406 | caller asked for RFKILL_STATE_UNBLOCKED. | ||
407 | |||
408 | 2. Activates the soft rfkill line if the caller asked for state | ||
409 | RFKILL_STATE_SOFT_BLOCKED. It should do this even if one of the hard rfkill | ||
410 | lines are active, effectively double-blocking the transmitter. | ||
411 | |||
412 | 3. Deactivates the soft rfkill line if none of the hardware rfkill lines are | ||
413 | active and the caller asked for RFKILL_STATE_UNBLOCKED. | ||
414 | |||
415 | =============================================================================== | ||
416 | 4: Kernel API | ||
417 | |||
418 | To build a driver with rfkill subsystem support, the driver should depend on | ||
419 | (or select) the Kconfig symbol RFKILL; it should _not_ depend on RKFILL_INPUT. | ||
420 | |||
421 | The hardware the driver talks to may be write-only (where the current state | ||
422 | of the hardware is unknown), or read-write (where the hardware can be queried | ||
423 | about its current state). | ||
424 | |||
425 | The rfkill class will call the get_state hook of a device every time it needs | ||
426 | to know the *real* current state of the hardware. This can happen often, but | ||
427 | it does not do any polling, so it is not enough on hardware that is subject | ||
428 | to state changes outside of the rfkill subsystem. | ||
429 | |||
430 | Therefore, calling rfkill_force_state() when a state change happens is | ||
431 | mandatory when the device has a hardware rfkill line, or when something else | ||
432 | like the firmware could cause its state to be changed without going through the | ||
433 | rfkill class. | ||
434 | |||
435 | Some hardware provides events when its status changes. In these cases, it is | ||
436 | best for the driver to not provide a get_state hook, and instead register the | ||
437 | rfkill class *already* with the correct status, and keep it updated using | ||
438 | rfkill_force_state() when it gets an event from the hardware. | ||
439 | |||
440 | rfkill_force_state() must be used on the device resume handlers to update the | ||
441 | rfkill status, should there be any chance of the device status changing during | ||
442 | the sleep. | ||
443 | |||
444 | There is no provision for a statically-allocated rfkill struct. You must | ||
445 | use rfkill_allocate() to allocate one. | ||
446 | |||
447 | You should: | ||
61 | - rfkill_allocate() | 448 | - rfkill_allocate() |
62 | - input_allocate_polled_device() | 449 | - modify rfkill fields (flags, name) |
450 | - modify state to the current hardware state (THIS IS THE ONLY TIME | ||
451 | YOU CAN ACCESS state DIRECTLY) | ||
63 | - rfkill_register() | 452 | - rfkill_register() |
64 | - input_register_polled_device() | ||
65 | 453 | ||
66 | When a key event has been detected, the correct event should be | 454 | The only way to set a device to the RFKILL_STATE_HARD_BLOCKED state is through |
67 | sent over the input device which has been registered by the driver. | 455 | a suitable return of get_state() or through rfkill_force_state(). |
68 | 456 | ||
69 | ==================================== | 457 | When a device is in the RFKILL_STATE_HARD_BLOCKED state, the only way to switch |
70 | 3: Userspace support | 458 | it to a different state is through a suitable return of get_state() or through |
459 | rfkill_force_state(). | ||
460 | |||
461 | If toggle_radio() is called to set a device to state RFKILL_STATE_SOFT_BLOCKED | ||
462 | when that device is already at the RFKILL_STATE_HARD_BLOCKED state, it should | ||
463 | not return an error. Instead, it should try to double-block the transmitter, | ||
464 | so that its state will change from RFKILL_STATE_HARD_BLOCKED to | ||
465 | RFKILL_STATE_SOFT_BLOCKED should the hardware blocking cease. | ||
71 | 466 | ||
72 | For each key an input device will be created which will send out the correct | 467 | Please refer to the source for more documentation. |
73 | key event when the rfkill key has been pressed. | 468 | |
469 | =============================================================================== | ||
470 | 5: Userspace support | ||
471 | |||
472 | rfkill devices issue uevents (with an action of "change"), with the following | ||
473 | environment variables set: | ||
474 | |||
475 | RFKILL_NAME | ||
476 | RFKILL_STATE | ||
477 | RFKILL_TYPE | ||
478 | |||
479 | The ABI for these variables is defined by the sysfs attributes. It is best | ||
480 | to take a quick look at the source to make sure of the possible values. | ||
481 | |||
482 | It is expected that HAL will trap those, and bridge them to DBUS, etc. These | ||
483 | events CAN and SHOULD be used to give feedback to the user about the rfkill | ||
484 | status of the system. | ||
485 | |||
486 | Input devices may issue events that are related to rfkill. These are the | ||
487 | various KEY_* events and SW_* events supported by rfkill-input.c. | ||
488 | |||
489 | ******IMPORTANT****** | ||
490 | When rfkill-input is ACTIVE, userspace is NOT TO CHANGE THE STATE OF AN RFKILL | ||
491 | SWITCH IN RESPONSE TO AN INPUT EVENT also handled by rfkill-input, unless it | ||
492 | has set to true the user_claim attribute for that particular switch. This rule | ||
493 | is *absolute*; do NOT violate it. | ||
494 | ******IMPORTANT****** | ||
495 | |||
496 | Userspace must not assume it is the only source of control for rfkill switches. | ||
497 | Their state CAN and WILL change due to firmware actions, direct user actions, | ||
498 | and the rfkill-input EPO override for *_RFKILL_ALL. | ||
499 | |||
500 | When rfkill-input is not active, userspace must initiate a rfkill status | ||
501 | change by writing to the "state" attribute in order for anything to happen. | ||
502 | |||
503 | Take particular care to implement EV_SW SW_RFKILL_ALL properly. When that | ||
504 | switch is set to OFF, *every* rfkill device *MUST* be immediately put into the | ||
505 | RFKILL_STATE_SOFT_BLOCKED state, no questions asked. | ||
74 | 506 | ||
75 | The following sysfs entries will be created: | 507 | The following sysfs entries will be created: |
76 | 508 | ||
77 | name: Name assigned by driver to this key (interface or driver name). | 509 | name: Name assigned by driver to this key (interface or driver name). |
78 | type: Name of the key type ("wlan", "bluetooth", etc). | 510 | type: Name of the key type ("wlan", "bluetooth", etc). |
79 | state: Current state of the key. 1: On, 0: Off. | 511 | state: Current state of the transmitter |
512 | 0: RFKILL_STATE_SOFT_BLOCKED | ||
513 | transmitter is forced off, but one can override it | ||
514 | by a write to the state attribute; | ||
515 | 1: RFKILL_STATE_UNBLOCKED | ||
516 | transmiter is NOT forced off, and may operate if | ||
517 | all other conditions for such operation are met | ||
518 | (such as interface is up and configured, etc); | ||
519 | 2: RFKILL_STATE_HARD_BLOCKED | ||
520 | transmitter is forced off by something outside of | ||
521 | the driver's control. One cannot set a device to | ||
522 | this state through writes to the state attribute; | ||
80 | claim: 1: Userspace handles events, 0: Kernel handles events | 523 | claim: 1: Userspace handles events, 0: Kernel handles events |
81 | 524 | ||
82 | Both the "state" and "claim" entries are also writable. For the "state" entry | 525 | Both the "state" and "claim" entries are also writable. For the "state" entry |
83 | this means that when 1 or 0 is written all radios, not yet in the requested | 526 | this means that when 1 or 0 is written, the device rfkill state (if not yet in |
84 | state, will be will be toggled accordingly. | 527 | the requested state), will be will be toggled accordingly. |
528 | |||
85 | For the "claim" entry writing 1 to it means that the kernel no longer handles | 529 | For the "claim" entry writing 1 to it means that the kernel no longer handles |
86 | key events even though RFKILL_INPUT input was enabled. When "claim" has been | 530 | key events even though RFKILL_INPUT input was enabled. When "claim" has been |
87 | set to 0, userspace should make sure that it listens for the input events or | 531 | set to 0, userspace should make sure that it listens for the input events or |
88 | check the sysfs "state" entry regularly to correctly perform the required | 532 | check the sysfs "state" entry regularly to correctly perform the required tasks |
89 | tasks when the rkfill key is pressed. | 533 | when the rkfill key is pressed. |
534 | |||
535 | A note about input devices and EV_SW events: | ||
536 | |||
537 | In order to know the current state of an input device switch (like | ||
538 | SW_RFKILL_ALL), you will need to use an IOCTL. That information is not | ||
539 | available through sysfs in a generic way at this time, and it is not available | ||
540 | through the rfkill class AT ALL. | ||
diff --git a/Documentation/s390/driver-model.txt b/Documentation/s390/driver-model.txt index e938c442277d..bde473df748d 100644 --- a/Documentation/s390/driver-model.txt +++ b/Documentation/s390/driver-model.txt | |||
@@ -25,7 +25,7 @@ device 4711 via subchannel 1 in subchannel set 0, and subchannel 2 is a non-I/O | |||
25 | subchannel. Device 1234 is accessed via subchannel 0 in subchannel set 1. | 25 | subchannel. Device 1234 is accessed via subchannel 0 in subchannel set 1. |
26 | 26 | ||
27 | The subchannel named 'defunct' does not represent any real subchannel on the | 27 | The subchannel named 'defunct' does not represent any real subchannel on the |
28 | system; it is a pseudo subchannel where disconnnected ccw devices are moved to | 28 | system; it is a pseudo subchannel where disconnected ccw devices are moved to |
29 | if they are displaced by another ccw device becoming operational on their | 29 | if they are displaced by another ccw device becoming operational on their |
30 | former subchannel. The ccw devices will be moved again to a proper subchannel | 30 | former subchannel. The ccw devices will be moved again to a proper subchannel |
31 | if they become operational again on that subchannel. | 31 | if they become operational again on that subchannel. |
diff --git a/Documentation/scheduler/sched-domains.txt b/Documentation/scheduler/sched-domains.txt index a9e990ab980f..373ceacc367e 100644 --- a/Documentation/scheduler/sched-domains.txt +++ b/Documentation/scheduler/sched-domains.txt | |||
@@ -61,10 +61,7 @@ builder by #define'ing ARCH_HASH_SCHED_DOMAIN, and exporting your | |||
61 | arch_init_sched_domains function. This function will attach domains to all | 61 | arch_init_sched_domains function. This function will attach domains to all |
62 | CPUs using cpu_attach_domain. | 62 | CPUs using cpu_attach_domain. |
63 | 63 | ||
64 | Implementors should change the line | 64 | The sched-domains debugging infrastructure can be enabled by enabling |
65 | #undef SCHED_DOMAIN_DEBUG | 65 | CONFIG_SCHED_DEBUG. This enables an error checking parse of the sched domains |
66 | to | ||
67 | #define SCHED_DOMAIN_DEBUG | ||
68 | in kernel/sched.c as this enables an error checking parse of the sched domains | ||
69 | which should catch most possible errors (described above). It also prints out | 66 | which should catch most possible errors (described above). It also prints out |
70 | the domain structure in a visual format. | 67 | the domain structure in a visual format. |
diff --git a/Documentation/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt index 14f901f639ee..3ef339f491e0 100644 --- a/Documentation/scheduler/sched-rt-group.txt +++ b/Documentation/scheduler/sched-rt-group.txt | |||
@@ -51,9 +51,9 @@ needs only about 3% CPU time to do so, it can do with a 0.03 * 0.005s = | |||
51 | 0.00015s. So this group can be scheduled with a period of 0.005s and a run time | 51 | 0.00015s. So this group can be scheduled with a period of 0.005s and a run time |
52 | of 0.00015s. | 52 | of 0.00015s. |
53 | 53 | ||
54 | The remaining CPU time will be used for user input and other tass. Because | 54 | The remaining CPU time will be used for user input and other tasks. Because |
55 | realtime tasks have explicitly allocated the CPU time they need to perform | 55 | realtime tasks have explicitly allocated the CPU time they need to perform |
56 | their tasks, buffer underruns in the graphocs or audio can be eliminated. | 56 | their tasks, buffer underruns in the graphics or audio can be eliminated. |
57 | 57 | ||
58 | NOTE: the above example is not fully implemented as of yet (2.6.25). We still | 58 | NOTE: the above example is not fully implemented as of yet (2.6.25). We still |
59 | lack an EDF scheduler to make non-uniform periods usable. | 59 | lack an EDF scheduler to make non-uniform periods usable. |
diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt index d16011a8618e..709ca991a451 100644 --- a/Documentation/scsi/aacraid.txt +++ b/Documentation/scsi/aacraid.txt | |||
@@ -56,19 +56,33 @@ Supported Cards/Chipsets | |||
56 | 9005:0285:9005:02d1 Adaptec 5405 (Voodoo40) | 56 | 9005:0285:9005:02d1 Adaptec 5405 (Voodoo40) |
57 | 9005:0285:15d9:02d2 SMC AOC-USAS-S8i-LP | 57 | 9005:0285:15d9:02d2 SMC AOC-USAS-S8i-LP |
58 | 9005:0285:15d9:02d3 SMC AOC-USAS-S8iR-LP | 58 | 9005:0285:15d9:02d3 SMC AOC-USAS-S8iR-LP |
59 | 9005:0285:9005:02d4 Adaptec 2045 (Voodoo04 Lite) | 59 | 9005:0285:9005:02d4 Adaptec ASR-2045 (Voodoo04 Lite) |
60 | 9005:0285:9005:02d5 Adaptec 2405 (Voodoo40 Lite) | 60 | 9005:0285:9005:02d5 Adaptec ASR-2405 (Voodoo40 Lite) |
61 | 9005:0285:9005:02d6 Adaptec 2445 (Voodoo44 Lite) | 61 | 9005:0285:9005:02d6 Adaptec ASR-2445 (Voodoo44 Lite) |
62 | 9005:0285:9005:02d7 Adaptec 2805 (Voodoo80 Lite) | 62 | 9005:0285:9005:02d7 Adaptec ASR-2805 (Voodoo80 Lite) |
63 | 9005:0285:9005:02d8 Adaptec 5405G (Voodoo40 PM) | ||
64 | 9005:0285:9005:02d9 Adaptec 5445G (Voodoo44 PM) | ||
65 | 9005:0285:9005:02da Adaptec 5805G (Voodoo80 PM) | ||
66 | 9005:0285:9005:02db Adaptec 5085G (Voodoo08 PM) | ||
67 | 9005:0285:9005:02dc Adaptec 51245G (Voodoo124 PM) | ||
68 | 9005:0285:9005:02dd Adaptec 51645G (Voodoo164 PM) | ||
69 | 9005:0285:9005:02de Adaptec 52445G (Voodoo244 PM) | ||
70 | 9005:0285:9005:02df Adaptec ASR-2045G (Voodoo04 Lite PM) | ||
71 | 9005:0285:9005:02e0 Adaptec ASR-2405G (Voodoo40 Lite PM) | ||
72 | 9005:0285:9005:02e1 Adaptec ASR-2445G (Voodoo44 Lite PM) | ||
73 | 9005:0285:9005:02e2 Adaptec ASR-2805G (Voodoo80 Lite PM) | ||
63 | 1011:0046:9005:0364 Adaptec 5400S (Mustang) | 74 | 1011:0046:9005:0364 Adaptec 5400S (Mustang) |
75 | 1011:0046:9005:0365 Adaptec 5400S (Mustang) | ||
64 | 9005:0287:9005:0800 Adaptec Themisto (Jupiter) | 76 | 9005:0287:9005:0800 Adaptec Themisto (Jupiter) |
65 | 9005:0200:9005:0200 Adaptec Themisto (Jupiter) | 77 | 9005:0200:9005:0200 Adaptec Themisto (Jupiter) |
66 | 9005:0286:9005:0800 Adaptec Callisto (Jupiter) | 78 | 9005:0286:9005:0800 Adaptec Callisto (Jupiter) |
67 | 1011:0046:9005:1364 Dell PERC 2/QC (Quad Channel, Mustang) | 79 | 1011:0046:9005:1364 Dell PERC 2/QC (Quad Channel, Mustang) |
80 | 1011:0046:9005:1365 Dell PERC 2/QC (Quad Channel, Mustang) | ||
68 | 1028:0001:1028:0001 Dell PERC 2/Si (Iguana) | 81 | 1028:0001:1028:0001 Dell PERC 2/Si (Iguana) |
69 | 1028:0003:1028:0003 Dell PERC 3/Si (SlimFast) | 82 | 1028:0003:1028:0003 Dell PERC 3/Si (SlimFast) |
70 | 1028:0002:1028:0002 Dell PERC 3/Di (Opal) | 83 | 1028:0002:1028:0002 Dell PERC 3/Di (Opal) |
71 | 1028:0004:1028:0004 Dell PERC 3/DiF (Iguana) | 84 | 1028:0004:1028:0004 Dell PERC 3/SiF (Iguana) |
85 | 1028:0004:1028:00d0 Dell PERC 3/DiF (Iguana) | ||
72 | 1028:0002:1028:00d1 Dell PERC 3/DiV (Viper) | 86 | 1028:0002:1028:00d1 Dell PERC 3/DiV (Viper) |
73 | 1028:0002:1028:00d9 Dell PERC 3/DiL (Lexus) | 87 | 1028:0002:1028:00d9 Dell PERC 3/DiL (Lexus) |
74 | 1028:000a:1028:0106 Dell PERC 3/DiJ (Jaguar) | 88 | 1028:000a:1028:0106 Dell PERC 3/DiJ (Jaguar) |
diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt index a810421f1fb3..3920f28710c4 100644 --- a/Documentation/scsi/ibmmca.txt +++ b/Documentation/scsi/ibmmca.txt | |||
@@ -524,7 +524,7 @@ | |||
524 | - Michael Lang | 524 | - Michael Lang |
525 | 525 | ||
526 | June 25 1997: (v1.8b) | 526 | June 25 1997: (v1.8b) |
527 | 1) Some cosmetical changes for the handling of SCSI-device-types. | 527 | 1) Some cosmetic changes for the handling of SCSI-device-types. |
528 | Now, also CD-Burners / WORMs and SCSI-scanners should work. For | 528 | Now, also CD-Burners / WORMs and SCSI-scanners should work. For |
529 | MO-drives I have no experience, therefore not yet supported. | 529 | MO-drives I have no experience, therefore not yet supported. |
530 | In logical_devices I changed from different type-variables to one | 530 | In logical_devices I changed from different type-variables to one |
@@ -914,7 +914,7 @@ | |||
914 | in version 4.0. This was never really necessary, as all troubles were | 914 | in version 4.0. This was never really necessary, as all troubles were |
915 | based on non-command related reasons up to now, so bypassing commands | 915 | based on non-command related reasons up to now, so bypassing commands |
916 | did not help to avoid any bugs. It is kept in 3.2X for debugging reasons. | 916 | did not help to avoid any bugs. It is kept in 3.2X for debugging reasons. |
917 | 5) Dynamical reassignment of ldns was again verified and analyzed to be | 917 | 5) Dynamic reassignment of ldns was again verified and analyzed to be |
918 | completely inoperational. This is corrected and should work now. | 918 | completely inoperational. This is corrected and should work now. |
919 | 6) All commands that get sent to the SCSI adapter were verified and | 919 | 6) All commands that get sent to the SCSI adapter were verified and |
920 | completed in such a way, that they are now completely conform to the | 920 | completed in such a way, that they are now completely conform to the |
@@ -1386,7 +1386,7 @@ | |||
1386 | concerning the Linux-kernel in special, this SCSI-driver comes without any | 1386 | concerning the Linux-kernel in special, this SCSI-driver comes without any |
1387 | warranty. Its functionality is tested as good as possible on certain | 1387 | warranty. Its functionality is tested as good as possible on certain |
1388 | machines and combinations of computer hardware, which does not exclude, | 1388 | machines and combinations of computer hardware, which does not exclude, |
1389 | that dataloss or severe damage of hardware is possible while using this | 1389 | that data loss or severe damage of hardware is possible while using this |
1390 | part of software on some arbitrary computer hardware or in combination | 1390 | part of software on some arbitrary computer hardware or in combination |
1391 | with other software packages. It is highly recommended to make backup | 1391 | with other software packages. It is highly recommended to make backup |
1392 | copies of your data before using this software. Furthermore, personal | 1392 | copies of your data before using this software. Furthermore, personal |
diff --git a/Documentation/scsi/lpfc.txt b/Documentation/scsi/lpfc.txt index 4dbe41370a6d..5741ea8aa88a 100644 --- a/Documentation/scsi/lpfc.txt +++ b/Documentation/scsi/lpfc.txt | |||
@@ -36,7 +36,7 @@ Cable pull and temporary device Loss: | |||
36 | being removed, a switch rebooting, or a device reboot), the driver could | 36 | being removed, a switch rebooting, or a device reboot), the driver could |
37 | hide the disappearance of the device from the midlayer. I/O's issued to | 37 | hide the disappearance of the device from the midlayer. I/O's issued to |
38 | the LLDD would simply be queued for a short duration, allowing the device | 38 | the LLDD would simply be queued for a short duration, allowing the device |
39 | to reappear or link come back alive, with no inadvertant side effects | 39 | to reappear or link come back alive, with no inadvertent side effects |
40 | to the system. If the driver did not hide these conditions, i/o would be | 40 | to the system. If the driver did not hide these conditions, i/o would be |
41 | errored by the driver, the mid-layer would exhaust its retries, and the | 41 | errored by the driver, the mid-layer would exhaust its retries, and the |
42 | device would be taken offline. Manual intervention would be required to | 42 | device would be taken offline. Manual intervention would be required to |
diff --git a/Documentation/scsi/scsi_fc_transport.txt b/Documentation/scsi/scsi_fc_transport.txt index d403e46d8463..75143f0c23b6 100644 --- a/Documentation/scsi/scsi_fc_transport.txt +++ b/Documentation/scsi/scsi_fc_transport.txt | |||
@@ -65,7 +65,7 @@ Overview: | |||
65 | discussion will concentrate on NPIV. | 65 | discussion will concentrate on NPIV. |
66 | 66 | ||
67 | Note: World Wide Name assignment (and uniqueness guarantees) are left | 67 | Note: World Wide Name assignment (and uniqueness guarantees) are left |
68 | up to an administrative entity controling the vport. For example, | 68 | up to an administrative entity controlling the vport. For example, |
69 | if vports are to be associated with virtual machines, a XEN mgmt | 69 | if vports are to be associated with virtual machines, a XEN mgmt |
70 | utility would be responsible for creating wwpn/wwnn's for the vport, | 70 | utility would be responsible for creating wwpn/wwnn's for the vport, |
71 | using it's own naming authority and OUI. (Note: it already does this | 71 | using it's own naming authority and OUI. (Note: it already does this |
@@ -91,7 +91,7 @@ Device Trees and Vport Objects: | |||
91 | Here's what to expect in the device tree : | 91 | Here's what to expect in the device tree : |
92 | The typical Physical Port's Scsi_Host: | 92 | The typical Physical Port's Scsi_Host: |
93 | /sys/devices/.../host17/ | 93 | /sys/devices/.../host17/ |
94 | and it has the typical decendent tree: | 94 | and it has the typical descendant tree: |
95 | /sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0: | 95 | /sys/devices/.../host17/rport-17:0-0/target17:0:0/17:0:0:0: |
96 | and then the vport is created on the Physical Port: | 96 | and then the vport is created on the Physical Port: |
97 | /sys/devices/.../host17/vport-17:0-0 | 97 | /sys/devices/.../host17/vport-17:0-0 |
@@ -192,7 +192,7 @@ Vport States: | |||
192 | independent of the adapter's link state. | 192 | independent of the adapter's link state. |
193 | - Instantiation of the vport on the FC link via ELS traffic, etc. | 193 | - Instantiation of the vport on the FC link via ELS traffic, etc. |
194 | This is equivalent to a "link up" and successfull link initialization. | 194 | This is equivalent to a "link up" and successfull link initialization. |
195 | Futher information can be found in the interfaces section below for | 195 | Further information can be found in the interfaces section below for |
196 | Vport Creation. | 196 | Vport Creation. |
197 | 197 | ||
198 | Once a vport has been instantiated with the kernel/LLDD, a vport state | 198 | Once a vport has been instantiated with the kernel/LLDD, a vport state |
diff --git a/Documentation/serial/driver b/Documentation/serial/driver index 88ad615dd338..77ba0afbe4db 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver | |||
@@ -186,6 +186,17 @@ hardware. | |||
186 | Locking: port_sem taken. | 186 | Locking: port_sem taken. |
187 | Interrupts: caller dependent. | 187 | Interrupts: caller dependent. |
188 | 188 | ||
189 | flush_buffer(port) | ||
190 | Flush any write buffers, reset any DMA state and stop any | ||
191 | ongoing DMA transfers. | ||
192 | |||
193 | This will be called whenever the port->info->xmit circular | ||
194 | buffer is cleared. | ||
195 | |||
196 | Locking: port->lock taken. | ||
197 | Interrupts: locally disabled. | ||
198 | This call must not sleep | ||
199 | |||
189 | set_termios(port,termios,oldtermios) | 200 | set_termios(port,termios,oldtermios) |
190 | Change the port parameters, including word length, parity, stop | 201 | Change the port parameters, including word length, parity, stop |
191 | bits. Update read_status_mask and ignore_status_mask to indicate | 202 | bits. Update read_status_mask and ignore_status_mask to indicate |
diff --git a/Documentation/sh/clk.txt b/Documentation/sh/clk.txt index 9aef710e9a4b..114b595cfa97 100644 --- a/Documentation/sh/clk.txt +++ b/Documentation/sh/clk.txt | |||
@@ -12,7 +12,7 @@ means no changes to adjanced clock | |||
12 | Internally, the clk_set_rate_ex forwards request to clk->ops->set_rate method, | 12 | Internally, the clk_set_rate_ex forwards request to clk->ops->set_rate method, |
13 | if it is present in ops structure. The method should set the clock rate and adjust | 13 | if it is present in ops structure. The method should set the clock rate and adjust |
14 | all needed clocks according to the passed algo_id. | 14 | all needed clocks according to the passed algo_id. |
15 | Exact values for algo_id are machine-dependend. For the sh7722, the following | 15 | Exact values for algo_id are machine-dependent. For the sh7722, the following |
16 | values are defined: | 16 | values are defined: |
17 | 17 | ||
18 | NO_CHANGE = 0, | 18 | NO_CHANGE = 0, |
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 0bbee38acd26..6f6d117ac7e2 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt | |||
@@ -753,8 +753,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
753 | 753 | ||
754 | [Multiple options for each card instance] | 754 | [Multiple options for each card instance] |
755 | model - force the model name | 755 | model - force the model name |
756 | position_fix - Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size) | 756 | position_fix - Fix DMA pointer (0 = auto, 1 = use LPIB, 2 = POSBUF) |
757 | probe_mask - Bitmask to probe codecs (default = -1, meaning all slots) | 757 | probe_mask - Bitmask to probe codecs (default = -1, meaning all slots) |
758 | bdl_pos_adj - Specifies the DMA IRQ timing delay in samples. | ||
759 | Passing -1 will make the driver to choose the appropriate | ||
760 | value based on the controller chip. | ||
758 | 761 | ||
759 | [Single (global) options] | 762 | [Single (global) options] |
760 | single_cmd - Use single immediate commands to communicate with | 763 | single_cmd - Use single immediate commands to communicate with |
@@ -845,7 +848,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
845 | ALC269 | 848 | ALC269 |
846 | basic Basic preset | 849 | basic Basic preset |
847 | 850 | ||
848 | ALC662 | 851 | ALC662/663 |
849 | 3stack-dig 3-stack (2-channel) with SPDIF | 852 | 3stack-dig 3-stack (2-channel) with SPDIF |
850 | 3stack-6ch 3-stack (6-channel) | 853 | 3stack-6ch 3-stack (6-channel) |
851 | 3stack-6ch-dig 3-stack (6-channel) with SPDIF | 854 | 3stack-6ch-dig 3-stack (6-channel) with SPDIF |
@@ -853,6 +856,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
853 | lenovo-101e Lenovo laptop | 856 | lenovo-101e Lenovo laptop |
854 | eeepc-p701 ASUS Eeepc P701 | 857 | eeepc-p701 ASUS Eeepc P701 |
855 | eeepc-ep20 ASUS Eeepc EP20 | 858 | eeepc-ep20 ASUS Eeepc EP20 |
859 | m51va ASUS M51VA | ||
860 | g71v ASUS G71V | ||
861 | h13 ASUS H13 | ||
862 | g50v ASUS G50V | ||
856 | auto auto-config reading BIOS (default) | 863 | auto auto-config reading BIOS (default) |
857 | 864 | ||
858 | ALC882/885 | 865 | ALC882/885 |
@@ -1017,6 +1024,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
1017 | intel-mac-v3 Intel Mac Type 3 | 1024 | intel-mac-v3 Intel Mac Type 3 |
1018 | intel-mac-v4 Intel Mac Type 4 | 1025 | intel-mac-v4 Intel Mac Type 4 |
1019 | intel-mac-v5 Intel Mac Type 5 | 1026 | intel-mac-v5 Intel Mac Type 5 |
1027 | intel-mac-auto Intel Mac (detect type according to subsystem id) | ||
1020 | macmini Intel Mac Mini (equivalent with type 3) | 1028 | macmini Intel Mac Mini (equivalent with type 3) |
1021 | macbook Intel Mac Book (eq. type 5) | 1029 | macbook Intel Mac Book (eq. type 5) |
1022 | macbook-pro-v1 Intel Mac Book Pro 1st generation (eq. type 3) | 1030 | macbook-pro-v1 Intel Mac Book Pro 1st generation (eq. type 3) |
@@ -1091,7 +1099,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
1091 | This occurs when the access to non-existing or non-working codec slot | 1099 | This occurs when the access to non-existing or non-working codec slot |
1092 | (likely a modem one) causes a stall of the communication via HD-audio | 1100 | (likely a modem one) causes a stall of the communication via HD-audio |
1093 | bus. You can see which codec slots are probed by enabling | 1101 | bus. You can see which codec slots are probed by enabling |
1094 | CONFIG_SND_DEBUG_DETECT, or simply from the file name of the codec | 1102 | CONFIG_SND_DEBUG_VERBOSE, or simply from the file name of the codec |
1095 | proc files. Then limit the slots to probe by probe_mask option. | 1103 | proc files. Then limit the slots to probe by probe_mask option. |
1096 | For example, probe_mask=1 means to probe only the first slot, and | 1104 | For example, probe_mask=1 means to probe only the first slot, and |
1097 | probe_mask=4 means only the third slot. | 1105 | probe_mask=4 means only the third slot. |
@@ -2267,6 +2275,10 @@ case above again, the first two slots are already reserved. If any | |||
2267 | other driver (e.g. snd-usb-audio) is loaded before snd-interwave or | 2275 | other driver (e.g. snd-usb-audio) is loaded before snd-interwave or |
2268 | snd-ens1371, it will be assigned to the third or later slot. | 2276 | snd-ens1371, it will be assigned to the third or later slot. |
2269 | 2277 | ||
2278 | When a module name is given with '!', the slot will be given for any | ||
2279 | modules but that name. For example, "slots=!snd-pcsp" will reserve | ||
2280 | the first slot for any modules but snd-pcsp. | ||
2281 | |||
2270 | 2282 | ||
2271 | ALSA PCM devices to OSS devices mapping | 2283 | ALSA PCM devices to OSS devices mapping |
2272 | ======================================= | 2284 | ======================================= |
diff --git a/Documentation/sound/alsa/Audiophile-Usb.txt b/Documentation/sound/alsa/Audiophile-Usb.txt index 2ad5e6306c44..a4c53d8961e1 100644 --- a/Documentation/sound/alsa/Audiophile-Usb.txt +++ b/Documentation/sound/alsa/Audiophile-Usb.txt | |||
@@ -236,15 +236,15 @@ The parameter can be given: | |||
236 | alias snd-card-1 snd-usb-audio | 236 | alias snd-card-1 snd-usb-audio |
237 | options snd-usb-audio index=1 device_setup=0x09 | 237 | options snd-usb-audio index=1 device_setup=0x09 |
238 | 238 | ||
239 | CAUTION when initializaing the device | 239 | CAUTION when initializing the device |
240 | ------------------------------------- | 240 | ------------------------------------- |
241 | 241 | ||
242 | * Correct initialization on the device requires that device_setup is given to | 242 | * Correct initialization on the device requires that device_setup is given to |
243 | the module BEFORE the device is turned on. So, if you use the "manual probing" | 243 | the module BEFORE the device is turned on. So, if you use the "manual probing" |
244 | method described above, take care to power-on the device AFTER this initialization. | 244 | method described above, take care to power-on the device AFTER this initialization. |
245 | 245 | ||
246 | * Failing to respect this will lead in a misconfiguration of the device. In this case | 246 | * Failing to respect this will lead to a misconfiguration of the device. In this case |
247 | turn off the device, unproble the snd-usb-audio module, then probe it again with | 247 | turn off the device, unprobe the snd-usb-audio module, then probe it again with |
248 | correct device_setup parameter and then (and only then) turn on the device again. | 248 | correct device_setup parameter and then (and only then) turn on the device again. |
249 | 249 | ||
250 | * If you've correctly initialized the device in a valid mode and then want to switch | 250 | * If you've correctly initialized the device in a valid mode and then want to switch |
@@ -388,9 +388,9 @@ There are 2 main potential issues when using Jackd with the device: | |||
388 | 388 | ||
389 | Jack supports big endian devices only in recent versions (thanks to | 389 | Jack supports big endian devices only in recent versions (thanks to |
390 | Andreas Steinmetz for his first big-endian patch). I can't remember | 390 | Andreas Steinmetz for his first big-endian patch). I can't remember |
391 | extacly when this support was released into jackd, let's just say that | 391 | exactly when this support was released into jackd, let's just say that |
392 | with jackd version 0.103.0 it's almost ok (just a small bug is affecting | 392 | with jackd version 0.103.0 it's almost ok (just a small bug is affecting |
393 | 16bits Big-Endian devices, but since you've read carefully the above | 393 | 16bits Big-Endian devices, but since you've read carefully the above |
394 | paragraphs, you're now using kernel >= 2.6.23 and your 16bits devices | 394 | paragraphs, you're now using kernel >= 2.6.23 and your 16bits devices |
395 | are now Little Endians ;-) ). | 395 | are now Little Endians ;-) ). |
396 | 396 | ||
diff --git a/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl b/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl index c4d2e3507af9..9d644f7e241e 100644 --- a/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl +++ b/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl | |||
@@ -42,7 +42,7 @@ | |||
42 | <sect1><title>Device Components</title> | 42 | <sect1><title>Device Components</title> |
43 | !Esound/core/device.c | 43 | !Esound/core/device.c |
44 | </sect1> | 44 | </sect1> |
45 | <sect1><title>KMOD and Device File Entries</title> | 45 | <sect1><title>Module requests and Device File Entries</title> |
46 | !Esound/core/sound.c | 46 | !Esound/core/sound.c |
47 | </sect1> | 47 | </sect1> |
48 | <sect1><title>Memory Management Helpers</title> | 48 | <sect1><title>Memory Management Helpers</title> |
diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl index b03df4d4795c..e13c4e67029f 100644 --- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl | |||
@@ -6127,8 +6127,8 @@ struct _snd_pcm_runtime { | |||
6127 | 6127 | ||
6128 | <para> | 6128 | <para> |
6129 | <function>snd_printdd()</function> is compiled in only when | 6129 | <function>snd_printdd()</function> is compiled in only when |
6130 | <constant>CONFIG_SND_DEBUG_DETECT</constant> is set. Please note | 6130 | <constant>CONFIG_SND_DEBUG_VERBOSE</constant> is set. Please note |
6131 | that <constant>DEBUG_DETECT</constant> is not set as default | 6131 | that <constant>CONFIG_SND_DEBUG_VERBOSE</constant> is not set as default |
6132 | even if you configure the alsa-driver with | 6132 | even if you configure the alsa-driver with |
6133 | <option>--with-debug=full</option> option. You need to give | 6133 | <option>--with-debug=full</option> option. You need to give |
6134 | explicitly <option>--with-debug=detect</option> option instead. | 6134 | explicitly <option>--with-debug=detect</option> option instead. |
diff --git a/Documentation/sound/alsa/hda_codec.txt b/Documentation/sound/alsa/hda_codec.txt index 8e1b02526698..34e87ec1379c 100644 --- a/Documentation/sound/alsa/hda_codec.txt +++ b/Documentation/sound/alsa/hda_codec.txt | |||
@@ -67,7 +67,7 @@ CONFIG_SND_HDA_POWER_SAVE kconfig. It's called when the codec needs | |||
67 | to power up or may power down. The controller should check the all | 67 | to power up or may power down. The controller should check the all |
68 | belonging codecs on the bus whether they are actually powered off | 68 | belonging codecs on the bus whether they are actually powered off |
69 | (check codec->power_on), and optionally the driver may power down the | 69 | (check codec->power_on), and optionally the driver may power down the |
70 | contoller side, too. | 70 | controller side, too. |
71 | 71 | ||
72 | The bus instance is created via snd_hda_bus_new(). You need to pass | 72 | The bus instance is created via snd_hda_bus_new(). You need to pass |
73 | the card instance, the template, and the pointer to store the | 73 | the card instance, the template, and the pointer to store the |
diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt index c784a18b94dc..b2ed6983f40d 100644 --- a/Documentation/sound/alsa/soc/dapm.txt +++ b/Documentation/sound/alsa/soc/dapm.txt | |||
@@ -68,7 +68,7 @@ Audio DAPM widgets fall into a number of types:- | |||
68 | (Widgets are defined in include/sound/soc-dapm.h) | 68 | (Widgets are defined in include/sound/soc-dapm.h) |
69 | 69 | ||
70 | Widgets are usually added in the codec driver and the machine driver. There are | 70 | Widgets are usually added in the codec driver and the machine driver. There are |
71 | convience macros defined in soc-dapm.h that can be used to quickly build a | 71 | convenience macros defined in soc-dapm.h that can be used to quickly build a |
72 | list of widgets of the codecs and machines DAPM widgets. | 72 | list of widgets of the codecs and machines DAPM widgets. |
73 | 73 | ||
74 | Most widgets have a name, register, shift and invert. Some widgets have extra | 74 | Most widgets have a name, register, shift and invert. Some widgets have extra |
diff --git a/Documentation/sparse.txt b/Documentation/sparse.txt index 1a3bdc27d95e..42f43fa59f24 100644 --- a/Documentation/sparse.txt +++ b/Documentation/sparse.txt | |||
@@ -73,10 +73,10 @@ recompiled, or use "make C=2" to run sparse on the files whether they need to | |||
73 | be recompiled or not. The latter is a fast way to check the whole tree if you | 73 | be recompiled or not. The latter is a fast way to check the whole tree if you |
74 | have already built it. | 74 | have already built it. |
75 | 75 | ||
76 | The optional make variable CHECKFLAGS can be used to pass arguments to sparse. | 76 | The optional make variable CF can be used to pass arguments to sparse. The |
77 | The build system passes -Wbitwise to sparse automatically. To perform | 77 | build system passes -Wbitwise to sparse automatically. To perform endianness |
78 | endianness checks, you may define __CHECK_ENDIAN__: | 78 | checks, you may define __CHECK_ENDIAN__: |
79 | 79 | ||
80 | make C=2 CHECKFLAGS="-D__CHECK_ENDIAN__" | 80 | make C=2 CF="-D__CHECK_ENDIAN__" |
81 | 81 | ||
82 | These checks are disabled by default as they generate a host of warnings. | 82 | These checks are disabled by default as they generate a host of warnings. |
diff --git a/Documentation/specialix.txt b/Documentation/specialix.txt index 4a4b428ce8f6..6eb6f3a3331c 100644 --- a/Documentation/specialix.txt +++ b/Documentation/specialix.txt | |||
@@ -270,8 +270,8 @@ The pinout of the connectors on the IO8+ is: | |||
270 | Hardware handshaking issues. | 270 | Hardware handshaking issues. |
271 | ============================ | 271 | ============================ |
272 | 272 | ||
273 | The driver can be compiled in two different ways. The default | 273 | The driver can be told to operate in two different ways. The default |
274 | ("Specialix DTR/RTS pin is RTS" is off) the pin behaves as DTR when | 274 | behaviour is specialix.sx_rtscts = 0 where the pin behaves as DTR when |
275 | hardware handshaking is off. It behaves as the RTS hardware | 275 | hardware handshaking is off. It behaves as the RTS hardware |
276 | handshaking signal when hardware handshaking is selected. | 276 | handshaking signal when hardware handshaking is selected. |
277 | 277 | ||
@@ -280,7 +280,7 @@ cable will either be compatible with hardware handshaking or with | |||
280 | software handshaking. So switching on the fly is not really an | 280 | software handshaking. So switching on the fly is not really an |
281 | option. | 281 | option. |
282 | 282 | ||
283 | I actually prefer to use the "Specialix DTR/RTS pin is RTS" option. | 283 | I actually prefer to use the "specialix.sx_rtscts=1" option. |
284 | This makes the DTR/RTS pin always an RTS pin, and ioctls to | 284 | This makes the DTR/RTS pin always an RTS pin, and ioctls to |
285 | change DTR are always ignored. I have a cable that is configured | 285 | change DTR are always ignored. I have a cable that is configured |
286 | for this. | 286 | for this. |
@@ -379,7 +379,5 @@ it doesn't fit in your computer, bring back the card. | |||
379 | You have to WRITE to the address register to even | 379 | You have to WRITE to the address register to even |
380 | read-probe a CD186x register. Disable autodetection? | 380 | read-probe a CD186x register. Disable autodetection? |
381 | -- Specialix: any suggestions? | 381 | -- Specialix: any suggestions? |
382 | - Arbitrary baud rates are not implemented yet. | ||
383 | If you need this, bug me about it. | ||
384 | 382 | ||
385 | 383 | ||
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 8a4863c4edd4..d79eeda7a699 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt | |||
@@ -116,7 +116,7 @@ of kilobytes free. The VM uses this number to compute a pages_min | |||
116 | value for each lowmem zone in the system. Each lowmem zone gets | 116 | value for each lowmem zone in the system. Each lowmem zone gets |
117 | a number of reserved free pages based proportionally on its size. | 117 | a number of reserved free pages based proportionally on its size. |
118 | 118 | ||
119 | Some minimal ammount of memory is needed to satisfy PF_MEMALLOC | 119 | Some minimal amount of memory is needed to satisfy PF_MEMALLOC |
120 | allocations; if you set this to lower than 1024KB, your system will | 120 | allocations; if you set this to lower than 1024KB, your system will |
121 | become subtly broken, and prone to deadlock under high loads. | 121 | become subtly broken, and prone to deadlock under high loads. |
122 | 122 | ||
diff --git a/Documentation/sysfs-rules.txt b/Documentation/sysfs-rules.txt index 80ef562160bb..6049a2a84dda 100644 --- a/Documentation/sysfs-rules.txt +++ b/Documentation/sysfs-rules.txt | |||
@@ -3,9 +3,8 @@ Rules on how to access information in the Linux kernel sysfs | |||
3 | The kernel-exported sysfs exports internal kernel implementation details | 3 | The kernel-exported sysfs exports internal kernel implementation details |
4 | and depends on internal kernel structures and layout. It is agreed upon | 4 | and depends on internal kernel structures and layout. It is agreed upon |
5 | by the kernel developers that the Linux kernel does not provide a stable | 5 | by the kernel developers that the Linux kernel does not provide a stable |
6 | internal API. As sysfs is a direct export of kernel internal | 6 | internal API. Therefore, there are aspects of the sysfs interface that |
7 | structures, the sysfs interface cannot provide a stable interface either; | 7 | may not be stable across kernel releases. |
8 | it may always change along with internal kernel changes. | ||
9 | 8 | ||
10 | To minimize the risk of breaking users of sysfs, which are in most cases | 9 | To minimize the risk of breaking users of sysfs, which are in most cases |
11 | low-level userspace applications, with a new kernel release, the users | 10 | low-level userspace applications, with a new kernel release, the users |
diff --git a/Documentation/telephony/ixj.txt b/Documentation/telephony/ixj.txt index 621024fd3a18..44d124005bad 100644 --- a/Documentation/telephony/ixj.txt +++ b/Documentation/telephony/ixj.txt | |||
@@ -305,21 +305,14 @@ driver, like this: | |||
305 | 305 | ||
306 | which will result in the needed drivers getting loaded automatically. | 306 | which will result in the needed drivers getting loaded automatically. |
307 | 307 | ||
308 | g. if you are planning on using kerneld to automatically load the | 308 | g. if you are planning on having the kernel automatically request |
309 | module for you, then you need to edit /etc/conf.modules and add the | 309 | the module for you, then you need to edit /etc/conf.modules and add the |
310 | following lines: | 310 | following lines: |
311 | 311 | ||
312 | options ixj dspio=0x340 xio=0x330 ixjdebug=0 | 312 | options ixj dspio=0x340 xio=0x330 ixjdebug=0 |
313 | 313 | ||
314 | If you do this, then when you execute an application that uses the | 314 | If you do this, then when you execute an application that uses the |
315 | module kerneld will load the module for you. Note that to do this, | 315 | module the kernel will request that it is loaded. |
316 | you need to have your kernel set to support kerneld. You can check | ||
317 | for this by looking at /usr/src/linux/.config and you should see this: | ||
318 | |||
319 | # Loadable module support | ||
320 | # | ||
321 | <snip> | ||
322 | CONFIG_KMOD=y | ||
323 | 316 | ||
324 | h. if you want non-root users to be able to read and write to the | 317 | h. if you want non-root users to be able to read and write to the |
325 | ixj devices (this is a good idea!) you should do the following: | 318 | ixj devices (this is a good idea!) you should do the following: |
diff --git a/Documentation/timers/highres.txt b/Documentation/timers/highres.txt index a73ecf5b4bdb..21332233cef1 100644 --- a/Documentation/timers/highres.txt +++ b/Documentation/timers/highres.txt | |||
@@ -125,7 +125,7 @@ increase of flexibility and the avoidance of duplicated code across | |||
125 | architectures justifies the slight increase of the binary size. | 125 | architectures justifies the slight increase of the binary size. |
126 | 126 | ||
127 | The conversion of an architecture has no functional impact, but allows to | 127 | The conversion of an architecture has no functional impact, but allows to |
128 | utilize the high resolution and dynamic tick functionalites without any change | 128 | utilize the high resolution and dynamic tick functionalities without any change |
129 | to the clock event device and timer interrupt code. After the conversion the | 129 | to the clock event device and timer interrupt code. After the conversion the |
130 | enabling of high resolution timers and dynamic ticks is simply provided by | 130 | enabling of high resolution timers and dynamic ticks is simply provided by |
131 | adding the kernel/time/Kconfig file to the architecture specific Kconfig and | 131 | adding the kernel/time/Kconfig file to the architecture specific Kconfig and |
diff --git a/Documentation/tracers/mmiotrace.txt b/Documentation/tracers/mmiotrace.txt new file mode 100644 index 000000000000..a4afb560a45b --- /dev/null +++ b/Documentation/tracers/mmiotrace.txt | |||
@@ -0,0 +1,164 @@ | |||
1 | In-kernel memory-mapped I/O tracing | ||
2 | |||
3 | |||
4 | Home page and links to optional user space tools: | ||
5 | |||
6 | http://nouveau.freedesktop.org/wiki/MmioTrace | ||
7 | |||
8 | MMIO tracing was originally developed by Intel around 2003 for their Fault | ||
9 | Injection Test Harness. In Dec 2006 - Jan 2007, using the code from Intel, | ||
10 | Jeff Muizelaar created a tool for tracing MMIO accesses with the Nouveau | ||
11 | project in mind. Since then many people have contributed. | ||
12 | |||
13 | Mmiotrace was built for reverse engineering any memory-mapped IO device with | ||
14 | the Nouveau project as the first real user. Only x86 and x86_64 architectures | ||
15 | are supported. | ||
16 | |||
17 | Out-of-tree mmiotrace was originally modified for mainline inclusion and | ||
18 | ftrace framework by Pekka Paalanen <pq@iki.fi>. | ||
19 | |||
20 | |||
21 | Preparation | ||
22 | ----------- | ||
23 | |||
24 | Mmiotrace feature is compiled in by the CONFIG_MMIOTRACE option. Tracing is | ||
25 | disabled by default, so it is safe to have this set to yes. SMP systems are | ||
26 | supported, but tracing is unreliable and may miss events if more than one CPU | ||
27 | is on-line, therefore mmiotrace takes all but one CPU off-line during run-time | ||
28 | activation. You can re-enable CPUs by hand, but you have been warned, there | ||
29 | is no way to automatically detect if you are losing events due to CPUs racing. | ||
30 | |||
31 | |||
32 | Usage Quick Reference | ||
33 | --------------------- | ||
34 | |||
35 | $ mount -t debugfs debugfs /debug | ||
36 | $ echo mmiotrace > /debug/tracing/current_tracer | ||
37 | $ cat /debug/tracing/trace_pipe > mydump.txt & | ||
38 | Start X or whatever. | ||
39 | $ echo "X is up" > /debug/tracing/marker | ||
40 | $ echo none > /debug/tracing/current_tracer | ||
41 | Check for lost events. | ||
42 | |||
43 | |||
44 | Usage | ||
45 | ----- | ||
46 | |||
47 | Make sure debugfs is mounted to /debug. If not, (requires root privileges) | ||
48 | $ mount -t debugfs debugfs /debug | ||
49 | |||
50 | Check that the driver you are about to trace is not loaded. | ||
51 | |||
52 | Activate mmiotrace (requires root privileges): | ||
53 | $ echo mmiotrace > /debug/tracing/current_tracer | ||
54 | |||
55 | Start storing the trace: | ||
56 | $ cat /debug/tracing/trace_pipe > mydump.txt & | ||
57 | The 'cat' process should stay running (sleeping) in the background. | ||
58 | |||
59 | Load the driver you want to trace and use it. Mmiotrace will only catch MMIO | ||
60 | accesses to areas that are ioremapped while mmiotrace is active. | ||
61 | |||
62 | [Unimplemented feature:] | ||
63 | During tracing you can place comments (markers) into the trace by | ||
64 | $ echo "X is up" > /debug/tracing/marker | ||
65 | This makes it easier to see which part of the (huge) trace corresponds to | ||
66 | which action. It is recommended to place descriptive markers about what you | ||
67 | do. | ||
68 | |||
69 | Shut down mmiotrace (requires root privileges): | ||
70 | $ echo none > /debug/tracing/current_tracer | ||
71 | The 'cat' process exits. If it does not, kill it by issuing 'fg' command and | ||
72 | pressing ctrl+c. | ||
73 | |||
74 | Check that mmiotrace did not lose events due to a buffer filling up. Either | ||
75 | $ grep -i lost mydump.txt | ||
76 | which tells you exactly how many events were lost, or use | ||
77 | $ dmesg | ||
78 | to view your kernel log and look for "mmiotrace has lost events" warning. If | ||
79 | events were lost, the trace is incomplete. You should enlarge the buffers and | ||
80 | try again. Buffers are enlarged by first seeing how large the current buffers | ||
81 | are: | ||
82 | $ cat /debug/tracing/trace_entries | ||
83 | gives you a number. Approximately double this number and write it back, for | ||
84 | instance: | ||
85 | $ echo 128000 > /debug/tracing/trace_entries | ||
86 | Then start again from the top. | ||
87 | |||
88 | If you are doing a trace for a driver project, e.g. Nouveau, you should also | ||
89 | do the following before sending your results: | ||
90 | $ lspci -vvv > lspci.txt | ||
91 | $ dmesg > dmesg.txt | ||
92 | $ tar zcf pciid-nick-mmiotrace.tar.gz mydump.txt lspci.txt dmesg.txt | ||
93 | and then send the .tar.gz file. The trace compresses considerably. Replace | ||
94 | "pciid" and "nick" with the PCI ID or model name of your piece of hardware | ||
95 | under investigation and your nick name. | ||
96 | |||
97 | |||
98 | How Mmiotrace Works | ||
99 | ------------------- | ||
100 | |||
101 | Access to hardware IO-memory is gained by mapping addresses from PCI bus by | ||
102 | calling one of the ioremap_*() functions. Mmiotrace is hooked into the | ||
103 | __ioremap() function and gets called whenever a mapping is created. Mapping is | ||
104 | an event that is recorded into the trace log. Note, that ISA range mappings | ||
105 | are not caught, since the mapping always exists and is returned directly. | ||
106 | |||
107 | MMIO accesses are recorded via page faults. Just before __ioremap() returns, | ||
108 | the mapped pages are marked as not present. Any access to the pages causes a | ||
109 | fault. The page fault handler calls mmiotrace to handle the fault. Mmiotrace | ||
110 | marks the page present, sets TF flag to achieve single stepping and exits the | ||
111 | fault handler. The instruction that faulted is executed and debug trap is | ||
112 | entered. Here mmiotrace again marks the page as not present. The instruction | ||
113 | is decoded to get the type of operation (read/write), data width and the value | ||
114 | read or written. These are stored to the trace log. | ||
115 | |||
116 | Setting the page present in the page fault handler has a race condition on SMP | ||
117 | machines. During the single stepping other CPUs may run freely on that page | ||
118 | and events can be missed without a notice. Re-enabling other CPUs during | ||
119 | tracing is discouraged. | ||
120 | |||
121 | |||
122 | Trace Log Format | ||
123 | ---------------- | ||
124 | |||
125 | The raw log is text and easily filtered with e.g. grep and awk. One record is | ||
126 | one line in the log. A record starts with a keyword, followed by keyword | ||
127 | dependant arguments. Arguments are separated by a space, or continue until the | ||
128 | end of line. The format for version 20070824 is as follows: | ||
129 | |||
130 | Explanation Keyword Space separated arguments | ||
131 | --------------------------------------------------------------------------- | ||
132 | |||
133 | read event R width, timestamp, map id, physical, value, PC, PID | ||
134 | write event W width, timestamp, map id, physical, value, PC, PID | ||
135 | ioremap event MAP timestamp, map id, physical, virtual, length, PC, PID | ||
136 | iounmap event UNMAP timestamp, map id, PC, PID | ||
137 | marker MARK timestamp, text | ||
138 | version VERSION the string "20070824" | ||
139 | info for reader LSPCI one line from lspci -v | ||
140 | PCI address map PCIDEV space separated /proc/bus/pci/devices data | ||
141 | unk. opcode UNKNOWN timestamp, map id, physical, data, PC, PID | ||
142 | |||
143 | Timestamp is in seconds with decimals. Physical is a PCI bus address, virtual | ||
144 | is a kernel virtual address. Width is the data width in bytes and value is the | ||
145 | data value. Map id is an arbitrary id number identifying the mapping that was | ||
146 | used in an operation. PC is the program counter and PID is process id. PC is | ||
147 | zero if it is not recorded. PID is always zero as tracing MMIO accesses | ||
148 | originating in user space memory is not yet supported. | ||
149 | |||
150 | For instance, the following awk filter will pass all 32-bit writes that target | ||
151 | physical addresses in the range [0xfb73ce40, 0xfb800000[ | ||
152 | |||
153 | $ awk '/W 4 / { adr=strtonum($5); if (adr >= 0xfb73ce40 && | ||
154 | adr < 0xfb800000) print; }' | ||
155 | |||
156 | |||
157 | Tools for Developers | ||
158 | -------------------- | ||
159 | |||
160 | The user space tools include utilities for: | ||
161 | - replacing numeric addresses and values with hardware register names | ||
162 | - replaying MMIO logs, i.e., re-executing the recorded writes | ||
163 | |||
164 | |||
diff --git a/Documentation/unaligned-memory-access.txt b/Documentation/unaligned-memory-access.txt index b0472ac5226a..f866c72291bf 100644 --- a/Documentation/unaligned-memory-access.txt +++ b/Documentation/unaligned-memory-access.txt | |||
@@ -218,9 +218,35 @@ If use of such macros is not convenient, another option is to use memcpy(), | |||
218 | where the source or destination (or both) are of type u8* or unsigned char*. | 218 | where the source or destination (or both) are of type u8* or unsigned char*. |
219 | Due to the byte-wise nature of this operation, unaligned accesses are avoided. | 219 | Due to the byte-wise nature of this operation, unaligned accesses are avoided. |
220 | 220 | ||
221 | |||
222 | Alignment vs. Networking | ||
223 | ======================== | ||
224 | |||
225 | On architectures that require aligned loads, networking requires that the IP | ||
226 | header is aligned on a four-byte boundary to optimise the IP stack. For | ||
227 | regular ethernet hardware, the constant NET_IP_ALIGN is used. On most | ||
228 | architectures this constant has the value 2 because the normal ethernet | ||
229 | header is 14 bytes long, so in order to get proper alignment one needs to | ||
230 | DMA to an address which can be expressed as 4*n + 2. One notable exception | ||
231 | here is powerpc which defines NET_IP_ALIGN to 0 because DMA to unaligned | ||
232 | addresses can be very expensive and dwarf the cost of unaligned loads. | ||
233 | |||
234 | For some ethernet hardware that cannot DMA to unaligned addresses like | ||
235 | 4*n+2 or non-ethernet hardware, this can be a problem, and it is then | ||
236 | required to copy the incoming frame into an aligned buffer. Because this is | ||
237 | unnecessary on architectures that can do unaligned accesses, the code can be | ||
238 | made dependent on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS like so: | ||
239 | |||
240 | #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS | ||
241 | skb = original skb | ||
242 | #else | ||
243 | skb = copy skb | ||
244 | #endif | ||
245 | |||
221 | -- | 246 | -- |
222 | Author: Daniel Drake <dsd@gentoo.org> | 247 | Authors: Daniel Drake <dsd@gentoo.org>, |
248 | Johannes Berg <johannes@sipsolutions.net> | ||
223 | With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt, | 249 | With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt, |
224 | Johannes Berg, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, | 250 | Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz, |
225 | Uli Kunitz, Vadim Lobanov | 251 | Vadim Lobanov |
226 | 252 | ||
diff --git a/Documentation/usb/authorization.txt b/Documentation/usb/authorization.txt index 2af400609498..381b22ee7834 100644 --- a/Documentation/usb/authorization.txt +++ b/Documentation/usb/authorization.txt | |||
@@ -8,7 +8,7 @@ not) in a system. This feature will allow you to implement a lock-down | |||
8 | of USB devices, fully controlled by user space. | 8 | of USB devices, fully controlled by user space. |
9 | 9 | ||
10 | As of now, when a USB device is connected it is configured and | 10 | As of now, when a USB device is connected it is configured and |
11 | it's interfaces inmediately made available to the users. With this | 11 | its interfaces are immediately made available to the users. With this |
12 | modification, only if root authorizes the device to be configured will | 12 | modification, only if root authorizes the device to be configured will |
13 | then it be possible to use it. | 13 | then it be possible to use it. |
14 | 14 | ||
diff --git a/Documentation/usb/gadget_serial.txt b/Documentation/usb/gadget_serial.txt index 815f5c2301ff..9b22bd14c348 100644 --- a/Documentation/usb/gadget_serial.txt +++ b/Documentation/usb/gadget_serial.txt | |||
@@ -1,6 +1,7 @@ | |||
1 | 1 | ||
2 | Linux Gadget Serial Driver v2.0 | 2 | Linux Gadget Serial Driver v2.0 |
3 | 11/20/2004 | 3 | 11/20/2004 |
4 | (updated 8-May-2008 for v2.3) | ||
4 | 5 | ||
5 | 6 | ||
6 | License and Disclaimer | 7 | License and Disclaimer |
@@ -31,7 +32,7 @@ Prerequisites | |||
31 | ------------- | 32 | ------------- |
32 | Versions of the gadget serial driver are available for the | 33 | Versions of the gadget serial driver are available for the |
33 | 2.4 Linux kernels, but this document assumes you are using | 34 | 2.4 Linux kernels, but this document assumes you are using |
34 | version 2.0 or later of the gadget serial driver in a 2.6 | 35 | version 2.3 or later of the gadget serial driver in a 2.6 |
35 | Linux kernel. | 36 | Linux kernel. |
36 | 37 | ||
37 | This document assumes that you are familiar with Linux and | 38 | This document assumes that you are familiar with Linux and |
@@ -40,6 +41,12 @@ standard utilities, use minicom and HyperTerminal, and work with | |||
40 | USB and serial devices. It also assumes you configure the Linux | 41 | USB and serial devices. It also assumes you configure the Linux |
41 | gadget and usb drivers as modules. | 42 | gadget and usb drivers as modules. |
42 | 43 | ||
44 | With version 2.3 of the driver, major and minor device nodes are | ||
45 | no longer statically defined. Your Linux based system should mount | ||
46 | sysfs in /sys, and use "mdev" (in Busybox) or "udev" to make the | ||
47 | /dev nodes matching the sysfs /sys/class/tty files. | ||
48 | |||
49 | |||
43 | 50 | ||
44 | Overview | 51 | Overview |
45 | -------- | 52 | -------- |
@@ -104,15 +111,8 @@ driver. All this are listed under "USB Gadget Support" when | |||
104 | configuring the kernel. Then rebuild and install the kernel or | 111 | configuring the kernel. Then rebuild and install the kernel or |
105 | modules. | 112 | modules. |
106 | 113 | ||
107 | The gadget serial driver uses major number 127, for now. So you | ||
108 | will need to create a device node for it, like this: | ||
109 | |||
110 | mknod /dev/ttygserial c 127 0 | ||
111 | |||
112 | You only need to do this once. | ||
113 | |||
114 | Then you must load the gadget serial driver. To load it as an | 114 | Then you must load the gadget serial driver. To load it as an |
115 | ACM device, do this: | 115 | ACM device (recommended for interoperability), do this: |
116 | 116 | ||
117 | modprobe g_serial use_acm=1 | 117 | modprobe g_serial use_acm=1 |
118 | 118 | ||
@@ -125,6 +125,23 @@ controller driver. This must be done each time you reboot the gadget | |||
125 | side Linux system. You can add this to the start up scripts, if | 125 | side Linux system. You can add this to the start up scripts, if |
126 | desired. | 126 | desired. |
127 | 127 | ||
128 | Your system should use mdev (from busybox) or udev to make the | ||
129 | device nodes. After this gadget driver has been set up you should | ||
130 | then see a /dev/ttyGS0 node: | ||
131 | |||
132 | # ls -l /dev/ttyGS0 | cat | ||
133 | crw-rw---- 1 root root 253, 0 May 8 14:10 /dev/ttyGS0 | ||
134 | # | ||
135 | |||
136 | Note that the major number (253, above) is system-specific. If | ||
137 | you need to create /dev nodes by hand, the right numbers to use | ||
138 | will be in the /sys/class/tty/ttyGS0/dev file. | ||
139 | |||
140 | When you link this gadget driver early, perhaps even statically, | ||
141 | you may want to set up an /etc/inittab entry to run "getty" on it. | ||
142 | The /dev/ttyGS0 line should work like most any other serial port. | ||
143 | |||
144 | |||
128 | If gadget serial is loaded as an ACM device you will want to use | 145 | If gadget serial is loaded as an ACM device you will want to use |
129 | either the Windows or Linux ACM driver on the host side. If gadget | 146 | either the Windows or Linux ACM driver on the host side. If gadget |
130 | serial is loaded as a bulk in/out device, you will want to use the | 147 | serial is loaded as a bulk in/out device, you will want to use the |
diff --git a/Documentation/usb/persist.txt b/Documentation/usb/persist.txt index d56cb1a11550..074b159b77c2 100644 --- a/Documentation/usb/persist.txt +++ b/Documentation/usb/persist.txt | |||
@@ -81,8 +81,11 @@ re-enumeration shows that the device now attached to that port has the | |||
81 | same descriptors as before, including the Vendor and Product IDs, then | 81 | same descriptors as before, including the Vendor and Product IDs, then |
82 | the kernel continues to use the same device structure. In effect, the | 82 | the kernel continues to use the same device structure. In effect, the |
83 | kernel treats the device as though it had merely been reset instead of | 83 | kernel treats the device as though it had merely been reset instead of |
84 | unplugged. The same thing happens if the host controller is in the | 84 | unplugged. |
85 | expected state but a USB device was unplugged and then replugged. | 85 | |
86 | The same thing happens if the host controller is in the expected state | ||
87 | but a USB device was unplugged and then replugged, or if a USB device | ||
88 | fails to carry out a normal resume. | ||
86 | 89 | ||
87 | If no device is now attached to the port, or if the descriptors are | 90 | If no device is now attached to the port, or if the descriptors are |
88 | different from what the kernel remembers, then the treatment is what | 91 | different from what the kernel remembers, then the treatment is what |
diff --git a/Documentation/usb/uhci.txt b/Documentation/usb/uhci.txt deleted file mode 100644 index 2f25952c86c6..000000000000 --- a/Documentation/usb/uhci.txt +++ /dev/null | |||
@@ -1,165 +0,0 @@ | |||
1 | Specification and Internals for the New UHCI Driver (Whitepaper...) | ||
2 | |||
3 | brought to you by | ||
4 | |||
5 | Georg Acher, acher@in.tum.de (executive slave) (base guitar) | ||
6 | Deti Fliegl, deti@fliegl.de (executive slave) (lead voice) | ||
7 | Thomas Sailer, sailer@ife.ee.ethz.ch (chief consultant) (cheer leader) | ||
8 | |||
9 | $Id: README.uhci,v 1.1 1999/12/14 14:03:02 fliegl Exp $ | ||
10 | |||
11 | This document and the new uhci sources can be found on | ||
12 | http://hotswap.in.tum.de/usb | ||
13 | |||
14 | 1. General issues | ||
15 | |||
16 | 1.1 Why a new UHCI driver, we already have one?!? | ||
17 | |||
18 | Correct, but its internal structure got more and more mixed up by the (still | ||
19 | ongoing) efforts to get isochronous transfers (ISO) to work. | ||
20 | Since there is an increasing need for reliable ISO-transfers (especially | ||
21 | for USB-audio needed by TS and for a DAB-USB-Receiver build by GA and DF), | ||
22 | this state was a bit unsatisfying in our opinion, so we've decided (based | ||
23 | on knowledge and experiences with the old UHCI driver) to start | ||
24 | from scratch with a new approach, much simpler but at the same time more | ||
25 | powerful. | ||
26 | It is inspired by the way Win98/Win2000 handles USB requests via URBs, | ||
27 | but it's definitely 100% free of MS-code and doesn't crash while | ||
28 | unplugging an used ISO-device like Win98 ;-) | ||
29 | Some code for HW setup and root hub management was taken from the | ||
30 | original UHCI driver, but heavily modified to fit into the new code. | ||
31 | The invention of the basic concept, and major coding were completed in two | ||
32 | days (and nights) on the 16th and 17th of October 1999, now known as the | ||
33 | great USB-October-Revolution started by GA, DF, and TS ;-) | ||
34 | |||
35 | Since the concept is in no way UHCI dependent, we hope that it will also be | ||
36 | transferred to the OHCI-driver, so both drivers share a common API. | ||
37 | |||
38 | 1.2. Advantages and disadvantages | ||
39 | |||
40 | + All USB transfer types work now! | ||
41 | + Asynchronous operation | ||
42 | + Simple, but powerful interface (only two calls for start and cancel) | ||
43 | + Easy migration to the new API, simplified by a compatibility API | ||
44 | + Simple usage of ISO transfers | ||
45 | + Automatic linking of requests | ||
46 | + ISO transfers allow variable length for each frame and striping | ||
47 | + No CPU dependent and non-portable atomic memory access, no asm()-inlines | ||
48 | + Tested on x86 and Alpha | ||
49 | |||
50 | - Rewriting for ISO transfers needed | ||
51 | |||
52 | 1.3. Is there some compatibility to the old API? | ||
53 | |||
54 | Yes, but only for control, bulk and interrupt transfers. We've implemented | ||
55 | some wrapper calls for these transfer types. The usbcore works fine with | ||
56 | these wrappers. For ISO there's no compatibility, because the old ISO-API | ||
57 | and its semantics were unnecessary complicated in our opinion. | ||
58 | |||
59 | 1.4. What's really working? | ||
60 | |||
61 | As said above, CTRL and BULK already work fine even with the wrappers, | ||
62 | so legacy code wouldn't notice the change. | ||
63 | Regarding to Thomas, ISO transfers now run stable with USB audio. | ||
64 | INT transfers (e.g. mouse driver) work fine, too. | ||
65 | |||
66 | 1.5. Are there any bugs? | ||
67 | |||
68 | No ;-) | ||
69 | Hm... | ||
70 | Well, of course this implementation needs extensive testing on all available | ||
71 | hardware, but we believe that any fixes shouldn't harm the overall concept. | ||
72 | |||
73 | 1.6. What should be done next? | ||
74 | |||
75 | A large part of the request handling seems to be identical for UHCI and | ||
76 | OHCI, so it would be a good idea to extract the common parts and have only | ||
77 | the HW specific stuff in uhci.c. Furthermore, all other USB device drivers | ||
78 | should need URBification, if they use isochronous or interrupt transfers. | ||
79 | One thing missing in the current implementation (and the old UHCI driver) | ||
80 | is fair queueing for BULK transfers. Since this would need (in principle) | ||
81 | the alteration of already constructed TD chains (to switch from depth to | ||
82 | breadth execution), another way has to be found. Maybe some simple | ||
83 | heuristics work with the same effect. | ||
84 | |||
85 | --------------------------------------------------------------------------- | ||
86 | |||
87 | 2. Internal structure and mechanisms | ||
88 | |||
89 | To get quickly familiar with the internal structures, here's a short | ||
90 | description how the new UHCI driver works. However, the ultimate source of | ||
91 | truth is only uhci.c! | ||
92 | |||
93 | 2.1. Descriptor structure (QHs and TDs) | ||
94 | |||
95 | During initialization, the following skeleton is allocated in init_skel: | ||
96 | |||
97 | framespecific | common chain | ||
98 | |||
99 | framelist[] | ||
100 | [ 0 ]-----> TD --> TD -------\ | ||
101 | [ 1 ]-----> TD --> TD --------> TD ----> QH -------> QH -------> QH ---> NULL | ||
102 | ... TD --> TD -------/ | ||
103 | [1023]-----> TD --> TD ------/ | ||
104 | |||
105 | ^^ ^^ ^^ ^^ ^^ ^^ | ||
106 | 1024 TDs for 7 TDs for 1 TD for Start of Start of End Chain | ||
107 | ISO INT (2-128ms) 1ms-INT CTRL Chain BULK Chain | ||
108 | |||
109 | For each CTRL or BULK transfer a new QH is allocated and the containing data | ||
110 | transfers are appended as (vertical) TDs. After building the whole QH with its | ||
111 | dangling TDs, the QH is inserted before the BULK Chain QH (for CTRL) or | ||
112 | before the End Chain QH (for BULK). Since only the QH->next pointers are | ||
113 | affected, no atomic memory operation is required. The three QHs in the | ||
114 | common chain are never equipped with TDs! | ||
115 | |||
116 | For ISO or INT, the TD for each frame is simply inserted into the appropriate | ||
117 | ISO/INT-TD-chain for the desired frame. The 7 skeleton INT-TDs are scattered | ||
118 | among the 1024 frames similar to the old UHCI driver. | ||
119 | |||
120 | For CTRL/BULK/ISO, the last TD in the transfer has the IOC-bit set. For INT, | ||
121 | every TD (there is only one...) has the IOC-bit set. | ||
122 | |||
123 | Besides the data for the UHCI controller (2 or 4 32bit words), the descriptors | ||
124 | are double-linked through the .vertical and .horizontal elements in the | ||
125 | SW data of the descriptor (using the double-linked list structures and | ||
126 | operations), but SW-linking occurs only in closed domains, i.e. for each of | ||
127 | the 1024 ISO-chains and the 8 INT-chains there is a closed cycle. This | ||
128 | simplifies all insertions and unlinking operations and avoids costly | ||
129 | bus_to_virt()-calls. | ||
130 | |||
131 | 2.2. URB structure and linking to QH/TDs | ||
132 | |||
133 | During assembly of the QH and TDs of the requested action, these descriptors | ||
134 | are stored in urb->urb_list, so the allocated QH/TD descriptors are bound to | ||
135 | this URB. | ||
136 | If the assembly was successful and the descriptors were added to the HW chain, | ||
137 | the corresponding URB is inserted into a global URB list for this controller. | ||
138 | This list stores all pending URBs. | ||
139 | |||
140 | 2.3. Interrupt processing | ||
141 | |||
142 | Since UHCI provides no means to directly detect completed transactions, the | ||
143 | following is done in each UHCI interrupt (uhci_interrupt()): | ||
144 | |||
145 | For each URB in the pending queue (process_urb()), the ACTIVE-flag of the | ||
146 | associated TDs are processed (depending on the transfer type | ||
147 | process_{transfer|interrupt|iso}()). If the TDs are not active anymore, | ||
148 | they indicate the completion of the transaction and the status is calculated. | ||
149 | Inactive QH/TDs are removed from the HW chain (since the host controller | ||
150 | already removed the TDs from the QH, no atomic access is needed) and | ||
151 | eventually the URB is marked as completed (OK or errors) and removed from the | ||
152 | pending queue. Then the next linked URB is submitted. After (or immediately | ||
153 | before) that, the completion handler is called. | ||
154 | |||
155 | 2.4. Unlinking URBs | ||
156 | |||
157 | First, all QH/TDs stored in the URB are unlinked from the HW chain. | ||
158 | To ensure that the host controller really left a vertical TD chain, we | ||
159 | wait for one frame. After that, the TDs are physically destroyed. | ||
160 | |||
161 | 2.5. URB linking and the consequences | ||
162 | |||
163 | Since URBs can be linked and the corresponding submit_urb is called in | ||
164 | the UHCI-interrupt, all work associated with URB/QH/TD assembly has to be | ||
165 | interrupt save. This forces kmalloc to use GFP_ATOMIC in the interrupt. | ||
diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828 index 86d1c8e7b18f..eedc399e8deb 100644 --- a/Documentation/video4linux/CARDLIST.au0828 +++ b/Documentation/video4linux/CARDLIST.au0828 | |||
@@ -2,3 +2,4 @@ | |||
2 | 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008] | 2 | 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008] |
3 | 2 -> Hauppauge HVR850 (au0828) [2040:7240] | 3 | 2 -> Hauppauge HVR850 (au0828) [2040:7240] |
4 | 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] | 4 | 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] |
5 | 4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281] | ||
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 191194ea1e25..f0e613ba55b8 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 | |||
@@ -8,3 +8,4 @@ | |||
8 | 7 -> Hauppauge WinTV-HVR1200 [0070:71d1,0070:71d3] | 8 | 7 -> Hauppauge WinTV-HVR1200 [0070:71d1,0070:71d3] |
9 | 8 -> Hauppauge WinTV-HVR1700 [0070:8101] | 9 | 8 -> Hauppauge WinTV-HVR1700 [0070:8101] |
10 | 9 -> Hauppauge WinTV-HVR1400 [0070:8010] | 10 | 9 -> Hauppauge WinTV-HVR1400 [0070:8010] |
11 | 10 -> DViCO FusionHDTV7 Dual Express [18ac:d618] | ||
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index 1d6a245c828f..89c7f32abf9f 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx | |||
@@ -1,17 +1,59 @@ | |||
1 | 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] | 1 | 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] |
2 | 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2750,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883] | 2 | 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883] |
3 | 2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036] | 3 | 2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036] |
4 | 3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208] | 4 | 3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208] |
5 | 4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201] | 5 | 4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201] |
6 | 5 -> MSI VOX USB 2.0 (em2820/em2840) | 6 | 5 -> MSI VOX USB 2.0 (em2820/em2840) |
7 | 6 -> Terratec Cinergy 200 USB (em2800) | 7 | 6 -> Terratec Cinergy 200 USB (em2800) |
8 | 7 -> Leadtek Winfast USB II (em2800) | 8 | 7 -> Leadtek Winfast USB II (em2800) [0413:6023] |
9 | 8 -> Kworld USB2800 (em2800) | 9 | 8 -> Kworld USB2800 (em2800) |
10 | 9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a] | 10 | 9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a] |
11 | 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500,2040:6502] | 11 | 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] |
12 | 11 -> Terratec Hybrid XS (em2880) [0ccd:0042] | 12 | 11 -> Terratec Hybrid XS (em2880) [0ccd:0042] |
13 | 12 -> Kworld PVR TV 2800 RF (em2820/em2840) | 13 | 12 -> Kworld PVR TV 2800 RF (em2820/em2840) |
14 | 13 -> Terratec Prodigy XS (em2880) [0ccd:0047] | 14 | 13 -> Terratec Prodigy XS (em2880) [0ccd:0047] |
15 | 14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840) | 15 | 14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840) |
16 | 15 -> V-Gear PocketTV (em2800) | 16 | 15 -> V-Gear PocketTV (em2800) |
17 | 16 -> Hauppauge WinTV HVR 950 (em2880) [2040:6513,2040:6517,2040:651b,2040:651f] | 17 | 16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b,2040:651f] |
18 | 17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227] | ||
19 | 18 -> Hauppauge WinTV HVR 900 (R2) (em2880) [2040:6502] | ||
20 | 19 -> PointNix Intra-Oral Camera (em2860) | ||
21 | 20 -> AMD ATI TV Wonder HD 600 (em2880) [0438:b002] | ||
22 | 21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder (em2800) [eb1a:2801] | ||
23 | 22 -> Unknown EM2750/EM2751 webcam grabber (em2750) [eb1a:2750,eb1a:2751] | ||
24 | 23 -> Huaqi DLCW-130 (em2750) | ||
25 | 24 -> D-Link DUB-T210 TV Tuner (em2820/em2840) [2001:f112] | ||
26 | 25 -> Gadmei UTV310 (em2820/em2840) | ||
27 | 26 -> Hercules Smart TV USB 2.0 (em2820/em2840) | ||
28 | 27 -> Pinnacle PCTV USB 2 (Philips FM1216ME) (em2820/em2840) | ||
29 | 28 -> Leadtek Winfast USB II Deluxe (em2820/em2840) | ||
30 | 29 -> Pinnacle Dazzle DVC 100 (em2820/em2840) | ||
31 | 30 -> Videology 20K14XUSB USB2.0 (em2820/em2840) | ||
32 | 31 -> Usbgear VD204v9 (em2821) | ||
33 | 32 -> Supercomp USB 2.0 TV (em2821) | ||
34 | 33 -> SIIG AVTuner-PVR/Prolink PlayTV USB 2.0 (em2821) | ||
35 | 34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f] | ||
36 | 35 -> Typhoon DVD Maker (em2860) | ||
37 | 36 -> NetGMBH Cam (em2860) | ||
38 | 37 -> Gadmei UTV330 (em2860) | ||
39 | 38 -> Yakumo MovieMixer (em2861) | ||
40 | 39 -> KWorld PVRTV 300U (em2861) [eb1a:e300] | ||
41 | 40 -> Plextor ConvertX PX-TV100U (em2861) [093b:a005] | ||
42 | 41 -> Kworld 350 U DVB-T (em2870) [eb1a:e350] | ||
43 | 42 -> Kworld 355 U DVB-T (em2870) [eb1a:e355,eb1a:e357] | ||
44 | 43 -> Terratec Cinergy T XS (em2870) [0ccd:0043] | ||
45 | 44 -> Terratec Cinergy T XS (MT2060) (em2870) | ||
46 | 45 -> Pinnacle PCTV DVB-T (em2870) | ||
47 | 46 -> Compro, VideoMate U3 (em2870) [185b:2870] | ||
48 | 47 -> KWorld DVB-T 305U (em2880) [eb1a:e305] | ||
49 | 48 -> KWorld DVB-T 310U (em2880) | ||
50 | 49 -> MSI DigiVox A/D (em2880) [eb1a:e310] | ||
51 | 50 -> MSI DigiVox A/D II (em2880) [eb1a:e320] | ||
52 | 51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c] | ||
53 | 52 -> DNT DA2 Hybrid (em2881) | ||
54 | 53 -> Pinnacle Hybrid Pro (em2881) | ||
55 | 54 -> Kworld VS-DVB-T 323UR (em2882) [eb1a:e323] | ||
56 | 55 -> Terratec Hybrid XS (em2882) (em2882) [0ccd:005e] | ||
57 | 56 -> Pinnacle Hybrid Pro (2) (em2882) [2304:0226] | ||
58 | 57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316] | ||
59 | 58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041] | ||
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 67937df1e974..39868af9cf9f 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 | |||
@@ -37,7 +37,7 @@ | |||
37 | 36 -> UPMOST PURPLE TV [12ab:0800] | 37 | 36 -> UPMOST PURPLE TV [12ab:0800] |
38 | 37 -> Items MuchTV Plus / IT-005 | 38 | 37 -> Items MuchTV Plus / IT-005 |
39 | 38 -> Terratec Cinergy 200 TV [153b:1152] | 39 | 38 -> Terratec Cinergy 200 TV [153b:1152] |
40 | 39 -> LifeView FlyTV Platinum Mini [5168:0212,4e42:0212] | 40 | 39 -> LifeView FlyTV Platinum Mini [5168:0212,4e42:0212,5169:1502] |
41 | 40 -> Compro VideoMate TV PVR/FM [185b:c100] | 41 | 40 -> Compro VideoMate TV PVR/FM [185b:c100] |
42 | 41 -> Compro VideoMate TV Gold+ [185b:c100] | 42 | 41 -> Compro VideoMate TV Gold+ [185b:c100] |
43 | 42 -> Sabrent SBT-TVFM (saa7130) | 43 | 42 -> Sabrent SBT-TVFM (saa7130) |
@@ -128,7 +128,7 @@ | |||
128 | 127 -> Beholder BeholdTV 507 FM/RDS / BeholdTV 509 FM [0000:5071,0000:507B,5ace:5070,5ace:5090] | 128 | 127 -> Beholder BeholdTV 507 FM/RDS / BeholdTV 509 FM [0000:5071,0000:507B,5ace:5070,5ace:5090] |
129 | 128 -> Beholder BeholdTV Columbus TVFM [0000:5201] | 129 | 128 -> Beholder BeholdTV Columbus TVFM [0000:5201] |
130 | 129 -> Beholder BeholdTV 607 / BeholdTV 609 [5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093] | 130 | 129 -> Beholder BeholdTV 607 / BeholdTV 609 [5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093] |
131 | 130 -> Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193,5ace:6191] | 131 | 130 -> Beholder BeholdTV M6 [5ace:6190] |
132 | 131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] | 132 | 131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] |
133 | 132 -> Genius TVGO AM11MCE | 133 | 132 -> Genius TVGO AM11MCE |
134 | 133 -> NXP Snake DVB-S reference design | 134 | 133 -> NXP Snake DVB-S reference design |
@@ -141,3 +141,7 @@ | |||
141 | 140 -> Avermedia DVB-S Pro A700 [1461:a7a1] | 141 | 140 -> Avermedia DVB-S Pro A700 [1461:a7a1] |
142 | 141 -> Avermedia DVB-S Hybrid+FM A700 [1461:a7a2] | 142 | 141 -> Avermedia DVB-S Hybrid+FM A700 [1461:a7a2] |
143 | 142 -> Beholder BeholdTV H6 [5ace:6290] | 143 | 142 -> Beholder BeholdTV H6 [5ace:6290] |
144 | 143 -> Beholder BeholdTV M63 [5ace:6191] | ||
145 | 144 -> Beholder BeholdTV M6 Extra [5ace:6193] | ||
146 | 145 -> AVerMedia MiniPCI DVB-T Hybrid M103 [1461:f636] | ||
147 | 146 -> ASUSTeK P7131 Analog | ||
diff --git a/Documentation/video4linux/cx18.txt b/Documentation/video4linux/cx18.txt index 6842c262890f..914cb7e734a2 100644 --- a/Documentation/video4linux/cx18.txt +++ b/Documentation/video4linux/cx18.txt | |||
@@ -1,36 +1,30 @@ | |||
1 | Some notes regarding the cx18 driver for the Conexant CX23418 MPEG | 1 | Some notes regarding the cx18 driver for the Conexant CX23418 MPEG |
2 | encoder chip: | 2 | encoder chip: |
3 | 3 | ||
4 | 1) The only hardware currently supported is the Hauppauge HVR-1600 | 4 | 1) Currently supported are: |
5 | card and the Compro VideoMate H900 (note that this card only | ||
6 | supports analog input, it has no digital tuner!). | ||
7 | 5 | ||
8 | 2) Some people have problems getting the i2c bus to work. Cause unknown. | 6 | - Hauppauge HVR-1600 |
9 | The symptom is that the eeprom cannot be read and the card is | 7 | - Compro VideoMate H900 |
10 | unusable. | 8 | - Yuan MPC718 |
9 | - Conexant Raptor PAL/SECAM devkit | ||
11 | 10 | ||
12 | 3) The audio from the analog tuner is mono only. Probably caused by | 11 | 2) Some people have problems getting the i2c bus to work. |
13 | incorrect audio register information in the datasheet. We are | 12 | The symptom is that the eeprom cannot be read and the card is |
14 | waiting for updated information from Conexant. | 13 | unusable. This is probably fixed, but if you have problems |
14 | then post to the video4linux or ivtv-users mailinglist. | ||
15 | 15 | ||
16 | 4) VBI (raw or sliced) has not yet been implemented. | 16 | 3) VBI (raw or sliced) has not yet been implemented. |
17 | 17 | ||
18 | 5) MPEG indexing is not yet implemented. | 18 | 4) MPEG indexing is not yet implemented. |
19 | 19 | ||
20 | 6) The driver is still a bit rough around the edges, this should | 20 | 5) The driver is still a bit rough around the edges, this should |
21 | improve over time. | 21 | improve over time. |
22 | 22 | ||
23 | 23 | ||
24 | Firmware: | 24 | Firmware: |
25 | 25 | ||
26 | The firmware needs to be extracted from the Windows Hauppauge HVR-1600 | 26 | You can obtain the firmware files here: |
27 | driver, available here: | ||
28 | |||
29 | http://hauppauge.lightpath.net/software/install_cd/hauppauge_cd_3.4d1.zip | ||
30 | 27 | ||
31 | Unzip, then copy the following files to the firmware directory | 28 | http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz |
32 | and rename them as follows: | ||
33 | 29 | ||
34 | Drivers/Driver18/hcw18apu.rom -> v4l-cx23418-apu.fw | 30 | Untar and copy the .fw files to your firmware directory. |
35 | Drivers/Driver18/hcw18enc.rom -> v4l-cx23418-cpu.fw | ||
36 | Drivers/Driver18/hcw18mlC.rom -> v4l-cx23418-dig.fw | ||
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt new file mode 100644 index 000000000000..bcaf4ab383be --- /dev/null +++ b/Documentation/video4linux/gspca.txt | |||
@@ -0,0 +1,243 @@ | |||
1 | List of the webcams known by gspca. | ||
2 | |||
3 | The modules are: | ||
4 | gspca_main main driver | ||
5 | gspca_xxxx subdriver module with xxxx as follows | ||
6 | |||
7 | xxxx vend:prod | ||
8 | ---- | ||
9 | spca501 0000:0000 MystFromOri Unknow Camera | ||
10 | spca501 040a:0002 Kodak DVC-325 | ||
11 | spca500 040a:0300 Kodak EZ200 | ||
12 | zc3xx 041e:041e Creative WebCam Live! | ||
13 | spca500 041e:400a Creative PC-CAM 300 | ||
14 | sunplus 041e:400b Creative PC-CAM 600 | ||
15 | sunplus 041e:4012 PC-Cam350 | ||
16 | sunplus 041e:4013 Creative Pccam750 | ||
17 | zc3xx 041e:4017 Creative Webcam Mobile PD1090 | ||
18 | spca508 041e:4018 Creative Webcam Vista (PD1100) | ||
19 | spca561 041e:401a Creative Webcam Vista (PD1100) | ||
20 | zc3xx 041e:401c Creative NX | ||
21 | spca505 041e:401d Creative Webcam NX ULTRA | ||
22 | zc3xx 041e:401e Creative Nx Pro | ||
23 | zc3xx 041e:401f Creative Webcam Notebook PD1171 | ||
24 | pac207 041e:4028 Creative Webcam Vista Plus | ||
25 | zc3xx 041e:4029 Creative WebCam Vista Pro | ||
26 | zc3xx 041e:4034 Creative Instant P0620 | ||
27 | zc3xx 041e:4035 Creative Instant P0620D | ||
28 | zc3xx 041e:4036 Creative Live ! | ||
29 | zc3xx 041e:403a Creative Nx Pro 2 | ||
30 | spca561 041e:403b Creative Webcam Vista (VF0010) | ||
31 | zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250) | ||
32 | ov519 041e:4052 Creative Live! VISTA IM | ||
33 | zc3xx 041e:4053 Creative Live!Cam Video IM | ||
34 | ov519 041e:405f Creative Live! VISTA VF0330 | ||
35 | ov519 041e:4060 Creative Live! VISTA VF0350 | ||
36 | ov519 041e:4061 Creative Live! VISTA VF0400 | ||
37 | ov519 041e:4064 Creative Live! VISTA VF0420 | ||
38 | ov519 041e:4068 Creative Live! VISTA VF0470 | ||
39 | spca561 0458:7004 Genius VideoCAM Express V2 | ||
40 | sunplus 0458:7006 Genius Dsc 1.3 Smart | ||
41 | zc3xx 0458:7007 Genius VideoCam V2 | ||
42 | zc3xx 0458:700c Genius VideoCam V3 | ||
43 | zc3xx 0458:700f Genius VideoCam Web V2 | ||
44 | sonixj 0458:7025 Genius Eye 311Q | ||
45 | sonixj 045e:00f5 MicroSoft VX3000 | ||
46 | sonixj 045e:00f7 MicroSoft VX1000 | ||
47 | ov519 045e:028c Micro$oft xbox cam | ||
48 | spca508 0461:0815 Micro Innovation IC200 | ||
49 | sunplus 0461:0821 Fujifilm MV-1 | ||
50 | zc3xx 0461:0a00 MicroInnovation WebCam320 | ||
51 | spca500 046d:0890 Logitech QuickCam traveler | ||
52 | vc032x 046d:0892 Logitech Orbicam | ||
53 | vc032x 046d:0896 Logitech Orbicam | ||
54 | zc3xx 046d:08a0 Logitech QC IM | ||
55 | zc3xx 046d:08a1 Logitech QC IM 0x08A1 +sound | ||
56 | zc3xx 046d:08a2 Labtec Webcam Pro | ||
57 | zc3xx 046d:08a3 Logitech QC Chat | ||
58 | zc3xx 046d:08a6 Logitech QCim | ||
59 | zc3xx 046d:08a7 Logitech QuickCam Image | ||
60 | zc3xx 046d:08a9 Logitech Notebook Deluxe | ||
61 | zc3xx 046d:08aa Labtec Webcam Notebook | ||
62 | zc3xx 046d:08ac Logitech QuickCam Cool | ||
63 | zc3xx 046d:08ad Logitech QCCommunicate STX | ||
64 | zc3xx 046d:08ae Logitech QuickCam for Notebooks | ||
65 | zc3xx 046d:08af Logitech QuickCam Cool | ||
66 | zc3xx 046d:08b9 Logitech QC IM ??? | ||
67 | zc3xx 046d:08d7 Logitech QCam STX | ||
68 | zc3xx 046d:08d9 Logitech QuickCam IM/Connect | ||
69 | zc3xx 046d:08d8 Logitech Notebook Deluxe | ||
70 | zc3xx 046d:08da Logitech QuickCam Messenger | ||
71 | zc3xx 046d:08dd Logitech QuickCam for Notebooks | ||
72 | spca500 046d:0900 Logitech Inc. ClickSmart 310 | ||
73 | spca500 046d:0901 Logitech Inc. ClickSmart 510 | ||
74 | sunplus 046d:0905 Logitech ClickSmart 820 | ||
75 | tv8532 046d:0920 QC Express | ||
76 | tv8532 046d:0921 Labtec Webcam | ||
77 | spca561 046d:0928 Logitech QC Express Etch2 | ||
78 | spca561 046d:0929 Labtec Webcam Elch2 | ||
79 | spca561 046d:092a Logitech QC for Notebook | ||
80 | spca561 046d:092b Labtec Webcam Plus | ||
81 | spca561 046d:092c Logitech QC chat Elch2 | ||
82 | spca561 046d:092d Logitech QC Elch2 | ||
83 | spca561 046d:092e Logitech QC Elch2 | ||
84 | spca561 046d:092f Logitech QC Elch2 | ||
85 | sunplus 046d:0960 Logitech ClickSmart 420 | ||
86 | sunplus 0471:0322 Philips DMVC1300K | ||
87 | zc3xx 0471:0325 Philips SPC 200 NC | ||
88 | zc3xx 0471:0326 Philips SPC 300 NC | ||
89 | sonixj 0471:0327 Philips SPC 600 NC | ||
90 | sonixj 0471:0328 Philips SPC 700 NC | ||
91 | zc3xx 0471:032d Philips spc210nc | ||
92 | zc3xx 0471:032e Philips spc315nc | ||
93 | sonixj 0471:0330 Philips SPC 710NC | ||
94 | spca501 0497:c001 Smile International | ||
95 | sunplus 04a5:3003 Benq DC 1300 | ||
96 | sunplus 04a5:3008 Benq DC 1500 | ||
97 | sunplus 04a5:300a Benq DC3410 | ||
98 | spca500 04a5:300c Benq DC1016 | ||
99 | sunplus 04f1:1001 JVC GC A50 | ||
100 | spca561 04fc:0561 Flexcam 100 | ||
101 | sunplus 04fc:500c Sunplus CA500C | ||
102 | sunplus 04fc:504a Aiptek Mini PenCam 1.3 | ||
103 | sunplus 04fc:504b Maxell MaxPocket LE 1.3 | ||
104 | sunplus 04fc:5330 Digitrex 2110 | ||
105 | sunplus 04fc:5360 Sunplus Generic | ||
106 | spca500 04fc:7333 PalmPixDC85 | ||
107 | sunplus 04fc:ffff Pure DigitalDakota | ||
108 | spca501 0506:00df 3Com HomeConnect Lite | ||
109 | sunplus 052b:1513 Megapix V4 | ||
110 | tv8532 0545:808b Veo Stingray | ||
111 | tv8532 0545:8333 Veo Stingray | ||
112 | sunplus 0546:3155 Polaroid PDC3070 | ||
113 | sunplus 0546:3191 Polaroid Ion 80 | ||
114 | sunplus 0546:3273 Polaroid PDC2030 | ||
115 | ov519 054c:0154 Sonny toy4 | ||
116 | ov519 054c:0155 Sonny toy5 | ||
117 | zc3xx 055f:c005 Mustek Wcam300A | ||
118 | spca500 055f:c200 Mustek Gsmart 300 | ||
119 | sunplus 055f:c211 Kowa Bs888e Microcamera | ||
120 | spca500 055f:c220 Gsmart Mini | ||
121 | sunplus 055f:c230 Mustek Digicam 330K | ||
122 | sunplus 055f:c232 Mustek MDC3500 | ||
123 | sunplus 055f:c360 Mustek DV4000 Mpeg4 | ||
124 | sunplus 055f:c420 Mustek gSmart Mini 2 | ||
125 | sunplus 055f:c430 Mustek Gsmart LCD 2 | ||
126 | sunplus 055f:c440 Mustek DV 3000 | ||
127 | sunplus 055f:c520 Mustek gSmart Mini 3 | ||
128 | sunplus 055f:c530 Mustek Gsmart LCD 3 | ||
129 | sunplus 055f:c540 Gsmart D30 | ||
130 | sunplus 055f:c630 Mustek MDC4000 | ||
131 | sunplus 055f:c650 Mustek MDC5500Z | ||
132 | zc3xx 055f:d003 Mustek WCam300A | ||
133 | zc3xx 055f:d004 Mustek WCam300 AN | ||
134 | conex 0572:0041 Creative Notebook cx11646 | ||
135 | ov519 05a9:0519 OmniVision | ||
136 | ov519 05a9:0530 OmniVision | ||
137 | ov519 05a9:4519 OmniVision | ||
138 | ov519 05a9:8519 OmniVision | ||
139 | sunplus 05da:1018 Digital Dream Enigma 1.3 | ||
140 | stk014 05e1:0893 Syntek DV4000 | ||
141 | spca561 060b:a001 Maxell Compact Pc PM3 | ||
142 | zc3xx 0698:2003 CTX M730V built in | ||
143 | spca500 06bd:0404 Agfa CL20 | ||
144 | spca500 06be:0800 Optimedia | ||
145 | sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom | ||
146 | spca506 06e1:a190 ADS Instant VCD | ||
147 | spca508 0733:0110 ViewQuest VQ110 | ||
148 | spca508 0130:0130 Clone Digital Webcam 11043 | ||
149 | spca501 0733:0401 Intel Create and Share | ||
150 | spca501 0733:0402 ViewQuest M318B | ||
151 | spca505 0733:0430 Intel PC Camera Pro | ||
152 | sunplus 0733:1311 Digital Dream Epsilon 1.3 | ||
153 | sunplus 0733:1314 Mercury 2.1MEG Deluxe Classic Cam | ||
154 | sunplus 0733:2211 Jenoptik jdc 21 LCD | ||
155 | sunplus 0733:2221 Mercury Digital Pro 3.1p | ||
156 | sunplus 0733:3261 Concord 3045 spca536a | ||
157 | sunplus 0733:3281 Cyberpix S550V | ||
158 | spca506 0734:043b 3DeMon USB Capture aka | ||
159 | spca500 084d:0003 D-Link DSC-350 | ||
160 | spca500 08ca:0103 Aiptek PocketDV | ||
161 | sunplus 08ca:0104 Aiptek PocketDVII 1.3 | ||
162 | sunplus 08ca:0106 Aiptek Pocket DV3100+ | ||
163 | sunplus 08ca:2008 Aiptek Mini PenCam 2 M | ||
164 | sunplus 08ca:2010 Aiptek PocketCam 3M | ||
165 | sunplus 08ca:2016 Aiptek PocketCam 2 Mega | ||
166 | sunplus 08ca:2018 Aiptek Pencam SD 2M | ||
167 | sunplus 08ca:2020 Aiptek Slim 3000F | ||
168 | sunplus 08ca:2022 Aiptek Slim 3200 | ||
169 | sunplus 08ca:2024 Aiptek DV3500 Mpeg4 | ||
170 | sunplus 08ca:2028 Aiptek PocketCam4M | ||
171 | sunplus 08ca:2040 Aiptek PocketDV4100M | ||
172 | sunplus 08ca:2042 Aiptek PocketDV5100 | ||
173 | sunplus 08ca:2050 Medion MD 41437 | ||
174 | sunplus 08ca:2060 Aiptek PocketDV5300 | ||
175 | tv8532 0923:010f ICM532 cams | ||
176 | mars 093a:050f Mars-Semi Pc-Camera | ||
177 | pac207 093a:2460 PAC207 Qtec Webcam 100 | ||
178 | pac207 093a:2463 Philips spc200nc pac207 | ||
179 | pac207 093a:2464 Labtec Webcam 1200 | ||
180 | pac207 093a:2468 PAC207 | ||
181 | pac207 093a:2470 Genius GF112 | ||
182 | pac207 093a:2471 PAC207 Genius VideoCam ge111 | ||
183 | pac207 093a:2472 PAC207 Genius VideoCam ge110 | ||
184 | pac7311 093a:2600 PAC7311 Typhoon | ||
185 | pac7311 093a:2601 PAC7311 Phillips SPC610NC | ||
186 | pac7311 093a:2603 PAC7312 | ||
187 | pac7311 093a:2608 PAC7311 Trust WB-3300p | ||
188 | pac7311 093a:260e PAC7311 Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350 | ||
189 | pac7311 093a:260f PAC7311 SnakeCam | ||
190 | pac7311 093a:2621 PAC731x | ||
191 | zc3xx 0ac8:0302 Z-star Vimicro zc0302 | ||
192 | vc032x 0ac8:0321 Vimicro generic vc0321 | ||
193 | vc032x 0ac8:0323 Vimicro Vc0323 | ||
194 | vc032x 0ac8:0328 A4Tech PK-130MG | ||
195 | zc3xx 0ac8:301b Z-Star zc301b | ||
196 | zc3xx 0ac8:303b Vimicro 0x303b | ||
197 | zc3xx 0ac8:305b Z-star Vimicro zc0305b | ||
198 | zc3xx 0ac8:307b Ldlc VC302+Ov7620 | ||
199 | vc032x 0ac8:c001 Sony embedded vimicro | ||
200 | vc032x 0ac8:c002 Sony embedded vimicro | ||
201 | spca508 0af9:0010 Hama USB Sightcam 100 | ||
202 | spca508 0af9:0011 Hama USB Sightcam 100 | ||
203 | sonixb 0c45:6001 Genius VideoCAM NB | ||
204 | sonixb 0c45:6005 Microdia Sweex Mini Webcam | ||
205 | sonixb 0c45:6007 Sonix sn9c101 + Tas5110D | ||
206 | sonixb 0c45:6009 spcaCam@120 | ||
207 | sonixb 0c45:600d spcaCam@120 | ||
208 | sonixb 0c45:6011 Microdia PC Camera (SN9C102) | ||
209 | sonixb 0c45:6019 Generic Sonix OV7630 | ||
210 | sonixb 0c45:6024 Generic Sonix Tas5130c | ||
211 | sonixb 0c45:6025 Xcam Shanga | ||
212 | sonixb 0c45:6028 Sonix Btc Pc380 | ||
213 | sonixb 0c45:6029 spcaCam@150 | ||
214 | sonixb 0c45:602c Generic Sonix OV7630 | ||
215 | sonixb 0c45:602d LIC-200 LG | ||
216 | sonixb 0c45:602e Genius VideoCam Messenger | ||
217 | sonixj 0c45:6040 Speed NVC 350K | ||
218 | sonixj 0c45:607c Sonix sn9c102p Hv7131R | ||
219 | sonixj 0c45:60c0 Sangha Sn535 | ||
220 | sonixj 0c45:60ec SN9C105+MO4000 | ||
221 | sonixj 0c45:60fb Surfer NoName | ||
222 | sonixj 0c45:60fc LG-LIC300 | ||
223 | sonixj 0c45:612a Avant Camera | ||
224 | sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix | ||
225 | sonixj 0c45:6130 Sonix Pccam | ||
226 | sonixj 0c45:6138 Sn9c120 Mo4000 | ||
227 | sonixj 0c45:613b Surfer SN-206 | ||
228 | sonixj 0c45:613c Sonix Pccam168 | ||
229 | sunplus 0d64:0303 Sunplus FashionCam DXG | ||
230 | etoms 102c:6151 Qcam Sangha CIF | ||
231 | etoms 102c:6251 Qcam xxxxxx VGA | ||
232 | zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128 | ||
233 | spca561 10fd:7e50 FlyCam Usb 100 | ||
234 | zc3xx 10fd:8050 Typhoon Webshot II USB 300k | ||
235 | spca501 1776:501c Arowana 300K CMOS Camera | ||
236 | t613 17a1:0128 T613/TAS5130A | ||
237 | vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC | ||
238 | pac207 2001:f115 D-Link DSB-C120 | ||
239 | spca500 2899:012c Toptro Industrial | ||
240 | spca508 8086:0110 Intel Easy PC Camera | ||
241 | spca500 8086:0630 Intel Pocket PC Camera | ||
242 | spca506 99fa:8988 Grandtec V.cap | ||
243 | spca561 abcd:cdee Petcam | ||
diff --git a/Documentation/video4linux/sn9c102.txt b/Documentation/video4linux/sn9c102.txt index b26f5195af51..73de4050d637 100644 --- a/Documentation/video4linux/sn9c102.txt +++ b/Documentation/video4linux/sn9c102.txt | |||
@@ -157,7 +157,7 @@ Loading can be done as shown below: | |||
157 | 157 | ||
158 | [root@localhost home]# modprobe sn9c102 | 158 | [root@localhost home]# modprobe sn9c102 |
159 | 159 | ||
160 | Note that the module is called "sn9c102" for historic reasons, althought it | 160 | Note that the module is called "sn9c102" for historic reasons, although it |
161 | does not just support the SN9C102. | 161 | does not just support the SN9C102. |
162 | 162 | ||
163 | At this point all the devices supported by the driver and connected to the USB | 163 | At this point all the devices supported by the driver and connected to the USB |
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt index e0bba8393c77..05138e8aea07 100644 --- a/Documentation/video4linux/w9968cf.txt +++ b/Documentation/video4linux/w9968cf.txt | |||
@@ -193,9 +193,6 @@ Description: Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled. | |||
193 | loads that module automatically. This action is performed as | 193 | loads that module automatically. This action is performed as |
194 | once soon as the 'w9968cf' module is loaded into memory. | 194 | once soon as the 'w9968cf' module is loaded into memory. |
195 | Default: 1 | 195 | Default: 1 |
196 | Note: The kernel must be compiled with the CONFIG_KMOD option | ||
197 | enabled for the 'ovcamchip' module to be loaded and for | ||
198 | this parameter to be present. | ||
199 | ------------------------------------------------------------------------------- | 196 | ------------------------------------------------------------------------------- |
200 | Name: simcams | 197 | Name: simcams |
201 | Type: int | 198 | Type: int |
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index 3102b81bef88..ea8714fcc3ad 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt | |||
@@ -77,7 +77,7 @@ memory that is preset in system at this time. System administrators may want | |||
77 | to put this command in one of the local rc init files. This will enable the | 77 | to put this command in one of the local rc init files. This will enable the |
78 | kernel to request huge pages early in the boot process (when the possibility | 78 | kernel to request huge pages early in the boot process (when the possibility |
79 | of getting physical contiguous pages is still very high). In either | 79 | of getting physical contiguous pages is still very high). In either |
80 | case, adminstrators will want to verify the number of hugepages actually | 80 | case, administrators will want to verify the number of hugepages actually |
81 | allocated by checking the sysctl or meminfo. | 81 | allocated by checking the sysctl or meminfo. |
82 | 82 | ||
83 | /proc/sys/vm/nr_overcommit_hugepages indicates how large the pool of | 83 | /proc/sys/vm/nr_overcommit_hugepages indicates how large the pool of |
@@ -95,6 +95,29 @@ this condition holds, however, no more surplus huge pages will be | |||
95 | allowed on the system until one of the two sysctls are increased | 95 | allowed on the system until one of the two sysctls are increased |
96 | sufficiently, or the surplus huge pages go out of use and are freed. | 96 | sufficiently, or the surplus huge pages go out of use and are freed. |
97 | 97 | ||
98 | With support for multiple hugepage pools at run-time available, much of | ||
99 | the hugepage userspace interface has been duplicated in sysfs. The above | ||
100 | information applies to the default hugepage size (which will be | ||
101 | controlled by the proc interfaces for backwards compatibility). The root | ||
102 | hugepage control directory is | ||
103 | |||
104 | /sys/kernel/mm/hugepages | ||
105 | |||
106 | For each hugepage size supported by the running kernel, a subdirectory | ||
107 | will exist, of the form | ||
108 | |||
109 | hugepages-${size}kB | ||
110 | |||
111 | Inside each of these directories, the same set of files will exist: | ||
112 | |||
113 | nr_hugepages | ||
114 | nr_overcommit_hugepages | ||
115 | free_hugepages | ||
116 | resv_hugepages | ||
117 | surplus_hugepages | ||
118 | |||
119 | which function as described above for the default hugepage-sized case. | ||
120 | |||
98 | If the user applications are going to request hugepages using mmap system | 121 | If the user applications are going to request hugepages using mmap system |
99 | call, then it is required that system administrator mount a file system of | 122 | call, then it is required that system administrator mount a file system of |
100 | type hugetlbfs: | 123 | type hugetlbfs: |
diff --git a/Documentation/vm/numa_memory_policy.txt b/Documentation/vm/numa_memory_policy.txt index bad16d3f6a47..6aaaeb38730c 100644 --- a/Documentation/vm/numa_memory_policy.txt +++ b/Documentation/vm/numa_memory_policy.txt | |||
@@ -58,7 +58,7 @@ most general to most specific: | |||
58 | the policy at the time they were allocated. | 58 | the policy at the time they were allocated. |
59 | 59 | ||
60 | VMA Policy: A "VMA" or "Virtual Memory Area" refers to a range of a task's | 60 | VMA Policy: A "VMA" or "Virtual Memory Area" refers to a range of a task's |
61 | virtual adddress space. A task may define a specific policy for a range | 61 | virtual address space. A task may define a specific policy for a range |
62 | of its virtual address space. See the MEMORY POLICIES APIS section, | 62 | of its virtual address space. See the MEMORY POLICIES APIS section, |
63 | below, for an overview of the mbind() system call used to set a VMA | 63 | below, for an overview of the mbind() system call used to set a VMA |
64 | policy. | 64 | policy. |
@@ -353,7 +353,7 @@ follows: | |||
353 | 353 | ||
354 | Because of this extra reference counting, and because we must lookup | 354 | Because of this extra reference counting, and because we must lookup |
355 | shared policies in a tree structure under spinlock, shared policies are | 355 | shared policies in a tree structure under spinlock, shared policies are |
356 | more expensive to use in the page allocation path. This is expecially | 356 | more expensive to use in the page allocation path. This is especially |
357 | true for shared policies on shared memory regions shared by tasks running | 357 | true for shared policies on shared memory regions shared by tasks running |
358 | on different NUMA nodes. This extra overhead can be avoided by always | 358 | on different NUMA nodes. This extra overhead can be avoided by always |
359 | falling back to task or system default policy for shared memory regions, | 359 | falling back to task or system default policy for shared memory regions, |
diff --git a/Documentation/volatile-considered-harmful.txt b/Documentation/volatile-considered-harmful.txt index 10c2e411cca8..991c26a6ef64 100644 --- a/Documentation/volatile-considered-harmful.txt +++ b/Documentation/volatile-considered-harmful.txt | |||
@@ -114,6 +114,6 @@ CREDITS | |||
114 | 114 | ||
115 | Original impetus and research by Randy Dunlap | 115 | Original impetus and research by Randy Dunlap |
116 | Written by Jonathan Corbet | 116 | Written by Jonathan Corbet |
117 | Improvements via coments from Satyam Sharma, Johannes Stezenbach, Jesper | 117 | Improvements via comments from Satyam Sharma, Johannes Stezenbach, Jesper |
118 | Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan | 118 | Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan |
119 | Richter. | 119 | Richter. |
diff --git a/Documentation/i386/IO-APIC.txt b/Documentation/x86/i386/IO-APIC.txt index 30b4c714fbe1..30b4c714fbe1 100644 --- a/Documentation/i386/IO-APIC.txt +++ b/Documentation/x86/i386/IO-APIC.txt | |||
diff --git a/Documentation/i386/boot.txt b/Documentation/x86/i386/boot.txt index 95ad15c3b01f..147bfe511cdd 100644 --- a/Documentation/i386/boot.txt +++ b/Documentation/x86/i386/boot.txt | |||
@@ -1,17 +1,14 @@ | |||
1 | THE LINUX/I386 BOOT PROTOCOL | 1 | THE LINUX/x86 BOOT PROTOCOL |
2 | ---------------------------- | 2 | --------------------------- |
3 | 3 | ||
4 | H. Peter Anvin <hpa@zytor.com> | 4 | On the x86 platform, the Linux kernel uses a rather complicated boot |
5 | Last update 2007-05-23 | ||
6 | |||
7 | On the i386 platform, the Linux kernel uses a rather complicated boot | ||
8 | convention. This has evolved partially due to historical aspects, as | 5 | convention. This has evolved partially due to historical aspects, as |
9 | well as the desire in the early days to have the kernel itself be a | 6 | well as the desire in the early days to have the kernel itself be a |
10 | bootable image, the complicated PC memory model and due to changed | 7 | bootable image, the complicated PC memory model and due to changed |
11 | expectations in the PC industry caused by the effective demise of | 8 | expectations in the PC industry caused by the effective demise of |
12 | real-mode DOS as a mainstream operating system. | 9 | real-mode DOS as a mainstream operating system. |
13 | 10 | ||
14 | Currently, the following versions of the Linux/i386 boot protocol exist. | 11 | Currently, the following versions of the Linux/x86 boot protocol exist. |
15 | 12 | ||
16 | Old kernels: zImage/Image support only. Some very early kernels | 13 | Old kernels: zImage/Image support only. Some very early kernels |
17 | may not even support a command line. | 14 | may not even support a command line. |
@@ -372,10 +369,17 @@ Protocol: 2.00+ | |||
372 | - If 0, the protected-mode code is loaded at 0x10000. | 369 | - If 0, the protected-mode code is loaded at 0x10000. |
373 | - If 1, the protected-mode code is loaded at 0x100000. | 370 | - If 1, the protected-mode code is loaded at 0x100000. |
374 | 371 | ||
372 | Bit 5 (write): QUIET_FLAG | ||
373 | - If 0, print early messages. | ||
374 | - If 1, suppress early messages. | ||
375 | This requests to the kernel (decompressor and early | ||
376 | kernel) to not write early messages that require | ||
377 | accessing the display hardware directly. | ||
378 | |||
375 | Bit 6 (write): KEEP_SEGMENTS | 379 | Bit 6 (write): KEEP_SEGMENTS |
376 | Protocol: 2.07+ | 380 | Protocol: 2.07+ |
377 | - if 0, reload the segment registers in the 32bit entry point. | 381 | - If 0, reload the segment registers in the 32bit entry point. |
378 | - if 1, do not reload the segment registers in the 32bit entry point. | 382 | - If 1, do not reload the segment registers in the 32bit entry point. |
379 | Assume that %cs %ds %ss %es are all set to flat segments with | 383 | Assume that %cs %ds %ss %es are all set to flat segments with |
380 | a base of 0 (or the equivalent for their environment). | 384 | a base of 0 (or the equivalent for their environment). |
381 | 385 | ||
@@ -504,7 +508,7 @@ Protocol: 2.06+ | |||
504 | maximum size was 255. | 508 | maximum size was 255. |
505 | 509 | ||
506 | Field name: hardware_subarch | 510 | Field name: hardware_subarch |
507 | Type: write | 511 | Type: write (optional, defaults to x86/PC) |
508 | Offset/size: 0x23c/4 | 512 | Offset/size: 0x23c/4 |
509 | Protocol: 2.07+ | 513 | Protocol: 2.07+ |
510 | 514 | ||
@@ -520,11 +524,13 @@ Protocol: 2.07+ | |||
520 | 0x00000002 Xen | 524 | 0x00000002 Xen |
521 | 525 | ||
522 | Field name: hardware_subarch_data | 526 | Field name: hardware_subarch_data |
523 | Type: write | 527 | Type: write (subarch-dependent) |
524 | Offset/size: 0x240/8 | 528 | Offset/size: 0x240/8 |
525 | Protocol: 2.07+ | 529 | Protocol: 2.07+ |
526 | 530 | ||
527 | A pointer to data that is specific to hardware subarch | 531 | A pointer to data that is specific to hardware subarch |
532 | This field is currently unused for the default x86/PC environment, | ||
533 | do not modify. | ||
528 | 534 | ||
529 | Field name: payload_offset | 535 | Field name: payload_offset |
530 | Type: read | 536 | Type: read |
@@ -545,6 +551,34 @@ Protocol: 2.08+ | |||
545 | 551 | ||
546 | The length of the payload. | 552 | The length of the payload. |
547 | 553 | ||
554 | Field name: setup_data | ||
555 | Type: write (special) | ||
556 | Offset/size: 0x250/8 | ||
557 | Protocol: 2.09+ | ||
558 | |||
559 | The 64-bit physical pointer to NULL terminated single linked list of | ||
560 | struct setup_data. This is used to define a more extensible boot | ||
561 | parameters passing mechanism. The definition of struct setup_data is | ||
562 | as follow: | ||
563 | |||
564 | struct setup_data { | ||
565 | u64 next; | ||
566 | u32 type; | ||
567 | u32 len; | ||
568 | u8 data[0]; | ||
569 | }; | ||
570 | |||
571 | Where, the next is a 64-bit physical pointer to the next node of | ||
572 | linked list, the next field of the last node is 0; the type is used | ||
573 | to identify the contents of data; the len is the length of data | ||
574 | field; the data holds the real payload. | ||
575 | |||
576 | This list may be modified at a number of points during the bootup | ||
577 | process. Therefore, when modifying this list one should always make | ||
578 | sure to consider the case where the linked list already contains | ||
579 | entries. | ||
580 | |||
581 | |||
548 | **** THE IMAGE CHECKSUM | 582 | **** THE IMAGE CHECKSUM |
549 | 583 | ||
550 | From boot protocol version 2.08 onwards the CRC-32 is calculated over | 584 | From boot protocol version 2.08 onwards the CRC-32 is calculated over |
@@ -553,6 +587,7 @@ initial remainder of 0xffffffff. The checksum is appended to the | |||
553 | file; therefore the CRC of the file up to the limit specified in the | 587 | file; therefore the CRC of the file up to the limit specified in the |
554 | syssize field of the header is always 0. | 588 | syssize field of the header is always 0. |
555 | 589 | ||
590 | |||
556 | **** THE KERNEL COMMAND LINE | 591 | **** THE KERNEL COMMAND LINE |
557 | 592 | ||
558 | The kernel command line has become an important way for the boot | 593 | The kernel command line has become an important way for the boot |
@@ -584,28 +619,6 @@ command line is entered using the following protocol: | |||
584 | covered by setup_move_size, so you may need to adjust this | 619 | covered by setup_move_size, so you may need to adjust this |
585 | field. | 620 | field. |
586 | 621 | ||
587 | Field name: setup_data | ||
588 | Type: write (obligatory) | ||
589 | Offset/size: 0x250/8 | ||
590 | Protocol: 2.09+ | ||
591 | |||
592 | The 64-bit physical pointer to NULL terminated single linked list of | ||
593 | struct setup_data. This is used to define a more extensible boot | ||
594 | parameters passing mechanism. The definition of struct setup_data is | ||
595 | as follow: | ||
596 | |||
597 | struct setup_data { | ||
598 | u64 next; | ||
599 | u32 type; | ||
600 | u32 len; | ||
601 | u8 data[0]; | ||
602 | }; | ||
603 | |||
604 | Where, the next is a 64-bit physical pointer to the next node of | ||
605 | linked list, the next field of the last node is 0; the type is used | ||
606 | to identify the contents of data; the len is the length of data | ||
607 | field; the data holds the real payload. | ||
608 | |||
609 | 622 | ||
610 | **** MEMORY LAYOUT OF THE REAL-MODE CODE | 623 | **** MEMORY LAYOUT OF THE REAL-MODE CODE |
611 | 624 | ||
diff --git a/Documentation/i386/usb-legacy-support.txt b/Documentation/x86/i386/usb-legacy-support.txt index 1894cdfc69d9..1894cdfc69d9 100644 --- a/Documentation/i386/usb-legacy-support.txt +++ b/Documentation/x86/i386/usb-legacy-support.txt | |||
diff --git a/Documentation/i386/zero-page.txt b/Documentation/x86/i386/zero-page.txt index 169ad423a3d1..169ad423a3d1 100644 --- a/Documentation/i386/zero-page.txt +++ b/Documentation/x86/i386/zero-page.txt | |||
diff --git a/Documentation/x86_64/00-INDEX b/Documentation/x86/x86_64/00-INDEX index 92fc20ab5f0e..92fc20ab5f0e 100644 --- a/Documentation/x86_64/00-INDEX +++ b/Documentation/x86/x86_64/00-INDEX | |||
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt index b0c7b6c4abda..b0c7b6c4abda 100644 --- a/Documentation/x86_64/boot-options.txt +++ b/Documentation/x86/x86_64/boot-options.txt | |||
diff --git a/Documentation/x86_64/cpu-hotplug-spec b/Documentation/x86/x86_64/cpu-hotplug-spec index 3c23e0587db3..3c23e0587db3 100644 --- a/Documentation/x86_64/cpu-hotplug-spec +++ b/Documentation/x86/x86_64/cpu-hotplug-spec | |||
diff --git a/Documentation/x86_64/fake-numa-for-cpusets b/Documentation/x86/x86_64/fake-numa-for-cpusets index d1a985c5b00a..d1a985c5b00a 100644 --- a/Documentation/x86_64/fake-numa-for-cpusets +++ b/Documentation/x86/x86_64/fake-numa-for-cpusets | |||
diff --git a/Documentation/x86_64/kernel-stacks b/Documentation/x86/x86_64/kernel-stacks index 5ad65d51fb95..5ad65d51fb95 100644 --- a/Documentation/x86_64/kernel-stacks +++ b/Documentation/x86/x86_64/kernel-stacks | |||
diff --git a/Documentation/x86_64/machinecheck b/Documentation/x86/x86_64/machinecheck index a05e58e7b159..a05e58e7b159 100644 --- a/Documentation/x86_64/machinecheck +++ b/Documentation/x86/x86_64/machinecheck | |||
diff --git a/Documentation/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt index b89b6d2bebfa..efce75097369 100644 --- a/Documentation/x86_64/mm.txt +++ b/Documentation/x86/x86_64/mm.txt | |||
@@ -11,9 +11,8 @@ ffffc10000000000 - ffffc1ffffffffff (=40 bits) hole | |||
11 | ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space | 11 | ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space |
12 | ffffe20000000000 - ffffe2ffffffffff (=40 bits) virtual memory map (1TB) | 12 | ffffe20000000000 - ffffe2ffffffffff (=40 bits) virtual memory map (1TB) |
13 | ... unused hole ... | 13 | ... unused hole ... |
14 | ffffffff80000000 - ffffffff82800000 (=40 MB) kernel text mapping, from phys 0 | 14 | ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0 |
15 | ... unused hole ... | 15 | ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space |
16 | ffffffff88000000 - fffffffffff00000 (=1919 MB) module mapping space | ||
17 | 16 | ||
18 | The direct mapping covers all memory in the system up to the highest | 17 | The direct mapping covers all memory in the system up to the highest |
19 | memory address (this means in some cases it can also include PCI memory | 18 | memory address (this means in some cases it can also include PCI memory |
diff --git a/Documentation/x86_64/uefi.txt b/Documentation/x86/x86_64/uefi.txt index 7d77120a5184..a5e2b4fdb170 100644 --- a/Documentation/x86_64/uefi.txt +++ b/Documentation/x86/x86_64/uefi.txt | |||
@@ -36,3 +36,7 @@ Mechanics: | |||
36 | services. | 36 | services. |
37 | noefi turn off all EFI runtime services | 37 | noefi turn off all EFI runtime services |
38 | reboot_type=k turn off EFI reboot runtime service | 38 | reboot_type=k turn off EFI reboot runtime service |
39 | - If the EFI memory map has additional entries not in the E820 map, | ||
40 | you can include those entries in the kernels memory map of available | ||
41 | physical RAM by using the following kernel command line parameter. | ||
42 | add_efi_memmap include EFI memory map of available physical RAM | ||