diff options
Diffstat (limited to 'Documentation')
240 files changed, 5344 insertions, 1561 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 0c4cc688e89a..38f8444bdd0e 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -40,7 +40,7 @@ IPMI.txt | |||
40 | IRQ-affinity.txt | 40 | IRQ-affinity.txt |
41 | - how to select which CPU(s) handle which interrupt events on SMP. | 41 | - how to select which CPU(s) handle which interrupt events on SMP. |
42 | IRQ-domain.txt | 42 | IRQ-domain.txt |
43 | - info on inerrupt numbering and setting up IRQ domains. | 43 | - info on interrupt numbering and setting up IRQ domains. |
44 | IRQ.txt | 44 | IRQ.txt |
45 | - description of what an IRQ is. | 45 | - description of what an IRQ is. |
46 | Intel-IOMMU.txt | 46 | Intel-IOMMU.txt |
diff --git a/Documentation/ABI/stable/sysfs-bus-usb b/Documentation/ABI/stable/sysfs-bus-usb new file mode 100644 index 000000000000..2be603c52a24 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-bus-usb | |||
@@ -0,0 +1,142 @@ | |||
1 | What: /sys/bus/usb/devices/.../power/persist | ||
2 | Date: May 2007 | ||
3 | KernelVersion: 2.6.23 | ||
4 | Contact: Alan Stern <stern@rowland.harvard.edu> | ||
5 | Description: | ||
6 | If CONFIG_USB_PERSIST is set, then each USB device directory | ||
7 | will contain a file named power/persist. The file holds a | ||
8 | boolean value (0 or 1) indicating whether or not the | ||
9 | "USB-Persist" facility is enabled for the device. Since the | ||
10 | facility is inherently dangerous, it is disabled by default | ||
11 | for all devices except hubs. For more information, see | ||
12 | Documentation/usb/persist.txt. | ||
13 | |||
14 | What: /sys/bus/usb/devices/.../power/autosuspend | ||
15 | Date: March 2007 | ||
16 | KernelVersion: 2.6.21 | ||
17 | Contact: Alan Stern <stern@rowland.harvard.edu> | ||
18 | Description: | ||
19 | Each USB device directory will contain a file named | ||
20 | power/autosuspend. This file holds the time (in seconds) | ||
21 | the device must be idle before it will be autosuspended. | ||
22 | 0 means the device will be autosuspended as soon as | ||
23 | possible. Negative values will prevent the device from | ||
24 | being autosuspended at all, and writing a negative value | ||
25 | will resume the device if it is already suspended. | ||
26 | |||
27 | The autosuspend delay for newly-created devices is set to | ||
28 | the value of the usbcore.autosuspend module parameter. | ||
29 | |||
30 | What: /sys/bus/usb/device/.../power/connected_duration | ||
31 | Date: January 2008 | ||
32 | KernelVersion: 2.6.25 | ||
33 | Contact: Sarah Sharp <sarah.a.sharp@intel.com> | ||
34 | Description: | ||
35 | If CONFIG_PM_RUNTIME is enabled then this file | ||
36 | is present. When read, it returns the total time (in msec) | ||
37 | that the USB device has been connected to the machine. This | ||
38 | file is read-only. | ||
39 | Users: | ||
40 | PowerTOP <power@bughost.org> | ||
41 | http://www.lesswatts.org/projects/powertop/ | ||
42 | |||
43 | What: /sys/bus/usb/device/.../power/active_duration | ||
44 | Date: January 2008 | ||
45 | KernelVersion: 2.6.25 | ||
46 | Contact: Sarah Sharp <sarah.a.sharp@intel.com> | ||
47 | Description: | ||
48 | If CONFIG_PM_RUNTIME is enabled then this file | ||
49 | is present. When read, it returns the total time (in msec) | ||
50 | that the USB device has been active, i.e. not in a suspended | ||
51 | state. This file is read-only. | ||
52 | |||
53 | Tools can use this file and the connected_duration file to | ||
54 | compute the percentage of time that a device has been active. | ||
55 | For example, | ||
56 | echo $((100 * `cat active_duration` / `cat connected_duration`)) | ||
57 | will give an integer percentage. Note that this does not | ||
58 | account for counter wrap. | ||
59 | Users: | ||
60 | PowerTOP <power@bughost.org> | ||
61 | http://www.lesswatts.org/projects/powertop/ | ||
62 | |||
63 | What: /sys/bus/usb/devices/<busnum>-<port[.port]>...:<config num>-<interface num>/supports_autosuspend | ||
64 | Date: January 2008 | ||
65 | KernelVersion: 2.6.27 | ||
66 | Contact: Sarah Sharp <sarah.a.sharp@intel.com> | ||
67 | Description: | ||
68 | When read, this file returns 1 if the interface driver | ||
69 | for this interface supports autosuspend. It also | ||
70 | returns 1 if no driver has claimed this interface, as an | ||
71 | unclaimed interface will not stop the device from being | ||
72 | autosuspended if all other interface drivers are idle. | ||
73 | The file returns 0 if autosuspend support has not been | ||
74 | added to the driver. | ||
75 | Users: | ||
76 | USB PM tool | ||
77 | git://git.moblin.org/users/sarah/usb-pm-tool/ | ||
78 | |||
79 | What: /sys/bus/usb/device/.../avoid_reset_quirk | ||
80 | Date: December 2009 | ||
81 | Contact: Oliver Neukum <oliver@neukum.org> | ||
82 | Description: | ||
83 | Writing 1 to this file tells the kernel that this | ||
84 | device will morph into another mode when it is reset. | ||
85 | Drivers will not use reset for error handling for | ||
86 | such devices. | ||
87 | Users: | ||
88 | usb_modeswitch | ||
89 | |||
90 | What: /sys/bus/usb/devices/.../devnum | ||
91 | KernelVersion: since at least 2.6.18 | ||
92 | Description: | ||
93 | Device address on the USB bus. | ||
94 | Users: | ||
95 | libusb | ||
96 | |||
97 | What: /sys/bus/usb/devices/.../bConfigurationValue | ||
98 | KernelVersion: since at least 2.6.18 | ||
99 | Description: | ||
100 | bConfigurationValue of the *active* configuration for the | ||
101 | device. Writing 0 or -1 to bConfigurationValue will reset the | ||
102 | active configuration (unconfigure the device). Writing | ||
103 | another value will change the active configuration. | ||
104 | |||
105 | Note that some devices, in violation of the USB spec, have a | ||
106 | configuration with a value equal to 0. Writing 0 to | ||
107 | bConfigurationValue for these devices will install that | ||
108 | configuration, rather then unconfigure the device. | ||
109 | |||
110 | Writing -1 will always unconfigure the device. | ||
111 | Users: | ||
112 | libusb | ||
113 | |||
114 | What: /sys/bus/usb/devices/.../busnum | ||
115 | KernelVersion: 2.6.22 | ||
116 | Description: | ||
117 | Bus-number of the USB-bus the device is connected to. | ||
118 | Users: | ||
119 | libusb | ||
120 | |||
121 | What: /sys/bus/usb/devices/.../descriptors | ||
122 | KernelVersion: 2.6.26 | ||
123 | Description: | ||
124 | Binary file containing cached descriptors of the device. The | ||
125 | binary data consists of the device descriptor followed by the | ||
126 | descriptors for each configuration of the device. | ||
127 | Note that the wTotalLength of the config descriptors can not | ||
128 | be trusted, as the device may have a smaller config descriptor | ||
129 | than it advertises. The bLength field of each (sub) descriptor | ||
130 | can be trusted, and can be used to seek forward one (sub) | ||
131 | descriptor at a time until the next config descriptor is found. | ||
132 | All descriptors read from this file are in bus-endian format | ||
133 | Users: | ||
134 | libusb | ||
135 | |||
136 | What: /sys/bus/usb/devices/.../speed | ||
137 | KernelVersion: since at least 2.6.18 | ||
138 | Description: | ||
139 | Speed the device is connected with to the usb-host in | ||
140 | Mbit / second. IE one of 1.5 / 12 / 480 / 5000. | ||
141 | Users: | ||
142 | libusb | ||
diff --git a/Documentation/ABI/testing/sysfs-block-zram b/Documentation/ABI/testing/sysfs-block-zram index ec93fe33baa6..3f0b9ae61d8c 100644 --- a/Documentation/ABI/testing/sysfs-block-zram +++ b/Documentation/ABI/testing/sysfs-block-zram | |||
@@ -5,20 +5,21 @@ Description: | |||
5 | The disksize file is read-write and specifies the disk size | 5 | The disksize file is read-write and specifies the disk size |
6 | which represents the limit on the *uncompressed* worth of data | 6 | which represents the limit on the *uncompressed* worth of data |
7 | that can be stored in this disk. | 7 | that can be stored in this disk. |
8 | Unit: bytes | ||
8 | 9 | ||
9 | What: /sys/block/zram<id>/initstate | 10 | What: /sys/block/zram<id>/initstate |
10 | Date: August 2010 | 11 | Date: August 2010 |
11 | Contact: Nitin Gupta <ngupta@vflare.org> | 12 | Contact: Nitin Gupta <ngupta@vflare.org> |
12 | Description: | 13 | Description: |
13 | The disksize file is read-only and shows the initialization | 14 | The initstate file is read-only and shows the initialization |
14 | state of the device. | 15 | state of the device. |
15 | 16 | ||
16 | What: /sys/block/zram<id>/reset | 17 | What: /sys/block/zram<id>/reset |
17 | Date: August 2010 | 18 | Date: August 2010 |
18 | Contact: Nitin Gupta <ngupta@vflare.org> | 19 | Contact: Nitin Gupta <ngupta@vflare.org> |
19 | Description: | 20 | Description: |
20 | The disksize file is write-only and allows resetting the | 21 | The reset file is write-only and allows resetting the |
21 | device. The reset operation frees all the memory assocaited | 22 | device. The reset operation frees all the memory associated |
22 | with this device. | 23 | with this device. |
23 | 24 | ||
24 | What: /sys/block/zram<id>/num_reads | 25 | What: /sys/block/zram<id>/num_reads |
@@ -48,7 +49,7 @@ Contact: Nitin Gupta <ngupta@vflare.org> | |||
48 | Description: | 49 | Description: |
49 | The notify_free file is read-only and specifies the number of | 50 | The notify_free file is read-only and specifies the number of |
50 | swap slot free notifications received by this device. These | 51 | swap slot free notifications received by this device. These |
51 | notifications are send to a swap block device when a swap slot | 52 | notifications are sent to a swap block device when a swap slot |
52 | is freed. This statistic is applicable only when this disk is | 53 | is freed. This statistic is applicable only when this disk is |
53 | being used as a swap disk. | 54 | being used as a swap disk. |
54 | 55 | ||
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index dda81ffae5cf..39c8de0e53d0 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio | |||
@@ -351,6 +351,7 @@ Description: | |||
351 | 6kohm_to_gnd: connected to ground via a 6kOhm resistor, | 351 | 6kohm_to_gnd: connected to ground via a 6kOhm resistor, |
352 | 20kohm_to_gnd: connected to ground via a 20kOhm resistor, | 352 | 20kohm_to_gnd: connected to ground via a 20kOhm resistor, |
353 | 100kohm_to_gnd: connected to ground via an 100kOhm resistor, | 353 | 100kohm_to_gnd: connected to ground via an 100kOhm resistor, |
354 | 500kohm_to_gnd: connected to ground via a 500kOhm resistor, | ||
354 | three_state: left floating. | 355 | three_state: left floating. |
355 | For a list of available output power down options read | 356 | For a list of available output power down options read |
356 | outX_powerdown_mode_available. If Y is not present the | 357 | outX_powerdown_mode_available. If Y is not present the |
@@ -792,3 +793,21 @@ Contact: linux-iio@vger.kernel.org | |||
792 | Description: | 793 | Description: |
793 | This attribute is used to read the amount of quadrature error | 794 | This attribute is used to read the amount of quadrature error |
794 | present in the device at a given time. | 795 | present in the device at a given time. |
796 | |||
797 | What: /sys/.../iio:deviceX/in_accelX_power_mode | ||
798 | KernelVersion: 3.11 | ||
799 | Contact: linux-iio@vger.kernel.org | ||
800 | Description: | ||
801 | Specifies the chip power mode. | ||
802 | low_noise: reduce noise level from ADC, | ||
803 | low_power: enable low current consumption. | ||
804 | For a list of available output power modes read | ||
805 | in_accel_power_mode_available. | ||
806 | |||
807 | What: /sys/bus/iio/devices/iio:deviceX/store_eeprom | ||
808 | KernelVersion: 3.4.0 | ||
809 | Contact: linux-iio@vger.kernel.org | ||
810 | Description: | ||
811 | Writing '1' stores the current device configuration into | ||
812 | on-chip EEPROM. After power-up or chip reset the device will | ||
813 | automatically load the saved configuration. | ||
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523 index 2ce9c3f68eee..a91aeabe7b24 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523 +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523 | |||
@@ -18,14 +18,6 @@ Description: | |||
18 | Reading returns either '1' or '0'. '1' means that the | 18 | Reading returns either '1' or '0'. '1' means that the |
19 | pllY is locked. | 19 | pllY is locked. |
20 | 20 | ||
21 | What: /sys/bus/iio/devices/iio:deviceX/store_eeprom | ||
22 | KernelVersion: 3.4.0 | ||
23 | Contact: linux-iio@vger.kernel.org | ||
24 | Description: | ||
25 | Writing '1' stores the current device configuration into | ||
26 | on-chip EEPROM. After power-up or chip reset the device will | ||
27 | automatically load the saved configuration. | ||
28 | |||
29 | What: /sys/bus/iio/devices/iio:deviceX/sync_dividers | 21 | What: /sys/bus/iio/devices/iio:deviceX/sync_dividers |
30 | KernelVersion: 3.4.0 | 22 | KernelVersion: 3.4.0 |
31 | Contact: linux-iio@vger.kernel.org | 23 | Contact: linux-iio@vger.kernel.org |
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 index d89aded01c5a..1254457a726e 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 | |||
@@ -18,4 +18,4 @@ Description: | |||
18 | adjust the reference frequency accordingly. | 18 | adjust the reference frequency accordingly. |
19 | The value written has no effect until out_altvoltageY_frequency | 19 | The value written has no effect until out_altvoltageY_frequency |
20 | is updated. Consider to use out_altvoltageY_powerdown to power | 20 | is updated. Consider to use out_altvoltageY_powerdown to power |
21 | down the PLL and it's RFOut buffers during REFin changes. | 21 | down the PLL and its RFOut buffers during REFin changes. |
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 9759b8c91332..1430f584b266 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb | |||
@@ -1,81 +1,3 @@ | |||
1 | What: /sys/bus/usb/devices/.../power/autosuspend | ||
2 | Date: March 2007 | ||
3 | KernelVersion: 2.6.21 | ||
4 | Contact: Alan Stern <stern@rowland.harvard.edu> | ||
5 | Description: | ||
6 | Each USB device directory will contain a file named | ||
7 | power/autosuspend. This file holds the time (in seconds) | ||
8 | the device must be idle before it will be autosuspended. | ||
9 | 0 means the device will be autosuspended as soon as | ||
10 | possible. Negative values will prevent the device from | ||
11 | being autosuspended at all, and writing a negative value | ||
12 | will resume the device if it is already suspended. | ||
13 | |||
14 | The autosuspend delay for newly-created devices is set to | ||
15 | the value of the usbcore.autosuspend module parameter. | ||
16 | |||
17 | What: /sys/bus/usb/devices/.../power/persist | ||
18 | Date: May 2007 | ||
19 | KernelVersion: 2.6.23 | ||
20 | Contact: Alan Stern <stern@rowland.harvard.edu> | ||
21 | Description: | ||
22 | If CONFIG_USB_PERSIST is set, then each USB device directory | ||
23 | will contain a file named power/persist. The file holds a | ||
24 | boolean value (0 or 1) indicating whether or not the | ||
25 | "USB-Persist" facility is enabled for the device. Since the | ||
26 | facility is inherently dangerous, it is disabled by default | ||
27 | for all devices except hubs. For more information, see | ||
28 | Documentation/usb/persist.txt. | ||
29 | |||
30 | What: /sys/bus/usb/device/.../power/connected_duration | ||
31 | Date: January 2008 | ||
32 | KernelVersion: 2.6.25 | ||
33 | Contact: Sarah Sharp <sarah.a.sharp@intel.com> | ||
34 | Description: | ||
35 | If CONFIG_PM_RUNTIME is enabled then this file | ||
36 | is present. When read, it returns the total time (in msec) | ||
37 | that the USB device has been connected to the machine. This | ||
38 | file is read-only. | ||
39 | Users: | ||
40 | PowerTOP <power@bughost.org> | ||
41 | http://www.lesswatts.org/projects/powertop/ | ||
42 | |||
43 | What: /sys/bus/usb/device/.../power/active_duration | ||
44 | Date: January 2008 | ||
45 | KernelVersion: 2.6.25 | ||
46 | Contact: Sarah Sharp <sarah.a.sharp@intel.com> | ||
47 | Description: | ||
48 | If CONFIG_PM_RUNTIME is enabled then this file | ||
49 | is present. When read, it returns the total time (in msec) | ||
50 | that the USB device has been active, i.e. not in a suspended | ||
51 | state. This file is read-only. | ||
52 | |||
53 | Tools can use this file and the connected_duration file to | ||
54 | compute the percentage of time that a device has been active. | ||
55 | For example, | ||
56 | echo $((100 * `cat active_duration` / `cat connected_duration`)) | ||
57 | will give an integer percentage. Note that this does not | ||
58 | account for counter wrap. | ||
59 | Users: | ||
60 | PowerTOP <power@bughost.org> | ||
61 | http://www.lesswatts.org/projects/powertop/ | ||
62 | |||
63 | What: /sys/bus/usb/device/<busnum>-<devnum>...:<config num>-<interface num>/supports_autosuspend | ||
64 | Date: January 2008 | ||
65 | KernelVersion: 2.6.27 | ||
66 | Contact: Sarah Sharp <sarah.a.sharp@intel.com> | ||
67 | Description: | ||
68 | When read, this file returns 1 if the interface driver | ||
69 | for this interface supports autosuspend. It also | ||
70 | returns 1 if no driver has claimed this interface, as an | ||
71 | unclaimed interface will not stop the device from being | ||
72 | autosuspended if all other interface drivers are idle. | ||
73 | The file returns 0 if autosuspend support has not been | ||
74 | added to the driver. | ||
75 | Users: | ||
76 | USB PM tool | ||
77 | git://git.moblin.org/users/sarah/usb-pm-tool/ | ||
78 | |||
79 | What: /sys/bus/usb/device/.../authorized | 1 | What: /sys/bus/usb/device/.../authorized |
80 | Date: July 2008 | 2 | Date: July 2008 |
81 | KernelVersion: 2.6.26 | 3 | KernelVersion: 2.6.26 |
@@ -172,17 +94,6 @@ Description: | |||
172 | device IDs, exactly like reading from the entry | 94 | device IDs, exactly like reading from the entry |
173 | "/sys/bus/usb/drivers/.../new_id" | 95 | "/sys/bus/usb/drivers/.../new_id" |
174 | 96 | ||
175 | What: /sys/bus/usb/device/.../avoid_reset_quirk | ||
176 | Date: December 2009 | ||
177 | Contact: Oliver Neukum <oliver@neukum.org> | ||
178 | Description: | ||
179 | Writing 1 to this file tells the kernel that this | ||
180 | device will morph into another mode when it is reset. | ||
181 | Drivers will not use reset for error handling for | ||
182 | such devices. | ||
183 | Users: | ||
184 | usb_modeswitch | ||
185 | |||
186 | What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm | 97 | What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm |
187 | Date: September 2011 | 98 | Date: September 2011 |
188 | Contact: Andiry Xu <andiry.xu@amd.com> | 99 | Contact: Andiry Xu <andiry.xu@amd.com> |
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs new file mode 100644 index 000000000000..31942efcaf0e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-fs-f2fs | |||
@@ -0,0 +1,26 @@ | |||
1 | What: /sys/fs/f2fs/<disk>/gc_max_sleep_time | ||
2 | Date: July 2013 | ||
3 | Contact: "Namjae Jeon" <namjae.jeon@samsung.com> | ||
4 | Description: | ||
5 | Controls the maximun sleep time for gc_thread. Time | ||
6 | is in milliseconds. | ||
7 | |||
8 | What: /sys/fs/f2fs/<disk>/gc_min_sleep_time | ||
9 | Date: July 2013 | ||
10 | Contact: "Namjae Jeon" <namjae.jeon@samsung.com> | ||
11 | Description: | ||
12 | Controls the minimum sleep time for gc_thread. Time | ||
13 | is in milliseconds. | ||
14 | |||
15 | What: /sys/fs/f2fs/<disk>/gc_no_gc_sleep_time | ||
16 | Date: July 2013 | ||
17 | Contact: "Namjae Jeon" <namjae.jeon@samsung.com> | ||
18 | Description: | ||
19 | Controls the default sleep time for gc_thread. Time | ||
20 | is in milliseconds. | ||
21 | |||
22 | What: /sys/fs/f2fs/<disk>/gc_idle | ||
23 | Date: July 2013 | ||
24 | Contact: "Namjae Jeon" <namjae.jeon@samsung.com> | ||
25 | Description: | ||
26 | Controls the victim selection policy for garbage collection. | ||
diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 49267ea97568..f403ec3c5c9a 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl | |||
@@ -325,6 +325,7 @@ | |||
325 | <title>functions/definitions</title> | 325 | <title>functions/definitions</title> |
326 | !Finclude/net/mac80211.h ieee80211_rx_status | 326 | !Finclude/net/mac80211.h ieee80211_rx_status |
327 | !Finclude/net/mac80211.h mac80211_rx_flags | 327 | !Finclude/net/mac80211.h mac80211_rx_flags |
328 | !Finclude/net/mac80211.h mac80211_tx_info_flags | ||
328 | !Finclude/net/mac80211.h mac80211_tx_control_flags | 329 | !Finclude/net/mac80211.h mac80211_tx_control_flags |
329 | !Finclude/net/mac80211.h mac80211_rate_control_flags | 330 | !Finclude/net/mac80211.h mac80211_rate_control_flags |
330 | !Finclude/net/mac80211.h ieee80211_tx_rate | 331 | !Finclude/net/mac80211.h ieee80211_tx_rate |
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 7d1278e7a434..ed1d6d289022 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl | |||
@@ -156,13 +156,6 @@ | |||
156 | </para></listitem> | 156 | </para></listitem> |
157 | </varlistentry> | 157 | </varlistentry> |
158 | <varlistentry> | 158 | <varlistentry> |
159 | <term>DRIVER_USE_MTRR</term> | ||
160 | <listitem><para> | ||
161 | Driver uses MTRR interface for mapping memory, the DRM core will | ||
162 | manage MTRR resources. Deprecated. | ||
163 | </para></listitem> | ||
164 | </varlistentry> | ||
165 | <varlistentry> | ||
166 | <term>DRIVER_PCI_DMA</term> | 159 | <term>DRIVER_PCI_DMA</term> |
167 | <listitem><para> | 160 | <listitem><para> |
168 | Driver is capable of PCI DMA, mapping of PCI DMA buffers to | 161 | Driver is capable of PCI DMA, mapping of PCI DMA buffers to |
@@ -195,28 +188,6 @@ | |||
195 | </para></listitem> | 188 | </para></listitem> |
196 | </varlistentry> | 189 | </varlistentry> |
197 | <varlistentry> | 190 | <varlistentry> |
198 | <term>DRIVER_IRQ_VBL</term> | ||
199 | <listitem><para>Unused. Deprecated.</para></listitem> | ||
200 | </varlistentry> | ||
201 | <varlistentry> | ||
202 | <term>DRIVER_DMA_QUEUE</term> | ||
203 | <listitem><para> | ||
204 | Should be set if the driver queues DMA requests and completes them | ||
205 | asynchronously. Deprecated. | ||
206 | </para></listitem> | ||
207 | </varlistentry> | ||
208 | <varlistentry> | ||
209 | <term>DRIVER_FB_DMA</term> | ||
210 | <listitem><para> | ||
211 | Driver supports DMA to/from the framebuffer, mapping of frambuffer | ||
212 | DMA buffers to userspace will be supported. Deprecated. | ||
213 | </para></listitem> | ||
214 | </varlistentry> | ||
215 | <varlistentry> | ||
216 | <term>DRIVER_IRQ_VBL2</term> | ||
217 | <listitem><para>Unused. Deprecated.</para></listitem> | ||
218 | </varlistentry> | ||
219 | <varlistentry> | ||
220 | <term>DRIVER_GEM</term> | 191 | <term>DRIVER_GEM</term> |
221 | <listitem><para> | 192 | <listitem><para> |
222 | Driver use the GEM memory manager. | 193 | Driver use the GEM memory manager. |
@@ -234,6 +205,12 @@ | |||
234 | Driver implements DRM PRIME buffer sharing. | 205 | Driver implements DRM PRIME buffer sharing. |
235 | </para></listitem> | 206 | </para></listitem> |
236 | </varlistentry> | 207 | </varlistentry> |
208 | <varlistentry> | ||
209 | <term>DRIVER_RENDER</term> | ||
210 | <listitem><para> | ||
211 | Driver supports dedicated render nodes. | ||
212 | </para></listitem> | ||
213 | </varlistentry> | ||
237 | </variablelist> | 214 | </variablelist> |
238 | </sect3> | 215 | </sect3> |
239 | <sect3> | 216 | <sect3> |
@@ -2212,6 +2189,18 @@ void intel_crt_init(struct drm_device *dev) | |||
2212 | !Iinclude/drm/drm_rect.h | 2189 | !Iinclude/drm/drm_rect.h |
2213 | !Edrivers/gpu/drm/drm_rect.c | 2190 | !Edrivers/gpu/drm/drm_rect.c |
2214 | </sect2> | 2191 | </sect2> |
2192 | <sect2> | ||
2193 | <title>Flip-work Helper Reference</title> | ||
2194 | !Pinclude/drm/drm_flip_work.h flip utils | ||
2195 | !Iinclude/drm/drm_flip_work.h | ||
2196 | !Edrivers/gpu/drm/drm_flip_work.c | ||
2197 | </sect2> | ||
2198 | <sect2> | ||
2199 | <title>VMA Offset Manager</title> | ||
2200 | !Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager | ||
2201 | !Edrivers/gpu/drm/drm_vma_manager.c | ||
2202 | !Iinclude/drm/drm_vma_manager.h | ||
2203 | </sect2> | ||
2215 | </sect1> | 2204 | </sect1> |
2216 | 2205 | ||
2217 | <!-- Internals: kms properties --> | 2206 | <!-- Internals: kms properties --> |
@@ -2422,18 +2411,18 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis> | |||
2422 | </abstract> | 2411 | </abstract> |
2423 | <para> | 2412 | <para> |
2424 | The <methodname>firstopen</methodname> method is called by the DRM core | 2413 | The <methodname>firstopen</methodname> method is called by the DRM core |
2425 | when an application opens a device that has no other opened file handle. | 2414 | for legacy UMS (User Mode Setting) drivers only when an application |
2426 | Similarly the <methodname>lastclose</methodname> method is called when | 2415 | opens a device that has no other opened file handle. UMS drivers can |
2427 | the last application holding a file handle opened on the device closes | 2416 | implement it to acquire device resources. KMS drivers can't use the |
2428 | it. Both methods are mostly used for UMS (User Mode Setting) drivers to | 2417 | method and must acquire resources in the <methodname>load</methodname> |
2429 | acquire and release device resources which should be done in the | 2418 | method instead. |
2430 | <methodname>load</methodname> and <methodname>unload</methodname> | ||
2431 | methods for KMS drivers. | ||
2432 | </para> | 2419 | </para> |
2433 | <para> | 2420 | <para> |
2434 | Note that the <methodname>lastclose</methodname> method is also called | 2421 | Similarly the <methodname>lastclose</methodname> method is called when |
2435 | at module unload time or, for hot-pluggable devices, when the device is | 2422 | the last application holding a file handle opened on the device closes |
2436 | unplugged. The <methodname>firstopen</methodname> and | 2423 | it, for both UMS and KMS drivers. Additionally, the method is also |
2424 | called at module unload time or, for hot-pluggable devices, when the | ||
2425 | device is unplugged. The <methodname>firstopen</methodname> and | ||
2437 | <methodname>lastclose</methodname> calls can thus be unbalanced. | 2426 | <methodname>lastclose</methodname> calls can thus be unbalanced. |
2438 | </para> | 2427 | </para> |
2439 | <para> | 2428 | <para> |
@@ -2462,7 +2451,12 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis> | |||
2462 | <para> | 2451 | <para> |
2463 | The <methodname>lastclose</methodname> method should restore CRTC and | 2452 | The <methodname>lastclose</methodname> method should restore CRTC and |
2464 | plane properties to default value, so that a subsequent open of the | 2453 | plane properties to default value, so that a subsequent open of the |
2465 | device will not inherit state from the previous user. | 2454 | device will not inherit state from the previous user. It can also be |
2455 | used to execute delayed power switching state changes, e.g. in | ||
2456 | conjunction with the vga-switcheroo infrastructure. Beyond that KMS | ||
2457 | drivers should not do any further cleanup. Only legacy UMS drivers might | ||
2458 | need to clean up device state so that the vga console or an independent | ||
2459 | fbdev driver could take over. | ||
2466 | </para> | 2460 | </para> |
2467 | </sect2> | 2461 | </sect2> |
2468 | <sect2> | 2462 | <sect2> |
@@ -2498,7 +2492,6 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis> | |||
2498 | <programlisting> | 2492 | <programlisting> |
2499 | .poll = drm_poll, | 2493 | .poll = drm_poll, |
2500 | .read = drm_read, | 2494 | .read = drm_read, |
2501 | .fasync = drm_fasync, | ||
2502 | .llseek = no_llseek, | 2495 | .llseek = no_llseek, |
2503 | </programlisting> | 2496 | </programlisting> |
2504 | </para> | 2497 | </para> |
@@ -2657,6 +2650,69 @@ int (*resume) (struct drm_device *);</synopsis> | |||
2657 | info, since man pages should cover the rest. | 2650 | info, since man pages should cover the rest. |
2658 | </para> | 2651 | </para> |
2659 | 2652 | ||
2653 | <!-- External: render nodes --> | ||
2654 | |||
2655 | <sect1> | ||
2656 | <title>Render nodes</title> | ||
2657 | <para> | ||
2658 | DRM core provides multiple character-devices for user-space to use. | ||
2659 | Depending on which device is opened, user-space can perform a different | ||
2660 | set of operations (mainly ioctls). The primary node is always created | ||
2661 | and called <term>card<num></term>. Additionally, a currently | ||
2662 | unused control node, called <term>controlD<num></term> is also | ||
2663 | created. The primary node provides all legacy operations and | ||
2664 | historically was the only interface used by userspace. With KMS, the | ||
2665 | control node was introduced. However, the planned KMS control interface | ||
2666 | has never been written and so the control node stays unused to date. | ||
2667 | </para> | ||
2668 | <para> | ||
2669 | With the increased use of offscreen renderers and GPGPU applications, | ||
2670 | clients no longer require running compositors or graphics servers to | ||
2671 | make use of a GPU. But the DRM API required unprivileged clients to | ||
2672 | authenticate to a DRM-Master prior to getting GPU access. To avoid this | ||
2673 | step and to grant clients GPU access without authenticating, render | ||
2674 | nodes were introduced. Render nodes solely serve render clients, that | ||
2675 | is, no modesetting or privileged ioctls can be issued on render nodes. | ||
2676 | Only non-global rendering commands are allowed. If a driver supports | ||
2677 | render nodes, it must advertise it via the <term>DRIVER_RENDER</term> | ||
2678 | DRM driver capability. If not supported, the primary node must be used | ||
2679 | for render clients together with the legacy drmAuth authentication | ||
2680 | procedure. | ||
2681 | </para> | ||
2682 | <para> | ||
2683 | If a driver advertises render node support, DRM core will create a | ||
2684 | separate render node called <term>renderD<num></term>. There will | ||
2685 | be one render node per device. No ioctls except PRIME-related ioctls | ||
2686 | will be allowed on this node. Especially <term>GEM_OPEN</term> will be | ||
2687 | explicitly prohibited. Render nodes are designed to avoid the | ||
2688 | buffer-leaks, which occur if clients guess the flink names or mmap | ||
2689 | offsets on the legacy interface. Additionally to this basic interface, | ||
2690 | drivers must mark their driver-dependent render-only ioctls as | ||
2691 | <term>DRM_RENDER_ALLOW</term> so render clients can use them. Driver | ||
2692 | authors must be careful not to allow any privileged ioctls on render | ||
2693 | nodes. | ||
2694 | </para> | ||
2695 | <para> | ||
2696 | With render nodes, user-space can now control access to the render node | ||
2697 | via basic file-system access-modes. A running graphics server which | ||
2698 | authenticates clients on the privileged primary/legacy node is no longer | ||
2699 | required. Instead, a client can open the render node and is immediately | ||
2700 | granted GPU access. Communication between clients (or servers) is done | ||
2701 | via PRIME. FLINK from render node to legacy node is not supported. New | ||
2702 | clients must not use the insecure FLINK interface. | ||
2703 | </para> | ||
2704 | <para> | ||
2705 | Besides dropping all modeset/global ioctls, render nodes also drop the | ||
2706 | DRM-Master concept. There is no reason to associate render clients with | ||
2707 | a DRM-Master as they are independent of any graphics server. Besides, | ||
2708 | they must work without any running master, anyway. | ||
2709 | Drivers must be able to run without a master object if they support | ||
2710 | render nodes. If, on the other hand, a driver requires shared state | ||
2711 | between clients which is visible to user-space and accessible beyond | ||
2712 | open-file boundaries, they cannot support render nodes. | ||
2713 | </para> | ||
2714 | </sect1> | ||
2715 | |||
2660 | <!-- External: vblank handling --> | 2716 | <!-- External: vblank handling --> |
2661 | 2717 | ||
2662 | <sect1> | 2718 | <sect1> |
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index c2fc9ec1417e..7a3b49b3cc3b 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml | |||
@@ -722,17 +722,22 @@ for more details.</para> | |||
722 | </section> | 722 | </section> |
723 | 723 | ||
724 | <section id="mpeg-controls"> | 724 | <section id="mpeg-controls"> |
725 | <title>MPEG Control Reference</title> | 725 | <title>Codec Control Reference</title> |
726 | 726 | ||
727 | <para>Below all controls within the MPEG control class are | 727 | <para>Below all controls within the Codec control class are |
728 | described. First the generic controls, then controls specific for | 728 | described. First the generic controls, then controls specific for |
729 | certain hardware.</para> | 729 | certain hardware.</para> |
730 | 730 | ||
731 | <para>Note: These controls are applicable to all codecs and | ||
732 | not just MPEG. The defines are prefixed with V4L2_CID_MPEG/V4L2_MPEG | ||
733 | as the controls were originally made for MPEG codecs and later | ||
734 | extended to cover all encoding formats.</para> | ||
735 | |||
731 | <section> | 736 | <section> |
732 | <title>Generic MPEG Controls</title> | 737 | <title>Generic Codec Controls</title> |
733 | 738 | ||
734 | <table pgwide="1" frame="none" id="mpeg-control-id"> | 739 | <table pgwide="1" frame="none" id="mpeg-control-id"> |
735 | <title>MPEG Control IDs</title> | 740 | <title>Codec Control IDs</title> |
736 | <tgroup cols="4"> | 741 | <tgroup cols="4"> |
737 | <colspec colname="c1" colwidth="1*" /> | 742 | <colspec colname="c1" colwidth="1*" /> |
738 | <colspec colname="c2" colwidth="6*" /> | 743 | <colspec colname="c2" colwidth="6*" /> |
@@ -752,7 +757,7 @@ certain hardware.</para> | |||
752 | <row> | 757 | <row> |
753 | <entry spanname="id"><constant>V4L2_CID_MPEG_CLASS</constant> </entry> | 758 | <entry spanname="id"><constant>V4L2_CID_MPEG_CLASS</constant> </entry> |
754 | <entry>class</entry> | 759 | <entry>class</entry> |
755 | </row><row><entry spanname="descr">The MPEG class | 760 | </row><row><entry spanname="descr">The Codec class |
756 | descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a | 761 | descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a |
757 | description of this control class. This description can be used as the | 762 | description of this control class. This description can be used as the |
758 | caption of a Tab page in a GUI, for example.</entry> | 763 | caption of a Tab page in a GUI, for example.</entry> |
@@ -3009,6 +3014,159 @@ in by the application. 0 = do not insert, 1 = insert packets.</entry> | |||
3009 | </tgroup> | 3014 | </tgroup> |
3010 | </table> | 3015 | </table> |
3011 | </section> | 3016 | </section> |
3017 | |||
3018 | <section> | ||
3019 | <title>VPX Control Reference</title> | ||
3020 | |||
3021 | <para>The VPX controls include controls for encoding parameters | ||
3022 | of VPx video codec.</para> | ||
3023 | |||
3024 | <table pgwide="1" frame="none" id="vpx-control-id"> | ||
3025 | <title>VPX Control IDs</title> | ||
3026 | |||
3027 | <tgroup cols="4"> | ||
3028 | <colspec colname="c1" colwidth="1*" /> | ||
3029 | <colspec colname="c2" colwidth="6*" /> | ||
3030 | <colspec colname="c3" colwidth="2*" /> | ||
3031 | <colspec colname="c4" colwidth="6*" /> | ||
3032 | <spanspec namest="c1" nameend="c2" spanname="id" /> | ||
3033 | <spanspec namest="c2" nameend="c4" spanname="descr" /> | ||
3034 | <thead> | ||
3035 | <row> | ||
3036 | <entry spanname="id" align="left">ID</entry> | ||
3037 | <entry align="left">Type</entry> | ||
3038 | </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry> | ||
3039 | </row> | ||
3040 | </thead> | ||
3041 | <tbody valign="top"> | ||
3042 | <row><entry></entry></row> | ||
3043 | |||
3044 | <row><entry></entry></row> | ||
3045 | <row id="v4l2-vpx-num-partitions"> | ||
3046 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS</constant></entry> | ||
3047 | <entry>enum v4l2_vp8_num_partitions</entry> | ||
3048 | </row> | ||
3049 | <row><entry spanname="descr">The number of token partitions to use in VP8 encoder. | ||
3050 | Possible values are:</entry> | ||
3051 | </row> | ||
3052 | <row> | ||
3053 | <entrytbl spanname="descr" cols="2"> | ||
3054 | <tbody valign="top"> | ||
3055 | <row> | ||
3056 | <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_1_PARTITION</constant></entry> | ||
3057 | <entry>1 coefficient partition</entry> | ||
3058 | </row> | ||
3059 | <row> | ||
3060 | <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_2_PARTITIONS</constant></entry> | ||
3061 | <entry>2 coefficient partitions</entry> | ||
3062 | </row> | ||
3063 | <row> | ||
3064 | <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_4_PARTITIONS</constant></entry> | ||
3065 | <entry>4 coefficient partitions</entry> | ||
3066 | </row> | ||
3067 | <row> | ||
3068 | <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_8_PARTITIONS</constant></entry> | ||
3069 | <entry>8 coefficient partitions</entry> | ||
3070 | </row> | ||
3071 | </tbody> | ||
3072 | </entrytbl> | ||
3073 | </row> | ||
3074 | |||
3075 | <row><entry></entry></row> | ||
3076 | <row> | ||
3077 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_IMD_DISABLE_4X4</constant></entry> | ||
3078 | <entry>boolean</entry> | ||
3079 | </row> | ||
3080 | <row><entry spanname="descr">Setting this prevents intra 4x4 mode in the intra mode decision.</entry> | ||
3081 | </row> | ||
3082 | |||
3083 | <row><entry></entry></row> | ||
3084 | <row id="v4l2-vpx-num-ref-frames"> | ||
3085 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES</constant></entry> | ||
3086 | <entry>enum v4l2_vp8_num_ref_frames</entry> | ||
3087 | </row> | ||
3088 | <row><entry spanname="descr">The number of reference pictures for encoding P frames. | ||
3089 | Possible values are:</entry> | ||
3090 | </row> | ||
3091 | <row> | ||
3092 | <entrytbl spanname="descr" cols="2"> | ||
3093 | <tbody valign="top"> | ||
3094 | <row> | ||
3095 | <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_1_REF_FRAME</constant></entry> | ||
3096 | <entry>Last encoded frame will be searched</entry> | ||
3097 | </row> | ||
3098 | <row> | ||
3099 | <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_2_REF_FRAME</constant></entry> | ||
3100 | <entry>Two frames will be searched among the last encoded frame, the golden frame | ||
3101 | and the alternate reference (altref) frame. The encoder implementation will decide which two are chosen.</entry> | ||
3102 | </row> | ||
3103 | <row> | ||
3104 | <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_3_REF_FRAME</constant></entry> | ||
3105 | <entry>The last encoded frame, the golden frame and the altref frame will be searched.</entry> | ||
3106 | </row> | ||
3107 | </tbody> | ||
3108 | </entrytbl> | ||
3109 | </row> | ||
3110 | |||
3111 | <row><entry></entry></row> | ||
3112 | <row> | ||
3113 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_FILTER_LEVEL</constant></entry> | ||
3114 | <entry>integer</entry> | ||
3115 | </row> | ||
3116 | <row><entry spanname="descr">Indicates the loop filter level. The adjustment of the loop | ||
3117 | filter level is done via a delta value against a baseline loop filter value.</entry> | ||
3118 | </row> | ||
3119 | |||
3120 | <row><entry></entry></row> | ||
3121 | <row> | ||
3122 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_FILTER_SHARPNESS</constant></entry> | ||
3123 | <entry>integer</entry> | ||
3124 | </row> | ||
3125 | <row><entry spanname="descr">This parameter affects the loop filter. Anything above | ||
3126 | zero weakens the deblocking effect on the loop filter.</entry> | ||
3127 | </row> | ||
3128 | |||
3129 | <row><entry></entry></row> | ||
3130 | <row> | ||
3131 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD</constant></entry> | ||
3132 | <entry>integer</entry> | ||
3133 | </row> | ||
3134 | <row><entry spanname="descr">Sets the refresh period for the golden frame. The period is defined | ||
3135 | in number of frames. For a value of 'n', every nth frame starting from the first key frame will be taken as a golden frame. | ||
3136 | For eg. for encoding sequence of 0, 1, 2, 3, 4, 5, 6, 7 where the golden frame refresh period is set as 4, the frames | ||
3137 | 0, 4, 8 etc will be taken as the golden frames as frame 0 is always a key frame.</entry> | ||
3138 | </row> | ||
3139 | |||
3140 | <row><entry></entry></row> | ||
3141 | <row id="v4l2-vpx-golden-frame-sel"> | ||
3142 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL</constant></entry> | ||
3143 | <entry>enum v4l2_vp8_golden_frame_sel</entry> | ||
3144 | </row> | ||
3145 | <row><entry spanname="descr">Selects the golden frame for encoding. | ||
3146 | Possible values are:</entry> | ||
3147 | </row> | ||
3148 | <row> | ||
3149 | <entrytbl spanname="descr" cols="2"> | ||
3150 | <tbody valign="top"> | ||
3151 | <row> | ||
3152 | <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_USE_PREV</constant></entry> | ||
3153 | <entry>Use the (n-2)th frame as a golden frame, current frame index being 'n'.</entry> | ||
3154 | </row> | ||
3155 | <row> | ||
3156 | <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_USE_REF_PERIOD</constant></entry> | ||
3157 | <entry>Use the previous specific frame indicated by | ||
3158 | V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a golden frame.</entry> | ||
3159 | </row> | ||
3160 | </tbody> | ||
3161 | </entrytbl> | ||
3162 | </row> | ||
3163 | |||
3164 | <row><entry></entry></row> | ||
3165 | </tbody> | ||
3166 | </tgroup> | ||
3167 | </table> | ||
3168 | |||
3169 | </section> | ||
3012 | </section> | 3170 | </section> |
3013 | 3171 | ||
3014 | <section id="camera-controls"> | 3172 | <section id="camera-controls"> |
diff --git a/Documentation/DocBook/media/v4l/lirc_device_interface.xml b/Documentation/DocBook/media/v4l/lirc_device_interface.xml index 8d7eb6bf6312..34cada2ca710 100644 --- a/Documentation/DocBook/media/v4l/lirc_device_interface.xml +++ b/Documentation/DocBook/media/v4l/lirc_device_interface.xml | |||
@@ -46,7 +46,9 @@ describing an IR signal are read from the chardev.</para> | |||
46 | values. Pulses and spaces are only marked implicitly by their position. The | 46 | values. Pulses and spaces are only marked implicitly by their position. The |
47 | data must start and end with a pulse, therefore, the data must always include | 47 | data must start and end with a pulse, therefore, the data must always include |
48 | an uneven number of samples. The write function must block until the data has | 48 | an uneven number of samples. The write function must block until the data has |
49 | been transmitted by the hardware.</para> | 49 | been transmitted by the hardware. If more data is provided than the hardware |
50 | can send, the driver returns EINVAL.</para> | ||
51 | |||
50 | </section> | 52 | </section> |
51 | 53 | ||
52 | <section id="lirc_ioctl"> | 54 | <section id="lirc_ioctl"> |
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml new file mode 100644 index 000000000000..c51d5a4cda09 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | |||
@@ -0,0 +1,171 @@ | |||
1 | <refentry> | ||
2 | <refmeta> | ||
3 | <refentrytitle>V4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M ('NM61')</refentrytitle> | ||
4 | &manvol; | ||
5 | </refmeta> | ||
6 | <refnamediv> | ||
7 | <refname id="V4L2-PIX-FMT-NV16M"><constant>V4L2_PIX_FMT_NV16M</constant></refname> | ||
8 | <refname id="V4L2-PIX-FMT-NV61M"><constant>V4L2_PIX_FMT_NV61M</constant></refname> | ||
9 | <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV16</constant> and <constant>V4L2_PIX_FMT_NV61</constant> with planes | ||
10 | non contiguous in memory. </refpurpose> | ||
11 | </refnamediv> | ||
12 | <refsect1> | ||
13 | <title>Description</title> | ||
14 | |||
15 | <para>This is a multi-planar, two-plane version of the YUV 4:2:0 format. | ||
16 | The three components are separated into two sub-images or planes. | ||
17 | <constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16 | ||
18 | </constant> in that the two planes are non-contiguous in memory, i.e. the chroma | ||
19 | plane does not necessarily immediately follows the luma plane. | ||
20 | The luminance data occupies the first plane. The Y plane has one byte per pixel. | ||
21 | In the second plane there is chrominance data with alternating chroma samples. | ||
22 | The CbCr plane is the same width and height, in bytes, as the Y plane. | ||
23 | Each CbCr pair belongs to four pixels. For example, | ||
24 | Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to | ||
25 | Y'<subscript>00</subscript>, Y'<subscript>01</subscript>, | ||
26 | Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. | ||
27 | <constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant> | ||
28 | except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para> | ||
29 | |||
30 | <para><constant>V4L2_PIX_FMT_NV16M</constant> and | ||
31 | <constant>V4L2_PIX_FMT_NV61M</constant> are intended to be used only in drivers | ||
32 | and applications that support the multi-planar API, described in | ||
33 | <xref linkend="planar-apis"/>. </para> | ||
34 | |||
35 | <example> | ||
36 | <title><constant>V4L2_PIX_FMT_NV16M</constant> 4 × 4 pixel image</title> | ||
37 | |||
38 | <formalpara> | ||
39 | <title>Byte Order.</title> | ||
40 | <para>Each cell is one byte. | ||
41 | <informaltable frame="none"> | ||
42 | <tgroup cols="5" align="center"> | ||
43 | <colspec align="left" colwidth="2*" /> | ||
44 | <tbody valign="top"> | ||
45 | <row> | ||
46 | <entry>start0 + 0:</entry> | ||
47 | <entry>Y'<subscript>00</subscript></entry> | ||
48 | <entry>Y'<subscript>01</subscript></entry> | ||
49 | <entry>Y'<subscript>02</subscript></entry> | ||
50 | <entry>Y'<subscript>03</subscript></entry> | ||
51 | </row> | ||
52 | <row> | ||
53 | <entry>start0 + 4:</entry> | ||
54 | <entry>Y'<subscript>10</subscript></entry> | ||
55 | <entry>Y'<subscript>11</subscript></entry> | ||
56 | <entry>Y'<subscript>12</subscript></entry> | ||
57 | <entry>Y'<subscript>13</subscript></entry> | ||
58 | </row> | ||
59 | <row> | ||
60 | <entry>start0 + 8:</entry> | ||
61 | <entry>Y'<subscript>20</subscript></entry> | ||
62 | <entry>Y'<subscript>21</subscript></entry> | ||
63 | <entry>Y'<subscript>22</subscript></entry> | ||
64 | <entry>Y'<subscript>23</subscript></entry> | ||
65 | </row> | ||
66 | <row> | ||
67 | <entry>start0 + 12:</entry> | ||
68 | <entry>Y'<subscript>30</subscript></entry> | ||
69 | <entry>Y'<subscript>31</subscript></entry> | ||
70 | <entry>Y'<subscript>32</subscript></entry> | ||
71 | <entry>Y'<subscript>33</subscript></entry> | ||
72 | </row> | ||
73 | <row> | ||
74 | <entry></entry> | ||
75 | </row> | ||
76 | <row> | ||
77 | <entry>start1 + 0:</entry> | ||
78 | <entry>Cb<subscript>00</subscript></entry> | ||
79 | <entry>Cr<subscript>00</subscript></entry> | ||
80 | <entry>Cb<subscript>02</subscript></entry> | ||
81 | <entry>Cr<subscript>02</subscript></entry> | ||
82 | </row> | ||
83 | <row> | ||
84 | <entry>start1 + 4:</entry> | ||
85 | <entry>Cb<subscript>10</subscript></entry> | ||
86 | <entry>Cr<subscript>10</subscript></entry> | ||
87 | <entry>Cb<subscript>12</subscript></entry> | ||
88 | <entry>Cr<subscript>12</subscript></entry> | ||
89 | </row> | ||
90 | <row> | ||
91 | <entry>start1 + 8:</entry> | ||
92 | <entry>Cb<subscript>20</subscript></entry> | ||
93 | <entry>Cr<subscript>20</subscript></entry> | ||
94 | <entry>Cb<subscript>22</subscript></entry> | ||
95 | <entry>Cr<subscript>22</subscript></entry> | ||
96 | </row> | ||
97 | <row> | ||
98 | <entry>start1 + 12:</entry> | ||
99 | <entry>Cb<subscript>30</subscript></entry> | ||
100 | <entry>Cr<subscript>30</subscript></entry> | ||
101 | <entry>Cb<subscript>32</subscript></entry> | ||
102 | <entry>Cr<subscript>32</subscript></entry> | ||
103 | </row> | ||
104 | </tbody> | ||
105 | </tgroup> | ||
106 | </informaltable> | ||
107 | </para> | ||
108 | </formalpara> | ||
109 | |||
110 | <formalpara> | ||
111 | <title>Color Sample Location.</title> | ||
112 | <para> | ||
113 | <informaltable frame="none"> | ||
114 | <tgroup cols="7" align="center"> | ||
115 | <tbody valign="top"> | ||
116 | <row> | ||
117 | <entry></entry> | ||
118 | <entry>0</entry><entry></entry><entry>1</entry><entry></entry> | ||
119 | <entry>2</entry><entry></entry><entry>3</entry> | ||
120 | </row> | ||
121 | <row> | ||
122 | <entry>0</entry> | ||
123 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
124 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
125 | </row> | ||
126 | <row> | ||
127 | <entry></entry> | ||
128 | <entry></entry><entry>C</entry><entry></entry><entry></entry> | ||
129 | <entry></entry><entry>C</entry><entry></entry> | ||
130 | </row> | ||
131 | <row> | ||
132 | <entry>1</entry> | ||
133 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
134 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
135 | </row> | ||
136 | <row> | ||
137 | <entry></entry> | ||
138 | <entry></entry><entry>C</entry><entry></entry><entry></entry> | ||
139 | <entry></entry><entry>C</entry><entry></entry> | ||
140 | </row> | ||
141 | <row> | ||
142 | <entry></entry> | ||
143 | </row> | ||
144 | <row> | ||
145 | <entry>2</entry> | ||
146 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
147 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
148 | </row> | ||
149 | <row> | ||
150 | <entry></entry> | ||
151 | <entry></entry><entry>C</entry><entry></entry><entry></entry> | ||
152 | <entry></entry><entry>C</entry><entry></entry> | ||
153 | </row> | ||
154 | <row> | ||
155 | <entry>3</entry> | ||
156 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
157 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
158 | </row> | ||
159 | <row> | ||
160 | <entry></entry> | ||
161 | <entry></entry><entry>C</entry><entry></entry><entry></entry> | ||
162 | <entry></entry><entry>C</entry><entry></entry> | ||
163 | </row> | ||
164 | </tbody> | ||
165 | </tgroup> | ||
166 | </informaltable> | ||
167 | </para> | ||
168 | </formalpara> | ||
169 | </example> | ||
170 | </refsect1> | ||
171 | </refentry> | ||
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 99b8d2ad6e4f..72d72bd67d0a 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml | |||
@@ -391,9 +391,9 @@ clamp (double x) | |||
391 | else return r; | 391 | else return r; |
392 | } | 392 | } |
393 | 393 | ||
394 | y1 = (255 / 219.0) * (Y1 - 16); | 394 | y1 = (Y1 - 16) / 219.0; |
395 | pb = (255 / 224.0) * (Cb - 128); | 395 | pb = (Cb - 128) / 224.0; |
396 | pr = (255 / 224.0) * (Cr - 128); | 396 | pr = (Cr - 128) / 224.0; |
397 | 397 | ||
398 | r = 1.0 * y1 + 0 * pb + 1.402 * pr; | 398 | r = 1.0 * y1 + 0 * pb + 1.402 * pr; |
399 | g = 1.0 * y1 - 0.344 * pb - 0.714 * pr; | 399 | g = 1.0 * y1 - 0.344 * pb - 0.714 * pr; |
@@ -718,6 +718,7 @@ information.</para> | |||
718 | &sub-nv12m; | 718 | &sub-nv12m; |
719 | &sub-nv12mt; | 719 | &sub-nv12mt; |
720 | &sub-nv16; | 720 | &sub-nv16; |
721 | &sub-nv16m; | ||
721 | &sub-nv24; | 722 | &sub-nv24; |
722 | &sub-m420; | 723 | &sub-m420; |
723 | </section> | 724 | </section> |
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index adc61982df7b..f72c1cc93a9b 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml | |||
@@ -97,31 +97,39 @@ | |||
97 | <colspec colname="id" align="left" /> | 97 | <colspec colname="id" align="left" /> |
98 | <colspec colname="code" align="center"/> | 98 | <colspec colname="code" align="center"/> |
99 | <colspec colname="bit" /> | 99 | <colspec colname="bit" /> |
100 | <colspec colnum="4" colname="b23" align="center" /> | 100 | <colspec colnum="4" colname="b31" align="center" /> |
101 | <colspec colnum="5" colname="b22" align="center" /> | 101 | <colspec colnum="5" colname="b20" align="center" /> |
102 | <colspec colnum="6" colname="b21" align="center" /> | 102 | <colspec colnum="6" colname="b29" align="center" /> |
103 | <colspec colnum="7" colname="b20" align="center" /> | 103 | <colspec colnum="7" colname="b28" align="center" /> |
104 | <colspec colnum="8" colname="b19" align="center" /> | 104 | <colspec colnum="8" colname="b27" align="center" /> |
105 | <colspec colnum="9" colname="b18" align="center" /> | 105 | <colspec colnum="9" colname="b26" align="center" /> |
106 | <colspec colnum="10" colname="b17" align="center" /> | 106 | <colspec colnum="10" colname="b25" align="center" /> |
107 | <colspec colnum="11" colname="b16" align="center" /> | 107 | <colspec colnum="11" colname="b24" align="center" /> |
108 | <colspec colnum="12" colname="b15" align="center" /> | 108 | <colspec colnum="12" colname="b23" align="center" /> |
109 | <colspec colnum="13" colname="b14" align="center" /> | 109 | <colspec colnum="13" colname="b22" align="center" /> |
110 | <colspec colnum="14" colname="b13" align="center" /> | 110 | <colspec colnum="14" colname="b21" align="center" /> |
111 | <colspec colnum="15" colname="b12" align="center" /> | 111 | <colspec colnum="15" colname="b20" align="center" /> |
112 | <colspec colnum="16" colname="b11" align="center" /> | 112 | <colspec colnum="16" colname="b19" align="center" /> |
113 | <colspec colnum="17" colname="b10" align="center" /> | 113 | <colspec colnum="17" colname="b18" align="center" /> |
114 | <colspec colnum="18" colname="b09" align="center" /> | 114 | <colspec colnum="18" colname="b17" align="center" /> |
115 | <colspec colnum="19" colname="b08" align="center" /> | 115 | <colspec colnum="19" colname="b16" align="center" /> |
116 | <colspec colnum="20" colname="b07" align="center" /> | 116 | <colspec colnum="20" colname="b15" align="center" /> |
117 | <colspec colnum="21" colname="b06" align="center" /> | 117 | <colspec colnum="21" colname="b14" align="center" /> |
118 | <colspec colnum="22" colname="b05" align="center" /> | 118 | <colspec colnum="22" colname="b13" align="center" /> |
119 | <colspec colnum="23" colname="b04" align="center" /> | 119 | <colspec colnum="23" colname="b12" align="center" /> |
120 | <colspec colnum="24" colname="b03" align="center" /> | 120 | <colspec colnum="24" colname="b11" align="center" /> |
121 | <colspec colnum="25" colname="b02" align="center" /> | 121 | <colspec colnum="25" colname="b10" align="center" /> |
122 | <colspec colnum="26" colname="b01" align="center" /> | 122 | <colspec colnum="26" colname="b09" align="center" /> |
123 | <colspec colnum="27" colname="b00" align="center" /> | 123 | <colspec colnum="27" colname="b08" align="center" /> |
124 | <spanspec namest="b23" nameend="b00" spanname="b0" /> | 124 | <colspec colnum="28" colname="b07" align="center" /> |
125 | <colspec colnum="29" colname="b06" align="center" /> | ||
126 | <colspec colnum="30" colname="b05" align="center" /> | ||
127 | <colspec colnum="31" colname="b04" align="center" /> | ||
128 | <colspec colnum="32" colname="b03" align="center" /> | ||
129 | <colspec colnum="33" colname="b02" align="center" /> | ||
130 | <colspec colnum="34" colname="b01" align="center" /> | ||
131 | <colspec colnum="35" colname="b00" align="center" /> | ||
132 | <spanspec namest="b31" nameend="b00" spanname="b0" /> | ||
125 | <thead> | 133 | <thead> |
126 | <row> | 134 | <row> |
127 | <entry>Identifier</entry> | 135 | <entry>Identifier</entry> |
@@ -133,6 +141,14 @@ | |||
133 | <entry></entry> | 141 | <entry></entry> |
134 | <entry></entry> | 142 | <entry></entry> |
135 | <entry>Bit</entry> | 143 | <entry>Bit</entry> |
144 | <entry>31</entry> | ||
145 | <entry>30</entry> | ||
146 | <entry>29</entry> | ||
147 | <entry>28</entry> | ||
148 | <entry>27</entry> | ||
149 | <entry>26</entry> | ||
150 | <entry>25</entry> | ||
151 | <entry>24</entry> | ||
136 | <entry>23</entry> | 152 | <entry>23</entry> |
137 | <entry>22</entry> | 153 | <entry>22</entry> |
138 | <entry>21</entry> | 154 | <entry>21</entry> |
@@ -164,7 +180,7 @@ | |||
164 | <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE</entry> | 180 | <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE</entry> |
165 | <entry>0x1001</entry> | 181 | <entry>0x1001</entry> |
166 | <entry></entry> | 182 | <entry></entry> |
167 | &dash-ent-16; | 183 | &dash-ent-24; |
168 | <entry>0</entry> | 184 | <entry>0</entry> |
169 | <entry>0</entry> | 185 | <entry>0</entry> |
170 | <entry>0</entry> | 186 | <entry>0</entry> |
@@ -178,7 +194,7 @@ | |||
178 | <entry></entry> | 194 | <entry></entry> |
179 | <entry></entry> | 195 | <entry></entry> |
180 | <entry></entry> | 196 | <entry></entry> |
181 | &dash-ent-16; | 197 | &dash-ent-24; |
182 | <entry>g<subscript>3</subscript></entry> | 198 | <entry>g<subscript>3</subscript></entry> |
183 | <entry>g<subscript>2</subscript></entry> | 199 | <entry>g<subscript>2</subscript></entry> |
184 | <entry>g<subscript>1</subscript></entry> | 200 | <entry>g<subscript>1</subscript></entry> |
@@ -192,7 +208,7 @@ | |||
192 | <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE</entry> | 208 | <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE</entry> |
193 | <entry>0x1002</entry> | 209 | <entry>0x1002</entry> |
194 | <entry></entry> | 210 | <entry></entry> |
195 | &dash-ent-16; | 211 | &dash-ent-24; |
196 | <entry>g<subscript>3</subscript></entry> | 212 | <entry>g<subscript>3</subscript></entry> |
197 | <entry>g<subscript>2</subscript></entry> | 213 | <entry>g<subscript>2</subscript></entry> |
198 | <entry>g<subscript>1</subscript></entry> | 214 | <entry>g<subscript>1</subscript></entry> |
@@ -206,7 +222,7 @@ | |||
206 | <entry></entry> | 222 | <entry></entry> |
207 | <entry></entry> | 223 | <entry></entry> |
208 | <entry></entry> | 224 | <entry></entry> |
209 | &dash-ent-16; | 225 | &dash-ent-24; |
210 | <entry>0</entry> | 226 | <entry>0</entry> |
211 | <entry>0</entry> | 227 | <entry>0</entry> |
212 | <entry>0</entry> | 228 | <entry>0</entry> |
@@ -220,7 +236,7 @@ | |||
220 | <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</entry> | 236 | <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</entry> |
221 | <entry>0x1003</entry> | 237 | <entry>0x1003</entry> |
222 | <entry></entry> | 238 | <entry></entry> |
223 | &dash-ent-16; | 239 | &dash-ent-24; |
224 | <entry>0</entry> | 240 | <entry>0</entry> |
225 | <entry>r<subscript>4</subscript></entry> | 241 | <entry>r<subscript>4</subscript></entry> |
226 | <entry>r<subscript>3</subscript></entry> | 242 | <entry>r<subscript>3</subscript></entry> |
@@ -234,7 +250,7 @@ | |||
234 | <entry></entry> | 250 | <entry></entry> |
235 | <entry></entry> | 251 | <entry></entry> |
236 | <entry></entry> | 252 | <entry></entry> |
237 | &dash-ent-16; | 253 | &dash-ent-24; |
238 | <entry>g<subscript>2</subscript></entry> | 254 | <entry>g<subscript>2</subscript></entry> |
239 | <entry>g<subscript>1</subscript></entry> | 255 | <entry>g<subscript>1</subscript></entry> |
240 | <entry>g<subscript>0</subscript></entry> | 256 | <entry>g<subscript>0</subscript></entry> |
@@ -248,7 +264,7 @@ | |||
248 | <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE</entry> | 264 | <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE</entry> |
249 | <entry>0x1004</entry> | 265 | <entry>0x1004</entry> |
250 | <entry></entry> | 266 | <entry></entry> |
251 | &dash-ent-16; | 267 | &dash-ent-24; |
252 | <entry>g<subscript>2</subscript></entry> | 268 | <entry>g<subscript>2</subscript></entry> |
253 | <entry>g<subscript>1</subscript></entry> | 269 | <entry>g<subscript>1</subscript></entry> |
254 | <entry>g<subscript>0</subscript></entry> | 270 | <entry>g<subscript>0</subscript></entry> |
@@ -262,7 +278,7 @@ | |||
262 | <entry></entry> | 278 | <entry></entry> |
263 | <entry></entry> | 279 | <entry></entry> |
264 | <entry></entry> | 280 | <entry></entry> |
265 | &dash-ent-16; | 281 | &dash-ent-24; |
266 | <entry>0</entry> | 282 | <entry>0</entry> |
267 | <entry>r<subscript>4</subscript></entry> | 283 | <entry>r<subscript>4</subscript></entry> |
268 | <entry>r<subscript>3</subscript></entry> | 284 | <entry>r<subscript>3</subscript></entry> |
@@ -276,7 +292,7 @@ | |||
276 | <entry>V4L2_MBUS_FMT_BGR565_2X8_BE</entry> | 292 | <entry>V4L2_MBUS_FMT_BGR565_2X8_BE</entry> |
277 | <entry>0x1005</entry> | 293 | <entry>0x1005</entry> |
278 | <entry></entry> | 294 | <entry></entry> |
279 | &dash-ent-16; | 295 | &dash-ent-24; |
280 | <entry>b<subscript>4</subscript></entry> | 296 | <entry>b<subscript>4</subscript></entry> |
281 | <entry>b<subscript>3</subscript></entry> | 297 | <entry>b<subscript>3</subscript></entry> |
282 | <entry>b<subscript>2</subscript></entry> | 298 | <entry>b<subscript>2</subscript></entry> |
@@ -290,7 +306,7 @@ | |||
290 | <entry></entry> | 306 | <entry></entry> |
291 | <entry></entry> | 307 | <entry></entry> |
292 | <entry></entry> | 308 | <entry></entry> |
293 | &dash-ent-16; | 309 | &dash-ent-24; |
294 | <entry>g<subscript>2</subscript></entry> | 310 | <entry>g<subscript>2</subscript></entry> |
295 | <entry>g<subscript>1</subscript></entry> | 311 | <entry>g<subscript>1</subscript></entry> |
296 | <entry>g<subscript>0</subscript></entry> | 312 | <entry>g<subscript>0</subscript></entry> |
@@ -304,7 +320,7 @@ | |||
304 | <entry>V4L2_MBUS_FMT_BGR565_2X8_LE</entry> | 320 | <entry>V4L2_MBUS_FMT_BGR565_2X8_LE</entry> |
305 | <entry>0x1006</entry> | 321 | <entry>0x1006</entry> |
306 | <entry></entry> | 322 | <entry></entry> |
307 | &dash-ent-16; | 323 | &dash-ent-24; |
308 | <entry>g<subscript>2</subscript></entry> | 324 | <entry>g<subscript>2</subscript></entry> |
309 | <entry>g<subscript>1</subscript></entry> | 325 | <entry>g<subscript>1</subscript></entry> |
310 | <entry>g<subscript>0</subscript></entry> | 326 | <entry>g<subscript>0</subscript></entry> |
@@ -318,7 +334,7 @@ | |||
318 | <entry></entry> | 334 | <entry></entry> |
319 | <entry></entry> | 335 | <entry></entry> |
320 | <entry></entry> | 336 | <entry></entry> |
321 | &dash-ent-16; | 337 | &dash-ent-24; |
322 | <entry>b<subscript>4</subscript></entry> | 338 | <entry>b<subscript>4</subscript></entry> |
323 | <entry>b<subscript>3</subscript></entry> | 339 | <entry>b<subscript>3</subscript></entry> |
324 | <entry>b<subscript>2</subscript></entry> | 340 | <entry>b<subscript>2</subscript></entry> |
@@ -332,7 +348,7 @@ | |||
332 | <entry>V4L2_MBUS_FMT_RGB565_2X8_BE</entry> | 348 | <entry>V4L2_MBUS_FMT_RGB565_2X8_BE</entry> |
333 | <entry>0x1007</entry> | 349 | <entry>0x1007</entry> |
334 | <entry></entry> | 350 | <entry></entry> |
335 | &dash-ent-16; | 351 | &dash-ent-24; |
336 | <entry>r<subscript>4</subscript></entry> | 352 | <entry>r<subscript>4</subscript></entry> |
337 | <entry>r<subscript>3</subscript></entry> | 353 | <entry>r<subscript>3</subscript></entry> |
338 | <entry>r<subscript>2</subscript></entry> | 354 | <entry>r<subscript>2</subscript></entry> |
@@ -346,7 +362,7 @@ | |||
346 | <entry></entry> | 362 | <entry></entry> |
347 | <entry></entry> | 363 | <entry></entry> |
348 | <entry></entry> | 364 | <entry></entry> |
349 | &dash-ent-16; | 365 | &dash-ent-24; |
350 | <entry>g<subscript>2</subscript></entry> | 366 | <entry>g<subscript>2</subscript></entry> |
351 | <entry>g<subscript>1</subscript></entry> | 367 | <entry>g<subscript>1</subscript></entry> |
352 | <entry>g<subscript>0</subscript></entry> | 368 | <entry>g<subscript>0</subscript></entry> |
@@ -360,7 +376,7 @@ | |||
360 | <entry>V4L2_MBUS_FMT_RGB565_2X8_LE</entry> | 376 | <entry>V4L2_MBUS_FMT_RGB565_2X8_LE</entry> |
361 | <entry>0x1008</entry> | 377 | <entry>0x1008</entry> |
362 | <entry></entry> | 378 | <entry></entry> |
363 | &dash-ent-16; | 379 | &dash-ent-24; |
364 | <entry>g<subscript>2</subscript></entry> | 380 | <entry>g<subscript>2</subscript></entry> |
365 | <entry>g<subscript>1</subscript></entry> | 381 | <entry>g<subscript>1</subscript></entry> |
366 | <entry>g<subscript>0</subscript></entry> | 382 | <entry>g<subscript>0</subscript></entry> |
@@ -374,7 +390,7 @@ | |||
374 | <entry></entry> | 390 | <entry></entry> |
375 | <entry></entry> | 391 | <entry></entry> |
376 | <entry></entry> | 392 | <entry></entry> |
377 | &dash-ent-16; | 393 | &dash-ent-24; |
378 | <entry>r<subscript>4</subscript></entry> | 394 | <entry>r<subscript>4</subscript></entry> |
379 | <entry>r<subscript>3</subscript></entry> | 395 | <entry>r<subscript>3</subscript></entry> |
380 | <entry>r<subscript>2</subscript></entry> | 396 | <entry>r<subscript>2</subscript></entry> |
@@ -388,12 +404,7 @@ | |||
388 | <entry>V4L2_MBUS_FMT_RGB666_1X18</entry> | 404 | <entry>V4L2_MBUS_FMT_RGB666_1X18</entry> |
389 | <entry>0x1009</entry> | 405 | <entry>0x1009</entry> |
390 | <entry></entry> | 406 | <entry></entry> |
391 | <entry>-</entry> | 407 | &dash-ent-14; |
392 | <entry>-</entry> | ||
393 | <entry>-</entry> | ||
394 | <entry>-</entry> | ||
395 | <entry>-</entry> | ||
396 | <entry>-</entry> | ||
397 | <entry>r<subscript>5</subscript></entry> | 408 | <entry>r<subscript>5</subscript></entry> |
398 | <entry>r<subscript>4</subscript></entry> | 409 | <entry>r<subscript>4</subscript></entry> |
399 | <entry>r<subscript>3</subscript></entry> | 410 | <entry>r<subscript>3</subscript></entry> |
@@ -417,6 +428,7 @@ | |||
417 | <entry>V4L2_MBUS_FMT_RGB888_1X24</entry> | 428 | <entry>V4L2_MBUS_FMT_RGB888_1X24</entry> |
418 | <entry>0x100a</entry> | 429 | <entry>0x100a</entry> |
419 | <entry></entry> | 430 | <entry></entry> |
431 | &dash-ent-8; | ||
420 | <entry>r<subscript>7</subscript></entry> | 432 | <entry>r<subscript>7</subscript></entry> |
421 | <entry>r<subscript>6</subscript></entry> | 433 | <entry>r<subscript>6</subscript></entry> |
422 | <entry>r<subscript>5</subscript></entry> | 434 | <entry>r<subscript>5</subscript></entry> |
@@ -446,9 +458,7 @@ | |||
446 | <entry>V4L2_MBUS_FMT_RGB888_2X12_BE</entry> | 458 | <entry>V4L2_MBUS_FMT_RGB888_2X12_BE</entry> |
447 | <entry>0x100b</entry> | 459 | <entry>0x100b</entry> |
448 | <entry></entry> | 460 | <entry></entry> |
449 | &dash-ent-10; | 461 | &dash-ent-20; |
450 | <entry>-</entry> | ||
451 | <entry>-</entry> | ||
452 | <entry>r<subscript>7</subscript></entry> | 462 | <entry>r<subscript>7</subscript></entry> |
453 | <entry>r<subscript>6</subscript></entry> | 463 | <entry>r<subscript>6</subscript></entry> |
454 | <entry>r<subscript>5</subscript></entry> | 464 | <entry>r<subscript>5</subscript></entry> |
@@ -466,9 +476,7 @@ | |||
466 | <entry></entry> | 476 | <entry></entry> |
467 | <entry></entry> | 477 | <entry></entry> |
468 | <entry></entry> | 478 | <entry></entry> |
469 | &dash-ent-10; | 479 | &dash-ent-20; |
470 | <entry>-</entry> | ||
471 | <entry>-</entry> | ||
472 | <entry>g<subscript>3</subscript></entry> | 480 | <entry>g<subscript>3</subscript></entry> |
473 | <entry>g<subscript>2</subscript></entry> | 481 | <entry>g<subscript>2</subscript></entry> |
474 | <entry>g<subscript>1</subscript></entry> | 482 | <entry>g<subscript>1</subscript></entry> |
@@ -486,9 +494,7 @@ | |||
486 | <entry>V4L2_MBUS_FMT_RGB888_2X12_LE</entry> | 494 | <entry>V4L2_MBUS_FMT_RGB888_2X12_LE</entry> |
487 | <entry>0x100c</entry> | 495 | <entry>0x100c</entry> |
488 | <entry></entry> | 496 | <entry></entry> |
489 | &dash-ent-10; | 497 | &dash-ent-20; |
490 | <entry>-</entry> | ||
491 | <entry>-</entry> | ||
492 | <entry>g<subscript>3</subscript></entry> | 498 | <entry>g<subscript>3</subscript></entry> |
493 | <entry>g<subscript>2</subscript></entry> | 499 | <entry>g<subscript>2</subscript></entry> |
494 | <entry>g<subscript>1</subscript></entry> | 500 | <entry>g<subscript>1</subscript></entry> |
@@ -506,9 +512,7 @@ | |||
506 | <entry></entry> | 512 | <entry></entry> |
507 | <entry></entry> | 513 | <entry></entry> |
508 | <entry></entry> | 514 | <entry></entry> |
509 | &dash-ent-10; | 515 | &dash-ent-20; |
510 | <entry>-</entry> | ||
511 | <entry>-</entry> | ||
512 | <entry>r<subscript>7</subscript></entry> | 516 | <entry>r<subscript>7</subscript></entry> |
513 | <entry>r<subscript>6</subscript></entry> | 517 | <entry>r<subscript>6</subscript></entry> |
514 | <entry>r<subscript>5</subscript></entry> | 518 | <entry>r<subscript>5</subscript></entry> |
@@ -522,6 +526,43 @@ | |||
522 | <entry>g<subscript>5</subscript></entry> | 526 | <entry>g<subscript>5</subscript></entry> |
523 | <entry>g<subscript>4</subscript></entry> | 527 | <entry>g<subscript>4</subscript></entry> |
524 | </row> | 528 | </row> |
529 | <row id="V4L2-MBUS-FMT-ARGB888-1X32"> | ||
530 | <entry>V4L2_MBUS_FMT_ARGB888_1X32</entry> | ||
531 | <entry>0x100d</entry> | ||
532 | <entry></entry> | ||
533 | <entry>a<subscript>7</subscript></entry> | ||
534 | <entry>a<subscript>6</subscript></entry> | ||
535 | <entry>a<subscript>5</subscript></entry> | ||
536 | <entry>a<subscript>4</subscript></entry> | ||
537 | <entry>a<subscript>3</subscript></entry> | ||
538 | <entry>a<subscript>2</subscript></entry> | ||
539 | <entry>a<subscript>1</subscript></entry> | ||
540 | <entry>a<subscript>0</subscript></entry> | ||
541 | <entry>r<subscript>7</subscript></entry> | ||
542 | <entry>r<subscript>6</subscript></entry> | ||
543 | <entry>r<subscript>5</subscript></entry> | ||
544 | <entry>r<subscript>4</subscript></entry> | ||
545 | <entry>r<subscript>3</subscript></entry> | ||
546 | <entry>r<subscript>2</subscript></entry> | ||
547 | <entry>r<subscript>1</subscript></entry> | ||
548 | <entry>r<subscript>0</subscript></entry> | ||
549 | <entry>g<subscript>7</subscript></entry> | ||
550 | <entry>g<subscript>6</subscript></entry> | ||
551 | <entry>g<subscript>5</subscript></entry> | ||
552 | <entry>g<subscript>4</subscript></entry> | ||
553 | <entry>g<subscript>3</subscript></entry> | ||
554 | <entry>g<subscript>2</subscript></entry> | ||
555 | <entry>g<subscript>1</subscript></entry> | ||
556 | <entry>g<subscript>0</subscript></entry> | ||
557 | <entry>b<subscript>7</subscript></entry> | ||
558 | <entry>b<subscript>6</subscript></entry> | ||
559 | <entry>b<subscript>5</subscript></entry> | ||
560 | <entry>b<subscript>4</subscript></entry> | ||
561 | <entry>b<subscript>3</subscript></entry> | ||
562 | <entry>b<subscript>2</subscript></entry> | ||
563 | <entry>b<subscript>1</subscript></entry> | ||
564 | <entry>b<subscript>0</subscript></entry> | ||
565 | </row> | ||
525 | </tbody> | 566 | </tbody> |
526 | </tgroup> | 567 | </tgroup> |
527 | </table> | 568 | </table> |
@@ -1149,6 +1190,7 @@ | |||
1149 | <listitem><para>y<subscript>x</subscript> for luma component bit number x</para></listitem> | 1190 | <listitem><para>y<subscript>x</subscript> for luma component bit number x</para></listitem> |
1150 | <listitem><para>u<subscript>x</subscript> for blue chroma component bit number x</para></listitem> | 1191 | <listitem><para>u<subscript>x</subscript> for blue chroma component bit number x</para></listitem> |
1151 | <listitem><para>v<subscript>x</subscript> for red chroma component bit number x</para></listitem> | 1192 | <listitem><para>v<subscript>x</subscript> for red chroma component bit number x</para></listitem> |
1193 | <listitem><para>a<subscript>x</subscript> for alpha component bit number x</para></listitem> | ||
1152 | <listitem><para>- for non-available bits (for positions higher than the bus width)</para></listitem> | 1194 | <listitem><para>- for non-available bits (for positions higher than the bus width)</para></listitem> |
1153 | <listitem><para>d for dummy bits</para></listitem> | 1195 | <listitem><para>d for dummy bits</para></listitem> |
1154 | </itemizedlist> | 1196 | </itemizedlist> |
@@ -1159,37 +1201,39 @@ | |||
1159 | <colspec colname="id" align="left" /> | 1201 | <colspec colname="id" align="left" /> |
1160 | <colspec colname="code" align="center"/> | 1202 | <colspec colname="code" align="center"/> |
1161 | <colspec colname="bit" /> | 1203 | <colspec colname="bit" /> |
1162 | <colspec colnum="4" colname="b29" align="center" /> | 1204 | <colspec colnum="4" colname="b31" align="center" /> |
1163 | <colspec colnum="5" colname="b28" align="center" /> | 1205 | <colspec colnum="5" colname="b20" align="center" /> |
1164 | <colspec colnum="6" colname="b27" align="center" /> | 1206 | <colspec colnum="6" colname="b29" align="center" /> |
1165 | <colspec colnum="7" colname="b26" align="center" /> | 1207 | <colspec colnum="7" colname="b28" align="center" /> |
1166 | <colspec colnum="8" colname="b25" align="center" /> | 1208 | <colspec colnum="8" colname="b27" align="center" /> |
1167 | <colspec colnum="9" colname="b24" align="center" /> | 1209 | <colspec colnum="9" colname="b26" align="center" /> |
1168 | <colspec colnum="10" colname="b23" align="center" /> | 1210 | <colspec colnum="10" colname="b25" align="center" /> |
1169 | <colspec colnum="11" colname="b22" align="center" /> | 1211 | <colspec colnum="11" colname="b24" align="center" /> |
1170 | <colspec colnum="12" colname="b21" align="center" /> | 1212 | <colspec colnum="12" colname="b23" align="center" /> |
1171 | <colspec colnum="13" colname="b20" align="center" /> | 1213 | <colspec colnum="13" colname="b22" align="center" /> |
1172 | <colspec colnum="14" colname="b19" align="center" /> | 1214 | <colspec colnum="14" colname="b21" align="center" /> |
1173 | <colspec colnum="15" colname="b18" align="center" /> | 1215 | <colspec colnum="15" colname="b20" align="center" /> |
1174 | <colspec colnum="16" colname="b17" align="center" /> | 1216 | <colspec colnum="16" colname="b19" align="center" /> |
1175 | <colspec colnum="17" colname="b16" align="center" /> | 1217 | <colspec colnum="17" colname="b18" align="center" /> |
1176 | <colspec colnum="18" colname="b15" align="center" /> | 1218 | <colspec colnum="18" colname="b17" align="center" /> |
1177 | <colspec colnum="19" colname="b14" align="center" /> | 1219 | <colspec colnum="19" colname="b16" align="center" /> |
1178 | <colspec colnum="20" colname="b13" align="center" /> | 1220 | <colspec colnum="20" colname="b15" align="center" /> |
1179 | <colspec colnum="21" colname="b12" align="center" /> | 1221 | <colspec colnum="21" colname="b14" align="center" /> |
1180 | <colspec colnum="22" colname="b11" align="center" /> | 1222 | <colspec colnum="22" colname="b13" align="center" /> |
1181 | <colspec colnum="23" colname="b10" align="center" /> | 1223 | <colspec colnum="23" colname="b12" align="center" /> |
1182 | <colspec colnum="24" colname="b09" align="center" /> | 1224 | <colspec colnum="24" colname="b11" align="center" /> |
1183 | <colspec colnum="25" colname="b08" align="center" /> | 1225 | <colspec colnum="25" colname="b10" align="center" /> |
1184 | <colspec colnum="26" colname="b07" align="center" /> | 1226 | <colspec colnum="26" colname="b09" align="center" /> |
1185 | <colspec colnum="27" colname="b06" align="center" /> | 1227 | <colspec colnum="27" colname="b08" align="center" /> |
1186 | <colspec colnum="28" colname="b05" align="center" /> | 1228 | <colspec colnum="28" colname="b07" align="center" /> |
1187 | <colspec colnum="29" colname="b04" align="center" /> | 1229 | <colspec colnum="29" colname="b06" align="center" /> |
1188 | <colspec colnum="30" colname="b03" align="center" /> | 1230 | <colspec colnum="30" colname="b05" align="center" /> |
1189 | <colspec colnum="31" colname="b02" align="center" /> | 1231 | <colspec colnum="31" colname="b04" align="center" /> |
1190 | <colspec colnum="32" colname="b01" align="center" /> | 1232 | <colspec colnum="32" colname="b03" align="center" /> |
1191 | <colspec colnum="33" colname="b00" align="center" /> | 1233 | <colspec colnum="33" colname="b02" align="center" /> |
1192 | <spanspec namest="b29" nameend="b00" spanname="b0" /> | 1234 | <colspec colnum="34" colname="b01" align="center" /> |
1235 | <colspec colnum="35" colname="b00" align="center" /> | ||
1236 | <spanspec namest="b31" nameend="b00" spanname="b0" /> | ||
1193 | <thead> | 1237 | <thead> |
1194 | <row> | 1238 | <row> |
1195 | <entry>Identifier</entry> | 1239 | <entry>Identifier</entry> |
@@ -1201,6 +1245,8 @@ | |||
1201 | <entry></entry> | 1245 | <entry></entry> |
1202 | <entry></entry> | 1246 | <entry></entry> |
1203 | <entry>Bit</entry> | 1247 | <entry>Bit</entry> |
1248 | <entry>31</entry> | ||
1249 | <entry>30</entry> | ||
1204 | <entry>29</entry> | 1250 | <entry>29</entry> |
1205 | <entry>28</entry> | 1251 | <entry>28</entry> |
1206 | <entry>27</entry> | 1252 | <entry>27</entry> |
@@ -1238,10 +1284,7 @@ | |||
1238 | <entry>V4L2_MBUS_FMT_Y8_1X8</entry> | 1284 | <entry>V4L2_MBUS_FMT_Y8_1X8</entry> |
1239 | <entry>0x2001</entry> | 1285 | <entry>0x2001</entry> |
1240 | <entry></entry> | 1286 | <entry></entry> |
1241 | &dash-ent-10; | 1287 | &dash-ent-24; |
1242 | &dash-ent-10; | ||
1243 | <entry>-</entry> | ||
1244 | <entry>-</entry> | ||
1245 | <entry>y<subscript>7</subscript></entry> | 1288 | <entry>y<subscript>7</subscript></entry> |
1246 | <entry>y<subscript>6</subscript></entry> | 1289 | <entry>y<subscript>6</subscript></entry> |
1247 | <entry>y<subscript>5</subscript></entry> | 1290 | <entry>y<subscript>5</subscript></entry> |
@@ -1255,18 +1298,7 @@ | |||
1255 | <entry>V4L2_MBUS_FMT_UV8_1X8</entry> | 1298 | <entry>V4L2_MBUS_FMT_UV8_1X8</entry> |
1256 | <entry>0x2015</entry> | 1299 | <entry>0x2015</entry> |
1257 | <entry></entry> | 1300 | <entry></entry> |
1258 | <entry>-</entry> | 1301 | &dash-ent-24; |
1259 | <entry>-</entry> | ||
1260 | <entry>-</entry> | ||
1261 | <entry>-</entry> | ||
1262 | <entry>-</entry> | ||
1263 | <entry>-</entry> | ||
1264 | <entry>-</entry> | ||
1265 | <entry>-</entry> | ||
1266 | <entry>-</entry> | ||
1267 | <entry>-</entry> | ||
1268 | <entry>-</entry> | ||
1269 | <entry>-</entry> | ||
1270 | <entry>u<subscript>7</subscript></entry> | 1302 | <entry>u<subscript>7</subscript></entry> |
1271 | <entry>u<subscript>6</subscript></entry> | 1303 | <entry>u<subscript>6</subscript></entry> |
1272 | <entry>u<subscript>5</subscript></entry> | 1304 | <entry>u<subscript>5</subscript></entry> |
@@ -1280,18 +1312,7 @@ | |||
1280 | <entry></entry> | 1312 | <entry></entry> |
1281 | <entry></entry> | 1313 | <entry></entry> |
1282 | <entry></entry> | 1314 | <entry></entry> |
1283 | <entry>-</entry> | 1315 | &dash-ent-24; |
1284 | <entry>-</entry> | ||
1285 | <entry>-</entry> | ||
1286 | <entry>-</entry> | ||
1287 | <entry>-</entry> | ||
1288 | <entry>-</entry> | ||
1289 | <entry>-</entry> | ||
1290 | <entry>-</entry> | ||
1291 | <entry>-</entry> | ||
1292 | <entry>-</entry> | ||
1293 | <entry>-</entry> | ||
1294 | <entry>-</entry> | ||
1295 | <entry>v<subscript>7</subscript></entry> | 1316 | <entry>v<subscript>7</subscript></entry> |
1296 | <entry>v<subscript>6</subscript></entry> | 1317 | <entry>v<subscript>6</subscript></entry> |
1297 | <entry>v<subscript>5</subscript></entry> | 1318 | <entry>v<subscript>5</subscript></entry> |
@@ -1305,10 +1326,7 @@ | |||
1305 | <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry> | 1326 | <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry> |
1306 | <entry>0x2002</entry> | 1327 | <entry>0x2002</entry> |
1307 | <entry></entry> | 1328 | <entry></entry> |
1308 | &dash-ent-10; | 1329 | &dash-ent-24; |
1309 | &dash-ent-10; | ||
1310 | <entry>-</entry> | ||
1311 | <entry>-</entry> | ||
1312 | <entry>u<subscript>7</subscript></entry> | 1330 | <entry>u<subscript>7</subscript></entry> |
1313 | <entry>u<subscript>6</subscript></entry> | 1331 | <entry>u<subscript>6</subscript></entry> |
1314 | <entry>u<subscript>5</subscript></entry> | 1332 | <entry>u<subscript>5</subscript></entry> |
@@ -1322,10 +1340,7 @@ | |||
1322 | <entry></entry> | 1340 | <entry></entry> |
1323 | <entry></entry> | 1341 | <entry></entry> |
1324 | <entry></entry> | 1342 | <entry></entry> |
1325 | &dash-ent-10; | 1343 | &dash-ent-24; |
1326 | &dash-ent-10; | ||
1327 | <entry>-</entry> | ||
1328 | <entry>-</entry> | ||
1329 | <entry>y<subscript>7</subscript></entry> | 1344 | <entry>y<subscript>7</subscript></entry> |
1330 | <entry>y<subscript>6</subscript></entry> | 1345 | <entry>y<subscript>6</subscript></entry> |
1331 | <entry>y<subscript>5</subscript></entry> | 1346 | <entry>y<subscript>5</subscript></entry> |
@@ -1339,10 +1354,7 @@ | |||
1339 | <entry></entry> | 1354 | <entry></entry> |
1340 | <entry></entry> | 1355 | <entry></entry> |
1341 | <entry></entry> | 1356 | <entry></entry> |
1342 | &dash-ent-10; | 1357 | &dash-ent-24; |
1343 | &dash-ent-10; | ||
1344 | <entry>-</entry> | ||
1345 | <entry>-</entry> | ||
1346 | <entry>y<subscript>7</subscript></entry> | 1358 | <entry>y<subscript>7</subscript></entry> |
1347 | <entry>y<subscript>6</subscript></entry> | 1359 | <entry>y<subscript>6</subscript></entry> |
1348 | <entry>y<subscript>5</subscript></entry> | 1360 | <entry>y<subscript>5</subscript></entry> |
@@ -1356,10 +1368,7 @@ | |||
1356 | <entry></entry> | 1368 | <entry></entry> |
1357 | <entry></entry> | 1369 | <entry></entry> |
1358 | <entry></entry> | 1370 | <entry></entry> |
1359 | &dash-ent-10; | 1371 | &dash-ent-24; |
1360 | &dash-ent-10; | ||
1361 | <entry>-</entry> | ||
1362 | <entry>-</entry> | ||
1363 | <entry>v<subscript>7</subscript></entry> | 1372 | <entry>v<subscript>7</subscript></entry> |
1364 | <entry>v<subscript>6</subscript></entry> | 1373 | <entry>v<subscript>6</subscript></entry> |
1365 | <entry>v<subscript>5</subscript></entry> | 1374 | <entry>v<subscript>5</subscript></entry> |
@@ -1373,10 +1382,7 @@ | |||
1373 | <entry></entry> | 1382 | <entry></entry> |
1374 | <entry></entry> | 1383 | <entry></entry> |
1375 | <entry></entry> | 1384 | <entry></entry> |
1376 | &dash-ent-10; | 1385 | &dash-ent-24; |
1377 | &dash-ent-10; | ||
1378 | <entry>-</entry> | ||
1379 | <entry>-</entry> | ||
1380 | <entry>y<subscript>7</subscript></entry> | 1386 | <entry>y<subscript>7</subscript></entry> |
1381 | <entry>y<subscript>6</subscript></entry> | 1387 | <entry>y<subscript>6</subscript></entry> |
1382 | <entry>y<subscript>5</subscript></entry> | 1388 | <entry>y<subscript>5</subscript></entry> |
@@ -1390,10 +1396,7 @@ | |||
1390 | <entry></entry> | 1396 | <entry></entry> |
1391 | <entry></entry> | 1397 | <entry></entry> |
1392 | <entry></entry> | 1398 | <entry></entry> |
1393 | &dash-ent-10; | 1399 | &dash-ent-24; |
1394 | &dash-ent-10; | ||
1395 | <entry>-</entry> | ||
1396 | <entry>-</entry> | ||
1397 | <entry>y<subscript>7</subscript></entry> | 1400 | <entry>y<subscript>7</subscript></entry> |
1398 | <entry>y<subscript>6</subscript></entry> | 1401 | <entry>y<subscript>6</subscript></entry> |
1399 | <entry>y<subscript>5</subscript></entry> | 1402 | <entry>y<subscript>5</subscript></entry> |
@@ -1407,10 +1410,7 @@ | |||
1407 | <entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry> | 1410 | <entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry> |
1408 | <entry>0x2003</entry> | 1411 | <entry>0x2003</entry> |
1409 | <entry></entry> | 1412 | <entry></entry> |
1410 | &dash-ent-10; | 1413 | &dash-ent-24; |
1411 | &dash-ent-10; | ||
1412 | <entry>-</entry> | ||
1413 | <entry>-</entry> | ||
1414 | <entry>v<subscript>7</subscript></entry> | 1414 | <entry>v<subscript>7</subscript></entry> |
1415 | <entry>v<subscript>6</subscript></entry> | 1415 | <entry>v<subscript>6</subscript></entry> |
1416 | <entry>v<subscript>5</subscript></entry> | 1416 | <entry>v<subscript>5</subscript></entry> |
@@ -1424,10 +1424,7 @@ | |||
1424 | <entry></entry> | 1424 | <entry></entry> |
1425 | <entry></entry> | 1425 | <entry></entry> |
1426 | <entry></entry> | 1426 | <entry></entry> |
1427 | &dash-ent-10; | 1427 | &dash-ent-24; |
1428 | &dash-ent-10; | ||
1429 | <entry>-</entry> | ||
1430 | <entry>-</entry> | ||
1431 | <entry>y<subscript>7</subscript></entry> | 1428 | <entry>y<subscript>7</subscript></entry> |
1432 | <entry>y<subscript>6</subscript></entry> | 1429 | <entry>y<subscript>6</subscript></entry> |
1433 | <entry>y<subscript>5</subscript></entry> | 1430 | <entry>y<subscript>5</subscript></entry> |
@@ -1441,10 +1438,7 @@ | |||
1441 | <entry></entry> | 1438 | <entry></entry> |
1442 | <entry></entry> | 1439 | <entry></entry> |
1443 | <entry></entry> | 1440 | <entry></entry> |
1444 | &dash-ent-10; | 1441 | &dash-ent-24; |
1445 | &dash-ent-10; | ||
1446 | <entry>-</entry> | ||
1447 | <entry>-</entry> | ||
1448 | <entry>y<subscript>7</subscript></entry> | 1442 | <entry>y<subscript>7</subscript></entry> |
1449 | <entry>y<subscript>6</subscript></entry> | 1443 | <entry>y<subscript>6</subscript></entry> |
1450 | <entry>y<subscript>5</subscript></entry> | 1444 | <entry>y<subscript>5</subscript></entry> |
@@ -1458,10 +1452,7 @@ | |||
1458 | <entry></entry> | 1452 | <entry></entry> |
1459 | <entry></entry> | 1453 | <entry></entry> |
1460 | <entry></entry> | 1454 | <entry></entry> |
1461 | &dash-ent-10; | 1455 | &dash-ent-24; |
1462 | &dash-ent-10; | ||
1463 | <entry>-</entry> | ||
1464 | <entry>-</entry> | ||
1465 | <entry>u<subscript>7</subscript></entry> | 1456 | <entry>u<subscript>7</subscript></entry> |
1466 | <entry>u<subscript>6</subscript></entry> | 1457 | <entry>u<subscript>6</subscript></entry> |
1467 | <entry>u<subscript>5</subscript></entry> | 1458 | <entry>u<subscript>5</subscript></entry> |
@@ -1475,10 +1466,7 @@ | |||
1475 | <entry></entry> | 1466 | <entry></entry> |
1476 | <entry></entry> | 1467 | <entry></entry> |
1477 | <entry></entry> | 1468 | <entry></entry> |
1478 | &dash-ent-10; | 1469 | &dash-ent-24; |
1479 | &dash-ent-10; | ||
1480 | <entry>-</entry> | ||
1481 | <entry>-</entry> | ||
1482 | <entry>y<subscript>7</subscript></entry> | 1470 | <entry>y<subscript>7</subscript></entry> |
1483 | <entry>y<subscript>6</subscript></entry> | 1471 | <entry>y<subscript>6</subscript></entry> |
1484 | <entry>y<subscript>5</subscript></entry> | 1472 | <entry>y<subscript>5</subscript></entry> |
@@ -1492,10 +1480,7 @@ | |||
1492 | <entry></entry> | 1480 | <entry></entry> |
1493 | <entry></entry> | 1481 | <entry></entry> |
1494 | <entry></entry> | 1482 | <entry></entry> |
1495 | &dash-ent-10; | 1483 | &dash-ent-24; |
1496 | &dash-ent-10; | ||
1497 | <entry>-</entry> | ||
1498 | <entry>-</entry> | ||
1499 | <entry>y<subscript>7</subscript></entry> | 1484 | <entry>y<subscript>7</subscript></entry> |
1500 | <entry>y<subscript>6</subscript></entry> | 1485 | <entry>y<subscript>6</subscript></entry> |
1501 | <entry>y<subscript>5</subscript></entry> | 1486 | <entry>y<subscript>5</subscript></entry> |
@@ -1509,10 +1494,7 @@ | |||
1509 | <entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry> | 1494 | <entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry> |
1510 | <entry>0x2004</entry> | 1495 | <entry>0x2004</entry> |
1511 | <entry></entry> | 1496 | <entry></entry> |
1512 | &dash-ent-10; | 1497 | &dash-ent-24; |
1513 | &dash-ent-10; | ||
1514 | <entry>-</entry> | ||
1515 | <entry>-</entry> | ||
1516 | <entry>y<subscript>7</subscript></entry> | 1498 | <entry>y<subscript>7</subscript></entry> |
1517 | <entry>y<subscript>6</subscript></entry> | 1499 | <entry>y<subscript>6</subscript></entry> |
1518 | <entry>y<subscript>5</subscript></entry> | 1500 | <entry>y<subscript>5</subscript></entry> |
@@ -1526,10 +1508,7 @@ | |||
1526 | <entry></entry> | 1508 | <entry></entry> |
1527 | <entry></entry> | 1509 | <entry></entry> |
1528 | <entry></entry> | 1510 | <entry></entry> |
1529 | &dash-ent-10; | 1511 | &dash-ent-24; |
1530 | &dash-ent-10; | ||
1531 | <entry>-</entry> | ||
1532 | <entry>-</entry> | ||
1533 | <entry>y<subscript>7</subscript></entry> | 1512 | <entry>y<subscript>7</subscript></entry> |
1534 | <entry>y<subscript>6</subscript></entry> | 1513 | <entry>y<subscript>6</subscript></entry> |
1535 | <entry>y<subscript>5</subscript></entry> | 1514 | <entry>y<subscript>5</subscript></entry> |
@@ -1543,10 +1522,7 @@ | |||
1543 | <entry></entry> | 1522 | <entry></entry> |
1544 | <entry></entry> | 1523 | <entry></entry> |
1545 | <entry></entry> | 1524 | <entry></entry> |
1546 | &dash-ent-10; | 1525 | &dash-ent-24; |
1547 | &dash-ent-10; | ||
1548 | <entry>-</entry> | ||
1549 | <entry>-</entry> | ||
1550 | <entry>u<subscript>7</subscript></entry> | 1526 | <entry>u<subscript>7</subscript></entry> |
1551 | <entry>u<subscript>6</subscript></entry> | 1527 | <entry>u<subscript>6</subscript></entry> |
1552 | <entry>u<subscript>5</subscript></entry> | 1528 | <entry>u<subscript>5</subscript></entry> |
@@ -1560,10 +1536,7 @@ | |||
1560 | <entry></entry> | 1536 | <entry></entry> |
1561 | <entry></entry> | 1537 | <entry></entry> |
1562 | <entry></entry> | 1538 | <entry></entry> |
1563 | &dash-ent-10; | 1539 | &dash-ent-24; |
1564 | &dash-ent-10; | ||
1565 | <entry>-</entry> | ||
1566 | <entry>-</entry> | ||
1567 | <entry>y<subscript>7</subscript></entry> | 1540 | <entry>y<subscript>7</subscript></entry> |
1568 | <entry>y<subscript>6</subscript></entry> | 1541 | <entry>y<subscript>6</subscript></entry> |
1569 | <entry>y<subscript>5</subscript></entry> | 1542 | <entry>y<subscript>5</subscript></entry> |
@@ -1577,10 +1550,7 @@ | |||
1577 | <entry></entry> | 1550 | <entry></entry> |
1578 | <entry></entry> | 1551 | <entry></entry> |
1579 | <entry></entry> | 1552 | <entry></entry> |
1580 | &dash-ent-10; | 1553 | &dash-ent-24; |
1581 | &dash-ent-10; | ||
1582 | <entry>-</entry> | ||
1583 | <entry>-</entry> | ||
1584 | <entry>y<subscript>7</subscript></entry> | 1554 | <entry>y<subscript>7</subscript></entry> |
1585 | <entry>y<subscript>6</subscript></entry> | 1555 | <entry>y<subscript>6</subscript></entry> |
1586 | <entry>y<subscript>5</subscript></entry> | 1556 | <entry>y<subscript>5</subscript></entry> |
@@ -1594,10 +1564,7 @@ | |||
1594 | <entry></entry> | 1564 | <entry></entry> |
1595 | <entry></entry> | 1565 | <entry></entry> |
1596 | <entry></entry> | 1566 | <entry></entry> |
1597 | &dash-ent-10; | 1567 | &dash-ent-24; |
1598 | &dash-ent-10; | ||
1599 | <entry>-</entry> | ||
1600 | <entry>-</entry> | ||
1601 | <entry>v<subscript>7</subscript></entry> | 1568 | <entry>v<subscript>7</subscript></entry> |
1602 | <entry>v<subscript>6</subscript></entry> | 1569 | <entry>v<subscript>6</subscript></entry> |
1603 | <entry>v<subscript>5</subscript></entry> | 1570 | <entry>v<subscript>5</subscript></entry> |
@@ -1611,10 +1578,7 @@ | |||
1611 | <entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry> | 1578 | <entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry> |
1612 | <entry>0x2005</entry> | 1579 | <entry>0x2005</entry> |
1613 | <entry></entry> | 1580 | <entry></entry> |
1614 | &dash-ent-10; | 1581 | &dash-ent-24; |
1615 | &dash-ent-10; | ||
1616 | <entry>-</entry> | ||
1617 | <entry>-</entry> | ||
1618 | <entry>y<subscript>7</subscript></entry> | 1582 | <entry>y<subscript>7</subscript></entry> |
1619 | <entry>y<subscript>6</subscript></entry> | 1583 | <entry>y<subscript>6</subscript></entry> |
1620 | <entry>y<subscript>5</subscript></entry> | 1584 | <entry>y<subscript>5</subscript></entry> |
@@ -1628,10 +1592,7 @@ | |||
1628 | <entry></entry> | 1592 | <entry></entry> |
1629 | <entry></entry> | 1593 | <entry></entry> |
1630 | <entry></entry> | 1594 | <entry></entry> |
1631 | &dash-ent-10; | 1595 | &dash-ent-24; |
1632 | &dash-ent-10; | ||
1633 | <entry>-</entry> | ||
1634 | <entry>-</entry> | ||
1635 | <entry>y<subscript>7</subscript></entry> | 1596 | <entry>y<subscript>7</subscript></entry> |
1636 | <entry>y<subscript>6</subscript></entry> | 1597 | <entry>y<subscript>6</subscript></entry> |
1637 | <entry>y<subscript>5</subscript></entry> | 1598 | <entry>y<subscript>5</subscript></entry> |
@@ -1645,10 +1606,7 @@ | |||
1645 | <entry></entry> | 1606 | <entry></entry> |
1646 | <entry></entry> | 1607 | <entry></entry> |
1647 | <entry></entry> | 1608 | <entry></entry> |
1648 | &dash-ent-10; | 1609 | &dash-ent-24; |
1649 | &dash-ent-10; | ||
1650 | <entry>-</entry> | ||
1651 | <entry>-</entry> | ||
1652 | <entry>v<subscript>7</subscript></entry> | 1610 | <entry>v<subscript>7</subscript></entry> |
1653 | <entry>v<subscript>6</subscript></entry> | 1611 | <entry>v<subscript>6</subscript></entry> |
1654 | <entry>v<subscript>5</subscript></entry> | 1612 | <entry>v<subscript>5</subscript></entry> |
@@ -1662,10 +1620,7 @@ | |||
1662 | <entry></entry> | 1620 | <entry></entry> |
1663 | <entry></entry> | 1621 | <entry></entry> |
1664 | <entry></entry> | 1622 | <entry></entry> |
1665 | &dash-ent-10; | 1623 | &dash-ent-24; |
1666 | &dash-ent-10; | ||
1667 | <entry>-</entry> | ||
1668 | <entry>-</entry> | ||
1669 | <entry>y<subscript>7</subscript></entry> | 1624 | <entry>y<subscript>7</subscript></entry> |
1670 | <entry>y<subscript>6</subscript></entry> | 1625 | <entry>y<subscript>6</subscript></entry> |
1671 | <entry>y<subscript>5</subscript></entry> | 1626 | <entry>y<subscript>5</subscript></entry> |
@@ -1679,10 +1634,7 @@ | |||
1679 | <entry></entry> | 1634 | <entry></entry> |
1680 | <entry></entry> | 1635 | <entry></entry> |
1681 | <entry></entry> | 1636 | <entry></entry> |
1682 | &dash-ent-10; | 1637 | &dash-ent-24; |
1683 | &dash-ent-10; | ||
1684 | <entry>-</entry> | ||
1685 | <entry>-</entry> | ||
1686 | <entry>y<subscript>7</subscript></entry> | 1638 | <entry>y<subscript>7</subscript></entry> |
1687 | <entry>y<subscript>6</subscript></entry> | 1639 | <entry>y<subscript>6</subscript></entry> |
1688 | <entry>y<subscript>5</subscript></entry> | 1640 | <entry>y<subscript>5</subscript></entry> |
@@ -1696,10 +1648,7 @@ | |||
1696 | <entry></entry> | 1648 | <entry></entry> |
1697 | <entry></entry> | 1649 | <entry></entry> |
1698 | <entry></entry> | 1650 | <entry></entry> |
1699 | &dash-ent-10; | 1651 | &dash-ent-24; |
1700 | &dash-ent-10; | ||
1701 | <entry>-</entry> | ||
1702 | <entry>-</entry> | ||
1703 | <entry>u<subscript>7</subscript></entry> | 1652 | <entry>u<subscript>7</subscript></entry> |
1704 | <entry>u<subscript>6</subscript></entry> | 1653 | <entry>u<subscript>6</subscript></entry> |
1705 | <entry>u<subscript>5</subscript></entry> | 1654 | <entry>u<subscript>5</subscript></entry> |
@@ -1713,10 +1662,7 @@ | |||
1713 | <entry>V4L2_MBUS_FMT_UYVY8_2X8</entry> | 1662 | <entry>V4L2_MBUS_FMT_UYVY8_2X8</entry> |
1714 | <entry>0x2006</entry> | 1663 | <entry>0x2006</entry> |
1715 | <entry></entry> | 1664 | <entry></entry> |
1716 | &dash-ent-10; | 1665 | &dash-ent-24; |
1717 | &dash-ent-10; | ||
1718 | <entry>-</entry> | ||
1719 | <entry>-</entry> | ||
1720 | <entry>u<subscript>7</subscript></entry> | 1666 | <entry>u<subscript>7</subscript></entry> |
1721 | <entry>u<subscript>6</subscript></entry> | 1667 | <entry>u<subscript>6</subscript></entry> |
1722 | <entry>u<subscript>5</subscript></entry> | 1668 | <entry>u<subscript>5</subscript></entry> |
@@ -1730,10 +1676,7 @@ | |||
1730 | <entry></entry> | 1676 | <entry></entry> |
1731 | <entry></entry> | 1677 | <entry></entry> |
1732 | <entry></entry> | 1678 | <entry></entry> |
1733 | &dash-ent-10; | 1679 | &dash-ent-24; |
1734 | &dash-ent-10; | ||
1735 | <entry>-</entry> | ||
1736 | <entry>-</entry> | ||
1737 | <entry>y<subscript>7</subscript></entry> | 1680 | <entry>y<subscript>7</subscript></entry> |
1738 | <entry>y<subscript>6</subscript></entry> | 1681 | <entry>y<subscript>6</subscript></entry> |
1739 | <entry>y<subscript>5</subscript></entry> | 1682 | <entry>y<subscript>5</subscript></entry> |
@@ -1747,10 +1690,7 @@ | |||
1747 | <entry></entry> | 1690 | <entry></entry> |
1748 | <entry></entry> | 1691 | <entry></entry> |
1749 | <entry></entry> | 1692 | <entry></entry> |
1750 | &dash-ent-10; | 1693 | &dash-ent-24; |
1751 | &dash-ent-10; | ||
1752 | <entry>-</entry> | ||
1753 | <entry>-</entry> | ||
1754 | <entry>v<subscript>7</subscript></entry> | 1694 | <entry>v<subscript>7</subscript></entry> |
1755 | <entry>v<subscript>6</subscript></entry> | 1695 | <entry>v<subscript>6</subscript></entry> |
1756 | <entry>v<subscript>5</subscript></entry> | 1696 | <entry>v<subscript>5</subscript></entry> |
@@ -1764,10 +1704,7 @@ | |||
1764 | <entry></entry> | 1704 | <entry></entry> |
1765 | <entry></entry> | 1705 | <entry></entry> |
1766 | <entry></entry> | 1706 | <entry></entry> |
1767 | &dash-ent-10; | 1707 | &dash-ent-24; |
1768 | &dash-ent-10; | ||
1769 | <entry>-</entry> | ||
1770 | <entry>-</entry> | ||
1771 | <entry>y<subscript>7</subscript></entry> | 1708 | <entry>y<subscript>7</subscript></entry> |
1772 | <entry>y<subscript>6</subscript></entry> | 1709 | <entry>y<subscript>6</subscript></entry> |
1773 | <entry>y<subscript>5</subscript></entry> | 1710 | <entry>y<subscript>5</subscript></entry> |
@@ -1781,10 +1718,7 @@ | |||
1781 | <entry>V4L2_MBUS_FMT_VYUY8_2X8</entry> | 1718 | <entry>V4L2_MBUS_FMT_VYUY8_2X8</entry> |
1782 | <entry>0x2007</entry> | 1719 | <entry>0x2007</entry> |
1783 | <entry></entry> | 1720 | <entry></entry> |
1784 | &dash-ent-10; | 1721 | &dash-ent-24; |
1785 | &dash-ent-10; | ||
1786 | <entry>-</entry> | ||
1787 | <entry>-</entry> | ||
1788 | <entry>v<subscript>7</subscript></entry> | 1722 | <entry>v<subscript>7</subscript></entry> |
1789 | <entry>v<subscript>6</subscript></entry> | 1723 | <entry>v<subscript>6</subscript></entry> |
1790 | <entry>v<subscript>5</subscript></entry> | 1724 | <entry>v<subscript>5</subscript></entry> |
@@ -1798,10 +1732,7 @@ | |||
1798 | <entry></entry> | 1732 | <entry></entry> |
1799 | <entry></entry> | 1733 | <entry></entry> |
1800 | <entry></entry> | 1734 | <entry></entry> |
1801 | &dash-ent-10; | 1735 | &dash-ent-24; |
1802 | &dash-ent-10; | ||
1803 | <entry>-</entry> | ||
1804 | <entry>-</entry> | ||
1805 | <entry>y<subscript>7</subscript></entry> | 1736 | <entry>y<subscript>7</subscript></entry> |
1806 | <entry>y<subscript>6</subscript></entry> | 1737 | <entry>y<subscript>6</subscript></entry> |
1807 | <entry>y<subscript>5</subscript></entry> | 1738 | <entry>y<subscript>5</subscript></entry> |
@@ -1815,10 +1746,7 @@ | |||
1815 | <entry></entry> | 1746 | <entry></entry> |
1816 | <entry></entry> | 1747 | <entry></entry> |
1817 | <entry></entry> | 1748 | <entry></entry> |
1818 | &dash-ent-10; | 1749 | &dash-ent-24; |
1819 | &dash-ent-10; | ||
1820 | <entry>-</entry> | ||
1821 | <entry>-</entry> | ||
1822 | <entry>u<subscript>7</subscript></entry> | 1750 | <entry>u<subscript>7</subscript></entry> |
1823 | <entry>u<subscript>6</subscript></entry> | 1751 | <entry>u<subscript>6</subscript></entry> |
1824 | <entry>u<subscript>5</subscript></entry> | 1752 | <entry>u<subscript>5</subscript></entry> |
@@ -1832,10 +1760,7 @@ | |||
1832 | <entry></entry> | 1760 | <entry></entry> |
1833 | <entry></entry> | 1761 | <entry></entry> |
1834 | <entry></entry> | 1762 | <entry></entry> |
1835 | &dash-ent-10; | 1763 | &dash-ent-24; |
1836 | &dash-ent-10; | ||
1837 | <entry>-</entry> | ||
1838 | <entry>-</entry> | ||
1839 | <entry>y<subscript>7</subscript></entry> | 1764 | <entry>y<subscript>7</subscript></entry> |
1840 | <entry>y<subscript>6</subscript></entry> | 1765 | <entry>y<subscript>6</subscript></entry> |
1841 | <entry>y<subscript>5</subscript></entry> | 1766 | <entry>y<subscript>5</subscript></entry> |
@@ -1849,10 +1774,7 @@ | |||
1849 | <entry>V4L2_MBUS_FMT_YUYV8_2X8</entry> | 1774 | <entry>V4L2_MBUS_FMT_YUYV8_2X8</entry> |
1850 | <entry>0x2008</entry> | 1775 | <entry>0x2008</entry> |
1851 | <entry></entry> | 1776 | <entry></entry> |
1852 | &dash-ent-10; | 1777 | &dash-ent-24; |
1853 | &dash-ent-10; | ||
1854 | <entry>-</entry> | ||
1855 | <entry>-</entry> | ||
1856 | <entry>y<subscript>7</subscript></entry> | 1778 | <entry>y<subscript>7</subscript></entry> |
1857 | <entry>y<subscript>6</subscript></entry> | 1779 | <entry>y<subscript>6</subscript></entry> |
1858 | <entry>y<subscript>5</subscript></entry> | 1780 | <entry>y<subscript>5</subscript></entry> |
@@ -1866,10 +1788,7 @@ | |||
1866 | <entry></entry> | 1788 | <entry></entry> |
1867 | <entry></entry> | 1789 | <entry></entry> |
1868 | <entry></entry> | 1790 | <entry></entry> |
1869 | &dash-ent-10; | 1791 | &dash-ent-24; |
1870 | &dash-ent-10; | ||
1871 | <entry>-</entry> | ||
1872 | <entry>-</entry> | ||
1873 | <entry>u<subscript>7</subscript></entry> | 1792 | <entry>u<subscript>7</subscript></entry> |
1874 | <entry>u<subscript>6</subscript></entry> | 1793 | <entry>u<subscript>6</subscript></entry> |
1875 | <entry>u<subscript>5</subscript></entry> | 1794 | <entry>u<subscript>5</subscript></entry> |
@@ -1883,10 +1802,7 @@ | |||
1883 | <entry></entry> | 1802 | <entry></entry> |
1884 | <entry></entry> | 1803 | <entry></entry> |
1885 | <entry></entry> | 1804 | <entry></entry> |
1886 | &dash-ent-10; | 1805 | &dash-ent-24; |
1887 | &dash-ent-10; | ||
1888 | <entry>-</entry> | ||
1889 | <entry>-</entry> | ||
1890 | <entry>y<subscript>7</subscript></entry> | 1806 | <entry>y<subscript>7</subscript></entry> |
1891 | <entry>y<subscript>6</subscript></entry> | 1807 | <entry>y<subscript>6</subscript></entry> |
1892 | <entry>y<subscript>5</subscript></entry> | 1808 | <entry>y<subscript>5</subscript></entry> |
@@ -1900,10 +1816,7 @@ | |||
1900 | <entry></entry> | 1816 | <entry></entry> |
1901 | <entry></entry> | 1817 | <entry></entry> |
1902 | <entry></entry> | 1818 | <entry></entry> |
1903 | &dash-ent-10; | 1819 | &dash-ent-24; |
1904 | &dash-ent-10; | ||
1905 | <entry>-</entry> | ||
1906 | <entry>-</entry> | ||
1907 | <entry>v<subscript>7</subscript></entry> | 1820 | <entry>v<subscript>7</subscript></entry> |
1908 | <entry>v<subscript>6</subscript></entry> | 1821 | <entry>v<subscript>6</subscript></entry> |
1909 | <entry>v<subscript>5</subscript></entry> | 1822 | <entry>v<subscript>5</subscript></entry> |
@@ -1917,10 +1830,7 @@ | |||
1917 | <entry>V4L2_MBUS_FMT_YVYU8_2X8</entry> | 1830 | <entry>V4L2_MBUS_FMT_YVYU8_2X8</entry> |
1918 | <entry>0x2009</entry> | 1831 | <entry>0x2009</entry> |
1919 | <entry></entry> | 1832 | <entry></entry> |
1920 | &dash-ent-10; | 1833 | &dash-ent-24; |
1921 | &dash-ent-10; | ||
1922 | <entry>-</entry> | ||
1923 | <entry>-</entry> | ||
1924 | <entry>y<subscript>7</subscript></entry> | 1834 | <entry>y<subscript>7</subscript></entry> |
1925 | <entry>y<subscript>6</subscript></entry> | 1835 | <entry>y<subscript>6</subscript></entry> |
1926 | <entry>y<subscript>5</subscript></entry> | 1836 | <entry>y<subscript>5</subscript></entry> |
@@ -1934,10 +1844,7 @@ | |||
1934 | <entry></entry> | 1844 | <entry></entry> |
1935 | <entry></entry> | 1845 | <entry></entry> |
1936 | <entry></entry> | 1846 | <entry></entry> |
1937 | &dash-ent-10; | 1847 | &dash-ent-24; |
1938 | &dash-ent-10; | ||
1939 | <entry>-</entry> | ||
1940 | <entry>-</entry> | ||
1941 | <entry>v<subscript>7</subscript></entry> | 1848 | <entry>v<subscript>7</subscript></entry> |
1942 | <entry>v<subscript>6</subscript></entry> | 1849 | <entry>v<subscript>6</subscript></entry> |
1943 | <entry>v<subscript>5</subscript></entry> | 1850 | <entry>v<subscript>5</subscript></entry> |
@@ -1951,10 +1858,7 @@ | |||
1951 | <entry></entry> | 1858 | <entry></entry> |
1952 | <entry></entry> | 1859 | <entry></entry> |
1953 | <entry></entry> | 1860 | <entry></entry> |
1954 | &dash-ent-10; | 1861 | &dash-ent-24; |
1955 | &dash-ent-10; | ||
1956 | <entry>-</entry> | ||
1957 | <entry>-</entry> | ||
1958 | <entry>y<subscript>7</subscript></entry> | 1862 | <entry>y<subscript>7</subscript></entry> |
1959 | <entry>y<subscript>6</subscript></entry> | 1863 | <entry>y<subscript>6</subscript></entry> |
1960 | <entry>y<subscript>5</subscript></entry> | 1864 | <entry>y<subscript>5</subscript></entry> |
@@ -1968,10 +1872,7 @@ | |||
1968 | <entry></entry> | 1872 | <entry></entry> |
1969 | <entry></entry> | 1873 | <entry></entry> |
1970 | <entry></entry> | 1874 | <entry></entry> |
1971 | &dash-ent-10; | 1875 | &dash-ent-24; |
1972 | &dash-ent-10; | ||
1973 | <entry>-</entry> | ||
1974 | <entry>-</entry> | ||
1975 | <entry>u<subscript>7</subscript></entry> | 1876 | <entry>u<subscript>7</subscript></entry> |
1976 | <entry>u<subscript>6</subscript></entry> | 1877 | <entry>u<subscript>6</subscript></entry> |
1977 | <entry>u<subscript>5</subscript></entry> | 1878 | <entry>u<subscript>5</subscript></entry> |
@@ -1985,8 +1886,7 @@ | |||
1985 | <entry>V4L2_MBUS_FMT_Y10_1X10</entry> | 1886 | <entry>V4L2_MBUS_FMT_Y10_1X10</entry> |
1986 | <entry>0x200a</entry> | 1887 | <entry>0x200a</entry> |
1987 | <entry></entry> | 1888 | <entry></entry> |
1988 | &dash-ent-10; | 1889 | &dash-ent-22; |
1989 | &dash-ent-10; | ||
1990 | <entry>y<subscript>9</subscript></entry> | 1890 | <entry>y<subscript>9</subscript></entry> |
1991 | <entry>y<subscript>8</subscript></entry> | 1891 | <entry>y<subscript>8</subscript></entry> |
1992 | <entry>y<subscript>7</subscript></entry> | 1892 | <entry>y<subscript>7</subscript></entry> |
@@ -2002,8 +1902,7 @@ | |||
2002 | <entry>V4L2_MBUS_FMT_YUYV10_2X10</entry> | 1902 | <entry>V4L2_MBUS_FMT_YUYV10_2X10</entry> |
2003 | <entry>0x200b</entry> | 1903 | <entry>0x200b</entry> |
2004 | <entry></entry> | 1904 | <entry></entry> |
2005 | &dash-ent-10; | 1905 | &dash-ent-22; |
2006 | &dash-ent-10; | ||
2007 | <entry>y<subscript>9</subscript></entry> | 1906 | <entry>y<subscript>9</subscript></entry> |
2008 | <entry>y<subscript>8</subscript></entry> | 1907 | <entry>y<subscript>8</subscript></entry> |
2009 | <entry>y<subscript>7</subscript></entry> | 1908 | <entry>y<subscript>7</subscript></entry> |
@@ -2019,8 +1918,7 @@ | |||
2019 | <entry></entry> | 1918 | <entry></entry> |
2020 | <entry></entry> | 1919 | <entry></entry> |
2021 | <entry></entry> | 1920 | <entry></entry> |
2022 | &dash-ent-10; | 1921 | &dash-ent-22; |
2023 | &dash-ent-10; | ||
2024 | <entry>u<subscript>9</subscript></entry> | 1922 | <entry>u<subscript>9</subscript></entry> |
2025 | <entry>u<subscript>8</subscript></entry> | 1923 | <entry>u<subscript>8</subscript></entry> |
2026 | <entry>u<subscript>7</subscript></entry> | 1924 | <entry>u<subscript>7</subscript></entry> |
@@ -2036,8 +1934,7 @@ | |||
2036 | <entry></entry> | 1934 | <entry></entry> |
2037 | <entry></entry> | 1935 | <entry></entry> |
2038 | <entry></entry> | 1936 | <entry></entry> |
2039 | &dash-ent-10; | 1937 | &dash-ent-22; |
2040 | &dash-ent-10; | ||
2041 | <entry>y<subscript>9</subscript></entry> | 1938 | <entry>y<subscript>9</subscript></entry> |
2042 | <entry>y<subscript>8</subscript></entry> | 1939 | <entry>y<subscript>8</subscript></entry> |
2043 | <entry>y<subscript>7</subscript></entry> | 1940 | <entry>y<subscript>7</subscript></entry> |
@@ -2053,8 +1950,7 @@ | |||
2053 | <entry></entry> | 1950 | <entry></entry> |
2054 | <entry></entry> | 1951 | <entry></entry> |
2055 | <entry></entry> | 1952 | <entry></entry> |
2056 | &dash-ent-10; | 1953 | &dash-ent-22; |
2057 | &dash-ent-10; | ||
2058 | <entry>v<subscript>9</subscript></entry> | 1954 | <entry>v<subscript>9</subscript></entry> |
2059 | <entry>v<subscript>8</subscript></entry> | 1955 | <entry>v<subscript>8</subscript></entry> |
2060 | <entry>v<subscript>7</subscript></entry> | 1956 | <entry>v<subscript>7</subscript></entry> |
@@ -2070,8 +1966,7 @@ | |||
2070 | <entry>V4L2_MBUS_FMT_YVYU10_2X10</entry> | 1966 | <entry>V4L2_MBUS_FMT_YVYU10_2X10</entry> |
2071 | <entry>0x200c</entry> | 1967 | <entry>0x200c</entry> |
2072 | <entry></entry> | 1968 | <entry></entry> |
2073 | &dash-ent-10; | 1969 | &dash-ent-22; |
2074 | &dash-ent-10; | ||
2075 | <entry>y<subscript>9</subscript></entry> | 1970 | <entry>y<subscript>9</subscript></entry> |
2076 | <entry>y<subscript>8</subscript></entry> | 1971 | <entry>y<subscript>8</subscript></entry> |
2077 | <entry>y<subscript>7</subscript></entry> | 1972 | <entry>y<subscript>7</subscript></entry> |
@@ -2087,8 +1982,7 @@ | |||
2087 | <entry></entry> | 1982 | <entry></entry> |
2088 | <entry></entry> | 1983 | <entry></entry> |
2089 | <entry></entry> | 1984 | <entry></entry> |
2090 | &dash-ent-10; | 1985 | &dash-ent-22; |
2091 | &dash-ent-10; | ||
2092 | <entry>v<subscript>9</subscript></entry> | 1986 | <entry>v<subscript>9</subscript></entry> |
2093 | <entry>v<subscript>8</subscript></entry> | 1987 | <entry>v<subscript>8</subscript></entry> |
2094 | <entry>v<subscript>7</subscript></entry> | 1988 | <entry>v<subscript>7</subscript></entry> |
@@ -2104,8 +1998,7 @@ | |||
2104 | <entry></entry> | 1998 | <entry></entry> |
2105 | <entry></entry> | 1999 | <entry></entry> |
2106 | <entry></entry> | 2000 | <entry></entry> |
2107 | &dash-ent-10; | 2001 | &dash-ent-22; |
2108 | &dash-ent-10; | ||
2109 | <entry>y<subscript>9</subscript></entry> | 2002 | <entry>y<subscript>9</subscript></entry> |
2110 | <entry>y<subscript>8</subscript></entry> | 2003 | <entry>y<subscript>8</subscript></entry> |
2111 | <entry>y<subscript>7</subscript></entry> | 2004 | <entry>y<subscript>7</subscript></entry> |
@@ -2121,8 +2014,7 @@ | |||
2121 | <entry></entry> | 2014 | <entry></entry> |
2122 | <entry></entry> | 2015 | <entry></entry> |
2123 | <entry></entry> | 2016 | <entry></entry> |
2124 | &dash-ent-10; | 2017 | &dash-ent-22; |
2125 | &dash-ent-10; | ||
2126 | <entry>u<subscript>9</subscript></entry> | 2018 | <entry>u<subscript>9</subscript></entry> |
2127 | <entry>u<subscript>8</subscript></entry> | 2019 | <entry>u<subscript>8</subscript></entry> |
2128 | <entry>u<subscript>7</subscript></entry> | 2020 | <entry>u<subscript>7</subscript></entry> |
@@ -2138,15 +2030,7 @@ | |||
2138 | <entry>V4L2_MBUS_FMT_Y12_1X12</entry> | 2030 | <entry>V4L2_MBUS_FMT_Y12_1X12</entry> |
2139 | <entry>0x2013</entry> | 2031 | <entry>0x2013</entry> |
2140 | <entry></entry> | 2032 | <entry></entry> |
2141 | &dash-ent-10; | 2033 | &dash-ent-20; |
2142 | <entry>-</entry> | ||
2143 | <entry>-</entry> | ||
2144 | <entry>-</entry> | ||
2145 | <entry>-</entry> | ||
2146 | <entry>-</entry> | ||
2147 | <entry>-</entry> | ||
2148 | <entry>-</entry> | ||
2149 | <entry>-</entry> | ||
2150 | <entry>y<subscript>11</subscript></entry> | 2034 | <entry>y<subscript>11</subscript></entry> |
2151 | <entry>y<subscript>10</subscript></entry> | 2035 | <entry>y<subscript>10</subscript></entry> |
2152 | <entry>y<subscript>9</subscript></entry> | 2036 | <entry>y<subscript>9</subscript></entry> |
@@ -2164,11 +2048,7 @@ | |||
2164 | <entry>V4L2_MBUS_FMT_UYVY8_1X16</entry> | 2048 | <entry>V4L2_MBUS_FMT_UYVY8_1X16</entry> |
2165 | <entry>0x200f</entry> | 2049 | <entry>0x200f</entry> |
2166 | <entry></entry> | 2050 | <entry></entry> |
2167 | &dash-ent-10; | 2051 | &dash-ent-16; |
2168 | <entry>-</entry> | ||
2169 | <entry>-</entry> | ||
2170 | <entry>-</entry> | ||
2171 | <entry>-</entry> | ||
2172 | <entry>u<subscript>7</subscript></entry> | 2052 | <entry>u<subscript>7</subscript></entry> |
2173 | <entry>u<subscript>6</subscript></entry> | 2053 | <entry>u<subscript>6</subscript></entry> |
2174 | <entry>u<subscript>5</subscript></entry> | 2054 | <entry>u<subscript>5</subscript></entry> |
@@ -2190,11 +2070,7 @@ | |||
2190 | <entry></entry> | 2070 | <entry></entry> |
2191 | <entry></entry> | 2071 | <entry></entry> |
2192 | <entry></entry> | 2072 | <entry></entry> |
2193 | &dash-ent-10; | 2073 | &dash-ent-16; |
2194 | <entry>-</entry> | ||
2195 | <entry>-</entry> | ||
2196 | <entry>-</entry> | ||
2197 | <entry>-</entry> | ||
2198 | <entry>v<subscript>7</subscript></entry> | 2074 | <entry>v<subscript>7</subscript></entry> |
2199 | <entry>v<subscript>6</subscript></entry> | 2075 | <entry>v<subscript>6</subscript></entry> |
2200 | <entry>v<subscript>5</subscript></entry> | 2076 | <entry>v<subscript>5</subscript></entry> |
@@ -2216,11 +2092,7 @@ | |||
2216 | <entry>V4L2_MBUS_FMT_VYUY8_1X16</entry> | 2092 | <entry>V4L2_MBUS_FMT_VYUY8_1X16</entry> |
2217 | <entry>0x2010</entry> | 2093 | <entry>0x2010</entry> |
2218 | <entry></entry> | 2094 | <entry></entry> |
2219 | &dash-ent-10; | 2095 | &dash-ent-16; |
2220 | <entry>-</entry> | ||
2221 | <entry>-</entry> | ||
2222 | <entry>-</entry> | ||
2223 | <entry>-</entry> | ||
2224 | <entry>v<subscript>7</subscript></entry> | 2096 | <entry>v<subscript>7</subscript></entry> |
2225 | <entry>v<subscript>6</subscript></entry> | 2097 | <entry>v<subscript>6</subscript></entry> |
2226 | <entry>v<subscript>5</subscript></entry> | 2098 | <entry>v<subscript>5</subscript></entry> |
@@ -2242,11 +2114,7 @@ | |||
2242 | <entry></entry> | 2114 | <entry></entry> |
2243 | <entry></entry> | 2115 | <entry></entry> |
2244 | <entry></entry> | 2116 | <entry></entry> |
2245 | &dash-ent-10; | 2117 | &dash-ent-16; |
2246 | <entry>-</entry> | ||
2247 | <entry>-</entry> | ||
2248 | <entry>-</entry> | ||
2249 | <entry>-</entry> | ||
2250 | <entry>u<subscript>7</subscript></entry> | 2118 | <entry>u<subscript>7</subscript></entry> |
2251 | <entry>u<subscript>6</subscript></entry> | 2119 | <entry>u<subscript>6</subscript></entry> |
2252 | <entry>u<subscript>5</subscript></entry> | 2120 | <entry>u<subscript>5</subscript></entry> |
@@ -2268,11 +2136,7 @@ | |||
2268 | <entry>V4L2_MBUS_FMT_YUYV8_1X16</entry> | 2136 | <entry>V4L2_MBUS_FMT_YUYV8_1X16</entry> |
2269 | <entry>0x2011</entry> | 2137 | <entry>0x2011</entry> |
2270 | <entry></entry> | 2138 | <entry></entry> |
2271 | &dash-ent-10; | 2139 | &dash-ent-16; |
2272 | <entry>-</entry> | ||
2273 | <entry>-</entry> | ||
2274 | <entry>-</entry> | ||
2275 | <entry>-</entry> | ||
2276 | <entry>y<subscript>7</subscript></entry> | 2140 | <entry>y<subscript>7</subscript></entry> |
2277 | <entry>y<subscript>6</subscript></entry> | 2141 | <entry>y<subscript>6</subscript></entry> |
2278 | <entry>y<subscript>5</subscript></entry> | 2142 | <entry>y<subscript>5</subscript></entry> |
@@ -2294,11 +2158,7 @@ | |||
2294 | <entry></entry> | 2158 | <entry></entry> |
2295 | <entry></entry> | 2159 | <entry></entry> |
2296 | <entry></entry> | 2160 | <entry></entry> |
2297 | &dash-ent-10; | 2161 | &dash-ent-16; |
2298 | <entry>-</entry> | ||
2299 | <entry>-</entry> | ||
2300 | <entry>-</entry> | ||
2301 | <entry>-</entry> | ||
2302 | <entry>y<subscript>7</subscript></entry> | 2162 | <entry>y<subscript>7</subscript></entry> |
2303 | <entry>y<subscript>6</subscript></entry> | 2163 | <entry>y<subscript>6</subscript></entry> |
2304 | <entry>y<subscript>5</subscript></entry> | 2164 | <entry>y<subscript>5</subscript></entry> |
@@ -2320,11 +2180,7 @@ | |||
2320 | <entry>V4L2_MBUS_FMT_YVYU8_1X16</entry> | 2180 | <entry>V4L2_MBUS_FMT_YVYU8_1X16</entry> |
2321 | <entry>0x2012</entry> | 2181 | <entry>0x2012</entry> |
2322 | <entry></entry> | 2182 | <entry></entry> |
2323 | &dash-ent-10; | 2183 | &dash-ent-16; |
2324 | <entry>-</entry> | ||
2325 | <entry>-</entry> | ||
2326 | <entry>-</entry> | ||
2327 | <entry>-</entry> | ||
2328 | <entry>y<subscript>7</subscript></entry> | 2184 | <entry>y<subscript>7</subscript></entry> |
2329 | <entry>y<subscript>6</subscript></entry> | 2185 | <entry>y<subscript>6</subscript></entry> |
2330 | <entry>y<subscript>5</subscript></entry> | 2186 | <entry>y<subscript>5</subscript></entry> |
@@ -2346,11 +2202,7 @@ | |||
2346 | <entry></entry> | 2202 | <entry></entry> |
2347 | <entry></entry> | 2203 | <entry></entry> |
2348 | <entry></entry> | 2204 | <entry></entry> |
2349 | &dash-ent-10; | 2205 | &dash-ent-16; |
2350 | <entry>-</entry> | ||
2351 | <entry>-</entry> | ||
2352 | <entry>-</entry> | ||
2353 | <entry>-</entry> | ||
2354 | <entry>y<subscript>7</subscript></entry> | 2206 | <entry>y<subscript>7</subscript></entry> |
2355 | <entry>y<subscript>6</subscript></entry> | 2207 | <entry>y<subscript>6</subscript></entry> |
2356 | <entry>y<subscript>5</subscript></entry> | 2208 | <entry>y<subscript>5</subscript></entry> |
@@ -2372,10 +2224,7 @@ | |||
2372 | <entry>V4L2_MBUS_FMT_YDYUYDYV8_1X16</entry> | 2224 | <entry>V4L2_MBUS_FMT_YDYUYDYV8_1X16</entry> |
2373 | <entry>0x2014</entry> | 2225 | <entry>0x2014</entry> |
2374 | <entry></entry> | 2226 | <entry></entry> |
2375 | <entry>-</entry> | 2227 | &dash-ent-16; |
2376 | <entry>-</entry> | ||
2377 | <entry>-</entry> | ||
2378 | <entry>-</entry> | ||
2379 | <entry>y<subscript>7</subscript></entry> | 2228 | <entry>y<subscript>7</subscript></entry> |
2380 | <entry>y<subscript>6</subscript></entry> | 2229 | <entry>y<subscript>6</subscript></entry> |
2381 | <entry>y<subscript>5</subscript></entry> | 2230 | <entry>y<subscript>5</subscript></entry> |
@@ -2397,10 +2246,7 @@ | |||
2397 | <entry></entry> | 2246 | <entry></entry> |
2398 | <entry></entry> | 2247 | <entry></entry> |
2399 | <entry></entry> | 2248 | <entry></entry> |
2400 | <entry>-</entry> | 2249 | &dash-ent-16; |
2401 | <entry>-</entry> | ||
2402 | <entry>-</entry> | ||
2403 | <entry>-</entry> | ||
2404 | <entry>y<subscript>7</subscript></entry> | 2250 | <entry>y<subscript>7</subscript></entry> |
2405 | <entry>y<subscript>6</subscript></entry> | 2251 | <entry>y<subscript>6</subscript></entry> |
2406 | <entry>y<subscript>5</subscript></entry> | 2252 | <entry>y<subscript>5</subscript></entry> |
@@ -2422,10 +2268,7 @@ | |||
2422 | <entry></entry> | 2268 | <entry></entry> |
2423 | <entry></entry> | 2269 | <entry></entry> |
2424 | <entry></entry> | 2270 | <entry></entry> |
2425 | <entry>-</entry> | 2271 | &dash-ent-16; |
2426 | <entry>-</entry> | ||
2427 | <entry>-</entry> | ||
2428 | <entry>-</entry> | ||
2429 | <entry>y<subscript>7</subscript></entry> | 2272 | <entry>y<subscript>7</subscript></entry> |
2430 | <entry>y<subscript>6</subscript></entry> | 2273 | <entry>y<subscript>6</subscript></entry> |
2431 | <entry>y<subscript>5</subscript></entry> | 2274 | <entry>y<subscript>5</subscript></entry> |
@@ -2447,10 +2290,7 @@ | |||
2447 | <entry></entry> | 2290 | <entry></entry> |
2448 | <entry></entry> | 2291 | <entry></entry> |
2449 | <entry></entry> | 2292 | <entry></entry> |
2450 | <entry>-</entry> | 2293 | &dash-ent-16; |
2451 | <entry>-</entry> | ||
2452 | <entry>-</entry> | ||
2453 | <entry>-</entry> | ||
2454 | <entry>y<subscript>7</subscript></entry> | 2294 | <entry>y<subscript>7</subscript></entry> |
2455 | <entry>y<subscript>6</subscript></entry> | 2295 | <entry>y<subscript>6</subscript></entry> |
2456 | <entry>y<subscript>5</subscript></entry> | 2296 | <entry>y<subscript>5</subscript></entry> |
@@ -2472,7 +2312,7 @@ | |||
2472 | <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry> | 2312 | <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry> |
2473 | <entry>0x200d</entry> | 2313 | <entry>0x200d</entry> |
2474 | <entry></entry> | 2314 | <entry></entry> |
2475 | &dash-ent-10; | 2315 | &dash-ent-12; |
2476 | <entry>y<subscript>9</subscript></entry> | 2316 | <entry>y<subscript>9</subscript></entry> |
2477 | <entry>y<subscript>8</subscript></entry> | 2317 | <entry>y<subscript>8</subscript></entry> |
2478 | <entry>y<subscript>7</subscript></entry> | 2318 | <entry>y<subscript>7</subscript></entry> |
@@ -2498,7 +2338,7 @@ | |||
2498 | <entry></entry> | 2338 | <entry></entry> |
2499 | <entry></entry> | 2339 | <entry></entry> |
2500 | <entry></entry> | 2340 | <entry></entry> |
2501 | &dash-ent-10; | 2341 | &dash-ent-12; |
2502 | <entry>y<subscript>9</subscript></entry> | 2342 | <entry>y<subscript>9</subscript></entry> |
2503 | <entry>y<subscript>8</subscript></entry> | 2343 | <entry>y<subscript>8</subscript></entry> |
2504 | <entry>y<subscript>7</subscript></entry> | 2344 | <entry>y<subscript>7</subscript></entry> |
@@ -2524,7 +2364,7 @@ | |||
2524 | <entry>V4L2_MBUS_FMT_YVYU10_1X20</entry> | 2364 | <entry>V4L2_MBUS_FMT_YVYU10_1X20</entry> |
2525 | <entry>0x200e</entry> | 2365 | <entry>0x200e</entry> |
2526 | <entry></entry> | 2366 | <entry></entry> |
2527 | &dash-ent-10; | 2367 | &dash-ent-12; |
2528 | <entry>y<subscript>9</subscript></entry> | 2368 | <entry>y<subscript>9</subscript></entry> |
2529 | <entry>y<subscript>8</subscript></entry> | 2369 | <entry>y<subscript>8</subscript></entry> |
2530 | <entry>y<subscript>7</subscript></entry> | 2370 | <entry>y<subscript>7</subscript></entry> |
@@ -2550,7 +2390,7 @@ | |||
2550 | <entry></entry> | 2390 | <entry></entry> |
2551 | <entry></entry> | 2391 | <entry></entry> |
2552 | <entry></entry> | 2392 | <entry></entry> |
2553 | &dash-ent-10; | 2393 | &dash-ent-12; |
2554 | <entry>y<subscript>9</subscript></entry> | 2394 | <entry>y<subscript>9</subscript></entry> |
2555 | <entry>y<subscript>8</subscript></entry> | 2395 | <entry>y<subscript>8</subscript></entry> |
2556 | <entry>y<subscript>7</subscript></entry> | 2396 | <entry>y<subscript>7</subscript></entry> |
@@ -2574,8 +2414,10 @@ | |||
2574 | </row> | 2414 | </row> |
2575 | <row id="V4L2-MBUS-FMT-YUV10-1X30"> | 2415 | <row id="V4L2-MBUS-FMT-YUV10-1X30"> |
2576 | <entry>V4L2_MBUS_FMT_YUV10_1X30</entry> | 2416 | <entry>V4L2_MBUS_FMT_YUV10_1X30</entry> |
2577 | <entry>0x2014</entry> | 2417 | <entry>0x2016</entry> |
2578 | <entry></entry> | 2418 | <entry></entry> |
2419 | <entry>-</entry> | ||
2420 | <entry>-</entry> | ||
2579 | <entry>y<subscript>9</subscript></entry> | 2421 | <entry>y<subscript>9</subscript></entry> |
2580 | <entry>y<subscript>8</subscript></entry> | 2422 | <entry>y<subscript>8</subscript></entry> |
2581 | <entry>y<subscript>7</subscript></entry> | 2423 | <entry>y<subscript>7</subscript></entry> |
@@ -2607,6 +2449,43 @@ | |||
2607 | <entry>v<subscript>1</subscript></entry> | 2449 | <entry>v<subscript>1</subscript></entry> |
2608 | <entry>v<subscript>0</subscript></entry> | 2450 | <entry>v<subscript>0</subscript></entry> |
2609 | </row> | 2451 | </row> |
2452 | <row id="V4L2-MBUS-FMT-AYUV8-1X32"> | ||
2453 | <entry>V4L2_MBUS_FMT_AYUV8_1X32</entry> | ||
2454 | <entry>0x2017</entry> | ||
2455 | <entry></entry> | ||
2456 | <entry>a<subscript>7</subscript></entry> | ||
2457 | <entry>a<subscript>6</subscript></entry> | ||
2458 | <entry>a<subscript>5</subscript></entry> | ||
2459 | <entry>a<subscript>4</subscript></entry> | ||
2460 | <entry>a<subscript>3</subscript></entry> | ||
2461 | <entry>a<subscript>2</subscript></entry> | ||
2462 | <entry>a<subscript>1</subscript></entry> | ||
2463 | <entry>a<subscript>0</subscript></entry> | ||
2464 | <entry>y<subscript>7</subscript></entry> | ||
2465 | <entry>y<subscript>6</subscript></entry> | ||
2466 | <entry>y<subscript>5</subscript></entry> | ||
2467 | <entry>y<subscript>4</subscript></entry> | ||
2468 | <entry>y<subscript>3</subscript></entry> | ||
2469 | <entry>y<subscript>2</subscript></entry> | ||
2470 | <entry>y<subscript>1</subscript></entry> | ||
2471 | <entry>y<subscript>0</subscript></entry> | ||
2472 | <entry>u<subscript>7</subscript></entry> | ||
2473 | <entry>u<subscript>6</subscript></entry> | ||
2474 | <entry>u<subscript>5</subscript></entry> | ||
2475 | <entry>u<subscript>4</subscript></entry> | ||
2476 | <entry>u<subscript>3</subscript></entry> | ||
2477 | <entry>u<subscript>2</subscript></entry> | ||
2478 | <entry>u<subscript>1</subscript></entry> | ||
2479 | <entry>u<subscript>0</subscript></entry> | ||
2480 | <entry>v<subscript>7</subscript></entry> | ||
2481 | <entry>v<subscript>6</subscript></entry> | ||
2482 | <entry>v<subscript>5</subscript></entry> | ||
2483 | <entry>v<subscript>4</subscript></entry> | ||
2484 | <entry>v<subscript>3</subscript></entry> | ||
2485 | <entry>v<subscript>2</subscript></entry> | ||
2486 | <entry>v<subscript>1</subscript></entry> | ||
2487 | <entry>v<subscript>0</subscript></entry> | ||
2488 | </row> | ||
2610 | </tbody> | 2489 | </tbody> |
2611 | </tgroup> | 2490 | </tgroup> |
2612 | </table> | 2491 | </table> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml index cd9943672434..9b700a5f4df7 100644 --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml | |||
@@ -62,18 +62,29 @@ addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter | |||
62 | control over buffers is required. This ioctl can be called multiple times to | 62 | control over buffers is required. This ioctl can be called multiple times to |
63 | create buffers of different sizes.</para> | 63 | create buffers of different sizes.</para> |
64 | 64 | ||
65 | <para>To allocate device buffers applications initialize relevant fields of | 65 | <para>To allocate the device buffers applications must initialize the |
66 | the <structname>v4l2_create_buffers</structname> structure. They set the | 66 | relevant fields of the <structname>v4l2_create_buffers</structname> structure. |
67 | <structfield>type</structfield> field in the | 67 | The <structfield>count</structfield> field must be set to the number of |
68 | &v4l2-format; structure, embedded in this | 68 | requested buffers, the <structfield>memory</structfield> field specifies the |
69 | structure, to the respective stream or buffer type. | 69 | requested I/O method and the <structfield>reserved</structfield> array must be |
70 | <structfield>count</structfield> must be set to the number of required buffers. | 70 | zeroed.</para> |
71 | <structfield>memory</structfield> specifies the required I/O method. The | 71 | |
72 | <structfield>format</structfield> field shall typically be filled in using | 72 | <para>The <structfield>format</structfield> field specifies the image format |
73 | either the <constant>VIDIOC_TRY_FMT</constant> or | 73 | that the buffers must be able to handle. The application has to fill in this |
74 | <constant>VIDIOC_G_FMT</constant> ioctl(). Additionally, applications can adjust | 74 | &v4l2-format;. Usually this will be done using the |
75 | <structfield>sizeimage</structfield> fields to fit their specific needs. The | 75 | <constant>VIDIOC_TRY_FMT</constant> or <constant>VIDIOC_G_FMT</constant> ioctl() |
76 | <structfield>reserved</structfield> array must be zeroed.</para> | 76 | to ensure that the requested format is supported by the driver. Unsupported |
77 | formats will result in an error.</para> | ||
78 | |||
79 | <para>The buffers created by this ioctl will have as minimum size the size | ||
80 | defined by the <structfield>format.pix.sizeimage</structfield> field. If the | ||
81 | <structfield>format.pix.sizeimage</structfield> field is less than the minimum | ||
82 | required for the given format, then <structfield>sizeimage</structfield> will be | ||
83 | increased by the driver to that minimum to allocate the buffers. If it is | ||
84 | larger, then the value will be used as-is. The same applies to the | ||
85 | <structfield>sizeimage</structfield> field of the | ||
86 | <structname>v4l2_plane_pix_format</structname> structure in the case of | ||
87 | multiplanar formats.</para> | ||
77 | 88 | ||
78 | <para>When the ioctl is called with a pointer to this structure the driver | 89 | <para>When the ioctl is called with a pointer to this structure the driver |
79 | will attempt to allocate up to the requested number of buffers and store the | 90 | will attempt to allocate up to the requested number of buffers and store the |
@@ -144,9 +155,9 @@ mapped</link> I/O.</para> | |||
144 | <varlistentry> | 155 | <varlistentry> |
145 | <term><errorcode>EINVAL</errorcode></term> | 156 | <term><errorcode>EINVAL</errorcode></term> |
146 | <listitem> | 157 | <listitem> |
147 | <para>The buffer type (<structfield>type</structfield> field) or the | 158 | <para>The buffer type (<structfield>format.type</structfield> field), |
148 | requested I/O method (<structfield>memory</structfield>) is not | 159 | requested I/O method (<structfield>memory</structfield>) or format |
149 | supported.</para> | 160 | (<structfield>format</structfield> field) is not valid.</para> |
150 | </listitem> | 161 | </listitem> |
151 | </varlistentry> | 162 | </varlistentry> |
152 | </variablelist> | 163 | </variablelist> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml index 72369707bd77..c4336577ff06 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml | |||
@@ -156,19 +156,19 @@ bit 0 (V4L2_DV_VSYNC_POS_POL) is for vertical sync polarity and bit 1 (V4L2_DV_H | |||
156 | <entry>__u32</entry> | 156 | <entry>__u32</entry> |
157 | <entry><structfield>il_vfrontporch</structfield></entry> | 157 | <entry><structfield>il_vfrontporch</structfield></entry> |
158 | <entry>Vertical front porch in lines for the even field (aka field 2) of | 158 | <entry>Vertical front porch in lines for the even field (aka field 2) of |
159 | interlaced field formats.</entry> | 159 | interlaced field formats. Must be 0 for progressive formats.</entry> |
160 | </row> | 160 | </row> |
161 | <row> | 161 | <row> |
162 | <entry>__u32</entry> | 162 | <entry>__u32</entry> |
163 | <entry><structfield>il_vsync</structfield></entry> | 163 | <entry><structfield>il_vsync</structfield></entry> |
164 | <entry>Vertical sync length in lines for the even field (aka field 2) of | 164 | <entry>Vertical sync length in lines for the even field (aka field 2) of |
165 | interlaced field formats.</entry> | 165 | interlaced field formats. Must be 0 for progressive formats.</entry> |
166 | </row> | 166 | </row> |
167 | <row> | 167 | <row> |
168 | <entry>__u32</entry> | 168 | <entry>__u32</entry> |
169 | <entry><structfield>il_vbackporch</structfield></entry> | 169 | <entry><structfield>il_vbackporch</structfield></entry> |
170 | <entry>Vertical back porch in lines for the even field (aka field 2) of | 170 | <entry>Vertical back porch in lines for the even field (aka field 2) of |
171 | interlaced field formats.</entry> | 171 | interlaced field formats. Must be 0 for progressive formats.</entry> |
172 | </row> | 172 | </row> |
173 | <row> | 173 | <row> |
174 | <entry>__u32</entry> | 174 | <entry>__u32</entry> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml b/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml index 48748499c097..098ff483802e 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml | |||
@@ -92,8 +92,8 @@ to add them.</para> | |||
92 | <entry>int</entry> | 92 | <entry>int</entry> |
93 | <entry><structfield>quality</structfield></entry> | 93 | <entry><structfield>quality</structfield></entry> |
94 | <entry>Deprecated. If <link linkend="jpeg-quality-control"><constant> | 94 | <entry>Deprecated. If <link linkend="jpeg-quality-control"><constant> |
95 | V4L2_CID_JPEG_IMAGE_QUALITY</constant></link> control is exposed by | 95 | V4L2_CID_JPEG_COMPRESSION_QUALITY</constant></link> control is exposed |
96 | a driver applications should use it instead and ignore this field. | 96 | by a driver applications should use it instead and ignore this field. |
97 | </entry> | 97 | </entry> |
98 | </row> | 98 | </row> |
99 | <row> | 99 | <row> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-parm.xml b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml index 9058224d1bbf..f4e28e7d4751 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-parm.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml | |||
@@ -132,7 +132,7 @@ devices.</para> | |||
132 | <row> | 132 | <row> |
133 | <entry>&v4l2-fract;</entry> | 133 | <entry>&v4l2-fract;</entry> |
134 | <entry><structfield>timeperframe</structfield></entry> | 134 | <entry><structfield>timeperframe</structfield></entry> |
135 | <entry><para>This is is the desired period between | 135 | <entry><para>This is the desired period between |
136 | successive frames captured by the driver, in seconds. The | 136 | successive frames captured by the driver, in seconds. The |
137 | field is intended to skip frames on the driver side, saving I/O | 137 | field is intended to skip frames on the driver side, saving I/O |
138 | bandwidth.</para><para>Applications store here the desired frame | 138 | bandwidth.</para><para>Applications store here the desired frame |
@@ -193,7 +193,7 @@ applications must set the array to zero.</entry> | |||
193 | <row> | 193 | <row> |
194 | <entry>&v4l2-fract;</entry> | 194 | <entry>&v4l2-fract;</entry> |
195 | <entry><structfield>timeperframe</structfield></entry> | 195 | <entry><structfield>timeperframe</structfield></entry> |
196 | <entry>This is is the desired period between | 196 | <entry>This is the desired period between |
197 | successive frames output by the driver, in seconds.</entry> | 197 | successive frames output by the driver, in seconds.</entry> |
198 | </row> | 198 | </row> |
199 | <row> | 199 | <row> |
diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 9c92bb879b6d..4c8d282545a2 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl | |||
@@ -22,8 +22,14 @@ | |||
22 | 22 | ||
23 | <!-- LinuxTV v4l-dvb repository. --> | 23 | <!-- LinuxTV v4l-dvb repository. --> |
24 | <!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>"> | 24 | <!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>"> |
25 | <!ENTITY dash-ent-8 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> | ||
25 | <!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> | 26 | <!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> |
27 | <!ENTITY dash-ent-12 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> | ||
28 | <!ENTITY dash-ent-14 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> | ||
26 | <!ENTITY dash-ent-16 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> | 29 | <!ENTITY dash-ent-16 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> |
30 | <!ENTITY dash-ent-20 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> | ||
31 | <!ENTITY dash-ent-22 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> | ||
32 | <!ENTITY dash-ent-24 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> | ||
27 | ]> | 33 | ]> |
28 | 34 | ||
29 | <book id="media_api"> | 35 | <book id="media_api"> |
diff --git a/Documentation/IRQ-affinity.txt b/Documentation/IRQ-affinity.txt index 7890fae18529..01a675175a36 100644 --- a/Documentation/IRQ-affinity.txt +++ b/Documentation/IRQ-affinity.txt | |||
@@ -57,8 +57,8 @@ i.e counters for the CPU0-3 did not change. | |||
57 | 57 | ||
58 | Here is an example of limiting that same irq (44) to cpus 1024 to 1031: | 58 | Here is an example of limiting that same irq (44) to cpus 1024 to 1031: |
59 | 59 | ||
60 | [root@moon 44]# echo 1024-1031 > smp_affinity | 60 | [root@moon 44]# echo 1024-1031 > smp_affinity_list |
61 | [root@moon 44]# cat smp_affinity | 61 | [root@moon 44]# cat smp_affinity_list |
62 | 1024-1031 | 62 | 1024-1031 |
63 | 63 | ||
64 | Note that to do this with a bitmask would require 32 bitmasks of zero | 64 | Note that to do this with a bitmask would require 32 bitmasks of zero |
diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index 7f40c72a9c51..273e654d7d08 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt | |||
@@ -39,7 +39,7 @@ in read-mostly situations. This algorithm does take pains to avoid | |||
39 | write-side contention and parallelize the other write-side overheads by | 39 | write-side contention and parallelize the other write-side overheads by |
40 | providing a fine-grained locking design, however, it would be interesting | 40 | providing a fine-grained locking design, however, it would be interesting |
41 | to see how much of the performance advantage reported in 1990 remains | 41 | to see how much of the performance advantage reported in 1990 remains |
42 | in 2004. | 42 | today. |
43 | 43 | ||
44 | At about this same time, Adams [Adams91] described ``chaotic relaxation'', | 44 | At about this same time, Adams [Adams91] described ``chaotic relaxation'', |
45 | where the normal barriers between successive iterations of convergent | 45 | where the normal barriers between successive iterations of convergent |
@@ -86,9 +86,9 @@ DYNIX/ptx kernel. The corresponding conference paper appeared in 1998 | |||
86 | [McKenney98]. | 86 | [McKenney98]. |
87 | 87 | ||
88 | In 1999, the Tornado and K42 groups described their "generations" | 88 | In 1999, the Tornado and K42 groups described their "generations" |
89 | mechanism, which quite similar to RCU [Gamsa99]. These operating systems | 89 | mechanism, which is quite similar to RCU [Gamsa99]. These operating |
90 | made pervasive use of RCU in place of "existence locks", which greatly | 90 | systems made pervasive use of RCU in place of "existence locks", which |
91 | simplifies locking hierarchies. | 91 | greatly simplifies locking hierarchies and helps avoid deadlocks. |
92 | 92 | ||
93 | 2001 saw the first RCU presentation involving Linux [McKenney01a] | 93 | 2001 saw the first RCU presentation involving Linux [McKenney01a] |
94 | at OLS. The resulting abundance of RCU patches was presented the | 94 | at OLS. The resulting abundance of RCU patches was presented the |
@@ -106,8 +106,11 @@ these techniques still impose significant read-side overhead in the | |||
106 | form of memory barriers. Researchers at Sun worked along similar lines | 106 | form of memory barriers. Researchers at Sun worked along similar lines |
107 | in the same timeframe [HerlihyLM02]. These techniques can be thought | 107 | in the same timeframe [HerlihyLM02]. These techniques can be thought |
108 | of as inside-out reference counts, where the count is represented by the | 108 | of as inside-out reference counts, where the count is represented by the |
109 | number of hazard pointers referencing a given data structure (rather than | 109 | number of hazard pointers referencing a given data structure rather than |
110 | the more conventional counter field within the data structure itself). | 110 | the more conventional counter field within the data structure itself. |
111 | The key advantage of inside-out reference counts is that they can be | ||
112 | stored in immortal variables, thus allowing races between access and | ||
113 | deletion to be avoided. | ||
111 | 114 | ||
112 | By the same token, RCU can be thought of as a "bulk reference count", | 115 | By the same token, RCU can be thought of as a "bulk reference count", |
113 | where some form of reference counter covers all reference by a given CPU | 116 | where some form of reference counter covers all reference by a given CPU |
@@ -179,7 +182,25 @@ tree using software transactional memory to protect concurrent updates | |||
179 | (strange, but true!) [PhilHoward2011RCUTMRBTree], yet another variant of | 182 | (strange, but true!) [PhilHoward2011RCUTMRBTree], yet another variant of |
180 | RCU-protected resizeable hash tables [Triplett:2011:RPHash], the 3.0 RCU | 183 | RCU-protected resizeable hash tables [Triplett:2011:RPHash], the 3.0 RCU |
181 | trainwreck [PaulEMcKenney2011RCU3.0trainwreck], and Neil Brown's "Meet the | 184 | trainwreck [PaulEMcKenney2011RCU3.0trainwreck], and Neil Brown's "Meet the |
182 | Lockers" LWN article [NeilBrown2011MeetTheLockers]. | 185 | Lockers" LWN article [NeilBrown2011MeetTheLockers]. Some academic |
186 | work looked at debugging uses of RCU [Seyster:2011:RFA:2075416.2075425]. | ||
187 | |||
188 | In 2012, Josh Triplett received his Ph.D. with his dissertation | ||
189 | covering RCU-protected resizable hash tables and the relationship | ||
190 | between memory barriers and read-side traversal order: If the updater | ||
191 | is making changes in the opposite direction from the read-side traveral | ||
192 | order, the updater need only execute a memory-barrier instruction, | ||
193 | but if in the same direction, the updater needs to wait for a grace | ||
194 | period between the individual updates [JoshTriplettPhD]. Also in 2012, | ||
195 | after seventeen years of attempts, an RCU paper made it into a top-flight | ||
196 | academic journal, IEEE Transactions on Parallel and Distributed Systems | ||
197 | [MathieuDesnoyers2012URCU]. A group of researchers in Spain applied | ||
198 | user-level RCU to crowd simulation [GuillermoVigueras2012RCUCrowd], and | ||
199 | another group of researchers in Europe produced a formal description of | ||
200 | RCU based on separation logic [AlexeyGotsman2012VerifyGraceExtended], | ||
201 | which was published in the 2013 European Symposium on Programming | ||
202 | [AlexeyGotsman2013ESOPRCU]. | ||
203 | |||
183 | 204 | ||
184 | 205 | ||
185 | Bibtex Entries | 206 | Bibtex Entries |
@@ -193,13 +214,12 @@ Bibtex Entries | |||
193 | ,volume="5" | 214 | ,volume="5" |
194 | ,number="3" | 215 | ,number="3" |
195 | ,pages="354-382" | 216 | ,pages="354-382" |
196 | ,note="Available: | ||
197 | \url{http://portal.acm.org/citation.cfm?id=320619&dl=GUIDE,} | ||
198 | [Viewed December 3, 2007]" | ||
199 | ,annotation={ | 217 | ,annotation={ |
200 | Use garbage collector to clean up data after everyone is done with it. | 218 | Use garbage collector to clean up data after everyone is done with it. |
201 | . | 219 | . |
202 | Oldest use of something vaguely resembling RCU that I have found. | 220 | Oldest use of something vaguely resembling RCU that I have found. |
221 | http://portal.acm.org/citation.cfm?id=320619&dl=GUIDE, | ||
222 | [Viewed December 3, 2007] | ||
203 | } | 223 | } |
204 | } | 224 | } |
205 | 225 | ||
@@ -309,7 +329,7 @@ for Programming Languages and Operating Systems}" | |||
309 | ,doi = {http://doi.acm.org/10.1145/42392.42399} | 329 | ,doi = {http://doi.acm.org/10.1145/42392.42399} |
310 | ,publisher = {ACM} | 330 | ,publisher = {ACM} |
311 | ,address = {New York, NY, USA} | 331 | ,address = {New York, NY, USA} |
312 | ,annotation= { | 332 | ,annotation={ |
313 | At the top of page 307: "Conflicts with deposits and withdrawals | 333 | At the top of page 307: "Conflicts with deposits and withdrawals |
314 | are necessary if the reported total is to be up to date. They | 334 | are necessary if the reported total is to be up to date. They |
315 | could be avoided by having total return a sum that is slightly | 335 | could be avoided by having total return a sum that is slightly |
@@ -346,8 +366,9 @@ for Programming Languages and Operating Systems}" | |||
346 | } | 366 | } |
347 | } | 367 | } |
348 | 368 | ||
349 | @Book{Adams91 | 369 | # Was Adams91, see also syncrefs.bib. |
350 | ,Author="Gregory R. Adams" | 370 | @Book{Andrews91textbook |
371 | ,Author="Gregory R. Andrews" | ||
351 | ,title="Concurrent Programming, Principles, and Practices" | 372 | ,title="Concurrent Programming, Principles, and Practices" |
352 | ,Publisher="Benjamin Cummins" | 373 | ,Publisher="Benjamin Cummins" |
353 | ,Year="1991" | 374 | ,Year="1991" |
@@ -398,39 +419,39 @@ for Programming Languages and Operating Systems}" | |||
398 | } | 419 | } |
399 | } | 420 | } |
400 | 421 | ||
401 | @conference{Pu95a, | 422 | @conference{Pu95a |
402 | Author = "Calton Pu and Tito Autrey and Andrew Black and Charles Consel and | 423 | ,Author = "Calton Pu and Tito Autrey and Andrew Black and Charles Consel and |
403 | Crispin Cowan and Jon Inouye and Lakshmi Kethana and Jonathan Walpole and | 424 | Crispin Cowan and Jon Inouye and Lakshmi Kethana and Jonathan Walpole and |
404 | Ke Zhang", | 425 | Ke Zhang" |
405 | Title = "Optimistic Incremental Specialization: Streamlining a Commercial | 426 | ,Title = "Optimistic Incremental Specialization: Streamlining a Commercial |
406 | Operating System", | 427 | ,Operating System" |
407 | Booktitle = "15\textsuperscript{th} ACM Symposium on | 428 | ,Booktitle = "15\textsuperscript{th} ACM Symposium on |
408 | Operating Systems Principles (SOSP'95)", | 429 | ,Operating Systems Principles (SOSP'95)" |
409 | address = "Copper Mountain, CO", | 430 | ,address = "Copper Mountain, CO" |
410 | month="December", | 431 | ,month="December" |
411 | year="1995", | 432 | ,year="1995" |
412 | pages="314-321", | 433 | ,pages="314-321" |
413 | annotation=" | 434 | ,annotation={ |
414 | Uses a replugger, but with a flag to signal when people are | 435 | Uses a replugger, but with a flag to signal when people are |
415 | using the resource at hand. Only one reader at a time. | 436 | using the resource at hand. Only one reader at a time. |
416 | " | 437 | } |
417 | } | 438 | } |
418 | 439 | ||
419 | @conference{Cowan96a, | 440 | @conference{Cowan96a |
420 | Author = "Crispin Cowan and Tito Autrey and Charles Krasic and | 441 | ,Author = "Crispin Cowan and Tito Autrey and Charles Krasic and |
421 | Calton Pu and Jonathan Walpole", | 442 | ,Calton Pu and Jonathan Walpole" |
422 | Title = "Fast Concurrent Dynamic Linking for an Adaptive Operating System", | 443 | ,Title = "Fast Concurrent Dynamic Linking for an Adaptive Operating System" |
423 | Booktitle = "International Conference on Configurable Distributed Systems | 444 | ,Booktitle = "International Conference on Configurable Distributed Systems |
424 | (ICCDS'96)", | 445 | (ICCDS'96)" |
425 | address = "Annapolis, MD", | 446 | ,address = "Annapolis, MD" |
426 | month="May", | 447 | ,month="May" |
427 | year="1996", | 448 | ,year="1996" |
428 | pages="108", | 449 | ,pages="108" |
429 | isbn="0-8186-7395-8", | 450 | ,isbn="0-8186-7395-8" |
430 | annotation=" | 451 | ,annotation={ |
431 | Uses a replugger, but with a counter to signal when people are | 452 | Uses a replugger, but with a counter to signal when people are |
432 | using the resource at hand. Allows multiple readers. | 453 | using the resource at hand. Allows multiple readers. |
433 | " | 454 | } |
434 | } | 455 | } |
435 | 456 | ||
436 | @techreport{Slingwine95 | 457 | @techreport{Slingwine95 |
@@ -493,14 +514,13 @@ Problems" | |||
493 | ,Year="1998" | 514 | ,Year="1998" |
494 | ,pages="509-518" | 515 | ,pages="509-518" |
495 | ,Address="Las Vegas, NV" | 516 | ,Address="Las Vegas, NV" |
496 | ,note="Available: | ||
497 | \url{http://www.rdrop.com/users/paulmck/RCU/rclockpdcsproof.pdf} | ||
498 | [Viewed December 3, 2007]" | ||
499 | ,annotation={ | 517 | ,annotation={ |
500 | Describes and analyzes RCU mechanism in DYNIX/ptx. Describes | 518 | Describes and analyzes RCU mechanism in DYNIX/ptx. Describes |
501 | application to linked list update and log-buffer flushing. | 519 | application to linked list update and log-buffer flushing. |
502 | Defines 'quiescent state'. Includes both measured and analytic | 520 | Defines 'quiescent state'. Includes both measured and analytic |
503 | evaluation. | 521 | evaluation. |
522 | http://www.rdrop.com/users/paulmck/RCU/rclockpdcsproof.pdf | ||
523 | [Viewed December 3, 2007] | ||
504 | } | 524 | } |
505 | } | 525 | } |
506 | 526 | ||
@@ -514,13 +534,12 @@ Operating System Design and Implementation}" | |||
514 | ,Year="1999" | 534 | ,Year="1999" |
515 | ,pages="87-100" | 535 | ,pages="87-100" |
516 | ,Address="New Orleans, LA" | 536 | ,Address="New Orleans, LA" |
517 | ,note="Available: | ||
518 | \url{http://www.usenix.org/events/osdi99/full_papers/gamsa/gamsa.pdf} | ||
519 | [Viewed August 30, 2006]" | ||
520 | ,annotation={ | 537 | ,annotation={ |
521 | Use of RCU-like facility in K42/Tornado. Another independent | 538 | Use of RCU-like facility in K42/Tornado. Another independent |
522 | invention of RCU. | 539 | invention of RCU. |
523 | See especially pages 7-9 (Section 5). | 540 | See especially pages 7-9 (Section 5). |
541 | http://www.usenix.org/events/osdi99/full_papers/gamsa/gamsa.pdf | ||
542 | [Viewed August 30, 2006] | ||
524 | } | 543 | } |
525 | } | 544 | } |
526 | 545 | ||
@@ -611,9 +630,9 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni" | |||
611 | ,note="Available: | 630 | ,note="Available: |
612 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=100259266316456&w=2} | 631 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=100259266316456&w=2} |
613 | [Viewed June 23, 2004]" | 632 | [Viewed June 23, 2004]" |
614 | ,annotation=" | 633 | ,annotation={ |
615 | Memory-barrier and Alpha thread. 100 messages, not too bad... | 634 | Memory-barrier and Alpha thread. 100 messages, not too bad... |
616 | " | 635 | } |
617 | } | 636 | } |
618 | 637 | ||
619 | @unpublished{Spraul01 | 638 | @unpublished{Spraul01 |
@@ -624,10 +643,10 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni" | |||
624 | ,note="Available: | 643 | ,note="Available: |
625 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=100264675012867&w=2} | 644 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=100264675012867&w=2} |
626 | [Viewed June 23, 2004]" | 645 | [Viewed June 23, 2004]" |
627 | ,annotation=" | 646 | ,annotation={ |
628 | Suggested burying memory barriers in Linux's list-manipulation | 647 | Suggested burying memory barriers in Linux's list-manipulation |
629 | primitives. | 648 | primitives. |
630 | " | 649 | } |
631 | } | 650 | } |
632 | 651 | ||
633 | @unpublished{LinusTorvalds2001a | 652 | @unpublished{LinusTorvalds2001a |
@@ -638,6 +657,8 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni" | |||
638 | ,note="Available: | 657 | ,note="Available: |
639 | \url{http://lkml.org/lkml/2001/10/13/105} | 658 | \url{http://lkml.org/lkml/2001/10/13/105} |
640 | [Viewed August 21, 2004]" | 659 | [Viewed August 21, 2004]" |
660 | ,annotation={ | ||
661 | } | ||
641 | } | 662 | } |
642 | 663 | ||
643 | @unpublished{Blanchard02a | 664 | @unpublished{Blanchard02a |
@@ -657,10 +678,10 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni" | |||
657 | ,Month="June" | 678 | ,Month="June" |
658 | ,Year="2002" | 679 | ,Year="2002" |
659 | ,pages="289-300" | 680 | ,pages="289-300" |
660 | ,annotation=" | 681 | ,annotation={ |
661 | Measured scalability of Linux 2.4 kernel's directory-entry cache | 682 | Measured scalability of Linux 2.4 kernel's directory-entry cache |
662 | (dcache), and measured some scalability enhancements. | 683 | (dcache), and measured some scalability enhancements. |
663 | " | 684 | } |
664 | } | 685 | } |
665 | 686 | ||
666 | @Conference{McKenney02a | 687 | @Conference{McKenney02a |
@@ -674,10 +695,10 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" | |||
674 | ,note="Available: | 695 | ,note="Available: |
675 | \url{http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz} | 696 | \url{http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz} |
676 | [Viewed June 23, 2004]" | 697 | [Viewed June 23, 2004]" |
677 | ,annotation=" | 698 | ,annotation={ |
678 | Presented and compared a number of RCU implementations for the | 699 | Presented and compared a number of RCU implementations for the |
679 | Linux kernel. | 700 | Linux kernel. |
680 | " | 701 | } |
681 | } | 702 | } |
682 | 703 | ||
683 | @unpublished{Sarma02a | 704 | @unpublished{Sarma02a |
@@ -688,9 +709,9 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" | |||
688 | ,note="Available: | 709 | ,note="Available: |
689 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=102645767914212&w=2} | 710 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=102645767914212&w=2} |
690 | [Viewed June 23, 2004]" | 711 | [Viewed June 23, 2004]" |
691 | ,annotation=" | 712 | ,annotation={ |
692 | Compare fastwalk and RCU for dcache. RCU won. | 713 | Compare fastwalk and RCU for dcache. RCU won. |
693 | " | 714 | } |
694 | } | 715 | } |
695 | 716 | ||
696 | @unpublished{Barbieri02 | 717 | @unpublished{Barbieri02 |
@@ -701,9 +722,9 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" | |||
701 | ,note="Available: | 722 | ,note="Available: |
702 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=103082050621241&w=2} | 723 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=103082050621241&w=2} |
703 | [Viewed: June 23, 2004]" | 724 | [Viewed: June 23, 2004]" |
704 | ,annotation=" | 725 | ,annotation={ |
705 | Suggested RCU for vfs\_shared\_cred. | 726 | Suggested RCU for vfs\_shared\_cred. |
706 | " | 727 | } |
707 | } | 728 | } |
708 | 729 | ||
709 | @unpublished{Dickins02a | 730 | @unpublished{Dickins02a |
@@ -722,10 +743,10 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" | |||
722 | ,note="Available: | 743 | ,note="Available: |
723 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=103462075416638&w=2} | 744 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=103462075416638&w=2} |
724 | [Viewed June 23, 2004]" | 745 | [Viewed June 23, 2004]" |
725 | ,annotation=" | 746 | ,annotation={ |
726 | Performance of dcache RCU on kernbench for 16x NUMA-Q and 1x, | 747 | Performance of dcache RCU on kernbench for 16x NUMA-Q and 1x, |
727 | 2x, and 4x systems. RCU does no harm, and helps on 16x. | 748 | 2x, and 4x systems. RCU does no harm, and helps on 16x. |
728 | " | 749 | } |
729 | } | 750 | } |
730 | 751 | ||
731 | @unpublished{LinusTorvalds2003a | 752 | @unpublished{LinusTorvalds2003a |
@@ -736,14 +757,14 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" | |||
736 | ,note="Available: | 757 | ,note="Available: |
737 | \url{http://lkml.org/lkml/2003/3/9/205} | 758 | \url{http://lkml.org/lkml/2003/3/9/205} |
738 | [Viewed March 13, 2006]" | 759 | [Viewed March 13, 2006]" |
739 | ,annotation=" | 760 | ,annotation={ |
740 | Linus suggests replacing brlock with RCU and/or seqlocks: | 761 | Linus suggests replacing brlock with RCU and/or seqlocks: |
741 | . | 762 | . |
742 | 'It's entirely possible that the current user could be replaced | 763 | 'It's entirely possible that the current user could be replaced |
743 | by RCU and/or seqlocks, and we could get rid of brlocks entirely.' | 764 | by RCU and/or seqlocks, and we could get rid of brlocks entirely.' |
744 | . | 765 | . |
745 | Steve Hemminger responds by replacing them with RCU. | 766 | Steve Hemminger responds by replacing them with RCU. |
746 | " | 767 | } |
747 | } | 768 | } |
748 | 769 | ||
749 | @article{Appavoo03a | 770 | @article{Appavoo03a |
@@ -758,9 +779,9 @@ B. Rosenburg and M. Stumm and J. Xenidis" | |||
758 | ,volume="42" | 779 | ,volume="42" |
759 | ,number="1" | 780 | ,number="1" |
760 | ,pages="60-76" | 781 | ,pages="60-76" |
761 | ,annotation=" | 782 | ,annotation={ |
762 | Use of RCU to enable hot-swapping for autonomic behavior in K42. | 783 | Use of RCU to enable hot-swapping for autonomic behavior in K42. |
763 | " | 784 | } |
764 | } | 785 | } |
765 | 786 | ||
766 | @unpublished{Seigh03 | 787 | @unpublished{Seigh03 |
@@ -769,9 +790,9 @@ B. Rosenburg and M. Stumm and J. Xenidis" | |||
769 | ,Year="2003" | 790 | ,Year="2003" |
770 | ,Month="March" | 791 | ,Month="March" |
771 | ,note="email correspondence" | 792 | ,note="email correspondence" |
772 | ,annotation=" | 793 | ,annotation={ |
773 | Described the relationship of the VM/XA passive serialization to RCU. | 794 | Described the relationship of the VM/XA passive serialization to RCU. |
774 | " | 795 | } |
775 | } | 796 | } |
776 | 797 | ||
777 | @Conference{Arcangeli03 | 798 | @Conference{Arcangeli03 |
@@ -785,14 +806,12 @@ Dipankar Sarma" | |||
785 | ,year="2003" | 806 | ,year="2003" |
786 | ,month="June" | 807 | ,month="June" |
787 | ,pages="297-310" | 808 | ,pages="297-310" |
788 | ,note="Available: | 809 | ,annotation={ |
789 | \url{http://www.rdrop.com/users/paulmck/RCU/rcu.FREENIX.2003.06.14.pdf} | ||
790 | [Viewed November 21, 2007]" | ||
791 | ,annotation=" | ||
792 | Compared updated RCU implementations for the Linux kernel, and | 810 | Compared updated RCU implementations for the Linux kernel, and |
793 | described System V IPC use of RCU, including order-of-magnitude | 811 | described System V IPC use of RCU, including order-of-magnitude |
794 | performance improvements. | 812 | performance improvements. |
795 | " | 813 | http://www.rdrop.com/users/paulmck/RCU/rcu.FREENIX.2003.06.14.pdf |
814 | } | ||
796 | } | 815 | } |
797 | 816 | ||
798 | @Conference{Soules03a | 817 | @Conference{Soules03a |
@@ -820,10 +839,10 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" | |||
820 | ,note="Available: | 839 | ,note="Available: |
821 | \url{http://www.linuxjournal.com/article/6993} | 840 | \url{http://www.linuxjournal.com/article/6993} |
822 | [Viewed November 14, 2007]" | 841 | [Viewed November 14, 2007]" |
823 | ,annotation=" | 842 | ,annotation={ |
824 | Reader-friendly intro to RCU, with the infamous old-man-and-brat | 843 | Reader-friendly intro to RCU, with the infamous old-man-and-brat |
825 | cartoon. | 844 | cartoon. |
826 | " | 845 | } |
827 | } | 846 | } |
828 | 847 | ||
829 | @unpublished{Sarma03a | 848 | @unpublished{Sarma03a |
@@ -832,7 +851,9 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" | |||
832 | ,month="December" | 851 | ,month="December" |
833 | ,year="2003" | 852 | ,year="2003" |
834 | ,note="Message ID: 20031222180114.GA2248@in.ibm.com" | 853 | ,note="Message ID: 20031222180114.GA2248@in.ibm.com" |
835 | ,annotation="dipankar/ct.2004.03.27/RCUll.2003.12.22.patch" | 854 | ,annotation={ |
855 | dipankar/ct.2004.03.27/RCUll.2003.12.22.patch | ||
856 | } | ||
836 | } | 857 | } |
837 | 858 | ||
838 | @techreport{Friedberg03a | 859 | @techreport{Friedberg03a |
@@ -844,11 +865,11 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" | |||
844 | ,number="US Patent 6,662,184" | 865 | ,number="US Patent 6,662,184" |
845 | ,month="December" | 866 | ,month="December" |
846 | ,pages="112" | 867 | ,pages="112" |
847 | ,annotation=" | 868 | ,annotation={ |
848 | Applies RCU to a wildcard-search Patricia tree in order to permit | 869 | Applies RCU to a wildcard-search Patricia tree in order to permit |
849 | synchronization-free lookup. RCU is used to retain removed nodes | 870 | synchronization-free lookup. RCU is used to retain removed nodes |
850 | for a grace period before freeing them. | 871 | for a grace period before freeing them. |
851 | " | 872 | } |
852 | } | 873 | } |
853 | 874 | ||
854 | @article{McKenney04a | 875 | @article{McKenney04a |
@@ -860,12 +881,11 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" | |||
860 | ,volume="1" | 881 | ,volume="1" |
861 | ,number="118" | 882 | ,number="118" |
862 | ,pages="38-46" | 883 | ,pages="38-46" |
863 | ,note="Available: | 884 | ,annotation={ |
864 | \url{http://www.linuxjournal.com/node/7124} | ||
865 | [Viewed December 26, 2010]" | ||
866 | ,annotation=" | ||
867 | Reader friendly intro to dcache and RCU. | 885 | Reader friendly intro to dcache and RCU. |
868 | " | 886 | http://www.linuxjournal.com/node/7124 |
887 | [Viewed December 26, 2010] | ||
888 | } | ||
869 | } | 889 | } |
870 | 890 | ||
871 | @Conference{McKenney04b | 891 | @Conference{McKenney04b |
@@ -879,10 +899,10 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" | |||
879 | \url{http://www.linux.org.au/conf/2004/abstracts.html#90} | 899 | \url{http://www.linux.org.au/conf/2004/abstracts.html#90} |
880 | \url{http://www.rdrop.com/users/paulmck/RCU/lockperf.2004.01.17a.pdf} | 900 | \url{http://www.rdrop.com/users/paulmck/RCU/lockperf.2004.01.17a.pdf} |
881 | [Viewed June 23, 2004]" | 901 | [Viewed June 23, 2004]" |
882 | ,annotation=" | 902 | ,annotation={ |
883 | Compares performance of RCU to that of other locking primitives | 903 | Compares performance of RCU to that of other locking primitives |
884 | over a number of CPUs (x86, Opteron, Itanium, and PPC). | 904 | over a number of CPUs (x86, Opteron, Itanium, and PPC). |
885 | " | 905 | } |
886 | } | 906 | } |
887 | 907 | ||
888 | @unpublished{Sarma04a | 908 | @unpublished{Sarma04a |
@@ -891,7 +911,9 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" | |||
891 | ,month="March" | 911 | ,month="March" |
892 | ,year="2004" | 912 | ,year="2004" |
893 | ,note="\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108003746402892&w=2}" | 913 | ,note="\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108003746402892&w=2}" |
894 | ,annotation="Head of thread: dipankar/2004.03.23/rcu-low-lat.1.patch" | 914 | ,annotation={ |
915 | Head of thread: dipankar/2004.03.23/rcu-low-lat.1.patch | ||
916 | } | ||
895 | } | 917 | } |
896 | 918 | ||
897 | @unpublished{Sarma04b | 919 | @unpublished{Sarma04b |
@@ -900,7 +922,9 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" | |||
900 | ,month="March" | 922 | ,month="March" |
901 | ,year="2004" | 923 | ,year="2004" |
902 | ,note="\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108016474829546&w=2}" | 924 | ,note="\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108016474829546&w=2}" |
903 | ,annotation="dipankar/rcuth.2004.03.24/rcu-throttle.patch" | 925 | ,annotation={ |
926 | dipankar/rcuth.2004.03.24/rcu-throttle.patch | ||
927 | } | ||
904 | } | 928 | } |
905 | 929 | ||
906 | @unpublished{Spraul04a | 930 | @unpublished{Spraul04a |
@@ -911,9 +935,9 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" | |||
911 | ,note="Available: | 935 | ,note="Available: |
912 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108546407726602&w=2} | 936 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108546407726602&w=2} |
913 | [Viewed June 23, 2004]" | 937 | [Viewed June 23, 2004]" |
914 | ,annotation=" | 938 | ,annotation={ |
915 | Hierarchical-bitmap patch for RCU infrastructure. | 939 | Hierarchical-bitmap patch for RCU infrastructure. |
916 | " | 940 | } |
917 | } | 941 | } |
918 | 942 | ||
919 | @unpublished{Steiner04a | 943 | @unpublished{Steiner04a |
@@ -950,10 +974,12 @@ Realtime Applications" | |||
950 | ,year="2004" | 974 | ,year="2004" |
951 | ,month="June" | 975 | ,month="June" |
952 | ,pages="182-191" | 976 | ,pages="182-191" |
953 | ,annotation=" | 977 | ,annotation={ |
954 | Describes and compares a number of modifications to the Linux RCU | 978 | Describes and compares a number of modifications to the Linux RCU |
955 | implementation that make it friendly to realtime applications. | 979 | implementation that make it friendly to realtime applications. |
956 | " | 980 | https://www.usenix.org/conference/2004-usenix-annual-technical-conference/making-rcu-safe-deep-sub-millisecond-response |
981 | [Viewed July 26, 2012] | ||
982 | } | ||
957 | } | 983 | } |
958 | 984 | ||
959 | @phdthesis{PaulEdwardMcKenneyPhD | 985 | @phdthesis{PaulEdwardMcKenneyPhD |
@@ -964,14 +990,13 @@ in Operating System Kernels" | |||
964 | ,school="OGI School of Science and Engineering at | 990 | ,school="OGI School of Science and Engineering at |
965 | Oregon Health and Sciences University" | 991 | Oregon Health and Sciences University" |
966 | ,year="2004" | 992 | ,year="2004" |
967 | ,note="Available: | 993 | ,annotation={ |
968 | \url{http://www.rdrop.com/users/paulmck/RCU/RCUdissertation.2004.07.14e1.pdf} | ||
969 | [Viewed October 15, 2004]" | ||
970 | ,annotation=" | ||
971 | Describes RCU implementations and presents design patterns | 994 | Describes RCU implementations and presents design patterns |
972 | corresponding to common uses of RCU in several operating-system | 995 | corresponding to common uses of RCU in several operating-system |
973 | kernels. | 996 | kernels. |
974 | " | 997 | http://www.rdrop.com/users/paulmck/RCU/RCUdissertation.2004.07.14e1.pdf |
998 | [Viewed October 15, 2004] | ||
999 | } | ||
975 | } | 1000 | } |
976 | 1001 | ||
977 | @unpublished{PaulEMcKenney2004rcu:dereference | 1002 | @unpublished{PaulEMcKenney2004rcu:dereference |
@@ -982,9 +1007,9 @@ Oregon Health and Sciences University" | |||
982 | ,note="Available: | 1007 | ,note="Available: |
983 | \url{http://lkml.org/lkml/2004/8/6/237} | 1008 | \url{http://lkml.org/lkml/2004/8/6/237} |
984 | [Viewed June 8, 2010]" | 1009 | [Viewed June 8, 2010]" |
985 | ,annotation=" | 1010 | ,annotation={ |
986 | Introduce rcu_dereference(). | 1011 | Introduce rcu_dereference(). |
987 | " | 1012 | } |
988 | } | 1013 | } |
989 | 1014 | ||
990 | @unpublished{JimHouston04a | 1015 | @unpublished{JimHouston04a |
@@ -995,11 +1020,11 @@ Oregon Health and Sciences University" | |||
995 | ,note="Available: | 1020 | ,note="Available: |
996 | \url{http://lkml.org/lkml/2004/8/30/87} | 1021 | \url{http://lkml.org/lkml/2004/8/30/87} |
997 | [Viewed February 17, 2005]" | 1022 | [Viewed February 17, 2005]" |
998 | ,annotation=" | 1023 | ,annotation={ |
999 | Uses active code in rcu_read_lock() and rcu_read_unlock() to | 1024 | Uses active code in rcu_read_lock() and rcu_read_unlock() to |
1000 | make RCU happen, allowing RCU to function on CPUs that do not | 1025 | make RCU happen, allowing RCU to function on CPUs that do not |
1001 | receive a scheduling-clock interrupt. | 1026 | receive a scheduling-clock interrupt. |
1002 | " | 1027 | } |
1003 | } | 1028 | } |
1004 | 1029 | ||
1005 | @unpublished{TomHart04a | 1030 | @unpublished{TomHart04a |
@@ -1010,9 +1035,9 @@ Oregon Health and Sciences University" | |||
1010 | ,note="Available: | 1035 | ,note="Available: |
1011 | \url{http://www.cs.toronto.edu/~tomhart/masters_thesis.html} | 1036 | \url{http://www.cs.toronto.edu/~tomhart/masters_thesis.html} |
1012 | [Viewed October 15, 2004]" | 1037 | [Viewed October 15, 2004]" |
1013 | ,annotation=" | 1038 | ,annotation={ |
1014 | Proposes comparing RCU to lock-free methods for the Linux kernel. | 1039 | Proposes comparing RCU to lock-free methods for the Linux kernel. |
1015 | " | 1040 | } |
1016 | } | 1041 | } |
1017 | 1042 | ||
1018 | @unpublished{Vaddagiri04a | 1043 | @unpublished{Vaddagiri04a |
@@ -1023,9 +1048,9 @@ Oregon Health and Sciences University" | |||
1023 | ,note="Available: | 1048 | ,note="Available: |
1024 | \url{http://marc.theaimsgroup.com/?t=109395731700004&r=1&w=2} | 1049 | \url{http://marc.theaimsgroup.com/?t=109395731700004&r=1&w=2} |
1025 | [Viewed October 18, 2004]" | 1050 | [Viewed October 18, 2004]" |
1026 | ,annotation=" | 1051 | ,annotation={ |
1027 | Srivatsa's RCU patch for tcp_ehash lookup. | 1052 | Srivatsa's RCU patch for tcp_ehash lookup. |
1028 | " | 1053 | } |
1029 | } | 1054 | } |
1030 | 1055 | ||
1031 | @unpublished{Thirumalai04a | 1056 | @unpublished{Thirumalai04a |
@@ -1036,9 +1061,9 @@ Oregon Health and Sciences University" | |||
1036 | ,note="Available: | 1061 | ,note="Available: |
1037 | \url{http://marc.theaimsgroup.com/?t=109144217400003&r=1&w=2} | 1062 | \url{http://marc.theaimsgroup.com/?t=109144217400003&r=1&w=2} |
1038 | [Viewed October 18, 2004]" | 1063 | [Viewed October 18, 2004]" |
1039 | ,annotation=" | 1064 | ,annotation={ |
1040 | Ravikiran's lockfree FD patch. | 1065 | Ravikiran's lockfree FD patch. |
1041 | " | 1066 | } |
1042 | } | 1067 | } |
1043 | 1068 | ||
1044 | @unpublished{Thirumalai04b | 1069 | @unpublished{Thirumalai04b |
@@ -1049,9 +1074,9 @@ Oregon Health and Sciences University" | |||
1049 | ,note="Available: | 1074 | ,note="Available: |
1050 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=109152521410459&w=2} | 1075 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=109152521410459&w=2} |
1051 | [Viewed October 18, 2004]" | 1076 | [Viewed October 18, 2004]" |
1052 | ,annotation=" | 1077 | ,annotation={ |
1053 | Ravikiran's lockfree FD patch. | 1078 | Ravikiran's lockfree FD patch. |
1054 | " | 1079 | } |
1055 | } | 1080 | } |
1056 | 1081 | ||
1057 | @unpublished{PaulEMcKenney2004rcu:assign:pointer | 1082 | @unpublished{PaulEMcKenney2004rcu:assign:pointer |
@@ -1062,9 +1087,9 @@ Oregon Health and Sciences University" | |||
1062 | ,note="Available: | 1087 | ,note="Available: |
1063 | \url{http://lkml.org/lkml/2004/10/23/241} | 1088 | \url{http://lkml.org/lkml/2004/10/23/241} |
1064 | [Viewed June 8, 2010]" | 1089 | [Viewed June 8, 2010]" |
1065 | ,annotation=" | 1090 | ,annotation={ |
1066 | Introduce rcu_assign_pointer(). | 1091 | Introduce rcu_assign_pointer(). |
1067 | " | 1092 | } |
1068 | } | 1093 | } |
1069 | 1094 | ||
1070 | @unpublished{JamesMorris04a | 1095 | @unpublished{JamesMorris04a |
@@ -1073,12 +1098,12 @@ Oregon Health and Sciences University" | |||
1073 | ,day="15" | 1098 | ,day="15" |
1074 | ,month="November" | 1099 | ,month="November" |
1075 | ,year="2004" | 1100 | ,year="2004" |
1076 | ,note="Available: | 1101 | ,note="\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=110054979416004&w=2}" |
1077 | \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=110054979416004&w=2} | 1102 | ,annotation={ |
1078 | [Viewed December 10, 2004]" | ||
1079 | ,annotation=" | ||
1080 | James Morris posts Kaigai Kohei's patch to LKML. | 1103 | James Morris posts Kaigai Kohei's patch to LKML. |
1081 | " | 1104 | [Viewed December 10, 2004] |
1105 | Kaigai's patch is at https://lkml.org/lkml/2004/9/27/52 | ||
1106 | } | ||
1082 | } | 1107 | } |
1083 | 1108 | ||
1084 | @unpublished{JamesMorris04b | 1109 | @unpublished{JamesMorris04b |
@@ -1089,9 +1114,9 @@ Oregon Health and Sciences University" | |||
1089 | ,note="Available: | 1114 | ,note="Available: |
1090 | \url{http://www.livejournal.com/users/james_morris/2153.html} | 1115 | \url{http://www.livejournal.com/users/james_morris/2153.html} |
1091 | [Viewed December 10, 2004]" | 1116 | [Viewed December 10, 2004]" |
1092 | ,annotation=" | 1117 | ,annotation={ |
1093 | RCU helps SELinux performance. ;-) Made LWN. | 1118 | RCU helps SELinux performance. ;-) Made LWN. |
1094 | " | 1119 | } |
1095 | } | 1120 | } |
1096 | 1121 | ||
1097 | @unpublished{PaulMcKenney2005RCUSemantics | 1122 | @unpublished{PaulMcKenney2005RCUSemantics |
@@ -1103,9 +1128,9 @@ Oregon Health and Sciences University" | |||
1103 | ,note="Available: | 1128 | ,note="Available: |
1104 | \url{http://www.rdrop.com/users/paulmck/RCU/rcu-semantics.2005.01.30a.pdf} | 1129 | \url{http://www.rdrop.com/users/paulmck/RCU/rcu-semantics.2005.01.30a.pdf} |
1105 | [Viewed December 6, 2009]" | 1130 | [Viewed December 6, 2009]" |
1106 | ,annotation=" | 1131 | ,annotation={ |
1107 | Early derivation of RCU semantics. | 1132 | Early derivation of RCU semantics. |
1108 | " | 1133 | } |
1109 | } | 1134 | } |
1110 | 1135 | ||
1111 | @unpublished{PaulMcKenney2005e | 1136 | @unpublished{PaulMcKenney2005e |
@@ -1117,10 +1142,10 @@ Oregon Health and Sciences University" | |||
1117 | ,note="Available: | 1142 | ,note="Available: |
1118 | \url{http://lkml.org/lkml/2005/3/17/199} | 1143 | \url{http://lkml.org/lkml/2005/3/17/199} |
1119 | [Viewed September 5, 2005]" | 1144 | [Viewed September 5, 2005]" |
1120 | ,annotation=" | 1145 | ,annotation={ |
1121 | First posting showing how RCU can be safely adapted for | 1146 | First posting showing how RCU can be safely adapted for |
1122 | preemptable RCU read side critical sections. | 1147 | preemptable RCU read side critical sections. |
1123 | " | 1148 | } |
1124 | } | 1149 | } |
1125 | 1150 | ||
1126 | @unpublished{EsbenNeilsen2005a | 1151 | @unpublished{EsbenNeilsen2005a |
@@ -1132,12 +1157,12 @@ Oregon Health and Sciences University" | |||
1132 | ,note="Available: | 1157 | ,note="Available: |
1133 | \url{http://lkml.org/lkml/2005/3/18/122} | 1158 | \url{http://lkml.org/lkml/2005/3/18/122} |
1134 | [Viewed March 30, 2006]" | 1159 | [Viewed March 30, 2006]" |
1135 | ,annotation=" | 1160 | ,annotation={ |
1136 | Esben Neilsen suggests read-side suppression of grace-period | 1161 | Esben Neilsen suggests read-side suppression of grace-period |
1137 | processing for crude-but-workable realtime RCU. The downside | 1162 | processing for crude-but-workable realtime RCU. The downside |
1138 | is indefinite grace periods...But this is OK for experimentation | 1163 | is indefinite grace periods... But this is OK for experimentation |
1139 | and testing. | 1164 | and testing. |
1140 | " | 1165 | } |
1141 | } | 1166 | } |
1142 | 1167 | ||
1143 | @unpublished{TomHart05a | 1168 | @unpublished{TomHart05a |
@@ -1149,10 +1174,10 @@ Data Structures" | |||
1149 | ,note="Available: | 1174 | ,note="Available: |
1150 | \url{ftp://ftp.cs.toronto.edu/csrg-technical-reports/515/} | 1175 | \url{ftp://ftp.cs.toronto.edu/csrg-technical-reports/515/} |
1151 | [Viewed March 4, 2005]" | 1176 | [Viewed March 4, 2005]" |
1152 | ,annotation=" | 1177 | ,annotation={ |
1153 | Comparison of RCU, QBSR, and EBSR. RCU wins for read-mostly | 1178 | Comparison of RCU, QBSR, and EBSR. RCU wins for read-mostly |
1154 | workloads. ;-) | 1179 | workloads. ;-) |
1155 | " | 1180 | } |
1156 | } | 1181 | } |
1157 | 1182 | ||
1158 | @unpublished{JonCorbet2005DeprecateSyncKernel | 1183 | @unpublished{JonCorbet2005DeprecateSyncKernel |
@@ -1164,10 +1189,10 @@ Data Structures" | |||
1164 | ,note="Available: | 1189 | ,note="Available: |
1165 | \url{http://lwn.net/Articles/134484/} | 1190 | \url{http://lwn.net/Articles/134484/} |
1166 | [Viewed May 3, 2005]" | 1191 | [Viewed May 3, 2005]" |
1167 | ,annotation=" | 1192 | ,annotation={ |
1168 | Jon Corbet describes deprecation of synchronize_kernel() | 1193 | Jon Corbet describes deprecation of synchronize_kernel() |
1169 | in favor of synchronize_rcu() and synchronize_sched(). | 1194 | in favor of synchronize_rcu() and synchronize_sched(). |
1170 | " | 1195 | } |
1171 | } | 1196 | } |
1172 | 1197 | ||
1173 | @unpublished{PaulMcKenney05a | 1198 | @unpublished{PaulMcKenney05a |
@@ -1178,10 +1203,10 @@ Data Structures" | |||
1178 | ,note="Available: | 1203 | ,note="Available: |
1179 | \url{http://lkml.org/lkml/2005/5/9/185} | 1204 | \url{http://lkml.org/lkml/2005/5/9/185} |
1180 | [Viewed May 13, 2005]" | 1205 | [Viewed May 13, 2005]" |
1181 | ,annotation=" | 1206 | ,annotation={ |
1182 | First publication of working lock-based deferred free patches | 1207 | First publication of working lock-based deferred free patches |
1183 | for the CONFIG_PREEMPT_RT environment. | 1208 | for the CONFIG_PREEMPT_RT environment. |
1184 | " | 1209 | } |
1185 | } | 1210 | } |
1186 | 1211 | ||
1187 | @conference{PaulMcKenney05b | 1212 | @conference{PaulMcKenney05b |
@@ -1194,10 +1219,10 @@ Data Structures" | |||
1194 | ,note="Available: | 1219 | ,note="Available: |
1195 | \url{http://www.rdrop.com/users/paulmck/RCU/realtimeRCU.2005.04.23a.pdf} | 1220 | \url{http://www.rdrop.com/users/paulmck/RCU/realtimeRCU.2005.04.23a.pdf} |
1196 | [Viewed May 13, 2005]" | 1221 | [Viewed May 13, 2005]" |
1197 | ,annotation=" | 1222 | ,annotation={ |
1198 | Realtime turns into making RCU yet more realtime friendly. | 1223 | Realtime turns into making RCU yet more realtime friendly. |
1199 | http://lca2005.linux.org.au/Papers/Paul%20McKenney/Towards%20Hard%20Realtime%20Response%20from%20the%20Linux%20Kernel/LKS.2005.04.22a.pdf | 1224 | http://lca2005.linux.org.au/Papers/Paul%20McKenney/Towards%20Hard%20Realtime%20Response%20from%20the%20Linux%20Kernel/LKS.2005.04.22a.pdf |
1200 | " | 1225 | } |
1201 | } | 1226 | } |
1202 | 1227 | ||
1203 | @unpublished{PaulEMcKenneyHomePage | 1228 | @unpublished{PaulEMcKenneyHomePage |
@@ -1208,9 +1233,9 @@ Data Structures" | |||
1208 | ,note="Available: | 1233 | ,note="Available: |
1209 | \url{http://www.rdrop.com/users/paulmck/} | 1234 | \url{http://www.rdrop.com/users/paulmck/} |
1210 | [Viewed May 25, 2005]" | 1235 | [Viewed May 25, 2005]" |
1211 | ,annotation=" | 1236 | ,annotation={ |
1212 | Paul McKenney's home page. | 1237 | Paul McKenney's home page. |
1213 | " | 1238 | } |
1214 | } | 1239 | } |
1215 | 1240 | ||
1216 | @unpublished{PaulEMcKenneyRCUPage | 1241 | @unpublished{PaulEMcKenneyRCUPage |
@@ -1221,9 +1246,9 @@ Data Structures" | |||
1221 | ,note="Available: | 1246 | ,note="Available: |
1222 | \url{http://www.rdrop.com/users/paulmck/RCU} | 1247 | \url{http://www.rdrop.com/users/paulmck/RCU} |
1223 | [Viewed May 25, 2005]" | 1248 | [Viewed May 25, 2005]" |
1224 | ,annotation=" | 1249 | ,annotation={ |
1225 | Paul McKenney's RCU page. | 1250 | Paul McKenney's RCU page. |
1226 | " | 1251 | } |
1227 | } | 1252 | } |
1228 | 1253 | ||
1229 | @unpublished{JosephSeigh2005a | 1254 | @unpublished{JosephSeigh2005a |
@@ -1232,10 +1257,10 @@ Data Structures" | |||
1232 | ,month="July" | 1257 | ,month="July" |
1233 | ,year="2005" | 1258 | ,year="2005" |
1234 | ,note="Personal communication" | 1259 | ,note="Personal communication" |
1235 | ,annotation=" | 1260 | ,annotation={ |
1236 | Joe Seigh announcing his atomic-ptr-plus project. | 1261 | Joe Seigh announcing his atomic-ptr-plus project. |
1237 | http://sourceforge.net/projects/atomic-ptr-plus/ | 1262 | http://sourceforge.net/projects/atomic-ptr-plus/ |
1238 | " | 1263 | } |
1239 | } | 1264 | } |
1240 | 1265 | ||
1241 | @unpublished{JosephSeigh2005b | 1266 | @unpublished{JosephSeigh2005b |
@@ -1247,9 +1272,9 @@ Data Structures" | |||
1247 | ,note="Available: | 1272 | ,note="Available: |
1248 | \url{http://sourceforge.net/projects/atomic-ptr-plus/} | 1273 | \url{http://sourceforge.net/projects/atomic-ptr-plus/} |
1249 | [Viewed August 8, 2005]" | 1274 | [Viewed August 8, 2005]" |
1250 | ,annotation=" | 1275 | ,annotation={ |
1251 | Joe Seigh's atomic-ptr-plus project. | 1276 | Joe Seigh's atomic-ptr-plus project. |
1252 | " | 1277 | } |
1253 | } | 1278 | } |
1254 | 1279 | ||
1255 | @unpublished{PaulMcKenney2005c | 1280 | @unpublished{PaulMcKenney2005c |
@@ -1261,9 +1286,9 @@ Data Structures" | |||
1261 | ,note="Available: | 1286 | ,note="Available: |
1262 | \url{http://lkml.org/lkml/2005/8/1/155} | 1287 | \url{http://lkml.org/lkml/2005/8/1/155} |
1263 | [Viewed March 14, 2006]" | 1288 | [Viewed March 14, 2006]" |
1264 | ,annotation=" | 1289 | ,annotation={ |
1265 | First operating counter-based realtime RCU patch posted to LKML. | 1290 | First operating counter-based realtime RCU patch posted to LKML. |
1266 | " | 1291 | } |
1267 | } | 1292 | } |
1268 | 1293 | ||
1269 | @unpublished{PaulMcKenney2005d | 1294 | @unpublished{PaulMcKenney2005d |
@@ -1275,11 +1300,11 @@ Data Structures" | |||
1275 | ,note="Available: | 1300 | ,note="Available: |
1276 | \url{http://lkml.org/lkml/2005/8/8/108} | 1301 | \url{http://lkml.org/lkml/2005/8/8/108} |
1277 | [Viewed March 14, 2006]" | 1302 | [Viewed March 14, 2006]" |
1278 | ,annotation=" | 1303 | ,annotation={ |
1279 | First operating counter-based realtime RCU patch posted to LKML, | 1304 | First operating counter-based realtime RCU patch posted to LKML, |
1280 | but fixed so that various unusual combinations of configuration | 1305 | but fixed so that various unusual combinations of configuration |
1281 | parameters all function properly. | 1306 | parameters all function properly. |
1282 | " | 1307 | } |
1283 | } | 1308 | } |
1284 | 1309 | ||
1285 | @unpublished{PaulMcKenney2005rcutorture | 1310 | @unpublished{PaulMcKenney2005rcutorture |
@@ -1291,9 +1316,25 @@ Data Structures" | |||
1291 | ,note="Available: | 1316 | ,note="Available: |
1292 | \url{http://lkml.org/lkml/2005/10/1/70} | 1317 | \url{http://lkml.org/lkml/2005/10/1/70} |
1293 | [Viewed March 14, 2006]" | 1318 | [Viewed March 14, 2006]" |
1294 | ,annotation=" | 1319 | ,annotation={ |
1295 | First rcutorture patch. | 1320 | First rcutorture patch. |
1296 | " | 1321 | } |
1322 | } | ||
1323 | |||
1324 | @unpublished{DavidSMiller2006HashedLocking | ||
1325 | ,Author="David S. Miller" | ||
1326 | ,Title="Re: [{PATCH}, {RFC}] {RCU} : {OOM} avoidance and lower latency" | ||
1327 | ,month="January" | ||
1328 | ,day="6" | ||
1329 | ,year="2006" | ||
1330 | ,note="Available: | ||
1331 | \url{https://lkml.org/lkml/2006/1/7/22} | ||
1332 | [Viewed February 29, 2012]" | ||
1333 | ,annotation={ | ||
1334 | David Miller's view on hashed arrays of locks: used to really | ||
1335 | like it, but time he saw an opportunity for this technique, | ||
1336 | something else always proved superior. Partitioning or RCU. ;-) | ||
1337 | } | ||
1297 | } | 1338 | } |
1298 | 1339 | ||
1299 | @conference{ThomasEHart2006a | 1340 | @conference{ThomasEHart2006a |
@@ -1309,10 +1350,10 @@ Distributed Processing Symposium" | |||
1309 | ,note="Available: | 1350 | ,note="Available: |
1310 | \url{http://www.rdrop.com/users/paulmck/RCU/hart_ipdps06.pdf} | 1351 | \url{http://www.rdrop.com/users/paulmck/RCU/hart_ipdps06.pdf} |
1311 | [Viewed April 28, 2008]" | 1352 | [Viewed April 28, 2008]" |
1312 | ,annotation=" | 1353 | ,annotation={ |
1313 | Compares QSBR, HPBR, EBR, and lock-free reference counting. | 1354 | Compares QSBR, HPBR, EBR, and lock-free reference counting. |
1314 | http://www.cs.toronto.edu/~tomhart/perflab/ipdps06.tgz | 1355 | http://www.cs.toronto.edu/~tomhart/perflab/ipdps06.tgz |
1315 | " | 1356 | } |
1316 | } | 1357 | } |
1317 | 1358 | ||
1318 | @unpublished{NickPiggin2006radixtree | 1359 | @unpublished{NickPiggin2006radixtree |
@@ -1324,9 +1365,9 @@ Distributed Processing Symposium" | |||
1324 | ,note="Available: | 1365 | ,note="Available: |
1325 | \url{http://lkml.org/lkml/2006/6/20/238} | 1366 | \url{http://lkml.org/lkml/2006/6/20/238} |
1326 | [Viewed March 25, 2008]" | 1367 | [Viewed March 25, 2008]" |
1327 | ,annotation=" | 1368 | ,annotation={ |
1328 | RCU-protected radix tree. | 1369 | RCU-protected radix tree. |
1329 | " | 1370 | } |
1330 | } | 1371 | } |
1331 | 1372 | ||
1332 | @Conference{PaulEMcKenney2006b | 1373 | @Conference{PaulEMcKenney2006b |
@@ -1341,9 +1382,9 @@ Suparna Bhattacharya" | |||
1341 | \url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184} | 1382 | \url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184} |
1342 | \url{http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf} | 1383 | \url{http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf} |
1343 | [Viewed January 1, 2007]" | 1384 | [Viewed January 1, 2007]" |
1344 | ,annotation=" | 1385 | ,annotation={ |
1345 | Described how to improve the -rt implementation of realtime RCU. | 1386 | Described how to improve the -rt implementation of realtime RCU. |
1346 | " | 1387 | } |
1347 | } | 1388 | } |
1348 | 1389 | ||
1349 | @unpublished{WikipediaRCU | 1390 | @unpublished{WikipediaRCU |
@@ -1354,12 +1395,11 @@ Canis Rufus and Zoicon5 and Anome and Hal Eisen" | |||
1354 | ,month="July" | 1395 | ,month="July" |
1355 | ,day="8" | 1396 | ,day="8" |
1356 | ,year="2006" | 1397 | ,year="2006" |
1357 | ,note="Available: | 1398 | ,note="\url{http://en.wikipedia.org/wiki/Read-copy-update}" |
1358 | \url{http://en.wikipedia.org/wiki/Read-copy-update} | 1399 | ,annotation={ |
1359 | [Viewed August 21, 2006]" | ||
1360 | ,annotation=" | ||
1361 | Wikipedia RCU page as of July 8 2006. | 1400 | Wikipedia RCU page as of July 8 2006. |
1362 | " | 1401 | [Viewed August 21, 2006] |
1402 | } | ||
1363 | } | 1403 | } |
1364 | 1404 | ||
1365 | @Conference{NickPiggin2006LocklessPageCache | 1405 | @Conference{NickPiggin2006LocklessPageCache |
@@ -1372,9 +1412,9 @@ Canis Rufus and Zoicon5 and Anome and Hal Eisen" | |||
1372 | ,note="Available: | 1412 | ,note="Available: |
1373 | \url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184} | 1413 | \url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184} |
1374 | [Viewed January 11, 2009]" | 1414 | [Viewed January 11, 2009]" |
1375 | ,annotation=" | 1415 | ,annotation={ |
1376 | Uses RCU-protected radix tree for a lockless page cache. | 1416 | Uses RCU-protected radix tree for a lockless page cache. |
1377 | " | 1417 | } |
1378 | } | 1418 | } |
1379 | 1419 | ||
1380 | @unpublished{PaulEMcKenney2006c | 1420 | @unpublished{PaulEMcKenney2006c |
@@ -1388,9 +1428,9 @@ Canis Rufus and Zoicon5 and Anome and Hal Eisen" | |||
1388 | Revised: | 1428 | Revised: |
1389 | \url{http://www.rdrop.com/users/paulmck/RCU/srcu.2007.01.14a.pdf} | 1429 | \url{http://www.rdrop.com/users/paulmck/RCU/srcu.2007.01.14a.pdf} |
1390 | [Viewed August 21, 2006]" | 1430 | [Viewed August 21, 2006]" |
1391 | ,annotation=" | 1431 | ,annotation={ |
1392 | LWN article introducing SRCU. | 1432 | LWN article introducing SRCU. |
1393 | " | 1433 | } |
1394 | } | 1434 | } |
1395 | 1435 | ||
1396 | @unpublished{RobertOlsson2006a | 1436 | @unpublished{RobertOlsson2006a |
@@ -1399,12 +1439,11 @@ Revised: | |||
1399 | ,month="August" | 1439 | ,month="August" |
1400 | ,day="18" | 1440 | ,day="18" |
1401 | ,year="2006" | 1441 | ,year="2006" |
1402 | ,note="Available: | 1442 | ,note="\url{http://www.nada.kth.se/~snilsson/publications/TRASH/trash.pdf}" |
1403 | \url{http://www.nada.kth.se/~snilsson/publications/TRASH/trash.pdf} | 1443 | ,annotation={ |
1404 | [Viewed March 4, 2011]" | ||
1405 | ,annotation=" | ||
1406 | RCU-protected dynamic trie-hash combination. | 1444 | RCU-protected dynamic trie-hash combination. |
1407 | " | 1445 | [Viewed March 4, 2011] |
1446 | } | ||
1408 | } | 1447 | } |
1409 | 1448 | ||
1410 | @unpublished{ChristophHellwig2006RCU2SRCU | 1449 | @unpublished{ChristophHellwig2006RCU2SRCU |
@@ -1426,10 +1465,10 @@ Revised: | |||
1426 | ,note="Available: | 1465 | ,note="Available: |
1427 | \url{http://www.rdrop.com/users/paulmck/RCU/linuxusage.html} | 1466 | \url{http://www.rdrop.com/users/paulmck/RCU/linuxusage.html} |
1428 | [Viewed January 14, 2007]" | 1467 | [Viewed January 14, 2007]" |
1429 | ,annotation=" | 1468 | ,annotation={ |
1430 | Paul McKenney's RCU page showing graphs plotting Linux-kernel | 1469 | Paul McKenney's RCU page showing graphs plotting Linux-kernel |
1431 | usage of RCU. | 1470 | usage of RCU. |
1432 | " | 1471 | } |
1433 | } | 1472 | } |
1434 | 1473 | ||
1435 | @unpublished{PaulEMcKenneyRCUusageRawDataPage | 1474 | @unpublished{PaulEMcKenneyRCUusageRawDataPage |
@@ -1440,10 +1479,10 @@ Revised: | |||
1440 | ,note="Available: | 1479 | ,note="Available: |
1441 | \url{http://www.rdrop.com/users/paulmck/RCU/linuxusage/rculocktab.html} | 1480 | \url{http://www.rdrop.com/users/paulmck/RCU/linuxusage/rculocktab.html} |
1442 | [Viewed January 14, 2007]" | 1481 | [Viewed January 14, 2007]" |
1443 | ,annotation=" | 1482 | ,annotation={ |
1444 | Paul McKenney's RCU page showing Linux usage of RCU in tabular | 1483 | Paul McKenney's RCU page showing Linux usage of RCU in tabular |
1445 | form, with links to corresponding cscope databases. | 1484 | form, with links to corresponding cscope databases. |
1446 | " | 1485 | } |
1447 | } | 1486 | } |
1448 | 1487 | ||
1449 | @unpublished{GauthamShenoy2006RCUrwlock | 1488 | @unpublished{GauthamShenoy2006RCUrwlock |
@@ -1455,13 +1494,13 @@ Revised: | |||
1455 | ,note="Available: | 1494 | ,note="Available: |
1456 | \url{http://lkml.org/lkml/2006/10/26/73} | 1495 | \url{http://lkml.org/lkml/2006/10/26/73} |
1457 | [Viewed January 26, 2009]" | 1496 | [Viewed January 26, 2009]" |
1458 | ,annotation=" | 1497 | ,annotation={ |
1459 | RCU-based reader-writer lock that allows readers to proceed with | 1498 | RCU-based reader-writer lock that allows readers to proceed with |
1460 | no memory barriers or atomic instruction in absence of writers. | 1499 | no memory barriers or atomic instruction in absence of writers. |
1461 | If writer do show up, readers must of course wait as required by | 1500 | If writer do show up, readers must of course wait as required by |
1462 | the semantics of reader-writer locking. This is a recursive | 1501 | the semantics of reader-writer locking. This is a recursive |
1463 | lock. | 1502 | lock. |
1464 | " | 1503 | } |
1465 | } | 1504 | } |
1466 | 1505 | ||
1467 | @unpublished{JensAxboe2006SlowSRCU | 1506 | @unpublished{JensAxboe2006SlowSRCU |
@@ -1474,11 +1513,11 @@ Revised: | |||
1474 | ,note="Available: | 1513 | ,note="Available: |
1475 | \url{http://lkml.org/lkml/2006/11/17/56} | 1514 | \url{http://lkml.org/lkml/2006/11/17/56} |
1476 | [Viewed May 28, 2007]" | 1515 | [Viewed May 28, 2007]" |
1477 | ,annotation=" | 1516 | ,annotation={ |
1478 | SRCU's grace periods are too slow for Jens, even after a | 1517 | SRCU's grace periods are too slow for Jens, even after a |
1479 | factor-of-three speedup. | 1518 | factor-of-three speedup. |
1480 | Sped-up version of SRCU at http://lkml.org/lkml/2006/11/17/359. | 1519 | Sped-up version of SRCU at http://lkml.org/lkml/2006/11/17/359. |
1481 | " | 1520 | } |
1482 | } | 1521 | } |
1483 | 1522 | ||
1484 | @unpublished{OlegNesterov2006QRCU | 1523 | @unpublished{OlegNesterov2006QRCU |
@@ -1491,10 +1530,10 @@ Revised: | |||
1491 | ,note="Available: | 1530 | ,note="Available: |
1492 | \url{http://lkml.org/lkml/2006/11/19/69} | 1531 | \url{http://lkml.org/lkml/2006/11/19/69} |
1493 | [Viewed May 28, 2007]" | 1532 | [Viewed May 28, 2007]" |
1494 | ,annotation=" | 1533 | ,annotation={ |
1495 | First cut of QRCU. Expanded/corrected versions followed. | 1534 | First cut of QRCU. Expanded/corrected versions followed. |
1496 | Used to be OlegNesterov2007QRCU, now time-corrected. | 1535 | Used to be OlegNesterov2007QRCU, now time-corrected. |
1497 | " | 1536 | } |
1498 | } | 1537 | } |
1499 | 1538 | ||
1500 | @unpublished{OlegNesterov2006aQRCU | 1539 | @unpublished{OlegNesterov2006aQRCU |
@@ -1506,10 +1545,10 @@ Revised: | |||
1506 | ,note="Available: | 1545 | ,note="Available: |
1507 | \url{http://lkml.org/lkml/2006/11/29/330} | 1546 | \url{http://lkml.org/lkml/2006/11/29/330} |
1508 | [Viewed November 26, 2008]" | 1547 | [Viewed November 26, 2008]" |
1509 | ,annotation=" | 1548 | ,annotation={ |
1510 | Expanded/corrected version of QRCU. | 1549 | Expanded/corrected version of QRCU. |
1511 | Used to be OlegNesterov2007aQRCU, now time-corrected. | 1550 | Used to be OlegNesterov2007aQRCU, now time-corrected. |
1512 | " | 1551 | } |
1513 | } | 1552 | } |
1514 | 1553 | ||
1515 | @unpublished{EvgeniyPolyakov2006RCUslowdown | 1554 | @unpublished{EvgeniyPolyakov2006RCUslowdown |
@@ -1521,10 +1560,10 @@ Revised: | |||
1521 | ,note="Available: | 1560 | ,note="Available: |
1522 | \url{http://www.ioremap.net/node/41} | 1561 | \url{http://www.ioremap.net/node/41} |
1523 | [Viewed October 28, 2008]" | 1562 | [Viewed October 28, 2008]" |
1524 | ,annotation=" | 1563 | ,annotation={ |
1525 | Using RCU as a pure delay leads to a 2.5x slowdown in skbs in | 1564 | Using RCU as a pure delay leads to a 2.5x slowdown in skbs in |
1526 | the Linux kernel. | 1565 | the Linux kernel. |
1527 | " | 1566 | } |
1528 | } | 1567 | } |
1529 | 1568 | ||
1530 | @inproceedings{ChrisMatthews2006ClusteredObjectsRCU | 1569 | @inproceedings{ChrisMatthews2006ClusteredObjectsRCU |
@@ -1541,7 +1580,8 @@ Revised: | |||
1541 | ,annotation={ | 1580 | ,annotation={ |
1542 | Uses K42's RCU-like functionality to manage clustered-object | 1581 | Uses K42's RCU-like functionality to manage clustered-object |
1543 | lifetimes. | 1582 | lifetimes. |
1544 | }} | 1583 | } |
1584 | } | ||
1545 | 1585 | ||
1546 | @article{DilmaDaSilva2006K42 | 1586 | @article{DilmaDaSilva2006K42 |
1547 | ,author = {Silva, Dilma Da and Krieger, Orran and Wisniewski, Robert W. and Waterland, Amos and Tam, David and Baumann, Andrew} | 1587 | ,author = {Silva, Dilma Da and Krieger, Orran and Wisniewski, Robert W. and Waterland, Amos and Tam, David and Baumann, Andrew} |
@@ -1557,7 +1597,8 @@ Revised: | |||
1557 | ,address = {New York, NY, USA} | 1597 | ,address = {New York, NY, USA} |
1558 | ,annotation={ | 1598 | ,annotation={ |
1559 | Describes relationship of K42 generations to RCU. | 1599 | Describes relationship of K42 generations to RCU. |
1560 | }} | 1600 | } |
1601 | } | ||
1561 | 1602 | ||
1562 | # CoreyMinyard2007list_splice_rcu | 1603 | # CoreyMinyard2007list_splice_rcu |
1563 | @unpublished{CoreyMinyard2007list:splice:rcu | 1604 | @unpublished{CoreyMinyard2007list:splice:rcu |
@@ -1569,9 +1610,9 @@ Revised: | |||
1569 | ,note="Available: | 1610 | ,note="Available: |
1570 | \url{http://lkml.org/lkml/2007/1/3/112} | 1611 | \url{http://lkml.org/lkml/2007/1/3/112} |
1571 | [Viewed May 28, 2007]" | 1612 | [Viewed May 28, 2007]" |
1572 | ,annotation=" | 1613 | ,annotation={ |
1573 | Patch for list_splice_rcu(). | 1614 | Patch for list_splice_rcu(). |
1574 | " | 1615 | } |
1575 | } | 1616 | } |
1576 | 1617 | ||
1577 | @unpublished{PaulEMcKenney2007rcubarrier | 1618 | @unpublished{PaulEMcKenney2007rcubarrier |
@@ -1583,9 +1624,9 @@ Revised: | |||
1583 | ,note="Available: | 1624 | ,note="Available: |
1584 | \url{http://lwn.net/Articles/217484/} | 1625 | \url{http://lwn.net/Articles/217484/} |
1585 | [Viewed November 22, 2007]" | 1626 | [Viewed November 22, 2007]" |
1586 | ,annotation=" | 1627 | ,annotation={ |
1587 | LWN article introducing the rcu_barrier() primitive. | 1628 | LWN article introducing the rcu_barrier() primitive. |
1588 | " | 1629 | } |
1589 | } | 1630 | } |
1590 | 1631 | ||
1591 | @unpublished{PeterZijlstra2007SyncBarrier | 1632 | @unpublished{PeterZijlstra2007SyncBarrier |
@@ -1597,10 +1638,10 @@ Revised: | |||
1597 | ,note="Available: | 1638 | ,note="Available: |
1598 | \url{http://lkml.org/lkml/2007/1/28/34} | 1639 | \url{http://lkml.org/lkml/2007/1/28/34} |
1599 | [Viewed March 27, 2008]" | 1640 | [Viewed March 27, 2008]" |
1600 | ,annotation=" | 1641 | ,annotation={ |
1601 | RCU-like implementation for frequent updaters and rare readers(!). | 1642 | RCU-like implementation for frequent updaters and rare readers(!). |
1602 | Subsumed into QRCU. Maybe... | 1643 | Subsumed into QRCU. Maybe... |
1603 | " | 1644 | } |
1604 | } | 1645 | } |
1605 | 1646 | ||
1606 | @unpublished{PaulEMcKenney2007BoostRCU | 1647 | @unpublished{PaulEMcKenney2007BoostRCU |
@@ -1609,14 +1650,13 @@ Revised: | |||
1609 | ,month="February" | 1650 | ,month="February" |
1610 | ,day="5" | 1651 | ,day="5" |
1611 | ,year="2007" | 1652 | ,year="2007" |
1612 | ,note="Available: | 1653 | ,note="\url{http://lwn.net/Articles/220677/}" |
1613 | \url{http://lwn.net/Articles/220677/} | 1654 | ,annotation={ |
1614 | Revised: | ||
1615 | \url{http://www.rdrop.com/users/paulmck/RCU/RCUbooststate.2007.04.16a.pdf} | ||
1616 | [Viewed September 7, 2007]" | ||
1617 | ,annotation=" | ||
1618 | LWN article introducing RCU priority boosting. | 1655 | LWN article introducing RCU priority boosting. |
1619 | " | 1656 | Revised: |
1657 | http://www.rdrop.com/users/paulmck/RCU/RCUbooststate.2007.04.16a.pdf | ||
1658 | [Viewed September 7, 2007] | ||
1659 | } | ||
1620 | } | 1660 | } |
1621 | 1661 | ||
1622 | @unpublished{PaulMcKenney2007QRCUpatch | 1662 | @unpublished{PaulMcKenney2007QRCUpatch |
@@ -1628,9 +1668,9 @@ Revised: | |||
1628 | ,note="Available: | 1668 | ,note="Available: |
1629 | \url{http://lkml.org/lkml/2007/2/25/18} | 1669 | \url{http://lkml.org/lkml/2007/2/25/18} |
1630 | [Viewed March 27, 2008]" | 1670 | [Viewed March 27, 2008]" |
1631 | ,annotation=" | 1671 | ,annotation={ |
1632 | Patch for QRCU supplying lock-free fast path. | 1672 | Patch for QRCU supplying lock-free fast path. |
1633 | " | 1673 | } |
1634 | } | 1674 | } |
1635 | 1675 | ||
1636 | @article{JonathanAppavoo2007K42RCU | 1676 | @article{JonathanAppavoo2007K42RCU |
@@ -1647,7 +1687,8 @@ Revised: | |||
1647 | ,address = {New York, NY, USA} | 1687 | ,address = {New York, NY, USA} |
1648 | ,annotation={ | 1688 | ,annotation={ |
1649 | Role of RCU in K42. | 1689 | Role of RCU in K42. |
1650 | }} | 1690 | } |
1691 | } | ||
1651 | 1692 | ||
1652 | @conference{RobertOlsson2007Trash | 1693 | @conference{RobertOlsson2007Trash |
1653 | ,Author="Robert Olsson and Stefan Nilsson" | 1694 | ,Author="Robert Olsson and Stefan Nilsson" |
@@ -1658,9 +1699,9 @@ Revised: | |||
1658 | ,note="Available: | 1699 | ,note="Available: |
1659 | \url{http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4281239} | 1700 | \url{http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4281239} |
1660 | [Viewed October 1, 2010]" | 1701 | [Viewed October 1, 2010]" |
1661 | ,annotation=" | 1702 | ,annotation={ |
1662 | RCU-protected dynamic trie-hash combination. | 1703 | RCU-protected dynamic trie-hash combination. |
1663 | " | 1704 | } |
1664 | } | 1705 | } |
1665 | 1706 | ||
1666 | @conference{PeterZijlstra2007ConcurrentPagecacheRCU | 1707 | @conference{PeterZijlstra2007ConcurrentPagecacheRCU |
@@ -1673,10 +1714,10 @@ Revised: | |||
1673 | ,note="Available: | 1714 | ,note="Available: |
1674 | \url{http://ols.108.redhat.com/2007/Reprints/zijlstra-Reprint.pdf} | 1715 | \url{http://ols.108.redhat.com/2007/Reprints/zijlstra-Reprint.pdf} |
1675 | [Viewed April 14, 2008]" | 1716 | [Viewed April 14, 2008]" |
1676 | ,annotation=" | 1717 | ,annotation={ |
1677 | Page-cache modifications permitting RCU readers and concurrent | 1718 | Page-cache modifications permitting RCU readers and concurrent |
1678 | updates. | 1719 | updates. |
1679 | " | 1720 | } |
1680 | } | 1721 | } |
1681 | 1722 | ||
1682 | @unpublished{PaulEMcKenney2007whatisRCU | 1723 | @unpublished{PaulEMcKenney2007whatisRCU |
@@ -1701,11 +1742,11 @@ Revised: | |||
1701 | ,note="Available: | 1742 | ,note="Available: |
1702 | \url{http://lwn.net/Articles/243851/} | 1743 | \url{http://lwn.net/Articles/243851/} |
1703 | [Viewed September 8, 2007]" | 1744 | [Viewed September 8, 2007]" |
1704 | ,annotation=" | 1745 | ,annotation={ |
1705 | LWN article describing Promela and spin, and also using Oleg | 1746 | LWN article describing Promela and spin, and also using Oleg |
1706 | Nesterov's QRCU as an example (with Paul McKenney's fastpath). | 1747 | Nesterov's QRCU as an example (with Paul McKenney's fastpath). |
1707 | Merged patch at: http://lkml.org/lkml/2007/2/25/18 | 1748 | Merged patch at: http://lkml.org/lkml/2007/2/25/18 |
1708 | " | 1749 | } |
1709 | } | 1750 | } |
1710 | 1751 | ||
1711 | @unpublished{PaulEMcKenney2007WG21DDOatomics | 1752 | @unpublished{PaulEMcKenney2007WG21DDOatomics |
@@ -1714,12 +1755,12 @@ Revised: | |||
1714 | ,month="August" | 1755 | ,month="August" |
1715 | ,day="3" | 1756 | ,day="3" |
1716 | ,year="2007" | 1757 | ,year="2007" |
1717 | ,note="Preprint: | 1758 | ,note="Available: |
1718 | \url{http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm} | 1759 | \url{http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm} |
1719 | [Viewed December 7, 2009]" | 1760 | [Viewed December 7, 2009]" |
1720 | ,annotation=" | 1761 | ,annotation={ |
1721 | RCU for C++, parts 1 and 2. | 1762 | RCU for C++, parts 1 and 2. |
1722 | " | 1763 | } |
1723 | } | 1764 | } |
1724 | 1765 | ||
1725 | @unpublished{PaulEMcKenney2007WG21DDOannotation | 1766 | @unpublished{PaulEMcKenney2007WG21DDOannotation |
@@ -1728,12 +1769,12 @@ Revised: | |||
1728 | ,month="September" | 1769 | ,month="September" |
1729 | ,day="18" | 1770 | ,day="18" |
1730 | ,year="2008" | 1771 | ,year="2008" |
1731 | ,note="Preprint: | 1772 | ,note="Available: |
1732 | \url{http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2782.htm} | 1773 | \url{http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2782.htm} |
1733 | [Viewed December 7, 2009]" | 1774 | [Viewed December 7, 2009]" |
1734 | ,annotation=" | 1775 | ,annotation={ |
1735 | RCU for C++, part 2, updated many times. | 1776 | RCU for C++, part 2, updated many times. |
1736 | " | 1777 | } |
1737 | } | 1778 | } |
1738 | 1779 | ||
1739 | @unpublished{PaulEMcKenney2007PreemptibleRCUPatch | 1780 | @unpublished{PaulEMcKenney2007PreemptibleRCUPatch |
@@ -1745,10 +1786,10 @@ Revised: | |||
1745 | ,note="Available: | 1786 | ,note="Available: |
1746 | \url{http://lkml.org/lkml/2007/9/10/213} | 1787 | \url{http://lkml.org/lkml/2007/9/10/213} |
1747 | [Viewed October 25, 2007]" | 1788 | [Viewed October 25, 2007]" |
1748 | ,annotation=" | 1789 | ,annotation={ |
1749 | Final patch for preemptable RCU to -rt. (Later patches were | 1790 | Final patch for preemptable RCU to -rt. (Later patches were |
1750 | to mainline, eventually incorporated.) | 1791 | to mainline, eventually incorporated.) |
1751 | " | 1792 | } |
1752 | } | 1793 | } |
1753 | 1794 | ||
1754 | @unpublished{PaulEMcKenney2007PreemptibleRCU | 1795 | @unpublished{PaulEMcKenney2007PreemptibleRCU |
@@ -1760,9 +1801,9 @@ Revised: | |||
1760 | ,note="Available: | 1801 | ,note="Available: |
1761 | \url{http://lwn.net/Articles/253651/} | 1802 | \url{http://lwn.net/Articles/253651/} |
1762 | [Viewed October 25, 2007]" | 1803 | [Viewed October 25, 2007]" |
1763 | ,annotation=" | 1804 | ,annotation={ |
1764 | LWN article describing the design of preemptible RCU. | 1805 | LWN article describing the design of preemptible RCU. |
1765 | " | 1806 | } |
1766 | } | 1807 | } |
1767 | 1808 | ||
1768 | @article{ThomasEHart2007a | 1809 | @article{ThomasEHart2007a |
@@ -1783,6 +1824,7 @@ Revised: | |||
1783 | } | 1824 | } |
1784 | } | 1825 | } |
1785 | 1826 | ||
1827 | # MathieuDesnoyers2007call_rcu_schedNeeded | ||
1786 | @unpublished{MathieuDesnoyers2007call:rcu:schedNeeded | 1828 | @unpublished{MathieuDesnoyers2007call:rcu:schedNeeded |
1787 | ,Author="Mathieu Desnoyers" | 1829 | ,Author="Mathieu Desnoyers" |
1788 | ,Title="Re: [patch 1/2] {Linux} Kernel Markers - Support Multiple Probes" | 1830 | ,Title="Re: [patch 1/2] {Linux} Kernel Markers - Support Multiple Probes" |
@@ -1792,9 +1834,9 @@ Revised: | |||
1792 | ,note="Available: | 1834 | ,note="Available: |
1793 | \url{http://lkml.org/lkml/2007/12/20/244} | 1835 | \url{http://lkml.org/lkml/2007/12/20/244} |
1794 | [Viewed March 27, 2008]" | 1836 | [Viewed March 27, 2008]" |
1795 | ,annotation=" | 1837 | ,annotation={ |
1796 | Request for call_rcu_sched() and rcu_barrier_sched(). | 1838 | Request for call_rcu_sched() and rcu_barrier_sched(). |
1797 | " | 1839 | } |
1798 | } | 1840 | } |
1799 | 1841 | ||
1800 | 1842 | ||
@@ -1815,11 +1857,11 @@ Revised: | |||
1815 | ,note="Available: | 1857 | ,note="Available: |
1816 | \url{http://lwn.net/Articles/262464/} | 1858 | \url{http://lwn.net/Articles/262464/} |
1817 | [Viewed December 27, 2007]" | 1859 | [Viewed December 27, 2007]" |
1818 | ,annotation=" | 1860 | ,annotation={ |
1819 | Lays out the three basic components of RCU: (1) publish-subscribe, | 1861 | Lays out the three basic components of RCU: (1) publish-subscribe, |
1820 | (2) wait for pre-existing readers to complete, and (2) maintain | 1862 | (2) wait for pre-existing readers to complete, and (2) maintain |
1821 | multiple versions. | 1863 | multiple versions. |
1822 | " | 1864 | } |
1823 | } | 1865 | } |
1824 | 1866 | ||
1825 | @unpublished{PaulEMcKenney2008WhatIsRCUUsage | 1867 | @unpublished{PaulEMcKenney2008WhatIsRCUUsage |
@@ -1831,7 +1873,7 @@ Revised: | |||
1831 | ,note="Available: | 1873 | ,note="Available: |
1832 | \url{http://lwn.net/Articles/263130/} | 1874 | \url{http://lwn.net/Articles/263130/} |
1833 | [Viewed January 4, 2008]" | 1875 | [Viewed January 4, 2008]" |
1834 | ,annotation=" | 1876 | ,annotation={ |
1835 | Lays out six uses of RCU: | 1877 | Lays out six uses of RCU: |
1836 | 1. RCU is a Reader-Writer Lock Replacement | 1878 | 1. RCU is a Reader-Writer Lock Replacement |
1837 | 2. RCU is a Restricted Reference-Counting Mechanism | 1879 | 2. RCU is a Restricted Reference-Counting Mechanism |
@@ -1839,7 +1881,7 @@ Revised: | |||
1839 | 4. RCU is a Poor Man's Garbage Collector | 1881 | 4. RCU is a Poor Man's Garbage Collector |
1840 | 5. RCU is a Way of Providing Existence Guarantees | 1882 | 5. RCU is a Way of Providing Existence Guarantees |
1841 | 6. RCU is a Way of Waiting for Things to Finish | 1883 | 6. RCU is a Way of Waiting for Things to Finish |
1842 | " | 1884 | } |
1843 | } | 1885 | } |
1844 | 1886 | ||
1845 | @unpublished{PaulEMcKenney2008WhatIsRCUAPI | 1887 | @unpublished{PaulEMcKenney2008WhatIsRCUAPI |
@@ -1851,10 +1893,10 @@ Revised: | |||
1851 | ,note="Available: | 1893 | ,note="Available: |
1852 | \url{http://lwn.net/Articles/264090/} | 1894 | \url{http://lwn.net/Articles/264090/} |
1853 | [Viewed January 10, 2008]" | 1895 | [Viewed January 10, 2008]" |
1854 | ,annotation=" | 1896 | ,annotation={ |
1855 | Gives an overview of the Linux-kernel RCU API and a brief annotated RCU | 1897 | Gives an overview of the Linux-kernel RCU API and a brief annotated RCU |
1856 | bibliography. | 1898 | bibliography. |
1857 | " | 1899 | } |
1858 | } | 1900 | } |
1859 | 1901 | ||
1860 | # | 1902 | # |
@@ -1872,10 +1914,10 @@ Revised: | |||
1872 | ,note="Available: | 1914 | ,note="Available: |
1873 | \url{http://lkml.org/lkml/2008/1/29/208} | 1915 | \url{http://lkml.org/lkml/2008/1/29/208} |
1874 | [Viewed March 27, 2008]" | 1916 | [Viewed March 27, 2008]" |
1875 | ,annotation=" | 1917 | ,annotation={ |
1876 | Patch that prevents preemptible RCU from unnecessarily waking | 1918 | Patch that prevents preemptible RCU from unnecessarily waking |
1877 | up dynticks-idle CPUs. | 1919 | up dynticks-idle CPUs. |
1878 | " | 1920 | } |
1879 | } | 1921 | } |
1880 | 1922 | ||
1881 | @unpublished{PaulEMcKenney2008LKMLDependencyOrdering | 1923 | @unpublished{PaulEMcKenney2008LKMLDependencyOrdering |
@@ -1887,9 +1929,9 @@ Revised: | |||
1887 | ,note="Available: | 1929 | ,note="Available: |
1888 | \url{http://lkml.org/lkml/2008/2/2/255} | 1930 | \url{http://lkml.org/lkml/2008/2/2/255} |
1889 | [Viewed October 18, 2008]" | 1931 | [Viewed October 18, 2008]" |
1890 | ,annotation=" | 1932 | ,annotation={ |
1891 | Explanation of compilers violating dependency ordering. | 1933 | Explanation of compilers violating dependency ordering. |
1892 | " | 1934 | } |
1893 | } | 1935 | } |
1894 | 1936 | ||
1895 | @Conference{PaulEMcKenney2008Beijing | 1937 | @Conference{PaulEMcKenney2008Beijing |
@@ -1916,24 +1958,26 @@ lot of {Linux} into your technology!!!" | |||
1916 | ,note="Available: | 1958 | ,note="Available: |
1917 | \url{http://lwn.net/Articles/279077/} | 1959 | \url{http://lwn.net/Articles/279077/} |
1918 | [Viewed April 24, 2008]" | 1960 | [Viewed April 24, 2008]" |
1919 | ,annotation=" | 1961 | ,annotation={ |
1920 | Describes use of Promela and Spin to validate (and fix!) the | 1962 | Describes use of Promela and Spin to validate (and fix!) the |
1921 | dynticks/RCU interface. | 1963 | dynticks/RCU interface. |
1922 | " | 1964 | } |
1923 | } | 1965 | } |
1924 | 1966 | ||
1925 | @article{DinakarGuniguntala2008IBMSysJ | 1967 | @article{DinakarGuniguntala2008IBMSysJ |
1926 | ,author="D. Guniguntala and P. E. McKenney and J. Triplett and J. Walpole" | 1968 | ,author="D. Guniguntala and P. E. McKenney and J. Triplett and J. Walpole" |
1927 | ,title="The read-copy-update mechanism for supporting real-time applications on shared-memory multiprocessor systems with {Linux}" | 1969 | ,title="The read-copy-update mechanism for supporting real-time applications on shared-memory multiprocessor systems with {Linux}" |
1928 | ,Year="2008" | 1970 | ,Year="2008" |
1929 | ,Month="April-June" | 1971 | ,Month="May" |
1930 | ,journal="IBM Systems Journal" | 1972 | ,journal="IBM Systems Journal" |
1931 | ,volume="47" | 1973 | ,volume="47" |
1932 | ,number="2" | 1974 | ,number="2" |
1933 | ,pages="221-236" | 1975 | ,pages="221-236" |
1934 | ,annotation=" | 1976 | ,annotation={ |
1935 | RCU, realtime RCU, sleepable RCU, performance. | 1977 | RCU, realtime RCU, sleepable RCU, performance. |
1936 | " | 1978 | http://www.research.ibm.com/journal/sj/472/guniguntala.pdf |
1979 | [Viewed April 24, 2008] | ||
1980 | } | ||
1937 | } | 1981 | } |
1938 | 1982 | ||
1939 | @unpublished{LaiJiangshan2008NewClassicAlgorithm | 1983 | @unpublished{LaiJiangshan2008NewClassicAlgorithm |
@@ -1945,11 +1989,11 @@ lot of {Linux} into your technology!!!" | |||
1945 | ,note="Available: | 1989 | ,note="Available: |
1946 | \url{http://lkml.org/lkml/2008/6/2/539} | 1990 | \url{http://lkml.org/lkml/2008/6/2/539} |
1947 | [Viewed December 10, 2008]" | 1991 | [Viewed December 10, 2008]" |
1948 | ,annotation=" | 1992 | ,annotation={ |
1949 | Updated RCU classic algorithm. Introduced multi-tailed list | 1993 | Updated RCU classic algorithm. Introduced multi-tailed list |
1950 | for RCU callbacks and also pulling common code into | 1994 | for RCU callbacks and also pulling common code into |
1951 | __call_rcu(). | 1995 | __call_rcu(). |
1952 | " | 1996 | } |
1953 | } | 1997 | } |
1954 | 1998 | ||
1955 | @article{PaulEMcKenney2008RCUOSR | 1999 | @article{PaulEMcKenney2008RCUOSR |
@@ -1966,6 +2010,7 @@ lot of {Linux} into your technology!!!" | |||
1966 | ,address="New York, NY, USA" | 2010 | ,address="New York, NY, USA" |
1967 | ,annotation={ | 2011 | ,annotation={ |
1968 | Linux changed RCU to a far greater degree than RCU has changed Linux. | 2012 | Linux changed RCU to a far greater degree than RCU has changed Linux. |
2013 | http://portal.acm.org/citation.cfm?doid=1400097.1400099 | ||
1969 | } | 2014 | } |
1970 | } | 2015 | } |
1971 | 2016 | ||
@@ -1978,10 +2023,10 @@ lot of {Linux} into your technology!!!" | |||
1978 | ,note="Available: | 2023 | ,note="Available: |
1979 | \url{http://lkml.org/lkml/2008/8/21/336} | 2024 | \url{http://lkml.org/lkml/2008/8/21/336} |
1980 | [Viewed December 8, 2008]" | 2025 | [Viewed December 8, 2008]" |
1981 | ,annotation=" | 2026 | ,annotation={ |
1982 | State-based RCU. One key thing that this patch does is to | 2027 | State-based RCU. One key thing that this patch does is to |
1983 | separate the dynticks handling of NMIs and IRQs. | 2028 | separate the dynticks handling of NMIs and IRQs. |
1984 | " | 2029 | } |
1985 | } | 2030 | } |
1986 | 2031 | ||
1987 | @unpublished{ManfredSpraul2008dyntickIRQNMI | 2032 | @unpublished{ManfredSpraul2008dyntickIRQNMI |
@@ -1993,12 +2038,13 @@ lot of {Linux} into your technology!!!" | |||
1993 | ,note="Available: | 2038 | ,note="Available: |
1994 | \url{http://lkml.org/lkml/2008/9/6/86} | 2039 | \url{http://lkml.org/lkml/2008/9/6/86} |
1995 | [Viewed December 8, 2008]" | 2040 | [Viewed December 8, 2008]" |
1996 | ,annotation=" | 2041 | ,annotation={ |
1997 | Manfred notes a fix required to my attempt to separate irq | 2042 | Manfred notes a fix required to my attempt to separate irq |
1998 | and NMI processing for hierarchical RCU's dynticks interface. | 2043 | and NMI processing for hierarchical RCU's dynticks interface. |
1999 | " | 2044 | } |
2000 | } | 2045 | } |
2001 | 2046 | ||
2047 | # Was PaulEMcKenney2011cyclicRCU | ||
2002 | @techreport{PaulEMcKenney2008cyclicRCU | 2048 | @techreport{PaulEMcKenney2008cyclicRCU |
2003 | ,author="Paul E. McKenney" | 2049 | ,author="Paul E. McKenney" |
2004 | ,title="Efficient Support of Consistent Cyclic Search With Read-Copy Update" | 2050 | ,title="Efficient Support of Consistent Cyclic Search With Read-Copy Update" |
@@ -2008,11 +2054,11 @@ lot of {Linux} into your technology!!!" | |||
2008 | ,number="US Patent 7,426,511" | 2054 | ,number="US Patent 7,426,511" |
2009 | ,month="September" | 2055 | ,month="September" |
2010 | ,pages="23" | 2056 | ,pages="23" |
2011 | ,annotation=" | 2057 | ,annotation={ |
2012 | Maintains an additional level of indirection to allow | 2058 | Maintains an additional level of indirection to allow |
2013 | readers to confine themselves to the desired snapshot of the | 2059 | readers to confine themselves to the desired snapshot of the |
2014 | data structure. Only permits one update at a time. | 2060 | data structure. Only permits one update at a time. |
2015 | " | 2061 | } |
2016 | } | 2062 | } |
2017 | 2063 | ||
2018 | @unpublished{PaulEMcKenney2008HierarchicalRCU | 2064 | @unpublished{PaulEMcKenney2008HierarchicalRCU |
@@ -2021,13 +2067,12 @@ lot of {Linux} into your technology!!!" | |||
2021 | ,month="November" | 2067 | ,month="November" |
2022 | ,day="3" | 2068 | ,day="3" |
2023 | ,year="2008" | 2069 | ,year="2008" |
2024 | ,note="Available: | 2070 | ,note="\url{http://lwn.net/Articles/305782/}" |
2025 | \url{http://lwn.net/Articles/305782/} | 2071 | ,annotation={ |
2026 | [Viewed November 6, 2008]" | ||
2027 | ,annotation=" | ||
2028 | RCU with combining-tree-based grace-period detection, | 2072 | RCU with combining-tree-based grace-period detection, |
2029 | permitting it to handle thousands of CPUs. | 2073 | permitting it to handle thousands of CPUs. |
2030 | " | 2074 | [Viewed November 6, 2008] |
2075 | } | ||
2031 | } | 2076 | } |
2032 | 2077 | ||
2033 | @unpublished{PaulEMcKenney2009BloatwatchRCU | 2078 | @unpublished{PaulEMcKenney2009BloatwatchRCU |
@@ -2039,10 +2084,10 @@ lot of {Linux} into your technology!!!" | |||
2039 | ,note="Available: | 2084 | ,note="Available: |
2040 | \url{http://lkml.org/lkml/2009/1/14/449} | 2085 | \url{http://lkml.org/lkml/2009/1/14/449} |
2041 | [Viewed January 15, 2009]" | 2086 | [Viewed January 15, 2009]" |
2042 | ,annotation=" | 2087 | ,annotation={ |
2043 | Small-footprint implementation of RCU for uniprocessor | 2088 | Small-footprint implementation of RCU for uniprocessor |
2044 | embedded applications -- and also for exposition purposes. | 2089 | embedded applications -- and also for exposition purposes. |
2045 | " | 2090 | } |
2046 | } | 2091 | } |
2047 | 2092 | ||
2048 | @conference{PaulEMcKenney2009MaliciousURCU | 2093 | @conference{PaulEMcKenney2009MaliciousURCU |
@@ -2055,9 +2100,9 @@ lot of {Linux} into your technology!!!" | |||
2055 | ,note="Available: | 2100 | ,note="Available: |
2056 | \url{http://www.rdrop.com/users/paulmck/RCU/urcutorture.2009.01.22a.pdf} | 2101 | \url{http://www.rdrop.com/users/paulmck/RCU/urcutorture.2009.01.22a.pdf} |
2057 | [Viewed February 2, 2009]" | 2102 | [Viewed February 2, 2009]" |
2058 | ,annotation=" | 2103 | ,annotation={ |
2059 | Realtime RCU and torture-testing RCU uses. | 2104 | Realtime RCU and torture-testing RCU uses. |
2060 | " | 2105 | } |
2061 | } | 2106 | } |
2062 | 2107 | ||
2063 | @unpublished{MathieuDesnoyers2009URCU | 2108 | @unpublished{MathieuDesnoyers2009URCU |
@@ -2066,16 +2111,14 @@ lot of {Linux} into your technology!!!" | |||
2066 | ,month="February" | 2111 | ,month="February" |
2067 | ,day="5" | 2112 | ,day="5" |
2068 | ,year="2009" | 2113 | ,year="2009" |
2069 | ,note="Available: | 2114 | ,note="\url{http://lttng.org/urcu}" |
2070 | \url{http://lkml.org/lkml/2009/2/5/572} | 2115 | ,annotation={ |
2071 | \url{http://lttng.org/urcu} | ||
2072 | [Viewed February 20, 2009]" | ||
2073 | ,annotation=" | ||
2074 | Mathieu Desnoyers's user-space RCU implementation. | 2116 | Mathieu Desnoyers's user-space RCU implementation. |
2075 | git://lttng.org/userspace-rcu.git | 2117 | git://lttng.org/userspace-rcu.git |
2076 | http://lttng.org/cgi-bin/gitweb.cgi?p=userspace-rcu.git | 2118 | http://lttng.org/cgi-bin/gitweb.cgi?p=userspace-rcu.git |
2077 | http://lttng.org/urcu | 2119 | http://lttng.org/urcu |
2078 | " | 2120 | http://lkml.org/lkml/2009/2/5/572 |
2121 | } | ||
2079 | } | 2122 | } |
2080 | 2123 | ||
2081 | @unpublished{PaulEMcKenney2009LWNBloatWatchRCU | 2124 | @unpublished{PaulEMcKenney2009LWNBloatWatchRCU |
@@ -2087,9 +2130,24 @@ lot of {Linux} into your technology!!!" | |||
2087 | ,note="Available: | 2130 | ,note="Available: |
2088 | \url{http://lwn.net/Articles/323929/} | 2131 | \url{http://lwn.net/Articles/323929/} |
2089 | [Viewed March 20, 2009]" | 2132 | [Viewed March 20, 2009]" |
2090 | ,annotation=" | 2133 | ,annotation={ |
2091 | Uniprocessor assumptions allow simplified RCU implementation. | 2134 | Uniprocessor assumptions allow simplified RCU implementation. |
2092 | " | 2135 | } |
2136 | } | ||
2137 | |||
2138 | @unpublished{EvgeniyPolyakov2009EllipticsNetwork | ||
2139 | ,Author="Evgeniy Polyakov" | ||
2140 | ,Title="The Elliptics Network" | ||
2141 | ,month="April" | ||
2142 | ,day="17" | ||
2143 | ,year="2009" | ||
2144 | ,note="Available: | ||
2145 | \url{http://www.ioremap.net/projects/elliptics} | ||
2146 | [Viewed April 30, 2009]" | ||
2147 | ,annotation={ | ||
2148 | Distributed hash table with transactions, using elliptic | ||
2149 | hash functions to distribute data. | ||
2150 | } | ||
2093 | } | 2151 | } |
2094 | 2152 | ||
2095 | @unpublished{PaulEMcKenney2009expeditedRCU | 2153 | @unpublished{PaulEMcKenney2009expeditedRCU |
@@ -2101,9 +2159,9 @@ lot of {Linux} into your technology!!!" | |||
2101 | ,note="Available: | 2159 | ,note="Available: |
2102 | \url{http://lkml.org/lkml/2009/6/25/306} | 2160 | \url{http://lkml.org/lkml/2009/6/25/306} |
2103 | [Viewed August 16, 2009]" | 2161 | [Viewed August 16, 2009]" |
2104 | ,annotation=" | 2162 | ,annotation={ |
2105 | First posting of expedited RCU to be accepted into -tip. | 2163 | First posting of expedited RCU to be accepted into -tip. |
2106 | " | 2164 | } |
2107 | } | 2165 | } |
2108 | 2166 | ||
2109 | @unpublished{PaulEMcKenney2009fastRTRCU | 2167 | @unpublished{PaulEMcKenney2009fastRTRCU |
@@ -2115,21 +2173,21 @@ lot of {Linux} into your technology!!!" | |||
2115 | ,note="Available: | 2173 | ,note="Available: |
2116 | \url{http://lkml.org/lkml/2009/7/23/294} | 2174 | \url{http://lkml.org/lkml/2009/7/23/294} |
2117 | [Viewed August 15, 2009]" | 2175 | [Viewed August 15, 2009]" |
2118 | ,annotation=" | 2176 | ,annotation={ |
2119 | First posting of simple and fast preemptable RCU. | 2177 | First posting of simple and fast preemptable RCU. |
2120 | " | 2178 | } |
2121 | } | 2179 | } |
2122 | 2180 | ||
2123 | @InProceedings{JoshTriplett2009RPHash | 2181 | @unpublished{JoshTriplett2009RPHash |
2124 | ,Author="Josh Triplett" | 2182 | ,Author="Josh Triplett" |
2125 | ,Title="Scalable concurrent hash tables via relativistic programming" | 2183 | ,Title="Scalable concurrent hash tables via relativistic programming" |
2126 | ,month="September" | 2184 | ,month="September" |
2127 | ,year="2009" | 2185 | ,year="2009" |
2128 | ,booktitle="Linux Plumbers Conference 2009" | 2186 | ,note="Linux Plumbers Conference presentation" |
2129 | ,annotation=" | 2187 | ,annotation={ |
2130 | RP fun with hash tables. | 2188 | RP fun with hash tables. |
2131 | See also JoshTriplett2010RPHash | 2189 | Superseded by JoshTriplett2010RPHash |
2132 | " | 2190 | } |
2133 | } | 2191 | } |
2134 | 2192 | ||
2135 | @phdthesis{MathieuDesnoyersPhD | 2193 | @phdthesis{MathieuDesnoyersPhD |
@@ -2154,9 +2212,9 @@ lot of {Linux} into your technology!!!" | |||
2154 | ,note="Available: | 2212 | ,note="Available: |
2155 | \url{http://wiki.cs.pdx.edu/rp/} | 2213 | \url{http://wiki.cs.pdx.edu/rp/} |
2156 | [Viewed December 9, 2009]" | 2214 | [Viewed December 9, 2009]" |
2157 | ,annotation=" | 2215 | ,annotation={ |
2158 | Main Relativistic Programming Wiki. | 2216 | Main Relativistic Programming Wiki. |
2159 | " | 2217 | } |
2160 | } | 2218 | } |
2161 | 2219 | ||
2162 | @conference{PaulEMcKenney2009DeterministicRCU | 2220 | @conference{PaulEMcKenney2009DeterministicRCU |
@@ -2180,9 +2238,9 @@ lot of {Linux} into your technology!!!" | |||
2180 | ,note="Available: | 2238 | ,note="Available: |
2181 | \url{http://paulmck.livejournal.com/14639.html} | 2239 | \url{http://paulmck.livejournal.com/14639.html} |
2182 | [Viewed June 4, 2010]" | 2240 | [Viewed June 4, 2010]" |
2183 | ,annotation=" | 2241 | ,annotation={ |
2184 | Day-one bug in Tree RCU that took forever to track down. | 2242 | Day-one bug in Tree RCU that took forever to track down. |
2185 | " | 2243 | } |
2186 | } | 2244 | } |
2187 | 2245 | ||
2188 | @unpublished{MathieuDesnoyers2009defer:rcu | 2246 | @unpublished{MathieuDesnoyers2009defer:rcu |
@@ -2193,10 +2251,10 @@ lot of {Linux} into your technology!!!" | |||
2193 | ,note="Available: | 2251 | ,note="Available: |
2194 | \url{http://lkml.org/lkml/2009/10/18/129} | 2252 | \url{http://lkml.org/lkml/2009/10/18/129} |
2195 | [Viewed December 29, 2009]" | 2253 | [Viewed December 29, 2009]" |
2196 | ,annotation=" | 2254 | ,annotation={ |
2197 | Mathieu proposed defer_rcu() with fixed-size per-thread pool | 2255 | Mathieu proposed defer_rcu() with fixed-size per-thread pool |
2198 | of RCU callbacks. | 2256 | of RCU callbacks. |
2199 | " | 2257 | } |
2200 | } | 2258 | } |
2201 | 2259 | ||
2202 | @unpublished{MathieuDesnoyers2009VerifPrePub | 2260 | @unpublished{MathieuDesnoyers2009VerifPrePub |
@@ -2205,10 +2263,10 @@ lot of {Linux} into your technology!!!" | |||
2205 | ,month="December" | 2263 | ,month="December" |
2206 | ,year="2009" | 2264 | ,year="2009" |
2207 | ,note="Submitted to IEEE TPDS" | 2265 | ,note="Submitted to IEEE TPDS" |
2208 | ,annotation=" | 2266 | ,annotation={ |
2209 | OOMem model for Mathieu's user-level RCU mechanical proof of | 2267 | OOMem model for Mathieu's user-level RCU mechanical proof of |
2210 | correctness. | 2268 | correctness. |
2211 | " | 2269 | } |
2212 | } | 2270 | } |
2213 | 2271 | ||
2214 | @unpublished{MathieuDesnoyers2009URCUPrePub | 2272 | @unpublished{MathieuDesnoyers2009URCUPrePub |
@@ -2216,15 +2274,15 @@ lot of {Linux} into your technology!!!" | |||
2216 | ,Title="User-Level Implementations of Read-Copy Update" | 2274 | ,Title="User-Level Implementations of Read-Copy Update" |
2217 | ,month="December" | 2275 | ,month="December" |
2218 | ,year="2010" | 2276 | ,year="2010" |
2219 | ,url=\url{http://www.computer.org/csdl/trans/td/2012/02/ttd2012020375-abs.html} | 2277 | ,url={\url{http://www.computer.org/csdl/trans/td/2012/02/ttd2012020375-abs.html}} |
2220 | ,annotation=" | 2278 | ,annotation={ |
2221 | RCU overview, desiderata, semi-formal semantics, user-level RCU | 2279 | RCU overview, desiderata, semi-formal semantics, user-level RCU |
2222 | usage scenarios, three classes of RCU implementation, wait-free | 2280 | usage scenarios, three classes of RCU implementation, wait-free |
2223 | RCU updates, RCU grace-period batching, update overhead, | 2281 | RCU updates, RCU grace-period batching, update overhead, |
2224 | http://www.rdrop.com/users/paulmck/RCU/urcu-main-accepted.2011.08.30a.pdf | 2282 | http://www.rdrop.com/users/paulmck/RCU/urcu-main-accepted.2011.08.30a.pdf |
2225 | http://www.rdrop.com/users/paulmck/RCU/urcu-supp-accepted.2011.08.30a.pdf | 2283 | http://www.rdrop.com/users/paulmck/RCU/urcu-supp-accepted.2011.08.30a.pdf |
2226 | Superseded by MathieuDesnoyers2012URCU. | 2284 | Superseded by MathieuDesnoyers2012URCU. |
2227 | " | 2285 | } |
2228 | } | 2286 | } |
2229 | 2287 | ||
2230 | @inproceedings{HariKannan2009DynamicAnalysisRCU | 2288 | @inproceedings{HariKannan2009DynamicAnalysisRCU |
@@ -2240,7 +2298,8 @@ lot of {Linux} into your technology!!!" | |||
2240 | ,address = {New York, NY, USA} | 2298 | ,address = {New York, NY, USA} |
2241 | ,annotation={ | 2299 | ,annotation={ |
2242 | Uses RCU to protect metadata used in dynamic analysis. | 2300 | Uses RCU to protect metadata used in dynamic analysis. |
2243 | }} | 2301 | } |
2302 | } | ||
2244 | 2303 | ||
2245 | @conference{PaulEMcKenney2010SimpleOptRCU | 2304 | @conference{PaulEMcKenney2010SimpleOptRCU |
2246 | ,Author="Paul E. McKenney" | 2305 | ,Author="Paul E. McKenney" |
@@ -2252,10 +2311,10 @@ lot of {Linux} into your technology!!!" | |||
2252 | ,note="Available: | 2311 | ,note="Available: |
2253 | \url{http://www.rdrop.com/users/paulmck/RCU/SimplicityThruOptimization.2010.01.21f.pdf} | 2312 | \url{http://www.rdrop.com/users/paulmck/RCU/SimplicityThruOptimization.2010.01.21f.pdf} |
2254 | [Viewed October 10, 2010]" | 2313 | [Viewed October 10, 2010]" |
2255 | ,annotation=" | 2314 | ,annotation={ |
2256 | TREE_PREEMPT_RCU optimizations greatly simplified the old | 2315 | TREE_PREEMPT_RCU optimizations greatly simplified the old |
2257 | PREEMPT_RCU implementation. | 2316 | PREEMPT_RCU implementation. |
2258 | " | 2317 | } |
2259 | } | 2318 | } |
2260 | 2319 | ||
2261 | @unpublished{PaulEMcKenney2010LockdepRCU | 2320 | @unpublished{PaulEMcKenney2010LockdepRCU |
@@ -2264,12 +2323,11 @@ lot of {Linux} into your technology!!!" | |||
2264 | ,month="February" | 2323 | ,month="February" |
2265 | ,year="2010" | 2324 | ,year="2010" |
2266 | ,day="1" | 2325 | ,day="1" |
2267 | ,note="Available: | 2326 | ,note="\url{https://lwn.net/Articles/371986/}" |
2268 | \url{https://lwn.net/Articles/371986/} | 2327 | ,annotation={ |
2269 | [Viewed June 4, 2010]" | ||
2270 | ,annotation=" | ||
2271 | CONFIG_PROVE_RCU, or at least an early version. | 2328 | CONFIG_PROVE_RCU, or at least an early version. |
2272 | " | 2329 | [Viewed June 4, 2010] |
2330 | } | ||
2273 | } | 2331 | } |
2274 | 2332 | ||
2275 | @unpublished{AviKivity2010KVM2RCU | 2333 | @unpublished{AviKivity2010KVM2RCU |
@@ -2280,10 +2338,10 @@ lot of {Linux} into your technology!!!" | |||
2280 | ,note="Available: | 2338 | ,note="Available: |
2281 | \url{http://www.mail-archive.com/kvm@vger.kernel.org/msg28640.html} | 2339 | \url{http://www.mail-archive.com/kvm@vger.kernel.org/msg28640.html} |
2282 | [Viewed March 20, 2010]" | 2340 | [Viewed March 20, 2010]" |
2283 | ,annotation=" | 2341 | ,annotation={ |
2284 | Use of RCU permits KVM to increase the size of guest OSes from | 2342 | Use of RCU permits KVM to increase the size of guest OSes from |
2285 | 16 CPUs to 64 CPUs. | 2343 | 16 CPUs to 64 CPUs. |
2286 | " | 2344 | } |
2287 | } | 2345 | } |
2288 | 2346 | ||
2289 | @unpublished{HerbertXu2010RCUResizeHash | 2347 | @unpublished{HerbertXu2010RCUResizeHash |
@@ -2297,7 +2355,19 @@ lot of {Linux} into your technology!!!" | |||
2297 | ,annotation={ | 2355 | ,annotation={ |
2298 | Use a pair of list_head structures to support RCU-protected | 2356 | Use a pair of list_head structures to support RCU-protected |
2299 | resizable hash tables. | 2357 | resizable hash tables. |
2300 | }} | 2358 | } |
2359 | } | ||
2360 | |||
2361 | @mastersthesis{AbhinavDuggal2010Masters | ||
2362 | ,author="Abhinav Duggal" | ||
2363 | ,title="Stopping Data Races Using Redflag" | ||
2364 | ,school="Stony Brook University" | ||
2365 | ,year="2010" | ||
2366 | ,annotation={ | ||
2367 | Data-race detector incorporating RCU. | ||
2368 | http://www.filesystems.org/docs/abhinav-thesis/abhinav_thesis.pdf | ||
2369 | } | ||
2370 | } | ||
2301 | 2371 | ||
2302 | @article{JoshTriplett2010RPHash | 2372 | @article{JoshTriplett2010RPHash |
2303 | ,author="Josh Triplett and Paul E. McKenney and Jonathan Walpole" | 2373 | ,author="Josh Triplett and Paul E. McKenney and Jonathan Walpole" |
@@ -2310,7 +2380,8 @@ lot of {Linux} into your technology!!!" | |||
2310 | ,annotation={ | 2380 | ,annotation={ |
2311 | RP fun with hash tables. | 2381 | RP fun with hash tables. |
2312 | http://portal.acm.org/citation.cfm?id=1842733.1842750 | 2382 | http://portal.acm.org/citation.cfm?id=1842733.1842750 |
2313 | }} | 2383 | } |
2384 | } | ||
2314 | 2385 | ||
2315 | @unpublished{PaulEMcKenney2010RCUAPI | 2386 | @unpublished{PaulEMcKenney2010RCUAPI |
2316 | ,Author="Paul E. McKenney" | 2387 | ,Author="Paul E. McKenney" |
@@ -2318,12 +2389,11 @@ lot of {Linux} into your technology!!!" | |||
2318 | ,month="December" | 2389 | ,month="December" |
2319 | ,day="8" | 2390 | ,day="8" |
2320 | ,year="2010" | 2391 | ,year="2010" |
2321 | ,note="Available: | 2392 | ,note="\url{http://lwn.net/Articles/418853/}" |
2322 | \url{http://lwn.net/Articles/418853/} | 2393 | ,annotation={ |
2323 | [Viewed December 8, 2010]" | ||
2324 | ,annotation=" | ||
2325 | Includes updated software-engineering features. | 2394 | Includes updated software-engineering features. |
2326 | " | 2395 | [Viewed December 8, 2010] |
2396 | } | ||
2327 | } | 2397 | } |
2328 | 2398 | ||
2329 | @mastersthesis{AndrejPodzimek2010masters | 2399 | @mastersthesis{AndrejPodzimek2010masters |
@@ -2338,7 +2408,8 @@ lot of {Linux} into your technology!!!" | |||
2338 | Reviews RCU implementations and creates a few for OpenSolaris. | 2408 | Reviews RCU implementations and creates a few for OpenSolaris. |
2339 | Drives quiescent-state detection from RCU read-side primitives, | 2409 | Drives quiescent-state detection from RCU read-side primitives, |
2340 | in a manner roughly similar to that of Jim Houston. | 2410 | in a manner roughly similar to that of Jim Houston. |
2341 | }} | 2411 | } |
2412 | } | ||
2342 | 2413 | ||
2343 | @unpublished{LinusTorvalds2011Linux2:6:38:rc1:NPigginVFS | 2414 | @unpublished{LinusTorvalds2011Linux2:6:38:rc1:NPigginVFS |
2344 | ,Author="Linus Torvalds" | 2415 | ,Author="Linus Torvalds" |
@@ -2358,7 +2429,8 @@ lot of {Linux} into your technology!!!" | |||
2358 | of the most expensive parts of path component lookup, which was the | 2429 | of the most expensive parts of path component lookup, which was the |
2359 | d_lock on every component lookup. So I'm seeing improvements of 30-50% | 2430 | d_lock on every component lookup. So I'm seeing improvements of 30-50% |
2360 | on some seriously pathname-lookup intensive loads." | 2431 | on some seriously pathname-lookup intensive loads." |
2361 | }} | 2432 | } |
2433 | } | ||
2362 | 2434 | ||
2363 | @techreport{JoshTriplett2011RPScalableCorrectOrdering | 2435 | @techreport{JoshTriplett2011RPScalableCorrectOrdering |
2364 | ,author = {Josh Triplett and Philip W. Howard and Paul E. McKenney and Jonathan Walpole} | 2436 | ,author = {Josh Triplett and Philip W. Howard and Paul E. McKenney and Jonathan Walpole} |
@@ -2392,12 +2464,12 @@ lot of {Linux} into your technology!!!" | |||
2392 | ,number="US Patent 7,953,778" | 2464 | ,number="US Patent 7,953,778" |
2393 | ,month="May" | 2465 | ,month="May" |
2394 | ,pages="34" | 2466 | ,pages="34" |
2395 | ,annotation=" | 2467 | ,annotation={ |
2396 | Maintains an array of generation numbers to track in-flight | 2468 | Maintains an array of generation numbers to track in-flight |
2397 | updates and keeps an additional level of indirection to allow | 2469 | updates and keeps an additional level of indirection to allow |
2398 | readers to confine themselves to the desired snapshot of the | 2470 | readers to confine themselves to the desired snapshot of the |
2399 | data structure. | 2471 | data structure. |
2400 | " | 2472 | } |
2401 | } | 2473 | } |
2402 | 2474 | ||
2403 | @inproceedings{Triplett:2011:RPHash | 2475 | @inproceedings{Triplett:2011:RPHash |
@@ -2408,7 +2480,7 @@ lot of {Linux} into your technology!!!" | |||
2408 | ,year = {2011} | 2480 | ,year = {2011} |
2409 | ,pages = {145--158} | 2481 | ,pages = {145--158} |
2410 | ,numpages = {14} | 2482 | ,numpages = {14} |
2411 | ,url={http://www.usenix.org/event/atc11/tech/final_files/atc11_proceedings.pdf} | 2483 | ,url={http://www.usenix.org/event/atc11/tech/final_files/Triplett.pdf} |
2412 | ,publisher = {The USENIX Association} | 2484 | ,publisher = {The USENIX Association} |
2413 | ,address = {Portland, OR USA} | 2485 | ,address = {Portland, OR USA} |
2414 | } | 2486 | } |
@@ -2419,27 +2491,58 @@ lot of {Linux} into your technology!!!" | |||
2419 | ,month="July" | 2491 | ,month="July" |
2420 | ,day="27" | 2492 | ,day="27" |
2421 | ,year="2011" | 2493 | ,year="2011" |
2422 | ,note="Available: | 2494 | ,note="\url{http://lwn.net/Articles/453002/}" |
2423 | \url{http://lwn.net/Articles/453002/} | 2495 | ,annotation={ |
2424 | [Viewed July 27, 2011]" | ||
2425 | ,annotation=" | ||
2426 | Analysis of the RCU trainwreck in Linux kernel 3.0. | 2496 | Analysis of the RCU trainwreck in Linux kernel 3.0. |
2427 | " | 2497 | [Viewed July 27, 2011] |
2498 | } | ||
2428 | } | 2499 | } |
2429 | 2500 | ||
2430 | @unpublished{NeilBrown2011MeetTheLockers | 2501 | @unpublished{NeilBrown2011MeetTheLockers |
2431 | ,Author="Neil Brown" | 2502 | ,Author="Neil Brown" |
2432 | ,Title="Meet the Lockers" | 2503 | ,Title="Meet the {Lockers}" |
2433 | ,month="August" | 2504 | ,month="August" |
2434 | ,day="3" | 2505 | ,day="3" |
2435 | ,year="2011" | 2506 | ,year="2011" |
2436 | ,note="Available: | 2507 | ,note="Available: |
2437 | \url{http://lwn.net/Articles/453685/} | 2508 | \url{http://lwn.net/Articles/453685/} |
2438 | [Viewed September 2, 2011]" | 2509 | [Viewed September 2, 2011]" |
2439 | ,annotation=" | 2510 | ,annotation={ |
2440 | The Locker family as an analogy for locking, reference counting, | 2511 | The Locker family as an analogy for locking, reference counting, |
2441 | RCU, and seqlock. | 2512 | RCU, and seqlock. |
2442 | " | 2513 | } |
2514 | } | ||
2515 | |||
2516 | @inproceedings{Seyster:2011:RFA:2075416.2075425 | ||
2517 | ,author = {Seyster, Justin and Radhakrishnan, Prabakar and Katoch, Samriti and Duggal, Abhinav and Stoller, Scott D. and Zadok, Erez} | ||
2518 | ,title = {Redflag: a framework for analysis of Kernel-level concurrency} | ||
2519 | ,booktitle = {Proceedings of the 11th international conference on Algorithms and architectures for parallel processing - Volume Part I} | ||
2520 | ,series = {ICA3PP'11} | ||
2521 | ,year = {2011} | ||
2522 | ,isbn = {978-3-642-24649-4} | ||
2523 | ,location = {Melbourne, Australia} | ||
2524 | ,pages = {66--79} | ||
2525 | ,numpages = {14} | ||
2526 | ,url = {http://dl.acm.org/citation.cfm?id=2075416.2075425} | ||
2527 | ,acmid = {2075425} | ||
2528 | ,publisher = {Springer-Verlag} | ||
2529 | ,address = {Berlin, Heidelberg} | ||
2530 | } | ||
2531 | |||
2532 | @phdthesis{JoshTriplettPhD | ||
2533 | ,author="Josh Triplett" | ||
2534 | ,title="Relativistic Causal Ordering: A Memory Model for Scalable Concurrent Data Structures" | ||
2535 | ,school="Portland State University" | ||
2536 | ,year="2012" | ||
2537 | ,annotation={ | ||
2538 | RCU-protected hash tables, barriers vs. read-side traversal order. | ||
2539 | . | ||
2540 | If the updater is making changes in the opposite direction from | ||
2541 | the read-side traveral order, the updater need only execute a | ||
2542 | memory-barrier instruction, but if in the same direction, the | ||
2543 | updater needs to wait for a grace period between the individual | ||
2544 | updates. | ||
2545 | } | ||
2443 | } | 2546 | } |
2444 | 2547 | ||
2445 | @article{MathieuDesnoyers2012URCU | 2548 | @article{MathieuDesnoyers2012URCU |
@@ -2459,5 +2562,150 @@ lot of {Linux} into your technology!!!" | |||
2459 | RCU updates, RCU grace-period batching, update overhead, | 2562 | RCU updates, RCU grace-period batching, update overhead, |
2460 | http://www.rdrop.com/users/paulmck/RCU/urcu-main-accepted.2011.08.30a.pdf | 2563 | http://www.rdrop.com/users/paulmck/RCU/urcu-main-accepted.2011.08.30a.pdf |
2461 | http://www.rdrop.com/users/paulmck/RCU/urcu-supp-accepted.2011.08.30a.pdf | 2564 | http://www.rdrop.com/users/paulmck/RCU/urcu-supp-accepted.2011.08.30a.pdf |
2565 | http://www.computer.org/cms/Computer.org/dl/trans/td/2012/02/extras/ttd2012020375s.pdf | ||
2566 | } | ||
2567 | } | ||
2568 | |||
2569 | @inproceedings{AustinClements2012RCULinux:mmapsem | ||
2570 | ,author = {Austin Clements and Frans Kaashoek and Nickolai Zeldovich} | ||
2571 | ,title = {Scalable Address Spaces Using {RCU} Balanced Trees} | ||
2572 | ,booktitle = {Architectural Support for Programming Languages and Operating Systems (ASPLOS 2012)} | ||
2573 | ,month = {March} | ||
2574 | ,year = {2012} | ||
2575 | ,pages = {199--210} | ||
2576 | ,numpages = {12} | ||
2577 | ,publisher = {ACM} | ||
2578 | ,address = {London, UK} | ||
2579 | ,url="http://people.csail.mit.edu/nickolai/papers/clements-bonsai.pdf" | ||
2580 | } | ||
2581 | |||
2582 | @unpublished{PaulEMcKenney2012ELCbattery | ||
2583 | ,Author="Paul E. McKenney" | ||
2584 | ,Title="Making {RCU} Safe For Battery-Powered Devices" | ||
2585 | ,month="February" | ||
2586 | ,day="15" | ||
2587 | ,year="2012" | ||
2588 | ,note="Available: | ||
2589 | \url{http://www.rdrop.com/users/paulmck/RCU/RCUdynticks.2012.02.15b.pdf} | ||
2590 | [Viewed March 1, 2012]" | ||
2591 | ,annotation={ | ||
2592 | RCU_FAST_NO_HZ, round 2. | ||
2593 | } | ||
2594 | } | ||
2595 | |||
2596 | @article{GuillermoVigueras2012RCUCrowd | ||
2597 | ,author = {Vigueras, Guillermo and Ordu\~{n}a, Juan M. and Lozano, Miguel} | ||
2598 | ,day = {25} | ||
2599 | ,doi = {10.1007/s11227-012-0766-x} | ||
2600 | ,issn = {0920-8542} | ||
2601 | ,journal = {The Journal of Supercomputing} | ||
2602 | ,keywords = {linux, simulation} | ||
2603 | ,month = apr | ||
2604 | ,posted-at = {2012-05-03 09:12:04} | ||
2605 | ,priority = {2} | ||
2606 | ,title = {{A Read-Copy Update based parallel server for distributed crowd simulations}} | ||
2607 | ,url = {http://dx.doi.org/10.1007/s11227-012-0766-x} | ||
2608 | ,year = {2012} | ||
2609 | } | ||
2610 | |||
2611 | |||
2612 | @unpublished{JonCorbet2012ACCESS:ONCE | ||
2613 | ,Author="Jon Corbet" | ||
2614 | ,Title="{ACCESS\_ONCE()}" | ||
2615 | ,month="August" | ||
2616 | ,day="1" | ||
2617 | ,year="2012" | ||
2618 | ,note="\url{http://lwn.net/Articles/508991/}" | ||
2619 | ,annotation={ | ||
2620 | A couple of simple specific compiler optimizations that motivate | ||
2621 | ACCESS_ONCE(). | ||
2622 | } | ||
2623 | } | ||
2624 | |||
2625 | @unpublished{AlexeyGotsman2012VerifyGraceExtended | ||
2626 | ,Author="Alexey Gotsman and Noam Rinetzky and Hongseok Yang" | ||
2627 | ,Title="Verifying Highly Concurrent Algorithms with Grace (extended version)" | ||
2628 | ,month="July" | ||
2629 | ,day="10" | ||
2630 | ,year="2012" | ||
2631 | ,note="\url{http://software.imdea.org/~gotsman/papers/recycling-esop13-ext.pdf}" | ||
2632 | ,annotation={ | ||
2633 | Separation-logic formulation of RCU uses. | ||
2634 | } | ||
2635 | } | ||
2636 | |||
2637 | @unpublished{PaulMcKenney2012RCUUsage | ||
2638 | ,Author="Paul E. McKenney and Silas Boyd-Wickizer and Jonathan Walpole" | ||
2639 | ,Title="{RCU} Usage In the Linux Kernel: One Decade Later" | ||
2640 | ,month="September" | ||
2641 | ,day="17" | ||
2642 | ,year="2012" | ||
2643 | ,url=http://rdrop.com/users/paulmck/techreports/survey.2012.09.17a.pdf | ||
2644 | ,note="Technical report paulmck.2012.09.17" | ||
2645 | ,annotation={ | ||
2646 | Overview of the first variant of no-CBs CPUs for RCU. | ||
2647 | } | ||
2648 | } | ||
2649 | |||
2650 | @unpublished{JonCorbet2012NOCB | ||
2651 | ,Author="Jon Corbet" | ||
2652 | ,Title="Relocating RCU callbacks" | ||
2653 | ,month="October" | ||
2654 | ,day="31" | ||
2655 | ,year="2012" | ||
2656 | ,note="\url{http://lwn.net/Articles/522262/}" | ||
2657 | ,annotation={ | ||
2658 | Overview of the first variant of no-CBs CPUs for RCU. | ||
2659 | } | ||
2660 | } | ||
2661 | |||
2662 | @phdthesis{JustinSeyster2012PhD | ||
2663 | ,author="Justin Seyster" | ||
2664 | ,title="Runtime Verification of Kernel-Level Concurrency Using Compiler-Based Instrumentation" | ||
2665 | ,school="Stony Brook University" | ||
2666 | ,year="2012" | ||
2667 | ,annotation={ | ||
2668 | Looking for data races, including those involving RCU. | ||
2669 | Proposal: | ||
2670 | http://www.fsl.cs.sunysb.edu/docs/jseyster-proposal/redflag.pdf | ||
2671 | Dissertation: | ||
2672 | http://www.fsl.cs.sunysb.edu/docs/jseyster-dissertation/redflag.pdf | ||
2673 | } | ||
2674 | } | ||
2675 | |||
2676 | @unpublished{PaulEMcKenney2013RCUUsage | ||
2677 | ,Author="Paul E. McKenney and Silas Boyd-Wickizer and Jonathan Walpole" | ||
2678 | ,Title="{RCU} Usage in the {Linux} Kernel: One Decade Later" | ||
2679 | ,month="February" | ||
2680 | ,day="24" | ||
2681 | ,year="2013" | ||
2682 | ,note="\url{http://rdrop.com/users/paulmck/techreports/RCUUsage.2013.02.24a.pdf}" | ||
2683 | ,annotation={ | ||
2684 | Usage of RCU within the Linux kernel. | ||
2685 | } | ||
2686 | } | ||
2687 | |||
2688 | @inproceedings{AlexeyGotsman2013ESOPRCU | ||
2689 | ,author = {Alexey Gotsman and Noam Rinetzky and Hongseok Yang} | ||
2690 | ,title = {Verifying concurrent memory reclamation algorithms with grace} | ||
2691 | ,booktitle = {ESOP'13: European Symposium on Programming} | ||
2692 | ,year = {2013} | ||
2693 | ,pages = {249--269} | ||
2694 | ,publisher = {Springer} | ||
2695 | ,address = {Rome, Italy} | ||
2696 | ,annotation={ | ||
2697 | http://software.imdea.org/~gotsman/papers/recycling-esop13.pdf | ||
2698 | } | ||
2699 | } | ||
2700 | |||
2701 | @unpublished{PaulEMcKenney2013NoTinyPreempt | ||
2702 | ,Author="Paul E. McKenney" | ||
2703 | ,Title="Simplifying RCU" | ||
2704 | ,month="March" | ||
2705 | ,day="6" | ||
2706 | ,year="2013" | ||
2707 | ,note="\url{http://lwn.net/Articles/541037/}" | ||
2708 | ,annotation={ | ||
2709 | Getting rid of TINY_PREEMPT_RCU. | ||
2462 | } | 2710 | } |
2463 | } | 2711 | } |
diff --git a/Documentation/RCU/rcubarrier.txt b/Documentation/RCU/rcubarrier.txt index 2e319d1b9ef2..b10cfe711e68 100644 --- a/Documentation/RCU/rcubarrier.txt +++ b/Documentation/RCU/rcubarrier.txt | |||
@@ -70,10 +70,14 @@ in realtime kernels in order to avoid excessive scheduling latencies. | |||
70 | 70 | ||
71 | rcu_barrier() | 71 | rcu_barrier() |
72 | 72 | ||
73 | We instead need the rcu_barrier() primitive. This primitive is similar | 73 | We instead need the rcu_barrier() primitive. Rather than waiting for |
74 | to synchronize_rcu(), but instead of waiting solely for a grace | 74 | a grace period to elapse, rcu_barrier() waits for all outstanding RCU |
75 | period to elapse, it also waits for all outstanding RCU callbacks to | 75 | callbacks to complete. Please note that rcu_barrier() does -not- imply |
76 | complete. Pseudo-code using rcu_barrier() is as follows: | 76 | synchronize_rcu(), in particular, if there are no RCU callbacks queued |
77 | anywhere, rcu_barrier() is within its rights to return immediately, | ||
78 | without waiting for a grace period to elapse. | ||
79 | |||
80 | Pseudo-code using rcu_barrier() is as follows: | ||
77 | 81 | ||
78 | 1. Prevent any new RCU callbacks from being posted. | 82 | 1. Prevent any new RCU callbacks from being posted. |
79 | 2. Execute rcu_barrier(). | 83 | 2. Execute rcu_barrier(). |
diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt index d8a502387397..dac02a6219b1 100644 --- a/Documentation/RCU/torture.txt +++ b/Documentation/RCU/torture.txt | |||
@@ -42,6 +42,16 @@ fqs_holdoff Holdoff time (in microseconds) between consecutive calls | |||
42 | fqs_stutter Wait time (in seconds) between consecutive bursts | 42 | fqs_stutter Wait time (in seconds) between consecutive bursts |
43 | of calls to force_quiescent_state(). | 43 | of calls to force_quiescent_state(). |
44 | 44 | ||
45 | gp_normal Make the fake writers use normal synchronous grace-period | ||
46 | primitives. | ||
47 | |||
48 | gp_exp Make the fake writers use expedited synchronous grace-period | ||
49 | primitives. If both gp_normal and gp_exp are set, or | ||
50 | if neither gp_normal nor gp_exp are set, then randomly | ||
51 | choose the primitive so that about 50% are normal and | ||
52 | 50% expedited. By default, neither are set, which | ||
53 | gives best overall test coverage. | ||
54 | |||
45 | irqreader Says to invoke RCU readers from irq level. This is currently | 55 | irqreader Says to invoke RCU readers from irq level. This is currently |
46 | done via timers. Defaults to "1" for variants of RCU that | 56 | done via timers. Defaults to "1" for variants of RCU that |
47 | permit this. (Or, more accurately, variants of RCU that do | 57 | permit this. (Or, more accurately, variants of RCU that do |
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 6e97e73d87b5..26b1e31d5a13 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches | |||
@@ -109,6 +109,16 @@ probably didn't even receive earlier versions of the patch. | |||
109 | If the patch fixes a logged bug entry, refer to that bug entry by | 109 | If the patch fixes a logged bug entry, refer to that bug entry by |
110 | number and URL. | 110 | number and URL. |
111 | 111 | ||
112 | If you want to refer to a specific commit, don't just refer to the | ||
113 | SHA-1 ID of the commit. Please also include the oneline summary of | ||
114 | the commit, to make it easier for reviewers to know what it is about. | ||
115 | Example: | ||
116 | |||
117 | Commit e21d2170f36602ae2708 ("video: remove unnecessary | ||
118 | platform_set_drvdata()") removed the unnecessary | ||
119 | platform_set_drvdata(), but left the variable "dev" unused, | ||
120 | delete it. | ||
121 | |||
112 | 122 | ||
113 | 3) Separate your changes. | 123 | 3) Separate your changes. |
114 | 124 | ||
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a97dff3..aca4e69121b7 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt | |||
@@ -207,7 +207,7 @@ passing those. One idea is to return this in _DSM method like: | |||
207 | Return (Local0) | 207 | Return (Local0) |
208 | } | 208 | } |
209 | 209 | ||
210 | Then the at25 SPI driver can get this configation by calling _DSM on its | 210 | Then the at25 SPI driver can get this configuration by calling _DSM on its |
211 | ACPI handle like: | 211 | ACPI handle like: |
212 | 212 | ||
213 | struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL }; | 213 | struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL }; |
@@ -228,19 +228,9 @@ ACPI handle like: | |||
228 | I2C serial bus support | 228 | I2C serial bus support |
229 | ~~~~~~~~~~~~~~~~~~~~~~ | 229 | ~~~~~~~~~~~~~~~~~~~~~~ |
230 | The slaves behind I2C bus controller only need to add the ACPI IDs like | 230 | The slaves behind I2C bus controller only need to add the ACPI IDs like |
231 | with the platform and SPI drivers. However the I2C bus controller driver | 231 | with the platform and SPI drivers. The I2C core automatically enumerates |
232 | needs to call acpi_i2c_register_devices() after it has added the adapter. | 232 | any slave devices behind the controller device once the adapter is |
233 | 233 | registered. | |
234 | An I2C bus (controller) driver does: | ||
235 | |||
236 | ... | ||
237 | ret = i2c_add_numbered_adapter(adapter); | ||
238 | if (ret) | ||
239 | /* handle error */ | ||
240 | |||
241 | of_i2c_register_devices(adapter); | ||
242 | /* Enumerate the slave devices behind this bus via ACPI */ | ||
243 | acpi_i2c_register_devices(adapter); | ||
244 | 234 | ||
245 | Below is an example of how to add ACPI support to the existing mpu3050 | 235 | Below is an example of how to add ACPI support to the existing mpu3050 |
246 | input driver: | 236 | input driver: |
diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting index 0c1f475fdf36..371814a36719 100644 --- a/Documentation/arm/Booting +++ b/Documentation/arm/Booting | |||
@@ -18,7 +18,8 @@ following: | |||
18 | 2. Initialise one serial port. | 18 | 2. Initialise one serial port. |
19 | 3. Detect the machine type. | 19 | 3. Detect the machine type. |
20 | 4. Setup the kernel tagged list. | 20 | 4. Setup the kernel tagged list. |
21 | 5. Call the kernel image. | 21 | 5. Load initramfs. |
22 | 6. Call the kernel image. | ||
22 | 23 | ||
23 | 24 | ||
24 | 1. Setup and initialise RAM | 25 | 1. Setup and initialise RAM |
@@ -120,12 +121,27 @@ tagged list. | |||
120 | The boot loader must pass at a minimum the size and location of the | 121 | 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 | 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 | 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 | overwrite it, whilst remaining within the region which will be covered |
124 | with the caveat that it may not be located at physical address 0 since | 125 | by the kernel's low-memory mapping. |
125 | the kernel interprets a value of 0 in r2 to mean neither a tagged list | ||
126 | nor a dtb were passed. | ||
127 | 126 | ||
128 | 5. Calling the kernel image | 127 | A safe location is just above the 128MiB boundary from start of RAM. |
128 | |||
129 | 5. Load initramfs. | ||
130 | ------------------ | ||
131 | |||
132 | Existing boot loaders: OPTIONAL | ||
133 | New boot loaders: OPTIONAL | ||
134 | |||
135 | If an initramfs is in use then, as with the dtb, it must be placed in | ||
136 | a region of memory where the kernel decompressor will not overwrite it | ||
137 | while also with the region which will be covered by the kernel's | ||
138 | low-memory mapping. | ||
139 | |||
140 | A safe location is just above the device tree blob which itself will | ||
141 | be loaded just above the 128MiB boundary from the start of RAM as | ||
142 | recommended above. | ||
143 | |||
144 | 6. Calling the kernel image | ||
129 | --------------------------- | 145 | --------------------------- |
130 | 146 | ||
131 | Existing boot loaders: MANDATORY | 147 | Existing boot loaders: MANDATORY |
@@ -136,11 +152,17 @@ is stored in flash, and is linked correctly to be run from flash, | |||
136 | then it is legal for the boot loader to call the zImage in flash | 152 | then it is legal for the boot loader to call the zImage in flash |
137 | directly. | 153 | directly. |
138 | 154 | ||
139 | The zImage may also be placed in system RAM (at any location) and | 155 | The zImage may also be placed in system RAM and called there. The |
140 | called there. Note that the kernel uses 16K of RAM below the image | 156 | kernel should be placed in the first 128MiB of RAM. It is recommended |
141 | to store page tables. The recommended placement is 32KiB into RAM. | 157 | that it is loaded above 32MiB in order to avoid the need to relocate |
158 | prior to decompression, which will make the boot process slightly | ||
159 | faster. | ||
160 | |||
161 | When booting a raw (non-zImage) kernel the constraints are tighter. | ||
162 | In this case the kernel must be loaded at an offset into system equal | ||
163 | to TEXT_OFFSET - PAGE_OFFSET. | ||
142 | 164 | ||
143 | In either case, the following conditions must be met: | 165 | In any case, the following conditions must be met: |
144 | 166 | ||
145 | - Quiesce all DMA capable devices so that memory does not get | 167 | - Quiesce all DMA capable devices so that memory does not get |
146 | corrupted by bogus network packets or disk data. This will save | 168 | corrupted by bogus network packets or disk data. This will save |
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm index 9012bb039094..4ae915a9f899 100644 --- a/Documentation/arm/OMAP/omap_pm +++ b/Documentation/arm/OMAP/omap_pm | |||
@@ -78,7 +78,7 @@ to NULL. Drivers should use the following idiom: | |||
78 | The most common usage of these functions will probably be to specify | 78 | The most common usage of these functions will probably be to specify |
79 | the maximum time from when an interrupt occurs, to when the device | 79 | the maximum time from when an interrupt occurs, to when the device |
80 | becomes accessible. To accomplish this, driver writers should use the | 80 | becomes accessible. To accomplish this, driver writers should use the |
81 | set_max_mpu_wakeup_lat() function to to constrain the MPU wakeup | 81 | set_max_mpu_wakeup_lat() function to constrain the MPU wakeup |
82 | latency, and the set_max_dev_wakeup_lat() function to constrain the | 82 | latency, and the set_max_dev_wakeup_lat() function to constrain the |
83 | device wakeup latency (from clk_enable() to accessibility). For | 83 | device wakeup latency (from clk_enable() to accessibility). For |
84 | example, | 84 | example, |
diff --git a/Documentation/arm/kernel_mode_neon.txt b/Documentation/arm/kernel_mode_neon.txt new file mode 100644 index 000000000000..525452726d31 --- /dev/null +++ b/Documentation/arm/kernel_mode_neon.txt | |||
@@ -0,0 +1,121 @@ | |||
1 | Kernel mode NEON | ||
2 | ================ | ||
3 | |||
4 | TL;DR summary | ||
5 | ------------- | ||
6 | * Use only NEON instructions, or VFP instructions that don't rely on support | ||
7 | code | ||
8 | * Isolate your NEON code in a separate compilation unit, and compile it with | ||
9 | '-mfpu=neon -mfloat-abi=softfp' | ||
10 | * Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your | ||
11 | NEON code | ||
12 | * Don't sleep in your NEON code, and be aware that it will be executed with | ||
13 | preemption disabled | ||
14 | |||
15 | |||
16 | Introduction | ||
17 | ------------ | ||
18 | It is possible to use NEON instructions (and in some cases, VFP instructions) in | ||
19 | code that runs in kernel mode. However, for performance reasons, the NEON/VFP | ||
20 | register file is not preserved and restored at every context switch or taken | ||
21 | exception like the normal register file is, so some manual intervention is | ||
22 | required. Furthermore, special care is required for code that may sleep [i.e., | ||
23 | may call schedule()], as NEON or VFP instructions will be executed in a | ||
24 | non-preemptible section for reasons outlined below. | ||
25 | |||
26 | |||
27 | Lazy preserve and restore | ||
28 | ------------------------- | ||
29 | The NEON/VFP register file is managed using lazy preserve (on UP systems) and | ||
30 | lazy restore (on both SMP and UP systems). This means that the register file is | ||
31 | kept 'live', and is only preserved and restored when multiple tasks are | ||
32 | contending for the NEON/VFP unit (or, in the SMP case, when a task migrates to | ||
33 | another core). Lazy restore is implemented by disabling the NEON/VFP unit after | ||
34 | every context switch, resulting in a trap when subsequently a NEON/VFP | ||
35 | instruction is issued, allowing the kernel to step in and perform the restore if | ||
36 | necessary. | ||
37 | |||
38 | Any use of the NEON/VFP unit in kernel mode should not interfere with this, so | ||
39 | it is required to do an 'eager' preserve of the NEON/VFP register file, and | ||
40 | enable the NEON/VFP unit explicitly so no exceptions are generated on first | ||
41 | subsequent use. This is handled by the function kernel_neon_begin(), which | ||
42 | should be called before any kernel mode NEON or VFP instructions are issued. | ||
43 | Likewise, the NEON/VFP unit should be disabled again after use to make sure user | ||
44 | mode will hit the lazy restore trap upon next use. This is handled by the | ||
45 | function kernel_neon_end(). | ||
46 | |||
47 | |||
48 | Interruptions in kernel mode | ||
49 | ---------------------------- | ||
50 | For reasons of performance and simplicity, it was decided that there shall be no | ||
51 | preserve/restore mechanism for the kernel mode NEON/VFP register contents. This | ||
52 | implies that interruptions of a kernel mode NEON section can only be allowed if | ||
53 | they are guaranteed not to touch the NEON/VFP registers. For this reason, the | ||
54 | following rules and restrictions apply in the kernel: | ||
55 | * NEON/VFP code is not allowed in interrupt context; | ||
56 | * NEON/VFP code is not allowed to sleep; | ||
57 | * NEON/VFP code is executed with preemption disabled. | ||
58 | |||
59 | If latency is a concern, it is possible to put back to back calls to | ||
60 | kernel_neon_end() and kernel_neon_begin() in places in your code where none of | ||
61 | the NEON registers are live. (Additional calls to kernel_neon_begin() should be | ||
62 | reasonably cheap if no context switch occurred in the meantime) | ||
63 | |||
64 | |||
65 | VFP and support code | ||
66 | -------------------- | ||
67 | Earlier versions of VFP (prior to version 3) rely on software support for things | ||
68 | like IEEE-754 compliant underflow handling etc. When the VFP unit needs such | ||
69 | software assistance, it signals the kernel by raising an undefined instruction | ||
70 | exception. The kernel responds by inspecting the VFP control registers and the | ||
71 | current instruction and arguments, and emulates the instruction in software. | ||
72 | |||
73 | Such software assistance is currently not implemented for VFP instructions | ||
74 | executed in kernel mode. If such a condition is encountered, the kernel will | ||
75 | fail and generate an OOPS. | ||
76 | |||
77 | |||
78 | Separating NEON code from ordinary code | ||
79 | --------------------------------------- | ||
80 | The compiler is not aware of the special significance of kernel_neon_begin() and | ||
81 | kernel_neon_end(), i.e., that it is only allowed to issue NEON/VFP instructions | ||
82 | between calls to these respective functions. Furthermore, GCC may generate NEON | ||
83 | instructions of its own at -O3 level if -mfpu=neon is selected, and even if the | ||
84 | kernel is currently compiled at -O2, future changes may result in NEON/VFP | ||
85 | instructions appearing in unexpected places if no special care is taken. | ||
86 | |||
87 | Therefore, the recommended and only supported way of using NEON/VFP in the | ||
88 | kernel is by adhering to the following rules: | ||
89 | * isolate the NEON code in a separate compilation unit and compile it with | ||
90 | '-mfpu=neon -mfloat-abi=softfp'; | ||
91 | * issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls | ||
92 | into the unit containing the NEON code from a compilation unit which is *not* | ||
93 | built with the GCC flag '-mfpu=neon' set. | ||
94 | |||
95 | As the kernel is compiled with '-msoft-float', the above will guarantee that | ||
96 | both NEON and VFP instructions will only ever appear in designated compilation | ||
97 | units at any optimization level. | ||
98 | |||
99 | |||
100 | NEON assembler | ||
101 | -------------- | ||
102 | NEON assembler is supported with no additional caveats as long as the rules | ||
103 | above are followed. | ||
104 | |||
105 | |||
106 | NEON code generated by GCC | ||
107 | -------------------------- | ||
108 | The GCC option -ftree-vectorize (implied by -O3) tries to exploit implicit | ||
109 | parallelism, and generates NEON code from ordinary C source code. This is fully | ||
110 | supported as long as the rules above are followed. | ||
111 | |||
112 | |||
113 | NEON intrinsics | ||
114 | --------------- | ||
115 | NEON intrinsics are also supported. However, as code using NEON intrinsics | ||
116 | relies on the GCC header <arm_neon.h>, (which #includes <stdint.h>), you should | ||
117 | observe the following in addition to the rules above: | ||
118 | * Compile the unit containing the NEON intrinsics with '-ffreestanding' so GCC | ||
119 | uses its builtin version of <stdint.h> (this is a C99 header which the kernel | ||
120 | does not supply); | ||
121 | * Include <arm_neon.h> last, or at least after <linux/types.h> | ||
diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index 9c4d388daddc..98df4a03807e 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt | |||
@@ -45,9 +45,9 @@ sees fit.) | |||
45 | 45 | ||
46 | Requirement: MANDATORY | 46 | Requirement: MANDATORY |
47 | 47 | ||
48 | The device tree blob (dtb) must be no bigger than 2 megabytes in size | 48 | The device tree blob (dtb) must be placed on an 8-byte boundary within |
49 | and placed at a 2-megabyte boundary within the first 512 megabytes from | 49 | the first 512 megabytes from the start of the kernel image and must not |
50 | the start of the kernel image. This is to allow the kernel to map the | 50 | cross a 2-megabyte boundary. This is to allow the kernel to map the |
51 | blob using a single section mapping in the initial page tables. | 51 | blob using a single section mapping in the initial page tables. |
52 | 52 | ||
53 | 53 | ||
@@ -68,13 +68,23 @@ Image target is available instead. | |||
68 | 68 | ||
69 | Requirement: MANDATORY | 69 | Requirement: MANDATORY |
70 | 70 | ||
71 | The decompressed kernel image contains a 32-byte header as follows: | 71 | The decompressed kernel image contains a 64-byte header as follows: |
72 | 72 | ||
73 | u32 magic = 0x14000008; /* branch to stext, little-endian */ | 73 | u32 code0; /* Executable code */ |
74 | u32 res0 = 0; /* reserved */ | 74 | u32 code1; /* Executable code */ |
75 | u64 text_offset; /* Image load offset */ | 75 | u64 text_offset; /* Image load offset */ |
76 | u64 res0 = 0; /* reserved */ | ||
76 | u64 res1 = 0; /* reserved */ | 77 | u64 res1 = 0; /* reserved */ |
77 | u64 res2 = 0; /* reserved */ | 78 | u64 res2 = 0; /* reserved */ |
79 | u64 res3 = 0; /* reserved */ | ||
80 | u64 res4 = 0; /* reserved */ | ||
81 | u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ | ||
82 | u32 res5 = 0; /* reserved */ | ||
83 | |||
84 | |||
85 | Header notes: | ||
86 | |||
87 | - code0/code1 are responsible for branching to stext. | ||
78 | 88 | ||
79 | The image must be placed at the specified offset (currently 0x80000) | 89 | The image must be placed at the specified offset (currently 0x80000) |
80 | from the start of the system RAM and called there. The start of the | 90 | from the start of the system RAM and called there. The start of the |
diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt new file mode 100644 index 000000000000..264e9841563a --- /dev/null +++ b/Documentation/arm64/tagged-pointers.txt | |||
@@ -0,0 +1,34 @@ | |||
1 | Tagged virtual addresses in AArch64 Linux | ||
2 | ========================================= | ||
3 | |||
4 | Author: Will Deacon <will.deacon@arm.com> | ||
5 | Date : 12 June 2013 | ||
6 | |||
7 | This document briefly describes the provision of tagged virtual | ||
8 | addresses in the AArch64 translation system and their potential uses | ||
9 | in AArch64 Linux. | ||
10 | |||
11 | The kernel configures the translation tables so that translations made | ||
12 | via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of | ||
13 | the virtual address ignored by the translation hardware. This frees up | ||
14 | this byte for application use, with the following caveats: | ||
15 | |||
16 | (1) The kernel requires that all user addresses passed to EL1 | ||
17 | are tagged with tag 0x00. This means that any syscall | ||
18 | parameters containing user virtual addresses *must* have | ||
19 | their top byte cleared before trapping to the kernel. | ||
20 | |||
21 | (2) Tags are not guaranteed to be preserved when delivering | ||
22 | signals. This means that signal handlers in applications | ||
23 | making use of tags cannot rely on the tag information for | ||
24 | user virtual addresses being maintained for fields inside | ||
25 | siginfo_t. One exception to this rule is for signals raised | ||
26 | in response to debug exceptions, where the tag information | ||
27 | will be preserved. | ||
28 | |||
29 | (3) Special care should be taken when using tagged pointers, | ||
30 | since it is likely that C compilers will not hazard two | ||
31 | addresses differing only in the upper bits. | ||
32 | |||
33 | The architecture prevents the use of a tagged PC, so the upper byte will | ||
34 | be set to a sign-extension of bit 55 on exception return. | ||
diff --git a/Documentation/block/cfq-iosched.txt b/Documentation/block/cfq-iosched.txt index 9887f0414c16..f3bc72945cbd 100644 --- a/Documentation/block/cfq-iosched.txt +++ b/Documentation/block/cfq-iosched.txt | |||
@@ -69,7 +69,7 @@ one, this value should be decreased relative to fifo_expire_async. | |||
69 | group_idle | 69 | group_idle |
70 | ----------- | 70 | ----------- |
71 | This parameter forces idling at the CFQ group level instead of CFQ | 71 | This parameter forces idling at the CFQ group level instead of CFQ |
72 | queue level. This was introduced after after a bottleneck was observed | 72 | queue level. This was introduced after a bottleneck was observed |
73 | in higher end storage due to idle on sequential queue and allow dispatch | 73 | in higher end storage due to idle on sequential queue and allow dispatch |
74 | from a single queue. The idea with this parameter is that it can be run with | 74 | from a single queue. The idea with this parameter is that it can be run with |
75 | slice_idle=0 and group_idle=8, so that idling does not happen on individual | 75 | slice_idle=0 and group_idle=8, so that idling does not happen on individual |
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt index 9b728dc17535..d79b008e4a32 100644 --- a/Documentation/cachetlb.txt +++ b/Documentation/cachetlb.txt | |||
@@ -57,7 +57,7 @@ changes occur: | |||
57 | interface must make sure that any previous page table | 57 | interface must make sure that any previous page table |
58 | modifications for the address space 'vma->vm_mm' in the range | 58 | modifications for the address space 'vma->vm_mm' in the range |
59 | 'start' to 'end-1' will be visible to the cpu. That is, after | 59 | 'start' to 'end-1' will be visible to the cpu. That is, after |
60 | running, here will be no entries in the TLB for 'mm' for | 60 | running, there will be no entries in the TLB for 'mm' for |
61 | virtual addresses in the range 'start' to 'end-1'. | 61 | virtual addresses in the range 'start' to 'end-1'. |
62 | 62 | ||
63 | The "vma" is the backing store being used for the region. | 63 | The "vma" is the backing store being used for the region. |
@@ -375,8 +375,8 @@ maps this page at its virtual address. | |||
375 | 375 | ||
376 | void flush_icache_page(struct vm_area_struct *vma, struct page *page) | 376 | void flush_icache_page(struct vm_area_struct *vma, struct page *page) |
377 | All the functionality of flush_icache_page can be implemented in | 377 | All the functionality of flush_icache_page can be implemented in |
378 | flush_dcache_page and update_mmu_cache. In 2.7 the hope is to | 378 | flush_dcache_page and update_mmu_cache. In the future, the hope |
379 | remove this interface completely. | 379 | is to remove this interface completely. |
380 | 380 | ||
381 | The final category of APIs is for I/O to deliberately aliased address | 381 | The final category of APIs is for I/O to deliberately aliased address |
382 | ranges inside the kernel. Such aliases are set up by use of the | 382 | ranges inside the kernel. Such aliases are set up by use of the |
diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index 19fa98e07bf7..40282e617913 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt | |||
@@ -50,8 +50,6 @@ What shall this struct cpufreq_driver contain? | |||
50 | 50 | ||
51 | cpufreq_driver.name - The name of this driver. | 51 | cpufreq_driver.name - The name of this driver. |
52 | 52 | ||
53 | cpufreq_driver.owner - THIS_MODULE; | ||
54 | |||
55 | cpufreq_driver.init - A pointer to the per-CPU initialization | 53 | cpufreq_driver.init - A pointer to the per-CPU initialization |
56 | function. | 54 | function. |
57 | 55 | ||
diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index 902d3151f527..0aad6deb2d96 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt | |||
@@ -22,7 +22,7 @@ to /proc/cpuinfo. | |||
22 | 22 | ||
23 | 4) /sys/devices/system/cpu/cpuX/topology/thread_siblings: | 23 | 4) /sys/devices/system/cpu/cpuX/topology/thread_siblings: |
24 | 24 | ||
25 | internel kernel map of cpuX's hardware threads within the same | 25 | internal kernel map of cpuX's hardware threads within the same |
26 | core as cpuX | 26 | core as cpuX |
27 | 27 | ||
28 | 5) /sys/devices/system/cpu/cpuX/topology/core_siblings: | 28 | 5) /sys/devices/system/cpu/cpuX/topology/core_siblings: |
diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index 4823577c6509..2e0617936e8f 100644 --- a/Documentation/development-process/2.Process +++ b/Documentation/development-process/2.Process | |||
@@ -276,7 +276,7 @@ mainline get there via -mm. | |||
276 | The current -mm patch is available in the "mmotm" (-mm of the moment) | 276 | The current -mm patch is available in the "mmotm" (-mm of the moment) |
277 | directory at: | 277 | directory at: |
278 | 278 | ||
279 | http://userweb.kernel.org/~akpm/mmotm/ | 279 | http://www.ozlabs.org/~akpm/mmotm/ |
280 | 280 | ||
281 | Use of the MMOTM tree is likely to be a frustrating experience, though; | 281 | Use of the MMOTM tree is likely to be a frustrating experience, though; |
282 | there is a definite chance that it will not even compile. | 282 | there is a definite chance that it will not even compile. |
@@ -287,7 +287,7 @@ the mainline is expected to look like after the next merge window closes. | |||
287 | Linux-next trees are announced on the linux-kernel and linux-next mailing | 287 | Linux-next trees are announced on the linux-kernel and linux-next mailing |
288 | lists when they are assembled; they can be downloaded from: | 288 | lists when they are assembled; they can be downloaded from: |
289 | 289 | ||
290 | http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/ | 290 | http://www.kernel.org/pub/linux/kernel/next/ |
291 | 291 | ||
292 | Some information about linux-next has been gathered at: | 292 | Some information about linux-next has been gathered at: |
293 | 293 | ||
diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt index 20746e5abe6f..06fc7602593a 100644 --- a/Documentation/devicetree/bindings/arm/arch_timer.txt +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt | |||
@@ -1,10 +1,14 @@ | |||
1 | * ARM architected timer | 1 | * ARM architected timer |
2 | 2 | ||
3 | ARM cores may have a per-core architected timer, which provides per-cpu timers. | 3 | ARM cores may have a per-core architected timer, which provides per-cpu timers, |
4 | or a memory mapped architected timer, which provides up to 8 frames with a | ||
5 | physical and optional virtual timer per frame. | ||
4 | 6 | ||
5 | The timer is attached to a GIC to deliver its per-processor interrupts. | 7 | The per-core architected timer is attached to a GIC to deliver its |
8 | per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC | ||
9 | to deliver its interrupts via SPIs. | ||
6 | 10 | ||
7 | ** Timer node properties: | 11 | ** CP15 Timer node properties: |
8 | 12 | ||
9 | - compatible : Should at least contain one of | 13 | - compatible : Should at least contain one of |
10 | "arm,armv7-timer" | 14 | "arm,armv7-timer" |
@@ -26,3 +30,52 @@ Example: | |||
26 | <1 10 0xf08>; | 30 | <1 10 0xf08>; |
27 | clock-frequency = <100000000>; | 31 | clock-frequency = <100000000>; |
28 | }; | 32 | }; |
33 | |||
34 | ** Memory mapped timer node properties: | ||
35 | |||
36 | - compatible : Should at least contain "arm,armv7-timer-mem". | ||
37 | |||
38 | - clock-frequency : The frequency of the main counter, in Hz. Optional. | ||
39 | |||
40 | - reg : The control frame base address. | ||
41 | |||
42 | Note that #address-cells, #size-cells, and ranges shall be present to ensure | ||
43 | the CPU can address a frame's registers. | ||
44 | |||
45 | A timer node has up to 8 frame sub-nodes, each with the following properties: | ||
46 | |||
47 | - frame-number: 0 to 7. | ||
48 | |||
49 | - interrupts : Interrupt list for physical and virtual timers in that order. | ||
50 | The virtual timer interrupt is optional. | ||
51 | |||
52 | - reg : The first and second view base addresses in that order. The second view | ||
53 | base address is optional. | ||
54 | |||
55 | - status : "disabled" indicates the frame is not available for use. Optional. | ||
56 | |||
57 | Example: | ||
58 | |||
59 | timer@f0000000 { | ||
60 | compatible = "arm,armv7-timer-mem"; | ||
61 | #address-cells = <1>; | ||
62 | #size-cells = <1>; | ||
63 | ranges; | ||
64 | reg = <0xf0000000 0x1000>; | ||
65 | clock-frequency = <50000000>; | ||
66 | |||
67 | frame@f0001000 { | ||
68 | frame-number = <0> | ||
69 | interrupts = <0 13 0x8>, | ||
70 | <0 14 0x8>; | ||
71 | reg = <0xf0001000 0x1000>, | ||
72 | <0xf0002000 0x1000>; | ||
73 | }; | ||
74 | |||
75 | frame@f0003000 { | ||
76 | frame-number = <1> | ||
77 | interrupts = <0 15 0x8>; | ||
78 | reg = <0xf0003000 0x1000>; | ||
79 | status = "disabled"; | ||
80 | }; | ||
81 | }; | ||
diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt index 16769d9cedd6..723c205cb10d 100644 --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt | |||
@@ -1,18 +1,15 @@ | |||
1 | * AT91's Analog to Digital Converter (ADC) | 1 | * AT91's Analog to Digital Converter (ADC) |
2 | 2 | ||
3 | Required properties: | 3 | Required properties: |
4 | - compatible: Should be "atmel,at91sam9260-adc" | 4 | - compatible: Should be "atmel,<chip>-adc" |
5 | <chip> can be "at91sam9260", "at91sam9g45" or "at91sam9x5" | ||
5 | - reg: Should contain ADC registers location and length | 6 | - reg: Should contain ADC registers location and length |
6 | - interrupts: Should contain the IRQ line for the ADC | 7 | - interrupts: Should contain the IRQ line for the ADC |
7 | - atmel,adc-channel-base: Offset of the first channel data register | ||
8 | - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this | 8 | - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this |
9 | device | 9 | device |
10 | - atmel,adc-drdy-mask: Mask of the DRDY interruption in the ADC | ||
11 | - atmel,adc-num-channels: Number of channels available in the ADC | 10 | - atmel,adc-num-channels: Number of channels available in the ADC |
12 | - atmel,adc-startup-time: Startup Time of the ADC in microseconds as | 11 | - atmel,adc-startup-time: Startup Time of the ADC in microseconds as |
13 | defined in the datasheet | 12 | defined in the datasheet |
14 | - atmel,adc-status-register: Offset of the Interrupt Status Register | ||
15 | - atmel,adc-trigger-register: Offset of the Trigger Register | ||
16 | - atmel,adc-vref: Reference voltage in millivolts for the conversions | 13 | - atmel,adc-vref: Reference voltage in millivolts for the conversions |
17 | - atmel,adc-res: List of resolution in bits supported by the ADC. List size | 14 | - atmel,adc-res: List of resolution in bits supported by the ADC. List size |
18 | must be two at least. | 15 | must be two at least. |
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt index 69ddf9fad2dc..c0c7626fd0ff 100644 --- a/Documentation/devicetree/bindings/arm/l2cc.txt +++ b/Documentation/devicetree/bindings/arm/l2cc.txt | |||
@@ -16,9 +16,11 @@ Required properties: | |||
16 | performs the same operation). | 16 | performs the same operation). |
17 | "marvell,"aurora-outer-cache: Marvell Controller designed to be | 17 | "marvell,"aurora-outer-cache: Marvell Controller designed to be |
18 | compatible with the ARM one with outer cache mode. | 18 | compatible with the ARM one with outer cache mode. |
19 | "bcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an | 19 | "brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an |
20 | offset needs to be added to the address before passing down to the L2 | 20 | offset needs to be added to the address before passing down to the L2 |
21 | cache controller | 21 | cache controller |
22 | "bcm,bcm11351-a2-pl310-cache": DEPRECATED by | ||
23 | "brcm,bcm11351-a2-pl310-cache" | ||
22 | - cache-unified : Specifies the cache is a unified cache. | 24 | - cache-unified : Specifies the cache is a unified cache. |
23 | - cache-level : Should be set to 2 for a level 2 cache. | 25 | - cache-level : Should be set to 2 for a level 2 cache. |
24 | - reg : Physical base address and size of cache controller's memory mapped | 26 | - reg : Physical base address and size of cache controller's memory mapped |
diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt index 69b5ab0b5f4b..d11d80006a19 100644 --- a/Documentation/devicetree/bindings/arm/ste-u300.txt +++ b/Documentation/devicetree/bindings/arm/ste-u300.txt | |||
@@ -22,7 +22,7 @@ This contains the board-specific information. | |||
22 | - compatible: must be "stericsson,s365". | 22 | - compatible: must be "stericsson,s365". |
23 | - vana15-supply: the regulator supplying the 1.5V to drive the | 23 | - vana15-supply: the regulator supplying the 1.5V to drive the |
24 | board. | 24 | board. |
25 | - syscon: a pointer to the syscon node so we can acccess the | 25 | - syscon: a pointer to the syscon node so we can access the |
26 | syscon registers to set the board as self-powered. | 26 | syscon registers to set the board as self-powered. |
27 | 27 | ||
28 | Example: | 28 | Example: |
diff --git a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt index 9cf3f25544c7..5580e9c4bd85 100644 --- a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt +++ b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt | |||
@@ -32,8 +32,8 @@ numbers - see motherboard's TRM for more details. | |||
32 | The node describing a config device must refer to the sysreg node via | 32 | The node describing a config device must refer to the sysreg node via |
33 | "arm,vexpress,config-bridge" phandle (can be also defined in the node's | 33 | "arm,vexpress,config-bridge" phandle (can be also defined in the node's |
34 | parent) and relies on the board topology properties - see main vexpress | 34 | parent) and relies on the board topology properties - see main vexpress |
35 | node documentation for more details. It must must also define the | 35 | node documentation for more details. It must also define the following |
36 | following property: | 36 | property: |
37 | - arm,vexpress-sysreg,func : must contain two cells: | 37 | - arm,vexpress-sysreg,func : must contain two cells: |
38 | - first cell defines function number (eg. 1 for clock generator, | 38 | - first cell defines function number (eg. 1 for clock generator, |
39 | 2 for voltage regulators etc.) | 39 | 2 for voltage regulators etc.) |
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index 3ec0c5c4f0e9..89de1564950c 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt | |||
@@ -4,27 +4,17 @@ SATA nodes are defined to describe on-chip Serial ATA controllers. | |||
4 | Each SATA controller should have its own node. | 4 | Each SATA controller should have its own node. |
5 | 5 | ||
6 | Required properties: | 6 | Required properties: |
7 | - compatible : compatible list, contains "calxeda,hb-ahci" or "snps,spear-ahci" | 7 | - compatible : compatible list, contains "snps,spear-ahci" |
8 | - interrupts : <interrupt mapping for SATA IRQ> | 8 | - interrupts : <interrupt mapping for SATA IRQ> |
9 | - reg : <registers mapping> | 9 | - reg : <registers mapping> |
10 | 10 | ||
11 | Optional properties: | 11 | Optional properties: |
12 | - calxeda,port-phys: phandle-combophy and lane assignment, which maps each | ||
13 | SATA port to a combophy and a lane within that | ||
14 | combophy | ||
15 | - calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off, | ||
16 | which indicates that the driver supports SGPIO | ||
17 | indicator lights using the indicated GPIOs | ||
18 | - calxeda,led-order : a u32 array that map port numbers to offsets within the | ||
19 | SGPIO bitstream. | ||
20 | - dma-coherent : Present if dma operations are coherent | 12 | - dma-coherent : Present if dma operations are coherent |
21 | 13 | ||
22 | Example: | 14 | Example: |
23 | sata@ffe08000 { | 15 | sata@ffe08000 { |
24 | compatible = "calxeda,hb-ahci"; | 16 | compatible = "snps,spear-ahci"; |
25 | reg = <0xffe08000 0x1000>; | 17 | reg = <0xffe08000 0x1000>; |
26 | interrupts = <115>; | 18 | interrupts = <115>; |
27 | calxeda,port-phys = <&combophy5 0 &combophy0 0 &combophy0 1 | ||
28 | &combophy0 2 &combophy0 3>; | ||
29 | 19 | ||
30 | }; | 20 | }; |
diff --git a/Documentation/devicetree/bindings/ata/sata_highbank.txt b/Documentation/devicetree/bindings/ata/sata_highbank.txt new file mode 100644 index 000000000000..aa83407cb7a4 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/sata_highbank.txt | |||
@@ -0,0 +1,44 @@ | |||
1 | * Calxeda AHCI SATA Controller | ||
2 | |||
3 | SATA nodes are defined to describe on-chip Serial ATA controllers. | ||
4 | The Calxeda SATA controller mostly conforms to the AHCI interface | ||
5 | with some special extensions to add functionality. | ||
6 | Each SATA controller should have its own node. | ||
7 | |||
8 | Required properties: | ||
9 | - compatible : compatible list, contains "calxeda,hb-ahci" | ||
10 | - interrupts : <interrupt mapping for SATA IRQ> | ||
11 | - reg : <registers mapping> | ||
12 | |||
13 | Optional properties: | ||
14 | - dma-coherent : Present if dma operations are coherent | ||
15 | - calxeda,port-phys : phandle-combophy and lane assignment, which maps each | ||
16 | SATA port to a combophy and a lane within that | ||
17 | combophy | ||
18 | - calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off, | ||
19 | which indicates that the driver supports SGPIO | ||
20 | indicator lights using the indicated GPIOs | ||
21 | - calxeda,led-order : a u32 array that map port numbers to offsets within the | ||
22 | SGPIO bitstream. | ||
23 | - calxeda,tx-atten : a u32 array that contains TX attenuation override | ||
24 | codes, one per port. The upper 3 bytes are always | ||
25 | 0 and thus ignored. | ||
26 | - calxeda,pre-clocks : a u32 that indicates the number of additional clock | ||
27 | cycles to transmit before sending an SGPIO pattern | ||
28 | - calxeda,post-clocks: a u32 that indicates the number of additional clock | ||
29 | cycles to transmit after sending an SGPIO pattern | ||
30 | |||
31 | Example: | ||
32 | sata@ffe08000 { | ||
33 | compatible = "calxeda,hb-ahci"; | ||
34 | reg = <0xffe08000 0x1000>; | ||
35 | interrupts = <115>; | ||
36 | dma-coherent; | ||
37 | calxeda,port-phys = <&combophy5 0 &combophy0 0 &combophy0 1 | ||
38 | &combophy0 2 &combophy0 3>; | ||
39 | calxeda,sgpio-gpio =<&gpioh 5 1 &gpioh 6 1 &gpioh 7 1>; | ||
40 | calxeda,led-order = <4 0 1 2 3>; | ||
41 | calxeda,tx-atten = <0xff 22 0xff 0xff 23>; | ||
42 | calxeda,pre-clocks = <10>; | ||
43 | calxeda,post-clocks = <0>; | ||
44 | }; | ||
diff --git a/Documentation/devicetree/bindings/c6x/dscr.txt b/Documentation/devicetree/bindings/c6x/dscr.txt index d847758f2b20..b0e97144cfb1 100644 --- a/Documentation/devicetree/bindings/c6x/dscr.txt +++ b/Documentation/devicetree/bindings/c6x/dscr.txt | |||
@@ -5,7 +5,7 @@ TI C6X SoCs contain a region of miscellaneous registers which provide various | |||
5 | function for SoC control or status. Details vary considerably among from SoC | 5 | function for SoC control or status. Details vary considerably among from SoC |
6 | to SoC with no two being alike. | 6 | to SoC with no two being alike. |
7 | 7 | ||
8 | In general, the Device State Configuraion Registers (DSCR) will provide one or | 8 | In general, the Device State Configuration Registers (DSCR) will provide one or |
9 | more configuration registers often protected by a lock register where one or | 9 | more configuration registers often protected by a lock register where one or |
10 | more key values must be written to a lock register in order to unlock the | 10 | more key values must be written to a lock register in order to unlock the |
11 | configuration register for writes. These configuration register may be used to | 11 | configuration register for writes. These configuration register may be used to |
diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt index a1201802f90d..75e2e1999f87 100644 --- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt +++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt | |||
@@ -2,7 +2,7 @@ | |||
2 | 2 | ||
3 | The Samsung Audio Subsystem clock controller generates and supplies clocks | 3 | The Samsung Audio Subsystem clock controller generates and supplies clocks |
4 | to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock | 4 | to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock |
5 | binding described here is applicable to all SoC's in Exynos family. | 5 | binding described here is applicable to all SoCs in Exynos family. |
6 | 6 | ||
7 | Required Properties: | 7 | Required Properties: |
8 | 8 | ||
diff --git a/Documentation/devicetree/bindings/clock/st,nomadik.txt b/Documentation/devicetree/bindings/clock/st,nomadik.txt index 7fc09773de46..40e0cf1f7b99 100644 --- a/Documentation/devicetree/bindings/clock/st,nomadik.txt +++ b/Documentation/devicetree/bindings/clock/st,nomadik.txt | |||
@@ -17,7 +17,7 @@ Optional properties for the SRC node: | |||
17 | - disable-mxtal: if present this will disable the MXTALO, | 17 | - disable-mxtal: if present this will disable the MXTALO, |
18 | i.e. the driver output for the main (~19.2 MHz) chrystal, | 18 | i.e. the driver output for the main (~19.2 MHz) chrystal, |
19 | if the board has its own circuitry for providing this | 19 | if the board has its own circuitry for providing this |
20 | osciallator | 20 | oscillator |
21 | 21 | ||
22 | 22 | ||
23 | PLL nodes: these nodes represent the two PLLs on the system, | 23 | PLL nodes: these nodes represent the two PLLs on the system, |
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec6.txt b/Documentation/devicetree/bindings/crypto/fsl-sec6.txt new file mode 100644 index 000000000000..c0a20cd972e3 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/fsl-sec6.txt | |||
@@ -0,0 +1,157 @@ | |||
1 | SEC 6 is as Freescale's Cryptographic Accelerator and Assurance Module (CAAM). | ||
2 | Currently Freescale powerpc chip C29X is embeded with SEC 6. | ||
3 | SEC 6 device tree binding include: | ||
4 | -SEC 6 Node | ||
5 | -Job Ring Node | ||
6 | -Full Example | ||
7 | |||
8 | ===================================================================== | ||
9 | SEC 6 Node | ||
10 | |||
11 | Description | ||
12 | |||
13 | Node defines the base address of the SEC 6 block. | ||
14 | This block specifies the address range of all global | ||
15 | configuration registers for the SEC 6 block. | ||
16 | For example, In C293, we could see three SEC 6 node. | ||
17 | |||
18 | PROPERTIES | ||
19 | |||
20 | - compatible | ||
21 | Usage: required | ||
22 | Value type: <string> | ||
23 | Definition: Must include "fsl,sec-v6.0". | ||
24 | |||
25 | - fsl,sec-era | ||
26 | Usage: optional | ||
27 | Value type: <u32> | ||
28 | Definition: A standard property. Define the 'ERA' of the SEC | ||
29 | device. | ||
30 | |||
31 | - #address-cells | ||
32 | Usage: required | ||
33 | Value type: <u32> | ||
34 | Definition: A standard property. Defines the number of cells | ||
35 | for representing physical addresses in child nodes. | ||
36 | |||
37 | - #size-cells | ||
38 | Usage: required | ||
39 | Value type: <u32> | ||
40 | Definition: A standard property. Defines the number of cells | ||
41 | for representing the size of physical addresses in | ||
42 | child nodes. | ||
43 | |||
44 | - reg | ||
45 | Usage: required | ||
46 | Value type: <prop-encoded-array> | ||
47 | Definition: A standard property. Specifies the physical | ||
48 | address and length of the SEC 6 configuration registers. | ||
49 | |||
50 | - ranges | ||
51 | Usage: required | ||
52 | Value type: <prop-encoded-array> | ||
53 | Definition: A standard property. Specifies the physical address | ||
54 | range of the SEC 6.0 register space (-SNVS not included). A | ||
55 | triplet that includes the child address, parent address, & | ||
56 | length. | ||
57 | |||
58 | Note: All other standard properties (see the ePAPR) are allowed | ||
59 | but are optional. | ||
60 | |||
61 | EXAMPLE | ||
62 | crypto@a0000 { | ||
63 | compatible = "fsl,sec-v6.0"; | ||
64 | fsl,sec-era = <6>; | ||
65 | #address-cells = <1>; | ||
66 | #size-cells = <1>; | ||
67 | reg = <0xa0000 0x20000>; | ||
68 | ranges = <0 0xa0000 0x20000>; | ||
69 | }; | ||
70 | |||
71 | ===================================================================== | ||
72 | Job Ring (JR) Node | ||
73 | |||
74 | Child of the crypto node defines data processing interface to SEC 6 | ||
75 | across the peripheral bus for purposes of processing | ||
76 | cryptographic descriptors. The specified address | ||
77 | range can be made visible to one (or more) cores. | ||
78 | The interrupt defined for this node is controlled within | ||
79 | the address range of this node. | ||
80 | |||
81 | - compatible | ||
82 | Usage: required | ||
83 | Value type: <string> | ||
84 | Definition: Must include "fsl,sec-v6.0-job-ring". | ||
85 | |||
86 | - reg | ||
87 | Usage: required | ||
88 | Value type: <prop-encoded-array> | ||
89 | Definition: Specifies a two JR parameters: an offset from | ||
90 | the parent physical address and the length the JR registers. | ||
91 | |||
92 | - interrupts | ||
93 | Usage: required | ||
94 | Value type: <prop_encoded-array> | ||
95 | Definition: Specifies the interrupts generated by this | ||
96 | device. The value of the interrupts property | ||
97 | consists of one interrupt specifier. The format | ||
98 | of the specifier is defined by the binding document | ||
99 | describing the node's interrupt parent. | ||
100 | |||
101 | EXAMPLE | ||
102 | jr@1000 { | ||
103 | compatible = "fsl,sec-v6.0-job-ring"; | ||
104 | reg = <0x1000 0x1000>; | ||
105 | interrupts = <49 2 0 0>; | ||
106 | }; | ||
107 | |||
108 | =================================================================== | ||
109 | Full Example | ||
110 | |||
111 | Since some chips may contain more than one SEC, the dtsi contains | ||
112 | only the node contents, not the node itself. A chip using the SEC | ||
113 | should include the dtsi inside each SEC node. Example: | ||
114 | |||
115 | In qoriq-sec6.0.dtsi: | ||
116 | |||
117 | compatible = "fsl,sec-v6.0"; | ||
118 | fsl,sec-era = <6>; | ||
119 | #address-cells = <1>; | ||
120 | #size-cells = <1>; | ||
121 | |||
122 | jr@1000 { | ||
123 | compatible = "fsl,sec-v6.0-job-ring", | ||
124 | "fsl,sec-v5.2-job-ring", | ||
125 | "fsl,sec-v5.0-job-ring", | ||
126 | "fsl,sec-v4.4-job-ring", | ||
127 | "fsl,sec-v4.0-job-ring"; | ||
128 | reg = <0x1000 0x1000>; | ||
129 | }; | ||
130 | |||
131 | jr@2000 { | ||
132 | compatible = "fsl,sec-v6.0-job-ring", | ||
133 | "fsl,sec-v5.2-job-ring", | ||
134 | "fsl,sec-v5.0-job-ring", | ||
135 | "fsl,sec-v4.4-job-ring", | ||
136 | "fsl,sec-v4.0-job-ring"; | ||
137 | reg = <0x2000 0x1000>; | ||
138 | }; | ||
139 | |||
140 | In the C293 device tree, we add the include of public property: | ||
141 | |||
142 | crypto@a0000 { | ||
143 | /include/ "qoriq-sec6.0.dtsi" | ||
144 | } | ||
145 | |||
146 | crypto@a0000 { | ||
147 | reg = <0xa0000 0x20000>; | ||
148 | ranges = <0 0xa0000 0x20000>; | ||
149 | |||
150 | jr@1000 { | ||
151 | interrupts = <49 2 0 0>; | ||
152 | }; | ||
153 | |||
154 | jr@2000 { | ||
155 | interrupts = <50 2 0 0>; | ||
156 | }; | ||
157 | }; | ||
diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt index c280a0e6f42d..e1f343c7a34b 100644 --- a/Documentation/devicetree/bindings/dma/atmel-dma.txt +++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt | |||
@@ -18,14 +18,14 @@ dma0: dma@ffffec00 { | |||
18 | 18 | ||
19 | DMA clients connected to the Atmel DMA controller must use the format | 19 | DMA clients connected to the Atmel DMA controller must use the format |
20 | described in the dma.txt file, using a three-cell specifier for each channel: | 20 | described in the dma.txt file, using a three-cell specifier for each channel: |
21 | a phandle plus two interger cells. | 21 | a phandle plus two integer cells. |
22 | The three cells in order are: | 22 | The three cells in order are: |
23 | 23 | ||
24 | 1. A phandle pointing to the DMA controller. | 24 | 1. A phandle pointing to the DMA controller. |
25 | 2. The memory interface (16 most significant bits), the peripheral interface | 25 | 2. The memory interface (16 most significant bits), the peripheral interface |
26 | (16 less significant bits). | 26 | (16 less significant bits). |
27 | 3. Parameters for the at91 DMA configuration register which are device | 27 | 3. Parameters for the at91 DMA configuration register which are device |
28 | dependant: | 28 | dependent: |
29 | - bit 7-0: peripheral identifier for the hardware handshaking interface. The | 29 | - bit 7-0: peripheral identifier for the hardware handshaking interface. The |
30 | identifier can be different for tx and rx. | 30 | identifier can be different for tx and rx. |
31 | - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP. | 31 | - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP. |
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt index 2717ecb47db9..7bd8847d6394 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt | |||
@@ -34,7 +34,7 @@ Clients have to specify the DMA requests with phandles in a list. | |||
34 | Required properties: | 34 | Required properties: |
35 | - dmas: List of one or more DMA request specifiers. One DMA request specifier | 35 | - dmas: List of one or more DMA request specifiers. One DMA request specifier |
36 | consists of a phandle to the DMA controller followed by the integer | 36 | consists of a phandle to the DMA controller followed by the integer |
37 | specifiying the request line. | 37 | specifying the request line. |
38 | - dma-names: List of string identifiers for the DMA requests. For the correct | 38 | - dma-names: List of string identifiers for the DMA requests. For the correct |
39 | names, have a look at the specific client driver. | 39 | names, have a look at the specific client driver. |
40 | 40 | ||
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt index bea5b73a7390..a8c21c256baa 100644 --- a/Documentation/devicetree/bindings/dma/ste-dma40.txt +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt | |||
@@ -37,14 +37,14 @@ Each dmas request consists of 4 cells: | |||
37 | 1. A phandle pointing to the DMA controller | 37 | 1. A phandle pointing to the DMA controller |
38 | 2. Device Type | 38 | 2. Device Type |
39 | 3. The DMA request line number (only when 'use fixed channel' is set) | 39 | 3. The DMA request line number (only when 'use fixed channel' is set) |
40 | 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow] | 40 | 4. A 32bit mask specifying; mode, direction and endianness [NB: This list will grow] |
41 | 0x00000001: Mode: | 41 | 0x00000001: Mode: |
42 | Logical channel when unset | 42 | Logical channel when unset |
43 | Physical channel when set | 43 | Physical channel when set |
44 | 0x00000002: Direction: | 44 | 0x00000002: Direction: |
45 | Memory to Device when unset | 45 | Memory to Device when unset |
46 | Device to Memory when set | 46 | Device to Memory when set |
47 | 0x00000004: Endianess: | 47 | 0x00000004: Endianness: |
48 | Little endian when unset | 48 | Little endian when unset |
49 | Big endian when set | 49 | Big endian when set |
50 | 0x00000008: Use fixed channel: | 50 | 0x00000008: Use fixed channel: |
diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt index 58f531ab4df3..7dab6a8f4a0e 100644 --- a/Documentation/devicetree/bindings/extcon/extcon-twl.txt +++ b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt | |||
@@ -1,15 +1,15 @@ | |||
1 | EXTCON FOR TWL CHIPS | 1 | EXTCON FOR PALMAS/TWL CHIPS |
2 | 2 | ||
3 | PALMAS USB COMPARATOR | 3 | PALMAS USB COMPARATOR |
4 | Required Properties: | 4 | Required Properties: |
5 | - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb" | 5 | - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb" |
6 | - vbus-supply : phandle to the regulator device tree node. | ||
7 | 6 | ||
8 | Optional Properties: | 7 | Optional Properties: |
9 | - ti,wakeup : To enable the wakeup comparator in probe | 8 | - ti,wakeup : To enable the wakeup comparator in probe |
9 | - ti,enable-id-detection: Perform ID detection. | ||
10 | - ti,enable-vbus-detection: Perform VBUS detection. | ||
10 | 11 | ||
11 | palmas-usb { | 12 | palmas-usb { |
12 | compatible = "ti,twl6035-usb", "ti,palmas-usb"; | 13 | compatible = "ti,twl6035-usb", "ti,palmas-usb"; |
13 | vbus-supply = <&smps10_reg>; | ||
14 | ti,wakeup; | 14 | ti,wakeup; |
15 | }; | 15 | }; |
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index d933af370697..6cec6ff20d2e 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt | |||
@@ -75,23 +75,36 @@ Example of two SOC GPIO banks defined as gpio-controller nodes: | |||
75 | gpio-controller; | 75 | gpio-controller; |
76 | }; | 76 | }; |
77 | 77 | ||
78 | 2.1) gpio-controller and pinctrl subsystem | 78 | 2.1) gpio- and pin-controller interaction |
79 | ------------------------------------------ | 79 | ----------------------------------------- |
80 | 80 | ||
81 | gpio-controller on a SOC might be tightly coupled with the pinctrl | 81 | Some or all of the GPIOs provided by a GPIO controller may be routed to pins |
82 | subsystem, in the sense that the pins can be used by other functions | 82 | on the package via a pin controller. This allows muxing those pins between |
83 | together with optional gpio feature. | 83 | GPIO and other functions. |
84 | 84 | ||
85 | While the pin allocation is totally managed by the pin ctrl subsystem, | 85 | It is useful to represent which GPIOs correspond to which pins on which pin |
86 | gpio (under gpiolib) is still maintained by gpio drivers. It may happen | 86 | controllers. The gpio-ranges property described below represents this, and |
87 | that different pin ranges in a SoC is managed by different gpio drivers. | 87 | contains information structures as follows: |
88 | 88 | ||
89 | This makes it logical to let gpio drivers announce their pin ranges to | 89 | gpio-range-list ::= <single-gpio-range> [gpio-range-list] |
90 | the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to | 90 | single-gpio-range ::= |
91 | request the corresponding pin before any gpio usage. | 91 | <pinctrl-phandle> <gpio-base> <pinctrl-base> <count> |
92 | gpio-phandle : phandle to pin controller node. | ||
93 | gpio-base : Base GPIO ID in the GPIO controller | ||
94 | pinctrl-base : Base pinctrl pin ID in the pin controller | ||
95 | count : The number of GPIOs/pins in this range | ||
92 | 96 | ||
93 | For this, the gpio controller can use a pinctrl phandle and pins to | 97 | The "pin controller node" mentioned above must conform to the bindings |
94 | announce the pinrange to the pin ctrl subsystem. For example, | 98 | described in ../pinctrl/pinctrl-bindings.txt. |
99 | |||
100 | Previous versions of this binding required all pin controller nodes that | ||
101 | were referenced by any gpio-ranges property to contain a property named | ||
102 | #gpio-range-cells with value <3>. This requirement is now deprecated. | ||
103 | However, that property may still exist in older device trees for | ||
104 | compatibility reasons, and would still be required even in new device | ||
105 | trees that need to be compatible with older software. | ||
106 | |||
107 | Example: | ||
95 | 108 | ||
96 | qe_pio_e: gpio-controller@1460 { | 109 | qe_pio_e: gpio-controller@1460 { |
97 | #gpio-cells = <2>; | 110 | #gpio-cells = <2>; |
@@ -99,16 +112,8 @@ announce the pinrange to the pin ctrl subsystem. For example, | |||
99 | reg = <0x1460 0x18>; | 112 | reg = <0x1460 0x18>; |
100 | gpio-controller; | 113 | gpio-controller; |
101 | gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>; | 114 | gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>; |
115 | }; | ||
102 | 116 | ||
103 | } | 117 | Here, a single GPIO controller has GPIOs 0..9 routed to pin controller |
104 | 118 | pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's | |
105 | where, | 119 | pins 50..59. |
106 | &pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node. | ||
107 | |||
108 | Next values specify the base pin and number of pins for the range | ||
109 | handled by 'qe_pio_e' gpio. In the given example from base pin 20 to | ||
110 | pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under | ||
111 | pinctrl2 with gpio offset 10 is handled by this gpio controller. | ||
112 | |||
113 | The pinctrl node must have "#gpio-range-cells" property to show number of | ||
114 | arguments to pass with phandle from gpio controllers node. | ||
diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt new file mode 100644 index 000000000000..82cd1ed0be93 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt | |||
@@ -0,0 +1,27 @@ | |||
1 | * Samsung Image Rotator | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : value should be one of the following: | ||
5 | (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210 | ||
6 | (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412 | ||
7 | (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250 | ||
8 | |||
9 | - reg : Physical base address of the IP registers and length of memory | ||
10 | mapped region. | ||
11 | |||
12 | - interrupts : Interrupt specifier for rotator interrupt, according to format | ||
13 | specific to interrupt parent. | ||
14 | |||
15 | - clocks : Clock specifier for rotator clock, according to generic clock | ||
16 | bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt) | ||
17 | |||
18 | - clock-names : Names of clocks. For exynos rotator, it should be "rotator". | ||
19 | |||
20 | Example: | ||
21 | rotator@12810000 { | ||
22 | compatible = "samsung,exynos4210-rotator"; | ||
23 | reg = <0x12810000 0x1000>; | ||
24 | interrupts = <0 83 0>; | ||
25 | clocks = <&clock 278>; | ||
26 | clock-names = "rotator"; | ||
27 | }; | ||
diff --git a/Documentation/devicetree/bindings/hid/hid-over-i2c.txt b/Documentation/devicetree/bindings/hid/hid-over-i2c.txt new file mode 100644 index 000000000000..488edcb264c4 --- /dev/null +++ b/Documentation/devicetree/bindings/hid/hid-over-i2c.txt | |||
@@ -0,0 +1,28 @@ | |||
1 | * HID over I2C Device-Tree bindings | ||
2 | |||
3 | HID over I2C provides support for various Human Interface Devices over the | ||
4 | I2C bus. These devices can be for example touchpads, keyboards, touch screens | ||
5 | or sensors. | ||
6 | |||
7 | The specification has been written by Microsoft and is currently available here: | ||
8 | http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx | ||
9 | |||
10 | If this binding is used, the kernel module i2c-hid will handle the communication | ||
11 | with the device and the generic hid core layer will handle the protocol. | ||
12 | |||
13 | Required properties: | ||
14 | - compatible: must be "hid-over-i2c" | ||
15 | - reg: i2c slave address | ||
16 | - hid-descr-addr: HID descriptor address | ||
17 | - interrupt-parent: the phandle for the interrupt controller | ||
18 | - interrupts: interrupt line | ||
19 | |||
20 | Example: | ||
21 | |||
22 | i2c-hid-dev@2c { | ||
23 | compatible = "hid-over-i2c"; | ||
24 | reg = <0x2c>; | ||
25 | hid-descr-addr = <0x0020>; | ||
26 | interrupt-parent = <&gpx3>; | ||
27 | interrupts = <3 2>; | ||
28 | }; | ||
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt index 3614242e7732..4a8513e44740 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt | |||
@@ -1,7 +1,10 @@ | |||
1 | * Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX | 1 | * Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX |
2 | 2 | ||
3 | Required properties: | 3 | Required properties: |
4 | - compatible : Should be "fsl,<chip>-i2c" | 4 | - compatible : |
5 | - "fsl,imx1-i2c" for I2C compatible with the one integrated on i.MX1 SoC | ||
6 | - "fsl,imx21-i2c" for I2C compatible with the one integrated on i.MX21 SoC | ||
7 | - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC | ||
5 | - reg : Should contain I2C/HS-I2C registers location and length | 8 | - reg : Should contain I2C/HS-I2C registers location and length |
6 | - interrupts : Should contain I2C/HS-I2C interrupt | 9 | - interrupts : Should contain I2C/HS-I2C interrupt |
7 | 10 | ||
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt index 6113f9275f42..82e8f6f17179 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | |||
@@ -5,6 +5,7 @@ Required properties : | |||
5 | 5 | ||
6 | - reg : Offset and length of the register set for the device | 6 | - reg : Offset and length of the register set for the device |
7 | - compatible : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c" | 7 | - compatible : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c" |
8 | or "marvell,mv78230-i2c" | ||
8 | - interrupts : The interrupt number | 9 | - interrupts : The interrupt number |
9 | 10 | ||
10 | Optional properties : | 11 | Optional properties : |
@@ -20,3 +21,12 @@ Examples: | |||
20 | interrupts = <29>; | 21 | interrupts = <29>; |
21 | clock-frequency = <100000>; | 22 | clock-frequency = <100000>; |
22 | }; | 23 | }; |
24 | |||
25 | For the Armada XP: | ||
26 | |||
27 | i2c@11000 { | ||
28 | compatible = "marvell,mv78230-i2c", "marvell,mv64xxx-i2c"; | ||
29 | reg = <0x11000 0x100>; | ||
30 | interrupts = <29>; | ||
31 | clock-frequency = <100000>; | ||
32 | }; | ||
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt b/Documentation/devicetree/bindings/iio/accel/bma180.txt new file mode 100644 index 000000000000..c5933573e0f6 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt | |||
@@ -0,0 +1,24 @@ | |||
1 | * Bosch BMA180 triaxial acceleration sensor | ||
2 | |||
3 | http://omapworld.com/BMA180_111_1002839.pdf | ||
4 | |||
5 | Required properties: | ||
6 | |||
7 | - compatible : should be "bosch,bma180" | ||
8 | - reg : the I2C address of the sensor | ||
9 | |||
10 | Optional properties: | ||
11 | |||
12 | - interrupt-parent : should be the phandle for the interrupt controller | ||
13 | |||
14 | - interrupts : interrupt mapping for GPIO IRQ, it should by configured with | ||
15 | flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING | ||
16 | |||
17 | Example: | ||
18 | |||
19 | bma180@40 { | ||
20 | compatible = "bosch,bma180"; | ||
21 | reg = <0x40>; | ||
22 | interrupt-parent = <&gpio6>; | ||
23 | interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>; | ||
24 | }; | ||
diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt new file mode 100644 index 000000000000..e9582e6fe350 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt | |||
@@ -0,0 +1,18 @@ | |||
1 | * Nuvoton NAU7802 Analog to Digital Converter (ADC) | ||
2 | |||
3 | Required properties: | ||
4 | - compatible: Should be "nuvoton,nau7802" | ||
5 | - reg: Should contain the ADC I2C address | ||
6 | |||
7 | Optional properties: | ||
8 | - nuvoton,vldo: Internal reference voltage in millivolts to be | ||
9 | configured valid values are between 2400 mV and 4500 mV. | ||
10 | - interrupts: IRQ line for the ADC. If not used the driver will use | ||
11 | polling. | ||
12 | |||
13 | Example: | ||
14 | adc2: nau7802@2a { | ||
15 | compatible = "nuvoton,nau7802"; | ||
16 | reg = <0x2a>; | ||
17 | nuvoton,vldo = <3000>; | ||
18 | }; | ||
diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt b/Documentation/devicetree/bindings/iio/light/apds9300.txt new file mode 100644 index 000000000000..d6f66c73ddbf --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt | |||
@@ -0,0 +1,22 @@ | |||
1 | * Avago APDS9300 ambient light sensor | ||
2 | |||
3 | http://www.avagotech.com/docs/AV02-1077EN | ||
4 | |||
5 | Required properties: | ||
6 | |||
7 | - compatible : should be "avago,apds9300" | ||
8 | - reg : the I2C address of the sensor | ||
9 | |||
10 | Optional properties: | ||
11 | |||
12 | - interrupt-parent : should be the phandle for the interrupt controller | ||
13 | - interrupts : interrupt mapping for GPIO IRQ | ||
14 | |||
15 | Example: | ||
16 | |||
17 | apds9300@39 { | ||
18 | compatible = "avago,apds9300"; | ||
19 | reg = <0x39>; | ||
20 | interrupt-parent = <&gpio2>; | ||
21 | interrupts = <29 8>; | ||
22 | }; | ||
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7343.txt b/Documentation/devicetree/bindings/media/i2c/adv7343.txt new file mode 100644 index 000000000000..5653bc2428b8 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adv7343.txt | |||
@@ -0,0 +1,48 @@ | |||
1 | * Analog Devices adv7343 video encoder | ||
2 | |||
3 | The ADV7343 are high speed, digital-to-analog video encoders in a 64-lead LQFP | ||
4 | package. Six high speed, 3.3 V, 11-bit video DACs provide support for composite | ||
5 | (CVBS), S-Video (Y-C), and component (YPrPb/RGB) analog outputs in standard | ||
6 | definition (SD), enhanced definition (ED), or high definition (HD) video | ||
7 | formats. | ||
8 | |||
9 | Required Properties : | ||
10 | - compatible: Must be "adi,adv7343" | ||
11 | |||
12 | Optional Properties : | ||
13 | - adi,power-mode-sleep-mode: on enable the current consumption is reduced to | ||
14 | micro ampere level. All DACs and the internal PLL | ||
15 | circuit are disabled. | ||
16 | - adi,power-mode-pll-ctrl: PLL and oversampling control. This control allows | ||
17 | internal PLL 1 circuit to be powered down and the | ||
18 | oversampling to be switched off. | ||
19 | - ad,adv7343-power-mode-dac: array configuring the power on/off DAC's 1..6, | ||
20 | 0 = OFF and 1 = ON, Default value when this | ||
21 | property is not specified is <0 0 0 0 0 0>. | ||
22 | - ad,adv7343-sd-config-dac-out: array configure SD DAC Output's 1 and 2, 0 = OFF | ||
23 | and 1 = ON, Default value when this property is | ||
24 | not specified is <0 0>. | ||
25 | |||
26 | Example: | ||
27 | |||
28 | i2c0@1c22000 { | ||
29 | ... | ||
30 | ... | ||
31 | |||
32 | adv7343@2a { | ||
33 | compatible = "adi,adv7343"; | ||
34 | reg = <0x2a>; | ||
35 | |||
36 | port { | ||
37 | adv7343_1: endpoint { | ||
38 | adi,power-mode-sleep-mode; | ||
39 | adi,power-mode-pll-ctrl; | ||
40 | /* Use DAC1..3, DAC6 */ | ||
41 | adi,dac-enable = <1 1 1 0 0 1>; | ||
42 | /* Use SD DAC output 1 */ | ||
43 | adi,sd-dac-enable = <1 0>; | ||
44 | }; | ||
45 | }; | ||
46 | }; | ||
47 | ... | ||
48 | }; | ||
diff --git a/Documentation/devicetree/bindings/media/i2c/ths8200.txt b/Documentation/devicetree/bindings/media/i2c/ths8200.txt new file mode 100644 index 000000000000..285f6ae7dfa9 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ths8200.txt | |||
@@ -0,0 +1,19 @@ | |||
1 | * Texas Instruments THS8200 video encoder | ||
2 | |||
3 | The ths8200 device is a digital to analog converter used in DVD players, video | ||
4 | recorders, set-top boxes. | ||
5 | |||
6 | Required Properties : | ||
7 | - compatible : value must be "ti,ths8200" | ||
8 | |||
9 | Example: | ||
10 | |||
11 | i2c0@1c22000 { | ||
12 | ... | ||
13 | ... | ||
14 | ths8200@5c { | ||
15 | compatible = "ti,ths8200"; | ||
16 | reg = <0x5c>; | ||
17 | }; | ||
18 | ... | ||
19 | }; | ||
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt new file mode 100644 index 000000000000..5f28b5d9abcc --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt | |||
@@ -0,0 +1,53 @@ | |||
1 | * Texas Instruments TV7002 video decoder | ||
2 | |||
3 | The TVP7002 device supports digitizing of video and graphics signal in RGB and | ||
4 | YPbPr color space. | ||
5 | |||
6 | Required Properties : | ||
7 | - compatible : Must be "ti,tvp7002" | ||
8 | |||
9 | Optional Properties: | ||
10 | - hsync-active: HSYNC Polarity configuration for the bus. Default value when | ||
11 | this property is not specified is <0>. | ||
12 | |||
13 | - vsync-active: VSYNC Polarity configuration for the bus. Default value when | ||
14 | this property is not specified is <0>. | ||
15 | |||
16 | - pclk-sample: Clock polarity of the bus. Default value when this property is | ||
17 | not specified is <0>. | ||
18 | |||
19 | - sync-on-green-active: Active state of Sync-on-green signal property of the | ||
20 | endpoint. | ||
21 | 0 = Normal Operation (Active Low, Default) | ||
22 | 1 = Inverted operation | ||
23 | |||
24 | - field-even-active: Active-high Field ID output polarity control of the bus. | ||
25 | Under normal operation, the field ID output is set to logic 1 for an odd field | ||
26 | (field 1) and set to logic 0 for an even field (field 0). | ||
27 | 0 = Normal Operation (Active Low, Default) | ||
28 | 1 = FID output polarity inverted | ||
29 | |||
30 | For further reading of port node refer Documentation/devicetree/bindings/media/ | ||
31 | video-interfaces.txt. | ||
32 | |||
33 | Example: | ||
34 | |||
35 | i2c0@1c22000 { | ||
36 | ... | ||
37 | ... | ||
38 | tvp7002@5c { | ||
39 | compatible = "ti,tvp7002"; | ||
40 | reg = <0x5c>; | ||
41 | |||
42 | port { | ||
43 | tvp7002_1: endpoint { | ||
44 | hsync-active = <1>; | ||
45 | vsync-active = <1>; | ||
46 | pclk-sample = <0>; | ||
47 | sync-on-green-active = <1>; | ||
48 | field-even-active = <0>; | ||
49 | }; | ||
50 | }; | ||
51 | }; | ||
52 | ... | ||
53 | }; | ||
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index d75c3e589d43..f4181680831b 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt | |||
@@ -10,6 +10,7 @@ Required properties: | |||
10 | - compatible : value should be either one among the following | 10 | - compatible : value should be either one among the following |
11 | (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs | 11 | (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs |
12 | (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs | 12 | (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs |
13 | (b) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC | ||
13 | 14 | ||
14 | - reg : Physical base address of the IP registers and length of memory | 15 | - reg : Physical base address of the IP registers and length of memory |
15 | mapped region. | 16 | mapped region. |
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2dc4962..ce719f89dd1c 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt | |||
@@ -88,6 +88,8 @@ Optional endpoint properties | |||
88 | - field-even-active: field signal level during the even field data transmission. | 88 | - field-even-active: field signal level during the even field data transmission. |
89 | - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock | 89 | - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock |
90 | signal. | 90 | signal. |
91 | - sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for | ||
92 | LOW/HIGH respectively. | ||
91 | - data-lanes: an array of physical data lane indexes. Position of an entry | 93 | - data-lanes: an array of physical data lane indexes. Position of an entry |
92 | determines the logical lane number, while the value of an entry indicates | 94 | determines the logical lane number, while the value of an entry indicates |
93 | physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have | 95 | physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have |
diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt index e0e59c58a1f9..5f229c5f6da9 100644 --- a/Documentation/devicetree/bindings/mfd/cros-ec.txt +++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt | |||
@@ -4,7 +4,7 @@ Google's ChromeOS EC is a Cortex-M device which talks to the AP and | |||
4 | implements various function such as keyboard and battery charging. | 4 | implements various function such as keyboard and battery charging. |
5 | 5 | ||
6 | The EC can be connect through various means (I2C, SPI, LPC) and the | 6 | The EC can be connect through various means (I2C, SPI, LPC) and the |
7 | compatible string used depends on the inteface. Each connection method has | 7 | compatible string used depends on the interface. Each connection method has |
8 | its own driver which connects to the top level interface-agnostic EC driver. | 8 | its own driver which connects to the top level interface-agnostic EC driver. |
9 | Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to | 9 | Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to |
10 | the top-level driver. | 10 | the top-level driver. |
diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt index 38e51ad2e07e..a45ae08c8ed1 100644 --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt | |||
@@ -7,9 +7,30 @@ Required properties: | |||
7 | - reg: Should contain SSC registers location and length | 7 | - reg: Should contain SSC registers location and length |
8 | - interrupts: Should contain SSC interrupt | 8 | - interrupts: Should contain SSC interrupt |
9 | 9 | ||
10 | Example: | 10 | |
11 | Required properties for devices compatible with "atmel,at91sam9g45-ssc": | ||
12 | - dmas: DMA specifier, consisting of a phandle to DMA controller node, | ||
13 | the memory interface and SSC DMA channel ID (for tx and rx). | ||
14 | See Documentation/devicetree/bindings/dma/atmel-dma.txt for details. | ||
15 | - dma-names: Must be "tx", "rx". | ||
16 | |||
17 | Examples: | ||
18 | - PDC transfer: | ||
11 | ssc0: ssc@fffbc000 { | 19 | ssc0: ssc@fffbc000 { |
12 | compatible = "atmel,at91rm9200-ssc"; | 20 | compatible = "atmel,at91rm9200-ssc"; |
13 | reg = <0xfffbc000 0x4000>; | 21 | reg = <0xfffbc000 0x4000>; |
14 | interrupts = <14 4 5>; | 22 | interrupts = <14 4 5>; |
15 | }; | 23 | }; |
24 | |||
25 | - DMA transfer: | ||
26 | ssc0: ssc@f0010000 { | ||
27 | compatible = "atmel,at91sam9g45-ssc"; | ||
28 | reg = <0xf0010000 0x4000>; | ||
29 | interrupts = <28 4 5>; | ||
30 | dmas = <&dma0 1 13>, | ||
31 | <&dma0 1 14>; | ||
32 | dma-names = "tx", "rx"; | ||
33 | pinctrl-names = "default"; | ||
34 | pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>; | ||
35 | status = "disabled"; | ||
36 | }; | ||
diff --git a/Documentation/devicetree/bindings/net/can/atmel-can.txt b/Documentation/devicetree/bindings/net/can/atmel-can.txt index 72cf0c5daff4..14e52a0d86ec 100644 --- a/Documentation/devicetree/bindings/net/can/atmel-can.txt +++ b/Documentation/devicetree/bindings/net/can/atmel-can.txt | |||
@@ -8,7 +8,7 @@ Required properties: | |||
8 | Example: | 8 | Example: |
9 | 9 | ||
10 | can0: can@f000c000 { | 10 | can0: can@f000c000 { |
11 | compatbile = "atmel,at91sam9x5-can"; | 11 | compatible = "atmel,at91sam9x5-can"; |
12 | reg = <0xf000c000 0x300>; | 12 | reg = <0xf000c000 0x300>; |
13 | interrupts = <40 4 5> | 13 | interrupts = <40 4 5> |
14 | }; | 14 | }; |
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz9021.txt b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt new file mode 100644 index 000000000000..997a63f1aea1 --- /dev/null +++ b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt | |||
@@ -0,0 +1,49 @@ | |||
1 | Micrel KSZ9021 Gigabit Ethernet PHY | ||
2 | |||
3 | Some boards require special tuning values, particularly when it comes to | ||
4 | clock delays. You can specify clock delay values by adding | ||
5 | micrel-specific properties to an Ethernet OF device node. | ||
6 | |||
7 | All skew control options are specified in picoseconds. The minimum | ||
8 | value is 0, and the maximum value is 3000. | ||
9 | |||
10 | Optional properties: | ||
11 | - rxc-skew-ps : Skew control of RXC pad | ||
12 | - rxdv-skew-ps : Skew control of RX CTL pad | ||
13 | - txc-skew-ps : Skew control of TXC pad | ||
14 | - txen-skew-ps : Skew control of TX_CTL pad | ||
15 | - rxd0-skew-ps : Skew control of RX data 0 pad | ||
16 | - rxd1-skew-ps : Skew control of RX data 1 pad | ||
17 | - rxd2-skew-ps : Skew control of RX data 2 pad | ||
18 | - rxd3-skew-ps : Skew control of RX data 3 pad | ||
19 | - txd0-skew-ps : Skew control of TX data 0 pad | ||
20 | - txd1-skew-ps : Skew control of TX data 1 pad | ||
21 | - txd2-skew-ps : Skew control of TX data 2 pad | ||
22 | - txd3-skew-ps : Skew control of TX data 3 pad | ||
23 | |||
24 | Examples: | ||
25 | |||
26 | /* Attach to an Ethernet device with autodetected PHY */ | ||
27 | &enet { | ||
28 | rxc-skew-ps = <3000>; | ||
29 | rxdv-skew-ps = <0>; | ||
30 | txc-skew-ps = <3000>; | ||
31 | txen-skew-ps = <0>; | ||
32 | status = "okay"; | ||
33 | }; | ||
34 | |||
35 | /* Attach to an explicitly-specified PHY */ | ||
36 | mdio { | ||
37 | phy0: ethernet-phy@0 { | ||
38 | rxc-skew-ps = <3000>; | ||
39 | rxdv-skew-ps = <0>; | ||
40 | txc-skew-ps = <3000>; | ||
41 | txen-skew-ps = <0>; | ||
42 | reg = <0>; | ||
43 | }; | ||
44 | }; | ||
45 | ethernet@70000 { | ||
46 | status = "okay"; | ||
47 | phy = <&phy0>; | ||
48 | phy-mode = "rgmii-id"; | ||
49 | }; | ||
diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt new file mode 100644 index 000000000000..583418b2c127 --- /dev/null +++ b/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt | |||
@@ -0,0 +1,21 @@ | |||
1 | MOXA ART Ethernet Controller | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | - compatible : Must be "moxa,moxart-mac" | ||
6 | - reg : Should contain register location and length | ||
7 | - interrupts : Should contain the mac interrupt number | ||
8 | |||
9 | Example: | ||
10 | |||
11 | mac0: mac@90900000 { | ||
12 | compatible = "moxa,moxart-mac"; | ||
13 | reg = <0x90900000 0x100>; | ||
14 | interrupts = <25 0>; | ||
15 | }; | ||
16 | |||
17 | mac1: mac@92000000 { | ||
18 | compatible = "moxa,moxart-mac"; | ||
19 | reg = <0x92000000 0x100>; | ||
20 | interrupts = <27 0>; | ||
21 | }; | ||
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index 261c563b5f06..eba0e5e59ebe 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt | |||
@@ -22,6 +22,11 @@ Required properties: | |||
22 | - snps,pbl Programmable Burst Length | 22 | - snps,pbl Programmable Burst Length |
23 | - snps,fixed-burst Program the DMA to use the fixed burst mode | 23 | - snps,fixed-burst Program the DMA to use the fixed burst mode |
24 | - snps,mixed-burst Program the DMA to use the mixed burst mode | 24 | - snps,mixed-burst Program the DMA to use the mixed burst mode |
25 | - snps,force_thresh_dma_mode Force DMA to use the threshold mode for | ||
26 | both tx and rx | ||
27 | - snps,force_sf_dma_mode Force DMA to use the Store and Forward | ||
28 | mode for both tx and rx. This flag is | ||
29 | ignored if force_thresh_dma_mode is set. | ||
25 | 30 | ||
26 | Optional properties: | 31 | Optional properties: |
27 | - mac-address: 6 bytes, mac address | 32 | - mac-address: 6 bytes, mac address |
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index e2371f5cdebe..eabcb4b5db6e 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt | |||
@@ -18,6 +18,7 @@ Required properties: | |||
18 | - interrupt-map-mask and interrupt-map: standard PCI properties | 18 | - interrupt-map-mask and interrupt-map: standard PCI properties |
19 | to define the mapping of the PCIe interface to interrupt | 19 | to define the mapping of the PCIe interface to interrupt |
20 | numbers. | 20 | numbers. |
21 | - num-lanes: number of lanes to use | ||
21 | - reset-gpio: gpio pin number of power good signal | 22 | - reset-gpio: gpio pin number of power good signal |
22 | 23 | ||
23 | Example: | 24 | Example: |
@@ -41,6 +42,7 @@ SoC specific DT Entry: | |||
41 | #interrupt-cells = <1>; | 42 | #interrupt-cells = <1>; |
42 | interrupt-map-mask = <0 0 0 0>; | 43 | interrupt-map-mask = <0 0 0 0>; |
43 | interrupt-map = <0x0 0 &gic 53>; | 44 | interrupt-map = <0x0 0 &gic 53>; |
45 | num-lanes = <4>; | ||
44 | }; | 46 | }; |
45 | 47 | ||
46 | pcie@2a0000 { | 48 | pcie@2a0000 { |
@@ -60,6 +62,7 @@ SoC specific DT Entry: | |||
60 | #interrupt-cells = <1>; | 62 | #interrupt-cells = <1>; |
61 | interrupt-map-mask = <0 0 0 0>; | 63 | interrupt-map-mask = <0 0 0 0>; |
62 | interrupt-map = <0x0 0 &gic 56>; | 64 | interrupt-map = <0x0 0 &gic 56>; |
65 | num-lanes = <4>; | ||
63 | }; | 66 | }; |
64 | 67 | ||
65 | Board specific DT Entry: | 68 | Board specific DT Entry: |
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt index 648d60eb9fd8..7ccae490ff6d 100644 --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt | |||
@@ -37,7 +37,7 @@ Bank: 3 (A, B and C) | |||
37 | 0xffffffff 0x7fff3ccf /* pioB */ | 37 | 0xffffffff 0x7fff3ccf /* pioB */ |
38 | 0xffffffff 0x007fffff /* pioC */ | 38 | 0xffffffff 0x007fffff /* pioC */ |
39 | 39 | ||
40 | For each peripheral/bank we will descibe in a u32 if a pin can can be | 40 | For each peripheral/bank we will descibe in a u32 if a pin can be |
41 | configured in it by putting 1 to the pin bit (1 << pin) | 41 | configured in it by putting 1 to the pin bit (1 << pin) |
42 | 42 | ||
43 | Let's take the pioA on peripheral B | 43 | Let's take the pioA on peripheral B |
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index aeb3c995cc04..1958ca9f9e5c 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | |||
@@ -127,21 +127,20 @@ whether there is any interaction between the child and intermediate parent | |||
127 | nodes, is again defined entirely by the binding for the individual pin | 127 | nodes, is again defined entirely by the binding for the individual pin |
128 | controller device. | 128 | controller device. |
129 | 129 | ||
130 | == Using generic pinconfig options == | 130 | == Generic pin configuration node content == |
131 | 131 | ||
132 | Generic pinconfig parameters can be used by defining a separate node containing | 132 | Many data items that are represented in a pin configuration node are common |
133 | the applicable parameters (and optional values), like: | 133 | and generic. Pin control bindings should use the properties defined below |
134 | where they are applicable; not all of these properties are relevant or useful | ||
135 | for all hardware or binding structures. Each individual binding document | ||
136 | should state which of these generic properties, if any, are used, and the | ||
137 | structure of the DT nodes that contain these properties. | ||
134 | 138 | ||
135 | pcfg_pull_up: pcfg_pull_up { | 139 | Supported generic properties are: |
136 | bias-pull-up; | ||
137 | drive-strength = <20>; | ||
138 | }; | ||
139 | |||
140 | This node should then be referenced in the appropriate pinctrl node as a phandle | ||
141 | and parsed in the driver using the pinconf_generic_parse_dt_config function. | ||
142 | |||
143 | Supported configuration parameters are: | ||
144 | 140 | ||
141 | pins - the list of pins that properties in the node | ||
142 | apply to | ||
143 | function - the mux function to select | ||
145 | bias-disable - disable any pin bias | 144 | bias-disable - disable any pin bias |
146 | bias-high-impedance - high impedance mode ("third-state", "floating") | 145 | bias-high-impedance - high impedance mode ("third-state", "floating") |
147 | bias-bus-hold - latch weakly | 146 | bias-bus-hold - latch weakly |
@@ -160,7 +159,21 @@ low-power-disable - disable low power mode | |||
160 | output-low - set the pin to output mode with low level | 159 | output-low - set the pin to output mode with low level |
161 | output-high - set the pin to output mode with high level | 160 | output-high - set the pin to output mode with high level |
162 | 161 | ||
163 | Arguments for parameters: | 162 | Some of the generic properties take arguments. For those that do, the |
163 | arguments are described below. | ||
164 | |||
165 | - pins takes a list of pin names or IDs as a required argument. The specific | ||
166 | binding for the hardware defines: | ||
167 | - Whether the entries are integers or strings, and their meaning. | ||
168 | |||
169 | - function takes a list of function names/IDs as a required argument. The | ||
170 | specific binding for the hardware defines: | ||
171 | - Whether the entries are integers or strings, and their meaning. | ||
172 | - Whether only a single entry is allowed (which is applied to all entries | ||
173 | in the pins property), or whether there may alternatively be one entry per | ||
174 | entry in the pins property, in which case the list lengths must match, and | ||
175 | for each list index i, the function at list index i is applied to the pin | ||
176 | at list index i. | ||
164 | 177 | ||
165 | - bias-pull-up, -down and -pin-default take as optional argument on hardware | 178 | - bias-pull-up, -down and -pin-default take as optional argument on hardware |
166 | supporting it the pull strength in Ohm. bias-disable will disable the pull. | 179 | supporting it the pull strength in Ohm. bias-disable will disable the pull. |
@@ -170,7 +183,5 @@ Arguments for parameters: | |||
170 | - input-debounce takes the debounce time in usec as argument | 183 | - input-debounce takes the debounce time in usec as argument |
171 | or 0 to disable debouncing | 184 | or 0 to disable debouncing |
172 | 185 | ||
173 | All parameters not listed here, do not take an argument. | ||
174 | |||
175 | More in-depth documentation on these parameters can be found in | 186 | More in-depth documentation on these parameters can be found in |
176 | <include/linux/pinctrl/pinconfig-generic.h> | 187 | <include/linux/pinctrl/pinconfig-generic.h> |
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt new file mode 100644 index 000000000000..734d9b04d533 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt | |||
@@ -0,0 +1,96 @@ | |||
1 | Palmas Pincontrol bindings | ||
2 | |||
3 | The pins of Palmas device can be set on different option and provides | ||
4 | the configuration for Pull UP/DOWN, open drain etc. | ||
5 | |||
6 | Required properties: | ||
7 | - compatible: It must be one of following: | ||
8 | - "ti,palmas-pinctrl" for Palma series of the pincontrol. | ||
9 | - "ti,tps65913-pinctrl" for Palma series device TPS65913. | ||
10 | - "ti,tps80036-pinctrl" for Palma series device TPS80036. | ||
11 | |||
12 | Please refer to pinctrl-bindings.txt in this directory for details of the | ||
13 | common pinctrl bindings used by client devices, including the meaning of the | ||
14 | phrase "pin configuration node". | ||
15 | |||
16 | Palmas's pin configuration nodes act as a container for an arbitrary number of | ||
17 | subnodes. Each of these subnodes represents some desired configuration for a | ||
18 | list of pins. This configuration can include the mux function to select on | ||
19 | those pin(s), and various pin configuration parameters, such as pull-up, | ||
20 | open drain. | ||
21 | |||
22 | The name of each subnode is not important; all subnodes should be enumerated | ||
23 | and processed purely based on their content. | ||
24 | |||
25 | Each subnode only affects those parameters that are explicitly listed. In | ||
26 | other words, a subnode that lists a mux function but no pin configuration | ||
27 | parameters implies no information about any pin configuration parameters. | ||
28 | Similarly, a pin subnode that describes a pullup parameter implies no | ||
29 | information about e.g. the mux function. | ||
30 | |||
31 | Optional properties: | ||
32 | - ti,palmas-enable-dvfs1: Enable DVFS1. Configure pins for DVFS1 mode. | ||
33 | Selection primary or secondary function associated to I2C2_SCL_SCE, | ||
34 | I2C2_SDA_SDO pin/pad for DVFS1 interface | ||
35 | - ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode. | ||
36 | Selection primary or secondary function associated to GPADC_START | ||
37 | and SYSEN2 pin/pad for DVFS2 interface | ||
38 | |||
39 | This binding uses the following generic properties as defined in | ||
40 | pinctrl-bindings.txt: | ||
41 | |||
42 | Required: pins | ||
43 | Options: function, bias-disable, bias-pull-up, bias-pull-down, | ||
44 | bias-pin-default, drive-open-drain. | ||
45 | |||
46 | Note that many of these properties are only valid for certain specific pins. | ||
47 | See the Palmas device datasheet for complete details regarding which pins | ||
48 | support which functionality. | ||
49 | |||
50 | Valid values for pin names are: | ||
51 | gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7, gpio8, gpio9, | ||
52 | gpio10, gpio11, gpio12, gpio13, gpio14, gpio15, vac, powergood, | ||
53 | nreswarm, pwrdown, gpadc_start, reset_in, nsleep, enable1, enable2, | ||
54 | int. | ||
55 | |||
56 | Valid value of function names are: | ||
57 | gpio, led, pwm, regen, sysen, clk32kgaudio, id, vbus_det, chrg_det, | ||
58 | vac, vacok, powergood, usb_psel, msecure, pwrhold, int, nreswarm, | ||
59 | simrsto, simrsti, low_vbat, wireless_chrg1, rcm, pwrdown, gpadc_start, | ||
60 | reset_in, nsleep, enable. | ||
61 | |||
62 | There are 4 special functions: opt0, opt1, opt2 and opt3. If any of these | ||
63 | functions is selected then directly pins register will be written with 0, 1, 2 | ||
64 | or 3 respectively if it is valid for that pins or list of pins. | ||
65 | |||
66 | Example: | ||
67 | palmas: tps65913 { | ||
68 | .... | ||
69 | pinctrl { | ||
70 | compatible = "ti,tps65913-pinctrl"; | ||
71 | ti,palmas-enable-dvfs1; | ||
72 | pinctrl-names = "default"; | ||
73 | pinctrl-0 = <&palmas_pins_state>; | ||
74 | |||
75 | palmas_pins_state: pinmux { | ||
76 | gpio0 { | ||
77 | pins = "gpio0"; | ||
78 | function = "id"; | ||
79 | bias-pull-up; | ||
80 | }; | ||
81 | |||
82 | vac { | ||
83 | pins = "vac"; | ||
84 | function = "vacok"; | ||
85 | bias-pull-down; | ||
86 | }; | ||
87 | |||
88 | gpio5 { | ||
89 | pins = "gpio5"; | ||
90 | function = "opt0"; | ||
91 | drive-open-drain = <1>; | ||
92 | }; | ||
93 | }; | ||
94 | }; | ||
95 | .... | ||
96 | }; | ||
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index 36281e7a2a46..257677de3e6b 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | |||
@@ -12,6 +12,7 @@ Required Properties: | |||
12 | - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller, | 12 | - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller, |
13 | - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller, | 13 | - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller, |
14 | - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller, | 14 | - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller, |
15 | - "samsung,s5pv210-pinctrl": for S5PV210-compatible pin-controller, | ||
15 | - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller. | 16 | - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller. |
16 | - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller. | 17 | - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller. |
17 | - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller. | 18 | - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller. |
@@ -128,7 +129,7 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a | |||
128 | - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller | 129 | - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller |
129 | found on Samsung S3C64xx SoCs, | 130 | found on Samsung S3C64xx SoCs, |
130 | - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller | 131 | - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller |
131 | found on Samsung Exynos4210 SoC. | 132 | found on Samsung Exynos4210 and S5PC110/S5PV210 SoCs. |
132 | - interrupt-parent: phandle of the interrupt parent to which the external | 133 | - interrupt-parent: phandle of the interrupt parent to which the external |
133 | wakeup interrupts are forwarded to. | 134 | wakeup interrupts are forwarded to. |
134 | - interrupts: interrupt used by multiplexed wakeup interrupts. | 135 | - interrupts: interrupt used by multiplexed wakeup interrupts. |
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt index 5693877ab377..82dd5b65cf48 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt | |||
@@ -1,21 +1,20 @@ | |||
1 | * Freescale MSI interrupt controller | 1 | * Freescale MSI interrupt controller |
2 | 2 | ||
3 | Required properties: | 3 | Required properties: |
4 | - compatible : compatible list, contains 2 entries, | 4 | - compatible : compatible list, may contain one or two entries |
5 | first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572, | 5 | The first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572, |
6 | etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on | 6 | etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" or |
7 | the parent type. | 7 | "fsl,mpic-msi-v4.3" depending on the parent type and version. If mpic |
8 | version is 4.3, the number of MSI registers is increased to 16, MSIIR1 is | ||
9 | provided to access these 16 registers, and compatible "fsl,mpic-msi-v4.3" | ||
10 | should be used. The first entry is optional; the second entry is | ||
11 | required. | ||
8 | 12 | ||
9 | - reg : It may contain one or two regions. The first region should contain | 13 | - reg : It may contain one or two regions. The first region should contain |
10 | the address and the length of the shared message interrupt register set. | 14 | the address and the length of the shared message interrupt register set. |
11 | The second region should contain the address of aliased MSIIR register for | 15 | The second region should contain the address of aliased MSIIR or MSIIR1 |
12 | platforms that have such an alias. | 16 | register for platforms that have such an alias, if using MSIIR1, the second |
13 | 17 | region must be added because different MSI group has different MSIIR1 offset. | |
14 | - msi-available-ranges: use <start count> style section to define which | ||
15 | msi interrupt can be used in the 256 msi interrupts. This property is | ||
16 | optional, without this, all the 256 MSI interrupts can be used. | ||
17 | Each available range must begin and end on a multiple of 32 (i.e. | ||
18 | no splitting an individual MSI register or the associated PIC interrupt). | ||
19 | 18 | ||
20 | - interrupts : each one of the interrupts here is one entry per 32 MSIs, | 19 | - interrupts : each one of the interrupts here is one entry per 32 MSIs, |
21 | and routed to the host interrupt controller. the interrupts should | 20 | and routed to the host interrupt controller. the interrupts should |
@@ -28,6 +27,14 @@ Required properties: | |||
28 | to MPIC. | 27 | to MPIC. |
29 | 28 | ||
30 | Optional properties: | 29 | Optional properties: |
30 | - msi-available-ranges: use <start count> style section to define which | ||
31 | msi interrupt can be used in the 256 msi interrupts. This property is | ||
32 | optional, without this, all the MSI interrupts can be used. | ||
33 | Each available range must begin and end on a multiple of 32 (i.e. | ||
34 | no splitting an individual MSI register or the associated PIC interrupt). | ||
35 | MPIC v4.3 does not support this property because the 32 interrupts of an | ||
36 | individual register are not continuous when using MSIIR1. | ||
37 | |||
31 | - msi-address-64: 64-bit PCI address of the MSIIR register. The MSIIR register | 38 | - msi-address-64: 64-bit PCI address of the MSIIR register. The MSIIR register |
32 | is used for MSI messaging. The address of MSIIR in PCI address space is | 39 | is used for MSI messaging. The address of MSIIR in PCI address space is |
33 | the MSI message address. | 40 | the MSI message address. |
@@ -54,6 +61,28 @@ Example: | |||
54 | interrupt-parent = <&mpic>; | 61 | interrupt-parent = <&mpic>; |
55 | }; | 62 | }; |
56 | 63 | ||
64 | msi@41600 { | ||
65 | compatible = "fsl,mpic-msi-v4.3"; | ||
66 | reg = <0x41600 0x200 0x44148 4>; | ||
67 | interrupts = < | ||
68 | 0xe0 0 0 0 | ||
69 | 0xe1 0 0 0 | ||
70 | 0xe2 0 0 0 | ||
71 | 0xe3 0 0 0 | ||
72 | 0xe4 0 0 0 | ||
73 | 0xe5 0 0 0 | ||
74 | 0xe6 0 0 0 | ||
75 | 0xe7 0 0 0 | ||
76 | 0x100 0 0 0 | ||
77 | 0x101 0 0 0 | ||
78 | 0x102 0 0 0 | ||
79 | 0x103 0 0 0 | ||
80 | 0x104 0 0 0 | ||
81 | 0x105 0 0 0 | ||
82 | 0x106 0 0 0 | ||
83 | 0x107 0 0 0>; | ||
84 | }; | ||
85 | |||
57 | The Freescale hypervisor and msi-address-64 | 86 | The Freescale hypervisor and msi-address-64 |
58 | ------------------------------------------- | 87 | ------------------------------------------- |
59 | Normally, PCI devices have access to all of CCSR via an ATMU mapping. The | 88 | Normally, PCI devices have access to all of CCSR via an ATMU mapping. The |
diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt index de0eaed86651..8031148bcf85 100644 --- a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | |||
@@ -2,11 +2,9 @@ Atmel TCB PWM controller | |||
2 | 2 | ||
3 | Required properties: | 3 | Required properties: |
4 | - compatible: should be "atmel,tcb-pwm" | 4 | - compatible: should be "atmel,tcb-pwm" |
5 | - #pwm-cells: Should be 3. The first cell specifies the per-chip index | 5 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of |
6 | of the PWM to use, the second cell is the period in nanoseconds and | 6 | the cells format. The only third cell flag supported by this binding is |
7 | bit 0 in the third cell is used to encode the polarity of PWM output. | 7 | PWM_POLARITY_INVERTED. |
8 | Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity & | ||
9 | set to 0 for normal polarity. | ||
10 | - tc-block: The Timer Counter block to use as a PWM chip. | 8 | - tc-block: The Timer Counter block to use as a PWM chip. |
11 | 9 | ||
12 | Example: | 10 | Example: |
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt index 8522bfbccfd7..b50d7a6d9d7f 100644 --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt | |||
@@ -3,8 +3,8 @@ Freescale i.MX PWM controller | |||
3 | Required properties: | 3 | Required properties: |
4 | - compatible: should be "fsl,<soc>-pwm" | 4 | - compatible: should be "fsl,<soc>-pwm" |
5 | - reg: physical base address and length of the controller's registers | 5 | - reg: physical base address and length of the controller's registers |
6 | - #pwm-cells: should be 2. The first cell specifies the per-chip index | 6 | - #pwm-cells: should be 2. See pwm.txt in this directory for a description of |
7 | of the PWM to use and the second cell is the period in nanoseconds. | 7 | the cells format. |
8 | - interrupts: The interrupt for the pwm controller | 8 | - interrupts: The interrupt for the pwm controller |
9 | 9 | ||
10 | Example: | 10 | Example: |
diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt index 9e3f8f1d46a2..96cdde5f6208 100644 --- a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt | |||
@@ -3,8 +3,8 @@ Freescale MXS PWM controller | |||
3 | Required properties: | 3 | Required properties: |
4 | - compatible: should be "fsl,imx23-pwm" | 4 | - compatible: should be "fsl,imx23-pwm" |
5 | - reg: physical base address and length of the controller's registers | 5 | - reg: physical base address and length of the controller's registers |
6 | - #pwm-cells: should be 2. The first cell specifies the per-chip index | 6 | - #pwm-cells: should be 2. See pwm.txt in this directory for a description of |
7 | of the PWM to use and the second cell is the period in nanoseconds. | 7 | the cells format. |
8 | - fsl,pwm-number: the number of PWM devices | 8 | - fsl,pwm-number: the number of PWM devices |
9 | 9 | ||
10 | Example: | 10 | Example: |
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt index 01438ecd6628..c3fc57af8772 100644 --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | |||
@@ -5,9 +5,8 @@ Required properties: | |||
5 | - "nvidia,tegra20-pwm" | 5 | - "nvidia,tegra20-pwm" |
6 | - "nvidia,tegra30-pwm" | 6 | - "nvidia,tegra30-pwm" |
7 | - reg: physical base address and length of the controller's registers | 7 | - reg: physical base address and length of the controller's registers |
8 | - #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The | 8 | - #pwm-cells: should be 2. See pwm.txt in this directory for a description of |
9 | first cell specifies the per-chip index of the PWM to use and the second | 9 | the cells format. |
10 | cell is the period in nanoseconds. | ||
11 | 10 | ||
12 | Example: | 11 | Example: |
13 | 12 | ||
diff --git a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt index 1e3dfe7a4894..f84ec9d291ea 100644 --- a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt | |||
@@ -3,8 +3,8 @@ NXP PCA9685 16-channel 12-bit PWM LED controller | |||
3 | 3 | ||
4 | Required properties: | 4 | Required properties: |
5 | - compatible: "nxp,pca9685-pwm" | 5 | - compatible: "nxp,pca9685-pwm" |
6 | - #pwm-cells: should be 2. The first cell specifies the per-chip index | 6 | - #pwm-cells: Should be 2. See pwm.txt in this directory for a description of |
7 | of the PWM to use and the second cell is the period in nanoseconds. | 7 | the cells format. |
8 | The index 16 is the ALLCALL channel, that sets all PWM channels at the same | 8 | The index 16 is the ALLCALL channel, that sets all PWM channels at the same |
9 | time. | 9 | time. |
10 | 10 | ||
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt index ac67c687a327..4caa1a78863e 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt | |||
@@ -19,13 +19,9 @@ Required properties: | |||
19 | - reg: base address and size of register area | 19 | - reg: base address and size of register area |
20 | - interrupts: list of timer interrupts (one interrupt per timer, starting at | 20 | - interrupts: list of timer interrupts (one interrupt per timer, starting at |
21 | timer 0) | 21 | timer 0) |
22 | - #pwm-cells: number of cells used for PWM specifier - must be 3 | 22 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of |
23 | the specifier format is as follows: | 23 | the cells format. The only third cell flag supported by this binding is |
24 | - phandle to PWM controller node | 24 | PWM_POLARITY_INVERTED. |
25 | - index of PWM channel (from 0 to 4) | ||
26 | - PWM signal period in nanoseconds | ||
27 | - bitmask of optional PWM flags: | ||
28 | 0x1 - invert PWM signal | ||
29 | 25 | ||
30 | Optional properties: | 26 | Optional properties: |
31 | - samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular | 27 | - samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular |
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt index 681afad73778..fb81179dce37 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt | |||
@@ -4,11 +4,9 @@ Required properties: | |||
4 | - compatible: Must be "ti,<soc>-ecap". | 4 | - compatible: Must be "ti,<soc>-ecap". |
5 | for am33xx - compatible = "ti,am33xx-ecap"; | 5 | for am33xx - compatible = "ti,am33xx-ecap"; |
6 | for da850 - compatible = "ti,da850-ecap", "ti,am33xx-ecap"; | 6 | for da850 - compatible = "ti,da850-ecap", "ti,am33xx-ecap"; |
7 | - #pwm-cells: Should be 3. Number of cells being used to specify PWM property. | 7 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of |
8 | First cell specifies the per-chip index of the PWM to use, the second | 8 | the cells format. The PWM channel index ranges from 0 to 4. The only third |
9 | cell is the period in nanoseconds and bit 0 in the third cell is used to | 9 | cell flag supported by this binding is PWM_POLARITY_INVERTED. |
10 | encode the polarity of PWM output. Set bit 0 of the third in PWM specifier | ||
11 | to 1 for inverse polarity & set to 0 for normal polarity. | ||
12 | - reg: physical base address and size of the registers map. | 10 | - reg: physical base address and size of the registers map. |
13 | 11 | ||
14 | Optional properties: | 12 | Optional properties: |
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt index 337c6fc65d3f..9c100b2c5b23 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | |||
@@ -4,11 +4,9 @@ Required properties: | |||
4 | - compatible: Must be "ti,<soc>-ehrpwm". | 4 | - compatible: Must be "ti,<soc>-ehrpwm". |
5 | for am33xx - compatible = "ti,am33xx-ehrpwm"; | 5 | for am33xx - compatible = "ti,am33xx-ehrpwm"; |
6 | for da850 - compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm"; | 6 | for da850 - compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm"; |
7 | - #pwm-cells: Should be 3. Number of cells being used to specify PWM property. | 7 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of |
8 | First cell specifies the per-chip index of the PWM to use, the second | 8 | the cells format. The only third cell flag supported by this binding is |
9 | cell is the period in nanoseconds and bit 0 in the third cell is used to | 9 | PWM_POLARITY_INVERTED. |
10 | encode the polarity of PWM output. Set bit 0 of the third in PWM specifier | ||
11 | to 1 for inverse polarity & set to 0 for normal polarity. | ||
12 | - reg: physical base address and size of the registers map. | 10 | - reg: physical base address and size of the registers map. |
13 | 11 | ||
14 | Optional properties: | 12 | Optional properties: |
diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt b/Documentation/devicetree/bindings/pwm/pwm.txt index 06e67247859a..8556263b8502 100644 --- a/Documentation/devicetree/bindings/pwm/pwm.txt +++ b/Documentation/devicetree/bindings/pwm/pwm.txt | |||
@@ -43,13 +43,14 @@ because the name "backlight" would be used as fallback anyway. | |||
43 | pwm-specifier typically encodes the chip-relative PWM number and the PWM | 43 | pwm-specifier typically encodes the chip-relative PWM number and the PWM |
44 | period in nanoseconds. | 44 | period in nanoseconds. |
45 | 45 | ||
46 | Optionally, the pwm-specifier can encode a number of flags in a third cell: | 46 | Optionally, the pwm-specifier can encode a number of flags (defined in |
47 | - bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity) | 47 | <dt-bindings/pwm/pwm.h>) in a third cell: |
48 | - PWM_POLARITY_INVERTED: invert the PWM signal polarity | ||
48 | 49 | ||
49 | Example with optional PWM specifier for inverse polarity | 50 | Example with optional PWM specifier for inverse polarity |
50 | 51 | ||
51 | bl: backlight { | 52 | bl: backlight { |
52 | pwms = <&pwm 0 5000000 1>; | 53 | pwms = <&pwm 0 5000000 PWM_POLARITY_INVERTED>; |
53 | pwm-names = "backlight"; | 54 | pwm-names = "backlight"; |
54 | }; | 55 | }; |
55 | 56 | ||
diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt new file mode 100644 index 000000000000..b067e84a94b5 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | |||
@@ -0,0 +1,28 @@ | |||
1 | * Renesas R-Car Timer Pulse Unit PWM Controller | ||
2 | |||
3 | Required Properties: | ||
4 | |||
5 | - compatible: should be one of the following. | ||
6 | - "renesas,tpu-r8a73a4": for R8A77A4 (R-Mobile APE6) compatible PWM controller. | ||
7 | - "renesas,tpu-r8a7740": for R8A7740 (R-Mobile A1) compatible PWM controller. | ||
8 | - "renesas,tpu-r8a7790": for R8A7790 (R-Car H2) compatible PWM controller. | ||
9 | - "renesas,tpu-sh7372": for SH7372 (SH-Mobile AP4) compatible PWM controller. | ||
10 | - "renesas,tpu": for generic R-Car TPU PWM controller. | ||
11 | |||
12 | - reg: Base address and length of each memory resource used by the PWM | ||
13 | controller hardware module. | ||
14 | |||
15 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of | ||
16 | the cells format. The only third cell flag supported by this binding is | ||
17 | PWM_POLARITY_INVERTED. | ||
18 | |||
19 | Please refer to pwm.txt in this directory for details of the common PWM bindings | ||
20 | used by client devices. | ||
21 | |||
22 | Example: R8A7740 (R-Car A1) TPU controller node | ||
23 | |||
24 | tpu: pwm@e6600000 { | ||
25 | compatible = "renesas,tpu-r8a7740", "renesas,tpu"; | ||
26 | reg = <0xe6600000 0x100>; | ||
27 | #pwm-cells = <3>; | ||
28 | }; | ||
diff --git a/Documentation/devicetree/bindings/pwm/spear-pwm.txt b/Documentation/devicetree/bindings/pwm/spear-pwm.txt index 3ac779d83386..b486de2c3fe3 100644 --- a/Documentation/devicetree/bindings/pwm/spear-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/spear-pwm.txt | |||
@@ -5,9 +5,8 @@ Required properties: | |||
5 | - "st,spear320-pwm" | 5 | - "st,spear320-pwm" |
6 | - "st,spear1340-pwm" | 6 | - "st,spear1340-pwm" |
7 | - reg: physical base address and length of the controller's registers | 7 | - reg: physical base address and length of the controller's registers |
8 | - #pwm-cells: number of cells used to specify PWM which is fixed to 2 on | 8 | - #pwm-cells: should be 2. See pwm.txt in this directory for a description of |
9 | SPEAr. The first cell specifies the per-chip index of the PWM to use and | 9 | the cells format. |
10 | the second cell is the period in nanoseconds. | ||
11 | 10 | ||
12 | Example: | 11 | Example: |
13 | 12 | ||
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt index 2943ee5fce00..4e32bee11201 100644 --- a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt | |||
@@ -6,8 +6,8 @@ On TWL6030 series: PWM0 and PWM1 | |||
6 | 6 | ||
7 | Required properties: | 7 | Required properties: |
8 | - compatible: "ti,twl4030-pwm" or "ti,twl6030-pwm" | 8 | - compatible: "ti,twl4030-pwm" or "ti,twl6030-pwm" |
9 | - #pwm-cells: should be 2. The first cell specifies the per-chip index | 9 | - #pwm-cells: should be 2. See pwm.txt in this directory for a description of |
10 | of the PWM to use and the second cell is the period in nanoseconds. | 10 | the cells format. |
11 | 11 | ||
12 | Example: | 12 | Example: |
13 | 13 | ||
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt index cb64f3acc10f..9f4b46090782 100644 --- a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt +++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt | |||
@@ -6,8 +6,8 @@ On TWL6030 series: LED PWM (mainly used as charging indicator LED) | |||
6 | 6 | ||
7 | Required properties: | 7 | Required properties: |
8 | - compatible: "ti,twl4030-pwmled" or "ti,twl6030-pwmled" | 8 | - compatible: "ti,twl4030-pwmled" or "ti,twl6030-pwmled" |
9 | - #pwm-cells: should be 2. The first cell specifies the per-chip index | 9 | - #pwm-cells: should be 2. See pwm.txt in this directory for a description of |
10 | of the PWM to use and the second cell is the period in nanoseconds. | 10 | the cells format. |
11 | 11 | ||
12 | Example: | 12 | Example: |
13 | 13 | ||
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt index d21d82d29855..a76390e6df2e 100644 --- a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt | |||
@@ -3,11 +3,9 @@ VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller | |||
3 | Required properties: | 3 | Required properties: |
4 | - compatible: should be "via,vt8500-pwm" | 4 | - compatible: should be "via,vt8500-pwm" |
5 | - reg: physical base address and length of the controller's registers | 5 | - reg: physical base address and length of the controller's registers |
6 | - #pwm-cells: Should be 3. Number of cells being used to specify PWM property. | 6 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of |
7 | First cell specifies the per-chip index of the PWM to use, the second | 7 | the cells format. The only third cell flag supported by this binding is |
8 | cell is the period in nanoseconds and bit 0 in the third cell is used to | 8 | PWM_POLARITY_INVERTED. |
9 | encode the polarity of PWM output. Set bit 0 of the third in PWM specifier | ||
10 | to 1 for inverse polarity & set to 0 for normal polarity. | ||
11 | - clocks: phandle to the PWM source clock | 9 | - clocks: phandle to the PWM source clock |
12 | 10 | ||
13 | Example: | 11 | Example: |
diff --git a/Documentation/devicetree/bindings/regulator/88pm800.txt b/Documentation/devicetree/bindings/regulator/88pm800.txt new file mode 100644 index 000000000000..e8a54c2a5821 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/88pm800.txt | |||
@@ -0,0 +1,38 @@ | |||
1 | Marvell 88PM800 regulator | ||
2 | |||
3 | Required properties: | ||
4 | - compatible: "marvell,88pm800" | ||
5 | - reg: I2C slave address | ||
6 | - regulators: A node that houses a sub-node for each regulator within the | ||
7 | device. Each sub-node is identified using the node's name (or the deprecated | ||
8 | regulator-compatible property if present), with valid values listed below. | ||
9 | The content of each sub-node is defined by the standard binding for | ||
10 | regulators; see regulator.txt. | ||
11 | |||
12 | The valid names for regulators are: | ||
13 | |||
14 | buck1, buck2, buck3, buck4, buck5, ldo1, ldo2, ldo3, ldo4, ldo5, ldo6, ldo7, | ||
15 | ldo8, ldo9, ldo10, ldo11, ldo12, ldo13, ldo14, ldo15, ldo16, ldo17, ldo18, ldo19 | ||
16 | |||
17 | Example: | ||
18 | |||
19 | pmic: 88pm800@31 { | ||
20 | compatible = "marvell,88pm800"; | ||
21 | reg = <0x31>; | ||
22 | |||
23 | regulators { | ||
24 | buck1 { | ||
25 | regulator-min-microvolt = <600000>; | ||
26 | regulator-max-microvolt = <3950000>; | ||
27 | regulator-boot-on; | ||
28 | regulator-always-on; | ||
29 | }; | ||
30 | ldo1 { | ||
31 | regulator-min-microvolt = <600000>; | ||
32 | regulator-max-microvolt = <15000000>; | ||
33 | regulator-boot-on; | ||
34 | regulator-always-on; | ||
35 | }; | ||
36 | ... | ||
37 | }; | ||
38 | }; | ||
diff --git a/Documentation/devicetree/bindings/regulator/max8660.txt b/Documentation/devicetree/bindings/regulator/max8660.txt new file mode 100644 index 000000000000..8ba994d8a142 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max8660.txt | |||
@@ -0,0 +1,47 @@ | |||
1 | Maxim MAX8660 voltage regulator | ||
2 | |||
3 | Required properties: | ||
4 | - compatible: must be one of "maxim,max8660", "maxim,max8661" | ||
5 | - reg: I2C slave address, usually 0x34 | ||
6 | - any required generic properties defined in regulator.txt | ||
7 | |||
8 | Example: | ||
9 | |||
10 | i2c_master { | ||
11 | max8660@34 { | ||
12 | compatible = "maxim,max8660"; | ||
13 | reg = <0x34>; | ||
14 | |||
15 | regulators { | ||
16 | regulator@0 { | ||
17 | regulator-compatible= "V3(DCDC)"; | ||
18 | regulator-min-microvolt = <725000>; | ||
19 | regulator-max-microvolt = <1800000>; | ||
20 | }; | ||
21 | |||
22 | regulator@1 { | ||
23 | regulator-compatible= "V4(DCDC)"; | ||
24 | regulator-min-microvolt = <725000>; | ||
25 | regulator-max-microvolt = <1800000>; | ||
26 | }; | ||
27 | |||
28 | regulator@2 { | ||
29 | regulator-compatible= "V5(LDO)"; | ||
30 | regulator-min-microvolt = <1700000>; | ||
31 | regulator-max-microvolt = <2000000>; | ||
32 | }; | ||
33 | |||
34 | regulator@3 { | ||
35 | regulator-compatible= "V6(LDO)"; | ||
36 | regulator-min-microvolt = <1800000>; | ||
37 | regulator-max-microvolt = <3300000>; | ||
38 | }; | ||
39 | |||
40 | regulator@4 { | ||
41 | regulator-compatible= "V7(LDO)"; | ||
42 | regulator-min-microvolt = <1800000>; | ||
43 | regulator-max-microvolt = <3300000>; | ||
44 | }; | ||
45 | }; | ||
46 | }; | ||
47 | }; | ||
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index 30b0581bb1ce..a22e4c70db5c 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt | |||
@@ -25,8 +25,8 @@ Optional nodes: | |||
25 | Additional custom properties are listed below. | 25 | Additional custom properties are listed below. |
26 | 26 | ||
27 | For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP, | 27 | For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP, |
28 | smps45, smps457, smps7 depending on variant, smps6, smps[8-10], | 28 | smps45, smps457, smps7 depending on variant, smps6, smps[8-9], |
29 | ldo[1-9], ldoln, ldousb. | 29 | smps10_out2, smps10_out1, do[1-9], ldoln, ldousb. |
30 | 30 | ||
31 | Optional sub-node properties: | 31 | Optional sub-node properties: |
32 | ti,warm-reset - maintain voltage during warm reset(boolean) | 32 | ti,warm-reset - maintain voltage during warm reset(boolean) |
diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt b/Documentation/devicetree/bindings/regulator/pfuze100.txt new file mode 100644 index 000000000000..fc989b2e8057 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt | |||
@@ -0,0 +1,115 @@ | |||
1 | PFUZE100 family of regulators | ||
2 | |||
3 | Required properties: | ||
4 | - compatible: "fsl,pfuze100" | ||
5 | - reg: I2C slave address | ||
6 | |||
7 | Required child node: | ||
8 | - regulators: This is the list of child nodes that specify the regulator | ||
9 | initialization data for defined regulators. Please refer to below doc | ||
10 | Documentation/devicetree/bindings/regulator/regulator.txt. | ||
11 | |||
12 | The valid names for regulators are: | ||
13 | sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6 | ||
14 | |||
15 | Each regulator is defined using the standard binding for regulators. | ||
16 | |||
17 | Example: | ||
18 | |||
19 | pmic: pfuze100@08 { | ||
20 | compatible = "fsl,pfuze100"; | ||
21 | reg = <0x08>; | ||
22 | |||
23 | regulators { | ||
24 | sw1a_reg: sw1ab { | ||
25 | regulator-min-microvolt = <300000>; | ||
26 | regulator-max-microvolt = <1875000>; | ||
27 | regulator-boot-on; | ||
28 | regulator-always-on; | ||
29 | regulator-ramp-delay = <6250>; | ||
30 | }; | ||
31 | |||
32 | sw1c_reg: sw1c { | ||
33 | regulator-min-microvolt = <300000>; | ||
34 | regulator-max-microvolt = <1875000>; | ||
35 | regulator-boot-on; | ||
36 | regulator-always-on; | ||
37 | }; | ||
38 | |||
39 | sw2_reg: sw2 { | ||
40 | regulator-min-microvolt = <800000>; | ||
41 | regulator-max-microvolt = <3300000>; | ||
42 | regulator-boot-on; | ||
43 | regulator-always-on; | ||
44 | }; | ||
45 | |||
46 | sw3a_reg: sw3a { | ||
47 | regulator-min-microvolt = <400000>; | ||
48 | regulator-max-microvolt = <1975000>; | ||
49 | regulator-boot-on; | ||
50 | regulator-always-on; | ||
51 | }; | ||
52 | |||
53 | sw3b_reg: sw3b { | ||
54 | regulator-min-microvolt = <400000>; | ||
55 | regulator-max-microvolt = <1975000>; | ||
56 | regulator-boot-on; | ||
57 | regulator-always-on; | ||
58 | }; | ||
59 | |||
60 | sw4_reg: sw4 { | ||
61 | regulator-min-microvolt = <800000>; | ||
62 | regulator-max-microvolt = <3300000>; | ||
63 | }; | ||
64 | |||
65 | swbst_reg: swbst { | ||
66 | regulator-min-microvolt = <5000000>; | ||
67 | regulator-max-microvolt = <5150000>; | ||
68 | }; | ||
69 | |||
70 | snvs_reg: vsnvs { | ||
71 | regulator-min-microvolt = <1000000>; | ||
72 | regulator-max-microvolt = <3000000>; | ||
73 | regulator-boot-on; | ||
74 | regulator-always-on; | ||
75 | }; | ||
76 | |||
77 | vref_reg: vrefddr { | ||
78 | regulator-boot-on; | ||
79 | regulator-always-on; | ||
80 | }; | ||
81 | |||
82 | vgen1_reg: vgen1 { | ||
83 | regulator-min-microvolt = <800000>; | ||
84 | regulator-max-microvolt = <1550000>; | ||
85 | }; | ||
86 | |||
87 | vgen2_reg: vgen2 { | ||
88 | regulator-min-microvolt = <800000>; | ||
89 | regulator-max-microvolt = <1550000>; | ||
90 | }; | ||
91 | |||
92 | vgen3_reg: vgen3 { | ||
93 | regulator-min-microvolt = <1800000>; | ||
94 | regulator-max-microvolt = <3300000>; | ||
95 | }; | ||
96 | |||
97 | vgen4_reg: vgen4 { | ||
98 | regulator-min-microvolt = <1800000>; | ||
99 | regulator-max-microvolt = <3300000>; | ||
100 | regulator-always-on; | ||
101 | }; | ||
102 | |||
103 | vgen5_reg: vgen5 { | ||
104 | regulator-min-microvolt = <1800000>; | ||
105 | regulator-max-microvolt = <3300000>; | ||
106 | regulator-always-on; | ||
107 | }; | ||
108 | |||
109 | vgen6_reg: vgen6 { | ||
110 | regulator-min-microvolt = <1800000>; | ||
111 | regulator-max-microvolt = <3300000>; | ||
112 | regulator-always-on; | ||
113 | }; | ||
114 | }; | ||
115 | }; | ||
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index 48a3b8e5d6bd..2bd8f0978765 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt | |||
@@ -12,6 +12,8 @@ Optional properties: | |||
12 | - regulator-allow-bypass: allow the regulator to go into bypass mode | 12 | - regulator-allow-bypass: allow the regulator to go into bypass mode |
13 | - <name>-supply: phandle to the parent supply/regulator node | 13 | - <name>-supply: phandle to the parent supply/regulator node |
14 | - regulator-ramp-delay: ramp delay for regulator(in uV/uS) | 14 | - regulator-ramp-delay: ramp delay for regulator(in uV/uS) |
15 | For hardwares which support disabling ramp rate, it should be explicitly | ||
16 | intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay. | ||
15 | 17 | ||
16 | Deprecated properties: | 18 | Deprecated properties: |
17 | - regulator-compatible: If a regulator chip contains multiple | 19 | - regulator-compatible: If a regulator chip contains multiple |
diff --git a/Documentation/devicetree/bindings/tty/serial/arc-uart.txt b/Documentation/devicetree/bindings/serial/arc-uart.txt index 5cae2eb686f8..5cae2eb686f8 100644 --- a/Documentation/devicetree/bindings/tty/serial/arc-uart.txt +++ b/Documentation/devicetree/bindings/serial/arc-uart.txt | |||
diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt index a49d9a1d4ccf..2191dcb9f1da 100644 --- a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt +++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt | |||
@@ -10,13 +10,18 @@ Required properties: | |||
10 | Optional properties: | 10 | Optional properties: |
11 | - atmel,use-dma-rx: use of PDC or DMA for receiving data | 11 | - atmel,use-dma-rx: use of PDC or DMA for receiving data |
12 | - atmel,use-dma-tx: use of PDC or DMA for transmitting data | 12 | - atmel,use-dma-tx: use of PDC or DMA for transmitting data |
13 | - add dma bindings for dma transfer: | ||
14 | - dmas: DMA specifier, consisting of a phandle to DMA controller node, | ||
15 | memory peripheral interface and USART DMA channel ID, FIFO configuration. | ||
16 | Refer to dma.txt and atmel-dma.txt for details. | ||
17 | - dma-names: "rx" for RX channel, "tx" for TX channel. | ||
13 | 18 | ||
14 | <chip> compatible description: | 19 | <chip> compatible description: |
15 | - at91rm9200: legacy USART support | 20 | - at91rm9200: legacy USART support |
16 | - at91sam9260: generic USART implementation for SAM9 SoCs | 21 | - at91sam9260: generic USART implementation for SAM9 SoCs |
17 | 22 | ||
18 | Example: | 23 | Example: |
19 | 24 | - use PDC: | |
20 | usart0: serial@fff8c000 { | 25 | usart0: serial@fff8c000 { |
21 | compatible = "atmel,at91sam9260-usart"; | 26 | compatible = "atmel,at91sam9260-usart"; |
22 | reg = <0xfff8c000 0x4000>; | 27 | reg = <0xfff8c000 0x4000>; |
@@ -25,3 +30,14 @@ Example: | |||
25 | atmel,use-dma-tx; | 30 | atmel,use-dma-tx; |
26 | }; | 31 | }; |
27 | 32 | ||
33 | - use DMA: | ||
34 | usart0: serial@f001c000 { | ||
35 | compatible = "atmel,at91sam9260-usart"; | ||
36 | reg = <0xf001c000 0x100>; | ||
37 | interrupts = <12 4 5>; | ||
38 | atmel,use-dma-rx; | ||
39 | atmel,use-dma-tx; | ||
40 | dmas = <&dma0 2 0x3>, | ||
41 | <&dma0 2 0x204>; | ||
42 | dma-names = "tx", "rx"; | ||
43 | }; | ||
diff --git a/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt b/Documentation/devicetree/bindings/serial/efm32-uart.txt index 8e080b893b49..8e080b893b49 100644 --- a/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt +++ b/Documentation/devicetree/bindings/serial/efm32-uart.txt | |||
diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt index c58573b5b1a4..35ae1fb3537f 100644 --- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt +++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | |||
@@ -1,35 +1,29 @@ | |||
1 | * Freescale i.MX UART controller | 1 | * Freescale i.MX Universal Asynchronous Receiver/Transmitter (UART) |
2 | 2 | ||
3 | Required properties: | 3 | Required properties: |
4 | - compatible : should be "fsl,imx21-uart" | 4 | - compatible : Should be "fsl,<soc>-uart" |
5 | - reg : Address and length of the register set for the device | 5 | - reg : Address and length of the register set for the device |
6 | - interrupts : Should contain UART interrupt number | 6 | - interrupts : Should contain uart interrupt |
7 | 7 | ||
8 | Optional properties: | 8 | Optional properties: |
9 | - fsl,uart-has-rtscts: indicate that RTS/CTS signals are used | 9 | - fsl,uart-has-rtscts : Indicate the uart has rts and cts |
10 | - fsl,irda-mode : Indicate the uart supports irda mode | ||
11 | - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works | ||
12 | is DCE mode by default. | ||
10 | 13 | ||
11 | Note: Each uart controller should have an alias correctly numbered | 14 | Note: Each uart controller should have an alias correctly numbered |
12 | in "aliases" node. | 15 | in "aliases" node. |
13 | 16 | ||
14 | Example: | 17 | Example: |
15 | 18 | ||
16 | - From imx51.dtsi: | ||
17 | aliases { | 19 | aliases { |
18 | serial0 = &uart1; | 20 | serial0 = &uart1; |
19 | serial1 = &uart2; | ||
20 | serial2 = &uart3; | ||
21 | }; | 21 | }; |
22 | 22 | ||
23 | uart1: serial@73fbc000 { | 23 | uart1: serial@73fbc000 { |
24 | compatible = "fsl,imx51-uart", "fsl,imx21-uart"; | 24 | compatible = "fsl,imx51-uart", "fsl,imx21-uart"; |
25 | reg = <0x73fbc000 0x4000>; | 25 | reg = <0x73fbc000 0x4000>; |
26 | interrupts = <31>; | 26 | interrupts = <31>; |
27 | status = "disabled"; | ||
28 | } | ||
29 | |||
30 | - From imx51-babbage.dts: | ||
31 | uart1: serial@73fbc000 { | ||
32 | fsl,uart-has-rtscts; | 27 | fsl,uart-has-rtscts; |
33 | status = "okay"; | 28 | fsl,dte-mode; |
34 | }; | 29 | }; |
35 | |||
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt index 6fd1dd1638dd..6fd1dd1638dd 100644 --- a/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt | |||
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/serial/fsl-mxs-auart.txt index 2c00ec64628e..59a40f18d551 100644 --- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt +++ b/Documentation/devicetree/bindings/serial/fsl-mxs-auart.txt | |||
@@ -10,6 +10,10 @@ Required properties: | |||
10 | Refer to dma.txt and fsl-mxs-dma.txt for details. | 10 | Refer to dma.txt and fsl-mxs-dma.txt for details. |
11 | - dma-names: "rx" for RX channel, "tx" for TX channel. | 11 | - dma-names: "rx" for RX channel, "tx" for TX channel. |
12 | 12 | ||
13 | Optional properties: | ||
14 | - fsl,uart-has-rtscts : Indicate the UART has RTS and CTS lines, | ||
15 | it also means you enable the DMA support for this UART. | ||
16 | |||
13 | Example: | 17 | Example: |
14 | auart0: serial@8006a000 { | 18 | auart0: serial@8006a000 { |
15 | compatible = "fsl,imx28-auart", "fsl,imx23-auart"; | 19 | compatible = "fsl,imx28-auart", "fsl,imx23-auart"; |
diff --git a/Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt b/Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt new file mode 100644 index 000000000000..669b8140dd79 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt | |||
@@ -0,0 +1,65 @@ | |||
1 | Device tree bindings for Marvell PXA SSP ports | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | - compatible: Must be one of | ||
6 | mrvl,pxa25x-ssp | ||
7 | mvrl,pxa25x-nssp | ||
8 | mrvl,pxa27x-ssp | ||
9 | mrvl,pxa3xx-ssp | ||
10 | mvrl,pxa168-ssp | ||
11 | mrvl,pxa910-ssp | ||
12 | mrvl,ce4100-ssp | ||
13 | mrvl,lpss-ssp | ||
14 | |||
15 | - reg: The memory base | ||
16 | - dmas: Two dma phandles, one for rx, one for tx | ||
17 | - dma-names: Must be "rx", "tx" | ||
18 | |||
19 | |||
20 | Example for PXA3xx: | ||
21 | |||
22 | ssp0: ssp@41000000 { | ||
23 | compatible = "mrvl,pxa3xx-ssp"; | ||
24 | reg = <0x41000000 0x40>; | ||
25 | ssp-id = <1>; | ||
26 | interrupts = <24>; | ||
27 | clock-names = "pxa27x-ssp.0"; | ||
28 | dmas = <&dma 13 | ||
29 | &dma 14>; | ||
30 | dma-names = "rx", "tx"; | ||
31 | }; | ||
32 | |||
33 | ssp1: ssp@41700000 { | ||
34 | compatible = "mrvl,pxa3xx-ssp"; | ||
35 | reg = <0x41700000 0x40>; | ||
36 | ssp-id = <2>; | ||
37 | interrupts = <16>; | ||
38 | clock-names = "pxa27x-ssp.1"; | ||
39 | dmas = <&dma 15 | ||
40 | &dma 16>; | ||
41 | dma-names = "rx", "tx"; | ||
42 | }; | ||
43 | |||
44 | ssp2: ssp@41900000 { | ||
45 | compatibl3 = "mrvl,pxa3xx-ssp"; | ||
46 | reg = <0x41900000 0x40>; | ||
47 | ssp-id = <3>; | ||
48 | interrupts = <0>; | ||
49 | clock-names = "pxa27x-ssp.2"; | ||
50 | dmas = <&dma 66 | ||
51 | &dma 67>; | ||
52 | dma-names = "rx", "tx"; | ||
53 | }; | ||
54 | |||
55 | ssp3: ssp@41a00000 { | ||
56 | compatible = "mrvl,pxa3xx-ssp"; | ||
57 | reg = <0x41a00000 0x40>; | ||
58 | ssp-id = <4>; | ||
59 | interrupts = <13>; | ||
60 | clock-names = "pxa27x-ssp.3"; | ||
61 | dmas = <&dma 2 | ||
62 | &dma 3>; | ||
63 | dma-names = "rx", "tx"; | ||
64 | }; | ||
65 | |||
diff --git a/Documentation/devicetree/bindings/tty/serial/nxp-lpc32xx-hsuart.txt b/Documentation/devicetree/bindings/serial/nxp-lpc32xx-hsuart.txt index 0d439dfc1aa5..0d439dfc1aa5 100644 --- a/Documentation/devicetree/bindings/tty/serial/nxp-lpc32xx-hsuart.txt +++ b/Documentation/devicetree/bindings/serial/nxp-lpc32xx-hsuart.txt | |||
diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt b/Documentation/devicetree/bindings/serial/of-serial.txt index 1928a3e83cd0..1928a3e83cd0 100644 --- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt +++ b/Documentation/devicetree/bindings/serial/of-serial.txt | |||
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uart.txt b/Documentation/devicetree/bindings/serial/qcom,msm-uart.txt new file mode 100644 index 000000000000..ce8c90161959 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/qcom,msm-uart.txt | |||
@@ -0,0 +1,25 @@ | |||
1 | * MSM Serial UART | ||
2 | |||
3 | The MSM serial UART hardware is designed for low-speed use cases where a | ||
4 | dma-engine isn't needed. From a software perspective it's mostly compatible | ||
5 | with the MSM serial UARTDM except that it only supports reading and writing one | ||
6 | character at a time. | ||
7 | |||
8 | Required properties: | ||
9 | - compatible: Should contain "qcom,msm-uart" | ||
10 | - reg: Should contain UART register location and length. | ||
11 | - interrupts: Should contain UART interrupt. | ||
12 | - clocks: Should contain the core clock. | ||
13 | - clock-names: Should be "core". | ||
14 | |||
15 | Example: | ||
16 | |||
17 | A uart device at 0xa9c00000 with interrupt 11. | ||
18 | |||
19 | serial@a9c00000 { | ||
20 | compatible = "qcom,msm-uart"; | ||
21 | reg = <0xa9c00000 0x1000>; | ||
22 | interrupts = <11>; | ||
23 | clocks = <&uart_cxc>; | ||
24 | clock-names = "core"; | ||
25 | }; | ||
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt new file mode 100644 index 000000000000..ffa5b784c66e --- /dev/null +++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt | |||
@@ -0,0 +1,53 @@ | |||
1 | * MSM Serial UARTDM | ||
2 | |||
3 | The MSM serial UARTDM hardware is designed for high-speed use cases where the | ||
4 | transmit and/or receive channels can be offloaded to a dma-engine. From a | ||
5 | software perspective it's mostly compatible with the MSM serial UART except | ||
6 | that it supports reading and writing multiple characters at a time. | ||
7 | |||
8 | Required properties: | ||
9 | - compatible: Should contain at least "qcom,msm-uartdm". | ||
10 | A more specific property should be specified as follows depending | ||
11 | on the version: | ||
12 | "qcom,msm-uartdm-v1.1" | ||
13 | "qcom,msm-uartdm-v1.2" | ||
14 | "qcom,msm-uartdm-v1.3" | ||
15 | "qcom,msm-uartdm-v1.4" | ||
16 | - reg: Should contain UART register locations and lengths. The first | ||
17 | register shall specify the main control registers. An optional second | ||
18 | register location shall specify the GSBI control region. | ||
19 | "qcom,msm-uartdm-v1.3" is the only compatible value that might | ||
20 | need the GSBI control region. | ||
21 | - interrupts: Should contain UART interrupt. | ||
22 | - clocks: Should contain the core clock and the AHB clock. | ||
23 | - clock-names: Should be "core" for the core clock and "iface" for the | ||
24 | AHB clock. | ||
25 | |||
26 | Optional properties: | ||
27 | - dmas: Should contain dma specifiers for transmit and receive channels | ||
28 | - dma-names: Should contain "tx" for transmit and "rx" for receive channels | ||
29 | |||
30 | Examples: | ||
31 | |||
32 | A uartdm v1.4 device with dma capabilities. | ||
33 | |||
34 | serial@f991e000 { | ||
35 | compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm"; | ||
36 | reg = <0xf991e000 0x1000>; | ||
37 | interrupts = <0 108 0x0>; | ||
38 | clocks = <&blsp1_uart2_apps_cxc>, <&blsp1_ahb_cxc>; | ||
39 | clock-names = "core", "iface"; | ||
40 | dmas = <&dma0 0>, <&dma0 1>; | ||
41 | dma-names = "tx", "rx"; | ||
42 | }; | ||
43 | |||
44 | A uartdm v1.3 device without dma capabilities and part of a GSBI complex. | ||
45 | |||
46 | serial@19c40000 { | ||
47 | compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; | ||
48 | reg = <0x19c40000 0x1000>, | ||
49 | <0x19c00000 0x1000>; | ||
50 | interrupts = <0 195 0x0>; | ||
51 | clocks = <&gsbi5_uart_cxc>, <&gsbi5_ahb_cxc>; | ||
52 | clock-names = "core", "iface"; | ||
53 | }; | ||
diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt index 1e753c69fc83..32b1fa1f2a5b 100644 --- a/Documentation/devicetree/bindings/serial/rs485.txt +++ b/Documentation/devicetree/bindings/serial/rs485.txt | |||
@@ -7,7 +7,7 @@ UART node. | |||
7 | 7 | ||
8 | Required properties: | 8 | Required properties: |
9 | - rs485-rts-delay: prop-encoded-array <a b> where: | 9 | - rs485-rts-delay: prop-encoded-array <a b> where: |
10 | * a is the delay beteween rts signal and beginning of data sent in milliseconds. | 10 | * a is the delay between rts signal and beginning of data sent in milliseconds. |
11 | it corresponds to the delay before sending data. | 11 | it corresponds to the delay before sending data. |
12 | * b is the delay between end of data sent and rts signal in milliseconds | 12 | * b is the delay between end of data sent and rts signal in milliseconds |
13 | it corresponds to the delay after sending data and actual release of the line. | 13 | it corresponds to the delay after sending data and actual release of the line. |
diff --git a/Documentation/devicetree/bindings/serial/sirf-uart.txt b/Documentation/devicetree/bindings/serial/sirf-uart.txt new file mode 100644 index 000000000000..a2dfc6522a91 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/sirf-uart.txt | |||
@@ -0,0 +1,33 @@ | |||
1 | * CSR SiRFprimaII/atlasVI Universal Synchronous Asynchronous Receiver/Transmitter * | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : Should be "sirf,prima2-uart" or "sirf, prima2-usp-uart" | ||
5 | - reg : Offset and length of the register set for the device | ||
6 | - interrupts : Should contain uart interrupt | ||
7 | - fifosize : Should define hardware rx/tx fifo size | ||
8 | - clocks : Should contain uart clock number | ||
9 | |||
10 | Optional properties: | ||
11 | - sirf,uart-has-rtscts: we have hardware flow controller pins in hardware | ||
12 | - rts-gpios: RTS pin for USP-based UART if sirf,uart-has-rtscts is true | ||
13 | - cts-gpios: CTS pin for USP-based UART if sirf,uart-has-rtscts is true | ||
14 | |||
15 | Example: | ||
16 | |||
17 | uart0: uart@b0050000 { | ||
18 | cell-index = <0>; | ||
19 | compatible = "sirf,prima2-uart"; | ||
20 | reg = <0xb0050000 0x1000>; | ||
21 | interrupts = <17>; | ||
22 | fifosize = <128>; | ||
23 | clocks = <&clks 13>; | ||
24 | }; | ||
25 | |||
26 | On the board-specific dts, we can put rts-gpios and cts-gpios like | ||
27 | |||
28 | usp@b0090000 { | ||
29 | compatible = "sirf,prima2-usp-uart"; | ||
30 | sirf,uart-has-rtscts; | ||
31 | rts-gpios = <&gpio 15 0>; | ||
32 | cts-gpios = <&gpio 46 0>; | ||
33 | }; | ||
diff --git a/Documentation/devicetree/bindings/tty/serial/snps-dw-apb-uart.txt b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt index f13f1c5be91c..f13f1c5be91c 100644 --- a/Documentation/devicetree/bindings/tty/serial/snps-dw-apb-uart.txt +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt | |||
diff --git a/Documentation/devicetree/bindings/serial/st-asc.txt b/Documentation/devicetree/bindings/serial/st-asc.txt new file mode 100644 index 000000000000..75d877f5968f --- /dev/null +++ b/Documentation/devicetree/bindings/serial/st-asc.txt | |||
@@ -0,0 +1,18 @@ | |||
1 | *st-asc(Serial Port) | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : Should be "st,asc". | ||
5 | - reg, reg-names, interrupts, interrupt-names : Standard way to define device | ||
6 | resources with names. look in | ||
7 | Documentation/devicetree/bindings/resource-names.txt | ||
8 | |||
9 | Optional properties: | ||
10 | - st,hw-flow-ctrl bool flag to enable hardware flow control. | ||
11 | - st,force-m1 bool flat to force asc to be in Mode-1 recommeded | ||
12 | for high bit rates (above 19.2K) | ||
13 | Example: | ||
14 | serial@fe440000{ | ||
15 | compatible = "st,asc"; | ||
16 | reg = <0xfe440000 0x2c>; | ||
17 | interrupts = <0 209 0>; | ||
18 | }; | ||
diff --git a/Documentation/devicetree/bindings/tty/serial/via,vt8500-uart.txt b/Documentation/devicetree/bindings/serial/via,vt8500-uart.txt index 5feef1ef167d..5feef1ef167d 100644 --- a/Documentation/devicetree/bindings/tty/serial/via,vt8500-uart.txt +++ b/Documentation/devicetree/bindings/serial/via,vt8500-uart.txt | |||
diff --git a/Documentation/devicetree/bindings/sound/ak4554.c b/Documentation/devicetree/bindings/sound/ak4554.c new file mode 100644 index 000000000000..934fa02754b3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ak4554.c | |||
@@ -0,0 +1,11 @@ | |||
1 | AK4554 ADC/DAC | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | - compatible : "asahi-kasei,ak4554" | ||
6 | |||
7 | Example: | ||
8 | |||
9 | ak4554-adc-dac { | ||
10 | compatible = "asahi-kasei,ak4554"; | ||
11 | }; | ||
diff --git a/Documentation/devicetree/bindings/sound/alc5632.txt b/Documentation/devicetree/bindings/sound/alc5632.txt index 8608f747dcfe..ffd886d110bd 100644 --- a/Documentation/devicetree/bindings/sound/alc5632.txt +++ b/Documentation/devicetree/bindings/sound/alc5632.txt | |||
@@ -13,6 +13,25 @@ Required properties: | |||
13 | - #gpio-cells : Should be two. The first cell is the pin number and the | 13 | - #gpio-cells : Should be two. The first cell is the pin number and the |
14 | second cell is used to specify optional parameters (currently unused). | 14 | second cell is used to specify optional parameters (currently unused). |
15 | 15 | ||
16 | Pins on the device (for linking into audio routes): | ||
17 | |||
18 | * SPK_OUTP | ||
19 | * SPK_OUTN | ||
20 | * HP_OUT_L | ||
21 | * HP_OUT_R | ||
22 | * AUX_OUT_P | ||
23 | * AUX_OUT_N | ||
24 | * LINE_IN_L | ||
25 | * LINE_IN_R | ||
26 | * PHONE_P | ||
27 | * PHONE_N | ||
28 | * MIC1_P | ||
29 | * MIC1_N | ||
30 | * MIC2_P | ||
31 | * MIC2_N | ||
32 | * MICBIAS1 | ||
33 | * DMICDAT | ||
34 | |||
16 | Example: | 35 | Example: |
17 | 36 | ||
18 | alc5632: alc5632@1e { | 37 | alc5632: alc5632@1e { |
diff --git a/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt new file mode 100644 index 000000000000..0720857089a7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel-sam9x5-wm8731-audio.txt | |||
@@ -0,0 +1,35 @@ | |||
1 | * Atmel at91sam9x5ek wm8731 audio complex | ||
2 | |||
3 | Required properties: | ||
4 | - compatible: "atmel,sam9x5-wm8731-audio" | ||
5 | - atmel,model: The user-visible name of this sound complex. | ||
6 | - atmel,ssc-controller: The phandle of the SSC controller | ||
7 | - atmel,audio-codec: The phandle of the WM8731 audio codec | ||
8 | - atmel,audio-routing: A list of the connections between audio components. | ||
9 | Each entry is a pair of strings, the first being the connection's sink, | ||
10 | the second being the connection's source. | ||
11 | |||
12 | Available audio endpoints for the audio-routing table: | ||
13 | |||
14 | Board connectors: | ||
15 | * Headphone Jack | ||
16 | * Line In Jack | ||
17 | |||
18 | wm8731 pins: | ||
19 | cf Documentation/devicetree/bindings/sound/wm8731.txt | ||
20 | |||
21 | Example: | ||
22 | sound { | ||
23 | compatible = "atmel,sam9x5-wm8731-audio"; | ||
24 | |||
25 | atmel,model = "wm8731 @ AT91SAM9X5EK"; | ||
26 | |||
27 | atmel,audio-routing = | ||
28 | "Headphone Jack", "RHPOUT", | ||
29 | "Headphone Jack", "LHPOUT", | ||
30 | "LLINEIN", "Line In Jack", | ||
31 | "RLINEIN", "Line In Jack"; | ||
32 | |||
33 | atmel,ssc-controller = <&ssc0>; | ||
34 | atmel,audio-codec = <&wm8731>; | ||
35 | }; | ||
diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt new file mode 100644 index 000000000000..8bbe50c884b6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt | |||
@@ -0,0 +1,55 @@ | |||
1 | Atmel ASoC driver with wm8904 audio codec complex | ||
2 | |||
3 | Required properties: | ||
4 | - compatible: "atmel,asoc-wm8904" | ||
5 | - atmel,model: The user-visible name of this sound complex. | ||
6 | - atmel,audio-routing: A list of the connections between audio components. | ||
7 | Each entry is a pair of strings, the first being the connection's sink, | ||
8 | the second being the connection's source. Valid names for sources and | ||
9 | sinks are the WM8904's pins, and the jacks on the board: | ||
10 | |||
11 | WM8904 pins: | ||
12 | |||
13 | * IN1L | ||
14 | * IN1R | ||
15 | * IN2L | ||
16 | * IN2R | ||
17 | * IN3L | ||
18 | * IN3R | ||
19 | * HPOUTL | ||
20 | * HPOUTR | ||
21 | * LINEOUTL | ||
22 | * LINEOUTR | ||
23 | * MICBIAS | ||
24 | |||
25 | Board connectors: | ||
26 | |||
27 | * Headphone Jack | ||
28 | * Line In Jack | ||
29 | * Mic | ||
30 | |||
31 | - atmel,ssc-controller: The phandle of the SSC controller | ||
32 | - atmel,audio-codec: The phandle of the WM8904 audio codec | ||
33 | |||
34 | Optional properties: | ||
35 | - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt | ||
36 | |||
37 | Example: | ||
38 | sound { | ||
39 | compatible = "atmel,asoc-wm8904"; | ||
40 | pinctrl-names = "default"; | ||
41 | pinctrl-0 = <&pinctrl_pck0_as_mck>; | ||
42 | |||
43 | atmel,model = "wm8904 @ AT91SAM9N12EK"; | ||
44 | |||
45 | atmel,audio-routing = | ||
46 | "Headphone Jack", "HPOUTL", | ||
47 | "Headphone Jack", "HPOUTR", | ||
48 | "IN2L", "Line In Jack", | ||
49 | "IN2R", "Line In Jack", | ||
50 | "Mic", "MICBIAS", | ||
51 | "IN1L", "Mic"; | ||
52 | |||
53 | atmel,ssc-controller = <&ssc0>; | ||
54 | atmel,audio-codec = <&wm8904>; | ||
55 | }; | ||
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt b/Documentation/devicetree/bindings/sound/fsl,spdif.txt new file mode 100644 index 000000000000..f2ae335670f5 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt | |||
@@ -0,0 +1,54 @@ | |||
1 | Freescale Sony/Philips Digital Interface Format (S/PDIF) Controller | ||
2 | |||
3 | The Freescale S/PDIF audio block is a stereo transceiver that allows the | ||
4 | processor to receive and transmit digital audio via an coaxial cable or | ||
5 | a fibre cable. | ||
6 | |||
7 | Required properties: | ||
8 | |||
9 | - compatible : Compatible list, must contain "fsl,imx35-spdif". | ||
10 | |||
11 | - reg : Offset and length of the register set for the device. | ||
12 | |||
13 | - interrupts : Contains the spdif interrupt. | ||
14 | |||
15 | - dmas : Generic dma devicetree binding as described in | ||
16 | Documentation/devicetree/bindings/dma/dma.txt. | ||
17 | |||
18 | - dma-names : Two dmas have to be defined, "tx" and "rx". | ||
19 | |||
20 | - clocks : Contains an entry for each entry in clock-names. | ||
21 | |||
22 | - clock-names : Includes the following entries: | ||
23 | "core" The core clock of spdif controller | ||
24 | "rxtx<0-7>" Clock source list for tx and rx clock. | ||
25 | This clock list should be identical to | ||
26 | the source list connecting to the spdif | ||
27 | clock mux in "SPDIF Transceiver Clock | ||
28 | Diagram" of SoC reference manual. It | ||
29 | can also be referred to TxClk_Source | ||
30 | bit of register SPDIF_STC. | ||
31 | |||
32 | Example: | ||
33 | |||
34 | spdif: spdif@02004000 { | ||
35 | compatible = "fsl,imx35-spdif"; | ||
36 | reg = <0x02004000 0x4000>; | ||
37 | interrupts = <0 52 0x04>; | ||
38 | dmas = <&sdma 14 18 0>, | ||
39 | <&sdma 15 18 0>; | ||
40 | dma-names = "rx", "tx"; | ||
41 | |||
42 | clocks = <&clks 197>, <&clks 3>, | ||
43 | <&clks 197>, <&clks 107>, | ||
44 | <&clks 0>, <&clks 118>, | ||
45 | <&clks 62>, <&clks 139>, | ||
46 | <&clks 0>; | ||
47 | clock-names = "core", "rxtx0", | ||
48 | "rxtx1", "rxtx2", | ||
49 | "rxtx3", "rxtx4", | ||
50 | "rxtx5", "rxtx6", | ||
51 | "rxtx7"; | ||
52 | |||
53 | status = "okay"; | ||
54 | }; | ||
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt index 5ff76c9c57d2..4303b6ab6208 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt +++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt | |||
@@ -43,10 +43,22 @@ Required properties: | |||
43 | together. This would still allow different sample sizes, | 43 | together. This would still allow different sample sizes, |
44 | but not different sample rates. | 44 | but not different sample rates. |
45 | 45 | ||
46 | Required are also ac97 link bindings if ac97 is used. See | ||
47 | Documentation/devicetree/bindings/sound/soc-ac97link.txt for the necessary | ||
48 | bindings. | ||
49 | |||
46 | Optional properties: | 50 | Optional properties: |
47 | - codec-handle: Phandle to a 'codec' node that defines an audio | 51 | - codec-handle: Phandle to a 'codec' node that defines an audio |
48 | codec connected to this SSI. This node is typically | 52 | codec connected to this SSI. This node is typically |
49 | a child of an I2C or other control node. | 53 | a child of an I2C or other control node. |
54 | - fsl,fiq-stream-filter: Bool property. Disabled DMA and use FIQ instead to | ||
55 | filter the codec stream. This is necessary for some boards | ||
56 | where an incompatible codec is connected to this SSI, e.g. | ||
57 | on pca100 and pcm043. | ||
58 | - dmas: Generic dma devicetree binding as described in | ||
59 | Documentation/devicetree/bindings/dma/dma.txt. | ||
60 | - dma-names: Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq | ||
61 | is not defined. | ||
50 | 62 | ||
51 | Child 'codec' node required properties: | 63 | Child 'codec' node required properties: |
52 | - compatible: Compatible list, contains the name of the codec | 64 | - compatible: Compatible list, contains the name of the codec |
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt new file mode 100644 index 000000000000..7d13479f9c3c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt | |||
@@ -0,0 +1,34 @@ | |||
1 | Freescale i.MX audio complex with S/PDIF transceiver | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | - compatible : "fsl,imx-audio-spdif" | ||
6 | |||
7 | - model : The user-visible name of this sound complex | ||
8 | |||
9 | - spdif-controller : The phandle of the i.MX S/PDIF controller | ||
10 | |||
11 | |||
12 | Optional properties: | ||
13 | |||
14 | - spdif-out : This is a boolean property. If present, the transmitting | ||
15 | function of S/PDIF will be enabled, indicating there's a physical | ||
16 | S/PDIF out connector/jack on the board or it's connecting to some | ||
17 | other IP block, such as an HDMI encoder/display-controller. | ||
18 | |||
19 | - spdif-in : This is a boolean property. If present, the receiving | ||
20 | function of S/PDIF will be enabled, indicating there's a physical | ||
21 | S/PDIF in connector/jack on the board. | ||
22 | |||
23 | * Note: At least one of these two properties should be set in the DT binding. | ||
24 | |||
25 | |||
26 | Example: | ||
27 | |||
28 | sound-spdif { | ||
29 | compatible = "fsl,imx-audio-spdif"; | ||
30 | model = "imx-spdif"; | ||
31 | spdif-controller = <&spdif>; | ||
32 | spdif-out; | ||
33 | spdif-in; | ||
34 | }; | ||
diff --git a/Documentation/devicetree/bindings/sound/imx-audmux.txt b/Documentation/devicetree/bindings/sound/imx-audmux.txt index 215aa9817213..f88a00e54c63 100644 --- a/Documentation/devicetree/bindings/sound/imx-audmux.txt +++ b/Documentation/devicetree/bindings/sound/imx-audmux.txt | |||
@@ -5,6 +5,15 @@ Required properties: | |||
5 | or "fsl,imx31-audmux" for the version firstly used on i.MX31. | 5 | or "fsl,imx31-audmux" for the version firstly used on i.MX31. |
6 | - reg : Should contain AUDMUX registers location and length | 6 | - reg : Should contain AUDMUX registers location and length |
7 | 7 | ||
8 | An initial configuration can be setup using child nodes. | ||
9 | |||
10 | Required properties of optional child nodes: | ||
11 | - fsl,audmux-port : Integer of the audmux port that is configured by this | ||
12 | child node. | ||
13 | - fsl,port-config : List of configuration options for the specific port. For | ||
14 | imx31-audmux and above, it is a list of tuples <ptcr pdcr>. For | ||
15 | imx21-audmux it is a list of pcr values. | ||
16 | |||
8 | Example: | 17 | Example: |
9 | 18 | ||
10 | audmux@021d8000 { | 19 | audmux@021d8000 { |
diff --git a/Documentation/devicetree/bindings/sound/mrvl,pxa-ssp.txt b/Documentation/devicetree/bindings/sound/mrvl,pxa-ssp.txt new file mode 100644 index 000000000000..74c9ba6c2823 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mrvl,pxa-ssp.txt | |||
@@ -0,0 +1,28 @@ | |||
1 | Marvell PXA SSP CPU DAI bindings | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | compatible Must be "mrvl,pxa-ssp-dai" | ||
6 | port A phandle reference to a PXA ssp upstream device | ||
7 | |||
8 | Example: | ||
9 | |||
10 | /* upstream device */ | ||
11 | |||
12 | ssp0: ssp@41000000 { | ||
13 | compatible = "mrvl,pxa3xx-ssp"; | ||
14 | reg = <0x41000000 0x40>; | ||
15 | interrupts = <24>; | ||
16 | clock-names = "pxa27x-ssp.0"; | ||
17 | dmas = <&dma 13 | ||
18 | &dma 14>; | ||
19 | dma-names = "rx", "tx"; | ||
20 | }; | ||
21 | |||
22 | /* DAI as user */ | ||
23 | |||
24 | ssp_dai0: ssp_dai@0 { | ||
25 | compatible = "mrvl,pxa-ssp-dai"; | ||
26 | port = <&ssp0>; | ||
27 | }; | ||
28 | |||
diff --git a/Documentation/devicetree/bindings/sound/mrvl,pxa2xx-pcm.txt b/Documentation/devicetree/bindings/sound/mrvl,pxa2xx-pcm.txt new file mode 100644 index 000000000000..551fbb8348c2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mrvl,pxa2xx-pcm.txt | |||
@@ -0,0 +1,15 @@ | |||
1 | DT bindings for ARM PXA2xx PCM platform driver | ||
2 | |||
3 | This is just a dummy driver that registers the PXA ASoC platform driver. | ||
4 | It does not have any resources assigned. | ||
5 | |||
6 | Required properties: | ||
7 | |||
8 | - compatible 'mrvl,pxa-pcm-audio' | ||
9 | |||
10 | Example: | ||
11 | |||
12 | pxa_pcm_audio: snd_soc_pxa_audio { | ||
13 | compatible = "mrvl,pxa-pcm-audio"; | ||
14 | }; | ||
15 | |||
diff --git a/Documentation/devicetree/bindings/sound/mvebu-audio.txt b/Documentation/devicetree/bindings/sound/mvebu-audio.txt new file mode 100644 index 000000000000..7e5fd37c1b3f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mvebu-audio.txt | |||
@@ -0,0 +1,29 @@ | |||
1 | * mvebu (Kirkwood, Dove, Armada 370) audio controller | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | - compatible: "marvell,mvebu-audio" | ||
6 | |||
7 | - reg: physical base address of the controller and length of memory mapped | ||
8 | region. | ||
9 | |||
10 | - interrupts: list of two irq numbers. | ||
11 | The first irq is used for data flow and the second one is used for errors. | ||
12 | |||
13 | - clocks: one or two phandles. | ||
14 | The first one is mandatory and defines the internal clock. | ||
15 | The second one is optional and defines an external clock. | ||
16 | |||
17 | - clock-names: names associated to the clocks: | ||
18 | "internal" for the internal clock | ||
19 | "extclk" for the external clock | ||
20 | |||
21 | Example: | ||
22 | |||
23 | i2s1: audio-controller@b4000 { | ||
24 | compatible = "marvell,mvebu-audio"; | ||
25 | reg = <0xb4000 0x2210>; | ||
26 | interrupts = <21>, <22>; | ||
27 | clocks = <&gate_clk 13>; | ||
28 | clock-names = "internal"; | ||
29 | }; | ||
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt index 05ffecb57103..8b8903ef0800 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt | |||
@@ -11,28 +11,8 @@ Required properties: | |||
11 | - nvidia,audio-routing : A list of the connections between audio components. | 11 | - nvidia,audio-routing : A list of the connections between audio components. |
12 | Each entry is a pair of strings, the first being the connection's sink, | 12 | Each entry is a pair of strings, the first being the connection's sink, |
13 | the second being the connection's source. Valid names for sources and | 13 | the second being the connection's source. Valid names for sources and |
14 | sinks are the ALC5632's pins: | 14 | sinks are the ALC5632's pins as documented in the binding for the device |
15 | 15 | and: | |
16 | ALC5632 pins: | ||
17 | |||
18 | * SPK_OUTP | ||
19 | * SPK_OUTN | ||
20 | * HP_OUT_L | ||
21 | * HP_OUT_R | ||
22 | * AUX_OUT_P | ||
23 | * AUX_OUT_N | ||
24 | * LINE_IN_L | ||
25 | * LINE_IN_R | ||
26 | * PHONE_P | ||
27 | * PHONE_N | ||
28 | * MIC1_P | ||
29 | * MIC1_N | ||
30 | * MIC2_P | ||
31 | * MIC2_N | ||
32 | * MICBIAS1 | ||
33 | * DMICDAT | ||
34 | |||
35 | Board connectors: | ||
36 | 16 | ||
37 | * Headset Stereophone | 17 | * Headset Stereophone |
38 | * Int Spk | 18 | * Int Spk |
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt index d130818700b2..dc6224994d69 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt | |||
@@ -11,32 +11,12 @@ Required properties: | |||
11 | - nvidia,audio-routing : A list of the connections between audio components. | 11 | - nvidia,audio-routing : A list of the connections between audio components. |
12 | Each entry is a pair of strings, the first being the connection's sink, | 12 | Each entry is a pair of strings, the first being the connection's sink, |
13 | the second being the connection's source. Valid names for sources and | 13 | the second being the connection's source. Valid names for sources and |
14 | sinks are the RT5640's pins, and the jacks on the board: | 14 | sinks are the RT5640's pins (as documented in its binding), and the jacks |
15 | 15 | on the board: | |
16 | RT5640 pins: | ||
17 | |||
18 | * DMIC1 | ||
19 | * DMIC2 | ||
20 | * MICBIAS1 | ||
21 | * IN1P | ||
22 | * IN1R | ||
23 | * IN2P | ||
24 | * IN2R | ||
25 | * HPOL | ||
26 | * HPOR | ||
27 | * LOUTL | ||
28 | * LOUTR | ||
29 | * MONOP | ||
30 | * MONON | ||
31 | * SPOLP | ||
32 | * SPOLN | ||
33 | * SPORP | ||
34 | * SPORN | ||
35 | |||
36 | Board connectors: | ||
37 | 16 | ||
38 | * Headphones | 17 | * Headphones |
39 | * Speakers | 18 | * Speakers |
19 | * Mic Jack | ||
40 | 20 | ||
41 | - nvidia,i2s-controller : The phandle of the Tegra I2S controller that's | 21 | - nvidia,i2s-controller : The phandle of the Tegra I2S controller that's |
42 | connected to the CODEC. | 22 | connected to the CODEC. |
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt index d14510613a7f..aab6ce0ad2fc 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt | |||
@@ -11,31 +11,8 @@ Required properties: | |||
11 | - nvidia,audio-routing : A list of the connections between audio components. | 11 | - nvidia,audio-routing : A list of the connections between audio components. |
12 | Each entry is a pair of strings, the first being the connection's sink, | 12 | Each entry is a pair of strings, the first being the connection's sink, |
13 | the second being the connection's source. Valid names for sources and | 13 | the second being the connection's source. Valid names for sources and |
14 | sinks are the WM8753's pins, and the jacks on the board: | 14 | sinks are the WM8753's pins as documented in the binding for the WM8753, |
15 | 15 | and the jacks on the board: | |
16 | WM8753 pins: | ||
17 | |||
18 | * LOUT1 | ||
19 | * LOUT2 | ||
20 | * ROUT1 | ||
21 | * ROUT2 | ||
22 | * MONO1 | ||
23 | * MONO2 | ||
24 | * OUT3 | ||
25 | * OUT4 | ||
26 | * LINE1 | ||
27 | * LINE2 | ||
28 | * RXP | ||
29 | * RXN | ||
30 | * ACIN | ||
31 | * ACOP | ||
32 | * MIC1N | ||
33 | * MIC1 | ||
34 | * MIC2N | ||
35 | * MIC2 | ||
36 | * Mic Bias | ||
37 | |||
38 | Board connectors: | ||
39 | 16 | ||
40 | * Headphone Jack | 17 | * Headphone Jack |
41 | * Mic Jack | 18 | * Mic Jack |
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt index 3bf722deb722..4b44dfb6ca0d 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt | |||
@@ -11,28 +11,8 @@ Required properties: | |||
11 | - nvidia,audio-routing : A list of the connections between audio components. | 11 | - nvidia,audio-routing : A list of the connections between audio components. |
12 | Each entry is a pair of strings, the first being the connection's sink, | 12 | Each entry is a pair of strings, the first being the connection's sink, |
13 | the second being the connection's source. Valid names for sources and | 13 | the second being the connection's source. Valid names for sources and |
14 | sinks are the WM8903's pins, and the jacks on the board: | 14 | sinks are the WM8903's pins (documented in the WM8903 binding document), |
15 | 15 | and the jacks on the board: | |
16 | WM8903 pins: | ||
17 | |||
18 | * IN1L | ||
19 | * IN1R | ||
20 | * IN2L | ||
21 | * IN2R | ||
22 | * IN3L | ||
23 | * IN3R | ||
24 | * DMICDAT | ||
25 | * HPOUTL | ||
26 | * HPOUTR | ||
27 | * LINEOUTL | ||
28 | * LINEOUTR | ||
29 | * LOP | ||
30 | * LON | ||
31 | * ROP | ||
32 | * RON | ||
33 | * MICBIAS | ||
34 | |||
35 | Board connectors: | ||
36 | 16 | ||
37 | * Headphone Jack | 17 | * Headphone Jack |
38 | * Int Spk | 18 | * Int Spk |
diff --git a/Documentation/devicetree/bindings/sound/pcm1792a.txt b/Documentation/devicetree/bindings/sound/pcm1792a.txt new file mode 100644 index 000000000000..970ba1ed576f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/pcm1792a.txt | |||
@@ -0,0 +1,18 @@ | |||
1 | Texas Instruments pcm1792a DT bindings | ||
2 | |||
3 | This driver supports the SPI bus. | ||
4 | |||
5 | Required properties: | ||
6 | |||
7 | - compatible: "ti,pcm1792a" | ||
8 | |||
9 | For required properties on SPI, please consult | ||
10 | Documentation/devicetree/bindings/spi/spi-bus.txt | ||
11 | |||
12 | Examples: | ||
13 | |||
14 | codec_spi: 1792a@0 { | ||
15 | compatible = "ti,pcm1792a"; | ||
16 | spi-max-frequency = <600000>; | ||
17 | }; | ||
18 | |||
diff --git a/Documentation/devicetree/bindings/sound/rt5640.txt b/Documentation/devicetree/bindings/sound/rt5640.txt index 005bcb24d72d..068a1141b06f 100644 --- a/Documentation/devicetree/bindings/sound/rt5640.txt +++ b/Documentation/devicetree/bindings/sound/rt5640.txt | |||
@@ -18,6 +18,26 @@ Optional properties: | |||
18 | 18 | ||
19 | - realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin. | 19 | - realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin. |
20 | 20 | ||
21 | Pins on the device (for linking into audio routes): | ||
22 | |||
23 | * DMIC1 | ||
24 | * DMIC2 | ||
25 | * MICBIAS1 | ||
26 | * IN1P | ||
27 | * IN1R | ||
28 | * IN2P | ||
29 | * IN2R | ||
30 | * HPOL | ||
31 | * HPOR | ||
32 | * LOUTL | ||
33 | * LOUTR | ||
34 | * MONOP | ||
35 | * MONON | ||
36 | * SPOLP | ||
37 | * SPOLN | ||
38 | * SPORP | ||
39 | * SPORN | ||
40 | |||
21 | Example: | 41 | Example: |
22 | 42 | ||
23 | rt5640 { | 43 | rt5640 { |
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt index 025e66b85a43..7386d444ada1 100644 --- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt +++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt | |||
@@ -2,7 +2,15 @@ | |||
2 | 2 | ||
3 | Required SoC Specific Properties: | 3 | Required SoC Specific Properties: |
4 | 4 | ||
5 | - compatible : "samsung,i2s-v5" | 5 | - compatible : should be one of the following. |
6 | - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. | ||
7 | - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with | ||
8 | secondary fifo, s/w reset control and internal mux for root clk src. | ||
9 | - samsung,exynos5420-i2s: for 8/16/24bit multichannel(7.1) I2S with | ||
10 | secondary fifo, s/w reset control, internal mux for root clk src and | ||
11 | TDM support. TDM (Time division multiplexing) is to allow transfer of | ||
12 | multiple channel audio data on single data line. | ||
13 | |||
6 | - reg: physical base address of the controller and length of memory mapped | 14 | - reg: physical base address of the controller and length of memory mapped |
7 | region. | 15 | region. |
8 | - dmas: list of DMA controller phandle and DMA request line ordered pairs. | 16 | - dmas: list of DMA controller phandle and DMA request line ordered pairs. |
@@ -21,13 +29,6 @@ Required SoC Specific Properties: | |||
21 | 29 | ||
22 | Optional SoC Specific Properties: | 30 | Optional SoC Specific Properties: |
23 | 31 | ||
24 | - samsung,supports-6ch: If the I2S Primary sound source has 5.1 Channel | ||
25 | support, this flag is enabled. | ||
26 | - samsung,supports-rstclr: This flag should be set if I2S software reset bit | ||
27 | control is required. When this flag is set I2S software reset bit will be | ||
28 | enabled or disabled based on need. | ||
29 | - samsung,supports-secdai:If I2S block has a secondary FIFO and internal DMA, | ||
30 | then this flag is enabled. | ||
31 | - samsung,idma-addr: Internal DMA register base address of the audio | 32 | - samsung,idma-addr: Internal DMA register base address of the audio |
32 | sub system(used in secondary sound source). | 33 | sub system(used in secondary sound source). |
33 | - pinctrl-0: Should specify pin control groups used for this controller. | 34 | - pinctrl-0: Should specify pin control groups used for this controller. |
@@ -36,7 +37,7 @@ Optional SoC Specific Properties: | |||
36 | Example: | 37 | Example: |
37 | 38 | ||
38 | i2s0: i2s@03830000 { | 39 | i2s0: i2s@03830000 { |
39 | compatible = "samsung,i2s-v5"; | 40 | compatible = "samsung,s5pv210-i2s"; |
40 | reg = <0x03830000 0x100>; | 41 | reg = <0x03830000 0x100>; |
41 | dmas = <&pdma0 10 | 42 | dmas = <&pdma0 10 |
42 | &pdma0 9 | 43 | &pdma0 9 |
@@ -46,9 +47,6 @@ i2s0: i2s@03830000 { | |||
46 | <&clock_audss EXYNOS_I2S_BUS>, | 47 | <&clock_audss EXYNOS_I2S_BUS>, |
47 | <&clock_audss EXYNOS_SCLK_I2S>; | 48 | <&clock_audss EXYNOS_SCLK_I2S>; |
48 | clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; | 49 | clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; |
49 | samsung,supports-6ch; | ||
50 | samsung,supports-rstclr; | ||
51 | samsung,supports-secdai; | ||
52 | samsung,idma-addr = <0x03000000>; | 50 | samsung,idma-addr = <0x03000000>; |
53 | pinctrl-names = "default"; | 51 | pinctrl-names = "default"; |
54 | pinctrl-0 = <&i2s0_bus>; | 52 | pinctrl-0 = <&i2s0_bus>; |
diff --git a/Documentation/devicetree/bindings/sound/soc-ac97link.txt b/Documentation/devicetree/bindings/sound/soc-ac97link.txt new file mode 100644 index 000000000000..80152a87f239 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/soc-ac97link.txt | |||
@@ -0,0 +1,28 @@ | |||
1 | AC97 link bindings | ||
2 | |||
3 | These bindings can be included within any other device node. | ||
4 | |||
5 | Required properties: | ||
6 | - pinctrl-names: Has to contain following states to setup the correct | ||
7 | pinmuxing for the used gpios: | ||
8 | "ac97-running": AC97-link is active | ||
9 | "ac97-reset": AC97-link reset state | ||
10 | "ac97-warm-reset": AC97-link warm reset state | ||
11 | - ac97-gpios: List of gpio phandles with args in the order ac97-sync, | ||
12 | ac97-sdata, ac97-reset | ||
13 | |||
14 | |||
15 | Example: | ||
16 | |||
17 | ssi { | ||
18 | ... | ||
19 | |||
20 | pinctrl-names = "default", "ac97-running", "ac97-reset", "ac97-warm-reset"; | ||
21 | pinctrl-0 = <&ac97link_running>; | ||
22 | pinctrl-1 = <&ac97link_running>; | ||
23 | pinctrl-2 = <&ac97link_reset>; | ||
24 | pinctrl-3 = <&ac97link_warm_reset>; | ||
25 | ac97-gpios = <&gpio3 20 0 &gpio3 22 0 &gpio3 28 0>; | ||
26 | |||
27 | ... | ||
28 | }; | ||
diff --git a/Documentation/devicetree/bindings/sound/ti,pcm1681.txt b/Documentation/devicetree/bindings/sound/ti,pcm1681.txt new file mode 100644 index 000000000000..4df17185ab80 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,pcm1681.txt | |||
@@ -0,0 +1,15 @@ | |||
1 | Texas Instruments PCM1681 8-channel PWM Processor | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | - compatible: Should contain "ti,pcm1681". | ||
6 | - reg: The i2c address. Should contain <0x4c>. | ||
7 | |||
8 | Examples: | ||
9 | |||
10 | i2c_bus { | ||
11 | pcm1681@4c { | ||
12 | compatible = "ti,pcm1681"; | ||
13 | reg = <0x4c>; | ||
14 | }; | ||
15 | }; | ||
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt index f47c3f589fd0..705a6b156c6c 100644 --- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt +++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt | |||
@@ -3,7 +3,14 @@ Texas Instruments - tlv320aic3x Codec module | |||
3 | The tlv320aic3x serial control bus communicates through I2C protocols | 3 | The tlv320aic3x serial control bus communicates through I2C protocols |
4 | 4 | ||
5 | Required properties: | 5 | Required properties: |
6 | - compatible - "string" - "ti,tlv320aic3x" | 6 | |
7 | - compatible - "string" - One of: | ||
8 | "ti,tlv320aic3x" - Generic TLV320AIC3x device | ||
9 | "ti,tlv320aic33" - TLV320AIC33 | ||
10 | "ti,tlv320aic3007" - TLV320AIC3007 | ||
11 | "ti,tlv320aic3106" - TLV320AIC3106 | ||
12 | |||
13 | |||
7 | - reg - <int> - I2C slave address | 14 | - reg - <int> - I2C slave address |
8 | 15 | ||
9 | 16 | ||
diff --git a/Documentation/devicetree/bindings/sound/wm8731.txt b/Documentation/devicetree/bindings/sound/wm8731.txt index 15f70048469b..236690e99b87 100644 --- a/Documentation/devicetree/bindings/sound/wm8731.txt +++ b/Documentation/devicetree/bindings/sound/wm8731.txt | |||
@@ -16,3 +16,12 @@ codec: wm8731@1a { | |||
16 | compatible = "wlf,wm8731"; | 16 | compatible = "wlf,wm8731"; |
17 | reg = <0x1a>; | 17 | reg = <0x1a>; |
18 | }; | 18 | }; |
19 | |||
20 | Available audio endpoints for an audio-routing table: | ||
21 | * LOUT: Left Channel Line Output | ||
22 | * ROUT: Right Channel Line Output | ||
23 | * LHPOUT: Left Channel Headphone Output | ||
24 | * RHPOUT: Right Channel Headphone Output | ||
25 | * LLINEIN: Left Channel Line Input | ||
26 | * RLINEIN: Right Channel Line Input | ||
27 | * MICIN: Microphone Input | ||
diff --git a/Documentation/devicetree/bindings/sound/wm8753.txt b/Documentation/devicetree/bindings/sound/wm8753.txt index e65277a0fb60..8eee61282105 100644 --- a/Documentation/devicetree/bindings/sound/wm8753.txt +++ b/Documentation/devicetree/bindings/sound/wm8753.txt | |||
@@ -10,9 +10,31 @@ Required properties: | |||
10 | - reg : the I2C address of the device for I2C, the chip select | 10 | - reg : the I2C address of the device for I2C, the chip select |
11 | number for SPI. | 11 | number for SPI. |
12 | 12 | ||
13 | Pins on the device (for linking into audio routes): | ||
14 | |||
15 | * LOUT1 | ||
16 | * LOUT2 | ||
17 | * ROUT1 | ||
18 | * ROUT2 | ||
19 | * MONO1 | ||
20 | * MONO2 | ||
21 | * OUT3 | ||
22 | * OUT4 | ||
23 | * LINE1 | ||
24 | * LINE2 | ||
25 | * RXP | ||
26 | * RXN | ||
27 | * ACIN | ||
28 | * ACOP | ||
29 | * MIC1N | ||
30 | * MIC1 | ||
31 | * MIC2N | ||
32 | * MIC2 | ||
33 | * Mic Bias | ||
34 | |||
13 | Example: | 35 | Example: |
14 | 36 | ||
15 | codec: wm8737@1a { | 37 | codec: wm8753@1a { |
16 | compatible = "wlf,wm8753"; | 38 | compatible = "wlf,wm8753"; |
17 | reg = <0x1a>; | 39 | reg = <0x1a>; |
18 | }; | 40 | }; |
diff --git a/Documentation/devicetree/bindings/sound/wm8903.txt b/Documentation/devicetree/bindings/sound/wm8903.txt index f102cbc42694..94ec32c194bb 100644 --- a/Documentation/devicetree/bindings/sound/wm8903.txt +++ b/Documentation/devicetree/bindings/sound/wm8903.txt | |||
@@ -28,6 +28,25 @@ Optional properties: | |||
28 | performed. If any entry has the value 0xffffffff, that GPIO's | 28 | performed. If any entry has the value 0xffffffff, that GPIO's |
29 | configuration will not be modified. | 29 | configuration will not be modified. |
30 | 30 | ||
31 | Pins on the device (for linking into audio routes): | ||
32 | |||
33 | * IN1L | ||
34 | * IN1R | ||
35 | * IN2L | ||
36 | * IN2R | ||
37 | * IN3L | ||
38 | * IN3R | ||
39 | * DMICDAT | ||
40 | * HPOUTL | ||
41 | * HPOUTR | ||
42 | * LINEOUTL | ||
43 | * LINEOUTR | ||
44 | * LOP | ||
45 | * LON | ||
46 | * ROP | ||
47 | * RON | ||
48 | * MICBIAS | ||
49 | |||
31 | Example: | 50 | Example: |
32 | 51 | ||
33 | codec: wm8903@1a { | 52 | codec: wm8903@1a { |
diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt b/Documentation/devicetree/bindings/sound/wm8994.txt index f2f3e80934d2..e045e90a0924 100644 --- a/Documentation/devicetree/bindings/sound/wm8994.txt +++ b/Documentation/devicetree/bindings/sound/wm8994.txt | |||
@@ -32,6 +32,10 @@ Optional properties: | |||
32 | The second cell is the flags, encoded as the trigger masks from | 32 | The second cell is the flags, encoded as the trigger masks from |
33 | Documentation/devicetree/bindings/interrupts.txt | 33 | Documentation/devicetree/bindings/interrupts.txt |
34 | 34 | ||
35 | - clocks : A list of up to two phandle and clock specifier pairs | ||
36 | - clock-names : A list of clock names sorted in the same order as clocks. | ||
37 | Valid clock names are "MCLK1" and "MCLK2". | ||
38 | |||
35 | - wlf,gpio-cfg : A list of GPIO configuration register values. If absent, | 39 | - wlf,gpio-cfg : A list of GPIO configuration register values. If absent, |
36 | no configuration of these registers is performed. If any value is | 40 | no configuration of these registers is performed. If any value is |
37 | over 0xffff then the register will be left as default. If present 11 | 41 | over 0xffff then the register will be left as default. If present 11 |
diff --git a/Documentation/devicetree/bindings/spi/efm32-spi.txt b/Documentation/devicetree/bindings/spi/efm32-spi.txt new file mode 100644 index 000000000000..a590ca51be75 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/efm32-spi.txt | |||
@@ -0,0 +1,34 @@ | |||
1 | * Energy Micro EFM32 SPI | ||
2 | |||
3 | Required properties: | ||
4 | - #address-cells: see spi-bus.txt | ||
5 | - #size-cells: see spi-bus.txt | ||
6 | - compatible: should be "efm32,spi" | ||
7 | - reg: Offset and length of the register set for the controller | ||
8 | - interrupts: pair specifying rx and tx irq | ||
9 | - clocks: phandle to the spi clock | ||
10 | - cs-gpios: see spi-bus.txt | ||
11 | - location: Value to write to the ROUTE register's LOCATION bitfield to configure the pinmux for the device, see datasheet for values. | ||
12 | |||
13 | Example: | ||
14 | |||
15 | spi1: spi@0x4000c400 { /* USART1 */ | ||
16 | #address-cells = <1>; | ||
17 | #size-cells = <0>; | ||
18 | compatible = "efm32,spi"; | ||
19 | reg = <0x4000c400 0x400>; | ||
20 | interrupts = <15 16>; | ||
21 | clocks = <&cmu 20>; | ||
22 | cs-gpios = <&gpio 51 1>; // D3 | ||
23 | location = <1>; | ||
24 | status = "ok"; | ||
25 | |||
26 | ks8851@0 { | ||
27 | compatible = "ks8851"; | ||
28 | spi-max-frequency = <6000000>; | ||
29 | reg = <0>; | ||
30 | interrupt-parent = <&boardfpga>; | ||
31 | interrupts = <4>; | ||
32 | status = "ok"; | ||
33 | }; | ||
34 | }; | ||
diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index 296015e3c632..800dafe5b01b 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt | |||
@@ -55,6 +55,16 @@ contain the following properties. | |||
55 | chip select active high | 55 | chip select active high |
56 | - spi-3wire - (optional) Empty property indicating device requires | 56 | - spi-3wire - (optional) Empty property indicating device requires |
57 | 3-wire mode. | 57 | 3-wire mode. |
58 | - spi-tx-bus-width - (optional) The bus width(number of data wires) that | ||
59 | used for MOSI. Defaults to 1 if not present. | ||
60 | - spi-rx-bus-width - (optional) The bus width(number of data wires) that | ||
61 | used for MISO. Defaults to 1 if not present. | ||
62 | |||
63 | Some SPI controllers and devices support Dual and Quad SPI transfer mode. | ||
64 | It allows data in SPI system transfered in 2 wires(DUAL) or 4 wires(QUAD). | ||
65 | Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is | ||
66 | only 1(SINGLE), 2(DUAL) and 4(QUAD). | ||
67 | Dual/Quad mode is not allowed when 3-wire mode is used. | ||
58 | 68 | ||
59 | If a gpio chipselect is used for the SPI slave the gpio number will be passed | 69 | If a gpio chipselect is used for the SPI slave the gpio number will be passed |
60 | via the cs_gpio | 70 | via the cs_gpio |
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt new file mode 100644 index 000000000000..a1fb3035a42b --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | |||
@@ -0,0 +1,42 @@ | |||
1 | ARM Freescale DSPI controller | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : "fsl,vf610-dspi" | ||
5 | - reg : Offset and length of the register set for the device | ||
6 | - interrupts : Should contain SPI controller interrupt | ||
7 | - clocks: from common clock binding: handle to dspi clock. | ||
8 | - clock-names: from common clock binding: Shall be "dspi". | ||
9 | - pinctrl-0: pin control group to be used for this controller. | ||
10 | - pinctrl-names: must contain a "default" entry. | ||
11 | - spi-num-chipselects : the number of the chipselect signals. | ||
12 | - bus-num : the slave chip chipselect signal number. | ||
13 | Example: | ||
14 | |||
15 | dspi0@4002c000 { | ||
16 | #address-cells = <1>; | ||
17 | #size-cells = <0>; | ||
18 | compatible = "fsl,vf610-dspi"; | ||
19 | reg = <0x4002c000 0x1000>; | ||
20 | interrupts = <0 67 0x04>; | ||
21 | clocks = <&clks VF610_CLK_DSPI0>; | ||
22 | clock-names = "dspi"; | ||
23 | spi-num-chipselects = <5>; | ||
24 | bus-num = <0>; | ||
25 | pinctrl-names = "default"; | ||
26 | pinctrl-0 = <&pinctrl_dspi0_1>; | ||
27 | status = "okay"; | ||
28 | |||
29 | sflash: at26df081a@0 { | ||
30 | #address-cells = <1>; | ||
31 | #size-cells = <1>; | ||
32 | compatible = "atmel,at26df081a"; | ||
33 | spi-max-frequency = <16000000>; | ||
34 | spi-cpol; | ||
35 | spi-cpha; | ||
36 | reg = <0>; | ||
37 | linux,modalias = "m25p80"; | ||
38 | modal = "at26df081a"; | ||
39 | }; | ||
40 | }; | ||
41 | |||
42 | |||
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt b/Documentation/devicetree/bindings/spi/ti_qspi.txt new file mode 100644 index 000000000000..1f9641ade0b5 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt | |||
@@ -0,0 +1,22 @@ | |||
1 | TI QSPI controller. | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : should be "ti,dra7xxx-qspi" or "ti,am4372-qspi". | ||
5 | - reg: Should contain QSPI registers location and length. | ||
6 | - #address-cells, #size-cells : Must be present if the device has sub-nodes | ||
7 | - ti,hwmods: Name of the hwmod associated to the QSPI | ||
8 | |||
9 | Recommended properties: | ||
10 | - spi-max-frequency: Definition as per | ||
11 | Documentation/devicetree/bindings/spi/spi-bus.txt | ||
12 | |||
13 | Example: | ||
14 | |||
15 | qspi: qspi@4b300000 { | ||
16 | compatible = "ti,dra7xxx-qspi"; | ||
17 | reg = <0x4b300000 0x100>; | ||
18 | #address-cells = <1>; | ||
19 | #size-cells = <0>; | ||
20 | spi-max-frequency = <25000000>; | ||
21 | ti,hwmods = "qspi"; | ||
22 | }; | ||
diff --git a/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt b/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt new file mode 100644 index 000000000000..da2d510cae47 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/moxa,moxart-timer.txt | |||
@@ -0,0 +1,17 @@ | |||
1 | MOXA ART timer | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | - compatible : Must be "moxa,moxart-timer" | ||
6 | - reg : Should contain registers location and length | ||
7 | - interrupts : Should contain the timer interrupt number | ||
8 | - clocks : Should contain phandle for the clock that drives the counter | ||
9 | |||
10 | Example: | ||
11 | |||
12 | timer: timer@98400000 { | ||
13 | compatible = "moxa,moxart-timer"; | ||
14 | reg = <0x98400000 0x42>; | ||
15 | interrupts = <19 1>; | ||
16 | clocks = <&coreclk>; | ||
17 | }; | ||
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt deleted file mode 100644 index c662eb36be29..000000000000 --- a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt +++ /dev/null | |||
@@ -1,22 +0,0 @@ | |||
1 | * Freescale i.MX Universal Asynchronous Receiver/Transmitter (UART) | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : Should be "fsl,<soc>-uart" | ||
5 | - reg : Address and length of the register set for the device | ||
6 | - interrupts : Should contain uart interrupt | ||
7 | |||
8 | Optional properties: | ||
9 | - fsl,uart-has-rtscts : Indicate the uart has rts and cts | ||
10 | - fsl,irda-mode : Indicate the uart supports irda mode | ||
11 | - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works | ||
12 | is DCE mode by default. | ||
13 | |||
14 | Example: | ||
15 | |||
16 | serial@73fbc000 { | ||
17 | compatible = "fsl,imx51-uart", "fsl,imx21-uart"; | ||
18 | reg = <0x73fbc000 0x4000>; | ||
19 | interrupts = <31>; | ||
20 | fsl,uart-has-rtscts; | ||
21 | fsl,dte-mode; | ||
22 | }; | ||
diff --git a/Documentation/devicetree/bindings/tty/serial/msm_serial.txt b/Documentation/devicetree/bindings/tty/serial/msm_serial.txt deleted file mode 100644 index aef383eb8876..000000000000 --- a/Documentation/devicetree/bindings/tty/serial/msm_serial.txt +++ /dev/null | |||
@@ -1,27 +0,0 @@ | |||
1 | * Qualcomm MSM UART | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : | ||
5 | - "qcom,msm-uart", and one of "qcom,msm-hsuart" or | ||
6 | "qcom,msm-lsuart". | ||
7 | - reg : offset and length of the register set for the device | ||
8 | for the hsuart operating in compatible mode, there should be a | ||
9 | second pair describing the gsbi registers. | ||
10 | - interrupts : should contain the uart interrupt. | ||
11 | |||
12 | There are two different UART blocks used in MSM devices, | ||
13 | "qcom,msm-hsuart" and "qcom,msm-lsuart". The msm-serial driver is | ||
14 | able to handle both of these, and matches against the "qcom,msm-uart" | ||
15 | as the compatibility. | ||
16 | |||
17 | The registers for the "qcom,msm-hsuart" device need to specify both | ||
18 | register blocks, even for the common driver. | ||
19 | |||
20 | Example: | ||
21 | |||
22 | uart@19c400000 { | ||
23 | compatible = "qcom,msm-hsuart", "qcom,msm-uart"; | ||
24 | reg = <0x19c40000 0x1000>, | ||
25 | <0x19c00000 0x1000>; | ||
26 | interrupts = <195>; | ||
27 | }; | ||
diff --git a/Documentation/devicetree/bindings/tty/serial/qca,ar9330-uart.txt b/Documentation/devicetree/bindings/tty/serial/qca,ar9330-uart.txt new file mode 100644 index 000000000000..c5e032c85bf9 --- /dev/null +++ b/Documentation/devicetree/bindings/tty/serial/qca,ar9330-uart.txt | |||
@@ -0,0 +1,34 @@ | |||
1 | * Qualcomm Atheros AR9330 High-Speed UART | ||
2 | |||
3 | Required properties: | ||
4 | |||
5 | - compatible: Must be "qca,ar9330-uart" | ||
6 | |||
7 | - reg: Specifies the physical base address of the controller and | ||
8 | the length of the memory mapped region. | ||
9 | |||
10 | - interrupt-parent: The phandle for the interrupt controller that | ||
11 | services interrupts for this device. | ||
12 | |||
13 | - interrupts: Specifies the interrupt source of the parent interrupt | ||
14 | controller. The format of the interrupt specifier depends on the | ||
15 | parent interrupt controller. | ||
16 | |||
17 | Additional requirements: | ||
18 | |||
19 | Each UART port must have an alias correctly numbered in "aliases" | ||
20 | node. | ||
21 | |||
22 | Example: | ||
23 | |||
24 | aliases { | ||
25 | serial0 = &uart0; | ||
26 | }; | ||
27 | |||
28 | uart0: uart@18020000 { | ||
29 | compatible = "qca,ar9330-uart"; | ||
30 | reg = <0x18020000 0x14>; | ||
31 | |||
32 | interrupt-parent = <&intc>; | ||
33 | interrupts = <3>; | ||
34 | }; | ||
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index dc9dc8c87f15..20c2ff2ba07e 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt | |||
@@ -1,35 +1,197 @@ | |||
1 | AM33XX MUSB GLUE | 1 | AM33xx MUSB |
2 | - compatible : Should be "ti,musb-am33xx" | 2 | ~~~~~~~~~~~~~~~ |
3 | - reg : offset and length of register sets, first usbss, then for musb instances | 3 | - compatible: ti,am33xx-usb |
4 | - interrupts : usbss, musb instance interrupts in order | 4 | - reg: offset and length of the usbss register sets |
5 | - ti,hwmods : must be "usb_otg_hs" | 5 | - ti,hwmods : must be "usb_otg_hs" |
6 | - multipoint : Should be "1" indicating the musb controller supports | 6 | |
7 | multipoint. This is a MUSB configuration-specific setting. | 7 | The glue layer contains multiple child nodes. It is required the have |
8 | - num-eps : Specifies the number of endpoints. This is also a | 8 | at least a control module node, USB node and a PHY node. The second USB |
9 | MUSB configuration-specific setting. Should be set to "16" | 9 | node and its PHY node is optional. The DMA node is also optional. |
10 | - ram-bits : Specifies the ram address size. Should be set to "12" | 10 | |
11 | - port0-mode : Should be "3" to represent OTG. "1" signifies HOST and "2" | 11 | Reset module |
12 | represents PERIPHERAL. | 12 | ~~~~~~~~~~~~ |
13 | - port1-mode : Should be "1" to represent HOST. "3" signifies OTG and "2" | 13 | - compatible: ti,am335x-usb-ctrl-module |
14 | represents PERIPHERAL. | 14 | - reg: offset and length of the "USB control registers" in the "Control |
15 | - power : Should be "250". This signifies the controller can supply up to | 15 | Module" block. A second offset and length for the USB wake up control |
16 | 500mA when operating in host mode. | 16 | in the same memory block. |
17 | - reg-names: "phy_ctrl" for the "USB control registers" and "wakeup" for | ||
18 | the USB wake up control register. | ||
19 | |||
20 | USB PHY | ||
21 | ~~~~~~~ | ||
22 | compatible: ti,am335x-usb-phy | ||
23 | reg: offset and length of the "USB PHY" register space | ||
24 | ti,ctrl_mod: reference to the "reset module" node | ||
25 | reg-names: phy | ||
26 | The PHY should have a "phy" alias numbered properly in the alias | ||
27 | node. | ||
28 | |||
29 | USB | ||
30 | ~~~ | ||
31 | - compatible: ti,musb-am33xx | ||
32 | - reg: offset and length of "USB Controller Registers", and offset and | ||
33 | length of "USB Core" register space. | ||
34 | - reg-names: control for the ""USB Controller Registers" and "mc" for | ||
35 | "USB Core" register space | ||
36 | - interrupts: USB interrupt number | ||
37 | - interrupt-names: mc | ||
38 | - dr_mode: Should be one of "host", "peripheral" or "otg". | ||
39 | - mentor,multipoint: Should be "1" indicating the musb controller supports | ||
40 | multipoint. This is a MUSB configuration-specific setting. | ||
41 | - mentor,num-eps: Specifies the number of endpoints. This is also a | ||
42 | MUSB configuration-specific setting. Should be set to "16" | ||
43 | - mentor,ram-bits: Specifies the ram address size. Should be set to "12" | ||
44 | - mentor,power: Should be "500". This signifies the controller can supply up to | ||
45 | 500mA when operating in host mode. | ||
46 | - phys: reference to the USB phy | ||
47 | - dmas: specifies the dma channels | ||
48 | - dma-names: specifies the names of the channels. Use "rxN" for receive | ||
49 | and "txN" for transmit endpoints. N specifies the endpoint number. | ||
50 | |||
51 | The controller should have an "usb" alias numbered properly in the alias | ||
52 | node. | ||
53 | |||
54 | DMA | ||
55 | ~~~ | ||
56 | - compatible: ti,am3359-cppi41 | ||
57 | - reg: offset and length of the following register spaces: USBSS, USB | ||
58 | CPPI DMA Controller, USB CPPI DMA Scheduler, USB Queue Manager | ||
59 | - reg-names: glue, controller, scheduler, queuemgr | ||
60 | - #dma-cells: should be set to 2. The first number represents the | ||
61 | endpoint number (0 … 14 for endpoints 1 … 15 on instance 0 and 15 … 29 | ||
62 | for endpoints 1 … 15 on instance 1). The second number is 0 for RX and | ||
63 | 1 for TX transfers. | ||
64 | - #dma-channels: should be set to 30 representing the 15 endpoints for | ||
65 | each USB instance. | ||
17 | 66 | ||
18 | Example: | 67 | Example: |
68 | ~~~~~~~~ | ||
69 | The following example contains all the nodes as used on am335x-evm: | ||
70 | |||
71 | aliases { | ||
72 | usb0 = &usb0; | ||
73 | usb1 = &usb1; | ||
74 | phy0 = &usb0_phy; | ||
75 | phy1 = &usb1_phy; | ||
76 | }; | ||
19 | 77 | ||
20 | usb@47400000 { | 78 | usb: usb@47400000 { |
21 | compatible = "ti,musb-am33xx"; | 79 | compatible = "ti,am33xx-usb"; |
22 | reg = <0x47400000 0x1000 /* usbss */ | 80 | reg = <0x47400000 0x1000>; |
23 | 0x47401000 0x800 /* musb instance 0 */ | 81 | ranges; |
24 | 0x47401800 0x800>; /* musb instance 1 */ | 82 | #address-cells = <1>; |
25 | interrupts = <17 /* usbss */ | 83 | #size-cells = <1>; |
26 | 18 /* musb instance 0 */ | ||
27 | 19>; /* musb instance 1 */ | ||
28 | multipoint = <1>; | ||
29 | num-eps = <16>; | ||
30 | ram-bits = <12>; | ||
31 | port0-mode = <3>; | ||
32 | port1-mode = <3>; | ||
33 | power = <250>; | ||
34 | ti,hwmods = "usb_otg_hs"; | 84 | ti,hwmods = "usb_otg_hs"; |
85 | |||
86 | ctrl_mod: control@44e10000 { | ||
87 | compatible = "ti,am335x-usb-ctrl-module"; | ||
88 | reg = <0x44e10620 0x10 | ||
89 | 0x44e10648 0x4>; | ||
90 | reg-names = "phy_ctrl", "wakeup"; | ||
91 | }; | ||
92 | |||
93 | usb0_phy: usb-phy@47401300 { | ||
94 | compatible = "ti,am335x-usb-phy"; | ||
95 | reg = <0x47401300 0x100>; | ||
96 | reg-names = "phy"; | ||
97 | ti,ctrl_mod = <&ctrl_mod>; | ||
98 | }; | ||
99 | |||
100 | usb0: usb@47401000 { | ||
101 | compatible = "ti,musb-am33xx"; | ||
102 | reg = <0x47401400 0x400 | ||
103 | 0x47401000 0x200>; | ||
104 | reg-names = "mc", "control"; | ||
105 | |||
106 | interrupts = <18>; | ||
107 | interrupt-names = "mc"; | ||
108 | dr_mode = "otg" | ||
109 | mentor,multipoint = <1>; | ||
110 | mentor,num-eps = <16>; | ||
111 | mentor,ram-bits = <12>; | ||
112 | mentor,power = <500>; | ||
113 | phys = <&usb0_phy>; | ||
114 | |||
115 | dmas = <&cppi41dma 0 0 &cppi41dma 1 0 | ||
116 | &cppi41dma 2 0 &cppi41dma 3 0 | ||
117 | &cppi41dma 4 0 &cppi41dma 5 0 | ||
118 | &cppi41dma 6 0 &cppi41dma 7 0 | ||
119 | &cppi41dma 8 0 &cppi41dma 9 0 | ||
120 | &cppi41dma 10 0 &cppi41dma 11 0 | ||
121 | &cppi41dma 12 0 &cppi41dma 13 0 | ||
122 | &cppi41dma 14 0 &cppi41dma 0 1 | ||
123 | &cppi41dma 1 1 &cppi41dma 2 1 | ||
124 | &cppi41dma 3 1 &cppi41dma 4 1 | ||
125 | &cppi41dma 5 1 &cppi41dma 6 1 | ||
126 | &cppi41dma 7 1 &cppi41dma 8 1 | ||
127 | &cppi41dma 9 1 &cppi41dma 10 1 | ||
128 | &cppi41dma 11 1 &cppi41dma 12 1 | ||
129 | &cppi41dma 13 1 &cppi41dma 14 1>; | ||
130 | dma-names = | ||
131 | "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7", | ||
132 | "rx8", "rx9", "rx10", "rx11", "rx12", "rx13", | ||
133 | "rx14", "rx15", | ||
134 | "tx1", "tx2", "tx3", "tx4", "tx5", "tx6", "tx7", | ||
135 | "tx8", "tx9", "tx10", "tx11", "tx12", "tx13", | ||
136 | "tx14", "tx15"; | ||
137 | }; | ||
138 | |||
139 | usb1_phy: usb-phy@47401b00 { | ||
140 | compatible = "ti,am335x-usb-phy"; | ||
141 | reg = <0x47401b00 0x100>; | ||
142 | reg-names = "phy"; | ||
143 | ti,ctrl_mod = <&ctrl_mod>; | ||
144 | }; | ||
145 | |||
146 | usb1: usb@47401800 { | ||
147 | compatible = "ti,musb-am33xx"; | ||
148 | reg = <0x47401c00 0x400 | ||
149 | 0x47401800 0x200>; | ||
150 | reg-names = "mc", "control"; | ||
151 | interrupts = <19>; | ||
152 | interrupt-names = "mc"; | ||
153 | dr_mode = "host" | ||
154 | mentor,multipoint = <1>; | ||
155 | mentor,num-eps = <16>; | ||
156 | mentor,ram-bits = <12>; | ||
157 | mentor,power = <500>; | ||
158 | phys = <&usb1_phy>; | ||
159 | |||
160 | dmas = <&cppi41dma 15 0 &cppi41dma 16 0 | ||
161 | &cppi41dma 17 0 &cppi41dma 18 0 | ||
162 | &cppi41dma 19 0 &cppi41dma 20 0 | ||
163 | &cppi41dma 21 0 &cppi41dma 22 0 | ||
164 | &cppi41dma 23 0 &cppi41dma 24 0 | ||
165 | &cppi41dma 25 0 &cppi41dma 26 0 | ||
166 | &cppi41dma 27 0 &cppi41dma 28 0 | ||
167 | &cppi41dma 29 0 &cppi41dma 15 1 | ||
168 | &cppi41dma 16 1 &cppi41dma 17 1 | ||
169 | &cppi41dma 18 1 &cppi41dma 19 1 | ||
170 | &cppi41dma 20 1 &cppi41dma 21 1 | ||
171 | &cppi41dma 22 1 &cppi41dma 23 1 | ||
172 | &cppi41dma 24 1 &cppi41dma 25 1 | ||
173 | &cppi41dma 26 1 &cppi41dma 27 1 | ||
174 | &cppi41dma 28 1 &cppi41dma 29 1>; | ||
175 | dma-names = | ||
176 | "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7", | ||
177 | "rx8", "rx9", "rx10", "rx11", "rx12", "rx13", | ||
178 | "rx14", "rx15", | ||
179 | "tx1", "tx2", "tx3", "tx4", "tx5", "tx6", "tx7", | ||
180 | "tx8", "tx9", "tx10", "tx11", "tx12", "tx13", | ||
181 | "tx14", "tx15"; | ||
182 | }; | ||
183 | |||
184 | cppi41dma: dma-controller@07402000 { | ||
185 | compatible = "ti,am3359-cppi41"; | ||
186 | reg = <0x47400000 0x1000 | ||
187 | 0x47402000 0x1000 | ||
188 | 0x47403000 0x1000 | ||
189 | 0x47404000 0x4000>; | ||
190 | reg-names = "glue", "controller", "scheduler", "queuemgr"; | ||
191 | interrupts = <17>; | ||
192 | interrupt-names = "glue"; | ||
193 | #dma-cells = <2>; | ||
194 | #dma-channels = <30>; | ||
195 | #dma-requests = <256>; | ||
196 | }; | ||
35 | }; | 197 | }; |
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 7a95c651ceb3..e807635f9e1c 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt | |||
@@ -3,10 +3,12 @@ synopsys DWC3 CORE | |||
3 | DWC3- USB3 CONTROLLER | 3 | DWC3- USB3 CONTROLLER |
4 | 4 | ||
5 | Required properties: | 5 | Required properties: |
6 | - compatible: must be "synopsys,dwc3" | 6 | - compatible: must be "snps,dwc3" |
7 | - reg : Address and length of the register set for the device | 7 | - reg : Address and length of the register set for the device |
8 | - interrupts: Interrupts used by the dwc3 controller. | 8 | - interrupts: Interrupts used by the dwc3 controller. |
9 | - usb-phy : array of phandle for the PHY device | 9 | - usb-phy : array of phandle for the PHY device. The first element |
10 | in the array is expected to be a handle to the USB2/HS PHY and | ||
11 | the second element is expected to be a handle to the USB3/SS PHY | ||
10 | 12 | ||
11 | Optional properties: | 13 | Optional properties: |
12 | - tx-fifo-resize: determines if the FIFO *has* to be reallocated. | 14 | - tx-fifo-resize: determines if the FIFO *has* to be reallocated. |
@@ -14,7 +16,7 @@ Optional properties: | |||
14 | This is usually a subnode to DWC3 glue to which it is connected. | 16 | This is usually a subnode to DWC3 glue to which it is connected. |
15 | 17 | ||
16 | dwc3@4a030000 { | 18 | dwc3@4a030000 { |
17 | compatible = "synopsys,dwc3"; | 19 | compatible = "snps,dwc3"; |
18 | reg = <0x4a030000 0xcfff>; | 20 | reg = <0x4a030000 0xcfff>; |
19 | interrupts = <0 92 4> | 21 | interrupts = <0 92 4> |
20 | usb-phy = <&usb2_phy>, <&usb3,phy>; | 22 | usb-phy = <&usb2_phy>, <&usb3,phy>; |
diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt new file mode 100644 index 000000000000..477d5bb5e51c --- /dev/null +++ b/Documentation/devicetree/bindings/usb/generic.txt | |||
@@ -0,0 +1,24 @@ | |||
1 | Generic USB Properties | ||
2 | |||
3 | Optional properties: | ||
4 | - maximum-speed: tells USB controllers we want to work up to a certain | ||
5 | speed. Valid arguments are "super-speed", "high-speed", | ||
6 | "full-speed" and "low-speed". In case this isn't passed | ||
7 | via DT, USB controllers should default to their maximum | ||
8 | HW capability. | ||
9 | - dr_mode: tells Dual-Role USB controllers that we want to work on a | ||
10 | particular mode. Valid arguments are "host", | ||
11 | "peripheral" and "otg". In case this attribute isn't | ||
12 | passed via DT, USB DRD controllers should default to | ||
13 | OTG. | ||
14 | |||
15 | This is an attribute to a USB controller such as: | ||
16 | |||
17 | dwc3@4a030000 { | ||
18 | compatible = "synopsys,dwc3"; | ||
19 | reg = <0x4a030000 0xcfff>; | ||
20 | interrupts = <0 92 4> | ||
21 | usb-phy = <&usb2_phy>, <&usb3,phy>; | ||
22 | maximum-speed = "super-speed"; | ||
23 | dr_mode = "otg"; | ||
24 | }; | ||
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt index c4c9e9e664aa..ba797d3e6326 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt | |||
@@ -3,7 +3,7 @@ Tegra SOC USB PHY | |||
3 | The device node for Tegra SOC USB PHY: | 3 | The device node for Tegra SOC USB PHY: |
4 | 4 | ||
5 | Required properties : | 5 | Required properties : |
6 | - compatible : Should be "nvidia,tegra20-usb-phy". | 6 | - compatible : Should be "nvidia,tegra<chip>-usb-phy". |
7 | - reg : Defines the following set of registers, in the order listed: | 7 | - reg : Defines the following set of registers, in the order listed: |
8 | - The PHY's own register set. | 8 | - The PHY's own register set. |
9 | Always present. | 9 | Always present. |
@@ -24,17 +24,26 @@ Required properties : | |||
24 | Required properties for phy_type == ulpi: | 24 | Required properties for phy_type == ulpi: |
25 | - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. | 25 | - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. |
26 | 26 | ||
27 | Required PHY timing params for utmi phy: | 27 | Required PHY timing params for utmi phy, for all chips: |
28 | - nvidia,hssync-start-delay : Number of 480 Mhz clock cycles to wait before | 28 | - nvidia,hssync-start-delay : Number of 480 Mhz clock cycles to wait before |
29 | start of sync launches RxActive | 29 | start of sync launches RxActive |
30 | - nvidia,elastic-limit : Variable FIFO Depth of elastic input store | 30 | - nvidia,elastic-limit : Variable FIFO Depth of elastic input store |
31 | - nvidia,idle-wait-delay : Number of 480 Mhz clock cycles of idle to wait | 31 | - nvidia,idle-wait-delay : Number of 480 Mhz clock cycles of idle to wait |
32 | before declare IDLE. | 32 | before declare IDLE. |
33 | - nvidia,term-range-adj : Range adjusment on terminations | 33 | - nvidia,term-range-adj : Range adjusment on terminations |
34 | - nvidia,xcvr-setup : HS driver output control | 34 | - Either one of the following for HS driver output control: |
35 | - nvidia,xcvr-setup : integer, uses the provided value. | ||
36 | - nvidia,xcvr-setup-use-fuses : boolean, indicates that the value is read | ||
37 | from the on-chip fuses | ||
38 | If both are provided, nvidia,xcvr-setup-use-fuses takes precedence. | ||
35 | - nvidia,xcvr-lsfslew : LS falling slew rate control. | 39 | - nvidia,xcvr-lsfslew : LS falling slew rate control. |
36 | - nvidia,xcvr-lsrslew : LS rising slew rate control. | 40 | - nvidia,xcvr-lsrslew : LS rising slew rate control. |
37 | 41 | ||
42 | Required PHY timing params for utmi phy, only on Tegra30 and above: | ||
43 | - nvidia,xcvr-hsslew : HS slew rate control. | ||
44 | - nvidia,hssquelch-level : HS squelch detector level. | ||
45 | - nvidia,hsdiscon-level : HS disconnect detector level. | ||
46 | |||
38 | Optional properties: | 47 | Optional properties: |
39 | - nvidia,has-legacy-mode : boolean indicates whether this controller can | 48 | - nvidia,has-legacy-mode : boolean indicates whether this controller can |
40 | operate in legacy mode (as APX 2500 / 2600). In legacy mode some | 49 | operate in legacy mode (as APX 2500 / 2600). In legacy mode some |
@@ -48,5 +57,5 @@ Optional properties: | |||
48 | peripheral means it is device controller | 57 | peripheral means it is device controller |
49 | otg means it can operate as either ("on the go") | 58 | otg means it can operate as either ("on the go") |
50 | 59 | ||
51 | Required properties for dr_mode == otg: | 60 | VBUS control (required for dr_mode == otg, optional for dr_mode == host): |
52 | - vbus-supply: regulator for VBUS | 61 | - vbus-supply: regulator for VBUS |
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 57e71f6817d0..9088ab09e200 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt | |||
@@ -53,6 +53,11 @@ OMAP DWC3 GLUE | |||
53 | It should be set to "1" for HW mode and "2" for SW mode. | 53 | It should be set to "1" for HW mode and "2" for SW mode. |
54 | - ranges: the child address space are mapped 1:1 onto the parent address space | 54 | - ranges: the child address space are mapped 1:1 onto the parent address space |
55 | 55 | ||
56 | Optional Properties: | ||
57 | - extcon : phandle for the extcon device omap dwc3 uses to detect | ||
58 | connect/disconnect events. | ||
59 | - vbus-supply : phandle to the regulator device tree node if needed. | ||
60 | |||
56 | Sub-nodes: | 61 | Sub-nodes: |
57 | The dwc3 core should be added as subnode to omap dwc3 glue. | 62 | The dwc3 core should be added as subnode to omap dwc3 glue. |
58 | - dwc3 : | 63 | - dwc3 : |
diff --git a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt new file mode 100644 index 000000000000..b83d428a265e --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt | |||
@@ -0,0 +1,40 @@ | |||
1 | Samsung High Speed USB OTG controller | ||
2 | ----------------------------- | ||
3 | |||
4 | The Samsung HSOTG IP can be found on Samsung SoCs, from S3C6400 onwards. | ||
5 | It gives functionality of OTG-compliant USB 2.0 host and device with | ||
6 | support for USB 2.0 high-speed (480Mbps) and full-speed (12 Mbps) | ||
7 | operation. | ||
8 | |||
9 | Currently only device mode is supported. | ||
10 | |||
11 | Binding details | ||
12 | ----- | ||
13 | |||
14 | Required properties: | ||
15 | - compatible: "samsung,s3c6400-hsotg" should be used for all currently | ||
16 | supported SoC, | ||
17 | - interrupt-parent: phandle for the interrupt controller to which the | ||
18 | interrupt signal of the HSOTG block is routed, | ||
19 | - interrupts: specifier of interrupt signal of interrupt controller, | ||
20 | according to bindings of interrupt controller, | ||
21 | - clocks: contains an array of clock specifiers: | ||
22 | - first entry: OTG clock | ||
23 | - clock-names: contains array of clock names: | ||
24 | - first entry: must be "otg" | ||
25 | - vusb_d-supply: phandle to voltage regulator of digital section, | ||
26 | - vusb_a-supply: phandle to voltage regulator of analog section. | ||
27 | |||
28 | Example | ||
29 | ----- | ||
30 | |||
31 | hsotg@12480000 { | ||
32 | compatible = "samsung,s3c6400-hsotg"; | ||
33 | reg = <0x12480000 0x20000>; | ||
34 | interrupts = <0 71 0>; | ||
35 | clocks = <&clock 305>; | ||
36 | clock-names = "otg"; | ||
37 | vusb_d-supply = <&vusb_reg>; | ||
38 | vusb_a-supply = <&vusbdac_reg>; | ||
39 | }; | ||
40 | |||
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt new file mode 100644 index 000000000000..5752df0e17a2 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt | |||
@@ -0,0 +1,14 @@ | |||
1 | USB xHCI controllers | ||
2 | |||
3 | Required properties: | ||
4 | - compatible: should be "xhci-platform". | ||
5 | - reg: should contain address and length of the standard XHCI | ||
6 | register set for the device. | ||
7 | - interrupts: one XHCI interrupt should be described here. | ||
8 | |||
9 | Example: | ||
10 | usb@f0931000 { | ||
11 | compatible = "xhci-platform"; | ||
12 | reg = <0xf0931000 0x8c8>; | ||
13 | interrupts = <0x0 0x4e 0x0>; | ||
14 | }; | ||
diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt index 8c5be48b43c8..a018da4a7ad7 100644 --- a/Documentation/devicetree/bindings/usb/usb3503.txt +++ b/Documentation/devicetree/bindings/usb/usb3503.txt | |||
@@ -1,8 +1,11 @@ | |||
1 | SMSC USB3503 High-Speed Hub Controller | 1 | SMSC USB3503 High-Speed Hub Controller |
2 | 2 | ||
3 | Required properties: | 3 | Required properties: |
4 | - compatible: Should be "smsc,usb3503". | 4 | - compatible: Should be "smsc,usb3503" or "smsc,usb3503a". |
5 | - reg: Specifies the i2c slave address, it should be 0x08. | 5 | |
6 | Optional properties: | ||
7 | - reg: Specifies the i2c slave address, it is required and should be 0x08 | ||
8 | if I2C is used. | ||
6 | - connect-gpios: Should specify GPIO for connect. | 9 | - connect-gpios: Should specify GPIO for connect. |
7 | - disabled-ports: Should specify the ports unused. | 10 | - disabled-ports: Should specify the ports unused. |
8 | '1' or '2' or '3' are availe for this property to describe the port | 11 | '1' or '2' or '3' are availe for this property to describe the port |
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ea95767cfed3..b571560ed5f9 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt | |||
@@ -12,6 +12,7 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC) | |||
12 | apm Applied Micro Circuits Corporation (APM) | 12 | apm Applied Micro Circuits Corporation (APM) |
13 | arm ARM Ltd. | 13 | arm ARM Ltd. |
14 | atmel Atmel Corporation | 14 | atmel Atmel Corporation |
15 | avago Avago Technologies | ||
15 | bosch Bosch Sensortec GmbH | 16 | bosch Bosch Sensortec GmbH |
16 | brcm Broadcom Corporation | 17 | brcm Broadcom Corporation |
17 | cavium Cavium, Inc. | 18 | cavium Cavium, Inc. |
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt index 3ea460583111..70c26f3a5b9a 100644 --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt | |||
@@ -12,6 +12,7 @@ Required properties: | |||
12 | - stride: The number of bytes in each line of the framebuffer. | 12 | - stride: The number of bytes in each line of the framebuffer. |
13 | - format: The format of the framebuffer surface. Valid values are: | 13 | - format: The format of the framebuffer surface. Valid values are: |
14 | - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b). | 14 | - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b). |
15 | - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r). | ||
15 | 16 | ||
16 | Example: | 17 | Example: |
17 | 18 | ||
diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 0b23261561d2..e31a2a9d2b07 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt | |||
@@ -321,7 +321,7 @@ Access to a dma_buf from the kernel context involves three steps: | |||
321 | 321 | ||
322 | When the importer is done accessing the range specified in begin_cpu_access, | 322 | When the importer is done accessing the range specified in begin_cpu_access, |
323 | it needs to announce this to the exporter (to facilitate cache flushing and | 323 | it needs to announce this to the exporter (to facilitate cache flushing and |
324 | unpinning of any pinned resources). The result of of any dma_buf kmap calls | 324 | unpinning of any pinned resources). The result of any dma_buf kmap calls |
325 | after end_cpu_access is undefined. | 325 | after end_cpu_access is undefined. |
326 | 326 | ||
327 | Interface: | 327 | Interface: |
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index b4671459857f..fb57d85e7316 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt | |||
@@ -237,6 +237,12 @@ MEM | |||
237 | devm_kzalloc() | 237 | devm_kzalloc() |
238 | devm_kfree() | 238 | devm_kfree() |
239 | 239 | ||
240 | IIO | ||
241 | devm_iio_device_alloc() | ||
242 | devm_iio_device_free() | ||
243 | devm_iio_trigger_alloc() | ||
244 | devm_iio_trigger_free() | ||
245 | |||
240 | IO region | 246 | IO region |
241 | devm_request_region() | 247 | devm_request_region() |
242 | devm_request_mem_region() | 248 | devm_request_mem_region() |
diff --git a/Documentation/early-userspace/README b/Documentation/early-userspace/README index 661a73fad399..93e63a9af30b 100644 --- a/Documentation/early-userspace/README +++ b/Documentation/early-userspace/README | |||
@@ -83,8 +83,7 @@ Where's this all leading? | |||
83 | 83 | ||
84 | The klibc distribution contains some of the necessary software to make | 84 | The klibc distribution contains some of the necessary software to make |
85 | early userspace useful. The klibc distribution is currently | 85 | early userspace useful. The klibc distribution is currently |
86 | maintained separately from the kernel, but this may change early in | 86 | maintained separately from the kernel. |
87 | the 2.7 era (it missed the boat for 2.5). | ||
88 | 87 | ||
89 | You can obtain somewhat infrequent snapshots of klibc from | 88 | You can obtain somewhat infrequent snapshots of klibc from |
90 | ftp://ftp.kernel.org/pub/linux/libs/klibc/ | 89 | ftp://ftp.kernel.org/pub/linux/libs/klibc/ |
diff --git a/Documentation/fb/fbcon.txt b/Documentation/fb/fbcon.txt index 99ea58e65eff..4a9739abc860 100644 --- a/Documentation/fb/fbcon.txt +++ b/Documentation/fb/fbcon.txt | |||
@@ -150,7 +150,7 @@ C. Boot options | |||
150 | 150 | ||
151 | C. Attaching, Detaching and Unloading | 151 | C. Attaching, Detaching and Unloading |
152 | 152 | ||
153 | Before going on on how to attach, detach and unload the framebuffer console, an | 153 | Before going on how to attach, detach and unload the framebuffer console, an |
154 | illustration of the dependencies may help. | 154 | illustration of the dependencies may help. |
155 | 155 | ||
156 | The console layer, as with most subsystems, needs a driver that interfaces with | 156 | The console layer, as with most subsystems, needs a driver that interfaces with |
diff --git a/Documentation/fb/viafb.modes b/Documentation/fb/viafb.modes index 02e5b487f00e..2a547da2e5cc 100644 --- a/Documentation/fb/viafb.modes +++ b/Documentation/fb/viafb.modes | |||
@@ -571,7 +571,7 @@ mode "640x480-60" | |||
571 | # 160 chars 800 lines | 571 | # 160 chars 800 lines |
572 | # Blank Time 4.798 us 0.564 ms | 572 | # Blank Time 4.798 us 0.564 ms |
573 | # 50 chars 28 lines | 573 | # 50 chars 28 lines |
574 | # Polarity negtive positive | 574 | # Polarity negative positive |
575 | # | 575 | # |
576 | mode "1280x800-60" | 576 | mode "1280x800-60" |
577 | # D: 83.500 MHz, H: 49.702 kHz, V: 60.00 Hz | 577 | # D: 83.500 MHz, H: 49.702 kHz, V: 60.00 Hz |
diff --git a/Documentation/fb/viafb.txt b/Documentation/fb/viafb.txt index 444e34b52ae1..1cb2462a71ce 100644 --- a/Documentation/fb/viafb.txt +++ b/Documentation/fb/viafb.txt | |||
@@ -32,7 +32,7 @@ | |||
32 | Start viafb with default settings: | 32 | Start viafb with default settings: |
33 | #modprobe viafb | 33 | #modprobe viafb |
34 | 34 | ||
35 | Start viafb with with user options: | 35 | Start viafb with user options: |
36 | #modprobe viafb viafb_mode=800x600 viafb_bpp=16 viafb_refresh=60 | 36 | #modprobe viafb viafb_mode=800x600 viafb_bpp=16 viafb_refresh=60 |
37 | viafb_active_dev=CRT+DVI viafb_dvi_port=DVP1 | 37 | viafb_active_dev=CRT+DVI viafb_dvi_port=DVP1 |
38 | viafb_mode1=1024x768 viafb_bpp=16 viafb_refresh1=60 | 38 | viafb_mode1=1024x768 viafb_bpp=16 viafb_refresh1=60 |
diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index b349d57b76ea..9dae59407437 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt | |||
@@ -87,7 +87,7 @@ Unless otherwise specified, all options default to off. | |||
87 | 87 | ||
88 | device=<devicepath> | 88 | device=<devicepath> |
89 | Specify a device during mount so that ioctls on the control device | 89 | Specify a device during mount so that ioctls on the control device |
90 | can be avoided. Especialy useful when trying to mount a multi-device | 90 | can be avoided. Especially useful when trying to mount a multi-device |
91 | setup as root. May be specified multiple times for multiple devices. | 91 | setup as root. May be specified multiple times for multiple devices. |
92 | 92 | ||
93 | discard | 93 | discard |
diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index 293855e95000..7ed0d17d6721 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt | |||
@@ -26,11 +26,12 @@ journal=inum When a journal already exists, this option is ignored. | |||
26 | Otherwise, it specifies the number of the inode which | 26 | Otherwise, it specifies the number of the inode which |
27 | will represent the ext3 file system's journal file. | 27 | will represent the ext3 file system's journal file. |
28 | 28 | ||
29 | journal_path=path | ||
29 | journal_dev=devnum When the external journal device's major/minor numbers | 30 | journal_dev=devnum When the external journal device's major/minor numbers |
30 | have changed, this option allows the user to specify | 31 | have changed, these options allow the user to specify |
31 | the new journal location. The journal device is | 32 | the new journal location. The journal device is |
32 | identified through its new major/minor numbers encoded | 33 | identified through either its new major/minor numbers |
33 | in devnum. | 34 | encoded in devnum, or via a path to the device. |
34 | 35 | ||
35 | norecovery Don't load the journal on mounting. Note that this forces | 36 | norecovery Don't load the journal on mounting. Note that this forces |
36 | noload mount of inconsistent filesystem, which can lead to | 37 | noload mount of inconsistent filesystem, which can lead to |
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index f7cbf574a875..919a3293aaa4 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt | |||
@@ -2,7 +2,7 @@ | |||
2 | Ext4 Filesystem | 2 | Ext4 Filesystem |
3 | =============== | 3 | =============== |
4 | 4 | ||
5 | Ext4 is an an advanced level of the ext3 filesystem which incorporates | 5 | Ext4 is an advanced level of the ext3 filesystem which incorporates |
6 | scalability and reliability enhancements for supporting large filesystems | 6 | scalability and reliability enhancements for supporting large filesystems |
7 | (64 bit) in keeping with increasing disk capacities and state-of-the-art | 7 | (64 bit) in keeping with increasing disk capacities and state-of-the-art |
8 | feature requirements. | 8 | feature requirements. |
@@ -144,11 +144,12 @@ journal_async_commit Commit block can be written to disk without waiting | |||
144 | mount the device. This will enable 'journal_checksum' | 144 | mount the device. This will enable 'journal_checksum' |
145 | internally. | 145 | internally. |
146 | 146 | ||
147 | journal_path=path | ||
147 | journal_dev=devnum When the external journal device's major/minor numbers | 148 | journal_dev=devnum When the external journal device's major/minor numbers |
148 | have changed, this option allows the user to specify | 149 | have changed, these options allow the user to specify |
149 | the new journal location. The journal device is | 150 | the new journal location. The journal device is |
150 | identified through its new major/minor numbers encoded | 151 | identified through either its new major/minor numbers |
151 | in devnum. | 152 | encoded in devnum, or via a path to the device. |
152 | 153 | ||
153 | norecovery Don't load the journal on mounting. Note that | 154 | norecovery Don't load the journal on mounting. Note that |
154 | noload if the filesystem was not unmounted cleanly, | 155 | noload if the filesystem was not unmounted cleanly, |
diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index b91e2f26b672..3cd27bed6349 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt | |||
@@ -18,8 +18,8 @@ according to its internal geometry or flash memory management scheme, namely FTL | |||
18 | F2FS and its tools support various parameters not only for configuring on-disk | 18 | F2FS and its tools support various parameters not only for configuring on-disk |
19 | layout, but also for selecting allocation and cleaning algorithms. | 19 | layout, but also for selecting allocation and cleaning algorithms. |
20 | 20 | ||
21 | The file system formatting tool, "mkfs.f2fs", is available from the following | 21 | The following git tree provides the file system formatting tool (mkfs.f2fs), |
22 | git tree: | 22 | a consistency checking tool (fsck.f2fs), and a debugging tool (dump.f2fs). |
23 | >> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git | 23 | >> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git |
24 | 24 | ||
25 | For reporting bugs and sending patches, please use the following mailing list: | 25 | For reporting bugs and sending patches, please use the following mailing list: |
@@ -133,6 +133,38 @@ f2fs. Each file shows the whole f2fs information. | |||
133 | - current memory footprint consumed by f2fs. | 133 | - current memory footprint consumed by f2fs. |
134 | 134 | ||
135 | ================================================================================ | 135 | ================================================================================ |
136 | SYSFS ENTRIES | ||
137 | ================================================================================ | ||
138 | |||
139 | Information about mounted f2f2 file systems can be found in | ||
140 | /sys/fs/f2fs. Each mounted filesystem will have a directory in | ||
141 | /sys/fs/f2fs based on its device name (i.e., /sys/fs/f2fs/sda). | ||
142 | The files in each per-device directory are shown in table below. | ||
143 | |||
144 | Files in /sys/fs/f2fs/<devname> | ||
145 | (see also Documentation/ABI/testing/sysfs-fs-f2fs) | ||
146 | .............................................................................. | ||
147 | File Content | ||
148 | |||
149 | gc_max_sleep_time This tuning parameter controls the maximum sleep | ||
150 | time for the garbage collection thread. Time is | ||
151 | in milliseconds. | ||
152 | |||
153 | gc_min_sleep_time This tuning parameter controls the minimum sleep | ||
154 | time for the garbage collection thread. Time is | ||
155 | in milliseconds. | ||
156 | |||
157 | gc_no_gc_sleep_time This tuning parameter controls the default sleep | ||
158 | time for the garbage collection thread. Time is | ||
159 | in milliseconds. | ||
160 | |||
161 | gc_idle This parameter controls the selection of victim | ||
162 | policy for garbage collection. Setting gc_idle = 0 | ||
163 | (default) will disable this option. Setting | ||
164 | gc_idle = 1 will select the Cost Benefit approach | ||
165 | & setting gc_idle = 2 will select the greedy aproach. | ||
166 | |||
167 | ================================================================================ | ||
136 | USAGE | 168 | USAGE |
137 | ================================================================================ | 169 | ================================================================================ |
138 | 170 | ||
@@ -149,8 +181,12 @@ USAGE | |||
149 | # mkfs.f2fs -l label /dev/block_device | 181 | # mkfs.f2fs -l label /dev/block_device |
150 | # mount -t f2fs /dev/block_device /mnt/f2fs | 182 | # mount -t f2fs /dev/block_device /mnt/f2fs |
151 | 183 | ||
152 | Format options | 184 | mkfs.f2fs |
153 | -------------- | 185 | --------- |
186 | The mkfs.f2fs is for the use of formatting a partition as the f2fs filesystem, | ||
187 | which builds a basic on-disk layout. | ||
188 | |||
189 | The options consist of: | ||
154 | -l [label] : Give a volume label, up to 512 unicode name. | 190 | -l [label] : Give a volume label, up to 512 unicode name. |
155 | -a [0 or 1] : Split start location of each area for heap-based allocation. | 191 | -a [0 or 1] : Split start location of each area for heap-based allocation. |
156 | 1 is set by default, which performs this. | 192 | 1 is set by default, which performs this. |
@@ -164,6 +200,37 @@ Format options | |||
164 | -t [0 or 1] : Disable discard command or not. | 200 | -t [0 or 1] : Disable discard command or not. |
165 | 1 is set by default, which conducts discard. | 201 | 1 is set by default, which conducts discard. |
166 | 202 | ||
203 | fsck.f2fs | ||
204 | --------- | ||
205 | The fsck.f2fs is a tool to check the consistency of an f2fs-formatted | ||
206 | partition, which examines whether the filesystem metadata and user-made data | ||
207 | are cross-referenced correctly or not. | ||
208 | Note that, initial version of the tool does not fix any inconsistency. | ||
209 | |||
210 | The options consist of: | ||
211 | -d debug level [default:0] | ||
212 | |||
213 | dump.f2fs | ||
214 | --------- | ||
215 | The dump.f2fs shows the information of specific inode and dumps SSA and SIT to | ||
216 | file. Each file is dump_ssa and dump_sit. | ||
217 | |||
218 | The dump.f2fs is used to debug on-disk data structures of the f2fs filesystem. | ||
219 | It shows on-disk inode information reconized by a given inode number, and is | ||
220 | able to dump all the SSA and SIT entries into predefined files, ./dump_ssa and | ||
221 | ./dump_sit respectively. | ||
222 | |||
223 | The options consist of: | ||
224 | -d debug level [default:0] | ||
225 | -i inode no (hex) | ||
226 | -s [SIT dump segno from #1~#2 (decimal), for all 0~-1] | ||
227 | -a [SSA dump segno from #1~#2 (decimal), for all 0~-1] | ||
228 | |||
229 | Examples: | ||
230 | # dump.f2fs -i [ino] /dev/sdx | ||
231 | # dump.f2fs -s 0~-1 /dev/sdx (SIT dump) | ||
232 | # dump.f2fs -a 0~-1 /dev/sdx (SSA dump) | ||
233 | |||
167 | ================================================================================ | 234 | ================================================================================ |
168 | DESIGN | 235 | DESIGN |
169 | ================================================================================ | 236 | ================================================================================ |
diff --git a/Documentation/filesystems/nfs/Exporting b/Documentation/filesystems/nfs/Exporting index 09994c247289..e543b1a619cc 100644 --- a/Documentation/filesystems/nfs/Exporting +++ b/Documentation/filesystems/nfs/Exporting | |||
@@ -93,7 +93,7 @@ For a filesystem to be exportable it must: | |||
93 | 2/ make sure that d_splice_alias is used rather than d_add | 93 | 2/ make sure that d_splice_alias is used rather than d_add |
94 | when ->lookup finds an inode for a given parent and name. | 94 | when ->lookup finds an inode for a given parent and name. |
95 | 95 | ||
96 | If inode is NULL, d_splice_alias(inode, dentry) is eqivalent to | 96 | If inode is NULL, d_splice_alias(inode, dentry) is equivalent to |
97 | 97 | ||
98 | d_add(dentry, inode), NULL | 98 | d_add(dentry, inode), NULL |
99 | 99 | ||
diff --git a/Documentation/filesystems/nfs/pnfs.txt b/Documentation/filesystems/nfs/pnfs.txt index 52ae07f5f578..adc81a35fe2d 100644 --- a/Documentation/filesystems/nfs/pnfs.txt +++ b/Documentation/filesystems/nfs/pnfs.txt | |||
@@ -12,7 +12,7 @@ struct pnfs_layout_hdr | |||
12 | ---------------------- | 12 | ---------------------- |
13 | The on-the-wire command LAYOUTGET corresponds to struct | 13 | The on-the-wire command LAYOUTGET corresponds to struct |
14 | pnfs_layout_segment, usually referred to by the variable name lseg. | 14 | pnfs_layout_segment, usually referred to by the variable name lseg. |
15 | Each nfs_inode may hold a pointer to a cache of of these layout | 15 | Each nfs_inode may hold a pointer to a cache of these layout |
16 | segments in nfsi->layout, of type struct pnfs_layout_hdr. | 16 | segments in nfsi->layout, of type struct pnfs_layout_hdr. |
17 | 17 | ||
18 | We reference the header for the inode pointing to it, across each | 18 | We reference the header for the inode pointing to it, across each |
diff --git a/Documentation/filesystems/qnx6.txt b/Documentation/filesystems/qnx6.txt index 99e90184a72f..408679789136 100644 --- a/Documentation/filesystems/qnx6.txt +++ b/Documentation/filesystems/qnx6.txt | |||
@@ -149,7 +149,7 @@ Bitmap system area | |||
149 | ------------------ | 149 | ------------------ |
150 | 150 | ||
151 | The bitmap itself is divided into three parts. | 151 | The bitmap itself is divided into three parts. |
152 | First the system area, that is split into two halfs. | 152 | First the system area, that is split into two halves. |
153 | Then userspace. | 153 | Then userspace. |
154 | 154 | ||
155 | The requirement for a static, fixed preallocated system area comes from how | 155 | The requirement for a static, fixed preallocated system area comes from how |
diff --git a/Documentation/filesystems/relay.txt b/Documentation/filesystems/relay.txt index 510b722667ac..33e2f3694733 100644 --- a/Documentation/filesystems/relay.txt +++ b/Documentation/filesystems/relay.txt | |||
@@ -31,7 +31,7 @@ Semantics | |||
31 | 31 | ||
32 | Each relay channel has one buffer per CPU, each buffer has one or more | 32 | Each relay channel has one buffer per CPU, each buffer has one or more |
33 | sub-buffers. Messages are written to the first sub-buffer until it is | 33 | sub-buffers. Messages are written to the first sub-buffer until it is |
34 | too full to contain a new message, in which case it it is written to | 34 | too full to contain a new message, in which case it is written to |
35 | the next (if available). Messages are never split across sub-buffers. | 35 | the next (if available). Messages are never split across sub-buffers. |
36 | At this point, userspace can be notified so it empties the first | 36 | At this point, userspace can be notified so it empties the first |
37 | sub-buffer, while the kernel continues writing to the next. | 37 | sub-buffer, while the kernel continues writing to the next. |
diff --git a/Documentation/filesystems/sysfs-tagging.txt b/Documentation/filesystems/sysfs-tagging.txt index caaaf1266d8f..eb843e49c5a3 100644 --- a/Documentation/filesystems/sysfs-tagging.txt +++ b/Documentation/filesystems/sysfs-tagging.txt | |||
@@ -24,7 +24,7 @@ flag between KOBJ_NS_TYPE_NONE and KOBJ_NS_TYPES, and s_ns will | |||
24 | point to the namespace to which it belongs. | 24 | point to the namespace to which it belongs. |
25 | 25 | ||
26 | Each sysfs superblock's sysfs_super_info contains an array void | 26 | Each sysfs superblock's sysfs_super_info contains an array void |
27 | *ns[KOBJ_NS_TYPES]. When a a task in a tagging namespace | 27 | *ns[KOBJ_NS_TYPES]. When a task in a tagging namespace |
28 | kobj_nstype first mounts sysfs, a new superblock is created. It | 28 | kobj_nstype first mounts sysfs, a new superblock is created. It |
29 | will be differentiated from other sysfs mounts by having its | 29 | will be differentiated from other sysfs mounts by having its |
30 | s_fs_info->ns[kobj_nstype] set to the new namespace. Note that | 30 | s_fs_info->ns[kobj_nstype] set to the new namespace. Note that |
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 12525b17d9ed..5be51fd888bd 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt | |||
@@ -135,7 +135,7 @@ default behaviour. | |||
135 | If the memory cost of 8 log buffers is too high on small | 135 | If the memory cost of 8 log buffers is too high on small |
136 | systems, then it may be reduced at some cost to performance | 136 | systems, then it may be reduced at some cost to performance |
137 | on metadata intensive workloads. The logbsize option below | 137 | on metadata intensive workloads. The logbsize option below |
138 | controls the size of each buffer and so is also relevent to | 138 | controls the size of each buffer and so is also relevant to |
139 | this case. | 139 | this case. |
140 | 140 | ||
141 | logbsize=value | 141 | logbsize=value |
diff --git a/Documentation/fmc/carrier.txt b/Documentation/fmc/carrier.txt index 173f6d65c88d..5e4f1dd3e98b 100644 --- a/Documentation/fmc/carrier.txt +++ b/Documentation/fmc/carrier.txt | |||
@@ -213,7 +213,7 @@ The individual methods perform the following tasks: | |||
213 | methods: for example the SPEC driver may define that its carrier | 213 | methods: for example the SPEC driver may define that its carrier |
214 | I2C memory is seen at offset 1M and the internal SPI flash is seen | 214 | I2C memory is seen at offset 1M and the internal SPI flash is seen |
215 | at offset 16M. This multiplexing of several flash memories in the | 215 | at offset 16M. This multiplexing of several flash memories in the |
216 | same address space is is carrier-specific and should only be used | 216 | same address space is carrier-specific and should only be used |
217 | by a driver that has verified the `carrier_name' field. | 217 | by a driver that has verified the `carrier_name' field. |
218 | 218 | ||
219 | 219 | ||
diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt index 3c741214dfbb..dc35a2b75eee 100644 --- a/Documentation/hid/uhid.txt +++ b/Documentation/hid/uhid.txt | |||
@@ -149,11 +149,13 @@ needs. Only UHID_OUTPUT and UHID_OUTPUT_EV have payloads. | |||
149 | is of type "struct uhid_data_req". | 149 | is of type "struct uhid_data_req". |
150 | This may be received even though you haven't received UHID_OPEN, yet. | 150 | This may be received even though you haven't received UHID_OPEN, yet. |
151 | 151 | ||
152 | UHID_OUTPUT_EV: | 152 | UHID_OUTPUT_EV (obsolete): |
153 | Same as UHID_OUTPUT but this contains a "struct input_event" as payload. This | 153 | Same as UHID_OUTPUT but this contains a "struct input_event" as payload. This |
154 | is called for force-feedback, LED or similar events which are received through | 154 | is called for force-feedback, LED or similar events which are received through |
155 | an input device by the HID subsystem. You should convert this into raw reports | 155 | an input device by the HID subsystem. You should convert this into raw reports |
156 | and send them to your device similar to events of type UHID_OUTPUT. | 156 | and send them to your device similar to events of type UHID_OUTPUT. |
157 | This is no longer sent by newer kernels. Instead, HID core converts it into a | ||
158 | raw output report and sends it via UHID_OUTPUT. | ||
157 | 159 | ||
158 | UHID_FEATURE: | 160 | UHID_FEATURE: |
159 | This event is sent if the kernel driver wants to perform a feature request as | 161 | This event is sent if the kernel driver wants to perform a feature request as |
diff --git a/Documentation/hwmon/abituguru-datasheet b/Documentation/hwmon/abituguru-datasheet index 8d2be8a0b1e3..86c0b1251c81 100644 --- a/Documentation/hwmon/abituguru-datasheet +++ b/Documentation/hwmon/abituguru-datasheet | |||
@@ -299,7 +299,7 @@ Byte 1: | |||
299 | min threshold (scale as bank 0x26) | 299 | min threshold (scale as bank 0x26) |
300 | 300 | ||
301 | 301 | ||
302 | Warning for the adventerous | 302 | Warning for the adventurous |
303 | =========================== | 303 | =========================== |
304 | 304 | ||
305 | A word of caution to those who want to experiment and see if they can figure | 305 | A word of caution to those who want to experiment and see if they can figure |
diff --git a/Documentation/hwmon/ads1015 b/Documentation/hwmon/ads1015 index f6fe9c203733..063b80d857b1 100644 --- a/Documentation/hwmon/ads1015 +++ b/Documentation/hwmon/ads1015 | |||
@@ -6,6 +6,10 @@ Supported chips: | |||
6 | Prefix: 'ads1015' | 6 | Prefix: 'ads1015' |
7 | Datasheet: Publicly available at the Texas Instruments website : | 7 | Datasheet: Publicly available at the Texas Instruments website : |
8 | http://focus.ti.com/lit/ds/symlink/ads1015.pdf | 8 | http://focus.ti.com/lit/ds/symlink/ads1015.pdf |
9 | * Texas Instruments ADS1115 | ||
10 | Prefix: 'ads1115' | ||
11 | Datasheet: Publicly available at the Texas Instruments website : | ||
12 | http://focus.ti.com/lit/ds/symlink/ads1115.pdf | ||
9 | 13 | ||
10 | Authors: | 14 | Authors: |
11 | Dirk Eibach, Guntermann & Drunck GmbH <eibach@gdsys.de> | 15 | Dirk Eibach, Guntermann & Drunck GmbH <eibach@gdsys.de> |
@@ -13,9 +17,9 @@ Authors: | |||
13 | Description | 17 | Description |
14 | ----------- | 18 | ----------- |
15 | 19 | ||
16 | This driver implements support for the Texas Instruments ADS1015. | 20 | This driver implements support for the Texas Instruments ADS1015/ADS1115. |
17 | 21 | ||
18 | This device is a 12-bit A-D converter with 4 inputs. | 22 | This device is a 12/16-bit A-D converter with 4 inputs. |
19 | 23 | ||
20 | The inputs can be used single ended or in certain differential combinations. | 24 | The inputs can be used single ended or in certain differential combinations. |
21 | 25 | ||
diff --git a/Documentation/hwmon/htu21 b/Documentation/hwmon/htu21 new file mode 100644 index 000000000000..f39a215fb6ae --- /dev/null +++ b/Documentation/hwmon/htu21 | |||
@@ -0,0 +1,46 @@ | |||
1 | Kernel driver htu21 | ||
2 | =================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Measurement Specialties HTU21D | ||
6 | Prefix: 'htu21' | ||
7 | Addresses scanned: none | ||
8 | Datasheet: Publicly available at the Measurement Specialties website | ||
9 | http://www.meas-spec.com/downloads/HTU21D.pdf | ||
10 | |||
11 | |||
12 | Author: | ||
13 | William Markezana <william.markezana@meas-spec.com> | ||
14 | |||
15 | Description | ||
16 | ----------- | ||
17 | |||
18 | The HTU21D is a humidity and temperature sensor in a DFN package of | ||
19 | only 3 x 3 mm footprint and 0.9 mm height. | ||
20 | |||
21 | The devices communicate with the I2C protocol. All sensors are set to the | ||
22 | same I2C address 0x40, so an entry with I2C_BOARD_INFO("htu21", 0x40) can | ||
23 | be used in the board setup code. | ||
24 | |||
25 | This driver does not auto-detect devices. You will have to instantiate the | ||
26 | devices explicitly. Please see Documentation/i2c/instantiating-devices | ||
27 | for details. | ||
28 | |||
29 | sysfs-Interface | ||
30 | --------------- | ||
31 | |||
32 | temp1_input - temperature input | ||
33 | humidity1_input - humidity input | ||
34 | |||
35 | Notes | ||
36 | ----- | ||
37 | |||
38 | The driver uses the default resolution settings of 12 bit for humidity and 14 | ||
39 | bit for temperature, which results in typical measurement times of 11 ms for | ||
40 | humidity and 44 ms for temperature. To keep self heating below 0.1 degree | ||
41 | Celsius, the device should not be active for more than 10% of the time. For | ||
42 | this reason, the driver performs no more than two measurements per second and | ||
43 | reports cached information if polled more frequently. | ||
44 | |||
45 | Different resolutions, the on-chip heater, using the CRC checksum and reading | ||
46 | the serial number are not supported yet. | ||
diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp index 90956b618025..4dfdc8f83633 100644 --- a/Documentation/hwmon/k10temp +++ b/Documentation/hwmon/k10temp | |||
@@ -12,6 +12,7 @@ Supported chips: | |||
12 | * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series) | 12 | * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series) |
13 | * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series) | 13 | * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series) |
14 | * AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity" | 14 | * AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity" |
15 | * AMD Family 16h processors: "Kabini" | ||
15 | 16 | ||
16 | Prefix: 'k10temp' | 17 | Prefix: 'k10temp' |
17 | Addresses scanned: PCI space | 18 | Addresses scanned: PCI space |
diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches index 46286460462b..3d1bac399a22 100644 --- a/Documentation/hwmon/submitting-patches +++ b/Documentation/hwmon/submitting-patches | |||
@@ -1,7 +1,7 @@ | |||
1 | How to Get Your Patch Accepted Into the Hwmon Subsystem | 1 | How to Get Your Patch Accepted Into the Hwmon Subsystem |
2 | ------------------------------------------------------- | 2 | ------------------------------------------------------- |
3 | 3 | ||
4 | This text is is a collection of suggestions for people writing patches or | 4 | This text is a collection of suggestions for people writing patches or |
5 | drivers for the hwmon subsystem. Following these suggestions will greatly | 5 | drivers for the hwmon subsystem. Following these suggestions will greatly |
6 | increase the chances of your change being accepted. | 6 | increase the chances of your change being accepted. |
7 | 7 | ||
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt index a903ee5e9776..62f7d4ea6e26 100644 --- a/Documentation/hwspinlock.txt +++ b/Documentation/hwspinlock.txt | |||
@@ -241,7 +241,7 @@ int hwspinlock_example2(void) | |||
241 | locks). | 241 | locks). |
242 | Should be called from a process context (this function might sleep). | 242 | Should be called from a process context (this function might sleep). |
243 | Returns the address of hwspinlock on success, or NULL on error (e.g. | 243 | Returns the address of hwspinlock on success, or NULL on error (e.g. |
244 | if the hwspinlock is sill in use). | 244 | if the hwspinlock is still in use). |
245 | 245 | ||
246 | 5. Important structs | 246 | 5. Important structs |
247 | 247 | ||
diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index a370b2047cf3..c097e0f020fe 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 | |||
@@ -73,9 +73,10 @@ this driver on those mainboards. | |||
73 | The ServerWorks Southbridges, the Intel 440MX, and the Victory66 are | 73 | The ServerWorks Southbridges, the Intel 440MX, and the Victory66 are |
74 | identical to the PIIX4 in I2C/SMBus support. | 74 | identical to the PIIX4 in I2C/SMBus support. |
75 | 75 | ||
76 | The AMD SB700 and SP5100 chipsets implement two PIIX4-compatible SMBus | 76 | The AMD SB700, SB800, SP5100 and Hudson-2 chipsets implement two |
77 | controllers. If your BIOS initializes the secondary controller, it will | 77 | PIIX4-compatible SMBus controllers. If your BIOS initializes the |
78 | be detected by this driver as an "Auxiliary SMBus Host Controller". | 78 | secondary controller, it will be detected by this driver as |
79 | an "Auxiliary SMBus Host Controller". | ||
79 | 80 | ||
80 | If you own Force CPCI735 motherboard or other OSB4 based systems you may need | 81 | If you own Force CPCI735 motherboard or other OSB4 based systems you may need |
81 | to change the SMBus Interrupt Select register so the SMBus controller uses | 82 | to change the SMBus Interrupt Select register so the SMBus controller uses |
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices index 22182660dda7..c70e7a7638d1 100644 --- a/Documentation/i2c/instantiating-devices +++ b/Documentation/i2c/instantiating-devices | |||
@@ -19,7 +19,7 @@ i2c_board_info which is registered by calling i2c_register_board_info(). | |||
19 | 19 | ||
20 | Example (from omap2 h4): | 20 | Example (from omap2 h4): |
21 | 21 | ||
22 | static struct i2c_board_info __initdata h4_i2c_board_info[] = { | 22 | static struct i2c_board_info h4_i2c_board_info[] __initdata = { |
23 | { | 23 | { |
24 | I2C_BOARD_INFO("isp1301_omap", 0x2d), | 24 | I2C_BOARD_INFO("isp1301_omap", 0x2d), |
25 | .irq = OMAP_GPIO_IRQ(125), | 25 | .irq = OMAP_GPIO_IRQ(125), |
diff --git a/Documentation/i2c/upgrading-clients b/Documentation/i2c/upgrading-clients index d6991625c407..8e5fbd88c7d1 100644 --- a/Documentation/i2c/upgrading-clients +++ b/Documentation/i2c/upgrading-clients | |||
@@ -196,8 +196,8 @@ static int example_probe(struct i2c_client *i2c_client, | |||
196 | 196 | ||
197 | Update the detach method, by changing the name to _remove and | 197 | Update the detach method, by changing the name to _remove and |
198 | to delete the i2c_detach_client call. It is possible that you | 198 | to delete the i2c_detach_client call. It is possible that you |
199 | can also remove the ret variable as it is not not needed for | 199 | can also remove the ret variable as it is not needed for any |
200 | any of the core functions. | 200 | of the core functions. |
201 | 201 | ||
202 | - static int example_detach(struct i2c_client *client) | 202 | - static int example_detach(struct i2c_client *client) |
203 | + static int example_remove(struct i2c_client *client) | 203 | + static int example_remove(struct i2c_client *client) |
diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt new file mode 100644 index 000000000000..8002c894c6b0 --- /dev/null +++ b/Documentation/input/gamepad.txt | |||
@@ -0,0 +1,156 @@ | |||
1 | Linux Gamepad API | ||
2 | ---------------------------------------------------------------------------- | ||
3 | |||
4 | 1. Intro | ||
5 | ~~~~~~~~ | ||
6 | Linux provides many different input drivers for gamepad hardware. To avoid | ||
7 | having user-space deal with different button-mappings for each gamepad, this | ||
8 | document defines how gamepads are supposed to report their data. | ||
9 | |||
10 | 2. Geometry | ||
11 | ~~~~~~~~~~~ | ||
12 | As "gamepad" we define devices which roughly look like this: | ||
13 | |||
14 | ____________________________ __ | ||
15 | / [__ZL__] [__ZR__] \ | | ||
16 | / [__ TL __] [__ TR __] \ | Front Triggers | ||
17 | __/________________________________\__ __| | ||
18 | / _ \ | | ||
19 | / /\ __ (N) \ | | ||
20 | / || __ |MO| __ _ _ \ | Main Pad | ||
21 | | <===DP===> |SE| |ST| (W) -|- (E) | | | ||
22 | \ || ___ ___ _ / | | ||
23 | /\ \/ / \ / \ (S) /\ __| | ||
24 | / \________ | LS | ____ | RS | ________/ \ | | ||
25 | | / \ \___/ / \ \___/ / \ | | Control Sticks | ||
26 | | / \_____/ \_____/ \ | __| | ||
27 | | / \ | | ||
28 | \_____/ \_____/ | ||
29 | |||
30 | |________|______| |______|___________| | ||
31 | D-Pad Left Right Action Pad | ||
32 | Stick Stick | ||
33 | |||
34 | |_____________| | ||
35 | Menu Pad | ||
36 | |||
37 | Most gamepads have the following features: | ||
38 | - Action-Pad | ||
39 | 4 buttons in diamonds-shape (on the right side). The buttons are | ||
40 | differently labeled on most devices so we define them as NORTH, | ||
41 | SOUTH, WEST and EAST. | ||
42 | - D-Pad (Direction-pad) | ||
43 | 4 buttons (on the left side) that point up, down, left and right. | ||
44 | - Menu-Pad | ||
45 | Different constellations, but most-times 2 buttons: SELECT - START | ||
46 | Furthermore, many gamepads have a fancy branded button that is used as | ||
47 | special system-button. It often looks different to the other buttons and | ||
48 | is used to pop up system-menus or system-settings. | ||
49 | - Analog-Sticks | ||
50 | Analog-sticks provide freely moveable sticks to control directions. Not | ||
51 | all devices have both or any, but they are present at most times. | ||
52 | Analog-sticks may also provide a digital button if you press them. | ||
53 | - Triggers | ||
54 | Triggers are located on the upper-side of the pad in vertical direction. | ||
55 | Not all devices provide them, but the upper buttons are normally named | ||
56 | Left- and Right-Triggers, the lower buttons Z-Left and Z-Right. | ||
57 | - Rumble | ||
58 | Many devices provide force-feedback features. But are mostly just | ||
59 | simple rumble motors. | ||
60 | |||
61 | 3. Detection | ||
62 | ~~~~~~~~~~~~ | ||
63 | All gamepads that follow the protocol described here map BTN_GAMEPAD. This is | ||
64 | an alias for BTN_SOUTH/BTN_A. It can be used to identify a gamepad as such. | ||
65 | However, not all gamepads provide all features, so you need to test for all | ||
66 | features that you need, first. How each feature is mapped is described below. | ||
67 | |||
68 | Legacy drivers often don't comply to these rules. As we cannot change them | ||
69 | for backwards-compatibility reasons, you need to provide fixup mappings in | ||
70 | user-space yourself. Some of them might also provide module-options that | ||
71 | change the mappings so you can adivce users to set these. | ||
72 | |||
73 | All new gamepads are supposed to comply with this mapping. Please report any | ||
74 | bugs, if they don't. | ||
75 | |||
76 | There are a lot of less-featured/less-powerful devices out there, which re-use | ||
77 | the buttons from this protocol. However, they try to do this in a compatible | ||
78 | fashion. For example, the "Nintendo Wii Nunchuk" provides two trigger buttons | ||
79 | and one analog stick. It reports them as if it were a gamepad with only one | ||
80 | analog stick and two trigger buttons on the right side. | ||
81 | But that means, that if you only support "real" gamepads, you must test | ||
82 | devices for _all_ reported events that you need. Otherwise, you will also get | ||
83 | devices that report a small subset of the events. | ||
84 | |||
85 | No other devices, that do not look/feel like a gamepad, shall report these | ||
86 | events. | ||
87 | |||
88 | 4. Events | ||
89 | ~~~~~~~~~ | ||
90 | Gamepads report the following events: | ||
91 | |||
92 | Action-Pad: | ||
93 | Every gamepad device has at least 2 action buttons. This means, that every | ||
94 | device reports BTN_SOUTH (which BTN_GAMEPAD is an alias for). Regardless | ||
95 | of the labels on the buttons, the codes are sent according to the | ||
96 | physical position of the buttons. | ||
97 | Please note that 2- and 3-button pads are fairly rare and old. You might | ||
98 | want to filter gamepads that do not report all four. | ||
99 | 2-Button Pad: | ||
100 | If only 2 action-buttons are present, they are reported as BTN_SOUTH and | ||
101 | BTN_EAST. For vertical layouts, the upper button is BTN_EAST. For | ||
102 | horizontal layouts, the button more on the right is BTN_EAST. | ||
103 | 3-Button Pad: | ||
104 | If only 3 action-buttons are present, they are reported as (from left | ||
105 | to right): BTN_WEST, BTN_SOUTH, BTN_EAST | ||
106 | If the buttons are aligned perfectly vertically, they are reported as | ||
107 | (from top down): BTN_WEST, BTN_SOUTH, BTN_EAST | ||
108 | 4-Button Pad: | ||
109 | If all 4 action-buttons are present, they can be aligned in two | ||
110 | different formations. If diamond-shaped, they are reported as BTN_NORTH, | ||
111 | BTN_WEST, BTN_SOUTH, BTN_EAST according to their physical location. | ||
112 | If rectangular-shaped, the upper-left button is BTN_NORTH, lower-left | ||
113 | is BTN_WEST, lower-right is BTN_SOUTH and upper-right is BTN_EAST. | ||
114 | |||
115 | D-Pad: | ||
116 | Every gamepad provides a D-Pad with four directions: Up, Down, Left, Right | ||
117 | Some of these are available as digital buttons, some as analog buttons. Some | ||
118 | may even report both. The kernel does not convert between these so | ||
119 | applications should support both and choose what is more appropriate if | ||
120 | both are reported. | ||
121 | Digital buttons are reported as: | ||
122 | BTN_DPAD_* | ||
123 | Analog buttons are reported as: | ||
124 | ABS_HAT0X and ABS_HAT0Y | ||
125 | |||
126 | Analog-Sticks: | ||
127 | The left analog-stick is reported as ABS_X, ABS_Y. The right analog stick is | ||
128 | reported as ABS_RX, ABS_RY. Zero, one or two sticks may be present. | ||
129 | If analog-sticks provide digital buttons, they are mapped accordingly as | ||
130 | BTN_THUMBL (first/left) and BTN_THUMBR (second/right). | ||
131 | |||
132 | Triggers: | ||
133 | Trigger buttons can be available as digital or analog buttons or both. User- | ||
134 | space must correctly deal with any situation and choose the most appropriate | ||
135 | mode. | ||
136 | Upper trigger buttons are reported as BTN_TR or ABS_HAT1X (right) and BTN_TL | ||
137 | or ABS_HAT1Y (left). Lower trigger buttons are reported as BTN_TR2 or | ||
138 | ABS_HAT2X (right/ZR) and BTN_TL2 or ABS_HAT2Y (left/ZL). | ||
139 | If only one trigger-button combination is present (upper+lower), they are | ||
140 | reported as "right" triggers (BTN_TR/ABS_HAT1X). | ||
141 | |||
142 | Menu-Pad: | ||
143 | Menu buttons are always digital and are mapped according to their location | ||
144 | instead of their labels. That is: | ||
145 | 1-button Pad: Mapped as BTN_START | ||
146 | 2-button Pad: Left button mapped as BTN_SELECT, right button mapped as | ||
147 | BTN_START | ||
148 | Many pads also have a third button which is branded or has a special symbol | ||
149 | and meaning. Such buttons are mapped as BTN_MODE. Examples are the Nintendo | ||
150 | "HOME" button, the XBox "X"-button or Sony "P" button. | ||
151 | |||
152 | Rumble: | ||
153 | Rumble is adverticed as FF_RUMBLE. | ||
154 | |||
155 | ---------------------------------------------------------------------------- | ||
156 | Written 2013 by David Herrmann <dh.herrmann@gmail.com> | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 15356aca938c..479eeaf44024 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -235,10 +235,61 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
235 | Format: To spoof as Windows 98: ="Microsoft Windows" | 235 | Format: To spoof as Windows 98: ="Microsoft Windows" |
236 | 236 | ||
237 | acpi_osi= [HW,ACPI] Modify list of supported OS interface strings | 237 | acpi_osi= [HW,ACPI] Modify list of supported OS interface strings |
238 | acpi_osi="string1" # add string1 -- only one string | 238 | acpi_osi="string1" # add string1 |
239 | acpi_osi="!string2" # remove built-in string2 | 239 | acpi_osi="!string2" # remove string2 |
240 | acpi_osi=!* # remove all strings | ||
241 | acpi_osi=! # disable all built-in OS vendor | ||
242 | strings | ||
240 | acpi_osi= # disable all strings | 243 | acpi_osi= # disable all strings |
241 | 244 | ||
245 | 'acpi_osi=!' can be used in combination with single or | ||
246 | multiple 'acpi_osi="string1"' to support specific OS | ||
247 | vendor string(s). Note that such command can only | ||
248 | affect the default state of the OS vendor strings, thus | ||
249 | it cannot affect the default state of the feature group | ||
250 | strings and the current state of the OS vendor strings, | ||
251 | specifying it multiple times through kernel command line | ||
252 | is meaningless. This command is useful when one do not | ||
253 | care about the state of the feature group strings which | ||
254 | should be controlled by the OSPM. | ||
255 | Examples: | ||
256 | 1. 'acpi_osi=! acpi_osi="Windows 2000"' is equivalent | ||
257 | to 'acpi_osi="Windows 2000" acpi_osi=!', they all | ||
258 | can make '_OSI("Windows 2000")' TRUE. | ||
259 | |||
260 | 'acpi_osi=' cannot be used in combination with other | ||
261 | 'acpi_osi=' command lines, the _OSI method will not | ||
262 | exist in the ACPI namespace. NOTE that such command can | ||
263 | only affect the _OSI support state, thus specifying it | ||
264 | multiple times through kernel command line is also | ||
265 | meaningless. | ||
266 | Examples: | ||
267 | 1. 'acpi_osi=' can make 'CondRefOf(_OSI, Local1)' | ||
268 | FALSE. | ||
269 | |||
270 | 'acpi_osi=!*' can be used in combination with single or | ||
271 | multiple 'acpi_osi="string1"' to support specific | ||
272 | string(s). Note that such command can affect the | ||
273 | current state of both the OS vendor strings and the | ||
274 | feature group strings, thus specifying it multiple times | ||
275 | through kernel command line is meaningful. But it may | ||
276 | still not able to affect the final state of a string if | ||
277 | there are quirks related to this string. This command | ||
278 | is useful when one want to control the state of the | ||
279 | feature group strings to debug BIOS issues related to | ||
280 | the OSPM features. | ||
281 | Examples: | ||
282 | 1. 'acpi_osi="Module Device" acpi_osi=!*' can make | ||
283 | '_OSI("Module Device")' FALSE. | ||
284 | 2. 'acpi_osi=!* acpi_osi="Module Device"' can make | ||
285 | '_OSI("Module Device")' TRUE. | ||
286 | 3. 'acpi_osi=! acpi_osi=!* acpi_osi="Windows 2000"' is | ||
287 | equivalent to | ||
288 | 'acpi_osi=!* acpi_osi=! acpi_osi="Windows 2000"' | ||
289 | and | ||
290 | 'acpi_osi=!* acpi_osi="Windows 2000" acpi_osi=!', | ||
291 | they all will make '_OSI("Windows 2000")' TRUE. | ||
292 | |||
242 | acpi_pm_good [X86] | 293 | acpi_pm_good [X86] |
243 | Override the pmtimer bug detection: force the kernel | 294 | Override the pmtimer bug detection: force the kernel |
244 | to assume that this machine's pmtimer latches its value | 295 | to assume that this machine's pmtimer latches its value |
@@ -2953,7 +3004,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
2953 | improve throughput, but will also increase the | 3004 | improve throughput, but will also increase the |
2954 | amount of memory reserved for use by the client. | 3005 | amount of memory reserved for use by the client. |
2955 | 3006 | ||
2956 | swapaccount[=0|1] | 3007 | swapaccount=[0|1] |
2957 | [KNL] Enable accounting of swap in memory resource | 3008 | [KNL] Enable accounting of swap in memory resource |
2958 | controller if no parameter or 1 is given or disable | 3009 | controller if no parameter or 1 is given or disable |
2959 | it if 0 is given (See Documentation/cgroups/memory.txt) | 3010 | it if 0 is given (See Documentation/cgroups/memory.txt) |
@@ -3322,6 +3373,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
3322 | them quite hard to use for exploits but | 3373 | them quite hard to use for exploits but |
3323 | might break your system. | 3374 | might break your system. |
3324 | 3375 | ||
3376 | vt.color= [VT] Default text color. | ||
3377 | Format: 0xYX, X = foreground, Y = background. | ||
3378 | Default: 0x07 = light gray on black. | ||
3379 | |||
3325 | vt.cur_default= [VT] Default cursor shape. | 3380 | vt.cur_default= [VT] Default cursor shape. |
3326 | Format: 0xCCBBAA, where AA, BB, and CC are the same as | 3381 | Format: 0xCCBBAA, where AA, BB, and CC are the same as |
3327 | the parameters of the <Esc>[?A;B;Cc escape sequence; | 3382 | the parameters of the <Esc>[?A;B;Cc escape sequence; |
@@ -3361,6 +3416,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
3361 | overridden by individual drivers. 0 will hide | 3416 | overridden by individual drivers. 0 will hide |
3362 | cursors, 1 will display them. | 3417 | cursors, 1 will display them. |
3363 | 3418 | ||
3419 | vt.italic= [VT] Default color for italic text; 0-15. | ||
3420 | Default: 2 = green. | ||
3421 | |||
3422 | vt.underline= [VT] Default color for underlined text; 0-15. | ||
3423 | Default: 3 = cyan. | ||
3424 | |||
3364 | watchdog timers [HW,WDT] For information on watchdog timers, | 3425 | watchdog timers [HW,WDT] For information on watchdog timers, |
3365 | see Documentation/watchdog/watchdog-parameters.txt | 3426 | see Documentation/watchdog/watchdog-parameters.txt |
3366 | or other driver-specific files in the | 3427 | or other driver-specific files in the |
diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt index c28f82895d6b..9398a501fdb9 100644 --- a/Documentation/kmemcheck.txt +++ b/Documentation/kmemcheck.txt | |||
@@ -91,9 +91,9 @@ information from the kmemcheck warnings, which is extremely valuable in | |||
91 | debugging a problem. This option is not mandatory, however, because it slows | 91 | debugging a problem. This option is not mandatory, however, because it slows |
92 | down the compilation process and produces a much bigger kernel image. | 92 | down the compilation process and produces a much bigger kernel image. |
93 | 93 | ||
94 | Now the kmemcheck menu should be visible (under "Kernel hacking" / "kmemcheck: | 94 | Now the kmemcheck menu should be visible (under "Kernel hacking" / "Memory |
95 | trap use of uninitialized memory"). Here follows a description of the | 95 | Debugging" / "kmemcheck: trap use of uninitialized memory"). Here follows |
96 | kmemcheck configuration variables: | 96 | a description of the kmemcheck configuration variables: |
97 | 97 | ||
98 | o CONFIG_KMEMCHECK | 98 | o CONFIG_KMEMCHECK |
99 | 99 | ||
diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO index 2f48f205fedc..680e64635958 100644 --- a/Documentation/ko_KR/HOWTO +++ b/Documentation/ko_KR/HOWTO | |||
@@ -182,8 +182,8 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H | |||
182 | 프로젝트를 봐야 한다. | 182 | 프로젝트를 봐야 한다. |
183 | http://kernelnewbies.org | 183 | http://kernelnewbies.org |
184 | 그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저 | 184 | 그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저 |
185 | 아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할수있는 도움이 | 185 | 아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할 수 있는 도움이 |
186 | 될만한 메일링 리스트가 있다. 또한 실시간으로 질문 할수 있는 IRC 채널도 | 186 | 될만한 메일링 리스트가 있다. 또한 실시간으로 질문 할 수 있는 IRC 채널도 |
187 | 가지고 있으며 리눅스 커널 개발을 배우는 데 유용한 문서들을 보유하고 있다. | 187 | 가지고 있으며 리눅스 커널 개발을 배우는 데 유용한 문서들을 보유하고 있다. |
188 | 188 | ||
189 | 웹사이트는 코드구성, 서브시스템들, 그리고 현재 프로젝트들 | 189 | 웹사이트는 코드구성, 서브시스템들, 그리고 현재 프로젝트들 |
@@ -245,7 +245,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H | |||
245 | 것을 기억해라. 왜냐하면 변경이 자체내에서만 발생하고 추가된 코드가 | 245 | 것을 기억해라. 왜냐하면 변경이 자체내에서만 발생하고 추가된 코드가 |
246 | 드라이버 외부의 다른 부분에는 영향을 주지 않으므로 그런 변경은 | 246 | 드라이버 외부의 다른 부분에는 영향을 주지 않으므로 그런 변경은 |
247 | 회귀(역자주: 이전에는 존재하지 않았지만 새로운 기능추가나 변경으로 인해 | 247 | 회귀(역자주: 이전에는 존재하지 않았지만 새로운 기능추가나 변경으로 인해 |
248 | 생겨난 버그)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이 | 248 | 생겨난 버그)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이 |
249 | 배포된 이후에 git를 사용하여 패치들을 Linus에게 보낼수 있지만 패치들은 | 249 | 배포된 이후에 git를 사용하여 패치들을 Linus에게 보낼수 있지만 패치들은 |
250 | 공식적인 메일링 리스트로 보내서 검토를 받을 필요가 있다. | 250 | 공식적인 메일링 리스트로 보내서 검토를 받을 필요가 있다. |
251 | - 새로운 -rc는 Linus가 현재 git tree가 테스트 하기에 충분히 안정된 상태에 | 251 | - 새로운 -rc는 Linus가 현재 git tree가 테스트 하기에 충분히 안정된 상태에 |
@@ -455,7 +455,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메 | |||
455 | - 의견 | 455 | - 의견 |
456 | - 변경을 위한 요구 | 456 | - 변경을 위한 요구 |
457 | - 당위성을 위한 요구 | 457 | - 당위성을 위한 요구 |
458 | - 고 | 458 | - 묵 |
459 | 459 | ||
460 | 기억하라. 이것들은 여러분의 패치가 커널로 들어가기 위한 과정이다. 여러분의 | 460 | 기억하라. 이것들은 여러분의 패치가 커널로 들어가기 위한 과정이다. 여러분의 |
461 | 패치들은 비판과 다른 의견을 받을 수 있고 그것들을 기술적인 레벨로 평가하고 | 461 | 패치들은 비판과 다른 의견을 받을 수 있고 그것들을 기술적인 레벨로 평가하고 |
@@ -472,7 +472,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메 | |||
472 | 가능한한 가장 좋은 기술적인 해답을 찾고 있는 커뮤니티에서는 항상 | 472 | 가능한한 가장 좋은 기술적인 해답을 찾고 있는 커뮤니티에서는 항상 |
473 | 어떤 패치가 얼마나 좋은지에 관하여 다른 의견들이 있을 수 있다. 여러분은 | 473 | 어떤 패치가 얼마나 좋은지에 관하여 다른 의견들이 있을 수 있다. 여러분은 |
474 | 협조적이어야 하고 기꺼이 여러분의 생각을 커널 내에 맞추어야 한다. 아니면 | 474 | 협조적이어야 하고 기꺼이 여러분의 생각을 커널 내에 맞추어야 한다. 아니면 |
475 | 적어도 여러분의 것이 가치있다는 것을 명하여야 한다. 잘못된 것도 여러분이 | 475 | 적어도 여러분의 것이 가치있다는 것을 명하여야 한다. 잘못된 것도 여러분이 |
476 | 올바른 방향의 해결책으로 이끌어갈 의지가 있다면 받아들여질 것이라는 점을 | 476 | 올바른 방향의 해결책으로 이끌어갈 의지가 있다면 받아들여질 것이라는 점을 |
477 | 기억하라. | 477 | 기억하라. |
478 | 478 | ||
@@ -488,21 +488,21 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메 | |||
488 | 커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의 | 488 | 커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의 |
489 | 문제를 피하기 위한 목록이 있다. | 489 | 문제를 피하기 위한 목록이 있다. |
490 | 여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 : | 490 | 여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 : |
491 | - "이것은 여러 문제들을 해합니다." | 491 | - "이것은 여러 문제들을 해합니다." |
492 | - "이것은 2000 라인의 코드를 거합니다." | 492 | - "이것은 2000 라인의 코드를 입니다." |
493 | - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다." | 493 | - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다." |
494 | - "나는 5개의 다른 아키텍쳐에서 그것을 테스트했로..." | 494 | - "나는 5개의 다른 아키텍쳐에서 그것을 테스트 했으..." |
495 | - "여기에 일련의 작은 패치들이 있음로..." | 495 | - "여기에 일련의 작은 패치들이 있..." |
496 | - "이것은 일반적인 머신에서 성능을 향상시으로..." | 496 | - "이것은 일반적인 머신에서 성능을 향상으로..." |
497 | 497 | ||
498 | 여러분들이 말할 때 피해야 할 좋지 않은 것들 : | 498 | 여러분들이 말할 때 피해야 할 좋지 않은 것들 : |
499 | - "우리를 그것을 AIT/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀립없다..." | 499 | - "우리는 그것을 AIX/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀림없다..." |
500 | - "나는 20년동안 이것을 해왔다. 그러므로..." | 500 | - "나는 20년동안 이것을 해왔다. 그러므로..." |
501 | - "이것은 돈을 벌기위해 나의 회사가 필요로 하는 것이다." | 501 | - "이것은 돈을 벌기위해 나의 회사가 필요로 하는 것이다." |
502 | - "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다." | 502 | - "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다." |
503 | - "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다." | 503 | - "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다." |
504 | - "나는 6달동안 이것을 했으니..." | 504 | - "나는 6달동안 이것을 했으니..." |
505 | - "여기에 5000라인 짜리 패치가 있으니..." | 505 | - "여기에 5000 라인 짜리 패치가 있으니..." |
506 | - "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..." | 506 | - "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..." |
507 | - "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다." | 507 | - "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다." |
508 | 508 | ||
@@ -574,6 +574,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅 | |||
574 | 또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들을 포함하는 | 574 | 또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들을 포함하는 |
575 | 패치들은 받아들여지지 않을 것이라는 점을 유념하라. | 575 | 패치들은 받아들여지지 않을 것이라는 점을 유념하라. |
576 | 576 | ||
577 | |||
577 | 변경을 정당화해라 | 578 | 변경을 정당화해라 |
578 | ----------------- | 579 | ----------------- |
579 | 580 | ||
diff --git a/Documentation/ko_KR/stable_api_nonsense.txt b/Documentation/ko_KR/stable_api_nonsense.txt index 8f2b0e1d98c4..51f85ade4190 100644 --- a/Documentation/ko_KR/stable_api_nonsense.txt +++ b/Documentation/ko_KR/stable_api_nonsense.txt | |||
@@ -106,12 +106,12 @@ Greg Kroah-Hartman <greg@kroah.com> | |||
106 | --------------------------------- | 106 | --------------------------------- |
107 | 107 | ||
108 | 리눅스 커널 드라이버를 계속해서 메인 커널 트리에 반영하지 않고 | 108 | 리눅스 커널 드라이버를 계속해서 메인 커널 트리에 반영하지 않고 |
109 | 유지보수하려고 하는 사들과 이 문제를 논의하게 되면 훨씬 더 | 109 | 유지보수하려고 하는 사들과 이 문제를 논의하게 되면 훨씬 더 |
110 | "논란의 여지가 많은" 주제가 될 것이다. | 110 | "논란의 여지가 많은" 주제가 될 것이다. |
111 | 111 | ||
112 | 리눅스 커널 개발은 끊임없이 빠른 속도로 이루어지고 있으며 결코 | 112 | 리눅스 커널 개발은 끊임없이 빠른 속도로 이루어지고 있으며 결코 |
113 | 느슨해진 적이 없다. 커널 개발자들이 현재 인터페이스들에서 버그를 | 113 | 느슨해진 적이 없다. 커널 개발자들이 현재 인터페이스들에서 버그를 |
114 | 발견하거나 무엇인가 할수 있는 더 좋은 방법을 찾게 되었다고 하자. | 114 | 발견하거나 무엇인가 할 수 있는 더 좋은 방법을 찾게 되었다고 하자. |
115 | 그들이 발견한 것을 실행한다면 아마도 더 잘 동작하도록 현재 인터페이스들을 | 115 | 그들이 발견한 것을 실행한다면 아마도 더 잘 동작하도록 현재 인터페이스들을 |
116 | 수정하게 될 것이다. 그들이 그런 일을 하게되면 함수 이름들은 변하게 되고, | 116 | 수정하게 될 것이다. 그들이 그런 일을 하게되면 함수 이름들은 변하게 되고, |
117 | 구조체들은 늘어나거나 줄어들게 되고, 함수 파라미터들은 재작업될 것이다. | 117 | 구조체들은 늘어나거나 줄어들게 되고, 함수 파라미터들은 재작업될 것이다. |
@@ -174,7 +174,7 @@ GPL을 따르는 배포 드라이버에 관해 얘기하고 있다는 것을 상 | |||
174 | 동작하는 것을 보장한다. | 174 | 동작하는 것을 보장한다. |
175 | 175 | ||
176 | 메인 커널 트리에 여러분의 드라이버를 반영하면 얻게 되는 장점들은 다음과 같다. | 176 | 메인 커널 트리에 여러분의 드라이버를 반영하면 얻게 되는 장점들은 다음과 같다. |
177 | - 관리 드는 비용(원래 개발자의)은 줄어줄면서 드라이버의 질은 향상될 것이다. | 177 | - 관리 드는 비용(원래 개발자의)은 줄어줄면서 드라이버의 질은 향상될 것이다. |
178 | - 다른 개발자들이 여러분의 드라이버에 기능들을 추가 할 것이다. | 178 | - 다른 개발자들이 여러분의 드라이버에 기능들을 추가 할 것이다. |
179 | - 다른 사람들은 여러분의 드라이버에 버그를 발견하고 수정할 것이다. | 179 | - 다른 사람들은 여러분의 드라이버에 버그를 발견하고 수정할 것이다. |
180 | - 다른 사람들은 여러분의 드라이버의 개선점을 찾을 줄 것이다. | 180 | - 다른 사람들은 여러분의 드라이버의 개선점을 찾을 줄 것이다. |
diff --git a/Documentation/laptops/asus-laptop.txt b/Documentation/laptops/asus-laptop.txt index 69f9fb3701e0..79a1bc675a8d 100644 --- a/Documentation/laptops/asus-laptop.txt +++ b/Documentation/laptops/asus-laptop.txt | |||
@@ -8,8 +8,8 @@ http://acpi4asus.sf.net/ | |||
8 | 8 | ||
9 | This driver provides support for extra features of ACPI-compatible ASUS laptops. | 9 | This driver provides support for extra features of ACPI-compatible ASUS laptops. |
10 | It may also support some MEDION, JVC or VICTOR laptops (such as MEDION 9675 or | 10 | It may also support some MEDION, JVC or VICTOR laptops (such as MEDION 9675 or |
11 | VICTOR XP7210 for example). It makes all the extra buttons generate standard | 11 | VICTOR XP7210 for example). It makes all the extra buttons generate input |
12 | ACPI events that go through /proc/acpi/events and input events (like keyboards). | 12 | events (like keyboards). |
13 | On some models adds support for changing the display brightness and output, | 13 | On some models adds support for changing the display brightness and output, |
14 | switching the LCD backlight on and off, and most importantly, allows you to | 14 | switching the LCD backlight on and off, and most importantly, allows you to |
15 | blink those fancy LEDs intended for reporting mail and wireless status. | 15 | blink those fancy LEDs intended for reporting mail and wireless status. |
@@ -55,8 +55,8 @@ Usage | |||
55 | DSDT) to me. | 55 | DSDT) to me. |
56 | 56 | ||
57 | That's all, now, all the events generated by the hotkeys of your laptop | 57 | That's all, now, all the events generated by the hotkeys of your laptop |
58 | should be reported in your /proc/acpi/event entry. You can check with | 58 | should be reported via netlink events. You can check with |
59 | "acpi_listen". | 59 | "acpi_genl monitor" (part of the acpica project). |
60 | 60 | ||
61 | Hotkeys are also reported as input keys (like keyboards) you can check | 61 | Hotkeys are also reported as input keys (like keyboards) you can check |
62 | which key are supported using "xev" under X11. | 62 | which key are supported using "xev" under X11. |
diff --git a/Documentation/laptops/sony-laptop.txt b/Documentation/laptops/sony-laptop.txt index 0d5ac7f5287e..978b1e615155 100644 --- a/Documentation/laptops/sony-laptop.txt +++ b/Documentation/laptops/sony-laptop.txt | |||
@@ -12,10 +12,10 @@ Fn keys (hotkeys): | |||
12 | ------------------ | 12 | ------------------ |
13 | Some models report hotkeys through the SNC or SPIC devices, such events are | 13 | Some models report hotkeys through the SNC or SPIC devices, such events are |
14 | reported both through the ACPI subsystem as acpi events and through the INPUT | 14 | reported both through the ACPI subsystem as acpi events and through the INPUT |
15 | subsystem. See the logs of acpid or /proc/acpi/event and | 15 | subsystem. See the logs of /proc/bus/input/devices to find out what those |
16 | /proc/bus/input/devices to find out what those events are and which input | 16 | events are and which input devices are created by the driver. |
17 | devices are created by the driver. Additionally, loading the driver with the | 17 | Additionally, loading the driver with the debug option will report all events |
18 | debug option will report all events in the kernel log. | 18 | in the kernel log. |
19 | 19 | ||
20 | The "scancodes" passed to the input system (that can be remapped with udev) | 20 | The "scancodes" passed to the input system (that can be remapped with udev) |
21 | are indexes to the table "sony_laptop_input_keycode_map" in the sony-laptop.c | 21 | are indexes to the table "sony_laptop_input_keycode_map" in the sony-laptop.c |
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index cf7bc6cb9719..86c52360ffe7 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt | |||
@@ -329,20 +329,6 @@ sysfs notes: | |||
329 | 329 | ||
330 | This attribute has poll()/select() support. | 330 | This attribute has poll()/select() support. |
331 | 331 | ||
332 | hotkey_report_mode: | ||
333 | Returns the state of the procfs ACPI event report mode | ||
334 | filter for hot keys. If it is set to 1 (the default), | ||
335 | all hot key presses are reported both through the input | ||
336 | layer and also as ACPI events through procfs (but not | ||
337 | through netlink). If it is set to 2, hot key presses | ||
338 | are reported only through the input layer. | ||
339 | |||
340 | This attribute is read-only in kernels 2.6.23 or later, | ||
341 | and read-write on earlier kernels. | ||
342 | |||
343 | May return -EPERM (write access locked out by module | ||
344 | parameter) or -EACCES (read-only). | ||
345 | |||
346 | wakeup_reason: | 332 | wakeup_reason: |
347 | Set to 1 if the system is waking up because the user | 333 | Set to 1 if the system is waking up because the user |
348 | requested a bay ejection. Set to 2 if the system is | 334 | requested a bay ejection. Set to 2 if the system is |
@@ -518,24 +504,21 @@ SW_TABLET_MODE Tablet ThinkPads HKEY events 0x5009 and 0x500A | |||
518 | Non hotkey ACPI HKEY event map: | 504 | Non hotkey ACPI HKEY event map: |
519 | ------------------------------- | 505 | ------------------------------- |
520 | 506 | ||
521 | Events that are not propagated by the driver, except for legacy | ||
522 | compatibility purposes when hotkey_report_mode is set to 1: | ||
523 | |||
524 | 0x5001 Lid closed | ||
525 | 0x5002 Lid opened | ||
526 | 0x5009 Tablet swivel: switched to tablet mode | ||
527 | 0x500A Tablet swivel: switched to normal mode | ||
528 | 0x7000 Radio Switch may have changed state | ||
529 | |||
530 | Events that are never propagated by the driver: | 507 | Events that are never propagated by the driver: |
531 | 508 | ||
532 | 0x2304 System is waking up from suspend to undock | 509 | 0x2304 System is waking up from suspend to undock |
533 | 0x2305 System is waking up from suspend to eject bay | 510 | 0x2305 System is waking up from suspend to eject bay |
534 | 0x2404 System is waking up from hibernation to undock | 511 | 0x2404 System is waking up from hibernation to undock |
535 | 0x2405 System is waking up from hibernation to eject bay | 512 | 0x2405 System is waking up from hibernation to eject bay |
513 | 0x5001 Lid closed | ||
514 | 0x5002 Lid opened | ||
515 | 0x5009 Tablet swivel: switched to tablet mode | ||
516 | 0x500A Tablet swivel: switched to normal mode | ||
536 | 0x5010 Brightness level changed/control event | 517 | 0x5010 Brightness level changed/control event |
537 | 0x6000 KEYBOARD: Numlock key pressed | 518 | 0x6000 KEYBOARD: Numlock key pressed |
538 | 0x6005 KEYBOARD: Fn key pressed (TO BE VERIFIED) | 519 | 0x6005 KEYBOARD: Fn key pressed (TO BE VERIFIED) |
520 | 0x7000 Radio Switch may have changed state | ||
521 | |||
539 | 522 | ||
540 | Events that are propagated by the driver to userspace: | 523 | Events that are propagated by the driver to userspace: |
541 | 524 | ||
@@ -574,50 +557,6 @@ operating system is to force either an immediate suspend or hibernate | |||
574 | cycle, or a system shutdown. Obviously, something is very wrong if this | 557 | cycle, or a system shutdown. Obviously, something is very wrong if this |
575 | happens. | 558 | happens. |
576 | 559 | ||
577 | Compatibility notes: | ||
578 | |||
579 | ibm-acpi and thinkpad-acpi 0.15 (mainline kernels before 2.6.23) never | ||
580 | supported the input layer, and sent events over the procfs ACPI event | ||
581 | interface. | ||
582 | |||
583 | To avoid sending duplicate events over the input layer and the ACPI | ||
584 | event interface, thinkpad-acpi 0.16 implements a module parameter | ||
585 | (hotkey_report_mode), and also a sysfs device attribute with the same | ||
586 | name. | ||
587 | |||
588 | Make no mistake here: userspace is expected to switch to using the input | ||
589 | layer interface of thinkpad-acpi, together with the ACPI netlink event | ||
590 | interface in kernels 2.6.23 and later, or with the ACPI procfs event | ||
591 | interface in kernels 2.6.22 and earlier. | ||
592 | |||
593 | If no hotkey_report_mode module parameter is specified (or it is set to | ||
594 | zero), the driver defaults to mode 1 (see below), and on kernels 2.6.22 | ||
595 | and earlier, also allows one to change the hotkey_report_mode through | ||
596 | sysfs. In kernels 2.6.23 and later, where the netlink ACPI event | ||
597 | interface is available, hotkey_report_mode cannot be changed through | ||
598 | sysfs (it is read-only). | ||
599 | |||
600 | If the hotkey_report_mode module parameter is set to 1 or 2, it cannot | ||
601 | be changed later through sysfs (any writes will return -EPERM to signal | ||
602 | that hotkey_report_mode was locked. On 2.6.23 and later, where | ||
603 | hotkey_report_mode cannot be changed at all, writes will return -EACCES). | ||
604 | |||
605 | hotkey_report_mode set to 1 makes the driver export through the procfs | ||
606 | ACPI event interface all hot key presses (which are *also* sent to the | ||
607 | input layer). This is a legacy compatibility behaviour, and it is also | ||
608 | the default mode of operation for the driver. | ||
609 | |||
610 | hotkey_report_mode set to 2 makes the driver filter out the hot key | ||
611 | presses from the procfs ACPI event interface, so these events will only | ||
612 | be sent through the input layer. Userspace that has been updated to use | ||
613 | the thinkpad-acpi input layer interface should set hotkey_report_mode to | ||
614 | 2. | ||
615 | |||
616 | Hot key press events are never sent to the ACPI netlink event interface. | ||
617 | Really up-to-date userspace under kernel 2.6.23 and later is to use the | ||
618 | netlink interface and the input layer interface, and don't bother at all | ||
619 | with hotkey_report_mode. | ||
620 | |||
621 | 560 | ||
622 | Brightness hotkey notes: | 561 | Brightness hotkey notes: |
623 | 562 | ||
diff --git a/Documentation/leds/leds-lm3556.txt b/Documentation/leds/leds-lm3556.txt index d9eb91b51913..62278e871b50 100644 --- a/Documentation/leds/leds-lm3556.txt +++ b/Documentation/leds/leds-lm3556.txt | |||
@@ -71,7 +71,7 @@ To register the chip at address 0x63 on specific adapter, set the platform data | |||
71 | according to include/linux/platform_data/leds-lm3556.h, set the i2c board info | 71 | according to include/linux/platform_data/leds-lm3556.h, set the i2c board info |
72 | 72 | ||
73 | Example: | 73 | Example: |
74 | static struct i2c_board_info __initdata board_i2c_ch4[] = { | 74 | static struct i2c_board_info board_i2c_ch4[] __initdata = { |
75 | { | 75 | { |
76 | I2C_BOARD_INFO(LM3556_NAME, 0x63), | 76 | I2C_BOARD_INFO(LM3556_NAME, 0x63), |
77 | .platform_data = &lm3556_pdata, | 77 | .platform_data = &lm3556_pdata, |
diff --git a/Documentation/leds/leds-lp3944.txt b/Documentation/leds/leds-lp3944.txt index c6eda18b15ef..e88ac3b60c08 100644 --- a/Documentation/leds/leds-lp3944.txt +++ b/Documentation/leds/leds-lp3944.txt | |||
@@ -37,7 +37,7 @@ registered using the i2c_board_info mechanism. | |||
37 | To register the chip at address 0x60 on adapter 0, set the platform data | 37 | To register the chip at address 0x60 on adapter 0, set the platform data |
38 | according to include/linux/leds-lp3944.h, set the i2c board info: | 38 | according to include/linux/leds-lp3944.h, set the i2c board info: |
39 | 39 | ||
40 | static struct i2c_board_info __initdata a910_i2c_board_info[] = { | 40 | static struct i2c_board_info a910_i2c_board_info[] __initdata = { |
41 | { | 41 | { |
42 | I2C_BOARD_INFO("lp3944", 0x60), | 42 | I2C_BOARD_INFO("lp3944", 0x60), |
43 | .platform_data = &a910_lp3944_leds, | 43 | .platform_data = &a910_lp3944_leds, |
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index fa5d8a9ae205..c8c42e64e953 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt | |||
@@ -531,9 +531,10 @@ dependency barrier to make it work correctly. Consider the following bit of | |||
531 | code: | 531 | code: |
532 | 532 | ||
533 | q = &a; | 533 | q = &a; |
534 | if (p) | 534 | if (p) { |
535 | <data dependency barrier> | ||
535 | q = &b; | 536 | q = &b; |
536 | <data dependency barrier> | 537 | } |
537 | x = *q; | 538 | x = *q; |
538 | 539 | ||
539 | This will not have the desired effect because there is no actual data | 540 | This will not have the desired effect because there is no actual data |
@@ -542,9 +543,10 @@ attempting to predict the outcome in advance. In such a case what's actually | |||
542 | required is: | 543 | required is: |
543 | 544 | ||
544 | q = &a; | 545 | q = &a; |
545 | if (p) | 546 | if (p) { |
547 | <read barrier> | ||
546 | q = &b; | 548 | q = &b; |
547 | <read barrier> | 549 | } |
548 | x = *q; | 550 | x = *q; |
549 | 551 | ||
550 | 552 | ||
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 8e5eacbdcfa3..58340d50f8a6 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt | |||
@@ -163,7 +163,7 @@ a recent addition and not present on older kernels. | |||
163 | at read: contains online/offline state of memory. | 163 | at read: contains online/offline state of memory. |
164 | at write: user can specify "online_kernel", | 164 | at write: user can specify "online_kernel", |
165 | "online_movable", "online", "offline" command | 165 | "online_movable", "online", "offline" command |
166 | which will be performed on al sections in the block. | 166 | which will be performed on all sections in the block. |
167 | 'phys_device' : read-only: designed to show the name of physical memory | 167 | 'phys_device' : read-only: designed to show the name of physical memory |
168 | device. This is not well implemented now. | 168 | device. This is not well implemented now. |
169 | 'removable' : read-only: contains an integer value indicating | 169 | 'removable' : read-only: contains an integer value indicating |
@@ -210,13 +210,15 @@ If memory device is found, memory hotplug code will be called. | |||
210 | 210 | ||
211 | 4.2 Notify memory hot-add event by hand | 211 | 4.2 Notify memory hot-add event by hand |
212 | ------------ | 212 | ------------ |
213 | In some environments, especially virtualized environment, firmware will not | 213 | On powerpc, the firmware does not notify a memory hotplug event to the kernel. |
214 | notify memory hotplug event to the kernel. For such environment, "probe" | 214 | Therefore, "probe" interface is supported to notify the event to the kernel. |
215 | interface is supported. This interface depends on CONFIG_ARCH_MEMORY_PROBE. | 215 | This interface depends on CONFIG_ARCH_MEMORY_PROBE. |
216 | 216 | ||
217 | Now, CONFIG_ARCH_MEMORY_PROBE is supported only by powerpc but it does not | 217 | CONFIG_ARCH_MEMORY_PROBE is supported on powerpc only. On x86, this config |
218 | contain highly architecture codes. Please add config if you need "probe" | 218 | option is disabled by default since ACPI notifies a memory hotplug event to |
219 | interface. | 219 | the kernel, which performs its hotplug operation as the result. Please |
220 | enable this option if you need the "probe" interface for testing purposes | ||
221 | on x86. | ||
220 | 222 | ||
221 | Probe interface is located at | 223 | Probe interface is located at |
222 | /sys/devices/system/memory/probe | 224 | /sys/devices/system/memory/probe |
diff --git a/Documentation/mtd/nand_ecc.txt b/Documentation/mtd/nand_ecc.txt index 990efd7a9818..e129b2479ea8 100644 --- a/Documentation/mtd/nand_ecc.txt +++ b/Documentation/mtd/nand_ecc.txt | |||
@@ -543,7 +543,7 @@ THe code within the for loop was changed to: | |||
543 | } | 543 | } |
544 | 544 | ||
545 | As you can see tmppar is used to accumulate the parity within a for | 545 | As you can see tmppar is used to accumulate the parity within a for |
546 | iteration. In the last 3 statements is is added to par and, if needed, | 546 | iteration. In the last 3 statements is added to par and, if needed, |
547 | to rp12 and rp14. | 547 | to rp12 and rp14. |
548 | 548 | ||
549 | While making the changes I also found that I could exploit that tmppar | 549 | While making the changes I also found that I could exploit that tmppar |
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 32dfbd924121..18b64b2b8a68 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX | |||
@@ -124,6 +124,8 @@ multiqueue.txt | |||
124 | - HOWTO for multiqueue network device support. | 124 | - HOWTO for multiqueue network device support. |
125 | netconsole.txt | 125 | netconsole.txt |
126 | - The network console module netconsole.ko: configuration and notes. | 126 | - The network console module netconsole.ko: configuration and notes. |
127 | netdev-FAQ.txt | ||
128 | - FAQ describing how to submit net changes to netdev mailing list. | ||
127 | netdev-features.txt | 129 | netdev-features.txt |
128 | - Network interface features API description. | 130 | - Network interface features API description. |
129 | netdevices.txt | 131 | netdevices.txt |
diff --git a/Documentation/networking/e100.txt b/Documentation/networking/e100.txt index fcb6c71cdb69..13a32124bca0 100644 --- a/Documentation/networking/e100.txt +++ b/Documentation/networking/e100.txt | |||
@@ -1,7 +1,7 @@ | |||
1 | Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters | 1 | Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters |
2 | ============================================================== | 2 | ============================================================== |
3 | 3 | ||
4 | November 15, 2005 | 4 | March 15, 2011 |
5 | 5 | ||
6 | Contents | 6 | Contents |
7 | ======== | 7 | ======== |
@@ -122,7 +122,7 @@ Additional Configurations | |||
122 | NOTE: This setting is not saved across reboots. | 122 | NOTE: This setting is not saved across reboots. |
123 | 123 | ||
124 | 124 | ||
125 | Ethtool | 125 | ethtool |
126 | ------- | 126 | ------- |
127 | 127 | ||
128 | The driver utilizes the ethtool interface for driver configuration and | 128 | The driver utilizes the ethtool interface for driver configuration and |
diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt index 71ca95855671..437b2099cced 100644 --- a/Documentation/networking/e1000.txt +++ b/Documentation/networking/e1000.txt | |||
@@ -1,8 +1,8 @@ | |||
1 | Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters | 1 | Linux* Base Driver for Intel(R) Ethernet Network Connection |
2 | =============================================================== | 2 | =========================================================== |
3 | 3 | ||
4 | Intel Gigabit Linux driver. | 4 | Intel Gigabit Linux driver. |
5 | Copyright(c) 1999 - 2010 Intel Corporation. | 5 | Copyright(c) 1999 - 2013 Intel Corporation. |
6 | 6 | ||
7 | Contents | 7 | Contents |
8 | ======== | 8 | ======== |
@@ -420,15 +420,15 @@ Additional Configurations | |||
420 | - The maximum MTU setting for Jumbo Frames is 16110. This value coincides | 420 | - The maximum MTU setting for Jumbo Frames is 16110. This value coincides |
421 | with the maximum Jumbo Frames size of 16128. | 421 | with the maximum Jumbo Frames size of 16128. |
422 | 422 | ||
423 | - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or | 423 | - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in |
424 | loss of link. | 424 | poor performance or loss of link. |
425 | 425 | ||
426 | - Adapters based on the Intel(R) 82542 and 82573V/E controller do not | 426 | - Adapters based on the Intel(R) 82542 and 82573V/E controller do not |
427 | support Jumbo Frames. These correspond to the following product names: | 427 | support Jumbo Frames. These correspond to the following product names: |
428 | Intel(R) PRO/1000 Gigabit Server Adapter | 428 | Intel(R) PRO/1000 Gigabit Server Adapter |
429 | Intel(R) PRO/1000 PM Network Connection | 429 | Intel(R) PRO/1000 PM Network Connection |
430 | 430 | ||
431 | Ethtool | 431 | ethtool |
432 | ------- | 432 | ------- |
433 | The driver utilizes the ethtool interface for driver configuration and | 433 | The driver utilizes the ethtool interface for driver configuration and |
434 | diagnostics, as well as displaying statistical information. The ethtool | 434 | diagnostics, as well as displaying statistical information. The ethtool |
diff --git a/Documentation/networking/e1000e.txt b/Documentation/networking/e1000e.txt index 97b5ba942ebf..ad2d9f38ce14 100644 --- a/Documentation/networking/e1000e.txt +++ b/Documentation/networking/e1000e.txt | |||
@@ -1,8 +1,8 @@ | |||
1 | Linux* Driver for Intel(R) Network Connection | 1 | Linux* Driver for Intel(R) Ethernet Network Connection |
2 | ============================================= | 2 | ====================================================== |
3 | 3 | ||
4 | Intel Gigabit Linux driver. | 4 | Intel Gigabit Linux driver. |
5 | Copyright(c) 1999 - 2010 Intel Corporation. | 5 | Copyright(c) 1999 - 2013 Intel Corporation. |
6 | 6 | ||
7 | Contents | 7 | Contents |
8 | ======== | 8 | ======== |
@@ -259,13 +259,16 @@ Additional Configurations | |||
259 | - The maximum MTU setting for Jumbo Frames is 9216. This value coincides | 259 | - The maximum MTU setting for Jumbo Frames is 9216. This value coincides |
260 | with the maximum Jumbo Frames size of 9234 bytes. | 260 | with the maximum Jumbo Frames size of 9234 bytes. |
261 | 261 | ||
262 | - Using Jumbo Frames at 10 or 100 Mbps is not supported and may result in | 262 | - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in |
263 | poor performance or loss of link. | 263 | poor performance or loss of link. |
264 | 264 | ||
265 | - Some adapters limit Jumbo Frames sized packets to a maximum of | 265 | - Some adapters limit Jumbo Frames sized packets to a maximum of |
266 | 4096 bytes and some adapters do not support Jumbo Frames. | 266 | 4096 bytes and some adapters do not support Jumbo Frames. |
267 | 267 | ||
268 | Ethtool | 268 | - Jumbo Frames cannot be configured on an 82579-based Network device, if |
269 | MACSec is enabled on the system. | ||
270 | |||
271 | ethtool | ||
269 | ------- | 272 | ------- |
270 | The driver utilizes the ethtool interface for driver configuration and | 273 | The driver utilizes the ethtool interface for driver configuration and |
271 | diagnostics, as well as displaying statistical information. We | 274 | diagnostics, as well as displaying statistical information. We |
@@ -273,6 +276,9 @@ Additional Configurations | |||
273 | 276 | ||
274 | http://ftp.kernel.org/pub/software/network/ethtool/ | 277 | http://ftp.kernel.org/pub/software/network/ethtool/ |
275 | 278 | ||
279 | NOTE: When validating enable/disable tests on some parts (82578, for example) | ||
280 | you need to add a few seconds between tests when working with ethtool. | ||
281 | |||
276 | Speed and Duplex | 282 | Speed and Duplex |
277 | ---------------- | 283 | ---------------- |
278 | Speed and Duplex are configured through the ethtool* utility. For | 284 | Speed and Duplex are configured through the ethtool* utility. For |
diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt index 9a2a037194a5..4ebbd659256f 100644 --- a/Documentation/networking/igb.txt +++ b/Documentation/networking/igb.txt | |||
@@ -1,8 +1,8 @@ | |||
1 | Linux* Base Driver for Intel(R) Network Connection | 1 | Linux* Base Driver for Intel(R) Ethernet Network Connection |
2 | ================================================== | 2 | =========================================================== |
3 | 3 | ||
4 | Intel Gigabit Linux driver. | 4 | Intel Gigabit Linux driver. |
5 | Copyright(c) 1999 - 2010 Intel Corporation. | 5 | Copyright(c) 1999 - 2013 Intel Corporation. |
6 | 6 | ||
7 | Contents | 7 | Contents |
8 | ======== | 8 | ======== |
@@ -36,6 +36,53 @@ Default Value: 0 | |||
36 | This parameter adds support for SR-IOV. It causes the driver to spawn up to | 36 | This parameter adds support for SR-IOV. It causes the driver to spawn up to |
37 | max_vfs worth of virtual function. | 37 | max_vfs worth of virtual function. |
38 | 38 | ||
39 | QueuePairs | ||
40 | ---------- | ||
41 | Valid Range: 0-1 | ||
42 | Default Value: 1 (TX and RX will be paired onto one interrupt vector) | ||
43 | |||
44 | If set to 0, when MSI-X is enabled, the TX and RX will attempt to occupy | ||
45 | separate vectors. | ||
46 | |||
47 | This option can be overridden to 1 if there are not sufficient interrupts | ||
48 | available. This can occur if any combination of RSS, VMDQ, and max_vfs | ||
49 | results in more than 4 queues being used. | ||
50 | |||
51 | Node | ||
52 | ---- | ||
53 | Valid Range: 0-n | ||
54 | Default Value: -1 (off) | ||
55 | |||
56 | 0 - n: where n is the number of the NUMA node that should be used to | ||
57 | allocate memory for this adapter port. | ||
58 | -1: uses the driver default of allocating memory on whichever processor is | ||
59 | running insmod/modprobe. | ||
60 | |||
61 | The Node parameter will allow you to pick which NUMA node you want to have | ||
62 | the adapter allocate memory from. All driver structures, in-memory queues, | ||
63 | and receive buffers will be allocated on the node specified. This parameter | ||
64 | is only useful when interrupt affinity is specified, otherwise some portion | ||
65 | of the time the interrupt could run on a different core than the memory is | ||
66 | allocated on, causing slower memory access and impacting throughput, CPU, or | ||
67 | both. | ||
68 | |||
69 | EEE | ||
70 | --- | ||
71 | Valid Range: 0-1 | ||
72 | Default Value: 1 (enabled) | ||
73 | |||
74 | A link between two EEE-compliant devices will result in periodic bursts of | ||
75 | data followed by long periods where in the link is in an idle state. This Low | ||
76 | Power Idle (LPI) state is supported in both 1Gbps and 100Mbps link speeds. | ||
77 | NOTE: EEE support requires autonegotiation. | ||
78 | |||
79 | DMAC | ||
80 | ---- | ||
81 | Valid Range: 0-1 | ||
82 | Default Value: 1 (enabled) | ||
83 | Enables or disables DMA Coalescing feature. | ||
84 | |||
85 | |||
39 | 86 | ||
40 | Additional Configurations | 87 | Additional Configurations |
41 | ========================= | 88 | ========================= |
@@ -55,10 +102,10 @@ Additional Configurations | |||
55 | - The maximum MTU setting for Jumbo Frames is 9216. This value coincides | 102 | - The maximum MTU setting for Jumbo Frames is 9216. This value coincides |
56 | with the maximum Jumbo Frames size of 9234 bytes. | 103 | with the maximum Jumbo Frames size of 9234 bytes. |
57 | 104 | ||
58 | - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or | 105 | - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in |
59 | loss of link. | 106 | poor performance or loss of link. |
60 | 107 | ||
61 | Ethtool | 108 | ethtool |
62 | ------- | 109 | ------- |
63 | The driver utilizes the ethtool interface for driver configuration and | 110 | The driver utilizes the ethtool interface for driver configuration and |
64 | diagnostics, as well as displaying statistical information. The latest | 111 | diagnostics, as well as displaying statistical information. The latest |
@@ -106,6 +153,14 @@ Additional Configurations | |||
106 | 153 | ||
107 | Where n=the VF that attempted to do the spoofing. | 154 | Where n=the VF that attempted to do the spoofing. |
108 | 155 | ||
156 | Setting MAC Address, VLAN and Rate Limit Using IProute2 Tool | ||
157 | ------------------------------------------------------------ | ||
158 | You can set a MAC address of a Virtual Function (VF), a default VLAN and the | ||
159 | rate limit using the IProute2 tool. Download the latest version of the | ||
160 | iproute2 tool from Sourceforge if your version does not have all the | ||
161 | features you require. | ||
162 | |||
163 | |||
109 | Support | 164 | Support |
110 | ======= | 165 | ======= |
111 | 166 | ||
diff --git a/Documentation/networking/igbvf.txt b/Documentation/networking/igbvf.txt index cbfe4ee65533..40db17a6665b 100644 --- a/Documentation/networking/igbvf.txt +++ b/Documentation/networking/igbvf.txt | |||
@@ -1,8 +1,8 @@ | |||
1 | Linux* Base Driver for Intel(R) Network Connection | 1 | Linux* Base Driver for Intel(R) Ethernet Network Connection |
2 | ================================================== | 2 | =========================================================== |
3 | 3 | ||
4 | Intel Gigabit Linux driver. | 4 | Intel Gigabit Linux driver. |
5 | Copyright(c) 1999 - 2010 Intel Corporation. | 5 | Copyright(c) 1999 - 2013 Intel Corporation. |
6 | 6 | ||
7 | Contents | 7 | Contents |
8 | ======== | 8 | ======== |
@@ -55,7 +55,7 @@ networking link on the left to search for your adapter: | |||
55 | Additional Configurations | 55 | Additional Configurations |
56 | ========================= | 56 | ========================= |
57 | 57 | ||
58 | Ethtool | 58 | ethtool |
59 | ------- | 59 | ------- |
60 | The driver utilizes the ethtool interface for driver configuration and | 60 | The driver utilizes the ethtool interface for driver configuration and |
61 | diagnostics, as well as displaying statistical information. The ethtool | 61 | diagnostics, as well as displaying statistical information. The ethtool |
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 10742902146f..a46d78583ae1 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt | |||
@@ -440,6 +440,10 @@ tcp_syncookies - BOOLEAN | |||
440 | SYN flood warnings in logs not being really flooded, your server | 440 | SYN flood warnings in logs not being really flooded, your server |
441 | is seriously misconfigured. | 441 | is seriously misconfigured. |
442 | 442 | ||
443 | If you want to test which effects syncookies have to your | ||
444 | network connections you can set this knob to 2 to enable | ||
445 | unconditionally generation of syncookies. | ||
446 | |||
443 | tcp_fastopen - INTEGER | 447 | tcp_fastopen - INTEGER |
444 | Enable TCP Fast Open feature (draft-ietf-tcpm-fastopen) to send data | 448 | Enable TCP Fast Open feature (draft-ietf-tcpm-fastopen) to send data |
445 | in the opening SYN packet. To use this feature, the client application | 449 | in the opening SYN packet. To use this feature, the client application |
@@ -478,6 +482,15 @@ tcp_syn_retries - INTEGER | |||
478 | tcp_timestamps - BOOLEAN | 482 | tcp_timestamps - BOOLEAN |
479 | Enable timestamps as defined in RFC1323. | 483 | Enable timestamps as defined in RFC1323. |
480 | 484 | ||
485 | tcp_min_tso_segs - INTEGER | ||
486 | Minimal number of segments per TSO frame. | ||
487 | Since linux-3.12, TCP does an automatic sizing of TSO frames, | ||
488 | depending on flow rate, instead of filling 64Kbytes packets. | ||
489 | For specific usages, it's possible to force TCP to build big | ||
490 | TSO frames. Note that TCP stack might split too big TSO packets | ||
491 | if available window is too small. | ||
492 | Default: 2 | ||
493 | |||
481 | tcp_tso_win_divisor - INTEGER | 494 | tcp_tso_win_divisor - INTEGER |
482 | This allows control over what percentage of the congestion window | 495 | This allows control over what percentage of the congestion window |
483 | can be consumed by a single TSO frame. | 496 | can be consumed by a single TSO frame. |
@@ -516,6 +529,19 @@ tcp_wmem - vector of 3 INTEGERs: min, default, max | |||
516 | this value is ignored. | 529 | this value is ignored. |
517 | Default: between 64K and 4MB, depending on RAM size. | 530 | Default: between 64K and 4MB, depending on RAM size. |
518 | 531 | ||
532 | tcp_notsent_lowat - UNSIGNED INTEGER | ||
533 | A TCP socket can control the amount of unsent bytes in its write queue, | ||
534 | thanks to TCP_NOTSENT_LOWAT socket option. poll()/select()/epoll() | ||
535 | reports POLLOUT events if the amount of unsent bytes is below a per | ||
536 | socket value, and if the write queue is not full. sendmsg() will | ||
537 | also not add new buffers if the limit is hit. | ||
538 | |||
539 | This global variable controls the amount of unsent data for | ||
540 | sockets not using TCP_NOTSENT_LOWAT. For these sockets, a change | ||
541 | to the global variable has immediate effect. | ||
542 | |||
543 | Default: UINT_MAX (0xFFFFFFFF) | ||
544 | |||
519 | tcp_workaround_signed_windows - BOOLEAN | 545 | tcp_workaround_signed_windows - BOOLEAN |
520 | If set, assume no receipt of a window scaling option means the | 546 | If set, assume no receipt of a window scaling option means the |
521 | remote TCP is broken and treats the window as a signed quantity. | 547 | remote TCP is broken and treats the window as a signed quantity. |
@@ -1022,7 +1048,15 @@ disable_policy - BOOLEAN | |||
1022 | disable_xfrm - BOOLEAN | 1048 | disable_xfrm - BOOLEAN |
1023 | Disable IPSEC encryption on this interface, whatever the policy | 1049 | Disable IPSEC encryption on this interface, whatever the policy |
1024 | 1050 | ||
1051 | igmpv2_unsolicited_report_interval - INTEGER | ||
1052 | The interval in milliseconds in which the next unsolicited | ||
1053 | IGMPv1 or IGMPv2 report retransmit will take place. | ||
1054 | Default: 10000 (10 seconds) | ||
1025 | 1055 | ||
1056 | igmpv3_unsolicited_report_interval - INTEGER | ||
1057 | The interval in milliseconds in which the next unsolicited | ||
1058 | IGMPv3 report retransmit will take place. | ||
1059 | Default: 1000 (1 seconds) | ||
1026 | 1060 | ||
1027 | tag - INTEGER | 1061 | tag - INTEGER |
1028 | Allows you to write a number, which can be used as required. | 1062 | Allows you to write a number, which can be used as required. |
@@ -1314,6 +1348,27 @@ ndisc_notify - BOOLEAN | |||
1314 | 1 - Generate unsolicited neighbour advertisements when device is brought | 1348 | 1 - Generate unsolicited neighbour advertisements when device is brought |
1315 | up or hardware address changes. | 1349 | up or hardware address changes. |
1316 | 1350 | ||
1351 | mldv1_unsolicited_report_interval - INTEGER | ||
1352 | The interval in milliseconds in which the next unsolicited | ||
1353 | MLDv1 report retransmit will take place. | ||
1354 | Default: 10000 (10 seconds) | ||
1355 | |||
1356 | mldv2_unsolicited_report_interval - INTEGER | ||
1357 | The interval in milliseconds in which the next unsolicited | ||
1358 | MLDv2 report retransmit will take place. | ||
1359 | Default: 1000 (1 second) | ||
1360 | |||
1361 | force_mld_version - INTEGER | ||
1362 | 0 - (default) No enforcement of a MLD version, MLDv1 fallback allowed | ||
1363 | 1 - Enforce to use MLD version 1 | ||
1364 | 2 - Enforce to use MLD version 2 | ||
1365 | |||
1366 | suppress_frag_ndisc - INTEGER | ||
1367 | Control RFC 6980 (Security Implications of IPv6 Fragmentation | ||
1368 | with IPv6 Neighbor Discovery) behavior: | ||
1369 | 1 - (default) discard fragmented neighbor discovery packets | ||
1370 | 0 - allow fragmented neighbor discovery packets | ||
1371 | |||
1317 | icmp/*: | 1372 | icmp/*: |
1318 | ratelimit - INTEGER | 1373 | ratelimit - INTEGER |
1319 | Limit the maximal rates for sending ICMPv6 packets. | 1374 | Limit the maximal rates for sending ICMPv6 packets. |
diff --git a/Documentation/networking/ixgb.txt b/Documentation/networking/ixgb.txt index d75a1f9565bb..1e0c045e89f7 100644 --- a/Documentation/networking/ixgb.txt +++ b/Documentation/networking/ixgb.txt | |||
@@ -1,7 +1,7 @@ | |||
1 | Linux Base Driver for 10 Gigabit Intel(R) Network Connection | 1 | Linux Base Driver for 10 Gigabit Intel(R) Ethernet Network Connection |
2 | ============================================================= | 2 | ===================================================================== |
3 | 3 | ||
4 | October 9, 2007 | 4 | March 14, 2011 |
5 | 5 | ||
6 | 6 | ||
7 | Contents | 7 | Contents |
@@ -274,9 +274,9 @@ Additional Configurations | |||
274 | ------------------------------------------------- | 274 | ------------------------------------------------- |
275 | Configuring a network driver to load properly when the system is started is | 275 | Configuring a network driver to load properly when the system is started is |
276 | distribution dependent. Typically, the configuration process involves adding | 276 | distribution dependent. Typically, the configuration process involves adding |
277 | an alias line to files in /etc/modprobe.d/ as well as editing other system | 277 | an alias line to /etc/modprobe.conf as well as editing other system startup |
278 | startup scripts and/or configuration files. Many popular Linux distributions | 278 | scripts and/or configuration files. Many popular Linux distributions ship |
279 | ship with tools to make these changes for you. To learn the proper way to | 279 | with tools to make these changes for you. To learn the proper way to |
280 | configure a network device for your system, refer to your distribution | 280 | configure a network device for your system, refer to your distribution |
281 | documentation. If during this process you are asked for the driver or module | 281 | documentation. If during this process you are asked for the driver or module |
282 | name, the name for the Linux Base Driver for the Intel 10GbE Family of | 282 | name, the name for the Linux Base Driver for the Intel 10GbE Family of |
@@ -306,7 +306,7 @@ Additional Configurations | |||
306 | with the maximum Jumbo Frames size of 16128. | 306 | with the maximum Jumbo Frames size of 16128. |
307 | 307 | ||
308 | 308 | ||
309 | Ethtool | 309 | ethtool |
310 | ------- | 310 | ------- |
311 | The driver utilizes the ethtool interface for driver configuration and | 311 | The driver utilizes the ethtool interface for driver configuration and |
312 | diagnostics, as well as displaying statistical information. The ethtool | 312 | diagnostics, as well as displaying statistical information. The ethtool |
diff --git a/Documentation/networking/ixgbe.txt b/Documentation/networking/ixgbe.txt index af77ed3c4172..96cccebb839b 100644 --- a/Documentation/networking/ixgbe.txt +++ b/Documentation/networking/ixgbe.txt | |||
@@ -1,8 +1,9 @@ | |||
1 | Linux Base Driver for 10 Gigabit PCI Express Intel(R) Network Connection | 1 | Linux* Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Family of |
2 | ======================================================================== | 2 | Adapters |
3 | ============================================================================= | ||
3 | 4 | ||
4 | Intel Gigabit Linux driver. | 5 | Intel 10 Gigabit Linux driver. |
5 | Copyright(c) 1999 - 2010 Intel Corporation. | 6 | Copyright(c) 1999 - 2013 Intel Corporation. |
6 | 7 | ||
7 | Contents | 8 | Contents |
8 | ======== | 9 | ======== |
@@ -16,8 +17,8 @@ Contents | |||
16 | Identifying Your Adapter | 17 | Identifying Your Adapter |
17 | ======================== | 18 | ======================== |
18 | 19 | ||
19 | The driver in this release is compatible with 82598 and 82599-based Intel | 20 | The driver in this release is compatible with 82598, 82599 and X540-based |
20 | Network Connections. | 21 | Intel Network Connections. |
21 | 22 | ||
22 | For more information on how to identify your adapter, go to the Adapter & | 23 | For more information on how to identify your adapter, go to the Adapter & |
23 | Driver ID Guide at: | 24 | Driver ID Guide at: |
@@ -72,7 +73,7 @@ cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. | |||
72 | Laser turns off for SFP+ when ifconfig down | 73 | Laser turns off for SFP+ when ifconfig down |
73 | ------------------------------------------- | 74 | ------------------------------------------- |
74 | "ifconfig down" turns off the laser for 82599-based SFP+ fiber adapters. | 75 | "ifconfig down" turns off the laser for 82599-based SFP+ fiber adapters. |
75 | "ifconfig up" turns on the later. | 76 | "ifconfig up" turns on the laser. |
76 | 77 | ||
77 | 78 | ||
78 | 82598-BASED ADAPTERS | 79 | 82598-BASED ADAPTERS |
@@ -118,6 +119,93 @@ NOTE: For 82598 backplane cards entering 1 gig mode, flow control default | |||
118 | behavior is changed to off. Flow control in 1 gig mode on these devices can | 119 | behavior is changed to off. Flow control in 1 gig mode on these devices can |
119 | lead to Tx hangs. | 120 | lead to Tx hangs. |
120 | 121 | ||
122 | Intel(R) Ethernet Flow Director | ||
123 | ------------------------------- | ||
124 | Supports advanced filters that direct receive packets by their flows to | ||
125 | different queues. Enables tight control on routing a flow in the platform. | ||
126 | Matches flows and CPU cores for flow affinity. Supports multiple parameters | ||
127 | for flexible flow classification and load balancing. | ||
128 | |||
129 | Flow director is enabled only if the kernel is multiple TX queue capable. | ||
130 | |||
131 | An included script (set_irq_affinity.sh) automates setting the IRQ to CPU | ||
132 | affinity. | ||
133 | |||
134 | You can verify that the driver is using Flow Director by looking at the counter | ||
135 | in ethtool: fdir_miss and fdir_match. | ||
136 | |||
137 | Other ethtool Commands: | ||
138 | To enable Flow Director | ||
139 | ethtool -K ethX ntuple on | ||
140 | To add a filter | ||
141 | Use -U switch. e.g., ethtool -U ethX flow-type tcp4 src-ip 0x178000a | ||
142 | action 1 | ||
143 | To see the list of filters currently present: | ||
144 | ethtool -u ethX | ||
145 | |||
146 | Perfect Filter: Perfect filter is an interface to load the filter table that | ||
147 | funnels all flow into queue_0 unless an alternative queue is specified using | ||
148 | "action". In that case, any flow that matches the filter criteria will be | ||
149 | directed to the appropriate queue. | ||
150 | |||
151 | If the queue is defined as -1, filter will drop matching packets. | ||
152 | |||
153 | To account for filter matches and misses, there are two stats in ethtool: | ||
154 | fdir_match and fdir_miss. In addition, rx_queue_N_packets shows the number of | ||
155 | packets processed by the Nth queue. | ||
156 | |||
157 | NOTE: Receive Packet Steering (RPS) and Receive Flow Steering (RFS) are not | ||
158 | compatible with Flow Director. IF Flow Director is enabled, these will be | ||
159 | disabled. | ||
160 | |||
161 | The following three parameters impact Flow Director. | ||
162 | |||
163 | FdirMode | ||
164 | -------- | ||
165 | Valid Range: 0-2 (0=off, 1=ATR, 2=Perfect filter mode) | ||
166 | Default Value: 1 | ||
167 | |||
168 | Flow Director filtering modes. | ||
169 | |||
170 | FdirPballoc | ||
171 | ----------- | ||
172 | Valid Range: 0-2 (0=64k, 1=128k, 2=256k) | ||
173 | Default Value: 0 | ||
174 | |||
175 | Flow Director allocated packet buffer size. | ||
176 | |||
177 | AtrSampleRate | ||
178 | -------------- | ||
179 | Valid Range: 1-100 | ||
180 | Default Value: 20 | ||
181 | |||
182 | Software ATR Tx packet sample rate. For example, when set to 20, every 20th | ||
183 | packet, looks to see if the packet will create a new flow. | ||
184 | |||
185 | Node | ||
186 | ---- | ||
187 | Valid Range: 0-n | ||
188 | Default Value: 1 (off) | ||
189 | |||
190 | 0 - n: where n is the number of NUMA nodes (i.e. 0 - 3) currently online in | ||
191 | your system | ||
192 | 1: turns this option off | ||
193 | |||
194 | The Node parameter will allow you to pick which NUMA node you want to have | ||
195 | the adapter allocate memory on. | ||
196 | |||
197 | max_vfs | ||
198 | ------- | ||
199 | Valid Range: 1-63 | ||
200 | Default Value: 0 | ||
201 | |||
202 | If the value is greater than 0 it will also force the VMDq parameter to be 1 | ||
203 | or more. | ||
204 | |||
205 | This parameter adds support for SR-IOV. It causes the driver to spawn up to | ||
206 | max_vfs worth of virtual function. | ||
207 | |||
208 | |||
121 | Additional Configurations | 209 | Additional Configurations |
122 | ========================= | 210 | ========================= |
123 | 211 | ||
@@ -221,9 +309,10 @@ http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf | |||
221 | Known Issues | 309 | Known Issues |
222 | ============ | 310 | ============ |
223 | 311 | ||
224 | Enabling SR-IOV in a 32-bit Microsoft* Windows* Server 2008 Guest OS using | 312 | Enabling SR-IOV in a 32-bit or 64-bit Microsoft* Windows* Server 2008/R2 |
225 | Intel (R) 82576-based GbE or Intel (R) 82599-based 10GbE controller under KVM | 313 | Guest OS using Intel (R) 82576-based GbE or Intel (R) 82599-based 10GbE |
226 | ----------------------------------------------------------------------------- | 314 | controller under KVM |
315 | ------------------------------------------------------------------------ | ||
227 | KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This | 316 | KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This |
228 | includes traditional PCIe devices, as well as SR-IOV-capable devices using | 317 | includes traditional PCIe devices, as well as SR-IOV-capable devices using |
229 | Intel 82576-based and 82599-based controllers. | 318 | Intel 82576-based and 82599-based controllers. |
diff --git a/Documentation/networking/ixgbevf.txt b/Documentation/networking/ixgbevf.txt index 5a91a41fa946..53d8d2a5a6a3 100644 --- a/Documentation/networking/ixgbevf.txt +++ b/Documentation/networking/ixgbevf.txt | |||
@@ -1,8 +1,8 @@ | |||
1 | Linux* Base Driver for Intel(R) Network Connection | 1 | Linux* Base Driver for Intel(R) Ethernet Network Connection |
2 | ================================================== | 2 | =========================================================== |
3 | 3 | ||
4 | Intel Gigabit Linux driver. | 4 | Intel Gigabit Linux driver. |
5 | Copyright(c) 1999 - 2010 Intel Corporation. | 5 | Copyright(c) 1999 - 2013 Intel Corporation. |
6 | 6 | ||
7 | Contents | 7 | Contents |
8 | ======== | 8 | ======== |
diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt new file mode 100644 index 000000000000..d9112f01c44a --- /dev/null +++ b/Documentation/networking/netdev-FAQ.txt | |||
@@ -0,0 +1,224 @@ | |||
1 | |||
2 | Information you need to know about netdev | ||
3 | ----------------------------------------- | ||
4 | |||
5 | Q: What is netdev? | ||
6 | |||
7 | A: It is a mailing list for all network related linux stuff. This includes | ||
8 | anything found under net/ (i.e. core code like IPv6) and drivers/net | ||
9 | (i.e. hardware specific drivers) in the linux source tree. | ||
10 | |||
11 | Note that some subsystems (e.g. wireless drivers) which have a high volume | ||
12 | of traffic have their own specific mailing lists. | ||
13 | |||
14 | The netdev list is managed (like many other linux mailing lists) through | ||
15 | VGER ( http://vger.kernel.org/ ) and archives can be found below: | ||
16 | |||
17 | http://marc.info/?l=linux-netdev | ||
18 | http://www.spinics.net/lists/netdev/ | ||
19 | |||
20 | Aside from subsystems like that mentioned above, all network related linux | ||
21 | development (i.e. RFC, review, comments, etc) takes place on netdev. | ||
22 | |||
23 | Q: How do the changes posted to netdev make their way into linux? | ||
24 | |||
25 | A: There are always two trees (git repositories) in play. Both are driven | ||
26 | by David Miller, the main network maintainer. There is the "net" tree, | ||
27 | and the "net-next" tree. As you can probably guess from the names, the | ||
28 | net tree is for fixes to existing code already in the mainline tree from | ||
29 | Linus, and net-next is where the new code goes for the future release. | ||
30 | You can find the trees here: | ||
31 | |||
32 | http://git.kernel.org/?p=linux/kernel/git/davem/net.git | ||
33 | http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git | ||
34 | |||
35 | Q: How often do changes from these trees make it to the mainline Linus tree? | ||
36 | |||
37 | A: To understand this, you need to know a bit of background information | ||
38 | on the cadence of linux development. Each new release starts off with | ||
39 | a two week "merge window" where the main maintainers feed their new | ||
40 | stuff to Linus for merging into the mainline tree. After the two weeks, | ||
41 | the merge window is closed, and it is called/tagged "-rc1". No new | ||
42 | features get mainlined after this -- only fixes to the rc1 content | ||
43 | are expected. After roughly a week of collecting fixes to the rc1 | ||
44 | content, rc2 is released. This repeats on a roughly weekly basis | ||
45 | until rc7 (typically; sometimes rc6 if things are quiet, or rc8 if | ||
46 | things are in a state of churn), and a week after the last vX.Y-rcN | ||
47 | was done, the official "vX.Y" is released. | ||
48 | |||
49 | Relating that to netdev: At the beginning of the 2 week merge window, | ||
50 | the net-next tree will be closed - no new changes/features. The | ||
51 | accumulated new content of the past ~10 weeks will be passed onto | ||
52 | mainline/Linus via a pull request for vX.Y -- at the same time, | ||
53 | the "net" tree will start accumulating fixes for this pulled content | ||
54 | relating to vX.Y | ||
55 | |||
56 | An announcement indicating when net-next has been closed is usually | ||
57 | sent to netdev, but knowing the above, you can predict that in advance. | ||
58 | |||
59 | IMPORTANT: Do not send new net-next content to netdev during the | ||
60 | period during which net-next tree is closed. | ||
61 | |||
62 | Shortly after the two weeks have passed, (and vX.Y-rc1 is released) the | ||
63 | tree for net-next reopens to collect content for the next (vX.Y+1) release. | ||
64 | |||
65 | If you aren't subscribed to netdev and/or are simply unsure if net-next | ||
66 | has re-opened yet, simply check the net-next git repository link above for | ||
67 | any new networking related commits. | ||
68 | |||
69 | The "net" tree continues to collect fixes for the vX.Y content, and | ||
70 | is fed back to Linus at regular (~weekly) intervals. Meaning that the | ||
71 | focus for "net" is on stablilization and bugfixes. | ||
72 | |||
73 | Finally, the vX.Y gets released, and the whole cycle starts over. | ||
74 | |||
75 | Q: So where are we now in this cycle? | ||
76 | |||
77 | A: Load the mainline (Linus) page here: | ||
78 | |||
79 | http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git | ||
80 | |||
81 | and note the top of the "tags" section. If it is rc1, it is early | ||
82 | in the dev cycle. If it was tagged rc7 a week ago, then a release | ||
83 | is probably imminent. | ||
84 | |||
85 | Q: How do I indicate which tree (net vs. net-next) my patch should be in? | ||
86 | |||
87 | A: Firstly, think whether you have a bug fix or new "next-like" content. | ||
88 | Then once decided, assuming that you use git, use the prefix flag, i.e. | ||
89 | |||
90 | git format-patch --subject-prefix='PATCH net-next' start..finish | ||
91 | |||
92 | Use "net" instead of "net-next" (always lower case) in the above for | ||
93 | bug-fix net content. If you don't use git, then note the only magic in | ||
94 | the above is just the subject text of the outgoing e-mail, and you can | ||
95 | manually change it yourself with whatever MUA you are comfortable with. | ||
96 | |||
97 | Q: I sent a patch and I'm wondering what happened to it. How can I tell | ||
98 | whether it got merged? | ||
99 | |||
100 | A: Start by looking at the main patchworks queue for netdev: | ||
101 | |||
102 | http://patchwork.ozlabs.org/project/netdev/list/ | ||
103 | |||
104 | The "State" field will tell you exactly where things are at with | ||
105 | your patch. | ||
106 | |||
107 | Q: The above only says "Under Review". How can I find out more? | ||
108 | |||
109 | A: Generally speaking, the patches get triaged quickly (in less than 48h). | ||
110 | So be patient. Asking the maintainer for status updates on your | ||
111 | patch is a good way to ensure your patch is ignored or pushed to | ||
112 | the bottom of the priority list. | ||
113 | |||
114 | Q: How can I tell what patches are queued up for backporting to the | ||
115 | various stable releases? | ||
116 | |||
117 | A: Normally Greg Kroah-Hartman collects stable commits himself, but | ||
118 | for networking, Dave collects up patches he deems critical for the | ||
119 | networking subsystem, and then hands them off to Greg. | ||
120 | |||
121 | There is a patchworks queue that you can see here: | ||
122 | http://patchwork.ozlabs.org/bundle/davem/stable/?state=* | ||
123 | |||
124 | It contains the patches which Dave has selected, but not yet handed | ||
125 | off to Greg. If Greg already has the patch, then it will be here: | ||
126 | http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git | ||
127 | |||
128 | A quick way to find whether the patch is in this stable-queue is | ||
129 | to simply clone the repo, and then git grep the mainline commit ID, e.g. | ||
130 | |||
131 | stable-queue$ git grep -l 284041ef21fdf2e | ||
132 | releases/3.0.84/ipv6-fix-possible-crashes-in-ip6_cork_release.patch | ||
133 | releases/3.4.51/ipv6-fix-possible-crashes-in-ip6_cork_release.patch | ||
134 | releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch | ||
135 | stable/stable-queue$ | ||
136 | |||
137 | Q: I see a network patch and I think it should be backported to stable. | ||
138 | Should I request it via "stable@vger.kernel.org" like the references in | ||
139 | the kernel's Documentation/stable_kernel_rules.txt file say? | ||
140 | |||
141 | A: No, not for networking. Check the stable queues as per above 1st to see | ||
142 | if it is already queued. If not, then send a mail to netdev, listing | ||
143 | the upstream commit ID and why you think it should be a stable candidate. | ||
144 | |||
145 | Before you jump to go do the above, do note that the normal stable rules | ||
146 | in Documentation/stable_kernel_rules.txt still apply. So you need to | ||
147 | explicitly indicate why it is a critical fix and exactly what users are | ||
148 | impacted. In addition, you need to convince yourself that you _really_ | ||
149 | think it has been overlooked, vs. having been considered and rejected. | ||
150 | |||
151 | Generally speaking, the longer it has had a chance to "soak" in mainline, | ||
152 | the better the odds that it is an OK candidate for stable. So scrambling | ||
153 | to request a commit be added the day after it appears should be avoided. | ||
154 | |||
155 | Q: I have created a network patch and I think it should be backported to | ||
156 | stable. Should I add a "Cc: stable@vger.kernel.org" like the references | ||
157 | in the kernel's Documentation/ directory say? | ||
158 | |||
159 | A: No. See above answer. In short, if you think it really belongs in | ||
160 | stable, then ensure you write a decent commit log that describes who | ||
161 | gets impacted by the bugfix and how it manifests itself, and when the | ||
162 | bug was introduced. If you do that properly, then the commit will | ||
163 | get handled appropriately and most likely get put in the patchworks | ||
164 | stable queue if it really warrants it. | ||
165 | |||
166 | If you think there is some valid information relating to it being in | ||
167 | stable that does _not_ belong in the commit log, then use the three | ||
168 | dash marker line as described in Documentation/SubmittingPatches to | ||
169 | temporarily embed that information into the patch that you send. | ||
170 | |||
171 | Q: Someone said that the comment style and coding convention is different | ||
172 | for the networking content. Is this true? | ||
173 | |||
174 | A: Yes, in a largely trivial way. Instead of this: | ||
175 | |||
176 | /* | ||
177 | * foobar blah blah blah | ||
178 | * another line of text | ||
179 | */ | ||
180 | |||
181 | it is requested that you make it look like this: | ||
182 | |||
183 | /* foobar blah blah blah | ||
184 | * another line of text | ||
185 | */ | ||
186 | |||
187 | Q: I am working in existing code that has the former comment style and not the | ||
188 | latter. Should I submit new code in the former style or the latter? | ||
189 | |||
190 | A: Make it the latter style, so that eventually all code in the domain of | ||
191 | netdev is of this format. | ||
192 | |||
193 | Q: I found a bug that might have possible security implications or similar. | ||
194 | Should I mail the main netdev maintainer off-list? | ||
195 | |||
196 | A: No. The current netdev maintainer has consistently requested that people | ||
197 | use the mailing lists and not reach out directly. If you aren't OK with | ||
198 | that, then perhaps consider mailing "security@kernel.org" or reading about | ||
199 | http://oss-security.openwall.org/wiki/mailing-lists/distros | ||
200 | as possible alternative mechanisms. | ||
201 | |||
202 | Q: What level of testing is expected before I submit my change? | ||
203 | |||
204 | A: If your changes are against net-next, the expectation is that you | ||
205 | have tested by layering your changes on top of net-next. Ideally you | ||
206 | will have done run-time testing specific to your change, but at a | ||
207 | minimum, your changes should survive an "allyesconfig" and an | ||
208 | "allmodconfig" build without new warnings or failures. | ||
209 | |||
210 | Q: Any other tips to help ensure my net/net-next patch gets OK'd? | ||
211 | |||
212 | A: Attention to detail. Re-read your own work as if you were the | ||
213 | reviewer. You can start with using checkpatch.pl, perhaps even | ||
214 | with the "--strict" flag. But do not be mindlessly robotic in | ||
215 | doing so. If your change is a bug-fix, make sure your commit log | ||
216 | indicates the end-user visible symptom, the underlying reason as | ||
217 | to why it happens, and then if necessary, explain why the fix proposed | ||
218 | is the best way to get things done. Don't mangle whitespace, and as | ||
219 | is common, don't mis-indent function arguments that span multiple lines. | ||
220 | If it is your 1st patch, mail it to yourself so you can test apply | ||
221 | it to an unpatched tree to confirm infrastructure didn't mangle it. | ||
222 | |||
223 | Finally, go back and read Documentation/SubmittingPatches to be | ||
224 | sure you are not repeating some common mistake documented there. | ||
diff --git a/Documentation/networking/openvswitch.txt b/Documentation/networking/openvswitch.txt index 8fa2dd1e792e..37c20ee2455e 100644 --- a/Documentation/networking/openvswitch.txt +++ b/Documentation/networking/openvswitch.txt | |||
@@ -91,6 +91,46 @@ Often we ellipsize arguments not important to the discussion, e.g.: | |||
91 | in_port(1), eth(...), eth_type(0x0800), ipv4(...), tcp(...) | 91 | in_port(1), eth(...), eth_type(0x0800), ipv4(...), tcp(...) |
92 | 92 | ||
93 | 93 | ||
94 | Wildcarded flow key format | ||
95 | -------------------------- | ||
96 | |||
97 | A wildcarded flow is described with two sequences of Netlink attributes | ||
98 | passed over the Netlink socket. A flow key, exactly as described above, and an | ||
99 | optional corresponding flow mask. | ||
100 | |||
101 | A wildcarded flow can represent a group of exact match flows. Each '1' bit | ||
102 | in the mask specifies a exact match with the corresponding bit in the flow key. | ||
103 | A '0' bit specifies a don't care bit, which will match either a '1' or '0' bit | ||
104 | of a incoming packet. Using wildcarded flow can improve the flow set up rate | ||
105 | by reduce the number of new flows need to be processed by the user space program. | ||
106 | |||
107 | Support for the mask Netlink attribute is optional for both the kernel and user | ||
108 | space program. The kernel can ignore the mask attribute, installing an exact | ||
109 | match flow, or reduce the number of don't care bits in the kernel to less than | ||
110 | what was specified by the user space program. In this case, variations in bits | ||
111 | that the kernel does not implement will simply result in additional flow setups. | ||
112 | The kernel module will also work with user space programs that neither support | ||
113 | nor supply flow mask attributes. | ||
114 | |||
115 | Since the kernel may ignore or modify wildcard bits, it can be difficult for | ||
116 | the userspace program to know exactly what matches are installed. There are | ||
117 | two possible approaches: reactively install flows as they miss the kernel | ||
118 | flow table (and therefore not attempt to determine wildcard changes at all) | ||
119 | or use the kernel's response messages to determine the installed wildcards. | ||
120 | |||
121 | When interacting with userspace, the kernel should maintain the match portion | ||
122 | of the key exactly as originally installed. This will provides a handle to | ||
123 | identify the flow for all future operations. However, when reporting the | ||
124 | mask of an installed flow, the mask should include any restrictions imposed | ||
125 | by the kernel. | ||
126 | |||
127 | The behavior when using overlapping wildcarded flows is undefined. It is the | ||
128 | responsibility of the user space program to ensure that any incoming packet | ||
129 | can match at most one flow, wildcarded or not. The current implementation | ||
130 | performs best-effort detection of overlapping wildcarded flows and may reject | ||
131 | some but not all of them. However, this behavior may change in future versions. | ||
132 | |||
133 | |||
94 | Basic rule for evolving flow keys | 134 | Basic rule for evolving flow keys |
95 | --------------------------------- | 135 | --------------------------------- |
96 | 136 | ||
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 8572796b1eb6..c01223628a87 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt | |||
@@ -543,6 +543,14 @@ TPACKET_V2 --> TPACKET_V3: | |||
543 | In the AF_PACKET fanout mode, packet reception can be load balanced among | 543 | In the AF_PACKET fanout mode, packet reception can be load balanced among |
544 | processes. This also works in combination with mmap(2) on packet sockets. | 544 | processes. This also works in combination with mmap(2) on packet sockets. |
545 | 545 | ||
546 | Currently implemented fanout policies are: | ||
547 | |||
548 | - PACKET_FANOUT_HASH: schedule to socket by skb's rxhash | ||
549 | - PACKET_FANOUT_LB: schedule to socket by round-robin | ||
550 | - PACKET_FANOUT_CPU: schedule to socket by CPU packet arrives on | ||
551 | - PACKET_FANOUT_RND: schedule to socket by random selection | ||
552 | - PACKET_FANOUT_ROLLOVER: if one socket is full, rollover to another | ||
553 | |||
546 | Minimal example code by David S. Miller (try things like "./test eth0 hash", | 554 | Minimal example code by David S. Miller (try things like "./test eth0 hash", |
547 | "./test eth0 lb", etc.): | 555 | "./test eth0 lb", etc.): |
548 | 556 | ||
diff --git a/Documentation/networking/sctp.txt b/Documentation/networking/sctp.txt index 0c790a76910e..97b810ca9082 100644 --- a/Documentation/networking/sctp.txt +++ b/Documentation/networking/sctp.txt | |||
@@ -19,7 +19,6 @@ of SCTP that is RFC 2960 compliant and provides an programming interface | |||
19 | referred to as the UDP-style API of the Sockets Extensions for SCTP, as | 19 | referred to as the UDP-style API of the Sockets Extensions for SCTP, as |
20 | proposed in IETF Internet-Drafts. | 20 | proposed in IETF Internet-Drafts. |
21 | 21 | ||
22 | |||
23 | Caveats: | 22 | Caveats: |
24 | 23 | ||
25 | -lksctp can be built as statically or as a module. However, be aware that | 24 | -lksctp can be built as statically or as a module. However, be aware that |
@@ -33,6 +32,4 @@ For more information, please visit the lksctp project website: | |||
33 | http://www.sf.net/projects/lksctp | 32 | http://www.sf.net/projects/lksctp |
34 | 33 | ||
35 | Or contact the lksctp developers through the mailing list: | 34 | Or contact the lksctp developers through the mailing list: |
36 | <lksctp-developers@lists.sourceforge.net> | 35 | <linux-sctp@vger.kernel.org> |
37 | |||
38 | |||
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt index 654d2e55c8cb..457b8bbafb08 100644 --- a/Documentation/networking/stmmac.txt +++ b/Documentation/networking/stmmac.txt | |||
@@ -123,6 +123,7 @@ struct plat_stmmacenet_data { | |||
123 | int bugged_jumbo; | 123 | int bugged_jumbo; |
124 | int pmt; | 124 | int pmt; |
125 | int force_sf_dma_mode; | 125 | int force_sf_dma_mode; |
126 | int force_thresh_dma_mode; | ||
126 | int riwt_off; | 127 | int riwt_off; |
127 | void (*fix_mac_speed)(void *priv, unsigned int speed); | 128 | void (*fix_mac_speed)(void *priv, unsigned int speed); |
128 | void (*bus_setup)(void __iomem *ioaddr); | 129 | void (*bus_setup)(void __iomem *ioaddr); |
@@ -159,6 +160,8 @@ Where: | |||
159 | o pmt: core has the embedded power module (optional). | 160 | o pmt: core has the embedded power module (optional). |
160 | o force_sf_dma_mode: force DMA to use the Store and Forward mode | 161 | o force_sf_dma_mode: force DMA to use the Store and Forward mode |
161 | instead of the Threshold. | 162 | instead of the Threshold. |
163 | o force_thresh_dma_mode: force DMA to use the Shreshold mode other than | ||
164 | the Store and Forward mode. | ||
162 | o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode. | 165 | o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode. |
163 | o fix_mac_speed: this callback is used for modifying some syscfg registers | 166 | o fix_mac_speed: this callback is used for modifying some syscfg registers |
164 | (on ST SoCs) according to the link speed negotiated by the | 167 | (on ST SoCs) according to the link speed negotiated by the |
diff --git a/Documentation/networking/tproxy.txt b/Documentation/networking/tproxy.txt index 7b5996d9357e..ec11429e1d42 100644 --- a/Documentation/networking/tproxy.txt +++ b/Documentation/networking/tproxy.txt | |||
@@ -2,9 +2,8 @@ Transparent proxy support | |||
2 | ========================= | 2 | ========================= |
3 | 3 | ||
4 | This feature adds Linux 2.2-like transparent proxy support to current kernels. | 4 | This feature adds Linux 2.2-like transparent proxy support to current kernels. |
5 | To use it, enable NETFILTER_TPROXY, the socket match and the TPROXY target in | 5 | To use it, enable the socket match and the TPROXY target in your kernel config. |
6 | your kernel config. You will need policy routing too, so be sure to enable that | 6 | You will need policy routing too, so be sure to enable that as well. |
7 | as well. | ||
8 | 7 | ||
9 | 8 | ||
10 | 1. Making non-local sockets work | 9 | 1. Making non-local sockets work |
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 052e13af2d38..c0ffd30eb55e 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt | |||
@@ -81,7 +81,7 @@ int __init foo_probe(void) | |||
81 | struct pinctrl_dev *pctl; | 81 | struct pinctrl_dev *pctl; |
82 | 82 | ||
83 | pctl = pinctrl_register(&foo_desc, <PARENT>, NULL); | 83 | pctl = pinctrl_register(&foo_desc, <PARENT>, NULL); |
84 | if (IS_ERR(pctl)) | 84 | if (!pctl) |
85 | pr_err("could not register foo pin driver\n"); | 85 | pr_err("could not register foo pin driver\n"); |
86 | } | 86 | } |
87 | 87 | ||
@@ -795,18 +795,97 @@ special GPIO-handler is registered. | |||
795 | GPIO mode pitfalls | 795 | GPIO mode pitfalls |
796 | ================== | 796 | ================== |
797 | 797 | ||
798 | Sometime the developer may be confused by a datasheet talking about a pin | 798 | Due to the naming conventions used by hardware engineers, where "GPIO" |
799 | being possible to set into "GPIO mode". It appears that what hardware | 799 | is taken to mean different things than what the kernel does, the developer |
800 | engineers mean with "GPIO mode" is not necessarily the use case that is | 800 | may be confused by a datasheet talking about a pin being possible to set |
801 | implied in the kernel interface <linux/gpio.h>: a pin that you grab from | 801 | into "GPIO mode". It appears that what hardware engineers mean with |
802 | kernel code and then either listen for input or drive high/low to | 802 | "GPIO mode" is not necessarily the use case that is implied in the kernel |
803 | assert/deassert some external line. | 803 | interface <linux/gpio.h>: a pin that you grab from kernel code and then |
804 | either listen for input or drive high/low to assert/deassert some | ||
805 | external line. | ||
804 | 806 | ||
805 | Rather hardware engineers think that "GPIO mode" means that you can | 807 | Rather hardware engineers think that "GPIO mode" means that you can |
806 | software-control a few electrical properties of the pin that you would | 808 | software-control a few electrical properties of the pin that you would |
807 | not be able to control if the pin was in some other mode, such as muxed in | 809 | not be able to control if the pin was in some other mode, such as muxed in |
808 | for a device. | 810 | for a device. |
809 | 811 | ||
812 | The GPIO portions of a pin and its relation to a certain pin controller | ||
813 | configuration and muxing logic can be constructed in several ways. Here | ||
814 | are two examples: | ||
815 | |||
816 | (A) | ||
817 | pin config | ||
818 | logic regs | ||
819 | | +- SPI | ||
820 | Physical pins --- pad --- pinmux -+- I2C | ||
821 | | +- mmc | ||
822 | | +- GPIO | ||
823 | pin | ||
824 | multiplex | ||
825 | logic regs | ||
826 | |||
827 | Here some electrical properties of the pin can be configured no matter | ||
828 | whether the pin is used for GPIO or not. If you multiplex a GPIO onto a | ||
829 | pin, you can also drive it high/low from "GPIO" registers. | ||
830 | Alternatively, the pin can be controlled by a certain peripheral, while | ||
831 | still applying desired pin config properties. GPIO functionality is thus | ||
832 | orthogonal to any other device using the pin. | ||
833 | |||
834 | In this arrangement the registers for the GPIO portions of the pin controller, | ||
835 | or the registers for the GPIO hardware module are likely to reside in a | ||
836 | separate memory range only intended for GPIO driving, and the register | ||
837 | range dealing with pin config and pin multiplexing get placed into a | ||
838 | different memory range and a separate section of the data sheet. | ||
839 | |||
840 | (B) | ||
841 | |||
842 | pin config | ||
843 | logic regs | ||
844 | | +- SPI | ||
845 | Physical pins --- pad --- pinmux -+- I2C | ||
846 | | | +- mmc | ||
847 | | | | ||
848 | GPIO pin | ||
849 | multiplex | ||
850 | logic regs | ||
851 | |||
852 | In this arrangement, the GPIO functionality can always be enabled, such that | ||
853 | e.g. a GPIO input can be used to "spy" on the SPI/I2C/MMC signal while it is | ||
854 | pulsed out. It is likely possible to disrupt the traffic on the pin by doing | ||
855 | wrong things on the GPIO block, as it is never really disconnected. It is | ||
856 | possible that the GPIO, pin config and pin multiplex registers are placed into | ||
857 | the same memory range and the same section of the data sheet, although that | ||
858 | need not be the case. | ||
859 | |||
860 | From a kernel point of view, however, these are different aspects of the | ||
861 | hardware and shall be put into different subsystems: | ||
862 | |||
863 | - Registers (or fields within registers) that control electrical | ||
864 | properties of the pin such as biasing and drive strength should be | ||
865 | exposed through the pinctrl subsystem, as "pin configuration" settings. | ||
866 | |||
867 | - Registers (or fields within registers) that control muxing of signals | ||
868 | from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should | ||
869 | be exposed through the pinctrl subssytem, as mux functions. | ||
870 | |||
871 | - Registers (or fields within registers) that control GPIO functionality | ||
872 | such as setting a GPIO's output value, reading a GPIO's input value, or | ||
873 | setting GPIO pin direction should be exposed through the GPIO subsystem, | ||
874 | and if they also support interrupt capabilities, through the irqchip | ||
875 | abstraction. | ||
876 | |||
877 | Depending on the exact HW register design, some functions exposed by the | ||
878 | GPIO subsystem may call into the pinctrl subsystem in order to | ||
879 | co-ordinate register settings across HW modules. In particular, this may | ||
880 | be needed for HW with separate GPIO and pin controller HW modules, where | ||
881 | e.g. GPIO direction is determined by a register in the pin controller HW | ||
882 | module rather than the GPIO HW module. | ||
883 | |||
884 | Electrical properties of the pin such as biasing and drive strength | ||
885 | may be placed at some pin-specific register in all cases or as part | ||
886 | of the GPIO register in case (B) especially. This doesn't mean that such | ||
887 | properties necessarily pertain to what the Linux kernel calls "GPIO". | ||
888 | |||
810 | Example: a pin is usually muxed in to be used as a UART TX line. But during | 889 | Example: a pin is usually muxed in to be used as a UART TX line. But during |
811 | system sleep, we need to put this pin into "GPIO mode" and ground it. | 890 | system sleep, we need to put this pin into "GPIO mode" and ground it. |
812 | 891 | ||
@@ -856,7 +935,7 @@ static unsigned long uart_sleep_mode[] = { | |||
856 | PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0), | 935 | PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0), |
857 | }; | 936 | }; |
858 | 937 | ||
859 | static struct pinctrl_map __initdata pinmap[] = { | 938 | static struct pinctrl_map pinmap[] __initdata = { |
860 | PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo", | 939 | PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo", |
861 | "u0_group", "u0"), | 940 | "u0_group", "u0"), |
862 | PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo", | 941 | PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo", |
@@ -951,7 +1030,7 @@ Since the above construct is pretty common there is a helper macro to make | |||
951 | it even more compact which assumes you want to use pinctrl-foo and position | 1030 | it even more compact which assumes you want to use pinctrl-foo and position |
952 | 0 for mapping, for example: | 1031 | 0 for mapping, for example: |
953 | 1032 | ||
954 | static struct pinctrl_map __initdata mapping[] = { | 1033 | static struct pinctrl_map mapping[] __initdata = { |
955 | PIN_MAP_MUX_GROUP("foo-i2c.o", PINCTRL_STATE_DEFAULT, "pinctrl-foo", NULL, "i2c0"), | 1034 | PIN_MAP_MUX_GROUP("foo-i2c.o", PINCTRL_STATE_DEFAULT, "pinctrl-foo", NULL, "i2c0"), |
956 | }; | 1035 | }; |
957 | 1036 | ||
@@ -970,7 +1049,7 @@ static unsigned long i2c_pin_configs[] = { | |||
970 | FOO_SLEW_RATE_SLOW, | 1049 | FOO_SLEW_RATE_SLOW, |
971 | }; | 1050 | }; |
972 | 1051 | ||
973 | static struct pinctrl_map __initdata mapping[] = { | 1052 | static struct pinctrl_map mapping[] __initdata = { |
974 | PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", "i2c0"), | 1053 | PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", "i2c0"), |
975 | PIN_MAP_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", i2c_grp_configs), | 1054 | PIN_MAP_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", i2c_grp_configs), |
976 | PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0scl", i2c_pin_configs), | 1055 | PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0scl", i2c_pin_configs), |
@@ -984,7 +1063,7 @@ order to explicitly indicate that the states were provided and intended to | |||
984 | be empty. Table entry macro PIN_MAP_DUMMY_STATE serves the purpose of defining | 1063 | be empty. Table entry macro PIN_MAP_DUMMY_STATE serves the purpose of defining |
985 | a named state without causing any pin controller to be programmed: | 1064 | a named state without causing any pin controller to be programmed: |
986 | 1065 | ||
987 | static struct pinctrl_map __initdata mapping[] = { | 1066 | static struct pinctrl_map mapping[] __initdata = { |
988 | PIN_MAP_DUMMY_STATE("foo-i2c.0", PINCTRL_STATE_DEFAULT), | 1067 | PIN_MAP_DUMMY_STATE("foo-i2c.0", PINCTRL_STATE_DEFAULT), |
989 | }; | 1068 | }; |
990 | 1069 | ||
diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt index 262acf56fa79..e9b54de8fdf7 100644 --- a/Documentation/power/basic-pm-debugging.txt +++ b/Documentation/power/basic-pm-debugging.txt | |||
@@ -179,7 +179,7 @@ use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt . | |||
179 | 179 | ||
180 | To verify that the STR works, it is generally more convenient to use the s2ram | 180 | To verify that the STR works, it is generally more convenient to use the s2ram |
181 | tool available from http://suspend.sf.net and documented at | 181 | tool available from http://suspend.sf.net and documented at |
182 | http://en.opensuse.org/SDB:Suspend_to_RAM. | 182 | http://en.opensuse.org/SDB:Suspend_to_RAM (S2RAM_LINK). |
183 | 183 | ||
184 | Namely, after writing "freezer", "devices", "platform", "processors", or "core" | 184 | Namely, after writing "freezer", "devices", "platform", "processors", or "core" |
185 | into /sys/power/pm_test (available if the kernel is compiled with | 185 | into /sys/power/pm_test (available if the kernel is compiled with |
@@ -194,10 +194,10 @@ Among other things, the testing with the help of /sys/power/pm_test may allow | |||
194 | you to identify drivers that fail to suspend or resume their devices. They | 194 | you to identify drivers that fail to suspend or resume their devices. They |
195 | should be unloaded every time before an STR transition. | 195 | should be unloaded every time before an STR transition. |
196 | 196 | ||
197 | Next, you can follow the instructions at http://en.opensuse.org/s2ram to test | 197 | Next, you can follow the instructions at S2RAM_LINK to test the system, but if |
198 | the system, but if it does not work "out of the box", you may need to boot it | 198 | it does not work "out of the box", you may need to boot it with |
199 | with "init=/bin/bash" and test s2ram in the minimal configuration. In that | 199 | "init=/bin/bash" and test s2ram in the minimal configuration. In that case, |
200 | case, you may be able to search for failing drivers by following the procedure | 200 | you may be able to search for failing drivers by following the procedure |
201 | analogous to the one described in section 1. If you find some failing drivers, | 201 | analogous to the one described in section 1. If you find some failing drivers, |
202 | you will have to unload them every time before an STR transition (ie. before | 202 | you will have to unload them every time before an STR transition (ie. before |
203 | you run s2ram), and please report the problems with them. | 203 | you run s2ram), and please report the problems with them. |
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index 0b4b63e7e9b6..079160e22bcc 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt | |||
@@ -50,6 +50,19 @@ echo N > /sys/power/image_size | |||
50 | 50 | ||
51 | before suspend (it is limited to 500 MB by default). | 51 | before suspend (it is limited to 500 MB by default). |
52 | 52 | ||
53 | . The resume process checks for the presence of the resume device, | ||
54 | if found, it then checks the contents for the hibernation image signature. | ||
55 | If both are found, it resumes the hibernation image. | ||
56 | |||
57 | . The resume process may be triggered in two ways: | ||
58 | 1) During lateinit: If resume=/dev/your_swap_partition is specified on | ||
59 | the kernel command line, lateinit runs the resume process. If the | ||
60 | resume device has not been probed yet, the resume process fails and | ||
61 | bootup continues. | ||
62 | 2) Manually from an initrd or initramfs: May be run from | ||
63 | the init script by using the /sys/power/resume file. It is vital | ||
64 | that this be done prior to remounting any filesystems (even as | ||
65 | read-only) otherwise data may be corrupted. | ||
53 | 66 | ||
54 | Article about goals and implementation of Software Suspend for Linux | 67 | Article about goals and implementation of Software Suspend for Linux |
55 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 68 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
@@ -326,7 +339,7 @@ Q: How can distributions ship a swsusp-supporting kernel with modular | |||
326 | disk drivers (especially SATA)? | 339 | disk drivers (especially SATA)? |
327 | 340 | ||
328 | A: Well, it can be done, load the drivers, then do echo into | 341 | A: Well, it can be done, load the drivers, then do echo into |
329 | /sys/power/disk/resume file from initrd. Be sure not to mount | 342 | /sys/power/resume file from initrd. Be sure not to mount |
330 | anything, not even read-only mount, or you are going to lose your | 343 | anything, not even read-only mount, or you are going to lose your |
331 | data. | 344 | data. |
332 | 345 | ||
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index 05026ce1875e..6db73df04278 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX | |||
@@ -5,13 +5,20 @@ please mail me. | |||
5 | 5 | ||
6 | 00-INDEX | 6 | 00-INDEX |
7 | - this file | 7 | - this file |
8 | bootwrapper.txt | ||
9 | - Information on how the powerpc kernel is wrapped for boot on various | ||
10 | different platforms. | ||
8 | cpu_features.txt | 11 | cpu_features.txt |
9 | - info on how we support a variety of CPUs with minimal compile-time | 12 | - info on how we support a variety of CPUs with minimal compile-time |
10 | options. | 13 | options. |
11 | eeh-pci-error-recovery.txt | 14 | eeh-pci-error-recovery.txt |
12 | - info on PCI Bus EEH Error Recovery | 15 | - info on PCI Bus EEH Error Recovery |
16 | firmware-assisted-dump.txt | ||
17 | - Documentation on the firmware assisted dump mechanism "fadump". | ||
13 | hvcs.txt | 18 | hvcs.txt |
14 | - IBM "Hypervisor Virtual Console Server" Installation Guide | 19 | - IBM "Hypervisor Virtual Console Server" Installation Guide |
20 | kvm_440.txt | ||
21 | - Various notes on the implementation of KVM for PowerPC 440. | ||
15 | mpc52xx.txt | 22 | mpc52xx.txt |
16 | - Linux 2.6.x on MPC52xx family | 23 | - Linux 2.6.x on MPC52xx family |
17 | pmu-ebb.txt | 24 | pmu-ebb.txt |
@@ -19,3 +26,7 @@ pmu-ebb.txt | |||
19 | qe_firmware.txt | 26 | qe_firmware.txt |
20 | - describes the layout of firmware binaries for the Freescale QUICC | 27 | - describes the layout of firmware binaries for the Freescale QUICC |
21 | Engine and the code that parses and uploads the microcode therein. | 28 | Engine and the code that parses and uploads the microcode therein. |
29 | ptrace.txt | ||
30 | - Information on the ptrace interfaces for hardware debug registers. | ||
31 | transactional_memory.txt | ||
32 | - Overview of the Power8 transactional memory support. | ||
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 3e8cb73ac43c..445ad743ec81 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt | |||
@@ -97,7 +97,7 @@ IPv4 addresses: | |||
97 | 97 | ||
98 | %pI4 1.2.3.4 | 98 | %pI4 1.2.3.4 |
99 | %pi4 001.002.003.004 | 99 | %pi4 001.002.003.004 |
100 | %p[Ii][hnbl] | 100 | %p[Ii]4[hnbl] |
101 | 101 | ||
102 | For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4' | 102 | For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4' |
103 | specifiers result in a printed address with ('i4') or without ('I4') | 103 | specifiers result in a printed address with ('i4') or without ('I4') |
@@ -168,6 +168,15 @@ UUID/GUID addresses: | |||
168 | Where no additional specifiers are used the default little endian | 168 | Where no additional specifiers are used the default little endian |
169 | order with lower case hex characters will be printed. | 169 | order with lower case hex characters will be printed. |
170 | 170 | ||
171 | dentry names: | ||
172 | %pd{,2,3,4} | ||
173 | %pD{,2,3,4} | ||
174 | |||
175 | For printing dentry name; if we race with d_move(), the name might be | ||
176 | a mix of old and new ones, but it won't oops. %pd dentry is a safer | ||
177 | equivalent of %s dentry->d_name.name we used to use, %pd<n> prints | ||
178 | n last components. %pD does the same thing for struct file. | ||
179 | |||
171 | struct va_format: | 180 | struct va_format: |
172 | 181 | ||
173 | %pV | 182 | %pV |
@@ -185,11 +194,11 @@ struct va_format: | |||
185 | 194 | ||
186 | u64 SHOULD be printed with %llu/%llx, (unsigned long long): | 195 | u64 SHOULD be printed with %llu/%llx, (unsigned long long): |
187 | 196 | ||
188 | printk("%llu", (unsigned long long)u64_var); | 197 | printk("%llu", u64_var); |
189 | 198 | ||
190 | s64 SHOULD be printed with %lld/%llx, (long long): | 199 | s64 SHOULD be printed with %lld/%llx, (long long): |
191 | 200 | ||
192 | printk("%lld", (long long)s64_var); | 201 | printk("%lld", s64_var); |
193 | 202 | ||
194 | If <type> is dependent on a config option for its size (e.g., sector_t, | 203 | If <type> is dependent on a config option for its size (e.g., sector_t, |
195 | blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a | 204 | blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a |
diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt index 717f5aa388b1..28fbd877f85a 100644 --- a/Documentation/rapidio/rapidio.txt +++ b/Documentation/rapidio/rapidio.txt | |||
@@ -300,7 +300,7 @@ initialization. | |||
300 | ------------------------------------------- | 300 | ------------------------------------------- |
301 | 301 | ||
302 | RapidIO subsystem code organization allows addition of new enumeration/discovery | 302 | RapidIO subsystem code organization allows addition of new enumeration/discovery |
303 | methods as new configuration options without significant impact to to the core | 303 | methods as new configuration options without significant impact to the core |
304 | RapidIO code. | 304 | RapidIO code. |
305 | 305 | ||
306 | A new enumeration/discovery method has to be attached to one or more mport | 306 | A new enumeration/discovery method has to be attached to one or more mport |
diff --git a/Documentation/scsi/LICENSE.qla4xxx b/Documentation/scsi/LICENSE.qla4xxx index 78c169f0d7c6..fcc27ad27d74 100644 --- a/Documentation/scsi/LICENSE.qla4xxx +++ b/Documentation/scsi/LICENSE.qla4xxx | |||
@@ -1,4 +1,4 @@ | |||
1 | Copyright (c) 2003-2012 QLogic Corporation | 1 | Copyright (c) 2003-2013 QLogic Corporation |
2 | QLogic Linux iSCSI Driver | 2 | QLogic Linux iSCSI Driver |
3 | 3 | ||
4 | This program includes a device driver for Linux 3.x. | 4 | This program includes a device driver for Linux 3.x. |
diff --git a/Documentation/scsi/hptiop.txt b/Documentation/scsi/hptiop.txt index 4a4f47e759cd..12ecfd308e55 100644 --- a/Documentation/scsi/hptiop.txt +++ b/Documentation/scsi/hptiop.txt | |||
@@ -151,7 +151,7 @@ To send a request to the controller: | |||
151 | generated. | 151 | generated. |
152 | 152 | ||
153 | - The host read the outbound list copy pointer shadow register and compare | 153 | - The host read the outbound list copy pointer shadow register and compare |
154 | with previous saved read ponter N. If they are different, the host will | 154 | with previous saved read pointer N. If they are different, the host will |
155 | read the (N+1)th outbound list unit. | 155 | read the (N+1)th outbound list unit. |
156 | 156 | ||
157 | The host get the index of the request from the (N+1)th outbound list | 157 | The host get the index of the request from the (N+1)th outbound list |
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 809d72b8eff1..a46ddb85e83a 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt | |||
@@ -244,6 +244,7 @@ STAC9227/9228/9229/927x | |||
244 | 5stack-no-fp D965 5stack without front panel | 244 | 5stack-no-fp D965 5stack without front panel |
245 | dell-3stack Dell Dimension E520 | 245 | dell-3stack Dell Dimension E520 |
246 | dell-bios Fixes with Dell BIOS setup | 246 | dell-bios Fixes with Dell BIOS setup |
247 | dell-bios-amic Fixes with Dell BIOS setup including analog mic | ||
247 | volknob Fixes with volume-knob widget 0x24 | 248 | volknob Fixes with volume-knob widget 0x24 |
248 | auto BIOS setup (default) | 249 | auto BIOS setup (default) |
249 | 250 | ||
diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt index c3c912d023cc..42a0a39b77e6 100644 --- a/Documentation/sound/alsa/HD-Audio.txt +++ b/Documentation/sound/alsa/HD-Audio.txt | |||
@@ -454,6 +454,8 @@ The generic parser supports the following hints: | |||
454 | - need_dac_fix (bool): limits the DACs depending on the channel count | 454 | - need_dac_fix (bool): limits the DACs depending on the channel count |
455 | - primary_hp (bool): probe headphone jacks as the primary outputs; | 455 | - primary_hp (bool): probe headphone jacks as the primary outputs; |
456 | default true | 456 | default true |
457 | - multi_io (bool): try probing multi-I/O config (e.g. shared | ||
458 | line-in/surround, mic/clfe jacks) | ||
457 | - multi_cap_vol (bool): provide multiple capture volumes | 459 | - multi_cap_vol (bool): provide multiple capture volumes |
458 | - inv_dmic_split (bool): provide split internal mic volume/switch for | 460 | - inv_dmic_split (bool): provide split internal mic volume/switch for |
459 | phase-inverted digital mics | 461 | phase-inverted digital mics |
diff --git a/Documentation/sound/alsa/README.maya44 b/Documentation/sound/alsa/README.maya44 index 0e41576fa13e..67b2ea1cc31d 100644 --- a/Documentation/sound/alsa/README.maya44 +++ b/Documentation/sound/alsa/README.maya44 | |||
@@ -120,7 +120,7 @@ Mic Phantom+48V: switch for +48V phantom power for electrostatic microphones on | |||
120 | Make sure this is not turned on while any other source is connected to input 1/2. | 120 | Make sure this is not turned on while any other source is connected to input 1/2. |
121 | It might damage the source and/or the maya44 card. | 121 | It might damage the source and/or the maya44 card. |
122 | 122 | ||
123 | Mic/Line input: if switch is is on, input jack 1/2 is microphone input (mono), otherwise line input (stereo). | 123 | Mic/Line input: if switch is on, input jack 1/2 is microphone input (mono), otherwise line input (stereo). |
124 | 124 | ||
125 | Bypass: analogue bypass from ADC input to output for channel 1+2. Same as "Monitor" in the windows driver. | 125 | Bypass: analogue bypass from ADC input to output for channel 1+2. Same as "Monitor" in the windows driver. |
126 | Bypass 1: same for channel 3+4. | 126 | Bypass 1: same for channel 3+4. |
diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt index 0bcc55155911..fd74ff26376e 100644 --- a/Documentation/sound/alsa/compress_offload.txt +++ b/Documentation/sound/alsa/compress_offload.txt | |||
@@ -73,7 +73,7 @@ The main requirements are: | |||
73 | 73 | ||
74 | Design | 74 | Design |
75 | 75 | ||
76 | The new API shares a number of concepts with with the PCM API for flow | 76 | The new API shares a number of concepts with the PCM API for flow |
77 | control. Start, pause, resume, drain and stop commands have the same | 77 | control. Start, pause, resume, drain and stop commands have the same |
78 | semantics no matter what the content is. | 78 | semantics no matter what the content is. |
79 | 79 | ||
@@ -130,7 +130,7 @@ the settings should remain the exception. | |||
130 | The timestamp becomes a multiple field structure. It lists the number | 130 | The timestamp becomes a multiple field structure. It lists the number |
131 | of bytes transferred, the number of samples processed and the number | 131 | of bytes transferred, the number of samples processed and the number |
132 | of samples rendered/grabbed. All these values can be used to determine | 132 | of samples rendered/grabbed. All these values can be used to determine |
133 | the avarage bitrate, figure out if the ring buffer needs to be | 133 | the average bitrate, figure out if the ring buffer needs to be |
134 | refilled or the delay due to decoding/encoding/io on the DSP. | 134 | refilled or the delay due to decoding/encoding/io on the DSP. |
135 | 135 | ||
136 | Note that the list of codecs/profiles/modes was derived from the | 136 | Note that the list of codecs/profiles/modes was derived from the |
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 2331eb214146..f21edb983413 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary | |||
@@ -215,7 +215,7 @@ So for example arch/.../mach-*/board-*.c files might have code like: | |||
215 | /* if your mach-* infrastructure doesn't support kernels that can | 215 | /* if your mach-* infrastructure doesn't support kernels that can |
216 | * run on multiple boards, pdata wouldn't benefit from "__init". | 216 | * run on multiple boards, pdata wouldn't benefit from "__init". |
217 | */ | 217 | */ |
218 | static struct mysoc_spi_data __initdata pdata = { ... }; | 218 | static struct mysoc_spi_data pdata __initdata = { ... }; |
219 | 219 | ||
220 | static __init board_init(void) | 220 | static __init board_init(void) |
221 | { | 221 | { |
diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index d569f2a424d5..9a0319a82470 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt | |||
@@ -50,6 +50,19 @@ The maximum number of packets that kernel can handle on a NAPI interrupt, | |||
50 | it's a Per-CPU variable. | 50 | it's a Per-CPU variable. |
51 | Default: 64 | 51 | Default: 64 |
52 | 52 | ||
53 | default_qdisc | ||
54 | -------------- | ||
55 | |||
56 | The default queuing discipline to use for network devices. This allows | ||
57 | overriding the default queue discipline of pfifo_fast with an | ||
58 | alternative. Since the default queuing discipline is created with the | ||
59 | no additional parameters so is best suited to queuing disciplines that | ||
60 | work well without configuration like stochastic fair queue (sfq), | ||
61 | CoDel (codel) or fair queue CoDel (fq_codel). Don't use queuing disciplines | ||
62 | like Hierarchical Token Bucket or Deficit Round Robin which require setting | ||
63 | up classes and bandwidths. | ||
64 | Default: pfifo_fast | ||
65 | |||
53 | busy_read | 66 | busy_read |
54 | ---------------- | 67 | ---------------- |
55 | Low latency busy poll timeout for socket reads. (needs CONFIG_NET_RX_BUSY_POLL) | 68 | Low latency busy poll timeout for socket reads. (needs CONFIG_NET_RX_BUSY_POLL) |
diff --git a/Documentation/sysfs-rules.txt b/Documentation/sysfs-rules.txt index c1a1fd636bf9..a5f985ee1822 100644 --- a/Documentation/sysfs-rules.txt +++ b/Documentation/sysfs-rules.txt | |||
@@ -47,7 +47,7 @@ versions of the sysfs interface. | |||
47 | at device creation and removal | 47 | at device creation and removal |
48 | - the unique key to the device at that point in time | 48 | - the unique key to the device at that point in time |
49 | - the kernel's path to the device directory without the leading | 49 | - the kernel's path to the device directory without the leading |
50 | /sys, and always starting with with a slash | 50 | /sys, and always starting with a slash |
51 | - all elements of a devpath must be real directories. Symlinks | 51 | - all elements of a devpath must be real directories. Symlinks |
52 | pointing to /sys/devices must always be resolved to their real | 52 | pointing to /sys/devices must always be resolved to their real |
53 | target and the target path must be used to access the device. | 53 | target and the target path must be used to access the device. |
diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py index 3fe0d812dcec..54d29c1320ed 100755 --- a/Documentation/target/tcm_mod_builder.py +++ b/Documentation/target/tcm_mod_builder.py | |||
@@ -300,7 +300,7 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): | |||
300 | buf += " int ret;\n\n" | 300 | buf += " int ret;\n\n" |
301 | buf += " if (strstr(name, \"tpgt_\") != name)\n" | 301 | buf += " if (strstr(name, \"tpgt_\") != name)\n" |
302 | buf += " return ERR_PTR(-EINVAL);\n" | 302 | buf += " return ERR_PTR(-EINVAL);\n" |
303 | buf += " if (strict_strtoul(name + 5, 10, &tpgt) || tpgt > UINT_MAX)\n" | 303 | buf += " if (kstrtoul(name + 5, 10, &tpgt) || tpgt > UINT_MAX)\n" |
304 | buf += " return ERR_PTR(-EINVAL);\n\n" | 304 | buf += " return ERR_PTR(-EINVAL);\n\n" |
305 | buf += " tpg = kzalloc(sizeof(struct " + fabric_mod_name + "_tpg), GFP_KERNEL);\n" | 305 | buf += " tpg = kzalloc(sizeof(struct " + fabric_mod_name + "_tpg), GFP_KERNEL);\n" |
306 | buf += " if (!tpg) {\n" | 306 | buf += " if (!tpg) {\n" |
diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt index 88697584242b..cca122f25120 100644 --- a/Documentation/timers/NO_HZ.txt +++ b/Documentation/timers/NO_HZ.txt | |||
@@ -24,8 +24,8 @@ There are three main ways of managing scheduling-clock interrupts | |||
24 | workloads, you will normally -not- want this option. | 24 | workloads, you will normally -not- want this option. |
25 | 25 | ||
26 | These three cases are described in the following three sections, followed | 26 | These three cases are described in the following three sections, followed |
27 | by a third section on RCU-specific considerations and a fourth and final | 27 | by a third section on RCU-specific considerations, a fourth section |
28 | section listing known issues. | 28 | discussing testing, and a fifth and final section listing known issues. |
29 | 29 | ||
30 | 30 | ||
31 | NEVER OMIT SCHEDULING-CLOCK TICKS | 31 | NEVER OMIT SCHEDULING-CLOCK TICKS |
@@ -121,14 +121,15 @@ boot parameter specifies the adaptive-ticks CPUs. For example, | |||
121 | "nohz_full=1,6-8" says that CPUs 1, 6, 7, and 8 are to be adaptive-ticks | 121 | "nohz_full=1,6-8" says that CPUs 1, 6, 7, and 8 are to be adaptive-ticks |
122 | CPUs. Note that you are prohibited from marking all of the CPUs as | 122 | CPUs. Note that you are prohibited from marking all of the CPUs as |
123 | adaptive-tick CPUs: At least one non-adaptive-tick CPU must remain | 123 | adaptive-tick CPUs: At least one non-adaptive-tick CPU must remain |
124 | online to handle timekeeping tasks in order to ensure that system calls | 124 | online to handle timekeeping tasks in order to ensure that system |
125 | like gettimeofday() returns accurate values on adaptive-tick CPUs. | 125 | calls like gettimeofday() returns accurate values on adaptive-tick CPUs. |
126 | (This is not an issue for CONFIG_NO_HZ_IDLE=y because there are no | 126 | (This is not an issue for CONFIG_NO_HZ_IDLE=y because there are no running |
127 | running user processes to observe slight drifts in clock rate.) | 127 | user processes to observe slight drifts in clock rate.) Therefore, the |
128 | Therefore, the boot CPU is prohibited from entering adaptive-ticks | 128 | boot CPU is prohibited from entering adaptive-ticks mode. Specifying a |
129 | mode. Specifying a "nohz_full=" mask that includes the boot CPU will | 129 | "nohz_full=" mask that includes the boot CPU will result in a boot-time |
130 | result in a boot-time error message, and the boot CPU will be removed | 130 | error message, and the boot CPU will be removed from the mask. Note that |
131 | from the mask. | 131 | this means that your system must have at least two CPUs in order for |
132 | CONFIG_NO_HZ_FULL=y to do anything for you. | ||
132 | 133 | ||
133 | Alternatively, the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter specifies | 134 | Alternatively, the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter specifies |
134 | that all CPUs other than the boot CPU are adaptive-ticks CPUs. This | 135 | that all CPUs other than the boot CPU are adaptive-ticks CPUs. This |
@@ -232,6 +233,29 @@ scheduler will decide where to run them, which might or might not be | |||
232 | where you want them to run. | 233 | where you want them to run. |
233 | 234 | ||
234 | 235 | ||
236 | TESTING | ||
237 | |||
238 | So you enable all the OS-jitter features described in this document, | ||
239 | but do not see any change in your workload's behavior. Is this because | ||
240 | your workload isn't affected that much by OS jitter, or is it because | ||
241 | something else is in the way? This section helps answer this question | ||
242 | by providing a simple OS-jitter test suite, which is available on branch | ||
243 | master of the following git archive: | ||
244 | |||
245 | git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git | ||
246 | |||
247 | Clone this archive and follow the instructions in the README file. | ||
248 | This test procedure will produce a trace that will allow you to evaluate | ||
249 | whether or not you have succeeded in removing OS jitter from your system. | ||
250 | If this trace shows that you have removed OS jitter as much as is | ||
251 | possible, then you can conclude that your workload is not all that | ||
252 | sensitive to OS jitter. | ||
253 | |||
254 | Note: this test requires that your system have at least two CPUs. | ||
255 | We do not currently have a good way to remove OS jitter from single-CPU | ||
256 | systems. | ||
257 | |||
258 | |||
235 | KNOWN ISSUES | 259 | KNOWN ISSUES |
236 | 260 | ||
237 | o Dyntick-idle slows transitions to and from idle slightly. | 261 | o Dyntick-idle slows transitions to and from idle slightly. |
diff --git a/Documentation/tpm/xen-tpmfront.txt b/Documentation/tpm/xen-tpmfront.txt new file mode 100644 index 000000000000..69346de87ff3 --- /dev/null +++ b/Documentation/tpm/xen-tpmfront.txt | |||
@@ -0,0 +1,113 @@ | |||
1 | Virtual TPM interface for Xen | ||
2 | |||
3 | Authors: Matthew Fioravante (JHUAPL), Daniel De Graaf (NSA) | ||
4 | |||
5 | This document describes the virtual Trusted Platform Module (vTPM) subsystem for | ||
6 | Xen. The reader is assumed to have familiarity with building and installing Xen, | ||
7 | Linux, and a basic understanding of the TPM and vTPM concepts. | ||
8 | |||
9 | INTRODUCTION | ||
10 | |||
11 | The goal of this work is to provide a TPM functionality to a virtual guest | ||
12 | operating system (in Xen terms, a DomU). This allows programs to interact with | ||
13 | a TPM in a virtual system the same way they interact with a TPM on the physical | ||
14 | system. Each guest gets its own unique, emulated, software TPM. However, each | ||
15 | of the vTPM's secrets (Keys, NVRAM, etc) are managed by a vTPM Manager domain, | ||
16 | which seals the secrets to the Physical TPM. If the process of creating each of | ||
17 | these domains (manager, vTPM, and guest) is trusted, the vTPM subsystem extends | ||
18 | the chain of trust rooted in the hardware TPM to virtual machines in Xen. Each | ||
19 | major component of vTPM is implemented as a separate domain, providing secure | ||
20 | separation guaranteed by the hypervisor. The vTPM domains are implemented in | ||
21 | mini-os to reduce memory and processor overhead. | ||
22 | |||
23 | This mini-os vTPM subsystem was built on top of the previous vTPM work done by | ||
24 | IBM and Intel corporation. | ||
25 | |||
26 | |||
27 | DESIGN OVERVIEW | ||
28 | --------------- | ||
29 | |||
30 | The architecture of vTPM is described below: | ||
31 | |||
32 | +------------------+ | ||
33 | | Linux DomU | ... | ||
34 | | | ^ | | ||
35 | | v | | | ||
36 | | xen-tpmfront | | ||
37 | +------------------+ | ||
38 | | ^ | ||
39 | v | | ||
40 | +------------------+ | ||
41 | | mini-os/tpmback | | ||
42 | | | ^ | | ||
43 | | v | | | ||
44 | | vtpm-stubdom | ... | ||
45 | | | ^ | | ||
46 | | v | | | ||
47 | | mini-os/tpmfront | | ||
48 | +------------------+ | ||
49 | | ^ | ||
50 | v | | ||
51 | +------------------+ | ||
52 | | mini-os/tpmback | | ||
53 | | | ^ | | ||
54 | | v | | | ||
55 | | vtpmmgr-stubdom | | ||
56 | | | ^ | | ||
57 | | v | | | ||
58 | | mini-os/tpm_tis | | ||
59 | +------------------+ | ||
60 | | ^ | ||
61 | v | | ||
62 | +------------------+ | ||
63 | | Hardware TPM | | ||
64 | +------------------+ | ||
65 | |||
66 | * Linux DomU: The Linux based guest that wants to use a vTPM. There may be | ||
67 | more than one of these. | ||
68 | |||
69 | * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver | ||
70 | provides vTPM access to a Linux-based DomU. | ||
71 | |||
72 | * mini-os/tpmback: Mini-os TPM backend driver. The Linux frontend driver | ||
73 | connects to this backend driver to facilitate communications | ||
74 | between the Linux DomU and its vTPM. This driver is also | ||
75 | used by vtpmmgr-stubdom to communicate with vtpm-stubdom. | ||
76 | |||
77 | * vtpm-stubdom: A mini-os stub domain that implements a vTPM. There is a | ||
78 | one to one mapping between running vtpm-stubdom instances and | ||
79 | logical vtpms on the system. The vTPM Platform Configuration | ||
80 | Registers (PCRs) are normally all initialized to zero. | ||
81 | |||
82 | * mini-os/tpmfront: Mini-os TPM frontend driver. The vTPM mini-os domain | ||
83 | vtpm-stubdom uses this driver to communicate with | ||
84 | vtpmmgr-stubdom. This driver is also used in mini-os | ||
85 | domains such as pv-grub that talk to the vTPM domain. | ||
86 | |||
87 | * vtpmmgr-stubdom: A mini-os domain that implements the vTPM manager. There is | ||
88 | only one vTPM manager and it should be running during the | ||
89 | entire lifetime of the machine. This domain regulates | ||
90 | access to the physical TPM on the system and secures the | ||
91 | persistent state of each vTPM. | ||
92 | |||
93 | * mini-os/tpm_tis: Mini-os TPM version 1.2 TPM Interface Specification (TIS) | ||
94 | driver. This driver used by vtpmmgr-stubdom to talk directly to | ||
95 | the hardware TPM. Communication is facilitated by mapping | ||
96 | hardware memory pages into vtpmmgr-stubdom. | ||
97 | |||
98 | * Hardware TPM: The physical TPM that is soldered onto the motherboard. | ||
99 | |||
100 | |||
101 | INTEGRATION WITH XEN | ||
102 | -------------------- | ||
103 | |||
104 | Support for the vTPM driver was added in Xen using the libxl toolstack in Xen | ||
105 | 4.3. See the Xen documentation (docs/misc/vtpm.txt) for details on setting up | ||
106 | the vTPM and vTPM Manager stub domains. Once the stub domains are running, a | ||
107 | vTPM device is set up in the same manner as a disk or network device in the | ||
108 | domain's configuration file. | ||
109 | |||
110 | In order to use features such as IMA that require a TPM to be loaded prior to | ||
111 | the initrd, the xen-tpmfront driver must be compiled in to the kernel. If not | ||
112 | using such features, the driver can be compiled as a module and will be loaded | ||
113 | as usual. | ||
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index b937c6e2163c..ea2d35d64d26 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt | |||
@@ -735,7 +735,7 @@ Here are the available options: | |||
735 | function as well as the function being traced. | 735 | function as well as the function being traced. |
736 | 736 | ||
737 | print-parent: | 737 | print-parent: |
738 | bash-4000 [01] 1477.606694: simple_strtoul <-strict_strtoul | 738 | bash-4000 [01] 1477.606694: simple_strtoul <-kstrtoul |
739 | 739 | ||
740 | noprint-parent: | 740 | noprint-parent: |
741 | bash-4000 [01] 1477.606694: simple_strtoul | 741 | bash-4000 [01] 1477.606694: simple_strtoul |
@@ -759,7 +759,7 @@ Here are the available options: | |||
759 | latency-format option is enabled. | 759 | latency-format option is enabled. |
760 | 760 | ||
761 | bash 4000 1 0 00000000 00010a95 [58127d26] 1720.415ms \ | 761 | bash 4000 1 0 00000000 00010a95 [58127d26] 1720.415ms \ |
762 | (+0.000ms): simple_strtoul (strict_strtoul) | 762 | (+0.000ms): simple_strtoul (kstrtoul) |
763 | 763 | ||
764 | raw - This will display raw numbers. This option is best for | 764 | raw - This will display raw numbers. This option is best for |
765 | use with user applications that can translate the raw | 765 | use with user applications that can translate the raw |
diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt index da49437d5aeb..ac4170dd0f24 100644 --- a/Documentation/trace/tracepoints.txt +++ b/Documentation/trace/tracepoints.txt | |||
@@ -40,7 +40,13 @@ Two elements are required for tracepoints : | |||
40 | 40 | ||
41 | In order to use tracepoints, you should include linux/tracepoint.h. | 41 | In order to use tracepoints, you should include linux/tracepoint.h. |
42 | 42 | ||
43 | In include/trace/subsys.h : | 43 | In include/trace/events/subsys.h : |
44 | |||
45 | #undef TRACE_SYSTEM | ||
46 | #define TRACE_SYSTEM subsys | ||
47 | |||
48 | #if !defined(_TRACE_SUBSYS_H) || defined(TRACE_HEADER_MULTI_READ) | ||
49 | #define _TRACE_SUBSYS_H | ||
44 | 50 | ||
45 | #include <linux/tracepoint.h> | 51 | #include <linux/tracepoint.h> |
46 | 52 | ||
@@ -48,10 +54,16 @@ DECLARE_TRACE(subsys_eventname, | |||
48 | TP_PROTO(int firstarg, struct task_struct *p), | 54 | TP_PROTO(int firstarg, struct task_struct *p), |
49 | TP_ARGS(firstarg, p)); | 55 | TP_ARGS(firstarg, p)); |
50 | 56 | ||
57 | #endif /* _TRACE_SUBSYS_H */ | ||
58 | |||
59 | /* This part must be outside protection */ | ||
60 | #include <trace/define_trace.h> | ||
61 | |||
51 | In subsys/file.c (where the tracing statement must be added) : | 62 | In subsys/file.c (where the tracing statement must be added) : |
52 | 63 | ||
53 | #include <trace/subsys.h> | 64 | #include <trace/events/subsys.h> |
54 | 65 | ||
66 | #define CREATE_TRACE_POINTS | ||
55 | DEFINE_TRACE(subsys_eventname); | 67 | DEFINE_TRACE(subsys_eventname); |
56 | 68 | ||
57 | void somefct(void) | 69 | void somefct(void) |
@@ -72,6 +84,9 @@ Where : | |||
72 | - TP_ARGS(firstarg, p) are the parameters names, same as found in the | 84 | - TP_ARGS(firstarg, p) are the parameters names, same as found in the |
73 | prototype. | 85 | prototype. |
74 | 86 | ||
87 | - if you use the header in multiple source files, #define CREATE_TRACE_POINTS | ||
88 | should appear only in one source file. | ||
89 | |||
75 | Connecting a function (probe) to a tracepoint is done by providing a | 90 | Connecting a function (probe) to a tracepoint is done by providing a |
76 | probe (function to call) for the specific tracepoint through | 91 | probe (function to call) for the specific tracepoint through |
77 | register_trace_subsys_eventname(). Removing a probe is done through | 92 | register_trace_subsys_eventname(). Removing a probe is done through |
diff --git a/Documentation/usb/URB.txt b/Documentation/usb/URB.txt index 00d2c644068e..50da0d455444 100644 --- a/Documentation/usb/URB.txt +++ b/Documentation/usb/URB.txt | |||
@@ -195,13 +195,12 @@ by the completion handler. | |||
195 | 195 | ||
196 | The handler is of the following type: | 196 | The handler is of the following type: |
197 | 197 | ||
198 | typedef void (*usb_complete_t)(struct urb *, struct pt_regs *) | 198 | typedef void (*usb_complete_t)(struct urb *) |
199 | 199 | ||
200 | I.e., it gets the URB that caused the completion call, plus the | 200 | I.e., it gets the URB that caused the completion call. In the completion |
201 | register values at the time of the corresponding interrupt (if any). | 201 | handler, you should have a look at urb->status to detect any USB errors. |
202 | In the completion handler, you should have a look at urb->status to | 202 | Since the context parameter is included in the URB, you can pass |
203 | detect any USB errors. Since the context parameter is included in the URB, | 203 | information to the completion handler. |
204 | you can pass information to the completion handler. | ||
205 | 204 | ||
206 | Note that even when an error (or unlink) is reported, data may have been | 205 | Note that even when an error (or unlink) is reported, data may have been |
207 | transferred. That's because USB transfers are packetized; it might take | 206 | transferred. That's because USB transfers are packetized; it might take |
@@ -210,12 +209,12 @@ have transferred successfully before the completion was called. | |||
210 | 209 | ||
211 | 210 | ||
212 | NOTE: ***** WARNING ***** | 211 | NOTE: ***** WARNING ***** |
213 | NEVER SLEEP IN A COMPLETION HANDLER. These are normally called | 212 | NEVER SLEEP IN A COMPLETION HANDLER. These are often called in atomic |
214 | during hardware interrupt processing. If you can, defer substantial | 213 | context. |
215 | work to a tasklet (bottom half) to keep system latencies low. You'll | ||
216 | probably need to use spinlocks to protect data structures you manipulate | ||
217 | in completion handlers. | ||
218 | 214 | ||
215 | In the current kernel, completion handlers run with local interrupts | ||
216 | disabled, but in the future this will be changed, so don't assume that | ||
217 | local IRQs are always disabled inside completion handlers. | ||
219 | 218 | ||
220 | 1.8. How to do isochronous (ISO) transfers? | 219 | 1.8. How to do isochronous (ISO) transfers? |
221 | 220 | ||
diff --git a/Documentation/usb/proc_usb_info.txt b/Documentation/usb/proc_usb_info.txt index c9c3f0f5ad7b..98be91982677 100644 --- a/Documentation/usb/proc_usb_info.txt +++ b/Documentation/usb/proc_usb_info.txt | |||
@@ -54,9 +54,12 @@ it and 002/048 sometime later. | |||
54 | 54 | ||
55 | These files can be read as binary data. The binary data consists | 55 | These files can be read as binary data. The binary data consists |
56 | of first the device descriptor, then the descriptors for each | 56 | of first the device descriptor, then the descriptors for each |
57 | configuration of the device. Multi-byte fields in the device and | 57 | configuration of the device. Multi-byte fields in the device descriptor |
58 | configuration descriptors, but not other descriptors, are converted | 58 | are converted to host endianness by the kernel. The configuration |
59 | to host endianness by the kernel. This information is also shown | 59 | descriptors are in bus endian format! The configuration descriptor |
60 | are wTotalLength bytes apart. If a device returns less configuration | ||
61 | descriptor data than indicated by wTotalLength there will be a hole in | ||
62 | the file for the missing bytes. This information is also shown | ||
60 | in text form by the /proc/bus/usb/devices file, described later. | 63 | in text form by the /proc/bus/usb/devices file, described later. |
61 | 64 | ||
62 | These files may also be used to write user-level drivers for the USB | 65 | These files may also be used to write user-level drivers for the USB |
diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt index 676f87366025..06cf3ac83631 100644 --- a/Documentation/video4linux/v4l2-controls.txt +++ b/Documentation/video4linux/v4l2-controls.txt | |||
@@ -124,26 +124,27 @@ You add non-menu controls by calling v4l2_ctrl_new_std: | |||
124 | const struct v4l2_ctrl_ops *ops, | 124 | const struct v4l2_ctrl_ops *ops, |
125 | u32 id, s32 min, s32 max, u32 step, s32 def); | 125 | u32 id, s32 min, s32 max, u32 step, s32 def); |
126 | 126 | ||
127 | Menu controls are added by calling v4l2_ctrl_new_std_menu: | 127 | Menu and integer menu controls are added by calling v4l2_ctrl_new_std_menu: |
128 | 128 | ||
129 | struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl, | 129 | struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl, |
130 | const struct v4l2_ctrl_ops *ops, | 130 | const struct v4l2_ctrl_ops *ops, |
131 | u32 id, s32 max, s32 skip_mask, s32 def); | 131 | u32 id, s32 max, s32 skip_mask, s32 def); |
132 | 132 | ||
133 | Or alternatively for integer menu controls, by calling v4l2_ctrl_new_int_menu: | 133 | Menu controls with a driver specific menu are added by calling |
134 | v4l2_ctrl_new_std_menu_items: | ||
135 | |||
136 | struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items( | ||
137 | struct v4l2_ctrl_handler *hdl, | ||
138 | const struct v4l2_ctrl_ops *ops, u32 id, s32 max, | ||
139 | s32 skip_mask, s32 def, const char * const *qmenu); | ||
140 | |||
141 | Integer menu controls with a driver specific menu can be added by calling | ||
142 | v4l2_ctrl_new_int_menu: | ||
134 | 143 | ||
135 | struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl, | 144 | struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl, |
136 | const struct v4l2_ctrl_ops *ops, | 145 | const struct v4l2_ctrl_ops *ops, |
137 | u32 id, s32 max, s32 def, const s64 *qmenu_int); | 146 | u32 id, s32 max, s32 def, const s64 *qmenu_int); |
138 | 147 | ||
139 | Standard menu controls with a driver specific menu are added by calling | ||
140 | v4l2_ctrl_new_std_menu_items: | ||
141 | |||
142 | struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items( | ||
143 | struct v4l2_ctrl_handler *hdl, | ||
144 | const struct v4l2_ctrl_ops *ops, u32 id, s32 max, | ||
145 | s32 skip_mask, s32 def, const char * const *qmenu); | ||
146 | |||
147 | These functions are typically called right after the v4l2_ctrl_handler_init: | 148 | These functions are typically called right after the v4l2_ctrl_handler_init: |
148 | 149 | ||
149 | static const s64 exp_bias_qmenu[] = { | 150 | static const s64 exp_bias_qmenu[] = { |
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index ef925eaa1460..858aecf21db2 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt | |||
@@ -53,7 +53,7 @@ incompatible change are allowed. However, there is an extension | |||
53 | facility that allows backward-compatible extensions to the API to be | 53 | facility that allows backward-compatible extensions to the API to be |
54 | queried and used. | 54 | queried and used. |
55 | 55 | ||
56 | The extension mechanism is not based on on the Linux version number. | 56 | The extension mechanism is not based on the Linux version number. |
57 | Instead, kvm defines extension identifiers and a facility to query | 57 | Instead, kvm defines extension identifiers and a facility to query |
58 | whether a particular extension identifier is available. If it is, a | 58 | whether a particular extension identifier is available. If it is, a |
59 | set of ioctls is available for application use. | 59 | set of ioctls is available for application use. |
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 83afe65d4966..22ff659bc0fb 100644 --- a/Documentation/virtual/kvm/cpuid.txt +++ b/Documentation/virtual/kvm/cpuid.txt | |||
@@ -43,6 +43,10 @@ KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock available at msrs | |||
43 | KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by | 43 | KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by |
44 | || || writing to msr 0x4b564d02 | 44 | || || writing to msr 0x4b564d02 |
45 | ------------------------------------------------------------------------------ | 45 | ------------------------------------------------------------------------------ |
46 | KVM_FEATURE_PV_UNHALT || 7 || guest checks this feature bit | ||
47 | || || before enabling paravirtualized | ||
48 | || || spinlock support. | ||
49 | ------------------------------------------------------------------------------ | ||
46 | KVM_FEATURE_CLOCKSOURCE_STABLE_BIT || 24 || host will warn if no guest-side | 50 | KVM_FEATURE_CLOCKSOURCE_STABLE_BIT || 24 || host will warn if no guest-side |
47 | || || per-cpu warps are expected in | 51 | || || per-cpu warps are expected in |
48 | || || kvmclock. | 52 | || || kvmclock. |
diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt index ea113b5d87a4..022198e389d7 100644 --- a/Documentation/virtual/kvm/hypercalls.txt +++ b/Documentation/virtual/kvm/hypercalls.txt | |||
@@ -64,3 +64,17 @@ Purpose: To enable communication between the hypervisor and guest there is a | |||
64 | shared page that contains parts of supervisor visible register state. | 64 | shared page that contains parts of supervisor visible register state. |
65 | The guest can map this shared page to access its supervisor register through | 65 | The guest can map this shared page to access its supervisor register through |
66 | memory using this hypercall. | 66 | memory using this hypercall. |
67 | |||
68 | 5. KVM_HC_KICK_CPU | ||
69 | ------------------------ | ||
70 | Architecture: x86 | ||
71 | Status: active | ||
72 | Purpose: Hypercall used to wakeup a vcpu from HLT state | ||
73 | Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest | ||
74 | kernel mode for an event to occur (ex: a spinlock to become available) can | ||
75 | execute HLT instruction once it has busy-waited for more than a threshold | ||
76 | time-interval. Execution of HLT instruction would cause the hypervisor to put | ||
77 | the vcpu to sleep until occurence of an appropriate event. Another vcpu of the | ||
78 | same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall, | ||
79 | specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0) | ||
80 | is used in the hypercall for future use. | ||
diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt index a6ab4b62d926..f81a65b54c29 100644 --- a/Documentation/workqueue.txt +++ b/Documentation/workqueue.txt | |||
@@ -85,32 +85,31 @@ workqueue. | |||
85 | Special purpose threads, called worker threads, execute the functions | 85 | Special purpose threads, called worker threads, execute the functions |
86 | off of the queue, one after the other. If no work is queued, the | 86 | off of the queue, one after the other. If no work is queued, the |
87 | worker threads become idle. These worker threads are managed in so | 87 | worker threads become idle. These worker threads are managed in so |
88 | called thread-pools. | 88 | called worker-pools. |
89 | 89 | ||
90 | The cmwq design differentiates between the user-facing workqueues that | 90 | The cmwq design differentiates between the user-facing workqueues that |
91 | subsystems and drivers queue work items on and the backend mechanism | 91 | subsystems and drivers queue work items on and the backend mechanism |
92 | which manages thread-pools and processes the queued work items. | 92 | which manages worker-pools and processes the queued work items. |
93 | 93 | ||
94 | The backend is called gcwq. There is one gcwq for each possible CPU | 94 | There are two worker-pools, one for normal work items and the other |
95 | and one gcwq to serve work items queued on unbound workqueues. Each | 95 | for high priority ones, for each possible CPU and some extra |
96 | gcwq has two thread-pools - one for normal work items and the other | 96 | worker-pools to serve work items queued on unbound workqueues - the |
97 | for high priority ones. | 97 | number of these backing pools is dynamic. |
98 | 98 | ||
99 | Subsystems and drivers can create and queue work items through special | 99 | Subsystems and drivers can create and queue work items through special |
100 | workqueue API functions as they see fit. They can influence some | 100 | workqueue API functions as they see fit. They can influence some |
101 | aspects of the way the work items are executed by setting flags on the | 101 | aspects of the way the work items are executed by setting flags on the |
102 | workqueue they are putting the work item on. These flags include | 102 | workqueue they are putting the work item on. These flags include |
103 | things like CPU locality, reentrancy, concurrency limits, priority and | 103 | things like CPU locality, concurrency limits, priority and more. To |
104 | more. To get a detailed overview refer to the API description of | 104 | get a detailed overview refer to the API description of |
105 | alloc_workqueue() below. | 105 | alloc_workqueue() below. |
106 | 106 | ||
107 | When a work item is queued to a workqueue, the target gcwq and | 107 | When a work item is queued to a workqueue, the target worker-pool is |
108 | thread-pool is determined according to the queue parameters and | 108 | determined according to the queue parameters and workqueue attributes |
109 | workqueue attributes and appended on the shared worklist of the | 109 | and appended on the shared worklist of the worker-pool. For example, |
110 | thread-pool. For example, unless specifically overridden, a work item | 110 | unless specifically overridden, a work item of a bound workqueue will |
111 | of a bound workqueue will be queued on the worklist of either normal | 111 | be queued on the worklist of either normal or highpri worker-pool that |
112 | or highpri thread-pool of the gcwq that is associated to the CPU the | 112 | is associated to the CPU the issuer is running on. |
113 | issuer is running on. | ||
114 | 113 | ||
115 | For any worker pool implementation, managing the concurrency level | 114 | For any worker pool implementation, managing the concurrency level |
116 | (how many execution contexts are active) is an important issue. cmwq | 115 | (how many execution contexts are active) is an important issue. cmwq |
@@ -118,14 +117,14 @@ tries to keep the concurrency at a minimal but sufficient level. | |||
118 | Minimal to save resources and sufficient in that the system is used at | 117 | Minimal to save resources and sufficient in that the system is used at |
119 | its full capacity. | 118 | its full capacity. |
120 | 119 | ||
121 | Each thread-pool bound to an actual CPU implements concurrency | 120 | Each worker-pool bound to an actual CPU implements concurrency |
122 | management by hooking into the scheduler. The thread-pool is notified | 121 | management by hooking into the scheduler. The worker-pool is notified |
123 | whenever an active worker wakes up or sleeps and keeps track of the | 122 | whenever an active worker wakes up or sleeps and keeps track of the |
124 | number of the currently runnable workers. Generally, work items are | 123 | number of the currently runnable workers. Generally, work items are |
125 | not expected to hog a CPU and consume many cycles. That means | 124 | not expected to hog a CPU and consume many cycles. That means |
126 | maintaining just enough concurrency to prevent work processing from | 125 | maintaining just enough concurrency to prevent work processing from |
127 | stalling should be optimal. As long as there are one or more runnable | 126 | stalling should be optimal. As long as there are one or more runnable |
128 | workers on the CPU, the thread-pool doesn't start execution of a new | 127 | workers on the CPU, the worker-pool doesn't start execution of a new |
129 | work, but, when the last running worker goes to sleep, it immediately | 128 | work, but, when the last running worker goes to sleep, it immediately |
130 | schedules a new worker so that the CPU doesn't sit idle while there | 129 | schedules a new worker so that the CPU doesn't sit idle while there |
131 | are pending work items. This allows using a minimal number of workers | 130 | are pending work items. This allows using a minimal number of workers |
@@ -135,19 +134,20 @@ Keeping idle workers around doesn't cost other than the memory space | |||
135 | for kthreads, so cmwq holds onto idle ones for a while before killing | 134 | for kthreads, so cmwq holds onto idle ones for a while before killing |
136 | them. | 135 | them. |
137 | 136 | ||
138 | For an unbound wq, the above concurrency management doesn't apply and | 137 | For unbound workqueues, the number of backing pools is dynamic. |
139 | the thread-pools for the pseudo unbound CPU try to start executing all | 138 | Unbound workqueue can be assigned custom attributes using |
140 | work items as soon as possible. The responsibility of regulating | 139 | apply_workqueue_attrs() and workqueue will automatically create |
141 | concurrency level is on the users. There is also a flag to mark a | 140 | backing worker pools matching the attributes. The responsibility of |
142 | bound wq to ignore the concurrency management. Please refer to the | 141 | regulating concurrency level is on the users. There is also a flag to |
143 | API section for details. | 142 | mark a bound wq to ignore the concurrency management. Please refer to |
143 | the API section for details. | ||
144 | 144 | ||
145 | Forward progress guarantee relies on that workers can be created when | 145 | Forward progress guarantee relies on that workers can be created when |
146 | more execution contexts are necessary, which in turn is guaranteed | 146 | more execution contexts are necessary, which in turn is guaranteed |
147 | through the use of rescue workers. All work items which might be used | 147 | through the use of rescue workers. All work items which might be used |
148 | on code paths that handle memory reclaim are required to be queued on | 148 | on code paths that handle memory reclaim are required to be queued on |
149 | wq's that have a rescue-worker reserved for execution under memory | 149 | wq's that have a rescue-worker reserved for execution under memory |
150 | pressure. Else it is possible that the thread-pool deadlocks waiting | 150 | pressure. Else it is possible that the worker-pool deadlocks waiting |
151 | for execution contexts to free up. | 151 | for execution contexts to free up. |
152 | 152 | ||
153 | 153 | ||
@@ -166,25 +166,15 @@ resources, scheduled and executed. | |||
166 | 166 | ||
167 | @flags: | 167 | @flags: |
168 | 168 | ||
169 | WQ_NON_REENTRANT | ||
170 | |||
171 | By default, a wq guarantees non-reentrance only on the same | ||
172 | CPU. A work item may not be executed concurrently on the same | ||
173 | CPU by multiple workers but is allowed to be executed | ||
174 | concurrently on multiple CPUs. This flag makes sure | ||
175 | non-reentrance is enforced across all CPUs. Work items queued | ||
176 | to a non-reentrant wq are guaranteed to be executed by at most | ||
177 | one worker system-wide at any given time. | ||
178 | |||
179 | WQ_UNBOUND | 169 | WQ_UNBOUND |
180 | 170 | ||
181 | Work items queued to an unbound wq are served by a special | 171 | Work items queued to an unbound wq are served by the special |
182 | gcwq which hosts workers which are not bound to any specific | 172 | woker-pools which host workers which are not bound to any |
183 | CPU. This makes the wq behave as a simple execution context | 173 | specific CPU. This makes the wq behave as a simple execution |
184 | provider without concurrency management. The unbound gcwq | 174 | context provider without concurrency management. The unbound |
185 | tries to start execution of work items as soon as possible. | 175 | worker-pools try to start execution of work items as soon as |
186 | Unbound wq sacrifices locality but is useful for the following | 176 | possible. Unbound wq sacrifices locality but is useful for |
187 | cases. | 177 | the following cases. |
188 | 178 | ||
189 | * Wide fluctuation in the concurrency level requirement is | 179 | * Wide fluctuation in the concurrency level requirement is |
190 | expected and using bound wq may end up creating large number | 180 | expected and using bound wq may end up creating large number |
@@ -209,10 +199,10 @@ resources, scheduled and executed. | |||
209 | WQ_HIGHPRI | 199 | WQ_HIGHPRI |
210 | 200 | ||
211 | Work items of a highpri wq are queued to the highpri | 201 | Work items of a highpri wq are queued to the highpri |
212 | thread-pool of the target gcwq. Highpri thread-pools are | 202 | worker-pool of the target cpu. Highpri worker-pools are |
213 | served by worker threads with elevated nice level. | 203 | served by worker threads with elevated nice level. |
214 | 204 | ||
215 | Note that normal and highpri thread-pools don't interact with | 205 | Note that normal and highpri worker-pools don't interact with |
216 | each other. Each maintain its separate pool of workers and | 206 | each other. Each maintain its separate pool of workers and |
217 | implements concurrency management among its workers. | 207 | implements concurrency management among its workers. |
218 | 208 | ||
@@ -221,7 +211,7 @@ resources, scheduled and executed. | |||
221 | Work items of a CPU intensive wq do not contribute to the | 211 | Work items of a CPU intensive wq do not contribute to the |
222 | concurrency level. In other words, runnable CPU intensive | 212 | concurrency level. In other words, runnable CPU intensive |
223 | work items will not prevent other work items in the same | 213 | work items will not prevent other work items in the same |
224 | thread-pool from starting execution. This is useful for bound | 214 | worker-pool from starting execution. This is useful for bound |
225 | work items which are expected to hog CPU cycles so that their | 215 | work items which are expected to hog CPU cycles so that their |
226 | execution is regulated by the system scheduler. | 216 | execution is regulated by the system scheduler. |
227 | 217 | ||
@@ -233,6 +223,10 @@ resources, scheduled and executed. | |||
233 | 223 | ||
234 | This flag is meaningless for unbound wq. | 224 | This flag is meaningless for unbound wq. |
235 | 225 | ||
226 | Note that the flag WQ_NON_REENTRANT no longer exists as all workqueues | ||
227 | are now non-reentrant - any work item is guaranteed to be executed by | ||
228 | at most one worker system-wide at any given time. | ||
229 | |||
236 | @max_active: | 230 | @max_active: |
237 | 231 | ||
238 | @max_active determines the maximum number of execution contexts per | 232 | @max_active determines the maximum number of execution contexts per |
@@ -254,9 +248,9 @@ recommended. | |||
254 | 248 | ||
255 | Some users depend on the strict execution ordering of ST wq. The | 249 | Some users depend on the strict execution ordering of ST wq. The |
256 | combination of @max_active of 1 and WQ_UNBOUND is used to achieve this | 250 | combination of @max_active of 1 and WQ_UNBOUND is used to achieve this |
257 | behavior. Work items on such wq are always queued to the unbound gcwq | 251 | behavior. Work items on such wq are always queued to the unbound |
258 | and only one work item can be active at any given time thus achieving | 252 | worker-pools and only one work item can be active at any given time thus |
259 | the same ordering property as ST wq. | 253 | achieving the same ordering property as ST wq. |
260 | 254 | ||
261 | 255 | ||
262 | 5. Example Execution Scenarios | 256 | 5. Example Execution Scenarios |
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt index fc66d42422ee..f4f268c2b826 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt | |||
@@ -58,7 +58,7 @@ Protocol 2.11: (Kernel 3.6) Added a field for offset of EFI handover | |||
58 | protocol entry point. | 58 | protocol entry point. |
59 | 59 | ||
60 | Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields | 60 | Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields |
61 | to struct boot_params for for loading bzImage and ramdisk | 61 | to struct boot_params for loading bzImage and ramdisk |
62 | above 4G in 64bit. | 62 | above 4G in 64bit. |
63 | 63 | ||
64 | **** MEMORY LAYOUT | 64 | **** MEMORY LAYOUT |
diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt index e9e8ddbbf376..1228b22e142b 100644 --- a/Documentation/x86/x86_64/boot-options.txt +++ b/Documentation/x86/x86_64/boot-options.txt | |||
@@ -176,6 +176,11 @@ ACPI | |||
176 | 176 | ||
177 | acpi=noirq Don't route interrupts | 177 | acpi=noirq Don't route interrupts |
178 | 178 | ||
179 | acpi=nocmcff Disable firmware first mode for corrected errors. This | ||
180 | disables parsing the HEST CMC error source to check if | ||
181 | firmware has set the FF flag. This may result in | ||
182 | duplicate corrected error reports. | ||
183 | |||
179 | PCI | 184 | PCI |
180 | 185 | ||
181 | pci=off Don't use PCI | 186 | pci=off Don't use PCI |
diff --git a/Documentation/zh_CN/SubmittingPatches b/Documentation/zh_CN/SubmittingPatches index 0f4385a62a49..be0bd4725062 100644 --- a/Documentation/zh_CN/SubmittingPatches +++ b/Documentation/zh_CN/SubmittingPatches | |||
@@ -146,7 +146,7 @@ Majordomo lists of VGER.KERNEL.ORG at: | |||
146 | <http://vger.kernel.org/vger-lists.html> | 146 | <http://vger.kernel.org/vger-lists.html> |
147 | 147 | ||
148 | 如果改动影响了用户空间和内核之间的接口,请给 MAN-PAGES 的维护者(列在 | 148 | 如果改动影响了用户空间和内核之间的接口,请给 MAN-PAGES 的维护者(列在 |
149 | MAITAINERS 文件里的)发送一个手册页(man-pages)补丁,或者至少通知一下改 | 149 | MAINTAINERS 文件里的)发送一个手册页(man-pages)补丁,或者至少通知一下改 |
150 | 变,让一些信息有途径进入手册页。 | 150 | 变,让一些信息有途径进入手册页。 |
151 | 151 | ||
152 | 即使在第四步的时候,维护者没有作出回应,也要确认在修改他们的代码的时候 | 152 | 即使在第四步的时候,维护者没有作出回应,也要确认在修改他们的代码的时候 |