diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/HOWTO | 20 | ||||
-rw-r--r-- | Documentation/MSI-HOWTO.txt | 63 | ||||
-rw-r--r-- | Documentation/cpu-hotplug.txt | 148 | ||||
-rw-r--r-- | Documentation/feature-removal-schedule.txt | 2 | ||||
-rw-r--r-- | Documentation/filesystems/00-INDEX | 2 | ||||
-rw-r--r-- | Documentation/filesystems/ext4.txt | 236 | ||||
-rw-r--r-- | Documentation/hwmon/adm9240 | 2 | ||||
-rw-r--r-- | Documentation/hwmon/f71805f | 2 | ||||
-rw-r--r-- | Documentation/hwmon/k8temp | 13 | ||||
-rw-r--r-- | Documentation/hwmon/smsc47m1 | 4 | ||||
-rw-r--r-- | Documentation/hwmon/w83627ehf | 6 | ||||
-rw-r--r-- | Documentation/ibm-acpi.txt | 75 | ||||
-rw-r--r-- | Documentation/input/xpad.txt | 115 | ||||
-rw-r--r-- | Documentation/kernel-parameters.txt | 5 | ||||
-rw-r--r-- | Documentation/lockdep-design.txt | 6 | ||||
-rw-r--r-- | Documentation/memory-barriers.txt | 2 | ||||
-rw-r--r-- | Documentation/mips/time.README | 10 | ||||
-rw-r--r-- | Documentation/s390/CommonIO | 2 | ||||
-rw-r--r-- | Documentation/s390/cds.txt | 52 | ||||
-rw-r--r-- | Documentation/s390/driver-model.txt | 3 | ||||
-rw-r--r-- | Documentation/scsi/ChangeLog.megaraid_sas | 45 | ||||
-rw-r--r-- | Documentation/sysctl/kernel.txt | 5 | ||||
-rw-r--r-- | Documentation/video4linux/CARDLIST.cx88 | 2 |
23 files changed, 619 insertions, 201 deletions
diff --git a/Documentation/HOWTO b/Documentation/HOWTO index d6f3dd1a3464..8d51c148f721 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO | |||
@@ -395,6 +395,26 @@ bugme-janitor mailing list (every change in the bugzilla is mailed here) | |||
395 | 395 | ||
396 | 396 | ||
397 | 397 | ||
398 | Managing bug reports | ||
399 | -------------------- | ||
400 | |||
401 | One of the best ways to put into practice your hacking skills is by fixing | ||
402 | bugs reported by other people. Not only you will help to make the kernel | ||
403 | more stable, you'll learn to fix real world problems and you will improve | ||
404 | your skills, and other developers will be aware of your presence. Fixing | ||
405 | bugs is one of the best ways to get merits among other developers, because | ||
406 | not many people like wasting time fixing other people's bugs. | ||
407 | |||
408 | To work in the already reported bug reports, go to http://bugzilla.kernel.org. | ||
409 | If you want to be advised of the future bug reports, you can subscribe to the | ||
410 | bugme-new mailing list (only new bug reports are mailed here) or to the | ||
411 | bugme-janitor mailing list (every change in the bugzilla is mailed here) | ||
412 | |||
413 | http://lists.osdl.org/mailman/listinfo/bugme-new | ||
414 | http://lists.osdl.org/mailman/listinfo/bugme-janitors | ||
415 | |||
416 | |||
417 | |||
398 | Mailing lists | 418 | Mailing lists |
399 | ------------- | 419 | ------------- |
400 | 420 | ||
diff --git a/Documentation/MSI-HOWTO.txt b/Documentation/MSI-HOWTO.txt index c70306abb7b2..5c34910665d1 100644 --- a/Documentation/MSI-HOWTO.txt +++ b/Documentation/MSI-HOWTO.txt | |||
@@ -470,7 +470,68 @@ LOC: 324553 325068 | |||
470 | ERR: 0 | 470 | ERR: 0 |
471 | MIS: 0 | 471 | MIS: 0 |
472 | 472 | ||
473 | 6. FAQ | 473 | 6. MSI quirks |
474 | |||
475 | Several PCI chipsets or devices are known to not support MSI. | ||
476 | The PCI stack provides 3 possible levels of MSI disabling: | ||
477 | * on a single device | ||
478 | * on all devices behind a specific bridge | ||
479 | * globally | ||
480 | |||
481 | 6.1. Disabling MSI on a single device | ||
482 | |||
483 | Under some circumstances, it might be required to disable MSI on a | ||
484 | single device, It may be achived by either not calling pci_enable_msi() | ||
485 | or all, or setting the pci_dev->no_msi flag before (most of the time | ||
486 | in a quirk). | ||
487 | |||
488 | 6.2. Disabling MSI below a bridge | ||
489 | |||
490 | The vast majority of MSI quirks are required by PCI bridges not | ||
491 | being able to route MSI between busses. In this case, MSI have to be | ||
492 | disabled on all devices behind this bridge. It is achieves by setting | ||
493 | the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge | ||
494 | subordinate bus. There is no need to set the same flag on bridges that | ||
495 | are below the broken brigde. When pci_enable_msi() is called to enable | ||
496 | MSI on a device, pci_msi_supported() takes care of checking the NO_MSI | ||
497 | flag in all parent busses of the device. | ||
498 | |||
499 | Some bridges actually support dynamic MSI support enabling/disabling | ||
500 | by changing some bits in their PCI configuration space (especially | ||
501 | the Hypertransport chipsets such as the nVidia nForce and Serverworks | ||
502 | HT2000). It may then be required to update the NO_MSI flag on the | ||
503 | corresponding devices in the sysfs hierarchy. To enable MSI support | ||
504 | on device "0000:00:0e", do: | ||
505 | |||
506 | echo 1 > /sys/bus/pci/devices/0000:00:0e/msi_bus | ||
507 | |||
508 | To disable MSI support, echo 0 instead of 1. Note that it should be | ||
509 | used with caution since changing this value might break interrupts. | ||
510 | |||
511 | 6.3. Disabling MSI globally | ||
512 | |||
513 | Some extreme cases may require to disable MSI globally on the system. | ||
514 | For now, the only known case is a Serverworks PCI-X chipsets (MSI are | ||
515 | not supported on several busses that are not all connected to the | ||
516 | chipset in the Linux PCI hierarchy). In the vast majority of other | ||
517 | cases, disabling only behind a specific bridge is enough. | ||
518 | |||
519 | For debugging purpose, the user may also pass pci=nomsi on the kernel | ||
520 | command-line to explicitly disable MSI globally. But, once the appro- | ||
521 | priate quirks are added to the kernel, this option should not be | ||
522 | required anymore. | ||
523 | |||
524 | 6.4. Finding why MSI cannot be enabled on a device | ||
525 | |||
526 | Assuming that MSI are not enabled on a device, you should look at | ||
527 | dmesg to find messages that quirks may output when disabling MSI | ||
528 | on some devices, some bridges or even globally. | ||
529 | Then, lspci -t gives the list of bridges above a device. Reading | ||
530 | /sys/bus/pci/devices/0000:00:0e/msi_bus will tell you whether MSI | ||
531 | are enabled (1) or disabled (0). In 0 is found in a single bridge | ||
532 | msi_bus file above the device, MSI cannot be enabled. | ||
533 | |||
534 | 7. FAQ | ||
474 | 535 | ||
475 | Q1. Are there any limitations on using the MSI? | 536 | Q1. Are there any limitations on using the MSI? |
476 | 537 | ||
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index bc107cb157a8..4868c34f7509 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt | |||
@@ -46,7 +46,7 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using | |||
46 | maxcpus=2 will only boot 2. You can choose to bring the | 46 | maxcpus=2 will only boot 2. You can choose to bring the |
47 | other cpus later online, read FAQ's for more info. | 47 | other cpus later online, read FAQ's for more info. |
48 | 48 | ||
49 | additional_cpus*=n Use this to limit hotpluggable cpus. This option sets | 49 | additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets |
50 | cpu_possible_map = cpu_present_map + additional_cpus | 50 | cpu_possible_map = cpu_present_map + additional_cpus |
51 | 51 | ||
52 | (*) Option valid only for following architectures | 52 | (*) Option valid only for following architectures |
@@ -101,15 +101,15 @@ cpu_possible_map/for_each_possible_cpu() to iterate. | |||
101 | 101 | ||
102 | Never use anything other than cpumask_t to represent bitmap of CPUs. | 102 | Never use anything other than cpumask_t to represent bitmap of CPUs. |
103 | 103 | ||
104 | #include <linux/cpumask.h> | 104 | #include <linux/cpumask.h> |
105 | 105 | ||
106 | for_each_possible_cpu - Iterate over cpu_possible_map | 106 | for_each_possible_cpu - Iterate over cpu_possible_map |
107 | for_each_online_cpu - Iterate over cpu_online_map | 107 | for_each_online_cpu - Iterate over cpu_online_map |
108 | for_each_present_cpu - Iterate over cpu_present_map | 108 | for_each_present_cpu - Iterate over cpu_present_map |
109 | for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask. | 109 | for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask. |
110 | 110 | ||
111 | #include <linux/cpu.h> | 111 | #include <linux/cpu.h> |
112 | lock_cpu_hotplug() and unlock_cpu_hotplug(): | 112 | lock_cpu_hotplug() and unlock_cpu_hotplug(): |
113 | 113 | ||
114 | The above calls are used to inhibit cpu hotplug operations. While holding the | 114 | The above calls are used to inhibit cpu hotplug operations. While holding the |
115 | cpucontrol mutex, cpu_online_map will not change. If you merely need to avoid | 115 | cpucontrol mutex, cpu_online_map will not change. If you merely need to avoid |
@@ -120,7 +120,7 @@ will work as long as stop_machine_run() is used to take a cpu down. | |||
120 | 120 | ||
121 | CPU Hotplug - Frequently Asked Questions. | 121 | CPU Hotplug - Frequently Asked Questions. |
122 | 122 | ||
123 | Q: How to i enable my kernel to support CPU hotplug? | 123 | Q: How to enable my kernel to support CPU hotplug? |
124 | A: When doing make defconfig, Enable CPU hotplug support | 124 | A: When doing make defconfig, Enable CPU hotplug support |
125 | 125 | ||
126 | "Processor type and Features" -> Support for Hotpluggable CPUs | 126 | "Processor type and Features" -> Support for Hotpluggable CPUs |
@@ -141,39 +141,39 @@ A: You should now notice an entry in sysfs. | |||
141 | Check if sysfs is mounted, using the "mount" command. You should notice | 141 | Check if sysfs is mounted, using the "mount" command. You should notice |
142 | an entry as shown below in the output. | 142 | an entry as shown below in the output. |
143 | 143 | ||
144 | .... | 144 | .... |
145 | none on /sys type sysfs (rw) | 145 | none on /sys type sysfs (rw) |
146 | .... | 146 | .... |
147 | 147 | ||
148 | if this is not mounted, do the following. | 148 | If this is not mounted, do the following. |
149 | 149 | ||
150 | #mkdir /sysfs | 150 | #mkdir /sysfs |
151 | #mount -t sysfs sys /sys | 151 | #mount -t sysfs sys /sys |
152 | 152 | ||
153 | now you should see entries for all present cpu, the following is an example | 153 | Now you should see entries for all present cpu, the following is an example |
154 | in a 8-way system. | 154 | in a 8-way system. |
155 | 155 | ||
156 | #pwd | 156 | #pwd |
157 | #/sys/devices/system/cpu | 157 | #/sys/devices/system/cpu |
158 | #ls -l | 158 | #ls -l |
159 | total 0 | 159 | total 0 |
160 | drwxr-xr-x 10 root root 0 Sep 19 07:44 . | 160 | drwxr-xr-x 10 root root 0 Sep 19 07:44 . |
161 | drwxr-xr-x 13 root root 0 Sep 19 07:45 .. | 161 | drwxr-xr-x 13 root root 0 Sep 19 07:45 .. |
162 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu0 | 162 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu0 |
163 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu1 | 163 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu1 |
164 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu2 | 164 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu2 |
165 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu3 | 165 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu3 |
166 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu4 | 166 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu4 |
167 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu5 | 167 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu5 |
168 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu6 | 168 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu6 |
169 | drwxr-xr-x 3 root root 0 Sep 19 07:48 cpu7 | 169 | drwxr-xr-x 3 root root 0 Sep 19 07:48 cpu7 |
170 | 170 | ||
171 | Under each directory you would find an "online" file which is the control | 171 | Under each directory you would find an "online" file which is the control |
172 | file to logically online/offline a processor. | 172 | file to logically online/offline a processor. |
173 | 173 | ||
174 | Q: Does hot-add/hot-remove refer to physical add/remove of cpus? | 174 | Q: Does hot-add/hot-remove refer to physical add/remove of cpus? |
175 | A: The usage of hot-add/remove may not be very consistently used in the code. | 175 | A: The usage of hot-add/remove may not be very consistently used in the code. |
176 | CONFIG_CPU_HOTPLUG enables logical online/offline capability in the kernel. | 176 | CONFIG_HOTPLUG_CPU enables logical online/offline capability in the kernel. |
177 | To support physical addition/removal, one would need some BIOS hooks and | 177 | To support physical addition/removal, one would need some BIOS hooks and |
178 | the platform should have something like an attention button in PCI hotplug. | 178 | the platform should have something like an attention button in PCI hotplug. |
179 | CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs. | 179 | CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs. |
@@ -181,17 +181,17 @@ CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs. | |||
181 | Q: How do i logically offline a CPU? | 181 | Q: How do i logically offline a CPU? |
182 | A: Do the following. | 182 | A: Do the following. |
183 | 183 | ||
184 | #echo 0 > /sys/devices/system/cpu/cpuX/online | 184 | #echo 0 > /sys/devices/system/cpu/cpuX/online |
185 | 185 | ||
186 | once the logical offline is successful, check | 186 | Once the logical offline is successful, check |
187 | 187 | ||
188 | #cat /proc/interrupts | 188 | #cat /proc/interrupts |
189 | 189 | ||
190 | you should now not see the CPU that you removed. Also online file will report | 190 | You should now not see the CPU that you removed. Also online file will report |
191 | the state as 0 when a cpu if offline and 1 when its online. | 191 | the state as 0 when a cpu if offline and 1 when its online. |
192 | 192 | ||
193 | #To display the current cpu state. | 193 | #To display the current cpu state. |
194 | #cat /sys/devices/system/cpu/cpuX/online | 194 | #cat /sys/devices/system/cpu/cpuX/online |
195 | 195 | ||
196 | Q: Why cant i remove CPU0 on some systems? | 196 | Q: Why cant i remove CPU0 on some systems? |
197 | A: Some architectures may have some special dependency on a certain CPU. | 197 | A: Some architectures may have some special dependency on a certain CPU. |
@@ -234,8 +234,8 @@ Q: If i have some kernel code that needs to be aware of CPU arrival and | |||
234 | departure, how to i arrange for proper notification? | 234 | departure, how to i arrange for proper notification? |
235 | A: This is what you would need in your kernel code to receive notifications. | 235 | A: This is what you would need in your kernel code to receive notifications. |
236 | 236 | ||
237 | #include <linux/cpu.h> | 237 | #include <linux/cpu.h> |
238 | static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb, | 238 | static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb, |
239 | unsigned long action, void *hcpu) | 239 | unsigned long action, void *hcpu) |
240 | { | 240 | { |
241 | unsigned int cpu = (unsigned long)hcpu; | 241 | unsigned int cpu = (unsigned long)hcpu; |
@@ -279,10 +279,10 @@ Q: I don't see my action being called for all CPUs already up and running? | |||
279 | A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined. | 279 | A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined. |
280 | If you need to perform some action for each cpu already in the system, then | 280 | If you need to perform some action for each cpu already in the system, then |
281 | 281 | ||
282 | for_each_online_cpu(i) { | 282 | for_each_online_cpu(i) { |
283 | foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i); | 283 | foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i); |
284 | foobar_cpu_callback(&foobar-cpu_notifier, CPU_ONLINE, i); | 284 | foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i); |
285 | } | 285 | } |
286 | 286 | ||
287 | Q: If i would like to develop cpu hotplug support for a new architecture, | 287 | Q: If i would like to develop cpu hotplug support for a new architecture, |
288 | what do i need at a minimum? | 288 | what do i need at a minimum? |
@@ -307,38 +307,38 @@ Q: I need to ensure that a particular cpu is not removed when there is some | |||
307 | work specific to this cpu is in progress. | 307 | work specific to this cpu is in progress. |
308 | A: First switch the current thread context to preferred cpu | 308 | A: First switch the current thread context to preferred cpu |
309 | 309 | ||
310 | int my_func_on_cpu(int cpu) | 310 | int my_func_on_cpu(int cpu) |
311 | { | 311 | { |
312 | cpumask_t saved_mask, new_mask = CPU_MASK_NONE; | 312 | cpumask_t saved_mask, new_mask = CPU_MASK_NONE; |
313 | int curr_cpu, err = 0; | 313 | int curr_cpu, err = 0; |
314 | 314 | ||
315 | saved_mask = current->cpus_allowed; | 315 | saved_mask = current->cpus_allowed; |
316 | cpu_set(cpu, new_mask); | 316 | cpu_set(cpu, new_mask); |
317 | err = set_cpus_allowed(current, new_mask); | 317 | err = set_cpus_allowed(current, new_mask); |
318 | 318 | ||
319 | if (err) | 319 | if (err) |
320 | return err; | 320 | return err; |
321 | 321 | ||
322 | /* | 322 | /* |
323 | * If we got scheduled out just after the return from | 323 | * If we got scheduled out just after the return from |
324 | * set_cpus_allowed() before running the work, this ensures | 324 | * set_cpus_allowed() before running the work, this ensures |
325 | * we stay locked. | 325 | * we stay locked. |
326 | */ | 326 | */ |
327 | curr_cpu = get_cpu(); | 327 | curr_cpu = get_cpu(); |
328 | 328 | ||
329 | if (curr_cpu != cpu) { | 329 | if (curr_cpu != cpu) { |
330 | err = -EAGAIN; | 330 | err = -EAGAIN; |
331 | goto ret; | 331 | goto ret; |
332 | } else { | 332 | } else { |
333 | /* | 333 | /* |
334 | * Do work : But cant sleep, since get_cpu() disables preempt | 334 | * Do work : But cant sleep, since get_cpu() disables preempt |
335 | */ | 335 | */ |
336 | } | 336 | } |
337 | ret: | 337 | ret: |
338 | put_cpu(); | 338 | put_cpu(); |
339 | set_cpus_allowed(current, saved_mask); | 339 | set_cpus_allowed(current, saved_mask); |
340 | return err; | 340 | return err; |
341 | } | 341 | } |
342 | 342 | ||
343 | 343 | ||
344 | Q: How do we determine how many CPUs are available for hotplug. | 344 | Q: How do we determine how many CPUs are available for hotplug. |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 24f3c63b3017..1ac3c74646e3 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -255,7 +255,7 @@ Who: Stephen Hemminger <shemminger@osdl.org> | |||
255 | 255 | ||
256 | 256 | ||
257 | What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment | 257 | What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment |
258 | When: Oktober 2008 | 258 | When: October 2008 |
259 | Why: The stacking of class devices makes these values misleading and | 259 | Why: The stacking of class devices makes these values misleading and |
260 | inconsistent. | 260 | inconsistent. |
261 | Class devices should not carry any of these properties, and bus | 261 | Class devices should not carry any of these properties, and bus |
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 3c384c0cf86e..4dc28cc93503 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX | |||
@@ -34,6 +34,8 @@ ext2.txt | |||
34 | - info, mount options and specifications for the Ext2 filesystem. | 34 | - info, mount options and specifications for the Ext2 filesystem. |
35 | ext3.txt | 35 | ext3.txt |
36 | - info, mount options and specifications for the Ext3 filesystem. | 36 | - info, mount options and specifications for the Ext3 filesystem. |
37 | ext4.txt | ||
38 | - info, mount options and specifications for the Ext4 filesystem. | ||
37 | files.txt | 39 | files.txt |
38 | - info on file management in the Linux kernel. | 40 | - info on file management in the Linux kernel. |
39 | fuse.txt | 41 | fuse.txt |
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt new file mode 100644 index 000000000000..6a4adcae9f9a --- /dev/null +++ b/Documentation/filesystems/ext4.txt | |||
@@ -0,0 +1,236 @@ | |||
1 | |||
2 | Ext4 Filesystem | ||
3 | =============== | ||
4 | |||
5 | This is a development version of the ext4 filesystem, an advanced level | ||
6 | of the ext3 filesystem which incorporates scalability and reliability | ||
7 | enhancements for supporting large filesystems (64 bit) in keeping with | ||
8 | increasing disk capacities and state-of-the-art feature requirements. | ||
9 | |||
10 | Mailing list: linux-ext4@vger.kernel.org | ||
11 | |||
12 | |||
13 | 1. Quick usage instructions: | ||
14 | =========================== | ||
15 | |||
16 | - Grab updated e2fsprogs from | ||
17 | ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim/ | ||
18 | This is a patchset on top of e2fsprogs-1.39, which can be found at | ||
19 | ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/ | ||
20 | |||
21 | - It's still mke2fs -j /dev/hda1 | ||
22 | |||
23 | - mount /dev/hda1 /wherever -t ext4dev | ||
24 | |||
25 | - To enable extents, | ||
26 | |||
27 | mount /dev/hda1 /wherever -t ext4dev -o extents | ||
28 | |||
29 | - The filesystem is compatible with the ext3 driver until you add a file | ||
30 | which has extents (ie: `mount -o extents', then create a file). | ||
31 | |||
32 | NOTE: The "extents" mount flag is temporary. It will soon go away and | ||
33 | extents will be enabled by the "-o extents" flag to mke2fs or tune2fs | ||
34 | |||
35 | - When comparing performance with other filesystems, remember that | ||
36 | ext3/4 by default offers higher data integrity guarantees than most. So | ||
37 | when comparing with a metadata-only journalling filesystem, use `mount -o | ||
38 | data=writeback'. And you might as well use `mount -o nobh' too along | ||
39 | with it. Making the journal larger than the mke2fs default often helps | ||
40 | performance with metadata-intensive workloads. | ||
41 | |||
42 | 2. Features | ||
43 | =========== | ||
44 | |||
45 | 2.1 Currently available | ||
46 | |||
47 | * ability to use filesystems > 16TB | ||
48 | * extent format reduces metadata overhead (RAM, IO for access, transactions) | ||
49 | * extent format more robust in face of on-disk corruption due to magics, | ||
50 | * internal redunancy in tree | ||
51 | |||
52 | 2.1 Previously available, soon to be enabled by default by "mkefs.ext4": | ||
53 | |||
54 | * dir_index and resize inode will be on by default | ||
55 | * large inodes will be used by default for fast EAs, nsec timestamps, etc | ||
56 | |||
57 | 2.2 Candidate features for future inclusion | ||
58 | |||
59 | There are several under discussion, whether they all make it in is | ||
60 | partly a function of how much time everyone has to work on them: | ||
61 | |||
62 | * improved file allocation (multi-block alloc, delayed alloc; basically done) | ||
63 | * fix 32000 subdirectory limit (patch exists, needs some e2fsck work) | ||
64 | * nsec timestamps for mtime, atime, ctime, create time (patch exists, | ||
65 | needs some e2fsck work) | ||
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 | |||
71 | Features like metadata checksumming have been discussed and planned for | ||
72 | a bit but no patches exist yet so I'm not sure they're in the near-term | ||
73 | roadmap. | ||
74 | |||
75 | The big performance win will come with mballoc and delalloc. CFS has | ||
76 | been using mballoc for a few years already with Lustre, and IBM + Bull | ||
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 | |||
83 | 3. Options | ||
84 | ========== | ||
85 | |||
86 | When mounting an ext4 filesystem, the following option are accepted: | ||
87 | (*) == default | ||
88 | |||
89 | extents ext4 will use extents to address file data. The | ||
90 | file system will no longer be mountable by ext3. | ||
91 | |||
92 | journal=update Update the ext4 file system's journal to the current | ||
93 | format. | ||
94 | |||
95 | journal=inum When a journal already exists, this option is ignored. | ||
96 | Otherwise, it specifies the number of the inode which | ||
97 | will represent the ext4 file system's journal file. | ||
98 | |||
99 | journal_dev=devnum When the external journal device's major/minor numbers | ||
100 | have changed, this option allows the user to specify | ||
101 | the new journal location. The journal device is | ||
102 | identified through its new major/minor numbers encoded | ||
103 | in devnum. | ||
104 | |||
105 | noload Don't load the journal on mounting. | ||
106 | |||
107 | data=journal All data are committed into the journal prior to being | ||
108 | written into the main file system. | ||
109 | |||
110 | data=ordered (*) All data are forced directly out to the main file | ||
111 | system prior to its metadata being committed to the | ||
112 | journal. | ||
113 | |||
114 | data=writeback Data ordering is not preserved, data may be written | ||
115 | into the main file system after its metadata has been | ||
116 | committed to the journal. | ||
117 | |||
118 | commit=nrsec (*) Ext4 can be told to sync all its data and metadata | ||
119 | every 'nrsec' seconds. The default value is 5 seconds. | ||
120 | This means that if you lose your power, you will lose | ||
121 | as much as the latest 5 seconds of work (your | ||
122 | filesystem will not be damaged though, thanks to the | ||
123 | journaling). This default value (or any low value) | ||
124 | will hurt performance, but it's good for data-safety. | ||
125 | Setting it to 0 will have the same effect as leaving | ||
126 | it at the default (5 seconds). | ||
127 | Setting it to very large values will improve | ||
128 | performance. | ||
129 | |||
130 | barrier=1 This enables/disables barriers. barrier=0 disables | ||
131 | it, barrier=1 enables it. | ||
132 | |||
133 | orlov (*) This enables the new Orlov block allocator. It is | ||
134 | enabled by default. | ||
135 | |||
136 | oldalloc This disables the Orlov block allocator and enables | ||
137 | the old block allocator. Orlov should have better | ||
138 | performance - we'd like to get some feedback if it's | ||
139 | the contrary for you. | ||
140 | |||
141 | user_xattr Enables Extended User Attributes. Additionally, you | ||
142 | need to have extended attribute support enabled in the | ||
143 | kernel configuration (CONFIG_EXT4_FS_XATTR). See the | ||
144 | attr(5) manual page and http://acl.bestbits.at/ to | ||
145 | learn more about extended attributes. | ||
146 | |||
147 | nouser_xattr Disables Extended User Attributes. | ||
148 | |||
149 | acl Enables POSIX Access Control Lists support. | ||
150 | Additionally, you need to have ACL support enabled in | ||
151 | the kernel configuration (CONFIG_EXT4_FS_POSIX_ACL). | ||
152 | See the acl(5) manual page and http://acl.bestbits.at/ | ||
153 | for more information. | ||
154 | |||
155 | noacl This option disables POSIX Access Control List | ||
156 | support. | ||
157 | |||
158 | reservation | ||
159 | |||
160 | noreservation | ||
161 | |||
162 | bsddf (*) Make 'df' act like BSD. | ||
163 | minixdf Make 'df' act like Minix. | ||
164 | |||
165 | check=none Don't do extra checking of bitmaps on mount. | ||
166 | nocheck | ||
167 | |||
168 | debug Extra debugging information is sent to syslog. | ||
169 | |||
170 | errors=remount-ro(*) Remount the filesystem read-only on an error. | ||
171 | errors=continue Keep going on a filesystem error. | ||
172 | errors=panic Panic and halt the machine if an error occurs. | ||
173 | |||
174 | grpid Give objects the same group ID as their creator. | ||
175 | bsdgroups | ||
176 | |||
177 | nogrpid (*) New objects have the group ID of their creator. | ||
178 | sysvgroups | ||
179 | |||
180 | resgid=n The group ID which may use the reserved blocks. | ||
181 | |||
182 | resuid=n The user ID which may use the reserved blocks. | ||
183 | |||
184 | sb=n Use alternate superblock at this location. | ||
185 | |||
186 | quota | ||
187 | noquota | ||
188 | grpquota | ||
189 | usrquota | ||
190 | |||
191 | bh (*) ext4 associates buffer heads to data pages to | ||
192 | nobh (a) cache disk block mapping information | ||
193 | (b) link pages into transaction to provide | ||
194 | ordering guarantees. | ||
195 | "bh" option forces use of buffer heads. | ||
196 | "nobh" option tries to avoid associating buffer | ||
197 | heads (supported only for "writeback" mode). | ||
198 | |||
199 | |||
200 | Data Mode | ||
201 | --------- | ||
202 | There are 3 different data modes: | ||
203 | |||
204 | * writeback mode | ||
205 | In data=writeback mode, ext4 does not journal data at all. This mode provides | ||
206 | a similar level of journaling as that of XFS, JFS, and ReiserFS in its default | ||
207 | mode - metadata journaling. A crash+recovery can cause incorrect data to | ||
208 | appear in files which were written shortly before the crash. This mode will | ||
209 | typically provide the best ext4 performance. | ||
210 | |||
211 | * ordered mode | ||
212 | In data=ordered mode, ext4 only officially journals metadata, but it logically | ||
213 | groups metadata and data blocks into a single unit called a transaction. When | ||
214 | it's time to write the new metadata out to disk, the associated data blocks | ||
215 | are written first. In general, this mode performs slightly slower than | ||
216 | writeback but significantly faster than journal mode. | ||
217 | |||
218 | * journal mode | ||
219 | data=journal mode provides full data and metadata journaling. All new data is | ||
220 | written to the journal first, and then to its final location. | ||
221 | In the event of a crash, the journal can be replayed, bringing both data and | ||
222 | metadata into a consistent state. This mode is the slowest except when data | ||
223 | needs to be read from and written to disk at the same time where it | ||
224 | outperforms all others modes. | ||
225 | |||
226 | References | ||
227 | ========== | ||
228 | |||
229 | kernel source: <file:fs/ext4/> | ||
230 | <file:fs/jbd2/> | ||
231 | |||
232 | programs: http://e2fsprogs.sourceforge.net/ | ||
233 | http://ext2resize.sourceforge.net | ||
234 | |||
235 | useful links: http://fedoraproject.org/wiki/ext3-devel | ||
236 | http://www.bullopensource.org/ext4/ | ||
diff --git a/Documentation/hwmon/adm9240 b/Documentation/hwmon/adm9240 index 35f618f32896..2c6f1fed4618 100644 --- a/Documentation/hwmon/adm9240 +++ b/Documentation/hwmon/adm9240 | |||
@@ -24,7 +24,7 @@ Authors: | |||
24 | Frodo Looijaard <frodol@dds.nl>, | 24 | Frodo Looijaard <frodol@dds.nl>, |
25 | Philip Edelbrock <phil@netroedge.com>, | 25 | Philip Edelbrock <phil@netroedge.com>, |
26 | Michiel Rook <michiel@grendelproject.nl>, | 26 | Michiel Rook <michiel@grendelproject.nl>, |
27 | Grant Coady <gcoady@gmail.com> with guidance | 27 | Grant Coady <gcoady.lk@gmail.com> with guidance |
28 | from Jean Delvare <khali@linux-fr.org> | 28 | from Jean Delvare <khali@linux-fr.org> |
29 | 29 | ||
30 | Interface | 30 | Interface |
diff --git a/Documentation/hwmon/f71805f b/Documentation/hwmon/f71805f index 28c5b7d1eb90..2ca69df669c3 100644 --- a/Documentation/hwmon/f71805f +++ b/Documentation/hwmon/f71805f | |||
@@ -17,7 +17,7 @@ Thanks to Kris Chen from Fintek for answering technical questions and | |||
17 | providing additional documentation. | 17 | providing additional documentation. |
18 | 18 | ||
19 | Thanks to Chris Lin from Jetway for providing wiring schematics and | 19 | Thanks to Chris Lin from Jetway for providing wiring schematics and |
20 | anwsering technical questions. | 20 | answering technical questions. |
21 | 21 | ||
22 | 22 | ||
23 | Description | 23 | Description |
diff --git a/Documentation/hwmon/k8temp b/Documentation/hwmon/k8temp index bab445ab0f52..30d123b8d920 100644 --- a/Documentation/hwmon/k8temp +++ b/Documentation/hwmon/k8temp | |||
@@ -2,7 +2,7 @@ Kernel driver k8temp | |||
2 | ==================== | 2 | ==================== |
3 | 3 | ||
4 | Supported chips: | 4 | Supported chips: |
5 | * AMD K8 CPU | 5 | * AMD Athlon64/FX or Opteron CPUs |
6 | Prefix: 'k8temp' | 6 | Prefix: 'k8temp' |
7 | Addresses scanned: PCI space | 7 | Addresses scanned: PCI space |
8 | Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf | 8 | Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf |
@@ -13,10 +13,13 @@ Contact: Rudolf Marek <r.marek@sh.cvut.cz> | |||
13 | Description | 13 | Description |
14 | ----------- | 14 | ----------- |
15 | 15 | ||
16 | This driver permits reading temperature sensor(s) embedded inside AMD K8 CPUs. | 16 | This driver permits reading temperature sensor(s) embedded inside AMD K8 |
17 | Official documentation says that it works from revision F of K8 core, but | 17 | family CPUs (Athlon64/FX, Opteron). Official documentation says that it works |
18 | in fact it seems to be implemented for all revisions of K8 except the first | 18 | from revision F of K8 core, but in fact it seems to be implemented for all |
19 | two revisions (SH-B0 and SH-B3). | 19 | revisions of K8 except the first two revisions (SH-B0 and SH-B3). |
20 | |||
21 | Please note that you will need at least lm-sensors 2.10.1 for proper userspace | ||
22 | support. | ||
20 | 23 | ||
21 | There can be up to four temperature sensors inside single CPU. The driver | 24 | There can be up to four temperature sensors inside single CPU. The driver |
22 | will auto-detect the sensors and will display only temperatures from | 25 | will auto-detect the sensors and will display only temperatures from |
diff --git a/Documentation/hwmon/smsc47m1 b/Documentation/hwmon/smsc47m1 index c15bbe68264e..04a11124f667 100644 --- a/Documentation/hwmon/smsc47m1 +++ b/Documentation/hwmon/smsc47m1 | |||
@@ -2,12 +2,14 @@ Kernel driver smsc47m1 | |||
2 | ====================== | 2 | ====================== |
3 | 3 | ||
4 | Supported chips: | 4 | Supported chips: |
5 | * SMSC LPC47B27x, LPC47M10x, LPC47M13x, LPC47M14x, LPC47M15x and LPC47M192 | 5 | * SMSC LPC47B27x, LPC47M112, LPC47M10x, LPC47M13x, LPC47M14x, |
6 | LPC47M15x and LPC47M192 | ||
6 | Addresses scanned: none, address read from Super I/O config space | 7 | Addresses scanned: none, address read from Super I/O config space |
7 | Prefix: 'smsc47m1' | 8 | Prefix: 'smsc47m1' |
8 | Datasheets: | 9 | Datasheets: |
9 | http://www.smsc.com/main/datasheets/47b27x.pdf | 10 | http://www.smsc.com/main/datasheets/47b27x.pdf |
10 | http://www.smsc.com/main/datasheets/47m10x.pdf | 11 | http://www.smsc.com/main/datasheets/47m10x.pdf |
12 | http://www.smsc.com/main/datasheets/47m112.pdf | ||
11 | http://www.smsc.com/main/tools/discontinued/47m13x.pdf | 13 | http://www.smsc.com/main/tools/discontinued/47m13x.pdf |
12 | http://www.smsc.com/main/datasheets/47m14x.pdf | 14 | http://www.smsc.com/main/datasheets/47m14x.pdf |
13 | http://www.smsc.com/main/tools/discontinued/47m15x.pdf | 15 | http://www.smsc.com/main/tools/discontinued/47m15x.pdf |
diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf index fae3b781d82d..caa610a297e8 100644 --- a/Documentation/hwmon/w83627ehf +++ b/Documentation/hwmon/w83627ehf | |||
@@ -26,7 +26,7 @@ fan control mode). | |||
26 | Temperatures are measured in degrees Celsius and measurement resolution is 1 | 26 | Temperatures are measured in degrees Celsius and measurement resolution is 1 |
27 | degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when | 27 | degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when |
28 | the temperature gets higher than high limit; it stays on until the temperature | 28 | the temperature gets higher than high limit; it stays on until the temperature |
29 | falls below the Hysteresis value. | 29 | falls below the hysteresis value. |
30 | 30 | ||
31 | Fan rotation speeds are reported in RPM (rotations per minute). An alarm is | 31 | Fan rotation speeds are reported in RPM (rotations per minute). An alarm is |
32 | triggered if the rotation speed has dropped below a programmable limit. Fan | 32 | triggered if the rotation speed has dropped below a programmable limit. Fan |
@@ -67,9 +67,9 @@ Thermal Cruise mode | |||
67 | 67 | ||
68 | If the temperature is in the range defined by: | 68 | If the temperature is in the range defined by: |
69 | 69 | ||
70 | pwm[1-4]_target - set target temperature, unit millidegree Celcius | 70 | pwm[1-4]_target - set target temperature, unit millidegree Celsius |
71 | (range 0 - 127000) | 71 | (range 0 - 127000) |
72 | pwm[1-4]_tolerance - tolerance, unit millidegree Celcius (range 0 - 15000) | 72 | pwm[1-4]_tolerance - tolerance, unit millidegree Celsius (range 0 - 15000) |
73 | 73 | ||
74 | there are no changes to fan speed. Once the temperature leaves the interval, | 74 | there are no changes to fan speed. Once the temperature leaves the interval, |
75 | fan speed increases (temp is higher) or decreases if lower than desired. | 75 | fan speed increases (temp is higher) or decreases if lower than desired. |
diff --git a/Documentation/ibm-acpi.txt b/Documentation/ibm-acpi.txt index 71aa40345272..e50595bfd8ea 100644 --- a/Documentation/ibm-acpi.txt +++ b/Documentation/ibm-acpi.txt | |||
@@ -30,9 +30,10 @@ detailed description): | |||
30 | - ACPI sounds | 30 | - ACPI sounds |
31 | - temperature sensors | 31 | - temperature sensors |
32 | - Experimental: embedded controller register dump | 32 | - Experimental: embedded controller register dump |
33 | - Experimental: LCD brightness control | 33 | - LCD brightness control |
34 | - Experimental: volume control | 34 | - Volume control |
35 | - Experimental: fan speed, fan enable/disable | 35 | - Experimental: fan speed, fan enable/disable |
36 | - Experimental: WAN enable and disable | ||
36 | 37 | ||
37 | A compatibility table by model and feature is maintained on the web | 38 | A compatibility table by model and feature is maintained on the web |
38 | site, http://ibm-acpi.sf.net/. I appreciate any success or failure | 39 | site, http://ibm-acpi.sf.net/. I appreciate any success or failure |
@@ -52,40 +53,7 @@ Installation | |||
52 | 53 | ||
53 | If you are compiling this driver as included in the Linux kernel | 54 | If you are compiling this driver as included in the Linux kernel |
54 | sources, simply enable the CONFIG_ACPI_IBM option (Power Management / | 55 | sources, simply enable the CONFIG_ACPI_IBM option (Power Management / |
55 | ACPI / IBM ThinkPad Laptop Extras). The rest of this section describes | 56 | ACPI / IBM ThinkPad Laptop Extras). |
56 | how to install this driver when downloaded from the web site. | ||
57 | |||
58 | First, you need to get a kernel with ACPI support up and running. | ||
59 | Please refer to http://acpi.sourceforge.net/ for help with this | ||
60 | step. How successful you will be depends a lot on you ThinkPad model, | ||
61 | the kernel you are using and any additional patches applied. The | ||
62 | kernel provided with your distribution may not be good enough. I | ||
63 | needed to compile a 2.6.7 kernel with the 20040715 ACPI patch to get | ||
64 | ACPI working reliably on my ThinkPad X40. Old ThinkPad models may not | ||
65 | be supported at all. | ||
66 | |||
67 | Assuming you have the basic ACPI support working (e.g. you can see the | ||
68 | /proc/acpi directory), follow the following steps to install this | ||
69 | driver: | ||
70 | |||
71 | - unpack the archive: | ||
72 | |||
73 | tar xzvf ibm-acpi-x.y.tar.gz; cd ibm-acpi-x.y | ||
74 | |||
75 | - compile the driver: | ||
76 | |||
77 | make | ||
78 | |||
79 | - install the module in your kernel modules directory: | ||
80 | |||
81 | make install | ||
82 | |||
83 | - load the module: | ||
84 | |||
85 | modprobe ibm_acpi | ||
86 | |||
87 | After loading the module, check the "dmesg" output for any error messages. | ||
88 | |||
89 | 57 | ||
90 | Features | 58 | Features |
91 | -------- | 59 | -------- |
@@ -523,13 +491,8 @@ registers contain the current battery capacity, etc. If you experiment | |||
523 | with this, do send me your results (including some complete dumps with | 491 | with this, do send me your results (including some complete dumps with |
524 | a description of the conditions when they were taken.) | 492 | a description of the conditions when they were taken.) |
525 | 493 | ||
526 | EXPERIMENTAL: LCD brightness control -- /proc/acpi/ibm/brightness | 494 | LCD brightness control -- /proc/acpi/ibm/brightness |
527 | ----------------------------------------------------------------- | 495 | --------------------------------------------------- |
528 | |||
529 | This feature is marked EXPERIMENTAL because the implementation | ||
530 | directly accesses hardware registers and may not work as expected. USE | ||
531 | WITH CAUTION! To use this feature, you need to supply the | ||
532 | experimental=1 parameter when loading the module. | ||
533 | 496 | ||
534 | This feature allows software control of the LCD brightness on ThinkPad | 497 | This feature allows software control of the LCD brightness on ThinkPad |
535 | models which don't have a hardware brightness slider. The available | 498 | models which don't have a hardware brightness slider. The available |
@@ -542,13 +505,8 @@ commands are: | |||
542 | The <level> number range is 0 to 7, although not all of them may be | 505 | The <level> number range is 0 to 7, although not all of them may be |
543 | distinct. The current brightness level is shown in the file. | 506 | distinct. The current brightness level is shown in the file. |
544 | 507 | ||
545 | EXPERIMENTAL: Volume control -- /proc/acpi/ibm/volume | 508 | Volume control -- /proc/acpi/ibm/volume |
546 | ----------------------------------------------------- | 509 | --------------------------------------- |
547 | |||
548 | This feature is marked EXPERIMENTAL because the implementation | ||
549 | directly accesses hardware registers and may not work as expected. USE | ||
550 | WITH CAUTION! To use this feature, you need to supply the | ||
551 | experimental=1 parameter when loading the module. | ||
552 | 510 | ||
553 | This feature allows volume control on ThinkPad models which don't have | 511 | This feature allows volume control on ThinkPad models which don't have |
554 | a hardware volume knob. The available commands are: | 512 | a hardware volume knob. The available commands are: |
@@ -611,6 +569,23 @@ with the following command: | |||
611 | 569 | ||
612 | echo 'level <level>' > /proc/acpi/ibm/thermal | 570 | echo 'level <level>' > /proc/acpi/ibm/thermal |
613 | 571 | ||
572 | EXPERIMENTAL: WAN -- /proc/acpi/ibm/wan | ||
573 | --------------------------------------- | ||
574 | |||
575 | This feature is marked EXPERIMENTAL because the implementation | ||
576 | directly accesses hardware registers and may not work as expected. USE | ||
577 | WITH CAUTION! To use this feature, you need to supply the | ||
578 | experimental=1 parameter when loading the module. | ||
579 | |||
580 | This feature shows the presence and current state of a WAN (Sierra | ||
581 | Wireless EV-DO) device. If WAN is installed, the following commands can | ||
582 | be used: | ||
583 | |||
584 | echo enable > /proc/acpi/ibm/wan | ||
585 | echo disable > /proc/acpi/ibm/wan | ||
586 | |||
587 | It was tested on a Lenovo Thinkpad X60. It should probably work on other | ||
588 | Thinkpad models which come with this module installed. | ||
614 | 589 | ||
615 | Multiple Commands, Module Parameters | 590 | Multiple Commands, Module Parameters |
616 | ------------------------------------ | 591 | ------------------------------------ |
diff --git a/Documentation/input/xpad.txt b/Documentation/input/xpad.txt index b9111a703ce0..5427bdf225ed 100644 --- a/Documentation/input/xpad.txt +++ b/Documentation/input/xpad.txt | |||
@@ -3,20 +3,37 @@ xpad - Linux USB driver for X-Box gamepads | |||
3 | This is the very first release of a driver for X-Box gamepads. | 3 | This is the very first release of a driver for X-Box gamepads. |
4 | Basically, this was hacked away in just a few hours, so don't expect | 4 | Basically, this was hacked away in just a few hours, so don't expect |
5 | miracles. | 5 | miracles. |
6 | |||
6 | In particular, there is currently NO support for the rumble pack. | 7 | In particular, there is currently NO support for the rumble pack. |
7 | You won't find many ff-aware linux applications anyway. | 8 | You won't find many ff-aware linux applications anyway. |
8 | 9 | ||
9 | 10 | ||
10 | 0. Status | 11 | 0. Notes |
11 | --------- | 12 | -------- |
13 | |||
14 | Driver updated for kernel 2.6.17.11. (Based on a patch for 2.6.11.4.) | ||
12 | 15 | ||
13 | For now, this driver has only been tested on just one Linux-Box. | 16 | The number of buttons/axes reported varies based on 3 things: |
14 | This one is running a 2.4.18 kernel with usb-uhci on an amd athlon 600. | 17 | - if you are using a known controller |
18 | - if you are using a known dance pad | ||
19 | - if using an unknown device (one not listed below), what you set in the | ||
20 | module configuration for "Map D-PAD to buttons rather than axes for unknown | ||
21 | pads" (module option dpad_to_buttons) | ||
15 | 22 | ||
16 | The jstest-program from joystick-1.2.15 (jstest-version 2.1.0) reports | 23 | If you set dpad_to_buttons to 0 and you are using an unknown device (one |
17 | 8 axes and 10 buttons. | 24 | not listed below), the driver will map the directional pad to axes (X/Y), |
25 | if you said N it will map the d-pad to buttons, which is needed for dance | ||
26 | style games to function correctly. The default is Y. | ||
27 | |||
28 | dpad_to_buttons has no effect for known pads. | ||
29 | |||
30 | 0.1 Normal Controllers | ||
31 | ---------------------- | ||
32 | With a normal controller, the directional pad is mapped to its own X/Y axes. | ||
33 | The jstest-program from joystick-1.2.15 (jstest-version 2.1.0) will report 8 | ||
34 | axes and 10 buttons. | ||
18 | 35 | ||
19 | Alls 8 axes work, though they all have the same range (-32768..32767) | 36 | All 8 axes work, though they all have the same range (-32768..32767) |
20 | and the zero-setting is not correct for the triggers (I don't know if that | 37 | and the zero-setting is not correct for the triggers (I don't know if that |
21 | is some limitation of jstest, since the input device setup should be fine. I | 38 | is some limitation of jstest, since the input device setup should be fine. I |
22 | didn't have a look at jstest itself yet). | 39 | didn't have a look at jstest itself yet). |
@@ -30,16 +47,50 @@ in game functionality were OK. However, I find it rather difficult to | |||
30 | play first person shooters with a pad. Your mileage may vary. | 47 | play first person shooters with a pad. Your mileage may vary. |
31 | 48 | ||
32 | 49 | ||
50 | 0.2 Xbox Dance Pads | ||
51 | ------------------- | ||
52 | When using a known dance pad, jstest will report 6 axes and 14 buttons. | ||
53 | |||
54 | For dance style pads (like the redoctane pad) several changes | ||
55 | have been made. The old driver would map the d-pad to axes, resulting | ||
56 | in the driver being unable to report when the user was pressing both | ||
57 | left+right or up+down, making DDR style games unplayable. | ||
58 | |||
59 | Known dance pads automatically map the d-pad to buttons and will work | ||
60 | correctly out of the box. | ||
61 | |||
62 | If your dance pad is recognized by the driver but is using axes instead | ||
63 | of buttons, see section 0.3 - Unknown Controllers | ||
64 | |||
65 | I've tested this with Stepmania, and it works quite well. | ||
66 | |||
67 | |||
68 | 0.3 Unkown Controllers | ||
69 | ---------------------- | ||
70 | If you have an unkown xbox controller, it should work just fine with | ||
71 | the default settings. | ||
72 | |||
73 | HOWEVER if you have an unknown dance pad not listed below, it will not | ||
74 | work UNLESS you set "dpad_to_buttons" to 1 in the module configuration. | ||
75 | |||
76 | PLEASE if you have an unkown controller, email Dom <binary1230@yahoo.com> with | ||
77 | a dump from /proc/bus/usb and a description of the pad (manufacturer, country, | ||
78 | whether it is a dance pad or normal controller) so that we can add your pad | ||
79 | to the list of supported devices, ensuring that it will work out of the | ||
80 | box in the future. | ||
81 | |||
82 | |||
33 | 1. USB adapter | 83 | 1. USB adapter |
34 | -------------- | 84 | -------------- |
35 | 85 | ||
36 | Before you can actually use the driver, you need to get yourself an | 86 | Before you can actually use the driver, you need to get yourself an |
37 | adapter cable to connect the X-Box controller to your Linux-Box. | 87 | adapter cable to connect the X-Box controller to your Linux-Box. You |
88 | can buy these online fairly cheap, or build your own. | ||
38 | 89 | ||
39 | Such a cable is pretty easy to build. The Controller itself is a USB compound | 90 | Such a cable is pretty easy to build. The Controller itself is a USB |
40 | device (a hub with three ports for two expansion slots and the controller | 91 | compound device (a hub with three ports for two expansion slots and |
41 | device) with the only difference in a nonstandard connector (5 pins vs. 4 on | 92 | the controller device) with the only difference in a nonstandard connector |
42 | standard USB connector). | 93 | (5 pins vs. 4 on standard USB connector). |
43 | 94 | ||
44 | You just need to solder a USB connector onto the cable and keep the | 95 | You just need to solder a USB connector onto the cable and keep the |
45 | yellow wire unconnected. The other pins have the same order on both | 96 | yellow wire unconnected. The other pins have the same order on both |
@@ -51,36 +102,36 @@ original one. You can buy an extension cable and cut that instead. That way, | |||
51 | you can still use the controller with your X-Box, if you have one ;) | 102 | you can still use the controller with your X-Box, if you have one ;) |
52 | 103 | ||
53 | 104 | ||
54 | 2. driver installation | 105 | 2. Driver Installation |
55 | ---------------------- | 106 | ---------------------- |
56 | 107 | ||
57 | Once you have the adapter cable and the controller is connected, you need | 108 | Once you have the adapter cable and the controller is connected, you need |
58 | to load your USB subsystem and should cat /proc/bus/usb/devices. | 109 | to load your USB subsystem and should cat /proc/bus/usb/devices. |
59 | There should be an entry like the one at the end [4]. | 110 | There should be an entry like the one at the end [4]. |
60 | 111 | ||
61 | Currently (as of version 0.0.4), the following three devices are included: | 112 | Currently (as of version 0.0.6), the following devices are included: |
62 | original Microsoft XBOX controller (US), vendor=0x045e, product=0x0202 | 113 | original Microsoft XBOX controller (US), vendor=0x045e, product=0x0202 |
114 | smaller Microsoft XBOX controller (US), vendor=0x045e, product=0x0289 | ||
63 | original Microsoft XBOX controller (Japan), vendor=0x045e, product=0x0285 | 115 | original Microsoft XBOX controller (Japan), vendor=0x045e, product=0x0285 |
64 | InterAct PowerPad Pro (Germany), vendor=0x05fd, product=0x107a | 116 | InterAct PowerPad Pro (Germany), vendor=0x05fd, product=0x107a |
117 | RedOctane Xbox Dance Pad (US), vendor=0x0c12, product=0x8809 | ||
65 | 118 | ||
66 | If you have another controller that is not listed above and is not recognized | 119 | The driver should work with xbox pads not listed above as well, however |
67 | by the driver, please drop me a line with the appropriate info (that is, include | 120 | you will need to do something extra for dance pads to work. |
68 | the name, vendor and product ID, as well as the country where you bought it; | ||
69 | sending the whole dump out of /proc/bus/usb/devices along would be even better). | ||
70 | 121 | ||
71 | In theory, the driver should work with other controllers than mine | 122 | If you have a controller not listed above, see 0.3 - Unknown Controllers |
72 | (InterAct PowerPad pro, bought in Germany) just fine, but I cannot test this | ||
73 | for I only have this one controller. | ||
74 | 123 | ||
75 | If you compiled and installed the driver, test the functionality: | 124 | If you compiled and installed the driver, test the functionality: |
76 | > modprobe xpad | 125 | > modprobe xpad |
77 | > modprobe joydev | 126 | > modprobe joydev |
78 | > jstest /dev/js0 | 127 | > jstest /dev/js0 |
79 | 128 | ||
80 | There should be a single line showing 18 inputs (8 axes, 10 buttons), and | 129 | If you're using a normal controller, there should be a single line showing |
81 | it's values should change if you move the sticks and push the buttons. | 130 | 18 inputs (8 axes, 10 buttons), and its values should change if you move |
131 | the sticks and push the buttons. If you're using a dance pad, it should | ||
132 | show 20 inputs (6 axes, 14 buttons). | ||
82 | 133 | ||
83 | It works? Voila, your done ;) | 134 | It works? Voila, you're done ;) |
84 | 135 | ||
85 | 136 | ||
86 | 3. Thanks | 137 | 3. Thanks |
@@ -111,6 +162,22 @@ I: If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none) | |||
111 | E: Ad=81(I) Atr=03(Int.) MxPS= 32 Ivl= 10ms | 162 | E: Ad=81(I) Atr=03(Int.) MxPS= 32 Ivl= 10ms |
112 | E: Ad=02(O) Atr=03(Int.) MxPS= 32 Ivl= 10ms | 163 | E: Ad=02(O) Atr=03(Int.) MxPS= 32 Ivl= 10ms |
113 | 164 | ||
165 | 5. /proc/bus/usb/devices - dump from Redoctane Xbox Dance Pad (US): | ||
166 | |||
167 | T: Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12 MxCh= 0 | ||
168 | D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 | ||
169 | P: Vendor=0c12 ProdID=8809 Rev= 0.01 | ||
170 | S: Product=XBOX DDR | ||
171 | C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA | ||
172 | I: If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad | ||
173 | E: Ad=82(I) Atr=03(Int.) MxPS= 32 Ivl=4ms | ||
174 | E: Ad=02(O) Atr=03(Int.) MxPS= 32 Ivl=4ms | ||
175 | |||
114 | -- | 176 | -- |
115 | Marko Friedemann <mfr@bmx-chemnitz.de> | 177 | Marko Friedemann <mfr@bmx-chemnitz.de> |
116 | 2002-07-16 | 178 | 2002-07-16 |
179 | - original doc | ||
180 | |||
181 | Dominic Cerquetti <binary1230@yahoo.com> | ||
182 | 2005-03-19 | ||
183 | - added stuff for dance pads, new d-pad->axes mappings | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index ff571f9298e0..dd00fd556a60 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -1231,6 +1231,11 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1231 | machine check when some devices' config space | 1231 | machine check when some devices' config space |
1232 | is read. But various workarounds are disabled | 1232 | is read. But various workarounds are disabled |
1233 | and some IOMMU drivers will not work. | 1233 | and some IOMMU drivers will not work. |
1234 | bfsort Sort PCI devices into breadth-first order. | ||
1235 | This sorting is done to get a device | ||
1236 | order compatible with older (<= 2.4) kernels. | ||
1237 | nobfsort Don't sort PCI devices into breadth-first order. | ||
1238 | |||
1234 | pcmv= [HW,PCMCIA] BadgePAD 4 | 1239 | pcmv= [HW,PCMCIA] BadgePAD 4 |
1235 | 1240 | ||
1236 | pd. [PARIDE] | 1241 | pd. [PARIDE] |
diff --git a/Documentation/lockdep-design.txt b/Documentation/lockdep-design.txt index dab123db5a4f..488773018152 100644 --- a/Documentation/lockdep-design.txt +++ b/Documentation/lockdep-design.txt | |||
@@ -50,10 +50,10 @@ The bit position indicates hardirq, softirq, hardirq-read, | |||
50 | softirq-read respectively, and the character displayed in each | 50 | softirq-read respectively, and the character displayed in each |
51 | indicates: | 51 | indicates: |
52 | 52 | ||
53 | '.' acquired while irqs enabled | 53 | '.' acquired while irqs disabled |
54 | '+' acquired in irq context | 54 | '+' acquired in irq context |
55 | '-' acquired in process context with irqs disabled | 55 | '-' acquired with irqs enabled |
56 | '?' read-acquired both with irqs enabled and in irq context | 56 | '?' read acquired in irq context with irqs enabled. |
57 | 57 | ||
58 | Unused mutexes cannot be part of the cause of an error. | 58 | Unused mutexes cannot be part of the cause of an error. |
59 | 59 | ||
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 994355b0cd19..7f790f66ec68 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt | |||
@@ -1898,7 +1898,7 @@ queue before processing any further requests: | |||
1898 | smp_wmb(); | 1898 | smp_wmb(); |
1899 | <A:modify v=2> <C:busy> | 1899 | <A:modify v=2> <C:busy> |
1900 | <C:queue v=2> | 1900 | <C:queue v=2> |
1901 | p = &b; q = p; | 1901 | p = &v; q = p; |
1902 | <D:request p> | 1902 | <D:request p> |
1903 | <B:modify p=&v> <D:commit p=&v> | 1903 | <B:modify p=&v> <D:commit p=&v> |
1904 | <D:read p> | 1904 | <D:read p> |
diff --git a/Documentation/mips/time.README b/Documentation/mips/time.README index 69ddc5c14b79..e1304b6bc483 100644 --- a/Documentation/mips/time.README +++ b/Documentation/mips/time.README | |||
@@ -63,7 +63,7 @@ the following functions or values: | |||
63 | a) board_time_init - a function pointer. Invoked at the beginnig of | 63 | a) board_time_init - a function pointer. Invoked at the beginnig of |
64 | time_init(). It is optional. | 64 | time_init(). It is optional. |
65 | 1. (optional) set up RTC routines | 65 | 1. (optional) set up RTC routines |
66 | 2. (optional) calibrate and set the mips_counter_frequency | 66 | 2. (optional) calibrate and set the mips_hpt_frequency |
67 | 67 | ||
68 | b) plat_timer_setup - a function pointer. Invoked at the end of time_init() | 68 | b) plat_timer_setup - a function pointer. Invoked at the end of time_init() |
69 | 1. (optional) over-ride any decisions made in time_init() | 69 | 1. (optional) over-ride any decisions made in time_init() |
@@ -72,7 +72,7 @@ the following functions or values: | |||
72 | 72 | ||
73 | c) (optional) board-specific RTC routines. | 73 | c) (optional) board-specific RTC routines. |
74 | 74 | ||
75 | d) (optional) mips_counter_frequency - It must be definied if the board | 75 | d) (optional) mips_hpt_frequency - It must be definied if the board |
76 | is using CPU counter for timer interrupt or it is using fixed rate | 76 | is using CPU counter for timer interrupt or it is using fixed rate |
77 | gettimeoffset(). | 77 | gettimeoffset(). |
78 | 78 | ||
@@ -104,7 +104,7 @@ Step 1: decide how you like to implement the time services. | |||
104 | or use an exnternal timer? | 104 | or use an exnternal timer? |
105 | 105 | ||
106 | In order to use CPU counter register as the timer interrupt source, you | 106 | In order to use CPU counter register as the timer interrupt source, you |
107 | must know the counter speed (mips_counter_frequency). It is usually the | 107 | must know the counter speed (mips_hpt_frequency). It is usually the |
108 | same as the CPU speed or an integral divisor of it. | 108 | same as the CPU speed or an integral divisor of it. |
109 | 109 | ||
110 | d) decide on whether you want to use high-level or low-level timer | 110 | d) decide on whether you want to use high-level or low-level timer |
@@ -121,8 +121,8 @@ Step 3: implement rtc routines, board_time_init() and plat_timer_setup() | |||
121 | if needed. | 121 | if needed. |
122 | 122 | ||
123 | board_time_init() - | 123 | board_time_init() - |
124 | a) (optional) set up RTC routines, | 124 | a) (optional) set up RTC routines, |
125 | b) (optional) calibrate and set the mips_counter_frequency | 125 | b) (optional) calibrate and set the mips_hpt_frequency |
126 | (only needed if you intended to use fixed_rate_gettimeoffset | 126 | (only needed if you intended to use fixed_rate_gettimeoffset |
127 | or use cpu counter as timer interrupt source) | 127 | or use cpu counter as timer interrupt source) |
128 | 128 | ||
diff --git a/Documentation/s390/CommonIO b/Documentation/s390/CommonIO index 59d1166d41ee..d684a6ac69a8 100644 --- a/Documentation/s390/CommonIO +++ b/Documentation/s390/CommonIO | |||
@@ -66,7 +66,7 @@ Command line parameters | |||
66 | 66 | ||
67 | When a device is un-ignored, device recognition and sensing is performed and | 67 | When a device is un-ignored, device recognition and sensing is performed and |
68 | the device driver will be notified if possible, so the device will become | 68 | the device driver will be notified if possible, so the device will become |
69 | available to the system. | 69 | available to the system. Note that un-ignoring is performed asynchronously. |
70 | 70 | ||
71 | You can also add ranges of devices to be ignored by piping to | 71 | You can also add ranges of devices to be ignored by piping to |
72 | /proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the | 72 | /proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the |
diff --git a/Documentation/s390/cds.txt b/Documentation/s390/cds.txt index d80e5733827d..32a96cc39215 100644 --- a/Documentation/s390/cds.txt +++ b/Documentation/s390/cds.txt | |||
@@ -174,14 +174,10 @@ read_dev_chars() - Read Device Characteristics | |||
174 | 174 | ||
175 | This routine returns the characteristics for the device specified. | 175 | This routine returns the characteristics for the device specified. |
176 | 176 | ||
177 | The function is meant to be called with an irq handler in place; that is, | 177 | The function is meant to be called with the device already enabled; that is, |
178 | at earliest during set_online() processing. | 178 | at earliest during set_online() processing. |
179 | 179 | ||
180 | While the request is processed synchronously, the device interrupt | 180 | The ccw_device must not be locked prior to calling read_dev_chars(). |
181 | handler is called for final ending status. In case of error situations the | ||
182 | interrupt handler may recover appropriately. The device irq handler can | ||
183 | recognize the corresponding interrupts by the interruption parameter be | ||
184 | 0x00524443. The ccw_device must not be locked prior to calling read_dev_chars(). | ||
185 | 181 | ||
186 | The function may be called enabled or disabled. | 182 | The function may be called enabled or disabled. |
187 | 183 | ||
@@ -410,26 +406,7 @@ individual flag meanings. | |||
410 | 406 | ||
411 | Usage Notes : | 407 | Usage Notes : |
412 | 408 | ||
413 | Prior to call ccw_device_start() the device driver must assure disabled state, | 409 | ccw_device_start() must be called disabled and with the ccw device lock held. |
414 | i.e. the I/O mask value in the PSW must be disabled. This can be accomplished | ||
415 | by calling local_save_flags( flags). The current PSW flags are preserved and | ||
416 | can be restored by local_irq_restore( flags) at a later time. | ||
417 | |||
418 | If the device driver violates this rule while running in a uni-processor | ||
419 | environment an interrupt might be presented prior to the ccw_device_start() | ||
420 | routine returning to the device driver main path. In this case we will end in a | ||
421 | deadlock situation as the interrupt handler will try to obtain the irq | ||
422 | lock the device driver still owns (see below) ! | ||
423 | |||
424 | The driver must assure to hold the device specific lock. This can be | ||
425 | accomplished by | ||
426 | |||
427 | (i) spin_lock(get_ccwdev_lock(cdev)), or | ||
428 | (ii) spin_lock_irqsave(get_ccwdev_lock(cdev), flags) | ||
429 | |||
430 | Option (i) should be used if the calling routine is running disabled for | ||
431 | I/O interrupts (see above) already. Option (ii) obtains the device gate und | ||
432 | puts the CPU into I/O disabled state by preserving the current PSW flags. | ||
433 | 410 | ||
434 | The device driver is allowed to issue the next ccw_device_start() call from | 411 | The device driver is allowed to issue the next ccw_device_start() call from |
435 | within its interrupt handler already. It is not required to schedule a | 412 | within its interrupt handler already. It is not required to schedule a |
@@ -488,7 +465,7 @@ int ccw_device_resume(struct ccw_device *cdev); | |||
488 | 465 | ||
489 | cdev - ccw_device the resume operation is requested for | 466 | cdev - ccw_device the resume operation is requested for |
490 | 467 | ||
491 | The resume_IO() function returns: | 468 | The ccw_device_resume() function returns: |
492 | 469 | ||
493 | 0 - suspended channel program is resumed | 470 | 0 - suspended channel program is resumed |
494 | -EBUSY - status pending | 471 | -EBUSY - status pending |
@@ -507,6 +484,8 @@ a long-running channel program or the device might require to initially issue | |||
507 | a halt subchannel (HSCH) I/O command. For those purposes the ccw_device_halt() | 484 | a halt subchannel (HSCH) I/O command. For those purposes the ccw_device_halt() |
508 | command is provided. | 485 | command is provided. |
509 | 486 | ||
487 | ccw_device_halt() must be called disabled and with the ccw device lock held. | ||
488 | |||
510 | int ccw_device_halt(struct ccw_device *cdev, | 489 | int ccw_device_halt(struct ccw_device *cdev, |
511 | unsigned long intparm); | 490 | unsigned long intparm); |
512 | 491 | ||
@@ -517,7 +496,7 @@ intparm : interruption parameter; value is only used if no I/O | |||
517 | 496 | ||
518 | The ccw_device_halt() function returns : | 497 | The ccw_device_halt() function returns : |
519 | 498 | ||
520 | 0 - successful completion or request successfully initiated | 499 | 0 - request successfully initiated |
521 | -EBUSY - the device is currently busy, or status pending. | 500 | -EBUSY - the device is currently busy, or status pending. |
522 | -ENODEV - cdev invalid. | 501 | -ENODEV - cdev invalid. |
523 | -EINVAL - The device is not operational or the ccw device is not online. | 502 | -EINVAL - The device is not operational or the ccw device is not online. |
@@ -533,6 +512,23 @@ can then perform an appropriate action. Prior to interrupt of an outstanding | |||
533 | read to a network device (with or without PCI flag) a ccw_device_halt() | 512 | read to a network device (with or without PCI flag) a ccw_device_halt() |
534 | is required to end the pending operation. | 513 | is required to end the pending operation. |
535 | 514 | ||
515 | ccw_device_clear() - Terminage I/O Request Processing | ||
516 | |||
517 | In order to terminate all I/O processing at the subchannel, the clear subchannel | ||
518 | (CSCH) command is used. It can be issued via ccw_device_clear(). | ||
519 | |||
520 | ccw_device_clear() must be called disabled and with the ccw device lock held. | ||
521 | |||
522 | int ccw_device_clear(struct ccw_device *cdev, unsigned long intparm); | ||
523 | |||
524 | cdev: ccw_device the clear operation is requested for | ||
525 | intparm: interruption parameter (see ccw_device_halt()) | ||
526 | |||
527 | The ccw_device_clear() function returns: | ||
528 | |||
529 | 0 - request successfully initiated | ||
530 | -ENODEV - cdev invalid | ||
531 | -EINVAL - The device is not operational or the ccw device is not online. | ||
536 | 532 | ||
537 | Miscellaneous Support Routines | 533 | Miscellaneous Support Routines |
538 | 534 | ||
diff --git a/Documentation/s390/driver-model.txt b/Documentation/s390/driver-model.txt index 62c082387aea..77bf450ec39b 100644 --- a/Documentation/s390/driver-model.txt +++ b/Documentation/s390/driver-model.txt | |||
@@ -239,6 +239,9 @@ status - Can be 'online' or 'offline'. | |||
239 | 239 | ||
240 | type - The physical type of the channel path. | 240 | type - The physical type of the channel path. |
241 | 241 | ||
242 | shared - Whether the channel path is shared. | ||
243 | |||
244 | cmg - The channel measurement group. | ||
242 | 245 | ||
243 | 3. System devices | 246 | 3. System devices |
244 | ----------------- | 247 | ----------------- |
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index d9e5960dafd5..5eb927544990 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas | |||
@@ -1,4 +1,49 @@ | |||
1 | 1 | ||
2 | 1 Release Date : Mon Oct 02 11:21:32 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com> | ||
3 | 2 Current Version : 00.00.03.05 | ||
4 | 3 Older Version : 00.00.03.04 | ||
5 | |||
6 | i. PCI_DEVICE macro used | ||
7 | |||
8 | Convert the pci_device_id-table of the megaraid_sas-driver to the PCI_DEVICE-macro, to safe some lines. | ||
9 | |||
10 | - Henrik Kretzschmar <henne@nachtwindheim.de> | ||
11 | ii. All compiler warnings removed | ||
12 | iii. megasas_ctrl_info struct reverted to 3.02 release | ||
13 | iv. Default value of megasas_dbg_lvl set to 0 | ||
14 | v. Removing in megasas_exit the sysfs entry created for megasas_dbg_lvl | ||
15 | vi. In megasas_teardown_frame_pool(), cmd->frame was passed instead of | ||
16 | cmd->sense to pci_pool_free. Fixed. Bug was pointed out by | ||
17 | Eric Sesterhenn | ||
18 | |||
19 | 1 Release Date : Wed Sep 13 14:22:51 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com> | ||
20 | 2 Current Version : 00.00.03.04 | ||
21 | 3 Older Version : 00.00.03.03 | ||
22 | |||
23 | i. Added Reboot notify | ||
24 | ii. Reduced by 1 max cmds sent to FW from Driver to make the reply_q_sz same | ||
25 | as Max Cmds FW can support | ||
26 | |||
27 | 1 Release Date : Tue Aug 22 16:33:14 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com> | ||
28 | 2 Current Version : 00.00.03.03 | ||
29 | 3 Older Version : 00.00.03.02 | ||
30 | |||
31 | i. Send stop adapter to FW & Dump pending FW cmds before declaring adapter dead. | ||
32 | New varible added to set dbg level. | ||
33 | ii. Disable interrupt made as fn pointer as they are different for 1068 / 1078 | ||
34 | iii. Frame count optimization. Main frame can contain 2 SGE for 64 bit SGLs and | ||
35 | 3 SGE for 32 bit SGL | ||
36 | iv. Tasklet added for cmd completion | ||
37 | v. If FW in operational state before firing INIT, now we send RESET Flag to FW instead of just READY. This is used to do soft reset. | ||
38 | vi. megasas_ctrl_prop structure updated (based on FW struct) | ||
39 | vii. Added print : FW now in Ready State during initialization | ||
40 | |||
41 | 1 Release Date : Sun Aug 06 22:49:52 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com> | ||
42 | 2 Current Version : 00.00.03.02 | ||
43 | 3 Older Version : 00.00.03.01 | ||
44 | |||
45 | i. Added FW tranistion state for Hotplug scenario | ||
46 | |||
2 | 1 Release Date : Sun May 14 22:49:52 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com> | 47 | 1 Release Date : Sun May 14 22:49:52 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com> |
3 | 2 Current Version : 00.00.03.01 | 48 | 2 Current Version : 00.00.03.01 |
4 | 3 Older Version : 00.00.02.04 | 49 | 3 Older Version : 00.00.02.04 |
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 89bf8c20a586..0bc7f1e3c9e6 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt | |||
@@ -86,7 +86,7 @@ valid for 30 seconds. | |||
86 | core_pattern: | 86 | core_pattern: |
87 | 87 | ||
88 | core_pattern is used to specify a core dumpfile pattern name. | 88 | core_pattern is used to specify a core dumpfile pattern name. |
89 | . max length 64 characters; default value is "core" | 89 | . max length 128 characters; default value is "core" |
90 | . core_pattern is used as a pattern template for the output filename; | 90 | . core_pattern is used as a pattern template for the output filename; |
91 | certain string patterns (beginning with '%') are substituted with | 91 | certain string patterns (beginning with '%') are substituted with |
92 | their actual values. | 92 | their actual values. |
@@ -105,6 +105,9 @@ core_pattern is used to specify a core dumpfile pattern name. | |||
105 | %h hostname | 105 | %h hostname |
106 | %e executable filename | 106 | %e executable filename |
107 | %<OTHER> both are dropped | 107 | %<OTHER> both are dropped |
108 | . If the first character of the pattern is a '|', the kernel will treat | ||
109 | the rest of the pattern as a command to run. The core dump will be | ||
110 | written to the standard input of that program instead of to a file. | ||
108 | 111 | ||
109 | ============================================================== | 112 | ============================================================== |
110 | 113 | ||
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index 126e59d935cd..8755b3e7b09e 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 | |||
@@ -51,7 +51,7 @@ | |||
51 | 50 -> NPG Tech Real TV FM Top 10 [14f1:0842] | 51 | 50 -> NPG Tech Real TV FM Top 10 [14f1:0842] |
52 | 51 -> WinFast DTV2000 H [107d:665e] | 52 | 51 -> WinFast DTV2000 H [107d:665e] |
53 | 52 -> Geniatech DVB-S [14f1:0084] | 53 | 52 -> Geniatech DVB-S [14f1:0084] |
54 | 53 -> Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DVB-T [0070:1404] | 54 | 53 -> Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DVB-T [0070:1404,0070:1400,0070:1401,0070:1402] |
55 | 54 -> Norwood Micro TV Tuner | 55 | 54 -> Norwood Micro TV Tuner |
56 | 55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM [c180:c980] | 56 | 55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM [c180:c980] |
57 | 56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602] | 57 | 56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602] |