diff options
Diffstat (limited to 'Documentation')
149 files changed, 3100 insertions, 443 deletions
diff --git a/Documentation/.gitignore b/Documentation/.gitignore deleted file mode 100644 index bcd907b4141f..000000000000 --- a/Documentation/.gitignore +++ /dev/null @@ -1,7 +0,0 @@ -filesystems/dnotify_test -laptops/dslm -timers/hpet_example -vm/hugepage-mmap -vm/hugepage-shm -vm/map_hugetlb - diff --git a/Documentation/ABI/removed/net_dma b/Documentation/ABI/removed/net_dma new file mode 100644 index 000000000000..a173aecc2f18 --- /dev/null +++ b/Documentation/ABI/removed/net_dma @@ -0,0 +1,8 @@ +What: tcp_dma_copybreak sysctl +Date: Removed in kernel v3.13 +Contact: Dan Williams <dan.j.williams@intel.com> +Description: + Formerly the lower limit, in bytes, of the size of socket reads + that will be offloaded to a DMA copy engine. Removed due to + coherency issues of the cpu potentially touching the buffers + while dma is in flight. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 b/Documentation/ABI/testing/configfs-usb-gadget-uac1 new file mode 100644 index 000000000000..8ba9a123316e --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1 @@ -0,0 +1,12 @@ +What: /config/usb-gadget/gadget/functions/uac1.name +Date: Sep 2014 +KernelVersion: 3.18 +Description: + The attributes: + + audio_buf_size - audio buffer size + fn_cap - capture pcm device file name + fn_cntl - control device file name + fn_play - playback pcm device file name + req_buf_size - ISO OUT endpoint request buffer size + req_count - ISO OUT endpoint request count diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 new file mode 100644 index 000000000000..2bfdd4efa9bd --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -0,0 +1,12 @@ +What: /config/usb-gadget/gadget/functions/uac2.name +Date: Sep 2014 +KernelVersion: 3.18 +Description: + The attributes: + + c_chmask - capture channel mask + c_srate - capture sampling rate + c_ssize - capture sample size (bytes) + p_chmask - playback channel mask + p_srate - playback sampling rate + p_ssize - playback sample size (bytes) diff --git a/Documentation/ABI/testing/sysfs-bus-iio-accel-bmc150 b/Documentation/ABI/testing/sysfs-bus-iio-accel-bmc150 new file mode 100644 index 000000000000..99847a913af7 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-accel-bmc150 @@ -0,0 +1,7 @@ +What: /sys/bus/iio/devices/triggerX/name = "bmc150_accel-any-motion-devX" +KernelVersion: 3.17 +Contact: linux-iio@vger.kernel.org +Description: + The BMC150 accelerometer kernel module provides an additional trigger, + which sets driver in a mode, where data is pushed to the buffer + only when there is any motion. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-gyro-bmg160 b/Documentation/ABI/testing/sysfs-bus-iio-gyro-bmg160 new file mode 100644 index 000000000000..e98209c9155e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-gyro-bmg160 @@ -0,0 +1,7 @@ +What: /sys/bus/iio/devices/triggerX/name = "bmg160-any-motion-devX" +KernelVersion: 3.17 +Contact: linux-iio@vger.kernel.org +Description: + The BMG160 gyro kernel module provides an additional trigger, + which sets driver in a mode, where data is pushed to the buffer + only when there is any motion. diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net index d322b0581194..e1b2e785bba8 100644 --- a/Documentation/ABI/testing/sysfs-class-net +++ b/Documentation/ABI/testing/sysfs-class-net @@ -159,7 +159,7 @@ Description: lower-level interface protocol used. Ethernet devices will show a 'mtu' attribute value of 1500 unless changed. -What: /sys/calss/net/<iface>/netdev_group +What: /sys/class/net/<iface>/netdev_group Date: January 2011 KernelVersion: 2.6.39 Contact: netdev@vger.kernel.org diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc b/Documentation/ABI/testing/sysfs-class-uwb_rc index 6a5fd072849d..85f4875d16ac 100644 --- a/Documentation/ABI/testing/sysfs-class-uwb_rc +++ b/Documentation/ABI/testing/sysfs-class-uwb_rc @@ -43,6 +43,19 @@ Description: Reading returns the currently active channel, or -1 if the radio controller is not beaconing. +What: /sys/class/uwb_rc/uwbN/ASIE +Date: August 2014 +KernelVersion: 3.18 +Contact: linux-usb@vger.kernel.org +Description: + + The application-specific information element (ASIE) + included in this device's beacon, in space separated + hex octets. + + Reading returns the current ASIE. Writing replaces + the current ASIE with the one written. + What: /sys/class/uwb_rc/uwbN/scan Date: July 2008 KernelVersion: 2.6.27 diff --git a/Documentation/Changes b/Documentation/Changes index 227bec88021e..1de131bb49fb 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -167,18 +167,11 @@ later is recommended, due to some significant improvements). PCMCIAutils ----------- -PCMCIAutils replaces pcmcia-cs (see below). It properly sets up +PCMCIAutils replaces pcmcia-cs. It properly sets up PCMCIA sockets at system startup and loads the appropriate modules for 16-bit PCMCIA devices if the kernel is modularized and the hotplug subsystem is used. -Pcmcia-cs ---------- - -PCMCIA (PC Card) support is now partially implemented in the main -kernel source. The "pcmciautils" package (see above) replaces pcmcia-cs -for newest kernels. - Quota-tools ----------- @@ -341,17 +334,13 @@ Pcmciautils ----------- o <ftp://ftp.kernel.org/pub/linux/utils/kernel/pcmcia/> -Pcmcia-cs ---------- -o <http://pcmcia-cs.sourceforge.net/> - Quota-tools ---------- o <http://sourceforge.net/projects/linuxquota/> DocBook Stylesheets ------------------- -o <http://nwalsh.com/docbook/dsssl/> +o <http://sourceforge.net/projects/docbook/files/docbook-dsssl/> XMLTO XSLT Frontend ------------------- @@ -359,11 +348,11 @@ o <http://cyberelk.net/tim/xmlto/> Intel P6 microcode ------------------ -o <http://www.urbanmyth.org/microcode/> +o <https://downloadcenter.intel.com/> udev ---- -o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html> +o <http://www.freedesktop.org/software/systemd/man/udev.html> FUSE ---- @@ -371,7 +360,7 @@ o <http://sourceforge.net/projects/fuse> mcelog ------ -o <ftp://ftp.kernel.org/pub/linux/utils/cpu/mce/> +o <http://www.mcelog.org/> Networking ********** diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 6b6bef31e956..3171822c22a5 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -675,7 +675,7 @@ the ones already enabled by DEBUG. Many subsystems have Kconfig debug options to turn on -DDEBUG in the corresponding Makefile; in other cases specific files #define DEBUG. And when a debug message should be unconditionally printed, such as if it is -already inside a debug-related #ifdef secton, printk(KERN_DEBUG ...) can be +already inside a debug-related #ifdef section, printk(KERN_DEBUG ...) can be used. diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index dcbbe3602d78..0f7afb2bb442 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -531,7 +531,7 @@ To map a single region, you do: size_t size = buffer->len; dma_handle = dma_map_single(dev, addr, size, direction); - if (dma_mapping_error(dma_handle)) { + if (dma_mapping_error(dev, dma_handle)) { /* * reduce current DMA mapping usage, * delay and try again later or @@ -588,7 +588,7 @@ Specifically: size_t size = buffer->len; dma_handle = dma_map_page(dev, page, offset, size, direction); - if (dma_mapping_error(dma_handle)) { + if (dma_mapping_error(dev, dma_handle)) { /* * reduce current DMA mapping usage, * delay and try again later or @@ -689,7 +689,7 @@ to use the dma_sync_*() interfaces. dma_addr_t mapping; mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE); - if (dma_mapping_error(dma_handle)) { + if (dma_mapping_error(cp->dev, dma_handle)) { /* * reduce current DMA mapping usage, * delay and try again later or diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 71f6bf9e735e..8b5e014224d6 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -110,7 +110,7 @@ makes no provisions to find these related devices. Some really complex devices use the Media Controller (see <xref linkend="media_controller" />) which can be used for this purpose. But most drivers do not use it, and while some code exists that uses sysfs to discover related devices -(see libmedia_dev in the <ulink url="http://git.linuxtv.org/v4l-utils/">v4l-utils</ulink> +(see libmedia_dev in the <ulink url="http://git.linuxtv.org/cgit.cgi/v4l-utils.git/">v4l-utils</ulink> git repository), there is no library yet that can provide a single API towards both Media Controller-based devices and devices that do not use the Media Controller. If you want to work on this please write to the linux-media mailing list: &v4l-ml;.</para> diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index eee6f0f4aa43..3a626d1b8f2e 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2545,6 +2545,30 @@ fields changed from _s32 to _u32. </orderedlist> </section> + <section> + <title>V4L2 in Linux 3.16</title> + <orderedlist> + <listitem> + <para>Added event V4L2_EVENT_SOURCE_CHANGE. + </para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 3.17</title> + <orderedlist> + <listitem> + <para>Extended &v4l2-pix-format;. Added format flags. + </para> + </listitem> + <listitem> + <para>Added compound control types and &VIDIOC-QUERY-EXT-CTRL;. + </para> + </listitem> + </orderedlist> + </section> + <section id="other"> <title>Relation of V4L2 to other Linux multimedia APIs</title> diff --git a/Documentation/DocBook/media/v4l/func-poll.xml b/Documentation/DocBook/media/v4l/func-poll.xml index 85cad8bff5ba..4c73f115219b 100644 --- a/Documentation/DocBook/media/v4l/func-poll.xml +++ b/Documentation/DocBook/media/v4l/func-poll.xml @@ -29,9 +29,12 @@ can suspend execution until the driver has captured data or is ready to accept data for output.</para> <para>When streaming I/O has been negotiated this function waits -until a buffer has been filled or displayed and can be dequeued with -the &VIDIOC-DQBUF; ioctl. When buffers are already in the outgoing -queue of the driver the function returns immediately.</para> +until a buffer has been filled by the capture device and can be dequeued +with the &VIDIOC-DQBUF; ioctl. For output devices this function waits +until the device is ready to accept a new buffer to be queued up with +the &VIDIOC-QBUF; ioctl for display. When buffers are already in the outgoing +queue of the driver (capture) or the incoming queue isn't full (display) +the function returns immediately.</para> <para>On success <function>poll()</function> returns the number of file descriptors that have been selected (that is, file descriptors @@ -44,10 +47,22 @@ Capture devices set the <constant>POLLIN</constant> and flags. When the function timed out it returns a value of zero, on failure it returns <returnvalue>-1</returnvalue> and the <varname>errno</varname> variable is set appropriately. When the -application did not call &VIDIOC-QBUF; or &VIDIOC-STREAMON; yet the +application did not call &VIDIOC-STREAMON; the <function>poll()</function> function succeeds, but sets the <constant>POLLERR</constant> flag in the -<structfield>revents</structfield> field.</para> +<structfield>revents</structfield> field. When the +application has called &VIDIOC-STREAMON; for a capture device but hasn't +yet called &VIDIOC-QBUF;, the <function>poll()</function> function +succeeds and sets the <constant>POLLERR</constant> flag in the +<structfield>revents</structfield> field. For output devices this +same situation will cause <function>poll()</function> to succeed +as well, but it sets the <constant>POLLOUT</constant> and +<constant>POLLWRNORM</constant> flags in the <structfield>revents</structfield> +field.</para> + + <para>If an event occurred (see &VIDIOC-DQEVENT;) then +<constant>POLLPRI</constant> will be set in the <structfield>revents</structfield> +field and <function>poll()</function> will return.</para> <para>When use of the <function>read()</function> function has been negotiated and the driver does not capture yet, the @@ -58,10 +73,18 @@ continuously (as opposed to, for example, still images) the function may return immediately.</para> <para>When use of the <function>write()</function> function has -been negotiated the <function>poll</function> function just waits +been negotiated and the driver does not stream yet, the +<function>poll</function> function starts streaming. When that fails +it returns a <constant>POLLERR</constant> as above. Otherwise it waits until the driver is ready for a non-blocking <function>write()</function> call.</para> + <para>If the caller is only interested in events (just +<constant>POLLPRI</constant> is set in the <structfield>events</structfield> +field), then <function>poll()</function> will <emphasis>not</emphasis> +start streaming if the driver does not stream yet. This makes it +possible to just poll for events and not for buffers.</para> + <para>All drivers implementing the <function>read()</function> or <function>write()</function> function or streaming I/O must also support the <function>poll()</function> function.</para> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index f2f81f06a17b..7cfe618f754d 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -152,10 +152,11 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> <revision> - <revnumber>3.16</revnumber> - <date>2014-05-27</date> - <authorinitials>lp</authorinitials> - <revremark>Extended &v4l2-pix-format;. Added format flags. + <revnumber>3.17</revnumber> + <date>2014-08-04</date> + <authorinitials>lp, hv</authorinitials> + <revremark>Extended &v4l2-pix-format;. Added format flags. Added compound control types +and VIDIOC_QUERY_EXT_CTRL. </revremark> </revision> @@ -538,7 +539,7 @@ and discussions on the V4L mailing list.</revremark> </partinfo> <title>Video for Linux Two API Specification</title> - <subtitle>Revision 3.14</subtitle> + <subtitle>Revision 3.17</subtitle> <chapter id="common"> &sub-common; diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml index 1ba9e999af3f..c62a7360719b 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml @@ -119,7 +119,7 @@ </row> <row> <entry>&v4l2-rect;</entry> - <entry><structfield>rect</structfield></entry> + <entry><structfield>r</structfield></entry> <entry>Selection rectangle, in pixels.</entry> </row> <row> diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl index 85fc0e28576f..4cd5b2cd0f3d 100644 --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl @@ -593,7 +593,7 @@ for (;;) { Each device has one control endpoint (endpoint zero) which supports a limited RPC style RPC access. Devices are configured - by khubd (in the kernel) setting a device-wide + by hub_wq (in the kernel) setting a device-wide <emphasis>configuration</emphasis> that affects things like power consumption and basic functionality. The endpoints are part of USB <emphasis>interfaces</emphasis>, diff --git a/Documentation/Makefile b/Documentation/Makefile index 31d302bc5863..6883a1b9b351 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -1,3 +1,4 @@ -obj-m := DocBook/ accounting/ auxdisplay/ connector/ \ - filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \ - pcmcia/ spi/ timers/ watchdog/src/ misc-devices/mei/ +subdir-y := accounting arm auxdisplay blackfin connector \ + filesystems filesystems ia64 laptops mic misc-devices \ + networking pcmcia prctl ptp spi timers vDSO video4linux \ + watchdog diff --git a/Documentation/accounting/Makefile b/Documentation/accounting/Makefile index 31929eb875b1..7e232cb6fd7d 100644 --- a/Documentation/accounting/Makefile +++ b/Documentation/accounting/Makefile @@ -1,6 +1,3 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build hostprogs-y := getdelays diff --git a/Documentation/applying-patches.txt b/Documentation/applying-patches.txt index a083ba35d1ad..77df55b0225a 100644 --- a/Documentation/applying-patches.txt +++ b/Documentation/applying-patches.txt @@ -94,7 +94,7 @@ Common errors when patching --- When patch applies a patch file it attempts to verify the sanity of the file in different ways. -Checking that the file looks like a valid patch file & checking the code +Checking that the file looks like a valid patch file and checking the code around the bits being modified matches the context provided in the patch are just two of the basic sanity checks patch does. diff --git a/Documentation/arm/Makefile b/Documentation/arm/Makefile new file mode 100644 index 000000000000..732c77050cff --- /dev/null +++ b/Documentation/arm/Makefile @@ -0,0 +1 @@ +subdir-y := SH-Mobile diff --git a/Documentation/arm/SH-Mobile/.gitignore b/Documentation/arm/SH-Mobile/.gitignore new file mode 100644 index 000000000000..c928dbf3cc88 --- /dev/null +++ b/Documentation/arm/SH-Mobile/.gitignore @@ -0,0 +1 @@ +vrl4 diff --git a/Documentation/arm/SH-Mobile/Makefile b/Documentation/arm/SH-Mobile/Makefile index 8771d832cf8c..bca8a7ef6bbe 100644 --- a/Documentation/arm/SH-Mobile/Makefile +++ b/Documentation/arm/SH-Mobile/Makefile @@ -1,8 +1,7 @@ -BIN := vrl4 +# List of programs to build +hostprogs-y := vrl4 -.PHONY: all -all: $(BIN) +# Tell kbuild to always build the programs +always := $(hostprogs-y) -.PHONY: clean -clean: - rm -f *.o $(BIN) +HOSTCFLAGS_vrl4.o += -I$(objtree)/usr/include -I$(srctree)/tools/include diff --git a/Documentation/arm/SH-Mobile/vrl4.c b/Documentation/arm/SH-Mobile/vrl4.c index e8a191358ad2..f4cd8ad4e720 100644 --- a/Documentation/arm/SH-Mobile/vrl4.c +++ b/Documentation/arm/SH-Mobile/vrl4.c @@ -34,6 +34,7 @@ #include <stdint.h> #include <stdio.h> #include <errno.h> +#include <tools/endian.h> struct hdr { uint32_t magic1; @@ -77,7 +78,7 @@ struct hdr { #define ROUND_UP(x) ((x + ALIGN - 1) & ~(ALIGN - 1)) -ssize_t do_read(int fd, void *buf, size_t count) +static ssize_t do_read(int fd, void *buf, size_t count) { size_t offset = 0; ssize_t l; @@ -98,7 +99,7 @@ ssize_t do_read(int fd, void *buf, size_t count) return offset; } -ssize_t do_write(int fd, const void *buf, size_t count) +static ssize_t do_write(int fd, const void *buf, size_t count) { size_t offset = 0; ssize_t l; @@ -117,7 +118,7 @@ ssize_t do_write(int fd, const void *buf, size_t count) return offset; } -ssize_t write_zero(int fd, size_t len) +static ssize_t write_zero(int fd, size_t len) { size_t i = len; diff --git a/Documentation/auxdisplay/Makefile b/Documentation/auxdisplay/Makefile index 51fe23332c81..ada4dac99ef4 100644 --- a/Documentation/auxdisplay/Makefile +++ b/Documentation/auxdisplay/Makefile @@ -1,6 +1,3 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build hostprogs-y := cfag12864b-example diff --git a/Documentation/blackfin/Makefile b/Documentation/blackfin/Makefile index 773dbb103f1c..c7e6c99bad81 100644 --- a/Documentation/blackfin/Makefile +++ b/Documentation/blackfin/Makefile @@ -1,6 +1,3 @@ +ifneq ($(CONFIG_BLACKFIN),) obj-m := gptimers-example.o - -all: modules - -modules clean: - $(MAKE) -C ../.. SUBDIRS=$(PWD) $@ +endif diff --git a/Documentation/block/null_blk.txt b/Documentation/block/null_blk.txt index b2830b435895..2f6c6ff7161d 100644 --- a/Documentation/block/null_blk.txt +++ b/Documentation/block/null_blk.txt @@ -42,7 +42,7 @@ nr_devices=[Number of devices]: Default: 2 Number of block devices instantiated. They are instantiated as /dev/nullb0, etc. -irq_mode=[0-2]: Default: 1-Soft-irq +irqmode=[0-2]: Default: 1-Soft-irq The completion mode used for completing IOs to the block-layer. 0: None. @@ -53,7 +53,7 @@ irq_mode=[0-2]: Default: 1-Soft-irq completion. completion_nsec=[ns]: Default: 10.000ns - Combined with irq_mode=2 (timer). The time each completion event must wait. + Combined with irqmode=2 (timer). The time each completion event must wait. submit_queues=[0..nr_cpus]: The number of submission queues attached to the device driver. If unset, it diff --git a/Documentation/block/queue-sysfs.txt b/Documentation/block/queue-sysfs.txt index 7d2d046c265f..3a29f8914df9 100644 --- a/Documentation/block/queue-sysfs.txt +++ b/Documentation/block/queue-sysfs.txt @@ -11,7 +11,7 @@ read-write. add_random (RW) ---------------- -This file allows to trun off the disk entropy contribution. Default +This file allows to turn off the disk entropy contribution. Default value of this file is '1'(on). discard_granularity (RO) @@ -72,7 +72,7 @@ Maximum segment size of the device. minimum_io_size (RO) -------------------- -This is the smallest preferred io size reported by the device. +This is the smallest preferred IO size reported by the device. nomerges (RW) ------------- @@ -98,7 +98,7 @@ regulated by nr_requests. optimal_io_size (RO) -------------------- -This is the optimal io size reported by the device. +This is the optimal IO size reported by the device. physical_block_size (RO) ------------------------ diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 7740038d82bc..3c94ff3f9693 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt @@ -345,14 +345,14 @@ the named feature on. The implementation is simple. Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag -PF_SPREAD_PAGE for each task that is in that cpuset or subsequently +PFA_SPREAD_PAGE for each task that is in that cpuset or subsequently joins that cpuset. The page allocation calls for the page cache -is modified to perform an inline check for this PF_SPREAD_PAGE task +is modified to perform an inline check for this PFA_SPREAD_PAGE task flag, and if set, a call to a new routine cpuset_mem_spread_node() returns the node to prefer for the allocation. Similarly, setting 'cpuset.memory_spread_slab' turns on the flag -PF_SPREAD_SLAB, and appropriately marked slab caches will allocate +PFA_SPREAD_SLAB, and appropriately marked slab caches will allocate pages from the node returned by cpuset_mem_spread_node(). The cpuset_mem_spread_node() routine is also simple. It uses the diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 298e2f6b33c6..6fd0f15e899a 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -219,6 +219,12 @@ nodes to be present and contain the properties described below. Value type: <phandle> Definition: Specifies the ACC[2] node associated with this CPU. + - cpu-idle-states + Usage: Optional + Value type: <prop-encoded-array> + Definition: + # List of phandles to idle state nodes supported + by this cpu [3]. Example 1 (dual-cluster big.LITTLE system 32-bit): @@ -415,3 +421,5 @@ cpus { -- [1] arm/msm/qcom,saw2.txt [2] arm/msm/qcom,kpss-acc.txt +[3] ARM Linux kernel documentation - idle states bindings + Documentation/devicetree/bindings/arm/idle-states.txt diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt new file mode 100644 index 000000000000..37375c7f3ccc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/idle-states.txt @@ -0,0 +1,679 @@ +========================================== +ARM idle states binding description +========================================== + +========================================== +1 - Introduction +========================================== + +ARM systems contain HW capable of managing power consumption dynamically, +where cores can be put in different low-power states (ranging from simple +wfi to power gating) according to OS PM policies. The CPU states representing +the range of dynamic idle states that a processor can enter at run-time, can be +specified through device tree bindings representing the parameters required +to enter/exit specific idle states on a given processor. + +According to the Server Base System Architecture document (SBSA, [3]), the +power states an ARM CPU can be put into are identified by the following list: + +- Running +- Idle_standby +- Idle_retention +- Sleep +- Off + +The power states described in the SBSA document define the basic CPU states on +top of which ARM platforms implement power management schemes that allow an OS +PM implementation to put the processor in different idle states (which include +states listed above; "off" state is not an idle state since it does not have +wake-up capabilities, hence it is not considered in this document). + +Idle state parameters (eg entry latency) are platform specific and need to be +characterized with bindings that provide the required information to OS PM +code so that it can build the required tables and use them at runtime. + +The device tree binding definition for ARM idle states is the subject of this +document. + +=========================================== +2 - idle-states definitions +=========================================== + +Idle states are characterized for a specific system through a set of +timing and energy related properties, that underline the HW behaviour +triggered upon idle states entry and exit. + +The following diagram depicts the CPU execution phases and related timing +properties required to enter and exit an idle state: + +..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__.. + | | | | | + + |<------ entry ------->| + | latency | + |<- exit ->| + | latency | + |<-------- min-residency -------->| + |<------- wakeup-latency ------->| + + Diagram 1: CPU idle state execution phases + +EXEC: Normal CPU execution. + +PREP: Preparation phase before committing the hardware to idle mode + like cache flushing. This is abortable on pending wake-up + event conditions. The abort latency is assumed to be negligible + (i.e. less than the ENTRY + EXIT duration). If aborted, CPU + goes back to EXEC. This phase is optional. If not abortable, + this should be included in the ENTRY phase instead. + +ENTRY: The hardware is committed to idle mode. This period must run + to completion up to IDLE before anything else can happen. + +IDLE: This is the actual energy-saving idle period. This may last + between 0 and infinite time, until a wake-up event occurs. + +EXIT: Period during which the CPU is brought back to operational + mode (EXEC). + +entry-latency: Worst case latency required to enter the idle state. The +exit-latency may be guaranteed only after entry-latency has passed. + +min-residency: Minimum period, including preparation and entry, for a given +idle state to be worthwhile energywise. + +wakeup-latency: Maximum delay between the signaling of a wake-up event and the +CPU being able to execute normal code again. If not specified, this is assumed +to be entry-latency + exit-latency. + +These timing parameters can be used by an OS in different circumstances. + +An idle CPU requires the expected min-residency time to select the most +appropriate idle state based on the expected expiry time of the next IRQ +(ie wake-up) that causes the CPU to return to the EXEC phase. + +An operating system scheduler may need to compute the shortest wake-up delay +for CPUs in the system by detecting how long will it take to get a CPU out +of an idle state, eg: + +wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0) + +In other words, the scheduler can make its scheduling decision by selecting +(eg waking-up) the CPU with the shortest wake-up latency. +The wake-up latency must take into account the entry latency if that period +has not expired. The abortable nature of the PREP period can be ignored +if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than +the worst case since it depends on the CPU operating conditions, ie caches +state). + +An OS has to reliably probe the wakeup-latency since some devices can enforce +latency constraints guarantees to work properly, so the OS has to detect the +worst case wake-up latency it can incur if a CPU is allowed to enter an +idle state, and possibly to prevent that to guarantee reliable device +functioning. + +The min-residency time parameter deserves further explanation since it is +expressed in time units but must factor in energy consumption coefficients. + +The energy consumption of a cpu when it enters a power state can be roughly +characterised by the following graph: + + | + | + | + e | + n | /--- + e | /------ + r | /------ + g | /----- + y | /------ + | ---- + | /| + | / | + | / | + | / | + | / | + | / | + |/ | + -----|-------+---------------------------------- + 0| 1 time(ms) + + Graph 1: Energy vs time example + +The graph is split in two parts delimited by time 1ms on the X-axis. +The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope +and denotes the energy costs incurred whilst entering and leaving the idle +state. +The graph curve in the area delimited by X-axis values = {x | x > 1ms } has +shallower slope and essentially represents the energy consumption of the idle +state. + +min-residency is defined for a given idle state as the minimum expected +residency time for a state (inclusive of preparation and entry) after +which choosing that state become the most energy efficient option. A good +way to visualise this, is by taking the same graph above and comparing some +states energy consumptions plots. + +For sake of simplicity, let's consider a system with two idle states IDLE1, +and IDLE2: + + | + | + | + | /-- IDLE1 + e | /--- + n | /---- + e | /--- + r | /-----/--------- IDLE2 + g | /-------/--------- + y | ------------ /---| + | / /---- | + | / /--- | + | / /---- | + | / /--- | + | --- | + | / | + | / | + |/ | time + ---/----------------------------+------------------------ + |IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy + | + IDLE2-min-residency + + Graph 2: idle states min-residency example + +In graph 2 above, that takes into account idle states entry/exit energy +costs, it is clear that if the idle state residency time (ie time till next +wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state +choice energywise. + +This is mainly down to the fact that IDLE1 entry/exit energy costs are lower +than IDLE2. + +However, the lower power consumption (ie shallower energy curve slope) of idle +state IDLE2 implies that after a suitable time, IDLE2 becomes more energy +efficient. + +The time at which IDLE2 becomes more energy efficient than IDLE1 (and other +shallower states in a system with multiple idle states) is defined +IDLE2-min-residency and corresponds to the time when energy consumption of +IDLE1 and IDLE2 states breaks even. + +The definitions provided in this section underpin the idle states +properties specification that is the subject of the following sections. + +=========================================== +3 - idle-states node +=========================================== + +ARM processor idle states are defined within the idle-states node, which is +a direct child of the cpus node [1] and provides a container where the +processor idle states, defined as device tree nodes, are listed. + +- idle-states node + + Usage: Optional - On ARM systems, it is a container of processor idle + states nodes. If the system does not provide CPU + power management capabilities or the processor just + supports idle_standby an idle-states node is not + required. + + Description: idle-states node is a container node, where its + subnodes describe the CPU idle states. + + Node name must be "idle-states". + + The idle-states node's parent node must be the cpus node. + + The idle-states node's child nodes can be: + + - one or more state nodes + + Any other configuration is considered invalid. + + An idle-states node defines the following properties: + + - entry-method + Value type: <stringlist> + Usage and definition depend on ARM architecture version. + # On ARM v8 64-bit this property is required and must + be one of: + - "psci" (see bindings in [2]) + # On ARM 32-bit systems this property is optional + +The nodes describing the idle states (state) can only be defined within the +idle-states node, any other configuration is considered invalid and therefore +must be ignored. + +=========================================== +4 - state node +=========================================== + +A state node represents an idle state description and must be defined as +follows: + +- state node + + Description: must be child of the idle-states node + + The state node name shall follow standard device tree naming + rules ([5], 2.2.1 "Node names"), in particular state nodes which + are siblings within a single common parent must be given a unique name. + + The idle state entered by executing the wfi instruction (idle_standby + SBSA,[3][4]) is considered standard on all ARM platforms and therefore + must not be listed. + + With the definitions provided above, the following list represents + the valid properties for a state node: + + - compatible + Usage: Required + Value type: <stringlist> + Definition: Must be "arm,idle-state". + + - local-timer-stop + Usage: See definition + Value type: <none> + Definition: if present the CPU local timer control logic is + lost on state entry, otherwise it is retained. + + - entry-latency-us + Usage: Required + Value type: <prop-encoded-array> + Definition: u32 value representing worst case latency in + microseconds required to enter the idle state. + The exit-latency-us duration may be guaranteed + only after entry-latency-us has passed. + + - exit-latency-us + Usage: Required + Value type: <prop-encoded-array> + Definition: u32 value representing worst case latency + in microseconds required to exit the idle state. + + - min-residency-us + Usage: Required + Value type: <prop-encoded-array> + Definition: u32 value representing minimum residency duration + in microseconds, inclusive of preparation and + entry, for this idle state to be considered + worthwhile energy wise (refer to section 2 of + this document for a complete description). + + - wakeup-latency-us: + Usage: Optional + Value type: <prop-encoded-array> + Definition: u32 value representing maximum delay between the + signaling of a wake-up event and the CPU being + able to execute normal code again. If omitted, + this is assumed to be equal to: + + entry-latency-us + exit-latency-us + + It is important to supply this value on systems + where the duration of PREP phase (see diagram 1, + section 2) is non-neglibigle. + In such systems entry-latency-us + exit-latency-us + will exceed wakeup-latency-us by this duration. + + In addition to the properties listed above, a state node may require + additional properties specifics to the entry-method defined in the + idle-states node, please refer to the entry-method bindings + documentation for properties definitions. + +=========================================== +4 - Examples +=========================================== + +Example 1 (ARM 64-bit, 16-cpu system, PSCI enable-method): + +cpus { + #size-cells = <0>; + #address-cells = <2>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x0>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x1>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + CPU4: cpu@10000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10000>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + CPU5: cpu@10001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10001>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + CPU6: cpu@10100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + CPU7: cpu@10101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 + &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + }; + + CPU8: cpu@100000000 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x0>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + CPU9: cpu@100000001 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x1>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + CPU10: cpu@100000100 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + CPU11: cpu@100000101 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + CPU12: cpu@100010000 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x10000>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + CPU13: cpu@100010001 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x10001>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + CPU14: cpu@100010100 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x10100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + CPU15: cpu@100010101 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1 0x10101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 + &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + }; + + idle-states { + entry-method = "arm,psci"; + + CPU_RETENTION_0_0: cpu-retention-0-0 { + compatible = "arm,idle-state"; + arm,psci-suspend-param = <0x0010000>; + entry-latency-us = <20>; + exit-latency-us = <40>; + min-residency-us = <80>; + }; + + CLUSTER_RETENTION_0: cluster-retention-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x1010000>; + entry-latency-us = <50>; + exit-latency-us = <100>; + min-residency-us = <250>; + wakeup-latency-us = <130>; + }; + + CPU_SLEEP_0_0: cpu-sleep-0-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x0010000>; + entry-latency-us = <250>; + exit-latency-us = <500>; + min-residency-us = <950>; + }; + + CLUSTER_SLEEP_0: cluster-sleep-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x1010000>; + entry-latency-us = <600>; + exit-latency-us = <1100>; + min-residency-us = <2700>; + wakeup-latency-us = <1500>; + }; + + CPU_RETENTION_1_0: cpu-retention-1-0 { + compatible = "arm,idle-state"; + arm,psci-suspend-param = <0x0010000>; + entry-latency-us = <20>; + exit-latency-us = <40>; + min-residency-us = <90>; + }; + + CLUSTER_RETENTION_1: cluster-retention-1 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x1010000>; + entry-latency-us = <50>; + exit-latency-us = <100>; + min-residency-us = <270>; + wakeup-latency-us = <100>; + }; + + CPU_SLEEP_1_0: cpu-sleep-1-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x0010000>; + entry-latency-us = <70>; + exit-latency-us = <100>; + min-residency-us = <300>; + wakeup-latency-us = <150>; + }; + + CLUSTER_SLEEP_1: cluster-sleep-1 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x1010000>; + entry-latency-us = <500>; + exit-latency-us = <1200>; + min-residency-us = <3500>; + wakeup-latency-us = <1300>; + }; + }; + +}; + +Example 2 (ARM 32-bit, 8-cpu system, two clusters): + +cpus { + #size-cells = <0>; + #address-cells = <1>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x0>; + cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x1>; + cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>; + }; + + CPU2: cpu@2 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x2>; + cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>; + }; + + CPU3: cpu@3 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x3>; + cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>; + }; + + CPU4: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x100>; + cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>; + }; + + CPU5: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x101>; + cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>; + }; + + CPU6: cpu@102 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x102>; + cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>; + }; + + CPU7: cpu@103 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x103>; + cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>; + }; + + idle-states { + CPU_SLEEP_0_0: cpu-sleep-0-0 { + compatible = "arm,idle-state"; + local-timer-stop; + entry-latency-us = <200>; + exit-latency-us = <100>; + min-residency-us = <400>; + wakeup-latency-us = <250>; + }; + + CLUSTER_SLEEP_0: cluster-sleep-0 { + compatible = "arm,idle-state"; + local-timer-stop; + entry-latency-us = <500>; + exit-latency-us = <1500>; + min-residency-us = <2500>; + wakeup-latency-us = <1700>; + }; + + CPU_SLEEP_1_0: cpu-sleep-1-0 { + compatible = "arm,idle-state"; + local-timer-stop; + entry-latency-us = <300>; + exit-latency-us = <500>; + min-residency-us = <900>; + wakeup-latency-us = <600>; + }; + + CLUSTER_SLEEP_1: cluster-sleep-1 { + compatible = "arm,idle-state"; + local-timer-stop; + entry-latency-us = <800>; + exit-latency-us = <2000>; + min-residency-us = <6500>; + wakeup-latency-us = <2300>; + }; + }; + +}; + +=========================================== +5 - References +=========================================== + +[1] ARM Linux Kernel documentation - CPUs bindings + Documentation/devicetree/bindings/arm/cpus.txt + +[2] ARM Linux Kernel documentation - PSCI bindings + Documentation/devicetree/bindings/arm/psci.txt + +[3] ARM Server Base System Architecture (SBSA) + http://infocenter.arm.com/help/index.jsp + +[4] ARM Architecture Reference Manuals + http://infocenter.arm.com/help/index.jsp + +[5] ePAPR standard + https://www.power.org/documentation/epapr-version-1-1/ diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt index af527ee111c2..292ef7ca3058 100644 --- a/Documentation/devicetree/bindings/arm/l2cc.txt +++ b/Documentation/devicetree/bindings/arm/l2cc.txt @@ -2,6 +2,10 @@ ARM cores often have a separate level 2 cache controller. There are various implementations of the L2 cache controller with compatible programming models. +Some of the properties that are just prefixed "cache-*" are taken from section +3.7.3 of the ePAPR v1.1 specification which can be found at: +https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf + The ARM L2 cache representation in the device tree should be done as follows: Required properties: @@ -44,6 +48,12 @@ Optional properties: I/O coherent mode. Valid only when the arm,pl310-cache compatible string is used. - interrupts : 1 combined interrupt. +- cache-size : specifies the size in bytes of the cache +- cache-sets : specifies the number of associativity sets of the cache +- cache-block-size : specifies the size in bytes of a cache block +- cache-line-size : specifies the size in bytes of a line in the cache, + if this is not specified, the line size is assumed to be equal to the + cache block size - cache-id-part: cache id part number to be used if it is not present on hardware - wt-override: If present then L2 is forced to Write through mode diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt index b4a58f39223c..5aa40ede0e99 100644 --- a/Documentation/devicetree/bindings/arm/psci.txt +++ b/Documentation/devicetree/bindings/arm/psci.txt @@ -50,6 +50,16 @@ Main node optional properties: - migrate : Function ID for MIGRATE operation +Device tree nodes that require usage of PSCI CPU_SUSPEND function (ie idle +state nodes, as per bindings in [1]) must specify the following properties: + +- arm,psci-suspend-param + Usage: Required for state nodes[1] if the corresponding + idle-states node entry-method property is set + to "psci". + Value type: <u32> + Definition: power_state parameter to pass to the PSCI + suspend call. Example: @@ -64,7 +74,6 @@ Case 1: PSCI v0.1 only. migrate = <0x95c10003>; }; - Case 2: PSCI v0.2 only psci { @@ -88,3 +97,6 @@ Case 3: PSCI v0.2 and PSCI v0.1. ... }; + +[1] Kernel documentation - ARM idle states bindings + Documentation/devicetree/bindings/arm/idle-states.txt diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt index adc61b095bd1..709efaa30841 100644 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt @@ -11,13 +11,25 @@ New driver handles the following Required properties: - compatible: Must be "samsung,exynos-adc-v1" - for exynos4412/5250 controllers. + for exynos4412/5250 and s5pv210 controllers. Must be "samsung,exynos-adc-v2" for future controllers. Must be "samsung,exynos3250-adc" for controllers compatible with ADC of Exynos3250. -- reg: Contains ADC register address range (base address and - length) and the address of the phy enable register. + Must be "samsung,s3c2410-adc" for + the ADC in s3c2410 and compatibles + Must be "samsung,s3c2416-adc" for + the ADC in s3c2416 and compatibles + Must be "samsung,s3c2440-adc" for + the ADC in s3c2440 and compatibles + Must be "samsung,s3c2443-adc" for + the ADC in s3c2443 and compatibles + Must be "samsung,s3c6410-adc" for + the ADC in s3c6410 and compatibles +- reg: List of ADC register address range + - The base address and range of ADC register + - The base address and range of ADC_PHY register (every + SoC except for s3c24xx/s3c64xx ADC) - interrupts: Contains the interrupt information for the timer. The format is being dependent on which interrupt controller the Samsung device uses. diff --git a/Documentation/devicetree/bindings/clock/arm-integrator.txt b/Documentation/devicetree/bindings/clock/arm-integrator.txt index ecc69520bcea..11f5f95f571b 100644 --- a/Documentation/devicetree/bindings/clock/arm-integrator.txt +++ b/Documentation/devicetree/bindings/clock/arm-integrator.txt @@ -1,6 +1,6 @@ Clock bindings for ARM Integrator and Versatile Core Module clocks -Auxilary Oscillator Clock +Auxiliary Oscillator Clock This is a configurable clock fed from a 24 MHz chrystal, used for generating e.g. video clocks. It is located on the diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec6.txt b/Documentation/devicetree/bindings/crypto/fsl-sec6.txt index c0a20cd972e3..baf8a3c1b469 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-sec6.txt +++ b/Documentation/devicetree/bindings/crypto/fsl-sec6.txt @@ -1,5 +1,5 @@ SEC 6 is as Freescale's Cryptographic Accelerator and Assurance Module (CAAM). -Currently Freescale powerpc chip C29X is embeded with SEC 6. +Currently Freescale powerpc chip C29X is embedded with SEC 6. SEC 6 device tree binding include: -SEC 6 Node -Job Ring Node diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt new file mode 100644 index 000000000000..5d3ec1df226d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt @@ -0,0 +1,24 @@ +Rockchip Successive Approximation Register (SAR) A/D Converter bindings + +Required properties: +- compatible: Should be "rockchip,saradc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: The interrupt number to the cpu. The interrupt specifier format + depends on the interrupt controller. +- clocks: Must contain an entry for each entry in clock-names. +- clock-names: Shall be "saradc" for the converter-clock, and "apb_pclk" for + the peripheral clock. +- vref-supply: The regulator supply ADC reference voltage. +- #io-channel-cells: Should be 1, see ../iio-bindings.txt + +Example: + saradc: saradc@2006c000 { + compatible = "rockchip,saradc"; + reg = <0x2006c000 0x100>; + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>; + clock-names = "saradc", "apb_pclk"; + #io-channel-cells = <1>; + vref-supply = <&vcc18>; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt index dcebff1928e1..1a4a43d5c9ea 100644 --- a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt +++ b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt @@ -9,7 +9,7 @@ Required properties: - interrupts: Should contain the interrupt for the device - clocks: The clock is needed by the ADC controller, ADC clock source is ipg clock. - clock-names: Must contain "adc", matching entry in the clocks property. -- vref-supply: The regulator supply ADC refrence voltage. +- vref-supply: The regulator supply ADC reference voltage. Example: adc0: adc@4003b000 { diff --git a/Documentation/devicetree/bindings/iio/dac/max5821.txt b/Documentation/devicetree/bindings/iio/dac/max5821.txt new file mode 100644 index 000000000000..54276ce8c971 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/max5821.txt @@ -0,0 +1,14 @@ +Maxim max5821 DAC device driver + +Required properties: + - compatible: Must be "maxim,max5821" + - reg: Should contain the DAC I2C address + - vref-supply: Phandle to the vref power supply + +Example: + + max5821@38 { + compatible = "maxim,max5821"; + reg = <0x38>; + vref-supply = <®_max5821>; + }; diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt index 0ac23f2ed104..1852906517ab 100644 --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt @@ -11,10 +11,6 @@ Required properties: Optional properties for main touchpad device: -- linux,gpio-keymap: An array of up to 4 entries indicating the Linux - keycode generated by each GPIO. Linux keycodes are defined in - <dt-bindings/input/input.h>. - - linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages on GPIO bit changes. An array of up to 8 entries can be provided indicating the Linux keycode mapped to each bit of the status byte, diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt b/Documentation/devicetree/bindings/input/ti,drv260x.txt new file mode 100644 index 000000000000..ee09c8f4474a --- /dev/null +++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt @@ -0,0 +1,50 @@ +* Texas Instruments - drv260x Haptics driver family + +Required properties: + - compatible - One of: + "ti,drv2604" - DRV2604 + "ti,drv2605" - DRV2605 + "ti,drv2605l" - DRV2605L + - reg - I2C slave address + - vbat-supply - Required supply regulator + - mode - Power up mode of the chip (defined in include/dt-bindings/input/ti-drv260x.h) + DRV260X_LRA_MODE - Linear Resonance Actuator mode (Piezoelectric) + DRV260X_LRA_NO_CAL_MODE - This is a LRA Mode but there is no calibration + sequence during init. And the device is configured for real + time playback mode (RTP mode). + DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary vibrator) + - library-sel - These are ROM based waveforms pre-programmed into the IC. + This should be set to set the library to use at power up. + (defined in include/dt-bindings/input/ti-drv260x.h) + DRV260X_LIB_EMPTY - Do not use a pre-programmed library + DRV260X_ERM_LIB_A - Pre-programmed Library + DRV260X_ERM_LIB_B - Pre-programmed Library + DRV260X_ERM_LIB_C - Pre-programmed Library + DRV260X_ERM_LIB_D - Pre-programmed Library + DRV260X_ERM_LIB_E - Pre-programmed Library + DRV260X_ERM_LIB_F - Pre-programmed Library + DRV260X_LIB_LRA - Pre-programmed LRA Library + +Optional properties: + - enable-gpio - gpio pin to enable/disable the device. + - vib-rated-mv - The rated voltage of the actuator in millivolts. + If this is not set then the value will be defaulted to + 3.2 v. + - vib-overdrive-mv - The overdrive voltage of the actuator in millivolts. + If this is not set then the value will be defaulted to + 3.2 v. +Example: + +haptics: haptics@5a { + compatible = "ti,drv2605l"; + reg = <0x5a>; + vbat-supply = <&vbat>; + enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>; + mode = <DRV260X_LRA_MODE>; + library-sel = <DRV260X_LIB_LRA>; + vib-rated-mv = <3200>; + vib-overdriver-mv = <3200>; +} + +For more product information please see the link below: +http://www.ti.com/product/drv2605 diff --git a/Documentation/devicetree/bindings/input/ti,drv2667.txt b/Documentation/devicetree/bindings/input/ti,drv2667.txt new file mode 100644 index 000000000000..996382cf994a --- /dev/null +++ b/Documentation/devicetree/bindings/input/ti,drv2667.txt @@ -0,0 +1,17 @@ +* Texas Instruments - drv2667 Haptics driver + +Required properties: + - compatible - "ti,drv2667" - DRV2667 + - reg - I2C slave address + - vbat-supply - Required supply regulator + +Example: + +haptics: haptics@59 { + compatible = "ti,drv2667"; + reg = <0x59>; + vbat-supply = <&vbat>; +}; + +For more product information please see the link below: +http://www.ti.com/product/drv2667 diff --git a/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt b/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt new file mode 100644 index 000000000000..a3dde8c30e67 --- /dev/null +++ b/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt @@ -0,0 +1,36 @@ +Texas Instruments Palmas family power button module + +This module is part of the Palmas family of PMICs. For more details +about the whole chip see: +Documentation/devicetree/bindings/mfd/palmas.txt. + +This module provides a simple power button event via an Interrupt. + +Required properties: +- compatible: should be one of the following + - "ti,palmas-pwrbutton": For Palmas compatible power on button +- interrupt-parent: Parent interrupt device, must be handle of palmas node. +- interrupts: Interrupt number of power button submodule on device. + +Optional Properties: + +- ti,palmas-long-press-seconds: Duration in seconds which the power + button should be kept pressed for Palmas to power off automatically. + NOTE: This depends on OTP support and POWERHOLD signal configuration + on platform. Valid values are 6, 8, 10 and 12. +- ti,palmas-pwron-debounce-milli-seconds: Duration in milliseconds + which the power button should be kept pressed for Palmas to register + a press for debouncing purposes. NOTE: This depends on specific + Palmas variation capability. Valid values are 15, 100, 500 and 1000. + +Example: + +&palmas { + palmas_pwr_button: pwrbutton { + compatible = "ti,palmas-pwrbutton"; + interrupt-parent = <&tps659038>; + interrupts = <1 IRQ_TYPE_EDGE_FALLING>; + ti,palmas-long-press-seconds = <12>; + ti,palmas-pwron-debounce-milli-seconds = <15>; + }; +}; diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index ba2d7f0f9c5f..0e4026a6cbbf 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -47,7 +47,7 @@ sub-node should be of the format as listed below. regulator-ramp-delay for BUCKs = [6250/12500/25000(default)/50000] uV/us - BUCK[2/3/4/6] supports disabling ramp delay on hardware, so explictly + BUCK[2/3/4/6] supports disabling ramp delay on hardware, so explicitly regulator-ramp-delay = <0> can be used for them to disable ramp delay. In the absence of the regulator-ramp-delay property, the default ramp delay will be used. diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index ee654e95d8ad..fb733c4e1c11 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -110,8 +110,8 @@ on various other factors also like; Other factor which governs the selection of ecc-scheme is oob-size. Higher ECC schemes require more OOB/Spare area to store ECC syndrome, so the device should have enough free bytes available its OOB/Spare - area to accomodate ECC for entire page. In general following expression - helps in determining if given device can accomodate ECC syndrome: + area to accommodate ECC for entire page. In general following expression + helps in determining if given device can accommodate ECC syndrome: "2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE" where OOBSIZE number of bytes in OOB/spare area @@ -133,5 +133,5 @@ on various other factors also like; Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 and trying to use BCH16 (ECC_BYTES=26) ecc-scheme. Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B - which can be accomodate in the OOB/Spare area of this device + which can be accommodated in the OOB/Spare area of this device (OOBSIZE=128). So this device can use BCH16 ecc-scheme. diff --git a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt index 989f6c95cfd5..888c250197fe 100644 --- a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt +++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt @@ -17,7 +17,7 @@ Required properties: - samsung,pbl: Integer, Programmable Burst Length. Supported values are 1, 2, 4, 8, 16, or 32. - samsung,burst-map: Integer, Program the possible bursts supported by sxgbe - This is an interger and represents allowable DMA bursts when fixed burst. + This is an integer and represents allowable DMA bursts when fixed burst. Allowable range is 0x01-0x3F. When this field is set fixed burst is enabled. When fixed length is needed for burst mode, it can be set within allowable range. diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index e45ac3f926b1..c41afd963edf 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -58,5 +58,5 @@ Examples: snps,multicast-filter-bins = <256>; snps,perfect-filter-entries = <128>; clocks = <&clock>; - clock-names = "stmmaceth">; + clock-names = "stmmaceth"; }; diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt b/Documentation/devicetree/bindings/pci/host-generic-pci.txt index f0b0436807b4..cf3e205e0b7e 100644 --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt @@ -55,7 +55,7 @@ For CAM, this 24-bit offset is: cfg_offset(bus, device, function, register) = bus << 16 | device << 11 | function << 8 | register -Whilst ECAM extends this by 4 bits to accomodate 4k of function space: +Whilst ECAM extends this by 4 bits to accommodate 4k of function space: cfg_offset(bus, device, function, register) = bus << 20 | device << 15 | function << 12 | register diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt index 2aa1840200ed..1293c321754c 100644 --- a/Documentation/devicetree/bindings/phy/phy-bindings.txt +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt @@ -27,7 +27,7 @@ phys: phy { }; That node describes an IP block (PHY provider) that implements 2 different PHYs. -In order to differentiate between these 2 PHYs, an additonal specifier should be +In order to differentiate between these 2 PHYs, an additional specifier should be given while trying to get a reference to it. PHY user node diff --git a/Documentation/devicetree/bindings/phy/phy-stih407-usb.txt b/Documentation/devicetree/bindings/phy/phy-stih407-usb.txt new file mode 100644 index 000000000000..1ef8228db73b --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-stih407-usb.txt @@ -0,0 +1,30 @@ +ST STiH407 USB PHY controller + +This file documents the dt bindings for the usb picoPHY driver which is the PHY for both USB2 and USB3 +host controllers (when controlling usb2/1.1 devices) available on STiH407 SoC family from STMicroelectronics. + +Required properties: +- compatible : should be "st,stih407-usb2-phy" +- reg : contain the offset and length of the system configuration registers + used as glue logic to control & parameter phy +- reg-names : the names of the system configuration registers in "reg", should be "param" and "reg" +- st,syscfg : sysconfig register to manage phy parameter at driver level +- resets : list of phandle and reset specifier pairs. There should be two entries, one + for the whole phy and one for the port +- reset-names : list of reset signal names. Should be "global" and "port" +See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt +See: Documentation/devicetree/bindings/reset/reset.txt + +Example: + +usb2_picophy0: usbpicophy@f8 { + compatible = "st,stih407-usb2-phy"; + reg = <0xf8 0x04>, /* syscfg 5062 */ + <0xf4 0x04>; /* syscfg 5061 */ + reg-names = "param", "ctrl"; + #phy-cells = <0>; + st,syscfg = <&syscfg_core>; + resets = <&softreset STIH407_PICOPHY_SOFTRESET>, + <&picophyreset STIH407_PICOPHY0_RESET>; + reset-names = "global", "port"; +}; diff --git a/Documentation/devicetree/bindings/phy/phy-stih41x-usb.txt b/Documentation/devicetree/bindings/phy/phy-stih41x-usb.txt new file mode 100644 index 000000000000..00944a05ee6b --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-stih41x-usb.txt @@ -0,0 +1,24 @@ +STMicroelectronics STiH41x USB PHY binding +------------------------------------------ + +This file contains documentation for the usb phy found in STiH415/6 SoCs from +STMicroelectronics. + +Required properties: +- compatible : should be "st,stih416-usb-phy" or "st,stih415-usb-phy" +- st,syscfg : should be a phandle of the syscfg node +- clock-names : must contain "osc_phy" +- clocks : must contain an entry for each name in clock-names. +See: Documentation/devicetree/bindings/clock/clock-bindings.txt +- #phy-cells : must be 0 for this phy +See: Documentation/devicetree/bindings/phy/phy-bindings.txt + +Example: + +usb2_phy: usb2phy@0 { + compatible = "st,stih416-usb-phy"; + #phy-cell = <0>; + st,syscfg = <&syscfg_rear>; + clocks = <&clk_sysin>; + clock-names = "osc_phy"; +}; diff --git a/Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt b/Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt new file mode 100644 index 000000000000..86f2dbe07ed4 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt @@ -0,0 +1,39 @@ +Qualcomm DWC3 HS AND SS PHY CONTROLLER +-------------------------------------- + +DWC3 PHY nodes are defined to describe on-chip Synopsis Physical layer +controllers. Each DWC3 PHY controller should have its own node. + +Required properties: +- compatible: should contain one of the following: + - "qcom,dwc3-hs-usb-phy" for High Speed Synopsis PHY controller + - "qcom,dwc3-ss-usb-phy" for Super Speed Synopsis PHY controller +- reg: offset and length of the DWC3 PHY controller register set +- #phy-cells: must be zero +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. +- clock-names: Should contain "ref" for the PHY reference clock + +Optional clocks: + "xo" External reference clock + +Example: + phy@100f8800 { + compatible = "qcom,dwc3-hs-usb-phy"; + reg = <0x100f8800 0x30>; + clocks = <&gcc USB30_0_UTMI_CLK>; + clock-names = "ref"; + #phy-cells = <0>; + + status = "ok"; + }; + + phy@100f8830 { + compatible = "qcom,dwc3-ss-usb-phy"; + reg = <0x100f8830 0x30>; + clocks = <&gcc USB30_0_MASTER_CLK>; + clock-names = "ref"; + #phy-cells = <0>; + + status = "ok"; + }; diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt new file mode 100644 index 000000000000..00fc52a034b7 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt @@ -0,0 +1,51 @@ +* Renesas R-Car generation 2 USB PHY + +This file provides information on what the device node for the R-Car generation +2 USB PHY contains. + +Required properties: +- compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC. + "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC. +- reg: offset and length of the register block. +- #address-cells: number of address cells for the USB channel subnodes, must + be <1>. +- #size-cells: number of size cells for the USB channel subnodes, must be <0>. +- clocks: clock phandle and specifier pair. +- clock-names: string, clock input name, must be "usbhs". + +The USB PHY device tree node should have the subnodes corresponding to the USB +channels. These subnodes must contain the following properties: +- reg: the USB controller selector; see the table below for the values. +- #phy-cells: see phy-bindings.txt in the same directory, must be <1>. + +The phandle's argument in the PHY specifier is the USB controller selector for +the USB channel; see the selector meanings below: + ++-----------+---------------+---------------+ +|\ Selector | | | ++ --------- + 0 | 1 | +| Channel \| | | ++-----------+---------------+---------------+ +| 0 | PCI EHCI/OHCI | HS-USB | +| 2 | PCI EHCI/OHCI | xHCI | ++-----------+---------------+---------------+ + +Example (Lager board): + + usb-phy@e6590100 { + compatible = "renesas,usb-phy-r8a7790"; + reg = <0 0xe6590100 0 0x100>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&mstp7_clks R8A7790_CLK_HSUSB>; + clock-names = "usbhs"; + + usb-channel@0 { + reg = <0>; + #phy-cells = <1>; + }; + usb-channel@2 { + reg = <2>; + #phy-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 7a6feea2a48b..15e0f2c7130f 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY ------------------------------------------------- Required properties: -- compatible : should be "samsung,exynos5250-dp-video-phy"; -- reg : offset and length of the Display Port PHY register set; +- compatible : should be one of the following supported values: + - "samsung,exynos5250-dp-video-phy" + - "samsung,exynos5420-dp-video-phy" +- samsung,pmu-syscon: phandle for PMU system controller interface, used to + control pmu registers for power isolation. - #phy-cells : from the generic PHY bindings, must be 0; Samsung S5P/EXYNOS SoC series USB PHY diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt index 02ab5ab198a4..b7a93e80a302 100644 --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt @@ -19,6 +19,7 @@ such as pull-up, multi drive, etc. Required properties for iomux controller: - compatible: "atmel,at91rm9200-pinctrl" or "atmel,at91sam9x5-pinctrl" + or "atmel,sama5d3-pinctrl" - atmel,mux-mask: array of mask (periph per bank) to describe if a pin can be configured in this periph mode. All the periph and bank need to be describe. @@ -85,13 +86,20 @@ Required properties for pin configuration node: PIN_BANK 0 is pioA, PIN_BANK 1 is pioB... Bits used for CONFIG: -PULL_UP (1 << 0): indicate this pin need a pull up. -MULTIDRIVE (1 << 1): indicate this pin need to be configured as multidrive. -DEGLITCH (1 << 2): indicate this pin need deglitch. -PULL_DOWN (1 << 3): indicate this pin need a pull down. -DIS_SCHMIT (1 << 4): indicate this pin need to disable schmit trigger. -DEBOUNCE (1 << 16): indicate this pin need debounce. -DEBOUNCE_VAL (0x3fff << 17): debounce val. +PULL_UP (1 << 0): indicate this pin needs a pull up. +MULTIDRIVE (1 << 1): indicate this pin needs to be configured as multi-drive. + Multi-drive is equivalent to open-drain type output. +DEGLITCH (1 << 2): indicate this pin needs deglitch. +PULL_DOWN (1 << 3): indicate this pin needs a pull down. +DIS_SCHMIT (1 << 4): indicate this pin needs to the disable schmitt trigger. +DRIVE_STRENGTH (3 << 5): indicate the drive strength of the pin using the + following values: + 00 - No change (reset state value kept) + 01 - Low + 10 - Medium + 11 - High +DEBOUNCE (1 << 16): indicate this pin needs debounce. +DEBOUNCE_VAL (0x3fff << 17): debounce value. NOTE: Some requirements for using atmel,at91rm9200-pinctrl binding: diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt index 6464bf769460..189814e7cdc7 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt @@ -10,6 +10,7 @@ Required properties: - reg: Should contain a list of base address and size pairs for: -- first entry - the drive strength and pad control registers. -- second entry - the pinmux registers + -- third entry - the MIPI_PAD_CTRL register Tegra124 adds the following optional properties for pin configuration subnodes. The macros for options are defined in the @@ -91,6 +92,12 @@ Valid values for pin and group names are: dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg, gmh, owr, uda, gpv, dev3, cec, usb_vbus_en, ao3, ao0, hv0, sdio4, ao4. + MIPI pad control groups: + + These support only the nvidia,function property. + + dsi_b + Valid values for nvidia,functions are: blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3, displaya, @@ -101,14 +108,15 @@ Valid values for nvidia,functions are: sdmmc4, soc, spdif, spi1, spi2, spi3, spi4, spi5, spi6, trace, uarta, uartb, uartc, uartd, ulpi, usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6, vi, vi_alt1, vi_alt3, vimclk2, vimclk2_alt, sata, ccla, pe0, pe, pe1, - dp, rtck, sys, clk tmds. + dp, rtck, sys, clk tmds, csi, dsi_b Example: pinmux: pinmux { compatible = "nvidia,tegra124-pinmux"; - reg = <0x70000868 0x164 /* Pad control registers */ - 0x70003000 0x434>; /* PinMux registers */ + reg = <0x0 0x70000868 0x0 0x164>, /* Pad control registers */ + <0x0 0x70003000 0x0 0x434>, /* Mux registers */ + <0x0 0x70000820 0x0 0x8>; /* MIPI pad control */ }; Example pinmux entries: diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index fa40a177164c..98eb94d91a1c 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -127,6 +127,24 @@ whether there is any interaction between the child and intermediate parent nodes, is again defined entirely by the binding for the individual pin controller device. +== Generic pin multiplexing node content == + +pin multiplexing nodes: + +function - the mux function to select +groups - the list of groups to select with this function + +Example: + +state_0_node_a { + function = "uart0"; + groups = "u0rxtx", "u0rtscts"; +}; +state_1_node_a { + function = "spi0"; + groups = "spi0pins"; +}; + == Generic pin configuration node content == Many data items that are represented in a pin configuration node are common @@ -139,8 +157,12 @@ structure of the DT nodes that contain these properties. Supported generic properties are: pins - the list of pins that properties in the node - apply to -function - the mux function to select + apply to (either this or "group" has to be + specified) +group - the group to apply the properties to, if the driver + supports configuration of whole groups rather than + individual pins (either this or "pins" has to be + specified) bias-disable - disable any pin bias bias-high-impedance - high impedance mode ("third-state", "floating") bias-bus-hold - latch weakly @@ -163,6 +185,21 @@ output-low - set the pin to output mode with low level output-high - set the pin to output mode with high level slew-rate - set the slew rate +For example: + +state_0_node_a { + pins = "GPIO0_AJ5", "GPIO2_AH4"; /* CTS+RXD */ + bias-pull-up; +}; +state_1_node_a { + pins = "GPIO1_AJ3", "GPIO3_AH3"; /* RTS+TXD */ + output-high; +}; +state_2_node_a { + group = "foo-group"; + bias-pull-up; +}; + Some of the generic properties take arguments. For those that do, the arguments are described below. @@ -170,15 +207,6 @@ arguments are described below. binding for the hardware defines: - Whether the entries are integers or strings, and their meaning. -- function takes a list of function names/IDs as a required argument. The - specific binding for the hardware defines: - - Whether the entries are integers or strings, and their meaning. - - Whether only a single entry is allowed (which is applied to all entries - in the pins property), or whether there may alternatively be one entry per - entry in the pins property, in which case the list lengths must match, and - for each list index i, the function at list index i is applied to the pin - at list index i. - - bias-pull-up, -down and -pin-default take as optional argument on hardware supporting it the pull strength in Ohm. bias-disable will disable the pull. diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt index 92fae82f35f2..2fb90b37aa09 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt @@ -50,7 +50,7 @@ Valid values for function are: gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1, gsbi7_spi_cs2, gsbi7_spi_cs3, gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm, - riva_wlan, sdc2, sdc4, slimbus, spkr_i2s, tsif1, tsif2, usb2_hsic, + riva_wlan, sdc2, sdc4, slimbus, spkr_i2s, tsif1, tsif2, usb2_hsic, ps_hold Example: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt new file mode 100644 index 000000000000..ffafa1990a30 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt @@ -0,0 +1,179 @@ +Qualcomm APQ8084 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +MSM8960 platform. + +- compatible: + Usage: required + Value type: <string> + Definition: must be "qcom,apq8084-pinctrl" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: <none> + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/interrupt-controller/irq.h> + +- gpio-controller: + Usage: required + Value type: <none> + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/gpio/gpio.h> + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: <string-array> + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio146, + sdc1_clk, + sdc1_cmd, + sdc1_data + sdc2_clk, + sdc2_cmd, + sdc2_data + +- function: + Usage: required + Value type: <string> + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + adsp_ext, audio_ref, blsp_i2c1, blsp_i2c2, blsp_i2c3, + blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8, + blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12, + blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5, + blsp_spi6, blsp_spi7, blsp_spi8, blsp_spi9, blsp_spi10, + blsp_spi11, blsp_spi12, blsp_uart1, blsp_uart2, blsp_uart3, + blsp_uart4, blsp_uart5, blsp_uart6, blsp_uart7, blsp_uart8, + blsp_uart9, blsp_uart10, blsp_uart11, blsp_uart12, + blsp_uim1, blsp_uim2, blsp_uim3, blsp_uim4, blsp_uim5, + blsp_uim6, blsp_uim7, blsp_uim8, blsp_uim9, blsp_uim10, + blsp_uim11, blsp_uim12, cam_mclk0, cam_mclk1, cam_mclk2, + cam_mclk3, cci_async, cci_async_in0, cci_i2c0, cci_i2c1, + cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4, + edp_hpd, gcc_gp1, gcc_gp2, gcc_gp3, gcc_obt, gcc_vtt,i + gp_mn, gp_pdm0, gp_pdm1, gp_pdm2, gp0_clk, gp1_clk, gpio, + hdmi_cec, hdmi_ddc, hdmi_dtest, hdmi_hpd, hdmi_rcv, hsic, + ldo_en, ldo_update, mdp_vsync, pci_e0, pci_e0_n, pci_e0_rst, + pci_e1, pci_e1_rst, pci_e1_rst_n, pci_e1_clkreq_n, pri_mi2s, + qua_mi2s, sata_act, sata_devsleep, sata_devsleep_n, + sd_write, sdc_emmc_mode, sdc3, sdc4, sec_mi2s, slimbus, + spdif_tx, spkr_i2s, spkr_i2s_ws, spss_geni, ter_mi2s, tsif1, + tsif2, uim, uim_batt_alarm + +- bias-disable: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as no pull. + +- bias-pull-down: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull down. + +- bias-pull-up: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull up. + +- output-high: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + high. + Not valid for sdc pins. + +- output-low: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + low. + Not valid for sdc pins. + +- drive-strength: + Usage: optional + Value type: <u32> + Definition: Selects the drive strength for the specified pins, in mA. + Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16 + +Example: + + tlmm: pinctrl@fd510000 { + compatible = "qcom,apq8084-pinctrl"; + reg = <0xfd510000 0x4000>; + + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <0 208 0>; + + uart2: uart2-default { + mux { + pins = "gpio4", "gpio5"; + function = "blsp_uart2"; + }; + + tx { + pins = "gpio4"; + drive-strength = <4>; + bias-disable; + }; + + rx { + pins = "gpio5"; + drive-strength = <2>; + bias-pull-up; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index 4658b69d4f4d..388b213249fd 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt @@ -2,8 +2,8 @@ The Rockchip Pinmux Controller, enables the IC to share one PAD to several functional blocks. The sharing is done by -multiplexing the PAD input/output signals. For each PAD there are up to -4 muxing options with option 0 being the use as a GPIO. +multiplexing the PAD input/output signals. For each PAD there are several +muxing options with option 0 being the use as a GPIO. Please refer to pinctrl-bindings.txt in this directory for details of the common pinctrl bindings used by client devices, including the meaning of the @@ -58,7 +58,7 @@ Deprecated properties for gpio sub nodes: Required properties for pin configuration node: - rockchip,pins: 3 integers array, represents a group of pins mux and config setting. The format is rockchip,pins = <PIN_BANK PIN_BANK_IDX MUX &phandle>. - The MUX 0 means gpio and MUX 1 to 3 mean the specific device function. + The MUX 0 means gpio and MUX 1 to N mean the specific device function. The phandle of a node containing the generic pinconfig options to use, as described in pinctrl-bindings.txt in this directory. diff --git a/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt new file mode 100644 index 000000000000..88c80273da91 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ti,omap-pinctrl.txt @@ -0,0 +1,13 @@ +OMAP Pinctrl definitions + +Required properties: +- compatible : Should be one of: + "ti,omap2420-padconf" - OMAP2420 compatible pinctrl + "ti,omap2430-padconf" - OMAP2430 compatible pinctrl + "ti,omap3-padconf" - OMAP3 compatible pinctrl + "ti,omap4-padconf" - OMAP4 compatible pinctrl + "ti,omap5-padconf" - OMAP5 compatible pinctrl + "ti,dra7-padconf" - DRA7 compatible pinctrl + "ti,am437-padconf" - AM437x compatible pinctrl + +See Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt for further details. diff --git a/Documentation/devicetree/bindings/power_supply/charger-manager.txt b/Documentation/devicetree/bindings/power_supply/charger-manager.txt index 2b33750e3db2..ec4fe9de3137 100644 --- a/Documentation/devicetree/bindings/power_supply/charger-manager.txt +++ b/Documentation/devicetree/bindings/power_supply/charger-manager.txt @@ -24,7 +24,7 @@ Optional properties : - cm-thermal-zone : name of external thermometer's thermal zone - cm-battery-* : threshold battery temperature for charging -cold : critical cold temperature of battery for charging - -cold-in-minus : flag that cold temerature is in minus degree + -cold-in-minus : flag that cold temperature is in minus degrees -hot : critical hot temperature of battery for charging -temp-diff : temperature difference to allow recharging - cm-dis/charging-max = limits of charging duration diff --git a/Documentation/devicetree/bindings/regmap/regmap.txt b/Documentation/devicetree/bindings/regmap/regmap.txt new file mode 100644 index 000000000000..b494f8b8ef72 --- /dev/null +++ b/Documentation/devicetree/bindings/regmap/regmap.txt @@ -0,0 +1,47 @@ +Device-Tree binding for regmap + +The endianness mode of CPU & Device scenarios: +Index Device Endianness properties +--------------------------------------------------- +1 BE 'big-endian' +2 LE 'little-endian' + +For one device driver, which will run in different scenarios above +on different SoCs using the devicetree, we need one way to simplify +this. + +Required properties: +- {big,little}-endian: these are boolean properties, if absent + meaning that the CPU and the Device are in the same endianness mode, + these properties are for register values and all the buffers only. + +Examples: +Scenario 1 : CPU in LE mode & device in LE mode. +dev: dev@40031000 { + compatible = "name"; + reg = <0x40031000 0x1000>; + ... +}; + +Scenario 2 : CPU in LE mode & device in BE mode. +dev: dev@40031000 { + compatible = "name"; + reg = <0x40031000 0x1000>; + ... + big-endian; +}; + +Scenario 3 : CPU in BE mode & device in BE mode. +dev: dev@40031000 { + compatible = "name"; + reg = <0x40031000 0x1000>; + ... +}; + +Scenario 4 : CPU in BE mode & device in LE mode. +dev: dev@40031000 { + compatible = "name"; + reg = <0x40031000 0x1000>; + ... + little-endian; +}; diff --git a/Documentation/devicetree/bindings/regulator/da9211.txt b/Documentation/devicetree/bindings/regulator/da9211.txt new file mode 100644 index 000000000000..240019a82f9a --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/da9211.txt @@ -0,0 +1,63 @@ +* Dialog Semiconductor DA9211/DA9213 Voltage Regulator + +Required properties: +- compatible: "dlg,da9211" or "dlg,da9213". +- reg: I2C slave address, usually 0x68. +- interrupts: the interrupt outputs of the controller +- regulators: A node that houses a sub-node for each regulator within the + device. Each sub-node is identified using the node's name, with valid + values listed below. The content of each sub-node is defined by the + standard binding for regulators; see regulator.txt. + BUCKA and BUCKB. + +Optional properties: +- Any optional property defined in regulator.txt + +Example 1) DA9211 + + pmic: da9211@68 { + compatible = "dlg,da9211"; + reg = <0x68>; + interrupts = <3 27>; + + regulators { + BUCKA { + regulator-name = "VBUCKA"; + regulator-min-microvolt = < 300000>; + regulator-max-microvolt = <1570000>; + regulator-min-microamp = <2000000>; + regulator-max-microamp = <5000000>; + }; + BUCKB { + regulator-name = "VBUCKB"; + regulator-min-microvolt = < 300000>; + regulator-max-microvolt = <1570000>; + regulator-min-microamp = <2000000>; + regulator-max-microamp = <5000000>; + }; + }; + }; + +Example 2) DA92113 + pmic: da9213@68 { + compatible = "dlg,da9213"; + reg = <0x68>; + interrupts = <3 27>; + + regulators { + BUCKA { + regulator-name = "VBUCKA"; + regulator-min-microvolt = < 300000>; + regulator-max-microvolt = <1570000>; + regulator-min-microamp = <3000000>; + regulator-max-microamp = <6000000>; + }; + BUCKB { + regulator-name = "VBUCKB"; + regulator-min-microvolt = < 300000>; + regulator-max-microvolt = <1570000>; + regulator-min-microamp = <3000000>; + regulator-max-microamp = <6000000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/fan53555.txt b/Documentation/devicetree/bindings/regulator/fan53555.txt new file mode 100644 index 000000000000..54a3f2c80e3a --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/fan53555.txt @@ -0,0 +1,23 @@ +Binding for Fairchild FAN53555 regulators + +Required properties: + - compatible: one of "fcs,fan53555", "silergy,syr827", "silergy,syr828" + - reg: I2C address + +Optional properties: + - fcs,suspend-voltage-selector: declare which of the two available + voltage selector registers should be used for the suspend + voltage. The other one is used for the runtime voltage setting + Possible values are either <0> or <1> + - vin-supply: regulator supplying the vin pin + +Example: + + regulator@40 { + compatible = "fcs,fan53555"; + regulator-name = "fan53555"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1800000>; + vin-supply = <&parent_reg>; + fcs,suspend-voltage-selector = <1>; + }; diff --git a/Documentation/devicetree/bindings/regulator/isl9305.txt b/Documentation/devicetree/bindings/regulator/isl9305.txt new file mode 100644 index 000000000000..a626fc1bbf0d --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/isl9305.txt @@ -0,0 +1,36 @@ +Intersil ISL9305/ISL9305H voltage regulator + +Required properties: + +- compatible: "isl,isl9305" or "isl,isl9305h" +- reg: I2C slave address, usually 0x68. +- regulators: A node that houses a sub-node for each regulator within the + device. Each sub-node is identified using the node's name, with valid + values being "dcd1", "dcd2", "ldo1" and "ldo2". The content of each sub-node + is defined by the standard binding for regulators; see regulator.txt. +- VINDCD1-supply: A phandle to a regulator node supplying VINDCD1. + VINDCD2-supply: A phandle to a regulator node supplying VINDCD2. + VINLDO1-supply: A phandle to a regulator node supplying VINLDO1. + VINLDO2-supply: A phandle to a regulator node supplying VINLDO2. + +Optional properties: +- Per-regulator optional properties are defined in regulator.txt + +Example + + pmic: isl9305@68 { + compatible = "isl,isl9305"; + reg = <0x68>; + + VINDCD1-supply = <&system_power>; + VINDCD2-supply = <&system_power>; + VINLDO1-supply = <&system_power>; + VINLDO2-supply = <&system_power>; + + regulators { + dcd1 { + regulator-name = "VDD_DSP"; + regulator-always-on; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/max1586-regulator.txt b/Documentation/devicetree/bindings/regulator/max1586-regulator.txt new file mode 100644 index 000000000000..c050c1744cb8 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max1586-regulator.txt @@ -0,0 +1,28 @@ +Maxim MAX1586 voltage regulator + +Required properties: +- compatible: must be "maxim,max1586" +- reg: I2C slave address, usually 0x14 +- v3-gain: integer specifying the V3 gain as per datasheet + (1 + R24/R25 + R24/185.5kOhm) +- any required generic properties defined in regulator.txt + +Example: + + i2c_master { + max1586@14 { + compatible = "maxim,max1586"; + reg = <0x14>; + v3-gain = <1000000>; + + regulators { + vcc_core: v3 { + regulator-name = "vcc_core"; + regulator-compatible = "Output_V3"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1705000>; + regulator-always-on; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt b/Documentation/devicetree/bindings/regulator/max77802.txt new file mode 100644 index 000000000000..5aeaffc0f1f0 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max77802.txt @@ -0,0 +1,53 @@ +Binding for Maxim MAX77802 regulators + +This is a part of device tree bindings of MAX77802 multi-function device. +More information can be found in bindings/mfd/max77802.txt file. + +The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout (LDO) +regulators that can be controlled over I2C. + +Following properties should be present in main device node of the MFD chip. + +Optional node: +- regulators : The regulators of max77802 have to be instantiated + under subnode named "regulators" using the following format. + + regulator-name { + standard regulator constraints.... + }; + refer Documentation/devicetree/bindings/regulator/regulator.txt + +The regulator node name should be initialized with a string to get matched +with their hardware counterparts as follow. The valid names are: + + -LDOn : for LDOs, where n can lie in ranges 1-15, 17-21, 23-30 + and 32-35. + example: LDO1, LDO2, LDO35. + -BUCKn : for BUCKs, where n can lie in range 1 to 10. + example: BUCK1, BUCK5, BUCK10. +Example: + + max77802@09 { + compatible = "maxim,max77802"; + interrupt-parent = <&wakeup_eint>; + interrupts = <26 0>; + reg = <0x09>; + #address-cells = <1>; + #size-cells = <0>; + + regulators { + ldo11_reg: LDO11 { + regulator-name = "vdd_ldo11"; + regulator-min-microvolt = <1900000>; + regulator-max-microvolt = <1900000>; + regulator-always-on; + }; + + buck1_reg: BUCK1 { + regulator-name = "vdd_mif"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + regulator-boot-on; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt new file mode 100644 index 000000000000..ce91f61feb12 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt @@ -0,0 +1,27 @@ +pwm regulator bindings + +Required properties: +- compatible: Should be "pwm-regulator" +- pwms: OF device-tree PWM specification (see PWM binding pwm.txt) +- voltage-table: voltage and duty table, include 2 members in each set of + brackets, first one is voltage(unit: uv), the next is duty(unit: percent) + +Any property defined as part of the core regulator binding defined in +regulator.txt can also be used. + +Example: + pwm_regulator { + compatible = "pwm-regulator; + pwms = <&pwm1 0 8448 0>; + + voltage-table = <1114000 0>, + <1095000 10>, + <1076000 20>, + <1056000 30>, + <1036000 40>, + <1016000 50>; + + regulator-min-microvolt = <1016000>; + regulator-max-microvolt = <1114000>; + regulator-name = "vdd_logic"; + }; diff --git a/Documentation/devicetree/bindings/regulator/sky81452-regulator.txt b/Documentation/devicetree/bindings/regulator/sky81452-regulator.txt new file mode 100644 index 000000000000..882455e9b36d --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/sky81452-regulator.txt @@ -0,0 +1,16 @@ +SKY81452 voltage regulator + +Required properties: +- any required generic properties defined in regulator.txt + +Optional properties: +- any available generic properties defined in regulator.txt + +Example: + + regulator { + /* generic regulator properties */ + regulator-name = "touch_en"; + regulator-min-microvolt = <4500000>; + regulator-max-microvolt = <8000000>; + }; diff --git a/Documentation/devicetree/bindings/rng/apm,rng.txt b/Documentation/devicetree/bindings/rng/apm,rng.txt new file mode 100644 index 000000000000..4dde4b06cdd9 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/apm,rng.txt @@ -0,0 +1,17 @@ +APM X-Gene SoC random number generator. + +Required properties: + +- compatible : should be "apm,xgene-rng" +- reg : specifies base physical address and size of the registers map +- clocks : phandle to clock-controller plus clock-specifier pair +- interrupts : specify the fault interrupt for the RNG device + +Example: + + rng: rng@10520000 { + compatible = "apm,xgene-rng"; + reg = <0x0 0x10520000 0x0 0x100>; + interrupts = <0x0 0x41 0x4>; + clocks = <&rngpkaclk 0>; + }; diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt index 6c55fcfe5e1d..9b82c20b306b 100644 --- a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt +++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt @@ -31,7 +31,7 @@ i2s@ff890000 { #address-cells = <1>; #size-cells = <0>; dmas = <&pdma1 0>, <&pdma1 1>; - dma-names = "rx", "tx"; + dma-names = "tx", "rx"; clock-names = "i2s_hclk", "i2s_clk"; clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>; }; diff --git a/Documentation/devicetree/bindings/sound/st,sta350.txt b/Documentation/devicetree/bindings/sound/st,sta350.txt index b7e71bf5caf4..307398ef2317 100644 --- a/Documentation/devicetree/bindings/sound/st,sta350.txt +++ b/Documentation/devicetree/bindings/sound/st,sta350.txt @@ -33,7 +33,7 @@ Optional properties: 0: Channel 1 1: Channel 2 2: Channel 3 - If parameter is missing, channel 1 is choosen. + If parameter is missing, channel 1 is chosen. This properties have to be specified as '/bits/ 8' values. - st,thermal-warning-recover: diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt index 4256a6df9b79..aad527b357a0 100644 --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt @@ -7,6 +7,9 @@ Required properties: - interrupts : Should contain CSPI/eCSPI interrupt - fsl,spi-num-chipselects : Contains the number of the chipselect - cs-gpios : Specifies the gpio pins to be used for chipselects. +- dmas: DMA specifiers for tx and rx dma. See the DMA client binding, + Documentation/devicetree/bindings/dma/dma.txt +- dma-names: DMA request names should include "tx" and "rx" if present. Example: @@ -19,4 +22,6 @@ ecspi@70010000 { fsl,spi-num-chipselects = <2>; cs-gpios = <&gpio3 24 0>, /* GPIO3_24 */ <&gpio3 25 0>; /* GPIO3_25 */ + dmas = <&sdma 3 7 1>, <&sdma 4 7 2>; + dma-names = "rx", "tx"; }; diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt index f24baf3b6cc1..d11c3721e7cd 100644 --- a/Documentation/devicetree/bindings/spi/sh-msiof.txt +++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt @@ -6,8 +6,17 @@ Required properties: "renesas,sh-mobile-msiof" for SH Mobile series. Examples with soctypes are: "renesas,msiof-r8a7790" (R-Car H2) - "renesas,msiof-r8a7791" (R-Car M2) -- reg : Offset and length of the register set for the device + "renesas,msiof-r8a7791" (R-Car M2-W) + "renesas,msiof-r8a7792" (R-Car V2H) + "renesas,msiof-r8a7793" (R-Car M2-N) + "renesas,msiof-r8a7794" (R-Car E2) +- reg : A list of offsets and lengths of the register sets for + the device. + If only one register set is present, it is to be used + by both the CPU and the DMA engine. + If two register sets are present, the first is to be + used by the CPU, and the second is to be used by the + DMA engine. - interrupt-parent : The phandle for the interrupt controller that services interrupts for this device - interrupts : Interrupt specifier @@ -17,12 +26,16 @@ Required properties: Optional properties: - clocks : Must contain a reference to the functional clock. - num-cs : Total number of chip-selects (default is 1) +- dmas : Must contain a list of two references to DMA + specifiers, one for transmission, and one for + reception. +- dma-names : Must contain a list of two DMA names, "tx" and "rx". Optional properties, deprecated for soctype-specific bindings: - renesas,tx-fifo-size : Overrides the default tx fifo size given in words (default is 64) - renesas,rx-fifo-size : Overrides the default rx fifo size given in words - (default is 64, or 256 on R-Car H2 and M2) + (default is 64, or 256 on R-Car Gen2) Pinctrl properties might be needed, too. See Documentation/devicetree/bindings/pinctrl/renesas,*. @@ -31,9 +44,11 @@ Example: msiof0: spi@e6e20000 { compatible = "renesas,msiof-r8a7791"; - reg = <0 0xe6e20000 0 0x0064>; + reg = <0 0xe6e20000 0 0x0064>, <0 0xe7e20000 0 0x0064>; interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>; clocks = <&mstp0_clks R8A7791_CLK_MSIOF0>; + dmas = <&dmac0 0x51>, <&dmac0 0x52>; + dma-names = "tx", "rx"; #address-cells = <1>; #size-cells = <0>; status = "disabled"; diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt index f80887bca0d6..12ecfe9e3599 100644 --- a/Documentation/devicetree/bindings/spi/spi-davinci.txt +++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt @@ -1,5 +1,10 @@ Davinci SPI controller device bindings +Links on DM: +Keystone 2 - http://www.ti.com/lit/ug/sprugp2a/sprugp2a.pdf +dm644x - http://www.ti.com/lit/ug/sprue32a/sprue32a.pdf +OMAP-L138/da830 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf + Required properties: - #address-cells: number of cells required to define a chip select address on the SPI bus. Should be set to 1. @@ -24,6 +29,30 @@ Optional: cs-gpios = <0>, <0>, <0>, <&gpio1 30 0>, <&gpio1 31 0>; where first three are internal CS and last two are GPIO CS. +Optional properties for slave devices: +SPI slave nodes can contain the following properties. +Not all SPI Peripherals from Texas Instruments support this. +Please check SPI peripheral documentation for a device before using these. + +- ti,spi-wdelay : delay between transmission of words + (SPIFMTn.WDELAY, SPIDAT1.WDEL) must be specified in number of SPI module + clock periods. + + delay = WDELAY * SPI_module_clock_period + 2 * SPI_module_clock_period + +Below is timing diagram which shows functional meaning of +"ti,spi-wdelay" parameter. + + +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +SPI_CLK | | | | | | | | | | | | | | | | + +----------+ +-+ +-+ +-+ +-+ +---------------------------+ +-+ +-+ +- + +SPI_SOMI/SIMO+-----------------+ +----------- + +----------+ word1 +---------------------------+word2 + +-----------------+ +----------- + WDELAY + <--------------------------> + Example of a NOR flash slave device (n25q032) connected to DaVinci SPI controller device over the SPI bus. @@ -43,6 +72,7 @@ spi0:spi@20BF0000 { compatible = "st,m25p32"; spi-max-frequency = <25000000>; reg = <0>; + ti,spi-wdelay = <8>; partition@0 { label = "u-boot-spl"; diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt index 5376de40f10b..cbbe16ed3874 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt @@ -10,7 +10,12 @@ Required properties: - pinctrl-names: must contain a "default" entry. - spi-num-chipselects : the number of the chipselect signals. - bus-num : the slave chip chipselect signal number. -- big-endian : if DSPI modudle is big endian, the bool will be set in node. + +Optional property: +- big-endian: If present the dspi device's registers are implemented + in big endian mode, otherwise in native mode(same with CPU), for more + detail please see: Documentation/devicetree/bindings/regmap/regmap.txt. + Example: dspi0@4002c000 { diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt index a3ff50fc76fb..50c3a3de61c1 100644 --- a/Documentation/devicetree/bindings/spi/spi-orion.txt +++ b/Documentation/devicetree/bindings/spi/spi-orion.txt @@ -1,7 +1,7 @@ Marvell Orion SPI device Required properties: -- compatible : should be "marvell,orion-spi". +- compatible : should be "marvell,orion-spi" or "marvell,armada-370-spi". - reg : offset and length of the register set for the device - cell-index : Which of multiple SPI controllers is this. Optional properties: diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt b/Documentation/devicetree/bindings/spi/spi-rockchip.txt index 7bab35575817..467dec441c62 100644 --- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt +++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt @@ -16,11 +16,15 @@ Required Properties: - clocks: Must contain an entry for each entry in clock-names. - clock-names: Shall be "spiclk" for the transfer-clock, and "apb_pclk" for the peripheral clock. +- #address-cells: should be 1. +- #size-cells: should be 0. + +Optional Properties: + - dmas: DMA specifiers for tx and rx dma. See the DMA client binding, Documentation/devicetree/bindings/dma/dma.txt - dma-names: DMA request names should include "tx" and "rx" if present. -- #address-cells: should be 1. -- #size-cells: should be 0. + Example: diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt b/Documentation/devicetree/bindings/spi/spi-rspi.txt index d57d82a74054..8f4169f63936 100644 --- a/Documentation/devicetree/bindings/spi/spi-rspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt @@ -11,7 +11,10 @@ Required properties: - "renesas,rspi-sh7757" (SH) - "renesas,rspi-r7s72100" (RZ/A1H) - "renesas,qspi-r8a7790" (R-Car H2) - - "renesas,qspi-r8a7791" (R-Car M2) + - "renesas,qspi-r8a7791" (R-Car M2-W) + - "renesas,qspi-r8a7792" (R-Car V2H) + - "renesas,qspi-r8a7793" (R-Car M2-N) + - "renesas,qspi-r8a7794" (R-Car E2) - reg : Address start and address range size of the device - interrupts : A list of interrupt-specifiers, one for each entry in interrupt-names. @@ -30,6 +33,9 @@ Required properties: Optional properties: - clocks : Must contain a reference to the functional clock. +- dmas : Must contain a list of two references to DMA specifiers, + one for transmission, and one for reception. +- dma-names : Must contain a list of two DMA names, "tx" and "rx". Pinctrl properties might be needed, too. See Documentation/devicetree/bindings/pinctrl/renesas,*. @@ -58,4 +64,6 @@ Examples: num-cs = <1>; #address-cells = <1>; #size-cells = <0>; + dmas = <&dmac0 0x17>, <&dmac0 0x18>; + dma-names = "tx", "rx"; }; diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt index 578a1fca366e..443bcb6134d5 100644 --- a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt +++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt @@ -56,6 +56,9 @@ Required properties: - fsl,data-width : should be <18> or <24> - port: A port node with endpoint definitions as defined in Documentation/devicetree/bindings/media/video-interfaces.txt. + On i.MX5, the internal two-input-multiplexer is used. + Due to hardware limitations, only one port (port@[0,1]) + can be used for each channel (lvds-channel@[0,1], respectively) On i.MX6, there should be four ports (port@[0-3]) that correspond to the four LVDS multiplexer inputs. @@ -78,6 +81,8 @@ ldb: ldb@53fa8008 { "di0", "di1"; lvds-channel@0 { + #address-cells = <1>; + #size-cells = <0>; reg = <0>; fsl,data-mapping = "spwg"; fsl,data-width = <24>; @@ -86,7 +91,9 @@ ldb: ldb@53fa8008 { /* ... */ }; - port { + port@0 { + reg = <0>; + lvds0_in: endpoint { remote-endpoint = <&ipu_di0_lvds0>; }; @@ -94,6 +101,8 @@ ldb: ldb@53fa8008 { }; lvds-channel@1 { + #address-cells = <1>; + #size-cells = <0>; reg = <1>; fsl,data-mapping = "spwg"; fsl,data-width = <24>; @@ -102,7 +111,9 @@ ldb: ldb@53fa8008 { /* ... */ }; - port { + port@1 { + reg = <1>; + lvds1_in: endpoint { remote-endpoint = <&ipu_di1_lvds1>; }; diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index 20468b2a7516..53579197eca2 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -8,9 +8,50 @@ Required properties: - interrupts : <interrupt mapping for UFS host controller IRQ> - reg : <registers mapping> +Optional properties: +- vdd-hba-supply : phandle to UFS host controller supply regulator node +- vcc-supply : phandle to VCC supply regulator node +- vccq-supply : phandle to VCCQ supply regulator node +- vccq2-supply : phandle to VCCQ2 supply regulator node +- vcc-supply-1p8 : For embedded UFS devices, valid VCC range is 1.7-1.95V + or 2.7-3.6V. This boolean property when set, specifies + to use low voltage range of 1.7-1.95V. Note for external + UFS cards this property is invalid and valid VCC range is + always 2.7-3.6V. +- vcc-max-microamp : specifies max. load that can be drawn from vcc supply +- vccq-max-microamp : specifies max. load that can be drawn from vccq supply +- vccq2-max-microamp : specifies max. load that can be drawn from vccq2 supply +- <name>-fixed-regulator : boolean property specifying that <name>-supply is a fixed regulator + +- clocks : List of phandle and clock specifier pairs +- clock-names : List of clock input name strings sorted in the same + order as the clocks property. +- freq-table-hz : Array of <min max> operating frequencies stored in the same + order as the clocks property. If this property is not + defined or a value in the array is "0" then it is assumed + that the frequency is set by the parent clock or a + fixed rate clock source. + +Note: If above properties are not defined it can be assumed that the supply +regulators or clocks are always on. + Example: ufshc@0xfc598000 { compatible = "jedec,ufs-1.1"; reg = <0xfc598000 0x800>; interrupts = <0 28 0>; + + vdd-hba-supply = <&xxx_reg0>; + vdd-hba-fixed-regulator; + vcc-supply = <&xxx_reg1>; + vcc-supply-1p8; + vccq-supply = <&xxx_reg2>; + vccq2-supply = <&xxx_reg3>; + vcc-max-microamp = 500000; + vccq-max-microamp = 200000; + vccq2-max-microamp = 200000; + + clocks = <&core 0>, <&ref 0>, <&iface 0>; + clock-names = "core_clk", "ref_clk", "iface_clk"; + freq-table-hz = <100000000 200000000>, <0 0>, <0 0>; }; diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt index 1bae71e9ad47..38a548001e3a 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt @@ -19,6 +19,7 @@ Optional properties: - disable-over-current: disable over current detect - external-vbus-divider: enables off-chip resistor divider for Vbus - maximum-speed: limit the maximum connection speed to "full-speed". +- tpl-support: TPL (Targeted Peripheral List) feature for targeted hosts Examples: usb@02184000 { /* USB OTG */ @@ -30,4 +31,5 @@ usb@02184000 { /* USB OTG */ disable-over-current; external-vbus-divider; maximum-speed = "full-speed"; + tpl-support; }; diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index 467ddd15d40c..482f815363ef 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -4,6 +4,9 @@ Platform DesignWare HS OTG USB 2.0 controller Required properties: - compatible : One of: - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC. + - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc; + - "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 Soc; + - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc; - snps,dwc2: A generic DWC2 USB controller with default parameters. - reg : Should contain 1 register range (address and length) - interrupts : Should contain 1 interrupt @@ -15,6 +18,8 @@ Optional properties: - phys: phy provider specifier - phy-names: shall be "usb2-phy" Refer to phy/phy-bindings.txt for generic phy consumer properties +- dr_mode: shall be one of "host", "peripheral" and "otg" + Refer to usb/generic.txt Example: diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt b/Documentation/devicetree/bindings/usb/dwc3-st.txt new file mode 100644 index 000000000000..f9d70252bbb2 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt @@ -0,0 +1,68 @@ +ST DWC3 glue logic + +This file documents the parameters for the dwc3-st driver. +This driver controls the glue logic used to configure the dwc3 core on +STiH407 based platforms. + +Required properties: + - compatible : must be "st,stih407-dwc3" + - reg : glue logic base address and USB syscfg ctrl register offset + - reg-names : should be "reg-glue" and "syscfg-reg" + - st,syscon : should be phandle to system configuration node which + encompasses the glue registers + - resets : list of phandle and reset specifier pairs. There should be two entries, one + for the powerdown and softreset lines of the usb3 IP + - reset-names : list of reset signal names. Names should be "powerdown" and "softreset" +See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt +See: Documentation/devicetree/bindings/reset/reset.txt + + - #address-cells, #size-cells : should be '1' if the device has sub-nodes + with 'reg' property + + - pinctl-names : A pinctrl state named "default" must be defined +See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt + + - pinctrl-0 : Pin control group +See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt + + - ranges : allows valid 1:1 translation between child's address space and + parent's address space + +Sub-nodes: +The dwc3 core should be added as subnode to ST DWC3 glue as shown in the +example below. The DT binding details of dwc3 can be found in: +Documentation/devicetree/bindings/usb/dwc3.txt + +NB: The dr_mode property described in [1] is NOT optional for this driver, as the default value +is "otg", which isn't supported by this SoC. Valid dr_mode values for dwc3-st are either "host" +or "device". + +[1] Documentation/devicetree/bindings/usb/generic.txt + +Example: + +st_dwc3: dwc3@8f94000 { + status = "disabled"; + compatible = "st,stih407-dwc3"; + reg = <0x08f94000 0x1000>, <0x110 0x4>; + reg-names = "reg-glue", "syscfg-reg"; + st,syscfg = <&syscfg_core>; + resets = <&powerdown STIH407_USB3_POWERDOWN>, + <&softreset STIH407_MIPHY2_SOFTRESET>; + reset-names = "powerdown", + "softreset"; + #address-cells = <1>; + #size-cells = <1>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usb3>; + ranges; + + dwc3: dwc3@9900000 { + compatible = "snps,dwc3"; + reg = <0x09900000 0x100000>; + interrupts = <GIC_SPI 155 IRQ_TYPE_NONE>; + dr_mode = "host"; + phys-names = "usb2-phy", "usb3-phy"; + phys = <&usb2_picophy2>, <&phy_port2 MIPHY_TYPE_USB>; + }; +}; diff --git a/Documentation/devicetree/bindings/usb/ehci-st.txt b/Documentation/devicetree/bindings/usb/ehci-st.txt new file mode 100644 index 000000000000..fb45fa5770bb --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ehci-st.txt @@ -0,0 +1,39 @@ +ST USB EHCI controller + +Required properties: + - compatible : must be "st,st-ehci-300x" + - reg : physical base addresses of the controller and length of memory mapped + region + - interrupts : one EHCI interrupt should be described here + - pinctrl-names : a pinctrl state named "default" must be defined + - pinctrl-0 : phandle referencing pin configuration of the USB controller +See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt + - clocks : phandle list of usb clocks + - clock-names : should be "ic" for interconnect clock and "clk48" +See: Documentation/devicetree/bindings/clock/clock-bindings.txt + + - phys : phandle for the PHY device + - phy-names : should be "usb" + - resets : phandle + reset specifier pairs to the powerdown and softreset lines + of the USB IP + - reset-names : should be "power" and "softreset" +See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt +See: Documentation/devicetree/bindings/reset/reset.txt + +Example: + + ehci1: usb@0xfe203e00 { + compatible = "st,st-ehci-300x"; + reg = <0xfe203e00 0x100>; + interrupts = <GIC_SPI 148 IRQ_TYPE_NONE>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usb1>; + clocks = <&clk_s_a1_ls 0>; + phys = <&usb2_phy>; + phy-names = "usb"; + status = "okay"; + + resets = <&powerdown STIH416_USB1_POWERDOWN>, + <&softreset STIH416_USB1_SOFTRESET>; + reset-names = "power", "softreset"; + }; diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt b/Documentation/devicetree/bindings/usb/mxs-phy.txt index 96681c93b86d..379b84a567cc 100644 --- a/Documentation/devicetree/bindings/usb/mxs-phy.txt +++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt @@ -5,6 +5,7 @@ Required properties: * "fsl,imx23-usbphy" for imx23 and imx28 * "fsl,imx6q-usbphy" for imx6dq and imx6dl * "fsl,imx6sl-usbphy" for imx6sl + * "fsl,vf610-usbphy" for Vybrid vf610 * "fsl,imx6sx-usbphy" for imx6sx "fsl,imx23-usbphy" is still a fallback for other strings - reg: Should contain registers location and length diff --git a/Documentation/devicetree/bindings/usb/ohci-st.txt b/Documentation/devicetree/bindings/usb/ohci-st.txt new file mode 100644 index 000000000000..6d8393748da2 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ohci-st.txt @@ -0,0 +1,37 @@ +ST USB OHCI controller + +Required properties: + + - compatible : must be "st,st-ohci-300x" + - reg : physical base addresses of the controller and length of memory mapped + region + - interrupts : one OHCI controller interrupt should be described here + - clocks : phandle list of usb clocks + - clock-names : should be "ic" for interconnect clock and "clk48" +See: Documentation/devicetree/bindings/clock/clock-bindings.txt + + - phys : phandle for the PHY device + - phy-names : should be "usb" + + - resets : phandle to the powerdown and reset controller for the USB IP + - reset-names : should be "power" and "softreset". +See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt +See: Documentation/devicetree/bindings/reset/reset.txt + +Example: + + ohci0: usb@0xfe1ffc00 { + compatible = "st,st-ohci-300x"; + reg = <0xfe1ffc00 0x100>; + interrupts = <GIC_SPI 149 IRQ_TYPE_NONE>; + clocks = <&clk_s_a1_ls 0>, + <&clockgen_b0 0>; + clock-names = "ic", "clk48"; + phys = <&usb2_phy>; + phy-names = "usb"; + status = "okay"; + + resets = <&powerdown STIH416_USB0_POWERDOWN>, + <&softreset STIH416_USB0_SOFTRESET>; + reset-names = "power", "softreset"; + }; diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt new file mode 100644 index 000000000000..ca164e71dd50 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt @@ -0,0 +1,66 @@ +Qualcomm SuperSpeed DWC3 USB SoC controller + +Required properties: +- compatible: should contain "qcom,dwc3" +- clocks: A list of phandle + clock-specifier pairs for the + clocks listed in clock-names +- clock-names: Should contain the following: + "core" Master/Core clock, have to be >= 125 MHz for SS + operation and >= 60MHz for HS operation + +Optional clocks: + "iface" System bus AXI clock. Not present on all platforms + "sleep" Sleep clock, used when USB3 core goes into low + power mode (U3). + +Required child node: +A child node must exist to represent the core DWC3 IP block. The name of +the node is not important. The content of the node is defined in dwc3.txt. + +Phy documentation is provided in the following places: +Documentation/devicetree/bindings/phy/qcom,dwc3-usb-phy.txt + +Example device nodes: + + hs_phy: phy@100f8800 { + compatible = "qcom,dwc3-hs-usb-phy"; + reg = <0x100f8800 0x30>; + clocks = <&gcc USB30_0_UTMI_CLK>; + clock-names = "ref"; + #phy-cells = <0>; + + status = "ok"; + }; + + ss_phy: phy@100f8830 { + compatible = "qcom,dwc3-ss-usb-phy"; + reg = <0x100f8830 0x30>; + clocks = <&gcc USB30_0_MASTER_CLK>; + clock-names = "ref"; + #phy-cells = <0>; + + status = "ok"; + }; + + usb3_0: usb30@0 { + compatible = "qcom,dwc3"; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&gcc USB30_0_MASTER_CLK>; + clock-names = "core"; + + ranges; + + status = "ok"; + + dwc3@10000000 { + compatible = "snps,dwc3"; + reg = <0x10000000 0xcd00>; + interrupts = <0 205 0x4>; + phys = <&hs_phy>, <&ss_phy>; + phy-names = "usb2-phy", "usb3-phy"; + tx-fifo-resize; + dr_mode = "host"; + }; + }; + diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt new file mode 100644 index 000000000000..b08c903f8668 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -0,0 +1,24 @@ +Renesas Electronics USBHS driver + +Required properties: + - compatible: Must contain one of the following: + - "renesas,usbhs-r8a7790" + - "renesas,usbhs-r8a7791" + - reg: Base address and length of the register for the USBHS + - interrupts: Interrupt specifier for the USBHS + - clocks: A list of phandle + clock specifier pairs + +Optional properties: + - renesas,buswait: Integer to use BUSWAIT register + - renesas,enable-gpio: A gpio specifier to check GPIO determining if USB + function should be enabled + - phys: phandle + phy specifier pair + - phy-names: must be "usb" + +Example: + usbhs: usb@e6590000 { + compatible = "renesas,usbhs-r8a7790"; + reg = <0 0xe6590000 0 0x100>; + interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp7_clks R8A7790_CLK_HSUSB>; + }; diff --git a/Documentation/devicetree/bindings/usb/udc-xilinx.txt b/Documentation/devicetree/bindings/usb/udc-xilinx.txt new file mode 100644 index 000000000000..47b4e397a08d --- /dev/null +++ b/Documentation/devicetree/bindings/usb/udc-xilinx.txt @@ -0,0 +1,18 @@ +Xilinx USB2 device controller + +Required properties: +- compatible : Should be "xlnx,usb2-device-4.00.a" +- reg : Physical base address and size of the USB2 + device registers map. +- interrupts : Should contain single irq line of USB2 device + controller +- xlnx,has-builtin-dma : if DMA is included + +Example: + axi-usb2-device@42e00000 { + compatible = "xlnx,usb2-device-4.00.a"; + interrupts = <0x0 0x39 0x1>; + reg = <0x42e00000 0x10000>; + xlnx,has-builtin-dma; + }; + diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt index 221ac0dbc678..52493b1480e2 100644 --- a/Documentation/devicetree/bindings/usb/usb3503.txt +++ b/Documentation/devicetree/bindings/usb/usb3503.txt @@ -8,8 +8,8 @@ Optional properties: if I2C is used. - connect-gpios: Should specify GPIO for connect. - disabled-ports: Should specify the ports unused. - '1' or '2' or '3' are availe for this property to describe the port - number. 1~3 property values are possible to be desribed. + '1' or '2' or '3' are available for this property to describe the port + number. 1~3 property values are possible to be described. Do not describe this property if all ports have to be enabled. - intn-gpios: Should specify GPIO for interrupt. - reset-gpios: Should specify GPIO for reset. diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt index 97ce94e1a6cc..c101a4b17131 100644 --- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt +++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt @@ -4,6 +4,7 @@ Required properties: - #index-cells: Cells used to descibe usb controller index. Should be <1> - compatible: Should be one of below: "fsl,imx6q-usbmisc" for imx6q + "fsl,vf610-usbmisc" for Vybrid vf610 - reg: Should contain registers location and length Examples: diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ac7269f90764..e1e34ad80600 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -29,6 +29,7 @@ calxeda Calxeda capella Capella Microsystems, Inc cavium Cavium, Inc. cdns Cadence Design Systems Inc. +chipidea Chipidea, Inc chrp Common Hardware Reference Platform chunghwa Chunghwa Picture Tubes Ltd. cirrus Cirrus Logic, Inc. @@ -49,6 +50,7 @@ epson Seiko Epson Corp. est ESTeem Wireless Modems eukrea Eukréa Electromatique excito Excito +fcs Fairchild Semiconductor fsl Freescale Semiconductor GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. @@ -124,6 +126,7 @@ sil Silicon Image silabs Silicon Laboratories simtek sii Seiko Instruments, Inc. +silergy Silergy Corp. sirf SiRF Technology, Inc. smsc Standard Microsystems Corporation snps Synopsys, Inc. @@ -138,7 +141,7 @@ tlm Trusted Logic Mobility toradex Toradex AG toshiba Toshiba Corporation toumaz Toumaz -usi Universal Scientifc Industrial Co., Ltd. +usi Universal Scientific Industrial Co., Ltd. v3 V3 Semiconductor variscite Variscite Ltd. via VIA Technologies, Inc. diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt b/Documentation/devicetree/bindings/video/atmel,lcdc.txt index b75af94a5e52..7d0c4a1ab811 100644 --- a/Documentation/devicetree/bindings/video/atmel,lcdc.txt +++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt @@ -39,8 +39,8 @@ Atmel LCDC Display ----------------------------------------------------- Required properties (as per of_videomode_helper): - - atmel,dmacon: dma controler configuration - - atmel,lcdcon2: lcd controler configuration + - atmel,dmacon: dma controller configuration + - atmel,lcdcon2: lcd controller configuration - atmel,guard-time: lcd guard time (Delay in frame periods) - bits-per-pixel: lcd panel bit-depth. diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt index 0329f60d431e..8c8c2f4e4c3f 100644 --- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt @@ -20,7 +20,7 @@ Optional properties: register is not modified as recommended by the datasheet. - fsl,lpccr: Contrast Control Register value. This property provides the default value for the contrast control register. - If that property is ommited, the register is zeroed. + If that property is omitted, the register is zeroed. - fsl,lscr1: LCDC Sharp Configuration Register value. Example: diff --git a/Documentation/devicetree/bindings/staging/xillybus.txt b/Documentation/devicetree/bindings/xillybus/xillybus.txt index 9e316dc2e40f..9e316dc2e40f 100644 --- a/Documentation/devicetree/bindings/staging/xillybus.txt +++ b/Documentation/devicetree/bindings/xillybus/xillybus.txt diff --git a/Documentation/devicetree/of_selftest.txt b/Documentation/devicetree/of_selftest.txt new file mode 100644 index 000000000000..3a2f54d07fc5 --- /dev/null +++ b/Documentation/devicetree/of_selftest.txt @@ -0,0 +1,211 @@ +Open Firmware Device Tree Selftest +---------------------------------- + +Author: Gaurav Minocha <gaurav.minocha.os@gmail.com> + +1. Introduction + +This document explains how the test data required for executing OF selftest +is attached to the live tree dynamically, independent of the machine's +architecture. + +It is recommended to read the following documents before moving ahead. + +[1] Documentation/devicetree/usage-model.txt +[2] http://www.devicetree.org/Device_Tree_Usage + +OF Selftest has been designed to test the interface (include/linux/of.h) +provided to device driver developers to fetch the device information..etc. +from the unflattened device tree data structure. This interface is used by +most of the device drivers in various use cases. + + +2. Test-data + +The Device Tree Source file (drivers/of/testcase-data/testcases.dts) contains +the test data required for executing the unit tests automated in +drivers/of/selftests.c. Currently, following Device Tree Source Include files +(.dtsi) are included in testcase.dts: + +drivers/of/testcase-data/tests-interrupts.dtsi +drivers/of/testcase-data/tests-platform.dtsi +drivers/of/testcase-data/tests-phandle.dtsi +drivers/of/testcase-data/tests-match.dtsi + +When the kernel is build with OF_SELFTEST enabled, then the following make rule + +$(obj)/%.dtb: $(src)/%.dts FORCE + $(call if_changed_dep, dtc) + +is used to compile the DT source file (testcase.dts) into a binary blob +(testcase.dtb), also referred as flattened DT. + +After that, using the following rule the binary blob above is wrapped as an +assembly file (testcase.dtb.S). + +$(obj)/%.dtb.S: $(obj)/%.dtb + $(call cmd, dt_S_dtb) + +The assembly file is compiled into an object file (testcase.dtb.o), and is +linked into the kernel image. + + +2.1. Adding the test data + +Un-flattened device tree structure: + +Un-flattened device tree consists of connected device_node(s) in form of a tree +structure described below. + +// following struct members are used to construct the tree +struct device_node { + ... + struct device_node *parent; + struct device_node *child; + struct device_node *sibling; + struct device_node *allnext; /* next in list of all nodes */ + ... + }; + +Figure 1, describes a generic structure of machine’s un-flattened device tree +considering only child and sibling pointers. There exists another pointer, +*parent, that is used to traverse the tree in the reverse direction. So, at +a particular level the child node and all the sibling nodes will have a parent +pointer pointing to a common node (e.g. child1, sibling2, sibling3, sibling4’s +parent points to root node) + +root (‘/’) + | +child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | + | | | null + | | | + | | child31 -> sibling32 -> null + | | | | + | | null null + | | + | child21 -> sibling22 -> sibling23 -> null + | | | | + | null null null + | +child11 -> sibling12 -> sibling13 -> sibling14 -> null + | | | | + | | | null + | | | + null null child131 -> null + | + null + +Figure 1: Generic structure of un-flattened device tree + + +*allnext: it is used to link all the nodes of DT into a list. So, for the + above tree the list would be as follows: + +root->child1->child11->sibling12->sibling13->child131->sibling14->sibling2-> +child21->sibling22->sibling23->sibling3->child31->sibling32->sibling4->null + +Before executing OF selftest, it is required to attach the test data to +machine's device tree (if present). So, when selftest_data_add() is called, +at first it reads the flattened device tree data linked into the kernel image +via the following kernel symbols: + +__dtb_testcases_begin - address marking the start of test data blob +__dtb_testcases_end - address marking the end of test data blob + +Secondly, it calls of_fdt_unflatten_device_tree() to unflatten the flattened +blob. And finally, if the machine’s device tree (i.e live tree) is present, +then it attaches the unflattened test data tree to the live tree, else it +attaches itself as a live device tree. + +attach_node_and_children() uses of_attach_node() to attach the nodes into the +live tree as explained below. To explain the same, the test data tree described + in Figure 2 is attached to the live tree described in Figure 1. + +root (‘/’) + | + testcase-data + | + test-child0 -> test-sibling1 -> test-sibling2 -> test-sibling3 -> null + | | | | + test-child01 null null null + + +allnext list: + +root->testcase-data->test-child0->test-child01->test-sibling1->test-sibling2 +->test-sibling3->null + +Figure 2: Example test data tree to be attached to live tree. + +According to the scenario above, the live tree is already present so it isn’t +required to attach the root(‘/’) node. All other nodes are attached by calling +of_attach_node() on each node. + +In the function of_attach_node(), the new node is attached as the child of the +given parent in live tree. But, if parent already has a child then the new node +replaces the current child and turns it into its sibling. So, when the testcase +data node is attached to the live tree above (Figure 1), the final structure is + as shown in Figure 3. + +root (‘/’) + | +testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | | + (...) | | | null + | | child31 -> sibling32 -> null + | | | | + | | null null + | | + | child21 -> sibling22 -> sibling23 -> null + | | | | + | null null null + | + child11 -> sibling12 -> sibling13 -> sibling14 -> null + | | | | + null null | null + | + child131 -> null + | + null +----------------------------------------------------------------------- + +root (‘/’) + | +testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | | + | (...) (...) (...) null + | +test-sibling3 -> test-sibling2 -> test-sibling1 -> test-child0 -> null + | | | | + null null null test-child01 + + +Figure 3: Live device tree structure after attaching the testcase-data. + + +Astute readers would have noticed that test-child0 node becomes the last +sibling compared to the earlier structure (Figure 2). After attaching first +test-child0 the test-sibling1 is attached that pushes the child node +(i.e. test-child0) to become a sibling and makes itself a child node, + as mentioned above. + +If a duplicate node is found (i.e. if a node with same full_name property is +already present in the live tree), then the node isn’t attached rather its +properties are updated to the live tree’s node by calling the function +update_node_properties(). + + +2.2. Removing the test data + +Once the test case execution is complete, selftest_data_remove is called in +order to remove the device nodes attached initially (first the leaf nodes are +detached and then moving up the parent nodes are removed, and eventually the +whole tree). selftest_data_remove() calls detach_node_and_children() that uses +of_detach_node() to detach the nodes from the live device tree. + +To detach a node, of_detach_node() first updates all_next linked list, by +attaching the previous node’s allnext to current node’s allnext pointer. And +then, it either updates the child pointer of given node’s parent to its +sibling or attaches the previous sibling to the given node’s sibling, as +appropriate. That is it :) diff --git a/Documentation/filesystems/.gitignore b/Documentation/filesystems/.gitignore new file mode 100644 index 000000000000..31d6e426b6d4 --- /dev/null +++ b/Documentation/filesystems/.gitignore @@ -0,0 +1 @@ +dnotify_test diff --git a/Documentation/filesystems/Makefile b/Documentation/filesystems/Makefile index a5dd114da14f..13483d192ebb 100644 --- a/Documentation/filesystems/Makefile +++ b/Documentation/filesystems/Makefile @@ -1,5 +1,4 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o +subdir-y := configfs # List of programs to build hostprogs-y := dnotify_test diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt index 54c8f9706a95..c8656dd029a9 100644 --- a/Documentation/hid/uhid.txt +++ b/Documentation/hid/uhid.txt @@ -1,28 +1,13 @@ UHID - User-space I/O driver support for HID subsystem ======================================================== -The HID subsystem needs two kinds of drivers. In this document we call them: +UHID allows user-space to implement HID transport drivers. Please see +hid-transport.txt for an introduction into HID transport drivers. This document +relies heavily on the definitions declared there. - 1. The "HID I/O Driver" is the driver that performs raw data I/O to the - low-level device. Internally, they register an hid_ll_driver structure with - the HID core. They perform device setup, read raw data from the device and - push it into the HID subsystem and they provide a callback so the HID - subsystem can send data to the device. - - 2. The "HID Device Driver" is the driver that parses HID reports and reacts on - them. There are generic drivers like "generic-usb" and "generic-bluetooth" - which adhere to the HID specification and provide the standardizes features. - But there may be special drivers and quirks for each non-standard device out - there. Internally, they use the hid_driver structure. - -Historically, the USB stack was the first subsystem to provide an HID I/O -Driver. However, other standards like Bluetooth have adopted the HID specs and -may provide HID I/O Drivers, too. The UHID driver allows to implement HID I/O -Drivers in user-space and feed the data into the kernel HID-subsystem. - -This allows user-space to operate on the same level as USB-HID, Bluetooth-HID -and similar. It does not provide a way to write HID Device Drivers, though. Use -hidraw for this purpose. +With UHID, a user-space transport driver can create kernel hid-devices for each +device connected to the user-space controlled bus. The UHID API defines the I/O +events provided from the kernel to user-space and vice versa. There is an example user-space application in ./samples/uhid/uhid-example.c @@ -42,8 +27,9 @@ by setting O_NONBLOCK. struct uhid_event { __u32 type; union { - struct uhid_create_req create; - struct uhid_data_req data; + struct uhid_create2_req create2; + struct uhid_output_req output; + struct uhid_input2_req input2; ... } u; }; @@ -54,8 +40,11 @@ multiple write()'s. A single event must always be sent as a whole. Furthermore, only a single event can be sent per read() or write(). Pending data is ignored. If you want to handle multiple events in a single syscall, then use vectored I/O with readv()/writev(). +The "type" field defines the payload. For each type, there is a +payload-structure available in the union "u" (except for empty payloads). This +payload contains management and/or device data. -The first thing you should do is sending an UHID_CREATE event. This will +The first thing you should do is sending an UHID_CREATE2 event. This will register the device. UHID will respond with an UHID_START event. You can now start sending data to and reading data from UHID. However, unless UHID sends the UHID_OPEN event, the internally attached HID Device Driver has no user attached. @@ -69,12 +58,20 @@ ref-counting for you. You may decide to ignore UHID_OPEN/UHID_CLOSE, though. I/O is allowed even though the device may have no users. -If you want to send data to the HID subsystem, you send an HID_INPUT event with -your raw data payload. If the kernel wants to send data to the device, you will -read an UHID_OUTPUT or UHID_OUTPUT_EV event. +If you want to send data on the interrupt channel to the HID subsystem, you send +an HID_INPUT2 event with your raw data payload. If the kernel wants to send data +on the interrupt channel to the device, you will read an UHID_OUTPUT event. +Data requests on the control channel are currently limited to GET_REPORT and +SET_REPORT (no other data reports on the control channel are defined so far). +Those requests are always synchronous. That means, the kernel sends +UHID_GET_REPORT and UHID_SET_REPORT events and requires you to forward them to +the device on the control channel. Once the device responds, you must forward +the response via UHID_GET_REPORT_REPLY and UHID_SET_REPORT_REPLY to the kernel. +The kernel blocks internal driver-execution during such round-trips (times out +after a hard-coded period). If your device disconnects, you should send an UHID_DESTROY event. This will -unregister the device. You can now send UHID_CREATE again to register a new +unregister the device. You can now send UHID_CREATE2 again to register a new device. If you close() the fd, the device is automatically unregistered and destroyed internally. @@ -82,73 +79,79 @@ internally. write() ------- write() allows you to modify the state of the device and feed input data into -the kernel. The following types are supported: UHID_CREATE, UHID_DESTROY and -UHID_INPUT. The kernel will parse the event immediately and if the event ID is +the kernel. The kernel will parse the event immediately and if the event ID is not supported, it will return -EOPNOTSUPP. If the payload is invalid, then -EINVAL is returned, otherwise, the amount of data that was read is returned and -the request was handled successfully. +the request was handled successfully. O_NONBLOCK does not affect write() as +writes are always handled immediately in a non-blocking fashion. Future requests +might make use of O_NONBLOCK, though. - UHID_CREATE: + UHID_CREATE2: This creates the internal HID device. No I/O is possible until you send this - event to the kernel. The payload is of type struct uhid_create_req and + event to the kernel. The payload is of type struct uhid_create2_req and contains information about your device. You can start I/O now. - UHID_CREATE2: - Same as UHID_CREATE, but the HID report descriptor data (rd_data) is an array - inside struct uhid_create2_req, instead of a pointer to a separate array. - Enables use from languages that don't support pointers, e.g. Python. - UHID_DESTROY: This destroys the internal HID device. No further I/O will be accepted. There may still be pending messages that you can receive with read() but no further UHID_INPUT events can be sent to the kernel. - You can create a new device by sending UHID_CREATE again. There is no need to + You can create a new device by sending UHID_CREATE2 again. There is no need to reopen the character device. - UHID_INPUT: - You must send UHID_CREATE before sending input to the kernel! This event - contains a data-payload. This is the raw data that you read from your device. - The kernel will parse the HID reports and react on it. - UHID_INPUT2: - Same as UHID_INPUT, but the data array is the last field of uhid_input2_req. - Enables userspace to write only the required bytes to kernel (ev.type + - ev.u.input2.size + the part of the data array that matters), instead of - the entire struct uhid_input2_req. - - UHID_FEATURE_ANSWER: - If you receive a UHID_FEATURE request you must answer with this request. You - must copy the "id" field from the request into the answer. Set the "err" field - to 0 if no error occurred or to EIO if an I/O error occurred. + You must send UHID_CREATE2 before sending input to the kernel! This event + contains a data-payload. This is the raw data that you read from your device + on the interrupt channel. The kernel will parse the HID reports. + + UHID_GET_REPORT_REPLY: + If you receive a UHID_GET_REPORT request you must answer with this request. + You must copy the "id" field from the request into the answer. Set the "err" + field to 0 if no error occurred or to EIO if an I/O error occurred. If "err" is 0 then you should fill the buffer of the answer with the results - of the feature request and set "size" correspondingly. + of the GET_REPORT request and set "size" correspondingly. + + UHID_SET_REPORT_REPLY: + This is the SET_REPORT equivalent of UHID_GET_REPORT_REPLY. Unlike GET_REPORT, + SET_REPORT never returns a data buffer, therefore, it's sufficient to set the + "id" and "err" fields correctly. read() ------ -read() will return a queued output report. These output reports can be of type -UHID_START, UHID_STOP, UHID_OPEN, UHID_CLOSE, UHID_OUTPUT or UHID_OUTPUT_EV. No -reaction is required to any of them but you should handle them according to your -needs. Only UHID_OUTPUT and UHID_OUTPUT_EV have payloads. +read() will return a queued output report. No reaction is required to any of +them but you should handle them according to your needs. UHID_START: This is sent when the HID device is started. Consider this as an answer to - UHID_CREATE. This is always the first event that is sent. + UHID_CREATE2. This is always the first event that is sent. Note that this + event might not be available immediately after write(UHID_CREATE2) returns. + Device drivers might required delayed setups. + This event contains a payload of type uhid_start_req. The "dev_flags" field + describes special behaviors of a device. The following flags are defined: + UHID_DEV_NUMBERED_FEATURE_REPORTS: + UHID_DEV_NUMBERED_OUTPUT_REPORTS: + UHID_DEV_NUMBERED_INPUT_REPORTS: + Each of these flags defines whether a given report-type uses numbered + reports. If numbered reports are used for a type, all messages from + the kernel already have the report-number as prefix. Otherwise, no + prefix is added by the kernel. + For messages sent by user-space to the kernel, you must adjust the + prefixes according to these flags. UHID_STOP: This is sent when the HID device is stopped. Consider this as an answer to UHID_DESTROY. - If the kernel HID device driver closes the device manually (that is, you - didn't send UHID_DESTROY) then you should consider this device closed and send - an UHID_DESTROY event. You may want to reregister your device, though. This is - always the last message that is sent to you unless you reopen the device with - UHID_CREATE. + If you didn't destroy your device via UHID_DESTROY, but the kernel sends an + UHID_STOP event, this should usually be ignored. It means that the kernel + reloaded/changed the device driver loaded on your HID device (or some other + maintenance actions happened). + You can usually ignored any UHID_STOP events safely. UHID_OPEN: This is sent when the HID device is opened. That is, the data that the HID device provides is read by some other process. You may ignore this event but it is useful for power-management. As long as you haven't received this event there is actually no other process that reads your data so there is no need to - send UHID_INPUT events to the kernel. + send UHID_INPUT2 events to the kernel. UHID_CLOSE: This is sent when there are no more processes which read the HID data. It is @@ -156,27 +159,29 @@ needs. Only UHID_OUTPUT and UHID_OUTPUT_EV have payloads. UHID_OUTPUT: This is sent if the HID device driver wants to send raw data to the I/O - device. You should read the payload and forward it to the device. The payload - is of type "struct uhid_data_req". + device on the interrupt channel. You should read the payload and forward it to + the device. The payload is of type "struct uhid_data_req". This may be received even though you haven't received UHID_OPEN, yet. - UHID_OUTPUT_EV (obsolete): - Same as UHID_OUTPUT but this contains a "struct input_event" as payload. This - is called for force-feedback, LED or similar events which are received through - an input device by the HID subsystem. You should convert this into raw reports - and send them to your device similar to events of type UHID_OUTPUT. - This is no longer sent by newer kernels. Instead, HID core converts it into a - raw output report and sends it via UHID_OUTPUT. - - UHID_FEATURE: - This event is sent if the kernel driver wants to perform a feature request as - described in the HID specs. The report-type and report-number are available in - the payload. - The kernel serializes feature requests so there will never be two in parallel. - However, if you fail to respond with a UHID_FEATURE_ANSWER in a time-span of 5 - seconds, then the requests will be dropped and a new one might be sent. - Therefore, the payload also contains an "id" field that identifies every - request. - -Document by: - David Herrmann <dh.herrmann@googlemail.com> + UHID_GET_REPORT: + This event is sent if the kernel driver wants to perform a GET_REPORT request + on the control channeld as described in the HID specs. The report-type and + report-number are available in the payload. + The kernel serializes GET_REPORT requests so there will never be two in + parallel. However, if you fail to respond with a UHID_GET_REPORT_REPLY, the + request might silently time out. + Once you read a GET_REPORT request, you shall forward it to the hid device and + remember the "id" field in the payload. Once your hid device responds to the + GET_REPORT (or if it fails), you must send a UHID_GET_REPORT_REPLY to the + kernel with the exact same "id" as in the request. If the request already + timed out, the kernel will ignore the response silently. The "id" field is + never re-used, so conflicts cannot happen. + + UHID_SET_REPORT: + This is the SET_REPORT equivalent of UHID_GET_REPORT. On receipt, you shall + send a SET_REPORT request to your hid device. Once it replies, you must tell + the kernel about it via UHID_SET_REPORT_REPLY. + The same restrictions as for UHID_GET_REPORT apply. + +---------------------------------------------------- +Written 2012, David Herrmann <dh.herrmann@gmail.com> diff --git a/Documentation/ia64/Makefile b/Documentation/ia64/Makefile index b75db69ec483..d493163affe7 100644 --- a/Documentation/ia64/Makefile +++ b/Documentation/ia64/Makefile @@ -1,6 +1,3 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build hostprogs-y := aliasing-test diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 67e93f139b57..d9a452e8fb9b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3540,6 +3540,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. READ_DISC_INFO command); e = NO_READ_CAPACITY_16 (don't use READ_CAPACITY_16 command); + f = NO_REPORT_OPCODES (don't use report opcodes + command, uas only); h = CAPACITY_HEURISTICS (decrease the reported device capacity by one sector if the number is odd); @@ -3559,6 +3561,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. bogus residue values); s = SINGLE_LUN (the device has only one Logical Unit); + t = NO_ATA_1X (don't allow ATA(12) and ATA(16) + commands, uas only); u = IGNORE_UAS (don't bind to the uas driver); w = NO_WP_DETECT (don't test whether the medium is write-protected). diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index b772418bf064..f4f033c8d856 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt @@ -122,7 +122,7 @@ Then as usual to get your report with: Freeing kmemleak internal objects --------------------------------- -To allow access to previosuly found memory leaks after kmemleak has been +To allow access to previously found memory leaks after kmemleak has been disabled by the user or due to an fatal error, internal kmemleak objects won't be freed when kmemleak is disabled, and those objects may occupy a large part of physical memory. diff --git a/Documentation/laptops/.gitignore b/Documentation/laptops/.gitignore new file mode 100644 index 000000000000..da2bd065f4bc --- /dev/null +++ b/Documentation/laptops/.gitignore @@ -0,0 +1,2 @@ +dslm +freefall diff --git a/Documentation/laptops/Makefile b/Documentation/laptops/Makefile index 5cb144af3c09..2b0fa5edf1d3 100644 --- a/Documentation/laptops/Makefile +++ b/Documentation/laptops/Makefile @@ -1,8 +1,5 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build -hostprogs-y := dslm +hostprogs-y := dslm freefall # Tell kbuild to always build the programs always := $(hostprogs-y) diff --git a/Documentation/lockup-watchdogs.txt b/Documentation/lockup-watchdogs.txt index d2a36602ca8d..ab0baa692c13 100644 --- a/Documentation/lockup-watchdogs.txt +++ b/Documentation/lockup-watchdogs.txt @@ -12,7 +12,7 @@ stack trace is displayed upon detection and, by default, the system will stay locked up. Alternatively, the kernel can be configured to panic; a sysctl, "kernel.softlockup_panic", a kernel parameter, "softlockup_panic" (see "Documentation/kernel-parameters.txt" for -details), and a compile option, "BOOTPARAM_HARDLOCKUP_PANIC", are +details), and a compile option, "BOOTPARAM_SOFTLOCKUP_PANIC", are provided for this. A 'hardlockup' is defined as a bug that causes the CPU to loop in diff --git a/Documentation/mic/Makefile b/Documentation/mic/Makefile new file mode 100644 index 000000000000..a191d453badf --- /dev/null +++ b/Documentation/mic/Makefile @@ -0,0 +1 @@ +subdir-y := mpssd diff --git a/Documentation/mic/mpssd/Makefile b/Documentation/mic/mpssd/Makefile index eb860a7d152e..0f3156888048 100644 --- a/Documentation/mic/mpssd/Makefile +++ b/Documentation/mic/mpssd/Makefile @@ -1,19 +1,19 @@ -# -# Makefile - Intel MIC User Space Tools. -# Copyright(c) 2013, Intel Corporation. -# +# List of programs to build +hostprogs-y := mpssd + +mpssd-objs := mpssd.o sysfs.o + +# Tell kbuild to always build the programs +always := $(hostprogs-y) + +HOSTCFLAGS += -I$(objtree)/usr/include -I$(srctree)/tools/include + ifdef DEBUG -CFLAGS += $(USERWARNFLAGS) -I. -g -Wall -DDEBUG=$(DEBUG) -else -CFLAGS += $(USERWARNFLAGS) -I. -g -Wall +HOSTCFLAGS += -DDEBUG=$(DEBUG) endif -mpssd: mpssd.o sysfs.o - $(CC) $(CFLAGS) -o $@ $^ -lpthread +HOSTLOADLIBES_mpssd := -lpthread install: install mpssd /usr/sbin/mpssd install micctrl /usr/sbin/micctrl - -clean: - rm -f mpssd *.o diff --git a/Documentation/mic/mpssd/mpssd.c b/Documentation/mic/mpssd/mpssd.c index 4d17487d5ad9..3c5c379fc29d 100644 --- a/Documentation/mic/mpssd/mpssd.c +++ b/Documentation/mic/mpssd/mpssd.c @@ -41,6 +41,7 @@ #include "mpssd.h" #include <linux/mic_ioctl.h> #include <linux/mic_common.h> +#include <tools/endian.h> static void init_mic(struct mic_info *mic); @@ -1476,9 +1477,9 @@ set_cmdline(struct mic_info *mic) len = snprintf(buffer, PATH_MAX, "clocksource=tsc highres=off nohz=off "); - len += snprintf(buffer + len, PATH_MAX, + len += snprintf(buffer + len, PATH_MAX - len, "cpufreq_on;corec6_off;pc3_off;pc6_off "); - len += snprintf(buffer + len, PATH_MAX, + len += snprintf(buffer + len, PATH_MAX - len, "ifcfg=static;address,172.31.%d.1;netmask,255.255.255.0", mic->id); diff --git a/Documentation/mips/AU1xxx_IDE.README b/Documentation/mips/AU1xxx_IDE.README index cc887ecfd6eb..52844a58cc8a 100644 --- a/Documentation/mips/AU1xxx_IDE.README +++ b/Documentation/mips/AU1xxx_IDE.README @@ -2,7 +2,7 @@ README for MIPS AU1XXX IDE driver - Released 2005-07-15 ABOUT ----- -This file describes the 'drivers/ide/mips/au1xxx-ide.c', related files and the +This file describes the 'drivers/ide/au1xxx-ide.c', related files and the services they provide. If you are short in patience and just want to know how to add your hard disc to diff --git a/Documentation/misc-devices/Makefile b/Documentation/misc-devices/Makefile new file mode 100644 index 000000000000..e2b7aa4c9e21 --- /dev/null +++ b/Documentation/misc-devices/Makefile @@ -0,0 +1 @@ +subdir-y := mei diff --git a/Documentation/misc-devices/mei/Makefile b/Documentation/misc-devices/mei/Makefile index 00e8c3e836ff..d758047d1b6d 100644 --- a/Documentation/misc-devices/mei/Makefile +++ b/Documentation/misc-devices/mei/Makefile @@ -1,6 +1,3 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build hostprogs-y := mei-amt-version HOSTCFLAGS_mei-amt-version.o += -I$(objtree)/usr/include diff --git a/Documentation/networking/.gitignore b/Documentation/networking/.gitignore deleted file mode 100644 index e69de29bb2d1..000000000000 --- a/Documentation/networking/.gitignore +++ /dev/null diff --git a/Documentation/networking/Makefile b/Documentation/networking/Makefile index 0aa1ac98fc2b..4c5d7c485439 100644 --- a/Documentation/networking/Makefile +++ b/Documentation/networking/Makefile @@ -1,7 +1 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - -# Tell kbuild to always build the programs -always := $(hostprogs-y) - -obj-m := timestamping/ +subdir-y := timestamping diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index c48a9704bda8..f4db0972ea38 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -462,9 +462,9 @@ JIT compiler ------------ The Linux kernel has a built-in BPF JIT compiler for x86_64, SPARC, PowerPC, -ARM and s390 and can be enabled through CONFIG_BPF_JIT. The JIT compiler is -transparently invoked for each attached filter from user space or for internal -kernel users if it has been previously enabled by root: +ARM, ARM64, MIPS and s390 and can be enabled through CONFIG_BPF_JIT. The JIT +compiler is transparently invoked for each attached filter from user space +or for internal kernel users if it has been previously enabled by root: echo 1 > /proc/sys/net/core/bpf_jit_enable diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 29a93518bf18..caedb18d4564 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -580,12 +580,6 @@ tcp_workaround_signed_windows - BOOLEAN not receive a window scaling option from them. Default: 0 -tcp_dma_copybreak - INTEGER - Lower limit, in bytes, of the size of socket reads that will be - offloaded to a DMA copy engine, if one is present in the system - and CONFIG_NET_DMA is enabled. - Default: 4096 - tcp_thin_linear_timeouts - BOOLEAN Enable dynamic triggering of linear timeouts for thin streams. If set, a check is performed upon retransmission by timeout to diff --git a/Documentation/networking/timestamping/.gitignore b/Documentation/networking/timestamping/.gitignore index a380159765ce..9e69e982fb38 100644 --- a/Documentation/networking/timestamping/.gitignore +++ b/Documentation/networking/timestamping/.gitignore @@ -1,2 +1,3 @@ timestamping +txtimestamp hwtstamp_config diff --git a/Documentation/networking/timestamping/Makefile b/Documentation/networking/timestamping/Makefile index d934afc8306a..52ac67da9315 100644 --- a/Documentation/networking/timestamping/Makefile +++ b/Documentation/networking/timestamping/Makefile @@ -1,14 +1,8 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build -hostprogs-y := timestamping hwtstamp_config +hostprogs-y := hwtstamp_config timestamping # Tell kbuild to always build the programs always := $(hostprogs-y) HOSTCFLAGS_timestamping.o += -I$(objtree)/usr/include HOSTCFLAGS_hwtstamp_config.o += -I$(objtree)/usr/include - -clean: - rm -f timestamping hwtstamp_config diff --git a/Documentation/pcmcia/Makefile b/Documentation/pcmcia/Makefile index accde871ae77..47a8fa162683 100644 --- a/Documentation/pcmcia/Makefile +++ b/Documentation/pcmcia/Makefile @@ -1,6 +1,3 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build hostprogs-y := crc32hash diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 23f1590f49fe..b8f2147b96dd 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -702,7 +702,7 @@ static int foo_get_groups(struct pinctrl_dev *pctldev, unsigned selector, return 0; } -int foo_enable(struct pinctrl_dev *pctldev, unsigned selector, +int foo_set_mux(struct pinctrl_dev *pctldev, unsigned selector, unsigned group) { u8 regbit = (1 << selector + group); @@ -711,21 +711,11 @@ int foo_enable(struct pinctrl_dev *pctldev, unsigned selector, return 0; } -void foo_disable(struct pinctrl_dev *pctldev, unsigned selector, - unsigned group) -{ - u8 regbit = (1 << selector + group); - - writeb((readb(MUX) & ~(regbit)), MUX) - return 0; -} - struct pinmux_ops foo_pmxops = { .get_functions_count = foo_get_functions_count, .get_function_name = foo_get_fname, .get_function_groups = foo_get_groups, - .enable = foo_enable, - .disable = foo_disable, + .set_mux = foo_set_mux, }; /* Pinmux operations are handled by some pin controller */ diff --git a/Documentation/prctl/.gitignore b/Documentation/prctl/.gitignore new file mode 100644 index 000000000000..0b5c27447bf6 --- /dev/null +++ b/Documentation/prctl/.gitignore @@ -0,0 +1,3 @@ +disable-tsc-ctxt-sw-stress-test +disable-tsc-on-off-stress-test +disable-tsc-test diff --git a/Documentation/prctl/Makefile b/Documentation/prctl/Makefile new file mode 100644 index 000000000000..3e3232dcb2b8 --- /dev/null +++ b/Documentation/prctl/Makefile @@ -0,0 +1,8 @@ +# List of programs to build +hostprogs-y := disable-tsc-ctxt-sw-stress-test disable-tsc-on-off-stress-test disable-tsc-test +# Tell kbuild to always build the programs +always := $(hostprogs-y) + +HOSTCFLAGS_disable-tsc-ctxt-sw-stress-test.o += -I$(objtree)/usr/include +HOSTCFLAGS_disable-tsc-on-off-stress-test.o += -I$(objtree)/usr/include +HOSTCFLAGS_disable-tsc-test.o += -I$(objtree)/usr/include diff --git a/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c b/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c index f8e8e95e81fd..81fdd425ab3e 100644 --- a/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c +++ b/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c @@ -27,19 +27,20 @@ # define PR_TSC_SIGSEGV 2 /* throw a SIGSEGV instead of reading the TSC */ #endif -uint64_t rdtsc() { +static uint64_t rdtsc(void) +{ uint32_t lo, hi; /* We cannot use "=A", since this would use %rax on x86_64 */ __asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi)); return (uint64_t)hi << 32 | lo; } -void sigsegv_expect(int sig) +static void sigsegv_expect(int sig) { /* */ } -void segvtask(void) +static void segvtask(void) { if (prctl(PR_SET_TSC, PR_TSC_SIGSEGV) < 0) { @@ -54,13 +55,13 @@ void segvtask(void) } -void sigsegv_fail(int sig) +static void sigsegv_fail(int sig) { fprintf(stderr, "FATAL ERROR, rdtsc() failed while enabled\n"); exit(0); } -void rdtsctask(void) +static void rdtsctask(void) { if (prctl(PR_SET_TSC, PR_TSC_ENABLE) < 0) { diff --git a/Documentation/prctl/disable-tsc-on-off-stress-test.c b/Documentation/prctl/disable-tsc-on-off-stress-test.c index 1fcd91445375..4d83a27627f9 100644 --- a/Documentation/prctl/disable-tsc-on-off-stress-test.c +++ b/Documentation/prctl/disable-tsc-on-off-stress-test.c @@ -29,7 +29,8 @@ /* snippet from wikipedia :-) */ -uint64_t rdtsc() { +static uint64_t rdtsc(void) +{ uint32_t lo, hi; /* We cannot use "=A", since this would use %rax on x86_64 */ __asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi)); @@ -38,7 +39,7 @@ return (uint64_t)hi << 32 | lo; int should_segv = 0; -void sigsegv_cb(int sig) +static void sigsegv_cb(int sig) { if (!should_segv) { @@ -55,7 +56,7 @@ void sigsegv_cb(int sig) rdtsc(); } -void task(void) +static void task(void) { signal(SIGSEGV, sigsegv_cb); alarm(10); diff --git a/Documentation/prctl/disable-tsc-test.c b/Documentation/prctl/disable-tsc-test.c index 843c81eac235..2541e65cb64b 100644 --- a/Documentation/prctl/disable-tsc-test.c +++ b/Documentation/prctl/disable-tsc-test.c @@ -29,14 +29,15 @@ const char *tsc_names[] = [PR_TSC_SIGSEGV] = "PR_TSC_SIGSEGV", }; -uint64_t rdtsc() { +static uint64_t rdtsc(void) +{ uint32_t lo, hi; /* We cannot use "=A", since this would use %rax on x86_64 */ __asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi)); return (uint64_t)hi << 32 | lo; } -void sigsegv_cb(int sig) +static void sigsegv_cb(int sig) { int tsc_val = 0; diff --git a/Documentation/ptp/.gitignore b/Documentation/ptp/.gitignore new file mode 100644 index 000000000000..f562e49d6917 --- /dev/null +++ b/Documentation/ptp/.gitignore @@ -0,0 +1 @@ +testptp diff --git a/Documentation/ptp/Makefile b/Documentation/ptp/Makefile new file mode 100644 index 000000000000..293d6c09a11f --- /dev/null +++ b/Documentation/ptp/Makefile @@ -0,0 +1,8 @@ +# List of programs to build +hostprogs-y := testptp + +# Tell kbuild to always build the programs +always := $(hostprogs-y) + +HOSTCFLAGS_testptp.o += -I$(objtree)/usr/include +HOSTLOADLIBES_testptp := -lrt diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c index ba1d50200c46..2bc8abc57fa0 100644 --- a/Documentation/ptp/testptp.c +++ b/Documentation/ptp/testptp.c @@ -500,11 +500,11 @@ int main(int argc, char *argv[]) interval = t2 - t1; offset = (t2 + t1) / 2 - tp; - printf("system time: %" PRId64 ".%u\n", + printf("system time: %lld.%u\n", (pct+2*i)->sec, (pct+2*i)->nsec); - printf("phc time: %" PRId64 ".%u\n", + printf("phc time: %lld.%u\n", (pct+2*i+1)->sec, (pct+2*i+1)->nsec); - printf("system time: %" PRId64 ".%u\n", + printf("system time: %lld.%u\n", (pct+2*i+2)->sec, (pct+2*i+2)->nsec); printf("system/phc clock time offset is %" PRId64 " ns\n" "system clock time delay is %" PRId64 " ns\n", diff --git a/Documentation/ptp/testptp.mk b/Documentation/ptp/testptp.mk deleted file mode 100644 index 4ef2d9755421..000000000000 --- a/Documentation/ptp/testptp.mk +++ /dev/null @@ -1,33 +0,0 @@ -# PTP 1588 clock support - User space test program -# -# Copyright (C) 2010 OMICRON electronics GmbH -# -# 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. - -CC = $(CROSS_COMPILE)gcc -INC = -I$(KBUILD_OUTPUT)/usr/include -CFLAGS = -Wall $(INC) -LDLIBS = -lrt -PROGS = testptp - -all: $(PROGS) - -testptp: testptp.o - -clean: - rm -f testptp.o - -distclean: clean - rm -f $(PROGS) diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 91ba58ef02d7..18b570990040 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,17 @@ +Release Date : Thu. Jun 19, 2014 17:00:00 PST 2014 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford + Kashyap Desai + Sumit Saxena + Uday Lingala +Current Version : 06.803.02.00-rc1 +Old Version : 06.803.01.00-rc1 + 1. Fix reset_mutex leak in megasas_reset_fusion(). + 2. Remove unused variables in megasas_instance. + 3. Fix LD/VF affiliation parsing. + 4. Add missing initial call to megasas_get_ld_vf_affiliation(). + 5. Version and Changelog update. +------------------------------------------------------------------------------- Release Date : Mon. Mar 10, 2014 17:00:00 PST 2014 - (emaild-id:megaraidlinux@lsi.com) Adam Radford diff --git a/Documentation/serial/tty.txt b/Documentation/serial/tty.txt index 540db41dfd5d..1e52d67d0abf 100644 --- a/Documentation/serial/tty.txt +++ b/Documentation/serial/tty.txt @@ -146,7 +146,7 @@ set_termios() Notify the tty driver that the device's termios driver function is responsible for modifying any bits in the request it cannot fulfill to indicate the actual modes being used. A device with no - hardware capability for change (eg a USB dongle or + hardware capability for change (e.g. a USB dongle or virtual port) can provide NULL for this method. throttle() Notify the tty driver that input buffers for the @@ -258,7 +258,7 @@ put_char() - Stuff a single character onto the queue. The flush_chars() - Ask the kernel to write put_char queue -write_room() - Return the number of characters tht can be stuffed +write_room() - Return the number of characters that can be stuffed into the port buffers without overflow (or less). The ldisc is responsible for being intelligent about multi-threading of write_room/write calls diff --git a/Documentation/spi/Makefile b/Documentation/spi/Makefile index a5b03c88beae..efa255813e9d 100644 --- a/Documentation/spi/Makefile +++ b/Documentation/spi/Makefile @@ -1,6 +1,3 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build hostprogs-y := spidev_test spidev_fdx diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 7982bcc4d151..d29734bff28c 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -601,13 +601,13 @@ THANKS TO Contributors to Linux-SPI discussions include (in alphabetical order, by last name): +Mark Brown David Brownell Russell King +Grant Likely Dmitry Pervushin Stephen Street Mark Underwood Andrew Victor -Vitaly Wool -Grant Likely -Mark Brown Linus Walleij +Vitaly Wool diff --git a/Documentation/this_cpu_ops.txt b/Documentation/this_cpu_ops.txt index 0ec995712176..2cbf71975381 100644 --- a/Documentation/this_cpu_ops.txt +++ b/Documentation/this_cpu_ops.txt @@ -41,7 +41,6 @@ The following this_cpu() operations with implied preemption protection are defined. These operations can be used without worrying about preemption and interrupts. - this_cpu_add() this_cpu_read(pcp) this_cpu_write(pcp, val) this_cpu_add(pcp, val) @@ -225,7 +224,6 @@ still occur while an operation is in progress and if the interrupt too modifies the variable, then RMW actions can not be guaranteed to be safe. - __this_cpu_add() __this_cpu_read(pcp) __this_cpu_write(pcp, val) __this_cpu_add(pcp, val) diff --git a/Documentation/timers/.gitignore b/Documentation/timers/.gitignore new file mode 100644 index 000000000000..c5c45d7ec0df --- /dev/null +++ b/Documentation/timers/.gitignore @@ -0,0 +1 @@ +hpet_example diff --git a/Documentation/timers/Makefile b/Documentation/timers/Makefile index 73f75f8a87dc..6c09ee6ca721 100644 --- a/Documentation/timers/Makefile +++ b/Documentation/timers/Makefile @@ -1,6 +1,3 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build hostprogs-$(CONFIG_X86) := hpet_example diff --git a/Documentation/usb/WUSB-Design-overview.txt b/Documentation/usb/WUSB-Design-overview.txt index 1cd07c017cf6..fdb47637720e 100644 --- a/Documentation/usb/WUSB-Design-overview.txt +++ b/Documentation/usb/WUSB-Design-overview.txt @@ -161,19 +161,10 @@ now on), such as to start/stop beaconing, scan, allocate bandwidth, etc. The main building block here is the UWB device (struct uwb_dev). For each device that pops up in radio presence (ie: the UWB host receives a beacon from it) you get a struct uwb_dev that will show up in -/sys/class/uwb and in /sys/bus/uwb/devices. +/sys/bus/uwb/devices. -For each RC that is detected, a new struct uwb_rc is created. In turn, a -RC is also a device, so they also show in /sys/class/uwb and -/sys/bus/uwb/devices, but at the same time, only radio controllers show -up in /sys/class/uwb_rc. - - * - - [*] The reason for RCs being also devices is that not only we can - see them while enumerating the system device tree, but also on the - radio (their beacons and stuff), so the handling has to be - likewise to that of a device. +For each RC that is detected, a new struct uwb_rc and struct uwb_dev are +created. An entry is also created in /sys/class/uwb_rc for each RC. Each RC driver is implemented by a separate driver that plugs into the interface that the UWB stack provides through a struct uwb_rc_ops. The @@ -246,7 +237,7 @@ the beacon cache of dead devices]. Device lists -All UWB devices are kept in the list of the struct bus_type uwb_bus. +All UWB devices are kept in the list of the struct bus_type uwb_bus_type. Bandwidth allocation @@ -317,7 +308,7 @@ HC picks the /DN_Connect/ out (nep module sends to notif.c for delivery into /devconnect/). This process starts the authentication process for the device. First we allocate a /fake port/ and assign an unauthenticated address (128 to 255--what we really do is -0x80 | fake_port_idx). We fiddle with the fake port status and /khubd/ +0x80 | fake_port_idx). We fiddle with the fake port status and /hub_wq/ sees a new connection, so he moves on to enable the fake port with a reset. So now we are in the reset path -- we know we have a non-yet enumerated @@ -326,7 +317,7 @@ device with an unauthorized address; we ask user space to authenticate exchange (FIXME: not yet done) and issue a /set address 0/ to bring the device to the default state. Device is authenticated. -From here, the USB stack takes control through the usb_hcd ops. khubd +From here, the USB stack takes control through the usb_hcd ops. hub_wq has seen the port status changes, as we have been toggling them. It will start enumerating and doing transfers through usb_hcd->urb_enqueue() to read descriptors and move our data. @@ -340,7 +331,7 @@ Keep Alive IE; it responds with a /DN_Alive/ pong during the DNTS (this arrives to us as a notification through devconnect.c:wusb_handle_dn_alive(). If a device times out, we disconnect it from the system (cleaning up internal information and -toggling the bits in the fake hub port, which kicks khubd into removing +toggling the bits in the fake hub port, which kicks hub_wq into removing the rest of the stuff). This is done through devconnect:__wusb_check_devs(), which will scan the diff --git a/Documentation/usb/hotplug.txt b/Documentation/usb/hotplug.txt index a80b0e9a7a0b..5b243f315b2c 100644 --- a/Documentation/usb/hotplug.txt +++ b/Documentation/usb/hotplug.txt @@ -58,7 +58,7 @@ USB POLICY AGENT The USB subsystem currently invokes /sbin/hotplug when USB devices are added or removed from system. The invocation is done by the kernel -hub daemon thread [khubd], or else as part of root hub initialization +hub workqueue [hub_wq], or else as part of root hub initialization (done by init, modprobe, kapmd, etc). Its single command line parameter is the string "usb", and it passes these environment variables: diff --git a/Documentation/vDSO/.gitignore b/Documentation/vDSO/.gitignore new file mode 100644 index 000000000000..133bf9ee986c --- /dev/null +++ b/Documentation/vDSO/.gitignore @@ -0,0 +1,2 @@ +vdso_test +vdso_standalone_test_x86 diff --git a/Documentation/vDSO/Makefile b/Documentation/vDSO/Makefile new file mode 100644 index 000000000000..2b99e57207c1 --- /dev/null +++ b/Documentation/vDSO/Makefile @@ -0,0 +1,12 @@ +# vdso_test won't build for glibc < 2.16, so disable it +# hostprogs-y := vdso_test +hostprogs-$(CONFIG_X86) := vdso_standalone_test_x86 +vdso_standalone_test_x86-objs := vdso_standalone_test_x86.o parse_vdso.o +vdso_test-objs := parse_vdso.o vdso_test.o + +# Tell kbuild to always build the programs +always := $(hostprogs-y) + +HOSTCFLAGS := -I$(objtree)/usr/include -std=gnu99 +HOSTCFLAGS_vdso_standalone_test_x86.o := -fno-asynchronous-unwind-tables -fno-stack-protector +HOSTLOADLIBES_vdso_standalone_test_x86 := -nostdlib diff --git a/Documentation/video4linux/.gitignore b/Documentation/video4linux/.gitignore deleted file mode 100644 index 952703943e8e..000000000000 --- a/Documentation/video4linux/.gitignore +++ /dev/null @@ -1 +0,0 @@ -v4lgrab diff --git a/Documentation/video4linux/Makefile b/Documentation/video4linux/Makefile new file mode 100644 index 000000000000..65a351d75c95 --- /dev/null +++ b/Documentation/video4linux/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_PCI_SKELETON) := v4l2-pci-skeleton.o diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index beae3fde075e..7610eaa4d491 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -1901,6 +1901,8 @@ registers, find a list below: PPC | KVM_REG_PPC_ARCH_COMPAT | 32 PPC | KVM_REG_PPC_DABRX | 32 PPC | KVM_REG_PPC_WORT | 64 + PPC | KVM_REG_PPC_SPRG9 | 64 + PPC | KVM_REG_PPC_DBSR | 32 PPC | KVM_REG_PPC_TM_GPR0 | 64 ... PPC | KVM_REG_PPC_TM_GPR31 | 64 @@ -2565,6 +2567,120 @@ associated with the service will be forgotten, and subsequent RTAS calls by the guest for that service will be passed to userspace to be handled. +4.87 KVM_SET_GUEST_DEBUG + +Capability: KVM_CAP_SET_GUEST_DEBUG +Architectures: x86, s390, ppc +Type: vcpu ioctl +Parameters: struct kvm_guest_debug (in) +Returns: 0 on success; -1 on error + +struct kvm_guest_debug { + __u32 control; + __u32 pad; + struct kvm_guest_debug_arch arch; +}; + +Set up the processor specific debug registers and configure vcpu for +handling guest debug events. There are two parts to the structure, the +first a control bitfield indicates the type of debug events to handle +when running. Common control bits are: + + - KVM_GUESTDBG_ENABLE: guest debugging is enabled + - KVM_GUESTDBG_SINGLESTEP: the next run should single-step + +The top 16 bits of the control field are architecture specific control +flags which can include the following: + + - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86] + - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390] + - KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86] + - KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86] + - KVM_GUESTDBG_EXIT_PENDING: trigger an immediate guest exit [s390] + +For example KVM_GUESTDBG_USE_SW_BP indicates that software breakpoints +are enabled in memory so we need to ensure breakpoint exceptions are +correctly trapped and the KVM run loop exits at the breakpoint and not +running off into the normal guest vector. For KVM_GUESTDBG_USE_HW_BP +we need to ensure the guest vCPUs architecture specific registers are +updated to the correct (supplied) values. + +The second part of the structure is architecture specific and +typically contains a set of debug registers. + +When debug events exit the main run loop with the reason +KVM_EXIT_DEBUG with the kvm_debug_exit_arch part of the kvm_run +structure containing architecture specific debug information. + +4.88 KVM_GET_EMULATED_CPUID + +Capability: KVM_CAP_EXT_EMUL_CPUID +Architectures: x86 +Type: system ioctl +Parameters: struct kvm_cpuid2 (in/out) +Returns: 0 on success, -1 on error + +struct kvm_cpuid2 { + __u32 nent; + __u32 flags; + struct kvm_cpuid_entry2 entries[0]; +}; + +The member 'flags' is used for passing flags from userspace. + +#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX BIT(0) +#define KVM_CPUID_FLAG_STATEFUL_FUNC BIT(1) +#define KVM_CPUID_FLAG_STATE_READ_NEXT BIT(2) + +struct kvm_cpuid_entry2 { + __u32 function; + __u32 index; + __u32 flags; + __u32 eax; + __u32 ebx; + __u32 ecx; + __u32 edx; + __u32 padding[3]; +}; + +This ioctl returns x86 cpuid features which are emulated by +kvm.Userspace can use the information returned by this ioctl to query +which features are emulated by kvm instead of being present natively. + +Userspace invokes KVM_GET_EMULATED_CPUID by passing a kvm_cpuid2 +structure with the 'nent' field indicating the number of entries in +the variable-size array 'entries'. If the number of entries is too low +to describe the cpu capabilities, an error (E2BIG) is returned. If the +number is too high, the 'nent' field is adjusted and an error (ENOMEM) +is returned. If the number is just right, the 'nent' field is adjusted +to the number of valid entries in the 'entries' array, which is then +filled. + +The entries returned are the set CPUID bits of the respective features +which kvm emulates, as returned by the CPUID instruction, with unknown +or unsupported feature bits cleared. + +Features like x2apic, for example, may not be present in the host cpu +but are exposed by kvm in KVM_GET_SUPPORTED_CPUID because they can be +emulated efficiently and thus not included here. + +The fields in each entry are defined as follows: + + function: the eax value used to obtain the entry + index: the ecx value used to obtain the entry (for entries that are + affected by ecx) + flags: an OR of zero or more of the following: + KVM_CPUID_FLAG_SIGNIFCANT_INDEX: + if the index field is valid + KVM_CPUID_FLAG_STATEFUL_FUNC: + if cpuid for this function returns different values for successive + invocations; there will be several entries with the same function, + all with this flag set + KVM_CPUID_FLAG_STATE_READ_NEXT: + for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is + the first entry to be read by a cpu + eax, ebx, ecx, edx: the values returned by the cpuid instruction for + this function/index combination 5. The kvm_run structure ------------------------ @@ -2861,78 +2977,12 @@ kvm_valid_regs for specific bits. These bits are architecture specific and usually define the validity of a groups of registers. (e.g. one bit for general purpose registers) -}; - +Please note that the kernel is allowed to use the kvm_run structure as the +primary storage for certain register types. Therefore, the kernel may use the +values in kvm_run even if the corresponding bit in kvm_dirty_regs is not set. -4.81 KVM_GET_EMULATED_CPUID - -Capability: KVM_CAP_EXT_EMUL_CPUID -Architectures: x86 -Type: system ioctl -Parameters: struct kvm_cpuid2 (in/out) -Returns: 0 on success, -1 on error - -struct kvm_cpuid2 { - __u32 nent; - __u32 flags; - struct kvm_cpuid_entry2 entries[0]; }; -The member 'flags' is used for passing flags from userspace. - -#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX BIT(0) -#define KVM_CPUID_FLAG_STATEFUL_FUNC BIT(1) -#define KVM_CPUID_FLAG_STATE_READ_NEXT BIT(2) - -struct kvm_cpuid_entry2 { - __u32 function; - __u32 index; - __u32 flags; - __u32 eax; - __u32 ebx; - __u32 ecx; - __u32 edx; - __u32 padding[3]; -}; - -This ioctl returns x86 cpuid features which are emulated by -kvm.Userspace can use the information returned by this ioctl to query -which features are emulated by kvm instead of being present natively. - -Userspace invokes KVM_GET_EMULATED_CPUID by passing a kvm_cpuid2 -structure with the 'nent' field indicating the number of entries in -the variable-size array 'entries'. If the number of entries is too low -to describe the cpu capabilities, an error (E2BIG) is returned. If the -number is too high, the 'nent' field is adjusted and an error (ENOMEM) -is returned. If the number is just right, the 'nent' field is adjusted -to the number of valid entries in the 'entries' array, which is then -filled. - -The entries returned are the set CPUID bits of the respective features -which kvm emulates, as returned by the CPUID instruction, with unknown -or unsupported feature bits cleared. - -Features like x2apic, for example, may not be present in the host cpu -but are exposed by kvm in KVM_GET_SUPPORTED_CPUID because they can be -emulated efficiently and thus not included here. - -The fields in each entry are defined as follows: - - function: the eax value used to obtain the entry - index: the ecx value used to obtain the entry (for entries that are - affected by ecx) - flags: an OR of zero or more of the following: - KVM_CPUID_FLAG_SIGNIFCANT_INDEX: - if the index field is valid - KVM_CPUID_FLAG_STATEFUL_FUNC: - if cpuid for this function returns different values for successive - invocations; there will be several entries with the same function, - all with this flag set - KVM_CPUID_FLAG_STATE_READ_NEXT: - for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is - the first entry to be read by a cpu - eax, ebx, ecx, edx: the values returned by the cpuid instruction for - this function/index combination 6. Capabilities that can be enabled on vCPUs diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt index 7f4e91b1316b..df8b0c7540b6 100644 --- a/Documentation/virtual/kvm/devices/arm-vgic.txt +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt @@ -71,3 +71,13 @@ Groups: Errors: -ENODEV: Getting or setting this register is not yet supported -EBUSY: One or more VCPUs are running + + KVM_DEV_ARM_VGIC_GRP_NR_IRQS + Attributes: + A value describing the number of interrupts (SGI, PPI and SPI) for + this GIC instance, ranging from 64 to 1024, in increments of 32. + + Errors: + -EINVAL: Value set is out of the expected range + -EBUSY: Value has already be set, or GIC has already been initialized + with default values. diff --git a/Documentation/virtual/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt index 290894176142..53838d9c6295 100644 --- a/Documentation/virtual/kvm/mmu.txt +++ b/Documentation/virtual/kvm/mmu.txt @@ -425,6 +425,20 @@ fault through the slow path. Since only 19 bits are used to store generation-number on mmio spte, all pages are zapped when there is an overflow. +Unfortunately, a single memory access might access kvm_memslots(kvm) multiple +times, the last one happening when the generation number is retrieved and +stored into the MMIO spte. Thus, the MMIO spte might be created based on +out-of-date information, but with an up-to-date generation number. + +To avoid this, the generation number is incremented again after synchronize_srcu +returns; thus, the low bit of kvm_memslots(kvm)->generation is only 1 during a +memslot update, while some SRCU readers might be using the old copy. We do not +want to use an MMIO sptes created with an odd generation number, and we can do +this without losing a bit in the MMIO spte. The low bit of the generation +is not stored in MMIO spte, and presumed zero when it is extracted out of the +spte. If KVM is unlucky and creates an MMIO spte while the low bit is 1, +the next access to the spte will always be a cache miss. + Further reading =============== diff --git a/Documentation/watchdog/Makefile b/Documentation/watchdog/Makefile new file mode 100644 index 000000000000..6018f45f2471 --- /dev/null +++ b/Documentation/watchdog/Makefile @@ -0,0 +1 @@ +subdir-y := src diff --git a/Documentation/watchdog/src/Makefile b/Documentation/watchdog/src/Makefile index 40e5f46e4740..4a892c304983 100644 --- a/Documentation/watchdog/src/Makefile +++ b/Documentation/watchdog/src/Makefile @@ -1,6 +1,3 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - # List of programs to build hostprogs-y := watchdog-simple watchdog-test diff --git a/Documentation/xillybus.txt b/Documentation/xillybus.txt new file mode 100644 index 000000000000..81d111b4dc28 --- /dev/null +++ b/Documentation/xillybus.txt @@ -0,0 +1,380 @@ + + ========================================== + Xillybus driver for generic FPGA interface + ========================================== + +Author: Eli Billauer, Xillybus Ltd. (http://xillybus.com) +Email: eli.billauer@gmail.com or as advertised on Xillybus' site. + +Contents: + + - Introduction + -- Background + -- Xillybus Overview + + - Usage + -- User interface + -- Synchronization + -- Seekable pipes + +- Internals + -- Source code organization + -- Pipe attributes + -- Host never reads from the FPGA + -- Channels, pipes, and the message channel + -- Data streaming + -- Data granularity + -- Probing + -- Buffer allocation + -- The "nonempty" message (supporting poll) + + +INTRODUCTION +============ + +Background +---------- + +An FPGA (Field Programmable Gate Array) is a piece of logic hardware, which +can be programmed to become virtually anything that is usually found as a +dedicated chipset: For instance, a display adapter, network interface card, +or even a processor with its peripherals. FPGAs are the LEGO of hardware: +Based upon certain building blocks, you make your own toys the way you like +them. It's usually pointless to reimplement something that is already +available on the market as a chipset, so FPGAs are mostly used when some +special functionality is needed, and the production volume is relatively low +(hence not justifying the development of an ASIC). + +The challenge with FPGAs is that everything is implemented at a very low +level, even lower than assembly language. In order to allow FPGA designers to +focus on their specific project, and not reinvent the wheel over and over +again, pre-designed building blocks, IP cores, are often used. These are the +FPGA parallels of library functions. IP cores may implement certain +mathematical functions, a functional unit (e.g. a USB interface), an entire +processor (e.g. ARM) or anything that might come handy. Think of them as a +building block, with electrical wires dangling on the sides for connection to +other blocks. + +One of the daunting tasks in FPGA design is communicating with a fullblown +operating system (actually, with the processor running it): Implementing the +low-level bus protocol and the somewhat higher-level interface with the host +(registers, interrupts, DMA etc.) is a project in itself. When the FPGA's +function is a well-known one (e.g. a video adapter card, or a NIC), it can +make sense to design the FPGA's interface logic specifically for the project. +A special driver is then written to present the FPGA as a well-known interface +to the kernel and/or user space. In that case, there is no reason to treat the +FPGA differently than any device on the bus. + +It's however common that the desired data communication doesn't fit any well- +known peripheral function. Also, the effort of designing an elegant +abstraction for the data exchange is often considered too big. In those cases, +a quicker and possibly less elegant solution is sought: The driver is +effectively written as a user space program, leaving the kernel space part +with just elementary data transport. This still requires designing some +interface logic for the FPGA, and write a simple ad-hoc driver for the kernel. + +Xillybus Overview +----------------- + +Xillybus is an IP core and a Linux driver. Together, they form a kit for +elementary data transport between an FPGA and the host, providing pipe-like +data streams with a straightforward user interface. It's intended as a low- +effort solution for mixed FPGA-host projects, for which it makes sense to +have the project-specific part of the driver running in a user-space program. + +Since the communication requirements may vary significantly from one FPGA +project to another (the number of data pipes needed in each direction and +their attributes), there isn't one specific chunk of logic being the Xillybus +IP core. Rather, the IP core is configured and built based upon a +specification given by its end user. + +Xillybus presents independent data streams, which resemble pipes or TCP/IP +communication to the user. At the host side, a character device file is used +just like any pipe file. On the FPGA side, hardware FIFOs are used to stream +the data. This is contrary to a common method of communicating through fixed- +sized buffers (even though such buffers are used by Xillybus under the hood). +There may be more than a hundred of these streams on a single IP core, but +also no more than one, depending on the configuration. + +In order to ease the deployment of the Xillybus IP core, it contains a simple +data structure which completely defines the core's configuration. The Linux +driver fetches this data structure during its initialization process, and sets +up the DMA buffers and character devices accordingly. As a result, a single +driver is used to work out of the box with any Xillybus IP core. + +The data structure just mentioned should not be confused with PCI's +configuration space or the Flattened Device Tree. + +USAGE +===== + +User interface +-------------- + +On the host, all interface with Xillybus is done through /dev/xillybus_* +device files, which are generated automatically as the drivers loads. The +names of these files depend on the IP core that is loaded in the FPGA (see +Probing below). To communicate with the FPGA, open the device file that +corresponds to the hardware FIFO you want to send data or receive data from, +and use plain write() or read() calls, just like with a regular pipe. In +particular, it makes perfect sense to go: + +$ cat mydata > /dev/xillybus_thisfifo + +$ cat /dev/xillybus_thatfifo > hisdata + +possibly pressing CTRL-C as some stage, even though the xillybus_* pipes have +the capability to send an EOF (but may not use it). + +The driver and hardware are designed to behave sensibly as pipes, including: + +* Supporting non-blocking I/O (by setting O_NONBLOCK on open() ). + +* Supporting poll() and select(). + +* Being bandwidth efficient under load (using DMA) but also handle small + pieces of data sent across (like TCP/IP) by autoflushing. + +A device file can be read only, write only or bidirectional. Bidirectional +device files are treated like two independent pipes (except for sharing a +"channel" structure in the implementation code). + +Synchronization +--------------- + +Xillybus pipes are configured (on the IP core) to be either synchronous or +asynchronous. For a synchronous pipe, write() returns successfully only after +some data has been submitted and acknowledged by the FPGA. This slows down +bulk data transfers, and is nearly impossible for use with streams that +require data at a constant rate: There is no data transmitted to the FPGA +between write() calls, in particular when the process loses the CPU. + +When a pipe is configured asynchronous, write() returns if there was enough +room in the buffers to store any of the data in the buffers. + +For FPGA to host pipes, asynchronous pipes allow data transfer from the FPGA +as soon as the respective device file is opened, regardless of if the data +has been requested by a read() call. On synchronous pipes, only the amount +of data requested by a read() call is transmitted. + +In summary, for synchronous pipes, data between the host and FPGA is +transmitted only to satisfy the read() or write() call currently handled +by the driver, and those calls wait for the transmission to complete before +returning. + +Note that the synchronization attribute has nothing to do with the possibility +that read() or write() completes less bytes than requested. There is a +separate configuration flag ("allowpartial") that determines whether such a +partial completion is allowed. + +Seekable pipes +-------------- + +A synchronous pipe can be configured to have the stream's position exposed +to the user logic at the FPGA. Such a pipe is also seekable on the host API. +With this feature, a memory or register interface can be attached on the +FPGA side to the seekable stream. Reading or writing to a certain address in +the attached memory is done by seeking to the desired address, and calling +read() or write() as required. + + +INTERNALS +========= + +Source code organization +------------------------ + +The Xillybus driver consists of a core module, xillybus_core.c, and modules +that depend on the specific bus interface (xillybus_of.c and xillybus_pcie.c). + +The bus specific modules are those probed when a suitable device is found by +the kernel. Since the DMA mapping and synchronization functions, which are bus +dependent by their nature, are used by the core module, a +xilly_endpoint_hardware structure is passed to the core module on +initialization. This structure is populated with pointers to wrapper functions +which execute the DMA-related operations on the bus. + +Pipe attributes +--------------- + +Each pipe has a number of attributes which are set when the FPGA component +(IP core) is built. They are fetched from the IDT (the data structure which +defines the core's configuration, see Probing below) by xilly_setupchannels() +in xillybus_core.c as follows: + +* is_writebuf: The pipe's direction. A non-zero value means it's an FPGA to + host pipe (the FPGA "writes"). + +* channelnum: The pipe's identification number in communication between the + host and FPGA. + +* format: The underlying data width. See Data Granularity below. + +* allowpartial: A non-zero value means that a read() or write() (whichever + applies) may return with less than the requested number of bytes. The common + choice is a non-zero value, to match standard UNIX behavior. + +* synchronous: A non-zero value means that the pipe is synchronous. See + Syncronization above. + +* bufsize: Each DMA buffer's size. Always a power of two. + +* bufnum: The number of buffers allocated for this pipe. Always a power of two. + +* exclusive_open: A non-zero value forces exclusive opening of the associated + device file. If the device file is bidirectional, and already opened only in + one direction, the opposite direction may be opened once. + +* seekable: A non-zero value indicates that the pipe is seekable. See + Seekable pipes above. + +* supports_nonempty: A non-zero value (which is typical) indicates that the + hardware will send the messages that are necessary to support select() and + poll() for this pipe. + +Host never reads from the FPGA +------------------------------ + +Even though PCI Express is hotpluggable in general, a typical motherboard +doesn't expect a card to go away all of the sudden. But since the PCIe card +is based upon reprogrammable logic, a sudden disappearance from the bus is +quite likely as a result of an accidental reprogramming of the FPGA while the +host is up. In practice, nothing happens immediately in such a situation. But +if the host attempts to read from an address that is mapped to the PCI Express +device, that leads to an immediate freeze of the system on some motherboards, +even though the PCIe standard requires a graceful recovery. + +In order to avoid these freezes, the Xillybus driver refrains completely from +reading from the device's register space. All communication from the FPGA to +the host is done through DMA. In particular, the Interrupt Service Routine +doesn't follow the common practice of checking a status register when it's +invoked. Rather, the FPGA prepares a small buffer which contains short +messages, which inform the host what the interrupt was about. + +This mechanism is used on non-PCIe buses as well for the sake of uniformity. + + +Channels, pipes, and the message channel +---------------------------------------- + +Each of the (possibly bidirectional) pipes presented to the user is allocated +a data channel between the FPGA and the host. The distinction between channels +and pipes is necessary only because of channel 0, which is used for interrupt- +related messages from the FPGA, and has no pipe attached to it. + +Data streaming +-------------- + +Even though a non-segmented data stream is presented to the user at both +sides, the implementation relies on a set of DMA buffers which is allocated +for each channel. For the sake of illustration, let's take the FPGA to host +direction: As data streams into the respective channel's interface in the +FPGA, the Xillybus IP core writes it to one of the DMA buffers. When the +buffer is full, the FPGA informs the host about that (appending a +XILLYMSG_OPCODE_RELEASEBUF message channel 0 and sending an interrupt if +necessary). The host responds by making the data available for reading through +the character device. When all data has been read, the host writes on the +the FPGA's buffer control register, allowing the buffer's overwriting. Flow +control mechanisms exist on both sides to prevent underflows and overflows. + +This is not good enough for creating a TCP/IP-like stream: If the data flow +stops momentarily before a DMA buffer is filled, the intuitive expectation is +that the partial data in buffer will arrive anyhow, despite the buffer not +being completed. This is implemented by adding a field in the +XILLYMSG_OPCODE_RELEASEBUF message, through which the FPGA informs not just +which buffer is submitted, but how much data it contains. + +But the FPGA will submit a partially filled buffer only if directed to do so +by the host. This situation occurs when the read() method has been blocking +for XILLY_RX_TIMEOUT jiffies (currently 10 ms), after which the host commands +the FPGA to submit a DMA buffer as soon as it can. This timeout mechanism +balances between bus bandwidth efficiency (preventing a lot of partially +filled buffers being sent) and a latency held fairly low for tails of data. + +A similar setting is used in the host to FPGA direction. The handling of +partial DMA buffers is somewhat different, though. The user can tell the +driver to submit all data it has in the buffers to the FPGA, by issuing a +write() with the byte count set to zero. This is similar to a flush request, +but it doesn't block. There is also an autoflushing mechanism, which triggers +an equivalent flush roughly XILLY_RX_TIMEOUT jiffies after the last write(). +This allows the user to be oblivious about the underlying buffering mechanism +and yet enjoy a stream-like interface. + +Note that the issue of partial buffer flushing is irrelevant for pipes having +the "synchronous" attribute nonzero, since synchronous pipes don't allow data +to lay around in the DMA buffers between read() and write() anyhow. + +Data granularity +---------------- + +The data arrives or is sent at the FPGA as 8, 16 or 32 bit wide words, as +configured by the "format" attribute. Whenever possible, the driver attempts +to hide this when the pipe is accessed differently from its natural alignment. +For example, reading single bytes from a pipe with 32 bit granularity works +with no issues. Writing single bytes to pipes with 16 or 32 bit granularity +will also work, but the driver can't send partially completed words to the +FPGA, so the transmission of up to one word may be held until it's fully +occupied with user data. + +This somewhat complicates the handling of host to FPGA streams, because +when a buffer is flushed, it may contain up to 3 bytes don't form a word in +the FPGA, and hence can't be sent. To prevent loss of data, these leftover +bytes need to be moved to the next buffer. The parts in xillybus_core.c +that mention "leftovers" in some way are related to this complication. + +Probing +------- + +As mentioned earlier, the number of pipes that are created when the driver +loads and their attributes depend on the Xillybus IP core in the FPGA. During +the driver's initialization, a blob containing configuration info, the +Interface Description Table (IDT), is sent from the FPGA to the host. The +bootstrap process is done in three phases: + +1. Acquire the length of the IDT, so a buffer can be allocated for it. This + is done by sending a quiesce command to the device, since the acknowledge + for this command contains the IDT's buffer length. + +2. Acquire the IDT itself. + +3. Create the interfaces according to the IDT. + +Buffer allocation +----------------- + +In order to simplify the logic that prevents illegal boundary crossings of +PCIe packets, the following rule applies: If a buffer is smaller than 4kB, +it must not cross a 4kB boundary. Otherwise, it must be 4kB aligned. The +xilly_setupchannels() functions allocates these buffers by requesting whole +pages from the kernel, and diving them into DMA buffers as necessary. Since +all buffers' sizes are powers of two, it's possible to pack any set of such +buffers, with a maximal waste of one page of memory. + +All buffers are allocated when the driver is loaded. This is necessary, +since large continuous physical memory segments are sometimes requested, +which are more likely to be available when the system is freshly booted. + +The allocation of buffer memory takes place in the same order they appear in +the IDT. The driver relies on a rule that the pipes are sorted with decreasing +buffer size in the IDT. If a requested buffer is larger or equal to a page, +the necessary number of pages is requested from the kernel, and these are +used for this buffer. If the requested buffer is smaller than a page, one +single page is requested from the kernel, and that page is partially used. +Or, if there already is a partially used page at hand, the buffer is packed +into that page. It can be shown that all pages requested from the kernel +(except possibly for the last) are 100% utilized this way. + +The "nonempty" message (supporting poll) +--------------------------------------- + +In order to support the "poll" method (and hence select() ), there is a small +catch regarding the FPGA to host direction: The FPGA may have filled a DMA +buffer with some data, but not submitted that buffer. If the host waited for +the buffer's submission by the FPGA, there would be a possibility that the +FPGA side has sent data, but a select() call would still block, because the +host has not received any notification about this. This is solved with +XILLYMSG_OPCODE_NONEMPTY messages sent by the FPGA when a channel goes from +completely empty to containing some data. + +These messages are used only to support poll() and select(). The IP core can +be configured not to send them for a slight reduction of bandwidth. |
