diff options
author | James Bottomley <jejb@mulgrave.il.steeleye.com> | 2006-06-10 14:47:26 -0400 |
---|---|---|
committer | James Bottomley <jejb@mulgrave.il.steeleye.com> | 2006-06-10 14:47:26 -0400 |
commit | f0cd91a68acdc9b49d7f6738b514a426da627649 (patch) | |
tree | 8ad73564015794197583b094217ae0a71e71e753 /Documentation | |
parent | 60eef25701d25e99c991dd0f4a9f3832a0c3ad3e (diff) | |
parent | 128e6ced247cda88f96fa9f2e4ba8b2c4a681560 (diff) |
Merge ../linux-2.6
Diffstat (limited to 'Documentation')
25 files changed, 834 insertions, 108 deletions
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 1af0f2d50220..2ffb0d62f0fe 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt | |||
@@ -33,7 +33,9 @@ pci_alloc_consistent(struct pci_dev *dev, size_t size, | |||
33 | 33 | ||
34 | Consistent memory is memory for which a write by either the device or | 34 | Consistent memory is memory for which a write by either the device or |
35 | the processor can immediately be read by the processor or device | 35 | the processor can immediately be read by the processor or device |
36 | without having to worry about caching effects. | 36 | without having to worry about caching effects. (You may however need |
37 | to make sure to flush the processor's write buffers before telling | ||
38 | devices to read that memory.) | ||
37 | 39 | ||
38 | This routine allocates a region of <size> bytes of consistent memory. | 40 | This routine allocates a region of <size> bytes of consistent memory. |
39 | it also returns a <dma_handle> which may be cast to an unsigned | 41 | it also returns a <dma_handle> which may be cast to an unsigned |
@@ -304,12 +306,12 @@ dma address with dma_mapping_error(). A non zero return value means the mapping | |||
304 | could not be created and the driver should take appropriate action (eg | 306 | could not be created and the driver should take appropriate action (eg |
305 | reduce current DMA mapping usage or delay and try again later). | 307 | reduce current DMA mapping usage or delay and try again later). |
306 | 308 | ||
307 | int | 309 | int |
308 | dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, | 310 | dma_map_sg(struct device *dev, struct scatterlist *sg, |
309 | enum dma_data_direction direction) | 311 | int nents, enum dma_data_direction direction) |
310 | int | 312 | int |
311 | pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg, | 313 | pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg, |
312 | int nents, int direction) | 314 | int nents, int direction) |
313 | 315 | ||
314 | Maps a scatter gather list from the block layer. | 316 | Maps a scatter gather list from the block layer. |
315 | 317 | ||
@@ -327,12 +329,33 @@ critical that the driver do something, in the case of a block driver | |||
327 | aborting the request or even oopsing is better than doing nothing and | 329 | aborting the request or even oopsing is better than doing nothing and |
328 | corrupting the filesystem. | 330 | corrupting the filesystem. |
329 | 331 | ||
330 | void | 332 | With scatterlists, you use the resulting mapping like this: |
331 | dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nhwentries, | 333 | |
332 | enum dma_data_direction direction) | 334 | int i, count = dma_map_sg(dev, sglist, nents, direction); |
333 | void | 335 | struct scatterlist *sg; |
334 | pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, | 336 | |
335 | int nents, int direction) | 337 | for (i = 0, sg = sglist; i < count; i++, sg++) { |
338 | hw_address[i] = sg_dma_address(sg); | ||
339 | hw_len[i] = sg_dma_len(sg); | ||
340 | } | ||
341 | |||
342 | where nents is the number of entries in the sglist. | ||
343 | |||
344 | The implementation is free to merge several consecutive sglist entries | ||
345 | into one (e.g. with an IOMMU, or if several pages just happen to be | ||
346 | physically contiguous) and returns the actual number of sg entries it | ||
347 | mapped them to. On failure 0, is returned. | ||
348 | |||
349 | Then you should loop count times (note: this can be less than nents times) | ||
350 | and use sg_dma_address() and sg_dma_len() macros where you previously | ||
351 | accessed sg->address and sg->length as shown above. | ||
352 | |||
353 | void | ||
354 | dma_unmap_sg(struct device *dev, struct scatterlist *sg, | ||
355 | int nhwentries, enum dma_data_direction direction) | ||
356 | void | ||
357 | pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, | ||
358 | int nents, int direction) | ||
336 | 359 | ||
337 | unmap the previously mapped scatter/gather list. All the parameters | 360 | unmap the previously mapped scatter/gather list. All the parameters |
338 | must be the same as those and passed in to the scatter/gather mapping | 361 | must be the same as those and passed in to the scatter/gather mapping |
diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt index 10bf4deb96aa..7c717699032c 100644 --- a/Documentation/DMA-mapping.txt +++ b/Documentation/DMA-mapping.txt | |||
@@ -58,11 +58,15 @@ translating each of those pages back to a kernel address using | |||
58 | something like __va(). [ EDIT: Update this when we integrate | 58 | something like __va(). [ EDIT: Update this when we integrate |
59 | Gerd Knorr's generic code which does this. ] | 59 | Gerd Knorr's generic code which does this. ] |
60 | 60 | ||
61 | This rule also means that you may not use kernel image addresses | 61 | This rule also means that you may use neither kernel image addresses |
62 | (ie. items in the kernel's data/text/bss segment, or your driver's) | 62 | (items in data/text/bss segments), nor module image addresses, nor |
63 | nor may you use kernel stack addresses for DMA. Both of these items | 63 | stack addresses for DMA. These could all be mapped somewhere entirely |
64 | might be mapped somewhere entirely different than the rest of physical | 64 | different than the rest of physical memory. Even if those classes of |
65 | memory. | 65 | memory could physically work with DMA, you'd need to ensure the I/O |
66 | buffers were cacheline-aligned. Without that, you'd see cacheline | ||
67 | sharing problems (data corruption) on CPUs with DMA-incoherent caches. | ||
68 | (The CPU could write to one word, DMA would write to a different one | ||
69 | in the same cache line, and one of them could be overwritten.) | ||
66 | 70 | ||
67 | Also, this means that you cannot take the return of a kmap() | 71 | Also, this means that you cannot take the return of a kmap() |
68 | call and DMA to/from that. This is similar to vmalloc(). | 72 | call and DMA to/from that. This is similar to vmalloc(). |
@@ -284,6 +288,11 @@ There are two types of DMA mappings: | |||
284 | 288 | ||
285 | in order to get correct behavior on all platforms. | 289 | in order to get correct behavior on all platforms. |
286 | 290 | ||
291 | Also, on some platforms your driver may need to flush CPU write | ||
292 | buffers in much the same way as it needs to flush write buffers | ||
293 | found in PCI bridges (such as by reading a register's value | ||
294 | after writing it). | ||
295 | |||
287 | - Streaming DMA mappings which are usually mapped for one DMA transfer, | 296 | - Streaming DMA mappings which are usually mapped for one DMA transfer, |
288 | unmapped right after it (unless you use pci_dma_sync_* below) and for which | 297 | unmapped right after it (unless you use pci_dma_sync_* below) and for which |
289 | hardware can optimize for sequential accesses. | 298 | hardware can optimize for sequential accesses. |
@@ -303,6 +312,9 @@ There are two types of DMA mappings: | |||
303 | 312 | ||
304 | Neither type of DMA mapping has alignment restrictions that come | 313 | Neither type of DMA mapping has alignment restrictions that come |
305 | from PCI, although some devices may have such restrictions. | 314 | from PCI, although some devices may have such restrictions. |
315 | Also, systems with caches that aren't DMA-coherent will work better | ||
316 | when the underlying buffers don't share cache lines with other data. | ||
317 | |||
306 | 318 | ||
307 | Using Consistent DMA mappings. | 319 | Using Consistent DMA mappings. |
308 | 320 | ||
diff --git a/Documentation/HOWTO b/Documentation/HOWTO index 6c9e746267da..915ae8c986c6 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO | |||
@@ -603,7 +603,8 @@ start exactly where you are now. | |||
603 | 603 | ||
604 | 604 | ||
605 | ---------- | 605 | ---------- |
606 | Thanks to Paolo Ciarrocchi who allowed the "Development Process" section | 606 | Thanks to Paolo Ciarrocchi who allowed the "Development Process" |
607 | (http://linux.tar.bz/articles/2.6-development_process) section | ||
607 | to be based on text he had written, and to Randy Dunlap and Gerrit | 608 | to be based on text he had written, and to Randy Dunlap and Gerrit |
608 | Huizenga for some of the list of things you should and should not say. | 609 | Huizenga for some of the list of things you should and should not say. |
609 | Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, | 610 | Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, |
diff --git a/Documentation/block/switching-sched.txt b/Documentation/block/switching-sched.txt new file mode 100644 index 000000000000..5fa130a67531 --- /dev/null +++ b/Documentation/block/switching-sched.txt | |||
@@ -0,0 +1,22 @@ | |||
1 | As of the Linux 2.6.10 kernel, it is now possible to change the | ||
2 | IO scheduler for a given block device on the fly (thus making it possible, | ||
3 | for instance, to set the CFQ scheduler for the system default, but | ||
4 | set a specific device to use the anticipatory or noop schedulers - which | ||
5 | can improve that device's throughput). | ||
6 | |||
7 | To set a specific scheduler, simply do this: | ||
8 | |||
9 | echo SCHEDNAME > /sys/block/DEV/queue/scheduler | ||
10 | |||
11 | where SCHEDNAME is the name of a defined IO scheduler, and DEV is the | ||
12 | device name (hda, hdb, sga, or whatever you happen to have). | ||
13 | |||
14 | The list of defined schedulers can be found by simply doing | ||
15 | a "cat /sys/block/DEV/queue/scheduler" - the list of valid names | ||
16 | will be displayed, with the currently selected scheduler in brackets: | ||
17 | |||
18 | # cat /sys/block/hda/queue/scheduler | ||
19 | noop anticipatory deadline [cfq] | ||
20 | # echo anticipatory > /sys/block/hda/queue/scheduler | ||
21 | # cat /sys/block/hda/queue/scheduler | ||
22 | noop [anticipatory] deadline cfq | ||
diff --git a/Documentation/cpu-freq/index.txt b/Documentation/cpu-freq/index.txt index 5009805f9378..ffdb5323df37 100644 --- a/Documentation/cpu-freq/index.txt +++ b/Documentation/cpu-freq/index.txt | |||
@@ -53,4 +53,4 @@ the CPUFreq Mailing list: | |||
53 | * http://lists.linux.org.uk/mailman/listinfo/cpufreq | 53 | * http://lists.linux.org.uk/mailman/listinfo/cpufreq |
54 | 54 | ||
55 | Clock and voltage scaling for the SA-1100: | 55 | Clock and voltage scaling for the SA-1100: |
56 | * http://www.lart.tudelft.nl/projects/scaling | 56 | * http://www.lartmaker.nl/projects/scaling |
diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 3c406acd4dfa..b369a8c46a73 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt | |||
@@ -1721,11 +1721,6 @@ Your cooperation is appreciated. | |||
1721 | These devices support the same API as the generic SCSI | 1721 | These devices support the same API as the generic SCSI |
1722 | devices. | 1722 | devices. |
1723 | 1723 | ||
1724 | 97 block Packet writing for CD/DVD devices | ||
1725 | 0 = /dev/pktcdvd0 First packet-writing module | ||
1726 | 1 = /dev/pktcdvd1 Second packet-writing module | ||
1727 | ... | ||
1728 | |||
1729 | 98 char Control and Measurement Device (comedi) | 1724 | 98 char Control and Measurement Device (comedi) |
1730 | 0 = /dev/comedi0 First comedi device | 1725 | 0 = /dev/comedi0 First comedi device |
1731 | 1 = /dev/comedi1 Second comedi device | 1726 | 1 = /dev/comedi1 Second comedi device |
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 15fc8fbef67e..4820366b6ae8 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware | |||
@@ -259,9 +259,9 @@ sub dibusb { | |||
259 | } | 259 | } |
260 | 260 | ||
261 | sub nxt2002 { | 261 | sub nxt2002 { |
262 | my $sourcefile = "Broadband4PC_4_2_11.zip"; | 262 | my $sourcefile = "Technisat_DVB-PC_4_4_COMPACT.zip"; |
263 | my $url = "http://www.bbti.us/download/windows/$sourcefile"; | 263 | my $url = "http://www.bbti.us/download/windows/$sourcefile"; |
264 | my $hash = "c6d2ea47a8f456d887ada0cfb718ff2a"; | 264 | my $hash = "476befae8c7c1bb9648954060b1eec1f"; |
265 | my $outfile = "dvb-fe-nxt2002.fw"; | 265 | my $outfile = "dvb-fe-nxt2002.fw"; |
266 | my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); | 266 | my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); |
267 | 267 | ||
@@ -269,8 +269,8 @@ sub nxt2002 { | |||
269 | 269 | ||
270 | wgetfile($sourcefile, $url); | 270 | wgetfile($sourcefile, $url); |
271 | unzip($sourcefile, $tmpdir); | 271 | unzip($sourcefile, $tmpdir); |
272 | verify("$tmpdir/SkyNETU.sys", $hash); | 272 | verify("$tmpdir/SkyNET.sys", $hash); |
273 | extract("$tmpdir/SkyNETU.sys", 375832, 5908, $outfile); | 273 | extract("$tmpdir/SkyNET.sys", 331624, 5908, $outfile); |
274 | 274 | ||
275 | $outfile; | 275 | $outfile; |
276 | } | 276 | } |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 293fed113dff..43ab119963d5 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -25,8 +25,9 @@ Who: Adrian Bunk <bunk@stusta.de> | |||
25 | 25 | ||
26 | --------------------------- | 26 | --------------------------- |
27 | 27 | ||
28 | What: drivers depending on OBSOLETE_OSS_DRIVER | 28 | What: drivers that were depending on OBSOLETE_OSS_DRIVER |
29 | When: January 2006 | 29 | (config options already removed) |
30 | When: before 2.6.19 | ||
30 | Why: OSS drivers with ALSA replacements | 31 | Why: OSS drivers with ALSA replacements |
31 | Who: Adrian Bunk <bunk@stusta.de> | 32 | Who: Adrian Bunk <bunk@stusta.de> |
32 | 33 | ||
@@ -56,6 +57,15 @@ Who: Jody McIntyre <scjody@steamballoon.com> | |||
56 | 57 | ||
57 | --------------------------- | 58 | --------------------------- |
58 | 59 | ||
60 | What: sbp2: module parameter "force_inquiry_hack" | ||
61 | When: July 2006 | ||
62 | Why: Superceded by parameter "workarounds". Both parameters are meant to be | ||
63 | used ad-hoc and for single devices only, i.e. not in modprobe.conf, | ||
64 | therefore the impact of this feature replacement should be low. | ||
65 | Who: Stefan Richter <stefanr@s5r6.in-berlin.de> | ||
66 | |||
67 | --------------------------- | ||
68 | |||
59 | What: Video4Linux API 1 ioctls and video_decoder.h from Video devices. | 69 | What: Video4Linux API 1 ioctls and video_decoder.h from Video devices. |
60 | When: July 2006 | 70 | When: July 2006 |
61 | Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6 | 71 | Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6 |
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index c8bce82ddcac..89b1d196ca80 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt | |||
@@ -246,6 +246,7 @@ class/ | |||
246 | devices/ | 246 | devices/ |
247 | firmware/ | 247 | firmware/ |
248 | net/ | 248 | net/ |
249 | fs/ | ||
249 | 250 | ||
250 | devices/ contains a filesystem representation of the device tree. It maps | 251 | devices/ contains a filesystem representation of the device tree. It maps |
251 | directly to the internal kernel device tree, which is a hierarchy of | 252 | directly to the internal kernel device tree, which is a hierarchy of |
@@ -264,6 +265,10 @@ drivers/ contains a directory for each device driver that is loaded | |||
264 | for devices on that particular bus (this assumes that drivers do not | 265 | for devices on that particular bus (this assumes that drivers do not |
265 | span multiple bus types). | 266 | span multiple bus types). |
266 | 267 | ||
268 | fs/ contains a directory for some filesystems. Currently each | ||
269 | filesystem wanting to export attributes must create its own hierarchy | ||
270 | below fs/ (see ./fuse.txt for an example). | ||
271 | |||
267 | 272 | ||
268 | More information can driver-model specific features can be found in | 273 | More information can driver-model specific features can be found in |
269 | Documentation/driver-model/. | 274 | Documentation/driver-model/. |
diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README index 43e836c07ae8..e9cc8bb26f7d 100644 --- a/Documentation/firmware_class/README +++ b/Documentation/firmware_class/README | |||
@@ -105,20 +105,3 @@ | |||
105 | on the setup, so I think that the choice on what firmware to make | 105 | on the setup, so I think that the choice on what firmware to make |
106 | persistent should be left to userspace. | 106 | persistent should be left to userspace. |
107 | 107 | ||
108 | - Why register_firmware()+__init can be useful: | ||
109 | - For boot devices needing firmware. | ||
110 | - To make the transition easier: | ||
111 | The firmware can be declared __init and register_firmware() | ||
112 | called on module_init. Then the firmware is warranted to be | ||
113 | there even if "firmware hotplug userspace" is not there yet or | ||
114 | it doesn't yet provide the needed firmware. | ||
115 | Once the firmware is widely available in userspace, it can be | ||
116 | removed from the kernel. Or made optional (CONFIG_.*_FIRMWARE). | ||
117 | |||
118 | In either case, if firmware hotplug support is there, it can move the | ||
119 | firmware out of kernel memory into the real filesystem for later | ||
120 | usage. | ||
121 | |||
122 | Note: If persistence is implemented on top of initramfs, | ||
123 | register_firmware() may not be appropriate. | ||
124 | |||
diff --git a/Documentation/firmware_class/firmware_sample_driver.c b/Documentation/firmware_class/firmware_sample_driver.c index ad3edaba4533..87feccdb5c9f 100644 --- a/Documentation/firmware_class/firmware_sample_driver.c +++ b/Documentation/firmware_class/firmware_sample_driver.c | |||
@@ -5,8 +5,6 @@ | |||
5 | * | 5 | * |
6 | * Sample code on how to use request_firmware() from drivers. | 6 | * Sample code on how to use request_firmware() from drivers. |
7 | * | 7 | * |
8 | * Note that register_firmware() is currently useless. | ||
9 | * | ||
10 | */ | 8 | */ |
11 | 9 | ||
12 | #include <linux/module.h> | 10 | #include <linux/module.h> |
@@ -17,11 +15,6 @@ | |||
17 | 15 | ||
18 | #include "linux/firmware.h" | 16 | #include "linux/firmware.h" |
19 | 17 | ||
20 | #define WE_CAN_NEED_FIRMWARE_BEFORE_USERSPACE_IS_AVAILABLE | ||
21 | #ifdef WE_CAN_NEED_FIRMWARE_BEFORE_USERSPACE_IS_AVAILABLE | ||
22 | char __init inkernel_firmware[] = "let's say that this is firmware\n"; | ||
23 | #endif | ||
24 | |||
25 | static struct device ghost_device = { | 18 | static struct device ghost_device = { |
26 | .bus_id = "ghost0", | 19 | .bus_id = "ghost0", |
27 | }; | 20 | }; |
@@ -104,10 +97,6 @@ static void sample_probe_async(void) | |||
104 | 97 | ||
105 | static int sample_init(void) | 98 | static int sample_init(void) |
106 | { | 99 | { |
107 | #ifdef WE_CAN_NEED_FIRMWARE_BEFORE_USERSPACE_IS_AVAILABLE | ||
108 | register_firmware("sample_driver_fw", inkernel_firmware, | ||
109 | sizeof(inkernel_firmware)); | ||
110 | #endif | ||
111 | device_initialize(&ghost_device); | 100 | device_initialize(&ghost_device); |
112 | /* since there is no real hardware insertion I just call the | 101 | /* since there is no real hardware insertion I just call the |
113 | * sample probe functions here */ | 102 | * sample probe functions here */ |
diff --git a/Documentation/i2c/busses/i2c-parport b/Documentation/i2c/busses/i2c-parport index d9f23c0763f1..77b995dfca22 100644 --- a/Documentation/i2c/busses/i2c-parport +++ b/Documentation/i2c/busses/i2c-parport | |||
@@ -12,18 +12,22 @@ meant as a replacement for the older, individual drivers: | |||
12 | teletext adapters) | 12 | teletext adapters) |
13 | 13 | ||
14 | It currently supports the following devices: | 14 | It currently supports the following devices: |
15 | * Philips adapter | 15 | * (type=0) Philips adapter |
16 | * home brew teletext adapter | 16 | * (type=1) home brew teletext adapter |
17 | * Velleman K8000 adapter | 17 | * (type=2) Velleman K8000 adapter |
18 | * ELV adapter | 18 | * (type=3) ELV adapter |
19 | * Analog Devices evaluation boards (ADM1025, ADM1030, ADM1031, ADM1032) | 19 | * (type=4) Analog Devices ADM1032 evaluation board |
20 | * Barco LPT->DVI (K5800236) adapter | 20 | * (type=5) Analog Devices evaluation boards: ADM1025, ADM1030, ADM1031 |
21 | * (type=6) Barco LPT->DVI (K5800236) adapter | ||
21 | 22 | ||
22 | These devices use different pinout configurations, so you have to tell | 23 | These devices use different pinout configurations, so you have to tell |
23 | the driver what you have, using the type module parameter. There is no | 24 | the driver what you have, using the type module parameter. There is no |
24 | way to autodetect the devices. Support for different pinout configurations | 25 | way to autodetect the devices. Support for different pinout configurations |
25 | can be easily added when needed. | 26 | can be easily added when needed. |
26 | 27 | ||
28 | Earlier kernels defaulted to type=0 (Philips). But now, if the type | ||
29 | parameter is missing, the driver will simply fail to initialize. | ||
30 | |||
27 | 31 | ||
28 | Building your own adapter | 32 | Building your own adapter |
29 | ------------------------- | 33 | ------------------------- |
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 92f0056d928c..c61d8b876fdb 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt | |||
@@ -1031,7 +1031,7 @@ conflict on any particular lock. | |||
1031 | LOCKS VS MEMORY ACCESSES | 1031 | LOCKS VS MEMORY ACCESSES |
1032 | ------------------------ | 1032 | ------------------------ |
1033 | 1033 | ||
1034 | Consider the following: the system has a pair of spinlocks (N) and (Q), and | 1034 | Consider the following: the system has a pair of spinlocks (M) and (Q), and |
1035 | three CPUs; then should the following sequence of events occur: | 1035 | three CPUs; then should the following sequence of events occur: |
1036 | 1036 | ||
1037 | CPU 1 CPU 2 | 1037 | CPU 1 CPU 2 |
@@ -1678,7 +1678,7 @@ CPU's caches by some other cache event: | |||
1678 | smp_wmb(); | 1678 | smp_wmb(); |
1679 | <A:modify v=2> <C:busy> | 1679 | <A:modify v=2> <C:busy> |
1680 | <C:queue v=2> | 1680 | <C:queue v=2> |
1681 | p = &b; q = p; | 1681 | p = &v; q = p; |
1682 | <D:request p> | 1682 | <D:request p> |
1683 | <B:modify p=&v> <D:commit p=&v> | 1683 | <B:modify p=&v> <D:commit p=&v> |
1684 | <D:read p> | 1684 | <D:read p> |
diff --git a/Documentation/networking/operstates.txt b/Documentation/networking/operstates.txt new file mode 100644 index 000000000000..4a21d9bb836b --- /dev/null +++ b/Documentation/networking/operstates.txt | |||
@@ -0,0 +1,161 @@ | |||
1 | |||
2 | 1. Introduction | ||
3 | |||
4 | Linux distinguishes between administrative and operational state of an | ||
5 | interface. Admininstrative state is the result of "ip link set dev | ||
6 | <dev> up or down" and reflects whether the administrator wants to use | ||
7 | the device for traffic. | ||
8 | |||
9 | However, an interface is not usable just because the admin enabled it | ||
10 | - ethernet requires to be plugged into the switch and, depending on | ||
11 | a site's networking policy and configuration, an 802.1X authentication | ||
12 | to be performed before user data can be transferred. Operational state | ||
13 | shows the ability of an interface to transmit this user data. | ||
14 | |||
15 | Thanks to 802.1X, userspace must be granted the possibility to | ||
16 | influence operational state. To accommodate this, operational state is | ||
17 | split into two parts: Two flags that can be set by the driver only, and | ||
18 | a RFC2863 compatible state that is derived from these flags, a policy, | ||
19 | and changeable from userspace under certain rules. | ||
20 | |||
21 | |||
22 | 2. Querying from userspace | ||
23 | |||
24 | Both admin and operational state can be queried via the netlink | ||
25 | operation RTM_GETLINK. It is also possible to subscribe to RTMGRP_LINK | ||
26 | to be notified of updates. This is important for setting from userspace. | ||
27 | |||
28 | These values contain interface state: | ||
29 | |||
30 | ifinfomsg::if_flags & IFF_UP: | ||
31 | Interface is admin up | ||
32 | ifinfomsg::if_flags & IFF_RUNNING: | ||
33 | Interface is in RFC2863 operational state UP or UNKNOWN. This is for | ||
34 | backward compatibility, routing daemons, dhcp clients can use this | ||
35 | flag to determine whether they should use the interface. | ||
36 | ifinfomsg::if_flags & IFF_LOWER_UP: | ||
37 | Driver has signaled netif_carrier_on() | ||
38 | ifinfomsg::if_flags & IFF_DORMANT: | ||
39 | Driver has signaled netif_dormant_on() | ||
40 | |||
41 | These interface flags can also be queried without netlink using the | ||
42 | SIOCGIFFLAGS ioctl. | ||
43 | |||
44 | TLV IFLA_OPERSTATE | ||
45 | |||
46 | contains RFC2863 state of the interface in numeric representation: | ||
47 | |||
48 | IF_OPER_UNKNOWN (0): | ||
49 | Interface is in unknown state, neither driver nor userspace has set | ||
50 | operational state. Interface must be considered for user data as | ||
51 | setting operational state has not been implemented in every driver. | ||
52 | IF_OPER_NOTPRESENT (1): | ||
53 | Unused in current kernel (notpresent interfaces normally disappear), | ||
54 | just a numerical placeholder. | ||
55 | IF_OPER_DOWN (2): | ||
56 | Interface is unable to transfer data on L1, f.e. ethernet is not | ||
57 | plugged or interface is ADMIN down. | ||
58 | IF_OPER_LOWERLAYERDOWN (3): | ||
59 | Interfaces stacked on an interface that is IF_OPER_DOWN show this | ||
60 | state (f.e. VLAN). | ||
61 | IF_OPER_TESTING (4): | ||
62 | Unused in current kernel. | ||
63 | IF_OPER_DORMANT (5): | ||
64 | Interface is L1 up, but waiting for an external event, f.e. for a | ||
65 | protocol to establish. (802.1X) | ||
66 | IF_OPER_UP (6): | ||
67 | Interface is operational up and can be used. | ||
68 | |||
69 | This TLV can also be queried via sysfs. | ||
70 | |||
71 | TLV IFLA_LINKMODE | ||
72 | |||
73 | contains link policy. This is needed for userspace interaction | ||
74 | described below. | ||
75 | |||
76 | This TLV can also be queried via sysfs. | ||
77 | |||
78 | |||
79 | 3. Kernel driver API | ||
80 | |||
81 | Kernel drivers have access to two flags that map to IFF_LOWER_UP and | ||
82 | IFF_DORMANT. These flags can be set from everywhere, even from | ||
83 | interrupts. It is guaranteed that only the driver has write access, | ||
84 | however, if different layers of the driver manipulate the same flag, | ||
85 | the driver has to provide the synchronisation needed. | ||
86 | |||
87 | __LINK_STATE_NOCARRIER, maps to !IFF_LOWER_UP: | ||
88 | |||
89 | The driver uses netif_carrier_on() to clear and netif_carrier_off() to | ||
90 | set this flag. On netif_carrier_off(), the scheduler stops sending | ||
91 | packets. The name 'carrier' and the inversion are historical, think of | ||
92 | it as lower layer. | ||
93 | |||
94 | netif_carrier_ok() can be used to query that bit. | ||
95 | |||
96 | __LINK_STATE_DORMANT, maps to IFF_DORMANT: | ||
97 | |||
98 | Set by the driver to express that the device cannot yet be used | ||
99 | because some driver controlled protocol establishment has to | ||
100 | complete. Corresponding functions are netif_dormant_on() to set the | ||
101 | flag, netif_dormant_off() to clear it and netif_dormant() to query. | ||
102 | |||
103 | On device allocation, networking core sets the flags equivalent to | ||
104 | netif_carrier_ok() and !netif_dormant(). | ||
105 | |||
106 | |||
107 | Whenever the driver CHANGES one of these flags, a workqueue event is | ||
108 | scheduled to translate the flag combination to IFLA_OPERSTATE as | ||
109 | follows: | ||
110 | |||
111 | !netif_carrier_ok(): | ||
112 | IF_OPER_LOWERLAYERDOWN if the interface is stacked, IF_OPER_DOWN | ||
113 | otherwise. Kernel can recognise stacked interfaces because their | ||
114 | ifindex != iflink. | ||
115 | |||
116 | netif_carrier_ok() && netif_dormant(): | ||
117 | IF_OPER_DORMANT | ||
118 | |||
119 | netif_carrier_ok() && !netif_dormant(): | ||
120 | IF_OPER_UP if userspace interaction is disabled. Otherwise | ||
121 | IF_OPER_DORMANT with the possibility for userspace to initiate the | ||
122 | IF_OPER_UP transition afterwards. | ||
123 | |||
124 | |||
125 | 4. Setting from userspace | ||
126 | |||
127 | Applications have to use the netlink interface to influence the | ||
128 | RFC2863 operational state of an interface. Setting IFLA_LINKMODE to 1 | ||
129 | via RTM_SETLINK instructs the kernel that an interface should go to | ||
130 | IF_OPER_DORMANT instead of IF_OPER_UP when the combination | ||
131 | netif_carrier_ok() && !netif_dormant() is set by the | ||
132 | driver. Afterwards, the userspace application can set IFLA_OPERSTATE | ||
133 | to IF_OPER_DORMANT or IF_OPER_UP as long as the driver does not set | ||
134 | netif_carrier_off() or netif_dormant_on(). Changes made by userspace | ||
135 | are multicasted on the netlink group RTMGRP_LINK. | ||
136 | |||
137 | So basically a 802.1X supplicant interacts with the kernel like this: | ||
138 | |||
139 | -subscribe to RTMGRP_LINK | ||
140 | -set IFLA_LINKMODE to 1 via RTM_SETLINK | ||
141 | -query RTM_GETLINK once to get initial state | ||
142 | -if initial flags are not (IFF_LOWER_UP && !IFF_DORMANT), wait until | ||
143 | netlink multicast signals this state | ||
144 | -do 802.1X, eventually abort if flags go down again | ||
145 | -send RTM_SETLINK to set operstate to IF_OPER_UP if authentication | ||
146 | succeeds, IF_OPER_DORMANT otherwise | ||
147 | -see how operstate and IFF_RUNNING is echoed via netlink multicast | ||
148 | -set interface back to IF_OPER_DORMANT if 802.1X reauthentication | ||
149 | fails | ||
150 | -restart if kernel changes IFF_LOWER_UP or IFF_DORMANT flag | ||
151 | |||
152 | if supplicant goes down, bring back IFLA_LINKMODE to 0 and | ||
153 | IFLA_OPERSTATE to a sane value. | ||
154 | |||
155 | A routing daemon or dhcp client just needs to care for IFF_RUNNING or | ||
156 | waiting for operstate to go IF_OPER_UP/IF_OPER_UNKNOWN before | ||
157 | considering the interface / querying a DHCP address. | ||
158 | |||
159 | |||
160 | For technical questions and/or comments please e-mail to Stefan Rompf | ||
161 | (stefan at loplof.de). | ||
diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt new file mode 100644 index 000000000000..8be626f7c0b8 --- /dev/null +++ b/Documentation/networking/xfrm_sync.txt | |||
@@ -0,0 +1,166 @@ | |||
1 | |||
2 | The sync patches work is based on initial patches from | ||
3 | Krisztian <hidden@balabit.hu> and others and additional patches | ||
4 | from Jamal <hadi@cyberus.ca>. | ||
5 | |||
6 | The end goal for syncing is to be able to insert attributes + generate | ||
7 | events so that the an SA can be safely moved from one machine to another | ||
8 | for HA purposes. | ||
9 | The idea is to synchronize the SA so that the takeover machine can do | ||
10 | the processing of the SA as accurate as possible if it has access to it. | ||
11 | |||
12 | We already have the ability to generate SA add/del/upd events. | ||
13 | These patches add ability to sync and have accurate lifetime byte (to | ||
14 | ensure proper decay of SAs) and replay counters to avoid replay attacks | ||
15 | with as minimal loss at failover time. | ||
16 | This way a backup stays as closely uptodate as an active member. | ||
17 | |||
18 | Because the above items change for every packet the SA receives, | ||
19 | it is possible for a lot of the events to be generated. | ||
20 | For this reason, we also add a nagle-like algorithm to restrict | ||
21 | the events. i.e we are going to set thresholds to say "let me | ||
22 | know if the replay sequence threshold is reached or 10 secs have passed" | ||
23 | These thresholds are set system-wide via sysctls or can be updated | ||
24 | per SA. | ||
25 | |||
26 | The identified items that need to be synchronized are: | ||
27 | - the lifetime byte counter | ||
28 | note that: lifetime time limit is not important if you assume the failover | ||
29 | machine is known ahead of time since the decay of the time countdown | ||
30 | is not driven by packet arrival. | ||
31 | - the replay sequence for both inbound and outbound | ||
32 | |||
33 | 1) Message Structure | ||
34 | ---------------------- | ||
35 | |||
36 | nlmsghdr:aevent_id:optional-TLVs. | ||
37 | |||
38 | The netlink message types are: | ||
39 | |||
40 | XFRM_MSG_NEWAE and XFRM_MSG_GETAE. | ||
41 | |||
42 | A XFRM_MSG_GETAE does not have TLVs. | ||
43 | A XFRM_MSG_NEWAE will have at least two TLVs (as is | ||
44 | discussed further below). | ||
45 | |||
46 | aevent_id structure looks like: | ||
47 | |||
48 | struct xfrm_aevent_id { | ||
49 | struct xfrm_usersa_id sa_id; | ||
50 | __u32 flags; | ||
51 | }; | ||
52 | |||
53 | xfrm_usersa_id in this message layout identifies the SA. | ||
54 | |||
55 | flags are used to indicate different things. The possible | ||
56 | flags are: | ||
57 | XFRM_AE_RTHR=1, /* replay threshold*/ | ||
58 | XFRM_AE_RVAL=2, /* replay value */ | ||
59 | XFRM_AE_LVAL=4, /* lifetime value */ | ||
60 | XFRM_AE_ETHR=8, /* expiry timer threshold */ | ||
61 | XFRM_AE_CR=16, /* Event cause is replay update */ | ||
62 | XFRM_AE_CE=32, /* Event cause is timer expiry */ | ||
63 | XFRM_AE_CU=64, /* Event cause is policy update */ | ||
64 | |||
65 | How these flags are used is dependent on the direction of the | ||
66 | message (kernel<->user) as well the cause (config, query or event). | ||
67 | This is described below in the different messages. | ||
68 | |||
69 | The pid will be set appropriately in netlink to recognize direction | ||
70 | (0 to the kernel and pid = processid that created the event | ||
71 | when going from kernel to user space) | ||
72 | |||
73 | A program needs to subscribe to multicast group XFRMNLGRP_AEVENTS | ||
74 | to get notified of these events. | ||
75 | |||
76 | 2) TLVS reflect the different parameters: | ||
77 | ----------------------------------------- | ||
78 | |||
79 | a) byte value (XFRMA_LTIME_VAL) | ||
80 | This TLV carries the running/current counter for byte lifetime since | ||
81 | last event. | ||
82 | |||
83 | b)replay value (XFRMA_REPLAY_VAL) | ||
84 | This TLV carries the running/current counter for replay sequence since | ||
85 | last event. | ||
86 | |||
87 | c)replay threshold (XFRMA_REPLAY_THRESH) | ||
88 | This TLV carries the threshold being used by the kernel to trigger events | ||
89 | when the replay sequence is exceeded. | ||
90 | |||
91 | d) expiry timer (XFRMA_ETIMER_THRESH) | ||
92 | This is a timer value in milliseconds which is used as the nagle | ||
93 | value to rate limit the events. | ||
94 | |||
95 | 3) Default configurations for the parameters: | ||
96 | ---------------------------------------------- | ||
97 | |||
98 | By default these events should be turned off unless there is | ||
99 | at least one listener registered to listen to the multicast | ||
100 | group XFRMNLGRP_AEVENTS. | ||
101 | |||
102 | Programs installing SAs will need to specify the two thresholds, however, | ||
103 | in order to not change existing applications such as racoon | ||
104 | we also provide default threshold values for these different parameters | ||
105 | in case they are not specified. | ||
106 | |||
107 | the two sysctls/proc entries are: | ||
108 | a) /proc/sys/net/core/sysctl_xfrm_aevent_etime | ||
109 | used to provide default values for the XFRMA_ETIMER_THRESH in incremental | ||
110 | units of time of 100ms. The default is 10 (1 second) | ||
111 | |||
112 | b) /proc/sys/net/core/sysctl_xfrm_aevent_rseqth | ||
113 | used to provide default values for XFRMA_REPLAY_THRESH parameter | ||
114 | in incremental packet count. The default is two packets. | ||
115 | |||
116 | 4) Message types | ||
117 | ---------------- | ||
118 | |||
119 | a) XFRM_MSG_GETAE issued by user-->kernel. | ||
120 | XFRM_MSG_GETAE does not carry any TLVs. | ||
121 | The response is a XFRM_MSG_NEWAE which is formatted based on what | ||
122 | XFRM_MSG_GETAE queried for. | ||
123 | The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs. | ||
124 | *if XFRM_AE_RTHR flag is set, then XFRMA_REPLAY_THRESH is also retrieved | ||
125 | *if XFRM_AE_ETHR flag is set, then XFRMA_ETIMER_THRESH is also retrieved | ||
126 | |||
127 | b) XFRM_MSG_NEWAE is issued by either user space to configure | ||
128 | or kernel to announce events or respond to a XFRM_MSG_GETAE. | ||
129 | |||
130 | i) user --> kernel to configure a specific SA. | ||
131 | any of the values or threshold parameters can be updated by passing the | ||
132 | appropriate TLV. | ||
133 | A response is issued back to the sender in user space to indicate success | ||
134 | or failure. | ||
135 | In the case of success, additionally an event with | ||
136 | XFRM_MSG_NEWAE is also issued to any listeners as described in iii). | ||
137 | |||
138 | ii) kernel->user direction as a response to XFRM_MSG_GETAE | ||
139 | The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs. | ||
140 | The threshold TLVs will be included if explicitly requested in | ||
141 | the XFRM_MSG_GETAE message. | ||
142 | |||
143 | iii) kernel->user to report as event if someone sets any values or | ||
144 | thresholds for an SA using XFRM_MSG_NEWAE (as described in #i above). | ||
145 | In such a case XFRM_AE_CU flag is set to inform the user that | ||
146 | the change happened as a result of an update. | ||
147 | The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs. | ||
148 | |||
149 | iv) kernel->user to report event when replay threshold or a timeout | ||
150 | is exceeded. | ||
151 | In such a case either XFRM_AE_CR (replay exceeded) or XFRM_AE_CE (timeout | ||
152 | happened) is set to inform the user what happened. | ||
153 | Note the two flags are mutually exclusive. | ||
154 | The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs. | ||
155 | |||
156 | Exceptions to threshold settings | ||
157 | -------------------------------- | ||
158 | |||
159 | If you have an SA that is getting hit by traffic in bursts such that | ||
160 | there is a period where the timer threshold expires with no packets | ||
161 | seen, then an odd behavior is seen as follows: | ||
162 | The first packet arrival after a timer expiry will trigger a timeout | ||
163 | aevent; i.e we dont wait for a timeout period or a packet threshold | ||
164 | to be reached. This is done for simplicity and efficiency reasons. | ||
165 | |||
166 | -JHS | ||
diff --git a/Documentation/pci.txt b/Documentation/pci.txt index 711210b38f5f..66bbbf1d1ef6 100644 --- a/Documentation/pci.txt +++ b/Documentation/pci.txt | |||
@@ -259,7 +259,17 @@ on the bus need to be capable of doing it, so this is something which needs | |||
259 | to be handled by platform and generic code, not individual drivers. | 259 | to be handled by platform and generic code, not individual drivers. |
260 | 260 | ||
261 | 261 | ||
262 | 8. Obsolete functions | 262 | 8. Vendor and device identifications |
263 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
264 | For the future, let's avoid adding device ids to include/linux/pci_ids.h. | ||
265 | |||
266 | PCI_VENDOR_ID_xxx for vendors, and a hex constant for device ids. | ||
267 | |||
268 | Rationale: PCI_VENDOR_ID_xxx constants are re-used, but device ids are not. | ||
269 | Further, device ids are arbitrary hex numbers, normally used only in a | ||
270 | single location, the pci_device_id table. | ||
271 | |||
272 | 9. Obsolete functions | ||
263 | ~~~~~~~~~~~~~~~~~~~~~ | 273 | ~~~~~~~~~~~~~~~~~~~~~ |
264 | There are several functions which you might come across when trying to | 274 | There are several functions which you might come across when trying to |
265 | port an old driver to the new PCI interface. They are no longer present | 275 | port an old driver to the new PCI interface. They are no longer present |
diff --git a/Documentation/power/video.txt b/Documentation/power/video.txt index d18a57d1a531..43a889f8f08d 100644 --- a/Documentation/power/video.txt +++ b/Documentation/power/video.txt | |||
@@ -140,7 +140,7 @@ IBM TP T41p s3_bios (2), switch to X after resume | |||
140 | IBM TP T42 s3_bios (2) | 140 | IBM TP T42 s3_bios (2) |
141 | IBM ThinkPad T42p (2373-GTG) s3_bios (2) | 141 | IBM ThinkPad T42p (2373-GTG) s3_bios (2) |
142 | IBM TP X20 ??? (*) | 142 | IBM TP X20 ??? (*) |
143 | IBM TP X30 s3_bios (2) | 143 | IBM TP X30 s3_bios, s3_mode (4) |
144 | IBM TP X31 / Type 2672-XXH none (1), use radeontool (http://fdd.com/software/radeon/) to turn off backlight. | 144 | IBM TP X31 / Type 2672-XXH none (1), use radeontool (http://fdd.com/software/radeon/) to turn off backlight. |
145 | IBM TP X32 none (1), but backlight is on and video is trashed after long suspend. s3_bios,s3_mode (4) works too. Perhaps that gets better results? | 145 | IBM TP X32 none (1), but backlight is on and video is trashed after long suspend. s3_bios,s3_mode (4) works too. Perhaps that gets better results? |
146 | IBM Thinkpad X40 Type 2371-7JG s3_bios,s3_mode (4) | 146 | IBM Thinkpad X40 Type 2371-7JG s3_bios,s3_mode (4) |
diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid index 09f6300eda4b..c173806c91fa 100644 --- a/Documentation/scsi/ChangeLog.megaraid +++ b/Documentation/scsi/ChangeLog.megaraid | |||
@@ -1,3 +1,28 @@ | |||
1 | Release Date : Mon Apr 11 12:27:22 EST 2006 - Seokmann Ju <sju@lsil.com> | ||
2 | Current Version : 2.20.4.8 (scsi module), 2.20.2.6 (cmm module) | ||
3 | Older Version : 2.20.4.7 (scsi module), 2.20.2.6 (cmm module) | ||
4 | |||
5 | 1. Fixed a bug in megaraid_reset_handler(). | ||
6 | Customer reported "Unable to handle kernel NULL pointer dereference | ||
7 | at virtual address 00000000" when system goes to reset condition | ||
8 | for some reason. It happened randomly. | ||
9 | Root Cause: in the megaraid_reset_handler(), there is possibility not | ||
10 | returning pending packets in the pend_list if there are multiple | ||
11 | pending packets. | ||
12 | Fix: Made the change in the driver so that it will return all packets | ||
13 | in the pend_list. | ||
14 | |||
15 | 2. Added change request. | ||
16 | As found in the following URL, rmb() only didn't help the | ||
17 | problem. I had to increase the loop counter to 0xFFFFFF. (6 F's) | ||
18 | http://marc.theaimsgroup.com/?l=linux-scsi&m=110971060502497&w=2 | ||
19 | |||
20 | I attached a patch for your reference, too. | ||
21 | Could you check and get this fix in your driver? | ||
22 | |||
23 | Best Regards, | ||
24 | Jun'ichi Nomura | ||
25 | |||
1 | Release Date : Fri Nov 11 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com> | 26 | Release Date : Fri Nov 11 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com> |
2 | Current Version : 2.20.4.7 (scsi module), 2.20.2.6 (cmm module) | 27 | Current Version : 2.20.4.7 (scsi module), 2.20.2.6 (cmm module) |
3 | Older Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module) | 28 | Older Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module) |
diff --git a/Documentation/serial/driver b/Documentation/serial/driver index 42ef9970bc86..88ad615dd338 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver | |||
@@ -3,14 +3,11 @@ | |||
3 | -------------------- | 3 | -------------------- |
4 | 4 | ||
5 | 5 | ||
6 | $Id: driver,v 1.10 2002/07/22 15:27:30 rmk Exp $ | ||
7 | |||
8 | |||
9 | This document is meant as a brief overview of some aspects of the new serial | 6 | This document is meant as a brief overview of some aspects of the new serial |
10 | driver. It is not complete, any questions you have should be directed to | 7 | driver. It is not complete, any questions you have should be directed to |
11 | <rmk@arm.linux.org.uk> | 8 | <rmk@arm.linux.org.uk> |
12 | 9 | ||
13 | The reference implementation is contained within serial_amba.c. | 10 | The reference implementation is contained within amba_pl011.c. |
14 | 11 | ||
15 | 12 | ||
16 | 13 | ||
@@ -31,6 +28,11 @@ The serial core provides a few helper functions. This includes identifing | |||
31 | the correct port structure (via uart_get_console) and decoding command line | 28 | the correct port structure (via uart_get_console) and decoding command line |
32 | arguments (uart_parse_options). | 29 | arguments (uart_parse_options). |
33 | 30 | ||
31 | There is also a helper function (uart_write_console) which performs a | ||
32 | character by character write, translating newlines to CRLF sequences. | ||
33 | Driver writers are recommended to use this function rather than implementing | ||
34 | their own version. | ||
35 | |||
34 | 36 | ||
35 | Locking | 37 | Locking |
36 | ------- | 38 | ------- |
@@ -86,6 +88,7 @@ hardware. | |||
86 | - TIOCM_DTR DTR signal. | 88 | - TIOCM_DTR DTR signal. |
87 | - TIOCM_OUT1 OUT1 signal. | 89 | - TIOCM_OUT1 OUT1 signal. |
88 | - TIOCM_OUT2 OUT2 signal. | 90 | - TIOCM_OUT2 OUT2 signal. |
91 | - TIOCM_LOOP Set the port into loopback mode. | ||
89 | If the appropriate bit is set, the signal should be driven | 92 | If the appropriate bit is set, the signal should be driven |
90 | active. If the bit is clear, the signal should be driven | 93 | active. If the bit is clear, the signal should be driven |
91 | inactive. | 94 | inactive. |
@@ -141,6 +144,10 @@ hardware. | |||
141 | enable_ms(port) | 144 | enable_ms(port) |
142 | Enable the modem status interrupts. | 145 | Enable the modem status interrupts. |
143 | 146 | ||
147 | This method may be called multiple times. Modem status | ||
148 | interrupts should be disabled when the shutdown method is | ||
149 | called. | ||
150 | |||
144 | Locking: port->lock taken. | 151 | Locking: port->lock taken. |
145 | Interrupts: locally disabled. | 152 | Interrupts: locally disabled. |
146 | This call must not sleep | 153 | This call must not sleep |
@@ -160,6 +167,8 @@ hardware. | |||
160 | state. Enable the port for reception. It should not activate | 167 | state. Enable the port for reception. It should not activate |
161 | RTS nor DTR; this will be done via a separate call to set_mctrl. | 168 | RTS nor DTR; this will be done via a separate call to set_mctrl. |
162 | 169 | ||
170 | This method will only be called when the port is initially opened. | ||
171 | |||
163 | Locking: port_sem taken. | 172 | Locking: port_sem taken. |
164 | Interrupts: globally disabled. | 173 | Interrupts: globally disabled. |
165 | 174 | ||
@@ -169,6 +178,11 @@ hardware. | |||
169 | RTS nor DTR; this will have already been done via a separate | 178 | RTS nor DTR; this will have already been done via a separate |
170 | call to set_mctrl. | 179 | call to set_mctrl. |
171 | 180 | ||
181 | Drivers must not access port->info once this call has completed. | ||
182 | |||
183 | This method will only be called when there are no more users of | ||
184 | this port. | ||
185 | |||
172 | Locking: port_sem taken. | 186 | Locking: port_sem taken. |
173 | Interrupts: caller dependent. | 187 | Interrupts: caller dependent. |
174 | 188 | ||
@@ -200,12 +214,13 @@ hardware. | |||
200 | The interaction of the iflag bits is as follows (parity error | 214 | The interaction of the iflag bits is as follows (parity error |
201 | given as an example): | 215 | given as an example): |
202 | Parity error INPCK IGNPAR | 216 | Parity error INPCK IGNPAR |
203 | None n/a n/a character received | 217 | n/a 0 n/a character received, marked as |
204 | Yes n/a 0 character discarded | 218 | TTY_NORMAL |
205 | Yes 0 1 character received, marked as | 219 | None 1 n/a character received, marked as |
206 | TTY_NORMAL | 220 | TTY_NORMAL |
207 | Yes 1 1 character received, marked as | 221 | Yes 1 0 character received, marked as |
208 | TTY_PARITY | 222 | TTY_PARITY |
223 | Yes 1 1 character discarded | ||
209 | 224 | ||
210 | Other flags may be used (eg, xon/xoff characters) if your | 225 | Other flags may be used (eg, xon/xoff characters) if your |
211 | hardware supports hardware "soft" flow control. | 226 | hardware supports hardware "soft" flow control. |
diff --git a/Documentation/sound/alsa/Audiophile-Usb.txt b/Documentation/sound/alsa/Audiophile-Usb.txt index 4692c8e77dc1..b535c2a198f8 100644 --- a/Documentation/sound/alsa/Audiophile-Usb.txt +++ b/Documentation/sound/alsa/Audiophile-Usb.txt | |||
@@ -1,4 +1,4 @@ | |||
1 | Guide to using M-Audio Audiophile USB with ALSA and Jack v1.2 | 1 | Guide to using M-Audio Audiophile USB with ALSA and Jack v1.3 |
2 | ======================================================== | 2 | ======================================================== |
3 | 3 | ||
4 | Thibault Le Meur <Thibault.LeMeur@supelec.fr> | 4 | Thibault Le Meur <Thibault.LeMeur@supelec.fr> |
@@ -22,16 +22,16 @@ The device has 4 audio interfaces, and 2 MIDI ports: | |||
22 | * Midi In (Mi) | 22 | * Midi In (Mi) |
23 | * Midi Out (Mo) | 23 | * Midi Out (Mo) |
24 | 24 | ||
25 | The internal DAC/ADC has the following caracteristics: | 25 | The internal DAC/ADC has the following characteristics: |
26 | * sample depth of 16 or 24 bits | 26 | * sample depth of 16 or 24 bits |
27 | * sample rate from 8kHz to 96kHz | 27 | * sample rate from 8kHz to 96kHz |
28 | * Two ports can't use different sample depths at the same time.Moreover, the | 28 | * Two ports can't use different sample depths at the same time. Moreover, the |
29 | Audiophile USB documentation gives the following Warning: "Please exit any | 29 | Audiophile USB documentation gives the following Warning: "Please exit any |
30 | audio application running before switching between bit depths" | 30 | audio application running before switching between bit depths" |
31 | 31 | ||
32 | Due to the USB 1.1 bandwidth limitation, a limited number of interfaces can be | 32 | Due to the USB 1.1 bandwidth limitation, a limited number of interfaces can be |
33 | activated at the same time depending on the audio mode selected: | 33 | activated at the same time depending on the audio mode selected: |
34 | * 16-bit/48kHz ==> 4 channels in/ 4 channels out | 34 | * 16-bit/48kHz ==> 4 channels in/4 channels out |
35 | - Ai+Ao+Di+Do | 35 | - Ai+Ao+Di+Do |
36 | * 24-bit/48kHz ==> 4 channels in/2 channels out, | 36 | * 24-bit/48kHz ==> 4 channels in/2 channels out, |
37 | or 2 channels in/4 channels out | 37 | or 2 channels in/4 channels out |
@@ -41,8 +41,8 @@ activated at the same time depending on the audio mode selected: | |||
41 | 41 | ||
42 | Important facts about the Digital interface: | 42 | Important facts about the Digital interface: |
43 | -------------------------------------------- | 43 | -------------------------------------------- |
44 | * The Do port additionnaly supports surround-encoded AC-3 and DTS passthrough, | 44 | * The Do port additionally supports surround-encoded AC-3 and DTS passthrough, |
45 | though I haven't tested it under linux | 45 | though I haven't tested it under Linux |
46 | - Note that in this setup only the Do interface can be enabled | 46 | - Note that in this setup only the Do interface can be enabled |
47 | * Apart from recording an audio digital stream, enabling the Di port is a way | 47 | * Apart from recording an audio digital stream, enabling the Di port is a way |
48 | to synchronize the device to an external sample clock | 48 | to synchronize the device to an external sample clock |
@@ -60,24 +60,23 @@ synchronization error (for instance sound played at an odd sample rate) | |||
60 | The Audiophile USB MIDI ports will be automatically supported once the | 60 | The Audiophile USB MIDI ports will be automatically supported once the |
61 | following modules have been loaded: | 61 | following modules have been loaded: |
62 | * snd-usb-audio | 62 | * snd-usb-audio |
63 | * snd-seq | ||
64 | * snd-seq-midi | 63 | * snd-seq-midi |
65 | 64 | ||
66 | No additionnal setting is required. | 65 | No additional setting is required. |
67 | 66 | ||
68 | 2.2 - Audio ports | 67 | 2.2 - Audio ports |
69 | ----------------- | 68 | ----------------- |
70 | 69 | ||
71 | Audio functions of the Audiophile USB device are handled by the snd-usb-audio | 70 | Audio functions of the Audiophile USB device are handled by the snd-usb-audio |
72 | module. This module can work in a default mode (without any device-specific | 71 | module. This module can work in a default mode (without any device-specific |
73 | parameter), or in an advanced mode with the device-specific parameter called | 72 | parameter), or in an "advanced" mode with the device-specific parameter called |
74 | "device_setup". | 73 | "device_setup". |
75 | 74 | ||
76 | 2.2.1 - Default Alsa driver mode | 75 | 2.2.1 - Default Alsa driver mode |
77 | 76 | ||
78 | The default behaviour of the snd-usb-audio driver is to parse the device | 77 | The default behavior of the snd-usb-audio driver is to parse the device |
79 | capabilities at startup and enable all functions inside the device (including | 78 | capabilities at startup and enable all functions inside the device (including |
80 | all ports at any sample rates and any sample depths supported). This approach | 79 | all ports at any supported sample rates and sample depths). This approach |
81 | has the advantage to let the driver easily switch from sample rates/depths | 80 | has the advantage to let the driver easily switch from sample rates/depths |
82 | automatically according to the need of the application claiming the device. | 81 | automatically according to the need of the application claiming the device. |
83 | 82 | ||
@@ -114,9 +113,9 @@ gain). | |||
114 | For people having this problem, the snd-usb-audio module has a new module | 113 | For people having this problem, the snd-usb-audio module has a new module |
115 | parameter called "device_setup". | 114 | parameter called "device_setup". |
116 | 115 | ||
117 | 2.2.2.1 - Initializing the working mode of the Audiohile USB | 116 | 2.2.2.1 - Initializing the working mode of the Audiophile USB |
118 | 117 | ||
119 | As far as the Audiohile USB device is concerned, this value let the user | 118 | As far as the Audiophile USB device is concerned, this value let the user |
120 | specify: | 119 | specify: |
121 | * the sample depth | 120 | * the sample depth |
122 | * the sample rate | 121 | * the sample rate |
@@ -174,20 +173,20 @@ The parameter can be given: | |||
174 | 173 | ||
175 | IMPORTANT NOTE WHEN SWITCHING CONFIGURATION: | 174 | IMPORTANT NOTE WHEN SWITCHING CONFIGURATION: |
176 | ------------------------------------------- | 175 | ------------------------------------------- |
177 | * You may need to _first_ intialize the module with the correct device_setup | 176 | * You may need to _first_ initialize the module with the correct device_setup |
178 | parameter and _only_after_ turn on the Audiophile USB device | 177 | parameter and _only_after_ turn on the Audiophile USB device |
179 | * This is especially true when switching the sample depth: | 178 | * This is especially true when switching the sample depth: |
180 | - first trun off the device | 179 | - first turn off the device |
181 | - de-register the snd-usb-audio module | 180 | - de-register the snd-usb-audio module (modprobe -r) |
182 | - change the device_setup parameter (by either manually reprobing the module | 181 | - change the device_setup parameter by changing the device_setup |
183 | or changing modprobe.conf) | 182 | option in /etc/modprobe.conf |
184 | - turn on the device | 183 | - turn on the device |
185 | 184 | ||
186 | 2.2.2.3 - Audiophile USB's device_setup structure | 185 | 2.2.2.3 - Audiophile USB's device_setup structure |
187 | 186 | ||
188 | If you want to understand the device_setup magic numbers for the Audiophile | 187 | If you want to understand the device_setup magic numbers for the Audiophile |
189 | USB, you need some very basic understanding of binary computation. However, | 188 | USB, you need some very basic understanding of binary computation. However, |
190 | this is not required to use the parameter and you may skip thi section. | 189 | this is not required to use the parameter and you may skip this section. |
191 | 190 | ||
192 | The device_setup is one byte long and its structure is the following: | 191 | The device_setup is one byte long and its structure is the following: |
193 | 192 | ||
@@ -231,11 +230,11 @@ Caution: | |||
231 | 230 | ||
232 | 2.2.3 - USB implementation details for this device | 231 | 2.2.3 - USB implementation details for this device |
233 | 232 | ||
234 | You may safely skip this section if you're not interrested in driver | 233 | You may safely skip this section if you're not interested in driver |
235 | development. | 234 | development. |
236 | 235 | ||
237 | This section describes some internals aspect of the device and summarize the | 236 | This section describes some internal aspects of the device and summarize the |
238 | data I got by usb-snooping the windows and linux drivers. | 237 | data I got by usb-snooping the windows and Linux drivers. |
239 | 238 | ||
240 | The M-Audio Audiophile USB has 7 USB Interfaces: | 239 | The M-Audio Audiophile USB has 7 USB Interfaces: |
241 | a "USB interface": | 240 | a "USB interface": |
@@ -277,9 +276,9 @@ Here is a short description of the AltSettings capabilities: | |||
277 | - 16-bit depth, 8-48kHz sample mode | 276 | - 16-bit depth, 8-48kHz sample mode |
278 | - Synch playback (Do), audio format type III IEC1937_AC-3 | 277 | - Synch playback (Do), audio format type III IEC1937_AC-3 |
279 | 278 | ||
280 | In order to ensure a correct intialization of the device, the driver | 279 | In order to ensure a correct initialization of the device, the driver |
281 | _must_know_ how the device will be used: | 280 | _must_know_ how the device will be used: |
282 | * if DTS is choosen, only Interface 2 with AltSet nb.6 must be | 281 | * if DTS is chosen, only Interface 2 with AltSet nb.6 must be |
283 | registered | 282 | registered |
284 | * if 96KHz only AltSets nb.1 of each interface must be selected | 283 | * if 96KHz only AltSets nb.1 of each interface must be selected |
285 | * if samples are using 24bits/48KHz then AltSet 2 must me used if | 284 | * if samples are using 24bits/48KHz then AltSet 2 must me used if |
@@ -290,7 +289,7 @@ _must_know_ how the device will be used: | |||
290 | is not connected | 289 | is not connected |
291 | 290 | ||
292 | When device_setup is given as a parameter to the snd-usb-audio module, the | 291 | When device_setup is given as a parameter to the snd-usb-audio module, the |
293 | parse_audio_enpoint function uses a quirk called | 292 | parse_audio_endpoints function uses a quirk called |
294 | "audiophile_skip_setting_quirk" in order to prevent AltSettings not | 293 | "audiophile_skip_setting_quirk" in order to prevent AltSettings not |
295 | corresponding to device_setup from being registered in the driver. | 294 | corresponding to device_setup from being registered in the driver. |
296 | 295 | ||
@@ -317,9 +316,8 @@ However you may see the following warning message: | |||
317 | using the "default" ALSA device. This is less efficient than it could be. | 316 | using the "default" ALSA device. This is less efficient than it could be. |
318 | Consider using a hardware device instead rather than using the plug layer." | 317 | Consider using a hardware device instead rather than using the plug layer." |
319 | 318 | ||
320 | |||
321 | 3.2 - Patching alsa to use direct pcm device | 319 | 3.2 - Patching alsa to use direct pcm device |
322 | ------------------------------------------- | 320 | -------------------------------------------- |
323 | A patch for Jack by Andreas Steinmetz adds support for Big Endian devices. | 321 | A patch for Jack by Andreas Steinmetz adds support for Big Endian devices. |
324 | However it has not been included in the CVS tree. | 322 | However it has not been included in the CVS tree. |
325 | 323 | ||
@@ -331,3 +329,32 @@ After having applied the patch you can run jackd with the following command | |||
331 | line: | 329 | line: |
332 | % jackd -R -dalsa -Phw:1,0 -r48000 -p128 -n2 -D -Chw:1,1 | 330 | % jackd -R -dalsa -Phw:1,0 -r48000 -p128 -n2 -D -Chw:1,1 |
333 | 331 | ||
332 | 3.2 - Getting 2 input and/or output interfaces in Jack | ||
333 | ------------------------------------------------------ | ||
334 | |||
335 | As you can see, starting the Jack server this way will only enable 1 stereo | ||
336 | input (Di or Ai) and 1 stereo output (Ao or Do). | ||
337 | |||
338 | This is due to the following restrictions: | ||
339 | * Jack can only open one capture device and one playback device at a time | ||
340 | * The Audiophile USB is seen as 2 (or three) Alsa devices: hw:1,0, hw:1,1 | ||
341 | (and optionally hw:1,2) | ||
342 | If you want to get Ai+Di and/or Ao+Do support with Jack, you would need to | ||
343 | combine the Alsa devices into one logical "complex" device. | ||
344 | |||
345 | If you want to give it a try, I recommend reading the information from | ||
346 | this page: http://www.sound-man.co.uk/linuxaudio/ice1712multi.html | ||
347 | It is related to another device (ice1712) but can be adapted to suit | ||
348 | the Audiophile USB. | ||
349 | |||
350 | Enabling multiple Audiophile USB interfaces for Jackd will certainly require: | ||
351 | * patching Jack with the previously mentioned "Big Endian" patch | ||
352 | * patching Jackd with the MMAP_COMPLEX patch (see the ice1712 page) | ||
353 | * patching the alsa-lib/src/pcm/pcm_multi.c file (see the ice1712 page) | ||
354 | * define a multi device (combination of hw:1,0 and hw:1,1) in your .asoundrc | ||
355 | file | ||
356 | * start jackd with this device | ||
357 | |||
358 | I had no success in testing this for now, but this may be due to my OS | ||
359 | configuration. If you have any success with this kind of setup, please | ||
360 | drop me an email. | ||
diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl index 68eeebc17ff4..1faf76383bab 100644 --- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl | |||
@@ -1172,7 +1172,7 @@ | |||
1172 | } | 1172 | } |
1173 | 1173 | ||
1174 | /* PCI IDs */ | 1174 | /* PCI IDs */ |
1175 | static struct pci_device_id snd_mychip_ids[] = { | 1175 | static struct pci_device_id snd_mychip_ids[] __devinitdata = { |
1176 | { PCI_VENDOR_ID_FOO, PCI_DEVICE_ID_BAR, | 1176 | { PCI_VENDOR_ID_FOO, PCI_DEVICE_ID_BAR, |
1177 | PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, | 1177 | PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, |
1178 | .... | 1178 | .... |
@@ -1565,7 +1565,7 @@ | |||
1565 | <informalexample> | 1565 | <informalexample> |
1566 | <programlisting> | 1566 | <programlisting> |
1567 | <![CDATA[ | 1567 | <![CDATA[ |
1568 | static struct pci_device_id snd_mychip_ids[] = { | 1568 | static struct pci_device_id snd_mychip_ids[] __devinitdata = { |
1569 | { PCI_VENDOR_ID_FOO, PCI_DEVICE_ID_BAR, | 1569 | { PCI_VENDOR_ID_FOO, PCI_DEVICE_ID_BAR, |
1570 | PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, | 1570 | PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, |
1571 | .... | 1571 | .... |
diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx new file mode 100644 index 000000000000..9c45f3df2e18 --- /dev/null +++ b/Documentation/spi/pxa2xx | |||
@@ -0,0 +1,234 @@ | |||
1 | PXA2xx SPI on SSP driver HOWTO | ||
2 | =================================================== | ||
3 | This a mini howto on the pxa2xx_spi driver. The driver turns a PXA2xx | ||
4 | synchronous serial port into a SPI master controller | ||
5 | (see Documentation/spi/spi_summary). The driver has the following features | ||
6 | |||
7 | - Support for any PXA2xx SSP | ||
8 | - SSP PIO and SSP DMA data transfers. | ||
9 | - External and Internal (SSPFRM) chip selects. | ||
10 | - Per slave device (chip) configuration. | ||
11 | - Full suspend, freeze, resume support. | ||
12 | |||
13 | The driver is built around a "spi_message" fifo serviced by workqueue and a | ||
14 | tasklet. The workqueue, "pump_messages", drives message fifo and the tasklet | ||
15 | (pump_transfer) is responsible for queuing SPI transactions and setting up and | ||
16 | launching the dma/interrupt driven transfers. | ||
17 | |||
18 | Declaring PXA2xx Master Controllers | ||
19 | ----------------------------------- | ||
20 | Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a | ||
21 | "platform device". The master configuration is passed to the driver via a table | ||
22 | found in include/asm-arm/arch-pxa/pxa2xx_spi.h: | ||
23 | |||
24 | struct pxa2xx_spi_master { | ||
25 | enum pxa_ssp_type ssp_type; | ||
26 | u32 clock_enable; | ||
27 | u16 num_chipselect; | ||
28 | u8 enable_dma; | ||
29 | }; | ||
30 | |||
31 | The "pxa2xx_spi_master.ssp_type" field must have a value between 1 and 3 and | ||
32 | informs the driver which features a particular SSP supports. | ||
33 | |||
34 | The "pxa2xx_spi_master.clock_enable" field is used to enable/disable the | ||
35 | corresponding SSP peripheral block in the "Clock Enable Register (CKEN"). See | ||
36 | the "PXA2xx Developer Manual" section "Clocks and Power Management". | ||
37 | |||
38 | The "pxa2xx_spi_master.num_chipselect" field is used to determine the number of | ||
39 | slave device (chips) attached to this SPI master. | ||
40 | |||
41 | The "pxa2xx_spi_master.enable_dma" field informs the driver that SSP DMA should | ||
42 | be used. This caused the driver to acquire two DMA channels: rx_channel and | ||
43 | tx_channel. The rx_channel has a higher DMA service priority the tx_channel. | ||
44 | See the "PXA2xx Developer Manual" section "DMA Controller". | ||
45 | |||
46 | NSSP MASTER SAMPLE | ||
47 | ------------------ | ||
48 | Below is a sample configuration using the PXA255 NSSP. | ||
49 | |||
50 | static struct resource pxa_spi_nssp_resources[] = { | ||
51 | [0] = { | ||
52 | .start = __PREG(SSCR0_P(2)), /* Start address of NSSP */ | ||
53 | .end = __PREG(SSCR0_P(2)) + 0x2c, /* Range of registers */ | ||
54 | .flags = IORESOURCE_MEM, | ||
55 | }, | ||
56 | [1] = { | ||
57 | .start = IRQ_NSSP, /* NSSP IRQ */ | ||
58 | .end = IRQ_NSSP, | ||
59 | .flags = IORESOURCE_IRQ, | ||
60 | }, | ||
61 | }; | ||
62 | |||
63 | static struct pxa2xx_spi_master pxa_nssp_master_info = { | ||
64 | .ssp_type = PXA25x_NSSP, /* Type of SSP */ | ||
65 | .clock_enable = CKEN9_NSSP, /* NSSP Peripheral clock */ | ||
66 | .num_chipselect = 1, /* Matches the number of chips attached to NSSP */ | ||
67 | .enable_dma = 1, /* Enables NSSP DMA */ | ||
68 | }; | ||
69 | |||
70 | static struct platform_device pxa_spi_nssp = { | ||
71 | .name = "pxa2xx-spi", /* MUST BE THIS VALUE, so device match driver */ | ||
72 | .id = 2, /* Bus number, MUST MATCH SSP number 1..n */ | ||
73 | .resource = pxa_spi_nssp_resources, | ||
74 | .num_resources = ARRAY_SIZE(pxa_spi_nssp_resources), | ||
75 | .dev = { | ||
76 | .platform_data = &pxa_nssp_master_info, /* Passed to driver */ | ||
77 | }, | ||
78 | }; | ||
79 | |||
80 | static struct platform_device *devices[] __initdata = { | ||
81 | &pxa_spi_nssp, | ||
82 | }; | ||
83 | |||
84 | static void __init board_init(void) | ||
85 | { | ||
86 | (void)platform_add_device(devices, ARRAY_SIZE(devices)); | ||
87 | } | ||
88 | |||
89 | Declaring Slave Devices | ||
90 | ----------------------- | ||
91 | Typically each SPI slave (chip) is defined in the arch/.../mach-*/board-*.c | ||
92 | using the "spi_board_info" structure found in "linux/spi/spi.h". See | ||
93 | "Documentation/spi/spi_summary" for additional information. | ||
94 | |||
95 | Each slave device attached to the PXA must provide slave specific configuration | ||
96 | information via the structure "pxa2xx_spi_chip" found in | ||
97 | "include/asm-arm/arch-pxa/pxa2xx_spi.h". The pxa2xx_spi master controller driver | ||
98 | will uses the configuration whenever the driver communicates with the slave | ||
99 | device. | ||
100 | |||
101 | struct pxa2xx_spi_chip { | ||
102 | u8 tx_threshold; | ||
103 | u8 rx_threshold; | ||
104 | u8 dma_burst_size; | ||
105 | u32 timeout_microsecs; | ||
106 | u8 enable_loopback; | ||
107 | void (*cs_control)(u32 command); | ||
108 | }; | ||
109 | |||
110 | The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are | ||
111 | used to configure the SSP hardware fifo. These fields are critical to the | ||
112 | performance of pxa2xx_spi driver and misconfiguration will result in rx | ||
113 | fifo overruns (especially in PIO mode transfers). Good default values are | ||
114 | |||
115 | .tx_threshold = 12, | ||
116 | .rx_threshold = 4, | ||
117 | |||
118 | The "pxa2xx_spi_chip.dma_burst_size" field is used to configure PXA2xx DMA | ||
119 | engine and is related the "spi_device.bits_per_word" field. Read and understand | ||
120 | the PXA2xx "Developer Manual" sections on the DMA controller and SSP Controllers | ||
121 | to determine the correct value. An SSP configured for byte-wide transfers would | ||
122 | use a value of 8. | ||
123 | |||
124 | The "pxa2xx_spi_chip.timeout_microsecs" fields is used to efficiently handle | ||
125 | trailing bytes in the SSP receiver fifo. The correct value for this field is | ||
126 | dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific | ||
127 | slave device. Please note the the PXA2xx SSP 1 does not support trailing byte | ||
128 | timeouts and must busy-wait any trailing bytes. | ||
129 | |||
130 | The "pxa2xx_spi_chip.enable_loopback" field is used to place the SSP porting | ||
131 | into internal loopback mode. In this mode the SSP controller internally | ||
132 | connects the SSPTX pin the the SSPRX pin. This is useful for initial setup | ||
133 | testing. | ||
134 | |||
135 | The "pxa2xx_spi_chip.cs_control" field is used to point to a board specific | ||
136 | function for asserting/deasserting a slave device chip select. If the field is | ||
137 | NULL, the pxa2xx_spi master controller driver assumes that the SSP port is | ||
138 | configured to use SSPFRM instead. | ||
139 | |||
140 | NSSP SALVE SAMPLE | ||
141 | ----------------- | ||
142 | The pxa2xx_spi_chip structure is passed to the pxa2xx_spi driver in the | ||
143 | "spi_board_info.controller_data" field. Below is a sample configuration using | ||
144 | the PXA255 NSSP. | ||
145 | |||
146 | /* Chip Select control for the CS8415A SPI slave device */ | ||
147 | static void cs8415a_cs_control(u32 command) | ||
148 | { | ||
149 | if (command & PXA2XX_CS_ASSERT) | ||
150 | GPCR(2) = GPIO_bit(2); | ||
151 | else | ||
152 | GPSR(2) = GPIO_bit(2); | ||
153 | } | ||
154 | |||
155 | /* Chip Select control for the CS8405A SPI slave device */ | ||
156 | static void cs8405a_cs_control(u32 command) | ||
157 | { | ||
158 | if (command & PXA2XX_CS_ASSERT) | ||
159 | GPCR(3) = GPIO_bit(3); | ||
160 | else | ||
161 | GPSR(3) = GPIO_bit(3); | ||
162 | } | ||
163 | |||
164 | static struct pxa2xx_spi_chip cs8415a_chip_info = { | ||
165 | .tx_threshold = 12, /* SSP hardward FIFO threshold */ | ||
166 | .rx_threshold = 4, /* SSP hardward FIFO threshold */ | ||
167 | .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ | ||
168 | .timeout_microsecs = 64, /* Wait at least 64usec to handle trailing */ | ||
169 | .cs_control = cs8415a_cs_control, /* Use external chip select */ | ||
170 | }; | ||
171 | |||
172 | static struct pxa2xx_spi_chip cs8405a_chip_info = { | ||
173 | .tx_threshold = 12, /* SSP hardward FIFO threshold */ | ||
174 | .rx_threshold = 4, /* SSP hardward FIFO threshold */ | ||
175 | .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ | ||
176 | .timeout_microsecs = 64, /* Wait at least 64usec to handle trailing */ | ||
177 | .cs_control = cs8405a_cs_control, /* Use external chip select */ | ||
178 | }; | ||
179 | |||
180 | static struct spi_board_info streetracer_spi_board_info[] __initdata = { | ||
181 | { | ||
182 | .modalias = "cs8415a", /* Name of spi_driver for this device */ | ||
183 | .max_speed_hz = 3686400, /* Run SSP as fast a possbile */ | ||
184 | .bus_num = 2, /* Framework bus number */ | ||
185 | .chip_select = 0, /* Framework chip select */ | ||
186 | .platform_data = NULL; /* No spi_driver specific config */ | ||
187 | .controller_data = &cs8415a_chip_info, /* Master chip config */ | ||
188 | .irq = STREETRACER_APCI_IRQ, /* Slave device interrupt */ | ||
189 | }, | ||
190 | { | ||
191 | .modalias = "cs8405a", /* Name of spi_driver for this device */ | ||
192 | .max_speed_hz = 3686400, /* Run SSP as fast a possbile */ | ||
193 | .bus_num = 2, /* Framework bus number */ | ||
194 | .chip_select = 1, /* Framework chip select */ | ||
195 | .controller_data = &cs8405a_chip_info, /* Master chip config */ | ||
196 | .irq = STREETRACER_APCI_IRQ, /* Slave device interrupt */ | ||
197 | }, | ||
198 | }; | ||
199 | |||
200 | static void __init streetracer_init(void) | ||
201 | { | ||
202 | spi_register_board_info(streetracer_spi_board_info, | ||
203 | ARRAY_SIZE(streetracer_spi_board_info)); | ||
204 | } | ||
205 | |||
206 | |||
207 | DMA and PIO I/O Support | ||
208 | ----------------------- | ||
209 | The pxa2xx_spi driver support both DMA and interrupt driven PIO message | ||
210 | transfers. The driver defaults to PIO mode and DMA transfers must enabled by | ||
211 | setting the "enable_dma" flag in the "pxa2xx_spi_master" structure and and | ||
212 | ensuring that the "pxa2xx_spi_chip.dma_burst_size" field is non-zero. The DMA | ||
213 | mode support both coherent and stream based DMA mappings. | ||
214 | |||
215 | The following logic is used to determine the type of I/O to be used on | ||
216 | a per "spi_transfer" basis: | ||
217 | |||
218 | if !enable_dma or dma_burst_size == 0 then | ||
219 | always use PIO transfers | ||
220 | |||
221 | if spi_message.is_dma_mapped and rx_dma_buf != 0 and tx_dma_buf != 0 then | ||
222 | use coherent DMA mode | ||
223 | |||
224 | if rx_buf and tx_buf are aligned on 8 byte boundary then | ||
225 | use streaming DMA mode | ||
226 | |||
227 | otherwise | ||
228 | use PIO transfer | ||
229 | |||
230 | THANKS TO | ||
231 | --------- | ||
232 | |||
233 | David Brownell and others for mentoring the development of this driver. | ||
234 | |||
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index a5ffba33a351..068732d32276 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary | |||
@@ -414,7 +414,33 @@ to get the driver-private data allocated for that device. | |||
414 | The driver will initialize the fields of that spi_master, including the | 414 | The driver will initialize the fields of that spi_master, including the |
415 | bus number (maybe the same as the platform device ID) and three methods | 415 | bus number (maybe the same as the platform device ID) and three methods |
416 | used to interact with the SPI core and SPI protocol drivers. It will | 416 | used to interact with the SPI core and SPI protocol drivers. It will |
417 | also initialize its own internal state. | 417 | also initialize its own internal state. (See below about bus numbering |
418 | and those methods.) | ||
419 | |||
420 | After you initialize the spi_master, then use spi_register_master() to | ||
421 | publish it to the rest of the system. At that time, device nodes for | ||
422 | the controller and any predeclared spi devices will be made available, | ||
423 | and the driver model core will take care of binding them to drivers. | ||
424 | |||
425 | If you need to remove your SPI controller driver, spi_unregister_master() | ||
426 | will reverse the effect of spi_register_master(). | ||
427 | |||
428 | |||
429 | BUS NUMBERING | ||
430 | |||
431 | Bus numbering is important, since that's how Linux identifies a given | ||
432 | SPI bus (shared SCK, MOSI, MISO). Valid bus numbers start at zero. On | ||
433 | SOC systems, the bus numbers should match the numbers defined by the chip | ||
434 | manufacturer. For example, hardware controller SPI2 would be bus number 2, | ||
435 | and spi_board_info for devices connected to it would use that number. | ||
436 | |||
437 | If you don't have such hardware-assigned bus number, and for some reason | ||
438 | you can't just assign them, then provide a negative bus number. That will | ||
439 | then be replaced by a dynamically assigned number. You'd then need to treat | ||
440 | this as a non-static configuration (see above). | ||
441 | |||
442 | |||
443 | SPI MASTER METHODS | ||
418 | 444 | ||
419 | master->setup(struct spi_device *spi) | 445 | master->setup(struct spi_device *spi) |
420 | This sets up the device clock rate, SPI mode, and word sizes. | 446 | This sets up the device clock rate, SPI mode, and word sizes. |
@@ -431,6 +457,9 @@ also initialize its own internal state. | |||
431 | state it dynamically associates with that device. If you do that, | 457 | state it dynamically associates with that device. If you do that, |
432 | be sure to provide the cleanup() method to free that state. | 458 | be sure to provide the cleanup() method to free that state. |
433 | 459 | ||
460 | |||
461 | SPI MESSAGE QUEUE | ||
462 | |||
434 | The bulk of the driver will be managing the I/O queue fed by transfer(). | 463 | The bulk of the driver will be managing the I/O queue fed by transfer(). |
435 | 464 | ||
436 | That queue could be purely conceptual. For example, a driver used only | 465 | That queue could be purely conceptual. For example, a driver used only |
@@ -440,6 +469,9 @@ But the queue will probably be very real, using message->queue, PIO, | |||
440 | often DMA (especially if the root filesystem is in SPI flash), and | 469 | often DMA (especially if the root filesystem is in SPI flash), and |
441 | execution contexts like IRQ handlers, tasklets, or workqueues (such | 470 | execution contexts like IRQ handlers, tasklets, or workqueues (such |
442 | as keventd). Your driver can be as fancy, or as simple, as you need. | 471 | as keventd). Your driver can be as fancy, or as simple, as you need. |
472 | Such a transfer() method would normally just add the message to a | ||
473 | queue, and then start some asynchronous transfer engine (unless it's | ||
474 | already running). | ||
443 | 475 | ||
444 | 476 | ||
445 | THANKS TO | 477 | THANKS TO |
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index 2803f63c1a27..687104bfd09a 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt | |||
@@ -32,7 +32,16 @@ The output of "cat /proc/meminfo" will have lines like: | |||
32 | ..... | 32 | ..... |
33 | HugePages_Total: xxx | 33 | HugePages_Total: xxx |
34 | HugePages_Free: yyy | 34 | HugePages_Free: yyy |
35 | Hugepagesize: zzz KB | 35 | HugePages_Rsvd: www |
36 | Hugepagesize: zzz kB | ||
37 | |||
38 | where: | ||
39 | HugePages_Total is the size of the pool of hugepages. | ||
40 | HugePages_Free is the number of hugepages in the pool that are not yet | ||
41 | allocated. | ||
42 | HugePages_Rsvd is short for "reserved," and is the number of hugepages | ||
43 | for which a commitment to allocate from the pool has been made, but no | ||
44 | allocation has yet been made. It's vaguely analogous to overcommit. | ||
36 | 45 | ||
37 | /proc/filesystems should also show a filesystem of type "hugetlbfs" configured | 46 | /proc/filesystems should also show a filesystem of type "hugetlbfs" configured |
38 | in the kernel. | 47 | in the kernel. |
diff --git a/Documentation/watchdog/watchdog-api.txt b/Documentation/watchdog/watchdog-api.txt index c5beb548cfc4..21ed51173662 100644 --- a/Documentation/watchdog/watchdog-api.txt +++ b/Documentation/watchdog/watchdog-api.txt | |||
@@ -36,6 +36,9 @@ timeout or margin. The simplest way to ping the watchdog is to write | |||
36 | some data to the device. So a very simple watchdog daemon would look | 36 | some data to the device. So a very simple watchdog daemon would look |
37 | like this: | 37 | like this: |
38 | 38 | ||
39 | #include <stdlib.h> | ||
40 | #include <fcntl.h> | ||
41 | |||
39 | int main(int argc, const char *argv[]) { | 42 | int main(int argc, const char *argv[]) { |
40 | int fd=open("/dev/watchdog",O_WRONLY); | 43 | int fd=open("/dev/watchdog",O_WRONLY); |
41 | if (fd==-1) { | 44 | if (fd==-1) { |