diff options
Diffstat (limited to 'Documentation')
182 files changed, 5654 insertions, 1303 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index c17cd4bb2290..1f89424c36a6 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -192,10 +192,6 @@ kernel-docs.txt | |||
192 | - listing of various WWW + books that document kernel internals. | 192 | - listing of various WWW + books that document kernel internals. |
193 | kernel-parameters.txt | 193 | kernel-parameters.txt |
194 | - summary listing of command line / boot prompt args for the kernel. | 194 | - summary listing of command line / boot prompt args for the kernel. |
195 | keys-request-key.txt | ||
196 | - description of the kernel key request service. | ||
197 | keys.txt | ||
198 | - description of the kernel key retention service. | ||
199 | kobject.txt | 195 | kobject.txt |
200 | - info of the kobject infrastructure of the Linux kernel. | 196 | - info of the kobject infrastructure of the Linux kernel. |
201 | kprobes.txt | 197 | kprobes.txt |
@@ -294,6 +290,8 @@ scheduler/ | |||
294 | - directory with info on the scheduler. | 290 | - directory with info on the scheduler. |
295 | scsi/ | 291 | scsi/ |
296 | - directory with info on Linux scsi support. | 292 | - directory with info on Linux scsi support. |
293 | security/ | ||
294 | - directory that contains security-related info | ||
297 | serial/ | 295 | serial/ |
298 | - directory with info on the low level serial API. | 296 | - directory with info on the low level serial API. |
299 | serial-console.txt | 297 | serial-console.txt |
@@ -328,8 +326,6 @@ sysrq.txt | |||
328 | - info on the magic SysRq key. | 326 | - info on the magic SysRq key. |
329 | telephony/ | 327 | telephony/ |
330 | - directory with info on telephony (e.g. voice over IP) support. | 328 | - directory with info on telephony (e.g. voice over IP) support. |
331 | uml/ | ||
332 | - directory with information about User Mode Linux. | ||
333 | unicode.txt | 329 | unicode.txt |
334 | - info on the Unicode character/font mapping used in Linux. | 330 | - info on the Unicode character/font mapping used in Linux. |
335 | unshare.txt | 331 | unshare.txt |
diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus new file mode 100644 index 000000000000..c2a270b45b03 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus | |||
@@ -0,0 +1,10 @@ | |||
1 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile | ||
2 | Date: October 2010 | ||
3 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
4 | Description: The integer value of this attribute ranges from 0-4. | ||
5 | When read, this attribute returns the number of the actual | ||
6 | profile. This value is persistent, so its equivalent to the | ||
7 | profile that's active when the mouse is powered on next time. | ||
8 | When written, this file sets the number of the startup profile | ||
9 | and the mouse activates this profile immediately. | ||
10 | Please use actual_profile, it does the same thing. | ||
diff --git a/Documentation/ABI/obsolete/o2cb b/Documentation/ABI/removed/o2cb index 9c49d8e6c0cc..7f5daa465093 100644 --- a/Documentation/ABI/obsolete/o2cb +++ b/Documentation/ABI/removed/o2cb | |||
@@ -1,11 +1,10 @@ | |||
1 | What: /sys/o2cb symlink | 1 | What: /sys/o2cb symlink |
2 | Date: Dec 2005 | 2 | Date: May 2011 |
3 | KernelVersion: 2.6.16 | 3 | KernelVersion: 2.6.40 |
4 | Contact: ocfs2-devel@oss.oracle.com | 4 | Contact: ocfs2-devel@oss.oracle.com |
5 | Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink will | 5 | Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is |
6 | be removed when new versions of ocfs2-tools which know to look | 6 | removed when new versions of ocfs2-tools which know to look |
7 | in /sys/fs/o2cb are sufficiently prevalent. Don't code new | 7 | in /sys/fs/o2cb are sufficiently prevalent. Don't code new |
8 | software to look here, it should try /sys/fs/o2cb instead. | 8 | software to look here, it should try /sys/fs/o2cb instead. |
9 | See Documentation/ABI/stable/o2cb for more information on usage. | ||
10 | Users: ocfs2-tools. It's sufficient to mail proposed changes to | 9 | Users: ocfs2-tools. It's sufficient to mail proposed changes to |
11 | ocfs2-devel@oss.oracle.com. | 10 | ocfs2-devel@oss.oracle.com. |
diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index 4873c759d535..c1eb41cb9876 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block | |||
@@ -142,3 +142,67 @@ Description: | |||
142 | with the previous I/O request are enabled. When set to 2, | 142 | with the previous I/O request are enabled. When set to 2, |
143 | all merge tries are disabled. The default value is 0 - | 143 | all merge tries are disabled. The default value is 0 - |
144 | which enables all types of merge tries. | 144 | which enables all types of merge tries. |
145 | |||
146 | What: /sys/block/<disk>/discard_alignment | ||
147 | Date: May 2011 | ||
148 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
149 | Description: | ||
150 | Devices that support discard functionality may | ||
151 | internally allocate space in units that are bigger than | ||
152 | the exported logical block size. The discard_alignment | ||
153 | parameter indicates how many bytes the beginning of the | ||
154 | device is offset from the internal allocation unit's | ||
155 | natural alignment. | ||
156 | |||
157 | What: /sys/block/<disk>/<partition>/discard_alignment | ||
158 | Date: May 2011 | ||
159 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
160 | Description: | ||
161 | Devices that support discard functionality may | ||
162 | internally allocate space in units that are bigger than | ||
163 | the exported logical block size. The discard_alignment | ||
164 | parameter indicates how many bytes the beginning of the | ||
165 | partition is offset from the internal allocation unit's | ||
166 | natural alignment. | ||
167 | |||
168 | What: /sys/block/<disk>/queue/discard_granularity | ||
169 | Date: May 2011 | ||
170 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
171 | Description: | ||
172 | Devices that support discard functionality may | ||
173 | internally allocate space using units that are bigger | ||
174 | than the logical block size. The discard_granularity | ||
175 | parameter indicates the size of the internal allocation | ||
176 | unit in bytes if reported by the device. Otherwise the | ||
177 | discard_granularity will be set to match the device's | ||
178 | physical block size. A discard_granularity of 0 means | ||
179 | that the device does not support discard functionality. | ||
180 | |||
181 | What: /sys/block/<disk>/queue/discard_max_bytes | ||
182 | Date: May 2011 | ||
183 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
184 | Description: | ||
185 | Devices that support discard functionality may have | ||
186 | internal limits on the number of bytes that can be | ||
187 | trimmed or unmapped in a single operation. Some storage | ||
188 | protocols also have inherent limits on the number of | ||
189 | blocks that can be described in a single command. The | ||
190 | discard_max_bytes parameter is set by the device driver | ||
191 | to the maximum number of bytes that can be discarded in | ||
192 | a single operation. Discard requests issued to the | ||
193 | device must not exceed this limit. A discard_max_bytes | ||
194 | value of 0 means that the device does not support | ||
195 | discard functionality. | ||
196 | |||
197 | What: /sys/block/<disk>/queue/discard_zeroes_data | ||
198 | Date: May 2011 | ||
199 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
200 | Description: | ||
201 | Devices that support discard functionality may return | ||
202 | stale or random data when a previously discarded block | ||
203 | is read back. This can cause problems if the filesystem | ||
204 | expects discarded blocks to be explicitly cleared. If a | ||
205 | device reports that it deterministically returns zeroes | ||
206 | when a discarded area is read the discard_zeroes_data | ||
207 | parameter will be set to one. Otherwise it will be 0 and | ||
208 | the result of reading a discarded area is undefined. | ||
diff --git a/Documentation/ABI/testing/sysfs-bus-bcma b/Documentation/ABI/testing/sysfs-bus-bcma new file mode 100644 index 000000000000..06b62badddd1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-bcma | |||
@@ -0,0 +1,31 @@ | |||
1 | What: /sys/bus/bcma/devices/.../manuf | ||
2 | Date: May 2011 | ||
3 | KernelVersion: 2.6.40 | ||
4 | Contact: Rafał Miłecki <zajec5@gmail.com> | ||
5 | Description: | ||
6 | Each BCMA core has it's manufacturer id. See | ||
7 | include/linux/bcma/bcma.h for possible values. | ||
8 | |||
9 | What: /sys/bus/bcma/devices/.../id | ||
10 | Date: May 2011 | ||
11 | KernelVersion: 2.6.40 | ||
12 | Contact: Rafał Miłecki <zajec5@gmail.com> | ||
13 | Description: | ||
14 | There are a few types of BCMA cores, they can be identified by | ||
15 | id field. | ||
16 | |||
17 | What: /sys/bus/bcma/devices/.../rev | ||
18 | Date: May 2011 | ||
19 | KernelVersion: 2.6.40 | ||
20 | Contact: Rafał Miłecki <zajec5@gmail.com> | ||
21 | Description: | ||
22 | BCMA cores of the same type can still slightly differ depending | ||
23 | on their revision. Use it for detailed programming. | ||
24 | |||
25 | What: /sys/bus/bcma/devices/.../class | ||
26 | Date: May 2011 | ||
27 | KernelVersion: 2.6.40 | ||
28 | Contact: Rafał Miłecki <zajec5@gmail.com> | ||
29 | Description: | ||
30 | Each BCMA core is identified by few fields, including class it | ||
31 | belongs to. See include/linux/bcma/bcma.h for possible values. | ||
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index 36bf454ba855..349ecf26ce10 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci | |||
@@ -74,6 +74,15 @@ Description: | |||
74 | hot-remove the PCI device and any of its children. | 74 | hot-remove the PCI device and any of its children. |
75 | Depends on CONFIG_HOTPLUG. | 75 | Depends on CONFIG_HOTPLUG. |
76 | 76 | ||
77 | What: /sys/bus/pci/devices/.../pci_bus/.../rescan | ||
78 | Date: May 2011 | ||
79 | Contact: Linux PCI developers <linux-pci@vger.kernel.org> | ||
80 | Description: | ||
81 | Writing a non-zero value to this attribute will | ||
82 | force a rescan of the bus and all child buses, | ||
83 | and re-discover devices removed earlier from this | ||
84 | part of the device tree. Depends on CONFIG_HOTPLUG. | ||
85 | |||
77 | What: /sys/bus/pci/devices/.../rescan | 86 | What: /sys/bus/pci/devices/.../rescan |
78 | Date: January 2009 | 87 | Date: January 2009 |
79 | Contact: Linux PCI developers <linux-pci@vger.kernel.org> | 88 | Contact: Linux PCI developers <linux-pci@vger.kernel.org> |
diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 b/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 new file mode 100644 index 000000000000..aa11dbdd794b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 | |||
@@ -0,0 +1,56 @@ | |||
1 | What: /sys/class/backlight/<backlight>/<ambient light zone>_max | ||
2 | What: /sys/class/backlight/<backlight>/l1_daylight_max | ||
3 | What: /sys/class/backlight/<backlight>/l2_bright_max | ||
4 | What: /sys/class/backlight/<backlight>/l3_office_max | ||
5 | What: /sys/class/backlight/<backlight>/l4_indoor_max | ||
6 | What: /sys/class/backlight/<backlight>/l5_dark_max | ||
7 | Date: Mai 2011 | ||
8 | KernelVersion: 2.6.40 | ||
9 | Contact: device-drivers-devel@blackfin.uclinux.org | ||
10 | Description: | ||
11 | Control the maximum brightness for <ambient light zone> | ||
12 | on this <backlight>. Values are between 0 and 127. This file | ||
13 | will also show the brightness level stored for this | ||
14 | <ambient light zone>. | ||
15 | |||
16 | What: /sys/class/backlight/<backlight>/<ambient light zone>_dim | ||
17 | What: /sys/class/backlight/<backlight>/l2_bright_dim | ||
18 | What: /sys/class/backlight/<backlight>/l3_office_dim | ||
19 | What: /sys/class/backlight/<backlight>/l4_indoor_dim | ||
20 | What: /sys/class/backlight/<backlight>/l5_dark_dim | ||
21 | Date: Mai 2011 | ||
22 | KernelVersion: 2.6.40 | ||
23 | Contact: device-drivers-devel@blackfin.uclinux.org | ||
24 | Description: | ||
25 | Control the dim brightness for <ambient light zone> | ||
26 | on this <backlight>. Values are between 0 and 127, typically | ||
27 | set to 0. Full off when the backlight is disabled. | ||
28 | This file will also show the dim brightness level stored for | ||
29 | this <ambient light zone>. | ||
30 | |||
31 | What: /sys/class/backlight/<backlight>/ambient_light_level | ||
32 | Date: Mai 2011 | ||
33 | KernelVersion: 2.6.40 | ||
34 | Contact: device-drivers-devel@blackfin.uclinux.org | ||
35 | Description: | ||
36 | Get conversion value of the light sensor. | ||
37 | This value is updated every 80 ms (when the light sensor | ||
38 | is enabled). Returns integer between 0 (dark) and | ||
39 | 8000 (max ambient brightness) | ||
40 | |||
41 | What: /sys/class/backlight/<backlight>/ambient_light_zone | ||
42 | Date: Mai 2011 | ||
43 | KernelVersion: 2.6.40 | ||
44 | Contact: device-drivers-devel@blackfin.uclinux.org | ||
45 | Description: | ||
46 | Get/Set current ambient light zone. Reading returns | ||
47 | integer between 1..5 (1 = daylight, 2 = bright, ..., 5 = dark). | ||
48 | Writing a value between 1..5 forces the backlight controller | ||
49 | to enter the corresponding ambient light zone. | ||
50 | Writing 0 returns to normal/automatic ambient light level | ||
51 | operation. The ambient light sensing feature on these devices | ||
52 | is an extension to the API documented in | ||
53 | Documentation/ABI/stable/sysfs-class-backlight. | ||
54 | It can be enabled by writing the value stored in | ||
55 | /sys/class/backlight/<backlight>/max_brightness to | ||
56 | /sys/class/backlight/<backlight>/brightness. \ No newline at end of file | ||
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 7564e88bfa43..e7be75b96e4b 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu | |||
@@ -183,21 +183,21 @@ Description: Discover and change clock speed of CPUs | |||
183 | to learn how to control the knobs. | 183 | to learn how to control the knobs. |
184 | 184 | ||
185 | 185 | ||
186 | What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X | 186 | What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1} |
187 | Date: August 2008 | 187 | Date: August 2008 |
188 | KernelVersion: 2.6.27 | 188 | KernelVersion: 2.6.27 |
189 | Contact: mark.langsdorf@amd.com | 189 | Contact: discuss@x86-64.org |
190 | Description: These files exist in every cpu's cache index directories. | 190 | Description: Disable L3 cache indices |
191 | There are currently 2 cache_disable_# files in each | 191 | |
192 | directory. Reading from these files on a supported | 192 | These files exist in every CPU's cache/index3 directory. Each |
193 | processor will return that cache disable index value | 193 | cache_disable_{0,1} file corresponds to one disable slot which |
194 | for that processor and node. Writing to one of these | 194 | can be used to disable a cache index. Reading from these files |
195 | files will cause the specificed cache index to be disabled. | 195 | on a processor with this functionality will return the currently |
196 | 196 | disabled index for that node. There is one L3 structure per | |
197 | Currently, only AMD Family 10h Processors support cache index | 197 | node, or per internal node on MCM machines. Writing a valid |
198 | disable, and only for their L3 caches. See the BIOS and | 198 | index to one of these files will cause the specificed cache |
199 | Kernel Developer's Guide at | 199 | index to be disabled. |
200 | http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf | 200 | |
201 | for formatting information and other details on the | 201 | All AMD processors with L3 caches provide this functionality. |
202 | cache index disable. | 202 | For details, see BKDGs at |
203 | Users: joachim.deguara@amd.com | 203 | http://developer.amd.com/documentation/guides/Pages/default.aspx |
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus index 326e05452da7..c1b53b8bc2ae 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus | |||
@@ -1,9 +1,12 @@ | |||
1 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile | 1 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile |
2 | Date: October 2010 | 2 | Date: October 2010 |
3 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 3 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
4 | Description: When read, this file returns the number of the actual profile in | 4 | Description: The integer value of this attribute ranges from 0-4. |
5 | range 0-4. | 5 | When read, this attribute returns the number of the actual |
6 | This file is readonly. | 6 | profile. This value is persistent, so its equivalent to the |
7 | profile that's active when the mouse is powered on next time. | ||
8 | When written, this file sets the number of the startup profile | ||
9 | and the mouse activates this profile immediately. | ||
7 | Users: http://roccat.sourceforge.net | 10 | Users: http://roccat.sourceforge.net |
8 | 11 | ||
9 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version | 12 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version |
@@ -89,16 +92,6 @@ Description: The mouse has a tracking- and a distance-control-unit. These | |||
89 | This file is writeonly. | 92 | This file is writeonly. |
90 | Users: http://roccat.sourceforge.net | 93 | Users: http://roccat.sourceforge.net |
91 | 94 | ||
92 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile | ||
93 | Date: October 2010 | ||
94 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
95 | Description: The integer value of this attribute ranges from 0-4. | ||
96 | When read, this attribute returns the number of the profile | ||
97 | that's active when the mouse is powered on. | ||
98 | When written, this file sets the number of the startup profile | ||
99 | and the mouse activates this profile immediately. | ||
100 | Users: http://roccat.sourceforge.net | ||
101 | |||
102 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu | 95 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu |
103 | Date: October 2010 | 96 | Date: October 2010 |
104 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 97 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi b/Documentation/ABI/testing/sysfs-firmware-dmi index ba9da9503c23..c78f9ab01e56 100644 --- a/Documentation/ABI/testing/sysfs-firmware-dmi +++ b/Documentation/ABI/testing/sysfs-firmware-dmi | |||
@@ -14,14 +14,15 @@ Description: | |||
14 | 14 | ||
15 | DMI is structured as a large table of entries, where | 15 | DMI is structured as a large table of entries, where |
16 | each entry has a common header indicating the type and | 16 | each entry has a common header indicating the type and |
17 | length of the entry, as well as 'handle' that is | 17 | length of the entry, as well as a firmware-provided |
18 | supposed to be unique amongst all entries. | 18 | 'handle' that is supposed to be unique amongst all |
19 | entries. | ||
19 | 20 | ||
20 | Some entries are required by the specification, but many | 21 | Some entries are required by the specification, but many |
21 | others are optional. In general though, users should | 22 | others are optional. In general though, users should |
22 | never expect to find a specific entry type on their | 23 | never expect to find a specific entry type on their |
23 | system unless they know for certain what their firmware | 24 | system unless they know for certain what their firmware |
24 | is doing. Machine to machine will vary. | 25 | is doing. Machine to machine experiences will vary. |
25 | 26 | ||
26 | Multiple entries of the same type are allowed. In order | 27 | Multiple entries of the same type are allowed. In order |
27 | to handle these duplicate entry types, each entry is | 28 | to handle these duplicate entry types, each entry is |
@@ -67,25 +68,24 @@ Description: | |||
67 | and the two terminating nul characters. | 68 | and the two terminating nul characters. |
68 | type : The type of the entry. This value is the same | 69 | type : The type of the entry. This value is the same |
69 | as found in the directory name. It indicates | 70 | as found in the directory name. It indicates |
70 | how the rest of the entry should be | 71 | how the rest of the entry should be interpreted. |
71 | interpreted. | ||
72 | instance: The instance ordinal of the entry for the | 72 | instance: The instance ordinal of the entry for the |
73 | given type. This value is the same as found | 73 | given type. This value is the same as found |
74 | in the parent directory name. | 74 | in the parent directory name. |
75 | position: The position of the entry within the entirety | 75 | position: The ordinal position (zero-based) of the entry |
76 | of the entirety. | 76 | within the entirety of the DMI entry table. |
77 | 77 | ||
78 | === Entry Specialization === | 78 | === Entry Specialization === |
79 | 79 | ||
80 | Some entry types may have other information available in | 80 | Some entry types may have other information available in |
81 | sysfs. | 81 | sysfs. Not all types are specialized. |
82 | 82 | ||
83 | --- Type 15 - System Event Log --- | 83 | --- Type 15 - System Event Log --- |
84 | 84 | ||
85 | This entry allows the firmware to export a log of | 85 | This entry allows the firmware to export a log of |
86 | events the system has taken. This information is | 86 | events the system has taken. This information is |
87 | typically backed by nvram, but the implementation | 87 | typically backed by nvram, but the implementation |
88 | details are abstracted by this table. This entries data | 88 | details are abstracted by this table. This entry's data |
89 | is exported in the directory: | 89 | is exported in the directory: |
90 | 90 | ||
91 | /sys/firmware/dmi/entries/15-0/system_event_log | 91 | /sys/firmware/dmi/entries/15-0/system_event_log |
diff --git a/Documentation/ABI/testing/sysfs-firmware-gsmi b/Documentation/ABI/testing/sysfs-firmware-gsmi new file mode 100644 index 000000000000..0faa0aaf4b6a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-gsmi | |||
@@ -0,0 +1,58 @@ | |||
1 | What: /sys/firmware/gsmi | ||
2 | Date: March 2011 | ||
3 | Contact: Mike Waychison <mikew@google.com> | ||
4 | Description: | ||
5 | Some servers used internally at Google have firmware | ||
6 | that provides callback functionality via explicit SMI | ||
7 | triggers. Some of the callbacks are similar to those | ||
8 | provided by the EFI runtime services page, but due to | ||
9 | historical reasons this different entry-point has been | ||
10 | used. | ||
11 | |||
12 | The gsmi driver implements the kernel's abstraction for | ||
13 | these firmware callbacks. Currently, this functionality | ||
14 | is limited to handling the system event log and getting | ||
15 | access to EFI-style variables stored in nvram. | ||
16 | |||
17 | Layout: | ||
18 | |||
19 | /sys/firmware/gsmi/vars: | ||
20 | |||
21 | This directory has the same layout (and | ||
22 | underlying implementation as /sys/firmware/efi/vars. | ||
23 | See Documentation/ABI/*/sysfs-firmware-efi-vars | ||
24 | for more information on how to interact with | ||
25 | this structure. | ||
26 | |||
27 | /sys/firmware/gsmi/append_to_eventlog - write-only: | ||
28 | |||
29 | This file takes a binary blob and passes it onto | ||
30 | the firmware to be timestamped and appended to | ||
31 | the system eventlog. The binary format is | ||
32 | interpreted by the firmware and may change from | ||
33 | platform to platform. The only kernel-enforced | ||
34 | requirement is that the blob be prefixed with a | ||
35 | 32bit host-endian type used as part of the | ||
36 | firmware call. | ||
37 | |||
38 | /sys/firmware/gsmi/clear_config - write-only: | ||
39 | |||
40 | Writing any value to this file will cause the | ||
41 | entire firmware configuration to be reset to | ||
42 | "factory defaults". Callers should assume that | ||
43 | a reboot is required for the configuration to be | ||
44 | cleared. | ||
45 | |||
46 | /sys/firmware/gsmi/clear_eventlog - write-only: | ||
47 | |||
48 | This file is used to clear out a portion/the | ||
49 | whole of the system event log. Values written | ||
50 | should be values between 1 and 100 inclusive (in | ||
51 | ASCII) representing the fraction of the log to | ||
52 | clear. Not all platforms support fractional | ||
53 | clearing though, and this writes to this file | ||
54 | will error out if the firmware doesn't like your | ||
55 | submitted fraction. | ||
56 | |||
57 | Callers should assume that a reboot is needed | ||
58 | for this operation to complete. | ||
diff --git a/Documentation/ABI/testing/sysfs-firmware-log b/Documentation/ABI/testing/sysfs-firmware-log new file mode 100644 index 000000000000..9b58e7c5365f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-log | |||
@@ -0,0 +1,7 @@ | |||
1 | What: /sys/firmware/log | ||
2 | Date: February 2011 | ||
3 | Contact: Mike Waychison <mikew@google.com> | ||
4 | Description: | ||
5 | The /sys/firmware/log is a binary file that represents a | ||
6 | read-only copy of the firmware's log if one is | ||
7 | available. | ||
diff --git a/Documentation/ABI/testing/sysfs-kernel-fscaps b/Documentation/ABI/testing/sysfs-kernel-fscaps new file mode 100644 index 000000000000..50a3033b5e15 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-fscaps | |||
@@ -0,0 +1,8 @@ | |||
1 | What: /sys/kernel/fscaps | ||
2 | Date: February 2011 | ||
3 | KernelVersion: 2.6.38 | ||
4 | Contact: Ludwig Nussel <ludwig.nussel@suse.de> | ||
5 | Description | ||
6 | Shows whether file system capabilities are honored | ||
7 | when executing a binary | ||
8 | |||
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cleancache b/Documentation/ABI/testing/sysfs-kernel-mm-cleancache new file mode 100644 index 000000000000..662ae646ea12 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-mm-cleancache | |||
@@ -0,0 +1,11 @@ | |||
1 | What: /sys/kernel/mm/cleancache/ | ||
2 | Date: April 2011 | ||
3 | Contact: Dan Magenheimer <dan.magenheimer@oracle.com> | ||
4 | Description: | ||
5 | /sys/kernel/mm/cleancache/ contains a number of files which | ||
6 | record a count of various cleancache operations | ||
7 | (sum across all filesystems): | ||
8 | succ_gets | ||
9 | failed_gets | ||
10 | puts | ||
11 | flushes | ||
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index 194ca446ac28..b464d12761ba 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power | |||
@@ -158,3 +158,17 @@ Description: | |||
158 | successful, will make the kernel abort a subsequent transition | 158 | successful, will make the kernel abort a subsequent transition |
159 | to a sleep state if any wakeup events are reported after the | 159 | to a sleep state if any wakeup events are reported after the |
160 | write has returned. | 160 | write has returned. |
161 | |||
162 | What: /sys/power/reserved_size | ||
163 | Date: May 2011 | ||
164 | Contact: Rafael J. Wysocki <rjw@sisk.pl> | ||
165 | Description: | ||
166 | The /sys/power/reserved_size file allows user space to control | ||
167 | the amount of memory reserved for allocations made by device | ||
168 | drivers during the "device freeze" stage of hibernation. It can | ||
169 | be written a string representing a non-negative integer that | ||
170 | will be used as the amount of memory to reserve for allocations | ||
171 | made by device drivers' "freeze" callbacks, in bytes. | ||
172 | |||
173 | Reading from this file will display the current value, which is | ||
174 | set to 1 MB by default. | ||
diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp new file mode 100644 index 000000000000..d40d2b550502 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-ptp | |||
@@ -0,0 +1,98 @@ | |||
1 | What: /sys/class/ptp/ | ||
2 | Date: September 2010 | ||
3 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
4 | Description: | ||
5 | This directory contains files and directories | ||
6 | providing a standardized interface to the ancillary | ||
7 | features of PTP hardware clocks. | ||
8 | |||
9 | What: /sys/class/ptp/ptpN/ | ||
10 | Date: September 2010 | ||
11 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
12 | Description: | ||
13 | This directory contains the attributes of the Nth PTP | ||
14 | hardware clock registered into the PTP class driver | ||
15 | subsystem. | ||
16 | |||
17 | What: /sys/class/ptp/ptpN/clock_name | ||
18 | Date: September 2010 | ||
19 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
20 | Description: | ||
21 | This file contains the name of the PTP hardware clock | ||
22 | as a human readable string. | ||
23 | |||
24 | What: /sys/class/ptp/ptpN/max_adjustment | ||
25 | Date: September 2010 | ||
26 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
27 | Description: | ||
28 | This file contains the PTP hardware clock's maximum | ||
29 | frequency adjustment value (a positive integer) in | ||
30 | parts per billion. | ||
31 | |||
32 | What: /sys/class/ptp/ptpN/n_alarms | ||
33 | Date: September 2010 | ||
34 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
35 | Description: | ||
36 | This file contains the number of periodic or one shot | ||
37 | alarms offer by the PTP hardware clock. | ||
38 | |||
39 | What: /sys/class/ptp/ptpN/n_external_timestamps | ||
40 | Date: September 2010 | ||
41 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
42 | Description: | ||
43 | This file contains the number of external timestamp | ||
44 | channels offered by the PTP hardware clock. | ||
45 | |||
46 | What: /sys/class/ptp/ptpN/n_periodic_outputs | ||
47 | Date: September 2010 | ||
48 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
49 | Description: | ||
50 | This file contains the number of programmable periodic | ||
51 | output channels offered by the PTP hardware clock. | ||
52 | |||
53 | What: /sys/class/ptp/ptpN/pps_avaiable | ||
54 | Date: September 2010 | ||
55 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
56 | Description: | ||
57 | This file indicates whether the PTP hardware clock | ||
58 | supports a Pulse Per Second to the host CPU. Reading | ||
59 | "1" means that the PPS is supported, while "0" means | ||
60 | not supported. | ||
61 | |||
62 | What: /sys/class/ptp/ptpN/extts_enable | ||
63 | Date: September 2010 | ||
64 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
65 | Description: | ||
66 | This write-only file enables or disables external | ||
67 | timestamps. To enable external timestamps, write the | ||
68 | channel index followed by a "1" into the file. | ||
69 | To disable external timestamps, write the channel | ||
70 | index followed by a "0" into the file. | ||
71 | |||
72 | What: /sys/class/ptp/ptpN/fifo | ||
73 | Date: September 2010 | ||
74 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
75 | Description: | ||
76 | This file provides timestamps on external events, in | ||
77 | the form of three integers: channel index, seconds, | ||
78 | and nanoseconds. | ||
79 | |||
80 | What: /sys/class/ptp/ptpN/period | ||
81 | Date: September 2010 | ||
82 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
83 | Description: | ||
84 | This write-only file enables or disables periodic | ||
85 | outputs. To enable a periodic output, write five | ||
86 | integers into the file: channel index, start time | ||
87 | seconds, start time nanoseconds, period seconds, and | ||
88 | period nanoseconds. To disable a periodic output, set | ||
89 | all the seconds and nanoseconds values to zero. | ||
90 | |||
91 | What: /sys/class/ptp/ptpN/pps_enable | ||
92 | Date: September 2010 | ||
93 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
94 | Description: | ||
95 | This write-only file enables or disables delivery of | ||
96 | PPS events to the Linux PPS subsystem. To enable PPS | ||
97 | events, write a "1" into the file. To disable events, | ||
98 | write a "0" into the file. | ||
diff --git a/Documentation/Changes b/Documentation/Changes index 5f4828a034e3..b17580885273 100644 --- a/Documentation/Changes +++ b/Documentation/Changes | |||
@@ -2,13 +2,7 @@ Intro | |||
2 | ===== | 2 | ===== |
3 | 3 | ||
4 | This document is designed to provide a list of the minimum levels of | 4 | This document is designed to provide a list of the minimum levels of |
5 | software necessary to run the 2.6 kernels, as well as provide brief | 5 | software necessary to run the 3.0 kernels. |
6 | instructions regarding any other "Gotchas" users may encounter when | ||
7 | trying life on the Bleeding Edge. If upgrading from a pre-2.4.x | ||
8 | kernel, please consult the Changes file included with 2.4.x kernels for | ||
9 | additional information; most of that information will not be repeated | ||
10 | here. Basically, this document assumes that your system is already | ||
11 | functional and running at least 2.4.x kernels. | ||
12 | 6 | ||
13 | This document is originally based on my "Changes" file for 2.0.x kernels | 7 | This document is originally based on my "Changes" file for 2.0.x kernels |
14 | and therefore owes credit to the same people as that file (Jared Mauch, | 8 | and therefore owes credit to the same people as that file (Jared Mauch, |
@@ -22,11 +16,10 @@ Upgrade to at *least* these software revisions before thinking you've | |||
22 | encountered a bug! If you're unsure what version you're currently | 16 | encountered a bug! If you're unsure what version you're currently |
23 | running, the suggested command should tell you. | 17 | running, the suggested command should tell you. |
24 | 18 | ||
25 | Again, keep in mind that this list assumes you are already | 19 | Again, keep in mind that this list assumes you are already functionally |
26 | functionally running a Linux 2.4 kernel. Also, not all tools are | 20 | running a Linux kernel. Also, not all tools are necessary on all |
27 | necessary on all systems; obviously, if you don't have any ISDN | 21 | systems; obviously, if you don't have any ISDN hardware, for example, |
28 | hardware, for example, you probably needn't concern yourself with | 22 | you probably needn't concern yourself with isdn4k-utils. |
29 | isdn4k-utils. | ||
30 | 23 | ||
31 | o Gnu C 3.2 # gcc --version | 24 | o Gnu C 3.2 # gcc --version |
32 | o Gnu make 3.80 # make --version | 25 | o Gnu make 3.80 # make --version |
@@ -114,12 +107,12 @@ Ksymoops | |||
114 | 107 | ||
115 | If the unthinkable happens and your kernel oopses, you may need the | 108 | If the unthinkable happens and your kernel oopses, you may need the |
116 | ksymoops tool to decode it, but in most cases you don't. | 109 | ksymoops tool to decode it, but in most cases you don't. |
117 | In the 2.6 kernel it is generally preferred to build the kernel with | 110 | It is generally preferred to build the kernel with CONFIG_KALLSYMS so |
118 | CONFIG_KALLSYMS so that it produces readable dumps that can be used as-is | 111 | that it produces readable dumps that can be used as-is (this also |
119 | (this also produces better output than ksymoops). | 112 | produces better output than ksymoops). If for some reason your kernel |
120 | If for some reason your kernel is not build with CONFIG_KALLSYMS and | 113 | is not build with CONFIG_KALLSYMS and you have no way to rebuild and |
121 | you have no way to rebuild and reproduce the Oops with that option, then | 114 | reproduce the Oops with that option, then you can still decode that Oops |
122 | you can still decode that Oops with ksymoops. | 115 | with ksymoops. |
123 | 116 | ||
124 | Module-Init-Tools | 117 | Module-Init-Tools |
125 | ----------------- | 118 | ----------------- |
@@ -261,8 +254,8 @@ needs to be recompiled or (preferably) upgraded. | |||
261 | NFS-utils | 254 | NFS-utils |
262 | --------- | 255 | --------- |
263 | 256 | ||
264 | In 2.4 and earlier kernels, the nfs server needed to know about any | 257 | In ancient (2.4 and earlier) kernels, the nfs server needed to know |
265 | client that expected to be able to access files via NFS. This | 258 | about any client that expected to be able to access files via NFS. This |
266 | information would be given to the kernel by "mountd" when the client | 259 | information would be given to the kernel by "mountd" when the client |
267 | mounted the filesystem, or by "exportfs" at system startup. exportfs | 260 | mounted the filesystem, or by "exportfs" at system startup. exportfs |
268 | would take information about active clients from /var/lib/nfs/rmtab. | 261 | would take information about active clients from /var/lib/nfs/rmtab. |
@@ -272,11 +265,11 @@ which is not always easy, particularly when trying to implement | |||
272 | fail-over. Even when the system is working well, rmtab suffers from | 265 | fail-over. Even when the system is working well, rmtab suffers from |
273 | getting lots of old entries that never get removed. | 266 | getting lots of old entries that never get removed. |
274 | 267 | ||
275 | With 2.6 we have the option of having the kernel tell mountd when it | 268 | With modern kernels we have the option of having the kernel tell mountd |
276 | gets a request from an unknown host, and mountd can give appropriate | 269 | when it gets a request from an unknown host, and mountd can give |
277 | export information to the kernel. This removes the dependency on | 270 | appropriate export information to the kernel. This removes the |
278 | rmtab and means that the kernel only needs to know about currently | 271 | dependency on rmtab and means that the kernel only needs to know about |
279 | active clients. | 272 | currently active clients. |
280 | 273 | ||
281 | To enable this new functionality, you need to: | 274 | To enable this new functionality, you need to: |
282 | 275 | ||
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 58b0bf917834..fa6e25b94a54 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle | |||
@@ -680,8 +680,8 @@ ones already enabled by DEBUG. | |||
680 | Chapter 14: Allocating memory | 680 | Chapter 14: Allocating memory |
681 | 681 | ||
682 | The kernel provides the following general purpose memory allocators: | 682 | The kernel provides the following general purpose memory allocators: |
683 | kmalloc(), kzalloc(), kcalloc(), and vmalloc(). Please refer to the API | 683 | kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc(). Please refer to |
684 | documentation for further information about them. | 684 | the API documentation for further information about them. |
685 | 685 | ||
686 | The preferred form for passing a size of a struct is the following: | 686 | The preferred form for passing a size of a struct is the following: |
687 | 687 | ||
diff --git a/Documentation/DocBook/.gitignore b/Documentation/DocBook/.gitignore index c6def352fe39..679034cbd686 100644 --- a/Documentation/DocBook/.gitignore +++ b/Documentation/DocBook/.gitignore | |||
@@ -8,3 +8,4 @@ | |||
8 | *.dvi | 8 | *.dvi |
9 | *.log | 9 | *.log |
10 | *.out | 10 | *.out |
11 | media/ | ||
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 8436b018c289..3cebfa0d1611 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile | |||
@@ -73,7 +73,7 @@ installmandocs: mandocs | |||
73 | ### | 73 | ### |
74 | #External programs used | 74 | #External programs used |
75 | KERNELDOC = $(srctree)/scripts/kernel-doc | 75 | KERNELDOC = $(srctree)/scripts/kernel-doc |
76 | DOCPROC = $(objtree)/scripts/basic/docproc | 76 | DOCPROC = $(objtree)/scripts/docproc |
77 | 77 | ||
78 | XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl | 78 | XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl |
79 | XMLTOFLAGS += --skip-validation | 79 | XMLTOFLAGS += --skip-validation |
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 36f63d4a0a06..b638e50cf8f6 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl | |||
@@ -96,10 +96,10 @@ X!Iinclude/linux/kobject.h | |||
96 | 96 | ||
97 | <chapter id="devdrivers"> | 97 | <chapter id="devdrivers"> |
98 | <title>Device drivers infrastructure</title> | 98 | <title>Device drivers infrastructure</title> |
99 | <sect1><title>The Basic Device Driver-Model Structures </title> | ||
100 | !Iinclude/linux/device.h | ||
101 | </sect1> | ||
99 | <sect1><title>Device Drivers Base</title> | 102 | <sect1><title>Device Drivers Base</title> |
100 | <!-- | ||
101 | X!Iinclude/linux/device.h | ||
102 | --> | ||
103 | !Edrivers/base/driver.c | 103 | !Edrivers/base/driver.c |
104 | !Edrivers/base/core.c | 104 | !Edrivers/base/core.c |
105 | !Edrivers/base/class.c | 105 | !Edrivers/base/class.c |
diff --git a/Documentation/DocBook/dvb/dvbapi.xml b/Documentation/DocBook/dvb/dvbapi.xml index ad8678d48916..9fad86ce7f5e 100644 --- a/Documentation/DocBook/dvb/dvbapi.xml +++ b/Documentation/DocBook/dvb/dvbapi.xml | |||
@@ -35,6 +35,14 @@ | |||
35 | <revhistory> | 35 | <revhistory> |
36 | <!-- Put document revisions here, newest first. --> | 36 | <!-- Put document revisions here, newest first. --> |
37 | <revision> | 37 | <revision> |
38 | <revnumber>2.0.4</revnumber> | ||
39 | <date>2011-05-06</date> | ||
40 | <authorinitials>mcc</authorinitials> | ||
41 | <revremark> | ||
42 | Add more information about DVB APIv5, better describing the frontend GET/SET props ioctl's. | ||
43 | </revremark> | ||
44 | </revision> | ||
45 | <revision> | ||
38 | <revnumber>2.0.3</revnumber> | 46 | <revnumber>2.0.3</revnumber> |
39 | <date>2010-07-03</date> | 47 | <date>2010-07-03</date> |
40 | <authorinitials>mcc</authorinitials> | 48 | <authorinitials>mcc</authorinitials> |
diff --git a/Documentation/DocBook/dvb/dvbproperty.xml b/Documentation/DocBook/dvb/dvbproperty.xml index 97f397e2fb3a..b5365f61d69b 100644 --- a/Documentation/DocBook/dvb/dvbproperty.xml +++ b/Documentation/DocBook/dvb/dvbproperty.xml | |||
@@ -1,6 +1,330 @@ | |||
1 | <section id="FE_GET_PROPERTY"> | 1 | <section id="FE_GET_SET_PROPERTY"> |
2 | <title>FE_GET_PROPERTY/FE_SET_PROPERTY</title> | 2 | <title>FE_GET_PROPERTY/FE_SET_PROPERTY</title> |
3 | 3 | ||
4 | <programlisting> | ||
5 | /* Reserved fields should be set to 0 */ | ||
6 | struct dtv_property { | ||
7 | __u32 cmd; | ||
8 | union { | ||
9 | __u32 data; | ||
10 | struct { | ||
11 | __u8 data[32]; | ||
12 | __u32 len; | ||
13 | __u32 reserved1[3]; | ||
14 | void *reserved2; | ||
15 | } buffer; | ||
16 | } u; | ||
17 | int result; | ||
18 | } __attribute__ ((packed)); | ||
19 | |||
20 | /* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */ | ||
21 | #define DTV_IOCTL_MAX_MSGS 64 | ||
22 | |||
23 | struct dtv_properties { | ||
24 | __u32 num; | ||
25 | struct dtv_property *props; | ||
26 | }; | ||
27 | </programlisting> | ||
28 | |||
29 | <section id="FE_GET_PROPERTY"> | ||
30 | <title>FE_GET_PROPERTY</title> | ||
31 | <para>DESCRIPTION | ||
32 | </para> | ||
33 | <informaltable><tgroup cols="1"><tbody><row><entry | ||
34 | align="char"> | ||
35 | <para>This ioctl call returns one or more frontend properties. This call only | ||
36 | requires read-only access to the device.</para> | ||
37 | </entry> | ||
38 | </row></tbody></tgroup></informaltable> | ||
39 | <para>SYNOPSIS | ||
40 | </para> | ||
41 | <informaltable><tgroup cols="1"><tbody><row><entry | ||
42 | align="char"> | ||
43 | <para>int ioctl(int fd, int request = <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>, | ||
44 | dtv_properties ⋆props);</para> | ||
45 | </entry> | ||
46 | </row></tbody></tgroup></informaltable> | ||
47 | <para>PARAMETERS | ||
48 | </para> | ||
49 | <informaltable><tgroup cols="2"><tbody><row><entry align="char"> | ||
50 | <para>int fd</para> | ||
51 | </entry><entry | ||
52 | align="char"> | ||
53 | <para>File descriptor returned by a previous call to open().</para> | ||
54 | </entry> | ||
55 | </row><row><entry | ||
56 | align="char"> | ||
57 | <para>int num</para> | ||
58 | </entry><entry | ||
59 | align="char"> | ||
60 | <para>Equals <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link> for this command.</para> | ||
61 | </entry> | ||
62 | </row><row><entry | ||
63 | align="char"> | ||
64 | <para>struct dtv_property *props</para> | ||
65 | </entry><entry | ||
66 | align="char"> | ||
67 | <para>Points to the location where the front-end property commands are stored.</para> | ||
68 | </entry> | ||
69 | </row></tbody></tgroup></informaltable> | ||
70 | <para>ERRORS</para> | ||
71 | <informaltable><tgroup cols="2"><tbody><row> | ||
72 | <entry align="char"><para>EINVAL</para></entry> | ||
73 | <entry align="char"><para>Invalid parameter(s) received or number of parameters out of the range.</para></entry> | ||
74 | </row><row> | ||
75 | <entry align="char"><para>ENOMEM</para></entry> | ||
76 | <entry align="char"><para>Out of memory.</para></entry> | ||
77 | </row><row> | ||
78 | <entry align="char"><para>EFAULT</para></entry> | ||
79 | <entry align="char"><para>Failure while copying data from/to userspace.</para></entry> | ||
80 | </row><row> | ||
81 | <entry align="char"><para>EOPNOTSUPP</para></entry> | ||
82 | <entry align="char"><para>Property type not supported.</para></entry> | ||
83 | </row></tbody></tgroup></informaltable> | ||
84 | </section> | ||
85 | |||
86 | <section id="FE_SET_PROPERTY"> | ||
87 | <title>FE_SET_PROPERTY</title> | ||
88 | <para>DESCRIPTION | ||
89 | </para> | ||
90 | <informaltable><tgroup cols="1"><tbody><row><entry | ||
91 | align="char"> | ||
92 | <para>This ioctl call sets one or more frontend properties. This call only | ||
93 | requires read-only access to the device.</para> | ||
94 | </entry> | ||
95 | </row></tbody></tgroup></informaltable> | ||
96 | <para>SYNOPSIS | ||
97 | </para> | ||
98 | <informaltable><tgroup cols="1"><tbody><row><entry | ||
99 | align="char"> | ||
100 | <para>int ioctl(int fd, int request = <link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>, | ||
101 | dtv_properties ⋆props);</para> | ||
102 | </entry> | ||
103 | </row></tbody></tgroup></informaltable> | ||
104 | <para>PARAMETERS | ||
105 | </para> | ||
106 | <informaltable><tgroup cols="2"><tbody><row><entry align="char"> | ||
107 | <para>int fd</para> | ||
108 | </entry><entry | ||
109 | align="char"> | ||
110 | <para>File descriptor returned by a previous call to open().</para> | ||
111 | </entry> | ||
112 | </row><row><entry | ||
113 | align="char"> | ||
114 | <para>int num</para> | ||
115 | </entry><entry | ||
116 | align="char"> | ||
117 | <para>Equals <link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link> for this command.</para> | ||
118 | </entry> | ||
119 | </row><row><entry | ||
120 | align="char"> | ||
121 | <para>struct dtv_property *props</para> | ||
122 | </entry><entry | ||
123 | align="char"> | ||
124 | <para>Points to the location where the front-end property commands are stored.</para> | ||
125 | </entry> | ||
126 | </row></tbody></tgroup></informaltable> | ||
127 | <para>ERRORS | ||
128 | </para> | ||
129 | <informaltable><tgroup cols="2"><tbody><row> | ||
130 | <entry align="char"><para>EINVAL</para></entry> | ||
131 | <entry align="char"><para>Invalid parameter(s) received or number of parameters out of the range.</para></entry> | ||
132 | </row><row> | ||
133 | <entry align="char"><para>ENOMEM</para></entry> | ||
134 | <entry align="char"><para>Out of memory.</para></entry> | ||
135 | </row><row> | ||
136 | <entry align="char"><para>EFAULT</para></entry> | ||
137 | <entry align="char"><para>Failure while copying data from/to userspace.</para></entry> | ||
138 | </row><row> | ||
139 | <entry align="char"><para>EOPNOTSUPP</para></entry> | ||
140 | <entry align="char"><para>Property type not supported.</para></entry> | ||
141 | </row></tbody></tgroup></informaltable> | ||
142 | </section> | ||
143 | |||
144 | <section> | ||
145 | <title>Property types</title> | ||
146 | <para> | ||
147 | On <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>/<link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>, | ||
148 | the actual action is determined by the dtv_property cmd/data pairs. With one single ioctl, is possible to | ||
149 | get/set up to 64 properties. The actual meaning of each property is described on the next sections. | ||
150 | </para> | ||
151 | |||
152 | <para>The available frontend property types are:</para> | ||
153 | <programlisting> | ||
154 | #define DTV_UNDEFINED 0 | ||
155 | #define DTV_TUNE 1 | ||
156 | #define DTV_CLEAR 2 | ||
157 | #define DTV_FREQUENCY 3 | ||
158 | #define DTV_MODULATION 4 | ||
159 | #define DTV_BANDWIDTH_HZ 5 | ||
160 | #define DTV_INVERSION 6 | ||
161 | #define DTV_DISEQC_MASTER 7 | ||
162 | #define DTV_SYMBOL_RATE 8 | ||
163 | #define DTV_INNER_FEC 9 | ||
164 | #define DTV_VOLTAGE 10 | ||
165 | #define DTV_TONE 11 | ||
166 | #define DTV_PILOT 12 | ||
167 | #define DTV_ROLLOFF 13 | ||
168 | #define DTV_DISEQC_SLAVE_REPLY 14 | ||
169 | #define DTV_FE_CAPABILITY_COUNT 15 | ||
170 | #define DTV_FE_CAPABILITY 16 | ||
171 | #define DTV_DELIVERY_SYSTEM 17 | ||
172 | #define DTV_ISDBT_PARTIAL_RECEPTION 18 | ||
173 | #define DTV_ISDBT_SOUND_BROADCASTING 19 | ||
174 | #define DTV_ISDBT_SB_SUBCHANNEL_ID 20 | ||
175 | #define DTV_ISDBT_SB_SEGMENT_IDX 21 | ||
176 | #define DTV_ISDBT_SB_SEGMENT_COUNT 22 | ||
177 | #define DTV_ISDBT_LAYERA_FEC 23 | ||
178 | #define DTV_ISDBT_LAYERA_MODULATION 24 | ||
179 | #define DTV_ISDBT_LAYERA_SEGMENT_COUNT 25 | ||
180 | #define DTV_ISDBT_LAYERA_TIME_INTERLEAVING 26 | ||
181 | #define DTV_ISDBT_LAYERB_FEC 27 | ||
182 | #define DTV_ISDBT_LAYERB_MODULATION 28 | ||
183 | #define DTV_ISDBT_LAYERB_SEGMENT_COUNT 29 | ||
184 | #define DTV_ISDBT_LAYERB_TIME_INTERLEAVING 30 | ||
185 | #define DTV_ISDBT_LAYERC_FEC 31 | ||
186 | #define DTV_ISDBT_LAYERC_MODULATION 32 | ||
187 | #define DTV_ISDBT_LAYERC_SEGMENT_COUNT 33 | ||
188 | #define DTV_ISDBT_LAYERC_TIME_INTERLEAVING 34 | ||
189 | #define DTV_API_VERSION 35 | ||
190 | #define DTV_CODE_RATE_HP 36 | ||
191 | #define DTV_CODE_RATE_LP 37 | ||
192 | #define DTV_GUARD_INTERVAL 38 | ||
193 | #define DTV_TRANSMISSION_MODE 39 | ||
194 | #define DTV_HIERARCHY 40 | ||
195 | #define DTV_ISDBT_LAYER_ENABLED 41 | ||
196 | #define DTV_ISDBS_TS_ID 42 | ||
197 | </programlisting> | ||
198 | </section> | ||
199 | |||
200 | <section id="fe_property_common"> | ||
201 | <title>Parameters that are common to all Digital TV standards</title> | ||
202 | <section id="DTV_FREQUENCY"> | ||
203 | <title><constant>DTV_FREQUENCY</constant></title> | ||
204 | |||
205 | <para>Central frequency of the channel, in HZ.</para> | ||
206 | |||
207 | <para>Notes:</para> | ||
208 | <para>1)For ISDB-T, the channels are usually transmitted with an offset of 143kHz. | ||
209 | E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of | ||
210 | the channel which is 6MHz.</para> | ||
211 | |||
212 | <para>2)As in ISDB-Tsb the channel consists of only one or three segments the | ||
213 | frequency step is 429kHz, 3*429 respectively. As for ISDB-T the | ||
214 | central frequency of the channel is expected.</para> | ||
215 | </section> | ||
216 | |||
217 | <section id="DTV_BANDWIDTH_HZ"> | ||
218 | <title><constant>DTV_BANDWIDTH_HZ</constant></title> | ||
219 | |||
220 | <para>Bandwidth for the channel, in HZ.</para> | ||
221 | |||
222 | <para>Possible values: | ||
223 | <constant>1712000</constant>, | ||
224 | <constant>5000000</constant>, | ||
225 | <constant>6000000</constant>, | ||
226 | <constant>7000000</constant>, | ||
227 | <constant>8000000</constant>, | ||
228 | <constant>10000000</constant>. | ||
229 | </para> | ||
230 | |||
231 | <para>Notes:</para> | ||
232 | |||
233 | <para>1) For ISDB-T it should be always 6000000Hz (6MHz)</para> | ||
234 | <para>2) For ISDB-Tsb it can vary depending on the number of connected segments</para> | ||
235 | <para>3) Bandwidth doesn't apply for DVB-C transmissions, as the bandwidth | ||
236 | for DVB-C depends on the symbol rate</para> | ||
237 | <para>4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from | ||
238 | other parameters (DTV_ISDBT_SB_SEGMENT_IDX, | ||
239 | DTV_ISDBT_SB_SEGMENT_COUNT).</para> | ||
240 | <para>5) DVB-T supports 6, 7 and 8MHz.</para> | ||
241 | <para>6) In addition, DVB-T2 supports 1.172, 5 and 10MHz.</para> | ||
242 | </section> | ||
243 | |||
244 | <section id="DTV_DELIVERY_SYSTEM"> | ||
245 | <title><constant>DTV_DELIVERY_SYSTEM</constant></title> | ||
246 | |||
247 | <para>Specifies the type of Delivery system</para> | ||
248 | |||
249 | <para>Possible values: </para> | ||
250 | <programlisting> | ||
251 | typedef enum fe_delivery_system { | ||
252 | SYS_UNDEFINED, | ||
253 | SYS_DVBC_ANNEX_AC, | ||
254 | SYS_DVBC_ANNEX_B, | ||
255 | SYS_DVBT, | ||
256 | SYS_DSS, | ||
257 | SYS_DVBS, | ||
258 | SYS_DVBS2, | ||
259 | SYS_DVBH, | ||
260 | SYS_ISDBT, | ||
261 | SYS_ISDBS, | ||
262 | SYS_ISDBC, | ||
263 | SYS_ATSC, | ||
264 | SYS_ATSCMH, | ||
265 | SYS_DMBTH, | ||
266 | SYS_CMMB, | ||
267 | SYS_DAB, | ||
268 | SYS_DVBT2, | ||
269 | } fe_delivery_system_t; | ||
270 | </programlisting> | ||
271 | |||
272 | </section> | ||
273 | |||
274 | <section id="DTV_TRANSMISSION_MODE"> | ||
275 | <title><constant>DTV_TRANSMISSION_MODE</constant></title> | ||
276 | |||
277 | <para>Specifies the number of carriers used by the standard</para> | ||
278 | |||
279 | <para>Possible values are:</para> | ||
280 | <programlisting> | ||
281 | typedef enum fe_transmit_mode { | ||
282 | TRANSMISSION_MODE_2K, | ||
283 | TRANSMISSION_MODE_8K, | ||
284 | TRANSMISSION_MODE_AUTO, | ||
285 | TRANSMISSION_MODE_4K, | ||
286 | TRANSMISSION_MODE_1K, | ||
287 | TRANSMISSION_MODE_16K, | ||
288 | TRANSMISSION_MODE_32K, | ||
289 | } fe_transmit_mode_t; | ||
290 | </programlisting> | ||
291 | |||
292 | <para>Notes:</para> | ||
293 | <para>1) ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called | ||
294 | 'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para> | ||
295 | |||
296 | <para>2) If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the | ||
297 | hardware will try to find the correct FFT-size (if capable) and will | ||
298 | use TMCC to fill in the missing parameters.</para> | ||
299 | <para>3) DVB-T specifies 2K and 8K as valid sizes.</para> | ||
300 | <para>4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K.</para> | ||
301 | </section> | ||
302 | |||
303 | <section id="DTV_GUARD_INTERVAL"> | ||
304 | <title><constant>DTV_GUARD_INTERVAL</constant></title> | ||
305 | |||
306 | <para>Possible values are:</para> | ||
307 | <programlisting> | ||
308 | typedef enum fe_guard_interval { | ||
309 | GUARD_INTERVAL_1_32, | ||
310 | GUARD_INTERVAL_1_16, | ||
311 | GUARD_INTERVAL_1_8, | ||
312 | GUARD_INTERVAL_1_4, | ||
313 | GUARD_INTERVAL_AUTO, | ||
314 | GUARD_INTERVAL_1_128, | ||
315 | GUARD_INTERVAL_19_128, | ||
316 | GUARD_INTERVAL_19_256, | ||
317 | } fe_guard_interval_t; | ||
318 | </programlisting> | ||
319 | |||
320 | <para>Notes:</para> | ||
321 | <para>1) If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will | ||
322 | try to find the correct guard interval (if capable) and will use TMCC to fill | ||
323 | in the missing parameters.</para> | ||
324 | <para>2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at present</para> | ||
325 | </section> | ||
326 | </section> | ||
327 | |||
4 | <section id="isdbt"> | 328 | <section id="isdbt"> |
5 | <title>ISDB-T frontend</title> | 329 | <title>ISDB-T frontend</title> |
6 | <para>This section describes shortly what are the possible parameters in the Linux | 330 | <para>This section describes shortly what are the possible parameters in the Linux |
@@ -32,73 +356,6 @@ | |||
32 | 356 | ||
33 | <para>Parameters used by ISDB-T and ISDB-Tsb.</para> | 357 | <para>Parameters used by ISDB-T and ISDB-Tsb.</para> |
34 | 358 | ||
35 | <section id="isdbt-parms"> | ||
36 | <title>Parameters that are common with DVB-T and ATSC</title> | ||
37 | |||
38 | <section id="isdbt-freq"> | ||
39 | <title><constant>DTV_FREQUENCY</constant></title> | ||
40 | |||
41 | <para>Central frequency of the channel.</para> | ||
42 | |||
43 | <para>For ISDB-T the channels are usually transmitted with an offset of 143kHz. E.g. a | ||
44 | valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of | ||
45 | the channel which is 6MHz.</para> | ||
46 | |||
47 | <para>As in ISDB-Tsb the channel consists of only one or three segments the | ||
48 | frequency step is 429kHz, 3*429 respectively. As for ISDB-T the | ||
49 | central frequency of the channel is expected.</para> | ||
50 | </section> | ||
51 | |||
52 | <section id="isdbt-bw"> | ||
53 | <title><constant>DTV_BANDWIDTH_HZ</constant> (optional)</title> | ||
54 | |||
55 | <para>Possible values:</para> | ||
56 | |||
57 | <para>For ISDB-T it should be always 6000000Hz (6MHz)</para> | ||
58 | <para>For ISDB-Tsb it can vary depending on the number of connected segments</para> | ||
59 | |||
60 | <para>Note: Hardware specific values might be given here, but standard | ||
61 | applications should not bother to set a value to this field as | ||
62 | standard demods are ignoring it anyway.</para> | ||
63 | |||
64 | <para>Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from | ||
65 | other parameters (DTV_ISDBT_SB_SEGMENT_IDX, | ||
66 | DTV_ISDBT_SB_SEGMENT_COUNT).</para> | ||
67 | </section> | ||
68 | |||
69 | <section id="isdbt-delivery-sys"> | ||
70 | <title><constant>DTV_DELIVERY_SYSTEM</constant></title> | ||
71 | |||
72 | <para>Possible values: <constant>SYS_ISDBT</constant></para> | ||
73 | </section> | ||
74 | |||
75 | <section id="isdbt-tx-mode"> | ||
76 | <title><constant>DTV_TRANSMISSION_MODE</constant></title> | ||
77 | |||
78 | <para>ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called | ||
79 | 'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para> | ||
80 | |||
81 | <para>Possible values: <constant>TRANSMISSION_MODE_2K</constant>, <constant>TRANSMISSION_MODE_8K</constant>, | ||
82 | <constant>TRANSMISSION_MODE_AUTO</constant>, <constant>TRANSMISSION_MODE_4K</constant></para> | ||
83 | |||
84 | <para>If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the | ||
85 | hardware will try to find the correct FFT-size (if capable) and will | ||
86 | use TMCC to fill in the missing parameters.</para> | ||
87 | |||
88 | <para><constant>TRANSMISSION_MODE_4K</constant> is added at the same time as the other new parameters.</para> | ||
89 | </section> | ||
90 | |||
91 | <section id="isdbt-guard-interval"> | ||
92 | <title><constant>DTV_GUARD_INTERVAL</constant></title> | ||
93 | |||
94 | <para>Possible values: <constant>GUARD_INTERVAL_1_32</constant>, <constant>GUARD_INTERVAL_1_16</constant>, <constant>GUARD_INTERVAL_1_8</constant>, | ||
95 | <constant>GUARD_INTERVAL_1_4</constant>, <constant>GUARD_INTERVAL_AUTO</constant></para> | ||
96 | |||
97 | <para>If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will | ||
98 | try to find the correct guard interval (if capable) and will use TMCC to fill | ||
99 | in the missing parameters.</para> | ||
100 | </section> | ||
101 | </section> | ||
102 | <section id="isdbt-new-parms"> | 359 | <section id="isdbt-new-parms"> |
103 | <title>ISDB-T only parameters</title> | 360 | <title>ISDB-T only parameters</title> |
104 | 361 | ||
@@ -314,5 +571,20 @@ | |||
314 | </section> | 571 | </section> |
315 | </section> | 572 | </section> |
316 | </section> | 573 | </section> |
574 | <section id="dvbt2-params"> | ||
575 | <title>DVB-T2 parameters</title> | ||
576 | |||
577 | <para>This section covers parameters that apply only to the DVB-T2 delivery method. DVB-T2 | ||
578 | support is currently in the early stages development so expect this section to grow | ||
579 | and become more detailed with time.</para> | ||
580 | |||
581 | <section id="dvbt2-plp-id"> | ||
582 | <title><constant>DTV_DVBT2_PLP_ID</constant></title> | ||
583 | |||
584 | <para>DVB-T2 supports Physical Layer Pipes (PLP) to allow transmission of | ||
585 | many data types via a single multiplex. The API will soon support this | ||
586 | at which point this section will be expanded.</para> | ||
587 | </section> | ||
588 | </section> | ||
317 | </section> | 589 | </section> |
318 | </section> | 590 | </section> |
diff --git a/Documentation/DocBook/dvb/frontend.h.xml b/Documentation/DocBook/dvb/frontend.h.xml index d08e0d401418..d792f789ad3b 100644 --- a/Documentation/DocBook/dvb/frontend.h.xml +++ b/Documentation/DocBook/dvb/frontend.h.xml | |||
@@ -176,14 +176,20 @@ typedef enum fe_transmit_mode { | |||
176 | TRANSMISSION_MODE_2K, | 176 | TRANSMISSION_MODE_2K, |
177 | TRANSMISSION_MODE_8K, | 177 | TRANSMISSION_MODE_8K, |
178 | TRANSMISSION_MODE_AUTO, | 178 | TRANSMISSION_MODE_AUTO, |
179 | TRANSMISSION_MODE_4K | 179 | TRANSMISSION_MODE_4K, |
180 | TRANSMISSION_MODE_1K, | ||
181 | TRANSMISSION_MODE_16K, | ||
182 | TRANSMISSION_MODE_32K, | ||
180 | } fe_transmit_mode_t; | 183 | } fe_transmit_mode_t; |
181 | 184 | ||
182 | typedef enum fe_bandwidth { | 185 | typedef enum fe_bandwidth { |
183 | BANDWIDTH_8_MHZ, | 186 | BANDWIDTH_8_MHZ, |
184 | BANDWIDTH_7_MHZ, | 187 | BANDWIDTH_7_MHZ, |
185 | BANDWIDTH_6_MHZ, | 188 | BANDWIDTH_6_MHZ, |
186 | BANDWIDTH_AUTO | 189 | BANDWIDTH_AUTO, |
190 | BANDWIDTH_5_MHZ, | ||
191 | BANDWIDTH_10_MHZ, | ||
192 | BANDWIDTH_1_712_MHZ, | ||
187 | } fe_bandwidth_t; | 193 | } fe_bandwidth_t; |
188 | 194 | ||
189 | 195 | ||
@@ -192,7 +198,10 @@ typedef enum fe_guard_interval { | |||
192 | GUARD_INTERVAL_1_16, | 198 | GUARD_INTERVAL_1_16, |
193 | GUARD_INTERVAL_1_8, | 199 | GUARD_INTERVAL_1_8, |
194 | GUARD_INTERVAL_1_4, | 200 | GUARD_INTERVAL_1_4, |
195 | GUARD_INTERVAL_AUTO | 201 | GUARD_INTERVAL_AUTO, |
202 | GUARD_INTERVAL_1_128, | ||
203 | GUARD_INTERVAL_19_128, | ||
204 | GUARD_INTERVAL_19_256, | ||
196 | } fe_guard_interval_t; | 205 | } fe_guard_interval_t; |
197 | 206 | ||
198 | 207 | ||
@@ -306,7 +315,9 @@ struct dvb_frontend_event { | |||
306 | 315 | ||
307 | #define DTV_ISDBS_TS_ID 42 | 316 | #define DTV_ISDBS_TS_ID 42 |
308 | 317 | ||
309 | #define DTV_MAX_COMMAND DTV_ISDBS_TS_ID | 318 | #define DTV_DVBT2_PLP_ID 43 |
319 | |||
320 | #define DTV_MAX_COMMAND DTV_DVBT2_PLP_ID | ||
310 | 321 | ||
311 | typedef enum fe_pilot { | 322 | typedef enum fe_pilot { |
312 | PILOT_ON, | 323 | PILOT_ON, |
@@ -338,6 +349,7 @@ typedef enum fe_delivery_system { | |||
338 | SYS_DMBTH, | 349 | SYS_DMBTH, |
339 | SYS_CMMB, | 350 | SYS_CMMB, |
340 | SYS_DAB, | 351 | SYS_DAB, |
352 | SYS_DVBT2, | ||
341 | } fe_delivery_system_t; | 353 | } fe_delivery_system_t; |
342 | 354 | ||
343 | struct dtv_cmds_h { | 355 | struct dtv_cmds_h { |
diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl index fb10fd08c05c..b3422341d65c 100644 --- a/Documentation/DocBook/genericirq.tmpl +++ b/Documentation/DocBook/genericirq.tmpl | |||
@@ -191,8 +191,8 @@ | |||
191 | <para> | 191 | <para> |
192 | Whenever an interrupt triggers, the lowlevel arch code calls into | 192 | Whenever an interrupt triggers, the lowlevel arch code calls into |
193 | the generic interrupt code by calling desc->handle_irq(). | 193 | the generic interrupt code by calling desc->handle_irq(). |
194 | This highlevel IRQ handling function only uses desc->chip primitives | 194 | This highlevel IRQ handling function only uses desc->irq_data.chip |
195 | referenced by the assigned chip descriptor structure. | 195 | primitives referenced by the assigned chip descriptor structure. |
196 | </para> | 196 | </para> |
197 | </sect1> | 197 | </sect1> |
198 | <sect1 id="Highlevel_Driver_API"> | 198 | <sect1 id="Highlevel_Driver_API"> |
@@ -206,11 +206,11 @@ | |||
206 | <listitem><para>enable_irq()</para></listitem> | 206 | <listitem><para>enable_irq()</para></listitem> |
207 | <listitem><para>disable_irq_nosync() (SMP only)</para></listitem> | 207 | <listitem><para>disable_irq_nosync() (SMP only)</para></listitem> |
208 | <listitem><para>synchronize_irq() (SMP only)</para></listitem> | 208 | <listitem><para>synchronize_irq() (SMP only)</para></listitem> |
209 | <listitem><para>set_irq_type()</para></listitem> | 209 | <listitem><para>irq_set_irq_type()</para></listitem> |
210 | <listitem><para>set_irq_wake()</para></listitem> | 210 | <listitem><para>irq_set_irq_wake()</para></listitem> |
211 | <listitem><para>set_irq_data()</para></listitem> | 211 | <listitem><para>irq_set_handler_data()</para></listitem> |
212 | <listitem><para>set_irq_chip()</para></listitem> | 212 | <listitem><para>irq_set_chip()</para></listitem> |
213 | <listitem><para>set_irq_chip_data()</para></listitem> | 213 | <listitem><para>irq_set_chip_data()</para></listitem> |
214 | </itemizedlist> | 214 | </itemizedlist> |
215 | See the autogenerated function documentation for details. | 215 | See the autogenerated function documentation for details. |
216 | </para> | 216 | </para> |
@@ -225,6 +225,8 @@ | |||
225 | <listitem><para>handle_fasteoi_irq</para></listitem> | 225 | <listitem><para>handle_fasteoi_irq</para></listitem> |
226 | <listitem><para>handle_simple_irq</para></listitem> | 226 | <listitem><para>handle_simple_irq</para></listitem> |
227 | <listitem><para>handle_percpu_irq</para></listitem> | 227 | <listitem><para>handle_percpu_irq</para></listitem> |
228 | <listitem><para>handle_edge_eoi_irq</para></listitem> | ||
229 | <listitem><para>handle_bad_irq</para></listitem> | ||
228 | </itemizedlist> | 230 | </itemizedlist> |
229 | The interrupt flow handlers (either predefined or architecture | 231 | The interrupt flow handlers (either predefined or architecture |
230 | specific) are assigned to specific interrupts by the architecture | 232 | specific) are assigned to specific interrupts by the architecture |
@@ -241,13 +243,13 @@ | |||
241 | <programlisting> | 243 | <programlisting> |
242 | default_enable(struct irq_data *data) | 244 | default_enable(struct irq_data *data) |
243 | { | 245 | { |
244 | desc->chip->irq_unmask(data); | 246 | desc->irq_data.chip->irq_unmask(data); |
245 | } | 247 | } |
246 | 248 | ||
247 | default_disable(struct irq_data *data) | 249 | default_disable(struct irq_data *data) |
248 | { | 250 | { |
249 | if (!delay_disable(data)) | 251 | if (!delay_disable(data)) |
250 | desc->chip->irq_mask(data); | 252 | desc->irq_data.chip->irq_mask(data); |
251 | } | 253 | } |
252 | 254 | ||
253 | default_ack(struct irq_data *data) | 255 | default_ack(struct irq_data *data) |
@@ -284,9 +286,9 @@ noop(struct irq_data *data)) | |||
284 | <para> | 286 | <para> |
285 | The following control flow is implemented (simplified excerpt): | 287 | The following control flow is implemented (simplified excerpt): |
286 | <programlisting> | 288 | <programlisting> |
287 | desc->chip->irq_mask(); | 289 | desc->irq_data.chip->irq_mask_ack(); |
288 | handle_IRQ_event(desc->action); | 290 | handle_irq_event(desc->action); |
289 | desc->chip->irq_unmask(); | 291 | desc->irq_data.chip->irq_unmask(); |
290 | </programlisting> | 292 | </programlisting> |
291 | </para> | 293 | </para> |
292 | </sect3> | 294 | </sect3> |
@@ -300,8 +302,8 @@ desc->chip->irq_unmask(); | |||
300 | <para> | 302 | <para> |
301 | The following control flow is implemented (simplified excerpt): | 303 | The following control flow is implemented (simplified excerpt): |
302 | <programlisting> | 304 | <programlisting> |
303 | handle_IRQ_event(desc->action); | 305 | handle_irq_event(desc->action); |
304 | desc->chip->irq_eoi(); | 306 | desc->irq_data.chip->irq_eoi(); |
305 | </programlisting> | 307 | </programlisting> |
306 | </para> | 308 | </para> |
307 | </sect3> | 309 | </sect3> |
@@ -315,17 +317,17 @@ desc->chip->irq_eoi(); | |||
315 | The following control flow is implemented (simplified excerpt): | 317 | The following control flow is implemented (simplified excerpt): |
316 | <programlisting> | 318 | <programlisting> |
317 | if (desc->status & running) { | 319 | if (desc->status & running) { |
318 | desc->chip->irq_mask(); | 320 | desc->irq_data.chip->irq_mask_ack(); |
319 | desc->status |= pending | masked; | 321 | desc->status |= pending | masked; |
320 | return; | 322 | return; |
321 | } | 323 | } |
322 | desc->chip->irq_ack(); | 324 | desc->irq_data.chip->irq_ack(); |
323 | desc->status |= running; | 325 | desc->status |= running; |
324 | do { | 326 | do { |
325 | if (desc->status & masked) | 327 | if (desc->status & masked) |
326 | desc->chip->irq_unmask(); | 328 | desc->irq_data.chip->irq_unmask(); |
327 | desc->status &= ~pending; | 329 | desc->status &= ~pending; |
328 | handle_IRQ_event(desc->action); | 330 | handle_irq_event(desc->action); |
329 | } while (status & pending); | 331 | } while (status & pending); |
330 | desc->status &= ~running; | 332 | desc->status &= ~running; |
331 | </programlisting> | 333 | </programlisting> |
@@ -344,7 +346,7 @@ desc->status &= ~running; | |||
344 | <para> | 346 | <para> |
345 | The following control flow is implemented (simplified excerpt): | 347 | The following control flow is implemented (simplified excerpt): |
346 | <programlisting> | 348 | <programlisting> |
347 | handle_IRQ_event(desc->action); | 349 | handle_irq_event(desc->action); |
348 | </programlisting> | 350 | </programlisting> |
349 | </para> | 351 | </para> |
350 | </sect3> | 352 | </sect3> |
@@ -362,12 +364,29 @@ handle_IRQ_event(desc->action); | |||
362 | <para> | 364 | <para> |
363 | The following control flow is implemented (simplified excerpt): | 365 | The following control flow is implemented (simplified excerpt): |
364 | <programlisting> | 366 | <programlisting> |
365 | handle_IRQ_event(desc->action); | 367 | if (desc->irq_data.chip->irq_ack) |
366 | if (desc->chip->irq_eoi) | 368 | desc->irq_data.chip->irq_ack(); |
367 | desc->chip->irq_eoi(); | 369 | handle_irq_event(desc->action); |
370 | if (desc->irq_data.chip->irq_eoi) | ||
371 | desc->irq_data.chip->irq_eoi(); | ||
368 | </programlisting> | 372 | </programlisting> |
369 | </para> | 373 | </para> |
370 | </sect3> | 374 | </sect3> |
375 | <sect3 id="EOI_Edge_IRQ_flow_handler"> | ||
376 | <title>EOI Edge IRQ flow handler</title> | ||
377 | <para> | ||
378 | handle_edge_eoi_irq provides an abnomination of the edge | ||
379 | handler which is solely used to tame a badly wreckaged | ||
380 | irq controller on powerpc/cell. | ||
381 | </para> | ||
382 | </sect3> | ||
383 | <sect3 id="BAD_IRQ_flow_handler"> | ||
384 | <title>Bad IRQ flow handler</title> | ||
385 | <para> | ||
386 | handle_bad_irq is used for spurious interrupts which | ||
387 | have no real handler assigned.. | ||
388 | </para> | ||
389 | </sect3> | ||
371 | </sect2> | 390 | </sect2> |
372 | <sect2 id="Quirks_and_optimizations"> | 391 | <sect2 id="Quirks_and_optimizations"> |
373 | <title>Quirks and optimizations</title> | 392 | <title>Quirks and optimizations</title> |
@@ -410,6 +429,7 @@ if (desc->chip->irq_eoi) | |||
410 | <listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem> | 429 | <listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem> |
411 | <listitem><para>irq_mask()</para></listitem> | 430 | <listitem><para>irq_mask()</para></listitem> |
412 | <listitem><para>irq_unmask()</para></listitem> | 431 | <listitem><para>irq_unmask()</para></listitem> |
432 | <listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem> | ||
413 | <listitem><para>irq_retrigger() - Optional</para></listitem> | 433 | <listitem><para>irq_retrigger() - Optional</para></listitem> |
414 | <listitem><para>irq_set_type() - Optional</para></listitem> | 434 | <listitem><para>irq_set_type() - Optional</para></listitem> |
415 | <listitem><para>irq_set_wake() - Optional</para></listitem> | 435 | <listitem><para>irq_set_wake() - Optional</para></listitem> |
@@ -424,32 +444,24 @@ if (desc->chip->irq_eoi) | |||
424 | <chapter id="doirq"> | 444 | <chapter id="doirq"> |
425 | <title>__do_IRQ entry point</title> | 445 | <title>__do_IRQ entry point</title> |
426 | <para> | 446 | <para> |
427 | The original implementation __do_IRQ() is an alternative entry | 447 | The original implementation __do_IRQ() was an alternative entry |
428 | point for all types of interrupts. | 448 | point for all types of interrupts. It not longer exists. |
429 | </para> | 449 | </para> |
430 | <para> | 450 | <para> |
431 | This handler turned out to be not suitable for all | 451 | This handler turned out to be not suitable for all |
432 | interrupt hardware and was therefore reimplemented with split | 452 | interrupt hardware and was therefore reimplemented with split |
433 | functionality for egde/level/simple/percpu interrupts. This is not | 453 | functionality for edge/level/simple/percpu interrupts. This is not |
434 | only a functional optimization. It also shortens code paths for | 454 | only a functional optimization. It also shortens code paths for |
435 | interrupts. | 455 | interrupts. |
436 | </para> | 456 | </para> |
437 | <para> | ||
438 | To make use of the split implementation, replace the call to | ||
439 | __do_IRQ by a call to desc->handle_irq() and associate | ||
440 | the appropriate handler function to desc->handle_irq(). | ||
441 | In most cases the generic handler implementations should | ||
442 | be sufficient. | ||
443 | </para> | ||
444 | </chapter> | 457 | </chapter> |
445 | 458 | ||
446 | <chapter id="locking"> | 459 | <chapter id="locking"> |
447 | <title>Locking on SMP</title> | 460 | <title>Locking on SMP</title> |
448 | <para> | 461 | <para> |
449 | The locking of chip registers is up to the architecture that | 462 | The locking of chip registers is up to the architecture that |
450 | defines the chip primitives. There is a chip->lock field that can be used | 463 | defines the chip primitives. The per-irq structure is |
451 | for serialization, but the generic layer does not touch it. The per-irq | 464 | protected via desc->lock, by the generic layer. |
452 | structure is protected via desc->lock, by the generic layer. | ||
453 | </para> | 465 | </para> |
454 | </chapter> | 466 | </chapter> |
455 | <chapter id="structs"> | 467 | <chapter id="structs"> |
diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index fea63b45471a..e5fe09430fd9 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl | |||
@@ -270,6 +270,7 @@ | |||
270 | <!ENTITY sub-write SYSTEM "v4l/func-write.xml"> | 270 | <!ENTITY sub-write SYSTEM "v4l/func-write.xml"> |
271 | <!ENTITY sub-io SYSTEM "v4l/io.xml"> | 271 | <!ENTITY sub-io SYSTEM "v4l/io.xml"> |
272 | <!ENTITY sub-grey SYSTEM "v4l/pixfmt-grey.xml"> | 272 | <!ENTITY sub-grey SYSTEM "v4l/pixfmt-grey.xml"> |
273 | <!ENTITY sub-m420 SYSTEM "v4l/pixfmt-m420.xml"> | ||
273 | <!ENTITY sub-nv12 SYSTEM "v4l/pixfmt-nv12.xml"> | 274 | <!ENTITY sub-nv12 SYSTEM "v4l/pixfmt-nv12.xml"> |
274 | <!ENTITY sub-nv12m SYSTEM "v4l/pixfmt-nv12m.xml"> | 275 | <!ENTITY sub-nv12m SYSTEM "v4l/pixfmt-nv12m.xml"> |
275 | <!ENTITY sub-nv12mt SYSTEM "v4l/pixfmt-nv12mt.xml"> | 276 | <!ENTITY sub-nv12mt SYSTEM "v4l/pixfmt-nv12mt.xml"> |
@@ -292,9 +293,11 @@ | |||
292 | <!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> | 293 | <!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> |
293 | <!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> | 294 | <!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> |
294 | <!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml"> | 295 | <!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml"> |
296 | <!ENTITY sub-srggb12 SYSTEM "v4l/pixfmt-srggb12.xml"> | ||
295 | <!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml"> | 297 | <!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml"> |
296 | <!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml"> | 298 | <!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml"> |
297 | <!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml"> | 299 | <!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml"> |
300 | <!ENTITY sub-y10b SYSTEM "v4l/pixfmt-y10b.xml"> | ||
298 | <!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml"> | 301 | <!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml"> |
299 | <!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml"> | 302 | <!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml"> |
300 | <!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml"> | 303 | <!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml"> |
@@ -371,9 +374,9 @@ | |||
371 | <!ENTITY sub-media-indices SYSTEM "media-indices.tmpl"> | 374 | <!ENTITY sub-media-indices SYSTEM "media-indices.tmpl"> |
372 | 375 | ||
373 | <!ENTITY sub-media-controller SYSTEM "v4l/media-controller.xml"> | 376 | <!ENTITY sub-media-controller SYSTEM "v4l/media-controller.xml"> |
374 | <!ENTITY sub-media-open SYSTEM "v4l/media-func-open.xml"> | 377 | <!ENTITY sub-media-func-open SYSTEM "v4l/media-func-open.xml"> |
375 | <!ENTITY sub-media-close SYSTEM "v4l/media-func-close.xml"> | 378 | <!ENTITY sub-media-func-close SYSTEM "v4l/media-func-close.xml"> |
376 | <!ENTITY sub-media-ioctl SYSTEM "v4l/media-func-ioctl.xml"> | 379 | <!ENTITY sub-media-func-ioctl SYSTEM "v4l/media-func-ioctl.xml"> |
377 | <!ENTITY sub-media-ioc-device-info SYSTEM "v4l/media-ioc-device-info.xml"> | 380 | <!ENTITY sub-media-ioc-device-info SYSTEM "v4l/media-ioc-device-info.xml"> |
378 | <!ENTITY sub-media-ioc-enum-entities SYSTEM "v4l/media-ioc-enum-entities.xml"> | 381 | <!ENTITY sub-media-ioc-enum-entities SYSTEM "v4l/media-ioc-enum-entities.xml"> |
379 | <!ENTITY sub-media-ioc-enum-links SYSTEM "v4l/media-ioc-enum-links.xml"> | 382 | <!ENTITY sub-media-ioc-enum-links SYSTEM "v4l/media-ioc-enum-links.xml"> |
diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index 6f242d5dee9a..17910e2052ad 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl | |||
@@ -189,8 +189,7 @@ static void __iomem *baseaddr; | |||
189 | <title>Partition defines</title> | 189 | <title>Partition defines</title> |
190 | <para> | 190 | <para> |
191 | If you want to divide your device into partitions, then | 191 | If you want to divide your device into partitions, then |
192 | enable the configuration switch CONFIG_MTD_PARTITIONS and define | 192 | define a partitioning scheme suitable to your board. |
193 | a partitioning scheme suitable to your board. | ||
194 | </para> | 193 | </para> |
195 | <programlisting> | 194 | <programlisting> |
196 | #define NUM_PARTITIONS 2 | 195 | #define NUM_PARTITIONS 2 |
diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index 2dc25e1d4089..873ac3a621f0 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml | |||
@@ -78,9 +78,9 @@ | |||
78 | <appendix id="media-user-func"> | 78 | <appendix id="media-user-func"> |
79 | <title>Function Reference</title> | 79 | <title>Function Reference</title> |
80 | <!-- Keep this alphabetically sorted. --> | 80 | <!-- Keep this alphabetically sorted. --> |
81 | &sub-media-open; | 81 | &sub-media-func-open; |
82 | &sub-media-close; | 82 | &sub-media-func-close; |
83 | &sub-media-ioctl; | 83 | &sub-media-func-ioctl; |
84 | <!-- All ioctls go here. --> | 84 | <!-- All ioctls go here. --> |
85 | &sub-media-ioc-device-info; | 85 | &sub-media-ioc-device-info; |
86 | &sub-media-ioc-enum-entities; | 86 | &sub-media-ioc-enum-entities; |
diff --git a/Documentation/DocBook/v4l/pixfmt-m420.xml b/Documentation/DocBook/v4l/pixfmt-m420.xml new file mode 100644 index 000000000000..ce4bc019e5c0 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-m420.xml | |||
@@ -0,0 +1,147 @@ | |||
1 | <refentry id="V4L2-PIX-FMT-M420"> | ||
2 | <refmeta> | ||
3 | <refentrytitle>V4L2_PIX_FMT_M420 ('M420')</refentrytitle> | ||
4 | &manvol; | ||
5 | </refmeta> | ||
6 | <refnamediv> | ||
7 | <refname><constant>V4L2_PIX_FMT_M420</constant></refname> | ||
8 | <refpurpose>Format with ½ horizontal and vertical chroma | ||
9 | resolution, also known as YUV 4:2:0. Hybrid plane line-interleaved | ||
10 | layout.</refpurpose> | ||
11 | </refnamediv> | ||
12 | <refsect1> | ||
13 | <title>Description</title> | ||
14 | |||
15 | <para>M420 is a YUV format with ½ horizontal and vertical chroma | ||
16 | subsampling (YUV 4:2:0). Pixels are organized as interleaved luma and | ||
17 | chroma planes. Two lines of luma data are followed by one line of chroma | ||
18 | data.</para> | ||
19 | <para>The luma plane has one byte per pixel. The chroma plane contains | ||
20 | interleaved CbCr pixels subsampled by ½ in the horizontal and | ||
21 | vertical directions. Each CbCr pair belongs to four pixels. For example, | ||
22 | Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to | ||
23 | Y'<subscript>00</subscript>, Y'<subscript>01</subscript>, | ||
24 | Y'<subscript>10</subscript>, Y'<subscript>11</subscript>.</para> | ||
25 | |||
26 | <para>All line lengths are identical: if the Y lines include pad bytes | ||
27 | so do the CbCr lines.</para> | ||
28 | |||
29 | <example> | ||
30 | <title><constant>V4L2_PIX_FMT_M420</constant> 4 × 4 | ||
31 | pixel image</title> | ||
32 | |||
33 | <formalpara> | ||
34 | <title>Byte Order.</title> | ||
35 | <para>Each cell is one byte. | ||
36 | <informaltable frame="none"> | ||
37 | <tgroup cols="5" align="center"> | ||
38 | <colspec align="left" colwidth="2*" /> | ||
39 | <tbody valign="top"> | ||
40 | <row> | ||
41 | <entry>start + 0:</entry> | ||
42 | <entry>Y'<subscript>00</subscript></entry> | ||
43 | <entry>Y'<subscript>01</subscript></entry> | ||
44 | <entry>Y'<subscript>02</subscript></entry> | ||
45 | <entry>Y'<subscript>03</subscript></entry> | ||
46 | </row> | ||
47 | <row> | ||
48 | <entry>start + 4:</entry> | ||
49 | <entry>Y'<subscript>10</subscript></entry> | ||
50 | <entry>Y'<subscript>11</subscript></entry> | ||
51 | <entry>Y'<subscript>12</subscript></entry> | ||
52 | <entry>Y'<subscript>13</subscript></entry> | ||
53 | </row> | ||
54 | <row> | ||
55 | <entry>start + 8:</entry> | ||
56 | <entry>Cb<subscript>00</subscript></entry> | ||
57 | <entry>Cr<subscript>00</subscript></entry> | ||
58 | <entry>Cb<subscript>01</subscript></entry> | ||
59 | <entry>Cr<subscript>01</subscript></entry> | ||
60 | </row> | ||
61 | <row> | ||
62 | <entry>start + 16:</entry> | ||
63 | <entry>Y'<subscript>20</subscript></entry> | ||
64 | <entry>Y'<subscript>21</subscript></entry> | ||
65 | <entry>Y'<subscript>22</subscript></entry> | ||
66 | <entry>Y'<subscript>23</subscript></entry> | ||
67 | </row> | ||
68 | <row> | ||
69 | <entry>start + 20:</entry> | ||
70 | <entry>Y'<subscript>30</subscript></entry> | ||
71 | <entry>Y'<subscript>31</subscript></entry> | ||
72 | <entry>Y'<subscript>32</subscript></entry> | ||
73 | <entry>Y'<subscript>33</subscript></entry> | ||
74 | </row> | ||
75 | <row> | ||
76 | <entry>start + 24:</entry> | ||
77 | <entry>Cb<subscript>10</subscript></entry> | ||
78 | <entry>Cr<subscript>10</subscript></entry> | ||
79 | <entry>Cb<subscript>11</subscript></entry> | ||
80 | <entry>Cr<subscript>11</subscript></entry> | ||
81 | </row> | ||
82 | </tbody> | ||
83 | </tgroup> | ||
84 | </informaltable> | ||
85 | </para> | ||
86 | </formalpara> | ||
87 | |||
88 | <formalpara> | ||
89 | <title>Color Sample Location.</title> | ||
90 | <para> | ||
91 | <informaltable frame="none"> | ||
92 | <tgroup cols="7" align="center"> | ||
93 | <tbody valign="top"> | ||
94 | <row> | ||
95 | <entry></entry> | ||
96 | <entry>0</entry><entry></entry><entry>1</entry><entry></entry> | ||
97 | <entry>2</entry><entry></entry><entry>3</entry> | ||
98 | </row> | ||
99 | <row> | ||
100 | <entry>0</entry> | ||
101 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
102 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
103 | </row> | ||
104 | <row> | ||
105 | <entry></entry> | ||
106 | <entry></entry><entry>C</entry><entry></entry><entry></entry> | ||
107 | <entry></entry><entry>C</entry><entry></entry> | ||
108 | </row> | ||
109 | <row> | ||
110 | <entry>1</entry> | ||
111 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
112 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
113 | </row> | ||
114 | <row> | ||
115 | <entry></entry> | ||
116 | </row> | ||
117 | <row> | ||
118 | <entry>2</entry> | ||
119 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
120 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
121 | </row> | ||
122 | <row> | ||
123 | <entry></entry> | ||
124 | <entry></entry><entry>C</entry><entry></entry><entry></entry> | ||
125 | <entry></entry><entry>C</entry><entry></entry> | ||
126 | </row> | ||
127 | <row> | ||
128 | <entry>3</entry> | ||
129 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
130 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
131 | </row> | ||
132 | </tbody> | ||
133 | </tgroup> | ||
134 | </informaltable> | ||
135 | </para> | ||
136 | </formalpara> | ||
137 | </example> | ||
138 | </refsect1> | ||
139 | </refentry> | ||
140 | |||
141 | <!-- | ||
142 | Local Variables: | ||
143 | mode: sgml | ||
144 | sgml-parent-document: "pixfmt.sgml" | ||
145 | indent-tabs-mode: nil | ||
146 | End: | ||
147 | --> | ||
diff --git a/Documentation/DocBook/v4l/pixfmt-y10b.xml b/Documentation/DocBook/v4l/pixfmt-y10b.xml new file mode 100644 index 000000000000..adb0ad808c93 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-y10b.xml | |||
@@ -0,0 +1,43 @@ | |||
1 | <refentry id="V4L2-PIX-FMT-Y10BPACK"> | ||
2 | <refmeta> | ||
3 | <refentrytitle>V4L2_PIX_FMT_Y10BPACK ('Y10B')</refentrytitle> | ||
4 | &manvol; | ||
5 | </refmeta> | ||
6 | <refnamediv> | ||
7 | <refname><constant>V4L2_PIX_FMT_Y10BPACK</constant></refname> | ||
8 | <refpurpose>Grey-scale image as a bit-packed array</refpurpose> | ||
9 | </refnamediv> | ||
10 | <refsect1> | ||
11 | <title>Description</title> | ||
12 | |||
13 | <para>This is a packed grey-scale image format with a depth of 10 bits per | ||
14 | pixel. Pixels are stored in a bit-packed array of 10bit bits per pixel, | ||
15 | with no padding between them and with the most significant bits coming | ||
16 | first from the left.</para> | ||
17 | |||
18 | <example> | ||
19 | <title><constant>V4L2_PIX_FMT_Y10BPACK</constant> 4 pixel data stream taking 5 bytes</title> | ||
20 | |||
21 | <formalpara> | ||
22 | <title>Bit-packed representation</title> | ||
23 | <para>pixels cross the byte boundary and have a ratio of 5 bytes for each 4 | ||
24 | pixels. | ||
25 | <informaltable frame="all"> | ||
26 | <tgroup cols="5" align="center"> | ||
27 | <colspec align="left" colwidth="2*" /> | ||
28 | <tbody valign="top"> | ||
29 | <row> | ||
30 | <entry>Y'<subscript>00[9:2]</subscript></entry> | ||
31 | <entry>Y'<subscript>00[1:0]</subscript>Y'<subscript>01[9:4]</subscript></entry> | ||
32 | <entry>Y'<subscript>01[3:0]</subscript>Y'<subscript>02[9:6]</subscript></entry> | ||
33 | <entry>Y'<subscript>02[5:0]</subscript>Y'<subscript>03[9:8]</subscript></entry> | ||
34 | <entry>Y'<subscript>03[7:0]</subscript></entry> | ||
35 | </row> | ||
36 | </tbody> | ||
37 | </tgroup> | ||
38 | </informaltable> | ||
39 | </para> | ||
40 | </formalpara> | ||
41 | </example> | ||
42 | </refsect1> | ||
43 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index 40af4beb48b9..deb660207f94 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml | |||
@@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< | |||
673 | &sub-srggb8; | 673 | &sub-srggb8; |
674 | &sub-sbggr16; | 674 | &sub-sbggr16; |
675 | &sub-srggb10; | 675 | &sub-srggb10; |
676 | &sub-srggb12; | ||
676 | </section> | 677 | </section> |
677 | 678 | ||
678 | <section id="yuv-formats"> | 679 | <section id="yuv-formats"> |
@@ -697,6 +698,7 @@ information.</para> | |||
697 | &sub-grey; | 698 | &sub-grey; |
698 | &sub-y10; | 699 | &sub-y10; |
699 | &sub-y12; | 700 | &sub-y12; |
701 | &sub-y10b; | ||
700 | &sub-y16; | 702 | &sub-y16; |
701 | &sub-yuyv; | 703 | &sub-yuyv; |
702 | &sub-uyvy; | 704 | &sub-uyvy; |
@@ -712,6 +714,7 @@ information.</para> | |||
712 | &sub-nv12m; | 714 | &sub-nv12m; |
713 | &sub-nv12mt; | 715 | &sub-nv12mt; |
714 | &sub-nv16; | 716 | &sub-nv16; |
717 | &sub-m420; | ||
715 | </section> | 718 | </section> |
716 | 719 | ||
717 | <section> | 720 | <section> |
diff --git a/Documentation/DocBook/v4l/subdev-formats.xml b/Documentation/DocBook/v4l/subdev-formats.xml index d7ccd25edcc1..8d3409d2c632 100644 --- a/Documentation/DocBook/v4l/subdev-formats.xml +++ b/Documentation/DocBook/v4l/subdev-formats.xml | |||
@@ -2522,5 +2522,51 @@ | |||
2522 | </tgroup> | 2522 | </tgroup> |
2523 | </table> | 2523 | </table> |
2524 | </section> | 2524 | </section> |
2525 | |||
2526 | <section> | ||
2527 | <title>JPEG Compressed Formats</title> | ||
2528 | |||
2529 | <para>Those data formats consist of an ordered sequence of 8-bit bytes | ||
2530 | obtained from JPEG compression process. Additionally to the | ||
2531 | <constant>_JPEG</constant> prefix the format code is made of | ||
2532 | the following information. | ||
2533 | <itemizedlist> | ||
2534 | <listitem><para>The number of bus samples per entropy encoded byte.</para></listitem> | ||
2535 | <listitem><para>The bus width.</para></listitem> | ||
2536 | </itemizedlist> | ||
2537 | </para> | ||
2538 | |||
2539 | <para>For instance, for a JPEG baseline process and an 8-bit bus width | ||
2540 | the format will be named <constant>V4L2_MBUS_FMT_JPEG_1X8</constant>. | ||
2541 | </para> | ||
2542 | |||
2543 | <para>The following table lists existing JPEG compressed formats.</para> | ||
2544 | |||
2545 | <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-jpeg"> | ||
2546 | <title>JPEG Formats</title> | ||
2547 | <tgroup cols="3"> | ||
2548 | <colspec colname="id" align="left" /> | ||
2549 | <colspec colname="code" align="left"/> | ||
2550 | <colspec colname="remarks" align="left"/> | ||
2551 | <thead> | ||
2552 | <row> | ||
2553 | <entry>Identifier</entry> | ||
2554 | <entry>Code</entry> | ||
2555 | <entry>Remarks</entry> | ||
2556 | </row> | ||
2557 | </thead> | ||
2558 | <tbody valign="top"> | ||
2559 | <row id="V4L2-MBUS-FMT-JPEG-1X8"> | ||
2560 | <entry>V4L2_MBUS_FMT_JPEG_1X8</entry> | ||
2561 | <entry>0x4001</entry> | ||
2562 | <entry>Besides of its usage for the parallel bus this format is | ||
2563 | recommended for transmission of JPEG data over MIPI CSI bus | ||
2564 | using the User Defined 8-bit Data types. | ||
2565 | </entry> | ||
2566 | </row> | ||
2567 | </tbody> | ||
2568 | </tgroup> | ||
2569 | </table> | ||
2570 | </section> | ||
2525 | </section> | 2571 | </section> |
2526 | </section> | 2572 | </section> |
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml b/Documentation/DocBook/v4l/videodev2.h.xml index 2b796a2ee98a..c50536a4f596 100644 --- a/Documentation/DocBook/v4l/videodev2.h.xml +++ b/Documentation/DocBook/v4l/videodev2.h.xml | |||
@@ -311,6 +311,9 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> { | |||
311 | #define <link linkend="V4L2-PIX-FMT-Y10">V4L2_PIX_FMT_Y10</link> v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale */ | 311 | #define <link linkend="V4L2-PIX-FMT-Y10">V4L2_PIX_FMT_Y10</link> v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale */ |
312 | #define <link linkend="V4L2-PIX-FMT-Y16">V4L2_PIX_FMT_Y16</link> v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */ | 312 | #define <link linkend="V4L2-PIX-FMT-Y16">V4L2_PIX_FMT_Y16</link> v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */ |
313 | 313 | ||
314 | /* Grey bit-packed formats */ | ||
315 | #define <link linkend="V4L2-PIX-FMT-Y10BPACK">V4L2_PIX_FMT_Y10BPACK</link> v4l2_fourcc('Y', '1', '0', 'B') /* 10 Greyscale bit-packed */ | ||
316 | |||
314 | /* Palette formats */ | 317 | /* Palette formats */ |
315 | #define <link linkend="V4L2-PIX-FMT-PAL8">V4L2_PIX_FMT_PAL8</link> v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit palette */ | 318 | #define <link linkend="V4L2-PIX-FMT-PAL8">V4L2_PIX_FMT_PAL8</link> v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit palette */ |
316 | 319 | ||
@@ -333,6 +336,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> { | |||
333 | #define <link linkend="V4L2-PIX-FMT-YUV420">V4L2_PIX_FMT_YUV420</link> v4l2_fourcc('Y', 'U', '1', '2') /* 12 YUV 4:2:0 */ | 336 | #define <link linkend="V4L2-PIX-FMT-YUV420">V4L2_PIX_FMT_YUV420</link> v4l2_fourcc('Y', 'U', '1', '2') /* 12 YUV 4:2:0 */ |
334 | #define <link linkend="V4L2-PIX-FMT-HI240">V4L2_PIX_FMT_HI240</link> v4l2_fourcc('H', 'I', '2', '4') /* 8 8-bit color */ | 337 | #define <link linkend="V4L2-PIX-FMT-HI240">V4L2_PIX_FMT_HI240</link> v4l2_fourcc('H', 'I', '2', '4') /* 8 8-bit color */ |
335 | #define <link linkend="V4L2-PIX-FMT-HM12">V4L2_PIX_FMT_HM12</link> v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV 4:2:0 16x16 macroblocks */ | 338 | #define <link linkend="V4L2-PIX-FMT-HM12">V4L2_PIX_FMT_HM12</link> v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV 4:2:0 16x16 macroblocks */ |
339 | #define <link linkend="V4L2-PIX-FMT-M420">V4L2_PIX_FMT_M420</link> v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv interleaved */ | ||
336 | 340 | ||
337 | /* two planes -- one Y, one Cr + Cb interleaved */ | 341 | /* two planes -- one Y, one Cr + Cb interleaved */ |
338 | #define <link linkend="V4L2-PIX-FMT-NV12">V4L2_PIX_FMT_NV12</link> v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */ | 342 | #define <link linkend="V4L2-PIX-FMT-NV12">V4L2_PIX_FMT_NV12</link> v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */ |
diff --git a/Documentation/HOWTO b/Documentation/HOWTO index 365bda9a0d94..81bc1a9ab9d8 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO | |||
@@ -209,7 +209,7 @@ tools. One such tool that is particularly recommended is the Linux | |||
209 | Cross-Reference project, which is able to present source code in a | 209 | Cross-Reference project, which is able to present source code in a |
210 | self-referential, indexed webpage format. An excellent up-to-date | 210 | self-referential, indexed webpage format. An excellent up-to-date |
211 | repository of the kernel code may be found at: | 211 | repository of the kernel code may be found at: |
212 | http://users.sosdg.org/~qiyong/lxr/ | 212 | http://lxr.linux.no/+trees |
213 | 213 | ||
214 | 214 | ||
215 | The development process | 215 | The development process |
diff --git a/Documentation/IRQ-affinity.txt b/Documentation/IRQ-affinity.txt index b4a615b78403..7890fae18529 100644 --- a/Documentation/IRQ-affinity.txt +++ b/Documentation/IRQ-affinity.txt | |||
@@ -4,10 +4,11 @@ ChangeLog: | |||
4 | 4 | ||
5 | SMP IRQ affinity | 5 | SMP IRQ affinity |
6 | 6 | ||
7 | /proc/irq/IRQ#/smp_affinity specifies which target CPUs are permitted | 7 | /proc/irq/IRQ#/smp_affinity and /proc/irq/IRQ#/smp_affinity_list specify |
8 | for a given IRQ source. It's a bitmask of allowed CPUs. It's not allowed | 8 | which target CPUs are permitted for a given IRQ source. It's a bitmask |
9 | to turn off all CPUs, and if an IRQ controller does not support IRQ | 9 | (smp_affinity) or cpu list (smp_affinity_list) of allowed CPUs. It's not |
10 | affinity then the value will not change from the default 0xffffffff. | 10 | allowed to turn off all CPUs, and if an IRQ controller does not support |
11 | IRQ affinity then the value will not change from the default of all cpus. | ||
11 | 12 | ||
12 | /proc/irq/default_smp_affinity specifies default affinity mask that applies | 13 | /proc/irq/default_smp_affinity specifies default affinity mask that applies |
13 | to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask | 14 | to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask |
@@ -54,3 +55,11 @@ round-trip min/avg/max = 0.1/0.5/585.4 ms | |||
54 | This time around IRQ44 was delivered only to the last four processors. | 55 | This time around IRQ44 was delivered only to the last four processors. |
55 | i.e counters for the CPU0-3 did not change. | 56 | i.e counters for the CPU0-3 did not change. |
56 | 57 | ||
58 | Here is an example of limiting that same irq (44) to cpus 1024 to 1031: | ||
59 | |||
60 | [root@moon 44]# echo 1024-1031 > smp_affinity | ||
61 | [root@moon 44]# cat smp_affinity | ||
62 | 1024-1031 | ||
63 | |||
64 | Note that to do this with a bitmask would require 32 bitmasks of zero | ||
65 | to follow the pertinent one. | ||
diff --git a/Documentation/RCU/00-INDEX b/Documentation/RCU/00-INDEX index 71b6f500ddb9..1d7a885761f5 100644 --- a/Documentation/RCU/00-INDEX +++ b/Documentation/RCU/00-INDEX | |||
@@ -21,7 +21,7 @@ rcu.txt | |||
21 | RTFP.txt | 21 | RTFP.txt |
22 | - List of RCU papers (bibliography) going back to 1980. | 22 | - List of RCU papers (bibliography) going back to 1980. |
23 | stallwarn.txt | 23 | stallwarn.txt |
24 | - RCU CPU stall warnings (CONFIG_RCU_CPU_STALL_DETECTOR) | 24 | - RCU CPU stall warnings (module parameter rcu_cpu_stall_suppress) |
25 | torture.txt | 25 | torture.txt |
26 | - RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST) | 26 | - RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST) |
27 | trace.txt | 27 | trace.txt |
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index 862c08ef1fde..4e959208f736 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt | |||
@@ -1,22 +1,25 @@ | |||
1 | Using RCU's CPU Stall Detector | 1 | Using RCU's CPU Stall Detector |
2 | 2 | ||
3 | The CONFIG_RCU_CPU_STALL_DETECTOR kernel config parameter enables | 3 | The rcu_cpu_stall_suppress module parameter enables RCU's CPU stall |
4 | RCU's CPU stall detector, which detects conditions that unduly delay | 4 | detector, which detects conditions that unduly delay RCU grace periods. |
5 | RCU grace periods. The stall detector's idea of what constitutes | 5 | This module parameter enables CPU stall detection by default, but |
6 | "unduly delayed" is controlled by a set of C preprocessor macros: | 6 | may be overridden via boot-time parameter or at runtime via sysfs. |
7 | The stall detector's idea of what constitutes "unduly delayed" is | ||
8 | controlled by a set of kernel configuration variables and cpp macros: | ||
7 | 9 | ||
8 | RCU_SECONDS_TILL_STALL_CHECK | 10 | CONFIG_RCU_CPU_STALL_TIMEOUT |
9 | 11 | ||
10 | This macro defines the period of time that RCU will wait from | 12 | This kernel configuration parameter defines the period of time |
11 | the beginning of a grace period until it issues an RCU CPU | 13 | that RCU will wait from the beginning of a grace period until it |
12 | stall warning. This time period is normally ten seconds. | 14 | issues an RCU CPU stall warning. This time period is normally |
15 | ten seconds. | ||
13 | 16 | ||
14 | RCU_SECONDS_TILL_STALL_RECHECK | 17 | RCU_SECONDS_TILL_STALL_RECHECK |
15 | 18 | ||
16 | This macro defines the period of time that RCU will wait after | 19 | This macro defines the period of time that RCU will wait after |
17 | issuing a stall warning until it issues another stall warning | 20 | issuing a stall warning until it issues another stall warning |
18 | for the same stall. This time period is normally set to thirty | 21 | for the same stall. This time period is normally set to three |
19 | seconds. | 22 | times the check interval plus thirty seconds. |
20 | 23 | ||
21 | RCU_STALL_RAT_DELAY | 24 | RCU_STALL_RAT_DELAY |
22 | 25 | ||
diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt index 6a8c73f55b80..8173cec473aa 100644 --- a/Documentation/RCU/trace.txt +++ b/Documentation/RCU/trace.txt | |||
@@ -10,34 +10,46 @@ for rcutree and next for rcutiny. | |||
10 | 10 | ||
11 | CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats | 11 | CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats |
12 | 12 | ||
13 | These implementations of RCU provides five debugfs files under the | 13 | These implementations of RCU provides several debugfs files under the |
14 | top-level directory RCU: rcu/rcudata (which displays fields in struct | 14 | top-level directory "rcu": |
15 | rcu_data), rcu/rcudata.csv (which is a .csv spreadsheet version of | 15 | |
16 | rcu/rcudata), rcu/rcugp (which displays grace-period counters), | 16 | rcu/rcudata: |
17 | rcu/rcuhier (which displays the struct rcu_node hierarchy), and | 17 | Displays fields in struct rcu_data. |
18 | rcu/rcu_pending (which displays counts of the reasons that the | 18 | rcu/rcudata.csv: |
19 | rcu_pending() function decided that there was core RCU work to do). | 19 | Comma-separated values spreadsheet version of rcudata. |
20 | rcu/rcugp: | ||
21 | Displays grace-period counters. | ||
22 | rcu/rcuhier: | ||
23 | Displays the struct rcu_node hierarchy. | ||
24 | rcu/rcu_pending: | ||
25 | Displays counts of the reasons rcu_pending() decided that RCU had | ||
26 | work to do. | ||
27 | rcu/rcutorture: | ||
28 | Displays rcutorture test progress. | ||
29 | rcu/rcuboost: | ||
30 | Displays RCU boosting statistics. Only present if | ||
31 | CONFIG_RCU_BOOST=y. | ||
20 | 32 | ||
21 | The output of "cat rcu/rcudata" looks as follows: | 33 | The output of "cat rcu/rcudata" looks as follows: |
22 | 34 | ||
23 | rcu_sched: | 35 | rcu_sched: |
24 | 0 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=10951/1 dn=0 df=1101 of=0 ri=36 ql=0 b=10 | 36 | 0 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=545/1/0 df=50 of=0 ri=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0 |
25 | 1 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=16117/1 dn=0 df=1015 of=0 ri=0 ql=0 b=10 | 37 | 1 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=967/1/0 df=58 of=0 ri=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0 |
26 | 2 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1445/1 dn=0 df=1839 of=0 ri=0 ql=0 b=10 | 38 | 2 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1081/1/0 df=175 of=0 ri=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0 |
27 | 3 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=6681/1 dn=0 df=1545 of=0 ri=0 ql=0 b=10 | 39 | 3 c=20942 g=20943 pq=1 pqc=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0 |
28 | 4 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1003/1 dn=0 df=1992 of=0 ri=0 ql=0 b=10 | 40 | 4 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=369/1/0 df=83 of=0 ri=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0 |
29 | 5 c=17829 g=17830 pq=1 pqc=17829 qp=1 dt=3887/1 dn=0 df=3331 of=0 ri=4 ql=2 b=10 | 41 | 5 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=381/1/0 df=64 of=0 ri=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0 |
30 | 6 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=859/1 dn=0 df=3224 of=0 ri=0 ql=0 b=10 | 42 | 6 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1037/1/0 df=183 of=0 ri=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0 |
31 | 7 c=17829 g=17830 pq=0 pqc=17829 qp=1 dt=3761/1 dn=0 df=1818 of=0 ri=0 ql=2 b=10 | 43 | 7 c=20897 g=20897 pq=1 pqc=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0 |
32 | rcu_bh: | 44 | rcu_bh: |
33 | 0 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=10951/1 dn=0 df=0 of=0 ri=0 ql=0 b=10 | 45 | 0 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0 |
34 | 1 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=16117/1 dn=0 df=13 of=0 ri=0 ql=0 b=10 | 46 | 1 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0 |
35 | 2 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1445/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 | 47 | 2 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0 |
36 | 3 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=6681/1 dn=0 df=9 of=0 ri=0 ql=0 b=10 | 48 | 3 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0 |
37 | 4 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1003/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 | 49 | 4 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0 |
38 | 5 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3887/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 | 50 | 5 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0 |
39 | 6 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=859/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 | 51 | 6 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0 |
40 | 7 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3761/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 | 52 | 7 c=1474 g=1474 pq=1 pqc=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0 |
41 | 53 | ||
42 | The first section lists the rcu_data structures for rcu_sched, the second | 54 | The first section lists the rcu_data structures for rcu_sched, the second |
43 | for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an | 55 | for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an |
@@ -52,17 +64,18 @@ o The number at the beginning of each line is the CPU number. | |||
52 | substantially larger than the number of actual CPUs. | 64 | substantially larger than the number of actual CPUs. |
53 | 65 | ||
54 | o "c" is the count of grace periods that this CPU believes have | 66 | o "c" is the count of grace periods that this CPU believes have |
55 | completed. CPUs in dynticks idle mode may lag quite a ways | 67 | completed. Offlined CPUs and CPUs in dynticks idle mode may |
56 | behind, for example, CPU 4 under "rcu_sched" above, which has | 68 | lag quite a ways behind, for example, CPU 6 under "rcu_sched" |
57 | slept through the past 25 RCU grace periods. It is not unusual | 69 | above, which has been offline through not quite 40,000 RCU grace |
58 | to see CPUs lagging by thousands of grace periods. | 70 | periods. It is not unusual to see CPUs lagging by thousands of |
71 | grace periods. | ||
59 | 72 | ||
60 | o "g" is the count of grace periods that this CPU believes have | 73 | o "g" is the count of grace periods that this CPU believes have |
61 | started. Again, CPUs in dynticks idle mode may lag behind. | 74 | started. Again, offlined CPUs and CPUs in dynticks idle mode |
62 | If the "c" and "g" values are equal, this CPU has already | 75 | may lag behind. If the "c" and "g" values are equal, this CPU |
63 | reported a quiescent state for the last RCU grace period that | 76 | has already reported a quiescent state for the last RCU grace |
64 | it is aware of, otherwise, the CPU believes that it owes RCU a | 77 | period that it is aware of, otherwise, the CPU believes that it |
65 | quiescent state. | 78 | owes RCU a quiescent state. |
66 | 79 | ||
67 | o "pq" indicates that this CPU has passed through a quiescent state | 80 | o "pq" indicates that this CPU has passed through a quiescent state |
68 | for the current grace period. It is possible for "pq" to be | 81 | for the current grace period. It is possible for "pq" to be |
@@ -81,22 +94,16 @@ o "pqc" indicates which grace period the last-observed quiescent | |||
81 | the next grace period! | 94 | the next grace period! |
82 | 95 | ||
83 | o "qp" indicates that RCU still expects a quiescent state from | 96 | o "qp" indicates that RCU still expects a quiescent state from |
84 | this CPU. | 97 | this CPU. Offlined CPUs and CPUs in dyntick idle mode might |
98 | well have qp=1, which is OK: RCU is still ignoring them. | ||
85 | 99 | ||
86 | o "dt" is the current value of the dyntick counter that is incremented | 100 | o "dt" is the current value of the dyntick counter that is incremented |
87 | when entering or leaving dynticks idle state, either by the | 101 | when entering or leaving dynticks idle state, either by the |
88 | scheduler or by irq. The number after the "/" is the interrupt | 102 | scheduler or by irq. This number is even if the CPU is in |
89 | nesting depth when in dyntick-idle state, or one greater than | 103 | dyntick idle mode and odd otherwise. The number after the first |
90 | the interrupt-nesting depth otherwise. | 104 | "/" is the interrupt nesting depth when in dyntick-idle state, |
91 | 105 | or one greater than the interrupt-nesting depth otherwise. | |
92 | This field is displayed only for CONFIG_NO_HZ kernels. | 106 | The number after the second "/" is the NMI nesting depth. |
93 | |||
94 | o "dn" is the current value of the dyntick counter that is incremented | ||
95 | when entering or leaving dynticks idle state via NMI. If both | ||
96 | the "dt" and "dn" values are even, then this CPU is in dynticks | ||
97 | idle mode and may be ignored by RCU. If either of these two | ||
98 | counters is odd, then RCU must be alert to the possibility of | ||
99 | an RCU read-side critical section running on this CPU. | ||
100 | 107 | ||
101 | This field is displayed only for CONFIG_NO_HZ kernels. | 108 | This field is displayed only for CONFIG_NO_HZ kernels. |
102 | 109 | ||
@@ -108,7 +115,7 @@ o "df" is the number of times that some other CPU has forced a | |||
108 | 115 | ||
109 | o "of" is the number of times that some other CPU has forced a | 116 | o "of" is the number of times that some other CPU has forced a |
110 | quiescent state on behalf of this CPU due to this CPU being | 117 | quiescent state on behalf of this CPU due to this CPU being |
111 | offline. In a perfect world, this might neve happen, but it | 118 | offline. In a perfect world, this might never happen, but it |
112 | turns out that offlining and onlining a CPU can take several grace | 119 | turns out that offlining and onlining a CPU can take several grace |
113 | periods, and so there is likely to be an extended period of time | 120 | periods, and so there is likely to be an extended period of time |
114 | when RCU believes that the CPU is online when it really is not. | 121 | when RCU believes that the CPU is online when it really is not. |
@@ -125,6 +132,62 @@ o "ql" is the number of RCU callbacks currently residing on | |||
125 | of what state they are in (new, waiting for grace period to | 132 | of what state they are in (new, waiting for grace period to |
126 | start, waiting for grace period to end, ready to invoke). | 133 | start, waiting for grace period to end, ready to invoke). |
127 | 134 | ||
135 | o "qs" gives an indication of the state of the callback queue | ||
136 | with four characters: | ||
137 | |||
138 | "N" Indicates that there are callbacks queued that are not | ||
139 | ready to be handled by the next grace period, and thus | ||
140 | will be handled by the grace period following the next | ||
141 | one. | ||
142 | |||
143 | "R" Indicates that there are callbacks queued that are | ||
144 | ready to be handled by the next grace period. | ||
145 | |||
146 | "W" Indicates that there are callbacks queued that are | ||
147 | waiting on the current grace period. | ||
148 | |||
149 | "D" Indicates that there are callbacks queued that have | ||
150 | already been handled by a prior grace period, and are | ||
151 | thus waiting to be invoked. Note that callbacks in | ||
152 | the process of being invoked are not counted here. | ||
153 | Callbacks in the process of being invoked are those | ||
154 | that have been removed from the rcu_data structures | ||
155 | queues by rcu_do_batch(), but which have not yet been | ||
156 | invoked. | ||
157 | |||
158 | If there are no callbacks in a given one of the above states, | ||
159 | the corresponding character is replaced by ".". | ||
160 | |||
161 | o "kt" is the per-CPU kernel-thread state. The digit preceding | ||
162 | the first slash is zero if there is no work pending and 1 | ||
163 | otherwise. The character between the first pair of slashes is | ||
164 | as follows: | ||
165 | |||
166 | "S" The kernel thread is stopped, in other words, all | ||
167 | CPUs corresponding to this rcu_node structure are | ||
168 | offline. | ||
169 | |||
170 | "R" The kernel thread is running. | ||
171 | |||
172 | "W" The kernel thread is waiting because there is no work | ||
173 | for it to do. | ||
174 | |||
175 | "O" The kernel thread is waiting because it has been | ||
176 | forced off of its designated CPU or because its | ||
177 | ->cpus_allowed mask permits it to run on other than | ||
178 | its designated CPU. | ||
179 | |||
180 | "Y" The kernel thread is yielding to avoid hogging CPU. | ||
181 | |||
182 | "?" Unknown value, indicates a bug. | ||
183 | |||
184 | The number after the final slash is the CPU that the kthread | ||
185 | is actually running on. | ||
186 | |||
187 | o "ktl" is the low-order 16 bits (in hexadecimal) of the count of | ||
188 | the number of times that this CPU's per-CPU kthread has gone | ||
189 | through its loop servicing invoke_rcu_cpu_kthread() requests. | ||
190 | |||
128 | o "b" is the batch limit for this CPU. If more than this number | 191 | o "b" is the batch limit for this CPU. If more than this number |
129 | of RCU callbacks is ready to invoke, then the remainder will | 192 | of RCU callbacks is ready to invoke, then the remainder will |
130 | be deferred. | 193 | be deferred. |
@@ -174,14 +237,14 @@ o "gpnum" is the number of grace periods that have started. It is | |||
174 | The output of "cat rcu/rcuhier" looks as follows, with very long lines: | 237 | The output of "cat rcu/rcuhier" looks as follows, with very long lines: |
175 | 238 | ||
176 | c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 | 239 | c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 |
177 | 1/1 .>. 0:127 ^0 | 240 | 1/1 ..>. 0:127 ^0 |
178 | 3/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3 | 241 | 3/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3 |
179 | 3/3f .>. 0:5 ^0 2/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3 | 242 | 3/3f ..>. 0:5 ^0 2/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3 |
180 | rcu_bh: | 243 | rcu_bh: |
181 | c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 | 244 | c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 |
182 | 0/1 .>. 0:127 ^0 | 245 | 0/1 ..>. 0:127 ^0 |
183 | 0/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3 | 246 | 0/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3 |
184 | 0/3f .>. 0:5 ^0 0/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3 | 247 | 0/3f ..>. 0:5 ^0 0/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3 |
185 | 248 | ||
186 | This is once again split into "rcu_sched" and "rcu_bh" portions, | 249 | This is once again split into "rcu_sched" and "rcu_bh" portions, |
187 | and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional | 250 | and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional |
@@ -240,13 +303,20 @@ o Each element of the form "1/1 0:127 ^0" represents one struct | |||
240 | current grace period. | 303 | current grace period. |
241 | 304 | ||
242 | o The characters separated by the ">" indicate the state | 305 | o The characters separated by the ">" indicate the state |
243 | of the blocked-tasks lists. A "T" preceding the ">" | 306 | of the blocked-tasks lists. A "G" preceding the ">" |
244 | indicates that at least one task blocked in an RCU | 307 | indicates that at least one task blocked in an RCU |
245 | read-side critical section blocks the current grace | 308 | read-side critical section blocks the current grace |
246 | period, while a "." preceding the ">" indicates otherwise. | 309 | period, while a "E" preceding the ">" indicates that |
247 | The character following the ">" indicates similarly for | 310 | at least one task blocked in an RCU read-side critical |
248 | the next grace period. A "T" should appear in this | 311 | section blocks the current expedited grace period. |
249 | field only for rcu-preempt. | 312 | A "T" character following the ">" indicates that at |
313 | least one task is blocked within an RCU read-side | ||
314 | critical section, regardless of whether any current | ||
315 | grace period (expedited or normal) is inconvenienced. | ||
316 | A "." character appears if the corresponding condition | ||
317 | does not hold, so that "..>." indicates that no tasks | ||
318 | are blocked. In contrast, "GE>T" indicates maximal | ||
319 | inconvenience from blocked tasks. | ||
250 | 320 | ||
251 | o The numbers separated by the ":" are the range of CPUs | 321 | o The numbers separated by the ":" are the range of CPUs |
252 | served by this struct rcu_node. This can be helpful | 322 | served by this struct rcu_node. This can be helpful |
@@ -328,6 +398,113 @@ o "nn" is the number of times that this CPU needed nothing. Alert | |||
328 | is due to short-circuit evaluation in rcu_pending(). | 398 | is due to short-circuit evaluation in rcu_pending(). |
329 | 399 | ||
330 | 400 | ||
401 | The output of "cat rcu/rcutorture" looks as follows: | ||
402 | |||
403 | rcutorture test sequence: 0 (test in progress) | ||
404 | rcutorture update version number: 615 | ||
405 | |||
406 | The first line shows the number of rcutorture tests that have completed | ||
407 | since boot. If a test is currently running, the "(test in progress)" | ||
408 | string will appear as shown above. The second line shows the number of | ||
409 | update cycles that the current test has started, or zero if there is | ||
410 | no test in progress. | ||
411 | |||
412 | |||
413 | The output of "cat rcu/rcuboost" looks as follows: | ||
414 | |||
415 | 0:5 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f | ||
416 | balk: nt=0 egt=989 bt=0 nb=0 ny=0 nos=16 | ||
417 | 6:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f | ||
418 | balk: nt=0 egt=225 bt=0 nb=0 ny=0 nos=6 | ||
419 | |||
420 | This information is output only for rcu_preempt. Each two-line entry | ||
421 | corresponds to a leaf rcu_node strcuture. The fields are as follows: | ||
422 | |||
423 | o "n:m" is the CPU-number range for the corresponding two-line | ||
424 | entry. In the sample output above, the first entry covers | ||
425 | CPUs zero through five and the second entry covers CPUs 6 | ||
426 | and 7. | ||
427 | |||
428 | o "tasks=TNEB" gives the state of the various segments of the | ||
429 | rnp->blocked_tasks list: | ||
430 | |||
431 | "T" This indicates that there are some tasks that blocked | ||
432 | while running on one of the corresponding CPUs while | ||
433 | in an RCU read-side critical section. | ||
434 | |||
435 | "N" This indicates that some of the blocked tasks are preventing | ||
436 | the current normal (non-expedited) grace period from | ||
437 | completing. | ||
438 | |||
439 | "E" This indicates that some of the blocked tasks are preventing | ||
440 | the current expedited grace period from completing. | ||
441 | |||
442 | "B" This indicates that some of the blocked tasks are in | ||
443 | need of RCU priority boosting. | ||
444 | |||
445 | Each character is replaced with "." if the corresponding | ||
446 | condition does not hold. | ||
447 | |||
448 | o "kt" is the state of the RCU priority-boosting kernel | ||
449 | thread associated with the corresponding rcu_node structure. | ||
450 | The state can be one of the following: | ||
451 | |||
452 | "S" The kernel thread is stopped, in other words, all | ||
453 | CPUs corresponding to this rcu_node structure are | ||
454 | offline. | ||
455 | |||
456 | "R" The kernel thread is running. | ||
457 | |||
458 | "W" The kernel thread is waiting because there is no work | ||
459 | for it to do. | ||
460 | |||
461 | "Y" The kernel thread is yielding to avoid hogging CPU. | ||
462 | |||
463 | "?" Unknown value, indicates a bug. | ||
464 | |||
465 | o "ntb" is the number of tasks boosted. | ||
466 | |||
467 | o "neb" is the number of tasks boosted in order to complete an | ||
468 | expedited grace period. | ||
469 | |||
470 | o "nnb" is the number of tasks boosted in order to complete a | ||
471 | normal (non-expedited) grace period. When boosting a task | ||
472 | that was blocking both an expedited and a normal grace period, | ||
473 | it is counted against the expedited total above. | ||
474 | |||
475 | o "j" is the low-order 16 bits of the jiffies counter in | ||
476 | hexadecimal. | ||
477 | |||
478 | o "bt" is the low-order 16 bits of the value that the jiffies | ||
479 | counter will have when we next start boosting, assuming that | ||
480 | the current grace period does not end beforehand. This is | ||
481 | also in hexadecimal. | ||
482 | |||
483 | o "balk: nt" counts the number of times we didn't boost (in | ||
484 | other words, we balked) even though it was time to boost because | ||
485 | there were no blocked tasks to boost. This situation occurs | ||
486 | when there is one blocked task on one rcu_node structure and | ||
487 | none on some other rcu_node structure. | ||
488 | |||
489 | o "egt" counts the number of times we balked because although | ||
490 | there were blocked tasks, none of them were blocking the | ||
491 | current grace period, whether expedited or otherwise. | ||
492 | |||
493 | o "bt" counts the number of times we balked because boosting | ||
494 | had already been initiated for the current grace period. | ||
495 | |||
496 | o "nb" counts the number of times we balked because there | ||
497 | was at least one task blocking the current non-expedited grace | ||
498 | period that never had blocked. If it is already running, it | ||
499 | just won't help to boost its priority! | ||
500 | |||
501 | o "ny" counts the number of times we balked because it was | ||
502 | not yet time to start boosting. | ||
503 | |||
504 | o "nos" counts the number of times we balked for other | ||
505 | reasons, e.g., the grace period ended first. | ||
506 | |||
507 | |||
331 | CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats | 508 | CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats |
332 | 509 | ||
333 | These implementations of RCU provides a single debugfs file under the | 510 | These implementations of RCU provides a single debugfs file under the |
@@ -394,9 +571,9 @@ o "neb" is the number of expedited grace periods that have had | |||
394 | o "nnb" is the number of normal grace periods that have had | 571 | o "nnb" is the number of normal grace periods that have had |
395 | to resort to RCU priority boosting since boot. | 572 | to resort to RCU priority boosting since boot. |
396 | 573 | ||
397 | o "j" is the low-order 12 bits of the jiffies counter in hexadecimal. | 574 | o "j" is the low-order 16 bits of the jiffies counter in hexadecimal. |
398 | 575 | ||
399 | o "bt" is the low-order 12 bits of the value that the jiffies counter | 576 | o "bt" is the low-order 16 bits of the value that the jiffies counter |
400 | will have at the next time that boosting is scheduled to begin. | 577 | will have at the next time that boosting is scheduled to begin. |
401 | 578 | ||
402 | o In the line beginning with "normal balk", the fields are as follows: | 579 | o In the line beginning with "normal balk", the fields are as follows: |
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index e439cd0d3375..569f3532e138 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches | |||
@@ -714,10 +714,11 @@ Jeff Garzik, "Linux kernel patch submission format". | |||
714 | <http://linux.yyz.us/patch-format.html> | 714 | <http://linux.yyz.us/patch-format.html> |
715 | 715 | ||
716 | Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". | 716 | Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". |
717 | <http://www.kroah.com/log/2005/03/31/> | 717 | <http://www.kroah.com/log/linux/maintainer.html> |
718 | <http://www.kroah.com/log/2005/07/08/> | 718 | <http://www.kroah.com/log/linux/maintainer-02.html> |
719 | <http://www.kroah.com/log/2005/10/19/> | 719 | <http://www.kroah.com/log/linux/maintainer-03.html> |
720 | <http://www.kroah.com/log/2006/01/11/> | 720 | <http://www.kroah.com/log/linux/maintainer-04.html> |
721 | <http://www.kroah.com/log/linux/maintainer-05.html> | ||
721 | 722 | ||
722 | NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! | 723 | NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! |
723 | <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> | 724 | <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> |
diff --git a/Documentation/accounting/cgroupstats.txt b/Documentation/accounting/cgroupstats.txt index eda40fd39cad..d16a9849e60e 100644 --- a/Documentation/accounting/cgroupstats.txt +++ b/Documentation/accounting/cgroupstats.txt | |||
@@ -21,7 +21,7 @@ information will not be available. | |||
21 | To extract cgroup statistics a utility very similar to getdelays.c | 21 | To extract cgroup statistics a utility very similar to getdelays.c |
22 | has been developed, the sample output of the utility is shown below | 22 | has been developed, the sample output of the utility is shown below |
23 | 23 | ||
24 | ~/balbir/cgroupstats # ./getdelays -C "/cgroup/a" | 24 | ~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup/a" |
25 | sleeping 1, blocked 0, running 1, stopped 0, uninterruptible 0 | 25 | sleeping 1, blocked 0, running 1, stopped 0, uninterruptible 0 |
26 | ~/balbir/cgroupstats # ./getdelays -C "/cgroup" | 26 | ~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup" |
27 | sleeping 155, blocked 0, running 1, stopped 0, uninterruptible 2 | 27 | sleeping 155, blocked 0, running 1, stopped 0, uninterruptible 2 |
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index e9c77788a39d..f6318f6d7baf 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c | |||
@@ -177,6 +177,8 @@ static int get_family_id(int sd) | |||
177 | rc = send_cmd(sd, GENL_ID_CTRL, getpid(), CTRL_CMD_GETFAMILY, | 177 | rc = send_cmd(sd, GENL_ID_CTRL, getpid(), CTRL_CMD_GETFAMILY, |
178 | CTRL_ATTR_FAMILY_NAME, (void *)name, | 178 | CTRL_ATTR_FAMILY_NAME, (void *)name, |
179 | strlen(TASKSTATS_GENL_NAME)+1); | 179 | strlen(TASKSTATS_GENL_NAME)+1); |
180 | if (rc < 0) | ||
181 | return 0; /* sendto() failure? */ | ||
180 | 182 | ||
181 | rep_len = recv(sd, &ans, sizeof(ans), 0); | 183 | rep_len = recv(sd, &ans, sizeof(ans), 0); |
182 | if (ans.n.nlmsg_type == NLMSG_ERROR || | 184 | if (ans.n.nlmsg_type == NLMSG_ERROR || |
@@ -191,30 +193,37 @@ static int get_family_id(int sd) | |||
191 | return id; | 193 | return id; |
192 | } | 194 | } |
193 | 195 | ||
196 | #define average_ms(t, c) (t / 1000000ULL / (c ? c : 1)) | ||
197 | |||
194 | static void print_delayacct(struct taskstats *t) | 198 | static void print_delayacct(struct taskstats *t) |
195 | { | 199 | { |
196 | printf("\n\nCPU %15s%15s%15s%15s\n" | 200 | printf("\n\nCPU %15s%15s%15s%15s%15s\n" |
197 | " %15llu%15llu%15llu%15llu\n" | 201 | " %15llu%15llu%15llu%15llu%15.3fms\n" |
198 | "IO %15s%15s\n" | 202 | "IO %15s%15s%15s\n" |
199 | " %15llu%15llu\n" | 203 | " %15llu%15llu%15llums\n" |
200 | "SWAP %15s%15s\n" | 204 | "SWAP %15s%15s%15s\n" |
201 | " %15llu%15llu\n" | 205 | " %15llu%15llu%15llums\n" |
202 | "RECLAIM %12s%15s\n" | 206 | "RECLAIM %12s%15s%15s\n" |
203 | " %15llu%15llu\n", | 207 | " %15llu%15llu%15llums\n", |
204 | "count", "real total", "virtual total", "delay total", | 208 | "count", "real total", "virtual total", |
209 | "delay total", "delay average", | ||
205 | (unsigned long long)t->cpu_count, | 210 | (unsigned long long)t->cpu_count, |
206 | (unsigned long long)t->cpu_run_real_total, | 211 | (unsigned long long)t->cpu_run_real_total, |
207 | (unsigned long long)t->cpu_run_virtual_total, | 212 | (unsigned long long)t->cpu_run_virtual_total, |
208 | (unsigned long long)t->cpu_delay_total, | 213 | (unsigned long long)t->cpu_delay_total, |
209 | "count", "delay total", | 214 | average_ms((double)t->cpu_delay_total, t->cpu_count), |
215 | "count", "delay total", "delay average", | ||
210 | (unsigned long long)t->blkio_count, | 216 | (unsigned long long)t->blkio_count, |
211 | (unsigned long long)t->blkio_delay_total, | 217 | (unsigned long long)t->blkio_delay_total, |
212 | "count", "delay total", | 218 | average_ms(t->blkio_delay_total, t->blkio_count), |
219 | "count", "delay total", "delay average", | ||
213 | (unsigned long long)t->swapin_count, | 220 | (unsigned long long)t->swapin_count, |
214 | (unsigned long long)t->swapin_delay_total, | 221 | (unsigned long long)t->swapin_delay_total, |
215 | "count", "delay total", | 222 | average_ms(t->swapin_delay_total, t->swapin_count), |
223 | "count", "delay total", "delay average", | ||
216 | (unsigned long long)t->freepages_count, | 224 | (unsigned long long)t->freepages_count, |
217 | (unsigned long long)t->freepages_delay_total); | 225 | (unsigned long long)t->freepages_delay_total, |
226 | average_ms(t->freepages_delay_total, t->freepages_count)); | ||
218 | } | 227 | } |
219 | 228 | ||
220 | static void task_context_switch_counts(struct taskstats *t) | 229 | static void task_context_switch_counts(struct taskstats *t) |
@@ -433,8 +442,6 @@ int main(int argc, char *argv[]) | |||
433 | } | 442 | } |
434 | 443 | ||
435 | do { | 444 | do { |
436 | int i; | ||
437 | |||
438 | rep_len = recv(nl_sd, &msg, sizeof(msg), 0); | 445 | rep_len = recv(nl_sd, &msg, sizeof(msg), 0); |
439 | PRINTF("received %d bytes\n", rep_len); | 446 | PRINTF("received %d bytes\n", rep_len); |
440 | 447 | ||
@@ -459,7 +466,6 @@ int main(int argc, char *argv[]) | |||
459 | 466 | ||
460 | na = (struct nlattr *) GENLMSG_DATA(&msg); | 467 | na = (struct nlattr *) GENLMSG_DATA(&msg); |
461 | len = 0; | 468 | len = 0; |
462 | i = 0; | ||
463 | while (len < rep_len) { | 469 | while (len < rep_len) { |
464 | len += NLA_ALIGN(na->nla_len); | 470 | len += NLA_ALIGN(na->nla_len); |
465 | switch (na->nla_type) { | 471 | switch (na->nla_type) { |
diff --git a/Documentation/acpi/method-customizing.txt b/Documentation/acpi/method-customizing.txt index 3e1d25aee3fb..5f55373dd53b 100644 --- a/Documentation/acpi/method-customizing.txt +++ b/Documentation/acpi/method-customizing.txt | |||
@@ -66,3 +66,8 @@ Note: We can use a kernel with multiple custom ACPI method running, | |||
66 | But each individual write to debugfs can implement a SINGLE | 66 | But each individual write to debugfs can implement a SINGLE |
67 | method override. i.e. if we want to insert/override multiple | 67 | method override. i.e. if we want to insert/override multiple |
68 | ACPI methods, we need to redo step c) ~ g) for multiple times. | 68 | ACPI methods, we need to redo step c) ~ g) for multiple times. |
69 | |||
70 | Note: Be aware that root can mis-use this driver to modify arbitrary | ||
71 | memory and gain additional rights, if root's privileges got | ||
72 | restricted (for example if root is not allowed to load additional | ||
73 | modules after boot). | ||
diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting index 76850295af8f..4e686a2ed91e 100644 --- a/Documentation/arm/Booting +++ b/Documentation/arm/Booting | |||
@@ -65,13 +65,19 @@ looks at the connected hardware is beyond the scope of this document. | |||
65 | The boot loader must ultimately be able to provide a MACH_TYPE_xxx | 65 | The boot loader must ultimately be able to provide a MACH_TYPE_xxx |
66 | value to the kernel. (see linux/arch/arm/tools/mach-types). | 66 | value to the kernel. (see linux/arch/arm/tools/mach-types). |
67 | 67 | ||
68 | 68 | 4. Setup boot data | |
69 | 4. Setup the kernel tagged list | 69 | ------------------ |
70 | ------------------------------- | ||
71 | 70 | ||
72 | Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED | 71 | Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED |
73 | New boot loaders: MANDATORY | 72 | New boot loaders: MANDATORY |
74 | 73 | ||
74 | The boot loader must provide either a tagged list or a dtb image for | ||
75 | passing configuration data to the kernel. The physical address of the | ||
76 | boot data is passed to the kernel in register r2. | ||
77 | |||
78 | 4a. Setup the kernel tagged list | ||
79 | -------------------------------- | ||
80 | |||
75 | The boot loader must create and initialise the kernel tagged list. | 81 | The boot loader must create and initialise the kernel tagged list. |
76 | A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. | 82 | A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. |
77 | The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag | 83 | The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag |
@@ -101,6 +107,24 @@ The tagged list must be placed in a region of memory where neither | |||
101 | the kernel decompressor nor initrd 'bootp' program will overwrite | 107 | the kernel decompressor nor initrd 'bootp' program will overwrite |
102 | it. The recommended placement is in the first 16KiB of RAM. | 108 | it. The recommended placement is in the first 16KiB of RAM. |
103 | 109 | ||
110 | 4b. Setup the device tree | ||
111 | ------------------------- | ||
112 | |||
113 | The boot loader must load a device tree image (dtb) into system ram | ||
114 | at a 64bit aligned address and initialize it with the boot data. The | ||
115 | dtb format is documented in Documentation/devicetree/booting-without-of.txt. | ||
116 | The kernel will look for the dtb magic value of 0xd00dfeed at the dtb | ||
117 | physical address to determine if a dtb has been passed instead of a | ||
118 | tagged list. | ||
119 | |||
120 | The boot loader must pass at a minimum the size and location of the | ||
121 | system memory, and the root filesystem location. The dtb must be | ||
122 | placed in a region of memory where the kernel decompressor will not | ||
123 | overwrite it. The recommended placement is in the first 16KiB of RAM | ||
124 | with the caveat that it may not be located at physical address 0 since | ||
125 | the kernel interprets a value of 0 in r2 to mean neither a tagged list | ||
126 | nor a dtb were passed. | ||
127 | |||
104 | 5. Calling the kernel image | 128 | 5. Calling the kernel image |
105 | --------------------------- | 129 | --------------------------- |
106 | 130 | ||
@@ -125,7 +149,8 @@ In either case, the following conditions must be met: | |||
125 | - CPU register settings | 149 | - CPU register settings |
126 | r0 = 0, | 150 | r0 = 0, |
127 | r1 = machine type number discovered in (3) above. | 151 | r1 = machine type number discovered in (3) above. |
128 | r2 = physical address of tagged list in system RAM. | 152 | r2 = physical address of tagged list in system RAM, or |
153 | physical address of device tree block (dtb) in system RAM | ||
129 | 154 | ||
130 | - CPU mode | 155 | - CPU mode |
131 | All forms of interrupts must be disabled (IRQs and FIQs) | 156 | All forms of interrupts must be disabled (IRQs and FIQs) |
diff --git a/Documentation/arm/Samsung/Overview.txt b/Documentation/arm/Samsung/Overview.txt index c3094ea51aa7..658abb258cef 100644 --- a/Documentation/arm/Samsung/Overview.txt +++ b/Documentation/arm/Samsung/Overview.txt | |||
@@ -14,7 +14,6 @@ Introduction | |||
14 | - S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list | 14 | - S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list |
15 | - S3C64XX: S3C6400 and S3C6410 | 15 | - S3C64XX: S3C6400 and S3C6410 |
16 | - S5P6440 | 16 | - S5P6440 |
17 | - S5P6442 | ||
18 | - S5PC100 | 17 | - S5PC100 |
19 | - S5PC110 / S5PV210 | 18 | - S5PC110 / S5PV210 |
20 | 19 | ||
@@ -36,7 +35,6 @@ Configuration | |||
36 | unifying all the SoCs into one kernel. | 35 | unifying all the SoCs into one kernel. |
37 | 36 | ||
38 | s5p6440_defconfig - S5P6440 specific default configuration | 37 | s5p6440_defconfig - S5P6440 specific default configuration |
39 | s5p6442_defconfig - S5P6442 specific default configuration | ||
40 | s5pc100_defconfig - S5PC100 specific default configuration | 38 | s5pc100_defconfig - S5PC100 specific default configuration |
41 | s5pc110_defconfig - S5PC110 specific default configuration | 39 | s5pc110_defconfig - S5PC110 specific default configuration |
42 | s5pv210_defconfig - S5PV210 specific default configuration | 40 | s5pv210_defconfig - S5PV210 specific default configuration |
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index ac4d47187122..3bd585b44927 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt | |||
@@ -12,7 +12,7 @@ Also, it should be made opaque such that any kind of cast to a normal | |||
12 | C integer type will fail. Something like the following should | 12 | C integer type will fail. Something like the following should |
13 | suffice: | 13 | suffice: |
14 | 14 | ||
15 | typedef struct { volatile int counter; } atomic_t; | 15 | typedef struct { int counter; } atomic_t; |
16 | 16 | ||
17 | Historically, counter has been declared volatile. This is now discouraged. | 17 | Historically, counter has been declared volatile. This is now discouraged. |
18 | See Documentation/volatile-considered-harmful.txt for the complete rationale. | 18 | See Documentation/volatile-considered-harmful.txt for the complete rationale. |
diff --git a/Documentation/blockdev/cciss.txt b/Documentation/blockdev/cciss.txt index 89698e8df7d4..c00c6a5ab21f 100644 --- a/Documentation/blockdev/cciss.txt +++ b/Documentation/blockdev/cciss.txt | |||
@@ -169,3 +169,18 @@ is issued which positions the tape to a known position. Typically you | |||
169 | must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example) | 169 | must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example) |
170 | before i/o can proceed again to a tape drive which was reset. | 170 | before i/o can proceed again to a tape drive which was reset. |
171 | 171 | ||
172 | There is a cciss_tape_cmds module parameter which can be used to make cciss | ||
173 | allocate more commands for use by tape drives. Ordinarily only a few commands | ||
174 | (6) are allocated for tape drives because tape drives are slow and | ||
175 | infrequently used and the primary purpose of Smart Array controllers is to | ||
176 | act as a RAID controller for disk drives, so the vast majority of commands | ||
177 | are allocated for disk devices. However, if you have more than a few tape | ||
178 | drives attached to a smart array, the default number of commands may not be | ||
179 | enought (for example, if you have 8 tape drives, you could only rewind 6 | ||
180 | at one time with the default number of commands.) The cciss_tape_cmds module | ||
181 | parameter allows more commands (up to 16 more) to be allocated for use by | ||
182 | tape drives. For example: | ||
183 | |||
184 | insmod cciss.ko cciss_tape_cmds=16 | ||
185 | |||
186 | Or, as a kernel boot parameter passed in via grub: cciss.cciss_tape_cmds=8 | ||
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt index 9164ae3b83bc..9b728dc17535 100644 --- a/Documentation/cachetlb.txt +++ b/Documentation/cachetlb.txt | |||
@@ -16,7 +16,7 @@ on all processors in the system. Don't let this scare you into | |||
16 | thinking SMP cache/tlb flushing must be so inefficient, this is in | 16 | thinking SMP cache/tlb flushing must be so inefficient, this is in |
17 | fact an area where many optimizations are possible. For example, | 17 | fact an area where many optimizations are possible. For example, |
18 | if it can be proven that a user address space has never executed | 18 | if it can be proven that a user address space has never executed |
19 | on a cpu (see vma->cpu_vm_mask), one need not perform a flush | 19 | on a cpu (see mm_cpumask()), one need not perform a flush |
20 | for this address space on that cpu. | 20 | for this address space on that cpu. |
21 | 21 | ||
22 | First, the TLB flushing interfaces, since they are the simplest. The | 22 | First, the TLB flushing interfaces, since they are the simplest. The |
diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index 465351d4cf85..84f0a15fc210 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt | |||
@@ -28,16 +28,19 @@ cgroups. Here is what you can do. | |||
28 | - Enable group scheduling in CFQ | 28 | - Enable group scheduling in CFQ |
29 | CONFIG_CFQ_GROUP_IOSCHED=y | 29 | CONFIG_CFQ_GROUP_IOSCHED=y |
30 | 30 | ||
31 | - Compile and boot into kernel and mount IO controller (blkio). | 31 | - Compile and boot into kernel and mount IO controller (blkio); see |
32 | cgroups.txt, Why are cgroups needed?. | ||
32 | 33 | ||
33 | mount -t cgroup -o blkio none /cgroup | 34 | mount -t tmpfs cgroup_root /sys/fs/cgroup |
35 | mkdir /sys/fs/cgroup/blkio | ||
36 | mount -t cgroup -o blkio none /sys/fs/cgroup/blkio | ||
34 | 37 | ||
35 | - Create two cgroups | 38 | - Create two cgroups |
36 | mkdir -p /cgroup/test1/ /cgroup/test2 | 39 | mkdir -p /sys/fs/cgroup/blkio/test1/ /sys/fs/cgroup/blkio/test2 |
37 | 40 | ||
38 | - Set weights of group test1 and test2 | 41 | - Set weights of group test1 and test2 |
39 | echo 1000 > /cgroup/test1/blkio.weight | 42 | echo 1000 > /sys/fs/cgroup/blkio/test1/blkio.weight |
40 | echo 500 > /cgroup/test2/blkio.weight | 43 | echo 500 > /sys/fs/cgroup/blkio/test2/blkio.weight |
41 | 44 | ||
42 | - Create two same size files (say 512MB each) on same disk (file1, file2) and | 45 | - Create two same size files (say 512MB each) on same disk (file1, file2) and |
43 | launch two dd threads in different cgroup to read those files. | 46 | launch two dd threads in different cgroup to read those files. |
@@ -46,12 +49,12 @@ cgroups. Here is what you can do. | |||
46 | echo 3 > /proc/sys/vm/drop_caches | 49 | echo 3 > /proc/sys/vm/drop_caches |
47 | 50 | ||
48 | dd if=/mnt/sdb/zerofile1 of=/dev/null & | 51 | dd if=/mnt/sdb/zerofile1 of=/dev/null & |
49 | echo $! > /cgroup/test1/tasks | 52 | echo $! > /sys/fs/cgroup/blkio/test1/tasks |
50 | cat /cgroup/test1/tasks | 53 | cat /sys/fs/cgroup/blkio/test1/tasks |
51 | 54 | ||
52 | dd if=/mnt/sdb/zerofile2 of=/dev/null & | 55 | dd if=/mnt/sdb/zerofile2 of=/dev/null & |
53 | echo $! > /cgroup/test2/tasks | 56 | echo $! > /sys/fs/cgroup/blkio/test2/tasks |
54 | cat /cgroup/test2/tasks | 57 | cat /sys/fs/cgroup/blkio/test2/tasks |
55 | 58 | ||
56 | - At macro level, first dd should finish first. To get more precise data, keep | 59 | - At macro level, first dd should finish first. To get more precise data, keep |
57 | on looking at (with the help of script), at blkio.disk_time and | 60 | on looking at (with the help of script), at blkio.disk_time and |
@@ -68,13 +71,13 @@ Throttling/Upper Limit policy | |||
68 | - Enable throttling in block layer | 71 | - Enable throttling in block layer |
69 | CONFIG_BLK_DEV_THROTTLING=y | 72 | CONFIG_BLK_DEV_THROTTLING=y |
70 | 73 | ||
71 | - Mount blkio controller | 74 | - Mount blkio controller (see cgroups.txt, Why are cgroups needed?) |
72 | mount -t cgroup -o blkio none /cgroup/blkio | 75 | mount -t cgroup -o blkio none /sys/fs/cgroup/blkio |
73 | 76 | ||
74 | - Specify a bandwidth rate on particular device for root group. The format | 77 | - Specify a bandwidth rate on particular device for root group. The format |
75 | for policy is "<major>:<minor> <byes_per_second>". | 78 | for policy is "<major>:<minor> <byes_per_second>". |
76 | 79 | ||
77 | echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device | 80 | echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device |
78 | 81 | ||
79 | Above will put a limit of 1MB/second on reads happening for root group | 82 | Above will put a limit of 1MB/second on reads happening for root group |
80 | on device having major/minor number 8:16. | 83 | on device having major/minor number 8:16. |
@@ -87,7 +90,7 @@ Throttling/Upper Limit policy | |||
87 | 1024+0 records out | 90 | 1024+0 records out |
88 | 4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s | 91 | 4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s |
89 | 92 | ||
90 | Limits for writes can be put using blkio.write_bps_device file. | 93 | Limits for writes can be put using blkio.throttle.write_bps_device file. |
91 | 94 | ||
92 | Hierarchical Cgroups | 95 | Hierarchical Cgroups |
93 | ==================== | 96 | ==================== |
@@ -108,7 +111,7 @@ Hierarchical Cgroups | |||
108 | CFQ and throttling will practically treat all groups at same level. | 111 | CFQ and throttling will practically treat all groups at same level. |
109 | 112 | ||
110 | pivot | 113 | pivot |
111 | / | \ \ | 114 | / / \ \ |
112 | root test1 test2 test3 | 115 | root test1 test2 test3 |
113 | 116 | ||
114 | Down the line we can implement hierarchical accounting/control support | 117 | Down the line we can implement hierarchical accounting/control support |
@@ -149,7 +152,7 @@ Proportional weight policy files | |||
149 | 152 | ||
150 | Following is the format. | 153 | Following is the format. |
151 | 154 | ||
152 | #echo dev_maj:dev_minor weight > /path/to/cgroup/blkio.weight_device | 155 | # echo dev_maj:dev_minor weight > blkio.weight_device |
153 | Configure weight=300 on /dev/sdb (8:16) in this cgroup | 156 | Configure weight=300 on /dev/sdb (8:16) in this cgroup |
154 | # echo 8:16 300 > blkio.weight_device | 157 | # echo 8:16 300 > blkio.weight_device |
155 | # cat blkio.weight_device | 158 | # cat blkio.weight_device |
@@ -283,28 +286,28 @@ Throttling/Upper limit policy files | |||
283 | specified in bytes per second. Rules are per deivce. Following is | 286 | specified in bytes per second. Rules are per deivce. Following is |
284 | the format. | 287 | the format. |
285 | 288 | ||
286 | echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.read_bps_device | 289 | echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.read_bps_device |
287 | 290 | ||
288 | - blkio.throttle.write_bps_device | 291 | - blkio.throttle.write_bps_device |
289 | - Specifies upper limit on WRITE rate to the device. IO rate is | 292 | - Specifies upper limit on WRITE rate to the device. IO rate is |
290 | specified in bytes per second. Rules are per deivce. Following is | 293 | specified in bytes per second. Rules are per deivce. Following is |
291 | the format. | 294 | the format. |
292 | 295 | ||
293 | echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.write_bps_device | 296 | echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.write_bps_device |
294 | 297 | ||
295 | - blkio.throttle.read_iops_device | 298 | - blkio.throttle.read_iops_device |
296 | - Specifies upper limit on READ rate from the device. IO rate is | 299 | - Specifies upper limit on READ rate from the device. IO rate is |
297 | specified in IO per second. Rules are per deivce. Following is | 300 | specified in IO per second. Rules are per deivce. Following is |
298 | the format. | 301 | the format. |
299 | 302 | ||
300 | echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.read_iops_device | 303 | echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.read_iops_device |
301 | 304 | ||
302 | - blkio.throttle.write_iops_device | 305 | - blkio.throttle.write_iops_device |
303 | - Specifies upper limit on WRITE rate to the device. IO rate is | 306 | - Specifies upper limit on WRITE rate to the device. IO rate is |
304 | specified in io per second. Rules are per deivce. Following is | 307 | specified in io per second. Rules are per deivce. Following is |
305 | the format. | 308 | the format. |
306 | 309 | ||
307 | echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.write_iops_device | 310 | echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.write_iops_device |
308 | 311 | ||
309 | Note: If both BW and IOPS rules are specified for a device, then IO is | 312 | Note: If both BW and IOPS rules are specified for a device, then IO is |
310 | subjectd to both the constraints. | 313 | subjectd to both the constraints. |
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index aedf1bd02fdd..cd67e90003c0 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt | |||
@@ -138,11 +138,11 @@ With the ability to classify tasks differently for different resources | |||
138 | the admin can easily set up a script which receives exec notifications | 138 | the admin can easily set up a script which receives exec notifications |
139 | and depending on who is launching the browser he can | 139 | and depending on who is launching the browser he can |
140 | 140 | ||
141 | # echo browser_pid > /mnt/<restype>/<userclass>/tasks | 141 | # echo browser_pid > /sys/fs/cgroup/<restype>/<userclass>/tasks |
142 | 142 | ||
143 | With only a single hierarchy, he now would potentially have to create | 143 | With only a single hierarchy, he now would potentially have to create |
144 | a separate cgroup for every browser launched and associate it with | 144 | a separate cgroup for every browser launched and associate it with |
145 | approp network and other resource class. This may lead to | 145 | appropriate network and other resource class. This may lead to |
146 | proliferation of such cgroups. | 146 | proliferation of such cgroups. |
147 | 147 | ||
148 | Also lets say that the administrator would like to give enhanced network | 148 | Also lets say that the administrator would like to give enhanced network |
@@ -153,9 +153,9 @@ apps enhanced CPU power, | |||
153 | With ability to write pids directly to resource classes, it's just a | 153 | With ability to write pids directly to resource classes, it's just a |
154 | matter of : | 154 | matter of : |
155 | 155 | ||
156 | # echo pid > /mnt/network/<new_class>/tasks | 156 | # echo pid > /sys/fs/cgroup/network/<new_class>/tasks |
157 | (after some time) | 157 | (after some time) |
158 | # echo pid > /mnt/network/<orig_class>/tasks | 158 | # echo pid > /sys/fs/cgroup/network/<orig_class>/tasks |
159 | 159 | ||
160 | Without this ability, he would have to split the cgroup into | 160 | Without this ability, he would have to split the cgroup into |
161 | multiple separate ones and then associate the new cgroups with the | 161 | multiple separate ones and then associate the new cgroups with the |
@@ -236,7 +236,8 @@ containing the following files describing that cgroup: | |||
236 | - cgroup.procs: list of tgids in the cgroup. This list is not | 236 | - cgroup.procs: list of tgids in the cgroup. This list is not |
237 | guaranteed to be sorted or free of duplicate tgids, and userspace | 237 | guaranteed to be sorted or free of duplicate tgids, and userspace |
238 | should sort/uniquify the list if this property is required. | 238 | should sort/uniquify the list if this property is required. |
239 | This is a read-only file, for now. | 239 | Writing a thread group id into this file moves all threads in that |
240 | group into this cgroup. | ||
240 | - notify_on_release flag: run the release agent on exit? | 241 | - notify_on_release flag: run the release agent on exit? |
241 | - release_agent: the path to use for release notifications (this file | 242 | - release_agent: the path to use for release notifications (this file |
242 | exists in the top cgroup only) | 243 | exists in the top cgroup only) |
@@ -309,21 +310,24 @@ subsystem, this is the case for the cpuset. | |||
309 | To start a new job that is to be contained within a cgroup, using | 310 | To start a new job that is to be contained within a cgroup, using |
310 | the "cpuset" cgroup subsystem, the steps are something like: | 311 | the "cpuset" cgroup subsystem, the steps are something like: |
311 | 312 | ||
312 | 1) mkdir /dev/cgroup | 313 | 1) mount -t tmpfs cgroup_root /sys/fs/cgroup |
313 | 2) mount -t cgroup -ocpuset cpuset /dev/cgroup | 314 | 2) mkdir /sys/fs/cgroup/cpuset |
314 | 3) Create the new cgroup by doing mkdir's and write's (or echo's) in | 315 | 3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset |
315 | the /dev/cgroup virtual file system. | 316 | 4) Create the new cgroup by doing mkdir's and write's (or echo's) in |
316 | 4) Start a task that will be the "founding father" of the new job. | 317 | the /sys/fs/cgroup virtual file system. |
317 | 5) Attach that task to the new cgroup by writing its pid to the | 318 | 5) Start a task that will be the "founding father" of the new job. |
318 | /dev/cgroup tasks file for that cgroup. | 319 | 6) Attach that task to the new cgroup by writing its pid to the |
319 | 6) fork, exec or clone the job tasks from this founding father task. | 320 | /sys/fs/cgroup/cpuset/tasks file for that cgroup. |
321 | 7) fork, exec or clone the job tasks from this founding father task. | ||
320 | 322 | ||
321 | For example, the following sequence of commands will setup a cgroup | 323 | For example, the following sequence of commands will setup a cgroup |
322 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, | 324 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, |
323 | and then start a subshell 'sh' in that cgroup: | 325 | and then start a subshell 'sh' in that cgroup: |
324 | 326 | ||
325 | mount -t cgroup cpuset -ocpuset /dev/cgroup | 327 | mount -t tmpfs cgroup_root /sys/fs/cgroup |
326 | cd /dev/cgroup | 328 | mkdir /sys/fs/cgroup/cpuset |
329 | mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset | ||
330 | cd /sys/fs/cgroup/cpuset | ||
327 | mkdir Charlie | 331 | mkdir Charlie |
328 | cd Charlie | 332 | cd Charlie |
329 | /bin/echo 2-3 > cpuset.cpus | 333 | /bin/echo 2-3 > cpuset.cpus |
@@ -344,7 +348,7 @@ Creating, modifying, using the cgroups can be done through the cgroup | |||
344 | virtual filesystem. | 348 | virtual filesystem. |
345 | 349 | ||
346 | To mount a cgroup hierarchy with all available subsystems, type: | 350 | To mount a cgroup hierarchy with all available subsystems, type: |
347 | # mount -t cgroup xxx /dev/cgroup | 351 | # mount -t cgroup xxx /sys/fs/cgroup |
348 | 352 | ||
349 | The "xxx" is not interpreted by the cgroup code, but will appear in | 353 | The "xxx" is not interpreted by the cgroup code, but will appear in |
350 | /proc/mounts so may be any useful identifying string that you like. | 354 | /proc/mounts so may be any useful identifying string that you like. |
@@ -353,23 +357,32 @@ Note: Some subsystems do not work without some user input first. For instance, | |||
353 | if cpusets are enabled the user will have to populate the cpus and mems files | 357 | if cpusets are enabled the user will have to populate the cpus and mems files |
354 | for each new cgroup created before that group can be used. | 358 | for each new cgroup created before that group can be used. |
355 | 359 | ||
360 | As explained in section `1.2 Why are cgroups needed?' you should create | ||
361 | different hierarchies of cgroups for each single resource or group of | ||
362 | resources you want to control. Therefore, you should mount a tmpfs on | ||
363 | /sys/fs/cgroup and create directories for each cgroup resource or resource | ||
364 | group. | ||
365 | |||
366 | # mount -t tmpfs cgroup_root /sys/fs/cgroup | ||
367 | # mkdir /sys/fs/cgroup/rg1 | ||
368 | |||
356 | To mount a cgroup hierarchy with just the cpuset and memory | 369 | To mount a cgroup hierarchy with just the cpuset and memory |
357 | subsystems, type: | 370 | subsystems, type: |
358 | # mount -t cgroup -o cpuset,memory hier1 /dev/cgroup | 371 | # mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1 |
359 | 372 | ||
360 | To change the set of subsystems bound to a mounted hierarchy, just | 373 | To change the set of subsystems bound to a mounted hierarchy, just |
361 | remount with different options: | 374 | remount with different options: |
362 | # mount -o remount,cpuset,blkio hier1 /dev/cgroup | 375 | # mount -o remount,cpuset,blkio hier1 /sys/fs/cgroup/rg1 |
363 | 376 | ||
364 | Now memory is removed from the hierarchy and blkio is added. | 377 | Now memory is removed from the hierarchy and blkio is added. |
365 | 378 | ||
366 | Note this will add blkio to the hierarchy but won't remove memory or | 379 | Note this will add blkio to the hierarchy but won't remove memory or |
367 | cpuset, because the new options are appended to the old ones: | 380 | cpuset, because the new options are appended to the old ones: |
368 | # mount -o remount,blkio /dev/cgroup | 381 | # mount -o remount,blkio /sys/fs/cgroup/rg1 |
369 | 382 | ||
370 | To Specify a hierarchy's release_agent: | 383 | To Specify a hierarchy's release_agent: |
371 | # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \ | 384 | # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \ |
372 | xxx /dev/cgroup | 385 | xxx /sys/fs/cgroup/rg1 |
373 | 386 | ||
374 | Note that specifying 'release_agent' more than once will return failure. | 387 | Note that specifying 'release_agent' more than once will return failure. |
375 | 388 | ||
@@ -378,17 +391,17 @@ when the hierarchy consists of a single (root) cgroup. Supporting | |||
378 | the ability to arbitrarily bind/unbind subsystems from an existing | 391 | the ability to arbitrarily bind/unbind subsystems from an existing |
379 | cgroup hierarchy is intended to be implemented in the future. | 392 | cgroup hierarchy is intended to be implemented in the future. |
380 | 393 | ||
381 | Then under /dev/cgroup you can find a tree that corresponds to the | 394 | Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the |
382 | tree of the cgroups in the system. For instance, /dev/cgroup | 395 | tree of the cgroups in the system. For instance, /sys/fs/cgroup/rg1 |
383 | is the cgroup that holds the whole system. | 396 | is the cgroup that holds the whole system. |
384 | 397 | ||
385 | If you want to change the value of release_agent: | 398 | If you want to change the value of release_agent: |
386 | # echo "/sbin/new_release_agent" > /dev/cgroup/release_agent | 399 | # echo "/sbin/new_release_agent" > /sys/fs/cgroup/rg1/release_agent |
387 | 400 | ||
388 | It can also be changed via remount. | 401 | It can also be changed via remount. |
389 | 402 | ||
390 | If you want to create a new cgroup under /dev/cgroup: | 403 | If you want to create a new cgroup under /sys/fs/cgroup/rg1: |
391 | # cd /dev/cgroup | 404 | # cd /sys/fs/cgroup/rg1 |
392 | # mkdir my_cgroup | 405 | # mkdir my_cgroup |
393 | 406 | ||
394 | Now you want to do something with this cgroup. | 407 | Now you want to do something with this cgroup. |
@@ -430,6 +443,12 @@ You can attach the current shell task by echoing 0: | |||
430 | 443 | ||
431 | # echo 0 > tasks | 444 | # echo 0 > tasks |
432 | 445 | ||
446 | You can use the cgroup.procs file instead of the tasks file to move all | ||
447 | threads in a threadgroup at once. Echoing the pid of any task in a | ||
448 | threadgroup to cgroup.procs causes all tasks in that threadgroup to be | ||
449 | be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks | ||
450 | in the writing task's threadgroup. | ||
451 | |||
433 | Note: Since every task is always a member of exactly one cgroup in each | 452 | Note: Since every task is always a member of exactly one cgroup in each |
434 | mounted hierarchy, to remove a task from its current cgroup you must | 453 | mounted hierarchy, to remove a task from its current cgroup you must |
435 | move it into a new cgroup (possibly the root cgroup) by writing to the | 454 | move it into a new cgroup (possibly the root cgroup) by writing to the |
@@ -575,7 +594,7 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be | |||
575 | called multiple times against a cgroup. | 594 | called multiple times against a cgroup. |
576 | 595 | ||
577 | int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, | 596 | int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, |
578 | struct task_struct *task, bool threadgroup) | 597 | struct task_struct *task) |
579 | (cgroup_mutex held by caller) | 598 | (cgroup_mutex held by caller) |
580 | 599 | ||
581 | Called prior to moving a task into a cgroup; if the subsystem | 600 | Called prior to moving a task into a cgroup; if the subsystem |
@@ -584,9 +603,14 @@ task is passed, then a successful result indicates that *any* | |||
584 | unspecified task can be moved into the cgroup. Note that this isn't | 603 | unspecified task can be moved into the cgroup. Note that this isn't |
585 | called on a fork. If this method returns 0 (success) then this should | 604 | called on a fork. If this method returns 0 (success) then this should |
586 | remain valid while the caller holds cgroup_mutex and it is ensured that either | 605 | remain valid while the caller holds cgroup_mutex and it is ensured that either |
587 | attach() or cancel_attach() will be called in future. If threadgroup is | 606 | attach() or cancel_attach() will be called in future. |
588 | true, then a successful result indicates that all threads in the given | 607 | |
589 | thread's threadgroup can be moved together. | 608 | int can_attach_task(struct cgroup *cgrp, struct task_struct *tsk); |
609 | (cgroup_mutex held by caller) | ||
610 | |||
611 | As can_attach, but for operations that must be run once per task to be | ||
612 | attached (possibly many when using cgroup_attach_proc). Called after | ||
613 | can_attach. | ||
590 | 614 | ||
591 | void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, | 615 | void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, |
592 | struct task_struct *task, bool threadgroup) | 616 | struct task_struct *task, bool threadgroup) |
@@ -598,15 +622,24 @@ function, so that the subsystem can implement a rollback. If not, not necessary. | |||
598 | This will be called only about subsystems whose can_attach() operation have | 622 | This will be called only about subsystems whose can_attach() operation have |
599 | succeeded. | 623 | succeeded. |
600 | 624 | ||
625 | void pre_attach(struct cgroup *cgrp); | ||
626 | (cgroup_mutex held by caller) | ||
627 | |||
628 | For any non-per-thread attachment work that needs to happen before | ||
629 | attach_task. Needed by cpuset. | ||
630 | |||
601 | void attach(struct cgroup_subsys *ss, struct cgroup *cgrp, | 631 | void attach(struct cgroup_subsys *ss, struct cgroup *cgrp, |
602 | struct cgroup *old_cgrp, struct task_struct *task, | 632 | struct cgroup *old_cgrp, struct task_struct *task) |
603 | bool threadgroup) | ||
604 | (cgroup_mutex held by caller) | 633 | (cgroup_mutex held by caller) |
605 | 634 | ||
606 | Called after the task has been attached to the cgroup, to allow any | 635 | Called after the task has been attached to the cgroup, to allow any |
607 | post-attachment activity that requires memory allocations or blocking. | 636 | post-attachment activity that requires memory allocations or blocking. |
608 | If threadgroup is true, the subsystem should take care of all threads | 637 | |
609 | in the specified thread's threadgroup. Currently does not support any | 638 | void attach_task(struct cgroup *cgrp, struct task_struct *tsk); |
639 | (cgroup_mutex held by caller) | ||
640 | |||
641 | As attach, but for operations that must be run once per task to be attached, | ||
642 | like can_attach_task. Called before attach. Currently does not support any | ||
610 | subsystem that might need the old_cgrp for every thread in the group. | 643 | subsystem that might need the old_cgrp for every thread in the group. |
611 | 644 | ||
612 | void fork(struct cgroup_subsy *ss, struct task_struct *task) | 645 | void fork(struct cgroup_subsy *ss, struct task_struct *task) |
@@ -630,7 +663,7 @@ always handled well. | |||
630 | void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) | 663 | void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) |
631 | (cgroup_mutex held by caller) | 664 | (cgroup_mutex held by caller) |
632 | 665 | ||
633 | Called at the end of cgroup_clone() to do any parameter | 666 | Called during cgroup_create() to do any parameter |
634 | initialization which might be required before a task could attach. For | 667 | initialization which might be required before a task could attach. For |
635 | example in cpusets, no task may attach before 'cpus' and 'mems' are set | 668 | example in cpusets, no task may attach before 'cpus' and 'mems' are set |
636 | up. | 669 | up. |
diff --git a/Documentation/cgroups/cpuacct.txt b/Documentation/cgroups/cpuacct.txt index 8b930946c52a..9ad85df4b983 100644 --- a/Documentation/cgroups/cpuacct.txt +++ b/Documentation/cgroups/cpuacct.txt | |||
@@ -10,26 +10,25 @@ directly present in its group. | |||
10 | 10 | ||
11 | Accounting groups can be created by first mounting the cgroup filesystem. | 11 | Accounting groups can be created by first mounting the cgroup filesystem. |
12 | 12 | ||
13 | # mkdir /cgroups | 13 | # mount -t cgroup -ocpuacct none /sys/fs/cgroup |
14 | # mount -t cgroup -ocpuacct none /cgroups | 14 | |
15 | 15 | With the above step, the initial or the parent accounting group becomes | |
16 | With the above step, the initial or the parent accounting group | 16 | visible at /sys/fs/cgroup. At bootup, this group includes all the tasks in |
17 | becomes visible at /cgroups. At bootup, this group includes all the | 17 | the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup. |
18 | tasks in the system. /cgroups/tasks lists the tasks in this cgroup. | 18 | /sys/fs/cgroup/cpuacct.usage gives the CPU time (in nanoseconds) obtained |
19 | /cgroups/cpuacct.usage gives the CPU time (in nanoseconds) obtained by | 19 | by this group which is essentially the CPU time obtained by all the tasks |
20 | this group which is essentially the CPU time obtained by all the tasks | ||
21 | in the system. | 20 | in the system. |
22 | 21 | ||
23 | New accounting groups can be created under the parent group /cgroups. | 22 | New accounting groups can be created under the parent group /sys/fs/cgroup. |
24 | 23 | ||
25 | # cd /cgroups | 24 | # cd /sys/fs/cgroup |
26 | # mkdir g1 | 25 | # mkdir g1 |
27 | # echo $$ > g1 | 26 | # echo $$ > g1 |
28 | 27 | ||
29 | The above steps create a new group g1 and move the current shell | 28 | The above steps create a new group g1 and move the current shell |
30 | process (bash) into it. CPU time consumed by this bash and its children | 29 | process (bash) into it. CPU time consumed by this bash and its children |
31 | can be obtained from g1/cpuacct.usage and the same is accumulated in | 30 | can be obtained from g1/cpuacct.usage and the same is accumulated in |
32 | /cgroups/cpuacct.usage also. | 31 | /sys/fs/cgroup/cpuacct.usage also. |
33 | 32 | ||
34 | cpuacct.stat file lists a few statistics which further divide the | 33 | cpuacct.stat file lists a few statistics which further divide the |
35 | CPU time obtained by the cgroup into user and system times. Currently | 34 | CPU time obtained by the cgroup into user and system times. Currently |
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 98a30829af7a..5b0d78e55ccc 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt | |||
@@ -661,21 +661,21 @@ than stress the kernel. | |||
661 | 661 | ||
662 | To start a new job that is to be contained within a cpuset, the steps are: | 662 | To start a new job that is to be contained within a cpuset, the steps are: |
663 | 663 | ||
664 | 1) mkdir /dev/cpuset | 664 | 1) mkdir /sys/fs/cgroup/cpuset |
665 | 2) mount -t cgroup -ocpuset cpuset /dev/cpuset | 665 | 2) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset |
666 | 3) Create the new cpuset by doing mkdir's and write's (or echo's) in | 666 | 3) Create the new cpuset by doing mkdir's and write's (or echo's) in |
667 | the /dev/cpuset virtual file system. | 667 | the /sys/fs/cgroup/cpuset virtual file system. |
668 | 4) Start a task that will be the "founding father" of the new job. | 668 | 4) Start a task that will be the "founding father" of the new job. |
669 | 5) Attach that task to the new cpuset by writing its pid to the | 669 | 5) Attach that task to the new cpuset by writing its pid to the |
670 | /dev/cpuset tasks file for that cpuset. | 670 | /sys/fs/cgroup/cpuset tasks file for that cpuset. |
671 | 6) fork, exec or clone the job tasks from this founding father task. | 671 | 6) fork, exec or clone the job tasks from this founding father task. |
672 | 672 | ||
673 | For example, the following sequence of commands will setup a cpuset | 673 | For example, the following sequence of commands will setup a cpuset |
674 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, | 674 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, |
675 | and then start a subshell 'sh' in that cpuset: | 675 | and then start a subshell 'sh' in that cpuset: |
676 | 676 | ||
677 | mount -t cgroup -ocpuset cpuset /dev/cpuset | 677 | mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset |
678 | cd /dev/cpuset | 678 | cd /sys/fs/cgroup/cpuset |
679 | mkdir Charlie | 679 | mkdir Charlie |
680 | cd Charlie | 680 | cd Charlie |
681 | /bin/echo 2-3 > cpuset.cpus | 681 | /bin/echo 2-3 > cpuset.cpus |
@@ -710,14 +710,14 @@ Creating, modifying, using the cpusets can be done through the cpuset | |||
710 | virtual filesystem. | 710 | virtual filesystem. |
711 | 711 | ||
712 | To mount it, type: | 712 | To mount it, type: |
713 | # mount -t cgroup -o cpuset cpuset /dev/cpuset | 713 | # mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset |
714 | 714 | ||
715 | Then under /dev/cpuset you can find a tree that corresponds to the | 715 | Then under /sys/fs/cgroup/cpuset you can find a tree that corresponds to the |
716 | tree of the cpusets in the system. For instance, /dev/cpuset | 716 | tree of the cpusets in the system. For instance, /sys/fs/cgroup/cpuset |
717 | is the cpuset that holds the whole system. | 717 | is the cpuset that holds the whole system. |
718 | 718 | ||
719 | If you want to create a new cpuset under /dev/cpuset: | 719 | If you want to create a new cpuset under /sys/fs/cgroup/cpuset: |
720 | # cd /dev/cpuset | 720 | # cd /sys/fs/cgroup/cpuset |
721 | # mkdir my_cpuset | 721 | # mkdir my_cpuset |
722 | 722 | ||
723 | Now you want to do something with this cpuset. | 723 | Now you want to do something with this cpuset. |
@@ -765,12 +765,12 @@ wrapper around the cgroup filesystem. | |||
765 | 765 | ||
766 | The command | 766 | The command |
767 | 767 | ||
768 | mount -t cpuset X /dev/cpuset | 768 | mount -t cpuset X /sys/fs/cgroup/cpuset |
769 | 769 | ||
770 | is equivalent to | 770 | is equivalent to |
771 | 771 | ||
772 | mount -t cgroup -ocpuset,noprefix X /dev/cpuset | 772 | mount -t cgroup -ocpuset,noprefix X /sys/fs/cgroup/cpuset |
773 | echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent | 773 | echo "/sbin/cpuset_release_agent" > /sys/fs/cgroup/cpuset/release_agent |
774 | 774 | ||
775 | 2.2 Adding/removing cpus | 775 | 2.2 Adding/removing cpus |
776 | ------------------------ | 776 | ------------------------ |
diff --git a/Documentation/cgroups/devices.txt b/Documentation/cgroups/devices.txt index 57ca4c89fe5c..16624a7f8222 100644 --- a/Documentation/cgroups/devices.txt +++ b/Documentation/cgroups/devices.txt | |||
@@ -22,16 +22,16 @@ removed from the child(ren). | |||
22 | An entry is added using devices.allow, and removed using | 22 | An entry is added using devices.allow, and removed using |
23 | devices.deny. For instance | 23 | devices.deny. For instance |
24 | 24 | ||
25 | echo 'c 1:3 mr' > /cgroups/1/devices.allow | 25 | echo 'c 1:3 mr' > /sys/fs/cgroup/1/devices.allow |
26 | 26 | ||
27 | allows cgroup 1 to read and mknod the device usually known as | 27 | allows cgroup 1 to read and mknod the device usually known as |
28 | /dev/null. Doing | 28 | /dev/null. Doing |
29 | 29 | ||
30 | echo a > /cgroups/1/devices.deny | 30 | echo a > /sys/fs/cgroup/1/devices.deny |
31 | 31 | ||
32 | will remove the default 'a *:* rwm' entry. Doing | 32 | will remove the default 'a *:* rwm' entry. Doing |
33 | 33 | ||
34 | echo a > /cgroups/1/devices.allow | 34 | echo a > /sys/fs/cgroup/1/devices.allow |
35 | 35 | ||
36 | will add the 'a *:* rwm' entry to the whitelist. | 36 | will add the 'a *:* rwm' entry to the whitelist. |
37 | 37 | ||
diff --git a/Documentation/cgroups/freezer-subsystem.txt b/Documentation/cgroups/freezer-subsystem.txt index 41f37fea1276..c21d77742a07 100644 --- a/Documentation/cgroups/freezer-subsystem.txt +++ b/Documentation/cgroups/freezer-subsystem.txt | |||
@@ -59,28 +59,28 @@ is non-freezable. | |||
59 | 59 | ||
60 | * Examples of usage : | 60 | * Examples of usage : |
61 | 61 | ||
62 | # mkdir /containers | 62 | # mkdir /sys/fs/cgroup/freezer |
63 | # mount -t cgroup -ofreezer freezer /containers | 63 | # mount -t cgroup -ofreezer freezer /sys/fs/cgroup/freezer |
64 | # mkdir /containers/0 | 64 | # mkdir /sys/fs/cgroup/freezer/0 |
65 | # echo $some_pid > /containers/0/tasks | 65 | # echo $some_pid > /sys/fs/cgroup/freezer/0/tasks |
66 | 66 | ||
67 | to get status of the freezer subsystem : | 67 | to get status of the freezer subsystem : |
68 | 68 | ||
69 | # cat /containers/0/freezer.state | 69 | # cat /sys/fs/cgroup/freezer/0/freezer.state |
70 | THAWED | 70 | THAWED |
71 | 71 | ||
72 | to freeze all tasks in the container : | 72 | to freeze all tasks in the container : |
73 | 73 | ||
74 | # echo FROZEN > /containers/0/freezer.state | 74 | # echo FROZEN > /sys/fs/cgroup/freezer/0/freezer.state |
75 | # cat /containers/0/freezer.state | 75 | # cat /sys/fs/cgroup/freezer/0/freezer.state |
76 | FREEZING | 76 | FREEZING |
77 | # cat /containers/0/freezer.state | 77 | # cat /sys/fs/cgroup/freezer/0/freezer.state |
78 | FROZEN | 78 | FROZEN |
79 | 79 | ||
80 | to unfreeze all tasks in the container : | 80 | to unfreeze all tasks in the container : |
81 | 81 | ||
82 | # echo THAWED > /containers/0/freezer.state | 82 | # echo THAWED > /sys/fs/cgroup/freezer/0/freezer.state |
83 | # cat /containers/0/freezer.state | 83 | # cat /sys/fs/cgroup/freezer/0/freezer.state |
84 | THAWED | 84 | THAWED |
85 | 85 | ||
86 | This is the basic mechanism which should do the right thing for user space task | 86 | This is the basic mechanism which should do the right thing for user space task |
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 7c163477fcd8..06eb6d957c83 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt | |||
@@ -1,8 +1,8 @@ | |||
1 | Memory Resource Controller | 1 | Memory Resource Controller |
2 | 2 | ||
3 | NOTE: The Memory Resource Controller has been generically been referred | 3 | NOTE: The Memory Resource Controller has generically been referred to as the |
4 | to as the memory controller in this document. Do not confuse memory | 4 | memory controller in this document. Do not confuse memory controller |
5 | controller used here with the memory controller that is used in hardware. | 5 | used here with the memory controller that is used in hardware. |
6 | 6 | ||
7 | (For editors) | 7 | (For editors) |
8 | In this document: | 8 | In this document: |
@@ -70,6 +70,7 @@ Brief summary of control files. | |||
70 | (See sysctl's vm.swappiness) | 70 | (See sysctl's vm.swappiness) |
71 | memory.move_charge_at_immigrate # set/show controls of moving charges | 71 | memory.move_charge_at_immigrate # set/show controls of moving charges |
72 | memory.oom_control # set/show oom controls. | 72 | memory.oom_control # set/show oom controls. |
73 | memory.numa_stat # show the number of memory usage per numa node | ||
73 | 74 | ||
74 | 1. History | 75 | 1. History |
75 | 76 | ||
@@ -181,7 +182,7 @@ behind this approach is that a cgroup that aggressively uses a shared | |||
181 | page will eventually get charged for it (once it is uncharged from | 182 | page will eventually get charged for it (once it is uncharged from |
182 | the cgroup that brought it in -- this will happen on memory pressure). | 183 | the cgroup that brought it in -- this will happen on memory pressure). |
183 | 184 | ||
184 | Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used.. | 185 | Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used. |
185 | When you do swapoff and make swapped-out pages of shmem(tmpfs) to | 186 | When you do swapoff and make swapped-out pages of shmem(tmpfs) to |
186 | be backed into memory in force, charges for pages are accounted against the | 187 | be backed into memory in force, charges for pages are accounted against the |
187 | caller of swapoff rather than the users of shmem. | 188 | caller of swapoff rather than the users of shmem. |
@@ -213,7 +214,7 @@ affecting global LRU, memory+swap limit is better than just limiting swap from | |||
213 | OS point of view. | 214 | OS point of view. |
214 | 215 | ||
215 | * What happens when a cgroup hits memory.memsw.limit_in_bytes | 216 | * What happens when a cgroup hits memory.memsw.limit_in_bytes |
216 | When a cgroup his memory.memsw.limit_in_bytes, it's useless to do swap-out | 217 | When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out |
217 | in this cgroup. Then, swap-out will not be done by cgroup routine and file | 218 | in this cgroup. Then, swap-out will not be done by cgroup routine and file |
218 | caches are dropped. But as mentioned above, global LRU can do swapout memory | 219 | caches are dropped. But as mentioned above, global LRU can do swapout memory |
219 | from it for sanity of the system's memory management state. You can't forbid | 220 | from it for sanity of the system's memory management state. You can't forbid |
@@ -263,16 +264,17 @@ b. Enable CONFIG_RESOURCE_COUNTERS | |||
263 | c. Enable CONFIG_CGROUP_MEM_RES_CTLR | 264 | c. Enable CONFIG_CGROUP_MEM_RES_CTLR |
264 | d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension) | 265 | d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension) |
265 | 266 | ||
266 | 1. Prepare the cgroups | 267 | 1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?) |
267 | # mkdir -p /cgroups | 268 | # mount -t tmpfs none /sys/fs/cgroup |
268 | # mount -t cgroup none /cgroups -o memory | 269 | # mkdir /sys/fs/cgroup/memory |
270 | # mount -t cgroup none /sys/fs/cgroup/memory -o memory | ||
269 | 271 | ||
270 | 2. Make the new group and move bash into it | 272 | 2. Make the new group and move bash into it |
271 | # mkdir /cgroups/0 | 273 | # mkdir /sys/fs/cgroup/memory/0 |
272 | # echo $$ > /cgroups/0/tasks | 274 | # echo $$ > /sys/fs/cgroup/memory/0/tasks |
273 | 275 | ||
274 | Since now we're in the 0 cgroup, we can alter the memory limit: | 276 | Since now we're in the 0 cgroup, we can alter the memory limit: |
275 | # echo 4M > /cgroups/0/memory.limit_in_bytes | 277 | # echo 4M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes |
276 | 278 | ||
277 | NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo, | 279 | NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo, |
278 | mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.) | 280 | mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.) |
@@ -280,11 +282,11 @@ mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.) | |||
280 | NOTE: We can write "-1" to reset the *.limit_in_bytes(unlimited). | 282 | NOTE: We can write "-1" to reset the *.limit_in_bytes(unlimited). |
281 | NOTE: We cannot set limits on the root cgroup any more. | 283 | NOTE: We cannot set limits on the root cgroup any more. |
282 | 284 | ||
283 | # cat /cgroups/0/memory.limit_in_bytes | 285 | # cat /sys/fs/cgroup/memory/0/memory.limit_in_bytes |
284 | 4194304 | 286 | 4194304 |
285 | 287 | ||
286 | We can check the usage: | 288 | We can check the usage: |
287 | # cat /cgroups/0/memory.usage_in_bytes | 289 | # cat /sys/fs/cgroup/memory/0/memory.usage_in_bytes |
288 | 1216512 | 290 | 1216512 |
289 | 291 | ||
290 | A successful write to this file does not guarantee a successful set of | 292 | A successful write to this file does not guarantee a successful set of |
@@ -464,6 +466,24 @@ value for efficient access. (Of course, when necessary, it's synchronized.) | |||
464 | If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP) | 466 | If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP) |
465 | value in memory.stat(see 5.2). | 467 | value in memory.stat(see 5.2). |
466 | 468 | ||
469 | 5.6 numa_stat | ||
470 | |||
471 | This is similar to numa_maps but operates on a per-memcg basis. This is | ||
472 | useful for providing visibility into the numa locality information within | ||
473 | an memcg since the pages are allowed to be allocated from any physical | ||
474 | node. One of the usecases is evaluating application performance by | ||
475 | combining this information with the application's cpu allocation. | ||
476 | |||
477 | We export "total", "file", "anon" and "unevictable" pages per-node for | ||
478 | each memcg. The ouput format of memory.numa_stat is: | ||
479 | |||
480 | total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ... | ||
481 | file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ... | ||
482 | anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ... | ||
483 | unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ... | ||
484 | |||
485 | And we have total = file + anon + unevictable. | ||
486 | |||
467 | 6. Hierarchy support | 487 | 6. Hierarchy support |
468 | 488 | ||
469 | The memory controller supports a deep hierarchy and hierarchical accounting. | 489 | The memory controller supports a deep hierarchy and hierarchical accounting. |
@@ -471,13 +491,13 @@ The hierarchy is created by creating the appropriate cgroups in the | |||
471 | cgroup filesystem. Consider for example, the following cgroup filesystem | 491 | cgroup filesystem. Consider for example, the following cgroup filesystem |
472 | hierarchy | 492 | hierarchy |
473 | 493 | ||
474 | root | 494 | root |
475 | / | \ | 495 | / | \ |
476 | / | \ | 496 | / | \ |
477 | a b c | 497 | a b c |
478 | | \ | 498 | | \ |
479 | | \ | 499 | | \ |
480 | d e | 500 | d e |
481 | 501 | ||
482 | In the diagram above, with hierarchical accounting enabled, all memory | 502 | In the diagram above, with hierarchical accounting enabled, all memory |
483 | usage of e, is accounted to its ancestors up until the root (i.e, c and root), | 503 | usage of e, is accounted to its ancestors up until the root (i.e, c and root), |
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt new file mode 100644 index 000000000000..bf57ecd5d73a --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt | |||
@@ -0,0 +1,397 @@ | |||
1 | ===================================================================== | ||
2 | SEC 4 Device Tree Binding | ||
3 | Copyright (C) 2008-2011 Freescale Semiconductor Inc. | ||
4 | |||
5 | CONTENTS | ||
6 | -Overview | ||
7 | -SEC 4 Node | ||
8 | -Job Ring Node | ||
9 | -Run Time Integrity Check (RTIC) Node | ||
10 | -Run Time Integrity Check (RTIC) Memory Node | ||
11 | -Secure Non-Volatile Storage (SNVS) Node | ||
12 | -Full Example | ||
13 | |||
14 | NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator | ||
15 | Accelerator and Assurance Module (CAAM). | ||
16 | |||
17 | ===================================================================== | ||
18 | Overview | ||
19 | |||
20 | DESCRIPTION | ||
21 | |||
22 | SEC 4 h/w can process requests from 2 types of sources. | ||
23 | 1. DPAA Queue Interface (HW interface between Queue Manager & SEC 4). | ||
24 | 2. Job Rings (HW interface between cores & SEC 4 registers). | ||
25 | |||
26 | High Speed Data Path Configuration: | ||
27 | |||
28 | HW interface between QM & SEC 4 and also BM & SEC 4, on DPAA-enabled parts | ||
29 | such as the P4080. The number of simultaneous dequeues the QI can make is | ||
30 | equal to the number of Descriptor Controller (DECO) engines in a particular | ||
31 | SEC version. E.g., the SEC 4.0 in the P4080 has 5 DECOs and can thus | ||
32 | dequeue from 5 subportals simultaneously. | ||
33 | |||
34 | Job Ring Data Path Configuration: | ||
35 | |||
36 | Each JR is located on a separate 4k page, they may (or may not) be made visible | ||
37 | in the memory partition devoted to a particular core. The P4080 has 4 JRs, so | ||
38 | up to 4 JRs can be configured; and all 4 JRs process requests in parallel. | ||
39 | |||
40 | ===================================================================== | ||
41 | SEC 4 Node | ||
42 | |||
43 | Description | ||
44 | |||
45 | Node defines the base address of the SEC 4 block. | ||
46 | This block specifies the address range of all global | ||
47 | configuration registers for the SEC 4 block. It | ||
48 | also receives interrupts from the Run Time Integrity Check | ||
49 | (RTIC) function within the SEC 4 block. | ||
50 | |||
51 | PROPERTIES | ||
52 | |||
53 | - compatible | ||
54 | Usage: required | ||
55 | Value type: <string> | ||
56 | Definition: Must include "fsl,sec-v4.0" | ||
57 | |||
58 | - #address-cells | ||
59 | Usage: required | ||
60 | Value type: <u32> | ||
61 | Definition: A standard property. Defines the number of cells | ||
62 | for representing physical addresses in child nodes. | ||
63 | |||
64 | - #size-cells | ||
65 | Usage: required | ||
66 | Value type: <u32> | ||
67 | Definition: A standard property. Defines the number of cells | ||
68 | for representing the size of physical addresses in | ||
69 | child nodes. | ||
70 | |||
71 | - reg | ||
72 | Usage: required | ||
73 | Value type: <prop-encoded-array> | ||
74 | Definition: A standard property. Specifies the physical | ||
75 | address and length of the SEC4 configuration registers. | ||
76 | registers | ||
77 | |||
78 | - ranges | ||
79 | Usage: required | ||
80 | Value type: <prop-encoded-array> | ||
81 | Definition: A standard property. Specifies the physical address | ||
82 | range of the SEC 4.0 register space (-SNVS not included). A | ||
83 | triplet that includes the child address, parent address, & | ||
84 | length. | ||
85 | |||
86 | - interrupts | ||
87 | Usage: required | ||
88 | Value type: <prop_encoded-array> | ||
89 | Definition: Specifies the interrupts generated by this | ||
90 | device. The value of the interrupts property | ||
91 | consists of one interrupt specifier. The format | ||
92 | of the specifier is defined by the binding document | ||
93 | describing the node's interrupt parent. | ||
94 | |||
95 | - interrupt-parent | ||
96 | Usage: (required if interrupt property is defined) | ||
97 | Value type: <phandle> | ||
98 | Definition: A single <phandle> value that points | ||
99 | to the interrupt parent to which the child domain | ||
100 | is being mapped. | ||
101 | |||
102 | Note: All other standard properties (see the ePAPR) are allowed | ||
103 | but are optional. | ||
104 | |||
105 | |||
106 | EXAMPLE | ||
107 | crypto@300000 { | ||
108 | compatible = "fsl,sec-v4.0"; | ||
109 | #address-cells = <1>; | ||
110 | #size-cells = <1>; | ||
111 | reg = <0x300000 0x10000>; | ||
112 | ranges = <0 0x300000 0x10000>; | ||
113 | interrupt-parent = <&mpic>; | ||
114 | interrupts = <92 2>; | ||
115 | }; | ||
116 | |||
117 | ===================================================================== | ||
118 | Job Ring (JR) Node | ||
119 | |||
120 | Child of the crypto node defines data processing interface to SEC 4 | ||
121 | across the peripheral bus for purposes of processing | ||
122 | cryptographic descriptors. The specified address | ||
123 | range can be made visible to one (or more) cores. | ||
124 | The interrupt defined for this node is controlled within | ||
125 | the address range of this node. | ||
126 | |||
127 | - compatible | ||
128 | Usage: required | ||
129 | Value type: <string> | ||
130 | Definition: Must include "fsl,sec-v4.0-job-ring" | ||
131 | |||
132 | - reg | ||
133 | Usage: required | ||
134 | Value type: <prop-encoded-array> | ||
135 | Definition: Specifies a two JR parameters: an offset from | ||
136 | the parent physical address and the length the JR registers. | ||
137 | |||
138 | - fsl,liodn | ||
139 | Usage: optional-but-recommended | ||
140 | Value type: <prop-encoded-array> | ||
141 | Definition: | ||
142 | Specifies the LIODN to be used in conjunction with | ||
143 | the ppid-to-liodn table that specifies the PPID to LIODN mapping. | ||
144 | Needed if the PAMU is used. Value is a 12 bit value | ||
145 | where value is a LIODN ID for this JR. This property is | ||
146 | normally set by boot firmware. | ||
147 | |||
148 | - interrupts | ||
149 | Usage: required | ||
150 | Value type: <prop_encoded-array> | ||
151 | Definition: Specifies the interrupts generated by this | ||
152 | device. The value of the interrupts property | ||
153 | consists of one interrupt specifier. The format | ||
154 | of the specifier is defined by the binding document | ||
155 | describing the node's interrupt parent. | ||
156 | |||
157 | - interrupt-parent | ||
158 | Usage: (required if interrupt property is defined) | ||
159 | Value type: <phandle> | ||
160 | Definition: A single <phandle> value that points | ||
161 | to the interrupt parent to which the child domain | ||
162 | is being mapped. | ||
163 | |||
164 | EXAMPLE | ||
165 | jr@1000 { | ||
166 | compatible = "fsl,sec-v4.0-job-ring"; | ||
167 | reg = <0x1000 0x1000>; | ||
168 | fsl,liodn = <0x081>; | ||
169 | interrupt-parent = <&mpic>; | ||
170 | interrupts = <88 2>; | ||
171 | }; | ||
172 | |||
173 | |||
174 | ===================================================================== | ||
175 | Run Time Integrity Check (RTIC) Node | ||
176 | |||
177 | Child node of the crypto node. Defines a register space that | ||
178 | contains up to 5 sets of addresses and their lengths (sizes) that | ||
179 | will be checked at run time. After an initial hash result is | ||
180 | calculated, these addresses are checked by HW to monitor any | ||
181 | change. If any memory is modified, a Security Violation is | ||
182 | triggered (see SNVS definition). | ||
183 | |||
184 | |||
185 | - compatible | ||
186 | Usage: required | ||
187 | Value type: <string> | ||
188 | Definition: Must include "fsl,sec-v4.0-rtic". | ||
189 | |||
190 | - #address-cells | ||
191 | Usage: required | ||
192 | Value type: <u32> | ||
193 | Definition: A standard property. Defines the number of cells | ||
194 | for representing physical addresses in child nodes. Must | ||
195 | have a value of 1. | ||
196 | |||
197 | - #size-cells | ||
198 | Usage: required | ||
199 | Value type: <u32> | ||
200 | Definition: A standard property. Defines the number of cells | ||
201 | for representing the size of physical addresses in | ||
202 | child nodes. Must have a value of 1. | ||
203 | |||
204 | - reg | ||
205 | Usage: required | ||
206 | Value type: <prop-encoded-array> | ||
207 | Definition: A standard property. Specifies a two parameters: | ||
208 | an offset from the parent physical address and the length | ||
209 | the SEC4 registers. | ||
210 | |||
211 | - ranges | ||
212 | Usage: required | ||
213 | Value type: <prop-encoded-array> | ||
214 | Definition: A standard property. Specifies the physical address | ||
215 | range of the SEC 4 register space (-SNVS not included). A | ||
216 | triplet that includes the child address, parent address, & | ||
217 | length. | ||
218 | |||
219 | EXAMPLE | ||
220 | rtic@6000 { | ||
221 | compatible = "fsl,sec-v4.0-rtic"; | ||
222 | #address-cells = <1>; | ||
223 | #size-cells = <1>; | ||
224 | reg = <0x6000 0x100>; | ||
225 | ranges = <0x0 0x6100 0xe00>; | ||
226 | }; | ||
227 | |||
228 | ===================================================================== | ||
229 | Run Time Integrity Check (RTIC) Memory Node | ||
230 | A child node that defines individual RTIC memory regions that are used to | ||
231 | perform run-time integrity check of memory areas that should not modified. | ||
232 | The node defines a register that contains the memory address & | ||
233 | length (combined) and a second register that contains the hash result | ||
234 | in big endian format. | ||
235 | |||
236 | - compatible | ||
237 | Usage: required | ||
238 | Value type: <string> | ||
239 | Definition: Must include "fsl,sec-v4.0-rtic-memory". | ||
240 | |||
241 | - reg | ||
242 | Usage: required | ||
243 | Value type: <prop-encoded-array> | ||
244 | Definition: A standard property. Specifies two parameters: | ||
245 | an offset from the parent physical address and the length: | ||
246 | |||
247 | 1. The location of the RTIC memory address & length registers. | ||
248 | 2. The location RTIC hash result. | ||
249 | |||
250 | - fsl,rtic-region | ||
251 | Usage: optional-but-recommended | ||
252 | Value type: <prop-encoded-array> | ||
253 | Definition: | ||
254 | Specifies the HW address (36 bit address) for this region | ||
255 | followed by the length of the HW partition to be checked; | ||
256 | the address is represented as a 64 bit quantity followed | ||
257 | by a 32 bit length. | ||
258 | |||
259 | - fsl,liodn | ||
260 | Usage: optional-but-recommended | ||
261 | Value type: <prop-encoded-array> | ||
262 | Definition: | ||
263 | Specifies the LIODN to be used in conjunction with | ||
264 | the ppid-to-liodn table that specifies the PPID to LIODN | ||
265 | mapping. Needed if the PAMU is used. Value is a 12 bit value | ||
266 | where value is a LIODN ID for this RTIC memory region. This | ||
267 | property is normally set by boot firmware. | ||
268 | |||
269 | EXAMPLE | ||
270 | rtic-a@0 { | ||
271 | compatible = "fsl,sec-v4.0-rtic-memory"; | ||
272 | reg = <0x00 0x20 0x100 0x80>; | ||
273 | fsl,liodn = <0x03c>; | ||
274 | fsl,rtic-region = <0x12345678 0x12345678 0x12345678>; | ||
275 | }; | ||
276 | |||
277 | ===================================================================== | ||
278 | Secure Non-Volatile Storage (SNVS) Node | ||
279 | |||
280 | Node defines address range and the associated | ||
281 | interrupt for the SNVS function. This function | ||
282 | monitors security state information & reports | ||
283 | security violations. | ||
284 | |||
285 | - compatible | ||
286 | Usage: required | ||
287 | Value type: <string> | ||
288 | Definition: Must include "fsl,sec-v4.0-mon". | ||
289 | |||
290 | - reg | ||
291 | Usage: required | ||
292 | Value type: <prop-encoded-array> | ||
293 | Definition: A standard property. Specifies the physical | ||
294 | address and length of the SEC4 configuration | ||
295 | registers. | ||
296 | |||
297 | - interrupts | ||
298 | Usage: required | ||
299 | Value type: <prop_encoded-array> | ||
300 | Definition: Specifies the interrupts generated by this | ||
301 | device. The value of the interrupts property | ||
302 | consists of one interrupt specifier. The format | ||
303 | of the specifier is defined by the binding document | ||
304 | describing the node's interrupt parent. | ||
305 | |||
306 | - interrupt-parent | ||
307 | Usage: (required if interrupt property is defined) | ||
308 | Value type: <phandle> | ||
309 | Definition: A single <phandle> value that points | ||
310 | to the interrupt parent to which the child domain | ||
311 | is being mapped. | ||
312 | |||
313 | EXAMPLE | ||
314 | sec_mon@314000 { | ||
315 | compatible = "fsl,sec-v4.0-mon"; | ||
316 | reg = <0x314000 0x1000>; | ||
317 | interrupt-parent = <&mpic>; | ||
318 | interrupts = <93 2>; | ||
319 | }; | ||
320 | |||
321 | ===================================================================== | ||
322 | FULL EXAMPLE | ||
323 | |||
324 | crypto: crypto@300000 { | ||
325 | compatible = "fsl,sec-v4.0"; | ||
326 | #address-cells = <1>; | ||
327 | #size-cells = <1>; | ||
328 | reg = <0x300000 0x10000>; | ||
329 | ranges = <0 0x300000 0x10000>; | ||
330 | interrupt-parent = <&mpic>; | ||
331 | interrupts = <92 2>; | ||
332 | |||
333 | sec_jr0: jr@1000 { | ||
334 | compatible = "fsl,sec-v4.0-job-ring"; | ||
335 | reg = <0x1000 0x1000>; | ||
336 | interrupt-parent = <&mpic>; | ||
337 | interrupts = <88 2>; | ||
338 | }; | ||
339 | |||
340 | sec_jr1: jr@2000 { | ||
341 | compatible = "fsl,sec-v4.0-job-ring"; | ||
342 | reg = <0x2000 0x1000>; | ||
343 | interrupt-parent = <&mpic>; | ||
344 | interrupts = <89 2>; | ||
345 | }; | ||
346 | |||
347 | sec_jr2: jr@3000 { | ||
348 | compatible = "fsl,sec-v4.0-job-ring"; | ||
349 | reg = <0x3000 0x1000>; | ||
350 | interrupt-parent = <&mpic>; | ||
351 | interrupts = <90 2>; | ||
352 | }; | ||
353 | |||
354 | sec_jr3: jr@4000 { | ||
355 | compatible = "fsl,sec-v4.0-job-ring"; | ||
356 | reg = <0x4000 0x1000>; | ||
357 | interrupt-parent = <&mpic>; | ||
358 | interrupts = <91 2>; | ||
359 | }; | ||
360 | |||
361 | rtic@6000 { | ||
362 | compatible = "fsl,sec-v4.0-rtic"; | ||
363 | #address-cells = <1>; | ||
364 | #size-cells = <1>; | ||
365 | reg = <0x6000 0x100>; | ||
366 | ranges = <0x0 0x6100 0xe00>; | ||
367 | |||
368 | rtic_a: rtic-a@0 { | ||
369 | compatible = "fsl,sec-v4.0-rtic-memory"; | ||
370 | reg = <0x00 0x20 0x100 0x80>; | ||
371 | }; | ||
372 | |||
373 | rtic_b: rtic-b@20 { | ||
374 | compatible = "fsl,sec-v4.0-rtic-memory"; | ||
375 | reg = <0x20 0x20 0x200 0x80>; | ||
376 | }; | ||
377 | |||
378 | rtic_c: rtic-c@40 { | ||
379 | compatible = "fsl,sec-v4.0-rtic-memory"; | ||
380 | reg = <0x40 0x20 0x300 0x80>; | ||
381 | }; | ||
382 | |||
383 | rtic_d: rtic-d@60 { | ||
384 | compatible = "fsl,sec-v4.0-rtic-memory"; | ||
385 | reg = <0x60 0x20 0x500 0x80>; | ||
386 | }; | ||
387 | }; | ||
388 | }; | ||
389 | |||
390 | sec_mon: sec_mon@314000 { | ||
391 | compatible = "fsl,sec-v4.0-mon"; | ||
392 | reg = <0x314000 0x1000>; | ||
393 | interrupt-parent = <&mpic>; | ||
394 | interrupts = <93 2>; | ||
395 | }; | ||
396 | |||
397 | ===================================================================== | ||
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt new file mode 100755 index 000000000000..1a729f089866 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | |||
@@ -0,0 +1,61 @@ | |||
1 | CAN Device Tree Bindings | ||
2 | ------------------------ | ||
3 | 2011 Freescale Semiconductor, Inc. | ||
4 | |||
5 | fsl,flexcan-v1.0 nodes | ||
6 | ----------------------- | ||
7 | In addition to the required compatible-, reg- and interrupt-properties, you can | ||
8 | also specify which clock source shall be used for the controller. | ||
9 | |||
10 | CPI Clock- Can Protocol Interface Clock | ||
11 | This CLK_SRC bit of CTRL(control register) selects the clock source to | ||
12 | the CAN Protocol Interface(CPI) to be either the peripheral clock | ||
13 | (driven by the PLL) or the crystal oscillator clock. The selected clock | ||
14 | is the one fed to the prescaler to generate the Serial Clock (Sclock). | ||
15 | The PRESDIV field of CTRL(control register) controls a prescaler that | ||
16 | generates the Serial Clock (Sclock), whose period defines the | ||
17 | time quantum used to compose the CAN waveform. | ||
18 | |||
19 | Can Engine Clock Source | ||
20 | There are two sources for CAN clock | ||
21 | - Platform Clock It represents the bus clock | ||
22 | - Oscillator Clock | ||
23 | |||
24 | Peripheral Clock (PLL) | ||
25 | -------------- | ||
26 | | | ||
27 | --------- ------------- | ||
28 | | |CPI Clock | Prescaler | Sclock | ||
29 | | |---------------->| (1.. 256) |------------> | ||
30 | --------- ------------- | ||
31 | | | | ||
32 | -------------- ---------------------CLK_SRC | ||
33 | Oscillator Clock | ||
34 | |||
35 | - fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects | ||
36 | the peripheral clock. PLL clock is fed to the | ||
37 | prescaler to generate the Serial Clock (Sclock). | ||
38 | Valid values are "oscillator" and "platform" | ||
39 | "oscillator": CAN engine clock source is oscillator clock. | ||
40 | "platform" The CAN engine clock source is the bus clock | ||
41 | (platform clock). | ||
42 | |||
43 | - fsl,flexcan-clock-divider : for the reference and system clock, an additional | ||
44 | clock divider can be specified. | ||
45 | - clock-frequency: frequency required to calculate the bitrate for FlexCAN. | ||
46 | |||
47 | Note: | ||
48 | - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC. | ||
49 | - P1010 does not have oscillator as the Clock Source.So the default | ||
50 | Clock Source is platform clock. | ||
51 | Examples: | ||
52 | |||
53 | can0@1c000 { | ||
54 | compatible = "fsl,flexcan-v1.0"; | ||
55 | reg = <0x1c000 0x1000>; | ||
56 | interrupts = <48 0x2>; | ||
57 | interrupt-parent = <&mpic>; | ||
58 | fsl,flexcan-clock-source = "platform"; | ||
59 | fsl,flexcan-clock-divider = <2>; | ||
60 | clock-frequency = <fixed by u-boot>; | ||
61 | }; | ||
diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt index edb7ae19e868..2c6be0377f55 100644 --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | |||
@@ -74,3 +74,57 @@ Example: | |||
74 | interrupt-parent = <&mpic>; | 74 | interrupt-parent = <&mpic>; |
75 | phy-handle = <&phy0> | 75 | phy-handle = <&phy0> |
76 | }; | 76 | }; |
77 | |||
78 | * Gianfar PTP clock nodes | ||
79 | |||
80 | General Properties: | ||
81 | |||
82 | - compatible Should be "fsl,etsec-ptp" | ||
83 | - reg Offset and length of the register set for the device | ||
84 | - interrupts There should be at least two interrupts. Some devices | ||
85 | have as many as four PTP related interrupts. | ||
86 | |||
87 | Clock Properties: | ||
88 | |||
89 | - fsl,tclk-period Timer reference clock period in nanoseconds. | ||
90 | - fsl,tmr-prsc Prescaler, divides the output clock. | ||
91 | - fsl,tmr-add Frequency compensation value. | ||
92 | - fsl,tmr-fiper1 Fixed interval period pulse generator. | ||
93 | - fsl,tmr-fiper2 Fixed interval period pulse generator. | ||
94 | - fsl,max-adj Maximum frequency adjustment in parts per billion. | ||
95 | |||
96 | These properties set the operational parameters for the PTP | ||
97 | clock. You must choose these carefully for the clock to work right. | ||
98 | Here is how to figure good values: | ||
99 | |||
100 | TimerOsc = system clock MHz | ||
101 | tclk_period = desired clock period nanoseconds | ||
102 | NominalFreq = 1000 / tclk_period MHz | ||
103 | FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0) | ||
104 | tmr_add = ceil(2^32 / FreqDivRatio) | ||
105 | OutputClock = NominalFreq / tmr_prsc MHz | ||
106 | PulseWidth = 1 / OutputClock microseconds | ||
107 | FiperFreq1 = desired frequency in Hz | ||
108 | FiperDiv1 = 1000000 * OutputClock / FiperFreq1 | ||
109 | tmr_fiper1 = tmr_prsc * tclk_period * FiperDiv1 - tclk_period | ||
110 | max_adj = 1000000000 * (FreqDivRatio - 1.0) - 1 | ||
111 | |||
112 | The calculation for tmr_fiper2 is the same as for tmr_fiper1. The | ||
113 | driver expects that tmr_fiper1 will be correctly set to produce a 1 | ||
114 | Pulse Per Second (PPS) signal, since this will be offered to the PPS | ||
115 | subsystem to synchronize the Linux clock. | ||
116 | |||
117 | Example: | ||
118 | |||
119 | ptp_clock@24E00 { | ||
120 | compatible = "fsl,etsec-ptp"; | ||
121 | reg = <0x24E00 0xB0>; | ||
122 | interrupts = <12 0x8 13 0x8>; | ||
123 | interrupt-parent = < &ipic >; | ||
124 | fsl,tclk-period = <10>; | ||
125 | fsl,tmr-prsc = <100>; | ||
126 | fsl,tmr-add = <0x999999A4>; | ||
127 | fsl,tmr-fiper1 = <0x3B9AC9F6>; | ||
128 | fsl,tmr-fiper2 = <0x00018696>; | ||
129 | fsl,max-adj = <659999998>; | ||
130 | }; | ||
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt b/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt new file mode 100644 index 000000000000..939a26d541f6 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt | |||
@@ -0,0 +1,76 @@ | |||
1 | Integrated Flash Controller | ||
2 | |||
3 | Properties: | ||
4 | - name : Should be ifc | ||
5 | - compatible : should contain "fsl,ifc". The version of the integrated | ||
6 | flash controller can be found in the IFC_REV register at | ||
7 | offset zero. | ||
8 | |||
9 | - #address-cells : Should be either two or three. The first cell is the | ||
10 | chipselect number, and the remaining cells are the | ||
11 | offset into the chipselect. | ||
12 | - #size-cells : Either one or two, depending on how large each chipselect | ||
13 | can be. | ||
14 | - reg : Offset and length of the register set for the device | ||
15 | - interrupts : IFC has two interrupts. The first one is the "common" | ||
16 | interrupt(CM_EVTER_STAT), and second is the NAND interrupt | ||
17 | (NAND_EVTER_STAT). | ||
18 | |||
19 | - ranges : Each range corresponds to a single chipselect, and covers | ||
20 | the entire access window as configured. | ||
21 | |||
22 | Child device nodes describe the devices connected to IFC such as NOR (e.g. | ||
23 | cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices | ||
24 | like FPGAs, CPLDs, etc. | ||
25 | |||
26 | Example: | ||
27 | |||
28 | ifc@ffe1e000 { | ||
29 | compatible = "fsl,ifc", "simple-bus"; | ||
30 | #address-cells = <2>; | ||
31 | #size-cells = <1>; | ||
32 | reg = <0x0 0xffe1e000 0 0x2000>; | ||
33 | interrupts = <16 2 19 2>; | ||
34 | |||
35 | /* NOR, NAND Flashes and CPLD on board */ | ||
36 | ranges = <0x0 0x0 0x0 0xee000000 0x02000000 | ||
37 | 0x1 0x0 0x0 0xffa00000 0x00010000 | ||
38 | 0x3 0x0 0x0 0xffb00000 0x00020000>; | ||
39 | |||
40 | flash@0,0 { | ||
41 | #address-cells = <1>; | ||
42 | #size-cells = <1>; | ||
43 | compatible = "cfi-flash"; | ||
44 | reg = <0x0 0x0 0x2000000>; | ||
45 | bank-width = <2>; | ||
46 | device-width = <1>; | ||
47 | |||
48 | partition@0 { | ||
49 | /* 32MB for user data */ | ||
50 | reg = <0x0 0x02000000>; | ||
51 | label = "NOR Data"; | ||
52 | }; | ||
53 | }; | ||
54 | |||
55 | flash@1,0 { | ||
56 | #address-cells = <1>; | ||
57 | #size-cells = <1>; | ||
58 | compatible = "fsl,ifc-nand"; | ||
59 | reg = <0x1 0x0 0x10000>; | ||
60 | |||
61 | partition@0 { | ||
62 | /* This location must not be altered */ | ||
63 | /* 1MB for u-boot Bootloader Image */ | ||
64 | reg = <0x0 0x00100000>; | ||
65 | label = "NAND U-Boot Image"; | ||
66 | read-only; | ||
67 | }; | ||
68 | }; | ||
69 | |||
70 | cpld@3,0 { | ||
71 | #address-cells = <1>; | ||
72 | #size-cells = <1>; | ||
73 | compatible = "fsl,p1010rdb-cpld"; | ||
74 | reg = <0x3 0x0 0x000001f>; | ||
75 | }; | ||
76 | }; | ||
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt new file mode 100644 index 000000000000..df41958140e8 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt | |||
@@ -0,0 +1,38 @@ | |||
1 | * Freescale MPIC timers | ||
2 | |||
3 | Required properties: | ||
4 | - compatible: "fsl,mpic-global-timer" | ||
5 | |||
6 | - reg : Contains two regions. The first is the main timer register bank | ||
7 | (GTCCRxx, GTBCRxx, GTVPRxx, GTDRxx). The second is the timer control | ||
8 | register (TCRx) for the group. | ||
9 | |||
10 | - fsl,available-ranges: use <start count> style section to define which | ||
11 | timer interrupts can be used. This property is optional; without this, | ||
12 | all timers within the group can be used. | ||
13 | |||
14 | - interrupts: one interrupt per timer in the group, in order, starting | ||
15 | with timer zero. If timer-available-ranges is present, only the | ||
16 | interrupts that correspond to available timers shall be present. | ||
17 | |||
18 | Example: | ||
19 | /* Note that this requires #interrupt-cells to be 4 */ | ||
20 | timer0: timer@41100 { | ||
21 | compatible = "fsl,mpic-global-timer"; | ||
22 | reg = <0x41100 0x100 0x41300 4>; | ||
23 | |||
24 | /* Another AMP partition is using timers 0 and 1 */ | ||
25 | fsl,available-ranges = <2 2>; | ||
26 | |||
27 | interrupts = <2 0 3 0 | ||
28 | 3 0 3 0>; | ||
29 | }; | ||
30 | |||
31 | timer1: timer@42100 { | ||
32 | compatible = "fsl,mpic-global-timer"; | ||
33 | reg = <0x42100 0x100 0x42300 4>; | ||
34 | interrupts = <4 0 3 0 | ||
35 | 5 0 3 0 | ||
36 | 6 0 3 0 | ||
37 | 7 0 3 0>; | ||
38 | }; | ||
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt index 4f6145859aab..2cf38bd841fd 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt | |||
@@ -190,7 +190,7 @@ EXAMPLE 4 | |||
190 | */ | 190 | */ |
191 | timer0: timer@41100 { | 191 | timer0: timer@41100 { |
192 | compatible = "fsl,mpic-global-timer"; | 192 | compatible = "fsl,mpic-global-timer"; |
193 | reg = <0x41100 0x100>; | 193 | reg = <0x41100 0x100 0x41300 4>; |
194 | interrupts = <0 0 3 0 | 194 | interrupts = <0 0 3 0 |
195 | 1 0 3 0 | 195 | 1 0 3 0 |
196 | 2 0 3 0 | 196 | 2 0 3 0 |
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt index a7e155a023b8..36afa322b04b 100644 --- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt +++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt | |||
@@ -127,7 +127,7 @@ Nintendo Wii device tree | |||
127 | - reg : should contain the SDHCI registers location and length | 127 | - reg : should contain the SDHCI registers location and length |
128 | - interrupts : should contain the SDHCI interrupt | 128 | - interrupts : should contain the SDHCI interrupt |
129 | 129 | ||
130 | 1.j) The Inter-Processsor Communication (IPC) node | 130 | 1.j) The Inter-Processor Communication (IPC) node |
131 | 131 | ||
132 | Represent the Inter-Processor Communication interface. This interface | 132 | Represent the Inter-Processor Communication interface. This interface |
133 | enables communications between the Broadway and the Starlet processors. | 133 | enables communications between the Broadway and the Starlet processors. |
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt index 50619a0720a8..7c1329de0596 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt | |||
@@ -12,8 +12,9 @@ Table of Contents | |||
12 | ================= | 12 | ================= |
13 | 13 | ||
14 | I - Introduction | 14 | I - Introduction |
15 | 1) Entry point for arch/powerpc | 15 | 1) Entry point for arch/arm |
16 | 2) Entry point for arch/x86 | 16 | 2) Entry point for arch/powerpc |
17 | 3) Entry point for arch/x86 | ||
17 | 18 | ||
18 | II - The DT block format | 19 | II - The DT block format |
19 | 1) Header | 20 | 1) Header |
@@ -148,7 +149,46 @@ upgrades without significantly impacting the kernel code or cluttering | |||
148 | it with special cases. | 149 | it with special cases. |
149 | 150 | ||
150 | 151 | ||
151 | 1) Entry point for arch/powerpc | 152 | 1) Entry point for arch/arm |
153 | --------------------------- | ||
154 | |||
155 | There is one single entry point to the kernel, at the start | ||
156 | of the kernel image. That entry point supports two calling | ||
157 | conventions. A summary of the interface is described here. A full | ||
158 | description of the boot requirements is documented in | ||
159 | Documentation/arm/Booting | ||
160 | |||
161 | a) ATAGS interface. Minimal information is passed from firmware | ||
162 | to the kernel with a tagged list of predefined parameters. | ||
163 | |||
164 | r0 : 0 | ||
165 | |||
166 | r1 : Machine type number | ||
167 | |||
168 | r2 : Physical address of tagged list in system RAM | ||
169 | |||
170 | b) Entry with a flattened device-tree block. Firmware loads the | ||
171 | physical address of the flattened device tree block (dtb) into r2, | ||
172 | r1 is not used, but it is considered good practise to use a valid | ||
173 | machine number as described in Documentation/arm/Booting. | ||
174 | |||
175 | r0 : 0 | ||
176 | |||
177 | r1 : Valid machine type number. When using a device tree, | ||
178 | a single machine type number will often be assigned to | ||
179 | represent a class or family of SoCs. | ||
180 | |||
181 | r2 : physical pointer to the device-tree block | ||
182 | (defined in chapter II) in RAM. Device tree can be located | ||
183 | anywhere in system RAM, but it should be aligned on a 64 bit | ||
184 | boundary. | ||
185 | |||
186 | The kernel will differentiate between ATAGS and device tree booting by | ||
187 | reading the memory pointed to by r2 and looking for either the flattened | ||
188 | device tree block magic value (0xd00dfeed) or the ATAG_CORE value at | ||
189 | offset 0x4 from r2 (0x54410001). | ||
190 | |||
191 | 2) Entry point for arch/powerpc | ||
152 | ------------------------------- | 192 | ------------------------------- |
153 | 193 | ||
154 | There is one single entry point to the kernel, at the start | 194 | There is one single entry point to the kernel, at the start |
@@ -226,7 +266,7 @@ it with special cases. | |||
226 | cannot support both configurations with Book E and configurations | 266 | cannot support both configurations with Book E and configurations |
227 | with classic Powerpc architectures. | 267 | with classic Powerpc architectures. |
228 | 268 | ||
229 | 2) Entry point for arch/x86 | 269 | 3) Entry point for arch/x86 |
230 | ------------------------------- | 270 | ------------------------------- |
231 | 271 | ||
232 | There is one single 32bit entry point to the kernel at code32_start, | 272 | There is one single 32bit entry point to the kernel at code32_start, |
diff --git a/Documentation/dmaengine.txt b/Documentation/dmaengine.txt index 0c1c2f63c0a9..5a0cb1ef6164 100644 --- a/Documentation/dmaengine.txt +++ b/Documentation/dmaengine.txt | |||
@@ -1 +1,96 @@ | |||
1 | See Documentation/crypto/async-tx-api.txt | 1 | DMA Engine API Guide |
2 | ==================== | ||
3 | |||
4 | Vinod Koul <vinod dot koul at intel.com> | ||
5 | |||
6 | NOTE: For DMA Engine usage in async_tx please see: | ||
7 | Documentation/crypto/async-tx-api.txt | ||
8 | |||
9 | |||
10 | Below is a guide to device driver writers on how to use the Slave-DMA API of the | ||
11 | DMA Engine. This is applicable only for slave DMA usage only. | ||
12 | |||
13 | The slave DMA usage consists of following steps | ||
14 | 1. Allocate a DMA slave channel | ||
15 | 2. Set slave and controller specific parameters | ||
16 | 3. Get a descriptor for transaction | ||
17 | 4. Submit the transaction and wait for callback notification | ||
18 | |||
19 | 1. Allocate a DMA slave channel | ||
20 | Channel allocation is slightly different in the slave DMA context, client | ||
21 | drivers typically need a channel from a particular DMA controller only and even | ||
22 | in some cases a specific channel is desired. To request a channel | ||
23 | dma_request_channel() API is used. | ||
24 | |||
25 | Interface: | ||
26 | struct dma_chan *dma_request_channel(dma_cap_mask_t mask, | ||
27 | dma_filter_fn filter_fn, | ||
28 | void *filter_param); | ||
29 | where dma_filter_fn is defined as: | ||
30 | typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param); | ||
31 | |||
32 | When the optional 'filter_fn' parameter is set to NULL dma_request_channel | ||
33 | simply returns the first channel that satisfies the capability mask. Otherwise, | ||
34 | when the mask parameter is insufficient for specifying the necessary channel, | ||
35 | the filter_fn routine can be used to disposition the available channels in the | ||
36 | system. The filter_fn routine is called once for each free channel in the | ||
37 | system. Upon seeing a suitable channel filter_fn returns DMA_ACK which flags | ||
38 | that channel to be the return value from dma_request_channel. A channel | ||
39 | allocated via this interface is exclusive to the caller, until | ||
40 | dma_release_channel() is called. | ||
41 | |||
42 | 2. Set slave and controller specific parameters | ||
43 | Next step is always to pass some specific information to the DMA driver. Most of | ||
44 | the generic information which a slave DMA can use is in struct dma_slave_config. | ||
45 | It allows the clients to specify DMA direction, DMA addresses, bus widths, DMA | ||
46 | burst lengths etc. If some DMA controllers have more parameters to be sent then | ||
47 | they should try to embed struct dma_slave_config in their controller specific | ||
48 | structure. That gives flexibility to client to pass more parameters, if | ||
49 | required. | ||
50 | |||
51 | Interface: | ||
52 | int dmaengine_slave_config(struct dma_chan *chan, | ||
53 | struct dma_slave_config *config) | ||
54 | |||
55 | 3. Get a descriptor for transaction | ||
56 | For slave usage the various modes of slave transfers supported by the | ||
57 | DMA-engine are: | ||
58 | slave_sg - DMA a list of scatter gather buffers from/to a peripheral | ||
59 | dma_cyclic - Perform a cyclic DMA operation from/to a peripheral till the | ||
60 | operation is explicitly stopped. | ||
61 | The non NULL return of this transfer API represents a "descriptor" for the given | ||
62 | transaction. | ||
63 | |||
64 | Interface: | ||
65 | struct dma_async_tx_descriptor *(*chan->device->device_prep_dma_sg)( | ||
66 | struct dma_chan *chan, | ||
67 | struct scatterlist *dst_sg, unsigned int dst_nents, | ||
68 | struct scatterlist *src_sg, unsigned int src_nents, | ||
69 | unsigned long flags); | ||
70 | struct dma_async_tx_descriptor *(*chan->device->device_prep_dma_cyclic)( | ||
71 | struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len, | ||
72 | size_t period_len, enum dma_data_direction direction); | ||
73 | |||
74 | 4. Submit the transaction and wait for callback notification | ||
75 | To schedule the transaction to be scheduled by dma device, the "descriptor" | ||
76 | returned in above (3) needs to be submitted. | ||
77 | To tell the dma driver that a transaction is ready to be serviced, the | ||
78 | descriptor->submit() callback needs to be invoked. This chains the descriptor to | ||
79 | the pending queue. | ||
80 | The transactions in the pending queue can be activated by calling the | ||
81 | issue_pending API. If channel is idle then the first transaction in queue is | ||
82 | started and subsequent ones queued up. | ||
83 | On completion of the DMA operation the next in queue is submitted and a tasklet | ||
84 | triggered. The tasklet would then call the client driver completion callback | ||
85 | routine for notification, if set. | ||
86 | Interface: | ||
87 | void dma_async_issue_pending(struct dma_chan *chan); | ||
88 | |||
89 | ============================================================================== | ||
90 | |||
91 | Additional usage notes for dma driver writers | ||
92 | 1/ Although DMA engine specifies that completion callback routines cannot submit | ||
93 | any new operations, but typically for slave DMA subsequent transaction may not | ||
94 | be available for submit prior to callback routine being called. This requirement | ||
95 | is not a requirement for DMA-slave devices. But they should take care to drop | ||
96 | the spin-lock they might be holding before calling the callback routine | ||
diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 470d3dba1a69..dfa6fc6e4b28 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff | |||
@@ -1,6 +1,8 @@ | |||
1 | *.a | 1 | *.a |
2 | *.aux | 2 | *.aux |
3 | *.bin | 3 | *.bin |
4 | *.bz2 | ||
5 | *.cis | ||
4 | *.cpio | 6 | *.cpio |
5 | *.csp | 7 | *.csp |
6 | *.dsp | 8 | *.dsp |
@@ -8,6 +10,8 @@ | |||
8 | *.elf | 10 | *.elf |
9 | *.eps | 11 | *.eps |
10 | *.fw | 12 | *.fw |
13 | *.gcno | ||
14 | *.gcov | ||
11 | *.gen.S | 15 | *.gen.S |
12 | *.gif | 16 | *.gif |
13 | *.grep | 17 | *.grep |
@@ -19,14 +23,20 @@ | |||
19 | *.ko | 23 | *.ko |
20 | *.log | 24 | *.log |
21 | *.lst | 25 | *.lst |
26 | *.lzma | ||
27 | *.lzo | ||
28 | *.mo | ||
22 | *.moc | 29 | *.moc |
23 | *.mod.c | 30 | *.mod.c |
24 | *.o | 31 | *.o |
25 | *.o.* | 32 | *.o.* |
33 | *.order | ||
26 | *.orig | 34 | *.orig |
27 | *.out | 35 | *.out |
36 | *.patch | ||
28 | 37 | ||
29 | *.png | 38 | *.png |
39 | *.pot | ||
30 | *.ps | 40 | *.ps |
31 | *.rej | 41 | *.rej |
32 | *.s | 42 | *.s |
@@ -39,16 +49,22 @@ | |||
39 | *.tex | 49 | *.tex |
40 | *.ver | 50 | *.ver |
41 | *.xml | 51 | *.xml |
52 | *.xz | ||
42 | *_MODULES | 53 | *_MODULES |
43 | *_vga16.c | 54 | *_vga16.c |
44 | *~ | 55 | *~ |
56 | \#*# | ||
45 | *.9 | 57 | *.9 |
46 | *.9.gz | ||
47 | .* | 58 | .* |
59 | .*.d | ||
48 | .mm | 60 | .mm |
49 | 53c700_d.h | 61 | 53c700_d.h |
50 | CVS | 62 | CVS |
51 | ChangeSet | 63 | ChangeSet |
64 | GPATH | ||
65 | GRTAGS | ||
66 | GSYMS | ||
67 | GTAGS | ||
52 | Image | 68 | Image |
53 | Kerntypes | 69 | Kerntypes |
54 | Module.markers | 70 | Module.markers |
@@ -57,15 +73,14 @@ PENDING | |||
57 | SCCS | 73 | SCCS |
58 | System.map* | 74 | System.map* |
59 | TAGS | 75 | TAGS |
76 | aconf | ||
77 | af_names.h | ||
60 | aic7*reg.h* | 78 | aic7*reg.h* |
61 | aic7*reg_print.c* | 79 | aic7*reg_print.c* |
62 | aic7*seq.h* | 80 | aic7*seq.h* |
63 | aicasm | 81 | aicasm |
64 | aicdb.h* | 82 | aicdb.h* |
65 | altivec1.c | 83 | altivec*.c |
66 | altivec2.c | ||
67 | altivec4.c | ||
68 | altivec8.c | ||
69 | asm-offsets.h | 84 | asm-offsets.h |
70 | asm_offsets.h | 85 | asm_offsets.h |
71 | autoconf.h* | 86 | autoconf.h* |
@@ -80,6 +95,7 @@ btfixupprep | |||
80 | build | 95 | build |
81 | bvmlinux | 96 | bvmlinux |
82 | bzImage* | 97 | bzImage* |
98 | capability_names.h | ||
83 | capflags.c | 99 | capflags.c |
84 | classlist.h* | 100 | classlist.h* |
85 | comp*.log | 101 | comp*.log |
@@ -88,7 +104,8 @@ conf | |||
88 | config | 104 | config |
89 | config-* | 105 | config-* |
90 | config_data.h* | 106 | config_data.h* |
91 | config_data.gz* | 107 | config.mak |
108 | config.mak.autogen | ||
92 | conmakehash | 109 | conmakehash |
93 | consolemap_deftbl.c* | 110 | consolemap_deftbl.c* |
94 | cpustr.h | 111 | cpustr.h |
@@ -96,7 +113,9 @@ crc32table.h* | |||
96 | cscope.* | 113 | cscope.* |
97 | defkeymap.c | 114 | defkeymap.c |
98 | devlist.h* | 115 | devlist.h* |
116 | dnotify_test | ||
99 | docproc | 117 | docproc |
118 | dslm | ||
100 | elf2ecoff | 119 | elf2ecoff |
101 | elfconfig.h* | 120 | elfconfig.h* |
102 | evergreen_reg_safe.h | 121 | evergreen_reg_safe.h |
@@ -105,6 +124,7 @@ flask.h | |||
105 | fore200e_mkfirm | 124 | fore200e_mkfirm |
106 | fore200e_pca_fw.c* | 125 | fore200e_pca_fw.c* |
107 | gconf | 126 | gconf |
127 | gconf.glade.h | ||
108 | gen-devlist | 128 | gen-devlist |
109 | gen_crc32table | 129 | gen_crc32table |
110 | gen_init_cpio | 130 | gen_init_cpio |
@@ -112,11 +132,12 @@ generated | |||
112 | genheaders | 132 | genheaders |
113 | genksyms | 133 | genksyms |
114 | *_gray256.c | 134 | *_gray256.c |
135 | hpet_example | ||
136 | hugepage-mmap | ||
137 | hugepage-shm | ||
115 | ihex2fw | 138 | ihex2fw |
116 | ikconfig.h* | 139 | ikconfig.h* |
117 | inat-tables.c | 140 | inat-tables.c |
118 | initramfs_data.cpio | ||
119 | initramfs_data.cpio.gz | ||
120 | initramfs_list | 141 | initramfs_list |
121 | int16.c | 142 | int16.c |
122 | int1.c | 143 | int1.c |
@@ -133,15 +154,19 @@ kxgettext | |||
133 | lkc_defs.h | 154 | lkc_defs.h |
134 | lex.c | 155 | lex.c |
135 | lex.*.c | 156 | lex.*.c |
157 | linux | ||
136 | logo_*.c | 158 | logo_*.c |
137 | logo_*_clut224.c | 159 | logo_*_clut224.c |
138 | logo_*_mono.c | 160 | logo_*_mono.c |
139 | lxdialog | 161 | lxdialog |
162 | mach | ||
140 | mach-types | 163 | mach-types |
141 | mach-types.h | 164 | mach-types.h |
142 | machtypes.h | 165 | machtypes.h |
143 | map | 166 | map |
167 | map_hugetlb | ||
144 | maui_boot.h | 168 | maui_boot.h |
169 | media | ||
145 | mconf | 170 | mconf |
146 | miboot* | 171 | miboot* |
147 | mk_elfconfig | 172 | mk_elfconfig |
@@ -150,23 +175,29 @@ mkbugboot | |||
150 | mkcpustr | 175 | mkcpustr |
151 | mkdep | 176 | mkdep |
152 | mkprep | 177 | mkprep |
178 | mkregtable | ||
153 | mktables | 179 | mktables |
154 | mktree | 180 | mktree |
155 | modpost | 181 | modpost |
156 | modules.builtin | 182 | modules.builtin |
157 | modules.order | 183 | modules.order |
158 | modversions.h* | 184 | modversions.h* |
185 | nconf | ||
159 | ncscope.* | 186 | ncscope.* |
160 | offset.h | 187 | offset.h |
161 | offsets.h | 188 | offsets.h |
162 | oui.c* | 189 | oui.c* |
190 | page-types | ||
163 | parse.c | 191 | parse.c |
164 | parse.h | 192 | parse.h |
165 | patches* | 193 | patches* |
166 | pca200e.bin | 194 | pca200e.bin |
167 | pca200e_ecd.bin2 | 195 | pca200e_ecd.bin2 |
168 | piggy.gz | 196 | perf.data |
197 | perf.data.old | ||
198 | perf-archive | ||
169 | piggyback | 199 | piggyback |
200 | piggy.gzip | ||
170 | piggy.S | 201 | piggy.S |
171 | pnmtologo | 202 | pnmtologo |
172 | ppc_defs.h* | 203 | ppc_defs.h* |
@@ -177,10 +208,9 @@ r200_reg_safe.h | |||
177 | r300_reg_safe.h | 208 | r300_reg_safe.h |
178 | r420_reg_safe.h | 209 | r420_reg_safe.h |
179 | r600_reg_safe.h | 210 | r600_reg_safe.h |
180 | raid6altivec*.c | 211 | recordmcount |
181 | raid6int*.c | ||
182 | raid6tables.c | ||
183 | relocs | 212 | relocs |
213 | rlim_names.h | ||
184 | rn50_reg_safe.h | 214 | rn50_reg_safe.h |
185 | rs600_reg_safe.h | 215 | rs600_reg_safe.h |
186 | rv515_reg_safe.h | 216 | rv515_reg_safe.h |
@@ -194,6 +224,7 @@ split-include | |||
194 | syscalltab.h | 224 | syscalltab.h |
195 | tables.c | 225 | tables.c |
196 | tags | 226 | tags |
227 | test_get_len | ||
197 | tftpboot.img | 228 | tftpboot.img |
198 | timeconst.h | 229 | timeconst.h |
199 | times.h* | 230 | times.h* |
@@ -210,10 +241,13 @@ vdso32.so.dbg | |||
210 | vdso64.lds | 241 | vdso64.lds |
211 | vdso64.so.dbg | 242 | vdso64.so.dbg |
212 | version.h* | 243 | version.h* |
244 | vmImage | ||
213 | vmlinux | 245 | vmlinux |
214 | vmlinux-* | 246 | vmlinux-* |
215 | vmlinux.aout | 247 | vmlinux.aout |
248 | vmlinux.bin.all | ||
216 | vmlinux.lds | 249 | vmlinux.lds |
250 | vmlinuz | ||
217 | voffset.h | 251 | voffset.h |
218 | vsyscall.lds | 252 | vsyscall.lds |
219 | vsyscall_32.lds | 253 | vsyscall_32.lds |
diff --git a/Documentation/driver-model/bus.txt b/Documentation/driver-model/bus.txt index 5001b7511626..6754b2df8aa1 100644 --- a/Documentation/driver-model/bus.txt +++ b/Documentation/driver-model/bus.txt | |||
@@ -3,24 +3,7 @@ Bus Types | |||
3 | 3 | ||
4 | Definition | 4 | Definition |
5 | ~~~~~~~~~~ | 5 | ~~~~~~~~~~ |
6 | 6 | See the kerneldoc for the struct bus_type. | |
7 | struct bus_type { | ||
8 | char * name; | ||
9 | |||
10 | struct subsystem subsys; | ||
11 | struct kset drivers; | ||
12 | struct kset devices; | ||
13 | |||
14 | struct bus_attribute * bus_attrs; | ||
15 | struct device_attribute * dev_attrs; | ||
16 | struct driver_attribute * drv_attrs; | ||
17 | |||
18 | int (*match)(struct device * dev, struct device_driver * drv); | ||
19 | int (*hotplug) (struct device *dev, char **envp, | ||
20 | int num_envp, char *buffer, int buffer_size); | ||
21 | int (*suspend)(struct device * dev, pm_message_t state); | ||
22 | int (*resume)(struct device * dev); | ||
23 | }; | ||
24 | 7 | ||
25 | int bus_register(struct bus_type * bus); | 8 | int bus_register(struct bus_type * bus); |
26 | 9 | ||
diff --git a/Documentation/driver-model/class.txt b/Documentation/driver-model/class.txt index 548505f14aa4..1fefc480a80b 100644 --- a/Documentation/driver-model/class.txt +++ b/Documentation/driver-model/class.txt | |||
@@ -27,22 +27,7 @@ The device class structure looks like: | |||
27 | typedef int (*devclass_add)(struct device *); | 27 | typedef int (*devclass_add)(struct device *); |
28 | typedef void (*devclass_remove)(struct device *); | 28 | typedef void (*devclass_remove)(struct device *); |
29 | 29 | ||
30 | struct device_class { | 30 | See the kerneldoc for the struct class. |
31 | char * name; | ||
32 | rwlock_t lock; | ||
33 | u32 devnum; | ||
34 | struct list_head node; | ||
35 | |||
36 | struct list_head drivers; | ||
37 | struct list_head intf_list; | ||
38 | |||
39 | struct driver_dir_entry dir; | ||
40 | struct driver_dir_entry device_dir; | ||
41 | struct driver_dir_entry driver_dir; | ||
42 | |||
43 | devclass_add add_device; | ||
44 | devclass_remove remove_device; | ||
45 | }; | ||
46 | 31 | ||
47 | A typical device class definition would look like: | 32 | A typical device class definition would look like: |
48 | 33 | ||
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt index a124f3126b0d..b2ff42685bcb 100644 --- a/Documentation/driver-model/device.txt +++ b/Documentation/driver-model/device.txt | |||
@@ -2,96 +2,7 @@ | |||
2 | The Basic Device Structure | 2 | The Basic Device Structure |
3 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | 3 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
4 | 4 | ||
5 | struct device { | 5 | See the kerneldoc for the struct device. |
6 | struct list_head g_list; | ||
7 | struct list_head node; | ||
8 | struct list_head bus_list; | ||
9 | struct list_head driver_list; | ||
10 | struct list_head intf_list; | ||
11 | struct list_head children; | ||
12 | struct device * parent; | ||
13 | |||
14 | char name[DEVICE_NAME_SIZE]; | ||
15 | char bus_id[BUS_ID_SIZE]; | ||
16 | |||
17 | spinlock_t lock; | ||
18 | atomic_t refcount; | ||
19 | |||
20 | struct bus_type * bus; | ||
21 | struct driver_dir_entry dir; | ||
22 | |||
23 | u32 class_num; | ||
24 | |||
25 | struct device_driver *driver; | ||
26 | void *driver_data; | ||
27 | void *platform_data; | ||
28 | |||
29 | u32 current_state; | ||
30 | unsigned char *saved_state; | ||
31 | |||
32 | void (*release)(struct device * dev); | ||
33 | }; | ||
34 | |||
35 | Fields | ||
36 | ~~~~~~ | ||
37 | g_list: Node in the global device list. | ||
38 | |||
39 | node: Node in device's parent's children list. | ||
40 | |||
41 | bus_list: Node in device's bus's devices list. | ||
42 | |||
43 | driver_list: Node in device's driver's devices list. | ||
44 | |||
45 | intf_list: List of intf_data. There is one structure allocated for | ||
46 | each interface that the device supports. | ||
47 | |||
48 | children: List of child devices. | ||
49 | |||
50 | parent: *** FIXME *** | ||
51 | |||
52 | name: ASCII description of device. | ||
53 | Example: " 3Com Corporation 3c905 100BaseTX [Boomerang]" | ||
54 | |||
55 | bus_id: ASCII representation of device's bus position. This | ||
56 | field should be a name unique across all devices on the | ||
57 | bus type the device belongs to. | ||
58 | |||
59 | Example: PCI bus_ids are in the form of | ||
60 | <bus number>:<slot number>.<function number> | ||
61 | This name is unique across all PCI devices in the system. | ||
62 | |||
63 | lock: Spinlock for the device. | ||
64 | |||
65 | refcount: Reference count on the device. | ||
66 | |||
67 | bus: Pointer to struct bus_type that device belongs to. | ||
68 | |||
69 | dir: Device's sysfs directory. | ||
70 | |||
71 | class_num: Class-enumerated value of the device. | ||
72 | |||
73 | driver: Pointer to struct device_driver that controls the device. | ||
74 | |||
75 | driver_data: Driver-specific data. | ||
76 | |||
77 | platform_data: Platform data specific to the device. | ||
78 | |||
79 | Example: for devices on custom boards, as typical of embedded | ||
80 | and SOC based hardware, Linux often uses platform_data to point | ||
81 | to board-specific structures describing devices and how they | ||
82 | are wired. That can include what ports are available, chip | ||
83 | variants, which GPIO pins act in what additional roles, and so | ||
84 | on. This shrinks the "Board Support Packages" (BSPs) and | ||
85 | minimizes board-specific #ifdefs in drivers. | ||
86 | |||
87 | current_state: Current power state of the device. | ||
88 | |||
89 | saved_state: Pointer to saved state of the device. This is usable by | ||
90 | the device driver controlling the device. | ||
91 | |||
92 | release: Callback to free the device after all references have | ||
93 | gone away. This should be set by the allocator of the | ||
94 | device (i.e. the bus driver that discovered the device). | ||
95 | 6 | ||
96 | 7 | ||
97 | Programming Interface | 8 | Programming Interface |
diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt index d2cd6fb8ba9e..4421135826a2 100644 --- a/Documentation/driver-model/driver.txt +++ b/Documentation/driver-model/driver.txt | |||
@@ -1,23 +1,7 @@ | |||
1 | 1 | ||
2 | Device Drivers | 2 | Device Drivers |
3 | 3 | ||
4 | struct device_driver { | 4 | See the kerneldoc for the struct device_driver. |
5 | char * name; | ||
6 | struct bus_type * bus; | ||
7 | |||
8 | struct completion unloaded; | ||
9 | struct kobject kobj; | ||
10 | list_t devices; | ||
11 | |||
12 | struct module *owner; | ||
13 | |||
14 | int (*probe) (struct device * dev); | ||
15 | int (*remove) (struct device * dev); | ||
16 | |||
17 | int (*suspend) (struct device * dev, pm_message_t state); | ||
18 | int (*resume) (struct device * dev); | ||
19 | }; | ||
20 | |||
21 | 5 | ||
22 | 6 | ||
23 | Allocation | 7 | Allocation |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 492e81df2968..b1c921c27519 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -6,6 +6,42 @@ be removed from this file. | |||
6 | 6 | ||
7 | --------------------------- | 7 | --------------------------- |
8 | 8 | ||
9 | What: x86 floppy disable_hlt | ||
10 | When: 2012 | ||
11 | Why: ancient workaround of dubious utility clutters the | ||
12 | code used by everybody else. | ||
13 | Who: Len Brown <len.brown@intel.com> | ||
14 | |||
15 | --------------------------- | ||
16 | |||
17 | What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle | ||
18 | When: 2012 | ||
19 | Why: This optional sub-feature of APM is of dubious reliability, | ||
20 | and ancient APM laptops are likely better served by calling HLT. | ||
21 | Deleting CONFIG_APM_CPU_IDLE allows x86 to stop exporting | ||
22 | the pm_idle function pointer to modules. | ||
23 | Who: Len Brown <len.brown@intel.com> | ||
24 | |||
25 | ---------------------------- | ||
26 | |||
27 | What: x86_32 "no-hlt" cmdline param | ||
28 | When: 2012 | ||
29 | Why: remove a branch from idle path, simplify code used by everybody. | ||
30 | This option disabled the use of HLT in idle and machine_halt() | ||
31 | for hardware that was flakey 15-years ago. Today we have | ||
32 | "idle=poll" that removed HLT from idle, and so if such a machine | ||
33 | is still running the upstream kernel, "idle=poll" is likely sufficient. | ||
34 | Who: Len Brown <len.brown@intel.com> | ||
35 | |||
36 | ---------------------------- | ||
37 | |||
38 | What: x86 "idle=mwait" cmdline param | ||
39 | When: 2012 | ||
40 | Why: simplify x86 idle code | ||
41 | Who: Len Brown <len.brown@intel.com> | ||
42 | |||
43 | ---------------------------- | ||
44 | |||
9 | What: PRISM54 | 45 | What: PRISM54 |
10 | When: 2.6.34 | 46 | When: 2.6.34 |
11 | 47 | ||
@@ -35,17 +71,6 @@ Who: Luis R. Rodriguez <lrodriguez@atheros.com> | |||
35 | 71 | ||
36 | --------------------------- | 72 | --------------------------- |
37 | 73 | ||
38 | What: AR9170USB | ||
39 | When: 2.6.40 | ||
40 | |||
41 | Why: This driver is deprecated and the firmware is no longer | ||
42 | maintained. The replacement driver "carl9170" has been | ||
43 | around for a while, so the devices are still supported. | ||
44 | |||
45 | Who: Christian Lamparter <chunkeey@googlemail.com> | ||
46 | |||
47 | --------------------------- | ||
48 | |||
49 | What: IRQF_SAMPLE_RANDOM | 74 | What: IRQF_SAMPLE_RANDOM |
50 | Check: IRQF_SAMPLE_RANDOM | 75 | Check: IRQF_SAMPLE_RANDOM |
51 | When: July 2009 | 76 | When: July 2009 |
@@ -226,7 +251,7 @@ Who: Zhang Rui <rui.zhang@intel.com> | |||
226 | What: CONFIG_ACPI_PROCFS_POWER | 251 | What: CONFIG_ACPI_PROCFS_POWER |
227 | When: 2.6.39 | 252 | When: 2.6.39 |
228 | Why: sysfs I/F for ACPI power devices, including AC and Battery, | 253 | Why: sysfs I/F for ACPI power devices, including AC and Battery, |
229 | has been working in upstream kenrel since 2.6.24, Sep 2007. | 254 | has been working in upstream kernel since 2.6.24, Sep 2007. |
230 | In 2.6.37, we make the sysfs I/F always built in and this option | 255 | In 2.6.37, we make the sysfs I/F always built in and this option |
231 | disabled by default. | 256 | disabled by default. |
232 | Remove this option and the ACPI power procfs interface in 2.6.39. | 257 | Remove this option and the ACPI power procfs interface in 2.6.39. |
@@ -273,16 +298,6 @@ Who: Michael Buesch <mb@bu3sch.de> | |||
273 | 298 | ||
274 | --------------------------- | 299 | --------------------------- |
275 | 300 | ||
276 | What: /sys/o2cb symlink | ||
277 | When: January 2010 | ||
278 | Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb | ||
279 | exists as a symlink for backwards compatibility for old versions of | ||
280 | ocfs2-tools. 2 years should be sufficient time to phase in new versions | ||
281 | which know to look in /sys/fs/o2cb. | ||
282 | Who: ocfs2-devel@oss.oracle.com | ||
283 | |||
284 | --------------------------- | ||
285 | |||
286 | What: Ability for non root users to shm_get hugetlb pages based on mlock | 301 | What: Ability for non root users to shm_get hugetlb pages based on mlock |
287 | resource limits | 302 | resource limits |
288 | When: 2.6.31 | 303 | When: 2.6.31 |
@@ -405,16 +420,6 @@ Who: anybody or Florian Mickler <florian@mickler.org> | |||
405 | 420 | ||
406 | ---------------------------- | 421 | ---------------------------- |
407 | 422 | ||
408 | What: capifs | ||
409 | When: February 2011 | ||
410 | Files: drivers/isdn/capi/capifs.* | ||
411 | Why: udev fully replaces this special file system that only contains CAPI | ||
412 | NCCI TTY device nodes. User space (pppdcapiplugin) works without | ||
413 | noticing the difference. | ||
414 | Who: Jan Kiszka <jan.kiszka@web.de> | ||
415 | |||
416 | ---------------------------- | ||
417 | |||
418 | What: KVM paravirt mmu host support | 423 | What: KVM paravirt mmu host support |
419 | When: January 2011 | 424 | When: January 2011 |
420 | Why: The paravirt mmu host support is slower than non-paravirt mmu, both | 425 | Why: The paravirt mmu host support is slower than non-paravirt mmu, both |
@@ -460,14 +465,6 @@ Who: Thomas Gleixner <tglx@linutronix.de> | |||
460 | 465 | ||
461 | ---------------------------- | 466 | ---------------------------- |
462 | 467 | ||
463 | What: The acpi_sleep=s4_nonvs command line option | ||
464 | When: 2.6.37 | ||
465 | Files: arch/x86/kernel/acpi/sleep.c | ||
466 | Why: superseded by acpi_sleep=nonvs | ||
467 | Who: Rafael J. Wysocki <rjw@sisk.pl> | ||
468 | |||
469 | ---------------------------- | ||
470 | |||
471 | What: PCI DMA unmap state API | 468 | What: PCI DMA unmap state API |
472 | When: August 2012 | 469 | When: August 2012 |
473 | Why: PCI DMA unmap state API (include/linux/pci-dma.h) was replaced | 470 | Why: PCI DMA unmap state API (include/linux/pci-dma.h) was replaced |
@@ -484,23 +481,6 @@ Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> | |||
484 | 481 | ||
485 | ---------------------------- | 482 | ---------------------------- |
486 | 483 | ||
487 | What: namespace cgroup (ns_cgroup) | ||
488 | When: 2.6.38 | ||
489 | Why: The ns_cgroup leads to some problems: | ||
490 | * cgroup creation is out-of-control | ||
491 | * cgroup name can conflict when pids are looping | ||
492 | * it is not possible to have a single process handling | ||
493 | a lot of namespaces without falling in a exponential creation time | ||
494 | * we may want to create a namespace without creating a cgroup | ||
495 | |||
496 | The ns_cgroup is replaced by a compatibility flag 'clone_children', | ||
497 | where a newly created cgroup will copy the parent cgroup values. | ||
498 | The userspace has to manually create a cgroup and add a task to | ||
499 | the 'tasks' file. | ||
500 | Who: Daniel Lezcano <daniel.lezcano@free.fr> | ||
501 | |||
502 | ---------------------------- | ||
503 | |||
504 | What: iwlwifi disable_hw_scan module parameters | 484 | What: iwlwifi disable_hw_scan module parameters |
505 | When: 2.6.40 | 485 | When: 2.6.40 |
506 | Why: Hareware scan is the prefer method for iwlwifi devices for | 486 | Why: Hareware scan is the prefer method for iwlwifi devices for |
@@ -580,3 +560,48 @@ Why: These legacy callbacks should no longer be used as i2c-core offers | |||
580 | Who: Jean Delvare <khali@linux-fr.org> | 560 | Who: Jean Delvare <khali@linux-fr.org> |
581 | 561 | ||
582 | ---------------------------- | 562 | ---------------------------- |
563 | |||
564 | What: Support for UVCIOC_CTRL_ADD in the uvcvideo driver | ||
565 | When: 2.6.42 | ||
566 | Why: The information passed to the driver by this ioctl is now queried | ||
567 | dynamically from the device. | ||
568 | Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com> | ||
569 | |||
570 | ---------------------------- | ||
571 | |||
572 | What: Support for UVCIOC_CTRL_MAP_OLD in the uvcvideo driver | ||
573 | When: 2.6.42 | ||
574 | Why: Used only by applications compiled against older driver versions. | ||
575 | Superseded by UVCIOC_CTRL_MAP which supports V4L2 menu controls. | ||
576 | Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com> | ||
577 | |||
578 | ---------------------------- | ||
579 | |||
580 | What: Support for UVCIOC_CTRL_GET and UVCIOC_CTRL_SET in the uvcvideo driver | ||
581 | When: 2.6.42 | ||
582 | Why: Superseded by the UVCIOC_CTRL_QUERY ioctl. | ||
583 | Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com> | ||
584 | |||
585 | ---------------------------- | ||
586 | |||
587 | What: For VIDIOC_S_FREQUENCY the type field must match the device node's type. | ||
588 | If not, return -EINVAL. | ||
589 | When: 3.2 | ||
590 | Why: It makes no sense to switch the tuner to radio mode by calling | ||
591 | VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by | ||
592 | calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a | ||
593 | move to more consistent handling of tv and radio tuners. | ||
594 | Who: Hans Verkuil <hans.verkuil@cisco.com> | ||
595 | |||
596 | ---------------------------- | ||
597 | |||
598 | What: Opening a radio device node will no longer automatically switch the | ||
599 | tuner mode from tv to radio. | ||
600 | When: 3.3 | ||
601 | Why: Just opening a V4L device should not change the state of the hardware | ||
602 | like that. It's very unexpected and against the V4L spec. Instead, you | ||
603 | switch to radio mode by calling VIDIOC_S_FREQUENCY. This is the second | ||
604 | and last step of the move to consistent handling of tv and radio tuners. | ||
605 | Who: Hans Verkuil <hans.verkuil@cisco.com> | ||
606 | |||
607 | ---------------------------- | ||
diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt index b22abba78fed..13de64c7f0ab 100644 --- a/Documentation/filesystems/9p.txt +++ b/Documentation/filesystems/9p.txt | |||
@@ -25,6 +25,8 @@ Other applications are described in the following papers: | |||
25 | http://xcpu.org/papers/cellfs-talk.pdf | 25 | http://xcpu.org/papers/cellfs-talk.pdf |
26 | * PROSE I/O: Using 9p to enable Application Partitions | 26 | * PROSE I/O: Using 9p to enable Application Partitions |
27 | http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf | 27 | http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf |
28 | * VirtFS: A Virtualization Aware File System pass-through | ||
29 | http://goo.gl/3WPDg | ||
28 | 30 | ||
29 | USAGE | 31 | USAGE |
30 | ===== | 32 | ===== |
@@ -130,31 +132,20 @@ OPTIONS | |||
130 | RESOURCES | 132 | RESOURCES |
131 | ========= | 133 | ========= |
132 | 134 | ||
133 | Our current recommendation is to use Inferno (http://www.vitanuova.com/nferno/index.html) | 135 | Protocol specifications are maintained on github: |
134 | as the 9p server. You can start a 9p server under Inferno by issuing the | 136 | http://ericvh.github.com/9p-rfc/ |
135 | following command: | ||
136 | ; styxlisten -A tcp!*!564 export '#U*' | ||
137 | 137 | ||
138 | The -A specifies an unauthenticated export. The 564 is the port # (you may | 138 | 9p client and server implementations are listed on |
139 | have to choose a higher port number if running as a normal user). The '#U*' | 139 | http://9p.cat-v.org/implementations |
140 | specifies exporting the root of the Linux name space. You may specify a | ||
141 | subset of the namespace by extending the path: '#U*'/tmp would just export | ||
142 | /tmp. For more information, see the Inferno manual pages covering styxlisten | ||
143 | and export. | ||
144 | 140 | ||
145 | A Linux version of the 9p server is now maintained under the npfs project | 141 | A 9p2000.L server is being developed by LLNL and can be found |
146 | on sourceforge (http://sourceforge.net/projects/npfs). The currently | 142 | at http://code.google.com/p/diod/ |
147 | maintained version is the single-threaded version of the server (named spfs) | ||
148 | available from the same SVN repository. | ||
149 | 143 | ||
150 | There are user and developer mailing lists available through the v9fs project | 144 | There are user and developer mailing lists available through the v9fs project |
151 | on sourceforge (http://sourceforge.net/projects/v9fs). | 145 | on sourceforge (http://sourceforge.net/projects/v9fs). |
152 | 146 | ||
153 | A stand-alone version of the module (which should build for any 2.6 kernel) | 147 | News and other information is maintained on a Wiki. |
154 | is available via (http://github.com/ericvh/9p-sac/tree/master) | 148 | (http://sf.net/apps/mediawiki/v9fs/index.php). |
155 | |||
156 | News and other information is maintained on SWiK (http://swik.net/v9fs) | ||
157 | and the Wiki (http://sf.net/apps/mediawiki/v9fs/index.php). | ||
158 | 149 | ||
159 | Bug reports may be issued through the kernel.org bugzilla | 150 | Bug reports may be issued through the kernel.org bugzilla |
160 | (http://bugzilla.kernel.org) | 151 | (http://bugzilla.kernel.org) |
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 61b31acb9176..57d827d6071d 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking | |||
@@ -104,7 +104,7 @@ of the locking scheme for directory operations. | |||
104 | prototypes: | 104 | prototypes: |
105 | struct inode *(*alloc_inode)(struct super_block *sb); | 105 | struct inode *(*alloc_inode)(struct super_block *sb); |
106 | void (*destroy_inode)(struct inode *); | 106 | void (*destroy_inode)(struct inode *); |
107 | void (*dirty_inode) (struct inode *); | 107 | void (*dirty_inode) (struct inode *, int flags); |
108 | int (*write_inode) (struct inode *, struct writeback_control *wbc); | 108 | int (*write_inode) (struct inode *, struct writeback_control *wbc); |
109 | int (*drop_inode) (struct inode *); | 109 | int (*drop_inode) (struct inode *); |
110 | void (*evict_inode) (struct inode *); | 110 | void (*evict_inode) (struct inode *); |
@@ -126,7 +126,7 @@ locking rules: | |||
126 | s_umount | 126 | s_umount |
127 | alloc_inode: | 127 | alloc_inode: |
128 | destroy_inode: | 128 | destroy_inode: |
129 | dirty_inode: (must not sleep) | 129 | dirty_inode: |
130 | write_inode: | 130 | write_inode: |
131 | drop_inode: !!!inode->i_lock!!! | 131 | drop_inode: !!!inode->i_lock!!! |
132 | evict_inode: | 132 | evict_inode: |
diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt index a167ab876c35..7cc6bf2871eb 100644 --- a/Documentation/filesystems/caching/netfs-api.txt +++ b/Documentation/filesystems/caching/netfs-api.txt | |||
@@ -673,6 +673,22 @@ storage request to complete, or it may attempt to cancel the storage request - | |||
673 | in which case the page will not be stored in the cache this time. | 673 | in which case the page will not be stored in the cache this time. |
674 | 674 | ||
675 | 675 | ||
676 | BULK INODE PAGE UNCACHE | ||
677 | ----------------------- | ||
678 | |||
679 | A convenience routine is provided to perform an uncache on all the pages | ||
680 | attached to an inode. This assumes that the pages on the inode correspond on a | ||
681 | 1:1 basis with the pages in the cache. | ||
682 | |||
683 | void fscache_uncache_all_inode_pages(struct fscache_cookie *cookie, | ||
684 | struct inode *inode); | ||
685 | |||
686 | This takes the netfs cookie that the pages were cached with and the inode that | ||
687 | the pages are attached to. This function will wait for pages to finish being | ||
688 | written to the cache and for the cache to finish with the page generally. No | ||
689 | error is returned. | ||
690 | |||
691 | |||
676 | ========================== | 692 | ========================== |
677 | INDEX AND DATA FILE UPDATE | 693 | INDEX AND DATA FILE UPDATE |
678 | ========================== | 694 | ========================== |
diff --git a/Documentation/filesystems/configfs/configfs_example_explicit.c b/Documentation/filesystems/configfs/configfs_example_explicit.c index fd53869f5633..1420233dfa55 100644 --- a/Documentation/filesystems/configfs/configfs_example_explicit.c +++ b/Documentation/filesystems/configfs/configfs_example_explicit.c | |||
@@ -464,9 +464,8 @@ static int __init configfs_example_init(void) | |||
464 | return 0; | 464 | return 0; |
465 | 465 | ||
466 | out_unregister: | 466 | out_unregister: |
467 | for (; i >= 0; i--) { | 467 | for (i--; i >= 0; i--) |
468 | configfs_unregister_subsystem(example_subsys[i]); | 468 | configfs_unregister_subsystem(example_subsys[i]); |
469 | } | ||
470 | 469 | ||
471 | return ret; | 470 | return ret; |
472 | } | 471 | } |
@@ -475,9 +474,8 @@ static void __exit configfs_example_exit(void) | |||
475 | { | 474 | { |
476 | int i; | 475 | int i; |
477 | 476 | ||
478 | for (i = 0; example_subsys[i]; i++) { | 477 | for (i = 0; example_subsys[i]; i++) |
479 | configfs_unregister_subsystem(example_subsys[i]); | 478 | configfs_unregister_subsystem(example_subsys[i]); |
480 | } | ||
481 | } | 479 | } |
482 | 480 | ||
483 | module_init(configfs_example_init); | 481 | module_init(configfs_example_init); |
diff --git a/Documentation/filesystems/configfs/configfs_example_macros.c b/Documentation/filesystems/configfs/configfs_example_macros.c index d8e30a0378aa..327dfbc640a9 100644 --- a/Documentation/filesystems/configfs/configfs_example_macros.c +++ b/Documentation/filesystems/configfs/configfs_example_macros.c | |||
@@ -427,9 +427,8 @@ static int __init configfs_example_init(void) | |||
427 | return 0; | 427 | return 0; |
428 | 428 | ||
429 | out_unregister: | 429 | out_unregister: |
430 | for (; i >= 0; i--) { | 430 | for (i--; i >= 0; i--) |
431 | configfs_unregister_subsystem(example_subsys[i]); | 431 | configfs_unregister_subsystem(example_subsys[i]); |
432 | } | ||
433 | 432 | ||
434 | return ret; | 433 | return ret; |
435 | } | 434 | } |
@@ -438,9 +437,8 @@ static void __exit configfs_example_exit(void) | |||
438 | { | 437 | { |
439 | int i; | 438 | int i; |
440 | 439 | ||
441 | for (i = 0; example_subsys[i]; i++) { | 440 | for (i = 0; example_subsys[i]; i++) |
442 | configfs_unregister_subsystem(example_subsys[i]); | 441 | configfs_unregister_subsystem(example_subsys[i]); |
443 | } | ||
444 | } | 442 | } |
445 | 443 | ||
446 | module_init(configfs_example_init); | 444 | module_init(configfs_example_init); |
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index c79ec58fd7f6..3ae9bc94352a 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt | |||
@@ -226,10 +226,6 @@ acl Enables POSIX Access Control Lists support. | |||
226 | noacl This option disables POSIX Access Control List | 226 | noacl This option disables POSIX Access Control List |
227 | support. | 227 | support. |
228 | 228 | ||
229 | reservation | ||
230 | |||
231 | noreservation | ||
232 | |||
233 | bsddf (*) Make 'df' act like BSD. | 229 | bsddf (*) Make 'df' act like BSD. |
234 | minixdf Make 'df' act like Minix. | 230 | minixdf Make 'df' act like Minix. |
235 | 231 | ||
diff --git a/Documentation/filesystems/nfs/idmapper.txt b/Documentation/filesystems/nfs/idmapper.txt index b9b4192ea8b5..9c8fd6148656 100644 --- a/Documentation/filesystems/nfs/idmapper.txt +++ b/Documentation/filesystems/nfs/idmapper.txt | |||
@@ -47,8 +47,8 @@ request-key will find the first matching line and corresponding program. In | |||
47 | this case, /some/other/program will handle all uid lookups and | 47 | this case, /some/other/program will handle all uid lookups and |
48 | /usr/sbin/nfs.idmap will handle gid, user, and group lookups. | 48 | /usr/sbin/nfs.idmap will handle gid, user, and group lookups. |
49 | 49 | ||
50 | See <file:Documentation/keys-request-keys.txt> for more information about the | 50 | See <file:Documentation/security/keys-request-keys.txt> for more information |
51 | request-key function. | 51 | about the request-key function. |
52 | 52 | ||
53 | 53 | ||
54 | ========= | 54 | ========= |
diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt index d5c0cef38a71..873a2ab2e9f8 100644 --- a/Documentation/filesystems/nilfs2.txt +++ b/Documentation/filesystems/nilfs2.txt | |||
@@ -40,7 +40,6 @@ Features which NILFS2 does not support yet: | |||
40 | - POSIX ACLs | 40 | - POSIX ACLs |
41 | - quotas | 41 | - quotas |
42 | - fsck | 42 | - fsck |
43 | - resize | ||
44 | - defragmentation | 43 | - defragmentation |
45 | 44 | ||
46 | Mount options | 45 | Mount options |
diff --git a/Documentation/filesystems/ocfs2.txt b/Documentation/filesystems/ocfs2.txt index 9ed920a8cd79..7618a287aa41 100644 --- a/Documentation/filesystems/ocfs2.txt +++ b/Documentation/filesystems/ocfs2.txt | |||
@@ -46,9 +46,15 @@ errors=panic Panic and halt the machine if an error occurs. | |||
46 | intr (*) Allow signals to interrupt cluster operations. | 46 | intr (*) Allow signals to interrupt cluster operations. |
47 | nointr Do not allow signals to interrupt cluster | 47 | nointr Do not allow signals to interrupt cluster |
48 | operations. | 48 | operations. |
49 | noatime Do not update access time. | ||
50 | relatime(*) Update atime if the previous atime is older than | ||
51 | mtime or ctime | ||
52 | strictatime Always update atime, but the minimum update interval | ||
53 | is specified by atime_quantum. | ||
49 | atime_quantum=60(*) OCFS2 will not update atime unless this number | 54 | atime_quantum=60(*) OCFS2 will not update atime unless this number |
50 | of seconds has passed since the last update. | 55 | of seconds has passed since the last update. |
51 | Set to zero to always update atime. | 56 | Set to zero to always update atime. This option need |
57 | work with strictatime. | ||
52 | data=ordered (*) All data are forced directly out to the main file | 58 | data=ordered (*) All data are forced directly out to the main file |
53 | system prior to its metadata being committed to the | 59 | system prior to its metadata being committed to the |
54 | journal. | 60 | journal. |
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index b0b814d75ca1..db3b1aba32a3 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt | |||
@@ -574,6 +574,12 @@ The contents of each smp_affinity file is the same by default: | |||
574 | > cat /proc/irq/0/smp_affinity | 574 | > cat /proc/irq/0/smp_affinity |
575 | ffffffff | 575 | ffffffff |
576 | 576 | ||
577 | There is an alternate interface, smp_affinity_list which allows specifying | ||
578 | a cpu range instead of a bitmask: | ||
579 | |||
580 | > cat /proc/irq/0/smp_affinity_list | ||
581 | 1024-1031 | ||
582 | |||
577 | The default_smp_affinity mask applies to all non-active IRQs, which are the | 583 | The default_smp_affinity mask applies to all non-active IRQs, which are the |
578 | IRQs which have not yet been allocated/activated, and hence which lack a | 584 | IRQs which have not yet been allocated/activated, and hence which lack a |
579 | /proc/irq/[0-9]* directory. | 585 | /proc/irq/[0-9]* directory. |
@@ -583,12 +589,13 @@ reports itself as being attached. This hardware locality information does not | |||
583 | include information about any possible driver locality preference. | 589 | include information about any possible driver locality preference. |
584 | 590 | ||
585 | prof_cpu_mask specifies which CPUs are to be profiled by the system wide | 591 | prof_cpu_mask specifies which CPUs are to be profiled by the system wide |
586 | profiler. Default value is ffffffff (all cpus). | 592 | profiler. Default value is ffffffff (all cpus if there are only 32 of them). |
587 | 593 | ||
588 | The way IRQs are routed is handled by the IO-APIC, and it's Round Robin | 594 | The way IRQs are routed is handled by the IO-APIC, and it's Round Robin |
589 | between all the CPUs which are allowed to handle it. As usual the kernel has | 595 | between all the CPUs which are allowed to handle it. As usual the kernel has |
590 | more info than you and does a better job than you, so the defaults are the | 596 | more info than you and does a better job than you, so the defaults are the |
591 | best choice for almost everyone. | 597 | best choice for almost everyone. [Note this applies only to those IO-APIC's |
598 | that support "Round Robin" interrupt distribution.] | ||
592 | 599 | ||
593 | There are three more important subdirectories in /proc: net, scsi, and sys. | 600 | There are three more important subdirectories in /proc: net, scsi, and sys. |
594 | The general rule is that the contents, or even the existence of these | 601 | The general rule is that the contents, or even the existence of these |
diff --git a/Documentation/filesystems/ubifs.txt b/Documentation/filesystems/ubifs.txt index d7b13b01e980..8e4fab639d9c 100644 --- a/Documentation/filesystems/ubifs.txt +++ b/Documentation/filesystems/ubifs.txt | |||
@@ -115,28 +115,8 @@ ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs | |||
115 | Module Parameters for Debugging | 115 | Module Parameters for Debugging |
116 | =============================== | 116 | =============================== |
117 | 117 | ||
118 | When UBIFS has been compiled with debugging enabled, there are 3 module | 118 | When UBIFS has been compiled with debugging enabled, there are 2 module |
119 | parameters that are available to control aspects of testing and debugging. | 119 | parameters that are available to control aspects of testing and debugging. |
120 | The parameters are unsigned integers where each bit controls an option. | ||
121 | The parameters are: | ||
122 | |||
123 | debug_msgs Selects which debug messages to display, as follows: | ||
124 | |||
125 | Message Type Flag value | ||
126 | |||
127 | General messages 1 | ||
128 | Journal messages 2 | ||
129 | Mount messages 4 | ||
130 | Commit messages 8 | ||
131 | LEB search messages 16 | ||
132 | Budgeting messages 32 | ||
133 | Garbage collection messages 64 | ||
134 | Tree Node Cache (TNC) messages 128 | ||
135 | LEB properties (lprops) messages 256 | ||
136 | Input/output messages 512 | ||
137 | Log messages 1024 | ||
138 | Scan messages 2048 | ||
139 | Recovery messages 4096 | ||
140 | 120 | ||
141 | debug_chks Selects extra checks that UBIFS can do while running: | 121 | debug_chks Selects extra checks that UBIFS can do while running: |
142 | 122 | ||
@@ -154,11 +134,9 @@ debug_tsts Selects a mode of testing, as follows: | |||
154 | 134 | ||
155 | Test mode Flag value | 135 | Test mode Flag value |
156 | 136 | ||
157 | Force in-the-gaps method 2 | ||
158 | Failure mode for recovery testing 4 | 137 | Failure mode for recovery testing 4 |
159 | 138 | ||
160 | For example, set debug_msgs to 5 to display General messages and Mount | 139 | For example, set debug_chks to 3 to enable general and TNC checks. |
161 | messages. | ||
162 | 140 | ||
163 | 141 | ||
164 | References | 142 | References |
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 21a7dc467bba..88b9f5519af9 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt | |||
@@ -211,7 +211,7 @@ struct super_operations { | |||
211 | struct inode *(*alloc_inode)(struct super_block *sb); | 211 | struct inode *(*alloc_inode)(struct super_block *sb); |
212 | void (*destroy_inode)(struct inode *); | 212 | void (*destroy_inode)(struct inode *); |
213 | 213 | ||
214 | void (*dirty_inode) (struct inode *); | 214 | void (*dirty_inode) (struct inode *, int flags); |
215 | int (*write_inode) (struct inode *, int); | 215 | int (*write_inode) (struct inode *, int); |
216 | void (*drop_inode) (struct inode *); | 216 | void (*drop_inode) (struct inode *); |
217 | void (*delete_inode) (struct inode *); | 217 | void (*delete_inode) (struct inode *); |
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 7bff3e4f35df..3fc0c31a6f5d 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt | |||
@@ -39,6 +39,12 @@ When mounting an XFS filesystem, the following options are accepted. | |||
39 | drive level write caching to be enabled, for devices that | 39 | drive level write caching to be enabled, for devices that |
40 | support write barriers. | 40 | support write barriers. |
41 | 41 | ||
42 | discard | ||
43 | Issue command to let the block device reclaim space freed by the | ||
44 | filesystem. This is useful for SSD devices, thinly provisioned | ||
45 | LUNs and virtual machine images, but may have a performance | ||
46 | impact. This option is incompatible with the nodelaylog option. | ||
47 | |||
42 | dmapi | 48 | dmapi |
43 | Enable the DMAPI (Data Management API) event callouts. | 49 | Enable the DMAPI (Data Management API) event callouts. |
44 | Use with the "mtpt" option. | 50 | Use with the "mtpt" option. |
diff --git a/Documentation/usb/hiddev.txt b/Documentation/hid/hiddev.txt index 6e8c9f1d2f22..6e8c9f1d2f22 100644 --- a/Documentation/usb/hiddev.txt +++ b/Documentation/hid/hiddev.txt | |||
diff --git a/Documentation/hid/hidraw.txt b/Documentation/hid/hidraw.txt new file mode 100644 index 000000000000..029e6cb9a7e8 --- /dev/null +++ b/Documentation/hid/hidraw.txt | |||
@@ -0,0 +1,119 @@ | |||
1 | HIDRAW - Raw Access to USB and Bluetooth Human Interface Devices | ||
2 | ================================================================== | ||
3 | |||
4 | The hidraw driver provides a raw interface to USB and Bluetooth Human | ||
5 | Interface Devices (HIDs). It differs from hiddev in that reports sent and | ||
6 | received are not parsed by the HID parser, but are sent to and received from | ||
7 | the device unmodified. | ||
8 | |||
9 | Hidraw should be used if the userspace application knows exactly how to | ||
10 | communicate with the hardware device, and is able to construct the HID | ||
11 | reports manually. This is often the case when making userspace drivers for | ||
12 | custom HID devices. | ||
13 | |||
14 | Hidraw is also useful for communicating with non-conformant HID devices | ||
15 | which send and receive data in a way that is inconsistent with their report | ||
16 | descriptors. Because hiddev parses reports which are sent and received | ||
17 | through it, checking them against the device's report descriptor, such | ||
18 | communication with these non-conformant devices is impossible using hiddev. | ||
19 | Hidraw is the only alternative, short of writing a custom kernel driver, for | ||
20 | these non-conformant devices. | ||
21 | |||
22 | A benefit of hidraw is that its use by userspace applications is independent | ||
23 | of the underlying hardware type. Currently, Hidraw is implemented for USB | ||
24 | and Bluetooth. In the future, as new hardware bus types are developed which | ||
25 | use the HID specification, hidraw will be expanded to add support for these | ||
26 | new bus types. | ||
27 | |||
28 | Hidraw uses a dynamic major number, meaning that udev should be relied on to | ||
29 | create hidraw device nodes. Udev will typically create the device nodes | ||
30 | directly under /dev (eg: /dev/hidraw0). As this location is distribution- | ||
31 | and udev rule-dependent, applications should use libudev to locate hidraw | ||
32 | devices attached to the system. There is a tutorial on libudev with a | ||
33 | working example at: | ||
34 | http://www.signal11.us/oss/udev/ | ||
35 | |||
36 | The HIDRAW API | ||
37 | --------------- | ||
38 | |||
39 | read() | ||
40 | ------- | ||
41 | read() will read a queued report received from the HID device. On USB | ||
42 | devices, the reports read using read() are the reports sent from the device | ||
43 | on the INTERRUPT IN endpoint. By default, read() will block until there is | ||
44 | a report available to be read. read() can be made non-blocking, by passing | ||
45 | the O_NONBLOCK flag to open(), or by setting the O_NONBLOCK flag using | ||
46 | fcntl(). | ||
47 | |||
48 | On a device which uses numbered reports, the first byte of the returned data | ||
49 | will be the report number; the report data follows, beginning in the second | ||
50 | byte. For devices which do not use numbered reports, the report data | ||
51 | will begin at the first byte. | ||
52 | |||
53 | write() | ||
54 | -------- | ||
55 | The write() function will write a report to the device. For USB devices, if | ||
56 | the device has an INTERRUPT OUT endpoint, the report will be sent on that | ||
57 | endpoint. If it does not, the report will be sent over the control endpoint, | ||
58 | using a SET_REPORT transfer. | ||
59 | |||
60 | The first byte of the buffer passed to write() should be set to the report | ||
61 | number. If the device does not use numbered reports, the first byte should | ||
62 | be set to 0. The report data itself should begin at the second byte. | ||
63 | |||
64 | ioctl() | ||
65 | -------- | ||
66 | Hidraw supports the following ioctls: | ||
67 | |||
68 | HIDIOCGRDESCSIZE: Get Report Descriptor Size | ||
69 | This ioctl will get the size of the device's report descriptor. | ||
70 | |||
71 | HIDIOCGRDESC: Get Report Descriptor | ||
72 | This ioctl returns the device's report descriptor using a | ||
73 | hidraw_report_descriptor struct. Make sure to set the size field of the | ||
74 | hidraw_report_descriptor struct to the size returned from HIDIOCGRDESCSIZE. | ||
75 | |||
76 | HIDIOCGRAWINFO: Get Raw Info | ||
77 | This ioctl will return a hidraw_devinfo struct containing the bus type, the | ||
78 | vendor ID (VID), and product ID (PID) of the device. The bus type can be one | ||
79 | of: | ||
80 | BUS_USB | ||
81 | BUS_HIL | ||
82 | BUS_BLUETOOTH | ||
83 | BUS_VIRTUAL | ||
84 | which are defined in linux/input.h. | ||
85 | |||
86 | HIDIOCGRAWNAME(len): Get Raw Name | ||
87 | This ioctl returns a string containing the vendor and product strings of | ||
88 | the device. The returned string is Unicode, UTF-8 encoded. | ||
89 | |||
90 | HIDIOCGRAWPHYS(len): Get Physical Address | ||
91 | This ioctl returns a string representing the physical address of the device. | ||
92 | For USB devices, the string contains the physical path to the device (the | ||
93 | USB controller, hubs, ports, etc). For Bluetooth devices, the string | ||
94 | contains the hardware (MAC) address of the device. | ||
95 | |||
96 | HIDIOCSFEATURE(len): Send a Feature Report | ||
97 | This ioctl will send a feature report to the device. Per the HID | ||
98 | specification, feature reports are always sent using the control endpoint. | ||
99 | Set the first byte of the supplied buffer to the report number. For devices | ||
100 | which do not use numbered reports, set the first byte to 0. The report data | ||
101 | begins in the second byte. Make sure to set len accordingly, to one more | ||
102 | than the length of the report (to account for the report number). | ||
103 | |||
104 | HIDIOCGFEATURE(len): Get a Feature Report | ||
105 | This ioctl will request a feature report from the device using the control | ||
106 | endpoint. The first byte of the supplied buffer should be set to the report | ||
107 | number of the requested report. For devices which do not use numbered | ||
108 | reports, set the first byte to 0. The report will be returned starting at | ||
109 | the first byte of the buffer (ie: the report number is not returned). | ||
110 | |||
111 | Example | ||
112 | --------- | ||
113 | In samples/, find hid-example.c, which shows examples of read(), write(), | ||
114 | and all the ioctls for hidraw. The code may be used by anyone for any | ||
115 | purpose, and can serve as a starting point for developing applications using | ||
116 | hidraw. | ||
117 | |||
118 | Document by: | ||
119 | Alan Ott <alan@signal11.us>, Signal 11 Software | ||
diff --git a/Documentation/hwmon/adm1275 b/Documentation/hwmon/adm1275 new file mode 100644 index 000000000000..6a3a6476cf20 --- /dev/null +++ b/Documentation/hwmon/adm1275 | |||
@@ -0,0 +1,60 @@ | |||
1 | Kernel driver adm1275 | ||
2 | ===================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Analog Devices ADM1275 | ||
6 | Prefix: 'adm1275' | ||
7 | Addresses scanned: - | ||
8 | Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1275.pdf | ||
9 | |||
10 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | ||
11 | |||
12 | |||
13 | Description | ||
14 | ----------- | ||
15 | |||
16 | This driver supports hardware montoring for Analog Devices ADM1275 Hot-Swap | ||
17 | Controller and Digital Power Monitor. | ||
18 | |||
19 | The ADM1275 is a hot-swap controller that allows a circuit board to be removed | ||
20 | from or inserted into a live backplane. It also features current and voltage | ||
21 | readback via an integrated 12-bit analog-to-digital converter (ADC), accessed | ||
22 | using a PMBus. interface. | ||
23 | |||
24 | The driver is a client driver to the core PMBus driver. Please see | ||
25 | Documentation/hwmon/pmbus for details on PMBus client drivers. | ||
26 | |||
27 | |||
28 | Usage Notes | ||
29 | ----------- | ||
30 | |||
31 | This driver does not auto-detect devices. You will have to instantiate the | ||
32 | devices explicitly. Please see Documentation/i2c/instantiating-devices for | ||
33 | details. | ||
34 | |||
35 | |||
36 | Platform data support | ||
37 | --------------------- | ||
38 | |||
39 | The driver supports standard PMBus driver platform data. Please see | ||
40 | Documentation/hwmon/pmbus for details. | ||
41 | |||
42 | |||
43 | Sysfs entries | ||
44 | ------------- | ||
45 | |||
46 | The following attributes are supported. Limits are read-write; all other | ||
47 | attributes are read-only. | ||
48 | |||
49 | in1_label "vin1" or "vout1" depending on chip variant and | ||
50 | configuration. | ||
51 | in1_input Measured voltage. From READ_VOUT register. | ||
52 | in1_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register. | ||
53 | in1_max Maximum voltage. From VOUT_OV_WARN_LIMIT register. | ||
54 | in1_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. | ||
55 | in1_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. | ||
56 | |||
57 | curr1_label "iout1" | ||
58 | curr1_input Measured current. From READ_IOUT register. | ||
59 | curr1_max Maximum current. From IOUT_OC_WARN_LIMIT register. | ||
60 | curr1_max_alarm Current high alarm. From IOUT_OC_WARN_LIMIT register. | ||
diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index 25568f844804..f85e913a3401 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp | |||
@@ -15,8 +15,13 @@ Author: Rudolf Marek | |||
15 | 15 | ||
16 | Description | 16 | Description |
17 | ----------- | 17 | ----------- |
18 | This driver permits reading the DTS (Digital Temperature Sensor) embedded | ||
19 | inside Intel CPUs. This driver can read both the per-core and per-package | ||
20 | temperature using the appropriate sensors. The per-package sensor is new; | ||
21 | as of now, it is present only in the SandyBridge platform. The driver will | ||
22 | show the temperature of all cores inside a package under a single device | ||
23 | directory inside hwmon. | ||
18 | 24 | ||
19 | This driver permits reading temperature sensor embedded inside Intel Core CPU. | ||
20 | Temperature is measured in degrees Celsius and measurement resolution is | 25 | Temperature is measured in degrees Celsius and measurement resolution is |
21 | 1 degree C. Valid temperatures are from 0 to TjMax degrees C, because | 26 | 1 degree C. Valid temperatures are from 0 to TjMax degrees C, because |
22 | the actual value of temperature register is in fact a delta from TjMax. | 27 | the actual value of temperature register is in fact a delta from TjMax. |
@@ -27,13 +32,15 @@ mechanism will perform actions to forcibly cool down the processor. Alarm | |||
27 | may be raised, if the temperature grows enough (more than TjMax) to trigger | 32 | may be raised, if the temperature grows enough (more than TjMax) to trigger |
28 | the Out-Of-Spec bit. Following table summarizes the exported sysfs files: | 33 | the Out-Of-Spec bit. Following table summarizes the exported sysfs files: |
29 | 34 | ||
30 | temp1_input - Core temperature (in millidegrees Celsius). | 35 | All Sysfs entries are named with their core_id (represented here by 'X'). |
31 | temp1_max - All cooling devices should be turned on (on Core2). | 36 | tempX_input - Core temperature (in millidegrees Celsius). |
32 | temp1_crit - Maximum junction temperature (in millidegrees Celsius). | 37 | tempX_max - All cooling devices should be turned on (on Core2). |
33 | temp1_crit_alarm - Set when Out-of-spec bit is set, never clears. | 38 | tempX_crit - Maximum junction temperature (in millidegrees Celsius). |
39 | tempX_crit_alarm - Set when Out-of-spec bit is set, never clears. | ||
34 | Correct CPU operation is no longer guaranteed. | 40 | Correct CPU operation is no longer guaranteed. |
35 | temp1_label - Contains string "Core X", where X is processor | 41 | tempX_label - Contains string "Core X", where X is processor |
36 | number. | 42 | number. For Package temp, this will be "Physical id Y", |
43 | where Y is the package number. | ||
37 | 44 | ||
38 | The TjMax temperature is set to 85 degrees C if undocumented model specific | 45 | The TjMax temperature is set to 85 degrees C if undocumented model specific |
39 | register (UMSR) 0xee has bit 30 set. If not the TjMax is 100 degrees C as | 46 | register (UMSR) 0xee has bit 30 set. If not the TjMax is 100 degrees C as |
diff --git a/Documentation/hwmon/emc6w201 b/Documentation/hwmon/emc6w201 new file mode 100644 index 000000000000..32f355aaf56b --- /dev/null +++ b/Documentation/hwmon/emc6w201 | |||
@@ -0,0 +1,42 @@ | |||
1 | Kernel driver emc6w201 | ||
2 | ====================== | ||
3 | |||
4 | Supported chips: | ||
5 | * SMSC EMC6W201 | ||
6 | Prefix: 'emc6w201' | ||
7 | Addresses scanned: I2C 0x2c, 0x2d, 0x2e | ||
8 | Datasheet: Not public | ||
9 | |||
10 | Author: Jean Delvare <khali@linux-fr.org> | ||
11 | |||
12 | |||
13 | Description | ||
14 | ----------- | ||
15 | |||
16 | From the datasheet: | ||
17 | |||
18 | "The EMC6W201 is an environmental monitoring device with automatic fan | ||
19 | control capability and enhanced system acoustics for noise suppression. | ||
20 | This ACPI compliant device provides hardware monitoring for up to six | ||
21 | voltages (including its own VCC) and five external thermal sensors, | ||
22 | measures the speed of up to five fans, and controls the speed of | ||
23 | multiple DC fans using three Pulse Width Modulator (PWM) outputs. Note | ||
24 | that it is possible to control more than three fans by connecting two | ||
25 | fans to one PWM output. The EMC6W201 will be available in a 36-pin | ||
26 | QFN package." | ||
27 | |||
28 | The device is functionally close to the EMC6D100 series, but is | ||
29 | register-incompatible. | ||
30 | |||
31 | The driver currently only supports the monitoring of the voltages, | ||
32 | temperatures and fan speeds. Limits can be changed. Alarms are not | ||
33 | supported, and neither is fan speed control. | ||
34 | |||
35 | |||
36 | Known Systems With EMC6W201 | ||
37 | --------------------------- | ||
38 | |||
39 | The EMC6W201 is a rare device, only found on a few systems, made in | ||
40 | 2005 and 2006. Known systems with this device: | ||
41 | * Dell Precision 670 workstation | ||
42 | * Gigabyte 2CEWH mainboard | ||
diff --git a/Documentation/hwmon/f71882fg b/Documentation/hwmon/f71882fg index df02245d1419..de91c0db5846 100644 --- a/Documentation/hwmon/f71882fg +++ b/Documentation/hwmon/f71882fg | |||
@@ -6,6 +6,10 @@ Supported chips: | |||
6 | Prefix: 'f71808e' | 6 | Prefix: 'f71808e' |
7 | Addresses scanned: none, address read from Super I/O config space | 7 | Addresses scanned: none, address read from Super I/O config space |
8 | Datasheet: Not public | 8 | Datasheet: Not public |
9 | * Fintek F71808A | ||
10 | Prefix: 'f71808a' | ||
11 | Addresses scanned: none, address read from Super I/O config space | ||
12 | Datasheet: Not public | ||
9 | * Fintek F71858FG | 13 | * Fintek F71858FG |
10 | Prefix: 'f71858fg' | 14 | Prefix: 'f71858fg' |
11 | Addresses scanned: none, address read from Super I/O config space | 15 | Addresses scanned: none, address read from Super I/O config space |
@@ -18,6 +22,10 @@ Supported chips: | |||
18 | Prefix: 'f71869' | 22 | Prefix: 'f71869' |
19 | Addresses scanned: none, address read from Super I/O config space | 23 | Addresses scanned: none, address read from Super I/O config space |
20 | Datasheet: Available from the Fintek website | 24 | Datasheet: Available from the Fintek website |
25 | * Fintek F71869A | ||
26 | Prefix: 'f71869a' | ||
27 | Addresses scanned: none, address read from Super I/O config space | ||
28 | Datasheet: Not public | ||
21 | * Fintek F71882FG and F71883FG | 29 | * Fintek F71882FG and F71883FG |
22 | Prefix: 'f71882fg' | 30 | Prefix: 'f71882fg' |
23 | Addresses scanned: none, address read from Super I/O config space | 31 | Addresses scanned: none, address read from Super I/O config space |
diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power new file mode 100644 index 000000000000..a92918e0bd69 --- /dev/null +++ b/Documentation/hwmon/fam15h_power | |||
@@ -0,0 +1,37 @@ | |||
1 | Kernel driver fam15h_power | ||
2 | ========================== | ||
3 | |||
4 | Supported chips: | ||
5 | * AMD Family 15h Processors | ||
6 | |||
7 | Prefix: 'fam15h_power' | ||
8 | Addresses scanned: PCI space | ||
9 | Datasheets: | ||
10 | BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors | ||
11 | (not yet published) | ||
12 | |||
13 | Author: Andreas Herrmann <andreas.herrmann3@amd.com> | ||
14 | |||
15 | Description | ||
16 | ----------- | ||
17 | |||
18 | This driver permits reading of registers providing power information | ||
19 | of AMD Family 15h processors. | ||
20 | |||
21 | For AMD Family 15h processors the following power values can be | ||
22 | calculated using different processor northbridge function registers: | ||
23 | |||
24 | * BasePwrWatts: Specifies in watts the maximum amount of power | ||
25 | consumed by the processor for NB and logic external to the core. | ||
26 | * ProcessorPwrWatts: Specifies in watts the maximum amount of power | ||
27 | the processor can support. | ||
28 | * CurrPwrWatts: Specifies in watts the current amount of power being | ||
29 | consumed by the processor. | ||
30 | |||
31 | This driver provides ProcessorPwrWatts and CurrPwrWatts: | ||
32 | * power1_crit (ProcessorPwrWatts) | ||
33 | * power1_input (CurrPwrWatts) | ||
34 | |||
35 | On multi-node processors the calculated value is for the entire | ||
36 | package and not for a single node. Thus the driver creates sysfs | ||
37 | attributes only for internal node0 of a multi-node processor. | ||
diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp index d2b56a4fd1f5..a10f73624ad3 100644 --- a/Documentation/hwmon/k10temp +++ b/Documentation/hwmon/k10temp | |||
@@ -9,8 +9,9 @@ Supported chips: | |||
9 | Socket S1G3: Athlon II, Sempron, Turion II | 9 | Socket S1G3: Athlon II, Sempron, Turion II |
10 | * AMD Family 11h processors: | 10 | * AMD Family 11h processors: |
11 | Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) | 11 | Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) |
12 | * AMD Family 12h processors: "Llano" | 12 | * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series) |
13 | * AMD Family 14h processors: "Brazos" (C/E/G-Series) | 13 | * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series) |
14 | * AMD Family 15h processors: "Bulldozer" | ||
14 | 15 | ||
15 | Prefix: 'k10temp' | 16 | Prefix: 'k10temp' |
16 | Addresses scanned: PCI space | 17 | Addresses scanned: PCI space |
@@ -19,12 +20,16 @@ Supported chips: | |||
19 | http://support.amd.com/us/Processor_TechDocs/31116.pdf | 20 | http://support.amd.com/us/Processor_TechDocs/31116.pdf |
20 | BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors: | 21 | BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors: |
21 | http://support.amd.com/us/Processor_TechDocs/41256.pdf | 22 | http://support.amd.com/us/Processor_TechDocs/41256.pdf |
23 | BIOS and Kernel Developer's Guide (BKDG) for AMD Family 12h Processors: | ||
24 | http://support.amd.com/us/Processor_TechDocs/41131.pdf | ||
22 | BIOS and Kernel Developer's Guide (BKDG) for AMD Family 14h Models 00h-0Fh Processors: | 25 | BIOS and Kernel Developer's Guide (BKDG) for AMD Family 14h Models 00h-0Fh Processors: |
23 | http://support.amd.com/us/Processor_TechDocs/43170.pdf | 26 | http://support.amd.com/us/Processor_TechDocs/43170.pdf |
24 | Revision Guide for AMD Family 10h Processors: | 27 | Revision Guide for AMD Family 10h Processors: |
25 | http://support.amd.com/us/Processor_TechDocs/41322.pdf | 28 | http://support.amd.com/us/Processor_TechDocs/41322.pdf |
26 | Revision Guide for AMD Family 11h Processors: | 29 | Revision Guide for AMD Family 11h Processors: |
27 | http://support.amd.com/us/Processor_TechDocs/41788.pdf | 30 | http://support.amd.com/us/Processor_TechDocs/41788.pdf |
31 | Revision Guide for AMD Family 12h Processors: | ||
32 | http://support.amd.com/us/Processor_TechDocs/44739.pdf | ||
28 | Revision Guide for AMD Family 14h Models 00h-0Fh Processors: | 33 | Revision Guide for AMD Family 14h Models 00h-0Fh Processors: |
29 | http://support.amd.com/us/Processor_TechDocs/47534.pdf | 34 | http://support.amd.com/us/Processor_TechDocs/47534.pdf |
30 | AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks: | 35 | AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks: |
@@ -40,7 +45,7 @@ Description | |||
40 | ----------- | 45 | ----------- |
41 | 46 | ||
42 | This driver permits reading of the internal temperature sensor of AMD | 47 | This driver permits reading of the internal temperature sensor of AMD |
43 | Family 10h/11h/12h/14h processors. | 48 | Family 10h/11h/12h/14h/15h processors. |
44 | 49 | ||
45 | All these processors have a sensor, but on those for Socket F or AM2+, | 50 | All these processors have a sensor, but on those for Socket F or AM2+, |
46 | the sensor may return inconsistent values (erratum 319). The driver | 51 | the sensor may return inconsistent values (erratum 319). The driver |
diff --git a/Documentation/hwmon/max16065 b/Documentation/hwmon/max16065 new file mode 100644 index 000000000000..44b4f61e04f9 --- /dev/null +++ b/Documentation/hwmon/max16065 | |||
@@ -0,0 +1,98 @@ | |||
1 | Kernel driver max16065 | ||
2 | ====================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Maxim MAX16065, MAX16066 | ||
6 | Prefixes: 'max16065', 'max16066' | ||
7 | Addresses scanned: - | ||
8 | Datasheet: | ||
9 | http://datasheets.maxim-ic.com/en/ds/MAX16065-MAX16066.pdf | ||
10 | * Maxim MAX16067 | ||
11 | Prefix: 'max16067' | ||
12 | Addresses scanned: - | ||
13 | Datasheet: | ||
14 | http://datasheets.maxim-ic.com/en/ds/MAX16067.pdf | ||
15 | * Maxim MAX16068 | ||
16 | Prefix: 'max16068' | ||
17 | Addresses scanned: - | ||
18 | Datasheet: | ||
19 | http://datasheets.maxim-ic.com/en/ds/MAX16068.pdf | ||
20 | * Maxim MAX16070/MAX16071 | ||
21 | Prefixes: 'max16070', 'max16071' | ||
22 | Addresses scanned: - | ||
23 | Datasheet: | ||
24 | http://datasheets.maxim-ic.com/en/ds/MAX16070-MAX16071.pdf | ||
25 | |||
26 | |||
27 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | ||
28 | |||
29 | |||
30 | Description | ||
31 | ----------- | ||
32 | |||
33 | [From datasheets] The MAX16065/MAX16066 flash-configurable system managers | ||
34 | monitor and sequence multiple system voltages. The MAX16065/MAX16066 can also | ||
35 | accurately monitor (+/-2.5%) one current channel using a dedicated high-side | ||
36 | current-sense amplifier. The MAX16065 manages up to twelve system voltages | ||
37 | simultaneously, and the MAX16066 manages up to eight supply voltages. | ||
38 | |||
39 | The MAX16067 flash-configurable system manager monitors and sequences multiple | ||
40 | system voltages. The MAX16067 manages up to six system voltages simultaneously. | ||
41 | |||
42 | The MAX16068 flash-configurable system manager monitors and manages up to six | ||
43 | system voltages simultaneously. | ||
44 | |||
45 | The MAX16070/MAX16071 flash-configurable system monitors supervise multiple | ||
46 | system voltages. The MAX16070/MAX16071 can also accurately monitor (+/-2.5%) | ||
47 | one current channel using a dedicated high-side current-sense amplifier. The | ||
48 | MAX16070 monitors up to twelve system voltages simultaneously, and the MAX16071 | ||
49 | monitors up to eight supply voltages. | ||
50 | |||
51 | Each monitored channel has its own low and high critical limits. MAX16065, | ||
52 | MAX16066, MAX16070, and MAX16071 support an additional limit which is | ||
53 | configurable as either low or high secondary limit. MAX16065, MAX16066, | ||
54 | MAX16070, and MAX16071 also support supply current monitoring. | ||
55 | |||
56 | |||
57 | Usage Notes | ||
58 | ----------- | ||
59 | |||
60 | This driver does not probe for devices, since there is no register which | ||
61 | can be safely used to identify the chip. You will have to instantiate | ||
62 | the devices explicitly. Please see Documentation/i2c/instantiating-devices for | ||
63 | details. | ||
64 | |||
65 | |||
66 | Sysfs entries | ||
67 | ------------- | ||
68 | |||
69 | in[0-11]_input Input voltage measurements. | ||
70 | |||
71 | in12_input Voltage on CSP (Current Sense Positive) pin. | ||
72 | Only if the chip supports current sensing and if | ||
73 | current sensing is enabled. | ||
74 | |||
75 | in[0-11]_min Low warning limit. | ||
76 | Supported on MAX16065, MAX16066, MAX16070, and MAX16071 | ||
77 | only. | ||
78 | |||
79 | in[0-11]_max High warning limit. | ||
80 | Supported on MAX16065, MAX16066, MAX16070, and MAX16071 | ||
81 | only. | ||
82 | |||
83 | Either low or high warning limits are supported | ||
84 | (depending on chip configuration), but not both. | ||
85 | |||
86 | in[0-11]_lcrit Low critical limit. | ||
87 | |||
88 | in[0-11]_crit High critical limit. | ||
89 | |||
90 | in[0-11]_alarm Input voltage alarm. | ||
91 | |||
92 | curr1_input Current sense input; only if the chip supports current | ||
93 | sensing and if current sensing is enabled. | ||
94 | Displayed current assumes 0.001 Ohm current sense | ||
95 | resistor. | ||
96 | |||
97 | curr1_alarm Overcurrent alarm; only if the chip supports current | ||
98 | sensing and if current sensing is enabled. | ||
diff --git a/Documentation/hwmon/max6642 b/Documentation/hwmon/max6642 new file mode 100644 index 000000000000..afbd3e4942e2 --- /dev/null +++ b/Documentation/hwmon/max6642 | |||
@@ -0,0 +1,21 @@ | |||
1 | Kernel driver max6642 | ||
2 | ===================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Maxim MAX6642 | ||
6 | Prefix: 'max6642' | ||
7 | Addresses scanned: I2C 0x48-0x4f | ||
8 | Datasheet: Publicly available at the Maxim website | ||
9 | http://datasheets.maxim-ic.com/en/ds/MAX6642.pdf | ||
10 | |||
11 | Authors: | ||
12 | Per Dalen <per.dalen@appeartv.com> | ||
13 | |||
14 | Description | ||
15 | ----------- | ||
16 | |||
17 | The MAX6642 is a digital temperature sensor. It senses its own temperature as | ||
18 | well as the temperature on one external diode. | ||
19 | |||
20 | All temperature values are given in degrees Celsius. Resolution | ||
21 | is 0.25 degree for the local temperature and for the remote temperature. | ||
diff --git a/Documentation/hwmon/max6650 b/Documentation/hwmon/max6650 index c565650fcfc6..58d9644a2bde 100644 --- a/Documentation/hwmon/max6650 +++ b/Documentation/hwmon/max6650 | |||
@@ -2,9 +2,13 @@ Kernel driver max6650 | |||
2 | ===================== | 2 | ===================== |
3 | 3 | ||
4 | Supported chips: | 4 | Supported chips: |
5 | * Maxim 6650 / 6651 | 5 | * Maxim MAX6650 |
6 | Prefix: 'max6650' | 6 | Prefix: 'max6650' |
7 | Addresses scanned: I2C 0x1b, 0x1f, 0x48, 0x4b | 7 | Addresses scanned: none |
8 | Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf | ||
9 | * Maxim MAX6651 | ||
10 | Prefix: 'max6651' | ||
11 | Addresses scanned: none | ||
8 | Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf | 12 | Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf |
9 | 13 | ||
10 | Authors: | 14 | Authors: |
@@ -15,10 +19,10 @@ Authors: | |||
15 | Description | 19 | Description |
16 | ----------- | 20 | ----------- |
17 | 21 | ||
18 | This driver implements support for the Maxim 6650/6651 | 22 | This driver implements support for the Maxim MAX6650 and MAX6651. |
19 | 23 | ||
20 | The 2 devices are very similar, but the Maxim 6550 has a reduced feature | 24 | The 2 devices are very similar, but the MAX6550 has a reduced feature |
21 | set, e.g. only one fan-input, instead of 4 for the 6651. | 25 | set, e.g. only one fan-input, instead of 4 for the MAX6651. |
22 | 26 | ||
23 | The driver is not able to distinguish between the 2 devices. | 27 | The driver is not able to distinguish between the 2 devices. |
24 | 28 | ||
@@ -36,6 +40,13 @@ fan1_div rw sets the speed range the inputs can handle. Legal | |||
36 | values are 1, 2, 4, and 8. Use lower values for | 40 | values are 1, 2, 4, and 8. Use lower values for |
37 | faster fans. | 41 | faster fans. |
38 | 42 | ||
43 | Usage notes | ||
44 | ----------- | ||
45 | |||
46 | This driver does not auto-detect devices. You will have to instantiate the | ||
47 | devices explicitly. Please see Documentation/i2c/instantiating-devices for | ||
48 | details. | ||
49 | |||
39 | Module parameters | 50 | Module parameters |
40 | ----------------- | 51 | ----------------- |
41 | 52 | ||
diff --git a/Documentation/hwmon/pkgtemp b/Documentation/hwmon/pkgtemp deleted file mode 100644 index c8e1fb0fadd3..000000000000 --- a/Documentation/hwmon/pkgtemp +++ /dev/null | |||
@@ -1,36 +0,0 @@ | |||
1 | Kernel driver pkgtemp | ||
2 | ====================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Intel family | ||
6 | Prefix: 'pkgtemp' | ||
7 | CPUID: | ||
8 | Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual | ||
9 | Volume 3A: System Programming Guide | ||
10 | |||
11 | Author: Fenghua Yu | ||
12 | |||
13 | Description | ||
14 | ----------- | ||
15 | |||
16 | This driver permits reading package level temperature sensor embedded inside | ||
17 | Intel CPU package. The sensors can be in core, uncore, memory controller, or | ||
18 | other components in a package. The feature is first implemented in Intel Sandy | ||
19 | Bridge platform. | ||
20 | |||
21 | Temperature is measured in degrees Celsius and measurement resolution is | ||
22 | 1 degree C. Valid temperatures are from 0 to TjMax degrees C, because the actual | ||
23 | value of temperature register is in fact a delta from TjMax. | ||
24 | |||
25 | Temperature known as TjMax is the maximum junction temperature of package. | ||
26 | We get this from MSR_IA32_TEMPERATURE_TARGET. If the MSR is not accessible, | ||
27 | we define TjMax as 100 degrees Celsius. At this temperature, protection | ||
28 | mechanism will perform actions to forcibly cool down the package. Alarm | ||
29 | may be raised, if the temperature grows enough (more than TjMax) to trigger | ||
30 | the Out-Of-Spec bit. Following table summarizes the exported sysfs files: | ||
31 | |||
32 | temp1_input - Package temperature (in millidegrees Celsius). | ||
33 | temp1_max - All cooling devices should be turned on. | ||
34 | temp1_crit - Maximum junction temperature (in millidegrees Celsius). | ||
35 | temp1_crit_alarm - Set when Out-of-spec bit is set, never clears. | ||
36 | Correct CPU operation is no longer guaranteed. | ||
diff --git a/Documentation/hwmon/sht15 b/Documentation/hwmon/sht15 new file mode 100644 index 000000000000..02850bdfac18 --- /dev/null +++ b/Documentation/hwmon/sht15 | |||
@@ -0,0 +1,74 @@ | |||
1 | Kernel driver sht15 | ||
2 | =================== | ||
3 | |||
4 | Authors: | ||
5 | * Wouter Horre | ||
6 | * Jonathan Cameron | ||
7 | * Vivien Didelot <vivien.didelot@savoirfairelinux.com> | ||
8 | * Jerome Oufella <jerome.oufella@savoirfairelinux.com> | ||
9 | |||
10 | Supported chips: | ||
11 | * Sensirion SHT10 | ||
12 | Prefix: 'sht10' | ||
13 | |||
14 | * Sensirion SHT11 | ||
15 | Prefix: 'sht11' | ||
16 | |||
17 | * Sensirion SHT15 | ||
18 | Prefix: 'sht15' | ||
19 | |||
20 | * Sensirion SHT71 | ||
21 | Prefix: 'sht71' | ||
22 | |||
23 | * Sensirion SHT75 | ||
24 | Prefix: 'sht75' | ||
25 | |||
26 | Datasheet: Publicly available at the Sensirion website | ||
27 | http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf | ||
28 | |||
29 | Description | ||
30 | ----------- | ||
31 | |||
32 | The SHT10, SHT11, SHT15, SHT71, and SHT75 are humidity and temperature | ||
33 | sensors. | ||
34 | |||
35 | The devices communicate using two GPIO lines. | ||
36 | |||
37 | Supported resolutions for the measurements are 14 bits for temperature and 12 | ||
38 | bits for humidity, or 12 bits for temperature and 8 bits for humidity. | ||
39 | |||
40 | The humidity calibration coefficients are programmed into an OTP memory on the | ||
41 | chip. These coefficients are used to internally calibrate the signals from the | ||
42 | sensors. Disabling the reload of those coefficients allows saving 10ms for each | ||
43 | measurement and decrease power consumption, while loosing on precision. | ||
44 | |||
45 | Some options may be set directly in the sht15_platform_data structure | ||
46 | or via sysfs attributes. | ||
47 | |||
48 | Notes: | ||
49 | * The regulator supply name is set to "vcc". | ||
50 | * If a CRC validation fails, a soft reset command is sent, which resets | ||
51 | status register to its hardware default value, but the driver will try to | ||
52 | restore the previous device configuration. | ||
53 | |||
54 | Platform data | ||
55 | ------------- | ||
56 | |||
57 | * checksum: | ||
58 | set it to true to enable CRC validation of the readings (default to false). | ||
59 | * no_otp_reload: | ||
60 | flag to indicate not to reload from OTP (default to false). | ||
61 | * low_resolution: | ||
62 | flag to indicate the temp/humidity resolution to use (default to false). | ||
63 | |||
64 | Sysfs interface | ||
65 | --------------- | ||
66 | |||
67 | * temp1_input: temperature input | ||
68 | * humidity1_input: humidity input | ||
69 | * heater_enable: write 1 in this attribute to enable the on-chip heater, | ||
70 | 0 to disable it. Be careful not to enable the heater | ||
71 | for too long. | ||
72 | * temp1_fault: if 1, this means that the voltage is low (below 2.47V) and | ||
73 | measurement may be invalid. | ||
74 | * humidity1_fault: same as temp1_fault. | ||
diff --git a/Documentation/hwmon/ucd9000 b/Documentation/hwmon/ucd9000 new file mode 100644 index 000000000000..40ca6db50c48 --- /dev/null +++ b/Documentation/hwmon/ucd9000 | |||
@@ -0,0 +1,110 @@ | |||
1 | Kernel driver ucd9000 | ||
2 | ===================== | ||
3 | |||
4 | Supported chips: | ||
5 | * TI UCD90120, UCD90124, UCD9090, and UCD90910 | ||
6 | Prefixes: 'ucd90120', 'ucd90124', 'ucd9090', 'ucd90910' | ||
7 | Addresses scanned: - | ||
8 | Datasheets: | ||
9 | http://focus.ti.com/lit/ds/symlink/ucd90120.pdf | ||
10 | http://focus.ti.com/lit/ds/symlink/ucd90124.pdf | ||
11 | http://focus.ti.com/lit/ds/symlink/ucd9090.pdf | ||
12 | http://focus.ti.com/lit/ds/symlink/ucd90910.pdf | ||
13 | |||
14 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | ||
15 | |||
16 | |||
17 | Description | ||
18 | ----------- | ||
19 | |||
20 | From datasheets: | ||
21 | |||
22 | The UCD90120 Power Supply Sequencer and System Health Monitor monitors and | ||
23 | sequences up to 12 independent voltage rails. The device integrates a 12-bit | ||
24 | ADC with a 2.5V internal reference for monitoring up to 13 power supply voltage, | ||
25 | current, or temperature inputs. | ||
26 | |||
27 | The UCD90124 is a 12-rail PMBus/I2C addressable power-supply sequencer and | ||
28 | system-health monitor. The device integrates a 12-bit ADC for monitoring up to | ||
29 | 13 power-supply voltage, current, or temperature inputs. Twenty-six GPIO pins | ||
30 | can be used for power supply enables, power-on reset signals, external | ||
31 | interrupts, cascading, or other system functions. Twelve of these pins offer PWM | ||
32 | functionality. Using these pins, the UCD90124 offers support for fan control, | ||
33 | margining, and general-purpose PWM functions. | ||
34 | |||
35 | The UCD9090 is a 10-rail PMBus/I2C addressable power-supply sequencer and | ||
36 | monitor. The device integrates a 12-bit ADC for monitoring up to 10 power-supply | ||
37 | voltage inputs. Twenty-three GPIO pins can be used for power supply enables, | ||
38 | power-on reset signals, external interrupts, cascading, or other system | ||
39 | functions. Ten of these pins offer PWM functionality. Using these pins, the | ||
40 | UCD9090 offers support for margining, and general-purpose PWM functions. | ||
41 | |||
42 | The UCD90910 is a ten-rail I2C / PMBus addressable power-supply sequencer and | ||
43 | system-health monitor. The device integrates a 12-bit ADC for monitoring up to | ||
44 | 13 power-supply voltage, current, or temperature inputs. | ||
45 | |||
46 | This driver is a client driver to the core PMBus driver. Please see | ||
47 | Documentation/hwmon/pmbus for details on PMBus client drivers. | ||
48 | |||
49 | |||
50 | Usage Notes | ||
51 | ----------- | ||
52 | |||
53 | This driver does not auto-detect devices. You will have to instantiate the | ||
54 | devices explicitly. Please see Documentation/i2c/instantiating-devices for | ||
55 | details. | ||
56 | |||
57 | |||
58 | Platform data support | ||
59 | --------------------- | ||
60 | |||
61 | The driver supports standard PMBus driver platform data. Please see | ||
62 | Documentation/hwmon/pmbus for details. | ||
63 | |||
64 | |||
65 | Sysfs entries | ||
66 | ------------- | ||
67 | |||
68 | The following attributes are supported. Limits are read-write; all other | ||
69 | attributes are read-only. | ||
70 | |||
71 | in[1-12]_label "vout[1-12]". | ||
72 | in[1-12]_input Measured voltage. From READ_VOUT register. | ||
73 | in[1-12]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register. | ||
74 | in[1-12]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register. | ||
75 | in[1-12]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register. | ||
76 | in[1-12]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register. | ||
77 | in[1-12]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. | ||
78 | in[1-12]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. | ||
79 | in[1-12]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status. | ||
80 | in[1-12]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status. | ||
81 | |||
82 | curr[1-12]_label "iout[1-12]". | ||
83 | curr[1-12]_input Measured current. From READ_IOUT register. | ||
84 | curr[1-12]_max Maximum current. From IOUT_OC_WARN_LIMIT register. | ||
85 | curr[1-12]_lcrit Critical minumum output current. From IOUT_UC_FAULT_LIMIT | ||
86 | register. | ||
87 | curr[1-12]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register. | ||
88 | curr[1-12]_max_alarm Current high alarm. From IOUT_OC_WARNING status. | ||
89 | curr[1-12]_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status. | ||
90 | |||
91 | For each attribute index, either voltage or current is | ||
92 | reported, but not both. If voltage or current is | ||
93 | reported depends on the chip configuration. | ||
94 | |||
95 | temp[1-2]_input Measured temperatures. From READ_TEMPERATURE_1 and | ||
96 | READ_TEMPERATURE_2 registers. | ||
97 | temp[1-2]_max Maximum temperature. From OT_WARN_LIMIT register. | ||
98 | temp[1-2]_crit Critical high temperature. From OT_FAULT_LIMIT register. | ||
99 | temp[1-2]_max_alarm Temperature high alarm. | ||
100 | temp[1-2]_crit_alarm Temperature critical high alarm. | ||
101 | |||
102 | fan[1-4]_input Fan RPM. | ||
103 | fan[1-4]_alarm Fan alarm. | ||
104 | fan[1-4]_fault Fan fault. | ||
105 | |||
106 | Fan attributes are only available on chips supporting | ||
107 | fan control (UCD90124, UCD90910). Attribute files are | ||
108 | created only for enabled fans. | ||
109 | Note that even though UCD90910 supports up to 10 fans, | ||
110 | only up to four fans are currently supported. | ||
diff --git a/Documentation/hwmon/ucd9200 b/Documentation/hwmon/ucd9200 new file mode 100644 index 000000000000..3c58607f72fe --- /dev/null +++ b/Documentation/hwmon/ucd9200 | |||
@@ -0,0 +1,112 @@ | |||
1 | Kernel driver ucd9200 | ||
2 | ===================== | ||
3 | |||
4 | Supported chips: | ||
5 | * TI UCD9220, UCD9222, UCD9224, UCD9240, UCD9244, UCD9246, and UCD9248 | ||
6 | Prefixes: 'ucd9220', 'ucd9222', 'ucd9224', 'ucd9240', 'ucd9244', 'ucd9246', | ||
7 | 'ucd9248' | ||
8 | Addresses scanned: - | ||
9 | Datasheets: | ||
10 | http://focus.ti.com/lit/ds/symlink/ucd9220.pdf | ||
11 | http://focus.ti.com/lit/ds/symlink/ucd9222.pdf | ||
12 | http://focus.ti.com/lit/ds/symlink/ucd9224.pdf | ||
13 | http://focus.ti.com/lit/ds/symlink/ucd9240.pdf | ||
14 | http://focus.ti.com/lit/ds/symlink/ucd9244.pdf | ||
15 | http://focus.ti.com/lit/ds/symlink/ucd9246.pdf | ||
16 | http://focus.ti.com/lit/ds/symlink/ucd9248.pdf | ||
17 | |||
18 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | ||
19 | |||
20 | |||
21 | Description | ||
22 | ----------- | ||
23 | |||
24 | [From datasheets] UCD9220, UCD9222, UCD9224, UCD9240, UCD9244, UCD9246, and | ||
25 | UCD9248 are multi-rail, multi-phase synchronous buck digital PWM controllers | ||
26 | designed for non-isolated DC/DC power applications. The devices integrate | ||
27 | dedicated circuitry for DC/DC loop management with flash memory and a serial | ||
28 | interface to support configuration, monitoring and management. | ||
29 | |||
30 | This driver is a client driver to the core PMBus driver. Please see | ||
31 | Documentation/hwmon/pmbus for details on PMBus client drivers. | ||
32 | |||
33 | |||
34 | Usage Notes | ||
35 | ----------- | ||
36 | |||
37 | This driver does not auto-detect devices. You will have to instantiate the | ||
38 | devices explicitly. Please see Documentation/i2c/instantiating-devices for | ||
39 | details. | ||
40 | |||
41 | |||
42 | Platform data support | ||
43 | --------------------- | ||
44 | |||
45 | The driver supports standard PMBus driver platform data. Please see | ||
46 | Documentation/hwmon/pmbus for details. | ||
47 | |||
48 | |||
49 | Sysfs entries | ||
50 | ------------- | ||
51 | |||
52 | The following attributes are supported. Limits are read-write; all other | ||
53 | attributes are read-only. | ||
54 | |||
55 | in1_label "vin". | ||
56 | in1_input Measured voltage. From READ_VIN register. | ||
57 | in1_min Minumum Voltage. From VIN_UV_WARN_LIMIT register. | ||
58 | in1_max Maximum voltage. From VIN_OV_WARN_LIMIT register. | ||
59 | in1_lcrit Critical minumum Voltage. VIN_UV_FAULT_LIMIT register. | ||
60 | in1_crit Critical maximum voltage. From VIN_OV_FAULT_LIMIT register. | ||
61 | in1_min_alarm Voltage low alarm. From VIN_UV_WARNING status. | ||
62 | in1_max_alarm Voltage high alarm. From VIN_OV_WARNING status. | ||
63 | in1_lcrit_alarm Voltage critical low alarm. From VIN_UV_FAULT status. | ||
64 | in1_crit_alarm Voltage critical high alarm. From VIN_OV_FAULT status. | ||
65 | |||
66 | in[2-5]_label "vout[1-4]". | ||
67 | in[2-5]_input Measured voltage. From READ_VOUT register. | ||
68 | in[2-5]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register. | ||
69 | in[2-5]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register. | ||
70 | in[2-5]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register. | ||
71 | in[2-5]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register. | ||
72 | in[2-5]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. | ||
73 | in[2-5]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. | ||
74 | in[2-5]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status. | ||
75 | in[2-5]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status. | ||
76 | |||
77 | curr1_label "iin". | ||
78 | curr1_input Measured current. From READ_IIN register. | ||
79 | |||
80 | curr[2-5]_label "iout[1-4]". | ||
81 | curr[2-5]_input Measured current. From READ_IOUT register. | ||
82 | curr[2-5]_max Maximum current. From IOUT_OC_WARN_LIMIT register. | ||
83 | curr[2-5]_lcrit Critical minumum output current. From IOUT_UC_FAULT_LIMIT | ||
84 | register. | ||
85 | curr[2-5]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register. | ||
86 | curr[2-5]_max_alarm Current high alarm. From IOUT_OC_WARNING status. | ||
87 | curr[2-5]_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status. | ||
88 | |||
89 | power1_input Measured input power. From READ_PIN register. | ||
90 | power1_label "pin" | ||
91 | |||
92 | power[2-5]_input Measured output power. From READ_POUT register. | ||
93 | power[2-5]_label "pout[1-4]" | ||
94 | |||
95 | The number of output voltage, current, and power | ||
96 | attribute sets is determined by the number of enabled | ||
97 | rails. See chip datasheets for details. | ||
98 | |||
99 | temp[1-5]_input Measured temperatures. From READ_TEMPERATURE_1 and | ||
100 | READ_TEMPERATURE_2 registers. | ||
101 | temp1 is the chip internal temperature. temp[2-5] are | ||
102 | rail temperatures. temp[2-5] attributes are only | ||
103 | created for enabled rails. See chip datasheets for | ||
104 | details. | ||
105 | temp[1-5]_max Maximum temperature. From OT_WARN_LIMIT register. | ||
106 | temp[1-5]_crit Critical high temperature. From OT_FAULT_LIMIT register. | ||
107 | temp[1-5]_max_alarm Temperature high alarm. | ||
108 | temp[1-5]_crit_alarm Temperature critical high alarm. | ||
109 | |||
110 | fan1_input Fan RPM. ucd9240 only. | ||
111 | fan1_alarm Fan alarm. ucd9240 only. | ||
112 | fan1_fault Fan fault. ucd9240 only. | ||
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 6df69765ccb7..2871fd500349 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 | |||
@@ -19,6 +19,7 @@ Supported adapters: | |||
19 | * Intel 6 Series (PCH) | 19 | * Intel 6 Series (PCH) |
20 | * Intel Patsburg (PCH) | 20 | * Intel Patsburg (PCH) |
21 | * Intel DH89xxCC (PCH) | 21 | * Intel DH89xxCC (PCH) |
22 | * Intel Panther Point (PCH) | ||
22 | Datasheets: Publicly available at the Intel website | 23 | Datasheets: Publicly available at the Intel website |
23 | 24 | ||
24 | On Intel Patsburg and later chipsets, both the normal host SMBus controller | 25 | On Intel Patsburg and later chipsets, both the normal host SMBus controller |
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 5ebf5af1d716..5aa53374ea2a 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients | |||
@@ -38,7 +38,7 @@ static struct i2c_driver foo_driver = { | |||
38 | .name = "foo", | 38 | .name = "foo", |
39 | }, | 39 | }, |
40 | 40 | ||
41 | .id_table = foo_ids, | 41 | .id_table = foo_idtable, |
42 | .probe = foo_probe, | 42 | .probe = foo_probe, |
43 | .remove = foo_remove, | 43 | .remove = foo_remove, |
44 | /* if device autodetection is needed: */ | 44 | /* if device autodetection is needed: */ |
diff --git a/Documentation/input/elantech.txt b/Documentation/input/elantech.txt index 56941ae1f5db..db798af5ef98 100644 --- a/Documentation/input/elantech.txt +++ b/Documentation/input/elantech.txt | |||
@@ -34,7 +34,8 @@ Contents | |||
34 | Currently the Linux Elantech touchpad driver is aware of two different | 34 | Currently the Linux Elantech touchpad driver is aware of two different |
35 | hardware versions unimaginatively called version 1 and version 2. Version 1 | 35 | hardware versions unimaginatively called version 1 and version 2. Version 1 |
36 | is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to | 36 | is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to |
37 | be introduced with the EeePC and uses 6 bytes per packet. | 37 | be introduced with the EeePC and uses 6 bytes per packet, and provides |
38 | additional features such as position of two fingers, and width of the touch. | ||
38 | 39 | ||
39 | The driver tries to support both hardware versions and should be compatible | 40 | The driver tries to support both hardware versions and should be compatible |
40 | with the Xorg Synaptics touchpad driver and its graphical configuration | 41 | with the Xorg Synaptics touchpad driver and its graphical configuration |
@@ -94,18 +95,44 @@ Currently the Linux Elantech touchpad driver provides two extra knobs under | |||
94 | can check these bits and reject any packet that appears corrupted. Using | 95 | can check these bits and reject any packet that appears corrupted. Using |
95 | this knob you can bypass that check. | 96 | this knob you can bypass that check. |
96 | 97 | ||
97 | It is not known yet whether hardware version 2 provides the same parity | 98 | Hardware version 2 does not provide the same parity bits. Only some basic |
98 | bits. Hence checking is disabled by default. Currently even turning it on | 99 | data consistency checking can be done. For now checking is disabled by |
99 | will do nothing. | 100 | default. Currently even turning it on will do nothing. |
100 | |||
101 | 101 | ||
102 | ///////////////////////////////////////////////////////////////////////////// | 102 | ///////////////////////////////////////////////////////////////////////////// |
103 | 103 | ||
104 | 3. Differentiating hardware versions | ||
105 | ================================= | ||
106 | |||
107 | To detect the hardware version, read the version number as param[0].param[1].param[2] | ||
108 | |||
109 | 4 bytes version: (after the arrow is the name given in the Dell-provided driver) | ||
110 | 02.00.22 => EF013 | ||
111 | 02.06.00 => EF019 | ||
112 | In the wild, there appear to be more versions, such as 00.01.64, 01.00.21, | ||
113 | 02.00.00, 02.00.04, 02.00.06. | ||
114 | |||
115 | 6 bytes: | ||
116 | 02.00.30 => EF113 | ||
117 | 02.08.00 => EF023 | ||
118 | 02.08.XX => EF123 | ||
119 | 02.0B.00 => EF215 | ||
120 | 04.01.XX => Scroll_EF051 | ||
121 | 04.02.XX => EF051 | ||
122 | In the wild, there appear to be more versions, such as 04.03.01, 04.04.11. There | ||
123 | appears to be almost no difference, except for EF113, which does not report | ||
124 | pressure/width and has different data consistency checks. | ||
125 | |||
126 | Probably all the versions with param[0] <= 01 can be considered as | ||
127 | 4 bytes/firmware 1. The versions < 02.08.00, with the exception of 02.00.30, as | ||
128 | 4 bytes/firmware 2. Everything >= 02.08.00 can be considered as 6 bytes. | ||
129 | |||
130 | ///////////////////////////////////////////////////////////////////////////// | ||
104 | 131 | ||
105 | 3. Hardware version 1 | 132 | 4. Hardware version 1 |
106 | ================== | 133 | ================== |
107 | 134 | ||
108 | 3.1 Registers | 135 | 4.1 Registers |
109 | ~~~~~~~~~ | 136 | ~~~~~~~~~ |
110 | 137 | ||
111 | By echoing a hexadecimal value to a register it contents can be altered. | 138 | By echoing a hexadecimal value to a register it contents can be altered. |
@@ -168,7 +195,7 @@ For example: | |||
168 | smart edge activation area width? | 195 | smart edge activation area width? |
169 | 196 | ||
170 | 197 | ||
171 | 3.2 Native relative mode 4 byte packet format | 198 | 4.2 Native relative mode 4 byte packet format |
172 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 199 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
173 | 200 | ||
174 | byte 0: | 201 | byte 0: |
@@ -226,9 +253,13 @@ byte 3: | |||
226 | positive = down | 253 | positive = down |
227 | 254 | ||
228 | 255 | ||
229 | 3.3 Native absolute mode 4 byte packet format | 256 | 4.3 Native absolute mode 4 byte packet format |
230 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 257 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
231 | 258 | ||
259 | EF013 and EF019 have a special behaviour (due to a bug in the firmware?), and | ||
260 | when 1 finger is touching, the first 2 position reports must be discarded. | ||
261 | This counting is reset whenever a different number of fingers is reported. | ||
262 | |||
232 | byte 0: | 263 | byte 0: |
233 | firmware version 1.x: | 264 | firmware version 1.x: |
234 | 265 | ||
@@ -279,11 +310,11 @@ byte 3: | |||
279 | ///////////////////////////////////////////////////////////////////////////// | 310 | ///////////////////////////////////////////////////////////////////////////// |
280 | 311 | ||
281 | 312 | ||
282 | 4. Hardware version 2 | 313 | 5. Hardware version 2 |
283 | ================== | 314 | ================== |
284 | 315 | ||
285 | 316 | ||
286 | 4.1 Registers | 317 | 5.1 Registers |
287 | ~~~~~~~~~ | 318 | ~~~~~~~~~ |
288 | 319 | ||
289 | By echoing a hexadecimal value to a register it contents can be altered. | 320 | By echoing a hexadecimal value to a register it contents can be altered. |
@@ -316,16 +347,41 @@ For example: | |||
316 | 0x7f = never i.e. tap again to release) | 347 | 0x7f = never i.e. tap again to release) |
317 | 348 | ||
318 | 349 | ||
319 | 4.2 Native absolute mode 6 byte packet format | 350 | 5.2 Native absolute mode 6 byte packet format |
320 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 351 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
321 | 352 | 5.2.1 Parity checking and packet re-synchronization | |
322 | 4.2.1 One finger touch | 353 | There is no parity checking, however some consistency checks can be performed. |
354 | |||
355 | For instance for EF113: | ||
356 | SA1= packet[0]; | ||
357 | A1 = packet[1]; | ||
358 | B1 = packet[2]; | ||
359 | SB1= packet[3]; | ||
360 | C1 = packet[4]; | ||
361 | D1 = packet[5]; | ||
362 | if( (((SA1 & 0x3C) != 0x3C) && ((SA1 & 0xC0) != 0x80)) || // check Byte 1 | ||
363 | (((SA1 & 0x0C) != 0x0C) && ((SA1 & 0xC0) == 0x80)) || // check Byte 1 (one finger pressed) | ||
364 | (((SA1 & 0xC0) != 0x80) && (( A1 & 0xF0) != 0x00)) || // check Byte 2 | ||
365 | (((SB1 & 0x3E) != 0x38) && ((SA1 & 0xC0) != 0x80)) || // check Byte 4 | ||
366 | (((SB1 & 0x0E) != 0x08) && ((SA1 & 0xC0) == 0x80)) || // check Byte 4 (one finger pressed) | ||
367 | (((SA1 & 0xC0) != 0x80) && (( C1 & 0xF0) != 0x00)) ) // check Byte 5 | ||
368 | // error detected | ||
369 | |||
370 | For all the other ones, there are just a few constant bits: | ||
371 | if( ((packet[0] & 0x0C) != 0x04) || | ||
372 | ((packet[3] & 0x0f) != 0x02) ) | ||
373 | // error detected | ||
374 | |||
375 | |||
376 | In case an error is detected, all the packets are shifted by one (and packet[0] is discarded). | ||
377 | |||
378 | 5.2.1 One/Three finger touch | ||
323 | ~~~~~~~~~~~~~~~~ | 379 | ~~~~~~~~~~~~~~~~ |
324 | 380 | ||
325 | byte 0: | 381 | byte 0: |
326 | 382 | ||
327 | bit 7 6 5 4 3 2 1 0 | 383 | bit 7 6 5 4 3 2 1 0 |
328 | n1 n0 . . . . R L | 384 | n1 n0 w3 w2 . . R L |
329 | 385 | ||
330 | L, R = 1 when Left, Right mouse button pressed | 386 | L, R = 1 when Left, Right mouse button pressed |
331 | n1..n0 = numbers of fingers on touchpad | 387 | n1..n0 = numbers of fingers on touchpad |
@@ -333,24 +389,40 @@ byte 0: | |||
333 | byte 1: | 389 | byte 1: |
334 | 390 | ||
335 | bit 7 6 5 4 3 2 1 0 | 391 | bit 7 6 5 4 3 2 1 0 |
336 | . . . . . x10 x9 x8 | 392 | p7 p6 p5 p4 . x10 x9 x8 |
337 | 393 | ||
338 | byte 2: | 394 | byte 2: |
339 | 395 | ||
340 | bit 7 6 5 4 3 2 1 0 | 396 | bit 7 6 5 4 3 2 1 0 |
341 | x7 x6 x5 x4 x4 x2 x1 x0 | 397 | x7 x6 x5 x4 x3 x2 x1 x0 |
342 | 398 | ||
343 | x10..x0 = absolute x value (horizontal) | 399 | x10..x0 = absolute x value (horizontal) |
344 | 400 | ||
345 | byte 3: | 401 | byte 3: |
346 | 402 | ||
347 | bit 7 6 5 4 3 2 1 0 | 403 | bit 7 6 5 4 3 2 1 0 |
348 | . . . . . . . . | 404 | n4 vf w1 w0 . . . b2 |
405 | |||
406 | n4 = set if more than 3 fingers (only in 3 fingers mode) | ||
407 | vf = a kind of flag ? (only on EF123, 0 when finger is over one | ||
408 | of the buttons, 1 otherwise) | ||
409 | w3..w0 = width of the finger touch (not EF113) | ||
410 | b2 (on EF113 only, 0 otherwise), b2.R.L indicates one button pressed: | ||
411 | 0 = none | ||
412 | 1 = Left | ||
413 | 2 = Right | ||
414 | 3 = Middle (Left and Right) | ||
415 | 4 = Forward | ||
416 | 5 = Back | ||
417 | 6 = Another one | ||
418 | 7 = Another one | ||
349 | 419 | ||
350 | byte 4: | 420 | byte 4: |
351 | 421 | ||
352 | bit 7 6 5 4 3 2 1 0 | 422 | bit 7 6 5 4 3 2 1 0 |
353 | . . . . . . y9 y8 | 423 | p3 p1 p2 p0 . . y9 y8 |
424 | |||
425 | p7..p0 = pressure (not EF113) | ||
354 | 426 | ||
355 | byte 5: | 427 | byte 5: |
356 | 428 | ||
@@ -363,6 +435,11 @@ byte 5: | |||
363 | 4.2.2 Two finger touch | 435 | 4.2.2 Two finger touch |
364 | ~~~~~~~~~~~~~~~~ | 436 | ~~~~~~~~~~~~~~~~ |
365 | 437 | ||
438 | Note that the two pairs of coordinates are not exactly the coordinates of the | ||
439 | two fingers, but only the pair of the lower-left and upper-right coordinates. | ||
440 | So the actual fingers might be situated on the other diagonal of the square | ||
441 | defined by these two points. | ||
442 | |||
366 | byte 0: | 443 | byte 0: |
367 | 444 | ||
368 | bit 7 6 5 4 3 2 1 0 | 445 | bit 7 6 5 4 3 2 1 0 |
@@ -376,14 +453,14 @@ byte 1: | |||
376 | bit 7 6 5 4 3 2 1 0 | 453 | bit 7 6 5 4 3 2 1 0 |
377 | ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0 | 454 | ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0 |
378 | 455 | ||
379 | ax8..ax0 = first finger absolute x value | 456 | ax8..ax0 = lower-left finger absolute x value |
380 | 457 | ||
381 | byte 2: | 458 | byte 2: |
382 | 459 | ||
383 | bit 7 6 5 4 3 2 1 0 | 460 | bit 7 6 5 4 3 2 1 0 |
384 | ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0 | 461 | ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0 |
385 | 462 | ||
386 | ay8..ay0 = first finger absolute y value | 463 | ay8..ay0 = lower-left finger absolute y value |
387 | 464 | ||
388 | byte 3: | 465 | byte 3: |
389 | 466 | ||
@@ -395,11 +472,11 @@ byte 4: | |||
395 | bit 7 6 5 4 3 2 1 0 | 472 | bit 7 6 5 4 3 2 1 0 |
396 | bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0 | 473 | bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0 |
397 | 474 | ||
398 | bx8..bx0 = second finger absolute x value | 475 | bx8..bx0 = upper-right finger absolute x value |
399 | 476 | ||
400 | byte 5: | 477 | byte 5: |
401 | 478 | ||
402 | bit 7 6 5 4 3 2 1 0 | 479 | bit 7 6 5 4 3 2 1 0 |
403 | by7 by8 by5 by4 by3 by2 by1 by0 | 480 | by7 by8 by5 by4 by3 by2 by1 by0 |
404 | 481 | ||
405 | by8..by0 = second finger absolute y value | 482 | by8..by0 = upper-right finger absolute y value |
diff --git a/Documentation/input/rotary-encoder.txt b/Documentation/input/rotary-encoder.txt index 943e8f6f2b15..92e68bce13a4 100644 --- a/Documentation/input/rotary-encoder.txt +++ b/Documentation/input/rotary-encoder.txt | |||
@@ -9,6 +9,9 @@ peripherals with two wires. The outputs are phase-shifted by 90 degrees | |||
9 | and by triggering on falling and rising edges, the turn direction can | 9 | and by triggering on falling and rising edges, the turn direction can |
10 | be determined. | 10 | be determined. |
11 | 11 | ||
12 | Some encoders have both outputs low in stable states, whereas others also have | ||
13 | a stable state with both outputs high (half-period mode). | ||
14 | |||
12 | The phase diagram of these two outputs look like this: | 15 | The phase diagram of these two outputs look like this: |
13 | 16 | ||
14 | _____ _____ _____ | 17 | _____ _____ _____ |
@@ -26,6 +29,8 @@ The phase diagram of these two outputs look like this: | |||
26 | |<-------->| | 29 | |<-------->| |
27 | one step | 30 | one step |
28 | 31 | ||
32 | |<-->| | ||
33 | one step (half-period mode) | ||
29 | 34 | ||
30 | For more information, please see | 35 | For more information, please see |
31 | http://en.wikipedia.org/wiki/Rotary_encoder | 36 | http://en.wikipedia.org/wiki/Rotary_encoder |
@@ -34,6 +39,13 @@ For more information, please see | |||
34 | 1. Events / state machine | 39 | 1. Events / state machine |
35 | ------------------------- | 40 | ------------------------- |
36 | 41 | ||
42 | In half-period mode, state a) and c) above are used to determine the | ||
43 | rotational direction based on the last stable state. Events are reported in | ||
44 | states b) and d) given that the new stable state is different from the last | ||
45 | (i.e. the rotation was not reversed half-way). | ||
46 | |||
47 | Otherwise, the following apply: | ||
48 | |||
37 | a) Rising edge on channel A, channel B in low state | 49 | a) Rising edge on channel A, channel B in low state |
38 | This state is used to recognize a clockwise turn | 50 | This state is used to recognize a clockwise turn |
39 | 51 | ||
@@ -96,6 +108,7 @@ static struct rotary_encoder_platform_data my_rotary_encoder_info = { | |||
96 | .gpio_b = GPIO_ROTARY_B, | 108 | .gpio_b = GPIO_ROTARY_B, |
97 | .inverted_a = 0, | 109 | .inverted_a = 0, |
98 | .inverted_b = 0, | 110 | .inverted_b = 0, |
111 | .half_period = false, | ||
99 | }; | 112 | }; |
100 | 113 | ||
101 | static struct platform_device rotary_encoder_device = { | 114 | static struct platform_device rotary_encoder_device = { |
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index a0a5d82b6b0b..3a46e360496d 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt | |||
@@ -166,7 +166,6 @@ Code Seq#(hex) Include File Comments | |||
166 | 'T' all arch/x86/include/asm/ioctls.h conflict! | 166 | 'T' all arch/x86/include/asm/ioctls.h conflict! |
167 | 'T' C0-DF linux/if_tun.h conflict! | 167 | 'T' C0-DF linux/if_tun.h conflict! |
168 | 'U' all sound/asound.h conflict! | 168 | 'U' all sound/asound.h conflict! |
169 | 'U' 00-0F drivers/media/video/uvc/uvcvideo.h conflict! | ||
170 | 'U' 00-CF linux/uinput.h conflict! | 169 | 'U' 00-CF linux/uinput.h conflict! |
171 | 'U' 00-EF linux/usbdevice_fs.h | 170 | 'U' 00-EF linux/usbdevice_fs.h |
172 | 'U' C0-CF drivers/bluetooth/hci_uart.h | 171 | 'U' C0-CF drivers/bluetooth/hci_uart.h |
@@ -259,6 +258,7 @@ Code Seq#(hex) Include File Comments | |||
259 | 't' 80-8F linux/isdn_ppp.h | 258 | 't' 80-8F linux/isdn_ppp.h |
260 | 't' 90 linux/toshiba.h | 259 | 't' 90 linux/toshiba.h |
261 | 'u' 00-1F linux/smb_fs.h gone | 260 | 'u' 00-1F linux/smb_fs.h gone |
261 | 'u' 20-3F linux/uvcvideo.h USB video class host driver | ||
262 | 'v' 00-1F linux/ext2_fs.h conflict! | 262 | 'v' 00-1F linux/ext2_fs.h conflict! |
263 | 'v' 00-1F linux/fs.h conflict! | 263 | 'v' 00-1F linux/fs.h conflict! |
264 | 'v' 00-0F linux/sonypi.h conflict! | 264 | 'v' 00-0F linux/sonypi.h conflict! |
@@ -304,6 +304,7 @@ Code Seq#(hex) Include File Comments | |||
304 | 0xB0 all RATIO devices in development: | 304 | 0xB0 all RATIO devices in development: |
305 | <mailto:vgo@ratio.de> | 305 | <mailto:vgo@ratio.de> |
306 | 0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca> | 306 | 0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca> |
307 | 0xB3 00 linux/mmc/ioctl.h | ||
307 | 0xC0 00-0F linux/usb/iowarrior.h | 308 | 0xC0 00-0F linux/usb/iowarrior.h |
308 | 0xCB 00-1F CBM serial IEC bus in development: | 309 | 0xCB 00-1F CBM serial IEC bus in development: |
309 | <mailto:michael.klein@puffin.lb.shuttle.de> | 310 | <mailto:michael.klein@puffin.lb.shuttle.de> |
diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO index b63301a03811..050d37fe6d40 100644 --- a/Documentation/ja_JP/HOWTO +++ b/Documentation/ja_JP/HOWTO | |||
@@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a | |||
11 | fork. So if you have any comments or updates for this file, please try | 11 | fork. So if you have any comments or updates for this file, please try |
12 | to update the original English file first. | 12 | to update the original English file first. |
13 | 13 | ||
14 | Last Updated: 2008/10/24 | 14 | Last Updated: 2011/03/31 |
15 | ================================== | 15 | ================================== |
16 | これは、 | 16 | これは、 |
17 | linux-2.6.28/Documentation/HOWTO | 17 | linux-2.6.38/Documentation/HOWTO |
18 | の和訳です。 | 18 | の和訳です。 |
19 | 19 | ||
20 | 翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ > | 20 | 翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ > |
21 | 翻訳日: 2008/10/24 | 21 | 翻訳日: 2011/3/28 |
22 | 翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> | 22 | 翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> |
23 | 校正者: 松倉さん <nbh--mats at nifty dot com> | 23 | 校正者: 松倉さん <nbh--mats at nifty dot com> |
24 | 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp> | 24 | 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp> |
@@ -256,8 +256,8 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン | |||
256 | - メインの 2.6.x カーネルツリー | 256 | - メインの 2.6.x カーネルツリー |
257 | - 2.6.x.y -stable カーネルツリー | 257 | - 2.6.x.y -stable カーネルツリー |
258 | - 2.6.x -git カーネルパッチ | 258 | - 2.6.x -git カーネルパッチ |
259 | - 2.6.x -mm カーネルパッチ | ||
260 | - サブシステム毎のカーネルツリーとパッチ | 259 | - サブシステム毎のカーネルツリーとパッチ |
260 | - 統合テストのための 2.6.x -next カーネルツリー | ||
261 | 261 | ||
262 | 2.6.x カーネルツリー | 262 | 2.6.x カーネルツリー |
263 | ----------------- | 263 | ----------------- |
@@ -268,9 +268,9 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン | |||
268 | 268 | ||
269 | - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、 | 269 | - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、 |
270 | この期間中に、メンテナ達は Linus に大きな差分を送ることができます。 | 270 | この期間中に、メンテナ達は Linus に大きな差分を送ることができます。 |
271 | このような差分は通常 -mm カーネルに数週間含まれてきたパッチです。 | 271 | このような差分は通常 -next カーネルに数週間含まれてきたパッチです。 |
272 | 大きな変更は git(カーネルのソース管理ツール、詳細は | 272 | 大きな変更は git(カーネルのソース管理ツール、詳細は |
273 | http://git.or.cz/ 参照) を使って送るのが好ましいやり方ですが、パッ | 273 | http://git-scm.com/ 参照) を使って送るのが好ましいやり方ですが、パッ |
274 | チファイルの形式のまま送るのでも十分です。 | 274 | チファイルの形式のまま送るのでも十分です。 |
275 | 275 | ||
276 | - 2週間後、-rc1 カーネルがリリースされ、この後にはカーネル全体の安定 | 276 | - 2週間後、-rc1 カーネルがリリースされ、この後にはカーネル全体の安定 |
@@ -333,86 +333,44 @@ git リポジトリで管理されているLinus のカーネルツリーの毎 | |||
333 | れは -rc カーネルと比べて、パッチが大丈夫かどうかも確認しないで自動的 | 333 | れは -rc カーネルと比べて、パッチが大丈夫かどうかも確認しないで自動的 |
334 | に生成されるので、より実験的です。 | 334 | に生成されるので、より実験的です。 |
335 | 335 | ||
336 | 2.6.x -mm カーネルパッチ | ||
337 | ------------------------ | ||
338 | |||
339 | Andrew Morton によってリリースされる実験的なカーネルパッチ群です。 | ||
340 | Andrew は個別のサブシステムカーネルツリーとパッチを全て集めてきて | ||
341 | linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま | ||
342 | とめます。 | ||
343 | このツリーは新機能とパッチが検証される場となります。ある期間の間パッチ | ||
344 | が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、 | ||
345 | メインラインへ入れるように Linus にプッシュします。 | ||
346 | |||
347 | メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ | ||
348 | チが -mm ツリーでテストされることが強く推奨されています。マージウィン | ||
349 | ドウが開く前に -mm ツリーに現れなかったパッチはメインラインにマージさ | ||
350 | れることは困難になります。 | ||
351 | |||
352 | これらのカーネルは安定して動作すべきシステムとして使うのには適切ではあ | ||
353 | りませんし、カーネルブランチの中でももっとも動作にリスクが高いものです。 | ||
354 | |||
355 | もしあなたが、カーネル開発プロセスの支援をしたいと思っているのであれば、 | ||
356 | どうぞこれらのカーネルリリースをテストに使ってみて、そしてもし問題があ | ||
357 | れば、またもし全てが正しく動作したとしても、linux-kernel メーリングリ | ||
358 | ストにフィードバックを提供してください。 | ||
359 | |||
360 | すべての他の実験的パッチに加えて、これらのカーネルは通常リリース時点で | ||
361 | メインラインの -git カーネルに含まれる全ての変更も含んでいます。 | ||
362 | |||
363 | -mm カーネルは決まったスケジュールではリリースされません、しかし通常幾 | ||
364 | つかの -mm カーネル (1 から 3 が普通)が各-rc カーネルの間にリリースさ | ||
365 | れます。 | ||
366 | |||
367 | サブシステム毎のカーネルツリーとパッチ | 336 | サブシステム毎のカーネルツリーとパッチ |
368 | ------------------------------------------- | 337 | ------------------------------------------- |
369 | 338 | ||
370 | カーネルの様々な領域で何が起きているかを見られるようにするため、多くの | 339 | それぞれのカーネルサブシステムのメンテナ達は --- そして多くのカーネル |
371 | カーネルサブシステム開発者は彼らの開発ツリーを公開しています。これらの | 340 | サブシステムの開発者達も --- 各自の最新の開発状況をソースリポジトリに |
372 | ツリーは説明したように -mm カーネルリリースに入れ込まれます。 | 341 | 公開しています。そのため、自分とは異なる領域のカーネルで何が起きている |
373 | 342 | かを他の人が見られるようになっています。開発が早く進んでいる領域では、 | |
374 | 以下はさまざまなカーネルツリーの中のいくつかのリスト- | 343 | 開発者は自身の投稿がどのサブシステムカーネルツリーを元にしているか質問 |
375 | 344 | されるので、その投稿とすでに進行中の他の作業との衝突が避けられます。 | |
376 | git ツリー- | 345 | |
377 | - Kbuild の開発ツリー、Sam Ravnborg <sam@ravnborg.org> | 346 | 大部分のこれらのリポジトリは git ツリーです。しかしその他の SCM や |
378 | git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git | 347 | quilt シリーズとして公開されているパッチキューも使われています。これら |
379 | 348 | のサブシステムリポジトリのアドレスは MAINTAINERS ファイルにリストされ | |
380 | - ACPI の開発ツリー、 Len Brown <len.brown@intel.com> | 349 | ています。これらの多くは http://git.kernel.org/ で参照することができま |
381 | git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git | 350 | す。 |
382 | |||
383 | - Block の開発ツリー、Jens Axboe <axboe@suse.de> | ||
384 | git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git | ||
385 | |||
386 | - DRM の開発ツリー、Dave Airlie <airlied@linux.ie> | ||
387 | git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git | ||
388 | |||
389 | - ia64 の開発ツリー、Tony Luck <tony.luck@intel.com> | ||
390 | git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git | ||
391 | |||
392 | - infiniband, Roland Dreier <rolandd@cisco.com> | ||
393 | git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git | ||
394 | |||
395 | - libata, Jeff Garzik <jgarzik@pobox.com> | ||
396 | git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git | ||
397 | |||
398 | - ネットワークドライバ, Jeff Garzik <jgarzik@pobox.com> | ||
399 | git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git | ||
400 | |||
401 | - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net> | ||
402 | git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git | ||
403 | |||
404 | - SCSI, James Bottomley <James.Bottomley@hansenpartnership.com> | ||
405 | git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git | ||
406 | |||
407 | - x86, Ingo Molnar <mingo@elte.hu> | ||
408 | git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git | ||
409 | |||
410 | quilt ツリー- | ||
411 | - USB, ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de> | ||
412 | kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ | ||
413 | 351 | ||
414 | その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ | 352 | 提案されたパッチがこのようなサブシステムツリーにコミットされる前に、メー |
415 | イルに一覧表があります。 | 353 | リングリストで事前にレビューにかけられます(以下の対応するセクションを |
354 | 参照)。いくつかのカーネルサブシステムでは、このレビューは patchwork | ||
355 | というツールによって追跡されます。Patchwork は web インターフェイスに | ||
356 | よってパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そして | ||
357 | メンテナはパッチに対して、レビュー中、受付済み、拒否というようなマーク | ||
358 | をつけることができます。大部分のこれらの patchwork のサイトは | ||
359 | http://patchwork.kernel.org/ でリストされています。 | ||
360 | |||
361 | 統合テストのための 2.6.x -next カーネルツリー | ||
362 | --------------------------------------------- | ||
363 | |||
364 | サブシステムツリーの更新内容がメインラインの 2.6.x ツリーにマージされ | ||
365 | る前に、それらは統合テストされる必要があります。この目的のため、実質的 | ||
366 | に全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリ | ||
367 | ポジトリが存在します- | ||
368 | http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git | ||
369 | http://linux.f-seidel.de/linux-next/pmwiki/ | ||
370 | |||
371 | このやり方によって、-next カーネルは次のマージ機会でどんなものがメイン | ||
372 | ラインカーネルにマージされるか、おおまかなの展望を提供します。-next | ||
373 | カーネルの実行テストを行う冒険好きなテスターは大いに歓迎されます | ||
416 | 374 | ||
417 | バグレポート | 375 | バグレポート |
418 | ------------- | 376 | ------------- |
@@ -673,10 +631,9 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を | |||
673 | じところからスタートしたのですから。 | 631 | じところからスタートしたのですから。 |
674 | 632 | ||
675 | Paolo Ciarrocchi に感謝、彼は彼の書いた "Development Process" | 633 | Paolo Ciarrocchi に感謝、彼は彼の書いた "Development Process" |
676 | (http://linux.tar.bz/articles/2.6-development_process)セクショ | 634 | (http://lwn.net/Articles/94386/) セクションをこのテキストの原型にする |
677 | ンをこのテキストの原型にすることを許可してくれました。 | 635 | ことを許可してくれました。Rundy Dunlap と Gerrit Huizenga はメーリング |
678 | Rundy Dunlap と Gerrit Huizenga はメーリングリストでやるべきこととやっ | 636 | リストでやるべきこととやってはいけないことのリストを提供してくれました。 |
679 | てはいけないことのリストを提供してくれました。 | ||
680 | 以下の人々のレビュー、コメント、貢献に感謝。 | 637 | 以下の人々のレビュー、コメント、貢献に感謝。 |
681 | Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, | 638 | Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, |
682 | Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi | 639 | Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi |
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index 7c2a89ba674c..68e32bb6bd80 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt | |||
@@ -201,3 +201,16 @@ KBUILD_ENABLE_EXTRA_GCC_CHECKS | |||
201 | -------------------------------------------------- | 201 | -------------------------------------------------- |
202 | If enabled over the make command line with "W=1", it turns on additional | 202 | If enabled over the make command line with "W=1", it turns on additional |
203 | gcc -W... options for more extensive build-time checking. | 203 | gcc -W... options for more extensive build-time checking. |
204 | |||
205 | KBUILD_BUILD_TIMESTAMP | ||
206 | -------------------------------------------------- | ||
207 | Setting this to a date string overrides the timestamp used in the | ||
208 | UTS_VERSION definition (uname -v in the running kernel). The value has to | ||
209 | be a string that can be passed to date -d. The default value | ||
210 | is the output of the date command at one point during build. | ||
211 | |||
212 | KBUILD_BUILD_USER, KBUILD_BUILD_HOST | ||
213 | -------------------------------------------------- | ||
214 | These two variables allow to override the user@host string displayed during | ||
215 | boot and in /proc/version. The default value is the output of the commands | ||
216 | whoami and host, respectively. | ||
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index b507d61fd41c..44e2649fbb29 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt | |||
@@ -113,6 +113,13 @@ applicable everywhere (see syntax). | |||
113 | That will limit the usefulness but on the other hand avoid | 113 | That will limit the usefulness but on the other hand avoid |
114 | the illegal configurations all over. | 114 | the illegal configurations all over. |
115 | 115 | ||
116 | - limiting menu display: "visible if" <expr> | ||
117 | This attribute is only applicable to menu blocks, if the condition is | ||
118 | false, the menu block is not displayed to the user (the symbols | ||
119 | contained there can still be selected by other symbols, though). It is | ||
120 | similar to a conditional "prompt" attribude for individual menu | ||
121 | entries. Default value of "visible" is true. | ||
122 | |||
116 | - numerical ranges: "range" <symbol> <symbol> ["if" <expr>] | 123 | - numerical ranges: "range" <symbol> <symbol> ["if" <expr>] |
117 | This allows to limit the range of possible input values for int | 124 | This allows to limit the range of possible input values for int |
118 | and hex symbols. The user can only input a value which is larger than | 125 | and hex symbols. The user can only input a value which is larger than |
@@ -303,7 +310,8 @@ menu: | |||
303 | "endmenu" | 310 | "endmenu" |
304 | 311 | ||
305 | This defines a menu block, see "Menu structure" above for more | 312 | This defines a menu block, see "Menu structure" above for more |
306 | information. The only possible options are dependencies. | 313 | information. The only possible options are dependencies and "visible" |
314 | attributes. | ||
307 | 315 | ||
308 | if: | 316 | if: |
309 | 317 | ||
@@ -381,3 +389,25 @@ config FOO | |||
381 | 389 | ||
382 | limits FOO to module (=m) or disabled (=n). | 390 | limits FOO to module (=m) or disabled (=n). |
383 | 391 | ||
392 | Kconfig symbol existence | ||
393 | ~~~~~~~~~~~~~~~~~~~~~~~~ | ||
394 | The following two methods produce the same kconfig symbol dependencies | ||
395 | but differ greatly in kconfig symbol existence (production) in the | ||
396 | generated config file. | ||
397 | |||
398 | case 1: | ||
399 | |||
400 | config FOO | ||
401 | tristate "about foo" | ||
402 | depends on BAR | ||
403 | |||
404 | vs. case 2: | ||
405 | |||
406 | if BAR | ||
407 | config FOO | ||
408 | tristate "about foo" | ||
409 | endif | ||
410 | |||
411 | In case 1, the symbol FOO will always exist in the config file (given | ||
412 | no other dependencies). In case 2, the symbol FOO will only exist in | ||
413 | the config file if BAR is enabled. | ||
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index cca46b1a0f6c..c313d71324b4 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt | |||
@@ -48,11 +48,6 @@ KCONFIG_OVERWRITECONFIG | |||
48 | If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not | 48 | If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not |
49 | break symlinks when .config is a symlink to somewhere else. | 49 | break symlinks when .config is a symlink to somewhere else. |
50 | 50 | ||
51 | KCONFIG_NOTIMESTAMP | ||
52 | -------------------------------------------------- | ||
53 | If this environment variable exists and is non-null, the timestamp line | ||
54 | in generated .config files is omitted. | ||
55 | |||
56 | ______________________________________________________________________ | 51 | ______________________________________________________________________ |
57 | Environment variables for '{allyes/allmod/allno/rand}config' | 52 | Environment variables for '{allyes/allmod/allno/rand}config' |
58 | 53 | ||
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 5d145bb443c0..47435e56c5da 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt | |||
@@ -40,11 +40,13 @@ This document describes the Linux kernel Makefiles. | |||
40 | --- 6.6 Commands useful for building a boot image | 40 | --- 6.6 Commands useful for building a boot image |
41 | --- 6.7 Custom kbuild commands | 41 | --- 6.7 Custom kbuild commands |
42 | --- 6.8 Preprocessing linker scripts | 42 | --- 6.8 Preprocessing linker scripts |
43 | --- 6.9 Generic header files | ||
43 | 44 | ||
44 | === 7 Kbuild syntax for exported headers | 45 | === 7 Kbuild syntax for exported headers |
45 | --- 7.1 header-y | 46 | --- 7.1 header-y |
46 | --- 7.2 objhdr-y | 47 | --- 7.2 objhdr-y |
47 | --- 7.3 destination-y | 48 | --- 7.3 destination-y |
49 | --- 7.4 generic-y | ||
48 | 50 | ||
49 | === 8 Kbuild Variables | 51 | === 8 Kbuild Variables |
50 | === 9 Makefile language | 52 | === 9 Makefile language |
@@ -499,6 +501,18 @@ more details, with real examples. | |||
499 | gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used. | 501 | gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used. |
500 | Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options | 502 | Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options |
501 | 503 | ||
504 | cc-disable-warning | ||
505 | cc-disable-warning checks if gcc supports a given warning and returns | ||
506 | the commandline switch to disable it. This special function is needed, | ||
507 | because gcc 4.4 and later accept any unknown -Wno-* option and only | ||
508 | warn about it if there is another warning in the source file. | ||
509 | |||
510 | Example: | ||
511 | KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) | ||
512 | |||
513 | In the above example, -Wno-unused-but-set-variable will be added to | ||
514 | KBUILD_CFLAGS only if gcc really accepts it. | ||
515 | |||
502 | cc-version | 516 | cc-version |
503 | cc-version returns a numerical version of the $(CC) compiler version. | 517 | cc-version returns a numerical version of the $(CC) compiler version. |
504 | The format is <major><minor> where both are two digits. So for example | 518 | The format is <major><minor> where both are two digits. So for example |
@@ -955,6 +969,11 @@ When kbuild executes, the following steps are followed (roughly): | |||
955 | used when linking modules. This is often a linker script. | 969 | used when linking modules. This is often a linker script. |
956 | From commandline LDFLAGS_MODULE shall be used (see kbuild.txt). | 970 | From commandline LDFLAGS_MODULE shall be used (see kbuild.txt). |
957 | 971 | ||
972 | KBUILD_ARFLAGS Options for $(AR) when creating archives | ||
973 | |||
974 | $(KBUILD_ARFLAGS) set by the top level Makefile to "D" (deterministic | ||
975 | mode) if this option is supported by $(AR). | ||
976 | |||
958 | --- 6.2 Add prerequisites to archprepare: | 977 | --- 6.2 Add prerequisites to archprepare: |
959 | 978 | ||
960 | The archprepare: rule is used to list prerequisites that need to be | 979 | The archprepare: rule is used to list prerequisites that need to be |
@@ -1209,6 +1228,14 @@ When kbuild executes, the following steps are followed (roughly): | |||
1209 | The kbuild infrastructure for *lds file are used in several | 1228 | The kbuild infrastructure for *lds file are used in several |
1210 | architecture-specific files. | 1229 | architecture-specific files. |
1211 | 1230 | ||
1231 | --- 6.9 Generic header files | ||
1232 | |||
1233 | The directory include/asm-generic contains the header files | ||
1234 | that may be shared between individual architectures. | ||
1235 | The recommended approach how to use a generic header file is | ||
1236 | to list the file in the Kbuild file. | ||
1237 | See "7.4 generic-y" for further info on syntax etc. | ||
1238 | |||
1212 | === 7 Kbuild syntax for exported headers | 1239 | === 7 Kbuild syntax for exported headers |
1213 | 1240 | ||
1214 | The kernel include a set of headers that is exported to userspace. | 1241 | The kernel include a set of headers that is exported to userspace. |
@@ -1265,6 +1292,32 @@ See subsequent chapter for the syntax of the Kbuild file. | |||
1265 | In the example above all exported headers in the Kbuild file | 1292 | In the example above all exported headers in the Kbuild file |
1266 | will be located in the directory "include/linux" when exported. | 1293 | will be located in the directory "include/linux" when exported. |
1267 | 1294 | ||
1295 | --- 7.4 generic-y | ||
1296 | |||
1297 | If an architecture uses a verbatim copy of a header from | ||
1298 | include/asm-generic then this is listed in the file | ||
1299 | arch/$(ARCH)/include/asm/Kbuild like this: | ||
1300 | |||
1301 | Example: | ||
1302 | #arch/x86/include/asm/Kbuild | ||
1303 | generic-y += termios.h | ||
1304 | generic-y += rtc.h | ||
1305 | |||
1306 | During the prepare phase of the build a wrapper include | ||
1307 | file is generated in the directory: | ||
1308 | |||
1309 | arch/$(ARCH)/include/generated/asm | ||
1310 | |||
1311 | When a header is exported where the architecture uses | ||
1312 | the generic header a similar wrapper is generated as part | ||
1313 | of the set of exported headers in the directory: | ||
1314 | |||
1315 | usr/include/asm | ||
1316 | |||
1317 | The generated wrapper will in both cases look like the following: | ||
1318 | |||
1319 | Example: termios.h | ||
1320 | #include <asm-generic/termios.h> | ||
1268 | 1321 | ||
1269 | === 8 Kbuild Variables | 1322 | === 8 Kbuild Variables |
1270 | 1323 | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index cc85a9278190..aa47be71df4c 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -245,7 +245,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
245 | 245 | ||
246 | acpi_sleep= [HW,ACPI] Sleep options | 246 | acpi_sleep= [HW,ACPI] Sleep options |
247 | Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig, | 247 | Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig, |
248 | old_ordering, s4_nonvs, sci_force_enable } | 248 | old_ordering, nonvs, sci_force_enable } |
249 | See Documentation/power/video.txt for information on | 249 | See Documentation/power/video.txt for information on |
250 | s3_bios and s3_mode. | 250 | s3_bios and s3_mode. |
251 | s3_beep is for debugging; it makes the PC's speaker beep | 251 | s3_beep is for debugging; it makes the PC's speaker beep |
@@ -999,7 +999,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
999 | With this option on every unmap_single operation will | 999 | With this option on every unmap_single operation will |
1000 | result in a hardware IOTLB flush operation as opposed | 1000 | result in a hardware IOTLB flush operation as opposed |
1001 | to batching them for performance. | 1001 | to batching them for performance. |
1002 | 1002 | sp_off [Default Off] | |
1003 | By default, super page will be supported if Intel IOMMU | ||
1004 | has the capability. With this option, super page will | ||
1005 | not be supported. | ||
1003 | intremap= [X86-64, Intel-IOMMU] | 1006 | intremap= [X86-64, Intel-IOMMU] |
1004 | Format: { on (default) | off | nosid } | 1007 | Format: { on (default) | off | nosid } |
1005 | on enable Interrupt Remapping (default) | 1008 | on enable Interrupt Remapping (default) |
@@ -1664,6 +1667,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
1664 | noexec=on: enable non-executable mappings (default) | 1667 | noexec=on: enable non-executable mappings (default) |
1665 | noexec=off: disable non-executable mappings | 1668 | noexec=off: disable non-executable mappings |
1666 | 1669 | ||
1670 | nosmep [X86] | ||
1671 | Disable SMEP (Supervisor Mode Execution Protection) | ||
1672 | even if it is supported by processor. | ||
1673 | |||
1667 | noexec32 [X86-64] | 1674 | noexec32 [X86-64] |
1668 | This affects only 32-bit executables. | 1675 | This affects only 32-bit executables. |
1669 | noexec32=on: enable non-executable mappings (default) | 1676 | noexec32=on: enable non-executable mappings (default) |
@@ -1773,9 +1780,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
1773 | 1780 | ||
1774 | nosoftlockup [KNL] Disable the soft-lockup detector. | 1781 | nosoftlockup [KNL] Disable the soft-lockup detector. |
1775 | 1782 | ||
1776 | noswapaccount [KNL] Disable accounting of swap in memory resource | ||
1777 | controller. (See Documentation/cgroups/memory.txt) | ||
1778 | |||
1779 | nosync [HW,M68K] Disables sync negotiation for all devices. | 1783 | nosync [HW,M68K] Disables sync negotiation for all devices. |
1780 | 1784 | ||
1781 | notsc [BUGS=X86-32] Disable Time Stamp Counter | 1785 | notsc [BUGS=X86-32] Disable Time Stamp Counter |
@@ -2011,6 +2015,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
2011 | the default. | 2015 | the default. |
2012 | off: Turn ECRC off | 2016 | off: Turn ECRC off |
2013 | on: Turn ECRC on. | 2017 | on: Turn ECRC on. |
2018 | realloc reallocate PCI resources if allocations done by BIOS | ||
2019 | are erroneous. | ||
2014 | 2020 | ||
2015 | pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power | 2021 | pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power |
2016 | Management. | 2022 | Management. |
@@ -2581,6 +2587,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
2581 | bytes of sense data); | 2587 | bytes of sense data); |
2582 | c = FIX_CAPACITY (decrease the reported | 2588 | c = FIX_CAPACITY (decrease the reported |
2583 | device capacity by one sector); | 2589 | device capacity by one sector); |
2590 | d = NO_READ_DISC_INFO (don't use | ||
2591 | READ_DISC_INFO command); | ||
2592 | e = NO_READ_CAPACITY_16 (don't use | ||
2593 | READ_CAPACITY_16 command); | ||
2584 | h = CAPACITY_HEURISTICS (decrease the | 2594 | h = CAPACITY_HEURISTICS (decrease the |
2585 | reported device capacity by one | 2595 | reported device capacity by one |
2586 | sector if the number is odd); | 2596 | sector if the number is odd); |
@@ -2590,6 +2600,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
2590 | unlock ejectable media); | 2600 | unlock ejectable media); |
2591 | m = MAX_SECTORS_64 (don't transfer more | 2601 | m = MAX_SECTORS_64 (don't transfer more |
2592 | than 64 sectors = 32 KB at a time); | 2602 | than 64 sectors = 32 KB at a time); |
2603 | n = INITIAL_READ10 (force a retry of the | ||
2604 | initial READ(10) command); | ||
2593 | o = CAPACITY_OK (accept the capacity | 2605 | o = CAPACITY_OK (accept the capacity |
2594 | reported by the device); | 2606 | reported by the device); |
2595 | r = IGNORE_RESIDUE (the device reports | 2607 | r = IGNORE_RESIDUE (the device reports |
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index 090e6ee04536..51063e681ca4 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt | |||
@@ -11,7 +11,9 @@ with the difference that the orphan objects are not freed but only | |||
11 | reported via /sys/kernel/debug/kmemleak. A similar method is used by the | 11 | reported via /sys/kernel/debug/kmemleak. A similar method is used by the |
12 | Valgrind tool (memcheck --leak-check) to detect the memory leaks in | 12 | Valgrind tool (memcheck --leak-check) to detect the memory leaks in |
13 | user-space applications. | 13 | user-space applications. |
14 | Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. | 14 | |
15 | Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported | ||
16 | architectures. | ||
15 | 17 | ||
16 | Usage | 18 | Usage |
17 | ----- | 19 | ----- |
diff --git a/Documentation/laptops/acer-wmi.txt b/Documentation/laptops/acer-wmi.txt deleted file mode 100644 index 4beafa663dd6..000000000000 --- a/Documentation/laptops/acer-wmi.txt +++ /dev/null | |||
@@ -1,184 +0,0 @@ | |||
1 | Acer Laptop WMI Extras Driver | ||
2 | http://code.google.com/p/aceracpi | ||
3 | Version 0.3 | ||
4 | 4th April 2009 | ||
5 | |||
6 | Copyright 2007-2009 Carlos Corbacho <carlos@strangeworlds.co.uk> | ||
7 | |||
8 | acer-wmi is a driver to allow you to control various parts of your Acer laptop | ||
9 | hardware under Linux which are exposed via ACPI-WMI. | ||
10 | |||
11 | This driver completely replaces the old out-of-tree acer_acpi, which I am | ||
12 | currently maintaining for bug fixes only on pre-2.6.25 kernels. All development | ||
13 | work is now focused solely on acer-wmi. | ||
14 | |||
15 | Disclaimer | ||
16 | ********** | ||
17 | |||
18 | Acer and Wistron have provided nothing towards the development acer_acpi or | ||
19 | acer-wmi. All information we have has been through the efforts of the developers | ||
20 | and the users to discover as much as possible about the hardware. | ||
21 | |||
22 | As such, I do warn that this could break your hardware - this is extremely | ||
23 | unlikely of course, but please bear this in mind. | ||
24 | |||
25 | Background | ||
26 | ********** | ||
27 | |||
28 | acer-wmi is derived from acer_acpi, originally developed by Mark | ||
29 | Smith in 2005, then taken over by Carlos Corbacho in 2007, in order to activate | ||
30 | the wireless LAN card under a 64-bit version of Linux, as acerhk[1] (the | ||
31 | previous solution to the problem) relied on making 32 bit BIOS calls which are | ||
32 | not possible in kernel space from a 64 bit OS. | ||
33 | |||
34 | [1] acerhk: http://www.cakey.de/acerhk/ | ||
35 | |||
36 | Supported Hardware | ||
37 | ****************** | ||
38 | |||
39 | NOTE: The Acer Aspire One is not supported hardware. It cannot work with | ||
40 | acer-wmi until Acer fix their ACPI-WMI implementation on them, so has been | ||
41 | blacklisted until that happens. | ||
42 | |||
43 | Please see the website for the current list of known working hardware: | ||
44 | |||
45 | http://code.google.com/p/aceracpi/wiki/SupportedHardware | ||
46 | |||
47 | If your laptop is not listed, or listed as unknown, and works with acer-wmi, | ||
48 | please contact me with a copy of the DSDT. | ||
49 | |||
50 | If your Acer laptop doesn't work with acer-wmi, I would also like to see the | ||
51 | DSDT. | ||
52 | |||
53 | To send me the DSDT, as root/sudo: | ||
54 | |||
55 | cat /sys/firmware/acpi/tables/DSDT > dsdt | ||
56 | |||
57 | And send me the resulting 'dsdt' file. | ||
58 | |||
59 | Usage | ||
60 | ***** | ||
61 | |||
62 | On Acer laptops, acer-wmi should already be autoloaded based on DMI matching. | ||
63 | For non-Acer laptops, until WMI based autoloading support is added, you will | ||
64 | need to manually load acer-wmi. | ||
65 | |||
66 | acer-wmi creates /sys/devices/platform/acer-wmi, and fills it with various | ||
67 | files whose usage is detailed below, which enables you to control some of the | ||
68 | following (varies between models): | ||
69 | |||
70 | * the wireless LAN card radio | ||
71 | * inbuilt Bluetooth adapter | ||
72 | * inbuilt 3G card | ||
73 | * mail LED of your laptop | ||
74 | * brightness of the LCD panel | ||
75 | |||
76 | Wireless | ||
77 | ******** | ||
78 | |||
79 | With regards to wireless, all acer-wmi does is enable the radio on the card. It | ||
80 | is not responsible for the wireless LED - once the radio is enabled, this is | ||
81 | down to the wireless driver for your card. So the behaviour of the wireless LED, | ||
82 | once you enable the radio, will depend on your hardware and driver combination. | ||
83 | |||
84 | e.g. With the BCM4318 on the Acer Aspire 5020 series: | ||
85 | |||
86 | ndiswrapper: Light blinks on when transmitting | ||
87 | b43: Solid light, blinks off when transmitting | ||
88 | |||
89 | Wireless radio control is unconditionally enabled - all Acer laptops that support | ||
90 | acer-wmi come with built-in wireless. However, should you feel so inclined to | ||
91 | ever wish to remove the card, or swap it out at some point, please get in touch | ||
92 | with me, as we may well be able to gain some data on wireless card detection. | ||
93 | |||
94 | The wireless radio is exposed through rfkill. | ||
95 | |||
96 | Bluetooth | ||
97 | ********* | ||
98 | |||
99 | For bluetooth, this is an internal USB dongle, so once enabled, you will get | ||
100 | a USB device connection event, and a new USB device appears. When you disable | ||
101 | bluetooth, you get the reverse - a USB device disconnect event, followed by the | ||
102 | device disappearing again. | ||
103 | |||
104 | Bluetooth is autodetected by acer-wmi, so if you do not have a bluetooth module | ||
105 | installed in your laptop, this file won't exist (please be aware that it is | ||
106 | quite common for Acer not to fit bluetooth to their laptops - so just because | ||
107 | you have a bluetooth button on the laptop, doesn't mean that bluetooth is | ||
108 | installed). | ||
109 | |||
110 | For the adventurously minded - if you want to buy an internal bluetooth | ||
111 | module off the internet that is compatible with your laptop and fit it, then | ||
112 | it will work just fine with acer-wmi. | ||
113 | |||
114 | Bluetooth is exposed through rfkill. | ||
115 | |||
116 | 3G | ||
117 | ** | ||
118 | |||
119 | 3G is currently not autodetected, so the 'threeg' file is always created under | ||
120 | sysfs. So far, no-one in possession of an Acer laptop with 3G built-in appears to | ||
121 | have tried Linux, or reported back, so we don't have any information on this. | ||
122 | |||
123 | If you have an Acer laptop that does have a 3G card in, please contact me so we | ||
124 | can properly detect these, and find out a bit more about them. | ||
125 | |||
126 | To read the status of the 3G card (0=off, 1=on): | ||
127 | cat /sys/devices/platform/acer-wmi/threeg | ||
128 | |||
129 | To enable the 3G card: | ||
130 | echo 1 > /sys/devices/platform/acer-wmi/threeg | ||
131 | |||
132 | To disable the 3G card: | ||
133 | echo 0 > /sys/devices/platform/acer-wmi/threeg | ||
134 | |||
135 | To set the state of the 3G card when loading acer-wmi, pass: | ||
136 | threeg=X (where X is 0 or 1) | ||
137 | |||
138 | Mail LED | ||
139 | ******** | ||
140 | |||
141 | This can be found in most older Acer laptops supported by acer-wmi, and many | ||
142 | newer ones - it is built into the 'mail' button, and blinks when active. | ||
143 | |||
144 | On newer (WMID) laptops though, we have no way of detecting the mail LED. If | ||
145 | your laptop identifies itself in dmesg as a WMID model, then please try loading | ||
146 | acer_acpi with: | ||
147 | |||
148 | force_series=2490 | ||
149 | |||
150 | This will use a known alternative method of reading/ writing the mail LED. If | ||
151 | it works, please report back to me with the DMI data from your laptop so this | ||
152 | can be added to acer-wmi. | ||
153 | |||
154 | The LED is exposed through the LED subsystem, and can be found in: | ||
155 | |||
156 | /sys/devices/platform/acer-wmi/leds/acer-wmi::mail/ | ||
157 | |||
158 | The mail LED is autodetected, so if you don't have one, the LED device won't | ||
159 | be registered. | ||
160 | |||
161 | Backlight | ||
162 | ********* | ||
163 | |||
164 | The backlight brightness control is available on all acer-wmi supported | ||
165 | hardware. The maximum brightness level is usually 15, but on some newer laptops | ||
166 | it's 10 (this is again autodetected). | ||
167 | |||
168 | The backlight is exposed through the backlight subsystem, and can be found in: | ||
169 | |||
170 | /sys/devices/platform/acer-wmi/backlight/acer-wmi/ | ||
171 | |||
172 | Credits | ||
173 | ******* | ||
174 | |||
175 | Olaf Tauber, who did the real hard work when he developed acerhk | ||
176 | http://www.cakey.de/acerhk/ | ||
177 | All the authors of laptop ACPI modules in the kernel, whose work | ||
178 | was an inspiration in the early days of acer_acpi | ||
179 | Mathieu Segaud, who solved the problem with having to modprobe the driver | ||
180 | twice in acer_acpi 0.2. | ||
181 | Jim Ramsay, who added support for the WMID interface | ||
182 | Mark Smith, who started the original acer_acpi | ||
183 | |||
184 | And the many people who have used both acer_acpi and acer-wmi. | ||
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 1565eefd6fd5..61815483efa3 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt | |||
@@ -534,6 +534,8 @@ Events that are never propagated by the driver: | |||
534 | 0x2404 System is waking up from hibernation to undock | 534 | 0x2404 System is waking up from hibernation to undock |
535 | 0x2405 System is waking up from hibernation to eject bay | 535 | 0x2405 System is waking up from hibernation to eject bay |
536 | 0x5010 Brightness level changed/control event | 536 | 0x5010 Brightness level changed/control event |
537 | 0x6000 KEYBOARD: Numlock key pressed | ||
538 | 0x6005 KEYBOARD: Fn key pressed (TO BE VERIFIED) | ||
537 | 539 | ||
538 | Events that are propagated by the driver to userspace: | 540 | Events that are propagated by the driver to userspace: |
539 | 541 | ||
@@ -545,6 +547,8 @@ Events that are propagated by the driver to userspace: | |||
545 | 0x3006 Bay hotplug request (hint to power up SATA link when | 547 | 0x3006 Bay hotplug request (hint to power up SATA link when |
546 | the optical drive tray is ejected) | 548 | the optical drive tray is ejected) |
547 | 0x4003 Undocked (see 0x2x04), can sleep again | 549 | 0x4003 Undocked (see 0x2x04), can sleep again |
550 | 0x4010 Docked into hotplug port replicator (non-ACPI dock) | ||
551 | 0x4011 Undocked from hotplug port replicator (non-ACPI dock) | ||
548 | 0x500B Tablet pen inserted into its storage bay | 552 | 0x500B Tablet pen inserted into its storage bay |
549 | 0x500C Tablet pen removed from its storage bay | 553 | 0x500C Tablet pen removed from its storage bay |
550 | 0x6011 ALARM: battery is too hot | 554 | 0x6011 ALARM: battery is too hot |
@@ -552,6 +556,7 @@ Events that are propagated by the driver to userspace: | |||
552 | 0x6021 ALARM: a sensor is too hot | 556 | 0x6021 ALARM: a sensor is too hot |
553 | 0x6022 ALARM: a sensor is extremely hot | 557 | 0x6022 ALARM: a sensor is extremely hot |
554 | 0x6030 System thermal table changed | 558 | 0x6030 System thermal table changed |
559 | 0x6040 Nvidia Optimus/AC adapter related (TO BE VERIFIED) | ||
555 | 560 | ||
556 | Battery nearly empty alarms are a last resort attempt to get the | 561 | Battery nearly empty alarms are a last resort attempt to get the |
557 | operating system to hibernate or shutdown cleanly (0x2313), or shutdown | 562 | operating system to hibernate or shutdown cleanly (0x2313), or shutdown |
diff --git a/Documentation/lockstat.txt b/Documentation/lockstat.txt index 65f4c795015d..cef00d42ed5b 100644 --- a/Documentation/lockstat.txt +++ b/Documentation/lockstat.txt | |||
@@ -12,8 +12,9 @@ Because things like lock contention can severely impact performance. | |||
12 | - HOW | 12 | - HOW |
13 | 13 | ||
14 | Lockdep already has hooks in the lock functions and maps lock instances to | 14 | Lockdep already has hooks in the lock functions and maps lock instances to |
15 | lock classes. We build on that. The graph below shows the relation between | 15 | lock classes. We build on that (see Documentation/lockdep-design.txt). |
16 | the lock functions and the various hooks therein. | 16 | The graph below shows the relation between the lock functions and the various |
17 | hooks therein. | ||
17 | 18 | ||
18 | __acquire | 19 | __acquire |
19 | | | 20 | | |
@@ -128,6 +129,37 @@ points are the points we're contending with. | |||
128 | 129 | ||
129 | The integer part of the time values is in us. | 130 | The integer part of the time values is in us. |
130 | 131 | ||
132 | Dealing with nested locks, subclasses may appear: | ||
133 | |||
134 | 32............................................................................................................................................................................................... | ||
135 | 33 | ||
136 | 34 &rq->lock: 13128 13128 0.43 190.53 103881.26 97454 3453404 0.00 401.11 13224683.11 | ||
137 | 35 --------- | ||
138 | 36 &rq->lock 645 [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75 | ||
139 | 37 &rq->lock 297 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a | ||
140 | 38 &rq->lock 360 [<ffffffff8103c4c5>] select_task_rq_fair+0x1f0/0x74a | ||
141 | 39 &rq->lock 428 [<ffffffff81045f98>] scheduler_tick+0x46/0x1fb | ||
142 | 40 --------- | ||
143 | 41 &rq->lock 77 [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75 | ||
144 | 42 &rq->lock 174 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a | ||
145 | 43 &rq->lock 4715 [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54 | ||
146 | 44 &rq->lock 893 [<ffffffff81340524>] schedule+0x157/0x7b8 | ||
147 | 45 | ||
148 | 46............................................................................................................................................................................................... | ||
149 | 47 | ||
150 | 48 &rq->lock/1: 11526 11488 0.33 388.73 136294.31 21461 38404 0.00 37.93 109388.53 | ||
151 | 49 ----------- | ||
152 | 50 &rq->lock/1 11526 [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54 | ||
153 | 51 ----------- | ||
154 | 52 &rq->lock/1 5645 [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54 | ||
155 | 53 &rq->lock/1 1224 [<ffffffff81340524>] schedule+0x157/0x7b8 | ||
156 | 54 &rq->lock/1 4336 [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54 | ||
157 | 55 &rq->lock/1 181 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a | ||
158 | |||
159 | Line 48 shows statistics for the second subclass (/1) of &rq->lock class | ||
160 | (subclass starts from 0), since in this case, as line 50 suggests, | ||
161 | double_rq_lock actually acquires a nested lock of two spinlocks. | ||
162 | |||
131 | View the top contending locks: | 163 | View the top contending locks: |
132 | 164 | ||
133 | # grep : /proc/lock_stat | head | 165 | # grep : /proc/lock_stat | head |
@@ -136,7 +168,7 @@ View the top contending locks: | |||
136 | dcache_lock: 1037 1161 0.38 45.32 774.51 6611 243371 0.15 306.48 77387.24 | 168 | dcache_lock: 1037 1161 0.38 45.32 774.51 6611 243371 0.15 306.48 77387.24 |
137 | &inode->i_mutex: 161 286 18446744073709 62882.54 1244614.55 3653 20598 18446744073709 62318.60 1693822.74 | 169 | &inode->i_mutex: 161 286 18446744073709 62882.54 1244614.55 3653 20598 18446744073709 62318.60 1693822.74 |
138 | &zone->lru_lock: 94 94 0.53 7.33 92.10 4366 32690 0.29 59.81 16350.06 | 170 | &zone->lru_lock: 94 94 0.53 7.33 92.10 4366 32690 0.29 59.81 16350.06 |
139 | &inode->i_data.i_mmap_lock: 79 79 0.40 3.77 53.03 11779 87755 0.28 116.93 29898.44 | 171 | &inode->i_data.i_mmap_mutex: 79 79 0.40 3.77 53.03 11779 87755 0.28 116.93 29898.44 |
140 | &q->__queue_lock: 48 50 0.52 31.62 86.31 774 13131 0.17 113.08 12277.52 | 172 | &q->__queue_lock: 48 50 0.52 31.62 86.31 774 13131 0.17 113.08 12277.52 |
141 | &rq->rq_lock_key: 43 47 0.74 68.50 170.63 3706 33929 0.22 107.99 17460.62 | 173 | &rq->rq_lock_key: 43 47 0.74 68.50 170.63 3706 33929 0.22 107.99 17460.62 |
142 | &rq->rq_lock_key#2: 39 46 0.75 6.68 49.03 2979 32292 0.17 125.17 17137.63 | 174 | &rq->rq_lock_key#2: 39 46 0.75 6.68 49.03 2979 32292 0.17 125.17 17137.63 |
diff --git a/Documentation/md.txt b/Documentation/md.txt index 2366b1c8cf19..f0eee83ff78a 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt | |||
@@ -555,7 +555,7 @@ also have | |||
555 | sync_min | 555 | sync_min |
556 | sync_max | 556 | sync_max |
557 | The two values, given as numbers of sectors, indicate a range | 557 | The two values, given as numbers of sectors, indicate a range |
558 | withing the array where 'check'/'repair' will operate. Must be | 558 | within the array where 'check'/'repair' will operate. Must be |
559 | a multiple of chunk_size. When it reaches "sync_max" it will | 559 | a multiple of chunk_size. When it reaches "sync_max" it will |
560 | pause, rather than complete. | 560 | pause, rather than complete. |
561 | You can use 'select' or 'poll' on "sync_completed" to wait for | 561 | You can use 'select' or 'poll' on "sync_completed" to wait for |
diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX index fca586f5b853..93dd7a714075 100644 --- a/Documentation/mmc/00-INDEX +++ b/Documentation/mmc/00-INDEX | |||
@@ -2,3 +2,5 @@ | |||
2 | - this file | 2 | - this file |
3 | mmc-dev-attrs.txt | 3 | mmc-dev-attrs.txt |
4 | - info on SD and MMC device attributes | 4 | - info on SD and MMC device attributes |
5 | mmc-dev-parts.txt | ||
6 | - info on SD and MMC device partitions | ||
diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt index ff2bd685bced..8898a95b41e5 100644 --- a/Documentation/mmc/mmc-dev-attrs.txt +++ b/Documentation/mmc/mmc-dev-attrs.txt | |||
@@ -1,3 +1,13 @@ | |||
1 | SD and MMC Block Device Attributes | ||
2 | ================================== | ||
3 | |||
4 | These attributes are defined for the block devices associated with the | ||
5 | SD or MMC device. | ||
6 | |||
7 | The following attributes are read/write. | ||
8 | |||
9 | force_ro Enforce read-only access even if write protect switch is off. | ||
10 | |||
1 | SD and MMC Device Attributes | 11 | SD and MMC Device Attributes |
2 | ============================ | 12 | ============================ |
3 | 13 | ||
diff --git a/Documentation/mmc/mmc-dev-parts.txt b/Documentation/mmc/mmc-dev-parts.txt new file mode 100644 index 000000000000..2db28b8e662f --- /dev/null +++ b/Documentation/mmc/mmc-dev-parts.txt | |||
@@ -0,0 +1,27 @@ | |||
1 | SD and MMC Device Partitions | ||
2 | ============================ | ||
3 | |||
4 | Device partitions are additional logical block devices present on the | ||
5 | SD/MMC device. | ||
6 | |||
7 | As of this writing, MMC boot partitions as supported and exposed as | ||
8 | /dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the | ||
9 | parent /dev/mmcblkX. | ||
10 | |||
11 | MMC Boot Partitions | ||
12 | =================== | ||
13 | |||
14 | Read and write access is provided to the two MMC boot partitions. Due to | ||
15 | the sensitive nature of the boot partition contents, which often store | ||
16 | a bootloader or bootloader configuration tables crucial to booting the | ||
17 | platform, write access is disabled by default to reduce the chance of | ||
18 | accidental bricking. | ||
19 | |||
20 | To enable write access to /dev/mmcblkXbootY, disable the forced read-only | ||
21 | access with: | ||
22 | |||
23 | echo 0 > /sys/block/mmcblkXbootY/force_ro | ||
24 | |||
25 | To re-enable read-only access: | ||
26 | |||
27 | echo 1 > /sys/block/mmcblkXbootY/force_ro | ||
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt index ee496eb2f4a6..88d4afbdef98 100644 --- a/Documentation/networking/batman-adv.txt +++ b/Documentation/networking/batman-adv.txt | |||
@@ -1,4 +1,4 @@ | |||
1 | [state: 27-01-2011] | 1 | [state: 17-04-2011] |
2 | 2 | ||
3 | BATMAN-ADV | 3 | BATMAN-ADV |
4 | ---------- | 4 | ---------- |
@@ -19,6 +19,7 @@ duce the overhead to a minimum. It does not depend on any (other) | |||
19 | network driver, and can be used on wifi as well as ethernet lan, | 19 | network driver, and can be used on wifi as well as ethernet lan, |
20 | vpn, etc ... (anything with ethernet-style layer 2). | 20 | vpn, etc ... (anything with ethernet-style layer 2). |
21 | 21 | ||
22 | |||
22 | CONFIGURATION | 23 | CONFIGURATION |
23 | ------------- | 24 | ------------- |
24 | 25 | ||
@@ -160,13 +161,13 @@ face. Each entry can/has to have the following values: | |||
160 | -> "TQ mac value" - src mac's link quality towards mac address | 161 | -> "TQ mac value" - src mac's link quality towards mac address |
161 | of a neighbor originator's interface which | 162 | of a neighbor originator's interface which |
162 | is being used for routing | 163 | is being used for routing |
163 | -> "HNA mac" - HNA announced by source mac | 164 | -> "TT mac" - TT announced by source mac |
164 | -> "PRIMARY" - this is a primary interface | 165 | -> "PRIMARY" - this is a primary interface |
165 | -> "SEC mac" - secondary mac address of source | 166 | -> "SEC mac" - secondary mac address of source |
166 | (requires preceding PRIMARY) | 167 | (requires preceding PRIMARY) |
167 | 168 | ||
168 | The TQ value has a range from 4 to 255 with 255 being the best. | 169 | The TQ value has a range from 4 to 255 with 255 being the best. |
169 | The HNA entries are showing which hosts are connected to the mesh | 170 | The TT entries are showing which hosts are connected to the mesh |
170 | via bat0 or being bridged into the mesh network. The PRIMARY/SEC | 171 | via bat0 or being bridged into the mesh network. The PRIMARY/SEC |
171 | values are only applied on primary interfaces | 172 | values are only applied on primary interfaces |
172 | 173 | ||
@@ -199,7 +200,7 @@ abled during run time. Following log_levels are defined: | |||
199 | 200 | ||
200 | 0 - All debug output disabled | 201 | 0 - All debug output disabled |
201 | 1 - Enable messages related to routing / flooding / broadcasting | 202 | 1 - Enable messages related to routing / flooding / broadcasting |
202 | 2 - Enable route or hna added / changed / deleted | 203 | 2 - Enable route or tt entry added / changed / deleted |
203 | 3 - Enable all messages | 204 | 3 - Enable all messages |
204 | 205 | ||
205 | The debug output can be changed at runtime using the file | 206 | The debug output can be changed at runtime using the file |
@@ -207,7 +208,7 @@ The debug output can be changed at runtime using the file | |||
207 | 208 | ||
208 | # echo 2 > /sys/class/net/bat0/mesh/log_level | 209 | # echo 2 > /sys/class/net/bat0/mesh/log_level |
209 | 210 | ||
210 | will enable debug messages for when routes or HNAs change. | 211 | will enable debug messages for when routes or TTs change. |
211 | 212 | ||
212 | 213 | ||
213 | BATCTL | 214 | BATCTL |
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index e27202bb8d75..675612ff41ae 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt | |||
@@ -1,7 +1,7 @@ | |||
1 | 1 | ||
2 | Linux Ethernet Bonding Driver HOWTO | 2 | Linux Ethernet Bonding Driver HOWTO |
3 | 3 | ||
4 | Latest update: 23 September 2009 | 4 | Latest update: 27 April 2011 |
5 | 5 | ||
6 | Initial release : Thomas Davis <tadavis at lbl.gov> | 6 | Initial release : Thomas Davis <tadavis at lbl.gov> |
7 | Corrections, HA extensions : 2000/10/03-15 : | 7 | Corrections, HA extensions : 2000/10/03-15 : |
@@ -585,25 +585,23 @@ mode | |||
585 | chosen. | 585 | chosen. |
586 | 586 | ||
587 | num_grat_arp | 587 | num_grat_arp |
588 | |||
589 | Specifies the number of gratuitous ARPs to be issued after a | ||
590 | failover event. One gratuitous ARP is issued immediately after | ||
591 | the failover, subsequent ARPs are sent at a rate of one per link | ||
592 | monitor interval (arp_interval or miimon, whichever is active). | ||
593 | |||
594 | The valid range is 0 - 255; the default value is 1. This option | ||
595 | affects only the active-backup mode. This option was added for | ||
596 | bonding version 3.3.0. | ||
597 | |||
598 | num_unsol_na | 588 | num_unsol_na |
599 | 589 | ||
600 | Specifies the number of unsolicited IPv6 Neighbor Advertisements | 590 | Specify the number of peer notifications (gratuitous ARPs and |
601 | to be issued after a failover event. One unsolicited NA is issued | 591 | unsolicited IPv6 Neighbor Advertisements) to be issued after a |
602 | immediately after the failover. | 592 | failover event. As soon as the link is up on the new slave |
593 | (possibly immediately) a peer notification is sent on the | ||
594 | bonding device and each VLAN sub-device. This is repeated at | ||
595 | each link monitor interval (arp_interval or miimon, whichever | ||
596 | is active) if the number is greater than 1. | ||
603 | 597 | ||
604 | The valid range is 0 - 255; the default value is 1. This option | 598 | The valid range is 0 - 255; the default value is 1. These options |
605 | affects only the active-backup mode. This option was added for | 599 | affect only the active-backup mode. These options were added for |
606 | bonding version 3.4.0. | 600 | bonding versions 3.3.0 and 3.4.0 respectively. |
601 | |||
602 | From Linux 2.6.40 and bonding version 3.7.1, these notifications | ||
603 | are generated by the ipv4 and ipv6 code and the numbers of | ||
604 | repetitions cannot be set independently. | ||
607 | 605 | ||
608 | primary | 606 | primary |
609 | 607 | ||
@@ -772,8 +770,17 @@ resend_igmp | |||
772 | a failover event. One membership report is issued immediately after | 770 | a failover event. One membership report is issued immediately after |
773 | the failover, subsequent packets are sent in each 200ms interval. | 771 | the failover, subsequent packets are sent in each 200ms interval. |
774 | 772 | ||
775 | The valid range is 0 - 255; the default value is 1. This option | 773 | The valid range is 0 - 255; the default value is 1. A value of 0 |
776 | was added for bonding version 3.7.0. | 774 | prevents the IGMP membership report from being issued in response |
775 | to the failover event. | ||
776 | |||
777 | This option is useful for bonding modes balance-rr (0), active-backup | ||
778 | (1), balance-tlb (5) and balance-alb (6), in which a failover can | ||
779 | switch the IGMP traffic from one slave to another. Therefore a fresh | ||
780 | IGMP report must be issued to cause the switch to forward the incoming | ||
781 | IGMP traffic over the newly selected slave. | ||
782 | |||
783 | This option was added for bonding version 3.7.0. | ||
777 | 784 | ||
778 | 3. Configuring Bonding Devices | 785 | 3. Configuring Bonding Devices |
779 | ============================== | 786 | ============================== |
diff --git a/Documentation/networking/dns_resolver.txt b/Documentation/networking/dns_resolver.txt index 04ca06325b08..7f531ad83285 100644 --- a/Documentation/networking/dns_resolver.txt +++ b/Documentation/networking/dns_resolver.txt | |||
@@ -139,8 +139,8 @@ the key will be discarded and recreated when the data it holds has expired. | |||
139 | dns_query() returns a copy of the value attached to the key, or an error if | 139 | dns_query() returns a copy of the value attached to the key, or an error if |
140 | that is indicated instead. | 140 | that is indicated instead. |
141 | 141 | ||
142 | See <file:Documentation/keys-request-key.txt> for further information about | 142 | See <file:Documentation/security/keys-request-key.txt> for further |
143 | request-key function. | 143 | information about request-key function. |
144 | 144 | ||
145 | 145 | ||
146 | ========= | 146 | ========= |
diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt index 98953c0d5342..9a2a037194a5 100644 --- a/Documentation/networking/igb.txt +++ b/Documentation/networking/igb.txt | |||
@@ -93,6 +93,19 @@ Additional Configurations | |||
93 | REQUIREMENTS: MSI-X support is required for Multiqueue. If MSI-X is not | 93 | REQUIREMENTS: MSI-X support is required for Multiqueue. If MSI-X is not |
94 | found, the system will fallback to MSI or to Legacy interrupts. | 94 | found, the system will fallback to MSI or to Legacy interrupts. |
95 | 95 | ||
96 | MAC and VLAN anti-spoofing feature | ||
97 | ---------------------------------- | ||
98 | When a malicious driver attempts to send a spoofed packet, it is dropped by | ||
99 | the hardware and not transmitted. An interrupt is sent to the PF driver | ||
100 | notifying it of the spoof attempt. | ||
101 | |||
102 | When a spoofed packet is detected the PF driver will send the following | ||
103 | message to the system log (displayed by the "dmesg" command): | ||
104 | |||
105 | Spoof event(s) detected on VF(n) | ||
106 | |||
107 | Where n=the VF that attempted to do the spoofing. | ||
108 | |||
96 | Support | 109 | Support |
97 | ======= | 110 | ======= |
98 | 111 | ||
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index d3d653a5f9b9..bfe924217f24 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt | |||
@@ -346,7 +346,7 @@ tcp_orphan_retries - INTEGER | |||
346 | when RTO retransmissions remain unacknowledged. | 346 | when RTO retransmissions remain unacknowledged. |
347 | See tcp_retries2 for more details. | 347 | See tcp_retries2 for more details. |
348 | 348 | ||
349 | The default value is 7. | 349 | The default value is 8. |
350 | If your machine is a loaded WEB server, | 350 | If your machine is a loaded WEB server, |
351 | you should think about lowering this value, such sockets | 351 | you should think about lowering this value, such sockets |
352 | may consume significant resources. Cf. tcp_max_orphans. | 352 | may consume significant resources. Cf. tcp_max_orphans. |
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 1971bcf48a60..64565aac6e40 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt | |||
@@ -279,11 +279,15 @@ When the system goes into the standby or memory sleep state, the phases are: | |||
279 | time.) Unlike the other suspend-related phases, during the prepare | 279 | time.) Unlike the other suspend-related phases, during the prepare |
280 | phase the device tree is traversed top-down. | 280 | phase the device tree is traversed top-down. |
281 | 281 | ||
282 | The prepare phase uses only a bus callback. After the callback method | 282 | In addition to that, if device drivers need to allocate additional |
283 | returns, no new children may be registered below the device. The method | 283 | memory to be able to hadle device suspend correctly, that should be |
284 | may also prepare the device or driver in some way for the upcoming | 284 | done in the prepare phase. |
285 | system power transition, but it should not put the device into a | 285 | |
286 | low-power state. | 286 | After the prepare callback method returns, no new children may be |
287 | registered below the device. The method may also prepare the device or | ||
288 | driver in some way for the upcoming system power transition (for | ||
289 | example, by allocating additional memory required for this purpose), but | ||
290 | it should not put the device into a low-power state. | ||
287 | 291 | ||
288 | 2. The suspend methods should quiesce the device to stop it from performing | 292 | 2. The suspend methods should quiesce the device to stop it from performing |
289 | I/O. They also may save the device registers and put it into the | 293 | I/O. They also may save the device registers and put it into the |
@@ -516,59 +520,20 @@ Support for power domains is provided through the pwr_domain field of struct | |||
516 | device. This field is a pointer to an object of type struct dev_power_domain, | 520 | device. This field is a pointer to an object of type struct dev_power_domain, |
517 | defined in include/linux/pm.h, providing a set of power management callbacks | 521 | defined in include/linux/pm.h, providing a set of power management callbacks |
518 | analogous to the subsystem-level and device driver callbacks that are executed | 522 | analogous to the subsystem-level and device driver callbacks that are executed |
519 | for the given device during all power transitions, in addition to the respective | 523 | for the given device during all power transitions, instead of the respective |
520 | subsystem-level callbacks. Specifically, the power domain "suspend" callbacks | 524 | subsystem-level callbacks. Specifically, if a device's pm_domain pointer is |
521 | (i.e. ->runtime_suspend(), ->suspend(), ->freeze(), ->poweroff(), etc.) are | 525 | not NULL, the ->suspend() callback from the object pointed to by it will be |
522 | executed after the analogous subsystem-level callbacks, while the power domain | 526 | executed instead of its subsystem's (e.g. bus type's) ->suspend() callback and |
523 | "resume" callbacks (i.e. ->runtime_resume(), ->resume(), ->thaw(), ->restore, | 527 | anlogously for all of the remaining callbacks. In other words, power management |
524 | etc.) are executed before the analogous subsystem-level callbacks. Error codes | 528 | domain callbacks, if defined for the given device, always take precedence over |
525 | returned by the "suspend" and "resume" power domain callbacks are ignored. | 529 | the callbacks provided by the device's subsystem (e.g. bus type). |
526 | 530 | ||
527 | Power domain ->runtime_idle() callback is executed before the subsystem-level | 531 | The support for device power management domains is only relevant to platforms |
528 | ->runtime_idle() callback and the result returned by it is not ignored. Namely, | 532 | needing to use the same device driver power management callbacks in many |
529 | if it returns error code, the subsystem-level ->runtime_idle() callback will not | 533 | different power domain configurations and wanting to avoid incorporating the |
530 | be called and the helper function rpm_idle() executing it will return error | 534 | support for power domains into subsystem-level callbacks, for example by |
531 | code. This mechanism is intended to help platforms where saving device state | 535 | modifying the platform bus type. Other platforms need not implement it or take |
532 | is a time consuming operation and should only be carried out if all devices | 536 | it into account in any way. |
533 | in the power domain are idle, before turning off the shared power resource(s). | ||
534 | Namely, the power domain ->runtime_idle() callback may return error code until | ||
535 | the pm_runtime_idle() helper (or its asychronous version) has been called for | ||
536 | all devices in the power domain (it is recommended that the returned error code | ||
537 | be -EBUSY in those cases), preventing the subsystem-level ->runtime_idle() | ||
538 | callback from being run prematurely. | ||
539 | |||
540 | The support for device power domains is only relevant to platforms needing to | ||
541 | use the same subsystem-level (e.g. platform bus type) and device driver power | ||
542 | management callbacks in many different power domain configurations and wanting | ||
543 | to avoid incorporating the support for power domains into the subsystem-level | ||
544 | callbacks. The other platforms need not implement it or take it into account | ||
545 | in any way. | ||
546 | |||
547 | |||
548 | System Devices | ||
549 | -------------- | ||
550 | System devices (sysdevs) follow a slightly different API, which can be found in | ||
551 | |||
552 | include/linux/sysdev.h | ||
553 | drivers/base/sys.c | ||
554 | |||
555 | System devices will be suspended with interrupts disabled, and after all other | ||
556 | devices have been suspended. On resume, they will be resumed before any other | ||
557 | devices, and also with interrupts disabled. These things occur in special | ||
558 | "sysdev_driver" phases, which affect only system devices. | ||
559 | |||
560 | Thus, after the suspend_noirq (or freeze_noirq or poweroff_noirq) phase, when | ||
561 | the non-boot CPUs are all offline and IRQs are disabled on the remaining online | ||
562 | CPU, then a sysdev_driver.suspend phase is carried out, and the system enters a | ||
563 | sleep state (or a system image is created). During resume (or after the image | ||
564 | has been created or loaded) a sysdev_driver.resume phase is carried out, IRQs | ||
565 | are enabled on the only online CPU, the non-boot CPUs are enabled, and the | ||
566 | resume_noirq (or thaw_noirq or restore_noirq) phase begins. | ||
567 | |||
568 | Code to actually enter and exit the system-wide low power state sometimes | ||
569 | involves hardware details that are only known to the boot firmware, and | ||
570 | may leave a CPU running software (from SRAM or flash memory) that monitors | ||
571 | the system and manages its wakeup sequence. | ||
572 | 537 | ||
573 | 538 | ||
574 | Device Low Power (suspend) States | 539 | Device Low Power (suspend) States |
diff --git a/Documentation/power/notifiers.txt b/Documentation/power/notifiers.txt index cf980709122a..c2a4a346c0d9 100644 --- a/Documentation/power/notifiers.txt +++ b/Documentation/power/notifiers.txt | |||
@@ -1,46 +1,41 @@ | |||
1 | Suspend notifiers | 1 | Suspend notifiers |
2 | (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL | 2 | (C) 2007-2011 Rafael J. Wysocki <rjw@sisk.pl>, GPL |
3 | 3 | ||
4 | There are some operations that device drivers may want to carry out in their | 4 | There are some operations that subsystems or drivers may want to carry out |
5 | .suspend() routines, but shouldn't, because they can cause the hibernation or | 5 | before hibernation/suspend or after restore/resume, but they require the system |
6 | suspend to fail. For example, a driver may want to allocate a substantial amount | 6 | to be fully functional, so the drivers' and subsystems' .suspend() and .resume() |
7 | of memory (like 50 MB) in .suspend(), but that shouldn't be done after the | 7 | or even .prepare() and .complete() callbacks are not suitable for this purpose. |
8 | swsusp's memory shrinker has run. | 8 | For example, device drivers may want to upload firmware to their devices after |
9 | 9 | resume/restore, but they cannot do it by calling request_firmware() from their | |
10 | Also, there may be some operations, that subsystems want to carry out before a | 10 | .resume() or .complete() routines (user land processes are frozen at these |
11 | hibernation/suspend or after a restore/resume, requiring the system to be fully | 11 | points). The solution may be to load the firmware into memory before processes |
12 | functional, so the drivers' .suspend() and .resume() routines are not suitable | 12 | are frozen and upload it from there in the .resume() routine. |
13 | for this purpose. For example, device drivers may want to upload firmware to | 13 | A suspend/hibernation notifier may be used for this purpose. |
14 | their devices after a restore from a hibernation image, but they cannot do it by | 14 | |
15 | calling request_firmware() from their .resume() routines (user land processes | 15 | The subsystems or drivers having such needs can register suspend notifiers that |
16 | are frozen at this point). The solution may be to load the firmware into | 16 | will be called upon the following events by the PM core: |
17 | memory before processes are frozen and upload it from there in the .resume() | ||
18 | routine. Of course, a hibernation notifier may be used for this purpose. | ||
19 | |||
20 | The subsystems that have such needs can register suspend notifiers that will be | ||
21 | called upon the following events by the suspend core: | ||
22 | 17 | ||
23 | PM_HIBERNATION_PREPARE The system is going to hibernate or suspend, tasks will | 18 | PM_HIBERNATION_PREPARE The system is going to hibernate or suspend, tasks will |
24 | be frozen immediately. | 19 | be frozen immediately. |
25 | 20 | ||
26 | PM_POST_HIBERNATION The system memory state has been restored from a | 21 | PM_POST_HIBERNATION The system memory state has been restored from a |
27 | hibernation image or an error occurred during the | 22 | hibernation image or an error occurred during |
28 | hibernation. Device drivers' .resume() callbacks have | 23 | hibernation. Device drivers' restore callbacks have |
29 | been executed and tasks have been thawed. | 24 | been executed and tasks have been thawed. |
30 | 25 | ||
31 | PM_RESTORE_PREPARE The system is going to restore a hibernation image. | 26 | PM_RESTORE_PREPARE The system is going to restore a hibernation image. |
32 | If all goes well the restored kernel will issue a | 27 | If all goes well, the restored kernel will issue a |
33 | PM_POST_HIBERNATION notification. | 28 | PM_POST_HIBERNATION notification. |
34 | 29 | ||
35 | PM_POST_RESTORE An error occurred during the hibernation restore. | 30 | PM_POST_RESTORE An error occurred during restore from hibernation. |
36 | Device drivers' .resume() callbacks have been executed | 31 | Device drivers' restore callbacks have been executed |
37 | and tasks have been thawed. | 32 | and tasks have been thawed. |
38 | 33 | ||
39 | PM_SUSPEND_PREPARE The system is preparing for a suspend. | 34 | PM_SUSPEND_PREPARE The system is preparing for suspend. |
40 | 35 | ||
41 | PM_POST_SUSPEND The system has just resumed or an error occurred during | 36 | PM_POST_SUSPEND The system has just resumed or an error occurred during |
42 | the suspend. Device drivers' .resume() callbacks have | 37 | suspend. Device drivers' resume callbacks have been |
43 | been executed and tasks have been thawed. | 38 | executed and tasks have been thawed. |
44 | 39 | ||
45 | It is generally assumed that whatever the notifiers do for | 40 | It is generally assumed that whatever the notifiers do for |
46 | PM_HIBERNATION_PREPARE, should be undone for PM_POST_HIBERNATION. Analogously, | 41 | PM_HIBERNATION_PREPARE, should be undone for PM_POST_HIBERNATION. Analogously, |
diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt index bdec39b9bd75..b42419b52e44 100644 --- a/Documentation/power/regulator/machine.txt +++ b/Documentation/power/regulator/machine.txt | |||
@@ -53,11 +53,11 @@ static struct regulator_init_data regulator1_data = { | |||
53 | 53 | ||
54 | Regulator-1 supplies power to Regulator-2. This relationship must be registered | 54 | Regulator-1 supplies power to Regulator-2. This relationship must be registered |
55 | with the core so that Regulator-1 is also enabled when Consumer A enables its | 55 | with the core so that Regulator-1 is also enabled when Consumer A enables its |
56 | supply (Regulator-2). The supply regulator is set by the supply_regulator_dev | 56 | supply (Regulator-2). The supply regulator is set by the supply_regulator |
57 | field below:- | 57 | field below:- |
58 | 58 | ||
59 | static struct regulator_init_data regulator2_data = { | 59 | static struct regulator_init_data regulator2_data = { |
60 | .supply_regulator_dev = &platform_regulator1_device.dev, | 60 | .supply_regulator = "regulator_name", |
61 | .constraints = { | 61 | .constraints = { |
62 | .min_uV = 1800000, | 62 | .min_uV = 1800000, |
63 | .max_uV = 2000000, | 63 | .max_uV = 2000000, |
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 654097b130b4..b24875b1ced5 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt | |||
@@ -501,13 +501,29 @@ helper functions described in Section 4. In that case, pm_runtime_resume() | |||
501 | should be used. Of course, for this purpose the device's run-time PM has to be | 501 | should be used. Of course, for this purpose the device's run-time PM has to be |
502 | enabled earlier by calling pm_runtime_enable(). | 502 | enabled earlier by calling pm_runtime_enable(). |
503 | 503 | ||
504 | If the device bus type's or driver's ->probe() or ->remove() callback runs | 504 | If the device bus type's or driver's ->probe() callback runs |
505 | pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts, | 505 | pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts, |
506 | they will fail returning -EAGAIN, because the device's usage counter is | 506 | they will fail returning -EAGAIN, because the device's usage counter is |
507 | incremented by the core before executing ->probe() and ->remove(). Still, it | 507 | incremented by the driver core before executing ->probe(). Still, it may be |
508 | may be desirable to suspend the device as soon as ->probe() or ->remove() has | 508 | desirable to suspend the device as soon as ->probe() has finished, so the driver |
509 | finished, so the PM core uses pm_runtime_idle_sync() to invoke the | 509 | core uses pm_runtime_put_sync() to invoke the subsystem-level idle callback for |
510 | subsystem-level idle callback for the device at that time. | 510 | the device at that time. |
511 | |||
512 | Moreover, the driver core prevents runtime PM callbacks from racing with the bus | ||
513 | notifier callback in __device_release_driver(), which is necessary, because the | ||
514 | notifier is used by some subsystems to carry out operations affecting the | ||
515 | runtime PM functionality. It does so by calling pm_runtime_get_sync() before | ||
516 | driver_sysfs_remove() and the BUS_NOTIFY_UNBIND_DRIVER notifications. This | ||
517 | resumes the device if it's in the suspended state and prevents it from | ||
518 | being suspended again while those routines are being executed. | ||
519 | |||
520 | To allow bus types and drivers to put devices into the suspended state by | ||
521 | calling pm_runtime_suspend() from their ->remove() routines, the driver core | ||
522 | executes pm_runtime_put_sync() after running the BUS_NOTIFY_UNBIND_DRIVER | ||
523 | notifications in __device_release_driver(). This requires bus types and | ||
524 | drivers to make their ->remove() callbacks avoid races with runtime PM directly, | ||
525 | but also it allows of more flexibility in the handling of devices during the | ||
526 | removal of their drivers. | ||
511 | 527 | ||
512 | The user space can effectively disallow the driver of the device to power manage | 528 | The user space can effectively disallow the driver of the device to power manage |
513 | it at run time by changing the value of its /sys/devices/.../power/control | 529 | it at run time by changing the value of its /sys/devices/.../power/control |
@@ -566,11 +582,6 @@ to do this is: | |||
566 | pm_runtime_set_active(dev); | 582 | pm_runtime_set_active(dev); |
567 | pm_runtime_enable(dev); | 583 | pm_runtime_enable(dev); |
568 | 584 | ||
569 | The PM core always increments the run-time usage counter before calling the | ||
570 | ->prepare() callback and decrements it after calling the ->complete() callback. | ||
571 | Hence disabling run-time PM temporarily like this will not cause any run-time | ||
572 | suspend callbacks to be lost. | ||
573 | |||
574 | 7. Generic subsystem callbacks | 585 | 7. Generic subsystem callbacks |
575 | 586 | ||
576 | Subsystems may wish to conserve code space by using the set of generic power | 587 | Subsystems may wish to conserve code space by using the set of generic power |
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 1b5a5ddbc3ef..5df176ed59b8 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt | |||
@@ -9,7 +9,121 @@ If variable is of Type, use printk format specifier: | |||
9 | size_t %zu or %zx | 9 | size_t %zu or %zx |
10 | ssize_t %zd or %zx | 10 | ssize_t %zd or %zx |
11 | 11 | ||
12 | Raw pointer value SHOULD be printed with %p. | 12 | Raw pointer value SHOULD be printed with %p. The kernel supports |
13 | the following extended format specifiers for pointer types: | ||
14 | |||
15 | Symbols/Function Pointers: | ||
16 | |||
17 | %pF versatile_init+0x0/0x110 | ||
18 | %pf versatile_init | ||
19 | %pS versatile_init+0x0/0x110 | ||
20 | %ps versatile_init | ||
21 | %pB prev_fn_of_versatile_init+0x88/0x88 | ||
22 | |||
23 | For printing symbols and function pointers. The 'S' and 's' specifiers | ||
24 | result in the symbol name with ('S') or without ('s') offsets. Where | ||
25 | this is used on a kernel without KALLSYMS - the symbol address is | ||
26 | printed instead. | ||
27 | |||
28 | The 'B' specifier results in the symbol name with offsets and should be | ||
29 | used when printing stack backtraces. The specifier takes into | ||
30 | consideration the effect of compiler optimisations which may occur | ||
31 | when tail-call's are used and marked with the noreturn GCC attribute. | ||
32 | |||
33 | On ia64, ppc64 and parisc64 architectures function pointers are | ||
34 | actually function descriptors which must first be resolved. The 'F' and | ||
35 | 'f' specifiers perform this resolution and then provide the same | ||
36 | functionality as the 'S' and 's' specifiers. | ||
37 | |||
38 | Kernel Pointers: | ||
39 | |||
40 | %pK 0x01234567 or 0x0123456789abcdef | ||
41 | |||
42 | For printing kernel pointers which should be hidden from unprivileged | ||
43 | users. The behaviour of %pK depends on the kptr_restrict sysctl - see | ||
44 | Documentation/sysctl/kernel.txt for more details. | ||
45 | |||
46 | Struct Resources: | ||
47 | |||
48 | %pr [mem 0x60000000-0x6fffffff flags 0x2200] or | ||
49 | [mem 0x0000000060000000-0x000000006fffffff flags 0x2200] | ||
50 | %pR [mem 0x60000000-0x6fffffff pref] or | ||
51 | [mem 0x0000000060000000-0x000000006fffffff pref] | ||
52 | |||
53 | For printing struct resources. The 'R' and 'r' specifiers result in a | ||
54 | printed resource with ('R') or without ('r') a decoded flags member. | ||
55 | |||
56 | MAC/FDDI addresses: | ||
57 | |||
58 | %pM 00:01:02:03:04:05 | ||
59 | %pMF 00-01-02-03-04-05 | ||
60 | %pm 000102030405 | ||
61 | |||
62 | For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm' | ||
63 | specifiers result in a printed address with ('M') or without ('m') byte | ||
64 | separators. The default byte separator is the colon (':'). | ||
65 | |||
66 | Where FDDI addresses are concerned the 'F' specifier can be used after | ||
67 | the 'M' specifier to use dash ('-') separators instead of the default | ||
68 | separator. | ||
69 | |||
70 | IPv4 addresses: | ||
71 | |||
72 | %pI4 1.2.3.4 | ||
73 | %pi4 001.002.003.004 | ||
74 | %p[Ii][hnbl] | ||
75 | |||
76 | For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4' | ||
77 | specifiers result in a printed address with ('i4') or without ('I4') | ||
78 | leading zeros. | ||
79 | |||
80 | The additional 'h', 'n', 'b', and 'l' specifiers are used to specify | ||
81 | host, network, big or little endian order addresses respectively. Where | ||
82 | no specifier is provided the default network/big endian order is used. | ||
83 | |||
84 | IPv6 addresses: | ||
85 | |||
86 | %pI6 0001:0002:0003:0004:0005:0006:0007:0008 | ||
87 | %pi6 00010002000300040005000600070008 | ||
88 | %pI6c 1:2:3:4:5:6:7:8 | ||
89 | |||
90 | For printing IPv6 network-order 16-bit hex addresses. The 'I6' and 'i6' | ||
91 | specifiers result in a printed address with ('I6') or without ('i6') | ||
92 | colon-separators. Leading zeros are always used. | ||
93 | |||
94 | The additional 'c' specifier can be used with the 'I' specifier to | ||
95 | print a compressed IPv6 address as described by | ||
96 | http://tools.ietf.org/html/rfc5952 | ||
97 | |||
98 | UUID/GUID addresses: | ||
99 | |||
100 | %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f | ||
101 | %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F | ||
102 | %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f | ||
103 | %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F | ||
104 | |||
105 | For printing 16-byte UUID/GUIDs addresses. The additional 'l', 'L', | ||
106 | 'b' and 'B' specifiers are used to specify a little endian order in | ||
107 | lower ('l') or upper case ('L') hex characters - and big endian order | ||
108 | in lower ('b') or upper case ('B') hex characters. | ||
109 | |||
110 | Where no additional specifiers are used the default little endian | ||
111 | order with lower case hex characters will be printed. | ||
112 | |||
113 | struct va_format: | ||
114 | |||
115 | %pV | ||
116 | |||
117 | For printing struct va_format structures. These contain a format string | ||
118 | and va_list as follows: | ||
119 | |||
120 | struct va_format { | ||
121 | const char *fmt; | ||
122 | va_list *va; | ||
123 | }; | ||
124 | |||
125 | Do not use this feature without some mechanism to verify the | ||
126 | correctness of the format string and va_list arguments. | ||
13 | 127 | ||
14 | u64 SHOULD be printed with %llu/%llx, (unsigned long long): | 128 | u64 SHOULD be printed with %llu/%llx, (unsigned long long): |
15 | 129 | ||
@@ -32,4 +146,5 @@ Reminder: sizeof() result is of type size_t. | |||
32 | Thank you for your cooperation and attention. | 146 | Thank you for your cooperation and attention. |
33 | 147 | ||
34 | 148 | ||
35 | By Randy Dunlap <rdunlap@xenotime.net> | 149 | By Randy Dunlap <rdunlap@xenotime.net> and |
150 | Andrew Murray <amurray@mpc-data.co.uk> | ||
diff --git a/Documentation/pti/pti_intel_mid.txt b/Documentation/pti/pti_intel_mid.txt new file mode 100644 index 000000000000..e7a5b6d1f7a9 --- /dev/null +++ b/Documentation/pti/pti_intel_mid.txt | |||
@@ -0,0 +1,99 @@ | |||
1 | The Intel MID PTI project is HW implemented in Intel Atom | ||
2 | system-on-a-chip designs based on the Parallel Trace | ||
3 | Interface for MIPI P1149.7 cJTAG standard. The kernel solution | ||
4 | for this platform involves the following files: | ||
5 | |||
6 | ./include/linux/pti.h | ||
7 | ./drivers/.../n_tracesink.h | ||
8 | ./drivers/.../n_tracerouter.c | ||
9 | ./drivers/.../n_tracesink.c | ||
10 | ./drivers/.../pti.c | ||
11 | |||
12 | pti.c is the driver that enables various debugging features | ||
13 | popular on platforms from certain mobile manufacturers. | ||
14 | n_tracerouter.c and n_tracesink.c allow extra system information to | ||
15 | be collected and routed to the pti driver, such as trace | ||
16 | debugging data from a modem. Although n_tracerouter | ||
17 | and n_tracesink are a part of the complete PTI solution, | ||
18 | these two line disciplines can work separately from | ||
19 | pti.c and route any data stream from one /dev/tty node | ||
20 | to another /dev/tty node via kernel-space. This provides | ||
21 | a stable, reliable connection that will not break unless | ||
22 | the user-space application shuts down (plus avoids | ||
23 | kernel->user->kernel context switch overheads of routing | ||
24 | data). | ||
25 | |||
26 | An example debugging usage for this driver system: | ||
27 | *Hook /dev/ttyPTI0 to syslogd. Opening this port will also start | ||
28 | a console device to further capture debugging messages to PTI. | ||
29 | *Hook /dev/ttyPTI1 to modem debugging data to write to PTI HW. | ||
30 | This is where n_tracerouter and n_tracesink are used. | ||
31 | *Hook /dev/pti to a user-level debugging application for writing | ||
32 | to PTI HW. | ||
33 | *Use mipi_* Kernel Driver API in other device drivers for | ||
34 | debugging to PTI by first requesting a PTI write address via | ||
35 | mipi_request_masterchannel(1). | ||
36 | |||
37 | Below is example pseudo-code on how a 'privileged' application | ||
38 | can hook up n_tracerouter and n_tracesink to any tty on | ||
39 | a system. 'Privileged' means the application has enough | ||
40 | privileges to successfully manipulate the ldisc drivers | ||
41 | but is not just blindly executing as 'root'. Keep in mind | ||
42 | the use of ioctl(,TIOCSETD,) is not specific to the n_tracerouter | ||
43 | and n_tracesink line discpline drivers but is a generic | ||
44 | operation for a program to use a line discpline driver | ||
45 | on a tty port other than the default n_tty. | ||
46 | |||
47 | /////////// To hook up n_tracerouter and n_tracesink ///////// | ||
48 | |||
49 | // Note that n_tracerouter depends on n_tracesink. | ||
50 | #include <errno.h> | ||
51 | #define ONE_TTY "/dev/ttyOne" | ||
52 | #define TWO_TTY "/dev/ttyTwo" | ||
53 | |||
54 | // needed global to hand onto ldisc connection | ||
55 | static int g_fd_source = -1; | ||
56 | static int g_fd_sink = -1; | ||
57 | |||
58 | // these two vars used to grab LDISC values from loaded ldisc drivers | ||
59 | // in OS. Look at /proc/tty/ldiscs to get the right numbers from | ||
60 | // the ldiscs loaded in the system. | ||
61 | int source_ldisc_num, sink_ldisc_num = -1; | ||
62 | int retval; | ||
63 | |||
64 | g_fd_source = open(ONE_TTY, O_RDWR); // must be R/W | ||
65 | g_fd_sink = open(TWO_TTY, O_RDWR); // must be R/W | ||
66 | |||
67 | if (g_fd_source <= 0) || (g_fd_sink <= 0) { | ||
68 | // doubt you'll want to use these exact error lines of code | ||
69 | printf("Error on open(). errno: %d\n",errno); | ||
70 | return errno; | ||
71 | } | ||
72 | |||
73 | retval = ioctl(g_fd_sink, TIOCSETD, &sink_ldisc_num); | ||
74 | if (retval < 0) { | ||
75 | printf("Error on ioctl(). errno: %d\n", errno); | ||
76 | return errno; | ||
77 | } | ||
78 | |||
79 | retval = ioctl(g_fd_source, TIOCSETD, &source_ldisc_num); | ||
80 | if (retval < 0) { | ||
81 | printf("Error on ioctl(). errno: %d\n", errno); | ||
82 | return errno; | ||
83 | } | ||
84 | |||
85 | /////////// To disconnect n_tracerouter and n_tracesink //////// | ||
86 | |||
87 | // First make sure data through the ldiscs has stopped. | ||
88 | |||
89 | // Second, disconnect ldiscs. This provides a | ||
90 | // little cleaner shutdown on tty stack. | ||
91 | sink_ldisc_num = 0; | ||
92 | source_ldisc_num = 0; | ||
93 | ioctl(g_fd_uart, TIOCSETD, &sink_ldisc_num); | ||
94 | ioctl(g_fd_gadget, TIOCSETD, &source_ldisc_num); | ||
95 | |||
96 | // Three, program closes connection, and cleanup: | ||
97 | close(g_fd_uart); | ||
98 | close(g_fd_gadget); | ||
99 | g_fd_uart = g_fd_gadget = NULL; | ||
diff --git a/Documentation/ptp/ptp.txt b/Documentation/ptp/ptp.txt new file mode 100644 index 000000000000..ae8fef86b832 --- /dev/null +++ b/Documentation/ptp/ptp.txt | |||
@@ -0,0 +1,89 @@ | |||
1 | |||
2 | * PTP hardware clock infrastructure for Linux | ||
3 | |||
4 | This patch set introduces support for IEEE 1588 PTP clocks in | ||
5 | Linux. Together with the SO_TIMESTAMPING socket options, this | ||
6 | presents a standardized method for developing PTP user space | ||
7 | programs, synchronizing Linux with external clocks, and using the | ||
8 | ancillary features of PTP hardware clocks. | ||
9 | |||
10 | A new class driver exports a kernel interface for specific clock | ||
11 | drivers and a user space interface. The infrastructure supports a | ||
12 | complete set of PTP hardware clock functionality. | ||
13 | |||
14 | + Basic clock operations | ||
15 | - Set time | ||
16 | - Get time | ||
17 | - Shift the clock by a given offset atomically | ||
18 | - Adjust clock frequency | ||
19 | |||
20 | + Ancillary clock features | ||
21 | - One short or periodic alarms, with signal delivery to user program | ||
22 | - Time stamp external events | ||
23 | - Period output signals configurable from user space | ||
24 | - Synchronization of the Linux system time via the PPS subsystem | ||
25 | |||
26 | ** PTP hardware clock kernel API | ||
27 | |||
28 | A PTP clock driver registers itself with the class driver. The | ||
29 | class driver handles all of the dealings with user space. The | ||
30 | author of a clock driver need only implement the details of | ||
31 | programming the clock hardware. The clock driver notifies the class | ||
32 | driver of asynchronous events (alarms and external time stamps) via | ||
33 | a simple message passing interface. | ||
34 | |||
35 | The class driver supports multiple PTP clock drivers. In normal use | ||
36 | cases, only one PTP clock is needed. However, for testing and | ||
37 | development, it can be useful to have more than one clock in a | ||
38 | single system, in order to allow performance comparisons. | ||
39 | |||
40 | ** PTP hardware clock user space API | ||
41 | |||
42 | The class driver also creates a character device for each | ||
43 | registered clock. User space can use an open file descriptor from | ||
44 | the character device as a POSIX clock id and may call | ||
45 | clock_gettime, clock_settime, and clock_adjtime. These calls | ||
46 | implement the basic clock operations. | ||
47 | |||
48 | User space programs may control the clock using standardized | ||
49 | ioctls. A program may query, enable, configure, and disable the | ||
50 | ancillary clock features. User space can receive time stamped | ||
51 | events via blocking read() and poll(). One shot and periodic | ||
52 | signals may be configured via the POSIX timer_settime() system | ||
53 | call. | ||
54 | |||
55 | ** Writing clock drivers | ||
56 | |||
57 | Clock drivers include include/linux/ptp_clock_kernel.h and register | ||
58 | themselves by presenting a 'struct ptp_clock_info' to the | ||
59 | registration method. Clock drivers must implement all of the | ||
60 | functions in the interface. If a clock does not offer a particular | ||
61 | ancillary feature, then the driver should just return -EOPNOTSUPP | ||
62 | from those functions. | ||
63 | |||
64 | Drivers must ensure that all of the methods in interface are | ||
65 | reentrant. Since most hardware implementations treat the time value | ||
66 | as a 64 bit integer accessed as two 32 bit registers, drivers | ||
67 | should use spin_lock_irqsave/spin_unlock_irqrestore to protect | ||
68 | against concurrent access. This locking cannot be accomplished in | ||
69 | class driver, since the lock may also be needed by the clock | ||
70 | driver's interrupt service routine. | ||
71 | |||
72 | ** Supported hardware | ||
73 | |||
74 | + Freescale eTSEC gianfar | ||
75 | - 2 Time stamp external triggers, programmable polarity (opt. interrupt) | ||
76 | - 2 Alarm registers (optional interrupt) | ||
77 | - 3 Periodic signals (optional interrupt) | ||
78 | |||
79 | + National DP83640 | ||
80 | - 6 GPIOs programmable as inputs or outputs | ||
81 | - 6 GPIOs with dedicated functions (LED/JTAG/clock) can also be | ||
82 | used as general inputs or outputs | ||
83 | - GPIO inputs can time stamp external triggers | ||
84 | - GPIO outputs can produce periodic signals | ||
85 | - 1 interrupt pin | ||
86 | |||
87 | + Intel IXP465 | ||
88 | - Auxiliary Slave/Master Mode Snapshot (optional interrupt) | ||
89 | - Target Time (optional interrupt) | ||
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c new file mode 100644 index 000000000000..f59ded066108 --- /dev/null +++ b/Documentation/ptp/testptp.c | |||
@@ -0,0 +1,381 @@ | |||
1 | /* | ||
2 | * PTP 1588 clock support - User space test program | ||
3 | * | ||
4 | * Copyright (C) 2010 OMICRON electronics GmbH | ||
5 | * | ||
6 | * This program is free software; you can redistribute it and/or modify | ||
7 | * it under the terms of the GNU General Public License as published by | ||
8 | * the Free Software Foundation; either version 2 of the License, or | ||
9 | * (at your option) any later version. | ||
10 | * | ||
11 | * This program is distributed in the hope that it will be useful, | ||
12 | * but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
13 | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
14 | * GNU General Public License for more details. | ||
15 | * | ||
16 | * You should have received a copy of the GNU General Public License | ||
17 | * along with this program; if not, write to the Free Software | ||
18 | * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
19 | */ | ||
20 | #include <errno.h> | ||
21 | #include <fcntl.h> | ||
22 | #include <math.h> | ||
23 | #include <signal.h> | ||
24 | #include <stdio.h> | ||
25 | #include <stdlib.h> | ||
26 | #include <string.h> | ||
27 | #include <sys/ioctl.h> | ||
28 | #include <sys/mman.h> | ||
29 | #include <sys/stat.h> | ||
30 | #include <sys/time.h> | ||
31 | #include <sys/timex.h> | ||
32 | #include <sys/types.h> | ||
33 | #include <time.h> | ||
34 | #include <unistd.h> | ||
35 | |||
36 | #include <linux/ptp_clock.h> | ||
37 | |||
38 | #define DEVICE "/dev/ptp0" | ||
39 | |||
40 | #ifndef ADJ_SETOFFSET | ||
41 | #define ADJ_SETOFFSET 0x0100 | ||
42 | #endif | ||
43 | |||
44 | #ifndef CLOCK_INVALID | ||
45 | #define CLOCK_INVALID -1 | ||
46 | #endif | ||
47 | |||
48 | /* When glibc offers the syscall, this will go away. */ | ||
49 | #include <sys/syscall.h> | ||
50 | static int clock_adjtime(clockid_t id, struct timex *tx) | ||
51 | { | ||
52 | return syscall(__NR_clock_adjtime, id, tx); | ||
53 | } | ||
54 | |||
55 | static clockid_t get_clockid(int fd) | ||
56 | { | ||
57 | #define CLOCKFD 3 | ||
58 | #define FD_TO_CLOCKID(fd) ((~(clockid_t) (fd) << 3) | CLOCKFD) | ||
59 | |||
60 | return FD_TO_CLOCKID(fd); | ||
61 | } | ||
62 | |||
63 | static void handle_alarm(int s) | ||
64 | { | ||
65 | printf("received signal %d\n", s); | ||
66 | } | ||
67 | |||
68 | static int install_handler(int signum, void (*handler)(int)) | ||
69 | { | ||
70 | struct sigaction action; | ||
71 | sigset_t mask; | ||
72 | |||
73 | /* Unblock the signal. */ | ||
74 | sigemptyset(&mask); | ||
75 | sigaddset(&mask, signum); | ||
76 | sigprocmask(SIG_UNBLOCK, &mask, NULL); | ||
77 | |||
78 | /* Install the signal handler. */ | ||
79 | action.sa_handler = handler; | ||
80 | action.sa_flags = 0; | ||
81 | sigemptyset(&action.sa_mask); | ||
82 | sigaction(signum, &action, NULL); | ||
83 | |||
84 | return 0; | ||
85 | } | ||
86 | |||
87 | static long ppb_to_scaled_ppm(int ppb) | ||
88 | { | ||
89 | /* | ||
90 | * The 'freq' field in the 'struct timex' is in parts per | ||
91 | * million, but with a 16 bit binary fractional field. | ||
92 | * Instead of calculating either one of | ||
93 | * | ||
94 | * scaled_ppm = (ppb / 1000) << 16 [1] | ||
95 | * scaled_ppm = (ppb << 16) / 1000 [2] | ||
96 | * | ||
97 | * we simply use double precision math, in order to avoid the | ||
98 | * truncation in [1] and the possible overflow in [2]. | ||
99 | */ | ||
100 | return (long) (ppb * 65.536); | ||
101 | } | ||
102 | |||
103 | static void usage(char *progname) | ||
104 | { | ||
105 | fprintf(stderr, | ||
106 | "usage: %s [options]\n" | ||
107 | " -a val request a one-shot alarm after 'val' seconds\n" | ||
108 | " -A val request a periodic alarm every 'val' seconds\n" | ||
109 | " -c query the ptp clock's capabilities\n" | ||
110 | " -d name device to open\n" | ||
111 | " -e val read 'val' external time stamp events\n" | ||
112 | " -f val adjust the ptp clock frequency by 'val' ppb\n" | ||
113 | " -g get the ptp clock time\n" | ||
114 | " -h prints this message\n" | ||
115 | " -p val enable output with a period of 'val' nanoseconds\n" | ||
116 | " -P val enable or disable (val=1|0) the system clock PPS\n" | ||
117 | " -s set the ptp clock time from the system time\n" | ||
118 | " -S set the system time from the ptp clock time\n" | ||
119 | " -t val shift the ptp clock time by 'val' seconds\n", | ||
120 | progname); | ||
121 | } | ||
122 | |||
123 | int main(int argc, char *argv[]) | ||
124 | { | ||
125 | struct ptp_clock_caps caps; | ||
126 | struct ptp_extts_event event; | ||
127 | struct ptp_extts_request extts_request; | ||
128 | struct ptp_perout_request perout_request; | ||
129 | struct timespec ts; | ||
130 | struct timex tx; | ||
131 | |||
132 | static timer_t timerid; | ||
133 | struct itimerspec timeout; | ||
134 | struct sigevent sigevent; | ||
135 | |||
136 | char *progname; | ||
137 | int c, cnt, fd; | ||
138 | |||
139 | char *device = DEVICE; | ||
140 | clockid_t clkid; | ||
141 | int adjfreq = 0x7fffffff; | ||
142 | int adjtime = 0; | ||
143 | int capabilities = 0; | ||
144 | int extts = 0; | ||
145 | int gettime = 0; | ||
146 | int oneshot = 0; | ||
147 | int periodic = 0; | ||
148 | int perout = -1; | ||
149 | int pps = -1; | ||
150 | int settime = 0; | ||
151 | |||
152 | progname = strrchr(argv[0], '/'); | ||
153 | progname = progname ? 1+progname : argv[0]; | ||
154 | while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) { | ||
155 | switch (c) { | ||
156 | case 'a': | ||
157 | oneshot = atoi(optarg); | ||
158 | break; | ||
159 | case 'A': | ||
160 | periodic = atoi(optarg); | ||
161 | break; | ||
162 | case 'c': | ||
163 | capabilities = 1; | ||
164 | break; | ||
165 | case 'd': | ||
166 | device = optarg; | ||
167 | break; | ||
168 | case 'e': | ||
169 | extts = atoi(optarg); | ||
170 | break; | ||
171 | case 'f': | ||
172 | adjfreq = atoi(optarg); | ||
173 | break; | ||
174 | case 'g': | ||
175 | gettime = 1; | ||
176 | break; | ||
177 | case 'p': | ||
178 | perout = atoi(optarg); | ||
179 | break; | ||
180 | case 'P': | ||
181 | pps = atoi(optarg); | ||
182 | break; | ||
183 | case 's': | ||
184 | settime = 1; | ||
185 | break; | ||
186 | case 'S': | ||
187 | settime = 2; | ||
188 | break; | ||
189 | case 't': | ||
190 | adjtime = atoi(optarg); | ||
191 | break; | ||
192 | case 'h': | ||
193 | usage(progname); | ||
194 | return 0; | ||
195 | case '?': | ||
196 | default: | ||
197 | usage(progname); | ||
198 | return -1; | ||
199 | } | ||
200 | } | ||
201 | |||
202 | fd = open(device, O_RDWR); | ||
203 | if (fd < 0) { | ||
204 | fprintf(stderr, "opening %s: %s\n", device, strerror(errno)); | ||
205 | return -1; | ||
206 | } | ||
207 | |||
208 | clkid = get_clockid(fd); | ||
209 | if (CLOCK_INVALID == clkid) { | ||
210 | fprintf(stderr, "failed to read clock id\n"); | ||
211 | return -1; | ||
212 | } | ||
213 | |||
214 | if (capabilities) { | ||
215 | if (ioctl(fd, PTP_CLOCK_GETCAPS, &caps)) { | ||
216 | perror("PTP_CLOCK_GETCAPS"); | ||
217 | } else { | ||
218 | printf("capabilities:\n" | ||
219 | " %d maximum frequency adjustment (ppb)\n" | ||
220 | " %d programmable alarms\n" | ||
221 | " %d external time stamp channels\n" | ||
222 | " %d programmable periodic signals\n" | ||
223 | " %d pulse per second\n", | ||
224 | caps.max_adj, | ||
225 | caps.n_alarm, | ||
226 | caps.n_ext_ts, | ||
227 | caps.n_per_out, | ||
228 | caps.pps); | ||
229 | } | ||
230 | } | ||
231 | |||
232 | if (0x7fffffff != adjfreq) { | ||
233 | memset(&tx, 0, sizeof(tx)); | ||
234 | tx.modes = ADJ_FREQUENCY; | ||
235 | tx.freq = ppb_to_scaled_ppm(adjfreq); | ||
236 | if (clock_adjtime(clkid, &tx)) { | ||
237 | perror("clock_adjtime"); | ||
238 | } else { | ||
239 | puts("frequency adjustment okay"); | ||
240 | } | ||
241 | } | ||
242 | |||
243 | if (adjtime) { | ||
244 | memset(&tx, 0, sizeof(tx)); | ||
245 | tx.modes = ADJ_SETOFFSET; | ||
246 | tx.time.tv_sec = adjtime; | ||
247 | tx.time.tv_usec = 0; | ||
248 | if (clock_adjtime(clkid, &tx) < 0) { | ||
249 | perror("clock_adjtime"); | ||
250 | } else { | ||
251 | puts("time shift okay"); | ||
252 | } | ||
253 | } | ||
254 | |||
255 | if (gettime) { | ||
256 | if (clock_gettime(clkid, &ts)) { | ||
257 | perror("clock_gettime"); | ||
258 | } else { | ||
259 | printf("clock time: %ld.%09ld or %s", | ||
260 | ts.tv_sec, ts.tv_nsec, ctime(&ts.tv_sec)); | ||
261 | } | ||
262 | } | ||
263 | |||
264 | if (settime == 1) { | ||
265 | clock_gettime(CLOCK_REALTIME, &ts); | ||
266 | if (clock_settime(clkid, &ts)) { | ||
267 | perror("clock_settime"); | ||
268 | } else { | ||
269 | puts("set time okay"); | ||
270 | } | ||
271 | } | ||
272 | |||
273 | if (settime == 2) { | ||
274 | clock_gettime(clkid, &ts); | ||
275 | if (clock_settime(CLOCK_REALTIME, &ts)) { | ||
276 | perror("clock_settime"); | ||
277 | } else { | ||
278 | puts("set time okay"); | ||
279 | } | ||
280 | } | ||
281 | |||
282 | if (extts) { | ||
283 | memset(&extts_request, 0, sizeof(extts_request)); | ||
284 | extts_request.index = 0; | ||
285 | extts_request.flags = PTP_ENABLE_FEATURE; | ||
286 | if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) { | ||
287 | perror("PTP_EXTTS_REQUEST"); | ||
288 | extts = 0; | ||
289 | } else { | ||
290 | puts("external time stamp request okay"); | ||
291 | } | ||
292 | for (; extts; extts--) { | ||
293 | cnt = read(fd, &event, sizeof(event)); | ||
294 | if (cnt != sizeof(event)) { | ||
295 | perror("read"); | ||
296 | break; | ||
297 | } | ||
298 | printf("event index %u at %lld.%09u\n", event.index, | ||
299 | event.t.sec, event.t.nsec); | ||
300 | fflush(stdout); | ||
301 | } | ||
302 | /* Disable the feature again. */ | ||
303 | extts_request.flags = 0; | ||
304 | if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) { | ||
305 | perror("PTP_EXTTS_REQUEST"); | ||
306 | } | ||
307 | } | ||
308 | |||
309 | if (oneshot) { | ||
310 | install_handler(SIGALRM, handle_alarm); | ||
311 | /* Create a timer. */ | ||
312 | sigevent.sigev_notify = SIGEV_SIGNAL; | ||
313 | sigevent.sigev_signo = SIGALRM; | ||
314 | if (timer_create(clkid, &sigevent, &timerid)) { | ||
315 | perror("timer_create"); | ||
316 | return -1; | ||
317 | } | ||
318 | /* Start the timer. */ | ||
319 | memset(&timeout, 0, sizeof(timeout)); | ||
320 | timeout.it_value.tv_sec = oneshot; | ||
321 | if (timer_settime(timerid, 0, &timeout, NULL)) { | ||
322 | perror("timer_settime"); | ||
323 | return -1; | ||
324 | } | ||
325 | pause(); | ||
326 | timer_delete(timerid); | ||
327 | } | ||
328 | |||
329 | if (periodic) { | ||
330 | install_handler(SIGALRM, handle_alarm); | ||
331 | /* Create a timer. */ | ||
332 | sigevent.sigev_notify = SIGEV_SIGNAL; | ||
333 | sigevent.sigev_signo = SIGALRM; | ||
334 | if (timer_create(clkid, &sigevent, &timerid)) { | ||
335 | perror("timer_create"); | ||
336 | return -1; | ||
337 | } | ||
338 | /* Start the timer. */ | ||
339 | memset(&timeout, 0, sizeof(timeout)); | ||
340 | timeout.it_interval.tv_sec = periodic; | ||
341 | timeout.it_value.tv_sec = periodic; | ||
342 | if (timer_settime(timerid, 0, &timeout, NULL)) { | ||
343 | perror("timer_settime"); | ||
344 | return -1; | ||
345 | } | ||
346 | while (1) { | ||
347 | pause(); | ||
348 | } | ||
349 | timer_delete(timerid); | ||
350 | } | ||
351 | |||
352 | if (perout >= 0) { | ||
353 | if (clock_gettime(clkid, &ts)) { | ||
354 | perror("clock_gettime"); | ||
355 | return -1; | ||
356 | } | ||
357 | memset(&perout_request, 0, sizeof(perout_request)); | ||
358 | perout_request.index = 0; | ||
359 | perout_request.start.sec = ts.tv_sec + 2; | ||
360 | perout_request.start.nsec = 0; | ||
361 | perout_request.period.sec = 0; | ||
362 | perout_request.period.nsec = perout; | ||
363 | if (ioctl(fd, PTP_PEROUT_REQUEST, &perout_request)) { | ||
364 | perror("PTP_PEROUT_REQUEST"); | ||
365 | } else { | ||
366 | puts("periodic output request okay"); | ||
367 | } | ||
368 | } | ||
369 | |||
370 | if (pps != -1) { | ||
371 | int enable = pps ? 1 : 0; | ||
372 | if (ioctl(fd, PTP_ENABLE_PPS, enable)) { | ||
373 | perror("PTP_ENABLE_PPS"); | ||
374 | } else { | ||
375 | puts("pps for system time request okay"); | ||
376 | } | ||
377 | } | ||
378 | |||
379 | close(fd); | ||
380 | return 0; | ||
381 | } | ||
diff --git a/Documentation/ptp/testptp.mk b/Documentation/ptp/testptp.mk new file mode 100644 index 000000000000..4ef2d9755421 --- /dev/null +++ b/Documentation/ptp/testptp.mk | |||
@@ -0,0 +1,33 @@ | |||
1 | # PTP 1588 clock support - User space test program | ||
2 | # | ||
3 | # Copyright (C) 2010 OMICRON electronics GmbH | ||
4 | # | ||
5 | # This program is free software; you can redistribute it and/or modify | ||
6 | # it under the terms of the GNU General Public License as published by | ||
7 | # the Free Software Foundation; either version 2 of the License, or | ||
8 | # (at your option) any later version. | ||
9 | # | ||
10 | # This program is distributed in the hope that it will be useful, | ||
11 | # but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
12 | # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
13 | # GNU General Public License for more details. | ||
14 | # | ||
15 | # You should have received a copy of the GNU General Public License | ||
16 | # along with this program; if not, write to the Free Software | ||
17 | # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
18 | |||
19 | CC = $(CROSS_COMPILE)gcc | ||
20 | INC = -I$(KBUILD_OUTPUT)/usr/include | ||
21 | CFLAGS = -Wall $(INC) | ||
22 | LDLIBS = -lrt | ||
23 | PROGS = testptp | ||
24 | |||
25 | all: $(PROGS) | ||
26 | |||
27 | testptp: testptp.o | ||
28 | |||
29 | clean: | ||
30 | rm -f testptp.o | ||
31 | |||
32 | distclean: clean | ||
33 | rm -f $(PROGS) | ||
diff --git a/Documentation/scheduler/sched-design-CFS.txt b/Documentation/scheduler/sched-design-CFS.txt index 99961993257a..91ecff07cede 100644 --- a/Documentation/scheduler/sched-design-CFS.txt +++ b/Documentation/scheduler/sched-design-CFS.txt | |||
@@ -223,9 +223,10 @@ When CONFIG_FAIR_GROUP_SCHED is defined, a "cpu.shares" file is created for each | |||
223 | group created using the pseudo filesystem. See example steps below to create | 223 | group created using the pseudo filesystem. See example steps below to create |
224 | task groups and modify their CPU share using the "cgroups" pseudo filesystem. | 224 | task groups and modify their CPU share using the "cgroups" pseudo filesystem. |
225 | 225 | ||
226 | # mkdir /dev/cpuctl | 226 | # mount -t tmpfs cgroup_root /sys/fs/cgroup |
227 | # mount -t cgroup -ocpu none /dev/cpuctl | 227 | # mkdir /sys/fs/cgroup/cpu |
228 | # cd /dev/cpuctl | 228 | # mount -t cgroup -ocpu none /sys/fs/cgroup/cpu |
229 | # cd /sys/fs/cgroup/cpu | ||
229 | 230 | ||
230 | # mkdir multimedia # create "multimedia" group of tasks | 231 | # mkdir multimedia # create "multimedia" group of tasks |
231 | # mkdir browser # create "browser" group of tasks | 232 | # mkdir browser # create "browser" group of tasks |
diff --git a/Documentation/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt index 605b0d40329d..71b54d549987 100644 --- a/Documentation/scheduler/sched-rt-group.txt +++ b/Documentation/scheduler/sched-rt-group.txt | |||
@@ -129,9 +129,8 @@ priority! | |||
129 | Enabling CONFIG_RT_GROUP_SCHED lets you explicitly allocate real | 129 | Enabling CONFIG_RT_GROUP_SCHED lets you explicitly allocate real |
130 | CPU bandwidth to task groups. | 130 | CPU bandwidth to task groups. |
131 | 131 | ||
132 | This uses the /cgroup virtual file system and | 132 | This uses the cgroup virtual file system and "<cgroup>/cpu.rt_runtime_us" |
133 | "/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each | 133 | to control the CPU time reserved for each control group. |
134 | control group. | ||
135 | 134 | ||
136 | For more information on working with control groups, you should read | 135 | For more information on working with control groups, you should read |
137 | Documentation/cgroups/cgroups.txt as well. | 136 | Documentation/cgroups/cgroups.txt as well. |
@@ -150,7 +149,7 @@ For now, this can be simplified to just the following (but see Future plans): | |||
150 | =============== | 149 | =============== |
151 | 150 | ||
152 | There is work in progress to make the scheduling period for each group | 151 | There is work in progress to make the scheduling period for each group |
153 | ("/cgroup/<cgroup>/cpu.rt_period_us") configurable as well. | 152 | ("<cgroup>/cpu.rt_period_us") configurable as well. |
154 | 153 | ||
155 | The constraint on the period is that a subgroup must have a smaller or | 154 | The constraint on the period is that a subgroup must have a smaller or |
156 | equal period to its parent. But realistically its not very useful _yet_ | 155 | equal period to its parent. But realistically its not very useful _yet_ |
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 4d9ce73ff730..9ed1d9d96783 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas | |||
@@ -1,3 +1,17 @@ | |||
1 | Release Date : Wed. May 11, 2011 17:00:00 PST 2010 - | ||
2 | (emaild-id:megaraidlinux@lsi.com) | ||
3 | Adam Radford | ||
4 | Current Version : 00.00.05.38-rc1 | ||
5 | Old Version : 00.00.05.34-rc1 | ||
6 | 1. Remove MSI-X black list, use MFI_REG_STATE.ready.msiEnable. | ||
7 | 2. Remove un-used function megasas_return_cmd_for_smid(). | ||
8 | 3. Check MFI_REG_STATE.fault.resetAdapter in megasas_reset_fusion(). | ||
9 | 4. Disable interrupts/free_irq() in megasas_shutdown(). | ||
10 | 5. Fix bug where AENs could be lost in probe() and resume(). | ||
11 | 6. Convert 6,10,12 byte CDB's to 16 byte CDB for large LBA's for FastPath | ||
12 | IO. | ||
13 | 7. Add 1078 OCR support. | ||
14 | ------------------------------------------------------------------------------- | ||
1 | Release Date : Thu. Feb 24, 2011 17:00:00 PST 2010 - | 15 | Release Date : Thu. Feb 24, 2011 17:00:00 PST 2010 - |
2 | (emaild-id:megaraidlinux@lsi.com) | 16 | (emaild-id:megaraidlinux@lsi.com) |
3 | Adam Radford | 17 | Adam Radford |
diff --git a/Documentation/scsi/LICENSE.qla2xxx b/Documentation/scsi/LICENSE.qla2xxx index 9e15b4f9cd28..19e7cd4bba66 100644 --- a/Documentation/scsi/LICENSE.qla2xxx +++ b/Documentation/scsi/LICENSE.qla2xxx | |||
@@ -1,11 +1,11 @@ | |||
1 | Copyright (c) 2003-2005 QLogic Corporation | 1 | Copyright (c) 2003-2011 QLogic Corporation |
2 | QLogic Linux Fibre Channel HBA Driver | 2 | QLogic Linux/ESX Fibre Channel HBA Driver |
3 | 3 | ||
4 | This program includes a device driver for Linux 2.6 that may be | 4 | This program includes a device driver for Linux 2.6/ESX that may be |
5 | distributed with QLogic hardware specific firmware binary file. | 5 | distributed with QLogic hardware specific firmware binary file. |
6 | You may modify and redistribute the device driver code under the | 6 | You may modify and redistribute the device driver code under the |
7 | GNU General Public License as published by the Free Software | 7 | GNU General Public License (a copy of which is attached hereto as |
8 | Foundation (version 2 or a later version). | 8 | Exhibit A) published by the Free Software Foundation (version 2). |
9 | 9 | ||
10 | You may redistribute the hardware specific firmware binary file | 10 | You may redistribute the hardware specific firmware binary file |
11 | under the following terms: | 11 | under the following terms: |
@@ -43,3 +43,285 @@ OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT, | |||
43 | TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN | 43 | TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN |
44 | ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN | 44 | ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN |
45 | COMBINATION WITH THIS PROGRAM. | 45 | COMBINATION WITH THIS PROGRAM. |
46 | |||
47 | |||
48 | EXHIBIT A | ||
49 | |||
50 | GNU GENERAL PUBLIC LICENSE | ||
51 | Version 2, June 1991 | ||
52 | |||
53 | Copyright (C) 1989, 1991 Free Software Foundation, Inc. | ||
54 | 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA | ||
55 | Everyone is permitted to copy and distribute verbatim copies | ||
56 | of this license document, but changing it is not allowed. | ||
57 | |||
58 | Preamble | ||
59 | |||
60 | The licenses for most software are designed to take away your | ||
61 | freedom to share and change it. By contrast, the GNU General Public | ||
62 | License is intended to guarantee your freedom to share and change free | ||
63 | software--to make sure the software is free for all its users. This | ||
64 | General Public License applies to most of the Free Software | ||
65 | Foundation's software and to any other program whose authors commit to | ||
66 | using it. (Some other Free Software Foundation software is covered by | ||
67 | the GNU Lesser General Public License instead.) You can apply it to | ||
68 | your programs, too. | ||
69 | |||
70 | When we speak of free software, we are referring to freedom, not | ||
71 | price. Our General Public Licenses are designed to make sure that you | ||
72 | have the freedom to distribute copies of free software (and charge for | ||
73 | this service if you wish), that you receive source code or can get it | ||
74 | if you want it, that you can change the software or use pieces of it | ||
75 | in new free programs; and that you know you can do these things. | ||
76 | |||
77 | To protect your rights, we need to make restrictions that forbid | ||
78 | anyone to deny you these rights or to ask you to surrender the rights. | ||
79 | These restrictions translate to certain responsibilities for you if you | ||
80 | distribute copies of the software, or if you modify it. | ||
81 | |||
82 | For example, if you distribute copies of such a program, whether | ||
83 | gratis or for a fee, you must give the recipients all the rights that | ||
84 | you have. You must make sure that they, too, receive or can get the | ||
85 | source code. And you must show them these terms so they know their | ||
86 | rights. | ||
87 | |||
88 | We protect your rights with two steps: (1) copyright the software, and | ||
89 | (2) offer you this license which gives you legal permission to copy, | ||
90 | distribute and/or modify the software. | ||
91 | |||
92 | Also, for each author's protection and ours, we want to make certain | ||
93 | that everyone understands that there is no warranty for this free | ||
94 | software. If the software is modified by someone else and passed on, we | ||
95 | want its recipients to know that what they have is not the original, so | ||
96 | that any problems introduced by others will not reflect on the original | ||
97 | authors' reputations. | ||
98 | |||
99 | Finally, any free program is threatened constantly by software | ||
100 | patents. We wish to avoid the danger that redistributors of a free | ||
101 | program will individually obtain patent licenses, in effect making the | ||
102 | program proprietary. To prevent this, we have made it clear that any | ||
103 | patent must be licensed for everyone's free use or not licensed at all. | ||
104 | |||
105 | The precise terms and conditions for copying, distribution and | ||
106 | modification follow. | ||
107 | |||
108 | GNU GENERAL PUBLIC LICENSE | ||
109 | TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION | ||
110 | |||
111 | 0. This License applies to any program or other work which contains | ||
112 | a notice placed by the copyright holder saying it may be distributed | ||
113 | under the terms of this General Public License. The "Program", below, | ||
114 | refers to any such program or work, and a "work based on the Program" | ||
115 | means either the Program or any derivative work under copyright law: | ||
116 | that is to say, a work containing the Program or a portion of it, | ||
117 | either verbatim or with modifications and/or translated into another | ||
118 | language. (Hereinafter, translation is included without limitation in | ||
119 | the term "modification".) Each licensee is addressed as "you". | ||
120 | |||
121 | Activities other than copying, distribution and modification are not | ||
122 | covered by this License; they are outside its scope. The act of | ||
123 | running the Program is not restricted, and the output from the Program | ||
124 | is covered only if its contents constitute a work based on the | ||
125 | Program (independent of having been made by running the Program). | ||
126 | Whether that is true depends on what the Program does. | ||
127 | |||
128 | 1. You may copy and distribute verbatim copies of the Program's | ||
129 | source code as you receive it, in any medium, provided that you | ||
130 | conspicuously and appropriately publish on each copy an appropriate | ||
131 | copyright notice and disclaimer of warranty; keep intact all the | ||
132 | notices that refer to this License and to the absence of any warranty; | ||
133 | and give any other recipients of the Program a copy of this License | ||
134 | along with the Program. | ||
135 | |||
136 | You may charge a fee for the physical act of transferring a copy, and | ||
137 | you may at your option offer warranty protection in exchange for a fee. | ||
138 | |||
139 | 2. You may modify your copy or copies of the Program or any portion | ||
140 | of it, thus forming a work based on the Program, and copy and | ||
141 | distribute such modifications or work under the terms of Section 1 | ||
142 | above, provided that you also meet all of these conditions: | ||
143 | |||
144 | a) You must cause the modified files to carry prominent notices | ||
145 | stating that you changed the files and the date of any change. | ||
146 | |||
147 | b) You must cause any work that you distribute or publish, that in | ||
148 | whole or in part contains or is derived from the Program or any | ||
149 | part thereof, to be licensed as a whole at no charge to all third | ||
150 | parties under the terms of this License. | ||
151 | |||
152 | c) If the modified program normally reads commands interactively | ||
153 | when run, you must cause it, when started running for such | ||
154 | interactive use in the most ordinary way, to print or display an | ||
155 | announcement including an appropriate copyright notice and a | ||
156 | notice that there is no warranty (or else, saying that you provide | ||
157 | a warranty) and that users may redistribute the program under | ||
158 | these conditions, and telling the user how to view a copy of this | ||
159 | License. (Exception: if the Program itself is interactive but | ||
160 | does not normally print such an announcement, your work based on | ||
161 | the Program is not required to print an announcement.) | ||
162 | |||
163 | These requirements apply to the modified work as a whole. If | ||
164 | identifiable sections of that work are not derived from the Program, | ||
165 | and can be reasonably considered independent and separate works in | ||
166 | themselves, then this License, and its terms, do not apply to those | ||
167 | sections when you distribute them as separate works. But when you | ||
168 | distribute the same sections as part of a whole which is a work based | ||
169 | on the Program, the distribution of the whole must be on the terms of | ||
170 | this License, whose permissions for other licensees extend to the | ||
171 | entire whole, and thus to each and every part regardless of who wrote it. | ||
172 | |||
173 | Thus, it is not the intent of this section to claim rights or contest | ||
174 | your rights to work written entirely by you; rather, the intent is to | ||
175 | exercise the right to control the distribution of derivative or | ||
176 | collective works based on the Program. | ||
177 | |||
178 | In addition, mere aggregation of another work not based on the Program | ||
179 | with the Program (or with a work based on the Program) on a volume of | ||
180 | a storage or distribution medium does not bring the other work under | ||
181 | the scope of this License. | ||
182 | |||
183 | 3. You may copy and distribute the Program (or a work based on it, | ||
184 | under Section 2) in object code or executable form under the terms of | ||
185 | Sections 1 and 2 above provided that you also do one of the following: | ||
186 | |||
187 | a) Accompany it with the complete corresponding machine-readable | ||
188 | source code, which must be distributed under the terms of Sections | ||
189 | 1 and 2 above on a medium customarily used for software interchange; or, | ||
190 | |||
191 | b) Accompany it with a written offer, valid for at least three | ||
192 | years, to give any third party, for a charge no more than your | ||
193 | cost of physically performing source distribution, a complete | ||
194 | machine-readable copy of the corresponding source code, to be | ||
195 | distributed under the terms of Sections 1 and 2 above on a medium | ||
196 | customarily used for software interchange; or, | ||
197 | |||
198 | c) Accompany it with the information you received as to the offer | ||
199 | to distribute corresponding source code. (This alternative is | ||
200 | allowed only for noncommercial distribution and only if you | ||
201 | received the program in object code or executable form with such | ||
202 | an offer, in accord with Subsection b above.) | ||
203 | |||
204 | The source code for a work means the preferred form of the work for | ||
205 | making modifications to it. For an executable work, complete source | ||
206 | code means all the source code for all modules it contains, plus any | ||
207 | associated interface definition files, plus the scripts used to | ||
208 | control compilation and installation of the executable. However, as a | ||
209 | special exception, the source code distributed need not include | ||
210 | anything that is normally distributed (in either source or binary | ||
211 | form) with the major components (compiler, kernel, and so on) of the | ||
212 | operating system on which the executable runs, unless that component | ||
213 | itself accompanies the executable. | ||
214 | |||
215 | If distribution of executable or object code is made by offering | ||
216 | access to copy from a designated place, then offering equivalent | ||
217 | access to copy the source code from the same place counts as | ||
218 | distribution of the source code, even though third parties are not | ||
219 | compelled to copy the source along with the object code. | ||
220 | |||
221 | 4. You may not copy, modify, sublicense, or distribute the Program | ||
222 | except as expressly provided under this License. Any attempt | ||
223 | otherwise to copy, modify, sublicense or distribute the Program is | ||
224 | void, and will automatically terminate your rights under this License. | ||
225 | However, parties who have received copies, or rights, from you under | ||
226 | this License will not have their licenses terminated so long as such | ||
227 | parties remain in full compliance. | ||
228 | |||
229 | 5. You are not required to accept this License, since you have not | ||
230 | signed it. However, nothing else grants you permission to modify or | ||
231 | distribute the Program or its derivative works. These actions are | ||
232 | prohibited by law if you do not accept this License. Therefore, by | ||
233 | modifying or distributing the Program (or any work based on the | ||
234 | Program), you indicate your acceptance of this License to do so, and | ||
235 | all its terms and conditions for copying, distributing or modifying | ||
236 | the Program or works based on it. | ||
237 | |||
238 | 6. Each time you redistribute the Program (or any work based on the | ||
239 | Program), the recipient automatically receives a license from the | ||
240 | original licensor to copy, distribute or modify the Program subject to | ||
241 | these terms and conditions. You may not impose any further | ||
242 | restrictions on the recipients' exercise of the rights granted herein. | ||
243 | You are not responsible for enforcing compliance by third parties to | ||
244 | this License. | ||
245 | |||
246 | 7. If, as a consequence of a court judgment or allegation of patent | ||
247 | infringement or for any other reason (not limited to patent issues), | ||
248 | conditions are imposed on you (whether by court order, agreement or | ||
249 | otherwise) that contradict the conditions of this License, they do not | ||
250 | excuse you from the conditions of this License. If you cannot | ||
251 | distribute so as to satisfy simultaneously your obligations under this | ||
252 | License and any other pertinent obligations, then as a consequence you | ||
253 | may not distribute the Program at all. For example, if a patent | ||
254 | license would not permit royalty-free redistribution of the Program by | ||
255 | all those who receive copies directly or indirectly through you, then | ||
256 | the only way you could satisfy both it and this License would be to | ||
257 | refrain entirely from distribution of the Program. | ||
258 | |||
259 | If any portion of this section is held invalid or unenforceable under | ||
260 | any particular circumstance, the balance of the section is intended to | ||
261 | apply and the section as a whole is intended to apply in other | ||
262 | circumstances. | ||
263 | |||
264 | It is not the purpose of this section to induce you to infringe any | ||
265 | patents or other property right claims or to contest validity of any | ||
266 | such claims; this section has the sole purpose of protecting the | ||
267 | integrity of the free software distribution system, which is | ||
268 | implemented by public license practices. Many people have made | ||
269 | generous contributions to the wide range of software distributed | ||
270 | through that system in reliance on consistent application of that | ||
271 | system; it is up to the author/donor to decide if he or she is willing | ||
272 | to distribute software through any other system and a licensee cannot | ||
273 | impose that choice. | ||
274 | |||
275 | This section is intended to make thoroughly clear what is believed to | ||
276 | be a consequence of the rest of this License. | ||
277 | |||
278 | 8. If the distribution and/or use of the Program is restricted in | ||
279 | certain countries either by patents or by copyrighted interfaces, the | ||
280 | original copyright holder who places the Program under this License | ||
281 | may add an explicit geographical distribution limitation excluding | ||
282 | those countries, so that distribution is permitted only in or among | ||
283 | countries not thus excluded. In such case, this License incorporates | ||
284 | the limitation as if written in the body of this License. | ||
285 | |||
286 | 9. The Free Software Foundation may publish revised and/or new versions | ||
287 | of the General Public License from time to time. Such new versions will | ||
288 | be similar in spirit to the present version, but may differ in detail to | ||
289 | address new problems or concerns. | ||
290 | |||
291 | Each version is given a distinguishing version number. If the Program | ||
292 | specifies a version number of this License which applies to it and "any | ||
293 | later version", you have the option of following the terms and conditions | ||
294 | either of that version or of any later version published by the Free | ||
295 | Software Foundation. If the Program does not specify a version number of | ||
296 | this License, you may choose any version ever published by the Free Software | ||
297 | Foundation. | ||
298 | |||
299 | 10. If you wish to incorporate parts of the Program into other free | ||
300 | programs whose distribution conditions are different, write to the author | ||
301 | to ask for permission. For software which is copyrighted by the Free | ||
302 | Software Foundation, write to the Free Software Foundation; we sometimes | ||
303 | make exceptions for this. Our decision will be guided by the two goals | ||
304 | of preserving the free status of all derivatives of our free software and | ||
305 | of promoting the sharing and reuse of software generally. | ||
306 | |||
307 | NO WARRANTY | ||
308 | |||
309 | 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY | ||
310 | FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN | ||
311 | OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES | ||
312 | PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED | ||
313 | OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF | ||
314 | MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS | ||
315 | TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE | ||
316 | PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, | ||
317 | REPAIR OR CORRECTION. | ||
318 | |||
319 | 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING | ||
320 | WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR | ||
321 | REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, | ||
322 | INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING | ||
323 | OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED | ||
324 | TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY | ||
325 | YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER | ||
326 | PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE | ||
327 | POSSIBILITY OF SUCH DAMAGES. | ||
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX new file mode 100644 index 000000000000..19bc49439cac --- /dev/null +++ b/Documentation/security/00-INDEX | |||
@@ -0,0 +1,18 @@ | |||
1 | 00-INDEX | ||
2 | - this file. | ||
3 | SELinux.txt | ||
4 | - how to get started with the SELinux security enhancement. | ||
5 | Smack.txt | ||
6 | - documentation on the Smack Linux Security Module. | ||
7 | apparmor.txt | ||
8 | - documentation on the AppArmor security extension. | ||
9 | credentials.txt | ||
10 | - documentation about credentials in Linux. | ||
11 | keys-request-key.txt | ||
12 | - description of the kernel key request service. | ||
13 | keys-trusted-encrypted.txt | ||
14 | - info on the Trusted and Encrypted keys in the kernel key ring service. | ||
15 | keys.txt | ||
16 | - description of the kernel key retention service. | ||
17 | tomoyo.txt | ||
18 | - documentation on the TOMOYO Linux Security Module. | ||
diff --git a/Documentation/SELinux.txt b/Documentation/security/SELinux.txt index 07eae00f3314..07eae00f3314 100644 --- a/Documentation/SELinux.txt +++ b/Documentation/security/SELinux.txt | |||
diff --git a/Documentation/Smack.txt b/Documentation/security/Smack.txt index e9dab41c0fe0..e9dab41c0fe0 100644 --- a/Documentation/Smack.txt +++ b/Documentation/security/Smack.txt | |||
diff --git a/Documentation/apparmor.txt b/Documentation/security/apparmor.txt index 93c1fd7d0635..93c1fd7d0635 100644 --- a/Documentation/apparmor.txt +++ b/Documentation/security/apparmor.txt | |||
diff --git a/Documentation/credentials.txt b/Documentation/security/credentials.txt index 995baf379c07..fc0366cbd7ce 100644 --- a/Documentation/credentials.txt +++ b/Documentation/security/credentials.txt | |||
@@ -216,7 +216,7 @@ The Linux kernel supports the following types of credentials: | |||
216 | When a process accesses a key, if not already present, it will normally be | 216 | When a process accesses a key, if not already present, it will normally be |
217 | cached on one of these keyrings for future accesses to find. | 217 | cached on one of these keyrings for future accesses to find. |
218 | 218 | ||
219 | For more information on using keys, see Documentation/keys.txt. | 219 | For more information on using keys, see Documentation/security/keys.txt. |
220 | 220 | ||
221 | (5) LSM | 221 | (5) LSM |
222 | 222 | ||
diff --git a/Documentation/keys-request-key.txt b/Documentation/security/keys-request-key.txt index 69686ad12c66..51987bfecfed 100644 --- a/Documentation/keys-request-key.txt +++ b/Documentation/security/keys-request-key.txt | |||
@@ -3,8 +3,8 @@ | |||
3 | =================== | 3 | =================== |
4 | 4 | ||
5 | The key request service is part of the key retention service (refer to | 5 | The key request service is part of the key retention service (refer to |
6 | Documentation/keys.txt). This document explains more fully how the requesting | 6 | Documentation/security/keys.txt). This document explains more fully how |
7 | algorithm works. | 7 | the requesting algorithm works. |
8 | 8 | ||
9 | The process starts by either the kernel requesting a service by calling | 9 | The process starts by either the kernel requesting a service by calling |
10 | request_key*(): | 10 | request_key*(): |
diff --git a/Documentation/keys-trusted-encrypted.txt b/Documentation/security/keys-trusted-encrypted.txt index 8fb79bc1ac4b..8fb79bc1ac4b 100644 --- a/Documentation/keys-trusted-encrypted.txt +++ b/Documentation/security/keys-trusted-encrypted.txt | |||
diff --git a/Documentation/keys.txt b/Documentation/security/keys.txt index 6523a9e6f293..4d75931d2d79 100644 --- a/Documentation/keys.txt +++ b/Documentation/security/keys.txt | |||
@@ -434,7 +434,7 @@ The main syscalls are: | |||
434 | /sbin/request-key will be invoked in an attempt to obtain a key. The | 434 | /sbin/request-key will be invoked in an attempt to obtain a key. The |
435 | callout_info string will be passed as an argument to the program. | 435 | callout_info string will be passed as an argument to the program. |
436 | 436 | ||
437 | See also Documentation/keys-request-key.txt. | 437 | See also Documentation/security/keys-request-key.txt. |
438 | 438 | ||
439 | 439 | ||
440 | The keyctl syscall functions are: | 440 | The keyctl syscall functions are: |
@@ -864,7 +864,7 @@ payload contents" for more information. | |||
864 | If successful, the key will have been attached to the default keyring for | 864 | If successful, the key will have been attached to the default keyring for |
865 | implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING. | 865 | implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING. |
866 | 866 | ||
867 | See also Documentation/keys-request-key.txt. | 867 | See also Documentation/security/keys-request-key.txt. |
868 | 868 | ||
869 | 869 | ||
870 | (*) To search for a key, passing auxiliary data to the upcaller, call: | 870 | (*) To search for a key, passing auxiliary data to the upcaller, call: |
diff --git a/Documentation/tomoyo.txt b/Documentation/security/tomoyo.txt index 200a2d37cbc8..200a2d37cbc8 100644 --- a/Documentation/tomoyo.txt +++ b/Documentation/security/tomoyo.txt | |||
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 9822afb6313c..89757012c7ff 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt | |||
@@ -1230,6 +1230,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
1230 | This module supports multiple cards. | 1230 | This module supports multiple cards. |
1231 | The driver requires the firmware loader support on kernel. | 1231 | The driver requires the firmware loader support on kernel. |
1232 | 1232 | ||
1233 | Module snd-lola | ||
1234 | --------------- | ||
1235 | |||
1236 | Module for Digigram Lola PCI-e boards | ||
1237 | |||
1238 | This module supports multiple cards. | ||
1239 | |||
1233 | Module snd-lx6464es | 1240 | Module snd-lx6464es |
1234 | ------------------- | 1241 | ------------------- |
1235 | 1242 | ||
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 0caf77e59be4..d70c93bdcadf 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt | |||
@@ -94,7 +94,7 @@ ALC662/663/272 | |||
94 | 3stack-dig 3-stack (2-channel) with SPDIF | 94 | 3stack-dig 3-stack (2-channel) with SPDIF |
95 | 3stack-6ch 3-stack (6-channel) | 95 | 3stack-6ch 3-stack (6-channel) |
96 | 3stack-6ch-dig 3-stack (6-channel) with SPDIF | 96 | 3stack-6ch-dig 3-stack (6-channel) with SPDIF |
97 | 6stack-dig 6-stack with SPDIF | 97 | 5stack-dig 5-stack with SPDIF |
98 | lenovo-101e Lenovo laptop | 98 | lenovo-101e Lenovo laptop |
99 | eeepc-p701 ASUS Eeepc P701 | 99 | eeepc-p701 ASUS Eeepc P701 |
100 | eeepc-ep20 ASUS Eeepc EP20 | 100 | eeepc-ep20 ASUS Eeepc EP20 |
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 2e3c64b1a6a5..9dbe885ecd8d 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt | |||
@@ -13,18 +13,8 @@ static DEFINE_SPINLOCK(xxx_lock); | |||
13 | The above is always safe. It will disable interrupts _locally_, but the | 13 | The above is always safe. It will disable interrupts _locally_, but the |
14 | spinlock itself will guarantee the global lock, so it will guarantee that | 14 | spinlock itself will guarantee the global lock, so it will guarantee that |
15 | there is only one thread-of-control within the region(s) protected by that | 15 | there is only one thread-of-control within the region(s) protected by that |
16 | lock. This works well even under UP. The above sequence under UP | 16 | lock. This works well even under UP also, so the code does _not_ need to |
17 | essentially is just the same as doing | 17 | worry about UP vs SMP issues: the spinlocks work correctly under both. |
18 | |||
19 | unsigned long flags; | ||
20 | |||
21 | save_flags(flags); cli(); | ||
22 | ... critical section ... | ||
23 | restore_flags(flags); | ||
24 | |||
25 | so the code does _not_ need to worry about UP vs SMP issues: the spinlocks | ||
26 | work correctly under both (and spinlocks are actually more efficient on | ||
27 | architectures that allow doing the "save_flags + cli" in one operation). | ||
28 | 18 | ||
29 | NOTE! Implications of spin_locks for memory are further described in: | 19 | NOTE! Implications of spin_locks for memory are further described in: |
30 | 20 | ||
@@ -36,27 +26,7 @@ The above is usually pretty simple (you usually need and want only one | |||
36 | spinlock for most things - using more than one spinlock can make things a | 26 | spinlock for most things - using more than one spinlock can make things a |
37 | lot more complex and even slower and is usually worth it only for | 27 | lot more complex and even slower and is usually worth it only for |
38 | sequences that you _know_ need to be split up: avoid it at all cost if you | 28 | sequences that you _know_ need to be split up: avoid it at all cost if you |
39 | aren't sure). HOWEVER, it _does_ mean that if you have some code that does | 29 | aren't sure). |
40 | |||
41 | cli(); | ||
42 | .. critical section .. | ||
43 | sti(); | ||
44 | |||
45 | and another sequence that does | ||
46 | |||
47 | spin_lock_irqsave(flags); | ||
48 | .. critical section .. | ||
49 | spin_unlock_irqrestore(flags); | ||
50 | |||
51 | then they are NOT mutually exclusive, and the critical regions can happen | ||
52 | at the same time on two different CPU's. That's fine per se, but the | ||
53 | critical regions had better be critical for different things (ie they | ||
54 | can't stomp on each other). | ||
55 | |||
56 | The above is a problem mainly if you end up mixing code - for example the | ||
57 | routines in ll_rw_block() tend to use cli/sti to protect the atomicity of | ||
58 | their actions, and if a driver uses spinlocks instead then you should | ||
59 | think about issues like the above. | ||
60 | 30 | ||
61 | This is really the only really hard part about spinlocks: once you start | 31 | This is really the only really hard part about spinlocks: once you start |
62 | using spinlocks they tend to expand to areas you might not have noticed | 32 | using spinlocks they tend to expand to areas you might not have noticed |
@@ -120,11 +90,10 @@ Lesson 3: spinlocks revisited. | |||
120 | 90 | ||
121 | The single spin-lock primitives above are by no means the only ones. They | 91 | The single spin-lock primitives above are by no means the only ones. They |
122 | are the most safe ones, and the ones that work under all circumstances, | 92 | are the most safe ones, and the ones that work under all circumstances, |
123 | but partly _because_ they are safe they are also fairly slow. They are | 93 | but partly _because_ they are safe they are also fairly slow. They are slower |
124 | much faster than a generic global cli/sti pair, but slower than they'd | 94 | than they'd need to be, because they do have to disable interrupts |
125 | need to be, because they do have to disable interrupts (which is just a | 95 | (which is just a single instruction on a x86, but it's an expensive one - |
126 | single instruction on a x86, but it's an expensive one - and on other | 96 | and on other architectures it can be worse). |
127 | architectures it can be worse). | ||
128 | 97 | ||
129 | If you have a case where you have to protect a data structure across | 98 | If you have a case where you have to protect a data structure across |
130 | several CPU's and you want to use spinlocks you can potentially use | 99 | several CPU's and you want to use spinlocks you can potentially use |
diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt index 847b342b7b20..db3be892afb2 100644 --- a/Documentation/stable_api_nonsense.txt +++ b/Documentation/stable_api_nonsense.txt | |||
@@ -122,7 +122,7 @@ operating system to suffer. | |||
122 | 122 | ||
123 | In both of these instances, all developers agreed that these were | 123 | In both of these instances, all developers agreed that these were |
124 | important changes that needed to be made, and they were made, with | 124 | important changes that needed to be made, and they were made, with |
125 | relatively little pain. If Linux had to ensure that it preserve a | 125 | relatively little pain. If Linux had to ensure that it will preserve a |
126 | stable source interface, a new interface would have been created, and | 126 | stable source interface, a new interface would have been created, and |
127 | the older, broken one would have had to be maintained over time, leading | 127 | the older, broken one would have had to be maintained over time, leading |
128 | to extra work for the USB developers. Since all Linux USB developers do | 128 | to extra work for the USB developers. Since all Linux USB developers do |
diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt index 4af0614147ef..88fd7f5c8dcd 100644 --- a/Documentation/sysctl/fs.txt +++ b/Documentation/sysctl/fs.txt | |||
@@ -231,13 +231,6 @@ its creation). | |||
231 | 231 | ||
232 | This directory contains configuration options for the epoll(7) interface. | 232 | This directory contains configuration options for the epoll(7) interface. |
233 | 233 | ||
234 | max_user_instances | ||
235 | ------------------ | ||
236 | |||
237 | This is the maximum number of epoll file descriptors that a single user can | ||
238 | have open at a given time. The default value is 128, and should be enough | ||
239 | for normal users. | ||
240 | |||
241 | max_user_watches | 234 | max_user_watches |
242 | ---------------- | 235 | ---------------- |
243 | 236 | ||
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 36f007514db3..5e7cb39ad195 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt | |||
@@ -161,7 +161,8 @@ core_pattern is used to specify a core dumpfile pattern name. | |||
161 | %s signal number | 161 | %s signal number |
162 | %t UNIX time of dump | 162 | %t UNIX time of dump |
163 | %h hostname | 163 | %h hostname |
164 | %e executable filename | 164 | %e executable filename (may be shortened) |
165 | %E executable path | ||
165 | %<OTHER> both are dropped | 166 | %<OTHER> both are dropped |
166 | . If the first character of the pattern is a '|', the kernel will treat | 167 | . If the first character of the pattern is a '|', the kernel will treat |
167 | the rest of the pattern as a command to run. The core dump will be | 168 | the rest of the pattern as a command to run. The core dump will be |
diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index cbd05ffc606b..3201a7097e4d 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt | |||
@@ -32,6 +32,17 @@ Table : Subdirectories in /proc/sys/net | |||
32 | 1. /proc/sys/net/core - Network core options | 32 | 1. /proc/sys/net/core - Network core options |
33 | ------------------------------------------------------- | 33 | ------------------------------------------------------- |
34 | 34 | ||
35 | bpf_jit_enable | ||
36 | -------------- | ||
37 | |||
38 | This enables Berkeley Packet Filter Just in Time compiler. | ||
39 | Currently supported on x86_64 architecture, bpf_jit provides a framework | ||
40 | to speed packet filtering, the one used by tcpdump/libpcap for example. | ||
41 | Values : | ||
42 | 0 - disable the JIT (default value) | ||
43 | 1 - enable the JIT | ||
44 | 2 - enable the JIT and ask the compiler to emit traces on kernel log. | ||
45 | |||
35 | rmem_default | 46 | rmem_default |
36 | ------------ | 47 | ------------ |
37 | 48 | ||
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 30289fab86eb..96f0ee825bed 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt | |||
@@ -481,10 +481,10 @@ the DMA zone. | |||
481 | Type(A) is called as "Node" order. Type (B) is "Zone" order. | 481 | Type(A) is called as "Node" order. Type (B) is "Zone" order. |
482 | 482 | ||
483 | "Node order" orders the zonelists by node, then by zone within each node. | 483 | "Node order" orders the zonelists by node, then by zone within each node. |
484 | Specify "[Nn]ode" for zone order | 484 | Specify "[Nn]ode" for node order |
485 | 485 | ||
486 | "Zone Order" orders the zonelists by zone type, then by node within each | 486 | "Zone Order" orders the zonelists by zone type, then by node within each |
487 | zone. Specify "[Zz]one"for zode order. | 487 | zone. Specify "[Zz]one" for zone order. |
488 | 488 | ||
489 | Specify "[Dd]efault" to request automatic configuration. Autoconfiguration | 489 | Specify "[Dd]efault" to request automatic configuration. Autoconfiguration |
490 | will select "node" order in following case. | 490 | will select "node" order in following case. |
diff --git a/Documentation/timers/timers-howto.txt b/Documentation/timers/timers-howto.txt index c9ef29d2ede3..038f8c77a076 100644 --- a/Documentation/timers/timers-howto.txt +++ b/Documentation/timers/timers-howto.txt | |||
@@ -24,7 +24,7 @@ ATOMIC CONTEXT: | |||
24 | 24 | ||
25 | ndelay(unsigned long nsecs) | 25 | ndelay(unsigned long nsecs) |
26 | udelay(unsigned long usecs) | 26 | udelay(unsigned long usecs) |
27 | mdelay(unsgined long msecs) | 27 | mdelay(unsigned long msecs) |
28 | 28 | ||
29 | udelay is the generally preferred API; ndelay-level | 29 | udelay is the generally preferred API; ndelay-level |
30 | precision may not actually exist on many non-PC devices. | 30 | precision may not actually exist on many non-PC devices. |
diff --git a/Documentation/trace/kprobetrace.txt b/Documentation/trace/kprobetrace.txt index 6d27ab8d6e9f..c83bd6b4e6e8 100644 --- a/Documentation/trace/kprobetrace.txt +++ b/Documentation/trace/kprobetrace.txt | |||
@@ -120,7 +120,6 @@ format: | |||
120 | field:unsigned char common_flags; offset:2; size:1; signed:0; | 120 | field:unsigned char common_flags; offset:2; size:1; signed:0; |
121 | field:unsigned char common_preempt_count; offset:3; size:1;signed:0; | 121 | field:unsigned char common_preempt_count; offset:3; size:1;signed:0; |
122 | field:int common_pid; offset:4; size:4; signed:1; | 122 | field:int common_pid; offset:4; size:4; signed:1; |
123 | field:int common_lock_depth; offset:8; size:4; signed:1; | ||
124 | 123 | ||
125 | field:unsigned long __probe_ip; offset:12; size:4; signed:0; | 124 | field:unsigned long __probe_ip; offset:12; size:4; signed:0; |
126 | field:int __probe_nargs; offset:16; size:4; signed:1; | 125 | field:int __probe_nargs; offset:16; size:4; signed:1; |
diff --git a/Documentation/usb/callbacks.txt b/Documentation/usb/callbacks.txt index bfb36b34b79e..9e85846bdb98 100644 --- a/Documentation/usb/callbacks.txt +++ b/Documentation/usb/callbacks.txt | |||
@@ -95,9 +95,11 @@ pre_reset | |||
95 | 95 | ||
96 | int (*pre_reset)(struct usb_interface *intf); | 96 | int (*pre_reset)(struct usb_interface *intf); |
97 | 97 | ||
98 | Another driver or user space is triggering a reset on the device which | 98 | A driver or user space is triggering a reset on the device which |
99 | contains the interface passed as an argument. Cease IO and save any | 99 | contains the interface passed as an argument. Cease IO, wait for all |
100 | device state you need to restore. | 100 | outstanding URBs to complete, and save any device state you need to |
101 | restore. No more URBs may be submitted until the post_reset method | ||
102 | is called. | ||
101 | 103 | ||
102 | If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you | 104 | If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you |
103 | are in atomic context. | 105 | are in atomic context. |
diff --git a/Documentation/usb/error-codes.txt b/Documentation/usb/error-codes.txt index d83703ea74b2..b3f606b81a03 100644 --- a/Documentation/usb/error-codes.txt +++ b/Documentation/usb/error-codes.txt | |||
@@ -76,6 +76,13 @@ A transfer's actual_length may be positive even when an error has been | |||
76 | reported. That's because transfers often involve several packets, so that | 76 | reported. That's because transfers often involve several packets, so that |
77 | one or more packets could finish before an error stops further endpoint I/O. | 77 | one or more packets could finish before an error stops further endpoint I/O. |
78 | 78 | ||
79 | For isochronous URBs, the urb status value is non-zero only if the URB is | ||
80 | unlinked, the device is removed, the host controller is disabled, or the total | ||
81 | transferred length is less than the requested length and the URB_SHORT_NOT_OK | ||
82 | flag is set. Completion handlers for isochronous URBs should only see | ||
83 | urb->status set to zero, -ENOENT, -ECONNRESET, -ESHUTDOWN, or -EREMOTEIO. | ||
84 | Individual frame descriptor status fields may report more status codes. | ||
85 | |||
79 | 86 | ||
80 | 0 Transfer completed successfully | 87 | 0 Transfer completed successfully |
81 | 88 | ||
@@ -132,7 +139,7 @@ one or more packets could finish before an error stops further endpoint I/O. | |||
132 | device removal events immediately. | 139 | device removal events immediately. |
133 | 140 | ||
134 | -EXDEV ISO transfer only partially completed | 141 | -EXDEV ISO transfer only partially completed |
135 | look at individual frame status for details | 142 | (only set in iso_frame_desc[n].status, not urb->status) |
136 | 143 | ||
137 | -EINVAL ISO madness, if this happens: Log off and go home | 144 | -EINVAL ISO madness, if this happens: Log off and go home |
138 | 145 | ||
diff --git a/Documentation/usb/linux-cdc-acm.inf b/Documentation/usb/linux-cdc-acm.inf index 612e7220fb29..37a02ce54841 100644 --- a/Documentation/usb/linux-cdc-acm.inf +++ b/Documentation/usb/linux-cdc-acm.inf | |||
@@ -90,10 +90,10 @@ ServiceBinary=%12%\USBSER.sys | |||
90 | [SourceDisksFiles] | 90 | [SourceDisksFiles] |
91 | [SourceDisksNames] | 91 | [SourceDisksNames] |
92 | [DeviceList] | 92 | [DeviceList] |
93 | %DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_0525&PID_A4AB&MI_02 | 93 | %DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_1D6B&PID_0104&MI_02 |
94 | 94 | ||
95 | [DeviceList.NTamd64] | 95 | [DeviceList.NTamd64] |
96 | %DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_0525&PID_A4AB&MI_02 | 96 | %DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_1D6B&PID_0104&MI_02 |
97 | 97 | ||
98 | 98 | ||
99 | ;------------------------------------------------------------------------------ | 99 | ;------------------------------------------------------------------------------ |
diff --git a/Documentation/usb/linux.inf b/Documentation/usb/linux.inf index 4dee95851224..4ffa715b0ae8 100644 --- a/Documentation/usb/linux.inf +++ b/Documentation/usb/linux.inf | |||
@@ -18,15 +18,15 @@ DriverVer = 06/21/2006,6.0.6000.16384 | |||
18 | 18 | ||
19 | ; Decoration for x86 architecture | 19 | ; Decoration for x86 architecture |
20 | [LinuxDevices.NTx86] | 20 | [LinuxDevices.NTx86] |
21 | %LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_0525&PID_a4ab&MI_00 | 21 | %LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_1d6b&PID_0104&MI_00 |
22 | 22 | ||
23 | ; Decoration for x64 architecture | 23 | ; Decoration for x64 architecture |
24 | [LinuxDevices.NTamd64] | 24 | [LinuxDevices.NTamd64] |
25 | %LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_0525&PID_a4ab&MI_00 | 25 | %LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_1d6b&PID_0104&MI_00 |
26 | 26 | ||
27 | ; Decoration for ia64 architecture | 27 | ; Decoration for ia64 architecture |
28 | [LinuxDevices.NTia64] | 28 | [LinuxDevices.NTia64] |
29 | %LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_0525&PID_a4ab&MI_00 | 29 | %LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_1d6b&PID_0104&MI_00 |
30 | 30 | ||
31 | ;@@@ This is the common setting for setup | 31 | ;@@@ This is the common setting for setup |
32 | [ControlFlags] | 32 | [ControlFlags] |
diff --git a/Documentation/vgaarbiter.txt b/Documentation/vgaarbiter.txt index 43a9b0694fdd..b7d401e0eae9 100644 --- a/Documentation/vgaarbiter.txt +++ b/Documentation/vgaarbiter.txt | |||
@@ -14,11 +14,10 @@ the legacy VGA arbitration task (besides other bus management tasks) when more | |||
14 | than one legacy device co-exists on the same machine. But the problem happens | 14 | than one legacy device co-exists on the same machine. But the problem happens |
15 | when these devices are trying to be accessed by different userspace clients | 15 | when these devices are trying to be accessed by different userspace clients |
16 | (e.g. two server in parallel). Their address assignments conflict. Moreover, | 16 | (e.g. two server in parallel). Their address assignments conflict. Moreover, |
17 | ideally, being an userspace application, it is not the role of the the X | 17 | ideally, being a userspace application, it is not the role of the X server to |
18 | server to control bus resources. Therefore an arbitration scheme outside of | 18 | control bus resources. Therefore an arbitration scheme outside of the X server |
19 | the X server is needed to control the sharing of these resources. This | 19 | is needed to control the sharing of these resources. This document introduces |
20 | document introduces the operation of the VGA arbiter implemented for Linux | 20 | the operation of the VGA arbiter implemented for the Linux kernel. |
21 | kernel. | ||
22 | 21 | ||
23 | ---------------------------------------------------------------------------- | 22 | ---------------------------------------------------------------------------- |
24 | 23 | ||
@@ -39,7 +38,7 @@ I.1 vgaarb | |||
39 | The vgaarb is a module of the Linux Kernel. When it is initially loaded, it | 38 | The vgaarb is a module of the Linux Kernel. When it is initially loaded, it |
40 | scans all PCI devices and adds the VGA ones inside the arbitration. The | 39 | scans all PCI devices and adds the VGA ones inside the arbitration. The |
41 | arbiter then enables/disables the decoding on different devices of the VGA | 40 | arbiter then enables/disables the decoding on different devices of the VGA |
42 | legacy instructions. Device which do not want/need to use the arbiter may | 41 | legacy instructions. Devices which do not want/need to use the arbiter may |
43 | explicitly tell it by calling vga_set_legacy_decoding(). | 42 | explicitly tell it by calling vga_set_legacy_decoding(). |
44 | 43 | ||
45 | The kernel exports a char device interface (/dev/vga_arbiter) to the clients, | 44 | The kernel exports a char device interface (/dev/vga_arbiter) to the clients, |
@@ -95,8 +94,8 @@ In the case of devices hot-{un,}plugged, there is a hook - pci_notify() - to | |||
95 | notify them being added/removed in the system and automatically added/removed | 94 | notify them being added/removed in the system and automatically added/removed |
96 | in the arbiter. | 95 | in the arbiter. |
97 | 96 | ||
98 | There's also a in-kernel API of the arbiter in the case of DRM, vgacon and | 97 | There is also an in-kernel API of the arbiter in case DRM, vgacon, or other |
99 | others which may use the arbiter. | 98 | drivers want to use it. |
100 | 99 | ||
101 | 100 | ||
102 | I.2 libpciaccess | 101 | I.2 libpciaccess |
@@ -117,9 +116,8 @@ Besides it, in pci_system were added: | |||
117 | struct pci_device *vga_default_dev; | 116 | struct pci_device *vga_default_dev; |
118 | 117 | ||
119 | 118 | ||
120 | The vga_count is usually need to keep informed how many cards are being | 119 | The vga_count is used to track how many cards are being arbitrated, so for |
121 | arbitrated, so for instance if there's only one then it can totally escape the | 120 | instance, if there is only one card, then it can completely escape arbitration. |
122 | scheme. | ||
123 | 121 | ||
124 | 122 | ||
125 | These functions below acquire VGA resources for the given card and mark those | 123 | These functions below acquire VGA resources for the given card and mark those |
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index 31b485723bc5..9aae449440dc 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx | |||
@@ -54,7 +54,7 @@ | |||
54 | 53 -> Pinnacle Hybrid Pro (em2881) | 54 | 53 -> Pinnacle Hybrid Pro (em2881) |
55 | 54 -> Kworld VS-DVB-T 323UR (em2882) [eb1a:e323] | 55 | 54 -> Kworld VS-DVB-T 323UR (em2882) [eb1a:e323] |
56 | 55 -> Terratec Cinnergy Hybrid T USB XS (em2882) (em2882) [0ccd:005e,0ccd:0042] | 56 | 55 -> Terratec Cinnergy Hybrid T USB XS (em2882) (em2882) [0ccd:005e,0ccd:0042] |
57 | 56 -> Pinnacle Hybrid Pro (2) (em2882) [2304:0226] | 57 | 56 -> Pinnacle Hybrid Pro (330e) (em2882) [2304:0226] |
58 | 57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316] | 58 | 57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316] |
59 | 58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041] | 59 | 58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041] |
60 | 60 -> Hauppauge WinTV HVR 850 (em2883) [2040:651f] | 60 | 60 -> Hauppauge WinTV HVR 850 (em2883) [2040:651f] |
diff --git a/Documentation/video4linux/Zoran b/Documentation/video4linux/Zoran index c40e3bab08fa..9ed629d4874b 100644 --- a/Documentation/video4linux/Zoran +++ b/Documentation/video4linux/Zoran | |||
@@ -130,7 +130,6 @@ Card number: 4 | |||
130 | 130 | ||
131 | Note: No module for the mse3000 is available yet | 131 | Note: No module for the mse3000 is available yet |
132 | Note: No module for the vpx3224 is available yet | 132 | Note: No module for the vpx3224 is available yet |
133 | Note: use encoder=X or decoder=X for non-default i2c chips | ||
134 | 133 | ||
135 | =========================== | 134 | =========================== |
136 | 135 | ||
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 5c542e60f51d..5bfa9a777d26 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt | |||
@@ -275,6 +275,7 @@ pac7302 093a:2629 Genious iSlim 300 | |||
275 | pac7302 093a:262a Webcam 300k | 275 | pac7302 093a:262a Webcam 300k |
276 | pac7302 093a:262c Philips SPC 230 NC | 276 | pac7302 093a:262c Philips SPC 230 NC |
277 | jeilinj 0979:0280 Sakar 57379 | 277 | jeilinj 0979:0280 Sakar 57379 |
278 | jeilinj 0979:0280 Sportscam DV15 | ||
278 | zc3xx 0ac8:0302 Z-star Vimicro zc0302 | 279 | zc3xx 0ac8:0302 Z-star Vimicro zc0302 |
279 | vc032x 0ac8:0321 Vimicro generic vc0321 | 280 | vc032x 0ac8:0321 Vimicro generic vc0321 |
280 | vc032x 0ac8:0323 Vimicro Vc0323 | 281 | vc032x 0ac8:0323 Vimicro Vc0323 |
diff --git a/Documentation/video4linux/uvcvideo.txt b/Documentation/video4linux/uvcvideo.txt new file mode 100644 index 000000000000..848d620dcc5c --- /dev/null +++ b/Documentation/video4linux/uvcvideo.txt | |||
@@ -0,0 +1,239 @@ | |||
1 | Linux USB Video Class (UVC) driver | ||
2 | ================================== | ||
3 | |||
4 | This file documents some driver-specific aspects of the UVC driver, such as | ||
5 | driver-specific ioctls and implementation notes. | ||
6 | |||
7 | Questions and remarks can be sent to the Linux UVC development mailing list at | ||
8 | linux-uvc-devel@lists.berlios.de. | ||
9 | |||
10 | |||
11 | Extension Unit (XU) support | ||
12 | --------------------------- | ||
13 | |||
14 | 1. Introduction | ||
15 | |||
16 | The UVC specification allows for vendor-specific extensions through extension | ||
17 | units (XUs). The Linux UVC driver supports extension unit controls (XU controls) | ||
18 | through two separate mechanisms: | ||
19 | |||
20 | - through mappings of XU controls to V4L2 controls | ||
21 | - through a driver-specific ioctl interface | ||
22 | |||
23 | The first one allows generic V4L2 applications to use XU controls by mapping | ||
24 | certain XU controls onto V4L2 controls, which then show up during ordinary | ||
25 | control enumeration. | ||
26 | |||
27 | The second mechanism requires uvcvideo-specific knowledge for the application to | ||
28 | access XU controls but exposes the entire UVC XU concept to user space for | ||
29 | maximum flexibility. | ||
30 | |||
31 | Both mechanisms complement each other and are described in more detail below. | ||
32 | |||
33 | |||
34 | 2. Control mappings | ||
35 | |||
36 | The UVC driver provides an API for user space applications to define so-called | ||
37 | control mappings at runtime. These allow for individual XU controls or byte | ||
38 | ranges thereof to be mapped to new V4L2 controls. Such controls appear and | ||
39 | function exactly like normal V4L2 controls (i.e. the stock controls, such as | ||
40 | brightness, contrast, etc.). However, reading or writing of such a V4L2 controls | ||
41 | triggers a read or write of the associated XU control. | ||
42 | |||
43 | The ioctl used to create these control mappings is called UVCIOC_CTRL_MAP. | ||
44 | Previous driver versions (before 0.2.0) required another ioctl to be used | ||
45 | beforehand (UVCIOC_CTRL_ADD) to pass XU control information to the UVC driver. | ||
46 | This is no longer necessary as newer uvcvideo versions query the information | ||
47 | directly from the device. | ||
48 | |||
49 | For details on the UVCIOC_CTRL_MAP ioctl please refer to the section titled | ||
50 | "IOCTL reference" below. | ||
51 | |||
52 | |||
53 | 3. Driver specific XU control interface | ||
54 | |||
55 | For applications that need to access XU controls directly, e.g. for testing | ||
56 | purposes, firmware upload, or accessing binary controls, a second mechanism to | ||
57 | access XU controls is provided in the form of a driver-specific ioctl, namely | ||
58 | UVCIOC_CTRL_QUERY. | ||
59 | |||
60 | A call to this ioctl allows applications to send queries to the UVC driver that | ||
61 | directly map to the low-level UVC control requests. | ||
62 | |||
63 | In order to make such a request the UVC unit ID of the control's extension unit | ||
64 | and the control selector need to be known. This information either needs to be | ||
65 | hardcoded in the application or queried using other ways such as by parsing the | ||
66 | UVC descriptor or, if available, using the media controller API to enumerate a | ||
67 | device's entities. | ||
68 | |||
69 | Unless the control size is already known it is necessary to first make a | ||
70 | UVC_GET_LEN requests in order to be able to allocate a sufficiently large buffer | ||
71 | and set the buffer size to the correct value. Similarly, to find out whether | ||
72 | UVC_GET_CUR or UVC_SET_CUR are valid requests for a given control, a | ||
73 | UVC_GET_INFO request should be made. The bits 0 (GET supported) and 1 (SET | ||
74 | supported) of the resulting byte indicate which requests are valid. | ||
75 | |||
76 | With the addition of the UVCIOC_CTRL_QUERY ioctl the UVCIOC_CTRL_GET and | ||
77 | UVCIOC_CTRL_SET ioctls have become obsolete since their functionality is a | ||
78 | subset of the former ioctl. For the time being they are still supported but | ||
79 | application developers are encouraged to use UVCIOC_CTRL_QUERY instead. | ||
80 | |||
81 | For details on the UVCIOC_CTRL_QUERY ioctl please refer to the section titled | ||
82 | "IOCTL reference" below. | ||
83 | |||
84 | |||
85 | 4. Security | ||
86 | |||
87 | The API doesn't currently provide a fine-grained access control facility. The | ||
88 | UVCIOC_CTRL_ADD and UVCIOC_CTRL_MAP ioctls require super user permissions. | ||
89 | |||
90 | Suggestions on how to improve this are welcome. | ||
91 | |||
92 | |||
93 | 5. Debugging | ||
94 | |||
95 | In order to debug problems related to XU controls or controls in general it is | ||
96 | recommended to enable the UVC_TRACE_CONTROL bit in the module parameter 'trace'. | ||
97 | This causes extra output to be written into the system log. | ||
98 | |||
99 | |||
100 | 6. IOCTL reference | ||
101 | |||
102 | ---- UVCIOC_CTRL_MAP - Map a UVC control to a V4L2 control ---- | ||
103 | |||
104 | Argument: struct uvc_xu_control_mapping | ||
105 | |||
106 | Description: | ||
107 | This ioctl creates a mapping between a UVC control or part of a UVC | ||
108 | control and a V4L2 control. Once mappings are defined, userspace | ||
109 | applications can access vendor-defined UVC control through the V4L2 | ||
110 | control API. | ||
111 | |||
112 | To create a mapping, applications fill the uvc_xu_control_mapping | ||
113 | structure with information about an existing UVC control defined with | ||
114 | UVCIOC_CTRL_ADD and a new V4L2 control. | ||
115 | |||
116 | A UVC control can be mapped to several V4L2 controls. For instance, | ||
117 | a UVC pan/tilt control could be mapped to separate pan and tilt V4L2 | ||
118 | controls. The UVC control is divided into non overlapping fields using | ||
119 | the 'size' and 'offset' fields and are then independantly mapped to | ||
120 | V4L2 control. | ||
121 | |||
122 | For signed integer V4L2 controls the data_type field should be set to | ||
123 | UVC_CTRL_DATA_TYPE_SIGNED. Other values are currently ignored. | ||
124 | |||
125 | Return value: | ||
126 | On success 0 is returned. On error -1 is returned and errno is set | ||
127 | appropriately. | ||
128 | |||
129 | ENOMEM | ||
130 | Not enough memory to perform the operation. | ||
131 | EPERM | ||
132 | Insufficient privileges (super user privileges are required). | ||
133 | EINVAL | ||
134 | No such UVC control. | ||
135 | EOVERFLOW | ||
136 | The requested offset and size would overflow the UVC control. | ||
137 | EEXIST | ||
138 | Mapping already exists. | ||
139 | |||
140 | Data types: | ||
141 | * struct uvc_xu_control_mapping | ||
142 | |||
143 | __u32 id V4L2 control identifier | ||
144 | __u8 name[32] V4L2 control name | ||
145 | __u8 entity[16] UVC extension unit GUID | ||
146 | __u8 selector UVC control selector | ||
147 | __u8 size V4L2 control size (in bits) | ||
148 | __u8 offset V4L2 control offset (in bits) | ||
149 | enum v4l2_ctrl_type | ||
150 | v4l2_type V4L2 control type | ||
151 | enum uvc_control_data_type | ||
152 | data_type UVC control data type | ||
153 | struct uvc_menu_info | ||
154 | *menu_info Array of menu entries (for menu controls only) | ||
155 | __u32 menu_count Number of menu entries (for menu controls only) | ||
156 | |||
157 | * struct uvc_menu_info | ||
158 | |||
159 | __u32 value Menu entry value used by the device | ||
160 | __u8 name[32] Menu entry name | ||
161 | |||
162 | |||
163 | * enum uvc_control_data_type | ||
164 | |||
165 | UVC_CTRL_DATA_TYPE_RAW Raw control (byte array) | ||
166 | UVC_CTRL_DATA_TYPE_SIGNED Signed integer | ||
167 | UVC_CTRL_DATA_TYPE_UNSIGNED Unsigned integer | ||
168 | UVC_CTRL_DATA_TYPE_BOOLEAN Boolean | ||
169 | UVC_CTRL_DATA_TYPE_ENUM Enumeration | ||
170 | UVC_CTRL_DATA_TYPE_BITMASK Bitmask | ||
171 | |||
172 | |||
173 | ---- UVCIOC_CTRL_QUERY - Query a UVC XU control ---- | ||
174 | |||
175 | Argument: struct uvc_xu_control_query | ||
176 | |||
177 | Description: | ||
178 | This ioctl queries a UVC XU control identified by its extension unit ID | ||
179 | and control selector. | ||
180 | |||
181 | There are a number of different queries available that closely | ||
182 | correspond to the low-level control requests described in the UVC | ||
183 | specification. These requests are: | ||
184 | |||
185 | UVC_GET_CUR | ||
186 | Obtain the current value of the control. | ||
187 | UVC_GET_MIN | ||
188 | Obtain the minimum value of the control. | ||
189 | UVC_GET_MAX | ||
190 | Obtain the maximum value of the control. | ||
191 | UVC_GET_DEF | ||
192 | Obtain the default value of the control. | ||
193 | UVC_GET_RES | ||
194 | Query the resolution of the control, i.e. the step size of the | ||
195 | allowed control values. | ||
196 | UVC_GET_LEN | ||
197 | Query the size of the control in bytes. | ||
198 | UVC_GET_INFO | ||
199 | Query the control information bitmap, which indicates whether | ||
200 | get/set requests are supported. | ||
201 | UVC_SET_CUR | ||
202 | Update the value of the control. | ||
203 | |||
204 | Applications must set the 'size' field to the correct length for the | ||
205 | control. Exceptions are the UVC_GET_LEN and UVC_GET_INFO queries, for | ||
206 | which the size must be set to 2 and 1, respectively. The 'data' field | ||
207 | must point to a valid writable buffer big enough to hold the indicated | ||
208 | number of data bytes. | ||
209 | |||
210 | Data is copied directly from the device without any driver-side | ||
211 | processing. Applications are responsible for data buffer formatting, | ||
212 | including little-endian/big-endian conversion. This is particularly | ||
213 | important for the result of the UVC_GET_LEN requests, which is always | ||
214 | returned as a little-endian 16-bit integer by the device. | ||
215 | |||
216 | Return value: | ||
217 | On success 0 is returned. On error -1 is returned and errno is set | ||
218 | appropriately. | ||
219 | |||
220 | ENOENT | ||
221 | The device does not support the given control or the specified | ||
222 | extension unit could not be found. | ||
223 | ENOBUFS | ||
224 | The specified buffer size is incorrect (too big or too small). | ||
225 | EINVAL | ||
226 | An invalid request code was passed. | ||
227 | EBADRQC | ||
228 | The given request is not supported by the given control. | ||
229 | EFAULT | ||
230 | The data pointer references an inaccessible memory area. | ||
231 | |||
232 | Data types: | ||
233 | * struct uvc_xu_control_query | ||
234 | |||
235 | __u8 unit Extension unit ID | ||
236 | __u8 selector Control selector | ||
237 | __u8 query Request code to send to the device | ||
238 | __u16 size Control data size (in bytes) | ||
239 | __u8 *data Control value | ||
diff --git a/Documentation/virtual/00-INDEX b/Documentation/virtual/00-INDEX new file mode 100644 index 000000000000..fe0251c4cfb7 --- /dev/null +++ b/Documentation/virtual/00-INDEX | |||
@@ -0,0 +1,10 @@ | |||
1 | Virtualization support in the Linux kernel. | ||
2 | |||
3 | 00-INDEX | ||
4 | - this file. | ||
5 | kvm/ | ||
6 | - Kernel Virtual Machine. See also http://linux-kvm.org | ||
7 | lguest/ | ||
8 | - Extremely simple hypervisor for experimental/educational use. | ||
9 | uml/ | ||
10 | - User Mode Linux, builds/runs Linux kernel as a userspace program. | ||
diff --git a/Documentation/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 9bef4e4cec50..42542eb802ca 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt | |||
@@ -175,7 +175,10 @@ Parameters: vcpu id (apic id on x86) | |||
175 | Returns: vcpu fd on success, -1 on error | 175 | Returns: vcpu fd on success, -1 on error |
176 | 176 | ||
177 | This API adds a vcpu to a virtual machine. The vcpu id is a small integer | 177 | This API adds a vcpu to a virtual machine. The vcpu id is a small integer |
178 | in the range [0, max_vcpus). | 178 | in the range [0, max_vcpus). You can use KVM_CAP_NR_VCPUS of the |
179 | KVM_CHECK_EXTENSION ioctl() to determine the value for max_vcpus at run-time. | ||
180 | If the KVM_CAP_NR_VCPUS does not exist, you should assume that max_vcpus is 4 | ||
181 | cpus max. | ||
179 | 182 | ||
180 | 4.8 KVM_GET_DIRTY_LOG (vm ioctl) | 183 | 4.8 KVM_GET_DIRTY_LOG (vm ioctl) |
181 | 184 | ||
@@ -261,7 +264,7 @@ See KVM_GET_REGS for the data structure. | |||
261 | 4.13 KVM_GET_SREGS | 264 | 4.13 KVM_GET_SREGS |
262 | 265 | ||
263 | Capability: basic | 266 | Capability: basic |
264 | Architectures: x86 | 267 | Architectures: x86, ppc |
265 | Type: vcpu ioctl | 268 | Type: vcpu ioctl |
266 | Parameters: struct kvm_sregs (out) | 269 | Parameters: struct kvm_sregs (out) |
267 | Returns: 0 on success, -1 on error | 270 | Returns: 0 on success, -1 on error |
@@ -279,6 +282,8 @@ struct kvm_sregs { | |||
279 | __u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64]; | 282 | __u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64]; |
280 | }; | 283 | }; |
281 | 284 | ||
285 | /* ppc -- see arch/powerpc/include/asm/kvm.h */ | ||
286 | |||
282 | interrupt_bitmap is a bitmap of pending external interrupts. At most | 287 | interrupt_bitmap is a bitmap of pending external interrupts. At most |
283 | one bit may be set. This interrupt has been acknowledged by the APIC | 288 | one bit may be set. This interrupt has been acknowledged by the APIC |
284 | but not yet injected into the cpu core. | 289 | but not yet injected into the cpu core. |
@@ -286,7 +291,7 @@ but not yet injected into the cpu core. | |||
286 | 4.14 KVM_SET_SREGS | 291 | 4.14 KVM_SET_SREGS |
287 | 292 | ||
288 | Capability: basic | 293 | Capability: basic |
289 | Architectures: x86 | 294 | Architectures: x86, ppc |
290 | Type: vcpu ioctl | 295 | Type: vcpu ioctl |
291 | Parameters: struct kvm_sregs (in) | 296 | Parameters: struct kvm_sregs (in) |
292 | Returns: 0 on success, -1 on error | 297 | Returns: 0 on success, -1 on error |
@@ -1263,6 +1268,29 @@ struct kvm_assigned_msix_entry { | |||
1263 | __u16 padding[3]; | 1268 | __u16 padding[3]; |
1264 | }; | 1269 | }; |
1265 | 1270 | ||
1271 | 4.54 KVM_SET_TSC_KHZ | ||
1272 | |||
1273 | Capability: KVM_CAP_TSC_CONTROL | ||
1274 | Architectures: x86 | ||
1275 | Type: vcpu ioctl | ||
1276 | Parameters: virtual tsc_khz | ||
1277 | Returns: 0 on success, -1 on error | ||
1278 | |||
1279 | Specifies the tsc frequency for the virtual machine. The unit of the | ||
1280 | frequency is KHz. | ||
1281 | |||
1282 | 4.55 KVM_GET_TSC_KHZ | ||
1283 | |||
1284 | Capability: KVM_CAP_GET_TSC_KHZ | ||
1285 | Architectures: x86 | ||
1286 | Type: vcpu ioctl | ||
1287 | Parameters: none | ||
1288 | Returns: virtual tsc-khz on success, negative value on error | ||
1289 | |||
1290 | Returns the tsc frequency of the guest. The unit of the return value is | ||
1291 | KHz. If the host has unstable tsc this ioctl returns -EIO instead as an | ||
1292 | error. | ||
1293 | |||
1266 | 5. The kvm_run structure | 1294 | 5. The kvm_run structure |
1267 | 1295 | ||
1268 | Application code obtains a pointer to the kvm_run structure by | 1296 | Application code obtains a pointer to the kvm_run structure by |
diff --git a/Documentation/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 882068538c9c..882068538c9c 100644 --- a/Documentation/kvm/cpuid.txt +++ b/Documentation/virtual/kvm/cpuid.txt | |||
diff --git a/Documentation/kvm/locking.txt b/Documentation/virtual/kvm/locking.txt index 3b4cd3bf5631..3b4cd3bf5631 100644 --- a/Documentation/kvm/locking.txt +++ b/Documentation/virtual/kvm/locking.txt | |||
diff --git a/Documentation/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt index f46aa58389ca..f46aa58389ca 100644 --- a/Documentation/kvm/mmu.txt +++ b/Documentation/virtual/kvm/mmu.txt | |||
diff --git a/Documentation/kvm/msr.txt b/Documentation/virtual/kvm/msr.txt index d079aed27e03..d079aed27e03 100644 --- a/Documentation/kvm/msr.txt +++ b/Documentation/virtual/kvm/msr.txt | |||
diff --git a/Documentation/kvm/ppc-pv.txt b/Documentation/virtual/kvm/ppc-pv.txt index 3ab969c59046..3ab969c59046 100644 --- a/Documentation/kvm/ppc-pv.txt +++ b/Documentation/virtual/kvm/ppc-pv.txt | |||
diff --git a/Documentation/kvm/review-checklist.txt b/Documentation/virtual/kvm/review-checklist.txt index 730475ae1b8d..a850986ed684 100644 --- a/Documentation/kvm/review-checklist.txt +++ b/Documentation/virtual/kvm/review-checklist.txt | |||
@@ -7,7 +7,7 @@ Review checklist for kvm patches | |||
7 | 2. Patches should be against kvm.git master branch. | 7 | 2. Patches should be against kvm.git master branch. |
8 | 8 | ||
9 | 3. If the patch introduces or modifies a new userspace API: | 9 | 3. If the patch introduces or modifies a new userspace API: |
10 | - the API must be documented in Documentation/kvm/api.txt | 10 | - the API must be documented in Documentation/virtual/kvm/api.txt |
11 | - the API must be discoverable using KVM_CHECK_EXTENSION | 11 | - the API must be discoverable using KVM_CHECK_EXTENSION |
12 | 12 | ||
13 | 4. New state must include support for save/restore. | 13 | 4. New state must include support for save/restore. |
diff --git a/Documentation/kvm/timekeeping.txt b/Documentation/virtual/kvm/timekeeping.txt index df8946377cb6..df8946377cb6 100644 --- a/Documentation/kvm/timekeeping.txt +++ b/Documentation/virtual/kvm/timekeeping.txt | |||
diff --git a/Documentation/lguest/.gitignore b/Documentation/virtual/lguest/.gitignore index 115587fd5f65..115587fd5f65 100644 --- a/Documentation/lguest/.gitignore +++ b/Documentation/virtual/lguest/.gitignore | |||
diff --git a/Documentation/lguest/Makefile b/Documentation/virtual/lguest/Makefile index bebac6b4f332..0ac34206f7a7 100644 --- a/Documentation/lguest/Makefile +++ b/Documentation/virtual/lguest/Makefile | |||
@@ -1,5 +1,5 @@ | |||
1 | # This creates the demonstration utility "lguest" which runs a Linux guest. | 1 | # This creates the demonstration utility "lguest" which runs a Linux guest. |
2 | # Missing headers? Add "-I../../include -I../../arch/x86/include" | 2 | # Missing headers? Add "-I../../../include -I../../../arch/x86/include" |
3 | CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -U_FORTIFY_SOURCE | 3 | CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -U_FORTIFY_SOURCE |
4 | 4 | ||
5 | all: lguest | 5 | all: lguest |
diff --git a/Documentation/lguest/extract b/Documentation/virtual/lguest/extract index 7730bb6e4b94..7730bb6e4b94 100644 --- a/Documentation/lguest/extract +++ b/Documentation/virtual/lguest/extract | |||
diff --git a/Documentation/lguest/lguest.c b/Documentation/virtual/lguest/lguest.c index d9da7e148538..cd9d6af61d07 100644 --- a/Documentation/lguest/lguest.c +++ b/Documentation/virtual/lguest/lguest.c | |||
@@ -49,7 +49,7 @@ | |||
49 | #include <linux/virtio_rng.h> | 49 | #include <linux/virtio_rng.h> |
50 | #include <linux/virtio_ring.h> | 50 | #include <linux/virtio_ring.h> |
51 | #include <asm/bootparam.h> | 51 | #include <asm/bootparam.h> |
52 | #include "../../include/linux/lguest_launcher.h" | 52 | #include "../../../include/linux/lguest_launcher.h" |
53 | /*L:110 | 53 | /*L:110 |
54 | * We can ignore the 42 include files we need for this program, but I do want | 54 | * We can ignore the 42 include files we need for this program, but I do want |
55 | * to draw attention to the use of kernel-style types. | 55 | * to draw attention to the use of kernel-style types. |
@@ -135,9 +135,6 @@ struct device { | |||
135 | /* Is it operational */ | 135 | /* Is it operational */ |
136 | bool running; | 136 | bool running; |
137 | 137 | ||
138 | /* Does Guest want an intrrupt on empty? */ | ||
139 | bool irq_on_empty; | ||
140 | |||
141 | /* Device-specific data. */ | 138 | /* Device-specific data. */ |
142 | void *priv; | 139 | void *priv; |
143 | }; | 140 | }; |
@@ -637,10 +634,7 @@ static void trigger_irq(struct virtqueue *vq) | |||
637 | 634 | ||
638 | /* If they don't want an interrupt, don't send one... */ | 635 | /* If they don't want an interrupt, don't send one... */ |
639 | if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT) { | 636 | if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT) { |
640 | /* ... unless they've asked us to force one on empty. */ | 637 | return; |
641 | if (!vq->dev->irq_on_empty | ||
642 | || lg_last_avail(vq) != vq->vring.avail->idx) | ||
643 | return; | ||
644 | } | 638 | } |
645 | 639 | ||
646 | /* Send the Guest an interrupt tell them we used something up. */ | 640 | /* Send the Guest an interrupt tell them we used something up. */ |
@@ -1057,15 +1051,6 @@ static void create_thread(struct virtqueue *vq) | |||
1057 | close(vq->eventfd); | 1051 | close(vq->eventfd); |
1058 | } | 1052 | } |
1059 | 1053 | ||
1060 | static bool accepted_feature(struct device *dev, unsigned int bit) | ||
1061 | { | ||
1062 | const u8 *features = get_feature_bits(dev) + dev->feature_len; | ||
1063 | |||
1064 | if (dev->feature_len < bit / CHAR_BIT) | ||
1065 | return false; | ||
1066 | return features[bit / CHAR_BIT] & (1 << (bit % CHAR_BIT)); | ||
1067 | } | ||
1068 | |||
1069 | static void start_device(struct device *dev) | 1054 | static void start_device(struct device *dev) |
1070 | { | 1055 | { |
1071 | unsigned int i; | 1056 | unsigned int i; |
@@ -1079,8 +1064,6 @@ static void start_device(struct device *dev) | |||
1079 | verbose(" %02x", get_feature_bits(dev) | 1064 | verbose(" %02x", get_feature_bits(dev) |
1080 | [dev->feature_len+i]); | 1065 | [dev->feature_len+i]); |
1081 | 1066 | ||
1082 | dev->irq_on_empty = accepted_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY); | ||
1083 | |||
1084 | for (vq = dev->vq; vq; vq = vq->next) { | 1067 | for (vq = dev->vq; vq; vq = vq->next) { |
1085 | if (vq->service) | 1068 | if (vq->service) |
1086 | create_thread(vq); | 1069 | create_thread(vq); |
@@ -1564,7 +1547,6 @@ static void setup_tun_net(char *arg) | |||
1564 | /* Set up the tun device. */ | 1547 | /* Set up the tun device. */ |
1565 | configure_device(ipfd, tapif, ip); | 1548 | configure_device(ipfd, tapif, ip); |
1566 | 1549 | ||
1567 | add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY); | ||
1568 | /* Expect Guest to handle everything except UFO */ | 1550 | /* Expect Guest to handle everything except UFO */ |
1569 | add_feature(dev, VIRTIO_NET_F_CSUM); | 1551 | add_feature(dev, VIRTIO_NET_F_CSUM); |
1570 | add_feature(dev, VIRTIO_NET_F_GUEST_CSUM); | 1552 | add_feature(dev, VIRTIO_NET_F_GUEST_CSUM); |
diff --git a/Documentation/lguest/lguest.txt b/Documentation/virtual/lguest/lguest.txt index dad99978a6a8..bff0c554485d 100644 --- a/Documentation/lguest/lguest.txt +++ b/Documentation/virtual/lguest/lguest.txt | |||
@@ -74,7 +74,8 @@ Running Lguest: | |||
74 | 74 | ||
75 | - Run an lguest as root: | 75 | - Run an lguest as root: |
76 | 76 | ||
77 | Documentation/lguest/lguest 64 vmlinux --tunnet=192.168.19.1 --block=rootfile root=/dev/vda | 77 | Documentation/virtual/lguest/lguest 64 vmlinux --tunnet=192.168.19.1 \ |
78 | --block=rootfile root=/dev/vda | ||
78 | 79 | ||
79 | Explanation: | 80 | Explanation: |
80 | 64: the amount of memory to use, in MB. | 81 | 64: the amount of memory to use, in MB. |
diff --git a/Documentation/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt index 9b7e1904db1c..5d0fc8bfcdb9 100644 --- a/Documentation/uml/UserModeLinux-HOWTO.txt +++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt | |||
@@ -1182,6 +1182,16 @@ | |||
1182 | forge.net/> and explains these in detail, as well as | 1182 | forge.net/> and explains these in detail, as well as |
1183 | some other issues. | 1183 | some other issues. |
1184 | 1184 | ||
1185 | There is also a related point-to-point only "ucast" transport. | ||
1186 | This is useful when your network does not support multicast, and | ||
1187 | all network connections are simple point to point links. | ||
1188 | |||
1189 | The full set of command line options for this transport are | ||
1190 | |||
1191 | |||
1192 | ethn=ucast,ethernet address,remote address,listen port,remote port | ||
1193 | |||
1194 | |||
1185 | 1195 | ||
1186 | 1196 | ||
1187 | 66..66.. TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr | 1197 | 66..66.. TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr |
diff --git a/Documentation/vm/cleancache.txt b/Documentation/vm/cleancache.txt new file mode 100644 index 000000000000..36c367c73084 --- /dev/null +++ b/Documentation/vm/cleancache.txt | |||
@@ -0,0 +1,278 @@ | |||
1 | MOTIVATION | ||
2 | |||
3 | Cleancache is a new optional feature provided by the VFS layer that | ||
4 | potentially dramatically increases page cache effectiveness for | ||
5 | many workloads in many environments at a negligible cost. | ||
6 | |||
7 | Cleancache can be thought of as a page-granularity victim cache for clean | ||
8 | pages that the kernel's pageframe replacement algorithm (PFRA) would like | ||
9 | to keep around, but can't since there isn't enough memory. So when the | ||
10 | PFRA "evicts" a page, it first attempts to use cleancache code to | ||
11 | put the data contained in that page into "transcendent memory", memory | ||
12 | that is not directly accessible or addressable by the kernel and is | ||
13 | of unknown and possibly time-varying size. | ||
14 | |||
15 | Later, when a cleancache-enabled filesystem wishes to access a page | ||
16 | in a file on disk, it first checks cleancache to see if it already | ||
17 | contains it; if it does, the page of data is copied into the kernel | ||
18 | and a disk access is avoided. | ||
19 | |||
20 | Transcendent memory "drivers" for cleancache are currently implemented | ||
21 | in Xen (using hypervisor memory) and zcache (using in-kernel compressed | ||
22 | memory) and other implementations are in development. | ||
23 | |||
24 | FAQs are included below. | ||
25 | |||
26 | IMPLEMENTATION OVERVIEW | ||
27 | |||
28 | A cleancache "backend" that provides transcendent memory registers itself | ||
29 | to the kernel's cleancache "frontend" by calling cleancache_register_ops, | ||
30 | passing a pointer to a cleancache_ops structure with funcs set appropriately. | ||
31 | Note that cleancache_register_ops returns the previous settings so that | ||
32 | chaining can be performed if desired. The functions provided must conform to | ||
33 | certain semantics as follows: | ||
34 | |||
35 | Most important, cleancache is "ephemeral". Pages which are copied into | ||
36 | cleancache have an indefinite lifetime which is completely unknowable | ||
37 | by the kernel and so may or may not still be in cleancache at any later time. | ||
38 | Thus, as its name implies, cleancache is not suitable for dirty pages. | ||
39 | Cleancache has complete discretion over what pages to preserve and what | ||
40 | pages to discard and when. | ||
41 | |||
42 | Mounting a cleancache-enabled filesystem should call "init_fs" to obtain a | ||
43 | pool id which, if positive, must be saved in the filesystem's superblock; | ||
44 | a negative return value indicates failure. A "put_page" will copy a | ||
45 | (presumably about-to-be-evicted) page into cleancache and associate it with | ||
46 | the pool id, a file key, and a page index into the file. (The combination | ||
47 | of a pool id, a file key, and an index is sometimes called a "handle".) | ||
48 | A "get_page" will copy the page, if found, from cleancache into kernel memory. | ||
49 | A "flush_page" will ensure the page no longer is present in cleancache; | ||
50 | a "flush_inode" will flush all pages associated with the specified file; | ||
51 | and, when a filesystem is unmounted, a "flush_fs" will flush all pages in | ||
52 | all files specified by the given pool id and also surrender the pool id. | ||
53 | |||
54 | An "init_shared_fs", like init_fs, obtains a pool id but tells cleancache | ||
55 | to treat the pool as shared using a 128-bit UUID as a key. On systems | ||
56 | that may run multiple kernels (such as hard partitioned or virtualized | ||
57 | systems) that may share a clustered filesystem, and where cleancache | ||
58 | may be shared among those kernels, calls to init_shared_fs that specify the | ||
59 | same UUID will receive the same pool id, thus allowing the pages to | ||
60 | be shared. Note that any security requirements must be imposed outside | ||
61 | of the kernel (e.g. by "tools" that control cleancache). Or a | ||
62 | cleancache implementation can simply disable shared_init by always | ||
63 | returning a negative value. | ||
64 | |||
65 | If a get_page is successful on a non-shared pool, the page is flushed (thus | ||
66 | making cleancache an "exclusive" cache). On a shared pool, the page | ||
67 | is NOT flushed on a successful get_page so that it remains accessible to | ||
68 | other sharers. The kernel is responsible for ensuring coherency between | ||
69 | cleancache (shared or not), the page cache, and the filesystem, using | ||
70 | cleancache flush operations as required. | ||
71 | |||
72 | Note that cleancache must enforce put-put-get coherency and get-get | ||
73 | coherency. For the former, if two puts are made to the same handle but | ||
74 | with different data, say AAA by the first put and BBB by the second, a | ||
75 | subsequent get can never return the stale data (AAA). For get-get coherency, | ||
76 | if a get for a given handle fails, subsequent gets for that handle will | ||
77 | never succeed unless preceded by a successful put with that handle. | ||
78 | |||
79 | Last, cleancache provides no SMP serialization guarantees; if two | ||
80 | different Linux threads are simultaneously putting and flushing a page | ||
81 | with the same handle, the results are indeterminate. Callers must | ||
82 | lock the page to ensure serial behavior. | ||
83 | |||
84 | CLEANCACHE PERFORMANCE METRICS | ||
85 | |||
86 | Cleancache monitoring is done by sysfs files in the | ||
87 | /sys/kernel/mm/cleancache directory. The effectiveness of cleancache | ||
88 | can be measured (across all filesystems) with: | ||
89 | |||
90 | succ_gets - number of gets that were successful | ||
91 | failed_gets - number of gets that failed | ||
92 | puts - number of puts attempted (all "succeed") | ||
93 | flushes - number of flushes attempted | ||
94 | |||
95 | A backend implementatation may provide additional metrics. | ||
96 | |||
97 | FAQ | ||
98 | |||
99 | 1) Where's the value? (Andrew Morton) | ||
100 | |||
101 | Cleancache provides a significant performance benefit to many workloads | ||
102 | in many environments with negligible overhead by improving the | ||
103 | effectiveness of the pagecache. Clean pagecache pages are | ||
104 | saved in transcendent memory (RAM that is otherwise not directly | ||
105 | addressable to the kernel); fetching those pages later avoids "refaults" | ||
106 | and thus disk reads. | ||
107 | |||
108 | Cleancache (and its sister code "frontswap") provide interfaces for | ||
109 | this transcendent memory (aka "tmem"), which conceptually lies between | ||
110 | fast kernel-directly-addressable RAM and slower DMA/asynchronous devices. | ||
111 | Disallowing direct kernel or userland reads/writes to tmem | ||
112 | is ideal when data is transformed to a different form and size (such | ||
113 | as with compression) or secretly moved (as might be useful for write- | ||
114 | balancing for some RAM-like devices). Evicted page-cache pages (and | ||
115 | swap pages) are a great use for this kind of slower-than-RAM-but-much- | ||
116 | faster-than-disk transcendent memory, and the cleancache (and frontswap) | ||
117 | "page-object-oriented" specification provides a nice way to read and | ||
118 | write -- and indirectly "name" -- the pages. | ||
119 | |||
120 | In the virtual case, the whole point of virtualization is to statistically | ||
121 | multiplex physical resources across the varying demands of multiple | ||
122 | virtual machines. This is really hard to do with RAM and efforts to | ||
123 | do it well with no kernel change have essentially failed (except in some | ||
124 | well-publicized special-case workloads). Cleancache -- and frontswap -- | ||
125 | with a fairly small impact on the kernel, provide a huge amount | ||
126 | of flexibility for more dynamic, flexible RAM multiplexing. | ||
127 | Specifically, the Xen Transcendent Memory backend allows otherwise | ||
128 | "fallow" hypervisor-owned RAM to not only be "time-shared" between multiple | ||
129 | virtual machines, but the pages can be compressed and deduplicated to | ||
130 | optimize RAM utilization. And when guest OS's are induced to surrender | ||
131 | underutilized RAM (e.g. with "self-ballooning"), page cache pages | ||
132 | are the first to go, and cleancache allows those pages to be | ||
133 | saved and reclaimed if overall host system memory conditions allow. | ||
134 | |||
135 | And the identical interface used for cleancache can be used in | ||
136 | physical systems as well. The zcache driver acts as a memory-hungry | ||
137 | device that stores pages of data in a compressed state. And | ||
138 | the proposed "RAMster" driver shares RAM across multiple physical | ||
139 | systems. | ||
140 | |||
141 | 2) Why does cleancache have its sticky fingers so deep inside the | ||
142 | filesystems and VFS? (Andrew Morton and Christoph Hellwig) | ||
143 | |||
144 | The core hooks for cleancache in VFS are in most cases a single line | ||
145 | and the minimum set are placed precisely where needed to maintain | ||
146 | coherency (via cleancache_flush operations) between cleancache, | ||
147 | the page cache, and disk. All hooks compile into nothingness if | ||
148 | cleancache is config'ed off and turn into a function-pointer- | ||
149 | compare-to-NULL if config'ed on but no backend claims the ops | ||
150 | functions, or to a compare-struct-element-to-negative if a | ||
151 | backend claims the ops functions but a filesystem doesn't enable | ||
152 | cleancache. | ||
153 | |||
154 | Some filesystems are built entirely on top of VFS and the hooks | ||
155 | in VFS are sufficient, so don't require an "init_fs" hook; the | ||
156 | initial implementation of cleancache didn't provide this hook. | ||
157 | But for some filesystems (such as btrfs), the VFS hooks are | ||
158 | incomplete and one or more hooks in fs-specific code are required. | ||
159 | And for some other filesystems, such as tmpfs, cleancache may | ||
160 | be counterproductive. So it seemed prudent to require a filesystem | ||
161 | to "opt in" to use cleancache, which requires adding a hook in | ||
162 | each filesystem. Not all filesystems are supported by cleancache | ||
163 | only because they haven't been tested. The existing set should | ||
164 | be sufficient to validate the concept, the opt-in approach means | ||
165 | that untested filesystems are not affected, and the hooks in the | ||
166 | existing filesystems should make it very easy to add more | ||
167 | filesystems in the future. | ||
168 | |||
169 | The total impact of the hooks to existing fs and mm files is only | ||
170 | about 40 lines added (not counting comments and blank lines). | ||
171 | |||
172 | 3) Why not make cleancache asynchronous and batched so it can | ||
173 | more easily interface with real devices with DMA instead | ||
174 | of copying each individual page? (Minchan Kim) | ||
175 | |||
176 | The one-page-at-a-time copy semantics simplifies the implementation | ||
177 | on both the frontend and backend and also allows the backend to | ||
178 | do fancy things on-the-fly like page compression and | ||
179 | page deduplication. And since the data is "gone" (copied into/out | ||
180 | of the pageframe) before the cleancache get/put call returns, | ||
181 | a great deal of race conditions and potential coherency issues | ||
182 | are avoided. While the interface seems odd for a "real device" | ||
183 | or for real kernel-addressable RAM, it makes perfect sense for | ||
184 | transcendent memory. | ||
185 | |||
186 | 4) Why is non-shared cleancache "exclusive"? And where is the | ||
187 | page "flushed" after a "get"? (Minchan Kim) | ||
188 | |||
189 | The main reason is to free up space in transcendent memory and | ||
190 | to avoid unnecessary cleancache_flush calls. If you want inclusive, | ||
191 | the page can be "put" immediately following the "get". If | ||
192 | put-after-get for inclusive becomes common, the interface could | ||
193 | be easily extended to add a "get_no_flush" call. | ||
194 | |||
195 | The flush is done by the cleancache backend implementation. | ||
196 | |||
197 | 5) What's the performance impact? | ||
198 | |||
199 | Performance analysis has been presented at OLS'09 and LCA'10. | ||
200 | Briefly, performance gains can be significant on most workloads, | ||
201 | especially when memory pressure is high (e.g. when RAM is | ||
202 | overcommitted in a virtual workload); and because the hooks are | ||
203 | invoked primarily in place of or in addition to a disk read/write, | ||
204 | overhead is negligible even in worst case workloads. Basically | ||
205 | cleancache replaces I/O with memory-copy-CPU-overhead; on older | ||
206 | single-core systems with slow memory-copy speeds, cleancache | ||
207 | has little value, but in newer multicore machines, especially | ||
208 | consolidated/virtualized machines, it has great value. | ||
209 | |||
210 | 6) How do I add cleancache support for filesystem X? (Boaz Harrash) | ||
211 | |||
212 | Filesystems that are well-behaved and conform to certain | ||
213 | restrictions can utilize cleancache simply by making a call to | ||
214 | cleancache_init_fs at mount time. Unusual, misbehaving, or | ||
215 | poorly layered filesystems must either add additional hooks | ||
216 | and/or undergo extensive additional testing... or should just | ||
217 | not enable the optional cleancache. | ||
218 | |||
219 | Some points for a filesystem to consider: | ||
220 | |||
221 | - The FS should be block-device-based (e.g. a ram-based FS such | ||
222 | as tmpfs should not enable cleancache) | ||
223 | - To ensure coherency/correctness, the FS must ensure that all | ||
224 | file removal or truncation operations either go through VFS or | ||
225 | add hooks to do the equivalent cleancache "flush" operations | ||
226 | - To ensure coherency/correctness, either inode numbers must | ||
227 | be unique across the lifetime of the on-disk file OR the | ||
228 | FS must provide an "encode_fh" function. | ||
229 | - The FS must call the VFS superblock alloc and deactivate routines | ||
230 | or add hooks to do the equivalent cleancache calls done there. | ||
231 | - To maximize performance, all pages fetched from the FS should | ||
232 | go through the do_mpag_readpage routine or the FS should add | ||
233 | hooks to do the equivalent (cf. btrfs) | ||
234 | - Currently, the FS blocksize must be the same as PAGESIZE. This | ||
235 | is not an architectural restriction, but no backends currently | ||
236 | support anything different. | ||
237 | - A clustered FS should invoke the "shared_init_fs" cleancache | ||
238 | hook to get best performance for some backends. | ||
239 | |||
240 | 7) Why not use the KVA of the inode as the key? (Christoph Hellwig) | ||
241 | |||
242 | If cleancache would use the inode virtual address instead of | ||
243 | inode/filehandle, the pool id could be eliminated. But, this | ||
244 | won't work because cleancache retains pagecache data pages | ||
245 | persistently even when the inode has been pruned from the | ||
246 | inode unused list, and only flushes the data page if the file | ||
247 | gets removed/truncated. So if cleancache used the inode kva, | ||
248 | there would be potential coherency issues if/when the inode | ||
249 | kva is reused for a different file. Alternately, if cleancache | ||
250 | flushed the pages when the inode kva was freed, much of the value | ||
251 | of cleancache would be lost because the cache of pages in cleanache | ||
252 | is potentially much larger than the kernel pagecache and is most | ||
253 | useful if the pages survive inode cache removal. | ||
254 | |||
255 | 8) Why is a global variable required? | ||
256 | |||
257 | The cleancache_enabled flag is checked in all of the frequently-used | ||
258 | cleancache hooks. The alternative is a function call to check a static | ||
259 | variable. Since cleancache is enabled dynamically at runtime, systems | ||
260 | that don't enable cleancache would suffer thousands (possibly | ||
261 | tens-of-thousands) of unnecessary function calls per second. So the | ||
262 | global variable allows cleancache to be enabled by default at compile | ||
263 | time, but have insignificant performance impact when cleancache remains | ||
264 | disabled at runtime. | ||
265 | |||
266 | 9) Does cleanache work with KVM? | ||
267 | |||
268 | The memory model of KVM is sufficiently different that a cleancache | ||
269 | backend may have less value for KVM. This remains to be tested, | ||
270 | especially in an overcommitted system. | ||
271 | |||
272 | 10) Does cleancache work in userspace? It sounds useful for | ||
273 | memory hungry caches like web browsers. (Jamie Lokier) | ||
274 | |||
275 | No plans yet, though we agree it sounds useful, at least for | ||
276 | apps that bypass the page cache (e.g. O_DIRECT). | ||
277 | |||
278 | Last updated: Dan Magenheimer, April 13 2011 | ||
diff --git a/Documentation/vm/hwpoison.txt b/Documentation/vm/hwpoison.txt index 12f9ba20ccb7..550068466605 100644 --- a/Documentation/vm/hwpoison.txt +++ b/Documentation/vm/hwpoison.txt | |||
@@ -129,12 +129,12 @@ Limit injection to pages owned by memgroup. Specified by inode number | |||
129 | of the memcg. | 129 | of the memcg. |
130 | 130 | ||
131 | Example: | 131 | Example: |
132 | mkdir /cgroup/hwpoison | 132 | mkdir /sys/fs/cgroup/mem/hwpoison |
133 | 133 | ||
134 | usemem -m 100 -s 1000 & | 134 | usemem -m 100 -s 1000 & |
135 | echo `jobs -p` > /cgroup/hwpoison/tasks | 135 | echo `jobs -p` > /sys/fs/cgroup/mem/hwpoison/tasks |
136 | 136 | ||
137 | memcg_ino=$(ls -id /cgroup/hwpoison | cut -f1 -d' ') | 137 | memcg_ino=$(ls -id /sys/fs/cgroup/mem/hwpoison | cut -f1 -d' ') |
138 | echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg | 138 | echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg |
139 | 139 | ||
140 | page-types -p `pidof init` --hwpoison # shall do nothing | 140 | page-types -p `pidof init` --hwpoison # shall do nothing |
diff --git a/Documentation/vm/locking b/Documentation/vm/locking index 25fadb448760..f61228bd6395 100644 --- a/Documentation/vm/locking +++ b/Documentation/vm/locking | |||
@@ -66,7 +66,7 @@ in some cases it is not really needed. Eg, vm_start is modified by | |||
66 | expand_stack(), it is hard to come up with a destructive scenario without | 66 | expand_stack(), it is hard to come up with a destructive scenario without |
67 | having the vmlist protection in this case. | 67 | having the vmlist protection in this case. |
68 | 68 | ||
69 | The page_table_lock nests with the inode i_mmap_lock and the kmem cache | 69 | The page_table_lock nests with the inode i_mmap_mutex and the kmem cache |
70 | c_spinlock spinlocks. This is okay, since the kmem code asks for pages after | 70 | c_spinlock spinlocks. This is okay, since the kmem code asks for pages after |
71 | dropping c_spinlock. The page_table_lock also nests with pagecache_lock and | 71 | dropping c_spinlock. The page_table_lock also nests with pagecache_lock and |
72 | pagemap_lru_lock spinlocks, and no code asks for memory with these locks | 72 | pagemap_lru_lock spinlocks, and no code asks for memory with these locks |
diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt index 092e596a1301..c54b4f503e2a 100644 --- a/Documentation/x86/x86_64/boot-options.txt +++ b/Documentation/x86/x86_64/boot-options.txt | |||
@@ -206,7 +206,7 @@ IOMMU (input/output memory management unit) | |||
206 | (e.g. because you have < 3 GB memory). | 206 | (e.g. because you have < 3 GB memory). |
207 | Kernel boot message: "PCI-DMA: Disabling IOMMU" | 207 | Kernel boot message: "PCI-DMA: Disabling IOMMU" |
208 | 208 | ||
209 | 2. <arch/x86_64/kernel/pci-gart.c>: AMD GART based hardware IOMMU. | 209 | 2. <arch/x86/kernel/amd_gart_64.c>: AMD GART based hardware IOMMU. |
210 | Kernel boot message: "PCI-DMA: using GART IOMMU" | 210 | Kernel boot message: "PCI-DMA: using GART IOMMU" |
211 | 211 | ||
212 | 3. <arch/x86_64/kernel/pci-swiotlb.c> : Software IOMMU implementation. Used | 212 | 3. <arch/x86_64/kernel/pci-swiotlb.c> : Software IOMMU implementation. Used |
diff --git a/Documentation/zh_CN/email-clients.txt b/Documentation/zh_CN/email-clients.txt new file mode 100644 index 000000000000..5d65e323d060 --- /dev/null +++ b/Documentation/zh_CN/email-clients.txt | |||
@@ -0,0 +1,210 @@ | |||
1 | 锘?Chinese translated version of Documentation/email-clients.txt | ||
2 | |||
3 | If you have any comment or update to the content, please contact the | ||
4 | original document maintainer directly. However, if you have a problem | ||
5 | communicating in English you can also ask the Chinese maintainer for | ||
6 | help. Contact the Chinese maintainer if this translation is outdated | ||
7 | or if there is a problem with the translation. | ||
8 | |||
9 | Chinese maintainer: Harry Wei <harryxiyou@gmail.com> | ||
10 | --------------------------------------------------------------------- | ||
11 | Documentation/email-clients.txt ???涓????缈昏?? | ||
12 | |||
13 | 濡??????宠??璁烘????存?版???????????瀹癸??璇风?存?ヨ??绯诲?????妗g??缁存?よ?????濡????浣?浣跨?ㄨ?辨?? | ||
14 | 浜ゆ???????伴?剧??璇?锛?涔????浠ュ??涓???????缁存?よ??姹???┿??濡???????缈昏????存?颁???????舵?????缈? | ||
15 | 璇?瀛???ㄩ??棰?锛?璇疯??绯讳腑??????缁存?よ????? | ||
16 | |||
17 | 涓???????缁存?よ??锛? 璐惧??濞? Harry Wei <harryxiyou@gmail.com> | ||
18 | 涓???????缈昏?????锛? 璐惧??濞? Harry Wei <harryxiyou@gmail.com> | ||
19 | 涓?????????¤?????锛? Yinglin Luan <synmyth@gmail.com> | ||
20 | Xiaochen Wang <wangxiaochen0@gmail.com> | ||
21 | yaxinsn <yaxinsn@163.com> | ||
22 | |||
23 | 浠ヤ??涓烘?f?? | ||
24 | --------------------------------------------------------------------- | ||
25 | |||
26 | Linux???浠跺?㈡?风?????缃?淇℃?? | ||
27 | ====================================================================== | ||
28 | |||
29 | ?????????缃? | ||
30 | ---------------------------------------------------------------------- | ||
31 | Linux?????歌ˉ涓???????杩????浠惰?????浜ょ??锛????濂芥??琛ヤ??浣?涓洪??浠朵????????宓?????????????浜?缁存?よ?? | ||
32 | ??ユ?堕??浠讹??浣???????浠剁?????瀹规?煎??搴?璇ユ??"text/plain"?????惰??锛????浠朵????????涓?璧???????锛? | ||
33 | ???涓鸿??浼?浣胯ˉ涓????寮???ㄩ?ㄥ????ㄨ??璁鸿??绋?涓???????寰???伴?俱?? | ||
34 | |||
35 | ??ㄦ?ュ?????Linux?????歌ˉ涓???????浠跺?㈡?风????ㄥ?????琛ヤ????跺??璇ュ??浜?????????????濮???舵?????渚?濡?锛? | ||
36 | 浠?浠?涓???芥?瑰?????????????ゅ?惰〃绗???????绌烘?硷???????虫????ㄦ??涓?琛????寮?澶存?????缁?灏俱?? | ||
37 | |||
38 | 涓?瑕????杩?"format=flowed"妯″????????琛ヤ?????杩???蜂??寮?璧蜂?????棰????浠ュ?????瀹崇?????琛???? | ||
39 | |||
40 | 涓?瑕?璁╀????????浠跺?㈡?风??杩?琛??????ㄦ?㈣?????杩???蜂??浼???村??浣????琛ヤ????? | ||
41 | |||
42 | ???浠跺?㈡?风??涓???芥?瑰???????????瀛?绗????缂??????瑰?????瑕??????????琛ヤ???????芥??ASCII??????UTF-8缂??????瑰??锛? | ||
43 | 濡????浣?浣跨??UTF-8缂??????瑰???????????浠讹????d??浣?灏?浼???垮??涓?浜??????藉????????瀛?绗???????棰???? | ||
44 | |||
45 | ???浠跺?㈡?风??搴?璇ュ舰???骞朵??淇???? References: ?????? In-Reply-To: ???棰?锛???d?? | ||
46 | ???浠惰??棰?灏变??浼?涓??????? | ||
47 | |||
48 | 澶???剁??甯?(?????????璐寸??甯?)???甯镐????界?ㄤ??琛ヤ??锛????涓哄?惰〃绗?浼?杞????涓虹┖??笺??浣跨??xclipboard, xclip | ||
49 | ??????xcutsel涔?璁稿??浠ワ??浣???????濂芥??璇?涓?涓?????????垮??浣跨?ㄥ????剁??甯???? | ||
50 | |||
51 | 涓?瑕???ㄤ娇???PGP/GPG缃插????????浠朵腑??????琛ヤ?????杩???蜂??浣垮??寰?澶???????涓???借?诲??????????ㄤ??浣????琛ヤ????? | ||
52 | 锛?杩?涓????棰?搴?璇ユ?????浠ヤ慨澶????锛? | ||
53 | |||
54 | ??ㄧ???????搁??浠跺??琛ㄥ?????琛ヤ??涔????锛?缁????宸卞?????涓?涓?琛ヤ?????涓?涓???????涓绘??锛?淇?瀛???ユ?跺?扮?? | ||
55 | ???浠讹??灏?琛ヤ?????'patch'??戒护???涓?锛?濡??????????浜?锛????缁??????搁??浠跺??琛ㄥ???????? | ||
56 | |||
57 | |||
58 | 涓?浜????浠跺?㈡?风?????绀? | ||
59 | ---------------------------------------------------------------------- | ||
60 | 杩????缁???轰??浜?璇?缁????MUA???缃????绀猴?????浠ョ?ㄤ??缁?Linux?????稿?????琛ヤ?????杩?浜?骞朵???????虫?? | ||
61 | ?????????杞?浠跺?????缃???荤????? | ||
62 | |||
63 | 璇存??锛? | ||
64 | TUI = 浠ユ?????涓哄?虹???????ㄦ?锋?ュ?? | ||
65 | GUI = ??惧舰?????㈢?ㄦ?锋?ュ?? | ||
66 | |||
67 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
68 | Alpine (TUI) | ||
69 | |||
70 | ???缃????椤癸?? | ||
71 | ???"Sending Preferences"??ㄥ??锛? | ||
72 | |||
73 | - "Do Not Send Flowed Text"蹇?椤诲????? | ||
74 | - "Strip Whitespace Before Sending"蹇?椤诲?抽?? | ||
75 | |||
76 | 褰???????浠舵?讹????????搴?璇ユ?惧?ㄨˉ涓?浼???虹?扮????版?癸????跺?????涓?CTRL-R缁???????锛?浣挎??瀹???? | ||
77 | 琛ヤ?????浠跺????ュ?伴??浠朵腑??? | ||
78 | |||
79 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
80 | Evolution (GUI) | ||
81 | |||
82 | 涓?浜?寮????????????????浣跨?ㄥ????????琛ヤ?? | ||
83 | |||
84 | 褰??????╅??浠堕??椤癸??Preformat | ||
85 | 浠?Format->Heading->Preformatted (Ctrl-7)??????宸ュ?锋?? | ||
86 | |||
87 | ??跺??浣跨??锛? | ||
88 | Insert->Text File... (Alt-n x)?????ヨˉ涓????浠躲?? | ||
89 | |||
90 | 浣?杩????浠?"diff -Nru old.c new.c | xclip"锛???????Preformat锛???跺??浣跨?ㄤ腑??撮??杩?琛?绮?甯???? | ||
91 | |||
92 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
93 | Kmail (GUI) | ||
94 | |||
95 | 涓?浜?寮????????????????浣跨?ㄥ????????琛ヤ????? | ||
96 | |||
97 | 榛?璁よ?剧疆涓?涓?HTML??煎??????????????锛?涓?瑕??????ㄥ????? | ||
98 | |||
99 | 褰?涔????涓?灏????浠剁????跺??锛???ㄩ??椤逛?????涓?瑕??????╄????ㄦ?㈣????????涓????缂虹?瑰氨???浣???ㄩ??浠朵腑杈???ョ??浠讳???????? | ||
100 | ??戒??浼?琚??????ㄦ?㈣??锛????姝や??蹇?椤诲?ㄥ?????琛ヤ??涔?????????ㄦ?㈣????????绠?????????规??灏辨???????ㄨ????ㄦ?㈣????ヤ功??????浠讹?? | ||
101 | ??跺?????瀹?淇?瀛?涓鸿??绋裤??涓????浣???ㄨ??绋夸腑???娆℃??寮?瀹?锛?瀹?宸茬????ㄩ?ㄨ????ㄦ?㈣??浜?锛???d??浣???????浠惰?界?舵病??? | ||
102 | ?????╄????ㄦ?㈣??锛?浣????杩?涓?浼?澶卞?诲凡???????????ㄦ?㈣????? | ||
103 | |||
104 | ??ㄩ??浠剁??搴????锛??????ヨˉ涓?涔????锛???句??甯哥?ㄧ??琛ヤ??瀹????绗?锛?涓?涓?杩?瀛????(---)??? | ||
105 | |||
106 | ??跺?????"Message"????????$??锛??????╂????ユ??浠讹????ョ????????浣????琛ヤ?????浠躲??杩????涓?涓?棰?澶???????椤癸??浣????浠? | ||
107 | ???杩?瀹????缃?浣???????浠跺缓绔?宸ュ?锋????????锛?杩????浠ュ甫涓?"insert file"??炬????? | ||
108 | |||
109 | 浣????浠ュ????ㄥ?伴??杩?GPG???璁伴??浠讹??浣???????宓?琛ヤ?????濂戒??瑕?浣跨??GPG???璁板??浠????浣?涓哄??宓??????????绛惧??琛ヤ??锛? | ||
110 | 褰?浠?GPG涓???????7浣?缂??????朵??浣夸??浠?????????村??澶??????? | ||
111 | |||
112 | 濡????浣????瑕?浠ラ??浠剁??褰㈠????????琛ヤ??锛???d??灏卞?抽????瑰?婚??浠讹????跺?????涓?灞???э??绐????"Suggest automatic | ||
113 | display"锛?杩???峰??宓????浠舵?村?规??璁╄?昏???????般?? | ||
114 | |||
115 | 褰?浣?瑕?淇?瀛?灏?瑕?????????????宓???????琛ヤ??锛?浣????浠ヤ??娑???????琛ㄧ????奸????╁?????琛ヤ????????浠讹????跺????冲?婚????? | ||
116 | "save as"???浣????浠ヤ娇??ㄤ??涓?娌℃????存?圭????????琛ヤ????????浠讹??濡????瀹????浠ユ?g‘???褰㈠??缁???????褰?浣?姝g????ㄥ?? | ||
117 | ???宸辩??绐???d??涓?瀵????锛???f?舵病??????椤瑰??浠ヤ??瀛????浠?--宸茬?????涓?涓?杩???风??bug琚?姹???ュ?颁??kmail???bugzilla | ||
118 | 骞朵??甯????杩?灏?浼?琚?澶??????????浠舵??浠ュ?????瀵规??涓???ㄦ?峰??璇诲???????????琚?淇?瀛????锛????浠ュ?????浣???虫?????浠跺????跺?板?朵????版?癸?? | ||
119 | 浣?涓?寰?涓????浠?浠????????????逛负缁?????????翠?????璇汇?? | ||
120 | |||
121 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
122 | Lotus Notes (GUI) | ||
123 | |||
124 | 涓?瑕?浣跨?ㄥ????? | ||
125 | |||
126 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
127 | Mutt (TUI) | ||
128 | |||
129 | 寰?澶?Linux寮????浜哄??浣跨??mutt瀹㈡?风??锛????浠ヨ?????瀹????瀹?宸ヤ????????甯告??浜???? | ||
130 | |||
131 | Mutt涓????甯?缂?杈????锛????浠ヤ??绠′??浣跨?ㄤ??涔?缂?杈???ㄩ?戒??搴?璇ュ甫????????ㄦ??琛????澶у????扮??杈???ㄩ?藉甫??? | ||
132 | 涓?涓?"insert file"???椤癸??瀹????浠ラ??杩?涓???瑰?????浠跺??瀹圭????瑰???????ユ??浠躲?? | ||
133 | |||
134 | 'vim'浣?涓?mutt???缂?杈????锛? | ||
135 | set editor="vi" | ||
136 | |||
137 | 濡????浣跨??xclip锛???插?ヤ互涓???戒护 | ||
138 | :set paste | ||
139 | ???涓????涔??????????shift-insert??????浣跨?? | ||
140 | :r filename | ||
141 | |||
142 | 濡??????宠?????琛ヤ??浣?涓哄??宓?????????? | ||
143 | (a)ttach宸ヤ?????寰?濂斤??涓?甯????"set paste"??? | ||
144 | |||
145 | ???缃????椤癸?? | ||
146 | 瀹?搴?璇ヤ互榛?璁よ?剧疆???褰㈠??宸ヤ????? | ||
147 | ??惰??锛????"send_charset"璁剧疆涓?"us-ascii::utf-8"涔????涓?涓?涓???????涓绘????? | ||
148 | |||
149 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
150 | Pine (TUI) | ||
151 | |||
152 | Pine杩???绘??涓?浜?绌烘?煎????????棰?锛?浣????杩?浜???板?ㄥ??璇ラ?借??淇?澶?浜???? | ||
153 | |||
154 | 濡???????浠ワ??璇蜂娇???alpine(pine???缁ф?胯??) | ||
155 | |||
156 | ???缃????椤癸?? | ||
157 | - ???杩?????????????瑕?娑???ゆ??绋??????? | ||
158 | - "no-strip-whitespace-before-send"???椤逛????????瑕??????? | ||
159 | |||
160 | |||
161 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
162 | Sylpheed (GUI) | ||
163 | |||
164 | - ???宓??????????浠ュ??濂界??宸ヤ??锛???????浣跨?ㄩ??浠讹????? | ||
165 | - ???璁镐娇??ㄥ????ㄧ??缂?杈???ㄣ?? | ||
166 | - 瀵逛?????褰?杈?澶???堕??甯告????? | ||
167 | - 濡???????杩?non-SSL杩???ワ?????娉?浣跨??TLS SMTP????????? | ||
168 | - ??ㄧ?????绐???d腑???涓?涓?寰??????ㄧ??ruler bar??? | ||
169 | - 缁???板?????涓?娣诲????板??灏变??浼?姝g‘???浜?瑙f?剧ず?????? | ||
170 | |||
171 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
172 | Thunderbird (GUI) | ||
173 | |||
174 | 榛?璁ゆ????典??锛?thunderbird寰?瀹规??????????????锛?浣????杩????涓?浜???规?????浠ュ己??跺?????寰???村ソ??? | ||
175 | |||
176 | - ??ㄧ?ㄦ?峰????疯?剧疆???锛?缁???????瀵诲??锛?涓?瑕???????"Compose messages in HTML format"??? | ||
177 | |||
178 | - 缂?杈?浣????Thunderbird???缃?璁剧疆??ヤ娇瀹?涓?瑕????琛?浣跨??锛?user_pref("mailnews.wraplength", 0); | ||
179 | |||
180 | - 缂?杈?浣????Thunderbird???缃?璁剧疆锛?浣垮??涓?瑕?浣跨??"format=flowed"??煎??锛?user_pref("mailnews. | ||
181 | send_plaintext_flowed", false); | ||
182 | |||
183 | - 浣????瑕?浣?Thunderbird???涓洪???????煎????瑰??锛? | ||
184 | 濡????榛?璁ゆ????典??浣?涔??????????HTML??煎??锛???d?????寰???俱??浠?浠?浠????棰???????涓????妗?涓???????"Preformat"??煎????? | ||
185 | 濡????榛?璁ゆ????典??浣?涔??????????????????煎??锛?浣?涓?寰????瀹???逛负HTML??煎??锛?浠?浠?浣?涓轰??娆℃?х??锛???ヤ功?????扮??娑????锛? | ||
186 | ??跺??寮哄?朵娇瀹??????版???????煎??锛???????瀹?灏变?????琛????瑕?瀹???板??锛???ㄥ??淇$????炬??涓?浣跨??shift?????ヤ娇瀹????涓?HTML | ||
187 | ??煎??锛???跺?????棰???????涓????妗?涓???????"Preformat"??煎????? | ||
188 | |||
189 | - ???璁镐娇??ㄥ????ㄧ??缂?杈????锛? | ||
190 | ???瀵?Thunderbird???琛ヤ?????绠?????????规??灏辨??浣跨?ㄤ??涓?"external editor"??╁??锛???跺??浣跨?ㄤ????????娆㈢?? | ||
191 | $EDITOR??ヨ?诲???????????骞惰ˉ涓???版?????涓????瑕?瀹???板??锛????浠ヤ??杞藉苟涓?瀹?瑁?杩?涓???╁??锛???跺??娣诲??涓?涓?浣跨?ㄥ????? | ||
192 | ??????View->Toolbars->Customize...??????褰?浣?涔????淇℃???????跺??浠?浠???瑰?诲??灏卞??浠ヤ????? | ||
193 | |||
194 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
195 | TkRat (GUI) | ||
196 | |||
197 | ???浠ヤ娇??ㄥ?????浣跨??"Insert file..."??????澶???ㄧ??缂?杈???ㄣ?? | ||
198 | |||
199 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
200 | Gmail (Web GUI) | ||
201 | |||
202 | 涓?瑕?浣跨?ㄥ????????琛ヤ????? | ||
203 | |||
204 | Gmail缃?椤靛?㈡?风???????ㄥ?版????惰〃绗?杞????涓虹┖??笺?? | ||
205 | |||
206 | ??界?跺?惰〃绗?杞????涓虹┖??奸??棰????浠ヨ??澶???ㄧ??杈???ㄨВ??筹???????跺??杩?浼?浣跨?ㄥ??杞???㈣?????姣?琛???????涓?78涓?瀛?绗???? | ||
207 | |||
208 | ???涓?涓????棰????Gmail杩?浼????浠讳??涓????ASCII???瀛?绗????淇℃????逛负base64缂???????瀹????涓?瑗垮????????娆ф床浜虹?????瀛???? | ||
209 | |||
210 | ### | ||