diff options
Diffstat (limited to 'Documentation')
174 files changed, 4683 insertions, 1461 deletions
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 @@ +What: /sys/bus/usb/devices/.../power/persist +Date: May 2007 +KernelVersion: 2.6.23 +Contact: Alan Stern <stern@rowland.harvard.edu> +Description: + If CONFIG_USB_PERSIST is set, then each USB device directory + will contain a file named power/persist. The file holds a + boolean value (0 or 1) indicating whether or not the + "USB-Persist" facility is enabled for the device. Since the + facility is inherently dangerous, it is disabled by default + for all devices except hubs. For more information, see + Documentation/usb/persist.txt. + +What: /sys/bus/usb/devices/.../power/autosuspend +Date: March 2007 +KernelVersion: 2.6.21 +Contact: Alan Stern <stern@rowland.harvard.edu> +Description: + Each USB device directory will contain a file named + power/autosuspend. This file holds the time (in seconds) + the device must be idle before it will be autosuspended. + 0 means the device will be autosuspended as soon as + possible. Negative values will prevent the device from + being autosuspended at all, and writing a negative value + will resume the device if it is already suspended. + + The autosuspend delay for newly-created devices is set to + the value of the usbcore.autosuspend module parameter. + +What: /sys/bus/usb/device/.../power/connected_duration +Date: January 2008 +KernelVersion: 2.6.25 +Contact: Sarah Sharp <sarah.a.sharp@intel.com> +Description: + If CONFIG_PM_RUNTIME is enabled then this file + is present. When read, it returns the total time (in msec) + that the USB device has been connected to the machine. This + file is read-only. +Users: + PowerTOP <power@bughost.org> + http://www.lesswatts.org/projects/powertop/ + +What: /sys/bus/usb/device/.../power/active_duration +Date: January 2008 +KernelVersion: 2.6.25 +Contact: Sarah Sharp <sarah.a.sharp@intel.com> +Description: + If CONFIG_PM_RUNTIME is enabled then this file + is present. When read, it returns the total time (in msec) + that the USB device has been active, i.e. not in a suspended + state. This file is read-only. + + Tools can use this file and the connected_duration file to + compute the percentage of time that a device has been active. + For example, + echo $((100 * `cat active_duration` / `cat connected_duration`)) + will give an integer percentage. Note that this does not + account for counter wrap. +Users: + PowerTOP <power@bughost.org> + http://www.lesswatts.org/projects/powertop/ + +What: /sys/bus/usb/devices/<busnum>-<port[.port]>...:<config num>-<interface num>/supports_autosuspend +Date: January 2008 +KernelVersion: 2.6.27 +Contact: Sarah Sharp <sarah.a.sharp@intel.com> +Description: + When read, this file returns 1 if the interface driver + for this interface supports autosuspend. It also + returns 1 if no driver has claimed this interface, as an + unclaimed interface will not stop the device from being + autosuspended if all other interface drivers are idle. + The file returns 0 if autosuspend support has not been + added to the driver. +Users: + USB PM tool + git://git.moblin.org/users/sarah/usb-pm-tool/ + +What: /sys/bus/usb/device/.../avoid_reset_quirk +Date: December 2009 +Contact: Oliver Neukum <oliver@neukum.org> +Description: + Writing 1 to this file tells the kernel that this + device will morph into another mode when it is reset. + Drivers will not use reset for error handling for + such devices. +Users: + usb_modeswitch + +What: /sys/bus/usb/devices/.../devnum +KernelVersion: since at least 2.6.18 +Description: + Device address on the USB bus. +Users: + libusb + +What: /sys/bus/usb/devices/.../bConfigurationValue +KernelVersion: since at least 2.6.18 +Description: + bConfigurationValue of the *active* configuration for the + device. Writing 0 or -1 to bConfigurationValue will reset the + active configuration (unconfigure the device). Writing + another value will change the active configuration. + + Note that some devices, in violation of the USB spec, have a + configuration with a value equal to 0. Writing 0 to + bConfigurationValue for these devices will install that + configuration, rather then unconfigure the device. + + Writing -1 will always unconfigure the device. +Users: + libusb + +What: /sys/bus/usb/devices/.../busnum +KernelVersion: 2.6.22 +Description: + Bus-number of the USB-bus the device is connected to. +Users: + libusb + +What: /sys/bus/usb/devices/.../descriptors +KernelVersion: 2.6.26 +Description: + Binary file containing cached descriptors of the device. The + binary data consists of the device descriptor followed by the + descriptors for each configuration of the device. + Note that the wTotalLength of the config descriptors can not + be trusted, as the device may have a smaller config descriptor + than it advertises. The bLength field of each (sub) descriptor + can be trusted, and can be used to seek forward one (sub) + descriptor at a time until the next config descriptor is found. + All descriptors read from this file are in bus-endian format +Users: + libusb + +What: /sys/bus/usb/devices/.../speed +KernelVersion: since at least 2.6.18 +Description: + Speed the device is connected with to the usb-host in + Mbit / second. IE one of 1.5 / 12 / 480 / 5000. +Users: + libusb 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: 6kohm_to_gnd: connected to ground via a 6kOhm resistor, 20kohm_to_gnd: connected to ground via a 20kOhm resistor, 100kohm_to_gnd: connected to ground via an 100kOhm resistor, + 500kohm_to_gnd: connected to ground via a 500kOhm resistor, three_state: left floating. For a list of available output power down options read outX_powerdown_mode_available. If Y is not present the @@ -792,3 +793,21 @@ Contact: linux-iio@vger.kernel.org Description: This attribute is used to read the amount of quadrature error present in the device at a given time. + +What: /sys/.../iio:deviceX/in_accelX_power_mode +KernelVersion: 3.11 +Contact: linux-iio@vger.kernel.org +Description: + Specifies the chip power mode. + low_noise: reduce noise level from ADC, + low_power: enable low current consumption. + For a list of available output power modes read + in_accel_power_mode_available. + +What: /sys/bus/iio/devices/iio:deviceX/store_eeprom +KernelVersion: 3.4.0 +Contact: linux-iio@vger.kernel.org +Description: + Writing '1' stores the current device configuration into + on-chip EEPROM. After power-up or chip reset the device will + 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: Reading returns either '1' or '0'. '1' means that the pllY is locked. -What: /sys/bus/iio/devices/iio:deviceX/store_eeprom -KernelVersion: 3.4.0 -Contact: linux-iio@vger.kernel.org -Description: - Writing '1' stores the current device configuration into - on-chip EEPROM. After power-up or chip reset the device will - automatically load the saved configuration. - What: /sys/bus/iio/devices/iio:deviceX/sync_dividers KernelVersion: 3.4.0 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: adjust the reference frequency accordingly. The value written has no effect until out_altvoltageY_frequency is updated. Consider to use out_altvoltageY_powerdown to power - down the PLL and it's RFOut buffers during REFin changes. + 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 @@ -What: /sys/bus/usb/devices/.../power/autosuspend -Date: March 2007 -KernelVersion: 2.6.21 -Contact: Alan Stern <stern@rowland.harvard.edu> -Description: - Each USB device directory will contain a file named - power/autosuspend. This file holds the time (in seconds) - the device must be idle before it will be autosuspended. - 0 means the device will be autosuspended as soon as - possible. Negative values will prevent the device from - being autosuspended at all, and writing a negative value - will resume the device if it is already suspended. - - The autosuspend delay for newly-created devices is set to - the value of the usbcore.autosuspend module parameter. - -What: /sys/bus/usb/devices/.../power/persist -Date: May 2007 -KernelVersion: 2.6.23 -Contact: Alan Stern <stern@rowland.harvard.edu> -Description: - If CONFIG_USB_PERSIST is set, then each USB device directory - will contain a file named power/persist. The file holds a - boolean value (0 or 1) indicating whether or not the - "USB-Persist" facility is enabled for the device. Since the - facility is inherently dangerous, it is disabled by default - for all devices except hubs. For more information, see - Documentation/usb/persist.txt. - -What: /sys/bus/usb/device/.../power/connected_duration -Date: January 2008 -KernelVersion: 2.6.25 -Contact: Sarah Sharp <sarah.a.sharp@intel.com> -Description: - If CONFIG_PM_RUNTIME is enabled then this file - is present. When read, it returns the total time (in msec) - that the USB device has been connected to the machine. This - file is read-only. -Users: - PowerTOP <power@bughost.org> - http://www.lesswatts.org/projects/powertop/ - -What: /sys/bus/usb/device/.../power/active_duration -Date: January 2008 -KernelVersion: 2.6.25 -Contact: Sarah Sharp <sarah.a.sharp@intel.com> -Description: - If CONFIG_PM_RUNTIME is enabled then this file - is present. When read, it returns the total time (in msec) - that the USB device has been active, i.e. not in a suspended - state. This file is read-only. - - Tools can use this file and the connected_duration file to - compute the percentage of time that a device has been active. - For example, - echo $((100 * `cat active_duration` / `cat connected_duration`)) - will give an integer percentage. Note that this does not - account for counter wrap. -Users: - PowerTOP <power@bughost.org> - http://www.lesswatts.org/projects/powertop/ - -What: /sys/bus/usb/device/<busnum>-<devnum>...:<config num>-<interface num>/supports_autosuspend -Date: January 2008 -KernelVersion: 2.6.27 -Contact: Sarah Sharp <sarah.a.sharp@intel.com> -Description: - When read, this file returns 1 if the interface driver - for this interface supports autosuspend. It also - returns 1 if no driver has claimed this interface, as an - unclaimed interface will not stop the device from being - autosuspended if all other interface drivers are idle. - The file returns 0 if autosuspend support has not been - added to the driver. -Users: - USB PM tool - git://git.moblin.org/users/sarah/usb-pm-tool/ - What: /sys/bus/usb/device/.../authorized Date: July 2008 KernelVersion: 2.6.26 @@ -172,17 +94,6 @@ Description: device IDs, exactly like reading from the entry "/sys/bus/usb/drivers/.../new_id" -What: /sys/bus/usb/device/.../avoid_reset_quirk -Date: December 2009 -Contact: Oliver Neukum <oliver@neukum.org> -Description: - Writing 1 to this file tells the kernel that this - device will morph into another mode when it is reset. - Drivers will not use reset for error handling for - such devices. -Users: - usb_modeswitch - What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm Date: September 2011 Contact: Andiry Xu <andiry.xu@amd.com> 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 @@ <title>functions/definitions</title> !Finclude/net/mac80211.h ieee80211_rx_status !Finclude/net/mac80211.h mac80211_rx_flags +!Finclude/net/mac80211.h mac80211_tx_info_flags !Finclude/net/mac80211.h mac80211_tx_control_flags !Finclude/net/mac80211.h mac80211_rate_control_flags !Finclude/net/mac80211.h ieee80211_tx_rate diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index cbfdf5486639..fe397f90a34f 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -84,7 +84,7 @@ X!Iinclude/linux/kobject.h <sect1><title>Kernel utility functions</title> !Iinclude/linux/kernel.h -!Ekernel/printk.c +!Ekernel/printk/printk.c !Ekernel/panic.c !Ekernel/sys.c !Ekernel/rcupdate.c 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 @@ </para></listitem> </varlistentry> <varlistentry> - <term>DRIVER_USE_MTRR</term> - <listitem><para> - Driver uses MTRR interface for mapping memory, the DRM core will - manage MTRR resources. Deprecated. - </para></listitem> - </varlistentry> - <varlistentry> <term>DRIVER_PCI_DMA</term> <listitem><para> Driver is capable of PCI DMA, mapping of PCI DMA buffers to @@ -195,28 +188,6 @@ </para></listitem> </varlistentry> <varlistentry> - <term>DRIVER_IRQ_VBL</term> - <listitem><para>Unused. Deprecated.</para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_DMA_QUEUE</term> - <listitem><para> - Should be set if the driver queues DMA requests and completes them - asynchronously. Deprecated. - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_FB_DMA</term> - <listitem><para> - Driver supports DMA to/from the framebuffer, mapping of frambuffer - DMA buffers to userspace will be supported. Deprecated. - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRIVER_IRQ_VBL2</term> - <listitem><para>Unused. Deprecated.</para></listitem> - </varlistentry> - <varlistentry> <term>DRIVER_GEM</term> <listitem><para> Driver use the GEM memory manager. @@ -234,6 +205,12 @@ Driver implements DRM PRIME buffer sharing. </para></listitem> </varlistentry> + <varlistentry> + <term>DRIVER_RENDER</term> + <listitem><para> + Driver supports dedicated render nodes. + </para></listitem> + </varlistentry> </variablelist> </sect3> <sect3> @@ -2212,6 +2189,18 @@ void intel_crt_init(struct drm_device *dev) !Iinclude/drm/drm_rect.h !Edrivers/gpu/drm/drm_rect.c </sect2> + <sect2> + <title>Flip-work Helper Reference</title> +!Pinclude/drm/drm_flip_work.h flip utils +!Iinclude/drm/drm_flip_work.h +!Edrivers/gpu/drm/drm_flip_work.c + </sect2> + <sect2> + <title>VMA Offset Manager</title> +!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager +!Edrivers/gpu/drm/drm_vma_manager.c +!Iinclude/drm/drm_vma_manager.h + </sect2> </sect1> <!-- Internals: kms properties --> @@ -2422,18 +2411,18 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis> </abstract> <para> The <methodname>firstopen</methodname> method is called by the DRM core - when an application opens a device that has no other opened file handle. - Similarly the <methodname>lastclose</methodname> method is called when - the last application holding a file handle opened on the device closes - it. Both methods are mostly used for UMS (User Mode Setting) drivers to - acquire and release device resources which should be done in the - <methodname>load</methodname> and <methodname>unload</methodname> - methods for KMS drivers. + for legacy UMS (User Mode Setting) drivers only when an application + opens a device that has no other opened file handle. UMS drivers can + implement it to acquire device resources. KMS drivers can't use the + method and must acquire resources in the <methodname>load</methodname> + method instead. </para> <para> - Note that the <methodname>lastclose</methodname> method is also called - at module unload time or, for hot-pluggable devices, when the device is - unplugged. The <methodname>firstopen</methodname> and + Similarly the <methodname>lastclose</methodname> method is called when + the last application holding a file handle opened on the device closes + it, for both UMS and KMS drivers. Additionally, the method is also + called at module unload time or, for hot-pluggable devices, when the + device is unplugged. The <methodname>firstopen</methodname> and <methodname>lastclose</methodname> calls can thus be unbalanced. </para> <para> @@ -2462,7 +2451,12 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis> <para> The <methodname>lastclose</methodname> method should restore CRTC and plane properties to default value, so that a subsequent open of the - device will not inherit state from the previous user. + device will not inherit state from the previous user. It can also be + used to execute delayed power switching state changes, e.g. in + conjunction with the vga-switcheroo infrastructure. Beyond that KMS + drivers should not do any further cleanup. Only legacy UMS drivers might + need to clean up device state so that the vga console or an independent + fbdev driver could take over. </para> </sect2> <sect2> @@ -2498,7 +2492,6 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis> <programlisting> .poll = drm_poll, .read = drm_read, - .fasync = drm_fasync, .llseek = no_llseek, </programlisting> </para> @@ -2657,6 +2650,69 @@ int (*resume) (struct drm_device *);</synopsis> info, since man pages should cover the rest. </para> + <!-- External: render nodes --> + + <sect1> + <title>Render nodes</title> + <para> + DRM core provides multiple character-devices for user-space to use. + Depending on which device is opened, user-space can perform a different + set of operations (mainly ioctls). The primary node is always created + and called <term>card<num></term>. Additionally, a currently + unused control node, called <term>controlD<num></term> is also + created. The primary node provides all legacy operations and + historically was the only interface used by userspace. With KMS, the + control node was introduced. However, the planned KMS control interface + has never been written and so the control node stays unused to date. + </para> + <para> + With the increased use of offscreen renderers and GPGPU applications, + clients no longer require running compositors or graphics servers to + make use of a GPU. But the DRM API required unprivileged clients to + authenticate to a DRM-Master prior to getting GPU access. To avoid this + step and to grant clients GPU access without authenticating, render + nodes were introduced. Render nodes solely serve render clients, that + is, no modesetting or privileged ioctls can be issued on render nodes. + Only non-global rendering commands are allowed. If a driver supports + render nodes, it must advertise it via the <term>DRIVER_RENDER</term> + DRM driver capability. If not supported, the primary node must be used + for render clients together with the legacy drmAuth authentication + procedure. + </para> + <para> + If a driver advertises render node support, DRM core will create a + separate render node called <term>renderD<num></term>. There will + be one render node per device. No ioctls except PRIME-related ioctls + will be allowed on this node. Especially <term>GEM_OPEN</term> will be + explicitly prohibited. Render nodes are designed to avoid the + buffer-leaks, which occur if clients guess the flink names or mmap + offsets on the legacy interface. Additionally to this basic interface, + drivers must mark their driver-dependent render-only ioctls as + <term>DRM_RENDER_ALLOW</term> so render clients can use them. Driver + authors must be careful not to allow any privileged ioctls on render + nodes. + </para> + <para> + With render nodes, user-space can now control access to the render node + via basic file-system access-modes. A running graphics server which + authenticates clients on the privileged primary/legacy node is no longer + required. Instead, a client can open the render node and is immediately + granted GPU access. Communication between clients (or servers) is done + via PRIME. FLINK from render node to legacy node is not supported. New + clients must not use the insecure FLINK interface. + </para> + <para> + Besides dropping all modeset/global ioctls, render nodes also drop the + DRM-Master concept. There is no reason to associate render clients with + a DRM-Master as they are independent of any graphics server. Besides, + they must work without any running master, anyway. + Drivers must be able to run without a master object if they support + render nodes. If, on the other hand, a driver requires shared state + between clients which is visible to user-space and accessible beyond + open-file boundaries, they cannot support render nodes. + </para> + </sect1> + <!-- External: vblank handling --> <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> </section> <section id="mpeg-controls"> - <title>MPEG Control Reference</title> + <title>Codec Control Reference</title> - <para>Below all controls within the MPEG control class are + <para>Below all controls within the Codec control class are described. First the generic controls, then controls specific for certain hardware.</para> + <para>Note: These controls are applicable to all codecs and +not just MPEG. The defines are prefixed with V4L2_CID_MPEG/V4L2_MPEG +as the controls were originally made for MPEG codecs and later +extended to cover all encoding formats.</para> + <section> - <title>Generic MPEG Controls</title> + <title>Generic Codec Controls</title> <table pgwide="1" frame="none" id="mpeg-control-id"> - <title>MPEG Control IDs</title> + <title>Codec Control IDs</title> <tgroup cols="4"> <colspec colname="c1" colwidth="1*" /> <colspec colname="c2" colwidth="6*" /> @@ -752,7 +757,7 @@ certain hardware.</para> <row> <entry spanname="id"><constant>V4L2_CID_MPEG_CLASS</constant> </entry> <entry>class</entry> - </row><row><entry spanname="descr">The MPEG class + </row><row><entry spanname="descr">The Codec class descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a description of this control class. This description can be used as the 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> </tgroup> </table> </section> + + <section> + <title>VPX Control Reference</title> + + <para>The VPX controls include controls for encoding parameters + of VPx video codec.</para> + + <table pgwide="1" frame="none" id="vpx-control-id"> + <title>VPX Control IDs</title> + + <tgroup cols="4"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="6*" /> + <colspec colname="c3" colwidth="2*" /> + <colspec colname="c4" colwidth="6*" /> + <spanspec namest="c1" nameend="c2" spanname="id" /> + <spanspec namest="c2" nameend="c4" spanname="descr" /> + <thead> + <row> + <entry spanname="id" align="left">ID</entry> + <entry align="left">Type</entry> + </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry> + </row> + </thead> + <tbody valign="top"> + <row><entry></entry></row> + + <row><entry></entry></row> + <row id="v4l2-vpx-num-partitions"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS</constant></entry> + <entry>enum v4l2_vp8_num_partitions</entry> + </row> + <row><entry spanname="descr">The number of token partitions to use in VP8 encoder. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_1_PARTITION</constant></entry> + <entry>1 coefficient partition</entry> + </row> + <row> + <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_2_PARTITIONS</constant></entry> + <entry>2 coefficient partitions</entry> + </row> + <row> + <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_4_PARTITIONS</constant></entry> + <entry>4 coefficient partitions</entry> + </row> + <row> + <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_8_PARTITIONS</constant></entry> + <entry>8 coefficient partitions</entry> + </row> + </tbody> + </entrytbl> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_IMD_DISABLE_4X4</constant></entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Setting this prevents intra 4x4 mode in the intra mode decision.</entry> + </row> + + <row><entry></entry></row> + <row id="v4l2-vpx-num-ref-frames"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES</constant></entry> + <entry>enum v4l2_vp8_num_ref_frames</entry> + </row> + <row><entry spanname="descr">The number of reference pictures for encoding P frames. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_1_REF_FRAME</constant></entry> + <entry>Last encoded frame will be searched</entry> + </row> + <row> + <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_2_REF_FRAME</constant></entry> + <entry>Two frames will be searched among the last encoded frame, the golden frame +and the alternate reference (altref) frame. The encoder implementation will decide which two are chosen.</entry> + </row> + <row> + <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_3_REF_FRAME</constant></entry> + <entry>The last encoded frame, the golden frame and the altref frame will be searched.</entry> + </row> + </tbody> + </entrytbl> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_FILTER_LEVEL</constant></entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Indicates the loop filter level. The adjustment of the loop +filter level is done via a delta value against a baseline loop filter value.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_FILTER_SHARPNESS</constant></entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">This parameter affects the loop filter. Anything above +zero weakens the deblocking effect on the loop filter.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD</constant></entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Sets the refresh period for the golden frame. The period is defined +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. +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 +0, 4, 8 etc will be taken as the golden frames as frame 0 is always a key frame.</entry> + </row> + + <row><entry></entry></row> + <row id="v4l2-vpx-golden-frame-sel"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL</constant></entry> + <entry>enum v4l2_vp8_golden_frame_sel</entry> + </row> + <row><entry spanname="descr">Selects the golden frame for encoding. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_USE_PREV</constant></entry> + <entry>Use the (n-2)th frame as a golden frame, current frame index being 'n'.</entry> + </row> + <row> + <entry><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_USE_REF_PERIOD</constant></entry> + <entry>Use the previous specific frame indicated by +V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a golden frame.</entry> + </row> + </tbody> + </entrytbl> + </row> + + <row><entry></entry></row> + </tbody> + </tgroup> + </table> + + </section> </section> <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> values. Pulses and spaces are only marked implicitly by their position. The data must start and end with a pulse, therefore, the data must always include an uneven number of samples. The write function must block until the data has -been transmitted by the hardware.</para> +been transmitted by the hardware. If more data is provided than the hardware +can send, the driver returns EINVAL.</para> + </section> <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 @@ + <refentry> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M ('NM61')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname id="V4L2-PIX-FMT-NV16M"><constant>V4L2_PIX_FMT_NV16M</constant></refname> + <refname id="V4L2-PIX-FMT-NV61M"><constant>V4L2_PIX_FMT_NV61M</constant></refname> + <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV16</constant> and <constant>V4L2_PIX_FMT_NV61</constant> with planes + non contiguous in memory. </refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This is a multi-planar, two-plane version of the YUV 4:2:0 format. +The three components are separated into two sub-images or planes. +<constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16 +</constant> in that the two planes are non-contiguous in memory, i.e. the chroma +plane does not necessarily immediately follows the luma plane. +The luminance data occupies the first plane. The Y plane has one byte per pixel. +In the second plane there is chrominance data with alternating chroma samples. +The CbCr plane is the same width and height, in bytes, as the Y plane. +Each CbCr pair belongs to four pixels. For example, +Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to +Y'<subscript>00</subscript>, Y'<subscript>01</subscript>, +Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. +<constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant> +except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para> + + <para><constant>V4L2_PIX_FMT_NV16M</constant> and +<constant>V4L2_PIX_FMT_NV61M</constant> are intended to be used only in drivers +and applications that support the multi-planar API, described in +<xref linkend="planar-apis"/>. </para> + + <example> + <title><constant>V4L2_PIX_FMT_NV16M</constant> 4 × 4 pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start0 + 0:</entry> + <entry>Y'<subscript>00</subscript></entry> + <entry>Y'<subscript>01</subscript></entry> + <entry>Y'<subscript>02</subscript></entry> + <entry>Y'<subscript>03</subscript></entry> + </row> + <row> + <entry>start0 + 4:</entry> + <entry>Y'<subscript>10</subscript></entry> + <entry>Y'<subscript>11</subscript></entry> + <entry>Y'<subscript>12</subscript></entry> + <entry>Y'<subscript>13</subscript></entry> + </row> + <row> + <entry>start0 + 8:</entry> + <entry>Y'<subscript>20</subscript></entry> + <entry>Y'<subscript>21</subscript></entry> + <entry>Y'<subscript>22</subscript></entry> + <entry>Y'<subscript>23</subscript></entry> + </row> + <row> + <entry>start0 + 12:</entry> + <entry>Y'<subscript>30</subscript></entry> + <entry>Y'<subscript>31</subscript></entry> + <entry>Y'<subscript>32</subscript></entry> + <entry>Y'<subscript>33</subscript></entry> + </row> + <row> + <entry></entry> + </row> + <row> + <entry>start1 + 0:</entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Cb<subscript>02</subscript></entry> + <entry>Cr<subscript>02</subscript></entry> + </row> + <row> + <entry>start1 + 4:</entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Cb<subscript>12</subscript></entry> + <entry>Cr<subscript>12</subscript></entry> + </row> + <row> + <entry>start1 + 8:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Cb<subscript>22</subscript></entry> + <entry>Cr<subscript>22</subscript></entry> + </row> + <row> + <entry>start1 + 12:</entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Cb<subscript>32</subscript></entry> + <entry>Cr<subscript>32</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + + <formalpara> + <title>Color Sample Location.</title> + <para> + <informaltable frame="none"> + <tgroup cols="7" align="center"> + <tbody valign="top"> + <row> + <entry></entry> + <entry>0</entry><entry></entry><entry>1</entry><entry></entry> + <entry>2</entry><entry></entry><entry>3</entry> + </row> + <row> + <entry>0</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + <row> + <entry>1</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + <row> + <entry></entry> + </row> + <row> + <entry>2</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + <row> + <entry>3</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> + </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) else return r; } -y1 = (255 / 219.0) * (Y1 - 16); -pb = (255 / 224.0) * (Cb - 128); -pr = (255 / 224.0) * (Cr - 128); +y1 = (Y1 - 16) / 219.0; +pb = (Cb - 128) / 224.0; +pr = (Cr - 128) / 224.0; r = 1.0 * y1 + 0 * pb + 1.402 * pr; g = 1.0 * y1 - 0.344 * pb - 0.714 * pr; @@ -718,6 +718,7 @@ information.</para> &sub-nv12m; &sub-nv12mt; &sub-nv16; + &sub-nv16m; &sub-nv24; &sub-m420; </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 @@ <colspec colname="id" align="left" /> <colspec colname="code" align="center"/> <colspec colname="bit" /> - <colspec colnum="4" colname="b23" align="center" /> - <colspec colnum="5" colname="b22" align="center" /> - <colspec colnum="6" colname="b21" align="center" /> - <colspec colnum="7" colname="b20" align="center" /> - <colspec colnum="8" colname="b19" align="center" /> - <colspec colnum="9" colname="b18" align="center" /> - <colspec colnum="10" colname="b17" align="center" /> - <colspec colnum="11" colname="b16" align="center" /> - <colspec colnum="12" colname="b15" align="center" /> - <colspec colnum="13" colname="b14" align="center" /> - <colspec colnum="14" colname="b13" align="center" /> - <colspec colnum="15" colname="b12" align="center" /> - <colspec colnum="16" colname="b11" align="center" /> - <colspec colnum="17" colname="b10" align="center" /> - <colspec colnum="18" colname="b09" align="center" /> - <colspec colnum="19" colname="b08" align="center" /> - <colspec colnum="20" colname="b07" align="center" /> - <colspec colnum="21" colname="b06" align="center" /> - <colspec colnum="22" colname="b05" align="center" /> - <colspec colnum="23" colname="b04" align="center" /> - <colspec colnum="24" colname="b03" align="center" /> - <colspec colnum="25" colname="b02" align="center" /> - <colspec colnum="26" colname="b01" align="center" /> - <colspec colnum="27" colname="b00" align="center" /> - <spanspec namest="b23" nameend="b00" spanname="b0" /> + <colspec colnum="4" colname="b31" align="center" /> + <colspec colnum="5" colname="b20" align="center" /> + <colspec colnum="6" colname="b29" align="center" /> + <colspec colnum="7" colname="b28" align="center" /> + <colspec colnum="8" colname="b27" align="center" /> + <colspec colnum="9" colname="b26" align="center" /> + <colspec colnum="10" colname="b25" align="center" /> + <colspec colnum="11" colname="b24" align="center" /> + <colspec colnum="12" colname="b23" align="center" /> + <colspec colnum="13" colname="b22" align="center" /> + <colspec colnum="14" colname="b21" align="center" /> + <colspec colnum="15" colname="b20" align="center" /> + <colspec colnum="16" colname="b19" align="center" /> + <colspec colnum="17" colname="b18" align="center" /> + <colspec colnum="18" colname="b17" align="center" /> + <colspec colnum="19" colname="b16" align="center" /> + <colspec colnum="20" colname="b15" align="center" /> + <colspec colnum="21" colname="b14" align="center" /> + <colspec colnum="22" colname="b13" align="center" /> + <colspec colnum="23" colname="b12" align="center" /> + <colspec colnum="24" colname="b11" align="center" /> + <colspec colnum="25" colname="b10" align="center" /> + <colspec colnum="26" colname="b09" align="center" /> + <colspec colnum="27" colname="b08" align="center" /> + <colspec colnum="28" colname="b07" align="center" /> + <colspec colnum="29" colname="b06" align="center" /> + <colspec colnum="30" colname="b05" align="center" /> + <colspec colnum="31" colname="b04" align="center" /> + <colspec colnum="32" colname="b03" align="center" /> + <colspec colnum="33" colname="b02" align="center" /> + <colspec colnum="34" colname="b01" align="center" /> + <colspec colnum="35" colname="b00" align="center" /> + <spanspec namest="b31" nameend="b00" spanname="b0" /> <thead> <row> <entry>Identifier</entry> @@ -133,6 +141,14 @@ <entry></entry> <entry></entry> <entry>Bit</entry> + <entry>31</entry> + <entry>30</entry> + <entry>29</entry> + <entry>28</entry> + <entry>27</entry> + <entry>26</entry> + <entry>25</entry> + <entry>24</entry> <entry>23</entry> <entry>22</entry> <entry>21</entry> @@ -164,7 +180,7 @@ <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE</entry> <entry>0x1001</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>0</entry> <entry>0</entry> <entry>0</entry> @@ -178,7 +194,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>3</subscript></entry> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> @@ -192,7 +208,7 @@ <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE</entry> <entry>0x1002</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>3</subscript></entry> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> @@ -206,7 +222,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>0</entry> <entry>0</entry> <entry>0</entry> @@ -220,7 +236,7 @@ <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</entry> <entry>0x1003</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>0</entry> <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> @@ -234,7 +250,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -248,7 +264,7 @@ <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE</entry> <entry>0x1004</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -262,7 +278,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>0</entry> <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> @@ -276,7 +292,7 @@ <entry>V4L2_MBUS_FMT_BGR565_2X8_BE</entry> <entry>0x1005</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>b<subscript>4</subscript></entry> <entry>b<subscript>3</subscript></entry> <entry>b<subscript>2</subscript></entry> @@ -290,7 +306,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -304,7 +320,7 @@ <entry>V4L2_MBUS_FMT_BGR565_2X8_LE</entry> <entry>0x1006</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -318,7 +334,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>b<subscript>4</subscript></entry> <entry>b<subscript>3</subscript></entry> <entry>b<subscript>2</subscript></entry> @@ -332,7 +348,7 @@ <entry>V4L2_MBUS_FMT_RGB565_2X8_BE</entry> <entry>0x1007</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> <entry>r<subscript>2</subscript></entry> @@ -346,7 +362,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -360,7 +376,7 @@ <entry>V4L2_MBUS_FMT_RGB565_2X8_LE</entry> <entry>0x1008</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -374,7 +390,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> <entry>r<subscript>2</subscript></entry> @@ -388,12 +404,7 @@ <entry>V4L2_MBUS_FMT_RGB666_1X18</entry> <entry>0x1009</entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-14; <entry>r<subscript>5</subscript></entry> <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> @@ -417,6 +428,7 @@ <entry>V4L2_MBUS_FMT_RGB888_1X24</entry> <entry>0x100a</entry> <entry></entry> + &dash-ent-8; <entry>r<subscript>7</subscript></entry> <entry>r<subscript>6</subscript></entry> <entry>r<subscript>5</subscript></entry> @@ -446,9 +458,7 @@ <entry>V4L2_MBUS_FMT_RGB888_2X12_BE</entry> <entry>0x100b</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-20; <entry>r<subscript>7</subscript></entry> <entry>r<subscript>6</subscript></entry> <entry>r<subscript>5</subscript></entry> @@ -466,9 +476,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-20; <entry>g<subscript>3</subscript></entry> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> @@ -486,9 +494,7 @@ <entry>V4L2_MBUS_FMT_RGB888_2X12_LE</entry> <entry>0x100c</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-20; <entry>g<subscript>3</subscript></entry> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> @@ -506,9 +512,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-20; <entry>r<subscript>7</subscript></entry> <entry>r<subscript>6</subscript></entry> <entry>r<subscript>5</subscript></entry> @@ -522,6 +526,43 @@ <entry>g<subscript>5</subscript></entry> <entry>g<subscript>4</subscript></entry> </row> + <row id="V4L2-MBUS-FMT-ARGB888-1X32"> + <entry>V4L2_MBUS_FMT_ARGB888_1X32</entry> + <entry>0x100d</entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> </tbody> </tgroup> </table> @@ -1149,6 +1190,7 @@ <listitem><para>y<subscript>x</subscript> for luma component bit number x</para></listitem> <listitem><para>u<subscript>x</subscript> for blue chroma component bit number x</para></listitem> <listitem><para>v<subscript>x</subscript> for red chroma component bit number x</para></listitem> + <listitem><para>a<subscript>x</subscript> for alpha component bit number x</para></listitem> <listitem><para>- for non-available bits (for positions higher than the bus width)</para></listitem> <listitem><para>d for dummy bits</para></listitem> </itemizedlist> @@ -1159,37 +1201,39 @@ <colspec colname="id" align="left" /> <colspec colname="code" align="center"/> <colspec colname="bit" /> - <colspec colnum="4" colname="b29" align="center" /> - <colspec colnum="5" colname="b28" align="center" /> - <colspec colnum="6" colname="b27" align="center" /> - <colspec colnum="7" colname="b26" align="center" /> - <colspec colnum="8" colname="b25" align="center" /> - <colspec colnum="9" colname="b24" align="center" /> - <colspec colnum="10" colname="b23" align="center" /> - <colspec colnum="11" colname="b22" align="center" /> - <colspec colnum="12" colname="b21" align="center" /> - <colspec colnum="13" colname="b20" align="center" /> - <colspec colnum="14" colname="b19" align="center" /> - <colspec colnum="15" colname="b18" align="center" /> - <colspec colnum="16" colname="b17" align="center" /> - <colspec colnum="17" colname="b16" align="center" /> - <colspec colnum="18" colname="b15" align="center" /> - <colspec colnum="19" colname="b14" align="center" /> - <colspec colnum="20" colname="b13" align="center" /> - <colspec colnum="21" colname="b12" align="center" /> - <colspec colnum="22" colname="b11" align="center" /> - <colspec colnum="23" colname="b10" align="center" /> - <colspec colnum="24" colname="b09" align="center" /> - <colspec colnum="25" colname="b08" align="center" /> - <colspec colnum="26" colname="b07" align="center" /> - <colspec colnum="27" colname="b06" align="center" /> - <colspec colnum="28" colname="b05" align="center" /> - <colspec colnum="29" colname="b04" align="center" /> - <colspec colnum="30" colname="b03" align="center" /> - <colspec colnum="31" colname="b02" align="center" /> - <colspec colnum="32" colname="b01" align="center" /> - <colspec colnum="33" colname="b00" align="center" /> - <spanspec namest="b29" nameend="b00" spanname="b0" /> + <colspec colnum="4" colname="b31" align="center" /> + <colspec colnum="5" colname="b20" align="center" /> + <colspec colnum="6" colname="b29" align="center" /> + <colspec colnum="7" colname="b28" align="center" /> + <colspec colnum="8" colname="b27" align="center" /> + <colspec colnum="9" colname="b26" align="center" /> + <colspec colnum="10" colname="b25" align="center" /> + <colspec colnum="11" colname="b24" align="center" /> + <colspec colnum="12" colname="b23" align="center" /> + <colspec colnum="13" colname="b22" align="center" /> + <colspec colnum="14" colname="b21" align="center" /> + <colspec colnum="15" colname="b20" align="center" /> + <colspec colnum="16" colname="b19" align="center" /> + <colspec colnum="17" colname="b18" align="center" /> + <colspec colnum="18" colname="b17" align="center" /> + <colspec colnum="19" colname="b16" align="center" /> + <colspec colnum="20" colname="b15" align="center" /> + <colspec colnum="21" colname="b14" align="center" /> + <colspec colnum="22" colname="b13" align="center" /> + <colspec colnum="23" colname="b12" align="center" /> + <colspec colnum="24" colname="b11" align="center" /> + <colspec colnum="25" colname="b10" align="center" /> + <colspec colnum="26" colname="b09" align="center" /> + <colspec colnum="27" colname="b08" align="center" /> + <colspec colnum="28" colname="b07" align="center" /> + <colspec colnum="29" colname="b06" align="center" /> + <colspec colnum="30" colname="b05" align="center" /> + <colspec colnum="31" colname="b04" align="center" /> + <colspec colnum="32" colname="b03" align="center" /> + <colspec colnum="33" colname="b02" align="center" /> + <colspec colnum="34" colname="b01" align="center" /> + <colspec colnum="35" colname="b00" align="center" /> + <spanspec namest="b31" nameend="b00" spanname="b0" /> <thead> <row> <entry>Identifier</entry> @@ -1201,6 +1245,8 @@ <entry></entry> <entry></entry> <entry>Bit</entry> + <entry>31</entry> + <entry>30</entry> <entry>29</entry> <entry>28</entry> <entry>27</entry> @@ -1238,10 +1284,7 @@ <entry>V4L2_MBUS_FMT_Y8_1X8</entry> <entry>0x2001</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1255,18 +1298,7 @@ <entry>V4L2_MBUS_FMT_UV8_1X8</entry> <entry>0x2015</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> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1280,18 +1312,7 @@ <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> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1305,10 +1326,7 @@ <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry> <entry>0x2002</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1322,10 +1340,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1339,10 +1354,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1356,10 +1368,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1373,10 +1382,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1390,10 +1396,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1407,10 +1410,7 @@ <entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry> <entry>0x2003</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1424,10 +1424,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1441,10 +1438,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1458,10 +1452,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1475,10 +1466,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1492,10 +1480,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1509,10 +1494,7 @@ <entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry> <entry>0x2004</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1526,10 +1508,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1543,10 +1522,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1560,10 +1536,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1577,10 +1550,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1594,10 +1564,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1611,10 +1578,7 @@ <entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry> <entry>0x2005</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1628,10 +1592,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1645,10 +1606,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1662,10 +1620,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1679,10 +1634,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1696,10 +1648,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1713,10 +1662,7 @@ <entry>V4L2_MBUS_FMT_UYVY8_2X8</entry> <entry>0x2006</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1730,10 +1676,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1747,10 +1690,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1764,10 +1704,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1781,10 +1718,7 @@ <entry>V4L2_MBUS_FMT_VYUY8_2X8</entry> <entry>0x2007</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1798,10 +1732,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1815,10 +1746,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1832,10 +1760,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1849,10 +1774,7 @@ <entry>V4L2_MBUS_FMT_YUYV8_2X8</entry> <entry>0x2008</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1866,10 +1788,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1883,10 +1802,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1900,10 +1816,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1917,10 +1830,7 @@ <entry>V4L2_MBUS_FMT_YVYU8_2X8</entry> <entry>0x2009</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1934,10 +1844,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1951,10 +1858,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1968,10 +1872,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1985,8 +1886,7 @@ <entry>V4L2_MBUS_FMT_Y10_1X10</entry> <entry>0x200a</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2002,8 +1902,7 @@ <entry>V4L2_MBUS_FMT_YUYV10_2X10</entry> <entry>0x200b</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2019,8 +1918,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>u<subscript>9</subscript></entry> <entry>u<subscript>8</subscript></entry> <entry>u<subscript>7</subscript></entry> @@ -2036,8 +1934,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2053,8 +1950,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>v<subscript>9</subscript></entry> <entry>v<subscript>8</subscript></entry> <entry>v<subscript>7</subscript></entry> @@ -2070,8 +1966,7 @@ <entry>V4L2_MBUS_FMT_YVYU10_2X10</entry> <entry>0x200c</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2087,8 +1982,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>v<subscript>9</subscript></entry> <entry>v<subscript>8</subscript></entry> <entry>v<subscript>7</subscript></entry> @@ -2104,8 +1998,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2121,8 +2014,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>u<subscript>9</subscript></entry> <entry>u<subscript>8</subscript></entry> <entry>u<subscript>7</subscript></entry> @@ -2138,15 +2030,7 @@ <entry>V4L2_MBUS_FMT_Y12_1X12</entry> <entry>0x2013</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-20; <entry>y<subscript>11</subscript></entry> <entry>y<subscript>10</subscript></entry> <entry>y<subscript>9</subscript></entry> @@ -2164,11 +2048,7 @@ <entry>V4L2_MBUS_FMT_UYVY8_1X16</entry> <entry>0x200f</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -2190,11 +2070,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -2216,11 +2092,7 @@ <entry>V4L2_MBUS_FMT_VYUY8_1X16</entry> <entry>0x2010</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -2242,11 +2114,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -2268,11 +2136,7 @@ <entry>V4L2_MBUS_FMT_YUYV8_1X16</entry> <entry>0x2011</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2294,11 +2158,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2320,11 +2180,7 @@ <entry>V4L2_MBUS_FMT_YVYU8_1X16</entry> <entry>0x2012</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2346,11 +2202,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2372,10 +2224,7 @@ <entry>V4L2_MBUS_FMT_YDYUYDYV8_1X16</entry> <entry>0x2014</entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2397,10 +2246,7 @@ <entry></entry> <entry></entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2422,10 +2268,7 @@ <entry></entry> <entry></entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2447,10 +2290,7 @@ <entry></entry> <entry></entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2472,7 +2312,7 @@ <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry> <entry>0x200d</entry> <entry></entry> - &dash-ent-10; + &dash-ent-12; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2498,7 +2338,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; + &dash-ent-12; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2524,7 +2364,7 @@ <entry>V4L2_MBUS_FMT_YVYU10_1X20</entry> <entry>0x200e</entry> <entry></entry> - &dash-ent-10; + &dash-ent-12; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2550,7 +2390,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; + &dash-ent-12; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2574,8 +2414,10 @@ </row> <row id="V4L2-MBUS-FMT-YUV10-1X30"> <entry>V4L2_MBUS_FMT_YUV10_1X30</entry> - <entry>0x2014</entry> + <entry>0x2016</entry> <entry></entry> + <entry>-</entry> + <entry>-</entry> <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2607,6 +2449,43 @@ <entry>v<subscript>1</subscript></entry> <entry>v<subscript>0</subscript></entry> </row> + <row id="V4L2-MBUS-FMT-AYUV8-1X32"> + <entry>V4L2_MBUS_FMT_AYUV8_1X32</entry> + <entry>0x2017</entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> </tbody> </tgroup> </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 control over buffers is required. This ioctl can be called multiple times to create buffers of different sizes.</para> - <para>To allocate device buffers applications initialize relevant fields of -the <structname>v4l2_create_buffers</structname> structure. They set the -<structfield>type</structfield> field in the -&v4l2-format; structure, embedded in this -structure, to the respective stream or buffer type. -<structfield>count</structfield> must be set to the number of required buffers. -<structfield>memory</structfield> specifies the required I/O method. The -<structfield>format</structfield> field shall typically be filled in using -either the <constant>VIDIOC_TRY_FMT</constant> or -<constant>VIDIOC_G_FMT</constant> ioctl(). Additionally, applications can adjust -<structfield>sizeimage</structfield> fields to fit their specific needs. The -<structfield>reserved</structfield> array must be zeroed.</para> + <para>To allocate the device buffers applications must initialize the +relevant fields of the <structname>v4l2_create_buffers</structname> structure. +The <structfield>count</structfield> field must be set to the number of +requested buffers, the <structfield>memory</structfield> field specifies the +requested I/O method and the <structfield>reserved</structfield> array must be +zeroed.</para> + + <para>The <structfield>format</structfield> field specifies the image format +that the buffers must be able to handle. The application has to fill in this +&v4l2-format;. Usually this will be done using the +<constant>VIDIOC_TRY_FMT</constant> or <constant>VIDIOC_G_FMT</constant> ioctl() +to ensure that the requested format is supported by the driver. Unsupported +formats will result in an error.</para> + + <para>The buffers created by this ioctl will have as minimum size the size +defined by the <structfield>format.pix.sizeimage</structfield> field. If the +<structfield>format.pix.sizeimage</structfield> field is less than the minimum +required for the given format, then <structfield>sizeimage</structfield> will be +increased by the driver to that minimum to allocate the buffers. If it is +larger, then the value will be used as-is. The same applies to the +<structfield>sizeimage</structfield> field of the +<structname>v4l2_plane_pix_format</structname> structure in the case of +multiplanar formats.</para> <para>When the ioctl is called with a pointer to this structure the driver will attempt to allocate up to the requested number of buffers and store the @@ -144,9 +155,9 @@ mapped</link> I/O.</para> <varlistentry> <term><errorcode>EINVAL</errorcode></term> <listitem> - <para>The buffer type (<structfield>type</structfield> field) or the -requested I/O method (<structfield>memory</structfield>) is not -supported.</para> + <para>The buffer type (<structfield>format.type</structfield> field), +requested I/O method (<structfield>memory</structfield>) or format +(<structfield>format</structfield> field) is not valid.</para> </listitem> </varlistentry> </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 <entry>__u32</entry> <entry><structfield>il_vfrontporch</structfield></entry> <entry>Vertical front porch in lines for the even field (aka field 2) of - interlaced field formats.</entry> + interlaced field formats. Must be 0 for progressive formats.</entry> </row> <row> <entry>__u32</entry> <entry><structfield>il_vsync</structfield></entry> <entry>Vertical sync length in lines for the even field (aka field 2) of - interlaced field formats.</entry> + interlaced field formats. Must be 0 for progressive formats.</entry> </row> <row> <entry>__u32</entry> <entry><structfield>il_vbackporch</structfield></entry> <entry>Vertical back porch in lines for the even field (aka field 2) of - interlaced field formats.</entry> + interlaced field formats. Must be 0 for progressive formats.</entry> </row> <row> <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> <entry>int</entry> <entry><structfield>quality</structfield></entry> <entry>Deprecated. If <link linkend="jpeg-quality-control"><constant> - V4L2_CID_JPEG_IMAGE_QUALITY</constant></link> control is exposed by - a driver applications should use it instead and ignore this field. + V4L2_CID_JPEG_COMPRESSION_QUALITY</constant></link> control is exposed + by a driver applications should use it instead and ignore this field. </entry> </row> <row> diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 6a8b7158697f..4c8d282545a2 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -1,6 +1,6 @@ <?xml version="1.0"?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ <!ENTITY % media-entities SYSTEM "./media-entities.tmpl"> %media-entities; <!ENTITY media-indices SYSTEM "./media-indices.tmpl"> @@ -22,8 +22,14 @@ <!-- LinuxTV v4l-dvb repository. --> <!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>"> +<!ENTITY dash-ent-8 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> <!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> +<!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>"> +<!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>"> <!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>"> +<!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>"> +<!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>"> +<!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>"> ]> <book id="media_api"> 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 write-side contention and parallelize the other write-side overheads by providing a fine-grained locking design, however, it would be interesting to see how much of the performance advantage reported in 1990 remains -in 2004. +today. At about this same time, Adams [Adams91] described ``chaotic relaxation'', where the normal barriers between successive iterations of convergent @@ -86,9 +86,9 @@ DYNIX/ptx kernel. The corresponding conference paper appeared in 1998 [McKenney98]. In 1999, the Tornado and K42 groups described their "generations" -mechanism, which quite similar to RCU [Gamsa99]. These operating systems -made pervasive use of RCU in place of "existence locks", which greatly -simplifies locking hierarchies. +mechanism, which is quite similar to RCU [Gamsa99]. These operating +systems made pervasive use of RCU in place of "existence locks", which +greatly simplifies locking hierarchies and helps avoid deadlocks. 2001 saw the first RCU presentation involving Linux [McKenney01a] 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 form of memory barriers. Researchers at Sun worked along similar lines in the same timeframe [HerlihyLM02]. These techniques can be thought of as inside-out reference counts, where the count is represented by the -number of hazard pointers referencing a given data structure (rather than -the more conventional counter field within the data structure itself). +number of hazard pointers referencing a given data structure rather than +the more conventional counter field within the data structure itself. +The key advantage of inside-out reference counts is that they can be +stored in immortal variables, thus allowing races between access and +deletion to be avoided. By the same token, RCU can be thought of as a "bulk reference count", 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 (strange, but true!) [PhilHoward2011RCUTMRBTree], yet another variant of RCU-protected resizeable hash tables [Triplett:2011:RPHash], the 3.0 RCU trainwreck [PaulEMcKenney2011RCU3.0trainwreck], and Neil Brown's "Meet the -Lockers" LWN article [NeilBrown2011MeetTheLockers]. +Lockers" LWN article [NeilBrown2011MeetTheLockers]. Some academic +work looked at debugging uses of RCU [Seyster:2011:RFA:2075416.2075425]. + +In 2012, Josh Triplett received his Ph.D. with his dissertation +covering RCU-protected resizable hash tables and the relationship +between memory barriers and read-side traversal order: If the updater +is making changes in the opposite direction from the read-side traveral +order, the updater need only execute a memory-barrier instruction, +but if in the same direction, the updater needs to wait for a grace +period between the individual updates [JoshTriplettPhD]. Also in 2012, +after seventeen years of attempts, an RCU paper made it into a top-flight +academic journal, IEEE Transactions on Parallel and Distributed Systems +[MathieuDesnoyers2012URCU]. A group of researchers in Spain applied +user-level RCU to crowd simulation [GuillermoVigueras2012RCUCrowd], and +another group of researchers in Europe produced a formal description of +RCU based on separation logic [AlexeyGotsman2012VerifyGraceExtended], +which was published in the 2013 European Symposium on Programming +[AlexeyGotsman2013ESOPRCU]. + Bibtex Entries @@ -193,13 +214,12 @@ Bibtex Entries ,volume="5" ,number="3" ,pages="354-382" -,note="Available: -\url{http://portal.acm.org/citation.cfm?id=320619&dl=GUIDE,} -[Viewed December 3, 2007]" ,annotation={ Use garbage collector to clean up data after everyone is done with it. . Oldest use of something vaguely resembling RCU that I have found. + http://portal.acm.org/citation.cfm?id=320619&dl=GUIDE, + [Viewed December 3, 2007] } } @@ -309,7 +329,7 @@ for Programming Languages and Operating Systems}" ,doi = {http://doi.acm.org/10.1145/42392.42399} ,publisher = {ACM} ,address = {New York, NY, USA} -,annotation= { +,annotation={ At the top of page 307: "Conflicts with deposits and withdrawals are necessary if the reported total is to be up to date. They could be avoided by having total return a sum that is slightly @@ -346,8 +366,9 @@ for Programming Languages and Operating Systems}" } } -@Book{Adams91 -,Author="Gregory R. Adams" +# Was Adams91, see also syncrefs.bib. +@Book{Andrews91textbook +,Author="Gregory R. Andrews" ,title="Concurrent Programming, Principles, and Practices" ,Publisher="Benjamin Cummins" ,Year="1991" @@ -398,39 +419,39 @@ for Programming Languages and Operating Systems}" } } -@conference{Pu95a, -Author = "Calton Pu and Tito Autrey and Andrew Black and Charles Consel and +@conference{Pu95a +,Author = "Calton Pu and Tito Autrey and Andrew Black and Charles Consel and Crispin Cowan and Jon Inouye and Lakshmi Kethana and Jonathan Walpole and -Ke Zhang", -Title = "Optimistic Incremental Specialization: Streamlining a Commercial -Operating System", -Booktitle = "15\textsuperscript{th} ACM Symposium on -Operating Systems Principles (SOSP'95)", -address = "Copper Mountain, CO", -month="December", -year="1995", -pages="314-321", -annotation=" +Ke Zhang" +,Title = "Optimistic Incremental Specialization: Streamlining a Commercial +,Operating System" +,Booktitle = "15\textsuperscript{th} ACM Symposium on +,Operating Systems Principles (SOSP'95)" +,address = "Copper Mountain, CO" +,month="December" +,year="1995" +,pages="314-321" +,annotation={ Uses a replugger, but with a flag to signal when people are using the resource at hand. Only one reader at a time. -" -} - -@conference{Cowan96a, -Author = "Crispin Cowan and Tito Autrey and Charles Krasic and -Calton Pu and Jonathan Walpole", -Title = "Fast Concurrent Dynamic Linking for an Adaptive Operating System", -Booktitle = "International Conference on Configurable Distributed Systems -(ICCDS'96)", -address = "Annapolis, MD", -month="May", -year="1996", -pages="108", -isbn="0-8186-7395-8", -annotation=" +} +} + +@conference{Cowan96a +,Author = "Crispin Cowan and Tito Autrey and Charles Krasic and +,Calton Pu and Jonathan Walpole" +,Title = "Fast Concurrent Dynamic Linking for an Adaptive Operating System" +,Booktitle = "International Conference on Configurable Distributed Systems +(ICCDS'96)" +,address = "Annapolis, MD" +,month="May" +,year="1996" +,pages="108" +,isbn="0-8186-7395-8" +,annotation={ Uses a replugger, but with a counter to signal when people are using the resource at hand. Allows multiple readers. -" +} } @techreport{Slingwine95 @@ -493,14 +514,13 @@ Problems" ,Year="1998" ,pages="509-518" ,Address="Las Vegas, NV" -,note="Available: -\url{http://www.rdrop.com/users/paulmck/RCU/rclockpdcsproof.pdf} -[Viewed December 3, 2007]" ,annotation={ Describes and analyzes RCU mechanism in DYNIX/ptx. Describes application to linked list update and log-buffer flushing. Defines 'quiescent state'. Includes both measured and analytic evaluation. + http://www.rdrop.com/users/paulmck/RCU/rclockpdcsproof.pdf + [Viewed December 3, 2007] } } @@ -514,13 +534,12 @@ Operating System Design and Implementation}" ,Year="1999" ,pages="87-100" ,Address="New Orleans, LA" -,note="Available: -\url{http://www.usenix.org/events/osdi99/full_papers/gamsa/gamsa.pdf} -[Viewed August 30, 2006]" ,annotation={ Use of RCU-like facility in K42/Tornado. Another independent invention of RCU. See especially pages 7-9 (Section 5). + http://www.usenix.org/events/osdi99/full_papers/gamsa/gamsa.pdf + [Viewed August 30, 2006] } } @@ -611,9 +630,9 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni" ,note="Available: \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=100259266316456&w=2} [Viewed June 23, 2004]" -,annotation=" +,annotation={ Memory-barrier and Alpha thread. 100 messages, not too bad... -" +} } @unpublished{Spraul01 @@ -624,10 +643,10 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni" ,note="Available: \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=100264675012867&w=2} [Viewed June 23, 2004]" -,annotation=" +,annotation={ Suggested burying memory barriers in Linux's list-manipulation primitives. -" +} } @unpublished{LinusTorvalds2001a @@ -638,6 +657,8 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni" ,note="Available: \url{http://lkml.org/lkml/2001/10/13/105} [Viewed August 21, 2004]" +,annotation={ +} } @unpublished{Blanchard02a @@ -657,10 +678,10 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni" ,Month="June" ,Year="2002" ,pages="289-300" -,annotation=" +,annotation={ Measured scalability of Linux 2.4 kernel's directory-entry cache (dcache), and measured some scalability enhancements. -" +} } @Conference{McKenney02a @@ -674,10 +695,10 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" ,note="Available: \url{http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz} [Viewed June 23, 2004]" -,annotation=" +,annotation={ Presented and compared a number of RCU implementations for the Linux kernel. -" +} } @unpublished{Sarma02a @@ -688,9 +709,9 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" ,note="Available: \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=102645767914212&w=2} [Viewed June 23, 2004]" -,annotation=" +,annotation={ Compare fastwalk and RCU for dcache. RCU won. -" +} } @unpublished{Barbieri02 @@ -701,9 +722,9 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" ,note="Available: \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=103082050621241&w=2} [Viewed: June 23, 2004]" -,annotation=" +,annotation={ Suggested RCU for vfs\_shared\_cred. -" +} } @unpublished{Dickins02a @@ -722,10 +743,10 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" ,note="Available: \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=103462075416638&w=2} [Viewed June 23, 2004]" -,annotation=" +,annotation={ Performance of dcache RCU on kernbench for 16x NUMA-Q and 1x, 2x, and 4x systems. RCU does no harm, and helps on 16x. -" +} } @unpublished{LinusTorvalds2003a @@ -736,14 +757,14 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" ,note="Available: \url{http://lkml.org/lkml/2003/3/9/205} [Viewed March 13, 2006]" -,annotation=" +,annotation={ Linus suggests replacing brlock with RCU and/or seqlocks: . 'It's entirely possible that the current user could be replaced by RCU and/or seqlocks, and we could get rid of brlocks entirely.' . Steve Hemminger responds by replacing them with RCU. -" +} } @article{Appavoo03a @@ -758,9 +779,9 @@ B. Rosenburg and M. Stumm and J. Xenidis" ,volume="42" ,number="1" ,pages="60-76" -,annotation=" +,annotation={ Use of RCU to enable hot-swapping for autonomic behavior in K42. -" +} } @unpublished{Seigh03 @@ -769,9 +790,9 @@ B. Rosenburg and M. Stumm and J. Xenidis" ,Year="2003" ,Month="March" ,note="email correspondence" -,annotation=" +,annotation={ Described the relationship of the VM/XA passive serialization to RCU. -" +} } @Conference{Arcangeli03 @@ -785,14 +806,12 @@ Dipankar Sarma" ,year="2003" ,month="June" ,pages="297-310" -,note="Available: -\url{http://www.rdrop.com/users/paulmck/RCU/rcu.FREENIX.2003.06.14.pdf} -[Viewed November 21, 2007]" -,annotation=" +,annotation={ Compared updated RCU implementations for the Linux kernel, and described System V IPC use of RCU, including order-of-magnitude performance improvements. -" + http://www.rdrop.com/users/paulmck/RCU/rcu.FREENIX.2003.06.14.pdf +} } @Conference{Soules03a @@ -820,10 +839,10 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" ,note="Available: \url{http://www.linuxjournal.com/article/6993} [Viewed November 14, 2007]" -,annotation=" +,annotation={ Reader-friendly intro to RCU, with the infamous old-man-and-brat cartoon. -" +} } @unpublished{Sarma03a @@ -832,7 +851,9 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" ,month="December" ,year="2003" ,note="Message ID: 20031222180114.GA2248@in.ibm.com" -,annotation="dipankar/ct.2004.03.27/RCUll.2003.12.22.patch" +,annotation={ + dipankar/ct.2004.03.27/RCUll.2003.12.22.patch +} } @techreport{Friedberg03a @@ -844,11 +865,11 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" ,number="US Patent 6,662,184" ,month="December" ,pages="112" -,annotation=" +,annotation={ Applies RCU to a wildcard-search Patricia tree in order to permit synchronization-free lookup. RCU is used to retain removed nodes for a grace period before freeing them. -" +} } @article{McKenney04a @@ -860,12 +881,11 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" ,volume="1" ,number="118" ,pages="38-46" -,note="Available: -\url{http://www.linuxjournal.com/node/7124} -[Viewed December 26, 2010]" -,annotation=" +,annotation={ Reader friendly intro to dcache and RCU. -" + http://www.linuxjournal.com/node/7124 + [Viewed December 26, 2010] +} } @Conference{McKenney04b @@ -879,10 +899,10 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" \url{http://www.linux.org.au/conf/2004/abstracts.html#90} \url{http://www.rdrop.com/users/paulmck/RCU/lockperf.2004.01.17a.pdf} [Viewed June 23, 2004]" -,annotation=" +,annotation={ Compares performance of RCU to that of other locking primitives over a number of CPUs (x86, Opteron, Itanium, and PPC). -" +} } @unpublished{Sarma04a @@ -891,7 +911,9 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" ,month="March" ,year="2004" ,note="\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108003746402892&w=2}" -,annotation="Head of thread: dipankar/2004.03.23/rcu-low-lat.1.patch" +,annotation={ + Head of thread: dipankar/2004.03.23/rcu-low-lat.1.patch +} } @unpublished{Sarma04b @@ -900,7 +922,9 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" ,month="March" ,year="2004" ,note="\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108016474829546&w=2}" -,annotation="dipankar/rcuth.2004.03.24/rcu-throttle.patch" +,annotation={ + dipankar/rcuth.2004.03.24/rcu-throttle.patch +} } @unpublished{Spraul04a @@ -911,9 +935,9 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis" ,note="Available: \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108546407726602&w=2} [Viewed June 23, 2004]" -,annotation=" +,annotation={ Hierarchical-bitmap patch for RCU infrastructure. -" +} } @unpublished{Steiner04a @@ -950,10 +974,12 @@ Realtime Applications" ,year="2004" ,month="June" ,pages="182-191" -,annotation=" +,annotation={ Describes and compares a number of modifications to the Linux RCU implementation that make it friendly to realtime applications. -" + https://www.usenix.org/conference/2004-usenix-annual-technical-conference/making-rcu-safe-deep-sub-millisecond-response + [Viewed July 26, 2012] +} } @phdthesis{PaulEdwardMcKenneyPhD @@ -964,14 +990,13 @@ in Operating System Kernels" ,school="OGI School of Science and Engineering at Oregon Health and Sciences University" ,year="2004" -,note="Available: -\url{http://www.rdrop.com/users/paulmck/RCU/RCUdissertation.2004.07.14e1.pdf} -[Viewed October 15, 2004]" -,annotation=" +,annotation={ Describes RCU implementations and presents design patterns corresponding to common uses of RCU in several operating-system kernels. -" + http://www.rdrop.com/users/paulmck/RCU/RCUdissertation.2004.07.14e1.pdf + [Viewed October 15, 2004] +} } @unpublished{PaulEMcKenney2004rcu:dereference @@ -982,9 +1007,9 @@ Oregon Health and Sciences University" ,note="Available: \url{http://lkml.org/lkml/2004/8/6/237} [Viewed June 8, 2010]" -,annotation=" +,annotation={ Introduce rcu_dereference(). -" +} } @unpublished{JimHouston04a @@ -995,11 +1020,11 @@ Oregon Health and Sciences University" ,note="Available: \url{http://lkml.org/lkml/2004/8/30/87} [Viewed February 17, 2005]" -,annotation=" +,annotation={ Uses active code in rcu_read_lock() and rcu_read_unlock() to make RCU happen, allowing RCU to function on CPUs that do not receive a scheduling-clock interrupt. -" +} } @unpublished{TomHart04a @@ -1010,9 +1035,9 @@ Oregon Health and Sciences University" ,note="Available: \url{http://www.cs.toronto.edu/~tomhart/masters_thesis.html} [Viewed October 15, 2004]" -,annotation=" +,annotation={ Proposes comparing RCU to lock-free methods for the Linux kernel. -" +} } @unpublished{Vaddagiri04a @@ -1023,9 +1048,9 @@ Oregon Health and Sciences University" ,note="Available: \url{http://marc.theaimsgroup.com/?t=109395731700004&r=1&w=2} [Viewed October 18, 2004]" -,annotation=" +,annotation={ Srivatsa's RCU patch for tcp_ehash lookup. -" +} } @unpublished{Thirumalai04a @@ -1036,9 +1061,9 @@ Oregon Health and Sciences University" ,note="Available: \url{http://marc.theaimsgroup.com/?t=109144217400003&r=1&w=2} [Viewed October 18, 2004]" -,annotation=" +,annotation={ Ravikiran's lockfree FD patch. -" +} } @unpublished{Thirumalai04b @@ -1049,9 +1074,9 @@ Oregon Health and Sciences University" ,note="Available: \url{http://marc.theaimsgroup.com/?l=linux-kernel&m=109152521410459&w=2} [Viewed October 18, 2004]" -,annotation=" +,annotation={ Ravikiran's lockfree FD patch. -" +} } @unpublished{PaulEMcKenney2004rcu:assign:pointer @@ -1062,9 +1087,9 @@ Oregon Health and Sciences University" ,note="Available: \url{http://lkml.org/lkml/2004/10/23/241} [Viewed June 8, 2010]" -,annotation=" +,annotation={ Introduce rcu_assign_pointer(). -" +} } @unpublished{JamesMorris04a @@ -1073,12 +1098,12 @@ Oregon Health and Sciences University" ,day="15" ,month="November" ,year="2004" -,note="Available: -\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=110054979416004&w=2} -[Viewed December 10, 2004]" -,annotation=" +,note="\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=110054979416004&w=2}" +,annotation={ James Morris posts Kaigai Kohei's patch to LKML. -" + [Viewed December 10, 2004] + Kaigai's patch is at https://lkml.org/lkml/2004/9/27/52 +} } @unpublished{JamesMorris04b @@ -1089,9 +1114,9 @@ Oregon Health and Sciences University" ,note="Available: \url{http://www.livejournal.com/users/james_morris/2153.html} [Viewed December 10, 2004]" -,annotation=" +,annotation={ RCU helps SELinux performance. ;-) Made LWN. -" +} } @unpublished{PaulMcKenney2005RCUSemantics @@ -1103,9 +1128,9 @@ Oregon Health and Sciences University" ,note="Available: \url{http://www.rdrop.com/users/paulmck/RCU/rcu-semantics.2005.01.30a.pdf} [Viewed December 6, 2009]" -,annotation=" +,annotation={ Early derivation of RCU semantics. -" +} } @unpublished{PaulMcKenney2005e @@ -1117,10 +1142,10 @@ Oregon Health and Sciences University" ,note="Available: \url{http://lkml.org/lkml/2005/3/17/199} [Viewed September 5, 2005]" -,annotation=" +,annotation={ First posting showing how RCU can be safely adapted for preemptable RCU read side critical sections. -" +} } @unpublished{EsbenNeilsen2005a @@ -1132,12 +1157,12 @@ Oregon Health and Sciences University" ,note="Available: \url{http://lkml.org/lkml/2005/3/18/122} [Viewed March 30, 2006]" -,annotation=" +,annotation={ Esben Neilsen suggests read-side suppression of grace-period processing for crude-but-workable realtime RCU. The downside - is indefinite grace periods...But this is OK for experimentation + is indefinite grace periods... But this is OK for experimentation and testing. -" +} } @unpublished{TomHart05a @@ -1149,10 +1174,10 @@ Data Structures" ,note="Available: \url{ftp://ftp.cs.toronto.edu/csrg-technical-reports/515/} [Viewed March 4, 2005]" -,annotation=" +,annotation={ Comparison of RCU, QBSR, and EBSR. RCU wins for read-mostly workloads. ;-) -" +} } @unpublished{JonCorbet2005DeprecateSyncKernel @@ -1164,10 +1189,10 @@ Data Structures" ,note="Available: \url{http://lwn.net/Articles/134484/} [Viewed May 3, 2005]" -,annotation=" +,annotation={ Jon Corbet describes deprecation of synchronize_kernel() in favor of synchronize_rcu() and synchronize_sched(). -" +} } @unpublished{PaulMcKenney05a @@ -1178,10 +1203,10 @@ Data Structures" ,note="Available: \url{http://lkml.org/lkml/2005/5/9/185} [Viewed May 13, 2005]" -,annotation=" +,annotation={ First publication of working lock-based deferred free patches for the CONFIG_PREEMPT_RT environment. -" +} } @conference{PaulMcKenney05b @@ -1194,10 +1219,10 @@ Data Structures" ,note="Available: \url{http://www.rdrop.com/users/paulmck/RCU/realtimeRCU.2005.04.23a.pdf} [Viewed May 13, 2005]" -,annotation=" +,annotation={ Realtime turns into making RCU yet more realtime friendly. http://lca2005.linux.org.au/Papers/Paul%20McKenney/Towards%20Hard%20Realtime%20Response%20from%20the%20Linux%20Kernel/LKS.2005.04.22a.pdf -" +} } @unpublished{PaulEMcKenneyHomePage @@ -1208,9 +1233,9 @@ Data Structures" ,note="Available: \url{http://www.rdrop.com/users/paulmck/} [Viewed May 25, 2005]" -,annotation=" +,annotation={ Paul McKenney's home page. -" +} } @unpublished{PaulEMcKenneyRCUPage @@ -1221,9 +1246,9 @@ Data Structures" ,note="Available: \url{http://www.rdrop.com/users/paulmck/RCU} [Viewed May 25, 2005]" -,annotation=" +,annotation={ Paul McKenney's RCU page. -" +} } @unpublished{JosephSeigh2005a @@ -1232,10 +1257,10 @@ Data Structures" ,month="July" ,year="2005" ,note="Personal communication" -,annotation=" +,annotation={ Joe Seigh announcing his atomic-ptr-plus project. http://sourceforge.net/projects/atomic-ptr-plus/ -" +} } @unpublished{JosephSeigh2005b @@ -1247,9 +1272,9 @@ Data Structures" ,note="Available: \url{http://sourceforge.net/projects/atomic-ptr-plus/} [Viewed August 8, 2005]" -,annotation=" +,annotation={ Joe Seigh's atomic-ptr-plus project. -" +} } @unpublished{PaulMcKenney2005c @@ -1261,9 +1286,9 @@ Data Structures" ,note="Available: \url{http://lkml.org/lkml/2005/8/1/155} [Viewed March 14, 2006]" -,annotation=" +,annotation={ First operating counter-based realtime RCU patch posted to LKML. -" +} } @unpublished{PaulMcKenney2005d @@ -1275,11 +1300,11 @@ Data Structures" ,note="Available: \url{http://lkml.org/lkml/2005/8/8/108} [Viewed March 14, 2006]" -,annotation=" +,annotation={ First operating counter-based realtime RCU patch posted to LKML, but fixed so that various unusual combinations of configuration parameters all function properly. -" +} } @unpublished{PaulMcKenney2005rcutorture @@ -1291,9 +1316,25 @@ Data Structures" ,note="Available: \url{http://lkml.org/lkml/2005/10/1/70} [Viewed March 14, 2006]" -,annotation=" +,annotation={ First rcutorture patch. -" +} +} + +@unpublished{DavidSMiller2006HashedLocking +,Author="David S. Miller" +,Title="Re: [{PATCH}, {RFC}] {RCU} : {OOM} avoidance and lower latency" +,month="January" +,day="6" +,year="2006" +,note="Available: +\url{https://lkml.org/lkml/2006/1/7/22} +[Viewed February 29, 2012]" +,annotation={ + David Miller's view on hashed arrays of locks: used to really + like it, but time he saw an opportunity for this technique, + something else always proved superior. Partitioning or RCU. ;-) +} } @conference{ThomasEHart2006a @@ -1309,10 +1350,10 @@ Distributed Processing Symposium" ,note="Available: \url{http://www.rdrop.com/users/paulmck/RCU/hart_ipdps06.pdf} [Viewed April 28, 2008]" -,annotation=" +,annotation={ Compares QSBR, HPBR, EBR, and lock-free reference counting. http://www.cs.toronto.edu/~tomhart/perflab/ipdps06.tgz -" +} } @unpublished{NickPiggin2006radixtree @@ -1324,9 +1365,9 @@ Distributed Processing Symposium" ,note="Available: \url{http://lkml.org/lkml/2006/6/20/238} [Viewed March 25, 2008]" -,annotation=" +,annotation={ RCU-protected radix tree. -" +} } @Conference{PaulEMcKenney2006b @@ -1341,9 +1382,9 @@ Suparna Bhattacharya" \url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184} \url{http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf} [Viewed January 1, 2007]" -,annotation=" +,annotation={ Described how to improve the -rt implementation of realtime RCU. -" +} } @unpublished{WikipediaRCU @@ -1354,12 +1395,11 @@ Canis Rufus and Zoicon5 and Anome and Hal Eisen" ,month="July" ,day="8" ,year="2006" -,note="Available: -\url{http://en.wikipedia.org/wiki/Read-copy-update} -[Viewed August 21, 2006]" -,annotation=" +,note="\url{http://en.wikipedia.org/wiki/Read-copy-update}" +,annotation={ Wikipedia RCU page as of July 8 2006. -" + [Viewed August 21, 2006] +} } @Conference{NickPiggin2006LocklessPageCache @@ -1372,9 +1412,9 @@ Canis Rufus and Zoicon5 and Anome and Hal Eisen" ,note="Available: \url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184} [Viewed January 11, 2009]" -,annotation=" +,annotation={ Uses RCU-protected radix tree for a lockless page cache. -" +} } @unpublished{PaulEMcKenney2006c @@ -1388,9 +1428,9 @@ Canis Rufus and Zoicon5 and Anome and Hal Eisen" Revised: \url{http://www.rdrop.com/users/paulmck/RCU/srcu.2007.01.14a.pdf} [Viewed August 21, 2006]" -,annotation=" +,annotation={ LWN article introducing SRCU. -" +} } @unpublished{RobertOlsson2006a @@ -1399,12 +1439,11 @@ Revised: ,month="August" ,day="18" ,year="2006" -,note="Available: -\url{http://www.nada.kth.se/~snilsson/publications/TRASH/trash.pdf} -[Viewed March 4, 2011]" -,annotation=" +,note="\url{http://www.nada.kth.se/~snilsson/publications/TRASH/trash.pdf}" +,annotation={ RCU-protected dynamic trie-hash combination. -" + [Viewed March 4, 2011] +} } @unpublished{ChristophHellwig2006RCU2SRCU @@ -1426,10 +1465,10 @@ Revised: ,note="Available: \url{http://www.rdrop.com/users/paulmck/RCU/linuxusage.html} [Viewed January 14, 2007]" -,annotation=" +,annotation={ Paul McKenney's RCU page showing graphs plotting Linux-kernel usage of RCU. -" +} } @unpublished{PaulEMcKenneyRCUusageRawDataPage @@ -1440,10 +1479,10 @@ Revised: ,note="Available: \url{http://www.rdrop.com/users/paulmck/RCU/linuxusage/rculocktab.html} [Viewed January 14, 2007]" -,annotation=" +,annotation={ Paul McKenney's RCU page showing Linux usage of RCU in tabular form, with links to corresponding cscope databases. -" +} } @unpublished{GauthamShenoy2006RCUrwlock @@ -1455,13 +1494,13 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2006/10/26/73} [Viewed January 26, 2009]" -,annotation=" +,annotation={ RCU-based reader-writer lock that allows readers to proceed with no memory barriers or atomic instruction in absence of writers. If writer do show up, readers must of course wait as required by the semantics of reader-writer locking. This is a recursive lock. -" +} } @unpublished{JensAxboe2006SlowSRCU @@ -1474,11 +1513,11 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2006/11/17/56} [Viewed May 28, 2007]" -,annotation=" +,annotation={ SRCU's grace periods are too slow for Jens, even after a factor-of-three speedup. Sped-up version of SRCU at http://lkml.org/lkml/2006/11/17/359. -" +} } @unpublished{OlegNesterov2006QRCU @@ -1491,10 +1530,10 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2006/11/19/69} [Viewed May 28, 2007]" -,annotation=" +,annotation={ First cut of QRCU. Expanded/corrected versions followed. Used to be OlegNesterov2007QRCU, now time-corrected. -" +} } @unpublished{OlegNesterov2006aQRCU @@ -1506,10 +1545,10 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2006/11/29/330} [Viewed November 26, 2008]" -,annotation=" +,annotation={ Expanded/corrected version of QRCU. Used to be OlegNesterov2007aQRCU, now time-corrected. -" +} } @unpublished{EvgeniyPolyakov2006RCUslowdown @@ -1521,10 +1560,10 @@ Revised: ,note="Available: \url{http://www.ioremap.net/node/41} [Viewed October 28, 2008]" -,annotation=" +,annotation={ Using RCU as a pure delay leads to a 2.5x slowdown in skbs in the Linux kernel. -" +} } @inproceedings{ChrisMatthews2006ClusteredObjectsRCU @@ -1541,7 +1580,8 @@ Revised: ,annotation={ Uses K42's RCU-like functionality to manage clustered-object lifetimes. -}} +} +} @article{DilmaDaSilva2006K42 ,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: ,address = {New York, NY, USA} ,annotation={ Describes relationship of K42 generations to RCU. -}} +} +} # CoreyMinyard2007list_splice_rcu @unpublished{CoreyMinyard2007list:splice:rcu @@ -1569,9 +1610,9 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2007/1/3/112} [Viewed May 28, 2007]" -,annotation=" +,annotation={ Patch for list_splice_rcu(). -" +} } @unpublished{PaulEMcKenney2007rcubarrier @@ -1583,9 +1624,9 @@ Revised: ,note="Available: \url{http://lwn.net/Articles/217484/} [Viewed November 22, 2007]" -,annotation=" +,annotation={ LWN article introducing the rcu_barrier() primitive. -" +} } @unpublished{PeterZijlstra2007SyncBarrier @@ -1597,10 +1638,10 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2007/1/28/34} [Viewed March 27, 2008]" -,annotation=" +,annotation={ RCU-like implementation for frequent updaters and rare readers(!). Subsumed into QRCU. Maybe... -" +} } @unpublished{PaulEMcKenney2007BoostRCU @@ -1609,14 +1650,13 @@ Revised: ,month="February" ,day="5" ,year="2007" -,note="Available: -\url{http://lwn.net/Articles/220677/} -Revised: -\url{http://www.rdrop.com/users/paulmck/RCU/RCUbooststate.2007.04.16a.pdf} -[Viewed September 7, 2007]" -,annotation=" +,note="\url{http://lwn.net/Articles/220677/}" +,annotation={ LWN article introducing RCU priority boosting. -" + Revised: + http://www.rdrop.com/users/paulmck/RCU/RCUbooststate.2007.04.16a.pdf + [Viewed September 7, 2007] +} } @unpublished{PaulMcKenney2007QRCUpatch @@ -1628,9 +1668,9 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2007/2/25/18} [Viewed March 27, 2008]" -,annotation=" +,annotation={ Patch for QRCU supplying lock-free fast path. -" +} } @article{JonathanAppavoo2007K42RCU @@ -1647,7 +1687,8 @@ Revised: ,address = {New York, NY, USA} ,annotation={ Role of RCU in K42. -}} +} +} @conference{RobertOlsson2007Trash ,Author="Robert Olsson and Stefan Nilsson" @@ -1658,9 +1699,9 @@ Revised: ,note="Available: \url{http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4281239} [Viewed October 1, 2010]" -,annotation=" +,annotation={ RCU-protected dynamic trie-hash combination. -" +} } @conference{PeterZijlstra2007ConcurrentPagecacheRCU @@ -1673,10 +1714,10 @@ Revised: ,note="Available: \url{http://ols.108.redhat.com/2007/Reprints/zijlstra-Reprint.pdf} [Viewed April 14, 2008]" -,annotation=" +,annotation={ Page-cache modifications permitting RCU readers and concurrent updates. -" +} } @unpublished{PaulEMcKenney2007whatisRCU @@ -1701,11 +1742,11 @@ Revised: ,note="Available: \url{http://lwn.net/Articles/243851/} [Viewed September 8, 2007]" -,annotation=" +,annotation={ LWN article describing Promela and spin, and also using Oleg Nesterov's QRCU as an example (with Paul McKenney's fastpath). Merged patch at: http://lkml.org/lkml/2007/2/25/18 -" +} } @unpublished{PaulEMcKenney2007WG21DDOatomics @@ -1714,12 +1755,12 @@ Revised: ,month="August" ,day="3" ,year="2007" -,note="Preprint: +,note="Available: \url{http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm} [Viewed December 7, 2009]" -,annotation=" +,annotation={ RCU for C++, parts 1 and 2. -" +} } @unpublished{PaulEMcKenney2007WG21DDOannotation @@ -1728,12 +1769,12 @@ Revised: ,month="September" ,day="18" ,year="2008" -,note="Preprint: +,note="Available: \url{http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2782.htm} [Viewed December 7, 2009]" -,annotation=" +,annotation={ RCU for C++, part 2, updated many times. -" +} } @unpublished{PaulEMcKenney2007PreemptibleRCUPatch @@ -1745,10 +1786,10 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2007/9/10/213} [Viewed October 25, 2007]" -,annotation=" +,annotation={ Final patch for preemptable RCU to -rt. (Later patches were to mainline, eventually incorporated.) -" +} } @unpublished{PaulEMcKenney2007PreemptibleRCU @@ -1760,9 +1801,9 @@ Revised: ,note="Available: \url{http://lwn.net/Articles/253651/} [Viewed October 25, 2007]" -,annotation=" +,annotation={ LWN article describing the design of preemptible RCU. -" +} } @article{ThomasEHart2007a @@ -1783,6 +1824,7 @@ Revised: } } +# MathieuDesnoyers2007call_rcu_schedNeeded @unpublished{MathieuDesnoyers2007call:rcu:schedNeeded ,Author="Mathieu Desnoyers" ,Title="Re: [patch 1/2] {Linux} Kernel Markers - Support Multiple Probes" @@ -1792,9 +1834,9 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2007/12/20/244} [Viewed March 27, 2008]" -,annotation=" +,annotation={ Request for call_rcu_sched() and rcu_barrier_sched(). -" +} } @@ -1815,11 +1857,11 @@ Revised: ,note="Available: \url{http://lwn.net/Articles/262464/} [Viewed December 27, 2007]" -,annotation=" +,annotation={ Lays out the three basic components of RCU: (1) publish-subscribe, (2) wait for pre-existing readers to complete, and (2) maintain multiple versions. -" +} } @unpublished{PaulEMcKenney2008WhatIsRCUUsage @@ -1831,7 +1873,7 @@ Revised: ,note="Available: \url{http://lwn.net/Articles/263130/} [Viewed January 4, 2008]" -,annotation=" +,annotation={ Lays out six uses of RCU: 1. RCU is a Reader-Writer Lock Replacement 2. RCU is a Restricted Reference-Counting Mechanism @@ -1839,7 +1881,7 @@ Revised: 4. RCU is a Poor Man's Garbage Collector 5. RCU is a Way of Providing Existence Guarantees 6. RCU is a Way of Waiting for Things to Finish -" +} } @unpublished{PaulEMcKenney2008WhatIsRCUAPI @@ -1851,10 +1893,10 @@ Revised: ,note="Available: \url{http://lwn.net/Articles/264090/} [Viewed January 10, 2008]" -,annotation=" +,annotation={ Gives an overview of the Linux-kernel RCU API and a brief annotated RCU bibliography. -" +} } # @@ -1872,10 +1914,10 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2008/1/29/208} [Viewed March 27, 2008]" -,annotation=" +,annotation={ Patch that prevents preemptible RCU from unnecessarily waking up dynticks-idle CPUs. -" +} } @unpublished{PaulEMcKenney2008LKMLDependencyOrdering @@ -1887,9 +1929,9 @@ Revised: ,note="Available: \url{http://lkml.org/lkml/2008/2/2/255} [Viewed October 18, 2008]" -,annotation=" +,annotation={ Explanation of compilers violating dependency ordering. -" +} } @Conference{PaulEMcKenney2008Beijing @@ -1916,24 +1958,26 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://lwn.net/Articles/279077/} [Viewed April 24, 2008]" -,annotation=" +,annotation={ Describes use of Promela and Spin to validate (and fix!) the dynticks/RCU interface. -" +} } @article{DinakarGuniguntala2008IBMSysJ ,author="D. Guniguntala and P. E. McKenney and J. Triplett and J. Walpole" ,title="The read-copy-update mechanism for supporting real-time applications on shared-memory multiprocessor systems with {Linux}" ,Year="2008" -,Month="April-June" +,Month="May" ,journal="IBM Systems Journal" ,volume="47" ,number="2" ,pages="221-236" -,annotation=" +,annotation={ RCU, realtime RCU, sleepable RCU, performance. -" + http://www.research.ibm.com/journal/sj/472/guniguntala.pdf + [Viewed April 24, 2008] +} } @unpublished{LaiJiangshan2008NewClassicAlgorithm @@ -1945,11 +1989,11 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://lkml.org/lkml/2008/6/2/539} [Viewed December 10, 2008]" -,annotation=" +,annotation={ Updated RCU classic algorithm. Introduced multi-tailed list for RCU callbacks and also pulling common code into __call_rcu(). -" +} } @article{PaulEMcKenney2008RCUOSR @@ -1966,6 +2010,7 @@ lot of {Linux} into your technology!!!" ,address="New York, NY, USA" ,annotation={ Linux changed RCU to a far greater degree than RCU has changed Linux. + http://portal.acm.org/citation.cfm?doid=1400097.1400099 } } @@ -1978,10 +2023,10 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://lkml.org/lkml/2008/8/21/336} [Viewed December 8, 2008]" -,annotation=" +,annotation={ State-based RCU. One key thing that this patch does is to separate the dynticks handling of NMIs and IRQs. -" +} } @unpublished{ManfredSpraul2008dyntickIRQNMI @@ -1993,12 +2038,13 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://lkml.org/lkml/2008/9/6/86} [Viewed December 8, 2008]" -,annotation=" +,annotation={ Manfred notes a fix required to my attempt to separate irq and NMI processing for hierarchical RCU's dynticks interface. -" +} } +# Was PaulEMcKenney2011cyclicRCU @techreport{PaulEMcKenney2008cyclicRCU ,author="Paul E. McKenney" ,title="Efficient Support of Consistent Cyclic Search With Read-Copy Update" @@ -2008,11 +2054,11 @@ lot of {Linux} into your technology!!!" ,number="US Patent 7,426,511" ,month="September" ,pages="23" -,annotation=" +,annotation={ Maintains an additional level of indirection to allow readers to confine themselves to the desired snapshot of the data structure. Only permits one update at a time. -" +} } @unpublished{PaulEMcKenney2008HierarchicalRCU @@ -2021,13 +2067,12 @@ lot of {Linux} into your technology!!!" ,month="November" ,day="3" ,year="2008" -,note="Available: -\url{http://lwn.net/Articles/305782/} -[Viewed November 6, 2008]" -,annotation=" +,note="\url{http://lwn.net/Articles/305782/}" +,annotation={ RCU with combining-tree-based grace-period detection, permitting it to handle thousands of CPUs. -" + [Viewed November 6, 2008] +} } @unpublished{PaulEMcKenney2009BloatwatchRCU @@ -2039,10 +2084,10 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://lkml.org/lkml/2009/1/14/449} [Viewed January 15, 2009]" -,annotation=" +,annotation={ Small-footprint implementation of RCU for uniprocessor embedded applications -- and also for exposition purposes. -" +} } @conference{PaulEMcKenney2009MaliciousURCU @@ -2055,9 +2100,9 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://www.rdrop.com/users/paulmck/RCU/urcutorture.2009.01.22a.pdf} [Viewed February 2, 2009]" -,annotation=" +,annotation={ Realtime RCU and torture-testing RCU uses. -" +} } @unpublished{MathieuDesnoyers2009URCU @@ -2066,16 +2111,14 @@ lot of {Linux} into your technology!!!" ,month="February" ,day="5" ,year="2009" -,note="Available: -\url{http://lkml.org/lkml/2009/2/5/572} -\url{http://lttng.org/urcu} -[Viewed February 20, 2009]" -,annotation=" +,note="\url{http://lttng.org/urcu}" +,annotation={ Mathieu Desnoyers's user-space RCU implementation. git://lttng.org/userspace-rcu.git http://lttng.org/cgi-bin/gitweb.cgi?p=userspace-rcu.git http://lttng.org/urcu -" + http://lkml.org/lkml/2009/2/5/572 +} } @unpublished{PaulEMcKenney2009LWNBloatWatchRCU @@ -2087,9 +2130,24 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://lwn.net/Articles/323929/} [Viewed March 20, 2009]" -,annotation=" +,annotation={ Uniprocessor assumptions allow simplified RCU implementation. -" +} +} + +@unpublished{EvgeniyPolyakov2009EllipticsNetwork +,Author="Evgeniy Polyakov" +,Title="The Elliptics Network" +,month="April" +,day="17" +,year="2009" +,note="Available: +\url{http://www.ioremap.net/projects/elliptics} +[Viewed April 30, 2009]" +,annotation={ + Distributed hash table with transactions, using elliptic + hash functions to distribute data. +} } @unpublished{PaulEMcKenney2009expeditedRCU @@ -2101,9 +2159,9 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://lkml.org/lkml/2009/6/25/306} [Viewed August 16, 2009]" -,annotation=" +,annotation={ First posting of expedited RCU to be accepted into -tip. -" +} } @unpublished{PaulEMcKenney2009fastRTRCU @@ -2115,21 +2173,21 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://lkml.org/lkml/2009/7/23/294} [Viewed August 15, 2009]" -,annotation=" +,annotation={ First posting of simple and fast preemptable RCU. -" +} } -@InProceedings{JoshTriplett2009RPHash +@unpublished{JoshTriplett2009RPHash ,Author="Josh Triplett" ,Title="Scalable concurrent hash tables via relativistic programming" ,month="September" ,year="2009" -,booktitle="Linux Plumbers Conference 2009" -,annotation=" +,note="Linux Plumbers Conference presentation" +,annotation={ RP fun with hash tables. - See also JoshTriplett2010RPHash -" + Superseded by JoshTriplett2010RPHash +} } @phdthesis{MathieuDesnoyersPhD @@ -2154,9 +2212,9 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://wiki.cs.pdx.edu/rp/} [Viewed December 9, 2009]" -,annotation=" +,annotation={ Main Relativistic Programming Wiki. -" +} } @conference{PaulEMcKenney2009DeterministicRCU @@ -2180,9 +2238,9 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://paulmck.livejournal.com/14639.html} [Viewed June 4, 2010]" -,annotation=" +,annotation={ Day-one bug in Tree RCU that took forever to track down. -" +} } @unpublished{MathieuDesnoyers2009defer:rcu @@ -2193,10 +2251,10 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://lkml.org/lkml/2009/10/18/129} [Viewed December 29, 2009]" -,annotation=" +,annotation={ Mathieu proposed defer_rcu() with fixed-size per-thread pool of RCU callbacks. -" +} } @unpublished{MathieuDesnoyers2009VerifPrePub @@ -2205,10 +2263,10 @@ lot of {Linux} into your technology!!!" ,month="December" ,year="2009" ,note="Submitted to IEEE TPDS" -,annotation=" +,annotation={ OOMem model for Mathieu's user-level RCU mechanical proof of correctness. -" +} } @unpublished{MathieuDesnoyers2009URCUPrePub @@ -2216,15 +2274,15 @@ lot of {Linux} into your technology!!!" ,Title="User-Level Implementations of Read-Copy Update" ,month="December" ,year="2010" -,url=\url{http://www.computer.org/csdl/trans/td/2012/02/ttd2012020375-abs.html} -,annotation=" +,url={\url{http://www.computer.org/csdl/trans/td/2012/02/ttd2012020375-abs.html}} +,annotation={ RCU overview, desiderata, semi-formal semantics, user-level RCU usage scenarios, three classes of RCU implementation, wait-free RCU updates, RCU grace-period batching, update overhead, http://www.rdrop.com/users/paulmck/RCU/urcu-main-accepted.2011.08.30a.pdf http://www.rdrop.com/users/paulmck/RCU/urcu-supp-accepted.2011.08.30a.pdf Superseded by MathieuDesnoyers2012URCU. -" +} } @inproceedings{HariKannan2009DynamicAnalysisRCU @@ -2240,7 +2298,8 @@ lot of {Linux} into your technology!!!" ,address = {New York, NY, USA} ,annotation={ Uses RCU to protect metadata used in dynamic analysis. -}} +} +} @conference{PaulEMcKenney2010SimpleOptRCU ,Author="Paul E. McKenney" @@ -2252,10 +2311,10 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://www.rdrop.com/users/paulmck/RCU/SimplicityThruOptimization.2010.01.21f.pdf} [Viewed October 10, 2010]" -,annotation=" +,annotation={ TREE_PREEMPT_RCU optimizations greatly simplified the old PREEMPT_RCU implementation. -" +} } @unpublished{PaulEMcKenney2010LockdepRCU @@ -2264,12 +2323,11 @@ lot of {Linux} into your technology!!!" ,month="February" ,year="2010" ,day="1" -,note="Available: -\url{https://lwn.net/Articles/371986/} -[Viewed June 4, 2010]" -,annotation=" +,note="\url{https://lwn.net/Articles/371986/}" +,annotation={ CONFIG_PROVE_RCU, or at least an early version. -" + [Viewed June 4, 2010] +} } @unpublished{AviKivity2010KVM2RCU @@ -2280,10 +2338,10 @@ lot of {Linux} into your technology!!!" ,note="Available: \url{http://www.mail-archive.com/kvm@vger.kernel.org/msg28640.html} [Viewed March 20, 2010]" -,annotation=" +,annotation={ Use of RCU permits KVM to increase the size of guest OSes from 16 CPUs to 64 CPUs. -" +} } @unpublished{HerbertXu2010RCUResizeHash @@ -2297,7 +2355,19 @@ lot of {Linux} into your technology!!!" ,annotation={ Use a pair of list_head structures to support RCU-protected resizable hash tables. -}} +} +} + +@mastersthesis{AbhinavDuggal2010Masters +,author="Abhinav Duggal" +,title="Stopping Data Races Using Redflag" +,school="Stony Brook University" +,year="2010" +,annotation={ + Data-race detector incorporating RCU. + http://www.filesystems.org/docs/abhinav-thesis/abhinav_thesis.pdf +} +} @article{JoshTriplett2010RPHash ,author="Josh Triplett and Paul E. McKenney and Jonathan Walpole" @@ -2310,7 +2380,8 @@ lot of {Linux} into your technology!!!" ,annotation={ RP fun with hash tables. http://portal.acm.org/citation.cfm?id=1842733.1842750 -}} +} +} @unpublished{PaulEMcKenney2010RCUAPI ,Author="Paul E. McKenney" @@ -2318,12 +2389,11 @@ lot of {Linux} into your technology!!!" ,month="December" ,day="8" ,year="2010" -,note="Available: -\url{http://lwn.net/Articles/418853/} -[Viewed December 8, 2010]" -,annotation=" +,note="\url{http://lwn.net/Articles/418853/}" +,annotation={ Includes updated software-engineering features. -" + [Viewed December 8, 2010] +} } @mastersthesis{AndrejPodzimek2010masters @@ -2338,7 +2408,8 @@ lot of {Linux} into your technology!!!" Reviews RCU implementations and creates a few for OpenSolaris. Drives quiescent-state detection from RCU read-side primitives, in a manner roughly similar to that of Jim Houston. -}} +} +} @unpublished{LinusTorvalds2011Linux2:6:38:rc1:NPigginVFS ,Author="Linus Torvalds" @@ -2358,7 +2429,8 @@ lot of {Linux} into your technology!!!" of the most expensive parts of path component lookup, which was the d_lock on every component lookup. So I'm seeing improvements of 30-50% on some seriously pathname-lookup intensive loads." -}} +} +} @techreport{JoshTriplett2011RPScalableCorrectOrdering ,author = {Josh Triplett and Philip W. Howard and Paul E. McKenney and Jonathan Walpole} @@ -2392,12 +2464,12 @@ lot of {Linux} into your technology!!!" ,number="US Patent 7,953,778" ,month="May" ,pages="34" -,annotation=" +,annotation={ Maintains an array of generation numbers to track in-flight updates and keeps an additional level of indirection to allow readers to confine themselves to the desired snapshot of the data structure. -" +} } @inproceedings{Triplett:2011:RPHash @@ -2408,7 +2480,7 @@ lot of {Linux} into your technology!!!" ,year = {2011} ,pages = {145--158} ,numpages = {14} -,url={http://www.usenix.org/event/atc11/tech/final_files/atc11_proceedings.pdf} +,url={http://www.usenix.org/event/atc11/tech/final_files/Triplett.pdf} ,publisher = {The USENIX Association} ,address = {Portland, OR USA} } @@ -2419,27 +2491,58 @@ lot of {Linux} into your technology!!!" ,month="July" ,day="27" ,year="2011" -,note="Available: -\url{http://lwn.net/Articles/453002/} -[Viewed July 27, 2011]" -,annotation=" +,note="\url{http://lwn.net/Articles/453002/}" +,annotation={ Analysis of the RCU trainwreck in Linux kernel 3.0. -" + [Viewed July 27, 2011] +} } @unpublished{NeilBrown2011MeetTheLockers ,Author="Neil Brown" -,Title="Meet the Lockers" +,Title="Meet the {Lockers}" ,month="August" ,day="3" ,year="2011" ,note="Available: \url{http://lwn.net/Articles/453685/} [Viewed September 2, 2011]" -,annotation=" +,annotation={ The Locker family as an analogy for locking, reference counting, RCU, and seqlock. -" +} +} + +@inproceedings{Seyster:2011:RFA:2075416.2075425 +,author = {Seyster, Justin and Radhakrishnan, Prabakar and Katoch, Samriti and Duggal, Abhinav and Stoller, Scott D. and Zadok, Erez} +,title = {Redflag: a framework for analysis of Kernel-level concurrency} +,booktitle = {Proceedings of the 11th international conference on Algorithms and architectures for parallel processing - Volume Part I} +,series = {ICA3PP'11} +,year = {2011} +,isbn = {978-3-642-24649-4} +,location = {Melbourne, Australia} +,pages = {66--79} +,numpages = {14} +,url = {http://dl.acm.org/citation.cfm?id=2075416.2075425} +,acmid = {2075425} +,publisher = {Springer-Verlag} +,address = {Berlin, Heidelberg} +} + +@phdthesis{JoshTriplettPhD +,author="Josh Triplett" +,title="Relativistic Causal Ordering: A Memory Model for Scalable Concurrent Data Structures" +,school="Portland State University" +,year="2012" +,annotation={ + RCU-protected hash tables, barriers vs. read-side traversal order. + . + If the updater is making changes in the opposite direction from + the read-side traveral order, the updater need only execute a + memory-barrier instruction, but if in the same direction, the + updater needs to wait for a grace period between the individual + updates. +} } @article{MathieuDesnoyers2012URCU @@ -2459,5 +2562,150 @@ lot of {Linux} into your technology!!!" RCU updates, RCU grace-period batching, update overhead, http://www.rdrop.com/users/paulmck/RCU/urcu-main-accepted.2011.08.30a.pdf http://www.rdrop.com/users/paulmck/RCU/urcu-supp-accepted.2011.08.30a.pdf + http://www.computer.org/cms/Computer.org/dl/trans/td/2012/02/extras/ttd2012020375s.pdf +} +} + +@inproceedings{AustinClements2012RCULinux:mmapsem +,author = {Austin Clements and Frans Kaashoek and Nickolai Zeldovich} +,title = {Scalable Address Spaces Using {RCU} Balanced Trees} +,booktitle = {Architectural Support for Programming Languages and Operating Systems (ASPLOS 2012)} +,month = {March} +,year = {2012} +,pages = {199--210} +,numpages = {12} +,publisher = {ACM} +,address = {London, UK} +,url="http://people.csail.mit.edu/nickolai/papers/clements-bonsai.pdf" +} + +@unpublished{PaulEMcKenney2012ELCbattery +,Author="Paul E. McKenney" +,Title="Making {RCU} Safe For Battery-Powered Devices" +,month="February" +,day="15" +,year="2012" +,note="Available: +\url{http://www.rdrop.com/users/paulmck/RCU/RCUdynticks.2012.02.15b.pdf} +[Viewed March 1, 2012]" +,annotation={ + RCU_FAST_NO_HZ, round 2. +} +} + +@article{GuillermoVigueras2012RCUCrowd +,author = {Vigueras, Guillermo and Ordu\~{n}a, Juan M. and Lozano, Miguel} +,day = {25} +,doi = {10.1007/s11227-012-0766-x} +,issn = {0920-8542} +,journal = {The Journal of Supercomputing} +,keywords = {linux, simulation} +,month = apr +,posted-at = {2012-05-03 09:12:04} +,priority = {2} +,title = {{A Read-Copy Update based parallel server for distributed crowd simulations}} +,url = {http://dx.doi.org/10.1007/s11227-012-0766-x} +,year = {2012} +} + + +@unpublished{JonCorbet2012ACCESS:ONCE +,Author="Jon Corbet" +,Title="{ACCESS\_ONCE()}" +,month="August" +,day="1" +,year="2012" +,note="\url{http://lwn.net/Articles/508991/}" +,annotation={ + A couple of simple specific compiler optimizations that motivate + ACCESS_ONCE(). +} +} + +@unpublished{AlexeyGotsman2012VerifyGraceExtended +,Author="Alexey Gotsman and Noam Rinetzky and Hongseok Yang" +,Title="Verifying Highly Concurrent Algorithms with Grace (extended version)" +,month="July" +,day="10" +,year="2012" +,note="\url{http://software.imdea.org/~gotsman/papers/recycling-esop13-ext.pdf}" +,annotation={ + Separation-logic formulation of RCU uses. +} +} + +@unpublished{PaulMcKenney2012RCUUsage +,Author="Paul E. McKenney and Silas Boyd-Wickizer and Jonathan Walpole" +,Title="{RCU} Usage In the Linux Kernel: One Decade Later" +,month="September" +,day="17" +,year="2012" +,url=http://rdrop.com/users/paulmck/techreports/survey.2012.09.17a.pdf +,note="Technical report paulmck.2012.09.17" +,annotation={ + Overview of the first variant of no-CBs CPUs for RCU. +} +} + +@unpublished{JonCorbet2012NOCB +,Author="Jon Corbet" +,Title="Relocating RCU callbacks" +,month="October" +,day="31" +,year="2012" +,note="\url{http://lwn.net/Articles/522262/}" +,annotation={ + Overview of the first variant of no-CBs CPUs for RCU. +} +} + +@phdthesis{JustinSeyster2012PhD +,author="Justin Seyster" +,title="Runtime Verification of Kernel-Level Concurrency Using Compiler-Based Instrumentation" +,school="Stony Brook University" +,year="2012" +,annotation={ + Looking for data races, including those involving RCU. + Proposal: + http://www.fsl.cs.sunysb.edu/docs/jseyster-proposal/redflag.pdf + Dissertation: + http://www.fsl.cs.sunysb.edu/docs/jseyster-dissertation/redflag.pdf +} +} + +@unpublished{PaulEMcKenney2013RCUUsage +,Author="Paul E. McKenney and Silas Boyd-Wickizer and Jonathan Walpole" +,Title="{RCU} Usage in the {Linux} Kernel: One Decade Later" +,month="February" +,day="24" +,year="2013" +,note="\url{http://rdrop.com/users/paulmck/techreports/RCUUsage.2013.02.24a.pdf}" +,annotation={ + Usage of RCU within the Linux kernel. +} +} + +@inproceedings{AlexeyGotsman2013ESOPRCU +,author = {Alexey Gotsman and Noam Rinetzky and Hongseok Yang} +,title = {Verifying concurrent memory reclamation algorithms with grace} +,booktitle = {ESOP'13: European Symposium on Programming} +,year = {2013} +,pages = {249--269} +,publisher = {Springer} +,address = {Rome, Italy} +,annotation={ + http://software.imdea.org/~gotsman/papers/recycling-esop13.pdf +} +} + +@unpublished{PaulEMcKenney2013NoTinyPreempt +,Author="Paul E. McKenney" +,Title="Simplifying RCU" +,month="March" +,day="6" +,year="2013" +,note="\url{http://lwn.net/Articles/541037/}" +,annotation={ + Getting rid of TINY_PREEMPT_RCU. } } 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. rcu_barrier() -We instead need the rcu_barrier() primitive. This primitive is similar -to synchronize_rcu(), but instead of waiting solely for a grace -period to elapse, it also waits for all outstanding RCU callbacks to -complete. Pseudo-code using rcu_barrier() is as follows: +We instead need the rcu_barrier() primitive. Rather than waiting for +a grace period to elapse, rcu_barrier() waits for all outstanding RCU +callbacks to complete. Please note that rcu_barrier() does -not- imply +synchronize_rcu(), in particular, if there are no RCU callbacks queued +anywhere, rcu_barrier() is within its rights to return immediately, +without waiting for a grace period to elapse. + +Pseudo-code using rcu_barrier() is as follows: 1. Prevent any new RCU callbacks from being posted. 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 fqs_stutter Wait time (in seconds) between consecutive bursts of calls to force_quiescent_state(). +gp_normal Make the fake writers use normal synchronous grace-period + primitives. + +gp_exp Make the fake writers use expedited synchronous grace-period + primitives. If both gp_normal and gp_exp are set, or + if neither gp_normal nor gp_exp are set, then randomly + choose the primitive so that about 50% are normal and + 50% expedited. By default, neither are set, which + gives best overall test coverage. + irqreader Says to invoke RCU readers from irq level. This is currently done via timers. Defaults to "1" for variants of RCU that permit this. (Or, more accurately, variants of RCU that do diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a97dff3..d977778b5e67 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -228,19 +228,9 @@ ACPI handle like: I2C serial bus support ~~~~~~~~~~~~~~~~~~~~~~ The slaves behind I2C bus controller only need to add the ACPI IDs like -with the platform and SPI drivers. However the I2C bus controller driver -needs to call acpi_i2c_register_devices() after it has added the adapter. - -An I2C bus (controller) driver does: - - ... - ret = i2c_add_numbered_adapter(adapter); - if (ret) - /* handle error */ - - of_i2c_register_devices(adapter); - /* Enumerate the slave devices behind this bus via ACPI */ - acpi_i2c_register_devices(adapter); +with the platform and SPI drivers. The I2C core automatically enumerates +any slave devices behind the controller device once the adapter is +registered. Below is an example of how to add ACPI support to the existing mpu3050 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: 2. Initialise one serial port. 3. Detect the machine type. 4. Setup the kernel tagged list. -5. Call the kernel image. +5. Load initramfs. +6. Call the kernel image. 1. Setup and initialise RAM @@ -120,12 +121,27 @@ tagged list. The boot loader must pass at a minimum the size and location of the system memory, and the root filesystem location. The dtb must be placed in a region of memory where the kernel decompressor will not -overwrite it. The recommended placement is in the first 16KiB of RAM -with the caveat that it may not be located at physical address 0 since -the kernel interprets a value of 0 in r2 to mean neither a tagged list -nor a dtb were passed. +overwrite it, whilst remaining within the region which will be covered +by the kernel's low-memory mapping. -5. Calling the kernel image +A safe location is just above the 128MiB boundary from start of RAM. + +5. Load initramfs. +------------------ + +Existing boot loaders: OPTIONAL +New boot loaders: OPTIONAL + +If an initramfs is in use then, as with the dtb, it must be placed in +a region of memory where the kernel decompressor will not overwrite it +while also with the region which will be covered by the kernel's +low-memory mapping. + +A safe location is just above the device tree blob which itself will +be loaded just above the 128MiB boundary from the start of RAM as +recommended above. + +6. Calling the kernel image --------------------------- Existing boot loaders: MANDATORY @@ -136,11 +152,17 @@ is stored in flash, and is linked correctly to be run from flash, then it is legal for the boot loader to call the zImage in flash directly. -The zImage may also be placed in system RAM (at any location) and -called there. Note that the kernel uses 16K of RAM below the image -to store page tables. The recommended placement is 32KiB into RAM. +The zImage may also be placed in system RAM and called there. The +kernel should be placed in the first 128MiB of RAM. It is recommended +that it is loaded above 32MiB in order to avoid the need to relocate +prior to decompression, which will make the boot process slightly +faster. + +When booting a raw (non-zImage) kernel the constraints are tighter. +In this case the kernel must be loaded at an offset into system equal +to TEXT_OFFSET - PAGE_OFFSET. -In either case, the following conditions must be met: +In any case, the following conditions must be met: - Quiesce all DMA capable devices so that memory does not get corrupted by bogus network packets or disk data. This will save 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 @@ +Kernel mode NEON +================ + +TL;DR summary +------------- +* Use only NEON instructions, or VFP instructions that don't rely on support + code +* Isolate your NEON code in a separate compilation unit, and compile it with + '-mfpu=neon -mfloat-abi=softfp' +* Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your + NEON code +* Don't sleep in your NEON code, and be aware that it will be executed with + preemption disabled + + +Introduction +------------ +It is possible to use NEON instructions (and in some cases, VFP instructions) in +code that runs in kernel mode. However, for performance reasons, the NEON/VFP +register file is not preserved and restored at every context switch or taken +exception like the normal register file is, so some manual intervention is +required. Furthermore, special care is required for code that may sleep [i.e., +may call schedule()], as NEON or VFP instructions will be executed in a +non-preemptible section for reasons outlined below. + + +Lazy preserve and restore +------------------------- +The NEON/VFP register file is managed using lazy preserve (on UP systems) and +lazy restore (on both SMP and UP systems). This means that the register file is +kept 'live', and is only preserved and restored when multiple tasks are +contending for the NEON/VFP unit (or, in the SMP case, when a task migrates to +another core). Lazy restore is implemented by disabling the NEON/VFP unit after +every context switch, resulting in a trap when subsequently a NEON/VFP +instruction is issued, allowing the kernel to step in and perform the restore if +necessary. + +Any use of the NEON/VFP unit in kernel mode should not interfere with this, so +it is required to do an 'eager' preserve of the NEON/VFP register file, and +enable the NEON/VFP unit explicitly so no exceptions are generated on first +subsequent use. This is handled by the function kernel_neon_begin(), which +should be called before any kernel mode NEON or VFP instructions are issued. +Likewise, the NEON/VFP unit should be disabled again after use to make sure user +mode will hit the lazy restore trap upon next use. This is handled by the +function kernel_neon_end(). + + +Interruptions in kernel mode +---------------------------- +For reasons of performance and simplicity, it was decided that there shall be no +preserve/restore mechanism for the kernel mode NEON/VFP register contents. This +implies that interruptions of a kernel mode NEON section can only be allowed if +they are guaranteed not to touch the NEON/VFP registers. For this reason, the +following rules and restrictions apply in the kernel: +* NEON/VFP code is not allowed in interrupt context; +* NEON/VFP code is not allowed to sleep; +* NEON/VFP code is executed with preemption disabled. + +If latency is a concern, it is possible to put back to back calls to +kernel_neon_end() and kernel_neon_begin() in places in your code where none of +the NEON registers are live. (Additional calls to kernel_neon_begin() should be +reasonably cheap if no context switch occurred in the meantime) + + +VFP and support code +-------------------- +Earlier versions of VFP (prior to version 3) rely on software support for things +like IEEE-754 compliant underflow handling etc. When the VFP unit needs such +software assistance, it signals the kernel by raising an undefined instruction +exception. The kernel responds by inspecting the VFP control registers and the +current instruction and arguments, and emulates the instruction in software. + +Such software assistance is currently not implemented for VFP instructions +executed in kernel mode. If such a condition is encountered, the kernel will +fail and generate an OOPS. + + +Separating NEON code from ordinary code +--------------------------------------- +The compiler is not aware of the special significance of kernel_neon_begin() and +kernel_neon_end(), i.e., that it is only allowed to issue NEON/VFP instructions +between calls to these respective functions. Furthermore, GCC may generate NEON +instructions of its own at -O3 level if -mfpu=neon is selected, and even if the +kernel is currently compiled at -O2, future changes may result in NEON/VFP +instructions appearing in unexpected places if no special care is taken. + +Therefore, the recommended and only supported way of using NEON/VFP in the +kernel is by adhering to the following rules: +* isolate the NEON code in a separate compilation unit and compile it with + '-mfpu=neon -mfloat-abi=softfp'; +* issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls + into the unit containing the NEON code from a compilation unit which is *not* + built with the GCC flag '-mfpu=neon' set. + +As the kernel is compiled with '-msoft-float', the above will guarantee that +both NEON and VFP instructions will only ever appear in designated compilation +units at any optimization level. + + +NEON assembler +-------------- +NEON assembler is supported with no additional caveats as long as the rules +above are followed. + + +NEON code generated by GCC +-------------------------- +The GCC option -ftree-vectorize (implied by -O3) tries to exploit implicit +parallelism, and generates NEON code from ordinary C source code. This is fully +supported as long as the rules above are followed. + + +NEON intrinsics +--------------- +NEON intrinsics are also supported. However, as code using NEON intrinsics +relies on the GCC header <arm_neon.h>, (which #includes <stdint.h>), you should +observe the following in addition to the rules above: +* Compile the unit containing the NEON intrinsics with '-ffreestanding' so GCC + uses its builtin version of <stdint.h> (this is a C99 header which the kernel + does not supply); +* Include <arm_neon.h> last, or at least after <linux/types.h> 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? cpufreq_driver.name - The name of this driver. -cpufreq_driver.owner - THIS_MODULE; - cpufreq_driver.init - A pointer to the per-CPU initialization function. 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 @@ * ARM architected timer -ARM cores may have a per-core architected timer, which provides per-cpu timers. +ARM cores may have a per-core architected timer, which provides per-cpu timers, +or a memory mapped architected timer, which provides up to 8 frames with a +physical and optional virtual timer per frame. -The timer is attached to a GIC to deliver its per-processor interrupts. +The per-core architected timer is attached to a GIC to deliver its +per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC +to deliver its interrupts via SPIs. -** Timer node properties: +** CP15 Timer node properties: - compatible : Should at least contain one of "arm,armv7-timer" @@ -26,3 +30,52 @@ Example: <1 10 0xf08>; clock-frequency = <100000000>; }; + +** Memory mapped timer node properties: + +- compatible : Should at least contain "arm,armv7-timer-mem". + +- clock-frequency : The frequency of the main counter, in Hz. Optional. + +- reg : The control frame base address. + +Note that #address-cells, #size-cells, and ranges shall be present to ensure +the CPU can address a frame's registers. + +A timer node has up to 8 frame sub-nodes, each with the following properties: + +- frame-number: 0 to 7. + +- interrupts : Interrupt list for physical and virtual timers in that order. + The virtual timer interrupt is optional. + +- reg : The first and second view base addresses in that order. The second view + base address is optional. + +- status : "disabled" indicates the frame is not available for use. Optional. + +Example: + + timer@f0000000 { + compatible = "arm,armv7-timer-mem"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + reg = <0xf0000000 0x1000>; + clock-frequency = <50000000>; + + frame@f0001000 { + frame-number = <0> + interrupts = <0 13 0x8>, + <0 14 0x8>; + reg = <0xf0001000 0x1000>, + <0xf0002000 0x1000>; + }; + + frame@f0003000 { + frame-number = <1> + interrupts = <0 15 0x8>; + reg = <0xf0003000 0x1000>; + status = "disabled"; + }; + }; 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 @@ * AT91's Analog to Digital Converter (ADC) Required properties: - - compatible: Should be "atmel,at91sam9260-adc" + - compatible: Should be "atmel,<chip>-adc" + <chip> can be "at91sam9260", "at91sam9g45" or "at91sam9x5" - reg: Should contain ADC registers location and length - interrupts: Should contain the IRQ line for the ADC - - atmel,adc-channel-base: Offset of the first channel data register - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this device - - atmel,adc-drdy-mask: Mask of the DRDY interruption in the ADC - atmel,adc-num-channels: Number of channels available in the ADC - atmel,adc-startup-time: Startup Time of the ADC in microseconds as defined in the datasheet - - atmel,adc-status-register: Offset of the Interrupt Status Register - - atmel,adc-trigger-register: Offset of the Trigger Register - atmel,adc-vref: Reference voltage in millivolts for the conversions - atmel,adc-res: List of resolution in bits supported by the ADC. List size 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: performs the same operation). "marvell,"aurora-outer-cache: Marvell Controller designed to be compatible with the ARM one with outer cache mode. - "bcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an + "brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an offset needs to be added to the address before passing down to the L2 cache controller + "bcm,bcm11351-a2-pl310-cache": DEPRECATED by + "brcm,bcm11351-a2-pl310-cache" - cache-unified : Specifies the cache is a unified cache. - cache-level : Should be set to 2 for a level 2 cache. - reg : Physical base address and size of cache controller's memory mapped 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. Each SATA controller should have its own node. Required properties: -- compatible : compatible list, contains "calxeda,hb-ahci" or "snps,spear-ahci" +- compatible : compatible list, contains "snps,spear-ahci" - interrupts : <interrupt mapping for SATA IRQ> - reg : <registers mapping> Optional properties: -- calxeda,port-phys: phandle-combophy and lane assignment, which maps each - SATA port to a combophy and a lane within that - combophy -- calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off, - which indicates that the driver supports SGPIO - indicator lights using the indicated GPIOs -- calxeda,led-order : a u32 array that map port numbers to offsets within the - SGPIO bitstream. - dma-coherent : Present if dma operations are coherent Example: sata@ffe08000 { - compatible = "calxeda,hb-ahci"; - reg = <0xffe08000 0x1000>; - interrupts = <115>; - calxeda,port-phys = <&combophy5 0 &combophy0 0 &combophy0 1 - &combophy0 2 &combophy0 3>; + compatible = "snps,spear-ahci"; + reg = <0xffe08000 0x1000>; + interrupts = <115>; }; 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 @@ +* Calxeda AHCI SATA Controller + +SATA nodes are defined to describe on-chip Serial ATA controllers. +The Calxeda SATA controller mostly conforms to the AHCI interface +with some special extensions to add functionality. +Each SATA controller should have its own node. + +Required properties: +- compatible : compatible list, contains "calxeda,hb-ahci" +- interrupts : <interrupt mapping for SATA IRQ> +- reg : <registers mapping> + +Optional properties: +- dma-coherent : Present if dma operations are coherent +- calxeda,port-phys : phandle-combophy and lane assignment, which maps each + SATA port to a combophy and a lane within that + combophy +- calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off, + which indicates that the driver supports SGPIO + indicator lights using the indicated GPIOs +- calxeda,led-order : a u32 array that map port numbers to offsets within the + SGPIO bitstream. +- calxeda,tx-atten : a u32 array that contains TX attenuation override + codes, one per port. The upper 3 bytes are always + 0 and thus ignored. +- calxeda,pre-clocks : a u32 that indicates the number of additional clock + cycles to transmit before sending an SGPIO pattern +- calxeda,post-clocks: a u32 that indicates the number of additional clock + cycles to transmit after sending an SGPIO pattern + +Example: + sata@ffe08000 { + compatible = "calxeda,hb-ahci"; + reg = <0xffe08000 0x1000>; + interrupts = <115>; + dma-coherent; + calxeda,port-phys = <&combophy5 0 &combophy0 0 &combophy0 1 + &combophy0 2 &combophy0 3>; + calxeda,sgpio-gpio =<&gpioh 5 1 &gpioh 6 1 &gpioh 7 1>; + calxeda,led-order = <4 0 1 2 3>; + calxeda,tx-atten = <0xff 22 0xff 0xff 23>; + calxeda,pre-clocks = <10>; + calxeda,post-clocks = <0>; + }; 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 @@ -EXTCON FOR TWL CHIPS +EXTCON FOR PALMAS/TWL CHIPS PALMAS USB COMPARATOR Required Properties: - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb" - - vbus-supply : phandle to the regulator device tree node. Optional Properties: - ti,wakeup : To enable the wakeup comparator in probe + - ti,enable-id-detection: Perform ID detection. + - ti,enable-vbus-detection: Perform VBUS detection. palmas-usb { compatible = "ti,twl6035-usb", "ti,palmas-usb"; - vbus-supply = <&smps10_reg>; ti,wakeup; }; 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: gpio-controller; }; -2.1) gpio-controller and pinctrl subsystem ------------------------------------------- +2.1) gpio- and pin-controller interaction +----------------------------------------- -gpio-controller on a SOC might be tightly coupled with the pinctrl -subsystem, in the sense that the pins can be used by other functions -together with optional gpio feature. +Some or all of the GPIOs provided by a GPIO controller may be routed to pins +on the package via a pin controller. This allows muxing those pins between +GPIO and other functions. -While the pin allocation is totally managed by the pin ctrl subsystem, -gpio (under gpiolib) is still maintained by gpio drivers. It may happen -that different pin ranges in a SoC is managed by different gpio drivers. +It is useful to represent which GPIOs correspond to which pins on which pin +controllers. The gpio-ranges property described below represents this, and +contains information structures as follows: -This makes it logical to let gpio drivers announce their pin ranges to -the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to -request the corresponding pin before any gpio usage. + gpio-range-list ::= <single-gpio-range> [gpio-range-list] + single-gpio-range ::= + <pinctrl-phandle> <gpio-base> <pinctrl-base> <count> + gpio-phandle : phandle to pin controller node. + gpio-base : Base GPIO ID in the GPIO controller + pinctrl-base : Base pinctrl pin ID in the pin controller + count : The number of GPIOs/pins in this range -For this, the gpio controller can use a pinctrl phandle and pins to -announce the pinrange to the pin ctrl subsystem. For example, +The "pin controller node" mentioned above must conform to the bindings +described in ../pinctrl/pinctrl-bindings.txt. + +Previous versions of this binding required all pin controller nodes that +were referenced by any gpio-ranges property to contain a property named +#gpio-range-cells with value <3>. This requirement is now deprecated. +However, that property may still exist in older device trees for +compatibility reasons, and would still be required even in new device +trees that need to be compatible with older software. + +Example: qe_pio_e: gpio-controller@1460 { #gpio-cells = <2>; @@ -99,16 +112,8 @@ announce the pinrange to the pin ctrl subsystem. For example, reg = <0x1460 0x18>; gpio-controller; gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>; + }; - } - -where, - &pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node. - - Next values specify the base pin and number of pins for the range - handled by 'qe_pio_e' gpio. In the given example from base pin 20 to - pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under - pinctrl2 with gpio offset 10 is handled by this gpio controller. - -The pinctrl node must have "#gpio-range-cells" property to show number of -arguments to pass with phandle from gpio controllers node. +Here, a single GPIO controller has GPIOs 0..9 routed to pin controller +pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's +pins 50..59. 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 @@ +* Samsung Image Rotator + +Required properties: + - compatible : value should be one of the following: + (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210 + (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412 + (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250 + + - reg : Physical base address of the IP registers and length of memory + mapped region. + + - interrupts : Interrupt specifier for rotator interrupt, according to format + specific to interrupt parent. + + - clocks : Clock specifier for rotator clock, according to generic clock + bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt) + + - clock-names : Names of clocks. For exynos rotator, it should be "rotator". + +Example: + rotator@12810000 { + compatible = "samsung,exynos4210-rotator"; + reg = <0x12810000 0x1000>; + interrupts = <0 83 0>; + clocks = <&clock 278>; + clock-names = "rotator"; + }; 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 @@ * Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX Required properties: -- compatible : Should be "fsl,<chip>-i2c" +- compatible : + - "fsl,imx1-i2c" for I2C compatible with the one integrated on i.MX1 SoC + - "fsl,imx21-i2c" for I2C compatible with the one integrated on i.MX21 SoC + - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC - reg : Should contain I2C/HS-I2C registers location and length - interrupts : Should contain I2C/HS-I2C interrupt diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt index a1ee681942cc..82e8f6f17179 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt @@ -4,7 +4,8 @@ Required properties : - reg : Offset and length of the register set for the device - - compatible : Should be "marvell,mv64xxx-i2c" + - compatible : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c" + or "marvell,mv78230-i2c" - interrupts : The interrupt number Optional properties : @@ -20,3 +21,12 @@ Examples: interrupts = <29>; clock-frequency = <100000>; }; + +For the Armada XP: + + i2c@11000 { + compatible = "marvell,mv78230-i2c", "marvell,mv64xxx-i2c"; + reg = <0x11000 0x100>; + interrupts = <29>; + clock-frequency = <100000>; + }; 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 @@ +* Bosch BMA180 triaxial acceleration sensor + +http://omapworld.com/BMA180_111_1002839.pdf + +Required properties: + + - compatible : should be "bosch,bma180" + - reg : the I2C address of the sensor + +Optional properties: + + - interrupt-parent : should be the phandle for the interrupt controller + + - interrupts : interrupt mapping for GPIO IRQ, it should by configured with + flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING + +Example: + +bma180@40 { + compatible = "bosch,bma180"; + reg = <0x40>; + interrupt-parent = <&gpio6>; + interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>; +}; 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 @@ +* Nuvoton NAU7802 Analog to Digital Converter (ADC) + +Required properties: + - compatible: Should be "nuvoton,nau7802" + - reg: Should contain the ADC I2C address + +Optional properties: + - nuvoton,vldo: Internal reference voltage in millivolts to be + configured valid values are between 2400 mV and 4500 mV. + - interrupts: IRQ line for the ADC. If not used the driver will use + polling. + +Example: +adc2: nau7802@2a { + compatible = "nuvoton,nau7802"; + reg = <0x2a>; + nuvoton,vldo = <3000>; +}; 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 @@ +* Avago APDS9300 ambient light sensor + +http://www.avagotech.com/docs/AV02-1077EN + +Required properties: + + - compatible : should be "avago,apds9300" + - reg : the I2C address of the sensor + +Optional properties: + + - interrupt-parent : should be the phandle for the interrupt controller + - interrupts : interrupt mapping for GPIO IRQ + +Example: + +apds9300@39 { + compatible = "avago,apds9300"; + reg = <0x39>; + interrupt-parent = <&gpio2>; + interrupts = <29 8>; +}; 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 @@ +* Analog Devices adv7343 video encoder + +The ADV7343 are high speed, digital-to-analog video encoders in a 64-lead LQFP +package. Six high speed, 3.3 V, 11-bit video DACs provide support for composite +(CVBS), S-Video (Y-C), and component (YPrPb/RGB) analog outputs in standard +definition (SD), enhanced definition (ED), or high definition (HD) video +formats. + +Required Properties : +- compatible: Must be "adi,adv7343" + +Optional Properties : +- adi,power-mode-sleep-mode: on enable the current consumption is reduced to + micro ampere level. All DACs and the internal PLL + circuit are disabled. +- adi,power-mode-pll-ctrl: PLL and oversampling control. This control allows + internal PLL 1 circuit to be powered down and the + oversampling to be switched off. +- ad,adv7343-power-mode-dac: array configuring the power on/off DAC's 1..6, + 0 = OFF and 1 = ON, Default value when this + property is not specified is <0 0 0 0 0 0>. +- ad,adv7343-sd-config-dac-out: array configure SD DAC Output's 1 and 2, 0 = OFF + and 1 = ON, Default value when this property is + not specified is <0 0>. + +Example: + +i2c0@1c22000 { + ... + ... + + adv7343@2a { + compatible = "adi,adv7343"; + reg = <0x2a>; + + port { + adv7343_1: endpoint { + adi,power-mode-sleep-mode; + adi,power-mode-pll-ctrl; + /* Use DAC1..3, DAC6 */ + adi,dac-enable = <1 1 1 0 0 1>; + /* Use SD DAC output 1 */ + adi,sd-dac-enable = <1 0>; + }; + }; + }; + ... +}; 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 @@ +* Texas Instruments THS8200 video encoder + +The ths8200 device is a digital to analog converter used in DVD players, video +recorders, set-top boxes. + +Required Properties : +- compatible : value must be "ti,ths8200" + +Example: + + i2c0@1c22000 { + ... + ... + ths8200@5c { + compatible = "ti,ths8200"; + reg = <0x5c>; + }; + ... + }; 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 @@ +* Texas Instruments TV7002 video decoder + +The TVP7002 device supports digitizing of video and graphics signal in RGB and +YPbPr color space. + +Required Properties : +- compatible : Must be "ti,tvp7002" + +Optional Properties: +- hsync-active: HSYNC Polarity configuration for the bus. Default value when + this property is not specified is <0>. + +- vsync-active: VSYNC Polarity configuration for the bus. Default value when + this property is not specified is <0>. + +- pclk-sample: Clock polarity of the bus. Default value when this property is + not specified is <0>. + +- sync-on-green-active: Active state of Sync-on-green signal property of the + endpoint. + 0 = Normal Operation (Active Low, Default) + 1 = Inverted operation + +- field-even-active: Active-high Field ID output polarity control of the bus. + Under normal operation, the field ID output is set to logic 1 for an odd field + (field 1) and set to logic 0 for an even field (field 0). + 0 = Normal Operation (Active Low, Default) + 1 = FID output polarity inverted + +For further reading of port node refer Documentation/devicetree/bindings/media/ +video-interfaces.txt. + +Example: + + i2c0@1c22000 { + ... + ... + tvp7002@5c { + compatible = "ti,tvp7002"; + reg = <0x5c>; + + port { + tvp7002_1: endpoint { + hsync-active = <1>; + vsync-active = <1>; + pclk-sample = <0>; + sync-on-green-active = <1>; + field-even-active = <0>; + }; + }; + }; + ... + }; diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index df37b0230c75..36bd2d6725c8 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -10,6 +10,7 @@ Required properties: - compatible : value should be either one among the following (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs + (b) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC - reg : Physical base address of the IP registers and length of memory 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 - field-even-active: field signal level during the even field data transmission. - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock signal. +- sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for + LOW/HIGH respectively. - data-lanes: an array of physical data lane indexes. Position of an entry determines the logical lane number, while the value of an entry indicates physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have 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: - reg: Should contain SSC registers location and length - interrupts: Should contain SSC interrupt -Example: + +Required properties for devices compatible with "atmel,at91sam9g45-ssc": +- dmas: DMA specifier, consisting of a phandle to DMA controller node, + the memory interface and SSC DMA channel ID (for tx and rx). + See Documentation/devicetree/bindings/dma/atmel-dma.txt for details. +- dma-names: Must be "tx", "rx". + +Examples: +- PDC transfer: ssc0: ssc@fffbc000 { compatible = "atmel,at91rm9200-ssc"; reg = <0xfffbc000 0x4000>; interrupts = <14 4 5>; }; + +- DMA transfer: +ssc0: ssc@f0010000 { + compatible = "atmel,at91sam9g45-ssc"; + reg = <0xf0010000 0x4000>; + interrupts = <28 4 5>; + dmas = <&dma0 1 13>, + <&dma0 1 14>; + dma-names = "tx", "rx"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>; + status = "disabled"; +}; 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 @@ +Micrel KSZ9021 Gigabit Ethernet PHY + +Some boards require special tuning values, particularly when it comes to +clock delays. You can specify clock delay values by adding +micrel-specific properties to an Ethernet OF device node. + +All skew control options are specified in picoseconds. The minimum +value is 0, and the maximum value is 3000. + +Optional properties: + - rxc-skew-ps : Skew control of RXC pad + - rxdv-skew-ps : Skew control of RX CTL pad + - txc-skew-ps : Skew control of TXC pad + - txen-skew-ps : Skew control of TX_CTL pad + - rxd0-skew-ps : Skew control of RX data 0 pad + - rxd1-skew-ps : Skew control of RX data 1 pad + - rxd2-skew-ps : Skew control of RX data 2 pad + - rxd3-skew-ps : Skew control of RX data 3 pad + - txd0-skew-ps : Skew control of TX data 0 pad + - txd1-skew-ps : Skew control of TX data 1 pad + - txd2-skew-ps : Skew control of TX data 2 pad + - txd3-skew-ps : Skew control of TX data 3 pad + +Examples: + + /* Attach to an Ethernet device with autodetected PHY */ + &enet { + rxc-skew-ps = <3000>; + rxdv-skew-ps = <0>; + txc-skew-ps = <3000>; + txen-skew-ps = <0>; + status = "okay"; + }; + + /* Attach to an explicitly-specified PHY */ + mdio { + phy0: ethernet-phy@0 { + rxc-skew-ps = <3000>; + rxdv-skew-ps = <0>; + txc-skew-ps = <3000>; + txen-skew-ps = <0>; + reg = <0>; + }; + }; + ethernet@70000 { + status = "okay"; + phy = <&phy0>; + phy-mode = "rgmii-id"; + }; 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 @@ +MOXA ART Ethernet Controller + +Required properties: + +- compatible : Must be "moxa,moxart-mac" +- reg : Should contain register location and length +- interrupts : Should contain the mac interrupt number + +Example: + + mac0: mac@90900000 { + compatible = "moxa,moxart-mac"; + reg = <0x90900000 0x100>; + interrupts = <25 0>; + }; + + mac1: mac@92000000 { + compatible = "moxa,moxart-mac"; + reg = <0x92000000 0x100>; + interrupts = <27 0>; + }; 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: - snps,pbl Programmable Burst Length - snps,fixed-burst Program the DMA to use the fixed burst mode - snps,mixed-burst Program the DMA to use the mixed burst mode +- snps,force_thresh_dma_mode Force DMA to use the threshold mode for + both tx and rx +- snps,force_sf_dma_mode Force DMA to use the Store and Forward + mode for both tx and rx. This flag is + ignored if force_thresh_dma_mode is set. Optional properties: - 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: - interrupt-map-mask and interrupt-map: standard PCI properties to define the mapping of the PCIe interface to interrupt numbers. +- num-lanes: number of lanes to use - reset-gpio: gpio pin number of power good signal Example: @@ -41,6 +42,7 @@ SoC specific DT Entry: #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0x0 0 &gic 53>; + num-lanes = <4>; }; pcie@2a0000 { @@ -60,6 +62,7 @@ SoC specific DT Entry: #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0x0 0 &gic 56>; + num-lanes = <4>; }; Board specific DT Entry: 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 nodes, is again defined entirely by the binding for the individual pin controller device. -== Using generic pinconfig options == +== Generic pin configuration node content == -Generic pinconfig parameters can be used by defining a separate node containing -the applicable parameters (and optional values), like: +Many data items that are represented in a pin configuration node are common +and generic. Pin control bindings should use the properties defined below +where they are applicable; not all of these properties are relevant or useful +for all hardware or binding structures. Each individual binding document +should state which of these generic properties, if any, are used, and the +structure of the DT nodes that contain these properties. -pcfg_pull_up: pcfg_pull_up { - bias-pull-up; - drive-strength = <20>; -}; - -This node should then be referenced in the appropriate pinctrl node as a phandle -and parsed in the driver using the pinconf_generic_parse_dt_config function. - -Supported configuration parameters are: +Supported generic properties are: +pins - the list of pins that properties in the node + apply to +function - the mux function to select bias-disable - disable any pin bias bias-high-impedance - high impedance mode ("third-state", "floating") bias-bus-hold - latch weakly @@ -160,7 +159,21 @@ low-power-disable - disable low power mode output-low - set the pin to output mode with low level output-high - set the pin to output mode with high level -Arguments for parameters: +Some of the generic properties take arguments. For those that do, the +arguments are described below. + +- pins takes a list of pin names or IDs as a required argument. The specific + binding for the hardware defines: + - Whether the entries are integers or strings, and their meaning. + +- function takes a list of function names/IDs as a required argument. The + specific binding for the hardware defines: + - Whether the entries are integers or strings, and their meaning. + - Whether only a single entry is allowed (which is applied to all entries + in the pins property), or whether there may alternatively be one entry per + entry in the pins property, in which case the list lengths must match, and + for each list index i, the function at list index i is applied to the pin + at list index i. - bias-pull-up, -down and -pin-default take as optional argument on hardware supporting it the pull strength in Ohm. bias-disable will disable the pull. @@ -170,7 +183,5 @@ Arguments for parameters: - input-debounce takes the debounce time in usec as argument or 0 to disable debouncing -All parameters not listed here, do not take an argument. - More in-depth documentation on these parameters can be found in <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 @@ +Palmas Pincontrol bindings + +The pins of Palmas device can be set on different option and provides +the configuration for Pull UP/DOWN, open drain etc. + +Required properties: +- compatible: It must be one of following: + - "ti,palmas-pinctrl" for Palma series of the pincontrol. + - "ti,tps65913-pinctrl" for Palma series device TPS65913. + - "ti,tps80036-pinctrl" for Palma series device TPS80036. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +Palmas's pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +list of pins. This configuration can include the mux function to select on +those pin(s), and various pin configuration parameters, such as pull-up, +open drain. + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + +Optional properties: +- ti,palmas-enable-dvfs1: Enable DVFS1. Configure pins for DVFS1 mode. + Selection primary or secondary function associated to I2C2_SCL_SCE, + I2C2_SDA_SDO pin/pad for DVFS1 interface +- ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode. + Selection primary or secondary function associated to GPADC_START + and SYSEN2 pin/pad for DVFS2 interface + +This binding uses the following generic properties as defined in +pinctrl-bindings.txt: + +Required: pins +Options: function, bias-disable, bias-pull-up, bias-pull-down, + bias-pin-default, drive-open-drain. + +Note that many of these properties are only valid for certain specific pins. +See the Palmas device datasheet for complete details regarding which pins +support which functionality. + +Valid values for pin names are: + gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7, gpio8, gpio9, + gpio10, gpio11, gpio12, gpio13, gpio14, gpio15, vac, powergood, + nreswarm, pwrdown, gpadc_start, reset_in, nsleep, enable1, enable2, + int. + +Valid value of function names are: + gpio, led, pwm, regen, sysen, clk32kgaudio, id, vbus_det, chrg_det, + vac, vacok, powergood, usb_psel, msecure, pwrhold, int, nreswarm, + simrsto, simrsti, low_vbat, wireless_chrg1, rcm, pwrdown, gpadc_start, + reset_in, nsleep, enable. + +There are 4 special functions: opt0, opt1, opt2 and opt3. If any of these +functions is selected then directly pins register will be written with 0, 1, 2 +or 3 respectively if it is valid for that pins or list of pins. + +Example: + palmas: tps65913 { + .... + pinctrl { + compatible = "ti,tps65913-pinctrl"; + ti,palmas-enable-dvfs1; + pinctrl-names = "default"; + pinctrl-0 = <&palmas_pins_state>; + + palmas_pins_state: pinmux { + gpio0 { + pins = "gpio0"; + function = "id"; + bias-pull-up; + }; + + vac { + pins = "vac"; + function = "vacok"; + bias-pull-down; + }; + + gpio5 { + pins = "gpio5"; + function = "opt0"; + drive-open-drain = <1>; + }; + }; + }; + .... + }; 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: - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller, - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller, - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller, + - "samsung,s5pv210-pinctrl": for S5PV210-compatible pin-controller, - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller. - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller. - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller. @@ -128,7 +129,7 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller found on Samsung S3C64xx SoCs, - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller - found on Samsung Exynos4210 SoC. + found on Samsung Exynos4210 and S5PC110/S5PV210 SoCs. - interrupt-parent: phandle of the interrupt parent to which the external wakeup interrupts are forwarded to. - interrupts: interrupt used by multiplexed wakeup interrupts. 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 Required properties: - compatible: should be "atmel,tcb-pwm" -- #pwm-cells: Should be 3. The first cell specifies the per-chip index - of the PWM to use, the second cell is the period in nanoseconds and - bit 0 in the third cell is used to encode the polarity of PWM output. - Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity & - set to 0 for normal polarity. +- #pwm-cells: should be 3. See pwm.txt in this directory for a description of + the cells format. The only third cell flag supported by this binding is + PWM_POLARITY_INVERTED. - tc-block: The Timer Counter block to use as a PWM chip. 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 Required properties: - compatible: should be "fsl,<soc>-pwm" - reg: physical base address and length of the controller's registers -- #pwm-cells: should be 2. The first cell specifies the per-chip index - of the PWM to use and the second cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. - interrupts: The interrupt for the pwm controller 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 Required properties: - compatible: should be "fsl,imx23-pwm" - reg: physical base address and length of the controller's registers -- #pwm-cells: should be 2. The first cell specifies the per-chip index - of the PWM to use and the second cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. - fsl,pwm-number: the number of PWM devices 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: - "nvidia,tegra20-pwm" - "nvidia,tegra30-pwm" - reg: physical base address and length of the controller's registers -- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The - first cell specifies the per-chip index of the PWM to use and the second - cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. Example: 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 Required properties: - compatible: "nxp,pca9685-pwm" - - #pwm-cells: should be 2. The first cell specifies the per-chip index - of the PWM to use and the second cell is the period in nanoseconds. + - #pwm-cells: Should be 2. See pwm.txt in this directory for a description of + the cells format. The index 16 is the ALLCALL channel, that sets all PWM channels at the same time. 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: - reg: base address and size of register area - interrupts: list of timer interrupts (one interrupt per timer, starting at timer 0) -- #pwm-cells: number of cells used for PWM specifier - must be 3 - the specifier format is as follows: - - phandle to PWM controller node - - index of PWM channel (from 0 to 4) - - PWM signal period in nanoseconds - - bitmask of optional PWM flags: - 0x1 - invert PWM signal +- #pwm-cells: should be 3. See pwm.txt in this directory for a description of + the cells format. The only third cell flag supported by this binding is + PWM_POLARITY_INVERTED. Optional properties: - 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: - compatible: Must be "ti,<soc>-ecap". for am33xx - compatible = "ti,am33xx-ecap"; for da850 - compatible = "ti,da850-ecap", "ti,am33xx-ecap"; -- #pwm-cells: Should be 3. Number of cells being used to specify PWM property. - First cell specifies the per-chip index of the PWM to use, the second - cell is the period in nanoseconds and bit 0 in the third cell is used to - encode the polarity of PWM output. Set bit 0 of the third in PWM specifier - to 1 for inverse polarity & set to 0 for normal polarity. +- #pwm-cells: should be 3. See pwm.txt in this directory for a description of + the cells format. The PWM channel index ranges from 0 to 4. The only third + cell flag supported by this binding is PWM_POLARITY_INVERTED. - reg: physical base address and size of the registers map. 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: - compatible: Must be "ti,<soc>-ehrpwm". for am33xx - compatible = "ti,am33xx-ehrpwm"; for da850 - compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm"; -- #pwm-cells: Should be 3. Number of cells being used to specify PWM property. - First cell specifies the per-chip index of the PWM to use, the second - cell is the period in nanoseconds and bit 0 in the third cell is used to - encode the polarity of PWM output. Set bit 0 of the third in PWM specifier - to 1 for inverse polarity & set to 0 for normal polarity. +- #pwm-cells: should be 3. See pwm.txt in this directory for a description of + the cells format. The only third cell flag supported by this binding is + PWM_POLARITY_INVERTED. - reg: physical base address and size of the registers map. 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. pwm-specifier typically encodes the chip-relative PWM number and the PWM period in nanoseconds. -Optionally, the pwm-specifier can encode a number of flags in a third cell: -- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity) +Optionally, the pwm-specifier can encode a number of flags (defined in +<dt-bindings/pwm/pwm.h>) in a third cell: +- PWM_POLARITY_INVERTED: invert the PWM signal polarity Example with optional PWM specifier for inverse polarity bl: backlight { - pwms = <&pwm 0 5000000 1>; + pwms = <&pwm 0 5000000 PWM_POLARITY_INVERTED>; pwm-names = "backlight"; }; 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 @@ +* Renesas R-Car Timer Pulse Unit PWM Controller + +Required Properties: + + - compatible: should be one of the following. + - "renesas,tpu-r8a73a4": for R8A77A4 (R-Mobile APE6) compatible PWM controller. + - "renesas,tpu-r8a7740": for R8A7740 (R-Mobile A1) compatible PWM controller. + - "renesas,tpu-r8a7790": for R8A7790 (R-Car H2) compatible PWM controller. + - "renesas,tpu-sh7372": for SH7372 (SH-Mobile AP4) compatible PWM controller. + - "renesas,tpu": for generic R-Car TPU PWM controller. + + - reg: Base address and length of each memory resource used by the PWM + controller hardware module. + + - #pwm-cells: should be 3. See pwm.txt in this directory for a description of + the cells format. The only third cell flag supported by this binding is + PWM_POLARITY_INVERTED. + +Please refer to pwm.txt in this directory for details of the common PWM bindings +used by client devices. + +Example: R8A7740 (R-Car A1) TPU controller node + + tpu: pwm@e6600000 { + compatible = "renesas,tpu-r8a7740", "renesas,tpu"; + reg = <0xe6600000 0x100>; + #pwm-cells = <3>; + }; 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: - "st,spear320-pwm" - "st,spear1340-pwm" - reg: physical base address and length of the controller's registers -- #pwm-cells: number of cells used to specify PWM which is fixed to 2 on - SPEAr. The first cell specifies the per-chip index of the PWM to use and - the second cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. Example: 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 Required properties: - compatible: "ti,twl4030-pwm" or "ti,twl6030-pwm" -- #pwm-cells: should be 2. The first cell specifies the per-chip index - of the PWM to use and the second cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. Example: 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) Required properties: - compatible: "ti,twl4030-pwmled" or "ti,twl6030-pwmled" -- #pwm-cells: should be 2. The first cell specifies the per-chip index - of the PWM to use and the second cell is the period in nanoseconds. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. Example: 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 Required properties: - compatible: should be "via,vt8500-pwm" - reg: physical base address and length of the controller's registers -- #pwm-cells: Should be 3. Number of cells being used to specify PWM property. - First cell specifies the per-chip index of the PWM to use, the second - cell is the period in nanoseconds and bit 0 in the third cell is used to - encode the polarity of PWM output. Set bit 0 of the third in PWM specifier - to 1 for inverse polarity & set to 0 for normal polarity. +- #pwm-cells: should be 3. See pwm.txt in this directory for a description of + the cells format. The only third cell flag supported by this binding is + PWM_POLARITY_INVERTED. - clocks: phandle to the PWM source clock 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 @@ +Marvell 88PM800 regulator + +Required properties: +- compatible: "marvell,88pm800" +- reg: I2C slave address +- regulators: A node that houses a sub-node for each regulator within the + device. Each sub-node is identified using the node's name (or the deprecated + regulator-compatible property if present), with valid values listed below. + The content of each sub-node is defined by the standard binding for + regulators; see regulator.txt. + +The valid names for regulators are: + + buck1, buck2, buck3, buck4, buck5, ldo1, ldo2, ldo3, ldo4, ldo5, ldo6, ldo7, + ldo8, ldo9, ldo10, ldo11, ldo12, ldo13, ldo14, ldo15, ldo16, ldo17, ldo18, ldo19 + +Example: + + pmic: 88pm800@31 { + compatible = "marvell,88pm800"; + reg = <0x31>; + + regulators { + buck1 { + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <3950000>; + regulator-boot-on; + regulator-always-on; + }; + ldo1 { + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <15000000>; + regulator-boot-on; + regulator-always-on; + }; +... + }; + }; 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 @@ +Maxim MAX8660 voltage regulator + +Required properties: +- compatible: must be one of "maxim,max8660", "maxim,max8661" +- reg: I2C slave address, usually 0x34 +- any required generic properties defined in regulator.txt + +Example: + + i2c_master { + max8660@34 { + compatible = "maxim,max8660"; + reg = <0x34>; + + regulators { + regulator@0 { + regulator-compatible= "V3(DCDC)"; + regulator-min-microvolt = <725000>; + regulator-max-microvolt = <1800000>; + }; + + regulator@1 { + regulator-compatible= "V4(DCDC)"; + regulator-min-microvolt = <725000>; + regulator-max-microvolt = <1800000>; + }; + + regulator@2 { + regulator-compatible= "V5(LDO)"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <2000000>; + }; + + regulator@3 { + regulator-compatible= "V6(LDO)"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + }; + + regulator@4 { + regulator-compatible= "V7(LDO)"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index d5a308629c57..a22e4c70db5c 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -25,15 +25,14 @@ Optional nodes: Additional custom properties are listed below. For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP, - smps45, smps457, smps7 depending on variant, smps6, smps[8-10], - ldo[1-9], ldoln, ldousb. + smps45, smps457, smps7 depending on variant, smps6, smps[8-9], + smps10_out2, smps10_out1, do[1-9], ldoln, ldousb. Optional sub-node properties: ti,warm-reset - maintain voltage during warm reset(boolean) ti,roof-floor - control voltage selection by pin(boolean) - ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto, + ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto, 2 - eco, 3 - forced pwm - ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us ti,smps-range - OTP has the wrong range set for the hardware so override 0 - low range, 1 - high range. @@ -59,7 +58,6 @@ pmic { ti,warm-reset; ti,roof-floor; ti,mode-sleep = <0>; - ti,tstep = <0>; ti,smps-range = <1>; }; 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 @@ +PFUZE100 family of regulators + +Required properties: +- compatible: "fsl,pfuze100" +- reg: I2C slave address + +Required child node: +- regulators: This is the list of child nodes that specify the regulator + initialization data for defined regulators. Please refer to below doc + Documentation/devicetree/bindings/regulator/regulator.txt. + + The valid names for regulators are: + sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6 + +Each regulator is defined using the standard binding for regulators. + +Example: + + pmic: pfuze100@08 { + compatible = "fsl,pfuze100"; + reg = <0x08>; + + regulators { + sw1a_reg: sw1ab { + regulator-min-microvolt = <300000>; + regulator-max-microvolt = <1875000>; + regulator-boot-on; + regulator-always-on; + regulator-ramp-delay = <6250>; + }; + + sw1c_reg: sw1c { + regulator-min-microvolt = <300000>; + regulator-max-microvolt = <1875000>; + regulator-boot-on; + regulator-always-on; + }; + + sw2_reg: sw2 { + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + + sw3a_reg: sw3a { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1975000>; + regulator-boot-on; + regulator-always-on; + }; + + sw3b_reg: sw3b { + regulator-min-microvolt = <400000>; + regulator-max-microvolt = <1975000>; + regulator-boot-on; + regulator-always-on; + }; + + sw4_reg: sw4 { + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3300000>; + }; + + swbst_reg: swbst { + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5150000>; + }; + + snvs_reg: vsnvs { + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3000000>; + regulator-boot-on; + regulator-always-on; + }; + + vref_reg: vrefddr { + regulator-boot-on; + regulator-always-on; + }; + + vgen1_reg: vgen1 { + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1550000>; + }; + + vgen2_reg: vgen2 { + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1550000>; + }; + + vgen3_reg: vgen3 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + }; + + vgen4_reg: vgen4 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + + vgen5_reg: vgen5 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + + vgen6_reg: vgen6 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + }; + }; 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: - regulator-allow-bypass: allow the regulator to go into bypass mode - <name>-supply: phandle to the parent supply/regulator node - regulator-ramp-delay: ramp delay for regulator(in uV/uS) + For hardwares which support disabling ramp rate, it should be explicitly + intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay. Deprecated properties: - 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: Optional properties: - atmel,use-dma-rx: use of PDC or DMA for receiving data - atmel,use-dma-tx: use of PDC or DMA for transmitting data +- add dma bindings for dma transfer: + - dmas: DMA specifier, consisting of a phandle to DMA controller node, + memory peripheral interface and USART DMA channel ID, FIFO configuration. + Refer to dma.txt and atmel-dma.txt for details. + - dma-names: "rx" for RX channel, "tx" for TX channel. <chip> compatible description: - at91rm9200: legacy USART support - at91sam9260: generic USART implementation for SAM9 SoCs Example: - +- use PDC: usart0: serial@fff8c000 { compatible = "atmel,at91sam9260-usart"; reg = <0xfff8c000 0x4000>; @@ -25,3 +30,14 @@ Example: atmel,use-dma-tx; }; +- use DMA: + usart0: serial@f001c000 { + compatible = "atmel,at91sam9260-usart"; + reg = <0xf001c000 0x100>; + interrupts = <12 4 5>; + atmel,use-dma-rx; + atmel,use-dma-tx; + dmas = <&dma0 2 0x3>, + <&dma0 2 0x204>; + dma-names = "tx", "rx"; + }; 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 @@ -* Freescale i.MX UART controller +* Freescale i.MX Universal Asynchronous Receiver/Transmitter (UART) Required properties: -- compatible : should be "fsl,imx21-uart" +- compatible : Should be "fsl,<soc>-uart" - reg : Address and length of the register set for the device -- interrupts : Should contain UART interrupt number +- interrupts : Should contain uart interrupt Optional properties: -- fsl,uart-has-rtscts: indicate that RTS/CTS signals are used +- fsl,uart-has-rtscts : Indicate the uart has rts and cts +- fsl,irda-mode : Indicate the uart supports irda mode +- fsl,dte-mode : Indicate the uart works in DTE mode. The uart works + is DCE mode by default. Note: Each uart controller should have an alias correctly numbered in "aliases" node. Example: -- From imx51.dtsi: aliases { serial0 = &uart1; - serial1 = &uart2; - serial2 = &uart3; }; uart1: serial@73fbc000 { compatible = "fsl,imx51-uart", "fsl,imx21-uart"; reg = <0x73fbc000 0x4000>; interrupts = <31>; - status = "disabled"; -} - -- From imx51-babbage.dts: -uart1: serial@73fbc000 { fsl,uart-has-rtscts; - status = "okay"; + fsl,dte-mode; }; - 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: Refer to dma.txt and fsl-mxs-dma.txt for details. - dma-names: "rx" for RX channel, "tx" for TX channel. +Optional properties: +- fsl,uart-has-rtscts : Indicate the UART has RTS and CTS lines, + it also means you enable the DMA support for this UART. + Example: auart0: serial@8006a000 { 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 @@ +Device tree bindings for Marvell PXA SSP ports + +Required properties: + + - compatible: Must be one of + mrvl,pxa25x-ssp + mvrl,pxa25x-nssp + mrvl,pxa27x-ssp + mrvl,pxa3xx-ssp + mvrl,pxa168-ssp + mrvl,pxa910-ssp + mrvl,ce4100-ssp + mrvl,lpss-ssp + + - reg: The memory base + - dmas: Two dma phandles, one for rx, one for tx + - dma-names: Must be "rx", "tx" + + +Example for PXA3xx: + + ssp0: ssp@41000000 { + compatible = "mrvl,pxa3xx-ssp"; + reg = <0x41000000 0x40>; + ssp-id = <1>; + interrupts = <24>; + clock-names = "pxa27x-ssp.0"; + dmas = <&dma 13 + &dma 14>; + dma-names = "rx", "tx"; + }; + + ssp1: ssp@41700000 { + compatible = "mrvl,pxa3xx-ssp"; + reg = <0x41700000 0x40>; + ssp-id = <2>; + interrupts = <16>; + clock-names = "pxa27x-ssp.1"; + dmas = <&dma 15 + &dma 16>; + dma-names = "rx", "tx"; + }; + + ssp2: ssp@41900000 { + compatibl3 = "mrvl,pxa3xx-ssp"; + reg = <0x41900000 0x40>; + ssp-id = <3>; + interrupts = <0>; + clock-names = "pxa27x-ssp.2"; + dmas = <&dma 66 + &dma 67>; + dma-names = "rx", "tx"; + }; + + ssp3: ssp@41a00000 { + compatible = "mrvl,pxa3xx-ssp"; + reg = <0x41a00000 0x40>; + ssp-id = <4>; + interrupts = <13>; + clock-names = "pxa27x-ssp.3"; + dmas = <&dma 2 + &dma 3>; + dma-names = "rx", "tx"; + }; + 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 @@ +* MSM Serial UART + +The MSM serial UART hardware is designed for low-speed use cases where a +dma-engine isn't needed. From a software perspective it's mostly compatible +with the MSM serial UARTDM except that it only supports reading and writing one +character at a time. + +Required properties: +- compatible: Should contain "qcom,msm-uart" +- reg: Should contain UART register location and length. +- interrupts: Should contain UART interrupt. +- clocks: Should contain the core clock. +- clock-names: Should be "core". + +Example: + +A uart device at 0xa9c00000 with interrupt 11. + +serial@a9c00000 { + compatible = "qcom,msm-uart"; + reg = <0xa9c00000 0x1000>; + interrupts = <11>; + clocks = <&uart_cxc>; + clock-names = "core"; +}; 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 @@ +* MSM Serial UARTDM + +The MSM serial UARTDM hardware is designed for high-speed use cases where the +transmit and/or receive channels can be offloaded to a dma-engine. From a +software perspective it's mostly compatible with the MSM serial UART except +that it supports reading and writing multiple characters at a time. + +Required properties: +- compatible: Should contain at least "qcom,msm-uartdm". + A more specific property should be specified as follows depending + on the version: + "qcom,msm-uartdm-v1.1" + "qcom,msm-uartdm-v1.2" + "qcom,msm-uartdm-v1.3" + "qcom,msm-uartdm-v1.4" +- reg: Should contain UART register locations and lengths. The first + register shall specify the main control registers. An optional second + register location shall specify the GSBI control region. + "qcom,msm-uartdm-v1.3" is the only compatible value that might + need the GSBI control region. +- interrupts: Should contain UART interrupt. +- clocks: Should contain the core clock and the AHB clock. +- clock-names: Should be "core" for the core clock and "iface" for the + AHB clock. + +Optional properties: +- dmas: Should contain dma specifiers for transmit and receive channels +- dma-names: Should contain "tx" for transmit and "rx" for receive channels + +Examples: + +A uartdm v1.4 device with dma capabilities. + +serial@f991e000 { + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm"; + reg = <0xf991e000 0x1000>; + interrupts = <0 108 0x0>; + clocks = <&blsp1_uart2_apps_cxc>, <&blsp1_ahb_cxc>; + clock-names = "core", "iface"; + dmas = <&dma0 0>, <&dma0 1>; + dma-names = "tx", "rx"; +}; + +A uartdm v1.3 device without dma capabilities and part of a GSBI complex. + +serial@19c40000 { + compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; + reg = <0x19c40000 0x1000>, + <0x19c00000 0x1000>; + interrupts = <0 195 0x0>; + clocks = <&gsbi5_uart_cxc>, <&gsbi5_ahb_cxc>; + clock-names = "core", "iface"; +}; 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 @@ +* CSR SiRFprimaII/atlasVI Universal Synchronous Asynchronous Receiver/Transmitter * + +Required properties: +- compatible : Should be "sirf,prima2-uart" or "sirf, prima2-usp-uart" +- reg : Offset and length of the register set for the device +- interrupts : Should contain uart interrupt +- fifosize : Should define hardware rx/tx fifo size +- clocks : Should contain uart clock number + +Optional properties: +- sirf,uart-has-rtscts: we have hardware flow controller pins in hardware +- rts-gpios: RTS pin for USP-based UART if sirf,uart-has-rtscts is true +- cts-gpios: CTS pin for USP-based UART if sirf,uart-has-rtscts is true + +Example: + +uart0: uart@b0050000 { + cell-index = <0>; + compatible = "sirf,prima2-uart"; + reg = <0xb0050000 0x1000>; + interrupts = <17>; + fifosize = <128>; + clocks = <&clks 13>; +}; + +On the board-specific dts, we can put rts-gpios and cts-gpios like + +usp@b0090000 { + compatible = "sirf,prima2-usp-uart"; + sirf,uart-has-rtscts; + rts-gpios = <&gpio 15 0>; + cts-gpios = <&gpio 46 0>; +}; 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 @@ +*st-asc(Serial Port) + +Required properties: +- compatible : Should be "st,asc". +- reg, reg-names, interrupts, interrupt-names : Standard way to define device + resources with names. look in + Documentation/devicetree/bindings/resource-names.txt + +Optional properties: +- st,hw-flow-ctrl bool flag to enable hardware flow control. +- st,force-m1 bool flat to force asc to be in Mode-1 recommeded + for high bit rates (above 19.2K) +Example: +serial@fe440000{ + compatible = "st,asc"; + reg = <0xfe440000 0x2c>; + interrupts = <0 209 0>; +}; 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 @@ +AK4554 ADC/DAC + +Required properties: + + - compatible : "asahi-kasei,ak4554" + +Example: + +ak4554-adc-dac { + compatible = "asahi-kasei,ak4554"; +}; 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: - #gpio-cells : Should be two. The first cell is the pin number and the second cell is used to specify optional parameters (currently unused). +Pins on the device (for linking into audio routes): + + * SPK_OUTP + * SPK_OUTN + * HP_OUT_L + * HP_OUT_R + * AUX_OUT_P + * AUX_OUT_N + * LINE_IN_L + * LINE_IN_R + * PHONE_P + * PHONE_N + * MIC1_P + * MIC1_N + * MIC2_P + * MIC2_N + * MICBIAS1 + * DMICDAT + Example: 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 @@ +* Atmel at91sam9x5ek wm8731 audio complex + +Required properties: + - compatible: "atmel,sam9x5-wm8731-audio" + - atmel,model: The user-visible name of this sound complex. + - atmel,ssc-controller: The phandle of the SSC controller + - atmel,audio-codec: The phandle of the WM8731 audio codec + - atmel,audio-routing: A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. + +Available audio endpoints for the audio-routing table: + +Board connectors: + * Headphone Jack + * Line In Jack + +wm8731 pins: +cf Documentation/devicetree/bindings/sound/wm8731.txt + +Example: +sound { + compatible = "atmel,sam9x5-wm8731-audio"; + + atmel,model = "wm8731 @ AT91SAM9X5EK"; + + atmel,audio-routing = + "Headphone Jack", "RHPOUT", + "Headphone Jack", "LHPOUT", + "LLINEIN", "Line In Jack", + "RLINEIN", "Line In Jack"; + + atmel,ssc-controller = <&ssc0>; + atmel,audio-codec = <&wm8731>; +}; 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 @@ +Atmel ASoC driver with wm8904 audio codec complex + +Required properties: + - compatible: "atmel,asoc-wm8904" + - atmel,model: The user-visible name of this sound complex. + - atmel,audio-routing: A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the WM8904's pins, and the jacks on the board: + + WM8904 pins: + + * IN1L + * IN1R + * IN2L + * IN2R + * IN3L + * IN3R + * HPOUTL + * HPOUTR + * LINEOUTL + * LINEOUTR + * MICBIAS + + Board connectors: + + * Headphone Jack + * Line In Jack + * Mic + + - atmel,ssc-controller: The phandle of the SSC controller + - atmel,audio-codec: The phandle of the WM8904 audio codec + +Optional properties: + - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt + +Example: +sound { + compatible = "atmel,asoc-wm8904"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pck0_as_mck>; + + atmel,model = "wm8904 @ AT91SAM9N12EK"; + + atmel,audio-routing = + "Headphone Jack", "HPOUTL", + "Headphone Jack", "HPOUTR", + "IN2L", "Line In Jack", + "IN2R", "Line In Jack", + "Mic", "MICBIAS", + "IN1L", "Mic"; + + atmel,ssc-controller = <&ssc0>; + atmel,audio-codec = <&wm8904>; +}; 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 @@ +Freescale Sony/Philips Digital Interface Format (S/PDIF) Controller + +The Freescale S/PDIF audio block is a stereo transceiver that allows the +processor to receive and transmit digital audio via an coaxial cable or +a fibre cable. + +Required properties: + + - compatible : Compatible list, must contain "fsl,imx35-spdif". + + - reg : Offset and length of the register set for the device. + + - interrupts : Contains the spdif interrupt. + + - dmas : Generic dma devicetree binding as described in + Documentation/devicetree/bindings/dma/dma.txt. + + - dma-names : Two dmas have to be defined, "tx" and "rx". + + - clocks : Contains an entry for each entry in clock-names. + + - clock-names : Includes the following entries: + "core" The core clock of spdif controller + "rxtx<0-7>" Clock source list for tx and rx clock. + This clock list should be identical to + the source list connecting to the spdif + clock mux in "SPDIF Transceiver Clock + Diagram" of SoC reference manual. It + can also be referred to TxClk_Source + bit of register SPDIF_STC. + +Example: + +spdif: spdif@02004000 { + compatible = "fsl,imx35-spdif"; + reg = <0x02004000 0x4000>; + interrupts = <0 52 0x04>; + dmas = <&sdma 14 18 0>, + <&sdma 15 18 0>; + dma-names = "rx", "tx"; + + clocks = <&clks 197>, <&clks 3>, + <&clks 197>, <&clks 107>, + <&clks 0>, <&clks 118>, + <&clks 62>, <&clks 139>, + <&clks 0>; + clock-names = "core", "rxtx0", + "rxtx1", "rxtx2", + "rxtx3", "rxtx4", + "rxtx5", "rxtx6", + "rxtx7"; + + status = "okay"; +}; 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: together. This would still allow different sample sizes, but not different sample rates. +Required are also ac97 link bindings if ac97 is used. See +Documentation/devicetree/bindings/sound/soc-ac97link.txt for the necessary +bindings. + Optional properties: - codec-handle: Phandle to a 'codec' node that defines an audio codec connected to this SSI. This node is typically a child of an I2C or other control node. +- fsl,fiq-stream-filter: Bool property. Disabled DMA and use FIQ instead to + filter the codec stream. This is necessary for some boards + where an incompatible codec is connected to this SSI, e.g. + on pca100 and pcm043. +- dmas: Generic dma devicetree binding as described in + Documentation/devicetree/bindings/dma/dma.txt. +- dma-names: Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq + is not defined. Child 'codec' node required properties: - 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 @@ +Freescale i.MX audio complex with S/PDIF transceiver + +Required properties: + + - compatible : "fsl,imx-audio-spdif" + + - model : The user-visible name of this sound complex + + - spdif-controller : The phandle of the i.MX S/PDIF controller + + +Optional properties: + + - spdif-out : This is a boolean property. If present, the transmitting + function of S/PDIF will be enabled, indicating there's a physical + S/PDIF out connector/jack on the board or it's connecting to some + other IP block, such as an HDMI encoder/display-controller. + + - spdif-in : This is a boolean property. If present, the receiving + function of S/PDIF will be enabled, indicating there's a physical + S/PDIF in connector/jack on the board. + +* Note: At least one of these two properties should be set in the DT binding. + + +Example: + +sound-spdif { + compatible = "fsl,imx-audio-spdif"; + model = "imx-spdif"; + spdif-controller = <&spdif>; + spdif-out; + spdif-in; +}; 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: or "fsl,imx31-audmux" for the version firstly used on i.MX31. - reg : Should contain AUDMUX registers location and length +An initial configuration can be setup using child nodes. + +Required properties of optional child nodes: +- fsl,audmux-port : Integer of the audmux port that is configured by this + child node. +- fsl,port-config : List of configuration options for the specific port. For + imx31-audmux and above, it is a list of tuples <ptcr pdcr>. For + imx21-audmux it is a list of pcr values. + Example: 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 @@ +Marvell PXA SSP CPU DAI bindings + +Required properties: + + compatible Must be "mrvl,pxa-ssp-dai" + port A phandle reference to a PXA ssp upstream device + +Example: + + /* upstream device */ + + ssp0: ssp@41000000 { + compatible = "mrvl,pxa3xx-ssp"; + reg = <0x41000000 0x40>; + interrupts = <24>; + clock-names = "pxa27x-ssp.0"; + dmas = <&dma 13 + &dma 14>; + dma-names = "rx", "tx"; + }; + + /* DAI as user */ + + ssp_dai0: ssp_dai@0 { + compatible = "mrvl,pxa-ssp-dai"; + port = <&ssp0>; + }; + 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 @@ +DT bindings for ARM PXA2xx PCM platform driver + +This is just a dummy driver that registers the PXA ASoC platform driver. +It does not have any resources assigned. + +Required properties: + + - compatible 'mrvl,pxa-pcm-audio' + +Example: + + pxa_pcm_audio: snd_soc_pxa_audio { + compatible = "mrvl,pxa-pcm-audio"; + }; + 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 @@ +* mvebu (Kirkwood, Dove, Armada 370) audio controller + +Required properties: + +- compatible: "marvell,mvebu-audio" + +- reg: physical base address of the controller and length of memory mapped + region. + +- interrupts: list of two irq numbers. + The first irq is used for data flow and the second one is used for errors. + +- clocks: one or two phandles. + The first one is mandatory and defines the internal clock. + The second one is optional and defines an external clock. + +- clock-names: names associated to the clocks: + "internal" for the internal clock + "extclk" for the external clock + +Example: + +i2s1: audio-controller@b4000 { + compatible = "marvell,mvebu-audio"; + reg = <0xb4000 0x2210>; + interrupts = <21>, <22>; + clocks = <&gate_clk 13>; + clock-names = "internal"; +}; 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: - nvidia,audio-routing : A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. Valid names for sources and - sinks are the ALC5632's pins: - - ALC5632 pins: - - * SPK_OUTP - * SPK_OUTN - * HP_OUT_L - * HP_OUT_R - * AUX_OUT_P - * AUX_OUT_N - * LINE_IN_L - * LINE_IN_R - * PHONE_P - * PHONE_N - * MIC1_P - * MIC1_N - * MIC2_P - * MIC2_N - * MICBIAS1 - * DMICDAT - - Board connectors: + sinks are the ALC5632's pins as documented in the binding for the device + and: * Headset Stereophone * 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: - nvidia,audio-routing : A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. Valid names for sources and - sinks are the RT5640's pins, and the jacks on the board: - - RT5640 pins: - - * DMIC1 - * DMIC2 - * MICBIAS1 - * IN1P - * IN1R - * IN2P - * IN2R - * HPOL - * HPOR - * LOUTL - * LOUTR - * MONOP - * MONON - * SPOLP - * SPOLN - * SPORP - * SPORN - - Board connectors: + sinks are the RT5640's pins (as documented in its binding), and the jacks + on the board: * Headphones * Speakers + * Mic Jack - nvidia,i2s-controller : The phandle of the Tegra I2S controller that's 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: - nvidia,audio-routing : A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. Valid names for sources and - sinks are the WM8753's pins, and the jacks on the board: - - WM8753 pins: - - * LOUT1 - * LOUT2 - * ROUT1 - * ROUT2 - * MONO1 - * MONO2 - * OUT3 - * OUT4 - * LINE1 - * LINE2 - * RXP - * RXN - * ACIN - * ACOP - * MIC1N - * MIC1 - * MIC2N - * MIC2 - * Mic Bias - - Board connectors: + sinks are the WM8753's pins as documented in the binding for the WM8753, + and the jacks on the board: * Headphone Jack * 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: - nvidia,audio-routing : A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. Valid names for sources and - sinks are the WM8903's pins, and the jacks on the board: - - WM8903 pins: - - * IN1L - * IN1R - * IN2L - * IN2R - * IN3L - * IN3R - * DMICDAT - * HPOUTL - * HPOUTR - * LINEOUTL - * LINEOUTR - * LOP - * LON - * ROP - * RON - * MICBIAS - - Board connectors: + sinks are the WM8903's pins (documented in the WM8903 binding document), + and the jacks on the board: * Headphone Jack * 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 @@ +Texas Instruments pcm1792a DT bindings + +This driver supports the SPI bus. + +Required properties: + + - compatible: "ti,pcm1792a" + +For required properties on SPI, please consult +Documentation/devicetree/bindings/spi/spi-bus.txt + +Examples: + + codec_spi: 1792a@0 { + compatible = "ti,pcm1792a"; + spi-max-frequency = <600000>; + }; + 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: - realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin. +Pins on the device (for linking into audio routes): + + * DMIC1 + * DMIC2 + * MICBIAS1 + * IN1P + * IN1R + * IN2P + * IN2R + * HPOL + * HPOR + * LOUTL + * LOUTR + * MONOP + * MONON + * SPOLP + * SPOLN + * SPORP + * SPORN + Example: 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 @@ Required SoC Specific Properties: -- compatible : "samsung,i2s-v5" +- compatible : should be one of the following. + - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. + - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with + secondary fifo, s/w reset control and internal mux for root clk src. + - samsung,exynos5420-i2s: for 8/16/24bit multichannel(7.1) I2S with + secondary fifo, s/w reset control, internal mux for root clk src and + TDM support. TDM (Time division multiplexing) is to allow transfer of + multiple channel audio data on single data line. + - reg: physical base address of the controller and length of memory mapped region. - dmas: list of DMA controller phandle and DMA request line ordered pairs. @@ -21,13 +29,6 @@ Required SoC Specific Properties: Optional SoC Specific Properties: -- samsung,supports-6ch: If the I2S Primary sound source has 5.1 Channel - support, this flag is enabled. -- samsung,supports-rstclr: This flag should be set if I2S software reset bit - control is required. When this flag is set I2S software reset bit will be - enabled or disabled based on need. -- samsung,supports-secdai:If I2S block has a secondary FIFO and internal DMA, - then this flag is enabled. - samsung,idma-addr: Internal DMA register base address of the audio sub system(used in secondary sound source). - pinctrl-0: Should specify pin control groups used for this controller. @@ -36,7 +37,7 @@ Optional SoC Specific Properties: Example: i2s0: i2s@03830000 { - compatible = "samsung,i2s-v5"; + compatible = "samsung,s5pv210-i2s"; reg = <0x03830000 0x100>; dmas = <&pdma0 10 &pdma0 9 @@ -46,9 +47,6 @@ i2s0: i2s@03830000 { <&clock_audss EXYNOS_I2S_BUS>, <&clock_audss EXYNOS_SCLK_I2S>; clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; - samsung,supports-6ch; - samsung,supports-rstclr; - samsung,supports-secdai; samsung,idma-addr = <0x03000000>; pinctrl-names = "default"; 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 @@ +AC97 link bindings + +These bindings can be included within any other device node. + +Required properties: + - pinctrl-names: Has to contain following states to setup the correct + pinmuxing for the used gpios: + "ac97-running": AC97-link is active + "ac97-reset": AC97-link reset state + "ac97-warm-reset": AC97-link warm reset state + - ac97-gpios: List of gpio phandles with args in the order ac97-sync, + ac97-sdata, ac97-reset + + +Example: + +ssi { + ... + + pinctrl-names = "default", "ac97-running", "ac97-reset", "ac97-warm-reset"; + pinctrl-0 = <&ac97link_running>; + pinctrl-1 = <&ac97link_running>; + pinctrl-2 = <&ac97link_reset>; + pinctrl-3 = <&ac97link_warm_reset>; + ac97-gpios = <&gpio3 20 0 &gpio3 22 0 &gpio3 28 0>; + + ... +}; 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 @@ +Texas Instruments PCM1681 8-channel PWM Processor + +Required properties: + + - compatible: Should contain "ti,pcm1681". + - reg: The i2c address. Should contain <0x4c>. + +Examples: + + i2c_bus { + pcm1681@4c { + compatible = "ti,pcm1681"; + reg = <0x4c>; + }; + }; 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 The tlv320aic3x serial control bus communicates through I2C protocols Required properties: -- compatible - "string" - "ti,tlv320aic3x" + +- compatible - "string" - One of: + "ti,tlv320aic3x" - Generic TLV320AIC3x device + "ti,tlv320aic33" - TLV320AIC33 + "ti,tlv320aic3007" - TLV320AIC3007 + "ti,tlv320aic3106" - TLV320AIC3106 + + - reg - <int> - I2C slave address 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 { compatible = "wlf,wm8731"; reg = <0x1a>; }; + +Available audio endpoints for an audio-routing table: + * LOUT: Left Channel Line Output + * ROUT: Right Channel Line Output + * LHPOUT: Left Channel Headphone Output + * RHPOUT: Right Channel Headphone Output + * LLINEIN: Left Channel Line Input + * RLINEIN: Right Channel Line Input + * 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: - reg : the I2C address of the device for I2C, the chip select number for SPI. +Pins on the device (for linking into audio routes): + + * LOUT1 + * LOUT2 + * ROUT1 + * ROUT2 + * MONO1 + * MONO2 + * OUT3 + * OUT4 + * LINE1 + * LINE2 + * RXP + * RXN + * ACIN + * ACOP + * MIC1N + * MIC1 + * MIC2N + * MIC2 + * Mic Bias + Example: -codec: wm8737@1a { +codec: wm8753@1a { compatible = "wlf,wm8753"; reg = <0x1a>; }; 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: performed. If any entry has the value 0xffffffff, that GPIO's configuration will not be modified. +Pins on the device (for linking into audio routes): + + * IN1L + * IN1R + * IN2L + * IN2R + * IN3L + * IN3R + * DMICDAT + * HPOUTL + * HPOUTR + * LINEOUTL + * LINEOUTR + * LOP + * LON + * ROP + * RON + * MICBIAS + Example: 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: The second cell is the flags, encoded as the trigger masks from Documentation/devicetree/bindings/interrupts.txt + - clocks : A list of up to two phandle and clock specifier pairs + - clock-names : A list of clock names sorted in the same order as clocks. + Valid clock names are "MCLK1" and "MCLK2". + - wlf,gpio-cfg : A list of GPIO configuration register values. If absent, no configuration of these registers is performed. If any value is 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 @@ +* Energy Micro EFM32 SPI + +Required properties: +- #address-cells: see spi-bus.txt +- #size-cells: see spi-bus.txt +- compatible: should be "efm32,spi" +- reg: Offset and length of the register set for the controller +- interrupts: pair specifying rx and tx irq +- clocks: phandle to the spi clock +- cs-gpios: see spi-bus.txt +- location: Value to write to the ROUTE register's LOCATION bitfield to configure the pinmux for the device, see datasheet for values. + +Example: + +spi1: spi@0x4000c400 { /* USART1 */ + #address-cells = <1>; + #size-cells = <0>; + compatible = "efm32,spi"; + reg = <0x4000c400 0x400>; + interrupts = <15 16>; + clocks = <&cmu 20>; + cs-gpios = <&gpio 51 1>; // D3 + location = <1>; + status = "ok"; + + ks8851@0 { + compatible = "ks8851"; + spi-max-frequency = <6000000>; + reg = <0>; + interrupt-parent = <&boardfpga>; + interrupts = <4>; + status = "ok"; + }; +}; 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. chip select active high - spi-3wire - (optional) Empty property indicating device requires 3-wire mode. +- spi-tx-bus-width - (optional) The bus width(number of data wires) that + used for MOSI. Defaults to 1 if not present. +- spi-rx-bus-width - (optional) The bus width(number of data wires) that + used for MISO. Defaults to 1 if not present. + +Some SPI controllers and devices support Dual and Quad SPI transfer mode. +It allows data in SPI system transfered in 2 wires(DUAL) or 4 wires(QUAD). +Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is +only 1(SINGLE), 2(DUAL) and 4(QUAD). +Dual/Quad mode is not allowed when 3-wire mode is used. If a gpio chipselect is used for the SPI slave the gpio number will be passed 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 @@ +ARM Freescale DSPI controller + +Required properties: +- compatible : "fsl,vf610-dspi" +- reg : Offset and length of the register set for the device +- interrupts : Should contain SPI controller interrupt +- clocks: from common clock binding: handle to dspi clock. +- clock-names: from common clock binding: Shall be "dspi". +- pinctrl-0: pin control group to be used for this controller. +- pinctrl-names: must contain a "default" entry. +- spi-num-chipselects : the number of the chipselect signals. +- bus-num : the slave chip chipselect signal number. +Example: + +dspi0@4002c000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,vf610-dspi"; + reg = <0x4002c000 0x1000>; + interrupts = <0 67 0x04>; + clocks = <&clks VF610_CLK_DSPI0>; + clock-names = "dspi"; + spi-num-chipselects = <5>; + bus-num = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_dspi0_1>; + status = "okay"; + + sflash: at26df081a@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "atmel,at26df081a"; + spi-max-frequency = <16000000>; + spi-cpol; + spi-cpha; + reg = <0>; + linux,modalias = "m25p80"; + modal = "at26df081a"; + }; +}; + + 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 @@ +TI QSPI controller. + +Required properties: +- compatible : should be "ti,dra7xxx-qspi" or "ti,am4372-qspi". +- reg: Should contain QSPI registers location and length. +- #address-cells, #size-cells : Must be present if the device has sub-nodes +- ti,hwmods: Name of the hwmod associated to the QSPI + +Recommended properties: +- spi-max-frequency: Definition as per + Documentation/devicetree/bindings/spi/spi-bus.txt + +Example: + +qspi: qspi@4b300000 { + compatible = "ti,dra7xxx-qspi"; + reg = <0x4b300000 0x100>; + #address-cells = <1>; + #size-cells = <0>; + spi-max-frequency = <25000000>; + ti,hwmods = "qspi"; +}; 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 @@ +MOXA ART timer + +Required properties: + +- compatible : Must be "moxa,moxart-timer" +- reg : Should contain registers location and length +- interrupts : Should contain the timer interrupt number +- clocks : Should contain phandle for the clock that drives the counter + +Example: + + timer: timer@98400000 { + compatible = "moxa,moxart-timer"; + reg = <0x98400000 0x42>; + interrupts = <19 1>; + clocks = <&coreclk>; + }; 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 @@ -* Freescale i.MX Universal Asynchronous Receiver/Transmitter (UART) - -Required properties: -- compatible : Should be "fsl,<soc>-uart" -- reg : Address and length of the register set for the device -- interrupts : Should contain uart interrupt - -Optional properties: -- fsl,uart-has-rtscts : Indicate the uart has rts and cts -- fsl,irda-mode : Indicate the uart supports irda mode -- fsl,dte-mode : Indicate the uart works in DTE mode. The uart works - is DCE mode by default. - -Example: - -serial@73fbc000 { - compatible = "fsl,imx51-uart", "fsl,imx21-uart"; - reg = <0x73fbc000 0x4000>; - interrupts = <31>; - fsl,uart-has-rtscts; - fsl,dte-mode; -}; 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 @@ -* Qualcomm MSM UART - -Required properties: -- compatible : - - "qcom,msm-uart", and one of "qcom,msm-hsuart" or - "qcom,msm-lsuart". -- reg : offset and length of the register set for the device - for the hsuart operating in compatible mode, there should be a - second pair describing the gsbi registers. -- interrupts : should contain the uart interrupt. - -There are two different UART blocks used in MSM devices, -"qcom,msm-hsuart" and "qcom,msm-lsuart". The msm-serial driver is -able to handle both of these, and matches against the "qcom,msm-uart" -as the compatibility. - -The registers for the "qcom,msm-hsuart" device need to specify both -register blocks, even for the common driver. - -Example: - - uart@19c400000 { - compatible = "qcom,msm-hsuart", "qcom,msm-uart"; - reg = <0x19c40000 0x1000>, - <0x19c00000 0x1000>; - interrupts = <195>; - }; 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 @@ +* Qualcomm Atheros AR9330 High-Speed UART + +Required properties: + +- compatible: Must be "qca,ar9330-uart" + +- reg: Specifies the physical base address of the controller and + the length of the memory mapped region. + +- interrupt-parent: The phandle for the interrupt controller that + services interrupts for this device. + +- interrupts: Specifies the interrupt source of the parent interrupt + controller. The format of the interrupt specifier depends on the + parent interrupt controller. + +Additional requirements: + + Each UART port must have an alias correctly numbered in "aliases" + node. + +Example: + + aliases { + serial0 = &uart0; + }; + + uart0: uart@18020000 { + compatible = "qca,ar9330-uart"; + reg = <0x18020000 0x14>; + + interrupt-parent = <&intc>; + interrupts = <3>; + }; 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 @@ -AM33XX MUSB GLUE - - compatible : Should be "ti,musb-am33xx" - - reg : offset and length of register sets, first usbss, then for musb instances - - interrupts : usbss, musb instance interrupts in order - - ti,hwmods : must be "usb_otg_hs" - - multipoint : Should be "1" indicating the musb controller supports - multipoint. This is a MUSB configuration-specific setting. - - num-eps : Specifies the number of endpoints. This is also a - MUSB configuration-specific setting. Should be set to "16" - - ram-bits : Specifies the ram address size. Should be set to "12" - - port0-mode : Should be "3" to represent OTG. "1" signifies HOST and "2" - represents PERIPHERAL. - - port1-mode : Should be "1" to represent HOST. "3" signifies OTG and "2" - represents PERIPHERAL. - - power : Should be "250". This signifies the controller can supply up to - 500mA when operating in host mode. + AM33xx MUSB +~~~~~~~~~~~~~~~ +- compatible: ti,am33xx-usb +- reg: offset and length of the usbss register sets +- ti,hwmods : must be "usb_otg_hs" + +The glue layer contains multiple child nodes. It is required the have +at least a control module node, USB node and a PHY node. The second USB +node and its PHY node is optional. The DMA node is also optional. + +Reset module +~~~~~~~~~~~~ +- compatible: ti,am335x-usb-ctrl-module +- reg: offset and length of the "USB control registers" in the "Control + Module" block. A second offset and length for the USB wake up control + in the same memory block. +- reg-names: "phy_ctrl" for the "USB control registers" and "wakeup" for + the USB wake up control register. + +USB PHY +~~~~~~~ +compatible: ti,am335x-usb-phy +reg: offset and length of the "USB PHY" register space +ti,ctrl_mod: reference to the "reset module" node +reg-names: phy +The PHY should have a "phy" alias numbered properly in the alias +node. + +USB +~~~ +- compatible: ti,musb-am33xx +- reg: offset and length of "USB Controller Registers", and offset and + length of "USB Core" register space. +- reg-names: control for the ""USB Controller Registers" and "mc" for + "USB Core" register space +- interrupts: USB interrupt number +- interrupt-names: mc +- dr_mode: Should be one of "host", "peripheral" or "otg". +- mentor,multipoint: Should be "1" indicating the musb controller supports + multipoint. This is a MUSB configuration-specific setting. +- mentor,num-eps: Specifies the number of endpoints. This is also a + MUSB configuration-specific setting. Should be set to "16" +- mentor,ram-bits: Specifies the ram address size. Should be set to "12" +- mentor,power: Should be "500". This signifies the controller can supply up to + 500mA when operating in host mode. +- phys: reference to the USB phy +- dmas: specifies the dma channels +- dma-names: specifies the names of the channels. Use "rxN" for receive + and "txN" for transmit endpoints. N specifies the endpoint number. + +The controller should have an "usb" alias numbered properly in the alias +node. + +DMA +~~~ +- compatible: ti,am3359-cppi41 +- reg: offset and length of the following register spaces: USBSS, USB + CPPI DMA Controller, USB CPPI DMA Scheduler, USB Queue Manager +- reg-names: glue, controller, scheduler, queuemgr +- #dma-cells: should be set to 2. The first number represents the + endpoint number (0 … 14 for endpoints 1 … 15 on instance 0 and 15 … 29 + for endpoints 1 … 15 on instance 1). The second number is 0 for RX and + 1 for TX transfers. +- #dma-channels: should be set to 30 representing the 15 endpoints for + each USB instance. Example: +~~~~~~~~ +The following example contains all the nodes as used on am335x-evm: + +aliases { + usb0 = &usb0; + usb1 = &usb1; + phy0 = &usb0_phy; + phy1 = &usb1_phy; +}; -usb@47400000 { - compatible = "ti,musb-am33xx"; - reg = <0x47400000 0x1000 /* usbss */ - 0x47401000 0x800 /* musb instance 0 */ - 0x47401800 0x800>; /* musb instance 1 */ - interrupts = <17 /* usbss */ - 18 /* musb instance 0 */ - 19>; /* musb instance 1 */ - multipoint = <1>; - num-eps = <16>; - ram-bits = <12>; - port0-mode = <3>; - port1-mode = <3>; - power = <250>; +usb: usb@47400000 { + compatible = "ti,am33xx-usb"; + reg = <0x47400000 0x1000>; + ranges; + #address-cells = <1>; + #size-cells = <1>; ti,hwmods = "usb_otg_hs"; + + ctrl_mod: control@44e10000 { + compatible = "ti,am335x-usb-ctrl-module"; + reg = <0x44e10620 0x10 + 0x44e10648 0x4>; + reg-names = "phy_ctrl", "wakeup"; + }; + + usb0_phy: usb-phy@47401300 { + compatible = "ti,am335x-usb-phy"; + reg = <0x47401300 0x100>; + reg-names = "phy"; + ti,ctrl_mod = <&ctrl_mod>; + }; + + usb0: usb@47401000 { + compatible = "ti,musb-am33xx"; + reg = <0x47401400 0x400 + 0x47401000 0x200>; + reg-names = "mc", "control"; + + interrupts = <18>; + interrupt-names = "mc"; + dr_mode = "otg" + mentor,multipoint = <1>; + mentor,num-eps = <16>; + mentor,ram-bits = <12>; + mentor,power = <500>; + phys = <&usb0_phy>; + + dmas = <&cppi41dma 0 0 &cppi41dma 1 0 + &cppi41dma 2 0 &cppi41dma 3 0 + &cppi41dma 4 0 &cppi41dma 5 0 + &cppi41dma 6 0 &cppi41dma 7 0 + &cppi41dma 8 0 &cppi41dma 9 0 + &cppi41dma 10 0 &cppi41dma 11 0 + &cppi41dma 12 0 &cppi41dma 13 0 + &cppi41dma 14 0 &cppi41dma 0 1 + &cppi41dma 1 1 &cppi41dma 2 1 + &cppi41dma 3 1 &cppi41dma 4 1 + &cppi41dma 5 1 &cppi41dma 6 1 + &cppi41dma 7 1 &cppi41dma 8 1 + &cppi41dma 9 1 &cppi41dma 10 1 + &cppi41dma 11 1 &cppi41dma 12 1 + &cppi41dma 13 1 &cppi41dma 14 1>; + dma-names = + "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7", + "rx8", "rx9", "rx10", "rx11", "rx12", "rx13", + "rx14", "rx15", + "tx1", "tx2", "tx3", "tx4", "tx5", "tx6", "tx7", + "tx8", "tx9", "tx10", "tx11", "tx12", "tx13", + "tx14", "tx15"; + }; + + usb1_phy: usb-phy@47401b00 { + compatible = "ti,am335x-usb-phy"; + reg = <0x47401b00 0x100>; + reg-names = "phy"; + ti,ctrl_mod = <&ctrl_mod>; + }; + + usb1: usb@47401800 { + compatible = "ti,musb-am33xx"; + reg = <0x47401c00 0x400 + 0x47401800 0x200>; + reg-names = "mc", "control"; + interrupts = <19>; + interrupt-names = "mc"; + dr_mode = "host" + mentor,multipoint = <1>; + mentor,num-eps = <16>; + mentor,ram-bits = <12>; + mentor,power = <500>; + phys = <&usb1_phy>; + + dmas = <&cppi41dma 15 0 &cppi41dma 16 0 + &cppi41dma 17 0 &cppi41dma 18 0 + &cppi41dma 19 0 &cppi41dma 20 0 + &cppi41dma 21 0 &cppi41dma 22 0 + &cppi41dma 23 0 &cppi41dma 24 0 + &cppi41dma 25 0 &cppi41dma 26 0 + &cppi41dma 27 0 &cppi41dma 28 0 + &cppi41dma 29 0 &cppi41dma 15 1 + &cppi41dma 16 1 &cppi41dma 17 1 + &cppi41dma 18 1 &cppi41dma 19 1 + &cppi41dma 20 1 &cppi41dma 21 1 + &cppi41dma 22 1 &cppi41dma 23 1 + &cppi41dma 24 1 &cppi41dma 25 1 + &cppi41dma 26 1 &cppi41dma 27 1 + &cppi41dma 28 1 &cppi41dma 29 1>; + dma-names = + "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7", + "rx8", "rx9", "rx10", "rx11", "rx12", "rx13", + "rx14", "rx15", + "tx1", "tx2", "tx3", "tx4", "tx5", "tx6", "tx7", + "tx8", "tx9", "tx10", "tx11", "tx12", "tx13", + "tx14", "tx15"; + }; + + cppi41dma: dma-controller@07402000 { + compatible = "ti,am3359-cppi41"; + reg = <0x47400000 0x1000 + 0x47402000 0x1000 + 0x47403000 0x1000 + 0x47404000 0x4000>; + reg-names = "glue", "controller", "scheduler", "queuemgr"; + interrupts = <17>; + interrupt-names = "glue"; + #dma-cells = <2>; + #dma-channels = <30>; + #dma-requests = <256>; + }; }; 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 DWC3- USB3 CONTROLLER Required properties: - - compatible: must be "synopsys,dwc3" + - compatible: must be "snps,dwc3" - reg : Address and length of the register set for the device - interrupts: Interrupts used by the dwc3 controller. - - usb-phy : array of phandle for the PHY device + - usb-phy : array of phandle for the PHY device. The first element + in the array is expected to be a handle to the USB2/HS PHY and + the second element is expected to be a handle to the USB3/SS PHY Optional properties: - tx-fifo-resize: determines if the FIFO *has* to be reallocated. @@ -14,7 +16,7 @@ Optional properties: This is usually a subnode to DWC3 glue to which it is connected. dwc3@4a030000 { - compatible = "synopsys,dwc3"; + compatible = "snps,dwc3"; reg = <0x4a030000 0xcfff>; interrupts = <0 92 4> 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 @@ +Generic USB Properties + +Optional properties: + - maximum-speed: tells USB controllers we want to work up to a certain + speed. Valid arguments are "super-speed", "high-speed", + "full-speed" and "low-speed". In case this isn't passed + via DT, USB controllers should default to their maximum + HW capability. + - dr_mode: tells Dual-Role USB controllers that we want to work on a + particular mode. Valid arguments are "host", + "peripheral" and "otg". In case this attribute isn't + passed via DT, USB DRD controllers should default to + OTG. + +This is an attribute to a USB controller such as: + +dwc3@4a030000 { + compatible = "synopsys,dwc3"; + reg = <0x4a030000 0xcfff>; + interrupts = <0 92 4> + usb-phy = <&usb2_phy>, <&usb3,phy>; + maximum-speed = "super-speed"; + dr_mode = "otg"; +}; 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 The device node for Tegra SOC USB PHY: Required properties : - - compatible : Should be "nvidia,tegra20-usb-phy". + - compatible : Should be "nvidia,tegra<chip>-usb-phy". - reg : Defines the following set of registers, in the order listed: - The PHY's own register set. Always present. @@ -24,17 +24,26 @@ Required properties : Required properties for phy_type == ulpi: - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. -Required PHY timing params for utmi phy: +Required PHY timing params for utmi phy, for all chips: - nvidia,hssync-start-delay : Number of 480 Mhz clock cycles to wait before start of sync launches RxActive - nvidia,elastic-limit : Variable FIFO Depth of elastic input store - nvidia,idle-wait-delay : Number of 480 Mhz clock cycles of idle to wait before declare IDLE. - nvidia,term-range-adj : Range adjusment on terminations - - nvidia,xcvr-setup : HS driver output control + - Either one of the following for HS driver output control: + - nvidia,xcvr-setup : integer, uses the provided value. + - nvidia,xcvr-setup-use-fuses : boolean, indicates that the value is read + from the on-chip fuses + If both are provided, nvidia,xcvr-setup-use-fuses takes precedence. - nvidia,xcvr-lsfslew : LS falling slew rate control. - nvidia,xcvr-lsrslew : LS rising slew rate control. +Required PHY timing params for utmi phy, only on Tegra30 and above: + - nvidia,xcvr-hsslew : HS slew rate control. + - nvidia,hssquelch-level : HS squelch detector level. + - nvidia,hsdiscon-level : HS disconnect detector level. + Optional properties: - nvidia,has-legacy-mode : boolean indicates whether this controller can operate in legacy mode (as APX 2500 / 2600). In legacy mode some @@ -48,5 +57,5 @@ Optional properties: peripheral means it is device controller otg means it can operate as either ("on the go") -Required properties for dr_mode == otg: +VBUS control (required for dr_mode == otg, optional for dr_mode == host): - 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 It should be set to "1" for HW mode and "2" for SW mode. - ranges: the child address space are mapped 1:1 onto the parent address space +Optional Properties: + - extcon : phandle for the extcon device omap dwc3 uses to detect + connect/disconnect events. + - vbus-supply : phandle to the regulator device tree node if needed. + Sub-nodes: The dwc3 core should be added as subnode to omap dwc3 glue. - 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 @@ +Samsung High Speed USB OTG controller +----------------------------- + +The Samsung HSOTG IP can be found on Samsung SoCs, from S3C6400 onwards. +It gives functionality of OTG-compliant USB 2.0 host and device with +support for USB 2.0 high-speed (480Mbps) and full-speed (12 Mbps) +operation. + +Currently only device mode is supported. + +Binding details +----- + +Required properties: +- compatible: "samsung,s3c6400-hsotg" should be used for all currently + supported SoC, +- interrupt-parent: phandle for the interrupt controller to which the + interrupt signal of the HSOTG block is routed, +- interrupts: specifier of interrupt signal of interrupt controller, + according to bindings of interrupt controller, +- clocks: contains an array of clock specifiers: + - first entry: OTG clock +- clock-names: contains array of clock names: + - first entry: must be "otg" +- vusb_d-supply: phandle to voltage regulator of digital section, +- vusb_a-supply: phandle to voltage regulator of analog section. + +Example +----- + + hsotg@12480000 { + compatible = "samsung,s3c6400-hsotg"; + reg = <0x12480000 0x20000>; + interrupts = <0 71 0>; + clocks = <&clock 305>; + clock-names = "otg"; + vusb_d-supply = <&vusb_reg>; + vusb_a-supply = <&vusbdac_reg>; + }; + 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 @@ +USB xHCI controllers + +Required properties: + - compatible: should be "xhci-platform". + - reg: should contain address and length of the standard XHCI + register set for the device. + - interrupts: one XHCI interrupt should be described here. + +Example: + usb@f0931000 { + compatible = "xhci-platform"; + reg = <0xf0931000 0x8c8>; + interrupts = <0x0 0x4e 0x0>; + }; 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 @@ SMSC USB3503 High-Speed Hub Controller Required properties: -- compatible: Should be "smsc,usb3503". -- reg: Specifies the i2c slave address, it should be 0x08. +- compatible: Should be "smsc,usb3503" or "smsc,usb3503a". + +Optional properties: +- reg: Specifies the i2c slave address, it is required and should be 0x08 + if I2C is used. - connect-gpios: Should specify GPIO for connect. - disabled-ports: Should specify the ports unused. '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 366ce9b87240..ec4d713674fa 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -11,6 +11,7 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC) apm Applied Micro Circuits Corporation (APM) arm ARM Ltd. atmel Atmel Corporation +avago Avago Technologies bosch Bosch Sensortec GmbH brcm Broadcom Corporation 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: - stride: The number of bytes in each line of the framebuffer. - format: The format of the framebuffer surface. Valid values are: - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b). + - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r). Example: 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 devm_kzalloc() devm_kfree() +IIO + devm_iio_device_alloc() + devm_iio_device_free() + devm_iio_trigger_alloc() + devm_iio_trigger_free() + IO region devm_request_region() devm_request_mem_region() diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index f7cbf574a875..b91cfaaf6a0f 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -144,11 +144,12 @@ journal_async_commit Commit block can be written to disk without waiting mount the device. This will enable 'journal_checksum' internally. +journal_path=path journal_dev=devnum When the external journal device's major/minor numbers - have changed, this option allows the user to specify + have changed, these options allow the user to specify the new journal location. The journal device is - identified through its new major/minor numbers encoded - in devnum. + identified through either its new major/minor numbers + encoded in devnum, or via a path to the device. norecovery Don't load the journal on mounting. Note that noload if the filesystem was not unmounted cleanly, 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: Prefix: 'ads1015' Datasheet: Publicly available at the Texas Instruments website : http://focus.ti.com/lit/ds/symlink/ads1015.pdf + * Texas Instruments ADS1115 + Prefix: 'ads1115' + Datasheet: Publicly available at the Texas Instruments website : + http://focus.ti.com/lit/ds/symlink/ads1115.pdf Authors: Dirk Eibach, Guntermann & Drunck GmbH <eibach@gdsys.de> @@ -13,9 +17,9 @@ Authors: Description ----------- -This driver implements support for the Texas Instruments ADS1015. +This driver implements support for the Texas Instruments ADS1015/ADS1115. -This device is a 12-bit A-D converter with 4 inputs. +This device is a 12/16-bit A-D converter with 4 inputs. The inputs can be used single ended or in certain differential combinations. 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 @@ +Kernel driver htu21 +=================== + +Supported chips: + * Measurement Specialties HTU21D + Prefix: 'htu21' + Addresses scanned: none + Datasheet: Publicly available at the Measurement Specialties website + http://www.meas-spec.com/downloads/HTU21D.pdf + + +Author: + William Markezana <william.markezana@meas-spec.com> + +Description +----------- + +The HTU21D is a humidity and temperature sensor in a DFN package of +only 3 x 3 mm footprint and 0.9 mm height. + +The devices communicate with the I2C protocol. All sensors are set to the +same I2C address 0x40, so an entry with I2C_BOARD_INFO("htu21", 0x40) can +be used in the board setup code. + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices +for details. + +sysfs-Interface +--------------- + +temp1_input - temperature input +humidity1_input - humidity input + +Notes +----- + +The driver uses the default resolution settings of 12 bit for humidity and 14 +bit for temperature, which results in typical measurement times of 11 ms for +humidity and 44 ms for temperature. To keep self heating below 0.1 degree +Celsius, the device should not be active for more than 10% of the time. For +this reason, the driver performs no more than two measurements per second and +reports cached information if polled more frequently. + +Different resolutions, the on-chip heater, using the CRC checksum and reading +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: * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series) * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series) * AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity" +* AMD Family 16h processors: "Kabini" Prefix: 'k10temp' Addresses scanned: PCI space 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. The ServerWorks Southbridges, the Intel 440MX, and the Victory66 are identical to the PIIX4 in I2C/SMBus support. -The AMD SB700 and SP5100 chipsets implement two PIIX4-compatible SMBus -controllers. If your BIOS initializes the secondary controller, it will -be detected by this driver as an "Auxiliary SMBus Host Controller". +The AMD SB700, SB800, SP5100 and Hudson-2 chipsets implement two +PIIX4-compatible SMBus controllers. If your BIOS initializes the +secondary controller, it will be detected by this driver as +an "Auxiliary SMBus Host Controller". If you own Force CPCI735 motherboard or other OSB4 based systems you may need 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(). Example (from omap2 h4): -static struct i2c_board_info __initdata h4_i2c_board_info[] = { +static struct i2c_board_info h4_i2c_board_info[] __initdata = { { I2C_BOARD_INFO("isp1301_omap", 0x2d), .irq = OMAP_GPIO_IRQ(125), 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. Format: To spoof as Windows 98: ="Microsoft Windows" acpi_osi= [HW,ACPI] Modify list of supported OS interface strings - acpi_osi="string1" # add string1 -- only one string - acpi_osi="!string2" # remove built-in string2 + acpi_osi="string1" # add string1 + acpi_osi="!string2" # remove string2 + acpi_osi=!* # remove all strings + acpi_osi=! # disable all built-in OS vendor + strings acpi_osi= # disable all strings + 'acpi_osi=!' can be used in combination with single or + multiple 'acpi_osi="string1"' to support specific OS + vendor string(s). Note that such command can only + affect the default state of the OS vendor strings, thus + it cannot affect the default state of the feature group + strings and the current state of the OS vendor strings, + specifying it multiple times through kernel command line + is meaningless. This command is useful when one do not + care about the state of the feature group strings which + should be controlled by the OSPM. + Examples: + 1. 'acpi_osi=! acpi_osi="Windows 2000"' is equivalent + to 'acpi_osi="Windows 2000" acpi_osi=!', they all + can make '_OSI("Windows 2000")' TRUE. + + 'acpi_osi=' cannot be used in combination with other + 'acpi_osi=' command lines, the _OSI method will not + exist in the ACPI namespace. NOTE that such command can + only affect the _OSI support state, thus specifying it + multiple times through kernel command line is also + meaningless. + Examples: + 1. 'acpi_osi=' can make 'CondRefOf(_OSI, Local1)' + FALSE. + + 'acpi_osi=!*' can be used in combination with single or + multiple 'acpi_osi="string1"' to support specific + string(s). Note that such command can affect the + current state of both the OS vendor strings and the + feature group strings, thus specifying it multiple times + through kernel command line is meaningful. But it may + still not able to affect the final state of a string if + there are quirks related to this string. This command + is useful when one want to control the state of the + feature group strings to debug BIOS issues related to + the OSPM features. + Examples: + 1. 'acpi_osi="Module Device" acpi_osi=!*' can make + '_OSI("Module Device")' FALSE. + 2. 'acpi_osi=!* acpi_osi="Module Device"' can make + '_OSI("Module Device")' TRUE. + 3. 'acpi_osi=! acpi_osi=!* acpi_osi="Windows 2000"' is + equivalent to + 'acpi_osi=!* acpi_osi=! acpi_osi="Windows 2000"' + and + 'acpi_osi=!* acpi_osi="Windows 2000" acpi_osi=!', + they all will make '_OSI("Windows 2000")' TRUE. + acpi_pm_good [X86] Override the pmtimer bug detection: force the kernel to assume that this machine's pmtimer latches its value @@ -2953,7 +3004,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. improve throughput, but will also increase the amount of memory reserved for use by the client. - swapaccount[=0|1] + swapaccount=[0|1] [KNL] Enable accounting of swap in memory resource controller if no parameter or 1 is given or disable it if 0 is given (See Documentation/cgroups/memory.txt) @@ -3322,6 +3373,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. them quite hard to use for exploits but might break your system. + vt.color= [VT] Default text color. + Format: 0xYX, X = foreground, Y = background. + Default: 0x07 = light gray on black. + vt.cur_default= [VT] Default cursor shape. Format: 0xCCBBAA, where AA, BB, and CC are the same as the parameters of the <Esc>[?A;B;Cc escape sequence; @@ -3361,6 +3416,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. overridden by individual drivers. 0 will hide cursors, 1 will display them. + vt.italic= [VT] Default color for italic text; 0-15. + Default: 2 = green. + + vt.underline= [VT] Default color for underlined text; 0-15. + Default: 3 = cyan. + watchdog timers [HW,WDT] For information on watchdog timers, see Documentation/watchdog/watchdog-parameters.txt or other driver-specific files in the 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 프로ì 트를 ë´ì•¼ 한다. http://kernelnewbies.org ê·¸ê³³ì€ ê±°ì˜ ëª¨ë“ ì¢…ë¥˜ì˜ ê¸°ë³¸ì ì¸ ì»¤ë„ ê°œë°œ 질문들(질문하기 ì „ì— ë¨¼ì € -ì•„ì¹´ì´ë¸Œë¥¼ 찾아ë´ë¼. ê³¼ê±°ì— ì´ë¯¸ 답변ë˜ì—ˆì„ ìˆ˜ë„ ìžˆë‹¤)ì„ í• ìˆ˜ìžˆëŠ” ë„ì›€ì´ -ë 만한 ë©”ì¼ë§ 리스트가 있다. ë˜í•œ 실시간으로 질문 í• ìˆ˜ 있는 IRC 채ë„ë„ +ì•„ì¹´ì´ë¸Œë¥¼ 찾아ë´ë¼. ê³¼ê±°ì— ì´ë¯¸ 답변ë˜ì—ˆì„ ìˆ˜ë„ ìžˆë‹¤)ì„ í• ìˆ˜ 있는 ë„ì›€ì´ +ë 만한 ë©”ì¼ë§ 리스트가 있다. ë˜í•œ 실시간으로 질문 í• ìˆ˜ 있는 IRC 채ë„ë„ ê°€ì§€ê³ ìžˆìœ¼ë©° 리눅스 ì»¤ë„ ê°œë°œì„ ë°°ìš°ëŠ” ë° ìœ ìš©í•œ ë¬¸ì„œë“¤ì„ ë³´ìœ í•˜ê³ ìžˆë‹¤. 웹사ì´íŠ¸ëŠ” 코드구성, 서브시스템들, ê·¸ë¦¬ê³ í˜„ìž¬ 프로ì 트들 @@ -245,7 +245,7 @@ Documentation/DocBook/ ë””ë ‰í† ë¦¬ ë‚´ì—ì„œ 만들어지며 PDF, Postscript, H ê²ƒì„ ê¸°ì–µí•´ë¼. 왜ëƒí•˜ë©´ ë³€ê²½ì´ ìžì²´ë‚´ì—서만 ë°œìƒí•˜ê³ ì¶”ê°€ëœ ì½”ë“œê°€ ë“œë¼ì´ë²„ ì™¸ë¶€ì˜ ë‹¤ë¥¸ 부분ì—는 ì˜í–¥ì„ 주지 않으므로 그런 ë³€ê²½ì€ íšŒê·€(ì—ìžì£¼: ì´ì „ì—는 존재하지 않았지만 새로운 기능추가나 변경으로 ì¸í•´ - ìƒê²¨ë‚œ 버그)를 ì¼ìœ¼í‚¬ 만한 ìœ„í—˜ì„ ê°€ì§€ê³ ìžˆì§€ 않기 때문ì´ë‹¤. -rc1ì´ + ìƒê²¨ë‚œ 버그)를 ì¼ìœ¼í‚¬ 만한 ìœ„í—˜ì„ ê°€ì§€ê³ ìžˆì§€ 않기 때문ì´ë‹¤. -rc1ì´ ë°°í¬ëœ ì´í›„ì— git를 사용하여 íŒ¨ì¹˜ë“¤ì„ Linusì—게 보낼수 있지만 íŒ¨ì¹˜ë“¤ì€ ê³µì‹ì ì¸ ë©”ì¼ë§ 리스트로 ë³´ë‚´ì„œ ê²€í† ë¥¼ ë°›ì„ í•„ìš”ê°€ 있다. - 새로운 -rc는 Linusê°€ 현재 git treeê°€ 테스트 í•˜ê¸°ì— ì¶©ë¶„ížˆ ì•ˆì •ëœ ìƒíƒœì— @@ -455,7 +455,7 @@ bugme-janitor ë©”ì¼ë§ 리스트(bugzillaì— ëª¨ë“ ë³€í™”ë“¤ì´ ì—¬ê¸°ì„œ ë©”ì - ì˜ê²¬ - ë³€ê²½ì„ ìœ„í•œ 요구 - ë‹¹ìœ„ì„±ì„ ìœ„í•œ 요구 - - ê³ ìš” + - 침묵 기억하ë¼. ì´ê²ƒë“¤ì€ ì—¬ëŸ¬ë¶„ì˜ íŒ¨ì¹˜ê°€ 커ë„ë¡œ 들어가기 위한 ê³¼ì •ì´ë‹¤. ì—¬ëŸ¬ë¶„ì˜ íŒ¨ì¹˜ë“¤ì€ ë¹„íŒê³¼ 다른 ì˜ê²¬ì„ ë°›ì„ ìˆ˜ ìžˆê³ ê·¸ê²ƒë“¤ì„ ê¸°ìˆ ì ì¸ ë ˆë²¨ë¡œ í‰ê°€í•˜ê³ @@ -472,7 +472,7 @@ bugme-janitor ë©”ì¼ë§ 리스트(bugzillaì— ëª¨ë“ ë³€í™”ë“¤ì´ ì—¬ê¸°ì„œ ë©”ì 가능한한 가장 ì¢‹ì€ ê¸°ìˆ ì ì¸ í•´ë‹µì„ ì°¾ê³ ìžˆëŠ” 커뮤니티ì—서는 í•ìƒ ì–´ë–¤ 패치가 얼마나 좋ì€ì§€ì— 관하여 다른 ì˜ê²¬ë“¤ì´ ìžˆì„ ìˆ˜ 있다. ì—¬ëŸ¬ë¶„ì€ í˜‘ì¡°ì ì´ì–´ì•¼ í•˜ê³ ê¸°êº¼ì´ ì—¬ëŸ¬ë¶„ì˜ ìƒê°ì„ ì»¤ë„ ë‚´ì— ë§žì¶”ì–´ì•¼ 한다. 아니면 -ì ì–´ë„ ì—¬ëŸ¬ë¶„ì˜ ê²ƒì´ ê°€ì¹˜ìžˆë‹¤ëŠ” ê²ƒì„ ì¤‘ëª…í•˜ì—¬ì•¼ 한다. ìž˜ëª»ëœ ê²ƒë„ ì—¬ëŸ¬ë¶„ì´ +ì ì–´ë„ ì—¬ëŸ¬ë¶„ì˜ ê²ƒì´ ê°€ì¹˜ìžˆë‹¤ëŠ” ê²ƒì„ ì¦ëª…하여야 한다. ìž˜ëª»ëœ ê²ƒë„ ì—¬ëŸ¬ë¶„ì´ ì˜¬ë°”ë¥¸ ë°©í–¥ì˜ í•´ê²°ì±…ìœ¼ë¡œ ì´ëŒì–´ê°ˆ ì˜ì§€ê°€ 있다면 받아들여질 것ì´ë¼ëŠ” ì ì„ ê¸°ì–µí•˜ë¼. @@ -488,21 +488,21 @@ bugme-janitor ë©”ì¼ë§ 리스트(bugzillaì— ëª¨ë“ ë³€í™”ë“¤ì´ ì—¬ê¸°ì„œ ë©”ì ì»¤ë„ ì»¤ë®¤ë‹ˆí‹°ëŠ” 가장 ì „í†µì ì¸ íšŒì‚¬ì˜ ê°œë°œ 환경과는 다르다. ì—¬ê¸°ì— ì—¬ëŸ¬ë¶„ë“¤ì˜ ë¬¸ì œë¥¼ 피하기 위한 목ë¡ì´ 있다. ì—¬ëŸ¬ë¶„ë“¤ì´ ì œì•ˆí•œ ë³€ê²½ë“¤ì— ê´€í•˜ì—¬ ë§í• ë•Œ ì¢‹ì€ ê²ƒë“¤ : - - "ì´ê²ƒì€ 여러 ë¬¸ì œë“¤ì„ í•´ê²¹í•©ë‹ˆë‹¤." - - "ì´ê²ƒì€ 2000 ë¼ì¸ì˜ 코드를 ì œê±°í•©ë‹ˆë‹¤." + - "ì´ê²ƒì€ 여러 ë¬¸ì œë“¤ì„ í•´ê²°í•©ë‹ˆë‹¤." + - "ì´ê²ƒì€ 2000 ë¼ì¸ì˜ 코드를 줄입니다." - "ì´ê²ƒì€ ë‚´ê°€ ë§í•˜ë ¤ëŠ” ê²ƒì— ê´€í•´ 설명하는 패치입니다." - - "나는 5ê°œì˜ ë‹¤ë¥¸ 아키í…ì³ì—ì„œ ê·¸ê²ƒì„ í…ŒìŠ¤íŠ¸í–ˆìŠ´ìœ¼ë¡œ..." - - "ì—¬ê¸°ì— ì¼ë ¨ì˜ ìž‘ì€ íŒ¨ì¹˜ë“¤ì´ ìžˆìŠ´ìŒë¡œ..." - - "ì´ê²ƒì€ ì¼ë°˜ì ì¸ ë¨¸ì‹ ì—ì„œ ì„±ëŠ¥ì„ í–¥ìƒì‹œí‚´ìœ¼ë¡œ..." + - "나는 5ê°œì˜ ë‹¤ë¥¸ 아키í…ì³ì—ì„œ ê·¸ê²ƒì„ í…ŒìŠ¤íŠ¸ 했으므로..." + - "ì—¬ê¸°ì— ì¼ë ¨ì˜ ìž‘ì€ íŒ¨ì¹˜ë“¤ì´ ìžˆìœ¼ë¯€ë¡œ..." + - "ì´ê²ƒì€ ì¼ë°˜ì ì¸ ë¨¸ì‹ ì—ì„œ ì„±ëŠ¥ì„ í–¥ìƒí•¨ìœ¼ë¡œ..." ì—¬ëŸ¬ë¶„ë“¤ì´ ë§í• ë•Œ 피해야 í• ì¢‹ì§€ ì•Šì€ ê²ƒë“¤ : - - "우리를 ê·¸ê²ƒì„ AIT/ptx/Solarisì—ì„œ ì´ëŸ¬í•œ 방법으로 했다. 그러므로 ê·¸ê²ƒì€ ì¢‹ì€ ê²ƒìž„ì— í‹€ë¦½ì—†ë‹¤..." + - "우리는 ê·¸ê²ƒì„ AIX/ptx/Solarisì—ì„œ ì´ëŸ¬í•œ 방법으로 했다. 그러므로 ê·¸ê²ƒì€ ì¢‹ì€ ê²ƒìž„ì— í‹€ë¦¼ì—†ë‹¤..." - "나는 20ë…„ë™ì•ˆ ì´ê²ƒì„ 해왔다. 그러므로..." - "ì´ê²ƒì€ ëˆì„ 벌기위해 ë‚˜ì˜ íšŒì‚¬ê°€ 필요로 하는 것ì´ë‹¤." - "ì´ê²ƒì€ ìš°ë¦¬ì˜ ì—”í„°í”„ë¼ì´ì¦ˆ ìƒí’ˆ ë¼ì¸ì„ 위한 것ì´ë‹¤." - "ì—¬ê¸°ì— ë‚˜ì˜ ìƒê°ì„ ë§í•˜ê³ 있는 1000 페ì´ì§€ 설계 문서가 있다." - "나는 6달ë™ì•ˆ ì´ê²ƒì„ 했으니..." - - "ì—¬ê¸°ì— 5000ë¼ì¸ 짜리 패치가 있으니..." + - "ì—¬ê¸°ì— 5000 ë¼ì¸ 짜리 패치가 있으니..." - "나는 현재 ë’¤ì£½ë°•ì£½ì¸ ê²ƒì„ ìž¬ìž‘ì„±í–ˆë‹¤. ê·¸ë¦¬ê³ ì—¬ê¸°ì—..." - "나는 마ê°ì‹œí•œì„ ê°€ì§€ê³ ìžˆìœ¼ë¯€ë¡œ ì´ íŒ¨ì¹˜ëŠ” 지금 ì ìš©ë 필요가 있다." @@ -574,6 +574,7 @@ Patì´ë¼ëŠ” ì´ë¦„ì„ ê°€ì§„ ì—¬ìžê°€ ìžˆì„ ìˆ˜ë„ ìžˆëŠ” 것ì´ë‹¤. ë¦¬ëˆ…ìŠ ë˜í•œ 완성ë˜ì§€ ì•Šì•˜ê³ "ë‚˜ì¤‘ì— ìˆ˜ì •ë 것ì´ë‹¤." 와 ê°™ì€ ê²ƒë“¤ì„ í¬í•¨í•˜ëŠ” íŒ¨ì¹˜ë“¤ì€ ë°›ì•„ë“¤ì—¬ì§€ì§€ ì•Šì„ ê²ƒì´ë¼ëŠ” ì ì„ ìœ ë…하ë¼. + ë³€ê²½ì„ ì •ë‹¹í™”í•´ë¼ ----------------- 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> --------------------------------- 리눅스 ì»¤ë„ ë“œë¼ì´ë²„를 계ì†í•´ì„œ ë©”ì¸ ì»¤ë„ íŠ¸ë¦¬ì— ë°˜ì˜í•˜ì§€ ì•Šê³ -ìœ ì§€ë³´ìˆ˜í•˜ë ¤ê³ í•˜ëŠ” 사름들과 ì´ ë¬¸ì œë¥¼ ë…¼ì˜í•˜ê²Œ ë˜ë©´ 훨씬 ë” +ìœ ì§€ë³´ìˆ˜í•˜ë ¤ê³ í•˜ëŠ” 사람들과 ì´ ë¬¸ì œë¥¼ ë…¼ì˜í•˜ê²Œ ë˜ë©´ 훨씬 ë” "ë…¼ëž€ì˜ ì—¬ì§€ê°€ 많ì€" ì£¼ì œê°€ ë 것ì´ë‹¤. 리눅스 ì»¤ë„ ê°œë°œì€ ëŠìž„ì—†ì´ ë¹ ë¥¸ ì†ë„ë¡œ ì´ë£¨ì–´ì§€ê³ 있으며 ê²°ì½” ëŠìŠ¨í•´ì§„ ì ì´ ì—†ë‹¤. ì»¤ë„ ê°œë°œìžë“¤ì´ 현재 ì¸í„°íŽ˜ì´ìŠ¤ë“¤ì—ì„œ 버그를 -발견하거나 무엇ì¸ê°€ í• ìˆ˜ 있는 ë” ì¢‹ì€ ë°©ë²•ì„ ì°¾ê²Œ ë˜ì—ˆë‹¤ê³ 하ìž. +발견하거나 무엇ì¸ê°€ í• ìˆ˜ 있는 ë” ì¢‹ì€ ë°©ë²•ì„ ì°¾ê²Œ ë˜ì—ˆë‹¤ê³ 하ìž. ê·¸ë“¤ì´ ë°œê²¬í•œ ê²ƒì„ ì‹¤í–‰í•œë‹¤ë©´ ì•„ë§ˆë„ ë” ìž˜ ë™ìž‘하ë„ë¡ í˜„ìž¬ ì¸í„°íŽ˜ì´ìŠ¤ë“¤ì„ ìˆ˜ì •í•˜ê²Œ ë 것ì´ë‹¤. ê·¸ë“¤ì´ ê·¸ëŸ° ì¼ì„ 하게ë˜ë©´ 함수 ì´ë¦„ë“¤ì€ ë³€í•˜ê²Œ ë˜ê³ , êµ¬ì¡°ì²´ë“¤ì€ ëŠ˜ì–´ë‚˜ê±°ë‚˜ 줄어들게 ë˜ê³ , 함수 파ë¼ë¯¸í„°ë“¤ì€ 재작업ë 것ì´ë‹¤. @@ -174,7 +174,7 @@ GPLì„ ë”°ë¥´ëŠ” ë°°í¬ ë“œë¼ì´ë²„ì— ê´€í•´ ì–˜ê¸°í•˜ê³ ìžˆë‹¤ëŠ” ê²ƒì„ ìƒ ë™ìž‘하는 ê²ƒì„ ë³´ìž¥í•œë‹¤. ë©”ì¸ ì»¤ë„ íŠ¸ë¦¬ì— ì—¬ëŸ¬ë¶„ì˜ ë“œë¼ì´ë²„를 ë°˜ì˜í•˜ë©´ 얻게 ë˜ëŠ” 장ì ë“¤ì€ ë‹¤ìŒê³¼ 같다. - - ê´€ë¦¬ì˜ ë“œëŠ” 비용(ì›ëž˜ 개발ìžì˜)ì€ ì¤„ì–´ì¤„ë©´ì„œ ë“œë¼ì´ë²„ì˜ ì§ˆì€ í–¥ìƒë 것ì´ë‹¤. + - ê´€ë¦¬ì— ë“œëŠ” 비용(ì›ëž˜ 개발ìžì˜)ì€ ì¤„ì–´ì¤„ë©´ì„œ ë“œë¼ì´ë²„ì˜ ì§ˆì€ í–¥ìƒë 것ì´ë‹¤. - 다른 개발ìžë“¤ì´ ì—¬ëŸ¬ë¶„ì˜ ë“œë¼ì´ë²„ì— ê¸°ëŠ¥ë“¤ì„ ì¶”ê°€ í• ê²ƒì´ë‹¤. - 다른 ì‚¬ëžŒë“¤ì€ ì—¬ëŸ¬ë¶„ì˜ ë“œë¼ì´ë²„ì— ë²„ê·¸ë¥¼ ë°œê²¬í•˜ê³ ìˆ˜ì •í• ê²ƒì´ë‹¤. - 다른 ì‚¬ëžŒë“¤ì€ ì—¬ëŸ¬ë¶„ì˜ ë“œë¼ì´ë²„ì˜ ê°œì„ ì ì„ ì°¾ì„ ì¤„ 것ì´ë‹¤. 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/ This driver provides support for extra features of ACPI-compatible ASUS laptops. It may also support some MEDION, JVC or VICTOR laptops (such as MEDION 9675 or - VICTOR XP7210 for example). It makes all the extra buttons generate standard - ACPI events that go through /proc/acpi/events and input events (like keyboards). + VICTOR XP7210 for example). It makes all the extra buttons generate input + events (like keyboards). On some models adds support for changing the display brightness and output, switching the LCD backlight on and off, and most importantly, allows you to blink those fancy LEDs intended for reporting mail and wireless status. @@ -55,8 +55,8 @@ Usage DSDT) to me. That's all, now, all the events generated by the hotkeys of your laptop - should be reported in your /proc/acpi/event entry. You can check with - "acpi_listen". + should be reported via netlink events. You can check with + "acpi_genl monitor" (part of the acpica project). Hotkeys are also reported as input keys (like keyboards) you can check 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): ------------------ Some models report hotkeys through the SNC or SPIC devices, such events are reported both through the ACPI subsystem as acpi events and through the INPUT -subsystem. See the logs of acpid or /proc/acpi/event and -/proc/bus/input/devices to find out what those events are and which input -devices are created by the driver. Additionally, loading the driver with the -debug option will report all events in the kernel log. +subsystem. See the logs of /proc/bus/input/devices to find out what those +events are and which input devices are created by the driver. +Additionally, loading the driver with the debug option will report all events +in the kernel log. The "scancodes" passed to the input system (that can be remapped with udev) 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: This attribute has poll()/select() support. - hotkey_report_mode: - Returns the state of the procfs ACPI event report mode - filter for hot keys. If it is set to 1 (the default), - all hot key presses are reported both through the input - layer and also as ACPI events through procfs (but not - through netlink). If it is set to 2, hot key presses - are reported only through the input layer. - - This attribute is read-only in kernels 2.6.23 or later, - and read-write on earlier kernels. - - May return -EPERM (write access locked out by module - parameter) or -EACCES (read-only). - wakeup_reason: Set to 1 if the system is waking up because the user 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 Non hotkey ACPI HKEY event map: ------------------------------- -Events that are not propagated by the driver, except for legacy -compatibility purposes when hotkey_report_mode is set to 1: - -0x5001 Lid closed -0x5002 Lid opened -0x5009 Tablet swivel: switched to tablet mode -0x500A Tablet swivel: switched to normal mode -0x7000 Radio Switch may have changed state - Events that are never propagated by the driver: 0x2304 System is waking up from suspend to undock 0x2305 System is waking up from suspend to eject bay 0x2404 System is waking up from hibernation to undock 0x2405 System is waking up from hibernation to eject bay +0x5001 Lid closed +0x5002 Lid opened +0x5009 Tablet swivel: switched to tablet mode +0x500A Tablet swivel: switched to normal mode 0x5010 Brightness level changed/control event 0x6000 KEYBOARD: Numlock key pressed 0x6005 KEYBOARD: Fn key pressed (TO BE VERIFIED) +0x7000 Radio Switch may have changed state + Events that are propagated by the driver to userspace: @@ -574,50 +557,6 @@ operating system is to force either an immediate suspend or hibernate cycle, or a system shutdown. Obviously, something is very wrong if this happens. -Compatibility notes: - -ibm-acpi and thinkpad-acpi 0.15 (mainline kernels before 2.6.23) never -supported the input layer, and sent events over the procfs ACPI event -interface. - -To avoid sending duplicate events over the input layer and the ACPI -event interface, thinkpad-acpi 0.16 implements a module parameter -(hotkey_report_mode), and also a sysfs device attribute with the same -name. - -Make no mistake here: userspace is expected to switch to using the input -layer interface of thinkpad-acpi, together with the ACPI netlink event -interface in kernels 2.6.23 and later, or with the ACPI procfs event -interface in kernels 2.6.22 and earlier. - -If no hotkey_report_mode module parameter is specified (or it is set to -zero), the driver defaults to mode 1 (see below), and on kernels 2.6.22 -and earlier, also allows one to change the hotkey_report_mode through -sysfs. In kernels 2.6.23 and later, where the netlink ACPI event -interface is available, hotkey_report_mode cannot be changed through -sysfs (it is read-only). - -If the hotkey_report_mode module parameter is set to 1 or 2, it cannot -be changed later through sysfs (any writes will return -EPERM to signal -that hotkey_report_mode was locked. On 2.6.23 and later, where -hotkey_report_mode cannot be changed at all, writes will return -EACCES). - -hotkey_report_mode set to 1 makes the driver export through the procfs -ACPI event interface all hot key presses (which are *also* sent to the -input layer). This is a legacy compatibility behaviour, and it is also -the default mode of operation for the driver. - -hotkey_report_mode set to 2 makes the driver filter out the hot key -presses from the procfs ACPI event interface, so these events will only -be sent through the input layer. Userspace that has been updated to use -the thinkpad-acpi input layer interface should set hotkey_report_mode to -2. - -Hot key press events are never sent to the ACPI netlink event interface. -Really up-to-date userspace under kernel 2.6.23 and later is to use the -netlink interface and the input layer interface, and don't bother at all -with hotkey_report_mode. - Brightness hotkey notes: 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 code: q = &a; - if (p) + if (p) { + <data dependency barrier> q = &b; - <data dependency barrier> + } x = *q; 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 required is: q = &a; - if (p) + if (p) { + <read barrier> q = &b; - <read barrier> + } x = *q; diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 8e5eacbdcfa3..8fd254c73589 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt @@ -210,13 +210,15 @@ If memory device is found, memory hotplug code will be called. 4.2 Notify memory hot-add event by hand ------------ -In some environments, especially virtualized environment, firmware will not -notify memory hotplug event to the kernel. For such environment, "probe" -interface is supported. This interface depends on CONFIG_ARCH_MEMORY_PROBE. - -Now, CONFIG_ARCH_MEMORY_PROBE is supported only by powerpc but it does not -contain highly architecture codes. Please add config if you need "probe" -interface. +On powerpc, the firmware does not notify a memory hotplug event to the kernel. +Therefore, "probe" interface is supported to notify the event to the kernel. +This interface depends on CONFIG_ARCH_MEMORY_PROBE. + +CONFIG_ARCH_MEMORY_PROBE is supported on powerpc only. On x86, this config +option is disabled by default since ACPI notifies a memory hotplug event to +the kernel, which performs its hotplug operation as the result. Please +enable this option if you need the "probe" interface for testing purposes +on x86. Probe interface is located at /sys/devices/system/memory/probe 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 - HOWTO for multiqueue network device support. netconsole.txt - The network console module netconsole.ko: configuration and notes. +netdev-FAQ.txt + - FAQ describing how to submit net changes to netdev mailing list. netdev-features.txt - Network interface features API description. 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 @@ Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters ============================================================== -November 15, 2005 +March 15, 2011 Contents ======== @@ -122,7 +122,7 @@ Additional Configurations NOTE: This setting is not saved across reboots. - Ethtool + ethtool ------- 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 @@ -Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters -=============================================================== +Linux* Base Driver for Intel(R) Ethernet Network Connection +=========================================================== Intel Gigabit Linux driver. -Copyright(c) 1999 - 2010 Intel Corporation. +Copyright(c) 1999 - 2013 Intel Corporation. Contents ======== @@ -420,15 +420,15 @@ Additional Configurations - The maximum MTU setting for Jumbo Frames is 16110. This value coincides with the maximum Jumbo Frames size of 16128. - - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or - loss of link. + - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in + poor performance or loss of link. - Adapters based on the Intel(R) 82542 and 82573V/E controller do not support Jumbo Frames. These correspond to the following product names: Intel(R) PRO/1000 Gigabit Server Adapter Intel(R) PRO/1000 PM Network Connection - Ethtool + ethtool ------- The driver utilizes the ethtool interface for driver configuration and 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 @@ -Linux* Driver for Intel(R) Network Connection -============================================= +Linux* Driver for Intel(R) Ethernet Network Connection +====================================================== Intel Gigabit Linux driver. -Copyright(c) 1999 - 2010 Intel Corporation. +Copyright(c) 1999 - 2013 Intel Corporation. Contents ======== @@ -259,13 +259,16 @@ Additional Configurations - The maximum MTU setting for Jumbo Frames is 9216. This value coincides with the maximum Jumbo Frames size of 9234 bytes. - - Using Jumbo Frames at 10 or 100 Mbps is not supported and may result in + - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in poor performance or loss of link. - Some adapters limit Jumbo Frames sized packets to a maximum of 4096 bytes and some adapters do not support Jumbo Frames. - Ethtool + - Jumbo Frames cannot be configured on an 82579-based Network device, if + MACSec is enabled on the system. + + ethtool ------- The driver utilizes the ethtool interface for driver configuration and diagnostics, as well as displaying statistical information. We @@ -273,6 +276,9 @@ Additional Configurations http://ftp.kernel.org/pub/software/network/ethtool/ + NOTE: When validating enable/disable tests on some parts (82578, for example) + you need to add a few seconds between tests when working with ethtool. + Speed and Duplex ---------------- 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 @@ -Linux* Base Driver for Intel(R) Network Connection -================================================== +Linux* Base Driver for Intel(R) Ethernet Network Connection +=========================================================== Intel Gigabit Linux driver. -Copyright(c) 1999 - 2010 Intel Corporation. +Copyright(c) 1999 - 2013 Intel Corporation. Contents ======== @@ -36,6 +36,53 @@ Default Value: 0 This parameter adds support for SR-IOV. It causes the driver to spawn up to max_vfs worth of virtual function. +QueuePairs +---------- +Valid Range: 0-1 +Default Value: 1 (TX and RX will be paired onto one interrupt vector) + +If set to 0, when MSI-X is enabled, the TX and RX will attempt to occupy +separate vectors. + +This option can be overridden to 1 if there are not sufficient interrupts +available. This can occur if any combination of RSS, VMDQ, and max_vfs +results in more than 4 queues being used. + +Node +---- +Valid Range: 0-n +Default Value: -1 (off) + + 0 - n: where n is the number of the NUMA node that should be used to + allocate memory for this adapter port. + -1: uses the driver default of allocating memory on whichever processor is + running insmod/modprobe. + + The Node parameter will allow you to pick which NUMA node you want to have + the adapter allocate memory from. All driver structures, in-memory queues, + and receive buffers will be allocated on the node specified. This parameter + is only useful when interrupt affinity is specified, otherwise some portion + of the time the interrupt could run on a different core than the memory is + allocated on, causing slower memory access and impacting throughput, CPU, or + both. + +EEE +--- +Valid Range: 0-1 +Default Value: 1 (enabled) + + A link between two EEE-compliant devices will result in periodic bursts of + data followed by long periods where in the link is in an idle state. This Low + Power Idle (LPI) state is supported in both 1Gbps and 100Mbps link speeds. + NOTE: EEE support requires autonegotiation. + +DMAC +---- +Valid Range: 0-1 +Default Value: 1 (enabled) + Enables or disables DMA Coalescing feature. + + Additional Configurations ========================= @@ -55,10 +102,10 @@ Additional Configurations - The maximum MTU setting for Jumbo Frames is 9216. This value coincides with the maximum Jumbo Frames size of 9234 bytes. - - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or - loss of link. + - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in + poor performance or loss of link. - Ethtool + ethtool ------- The driver utilizes the ethtool interface for driver configuration and diagnostics, as well as displaying statistical information. The latest @@ -106,6 +153,14 @@ Additional Configurations Where n=the VF that attempted to do the spoofing. + Setting MAC Address, VLAN and Rate Limit Using IProute2 Tool + ------------------------------------------------------------ + You can set a MAC address of a Virtual Function (VF), a default VLAN and the + rate limit using the IProute2 tool. Download the latest version of the + iproute2 tool from Sourceforge if your version does not have all the + features you require. + + Support ======= 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 @@ -Linux* Base Driver for Intel(R) Network Connection -================================================== +Linux* Base Driver for Intel(R) Ethernet Network Connection +=========================================================== Intel Gigabit Linux driver. -Copyright(c) 1999 - 2010 Intel Corporation. +Copyright(c) 1999 - 2013 Intel Corporation. Contents ======== @@ -55,7 +55,7 @@ networking link on the left to search for your adapter: Additional Configurations ========================= - Ethtool + ethtool ------- The driver utilizes the ethtool interface for driver configuration and 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 SYN flood warnings in logs not being really flooded, your server is seriously misconfigured. + If you want to test which effects syncookies have to your + network connections you can set this knob to 2 to enable + unconditionally generation of syncookies. + tcp_fastopen - INTEGER Enable TCP Fast Open feature (draft-ietf-tcpm-fastopen) to send data in the opening SYN packet. To use this feature, the client application @@ -478,6 +482,15 @@ tcp_syn_retries - INTEGER tcp_timestamps - BOOLEAN Enable timestamps as defined in RFC1323. +tcp_min_tso_segs - INTEGER + Minimal number of segments per TSO frame. + Since linux-3.12, TCP does an automatic sizing of TSO frames, + depending on flow rate, instead of filling 64Kbytes packets. + For specific usages, it's possible to force TCP to build big + TSO frames. Note that TCP stack might split too big TSO packets + if available window is too small. + Default: 2 + tcp_tso_win_divisor - INTEGER This allows control over what percentage of the congestion window can be consumed by a single TSO frame. @@ -516,6 +529,19 @@ tcp_wmem - vector of 3 INTEGERs: min, default, max this value is ignored. Default: between 64K and 4MB, depending on RAM size. +tcp_notsent_lowat - UNSIGNED INTEGER + A TCP socket can control the amount of unsent bytes in its write queue, + thanks to TCP_NOTSENT_LOWAT socket option. poll()/select()/epoll() + reports POLLOUT events if the amount of unsent bytes is below a per + socket value, and if the write queue is not full. sendmsg() will + also not add new buffers if the limit is hit. + + This global variable controls the amount of unsent data for + sockets not using TCP_NOTSENT_LOWAT. For these sockets, a change + to the global variable has immediate effect. + + Default: UINT_MAX (0xFFFFFFFF) + tcp_workaround_signed_windows - BOOLEAN If set, assume no receipt of a window scaling option means the remote TCP is broken and treats the window as a signed quantity. @@ -1022,7 +1048,15 @@ disable_policy - BOOLEAN disable_xfrm - BOOLEAN Disable IPSEC encryption on this interface, whatever the policy +igmpv2_unsolicited_report_interval - INTEGER + The interval in milliseconds in which the next unsolicited + IGMPv1 or IGMPv2 report retransmit will take place. + Default: 10000 (10 seconds) +igmpv3_unsolicited_report_interval - INTEGER + The interval in milliseconds in which the next unsolicited + IGMPv3 report retransmit will take place. + Default: 1000 (1 seconds) tag - INTEGER Allows you to write a number, which can be used as required. @@ -1314,6 +1348,27 @@ ndisc_notify - BOOLEAN 1 - Generate unsolicited neighbour advertisements when device is brought up or hardware address changes. +mldv1_unsolicited_report_interval - INTEGER + The interval in milliseconds in which the next unsolicited + MLDv1 report retransmit will take place. + Default: 10000 (10 seconds) + +mldv2_unsolicited_report_interval - INTEGER + The interval in milliseconds in which the next unsolicited + MLDv2 report retransmit will take place. + Default: 1000 (1 second) + +force_mld_version - INTEGER + 0 - (default) No enforcement of a MLD version, MLDv1 fallback allowed + 1 - Enforce to use MLD version 1 + 2 - Enforce to use MLD version 2 + +suppress_frag_ndisc - INTEGER + Control RFC 6980 (Security Implications of IPv6 Fragmentation + with IPv6 Neighbor Discovery) behavior: + 1 - (default) discard fragmented neighbor discovery packets + 0 - allow fragmented neighbor discovery packets + icmp/*: ratelimit - INTEGER 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 @@ -Linux Base Driver for 10 Gigabit Intel(R) Network Connection -============================================================= +Linux Base Driver for 10 Gigabit Intel(R) Ethernet Network Connection +===================================================================== -October 9, 2007 +March 14, 2011 Contents @@ -274,9 +274,9 @@ Additional Configurations ------------------------------------------------- Configuring a network driver to load properly when the system is started is distribution dependent. Typically, the configuration process involves adding - an alias line to files in /etc/modprobe.d/ as well as editing other system - startup scripts and/or configuration files. Many popular Linux distributions - ship with tools to make these changes for you. To learn the proper way to + an alias line to /etc/modprobe.conf as well as editing other system startup + scripts and/or configuration files. Many popular Linux distributions ship + with tools to make these changes for you. To learn the proper way to configure a network device for your system, refer to your distribution documentation. If during this process you are asked for the driver or module name, the name for the Linux Base Driver for the Intel 10GbE Family of @@ -306,7 +306,7 @@ Additional Configurations with the maximum Jumbo Frames size of 16128. - Ethtool + ethtool ------- The driver utilizes the ethtool interface for driver configuration and 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 @@ -Linux Base Driver for 10 Gigabit PCI Express Intel(R) Network Connection -======================================================================== +Linux* Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Family of +Adapters +============================================================================= -Intel Gigabit Linux driver. -Copyright(c) 1999 - 2010 Intel Corporation. +Intel 10 Gigabit Linux driver. +Copyright(c) 1999 - 2013 Intel Corporation. Contents ======== @@ -16,8 +17,8 @@ Contents Identifying Your Adapter ======================== -The driver in this release is compatible with 82598 and 82599-based Intel -Network Connections. +The driver in this release is compatible with 82598, 82599 and X540-based +Intel Network Connections. For more information on how to identify your adapter, go to the Adapter & Driver ID Guide at: @@ -72,7 +73,7 @@ cables that comply with SFF-8431 v4.1 and SFF-8472 v10.4 specifications. Laser turns off for SFP+ when ifconfig down ------------------------------------------- "ifconfig down" turns off the laser for 82599-based SFP+ fiber adapters. -"ifconfig up" turns on the later. +"ifconfig up" turns on the laser. 82598-BASED ADAPTERS @@ -118,6 +119,93 @@ NOTE: For 82598 backplane cards entering 1 gig mode, flow control default behavior is changed to off. Flow control in 1 gig mode on these devices can lead to Tx hangs. +Intel(R) Ethernet Flow Director +------------------------------- +Supports advanced filters that direct receive packets by their flows to +different queues. Enables tight control on routing a flow in the platform. +Matches flows and CPU cores for flow affinity. Supports multiple parameters +for flexible flow classification and load balancing. + +Flow director is enabled only if the kernel is multiple TX queue capable. + +An included script (set_irq_affinity.sh) automates setting the IRQ to CPU +affinity. + +You can verify that the driver is using Flow Director by looking at the counter +in ethtool: fdir_miss and fdir_match. + +Other ethtool Commands: +To enable Flow Director + ethtool -K ethX ntuple on +To add a filter + Use -U switch. e.g., ethtool -U ethX flow-type tcp4 src-ip 0x178000a + action 1 +To see the list of filters currently present: + ethtool -u ethX + +Perfect Filter: Perfect filter is an interface to load the filter table that +funnels all flow into queue_0 unless an alternative queue is specified using +"action". In that case, any flow that matches the filter criteria will be +directed to the appropriate queue. + +If the queue is defined as -1, filter will drop matching packets. + +To account for filter matches and misses, there are two stats in ethtool: +fdir_match and fdir_miss. In addition, rx_queue_N_packets shows the number of +packets processed by the Nth queue. + +NOTE: Receive Packet Steering (RPS) and Receive Flow Steering (RFS) are not +compatible with Flow Director. IF Flow Director is enabled, these will be +disabled. + +The following three parameters impact Flow Director. + +FdirMode +-------- +Valid Range: 0-2 (0=off, 1=ATR, 2=Perfect filter mode) +Default Value: 1 + + Flow Director filtering modes. + +FdirPballoc +----------- +Valid Range: 0-2 (0=64k, 1=128k, 2=256k) +Default Value: 0 + + Flow Director allocated packet buffer size. + +AtrSampleRate +-------------- +Valid Range: 1-100 +Default Value: 20 + + Software ATR Tx packet sample rate. For example, when set to 20, every 20th + packet, looks to see if the packet will create a new flow. + +Node +---- +Valid Range: 0-n +Default Value: 1 (off) + + 0 - n: where n is the number of NUMA nodes (i.e. 0 - 3) currently online in + your system + 1: turns this option off + + The Node parameter will allow you to pick which NUMA node you want to have + the adapter allocate memory on. + +max_vfs +------- +Valid Range: 1-63 +Default Value: 0 + + If the value is greater than 0 it will also force the VMDq parameter to be 1 + or more. + + This parameter adds support for SR-IOV. It causes the driver to spawn up to + max_vfs worth of virtual function. + + Additional Configurations ========================= @@ -221,9 +309,10 @@ http://www.redhat.com/promo/summit/2008/downloads/pdf/Thursday/Mark_Wagner.pdf Known Issues ============ - Enabling SR-IOV in a 32-bit Microsoft* Windows* Server 2008 Guest OS using - Intel (R) 82576-based GbE or Intel (R) 82599-based 10GbE controller under KVM - ----------------------------------------------------------------------------- + Enabling SR-IOV in a 32-bit or 64-bit Microsoft* Windows* Server 2008/R2 + Guest OS using Intel (R) 82576-based GbE or Intel (R) 82599-based 10GbE + controller under KVM + ------------------------------------------------------------------------ KVM Hypervisor/VMM supports direct assignment of a PCIe device to a VM. This includes traditional PCIe devices, as well as SR-IOV-capable devices using 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 @@ -Linux* Base Driver for Intel(R) Network Connection -================================================== +Linux* Base Driver for Intel(R) Ethernet Network Connection +=========================================================== Intel Gigabit Linux driver. -Copyright(c) 1999 - 2010 Intel Corporation. +Copyright(c) 1999 - 2013 Intel Corporation. Contents ======== 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 @@ + +Information you need to know about netdev +----------------------------------------- + +Q: What is netdev? + +A: It is a mailing list for all network related linux stuff. This includes + anything found under net/ (i.e. core code like IPv6) and drivers/net + (i.e. hardware specific drivers) in the linux source tree. + + Note that some subsystems (e.g. wireless drivers) which have a high volume + of traffic have their own specific mailing lists. + + The netdev list is managed (like many other linux mailing lists) through + VGER ( http://vger.kernel.org/ ) and archives can be found below: + + http://marc.info/?l=linux-netdev + http://www.spinics.net/lists/netdev/ + + Aside from subsystems like that mentioned above, all network related linux + development (i.e. RFC, review, comments, etc) takes place on netdev. + +Q: How do the changes posted to netdev make their way into linux? + +A: There are always two trees (git repositories) in play. Both are driven + by David Miller, the main network maintainer. There is the "net" tree, + and the "net-next" tree. As you can probably guess from the names, the + net tree is for fixes to existing code already in the mainline tree from + Linus, and net-next is where the new code goes for the future release. + You can find the trees here: + + http://git.kernel.org/?p=linux/kernel/git/davem/net.git + http://git.kernel.org/?p=linux/kernel/git/davem/net-next.git + +Q: How often do changes from these trees make it to the mainline Linus tree? + +A: To understand this, you need to know a bit of background information + on the cadence of linux development. Each new release starts off with + a two week "merge window" where the main maintainers feed their new + stuff to Linus for merging into the mainline tree. After the two weeks, + the merge window is closed, and it is called/tagged "-rc1". No new + features get mainlined after this -- only fixes to the rc1 content + are expected. After roughly a week of collecting fixes to the rc1 + content, rc2 is released. This repeats on a roughly weekly basis + until rc7 (typically; sometimes rc6 if things are quiet, or rc8 if + things are in a state of churn), and a week after the last vX.Y-rcN + was done, the official "vX.Y" is released. + + Relating that to netdev: At the beginning of the 2 week merge window, + the net-next tree will be closed - no new changes/features. The + accumulated new content of the past ~10 weeks will be passed onto + mainline/Linus via a pull request for vX.Y -- at the same time, + the "net" tree will start accumulating fixes for this pulled content + relating to vX.Y + + An announcement indicating when net-next has been closed is usually + sent to netdev, but knowing the above, you can predict that in advance. + + IMPORTANT: Do not send new net-next content to netdev during the + period during which net-next tree is closed. + + Shortly after the two weeks have passed, (and vX.Y-rc1 is released) the + tree for net-next reopens to collect content for the next (vX.Y+1) release. + + If you aren't subscribed to netdev and/or are simply unsure if net-next + has re-opened yet, simply check the net-next git repository link above for + any new networking related commits. + + The "net" tree continues to collect fixes for the vX.Y content, and + is fed back to Linus at regular (~weekly) intervals. Meaning that the + focus for "net" is on stablilization and bugfixes. + + Finally, the vX.Y gets released, and the whole cycle starts over. + +Q: So where are we now in this cycle? + +A: Load the mainline (Linus) page here: + + http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git + + and note the top of the "tags" section. If it is rc1, it is early + in the dev cycle. If it was tagged rc7 a week ago, then a release + is probably imminent. + +Q: How do I indicate which tree (net vs. net-next) my patch should be in? + +A: Firstly, think whether you have a bug fix or new "next-like" content. + Then once decided, assuming that you use git, use the prefix flag, i.e. + + git format-patch --subject-prefix='PATCH net-next' start..finish + + Use "net" instead of "net-next" (always lower case) in the above for + bug-fix net content. If you don't use git, then note the only magic in + the above is just the subject text of the outgoing e-mail, and you can + manually change it yourself with whatever MUA you are comfortable with. + +Q: I sent a patch and I'm wondering what happened to it. How can I tell + whether it got merged? + +A: Start by looking at the main patchworks queue for netdev: + + http://patchwork.ozlabs.org/project/netdev/list/ + + The "State" field will tell you exactly where things are at with + your patch. + +Q: The above only says "Under Review". How can I find out more? + +A: Generally speaking, the patches get triaged quickly (in less than 48h). + So be patient. Asking the maintainer for status updates on your + patch is a good way to ensure your patch is ignored or pushed to + the bottom of the priority list. + +Q: How can I tell what patches are queued up for backporting to the + various stable releases? + +A: Normally Greg Kroah-Hartman collects stable commits himself, but + for networking, Dave collects up patches he deems critical for the + networking subsystem, and then hands them off to Greg. + + There is a patchworks queue that you can see here: + http://patchwork.ozlabs.org/bundle/davem/stable/?state=* + + It contains the patches which Dave has selected, but not yet handed + off to Greg. If Greg already has the patch, then it will be here: + http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git + + A quick way to find whether the patch is in this stable-queue is + to simply clone the repo, and then git grep the mainline commit ID, e.g. + + stable-queue$ git grep -l 284041ef21fdf2e + releases/3.0.84/ipv6-fix-possible-crashes-in-ip6_cork_release.patch + releases/3.4.51/ipv6-fix-possible-crashes-in-ip6_cork_release.patch + releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch + stable/stable-queue$ + +Q: I see a network patch and I think it should be backported to stable. + Should I request it via "stable@vger.kernel.org" like the references in + the kernel's Documentation/stable_kernel_rules.txt file say? + +A: No, not for networking. Check the stable queues as per above 1st to see + if it is already queued. If not, then send a mail to netdev, listing + the upstream commit ID and why you think it should be a stable candidate. + + Before you jump to go do the above, do note that the normal stable rules + in Documentation/stable_kernel_rules.txt still apply. So you need to + explicitly indicate why it is a critical fix and exactly what users are + impacted. In addition, you need to convince yourself that you _really_ + think it has been overlooked, vs. having been considered and rejected. + + Generally speaking, the longer it has had a chance to "soak" in mainline, + the better the odds that it is an OK candidate for stable. So scrambling + to request a commit be added the day after it appears should be avoided. + +Q: I have created a network patch and I think it should be backported to + stable. Should I add a "Cc: stable@vger.kernel.org" like the references + in the kernel's Documentation/ directory say? + +A: No. See above answer. In short, if you think it really belongs in + stable, then ensure you write a decent commit log that describes who + gets impacted by the bugfix and how it manifests itself, and when the + bug was introduced. If you do that properly, then the commit will + get handled appropriately and most likely get put in the patchworks + stable queue if it really warrants it. + + If you think there is some valid information relating to it being in + stable that does _not_ belong in the commit log, then use the three + dash marker line as described in Documentation/SubmittingPatches to + temporarily embed that information into the patch that you send. + +Q: Someone said that the comment style and coding convention is different + for the networking content. Is this true? + +A: Yes, in a largely trivial way. Instead of this: + + /* + * foobar blah blah blah + * another line of text + */ + + it is requested that you make it look like this: + + /* foobar blah blah blah + * another line of text + */ + +Q: I am working in existing code that has the former comment style and not the + latter. Should I submit new code in the former style or the latter? + +A: Make it the latter style, so that eventually all code in the domain of + netdev is of this format. + +Q: I found a bug that might have possible security implications or similar. + Should I mail the main netdev maintainer off-list? + +A: No. The current netdev maintainer has consistently requested that people + use the mailing lists and not reach out directly. If you aren't OK with + that, then perhaps consider mailing "security@kernel.org" or reading about + http://oss-security.openwall.org/wiki/mailing-lists/distros + as possible alternative mechanisms. + +Q: What level of testing is expected before I submit my change? + +A: If your changes are against net-next, the expectation is that you + have tested by layering your changes on top of net-next. Ideally you + will have done run-time testing specific to your change, but at a + minimum, your changes should survive an "allyesconfig" and an + "allmodconfig" build without new warnings or failures. + +Q: Any other tips to help ensure my net/net-next patch gets OK'd? + +A: Attention to detail. Re-read your own work as if you were the + reviewer. You can start with using checkpatch.pl, perhaps even + with the "--strict" flag. But do not be mindlessly robotic in + doing so. If your change is a bug-fix, make sure your commit log + indicates the end-user visible symptom, the underlying reason as + to why it happens, and then if necessary, explain why the fix proposed + is the best way to get things done. Don't mangle whitespace, and as + is common, don't mis-indent function arguments that span multiple lines. + If it is your 1st patch, mail it to yourself so you can test apply + it to an unpatched tree to confirm infrastructure didn't mangle it. + + Finally, go back and read Documentation/SubmittingPatches to be + 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.: in_port(1), eth(...), eth_type(0x0800), ipv4(...), tcp(...) +Wildcarded flow key format +-------------------------- + +A wildcarded flow is described with two sequences of Netlink attributes +passed over the Netlink socket. A flow key, exactly as described above, and an +optional corresponding flow mask. + +A wildcarded flow can represent a group of exact match flows. Each '1' bit +in the mask specifies a exact match with the corresponding bit in the flow key. +A '0' bit specifies a don't care bit, which will match either a '1' or '0' bit +of a incoming packet. Using wildcarded flow can improve the flow set up rate +by reduce the number of new flows need to be processed by the user space program. + +Support for the mask Netlink attribute is optional for both the kernel and user +space program. The kernel can ignore the mask attribute, installing an exact +match flow, or reduce the number of don't care bits in the kernel to less than +what was specified by the user space program. In this case, variations in bits +that the kernel does not implement will simply result in additional flow setups. +The kernel module will also work with user space programs that neither support +nor supply flow mask attributes. + +Since the kernel may ignore or modify wildcard bits, it can be difficult for +the userspace program to know exactly what matches are installed. There are +two possible approaches: reactively install flows as they miss the kernel +flow table (and therefore not attempt to determine wildcard changes at all) +or use the kernel's response messages to determine the installed wildcards. + +When interacting with userspace, the kernel should maintain the match portion +of the key exactly as originally installed. This will provides a handle to +identify the flow for all future operations. However, when reporting the +mask of an installed flow, the mask should include any restrictions imposed +by the kernel. + +The behavior when using overlapping wildcarded flows is undefined. It is the +responsibility of the user space program to ensure that any incoming packet +can match at most one flow, wildcarded or not. The current implementation +performs best-effort detection of overlapping wildcarded flows and may reject +some but not all of them. However, this behavior may change in future versions. + + Basic rule for evolving flow keys --------------------------------- 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: In the AF_PACKET fanout mode, packet reception can be load balanced among processes. This also works in combination with mmap(2) on packet sockets. +Currently implemented fanout policies are: + + - PACKET_FANOUT_HASH: schedule to socket by skb's rxhash + - PACKET_FANOUT_LB: schedule to socket by round-robin + - PACKET_FANOUT_CPU: schedule to socket by CPU packet arrives on + - PACKET_FANOUT_RND: schedule to socket by random selection + - PACKET_FANOUT_ROLLOVER: if one socket is full, rollover to another + Minimal example code by David S. Miller (try things like "./test eth0 hash", "./test eth0 lb", etc.): 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 referred to as the UDP-style API of the Sockets Extensions for SCTP, as proposed in IETF Internet-Drafts. - Caveats: -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: http://www.sf.net/projects/lksctp Or contact the lksctp developers through the mailing list: - <lksctp-developers@lists.sourceforge.net> - - + <linux-sctp@vger.kernel.org> 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 { int bugged_jumbo; int pmt; int force_sf_dma_mode; + int force_thresh_dma_mode; int riwt_off; void (*fix_mac_speed)(void *priv, unsigned int speed); void (*bus_setup)(void __iomem *ioaddr); @@ -159,6 +160,8 @@ Where: o pmt: core has the embedded power module (optional). o force_sf_dma_mode: force DMA to use the Store and Forward mode instead of the Threshold. + o force_thresh_dma_mode: force DMA to use the Shreshold mode other than + the Store and Forward mode. o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode. o fix_mac_speed: this callback is used for modifying some syscfg registers (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 ========================= This feature adds Linux 2.2-like transparent proxy support to current kernels. -To use it, enable NETFILTER_TPROXY, the socket match and the TPROXY target in -your kernel config. You will need policy routing too, so be sure to enable that -as well. +To use it, enable the socket match and the TPROXY target in your kernel config. +You will need policy routing too, so be sure to enable that as well. 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) struct pinctrl_dev *pctl; pctl = pinctrl_register(&foo_desc, <PARENT>, NULL); - if (IS_ERR(pctl)) + if (!pctl) pr_err("could not register foo pin driver\n"); } @@ -795,18 +795,97 @@ special GPIO-handler is registered. GPIO mode pitfalls ================== -Sometime the developer may be confused by a datasheet talking about a pin -being possible to set into "GPIO mode". It appears that what hardware -engineers mean with "GPIO mode" is not necessarily the use case that is -implied in the kernel interface <linux/gpio.h>: a pin that you grab from -kernel code and then either listen for input or drive high/low to -assert/deassert some external line. +Due to the naming conventions used by hardware engineers, where "GPIO" +is taken to mean different things than what the kernel does, the developer +may be confused by a datasheet talking about a pin being possible to set +into "GPIO mode". It appears that what hardware engineers mean with +"GPIO mode" is not necessarily the use case that is implied in the kernel +interface <linux/gpio.h>: a pin that you grab from kernel code and then +either listen for input or drive high/low to assert/deassert some +external line. Rather hardware engineers think that "GPIO mode" means that you can software-control a few electrical properties of the pin that you would not be able to control if the pin was in some other mode, such as muxed in for a device. +The GPIO portions of a pin and its relation to a certain pin controller +configuration and muxing logic can be constructed in several ways. Here +are two examples: + +(A) + pin config + logic regs + | +- SPI + Physical pins --- pad --- pinmux -+- I2C + | +- mmc + | +- GPIO + pin + multiplex + logic regs + +Here some electrical properties of the pin can be configured no matter +whether the pin is used for GPIO or not. If you multiplex a GPIO onto a +pin, you can also drive it high/low from "GPIO" registers. +Alternatively, the pin can be controlled by a certain peripheral, while +still applying desired pin config properties. GPIO functionality is thus +orthogonal to any other device using the pin. + +In this arrangement the registers for the GPIO portions of the pin controller, +or the registers for the GPIO hardware module are likely to reside in a +separate memory range only intended for GPIO driving, and the register +range dealing with pin config and pin multiplexing get placed into a +different memory range and a separate section of the data sheet. + +(B) + + pin config + logic regs + | +- SPI + Physical pins --- pad --- pinmux -+- I2C + | | +- mmc + | | + GPIO pin + multiplex + logic regs + +In this arrangement, the GPIO functionality can always be enabled, such that +e.g. a GPIO input can be used to "spy" on the SPI/I2C/MMC signal while it is +pulsed out. It is likely possible to disrupt the traffic on the pin by doing +wrong things on the GPIO block, as it is never really disconnected. It is +possible that the GPIO, pin config and pin multiplex registers are placed into +the same memory range and the same section of the data sheet, although that +need not be the case. + +From a kernel point of view, however, these are different aspects of the +hardware and shall be put into different subsystems: + +- Registers (or fields within registers) that control electrical + properties of the pin such as biasing and drive strength should be + exposed through the pinctrl subsystem, as "pin configuration" settings. + +- Registers (or fields within registers) that control muxing of signals + from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should + be exposed through the pinctrl subssytem, as mux functions. + +- Registers (or fields within registers) that control GPIO functionality + such as setting a GPIO's output value, reading a GPIO's input value, or + setting GPIO pin direction should be exposed through the GPIO subsystem, + and if they also support interrupt capabilities, through the irqchip + abstraction. + +Depending on the exact HW register design, some functions exposed by the +GPIO subsystem may call into the pinctrl subsystem in order to +co-ordinate register settings across HW modules. In particular, this may +be needed for HW with separate GPIO and pin controller HW modules, where +e.g. GPIO direction is determined by a register in the pin controller HW +module rather than the GPIO HW module. + +Electrical properties of the pin such as biasing and drive strength +may be placed at some pin-specific register in all cases or as part +of the GPIO register in case (B) especially. This doesn't mean that such +properties necessarily pertain to what the Linux kernel calls "GPIO". + Example: a pin is usually muxed in to be used as a UART TX line. But during system sleep, we need to put this pin into "GPIO mode" and ground it. @@ -856,7 +935,7 @@ static unsigned long uart_sleep_mode[] = { PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0), }; -static struct pinctrl_map __initdata pinmap[] = { +static struct pinctrl_map pinmap[] __initdata = { PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "u0_group", "u0"), 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 it even more compact which assumes you want to use pinctrl-foo and position 0 for mapping, for example: -static struct pinctrl_map __initdata mapping[] = { +static struct pinctrl_map mapping[] __initdata = { PIN_MAP_MUX_GROUP("foo-i2c.o", PINCTRL_STATE_DEFAULT, "pinctrl-foo", NULL, "i2c0"), }; @@ -970,7 +1049,7 @@ static unsigned long i2c_pin_configs[] = { FOO_SLEW_RATE_SLOW, }; -static struct pinctrl_map __initdata mapping[] = { +static struct pinctrl_map mapping[] __initdata = { PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", "i2c0"), PIN_MAP_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", i2c_grp_configs), 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 be empty. Table entry macro PIN_MAP_DUMMY_STATE serves the purpose of defining a named state without causing any pin controller to be programmed: -static struct pinctrl_map __initdata mapping[] = { +static struct pinctrl_map mapping[] __initdata = { PIN_MAP_DUMMY_STATE("foo-i2c.0", PINCTRL_STATE_DEFAULT), }; diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 3e8cb73ac43c..9552a3299ec9 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt @@ -168,6 +168,15 @@ UUID/GUID addresses: Where no additional specifiers are used the default little endian order with lower case hex characters will be printed. +dentry names: + %pd{,2,3,4} + %pD{,2,3,4} + + For printing dentry name; if we race with d_move(), the name might be + a mix of old and new ones, but it won't oops. %pd dentry is a safer + equivalent of %s dentry->d_name.name we used to use, %pd<n> prints + n last components. %pD does the same thing for struct file. + struct va_format: %pV 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 @@ -Copyright (c) 2003-2012 QLogic Corporation +Copyright (c) 2003-2013 QLogic Corporation QLogic Linux iSCSI Driver This program includes a device driver for Linux 3.x. 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 5stack-no-fp D965 5stack without front panel dell-3stack Dell Dimension E520 dell-bios Fixes with Dell BIOS setup + dell-bios-amic Fixes with Dell BIOS setup including analog mic volknob Fixes with volume-knob widget 0x24 auto BIOS setup (default) 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: - need_dac_fix (bool): limits the DACs depending on the channel count - primary_hp (bool): probe headphone jacks as the primary outputs; default true +- multi_io (bool): try probing multi-I/O config (e.g. shared + line-in/surround, mic/clfe jacks) - multi_cap_vol (bool): provide multiple capture volumes - inv_dmic_split (bool): provide split internal mic volume/switch for phase-inverted digital mics 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: /* if your mach-* infrastructure doesn't support kernels that can * run on multiple boards, pdata wouldn't benefit from "__init". */ - static struct mysoc_spi_data __initdata pdata = { ... }; + static struct mysoc_spi_data pdata __initdata = { ... }; static __init board_init(void) { diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index 1c15043aaee4..9a0319a82470 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -50,9 +50,22 @@ The maximum number of packets that kernel can handle on a NAPI interrupt, it's a Per-CPU variable. Default: 64 +default_qdisc +-------------- + +The default queuing discipline to use for network devices. This allows +overriding the default queue discipline of pfifo_fast with an +alternative. Since the default queuing discipline is created with the +no additional parameters so is best suited to queuing disciplines that +work well without configuration like stochastic fair queue (sfq), +CoDel (codel) or fair queue CoDel (fq_codel). Don't use queuing disciplines +like Hierarchical Token Bucket or Deficit Round Robin which require setting +up classes and bandwidths. +Default: pfifo_fast + busy_read ---------------- -Low latency busy poll timeout for socket reads. (needs CONFIG_NET_LL_RX_POLL) +Low latency busy poll timeout for socket reads. (needs CONFIG_NET_RX_BUSY_POLL) Approximate time in us to busy loop waiting for packets on the device queue. This sets the default value of the SO_BUSY_POLL socket option. Can be set or overridden per socket by setting socket option SO_BUSY_POLL, @@ -63,7 +76,7 @@ Default: 0 (off) busy_poll ---------------- -Low latency busy poll timeout for poll and select. (needs CONFIG_NET_LL_RX_POLL) +Low latency busy poll timeout for poll and select. (needs CONFIG_NET_RX_BUSY_POLL) Approximate time in us to busy loop waiting for events. Recommended value depends on the number of sockets you poll on. For several sockets 50, for several hundreds 100. 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 workloads, you will normally -not- want this option. These three cases are described in the following three sections, followed -by a third section on RCU-specific considerations and a fourth and final -section listing known issues. +by a third section on RCU-specific considerations, a fourth section +discussing testing, and a fifth and final section listing known issues. NEVER OMIT SCHEDULING-CLOCK TICKS @@ -121,14 +121,15 @@ boot parameter specifies the adaptive-ticks CPUs. For example, "nohz_full=1,6-8" says that CPUs 1, 6, 7, and 8 are to be adaptive-ticks CPUs. Note that you are prohibited from marking all of the CPUs as adaptive-tick CPUs: At least one non-adaptive-tick CPU must remain -online to handle timekeeping tasks in order to ensure that system calls -like gettimeofday() returns accurate values on adaptive-tick CPUs. -(This is not an issue for CONFIG_NO_HZ_IDLE=y because there are no -running user processes to observe slight drifts in clock rate.) -Therefore, the boot CPU is prohibited from entering adaptive-ticks -mode. Specifying a "nohz_full=" mask that includes the boot CPU will -result in a boot-time error message, and the boot CPU will be removed -from the mask. +online to handle timekeeping tasks in order to ensure that system +calls like gettimeofday() returns accurate values on adaptive-tick CPUs. +(This is not an issue for CONFIG_NO_HZ_IDLE=y because there are no running +user processes to observe slight drifts in clock rate.) Therefore, the +boot CPU is prohibited from entering adaptive-ticks mode. Specifying a +"nohz_full=" mask that includes the boot CPU will result in a boot-time +error message, and the boot CPU will be removed from the mask. Note that +this means that your system must have at least two CPUs in order for +CONFIG_NO_HZ_FULL=y to do anything for you. Alternatively, the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter specifies 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 where you want them to run. +TESTING + +So you enable all the OS-jitter features described in this document, +but do not see any change in your workload's behavior. Is this because +your workload isn't affected that much by OS jitter, or is it because +something else is in the way? This section helps answer this question +by providing a simple OS-jitter test suite, which is available on branch +master of the following git archive: + +git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git + +Clone this archive and follow the instructions in the README file. +This test procedure will produce a trace that will allow you to evaluate +whether or not you have succeeded in removing OS jitter from your system. +If this trace shows that you have removed OS jitter as much as is +possible, then you can conclude that your workload is not all that +sensitive to OS jitter. + +Note: this test requires that your system have at least two CPUs. +We do not currently have a good way to remove OS jitter from single-CPU +systems. + + KNOWN ISSUES 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 @@ +Virtual TPM interface for Xen + +Authors: Matthew Fioravante (JHUAPL), Daniel De Graaf (NSA) + +This document describes the virtual Trusted Platform Module (vTPM) subsystem for +Xen. The reader is assumed to have familiarity with building and installing Xen, +Linux, and a basic understanding of the TPM and vTPM concepts. + +INTRODUCTION + +The goal of this work is to provide a TPM functionality to a virtual guest +operating system (in Xen terms, a DomU). This allows programs to interact with +a TPM in a virtual system the same way they interact with a TPM on the physical +system. Each guest gets its own unique, emulated, software TPM. However, each +of the vTPM's secrets (Keys, NVRAM, etc) are managed by a vTPM Manager domain, +which seals the secrets to the Physical TPM. If the process of creating each of +these domains (manager, vTPM, and guest) is trusted, the vTPM subsystem extends +the chain of trust rooted in the hardware TPM to virtual machines in Xen. Each +major component of vTPM is implemented as a separate domain, providing secure +separation guaranteed by the hypervisor. The vTPM domains are implemented in +mini-os to reduce memory and processor overhead. + +This mini-os vTPM subsystem was built on top of the previous vTPM work done by +IBM and Intel corporation. + + +DESIGN OVERVIEW +--------------- + +The architecture of vTPM is described below: + ++------------------+ +| Linux DomU | ... +| | ^ | +| v | | +| xen-tpmfront | ++------------------+ + | ^ + v | ++------------------+ +| mini-os/tpmback | +| | ^ | +| v | | +| vtpm-stubdom | ... +| | ^ | +| v | | +| mini-os/tpmfront | ++------------------+ + | ^ + v | ++------------------+ +| mini-os/tpmback | +| | ^ | +| v | | +| vtpmmgr-stubdom | +| | ^ | +| v | | +| mini-os/tpm_tis | ++------------------+ + | ^ + v | ++------------------+ +| Hardware TPM | ++------------------+ + + * Linux DomU: The Linux based guest that wants to use a vTPM. There may be + more than one of these. + + * xen-tpmfront.ko: Linux kernel virtual TPM frontend driver. This driver + provides vTPM access to a Linux-based DomU. + + * mini-os/tpmback: Mini-os TPM backend driver. The Linux frontend driver + connects to this backend driver to facilitate communications + between the Linux DomU and its vTPM. This driver is also + used by vtpmmgr-stubdom to communicate with vtpm-stubdom. + + * vtpm-stubdom: A mini-os stub domain that implements a vTPM. There is a + one to one mapping between running vtpm-stubdom instances and + logical vtpms on the system. The vTPM Platform Configuration + Registers (PCRs) are normally all initialized to zero. + + * mini-os/tpmfront: Mini-os TPM frontend driver. The vTPM mini-os domain + vtpm-stubdom uses this driver to communicate with + vtpmmgr-stubdom. This driver is also used in mini-os + domains such as pv-grub that talk to the vTPM domain. + + * vtpmmgr-stubdom: A mini-os domain that implements the vTPM manager. There is + only one vTPM manager and it should be running during the + entire lifetime of the machine. This domain regulates + access to the physical TPM on the system and secures the + persistent state of each vTPM. + + * mini-os/tpm_tis: Mini-os TPM version 1.2 TPM Interface Specification (TIS) + driver. This driver used by vtpmmgr-stubdom to talk directly to + the hardware TPM. Communication is facilitated by mapping + hardware memory pages into vtpmmgr-stubdom. + + * Hardware TPM: The physical TPM that is soldered onto the motherboard. + + +INTEGRATION WITH XEN +-------------------- + +Support for the vTPM driver was added in Xen using the libxl toolstack in Xen +4.3. See the Xen documentation (docs/misc/vtpm.txt) for details on setting up +the vTPM and vTPM Manager stub domains. Once the stub domains are running, a +vTPM device is set up in the same manner as a disk or network device in the +domain's configuration file. + +In order to use features such as IMA that require a TPM to be loaded prior to +the initrd, the xen-tpmfront driver must be compiled in to the kernel. If not +using such features, the driver can be compiled as a module and will be loaded +as usual. 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. The handler is of the following type: - typedef void (*usb_complete_t)(struct urb *, struct pt_regs *) + typedef void (*usb_complete_t)(struct urb *) -I.e., it gets the URB that caused the completion call, plus the -register values at the time of the corresponding interrupt (if any). -In the completion handler, you should have a look at urb->status to -detect any USB errors. Since the context parameter is included in the URB, -you can pass information to the completion handler. +I.e., it gets the URB that caused the completion call. In the completion +handler, you should have a look at urb->status to detect any USB errors. +Since the context parameter is included in the URB, you can pass +information to the completion handler. Note that even when an error (or unlink) is reported, data may have been transferred. That's because USB transfers are packetized; it might take @@ -210,12 +209,12 @@ have transferred successfully before the completion was called. NOTE: ***** WARNING ***** -NEVER SLEEP IN A COMPLETION HANDLER. These are normally called -during hardware interrupt processing. If you can, defer substantial -work to a tasklet (bottom half) to keep system latencies low. You'll -probably need to use spinlocks to protect data structures you manipulate -in completion handlers. +NEVER SLEEP IN A COMPLETION HANDLER. These are often called in atomic +context. +In the current kernel, completion handlers run with local interrupts +disabled, but in the future this will be changed, so don't assume that +local IRQs are always disabled inside completion handlers. 1.8. How to do isochronous (ISO) transfers? 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. These files can be read as binary data. The binary data consists of first the device descriptor, then the descriptors for each -configuration of the device. Multi-byte fields in the device and -configuration descriptors, but not other descriptors, are converted -to host endianness by the kernel. This information is also shown +configuration of the device. Multi-byte fields in the device descriptor +are converted to host endianness by the kernel. The configuration +descriptors are in bus endian format! The configuration descriptor +are wTotalLength bytes apart. If a device returns less configuration +descriptor data than indicated by wTotalLength there will be a hole in +the file for the missing bytes. This information is also shown in text form by the /proc/bus/usb/devices file, described later. 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: const struct v4l2_ctrl_ops *ops, u32 id, s32 min, s32 max, u32 step, s32 def); -Menu controls are added by calling v4l2_ctrl_new_std_menu: +Menu and integer menu controls are added by calling v4l2_ctrl_new_std_menu: struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl, const struct v4l2_ctrl_ops *ops, u32 id, s32 max, s32 skip_mask, s32 def); -Or alternatively for integer menu controls, by calling v4l2_ctrl_new_int_menu: +Menu controls with a driver specific menu are added by calling +v4l2_ctrl_new_std_menu_items: + + struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items( + struct v4l2_ctrl_handler *hdl, + const struct v4l2_ctrl_ops *ops, u32 id, s32 max, + s32 skip_mask, s32 def, const char * const *qmenu); + +Integer menu controls with a driver specific menu can be added by calling +v4l2_ctrl_new_int_menu: struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl, const struct v4l2_ctrl_ops *ops, u32 id, s32 max, s32 def, const s64 *qmenu_int); -Standard menu controls with a driver specific menu are added by calling -v4l2_ctrl_new_std_menu_items: - - struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items( - struct v4l2_ctrl_handler *hdl, - const struct v4l2_ctrl_ops *ops, u32 id, s32 max, - s32 skip_mask, s32 def, const char * const *qmenu); - These functions are typically called right after the v4l2_ctrl_handler_init: static const s64 exp_bias_qmenu[] = { 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 KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by || || writing to msr 0x4b564d02 ------------------------------------------------------------------------------ +KVM_FEATURE_PV_UNHALT || 7 || guest checks this feature bit + || || before enabling paravirtualized + || || spinlock support. +------------------------------------------------------------------------------ KVM_FEATURE_CLOCKSOURCE_STABLE_BIT || 24 || host will warn if no guest-side || || per-cpu warps are expected in || || 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 shared page that contains parts of supervisor visible register state. The guest can map this shared page to access its supervisor register through memory using this hypercall. + +5. KVM_HC_KICK_CPU +------------------------ +Architecture: x86 +Status: active +Purpose: Hypercall used to wakeup a vcpu from HLT state +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest +kernel mode for an event to occur (ex: a spinlock to become available) can +execute HLT instruction once it has busy-waited for more than a threshold +time-interval. Execution of HLT instruction would cause the hypervisor to put +the vcpu to sleep until occurence of an appropriate event. Another vcpu of the +same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall, +specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0) +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. Special purpose threads, called worker threads, execute the functions off of the queue, one after the other. If no work is queued, the worker threads become idle. These worker threads are managed in so -called thread-pools. +called worker-pools. The cmwq design differentiates between the user-facing workqueues that subsystems and drivers queue work items on and the backend mechanism -which manages thread-pools and processes the queued work items. +which manages worker-pools and processes the queued work items. -The backend is called gcwq. There is one gcwq for each possible CPU -and one gcwq to serve work items queued on unbound workqueues. Each -gcwq has two thread-pools - one for normal work items and the other -for high priority ones. +There are two worker-pools, one for normal work items and the other +for high priority ones, for each possible CPU and some extra +worker-pools to serve work items queued on unbound workqueues - the +number of these backing pools is dynamic. Subsystems and drivers can create and queue work items through special workqueue API functions as they see fit. They can influence some aspects of the way the work items are executed by setting flags on the workqueue they are putting the work item on. These flags include -things like CPU locality, reentrancy, concurrency limits, priority and -more. To get a detailed overview refer to the API description of +things like CPU locality, concurrency limits, priority and more. To +get a detailed overview refer to the API description of alloc_workqueue() below. -When a work item is queued to a workqueue, the target gcwq and -thread-pool is determined according to the queue parameters and -workqueue attributes and appended on the shared worklist of the -thread-pool. For example, unless specifically overridden, a work item -of a bound workqueue will be queued on the worklist of either normal -or highpri thread-pool of the gcwq that is associated to the CPU the -issuer is running on. +When a work item is queued to a workqueue, the target worker-pool is +determined according to the queue parameters and workqueue attributes +and appended on the shared worklist of the worker-pool. For example, +unless specifically overridden, a work item of a bound workqueue will +be queued on the worklist of either normal or highpri worker-pool that +is associated to the CPU the issuer is running on. For any worker pool implementation, managing the concurrency level (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. Minimal to save resources and sufficient in that the system is used at its full capacity. -Each thread-pool bound to an actual CPU implements concurrency -management by hooking into the scheduler. The thread-pool is notified +Each worker-pool bound to an actual CPU implements concurrency +management by hooking into the scheduler. The worker-pool is notified whenever an active worker wakes up or sleeps and keeps track of the number of the currently runnable workers. Generally, work items are not expected to hog a CPU and consume many cycles. That means maintaining just enough concurrency to prevent work processing from stalling should be optimal. As long as there are one or more runnable -workers on the CPU, the thread-pool doesn't start execution of a new +workers on the CPU, the worker-pool doesn't start execution of a new work, but, when the last running worker goes to sleep, it immediately schedules a new worker so that the CPU doesn't sit idle while there 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 for kthreads, so cmwq holds onto idle ones for a while before killing them. -For an unbound wq, the above concurrency management doesn't apply and -the thread-pools for the pseudo unbound CPU try to start executing all -work items as soon as possible. The responsibility of regulating -concurrency level is on the users. There is also a flag to mark a -bound wq to ignore the concurrency management. Please refer to the -API section for details. +For unbound workqueues, the number of backing pools is dynamic. +Unbound workqueue can be assigned custom attributes using +apply_workqueue_attrs() and workqueue will automatically create +backing worker pools matching the attributes. The responsibility of +regulating concurrency level is on the users. There is also a flag to +mark a bound wq to ignore the concurrency management. Please refer to +the API section for details. Forward progress guarantee relies on that workers can be created when more execution contexts are necessary, which in turn is guaranteed through the use of rescue workers. All work items which might be used on code paths that handle memory reclaim are required to be queued on wq's that have a rescue-worker reserved for execution under memory -pressure. Else it is possible that the thread-pool deadlocks waiting +pressure. Else it is possible that the worker-pool deadlocks waiting for execution contexts to free up. @@ -166,25 +166,15 @@ resources, scheduled and executed. @flags: - WQ_NON_REENTRANT - - By default, a wq guarantees non-reentrance only on the same - CPU. A work item may not be executed concurrently on the same - CPU by multiple workers but is allowed to be executed - concurrently on multiple CPUs. This flag makes sure - non-reentrance is enforced across all CPUs. Work items queued - to a non-reentrant wq are guaranteed to be executed by at most - one worker system-wide at any given time. - WQ_UNBOUND - Work items queued to an unbound wq are served by a special - gcwq which hosts workers which are not bound to any specific - CPU. This makes the wq behave as a simple execution context - provider without concurrency management. The unbound gcwq - tries to start execution of work items as soon as possible. - Unbound wq sacrifices locality but is useful for the following - cases. + Work items queued to an unbound wq are served by the special + woker-pools which host workers which are not bound to any + specific CPU. This makes the wq behave as a simple execution + context provider without concurrency management. The unbound + worker-pools try to start execution of work items as soon as + possible. Unbound wq sacrifices locality but is useful for + the following cases. * Wide fluctuation in the concurrency level requirement is expected and using bound wq may end up creating large number @@ -209,10 +199,10 @@ resources, scheduled and executed. WQ_HIGHPRI Work items of a highpri wq are queued to the highpri - thread-pool of the target gcwq. Highpri thread-pools are + worker-pool of the target cpu. Highpri worker-pools are served by worker threads with elevated nice level. - Note that normal and highpri thread-pools don't interact with + Note that normal and highpri worker-pools don't interact with each other. Each maintain its separate pool of workers and implements concurrency management among its workers. @@ -221,7 +211,7 @@ resources, scheduled and executed. Work items of a CPU intensive wq do not contribute to the concurrency level. In other words, runnable CPU intensive work items will not prevent other work items in the same - thread-pool from starting execution. This is useful for bound + worker-pool from starting execution. This is useful for bound work items which are expected to hog CPU cycles so that their execution is regulated by the system scheduler. @@ -233,6 +223,10 @@ resources, scheduled and executed. This flag is meaningless for unbound wq. +Note that the flag WQ_NON_REENTRANT no longer exists as all workqueues +are now non-reentrant - any work item is guaranteed to be executed by +at most one worker system-wide at any given time. + @max_active: @max_active determines the maximum number of execution contexts per @@ -254,9 +248,9 @@ recommended. Some users depend on the strict execution ordering of ST wq. The combination of @max_active of 1 and WQ_UNBOUND is used to achieve this -behavior. Work items on such wq are always queued to the unbound gcwq -and only one work item can be active at any given time thus achieving -the same ordering property as ST wq. +behavior. Work items on such wq are always queued to the unbound +worker-pools and only one work item can be active at any given time thus +achieving the same ordering property as ST wq. 5. Example Execution Scenarios 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 acpi=noirq Don't route interrupts + acpi=nocmcff Disable firmware first mode for corrected errors. This + disables parsing the HEST CMC error source to check if + firmware has set the FF flag. This may result in + duplicate corrected error reports. + PCI pci=off Don't use PCI |