diff options
Diffstat (limited to 'Documentation')
196 files changed, 4486 insertions, 902 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 0c4cc688e89a..38f8444bdd0e 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -40,7 +40,7 @@ IPMI.txt IRQ-affinity.txt - how to select which CPU(s) handle which interrupt events on SMP. IRQ-domain.txt - - info on inerrupt numbering and setting up IRQ domains. + - info on interrupt numbering and setting up IRQ domains. IRQ.txt - description of what an IRQ is. Intel-IOMMU.txt diff --git a/Documentation/ABI/testing/sysfs-block-zram b/Documentation/ABI/testing/sysfs-block-zram index ec93fe33baa6..3f0b9ae61d8c 100644 --- a/Documentation/ABI/testing/sysfs-block-zram +++ b/Documentation/ABI/testing/sysfs-block-zram @@ -5,20 +5,21 @@ Description: The disksize file is read-write and specifies the disk size which represents the limit on the *uncompressed* worth of data that can be stored in this disk. + Unit: bytes What: /sys/block/zram<id>/initstate Date: August 2010 Contact: Nitin Gupta <ngupta@vflare.org> Description: - The disksize file is read-only and shows the initialization + The initstate file is read-only and shows the initialization state of the device. What: /sys/block/zram<id>/reset Date: August 2010 Contact: Nitin Gupta <ngupta@vflare.org> Description: - The disksize file is write-only and allows resetting the - device. The reset operation frees all the memory assocaited + The reset file is write-only and allows resetting the + device. The reset operation frees all the memory associated with this device. What: /sys/block/zram<id>/num_reads @@ -48,7 +49,7 @@ Contact: Nitin Gupta <ngupta@vflare.org> Description: The notify_free file is read-only and specifies the number of swap slot free notifications received by this device. These - notifications are send to a swap block device when a swap slot + notifications are sent to a swap block device when a swap slot is freed. This statistic is applicable only when this disk is being used as a swap disk. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs new file mode 100644 index 000000000000..31942efcaf0e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -0,0 +1,26 @@ +What: /sys/fs/f2fs/<disk>/gc_max_sleep_time +Date: July 2013 +Contact: "Namjae Jeon" <namjae.jeon@samsung.com> +Description: + Controls the maximun sleep time for gc_thread. Time + is in milliseconds. + +What: /sys/fs/f2fs/<disk>/gc_min_sleep_time +Date: July 2013 +Contact: "Namjae Jeon" <namjae.jeon@samsung.com> +Description: + Controls the minimum sleep time for gc_thread. Time + is in milliseconds. + +What: /sys/fs/f2fs/<disk>/gc_no_gc_sleep_time +Date: July 2013 +Contact: "Namjae Jeon" <namjae.jeon@samsung.com> +Description: + Controls the default sleep time for gc_thread. Time + is in milliseconds. + +What: /sys/fs/f2fs/<disk>/gc_idle +Date: July 2013 +Contact: "Namjae Jeon" <namjae.jeon@samsung.com> +Description: + Controls the victim selection policy for garbage collection. diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 49267ea97568..f403ec3c5c9a 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -325,6 +325,7 @@ <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/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/v4l/vidioc-g-parm.xml b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml index 9058224d1bbf..f4e28e7d4751 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-parm.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml @@ -132,7 +132,7 @@ devices.</para> <row> <entry>&v4l2-fract;</entry> <entry><structfield>timeperframe</structfield></entry> - <entry><para>This is is the desired period between + <entry><para>This is the desired period between successive frames captured by the driver, in seconds. The field is intended to skip frames on the driver side, saving I/O bandwidth.</para><para>Applications store here the desired frame @@ -193,7 +193,7 @@ applications must set the array to zero.</entry> <row> <entry>&v4l2-fract;</entry> <entry><structfield>timeperframe</structfield></entry> - <entry>This is is the desired period between + <entry>This is the desired period between successive frames output by the driver, in seconds.</entry> </row> <row> diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 9c92bb879b6d..4c8d282545a2 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -22,8 +22,14 @@ <!-- 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/IRQ-affinity.txt b/Documentation/IRQ-affinity.txt index 7890fae18529..01a675175a36 100644 --- a/Documentation/IRQ-affinity.txt +++ b/Documentation/IRQ-affinity.txt @@ -57,8 +57,8 @@ i.e counters for the CPU0-3 did not change. Here is an example of limiting that same irq (44) to cpus 1024 to 1031: -[root@moon 44]# echo 1024-1031 > smp_affinity -[root@moon 44]# cat smp_affinity +[root@moon 44]# echo 1024-1031 > smp_affinity_list +[root@moon 44]# cat smp_affinity_list 1024-1031 Note that to do this with a bitmask would require 32 bitmasks of zero diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 6e97e73d87b5..26b1e31d5a13 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -109,6 +109,16 @@ probably didn't even receive earlier versions of the patch. If the patch fixes a logged bug entry, refer to that bug entry by number and URL. +If you want to refer to a specific commit, don't just refer to the +SHA-1 ID of the commit. Please also include the oneline summary of +the commit, to make it easier for reviewers to know what it is about. +Example: + + Commit e21d2170f36602ae2708 ("video: remove unnecessary + platform_set_drvdata()") removed the unnecessary + platform_set_drvdata(), but left the variable "dev" unused, + delete it. + 3) Separate your changes. diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a97dff3..aca4e69121b7 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -207,7 +207,7 @@ passing those. One idea is to return this in _DSM method like: Return (Local0) } -Then the at25 SPI driver can get this configation by calling _DSM on its +Then the at25 SPI driver can get this configuration by calling _DSM on its ACPI handle like: struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL }; @@ -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/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm index 9012bb039094..4ae915a9f899 100644 --- a/Documentation/arm/OMAP/omap_pm +++ b/Documentation/arm/OMAP/omap_pm @@ -78,7 +78,7 @@ to NULL. Drivers should use the following idiom: The most common usage of these functions will probably be to specify the maximum time from when an interrupt occurs, to when the device becomes accessible. To accomplish this, driver writers should use the -set_max_mpu_wakeup_lat() function to to constrain the MPU wakeup +set_max_mpu_wakeup_lat() function to constrain the MPU wakeup latency, and the set_max_dev_wakeup_lat() function to constrain the device wakeup latency (from clk_enable() to accessibility). For example, diff --git a/Documentation/arm/kernel_mode_neon.txt b/Documentation/arm/kernel_mode_neon.txt new file mode 100644 index 000000000000..525452726d31 --- /dev/null +++ b/Documentation/arm/kernel_mode_neon.txt @@ -0,0 +1,121 @@ +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/arm64/booting.txt b/Documentation/arm64/booting.txt index 9c4d388daddc..98df4a03807e 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -45,9 +45,9 @@ sees fit.) Requirement: MANDATORY -The device tree blob (dtb) must be no bigger than 2 megabytes in size -and placed at a 2-megabyte boundary within the first 512 megabytes from -the start of the kernel image. This is to allow the kernel to map the +The device tree blob (dtb) must be placed on an 8-byte boundary within +the first 512 megabytes from the start of the kernel image and must not +cross a 2-megabyte boundary. This is to allow the kernel to map the blob using a single section mapping in the initial page tables. @@ -68,13 +68,23 @@ Image target is available instead. Requirement: MANDATORY -The decompressed kernel image contains a 32-byte header as follows: +The decompressed kernel image contains a 64-byte header as follows: - u32 magic = 0x14000008; /* branch to stext, little-endian */ - u32 res0 = 0; /* reserved */ + u32 code0; /* Executable code */ + u32 code1; /* Executable code */ u64 text_offset; /* Image load offset */ + u64 res0 = 0; /* reserved */ u64 res1 = 0; /* reserved */ u64 res2 = 0; /* reserved */ + u64 res3 = 0; /* reserved */ + u64 res4 = 0; /* reserved */ + u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ + u32 res5 = 0; /* reserved */ + + +Header notes: + +- code0/code1 are responsible for branching to stext. The image must be placed at the specified offset (currently 0x80000) from the start of the system RAM and called there. The start of the diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt new file mode 100644 index 000000000000..264e9841563a --- /dev/null +++ b/Documentation/arm64/tagged-pointers.txt @@ -0,0 +1,34 @@ + Tagged virtual addresses in AArch64 Linux + ========================================= + +Author: Will Deacon <will.deacon@arm.com> +Date : 12 June 2013 + +This document briefly describes the provision of tagged virtual +addresses in the AArch64 translation system and their potential uses +in AArch64 Linux. + +The kernel configures the translation tables so that translations made +via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of +the virtual address ignored by the translation hardware. This frees up +this byte for application use, with the following caveats: + + (1) The kernel requires that all user addresses passed to EL1 + are tagged with tag 0x00. This means that any syscall + parameters containing user virtual addresses *must* have + their top byte cleared before trapping to the kernel. + + (2) Tags are not guaranteed to be preserved when delivering + signals. This means that signal handlers in applications + making use of tags cannot rely on the tag information for + user virtual addresses being maintained for fields inside + siginfo_t. One exception to this rule is for signals raised + in response to debug exceptions, where the tag information + will be preserved. + + (3) Special care should be taken when using tagged pointers, + since it is likely that C compilers will not hazard two + addresses differing only in the upper bits. + +The architecture prevents the use of a tagged PC, so the upper byte will +be set to a sign-extension of bit 55 on exception return. diff --git a/Documentation/block/cfq-iosched.txt b/Documentation/block/cfq-iosched.txt index 9887f0414c16..f3bc72945cbd 100644 --- a/Documentation/block/cfq-iosched.txt +++ b/Documentation/block/cfq-iosched.txt @@ -69,7 +69,7 @@ one, this value should be decreased relative to fifo_expire_async. group_idle ----------- This parameter forces idling at the CFQ group level instead of CFQ -queue level. This was introduced after after a bottleneck was observed +queue level. This was introduced after a bottleneck was observed in higher end storage due to idle on sequential queue and allow dispatch from a single queue. The idea with this parameter is that it can be run with slice_idle=0 and group_idle=8, so that idling does not happen on individual diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt index 9b728dc17535..d79b008e4a32 100644 --- a/Documentation/cachetlb.txt +++ b/Documentation/cachetlb.txt @@ -57,7 +57,7 @@ changes occur: interface must make sure that any previous page table modifications for the address space 'vma->vm_mm' in the range 'start' to 'end-1' will be visible to the cpu. That is, after - running, here will be no entries in the TLB for 'mm' for + running, there will be no entries in the TLB for 'mm' for virtual addresses in the range 'start' to 'end-1'. The "vma" is the backing store being used for the region. @@ -375,8 +375,8 @@ maps this page at its virtual address. void flush_icache_page(struct vm_area_struct *vma, struct page *page) All the functionality of flush_icache_page can be implemented in - flush_dcache_page and update_mmu_cache. In 2.7 the hope is to - remove this interface completely. + flush_dcache_page and update_mmu_cache. In the future, the hope + is to remove this interface completely. The final category of APIs is for I/O to deliberately aliased address ranges inside the kernel. Such aliases are set up by use of the diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index 902d3151f527..0aad6deb2d96 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt @@ -22,7 +22,7 @@ to /proc/cpuinfo. 4) /sys/devices/system/cpu/cpuX/topology/thread_siblings: - internel kernel map of cpuX's hardware threads within the same + internal kernel map of cpuX's hardware threads within the same core as cpuX 5) /sys/devices/system/cpu/cpuX/topology/core_siblings: diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index 4823577c6509..2e0617936e8f 100644 --- a/Documentation/development-process/2.Process +++ b/Documentation/development-process/2.Process @@ -276,7 +276,7 @@ mainline get there via -mm. The current -mm patch is available in the "mmotm" (-mm of the moment) directory at: - http://userweb.kernel.org/~akpm/mmotm/ + http://www.ozlabs.org/~akpm/mmotm/ Use of the MMOTM tree is likely to be a frustrating experience, though; there is a definite chance that it will not even compile. @@ -287,7 +287,7 @@ the mainline is expected to look like after the next merge window closes. Linux-next trees are announced on the linux-kernel and linux-next mailing lists when they are assembled; they can be downloaded from: - http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/ + http://www.kernel.org/pub/linux/kernel/next/ Some information about linux-next has been gathered at: diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt index fb7b5cd2652f..0ff6560e6094 100644 --- a/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt +++ b/Documentation/devicetree/bindings/arm/bcm/bcm11351.txt @@ -6,4 +6,5 @@ bcm11351, bcm28145, bcm28155 SoCs) shall have the following properties: Required root node property: -compatible = "bcm,bcm11351"; +compatible = "brcm,bcm11351"; +DEPRECATED: compatible = "bcm,bcm11351"; diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt b/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt index 59fa6e68d4f6..17d88b233d1b 100644 --- a/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt +++ b/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt @@ -4,14 +4,15 @@ This timer is used in the following Broadcom SoCs: BCM11130, BCM11140, BCM11351, BCM28145, BCM28155 Required properties: -- compatible : "bcm,kona-timer" +- compatible : "brcm,kona-timer" +- DEPRECATED: compatible : "bcm,kona-timer" - reg : Register range for the timer - interrupts : interrupt for the timer - clock-frequency: frequency that the clock operates Example: timer@35006000 { - compatible = "bcm,kona-timer"; + compatible = "brcm,kona-timer"; reg = <0x35006000 0x1000>; interrupts = <0x0 7 0x4>; clock-frequency = <32768>; diff --git a/Documentation/devicetree/bindings/arm/bcm/kona-wdt.txt b/Documentation/devicetree/bindings/arm/bcm/kona-wdt.txt new file mode 100644 index 000000000000..2b86a00e351d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/kona-wdt.txt @@ -0,0 +1,15 @@ +Broadcom Kona Family Watchdog Timer +----------------------------------- + +This watchdog timer is used in the following Broadcom SoCs: + BCM11130, BCM11140, BCM11351, BCM28145, BCM28155 + +Required properties: + - compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt"; + - reg: memory address & range + +Example: + watchdog@35002f40 { + compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt"; + reg = <0x35002f40 0x6c>; + }; 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/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index 6d498c758b45..91b7049affa1 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -59,3 +59,6 @@ Boards: - AM43x EPOS EVM compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43" + +- DRA7 EVM: Software Developement Board for DRA7XX + compatible = "ti,dra7-evm", "ti,dra7" diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt index 69b5ab0b5f4b..d11d80006a19 100644 --- a/Documentation/devicetree/bindings/arm/ste-u300.txt +++ b/Documentation/devicetree/bindings/arm/ste-u300.txt @@ -22,7 +22,7 @@ This contains the board-specific information. - compatible: must be "stericsson,s365". - vana15-supply: the regulator supplying the 1.5V to drive the board. -- syscon: a pointer to the syscon node so we can acccess the +- syscon: a pointer to the syscon node so we can access the syscon registers to set the board as self-powered. Example: diff --git a/Documentation/devicetree/bindings/arm/vexpress-scc.txt b/Documentation/devicetree/bindings/arm/vexpress-scc.txt new file mode 100644 index 000000000000..ae5043e42e5d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/vexpress-scc.txt @@ -0,0 +1,33 @@ +ARM Versatile Express Serial Configuration Controller +----------------------------------------------------- + +Test chips for ARM Versatile Express platform implement SCC (Serial +Configuration Controller) interface, used to set initial conditions +for the test chip. + +In some cases its registers are also mapped in normal address space +and can be used to obtain runtime information about the chip internals +(like silicon temperature sensors) and as interface to other subsystems +like platform configuration control and power management. + +Required properties: + +- compatible value: "arm,vexpress-scc,<model>", "arm,vexpress-scc"; + where <model> is the full tile model name (as used + in the tile's Technical Reference Manual), + eg. for Coretile Express A15x2 A7x3 (V2P-CA15_A7): + compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; + +Optional properties: + +- reg: when the SCC is memory mapped, physical address and size of the + registers window +- interrupts: when the SCC can generate a system-level interrupt + +Example: + + scc@7fff0000 { + compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; + reg = <0 0x7fff0000 0 0x1000>; + interrupts = <0 95 4>; + }; diff --git a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt index 9cf3f25544c7..5580e9c4bd85 100644 --- a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt +++ b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt @@ -32,8 +32,8 @@ numbers - see motherboard's TRM for more details. The node describing a config device must refer to the sysreg node via "arm,vexpress,config-bridge" phandle (can be also defined in the node's parent) and relies on the board topology properties - see main vexpress -node documentation for more details. It must must also define the -following property: +node documentation for more details. It must also define the following +property: - arm,vexpress-sysreg,func : must contain two cells: - first cell defines function number (eg. 1 for clock generator, 2 for voltage regulators etc.) diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt index cedc2a9c4785..0fd76c405208 100644 --- a/Documentation/devicetree/bindings/bus/imx-weim.txt +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt @@ -8,7 +8,7 @@ The actual devices are instantiated from the child nodes of a WEIM node. Required properties: - - compatible: Should be set to "fsl,imx6q-weim" + - compatible: Should be set to "fsl,<soc>-weim" - reg: A resource specifier for the register space (see the example below) - clocks: the clock, see the example below. @@ -21,11 +21,18 @@ Required properties: Timing property for child nodes. It is mandatory, not optional. - - fsl,weim-cs-timing: The timing array, contains 6 timing values for the + - fsl,weim-cs-timing: The timing array, contains timing values for the child node. We can get the CS index from the child - node's "reg" property. This property contains the values - for the registers EIM_CSnGCR1, EIM_CSnGCR2, EIM_CSnRCR1, - EIM_CSnRCR2, EIM_CSnWCR1, EIM_CSnWCR2 in this order. + node's "reg" property. The number of registers depends + on the selected chip. + For i.MX1, i.MX21 ("fsl,imx1-weim") there are two + registers: CSxU, CSxL. + For i.MX25, i.MX27, i.MX31 and i.MX35 ("fsl,imx27-weim") + there are three registers: CSCRxU, CSCRxL, CSCRxA. + For i.MX50, i.MX53 ("fsl,imx50-weim"), + i.MX51 ("fsl,imx51-weim") and i.MX6Q ("fsl,imx6q-weim") + there are six registers: CSxGCR1, CSxGCR2, CSxRCR1, + CSxRCR2, CSxWCR1, CSxWCR2. Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM: diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt new file mode 100644 index 000000000000..7586fb68c072 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt @@ -0,0 +1,276 @@ + +* Marvell MBus + +Required properties: + +- compatible: Should be set to one of the following: + marvell,armada370-mbus + marvell,armadaxp-mbus + marvell,armada370-mbus + marvell,armadaxp-mbus + marvell,kirkwood-mbus + marvell,dove-mbus + marvell,orion5x-88f5281-mbus + marvell,orion5x-88f5182-mbus + marvell,orion5x-88f5181-mbus + marvell,orion5x-88f6183-mbus + marvell,mv78xx0-mbus + +- address-cells: Must be '2'. The first cell for the MBus ID encoding, + the second cell for the address offset within the window. + +- size-cells: Must be '1'. + +- ranges: Must be set up to provide a proper translation for each child. + See the examples below. + +- controller: Contains a single phandle referring to the MBus controller + node. This allows to specify the node that contains the + registers that control the MBus, which is typically contained + within the internal register window (see below). + +Optional properties: + +- pcie-mem-aperture: This optional property contains the aperture for + the memory region of the PCIe driver. + If it's defined, it must encode the base address and + size for the address decoding windows allocated for + the PCIe memory region. + +- pcie-io-aperture: Just as explained for the above property, this + optional property contains the aperture for the + I/O region of the PCIe driver. + +* Marvell MBus controller + +Required properties: + +- compatible: Should be set to "marvell,mbus-controller". + +- reg: Device's register space. + Two entries are expected (see the examples below): + the first one controls the devices decoding window and + the second one controls the SDRAM decoding window. + +Example: + + soc { + compatible = "marvell,armada370-mbus", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + controller = <&mbusc>; + pcie-mem-aperture = <0xe0000000 0x8000000>; + pcie-io-aperture = <0xe8000000 0x100000>; + + internal-regs { + compatible = "simple-bus"; + + mbusc: mbus-controller@20000 { + compatible = "marvell,mbus-controller"; + reg = <0x20000 0x100>, <0x20180 0x20>; + }; + + /* more children ...*/ + }; + }; + +** MBus address decoding window specification + +The MBus children address space is comprised of two cells: the first one for +the window ID and the second one for the offset within the window. +In order to allow to describe valid and non-valid window entries, the +following encoding is used: + + 0xSIAA0000 0x00oooooo + +Where: + + S = 0x0 for a MBus valid window + S = 0xf for a non-valid window (see below) + +If S = 0x0, then: + + I = 4-bit window target ID + AA = windpw attribute + +If S = 0xf, then: + + I = don't care + AA = 1 for internal register + +Following the above encoding, for each ranges entry for a MBus valid window +(S = 0x0), an address decoding window is allocated. On the other side, +entries for translation that do not correspond to valid windows (S = 0xf) +are skipped. + + soc { + compatible = "marvell,armada370-mbus", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + controller = <&mbusc>; + + ranges = <0xf0010000 0 0 0xd0000000 0x100000 + 0x01e00000 0 0 0xfff00000 0x100000>; + + bootrom { + compatible = "marvell,bootrom"; + reg = <0x01e00000 0 0x100000>; + }; + + /* other children */ + ... + + internal-regs { + compatible = "simple-bus"; + ranges = <0 0xf0010000 0 0x100000>; + + mbusc: mbus-controller@20000 { + compatible = "marvell,mbus-controller"; + reg = <0x20000 0x100>, <0x20180 0x20>; + }; + + /* more children ...*/ + }; + }; + +In the shown example, the translation entry in the 'ranges' property is what +makes the MBus driver create a static decoding window for the corresponding +given child device. Note that the binding does not require child nodes to be +present. Of course, child nodes are needed to probe the devices. + +Since each window is identified by its target ID and attribute ID there's +a special macro that can be use to simplify the translation entries: + +#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16)) + +Using this macro, the above example would be: + + soc { + compatible = "marvell,armada370-mbus", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + controller = <&mbusc>; + + ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 + MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>; + + bootrom { + compatible = "marvell,bootrom"; + reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>; + }; + + /* other children */ + ... + + internal-regs { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>; + + mbusc: mbus-controller@20000 { + compatible = "marvell,mbus-controller"; + reg = <0x20000 0x100>, <0x20180 0x20>; + }; + + /* other children */ + ... + }; + }; + + +** About the window base address + +Remember the MBus controller allows a great deal of flexibility for choosing +the decoding window base address. When planning the device tree layout it's +possible to choose any address as the base address, provided of course there's +a region large enough available, and with the required alignment. + +Yet in other words: there's nothing preventing us from setting a base address +of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is +unused. + +** Window allocation policy + +The mbus-node ranges property defines a set of mbus windows that are expected +to be set by the operating system and that are guaranteed to be free of overlaps +with one another or with the system memory ranges. + +Each entry in the property refers to exactly one window. If the operating system +choses to use a different set of mbus windows, it must ensure that any address +translations performed from downstream devices are adapted accordingly. + +The operating system may insert additional mbus windows that do not conflict +with the ones listed in the ranges, e.g. for mapping PCIe devices. +As a special case, the internal register window must be set up by the boot +loader at the address listed in the ranges property, since access to that region +is needed to set up the other windows. + +** Example + +See the example below, where a more complete device tree is shown: + + soc { + compatible = "marvell,armadaxp-mbus", "simple-bus"; + controller = <&mbusc>; + + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 /* internal-regs */ + MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000 + MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>; + + bootrom { + compatible = "marvell,bootrom"; + reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>; + }; + + devbus-bootcs { + status = "okay"; + ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>; + + /* NOR */ + nor { + compatible = "cfi-flash"; + reg = <0 0x8000000>; + bank-width = <2>; + }; + }; + + pcie-controller { + compatible = "marvell,armada-xp-pcie"; + status = "okay"; + device_type = "pci"; + + #address-cells = <3>; + #size-cells = <2>; + + ranges = + <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */ + 0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */ + 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */ + 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */ + 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */ + 0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */ + 0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>; + + + pcie@1,0 { + /* Port 0, Lane 0 */ + status = "okay"; + }; + }; + + internal-regs { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>; + + mbusc: mbus-controller@20000 { + reg = <0x20000 0x100>, <0x20180 0x20>; + }; + + interrupt-controller@20000 { + reg = <0x20a00 0x2d0>, <0x21070 0x58>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/c6x/dscr.txt b/Documentation/devicetree/bindings/c6x/dscr.txt index d847758f2b20..b0e97144cfb1 100644 --- a/Documentation/devicetree/bindings/c6x/dscr.txt +++ b/Documentation/devicetree/bindings/c6x/dscr.txt @@ -5,7 +5,7 @@ TI C6X SoCs contain a region of miscellaneous registers which provide various function for SoC control or status. Details vary considerably among from SoC to SoC with no two being alike. -In general, the Device State Configuraion Registers (DSCR) will provide one or +In general, the Device State Configuration Registers (DSCR) will provide one or more configuration registers often protected by a lock register where one or more key values must be written to a lock register in order to unlock the configuration register for writes. These configuration register may be used to diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt index a1201802f90d..75e2e1999f87 100644 --- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt +++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt @@ -2,7 +2,7 @@ The Samsung Audio Subsystem clock controller generates and supplies clocks to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock -binding described here is applicable to all SoC's in Exynos family. +binding described here is applicable to all SoCs in Exynos family. Required Properties: diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt index f46f5625d8ad..4c029a8739d3 100644 --- a/Documentation/devicetree/bindings/clock/imx5-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt @@ -197,6 +197,7 @@ clocks and IDs. spdif0_gate 183 spdif1_gate 184 spdif_ipg_gate 185 + ocram 186 Examples (for mx53): diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index a0e104f0527e..5a90a724b520 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt @@ -209,6 +209,12 @@ clocks and IDs. pll5_post_div 194 pll5_video_div 195 eim_slow 196 + spdif 197 + cko2_sel 198 + cko2_podf 199 + cko2 200 + cko 201 + vdoa 202 Examples: diff --git a/Documentation/devicetree/bindings/clock/st,nomadik.txt b/Documentation/devicetree/bindings/clock/st,nomadik.txt index 7fc09773de46..40e0cf1f7b99 100644 --- a/Documentation/devicetree/bindings/clock/st,nomadik.txt +++ b/Documentation/devicetree/bindings/clock/st,nomadik.txt @@ -17,7 +17,7 @@ Optional properties for the SRC node: - disable-mxtal: if present this will disable the MXTALO, i.e. the driver output for the main (~19.2 MHz) chrystal, if the board has its own circuitry for providing this - osciallator + oscillator PLL nodes: these nodes represent the two PLLs on the system, diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec6.txt b/Documentation/devicetree/bindings/crypto/fsl-sec6.txt new file mode 100644 index 000000000000..c0a20cd972e3 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/fsl-sec6.txt @@ -0,0 +1,157 @@ +SEC 6 is as Freescale's Cryptographic Accelerator and Assurance Module (CAAM). +Currently Freescale powerpc chip C29X is embeded with SEC 6. +SEC 6 device tree binding include: + -SEC 6 Node + -Job Ring Node + -Full Example + +===================================================================== +SEC 6 Node + +Description + + Node defines the base address of the SEC 6 block. + This block specifies the address range of all global + configuration registers for the SEC 6 block. + For example, In C293, we could see three SEC 6 node. + +PROPERTIES + + - compatible + Usage: required + Value type: <string> + Definition: Must include "fsl,sec-v6.0". + + - fsl,sec-era + Usage: optional + Value type: <u32> + Definition: A standard property. Define the 'ERA' of the SEC + device. + + - #address-cells + Usage: required + Value type: <u32> + Definition: A standard property. Defines the number of cells + for representing physical addresses in child nodes. + + - #size-cells + Usage: required + Value type: <u32> + Definition: A standard property. Defines the number of cells + for representing the size of physical addresses in + child nodes. + + - reg + Usage: required + Value type: <prop-encoded-array> + Definition: A standard property. Specifies the physical + address and length of the SEC 6 configuration registers. + + - ranges + Usage: required + Value type: <prop-encoded-array> + Definition: A standard property. Specifies the physical address + range of the SEC 6.0 register space (-SNVS not included). A + triplet that includes the child address, parent address, & + length. + + Note: All other standard properties (see the ePAPR) are allowed + but are optional. + +EXAMPLE + crypto@a0000 { + compatible = "fsl,sec-v6.0"; + fsl,sec-era = <6>; + #address-cells = <1>; + #size-cells = <1>; + reg = <0xa0000 0x20000>; + ranges = <0 0xa0000 0x20000>; + }; + +===================================================================== +Job Ring (JR) Node + + Child of the crypto node defines data processing interface to SEC 6 + across the peripheral bus for purposes of processing + cryptographic descriptors. The specified address + range can be made visible to one (or more) cores. + The interrupt defined for this node is controlled within + the address range of this node. + + - compatible + Usage: required + Value type: <string> + Definition: Must include "fsl,sec-v6.0-job-ring". + + - reg + Usage: required + Value type: <prop-encoded-array> + Definition: Specifies a two JR parameters: an offset from + the parent physical address and the length the JR registers. + + - interrupts + Usage: required + Value type: <prop_encoded-array> + Definition: Specifies the interrupts generated by this + device. The value of the interrupts property + consists of one interrupt specifier. The format + of the specifier is defined by the binding document + describing the node's interrupt parent. + +EXAMPLE + jr@1000 { + compatible = "fsl,sec-v6.0-job-ring"; + reg = <0x1000 0x1000>; + interrupts = <49 2 0 0>; + }; + +=================================================================== +Full Example + +Since some chips may contain more than one SEC, the dtsi contains +only the node contents, not the node itself. A chip using the SEC +should include the dtsi inside each SEC node. Example: + +In qoriq-sec6.0.dtsi: + + compatible = "fsl,sec-v6.0"; + fsl,sec-era = <6>; + #address-cells = <1>; + #size-cells = <1>; + + jr@1000 { + compatible = "fsl,sec-v6.0-job-ring", + "fsl,sec-v5.2-job-ring", + "fsl,sec-v5.0-job-ring", + "fsl,sec-v4.4-job-ring", + "fsl,sec-v4.0-job-ring"; + reg = <0x1000 0x1000>; + }; + + jr@2000 { + compatible = "fsl,sec-v6.0-job-ring", + "fsl,sec-v5.2-job-ring", + "fsl,sec-v5.0-job-ring", + "fsl,sec-v4.4-job-ring", + "fsl,sec-v4.0-job-ring"; + reg = <0x2000 0x1000>; + }; + +In the C293 device tree, we add the include of public property: + + crypto@a0000 { + /include/ "qoriq-sec6.0.dtsi" + } + + crypto@a0000 { + reg = <0xa0000 0x20000>; + ranges = <0 0xa0000 0x20000>; + + jr@1000 { + interrupts = <49 2 0 0>; + }; + + jr@2000 { + interrupts = <50 2 0 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt index c280a0e6f42d..e1f343c7a34b 100644 --- a/Documentation/devicetree/bindings/dma/atmel-dma.txt +++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt @@ -18,14 +18,14 @@ dma0: dma@ffffec00 { DMA clients connected to the Atmel DMA controller must use the format described in the dma.txt file, using a three-cell specifier for each channel: -a phandle plus two interger cells. +a phandle plus two integer cells. The three cells in order are: 1. A phandle pointing to the DMA controller. 2. The memory interface (16 most significant bits), the peripheral interface (16 less significant bits). 3. Parameters for the at91 DMA configuration register which are device -dependant: +dependent: - bit 7-0: peripheral identifier for the hardware handshaking interface. The identifier can be different for tx and rx. - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP. diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt index 2717ecb47db9..7bd8847d6394 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt @@ -34,7 +34,7 @@ Clients have to specify the DMA requests with phandles in a list. Required properties: - dmas: List of one or more DMA request specifiers. One DMA request specifier consists of a phandle to the DMA controller followed by the integer - specifiying the request line. + specifying the request line. - dma-names: List of string identifiers for the DMA requests. For the correct names, have a look at the specific client driver. diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt index bea5b73a7390..a8c21c256baa 100644 --- a/Documentation/devicetree/bindings/dma/ste-dma40.txt +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt @@ -37,14 +37,14 @@ Each dmas request consists of 4 cells: 1. A phandle pointing to the DMA controller 2. Device Type 3. The DMA request line number (only when 'use fixed channel' is set) - 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow] + 4. A 32bit mask specifying; mode, direction and endianness [NB: This list will grow] 0x00000001: Mode: Logical channel when unset Physical channel when set 0x00000002: Direction: Memory to Device when unset Device to Memory when set - 0x00000004: Endianess: + 0x00000004: Endianness: Little endian when unset Big endian when set 0x00000008: Use fixed channel: diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt index 629d0ef17308..daa30174bcc1 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt @@ -3,10 +3,17 @@ Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for Required properties: - compatible : Should be - - "mcp,mcp23s08" for 8 GPIO SPI version - - "mcp,mcp23s17" for 16 GPIO SPI version - - "mcp,mcp23008" for 8 GPIO I2C version or - - "mcp,mcp23017" for 16 GPIO I2C version of the chip + - "mcp,mcp23s08" (DEPRECATED) for 8 GPIO SPI version + - "mcp,mcp23s17" (DEPRECATED) for 16 GPIO SPI version + - "mcp,mcp23008" (DEPRECATED) for 8 GPIO I2C version or + - "mcp,mcp23017" (DEPRECATED) for 16 GPIO I2C version of the chip + + - "microchip,mcp23s08" for 8 GPIO SPI version + - "microchip,mcp23s17" for 16 GPIO SPI version + - "microchip,mcp23008" for 8 GPIO I2C version or + - "microchip,mcp23017" for 16 GPIO I2C version of the chip + NOTE: Do not use the old mcp prefix any more. It is deprecated and will be + removed. - #gpio-cells : Should be two. - first cell is the pin number - second cell is used to specify flags. Flags are currently unused. @@ -15,10 +22,11 @@ Required properties: SPI uses this to specify the chipselect line which the chip is connected to. The driver and the SPI variant of the chip support multiple chips on the same chipselect. Have a look at - mcp,spi-present-mask below. + microchip,spi-present-mask below. Required device specific properties (only for SPI chips): -- mcp,spi-present-mask : This is a present flag, that makes only sense for SPI +- mcp,spi-present-mask (DEPRECATED) +- microchip,spi-present-mask : This is a present flag, that makes only sense for SPI chips - as the name suggests. Multiple SPI chips can share the same SPI chipselect. Set a bit in bit0-7 in this mask to 1 if there is a chip connected with the corresponding spi address set. For example if @@ -26,11 +34,13 @@ Required device specific properties (only for SPI chips): which is 0x08. mcp23s08 chip variant only supports bits 0-3. It is not possible to mix mcp23s08 and mcp23s17 on the same chipselect. Set at least one bit to 1 for SPI chips. + NOTE: Do not use the old mcp prefix any more. It is deprecated and will be + removed. - spi-max-frequency = The maximum frequency this chip is able to handle Example I2C: gpiom1: gpio@20 { - compatible = "mcp,mcp23017"; + compatible = "microchip,mcp23017"; gpio-controller; #gpio-cells = <2>; reg = <0x20>; @@ -38,7 +48,7 @@ gpiom1: gpio@20 { Example SPI: gpiom1: gpio@0 { - compatible = "mcp,mcp23s17"; + compatible = "microchip,mcp23s17"; gpio-controller; #gpio-cells = <2>; spi-present-mask = <0x01>; diff --git a/Documentation/devicetree/bindings/gpio/gpio-palmas.txt b/Documentation/devicetree/bindings/gpio/gpio-palmas.txt new file mode 100644 index 000000000000..08b5b52a3ae0 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-palmas.txt @@ -0,0 +1,27 @@ +Palmas GPIO controller bindings + +Required properties: +- compatible: + - "ti,palams-gpio" for palma series of the GPIO controller + - "ti,tps80036-gpio" for Palma series device TPS80036. + - "ti,tps65913-gpio" for palma series device TPS65913. + - "ti,tps65914-gpio" for palma series device TPS65914. +- #gpio-cells : Should be two. + - first cell is the gpio pin number + - second cell is used to specify the gpio polarity: + 0 = active high + 1 = active low +- gpio-controller : Marks the device node as a GPIO controller. + +Note: This gpio node will be sub node of palmas node. + +Example: + palmas: tps65913@58 { + ::::::::::: + palmas_gpio: palmas_gpio { + compatible = "ti,palmas-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; + ::::::::::: + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt b/Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt new file mode 100644 index 000000000000..1fd98ffa8cb7 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt @@ -0,0 +1,45 @@ +ImgTec TZ1090 PDC GPIO Controller + +Required properties: +- compatible: Compatible property value should be "img,tz1090-pdc-gpio". + +- reg: Physical base address of the controller and length of memory mapped + region. This starts at and cover the SOC_GPIO_CONTROL registers. + +- gpio-controller: Specifies that the node is a gpio controller. + +- #gpio-cells: Should be 2. The syntax of the gpio specifier used by client + nodes should have the following values. + <[phandle of the gpio controller node] + [PDC gpio number] + [gpio flags]> + + Values for gpio specifier: + - GPIO number: a value in the range 0 to 6. + - GPIO flags: bit field of flags, as defined in <dt-bindings/gpio/gpio.h>. + Only the following flags are supported: + GPIO_ACTIVE_HIGH + GPIO_ACTIVE_LOW + +Optional properties: +- gpio-ranges: Mapping to pin controller pins (as described in + Documentation/devicetree/bindings/gpio/gpio.txt) + +- interrupts: Individual syswake interrupts (other GPIOs cannot interrupt) + + +Example: + + pdc_gpios: gpio-controller@02006500 { + gpio-controller; + #gpio-cells = <2>; + + compatible = "img,tz1090-pdc-gpio"; + reg = <0x02006500 0x100>; + + interrupt-parent = <&pdc>; + interrupts = <8 IRQ_TYPE_NONE>, /* Syswake 0 */ + <9 IRQ_TYPE_NONE>, /* Syswake 1 */ + <10 IRQ_TYPE_NONE>; /* Syswake 2 */ + gpio-ranges = <&pdc_pinctrl 0 0 7>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt b/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt new file mode 100644 index 000000000000..174cdf309170 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-tz1090.txt @@ -0,0 +1,88 @@ +ImgTec TZ1090 GPIO Controller + +Required properties: +- compatible: Compatible property value should be "img,tz1090-gpio". + +- reg: Physical base address of the controller and length of memory mapped + region. + +- #address-cells: Should be 1 (for bank subnodes) + +- #size-cells: Should be 0 (for bank subnodes) + +- Each bank of GPIOs should have a subnode to represent it. + + Bank subnode required properties: + - reg: Index of bank in the range 0 to 2. + + - gpio-controller: Specifies that the node is a gpio controller. + + - #gpio-cells: Should be 2. The syntax of the gpio specifier used by client + nodes should have the following values. + <[phandle of the gpio controller node] + [gpio number within the gpio bank] + [gpio flags]> + + Values for gpio specifier: + - GPIO number: a value in the range 0 to 29. + - GPIO flags: bit field of flags, as defined in <dt-bindings/gpio/gpio.h>. + Only the following flags are supported: + GPIO_ACTIVE_HIGH + GPIO_ACTIVE_LOW + + Bank subnode optional properties: + - gpio-ranges: Mapping to pin controller pins (as described in + Documentation/devicetree/bindings/gpio/gpio.txt) + + - interrupts: Interrupt for the entire bank + + - interrupt-controller: Specifies that the node is an interrupt controller + + - #interrupt-cells: Should be 2. The syntax of the interrupt specifier used by + client nodes should have the following values. + <[phandle of the interurupt controller] + [gpio number within the gpio bank] + [irq flags]> + + Values for irq specifier: + - GPIO number: a value in the range 0 to 29 + - IRQ flags: value to describe edge and level triggering, as defined in + <dt-bindings/interrupt-controller/irq.h>. Only the following flags are + supported: + IRQ_TYPE_EDGE_RISING + IRQ_TYPE_EDGE_FALLING + IRQ_TYPE_EDGE_BOTH + IRQ_TYPE_LEVEL_HIGH + IRQ_TYPE_LEVEL_LOW + + + +Example: + + gpios: gpio-controller@02005800 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "img,tz1090-gpio"; + reg = <0x02005800 0x90>; + + /* bank 0 with an interrupt */ + gpios0: bank@0 { + #gpio-cells = <2>; + #interrupt-cells = <2>; + reg = <0>; + interrupts = <13 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + gpio-ranges = <&pinctrl 0 0 30>; + interrupt-controller; + }; + + /* bank 2 without interrupt */ + gpios2: bank@2 { + #gpio-cells = <2>; + reg = <2>; + gpio-controller; + gpio-ranges = <&pinctrl 0 60 30>; + }; + }; + + 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/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt index 9b3f1d4a88d6..66416261e14d 100644 --- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt +++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt @@ -10,8 +10,9 @@ Required properties: There're three gpio interrupts in arch-pxa, and they're gpio0, gpio1 and gpio_mux. There're only one gpio interrupt in arch-mmp, gpio_mux. -- interrupt-name : Should be the name of irq resource. Each interrupt - binds its interrupt-name. +- interrupt-names : Should be the names of irq resources. Each interrupt + uses its own interrupt name, so there should be as many interrupt names + as referenced interrups. - interrupt-controller : Identifies the node as an interrupt controller. - #interrupt-cells: Specifies the number of cells needed to encode an interrupt source. @@ -24,7 +25,7 @@ Example: compatible = "marvell,mmp-gpio"; reg = <0xd4019000 0x1000>; interrupts = <49>; - interrupt-name = "gpio_mux"; + interrupt-names = "gpio_mux"; gpio-controller; #gpio-cells = <1>; interrupt-controller; diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt index cb3dc7bcd8e6..8655df9440d5 100644 --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt @@ -23,6 +23,10 @@ Required Properties: Please refer to gpio.txt in this directory for details of gpio-ranges property and the common GPIO bindings used by client devices. +The GPIO controller also acts as an interrupt controller. It uses the default +two cells specifier as described in Documentation/devicetree/bindings/ +interrupt-controller/interrupts.txt. + Example: R8A7779 (R-Car H1) GPIO controller nodes gpio0: gpio@ffc40000 { @@ -33,6 +37,8 @@ Example: R8A7779 (R-Car H1) GPIO controller nodes #gpio-cells = <2>; gpio-controller; gpio-ranges = <&pfc 0 0 32>; + interrupt-controller; + #interrupt-cells = <2>; }; ... gpio6: gpio@ffc46000 { @@ -43,4 +49,6 @@ Example: R8A7779 (R-Car H1) GPIO controller nodes #gpio-cells = <2>; gpio-controller; gpio-ranges = <&pfc 0 192 9>; + interrupt-controller; + #interrupt-cells = <2>; }; 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/hid/hid-over-i2c.txt b/Documentation/devicetree/bindings/hid/hid-over-i2c.txt new file mode 100644 index 000000000000..488edcb264c4 --- /dev/null +++ b/Documentation/devicetree/bindings/hid/hid-over-i2c.txt @@ -0,0 +1,28 @@ +* HID over I2C Device-Tree bindings + +HID over I2C provides support for various Human Interface Devices over the +I2C bus. These devices can be for example touchpads, keyboards, touch screens +or sensors. + +The specification has been written by Microsoft and is currently available here: +http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx + +If this binding is used, the kernel module i2c-hid will handle the communication +with the device and the generic hid core layer will handle the protocol. + +Required properties: +- compatible: must be "hid-over-i2c" +- reg: i2c slave address +- hid-descr-addr: HID descriptor address +- interrupt-parent: the phandle for the interrupt controller +- interrupts: interrupt line + +Example: + + i2c-hid-dev@2c { + compatible = "hid-over-i2c"; + reg = <0x2c>; + hid-descr-addr = <0x0020>; + interrupt-parent = <&gpx3>; + interrupts = <3 2>; + }; 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 6113f9275f42..82e8f6f17179 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt @@ -5,6 +5,7 @@ Required properties : - reg : Offset and length of the register set for the device - 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/input/input-reset.txt b/Documentation/devicetree/bindings/input/input-reset.txt new file mode 100644 index 000000000000..2bb2626fdb78 --- /dev/null +++ b/Documentation/devicetree/bindings/input/input-reset.txt @@ -0,0 +1,33 @@ +Input: sysrq reset sequence + +A simple binding to represent a set of keys as described in +include/uapi/linux/input.h. This is to communicate a sequence of keys to the +sysrq driver. Upon holding the keys for a specified amount of time (if +specified) the system is sync'ed and reset. + +Key sequences are global to the system but all the keys in a set must be coming +from the same input device. + +The /chosen node should contain a 'linux,sysrq-reset-seq' child node to define +a set of keys. + +Required property: +sysrq-reset-seq: array of Linux keycodes, one keycode per cell. + +Optional property: +timeout-ms: duration keys must be pressed together in milliseconds before +generating a sysrq. If omitted the system is rebooted immediately when a valid +sequence has been recognized. + +Example: + + chosen { + linux,sysrq-reset-seq { + keyset = <0x03 + 0x04 + 0x0a>; + timeout-ms = <3000>; + }; + }; + +Would represent KEY_2, KEY_3 and KEY_9. diff --git a/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt index df70318a617f..49fa14ed155c 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt @@ -6,7 +6,7 @@ Required properties: - interrupt-parent: the phandle for the interrupt controller - interrupts: touch controller interrupt - wakeup-gpios: the gpio pin to be used for waking up the controller - as well as uased as irq pin + and also used as irq pin Example: 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..f4181680831b 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -10,14 +10,15 @@ 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. - interrupts : MFC interrupt number to the CPU. - - clocks : from common clock binding: handle to mfc clocks. - - clock-names : from common clock binding: must contain "sclk_mfc" and "mfc", - corresponding to entries in the clocks property. + - clocks : from common clock binding: handle to mfc clock. + - clock-names : from common clock binding: must contain "mfc", + corresponding to entry in the clocks property. - samsung,mfc-r : Base address of the first memory bank used by MFC for DMA contiguous memory allocation and its size. @@ -37,8 +38,8 @@ mfc: codec@13400000 { reg = <0x13400000 0x10000>; interrupts = <0 94 0>; samsung,power-domain = <&pd_mfc>; - clocks = <&clock 170>, <&clock 273>; - clock-names = "sclk_mfc", "mfc"; + clocks = <&clock 273>; + clock-names = "mfc"; }; Board specific DT entry: 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/metag/pdc-intc.txt b/Documentation/devicetree/bindings/metag/pdc-intc.txt new file mode 100644 index 000000000000..a69118550344 --- /dev/null +++ b/Documentation/devicetree/bindings/metag/pdc-intc.txt @@ -0,0 +1,105 @@ +* ImgTec Powerdown Controller (PDC) Interrupt Controller Binding + +This binding specifies what properties must be available in the device tree +representation of a PDC IRQ controller. This has a number of input interrupt +lines which can wake the system, and are passed on through output interrupt +lines. + +Required properties: + + - compatible: Specifies the compatibility list for the interrupt controller. + The type shall be <string> and the value shall include "img,pdc-intc". + + - reg: Specifies the base PDC physical address(s) and size(s) of the + addressable register space. The type shall be <prop-encoded-array>. + + - interrupt-controller: The presence of this property identifies the node + as an interrupt controller. No property value shall be defined. + + - #interrupt-cells: Specifies the number of cells needed to encode an + interrupt source. The type shall be a <u32> and the value shall be 2. + + - num-perips: Number of waking peripherals. + + - num-syswakes: Number of SysWake inputs. + + - interrupts: List of interrupt specifiers. The first specifier shall be the + shared SysWake interrupt, and remaining specifies shall be PDC peripheral + interrupts in order. + +* Interrupt Specifier Definition + + Interrupt specifiers consists of 2 cells encoded as follows: + + - <1st-cell>: The interrupt-number that identifies the interrupt source. + 0-7: Peripheral interrupts + 8-15: SysWake interrupts + + - <2nd-cell>: The level-sense information, encoded using the Linux interrupt + flags as follows (only 4 valid for peripheral interrupts): + 0 = none (decided by software) + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 3 = both edge triggered + 4 = active-high level-sensitive (required for perip irqs) + 8 = active-low level-sensitive + +* Examples + +Example 1: + + /* + * TZ1090 PDC block + */ + pdc: pdc@0x02006000 { + // This is an interrupt controller node. + interrupt-controller; + + // Three cells to encode interrupt sources. + #interrupt-cells = <2>; + + // Offset address of 0x02006000 and size of 0x1000. + reg = <0x02006000 0x1000>; + + // Compatible with Meta hardware trigger block. + compatible = "img,pdc-intc"; + + // Three peripherals are connected. + num-perips = <3>; + + // Four SysWakes are connected. + num-syswakes = <4>; + + interrupts = <18 4 /* level */>, /* Syswakes */ + <30 4 /* level */>, /* Peripheral 0 (RTC) */ + <29 4 /* level */>, /* Peripheral 1 (IR) */ + <31 4 /* level */>; /* Peripheral 2 (WDT) */ + }; + +Example 2: + + /* + * An SoC peripheral that is wired through the PDC. + */ + rtc0 { + // The interrupt controller that this device is wired to. + interrupt-parent = <&pdc>; + + // Interrupt source Peripheral 0 + interrupts = <0 /* Peripheral 0 (RTC) */ + 4> /* IRQ_TYPE_LEVEL_HIGH */ + }; + +Example 3: + + /* + * An interrupt generating device that is wired to a SysWake pin. + */ + touchscreen0 { + // The interrupt controller that this device is wired to. + interrupt-parent = <&pdc>; + + // Interrupt source SysWake 0 that is active-low level-sensitive + interrupts = <8 /* SysWake0 */ + 8 /* IRQ_TYPE_LEVEL_LOW */>; + }; diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt index e0e59c58a1f9..5f229c5f6da9 100644 --- a/Documentation/devicetree/bindings/mfd/cros-ec.txt +++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt @@ -4,7 +4,7 @@ Google's ChromeOS EC is a Cortex-M device which talks to the AP and implements various function such as keyboard and battery charging. The EC can be connect through various means (I2C, SPI, LPC) and the -compatible string used depends on the inteface. Each connection method has +compatible string used depends on the interface. Each connection method has its own driver which connects to the top level interface-agnostic EC driver. Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to the top-level driver. diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index 892537d1a48f..e5f0f8303461 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -5,6 +5,7 @@ twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) +tps659038 Required properties: - compatible : Should be from the list @@ -14,6 +15,7 @@ Required properties: ti,tps65913 ti,tps65914 ti,tps80036 + ti,tps659038 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt new file mode 100644 index 000000000000..c9332c626021 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -0,0 +1,109 @@ + +* Samsung S2MPS11 Voltage and Current Regulator + +The Samsung S2MP211 is a multi-function device which includes voltage and +current regulators, RTC, charger controller and other sub-blocks. It is +interfaced to the host controller using a I2C interface. Each sub-block is +addressed by the host system using different I2C slave address. + +Required properties: +- compatible: Should be "samsung,s2mps11-pmic". +- reg: Specifies the I2C slave address of the pmic block. It should be 0x66. + +Optional properties: +- interrupt-parent: Specifies the phandle of the interrupt controller to which + the interrupts from s2mps11 are delivered to. +- interrupts: Interrupt specifiers for interrupt sources. + +Optional nodes: +- clocks: s2mps11 provides three(AP/CP/BT) buffered 32.768 KHz outputs, so to + register these as clocks with common clock framework instantiate a sub-node + named "clocks". It uses the common clock binding documented in : + [Documentation/devicetree/bindings/clock/clock-bindings.txt] + - #clock-cells: should be 1. + + - The following is the list of clocks generated by the controller. Each clock + is assigned an identifier and client nodes use this identifier to specify + the clock which they consume. + Clock ID + ---------------------- + 32KhzAP 0 + 32KhzCP 1 + 32KhzBT 2 + +- regulators: The regulators of s2mps11 that have to be instantiated should be +included in a sub-node named 'regulators'. Regulator nodes included in this +sub-node should be of the format as listed below. + + regulator_name { + [standard regulator constraints....]; + }; + + regulator-ramp-delay for BUCKs = [6250/12500/25000(default)/50000] uV/us + + BUCK[2/3/4/6] supports disabling ramp delay on hardware, so explictly + regulator-ramp-delay = <0> can be used for them to disable ramp delay. + In absence of regulator-ramp-delay property, default ramp delay will be used. + +NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set +for a particular group of BUCKs. So provide same regulator-ramp-delay<value>. +Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6], +BUCK[3, 4], and BUCK[7, 8, 10] + +The regulator constraints inside the regulator nodes use the standard regulator +bindings which are documented elsewhere. + +The following are the names of the regulators that the s2mps11 pmic block +supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number +as per the datasheet of s2mps11. + + - LDOn + - valid values for n are 1 to 28 + - Example: LDO0, LD01, LDO28 + - BUCKn + - valid values for n are 1 to 9. + - Example: BUCK1, BUCK2, BUCK9 + +Example: + + s2mps11_pmic@66 { + compatible = "samsung,s2mps11-pmic"; + reg = <0x66>; + + s2m_osc: clocks{ + #clock-cells = 1; + clock-output-names = "xx", "yy", "zz"; + }; + + regulators { + ldo1_reg: LDO1 { + regulator-name = "VDD_ABB_3.3V"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + ldo2_reg: LDO2 { + regulator-name = "VDD_ALIVE_1.1V"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + }; + + buck1_reg: BUCK1 { + regulator-name = "vdd_mif"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + }; + + buck2_reg: BUCK2 { + regulator-name = "vdd_arm"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + regulator-ramp-delay = <50000>; + }; + }; + }; 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/misc/smc.txt b/Documentation/devicetree/bindings/misc/smc.txt index 02b428136177..6c9f176f3571 100644 --- a/Documentation/devicetree/bindings/misc/smc.txt +++ b/Documentation/devicetree/bindings/misc/smc.txt @@ -4,11 +4,12 @@ This binding defines the location of the bounce buffer used for non-secure to secure communications. Required properties: -- compatible : "bcm,kona-smc" +- compatible : "brcm,kona-smc" +- DEPRECATED: compatible : "bcm,kona-smc" - reg : Location and size of bounce buffer Example: smc@0x3404c000 { - compatible = "bcm,bcm11351-smc", "bcm,kona-smc"; + compatible = "brcm,bcm11351-smc", "brcm,kona-smc"; reg = <0x3404c000 0x400>; //1 KiB in SRAM }; diff --git a/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt b/Documentation/devicetree/bindings/mmc/kona-sdhci.txt index 094ae010f2fb..789fb07a426d 100644 --- a/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/kona-sdhci.txt @@ -4,12 +4,13 @@ This file documents differences between the core properties in mmc.txt and the properties present in the bcm281xx SDHCI Required properties: -- compatible : Should be "bcm,kona-sdhci" +- compatible : Should be "brcm,kona-sdhci" +- DEPRECATED: compatible : Should be "bcm,kona-sdhci" Example: sdio2: sdio@0x3f1a0000 { - compatible = "bcm,kona-sdhci"; + compatible = "brcm,kona-sdhci"; reg = <0x3f1a0000 0x10000>; interrupts = <0x0 74 0x4>; }; diff --git a/Documentation/devicetree/bindings/net/can/atmel-can.txt b/Documentation/devicetree/bindings/net/can/atmel-can.txt index 72cf0c5daff4..14e52a0d86ec 100644 --- a/Documentation/devicetree/bindings/net/can/atmel-can.txt +++ b/Documentation/devicetree/bindings/net/can/atmel-can.txt @@ -8,7 +8,7 @@ Required properties: Example: can0: can@f000c000 { - compatbile = "atmel,at91sam9x5-can"; + compatible = "atmel,at91sam9x5-can"; reg = <0xf000c000 0x300>; interrupts = <40 4 5> }; 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/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt index f8d405897a94..9556e2fedf6d 100644 --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt @@ -1,6 +1,7 @@ * Marvell EBU PCIe interfaces Mandatory properties: + - compatible: one of the following values: marvell,armada-370-pcie marvell,armada-xp-pcie @@ -10,11 +11,49 @@ Mandatory properties: - #interrupt-cells, set to <1> - bus-range: PCI bus numbers covered - device_type, set to "pci" -- ranges: ranges for the PCI memory and I/O regions, as well as the - MMIO registers to control the PCIe interfaces. +- ranges: ranges describing the MMIO registers to control the PCIe + interfaces, and ranges describing the MBus windows needed to access + the memory and I/O regions of each PCIe interface. + +The ranges describing the MMIO registers have the following layout: + + 0x82000000 0 r MBUS_ID(0xf0, 0x01) r 0 s + +where: + + * r is a 32-bits value that gives the offset of the MMIO + registers of this PCIe interface, from the base of the internal + registers. + + * s is a 32-bits value that give the size of this MMIO + registers area. This range entry translates the '0x82000000 0 r' PCI + address into the 'MBUS_ID(0xf0, 0x01) r' CPU address, which is part + of the internal register window (as identified by MBUS_ID(0xf0, + 0x01)). + +The ranges describing the MBus windows have the following layout: + + 0x8t000000 s 0 MBUS_ID(w, a) 0 1 0 + +where: + + * t is the type of the MBus window (as defined by the standard PCI DT + bindings), 1 for I/O and 2 for memory. -In addition, the Device Tree node must have sub-nodes describing each + * s is the PCI slot that corresponds to this PCIe interface + + * w is the 'target ID' value for the MBus window + + * a the 'attribute' value for the MBus window. + +Since the location and size of the different MBus windows is not fixed in +hardware, and only determined in runtime, those ranges cover the full first +4 GB of the physical address space, and do not translate into a valid CPU +address. + +In addition, the device tree node must have sub-nodes describing each PCIe interface, having the following mandatory properties: + - reg: used only for interrupt mapping, so only the first four bytes are used to refer to the correct bus number and device number. - assigned-addresses: reference to the MMIO registers used to control @@ -26,7 +65,8 @@ PCIe interface, having the following mandatory properties: - #address-cells, set to <3> - #size-cells, set to <2> - #interrupt-cells, set to <1> -- ranges, empty property. +- ranges, translating the MBus windows ranges of the parent node into + standard PCI addresses. - interrupt-map-mask and interrupt-map, standard PCI properties to define the mapping of the PCIe interface to interrupt numbers. @@ -47,27 +87,50 @@ pcie-controller { bus-range = <0x00 0xff>; - ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000 /* Port 0.0 registers */ - 0x82000000 0 0xd0042000 0xd0042000 0 0x00002000 /* Port 2.0 registers */ - 0x82000000 0 0xd0044000 0xd0044000 0 0x00002000 /* Port 0.1 registers */ - 0x82000000 0 0xd0048000 0xd0048000 0 0x00002000 /* Port 0.2 registers */ - 0x82000000 0 0xd004c000 0xd004c000 0 0x00002000 /* Port 0.3 registers */ - 0x82000000 0 0xd0080000 0xd0080000 0 0x00002000 /* Port 1.0 registers */ - 0x82000000 0 0xd0082000 0xd0082000 0 0x00002000 /* Port 3.0 registers */ - 0x82000000 0 0xd0084000 0xd0084000 0 0x00002000 /* Port 1.1 registers */ - 0x82000000 0 0xd0088000 0xd0088000 0 0x00002000 /* Port 1.2 registers */ - 0x82000000 0 0xd008c000 0xd008c000 0 0x00002000 /* Port 1.3 registers */ - 0x82000000 0 0xe0000000 0xe0000000 0 0x08000000 /* non-prefetchable memory */ - 0x81000000 0 0 0xe8000000 0 0x00100000>; /* downstream I/O */ + ranges = + <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */ + 0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */ + 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */ + 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */ + 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */ + 0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000 /* Port 1.0 registers */ + 0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000 /* Port 3.0 registers */ + 0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000 /* Port 1.1 registers */ + 0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000 /* Port 1.2 registers */ + 0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000 /* Port 1.3 registers */ + 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */ + 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */ + 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */ + 0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 0.1 IO */ + 0x82000000 0x3 0 MBUS_ID(0x04, 0xb8) 0 1 0 /* Port 0.2 MEM */ + 0x81000000 0x3 0 MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO */ + 0x82000000 0x4 0 MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */ + 0x81000000 0x4 0 MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO */ + + 0x82000000 0x5 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */ + 0x81000000 0x5 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */ + 0x82000000 0x6 0 MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */ + 0x81000000 0x6 0 MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO */ + 0x82000000 0x7 0 MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */ + 0x81000000 0x7 0 MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO */ + 0x82000000 0x8 0 MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */ + 0x81000000 0x8 0 MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO */ + + 0x82000000 0x9 0 MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */ + 0x81000000 0x9 0 MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO */ + + 0x82000000 0xa 0 MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */ + 0x81000000 0xa 0 MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO */>; pcie@1,0 { device_type = "pci"; - assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>; + assigned-addresses = <0x82000800 0 0x40000 0 0x2000>; reg = <0x0800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0 + 0x81000000 0 0 0x81000000 0x1 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 58>; marvell,pcie-port = <0>; @@ -78,12 +141,13 @@ pcie-controller { pcie@2,0 { device_type = "pci"; - assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>; + assigned-addresses = <0x82001000 0 0x44000 0 0x2000>; reg = <0x1000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0 + 0x81000000 0 0 0x81000000 0x2 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 59>; marvell,pcie-port = <0>; @@ -94,12 +158,13 @@ pcie-controller { pcie@3,0 { device_type = "pci"; - assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>; + assigned-addresses = <0x82001800 0 0x48000 0 0x2000>; reg = <0x1800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0 + 0x81000000 0 0 0x81000000 0x3 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 60>; marvell,pcie-port = <0>; @@ -110,12 +175,13 @@ pcie-controller { pcie@4,0 { device_type = "pci"; - assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>; + assigned-addresses = <0x82002000 0 0x4c000 0 0x2000>; reg = <0x2000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0 + 0x81000000 0 0 0x81000000 0x4 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 61>; marvell,pcie-port = <0>; @@ -126,12 +192,13 @@ pcie-controller { pcie@5,0 { device_type = "pci"; - assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>; + assigned-addresses = <0x82002800 0 0x80000 0 0x2000>; reg = <0x2800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0 + 0x81000000 0 0 0x81000000 0x5 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 62>; marvell,pcie-port = <1>; @@ -142,12 +209,13 @@ pcie-controller { pcie@6,0 { device_type = "pci"; - assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>; + assigned-addresses = <0x82003000 0 0x84000 0 0x2000>; reg = <0x3000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0 + 0x81000000 0 0 0x81000000 0x6 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 63>; marvell,pcie-port = <1>; @@ -158,12 +226,13 @@ pcie-controller { pcie@7,0 { device_type = "pci"; - assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>; + assigned-addresses = <0x82003800 0 0x88000 0 0x2000>; reg = <0x3800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0 + 0x81000000 0 0 0x81000000 0x7 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 64>; marvell,pcie-port = <1>; @@ -174,12 +243,13 @@ pcie-controller { pcie@8,0 { device_type = "pci"; - assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>; + assigned-addresses = <0x82004000 0 0x8c000 0 0x2000>; reg = <0x4000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0 + 0x81000000 0 0 0x81000000 0x8 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 65>; marvell,pcie-port = <1>; @@ -187,14 +257,16 @@ pcie-controller { clocks = <&gateclk 12>; status = "disabled"; }; + pcie@9,0 { device_type = "pci"; - assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>; + assigned-addresses = <0x82004800 0 0x42000 0 0x2000>; reg = <0x4800 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0 + 0x81000000 0 0 0x81000000 0x9 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 99>; marvell,pcie-port = <2>; @@ -205,12 +277,13 @@ pcie-controller { pcie@10,0 { device_type = "pci"; - assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>; + assigned-addresses = <0x82005000 0 0x82000 0 0x2000>; reg = <0x5000 0 0 0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - ranges; + ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0 + 0x81000000 0 0 0x81000000 0xa 0 1 0>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 &mpic 103>; marvell,pcie-port = <3>; diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt new file mode 100644 index 000000000000..6b7510775c50 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt @@ -0,0 +1,163 @@ +NVIDIA Tegra PCIe controller + +Required properties: +- compatible: "nvidia,tegra20-pcie" or "nvidia,tegra30-pcie" +- device_type: Must be "pci" +- reg: A list of physical base address and length for each set of controller + registers. Must contain an entry for each entry in the reg-names property. +- reg-names: Must include the following entries: + "pads": PADS registers + "afi": AFI registers + "cs": configuration space region +- interrupts: A list of interrupt outputs of the controller. Must contain an + entry for each entry in the interrupt-names property. +- interrupt-names: Must include the following entries: + "intr": The Tegra interrupt that is asserted for controller interrupts + "msi": The Tegra interrupt that is asserted when an MSI is received +- pex-clk-supply: Supply voltage for internal reference clock +- vdd-supply: Power supply for controller (1.05V) +- avdd-supply: Power supply for controller (1.05V) (not required for Tegra20) +- bus-range: Range of bus numbers associated with this controller +- #address-cells: Address representation for root ports (must be 3) + - cell 0 specifies the bus and device numbers of the root port: + [23:16]: bus number + [15:11]: device number + - cell 1 denotes the upper 32 address bits and should be 0 + - cell 2 contains the lower 32 address bits and is used to translate to the + CPU address space +- #size-cells: Size representation for root ports (must be 2) +- ranges: Describes the translation of addresses for root ports and standard + PCI regions. The entries must be 6 cells each, where the first three cells + correspond to the address as described for the #address-cells property + above, the fourth cell is the physical CPU address to translate to and the + fifth and six cells are as described for the #size-cells property above. + - The first two entries are expected to translate the addresses for the root + port registers, which are referenced by the assigned-addresses property of + the root port nodes (see below). + - The remaining entries setup the mapping for the standard I/O, memory and + prefetchable PCI regions. The first cell determines the type of region + that is setup: + - 0x81000000: I/O memory region + - 0x82000000: non-prefetchable memory region + - 0xc2000000: prefetchable memory region + Please refer to the standard PCI bus binding document for a more detailed + explanation. +- clocks: List of clock inputs of the controller. Must contain an entry for + each entry in the clock-names property. +- clock-names: Must include the following entries: + "pex": The Tegra clock of that name + "afi": The Tegra clock of that name + "pcie_xclk": The Tegra clock of that name + "pll_e": The Tegra clock of that name + "cml": The Tegra clock of that name (not required for Tegra20) + +Root ports are defined as subnodes of the PCIe controller node. + +Required properties: +- device_type: Must be "pci" +- assigned-addresses: Address and size of the port configuration registers +- reg: PCI bus address of the root port +- #address-cells: Must be 3 +- #size-cells: Must be 2 +- ranges: Sub-ranges distributed from the PCIe controller node. An empty + property is sufficient. +- nvidia,num-lanes: Number of lanes to use for this port. Valid combinations + are: + - Root port 0 uses 4 lanes, root port 1 is unused. + - Both root ports use 2 lanes. + +Example: + +SoC DTSI: + + pcie-controller { + compatible = "nvidia,tegra20-pcie"; + device_type = "pci"; + reg = <0x80003000 0x00000800 /* PADS registers */ + 0x80003800 0x00000200 /* AFI registers */ + 0x90000000 0x10000000>; /* configuration space */ + reg-names = "pads", "afi", "cs"; + interrupts = <0 98 0x04 /* controller interrupt */ + 0 99 0x04>; /* MSI interrupt */ + interrupt-names = "intr", "msi"; + + bus-range = <0x00 0xff>; + #address-cells = <3>; + #size-cells = <2>; + + ranges = <0x82000000 0 0x80000000 0x80000000 0 0x00001000 /* port 0 registers */ + 0x82000000 0 0x80001000 0x80001000 0 0x00001000 /* port 1 registers */ + 0x81000000 0 0 0x82000000 0 0x00010000 /* downstream I/O */ + 0x82000000 0 0xa0000000 0xa0000000 0 0x10000000 /* non-prefetchable memory */ + 0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */ + + clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>, + <&tegra_car 118>; + clock-names = "pex", "afi", "pcie_xclk", "pll_e"; + status = "disabled"; + + pci@1,0 { + device_type = "pci"; + assigned-addresses = <0x82000800 0 0x80000000 0 0x1000>; + reg = <0x000800 0 0 0 0>; + status = "disabled"; + + #address-cells = <3>; + #size-cells = <2>; + + ranges; + + nvidia,num-lanes = <2>; + }; + + pci@2,0 { + device_type = "pci"; + assigned-addresses = <0x82001000 0 0x80001000 0 0x1000>; + reg = <0x001000 0 0 0 0>; + status = "disabled"; + + #address-cells = <3>; + #size-cells = <2>; + + ranges; + + nvidia,num-lanes = <2>; + }; + }; + + +Board DTS: + + pcie-controller { + status = "okay"; + + vdd-supply = <&pci_vdd_reg>; + pex-clk-supply = <&pci_clk_reg>; + + /* root port 00:01.0 */ + pci@1,0 { + status = "okay"; + + /* bridge 01:00.0 (optional) */ + pci@0,0 { + reg = <0x010000 0 0 0 0>; + + #address-cells = <3>; + #size-cells = <2>; + + device_type = "pci"; + + /* endpoint 02:00.0 */ + pci@0,0 { + reg = <0x020000 0 0 0 0>; + }; + }; + }; + }; + +Note that devices on the PCI bus are dynamically discovered using PCI's bus +enumeration and therefore don't need corresponding device nodes in DT. However +if a device on the PCI bus provides a non-probeable bus such as I2C or SPI, +device nodes need to be added in order to allow the bus' children to be +instantiated at the proper location in the operating system's device tree (as +illustrated by the optional nodes in the example above). diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt index 648d60eb9fd8..7ccae490ff6d 100644 --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt @@ -37,7 +37,7 @@ Bank: 3 (A, B and C) 0xffffffff 0x7fff3ccf /* pioB */ 0xffffffff 0x007fffff /* pioC */ -For each peripheral/bank we will descibe in a u32 if a pin can can be +For each peripheral/bank we will descibe in a u32 if a pin can be configured in it by putting 1 to the pin bit (1 << pin) Let's take the pioA on peripheral B diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt index e204d009f16c..fb70856c5b51 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt @@ -80,6 +80,17 @@ Valid values for pin and group names are: dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg, gmh, owr, uda. +Valid values for nvidia,functions are: + + blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3, displaya, + displaya_alt, displayb, dtv, emc_dll, extperiph1, extperiph2, + extperiph3, gmi, gmi_alt, hda, hsi, i2c1, i2c2, i2c3, i2c4, i2cpwr, + i2s0, i2s1, i2s2, i2s3, i2s4, irda, kbc, nand, nand_alt, owr, pmi, + pwm0, pwm1, pwm2, pwm3, pwron, reset_out_n, rsvd1, rsvd2, rsvd3, + rsvd4, sdmmc1, sdmmc2, sdmmc3, sdmmc4, soc, spdif, spi1, spi2, spi3, + spi4, spi5, spi6, sysclk, trace, uarta, uartb, uartc, uartd, ulpi, + usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, vi, vi_alt1, vi_alt3 + Example: pinmux: pinmux { diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt index 683fde93c4fb..61e73cde9ae9 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt @@ -103,6 +103,17 @@ Valid values for pin and group names are: drive_gma, drive_gmb, drive_gmc, drive_gmd, drive_gme, drive_owr, drive_uda. +Valid values for nvidia,functions are: + + ahb_clk, apb_clk, audio_sync, crt, dap1, dap2, dap3, dap4, dap5, + displaya, displayb, emc_test0_dll, emc_test1_dll, gmi, gmi_int, + hdmi, i2cp, i2c1, i2c2, i2c3, ide, irda, kbc, mio, mipi_hs, nand, + osc, owr, pcie, plla_out, pllc_out1, pllm_out1, pllp_out2, pllp_out3, + pllp_out4, pwm, pwr_intr, pwr_on, rsvd1, rsvd2, rsvd3, rsvd4, rtck, + sdio1, sdio2, sdio3, sdio4, sflash, spdif, spi1, spi2, spi2_alt, + spi3, spi4, trace, twc, uarta, uartb, uartc, uartd, uarte, ulpi, + vi, vi_sensor_clk, xio + Example: pinctrl@70000000 { diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt index 6f426ed7009e..0e6354c11e6d 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt @@ -91,6 +91,18 @@ Valid values for pin and group names are: gmh, gpv, lcd1, lcd2, owr, sdio1, sdio2, sdio3, spi, uaa, uab, uart2, uart3, uda, vi1. +Valid values for nvidia,functions are: + + blink, cec, clk_12m_out, clk_32k_in, core_pwr_req, cpu_pwr_req, crt, + dap, ddr, dev3, displaya, displayb, dtv, extperiph1, extperiph2, + extperiph3, gmi, gmi_alt, hda, hdcp, hdmi, hsi, i2c1, i2c2, i2c3, + i2c4, i2cpwr, i2s0, i2s1, i2s2, i2s3, i2s4, invalid, kbc, mio, nand, + nand_alt, owr, pcie, pwm0, pwm1, pwm2, pwm3, pwr_int_n, rsvd1, rsvd2, + rsvd3, rsvd4, rtck, sata, sdmmc1, sdmmc2, sdmmc3, sdmmc4, spdif, spi1, + spi2, spi2_alt, spi3, spi4, spi5, spi6, sysclk, test, trace, uarta, + uartb, uartc, uartd, uarte, ulpi, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, + vi, vi_alt1, vi_alt2, vi_alt3 + Example: pinctrl@70000000 { 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/pinctrl/ste,nomadik.txt b/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt index 9a2f3f420526..6b33b9f18e88 100644 --- a/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt +++ b/Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt @@ -1,8 +1,8 @@ ST Ericsson Nomadik pinmux controller Required properties: -- compatible: "stericsson,nmk-pinctrl", "stericsson,nmk-pinctrl-db8540", - "stericsson,nmk-pinctrl-stn8815" +- compatible: "stericsson,db8500-pinctrl", "stericsson,db8540-pinctrl", + "stericsson,stn8815-pinctrl" - reg: Should contain the register physical address and length of the PRCMU. Please refer to pinctrl-bindings.txt in this directory for details of the @@ -68,7 +68,7 @@ Optional subnode-properties: Example board file extract: pinctrl@80157000 { - compatible = "stericsson,nmk-pinctrl"; + compatible = "stericsson,db8500-pinctrl"; reg = <0x80157000 0x2000>; pinctrl-names = "default"; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt index 5693877ab377..82dd5b65cf48 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt @@ -1,21 +1,20 @@ * Freescale MSI interrupt controller Required properties: -- compatible : compatible list, contains 2 entries, - first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572, - etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on - the parent type. +- compatible : compatible list, may contain one or two entries + The first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572, + etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" or + "fsl,mpic-msi-v4.3" depending on the parent type and version. If mpic + version is 4.3, the number of MSI registers is increased to 16, MSIIR1 is + provided to access these 16 registers, and compatible "fsl,mpic-msi-v4.3" + should be used. The first entry is optional; the second entry is + required. - reg : It may contain one or two regions. The first region should contain the address and the length of the shared message interrupt register set. - The second region should contain the address of aliased MSIIR register for - platforms that have such an alias. - -- msi-available-ranges: use <start count> style section to define which - msi interrupt can be used in the 256 msi interrupts. This property is - optional, without this, all the 256 MSI interrupts can be used. - Each available range must begin and end on a multiple of 32 (i.e. - no splitting an individual MSI register or the associated PIC interrupt). + The second region should contain the address of aliased MSIIR or MSIIR1 + register for platforms that have such an alias, if using MSIIR1, the second + region must be added because different MSI group has different MSIIR1 offset. - interrupts : each one of the interrupts here is one entry per 32 MSIs, and routed to the host interrupt controller. the interrupts should @@ -28,6 +27,14 @@ Required properties: to MPIC. Optional properties: +- msi-available-ranges: use <start count> style section to define which + msi interrupt can be used in the 256 msi interrupts. This property is + optional, without this, all the MSI interrupts can be used. + Each available range must begin and end on a multiple of 32 (i.e. + no splitting an individual MSI register or the associated PIC interrupt). + MPIC v4.3 does not support this property because the 32 interrupts of an + individual register are not continuous when using MSIIR1. + - msi-address-64: 64-bit PCI address of the MSIIR register. The MSIIR register is used for MSI messaging. The address of MSIIR in PCI address space is the MSI message address. @@ -54,6 +61,28 @@ Example: interrupt-parent = <&mpic>; }; + msi@41600 { + compatible = "fsl,mpic-msi-v4.3"; + reg = <0x41600 0x200 0x44148 4>; + interrupts = < + 0xe0 0 0 0 + 0xe1 0 0 0 + 0xe2 0 0 0 + 0xe3 0 0 0 + 0xe4 0 0 0 + 0xe5 0 0 0 + 0xe6 0 0 0 + 0xe7 0 0 0 + 0x100 0 0 0 + 0x101 0 0 0 + 0x102 0 0 0 + 0x103 0 0 0 + 0x104 0 0 0 + 0x105 0 0 0 + 0x106 0 0 0 + 0x107 0 0 0>; + }; + The Freescale hypervisor and msi-address-64 ------------------------------------------- Normally, PCI devices have access to all of CCSR via an ATMU mapping. The diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index a22e4c70db5c..875639ae0606 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -36,6 +36,9 @@ Optional nodes: ti,smps-range - OTP has the wrong range set for the hardware so override 0 - low range, 1 - high range. +- ti,system-power-controller: Telling whether or not this pmic is controlling + the system power. + Example: #include <dt-bindings/interrupt-controller/irq.h> @@ -48,6 +51,8 @@ pmic { ti,ldo6-vibrator; + ti,system-power-controller; + regulators { smps12_reg : smps12 { regulator-name = "smps12"; diff --git a/Documentation/devicetree/bindings/rtc/dw-apb.txt b/Documentation/devicetree/bindings/rtc/dw-apb.txt index eb2327b2bdb3..c703d51abb6c 100644 --- a/Documentation/devicetree/bindings/rtc/dw-apb.txt +++ b/Documentation/devicetree/bindings/rtc/dw-apb.txt @@ -1,7 +1,10 @@ * Designware APB timer Required properties: -- compatible: "snps,dw-apb-timer-sp" or "snps,dw-apb-timer-osc" +- compatible: One of: + "snps,dw-apb-timer" + "snps,dw-apb-timer-sp" <DEPRECATED> + "snps,dw-apb-timer-osc" <DEPRECATED> - reg: physical base address of the controller and length of memory mapped region. - interrupts: IRQ line for the timer. @@ -20,25 +23,10 @@ systems may use one. Example: - - timer1: timer@ffc09000 { - compatible = "snps,dw-apb-timer-sp"; - interrupts = <0 168 4>; - clock-frequency = <200000000>; - reg = <0xffc09000 0x1000>; - }; - - timer2: timer@ffd00000 { - compatible = "snps,dw-apb-timer-osc"; - interrupts = <0 169 4>; - clock-frequency = <200000000>; - reg = <0xffd00000 0x1000>; - }; - - timer3: timer@ffe00000 { - compatible = "snps,dw-apb-timer-osc"; - interrupts = <0 170 4>; - reg = <0xffe00000 0x1000>; - clocks = <&timer_clk>, <&timer_pclk>; - clock-names = "timer", "pclk"; - }; + timer@ffe00000 { + compatible = "snps,dw-apb-timer"; + interrupts = <0 170 4>; + reg = <0xffe00000 0x1000>; + clocks = <&timer_clk>, <&timer_pclk>; + clock-names = "timer", "pclk"; + }; diff --git a/Documentation/devicetree/bindings/serial/altera_jtaguart.txt b/Documentation/devicetree/bindings/serial/altera_jtaguart.txt index c152f65f9a28..55a901051e8f 100644 --- a/Documentation/devicetree/bindings/serial/altera_jtaguart.txt +++ b/Documentation/devicetree/bindings/serial/altera_jtaguart.txt @@ -1,4 +1,5 @@ Altera JTAG UART Required properties: -- compatible : should be "ALTR,juart-1.0" +- compatible : should be "ALTR,juart-1.0" <DEPRECATED> +- compatible : should be "altr,juart-1.0" diff --git a/Documentation/devicetree/bindings/serial/altera_uart.txt b/Documentation/devicetree/bindings/serial/altera_uart.txt index 71cae3f70100..81bf7ffb1a81 100644 --- a/Documentation/devicetree/bindings/serial/altera_uart.txt +++ b/Documentation/devicetree/bindings/serial/altera_uart.txt @@ -1,7 +1,8 @@ Altera UART Required properties: -- compatible : should be "ALTR,uart-1.0" +- compatible : should be "ALTR,uart-1.0" <DEPRECATED> +- compatible : should be "altr,uart-1.0" Optional properties: - clock-frequency : frequency of the clock input to the UART 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/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt index 1e753c69fc83..32b1fa1f2a5b 100644 --- a/Documentation/devicetree/bindings/serial/rs485.txt +++ b/Documentation/devicetree/bindings/serial/rs485.txt @@ -7,7 +7,7 @@ UART node. Required properties: - rs485-rts-delay: prop-encoded-array <a b> where: - * a is the delay beteween rts signal and beginning of data sent in milliseconds. + * a is the delay between rts signal and beginning of data sent in milliseconds. it corresponds to the delay before sending data. * b is the delay between end of data sent and rts signal in milliseconds it corresponds to the delay after sending data and actual release of the line. diff --git a/Documentation/devicetree/bindings/serio/altera_ps2.txt b/Documentation/devicetree/bindings/serio/altera_ps2.txt index 4d9eecc2ef7d..520199e2e347 100644 --- a/Documentation/devicetree/bindings/serio/altera_ps2.txt +++ b/Documentation/devicetree/bindings/serio/altera_ps2.txt @@ -1,4 +1,5 @@ Altera UP PS/2 controller Required properties: -- compatible : should be "ALTR,ps2-1.0". +- compatible : should be "ALTR,ps2-1.0". <DEPRECATED> +- compatible : should be "altr,ps2-1.0". 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/spi_altera.txt b/Documentation/devicetree/bindings/spi/spi_altera.txt index dda375943506..31319dcf30ab 100644 --- a/Documentation/devicetree/bindings/spi/spi_altera.txt +++ b/Documentation/devicetree/bindings/spi/spi_altera.txt @@ -1,4 +1,5 @@ Altera SPI Required properties: -- compatible : should be "ALTR,spi-1.0". +- compatible : should be "ALTR,spi-1.0". <DEPRECATED> +- compatible : should be "altr,spi-1.0". diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ec4d713674fa..2956800f0240 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -7,6 +7,7 @@ ad Avionic Design GmbH adi Analog Devices, Inc. aeroflexgaisler Aeroflex Gaisler AB ak Asahi Kasei Corp. +altr Altera Corp. amcc Applied Micro Circuits Corporation (APM, formally AMCC) apm Applied Micro Circuits Corporation (APM) arm ARM Ltd. @@ -37,6 +38,7 @@ linux Linux-specific binding lsi LSI Corp. (LSI Logic) marvell Marvell Technology Group Ltd. maxim Maxim Integrated Products +microchip Microchip Technology Inc. mosaixtech Mosaix Technologies, Inc. national National Semiconductor nintendo Nintendo 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/devicetree/bindings/watchdog/sun4i-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt index ecd650adff31..e39cb266c8f4 100644 --- a/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt @@ -1,8 +1,9 @@ -Allwinner sun4i Watchdog timer +Allwinner SoCs Watchdog timer Required properties: -- compatible : should be "allwinner,sun4i-wdt" +- compatible : should be "allwinner,<soc-family>-wdt", the currently supported + SoC families being sun4i and sun6i - reg : Specifies base physical address and size of the registers. Example: diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 0b23261561d2..e31a2a9d2b07 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -321,7 +321,7 @@ Access to a dma_buf from the kernel context involves three steps: When the importer is done accessing the range specified in begin_cpu_access, it needs to announce this to the exporter (to facilitate cache flushing and - unpinning of any pinned resources). The result of of any dma_buf kmap calls + unpinning of any pinned resources). The result of any dma_buf kmap calls after end_cpu_access is undefined. Interface: diff --git a/Documentation/early-userspace/README b/Documentation/early-userspace/README index 661a73fad399..93e63a9af30b 100644 --- a/Documentation/early-userspace/README +++ b/Documentation/early-userspace/README @@ -83,8 +83,7 @@ Where's this all leading? The klibc distribution contains some of the necessary software to make early userspace useful. The klibc distribution is currently -maintained separately from the kernel, but this may change early in -the 2.7 era (it missed the boat for 2.5). +maintained separately from the kernel. You can obtain somewhat infrequent snapshots of klibc from ftp://ftp.kernel.org/pub/linux/libs/klibc/ diff --git a/Documentation/fb/fbcon.txt b/Documentation/fb/fbcon.txt index 99ea58e65eff..4a9739abc860 100644 --- a/Documentation/fb/fbcon.txt +++ b/Documentation/fb/fbcon.txt @@ -150,7 +150,7 @@ C. Boot options C. Attaching, Detaching and Unloading -Before going on on how to attach, detach and unload the framebuffer console, an +Before going on how to attach, detach and unload the framebuffer console, an illustration of the dependencies may help. The console layer, as with most subsystems, needs a driver that interfaces with diff --git a/Documentation/fb/viafb.modes b/Documentation/fb/viafb.modes index 02e5b487f00e..2a547da2e5cc 100644 --- a/Documentation/fb/viafb.modes +++ b/Documentation/fb/viafb.modes @@ -571,7 +571,7 @@ mode "640x480-60" # 160 chars 800 lines # Blank Time 4.798 us 0.564 ms # 50 chars 28 lines -# Polarity negtive positive +# Polarity negative positive # mode "1280x800-60" # D: 83.500 MHz, H: 49.702 kHz, V: 60.00 Hz diff --git a/Documentation/fb/viafb.txt b/Documentation/fb/viafb.txt index 444e34b52ae1..1cb2462a71ce 100644 --- a/Documentation/fb/viafb.txt +++ b/Documentation/fb/viafb.txt @@ -32,7 +32,7 @@ Start viafb with default settings: #modprobe viafb - Start viafb with with user options: + Start viafb with user options: #modprobe viafb viafb_mode=800x600 viafb_bpp=16 viafb_refresh=60 viafb_active_dev=CRT+DVI viafb_dvi_port=DVP1 viafb_mode1=1024x768 viafb_bpp=16 viafb_refresh1=60 diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index b349d57b76ea..9dae59407437 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -87,7 +87,7 @@ Unless otherwise specified, all options default to off. device=<devicepath> Specify a device during mount so that ioctls on the control device - can be avoided. Especialy useful when trying to mount a multi-device + can be avoided. Especially useful when trying to mount a multi-device setup as root. May be specified multiple times for multiple devices. discard diff --git a/Documentation/filesystems/caching/backend-api.txt b/Documentation/filesystems/caching/backend-api.txt index d78bab9622c6..277d1e810670 100644 --- a/Documentation/filesystems/caching/backend-api.txt +++ b/Documentation/filesystems/caching/backend-api.txt @@ -299,6 +299,15 @@ performed on the denizens of the cache. These are held in a structure of type: enough space in the cache to permit this. + (*) Check coherency state of an object [mandatory]: + + int (*check_consistency)(struct fscache_object *object) + + This method is called to have the cache check the saved auxiliary data of + the object against the netfs's idea of the state. 0 should be returned + if they're consistent and -ESTALE otherwise. -ENOMEM and -ERESTARTSYS + may also be returned. + (*) Update object [mandatory]: int (*update_object)(struct fscache_object *object) diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt index 97e6c0ecc5ef..11a0a40ce445 100644 --- a/Documentation/filesystems/caching/netfs-api.txt +++ b/Documentation/filesystems/caching/netfs-api.txt @@ -32,7 +32,7 @@ This document contains the following sections: (9) Setting the data file size (10) Page alloc/read/write (11) Page uncaching - (12) Index and data file update + (12) Index and data file consistency (13) Miscellaneous cookie operations (14) Cookie unregistration (15) Index invalidation @@ -433,7 +433,7 @@ to the caller. The attribute adjustment excludes read and write operations. ===================== -PAGE READ/ALLOC/WRITE +PAGE ALLOC/READ/WRITE ===================== And the sixth step is to store and retrieve pages in the cache. There are @@ -499,7 +499,7 @@ Else if there's a copy of the page resident in the cache: (*) An argument that's 0 on success or negative for an error code. If an error occurs, it should be assumed that the page contains no usable - data. + data. fscache_readpages_cancel() may need to be called. end_io_func() will be called in process context if the read is results in an error, but it might be called in interrupt context if the read is @@ -623,6 +623,22 @@ some of the pages being read and some being allocated. Those pages will have been marked appropriately and will need uncaching. +CANCELLATION OF UNREAD PAGES +---------------------------- + +If one or more pages are passed to fscache_read_or_alloc_pages() but not then +read from the cache and also not read from the underlying filesystem then +those pages will need to have any marks and reservations removed. This can be +done by calling: + + void fscache_readpages_cancel(struct fscache_cookie *cookie, + struct list_head *pages); + +prior to returning to the caller. The cookie argument should be as passed to +fscache_read_or_alloc_pages(). Every page in the pages list will be examined +and any that have PG_fscache set will be uncached. + + ============== PAGE UNCACHING ============== @@ -690,9 +706,18 @@ written to the cache and for the cache to finish with the page generally. No error is returned. -========================== -INDEX AND DATA FILE UPDATE -========================== +=============================== +INDEX AND DATA FILE CONSISTENCY +=============================== + +To find out whether auxiliary data for an object is up to data within the +cache, the following function can be called: + + int fscache_check_consistency(struct fscache_cookie *cookie) + +This will call back to the netfs to check whether the auxiliary data associated +with a cookie is correct. It returns 0 if it is and -ESTALE if it isn't; it +may also return -ENOMEM and -ERESTARTSYS. To request an update of the index data for an index or other object, the following function should be called: diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index 293855e95000..7ed0d17d6721 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt @@ -26,11 +26,12 @@ journal=inum When a journal already exists, this option is ignored. Otherwise, it specifies the number of the inode which will represent the ext3 file system's journal file. +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 this forces noload mount of inconsistent filesystem, which can lead to diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index f7cbf574a875..919a3293aaa4 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -2,7 +2,7 @@ Ext4 Filesystem =============== -Ext4 is an an advanced level of the ext3 filesystem which incorporates +Ext4 is an advanced level of the ext3 filesystem which incorporates scalability and reliability enhancements for supporting large filesystems (64 bit) in keeping with increasing disk capacities and state-of-the-art feature requirements. @@ -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/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index b91e2f26b672..3cd27bed6349 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -18,8 +18,8 @@ according to its internal geometry or flash memory management scheme, namely FTL F2FS and its tools support various parameters not only for configuring on-disk layout, but also for selecting allocation and cleaning algorithms. -The file system formatting tool, "mkfs.f2fs", is available from the following -git tree: +The following git tree provides the file system formatting tool (mkfs.f2fs), +a consistency checking tool (fsck.f2fs), and a debugging tool (dump.f2fs). >> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git For reporting bugs and sending patches, please use the following mailing list: @@ -133,6 +133,38 @@ f2fs. Each file shows the whole f2fs information. - current memory footprint consumed by f2fs. ================================================================================ +SYSFS ENTRIES +================================================================================ + +Information about mounted f2f2 file systems can be found in +/sys/fs/f2fs. Each mounted filesystem will have a directory in +/sys/fs/f2fs based on its device name (i.e., /sys/fs/f2fs/sda). +The files in each per-device directory are shown in table below. + +Files in /sys/fs/f2fs/<devname> +(see also Documentation/ABI/testing/sysfs-fs-f2fs) +.............................................................................. + File Content + + gc_max_sleep_time This tuning parameter controls the maximum sleep + time for the garbage collection thread. Time is + in milliseconds. + + gc_min_sleep_time This tuning parameter controls the minimum sleep + time for the garbage collection thread. Time is + in milliseconds. + + gc_no_gc_sleep_time This tuning parameter controls the default sleep + time for the garbage collection thread. Time is + in milliseconds. + + gc_idle This parameter controls the selection of victim + policy for garbage collection. Setting gc_idle = 0 + (default) will disable this option. Setting + gc_idle = 1 will select the Cost Benefit approach + & setting gc_idle = 2 will select the greedy aproach. + +================================================================================ USAGE ================================================================================ @@ -149,8 +181,12 @@ USAGE # mkfs.f2fs -l label /dev/block_device # mount -t f2fs /dev/block_device /mnt/f2fs -Format options --------------- +mkfs.f2fs +--------- +The mkfs.f2fs is for the use of formatting a partition as the f2fs filesystem, +which builds a basic on-disk layout. + +The options consist of: -l [label] : Give a volume label, up to 512 unicode name. -a [0 or 1] : Split start location of each area for heap-based allocation. 1 is set by default, which performs this. @@ -164,6 +200,37 @@ Format options -t [0 or 1] : Disable discard command or not. 1 is set by default, which conducts discard. +fsck.f2fs +--------- +The fsck.f2fs is a tool to check the consistency of an f2fs-formatted +partition, which examines whether the filesystem metadata and user-made data +are cross-referenced correctly or not. +Note that, initial version of the tool does not fix any inconsistency. + +The options consist of: + -d debug level [default:0] + +dump.f2fs +--------- +The dump.f2fs shows the information of specific inode and dumps SSA and SIT to +file. Each file is dump_ssa and dump_sit. + +The dump.f2fs is used to debug on-disk data structures of the f2fs filesystem. +It shows on-disk inode information reconized by a given inode number, and is +able to dump all the SSA and SIT entries into predefined files, ./dump_ssa and +./dump_sit respectively. + +The options consist of: + -d debug level [default:0] + -i inode no (hex) + -s [SIT dump segno from #1~#2 (decimal), for all 0~-1] + -a [SSA dump segno from #1~#2 (decimal), for all 0~-1] + +Examples: +# dump.f2fs -i [ino] /dev/sdx +# dump.f2fs -s 0~-1 /dev/sdx (SIT dump) +# dump.f2fs -a 0~-1 /dev/sdx (SSA dump) + ================================================================================ DESIGN ================================================================================ diff --git a/Documentation/filesystems/nfs/Exporting b/Documentation/filesystems/nfs/Exporting index 09994c247289..e543b1a619cc 100644 --- a/Documentation/filesystems/nfs/Exporting +++ b/Documentation/filesystems/nfs/Exporting @@ -93,7 +93,7 @@ For a filesystem to be exportable it must: 2/ make sure that d_splice_alias is used rather than d_add when ->lookup finds an inode for a given parent and name. - If inode is NULL, d_splice_alias(inode, dentry) is eqivalent to + If inode is NULL, d_splice_alias(inode, dentry) is equivalent to d_add(dentry, inode), NULL diff --git a/Documentation/filesystems/nfs/pnfs.txt b/Documentation/filesystems/nfs/pnfs.txt index 52ae07f5f578..adc81a35fe2d 100644 --- a/Documentation/filesystems/nfs/pnfs.txt +++ b/Documentation/filesystems/nfs/pnfs.txt @@ -12,7 +12,7 @@ struct pnfs_layout_hdr ---------------------- The on-the-wire command LAYOUTGET corresponds to struct pnfs_layout_segment, usually referred to by the variable name lseg. -Each nfs_inode may hold a pointer to a cache of of these layout +Each nfs_inode may hold a pointer to a cache of these layout segments in nfsi->layout, of type struct pnfs_layout_hdr. We reference the header for the inode pointing to it, across each diff --git a/Documentation/filesystems/qnx6.txt b/Documentation/filesystems/qnx6.txt index 99e90184a72f..408679789136 100644 --- a/Documentation/filesystems/qnx6.txt +++ b/Documentation/filesystems/qnx6.txt @@ -149,7 +149,7 @@ Bitmap system area ------------------ The bitmap itself is divided into three parts. -First the system area, that is split into two halfs. +First the system area, that is split into two halves. Then userspace. The requirement for a static, fixed preallocated system area comes from how diff --git a/Documentation/filesystems/relay.txt b/Documentation/filesystems/relay.txt index 510b722667ac..33e2f3694733 100644 --- a/Documentation/filesystems/relay.txt +++ b/Documentation/filesystems/relay.txt @@ -31,7 +31,7 @@ Semantics Each relay channel has one buffer per CPU, each buffer has one or more sub-buffers. Messages are written to the first sub-buffer until it is -too full to contain a new message, in which case it it is written to +too full to contain a new message, in which case it is written to the next (if available). Messages are never split across sub-buffers. At this point, userspace can be notified so it empties the first sub-buffer, while the kernel continues writing to the next. diff --git a/Documentation/filesystems/sysfs-tagging.txt b/Documentation/filesystems/sysfs-tagging.txt index caaaf1266d8f..eb843e49c5a3 100644 --- a/Documentation/filesystems/sysfs-tagging.txt +++ b/Documentation/filesystems/sysfs-tagging.txt @@ -24,7 +24,7 @@ flag between KOBJ_NS_TYPE_NONE and KOBJ_NS_TYPES, and s_ns will point to the namespace to which it belongs. Each sysfs superblock's sysfs_super_info contains an array void -*ns[KOBJ_NS_TYPES]. When a a task in a tagging namespace +*ns[KOBJ_NS_TYPES]. When a task in a tagging namespace kobj_nstype first mounts sysfs, a new superblock is created. It will be differentiated from other sysfs mounts by having its s_fs_info->ns[kobj_nstype] set to the new namespace. Note that diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 12525b17d9ed..5be51fd888bd 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt @@ -135,7 +135,7 @@ default behaviour. If the memory cost of 8 log buffers is too high on small systems, then it may be reduced at some cost to performance on metadata intensive workloads. The logbsize option below - controls the size of each buffer and so is also relevent to + controls the size of each buffer and so is also relevant to this case. logbsize=value diff --git a/Documentation/fmc/carrier.txt b/Documentation/fmc/carrier.txt index 173f6d65c88d..5e4f1dd3e98b 100644 --- a/Documentation/fmc/carrier.txt +++ b/Documentation/fmc/carrier.txt @@ -213,7 +213,7 @@ The individual methods perform the following tasks: methods: for example the SPEC driver may define that its carrier I2C memory is seen at offset 1M and the internal SPI flash is seen at offset 16M. This multiplexing of several flash memories in the - same address space is is carrier-specific and should only be used + same address space is carrier-specific and should only be used by a driver that has verified the `carrier_name' field. diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt index 3c741214dfbb..dc35a2b75eee 100644 --- a/Documentation/hid/uhid.txt +++ b/Documentation/hid/uhid.txt @@ -149,11 +149,13 @@ needs. Only UHID_OUTPUT and UHID_OUTPUT_EV have payloads. is of type "struct uhid_data_req". This may be received even though you haven't received UHID_OPEN, yet. - UHID_OUTPUT_EV: + UHID_OUTPUT_EV (obsolete): Same as UHID_OUTPUT but this contains a "struct input_event" as payload. This is called for force-feedback, LED or similar events which are received through an input device by the HID subsystem. You should convert this into raw reports and send them to your device similar to events of type UHID_OUTPUT. + This is no longer sent by newer kernels. Instead, HID core converts it into a + raw output report and sends it via UHID_OUTPUT. UHID_FEATURE: This event is sent if the kernel driver wants to perform a feature request as diff --git a/Documentation/hwmon/abituguru-datasheet b/Documentation/hwmon/abituguru-datasheet index 8d2be8a0b1e3..86c0b1251c81 100644 --- a/Documentation/hwmon/abituguru-datasheet +++ b/Documentation/hwmon/abituguru-datasheet @@ -299,7 +299,7 @@ Byte 1: min threshold (scale as bank 0x26) -Warning for the adventerous +Warning for the adventurous =========================== A word of caution to those who want to experiment and see if they can figure diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches index 46286460462b..3d1bac399a22 100644 --- a/Documentation/hwmon/submitting-patches +++ b/Documentation/hwmon/submitting-patches @@ -1,7 +1,7 @@ How to Get Your Patch Accepted Into the Hwmon Subsystem ------------------------------------------------------- -This text is is a collection of suggestions for people writing patches or +This text is a collection of suggestions for people writing patches or drivers for the hwmon subsystem. Following these suggestions will greatly increase the chances of your change being accepted. diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d index 90387c3540f7..f4021a285460 100644 --- a/Documentation/hwmon/w83791d +++ b/Documentation/hwmon/w83791d @@ -17,7 +17,7 @@ Credits: Philip Edelbrock <phil@netroedge.com>, and Mark Studebaker <mdsxyz123@yahoo.com> w83792d.c: - Chunhao Huang <DZShen@Winbond.com.tw>, + Shane Huang (Winbond), Rudolf Marek <r.marek@assembler.cz> Additional contributors: diff --git a/Documentation/hwmon/w83792d b/Documentation/hwmon/w83792d index 8a023ce0b72e..53f7b6866fec 100644 --- a/Documentation/hwmon/w83792d +++ b/Documentation/hwmon/w83792d @@ -7,8 +7,7 @@ Supported chips: Addresses scanned: I2C 0x2c - 0x2f Datasheet: http://www.winbond.com.tw -Author: Chunhao Huang -Contact: DZShen <DZShen@Winbond.com.tw> +Author: Shane Huang (Winbond) Module Parameters diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt index a903ee5e9776..62f7d4ea6e26 100644 --- a/Documentation/hwspinlock.txt +++ b/Documentation/hwspinlock.txt @@ -241,7 +241,7 @@ int hwspinlock_example2(void) locks). Should be called from a process context (this function might sleep). Returns the address of hwspinlock on success, or NULL on error (e.g. - if the hwspinlock is sill in use). + if the hwspinlock is still in use). 5. Important structs 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/i2c/upgrading-clients b/Documentation/i2c/upgrading-clients index d6991625c407..8e5fbd88c7d1 100644 --- a/Documentation/i2c/upgrading-clients +++ b/Documentation/i2c/upgrading-clients @@ -196,8 +196,8 @@ static int example_probe(struct i2c_client *i2c_client, Update the detach method, by changing the name to _remove and to delete the i2c_detach_client call. It is possible that you -can also remove the ret variable as it is not not needed for -any of the core functions. +can also remove the ret variable as it is not needed for any +of the core functions. - static int example_detach(struct i2c_client *client) + static int example_remove(struct i2c_client *client) diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt new file mode 100644 index 000000000000..8002c894c6b0 --- /dev/null +++ b/Documentation/input/gamepad.txt @@ -0,0 +1,156 @@ + Linux Gamepad API +---------------------------------------------------------------------------- + +1. Intro +~~~~~~~~ +Linux provides many different input drivers for gamepad hardware. To avoid +having user-space deal with different button-mappings for each gamepad, this +document defines how gamepads are supposed to report their data. + +2. Geometry +~~~~~~~~~~~ +As "gamepad" we define devices which roughly look like this: + + ____________________________ __ + / [__ZL__] [__ZR__] \ | + / [__ TL __] [__ TR __] \ | Front Triggers + __/________________________________\__ __| + / _ \ | + / /\ __ (N) \ | + / || __ |MO| __ _ _ \ | Main Pad + | <===DP===> |SE| |ST| (W) -|- (E) | | + \ || ___ ___ _ / | + /\ \/ / \ / \ (S) /\ __| + / \________ | LS | ____ | RS | ________/ \ | + | / \ \___/ / \ \___/ / \ | | Control Sticks + | / \_____/ \_____/ \ | __| + | / \ | + \_____/ \_____/ + + |________|______| |______|___________| + D-Pad Left Right Action Pad + Stick Stick + + |_____________| + Menu Pad + +Most gamepads have the following features: + - Action-Pad + 4 buttons in diamonds-shape (on the right side). The buttons are + differently labeled on most devices so we define them as NORTH, + SOUTH, WEST and EAST. + - D-Pad (Direction-pad) + 4 buttons (on the left side) that point up, down, left and right. + - Menu-Pad + Different constellations, but most-times 2 buttons: SELECT - START + Furthermore, many gamepads have a fancy branded button that is used as + special system-button. It often looks different to the other buttons and + is used to pop up system-menus or system-settings. + - Analog-Sticks + Analog-sticks provide freely moveable sticks to control directions. Not + all devices have both or any, but they are present at most times. + Analog-sticks may also provide a digital button if you press them. + - Triggers + Triggers are located on the upper-side of the pad in vertical direction. + Not all devices provide them, but the upper buttons are normally named + Left- and Right-Triggers, the lower buttons Z-Left and Z-Right. + - Rumble + Many devices provide force-feedback features. But are mostly just + simple rumble motors. + +3. Detection +~~~~~~~~~~~~ +All gamepads that follow the protocol described here map BTN_GAMEPAD. This is +an alias for BTN_SOUTH/BTN_A. It can be used to identify a gamepad as such. +However, not all gamepads provide all features, so you need to test for all +features that you need, first. How each feature is mapped is described below. + +Legacy drivers often don't comply to these rules. As we cannot change them +for backwards-compatibility reasons, you need to provide fixup mappings in +user-space yourself. Some of them might also provide module-options that +change the mappings so you can adivce users to set these. + +All new gamepads are supposed to comply with this mapping. Please report any +bugs, if they don't. + +There are a lot of less-featured/less-powerful devices out there, which re-use +the buttons from this protocol. However, they try to do this in a compatible +fashion. For example, the "Nintendo Wii Nunchuk" provides two trigger buttons +and one analog stick. It reports them as if it were a gamepad with only one +analog stick and two trigger buttons on the right side. +But that means, that if you only support "real" gamepads, you must test +devices for _all_ reported events that you need. Otherwise, you will also get +devices that report a small subset of the events. + +No other devices, that do not look/feel like a gamepad, shall report these +events. + +4. Events +~~~~~~~~~ +Gamepads report the following events: + +Action-Pad: + Every gamepad device has at least 2 action buttons. This means, that every + device reports BTN_SOUTH (which BTN_GAMEPAD is an alias for). Regardless + of the labels on the buttons, the codes are sent according to the + physical position of the buttons. + Please note that 2- and 3-button pads are fairly rare and old. You might + want to filter gamepads that do not report all four. + 2-Button Pad: + If only 2 action-buttons are present, they are reported as BTN_SOUTH and + BTN_EAST. For vertical layouts, the upper button is BTN_EAST. For + horizontal layouts, the button more on the right is BTN_EAST. + 3-Button Pad: + If only 3 action-buttons are present, they are reported as (from left + to right): BTN_WEST, BTN_SOUTH, BTN_EAST + If the buttons are aligned perfectly vertically, they are reported as + (from top down): BTN_WEST, BTN_SOUTH, BTN_EAST + 4-Button Pad: + If all 4 action-buttons are present, they can be aligned in two + different formations. If diamond-shaped, they are reported as BTN_NORTH, + BTN_WEST, BTN_SOUTH, BTN_EAST according to their physical location. + If rectangular-shaped, the upper-left button is BTN_NORTH, lower-left + is BTN_WEST, lower-right is BTN_SOUTH and upper-right is BTN_EAST. + +D-Pad: + Every gamepad provides a D-Pad with four directions: Up, Down, Left, Right + Some of these are available as digital buttons, some as analog buttons. Some + may even report both. The kernel does not convert between these so + applications should support both and choose what is more appropriate if + both are reported. + Digital buttons are reported as: + BTN_DPAD_* + Analog buttons are reported as: + ABS_HAT0X and ABS_HAT0Y + +Analog-Sticks: + The left analog-stick is reported as ABS_X, ABS_Y. The right analog stick is + reported as ABS_RX, ABS_RY. Zero, one or two sticks may be present. + If analog-sticks provide digital buttons, they are mapped accordingly as + BTN_THUMBL (first/left) and BTN_THUMBR (second/right). + +Triggers: + Trigger buttons can be available as digital or analog buttons or both. User- + space must correctly deal with any situation and choose the most appropriate + mode. + Upper trigger buttons are reported as BTN_TR or ABS_HAT1X (right) and BTN_TL + or ABS_HAT1Y (left). Lower trigger buttons are reported as BTN_TR2 or + ABS_HAT2X (right/ZR) and BTN_TL2 or ABS_HAT2Y (left/ZL). + If only one trigger-button combination is present (upper+lower), they are + reported as "right" triggers (BTN_TR/ABS_HAT1X). + +Menu-Pad: + Menu buttons are always digital and are mapped according to their location + instead of their labels. That is: + 1-button Pad: Mapped as BTN_START + 2-button Pad: Left button mapped as BTN_SELECT, right button mapped as + BTN_START + Many pads also have a third button which is branded or has a special symbol + and meaning. Such buttons are mapped as BTN_MODE. Examples are the Nintendo + "HOME" button, the XBox "X"-button or Sony "P" button. + +Rumble: + Rumble is adverticed as FF_RUMBLE. + +---------------------------------------------------------------------------- + Written 2013 by David Herrmann <dh.herrmann@gmail.com> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 479eeaf44024..1a036cd972fb 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1898,6 +1898,18 @@ bytes respectively. Such letter suffixes can also be entirely omitted. will be sent. The default is to send the implementation identification information. + + nfs.recover_lost_locks = + [NFSv4] Attempt to recover locks that were lost due + to a lease timeout on the server. Please note that + doing this risks data corruption, since there are + no guarantees that the file will remain unchanged + after the locks are lost. + If you want to enable the kernel legacy behaviour of + attempting to recover these locks, then set this + parameter to '1'. + The default parameter value of '0' causes the kernel + not to attempt recovery of lost locks. nfsd.nfs4_disable_idmapping= [NFSv4] When set to the default of '1', the NFSv4 diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt index c28f82895d6b..9398a501fdb9 100644 --- a/Documentation/kmemcheck.txt +++ b/Documentation/kmemcheck.txt @@ -91,9 +91,9 @@ information from the kmemcheck warnings, which is extremely valuable in debugging a problem. This option is not mandatory, however, because it slows down the compilation process and produces a much bigger kernel image. -Now the kmemcheck menu should be visible (under "Kernel hacking" / "kmemcheck: -trap use of uninitialized memory"). Here follows a description of the -kmemcheck configuration variables: +Now the kmemcheck menu should be visible (under "Kernel hacking" / "Memory +Debugging" / "kmemcheck: trap use of uninitialized memory"). Here follows +a description of the kmemcheck configuration variables: o CONFIG_KMEMCHECK diff --git a/Documentation/leds/leds-lm3556.txt b/Documentation/leds/leds-lm3556.txt index d9eb91b51913..62278e871b50 100644 --- a/Documentation/leds/leds-lm3556.txt +++ b/Documentation/leds/leds-lm3556.txt @@ -71,7 +71,7 @@ To register the chip at address 0x63 on specific adapter, set the platform data according to include/linux/platform_data/leds-lm3556.h, set the i2c board info Example: - static struct i2c_board_info __initdata board_i2c_ch4[] = { + static struct i2c_board_info board_i2c_ch4[] __initdata = { { I2C_BOARD_INFO(LM3556_NAME, 0x63), .platform_data = &lm3556_pdata, diff --git a/Documentation/leds/leds-lp3944.txt b/Documentation/leds/leds-lp3944.txt index c6eda18b15ef..e88ac3b60c08 100644 --- a/Documentation/leds/leds-lp3944.txt +++ b/Documentation/leds/leds-lp3944.txt @@ -37,7 +37,7 @@ registered using the i2c_board_info mechanism. To register the chip at address 0x60 on adapter 0, set the platform data according to include/linux/leds-lp3944.h, set the i2c board info: - static struct i2c_board_info __initdata a910_i2c_board_info[] = { + static struct i2c_board_info a910_i2c_board_info[] __initdata = { { I2C_BOARD_INFO("lp3944", 0x60), .platform_data = &a910_lp3944_leds, diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 8fd254c73589..58340d50f8a6 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt @@ -163,7 +163,7 @@ a recent addition and not present on older kernels. at read: contains online/offline state of memory. at write: user can specify "online_kernel", "online_movable", "online", "offline" command - which will be performed on al sections in the block. + which will be performed on all sections in the block. 'phys_device' : read-only: designed to show the name of physical memory device. This is not well implemented now. 'removable' : read-only: contains an integer value indicating diff --git a/Documentation/mtd/nand_ecc.txt b/Documentation/mtd/nand_ecc.txt index 990efd7a9818..e129b2479ea8 100644 --- a/Documentation/mtd/nand_ecc.txt +++ b/Documentation/mtd/nand_ecc.txt @@ -543,7 +543,7 @@ THe code within the for loop was changed to: } As you can see tmppar is used to accumulate the parity within a for -iteration. In the last 3 statements is is added to par and, if needed, +iteration. In the last 3 statements is added to par and, if needed, to rp12 and rp14. While making the changes I also found that I could exploit that tmppar diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 32dfbd924121..18b64b2b8a68 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -124,6 +124,8 @@ multiqueue.txt - 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/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt index 262acf56fa79..e9b54de8fdf7 100644 --- a/Documentation/power/basic-pm-debugging.txt +++ b/Documentation/power/basic-pm-debugging.txt @@ -179,7 +179,7 @@ use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt . To verify that the STR works, it is generally more convenient to use the s2ram tool available from http://suspend.sf.net and documented at -http://en.opensuse.org/SDB:Suspend_to_RAM. +http://en.opensuse.org/SDB:Suspend_to_RAM (S2RAM_LINK). Namely, after writing "freezer", "devices", "platform", "processors", or "core" into /sys/power/pm_test (available if the kernel is compiled with @@ -194,10 +194,10 @@ Among other things, the testing with the help of /sys/power/pm_test may allow you to identify drivers that fail to suspend or resume their devices. They should be unloaded every time before an STR transition. -Next, you can follow the instructions at http://en.opensuse.org/s2ram to test -the system, but if it does not work "out of the box", you may need to boot it -with "init=/bin/bash" and test s2ram in the minimal configuration. In that -case, you may be able to search for failing drivers by following the procedure +Next, you can follow the instructions at S2RAM_LINK to test the system, but if +it does not work "out of the box", you may need to boot it with +"init=/bin/bash" and test s2ram in the minimal configuration. In that case, +you may be able to search for failing drivers by following the procedure analogous to the one described in section 1. If you find some failing drivers, you will have to unload them every time before an STR transition (ie. before you run s2ram), and please report the problems with them. diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index 0b4b63e7e9b6..079160e22bcc 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt @@ -50,6 +50,19 @@ echo N > /sys/power/image_size before suspend (it is limited to 500 MB by default). +. The resume process checks for the presence of the resume device, +if found, it then checks the contents for the hibernation image signature. +If both are found, it resumes the hibernation image. + +. The resume process may be triggered in two ways: + 1) During lateinit: If resume=/dev/your_swap_partition is specified on + the kernel command line, lateinit runs the resume process. If the + resume device has not been probed yet, the resume process fails and + bootup continues. + 2) Manually from an initrd or initramfs: May be run from + the init script by using the /sys/power/resume file. It is vital + that this be done prior to remounting any filesystems (even as + read-only) otherwise data may be corrupted. Article about goals and implementation of Software Suspend for Linux ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -326,7 +339,7 @@ Q: How can distributions ship a swsusp-supporting kernel with modular disk drivers (especially SATA)? A: Well, it can be done, load the drivers, then do echo into -/sys/power/disk/resume file from initrd. Be sure not to mount +/sys/power/resume file from initrd. Be sure not to mount anything, not even read-only mount, or you are going to lose your data. diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index 05026ce1875e..6db73df04278 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX @@ -5,13 +5,20 @@ please mail me. 00-INDEX - this file +bootwrapper.txt + - Information on how the powerpc kernel is wrapped for boot on various + different platforms. cpu_features.txt - info on how we support a variety of CPUs with minimal compile-time options. eeh-pci-error-recovery.txt - info on PCI Bus EEH Error Recovery +firmware-assisted-dump.txt + - Documentation on the firmware assisted dump mechanism "fadump". hvcs.txt - IBM "Hypervisor Virtual Console Server" Installation Guide +kvm_440.txt + - Various notes on the implementation of KVM for PowerPC 440. mpc52xx.txt - Linux 2.6.x on MPC52xx family pmu-ebb.txt @@ -19,3 +26,7 @@ pmu-ebb.txt qe_firmware.txt - describes the layout of firmware binaries for the Freescale QUICC Engine and the code that parses and uploads the microcode therein. +ptrace.txt + - Information on the ptrace interfaces for hardware debug registers. +transactional_memory.txt + - Overview of the Power8 transactional memory support. diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 3e8cb73ac43c..445ad743ec81 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt @@ -97,7 +97,7 @@ IPv4 addresses: %pI4 1.2.3.4 %pi4 001.002.003.004 - %p[Ii][hnbl] + %p[Ii]4[hnbl] For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4' specifiers result in a printed address with ('i4') or without ('I4') @@ -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 @@ -185,11 +194,11 @@ struct va_format: u64 SHOULD be printed with %llu/%llx, (unsigned long long): - printk("%llu", (unsigned long long)u64_var); + printk("%llu", u64_var); s64 SHOULD be printed with %lld/%llx, (long long): - printk("%lld", (long long)s64_var); + printk("%lld", s64_var); If <type> is dependent on a config option for its size (e.g., sector_t, blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt index 717f5aa388b1..28fbd877f85a 100644 --- a/Documentation/rapidio/rapidio.txt +++ b/Documentation/rapidio/rapidio.txt @@ -300,7 +300,7 @@ initialization. ------------------------------------------- RapidIO subsystem code organization allows addition of new enumeration/discovery -methods as new configuration options without significant impact to to the core +methods as new configuration options without significant impact to the core RapidIO code. A new enumeration/discovery method has to be attached to one or more mport diff --git a/Documentation/scsi/hptiop.txt b/Documentation/scsi/hptiop.txt index 4a4f47e759cd..12ecfd308e55 100644 --- a/Documentation/scsi/hptiop.txt +++ b/Documentation/scsi/hptiop.txt @@ -151,7 +151,7 @@ To send a request to the controller: generated. - The host read the outbound list copy pointer shadow register and compare - with previous saved read ponter N. If they are different, the host will + with previous saved read pointer N. If they are different, the host will read the (N+1)th outbound list unit. The host get the index of the request from the (N+1)th outbound list diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 809d72b8eff1..a46ddb85e83a 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -244,6 +244,7 @@ STAC9227/9228/9229/927x 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/sound/alsa/README.maya44 b/Documentation/sound/alsa/README.maya44 index 0e41576fa13e..67b2ea1cc31d 100644 --- a/Documentation/sound/alsa/README.maya44 +++ b/Documentation/sound/alsa/README.maya44 @@ -120,7 +120,7 @@ Mic Phantom+48V: switch for +48V phantom power for electrostatic microphones on Make sure this is not turned on while any other source is connected to input 1/2. It might damage the source and/or the maya44 card. -Mic/Line input: if switch is is on, input jack 1/2 is microphone input (mono), otherwise line input (stereo). +Mic/Line input: if switch is on, input jack 1/2 is microphone input (mono), otherwise line input (stereo). Bypass: analogue bypass from ADC input to output for channel 1+2. Same as "Monitor" in the windows driver. Bypass 1: same for channel 3+4. diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt index 0bcc55155911..fd74ff26376e 100644 --- a/Documentation/sound/alsa/compress_offload.txt +++ b/Documentation/sound/alsa/compress_offload.txt @@ -73,7 +73,7 @@ The main requirements are: Design -The new API shares a number of concepts with with the PCM API for flow +The new API shares a number of concepts with the PCM API for flow control. Start, pause, resume, drain and stop commands have the same semantics no matter what the content is. @@ -130,7 +130,7 @@ the settings should remain the exception. The timestamp becomes a multiple field structure. It lists the number of bytes transferred, the number of samples processed and the number of samples rendered/grabbed. All these values can be used to determine -the avarage bitrate, figure out if the ring buffer needs to be +the average bitrate, figure out if the ring buffer needs to be refilled or the delay due to decoding/encoding/io on the DSP. Note that the list of codecs/profiles/modes was derived from the diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index d569f2a424d5..9a0319a82470 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -50,6 +50,19 @@ The maximum number of packets that kernel can handle on a NAPI interrupt, 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_RX_BUSY_POLL) diff --git a/Documentation/sysfs-rules.txt b/Documentation/sysfs-rules.txt index c1a1fd636bf9..a5f985ee1822 100644 --- a/Documentation/sysfs-rules.txt +++ b/Documentation/sysfs-rules.txt @@ -47,7 +47,7 @@ versions of the sysfs interface. at device creation and removal - the unique key to the device at that point in time - the kernel's path to the device directory without the leading - /sys, and always starting with with a slash + /sys, and always starting with a slash - all elements of a devpath must be real directories. Symlinks pointing to /sys/devices must always be resolved to their real target and the target path must be used to access the device. diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py index 3fe0d812dcec..54d29c1320ed 100755 --- a/Documentation/target/tcm_mod_builder.py +++ b/Documentation/target/tcm_mod_builder.py @@ -300,7 +300,7 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += " int ret;\n\n" buf += " if (strstr(name, \"tpgt_\") != name)\n" buf += " return ERR_PTR(-EINVAL);\n" - buf += " if (strict_strtoul(name + 5, 10, &tpgt) || tpgt > UINT_MAX)\n" + buf += " if (kstrtoul(name + 5, 10, &tpgt) || tpgt > UINT_MAX)\n" buf += " return ERR_PTR(-EINVAL);\n\n" buf += " tpg = kzalloc(sizeof(struct " + fabric_mod_name + "_tpg), GFP_KERNEL);\n" buf += " if (!tpg) {\n" 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/trace/ftrace.txt b/Documentation/trace/ftrace.txt index b937c6e2163c..ea2d35d64d26 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -735,7 +735,7 @@ Here are the available options: function as well as the function being traced. print-parent: - bash-4000 [01] 1477.606694: simple_strtoul <-strict_strtoul + bash-4000 [01] 1477.606694: simple_strtoul <-kstrtoul noprint-parent: bash-4000 [01] 1477.606694: simple_strtoul @@ -759,7 +759,7 @@ Here are the available options: latency-format option is enabled. bash 4000 1 0 00000000 00010a95 [58127d26] 1720.415ms \ - (+0.000ms): simple_strtoul (strict_strtoul) + (+0.000ms): simple_strtoul (kstrtoul) raw - This will display raw numbers. This option is best for use with user applications that can translate the raw diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt index da49437d5aeb..ac4170dd0f24 100644 --- a/Documentation/trace/tracepoints.txt +++ b/Documentation/trace/tracepoints.txt @@ -40,7 +40,13 @@ Two elements are required for tracepoints : In order to use tracepoints, you should include linux/tracepoint.h. -In include/trace/subsys.h : +In include/trace/events/subsys.h : + +#undef TRACE_SYSTEM +#define TRACE_SYSTEM subsys + +#if !defined(_TRACE_SUBSYS_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_SUBSYS_H #include <linux/tracepoint.h> @@ -48,10 +54,16 @@ DECLARE_TRACE(subsys_eventname, TP_PROTO(int firstarg, struct task_struct *p), TP_ARGS(firstarg, p)); +#endif /* _TRACE_SUBSYS_H */ + +/* This part must be outside protection */ +#include <trace/define_trace.h> + In subsys/file.c (where the tracing statement must be added) : -#include <trace/subsys.h> +#include <trace/events/subsys.h> +#define CREATE_TRACE_POINTS DEFINE_TRACE(subsys_eventname); void somefct(void) @@ -72,6 +84,9 @@ Where : - TP_ARGS(firstarg, p) are the parameters names, same as found in the prototype. +- if you use the header in multiple source files, #define CREATE_TRACE_POINTS + should appear only in one source file. + Connecting a function (probe) to a tracepoint is done by providing a probe (function to call) for the specific tracepoint through register_trace_subsys_eventname(). Removing a probe is done through 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/api.txt b/Documentation/virtual/kvm/api.txt index ef925eaa1460..858aecf21db2 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -53,7 +53,7 @@ incompatible change are allowed. However, there is an extension facility that allows backward-compatible extensions to the API to be queried and used. -The extension mechanism is not based on on the Linux version number. +The extension mechanism is not based on the Linux version number. Instead, kvm defines extension identifiers and a facility to query whether a particular extension identifier is available. If it is, a set of ioctls is available for application use. diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 83afe65d4966..22ff659bc0fb 100644 --- a/Documentation/virtual/kvm/cpuid.txt +++ b/Documentation/virtual/kvm/cpuid.txt @@ -43,6 +43,10 @@ KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock available at msrs 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/x86/boot.txt b/Documentation/x86/boot.txt index fc66d42422ee..f4f268c2b826 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt @@ -58,7 +58,7 @@ Protocol 2.11: (Kernel 3.6) Added a field for offset of EFI handover protocol entry point. Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension fields - to struct boot_params for for loading bzImage and ramdisk + to struct boot_params for loading bzImage and ramdisk above 4G in 64bit. **** MEMORY LAYOUT diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt index e9e8ddbbf376..1228b22e142b 100644 --- a/Documentation/x86/x86_64/boot-options.txt +++ b/Documentation/x86/x86_64/boot-options.txt @@ -176,6 +176,11 @@ ACPI 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 diff --git a/Documentation/zh_CN/SubmittingPatches b/Documentation/zh_CN/SubmittingPatches index 0f4385a62a49..be0bd4725062 100644 --- a/Documentation/zh_CN/SubmittingPatches +++ b/Documentation/zh_CN/SubmittingPatches @@ -146,7 +146,7 @@ Majordomo lists of VGER.KERNEL.ORG at: <http://vger.kernel.org/vger-lists.html> 如果改动影响了用户空间和内核之间的接口，请给 MAN-PAGES 的维护者（列在 -MAITAINERS 文件里的）发送一个手册页（man-pages）补丁，或者至少通知一下改 +MAINTAINERS 文件里的）发送一个手册页（man-pages）补丁，或者至少通知一下改 变，让一些信息有途径进入手册页。 即使在第四步的时候，维护者没有作出回应，也要确认在修改他们的代码的时候 |