diff options
Diffstat (limited to 'Documentation')
151 files changed, 2848 insertions, 873 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 38f8444bdd0e..07de7e19b4ce 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -29,6 +29,8 @@ DMA-ISA-LPC.txt - How to do DMA with ISA (and LPC) devices. DMA-attributes.txt - listing of the various possible attributes a DMA region can have +dmatest.txt + - how to compile, configure and use the dmatest system. DocBook/ - directory with DocBook templates etc. for kernel documentation. EDID/ @@ -77,6 +79,8 @@ arm/ - directory with info about Linux on the ARM architecture. arm64/ - directory with info about Linux on the 64 bit ARM architecture. +assoc_array.txt + - generic associative array intro. atomic_ops.txt - semantics and behavior of atomic and bitmask operations. auxdisplay/ @@ -87,6 +91,8 @@ bad_memory.txt - how to use kernel parameters to exclude bad RAM regions. basic_profiling.txt - basic instructions for those who wants to profile Linux kernel. +bcache.txt + - Block-layer cache on fast SSDs to improve slow (raid) I/O performance. binfmt_misc.txt - info on the kernel support for extra binary formats. blackfin/ @@ -171,6 +177,8 @@ early-userspace/ - info about initramfs, klibc, and userspace early during boot. edac.txt - information on EDAC - Error Detection And Correction +efi-stub.txt + - How to use the EFI boot stub to bypass GRUB or elilo on EFI systems. eisa.txt - info on EISA bus support. email-clients.txt @@ -195,8 +203,8 @@ futex-requeue-pi.txt - info on requeueing of tasks from a non-PI futex to a PI futex gcov.txt - use of GCC's coverage testing tool "gcov" with the Linux kernel -gpio.txt - - overview of GPIO (General Purpose Input/Output) access conventions. +gpio/ + - gpio related documentation hid/ - directory with information on human interface devices highuid.txt @@ -255,6 +263,8 @@ kernel-docs.txt - listing of various WWW + books that document kernel internals. kernel-parameters.txt - summary listing of command line / boot prompt args for the kernel. +kernel-per-CPU-kthreads.txt + - List of all per-CPU kthreads and how they introduce jitter. kmemcheck.txt - info on dynamic checker that detects uses of uninitialized memory. kmemleak.txt @@ -299,8 +309,6 @@ memory-devices/ - directory with info on parts like the Texas Instruments EMIF driver memory-hotplug.txt - Hotpluggable memory support, how to use and current status. -memory.txt - - info on typical Linux memory problems. metag/ - directory with info about Linux on Meta architecture. mips/ @@ -311,6 +319,8 @@ mmc/ - directory with info about the MMC subsystem mn10300/ - directory with info about the mn10300 architecture port +module-signing.txt + - Kernel module signing for increased security when loading modules. mtd/ - directory with info about memory technology devices (flash) mono.txt @@ -343,6 +353,8 @@ pcmcia/ - info on the Linux PCMCIA driver. percpu-rw-semaphore.txt - RCU based read-write semaphore optimized for locking for reading +phy.txt + - Description of the generic PHY framework. pi-futex.txt - documentation on lightweight priority inheritance futexes. pinctrl.txt @@ -431,6 +443,8 @@ sysrq.txt - info on the magic SysRq key. target/ - directory with info on generating TCM v4 fabric .ko modules +this_cpu_ops.txt + - List rationale behind and the way to use this_cpu operations. thermal/ - directory with information on managing thermal issues (CPU/temp) trace/ @@ -469,6 +483,8 @@ wimax/ - directory with info about Intel Wireless Wimax Connections workqueue.txt - information on the Concurrency Managed Workqueue implementation +ww-mutex-design.txt + - Intro to Mutex wait/would deadlock handling.s x86/x86_64/ - directory with info on Linux support for AMD x86-64 (Hammer) machines. xtensa/ diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget index 01e769d6984d..37559a06393b 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget +++ b/Documentation/ABI/testing/configfs-usb-gadget @@ -1,13 +1,13 @@ What: /config/usb-gadget Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: This group contains sub-groups corresponding to created USB gadgets. What: /config/usb-gadget/gadget Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: The attributes of a gadget: @@ -27,7 +27,7 @@ Description: What: /config/usb-gadget/gadget/configs Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: This group contains a USB gadget's configurations @@ -58,20 +58,20 @@ Description: What: /config/usb-gadget/gadget/functions Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: This group contains functions available to this USB gadget. What: /config/usb-gadget/gadget/strings Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: This group contains subdirectories for language-specific strings for this gadget. What: /config/usb-gadget/gadget/strings/language Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: The attributes: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-acm b/Documentation/ABI/testing/configfs-usb-gadget-acm index 5708a568b5f6..d21092d75a05 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-acm +++ b/Documentation/ABI/testing/configfs-usb-gadget-acm @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/acm.name Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: This item contains just one readonly attribute: port_num. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ecm b/Documentation/ABI/testing/configfs-usb-gadget-ecm index 6b9a582ce0b5..0addf7704b4c 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-ecm +++ b/Documentation/ABI/testing/configfs-usb-gadget-ecm @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/ecm.name Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: The attributes: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-eem b/Documentation/ABI/testing/configfs-usb-gadget-eem index dbddf36b48b3..a4c57158fcde 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-eem +++ b/Documentation/ABI/testing/configfs-usb-gadget-eem @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/eem.name Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: The attributes: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ffs b/Documentation/ABI/testing/configfs-usb-gadget-ffs index 14343e237e83..e39b27653c65 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-ffs +++ b/Documentation/ABI/testing/configfs-usb-gadget-ffs @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/ffs.name Date: Nov 2013 -KenelVersion: 3.13 +KernelVersion: 3.13 Description: The purpose of this directory is to create and remove it. A corresponding USB function instance is created/removed. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-loopback b/Documentation/ABI/testing/configfs-usb-gadget-loopback index 852b2365a5b5..9aae5bfb9908 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-loopback +++ b/Documentation/ABI/testing/configfs-usb-gadget-loopback @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/Loopback.name Date: Nov 2013 -KenelVersion: 3.13 +KernelVersion: 3.13 Description: The attributes: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage index ad72a37ee9ff..9931fb0d63ba 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage +++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/mass_storage.name Date: Oct 2013 -KenelVersion: 3.13 +KernelVersion: 3.13 Description: The attributes: @@ -13,7 +13,7 @@ Description: What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name Date: Oct 2013 -KenelVersion: 3.13 +KernelVersion: 3.13 Description: The attributes: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ncm b/Documentation/ABI/testing/configfs-usb-gadget-ncm index bc309f42357d..6fe723effc78 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-ncm +++ b/Documentation/ABI/testing/configfs-usb-gadget-ncm @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/ncm.name Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: The attributes: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-obex b/Documentation/ABI/testing/configfs-usb-gadget-obex index aaa5c96fb7c6..a6a9327ed9ba 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-obex +++ b/Documentation/ABI/testing/configfs-usb-gadget-obex @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/obex.name Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: This item contains just one readonly attribute: port_num. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-phonet b/Documentation/ABI/testing/configfs-usb-gadget-phonet index 3e3b742cdfd7..7037a358e6c4 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-phonet +++ b/Documentation/ABI/testing/configfs-usb-gadget-phonet @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/phonet.name Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: This item contains just one readonly attribute: ifname. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-rndis b/Documentation/ABI/testing/configfs-usb-gadget-rndis index 822e6dad8fc0..e32879b84b4d 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-rndis +++ b/Documentation/ABI/testing/configfs-usb-gadget-rndis @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/rndis.name Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: The attributes: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-serial b/Documentation/ABI/testing/configfs-usb-gadget-serial index 16f130c1501f..474d249f760b 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-serial +++ b/Documentation/ABI/testing/configfs-usb-gadget-serial @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/gser.name Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: This item contains just one readonly attribute: port_num. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-sourcesink b/Documentation/ABI/testing/configfs-usb-gadget-sourcesink index a30f3093ef6c..29477c319f61 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-sourcesink +++ b/Documentation/ABI/testing/configfs-usb-gadget-sourcesink @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/SourceSink.name Date: Nov 2013 -KenelVersion: 3.13 +KernelVersion: 3.13 Description: The attributes: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-subset b/Documentation/ABI/testing/configfs-usb-gadget-subset index 154ae597cd99..9373e2c51ea4 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-subset +++ b/Documentation/ABI/testing/configfs-usb-gadget-subset @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/geth.name Date: Jun 2013 -KenelVersion: 3.11 +KernelVersion: 3.11 Description: The attributes: diff --git a/Documentation/ABI/testing/sysfs-bus-mdio b/Documentation/ABI/testing/sysfs-bus-mdio index 6349749ebc29..491baaf4285f 100644 --- a/Documentation/ABI/testing/sysfs-bus-mdio +++ b/Documentation/ABI/testing/sysfs-bus-mdio @@ -7,3 +7,23 @@ Description: by the device during bus enumeration, encoded in hexadecimal. This ID is used to match the device with the appropriate driver. + +What: /sys/bus/mdio_bus/devices/.../phy_interface +Date: February 2014 +KernelVersion: 3.15 +Contact: netdev@vger.kernel.org +Description: + This attribute contains the PHY interface as configured by the + Ethernet driver during bus enumeration, encoded in string. + This interface mode is used to configure the Ethernet MAC with the + appropriate mode for its data lines to the PHY hardware. + +What: /sys/bus/mdio_bus/devices/.../phy_has_fixups +Date: February 2014 +KernelVersion: 3.15 +Contact: netdev@vger.kernel.org +Description: + This attribute contains the boolean value whether a given PHY + device has had any "fixup" workaround running on it, encoded as + a boolean. This information is provided to help troubleshooting + PHY configurations. diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd index 0a306476424e..501adc2a9ec7 100644 --- a/Documentation/ABI/testing/sysfs-bus-rbd +++ b/Documentation/ABI/testing/sysfs-bus-rbd @@ -18,6 +18,28 @@ Removal of a device: $ echo <dev-id> > /sys/bus/rbd/remove +What: /sys/bus/rbd/add_single_major +Date: December 2013 +KernelVersion: 3.14 +Contact: Sage Weil <sage@inktank.com> +Description: Available only if rbd module is inserted with single_major + parameter set to true. + Usage is the same as for /sys/bus/rbd/add. If present, + should be used instead of the latter: any attempts to use + /sys/bus/rbd/add if /sys/bus/rbd/add_single_major is + available will fail for backwards compatibility reasons. + +What: /sys/bus/rbd/remove_single_major +Date: December 2013 +KernelVersion: 3.14 +Contact: Sage Weil <sage@inktank.com> +Description: Available only if rbd module is inserted with single_major + parameter set to true. + Usage is the same as for /sys/bus/rbd/remove. If present, + should be used instead of the latter: any attempts to use + /sys/bus/rbd/remove if /sys/bus/rbd/remove_single_major is + available will fail for backwards compatibility reasons. + Entries under /sys/bus/rbd/devices/<dev-id>/ -------------------------------------------- @@ -33,6 +55,10 @@ major The block device major number. +minor + + The block device minor number. (December 2013, since 3.14.) + name The name of the rbd image. diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 0c7195e3e093..c4cac6dbf9af 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2523,6 +2523,18 @@ that used it. It was originally scheduled for removal in 2.6.35. </orderedlist> </section> + <section> + <title>V4L2 in Linux 3.14</title> + <orderedlist> + <listitem> + <para> In struct <structname>v4l2_rect</structname>, the type +of <structfield>width</structfield> and <structfield>height</structfield> +fields changed from _s32 to _u32. + </para> + </listitem> + </orderedlist> + </section> + <section id="other"> <title>Relation of V4L2 to other Linux multimedia APIs</title> diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7a3b49b3cc3b..a5a3188e5af7 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3161,6 +3161,47 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a golden frame.</entry> </entrytbl> </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_MIN_QP</constant></entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Minimum quantization parameter for VP8.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_MAX_QP</constant></entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Maximum quantization parameter for VP8.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Quantization parameter for an I frame for VP8.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Quantization parameter for a P frame for VP8.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_PROFILE</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Select the desired profile for VPx encoder. +Acceptable values are 0, 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.</entry> + </row> + <row><entry></entry></row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/dev-overlay.xml b/Documentation/DocBook/media/v4l/dev-overlay.xml index 40d1d7681439..cc6e0c5c960c 100644 --- a/Documentation/DocBook/media/v4l/dev-overlay.xml +++ b/Documentation/DocBook/media/v4l/dev-overlay.xml @@ -346,17 +346,14 @@ rectangle, in pixels.</entry> rectangle, in pixels. Offsets increase to the right and down.</entry> </row> <row> - <entry>__s32</entry> + <entry>__u32</entry> <entry><structfield>width</structfield></entry> <entry>Width of the rectangle, in pixels.</entry> </row> <row> - <entry>__s32</entry> + <entry>__u32</entry> <entry><structfield>height</structfield></entry> - <entry>Height of the rectangle, in pixels. Width and -height cannot be negative, the fields are signed for hysterical -reasons. <!-- video4linux-list@redhat.com on 22 Oct 2002 subject -"Re:[V4L][patches!] Re:v4l2/kernel-2.5" --></entry> + <entry>Height of the rectangle, in pixels.</entry> </row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml index 355df43badc5..cf8548556c7d 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml @@ -134,6 +134,15 @@ <entry>Output pad, relative to the entity. Output pads source data and are origins of links.</entry> </row> + <row> + <entry><constant>MEDIA_PAD_FL_MUST_CONNECT</constant></entry> + <entry>If this flag is set and the pad is linked to any other + pad, then at least one of those links must be enabled for the + entity to be able to stream. There could be temporary reasons + (e.g. device configuration dependent) for the pad to need + enabled links even when this flag isn't set; the absence of the + flag doesn't imply there is none.</entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index f72c1cc93a9b..7331ce116f4c 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -89,7 +89,7 @@ <constant>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</constant>. </para> - <para>The following tables list existing packet RGB formats.</para> + <para>The following tables list existing packed RGB formats.</para> <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-rgb"> <title>RGB formats</title> @@ -615,7 +615,7 @@ </mediaobject> </figure> - <para>The following table lists existing packet Bayer formats. The data + <para>The following table lists existing packed Bayer formats. The data organization is given as an example for the first pixel only.</para> <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-bayer"> @@ -1178,7 +1178,7 @@ U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>. </para> - <para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> list existing packet YUV + <para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> lists existing packed YUV formats and describes the organization of each pixel data in each sample. When a format pattern is split across multiple samples each of the samples in the pattern is described.</para> @@ -2492,6 +2492,163 @@ </section> <section> + <title>HSV/HSL Formats</title> + + <para>Those formats transfer pixel data as RGB values in a cylindrical-coordinate + system using Hue-Saturation-Value or Hue-Saturation-Lightness components. The + format code is made of the following information. + <itemizedlist> + <listitem><para>The hue, saturation, value or lightness and optional alpha + components order code, as encoded in a pixel sample. The only currently + supported value is AHSV. + </para></listitem> + <listitem><para>The number of bits per component, for each component. The values + can be different for all components. The only currently supported value is 8888. + </para></listitem> + <listitem><para>The number of bus samples per pixel. Pixels that are wider than + the bus width must be transferred in multiple samples. The only currently + supported value is 1.</para></listitem> + <listitem><para>The bus width.</para></listitem> + <listitem><para>For formats where the total number of bits per pixel is smaller + than the number of bus samples per pixel times the bus width, a padding + value stating if the bytes are padded in their most high order bits + (PADHI) or low order bits (PADLO).</para></listitem> + <listitem><para>For formats where the number of bus samples per pixel is larger + than 1, an endianness value stating if the pixel is transferred MSB first + (BE) or LSB first (LE).</para></listitem> + </itemizedlist> + </para> + + <para>The following table lists existing HSV/HSL formats.</para> + + <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-hsv"> + <title>HSV/HSL formats</title> + <tgroup cols="27"> + <colspec colname="id" align="left" /> + <colspec colname="code" align="center"/> + <colspec colname="bit" /> + <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> + <entry>Code</entry> + <entry></entry> + <entry spanname="b0">Data organization</entry> + </row> + <row> + <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> + <entry>20</entry> + <entry>19</entry> + <entry>18</entry> + <entry>17</entry> + <entry>16</entry> + <entry>15</entry> + <entry>14</entry> + <entry>13</entry> + <entry>12</entry> + <entry>11</entry> + <entry>10</entry> + <entry>9</entry> + <entry>8</entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + </row> + </thead> + <tbody valign="top"> + <row id="V4L2-MBUS-FMT-AHSV8888-1X32"> + <entry>V4L2_MBUS_FMT_AHSV8888_1X32</entry> + <entry>0x6001</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>h<subscript>7</subscript></entry> + <entry>h<subscript>6</subscript></entry> + <entry>h<subscript>5</subscript></entry> + <entry>h<subscript>4</subscript></entry> + <entry>h<subscript>3</subscript></entry> + <entry>h<subscript>2</subscript></entry> + <entry>h<subscript>1</subscript></entry> + <entry>h<subscript>0</subscript></entry> + <entry>s<subscript>7</subscript></entry> + <entry>s<subscript>6</subscript></entry> + <entry>s<subscript>5</subscript></entry> + <entry>s<subscript>4</subscript></entry> + <entry>s<subscript>3</subscript></entry> + <entry>s<subscript>2</subscript></entry> + <entry>s<subscript>1</subscript></entry> + <entry>s<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> + </section> + + <section> <title>JPEG Compressed Formats</title> <para>Those data formats consist of an ordered sequence of 8-bit bytes diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 8469fe13945c..74b7f27af71a 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -141,6 +141,14 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> <revision> + <revnumber>3.14</revnumber> + <date>2013-11-25</date> + <authorinitials>rr</authorinitials> + <revremark>Set width and height as unsigned on v4l2_rect. + </revremark> + </revision> + + <revision> <revnumber>3.11</revnumber> <date>2013-05-26</date> <authorinitials>hv</authorinitials> @@ -501,7 +509,7 @@ and discussions on the V4L mailing list.</revremark> </partinfo> <title>Video for Linux Two API Specification</title> - <subtitle>Revision 3.11</subtitle> + <subtitle>Revision 3.14</subtitle> <chapter id="common"> &sub-common; diff --git a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml index bf7cc979fdfa..1f5ed64cd75a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml @@ -133,18 +133,14 @@ rectangle, in pixels.</entry> rectangle, in pixels.</entry> </row> <row> - <entry>__s32</entry> + <entry>__u32</entry> <entry><structfield>width</structfield></entry> <entry>Width of the rectangle, in pixels.</entry> </row> <row> - <entry>__s32</entry> + <entry>__u32</entry> <entry><structfield>height</structfield></entry> - <entry>Height of the rectangle, in pixels. Width -and height cannot be negative, the fields are signed for -hysterical reasons. <!-- video4linux-list@redhat.com -on 22 Oct 2002 subject "Re:[V4L][patches!] Re:v4l2/kernel-2.5" --> -</entry> + <entry>Height of the rectangle, in pixels.</entry> </row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/vidioc-streamon.xml b/Documentation/DocBook/media/v4l/vidioc-streamon.xml index 716ea15e54a1..65dff55079d7 100644 --- a/Documentation/DocBook/media/v4l/vidioc-streamon.xml +++ b/Documentation/DocBook/media/v4l/vidioc-streamon.xml @@ -59,7 +59,7 @@ buffers are filled (if there are any empty buffers in the incoming queue) until <constant>VIDIOC_STREAMON</constant> has been called. Accordingly the output hardware is disabled, no video signal is produced until <constant>VIDIOC_STREAMON</constant> has been called. -The ioctl will succeed only when at least one output buffer is in the +The ioctl will succeed when at least one output buffer is in the incoming queue.</para> <para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of diff --git a/Documentation/RCU/00-INDEX b/Documentation/RCU/00-INDEX index 1d7a885761f5..fa57139f50bf 100644 --- a/Documentation/RCU/00-INDEX +++ b/Documentation/RCU/00-INDEX @@ -8,6 +8,8 @@ listRCU.txt - Using RCU to Protect Read-Mostly Linked Lists lockdep.txt - RCU and lockdep checking +lockdep-splat.txt + - RCU Lockdep splats explained. NMI-RCU.txt - Using RCU to Protect Dynamic NMI Handlers rcubarrier.txt diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX index 36420e116c90..a94090cc785d 100644 --- a/Documentation/arm/00-INDEX +++ b/Documentation/arm/00-INDEX @@ -4,6 +4,8 @@ Booting - requirements for booting Interrupts - ARM Interrupt subsystem documentation +IXP4xx + - Intel IXP4xx Network processor. msm - MSM specific documentation Netwinder @@ -24,8 +26,16 @@ SPEAr - ST SPEAr platform Linux Overview VFP/ - Release notes for Linux Kernel Vector Floating Point support code +cluster-pm-race-avoidance.txt + - Algorithm for CPU and Cluster setup/teardown empeg/ - Ltd's Empeg MP3 Car Audio Player +firmware.txt + - Secure firmware registration and calling. +kernel_mode_neon.txt + - How to use NEON instructions in kernel mode +kernel_user_helpers.txt + - Helper functions in kernel space made available for userspace. mem_alignment - alignment abort handler documentation memory.txt @@ -34,3 +44,7 @@ nwfpe/ - NWFPE floating point emulator documentation swp_emulation - SWP/SWPB emulation handler/logging description +tcm.txt + - ARM Tightly Coupled Memory +vlocks.txt + - Voting locks, low-level mechanism relying on memory system atomic writes. diff --git a/Documentation/blackfin/00-INDEX b/Documentation/blackfin/00-INDEX index 2df0365f2dff..c54fcdd4ae9f 100644 --- a/Documentation/blackfin/00-INDEX +++ b/Documentation/blackfin/00-INDEX @@ -1,8 +1,10 @@ 00-INDEX - This file - +Makefile + - Makefile for gptimers example file. bfin-gpio-notes.txt - Notes in developing/using bfin-gpio driver. - bfin-spi-notes.txt - Notes for using bfin spi bus driver. +gptimers-example.c + - gptimers example diff --git a/Documentation/block/00-INDEX b/Documentation/block/00-INDEX index 929d9904f74b..e840b47613f7 100644 --- a/Documentation/block/00-INDEX +++ b/Documentation/block/00-INDEX @@ -14,6 +14,8 @@ deadline-iosched.txt - Deadline IO scheduler tunables ioprio.txt - Block io priorities (in CFQ scheduler) +null_blk.txt + - Null block for block-layer benchmarking. queue-sysfs.txt - Queue's sysfs entries request.txt diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 8df5e8e6dceb..2101e718670d 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -447,14 +447,13 @@ struct bio_vec { * main unit of I/O for the block layer and lower layers (ie drivers) */ struct bio { - sector_t bi_sector; struct bio *bi_next; /* request queue link */ struct block_device *bi_bdev; /* target device */ unsigned long bi_flags; /* status, command, etc */ unsigned long bi_rw; /* low bits: r/w, high: priority */ unsigned int bi_vcnt; /* how may bio_vec's */ - unsigned int bi_idx; /* current index into bio_vec array */ + struct bvec_iter bi_iter; /* current index into bio_vec array */ unsigned int bi_size; /* total size in bytes */ unsigned short bi_phys_segments; /* segments after physaddr coalesce*/ @@ -480,7 +479,7 @@ With this multipage bio design: - Code that traverses the req list can find all the segments of a bio by using rq_for_each_segment. This handles the fact that a request has multiple bios, each of which can have multiple segments. -- Drivers which can't process a large bio in one shot can use the bi_idx +- Drivers which can't process a large bio in one shot can use the bi_iter field to keep track of the next bio_vec entry to process. (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE) [TBD: Should preferably also have a bi_voffset and bi_vlen to avoid modifying @@ -589,7 +588,7 @@ driver should not modify these values. The block layer sets up the nr_sectors and current_nr_sectors fields (based on the corresponding hard_xxx values and the number of bytes transferred) and updates it on every transfer that invokes end_that_request_first. It does the same for the -buffer, bio, bio->bi_idx fields too. +buffer, bio, bio->bi_iter fields too. The buffer field is just a virtual address mapping of the current segment of the i/o buffer in cases where the buffer resides in low-memory. For high diff --git a/Documentation/block/biovecs.txt b/Documentation/block/biovecs.txt new file mode 100644 index 000000000000..74a32ad52f53 --- /dev/null +++ b/Documentation/block/biovecs.txt @@ -0,0 +1,111 @@ + +Immutable biovecs and biovec iterators: +======================================= + +Kent Overstreet <kmo@daterainc.com> + +As of 3.13, biovecs should never be modified after a bio has been submitted. +Instead, we have a new struct bvec_iter which represents a range of a biovec - +the iterator will be modified as the bio is completed, not the biovec. + +More specifically, old code that needed to partially complete a bio would +update bi_sector and bi_size, and advance bi_idx to the next biovec. If it +ended up partway through a biovec, it would increment bv_offset and decrement +bv_len by the number of bytes completed in that biovec. + +In the new scheme of things, everything that must be mutated in order to +partially complete a bio is segregated into struct bvec_iter: bi_sector, +bi_size and bi_idx have been moved there; and instead of modifying bv_offset +and bv_len, struct bvec_iter has bi_bvec_done, which represents the number of +bytes completed in the current bvec. + +There are a bunch of new helper macros for hiding the gory details - in +particular, presenting the illusion of partially completed biovecs so that +normal code doesn't have to deal with bi_bvec_done. + + * Driver code should no longer refer to biovecs directly; we now have + bio_iovec() and bio_iovec_iter() macros that return literal struct biovecs, + constructed from the raw biovecs but taking into account bi_bvec_done and + bi_size. + + bio_for_each_segment() has been updated to take a bvec_iter argument + instead of an integer (that corresponded to bi_idx); for a lot of code the + conversion just required changing the types of the arguments to + bio_for_each_segment(). + + * Advancing a bvec_iter is done with bio_advance_iter(); bio_advance() is a + wrapper around bio_advance_iter() that operates on bio->bi_iter, and also + advances the bio integrity's iter if present. + + There is a lower level advance function - bvec_iter_advance() - which takes + a pointer to a biovec, not a bio; this is used by the bio integrity code. + +What's all this get us? +======================= + +Having a real iterator, and making biovecs immutable, has a number of +advantages: + + * Before, iterating over bios was very awkward when you weren't processing + exactly one bvec at a time - for example, bio_copy_data() in fs/bio.c, + which copies the contents of one bio into another. Because the biovecs + wouldn't necessarily be the same size, the old code was tricky convoluted - + it had to walk two different bios at the same time, keeping both bi_idx and + and offset into the current biovec for each. + + The new code is much more straightforward - have a look. This sort of + pattern comes up in a lot of places; a lot of drivers were essentially open + coding bvec iterators before, and having common implementation considerably + simplifies a lot of code. + + * Before, any code that might need to use the biovec after the bio had been + completed (perhaps to copy the data somewhere else, or perhaps to resubmit + it somewhere else if there was an error) had to save the entire bvec array + - again, this was being done in a fair number of places. + + * Biovecs can be shared between multiple bios - a bvec iter can represent an + arbitrary range of an existing biovec, both starting and ending midway + through biovecs. This is what enables efficient splitting of arbitrary + bios. Note that this means we _only_ use bi_size to determine when we've + reached the end of a bio, not bi_vcnt - and the bio_iovec() macro takes + bi_size into account when constructing biovecs. + + * Splitting bios is now much simpler. The old bio_split() didn't even work on + bios with more than a single bvec! Now, we can efficiently split arbitrary + size bios - because the new bio can share the old bio's biovec. + + Care must be taken to ensure the biovec isn't freed while the split bio is + still using it, in case the original bio completes first, though. Using + bio_chain() when splitting bios helps with this. + + * Submitting partially completed bios is now perfectly fine - this comes up + occasionally in stacking block drivers and various code (e.g. md and + bcache) had some ugly workarounds for this. + + It used to be the case that submitting a partially completed bio would work + fine to _most_ devices, but since accessing the raw bvec array was the + norm, not all drivers would respect bi_idx and those would break. Now, + since all drivers _must_ go through the bvec iterator - and have been + audited to make sure they are - submitting partially completed bios is + perfectly fine. + +Other implications: +=================== + + * Almost all usage of bi_idx is now incorrect and has been removed; instead, + where previously you would have used bi_idx you'd now use a bvec_iter, + probably passing it to one of the helper macros. + + I.e. instead of using bio_iovec_idx() (or bio->bi_iovec[bio->bi_idx]), you + now use bio_iter_iovec(), which takes a bvec_iter and returns a + literal struct bio_vec - constructed on the fly from the raw biovec but + taking into account bi_bvec_done (and bi_size). + + * bi_vcnt can't be trusted or relied upon by driver code - i.e. anything that + doesn't actually own the bio. The reason is twofold: firstly, it's not + actually needed for iterating over the bio anymore - we only use bi_size. + Secondly, when cloning a bio and reusing (a portion of) the original bio's + biovec, in order to calculate bi_vcnt for the new bio we'd have to iterate + over all the biovecs in the new bio - which is silly as it's not needed. + + So, don't use bi_vcnt anymore. diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt new file mode 100644 index 000000000000..2eccddffa6c8 --- /dev/null +++ b/Documentation/blockdev/zram.txt @@ -0,0 +1,71 @@ +zram: Compressed RAM based block devices +---------------------------------------- + +* Introduction + +The zram module creates RAM based block devices named /dev/zram<id> +(<id> = 0, 1, ...). Pages written to these disks are compressed and stored +in memory itself. These disks allow very fast I/O and compression provides +good amounts of memory savings. Some of the usecases include /tmp storage, +use as swap disks, various caches under /var and maybe many more :) + +Statistics for individual zram devices are exported through sysfs nodes at +/sys/block/zram<id>/ + +* Usage + +Following shows a typical sequence of steps for using zram. + +1) Load Module: + modprobe zram num_devices=4 + This creates 4 devices: /dev/zram{0,1,2,3} + (num_devices parameter is optional. Default: 1) + +2) Set Disksize + Set disk size by writing the value to sysfs node 'disksize'. + The value can be either in bytes or you can use mem suffixes. + Examples: + # Initialize /dev/zram0 with 50MB disksize + echo $((50*1024*1024)) > /sys/block/zram0/disksize + + # Using mem suffixes + echo 256K > /sys/block/zram0/disksize + echo 512M > /sys/block/zram0/disksize + echo 1G > /sys/block/zram0/disksize + +3) Activate: + mkswap /dev/zram0 + swapon /dev/zram0 + + mkfs.ext4 /dev/zram1 + mount /dev/zram1 /tmp + +4) Stats: + Per-device statistics are exported as various nodes under + /sys/block/zram<id>/ + disksize + num_reads + num_writes + invalid_io + notify_free + discard + zero_pages + orig_data_size + compr_data_size + mem_used_total + +5) Deactivate: + swapoff /dev/zram0 + umount /dev/zram1 + +6) Reset: + Write any positive value to 'reset' sysfs node + echo 1 > /sys/block/zram0/reset + echo 1 > /sys/block/zram1/reset + + This frees all the memory allocated for the given device and + resets the disksize to zero. You must set the disksize again + before reusing the device. + +Nitin Gupta +ngupta@vflare.org diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt index 52e1da16a309..5108afb3645c 100644 --- a/Documentation/cgroups/resource_counter.txt +++ b/Documentation/cgroups/resource_counter.txt @@ -95,7 +95,7 @@ to work with it. f. u64 res_counter_uncharge_until (struct res_counter *rc, struct res_counter *top, - unsinged long val) + unsigned long val) Almost same as res_counter_uncharge() but propagation of uncharge stops when rc == top. This is useful when kill a res_counter in diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt index 611f5a5499b1..fa0151a712f9 100644 --- a/Documentation/debugging-via-ohci1394.txt +++ b/Documentation/debugging-via-ohci1394.txt @@ -22,10 +22,12 @@ locations such as buffers like the printk buffer or the process table. Retrieving a full system memory dump is also possible over the FireWire, using data transfer rates in the order of 10MB/s or more. -Memory access is currently limited to the low 4G of physical address -space which can be a problem on IA64 machines where memory is located -mostly above that limit, but it is rarely a problem on more common -hardware such as hardware based on x86, x86-64 and PowerPC. +With most FireWire controllers, memory access is limited to the low 4 GB +of physical address space. This can be a problem on IA64 machines where +memory is located mostly above that limit, but it is rarely a problem on +more common hardware such as x86, x86-64 and PowerPC. However, at least +Agere/LSI FW643e and FW643e2 controllers are known to support access to +physical addresses above 4 GB. Together with a early initialization of the OHCI-1394 controller for debugging, this facility proved most useful for examining long debugs logs in the printk @@ -36,17 +38,11 @@ available (notebooks) or too slow for extensive debug information (like ACPI). Drivers ------- -The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers -to a working state and enables physical DMA by default for all remote nodes. -This can be turned off by ohci1394's module parameter phys_dma=0. - -The alternative firewire-ohci driver in drivers/firewire uses filtered physical +The firewire-ohci driver in drivers/firewire uses filtered physical DMA by default, which is more secure but not suitable for remote debugging. -Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu: -Remote debugging over FireWire with firewire-ohci) to get unfiltered physical -DMA. +Pass the remote_dma=1 parameter to the driver to get unfiltered physical DMA. -Because ohci1394 and firewire-ohci depend on the PCI enumeration to be +Because the firewire-ohci driver depends on the PCI enumeration to be completed, an initialization routine which runs pretty early has been implemented for x86. This routine runs long before console_init() can be called, i.e. before the printk buffer appears on the console. @@ -64,7 +60,7 @@ be used to view the printk buffer of a remote machine, even with live update. Bernhard Kaindl enhanced firescope to support accessing 64-bit machines from 32-bit firescope and vice versa: -- http://halobates.de/firewire/firescope-0.2.2.tar.bz2 +- http://v3.sk/~lkundrak/firescope/ and he implemented fast system dump (alpha version - read README.txt): - http://halobates.de/firewire/firedump-0.1.tar.bz2 @@ -92,11 +88,11 @@ Step-by-step instructions for using firescope with early OHCI initialization: 1) Verify that your hardware is supported: - Load the ohci1394 or the fw-ohci module and check your kernel logs. + Load the firewire-ohci module and check your kernel logs. You should see a line similar to - ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[fe9ff800-fe9fffff] - ... Max Packet=[2048] IR/IT contexts=[4/8] + firewire_ohci 0000:15:00.1: added OHCI v1.0 device as card 2, 4 IR + 4 IT + ... contexts, quirks 0x11 when loading the driver. If you have no supported controller, many PCI, CardBus and even some Express cards which are fully compliant to OHCI-1394 @@ -105,6 +101,9 @@ Step-by-step instructions for using firescope with early OHCI initialization: compliant, they are based on TI PCILynx chips and require drivers for Win- dows operating systems. + The mentioned kernel log message contains ">4 GB phys DMA" in case of + OHCI-1394 controllers which support accesses above this limit. + 2) Establish a working FireWire cable connection: Any FireWire cable, as long at it provides electrically and mechanically @@ -113,20 +112,18 @@ Step-by-step instructions for using firescope with early OHCI initialization: If an driver is running on both machines you should see a line like - ieee1394: Node added: ID:BUS[0-01:1023] GUID[0090270001b84bba] + firewire_core 0000:15:00.1: created device fw1: GUID 00061b0020105917, S400 on both machines in the kernel log when the cable is plugged in and connects the two machines. 3) Test physical DMA using firescope: - On the debug host, - - load the raw1394 module, - - make sure that /dev/raw1394 is accessible, + On the debug host, make sure that /dev/fw* is accessible, then start firescope: $ firescope - Port 0 (ohci1394) opened, 2 nodes detected + Port 0 (/dev/fw1) opened, 2 nodes detected FireScope --------- diff --git a/Documentation/devicetree/00-INDEX b/Documentation/devicetree/00-INDEX index b78f691fd847..8c4102c6a5e7 100644 --- a/Documentation/devicetree/00-INDEX +++ b/Documentation/devicetree/00-INDEX @@ -8,3 +8,5 @@ https://lists.ozlabs.org/listinfo/devicetree-discuss - this file booting-without-of.txt - Booting Linux without Open Firmware, describes history and format of device trees. +usage-model.txt + - How Linux uses DT and what DT aims to solve.
\ No newline at end of file diff --git a/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt b/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt index 17d88b233d1b..39adf54b4388 100644 --- a/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt +++ b/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt @@ -8,13 +8,18 @@ Required properties: - DEPRECATED: compatible : "bcm,kona-timer" - reg : Register range for the timer - interrupts : interrupt for the timer +- clocks: phandle + clock specifier pair of the external clock - clock-frequency: frequency that the clock operates +Only one of clocks or clock-frequency should be specified. + +Refer to clocks/clock-bindings.txt for generic clock consumer properties. + Example: timer@35006000 { compatible = "brcm,kona-timer"; reg = <0x35006000 0x1000>; interrupts = <0x0 7 0x4>; - clock-frequency = <32768>; + clocks = <&hub_timer_clk>; }; diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt deleted file mode 100644 index 3545ea704b50..000000000000 --- a/Documentation/devicetree/bindings/arm/davinci/nand.txt +++ /dev/null @@ -1,46 +0,0 @@ -* Texas Instruments Davinci NAND - -This file provides information, what the device node for the -davinci nand interface contain. - -Required properties: -- compatible: "ti,davinci-nand"; -- reg : contain 2 offset/length values: - - offset and length for the access window - - offset and length for accessing the aemif control registers -- ti,davinci-chipselect: Indicates on the davinci_nand driver which - chipselect is used for accessing the nand. - -Recommended properties : -- ti,davinci-mask-ale: mask for ale -- ti,davinci-mask-cle: mask for cle -- ti,davinci-mask-chipsel: mask for chipselect -- ti,davinci-ecc-mode: ECC mode valid values for davinci driver: - - "none" - - "soft" - - "hw" -- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4. -- ti,davinci-nand-buswidth: buswidth 8 or 16 -- ti,davinci-nand-use-bbt: use flash based bad block table support. - -nand device bindings may contain additional sub-nodes describing -partitions of the address space. See partition.txt for more detail. - -Example(da850 EVM ): -nand_cs3@62000000 { - compatible = "ti,davinci-nand"; - reg = <0x62000000 0x807ff - 0x68000000 0x8000>; - ti,davinci-chipselect = <1>; - ti,davinci-mask-ale = <0>; - ti,davinci-mask-cle = <0>; - ti,davinci-mask-chipsel = <0>; - ti,davinci-ecc-mode = "hw"; - ti,davinci-ecc-bits = <4>; - ti,davinci-nand-use-bbt; - - partition@180000 { - label = "ubifs"; - reg = <0x180000 0x7e80000>; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt new file mode 100644 index 000000000000..56d1f4961075 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt @@ -0,0 +1,93 @@ +Broadcom Kona Family Clocks + +This binding is associated with Broadcom SoCs having "Kona" style +clock control units (CCUs). A CCU is a clock provider that manages +a set of clock signals. Each CCU is represented by a node in the +device tree. + +This binding uses the common clock binding: + Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible + Shall have one of the following values: + - "brcm,bcm11351-root-ccu" + - "brcm,bcm11351-aon-ccu" + - "brcm,bcm11351-hub-ccu" + - "brcm,bcm11351-master-ccu" + - "brcm,bcm11351-slave-ccu" +- reg + Shall define the base and range of the address space + containing clock control registers +- #clock-cells + Shall have value <1>. The permitted clock-specifier values + are defined below. +- clock-output-names + Shall be an ordered list of strings defining the names of + the clocks provided by the CCU. + + +BCM281XX family SoCs use Kona CCUs. The following table defines +the set of CCUs and clock specifiers for BCM281XX clocks. When +a clock consumer references a clocks, its symbolic specifier +(rather than its numeric index value) should be used. These +specifiers are defined in "include/dt-bindings/clock/bcm281xx.h". + + CCU Clock Type Index Specifier + --- ----- ---- ----- --------- + root frac_1m peri 0 BCM281XX_ROOT_CCU_FRAC_1M + + aon hub_timer peri 0 BCM281XX_AON_CCU_HUB_TIMER + aon pmu_bsc peri 1 BCM281XX_AON_CCU_PMU_BSC + aon pmu_bsc_var peri 2 BCM281XX_AON_CCU_PMU_BSC_VAR + + hub tmon_1m peri 0 BCM281XX_HUB_CCU_TMON_1M + + master sdio1 peri 0 BCM281XX_MASTER_CCU_SDIO1 + master sdio2 peri 1 BCM281XX_MASTER_CCU_SDIO2 + master sdio3 peri 2 BCM281XX_MASTER_CCU_SDIO3 + master sdio4 peri 3 BCM281XX_MASTER_CCU_SDIO4 + master dmac peri 4 BCM281XX_MASTER_CCU_DMAC + master usb_ic peri 5 BCM281XX_MASTER_CCU_USB_IC + master hsic2_48m peri 6 BCM281XX_MASTER_CCU_HSIC_48M + master hsic2_12m peri 7 BCM281XX_MASTER_CCU_HSIC_12M + + slave uartb peri 0 BCM281XX_SLAVE_CCU_UARTB + slave uartb2 peri 1 BCM281XX_SLAVE_CCU_UARTB2 + slave uartb3 peri 2 BCM281XX_SLAVE_CCU_UARTB3 + slave uartb4 peri 3 BCM281XX_SLAVE_CCU_UARTB4 + slave ssp0 peri 4 BCM281XX_SLAVE_CCU_SSP0 + slave ssp2 peri 5 BCM281XX_SLAVE_CCU_SSP2 + slave bsc1 peri 6 BCM281XX_SLAVE_CCU_BSC1 + slave bsc2 peri 7 BCM281XX_SLAVE_CCU_BSC2 + slave bsc3 peri 8 BCM281XX_SLAVE_CCU_BSC3 + slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM + + +Device tree example: + + slave_ccu: slave_ccu { + compatible = "brcm,bcm11351-slave-ccu"; + reg = <0x3e011000 0x0f00>; + #clock-cells = <1>; + clock-output-names = "uartb", + "uartb2", + "uartb3", + "uartb4"; + }; + + ref_crystal_clk: ref_crystal { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <26000000>; + }; + + uart@3e002000 { + compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; + status = "disabled"; + reg = <0x3e002000 0x1000>; + clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>; + interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>; + reg-shift = <2>; + reg-io-width = <4>; + }; diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt b/Documentation/devicetree/bindings/clock/corenet-clock.txt new file mode 100644 index 000000000000..24711af48e30 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt @@ -0,0 +1,134 @@ +* Clock Block on Freescale CoreNet Platforms + +Freescale CoreNet chips take primary clocking input from the external +SYSCLK signal. The SYSCLK input (frequency) is multiplied using +multiple phase locked loops (PLL) to create a variety of frequencies +which can then be passed to a variety of internal logic, including +cores and peripheral IP blocks. +Please refer to the Reference Manual for details. + +1. Clock Block Binding + +Required properties: +- compatible: Should contain a specific clock block compatible string + and a single chassis clock compatible string. + Clock block strings include, but not limited to, one of the: + * "fsl,p2041-clockgen" + * "fsl,p3041-clockgen" + * "fsl,p4080-clockgen" + * "fsl,p5020-clockgen" + * "fsl,p5040-clockgen" + * "fsl,t4240-clockgen" + * "fsl,b4420-clockgen" + * "fsl,b4860-clockgen" + Chassis clock strings include: + * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks + * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks +- reg: Describes the address of the device's resources within the + address space defined by its parent bus, and resource zero + represents the clock register set +- clock-frequency: Input system clock frequency + +Recommended properties: +- ranges: Allows valid translation between child's address space and + parent's. Must be present if the device has sub-nodes. +- #address-cells: Specifies the number of cells used to represent + physical base addresses. Must be present if the device has + sub-nodes and set to 1 if present +- #size-cells: Specifies the number of cells used to represent + the size of an address. Must be present if the device has + sub-nodes and set to 1 if present + +2. Clock Provider/Consumer Binding + +Most of the bindings are from the common clock binding[1]. + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : Should include one of the following: + * "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0) + * "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0) + * "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0) + * "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0) + * "fsl,qoriq-sysclk-1.0": for input system clock (v1.0). + It takes parent's clock-frequency as its clock. + * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0). + It takes parent's clock-frequency as its clock. +- #clock-cells: From common clock binding. The number of cells in a + clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0" + clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks. + For "fsl,qoriq-core-pll-[1,2].0" clocks, the single + clock-specifier cell may take the following values: + * 0 - equal to the PLL frequency + * 1 - equal to the PLL frequency divided by 2 + * 2 - equal to the PLL frequency divided by 4 + +Recommended properties: +- clocks: Should be the phandle of input parent clock +- clock-names: From common clock binding, indicates the clock name +- clock-output-names: From common clock binding, indicates the names of + output clocks +- reg: Should be the offset and length of clock block base address. + The length should be 4. + +Example for clock block and clock provider: +/ { + clockgen: global-utilities@e1000 { + compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0"; + ranges = <0x0 0xe1000 0x1000>; + clock-frequency = <133333333>; + reg = <0xe1000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + + sysclk: sysclk { + #clock-cells = <0>; + compatible = "fsl,qoriq-sysclk-1.0"; + clock-output-names = "sysclk"; + } + + pll0: pll0@800 { + #clock-cells = <1>; + reg = <0x800 0x4>; + compatible = "fsl,qoriq-core-pll-1.0"; + clocks = <&sysclk>; + clock-output-names = "pll0", "pll0-div2"; + }; + + pll1: pll1@820 { + #clock-cells = <1>; + reg = <0x820 0x4>; + compatible = "fsl,qoriq-core-pll-1.0"; + clocks = <&sysclk>; + clock-output-names = "pll1", "pll1-div2"; + }; + + mux0: mux0@0 { + #clock-cells = <0>; + reg = <0x0 0x4>; + compatible = "fsl,qoriq-core-mux-1.0"; + clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>; + clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2"; + clock-output-names = "cmux0"; + }; + + mux1: mux1@20 { + #clock-cells = <0>; + reg = <0x20 0x4>; + compatible = "fsl,qoriq-core-mux-1.0"; + clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>; + clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2"; + clock-output-names = "cmux1"; + }; + }; + } + +Example for clock consumer: + +/ { + cpu0: PowerPC,e5500@0 { + ... + clocks = <&mux0>; + ... + }; + } diff --git a/Documentation/devicetree/bindings/clock/ti/apll.txt b/Documentation/devicetree/bindings/clock/ti/apll.txt new file mode 100644 index 000000000000..7faf5a68b3be --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/apll.txt @@ -0,0 +1,31 @@ +Binding for Texas Instruments APLL clock. + +Binding status: Unstable - ABI compatibility may be broken in the future + +This binding uses the common clock binding[1]. It assumes a +register-mapped APLL with usually two selectable input clocks +(reference clock and bypass clock), with analog phase locked +loop logic for multiplying the input clock to a desired output +clock. This clock also typically supports different operation +modes (locked, low power stop etc.) APLL mostly behaves like +a subtype of a DPLL [2], although a simplified one at that. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/ti/dpll.txt + +Required properties: +- compatible : shall be "ti,dra7-apll-clock" +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles of parent clocks (clk-ref and clk-bypass) +- reg : address and length of the register set for controlling the APLL. + It contains the information of registers in the following order: + "control" - contains the control register base address + "idlest" - contains the idlest register base address + +Examples: + apll_pcie_ck: apll_pcie_ck@4a008200 { + #clock-cells = <0>; + clocks = <&apll_pcie_in_clk_mux>, <&dpll_pcie_ref_ck>; + reg = <0x4a00821c 0x4>, <0x4a008220 0x4>; + compatible = "ti,dra7-apll-clock"; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/autoidle.txt b/Documentation/devicetree/bindings/clock/ti/autoidle.txt new file mode 100644 index 000000000000..7c735dde9fe9 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/autoidle.txt @@ -0,0 +1,39 @@ +Binding for Texas Instruments autoidle clock. + +Binding status: Unstable - ABI compatibility may be broken in the future + +This binding uses the common clock binding[1]. It assumes a register mapped +clock which can be put to idle automatically by hardware based on the usage +and a configuration bit setting. Autoidle clock is never an individual +clock, it is always a derivative of some basic clock like a gate, divider, +or fixed-factor. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- reg : offset for the register controlling the autoidle +- ti,autoidle-shift : bit shift of the autoidle enable bit +- ti,invert-autoidle-bit : autoidle is enabled by setting the bit to 0 + +Examples: + dpll_core_m4_ck: dpll_core_m4_ck { + #clock-cells = <0>; + compatible = "ti,divider-clock"; + clocks = <&dpll_core_x2_ck>; + ti,max-div = <31>; + ti,autoidle-shift = <8>; + reg = <0x2d38>; + ti,index-starts-at-one; + ti,invert-autoidle-bit; + }; + + dpll_usb_clkdcoldo_ck: dpll_usb_clkdcoldo_ck { + #clock-cells = <0>; + compatible = "ti,fixed-factor-clock"; + clocks = <&dpll_usb_ck>; + ti,clock-div = <1>; + ti,autoidle-shift = <8>; + reg = <0x01b4>; + ti,clock-mult = <1>; + ti,invert-autoidle-bit; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt new file mode 100644 index 000000000000..cb76b3f2b341 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt @@ -0,0 +1,24 @@ +Binding for Texas Instruments clockdomain. + +Binding status: Unstable - ABI compatibility may be broken in the future + +This binding uses the common clock binding[1] in consumer role. +Every clock on TI SoC belongs to one clockdomain, but software +only needs this information for specific clocks which require +their parent clockdomain to be controlled when the clock is +enabled/disabled. This binding doesn't define a new clock +binding type, it is used to group existing clock nodes under +hardware hierarchy. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be "ti,clockdomain" +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles of clocks within this domain + +Examples: + dss_clkdm: dss_clkdm { + compatible = "ti,clockdomain"; + clocks = <&dss1_alwon_fck_3430es2>, <&dss_ick_3430es2>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/composite.txt b/Documentation/devicetree/bindings/clock/ti/composite.txt new file mode 100644 index 000000000000..5f43c4706b09 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/composite.txt @@ -0,0 +1,54 @@ +Binding for TI composite clock. + +Binding status: Unstable - ABI compatibility may be broken in the future + +This binding uses the common clock binding[1]. It assumes a +register-mapped composite clock with multiple different sub-types; + +a multiplexer clock with multiple input clock signals or parents, one +of which can be selected as output, this behaves exactly as [2] + +an adjustable clock rate divider, this behaves exactly as [3] + +a gating function which can be used to enable and disable the output +clock, this behaves exactly as [4] + +The binding must provide a list of the component clocks that shall be +merged to this clock. The component clocks shall be of one of the +"ti,*composite*-clock" types. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/ti/mux.txt +[3] Documentation/devicetree/bindings/clock/ti/divider.txt +[4] Documentation/devicetree/bindings/clock/ti/gate.txt + +Required properties: +- compatible : shall be: "ti,composite-clock" +- clocks : link phandles of component clocks +- #clock-cells : from common clock binding; shall be set to 0. + +Examples: + +usb_l4_gate_ick: usb_l4_gate_ick { + #clock-cells = <0>; + compatible = "ti,composite-interface-clock"; + clocks = <&l4_ick>; + ti,bit-shift = <5>; + reg = <0x0a10>; +}; + +usb_l4_div_ick: usb_l4_div_ick { + #clock-cells = <0>; + compatible = "ti,composite-divider-clock"; + clocks = <&l4_ick>; + ti,bit-shift = <4>; + ti,max-div = <1>; + reg = <0x0a40>; + ti,index-starts-at-one; +}; + +usb_l4_ick: usb_l4_ick { + #clock-cells = <0>; + compatible = "ti,composite-clock"; + clocks = <&usb_l4_gate_ick>, <&usb_l4_div_ick>; +}; diff --git a/Documentation/devicetree/bindings/clock/ti/divider.txt b/Documentation/devicetree/bindings/clock/ti/divider.txt new file mode 100644 index 000000000000..35a6f5c7e5c2 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/divider.txt @@ -0,0 +1,114 @@ +Binding for TI divider clock + +Binding status: Unstable - ABI compatibility may be broken in the future + +This binding uses the common clock binding[1]. It assumes a +register-mapped adjustable clock rate divider that does not gate and has +only one input clock or parent. By default the value programmed into +the register is one less than the actual divisor value. E.g: + +register value actual divisor value +0 1 +1 2 +2 3 + +This assumption may be modified by the following optional properties: + +ti,index-starts-at-one - valid divisor values start at 1, not the default +of 0. E.g: +register value actual divisor value +1 1 +2 2 +3 3 + +ti,index-power-of-two - valid divisor values are powers of two. E.g: +register value actual divisor value +0 1 +1 2 +2 4 + +Additionally an array of valid dividers may be supplied like so: + + ti,dividers = <4>, <8>, <0>, <16>; + +Which will map the resulting values to a divisor table by their index: +register value actual divisor value +0 4 +1 8 +2 <invalid divisor, skipped> +3 16 + +Any zero value in this array means the corresponding bit-value is invalid +and must not be used. + +The binding must also provide the register to control the divider and +unless the divider array is provided, min and max dividers. Optionally +the number of bits to shift that mask, if necessary. If the shift value +is missing it is the same as supplying a zero shift. + +This binding can also optionally provide support to the hardware autoidle +feature, see [2]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/ti/autoidle.txt + +Required properties: +- compatible : shall be "ti,divider-clock" or "ti,composite-divider-clock". +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link to phandle of parent clock +- reg : offset for register controlling adjustable divider + +Optional properties: +- clock-output-names : from common clock binding. +- ti,dividers : array of integers defining divisors +- ti,bit-shift : number of bits to shift the divider value, defaults to 0 +- ti,min-div : min divisor for dividing the input clock rate, only + needed if the first divisor is offset from the default value (1) +- ti,max-div : max divisor for dividing the input clock rate, only needed + if ti,dividers is not defined. +- ti,index-starts-at-one : valid divisor programming starts at 1, not zero, + only valid if ti,dividers is not defined. +- ti,index-power-of-two : valid divisor programming must be a power of two, + only valid if ti,dividers is not defined. +- ti,autoidle-shift : bit shift of the autoidle enable bit for the clock, + see [2] +- ti,invert-autoidle-bit : autoidle is enabled by setting the bit to 0, + see [2] +- ti,set-rate-parent : clk_set_rate is propagated to parent + +Examples: +dpll_usb_m2_ck: dpll_usb_m2_ck@4a008190 { + #clock-cells = <0>; + compatible = "ti,divider-clock"; + clocks = <&dpll_usb_ck>; + ti,max-div = <127>; + reg = <0x190>; + ti,index-starts-at-one; +}; + +aess_fclk: aess_fclk@4a004528 { + #clock-cells = <0>; + compatible = "ti,divider-clock"; + clocks = <&abe_clk>; + ti,bit-shift = <24>; + reg = <0x528>; + ti,max-div = <2>; +}; + +dpll_core_m3x2_div_ck: dpll_core_m3x2_div_ck { + #clock-cells = <0>; + compatible = "ti,composite-divider-clock"; + clocks = <&dpll_core_x2_ck>; + ti,max-div = <31>; + reg = <0x0134>; + ti,index-starts-at-one; +}; + +ssi_ssr_div_fck_3430es2: ssi_ssr_div_fck_3430es2 { + #clock-cells = <0>; + compatible = "ti,composite-divider-clock"; + clocks = <&corex2_fck>; + ti,bit-shift = <8>; + reg = <0x0a40>; + ti,dividers = <0>, <1>, <2>, <3>, <4>, <0>, <6>, <0>, <8>; +}; diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt new file mode 100644 index 000000000000..30bfdb7c9f18 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -0,0 +1,75 @@ +Binding for Texas Instruments DPLL clock. + +Binding status: Unstable - ABI compatibility may be broken in the future + +This binding uses the common clock binding[1]. It assumes a +register-mapped DPLL with usually two selectable input clocks +(reference clock and bypass clock), with digital phase locked +loop logic for multiplying the input clock to a desired output +clock. This clock also typically supports different operation +modes (locked, low power stop etc.) This binding has several +sub-types, which effectively result in slightly different setup +for the actual DPLL clock. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be one of: + "ti,omap3-dpll-clock", + "ti,omap3-dpll-core-clock", + "ti,omap3-dpll-per-clock", + "ti,omap3-dpll-per-j-type-clock", + "ti,omap4-dpll-clock", + "ti,omap4-dpll-x2-clock", + "ti,omap4-dpll-core-clock", + "ti,omap4-dpll-m4xen-clock", + "ti,omap4-dpll-j-type-clock", + "ti,am3-dpll-no-gate-clock", + "ti,am3-dpll-j-type-clock", + "ti,am3-dpll-no-gate-j-type-clock", + "ti,am3-dpll-clock", + "ti,am3-dpll-core-clock", + "ti,am3-dpll-x2-clock", + +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles of parent clocks, first entry lists reference clock + and second entry bypass clock +- reg : offsets for the register set for controlling the DPLL. + Registers are listed in following order: + "control" - contains the control register base address + "idlest" - contains the idle status register base address + "mult-div1" - contains the multiplier / divider register base address + "autoidle" - contains the autoidle register base address (optional) + ti,am3-* dpll types do not have autoidle register + +Optional properties: +- DPLL mode setting - defining any one or more of the following overrides + default setting. + - ti,low-power-stop : DPLL supports low power stop mode, gating output + - ti,low-power-bypass : DPLL output matches rate of parent bypass clock + - ti,lock : DPLL locks in programmed rate + +Examples: + dpll_core_ck: dpll_core_ck@44e00490 { + #clock-cells = <0>; + compatible = "ti,omap4-dpll-core-clock"; + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; + reg = <0x490>, <0x45c>, <0x488>, <0x468>; + }; + + dpll2_ck: dpll2_ck@48004004 { + #clock-cells = <0>; + compatible = "ti,omap3-dpll-clock"; + clocks = <&sys_ck>, <&dpll2_fck>; + ti,low-power-stop; + ti,low-power-bypass; + ti,lock; + reg = <0x4>, <0x24>, <0x34>, <0x40>; + }; + + dpll_core_ck: dpll_core_ck@44e00490 { + #clock-cells = <0>; + compatible = "ti,am3-dpll-core-clock"; + clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; + reg = <0x90>, <0x5c>, <0x68>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt new file mode 100644 index 000000000000..662b36d53bf0 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt @@ -0,0 +1,43 @@ +Binding for TI fixed factor rate clock sources. + +Binding status: Unstable - ABI compatibility may be broken in the future + +This binding uses the common clock binding[1], and also uses the autoidle +support from TI autoidle clock [2]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/ti/autoidle.txt + +Required properties: +- compatible : shall be "ti,fixed-factor-clock". +- #clock-cells : from common clock binding; shall be set to 0. +- ti,clock-div: fixed divider. +- ti,clock-mult: fixed multiplier. +- clocks: parent clock. + +Optional properties: +- ti,autoidle-shift: bit shift of the autoidle enable bit for the clock, + see [2] +- reg: offset for the autoidle register of this clock, see [2] +- ti,invert-autoidle-bit: autoidle is enabled by setting the bit to 0, see [2] +- ti,set-rate-parent: clk_set_rate is propagated to parent + +Example: + clock { + compatible = "ti,fixed-factor-clock"; + clocks = <&parentclk>; + #clock-cells = <0>; + ti,clock-div = <2>; + ti,clock-mult = <1>; + }; + + dpll_usb_clkdcoldo_ck: dpll_usb_clkdcoldo_ck { + #clock-cells = <0>; + compatible = "ti,fixed-factor-clock"; + clocks = <&dpll_usb_ck>; + ti,clock-div = <1>; + ti,autoidle-shift = <8>; + reg = <0x01b4>; + ti,clock-mult = <1>; + ti,invert-autoidle-bit; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt new file mode 100644 index 000000000000..125281aaa4ca --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/gate.txt @@ -0,0 +1,85 @@ +Binding for Texas Instruments gate clock. + +Binding status: Unstable - ABI compatibility may be broken in the future + +This binding uses the common clock binding[1]. This clock is +quite much similar to the basic gate-clock [2], however, +it supports a number of additional features. If no register +is provided for this clock, the code assumes that a clockdomain +will be controlled instead and the corresponding hw-ops for +that is used. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/gate-clock.txt +[3] Documentation/devicetree/bindings/clock/ti/clockdomain.txt + +Required properties: +- compatible : shall be one of: + "ti,gate-clock" - basic gate clock + "ti,wait-gate-clock" - gate clock which waits until clock is active before + returning from clk_enable() + "ti,dss-gate-clock" - gate clock with DSS specific hardware handling + "ti,am35xx-gate-clock" - gate clock with AM35xx specific hardware handling + "ti,clkdm-gate-clock" - clockdomain gate clock, which derives its functional + clock directly from a clockdomain, see [3] how + to map clockdomains properly + "ti,hsdiv-gate-clock" - gate clock with OMAP36xx specific hardware handling, + required for a hardware errata +- #clock-cells : from common clock binding; shall be set to 0 +- clocks : link to phandle of parent clock +- reg : offset for register controlling adjustable gate, not needed for + ti,clkdm-gate-clock type + +Optional properties: +- ti,bit-shift : bit shift for programming the clock gate, invalid for + ti,clkdm-gate-clock type +- ti,set-bit-to-disable : inverts default gate programming. Setting the bit + gates the clock and clearing the bit ungates the clock. + +Examples: + mmchs2_fck: mmchs2_fck@48004a00 { + #clock-cells = <0>; + compatible = "ti,gate-clock"; + clocks = <&core_96m_fck>; + reg = <0x48004a00 0x4>; + ti,bit-shift = <25>; + }; + + uart4_fck_am35xx: uart4_fck_am35xx { + #clock-cells = <0>; + compatible = "ti,wait-gate-clock"; + clocks = <&core_48m_fck>; + reg = <0x0a00>; + ti,bit-shift = <23>; + }; + + dss1_alwon_fck_3430es2: dss1_alwon_fck_3430es2@48004e00 { + #clock-cells = <0>; + compatible = "ti,dss-gate-clock"; + clocks = <&dpll4_m4x2_ck>; + reg = <0x48004e00 0x4>; + ti,bit-shift = <0>; + }; + + emac_ick: emac_ick@4800259c { + #clock-cells = <0>; + compatible = "ti,am35xx-gate-clock"; + clocks = <&ipss_ick>; + reg = <0x4800259c 0x4>; + ti,bit-shift = <1>; + }; + + emu_src_ck: emu_src_ck { + #clock-cells = <0>; + compatible = "ti,clkdm-gate-clock"; + clocks = <&emu_src_mux_ck>; + }; + + dpll4_m2x2_ck: dpll4_m2x2_ck@48004d00 { + #clock-cells = <0>; + compatible = "ti,hsdiv-gate-clock"; + clocks = <&dpll4_m2x2_mul_ck>; + ti,bit-shift = <0x1b>; + reg = <0x48004d00 0x4>; + ti,set-bit-to-disable; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt new file mode 100644 index 000000000000..064e8caccac3 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/interface.txt @@ -0,0 +1,54 @@ +Binding for Texas Instruments interface clock. + +Binding status: Unstable - ABI compatibility may be broken in the future + +This binding uses the common clock binding[1]. This clock is +quite much similar to the basic gate-clock [2], however, +it supports a number of additional features, including +companion clock finding (match corresponding functional gate +clock) and hardware autoidle enable / disable. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/gate-clock.txt + +Required properties: +- compatible : shall be one of: + "ti,omap3-interface-clock" - basic OMAP3 interface clock + "ti,omap3-no-wait-interface-clock" - interface clock which has no hardware + capability for waiting clock to be ready + "ti,omap3-hsotgusb-interface-clock" - interface clock with USB specific HW + handling + "ti,omap3-dss-interface-clock" - interface clock with DSS specific HW handling + "ti,omap3-ssi-interface-clock" - interface clock with SSI specific HW handling + "ti,am35xx-interface-clock" - interface clock with AM35xx specific HW handling +- #clock-cells : from common clock binding; shall be set to 0 +- clocks : link to phandle of parent clock +- reg : base address for the control register + +Optional properties: +- ti,bit-shift : bit shift for the bit enabling/disabling the clock (default 0) + +Examples: + aes1_ick: aes1_ick@48004a14 { + #clock-cells = <0>; + compatible = "ti,omap3-interface-clock"; + clocks = <&security_l4_ick2>; + reg = <0x48004a14 0x4>; + ti,bit-shift = <3>; + }; + + cam_ick: cam_ick@48004f10 { + #clock-cells = <0>; + compatible = "ti,omap3-no-wait-interface-clock"; + clocks = <&l4_ick>; + reg = <0x48004f10 0x4>; + ti,bit-shift = <0>; + }; + + ssi_ick_3430es2: ssi_ick_3430es2@48004a10 { + #clock-cells = <0>; + compatible = "ti,omap3-ssi-interface-clock"; + clocks = <&ssi_l4_ick>; + reg = <0x48004a10 0x4>; + ti,bit-shift = <0>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/mux.txt b/Documentation/devicetree/bindings/clock/ti/mux.txt new file mode 100644 index 000000000000..2d0d170f8001 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/mux.txt @@ -0,0 +1,76 @@ +Binding for TI mux clock. + +Binding status: Unstable - ABI compatibility may be broken in the future + +This binding uses the common clock binding[1]. It assumes a +register-mapped multiplexer with multiple input clock signals or +parents, one of which can be selected as output. This clock does not +gate or adjust the parent rate via a divider or multiplier. + +By default the "clocks" property lists the parents in the same order +as they are programmed into the regster. E.g: + + clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>; + +results in programming the register as follows: + +register value selected parent clock +0 foo_clock +1 bar_clock +2 baz_clock + +Some clock controller IPs do not allow a value of zero to be programmed +into the register, instead indexing begins at 1. The optional property +"index-starts-at-one" modified the scheme as follows: + +register value selected clock parent +1 foo_clock +2 bar_clock +3 baz_clock + +The binding must provide the register to control the mux. Optionally +the number of bits to shift the control field in the register can be +supplied. If the shift value is missing it is the same as supplying +a zero shift. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be "ti,mux-clock" or "ti,composite-mux-clock". +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles of parent clocks +- reg : register offset for register controlling adjustable mux + +Optional properties: +- ti,bit-shift : number of bits to shift the bit-mask, defaults to + 0 if not present +- ti,index-starts-at-one : valid input select programming starts at 1, not + zero +- ti,set-rate-parent : clk_set_rate is propagated to parent clock, + not supported by the composite-mux-clock subtype + +Examples: + +sys_clkin_ck: sys_clkin_ck@4a306110 { + #clock-cells = <0>; + compatible = "ti,mux-clock"; + clocks = <&virt_12000000_ck>, <&virt_13000000_ck>, <&virt_16800000_ck>, <&virt_19200000_ck>, <&virt_26000000_ck>, <&virt_27000000_ck>, <&virt_38400000_ck>; + reg = <0x0110>; + ti,index-starts-at-one; +}; + +abe_dpll_bypass_clk_mux_ck: abe_dpll_bypass_clk_mux_ck@4a306108 { + #clock-cells = <0>; + compatible = "ti,mux-clock"; + clocks = <&sys_clkin_ck>, <&sys_32k_ck>; + ti,bit-shift = <24>; + reg = <0x0108>; +}; + +mcbsp5_mux_fck: mcbsp5_mux_fck { + #clock-cells = <0>; + compatible = "ti,composite-mux-clock"; + clocks = <&core_96m_fck>, <&mcbsp_clks>; + ti,bit-shift = <4>; + reg = <0x02d8>; +}; diff --git a/Documentation/devicetree/bindings/dma/bcm2835-dma.txt b/Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file mode 100644 index 000000000000..1396078d15ac --- /dev/null +++ b/Documentation/devicetree/bindings/dma/bcm2835-dma.txt @@ -0,0 +1,57 @@ +* BCM2835 DMA controller + +The BCM2835 DMA controller has 16 channels in total. +Only the lower 13 channels have an associated IRQ. +Some arbitrary channels are used by the firmware +(1,3,6,7 in the current firmware version). +The channels 0,2 and 3 have special functionality +and should not be used by the driver. + +Required properties: +- compatible: Should be "brcm,bcm2835-dma". +- reg: Should contain DMA registers location and length. +- interrupts: Should contain the DMA interrupts associated + to the DMA channels in ascending order. +- #dma-cells: Must be <1>, the cell in the dmas property of the + client device represents the DREQ number. +- brcm,dma-channel-mask: Bit mask representing the channels + not used by the firmware in ascending order, + i.e. first channel corresponds to LSB. + +Example: + +dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16>, + <1 17>, + <1 18>, + <1 19>, + <1 20>, + <1 21>, + <1 22>, + <1 23>, + <1 24>, + <1 25>, + <1 26>, + <1 27>, + <1 28>; + + #dma-cells = <1>; + brcm,dma-channel-mask = <0x7f35>; +}; + +DMA clients connected to the BCM2835 DMA controller must use the format +described in the dma.txt file, using a two-cell specifier for each channel. + +Example: + +bcm2835_i2s: i2s@7e203000 { + compatible = "brcm,bcm2835-i2s"; + reg = < 0x7e203000 0x20>, + < 0x7e101098 0x02>; + + dmas = <&dma 2>, + <&dma 3>; + dma-names = "tx", "rx"; +}; diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt index 4fa814d38321..68b83ecc3850 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt @@ -42,6 +42,7 @@ The full ID of peripheral types can be found below. 19 IPU Memory 20 ASRC 21 ESAI + 22 SSI Dual FIFO (needs firmware ver >= 2) The third cell specifies the transfer priority as below. diff --git a/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt new file mode 100644 index 000000000000..8a9f3559335b --- /dev/null +++ b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt @@ -0,0 +1,45 @@ +MOXA ART DMA Controller + +See dma.txt first + +Required properties: + +- compatible : Must be "moxa,moxart-dma" +- reg : Should contain registers location and length +- interrupts : Should contain an interrupt-specifier for the sole + interrupt generated by the device +- #dma-cells : Should be 1, a single cell holding a line request number + +Example: + + dma: dma@90500000 { + compatible = "moxa,moxart-dma"; + reg = <0x90500080 0x40>; + interrupts = <24 0>; + #dma-cells = <1>; + }; + + +Clients: + +DMA clients connected to the MOXA ART DMA controller must use the format +described in the dma.txt file, using a two-cell specifier for each channel: +a phandle plus one integer cells. +The two cells in order are: + +1. A phandle pointing to the DMA controller. +2. Peripheral identifier for the hardware handshaking interface. + +Example: +Use specific request line passing from dma +For example, MMC request line is 5 + + sdhci: sdhci@98e00000 { + compatible = "moxa,moxart-sdhci"; + reg = <0x98e00000 0x5C>; + interrupts = <5 0>; + clocks = <&clk_apb>; + dmas = <&dma 5>, + <&dma 5>; + dma-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt index ab45c02aa658..efaeec8961b6 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt @@ -118,6 +118,9 @@ of the following host1x client modules: See ../reset/reset.txt for details. - reset-names: Must include the following entries: - dc + - nvidia,head: The number of the display controller head. This is used to + setup the various types of output to receive video data from the given + head. Each display controller node has a child node, named "rgb", that represents the RGB output associated with the controller. It can take the following @@ -125,6 +128,7 @@ of the following host1x client modules: - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - nvidia,edid: supplies a binary EDID blob + - nvidia,panel: phandle of a display panel - hdmi: High Definition Multimedia Interface @@ -149,6 +153,7 @@ of the following host1x client modules: - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - nvidia,edid: supplies a binary EDID blob + - nvidia,panel: phandle of a display panel - tvo: TV encoder output @@ -169,11 +174,21 @@ of the following host1x client modules: - clock-names: Must include the following entries: - dsi This MUST be the first entry. + - lp - parent - resets: Must contain an entry for each entry in reset-names. See ../reset/reset.txt for details. - reset-names: Must include the following entries: - dsi + - nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying + which pads are used by this DSI output and need to be calibrated. See also + ../mipi/nvidia,tegra114-mipi.txt. + + Optional properties: + - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing + - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection + - nvidia,edid: supplies a binary EDID blob + - nvidia,panel: phandle of a display panel Example: @@ -253,7 +268,7 @@ Example: interrupts = <0 73 0x04>; clocks = <&tegra_car TEGRA20_CLK_DISP1>, <&tegra_car TEGRA20_CLK_PLL_P>; - clock-names = "disp1", "parent"; + clock-names = "dc", "parent"; resets = <&tegra_car 27>; reset-names = "dc"; @@ -268,7 +283,7 @@ Example: interrupts = <0 74 0x04>; clocks = <&tegra_car TEGRA20_CLK_DISP2>, <&tegra_car TEGRA20_CLK_PLL_P>; - clock-names = "disp2", "parent"; + clock-names = "dc", "parent"; resets = <&tegra_car 26>; reset-names = "dc"; diff --git a/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt new file mode 100644 index 000000000000..aee38e7c13e7 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt @@ -0,0 +1,18 @@ +TI-NSPIRE interrupt controller + +Required properties: +- compatible: Compatible property value should be "lsi,zevio-intc". + +- reg: Physical base address of the controller and length of memory mapped + region. + +- interrupt-controller : Identifies the node as an interrupt controller + +Example: + +interrupt-controller { + compatible = "lsi,zevio-intc"; + interrupt-controller; + reg = <0xDC000000 0x1000>; + #interrupt-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/leds/tca6507.txt b/Documentation/devicetree/bindings/leds/tca6507.txt index 80ff3dfb1f32..d7221b84987c 100644 --- a/Documentation/devicetree/bindings/leds/tca6507.txt +++ b/Documentation/devicetree/bindings/leds/tca6507.txt @@ -2,6 +2,13 @@ LEDs connected to tca6507 Required properties: - compatible : should be : "ti,tca6507". +- #address-cells: must be 1 +- #size-cells: must be 0 +- reg: typically 0x45. + +Optional properties: +- gpio-controller: allows lines to be used as output-only GPIOs. +- #gpio-cells: if present, must be 0. Each led is represented as a sub-node of the ti,tca6507 device. @@ -10,6 +17,7 @@ LED sub-node properties: - reg : number of LED line (could be from 0 to 6) - linux,default-trigger : (optional) see Documentation/devicetree/bindings/leds/common.txt +- compatible: either "led" (the default) or "gpio". Examples: @@ -19,6 +27,9 @@ tca6507@45 { #size-cells = <0>; reg = <0x45>; + gpio-controller; + #gpio-cells = <2>; + led0: red-aux@0 { label = "red:aux"; reg = <0x0>; @@ -29,5 +40,10 @@ tca6507@45 { reg = <0x5>; linux,default-trigger = "default-on"; }; + + wifi-reset@6 { + reg = <0x6>; + compatible = "gpio"; + }; }; diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt new file mode 100644 index 000000000000..937b755baf8f --- /dev/null +++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt @@ -0,0 +1,11 @@ +Samsung S5P/EXYNOS SoC series JPEG codec + +Required properties: + +- compatible : should be one of: + "samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg"; +- reg : address and length of the JPEG codec IP register set; +- interrupts : specifies the JPEG codec IP interrupt; +- clocks : should contain the JPEG codec IP gate clock specifier, from the + common clock bindings; +- clock-names : should contain "jpeg" entry. diff --git a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt new file mode 100644 index 000000000000..1f51e0439c96 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt @@ -0,0 +1,58 @@ +Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor with embedded SoC ISP +-------------------------------------------------------------------- + +Required properties: + +- compatible : "samsung,s5k5baf"; +- reg : I2C slave address of the sensor; +- vdda-supply : analog power supply 2.8V (2.6V to 3.0V); +- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V) + or 2.8V (2.6V to 3.0); +- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V) + or 2.8V (2.5V to 3.1V); +- stbyn-gpios : GPIO connected to STDBYN pin; +- rstn-gpios : GPIO connected to RSTN pin; +- clocks : list of phandle and clock specifier pairs + according to common clock bindings for the + clocks described in clock-names; +- clock-names : should include "mclk" for the sensor's master clock; + +Optional properties: + +- clock-frequency : the frequency at which the "mclk" clock should be + configured to operate, in Hz; if this property is not + specified default 24 MHz value will be used. + +The device node should contain one 'port' child node with one child 'endpoint' +node, according to the bindings defined in Documentation/devicetree/bindings/ +media/video-interfaces.txt. The following are properties specific to those +nodes. + +endpoint node +------------- + +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in + video-interfaces.txt. If present it should be <1> - the device + supports only one data lane without re-mapping. + +Example: + +s5k5bafx@2d { + compatible = "samsung,s5k5baf"; + reg = <0x2d>; + vdda-supply = <&cam_io_en_reg>; + vddreg-supply = <&vt_core_15v_reg>; + vddio-supply = <&vtcam_reg>; + stbyn-gpios = <&gpl2 0 1>; + rstn-gpios = <&gpl2 1 1>; + clock-names = "mclk"; + clocks = <&clock_cam 0>; + clock-frequency = <24000000>; + + port { + s5k5bafx_ep: endpoint { + remote-endpoint = <&csis1_ep>; + data-lanes = <1>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt new file mode 100644 index 000000000000..973c27273772 --- /dev/null +++ b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt @@ -0,0 +1,98 @@ +MIPI DSI (Display Serial Interface) busses +========================================== + +The MIPI Display Serial Interface specifies a serial bus and a protocol for +communication between a host and up to four peripherals. This document will +define the syntax used to represent a DSI bus in a device tree. + +This document describes DSI bus-specific properties only or defines existing +standard properties in the context of the DSI bus. + +Each DSI host provides a DSI bus. The DSI host controller's node contains a +set of properties that characterize the bus. Child nodes describe individual +peripherals on that bus. + +The following assumes that only a single peripheral is connected to a DSI +host. Experience shows that this is true for the large majority of setups. + +DSI host +-------- + +In addition to the standard properties and those defined by the parent bus of +a DSI host, the following properties apply to a node representing a DSI host. + +Required properties: +- #address-cells: The number of cells required to represent an address on the + bus. DSI peripherals are addressed using a 2-bit virtual channel number, so + a maximum of 4 devices can be addressed on a single bus. Hence the value of + this property should be 1. +- #size-cells: Should be 0. There are cases where it makes sense to use a + different value here. See below. + +DSI peripheral +-------------- + +Peripherals are represented as child nodes of the DSI host's node. Properties +described here apply to all DSI peripherals, but individual bindings may want +to define additional, device-specific properties. + +Required properties: +- reg: The virtual channel number of a DSI peripheral. Must be in the range + from 0 to 3. + +Some DSI peripherals respond to more than a single virtual channel. In that +case two alternative representations can be chosen: +- The reg property can take multiple entries, one for each virtual channel + that the peripheral responds to. +- If the virtual channels that a peripheral responds to are consecutive, the + #size-cells can be set to 1. The first cell of each entry in the reg + property is the number of the first virtual channel and the second cell is + the number of consecutive virtual channels. + +Example +------- + + dsi-host { + ... + + #address-cells = <1>; + #size-cells = <0>; + + /* peripheral responds to virtual channel 0 */ + peripheral@0 { + compatible = "..."; + reg = <0>; + }; + + ... + }; + + dsi-host { + ... + + #address-cells = <1>; + #size-cells = <0>; + + /* peripheral responds to virtual channels 0 and 2 */ + peripheral@0 { + compatible = "..."; + reg = <0, 2>; + }; + + ... + }; + + dsi-host { + ... + + #address-cells = <1>; + #size-cells = <1>; + + /* peripheral responds to virtual channels 1, 2 and 3 */ + peripheral@1 { + compatible = "..."; + reg = <1 3>; + }; + + ... + }; diff --git a/Documentation/devicetree/bindings/mipi/nvidia,tegra114-mipi.txt b/Documentation/devicetree/bindings/mipi/nvidia,tegra114-mipi.txt new file mode 100644 index 000000000000..e4a25cedc5cf --- /dev/null +++ b/Documentation/devicetree/bindings/mipi/nvidia,tegra114-mipi.txt @@ -0,0 +1,41 @@ +NVIDIA Tegra MIPI pad calibration controller + +Required properties: +- compatible: "nvidia,tegra<chip>-mipi" +- reg: Physical base address and length of the controller's registers. +- clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - mipi-cal +- #nvidia,mipi-calibrate-cells: Should be 1. The cell is a bitmask of the pads + that need to be calibrated for a given device. + +User nodes need to contain an nvidia,mipi-calibrate property that has a +phandle to refer to the calibration controller node and a bitmask of the pads +that need to be calibrated. + +Example: + + mipi: mipi@700e3000 { + compatible = "nvidia,tegra114-mipi"; + reg = <0x700e3000 0x100>; + clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>; + clock-names = "mipi-cal"; + #nvidia,mipi-calibrate-cells = <1>; + }; + + ... + + host1x@50000000 { + ... + + dsi@54300000 { + ... + + nvidia,mipi-calibrate = <&mipi 0x060>; + + ... + }; + + ... + }; diff --git a/Documentation/devicetree/bindings/mmc/kona-sdhci.txt b/Documentation/devicetree/bindings/mmc/kona-sdhci.txt index 789fb07a426d..aaba2483b4ff 100644 --- a/Documentation/devicetree/bindings/mmc/kona-sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/kona-sdhci.txt @@ -6,12 +6,16 @@ and the properties present in the bcm281xx SDHCI Required properties: - compatible : Should be "brcm,kona-sdhci" - DEPRECATED: compatible : Should be "bcm,kona-sdhci" +- clocks: phandle + clock specifier pair of the external clock + +Refer to clocks/clock-bindings.txt for generic clock consumer properties. Example: sdio2: sdio@0x3f1a0000 { compatible = "brcm,kona-sdhci"; reg = <0x3f1a0000 0x10000>; + clocks = <&sdio3_clk>; interrupts = <0x0 74 0x4>; }; diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt b/Documentation/devicetree/bindings/mtd/davinci-nand.txt new file mode 100644 index 000000000000..cfb18abe6001 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt @@ -0,0 +1,94 @@ +Device tree bindings for Texas instruments Davinci/Keystone NAND controller + +This file provides information, what the device node for the davinci/keystone +NAND interface contains. + +Documentation: +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf + +Required properties: + +- compatible: "ti,davinci-nand" + "ti,keystone-nand" + +- reg: Contains 2 offset/length values: + - offset and length for the access window. + - offset and length for accessing the AEMIF + control registers. + +- ti,davinci-chipselect: number of chipselect. Indicates on the + davinci_nand driver which chipselect is used + for accessing the nand. + Can be in the range [0-3]. + +Recommended properties : + +- ti,davinci-mask-ale: mask for ALE. Needed for executing address + phase. These offset will be added to the base + address for the chip select space the NAND Flash + device is connected to. + If not set equal to 0x08. + +- ti,davinci-mask-cle: mask for CLE. Needed for executing command + phase. These offset will be added to the base + address for the chip select space the NAND Flash + device is connected to. + If not set equal to 0x10. + +- ti,davinci-mask-chipsel: mask for chipselect address. Needed to mask + addresses for given chipselect. + +- nand-ecc-mode: operation mode of the NAND ecc mode. ECC mode + valid values for davinci driver: + - "none" + - "soft" + - "hw" + +- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4. + +- nand-bus-width: buswidth 8 or 16. If not present 8. + +- nand-on-flash-bbt: use flash based bad block table support. OOB + identifier is saved in OOB area. If not present + false. + +Deprecated properties: + +- ti,davinci-ecc-mode: operation mode of the NAND ecc mode. ECC mode + valid values for davinci driver: + - "none" + - "soft" + - "hw" + +- ti,davinci-nand-buswidth: buswidth 8 or 16. If not present 8. + +- ti,davinci-nand-use-bbt: use flash based bad block table support. OOB + identifier is saved in OOB area. If not present + false. + +Nand device bindings may contain additional sub-nodes describing partitions of +the address space. See partition.txt for more detail. The NAND Flash timing +values must be programmed in the chip select’s node of AEMIF +memory-controller (see Documentation/devicetree/bindings/memory-controllers/ +davinci-aemif.txt). + +Example(da850 EVM ): + +nand_cs3@62000000 { + compatible = "ti,davinci-nand"; + reg = <0x62000000 0x807ff + 0x68000000 0x8000>; + ti,davinci-chipselect = <1>; + ti,davinci-mask-ale = <0>; + ti,davinci-mask-cle = <0>; + ti,davinci-mask-chipsel = <0>; + nand-ecc-mode = "hw"; + ti,davinci-ecc-bits = <4>; + nand-on-flash-bbt; + + partition@180000 { + label = "ubifs"; + reg = <0x180000 0x7e80000>; + }; +}; diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt index 551b2a179d01..458d59634688 100644 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt @@ -17,6 +17,14 @@ Required properties: Optional properties: - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false + - fsl,use-minimum-ecc: Protect this NAND flash with the minimum ECC + strength required. The required ECC strength is + automatically discoverable for some flash + (e.g., according to the ONFI standard). + However, note that if this strength is not + discoverable or this property is not enabled, + the software may chooses an implementation-defined + ECC scheme. The device tree may optionally contain sub-nodes describing partitions of the address space. See partition.txt for more detail. diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt index f1421e2bbab7..86e0a5601ff5 100644 --- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt +++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt @@ -2,7 +2,9 @@ PXA3xx NAND DT bindings Required properties: - - compatible: Should be "marvell,pxa3xx-nand" + - compatible: Should be set to one of the following: + marvell,pxa3xx-nand + marvell,armada370-nand - reg: The register base for the controller - interrupts: The interrupt to map - #address-cells: Set to <1> if the node includes partitions @@ -13,6 +15,8 @@ Optional properties: - marvell,nand-keep-config: Set to keep the NAND controller config as set by the bootloader - num-cs: Number of chipselect lines to usw + - nand-on-flash-bbt: boolean to enable on flash bbt option if + not present false Example: diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt index b90bfcd138ff..863d5b8155c7 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt @@ -1,7 +1,8 @@ * Allwinner EMAC ethernet controller Required properties: -- compatible: should be "allwinner,sun4i-emac". +- compatible: should be "allwinner,sun4i-a10-emac" (Deprecated: + "allwinner,sun4i-emac") - reg: address and length of the register set for the device. - interrupts: interrupt for the device - phy: A phandle to a phy node defining the PHY address (as the reg @@ -14,7 +15,7 @@ Optional properties: Example: emac: ethernet@01c0b000 { - compatible = "allwinner,sun4i-emac"; + compatible = "allwinner,sun4i-a10-emac"; reg = <0x01c0b000 0x1000>; interrupts = <55>; clocks = <&ahb_gates 17>; diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt index 00b9f9a3ec1d..4ec56413779d 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt @@ -1,7 +1,8 @@ * Allwinner A10 MDIO Ethernet Controller interface Required properties: -- compatible: should be "allwinner,sun4i-mdio". +- compatible: should be "allwinner,sun4i-a10-mdio" + (Deprecated: "allwinner,sun4i-mdio"). - reg: address and length of the register set for the device. Optional properties: @@ -9,7 +10,7 @@ Optional properties: Example at the SoC level: mdio@01c0b080 { - compatible = "allwinner,sun4i-mdio"; + compatible = "allwinner,sun4i-a10-mdio"; reg = <0x01c0b080 0x14>; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/net/davinci_emac.txt b/Documentation/devicetree/bindings/net/davinci_emac.txt index ca0911a20e8b..6e356d15154a 100644 --- a/Documentation/devicetree/bindings/net/davinci_emac.txt +++ b/Documentation/devicetree/bindings/net/davinci_emac.txt @@ -10,8 +10,6 @@ Required properties: - ti,davinci-ctrl-mod-reg-offset: offset to control module register - ti,davinci-ctrl-ram-offset: offset to control module ram - ti,davinci-ctrl-ram-size: size of control module ram -- ti,davinci-rmii-en: use RMII -- ti,davinci-no-bd-ram: has the emac controller BD RAM - interrupts: interrupt mapping for the davinci emac interrupts sources: 4 sources: <Receive Threshold Interrupt Receive Interrupt @@ -22,6 +20,8 @@ Optional properties: - phy-handle: Contains a phandle to an Ethernet PHY. If absent, davinci_emac driver defaults to 100/FULL. - local-mac-address : 6 bytes, mac address +- ti,davinci-rmii-en: 1 byte, 1 means use RMII +- ti,davinci-no-bd-ram: boolean, does EMAC have BD RAM? Example (enbw_cmc board): eth0: emac@1e20000 { diff --git a/Documentation/devicetree/bindings/panel/auo,b101aw03.txt b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt new file mode 100644 index 000000000000..72e088a4fb3a --- /dev/null +++ b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 10.1" WSVGA TFT LCD panel + +Required properties: +- compatible: should be "auo,b101aw03" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/chunghwa,claa101wa01a.txt b/Documentation/devicetree/bindings/panel/chunghwa,claa101wa01a.txt new file mode 100644 index 000000000000..f24614e4d5ec --- /dev/null +++ b/Documentation/devicetree/bindings/panel/chunghwa,claa101wa01a.txt @@ -0,0 +1,7 @@ +Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "chunghwa,claa101wa01a" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt new file mode 100644 index 000000000000..0ab2c05a4c22 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt @@ -0,0 +1,7 @@ +Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "chunghwa,claa101wb03" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt new file mode 100644 index 000000000000..d328b0341bf4 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt @@ -0,0 +1,7 @@ +Panasonic Corporation 10.1" WUXGA TFT LCD panel + +Required properties: +- compatible: should be "panasonic,vvx10f004b00" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/samsung,ltn101nt05.txt b/Documentation/devicetree/bindings/panel/samsung,ltn101nt05.txt new file mode 100644 index 000000000000..ef522c6bb85f --- /dev/null +++ b/Documentation/devicetree/bindings/panel/samsung,ltn101nt05.txt @@ -0,0 +1,7 @@ +Samsung Electronics 10.1" WSVGA TFT LCD panel + +Required properties: +- compatible: should be "samsung,ltn101nt05" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/simple-panel.txt b/Documentation/devicetree/bindings/panel/simple-panel.txt new file mode 100644 index 000000000000..1341bbf4aa3d --- /dev/null +++ b/Documentation/devicetree/bindings/panel/simple-panel.txt @@ -0,0 +1,21 @@ +Simple display panel + +Required properties: +- power-supply: regulator to provide the supply voltage + +Optional properties: +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing +- enable-gpios: GPIO pin to enable or disable the panel +- backlight: phandle of the backlight device attached to the panel + +Example: + + panel: panel { + compatible = "cptt,claa101wb01"; + ddc-i2c-bus = <&panelddc>; + + power-supply = <&vdd_pnl_reg>; + enable-gpios = <&gpio 90 0>; + + backlight = <&backlight>; + }; diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt new file mode 100644 index 000000000000..02331b904d4e --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt @@ -0,0 +1,33 @@ +Atmel PWM controller + +Required properties: + - compatible: should be one of: + - "atmel,at91sam9rl-pwm" + - "atmel,sama5d3-pwm" + - reg: physical base address and length of the controller's registers + - #pwm-cells: Should be 3. See pwm.txt in this directory for a + description of the cells format. + +Example: + + pwm0: pwm@f8034000 { + compatible = "atmel,at91sam9rl-pwm"; + reg = <0xf8034000 0x400>; + #pwm-cells = <3>; + }; + + pwmleds { + compatible = "pwm-leds"; + + d1 { + label = "d1"; + pwms = <&pwm0 3 5000 0> + max-brightness = <255>; + }; + + d2 { + label = "d2"; + pwms = <&pwm0 1 5000 1> + max-brightness = <255>; + }; + }; diff --git a/Documentation/devicetree/bindings/pwm/pxa-pwm.txt b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt new file mode 100644 index 000000000000..5ae9f1e3c338 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt @@ -0,0 +1,30 @@ +Marvell PWM controller + +Required properties: +- compatible: should be one or more of: + - "marvell,pxa250-pwm" + - "marvell,pxa270-pwm" + - "marvell,pxa168-pwm" + - "marvell,pxa910-pwm" +- reg: Physical base address and length of the registers used by the PWM channel + Note that one device instance must be created for each PWM that is used, so the + length covers only the register window for one PWM output, not that of the + entire PWM controller. Currently length is 0x10 for all supported devices. +- #pwm-cells: Should be 1. This cell is used to specify the period in + nanoseconds. + +Example PWM device node: + +pwm0: pwm@40b00000 { + compatible = "marvell,pxa250-pwm"; + reg = <0x40b00000 0x10>; + #pwm-cells = <1>; +}; + +Example PWM client node: + +backlight { + compatible = "pwm-backlight"; + pwms = <&pwm0 5000000>; + ... +} diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index e9e20ec67d62..19c84df5fffa 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -43,7 +43,7 @@ Example: sound { compatible = "simple-audio-card"; simple-audio-card,format = "left_j"; - simple-audio-routing = + simple-audio-card,routing = "MIC_IN", "Mic Jack", "Headphone Jack", "HP_OUT", "Ext Spk", "LINE_OUT"; diff --git a/Documentation/devicetree/bindings/video/ssd1289fb.txt b/Documentation/devicetree/bindings/video/ssd1289fb.txt new file mode 100644 index 000000000000..4fcd5e68cb6e --- /dev/null +++ b/Documentation/devicetree/bindings/video/ssd1289fb.txt @@ -0,0 +1,13 @@ +* Solomon SSD1289 Framebuffer Driver + +Required properties: + - compatible: Should be "solomon,ssd1289fb". The only supported bus for + now is lbc. + - reg: Should contain address of the controller on the LBC bus. The detail + was described in Documentation/devicetree/bindings/powerpc/fsl/lbc.txt + +Examples: +display@2,0 { + compatible = "solomon,ssd1289fb"; + reg = <0x2 0x0000 0x0004>; +}; diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt index fcdd48f7dcff..f90e294d7631 100644 --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt @@ -9,11 +9,37 @@ Required properties: Optional properties: - timeout-sec: contains the watchdog timeout in seconds. +- interrupts : Should contain WDT interrupt. +- atmel,max-heartbeat-sec : Should contain the maximum heartbeat value in + seconds. This value should be less or equal to 16. It is used to + compute the WDV field. +- atmel,min-heartbeat-sec : Should contain the minimum heartbeat value in + seconds. This value must be smaller than the max-heartbeat-sec value. + It is used to compute the WDD field. +- atmel,watchdog-type : Should be "hardware" or "software". Hardware watchdog + use the at91 watchdog reset. Software watchdog use the watchdog + interrupt to trigger a software reset. +- atmel,reset-type : Should be "proc" or "all". + "all" : assert peripherals and processor reset signals + "proc" : assert the processor reset signal + This is valid only when using "hardware" watchdog. +- atmel,disable : Should be present if you want to disable the watchdog. +- atmel,idle-halt : Should be present if you want to stop the watchdog when + entering idle state. +- atmel,dbg-halt : Should be present if you want to stop the watchdog when + entering debug state. Example: - watchdog@fffffd40 { compatible = "atmel,at91sam9260-wdt"; reg = <0xfffffd40 0x10>; - timeout-sec = <10>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; + timeout-sec = <15>; + atmel,watchdog-type = "hardware"; + atmel,reset-type = "all"; + atmel,dbg-halt; + atmel,idle-halt; + atmel,max-heartbeat-sec = <16>; + atmel,min-heartbeat-sec = <0>; + status = "okay"; }; diff --git a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt index 75558ccd9a05..e60b9a13bdcb 100644 --- a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt @@ -1,12 +1,24 @@ -DaVinci Watchdog Timer (WDT) Controller +Texas Instruments DaVinci/Keystone Watchdog Timer (WDT) Controller Required properties: -- compatible : Should be "ti,davinci-wdt" +- compatible : Should be "ti,davinci-wdt", "ti,keystone-wdt" - reg : Should contain WDT registers location and length +Optional properties: +- timeout-sec : Contains the watchdog timeout in seconds +- clocks : the clock feeding the watchdog timer. + Needed if platform uses clocks. + See clock-bindings.txt + +Documentation: +Davinci DM646x - http://www.ti.com/lit/ug/spruer5b/spruer5b.pdf +Keystone - http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf + Examples: wdt: wdt@2320000 { compatible = "ti,davinci-wdt"; reg = <0x02320000 0x80>; + timeout-sec = <30>; + clocks = <&clkwdtimer0>; }; diff --git a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt new file mode 100644 index 000000000000..37afec194949 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt @@ -0,0 +1,23 @@ +* GPIO-controlled Watchdog + +Required Properties: +- compatible: Should contain "linux,wdt-gpio". +- gpios: From common gpio binding; gpio connection to WDT reset pin. +- hw_algo: The algorithm used by the driver. Should be one of the + following values: + - toggle: Either a high-to-low or a low-to-high transition clears + the WDT counter. The watchdog timer is disabled when GPIO is + left floating or connected to a three-state buffer. + - level: Low or high level starts counting WDT timeout, + the opposite level disables the WDT. Active level is determined + by the GPIO flags. +- hw_margin_ms: Maximum time to reset watchdog circuit (milliseconds). + +Example: + watchdog: watchdog { + /* ADM706 */ + compatible = "linux,wdt-gpio"; + gpios = <&gpio3 9 GPIO_ACTIVE_LOW>; + hw_algo = "toggle"; + hw_margin_ms = <1600>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt index 2aa486cc1ff6..cfff37511aac 100644 --- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt @@ -5,10 +5,29 @@ after a preset amount of time during which the WDT reset event has not occurred. Required properties: -- compatible : should be "samsung,s3c2410-wdt" +- compatible : should be one among the following + (a) "samsung,s3c2410-wdt" for Exynos4 and previous SoCs + (b) "samsung,exynos5250-wdt" for Exynos5250 + (c) "samsung,exynos5420-wdt" for Exynos5420 + - reg : base physical address of the controller and length of memory mapped region. - interrupts : interrupt number to the cpu. +- samsung,syscon-phandle : reference to syscon node (This property required only + in case of compatible being "samsung,exynos5250-wdt" or "samsung,exynos5420-wdt". + In case of Exynos5250 and 5420 this property points to syscon node holding the PMU + base address) Optional properties: - timeout-sec : contains the watchdog timeout in seconds. + +Example: + +watchdog@101D0000 { + compatible = "samsung,exynos5250-wdt"; + reg = <0x101D0000 0x100>; + interrupts = <0 42 0>; + clocks = <&clock 336>; + clock-names = "watchdog"; + samsung,syscon-phandle = <&pmu_syscon>; +}; diff --git a/Documentation/dvb/contributors.txt b/Documentation/dvb/contributors.txt index 47c30098dab6..731a009723c7 100644 --- a/Documentation/dvb/contributors.txt +++ b/Documentation/dvb/contributors.txt @@ -78,7 +78,7 @@ Peter Beutner <p.beutner@gmx.net> Wilson Michaels <wilsonmichaels@earthlink.net> for the lgdt330x frontend driver, and various bugfixes -Michael Krufky <mkrufky@m1k.net> +Michael Krufky <mkrufky@linuxtv.org> for maintaining v4l/dvb inter-tree dependencies Taylor Jacob <rtjacob@earthlink.net> diff --git a/Documentation/fb/00-INDEX b/Documentation/fb/00-INDEX index 30a70542e823..fe85e7c5907a 100644 --- a/Documentation/fb/00-INDEX +++ b/Documentation/fb/00-INDEX @@ -5,6 +5,8 @@ please mail me. 00-INDEX - this file. +api.txt + - The frame buffer API between applications and buffer devices. arkfb.txt - info on the fbdev driver for ARK Logic chips. aty128fb.txt @@ -51,12 +53,16 @@ sh7760fb.txt - info on the SH7760/SH7763 integrated LCDC Framebuffer driver. sisfb.txt - info on the framebuffer device driver for various SiS chips. +sm501.txt + - info on the framebuffer device driver for sm501 videoframebuffer. sstfb.txt - info on the frame buffer driver for 3dfx' Voodoo Graphics boards. tgafb.txt - info on the TGA (DECChip 21030) frame buffer driver. tridentfb.txt info on the framebuffer driver for some Trident chip based cards. +udlfb.txt + - Driver for DisplayLink USB 2.0 chips. uvesafb.txt - info on the userspace VESA (VBE2+ compliant) frame buffer device. vesafb.txt diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 632211cbdd56..ac28149aede4 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -2,6 +2,8 @@ - this file (info on some of the filesystems supported by linux). Locking - info on locking rules as they pertain to Linux VFS. +Makefile + - Makefile for building the filsystems-part of DocBook. 9p.txt - 9p (v9fs) is an implementation of the Plan 9 remote fs protocol. adfs.txt diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt index 5dd282dda55c..d11cc2f8077b 100644 --- a/Documentation/filesystems/btrfs.txt +++ b/Documentation/filesystems/btrfs.txt @@ -38,7 +38,7 @@ Mount Options ============= When mounting a btrfs filesystem, the following option are accepted. -Unless otherwise specified, all options default to off. +Options with (*) are default options and will not show in the mount options. alloc_start=<bytes> Debugging option to force all block allocations above a certain @@ -46,10 +46,12 @@ Unless otherwise specified, all options default to off. bytes, optionally with a K, M, or G suffix, case insensitive. Default is 1MB. + noautodefrag(*) autodefrag - Detect small random writes into files and queue them up for the - defrag process. Works best for small files; Not well suited for - large database workloads. + Disable/enable auto defragmentation. + Auto defragmentation detects small random writes into files and queue + them up for the defrag process. Works best for small files; + Not well suited for large database workloads. check_int check_int_data @@ -96,21 +98,26 @@ Unless otherwise specified, all options default to off. can be avoided. Especially useful when trying to mount a multi-device setup as root. May be specified multiple times for multiple devices. + nodiscard(*) discard - Issue frequent commands to let the block device reclaim space freed by - the filesystem. This is useful for SSD devices, thinly provisioned + Disable/enable discard mount option. + Discard issues frequent commands to let the block device reclaim space + freed by the filesystem. + This is useful for SSD devices, thinly provisioned LUNs and virtual machine images, but may have a significant performance impact. (The fstrim command is also available to initiate batch trims from userspace). + noenospc_debug(*) enospc_debug - Debugging option to be more verbose in some ENOSPC conditions. + Disable/enable debugging option to be more verbose in some ENOSPC conditions. fatal_errors=<action> Action to take when encountering a fatal error: "bug" - BUG() on a fatal error. This is the default. "panic" - panic() on a fatal error. + noflushoncommit(*) flushoncommit The 'flushoncommit' mount option forces any data dirtied by a write in a prior transaction to commit as part of the current commit. This makes @@ -134,26 +141,32 @@ Unless otherwise specified, all options default to off. Specify that 1 metadata chunk should be allocated after every <value> data chunks. Off by default. + acl(*) noacl - Disable support for Posix Access Control Lists (ACLs). See the + Enable/disable support for Posix Access Control Lists (ACLs). See the acl(5) manual page for more information about ACLs. + barrier(*) nobarrier - Disables the use of block layer write barriers. Write barriers ensure - that certain IOs make it through the device cache and are on persistent - storage. If used on a device with a volatile (non-battery-backed) - write-back cache, this option will lead to filesystem corruption on a - system crash or power loss. + Enable/disable the use of block layer write barriers. Write barriers + ensure that certain IOs make it through the device cache and are on + persistent storage. If disabled on a device with a volatile + (non-battery-backed) write-back cache, nobarrier option will lead to + filesystem corruption on a system crash or power loss. + datacow(*) nodatacow - Disable data copy-on-write for newly created files. Implies nodatasum, - and disables all compression. + Enable/disable data copy-on-write for newly created files. + Nodatacow implies nodatasum, and disables all compression. + datasum(*) nodatasum - Disable data checksumming for newly created files. + Enable/disable data checksumming for newly created files. + Datasum implies datacow. + treelog(*) notreelog - Disable the tree logging used for fsync and O_SYNC writes. + Enable/disable the tree logging used for fsync and O_SYNC writes. recovery Enable autorecovery attempts if a bad tree root is found at mount time. diff --git a/Documentation/filesystems/nfs/00-INDEX b/Documentation/filesystems/nfs/00-INDEX index 66eb6c8c5334..53f3b596ac0d 100644 --- a/Documentation/filesystems/nfs/00-INDEX +++ b/Documentation/filesystems/nfs/00-INDEX @@ -12,6 +12,8 @@ nfs41-server.txt - info on the Linux server implementation of NFSv4 minor version 1. nfs-rdma.txt - how to install and setup the Linux NFS/RDMA client and server software +nfsd-admin-interfaces.txt + - Administrative interfaces for nfsd. nfsroot.txt - short guide on setting up a diskless box with NFS root filesystem. pnfs.txt @@ -20,5 +22,5 @@ rpc-cache.txt - introduction to the caching mechanisms in the sunrpc layer. idmapper.txt - information for configuring request-keys to be used by idmapper -knfsd-rpcgss.txt +rpc-server-gss.txt - Information on GSS authentication support in the NFS Server diff --git a/Documentation/filesystems/nfs/nfs41-server.txt b/Documentation/filesystems/nfs/nfs41-server.txt index 01c2db769791..b930ad087780 100644 --- a/Documentation/filesystems/nfs/nfs41-server.txt +++ b/Documentation/filesystems/nfs/nfs41-server.txt @@ -5,11 +5,11 @@ Server support for minorversion 1 can be controlled using the by reading this file will contain either "+4.1" or "-4.1" correspondingly. -Currently, server support for minorversion 1 is disabled by default. -It can be enabled at run time by writing the string "+4.1" to +Currently, server support for minorversion 1 is enabled by default. +It can be disabled at run time by writing the string "-4.1" to the /proc/fs/nfsd/versions control file. Note that to write this -control file, the nfsd service must be taken down. Use your user-mode -nfs-utils to set this up; see rpc.nfsd(8) +control file, the nfsd service must be taken down. You can use rpc.nfsd +for this; see rpc.nfsd(8). (Warning: older servers will interpret "+4.1" and "-4.1" as "+4" and "-4", respectively. Therefore, code meant to work on both new and old @@ -29,29 +29,6 @@ are still under development out of tree. See http://wiki.linux-nfs.org/wiki/index.php/PNFS_prototype_design for more information. -The current implementation is intended for developers only: while it -does support ordinary file operations on clients we have tested against -(including the linux client), it is incomplete in ways which may limit -features unexpectedly, cause known bugs in rare cases, or cause -interoperability problems with future clients. Known issues: - - - gss support is questionable: currently mounts with kerberos - from a linux client are possible, but we aren't really - conformant with the spec (for example, we don't use kerberos - on the backchannel correctly). - - We do not support SSV, which provides security for shared - client-server state (thus preventing unauthorized tampering - with locks and opens, for example). It is mandatory for - servers to support this, though no clients use it yet. - -In addition, some limitations are inherited from the current NFSv4 -implementation: - - - Incomplete delegation enforcement: if a file is renamed or - unlinked by a local process, a client holding a delegation may - continue to indefinitely allow opens of the file under the old - name. - The table below, taken from the NFSv4.1 document, lists the operations that are mandatory to implement (REQ), optional (OPT), and NFSv4.0 operations that are required not to implement (MNI) @@ -169,6 +146,16 @@ NS*| CB_WANTS_CANCELLED | OPT | FDELG, | Section 20.10 | Implementation notes: +SSV: +* The spec claims this is mandatory, but we don't actually know of any + implementations, so we're ignoring it for now. The server returns + NFS4ERR_ENCR_ALG_UNSUPP on EXCHANGE_ID, which should be future-proof. + +GSS on the backchannel: +* Again, theoretically required but not widely implemented (in + particular, the current Linux client doesn't request it). We return + NFS4ERR_ENCR_ALG_UNSUPP on CREATE_SESSION. + DELEGPURGE: * mandatory only for servers that support CLAIM_DELEGATE_PREV and/or CLAIM_DELEG_PREV_FH (which allows clients to keep delegations that @@ -176,7 +163,6 @@ DELEGPURGE: now. EXCHANGE_ID: -* only SP4_NONE state protection supported * implementation ids are ignored CREATE_SESSION: diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 31f76178c987..f00bee144add 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1386,8 +1386,8 @@ may allocate from based on an estimation of its current memory and swap use. For example, if a task is using all allowed memory, its badness score will be 1000. If it is using half of its allowed memory, its score will be 500. -There is an additional factor included in the badness score: root -processes are given 3% extra memory over other tasks. +There is an additional factor included in the badness score: the current memory +and swap usage is discounted by 3% for root processes. The amount of "allowed" memory depends on the context in which the oom killer was called. If it is due to the memory assigned to the allocating task's cpuset diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index deb48b5fd883..c53784c119c8 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -782,7 +782,7 @@ struct file_operations ---------------------- This describes how the VFS can manipulate an open file. As of kernel -3.5, the following members are defined: +3.12, the following members are defined: struct file_operations { struct module *owner; @@ -803,9 +803,6 @@ struct file_operations { int (*aio_fsync) (struct kiocb *, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); - ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *); - ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *); - ssize_t (*sendfile) (struct file *, loff_t *, size_t, read_actor_t, void *); ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int); unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); int (*check_flags)(int); @@ -814,6 +811,7 @@ struct file_operations { ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int); int (*setlease)(struct file *, long arg, struct file_lock **); long (*fallocate)(struct file *, int mode, loff_t offset, loff_t len); + int (*show_fdinfo)(struct seq_file *m, struct file *f); }; Again, all methods are called without any locks being held, unless @@ -864,12 +862,6 @@ otherwise noted. lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW commands - readv: called by the readv(2) system call - - writev: called by the writev(2) system call - - sendfile: called by the sendfile(2) system call - get_unmapped_area: called by the mmap(2) system call check_flags: called by the fcntl(2) system call for F_SETFL command diff --git a/Documentation/hwmon/adm1025 b/Documentation/hwmon/adm1025 index 39d2b781b5d6..99f05049c68a 100644 --- a/Documentation/hwmon/adm1025 +++ b/Documentation/hwmon/adm1025 @@ -18,7 +18,7 @@ The NE1619 presents some differences with the original ADM1025: Authors: Chen-Yuan Wu <gwu@esoft.com>, - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Description ----------- diff --git a/Documentation/hwmon/adm1031 b/Documentation/hwmon/adm1031 index be92a77da1d5..a143117c99cb 100644 --- a/Documentation/hwmon/adm1031 +++ b/Documentation/hwmon/adm1031 @@ -16,7 +16,7 @@ Supported chips: Authors: Alexandre d'Alton <alex@alexdalton.org> - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Description ----------- diff --git a/Documentation/hwmon/adm9240 b/Documentation/hwmon/adm9240 index 36e8ec6aa868..9b174fc700cc 100644 --- a/Documentation/hwmon/adm9240 +++ b/Documentation/hwmon/adm9240 @@ -25,7 +25,7 @@ Authors: Philip Edelbrock <phil@netroedge.com>, Michiel Rook <michiel@grendelproject.nl>, Grant Coady <gcoady.lk@gmail.com> with guidance - from Jean Delvare <khali@linux-fr.org> + from Jean Delvare <jdelvare@suse.de> Interface --------- diff --git a/Documentation/hwmon/ds1621 b/Documentation/hwmon/ds1621 index 896cdc972ca8..f775e612f582 100644 --- a/Documentation/hwmon/ds1621 +++ b/Documentation/hwmon/ds1621 @@ -31,7 +31,7 @@ Authors: Christian W. Zuckschwerdt <zany@triq.net> valuable contributions by Jan M. Sendler <sendler@sendler.de> ported to 2.6 by Aurelien Jarno <aurelien@aurel32.net> - with the help of Jean Delvare <khali@linux-fr.org> + with the help of Jean Delvare <jdelvare@suse.de> Module Parameters ------------------ diff --git a/Documentation/hwmon/emc6w201 b/Documentation/hwmon/emc6w201 index 32f355aaf56b..757629b12897 100644 --- a/Documentation/hwmon/emc6w201 +++ b/Documentation/hwmon/emc6w201 @@ -7,7 +7,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2d, 0x2e Datasheet: Not public -Author: Jean Delvare <khali@linux-fr.org> +Author: Jean Delvare <jdelvare@suse.de> Description diff --git a/Documentation/hwmon/f71805f b/Documentation/hwmon/f71805f index f0d55976740a..48a356084bc6 100644 --- a/Documentation/hwmon/f71805f +++ b/Documentation/hwmon/f71805f @@ -15,7 +15,7 @@ Supported chips: Addresses scanned: none, address read from Super I/O config space Datasheet: Available from the Fintek website -Author: Jean Delvare <khali@linux-fr.org> +Author: Jean Delvare <jdelvare@suse.de> Thanks to Denis Kieft from Barracuda Networks for the donation of a test system (custom Jetway K8M8MS motherboard, with CPU and RAM) and diff --git a/Documentation/hwmon/gl518sm b/Documentation/hwmon/gl518sm index 26f9f3c02dc7..494bb55b6e72 100644 --- a/Documentation/hwmon/gl518sm +++ b/Documentation/hwmon/gl518sm @@ -14,7 +14,7 @@ Authors: Frodo Looijaard <frodol@dds.nl>, Kyösti Mälkki <kmalkki@cc.hut.fi> Hong-Gunn Chew <hglinux@gunnet.org> - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Description ----------- diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index c263740f0cba..0c1635082c99 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -2,6 +2,10 @@ Kernel driver it87 ================== Supported chips: + * IT8603E + Prefix: 'it8603' + Addresses scanned: from Super I/O config space (8 I/O ports) + Datasheet: Not publicly available * IT8705F Prefix: 'it87' Addresses scanned: from Super I/O config space (8 I/O ports) @@ -53,7 +57,7 @@ Supported chips: Authors: Christophe Gauthron - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Module Parameters @@ -90,7 +94,7 @@ motherboard models. Description ----------- -This driver implements support for the IT8705F, IT8712F, IT8716F, +This driver implements support for the IT8603E, IT8705F, IT8712F, IT8716F, IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, IT8772E, IT8782F, IT8783E/F, and SiS950 chips. @@ -129,6 +133,10 @@ to userspace applications. The IT8728F, IT8771E, and IT8772E are considered compatible with the IT8721F, until a datasheet becomes available (hopefully.) +The IT8603E is a custom design, hardware monitoring part is similar to +IT8728F. It only supports 16-bit fan mode, the full speed mode of the +fan is not supported (value 0 of pwmX_enable). + Temperatures are measured in degrees Celsius. An alarm is triggered once when the Overtemperature Shutdown limit is crossed. @@ -145,13 +153,16 @@ alarm is triggered if the voltage has crossed a programmable minimum or maximum limit. Note that minimum in this case always means 'closest to zero'; this is important for negative voltage measurements. All voltage inputs can measure voltages between 0 and 4.08 volts, with a resolution of -0.016 volt (except IT8721F/IT8758E and IT8728F: 0.012 volt.) The battery -voltage in8 does not have limit registers. - -On the IT8721F/IT8758E, IT8782F, and IT8783E/F, some voltage inputs are -internal and scaled inside the chip (in7 (optional for IT8782F and IT8783E/F), -in8 and optionally in3). The driver handles this transparently so user-space -doesn't have to care. +0.016 volt (except IT8603E, IT8721F/IT8758E and IT8728F: 0.012 volt.) The +battery voltage in8 does not have limit registers. + +On the IT8603E, IT8721F/IT8758E, IT8782F, and IT8783E/F, some voltage inputs +are internal and scaled inside the chip: +* in3 (optional) +* in7 (optional for IT8782F and IT8783E/F) +* in8 (always) +* in9 (relevant for IT8603E only) +The driver handles this transparently so user-space doesn't have to care. The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value: the voltage level your processor should work with. This is hardcoded by diff --git a/Documentation/hwmon/lm63 b/Documentation/hwmon/lm63 index 4d30d209881a..4a00461512a6 100644 --- a/Documentation/hwmon/lm63 +++ b/Documentation/hwmon/lm63 @@ -18,7 +18,7 @@ Supported chips: Datasheet: Publicly available at the National Semiconductor website http://www.national.com/pf/LM/LM96163.html -Author: Jean Delvare <khali@linux-fr.org> +Author: Jean Delvare <jdelvare@suse.de> Thanks go to Tyan and especially Alex Buckingham for setting up a remote access to their S4882 test platform for this driver. diff --git a/Documentation/hwmon/lm70 b/Documentation/hwmon/lm70 index 86d182942c51..1bb2db440671 100644 --- a/Documentation/hwmon/lm70 +++ b/Documentation/hwmon/lm70 @@ -43,5 +43,5 @@ data (0.03125 degrees celsius resolution). Thanks to --------- -Jean Delvare <khali@linux-fr.org> for mentoring the hwmon-side driver +Jean Delvare <jdelvare@suse.de> for mentoring the hwmon-side driver development. diff --git a/Documentation/hwmon/lm78 b/Documentation/hwmon/lm78 index 2bdc881a0c12..4dd47731789f 100644 --- a/Documentation/hwmon/lm78 +++ b/Documentation/hwmon/lm78 @@ -14,7 +14,7 @@ Supported chips: http://www.national.com/ Authors: Frodo Looijaard <frodol@dds.nl> - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Description ----------- diff --git a/Documentation/hwmon/lm83 b/Documentation/hwmon/lm83 index a04d1fe9269c..50be5cb26de9 100644 --- a/Documentation/hwmon/lm83 +++ b/Documentation/hwmon/lm83 @@ -13,7 +13,7 @@ Supported chips: http://www.national.com/pf/LM/LM82.html -Author: Jean Delvare <khali@linux-fr.org> +Author: Jean Delvare <jdelvare@suse.de> Description ----------- diff --git a/Documentation/hwmon/lm87 b/Documentation/hwmon/lm87 index 6b47b67fd968..a2339fd9acb9 100644 --- a/Documentation/hwmon/lm87 +++ b/Documentation/hwmon/lm87 @@ -17,7 +17,7 @@ Authors: Mark Studebaker <mdsxyz123@yahoo.com>, Stephen Rousset <stephen.rousset@rocketlogix.com>, Dan Eaton <dan.eaton@rocketlogix.com>, - Jean Delvare <khali@linux-fr.org>, + Jean Delvare <jdelvare@suse.de>, Original 2.6 port Jeff Oliver Description diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90 index ab81013cc390..8122675d30f6 100644 --- a/Documentation/hwmon/lm90 +++ b/Documentation/hwmon/lm90 @@ -129,7 +129,7 @@ Supported chips: http://www.ti.com/litv/pdf/sbos686 -Author: Jean Delvare <khali@linux-fr.org> +Author: Jean Delvare <jdelvare@suse.de> Description diff --git a/Documentation/hwmon/lm92 b/Documentation/hwmon/lm92 index 7705bfaa0708..22f68ad032cf 100644 --- a/Documentation/hwmon/lm92 +++ b/Documentation/hwmon/lm92 @@ -19,7 +19,7 @@ Supported chips: Authors: Abraham van der Merwe <abraham@2d3d.co.za> - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Description diff --git a/Documentation/hwmon/max1619 b/Documentation/hwmon/max1619 index e6d87398cc8f..518bae3a80c4 100644 --- a/Documentation/hwmon/max1619 +++ b/Documentation/hwmon/max1619 @@ -10,7 +10,7 @@ Supported chips: Authors: Oleksij Rempel <bug-track@fisher-privat.net>, - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Description ----------- diff --git a/Documentation/hwmon/pc87360 b/Documentation/hwmon/pc87360 index cbac32b59c8c..d5f5cf16ce59 100644 --- a/Documentation/hwmon/pc87360 +++ b/Documentation/hwmon/pc87360 @@ -7,7 +7,7 @@ Supported chips: Addresses scanned: none, address read from Super I/O config space Datasheets: No longer available -Authors: Jean Delvare <khali@linux-fr.org> +Authors: Jean Delvare <jdelvare@suse.de> Thanks to Sandeep Mehta, Tonko de Rooy and Daniel Ceregatti for testing. Thanks to Rudolf Marek for helping me investigate conversion issues. diff --git a/Documentation/hwmon/pc87427 b/Documentation/hwmon/pc87427 index 8fdd08c9e48b..c313eb66e08a 100644 --- a/Documentation/hwmon/pc87427 +++ b/Documentation/hwmon/pc87427 @@ -7,7 +7,7 @@ Supported chips: Addresses scanned: none, address read from Super I/O config space Datasheet: No longer available -Author: Jean Delvare <khali@linux-fr.org> +Author: Jean Delvare <jdelvare@suse.de> Thanks to Amir Habibi at Candelis for setting up a test system, and to Michael Kress for testing several iterations of this driver. diff --git a/Documentation/hwmon/pcf8591 b/Documentation/hwmon/pcf8591 index ac020b3bb7b3..447c0702c0ec 100644 --- a/Documentation/hwmon/pcf8591 +++ b/Documentation/hwmon/pcf8591 @@ -11,7 +11,7 @@ Supported chips: Authors: Aurelien Jarno <aurelien@aurel32.net> valuable contributions by Jan M. Sendler <sendler@sendler.de>, - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Description diff --git a/Documentation/hwmon/smsc47m1 b/Documentation/hwmon/smsc47m1 index 2a13378dcf22..10a24b420686 100644 --- a/Documentation/hwmon/smsc47m1 +++ b/Documentation/hwmon/smsc47m1 @@ -25,7 +25,7 @@ Authors: With assistance from Bruce Allen <ballen@uwm.edu>, and his fan.c program: http://www.lsc-group.phys.uwm.edu/%7Eballen/driver/ Gabriele Gorla <gorlik@yahoo.com>, - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Description ----------- diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf index ceaf6f652b00..735c42a85ead 100644 --- a/Documentation/hwmon/w83627ehf +++ b/Documentation/hwmon/w83627ehf @@ -36,7 +36,7 @@ Supported chips: Datasheet: Available from Nuvoton upon request Authors: - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Yuan Mu (Winbond) Rudolf Marek <r.marek@assembler.cz> David Hubbard <david.c.hubbard@gmail.com> diff --git a/Documentation/hwmon/w83795 b/Documentation/hwmon/w83795 index 9f160371f463..d3e678216b9a 100644 --- a/Documentation/hwmon/w83795 +++ b/Documentation/hwmon/w83795 @@ -13,7 +13,7 @@ Supported chips: Authors: Wei Song (Nuvoton) - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Pin mapping diff --git a/Documentation/hwmon/w83l785ts b/Documentation/hwmon/w83l785ts index bd1fa9d4468d..c8978478871f 100644 --- a/Documentation/hwmon/w83l785ts +++ b/Documentation/hwmon/w83l785ts @@ -9,7 +9,7 @@ Supported chips: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83L785TS-S.pdf Authors: - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Description ----------- diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 7b0dcdb57173..aaaf069306a3 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -33,7 +33,7 @@ and the additional 'Integrated Device Function' controllers are supported. Authors: Mark Studebaker <mdsxyz123@yahoo.com> - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Module Parameters diff --git a/Documentation/i2c/busses/i2c-parport b/Documentation/i2c/busses/i2c-parport index 2461c7b53b2c..0e2d17b460fd 100644 --- a/Documentation/i2c/busses/i2c-parport +++ b/Documentation/i2c/busses/i2c-parport @@ -1,6 +1,6 @@ Kernel driver i2c-parport -Author: Jean Delvare <khali@linux-fr.org> +Author: Jean Delvare <jdelvare@suse.de> This is a unified driver for several i2c-over-parallel-port adapters, such as the ones made by Philips, Velleman or ELV. This driver is diff --git a/Documentation/i2c/busses/i2c-parport-light b/Documentation/i2c/busses/i2c-parport-light index c22ee063e1e5..7071b8ba0af4 100644 --- a/Documentation/i2c/busses/i2c-parport-light +++ b/Documentation/i2c/busses/i2c-parport-light @@ -1,6 +1,6 @@ Kernel driver i2c-parport-light -Author: Jean Delvare <khali@linux-fr.org> +Author: Jean Delvare <jdelvare@suse.de> This driver is a light version of i2c-parport. It doesn't depend on the parport driver, and uses direct I/O access instead. This might be diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index c097e0f020fe..aa959fd22450 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 @@ -13,7 +13,7 @@ Supported adapters: * AMD SP5100 (SB700 derivative found on some server mainboards) Datasheet: Publicly available at the AMD website http://support.amd.com/us/Embedded_TechDocs/44413.pdf - * AMD Hudson-2, CZ + * AMD Hudson-2, ML, CZ Datasheet: Not publicly available * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge Datasheet: Publicly available at the SMSC website http://www.smsc.com diff --git a/Documentation/i2c/busses/i2c-taos-evm b/Documentation/i2c/busses/i2c-taos-evm index 63f62bcbf592..60299555dcf0 100644 --- a/Documentation/i2c/busses/i2c-taos-evm +++ b/Documentation/i2c/busses/i2c-taos-evm @@ -1,6 +1,6 @@ Kernel driver i2c-taos-evm -Author: Jean Delvare <khali@linux-fr.org> +Author: Jean Delvare <jdelvare@suse.de> This is a driver for the evaluation modules for TAOS I2C/SMBus chips. The modules include an SMBus master with limited capabilities, which can diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro index b88f91ae580e..ab64ce21c254 100644 --- a/Documentation/i2c/busses/i2c-viapro +++ b/Documentation/i2c/busses/i2c-viapro @@ -28,7 +28,7 @@ Supported adapters: Authors: Kyösti Mälkki <kmalkki@cc.hut.fi>, Mark D. Studebaker <mdsxyz123@yahoo.com>, - Jean Delvare <khali@linux-fr.org> + Jean Delvare <jdelvare@suse.de> Module Parameters ----------------- diff --git a/Documentation/ide/00-INDEX b/Documentation/ide/00-INDEX index d6b778842b75..22f98ca79539 100644 --- a/Documentation/ide/00-INDEX +++ b/Documentation/ide/00-INDEX @@ -10,3 +10,5 @@ ide-tape.txt - info on the IDE ATAPI streaming tape driver ide.txt - important info for users of ATA devices (IDE/EIDE disks and CD-ROMS). +warm-plug-howto.txt + - using sysfs to remove and add IDE devices.
\ No newline at end of file diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 7cbfa3c4fc3d..d7e43fa88575 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -73,6 +73,7 @@ Code Seq#(hex) Include File Comments 0x09 all linux/raid/md_u.h 0x10 00-0F drivers/char/s390/vmcp.h 0x10 10-1F arch/s390/include/uapi/sclp_ctl.h +0x10 20-2F arch/s390/include/uapi/asm/hypfs.h 0x12 all linux/fs.h linux/blkpg.h 0x1b all InfiniBand Subsystem <http://infiniband.sourceforge.net/> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index be6ba33d4ff1..7116fda7077f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1726,16 +1726,16 @@ bytes respectively. Such letter suffixes can also be entirely omitted. option description. memmap=nn[KMG]@ss[KMG] - [KNL] Force usage of a specific region of memory - Region of memory to be used, from ss to ss+nn. + [KNL] Force usage of a specific region of memory. + Region of memory to be used is from ss to ss+nn. memmap=nn[KMG]#ss[KMG] [KNL,ACPI] Mark specific memory as ACPI data. - Region of memory to be used, from ss to ss+nn. + Region of memory to be marked is from ss to ss+nn. memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. - Region of memory to be used, from ss to ss+nn. + Region of memory to be reserved is from ss to ss+nn. Example: Exclude memory from 0x18690000-0x1869ffff memmap=64K$0x18690000 or @@ -3124,7 +3124,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. controller if no parameter or 1 is given or disable it if 0 is given (See Documentation/cgroups/memory.txt) - swiotlb= [IA-64] Number of I/O TLB slabs + swiotlb= [ARM,IA-64,PPC,MIPS,X86] + Format: { <int> | force } + <int> -- Number of I/O TLB slabs + force -- force using of bounce buffers even if they + wouldn't be automatically used by the kernel switches= [HW,M68k] diff --git a/Documentation/kmsg/s390/zcrypt b/Documentation/kmsg/s390/zcrypt deleted file mode 100644 index 7fb2087409d6..000000000000 --- a/Documentation/kmsg/s390/zcrypt +++ /dev/null @@ -1,20 +0,0 @@ -/*? - * Text: "Cryptographic device %x failed and was set offline\n" - * Severity: Error - * Parameter: - * @1: device index - * Description: - * A cryptographic device failed to process a cryptographic request. - * The cryptographic device driver could not correct the error and - * set the device offline. The application that issued the - * request received an indication that the request has failed. - * User action: - * Use the lszcrypt command to confirm that the cryptographic - * hardware is still configured to your LPAR or z/VM guest virtual - * machine. If the device is available to your Linux instance the - * command output contains a line that begins with 'card<device index>', - * where <device index> is the two-digit decimal number in the message text. - * After ensuring that the device is available, use the chzcrypt command to - * set it online again. - * If the error persists, contact your support organization. - */ diff --git a/Documentation/laptops/00-INDEX b/Documentation/laptops/00-INDEX index fa688538e757..d13b9a9a9e00 100644 --- a/Documentation/laptops/00-INDEX +++ b/Documentation/laptops/00-INDEX @@ -1,13 +1,15 @@ 00-INDEX - This file -acer-wmi.txt - - information on the Acer Laptop WMI Extras driver. +Makefile + - Makefile for building dslm example program. asus-laptop.txt - information on the Asus Laptop Extras driver. disk-shock-protection.txt - information on hard disk shock protection. dslm.c - Simple Disk Sleep Monitor program +hpfall.c + - (HP) laptop accelerometer program for disk protection. laptop-mode.txt - how to conserve battery power using laptop-mode. sony-laptop.txt diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX index 1ecd1596633e..b4ef1f34e25f 100644 --- a/Documentation/leds/00-INDEX +++ b/Documentation/leds/00-INDEX @@ -1,3 +1,7 @@ +00-INDEX + - This file +leds-blinkm.txt + - Driver for BlinkM LED-devices. leds-class.txt - documents LED handling under Linux. leds-lp3944.txt @@ -12,3 +16,7 @@ leds-lp55xx.txt - description about lp55xx common driver. leds-lm3556.txt - notes on how to use the leds-lm3556 driver. +ledtrig-oneshot.txt + - One-shot LED trigger for both sporadic and dense events. +ledtrig-transient.txt + - LED Transient Trigger, one shot timer activation. diff --git a/Documentation/leds/leds-lp55xx.txt b/Documentation/leds/leds-lp55xx.txt index 82713ff92eb3..bcea12a0c584 100644 --- a/Documentation/leds/leds-lp55xx.txt +++ b/Documentation/leds/leds-lp55xx.txt @@ -73,6 +73,10 @@ select_engine : Select which engine is used for running program run_engine : Start program which is loaded via the firmware interface firmware : Load program data +In case of LP5523, one more command is required, 'enginex_leds'. +It is used for selecting LED output(s) at each engine number. +In more details, please refer to 'leds-lp5523.txt'. + For example, run blinking pattern in engine #1 of LP5521 echo 1 > /sys/bus/i2c/devices/xxxx/select_engine echo 1 > /sys/class/firmware/lp5521/loading @@ -81,10 +85,12 @@ echo 0 > /sys/class/firmware/lp5521/loading echo 1 > /sys/bus/i2c/devices/xxxx/run_engine For example, run blinking pattern in engine #3 of LP55231 +Two LEDs are configured as pattern output channels. echo 3 > /sys/bus/i2c/devices/xxxx/select_engine echo 1 > /sys/class/firmware/lp55231/loading echo "9d0740ff7e0040007e00a0010000" > /sys/class/firmware/lp55231/data echo 0 > /sys/class/firmware/lp55231/loading +echo "000001100" > /sys/bus/i2c/devices/xxxx/engine3_leds echo 1 > /sys/bus/i2c/devices/xxxx/run_engine To start blinking patterns in engine #2 and #3 simultaneously, @@ -99,17 +105,19 @@ done echo 1 > /sys/class/leds/red/device/run_engine Here is another example for LP5523. +Full LED strings are selected by 'engine2_leds'. echo 2 > /sys/bus/i2c/devices/xxxx/select_engine echo 1 > /sys/class/firmware/lp5523/loading echo "9d80400004ff05ff437f0000" > /sys/class/firmware/lp5523/data echo 0 > /sys/class/firmware/lp5523/loading +echo "111111111" > /sys/bus/i2c/devices/xxxx/engine2_leds echo 1 > /sys/bus/i2c/devices/xxxx/run_engine As soon as 'loading' is set to 0, registered callback is called. Inside the callback, the selected engine is loaded and memory is updated. To run programmed pattern, 'run_engine' attribute should be enabled. -The pattern sqeuence of LP8501 is same as LP5523. +The pattern sqeuence of LP8501 is similar to LP5523. However pattern data is specific. Ex 1) Engine 1 is used echo 1 > /sys/bus/i2c/devices/xxxx/select_engine diff --git a/Documentation/m68k/00-INDEX b/Documentation/m68k/00-INDEX index a014e9f00765..2be8c6b00e74 100644 --- a/Documentation/m68k/00-INDEX +++ b/Documentation/m68k/00-INDEX @@ -1,5 +1,7 @@ 00-INDEX - this file +README.buddha + - Amiga Buddha and Catweasel IDE Driver kernel-options.txt - command line options for Linux/m68k diff --git a/Documentation/misc-devices/eeprom b/Documentation/misc-devices/eeprom index f7e8104b5764..ba692011f221 100644 --- a/Documentation/misc-devices/eeprom +++ b/Documentation/misc-devices/eeprom @@ -38,7 +38,7 @@ Supported chips: Authors: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock <phil@netroedge.com>, - Jean Delvare <khali@linux-fr.org>, + Jean Delvare <jdelvare@suse.de>, Greg Kroah-Hartman <greg@kroah.com>, IBM Corp. diff --git a/Documentation/mtd/nand/pxa3xx-nand.txt b/Documentation/mtd/nand/pxa3xx-nand.txt new file mode 100644 index 000000000000..840fd41c181b --- /dev/null +++ b/Documentation/mtd/nand/pxa3xx-nand.txt @@ -0,0 +1,113 @@ + +About this document +=================== + +Some notes about Marvell's NAND controller available in PXA and Armada 370/XP +SoC (aka NFCv1 and NFCv2), with an emphasis on the latter. + +NFCv2 controller background +=========================== + +The controller has a 2176 bytes FIFO buffer. Therefore, in order to support +larger pages, I/O operations on 4 KiB and 8 KiB pages is done with a set of +chunked transfers. + +For instance, if we choose a 2048 data chunk and set "BCH" ECC (see below) +we'll have this layout in the pages: + + ------------------------------------------------------------------------------ + | 2048B data | 32B spare | 30B ECC || 2048B data | 32B spare | 30B ECC | ... | + ------------------------------------------------------------------------------ + +The driver reads the data and spare portions independently and builds an internal +buffer with this layout (in the 4 KiB page case): + + ------------------------------------------ + | 4096B data | 64B spare | + ------------------------------------------ + +Also, for the READOOB command the driver disables the ECC and reads a 'spare + ECC' +OOB, one per chunk read. + + ------------------------------------------------------------------- + | 4096B data | 32B spare | 30B ECC | 32B spare | 30B ECC | + ------------------------------------------------------------------- + +So, in order to achieve reading (for instance), we issue several READ0 commands +(with some additional controller-specific magic) and read two chunks of 2080B +(2048 data + 32 spare) each. +The driver accommodates this data to expose the NAND core a contiguous buffer +(4096 data + spare) or (4096 + spare + ECC + spare + ECC). + +ECC +=== + +The controller has built-in hardware ECC capabilities. In addition it is +configurable between two modes: 1) Hamming, 2) BCH. + +Note that the actual BCH mode: BCH-4 or BCH-8 will depend on the way +the controller is configured to transfer the data. + +In the BCH mode the ECC code will be calculated for each transfered chunk +and expected to be located (when reading/programming) right after the spare +bytes as the figure above shows. + +So, repeating the above scheme, a 2048B data chunk will be followed by 32B +spare, and then the ECC controller will read/write the ECC code (30B in +this case): + + ------------------------------------ + | 2048B data | 32B spare | 30B ECC | + ------------------------------------ + +If the ECC mode is 'BCH' then the ECC is *always* 30 bytes long. +If the ECC mode is 'Hamming' the ECC is 6 bytes long, for each 512B block. +So in Hamming mode, a 2048B page will have a 24B ECC. + +Despite all of the above, the controller requires the driver to only read or +write in multiples of 8-bytes, because the data buffer is 64-bits. + +OOB +=== + +Because of the above scheme, and because the "spare" OOB is really located in +the middle of a page, spare OOB cannot be read or write independently of the +data area. In other words, in order to read the OOB (aka READOOB), the entire +page (aka READ0) has to be read. + +In the same sense, in order to write to the spare OOB the driver has to write +an *entire* page. + +Factory bad blocks handling +=========================== + +Given the ECC BCH requires to layout the device's pages in a split +data/OOB/data/OOB way, the controller has a view of the flash page that's +different from the specified (aka the manufacturer's) view. In other words, + +Factory view: + + ----------------------------------------------- + | Data |x OOB | + ----------------------------------------------- + +Driver's view: + + ----------------------------------------------- + | Data | OOB | Data x | OOB | + ----------------------------------------------- + +It can be seen from the above, that the factory bad block marker must be +searched within the 'data' region, and not in the usual OOB region. + +In addition, this means under regular usage the driver will write such +position (since it belongs to the data region) and every used block is +likely to be marked as bad. + +For this reason, marking the block as bad in the OOB is explicitly +disabled by using the NAND_BBT_NO_OOB_BBM option in the driver. The rationale +for this is that there's no point in marking a block as bad, because good +blocks are also 'marked as bad' (in the OOB BBM sense) under normal usage. + +Instead, the driver relies on the bad block table alone, and should only perform +the bad block scan on the very first time (when the device hasn't been used). diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index f11580f8719a..557b6ef70c26 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -6,8 +6,14 @@ - information on the 3Com Etherlink III Series Ethernet cards. 6pack.txt - info on the 6pack protocol, an alternative to KISS for AX.25 -DLINK.txt - - info on the D-Link DE-600/DE-620 parallel port pocket adapters +LICENSE.qla3xxx + - GPLv2 for QLogic Linux Networking HBA Driver +LICENSE.qlge + - GPLv2 for QLogic Linux qlge NIC Driver +LICENSE.qlcnic + - GPLv2 for QLogic Linux qlcnic NIC Driver +Makefile + - Makefile for docsrc. PLIP.txt - PLIP: The Parallel Line Internet Protocol device driver README.ipw2100 @@ -17,7 +23,7 @@ README.ipw2200 README.sb1000 - info on General Instrument/NextLevel SURFboard1000 cable modem. alias.txt - - info on using alias network devices + - info on using alias network devices. arcnet-hardware.txt - tons of info on ARCnet, hubs, jumper settings for ARCnet cards, etc. arcnet.txt @@ -80,7 +86,7 @@ framerelay.txt - info on using Frame Relay/Data Link Connection Identifier (DLCI). gen_stats.txt - Generic networking statistics for netlink users. -generic_hdlc.txt +generic-hdlc.txt - The generic High Level Data Link Control (HDLC) layer. generic_netlink.txt - info on Generic Netlink @@ -88,6 +94,8 @@ gianfar.txt - Gianfar Ethernet Driver. i40e.txt - README for the Intel Ethernet Controller XL710 Driver (i40e). +i40evf.txt + - Short note on the Driver for the Intel(R) XL710 X710 Virtual Function ieee802154.txt - Linux IEEE 802.15.4 implementation, API and drivers igb.txt @@ -102,6 +110,8 @@ ipddp.txt - AppleTalk-IP Decapsulation and AppleTalk-IP Encapsulation iphase.txt - Interphase PCI ATM (i)Chip IA Linux driver info. +ipsec.txt + - Note on not compressing IPSec payload and resulting failed policy check. ipv6.txt - Options to the ipv6 kernel module. ipvs-sysctl.txt @@ -120,6 +130,8 @@ lapb-module.txt - programming information of the LAPB module. ltpc.txt - the Apple or Farallon LocalTalk PC card driver +mac80211-auth-assoc-deauth.txt + - authentication and association / deauth-disassoc with max80211 mac80211-injection.txt - HOWTO use packet injection with mac80211 multiqueue.txt @@ -134,6 +146,10 @@ netdevices.txt - info on network device driver functions exported to the kernel. netif-msg.txt - Design of the network interface message level setting (NETIF_MSG_*). +netlink_mmap.txt + - memory mapped I/O with netlink +nf_conntrack-sysctl.txt + - list of netfilter-sysctl knobs. nfc.txt - The Linux Near Field Communication (NFS) subsystem. openvswitch.txt @@ -176,7 +192,7 @@ skfp.txt - SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info. smc9.txt - the driver for SMC's 9000 series of Ethernet cards -spider-net.txt +spider_net.txt - README for the Spidernet Driver (as found in PS3 / Cell BE). stmmac.txt - README for the STMicro Synopsys Ethernet driver. @@ -188,6 +204,8 @@ tcp.txt - short blurb on how TCP output takes place. tcp-thin.txt - kernel tuning options for low rate 'thin' TCP streams. +team.txt + - pointer to information for ethernet teaming devices. tlan.txt - ThunderLAN (Compaq Netelligent 10/100, Olicom OC-2xxx) driver info. tproxy.txt @@ -200,6 +218,8 @@ vortex.txt - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. vxge.txt - README for the Neterion X3100 PCIe Server Adapter. +vxlan.txt + - Virtual extensible LAN overview x25.txt - general info on X.25 development. x25-iface.txt diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 5de03740cdd5..ab42c95f9985 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -1088,6 +1088,12 @@ igmpv3_unsolicited_report_interval - INTEGER IGMPv3 report retransmit will take place. Default: 1000 (1 seconds) +promote_secondaries - BOOLEAN + When a primary IP address is removed from this interface + promote a corresponding secondary IP address instead of + removing all the corresponding secondary IP addresses. + + tag - INTEGER Allows you to write a number, which can be used as required. Default value is 0. diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 91ffe1d9e8ca..1404674c0a02 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -583,6 +583,7 @@ Currently implemented fanout policies are: - 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 + - PACKET_FANOUT_QM: schedule to socket by skbs recorded queue_mapping Minimal example code by David S. Miller (try things like "./test eth0 hash", "./test eth0 lb", etc.): diff --git a/Documentation/power/00-INDEX b/Documentation/power/00-INDEX index a4d682f54231..ad04cc8097ed 100644 --- a/Documentation/power/00-INDEX +++ b/Documentation/power/00-INDEX @@ -4,6 +4,8 @@ apm-acpi.txt - basic info about the APM and ACPI support. basic-pm-debugging.txt - Debugging suspend and resume +charger-manager.txt + - Battery charger management. devices.txt - How drivers interact with system-wide power management drivers-testing.txt @@ -22,6 +24,8 @@ pm_qos_interface.txt - info on Linux PM Quality of Service interface power_supply_class.txt - Tells userspace about battery, UPS, AC or DC power supply properties +runtime_pm.txt + - Power management framework for I/O devices. s2ram.txt - How to get suspend to ram working (and debug it when it isn't) states.txt @@ -38,7 +42,5 @@ tricks.txt - How to trick software suspend (to disk) into working when it isn't userland-swsusp.txt - Experimental implementation of software suspend in userspace -video_extension.txt - - ACPI video extensions video.txt - Video issues during resume from suspend diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt index e9b54de8fdf7..edeecd447d23 100644 --- a/Documentation/power/basic-pm-debugging.txt +++ b/Documentation/power/basic-pm-debugging.txt @@ -172,7 +172,7 @@ you can boot the kernel with the 'no_console_suspend' parameter and try to log kernel messages using the serial console. This may provide you with some information about the reasons of the suspend (resume) failure. Alternatively, it may be possible to use a FireWire port for debugging with firescope -(ftp://ftp.firstfloor.org/pub/ak/firescope/). On x86 it is also possible to +(http://v3.sk/~lkundrak/firescope/). On x86 it is also possible to use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt . 2. Testing suspend to RAM (STR) diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c index a74d0a84d329..4aba0436da65 100644 --- a/Documentation/ptp/testptp.c +++ b/Documentation/ptp/testptp.c @@ -117,6 +117,7 @@ static void usage(char *progname) " -f val adjust the ptp clock frequency by 'val' ppb\n" " -g get the ptp clock time\n" " -h prints this message\n" + " -i val index for event/trigger\n" " -k val measure the time offset between system and phc clock\n" " for 'val' times (Maximum 25)\n" " -p val enable output with a period of 'val' nanoseconds\n" @@ -154,6 +155,7 @@ int main(int argc, char *argv[]) int capabilities = 0; int extts = 0; int gettime = 0; + int index = 0; int oneshot = 0; int pct_offset = 0; int n_samples = 0; @@ -167,7 +169,7 @@ int main(int argc, char *argv[]) progname = strrchr(argv[0], '/'); progname = progname ? 1+progname : argv[0]; - while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghk:p:P:sSt:v"))) { + while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghi:k:p:P:sSt:v"))) { switch (c) { case 'a': oneshot = atoi(optarg); @@ -190,6 +192,9 @@ int main(int argc, char *argv[]) case 'g': gettime = 1; break; + case 'i': + index = atoi(optarg); + break; case 'k': pct_offset = 1; n_samples = atoi(optarg); @@ -301,7 +306,7 @@ int main(int argc, char *argv[]) if (extts) { memset(&extts_request, 0, sizeof(extts_request)); - extts_request.index = 0; + extts_request.index = index; extts_request.flags = PTP_ENABLE_FEATURE; if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) { perror("PTP_EXTTS_REQUEST"); @@ -375,7 +380,7 @@ int main(int argc, char *argv[]) return -1; } memset(&perout_request, 0, sizeof(perout_request)); - perout_request.index = 0; + perout_request.index = index; perout_request.start.sec = ts.tv_sec + 2; perout_request.start.nsec = 0; perout_request.period.sec = 0; diff --git a/Documentation/s390/00-INDEX b/Documentation/s390/00-INDEX index 3a2b96302ecc..10c874ebdfe5 100644 --- a/Documentation/s390/00-INDEX +++ b/Documentation/s390/00-INDEX @@ -16,11 +16,13 @@ Debugging390.txt - hints for debugging on s390 systems. driver-model.txt - information on s390 devices and the driver model. +kvm.txt + - ioctl calls to /dev/kvm on s390. monreader.txt - information on accessing the z/VM monitor stream from Linux. +qeth.txt + - HiperSockets Bridge Port Support. s390dbf.txt - information on using the s390 debug feature. -TAPE - - information on the driver for channel-attached tapes. -zfcpdump +zfcpdump.txt - information on the s390 SCSI dump tool. diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX index d2651c47ae27..eccf7ad2e7f9 100644 --- a/Documentation/scheduler/00-INDEX +++ b/Documentation/scheduler/00-INDEX @@ -2,6 +2,8 @@ - this file. sched-arch.txt - CPU Scheduler implementation hints for architecture specific code. +sched-bwc.txt + - CFS bandwidth control overview. sched-design-CFS.txt - goals, design and implementation of the Completely Fair Scheduler. sched-domains.txt @@ -10,5 +12,7 @@ sched-nice-design.txt - How and why the scheduler's nice levels are implemented. sched-rt-group.txt - real-time group scheduling. +sched-deadline.txt + - deadline scheduling. sched-stats.txt - information on schedstats (Linux Scheduler Statistics). diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt new file mode 100644 index 000000000000..18adc92a6b3b --- /dev/null +++ b/Documentation/scheduler/sched-deadline.txt @@ -0,0 +1,281 @@ + Deadline Task Scheduling + ------------------------ + +CONTENTS +======== + + 0. WARNING + 1. Overview + 2. Scheduling algorithm + 3. Scheduling Real-Time Tasks + 4. Bandwidth management + 4.1 System-wide settings + 4.2 Task interface + 4.3 Default behavior + 5. Tasks CPU affinity + 5.1 SCHED_DEADLINE and cpusets HOWTO + 6. Future plans + + +0. WARNING +========== + + Fiddling with these settings can result in an unpredictable or even unstable + system behavior. As for -rt (group) scheduling, it is assumed that root users + know what they're doing. + + +1. Overview +=========== + + The SCHED_DEADLINE policy contained inside the sched_dl scheduling class is + basically an implementation of the Earliest Deadline First (EDF) scheduling + algorithm, augmented with a mechanism (called Constant Bandwidth Server, CBS) + that makes it possible to isolate the behavior of tasks between each other. + + +2. Scheduling algorithm +================== + + SCHED_DEADLINE uses three parameters, named "runtime", "period", and + "deadline" to schedule tasks. A SCHED_DEADLINE task is guaranteed to receive + "runtime" microseconds of execution time every "period" microseconds, and + these "runtime" microseconds are available within "deadline" microseconds + from the beginning of the period. In order to implement this behaviour, + every time the task wakes up, the scheduler computes a "scheduling deadline" + consistent with the guarantee (using the CBS[2,3] algorithm). Tasks are then + scheduled using EDF[1] on these scheduling deadlines (the task with the + smallest scheduling deadline is selected for execution). Notice that this + guaranteed is respected if a proper "admission control" strategy (see Section + "4. Bandwidth management") is used. + + Summing up, the CBS[2,3] algorithms assigns scheduling deadlines to tasks so + that each task runs for at most its runtime every period, avoiding any + interference between different tasks (bandwidth isolation), while the EDF[1] + algorithm selects the task with the smallest scheduling deadline as the one + to be executed first. Thanks to this feature, also tasks that do not + strictly comply with the "traditional" real-time task model (see Section 3) + can effectively use the new policy. + + In more details, the CBS algorithm assigns scheduling deadlines to + tasks in the following way: + + - Each SCHED_DEADLINE task is characterised by the "runtime", + "deadline", and "period" parameters; + + - The state of the task is described by a "scheduling deadline", and + a "current runtime". These two parameters are initially set to 0; + + - When a SCHED_DEADLINE task wakes up (becomes ready for execution), + the scheduler checks if + + current runtime runtime + ---------------------------------- > ---------------- + scheduling deadline - current time period + + then, if the scheduling deadline is smaller than the current time, or + this condition is verified, the scheduling deadline and the + current budget are re-initialised as + + scheduling deadline = current time + deadline + current runtime = runtime + + otherwise, the scheduling deadline and the current runtime are + left unchanged; + + - When a SCHED_DEADLINE task executes for an amount of time t, its + current runtime is decreased as + + current runtime = current runtime - t + + (technically, the runtime is decreased at every tick, or when the + task is descheduled / preempted); + + - When the current runtime becomes less or equal than 0, the task is + said to be "throttled" (also known as "depleted" in real-time literature) + and cannot be scheduled until its scheduling deadline. The "replenishment + time" for this task (see next item) is set to be equal to the current + value of the scheduling deadline; + + - When the current time is equal to the replenishment time of a + throttled task, the scheduling deadline and the current runtime are + updated as + + scheduling deadline = scheduling deadline + period + current runtime = current runtime + runtime + + +3. Scheduling Real-Time Tasks +============================= + + * BIG FAT WARNING ****************************************************** + * + * This section contains a (not-thorough) summary on classical deadline + * scheduling theory, and how it applies to SCHED_DEADLINE. + * The reader can "safely" skip to Section 4 if only interested in seeing + * how the scheduling policy can be used. Anyway, we strongly recommend + * to come back here and continue reading (once the urge for testing is + * satisfied :P) to be sure of fully understanding all technical details. + ************************************************************************ + + There are no limitations on what kind of task can exploit this new + scheduling discipline, even if it must be said that it is particularly + suited for periodic or sporadic real-time tasks that need guarantees on their + timing behavior, e.g., multimedia, streaming, control applications, etc. + + A typical real-time task is composed of a repetition of computation phases + (task instances, or jobs) which are activated on a periodic or sporadic + fashion. + Each job J_j (where J_j is the j^th job of the task) is characterised by an + arrival time r_j (the time when the job starts), an amount of computation + time c_j needed to finish the job, and a job absolute deadline d_j, which + is the time within which the job should be finished. The maximum execution + time max_j{c_j} is called "Worst Case Execution Time" (WCET) for the task. + A real-time task can be periodic with period P if r_{j+1} = r_j + P, or + sporadic with minimum inter-arrival time P is r_{j+1} >= r_j + P. Finally, + d_j = r_j + D, where D is the task's relative deadline. + + SCHED_DEADLINE can be used to schedule real-time tasks guaranteeing that + the jobs' deadlines of a task are respected. In order to do this, a task + must be scheduled by setting: + + - runtime >= WCET + - deadline = D + - period <= P + + IOW, if runtime >= WCET and if period is >= P, then the scheduling deadlines + and the absolute deadlines (d_j) coincide, so a proper admission control + allows to respect the jobs' absolute deadlines for this task (this is what is + called "hard schedulability property" and is an extension of Lemma 1 of [2]). + + References: + 1 - C. L. Liu and J. W. Layland. Scheduling algorithms for multiprogram- + ming in a hard-real-time environment. Journal of the Association for + Computing Machinery, 20(1), 1973. + 2 - L. Abeni , G. Buttazzo. Integrating Multimedia Applications in Hard + Real-Time Systems. Proceedings of the 19th IEEE Real-time Systems + Symposium, 1998. http://retis.sssup.it/~giorgio/paps/1998/rtss98-cbs.pdf + 3 - L. Abeni. Server Mechanisms for Multimedia Applications. ReTiS Lab + Technical Report. http://xoomer.virgilio.it/lucabe72/pubs/tr-98-01.ps + +4. Bandwidth management +======================= + + In order for the -deadline scheduling to be effective and useful, it is + important to have some method to keep the allocation of the available CPU + bandwidth to the tasks under control. + This is usually called "admission control" and if it is not performed at all, + no guarantee can be given on the actual scheduling of the -deadline tasks. + + Since when RT-throttling has been introduced each task group has a bandwidth + associated, calculated as a certain amount of runtime over a period. + Moreover, to make it possible to manipulate such bandwidth, readable/writable + controls have been added to both procfs (for system wide settings) and cgroupfs + (for per-group settings). + Therefore, the same interface is being used for controlling the bandwidth + distrubution to -deadline tasks. + + However, more discussion is needed in order to figure out how we want to manage + SCHED_DEADLINE bandwidth at the task group level. Therefore, SCHED_DEADLINE + uses (for now) a less sophisticated, but actually very sensible, mechanism to + ensure that a certain utilization cap is not overcome per each root_domain. + + Another main difference between deadline bandwidth management and RT-throttling + is that -deadline tasks have bandwidth on their own (while -rt ones don't!), + and thus we don't need an higher level throttling mechanism to enforce the + desired bandwidth. + +4.1 System wide settings +------------------------ + + The system wide settings are configured under the /proc virtual file system. + + For now the -rt knobs are used for dl admission control and the -deadline + runtime is accounted against the -rt runtime. We realise that this isn't + entirely desirable; however, it is better to have a small interface for now, + and be able to change it easily later. The ideal situation (see 5.) is to run + -rt tasks from a -deadline server; in which case the -rt bandwidth is a direct + subset of dl_bw. + + This means that, for a root_domain comprising M CPUs, -deadline tasks + can be created while the sum of their bandwidths stays below: + + M * (sched_rt_runtime_us / sched_rt_period_us) + + It is also possible to disable this bandwidth management logic, and + be thus free of oversubscribing the system up to any arbitrary level. + This is done by writing -1 in /proc/sys/kernel/sched_rt_runtime_us. + + +4.2 Task interface +------------------ + + Specifying a periodic/sporadic task that executes for a given amount of + runtime at each instance, and that is scheduled according to the urgency of + its own timing constraints needs, in general, a way of declaring: + - a (maximum/typical) instance execution time, + - a minimum interval between consecutive instances, + - a time constraint by which each instance must be completed. + + Therefore: + * a new struct sched_attr, containing all the necessary fields is + provided; + * the new scheduling related syscalls that manipulate it, i.e., + sched_setattr() and sched_getattr() are implemented. + + +4.3 Default behavior +--------------------- + + The default value for SCHED_DEADLINE bandwidth is to have rt_runtime equal to + 950000. With rt_period equal to 1000000, by default, it means that -deadline + tasks can use at most 95%, multiplied by the number of CPUs that compose the + root_domain, for each root_domain. + + A -deadline task cannot fork. + +5. Tasks CPU affinity +===================== + + -deadline tasks cannot have an affinity mask smaller that the entire + root_domain they are created on. However, affinities can be specified + through the cpuset facility (Documentation/cgroups/cpusets.txt). + +5.1 SCHED_DEADLINE and cpusets HOWTO +------------------------------------ + + An example of a simple configuration (pin a -deadline task to CPU0) + follows (rt-app is used to create a -deadline task). + + mkdir /dev/cpuset + mount -t cgroup -o cpuset cpuset /dev/cpuset + cd /dev/cpuset + mkdir cpu0 + echo 0 > cpu0/cpuset.cpus + echo 0 > cpu0/cpuset.mems + echo 1 > cpuset.cpu_exclusive + echo 0 > cpuset.sched_load_balance + echo 1 > cpu0/cpuset.cpu_exclusive + echo 1 > cpu0/cpuset.mem_exclusive + echo $$ > cpu0/tasks + rt-app -t 100000:10000:d:0 -D5 (it is now actually superfluous to specify + task affinity) + +6. Future plans +=============== + + Still missing: + + - refinements to deadline inheritance, especially regarding the possibility + of retaining bandwidth isolation among non-interacting tasks. This is + being studied from both theoretical and practical points of view, and + hopefully we should be able to produce some demonstrative code soon; + - (c)group based bandwidth management, and maybe scheduling; + - access control for non-root users (and related security concerns to + address), which is the best way to allow unprivileged use of the mechanisms + and how to prevent non-root users "cheat" the system? + + As already discussed, we are planning also to merge this work with the EDF + throttling patches [https://lkml.org/lkml/2010/2/23/239] but we still are in + the preliminary phases of the merge and we really seek feedback that would + help us decide on the direction it should take. diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX index 2044be565d93..c4b978a72f78 100644 --- a/Documentation/scsi/00-INDEX +++ b/Documentation/scsi/00-INDEX @@ -36,6 +36,8 @@ NinjaSCSI.txt - info on WorkBiT NinjaSCSI-32/32Bi driver aacraid.txt - Driver supporting Adaptec RAID controllers +advansys.txt + - List of Advansys Host Adapters aha152x.txt - info on driver for Adaptec AHA152x based adapters aic79xx.txt @@ -44,6 +46,12 @@ aic7xxx.txt - info on driver for Adaptec controllers arcmsr_spec.txt - ARECA FIRMWARE SPEC (for IOP331 adapter) +bfa.txt + - Brocade FC/FCOE adapter driver. +bnx2fc.txt + - FCoE hardware offload for Broadcom network interfaces. +cxgb3i.txt + - Chelsio iSCSI Linux Driver dc395x.txt - README file for the dc395x SCSI driver dpti.txt @@ -52,18 +60,24 @@ dtc3x80.txt - info on driver for DTC 2x80 based adapters g_NCR5380.txt - info on driver for NCR5380 and NCR53c400 based adapters +hpsa.txt + - HP Smart Array Controller SCSI driver. hptiop.txt - HIGHPOINT ROCKETRAID 3xxx RAID DRIVER in2000.txt - info on in2000 driver libsas.txt - Serial Attached SCSI management layer. +link_power_management_policy.txt + - Link power management options. lpfc.txt - LPFC driver release notes megaraid.txt - Common Management Module, shared code handling ioctls for LSI drivers ncr53c8xx.txt - info on driver for NCR53c8xx based adapters +osd.txt + Object-Based Storage Device, command set introduction. osst.txt - info on driver for OnStream SC-x0 SCSI tape ppa.txt @@ -74,6 +88,8 @@ scsi-changer.txt - README for the SCSI media changer driver scsi-generic.txt - info on the sg driver for generic (non-disk/CD/tape) SCSI devices. +scsi-parameters.txt + - List of SCSI-parameters to pass to the kernel at module load-time. scsi.txt - short blurb on using SCSI support as a module. scsi_mid_low_api.txt diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX index 1f1b22fbd739..f9c6b5ed03e7 100644 --- a/Documentation/serial/00-INDEX +++ b/Documentation/serial/00-INDEX @@ -4,10 +4,12 @@ README.cycladesZ - info on Cyclades-Z firmware loading. digiepca.txt - info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards. -hayes-esp.txt - - info on using the Hayes ESP serial driver. +driver + - intro to the low level serial driver. moxa-smartio - file with info on installing/using Moxa multiport serial driver. +n_gsm.txt + - GSM 0710 tty multiplexer howto. riscom8.txt - notes on using the RISCom/8 multi-port serial driver. rocket.txt diff --git a/Documentation/spi/00-INDEX b/Documentation/spi/00-INDEX new file mode 100644 index 000000000000..a128fa835512 --- /dev/null +++ b/Documentation/spi/00-INDEX @@ -0,0 +1,22 @@ +00-INDEX + - this file. +Makefile + - Makefile for the example sourcefiles. +butterfly + - AVR Butterfly SPI driver overview and pin configuration. +ep93xx_spi + - Basic EP93xx SPI driver configuration. +pxa2xx + - PXA2xx SPI master controller build by spi_message fifo wq +spidev + - Intro to the userspace API for spi devices +spidev_fdx.c + - spidev example file +spi-lm70llp + - Connecting an LM70-LLP sensor to the kernel via the SPI subsys. +spi-sc18is602 + - NXP SC18IS602/603 I2C-bus to SPI bridge +spi-summary + - (Linux) SPI overview. If unsure about SPI or SPI in Linux, start here. +spidev_test.c + - SPI testing utility. diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index ee9a2f983b99..e55124e7c40c 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -33,6 +33,10 @@ show up in /proc/sys/kernel: - domainname - hostname - hotplug +- hung_task_panic +- hung_task_check_count +- hung_task_timeout_secs +- hung_task_warnings - kexec_load_disabled - kptr_restrict - kstack_depth_to_print [ X86 only ] @@ -288,6 +292,44 @@ Default value is "/sbin/hotplug". ============================================================== +hung_task_panic: + +Controls the kernel's behavior when a hung task is detected. +This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. + +0: continue operation. This is the default behavior. + +1: panic immediately. + +============================================================== + +hung_task_check_count: + +The upper bound on the number of tasks that are checked. +This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. + +============================================================== + +hung_task_timeout_secs: + +Check interval. When a task in D state did not get scheduled +for more than this value report a warning. +This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. + +0: means infinite timeout - no checking done. + +============================================================== + +hung_task_warning: + +The maximum number of warnings to report. During a check interval +When this value is reached, no more the warnings will be reported. +This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. + +-1: report an infinite number of warnings. + +============================================================== + kexec_load_disabled: A toggle indicating if the kexec_load syscall has been disabled. This diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 9f5481bdc5a4..d614a9b6a280 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -696,7 +696,9 @@ swappiness This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase agressiveness, lower values -decrease the amount of swap. +decrease the amount of swap. A value of 0 instructs the kernel not to +initiate swap until the amount of free and file-backed pages is less +than the high water mark in a zone. The default value is 60. diff --git a/Documentation/timers/00-INDEX b/Documentation/timers/00-INDEX index ef2ccbf77fa2..6d042dc1cce0 100644 --- a/Documentation/timers/00-INDEX +++ b/Documentation/timers/00-INDEX @@ -8,6 +8,8 @@ hpet_example.c - sample hpet timer test program hrtimers.txt - subsystem for high-resolution kernel timers +Makefile + - Build and link hpet_example NO_HZ.txt - Summary of the different methods for the scheduler clock-interrupts management. timers-howto.txt diff --git a/Documentation/video4linux/omap4_camera.txt b/Documentation/video4linux/omap4_camera.txt new file mode 100644 index 000000000000..25d9b40a4651 --- /dev/null +++ b/Documentation/video4linux/omap4_camera.txt @@ -0,0 +1,60 @@ + OMAP4 ISS Driver + ================ + +Introduction +------------ + +The OMAP44XX family of chips contains the Imaging SubSystem (a.k.a. ISS), +Which contains several components that can be categorized in 3 big groups: + +- Interfaces (2 Interfaces: CSI2-A & CSI2-B/CCP2) +- ISP (Image Signal Processor) +- SIMCOP (Still Image Coprocessor) + +For more information, please look in [1] for latest version of: + "OMAP4430 Multimedia Device Silicon Revision 2.x" + +As of Revision AB, the ISS is described in detail in section 8. + +This driver is supporting _only_ the CSI2-A/B interfaces for now. + +It makes use of the Media Controller framework [2], and inherited most of the +code from OMAP3 ISP driver (found under drivers/media/platform/omap3isp/*), +except that it doesn't need an IOMMU now for ISS buffers memory mapping. + +Supports usage of MMAP buffers only (for now). + +Tested platforms +---------------- + +- OMAP4430SDP, w/ ES2.1 GP & SEVM4430-CAM-V1-0 (Contains IMX060 & OV5640, in + which only the last one is supported, outputting YUV422 frames). + +- TI Blaze MDP, w/ OMAP4430 ES2.2 EMU (Contains 1 IMX060 & 2 OV5650 sensors, in + which only the OV5650 are supported, outputting RAW10 frames). + +- PandaBoard, Rev. A2, w/ OMAP4430 ES2.1 GP & OV adapter board, tested with + following sensors: + * OV5640 + * OV5650 + +- Tested on mainline kernel: + + http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary + + Tag: v3.3 (commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7) + +File list +--------- +drivers/staging/media/omap4iss/ +include/media/omap4iss.h + +References +---------- + +[1] http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?navigationId=12037&templateId=6123#62 +[2] http://lwn.net/Articles/420485/ +[3] http://www.spinics.net/lists/linux-media/msg44370.html +-- +Author: Sergio Aguirre <sergio.a.aguirre@gmail.com> +Copyright (C) 2012, Texas Instruments diff --git a/Documentation/video4linux/si476x.txt b/Documentation/video4linux/si476x.txt index 2f9b4875ab8a..616607955aaf 100644 --- a/Documentation/video4linux/si476x.txt +++ b/Documentation/video4linux/si476x.txt @@ -147,7 +147,7 @@ The drivers exposes following files: -------------------------------------------------------------------- 0x12 | readfreq | Current tuned frequency -------------------------------------------------------------------- - 0x14 | freqoff | Singed frequency offset in units of + 0x14 | freqoff | Signed frequency offset in units of | | 2ppm -------------------------------------------------------------------- 0x15 | rssi | Signed value of RSSI in dBuV diff --git a/Documentation/video4linux/sn9c102.txt b/Documentation/video4linux/sn9c102.txt deleted file mode 100644 index b4f67040403a..000000000000 --- a/Documentation/video4linux/sn9c102.txt +++ /dev/null @@ -1,592 +0,0 @@ - - SN9C1xx PC Camera Controllers - Driver for Linux - ============================= - - - Documentation - - - -Index -===== -1. Copyright -2. Disclaimer -3. License -4. Overview and features -5. Module dependencies -6. Module loading -7. Module parameters -8. Optional device control through "sysfs" -9. Supported devices -10. Notes for V4L2 application developers -11. Video frame formats -12. Contact information -13. Credits - - -1. Copyright -============ -Copyright (C) 2004-2007 by Luca Risolia <luca.risolia@studio.unibo.it> - - -2. Disclaimer -============= -SONiX is a trademark of SONiX Technology Company Limited, inc. -This software is not sponsored or developed by SONiX. - - -3. License -========== -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or -(at your option) any later version. - -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - -4. Overview and features -======================== -This driver attempts to support the video interface of the devices assembling -the SONiX SN9C101, SN9C102, SN9C103, SN9C105 and SN9C120 PC Camera Controllers -("SN9C1xx" from now on). - -The driver relies on the Video4Linux2 and USB core modules. It has been -designed to run properly on SMP systems as well. - -The latest version of the SN9C1xx driver can be found at the following URL: -http://www.linux-projects.org/ - -Some of the features of the driver are: - -- full compliance with the Video4Linux2 API (see also "Notes for V4L2 - application developers" paragraph); -- available mmap or read/poll methods for video streaming through isochronous - data transfers; -- automatic detection of image sensor; -- support for built-in microphone interface; -- support for any window resolutions and optional panning within the maximum - pixel area of image sensor; -- image downscaling with arbitrary scaling factors from 1, 2 and 4 in both - directions (see "Notes for V4L2 application developers" paragraph); -- two different video formats for uncompressed or compressed data in low or - high compression quality (see also "Notes for V4L2 application developers" - and "Video frame formats" paragraphs); -- full support for the capabilities of many of the possible image sensors that - can be connected to the SN9C1xx bridges, including, for instance, red, green, - blue and global gain adjustments and exposure (see "Supported devices" - paragraph for details); -- use of default color settings for sunlight conditions; -- dynamic I/O interface for both SN9C1xx and image sensor control and - monitoring (see "Optional device control through 'sysfs'" paragraph); -- dynamic driver control thanks to various module parameters (see "Module - parameters" paragraph); -- up to 64 cameras can be handled at the same time; they can be connected and - disconnected from the host many times without turning off the computer, if - the system supports hotplugging; -- no known bugs. - - -5. Module dependencies -====================== -For it to work properly, the driver needs kernel support for Video4Linux and -USB. - -The following options of the kernel configuration file must be enabled and -corresponding modules must be compiled: - - # Multimedia devices - # - CONFIG_VIDEO_DEV=m - -To enable advanced debugging functionality on the device through /sysfs: - - # Multimedia devices - # - CONFIG_VIDEO_ADV_DEBUG=y - - # USB support - # - CONFIG_USB=m - -In addition, depending on the hardware being used, the modules below are -necessary: - - # USB Host Controller Drivers - # - CONFIG_USB_EHCI_HCD=m - CONFIG_USB_UHCI_HCD=m - CONFIG_USB_OHCI_HCD=m - -The SN9C103, SN9c105 and SN9C120 controllers also provide a built-in microphone -interface. It is supported by the USB Audio driver thanks to the ALSA API: - - # Sound - # - CONFIG_SOUND=y - - # Advanced Linux Sound Architecture - # - CONFIG_SND=m - - # USB devices - # - CONFIG_SND_USB_AUDIO=m - -And finally: - - # USB Multimedia devices - # - CONFIG_USB_SN9C102=m - - -6. Module loading -================= -To use the driver, it is necessary to load the "sn9c102" module into memory -after every other module required: "videodev", "v4l2_common", "compat_ioctl32", -"usbcore" and, depending on the USB host controller you have, "ehci-hcd", -"uhci-hcd" or "ohci-hcd". - -Loading can be done as shown below: - - [root@localhost home]# modprobe sn9c102 - -Note that the module is called "sn9c102" for historic reasons, although it -does not just support the SN9C102. - -At this point all the devices supported by the driver and connected to the USB -ports should be recognized. You can invoke "dmesg" to analyze kernel messages -and verify that the loading process has gone well: - - [user@localhost home]$ dmesg - -or, to isolate all the kernel messages generated by the driver: - - [user@localhost home]$ dmesg | grep sn9c102 - - -7. Module parameters -==================== -Module parameters are listed below: -------------------------------------------------------------------------------- -Name: video_nr -Type: short array (min = 0, max = 64) -Syntax: <-1|n[,...]> -Description: Specify V4L2 minor mode number: - -1 = use next available - n = use minor number n - You can specify up to 64 cameras this way. - For example: - video_nr=-1,2,-1 would assign minor number 2 to the second - recognized camera and use auto for the first one and for every - other camera. -Default: -1 -------------------------------------------------------------------------------- -Name: force_munmap -Type: bool array (min = 0, max = 64) -Syntax: <0|1[,...]> -Description: Force the application to unmap previously mapped buffer memory - before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not - all the applications support this feature. This parameter is - specific for each detected camera. - 0 = do not force memory unmapping - 1 = force memory unmapping (save memory) -Default: 0 -------------------------------------------------------------------------------- -Name: frame_timeout -Type: uint array (min = 0, max = 64) -Syntax: <0|n[,...]> -Description: Timeout for a video frame in seconds before returning an I/O - error; 0 for infinity. This parameter is specific for each - detected camera and can be changed at runtime thanks to the - /sys filesystem interface. -Default: 2 -------------------------------------------------------------------------------- -Name: debug -Type: ushort -Syntax: <n> -Description: Debugging information level, from 0 to 3: - 0 = none (use carefully) - 1 = critical errors - 2 = significant information - 3 = more verbose messages - Level 3 is useful for testing only. It also shows some more - information about the hardware being detected. - This parameter can be changed at runtime thanks to the /sys - filesystem interface. -Default: 2 -------------------------------------------------------------------------------- - - -8. Optional device control through "sysfs" [1] -========================================== -If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled, -it is possible to read and write both the SN9C1xx and the image sensor -registers by using the "sysfs" filesystem interface. - -Every time a supported device is recognized, a write-only file named "green" is -created in the /sys/class/video4linux/videoX directory. You can set the green -channel's gain by writing the desired value to it. The value may range from 0 -to 15 for the SN9C101 or SN9C102 bridges, from 0 to 127 for the SN9C103, -SN9C105 and SN9C120 bridges. -Similarly, only for the SN9C103, SN9C105 and SN9C120 controllers, blue and red -gain control files are available in the same directory, for which accepted -values may range from 0 to 127. - -There are other four entries in the directory above for each registered camera: -"reg", "val", "i2c_reg" and "i2c_val". The first two files control the -SN9C1xx bridge, while the other two control the sensor chip. "reg" and -"i2c_reg" hold the values of the current register index where the following -reading/writing operations are addressed at through "val" and "i2c_val". Their -use is not intended for end-users. Note that "i2c_reg" and "i2c_val" will not -be created if the sensor does not actually support the standard I2C protocol or -its registers are not 8-bit long. Also, remember that you must be logged in as -root before writing to them. - -As an example, suppose we were to want to read the value contained in the -register number 1 of the sensor register table - which is usually the product -identifier - of the camera registered as "/dev/video0": - - [root@localhost #] cd /sys/class/video4linux/video0 - [root@localhost #] echo 1 > i2c_reg - [root@localhost #] cat i2c_val - -Note that "cat" will fail if sensor registers cannot be read. - -Now let's set the green gain's register of the SN9C101 or SN9C102 chips to 2: - - [root@localhost #] echo 0x11 > reg - [root@localhost #] echo 2 > val - -Note that the SN9C1xx always returns 0 when some of its registers are read. -To avoid race conditions, all the I/O accesses to the above files are -serialized. -The sysfs interface also provides the "frame_header" entry, which exports the -frame header of the most recent requested and captured video frame. The header -is always 18-bytes long and is appended to every video frame by the SN9C1xx -controllers. As an example, this additional information can be used by the user -application for implementing auto-exposure features via software. - -The following table describes the frame header exported by the SN9C101 and -SN9C102: - -Byte # Value or bits Description ------- ------------- ----------- -0x00 0xFF Frame synchronisation pattern -0x01 0xFF Frame synchronisation pattern -0x02 0x00 Frame synchronisation pattern -0x03 0xC4 Frame synchronisation pattern -0x04 0xC4 Frame synchronisation pattern -0x05 0x96 Frame synchronisation pattern -0x06 [3:0] Read channel gain control = (1+R_GAIN/8) - [7:4] Blue channel gain control = (1+B_GAIN/8) -0x07 [ 0 ] Compression mode. 0=No compression, 1=Compression enabled - [2:1] Maximum scale factor for compression - [ 3 ] 1 = USB fifo(2K bytes) is full - [ 4 ] 1 = Digital gain is finish - [ 5 ] 1 = Exposure is finish - [7:6] Frame index -0x08 [7:0] Y sum inside Auto-Exposure area (low-byte) -0x09 [7:0] Y sum inside Auto-Exposure area (high-byte) - where Y sum = (R/4 + 5G/16 + B/8) / 32 -0x0A [7:0] Y sum outside Auto-Exposure area (low-byte) -0x0B [7:0] Y sum outside Auto-Exposure area (high-byte) - where Y sum = (R/4 + 5G/16 + B/8) / 128 -0x0C 0xXX Not used -0x0D 0xXX Not used -0x0E 0xXX Not used -0x0F 0xXX Not used -0x10 0xXX Not used -0x11 0xXX Not used - -The following table describes the frame header exported by the SN9C103: - -Byte # Value or bits Description ------- ------------- ----------- -0x00 0xFF Frame synchronisation pattern -0x01 0xFF Frame synchronisation pattern -0x02 0x00 Frame synchronisation pattern -0x03 0xC4 Frame synchronisation pattern -0x04 0xC4 Frame synchronisation pattern -0x05 0x96 Frame synchronisation pattern -0x06 [6:0] Read channel gain control = (1/2+R_GAIN/64) -0x07 [6:0] Blue channel gain control = (1/2+B_GAIN/64) - [7:4] -0x08 [ 0 ] Compression mode. 0=No compression, 1=Compression enabled - [2:1] Maximum scale factor for compression - [ 3 ] 1 = USB fifo(2K bytes) is full - [ 4 ] 1 = Digital gain is finish - [ 5 ] 1 = Exposure is finish - [7:6] Frame index -0x09 [7:0] Y sum inside Auto-Exposure area (low-byte) -0x0A [7:0] Y sum inside Auto-Exposure area (high-byte) - where Y sum = (R/4 + 5G/16 + B/8) / 32 -0x0B [7:0] Y sum outside Auto-Exposure area (low-byte) -0x0C [7:0] Y sum outside Auto-Exposure area (high-byte) - where Y sum = (R/4 + 5G/16 + B/8) / 128 -0x0D [1:0] Audio frame number - [ 2 ] 1 = Audio is recording -0x0E [7:0] Audio summation (low-byte) -0x0F [7:0] Audio summation (high-byte) -0x10 [7:0] Audio sample count -0x11 [7:0] Audio peak data in audio frame - -The AE area (sx, sy, ex, ey) in the active window can be set by programming the -registers 0x1c, 0x1d, 0x1e and 0x1f of the SN9C1xx controllers, where one unit -corresponds to 32 pixels. - -[1] The frame headers exported by the SN9C105 and SN9C120 are not described. - - -9. Supported devices -==================== -None of the names of the companies as well as their products will be mentioned -here. They have never collaborated with the author, so no advertising. - -From the point of view of a driver, what unambiguously identify a device are -its vendor and product USB identifiers. Below is a list of known identifiers of -devices assembling the SN9C1xx PC camera controllers: - -Vendor ID Product ID ---------- ---------- -0x0458 0x7025 -0x045e 0x00f5 -0x045e 0x00f7 -0x0471 0x0327 -0x0471 0x0328 -0x0c45 0x6001 -0x0c45 0x6005 -0x0c45 0x6007 -0x0c45 0x6009 -0x0c45 0x600d -0x0c45 0x6011 -0x0c45 0x6019 -0x0c45 0x6024 -0x0c45 0x6025 -0x0c45 0x6028 -0x0c45 0x6029 -0x0c45 0x602a -0x0c45 0x602b -0x0c45 0x602c -0x0c45 0x602d -0x0c45 0x602e -0x0c45 0x6030 -0x0c45 0x603f -0x0c45 0x6080 -0x0c45 0x6082 -0x0c45 0x6083 -0x0c45 0x6088 -0x0c45 0x608a -0x0c45 0x608b -0x0c45 0x608c -0x0c45 0x608e -0x0c45 0x608f -0x0c45 0x60a0 -0x0c45 0x60a2 -0x0c45 0x60a3 -0x0c45 0x60a8 -0x0c45 0x60aa -0x0c45 0x60ab -0x0c45 0x60ac -0x0c45 0x60ae -0x0c45 0x60af -0x0c45 0x60b0 -0x0c45 0x60b2 -0x0c45 0x60b3 -0x0c45 0x60b8 -0x0c45 0x60ba -0x0c45 0x60bb -0x0c45 0x60bc -0x0c45 0x60be -0x0c45 0x60c0 -0x0c45 0x60c2 -0x0c45 0x60c8 -0x0c45 0x60cc -0x0c45 0x60ea -0x0c45 0x60ec -0x0c45 0x60ef -0x0c45 0x60fa -0x0c45 0x60fb -0x0c45 0x60fc -0x0c45 0x60fe -0x0c45 0x6102 -0x0c45 0x6108 -0x0c45 0x610f -0x0c45 0x6130 -0x0c45 0x6138 -0x0c45 0x613a -0x0c45 0x613b -0x0c45 0x613c -0x0c45 0x613e - -The list above does not imply that all those devices work with this driver: up -until now only the ones that assemble the following pairs of SN9C1xx bridges -and image sensors are supported; kernel messages will always tell you whether -this is the case (see "Module loading" paragraph): - -Image sensor / SN9C1xx bridge | SN9C10[12] SN9C103 SN9C105 SN9C120 -------------------------------------------------------------------------------- -HV7131D Hynix Semiconductor | Yes No No No -HV7131R Hynix Semiconductor | No Yes Yes Yes -MI-0343 Micron Technology | Yes No No No -MI-0360 Micron Technology | No Yes Yes Yes -OV7630 OmniVision Technologies | Yes Yes Yes Yes -OV7660 OmniVision Technologies | No No Yes Yes -PAS106B PixArt Imaging | Yes No No No -PAS202B PixArt Imaging | Yes Yes No No -TAS5110C1B Taiwan Advanced Sensor | Yes No No No -TAS5110D Taiwan Advanced Sensor | Yes No No No -TAS5130D1B Taiwan Advanced Sensor | Yes No No No - -"Yes" means that the pair is supported by the driver, while "No" means that the -pair does not exist or is not supported by the driver. - -Only some of the available control settings of each image sensor are supported -through the V4L2 interface. - -Donations of new models for further testing and support would be much -appreciated. Non-available hardware will not be supported by the author of this -driver. - - -10. Notes for V4L2 application developers -========================================= -This driver follows the V4L2 API specifications. In particular, it enforces two -rules: - -- exactly one I/O method, either "mmap" or "read", is associated with each -file descriptor. Once it is selected, the application must close and reopen the -device to switch to the other I/O method; - -- although it is not mandatory, previously mapped buffer memory should always -be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. -The same number of buffers as before will be allocated again to match the size -of the new video frames, so you have to map the buffers again before any I/O -attempts on them. - -Consistently with the hardware limits, this driver also supports image -downscaling with arbitrary scaling factors from 1, 2 and 4 in both directions. -However, the V4L2 API specifications don't correctly define how the scaling -factor can be chosen arbitrarily by the "negotiation" of the "source" and -"target" rectangles. To work around this flaw, we have added the convention -that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the -scaling factor is restored to 1. - -This driver supports two different video formats: the first one is the "8-bit -Sequential Bayer" format and can be used to obtain uncompressed video data -from the device through the current I/O method, while the second one provides -either "raw" compressed video data (without frame headers not related to the -compressed data) or standard JPEG (with frame headers). The compression quality -may vary from 0 to 1 and can be selected or queried thanks to the -VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP V4L2 ioctl's. For maximum flexibility, -both the default active video format and the default compression quality -depend on how the image sensor being used is initialized. - - -11. Video frame formats [1] -======================= -The SN9C1xx PC Camera Controllers can send images in two possible video -formats over the USB: either native "Sequential RGB Bayer" or compressed. -The compression is used to achieve high frame rates. With regard to the -SN9C101, SN9C102 and SN9C103, the compression is based on the Huffman encoding -algorithm described below, while with regard to the SN9C105 and SN9C120 the -compression is based on the JPEG standard. -The current video format may be selected or queried from the user application -by calling the VIDIOC_S_FMT or VIDIOC_G_FMT ioctl's, as described in the V4L2 -API specifications. - -The name "Sequential Bayer" indicates the organization of the red, green and -blue pixels in one video frame. Each pixel is associated with a 8-bit long -value and is disposed in memory according to the pattern shown below: - -B[0] G[1] B[2] G[3] ... B[m-2] G[m-1] -G[m] R[m+1] G[m+2] R[m+2] ... G[2m-2] R[2m-1] -... -... B[(n-1)(m-2)] G[(n-1)(m-1)] -... G[n(m-2)] R[n(m-1)] - -The above matrix also represents the sequential or progressive read-out mode of -the (n, m) Bayer color filter array used in many CCD or CMOS image sensors. - -The Huffman compressed video frame consists of a bitstream that encodes for -every R, G, or B pixel the difference between the value of the pixel itself and -some reference pixel value. Pixels are organised in the Bayer pattern and the -Bayer sub-pixels are tracked individually and alternatingly. For example, in -the first line values for the B and G1 pixels are alternatingly encoded, while -in the second line values for the G2 and R pixels are alternatingly encoded. - -The pixel reference value is calculated as follows: -- the 4 top left pixels are encoded in raw uncompressed 8-bit format; -- the value in the top two rows is the value of the pixel left of the current - pixel; -- the value in the left column is the value of the pixel above the current - pixel; -- for all other pixels, the reference value is the average of the value of the - pixel on the left and the value of the pixel above the current pixel; -- there is one code in the bitstream that specifies the value of a pixel - directly (in 4-bit resolution); -- pixel values need to be clamped inside the range [0..255] for proper - decoding. - -The algorithm purely describes the conversion from compressed Bayer code used -in the SN9C101, SN9C102 and SN9C103 chips to uncompressed Bayer. Additional -steps are required to convert this to a color image (i.e. a color interpolation -algorithm). - -The following Huffman codes have been found: -0: +0 (relative to reference pixel value) -100: +4 -101: -4? -1110xxxx: set absolute value to xxxx.0000 -1101: +11 -1111: -11 -11001: +20 -110000: -20 -110001: ??? - these codes are apparently not used - -[1] The Huffman compression algorithm has been reverse-engineered and - documented by Bertrik Sikken. - - -12. Contact information -======================= -The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>. - -GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is -'FCE635A4'; the public 1024-bit key should be available at any keyserver; -the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. - - -13. Credits -=========== -Many thanks to following persons for their contribute (listed in alphabetical -order): - -- David Anderson for the donation of a webcam; -- Luca Capello for the donation of a webcam; -- Philippe Coval for having helped testing the PAS202BCA image sensor; -- Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the - donation of a webcam; -- Dennis Heitmann for the donation of a webcam; -- Jon Hollstrom for the donation of a webcam; -- Nick McGill for the donation of a webcam; -- Carlos Eduardo Medaglia Dyonisio, who added the support for the PAS202BCB - image sensor; -- Stefano Mozzi, who donated 45 EU; -- Andrew Pearce for the donation of a webcam; -- John Pullan for the donation of a webcam; -- Bertrik Sikken, who reverse-engineered and documented the Huffman compression - algorithm used in the SN9C101, SN9C102 and SN9C103 controllers and - implemented the first decoder; -- Ronny Standke for the donation of a webcam; -- Mizuno Takafumi for the donation of a webcam; -- an "anonymous" donator (who didn't want his name to be revealed) for the - donation of a webcam. -- an anonymous donator for the donation of four webcams and two boards with ten - image sensors. diff --git a/Documentation/virtual/kvm/00-INDEX b/Documentation/virtual/kvm/00-INDEX index 641ec9220179..fee9f2bf9c64 100644 --- a/Documentation/virtual/kvm/00-INDEX +++ b/Documentation/virtual/kvm/00-INDEX @@ -20,5 +20,7 @@ ppc-pv.txt - the paravirtualization interface on PowerPC. review-checklist.txt - review checklist for KVM patches. +s390-diag.txt + - Diagnose hypercall description (for IBM S/390) timekeeping.txt - timekeeping virtualization for x86-based architectures. diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 366bf4b47ef4..6cd63a9010fb 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -1838,6 +1838,7 @@ registers, find a list below: PPC | KVM_REG_PPC_LPCR | 64 PPC | KVM_REG_PPC_PPR | 64 PPC | KVM_REG_PPC_ARCH_COMPAT 32 + PPC | KVM_REG_PPC_DABRX | 32 PPC | KVM_REG_PPC_TM_GPR0 | 64 ... PPC | KVM_REG_PPC_TM_GPR31 | 64 diff --git a/Documentation/vm/00-INDEX b/Documentation/vm/00-INDEX index a39d06680e1c..081c49777abb 100644 --- a/Documentation/vm/00-INDEX +++ b/Documentation/vm/00-INDEX @@ -16,8 +16,6 @@ hwpoison.txt - explains what hwpoison is ksm.txt - how to use the Kernel Samepage Merging feature. -locking - - info on how locking and synchronization is done in the Linux vm code. numa - information about NUMA specific code in the Linux vm. numa_memory_policy.txt @@ -32,6 +30,8 @@ slub.txt - a short users guide for SLUB. soft-dirty.txt - short explanation for soft-dirty PTEs +split_page_table_lock + - Separate per-table lock to improve scalability of the old page_table_lock. transhuge.txt - Transparent Hugepage Support, alternative way of using hugepages. unevictable-lru.txt diff --git a/Documentation/w1/masters/00-INDEX b/Documentation/w1/masters/00-INDEX index d63fa024ac05..8330cf9325f0 100644 --- a/Documentation/w1/masters/00-INDEX +++ b/Documentation/w1/masters/00-INDEX @@ -4,7 +4,9 @@ ds2482 - The Maxim/Dallas Semiconductor DS2482 provides 1-wire busses. ds2490 - The Maxim/Dallas Semiconductor DS2490 builds USB <-> W1 bridges. -mxc_w1 +mxc-w1 - W1 master controller driver found on Freescale MX2/MX3 SoCs +omap-hdq + - HDQ/1-wire module of TI OMAP 2430/3430. w1-gpio - GPIO 1-wire bus master driver. diff --git a/Documentation/w1/slaves/00-INDEX b/Documentation/w1/slaves/00-INDEX index 75613c9ac4db..6e18c70c3474 100644 --- a/Documentation/w1/slaves/00-INDEX +++ b/Documentation/w1/slaves/00-INDEX @@ -4,3 +4,5 @@ w1_therm - The Maxim/Dallas Semiconductor ds18*20 temperature sensor. w1_ds2423 - The Maxim/Dallas Semiconductor ds2423 counter device. +w1_ds28e04 + - The Maxim/Dallas Semiconductor ds28e04 eeprom. diff --git a/Documentation/x86/00-INDEX b/Documentation/x86/00-INDEX index f37b46d34861..692264456f0f 100644 --- a/Documentation/x86/00-INDEX +++ b/Documentation/x86/00-INDEX @@ -1,6 +1,20 @@ 00-INDEX - this file -mtrr.txt - - how to use x86 Memory Type Range Registers to increase performance +boot.txt + - List of boot protocol versions +early-microcode.txt + - How to load microcode from an initrd-CPIO archive early to fix CPU issues. +earlyprintk.txt + - Using earlyprintk with a USB2 debug port key. +entry_64.txt + - Describe (some of the) kernel entry points for x86. exception-tables.txt - why and how Linux kernel uses exception tables on x86 +mtrr.txt + - how to use x86 Memory Type Range Registers to increase performance +pat.txt + - Page Attribute Table intro and API +usb-legacy-support.txt + - how to fix/avoid quirks when using emulated PS/2 mouse/keyboard. +zero-page.txt + - layout of the first page of memory. |