296 files changed, 12923 insertions, 9685 deletions

diff --git a/Documentation/ABI/testing/sysfs-block-bcache b/Documentation/ABI/testing/sysfs-block-bcache
new file mode 100644
index 000000000000..9e4bbc5d51fd
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-block-bcache
@@ -0,0 +1,156 @@
+What:           /sys/block/<disk>/bcache/unregister
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                A write to this file causes the backing device or cache to be
+                unregistered. If a backing device had dirty data in the cache,
+                writeback mode is automatically disabled and all dirty data is
+                flushed before the device is unregistered. Caches unregister
+                all associated backing devices before unregistering themselves.
+
+What:           /sys/block/<disk>/bcache/clear_stats
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                Writing to this file resets all the statistics for the device.
+
+What:           /sys/block/<disk>/bcache/cache
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For a backing device that has cache, a symlink to
+                the bcache/ dir of that cache.
+
+What:           /sys/block/<disk>/bcache/cache_hits
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For backing devices: integer number of full cache hits,
+                counted per bio. A partial cache hit counts as a miss.
+
+What:           /sys/block/<disk>/bcache/cache_misses
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For backing devices: integer number of cache misses.
+
+What:           /sys/block/<disk>/bcache/cache_hit_ratio
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For backing devices: cache hits as a percentage.
+
+What:           /sys/block/<disk>/bcache/sequential_cutoff
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For backing devices: Threshold past which sequential IO will
+                skip the cache. Read and written as bytes in human readable
+                units (i.e. echo 10M > sequntial_cutoff).
+
+What:           /sys/block/<disk>/bcache/bypassed
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                Sum of all reads and writes that have bypassed the cache (due
+                to the sequential cutoff).  Expressed as bytes in human
+                readable units.
+
+What:           /sys/block/<disk>/bcache/writeback
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For backing devices: When on, writeback caching is enabled and
+                writes will be buffered in the cache. When off, caching is in
+                writethrough mode; reads and writes will be added to the
+                cache but no write buffering will take place.
+
+What:           /sys/block/<disk>/bcache/writeback_running
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For backing devices: when off, dirty data will not be written
+                from the cache to the backing device. The cache will still be
+                used to buffer writes until it is mostly full, at which point
+                writes transparently revert to writethrough mode. Intended only
+                for benchmarking/testing.
+
+What:           /sys/block/<disk>/bcache/writeback_delay
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For backing devices: In writeback mode, when dirty data is
+                written to the cache and the cache held no dirty data for that
+                backing device, writeback from cache to backing device starts
+                after this delay, expressed as an integer number of seconds.
+
+What:           /sys/block/<disk>/bcache/writeback_percent
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For backing devices: If nonzero, writeback from cache to
+                backing device only takes place when more than this percentage
+                of the cache is used, allowing more write coalescing to take
+                place and reducing total number of writes sent to the backing
+                device. Integer between 0 and 40.
+
+What:           /sys/block/<disk>/bcache/synchronous
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For a cache, a boolean that allows synchronous mode to be
+                switched on and off. In synchronous mode all writes are ordered
+                such that the cache can reliably recover from unclean shutdown;
+                if disabled bcache will not generally wait for writes to
+                complete but if the cache is not shut down cleanly all data
+                will be discarded from the cache. Should not be turned off with
+                writeback caching enabled.
+
+What:           /sys/block/<disk>/bcache/discard
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For a cache, a boolean allowing discard/TRIM to be turned off
+                or back on if the device supports it.
+
+What:           /sys/block/<disk>/bcache/bucket_size
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For a cache, bucket size in human readable units, as set at
+                cache creation time; should match the erase block size of the
+                SSD for optimal performance.
+
+What:           /sys/block/<disk>/bcache/nbuckets
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For a cache, the number of usable buckets.
+
+What:           /sys/block/<disk>/bcache/tree_depth
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For a cache, height of the btree excluding leaf nodes (i.e. a
+                one node tree will have a depth of 0).
+
+What:           /sys/block/<disk>/bcache/btree_cache_size
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                Number of btree buckets/nodes that are currently cached in
+                memory; cache dynamically grows and shrinks in response to
+                memory pressure from the rest of the system.
+
+What:           /sys/block/<disk>/bcache/written
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For a cache, total amount of data in human readable units
+                written to the cache, excluding all metadata.
+
+What:           /sys/block/<disk>/bcache/btree_written
+Date:           November 2010
+Contact:        Kent Overstreet <kent.overstreet@gmail.com>
+Description:
+                For a cache, sum of all btree writes in human readable units.
diff --git a/Documentation/ABI/testing/sysfs-bus-mei b/Documentation/ABI/testing/sysfs-bus-mei
new file mode 100644
index 000000000000..2066f0bbd453
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-mei
@@ -0,0 +1,7 @@
+What:           /sys/bus/mei/devices/.../modalias
+Date:           March 2013
+KernelVersion:  3.10
+Contact:        Samuel Ortiz <sameo@linux.intel.com>
+                linux-mei@linux.intel.com
+Description:    Stores the same MODALIAS value emitted by uevent
+                Format: mei:<mei device name>
diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd
index cd9213ccf3dc..0a306476424e 100644
--- a/Documentation/ABI/testing/sysfs-bus-rbd
+++ b/Documentation/ABI/testing/sysfs-bus-rbd
@@ -66,27 +66,7 @@ current_snap
 
         The current snapshot for which the device is mapped.
 
-snap_*
-
-        A directory per each snapshot
-
 parent
 
         Information identifying the pool, image, and snapshot id for
         the parent image in a layered rbd image (format 2 only).
-
-Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
--------------------------------------------------------------
-
-snap_id
-
-        The rados internal snapshot id assigned for this snapshot
-
-snap_size
-
-        The size of the image when this snapshot was taken.
-
-snap_features
-
-        A hexadecimal encoding of the feature bits for this snapshot.
-
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index c8baaf53594a..f093e59cbe5f 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -32,7 +32,7 @@ Date:		January 2008
 KernelVersion:  2.6.25
 Contact:        Sarah Sharp <sarah.a.sharp@intel.com>
 Description:
-                If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
+                If CONFIG_PM_RUNTIME is enabled then this file
                 is present.  When read, it returns the total time (in msec)
                 that the USB device has been connected to the machine.  This
                 file is read-only.
@@ -45,7 +45,7 @@ Date:		January 2008
 KernelVersion:  2.6.25
 Contact:        Sarah Sharp <sarah.a.sharp@intel.com>
 Description:
-                If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
+                If CONFIG_PM_RUNTIME is enabled then this file
                 is present.  When read, it returns the total time (in msec)
                 that the USB device has been active, i.e. not in a suspended
                 state.  This file is read-only.
@@ -187,7 +187,7 @@ What:		/sys/bus/usb/devices/.../power/usb2_hardware_lpm
 Date:           September 2011
 Contact:        Andiry Xu <andiry.xu@amd.com>
 Description:
-                If CONFIG_USB_SUSPEND is set and a USB 2.0 lpm-capable device
+                If CONFIG_PM_RUNTIME is set and a USB 2.0 lpm-capable device
                 is plugged in to a xHCI host which support link PM, it will
                 perform a LPM test; if the test is passed and host supports
                 USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will
diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh
index bc41da61608d..bdcd8b4e38f2 100644
--- a/Documentation/ABI/testing/sysfs-class-net-mesh
+++ b/Documentation/ABI/testing/sysfs-class-net-mesh
@@ -67,6 +67,14 @@ Description:
                 Defines the penalty which will be applied to an
                 originator message's tq-field on every hop.
 
+What:           /sys/class/net/<mesh_iface>/mesh/network_coding
+Date:           Nov 2012
+Contact:        Martin Hundeboll <martin@hundeboll.net>
+Description:
+                Controls whether Network Coding (using some magic
+                to send fewer wifi packets but still the same
+                content) is enabled or not.
+
 What:           /sys/class/net/<mesh_iface>/mesh/orig_interval
 Date:           May 2010
 Contact:        Marek Lindner <lindner_marek@yahoo.de>
diff --git a/Documentation/ABI/testing/sysfs-devices-lpss_ltr b/Documentation/ABI/testing/sysfs-devices-lpss_ltr
new file mode 100644
index 000000000000..ea9298d9bbaf
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-lpss_ltr
@@ -0,0 +1,44 @@
+What:           /sys/devices/.../lpss_ltr/
+Date:           March 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../lpss_ltr/ directory is only present for
+                devices included into the Intel Lynxpoint Low Power Subsystem
+                (LPSS).  If present, it contains attributes containing the LTR
+                mode and the values of LTR registers of the device.
+
+What:           /sys/devices/.../lpss_ltr/ltr_mode
+Date:           March 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../lpss_ltr/ltr_mode attribute contains an
+                integer number (0 or 1) indicating whether or not the devices'
+                LTR functionality is working in the software mode (1).
+
+                This attribute is read-only.  If the device's runtime PM status
+                is not "active", attempts to read from this attribute cause
+                -EAGAIN to be returned.
+
+What:           /sys/devices/.../lpss_ltr/auto_ltr
+Date:           March 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
+                current value of the device's AUTO_LTR register (raw)
+                represented as an 8-digit hexadecimal number.
+
+                This attribute is read-only.  If the device's runtime PM status
+                is not "active", attempts to read from this attribute cause
+                -EAGAIN to be returned.
+
+What:           /sys/devices/.../lpss_ltr/sw_ltr
+Date:           March 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
+                current value of the device's SW_LTR register (raw) represented
+                as an 8-digit hexadecimal number.
+
+                This attribute is read-only.  If the device's runtime PM status
+                is not "active", attempts to read from this attribute cause
+                -EAGAIN to be returned.
diff --git a/Documentation/ABI/testing/sysfs-devices-power_resources_wakeup b/Documentation/ABI/testing/sysfs-devices-power_resources_wakeup
new file mode 100644
index 000000000000..e0588feeb6e1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-power_resources_wakeup
@@ -0,0 +1,13 @@
+What:           /sys/devices/.../power_resources_wakeup/
+Date:           April 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../power_resources_wakeup/ directory is only
+                present for device objects representing ACPI device nodes that
+                require ACPI power resources for wakeup signaling.
+
+                If present, it contains symbolic links to device directories
+                representing ACPI power resources that need to be turned on for
+                the given device node to be able to signal wakeup.  The names of
+                the links are the same as the names of the directories they
+                point to.
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 9c978dcae07d..2447698aed41 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -173,3 +173,15 @@ Description:	Processor frequency boosting control
                 Boosting allows the CPU and the firmware to run at a frequency
                 beyound it's nominal limit.
                 More details can be found in Documentation/cpu-freq/boost.txt
+
+
+What:           /sys/devices/system/cpu/cpu#/crash_notes
+                /sys/devices/system/cpu/cpu#/crash_notes_size
+Date:           April 2013
+Contact:        kexec@lists.infradead.org
+Description:    address and size of the percpu note.
+
+                crash_notes: the physical address of the memory that holds the
+                note of cpu#.
+
+                crash_notes_size: size of the note of cpu#.
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku b/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
index 9eca5a182e64..c601d0f2ac46 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
@@ -101,7 +101,8 @@ Date:		June 2011
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    When written, this file lets one set the backlight intensity for
                 a specific profile. Profile number is included in written data.
-                The data has to be 10 bytes long.
+                The data has to be 10 bytes long for Isku, IskuFX needs 16 bytes
+                of data.
                 Before reading this file, control has to be written to select
                 which profile to read.
 Users:          http://roccat.sourceforge.net
@@ -141,3 +142,12 @@ Description:	When written, this file lets one trigger easyshift functionality
                 The data has to be 16 bytes long.
                 This file is writeonly.
 Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/talkfx
+Date:           February 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one trigger temporary color schemes
+                from the host.
+                The data has to be 16 bytes long.
+                This file is writeonly.
+Users:          http://roccat.sourceforge.net
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure b/Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure
new file mode 100644
index 000000000000..41a9b7fbfc79
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure
@@ -0,0 +1,105 @@
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/actual_profile
+Date:           December 2012
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The mouse can store 5 profiles which can be switched by the
+                press of a button. actual_profile holds number of actual profile.
+                This value is persistent, so its value determines the profile
+                that's active when the mouse is powered on next time.
+                When written, the mouse activates the set profile immediately.
+                The data has to be 3 bytes long.
+                The mouse will reject invalid data.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/control
+Date:           December 2012
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one select which data from which
+                profile will be read next. The data has to be 3 bytes long.
+                This file is writeonly.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/info
+Date:           December 2012
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When read, this file returns general data like firmware version.
+                When written, the device can be reset.
+                The data is 6 bytes long.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/macro
+Date:           December 2012
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The mouse can store a macro with max 500 key/button strokes
+                internally.
+                When written, this file lets one set the sequence for a specific
+                button for a specific profile. Button and profile numbers are
+                included in written data. The data has to be 2082 bytes long.
+                This file is writeonly.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/profile_buttons
+Date:           December 2012
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The mouse can store 5 profiles which can be switched by the
+                press of a button. A profile is split in settings and buttons.
+                profile_buttons holds information about button layout.
+                When written, this file lets one write the respective profile
+                buttons back to the mouse. The data has to be 59 bytes long.
+                The mouse will reject invalid data.
+                Which profile to write is determined by the profile number
+                contained in the data.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/profile_settings
+Date:           December 2012
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The mouse can store 5 profiles which can be switched by the
+                press of a button. A profile is split in settings and buttons.
+                profile_settings holds information like resolution, sensitivity
+                and light effects.
+                When written, this file lets one write the respective profile
+                settings back to the mouse. The data has to be 31 bytes long.
+                The mouse will reject invalid data.
+                Which profile to write is determined by the profile number
+                contained in the data.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/sensor
+Date:           December 2012
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The mouse has a tracking- and a distance-control-unit. These
+                can be activated/deactivated and the lift-off distance can be
+                set. The data has to be 6 bytes long.
+                This file is writeonly.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/talk
+Date:           December 2012
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    Used to active some easy* functions of the mouse from outside.
+                The data has to be 16 bytes long.
+                This file is writeonly.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/tcu
+Date:           December 2012
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written a calibration process for the tracking control unit
+                can be initiated/cancelled. Also lets one read/write sensor
+                registers.
+                The data has to be 4 bytes long.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/tcu_image
+Date:           December 2012
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When read the mouse returns a 30x30 pixel image of the
+                sampled underground. This works only in the course of a
+                calibration process initiated with tcu.
+                The returned data is 1028 bytes in size.
+                This file is readonly.
+Users:          http://roccat.sourceforge.net
diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi
index dd930c8db41f..ce9bee98b43b 100644
--- a/Documentation/ABI/testing/sysfs-firmware-acpi
+++ b/Documentation/ABI/testing/sysfs-firmware-acpi
@@ -18,6 +18,32 @@ Description:
                 yoffset: The number of pixels between the top of the screen
                          and the top edge of the image.
 
+What:           /sys/firmware/acpi/hotplug/
+Date:           February 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                There are separate hotplug profiles for different classes of
+                devices supported by ACPI, such as containers, memory modules,
+                processors, PCI root bridges etc.  A hotplug profile for a given
+                class of devices is a collection of settings defining the way
+                that class of devices will be handled by the ACPI core hotplug
+                code.  Those profiles are represented in sysfs as subdirectories
+                of /sys/firmware/acpi/hotplug/.
+
+                The following setting is available to user space for each
+                hotplug profile:
+
+                enabled: If set, the ACPI core will handle notifications of
+                        hotplug events associated with the given class of
+                        devices and will allow those devices to be ejected with
+                        the help of the _EJ0 control method.  Unsetting it
+                        effectively disables hotplug for the correspoinding
+                        class of devices.
+
+                The value of the above attribute is an integer number: 1 (set)
+                or 0 (unset).  Attempts to write any other values to it will
+                cause -EINVAL to be returned.
+
 What:           /sys/firmware/acpi/interrupts/
 Date:           February 2008
 Contact:        Len Brown <lenb@kernel.org>
diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl
index 284ced7a228f..0f6a3edcd44b 100644
--- a/Documentation/DocBook/80211.tmpl
+++ b/Documentation/DocBook/80211.tmpl
@@ -437,7 +437,7 @@
       </section>
 !Finclude/net/mac80211.h ieee80211_get_buffered_bc
 !Finclude/net/mac80211.h ieee80211_beacon_get
-!Finclude/net/mac80211.h ieee80211_sta_eosp_irqsafe
+!Finclude/net/mac80211.h ieee80211_sta_eosp
 !Finclude/net/mac80211.h ieee80211_frame_release_type
 !Finclude/net/mac80211.h ieee80211_sta_ps_transition
 !Finclude/net/mac80211.h ieee80211_sta_ps_transition_ni
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl
index 7514dbf0a679..c36892c072da 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -227,7 +227,7 @@ X!Isound/sound_firmware.c
   <chapter id="uart16x50">
      <title>16x50 UART Driver</title>
 !Edrivers/tty/serial/serial_core.c
-!Edrivers/tty/serial/8250/8250.c
+!Edrivers/tty/serial/8250/8250_core.c
   </chapter>
 
   <chapter id="fbdev">
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 4a5eaeed0b9e..a9b15e34c5b2 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -1,6 +1,6 @@
 <section id="FE_GET_SET_PROPERTY">
 <title><constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant></title>
-<para>This section describes the DVB version 5 extention of the DVB-API, also
+<para>This section describes the DVB version 5 extension of the DVB-API, also
 called "S2API", as this API were added to provide support for DVB-S2. It was
 designed to be able to replace the old frontend API. Yet, the DISEQC and
 the capability ioctls weren't implemented yet via the new way.</para>
@@ -903,14 +903,12 @@ enum fe_interleaving {
                         <constant>svalue</constant> is for signed values of the measure (dB measures)
                         and <constant>uvalue</constant> is for unsigned values (counters, relative scale)</para></listitem>
                 <listitem><para><constant>scale</constant> - Scale for the value. It can be:</para>
-                        <section id = "fecap-scale-params">
-                        <itemizedlist mark='bullet'>
+                        <itemizedlist mark='bullet' id="fecap-scale-params">
                                 <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)</para></listitem>
                                 <listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 1/1000 dB</para></listitem>
                                 <listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem>
                                 <listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem>
                         </itemizedlist>
-                        </section>
                 </listitem>
         </itemizedlist>
         <section id="DTV-STAT-SIGNAL-STRENGTH">
@@ -918,9 +916,9 @@ enum fe_interleaving {
                 <para>Indicates the signal strength level at the analog part of the tuner or of the demod.</para>
                 <para>Possible scales for this metric are:</para>
                 <itemizedlist mark='bullet'>
-                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
-                        <listitem><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</listitem>
-                        <listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</listitem>
+                        <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+                        <listitem><para><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</para></listitem>
+                        <listitem><para><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</para></listitem>
                 </itemizedlist>
         </section>
         <section id="DTV-STAT-CNR">
@@ -928,9 +926,9 @@ enum fe_interleaving {
                 <para>Indicates the Signal to Noise ratio for the main carrier.</para>
                 <para>Possible scales for this metric are:</para>
                 <itemizedlist mark='bullet'>
-                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
-                        <listitem><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</listitem>
-                        <listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem>
+                        <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+                        <listitem><para><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</para></listitem>
+                        <listitem><para><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</para></listitem>
                 </itemizedlist>
         </section>
         <section id="DTV-STAT-PRE-ERROR-BIT-COUNT">
@@ -943,8 +941,8 @@ enum fe_interleaving {
                       The frontend may reset it when a channel/transponder is tuned.</para>
                 <para>Possible scales for this metric are:</para>
                 <itemizedlist mark='bullet'>
-                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
-                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem>
+                        <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+                        <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</para></listitem>
                 </itemizedlist>
         </section>
         <section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
@@ -952,14 +950,14 @@ enum fe_interleaving {
                 <para>Measures the amount of bits received before the inner code block, during the same period as
                 <link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
                 <para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
-                      as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
+                      as the frontend may need to manually restart the measurement, losing some data between each measurement interval.</para>
                 <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
                       The frontend may reset it when a channel/transponder is tuned.</para>
                 <para>Possible scales for this metric are:</para>
                 <itemizedlist mark='bullet'>
-                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
-                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
-                                 <link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</listitem>
+                        <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+                        <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
+                                 <link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</para></listitem>
                 </itemizedlist>
         </section>
         <section id="DTV-STAT-POST-ERROR-BIT-COUNT">
@@ -972,8 +970,8 @@ enum fe_interleaving {
                       The frontend may reset it when a channel/transponder is tuned.</para>
                 <para>Possible scales for this metric are:</para>
                 <itemizedlist mark='bullet'>
-                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
-                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem>
+                        <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+                        <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</para></listitem>
                 </itemizedlist>
         </section>
         <section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
@@ -981,14 +979,14 @@ enum fe_interleaving {
                 <para>Measures the amount of bits received after the inner coding, during the same period as
                 <link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
                 <para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
-                      as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
+                      as the frontend may need to manually restart the measurement, losing some data between each measurement interval.</para>
                 <para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
                       The frontend may reset it when a channel/transponder is tuned.</para>
                 <para>Possible scales for this metric are:</para>
                 <itemizedlist mark='bullet'>
-                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
-                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
-                                 <link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</listitem>
+                        <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+                        <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
+                                 <link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</para></listitem>
                 </itemizedlist>
         </section>
         <section id="DTV-STAT-ERROR-BLOCK-COUNT">
@@ -998,8 +996,8 @@ enum fe_interleaving {
                       The frontend may reset it when a channel/transponder is tuned.</para>
                 <para>Possible scales for this metric are:</para>
                 <itemizedlist mark='bullet'>
-                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
-                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem>
+                        <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+                        <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</para></listitem>
                 </itemizedlist>
         </section>
         <section id="DTV-STAT-TOTAL-BLOCK-COUNT">
@@ -1011,9 +1009,9 @@ enum fe_interleaving {
                 by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
                 <para>Possible scales for this metric are:</para>
                 <itemizedlist mark='bullet'>
-                        <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
-                        <listitem><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
-                        <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</listitem>
+                        <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
+                        <listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
+                        <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</para></listitem>
                 </itemizedlist>
         </section>
         </section>
diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml
index ae06afbbb3a9..1ddf354aa997 100644
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -750,15 +750,6 @@ header can be used to get the timings of the formats in the <xref linkend="cea86
 <xref linkend="vesadmt" /> standards.
         </para>
         </listitem>
-        <listitem>
-        <para>DV Presets: Digital Video (DV) presets (<emphasis role="bold">deprecated</emphasis>).
-        These are IDs representing a
-video timing at the input/output. Presets are pre-defined timings implemented
-by the hardware according to video standards. A __u32 data type is used to represent
-a preset unlike the bit mask that is used in &v4l2-std-id; allowing future extensions
-to support as many different presets as needed. This API is deprecated in favor of the DV Timings
-API.</para>
-        </listitem>
         </itemizedlist>
         <para>To enumerate and query the attributes of the DV timings supported by a device,
         applications use the &VIDIOC-ENUM-DV-TIMINGS; and &VIDIOC-DV-TIMINGS-CAP; ioctls.
@@ -766,11 +757,6 @@ API.</para>
 &VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the
 &VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications
 use the &VIDIOC-QUERY-DV-TIMINGS; ioctl.</para>
-        <para>To enumerate and query the attributes of DV presets supported by a device,
-applications use the &VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current DV preset,
-applications use the &VIDIOC-G-DV-PRESET; ioctl and to set a preset they use the
-&VIDIOC-S-DV-PRESET; ioctl. To detect the preset as seen by the video receiver applications
-use the &VIDIOC-QUERY-DV-PRESET; ioctl.</para>
         <para>Applications can make use of the <xref linkend="input-capabilities" /> and
 <xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the
 video timings for the device.</para>
diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
index 104a1a2b8849..f43542ae2981 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2310,6 +2310,9 @@ more information.</para>
         <listitem>
           <para>Added FM Modulator (FM TX) Extended Control Class: <constant>V4L2_CTRL_CLASS_FM_TX</constant> and their Control IDs.</para>
         </listitem>
+<listitem>
+          <para>Added FM Receiver (FM RX) Extended Control Class: <constant>V4L2_CTRL_CLASS_FM_RX</constant> and their Control IDs.</para>
+        </listitem>
         <listitem>
           <para>Added Remote Controller chapter, describing the default Remote Controller mapping for media devices.</para>
         </listitem>
@@ -2493,6 +2496,23 @@ that used it. It was originally scheduled for removal in 2.6.35.
       </orderedlist>
     </section>
 
+    <section>
+      <title>V4L2 in Linux 3.10</title>
+      <orderedlist>
+        <listitem>
+          <para>Removed obsolete and unused DV_PRESET ioctls
+          VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET, VIDIOC_QUERY_DV_PRESET and
+          VIDIOC_ENUM_DV_PRESET. Remove the related v4l2_input/output capability
+          flags V4L2_IN_CAP_PRESETS and V4L2_OUT_CAP_PRESETS.
+          </para>
+        </listitem>
+        <listitem>
+          <para>Added new debugging ioctl &VIDIOC-DBG-G-CHIP-INFO;.
+          </para>
+        </listitem>
+      </orderedlist>
+    </section>
+
     <section id="other">
       <title>Relation of V4L2 to other Linux multimedia APIs</title>
 
@@ -2625,8 +2645,8 @@ interfaces and should not be implemented in new drivers.</para>
 <xref linkend="extended-controls" />.</para>
         </listitem>
         <listitem>
-          <para>&VIDIOC-G-DV-PRESET;, &VIDIOC-S-DV-PRESET;, &VIDIOC-ENUM-DV-PRESETS; and
-          &VIDIOC-QUERY-DV-PRESET; ioctls. Use the DV Timings API (<xref linkend="dv-timings" />).</para>
+          <para>VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET, VIDIOC_ENUM_DV_PRESETS and
+          VIDIOC_QUERY_DV_PRESET ioctls. Use the DV Timings API (<xref linkend="dv-timings" />).</para>
         </listitem>
         <listitem>
           <para><constant>VIDIOC_SUBDEV_G_CROP</constant> and
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index 9e8f85498678..8d7a77928d49 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2300,6 +2300,12 @@ Possible values are:</entry>
               </row>
               <row><entry></entry></row>
               <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER</constant>&nbsp;</entry>
+                <entry>boolean</entry>
+              </row><row><entry spanname="descr">Repeat the video sequence headers. Repeating these
+headers makes random access to the video stream easier. Applicable to the MPEG1, 2 and 4 encoder.</entry>
+              </row>
+              <row>
                 <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER</constant>&nbsp;</entry>
                 <entry>boolean</entry>
               </row><row><entry spanname="descr">Enabled the deblocking post processing filter for MPEG4 decoder.
@@ -3136,6 +3142,13 @@ giving priority to the center of the metered area.</entry>
                   <entry><constant>V4L2_EXPOSURE_METERING_SPOT</constant>&nbsp;</entry>
                   <entry>Measure only very small area at the center of the frame.</entry>
                 </row>
+                <row>
+                  <entry><constant>V4L2_EXPOSURE_METERING_MATRIX</constant>&nbsp;</entry>
+                  <entry>A multi-zone metering. The light intensity is measured
+in several points of the frame and the the results are combined. The
+algorithm of the zones selection and their significance in calculating the
+final value is device dependant.</entry>
+                </row>
               </tbody>
             </entrytbl>
           </row>
@@ -3848,7 +3861,7 @@ in Hz. The range and step are driver-specific.</entry>
           </row>
           <row>
             <entry spanname="id"><constant>V4L2_CID_TUNE_PREEMPHASIS</constant>&nbsp;</entry>
-            <entry>integer</entry>
+            <entry>enum v4l2_preemphasis</entry>
           </row>
           <row id="v4l2-preemphasis"><entry spanname="descr">Configures the pre-emphasis value for broadcasting.
 A pre-emphasis filter is applied to the broadcast to accentuate the high audio frequencies.
@@ -4687,4 +4700,76 @@ interface and may change in the future.</para>
       </table>
 
     </section>
+
+    <section id="fm-rx-controls">
+      <title>FM Receiver Control Reference</title>
+
+      <para>The FM Receiver (FM_RX) class includes controls for common features of
+      FM Reception capable devices.</para>
+
+      <table pgwide="1" frame="none" id="fm-rx-control-id">
+      <title>FM_RX Control IDs</title>
+
+      <tgroup cols="4">
+        <colspec colname="c1" colwidth="1*" />
+        <colspec colname="c2" colwidth="6*" />
+        <colspec colname="c3" colwidth="2*" />
+        <colspec colname="c4" colwidth="6*" />
+        <spanspec namest="c1" nameend="c2" spanname="id" />
+        <spanspec namest="c2" nameend="c4" spanname="descr" />
+        <thead>
+          <row>
+            <entry spanname="id" align="left">ID</entry>
+            <entry align="left">Type</entry>
+          </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry>
+          </row>
+        </thead>
+        <tbody valign="top">
+          <row><entry></entry></row>
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_FM_RX_CLASS</constant>&nbsp;</entry>
+            <entry>class</entry>
+          </row><row><entry spanname="descr">The FM_RX class
+descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a
+description of this control class.</entry>
+          </row>
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_RDS_RECEPTION</constant>&nbsp;</entry>
+            <entry>boolean</entry>
+          </row><row><entry spanname="descr">Enables/disables RDS
+          reception by the radio tuner</entry>
+          </row>
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_TUNE_DEEMPHASIS</constant>&nbsp;</entry>
+            <entry>enum v4l2_deemphasis</entry>
+          </row>
+          <row id="v4l2-deemphasis"><entry spanname="descr">Configures the de-emphasis value for reception.
+A de-emphasis filter is applied to the broadcast to accentuate the high audio frequencies.
+Depending on the region, a time constant of either 50 or 75 useconds is used. The enum&nbsp;v4l2_deemphasis
+defines possible values for de-emphasis. Here they are:</entry>
+        </row><row>
+        <entrytbl spanname="descr" cols="2">
+                  <tbody valign="top">
+                    <row>
+                      <entry><constant>V4L2_DEEMPHASIS_DISABLED</constant>&nbsp;</entry>
+                      <entry>No de-emphasis is applied.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_DEEMPHASIS_50_uS</constant>&nbsp;</entry>
+                      <entry>A de-emphasis of 50 uS is used.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_DEEMPHASIS_75_uS</constant>&nbsp;</entry>
+                      <entry>A de-emphasis of 75 uS is used.</entry>
+                    </row>
+                  </tbody>
+                </entrytbl>
+
+          </row>
+          <row><entry></entry></row>
+        </tbody>
+      </tgroup>
+      </table>
+
+      </section>
 </section>
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index e6c58559ca6b..2c4c068dde83 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -1145,6 +1145,12 @@ in which case caches have not been used.</entry>
             same clock outside V4L2, use
             <function>clock_gettime(2)</function> .</entry>
           </row>
+          <row>
+            <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry>
+            <entry>0x4000</entry>
+            <entry>The CAPTURE buffer timestamp has been taken from the
+            corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry>
+          </row>
         </tbody>
       </tgroup>
     </table>
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index 576b68b33f2c..116c301656e0 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -272,6 +272,16 @@
             <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
             <entry>Lens controller</entry>
           </row>
+          <row>
+            <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_DECODER</constant></entry>
+            <entry>Video decoder, the basic function of the video decoder is to
+            accept analogue video from a wide variety of sources such as
+            broadcast, DVD players, cameras and video cassette recorders, in
+            either NTSC, PAL or HD format and still occasionally SECAM, separate
+            it into its component parts, luminance and chrominance, and output
+            it in some digital video standard, with appropriate embedded timing
+            signals.</entry>
+          </row>
         </tbody>
       </tgroup>
     </table>
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml
index cc51372ed5e0..adc61982df7b 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -93,19 +93,35 @@
 
       <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-rgb">
         <title>RGB formats</title>
-        <tgroup cols="11">
+        <tgroup cols="27">
           <colspec colname="id" align="left" />
           <colspec colname="code" align="center"/>
           <colspec colname="bit" />
-          <colspec colnum="4" colname="b07" align="center" />
-          <colspec colnum="5" colname="b06" align="center" />
-          <colspec colnum="6" colname="b05" align="center" />
-          <colspec colnum="7" colname="b04" align="center" />
-          <colspec colnum="8" colname="b03" align="center" />
-          <colspec colnum="9" colname="b02" align="center" />
-          <colspec colnum="10" colname="b01" align="center" />
-          <colspec colnum="11" colname="b00" align="center" />
-          <spanspec namest="b07" nameend="b00" spanname="b0" />
+          <colspec colnum="4" colname="b23" align="center" />
+          <colspec colnum="5" colname="b22" align="center" />
+          <colspec colnum="6" colname="b21" align="center" />
+          <colspec colnum="7" colname="b20" align="center" />
+          <colspec colnum="8" colname="b19" align="center" />
+          <colspec colnum="9" colname="b18" align="center" />
+          <colspec colnum="10" colname="b17" align="center" />
+          <colspec colnum="11" colname="b16" align="center" />
+          <colspec colnum="12" colname="b15" align="center" />
+          <colspec colnum="13" colname="b14" align="center" />
+          <colspec colnum="14" colname="b13" align="center" />
+          <colspec colnum="15" colname="b12" align="center" />
+          <colspec colnum="16" colname="b11" align="center" />
+          <colspec colnum="17" colname="b10" align="center" />
+          <colspec colnum="18" colname="b09" align="center" />
+          <colspec colnum="19" colname="b08" align="center" />
+          <colspec colnum="20" colname="b07" align="center" />
+          <colspec colnum="21" colname="b06" align="center" />
+          <colspec colnum="22" colname="b05" align="center" />
+          <colspec colnum="23" colname="b04" align="center" />
+          <colspec colnum="24" colname="b03" align="center" />
+          <colspec colnum="25" colname="b02" align="center" />
+          <colspec colnum="26" colname="b01" align="center" />
+          <colspec colnum="27" colname="b00" align="center" />
+          <spanspec namest="b23" nameend="b00" spanname="b0" />
           <thead>
             <row>
               <entry>Identifier</entry>
@@ -117,6 +133,22 @@
               <entry></entry>
               <entry></entry>
               <entry>Bit</entry>
+              <entry>23</entry>
+              <entry>22</entry>
+              <entry>21</entry>
+              <entry>20</entry>
+              <entry>19</entry>
+              <entry>18</entry>
+              <entry>17</entry>
+              <entry>16</entry>
+              <entry>15</entry>
+              <entry>14</entry>
+              <entry>13</entry>
+              <entry>12</entry>
+              <entry>11</entry>
+              <entry>10</entry>
+              <entry>9</entry>
+              <entry>8</entry>
               <entry>7</entry>
               <entry>6</entry>
               <entry>5</entry>
@@ -132,6 +164,7 @@
               <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE</entry>
               <entry>0x1001</entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>0</entry>
               <entry>0</entry>
               <entry>0</entry>
@@ -145,6 +178,7 @@
               <entry></entry>
               <entry></entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>g<subscript>3</subscript></entry>
               <entry>g<subscript>2</subscript></entry>
               <entry>g<subscript>1</subscript></entry>
@@ -158,6 +192,7 @@
               <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE</entry>
               <entry>0x1002</entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>g<subscript>3</subscript></entry>
               <entry>g<subscript>2</subscript></entry>
               <entry>g<subscript>1</subscript></entry>
@@ -171,6 +206,7 @@
               <entry></entry>
               <entry></entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>0</entry>
               <entry>0</entry>
               <entry>0</entry>
@@ -184,6 +220,7 @@
               <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</entry>
               <entry>0x1003</entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>0</entry>
               <entry>r<subscript>4</subscript></entry>
               <entry>r<subscript>3</subscript></entry>
@@ -197,6 +234,7 @@
               <entry></entry>
               <entry></entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>g<subscript>2</subscript></entry>
               <entry>g<subscript>1</subscript></entry>
               <entry>g<subscript>0</subscript></entry>
@@ -210,6 +248,7 @@
               <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE</entry>
               <entry>0x1004</entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>g<subscript>2</subscript></entry>
               <entry>g<subscript>1</subscript></entry>
               <entry>g<subscript>0</subscript></entry>
@@ -223,6 +262,7 @@
               <entry></entry>
               <entry></entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>0</entry>
               <entry>r<subscript>4</subscript></entry>
               <entry>r<subscript>3</subscript></entry>
@@ -236,6 +276,7 @@
               <entry>V4L2_MBUS_FMT_BGR565_2X8_BE</entry>
               <entry>0x1005</entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>b<subscript>4</subscript></entry>
               <entry>b<subscript>3</subscript></entry>
               <entry>b<subscript>2</subscript></entry>
@@ -249,6 +290,7 @@
               <entry></entry>
               <entry></entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>g<subscript>2</subscript></entry>
               <entry>g<subscript>1</subscript></entry>
               <entry>g<subscript>0</subscript></entry>
@@ -262,6 +304,7 @@
               <entry>V4L2_MBUS_FMT_BGR565_2X8_LE</entry>
               <entry>0x1006</entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>g<subscript>2</subscript></entry>
               <entry>g<subscript>1</subscript></entry>
               <entry>g<subscript>0</subscript></entry>
@@ -275,6 +318,7 @@
               <entry></entry>
               <entry></entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>b<subscript>4</subscript></entry>
               <entry>b<subscript>3</subscript></entry>
               <entry>b<subscript>2</subscript></entry>
@@ -288,6 +332,7 @@
               <entry>V4L2_MBUS_FMT_RGB565_2X8_BE</entry>
               <entry>0x1007</entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>r<subscript>4</subscript></entry>
               <entry>r<subscript>3</subscript></entry>
               <entry>r<subscript>2</subscript></entry>
@@ -301,6 +346,7 @@
               <entry></entry>
               <entry></entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>g<subscript>2</subscript></entry>
               <entry>g<subscript>1</subscript></entry>
               <entry>g<subscript>0</subscript></entry>
@@ -314,6 +360,7 @@
               <entry>V4L2_MBUS_FMT_RGB565_2X8_LE</entry>
               <entry>0x1008</entry>
               <entry></entry>
+              &dash-ent-16;
               <entry>g<subscript>2</subscript></entry>
               <entry>g<subscript>1</subscript></entry>
               <entry>g<subscript>0</subscript></entry>
@@ -327,6 +374,27 @@
               <entry></entry>
               <entry></entry>
               <entry></entry>
+              &dash-ent-16;
+              <entry>r<subscript>4</subscript></entry>
+              <entry>r<subscript>3</subscript></entry>
+              <entry>r<subscript>2</subscript></entry>
+              <entry>r<subscript>1</subscript></entry>
+              <entry>r<subscript>0</subscript></entry>
+              <entry>g<subscript>5</subscript></entry>
+              <entry>g<subscript>4</subscript></entry>
+              <entry>g<subscript>3</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-RGB666-1X18">
+              <entry>V4L2_MBUS_FMT_RGB666_1X18</entry>
+              <entry>0x1009</entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>r<subscript>5</subscript></entry>
               <entry>r<subscript>4</subscript></entry>
               <entry>r<subscript>3</subscript></entry>
               <entry>r<subscript>2</subscript></entry>
@@ -335,6 +403,124 @@
               <entry>g<subscript>5</subscript></entry>
               <entry>g<subscript>4</subscript></entry>
               <entry>g<subscript>3</subscript></entry>
+              <entry>g<subscript>2</subscript></entry>
+              <entry>g<subscript>1</subscript></entry>
+              <entry>g<subscript>0</subscript></entry>
+              <entry>b<subscript>5</subscript></entry>
+              <entry>b<subscript>4</subscript></entry>
+              <entry>b<subscript>3</subscript></entry>
+              <entry>b<subscript>2</subscript></entry>
+              <entry>b<subscript>1</subscript></entry>
+              <entry>b<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-RGB888-1X24">
+              <entry>V4L2_MBUS_FMT_RGB888_1X24</entry>
+              <entry>0x100a</entry>
+              <entry></entry>
+              <entry>r<subscript>7</subscript></entry>
+              <entry>r<subscript>6</subscript></entry>
+              <entry>r<subscript>5</subscript></entry>
+              <entry>r<subscript>4</subscript></entry>
+              <entry>r<subscript>3</subscript></entry>
+              <entry>r<subscript>2</subscript></entry>
+              <entry>r<subscript>1</subscript></entry>
+              <entry>r<subscript>0</subscript></entry>
+              <entry>g<subscript>7</subscript></entry>
+              <entry>g<subscript>6</subscript></entry>
+              <entry>g<subscript>5</subscript></entry>
+              <entry>g<subscript>4</subscript></entry>
+              <entry>g<subscript>3</subscript></entry>
+              <entry>g<subscript>2</subscript></entry>
+              <entry>g<subscript>1</subscript></entry>
+              <entry>g<subscript>0</subscript></entry>
+              <entry>b<subscript>7</subscript></entry>
+              <entry>b<subscript>6</subscript></entry>
+              <entry>b<subscript>5</subscript></entry>
+              <entry>b<subscript>4</subscript></entry>
+              <entry>b<subscript>3</subscript></entry>
+              <entry>b<subscript>2</subscript></entry>
+              <entry>b<subscript>1</subscript></entry>
+              <entry>b<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-RGB888-2X12-BE">
+              <entry>V4L2_MBUS_FMT_RGB888_2X12_BE</entry>
+              <entry>0x100b</entry>
+              <entry></entry>
+              &dash-ent-10;
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>r<subscript>7</subscript></entry>
+              <entry>r<subscript>6</subscript></entry>
+              <entry>r<subscript>5</subscript></entry>
+              <entry>r<subscript>4</subscript></entry>
+              <entry>r<subscript>3</subscript></entry>
+              <entry>r<subscript>2</subscript></entry>
+              <entry>r<subscript>1</subscript></entry>
+              <entry>r<subscript>0</subscript></entry>
+              <entry>g<subscript>7</subscript></entry>
+              <entry>g<subscript>6</subscript></entry>
+              <entry>g<subscript>5</subscript></entry>
+              <entry>g<subscript>4</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-10;
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>g<subscript>3</subscript></entry>
+              <entry>g<subscript>2</subscript></entry>
+              <entry>g<subscript>1</subscript></entry>
+              <entry>g<subscript>0</subscript></entry>
+              <entry>b<subscript>7</subscript></entry>
+              <entry>b<subscript>6</subscript></entry>
+              <entry>b<subscript>5</subscript></entry>
+              <entry>b<subscript>4</subscript></entry>
+              <entry>b<subscript>3</subscript></entry>
+              <entry>b<subscript>2</subscript></entry>
+              <entry>b<subscript>1</subscript></entry>
+              <entry>b<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-RGB888-2X12-LE">
+              <entry>V4L2_MBUS_FMT_RGB888_2X12_LE</entry>
+              <entry>0x100c</entry>
+              <entry></entry>
+              &dash-ent-10;
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>g<subscript>3</subscript></entry>
+              <entry>g<subscript>2</subscript></entry>
+              <entry>g<subscript>1</subscript></entry>
+              <entry>g<subscript>0</subscript></entry>
+              <entry>b<subscript>7</subscript></entry>
+              <entry>b<subscript>6</subscript></entry>
+              <entry>b<subscript>5</subscript></entry>
+              <entry>b<subscript>4</subscript></entry>
+              <entry>b<subscript>3</subscript></entry>
+              <entry>b<subscript>2</subscript></entry>
+              <entry>b<subscript>1</subscript></entry>
+              <entry>b<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-10;
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>r<subscript>7</subscript></entry>
+              <entry>r<subscript>6</subscript></entry>
+              <entry>r<subscript>5</subscript></entry>
+              <entry>r<subscript>4</subscript></entry>
+              <entry>r<subscript>3</subscript></entry>
+              <entry>r<subscript>2</subscript></entry>
+              <entry>r<subscript>1</subscript></entry>
+              <entry>r<subscript>0</subscript></entry>
+              <entry>g<subscript>7</subscript></entry>
+              <entry>g<subscript>6</subscript></entry>
+              <entry>g<subscript>5</subscript></entry>
+              <entry>g<subscript>4</subscript></entry>
             </row>
           </tbody>
         </tgroup>
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index a3cce18384e9..bfc93cdcf696 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -124,6 +124,7 @@ Remote Controller chapter.</contrib>
       <year>2010</year>
       <year>2011</year>
       <year>2012</year>
+      <year>2013</year>
       <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
 Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
         Pawel Osciak</holder>
@@ -140,12 +141,22 @@ structs, ioctls) must be noted in more detail in the history chapter
 applications. -->
 
       <revision>
+        <revnumber>3.10</revnumber>
+        <date>2013-03-25</date>
+        <authorinitials>hv</authorinitials>
+        <revremark>Remove obsolete and unused DV_PRESET ioctls:
+        VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET, VIDIOC_QUERY_DV_PRESET and
+        VIDIOC_ENUM_DV_PRESET. Remove the related v4l2_input/output capability
+        flags V4L2_IN_CAP_PRESETS and V4L2_OUT_CAP_PRESETS. Added VIDIOC_DBG_G_CHIP_INFO.
+        </revremark>
+      </revision>
+
+      <revision>
         <revnumber>3.9</revnumber>
         <date>2012-12-03</date>
         <authorinitials>sa, sn</authorinitials>
         <revremark>Added timestamp types to v4l2_buffer.
-        Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control
-        event changes flag, see <xref linkend="changes-flags"/>.
+        Added V4L2_EVENT_CTRL_CH_RANGE control event changes flag.
         </revremark>
       </revision>
 
@@ -537,6 +548,7 @@ and discussions on the V4L mailing list.</revremark>
     &sub-create-bufs;
     &sub-cropcap;
     &sub-dbg-g-chip-ident;
+    &sub-dbg-g-chip-info;
     &sub-dbg-g-register;
     &sub-decoder-cmd;
     &sub-dqevent;
@@ -544,7 +556,6 @@ and discussions on the V4L mailing list.</revremark>
     &sub-encoder-cmd;
     &sub-enumaudio;
     &sub-enumaudioout;
-    &sub-enum-dv-presets;
     &sub-enum-dv-timings;
     &sub-enum-fmt;
     &sub-enum-framesizes;
@@ -558,7 +569,6 @@ and discussions on the V4L mailing list.</revremark>
     &sub-g-audioout;
     &sub-g-crop;
     &sub-g-ctrl;
-    &sub-g-dv-preset;
     &sub-g-dv-timings;
     &sub-g-enc-index;
     &sub-g-ext-ctrls;
@@ -582,7 +592,6 @@ and discussions on the V4L mailing list.</revremark>
     &sub-querybuf;
     &sub-querycap;
     &sub-queryctrl;
-    &sub-query-dv-preset;
     &sub-query-dv-timings;
     &sub-querystd;
     &sub-reqbufs;
diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml
index 4ecd966808de..921e18550d26 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml
@@ -200,10 +200,10 @@ the values from <xref linkend="chip-ids" />.</entry>
         &cs-def;
         <tbody valign="top">
           <row>
-            <entry><constant>V4L2_CHIP_MATCH_HOST</constant></entry>
+            <entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
             <entry>0</entry>
             <entry>Match the nth chip on the card, zero for the
-            host chip. Does not match &i2c; chips.</entry>
+            bridge chip. Does not match sub-devices.</entry>
           </row>
           <row>
             <entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
@@ -220,6 +220,11 @@ the values from <xref linkend="chip-ids" />.</entry>
             <entry>3</entry>
             <entry>Match the nth anciliary AC97 chip.</entry>
           </row>
+          <row>
+            <entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
+            <entry>4</entry>
+            <entry>Match the nth sub-device. Can't be used with this ioctl.</entry>
+          </row>
         </tbody>
       </tgroup>
     </table>
diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml
new file mode 100644
index 000000000000..e1cece6c5de1
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml
@@ -0,0 +1,223 @@
+<refentry id="vidioc-dbg-g-chip-info">
+  <refmeta>
+    <refentrytitle>ioctl VIDIOC_DBG_G_CHIP_INFO</refentrytitle>
+    &manvol;
+  </refmeta>
+
+  <refnamediv>
+    <refname>VIDIOC_DBG_G_CHIP_INFO</refname>
+    <refpurpose>Identify the chips on a TV card</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcprototype>
+        <funcdef>int <function>ioctl</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>int <parameter>request</parameter></paramdef>
+        <paramdef>struct v4l2_dbg_chip_info
+*<parameter>argp</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Arguments</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><parameter>fd</parameter></term>
+        <listitem>
+          <para>&fd;</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><parameter>request</parameter></term>
+        <listitem>
+          <para>VIDIOC_DBG_G_CHIP_INFO</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><parameter>argp</parameter></term>
+        <listitem>
+          <para></para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Description</title>
+
+    <note>
+      <title>Experimental</title>
+
+      <para>This is an <link
+linkend="experimental">experimental</link> interface and may change in
+the future.</para>
+    </note>
+
+    <para>For driver debugging purposes this ioctl allows test
+applications to query the driver about the chips present on the TV
+card. Regular applications must not use it. When you found a chip
+specific bug, please contact the linux-media mailing list (&v4l-ml;)
+so it can be fixed.</para>
+
+    <para>Additionally the Linux kernel must be compiled with the
+<constant>CONFIG_VIDEO_ADV_DEBUG</constant> option to enable this ioctl.</para>
+
+    <para>To query the driver applications must initialize the
+<structfield>match.type</structfield> and
+<structfield>match.addr</structfield> or <structfield>match.name</structfield>
+fields of a &v4l2-dbg-chip-info;
+and call <constant>VIDIOC_DBG_G_CHIP_INFO</constant> with a pointer to
+this structure. On success the driver stores information about the
+selected chip in the <structfield>name</structfield> and
+<structfield>flags</structfield> fields. On failure the structure
+remains unchanged.</para>
+
+    <para>When <structfield>match.type</structfield> is
+<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
+<structfield>match.addr</structfield> selects the nth bridge 'chip'
+on the TV card. You can enumerate all chips by starting at zero and
+incrementing <structfield>match.addr</structfield> by one until
+<constant>VIDIOC_DBG_G_CHIP_INFO</constant> fails with an &EINVAL;.
+The number zero always selects the bridge chip itself, &eg; the chip
+connected to the PCI or USB bus. Non-zero numbers identify specific
+parts of the bridge chip such as an AC97 register block.</para>
+
+    <para>When <structfield>match.type</structfield> is
+<constant>V4L2_CHIP_MATCH_SUBDEV</constant>,
+<structfield>match.addr</structfield> selects the nth sub-device. This
+allows you to enumerate over all sub-devices.</para>
+
+    <para>On success, the <structfield>name</structfield> field will
+contain a chip name and the <structfield>flags</structfield> field will
+contain <constant>V4L2_CHIP_FL_READABLE</constant> if the driver supports
+reading registers from the device or <constant>V4L2_CHIP_FL_WRITABLE</constant>
+if the driver supports writing registers to the device.</para>
+
+    <para>We recommended the <application>v4l2-dbg</application>
+utility over calling this ioctl directly. It is available from the
+LinuxTV v4l-dvb repository; see <ulink
+url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
+access instructions.</para>
+
+    <!-- Note for convenience vidioc-dbg-g-register.sgml
+         contains a duplicate of this table. -->
+    <table pgwide="1" frame="none" id="name-v4l2-dbg-match">
+      <title>struct <structname>v4l2_dbg_match</structname></title>
+      <tgroup cols="4">
+        &cs-ustr;
+        <tbody valign="top">
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>type</structfield></entry>
+            <entry>See <xref linkend="name-chip-match-types" /> for a list of
+possible types.</entry>
+          </row>
+          <row>
+            <entry>union</entry>
+            <entry>(anonymous)</entry>
+          </row>
+          <row>
+            <entry></entry>
+            <entry>__u32</entry>
+            <entry><structfield>addr</structfield></entry>
+            <entry>Match a chip by this number, interpreted according
+to the <structfield>type</structfield> field.</entry>
+          </row>
+          <row>
+            <entry></entry>
+            <entry>char</entry>
+            <entry><structfield>name[32]</structfield></entry>
+            <entry>Match a chip by this name, interpreted according
+to the <structfield>type</structfield> field.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <table pgwide="1" frame="none" id="v4l2-dbg-chip-info">
+      <title>struct <structname>v4l2_dbg_chip_info</structname></title>
+      <tgroup cols="3">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>struct v4l2_dbg_match</entry>
+            <entry><structfield>match</structfield></entry>
+            <entry>How to match the chip, see <xref linkend="name-v4l2-dbg-match" />.</entry>
+          </row>
+          <row>
+            <entry>char</entry>
+            <entry><structfield>name[32]</structfield></entry>
+            <entry>The name of the chip.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>flags</structfield></entry>
+            <entry>Set by the driver. If <constant>V4L2_CHIP_FL_READABLE</constant>
+is set, then the driver supports reading registers from the device. If
+<constant>V4L2_CHIP_FL_WRITABLE</constant> is set, then it supports writing registers.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>reserved[8]</structfield></entry>
+            <entry>Reserved fields, both application and driver must set these to 0.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <!-- Note for convenience vidioc-dbg-g-register.sgml
+         contains a duplicate of this table. -->
+    <table pgwide="1" frame="none" id="name-chip-match-types">
+      <title>Chip Match Types</title>
+      <tgroup cols="3">
+        &cs-def;
+        <tbody valign="top">
+          <row>
+            <entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
+            <entry>0</entry>
+            <entry>Match the nth chip on the card, zero for the
+            bridge chip. Does not match sub-devices.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
+            <entry>1</entry>
+            <entry>Match an &i2c; chip by its driver name. Can't be used with this ioctl.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
+            <entry>2</entry>
+            <entry>Match a chip by its 7 bit &i2c; bus address. Can't be used with this ioctl.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
+            <entry>3</entry>
+            <entry>Match the nth anciliary AC97 chip. Can't be used with this ioctl.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
+            <entry>4</entry>
+            <entry>Match the nth sub-device.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    &return-value;
+
+    <variablelist>
+      <varlistentry>
+        <term><errorcode>EINVAL</errorcode></term>
+        <listitem>
+          <para>The <structfield>match_type</structfield> is invalid or
+no device could be matched.</para>
+        </listitem>
+      </varlistentry>
+     </variablelist>
+  </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml
index a44aebc7997a..d13bac9e2445 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml
@@ -87,7 +87,7 @@ written into the register.</para>
 
     <para>To read a register applications must initialize the
 <structfield>match.type</structfield>,
-<structfield>match.chip</structfield> or <structfield>match.name</structfield> and
+<structfield>match.addr</structfield> or <structfield>match.name</structfield> and
 <structfield>reg</structfield> fields, and call
 <constant>VIDIOC_DBG_G_REGISTER</constant> with a pointer to this
 structure. On success the driver stores the register value in the
@@ -95,11 +95,11 @@ structure. On success the driver stores the register value in the
 unchanged.</para>
 
     <para>When <structfield>match.type</structfield> is
-<constant>V4L2_CHIP_MATCH_HOST</constant>,
-<structfield>match.addr</structfield> selects the nth non-&i2c; chip
+<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
+<structfield>match.addr</structfield> selects the nth non-sub-device chip
 on the TV card.  The number zero always selects the host chip, &eg; the
 chip connected to the PCI or USB bus. You can find out which chips are
-present with the &VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para>
+present with the &VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
 
     <para>When <structfield>match.type</structfield> is
 <constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
@@ -109,7 +109,7 @@ For instance
 supported by the saa7127 driver, regardless of its &i2c; bus address.
 When multiple chips supported by the same driver are present, the
 effect of these ioctls is undefined. Again with the
-&VIDIOC-DBG-G-CHIP-IDENT; ioctl you can find out which &i2c; chips are
+&VIDIOC-DBG-G-CHIP-INFO; ioctl you can find out which &i2c; chips are
 present.</para>
 
     <para>When <structfield>match.type</structfield> is
@@ -122,19 +122,23 @@ bus address.</para>
 <structfield>match.addr</structfield> selects the nth AC97 chip
 on the TV card.</para>
 
+    <para>When <structfield>match.type</structfield> is
+<constant>V4L2_CHIP_MATCH_SUBDEV</constant>,
+<structfield>match.addr</structfield> selects the nth sub-device.</para>
+
     <note>
       <title>Success not guaranteed</title>
 
       <para>Due to a flaw in the Linux &i2c; bus driver these ioctls may
 return successfully without actually reading or writing a register. To
-catch the most likely failure we recommend a &VIDIOC-DBG-G-CHIP-IDENT;
+catch the most likely failure we recommend a &VIDIOC-DBG-G-CHIP-INFO;
 call confirming the presence of the selected &i2c; chip.</para>
     </note>
 
     <para>These ioctls are optional, not all drivers may support them.
 However when a driver supports these ioctls it must also support
-&VIDIOC-DBG-G-CHIP-IDENT;. Conversely it may support
-<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> but not these ioctls.</para>
+&VIDIOC-DBG-G-CHIP-INFO;. Conversely it may support
+<constant>VIDIOC_DBG_G_CHIP_INFO</constant> but not these ioctls.</para>
 
     <para><constant>VIDIOC_DBG_G_REGISTER</constant> and
 <constant>VIDIOC_DBG_S_REGISTER</constant> were introduced in Linux
@@ -217,10 +221,10 @@ register.</entry>
         &cs-def;
         <tbody valign="top">
           <row>
-            <entry><constant>V4L2_CHIP_MATCH_HOST</constant></entry>
+            <entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
             <entry>0</entry>
             <entry>Match the nth chip on the card, zero for the
-            host chip. Does not match &i2c; chips.</entry>
+            bridge chip. Does not match sub-devices.</entry>
           </row>
           <row>
             <entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
@@ -237,6 +241,11 @@ register.</entry>
             <entry>3</entry>
             <entry>Match the nth anciliary AC97 chip.</entry>
           </row>
+          <row>
+            <entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
+            <entry>4</entry>
+            <entry>Match the nth sub-device.</entry>
+          </row>
         </tbody>
       </tgroup>
     </table>
diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml
deleted file mode 100644
index fced5fb0dbf0..000000000000
--- a/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml
+++ /dev/null
@@ -1,240 +0,0 @@
-<refentry id="vidioc-enum-dv-presets">
-  <refmeta>
-    <refentrytitle>ioctl VIDIOC_ENUM_DV_PRESETS</refentrytitle>
-    &manvol;
-  </refmeta>
-
-  <refnamediv>
-    <refname>VIDIOC_ENUM_DV_PRESETS</refname>
-    <refpurpose>Enumerate supported Digital Video presets</refpurpose>
-  </refnamediv>
-
-  <refsynopsisdiv>
-    <funcsynopsis>
-      <funcprototype>
-        <funcdef>int <function>ioctl</function></funcdef>
-        <paramdef>int <parameter>fd</parameter></paramdef>
-        <paramdef>int <parameter>request</parameter></paramdef>
-        <paramdef>struct v4l2_dv_enum_preset *<parameter>argp</parameter></paramdef>
-      </funcprototype>
-    </funcsynopsis>
-  </refsynopsisdiv>
-
-  <refsect1>
-    <title>Arguments</title>
-
-    <variablelist>
-      <varlistentry>
-        <term><parameter>fd</parameter></term>
-        <listitem>
-          <para>&fd;</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term><parameter>request</parameter></term>
-        <listitem>
-          <para>VIDIOC_ENUM_DV_PRESETS</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term><parameter>argp</parameter></term>
-        <listitem>
-          <para></para>
-        </listitem>
-      </varlistentry>
-    </variablelist>
-  </refsect1>
-
-  <refsect1>
-    <title>Description</title>
-
-    <para>This ioctl is <emphasis role="bold">deprecated</emphasis>.
-    New drivers and applications should use &VIDIOC-ENUM-DV-TIMINGS; instead.
-    </para>
-
-    <para>To query the attributes of a DV preset, applications initialize the
-<structfield>index</structfield> field and zero the reserved array of &v4l2-dv-enum-preset;
-and call the <constant>VIDIOC_ENUM_DV_PRESETS</constant> ioctl with a pointer to this
-structure. Drivers fill the rest of the structure or return an
-&EINVAL; when the index is out of bounds. To enumerate all DV Presets supported,
-applications shall begin at index zero, incrementing by one until the
-driver returns <errorcode>EINVAL</errorcode>. Drivers may enumerate a
-different set of DV presets after switching the video input or
-output.</para>
-
-    <table pgwide="1" frame="none" id="v4l2-dv-enum-preset">
-      <title>struct <structname>v4l2_dv_enum_presets</structname></title>
-      <tgroup cols="3">
-        &cs-str;
-        <tbody valign="top">
-          <row>
-            <entry>__u32</entry>
-            <entry><structfield>index</structfield></entry>
-            <entry>Number of the DV preset, set by the
-application.</entry>
-          </row>
-          <row>
-            <entry>__u32</entry>
-            <entry><structfield>preset</structfield></entry>
-            <entry>This field identifies one of the DV preset values listed in <xref linkend="v4l2-dv-presets-vals"/>.</entry>
-          </row>
-          <row>
-            <entry>__u8</entry>
-            <entry><structfield>name</structfield>[24]</entry>
-            <entry>Name of the preset, a NUL-terminated ASCII string, for example: "720P-60", "1080I-60". This information is
-intended for the user.</entry>
-          </row>
-          <row>
-            <entry>__u32</entry>
-            <entry><structfield>width</structfield></entry>
-            <entry>Width of the active video in pixels for the DV preset.</entry>
-          </row>
-          <row>
-            <entry>__u32</entry>
-            <entry><structfield>height</structfield></entry>
-            <entry>Height of the active video in lines for the DV preset.</entry>
-          </row>
-          <row>
-            <entry>__u32</entry>
-            <entry><structfield>reserved</structfield>[4]</entry>
-            <entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
-          </row>
-        </tbody>
-      </tgroup>
-    </table>
-
-    <table pgwide="1" frame="none" id="v4l2-dv-presets-vals">
-      <title>struct <structname>DV Presets</structname></title>
-      <tgroup cols="3">
-        &cs-str;
-        <tbody valign="top">
-          <row>
-            <entry>Preset</entry>
-            <entry>Preset value</entry>
-            <entry>Description</entry>
-          </row>
-          <row>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_INVALID</entry>
-            <entry>0</entry>
-            <entry>Invalid preset value.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_480P59_94</entry>
-            <entry>1</entry>
-            <entry>720x480 progressive video at 59.94 fps as per BT.1362.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_576P50</entry>
-            <entry>2</entry>
-            <entry>720x576 progressive video at 50 fps as per BT.1362.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_720P24</entry>
-            <entry>3</entry>
-            <entry>1280x720 progressive video at 24 fps as per SMPTE 296M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_720P25</entry>
-            <entry>4</entry>
-            <entry>1280x720 progressive video at 25 fps as per SMPTE 296M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_720P30</entry>
-            <entry>5</entry>
-            <entry>1280x720 progressive video at 30 fps as per SMPTE 296M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_720P50</entry>
-            <entry>6</entry>
-            <entry>1280x720 progressive video at 50 fps as per SMPTE 296M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_720P59_94</entry>
-            <entry>7</entry>
-            <entry>1280x720 progressive video at 59.94 fps as per SMPTE 274M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_720P60</entry>
-            <entry>8</entry>
-            <entry>1280x720 progressive video at 60 fps as per SMPTE 274M/296M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_1080I29_97</entry>
-            <entry>9</entry>
-            <entry>1920x1080 interlaced video at 29.97 fps as per BT.1120/SMPTE 274M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_1080I30</entry>
-            <entry>10</entry>
-            <entry>1920x1080 interlaced video at 30 fps as per BT.1120/SMPTE 274M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_1080I25</entry>
-            <entry>11</entry>
-            <entry>1920x1080 interlaced video at 25 fps as per BT.1120.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_1080I50</entry>
-            <entry>12</entry>
-            <entry>1920x1080 interlaced video at 50 fps as per SMPTE 296M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_1080I60</entry>
-            <entry>13</entry>
-            <entry>1920x1080 interlaced video at 60 fps as per SMPTE 296M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_1080P24</entry>
-            <entry>14</entry>
-            <entry>1920x1080 progressive video at 24 fps as per SMPTE 296M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_1080P25</entry>
-            <entry>15</entry>
-            <entry>1920x1080 progressive video at 25 fps as per SMPTE 296M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_1080P30</entry>
-            <entry>16</entry>
-            <entry>1920x1080 progressive video at 30 fps as per SMPTE 296M.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_1080P50</entry>
-            <entry>17</entry>
-            <entry>1920x1080 progressive video at 50 fps as per BT.1120.</entry>
-          </row>
-          <row>
-            <entry>V4L2_DV_1080P60</entry>
-            <entry>18</entry>
-            <entry>1920x1080 progressive video at 60 fps as per BT.1120.</entry>
-          </row>
-        </tbody>
-      </tgroup>
-    </table>
-  </refsect1>
-
-  <refsect1>
-    &return-value;
-
-    <variablelist>
-      <varlistentry>
-        <term><errorcode>EINVAL</errorcode></term>
-        <listitem>
-          <para>The &v4l2-dv-enum-preset; <structfield>index</structfield>
-is out of bounds.</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term><errorcode>ENODATA</errorcode></term>
-        <listitem>
-          <para>Digital video presets are not supported for this input or output.</para>
-        </listitem>
-      </varlistentry>
-    </variablelist>
-  </refsect1>
-</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
index 3c9a81305ad4..493a39a8ef21 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
@@ -278,11 +278,6 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
         &cs-def;
         <tbody valign="top">
           <row>
-            <entry><constant>V4L2_IN_CAP_PRESETS</constant></entry>
-            <entry>0x00000001</entry>
-            <entry>This input supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
-          </row>
-          <row>
             <entry><constant>V4L2_IN_CAP_DV_TIMINGS</constant></entry>
             <entry>0x00000002</entry>
             <entry>This input supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
index f4ab0798545d..2654e097df39 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
@@ -163,11 +163,6 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
         &cs-def;
         <tbody valign="top">
           <row>
-            <entry><constant>V4L2_OUT_CAP_PRESETS</constant></entry>
-            <entry>0x00000001</entry>
-            <entry>This output supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
-          </row>
-          <row>
             <entry><constant>V4L2_OUT_CAP_DV_TIMINGS</constant></entry>
             <entry>0x00000002</entry>
             <entry>This output supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml b/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml
deleted file mode 100644
index b9ea37634f6c..000000000000
--- a/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml
+++ /dev/null
@@ -1,113 +0,0 @@
-<refentry id="vidioc-g-dv-preset">
-  <refmeta>
-    <refentrytitle>ioctl VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET</refentrytitle>
-    &manvol;
-  </refmeta>
-
-  <refnamediv>
-    <refname>VIDIOC_G_DV_PRESET</refname>
-    <refname>VIDIOC_S_DV_PRESET</refname>
-    <refpurpose>Query or select the DV preset of the current input or output</refpurpose>
-  </refnamediv>
-
-  <refsynopsisdiv>
-    <funcsynopsis>
-      <funcprototype>
-        <funcdef>int <function>ioctl</function></funcdef>
-        <paramdef>int <parameter>fd</parameter></paramdef>
-        <paramdef>int <parameter>request</parameter></paramdef>
-        <paramdef>struct v4l2_dv_preset *<parameter>argp</parameter></paramdef>
-      </funcprototype>
-    </funcsynopsis>
-  </refsynopsisdiv>
-
-  <refsect1>
-    <title>Arguments</title>
-
-    <variablelist>
-      <varlistentry>
-        <term><parameter>fd</parameter></term>
-        <listitem>
-          <para>&fd;</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term><parameter>request</parameter></term>
-        <listitem>
-          <para>VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term><parameter>argp</parameter></term>
-        <listitem>
-          <para></para>
-        </listitem>
-      </varlistentry>
-    </variablelist>
-  </refsect1>
-
-  <refsect1>
-    <title>Description</title>
-
-    <para>These ioctls are <emphasis role="bold">deprecated</emphasis>.
-    New drivers and applications should use &VIDIOC-G-DV-TIMINGS; and &VIDIOC-S-DV-TIMINGS;
-    instead.
-    </para>
-
-    <para>To query and select the current DV preset, applications
-use the <constant>VIDIOC_G_DV_PRESET</constant> and <constant>VIDIOC_S_DV_PRESET</constant>
-ioctls which take a pointer to a &v4l2-dv-preset; type as argument.
-Applications must zero the reserved array in &v4l2-dv-preset;.
-<constant>VIDIOC_G_DV_PRESET</constant> returns a dv preset in the field
-<structfield>preset</structfield> of &v4l2-dv-preset;.</para>
-
-    <para><constant>VIDIOC_S_DV_PRESET</constant> accepts a pointer to a &v4l2-dv-preset;
-that has the preset value to be set. Applications must zero the reserved array in &v4l2-dv-preset;.
-If the preset is not supported, it returns an &EINVAL; </para>
-  </refsect1>
-
-  <refsect1>
-    &return-value;
-
-    <variablelist>
-      <varlistentry>
-        <term><errorcode>EINVAL</errorcode></term>
-        <listitem>
-          <para>This ioctl is not supported, or the
-<constant>VIDIOC_S_DV_PRESET</constant>,<constant>VIDIOC_S_DV_PRESET</constant> parameter was unsuitable.</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term><errorcode>ENODATA</errorcode></term>
-        <listitem>
-          <para>Digital video presets are not supported for this input or output.</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term><errorcode>EBUSY</errorcode></term>
-        <listitem>
-          <para>The device is busy and therefore can not change the preset.</para>
-        </listitem>
-      </varlistentry>
-    </variablelist>
-
-    <table pgwide="1" frame="none" id="v4l2-dv-preset">
-      <title>struct <structname>v4l2_dv_preset</structname></title>
-      <tgroup cols="3">
-        &cs-str;
-        <tbody valign="top">
-          <row>
-            <entry>__u32</entry>
-            <entry><structfield>preset</structfield></entry>
-            <entry>Preset value to represent the digital video timings</entry>
-          </row>
-          <row>
-            <entry>__u32</entry>
-            <entry><structfield>reserved[4]</structfield></entry>
-            <entry>Reserved fields for future use</entry>
-          </row>
-        </tbody>
-      </tgroup>
-    </table>
-  </refsect1>
-</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
index 4e16112df992..b3bb9575b2e0 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
@@ -319,6 +319,15 @@ These controls are described in <xref
             processing controls. These controls are described in <xref
             linkend="image-process-controls" />.</entry>
           </row>
+
+          <row>
+            <entry><constant>V4L2_CTRL_CLASS_FM_RX</constant></entry>
+            <entry>0xa10000</entry>
+            <entry>The class containing FM Receiver (FM RX) controls.
+These controls are described in <xref
+                linkend="fm-rx-controls" />.</entry>
+          </row>
+
         </tbody>
       </tgroup>
     </table>
diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml
deleted file mode 100644
index 68b49d09e245..000000000000
--- a/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml
+++ /dev/null
@@ -1,78 +0,0 @@
-<refentry id="vidioc-query-dv-preset">
-  <refmeta>
-    <refentrytitle>ioctl VIDIOC_QUERY_DV_PRESET</refentrytitle>
-    &manvol;
-  </refmeta>
-
-  <refnamediv>
-    <refname>VIDIOC_QUERY_DV_PRESET</refname>
-    <refpurpose>Sense the DV preset received by the current
-input</refpurpose>
-  </refnamediv>
-
-  <refsynopsisdiv>
-    <funcsynopsis>
-      <funcprototype>
-        <funcdef>int <function>ioctl</function></funcdef>
-        <paramdef>int <parameter>fd</parameter></paramdef>
-        <paramdef>int <parameter>request</parameter></paramdef>
-        <paramdef>struct v4l2_dv_preset *<parameter>argp</parameter></paramdef>
-      </funcprototype>
-    </funcsynopsis>
-  </refsynopsisdiv>
-
-  <refsect1>
-    <title>Arguments</title>
-
-    <variablelist>
-        <varlistentry>
-        <term><parameter>fd</parameter></term>
-        <listitem>
-          <para>&fd;</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term><parameter>request</parameter></term>
-        <listitem>
-          <para>VIDIOC_QUERY_DV_PRESET</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term><parameter>argp</parameter></term>
-        <listitem>
-          <para></para>
-        </listitem>
-      </varlistentry>
-    </variablelist>
-  </refsect1>
-
-  <refsect1>
-    <title>Description</title>
-
-    <para>This ioctl is <emphasis role="bold">deprecated</emphasis>.
-    New drivers and applications should use &VIDIOC-QUERY-DV-TIMINGS; instead.
-    </para>
-
-    <para>The hardware may be able to detect the current DV preset
-automatically, similar to sensing the video standard. To do so, applications
-call <constant> VIDIOC_QUERY_DV_PRESET</constant> with a pointer to a
-&v4l2-dv-preset; type. Once the hardware detects a preset, that preset is
-returned in the preset field of &v4l2-dv-preset;. If the preset could not be
-detected because there was no signal, or the signal was unreliable, or the
-signal did not map to a supported preset, then the value V4L2_DV_INVALID is
-returned.</para>
-  </refsect1>
-
-  <refsect1>
-    &return-value;
-
-    <variablelist>
-      <varlistentry>
-        <term><errorcode>ENODATA</errorcode></term>
-        <listitem>
-          <para>Digital video presets are not supported for this input or output.</para>
-        </listitem>
-      </varlistentry>
-    </variablelist>
-  </refsect1>
-</refentry>
diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl
index 1f6593deb995..6a8b7158697f 100644
--- a/Documentation/DocBook/media_api.tmpl
+++ b/Documentation/DocBook/media_api.tmpl
@@ -23,6 +23,7 @@
 <!-- LinuxTV v4l-dvb repository. -->
 <!ENTITY v4l-dvb                "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
 <!ENTITY dash-ent-10            "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
+<!ENTITY dash-ent-16            "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
 ]>
 
 <book id="media_api">
diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl
index bd6fee22c4dd..06741e925985 100644
--- a/Documentation/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl
@@ -6164,14 +6164,12 @@ struct _snd_pcm_runtime {
 
       <para>
         The macro takes an conditional expression to evaluate.
-        When <constant>CONFIG_SND_DEBUG</constant>, is set, the
-        expression is actually evaluated. If it's non-zero, it shows
-        the warning message such as
+        When <constant>CONFIG_SND_DEBUG</constant>, is set, if the
+        expression is non-zero, it shows the warning message such as
         <computeroutput>BUG? (xxx)</computeroutput>
-        normally followed by stack trace.  It returns the evaluated
-        value.
-        When no <constant>CONFIG_SND_DEBUG</constant> is set, this
-        macro always returns zero.
+        normally followed by stack trace.
+
+        In both cases it returns the evaluated value.
       </para>
 
     </section>
diff --git a/Documentation/EDID/1600x1200.S b/Documentation/EDID/1600x1200.S
new file mode 100644
index 000000000000..0ded64cfd1f5
--- /dev/null
+++ b/Documentation/EDID/1600x1200.S
@@ -0,0 +1,44 @@
+/*
+   1600x1200.S: EDID data set for standard 1600x1200 60 Hz monitor
+
+   Copyright (C) 2013 Carsten Emde <C.Emde@osadl.org>
+
+   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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 162000 /* kHz */
+#define XPIX 1600
+#define YPIX 1200
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 560
+#define YBLANK 50
+#define XOFFSET 64
+#define XPULSE 192
+#define YOFFSET (63+1)
+#define YPULSE (63+3)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux UXGA"
+#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+#define HSYNC_POL 1
+#define VSYNC_POL 1
+#define CRC 0x9d
+
+#include "edid.S"
diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt
index 2d0a8f09475d..7146db1d9e8c 100644
--- a/Documentation/EDID/HOWTO.txt
+++ b/Documentation/EDID/HOWTO.txt
@@ -18,12 +18,12 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
 individually prepared or corrected EDID data set in the /lib/firmware
 directory from where it is loaded via the firmware interface. The code
 (see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
-commonly used screen resolutions (1024x768, 1280x1024, 1680x1050,
-1920x1080) as binary blobs, but the kernel source tree does not contain
-code to create these data. In order to elucidate the origin of the
-built-in binary EDID blobs and to facilitate the creation of individual
-data for a specific misbehaving monitor, commented sources and a
-Makefile environment are given here.
+commonly used screen resolutions (1024x768, 1280x1024, 1600x1200,
+1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
+not contain code to create these data. In order to elucidate the origin
+of the built-in binary EDID blobs and to facilitate the creation of
+individual data for a specific misbehaving monitor, commented sources
+and a Makefile environment are given here.
 
 To create binary EDID and C source code files from the existing data
 material, simply type "make".
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 31ef8fe07f82..79e789b8b8ea 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -217,9 +217,14 @@ over a rather long period of time, but improvements are always welcome!
         whether the increased speed is worth it.
 
 8.      Although synchronize_rcu() is slower than is call_rcu(), it
-        usually results in simpler code.  So, unless update performance
-        is critically important or the updaters cannot block,
-        synchronize_rcu() should be used in preference to call_rcu().
+        usually results in simpler code.  So, unless update performance is
+        critically important, the updaters cannot block, or the latency of
+        synchronize_rcu() is visible from userspace, synchronize_rcu()
+        should be used in preference to call_rcu().  Furthermore,
+        kfree_rcu() usually results in even simpler code than does
+        synchronize_rcu() without synchronize_rcu()'s multi-millisecond
+        latency.  So please take advantage of kfree_rcu()'s "fire and
+        forget" memory-freeing capabilities where it applies.
 
         An especially important property of the synchronize_rcu()
         primitive is that it automatically self-limits: if grace periods
@@ -268,7 +273,8 @@ over a rather long period of time, but improvements are always welcome!
         e.      Periodically invoke synchronize_rcu(), permitting a limited
                 number of updates per grace period.
 
-        The same cautions apply to call_rcu_bh() and call_rcu_sched().
+        The same cautions apply to call_rcu_bh(), call_rcu_sched(),
+        call_srcu(), and kfree_rcu().
 
 9.      All RCU list-traversal primitives, which include
         rcu_dereference(), list_for_each_entry_rcu(), and
@@ -296,9 +302,9 @@ over a rather long period of time, but improvements are always welcome!
         all currently executing rcu_read_lock()-protected RCU read-side
         critical sections complete.  It does -not- necessarily guarantee
         that all currently running interrupts, NMIs, preempt_disable()
-        code, or idle loops will complete.  Therefore, if you do not have
-        rcu_read_lock()-protected read-side critical sections, do -not-
-        use synchronize_rcu().
+        code, or idle loops will complete.  Therefore, if your
+        read-side critical sections are protected by something other
+        than rcu_read_lock(), do -not- use synchronize_rcu().
 
         Similarly, disabling preemption is not an acceptable substitute
         for rcu_read_lock().  Code that attempts to use preemption
@@ -401,9 +407,9 @@ over a rather long period of time, but improvements are always welcome!
         read-side critical sections.  It is the responsibility of the
         RCU update-side primitives to deal with this.
 
-17.     Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and
-        the __rcu sparse checks to validate your RCU code.  These
-        can help find problems as follows:
+17.     Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and the
+        __rcu sparse checks (enabled by CONFIG_SPARSE_RCU_POINTER) to
+        validate your RCU code.  These can help find problems as follows:
 
         CONFIG_PROVE_RCU: check that accesses to RCU-protected data
                 structures are carried out under the proper RCU
diff --git a/Documentation/RCU/lockdep.txt b/Documentation/RCU/lockdep.txt
index a102d4b3724b..cd83d2348fef 100644
--- a/Documentation/RCU/lockdep.txt
+++ b/Documentation/RCU/lockdep.txt
@@ -64,6 +64,11 @@ checking of rcu_dereference() primitives:
                 but retain the compiler constraints that prevent duplicating
                 or coalescsing.  This is useful when when testing the
                 value of the pointer itself, for example, against NULL.
+        rcu_access_index(idx):
+                Return the value of the index and omit all barriers, but
+                retain the compiler constraints that prevent duplicating
+                or coalescsing.  This is useful when when testing the
+                value of the index itself, for example, against -1.
 
 The rcu_dereference_check() check expression can be any boolean
 expression, but would normally include a lockdep expression.  However,
diff --git a/Documentation/RCU/rcubarrier.txt b/Documentation/RCU/rcubarrier.txt
index 38428c125135..2e319d1b9ef2 100644
--- a/Documentation/RCU/rcubarrier.txt
+++ b/Documentation/RCU/rcubarrier.txt
@@ -79,7 +79,20 @@ complete. Pseudo-code using rcu_barrier() is as follows:
    2. Execute rcu_barrier().
    3. Allow the module to be unloaded.
 
-The rcutorture module makes use of rcu_barrier in its exit function
+There are also rcu_barrier_bh(), rcu_barrier_sched(), and srcu_barrier()
+functions for the other flavors of RCU, and you of course must match
+the flavor of rcu_barrier() with that of call_rcu().  If your module
+uses multiple flavors of call_rcu(), then it must also use multiple
+flavors of rcu_barrier() when unloading that module.  For example, if
+it uses call_rcu_bh(), call_srcu() on srcu_struct_1, and call_srcu() on
+srcu_struct_2(), then the following three lines of code will be required
+when unloading:
+
+ 1 rcu_barrier_bh();
+ 2 srcu_barrier(&srcu_struct_1);
+ 3 srcu_barrier(&srcu_struct_2);
+
+The rcutorture module makes use of rcu_barrier() in its exit function
 as follows:
 
  1 static void
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index 1927151b386b..8e9359de1d28 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -92,14 +92,14 @@ If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
 more information is printed with the stall-warning message, for example:
 
         INFO: rcu_preempt detected stall on CPU
-        0: (63959 ticks this GP) idle=241/3fffffffffffffff/0
+        0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543
            (t=65000 jiffies)
 
 In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
 printed:
 
         INFO: rcu_preempt detected stall on CPU
-        0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
+        0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D
            (t=65000 jiffies)
 
 The "(64628 ticks this GP)" indicates that this CPU has taken more
@@ -116,13 +116,28 @@ number between the two "/"s is the value of the nesting, which will
 be a small positive number if in the idle loop and a very large positive
 number (as shown above) otherwise.
 
-For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
-not in the process of trying to force itself into dyntick-idle state, the
-"." indicates that the CPU has not given up forcing RCU into dyntick-idle
-mode (it would be "H" otherwise), and the "timer not pending" indicates
-that the CPU has not recently forced RCU into dyntick-idle mode (it
-would otherwise indicate the number of microseconds remaining in this
-forced state).
+The "softirq=" portion of the message tracks the number of RCU softirq
+handlers that the stalled CPU has executed.  The number before the "/"
+is the number that had executed since boot at the time that this CPU
+last noted the beginning of a grace period, which might be the current
+(stalled) grace period, or it might be some earlier grace period (for
+example, if the CPU might have been in dyntick-idle mode for an extended
+time period.  The number after the "/" is the number that have executed
+since boot until the current time.  If this latter number stays constant
+across repeated stall-warning messages, it is possible that RCU's softirq
+handlers are no longer able to execute on this CPU.  This can happen if
+the stalled CPU is spinning with interrupts are disabled, or, in -rt
+kernels, if a high-priority process is starving RCU's softirq handler.
+
+For CONFIG_RCU_FAST_NO_HZ kernels, the "last_accelerate:" prints the
+low-order 16 bits (in hex) of the jiffies counter when this CPU last
+invoked rcu_try_advance_all_cbs() from rcu_needs_cpu() or last invoked
+rcu_accelerate_cbs() from rcu_prepare_for_idle().  The "nonlazy_posted:"
+prints the number of non-lazy callbacks posted since the last call to
+rcu_needs_cpu().  Finally, an "L" indicates that there are currently
+no non-lazy callbacks ("." is printed otherwise, as shown above) and
+"D" indicates that dyntick-idle processing is enabled ("." is printed
+otherwise, for example, if disabled via the "nohz=" kernel boot parameter).
 
 
 Multiple Warnings From One Stall
@@ -176,7 +191,7 @@ o	A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
 o       A hardware or software issue shuts off the scheduler-clock
         interrupt on a CPU that is not in dyntick-idle mode.  This
         problem really has happened, and seems to be most likely to
-        result in RCU CPU stall warnings for CONFIG_NO_HZ=n kernels.
+        result in RCU CPU stall warnings for CONFIG_NO_HZ_COMMON=n kernels.
 
 o       A bug in the RCU implementation.
 
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 0cc7820967f4..10df0b82f459 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -265,9 +265,9 @@ rcu_dereference()
                 rcu_read_lock();
                 p = rcu_dereference(head.next);
                 rcu_read_unlock();
-                x = p->address;
+                x = p->address; /* BUG!!! */
                 rcu_read_lock();
-                y = p->data;
+                y = p->data;    /* BUG!!! */
                 rcu_read_unlock();
 
         Holding a reference from one RCU read-side critical section
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index c379a2a6949f..6e97e73d87b5 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -60,8 +60,7 @@ own source tree.  For example:
 "dontdiff" is a list of files which are generated by the kernel during
 the build process, and should be ignored in any diff(1)-generated
 patch.  The "dontdiff" file is included in the kernel tree in
-2.6.12 and later.  For earlier kernel versions, you can get it
-from <http://www.xenotime.net/linux/doc/dontdiff>.
+2.6.12 and later.
 
 Make sure your patch does not include any extra files which do not
 belong in a patch submission.  Make sure to review your patch -after-
@@ -421,7 +420,7 @@ person it names.  This tag documents that potentially interested parties
 have been included in the discussion
 
 
-14) Using Reported-by:, Tested-by: and Reviewed-by:
+14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
 
 If this patch fixes a problem reported by somebody else, consider adding a
 Reported-by: tag to credit the reporter for their contribution.  Please
@@ -469,6 +468,13 @@ done on the patch.  Reviewed-by: tags, when supplied by reviewers known to
 understand the subject area and to perform thorough reviews, will normally
 increase the likelihood of your patch getting into the kernel.
 
+A Suggested-by: tag indicates that the patch idea is suggested by the person
+named and ensures credit to the person for the idea. Please note that this
+tag should not be added without the reporter's permission, especially if the
+idea was not posted in a public forum. That said, if we diligently credit our
+idea reporters, they will, hopefully, be inspired to help us again in the
+future.
+
 
 15) The canonical patch format
 
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
index 94a656131885..b0d541042ac6 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -199,6 +199,8 @@ the device to the driver. For example:
         {
                 Name (SBUF, ResourceTemplate()
                 {
+                        ...
+                        // Used to power on/off the device
                         GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
                                 IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
                                 0x00, ResourceConsumer,,)
@@ -206,10 +208,20 @@ the device to the driver. For example:
                                 // Pin List
                                 0x0055
                         }
+
+                        // Interrupt for the device
+                        GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
+                                 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,)
+                        {
+                                // Pin list
+                                0x0058
+                        }
+
                         ...
 
-                        Return (SBUF)
                 }
+
+                Return (SBUF)
         }
 
 These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
@@ -220,6 +232,24 @@ The driver can do this by including <linux/acpi_gpio.h> and then calling
 acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
 negative errno if there was no translation found.
 
+In a simple case of just getting the Linux GPIO number from device
+resources one can use acpi_get_gpio_by_index() helper function. It takes
+pointer to the device and index of the GpioIo/GpioInt descriptor in the
+device resources list. For example:
+
+        int gpio_irq, gpio_power;
+        int ret;
+
+        gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL);
+        if (gpio_irq < 0)
+                /* handle error */
+
+        gpio_power = acpi_get_gpio_by_index(dev, 0, NULL);
+        if (gpio_power < 0)
+                /* handle error */
+
+        /* Now we can use the GPIO numbers */
+
 Other GpioIo parameters must be converted first by the driver to be
 suitable to the gpiolib before passing them.
 
diff --git a/Documentation/arm/cluster-pm-race-avoidance.txt b/Documentation/arm/cluster-pm-race-avoidance.txt
new file mode 100644
index 000000000000..750b6fc24af9
--- /dev/null
+++ b/Documentation/arm/cluster-pm-race-avoidance.txt
@@ -0,0 +1,498 @@
+Cluster-wide Power-up/power-down race avoidance algorithm
+=========================================================
+
+This file documents the algorithm which is used to coordinate CPU and
+cluster setup and teardown operations and to manage hardware coherency
+controls safely.
+
+The section "Rationale" explains what the algorithm is for and why it is
+needed.  "Basic model" explains general concepts using a simplified view
+of the system.  The other sections explain the actual details of the
+algorithm in use.
+
+
+Rationale
+---------
+
+In a system containing multiple CPUs, it is desirable to have the
+ability to turn off individual CPUs when the system is idle, reducing
+power consumption and thermal dissipation.
+
+In a system containing multiple clusters of CPUs, it is also desirable
+to have the ability to turn off entire clusters.
+
+Turning entire clusters off and on is a risky business, because it
+involves performing potentially destructive operations affecting a group
+of independently running CPUs, while the OS continues to run.  This
+means that we need some coordination in order to ensure that critical
+cluster-level operations are only performed when it is truly safe to do
+so.
+
+Simple locking may not be sufficient to solve this problem, because
+mechanisms like Linux spinlocks may rely on coherency mechanisms which
+are not immediately enabled when a cluster powers up.  Since enabling or
+disabling those mechanisms may itself be a non-atomic operation (such as
+writing some hardware registers and invalidating large caches), other
+methods of coordination are required in order to guarantee safe
+power-down and power-up at the cluster level.
+
+The mechanism presented in this document describes a coherent memory
+based protocol for performing the needed coordination.  It aims to be as
+lightweight as possible, while providing the required safety properties.
+
+
+Basic model
+-----------
+
+Each cluster and CPU is assigned a state, as follows:
+
+        DOWN
+        COMING_UP
+        UP
+        GOING_DOWN
+
+            +---------> UP ----------+
+            |                        v
+
+        COMING_UP                GOING_DOWN
+
+            ^                        |
+            +--------- DOWN <--------+
+
+
+DOWN:   The CPU or cluster is not coherent, and is either powered off or
+        suspended, or is ready to be powered off or suspended.
+
+COMING_UP: The CPU or cluster has committed to moving to the UP state.
+        It may be part way through the process of initialisation and
+        enabling coherency.
+
+UP:     The CPU or cluster is active and coherent at the hardware
+        level.  A CPU in this state is not necessarily being used
+        actively by the kernel.
+
+GOING_DOWN: The CPU or cluster has committed to moving to the DOWN
+        state.  It may be part way through the process of teardown and
+        coherency exit.
+
+
+Each CPU has one of these states assigned to it at any point in time.
+The CPU states are described in the "CPU state" section, below.
+
+Each cluster is also assigned a state, but it is necessary to split the
+state value into two parts (the "cluster" state and "inbound" state) and
+to introduce additional states in order to avoid races between different
+CPUs in the cluster simultaneously modifying the state.  The cluster-
+level states are described in the "Cluster state" section.
+
+To help distinguish the CPU states from cluster states in this
+discussion, the state names are given a CPU_ prefix for the CPU states,
+and a CLUSTER_ or INBOUND_ prefix for the cluster states.
+
+
+CPU state
+---------
+
+In this algorithm, each individual core in a multi-core processor is
+referred to as a "CPU".  CPUs are assumed to be single-threaded:
+therefore, a CPU can only be doing one thing at a single point in time.
+
+This means that CPUs fit the basic model closely.
+
+The algorithm defines the following states for each CPU in the system:
+
+        CPU_DOWN
+        CPU_COMING_UP
+        CPU_UP
+        CPU_GOING_DOWN
+
+         cluster setup and
+        CPU setup complete          policy decision
+              +-----------> CPU_UP ------------+
+              |                                v
+
+        CPU_COMING_UP                   CPU_GOING_DOWN
+
+              ^                                |
+              +----------- CPU_DOWN <----------+
+         policy decision           CPU teardown complete
+        or hardware event
+
+
+The definitions of the four states correspond closely to the states of
+the basic model.
+
+Transitions between states occur as follows.
+
+A trigger event (spontaneous) means that the CPU can transition to the
+next state as a result of making local progress only, with no
+requirement for any external event to happen.
+
+
+CPU_DOWN:
+
+        A CPU reaches the CPU_DOWN state when it is ready for
+        power-down.  On reaching this state, the CPU will typically
+        power itself down or suspend itself, via a WFI instruction or a
+        firmware call.
+
+        Next state:     CPU_COMING_UP
+        Conditions:     none
+
+        Trigger events:
+
+                a) an explicit hardware power-up operation, resulting
+                   from a policy decision on another CPU;
+
+                b) a hardware event, such as an interrupt.
+
+
+CPU_COMING_UP:
+
+        A CPU cannot start participating in hardware coherency until the
+        cluster is set up and coherent.  If the cluster is not ready,
+        then the CPU will wait in the CPU_COMING_UP state until the
+        cluster has been set up.
+
+        Next state:     CPU_UP
+        Conditions:     The CPU's parent cluster must be in CLUSTER_UP.
+        Trigger events: Transition of the parent cluster to CLUSTER_UP.
+
+        Refer to the "Cluster state" section for a description of the
+        CLUSTER_UP state.
+
+
+CPU_UP:
+        When a CPU reaches the CPU_UP state, it is safe for the CPU to
+        start participating in local coherency.
+
+        This is done by jumping to the kernel's CPU resume code.
+
+        Note that the definition of this state is slightly different
+        from the basic model definition: CPU_UP does not mean that the
+        CPU is coherent yet, but it does mean that it is safe to resume
+        the kernel.  The kernel handles the rest of the resume
+        procedure, so the remaining steps are not visible as part of the
+        race avoidance algorithm.
+
+        The CPU remains in this state until an explicit policy decision
+        is made to shut down or suspend the CPU.
+
+        Next state:     CPU_GOING_DOWN
+        Conditions:     none
+        Trigger events: explicit policy decision
+
+
+CPU_GOING_DOWN:
+
+        While in this state, the CPU exits coherency, including any
+        operations required to achieve this (such as cleaning data
+        caches).
+
+        Next state:     CPU_DOWN
+        Conditions:     local CPU teardown complete
+        Trigger events: (spontaneous)
+
+
+Cluster state
+-------------
+
+A cluster is a group of connected CPUs with some common resources.
+Because a cluster contains multiple CPUs, it can be doing multiple
+things at the same time.  This has some implications.  In particular, a
+CPU can start up while another CPU is tearing the cluster down.
+
+In this discussion, the "outbound side" is the view of the cluster state
+as seen by a CPU tearing the cluster down.  The "inbound side" is the
+view of the cluster state as seen by a CPU setting the CPU up.
+
+In order to enable safe coordination in such situations, it is important
+that a CPU which is setting up the cluster can advertise its state
+independently of the CPU which is tearing down the cluster.  For this
+reason, the cluster state is split into two parts:
+
+        "cluster" state: The global state of the cluster; or the state
+                on the outbound side:
+
+                CLUSTER_DOWN
+                CLUSTER_UP
+                CLUSTER_GOING_DOWN
+
+        "inbound" state: The state of the cluster on the inbound side.
+
+                INBOUND_NOT_COMING_UP
+                INBOUND_COMING_UP
+
+
+        The different pairings of these states results in six possible
+        states for the cluster as a whole:
+
+                                    CLUSTER_UP
+                  +==========> INBOUND_NOT_COMING_UP -------------+
+                  #                                               |
+                                                                  |
+             CLUSTER_UP     <----+                                |
+          INBOUND_COMING_UP      |                                v
+
+                  ^             CLUSTER_GOING_DOWN       CLUSTER_GOING_DOWN
+                  #              INBOUND_COMING_UP <=== INBOUND_NOT_COMING_UP
+
+            CLUSTER_DOWN         |                                |
+          INBOUND_COMING_UP <----+                                |
+                                                                  |
+                  ^                                               |
+                  +===========     CLUSTER_DOWN      <------------+
+                               INBOUND_NOT_COMING_UP
+
+        Transitions -----> can only be made by the outbound CPU, and
+        only involve changes to the "cluster" state.
+
+        Transitions ===##> can only be made by the inbound CPU, and only
+        involve changes to the "inbound" state, except where there is no
+        further transition possible on the outbound side (i.e., the
+        outbound CPU has put the cluster into the CLUSTER_DOWN state).
+
+        The race avoidance algorithm does not provide a way to determine
+        which exact CPUs within the cluster play these roles.  This must
+        be decided in advance by some other means.  Refer to the section
+        "Last man and first man selection" for more explanation.
+
+
+        CLUSTER_DOWN/INBOUND_NOT_COMING_UP is the only state where the
+        cluster can actually be powered down.
+
+        The parallelism of the inbound and outbound CPUs is observed by
+        the existence of two different paths from CLUSTER_GOING_DOWN/
+        INBOUND_NOT_COMING_UP (corresponding to GOING_DOWN in the basic
+        model) to CLUSTER_DOWN/INBOUND_COMING_UP (corresponding to
+        COMING_UP in the basic model).  The second path avoids cluster
+        teardown completely.
+
+        CLUSTER_UP/INBOUND_COMING_UP is equivalent to UP in the basic
+        model.  The final transition to CLUSTER_UP/INBOUND_NOT_COMING_UP
+        is trivial and merely resets the state machine ready for the
+        next cycle.
+
+        Details of the allowable transitions follow.
+
+        The next state in each case is notated
+
+                <cluster state>/<inbound state> (<transitioner>)
+
+        where the <transitioner> is the side on which the transition
+        can occur; either the inbound or the outbound side.
+
+
+CLUSTER_DOWN/INBOUND_NOT_COMING_UP:
+
+        Next state:     CLUSTER_DOWN/INBOUND_COMING_UP (inbound)
+        Conditions:     none
+        Trigger events:
+
+                a) an explicit hardware power-up operation, resulting
+                   from a policy decision on another CPU;
+
+                b) a hardware event, such as an interrupt.
+
+
+CLUSTER_DOWN/INBOUND_COMING_UP:
+
+        In this state, an inbound CPU sets up the cluster, including
+        enabling of hardware coherency at the cluster level and any
+        other operations (such as cache invalidation) which are required
+        in order to achieve this.
+
+        The purpose of this state is to do sufficient cluster-level
+        setup to enable other CPUs in the cluster to enter coherency
+        safely.
+
+        Next state:     CLUSTER_UP/INBOUND_COMING_UP (inbound)
+        Conditions:     cluster-level setup and hardware coherency complete
+        Trigger events: (spontaneous)
+
+
+CLUSTER_UP/INBOUND_COMING_UP:
+
+        Cluster-level setup is complete and hardware coherency is
+        enabled for the cluster.  Other CPUs in the cluster can safely
+        enter coherency.
+
+        This is a transient state, leading immediately to
+        CLUSTER_UP/INBOUND_NOT_COMING_UP.  All other CPUs on the cluster
+        should consider treat these two states as equivalent.
+
+        Next state:     CLUSTER_UP/INBOUND_NOT_COMING_UP (inbound)
+        Conditions:     none
+        Trigger events: (spontaneous)
+
+
+CLUSTER_UP/INBOUND_NOT_COMING_UP:
+
+        Cluster-level setup is complete and hardware coherency is
+        enabled for the cluster.  Other CPUs in the cluster can safely
+        enter coherency.
+
+        The cluster will remain in this state until a policy decision is
+        made to power the cluster down.
+
+        Next state:     CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP (outbound)
+        Conditions:     none
+        Trigger events: policy decision to power down the cluster
+
+
+CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP:
+
+        An outbound CPU is tearing the cluster down.  The selected CPU
+        must wait in this state until all CPUs in the cluster are in the
+        CPU_DOWN state.
+
+        When all CPUs are in the CPU_DOWN state, the cluster can be torn
+        down, for example by cleaning data caches and exiting
+        cluster-level coherency.
+
+        To avoid wasteful unnecessary teardown operations, the outbound
+        should check the inbound cluster state for asynchronous
+        transitions to INBOUND_COMING_UP.  Alternatively, individual
+        CPUs can be checked for entry into CPU_COMING_UP or CPU_UP.
+
+
+        Next states:
+
+        CLUSTER_DOWN/INBOUND_NOT_COMING_UP (outbound)
+                Conditions:     cluster torn down and ready to power off
+                Trigger events: (spontaneous)
+
+        CLUSTER_GOING_DOWN/INBOUND_COMING_UP (inbound)
+                Conditions:     none
+                Trigger events:
+
+                        a) an explicit hardware power-up operation,
+                           resulting from a policy decision on another
+                           CPU;
+
+                        b) a hardware event, such as an interrupt.
+
+
+CLUSTER_GOING_DOWN/INBOUND_COMING_UP:
+
+        The cluster is (or was) being torn down, but another CPU has
+        come online in the meantime and is trying to set up the cluster
+        again.
+
+        If the outbound CPU observes this state, it has two choices:
+
+                a) back out of teardown, restoring the cluster to the
+                   CLUSTER_UP state;
+
+                b) finish tearing the cluster down and put the cluster
+                   in the CLUSTER_DOWN state; the inbound CPU will
+                   set up the cluster again from there.
+
+        Choice (a) permits the removal of some latency by avoiding
+        unnecessary teardown and setup operations in situations where
+        the cluster is not really going to be powered down.
+
+
+        Next states:
+
+        CLUSTER_UP/INBOUND_COMING_UP (outbound)
+                Conditions:     cluster-level setup and hardware
+                                coherency complete
+                Trigger events: (spontaneous)
+
+        CLUSTER_DOWN/INBOUND_COMING_UP (outbound)
+                Conditions:     cluster torn down and ready to power off
+                Trigger events: (spontaneous)
+
+
+Last man and First man selection
+--------------------------------
+
+The CPU which performs cluster tear-down operations on the outbound side
+is commonly referred to as the "last man".
+
+The CPU which performs cluster setup on the inbound side is commonly
+referred to as the "first man".
+
+The race avoidance algorithm documented above does not provide a
+mechanism to choose which CPUs should play these roles.
+
+
+Last man:
+
+When shutting down the cluster, all the CPUs involved are initially
+executing Linux and hence coherent.  Therefore, ordinary spinlocks can
+be used to select a last man safely, before the CPUs become
+non-coherent.
+
+
+First man:
+
+Because CPUs may power up asynchronously in response to external wake-up
+events, a dynamic mechanism is needed to make sure that only one CPU
+attempts to play the first man role and do the cluster-level
+initialisation: any other CPUs must wait for this to complete before
+proceeding.
+
+Cluster-level initialisation may involve actions such as configuring
+coherency controls in the bus fabric.
+
+The current implementation in mcpm_head.S uses a separate mutual exclusion
+mechanism to do this arbitration.  This mechanism is documented in
+detail in vlocks.txt.
+
+
+Features and Limitations
+------------------------
+
+Implementation:
+
+        The current ARM-based implementation is split between
+        arch/arm/common/mcpm_head.S (low-level inbound CPU operations) and
+        arch/arm/common/mcpm_entry.c (everything else):
+
+        __mcpm_cpu_going_down() signals the transition of a CPU to the
+                CPU_GOING_DOWN state.
+
+        __mcpm_cpu_down() signals the transition of a CPU to the CPU_DOWN
+                state.
+
+        A CPU transitions to CPU_COMING_UP and then to CPU_UP via the
+                low-level power-up code in mcpm_head.S.  This could
+                involve CPU-specific setup code, but in the current
+                implementation it does not.
+
+        __mcpm_outbound_enter_critical() and __mcpm_outbound_leave_critical()
+                handle transitions from CLUSTER_UP to CLUSTER_GOING_DOWN
+                and from there to CLUSTER_DOWN or back to CLUSTER_UP (in
+                the case of an aborted cluster power-down).
+
+                These functions are more complex than the __mcpm_cpu_*()
+                functions due to the extra inter-CPU coordination which
+                is needed for safe transitions at the cluster level.
+
+        A cluster transitions from CLUSTER_DOWN back to CLUSTER_UP via
+                the low-level power-up code in mcpm_head.S.  This
+                typically involves platform-specific setup code,
+                provided by the platform-specific power_up_setup
+                function registered via mcpm_sync_init.
+
+Deep topologies:
+
+        As currently described and implemented, the algorithm does not
+        support CPU topologies involving more than two levels (i.e.,
+        clusters of clusters are not supported).  The algorithm could be
+        extended by replicating the cluster-level states for the
+        additional topological levels, and modifying the transition
+        rules for the intermediate (non-outermost) cluster levels.
+
+
+Colophon
+--------
+
+Originally created and documented by Dave Martin for Linaro Limited, in
+collaboration with Nicolas Pitre and Achin Gupta.
+
+Copyright (C) 2012-2013  Linaro Limited
+Distributed under the terms of Version 2 of the GNU General Public
+License, as defined in linux/COPYING.
diff --git a/Documentation/arm/firmware.txt b/Documentation/arm/firmware.txt
new file mode 100644
index 000000000000..c2e468fe7b0b
--- /dev/null
+++ b/Documentation/arm/firmware.txt
@@ -0,0 +1,88 @@
+Interface for registering and calling firmware-specific operations for ARM.
+----
+Written by Tomasz Figa <t.figa@samsung.com>
+
+Some boards are running with secure firmware running in TrustZone secure
+world, which changes the way some things have to be initialized. This makes
+a need to provide an interface for such platforms to specify available firmware
+operations and call them when needed.
+
+Firmware operations can be specified using struct firmware_ops
+
+        struct firmware_ops {
+                /*
+                * Enters CPU idle mode
+                */
+                int (*do_idle)(void);
+                /*
+                * Sets boot address of specified physical CPU
+                */
+                int (*set_cpu_boot_addr)(int cpu, unsigned long boot_addr);
+                /*
+                * Boots specified physical CPU
+                */
+                int (*cpu_boot)(int cpu);
+                /*
+                * Initializes L2 cache
+                */
+                int (*l2x0_init)(void);
+        };
+
+and then registered with register_firmware_ops function
+
+        void register_firmware_ops(const struct firmware_ops *ops)
+
+the ops pointer must be non-NULL.
+
+There is a default, empty set of operations provided, so there is no need to
+set anything if platform does not require firmware operations.
+
+To call a firmware operation, a helper macro is provided
+
+        #define call_firmware_op(op, ...)                               \
+                ((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
+
+the macro checks if the operation is provided and calls it or otherwise returns
+-ENOSYS to signal that given operation is not available (for example, to allow
+fallback to legacy operation).
+
+Example of registering firmware operations:
+
+        /* board file */
+
+        static int platformX_do_idle(void)
+        {
+                /* tell platformX firmware to enter idle */
+                return 0;
+        }
+
+        static int platformX_cpu_boot(int i)
+        {
+                /* tell platformX firmware to boot CPU i */
+                return 0;
+        }
+
+        static const struct firmware_ops platformX_firmware_ops = {
+                .do_idle        = exynos_do_idle,
+                .cpu_boot       = exynos_cpu_boot,
+                /* other operations not available on platformX */
+        };
+
+        /* init_early callback of machine descriptor */
+        static void __init board_init_early(void)
+        {
+                register_firmware_ops(&platformX_firmware_ops);
+        }
+
+Example of using a firmware operation:
+
+        /* some platform code, e.g. SMP initialization */
+
+        __raw_writel(virt_to_phys(exynos4_secondary_startup),
+                CPU1_BOOT_REG);
+
+        /* Call Exynos specific smc call */
+        if (call_firmware_op(cpu_boot, cpu) == -ENOSYS)
+                cpu_boot_legacy(...); /* Try legacy way */
+
+        gic_raise_softirq(cpumask_of(cpu), 1);
diff --git a/Documentation/arm/sunxi/clocks.txt b/Documentation/arm/sunxi/clocks.txt
new file mode 100644
index 000000000000..e09a88aa3136
--- /dev/null
+++ b/Documentation/arm/sunxi/clocks.txt
@@ -0,0 +1,56 @@
+Frequently asked questions about the sunxi clock system
+=======================================================
+
+This document contains useful bits of information that people tend to ask
+about the sunxi clock system, as well as accompanying ASCII art when adequate.
+
+Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the
+   system?
+
+A: The 24MHz oscillator allows gating to save power. Indeed, if gated
+   carelessly the system would stop functioning, but with the right
+   steps, one can gate it and keep the system running. Consider this
+   simplified suspend example:
+
+   While the system is operational, you would see something like
+
+      24MHz         32kHz
+       |
+      PLL1
+       \
+        \_ CPU Mux
+             |
+           [CPU]
+
+   When you are about to suspend, you switch the CPU Mux to the 32kHz
+   oscillator:
+
+      24Mhz         32kHz
+       |              |
+      PLL1            |
+                     /
+           CPU Mux _/
+             |
+           [CPU]
+
+    Finally you can gate the main oscillator
+
+                    32kHz
+                      |
+                      |
+                     /
+           CPU Mux _/
+             |
+           [CPU]
+
+Q: Were can I learn more about the sunxi clocks?
+
+A: The linux-sunxi wiki contains a page documenting the clock registers,
+   you can find it at
+
+        http://linux-sunxi.org/A10/CCM
+
+   The authoritative source for information at this time is the ccmu driver
+   released by Allwinner, you can find it at
+
+        https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.0/arch/arm/mach-sun4i/clock/ccmu
diff --git a/Documentation/arm/vlocks.txt b/Documentation/arm/vlocks.txt
new file mode 100644
index 000000000000..415960a9bab0
--- /dev/null
+++ b/Documentation/arm/vlocks.txt
@@ -0,0 +1,211 @@
+vlocks for Bare-Metal Mutual Exclusion
+======================================
+
+Voting Locks, or "vlocks" provide a simple low-level mutual exclusion
+mechanism, with reasonable but minimal requirements on the memory
+system.
+
+These are intended to be used to coordinate critical activity among CPUs
+which are otherwise non-coherent, in situations where the hardware
+provides no other mechanism to support this and ordinary spinlocks
+cannot be used.
+
+
+vlocks make use of the atomicity provided by the memory system for
+writes to a single memory location.  To arbitrate, every CPU "votes for
+itself", by storing a unique number to a common memory location.  The
+final value seen in that memory location when all the votes have been
+cast identifies the winner.
+
+In order to make sure that the election produces an unambiguous result
+in finite time, a CPU will only enter the election in the first place if
+no winner has been chosen and the election does not appear to have
+started yet.
+
+
+Algorithm
+---------
+
+The easiest way to explain the vlocks algorithm is with some pseudo-code:
+
+
+        int currently_voting[NR_CPUS] = { 0, };
+        int last_vote = -1; /* no votes yet */
+
+        bool vlock_trylock(int this_cpu)
+        {
+                /* signal our desire to vote */
+                currently_voting[this_cpu] = 1;
+                if (last_vote != -1) {
+                        /* someone already volunteered himself */
+                        currently_voting[this_cpu] = 0;
+                        return false; /* not ourself */
+                }
+
+                /* let's suggest ourself */
+                last_vote = this_cpu;
+                currently_voting[this_cpu] = 0;
+
+                /* then wait until everyone else is done voting */
+                for_each_cpu(i) {
+                        while (currently_voting[i] != 0)
+                                /* wait */;
+                }
+
+                /* result */
+                if (last_vote == this_cpu)
+                        return true; /* we won */
+                return false;
+        }
+
+        bool vlock_unlock(void)
+        {
+                last_vote = -1;
+        }
+
+
+The currently_voting[] array provides a way for the CPUs to determine
+whether an election is in progress, and plays a role analogous to the
+"entering" array in Lamport's bakery algorithm [1].
+
+However, once the election has started, the underlying memory system
+atomicity is used to pick the winner.  This avoids the need for a static
+priority rule to act as a tie-breaker, or any counters which could
+overflow.
+
+As long as the last_vote variable is globally visible to all CPUs, it
+will contain only one value that won't change once every CPU has cleared
+its currently_voting flag.
+
+
+Features and limitations
+------------------------
+
+ * vlocks are not intended to be fair.  In the contended case, it is the
+   _last_ CPU which attempts to get the lock which will be most likely
+   to win.
+
+   vlocks are therefore best suited to situations where it is necessary
+   to pick a unique winner, but it does not matter which CPU actually
+   wins.
+
+ * Like other similar mechanisms, vlocks will not scale well to a large
+   number of CPUs.
+
+   vlocks can be cascaded in a voting hierarchy to permit better scaling
+   if necessary, as in the following hypothetical example for 4096 CPUs:
+
+        /* first level: local election */
+        my_town = towns[(this_cpu >> 4) & 0xf];
+        I_won = vlock_trylock(my_town, this_cpu & 0xf);
+        if (I_won) {
+                /* we won the town election, let's go for the state */
+                my_state = states[(this_cpu >> 8) & 0xf];
+                I_won = vlock_lock(my_state, this_cpu & 0xf));
+                if (I_won) {
+                        /* and so on */
+                        I_won = vlock_lock(the_whole_country, this_cpu & 0xf];
+                        if (I_won) {
+                                /* ... */
+                        }
+                        vlock_unlock(the_whole_country);
+                }
+                vlock_unlock(my_state);
+        }
+        vlock_unlock(my_town);
+
+
+ARM implementation
+------------------
+
+The current ARM implementation [2] contains some optimisations beyond
+the basic algorithm:
+
+ * By packing the members of the currently_voting array close together,
+   we can read the whole array in one transaction (providing the number
+   of CPUs potentially contending the lock is small enough).  This
+   reduces the number of round-trips required to external memory.
+
+   In the ARM implementation, this means that we can use a single load
+   and comparison:
+
+        LDR     Rt, [Rn]
+        CMP     Rt, #0
+
+   ...in place of code equivalent to:
+
+        LDRB    Rt, [Rn]
+        CMP     Rt, #0
+        LDRBEQ  Rt, [Rn, #1]
+        CMPEQ   Rt, #0
+        LDRBEQ  Rt, [Rn, #2]
+        CMPEQ   Rt, #0
+        LDRBEQ  Rt, [Rn, #3]
+        CMPEQ   Rt, #0
+
+   This cuts down on the fast-path latency, as well as potentially
+   reducing bus contention in contended cases.
+
+   The optimisation relies on the fact that the ARM memory system
+   guarantees coherency between overlapping memory accesses of
+   different sizes, similarly to many other architectures.  Note that
+   we do not care which element of currently_voting appears in which
+   bits of Rt, so there is no need to worry about endianness in this
+   optimisation.
+
+   If there are too many CPUs to read the currently_voting array in
+   one transaction then multiple transations are still required.  The
+   implementation uses a simple loop of word-sized loads for this
+   case.  The number of transactions is still fewer than would be
+   required if bytes were loaded individually.
+
+
+   In principle, we could aggregate further by using LDRD or LDM, but
+   to keep the code simple this was not attempted in the initial
+   implementation.
+
+
+ * vlocks are currently only used to coordinate between CPUs which are
+   unable to enable their caches yet.  This means that the
+   implementation removes many of the barriers which would be required
+   when executing the algorithm in cached memory.
+
+   packing of the currently_voting array does not work with cached
+   memory unless all CPUs contending the lock are cache-coherent, due
+   to cache writebacks from one CPU clobbering values written by other
+   CPUs.  (Though if all the CPUs are cache-coherent, you should be
+   probably be using proper spinlocks instead anyway).
+
+
+ * The "no votes yet" value used for the last_vote variable is 0 (not
+   -1 as in the pseudocode).  This allows statically-allocated vlocks
+   to be implicitly initialised to an unlocked state simply by putting
+   them in .bss.
+
+   An offset is added to each CPU's ID for the purpose of setting this
+   variable, so that no CPU uses the value 0 for its ID.
+
+
+Colophon
+--------
+
+Originally created and documented by Dave Martin for Linaro Limited, for
+use in ARM-based big.LITTLE platforms, with review and input gratefully
+received from Nicolas Pitre and Achin Gupta.  Thanks to Nicolas for
+grabbing most of this text out of the relevant mail thread and writing
+up the pseudocode.
+
+Copyright (C) 2012-2013  Linaro Limited
+Distributed under the terms of Version 2 of the GNU General Public
+License, as defined in linux/COPYING.
+
+
+References
+----------
+
+[1] Lamport, L. "A New Solution of Dijkstra's Concurrent Programming
+    Problem", Communications of the ACM 17, 8 (August 1974), 453-455.
+
+    http://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm
+
+[2] linux/arch/arm/common/vlock.S, www.kernel.org.
diff --git a/Documentation/backlight/lp855x-driver.txt b/Documentation/backlight/lp855x-driver.txt
index 18b06ca038ea..1c732f0c6758 100644
--- a/Documentation/backlight/lp855x-driver.txt
+++ b/Documentation/backlight/lp855x-driver.txt
@@ -32,14 +32,10 @@ Platform data for lp855x
 For supporting platform specific data, the lp855x platform data can be used.
 
 * name : Backlight driver name. If it is not defined, default name is set.
-* mode : Brightness control mode. PWM or register based.
 * device_control : Value of DEVICE CONTROL register.
 * initial_brightness : Initial value of backlight brightness.
 * period_ns : Platform specific PWM period value. unit is nano.
              Only valid when brightness is pwm input mode.
-* load_new_rom_data :
-        0 : use default configuration data
-        1 : update values of eeprom or eprom registers on loading driver
 * size_program : Total size of lp855x_rom_data.
 * rom_data : List of new eeprom/eprom registers.
 
@@ -54,10 +50,8 @@ static struct lp855x_rom_data lp8552_eeprom_arr[] = {
 
 static struct lp855x_platform_data lp8552_pdata = {
         .name = "lcd-bl",
-        .mode = REGISTER_BASED,
         .device_control = I2C_CONFIG(LP8552),
         .initial_brightness = INITIAL_BRT,
-        .load_new_rom_data = 1,
         .size_program = ARRAY_SIZE(lp8552_eeprom_arr),
         .rom_data = lp8552_eeprom_arr,
 };
@@ -65,7 +59,6 @@ static struct lp855x_platform_data lp8552_pdata = {
 example 2) lp8556 platform data : pwm input mode with default rom data
 
 static struct lp855x_platform_data lp8556_pdata = {
-        .mode = PWM_BASED,
         .device_control = PWM_CONFIG(LP8556),
         .initial_brightness = INITIAL_BRT,
         .period_ns = 1000000,
diff --git a/Documentation/bcache.txt b/Documentation/bcache.txt
new file mode 100644
index 000000000000..77db8809bd96
--- /dev/null
+++ b/Documentation/bcache.txt
@@ -0,0 +1,431 @@
+Say you've got a big slow raid 6, and an X-25E or three. Wouldn't it be
+nice if you could use them as cache... Hence bcache.
+
+Wiki and git repositories are at:
+  http://bcache.evilpiepirate.org
+  http://evilpiepirate.org/git/linux-bcache.git
+  http://evilpiepirate.org/git/bcache-tools.git
+
+It's designed around the performance characteristics of SSDs - it only allocates
+in erase block sized buckets, and it uses a hybrid btree/log to track cached
+extants (which can be anywhere from a single sector to the bucket size). It's
+designed to avoid random writes at all costs; it fills up an erase block
+sequentially, then issues a discard before reusing it.
+
+Both writethrough and writeback caching are supported. Writeback defaults to
+off, but can be switched on and off arbitrarily at runtime. Bcache goes to
+great lengths to protect your data - it reliably handles unclean shutdown. (It
+doesn't even have a notion of a clean shutdown; bcache simply doesn't return
+writes as completed until they're on stable storage).
+
+Writeback caching can use most of the cache for buffering writes - writing
+dirty data to the backing device is always done sequentially, scanning from the
+start to the end of the index.
+
+Since random IO is what SSDs excel at, there generally won't be much benefit
+to caching large sequential IO. Bcache detects sequential IO and skips it;
+it also keeps a rolling average of the IO sizes per task, and as long as the
+average is above the cutoff it will skip all IO from that task - instead of
+caching the first 512k after every seek. Backups and large file copies should
+thus entirely bypass the cache.
+
+In the event of a data IO error on the flash it will try to recover by reading
+from disk or invalidating cache entries.  For unrecoverable errors (meta data
+or dirty data), caching is automatically disabled; if dirty data was present
+in the cache it first disables writeback caching and waits for all dirty data
+to be flushed.
+
+Getting started:
+You'll need make-bcache from the bcache-tools repository. Both the cache device
+and backing device must be formatted before use.
+  make-bcache -B /dev/sdb
+  make-bcache -C /dev/sdc
+
+make-bcache has the ability to format multiple devices at the same time - if
+you format your backing devices and cache device at the same time, you won't
+have to manually attach:
+  make-bcache -B /dev/sda /dev/sdb -C /dev/sdc
+
+To make bcache devices known to the kernel, echo them to /sys/fs/bcache/register:
+
+  echo /dev/sdb > /sys/fs/bcache/register
+  echo /dev/sdc > /sys/fs/bcache/register
+
+To register your bcache devices automatically, you could add something like
+this to an init script:
+
+  echo /dev/sd* > /sys/fs/bcache/register_quiet
+
+It'll look for bcache superblocks and ignore everything that doesn't have one.
+
+Registering the backing device makes the bcache show up in /dev; you can now
+format it and use it as normal. But the first time using a new bcache device,
+it'll be running in passthrough mode until you attach it to a cache. See the
+section on attaching.
+
+The devices show up at /dev/bcacheN, and can be controlled via sysfs from
+/sys/block/bcacheN/bcache:
+
+  mkfs.ext4 /dev/bcache0
+  mount /dev/bcache0 /mnt
+
+Cache devices are managed as sets; multiple caches per set isn't supported yet
+but will allow for mirroring of metadata and dirty data in the future. Your new
+cache set shows up as /sys/fs/bcache/<UUID>
+
+ATTACHING:
+
+After your cache device and backing device are registered, the backing device
+must be attached to your cache set to enable caching. Attaching a backing
+device to a cache set is done thusly, with the UUID of the cache set in
+/sys/fs/bcache:
+
+  echo <UUID> > /sys/block/bcache0/bcache/attach
+
+This only has to be done once. The next time you reboot, just reregister all
+your bcache devices. If a backing device has data in a cache somewhere, the
+/dev/bcache# device won't be created until the cache shows up - particularly
+important if you have writeback caching turned on.
+
+If you're booting up and your cache device is gone and never coming back, you
+can force run the backing device:
+
+  echo 1 > /sys/block/sdb/bcache/running
+
+(You need to use /sys/block/sdb (or whatever your backing device is called), not
+/sys/block/bcache0, because bcache0 doesn't exist yet. If you're using a
+partition, the bcache directory would be at /sys/block/sdb/sdb2/bcache)
+
+The backing device will still use that cache set if it shows up in the future,
+but all the cached data will be invalidated. If there was dirty data in the
+cache, don't expect the filesystem to be recoverable - you will have massive
+filesystem corruption, though ext4's fsck does work miracles.
+
+ERROR HANDLING:
+
+Bcache tries to transparently handle IO errors to/from the cache device without
+affecting normal operation; if it sees too many errors (the threshold is
+configurable, and defaults to 0) it shuts down the cache device and switches all
+the backing devices to passthrough mode.
+
+ - For reads from the cache, if they error we just retry the read from the
+   backing device.
+
+ - For writethrough writes, if the write to the cache errors we just switch to
+   invalidating the data at that lba in the cache (i.e. the same thing we do for
+   a write that bypasses the cache)
+
+ - For writeback writes, we currently pass that error back up to the
+   filesystem/userspace. This could be improved - we could retry it as a write
+   that skips the cache so we don't have to error the write.
+
+ - When we detach, we first try to flush any dirty data (if we were running in
+   writeback mode). It currently doesn't do anything intelligent if it fails to
+   read some of the dirty data, though.
+
+TROUBLESHOOTING PERFORMANCE:
+
+Bcache has a bunch of config options and tunables. The defaults are intended to
+be reasonable for typical desktop and server workloads, but they're not what you
+want for getting the best possible numbers when benchmarking.
+
+ - Bad write performance
+
+   If write performance is not what you expected, you probably wanted to be
+   running in writeback mode, which isn't the default (not due to a lack of
+   maturity, but simply because in writeback mode you'll lose data if something
+   happens to your SSD)
+
+   # echo writeback > /sys/block/bcache0/cache_mode
+
+ - Bad performance, or traffic not going to the SSD that you'd expect
+
+   By default, bcache doesn't cache everything. It tries to skip sequential IO -
+   because you really want to be caching the random IO, and if you copy a 10
+   gigabyte file you probably don't want that pushing 10 gigabytes of randomly
+   accessed data out of your cache.
+
+   But if you want to benchmark reads from cache, and you start out with fio
+   writing an 8 gigabyte test file - so you want to disable that.
+
+   # echo 0 > /sys/block/bcache0/bcache/sequential_cutoff
+
+   To set it back to the default (4 mb), do
+
+   # echo 4M > /sys/block/bcache0/bcache/sequential_cutoff
+
+ - Traffic's still going to the spindle/still getting cache misses
+
+   In the real world, SSDs don't always keep up with disks - particularly with
+   slower SSDs, many disks being cached by one SSD, or mostly sequential IO. So
+   you want to avoid being bottlenecked by the SSD and having it slow everything
+   down.
+
+   To avoid that bcache tracks latency to the cache device, and gradually
+   throttles traffic if the latency exceeds a threshold (it does this by
+   cranking down the sequential bypass).
+
+   You can disable this if you need to by setting the thresholds to 0:
+
+   # echo 0 > /sys/fs/bcache/<cache set>/congested_read_threshold_us
+   # echo 0 > /sys/fs/bcache/<cache set>/congested_write_threshold_us
+
+   The default is 2000 us (2 milliseconds) for reads, and 20000 for writes.
+
+ - Still getting cache misses, of the same data
+
+   One last issue that sometimes trips people up is actually an old bug, due to
+   the way cache coherency is handled for cache misses. If a btree node is full,
+   a cache miss won't be able to insert a key for the new data and the data
+   won't be written to the cache.
+
+   In practice this isn't an issue because as soon as a write comes along it'll
+   cause the btree node to be split, and you need almost no write traffic for
+   this to not show up enough to be noticable (especially since bcache's btree
+   nodes are huge and index large regions of the device). But when you're
+   benchmarking, if you're trying to warm the cache by reading a bunch of data
+   and there's no other traffic - that can be a problem.
+
+   Solution: warm the cache by doing writes, or use the testing branch (there's
+   a fix for the issue there).
+
+SYSFS - BACKING DEVICE:
+
+attach
+  Echo the UUID of a cache set to this file to enable caching.
+
+cache_mode
+  Can be one of either writethrough, writeback, writearound or none.
+
+clear_stats
+  Writing to this file resets the running total stats (not the day/hour/5 minute
+  decaying versions).
+
+detach
+  Write to this file to detach from a cache set. If there is dirty data in the
+  cache, it will be flushed first.
+
+dirty_data
+  Amount of dirty data for this backing device in the cache. Continuously
+  updated unlike the cache set's version, but may be slightly off.
+
+label
+  Name of underlying device.
+
+readahead
+  Size of readahead that should be performed.  Defaults to 0.  If set to e.g.
+  1M, it will round cache miss reads up to that size, but without overlapping
+  existing cache entries.
+
+running
+  1 if bcache is running (i.e. whether the /dev/bcache device exists, whether
+  it's in passthrough mode or caching).
+
+sequential_cutoff
+  A sequential IO will bypass the cache once it passes this threshhold; the
+  most recent 128 IOs are tracked so sequential IO can be detected even when
+  it isn't all done at once.
+
+sequential_merge
+  If non zero, bcache keeps a list of the last 128 requests submitted to compare
+  against all new requests to determine which new requests are sequential
+  continuations of previous requests for the purpose of determining sequential
+  cutoff. This is necessary if the sequential cutoff value is greater than the
+  maximum acceptable sequential size for any single request. 
+
+state
+  The backing device can be in one of four different states:
+
+  no cache: Has never been attached to a cache set.
+
+  clean: Part of a cache set, and there is no cached dirty data.
+
+  dirty: Part of a cache set, and there is cached dirty data.
+
+  inconsistent: The backing device was forcibly run by the user when there was
+  dirty data cached but the cache set was unavailable; whatever data was on the
+  backing device has likely been corrupted.
+
+stop
+  Write to this file to shut down the bcache device and close the backing
+  device.
+
+writeback_delay
+  When dirty data is written to the cache and it previously did not contain
+  any, waits some number of seconds before initiating writeback. Defaults to
+  30.
+
+writeback_percent
+  If nonzero, bcache tries to keep around this percentage of the cache dirty by
+  throttling background writeback and using a PD controller to smoothly adjust
+  the rate.
+
+writeback_rate
+  Rate in sectors per second - if writeback_percent is nonzero, background
+  writeback is throttled to this rate. Continuously adjusted by bcache but may
+  also be set by the user.
+
+writeback_running
+  If off, writeback of dirty data will not take place at all. Dirty data will
+  still be added to the cache until it is mostly full; only meant for
+  benchmarking. Defaults to on.
+
+SYSFS - BACKING DEVICE STATS:
+
+There are directories with these numbers for a running total, as well as
+versions that decay over the past day, hour and 5 minutes; they're also
+aggregated in the cache set directory as well.
+
+bypassed
+  Amount of IO (both reads and writes) that has bypassed the cache
+
+cache_hits
+cache_misses
+cache_hit_ratio
+  Hits and misses are counted per individual IO as bcache sees them; a
+  partial hit is counted as a miss.
+
+cache_bypass_hits
+cache_bypass_misses
+  Hits and misses for IO that is intended to skip the cache are still counted,
+  but broken out here.
+
+cache_miss_collisions
+  Counts instances where data was going to be inserted into the cache from a
+  cache miss, but raced with a write and data was already present (usually 0
+  since the synchronization for cache misses was rewritten)
+
+cache_readaheads
+  Count of times readahead occured.
+
+SYSFS - CACHE SET:
+
+average_key_size
+  Average data per key in the btree.
+
+bdev<0..n>
+  Symlink to each of the attached backing devices.
+
+block_size
+  Block size of the cache devices.
+
+btree_cache_size
+  Amount of memory currently used by the btree cache
+
+bucket_size
+  Size of buckets
+
+cache<0..n>
+  Symlink to each of the cache devices comprising this cache set. 
+
+cache_available_percent
+  Percentage of cache device free.
+
+clear_stats
+  Clears the statistics associated with this cache
+
+dirty_data
+  Amount of dirty data is in the cache (updated when garbage collection runs).
+
+flash_vol_create
+  Echoing a size to this file (in human readable units, k/M/G) creates a thinly
+  provisioned volume backed by the cache set.
+
+io_error_halflife
+io_error_limit
+  These determines how many errors we accept before disabling the cache.
+  Each error is decayed by the half life (in # ios).  If the decaying count
+  reaches io_error_limit dirty data is written out and the cache is disabled.
+
+journal_delay_ms
+  Journal writes will delay for up to this many milliseconds, unless a cache
+  flush happens sooner. Defaults to 100.
+
+root_usage_percent
+  Percentage of the root btree node in use.  If this gets too high the node
+  will split, increasing the tree depth.
+
+stop
+  Write to this file to shut down the cache set - waits until all attached
+  backing devices have been shut down.
+
+tree_depth
+  Depth of the btree (A single node btree has depth 0).
+
+unregister
+  Detaches all backing devices and closes the cache devices; if dirty data is
+  present it will disable writeback caching and wait for it to be flushed.
+
+SYSFS - CACHE SET INTERNAL:
+
+This directory also exposes timings for a number of internal operations, with
+separate files for average duration, average frequency, last occurence and max
+duration: garbage collection, btree read, btree node sorts and btree splits.
+
+active_journal_entries
+  Number of journal entries that are newer than the index.
+
+btree_nodes
+  Total nodes in the btree.
+
+btree_used_percent
+  Average fraction of btree in use.
+
+bset_tree_stats
+  Statistics about the auxiliary search trees
+
+btree_cache_max_chain
+  Longest chain in the btree node cache's hash table
+
+cache_read_races
+  Counts instances where while data was being read from the cache, the bucket
+  was reused and invalidated - i.e. where the pointer was stale after the read
+  completed. When this occurs the data is reread from the backing device.
+
+trigger_gc
+  Writing to this file forces garbage collection to run.
+
+SYSFS - CACHE DEVICE:
+
+block_size
+  Minimum granularity of writes - should match hardware sector size.
+
+btree_written
+  Sum of all btree writes, in (kilo/mega/giga) bytes
+
+bucket_size
+  Size of buckets
+
+cache_replacement_policy
+  One of either lru, fifo or random.
+
+discard
+  Boolean; if on a discard/TRIM will be issued to each bucket before it is
+  reused. Defaults to off, since SATA TRIM is an unqueued command (and thus
+  slow).
+
+freelist_percent
+  Size of the freelist as a percentage of nbuckets. Can be written to to
+  increase the number of buckets kept on the freelist, which lets you
+  artificially reduce the size of the cache at runtime. Mostly for testing
+  purposes (i.e. testing how different size caches affect your hit rate), but
+  since buckets are discarded when they move on to the freelist will also make
+  the SSD's garbage collection easier by effectively giving it more reserved
+  space.
+
+io_errors
+  Number of errors that have occured, decayed by io_error_halflife.
+
+metadata_written
+  Sum of all non data writes (btree writes and all other metadata).
+
+nbuckets
+  Total buckets in this cache
+
+priority_stats
+  Statistics about how recently data in the cache has been accessed.  This can
+  reveal your working set size.
+
+written
+  Sum of all data that has been written to the cache; comparison with
+  btree_written gives the amount of write inflation in bcache.
diff --git a/Documentation/block/cfq-iosched.txt b/Documentation/block/cfq-iosched.txt
index a5eb7d19a65d..9887f0414c16 100644
--- a/Documentation/block/cfq-iosched.txt
+++ b/Documentation/block/cfq-iosched.txt
@@ -5,7 +5,7 @@ The main aim of CFQ scheduler is to provide a fair allocation of the disk
 I/O bandwidth for all the processes which requests an I/O operation.
 
 CFQ maintains the per process queue for the processes which request I/O
-operation(syncronous requests). In case of asynchronous requests, all the
+operation(synchronous requests). In case of asynchronous requests, all the
 requests from all the processes are batched together according to their
 process's I/O priority.
 
@@ -66,6 +66,47 @@ This parameter is used to set the timeout of synchronous requests. Default
 value of this is 124ms. In case to favor synchronous requests over asynchronous
 one, this value should be decreased relative to fifo_expire_async.
 
+group_idle
+-----------
+This parameter forces idling at the CFQ group level instead of CFQ
+queue level. This was introduced after after a bottleneck was observed
+in higher end storage due to idle on sequential queue and allow dispatch
+from a single queue. The idea with this parameter is that it can be run with
+slice_idle=0 and group_idle=8, so that idling does not happen on individual
+queues in the group but happens overall on the group and thus still keeps the
+IO controller working.
+Not idling on individual queues in the group will dispatch requests from
+multiple queues in the group at the same time and achieve higher throughput
+on higher end storage.
+
+Default value for this parameter is 8ms.
+
+latency
+-------
+This parameter is used to enable/disable the latency mode of the CFQ
+scheduler. If latency mode (called low_latency) is enabled, CFQ tries
+to recompute the slice time for each process based on the target_latency set
+for the system. This favors fairness over throughput. Disabling low
+latency (setting it to 0) ignores target latency, allowing each process in the
+system to get a full time slice.
+
+By default low latency mode is enabled.
+
+target_latency
+--------------
+This parameter is used to calculate the time slice for a process if cfq's
+latency mode is enabled. It will ensure that sync requests have an estimated
+latency. But if sequential workload is higher(e.g. sequential read),
+then to meet the latency constraints, throughput may decrease because of less
+time for each process to issue I/O request before the cfq queue is switched.
+
+Though this can be overcome by disabling the latency_mode, it may increase
+the read latency for some applications. This parameter allows for changing
+target_latency through the sysfs interface which can provide the balanced
+throughput and read latency.
+
+Default value for target_latency is 300ms.
+
 slice_async
 -----------
 This parameter is same as of slice_sync but for asynchronous queue. The
@@ -98,8 +139,8 @@ in the device exceeds this parameter. This parameter is used for synchronous
 request.
 
 In case of storage with several disk, this setting can limit the parallel
-processing of request. Therefore, increasing the value can imporve the
-performace although this can cause the latency of some I/O to increase due
+processing of request. Therefore, increasing the value can improve the
+performance although this can cause the latency of some I/O to increase due
 to more number of requests.
 
 CFQ Group scheduling
diff --git a/Documentation/cgroups/00-INDEX b/Documentation/cgroups/00-INDEX
index f5635a09c3f6..bc461b6425a7 100644
--- a/Documentation/cgroups/00-INDEX
+++ b/Documentation/cgroups/00-INDEX
@@ -18,6 +18,8 @@ memcg_test.txt
         - Memory Resource Controller; implementation details.
 memory.txt
         - Memory Resource Controller; design, accounting, interface, testing.
+net_cls.txt
+        - Network classifier cgroups details and usages.
 net_prio.txt
         - Network priority cgroups details and usages.
 resource_counter.txt
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
index bcf1a00b06a1..638bf17ff869 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -442,7 +442,7 @@ You can attach the current shell task by echoing 0:
 You can use the cgroup.procs file instead of the tasks file to move all
 threads in a threadgroup at once. Echoing the PID of any task in a
 threadgroup to cgroup.procs causes all tasks in that threadgroup to be
-be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
+attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
 in the writing task's threadgroup.
 
 Note: Since every task is always a member of exactly one cgroup in each
@@ -580,6 +580,7 @@ propagation along the hierarchy. See the comment on
 cgroup_for_each_descendant_pre() for details.
 
 void css_offline(struct cgroup *cgrp);
+(cgroup_mutex held by caller)
 
 This is the counterpart of css_online() and called iff css_online()
 has succeeded on @cgrp. This signifies the beginning of the end of
diff --git a/Documentation/cgroups/devices.txt b/Documentation/cgroups/devices.txt
index 16624a7f8222..3c1095ca02ea 100644
--- a/Documentation/cgroups/devices.txt
+++ b/Documentation/cgroups/devices.txt
@@ -13,9 +13,7 @@ either an integer or * for all.  Access is a composition of r
 The root device cgroup starts with rwm to 'all'.  A child device
 cgroup gets a copy of the parent.  Administrators can then remove
 devices from the whitelist or add new entries.  A child cgroup can
-never receive a device access which is denied by its parent.  However
-when a device access is removed from a parent it will not also be
-removed from the child(ren).
+never receive a device access which is denied by its parent.
 
 2. User Interface
 
@@ -50,3 +48,69 @@ task to a new cgroup.  (Again we'll probably want to change that).
 
 A cgroup may not be granted more permissions than the cgroup's
 parent has.
+
+4. Hierarchy
+
+device cgroups maintain hierarchy by making sure a cgroup never has more
+access permissions than its parent.  Every time an entry is written to
+a cgroup's devices.deny file, all its children will have that entry removed
+from their whitelist and all the locally set whitelist entries will be
+re-evaluated.  In case one of the locally set whitelist entries would provide
+more access than the cgroup's parent, it'll be removed from the whitelist.
+
+Example:
+      A
+     / \
+        B
+
+    group        behavior       exceptions
+    A            allow          "b 8:* rwm", "c 116:1 rw"
+    B            deny           "c 1:3 rwm", "c 116:2 rwm", "b 3:* rwm"
+
+If a device is denied in group A:
+        # echo "c 116:* r" > A/devices.deny
+it'll propagate down and after revalidating B's entries, the whitelist entry
+"c 116:2 rwm" will be removed:
+
+    group        whitelist entries                        denied devices
+    A            all                                      "b 8:* rwm", "c 116:* rw"
+    B            "c 1:3 rwm", "b 3:* rwm"                 all the rest
+
+In case parent's exceptions change and local exceptions are not allowed
+anymore, they'll be deleted.
+
+Notice that new whitelist entries will not be propagated:
+      A
+     / \
+        B
+
+    group        whitelist entries                        denied devices
+    A            "c 1:3 rwm", "c 1:5 r"                   all the rest
+    B            "c 1:3 rwm", "c 1:5 r"                   all the rest
+
+when adding "c *:3 rwm":
+        # echo "c *:3 rwm" >A/devices.allow
+
+the result:
+    group        whitelist entries                        denied devices
+    A            "c *:3 rwm", "c 1:5 r"                   all the rest
+    B            "c 1:3 rwm", "c 1:5 r"                   all the rest
+
+but now it'll be possible to add new entries to B:
+        # echo "c 2:3 rwm" >B/devices.allow
+        # echo "c 50:3 r" >B/devices.allow
+or even
+        # echo "c *:3 rwm" >B/devices.allow
+
+Allowing or denying all by writing 'a' to devices.allow or devices.deny will
+not be possible once the device cgroups has children.
+
+4.1 Hierarchy (internal implementation)
+
+device cgroups is implemented internally using a behavior (ALLOW, DENY) and a
+list of exceptions.  The internal state is controlled using the same user
+interface to preserve compatibility with the previous whitelist-only
+implementation.  Removal or addition of exceptions that will reduce the access
+to devices will be propagated down the hierarchy.
+For every propagated exception, the effective rules will be re-evaluated based
+on current parent's access rules.
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index 8b8c28b9864c..ddf4f93967a9 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -40,6 +40,7 @@ Features:
  - soft limit
  - moving (recharging) account at moving a task is selectable.
  - usage threshold notifier
+ - memory pressure notifier
  - oom-killer disable knob and oom-notifier
  - Root cgroup has no limit controls.
 
@@ -65,6 +66,7 @@ Brief summary of control files.
  memory.stat                     # show various statistics
  memory.use_hierarchy            # set/show hierarchical account enabled
  memory.force_empty              # trigger forced move charge to parent
+ memory.pressure_level           # set memory pressure notifications
  memory.swappiness               # set/show swappiness parameter of vmscan
                                  (See sysctl's vm.swappiness)
  memory.move_charge_at_immigrate # set/show controls of moving charges
@@ -194,7 +196,7 @@ the cgroup that brought it in -- this will happen on memory pressure).
 But see section 8.2: when moving a task to another cgroup, its pages may
 be recharged to the new cgroup, if move_charge_at_immigrate has been chosen.
 
-Exception: If CONFIG_CGROUP_CGROUP_MEMCG_SWAP is not used.
+Exception: If CONFIG_MEMCG_SWAP is not used.
 When you do swapoff and make swapped-out pages of shmem(tmpfs) to
 be backed into memory in force, charges for pages are accounted against the
 caller of swapoff rather than the users of shmem.
@@ -478,7 +480,9 @@ memory.stat file includes following statistics
 
 # per-memory cgroup local status
 cache           - # of bytes of page cache memory.
-rss             - # of bytes of anonymous and swap cache memory.
+rss             - # of bytes of anonymous and swap cache memory (includes
+                transparent hugepages).
+rss_huge        - # of bytes of anonymous transparent hugepages.
 mapped_file     - # of bytes of mapped file (includes tmpfs/shmem)
 pgpgin          - # of charging events to the memory cgroup. The charging
                 event happens each time a page is accounted as either mapped
@@ -762,7 +766,73 @@ At reading, current status of OOM is shown.
         under_oom        0 or 1 (if 1, the memory cgroup is under OOM, tasks may
                                  be stopped.)
 
-11. TODO
+11. Memory Pressure
+
+The pressure level notifications can be used to monitor the memory
+allocation cost; based on the pressure, applications can implement
+different strategies of managing their memory resources. The pressure
+levels are defined as following:
+
+The "low" level means that the system is reclaiming memory for new
+allocations. Monitoring this reclaiming activity might be useful for
+maintaining cache level. Upon notification, the program (typically
+"Activity Manager") might analyze vmstat and act in advance (i.e.
+prematurely shutdown unimportant services).
+
+The "medium" level means that the system is experiencing medium memory
+pressure, the system might be making swap, paging out active file caches,
+etc. Upon this event applications may decide to further analyze
+vmstat/zoneinfo/memcg or internal memory usage statistics and free any
+resources that can be easily reconstructed or re-read from a disk.
+
+The "critical" level means that the system is actively thrashing, it is
+about to out of memory (OOM) or even the in-kernel OOM killer is on its
+way to trigger. Applications should do whatever they can to help the
+system. It might be too late to consult with vmstat or any other
+statistics, so it's advisable to take an immediate action.
+
+The events are propagated upward until the event is handled, i.e. the
+events are not pass-through. Here is what this means: for example you have
+three cgroups: A->B->C. Now you set up an event listener on cgroups A, B
+and C, and suppose group C experiences some pressure. In this situation,
+only group C will receive the notification, i.e. groups A and B will not
+receive it. This is done to avoid excessive "broadcasting" of messages,
+which disturbs the system and which is especially bad if we are low on
+memory or thrashing. So, organize the cgroups wisely, or propagate the
+events manually (or, ask us to implement the pass-through events,
+explaining why would you need them.)
+
+The file memory.pressure_level is only used to setup an eventfd. To
+register a notification, an application must:
+
+- create an eventfd using eventfd(2);
+- open memory.pressure_level;
+- write string like "<event_fd> <fd of memory.pressure_level> <level>"
+  to cgroup.event_control.
+
+Application will be notified through eventfd when memory pressure is at
+the specific level (or higher). Read/write operations to
+memory.pressure_level are no implemented.
+
+Test:
+
+   Here is a small script example that makes a new cgroup, sets up a
+   memory limit, sets up a notification in the cgroup and then makes child
+   cgroup experience a critical pressure:
+
+   # cd /sys/fs/cgroup/memory/
+   # mkdir foo
+   # cd foo
+   # cgroup_event_listener memory.pressure_level low &
+   # echo 8000000 > memory.limit_in_bytes
+   # echo 8000000 > memory.memsw.limit_in_bytes
+   # echo $$ > tasks
+   # dd if=/dev/zero | read x
+
+   (Expect a bunch of notifications, and eventually, the oom-killer will
+   trigger.)
+
+12. TODO
 
 1. Add support for accounting huge pages (as a separate controller)
 2. Make per-cgroup scanner reclaim not-shared pages first
diff --git a/Documentation/cgroups/net_cls.txt b/Documentation/cgroups/net_cls.txt
new file mode 100644
index 000000000000..9face6bb578a
--- /dev/null
+++ b/Documentation/cgroups/net_cls.txt
@@ -0,0 +1,34 @@
+Network classifier cgroup
+-------------------------
+
+The Network classifier cgroup provides an interface to
+tag network packets with a class identifier (classid).
+
+The Traffic Controller (tc) can be used to assign
+different priorities to packets from different cgroups.
+
+Creating a net_cls cgroups instance creates a net_cls.classid file.
+This net_cls.classid value is initialized to 0.
+
+You can write hexadecimal values to net_cls.classid; the format for these
+values is 0xAAAABBBB; AAAA is the major handle number and BBBB
+is the minor handle number.
+Reading net_cls.classid yields a decimal result.
+
+Example:
+mkdir /sys/fs/cgroup/net_cls
+mount -t cgroup -onet_cls net_cls /sys/fs/cgroup/net_cls
+mkdir /sys/fs/cgroup/net_cls/0
+echo 0x100001 >  /sys/fs/cgroup/net_cls/0/net_cls.classid
+        - setting a 10:1 handle.
+
+cat /sys/fs/cgroup/net_cls/0/net_cls.classid
+1048577
+
+configuring tc:
+tc qdisc add dev eth0 root handle 10: htb
+
+tc class add dev eth0 parent 10: classid 10:1 htb rate 40mbit
+ - creating traffic class 10:1
+
+tc filter add dev eth0 parent 10: protocol ip prio 10 handle 1: cgroup
diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 1943fae014fd..b9911c27f496 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -174,9 +174,9 @@ int clk_foo_enable(struct clk_hw *hw)
 };
 
 Below is a matrix detailing which clk_ops are mandatory based upon the
-hardware capbilities of that clock.  A cell marked as "y" means
+hardware capabilities of that clock.  A cell marked as "y" means
 mandatory, a cell marked as "n" implies that either including that
-callback is invalid or otherwise uneccesary.  Empty cells are either
+callback is invalid or otherwise unnecessary.  Empty cells are either
 optional or must be evaluated on a case-by-case basis.
 
                            clock hardware characteristics
@@ -231,3 +231,14 @@ To better enforce this policy, always follow this simple rule: any
 statically initialized clock data MUST be defined in a separate file
 from the logic that implements its ops.  Basically separate the logic
 from the data and all is well.
+
+        Part 6 - Disabling clock gating of unused clocks
+
+Sometimes during development it can be useful to be able to bypass the
+default disabling of unused clocks. For example, if drivers aren't enabling
+clocks properly but rely on them being on from the bootloader, bypassing
+the disabling means that the driver will remain functional while the issues
+are sorted out.
+
+To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
+kernel.
diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt
index dffa2d620d6d..18de78599dd4 100644
--- a/Documentation/coccinelle.txt
+++ b/Documentation/coccinelle.txt
@@ -114,7 +114,7 @@ To apply Coccinelle to a specific directory, M= can be used.
 For example, to check drivers/net/wireless/ one may write:
 
     make coccicheck M=drivers/net/wireless/
-    
+
 To apply Coccinelle on a file basis, instead of a directory basis, the
 following command may be used:
 
@@ -134,6 +134,15 @@ MODE variable explained above.
 In this mode, there is no information about semantic patches
 displayed, and no commit message proposed.
 
+ Additional flags
+~~~~~~~~~~~~~~~~~~
+
+Additional flags can be passed to spatch through the SPFLAGS
+variable.
+
+    make SPFLAGS=--use_glimpse coccicheck
+
+See spatch --help to learn more about spatch options.
 
  Proposing new semantic patches
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt
index 72f70b16d299..a3585eac83b6 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -108,8 +108,9 @@ policy->governor		must contain the "default policy" for
                                 cpufreq_driver.target is called with
                                 these values.
 
-For setting some of these values, the frequency table helpers might be
-helpful. See the section 2 for more information on them.
+For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the
+frequency table helpers might be helpful. See the section 2 for more information
+on them.
 
 SMP systems normally have same clock source for a group of cpus. For these the
 .init() would be called only once for the first online cpu. Here the .init()
@@ -184,10 +185,10 @@ the reference implementation in drivers/cpufreq/longrun.c
 As most cpufreq processors only allow for being set to a few specific
 frequencies, a "frequency table" with some functions might assist in
 some work of the processor driver. Such a "frequency table" consists
-of an array of struct cpufreq_freq_table entries, with any value in
+of an array of struct cpufreq_frequency_table entries, with any value in
 "index" you want to use, and the corresponding frequency in
 "frequency". At the end of the table, you need to add a
-cpufreq_freq_table entry with frequency set to CPUFREQ_TABLE_END. And
+cpufreq_frequency_table entry with frequency set to CPUFREQ_TABLE_END. And
 if you want to skip one entry in the table, set the frequency to 
 CPUFREQ_ENTRY_INVALID. The entries don't need to be in ascending
 order.
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt
index c7a2eb8450c2..219970ba54b7 100644
--- a/Documentation/cpu-freq/governors.txt
+++ b/Documentation/cpu-freq/governors.txt
@@ -131,8 +131,8 @@ sampling_rate_min:
 The sampling rate is limited by the HW transition latency:
 transition_latency * 100
 Or by kernel restrictions:
-If CONFIG_NO_HZ is set, the limit is 10ms fixed.
-If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the
+If CONFIG_NO_HZ_COMMON is set, the limit is 10ms fixed.
+If CONFIG_NO_HZ_COMMON is not set or nohz=off boot parameter is used, the
 limits depend on the CONFIG_HZ option:
 HZ=1000: min=20000us  (20ms)
 HZ=250:  min=80000us  (80ms)
@@ -167,6 +167,27 @@ of load evaluation and helping the CPU stay at its top speed when truly
 busy, rather than shifting back and forth in speed. This tunable has no
 effect on behavior at lower speeds/lower CPU loads.
 
+powersave_bias: this parameter takes a value between 0 to 1000. It
+defines the percentage (times 10) value of the target frequency that
+will be shaved off of the target. For example, when set to 100 -- 10%,
+when ondemand governor would have targeted 1000 MHz, it will target
+1000 MHz - (10% of 1000 MHz) = 900 MHz instead. This is set to 0
+(disabled) by default.
+When AMD frequency sensitivity powersave bias driver --
+drivers/cpufreq/amd_freq_sensitivity.c is loaded, this parameter
+defines the workload frequency sensitivity threshold in which a lower
+frequency is chosen instead of ondemand governor's original target.
+The frequency sensitivity is a hardware reported (on AMD Family 16h
+Processors and above) value between 0 to 100% that tells software how
+the performance of the workload running on a CPU will change when
+frequency changes. A workload with sensitivity of 0% (memory/IO-bound)
+will not perform any better on higher core frequency, whereas a
+workload with sensitivity of 100% (CPU-bound) will perform better
+higher the frequency. When the driver is loaded, this is set to 400
+by default -- for CPUs running workloads with sensitivity value below
+40%, a lower frequency is chosen. Unloading the driver or writing 0
+will disable this feature.
+
 
 2.5 Conservative
 ----------------
@@ -191,6 +212,12 @@ governor but for the opposite direction.  For example when set to its
 default value of '20' it means that if the CPU usage needs to be below
 20% between samples to have the frequency decreased.
 
+sampling_down_factor: similar functionality as in "ondemand" governor.
+But in "conservative", it controls the rate at which the kernel makes
+a decision on when to decrease the frequency while running in any
+speed. Load for frequency increase is still evaluated every
+sampling rate.
+
 3. The Governor Interface in the CPUfreq Core
 =============================================
 
diff --git a/Documentation/cpuidle/driver.txt b/Documentation/cpuidle/driver.txt
index 7a9e09ece931..1b0d81d92583 100644
--- a/Documentation/cpuidle/driver.txt
+++ b/Documentation/cpuidle/driver.txt
@@ -15,11 +15,17 @@ has mechanisms in place to support actual entry-exit into CPU idle states.
 cpuidle driver initializes the cpuidle_device structure for each CPU device
 and registers with cpuidle using cpuidle_register_device.
 
+If all the idle states are the same, the wrapper function cpuidle_register
+could be used instead.
+
 It can also support the dynamic changes (like battery <-> AC), by using
 cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
 cpuidle_resume_and_unlock.
 
 Interfaces:
+extern int cpuidle_register(struct cpuidle_driver *drv,
+                            const struct cpumask *const coupled_cpus);
+extern int cpuidle_unregister(struct cpuidle_driver *drv);
 extern int cpuidle_register_driver(struct cpuidle_driver *drv);
 extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
 extern int cpuidle_register_device(struct cpuidle_device *dev);
diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt
index 56fb62b09fc5..e9192283e5a5 100644
--- a/Documentation/device-mapper/dm-raid.txt
+++ b/Documentation/device-mapper/dm-raid.txt
@@ -1,10 +1,13 @@
 dm-raid
--------
+=======
 
 The device-mapper RAID (dm-raid) target provides a bridge from DM to MD.
 It allows the MD RAID drivers to be accessed using a device-mapper
 interface.
 
+
+Mapping Table Interface
+-----------------------
 The target is named "raid" and it accepts the following parameters:
 
   <raid_type> <#raid_params> <raid_params> \
@@ -30,6 +33,7 @@ The target is named "raid" and it accepts the following parameters:
   raid10        Various RAID10 inspired algorithms chosen by additional params
                 - RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
                 - RAID1E: Integrated Adjacent Stripe Mirroring
+                - RAID1E: Integrated Offset Stripe Mirroring
                 -  and other similar RAID10 variants
 
   Reference: Chapter 4 of
@@ -46,7 +50,7 @@ The target is named "raid" and it accepts the following parameters:
     followed by optional parameters (in any order):
         [sync|nosync]   Force or prevent RAID initialization.
 
-        [rebuild <idx>] Rebuild drive number idx (first drive is 0).
+        [rebuild <idx>] Rebuild drive number 'idx' (first drive is 0).
 
         [daemon_sleep <ms>]
                 Interval between runs of the bitmap daemon that
@@ -55,24 +59,24 @@ The target is named "raid" and it accepts the following parameters:
 
         [min_recovery_rate <kB/sec/disk>]  Throttle RAID initialization
         [max_recovery_rate <kB/sec/disk>]  Throttle RAID initialization
-        [write_mostly <idx>]               Drive index is write-mostly
-        [max_write_behind <sectors>]       See '-write-behind=' (man mdadm)
-        [stripe_cache <sectors>]           Stripe cache size (higher RAIDs only)
+        [write_mostly <idx>]               Mark drive index 'idx' write-mostly.
+        [max_write_behind <sectors>]       See '--write-behind=' (man mdadm)
+        [stripe_cache <sectors>]           Stripe cache size (RAID 4/5/6 only)
         [region_size <sectors>]
                 The region_size multiplied by the number of regions is the
                 logical size of the array.  The bitmap records the device
                 synchronisation state for each region.
 
         [raid10_copies   <# copies>]
-        [raid10_format   near]
+        [raid10_format   <near|far|offset>]
                 These two options are used to alter the default layout of
                 a RAID10 configuration.  The number of copies is can be
-                specified, but the default is 2.  There are other variations
-                to how the copies are laid down - the default and only current
-                option is "near".  Near copies are what most people think of
-                with respect to mirroring.  If these options are left
-                unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
-                are given, then the layouts for 2, 3 and 4 devices are:
+                specified, but the default is 2.  There are also three
+                variations to how the copies are laid down - the default
+                is "near".  Near copies are what most people think of with
+                respect to mirroring.  If these options are left unspecified,
+                or 'raid10_copies 2' and/or 'raid10_format near' are given,
+                then the layouts for 2, 3 and 4 devices are:
                 2 drives         3 drives          4 drives
                 --------         ----------        --------------
                 A1  A1           A1  A1  A2        A1  A1  A2  A2
@@ -85,6 +89,33 @@ The target is named "raid" and it accepts the following parameters:
                 3-device layout is what might be called a 'RAID1E - Integrated
                 Adjacent Stripe Mirroring'.
 
+                If 'raid10_copies 2' and 'raid10_format far', then the layouts
+                for 2, 3 and 4 devices are:
+                2 drives             3 drives             4 drives
+                --------             --------------       --------------------
+                A1  A2               A1   A2   A3         A1   A2   A3   A4
+                A3  A4               A4   A5   A6         A5   A6   A7   A8
+                A5  A6               A7   A8   A9         A9   A10  A11  A12
+                ..  ..               ..   ..   ..         ..   ..   ..   ..
+                A2  A1               A3   A1   A2         A2   A1   A4   A3
+                A4  A3               A6   A4   A5         A6   A5   A8   A7
+                A6  A5               A9   A7   A8         A10  A9   A12  A11
+                ..  ..               ..   ..   ..         ..   ..   ..   ..
+
+                If 'raid10_copies 2' and 'raid10_format offset', then the
+                layouts for 2, 3 and 4 devices are:
+                2 drives       3 drives           4 drives
+                --------       ------------       -----------------
+                A1  A2         A1  A2  A3         A1  A2  A3  A4
+                A2  A1         A3  A1  A2         A2  A1  A4  A3
+                A3  A4         A4  A5  A6         A5  A6  A7  A8
+                A4  A3         A6  A4  A5         A6  A5  A8  A7
+                A5  A6         A7  A8  A9         A9  A10 A11 A12
+                A6  A5         A9  A7  A8         A10 A9  A12 A11
+                ..  ..         ..  ..  ..         ..  ..  ..  ..
+                Here we see layouts closely akin to 'RAID1E - Integrated
+                Offset Stripe Mirroring'.
+
 <#raid_devs>: The number of devices composing the array.
         Each device consists of two entries.  The first is the device
         containing the metadata (if any); the second is the one containing the
@@ -94,7 +125,7 @@ The target is named "raid" and it accepts the following parameters:
         given for both the metadata and data drives for a given position.
 
 
-Example tables
+Example Tables
 --------------
 # RAID4 - 4 data drives, 1 parity (no metadata devices)
 # No metadata devices specified to hold superblock/bitmap info
@@ -113,26 +144,70 @@ Example tables
         raid4 4 2048 sync min_recovery_rate 20 \
         5 8:17 8:18 8:33 8:34 8:49 8:50 8:65 8:66 8:81 8:82
 
+
+Status Output
+-------------
 'dmsetup table' displays the table used to construct the mapping.
 The optional parameters are always printed in the order listed
 above with "sync" or "nosync" always output ahead of the other
 arguments, regardless of the order used when originally loading the table.
 Arguments that can be repeated are ordered by value.
 
-'dmsetup status' yields information on the state and health of the
-array.
-The output is as follows:
+
+'dmsetup status' yields information on the state and health of the array.
+The output is as follows (normally a single line, but expanded here for
+clarity):
 1: <s> <l> raid \
-2:      <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
+2:      <raid_type> <#devices> <health_chars> \
+3:      <sync_ratio> <sync_action> <mismatch_cnt>
 
 Line 1 is the standard output produced by device-mapper.
-Line 2 is produced by the raid target, and best explained by example:
-        0 1960893648 raid raid4 5 AAAAA 2/490221568
+Line 2 & 3 are produced by the raid target and are best explained by example:
+        0 1960893648 raid raid4 5 AAAAA 2/490221568 init 0
 Here we can see the RAID type is raid4, there are 5 devices - all of
-which are 'A'live, and the array is 2/490221568 complete with recovery.
-Faulty or missing devices are marked 'D'.  Devices that are out-of-sync
-are marked 'a'.
-
+which are 'A'live, and the array is 2/490221568 complete with its initial
+recovery.  Here is a fuller description of the individual fields:
+        <raid_type>     Same as the <raid_type> used to create the array.
+        <health_chars>  One char for each device, indicating: 'A' = alive and
+                        in-sync, 'a' = alive but not in-sync, 'D' = dead/failed.
+        <sync_ratio>    The ratio indicating how much of the array has undergone
+                        the process described by 'sync_action'.  If the
+                        'sync_action' is "check" or "repair", then the process
+                        of "resync" or "recover" can be considered complete.
+        <sync_action>   One of the following possible states:
+                        idle    - No synchronization action is being performed.
+                        frozen  - The current action has been halted.
+                        resync  - Array is undergoing its initial synchronization
+                                  or is resynchronizing after an unclean shutdown
+                                  (possibly aided by a bitmap).
+                        recover - A device in the array is being rebuilt or
+                                  replaced.
+                        check   - A user-initiated full check of the array is
+                                  being performed.  All blocks are read and
+                                  checked for consistency.  The number of
+                                  discrepancies found are recorded in
+                                  <mismatch_cnt>.  No changes are made to the
+                                  array by this action.
+                        repair  - The same as "check", but discrepancies are
+                                  corrected.
+                        reshape - The array is undergoing a reshape.
+        <mismatch_cnt>  The number of discrepancies found between mirror copies
+                        in RAID1/10 or wrong parity values found in RAID4/5/6.
+                        This value is valid only after a "check" of the array
+                        is performed.  A healthy array has a 'mismatch_cnt' of 0.
+
+Message Interface
+-----------------
+The dm-raid target will accept certain actions through the 'message' interface.
+('man dmsetup' for more information on the message interface.)  These actions
+include:
+        "idle"   - Halt the current sync action.
+        "frozen" - Freeze the current sync action.
+        "resync" - Initiate/continue a resync.
+        "recover"- Initiate/continue a recover process.
+        "check"  - Initiate a check (i.e. a "scrub") of the array.
+        "repair" - Initiate a repair of the array.
+        "reshape"- Currently unsupported (-EINVAL).
 
 Version History
 ---------------
@@ -142,3 +217,8 @@ Version History
 1.3.0   Added support for RAID 10
 1.3.1   Allow device replacement/rebuild for RAID 10
 1.3.2   Fix/improve redundancy checking for RAID10
+1.4.0   Non-functional change.  Removes arg from mapping function.
+1.4.1   RAID10 fix redundancy validation checks (commit 55ebbb5).
+1.4.2   Add RAID10 "far" and "offset" algorithm support.
+1.5.0   Add message interface to allow manipulation of the sync_action.
+        New status (STATUSTYPE_INFO) fields: sync_action and mismatch_cnt.
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
new file mode 100644
index 000000000000..2c28f1d12f45
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
@@ -0,0 +1,11 @@
+Altera SOCFPGA Clock Manager
+
+Required properties:
+- compatible : "altr,clk-mgr"
+- reg : Should contain base address and length for Clock Manager
+
+Example:
+         clkmgr@ffd04000 {
+                compatible = "altr,clk-mgr";
+                reg = <0xffd04000 0x1000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
index c63097d6afeb..16769d9cedd6 100644
--- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
@@ -14,9 +14,19 @@ Required properties:
   - atmel,adc-status-register: Offset of the Interrupt Status Register
   - atmel,adc-trigger-register: Offset of the Trigger Register
   - atmel,adc-vref: Reference voltage in millivolts for the conversions
+  - atmel,adc-res: List of resolution in bits supported by the ADC. List size
+                   must be two at least.
+  - atmel,adc-res-names: Contains one identifier string for each resolution
+                         in atmel,adc-res property. "lowres" and "highres"
+                         identifiers are required.
 
 Optional properties:
   - atmel,adc-use-external: Boolean to enable of external triggers
+  - atmel,adc-use-res: String corresponding to an identifier from
+                       atmel,adc-res-names property. If not specified, the highest
+                       resolution will be used.
+  - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
+  - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
  
 Optional trigger Nodes:
   - Required properties:
@@ -40,6 +50,9 @@ adc0: adc@fffb0000 {
         atmel,adc-trigger-register = <0x08>;
         atmel,adc-use-external;
         atmel,adc-vref = <3300>;
+        atmel,adc-res = <8 10>;
+        atmel,adc-res-names = "lowres", "highres";
+        atmel,adc-use-res = "lowres";
 
         trigger@0 {
                 trigger-name = "external-rising";
diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt b/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt
new file mode 100644
index 000000000000..59fa6e68d4f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt
@@ -0,0 +1,19 @@
+Broadcom Kona Family timer
+-----------------------------------------------------
+This timer is used in the following Broadcom SoCs:
+ BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
+
+Required properties:
+- compatible : "bcm,kona-timer"
+- reg : Register range for the timer
+- interrupts : interrupt for the timer
+- clock-frequency: frequency that the clock operates
+
+Example:
+        timer@35006000 {
+                compatible = "bcm,kona-timer";
+                reg = <0x35006000 0x1000>;
+                interrupts = <0x0 7 0x4>;
+                clock-frequency = <32768>;
+        };
+
diff --git a/Documentation/devicetree/bindings/arm/msm/ssbi.txt b/Documentation/devicetree/bindings/arm/msm/ssbi.txt
new file mode 100644
index 000000000000..54fd5ced3401
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/ssbi.txt
@@ -0,0 +1,18 @@
+* Qualcomm SSBI
+
+Some Qualcomm MSM devices contain a point-to-point serial bus used to
+communicate with a limited range of devices (mostly power management
+chips).
+
+These require the following properties:
+
+- compatible: "qcom,ssbi"
+
+- qcom,controller-type
+  indicates the SSBI bus variant the controller should use to talk
+  with the slave device.  This should be one of "ssbi", "ssbi2", or
+  "pmic-arbiter".  The type chosen is determined by the attached
+  slave.
+
+The slave device should be the single child node of the ssbi device
+with a compatible field.
diff --git a/Documentation/devicetree/bindings/arm/msm/timer.txt b/Documentation/devicetree/bindings/arm/msm/timer.txt
index 8c5907b9cae8..c6ef8f13dc7e 100644
--- a/Documentation/devicetree/bindings/arm/msm/timer.txt
+++ b/Documentation/devicetree/bindings/arm/msm/timer.txt
@@ -3,36 +3,35 @@
 Properties:
 
 - compatible : Should at least contain "qcom,msm-timer". More specific
-  properties such as "qcom,msm-gpt" and "qcom,msm-dgt" specify a general
-  purpose timer and a debug timer respectively.
+               properties specify which subsystem the timers are paired with.
 
-- interrupts : Interrupt indicating a match event.
+               "qcom,kpss-timer" - krait subsystem
+               "qcom,scss-timer" - scorpion subsystem
 
-- reg : Specifies the base address of the timer registers. The second region
-  specifies an optional register used to configure the clock divider.
+- interrupts : Interrupts for the the debug timer, the first general purpose
+               timer, and optionally a second general purpose timer in that
+               order.
 
-- clock-frequency : The frequency of the timer in Hz.
+- reg : Specifies the base address of the timer registers.
+
+- clock-frequency : The frequency of the debug timer and the general purpose
+                    timer(s) in Hz in that order.
 
 Optional:
 
 - cpu-offset : per-cpu offset used when the timer is accessed without the
-  CPU remapping facilities. The offset is cpu-offset * cpu-nr.
+               CPU remapping facilities. The offset is
+               cpu-offset + (0x10000 * cpu-nr).
 
 Example:
 
-       timer@200a004 {
-               compatible = "qcom,msm-gpt", "qcom,msm-timer";
-               interrupts = <1 2 0x301>;
-               reg = <0x0200a004 0x10>;
-               clock-frequency = <32768>;
-               cpu-offset = <0x40000>;
-       };
-
-       timer@200a024 {
-               compatible = "qcom,msm-dgt", "qcom,msm-timer";
-               interrupts = <1 3 0x301>;
-               reg = <0x0200a024 0x10>,
-                     <0x0200a034 0x4>;
-               clock-frequency = <6750000>;
+       timer@200a000 {
+               compatible = "qcom,scss-timer", "qcom,msm-timer";
+               interrupts = <1 1 0x301>,
+                            <1 2 0x301>,
+                            <1 3 0x301>;
+               reg = <0x0200a000 0x100>;
+               clock-frequency = <19200000>,
+                                 <32768>;
                cpu-offset = <0x40000>;
        };
diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
index 6888a5efc860..c0105de55cbd 100644
--- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
+++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
@@ -6,6 +6,7 @@ provided by Arteris.
 Required properties:
 - compatible : Should be "ti,omap3-l3-smx" for OMAP3 family
                Should be "ti,omap4-l3-noc" for OMAP4 family
+- reg:  Contains L3 register address range for each noc domain.
 - ti,hwmods: "l3_main_1", ... One hwmod for each noc domain.
 
 Examples:
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
index 8732d4d41f8b..d02e27c764ec 100644
--- a/Documentation/devicetree/bindings/arm/omap/timer.txt
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -1,7 +1,20 @@
 OMAP Timer bindings
 
 Required properties:
-- compatible:           Must be "ti,omap2-timer" for OMAP2+ controllers.
+- compatible:           Should be set to one of the below. Please note that
+                        OMAP44xx devices have timer instances that are 100%
+                        register compatible with OMAP3xxx devices as well as
+                        newer timers that are not 100% register compatible.
+                        So for OMAP44xx devices timer instances may use
+                        different compatible strings.
+
+                        ti,omap2420-timer (applicable to OMAP24xx devices)
+                        ti,omap3430-timer (applicable to OMAP3xxx/44xx devices)
+                        ti,omap4430-timer (applicable to OMAP44xx devices)
+                        ti,omap5430-timer (applicable to OMAP543x devices)
+                        ti,am335x-timer (applicable to AM335x devices)
+                        ti,am335x-timer-1ms (applicable to AM335x devices)
+
 - reg:                  Contains timer register address range (base address and
                         length).
 - interrupts:           Contains the interrupt information for the timer. The
@@ -22,7 +35,7 @@ Optional properties:
 Example:
 
 timer12: timer@48304000 {
-        compatible = "ti,omap2-timer";
+        compatible = "ti,omap3430-timer";
         reg = <0x48304000 0x400>;
         interrupts = <95>;
         ti,hwmods = "timer12"
diff --git a/Documentation/devicetree/bindings/arm/primecell.txt b/Documentation/devicetree/bindings/arm/primecell.txt
index 64fc82bc8928..0df6acacfaea 100644
--- a/Documentation/devicetree/bindings/arm/primecell.txt
+++ b/Documentation/devicetree/bindings/arm/primecell.txt
@@ -16,14 +16,31 @@ Optional properties:
 - clocks : From common clock binding. First clock is phandle to clock for apb
         pclk. Additional clocks are optional and specific to those peripherals.
 - clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
+- dmas : From common DMA binding. If present, refers to one or more dma channels.
+- dma-names : From common DMA binding, needs to match the 'dmas' property.
+              Devices with exactly one receive and transmit channel shall name
+              these "rx" and "tx", respectively.
+- pinctrl-<n> : Pinctrl states as described in bindings/pinctrl/pinctrl-bindings.txt
+- pinctrl-names : Names corresponding to the numbered pinctrl states
+- interrupts : one or more interrupt specifiers
+- interrupt-names : names corresponding to the interrupts properties
 
 Example:
 
 serial@fff36000 {
         compatible = "arm,pl011", "arm,primecell";
         arm,primecell-periphid = <0x00341011>;
+
         clocks = <&pclk>;
         clock-names = "apb_pclk";
-        
+
+        dmas = <&dma-controller 4>, <&dma-controller 5>;
+        dma-names = "rx", "tx"; 
+
+        pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
+        pinctrl-1 = <&uart0_sleep_mode>;
+        pinctrl-names = "default","sleep";
+
+        interrupts = <0 11 0x4>;
 };
 
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 0bf68be56fd1..2168ed31e1b0 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -6,3 +6,13 @@ Required root node properties:
     - compatible = should be one or more of the following.
         (a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
         (b) "samsung,exynos4210"  - for boards based on Exynos4210 SoC.
+
+Optional:
+    - firmware node, specifying presence and type of secure firmware:
+        - compatible: only "samsung,secure-firmware" is currently supported
+        - reg: address of non-secure SYSRAM used for communication with firmware
+
+        firmware@0203F000 {
+                compatible = "samsung,secure-firmware";
+                reg = <0x0203F000 0x1000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
new file mode 100644
index 000000000000..47ada1dff216
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -0,0 +1,60 @@
+Samsung Exynos Analog to Digital Converter bindings
+
+The devicetree bindings are for the new ADC driver written for
+Exynos4 and upward SoCs from Samsung.
+
+New driver handles the following
+1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
+   and future SoCs from Samsung
+2. Add ADC driver under iio/adc framework
+3. Also adds the Documentation for device tree bindings
+
+Required properties:
+- compatible:           Must be "samsung,exynos-adc-v1"
+                                for exynos4412/5250 controllers.
+                        Must be "samsung,exynos-adc-v2" for
+                                future controllers.
+- reg:                  Contains ADC register address range (base address and
+                        length) and the address of the phy enable register.
+- interrupts:           Contains the interrupt information for the timer. The
+                        format is being dependent on which interrupt controller
+                        the Samsung device uses.
+- #io-channel-cells = <1>; As ADC has multiple outputs
+- clocks                From common clock binding: handle to adc clock.
+- clock-names           From common clock binding: Shall be "adc".
+- vdd-supply            VDD input supply.
+
+Note: child nodes can be added for auto probing from device tree.
+
+Example: adding device info in dtsi file
+
+adc: adc@12D10000 {
+        compatible = "samsung,exynos-adc-v1";
+        reg = <0x12D10000 0x100>, <0x10040718 0x4>;
+        interrupts = <0 106 0>;
+        #io-channel-cells = <1>;
+        io-channel-ranges;
+
+        clocks = <&clock 303>;
+        clock-names = "adc";
+
+        vdd-supply = <&buck5_reg>;
+};
+
+
+Example: Adding child nodes in dts file
+
+adc@12D10000 {
+
+        /* NTC thermistor is a hwmon device */
+        ncp15wb473@0 {
+                compatible = "ntc,ncp15wb473";
+                pullup-uV = <1800000>;
+                pullup-ohm = <47000>;
+                pulldown-ohm = <0>;
+                io-channels = <&adc 4>;
+        };
+};
+
+Note: Does not apply to ADC driver under arch/arm/plat-samsung/
+Note: The child node can be added under the adc node or separately.
diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
new file mode 100644
index 000000000000..5039c0a12f55
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
@@ -0,0 +1,7 @@
+SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
+
+Properties:
+ - name : should be 'sysreg';
+ - compatible : should contain "samsung,<chip name>-sysreg", "syscon";
+   For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
+ - reg : offset and length of the register set.
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
index b5846e21cc2e..1608a54e90e1 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
@@ -1,19 +1,84 @@
 NVIDIA Tegra Power Management Controller (PMC)
 
-Properties:
+The PMC block interacts with an external Power Management Unit. The PMC
+mostly controls the entry and exit of the system from different sleep
+modes. It provides power-gating controllers for SoC and CPU power-islands.
+
+Required properties:
 - name : Should be pmc
 - compatible : Should contain "nvidia,tegra<chip>-pmc".
 - reg : Offset and length of the register set for the device
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+  "pclk" (The Tegra clock of that name),
+  "clk32k_in" (The 32KHz clock input to Tegra).
+
+Optional properties:
 - nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
   The PMU is an external Power Management Unit, whose interrupt output
   signal is fed into the PMC. This signal is optionally inverted, and then
   fed into the ARM GIC. The PMC is not involved in the detection or
   handling of this interrupt signal, merely its inversion.
+- nvidia,suspend-mode : The suspend mode that the platform should use.
+  Valid values are 0, 1 and 2:
+  0 (LP0): CPU + Core voltage off and DRAM in self-refresh
+  1 (LP1): CPU voltage off and DRAM in self-refresh
+  2 (LP2): CPU voltage off
+- nvidia,core-power-req-active-high : Boolean, core power request active-high
+- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high
+- nvidia,combined-power-req : Boolean, combined power request for CPU & Core
+- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
+                           is enabled.
+
+Required properties when nvidia,suspend-mode is specified:
+- nvidia,cpu-pwr-good-time : CPU power good time in uS.
+- nvidia,cpu-pwr-off-time : CPU power off time in uS.
+- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
+                              Core power good time in uS.
+- nvidia,core-pwr-off-time : Core power off time in uS.
+
+Required properties when nvidia,suspend-mode=<0>:
+- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector
+  The LP0 vector contains the warm boot code that is executed by AVP when
+  resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7
+  processor and always being the first boot processor when chip is power on
+  or resume from deep sleep mode. When the system is resumed from the deep
+  sleep mode, the warm boot code will restore some PLLs, clocks and then
+  bring up CPU0 for resuming the system.
 
 Example:
 
+/ SoC dts including file
 pmc@7000f400 {
         compatible = "nvidia,tegra20-pmc";
         reg = <0x7000e400 0x400>;
+        clocks = <&tegra_car 110>, <&clk32k_in>;
+        clock-names = "pclk", "clk32k_in";
         nvidia,invert-interrupt;
+        nvidia,suspend-mode = <1>;
+        nvidia,cpu-pwr-good-time = <2000>;
+        nvidia,cpu-pwr-off-time = <100>;
+        nvidia,core-pwr-good-time = <3845 3845>;
+        nvidia,core-pwr-off-time = <458>;
+        nvidia,core-power-req-active-high;
+        nvidia,sys-clock-req-active-high;
+        nvidia,lp0-vec = <0xbdffd000 0x2000>;
+};
+
+/ Tegra board dts file
+{
+        ...
+        clocks {
+                compatible = "simple-bus";
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                clk32k_in: clock {
+                        compatible = "fixed-clock";
+                        reg=<0>;
+                        #clock-cells = <0>;
+                        clock-frequency = <32768>;
+                };
+        };
+        ...
 };
diff --git a/Documentation/devicetree/bindings/ata/imx-pata.txt b/Documentation/devicetree/bindings/ata/imx-pata.txt
new file mode 100644
index 000000000000..e38d73414b0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/imx-pata.txt
@@ -0,0 +1,17 @@
+* Freescale i.MX PATA Controller
+
+Required properties:
+- compatible: "fsl,imx27-pata"
+- reg: Address range of the PATA Controller
+- interrupts: The interrupt of the PATA Controller
+- clocks: the clocks for the PATA Controller
+
+Example:
+
+        pata: pata@83fe0000 {
+                compatible = "fsl,imx51-pata", "fsl,imx27-pata";
+                reg = <0x83fe0000 0x4000>;
+                interrupts = <70>;
+                clocks = <&clks 161>;
+                status = "disabled";
+        };
diff --git a/Documentation/devicetree/bindings/ata/pata-arasan.txt b/Documentation/devicetree/bindings/ata/pata-arasan.txt
index 95ec7f825ede..2aff154be84e 100644
--- a/Documentation/devicetree/bindings/ata/pata-arasan.txt
+++ b/Documentation/devicetree/bindings/ata/pata-arasan.txt
@@ -6,6 +6,26 @@ Required properties:
 - interrupt-parent: Should be the phandle for the interrupt controller
   that services interrupts for this device
 - interrupt: Should contain the CF interrupt number
+- clock-frequency: Interface clock rate, in Hz, one of
+       25000000
+       33000000
+       40000000
+       50000000
+       66000000
+       75000000
+      100000000
+      125000000
+      150000000
+      166000000
+      200000000
+
+Optional properties:
+- arasan,broken-udma: if present, UDMA mode is unusable
+- arasan,broken-mwdma: if present, MWDMA mode is unusable
+- arasan,broken-pio: if present, PIO mode is unusable
+- dmas: one DMA channel, as described in bindings/dma/dma.txt
+  required unless both UDMA and MWDMA mode are broken
+- dma-names: the corresponding channel name, must be "data"
 
 Example:
 
@@ -14,4 +34,6 @@ Example:
                 reg = <0xfc000000 0x1000>;
                 interrupt-parent = <&vic1>;
                 interrupts = <12>;
+                dmas = <&dma-controller 23>;
+                dma-names = "data";
         };
diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
new file mode 100644
index 000000000000..bd0c8416a5c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
@@ -0,0 +1,18 @@
+Device Tree Clock bindings for Altera's SoCFPGA platform
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of the following:
+        "altr,socfpga-pll-clock" - for a PLL clock
+        "altr,socfpga-perip-clock" - The peripheral clock divided from the
+                PLL clock.
+- reg : shall be the control register offset from CLOCK_MANAGER's base for the clock.
+- clocks : shall be the input parent clock phandle for the clock. This is
+        either an oscillator or a pll output.
+- #clock-cells : from common clock binding, shall be set to 0.
+
+Optional properties:
+- fixed-divider : If clocks have a fixed divider value, use this property.
diff --git a/Documentation/devicetree/bindings/clock/axi-clkgen.txt b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
new file mode 100644
index 000000000000..028b493e97ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
@@ -0,0 +1,22 @@
+Binding for the axi-clkgen clock generator
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "adi,axi-clkgen".
+- #clock-cells : from common clock binding; Should always be set to 0.
+- reg : Address and length of the axi-clkgen register set.
+- clocks : Phandle and clock specifier for the parent clock.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+        clock@0xff000000 {
+                compatible = "adi,axi-clkgen";
+                #clock-cells = <0>;
+                reg = <0xff000000 0x1000>;
+                clocks = <&osc 1>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
new file mode 100644
index 000000000000..ea5e26f16aec
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
@@ -0,0 +1,288 @@
+* Samsung Exynos4 Clock Controller
+
+The Exynos4 clock controller generates and supplies clock to various controllers
+within the Exynos4 SoC. The clock binding described here is applicable to all
+SoC's in the Exynos4 family.
+
+Required Properties:
+
+- comptible: should be one of the following.
+  - "samsung,exynos4210-clock" - controller compatible with Exynos4210 SoC.
+  - "samsung,exynos4412-clock" - controller compatible with Exynos4412 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume. Some of the clocks are available only on a particular
+Exynos4 SoC and this is specified where applicable.
+
+
+                 [Core Clocks]
+
+  Clock               ID      SoC (if specific)
+  -----------------------------------------------
+
+  xxti                1
+  xusbxti             2
+  fin_pll             3
+  fout_apll           4
+  fout_mpll           5
+  fout_epll           6
+  fout_vpll           7
+  sclk_apll           8
+  sclk_mpll           9
+  sclk_epll           10
+  sclk_vpll           11
+  arm_clk             12
+  aclk200             13
+  aclk100             14
+  aclk160             15
+  aclk133             16
+  mout_mpll_user_t    17      Exynos4x12
+  mout_mpll_user_c    18      Exynos4x12
+  mout_core           19
+  mout_apll           20
+
+
+            [Clock Gate for Special Clocks]
+
+  Clock               ID      SoC (if specific)
+  -----------------------------------------------
+
+  sclk_fimc0          128
+  sclk_fimc1          129
+  sclk_fimc2          130
+  sclk_fimc3          131
+  sclk_cam0           132
+  sclk_cam1           133
+  sclk_csis0          134
+  sclk_csis1          135
+  sclk_hdmi           136
+  sclk_mixer          137
+  sclk_dac            138
+  sclk_pixel          139
+  sclk_fimd0          140
+  sclk_mdnie0         141     Exynos4412
+  sclk_mdnie_pwm0 12  142     Exynos4412
+  sclk_mipi0          143
+  sclk_audio0         144
+  sclk_mmc0           145
+  sclk_mmc1           146
+  sclk_mmc2           147
+  sclk_mmc3           148
+  sclk_mmc4           149
+  sclk_sata           150     Exynos4210
+  sclk_uart0          151
+  sclk_uart1          152
+  sclk_uart2          153
+  sclk_uart3          154
+  sclk_uart4          155
+  sclk_audio1         156
+  sclk_audio2         157
+  sclk_spdif          158
+  sclk_spi0           159
+  sclk_spi1           160
+  sclk_spi2           161
+  sclk_slimbus        162
+  sclk_fimd1          163     Exynos4210
+  sclk_mipi1          164     Exynos4210
+  sclk_pcm1           165
+  sclk_pcm2           166
+  sclk_i2s1           167
+  sclk_i2s2           168
+  sclk_mipihsi        169     Exynos4412
+  sclk_mfc            170
+  sclk_pcm0           171
+  sclk_g3d            172
+  sclk_pwm_isp        173     Exynos4x12
+  sclk_spi0_isp       174     Exynos4x12
+  sclk_spi1_isp       175     Exynos4x12
+  sclk_uart_isp       176     Exynos4x12
+
+              [Peripheral Clock Gates]
+
+  Clock               ID      SoC (if specific)
+  -----------------------------------------------
+
+  fimc0               256
+  fimc1               257
+  fimc2               258
+  fimc3               259
+  csis0               260
+  csis1               261
+  jpeg                262
+  smmu_fimc0          263
+  smmu_fimc1          264
+  smmu_fimc2          265
+  smmu_fimc3          266
+  smmu_jpeg           267
+  vp                  268
+  mixer               269
+  tvenc               270     Exynos4210
+  hdmi                271
+  smmu_tv             272
+  mfc                 273
+  smmu_mfcl           274
+  smmu_mfcr           275
+  g3d                 276
+  g2d                 277     Exynos4210
+  rotator             278     Exynos4210
+  mdma                279     Exynos4210
+  smmu_g2d            280     Exynos4210
+  smmu_rotator        281     Exynos4210
+  smmu_mdma           282     Exynos4210
+  fimd0               283
+  mie0                284
+  mdnie0              285     Exynos4412
+  dsim0               286
+  smmu_fimd0          287
+  fimd1               288     Exynos4210
+  mie1                289     Exynos4210
+  dsim1               290     Exynos4210
+  smmu_fimd1          291     Exynos4210
+  pdma0               292
+  pdma1               293
+  pcie_phy            294
+  sata_phy            295     Exynos4210
+  tsi                 296
+  sdmmc0              297
+  sdmmc1              298
+  sdmmc2              299
+  sdmmc3              300
+  sdmmc4              301
+  sata                302     Exynos4210
+  sromc               303
+  usb_host            304
+  usb_device          305
+  pcie                306
+  onenand             307
+  nfcon               308
+  smmu_pcie           309
+  gps                 310
+  smmu_gps            311
+  uart0               312
+  uart1               313
+  uart2               314
+  uart3               315
+  uart4               316
+  i2c0                317
+  i2c1                318
+  i2c2                319
+  i2c3                320
+  i2c4                321
+  i2c5                322
+  i2c6                323
+  i2c7                324
+  i2c_hdmi            325
+  tsadc               326
+  spi0                327
+  spi1                328
+  spi2                329
+  i2s1                330
+  i2s2                331
+  pcm0                332
+  i2s0                333
+  pcm1                334
+  pcm2                335
+  pwm                 336
+  slimbus             337
+  spdif               338
+  ac97                339
+  modemif             340
+  chipid              341
+  sysreg              342
+  hdmi_cec            343
+  mct                 344
+  wdt                 345
+  rtc                 346
+  keyif               347
+  audss               348
+  mipi_hsi            349     Exynos4210
+  mdma2               350     Exynos4210
+  pixelasyncm0        351
+  pixelasyncm1        352
+  fimc_lite0          353     Exynos4x12
+  fimc_lite1          354     Exynos4x12
+  ppmuispx            355     Exynos4x12
+  ppmuispmx           356     Exynos4x12
+  fimc_isp            357     Exynos4x12
+  fimc_drc            358     Exynos4x12
+  fimc_fd             359     Exynos4x12
+  mcuisp              360     Exynos4x12
+  gicisp              361     Exynos4x12
+  smmu_isp            362     Exynos4x12
+  smmu_drc            363     Exynos4x12
+  smmu_fd             364     Exynos4x12
+  smmu_lite0          365     Exynos4x12
+  smmu_lite1          366     Exynos4x12
+  mcuctl_isp          367     Exynos4x12
+  mpwm_isp            368     Exynos4x12
+  i2c0_isp            369     Exynos4x12
+  i2c1_isp            370     Exynos4x12
+  mtcadc_isp          371     Exynos4x12
+  pwm_isp             372     Exynos4x12
+  wdt_isp             373     Exynos4x12
+  uart_isp            374     Exynos4x12
+  asyncaxim           375     Exynos4x12
+  smmu_ispcx          376     Exynos4x12
+  spi0_isp            377     Exynos4x12
+  spi1_isp            378     Exynos4x12
+  pwm_isp_sclk        379     Exynos4x12
+  spi0_isp_sclk       380     Exynos4x12
+  spi1_isp_sclk       381     Exynos4x12
+  uart_isp_sclk       382     Exynos4x12
+
+                [Mux Clocks]
+
+  Clock                 ID      SoC (if specific)
+  -----------------------------------------------
+
+  mout_fimc0            384
+  mout_fimc1            385
+  mout_fimc2            386
+  mout_fimc3            387
+  mout_cam0             388
+  mout_cam1             389
+  mout_csis0            390
+  mout_csis1            391
+  mout_g3d0             392
+  mout_g3d1             393
+  mout_g3d              394
+  aclk400_mcuisp        395     Exynos4x12
+
+                [Div Clocks]
+
+  Clock                 ID      SoC (if specific)
+  -----------------------------------------------
+
+  div_isp0              450     Exynos4x12
+  div_isp1              451     Exynos4x12
+  div_mcuisp0           452     Exynos4x12
+  div_mcuisp1           453     Exynos4x12
+  div_aclk200           454     Exynos4x12
+  div_aclk400_mcuisp    455     Exynos4x12
+
+
+Example 1: An example of a clock controller node is listed below.
+
+        clock: clock-controller@0x10030000 {
+                compatible = "samsung,exynos4210-clock";
+                reg = <0x10030000 0x20000>;
+                #clock-cells = <1>;
+        };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+           controller. Refer to the standard clock bindings for information
+           about 'clocks' and 'clock-names' property.
+
+        serial@13820000 {
+                compatible = "samsung,exynos4210-uart";
+                reg = <0x13820000 0x100>;
+                interrupts = <0 54 0>;
+                clocks = <&clock 314>, <&clock 153>;
+                clock-names = "uart", "clk_uart_baud0";
+        };
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
new file mode 100644
index 000000000000..781a6276adf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -0,0 +1,177 @@
+* Samsung Exynos5250 Clock Controller
+
+The Exynos5250 clock controller generates and supplies clock to various
+controllers within the Exynos5250 SoC.
+
+Required Properties:
+
+- comptible: should be one of the following.
+  - "samsung,exynos5250-clock" - controller compatible with Exynos5250 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume.
+
+
+       [Core Clocks]
+
+  Clock                 ID
+  ----------------------------
+
+  fin_pll               1
+
+  [Clock Gate for Special Clocks]
+
+  Clock                 ID
+  ----------------------------
+
+  sclk_cam_bayer        128
+  sclk_cam0             129
+  sclk_cam1             130
+  sclk_gscl_wa          131
+  sclk_gscl_wb          132
+  sclk_fimd1            133
+  sclk_mipi1            134
+  sclk_dp               135
+  sclk_hdmi             136
+  sclk_pixel            137
+  sclk_audio0           138
+  sclk_mmc0             139
+  sclk_mmc1             140
+  sclk_mmc2             141
+  sclk_mmc3             142
+  sclk_sata             143
+  sclk_usb3             144
+  sclk_jpeg             145
+  sclk_uart0            146
+  sclk_uart1            147
+  sclk_uart2            148
+  sclk_uart3            149
+  sclk_pwm              150
+  sclk_audio1           151
+  sclk_audio2           152
+  sclk_spdif            153
+  sclk_spi0             154
+  sclk_spi1             155
+  sclk_spi2             156
+
+
+   [Peripheral Clock Gates]
+
+  Clock                 ID
+  ----------------------------
+
+  gscl0                 256
+  gscl1                 257
+  gscl2                 258
+  gscl3                 259
+  gscl_wa               260
+  gscl_wb               261
+  smmu_gscl0            262
+  smmu_gscl1            263
+  smmu_gscl2            264
+  smmu_gscl3            265
+  mfc                   266
+  smmu_mfcl             267
+  smmu_mfcr             268
+  rotator               269
+  jpeg                  270
+  mdma1                 271
+  smmu_rotator          272
+  smmu_jpeg             273
+  smmu_mdma1            274
+  pdma0                 275
+  pdma1                 276
+  sata                  277
+  usbotg                278
+  mipi_hsi              279
+  sdmmc0                280
+  sdmmc1                281
+  sdmmc2                282
+  sdmmc3                283
+  sromc                 284
+  usb2                  285
+  usb3                  286
+  sata_phyctrl          287
+  sata_phyi2c           288
+  uart0                 289
+  uart1                 290
+  uart2                 291
+  uart3                 292
+  uart4                 293
+  i2c0                  294
+  i2c1                  295
+  i2c2                  296
+  i2c3                  297
+  i2c4                  298
+  i2c5                  299
+  i2c6                  300
+  i2c7                  301
+  i2c_hdmi              302
+  adc                   303
+  spi0                  304
+  spi1                  305
+  spi2                  306
+  i2s1                  307
+  i2s2                  308
+  pcm1                  309
+  pcm2                  310
+  pwm                   311
+  spdif                 312
+  ac97                  313
+  hsi2c0                314
+  hsi2c1                315
+  hs12c2                316
+  hs12c3                317
+  chipid                318
+  sysreg                319
+  pmu                   320
+  cmu_top               321
+  cmu_core              322
+  cmu_mem               323
+  tzpc0                 324
+  tzpc1                 325
+  tzpc2                 326
+  tzpc3                 327
+  tzpc4                 328
+  tzpc5                 329
+  tzpc6                 330
+  tzpc7                 331
+  tzpc8                 332
+  tzpc9                 333
+  hdmi_cec              334
+  mct                   335
+  wdt                   336
+  rtc                   337
+  tmu                   338
+  fimd1                 339
+  mie1                  340
+  dsim0                 341
+  dp                    342
+  mixer                 343
+  hdmi                  345
+
+Example 1: An example of a clock controller node is listed below.
+
+        clock: clock-controller@0x10010000 {
+                compatible = "samsung,exynos5250-clock";
+                reg = <0x10010000 0x30000>;
+                #clock-cells = <1>;
+        };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+           controller. Refer to the standard clock bindings for information
+           about 'clocks' and 'clock-names' property.
+
+        serial@13820000 {
+                compatible = "samsung,exynos4210-uart";
+                reg = <0x13820000 0x100>;
+                interrupts = <0 54 0>;
+                clocks = <&clock 314>, <&clock 153>;
+                clock-names = "uart", "clk_uart_baud0";
+        };
diff --git a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
new file mode 100644
index 000000000000..4499e9966bc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
@@ -0,0 +1,61 @@
+* Samsung Exynos5440 Clock Controller
+
+The Exynos5440 clock controller generates and supplies clock to various
+controllers within the Exynos5440 SoC.
+
+Required Properties:
+
+- comptible: should be "samsung,exynos5440-clock".
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume.
+
+
+       [Core Clocks]
+
+  Clock                 ID
+  ----------------------------
+
+  xtal                  1
+  arm_clk               2
+
+   [Peripheral Clock Gates]
+
+  Clock                 ID
+  ----------------------------
+
+  spi_baud              16
+  pb0_250               17
+  pr0_250               18
+  pr1_250               19
+  b_250                 20
+  b_125                 21
+  b_200                 22
+  sata                  23
+  usb                   24
+  gmac0                 25
+  cs250                 26
+  pb0_250_o             27
+  pr0_250_o             28
+  pr1_250_o             29
+  b_250_o               30
+  b_125_o               31
+  b_200_o               32
+  sata_o                33
+  usb_o                 34
+  gmac0_o               35
+  cs250_o               36
+
+Example: An example of a clock controller node is listed below.
+
+        clock: clock-controller@0x10010000 {
+                compatible = "samsung,exynos5440-clock";
+                reg = <0x160000 0x10000>;
+                #clock-cells = <1>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
new file mode 100644
index 000000000000..5757f9abfc26
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
@@ -0,0 +1,24 @@
+Binding for simple fixed factor rate clock sources.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "fixed-factor-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clock-div: fixed divider.
+- clock-mult: fixed multiplier.
+- clocks: parent clock.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+        clock {
+                compatible = "fixed-factor-clock";
+                clocks = <&parentclk>;
+                #clock-cells = <0>;
+                div = <2>;
+                mult = <1>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt
new file mode 100644
index 000000000000..ab1a56e9de9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx27-clock.txt
@@ -0,0 +1,117 @@
+* Clock bindings for Freescale i.MX27
+
+Required properties:
+- compatible: Should be "fsl,imx27-ccm"
+- reg: Address and length of the register set
+- interrupts: Should contain CCM interrupt
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell.  The following is a full list of i.MX27
+clocks and IDs.
+
+        Clock               ID
+        -----------------------
+        dummy                0
+        ckih                 1
+        ckil                 2
+        mpll                 3
+        spll                 4
+        mpll_main2           5
+        ahb                  6
+        ipg                  7
+        nfc_div              8
+        per1_div             9
+        per2_div             10
+        per3_div             11
+        per4_div             12
+        vpu_sel              13
+        vpu_div              14
+        usb_div              15
+        cpu_sel              16
+        clko_sel             17
+        cpu_div              18
+        clko_div             19
+        ssi1_sel             20
+        ssi2_sel             21
+        ssi1_div             22
+        ssi2_div             23
+        clko_en              24
+        ssi2_ipg_gate        25
+        ssi1_ipg_gate        26
+        slcdc_ipg_gate       27
+        sdhc3_ipg_gate       28
+        sdhc2_ipg_gate       29
+        sdhc1_ipg_gate       30
+        scc_ipg_gate         31
+        sahara_ipg_gate      32
+        rtc_ipg_gate         33
+        pwm_ipg_gate         34
+        owire_ipg_gate       35
+        lcdc_ipg_gate        36
+        kpp_ipg_gate         37
+        iim_ipg_gate         38
+        i2c2_ipg_gate        39
+        i2c1_ipg_gate        40
+        gpt6_ipg_gate        41
+        gpt5_ipg_gate        42
+        gpt4_ipg_gate        43
+        gpt3_ipg_gate        44
+        gpt2_ipg_gate        45
+        gpt1_ipg_gate        46
+        gpio_ipg_gate        47
+        fec_ipg_gate         48
+        emma_ipg_gate        49
+        dma_ipg_gate         50
+        cspi3_ipg_gate       51
+        cspi2_ipg_gate       52
+        cspi1_ipg_gate       53
+        nfc_baud_gate        54
+        ssi2_baud_gate       55
+        ssi1_baud_gate       56
+        vpu_baud_gate        57
+        per4_gate            58
+        per3_gate            59
+        per2_gate            60
+        per1_gate            61
+        usb_ahb_gate         62
+        slcdc_ahb_gate       63
+        sahara_ahb_gate      64
+        lcdc_ahb_gate        65
+        vpu_ahb_gate         66
+        fec_ahb_gate         67
+        emma_ahb_gate        68
+        emi_ahb_gate         69
+        dma_ahb_gate         70
+        csi_ahb_gate         71
+        brom_ahb_gate        72
+        ata_ahb_gate         73
+        wdog_ipg_gate        74
+        usb_ipg_gate         75
+        uart6_ipg_gate       76
+        uart5_ipg_gate       77
+        uart4_ipg_gate       78
+        uart3_ipg_gate       79
+        uart2_ipg_gate       80
+        uart1_ipg_gate       81
+        ckih_div1p5          82
+        fpm                  83
+        mpll_osc_sel         84
+        mpll_sel             85
+
+Examples:
+
+clks: ccm@10027000{
+        compatible = "fsl,imx27-ccm";
+        reg = <0x10027000 0x1000>;
+        #clock-cells = <1>;
+};
+
+uart1: serial@1000a000 {
+        compatible = "fsl,imx27-uart", "fsl,imx21-uart";
+        reg = <0x1000a000 0x1000>;
+        interrupts = <20>;
+        clocks = <&clks 81>, <&clks 61>;
+        clock-names = "ipg", "per";
+        status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt
index 2a0c904c46ae..d71b4b2c077d 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt
@@ -38,7 +38,6 @@ clocks and IDs.
         usb_phy_podf            23
         cpu_podf                24
         di_pred                 25
-        tve_di                  26
         tve_s                   27
         uart1_ipg_gate          28
         uart1_per_gate          29
@@ -172,6 +171,19 @@ clocks and IDs.
         can1_serial_gate        157
         can1_ipg_gate           158
         owire_gate              159
+        gpu3d_s                 160
+        gpu2d_s                 161
+        gpu3d_gate              162
+        gpu2d_gate              163
+        garb_gate               164
+        cko1_sel                165
+        cko1_podf               166
+        cko1                    167
+        cko2_sel                168
+        cko2_podf               169
+        cko2                    170
+        srtc_gate               171
+        pata_gate               172
 
 Examples (for mx53):
 
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 969b38e06ad3..6deb6fd1c7cd 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -205,6 +205,9 @@ clocks and IDs.
         enet_ref                190
         usbphy1_gate            191
         usbphy2_gate            192
+        pll4_post_div           193
+        pll5_post_div           194
+        pll5_video_div          195
 
 Examples:
 
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
new file mode 100644
index 000000000000..d6cb083b90a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
@@ -0,0 +1,303 @@
+NVIDIA Tegra114 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,tegra114-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- #clock-cells : Should be 1.
+  In clock consumers, this cell represents the clock ID exposed by the CAR.
+
+  The first 160 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+  registers. These IDs often match those in the CAR's RST_DEVICES registers,
+  but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
+  this case, those clocks are assigned IDs above 160 in order to highlight
+  this issue. Implementations that interpret these clock IDs as bit values
+  within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
+  explicitly handle these special cases.
+
+  The balance of the clocks controlled by the CAR are assigned IDs of 160 and
+  above.
+
+  0     unassigned
+  1     unassigned
+  2     unassigned
+  3     unassigned
+  4     rtc
+  5     timer
+  6     uarta
+  7     unassigned      (register bit affects uartb and vfir)
+  8     unassigned
+  9     sdmmc2
+  10    unassigned      (register bit affects spdif_in and spdif_out)
+  11    i2s1
+  12    i2c1
+  13    ndflash
+  14    sdmmc1
+  15    sdmmc4
+  16    unassigned
+  17    pwm
+  18    i2s2
+  19    epp
+  20    unassigned      (register bit affects vi and vi_sensor)
+  21    2d
+  22    usbd
+  23    isp
+  24    3d
+  25    unassigned
+  26    disp2
+  27    disp1
+  28    host1x
+  29    vcp
+  30    i2s0
+  31    unassigned
+
+  32    unassigned
+  33    unassigned
+  34    apbdma
+  35    unassigned
+  36    kbc
+  37    unassigned
+  38    unassigned
+  39    unassigned      (register bit affects fuse and fuse_burn)
+  40    kfuse
+  41    sbc1
+  42    nor
+  43    unassigned
+  44    sbc2
+  45    unassigned
+  46    sbc3
+  47    i2c5
+  48    dsia
+  49    unassigned
+  50    mipi
+  51    hdmi
+  52    csi
+  53    unassigned
+  54    i2c2
+  55    uartc
+  56    mipi-cal
+  57    emc
+  58    usb2
+  59    usb3
+  60    msenc
+  61    vde
+  62    bsea
+  63    bsev
+
+  64    unassigned
+  65    uartd
+  66    unassigned
+  67    i2c3
+  68    sbc4
+  69    sdmmc3
+  70    unassigned
+  71    owr
+  72    afi
+  73    csite
+  74    unassigned
+  75    unassigned
+  76    la
+  77    trace
+  78    soc_therm
+  79    dtv
+  80    ndspeed
+  81    i2cslow
+  82    dsib
+  83    tsec
+  84    unassigned
+  85    unassigned
+  86    unassigned
+  87    unassigned
+  88    unassigned
+  89    xusb_host
+  90    unassigned
+  91    msenc
+  92    csus
+  93    unassigned
+  94    unassigned
+  95    unassigned      (bit affects xusb_dev and xusb_dev_src)
+
+  96    unassigned
+  97    unassigned
+  98    unassigned
+  99    mselect
+  100   tsensor
+  101   i2s3
+  102   i2s4
+  103   i2c4
+  104   sbc5
+  105   sbc6
+  106   d_audio
+  107   apbif
+  108   dam0
+  109   dam1
+  110   dam2
+  111   hda2codec_2x
+  112   unassigned
+  113   audio0_2x
+  114   audio1_2x
+  115   audio2_2x
+  116   audio3_2x
+  117   audio4_2x
+  118   spdif_2x
+  119   actmon
+  120   extern1
+  121   extern2
+  122   extern3
+  123   unassigned
+  124   unassigned
+  125   hda
+  126   unassigned
+  127   se
+
+  128   hda2hdmi
+  129   unassigned
+  130   unassigned
+  131   unassigned
+  132   unassigned
+  133   unassigned
+  134   unassigned
+  135   unassigned
+  136   unassigned
+  137   unassigned
+  138   unassigned
+  139   unassigned
+  140   unassigned
+  141   unassigned
+  142   unassigned
+  143   unassigned      (bit affects xusb_falcon_src, xusb_fs_src,
+                         xusb_host_src and xusb_ss_src)
+  144   cilab
+  145   cilcd
+  146   cile
+  147   dsialp
+  148   dsiblp
+  149   unassigned
+  150   dds
+  151   unassigned
+  152   dp2
+  153   amx
+  154   adx
+  155   unassigned      (bit affects dfll_ref and dfll_soc)
+  156   xusb_ss
+
+  192   uartb
+  193   vfir
+  194   spdif_in
+  195   spdif_out
+  196   vi
+  197   vi_sensor
+  198   fuse
+  199   fuse_burn
+  200   clk_32k
+  201   clk_m
+  202   clk_m_div2
+  203   clk_m_div4
+  204   pll_ref
+  205   pll_c
+  206   pll_c_out1
+  207   pll_c2
+  208   pll_c3
+  209   pll_m
+  210   pll_m_out1
+  211   pll_p
+  212   pll_p_out1
+  213   pll_p_out2
+  214   pll_p_out3
+  215   pll_p_out4
+  216   pll_a
+  217   pll_a_out0
+  218   pll_d
+  219   pll_d_out0
+  220   pll_d2
+  221   pll_d2_out0
+  222   pll_u
+  223   pll_u_480M
+  224   pll_u_60M
+  225   pll_u_48M
+  226   pll_u_12M
+  227   pll_x
+  228   pll_x_out0
+  229   pll_re_vco
+  230   pll_re_out
+  231   pll_e_out0
+  232   spdif_in_sync
+  233   i2s0_sync
+  234   i2s1_sync
+  235   i2s2_sync
+  236   i2s3_sync
+  237   i2s4_sync
+  238   vimclk_sync
+  239   audio0
+  240   audio1
+  241   audio2
+  242   audio3
+  243   audio4
+  244   spdif
+  245   clk_out_1
+  246   clk_out_2
+  247   clk_out_3
+  248   blink
+  252   xusb_host_src
+  253   xusb_falcon_src
+  254   xusb_fs_src
+  255   xusb_ss_src
+  256   xusb_dev_src
+  257   xusb_dev
+  258   xusb_hs_src
+  259   sclk
+  260   hclk
+  261   pclk
+  262   cclk_g
+  263   cclk_lp
+  264   dfll_ref
+  265   dfll_soc
+
+Example SoC include file:
+
+/ {
+        tegra_car: clock {
+                compatible = "nvidia,tegra114-car";
+                reg = <0x60006000 0x1000>;
+                #clock-cells = <1>;
+        };
+
+        usb@c5004000 {
+                clocks = <&tegra_car 58>; /* usb2 */
+        };
+};
+
+Example board file:
+
+/ {
+        clocks {
+                compatible = "simple-bus";
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                osc: clock@0 {
+                        compatible = "fixed-clock";
+                        reg = <0>;
+                        #clock-cells = <0>;
+                        clock-frequency = <12000000>;
+                };
+
+                clk_32k: clock@1 {
+                        compatible = "fixed-clock";
+                        reg = <1>;
+                        #clock-cells = <0>;
+                        clock-frequency = <32768>;
+                };
+        };
+
+        &tegra_car {
+                clocks = <&clk_32k> <&osc>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
index 0921fac73528..e885680f6b45 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -120,8 +120,8 @@ Required properties :
   90    clk_d
   91    unassigned
   92    sus
-  93    cdev1
-  94    cdev2
+  93    cdev2
+  94    cdev1
   95    unassigned
 
   96    uart2
diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
new file mode 100644
index 000000000000..cc374651662c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -0,0 +1,114 @@
+Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
+
+Reference
+[1] Si5351A/B/C Data Sheet
+    http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
+
+The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
+3 output clocks are accessible. The internal structure of the clock
+generators can be found in [1].
+
+==I2C device node==
+
+Required properties:
+- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
+- reg: i2c device address, shall be 0x60 or 0x61.
+- #clock-cells: from common clock binding; shall be set to 1.
+- clocks: from common clock binding; list of parent clock
+  handles, shall be xtal reference clock or xtal and clkin for
+  si5351c only.
+- #address-cells: shall be set to 1.
+- #size-cells: shall be set to 0.
+
+Optional properties:
+- silabs,pll-source: pair of (number, source) for each pll. Allows
+  to overwrite clock source of pll A (number=0) or B (number=1).
+
+==Child nodes==
+
+Each of the clock outputs can be overwritten individually by
+using a child node to the I2C device node. If a child node for a clock
+output is not set, the eeprom configuration is not overwritten.
+
+Required child node properties:
+- reg: number of clock output.
+
+Optional child node properties:
+- silabs,clock-source: source clock of the output divider stage N, shall be
+  0 = multisynth N
+  1 = multisynth 0 for output clocks 0-3, else multisynth4
+  2 = xtal
+  3 = clkin (si5351c only)
+- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
+- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
+  divider.
+- silabs,pll-master: boolean, multisynth can change pll frequency.
+
+==Example==
+
+/* 25MHz reference crystal */
+ref25: ref25M {
+        compatible = "fixed-clock";
+        #clock-cells = <0>;
+        clock-frequency = <25000000>;
+};
+
+i2c-master-node {
+
+        /* Si5351a msop10 i2c clock generator */
+        si5351a: clock-generator@60 {
+                compatible = "silabs,si5351a-msop";
+                reg = <0x60>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+                #clock-cells = <1>;
+
+                /* connect xtal input to 25MHz reference */
+                clocks = <&ref25>;
+
+                /* connect xtal input as source of pll0 and pll1 */
+                silabs,pll-source = <0 0>, <1 0>;
+
+                /*
+                 * overwrite clkout0 configuration with:
+                 * - 8mA output drive strength
+                 * - pll0 as clock source of multisynth0
+                 * - multisynth0 as clock source of output divider
+                 * - multisynth0 can change pll0
+                 * - set initial clock frequency of 74.25MHz
+                 */
+                clkout0 {
+                        reg = <0>;
+                        silabs,drive-strength = <8>;
+                        silabs,multisynth-source = <0>;
+                        silabs,clock-source = <0>;
+                        silabs,pll-master;
+                        clock-frequency = <74250000>;
+                };
+
+                /*
+                 * overwrite clkout1 configuration with:
+                 * - 4mA output drive strength
+                 * - pll1 as clock source of multisynth1
+                 * - multisynth1 as clock source of output divider
+                 * - multisynth1 can change pll1
+                 */
+                clkout1 {
+                        reg = <1>;
+                        silabs,drive-strength = <4>;
+                        silabs,multisynth-source = <1>;
+                        silabs,clock-source = <0>;
+                        pll-master;
+                };
+
+                /*
+                 * overwrite clkout2 configuration with:
+                 * - xtal as clock source of output divider
+                 */
+                clkout2 {
+                        reg = <2>;
+                        silabs,clock-source = <2>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
new file mode 100644
index 000000000000..729f52426fe1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -0,0 +1,151 @@
+Device Tree Clock bindings for arch-sunxi
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of the following:
+        "allwinner,sun4i-osc-clk" - for a gatable oscillator
+        "allwinner,sun4i-pll1-clk" - for the main PLL clock
+        "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
+        "allwinner,sun4i-axi-clk" - for the AXI clock
+        "allwinner,sun4i-axi-gates-clk" - for the AXI gates
+        "allwinner,sun4i-ahb-clk" - for the AHB clock
+        "allwinner,sun4i-ahb-gates-clk" - for the AHB gates
+        "allwinner,sun4i-apb0-clk" - for the APB0 clock
+        "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates
+        "allwinner,sun4i-apb1-clk" - for the APB1 clock
+        "allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
+        "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates
+
+Required properties for all clocks:
+- reg : shall be the control register address for the clock.
+- clocks : shall be the input parent clock(s) phandle for the clock
+- #clock-cells : from common clock binding; shall be set to 0 except for
+        "allwinner,sun4i-*-gates-clk" where it shall be set to 1
+
+Additionally, "allwinner,sun4i-*-gates-clk" clocks require:
+- clock-output-names : the corresponding gate names that the clock controls
+
+For example:
+
+osc24M: osc24M@01c20050 {
+        #clock-cells = <0>;
+        compatible = "allwinner,sun4i-osc-clk";
+        reg = <0x01c20050 0x4>;
+        clocks = <&osc24M_fixed>;
+};
+
+pll1: pll1@01c20000 {
+        #clock-cells = <0>;
+        compatible = "allwinner,sun4i-pll1-clk";
+        reg = <0x01c20000 0x4>;
+        clocks = <&osc24M>;
+};
+
+cpu: cpu@01c20054 {
+        #clock-cells = <0>;
+        compatible = "allwinner,sun4i-cpu-clk";
+        reg = <0x01c20054 0x4>;
+        clocks = <&osc32k>, <&osc24M>, <&pll1>;
+};
+
+
+
+Gate clock outputs
+
+The "allwinner,sun4i-*-gates-clk" clocks provide several gatable outputs;
+their corresponding offsets as present on sun4i are listed below. Note that
+some of these gates are not present on sun5i.
+
+  * AXI gates ("allwinner,sun4i-axi-gates-clk")
+
+    DRAM                                                                0
+
+  * AHB gates ("allwinner,sun4i-ahb-gates-clk")
+
+    USB0                                                                0
+    EHCI0                                                               1
+    OHCI0                                                               2*
+    EHCI1                                                               3
+    OHCI1                                                               4*
+    SS                                                                  5
+    DMA                                                                 6
+    BIST                                                                7
+    MMC0                                                                8
+    MMC1                                                                9
+    MMC2                                                                10
+    MMC3                                                                11
+    MS                                                                  12**
+    NAND                                                                13
+    SDRAM                                                               14
+
+    ACE                                                                 16
+    EMAC                                                                17
+    TS                                                                  18
+
+    SPI0                                                                20
+    SPI1                                                                21
+    SPI2                                                                22
+    SPI3                                                                23
+    PATA                                                                24
+    SATA                                                                25**
+    GPS                                                                 26*
+
+    VE                                                                  32
+    TVD                                                                 33
+    TVE0                                                                34
+    TVE1                                                                35
+    LCD0                                                                36
+    LCD1                                                                37
+
+    CSI0                                                                40
+    CSI1                                                                41
+
+    HDMI                                                                43
+    DE_BE0                                                              44
+    DE_BE1                                                              45
+    DE_FE0                                                              46
+    DE_FE1                                                              47
+
+    MP                                                                  50
+
+    MALI400                                                             52
+
+  * APB0 gates ("allwinner,sun4i-apb0-gates-clk")
+
+    CODEC                                                               0
+    SPDIF                                                               1*
+    AC97                                                                2
+    IIS                                                                 3
+
+    PIO                                                                 5
+    IR0                                                                 6
+    IR1                                                                 7
+
+    KEYPAD                                                              10
+
+  * APB1 gates ("allwinner,sun4i-apb1-gates-clk")
+
+    I2C0                                                                0
+    I2C1                                                                1
+    I2C2                                                                2
+
+    CAN                                                                 4
+    SCR                                                                 5
+    PS20                                                                6
+    PS21                                                                7
+
+    UART0                                                               16
+    UART1                                                               17
+    UART2                                                               18
+    UART3                                                               19
+    UART4                                                               20
+    UART5                                                               21
+    UART6                                                               22
+    UART7                                                               23
+
+Notation:
+ [*]:  The datasheet didn't mention these, but they are present on AW code
+ [**]: The datasheet had this marked as "NC" but they are used on AW code
diff --git a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
new file mode 100644
index 000000000000..0715695e94a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
@@ -0,0 +1,65 @@
+Generic ARM big LITTLE cpufreq driver's DT glue
+-----------------------------------------------
+
+This is DT specific glue layer for generic cpufreq driver for big LITTLE
+systems.
+
+Both required and optional properties listed below must be defined
+under node /cpus/cpu@x. Where x is the first cpu inside a cluster.
+
+FIXME: Cpus should boot in the order specified in DT and all cpus for a cluster
+must be present contiguously. Generic DT driver will check only node 'x' for
+cpu:x.
+
+Required properties:
+- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
+  for details
+
+Optional properties:
+- clock-latency: Specify the possible maximum transition latency for clock,
+  in unit of nanoseconds.
+
+Examples:
+
+cpus {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        cpu@0 {
+                compatible = "arm,cortex-a15";
+                reg = <0>;
+                next-level-cache = <&L2>;
+                operating-points = <
+                        /* kHz    uV */
+                        792000  1100000
+                        396000  950000
+                        198000  850000
+                >;
+                clock-latency = <61036>; /* two CLK32 periods */
+        };
+
+        cpu@1 {
+                compatible = "arm,cortex-a15";
+                reg = <1>;
+                next-level-cache = <&L2>;
+        };
+
+        cpu@100 {
+                compatible = "arm,cortex-a7";
+                reg = <100>;
+                next-level-cache = <&L2>;
+                operating-points = <
+                        /* kHz    uV */
+                        792000  950000
+                        396000  750000
+                        198000  450000
+                >;
+                clock-latency = <61036>; /* two CLK32 periods */
+        };
+
+        cpu@101 {
+                compatible = "arm,cortex-a7";
+                reg = <101>;
+                next-level-cache = <&L2>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 4416ccc33472..051f764bedb8 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -32,7 +32,7 @@ cpus {
                         396000  950000
                         198000  850000
                 >;
-                transition-latency = <61036>; /* two CLK32 periods */
+                clock-latency = <61036>; /* two CLK32 periods */
         };
 
         cpu@1 {
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000000000000..caff1a57436f
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,28 @@
+
+Exynos5440 cpufreq driver
+-------------------
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be transitioned into,
+        in the decreasing order. Frequency should be in KHz units and voltage
+        should be in microvolts.
+
+Optional properties:
+- clock-latency: Clock monitor latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+--------
+        cpufreq@160000 {
+                compatible = "samsung,exynos5440-cpufreq";
+                reg = <0x160000 0x1000>;
+                interrupts = <0 57 0>;
+                operating-points = <
+                                1000000 975000
+                                800000  925000>;
+                clock-latency = <100000>;
+        };
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
new file mode 100644
index 000000000000..5c65eccd0e56
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
@@ -0,0 +1,15 @@
+Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
+Currently only i.MX27 is supported.
+
+Required properties:
+- compatible : Should be "fsl,<soc>-sahara"
+- reg : Should contain SAHARA registers location and length
+- interrupts : Should contain SAHARA interrupt number
+
+Example:
+
+sah@10025000 {
+        compatible = "fsl,imx27-sahara";
+        reg = < 0x10025000 0x800>;
+        interrupts = <75>;
+};
diff --git a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
index ded0398d3bdc..a4873e5e3e36 100644
--- a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
@@ -3,17 +3,58 @@
 Required properties:
 - compatible : Should be "fsl,<chip>-dma-apbh" or "fsl,<chip>-dma-apbx"
 - reg : Should contain registers location and length
+- interrupts : Should contain the interrupt numbers of DMA channels.
+  If a channel is empty/reserved, 0 should be filled in place.
+- #dma-cells : Must be <1>.  The number cell specifies the channel ID.
+- dma-channels : Number of channels supported by the DMA controller
+
+Optional properties:
+- interrupt-names : Name of DMA channel interrupts
 
 Supported chips:
 imx23, imx28.
 
 Examples:
-dma-apbh@80004000 {
+
+dma_apbh: dma-apbh@80004000 {
         compatible = "fsl,imx28-dma-apbh";
-        reg = <0x80004000 2000>;
+        reg = <0x80004000 0x2000>;
+        interrupts = <82 83 84 85
+                      88 88 88 88
+                      88 88 88 88
+                      87 86 0 0>;
+        interrupt-names = "ssp0", "ssp1", "ssp2", "ssp3",
+                          "gpmi0", "gmpi1", "gpmi2", "gmpi3",
+                          "gpmi4", "gmpi5", "gpmi6", "gmpi7",
+                          "hsadc", "lcdif", "empty", "empty";
+        #dma-cells = <1>;
+        dma-channels = <16>;
 };
 
-dma-apbx@80024000 {
+dma_apbx: dma-apbx@80024000 {
         compatible = "fsl,imx28-dma-apbx";
-        reg = <0x80024000 2000>;
+        reg = <0x80024000 0x2000>;
+        interrupts = <78 79 66 0
+                      80 81 68 69
+                      70 71 72 73
+                      74 75 76 77>;
+        interrupt-names = "auart4-rx", "aurat4-tx", "spdif-tx", "empty",
+                          "saif0", "saif1", "i2c0", "i2c1",
+                          "auart0-rx", "auart0-tx", "auart1-rx", "auart1-tx",
+                          "auart2-rx", "auart2-tx", "auart3-rx", "auart3-tx";
+        #dma-cells = <1>;
+        dma-channels = <16>;
+};
+
+DMA clients connected to the MXS DMA controller must use the format
+described in the dma.txt file.
+
+Examples:
+
+auart0: serial@8006a000 {
+        compatible = "fsl,imx28-auart", "fsl,imx23-auart";
+        reg = <0x8006a000 0x2000>;
+        interrupts = <112>;
+        dmas = <&dma_apbx 8>, <&dma_apbx 9>;
+        dma-names = "rx", "tx";
 };
diff --git a/Documentation/devicetree/bindings/drm/exynos/g2d.txt b/Documentation/devicetree/bindings/drm/exynos/g2d.txt
deleted file mode 100644
index 1eb124d35a99..000000000000
--- a/Documentation/devicetree/bindings/drm/exynos/g2d.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Samsung 2D Graphic Accelerator using DRM frame work
-
-Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer.
-We set the drawing-context registers for configuring rendering parameters and
-then start rendering.
-This driver is for SOCs which contain G2D IPs with version 4.1.
-
-Required properties:
-        -compatible:
-                should be "samsung,exynos-g2d-41".
-        -reg:
-                physical base address of the controller and length
-                of memory mapped region.
-        -interrupts:
-                interrupt combiner values.
-
-Example:
-        g2d {
-                compatible = "samsung,exynos-g2d-41";
-                reg = <0x10850000 0x1000>;
-                interrupts = <0 91 0>;
-        };
diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt
index b41e5e52a676..96ec5179c8a0 100644
--- a/Documentation/devicetree/bindings/fb/mxsfb.txt
+++ b/Documentation/devicetree/bindings/fb/mxsfb.txt
@@ -5,9 +5,16 @@ Required properties:
   imx23 and imx28.
 - reg: Address and length of the register set for lcdif
 - interrupts: Should contain lcdif interrupts
+- display : phandle to display node (see below for details)
 
-Optional properties:
-- panel-enable-gpios : Should specify the gpio for panel enable
+* display node
+
+Required properties:
+- bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
+- bus-width : number of data lines.  Could be <8>, <16>, <18> or <24>.
+
+Required sub-node:
+- display-timings : Refer to binding doc display-timing.txt for details.
 
 Examples:
 
@@ -15,5 +22,28 @@ lcdif@80030000 {
         compatible = "fsl,imx28-lcdif";
         reg = <0x80030000 2000>;
         interrupts = <38 86>;
-        panel-enable-gpios = <&gpio3 30 0>;
+
+        display: display {
+                bits-per-pixel = <32>;
+                bus-width = <24>;
+
+                display-timings {
+                        native-mode = <&timing0>;
+                        timing0: timing0 {
+                                clock-frequency = <33500000>;
+                                hactive = <800>;
+                                vactive = <480>;
+                                hfront-porch = <164>;
+                                hback-porch = <89>;
+                                hsync-len = <10>;
+                                vback-porch = <23>;
+                                vfront-porch = <10>;
+                                vsync-len = <10>;
+                                hsync-active = <0>;
+                                vsync-active = <0>;
+                                de-active = <1>;
+                                pixelclk-active = <0>;
+                        };
+                };
+        };
 };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt b/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
new file mode 100644
index 000000000000..e466598105fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-grgpio.txt
@@ -0,0 +1,26 @@
+Aeroflex Gaisler GRGPIO General Purpose I/O cores.
+
+The GRGPIO GPIO core is available in the GRLIB VHDL IP core library.
+
+Note: In the ordinary environment for the GRGPIO core, a Leon SPARC system,
+these properties are built from information in the AMBA plug&play.
+
+Required properties:
+
+- name : Should be "GAISLER_GPIO" or "01_01a"
+
+- reg : Address and length of the register set for the device
+
+- interrupts : Interrupt numbers for this device
+
+Optional properties:
+
+- nbits : The number of gpio lines. If not present driver assumes 32 lines.
+
+- irqmap : An array with an index for each gpio line. An index is either a valid
+        index into the interrupts property array, or 0xffffffff that indicates
+        no irq for that line. Driver provides no interrupt support if not
+        present.
+
+For further information look in the documentation for the GLIB IP core library:
+http://www.gaisler.com/products/grlib/grip.pdf
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
new file mode 100644
index 000000000000..629d0ef17308
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
@@ -0,0 +1,47 @@
+Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
+8-/16-bit I/O expander with serial interface (I2C/SPI)
+
+Required properties:
+- compatible : Should be
+    - "mcp,mcp23s08" for  8 GPIO SPI version
+    - "mcp,mcp23s17" for 16 GPIO SPI version
+    - "mcp,mcp23008" for  8 GPIO I2C version or
+    - "mcp,mcp23017" for 16 GPIO I2C version of the chip
+- #gpio-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify flags. Flags are currently unused.
+- gpio-controller : Marks the device node as a GPIO controller.
+- reg : For an address on its bus. I2C uses this a the I2C address of the chip.
+        SPI uses this to specify the chipselect line which the chip is
+        connected to. The driver and the SPI variant of the chip support
+        multiple chips on the same chipselect. Have a look at
+        mcp,spi-present-mask below.
+
+Required device specific properties (only for SPI chips):
+- mcp,spi-present-mask : This is a present flag, that makes only sense for SPI
+        chips - as the name suggests. Multiple SPI chips can share the same
+        SPI chipselect. Set a bit in bit0-7 in this mask to 1 if there is a
+        chip connected with the corresponding spi address set. For example if
+        you have a chip with address 3 connected, you have to set bit3 to 1,
+        which is 0x08. mcp23s08 chip variant only supports bits 0-3. It is not
+        possible to mix mcp23s08 and mcp23s17 on the same chipselect. Set at
+        least one bit to 1 for SPI chips.
+- spi-max-frequency = The maximum frequency this chip is able to handle
+
+Example I2C:
+gpiom1: gpio@20 {
+        compatible = "mcp,mcp23017";
+        gpio-controller;
+        #gpio-cells = <2>;
+        reg = <0x20>;
+};
+
+Example SPI:
+gpiom1: gpio@0 {
+        compatible = "mcp,mcp23s17";
+        gpio-controller;
+        #gpio-cells = <2>;
+        spi-present-mask = <0x01>;
+        reg = <0>;
+        spi-max-frequency = <1000000>;
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2fee1e..8d950522e7fa 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
   - "ti,omap2-gpio" for OMAP2 controllers
   - "ti,omap3-gpio" for OMAP3 controllers
   - "ti,omap4-gpio" for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
 - #gpio-cells : Should be two.
   - first cell is the pin number
   - second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
 - #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
   The first cell is the GPIO number.
   The second cell is used to specify flags:
     bits[3:0] trigger type and level flags:
@@ -20,8 +20,11 @@ Required properties:
       8 = active low level-sensitive.
 
 OMAP specific properties:
-- ti,hwmods: Name of the hwmod associated to the GPIO:
-  "gpio<X>", <X> being the 1-based instance number from the HW spec
+- ti,hwmods:            Name of the hwmod associated to the GPIO:
+                        "gpio<X>", <X> being the 1-based instance number
+                        from the HW spec.
+- ti,gpio-always-on:    Indicates if a GPIO bank is always powered and
+                        so will never lose its logic state.
 
 
 Example:
@@ -29,8 +32,8 @@ Example:
 gpio4: gpio4 {
     compatible = "ti,omap4-gpio";
     ti,hwmods = "gpio4";
-    #gpio-cells = <2>;
     gpio-controller;
-    #interrupt-cells = <2>;
+    #gpio-cells = <2>;
     interrupt-controller;
+    #interrupt-cells = <2>;
 };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt b/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
deleted file mode 100644
index f4dc5233167e..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-VIA/Wondermedia VT8500 GPIO Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-gpio", "wm,wm8505-gpio"
-        or "wm,wm8650-gpio" depending on your SoC
-- reg : Should contain 1 register range (address and length)
-- #gpio-cells : should be <3>.
-        1) bank
-        2) pin number
-        3) flags - should be 0
-
-Example:
-
-        gpio: gpio-controller@d8110000 {
-                compatible = "via,vt8500-gpio";
-                gpio-controller;
-                reg = <0xd8110000 0x10000>;
-                #gpio-cells = <3>;
-        };
-
-        vibrate {
-                gpios = <&gpio 0 1 0>; /* Bank 0, Pin 1, No flags */
-        };
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index a33628759d36..d933af370697 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -98,7 +98,7 @@ announce the pinrange to the pin ctrl subsystem. For example,
                 compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
                 reg = <0x1460 0x18>;
                 gpio-controller;
-                gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>;
+                gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
 
     }
 
@@ -107,8 +107,8 @@ where,
 
    Next values specify the base pin and number of pins for the range
    handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
-   pin 29 under pinctrl1 and pin 50 to pin 69 under pinctrl2 is handled
-   by this gpio controller.
+   pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under
+   pinctrl2 with gpio offset 10 is handled by this gpio controller.
 
 The pinctrl node must have "#gpio-range-cells" property to show number of
 arguments to pass with phandle from gpio controllers node.
diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index e13787498bcf..9b3f1d4a88d6 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -1,7 +1,10 @@
 * Marvell PXA GPIO controller
 
 Required properties:
-- compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio"
+- compatible : Should be "intel,pxa25x-gpio", "intel,pxa26x-gpio",
+                "intel,pxa27x-gpio", "intel,pxa3xx-gpio",
+                "marvell,pxa93x-gpio", "marvell,mmp-gpio" or
+                "marvell,mmp2-gpio".
 - reg : Address and length of the register set for the device
 - interrupts : Should be the port interrupt shared by all gpio pins.
   There're three gpio interrupts in arch-pxa, and they're gpio0,
@@ -18,7 +21,7 @@ Required properties:
 Example:
 
         gpio: gpio@d4019000 {
-                compatible = "mrvl,mmp-gpio";
+                compatible = "marvell,mmp-gpio";
                 reg = <0xd4019000 0x1000>;
                 interrupts = <49>;
                 interrupt-name = "gpio_mux";
diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
new file mode 100644
index 000000000000..2b14a940eb75
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
@@ -0,0 +1,20 @@
+* Samsung 2D Graphics Accelerator
+
+Required properties:
+  - compatible : value should be one among the following:
+        (a) "samsung,s5pv210-g2d" for G2D IP present in S5PV210 & Exynos4210 SoC
+        (b) "samsung,exynos4212-g2d" for G2D IP present in Exynos4x12 SoCs
+        (c) "samsung,exynos5250-g2d" for G2D IP present in Exynos5250 SoC
+
+  - reg : Physical base address of the IP registers and length of memory
+          mapped region.
+
+  - interrupts : G2D interrupt number to the CPU.
+
+Example:
+        g2d@12800000 {
+                compatible = "samsung,s5pv210-g2d";
+                reg = <0x12800000 0x1000>;
+                interrupts = <0 89 0>;
+                status = "disabled";
+        };
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
new file mode 100644
index 000000000000..c6f66674f19c
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -0,0 +1,29 @@
+NTC Thermistor hwmon sensors
+-------------------------------
+
+Requires node properties:
+- "compatible" value : one of
+        "ntc,ncp15wb473"
+        "ntc,ncp18wb473"
+        "ntc,ncp21wb473"
+        "ntc,ncp03wb473"
+        "ntc,ncp15wl333"
+- "pullup-uv"   Pull up voltage in micro volts
+- "pullup-ohm"  Pull up resistor value in ohms
+- "pulldown-ohm" Pull down resistor value in ohms
+- "connected-positive" Always ON, If not specified.
+                Status change is possible.
+- "io-channels" Channel node of ADC to be used for
+                conversion.
+
+Read more about iio bindings at
+        Documentation/devicetree/bindings/iio/iio-bindings.txt
+
+Example:
+        ncp15wb473@0 {
+                compatible = "ntc,ncp15wb473";
+                pullup-uv = <1800000>;
+                pullup-ohm = <47000>;
+                pulldown-ohm = <0>;
+                io-channels = <&adc 3>;
+        };
diff --git a/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt b/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt
new file mode 100644
index 000000000000..6616d15866a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt
@@ -0,0 +1,18 @@
+HWRNG support for the timeriomem_rng driver
+
+Required properties:
+- compatible : "timeriomem_rng"
+- reg : base address to sample from
+- period : wait time in microseconds to use between samples
+
+N.B. currently 'reg' must be four bytes wide and aligned
+
+Example:
+
+hwrng@44 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        compatible = "timeriomem_rng";
+        reg = <0x44 0x04>;
+        period = <1000000>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
new file mode 100644
index 000000000000..1ac8ea8ade1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
@@ -0,0 +1,80 @@
+GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
+=================================================================
+This uses GPIO lines and a challenge & response mechanism to arbitrate who is
+the master of an I2C bus in a multimaster situation.
+
+In many cases using GPIOs to arbitrate is not needed and a design can use
+the standard I2C multi-master rules.  Using GPIOs is generally useful in
+the case where there is a device on the bus that has errata and/or bugs
+that makes standard multimaster mode not feasible.
+
+
+Algorithm:
+
+All masters on the bus have a 'bus claim' line which is an output that the
+others can see. These are all active low with pull-ups enabled.  We'll
+describe these lines as:
+
+- OUR_CLAIM: output from us signaling to other hosts that we want the bus
+- THEIR_CLAIMS: output from others signaling that they want the bus
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also.  A detailed explanation is best
+done with an example.
+
+Let's say we want to claim the bus.  We:
+1. Assert OUR_CLAIM.
+2. Waits a little bit for the other sides to notice (slew time, say 10
+   microseconds).
+3. Check THEIR_CLAIMS.  If none are asserted then the we have the bus and we are
+   done.
+4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arb-gpio-challenge
+- our-claim-gpio: The GPIO that we use to claim the bus.
+- their-claim-gpios: The GPIOs that the other sides use to claim the bus.
+  Note that some implementations may only support a single other master.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+    Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+        i2c@12CA0000 {
+                compatible = "acme,some-i2c-device";
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
+
+        i2c-arbitrator {
+                compatible = "i2c-arb-gpio-challenge";
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                i2c-parent = <&{/i2c@12CA0000}>;
+
+                our-claim-gpio = <&gpf0 3 1>;
+                their-claim-gpios = <&gpe0 4 1>;
+                slew-delay-us = <10>;
+                wait-retry-us = <3000>;
+                wait-free-us = <50000>;
+
+                i2c@0 {
+                        reg = <0>;
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        i2c@52 {
+                                // Normal I2C device
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
index 7a3fe9e5f4cb..4e1c8ac01eba 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
@@ -3,10 +3,13 @@
 Required properties:
 - compatible: Should be "fsl,<chip>-i2c"
 - reg: Should contain registers location and length
-- interrupts: Should contain ERROR and DMA interrupts
+- interrupts: Should contain ERROR interrupt number
 - clock-frequency: Desired I2C bus clock frequency in Hz.
                    Only 100000Hz and 400000Hz modes are supported.
-- fsl,i2c-dma-channel: APBX DMA channel for the I2C
+- dmas: DMA specifier, consisting of a phandle to DMA controller node
+  and I2C DMA channel ID.
+  Refer to dma.txt and fsl-mxs-dma.txt for details.
+- dma-names: Must be "rx-tx".
 
 Examples:
 
@@ -15,7 +18,8 @@ i2c0: i2c@80058000 {
         #size-cells = <0>;
         compatible = "fsl,imx28-i2c";
         reg = <0x80058000 2000>;
-        interrupts = <111 68>;
+        interrupts = <111>;
         clock-frequency = <100000>;
-        fsl,i2c-dma-channel = <6>;
+        dmas = <&dma_apbx 6>;
+        dma-names = "rx-tx";
 };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
index f98d4c5b5cca..296eb4536129 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
@@ -26,7 +26,7 @@ Required for all cases except "samsung,s3c2440-hdmiphy-i2c":
     - pinctrl-names: Should contain only one value - "default".
 
 Optional properties:
-  - samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not
+  - samsung,i2c-slave-addr: Slave address in multi-master environment. If not
     specified, default value is 0.
   - samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
     specified, the default value in Hz is 100000.
diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
new file mode 100644
index 000000000000..ef77cc7a0e46
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
@@ -0,0 +1,60 @@
+NVIDIA Tegra20/Tegra30/Tegra114 I2C controller driver.
+
+Required properties:
+- compatible : should be:
+        "nvidia,tegra114-i2c"
+        "nvidia,tegra30-i2c"
+        "nvidia,tegra20-i2c"
+        "nvidia,tegra20-i2c-dvc"
+  Details of compatible are as follows:
+  nvidia,tegra20-i2c-dvc: Tegra20 has specific I2C controller called as DVC I2C
+        controller. This only support master mode of I2C communication. Register
+        interface/offset and interrupts handling are different than generic I2C
+        controller. Driver of DVC I2C controller is only compatible with
+        "nvidia,tegra20-i2c-dvc".
+  nvidia,tegra20-i2c: Tegra20 has 4 generic I2C controller. This can support
+        master and slave mode of I2C communication. The i2c-tegra driver only
+        support master mode of I2C communication. Driver of I2C controller is
+        only compatible with "nvidia,tegra20-i2c".
+  nvidia,tegra30-i2c: Tegra30 has 5 generic I2C controller. This controller is
+        very much similar to Tegra20 I2C controller with additional feature:
+        Continue Transfer Support. This feature helps to implement M_NO_START
+        as per I2C core API transfer flags. Driver of I2C controller is
+        compatible with "nvidia,tegra30-i2c" to enable the continue transfer
+        support. This is also compatible with "nvidia,tegra20-i2c" without
+        continue transfer support.
+  nvidia,tegra114-i2c: Tegra114 has 5 generic I2C controller. This controller is
+        very much similar to Tegra30 I2C controller with some hardware
+        modification:
+         - Tegra30/Tegra20 I2C controller has 2 clock source called div-clk and
+           fast-clk. Tegra114 has only one clock source called as div-clk and
+           hence clock mechanism is changed in I2C controller.
+         - Tegra30/Tegra20 I2C controller has enabled per packet transfer by
+           default and there is no way to disable it. Tegra114 has this
+           interrupt disable by default and SW need to enable explicitly.
+        Due to above changes, Tegra114 I2C driver makes incompatible with
+        previous hardware driver. Hence, tegra114 I2C controller is compatible
+        with "nvidia,tegra114-i2c".
+- reg: Should contain I2C controller registers physical address and length.
+- interrupts: Should contain I2C controller interrupts.
+- address-cells: Address cells for I2C device address.
+- size-cells: Size of the I2C device address.
+- clocks: Clock ID as per
+                Documentation/devicetree/bindings/clock/tegra<chip-id>.txt
+        for I2C controller.
+- clock-names: Name of the clock:
+        Tegra20/Tegra30 I2C controller: "div-clk and "fast-clk".
+        Tegra114 I2C controller: "div-clk".
+
+Example:
+
+        i2c@7000c000 {
+                compatible = "nvidia,tegra20-i2c";
+                reg = <0x7000c000 0x100>;
+                interrupts = <0 38 0x04>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+                clocks = <&tegra_car 12>, <&tegra_car 124>;
+                clock-names = "div-clk", "fast-clk";
+                status = "disabled";
+        };
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 446859fcdca4..ad6a73852f08 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -35,6 +35,8 @@ fsl,mc13892		MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51
 fsl,mma8450             MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
 fsl,mpr121              MPR121: Proximity Capacitive Touch Sensor Controller
 fsl,sgtl5000            SGTL5000: Ultra Low-Power Audio Codec
+infineon,slb9635tt      Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
+infineon,slb9645tt      Infineon SLB9645 I2C TPM (new protocol, max 400khz)
 maxim,ds1050            5 Bit Programmable, Pulse-Width Modulator
 maxim,max1237           Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
 maxim,max6625           9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface
diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
new file mode 100644
index 000000000000..0b447d9ad196
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -0,0 +1,97 @@
+This binding is derived from clock bindings, and based on suggestions
+from Lars-Peter Clausen [1].
+
+Sources of IIO channels can be represented by any node in the device
+tree. Those nodes are designated as IIO providers. IIO consumer
+nodes use a phandle and IIO specifier pair to connect IIO provider
+outputs to IIO inputs. Similar to the gpio specifiers, an IIO
+specifier is an array of one or more cells identifying the IIO
+output on a device. The length of an IIO specifier is defined by the
+value of a #io-channel-cells property in the IIO provider node.
+
+[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2
+
+==IIO providers==
+
+Required properties:
+#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
+                   with a single IIO output and 1 for nodes with multiple
+                   IIO outputs.
+
+Example for a simple configuration with no trigger:
+
+        adc: voltage-sensor@35 {
+                compatible = "maxim,max1139";
+                reg = <0x35>;
+                #io-channel-cells = <1>;
+        };
+
+Example for a configuration with trigger:
+
+        adc@35 {
+                compatible = "some-vendor,some-adc";
+                reg = <0x35>;
+
+                adc1: iio-device@0 {
+                        #io-channel-cells = <1>;
+                        /* other properties */
+                };
+                adc2: iio-device@1 {
+                        #io-channel-cells = <1>;
+                        /* other properties */
+                };
+        };
+
+==IIO consumers==
+
+Required properties:
+io-channels:    List of phandle and IIO specifier pairs, one pair
+                for each IIO input to the device. Note: if the
+                IIO provider specifies '0' for #io-channel-cells,
+                then only the phandle portion of the pair will appear.
+
+Optional properties:
+io-channel-names:
+                List of IIO input name strings sorted in the same
+                order as the io-channels property. Consumers drivers
+                will use io-channel-names to match IIO input names
+                with IIO specifiers.
+io-channel-ranges:
+                Empty property indicating that child nodes can inherit named
+                IIO channels from this node. Useful for bus nodes to provide
+                and IIO channel to their children.
+
+For example:
+
+        device {
+                io-channels = <&adc 1>, <&ref 0>;
+                io-channel-names = "vcc", "vdd";
+        };
+
+This represents a device with two IIO inputs, named "vcc" and "vdd".
+The vcc channel is connected to output 1 of the &adc device, and the
+vdd channel is connected to output 0 of the &ref device.
+
+==Example==
+
+        adc: max1139@35 {
+                compatible = "maxim,max1139";
+                reg = <0x35>;
+                #io-channel-cells = <1>;
+        };
+
+        ...
+
+        iio_hwmon {
+                compatible = "iio-hwmon";
+                io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
+                        <&adc 3>, <&adc 4>, <&adc 5>,
+                        <&adc 6>, <&adc 7>, <&adc 8>,
+                        <&adc 9>;
+        };
+
+        some_consumer {
+                compatible = "some-consumer";
+                io-channels = <&adc 10>, <&adc 11>;
+                io-channel-names = "adc1", "adc2";
+        };
diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000000000000..0f6355ce39b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: "google,cros-ec-keyb"
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+        compatible = "google,cros-ec-keyb";
+        keypad,num-rows = <8>;
+        keypad,num-columns = <13>;
+        google,needs-ghost-filter;
+        /*
+         * Keymap entries take the form of 0xRRCCKKKK where
+         * RR=Row CC=Column KKKK=Key Code
+         * The values below are for a US keyboard layout and
+         * are taken from the Linux driver. Note that the
+         * 102ND key is not used for US keyboards.
+         */
+        linux,keymap = <
+                /* CAPSLCK F1         B          F10     */
+                0x0001003a 0x0002003b 0x00030030 0x00040044
+                /* N       =          R_ALT      ESC     */
+                0x00060031 0x0008000d 0x000a0064 0x01010001
+                /* F4      G          F7         H       */
+                0x0102003e 0x01030022 0x01040041 0x01060023
+                /* '       F9         BKSPACE    L_CTRL  */
+                0x01080028 0x01090043 0x010b000e 0x0200001d
+                /* TAB     F3         T          F6      */
+                0x0201000f 0x0202003d 0x02030014 0x02040040
+                /* ]       Y          102ND      [       */
+                0x0205001b 0x02060015 0x02070056 0x0208001a
+                /* F8      GRAVE      F2         5       */
+                0x02090042 0x03010029 0x0302003c 0x03030006
+                /* F5      6          -          \       */
+                0x0304003f 0x03060007 0x0308000c 0x030b002b
+                /* R_CTRL  A          D          F       */
+                0x04000061 0x0401001e 0x04020020 0x04030021
+                /* S       K          J          ;       */
+                0x0404001f 0x04050025 0x04060024 0x04080027
+                /* L       ENTER      Z          C       */
+                0x04090026 0x040b001c 0x0501002c 0x0502002e
+                /* V       X          ,          M       */
+                0x0503002f 0x0504002d 0x05050033 0x05060032
+                /* L_SHIFT /          .          SPACE   */
+                0x0507002a 0x05080035 0x05090034 0x050B0039
+                /* 1       3          4          2       */
+                0x06010002 0x06020004 0x06030005 0x06040003
+                /* 8       7          0          9       */
+                0x06050009 0x06060008 0x0608000b 0x0609000a
+                /* L_ALT   DOWN       RIGHT      Q       */
+                0x060a0038 0x060b006c 0x060c006a 0x07010010
+                /* E       R          W          I       */
+                0x07020012 0x07030013 0x07040011 0x07050017
+                /* U       R_SHIFT    P          O       */
+                0x07060016 0x07070036 0x07080019 0x07090018
+                /* UP      LEFT    */
+                0x070b0067 0x070c0069>;
+};
diff --git a/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt b/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt
new file mode 100644
index 000000000000..3029c5694cf6
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt
@@ -0,0 +1,16 @@
+Aeroflex Gaisler APBPS2 PS/2 Core, supporting Keyboard or Mouse.
+
+The APBPS2 PS/2 core is available in the GRLIB VHDL IP core library.
+
+Note: In the ordinary environment for the APBPS2 core, a LEON SPARC system,
+these properties are built from information in the AMBA plug&play and from
+bootloader settings.
+
+Required properties:
+
+- name : Should be "GAISLER_APBPS2" or "01_060"
+- reg : Address and length of the register set for the device
+- interrupts : Interrupt numbers for this device
+
+For further information look in the documentation for the GLIB IP core library:
+http://www.gaisler.com/products/grlib/grip.pdf
diff --git a/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt
new file mode 100644
index 000000000000..f40f21c642b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/auo_pixcir_ts.txt
@@ -0,0 +1,30 @@
+* AUO in-cell touchscreen controller using Pixcir sensors
+
+Required properties:
+- compatible: must be "auo,auo_pixcir_ts"
+- reg: I2C address of the chip
+- interrupts: interrupt to which the chip is connected
+- gpios: gpios the chip is connected to
+  first one is the interrupt gpio and second one the reset gpio
+- x-size: horizontal resolution of touchscreen
+- y-size: vertical resolution of touchscreen
+
+Example:
+
+        i2c@00000000 {
+                /* ... */
+
+                auo_pixcir_ts@5c {
+                        compatible = "auo,auo_pixcir_ts";
+                        reg = <0x5c>;
+                        interrupts = <2 0>;
+
+                        gpios = <&gpf 2 0 2>, /* INT */
+                                <&gpf 5 1 0>; /* RST */
+
+                        x-size = <800>;
+                        y-size = <600>;
+                };
+
+                /* ... */
+        };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt b/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt
new file mode 100644
index 000000000000..64ad48b824a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt
@@ -0,0 +1,24 @@
+* Sitronix st1232 touchscreen controller
+
+Required properties:
+- compatible: must be "sitronix,st1232"
+- reg: I2C address of the chip
+- interrupts: interrupt to which the chip is connected
+
+Optional properties:
+- gpios: a phandle to the reset GPIO
+
+Example:
+
+        i2c@00000000 {
+                /* ... */
+
+                touchscreen@55 {
+                        compatible = "sitronix,st1232";
+                        reg = <0x55>;
+                        interrupts = <2 0>;
+                        gpios = <&gpio1 166 0>;
+                };
+
+                /* ... */
+        };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
index 7f9fb85f5456..e7f4dc14eff2 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
@@ -2,7 +2,7 @@ Allwinner Sunxi Interrupt Controller
 
 Required properties:
 
-- compatible : should be "allwinner,sunxi-ic"
+- compatible : should be "allwinner,sun4i-ic"
 - reg : Specifies base physical address and size of the registers.
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
@@ -97,7 +97,7 @@ The interrupt sources are as follows:
 Example:
 
 intc: interrupt-controller {
-        compatible = "allwinner,sunxi-ic";
+        compatible = "allwinner,sun4i-ic";
         reg = <0x01c20400 0x400>;
         interrupt-controller;
         #interrupt-cells = <2>;
diff --git a/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
new file mode 100644
index 000000000000..c54c5a9a2a90
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
@@ -0,0 +1,53 @@
+Samsung S3C24XX Interrupt Controllers
+
+The S3C24XX SoCs contain a custom set of interrupt controllers providing a
+varying number of interrupt sources. The set consists of a main- and sub-
+controller and on newer SoCs even a second main controller.
+
+Required properties:
+- compatible: Compatible property value should be "samsung,s3c2410-irq"
+  for machines before s3c2416 and "samsung,s3c2416-irq" for s3c2416 and later.
+
+- reg: Physical base address of the controller and length of memory mapped
+  region.
+
+- interrupt-controller : Identifies the node as an interrupt controller
+
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 4 and interrupt descriptor shall
+  have the following format:
+      <ctrl_num parent_irq ctrl_irq type>
+
+  ctrl_num contains the controller to use:
+      - 0 ... main controller
+      - 1 ... sub controller
+      - 2 ... second main controller on s3c2416 and s3c2450
+  parent_irq contains the parent bit in the main controller and will be
+             ignored in main controllers
+  ctrl_irq contains the interrupt bit of the controller
+  type contains the trigger type to use
+
+Example:
+
+        interrupt-controller@4a000000 {
+                compatible = "samsung,s3c2410-irq";
+                reg = <0x4a000000 0x100>;
+                interrupt-controller;
+                #interrupt-cells=<4>;
+        };
+
+        [...]
+
+        serial@50000000 {
+                compatible = "samsung,s3c2410-uart";
+                reg = <0x50000000 0x4000>;
+                interrupt-parent = <&subintc>;
+                interrupts = <1 28 0 4>, <1 28 1 4>;
+        };
+
+        rtc@57000000 {
+                compatible = "samsung,s3c2410-rtc";
+                reg = <0x57000000 0x100>;
+                interrupt-parent = <&intc>;
+                interrupts = <0 30 0 3>, <0 8 0 3>;
+        };
diff --git a/Documentation/devicetree/bindings/leds/tca6507.txt b/Documentation/devicetree/bindings/leds/tca6507.txt
index 2b6693b972fb..80ff3dfb1f32 100644
--- a/Documentation/devicetree/bindings/leds/tca6507.txt
+++ b/Documentation/devicetree/bindings/leds/tca6507.txt
@@ -1,4 +1,4 @@
-LEDs conected to tca6507
+LEDs connected to tca6507
 
 Required properties:
 - compatible : should be : "ti,tca6507".
diff --git a/Documentation/devicetree/bindings/marvell.txt b/Documentation/devicetree/bindings/marvell.txt
index f1533d91953a..f7a0da6b4022 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -115,6 +115,9 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
      - compatible : "marvell,mv64360-eth-block"
      - reg : Offset and length of the register set for this block
 
+   Optional properties:
+     - clocks : Phandle to the clock control device and gate bit
+
    Example Discovery Ethernet block node:
      ethernet-block@2000 {
              #address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/media/coda.txt b/Documentation/devicetree/bindings/media/coda.txt
new file mode 100644
index 000000000000..2865d04e4030
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/coda.txt
@@ -0,0 +1,30 @@
+Chips&Media Coda multi-standard codec IP
+========================================
+
+Coda codec IPs are present in i.MX SoCs in various versions,
+called VPU (Video Processing Unit).
+
+Required properties:
+- compatible : should be "fsl,<chip>-src" for i.MX SoCs:
+  (a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27
+  (b) "fsl,imx53-vpu" for CODA7541 present in i.MX53
+  (c) "fsl,imx6q-vpu" for CODA960 present in i.MX6q
+- reg: should be register base and length as documented in the
+  SoC reference manual
+- interrupts : Should contain the VPU interrupt. For CODA960,
+  a second interrupt is needed for the MJPEG unit.
+- clocks : Should contain the ahb and per clocks, in the order
+  determined by the clock-names property.
+- clock-names : Should be "ahb", "per"
+- iram : phandle pointing to the SRAM device node
+
+Example:
+
+vpu: vpu@63ff4000 {
+        compatible = "fsl,imx53-vpu";
+        reg = <0x63ff4000 0x1000>;
+        interrupts = <9>;
+        clocks = <&clks 63>, <&clks 63>;
+        clock-names = "ahb", "per";
+        iram = <&ocram>;
+};
diff --git a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
new file mode 100644
index 000000000000..3f62adfb3e0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
@@ -0,0 +1,14 @@
+Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE)
+
+Required properties:
+
+- compatible    : should be "samsung,exynos4212-fimc" for Exynos4212 and
+                  Exynos4412 SoCs;
+- reg           : physical base address and size of the device memory mapped
+                  registers;
+- interrupts    : should contain FIMC-LITE interrupt;
+- clocks        : FIMC LITE gate clock should be specified in this property.
+- clock-names   : should contain "flite" entry.
+
+Each FIMC device should have an alias in the aliases node, in the form of
+fimc-lite<n>, where <n> is an integer specifying the IP block instance.
diff --git a/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt
new file mode 100644
index 000000000000..55c9ad6f9599
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt
@@ -0,0 +1,49 @@
+Exynos4x12 SoC series Imaging Subsystem (FIMC-IS)
+
+The FIMC-IS is a subsystem for processing image signal from an image sensor.
+The Exynos4x12 SoC series FIMC-IS V1.5 comprises of a dedicated ARM Cortex-A5
+processor, ISP, DRC and FD IP blocks and peripheral devices such as UART, I2C
+and SPI bus controllers, PWM and ADC.
+
+fimc-is node
+------------
+
+Required properties:
+- compatible    : should be "samsung,exynos4212-fimc-is" for Exynos4212 and
+                  Exynos4412 SoCs;
+- reg           : physical base address and length of the registers set;
+- interrupts    : must contain two FIMC-IS interrupts, in order: ISP0, ISP1;
+- clocks        : list of clock specifiers, corresponding to entries in
+                  clock-names property;
+- clock-names   : must contain "ppmuispx", "ppmuispx", "lite0", "lite1"
+                  "mpll", "sysreg", "isp", "drc", "fd", "mcuisp", "uart",
+                  "ispdiv0", "ispdiv1", "mcuispdiv0", "mcuispdiv1", "aclk200",
+                  "div_aclk200", "aclk400mcuisp", "div_aclk400mcuisp" entries,
+                  matching entries in the clocks property.
+pmu subnode
+-----------
+
+Required properties:
+ - reg : must contain PMU physical base address and size of the register set.
+
+The following are the FIMC-IS peripheral device nodes and can be specified
+either standalone or as the fimc-is node child nodes.
+
+i2c-isp (ISP I2C bus controller) nodes
+------------------------------------------
+
+Required properties:
+
+- compatible    : should be "samsung,exynos4212-i2c-isp" for Exynos4212 and
+                  Exynos4412 SoCs;
+- reg           : physical base address and length of the registers set;
+- clocks        : must contain gate clock specifier for this controller;
+- clock-names   : must contain "i2c_isp" entry.
+
+For the above nodes it is required to specify a pinctrl state named "default",
+according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt.
+
+Device tree nodes of the image sensors' controlled directly by the FIMC-IS
+firmware must be child nodes of their corresponding ISP I2C bus controller node.
+The data link of these image sensors must be specified using the common video
+interfaces bindings, defined in video-interfaces.txt.
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 67ec3d4ccc7f..bf0182d8da25 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -21,3 +21,24 @@ Required properties:
 
   - samsung,mfc-l : Base address of the second memory bank used by MFC
                     for DMA contiguous memory allocation and its size.
+
+Optional properties:
+  - samsung,power-domain : power-domain property defined with a phandle
+                           to respective power domain.
+
+Example:
+SoC specific DT entry:
+
+mfc: codec@13400000 {
+        compatible = "samsung,mfc-v5";
+        reg = <0x13400000 0x10000>;
+        interrupts = <0 94 0>;
+        samsung,power-domain = <&pd_mfc>;
+};
+
+Board specific DT entry:
+
+codec@13400000 {
+        samsung,mfc-r = <0x43000000 0x800000>;
+        samsung,mfc-l = <0x51000000 0x800000>;
+};
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt
new file mode 100644
index 000000000000..51c776b7f7a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -0,0 +1,197 @@
+Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC)
+----------------------------------------------
+
+The S5P/Exynos SoC Camera subsystem comprises of multiple sub-devices
+represented by separate device tree nodes. Currently this includes: FIMC (in
+the S5P SoCs series known as CAMIF), MIPI CSIS, FIMC-LITE and FIMC-IS (ISP).
+
+The sub-subdevices are defined as child nodes of the common 'camera' node which
+also includes common properties of the whole subsystem not really specific to
+any single sub-device, like common camera port pins or the CAMCLK clock outputs
+for external image sensors attached to an SoC.
+
+Common 'camera' node
+--------------------
+
+Required properties:
+
+- compatible    : must be "samsung,fimc", "simple-bus"
+- clocks        : list of clock specifiers, corresponding to entries in
+                  the clock-names property;
+- clock-names   : must contain "sclk_cam0", "sclk_cam1", "pxl_async0",
+                  "pxl_async1" entries, matching entries in the clocks property.
+
+The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
+to define a required pinctrl state named "default" and optional pinctrl states:
+"idle", "active-a", active-b". These optional states can be used to switch the
+camera port pinmux at runtime. The "idle" state should configure both the camera
+ports A and B into high impedance state, especially the CAMCLK clock output
+should be inactive. For the "active-a" state the camera port A must be activated
+and the port B deactivated and for the state "active-b" it should be the other
+way around.
+
+The 'camera' node must include at least one 'fimc' child node.
+
+'fimc' device nodes
+-------------------
+
+Required properties:
+
+- compatible: "samsung,s5pv210-fimc" for S5PV210, "samsung,exynos4210-fimc"
+  for Exynos4210 and "samsung,exynos4212-fimc" for Exynos4x12 SoCs;
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain FIMC interrupt;
+- clocks: list of clock specifiers, must contain an entry for each required
+  entry in clock-names;
+- clock-names: must contain "fimc", "sclk_fimc" entries.
+- samsung,pix-limits: an array of maximum supported image sizes in pixels, for
+  details refer to Table 2-1 in the S5PV210 SoC User Manual; The meaning of
+  each cell is as follows:
+  0 - scaler input horizontal size,
+  1 - input horizontal size for the scaler bypassed,
+  2 - REAL_WIDTH without input rotation,
+  3 - REAL_HEIGHT with input rotation,
+- samsung,sysreg: a phandle to the SYSREG node.
+
+Each FIMC device should have an alias in the aliases node, in the form of
+fimc<n>, where <n> is an integer specifying the IP block instance.
+
+Optional properties:
+
+- clock-frequency: maximum FIMC local clock (LCLK) frequency;
+- samsung,min-pix-sizes: an array specyfing minimum image size in pixels at
+  the FIMC input and output DMA, in the first and second cell respectively.
+  Default value when this property is not present is <16 16>;
+- samsung,min-pix-alignment: minimum supported image height alignment (first
+  cell) and the horizontal image offset (second cell). The values are in pixels
+  and default to <2 1> when this property is not present;
+- samsung,mainscaler-ext: a boolean property indicating whether the FIMC IP
+  supports extended image size and has CIEXTEN register;
+- samsung,rotators: a bitmask specifying whether this IP has the input and
+  the output rotator. Bits 4 and 0 correspond to input and output rotator
+  respectively. If a rotator is present its corresponding bit should be set.
+  Default value when this property is not specified is 0x11.
+- samsung,cam-if: a bolean property indicating whether the IP block includes
+  the camera input interface.
+- samsung,isp-wb: this property must be present if the IP block has the ISP
+  writeback input.
+- samsung,lcd-wb: this property must be present if the IP block has the LCD
+  writeback input.
+
+
+'parallel-ports' node
+---------------------
+
+This node should contain child 'port' nodes specifying active parallel video
+input ports. It includes camera A and camera B inputs. 'reg' property in the
+port nodes specifies data input - 0, 1 indicates input A, B respectively.
+
+Optional properties
+
+- samsung,camclk-out : specifies clock output for remote sensor,
+                       0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+
+Image sensor nodes
+------------------
+
+The sensor device nodes should be added to their control bus controller (e.g.
+I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
+using the common video interfaces bindings, defined in video-interfaces.txt.
+The implementation of this bindings requires clock-frequency property to be
+present in the sensor device nodes.
+
+Example:
+
+        aliases {
+                fimc0 = &fimc_0;
+        };
+
+        /* Parallel bus IF sensor */
+        i2c_0: i2c@13860000 {
+                s5k6aa: sensor@3c {
+                        compatible = "samsung,s5k6aafx";
+                        reg = <0x3c>;
+                        vddio-supply = <...>;
+
+                        clock-frequency = <24000000>;
+                        clocks = <...>;
+                        clock-names = "mclk";
+
+                        port {
+                                s5k6aa_ep: endpoint {
+                                        remote-endpoint = <&fimc0_ep>;
+                                        bus-width = <8>;
+                                        hsync-active = <0>;
+                                        vsync-active = <1>;
+                                        pclk-sample = <1>;
+                                };
+                        };
+                };
+        };
+
+        /* MIPI CSI-2 bus IF sensor */
+        s5c73m3: sensor@0x1a {
+                compatible = "samsung,s5c73m3";
+                reg = <0x1a>;
+                vddio-supply = <...>;
+
+                clock-frequency = <24000000>;
+                clocks = <...>;
+                clock-names = "mclk";
+
+                port {
+                        s5c73m3_1: endpoint {
+                                data-lanes = <1 2 3 4>;
+                                remote-endpoint = <&csis0_ep>;
+                        };
+                };
+        };
+
+        camera {
+                compatible = "samsung,fimc", "simple-bus";
+                #address-cells = <1>;
+                #size-cells = <1>;
+                status = "okay";
+
+                pinctrl-names = "default";
+                pinctrl-0 = <&cam_port_a_clk_active>;
+
+                /* parallel camera ports */
+                parallel-ports {
+                        /* camera A input */
+                        port@0 {
+                                reg = <0>;
+                                fimc0_ep: endpoint {
+                                        remote-endpoint = <&s5k6aa_ep>;
+                                        bus-width = <8>;
+                                        hsync-active = <0>;
+                                        vsync-active = <1>;
+                                        pclk-sample = <1>;
+                                };
+                        };
+                };
+
+                fimc_0: fimc@11800000 {
+                        compatible = "samsung,exynos4210-fimc";
+                        reg = <0x11800000 0x1000>;
+                        interrupts = <0 85 0>;
+                        status = "okay";
+                };
+
+                csis_0: csis@11880000 {
+                        compatible = "samsung,exynos4210-csis";
+                        reg = <0x11880000 0x1000>;
+                        interrupts = <0 78 0>;
+                        /* camera C input */
+                        port@3 {
+                                reg = <3>;
+                                csis0_ep: endpoint {
+                                        remote-endpoint = <&s5c73m3_ep>;
+                                        data-lanes = <1 2 3 4>;
+                                        samsung,csis-hs-settle = <12>;
+                                };
+                        };
+                };
+        };
+
+The MIPI-CSIS device binding is defined in samsung-mipi-csis.txt.
diff --git a/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt
new file mode 100644
index 000000000000..5f8e28e2484f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt
@@ -0,0 +1,81 @@
+Samsung S5P/EXYNOS SoC series MIPI CSI-2 receiver (MIPI CSIS)
+-------------------------------------------------------------
+
+Required properties:
+
+- compatible      : "samsung,s5pv210-csis" for S5PV210 (S5PC110),
+                    "samsung,exynos4210-csis" for Exynos4210 (S5PC210),
+                    "samsung,exynos4212-csis" for Exynos4212/Exynos4412
+                    SoC series;
+- reg             : offset and length of the register set for the device;
+- interrupts      : should contain MIPI CSIS interrupt; the format of the
+                    interrupt specifier depends on the interrupt controller;
+- bus-width       : maximum number of data lanes supported (SoC specific);
+- vddio-supply    : MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V);
+- vddcore-supply  : MIPI CSIS Core voltage supply (e.g. 1.1V);
+- clocks          : list of clock specifiers, corresponding to entries in
+                    clock-names property;
+- clock-names     : must contain "csis", "sclk_csis" entries, matching entries
+                    in the clocks property.
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
+                    value when this property is not specified is 166 MHz;
+- samsung,csis-wclk : CSI-2 wrapper clock selection. If this property is present
+                    external clock from CMU will be used, or the bus clock if
+                    if it's not specified.
+
+The device node should contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in Documentation/devicetree/bindings/
+media/video-interfaces.txt. The following are properties specific to those nodes.
+
+port node
+---------
+
+- reg             : (required) must be 3 for camera C input (CSIS0) or 4 for
+                    camera D input (CSIS1);
+
+endpoint node
+-------------
+
+- data-lanes      : (required) an array specifying active physical MIPI-CSI2
+                    data input lanes and their mapping to logical lanes; the
+                    array's content is unused, only its length is meaningful;
+
+- samsung,csis-hs-settle : (optional) differential receiver (HS-RX) settle time;
+
+
+Example:
+
+        reg0: regulator@0 {
+        };
+
+        reg1: regulator@1 {
+        };
+
+/* SoC properties */
+
+        csis_0: csis@11880000 {
+                compatible = "samsung,exynos4210-csis";
+                reg = <0x11880000 0x1000>;
+                interrupts = <0 78 0>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
+
+/* Board properties */
+
+        csis_0: csis@11880000 {
+                clock-frequency = <166000000>;
+                vddio-supply = <&reg0>;
+                vddcore-supply = <&reg1>;
+                port {
+                        reg = <3>; /* 3 - CSIS0, 4 - CSIS1 */
+                        csis0_ep: endpoint {
+                                remote-endpoint = <...>;
+                                data-lanes = <1>, <2>;
+                                samsung,csis-hs-settle = <12>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
new file mode 100644
index 000000000000..e022d2dc4962
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -0,0 +1,228 @@
+Common bindings for video receiver and transmitter interfaces
+
+General concept
+---------------
+
+Video data pipelines usually consist of external devices, e.g. camera sensors,
+controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
+video DMA engines and video data processors.
+
+SoC internal blocks are described by DT nodes, placed similarly to other SoC
+blocks.  External devices are represented as child nodes of their respective
+bus controller nodes, e.g. I2C.
+
+Data interfaces on all video devices are described by their child 'port' nodes.
+Configuration of a port depends on other devices participating in the data
+transfer and is described by 'endpoint' subnodes.
+
+device {
+        ...
+        ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                        ...
+                        endpoint@0 { ... };
+                        endpoint@1 { ... };
+                };
+                port@1 { ... };
+        };
+};
+
+If a port can be configured to work with more than one remote device on the same
+bus, an 'endpoint' child node must be provided for each of them.  If more than
+one port is present in a device node or there is more than one endpoint at a
+port, or port node needs to be associated with a selected hardware interface,
+a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
+used.
+
+All 'port' nodes can be grouped under optional 'ports' node, which allows to
+specify #address-cells, #size-cells properties independently for the 'port'
+and 'endpoint' nodes and any child device nodes a device might have.
+
+Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
+phandles.  An endpoint subnode of a device contains all properties needed for
+configuration of this device for data exchange with other device.  In most
+cases properties at the peer 'endpoint' nodes will be identical, however they
+might need to be different when there is any signal modifications on the bus
+between two devices, e.g. there are logic signal inverters on the lines.
+
+It is allowed for multiple endpoints at a port to be active simultaneously,
+where supported by a device.  For example, in case where a data interface of
+a device is partitioned into multiple data busses, e.g. 16-bit input port
+divided into two separate ITU-R BT.656 8-bit busses.  In such case bus-width
+and data-shift properties can be used to assign physical data lines to each
+endpoint node (logical bus).
+
+
+Required properties
+-------------------
+
+If there is more than one 'port' or more than one 'endpoint' node or 'reg'
+property is present in port and/or endpoint nodes the following properties
+are required in a relevant parent node:
+
+ - #address-cells : number of cells required to define port/endpoint
+                    identifier, should be 1.
+ - #size-cells    : should be zero.
+
+Optional endpoint properties
+----------------------------
+
+- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
+- slave-mode: a boolean property indicating that the link is run in slave mode.
+  The default when this property is not specified is master mode. In the slave
+  mode horizontal and vertical synchronization signals are provided to the
+  slave device (data source) by the master device (data sink). In the master
+  mode the data source device is also the source of the synchronization signals.
+- bus-width: number of data lines actively used, valid for the parallel busses.
+- data-shift: on the parallel data busses, if bus-width is used to specify the
+  number of data lines, data-shift can be used to specify which data lines are
+  used, e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
+- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
+- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
+  Note, that if HSYNC and VSYNC polarities are not specified, embedded
+  synchronization may be required, where supported.
+- data-active: similar to HSYNC and VSYNC, specifies data line polarity.
+- field-even-active: field signal level during the even field data transmission.
+- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
+  signal.
+- data-lanes: an array of physical data lane indexes. Position of an entry
+  determines the logical lane number, while the value of an entry indicates
+  physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have
+  "data-lanes = <1 2>;", assuming the clock lane is on hardware lane 0.
+  This property is valid for serial busses only (e.g. MIPI CSI-2).
+- clock-lanes: an array of physical clock lane indexes. Position of an entry
+  determines the logical lane number, while the value of an entry indicates
+  physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
+  which places the clock lane on hardware lane 0. This property is valid for
+  serial busses only (e.g. MIPI CSI-2). Note that for the MIPI CSI-2 bus this
+  array contains only one entry.
+- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
+  clock mode.
+
+
+Example
+-------
+
+The example snippet below describes two data pipelines.  ov772x and imx074 are
+camera sensors with a parallel and serial (MIPI CSI-2) video bus respectively.
+Both sensors are on the I2C control bus corresponding to the i2c0 controller
+node.  ov772x sensor is linked directly to the ceu0 video host interface.
+imx074 is linked to ceu0 through the MIPI CSI-2 receiver (csi2). ceu0 has a
+(single) DMA engine writing captured data to memory.  ceu0 node has a single
+'port' node which may indicate that at any time only one of the following data
+pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
+
+        ceu0: ceu@0xfe910000 {
+                compatible = "renesas,sh-mobile-ceu";
+                reg = <0xfe910000 0xa0>;
+                interrupts = <0x880>;
+
+                mclk: master_clock {
+                        compatible = "renesas,ceu-clock";
+                        #clock-cells = <1>;
+                        clock-frequency = <50000000>;   /* Max clock frequency */
+                        clock-output-names = "mclk";
+                };
+
+                port {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        /* Parallel bus endpoint */
+                        ceu0_1: endpoint@1 {
+                                reg = <1>;              /* Local endpoint # */
+                                remote = <&ov772x_1_1>; /* Remote phandle */
+                                bus-width = <8>;        /* Used data lines */
+                                data-shift = <2>;       /* Lines 9:2 are used */
+
+                                /* If hsync-active/vsync-active are missing,
+                                   embedded BT.656 sync is used */
+                                hsync-active = <0>;     /* Active low */
+                                vsync-active = <0>;     /* Active low */
+                                data-active = <1>;      /* Active high */
+                                pclk-sample = <1>;      /* Rising */
+                        };
+
+                        /* MIPI CSI-2 bus endpoint */
+                        ceu0_0: endpoint@0 {
+                                reg = <0>;
+                                remote = <&csi2_2>;
+                        };
+                };
+        };
+
+        i2c0: i2c@0xfff20000 {
+                ...
+                ov772x_1: camera@0x21 {
+                        compatible = "omnivision,ov772x";
+                        reg = <0x21>;
+                        vddio-supply = <&regulator1>;
+                        vddcore-supply = <&regulator2>;
+
+                        clock-frequency = <20000000>;
+                        clocks = <&mclk 0>;
+                        clock-names = "xclk";
+
+                        port {
+                                /* With 1 endpoint per port no need for addresses. */
+                                ov772x_1_1: endpoint {
+                                        bus-width = <8>;
+                                        remote-endpoint = <&ceu0_1>;
+                                        hsync-active = <1>;
+                                        vsync-active = <0>; /* Who came up with an
+                                                               inverter here ?... */
+                                        data-active = <1>;
+                                        pclk-sample = <1>;
+                                };
+                        };
+                };
+
+                imx074: camera@0x1a {
+                        compatible = "sony,imx074";
+                        reg = <0x1a>;
+                        vddio-supply = <&regulator1>;
+                        vddcore-supply = <&regulator2>;
+
+                        clock-frequency = <30000000>;   /* Shared clock with ov772x_1 */
+                        clocks = <&mclk 0>;
+                        clock-names = "sysclk";         /* Assuming this is the
+                                                           name in the datasheet */
+                        port {
+                                imx074_1: endpoint {
+                                        clock-lanes = <0>;
+                                        data-lanes = <1 2>;
+                                        remote-endpoint = <&csi2_1>;
+                                };
+                        };
+                };
+        };
+
+        csi2: csi2@0xffc90000 {
+                compatible = "renesas,sh-mobile-csi2";
+                reg = <0xffc90000 0x1000>;
+                interrupts = <0x17a0>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@1 {
+                        compatible = "renesas,csi2c";   /* One of CSI2I and CSI2C. */
+                        reg = <1>;                      /* CSI-2 PHY #1 of 2: PHY_S,
+                                                           PHY_M has port address 0,
+                                                           is unused. */
+                        csi2_1: endpoint {
+                                clock-lanes = <0>;
+                                data-lanes = <2 1>;
+                                remote-endpoint = <&imx074_1>;
+                        };
+                };
+                port@2 {
+                        reg = <2>;                      /* port 2: link to the CEU */
+
+                        csi2_2: endpoint {
+                                remote-endpoint = <&ceu0_0>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/metag/meta-intc.txt b/Documentation/devicetree/bindings/metag/meta-intc.txt
index 8c47dcbfabc6..80994adab392 100644
--- a/Documentation/devicetree/bindings/metag/meta-intc.txt
+++ b/Documentation/devicetree/bindings/metag/meta-intc.txt
@@ -12,7 +12,7 @@ Required properties:
       handle 32 interrupt sources).
 
     - interrupt-controller: The presence of this property identifies the node
-      as an interupt controller. No property value shall be defined.
+      as an interrupt controller. No property value shall be defined.
 
     - #interrupt-cells: Specifies the number of cells needed to encode an
       interrupt source. The type shall be a <u32> and the value shall be 2.
diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt
index 13b707b7355c..c3a14e0ad0ad 100644
--- a/Documentation/devicetree/bindings/mfd/ab8500.txt
+++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
@@ -13,9 +13,6 @@ Required parent device properties:
                                   4 = active high level-sensitive
                                   8 = active low level-sensitive
 
-Optional parent device properties:
-- reg                    : contains the PRCMU mailbox address for the AB8500 i2c port
-
 The AB8500 consists of a large and varied group of sub-devices:
 
 Device                     IRQ Names              Supply Names   Description
@@ -86,9 +83,8 @@ Non-standard child device properties:
    - stericsson,amic2-bias-vamic1           : Analoge Mic wishes to use a non-standard Vamic
    - stericsson,earpeice-cmv                : Earpeice voltage (only: 950 | 1100 | 1270 | 1580)
 
-ab8500@5 {
+ab8500 {
          compatible = "stericsson,ab8500";
-         reg = <5>; /* mailbox 5 is i2c */
          interrupts = <0 40 0x4>;
          interrupt-controller;
          #interrupt-cells = <2>;
diff --git a/Documentation/devicetree/bindings/mfd/as3711.txt b/Documentation/devicetree/bindings/mfd/as3711.txt
new file mode 100644
index 000000000000..d98cf18c721c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/as3711.txt
@@ -0,0 +1,73 @@
+AS3711 is an I2C PMIC from Austria MicroSystems with multiple DCDC and LDO power
+supplies, a battery charger and an RTC. So far only bindings for the two stepup
+DCDC converters are defined. Other DCDC and LDO supplies are configured, using
+standard regulator properties, they must belong to a sub-node, called
+"regulators" and be called "sd1" to "sd4" and "ldo1" to "ldo8." Stepup converter
+configuration should be placed in a subnode, called "backlight."
+
+Compulsory properties:
+- compatible            : must be "ams,as3711"
+- reg                   : specifies the I2C address
+
+To use the SU1 converter as a backlight source the following two properties must
+be provided:
+- su1-dev               : framebuffer phandle
+- su1-max-uA            : maximum current
+
+To use the SU2 converter as a backlight source the following two properties must
+be provided:
+- su2-dev               : framebuffer phandle
+- su1-max-uA            : maximum current
+
+Additionally one of these properties must be provided to select the type of
+feedback used:
+- su2-feedback-voltage  : voltage feedback is used
+- su2-feedback-curr1    : CURR1 input used for current feedback
+- su2-feedback-curr2    : CURR2 input used for current feedback
+- su2-feedback-curr3    : CURR3 input used for current feedback
+- su2-feedback-curr-auto: automatic current feedback selection
+
+and one of these to select the over-voltage protection pin
+- su2-fbprot-lx-sd4     : LX_SD4 is used for over-voltage protection
+- su2-fbprot-gpio2      : GPIO2 is used for over-voltage protection
+- su2-fbprot-gpio3      : GPIO3 is used for over-voltage protection
+- su2-fbprot-gpio4      : GPIO4 is used for over-voltage protection
+
+If "su2-feedback-curr-auto" is selected, one or more of the following properties
+have to be specified:
+- su2-auto-curr1        : use CURR1 input for current feedback
+- su2-auto-curr2        : use CURR2 input for current feedback
+- su2-auto-curr3        : use CURR3 input for current feedback
+
+Example:
+
+as3711@40 {
+        compatible = "ams,as3711";
+        reg = <0x40>;
+
+        regulators {
+                sd4 {
+                        regulator-name = "1.215V";
+                        regulator-min-microvolt = <1215000>;
+                        regulator-max-microvolt = <1235000>;
+                };
+                ldo2 {
+                        regulator-name = "2.8V CPU";
+                        regulator-min-microvolt = <2800000>;
+                        regulator-max-microvolt = <2800000>;
+                        regulator-always-on;
+                        regulator-boot-on;
+                };
+        };
+
+        backlight {
+                compatible = "ams,as3711-bl";
+                su2-dev = <&lcdc>;
+                su2-max-uA = <36000>;
+                su2-feedback-curr-auto;
+                su2-fbprot-gpio4;
+                su2-auto-curr1;
+                su2-auto-curr2;
+                su2-auto-curr3;
+        };
+};
diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt
new file mode 100644
index 000000000000..e0e59c58a1f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -0,0 +1,56 @@
+ChromeOS Embedded Controller
+
+Google's ChromeOS EC is a Cortex-M device which talks to the AP and
+implements various function such as keyboard and battery charging.
+
+The EC can be connect through various means (I2C, SPI, LPC) and the
+compatible string used depends on the inteface. Each connection method has
+its own driver which connects to the top level interface-agnostic EC driver.
+Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
+the top-level driver.
+
+Required properties (I2C):
+- compatible: "google,cros-ec-i2c"
+- reg: I2C slave address
+
+Required properties (SPI):
+- compatible: "google,cros-ec-spi"
+- reg: SPI chip select
+
+Required properties (LPC):
+- compatible: "google,cros-ec-lpc"
+- reg: List of (IO address, size) pairs defining the interface uses
+
+
+Example for I2C:
+
+i2c@12CA0000 {
+        cros-ec@1e {
+                reg = <0x1e>;
+                compatible = "google,cros-ec-i2c";
+                interrupts = <14 0>;
+                interrupt-parent = <&wakeup_eint>;
+                wakeup-source;
+        };
+
+
+Example for SPI:
+
+spi@131b0000 {
+        ec@0 {
+                compatible = "google,cros-ec-spi";
+                reg = <0x0>;
+                interrupts = <14 0>;
+                interrupt-parent = <&wakeup_eint>;
+                wakeup-source;
+                spi-max-frequency = <5000000>;
+                controller-data {
+                cs-gpio = <&gpf0 3 4 3 0>;
+                samsung,spi-cs;
+                samsung,spi-feedback-delay = <2>;
+                };
+        };
+};
+
+
+Example for LPC is not supplied as it is not yet implemented.
diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
index baf07987ae68..abd9e3cb2db7 100644
--- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt
+++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
@@ -10,10 +10,40 @@ Optional properties:
 - fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
 
 Sub-nodes:
-- regulators : Contain the regulator nodes.  The MC13892 regulators are
-  bound using their names as listed below with their registers and bits
-  for enabling.
+- regulators : Contain the regulator nodes. The regulators are bound using
+  their names as listed below with their registers and bits for enabling.
 
+MC13783 regulators:
+    sw1a      : regulator SW1A      (register 24, bit 0)
+    sw1b      : regulator SW1B      (register 25, bit 0)
+    sw2a      : regulator SW2A      (register 26, bit 0)
+    sw2b      : regulator SW2B      (register 27, bit 0)
+    sw3       : regulator SW3       (register 29, bit 20)
+    vaudio    : regulator VAUDIO    (register 32, bit 0)
+    viohi     : regulator VIOHI     (register 32, bit 3)
+    violo     : regulator VIOLO     (register 32, bit 6)
+    vdig      : regulator VDIG      (register 32, bit 9)
+    vgen      : regulator VGEN      (register 32, bit 12)
+    vrfdig    : regulator VRFDIG    (register 32, bit 15)
+    vrfref    : regulator VRFREF    (register 32, bit 18)
+    vrfcp     : regulator VRFCP     (register 32, bit 21)
+    vsim      : regulator VSIM      (register 33, bit 0)
+    vesim     : regulator VESIM     (register 33, bit 3)
+    vcam      : regulator VCAM      (register 33, bit 6)
+    vrfbg     : regulator VRFBG     (register 33, bit 9)
+    vvib      : regulator VVIB      (register 33, bit 11)
+    vrf1      : regulator VRF1      (register 33, bit 12)
+    vrf2      : regulator VRF2      (register 33, bit 15)
+    vmmc1     : regulator VMMC1     (register 33, bit 18)
+    vmmc2     : regulator VMMC2     (register 33, bit 21)
+    gpo1      : regulator GPO1      (register 34, bit 6)
+    gpo2      : regulator GPO2      (register 34, bit 8)
+    gpo3      : regulator GPO3      (register 34, bit 10)
+    gpo4      : regulator GPO4      (register 34, bit 12)
+    pwgt1spi  : regulator PWGT1SPI  (register 34, bit 15)
+    pwgt2spi  : regulator PWGT2SPI  (register 34, bit 16)
+
+MC13892 regulators:
     vcoincell : regulator VCOINCELL (register 13, bit 23)
     sw1       : regulator SW1       (register 24, bit 0)
     sw2       : regulator SW2       (register 25, bit 0)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 000000000000..b381fa696bf9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,80 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be "ti,usbhs-host"
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain "usb_host_hs"
+
+Optional properties:
+
+- num-ports: number of USB ports. Usually this is automatically detected
+  from the IP's revision register but can be overridden by specifying
+  this property. A maximum of 3 ports are supported at the moment.
+
+- portN-mode: String specifying the port mode for port N, where N can be
+  from 1 to 3. If the port mode is not specified, that port is treated
+  as unused. When specified, it must be one of the following.
+        "ehci-phy",
+        "ehci-tll",
+        "ehci-hsic",
+        "ohci-phy-6pin-datse0",
+        "ohci-phy-6pin-dpdm",
+        "ohci-phy-3pin-datse0",
+        "ohci-phy-4pin-dpdm",
+        "ohci-tll-6pin-datse0",
+        "ohci-tll-6pin-dpdm",
+        "ohci-tll-3pin-datse0",
+        "ohci-tll-4pin-dpdm",
+        "ohci-tll-2pin-datse0",
+        "ohci-tll-2pin-dpdm",
+
+- single-ulpi-bypass: Must be present if the controller contains a single
+  ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+usbhshost: usbhshost@4a064000 {
+        compatible = "ti,usbhs-host";
+        reg = <0x4a064000 0x800>;
+        ti,hwmods = "usb_host_hs";
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+
+        usbhsohci: ohci@4a064800 {
+                compatible = "ti,ohci-omap3", "usb-ohci";
+                reg = <0x4a064800 0x400>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 76 0x4>;
+        };
+
+        usbhsehci: ehci@4a064c00 {
+                compatible = "ti,ehci-omap", "usb-ehci";
+                reg = <0x4a064c00 0x400>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 77 0x4>;
+        };
+};
+
+&usbhshost {
+        port1-mode = "ehci-phy";
+        port2-mode = "ehci-tll";
+        port3-mode = "ehci-phy";
+};
+
+&usbhsehci {
+        phys = <&hsusb1_phy 0 &hsusb3_phy>;
+};
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
new file mode 100644
index 000000000000..62fe69724e3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -0,0 +1,17 @@
+OMAP HS USB Host TLL (Transceiver-Less Interface)
+
+Required properties:
+
+- compatible : should be "ti,usbhs-tll"
+- reg : should contain one register range i.e. start and length
+- interrupts : should contain the TLL module's interrupt
+- ti,hwmod : must contain "usb_tll_hs"
+
+Example:
+
+        usbhstll: usbhstll@4a062000 {
+                compatible = "ti,usbhs-tll";
+                reg = <0x4a062000 0x1000>;
+                interrupts = <78>;
+                ti,hwmods = "usb_tll_hs";
+          };
diff --git a/Documentation/devicetree/bindings/misc/smc.txt b/Documentation/devicetree/bindings/misc/smc.txt
new file mode 100644
index 000000000000..02b428136177
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/smc.txt
@@ -0,0 +1,14 @@
+Broadcom Secure Monitor Bounce buffer
+-----------------------------------------------------
+This binding defines the location of the bounce buffer
+used for non-secure to secure communications.
+
+Required properties:
+- compatible : "bcm,kona-smc"
+- reg : Location and size of bounce buffer
+
+Example:
+        smc@0x3404c000 {
+                compatible = "bcm,bcm11351-smc", "bcm,kona-smc";
+                reg = <0x3404c000 0x400>; //1 KiB in SRAM
+        };
diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
new file mode 100644
index 000000000000..4d0a00e453a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/sram.txt
@@ -0,0 +1,16 @@
+Generic on-chip SRAM
+
+Simple IO memory regions to be managed by the genalloc API.
+
+Required properties:
+
+- compatible : mmio-sram
+
+- reg : SRAM iomem address range
+
+Example:
+
+sram: sram@5c000000 {
+        compatible = "mmio-sram";
+        reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
+};
diff --git a/Documentation/devicetree/bindings/mmc/davinci_mmc.txt b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
new file mode 100644
index 000000000000..e5a0140b2381
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
@@ -0,0 +1,33 @@
+* TI Highspeed MMC host controller for DaVinci
+
+The Highspeed MMC Host Controller on TI DaVinci family
+provides an interface for MMC, SD and SDIO types of memory cards.
+
+This file documents the properties used by the davinci_mmc driver.
+
+Required properties:
+- compatible:
+ Should be "ti,da830-mmc": for da830, da850, dm365
+ Should be "ti,dm355-mmc": for dm355, dm644x
+
+Optional properties:
+- bus-width: Number of data lines, can be <1>, <4>, or <8>, default <1>
+- max-frequency: Maximum operating clock frequency, default 25MHz.
+- dmas: List of DMA specifiers with the controller specific format
+        as described in the generic DMA client binding. A tx and rx
+        specifier is required.
+- dma-names: RX and TX  DMA request names. These strings correspond
+        1:1 with the DMA specifiers listed in dmas.
+
+Example:
+mmc0: mmc@1c40000 {
+        compatible = "ti,da830-mmc",
+        reg = <0x40000 0x1000>;
+        interrupts = <16>;
+        status = "okay";
+        bus-width = <4>;
+        max-frequency = <50000000>;
+        dmas = <&edma 16
+                &edma 17>;
+        dma-names = "rx", "tx";
+};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
new file mode 100644
index 000000000000..db442355cd24
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
@@ -0,0 +1,24 @@
+* Freescale Secure Digital Host Controller for i.MX2/3 series
+
+This file documents differences to the properties defined in mmc.txt.
+
+Required properties:
+- compatible : Should be "fsl,<chip>-mmc", chip can be imx21 or imx31
+
+Optional properties:
+- dmas: One DMA phandle with arguments as defined by the devicetree bindings
+        of the used DMA controller.
+- dma-names: Has to be "rx-tx".
+
+Example:
+
+sdhci1: sdhci@10014000 {
+        compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
+        reg = <0x10014000 0x1000>;
+        interrupts = <11>;
+        dmas = <&dma 7>;
+        dma-names = "rx-tx";
+        bus-width = <4>;
+        cd-gpios = <&gpio3 29>;
+        status = "okay";
+};
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
index 54949f6faede..515addc20070 100644
--- a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
@@ -9,15 +9,19 @@ and the properties used by the mxsmmc driver.
 Required properties:
 - compatible: Should be "fsl,<chip>-mmc".  The supported chips include
   imx23 and imx28.
-- interrupts: Should contain ERROR and DMA interrupts
-- fsl,ssp-dma-channel: APBH DMA channel for the SSP
+- interrupts: Should contain ERROR interrupt number
+- dmas: DMA specifier, consisting of a phandle to DMA controller node
+  and SSP DMA channel ID.
+  Refer to dma.txt and fsl-mxs-dma.txt for details.
+- dma-names: Must be "rx-tx".
 
 Examples:
 
 ssp0: ssp@80010000 {
         compatible = "fsl,imx28-mmc";
         reg = <0x80010000 2000>;
-        interrupts = <96 82>;
-        fsl,ssp-dma-channel = <0>;
+        interrupts = <96>;
+        dmas = <&dma_apbh 0>;
+        dma-names = "rx-tx";
         bus-width = <8>;
 };
diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
index 3b3a1ee055ff..328e990d2546 100644
--- a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -5,13 +5,6 @@ MMC, SD and eMMC storage mediums. This file documents differences between the
 core mmc properties described by mmc.txt and the properties used by the
 Samsung implmentation of the SDHCI controller.
 
-Note: The mmc core bindings documentation states that if none of the core
-card-detect bindings are used, then the standard sdhci card detect mechanism
-is used. The Samsung's SDHCI controller bindings extends this as listed below.
-
-[A] The property "samsung,cd-pinmux-gpio" can be used as stated in the
-    "Optional Board Specific Properties" section below.
-
 Required SoC Specific Properties:
 - compatible: should be one of the following
   - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
@@ -20,18 +13,8 @@ Required SoC Specific Properties:
     controller.
 
 Required Board Specific Properties:
-- Samsung GPIO variant (will be completely replaced by pinctrl):
-  - gpios: Should specify the gpios used for clock, command and data lines. The
-    gpio specifier format depends on the gpio controller.
-- Pinctrl variant (preferred if available):
-  - pinctrl-0: Should specify pin control groups used for this controller.
-  - pinctrl-names: Should contain only one value - "default".
-
-Optional Board Specific Properties:
-- samsung,cd-pinmux-gpio: Specifies the card detect line that is routed
-  through a pinmux to the card-detect pin of the card slot. This property
-  should be used only if none of the mmc core card-detect properties are
-  used. Only for Samsung GPIO variant.
+- pinctrl-0: Should specify pin control groups used for this controller.
+- pinctrl-names: Should contain only one value - "default".
 
 Example:
         sdhci@12530000 {
@@ -39,19 +22,9 @@ Example:
                 reg = <0x12530000 0x100>;
                 interrupts = <0 75 0>;
                 bus-width = <4>;
-                cd-gpios = <&gpk2 2 2 3 3>;
-
-                /* Samsung GPIO variant */
-                gpios = <&gpk2 0 2 0 3>,  /* clock line */
-                        <&gpk2 1 2 0 3>,  /* command line */
-                        <&gpk2 3 2 3 3>,  /* data line 0 */
-                        <&gpk2 4 2 3 3>,  /* data line 1 */
-                        <&gpk2 5 2 3 3>,  /* data line 2 */
-                        <&gpk2 6 2 3 3>;  /* data line 3 */
-
-                /* Pinctrl variant */
-                pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>;
+                cd-gpios = <&gpk2 2 0>;
                 pinctrl-names = "default";
+                pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>;
         };
 
         Note: This example shows both SoC specific and board specific properties
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-sirf.txt b/Documentation/devicetree/bindings/mmc/sdhci-sirf.txt
new file mode 100644
index 000000000000..dd6ed464bcb8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-sirf.txt
@@ -0,0 +1,18 @@
+* SiRFprimII/marco/atlas6 SDHCI Controller
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-sirf driver.
+
+Required properties:
+- compatible: sirf,prima2-sdhc
+
+Optional properties:
+- cd-gpios: card detect gpio, with zero flags.
+
+Example:
+
+        sd0: sdhci@56000000 {
+                compatible = "sirf,prima2-sdhc";
+                reg = <0xcd000000 0x100000>;
+                cd-gpios = <&gpio 6 0>;
+        };
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
index 3fb3f9015365..551b2a179d01 100644
--- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
@@ -7,10 +7,12 @@ Required properties:
   - compatible : should be "fsl,<chip>-gpmi-nand"
   - reg : should contain registers location and length for gpmi and bch.
   - reg-names: Should contain the reg names "gpmi-nand" and "bch"
-  - interrupts : The first is the DMA interrupt number for GPMI.
-                 The second is the BCH interrupt number.
-  - interrupt-names : The interrupt names "gpmi-dma", "bch";
-  - fsl,gpmi-dma-channel : Should contain the dma channel it uses.
+  - interrupts : BCH interrupt number.
+  - interrupt-names : Should be "bch".
+  - dmas: DMA specifier, consisting of a phandle to DMA controller node
+    and GPMI DMA channel ID.
+    Refer to dma.txt and fsl-mxs-dma.txt for details.
+  - dma-names: Must be "rx-tx".
 
 Optional properties:
   - nand-on-flash-bbt: boolean to enable on flash bbt option if not
@@ -27,9 +29,10 @@ gpmi-nand@8000c000 {
         #size-cells = <1>;
         reg = <0x8000c000 2000>, <0x8000a000 2000>;
         reg-names = "gpmi-nand", "bch";
-        interrupts = <88>, <41>;
-        interrupt-names = "gpmi-dma", "bch";
-        fsl,gpmi-dma-channel = <4>;
+        interrupts = <41>;
+        interrupt-names = "bch";
+        dmas = <&dma_apbh 4>;
+        dma-names = "rx-tx";
 
         partition@0 {
         ...
diff --git a/Documentation/devicetree/bindings/net/can/atmel-can.txt b/Documentation/devicetree/bindings/net/can/atmel-can.txt
new file mode 100644
index 000000000000..72cf0c5daff4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/atmel-can.txt
@@ -0,0 +1,14 @@
+* AT91 CAN *
+
+Required properties:
+  - compatible: Should be "atmel,at91sam9263-can" or "atmel,at91sam9x5-can"
+  - reg: Should contain CAN controller registers location and length
+  - interrupts: Should contain IRQ line for the CAN controller
+
+Example:
+
+        can0: can@f000c000 {
+                compatbile = "atmel,at91sam9x5-can";
+                reg = <0xf000c000 0x300>;
+                interrupts = <40 4 5>
+        };
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
index ecfdf756d10f..4f2ca6b4a182 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -15,16 +15,22 @@ Required properties:
 - mac_control           : Specifies Default MAC control register content
                           for the specific platform
 - slaves                : Specifies number for slaves
-- cpts_active_slave     : Specifies the slave to use for time stamping
+- active_slave          : Specifies the slave to use for time stamping,
+                          ethtool and SIOCGMIIPHY
 - cpts_clock_mult       : Numerator to convert input clock ticks into nanoseconds
 - cpts_clock_shift      : Denominator to convert input clock ticks into nanoseconds
-- phy_id                : Specifies slave phy id
-- mac-address           : Specifies slave MAC address
 
 Optional properties:
 - ti,hwmods             : Must be "cpgmac0"
 - no_bd_ram             : Must be 0 or 1
 - dual_emac             : Specifies Switch to act as Dual EMAC
+
+Slave Properties:
+Required properties:
+- phy_id                : Specifies slave phy id
+- mac-address           : Specifies slave MAC address
+
+Optional properties:
 - dual_emac_res_vlan    : Specifies VID to be used to segregate the ports
 
 Note: "ti,hwmods" field is used to fetch the base address and irq
@@ -47,7 +53,7 @@ Examples:
                 rx_descs = <64>;
                 mac_control = <0x20>;
                 slaves = <2>;
-                cpts_active_slave = <0>;
+                active_slave = <0>;
                 cpts_clock_mult = <0x80000000>;
                 cpts_clock_shift = <29>;
                 cpsw_emac0: slave@0 {
@@ -73,7 +79,7 @@ Examples:
                 rx_descs = <64>;
                 mac_control = <0x20>;
                 slaves = <2>;
-                cpts_active_slave = <0>;
+                active_slave = <0>;
                 cpts_clock_mult = <0x80000000>;
                 cpts_clock_shift = <29>;
                 cpsw_emac0: slave@0 {
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.txt b/Documentation/devicetree/bindings/net/dsa/dsa.txt
new file mode 100644
index 000000000000..49f4f7ae3f51
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.txt
@@ -0,0 +1,91 @@
+Marvell Distributed Switch Architecture Device Tree Bindings
+------------------------------------------------------------
+
+Required properties:
+- compatible            : Should be "marvell,dsa"
+- #address-cells        : Must be 2, first cell is the address on the MDIO bus
+                          and second cell is the address in the switch tree.
+                          Second cell is used only when cascading/chaining.
+- #size-cells           : Must be 0
+- dsa,ethernet          : Should be a phandle to a valid Ethernet device node
+- dsa,mii-bus           : Should be a phandle to a valid MDIO bus device node
+
+Optionnal properties:
+- interrupts            : property with a value describing the switch
+                          interrupt number (not supported by the driver)
+
+A DSA node can contain multiple switch chips which are therefore child nodes of
+the parent DSA node. The maximum number of allowed child nodes is 4
+(DSA_MAX_SWITCHES).
+Each of these switch child nodes should have the following required properties:
+
+- reg                   : Describes the switch address on the MII bus
+- #address-cells        : Must be 1
+- #size-cells           : Must be 0
+
+A switch may have multiple "port" children nodes
+
+Each port children node must have the following mandatory properties:
+- reg                   : Describes the port address in the switch
+- label                 : Describes the label associated with this port, special
+                          labels are "cpu" to indicate a CPU port and "dsa" to
+                          indicate an uplink/downlink port.
+
+Note that a port labelled "dsa" will imply checking for the uplink phandle
+described below.
+
+Optionnal property:
+- link                  : Should be a phandle to another switch's DSA port.
+                          This property is only used when switches are being
+                          chained/cascaded together.
+
+Example:
+
+        dsa@0 {
+                compatible = "marvell,dsa";
+                #address-cells = <2>;
+                #size-cells = <0>;
+
+                interrupts = <10>;
+                dsa,ethernet = <&ethernet0>;
+                dsa,mii-bus = <&mii_bus0>;
+
+                switch@0 {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        reg = <16 0>;   /* MDIO address 16, switch 0 in tree */
+
+                        port@0 {
+                                reg = <0>;
+                                label = "lan1";
+                        };
+
+                        port@1 {
+                                reg = <1>;
+                                label = "lan2";
+                        };
+
+                        port@5 {
+                                reg = <5>;
+                                label = "cpu";
+                        };
+
+                        switch0uplink: port@6 {
+                                reg = <6>;
+                                label = "dsa";
+                                link = <&switch1uplink>;
+                        };
+                };
+
+                switch@1 {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        reg = <17 1>;   /* MDIO address 17, switch 1 in tree */
+
+                        switch1uplink: port@0 {
+                                reg = <0>;
+                                label = "dsa";
+                                link = <&switch0uplink>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 34e7aafa321c..9417e54c26c0 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -9,6 +9,10 @@ Required properties:
 - compatible: "marvell,orion-mdio"
 - reg: address and length of the SMI register
 
+Optional properties:
+- interrupts: interrupt line number for the SMI error/done interrupt
+- clocks: Phandle to the clock control device and gate bit
+
 The child nodes of the MDIO driver are the individual PHY devices
 connected to this MDIO bus. They must have a "reg" property given the
 PHY address on the MDIO bus.
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
index bc50899e0c81..648d60eb9fd8 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
@@ -1,6 +1,6 @@
 * Atmel AT91 Pinmux Controller
 
-The AT91 Pinmux Controler, enables the IC
+The AT91 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
 8 muxing options (called periph modes). Since different modules require
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index 8edc20e1b09e..2569866c692f 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -5,7 +5,7 @@ controller, and pinmux/control device.
 
 Required properties:
 - compatible: "brcm,bcm2835-gpio"
-- reg: Should contain the physical address of the GPIO module's registes.
+- reg: Should contain the physical address of the GPIO module's registers.
 - gpio-controller: Marks the device node as a GPIO controller.
 - #gpio-cells : Should be two. The first cell is the pin number and the
   second cell is used to specify optional parameters:
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
index ab19e6bc7d3b..bcfdab5d442e 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
@@ -24,9 +24,9 @@ Required properties for iomux controller:
 Required properties for pin configuration node:
 - fsl,pins: two integers array, represents a group of pins mux and config
   setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
-  pin working on a specific function, CONFIG is the pad setting value like
-  pull-up on this pin. Please refer to fsl,<soc>-pinctrl.txt for the valid
-  pins and functions of each SoC.
+  pin working on a specific function, which consists of a tuple of
+  <mux_reg conf_reg input_reg mux_val input_val>.  CONFIG is the pad setting
+  value like pull-up on this pin.
 
 Bits used for CONFIG:
 NO_PAD_CTL(1 << 31): indicate this pin does not need config.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
index 1183f1a3be33..c083dfd25db9 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
@@ -29,956 +29,5 @@ PAD_CTL_DSE_MAX			(2 << 1)
 PAD_CTL_SRE_FAST                (1 << 0)
 PAD_CTL_SRE_SLOW                (0 << 0)
 
-See below for available PIN_FUNC_ID for imx35:
-0 MX35_PAD_CAPTURE__GPT_CAPIN1
-1 MX35_PAD_CAPTURE__GPT_CMPOUT2
-2 MX35_PAD_CAPTURE__CSPI2_SS1
-3 MX35_PAD_CAPTURE__EPIT1_EPITO
-4 MX35_PAD_CAPTURE__CCM_CLK32K
-5 MX35_PAD_CAPTURE__GPIO1_4
-6 MX35_PAD_COMPARE__GPT_CMPOUT1
-7 MX35_PAD_COMPARE__GPT_CAPIN2
-8 MX35_PAD_COMPARE__GPT_CMPOUT3
-9 MX35_PAD_COMPARE__EPIT2_EPITO
-10 MX35_PAD_COMPARE__GPIO1_5
-11 MX35_PAD_COMPARE__SDMA_EXTDMA_2
-12 MX35_PAD_WDOG_RST__WDOG_WDOG_B
-13 MX35_PAD_WDOG_RST__IPU_FLASH_STROBE
-14 MX35_PAD_WDOG_RST__GPIO1_6
-15 MX35_PAD_GPIO1_0__GPIO1_0
-16 MX35_PAD_GPIO1_0__CCM_PMIC_RDY
-17 MX35_PAD_GPIO1_0__OWIRE_LINE
-18 MX35_PAD_GPIO1_0__SDMA_EXTDMA_0
-19 MX35_PAD_GPIO1_1__GPIO1_1
-20 MX35_PAD_GPIO1_1__PWM_PWMO
-21 MX35_PAD_GPIO1_1__CSPI1_SS2
-22 MX35_PAD_GPIO1_1__SCC_TAMPER_DETECT
-23 MX35_PAD_GPIO1_1__SDMA_EXTDMA_1
-24 MX35_PAD_GPIO2_0__GPIO2_0
-25 MX35_PAD_GPIO2_0__USB_TOP_USBOTG_CLK
-26 MX35_PAD_GPIO3_0__GPIO3_0
-27 MX35_PAD_GPIO3_0__USB_TOP_USBH2_CLK
-28 MX35_PAD_RESET_IN_B__CCM_RESET_IN_B
-29 MX35_PAD_POR_B__CCM_POR_B
-30 MX35_PAD_CLKO__CCM_CLKO
-31 MX35_PAD_CLKO__GPIO1_8
-32 MX35_PAD_BOOT_MODE0__CCM_BOOT_MODE_0
-33 MX35_PAD_BOOT_MODE1__CCM_BOOT_MODE_1
-34 MX35_PAD_CLK_MODE0__CCM_CLK_MODE_0
-35 MX35_PAD_CLK_MODE1__CCM_CLK_MODE_1
-36 MX35_PAD_POWER_FAIL__CCM_DSM_WAKEUP_INT_26
-37 MX35_PAD_VSTBY__CCM_VSTBY
-38 MX35_PAD_VSTBY__GPIO1_7
-39 MX35_PAD_A0__EMI_EIM_DA_L_0
-40 MX35_PAD_A1__EMI_EIM_DA_L_1
-41 MX35_PAD_A2__EMI_EIM_DA_L_2
-42 MX35_PAD_A3__EMI_EIM_DA_L_3
-43 MX35_PAD_A4__EMI_EIM_DA_L_4
-44 MX35_PAD_A5__EMI_EIM_DA_L_5
-45 MX35_PAD_A6__EMI_EIM_DA_L_6
-46 MX35_PAD_A7__EMI_EIM_DA_L_7
-47 MX35_PAD_A8__EMI_EIM_DA_H_8
-48 MX35_PAD_A9__EMI_EIM_DA_H_9
-49 MX35_PAD_A10__EMI_EIM_DA_H_10
-50 MX35_PAD_MA10__EMI_MA10
-51 MX35_PAD_A11__EMI_EIM_DA_H_11
-52 MX35_PAD_A12__EMI_EIM_DA_H_12
-53 MX35_PAD_A13__EMI_EIM_DA_H_13
-54 MX35_PAD_A14__EMI_EIM_DA_H2_14
-55 MX35_PAD_A15__EMI_EIM_DA_H2_15
-56 MX35_PAD_A16__EMI_EIM_A_16
-57 MX35_PAD_A17__EMI_EIM_A_17
-58 MX35_PAD_A18__EMI_EIM_A_18
-59 MX35_PAD_A19__EMI_EIM_A_19
-60 MX35_PAD_A20__EMI_EIM_A_20
-61 MX35_PAD_A21__EMI_EIM_A_21
-62 MX35_PAD_A22__EMI_EIM_A_22
-63 MX35_PAD_A23__EMI_EIM_A_23
-64 MX35_PAD_A24__EMI_EIM_A_24
-65 MX35_PAD_A25__EMI_EIM_A_25
-66 MX35_PAD_SDBA1__EMI_EIM_SDBA1
-67 MX35_PAD_SDBA0__EMI_EIM_SDBA0
-68 MX35_PAD_SD0__EMI_DRAM_D_0
-69 MX35_PAD_SD1__EMI_DRAM_D_1
-70 MX35_PAD_SD2__EMI_DRAM_D_2
-71 MX35_PAD_SD3__EMI_DRAM_D_3
-72 MX35_PAD_SD4__EMI_DRAM_D_4
-73 MX35_PAD_SD5__EMI_DRAM_D_5
-74 MX35_PAD_SD6__EMI_DRAM_D_6
-75 MX35_PAD_SD7__EMI_DRAM_D_7
-76 MX35_PAD_SD8__EMI_DRAM_D_8
-77 MX35_PAD_SD9__EMI_DRAM_D_9
-78 MX35_PAD_SD10__EMI_DRAM_D_10
-79 MX35_PAD_SD11__EMI_DRAM_D_11
-80 MX35_PAD_SD12__EMI_DRAM_D_12
-81 MX35_PAD_SD13__EMI_DRAM_D_13
-82 MX35_PAD_SD14__EMI_DRAM_D_14
-83 MX35_PAD_SD15__EMI_DRAM_D_15
-84 MX35_PAD_SD16__EMI_DRAM_D_16
-85 MX35_PAD_SD17__EMI_DRAM_D_17
-86 MX35_PAD_SD18__EMI_DRAM_D_18
-87 MX35_PAD_SD19__EMI_DRAM_D_19
-88 MX35_PAD_SD20__EMI_DRAM_D_20
-89 MX35_PAD_SD21__EMI_DRAM_D_21
-90 MX35_PAD_SD22__EMI_DRAM_D_22
-91 MX35_PAD_SD23__EMI_DRAM_D_23
-92 MX35_PAD_SD24__EMI_DRAM_D_24
-93 MX35_PAD_SD25__EMI_DRAM_D_25
-94 MX35_PAD_SD26__EMI_DRAM_D_26
-95 MX35_PAD_SD27__EMI_DRAM_D_27
-96 MX35_PAD_SD28__EMI_DRAM_D_28
-97 MX35_PAD_SD29__EMI_DRAM_D_29
-98 MX35_PAD_SD30__EMI_DRAM_D_30
-99 MX35_PAD_SD31__EMI_DRAM_D_31
-100 MX35_PAD_DQM0__EMI_DRAM_DQM_0
-101 MX35_PAD_DQM1__EMI_DRAM_DQM_1
-102 MX35_PAD_DQM2__EMI_DRAM_DQM_2
-103 MX35_PAD_DQM3__EMI_DRAM_DQM_3
-104 MX35_PAD_EB0__EMI_EIM_EB0_B
-105 MX35_PAD_EB1__EMI_EIM_EB1_B
-106 MX35_PAD_OE__EMI_EIM_OE
-107 MX35_PAD_CS0__EMI_EIM_CS0
-108 MX35_PAD_CS1__EMI_EIM_CS1
-109 MX35_PAD_CS1__EMI_NANDF_CE3
-110 MX35_PAD_CS2__EMI_EIM_CS2
-111 MX35_PAD_CS3__EMI_EIM_CS3
-112 MX35_PAD_CS4__EMI_EIM_CS4
-113 MX35_PAD_CS4__EMI_DTACK_B
-114 MX35_PAD_CS4__EMI_NANDF_CE1
-115 MX35_PAD_CS4__GPIO1_20
-116 MX35_PAD_CS5__EMI_EIM_CS5
-117 MX35_PAD_CS5__CSPI2_SS2
-118 MX35_PAD_CS5__CSPI1_SS2
-119 MX35_PAD_CS5__EMI_NANDF_CE2
-120 MX35_PAD_CS5__GPIO1_21
-121 MX35_PAD_NF_CE0__EMI_NANDF_CE0
-122 MX35_PAD_NF_CE0__GPIO1_22
-123 MX35_PAD_ECB__EMI_EIM_ECB
-124 MX35_PAD_LBA__EMI_EIM_LBA
-125 MX35_PAD_BCLK__EMI_EIM_BCLK
-126 MX35_PAD_RW__EMI_EIM_RW
-127 MX35_PAD_RAS__EMI_DRAM_RAS
-128 MX35_PAD_CAS__EMI_DRAM_CAS
-129 MX35_PAD_SDWE__EMI_DRAM_SDWE
-130 MX35_PAD_SDCKE0__EMI_DRAM_SDCKE_0
-131 MX35_PAD_SDCKE1__EMI_DRAM_SDCKE_1
-132 MX35_PAD_SDCLK__EMI_DRAM_SDCLK
-133 MX35_PAD_SDQS0__EMI_DRAM_SDQS_0
-134 MX35_PAD_SDQS1__EMI_DRAM_SDQS_1
-135 MX35_PAD_SDQS2__EMI_DRAM_SDQS_2
-136 MX35_PAD_SDQS3__EMI_DRAM_SDQS_3
-137 MX35_PAD_NFWE_B__EMI_NANDF_WE_B
-138 MX35_PAD_NFWE_B__USB_TOP_USBH2_DATA_3
-139 MX35_PAD_NFWE_B__IPU_DISPB_D0_VSYNC
-140 MX35_PAD_NFWE_B__GPIO2_18
-141 MX35_PAD_NFWE_B__ARM11P_TOP_TRACE_0
-142 MX35_PAD_NFRE_B__EMI_NANDF_RE_B
-143 MX35_PAD_NFRE_B__USB_TOP_USBH2_DIR
-144 MX35_PAD_NFRE_B__IPU_DISPB_BCLK
-145 MX35_PAD_NFRE_B__GPIO2_19
-146 MX35_PAD_NFRE_B__ARM11P_TOP_TRACE_1
-147 MX35_PAD_NFALE__EMI_NANDF_ALE
-148 MX35_PAD_NFALE__USB_TOP_USBH2_STP
-149 MX35_PAD_NFALE__IPU_DISPB_CS0
-150 MX35_PAD_NFALE__GPIO2_20
-151 MX35_PAD_NFALE__ARM11P_TOP_TRACE_2
-152 MX35_PAD_NFCLE__EMI_NANDF_CLE
-153 MX35_PAD_NFCLE__USB_TOP_USBH2_NXT
-154 MX35_PAD_NFCLE__IPU_DISPB_PAR_RS
-155 MX35_PAD_NFCLE__GPIO2_21
-156 MX35_PAD_NFCLE__ARM11P_TOP_TRACE_3
-157 MX35_PAD_NFWP_B__EMI_NANDF_WP_B
-158 MX35_PAD_NFWP_B__USB_TOP_USBH2_DATA_7
-159 MX35_PAD_NFWP_B__IPU_DISPB_WR
-160 MX35_PAD_NFWP_B__GPIO2_22
-161 MX35_PAD_NFWP_B__ARM11P_TOP_TRCTL
-162 MX35_PAD_NFRB__EMI_NANDF_RB
-163 MX35_PAD_NFRB__IPU_DISPB_RD
-164 MX35_PAD_NFRB__GPIO2_23
-165 MX35_PAD_NFRB__ARM11P_TOP_TRCLK
-166 MX35_PAD_D15__EMI_EIM_D_15
-167 MX35_PAD_D14__EMI_EIM_D_14
-168 MX35_PAD_D13__EMI_EIM_D_13
-169 MX35_PAD_D12__EMI_EIM_D_12
-170 MX35_PAD_D11__EMI_EIM_D_11
-171 MX35_PAD_D10__EMI_EIM_D_10
-172 MX35_PAD_D9__EMI_EIM_D_9
-173 MX35_PAD_D8__EMI_EIM_D_8
-174 MX35_PAD_D7__EMI_EIM_D_7
-175 MX35_PAD_D6__EMI_EIM_D_6
-176 MX35_PAD_D5__EMI_EIM_D_5
-177 MX35_PAD_D4__EMI_EIM_D_4
-178 MX35_PAD_D3__EMI_EIM_D_3
-179 MX35_PAD_D2__EMI_EIM_D_2
-180 MX35_PAD_D1__EMI_EIM_D_1
-181 MX35_PAD_D0__EMI_EIM_D_0
-182 MX35_PAD_CSI_D8__IPU_CSI_D_8
-183 MX35_PAD_CSI_D8__KPP_COL_0
-184 MX35_PAD_CSI_D8__GPIO1_20
-185 MX35_PAD_CSI_D8__ARM11P_TOP_EVNTBUS_13
-186 MX35_PAD_CSI_D9__IPU_CSI_D_9
-187 MX35_PAD_CSI_D9__KPP_COL_1
-188 MX35_PAD_CSI_D9__GPIO1_21
-189 MX35_PAD_CSI_D9__ARM11P_TOP_EVNTBUS_14
-190 MX35_PAD_CSI_D10__IPU_CSI_D_10
-191 MX35_PAD_CSI_D10__KPP_COL_2
-192 MX35_PAD_CSI_D10__GPIO1_22
-193 MX35_PAD_CSI_D10__ARM11P_TOP_EVNTBUS_15
-194 MX35_PAD_CSI_D11__IPU_CSI_D_11
-195 MX35_PAD_CSI_D11__KPP_COL_3
-196 MX35_PAD_CSI_D11__GPIO1_23
-197 MX35_PAD_CSI_D12__IPU_CSI_D_12
-198 MX35_PAD_CSI_D12__KPP_ROW_0
-199 MX35_PAD_CSI_D12__GPIO1_24
-200 MX35_PAD_CSI_D13__IPU_CSI_D_13
-201 MX35_PAD_CSI_D13__KPP_ROW_1
-202 MX35_PAD_CSI_D13__GPIO1_25
-203 MX35_PAD_CSI_D14__IPU_CSI_D_14
-204 MX35_PAD_CSI_D14__KPP_ROW_2
-205 MX35_PAD_CSI_D14__GPIO1_26
-206 MX35_PAD_CSI_D15__IPU_CSI_D_15
-207 MX35_PAD_CSI_D15__KPP_ROW_3
-208 MX35_PAD_CSI_D15__GPIO1_27
-209 MX35_PAD_CSI_MCLK__IPU_CSI_MCLK
-210 MX35_PAD_CSI_MCLK__GPIO1_28
-211 MX35_PAD_CSI_VSYNC__IPU_CSI_VSYNC
-212 MX35_PAD_CSI_VSYNC__GPIO1_29
-213 MX35_PAD_CSI_HSYNC__IPU_CSI_HSYNC
-214 MX35_PAD_CSI_HSYNC__GPIO1_30
-215 MX35_PAD_CSI_PIXCLK__IPU_CSI_PIXCLK
-216 MX35_PAD_CSI_PIXCLK__GPIO1_31
-217 MX35_PAD_I2C1_CLK__I2C1_SCL
-218 MX35_PAD_I2C1_CLK__GPIO2_24
-219 MX35_PAD_I2C1_CLK__CCM_USB_BYP_CLK
-220 MX35_PAD_I2C1_DAT__I2C1_SDA
-221 MX35_PAD_I2C1_DAT__GPIO2_25
-222 MX35_PAD_I2C2_CLK__I2C2_SCL
-223 MX35_PAD_I2C2_CLK__CAN1_TXCAN
-224 MX35_PAD_I2C2_CLK__USB_TOP_USBH2_PWR
-225 MX35_PAD_I2C2_CLK__GPIO2_26
-226 MX35_PAD_I2C2_CLK__SDMA_DEBUG_BUS_DEVICE_2
-227 MX35_PAD_I2C2_DAT__I2C2_SDA
-228 MX35_PAD_I2C2_DAT__CAN1_RXCAN
-229 MX35_PAD_I2C2_DAT__USB_TOP_USBH2_OC
-230 MX35_PAD_I2C2_DAT__GPIO2_27
-231 MX35_PAD_I2C2_DAT__SDMA_DEBUG_BUS_DEVICE_3
-232 MX35_PAD_STXD4__AUDMUX_AUD4_TXD
-233 MX35_PAD_STXD4__GPIO2_28
-234 MX35_PAD_STXD4__ARM11P_TOP_ARM_COREASID0
-235 MX35_PAD_SRXD4__AUDMUX_AUD4_RXD
-236 MX35_PAD_SRXD4__GPIO2_29
-237 MX35_PAD_SRXD4__ARM11P_TOP_ARM_COREASID1
-238 MX35_PAD_SCK4__AUDMUX_AUD4_TXC
-239 MX35_PAD_SCK4__GPIO2_30
-240 MX35_PAD_SCK4__ARM11P_TOP_ARM_COREASID2
-241 MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS
-242 MX35_PAD_STXFS4__GPIO2_31
-243 MX35_PAD_STXFS4__ARM11P_TOP_ARM_COREASID3
-244 MX35_PAD_STXD5__AUDMUX_AUD5_TXD
-245 MX35_PAD_STXD5__SPDIF_SPDIF_OUT1
-246 MX35_PAD_STXD5__CSPI2_MOSI
-247 MX35_PAD_STXD5__GPIO1_0
-248 MX35_PAD_STXD5__ARM11P_TOP_ARM_COREASID4
-249 MX35_PAD_SRXD5__AUDMUX_AUD5_RXD
-250 MX35_PAD_SRXD5__SPDIF_SPDIF_IN1
-251 MX35_PAD_SRXD5__CSPI2_MISO
-252 MX35_PAD_SRXD5__GPIO1_1
-253 MX35_PAD_SRXD5__ARM11P_TOP_ARM_COREASID5
-254 MX35_PAD_SCK5__AUDMUX_AUD5_TXC
-255 MX35_PAD_SCK5__SPDIF_SPDIF_EXTCLK
-256 MX35_PAD_SCK5__CSPI2_SCLK
-257 MX35_PAD_SCK5__GPIO1_2
-258 MX35_PAD_SCK5__ARM11P_TOP_ARM_COREASID6
-259 MX35_PAD_STXFS5__AUDMUX_AUD5_TXFS
-260 MX35_PAD_STXFS5__CSPI2_RDY
-261 MX35_PAD_STXFS5__GPIO1_3
-262 MX35_PAD_STXFS5__ARM11P_TOP_ARM_COREASID7
-263 MX35_PAD_SCKR__ESAI_SCKR
-264 MX35_PAD_SCKR__GPIO1_4
-265 MX35_PAD_SCKR__ARM11P_TOP_EVNTBUS_10
-266 MX35_PAD_FSR__ESAI_FSR
-267 MX35_PAD_FSR__GPIO1_5
-268 MX35_PAD_FSR__ARM11P_TOP_EVNTBUS_11
-269 MX35_PAD_HCKR__ESAI_HCKR
-270 MX35_PAD_HCKR__AUDMUX_AUD5_RXFS
-271 MX35_PAD_HCKR__CSPI2_SS0
-272 MX35_PAD_HCKR__IPU_FLASH_STROBE
-273 MX35_PAD_HCKR__GPIO1_6
-274 MX35_PAD_HCKR__ARM11P_TOP_EVNTBUS_12
-275 MX35_PAD_SCKT__ESAI_SCKT
-276 MX35_PAD_SCKT__GPIO1_7
-277 MX35_PAD_SCKT__IPU_CSI_D_0
-278 MX35_PAD_SCKT__KPP_ROW_2
-279 MX35_PAD_FST__ESAI_FST
-280 MX35_PAD_FST__GPIO1_8
-281 MX35_PAD_FST__IPU_CSI_D_1
-282 MX35_PAD_FST__KPP_ROW_3
-283 MX35_PAD_HCKT__ESAI_HCKT
-284 MX35_PAD_HCKT__AUDMUX_AUD5_RXC
-285 MX35_PAD_HCKT__GPIO1_9
-286 MX35_PAD_HCKT__IPU_CSI_D_2
-287 MX35_PAD_HCKT__KPP_COL_3
-288 MX35_PAD_TX5_RX0__ESAI_TX5_RX0
-289 MX35_PAD_TX5_RX0__AUDMUX_AUD4_RXC
-290 MX35_PAD_TX5_RX0__CSPI2_SS2
-291 MX35_PAD_TX5_RX0__CAN2_TXCAN
-292 MX35_PAD_TX5_RX0__UART2_DTR
-293 MX35_PAD_TX5_RX0__GPIO1_10
-294 MX35_PAD_TX5_RX0__EMI_M3IF_CHOSEN_MASTER_0
-295 MX35_PAD_TX4_RX1__ESAI_TX4_RX1
-296 MX35_PAD_TX4_RX1__AUDMUX_AUD4_RXFS
-297 MX35_PAD_TX4_RX1__CSPI2_SS3
-298 MX35_PAD_TX4_RX1__CAN2_RXCAN
-299 MX35_PAD_TX4_RX1__UART2_DSR
-300 MX35_PAD_TX4_RX1__GPIO1_11
-301 MX35_PAD_TX4_RX1__IPU_CSI_D_3
-302 MX35_PAD_TX4_RX1__KPP_ROW_0
-303 MX35_PAD_TX3_RX2__ESAI_TX3_RX2
-304 MX35_PAD_TX3_RX2__I2C3_SCL
-305 MX35_PAD_TX3_RX2__EMI_NANDF_CE1
-306 MX35_PAD_TX3_RX2__GPIO1_12
-307 MX35_PAD_TX3_RX2__IPU_CSI_D_4
-308 MX35_PAD_TX3_RX2__KPP_ROW_1
-309 MX35_PAD_TX2_RX3__ESAI_TX2_RX3
-310 MX35_PAD_TX2_RX3__I2C3_SDA
-311 MX35_PAD_TX2_RX3__EMI_NANDF_CE2
-312 MX35_PAD_TX2_RX3__GPIO1_13
-313 MX35_PAD_TX2_RX3__IPU_CSI_D_5
-314 MX35_PAD_TX2_RX3__KPP_COL_0
-315 MX35_PAD_TX1__ESAI_TX1
-316 MX35_PAD_TX1__CCM_PMIC_RDY
-317 MX35_PAD_TX1__CSPI1_SS2
-318 MX35_PAD_TX1__EMI_NANDF_CE3
-319 MX35_PAD_TX1__UART2_RI
-320 MX35_PAD_TX1__GPIO1_14
-321 MX35_PAD_TX1__IPU_CSI_D_6
-322 MX35_PAD_TX1__KPP_COL_1
-323 MX35_PAD_TX0__ESAI_TX0
-324 MX35_PAD_TX0__SPDIF_SPDIF_EXTCLK
-325 MX35_PAD_TX0__CSPI1_SS3
-326 MX35_PAD_TX0__EMI_DTACK_B
-327 MX35_PAD_TX0__UART2_DCD
-328 MX35_PAD_TX0__GPIO1_15
-329 MX35_PAD_TX0__IPU_CSI_D_7
-330 MX35_PAD_TX0__KPP_COL_2
-331 MX35_PAD_CSPI1_MOSI__CSPI1_MOSI
-332 MX35_PAD_CSPI1_MOSI__GPIO1_16
-333 MX35_PAD_CSPI1_MOSI__ECT_CTI_TRIG_OUT1_2
-334 MX35_PAD_CSPI1_MISO__CSPI1_MISO
-335 MX35_PAD_CSPI1_MISO__GPIO1_17
-336 MX35_PAD_CSPI1_MISO__ECT_CTI_TRIG_OUT1_3
-337 MX35_PAD_CSPI1_SS0__CSPI1_SS0
-338 MX35_PAD_CSPI1_SS0__OWIRE_LINE
-339 MX35_PAD_CSPI1_SS0__CSPI2_SS3
-340 MX35_PAD_CSPI1_SS0__GPIO1_18
-341 MX35_PAD_CSPI1_SS0__ECT_CTI_TRIG_OUT1_4
-342 MX35_PAD_CSPI1_SS1__CSPI1_SS1
-343 MX35_PAD_CSPI1_SS1__PWM_PWMO
-344 MX35_PAD_CSPI1_SS1__CCM_CLK32K
-345 MX35_PAD_CSPI1_SS1__GPIO1_19
-346 MX35_PAD_CSPI1_SS1__IPU_DIAGB_29
-347 MX35_PAD_CSPI1_SS1__ECT_CTI_TRIG_OUT1_5
-348 MX35_PAD_CSPI1_SCLK__CSPI1_SCLK
-349 MX35_PAD_CSPI1_SCLK__GPIO3_4
-350 MX35_PAD_CSPI1_SCLK__IPU_DIAGB_30
-351 MX35_PAD_CSPI1_SCLK__EMI_M3IF_CHOSEN_MASTER_1
-352 MX35_PAD_CSPI1_SPI_RDY__CSPI1_RDY
-353 MX35_PAD_CSPI1_SPI_RDY__GPIO3_5
-354 MX35_PAD_CSPI1_SPI_RDY__IPU_DIAGB_31
-355 MX35_PAD_CSPI1_SPI_RDY__EMI_M3IF_CHOSEN_MASTER_2
-356 MX35_PAD_RXD1__UART1_RXD_MUX
-357 MX35_PAD_RXD1__CSPI2_MOSI
-358 MX35_PAD_RXD1__KPP_COL_4
-359 MX35_PAD_RXD1__GPIO3_6
-360 MX35_PAD_RXD1__ARM11P_TOP_EVNTBUS_16
-361 MX35_PAD_TXD1__UART1_TXD_MUX
-362 MX35_PAD_TXD1__CSPI2_MISO
-363 MX35_PAD_TXD1__KPP_COL_5
-364 MX35_PAD_TXD1__GPIO3_7
-365 MX35_PAD_TXD1__ARM11P_TOP_EVNTBUS_17
-366 MX35_PAD_RTS1__UART1_RTS
-367 MX35_PAD_RTS1__CSPI2_SCLK
-368 MX35_PAD_RTS1__I2C3_SCL
-369 MX35_PAD_RTS1__IPU_CSI_D_0
-370 MX35_PAD_RTS1__KPP_COL_6
-371 MX35_PAD_RTS1__GPIO3_8
-372 MX35_PAD_RTS1__EMI_NANDF_CE1
-373 MX35_PAD_RTS1__ARM11P_TOP_EVNTBUS_18
-374 MX35_PAD_CTS1__UART1_CTS
-375 MX35_PAD_CTS1__CSPI2_RDY
-376 MX35_PAD_CTS1__I2C3_SDA
-377 MX35_PAD_CTS1__IPU_CSI_D_1
-378 MX35_PAD_CTS1__KPP_COL_7
-379 MX35_PAD_CTS1__GPIO3_9
-380 MX35_PAD_CTS1__EMI_NANDF_CE2
-381 MX35_PAD_CTS1__ARM11P_TOP_EVNTBUS_19
-382 MX35_PAD_RXD2__UART2_RXD_MUX
-383 MX35_PAD_RXD2__KPP_ROW_4
-384 MX35_PAD_RXD2__GPIO3_10
-385 MX35_PAD_TXD2__UART2_TXD_MUX
-386 MX35_PAD_TXD2__SPDIF_SPDIF_EXTCLK
-387 MX35_PAD_TXD2__KPP_ROW_5
-388 MX35_PAD_TXD2__GPIO3_11
-389 MX35_PAD_RTS2__UART2_RTS
-390 MX35_PAD_RTS2__SPDIF_SPDIF_IN1
-391 MX35_PAD_RTS2__CAN2_RXCAN
-392 MX35_PAD_RTS2__IPU_CSI_D_2
-393 MX35_PAD_RTS2__KPP_ROW_6
-394 MX35_PAD_RTS2__GPIO3_12
-395 MX35_PAD_RTS2__AUDMUX_AUD5_RXC
-396 MX35_PAD_RTS2__UART3_RXD_MUX
-397 MX35_PAD_CTS2__UART2_CTS
-398 MX35_PAD_CTS2__SPDIF_SPDIF_OUT1
-399 MX35_PAD_CTS2__CAN2_TXCAN
-400 MX35_PAD_CTS2__IPU_CSI_D_3
-401 MX35_PAD_CTS2__KPP_ROW_7
-402 MX35_PAD_CTS2__GPIO3_13
-403 MX35_PAD_CTS2__AUDMUX_AUD5_RXFS
-404 MX35_PAD_CTS2__UART3_TXD_MUX
-405 MX35_PAD_RTCK__ARM11P_TOP_RTCK
-406 MX35_PAD_TCK__SJC_TCK
-407 MX35_PAD_TMS__SJC_TMS
-408 MX35_PAD_TDI__SJC_TDI
-409 MX35_PAD_TDO__SJC_TDO
-410 MX35_PAD_TRSTB__SJC_TRSTB
-411 MX35_PAD_DE_B__SJC_DE_B
-412 MX35_PAD_SJC_MOD__SJC_MOD
-413 MX35_PAD_USBOTG_PWR__USB_TOP_USBOTG_PWR
-414 MX35_PAD_USBOTG_PWR__USB_TOP_USBH2_PWR
-415 MX35_PAD_USBOTG_PWR__GPIO3_14
-416 MX35_PAD_USBOTG_OC__USB_TOP_USBOTG_OC
-417 MX35_PAD_USBOTG_OC__USB_TOP_USBH2_OC
-418 MX35_PAD_USBOTG_OC__GPIO3_15
-419 MX35_PAD_LD0__IPU_DISPB_DAT_0
-420 MX35_PAD_LD0__GPIO2_0
-421 MX35_PAD_LD0__SDMA_SDMA_DEBUG_PC_0
-422 MX35_PAD_LD1__IPU_DISPB_DAT_1
-423 MX35_PAD_LD1__GPIO2_1
-424 MX35_PAD_LD1__SDMA_SDMA_DEBUG_PC_1
-425 MX35_PAD_LD2__IPU_DISPB_DAT_2
-426 MX35_PAD_LD2__GPIO2_2
-427 MX35_PAD_LD2__SDMA_SDMA_DEBUG_PC_2
-428 MX35_PAD_LD3__IPU_DISPB_DAT_3
-429 MX35_PAD_LD3__GPIO2_3
-430 MX35_PAD_LD3__SDMA_SDMA_DEBUG_PC_3
-431 MX35_PAD_LD4__IPU_DISPB_DAT_4
-432 MX35_PAD_LD4__GPIO2_4
-433 MX35_PAD_LD4__SDMA_SDMA_DEBUG_PC_4
-434 MX35_PAD_LD5__IPU_DISPB_DAT_5
-435 MX35_PAD_LD5__GPIO2_5
-436 MX35_PAD_LD5__SDMA_SDMA_DEBUG_PC_5
-437 MX35_PAD_LD6__IPU_DISPB_DAT_6
-438 MX35_PAD_LD6__GPIO2_6
-439 MX35_PAD_LD6__SDMA_SDMA_DEBUG_PC_6
-440 MX35_PAD_LD7__IPU_DISPB_DAT_7
-441 MX35_PAD_LD7__GPIO2_7
-442 MX35_PAD_LD7__SDMA_SDMA_DEBUG_PC_7
-443 MX35_PAD_LD8__IPU_DISPB_DAT_8
-444 MX35_PAD_LD8__GPIO2_8
-445 MX35_PAD_LD8__SDMA_SDMA_DEBUG_PC_8
-446 MX35_PAD_LD9__IPU_DISPB_DAT_9
-447 MX35_PAD_LD9__GPIO2_9
-448 MX35_PAD_LD9__SDMA_SDMA_DEBUG_PC_9
-449 MX35_PAD_LD10__IPU_DISPB_DAT_10
-450 MX35_PAD_LD10__GPIO2_10
-451 MX35_PAD_LD10__SDMA_SDMA_DEBUG_PC_10
-452 MX35_PAD_LD11__IPU_DISPB_DAT_11
-453 MX35_PAD_LD11__GPIO2_11
-454 MX35_PAD_LD11__SDMA_SDMA_DEBUG_PC_11
-455 MX35_PAD_LD11__ARM11P_TOP_TRACE_4
-456 MX35_PAD_LD12__IPU_DISPB_DAT_12
-457 MX35_PAD_LD12__GPIO2_12
-458 MX35_PAD_LD12__SDMA_SDMA_DEBUG_PC_12
-459 MX35_PAD_LD12__ARM11P_TOP_TRACE_5
-460 MX35_PAD_LD13__IPU_DISPB_DAT_13
-461 MX35_PAD_LD13__GPIO2_13
-462 MX35_PAD_LD13__SDMA_SDMA_DEBUG_PC_13
-463 MX35_PAD_LD13__ARM11P_TOP_TRACE_6
-464 MX35_PAD_LD14__IPU_DISPB_DAT_14
-465 MX35_PAD_LD14__GPIO2_14
-466 MX35_PAD_LD14__SDMA_SDMA_DEBUG_EVENT_CHANNEL_0
-467 MX35_PAD_LD14__ARM11P_TOP_TRACE_7
-468 MX35_PAD_LD15__IPU_DISPB_DAT_15
-469 MX35_PAD_LD15__GPIO2_15
-470 MX35_PAD_LD15__SDMA_SDMA_DEBUG_EVENT_CHANNEL_1
-471 MX35_PAD_LD15__ARM11P_TOP_TRACE_8
-472 MX35_PAD_LD16__IPU_DISPB_DAT_16
-473 MX35_PAD_LD16__IPU_DISPB_D12_VSYNC
-474 MX35_PAD_LD16__GPIO2_16
-475 MX35_PAD_LD16__SDMA_SDMA_DEBUG_EVENT_CHANNEL_2
-476 MX35_PAD_LD16__ARM11P_TOP_TRACE_9
-477 MX35_PAD_LD17__IPU_DISPB_DAT_17
-478 MX35_PAD_LD17__IPU_DISPB_CS2
-479 MX35_PAD_LD17__GPIO2_17
-480 MX35_PAD_LD17__SDMA_SDMA_DEBUG_EVENT_CHANNEL_3
-481 MX35_PAD_LD17__ARM11P_TOP_TRACE_10
-482 MX35_PAD_LD18__IPU_DISPB_DAT_18
-483 MX35_PAD_LD18__IPU_DISPB_D0_VSYNC
-484 MX35_PAD_LD18__IPU_DISPB_D12_VSYNC
-485 MX35_PAD_LD18__ESDHC3_CMD
-486 MX35_PAD_LD18__USB_TOP_USBOTG_DATA_3
-487 MX35_PAD_LD18__GPIO3_24
-488 MX35_PAD_LD18__SDMA_SDMA_DEBUG_EVENT_CHANNEL_4
-489 MX35_PAD_LD18__ARM11P_TOP_TRACE_11
-490 MX35_PAD_LD19__IPU_DISPB_DAT_19
-491 MX35_PAD_LD19__IPU_DISPB_BCLK
-492 MX35_PAD_LD19__IPU_DISPB_CS1
-493 MX35_PAD_LD19__ESDHC3_CLK
-494 MX35_PAD_LD19__USB_TOP_USBOTG_DIR
-495 MX35_PAD_LD19__GPIO3_25
-496 MX35_PAD_LD19__SDMA_SDMA_DEBUG_EVENT_CHANNEL_5
-497 MX35_PAD_LD19__ARM11P_TOP_TRACE_12
-498 MX35_PAD_LD20__IPU_DISPB_DAT_20
-499 MX35_PAD_LD20__IPU_DISPB_CS0
-500 MX35_PAD_LD20__IPU_DISPB_SD_CLK
-501 MX35_PAD_LD20__ESDHC3_DAT0
-502 MX35_PAD_LD20__GPIO3_26
-503 MX35_PAD_LD20__SDMA_SDMA_DEBUG_CORE_STATUS_3
-504 MX35_PAD_LD20__ARM11P_TOP_TRACE_13
-505 MX35_PAD_LD21__IPU_DISPB_DAT_21
-506 MX35_PAD_LD21__IPU_DISPB_PAR_RS
-507 MX35_PAD_LD21__IPU_DISPB_SER_RS
-508 MX35_PAD_LD21__ESDHC3_DAT1
-509 MX35_PAD_LD21__USB_TOP_USBOTG_STP
-510 MX35_PAD_LD21__GPIO3_27
-511 MX35_PAD_LD21__SDMA_DEBUG_EVENT_CHANNEL_SEL
-512 MX35_PAD_LD21__ARM11P_TOP_TRACE_14
-513 MX35_PAD_LD22__IPU_DISPB_DAT_22
-514 MX35_PAD_LD22__IPU_DISPB_WR
-515 MX35_PAD_LD22__IPU_DISPB_SD_D_I
-516 MX35_PAD_LD22__ESDHC3_DAT2
-517 MX35_PAD_LD22__USB_TOP_USBOTG_NXT
-518 MX35_PAD_LD22__GPIO3_28
-519 MX35_PAD_LD22__SDMA_DEBUG_BUS_ERROR
-520 MX35_PAD_LD22__ARM11P_TOP_TRCTL
-521 MX35_PAD_LD23__IPU_DISPB_DAT_23
-522 MX35_PAD_LD23__IPU_DISPB_RD
-523 MX35_PAD_LD23__IPU_DISPB_SD_D_IO
-524 MX35_PAD_LD23__ESDHC3_DAT3
-525 MX35_PAD_LD23__USB_TOP_USBOTG_DATA_7
-526 MX35_PAD_LD23__GPIO3_29
-527 MX35_PAD_LD23__SDMA_DEBUG_MATCHED_DMBUS
-528 MX35_PAD_LD23__ARM11P_TOP_TRCLK
-529 MX35_PAD_D3_HSYNC__IPU_DISPB_D3_HSYNC
-530 MX35_PAD_D3_HSYNC__IPU_DISPB_SD_D_IO
-531 MX35_PAD_D3_HSYNC__GPIO3_30
-532 MX35_PAD_D3_HSYNC__SDMA_DEBUG_RTBUFFER_WRITE
-533 MX35_PAD_D3_HSYNC__ARM11P_TOP_TRACE_15
-534 MX35_PAD_D3_FPSHIFT__IPU_DISPB_D3_CLK
-535 MX35_PAD_D3_FPSHIFT__IPU_DISPB_SD_CLK
-536 MX35_PAD_D3_FPSHIFT__GPIO3_31
-537 MX35_PAD_D3_FPSHIFT__SDMA_SDMA_DEBUG_CORE_STATUS_0
-538 MX35_PAD_D3_FPSHIFT__ARM11P_TOP_TRACE_16
-539 MX35_PAD_D3_DRDY__IPU_DISPB_D3_DRDY
-540 MX35_PAD_D3_DRDY__IPU_DISPB_SD_D_O
-541 MX35_PAD_D3_DRDY__GPIO1_0
-542 MX35_PAD_D3_DRDY__SDMA_SDMA_DEBUG_CORE_STATUS_1
-543 MX35_PAD_D3_DRDY__ARM11P_TOP_TRACE_17
-544 MX35_PAD_CONTRAST__IPU_DISPB_CONTR
-545 MX35_PAD_CONTRAST__GPIO1_1
-546 MX35_PAD_CONTRAST__SDMA_SDMA_DEBUG_CORE_STATUS_2
-547 MX35_PAD_CONTRAST__ARM11P_TOP_TRACE_18
-548 MX35_PAD_D3_VSYNC__IPU_DISPB_D3_VSYNC
-549 MX35_PAD_D3_VSYNC__IPU_DISPB_CS1
-550 MX35_PAD_D3_VSYNC__GPIO1_2
-551 MX35_PAD_D3_VSYNC__SDMA_DEBUG_YIELD
-552 MX35_PAD_D3_VSYNC__ARM11P_TOP_TRACE_19
-553 MX35_PAD_D3_REV__IPU_DISPB_D3_REV
-554 MX35_PAD_D3_REV__IPU_DISPB_SER_RS
-555 MX35_PAD_D3_REV__GPIO1_3
-556 MX35_PAD_D3_REV__SDMA_DEBUG_BUS_RWB
-557 MX35_PAD_D3_REV__ARM11P_TOP_TRACE_20
-558 MX35_PAD_D3_CLS__IPU_DISPB_D3_CLS
-559 MX35_PAD_D3_CLS__IPU_DISPB_CS2
-560 MX35_PAD_D3_CLS__GPIO1_4
-561 MX35_PAD_D3_CLS__SDMA_DEBUG_BUS_DEVICE_0
-562 MX35_PAD_D3_CLS__ARM11P_TOP_TRACE_21
-563 MX35_PAD_D3_SPL__IPU_DISPB_D3_SPL
-564 MX35_PAD_D3_SPL__IPU_DISPB_D12_VSYNC
-565 MX35_PAD_D3_SPL__GPIO1_5
-566 MX35_PAD_D3_SPL__SDMA_DEBUG_BUS_DEVICE_1
-567 MX35_PAD_D3_SPL__ARM11P_TOP_TRACE_22
-568 MX35_PAD_SD1_CMD__ESDHC1_CMD
-569 MX35_PAD_SD1_CMD__MSHC_SCLK
-570 MX35_PAD_SD1_CMD__IPU_DISPB_D0_VSYNC
-571 MX35_PAD_SD1_CMD__USB_TOP_USBOTG_DATA_4
-572 MX35_PAD_SD1_CMD__GPIO1_6
-573 MX35_PAD_SD1_CMD__ARM11P_TOP_TRCTL
-574 MX35_PAD_SD1_CLK__ESDHC1_CLK
-575 MX35_PAD_SD1_CLK__MSHC_BS
-576 MX35_PAD_SD1_CLK__IPU_DISPB_BCLK
-577 MX35_PAD_SD1_CLK__USB_TOP_USBOTG_DATA_5
-578 MX35_PAD_SD1_CLK__GPIO1_7
-579 MX35_PAD_SD1_CLK__ARM11P_TOP_TRCLK
-580 MX35_PAD_SD1_DATA0__ESDHC1_DAT0
-581 MX35_PAD_SD1_DATA0__MSHC_DATA_0
-582 MX35_PAD_SD1_DATA0__IPU_DISPB_CS0
-583 MX35_PAD_SD1_DATA0__USB_TOP_USBOTG_DATA_6
-584 MX35_PAD_SD1_DATA0__GPIO1_8
-585 MX35_PAD_SD1_DATA0__ARM11P_TOP_TRACE_23
-586 MX35_PAD_SD1_DATA1__ESDHC1_DAT1
-587 MX35_PAD_SD1_DATA1__MSHC_DATA_1
-588 MX35_PAD_SD1_DATA1__IPU_DISPB_PAR_RS
-589 MX35_PAD_SD1_DATA1__USB_TOP_USBOTG_DATA_0
-590 MX35_PAD_SD1_DATA1__GPIO1_9
-591 MX35_PAD_SD1_DATA1__ARM11P_TOP_TRACE_24
-592 MX35_PAD_SD1_DATA2__ESDHC1_DAT2
-593 MX35_PAD_SD1_DATA2__MSHC_DATA_2
-594 MX35_PAD_SD1_DATA2__IPU_DISPB_WR
-595 MX35_PAD_SD1_DATA2__USB_TOP_USBOTG_DATA_1
-596 MX35_PAD_SD1_DATA2__GPIO1_10
-597 MX35_PAD_SD1_DATA2__ARM11P_TOP_TRACE_25
-598 MX35_PAD_SD1_DATA3__ESDHC1_DAT3
-599 MX35_PAD_SD1_DATA3__MSHC_DATA_3
-600 MX35_PAD_SD1_DATA3__IPU_DISPB_RD
-601 MX35_PAD_SD1_DATA3__USB_TOP_USBOTG_DATA_2
-602 MX35_PAD_SD1_DATA3__GPIO1_11
-603 MX35_PAD_SD1_DATA3__ARM11P_TOP_TRACE_26
-604 MX35_PAD_SD2_CMD__ESDHC2_CMD
-605 MX35_PAD_SD2_CMD__I2C3_SCL
-606 MX35_PAD_SD2_CMD__ESDHC1_DAT4
-607 MX35_PAD_SD2_CMD__IPU_CSI_D_2
-608 MX35_PAD_SD2_CMD__USB_TOP_USBH2_DATA_4
-609 MX35_PAD_SD2_CMD__GPIO2_0
-610 MX35_PAD_SD2_CMD__SPDIF_SPDIF_OUT1
-611 MX35_PAD_SD2_CMD__IPU_DISPB_D12_VSYNC
-612 MX35_PAD_SD2_CLK__ESDHC2_CLK
-613 MX35_PAD_SD2_CLK__I2C3_SDA
-614 MX35_PAD_SD2_CLK__ESDHC1_DAT5
-615 MX35_PAD_SD2_CLK__IPU_CSI_D_3
-616 MX35_PAD_SD2_CLK__USB_TOP_USBH2_DATA_5
-617 MX35_PAD_SD2_CLK__GPIO2_1
-618 MX35_PAD_SD2_CLK__SPDIF_SPDIF_IN1
-619 MX35_PAD_SD2_CLK__IPU_DISPB_CS2
-620 MX35_PAD_SD2_DATA0__ESDHC2_DAT0
-621 MX35_PAD_SD2_DATA0__UART3_RXD_MUX
-622 MX35_PAD_SD2_DATA0__ESDHC1_DAT6
-623 MX35_PAD_SD2_DATA0__IPU_CSI_D_4
-624 MX35_PAD_SD2_DATA0__USB_TOP_USBH2_DATA_6
-625 MX35_PAD_SD2_DATA0__GPIO2_2
-626 MX35_PAD_SD2_DATA0__SPDIF_SPDIF_EXTCLK
-627 MX35_PAD_SD2_DATA1__ESDHC2_DAT1
-628 MX35_PAD_SD2_DATA1__UART3_TXD_MUX
-629 MX35_PAD_SD2_DATA1__ESDHC1_DAT7
-630 MX35_PAD_SD2_DATA1__IPU_CSI_D_5
-631 MX35_PAD_SD2_DATA1__USB_TOP_USBH2_DATA_0
-632 MX35_PAD_SD2_DATA1__GPIO2_3
-633 MX35_PAD_SD2_DATA2__ESDHC2_DAT2
-634 MX35_PAD_SD2_DATA2__UART3_RTS
-635 MX35_PAD_SD2_DATA2__CAN1_RXCAN
-636 MX35_PAD_SD2_DATA2__IPU_CSI_D_6
-637 MX35_PAD_SD2_DATA2__USB_TOP_USBH2_DATA_1
-638 MX35_PAD_SD2_DATA2__GPIO2_4
-639 MX35_PAD_SD2_DATA3__ESDHC2_DAT3
-640 MX35_PAD_SD2_DATA3__UART3_CTS
-641 MX35_PAD_SD2_DATA3__CAN1_TXCAN
-642 MX35_PAD_SD2_DATA3__IPU_CSI_D_7
-643 MX35_PAD_SD2_DATA3__USB_TOP_USBH2_DATA_2
-644 MX35_PAD_SD2_DATA3__GPIO2_5
-645 MX35_PAD_ATA_CS0__ATA_CS0
-646 MX35_PAD_ATA_CS0__CSPI1_SS3
-647 MX35_PAD_ATA_CS0__IPU_DISPB_CS1
-648 MX35_PAD_ATA_CS0__GPIO2_6
-649 MX35_PAD_ATA_CS0__IPU_DIAGB_0
-650 MX35_PAD_ATA_CS0__ARM11P_TOP_MAX1_HMASTER_0
-651 MX35_PAD_ATA_CS1__ATA_CS1
-652 MX35_PAD_ATA_CS1__IPU_DISPB_CS2
-653 MX35_PAD_ATA_CS1__CSPI2_SS0
-654 MX35_PAD_ATA_CS1__GPIO2_7
-655 MX35_PAD_ATA_CS1__IPU_DIAGB_1
-656 MX35_PAD_ATA_CS1__ARM11P_TOP_MAX1_HMASTER_1
-657 MX35_PAD_ATA_DIOR__ATA_DIOR
-658 MX35_PAD_ATA_DIOR__ESDHC3_DAT0
-659 MX35_PAD_ATA_DIOR__USB_TOP_USBOTG_DIR
-660 MX35_PAD_ATA_DIOR__IPU_DISPB_BE0
-661 MX35_PAD_ATA_DIOR__CSPI2_SS1
-662 MX35_PAD_ATA_DIOR__GPIO2_8
-663 MX35_PAD_ATA_DIOR__IPU_DIAGB_2
-664 MX35_PAD_ATA_DIOR__ARM11P_TOP_MAX1_HMASTER_2
-665 MX35_PAD_ATA_DIOW__ATA_DIOW
-666 MX35_PAD_ATA_DIOW__ESDHC3_DAT1
-667 MX35_PAD_ATA_DIOW__USB_TOP_USBOTG_STP
-668 MX35_PAD_ATA_DIOW__IPU_DISPB_BE1
-669 MX35_PAD_ATA_DIOW__CSPI2_MOSI
-670 MX35_PAD_ATA_DIOW__GPIO2_9
-671 MX35_PAD_ATA_DIOW__IPU_DIAGB_3
-672 MX35_PAD_ATA_DIOW__ARM11P_TOP_MAX1_HMASTER_3
-673 MX35_PAD_ATA_DMACK__ATA_DMACK
-674 MX35_PAD_ATA_DMACK__ESDHC3_DAT2
-675 MX35_PAD_ATA_DMACK__USB_TOP_USBOTG_NXT
-676 MX35_PAD_ATA_DMACK__CSPI2_MISO
-677 MX35_PAD_ATA_DMACK__GPIO2_10
-678 MX35_PAD_ATA_DMACK__IPU_DIAGB_4
-679 MX35_PAD_ATA_DMACK__ARM11P_TOP_MAX0_HMASTER_0
-680 MX35_PAD_ATA_RESET_B__ATA_RESET_B
-681 MX35_PAD_ATA_RESET_B__ESDHC3_DAT3
-682 MX35_PAD_ATA_RESET_B__USB_TOP_USBOTG_DATA_0
-683 MX35_PAD_ATA_RESET_B__IPU_DISPB_SD_D_O
-684 MX35_PAD_ATA_RESET_B__CSPI2_RDY
-685 MX35_PAD_ATA_RESET_B__GPIO2_11
-686 MX35_PAD_ATA_RESET_B__IPU_DIAGB_5
-687 MX35_PAD_ATA_RESET_B__ARM11P_TOP_MAX0_HMASTER_1
-688 MX35_PAD_ATA_IORDY__ATA_IORDY
-689 MX35_PAD_ATA_IORDY__ESDHC3_DAT4
-690 MX35_PAD_ATA_IORDY__USB_TOP_USBOTG_DATA_1
-691 MX35_PAD_ATA_IORDY__IPU_DISPB_SD_D_IO
-692 MX35_PAD_ATA_IORDY__ESDHC2_DAT4
-693 MX35_PAD_ATA_IORDY__GPIO2_12
-694 MX35_PAD_ATA_IORDY__IPU_DIAGB_6
-695 MX35_PAD_ATA_IORDY__ARM11P_TOP_MAX0_HMASTER_2
-696 MX35_PAD_ATA_DATA0__ATA_DATA_0
-697 MX35_PAD_ATA_DATA0__ESDHC3_DAT5
-698 MX35_PAD_ATA_DATA0__USB_TOP_USBOTG_DATA_2
-699 MX35_PAD_ATA_DATA0__IPU_DISPB_D12_VSYNC
-700 MX35_PAD_ATA_DATA0__ESDHC2_DAT5
-701 MX35_PAD_ATA_DATA0__GPIO2_13
-702 MX35_PAD_ATA_DATA0__IPU_DIAGB_7
-703 MX35_PAD_ATA_DATA0__ARM11P_TOP_MAX0_HMASTER_3
-704 MX35_PAD_ATA_DATA1__ATA_DATA_1
-705 MX35_PAD_ATA_DATA1__ESDHC3_DAT6
-706 MX35_PAD_ATA_DATA1__USB_TOP_USBOTG_DATA_3
-707 MX35_PAD_ATA_DATA1__IPU_DISPB_SD_CLK
-708 MX35_PAD_ATA_DATA1__ESDHC2_DAT6
-709 MX35_PAD_ATA_DATA1__GPIO2_14
-710 MX35_PAD_ATA_DATA1__IPU_DIAGB_8
-711 MX35_PAD_ATA_DATA1__ARM11P_TOP_TRACE_27
-712 MX35_PAD_ATA_DATA2__ATA_DATA_2
-713 MX35_PAD_ATA_DATA2__ESDHC3_DAT7
-714 MX35_PAD_ATA_DATA2__USB_TOP_USBOTG_DATA_4
-715 MX35_PAD_ATA_DATA2__IPU_DISPB_SER_RS
-716 MX35_PAD_ATA_DATA2__ESDHC2_DAT7
-717 MX35_PAD_ATA_DATA2__GPIO2_15
-718 MX35_PAD_ATA_DATA2__IPU_DIAGB_9
-719 MX35_PAD_ATA_DATA2__ARM11P_TOP_TRACE_28
-720 MX35_PAD_ATA_DATA3__ATA_DATA_3
-721 MX35_PAD_ATA_DATA3__ESDHC3_CLK
-722 MX35_PAD_ATA_DATA3__USB_TOP_USBOTG_DATA_5
-723 MX35_PAD_ATA_DATA3__CSPI2_SCLK
-724 MX35_PAD_ATA_DATA3__GPIO2_16
-725 MX35_PAD_ATA_DATA3__IPU_DIAGB_10
-726 MX35_PAD_ATA_DATA3__ARM11P_TOP_TRACE_29
-727 MX35_PAD_ATA_DATA4__ATA_DATA_4
-728 MX35_PAD_ATA_DATA4__ESDHC3_CMD
-729 MX35_PAD_ATA_DATA4__USB_TOP_USBOTG_DATA_6
-730 MX35_PAD_ATA_DATA4__GPIO2_17
-731 MX35_PAD_ATA_DATA4__IPU_DIAGB_11
-732 MX35_PAD_ATA_DATA4__ARM11P_TOP_TRACE_30
-733 MX35_PAD_ATA_DATA5__ATA_DATA_5
-734 MX35_PAD_ATA_DATA5__USB_TOP_USBOTG_DATA_7
-735 MX35_PAD_ATA_DATA5__GPIO2_18
-736 MX35_PAD_ATA_DATA5__IPU_DIAGB_12
-737 MX35_PAD_ATA_DATA5__ARM11P_TOP_TRACE_31
-738 MX35_PAD_ATA_DATA6__ATA_DATA_6
-739 MX35_PAD_ATA_DATA6__CAN1_TXCAN
-740 MX35_PAD_ATA_DATA6__UART1_DTR
-741 MX35_PAD_ATA_DATA6__AUDMUX_AUD6_TXD
-742 MX35_PAD_ATA_DATA6__GPIO2_19
-743 MX35_PAD_ATA_DATA6__IPU_DIAGB_13
-744 MX35_PAD_ATA_DATA7__ATA_DATA_7
-745 MX35_PAD_ATA_DATA7__CAN1_RXCAN
-746 MX35_PAD_ATA_DATA7__UART1_DSR
-747 MX35_PAD_ATA_DATA7__AUDMUX_AUD6_RXD
-748 MX35_PAD_ATA_DATA7__GPIO2_20
-749 MX35_PAD_ATA_DATA7__IPU_DIAGB_14
-750 MX35_PAD_ATA_DATA8__ATA_DATA_8
-751 MX35_PAD_ATA_DATA8__UART3_RTS
-752 MX35_PAD_ATA_DATA8__UART1_RI
-753 MX35_PAD_ATA_DATA8__AUDMUX_AUD6_TXC
-754 MX35_PAD_ATA_DATA8__GPIO2_21
-755 MX35_PAD_ATA_DATA8__IPU_DIAGB_15
-756 MX35_PAD_ATA_DATA9__ATA_DATA_9
-757 MX35_PAD_ATA_DATA9__UART3_CTS
-758 MX35_PAD_ATA_DATA9__UART1_DCD
-759 MX35_PAD_ATA_DATA9__AUDMUX_AUD6_TXFS
-760 MX35_PAD_ATA_DATA9__GPIO2_22
-761 MX35_PAD_ATA_DATA9__IPU_DIAGB_16
-762 MX35_PAD_ATA_DATA10__ATA_DATA_10
-763 MX35_PAD_ATA_DATA10__UART3_RXD_MUX
-764 MX35_PAD_ATA_DATA10__AUDMUX_AUD6_RXC
-765 MX35_PAD_ATA_DATA10__GPIO2_23
-766 MX35_PAD_ATA_DATA10__IPU_DIAGB_17
-767 MX35_PAD_ATA_DATA11__ATA_DATA_11
-768 MX35_PAD_ATA_DATA11__UART3_TXD_MUX
-769 MX35_PAD_ATA_DATA11__AUDMUX_AUD6_RXFS
-770 MX35_PAD_ATA_DATA11__GPIO2_24
-771 MX35_PAD_ATA_DATA11__IPU_DIAGB_18
-772 MX35_PAD_ATA_DATA12__ATA_DATA_12
-773 MX35_PAD_ATA_DATA12__I2C3_SCL
-774 MX35_PAD_ATA_DATA12__GPIO2_25
-775 MX35_PAD_ATA_DATA12__IPU_DIAGB_19
-776 MX35_PAD_ATA_DATA13__ATA_DATA_13
-777 MX35_PAD_ATA_DATA13__I2C3_SDA
-778 MX35_PAD_ATA_DATA13__GPIO2_26
-779 MX35_PAD_ATA_DATA13__IPU_DIAGB_20
-780 MX35_PAD_ATA_DATA14__ATA_DATA_14
-781 MX35_PAD_ATA_DATA14__IPU_CSI_D_0
-782 MX35_PAD_ATA_DATA14__KPP_ROW_0
-783 MX35_PAD_ATA_DATA14__GPIO2_27
-784 MX35_PAD_ATA_DATA14__IPU_DIAGB_21
-785 MX35_PAD_ATA_DATA15__ATA_DATA_15
-786 MX35_PAD_ATA_DATA15__IPU_CSI_D_1
-787 MX35_PAD_ATA_DATA15__KPP_ROW_1
-788 MX35_PAD_ATA_DATA15__GPIO2_28
-789 MX35_PAD_ATA_DATA15__IPU_DIAGB_22
-790 MX35_PAD_ATA_INTRQ__ATA_INTRQ
-791 MX35_PAD_ATA_INTRQ__IPU_CSI_D_2
-792 MX35_PAD_ATA_INTRQ__KPP_ROW_2
-793 MX35_PAD_ATA_INTRQ__GPIO2_29
-794 MX35_PAD_ATA_INTRQ__IPU_DIAGB_23
-795 MX35_PAD_ATA_BUFF_EN__ATA_BUFFER_EN
-796 MX35_PAD_ATA_BUFF_EN__IPU_CSI_D_3
-797 MX35_PAD_ATA_BUFF_EN__KPP_ROW_3
-798 MX35_PAD_ATA_BUFF_EN__GPIO2_30
-799 MX35_PAD_ATA_BUFF_EN__IPU_DIAGB_24
-800 MX35_PAD_ATA_DMARQ__ATA_DMARQ
-801 MX35_PAD_ATA_DMARQ__IPU_CSI_D_4
-802 MX35_PAD_ATA_DMARQ__KPP_COL_0
-803 MX35_PAD_ATA_DMARQ__GPIO2_31
-804 MX35_PAD_ATA_DMARQ__IPU_DIAGB_25
-805 MX35_PAD_ATA_DMARQ__ECT_CTI_TRIG_IN1_4
-806 MX35_PAD_ATA_DA0__ATA_DA_0
-807 MX35_PAD_ATA_DA0__IPU_CSI_D_5
-808 MX35_PAD_ATA_DA0__KPP_COL_1
-809 MX35_PAD_ATA_DA0__GPIO3_0
-810 MX35_PAD_ATA_DA0__IPU_DIAGB_26
-811 MX35_PAD_ATA_DA0__ECT_CTI_TRIG_IN1_5
-812 MX35_PAD_ATA_DA1__ATA_DA_1
-813 MX35_PAD_ATA_DA1__IPU_CSI_D_6
-814 MX35_PAD_ATA_DA1__KPP_COL_2
-815 MX35_PAD_ATA_DA1__GPIO3_1
-816 MX35_PAD_ATA_DA1__IPU_DIAGB_27
-817 MX35_PAD_ATA_DA1__ECT_CTI_TRIG_IN1_6
-818 MX35_PAD_ATA_DA2__ATA_DA_2
-819 MX35_PAD_ATA_DA2__IPU_CSI_D_7
-820 MX35_PAD_ATA_DA2__KPP_COL_3
-821 MX35_PAD_ATA_DA2__GPIO3_2
-822 MX35_PAD_ATA_DA2__IPU_DIAGB_28
-823 MX35_PAD_ATA_DA2__ECT_CTI_TRIG_IN1_7
-824 MX35_PAD_MLB_CLK__MLB_MLBCLK
-825 MX35_PAD_MLB_CLK__GPIO3_3
-826 MX35_PAD_MLB_DAT__MLB_MLBDAT
-827 MX35_PAD_MLB_DAT__GPIO3_4
-828 MX35_PAD_MLB_SIG__MLB_MLBSIG
-829 MX35_PAD_MLB_SIG__GPIO3_5
-830 MX35_PAD_FEC_TX_CLK__FEC_TX_CLK
-831 MX35_PAD_FEC_TX_CLK__ESDHC1_DAT4
-832 MX35_PAD_FEC_TX_CLK__UART3_RXD_MUX
-833 MX35_PAD_FEC_TX_CLK__USB_TOP_USBH2_DIR
-834 MX35_PAD_FEC_TX_CLK__CSPI2_MOSI
-835 MX35_PAD_FEC_TX_CLK__GPIO3_6
-836 MX35_PAD_FEC_TX_CLK__IPU_DISPB_D12_VSYNC
-837 MX35_PAD_FEC_TX_CLK__ARM11P_TOP_EVNTBUS_0
-838 MX35_PAD_FEC_RX_CLK__FEC_RX_CLK
-839 MX35_PAD_FEC_RX_CLK__ESDHC1_DAT5
-840 MX35_PAD_FEC_RX_CLK__UART3_TXD_MUX
-841 MX35_PAD_FEC_RX_CLK__USB_TOP_USBH2_STP
-842 MX35_PAD_FEC_RX_CLK__CSPI2_MISO
-843 MX35_PAD_FEC_RX_CLK__GPIO3_7
-844 MX35_PAD_FEC_RX_CLK__IPU_DISPB_SD_D_I
-845 MX35_PAD_FEC_RX_CLK__ARM11P_TOP_EVNTBUS_1
-846 MX35_PAD_FEC_RX_DV__FEC_RX_DV
-847 MX35_PAD_FEC_RX_DV__ESDHC1_DAT6
-848 MX35_PAD_FEC_RX_DV__UART3_RTS
-849 MX35_PAD_FEC_RX_DV__USB_TOP_USBH2_NXT
-850 MX35_PAD_FEC_RX_DV__CSPI2_SCLK
-851 MX35_PAD_FEC_RX_DV__GPIO3_8
-852 MX35_PAD_FEC_RX_DV__IPU_DISPB_SD_CLK
-853 MX35_PAD_FEC_RX_DV__ARM11P_TOP_EVNTBUS_2
-854 MX35_PAD_FEC_COL__FEC_COL
-855 MX35_PAD_FEC_COL__ESDHC1_DAT7
-856 MX35_PAD_FEC_COL__UART3_CTS
-857 MX35_PAD_FEC_COL__USB_TOP_USBH2_DATA_0
-858 MX35_PAD_FEC_COL__CSPI2_RDY
-859 MX35_PAD_FEC_COL__GPIO3_9
-860 MX35_PAD_FEC_COL__IPU_DISPB_SER_RS
-861 MX35_PAD_FEC_COL__ARM11P_TOP_EVNTBUS_3
-862 MX35_PAD_FEC_RDATA0__FEC_RDATA_0
-863 MX35_PAD_FEC_RDATA0__PWM_PWMO
-864 MX35_PAD_FEC_RDATA0__UART3_DTR
-865 MX35_PAD_FEC_RDATA0__USB_TOP_USBH2_DATA_1
-866 MX35_PAD_FEC_RDATA0__CSPI2_SS0
-867 MX35_PAD_FEC_RDATA0__GPIO3_10
-868 MX35_PAD_FEC_RDATA0__IPU_DISPB_CS1
-869 MX35_PAD_FEC_RDATA0__ARM11P_TOP_EVNTBUS_4
-870 MX35_PAD_FEC_TDATA0__FEC_TDATA_0
-871 MX35_PAD_FEC_TDATA0__SPDIF_SPDIF_OUT1
-872 MX35_PAD_FEC_TDATA0__UART3_DSR
-873 MX35_PAD_FEC_TDATA0__USB_TOP_USBH2_DATA_2
-874 MX35_PAD_FEC_TDATA0__CSPI2_SS1
-875 MX35_PAD_FEC_TDATA0__GPIO3_11
-876 MX35_PAD_FEC_TDATA0__IPU_DISPB_CS0
-877 MX35_PAD_FEC_TDATA0__ARM11P_TOP_EVNTBUS_5
-878 MX35_PAD_FEC_TX_EN__FEC_TX_EN
-879 MX35_PAD_FEC_TX_EN__SPDIF_SPDIF_IN1
-880 MX35_PAD_FEC_TX_EN__UART3_RI
-881 MX35_PAD_FEC_TX_EN__USB_TOP_USBH2_DATA_3
-882 MX35_PAD_FEC_TX_EN__GPIO3_12
-883 MX35_PAD_FEC_TX_EN__IPU_DISPB_PAR_RS
-884 MX35_PAD_FEC_TX_EN__ARM11P_TOP_EVNTBUS_6
-885 MX35_PAD_FEC_MDC__FEC_MDC
-886 MX35_PAD_FEC_MDC__CAN2_TXCAN
-887 MX35_PAD_FEC_MDC__UART3_DCD
-888 MX35_PAD_FEC_MDC__USB_TOP_USBH2_DATA_4
-889 MX35_PAD_FEC_MDC__GPIO3_13
-890 MX35_PAD_FEC_MDC__IPU_DISPB_WR
-891 MX35_PAD_FEC_MDC__ARM11P_TOP_EVNTBUS_7
-892 MX35_PAD_FEC_MDIO__FEC_MDIO
-893 MX35_PAD_FEC_MDIO__CAN2_RXCAN
-894 MX35_PAD_FEC_MDIO__USB_TOP_USBH2_DATA_5
-895 MX35_PAD_FEC_MDIO__GPIO3_14
-896 MX35_PAD_FEC_MDIO__IPU_DISPB_RD
-897 MX35_PAD_FEC_MDIO__ARM11P_TOP_EVNTBUS_8
-898 MX35_PAD_FEC_TX_ERR__FEC_TX_ERR
-899 MX35_PAD_FEC_TX_ERR__OWIRE_LINE
-900 MX35_PAD_FEC_TX_ERR__SPDIF_SPDIF_EXTCLK
-901 MX35_PAD_FEC_TX_ERR__USB_TOP_USBH2_DATA_6
-902 MX35_PAD_FEC_TX_ERR__GPIO3_15
-903 MX35_PAD_FEC_TX_ERR__IPU_DISPB_D0_VSYNC
-904 MX35_PAD_FEC_TX_ERR__ARM11P_TOP_EVNTBUS_9
-905 MX35_PAD_FEC_RX_ERR__FEC_RX_ERR
-906 MX35_PAD_FEC_RX_ERR__IPU_CSI_D_0
-907 MX35_PAD_FEC_RX_ERR__USB_TOP_USBH2_DATA_7
-908 MX35_PAD_FEC_RX_ERR__KPP_COL_4
-909 MX35_PAD_FEC_RX_ERR__GPIO3_16
-910 MX35_PAD_FEC_RX_ERR__IPU_DISPB_SD_D_IO
-911 MX35_PAD_FEC_CRS__FEC_CRS
-912 MX35_PAD_FEC_CRS__IPU_CSI_D_1
-913 MX35_PAD_FEC_CRS__USB_TOP_USBH2_PWR
-914 MX35_PAD_FEC_CRS__KPP_COL_5
-915 MX35_PAD_FEC_CRS__GPIO3_17
-916 MX35_PAD_FEC_CRS__IPU_FLASH_STROBE
-917 MX35_PAD_FEC_RDATA1__FEC_RDATA_1
-918 MX35_PAD_FEC_RDATA1__IPU_CSI_D_2
-919 MX35_PAD_FEC_RDATA1__AUDMUX_AUD6_RXC
-920 MX35_PAD_FEC_RDATA1__USB_TOP_USBH2_OC
-921 MX35_PAD_FEC_RDATA1__KPP_COL_6
-922 MX35_PAD_FEC_RDATA1__GPIO3_18
-923 MX35_PAD_FEC_RDATA1__IPU_DISPB_BE0
-924 MX35_PAD_FEC_TDATA1__FEC_TDATA_1
-925 MX35_PAD_FEC_TDATA1__IPU_CSI_D_3
-926 MX35_PAD_FEC_TDATA1__AUDMUX_AUD6_RXFS
-927 MX35_PAD_FEC_TDATA1__KPP_COL_7
-928 MX35_PAD_FEC_TDATA1__GPIO3_19
-929 MX35_PAD_FEC_TDATA1__IPU_DISPB_BE1
-930 MX35_PAD_FEC_RDATA2__FEC_RDATA_2
-931 MX35_PAD_FEC_RDATA2__IPU_CSI_D_4
-932 MX35_PAD_FEC_RDATA2__AUDMUX_AUD6_TXD
-933 MX35_PAD_FEC_RDATA2__KPP_ROW_4
-934 MX35_PAD_FEC_RDATA2__GPIO3_20
-935 MX35_PAD_FEC_TDATA2__FEC_TDATA_2
-936 MX35_PAD_FEC_TDATA2__IPU_CSI_D_5
-937 MX35_PAD_FEC_TDATA2__AUDMUX_AUD6_RXD
-938 MX35_PAD_FEC_TDATA2__KPP_ROW_5
-939 MX35_PAD_FEC_TDATA2__GPIO3_21
-940 MX35_PAD_FEC_RDATA3__FEC_RDATA_3
-941 MX35_PAD_FEC_RDATA3__IPU_CSI_D_6
-942 MX35_PAD_FEC_RDATA3__AUDMUX_AUD6_TXC
-943 MX35_PAD_FEC_RDATA3__KPP_ROW_6
-944 MX35_PAD_FEC_RDATA3__GPIO3_22
-945 MX35_PAD_FEC_TDATA3__FEC_TDATA_3
-946 MX35_PAD_FEC_TDATA3__IPU_CSI_D_7
-947 MX35_PAD_FEC_TDATA3__AUDMUX_AUD6_TXFS
-948 MX35_PAD_FEC_TDATA3__KPP_ROW_7
-949 MX35_PAD_FEC_TDATA3__GPIO3_23
-950 MX35_PAD_EXT_ARMCLK__CCM_EXT_ARMCLK
-951 MX35_PAD_TEST_MODE__TCU_TEST_MODE
+Refer to imx35-pinfunc.h in device tree source folder for all available
+imx35 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
index b96fa4c31745..4d1408fcc99c 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
@@ -28,760 +28,5 @@ PAD_CTL_DSE_MAX			(3 << 1)
 PAD_CTL_SRE_FAST                (1 << 0)
 PAD_CTL_SRE_SLOW                (0 << 0)
 
-See below for available PIN_FUNC_ID for imx51:
-MX51_PAD_EIM_D16__AUD4_RXFS                     0
-MX51_PAD_EIM_D16__AUD5_TXD                      1
-MX51_PAD_EIM_D16__EIM_D16                       2
-MX51_PAD_EIM_D16__GPIO2_0                       3
-MX51_PAD_EIM_D16__I2C1_SDA                      4
-MX51_PAD_EIM_D16__UART2_CTS                     5
-MX51_PAD_EIM_D16__USBH2_DATA0                   6
-MX51_PAD_EIM_D17__AUD5_RXD                      7
-MX51_PAD_EIM_D17__EIM_D17                       8
-MX51_PAD_EIM_D17__GPIO2_1                       9
-MX51_PAD_EIM_D17__UART2_RXD                     10
-MX51_PAD_EIM_D17__UART3_CTS                     11
-MX51_PAD_EIM_D17__USBH2_DATA1                   12
-MX51_PAD_EIM_D18__AUD5_TXC                      13
-MX51_PAD_EIM_D18__EIM_D18                       14
-MX51_PAD_EIM_D18__GPIO2_2                       15
-MX51_PAD_EIM_D18__UART2_TXD                     16
-MX51_PAD_EIM_D18__UART3_RTS                     17
-MX51_PAD_EIM_D18__USBH2_DATA2                   18
-MX51_PAD_EIM_D19__AUD4_RXC                      19
-MX51_PAD_EIM_D19__AUD5_TXFS                     20
-MX51_PAD_EIM_D19__EIM_D19                       21
-MX51_PAD_EIM_D19__GPIO2_3                       22
-MX51_PAD_EIM_D19__I2C1_SCL                      23
-MX51_PAD_EIM_D19__UART2_RTS                     24
-MX51_PAD_EIM_D19__USBH2_DATA3                   25
-MX51_PAD_EIM_D20__AUD4_TXD                      26
-MX51_PAD_EIM_D20__EIM_D20                       27
-MX51_PAD_EIM_D20__GPIO2_4                       28
-MX51_PAD_EIM_D20__SRTC_ALARM_DEB                29
-MX51_PAD_EIM_D20__USBH2_DATA4                   30
-MX51_PAD_EIM_D21__AUD4_RXD                      31
-MX51_PAD_EIM_D21__EIM_D21                       32
-MX51_PAD_EIM_D21__GPIO2_5                       33
-MX51_PAD_EIM_D21__SRTC_ALARM_DEB                34
-MX51_PAD_EIM_D21__USBH2_DATA5                   35
-MX51_PAD_EIM_D22__AUD4_TXC                      36
-MX51_PAD_EIM_D22__EIM_D22                       37
-MX51_PAD_EIM_D22__GPIO2_6                       38
-MX51_PAD_EIM_D22__USBH2_DATA6                   39
-MX51_PAD_EIM_D23__AUD4_TXFS                     40
-MX51_PAD_EIM_D23__EIM_D23                       41
-MX51_PAD_EIM_D23__GPIO2_7                       42
-MX51_PAD_EIM_D23__SPDIF_OUT1                    43
-MX51_PAD_EIM_D23__USBH2_DATA7                   44
-MX51_PAD_EIM_D24__AUD6_RXFS                     45
-MX51_PAD_EIM_D24__EIM_D24                       46
-MX51_PAD_EIM_D24__GPIO2_8                       47
-MX51_PAD_EIM_D24__I2C2_SDA                      48
-MX51_PAD_EIM_D24__UART3_CTS                     49
-MX51_PAD_EIM_D24__USBOTG_DATA0                  50
-MX51_PAD_EIM_D25__EIM_D25                       51
-MX51_PAD_EIM_D25__KEY_COL6                      52
-MX51_PAD_EIM_D25__UART2_CTS                     53
-MX51_PAD_EIM_D25__UART3_RXD                     54
-MX51_PAD_EIM_D25__USBOTG_DATA1                  55
-MX51_PAD_EIM_D26__EIM_D26                       56
-MX51_PAD_EIM_D26__KEY_COL7                      57
-MX51_PAD_EIM_D26__UART2_RTS                     58
-MX51_PAD_EIM_D26__UART3_TXD                     59
-MX51_PAD_EIM_D26__USBOTG_DATA2                  60
-MX51_PAD_EIM_D27__AUD6_RXC                      61
-MX51_PAD_EIM_D27__EIM_D27                       62
-MX51_PAD_EIM_D27__GPIO2_9                       63
-MX51_PAD_EIM_D27__I2C2_SCL                      64
-MX51_PAD_EIM_D27__UART3_RTS                     65
-MX51_PAD_EIM_D27__USBOTG_DATA3                  66
-MX51_PAD_EIM_D28__AUD6_TXD                      67
-MX51_PAD_EIM_D28__EIM_D28                       68
-MX51_PAD_EIM_D28__KEY_ROW4                      69
-MX51_PAD_EIM_D28__USBOTG_DATA4                  70
-MX51_PAD_EIM_D29__AUD6_RXD                      71
-MX51_PAD_EIM_D29__EIM_D29                       72
-MX51_PAD_EIM_D29__KEY_ROW5                      73
-MX51_PAD_EIM_D29__USBOTG_DATA5                  74
-MX51_PAD_EIM_D30__AUD6_TXC                      75
-MX51_PAD_EIM_D30__EIM_D30                       76
-MX51_PAD_EIM_D30__KEY_ROW6                      77
-MX51_PAD_EIM_D30__USBOTG_DATA6                  78
-MX51_PAD_EIM_D31__AUD6_TXFS                     79
-MX51_PAD_EIM_D31__EIM_D31                       80
-MX51_PAD_EIM_D31__KEY_ROW7                      81
-MX51_PAD_EIM_D31__USBOTG_DATA7                  82
-MX51_PAD_EIM_A16__EIM_A16                       83
-MX51_PAD_EIM_A16__GPIO2_10                      84
-MX51_PAD_EIM_A16__OSC_FREQ_SEL0                 85
-MX51_PAD_EIM_A17__EIM_A17                       86
-MX51_PAD_EIM_A17__GPIO2_11                      87
-MX51_PAD_EIM_A17__OSC_FREQ_SEL1                 88
-MX51_PAD_EIM_A18__BOOT_LPB0                     89
-MX51_PAD_EIM_A18__EIM_A18                       90
-MX51_PAD_EIM_A18__GPIO2_12                      91
-MX51_PAD_EIM_A19__BOOT_LPB1                     92
-MX51_PAD_EIM_A19__EIM_A19                       93
-MX51_PAD_EIM_A19__GPIO2_13                      94
-MX51_PAD_EIM_A20__BOOT_UART_SRC0                95
-MX51_PAD_EIM_A20__EIM_A20                       96
-MX51_PAD_EIM_A20__GPIO2_14                      97
-MX51_PAD_EIM_A21__BOOT_UART_SRC1                98
-MX51_PAD_EIM_A21__EIM_A21                       99
-MX51_PAD_EIM_A21__GPIO2_15                      100
-MX51_PAD_EIM_A22__EIM_A22                       101
-MX51_PAD_EIM_A22__GPIO2_16                      102
-MX51_PAD_EIM_A23__BOOT_HPN_EN                   103
-MX51_PAD_EIM_A23__EIM_A23                       104
-MX51_PAD_EIM_A23__GPIO2_17                      105
-MX51_PAD_EIM_A24__EIM_A24                       106
-MX51_PAD_EIM_A24__GPIO2_18                      107
-MX51_PAD_EIM_A24__USBH2_CLK                     108
-MX51_PAD_EIM_A25__DISP1_PIN4                    109
-MX51_PAD_EIM_A25__EIM_A25                       110
-MX51_PAD_EIM_A25__GPIO2_19                      111
-MX51_PAD_EIM_A25__USBH2_DIR                     112
-MX51_PAD_EIM_A26__CSI1_DATA_EN                  113
-MX51_PAD_EIM_A26__DISP2_EXT_CLK                 114
-MX51_PAD_EIM_A26__EIM_A26                       115
-MX51_PAD_EIM_A26__GPIO2_20                      116
-MX51_PAD_EIM_A26__USBH2_STP                     117
-MX51_PAD_EIM_A27__CSI2_DATA_EN                  118
-MX51_PAD_EIM_A27__DISP1_PIN1                    119
-MX51_PAD_EIM_A27__EIM_A27                       120
-MX51_PAD_EIM_A27__GPIO2_21                      121
-MX51_PAD_EIM_A27__USBH2_NXT                     122
-MX51_PAD_EIM_EB0__EIM_EB0                       123
-MX51_PAD_EIM_EB1__EIM_EB1                       124
-MX51_PAD_EIM_EB2__AUD5_RXFS                     125
-MX51_PAD_EIM_EB2__CSI1_D2                       126
-MX51_PAD_EIM_EB2__EIM_EB2                       127
-MX51_PAD_EIM_EB2__FEC_MDIO                      128
-MX51_PAD_EIM_EB2__GPIO2_22                      129
-MX51_PAD_EIM_EB2__GPT_CMPOUT1                   130
-MX51_PAD_EIM_EB3__AUD5_RXC                      131
-MX51_PAD_EIM_EB3__CSI1_D3                       132
-MX51_PAD_EIM_EB3__EIM_EB3                       133
-MX51_PAD_EIM_EB3__FEC_RDATA1                    134
-MX51_PAD_EIM_EB3__GPIO2_23                      135
-MX51_PAD_EIM_EB3__GPT_CMPOUT2                   136
-MX51_PAD_EIM_OE__EIM_OE                         137
-MX51_PAD_EIM_OE__GPIO2_24                       138
-MX51_PAD_EIM_CS0__EIM_CS0                       139
-MX51_PAD_EIM_CS0__GPIO2_25                      140
-MX51_PAD_EIM_CS1__EIM_CS1                       141
-MX51_PAD_EIM_CS1__GPIO2_26                      142
-MX51_PAD_EIM_CS2__AUD5_TXD                      143
-MX51_PAD_EIM_CS2__CSI1_D4                       144
-MX51_PAD_EIM_CS2__EIM_CS2                       145
-MX51_PAD_EIM_CS2__FEC_RDATA2                    146
-MX51_PAD_EIM_CS2__GPIO2_27                      147
-MX51_PAD_EIM_CS2__USBOTG_STP                    148
-MX51_PAD_EIM_CS3__AUD5_RXD                      149
-MX51_PAD_EIM_CS3__CSI1_D5                       150
-MX51_PAD_EIM_CS3__EIM_CS3                       151
-MX51_PAD_EIM_CS3__FEC_RDATA3                    152
-MX51_PAD_EIM_CS3__GPIO2_28                      153
-MX51_PAD_EIM_CS3__USBOTG_NXT                    154
-MX51_PAD_EIM_CS4__AUD5_TXC                      155
-MX51_PAD_EIM_CS4__CSI1_D6                       156
-MX51_PAD_EIM_CS4__EIM_CS4                       157
-MX51_PAD_EIM_CS4__FEC_RX_ER                     158
-MX51_PAD_EIM_CS4__GPIO2_29                      159
-MX51_PAD_EIM_CS4__USBOTG_CLK                    160
-MX51_PAD_EIM_CS5__AUD5_TXFS                     161
-MX51_PAD_EIM_CS5__CSI1_D7                       162
-MX51_PAD_EIM_CS5__DISP1_EXT_CLK                 163
-MX51_PAD_EIM_CS5__EIM_CS5                       164
-MX51_PAD_EIM_CS5__FEC_CRS                       165
-MX51_PAD_EIM_CS5__GPIO2_30                      166
-MX51_PAD_EIM_CS5__USBOTG_DIR                    167
-MX51_PAD_EIM_DTACK__EIM_DTACK                   168
-MX51_PAD_EIM_DTACK__GPIO2_31                    169
-MX51_PAD_EIM_LBA__EIM_LBA                       170
-MX51_PAD_EIM_LBA__GPIO3_1                       171
-MX51_PAD_EIM_CRE__EIM_CRE                       172
-MX51_PAD_EIM_CRE__GPIO3_2                       173
-MX51_PAD_DRAM_CS1__DRAM_CS1                     174
-MX51_PAD_NANDF_WE_B__GPIO3_3                    175
-MX51_PAD_NANDF_WE_B__NANDF_WE_B                 176
-MX51_PAD_NANDF_WE_B__PATA_DIOW                  177
-MX51_PAD_NANDF_WE_B__SD3_DATA0                  178
-MX51_PAD_NANDF_RE_B__GPIO3_4                    179
-MX51_PAD_NANDF_RE_B__NANDF_RE_B                 180
-MX51_PAD_NANDF_RE_B__PATA_DIOR                  181
-MX51_PAD_NANDF_RE_B__SD3_DATA1                  182
-MX51_PAD_NANDF_ALE__GPIO3_5                     183
-MX51_PAD_NANDF_ALE__NANDF_ALE                   184
-MX51_PAD_NANDF_ALE__PATA_BUFFER_EN              185
-MX51_PAD_NANDF_CLE__GPIO3_6                     186
-MX51_PAD_NANDF_CLE__NANDF_CLE                   187
-MX51_PAD_NANDF_CLE__PATA_RESET_B                188
-MX51_PAD_NANDF_WP_B__GPIO3_7                    189
-MX51_PAD_NANDF_WP_B__NANDF_WP_B                 190
-MX51_PAD_NANDF_WP_B__PATA_DMACK                 191
-MX51_PAD_NANDF_WP_B__SD3_DATA2                  192
-MX51_PAD_NANDF_RB0__ECSPI2_SS1                  193
-MX51_PAD_NANDF_RB0__GPIO3_8                     194
-MX51_PAD_NANDF_RB0__NANDF_RB0                   195
-MX51_PAD_NANDF_RB0__PATA_DMARQ                  196
-MX51_PAD_NANDF_RB0__SD3_DATA3                   197
-MX51_PAD_NANDF_RB1__CSPI_MOSI                   198
-MX51_PAD_NANDF_RB1__ECSPI2_RDY                  199
-MX51_PAD_NANDF_RB1__GPIO3_9                     200
-MX51_PAD_NANDF_RB1__NANDF_RB1                   201
-MX51_PAD_NANDF_RB1__PATA_IORDY                  202
-MX51_PAD_NANDF_RB1__SD4_CMD                     203
-MX51_PAD_NANDF_RB2__DISP2_WAIT                  204
-MX51_PAD_NANDF_RB2__ECSPI2_SCLK                 205
-MX51_PAD_NANDF_RB2__FEC_COL                     206
-MX51_PAD_NANDF_RB2__GPIO3_10                    207
-MX51_PAD_NANDF_RB2__NANDF_RB2                   208
-MX51_PAD_NANDF_RB2__USBH3_H3_DP                 209
-MX51_PAD_NANDF_RB2__USBH3_NXT                   210
-MX51_PAD_NANDF_RB3__DISP1_WAIT                  211
-MX51_PAD_NANDF_RB3__ECSPI2_MISO                 212
-MX51_PAD_NANDF_RB3__FEC_RX_CLK                  213
-MX51_PAD_NANDF_RB3__GPIO3_11                    214
-MX51_PAD_NANDF_RB3__NANDF_RB3                   215
-MX51_PAD_NANDF_RB3__USBH3_CLK                   216
-MX51_PAD_NANDF_RB3__USBH3_H3_DM                 217
-MX51_PAD_GPIO_NAND__GPIO_NAND                   218
-MX51_PAD_GPIO_NAND__PATA_INTRQ                  219
-MX51_PAD_NANDF_CS0__GPIO3_16                    220
-MX51_PAD_NANDF_CS0__NANDF_CS0                   221
-MX51_PAD_NANDF_CS1__GPIO3_17                    222
-MX51_PAD_NANDF_CS1__NANDF_CS1                   223
-MX51_PAD_NANDF_CS2__CSPI_SCLK                   224
-MX51_PAD_NANDF_CS2__FEC_TX_ER                   225
-MX51_PAD_NANDF_CS2__GPIO3_18                    226
-MX51_PAD_NANDF_CS2__NANDF_CS2                   227
-MX51_PAD_NANDF_CS2__PATA_CS_0                   228
-MX51_PAD_NANDF_CS2__SD4_CLK                     229
-MX51_PAD_NANDF_CS2__USBH3_H1_DP                 230
-MX51_PAD_NANDF_CS3__FEC_MDC                     231
-MX51_PAD_NANDF_CS3__GPIO3_19                    232
-MX51_PAD_NANDF_CS3__NANDF_CS3                   233
-MX51_PAD_NANDF_CS3__PATA_CS_1                   234
-MX51_PAD_NANDF_CS3__SD4_DAT0                    235
-MX51_PAD_NANDF_CS3__USBH3_H1_DM                 236
-MX51_PAD_NANDF_CS4__FEC_TDATA1                  237
-MX51_PAD_NANDF_CS4__GPIO3_20                    238
-MX51_PAD_NANDF_CS4__NANDF_CS4                   239
-MX51_PAD_NANDF_CS4__PATA_DA_0                   240
-MX51_PAD_NANDF_CS4__SD4_DAT1                    241
-MX51_PAD_NANDF_CS4__USBH3_STP                   242
-MX51_PAD_NANDF_CS5__FEC_TDATA2                  243
-MX51_PAD_NANDF_CS5__GPIO3_21                    244
-MX51_PAD_NANDF_CS5__NANDF_CS5                   245
-MX51_PAD_NANDF_CS5__PATA_DA_1                   246
-MX51_PAD_NANDF_CS5__SD4_DAT2                    247
-MX51_PAD_NANDF_CS5__USBH3_DIR                   248
-MX51_PAD_NANDF_CS6__CSPI_SS3                    249
-MX51_PAD_NANDF_CS6__FEC_TDATA3                  250
-MX51_PAD_NANDF_CS6__GPIO3_22                    251
-MX51_PAD_NANDF_CS6__NANDF_CS6                   252
-MX51_PAD_NANDF_CS6__PATA_DA_2                   253
-MX51_PAD_NANDF_CS6__SD4_DAT3                    254
-MX51_PAD_NANDF_CS7__FEC_TX_EN                   255
-MX51_PAD_NANDF_CS7__GPIO3_23                    256
-MX51_PAD_NANDF_CS7__NANDF_CS7                   257
-MX51_PAD_NANDF_CS7__SD3_CLK                     258
-MX51_PAD_NANDF_RDY_INT__ECSPI2_SS0              259
-MX51_PAD_NANDF_RDY_INT__FEC_TX_CLK              260
-MX51_PAD_NANDF_RDY_INT__GPIO3_24                261
-MX51_PAD_NANDF_RDY_INT__NANDF_RDY_INT           262
-MX51_PAD_NANDF_RDY_INT__SD3_CMD                 263
-MX51_PAD_NANDF_D15__ECSPI2_MOSI                 264
-MX51_PAD_NANDF_D15__GPIO3_25                    265
-MX51_PAD_NANDF_D15__NANDF_D15                   266
-MX51_PAD_NANDF_D15__PATA_DATA15                 267
-MX51_PAD_NANDF_D15__SD3_DAT7                    268
-MX51_PAD_NANDF_D14__ECSPI2_SS3                  269
-MX51_PAD_NANDF_D14__GPIO3_26                    270
-MX51_PAD_NANDF_D14__NANDF_D14                   271
-MX51_PAD_NANDF_D14__PATA_DATA14                 272
-MX51_PAD_NANDF_D14__SD3_DAT6                    273
-MX51_PAD_NANDF_D13__ECSPI2_SS2                  274
-MX51_PAD_NANDF_D13__GPIO3_27                    275
-MX51_PAD_NANDF_D13__NANDF_D13                   276
-MX51_PAD_NANDF_D13__PATA_DATA13                 277
-MX51_PAD_NANDF_D13__SD3_DAT5                    278
-MX51_PAD_NANDF_D12__ECSPI2_SS1                  279
-MX51_PAD_NANDF_D12__GPIO3_28                    280
-MX51_PAD_NANDF_D12__NANDF_D12                   281
-MX51_PAD_NANDF_D12__PATA_DATA12                 282
-MX51_PAD_NANDF_D12__SD3_DAT4                    283
-MX51_PAD_NANDF_D11__FEC_RX_DV                   284
-MX51_PAD_NANDF_D11__GPIO3_29                    285
-MX51_PAD_NANDF_D11__NANDF_D11                   286
-MX51_PAD_NANDF_D11__PATA_DATA11                 287
-MX51_PAD_NANDF_D11__SD3_DATA3                   288
-MX51_PAD_NANDF_D10__GPIO3_30                    289
-MX51_PAD_NANDF_D10__NANDF_D10                   290
-MX51_PAD_NANDF_D10__PATA_DATA10                 291
-MX51_PAD_NANDF_D10__SD3_DATA2                   292
-MX51_PAD_NANDF_D9__FEC_RDATA0                   293
-MX51_PAD_NANDF_D9__GPIO3_31                     294
-MX51_PAD_NANDF_D9__NANDF_D9                     295
-MX51_PAD_NANDF_D9__PATA_DATA9                   296
-MX51_PAD_NANDF_D9__SD3_DATA1                    297
-MX51_PAD_NANDF_D8__FEC_TDATA0                   298
-MX51_PAD_NANDF_D8__GPIO4_0                      299
-MX51_PAD_NANDF_D8__NANDF_D8                     300
-MX51_PAD_NANDF_D8__PATA_DATA8                   301
-MX51_PAD_NANDF_D8__SD3_DATA0                    302
-MX51_PAD_NANDF_D7__GPIO4_1                      303
-MX51_PAD_NANDF_D7__NANDF_D7                     304
-MX51_PAD_NANDF_D7__PATA_DATA7                   305
-MX51_PAD_NANDF_D7__USBH3_DATA0                  306
-MX51_PAD_NANDF_D6__GPIO4_2                      307
-MX51_PAD_NANDF_D6__NANDF_D6                     308
-MX51_PAD_NANDF_D6__PATA_DATA6                   309
-MX51_PAD_NANDF_D6__SD4_LCTL                     310
-MX51_PAD_NANDF_D6__USBH3_DATA1                  311
-MX51_PAD_NANDF_D5__GPIO4_3                      312
-MX51_PAD_NANDF_D5__NANDF_D5                     313
-MX51_PAD_NANDF_D5__PATA_DATA5                   314
-MX51_PAD_NANDF_D5__SD4_WP                       315
-MX51_PAD_NANDF_D5__USBH3_DATA2                  316
-MX51_PAD_NANDF_D4__GPIO4_4                      317
-MX51_PAD_NANDF_D4__NANDF_D4                     318
-MX51_PAD_NANDF_D4__PATA_DATA4                   319
-MX51_PAD_NANDF_D4__SD4_CD                       320
-MX51_PAD_NANDF_D4__USBH3_DATA3                  321
-MX51_PAD_NANDF_D3__GPIO4_5                      322
-MX51_PAD_NANDF_D3__NANDF_D3                     323
-MX51_PAD_NANDF_D3__PATA_DATA3                   324
-MX51_PAD_NANDF_D3__SD4_DAT4                     325
-MX51_PAD_NANDF_D3__USBH3_DATA4                  326
-MX51_PAD_NANDF_D2__GPIO4_6                      327
-MX51_PAD_NANDF_D2__NANDF_D2                     328
-MX51_PAD_NANDF_D2__PATA_DATA2                   329
-MX51_PAD_NANDF_D2__SD4_DAT5                     330
-MX51_PAD_NANDF_D2__USBH3_DATA5                  331
-MX51_PAD_NANDF_D1__GPIO4_7                      332
-MX51_PAD_NANDF_D1__NANDF_D1                     333
-MX51_PAD_NANDF_D1__PATA_DATA1                   334
-MX51_PAD_NANDF_D1__SD4_DAT6                     335
-MX51_PAD_NANDF_D1__USBH3_DATA6                  336
-MX51_PAD_NANDF_D0__GPIO4_8                      337
-MX51_PAD_NANDF_D0__NANDF_D0                     338
-MX51_PAD_NANDF_D0__PATA_DATA0                   339
-MX51_PAD_NANDF_D0__SD4_DAT7                     340
-MX51_PAD_NANDF_D0__USBH3_DATA7                  341
-MX51_PAD_CSI1_D8__CSI1_D8                       342
-MX51_PAD_CSI1_D8__GPIO3_12                      343
-MX51_PAD_CSI1_D9__CSI1_D9                       344
-MX51_PAD_CSI1_D9__GPIO3_13                      345
-MX51_PAD_CSI1_D10__CSI1_D10                     346
-MX51_PAD_CSI1_D11__CSI1_D11                     347
-MX51_PAD_CSI1_D12__CSI1_D12                     348
-MX51_PAD_CSI1_D13__CSI1_D13                     349
-MX51_PAD_CSI1_D14__CSI1_D14                     350
-MX51_PAD_CSI1_D15__CSI1_D15                     351
-MX51_PAD_CSI1_D16__CSI1_D16                     352
-MX51_PAD_CSI1_D17__CSI1_D17                     353
-MX51_PAD_CSI1_D18__CSI1_D18                     354
-MX51_PAD_CSI1_D19__CSI1_D19                     355
-MX51_PAD_CSI1_VSYNC__CSI1_VSYNC                 356
-MX51_PAD_CSI1_VSYNC__GPIO3_14                   357
-MX51_PAD_CSI1_HSYNC__CSI1_HSYNC                 358
-MX51_PAD_CSI1_HSYNC__GPIO3_15                   359
-MX51_PAD_CSI1_PIXCLK__CSI1_PIXCLK               360
-MX51_PAD_CSI1_MCLK__CSI1_MCLK                   361
-MX51_PAD_CSI2_D12__CSI2_D12                     362
-MX51_PAD_CSI2_D12__GPIO4_9                      363
-MX51_PAD_CSI2_D13__CSI2_D13                     364
-MX51_PAD_CSI2_D13__GPIO4_10                     365
-MX51_PAD_CSI2_D14__CSI2_D14                     366
-MX51_PAD_CSI2_D15__CSI2_D15                     367
-MX51_PAD_CSI2_D16__CSI2_D16                     368
-MX51_PAD_CSI2_D17__CSI2_D17                     369
-MX51_PAD_CSI2_D18__CSI2_D18                     370
-MX51_PAD_CSI2_D18__GPIO4_11                     371
-MX51_PAD_CSI2_D19__CSI2_D19                     372
-MX51_PAD_CSI2_D19__GPIO4_12                     373
-MX51_PAD_CSI2_VSYNC__CSI2_VSYNC                 374
-MX51_PAD_CSI2_VSYNC__GPIO4_13                   375
-MX51_PAD_CSI2_HSYNC__CSI2_HSYNC                 376
-MX51_PAD_CSI2_HSYNC__GPIO4_14                   377
-MX51_PAD_CSI2_PIXCLK__CSI2_PIXCLK               378
-MX51_PAD_CSI2_PIXCLK__GPIO4_15                  379
-MX51_PAD_I2C1_CLK__GPIO4_16                     380
-MX51_PAD_I2C1_CLK__I2C1_CLK                     381
-MX51_PAD_I2C1_DAT__GPIO4_17                     382
-MX51_PAD_I2C1_DAT__I2C1_DAT                     383
-MX51_PAD_AUD3_BB_TXD__AUD3_TXD                  384
-MX51_PAD_AUD3_BB_TXD__GPIO4_18                  385
-MX51_PAD_AUD3_BB_RXD__AUD3_RXD                  386
-MX51_PAD_AUD3_BB_RXD__GPIO4_19                  387
-MX51_PAD_AUD3_BB_RXD__UART3_RXD                 388
-MX51_PAD_AUD3_BB_CK__AUD3_TXC                   389
-MX51_PAD_AUD3_BB_CK__GPIO4_20                   390
-MX51_PAD_AUD3_BB_FS__AUD3_TXFS                  391
-MX51_PAD_AUD3_BB_FS__GPIO4_21                   392
-MX51_PAD_AUD3_BB_FS__UART3_TXD                  393
-MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI                394
-MX51_PAD_CSPI1_MOSI__GPIO4_22                   395
-MX51_PAD_CSPI1_MOSI__I2C1_SDA                   396
-MX51_PAD_CSPI1_MISO__AUD4_RXD                   397
-MX51_PAD_CSPI1_MISO__ECSPI1_MISO                398
-MX51_PAD_CSPI1_MISO__GPIO4_23                   399
-MX51_PAD_CSPI1_SS0__AUD4_TXC                    400
-MX51_PAD_CSPI1_SS0__ECSPI1_SS0                  401
-MX51_PAD_CSPI1_SS0__GPIO4_24                    402
-MX51_PAD_CSPI1_SS1__AUD4_TXD                    403
-MX51_PAD_CSPI1_SS1__ECSPI1_SS1                  404
-MX51_PAD_CSPI1_SS1__GPIO4_25                    405
-MX51_PAD_CSPI1_RDY__AUD4_TXFS                   406
-MX51_PAD_CSPI1_RDY__ECSPI1_RDY                  407
-MX51_PAD_CSPI1_RDY__GPIO4_26                    408
-MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK                409
-MX51_PAD_CSPI1_SCLK__GPIO4_27                   410
-MX51_PAD_CSPI1_SCLK__I2C1_SCL                   411
-MX51_PAD_UART1_RXD__GPIO4_28                    412
-MX51_PAD_UART1_RXD__UART1_RXD                   413
-MX51_PAD_UART1_TXD__GPIO4_29                    414
-MX51_PAD_UART1_TXD__PWM2_PWMO                   415
-MX51_PAD_UART1_TXD__UART1_TXD                   416
-MX51_PAD_UART1_RTS__GPIO4_30                    417
-MX51_PAD_UART1_RTS__UART1_RTS                   418
-MX51_PAD_UART1_CTS__GPIO4_31                    419
-MX51_PAD_UART1_CTS__UART1_CTS                   420
-MX51_PAD_UART2_RXD__FIRI_TXD                    421
-MX51_PAD_UART2_RXD__GPIO1_20                    422
-MX51_PAD_UART2_RXD__UART2_RXD                   423
-MX51_PAD_UART2_TXD__FIRI_RXD                    424
-MX51_PAD_UART2_TXD__GPIO1_21                    425
-MX51_PAD_UART2_TXD__UART2_TXD                   426
-MX51_PAD_UART3_RXD__CSI1_D0                     427
-MX51_PAD_UART3_RXD__GPIO1_22                    428
-MX51_PAD_UART3_RXD__UART1_DTR                   429
-MX51_PAD_UART3_RXD__UART3_RXD                   430
-MX51_PAD_UART3_TXD__CSI1_D1                     431
-MX51_PAD_UART3_TXD__GPIO1_23                    432
-MX51_PAD_UART3_TXD__UART1_DSR                   433
-MX51_PAD_UART3_TXD__UART3_TXD                   434
-MX51_PAD_OWIRE_LINE__GPIO1_24                   435
-MX51_PAD_OWIRE_LINE__OWIRE_LINE                 436
-MX51_PAD_OWIRE_LINE__SPDIF_OUT                  437
-MX51_PAD_KEY_ROW0__KEY_ROW0                     438
-MX51_PAD_KEY_ROW1__KEY_ROW1                     439
-MX51_PAD_KEY_ROW2__KEY_ROW2                     440
-MX51_PAD_KEY_ROW3__KEY_ROW3                     441
-MX51_PAD_KEY_COL0__KEY_COL0                     442
-MX51_PAD_KEY_COL0__PLL1_BYP                     443
-MX51_PAD_KEY_COL1__KEY_COL1                     444
-MX51_PAD_KEY_COL1__PLL2_BYP                     445
-MX51_PAD_KEY_COL2__KEY_COL2                     446
-MX51_PAD_KEY_COL2__PLL3_BYP                     447
-MX51_PAD_KEY_COL3__KEY_COL3                     448
-MX51_PAD_KEY_COL4__I2C2_SCL                     449
-MX51_PAD_KEY_COL4__KEY_COL4                     450
-MX51_PAD_KEY_COL4__SPDIF_OUT1                   451
-MX51_PAD_KEY_COL4__UART1_RI                     452
-MX51_PAD_KEY_COL4__UART3_RTS                    453
-MX51_PAD_KEY_COL5__I2C2_SDA                     454
-MX51_PAD_KEY_COL5__KEY_COL5                     455
-MX51_PAD_KEY_COL5__UART1_DCD                    456
-MX51_PAD_KEY_COL5__UART3_CTS                    457
-MX51_PAD_USBH1_CLK__CSPI_SCLK                   458
-MX51_PAD_USBH1_CLK__GPIO1_25                    459
-MX51_PAD_USBH1_CLK__I2C2_SCL                    460
-MX51_PAD_USBH1_CLK__USBH1_CLK                   461
-MX51_PAD_USBH1_DIR__CSPI_MOSI                   462
-MX51_PAD_USBH1_DIR__GPIO1_26                    463
-MX51_PAD_USBH1_DIR__I2C2_SDA                    464
-MX51_PAD_USBH1_DIR__USBH1_DIR                   465
-MX51_PAD_USBH1_STP__CSPI_RDY                    466
-MX51_PAD_USBH1_STP__GPIO1_27                    467
-MX51_PAD_USBH1_STP__UART3_RXD                   468
-MX51_PAD_USBH1_STP__USBH1_STP                   469
-MX51_PAD_USBH1_NXT__CSPI_MISO                   470
-MX51_PAD_USBH1_NXT__GPIO1_28                    471
-MX51_PAD_USBH1_NXT__UART3_TXD                   472
-MX51_PAD_USBH1_NXT__USBH1_NXT                   473
-MX51_PAD_USBH1_DATA0__GPIO1_11                  474
-MX51_PAD_USBH1_DATA0__UART2_CTS                 475
-MX51_PAD_USBH1_DATA0__USBH1_DATA0               476
-MX51_PAD_USBH1_DATA1__GPIO1_12                  477
-MX51_PAD_USBH1_DATA1__UART2_RXD                 478
-MX51_PAD_USBH1_DATA1__USBH1_DATA1               479
-MX51_PAD_USBH1_DATA2__GPIO1_13                  480
-MX51_PAD_USBH1_DATA2__UART2_TXD                 481
-MX51_PAD_USBH1_DATA2__USBH1_DATA2               482
-MX51_PAD_USBH1_DATA3__GPIO1_14                  483
-MX51_PAD_USBH1_DATA3__UART2_RTS                 484
-MX51_PAD_USBH1_DATA3__USBH1_DATA3               485
-MX51_PAD_USBH1_DATA4__CSPI_SS0                  486
-MX51_PAD_USBH1_DATA4__GPIO1_15                  487
-MX51_PAD_USBH1_DATA4__USBH1_DATA4               488
-MX51_PAD_USBH1_DATA5__CSPI_SS1                  489
-MX51_PAD_USBH1_DATA5__GPIO1_16                  490
-MX51_PAD_USBH1_DATA5__USBH1_DATA5               491
-MX51_PAD_USBH1_DATA6__CSPI_SS3                  492
-MX51_PAD_USBH1_DATA6__GPIO1_17                  493
-MX51_PAD_USBH1_DATA6__USBH1_DATA6               494
-MX51_PAD_USBH1_DATA7__ECSPI1_SS3                495
-MX51_PAD_USBH1_DATA7__ECSPI2_SS3                496
-MX51_PAD_USBH1_DATA7__GPIO1_18                  497
-MX51_PAD_USBH1_DATA7__USBH1_DATA7               498
-MX51_PAD_DI1_PIN11__DI1_PIN11                   499
-MX51_PAD_DI1_PIN11__ECSPI1_SS2                  500
-MX51_PAD_DI1_PIN11__GPIO3_0                     501
-MX51_PAD_DI1_PIN12__DI1_PIN12                   502
-MX51_PAD_DI1_PIN12__GPIO3_1                     503
-MX51_PAD_DI1_PIN13__DI1_PIN13                   504
-MX51_PAD_DI1_PIN13__GPIO3_2                     505
-MX51_PAD_DI1_D0_CS__DI1_D0_CS                   506
-MX51_PAD_DI1_D0_CS__GPIO3_3                     507
-MX51_PAD_DI1_D1_CS__DI1_D1_CS                   508
-MX51_PAD_DI1_D1_CS__DISP1_PIN14                 509
-MX51_PAD_DI1_D1_CS__DISP1_PIN5                  510
-MX51_PAD_DI1_D1_CS__GPIO3_4                     511
-MX51_PAD_DISPB2_SER_DIN__DISP1_PIN1             512
-MX51_PAD_DISPB2_SER_DIN__DISPB2_SER_DIN         513
-MX51_PAD_DISPB2_SER_DIN__GPIO3_5                514
-MX51_PAD_DISPB2_SER_DIO__DISP1_PIN6             515
-MX51_PAD_DISPB2_SER_DIO__DISPB2_SER_DIO         516
-MX51_PAD_DISPB2_SER_DIO__GPIO3_6                517
-MX51_PAD_DISPB2_SER_CLK__DISP1_PIN17            518
-MX51_PAD_DISPB2_SER_CLK__DISP1_PIN7             519
-MX51_PAD_DISPB2_SER_CLK__DISPB2_SER_CLK         520
-MX51_PAD_DISPB2_SER_CLK__GPIO3_7                521
-MX51_PAD_DISPB2_SER_RS__DISP1_EXT_CLK           522
-MX51_PAD_DISPB2_SER_RS__DISP1_PIN16             523
-MX51_PAD_DISPB2_SER_RS__DISP1_PIN8              524
-MX51_PAD_DISPB2_SER_RS__DISPB2_SER_RS           525
-MX51_PAD_DISPB2_SER_RS__DISPB2_SER_RS           526
-MX51_PAD_DISPB2_SER_RS__GPIO3_8                 527
-MX51_PAD_DISP1_DAT0__DISP1_DAT0                 528
-MX51_PAD_DISP1_DAT1__DISP1_DAT1                 529
-MX51_PAD_DISP1_DAT2__DISP1_DAT2                 530
-MX51_PAD_DISP1_DAT3__DISP1_DAT3                 531
-MX51_PAD_DISP1_DAT4__DISP1_DAT4                 532
-MX51_PAD_DISP1_DAT5__DISP1_DAT5                 533
-MX51_PAD_DISP1_DAT6__BOOT_USB_SRC               534
-MX51_PAD_DISP1_DAT6__DISP1_DAT6                 535
-MX51_PAD_DISP1_DAT7__BOOT_EEPROM_CFG            536
-MX51_PAD_DISP1_DAT7__DISP1_DAT7                 537
-MX51_PAD_DISP1_DAT8__BOOT_SRC0                  538
-MX51_PAD_DISP1_DAT8__DISP1_DAT8                 539
-MX51_PAD_DISP1_DAT9__BOOT_SRC1                  540
-MX51_PAD_DISP1_DAT9__DISP1_DAT9                 541
-MX51_PAD_DISP1_DAT10__BOOT_SPARE_SIZE           542
-MX51_PAD_DISP1_DAT10__DISP1_DAT10               543
-MX51_PAD_DISP1_DAT11__BOOT_LPB_FREQ2            544
-MX51_PAD_DISP1_DAT11__DISP1_DAT11               545
-MX51_PAD_DISP1_DAT12__BOOT_MLC_SEL              546
-MX51_PAD_DISP1_DAT12__DISP1_DAT12               547
-MX51_PAD_DISP1_DAT13__BOOT_MEM_CTL0             548
-MX51_PAD_DISP1_DAT13__DISP1_DAT13               549
-MX51_PAD_DISP1_DAT14__BOOT_MEM_CTL1             550
-MX51_PAD_DISP1_DAT14__DISP1_DAT14               551
-MX51_PAD_DISP1_DAT15__BOOT_BUS_WIDTH            552
-MX51_PAD_DISP1_DAT15__DISP1_DAT15               553
-MX51_PAD_DISP1_DAT16__BOOT_PAGE_SIZE0           554
-MX51_PAD_DISP1_DAT16__DISP1_DAT16               555
-MX51_PAD_DISP1_DAT17__BOOT_PAGE_SIZE1           556
-MX51_PAD_DISP1_DAT17__DISP1_DAT17               557
-MX51_PAD_DISP1_DAT18__BOOT_WEIM_MUXED0          558
-MX51_PAD_DISP1_DAT18__DISP1_DAT18               559
-MX51_PAD_DISP1_DAT18__DISP2_PIN11               560
-MX51_PAD_DISP1_DAT18__DISP2_PIN5                561
-MX51_PAD_DISP1_DAT19__BOOT_WEIM_MUXED1          562
-MX51_PAD_DISP1_DAT19__DISP1_DAT19               563
-MX51_PAD_DISP1_DAT19__DISP2_PIN12               564
-MX51_PAD_DISP1_DAT19__DISP2_PIN6                565
-MX51_PAD_DISP1_DAT20__BOOT_MEM_TYPE0            566
-MX51_PAD_DISP1_DAT20__DISP1_DAT20               567
-MX51_PAD_DISP1_DAT20__DISP2_PIN13               568
-MX51_PAD_DISP1_DAT20__DISP2_PIN7                569
-MX51_PAD_DISP1_DAT21__BOOT_MEM_TYPE1            570
-MX51_PAD_DISP1_DAT21__DISP1_DAT21               571
-MX51_PAD_DISP1_DAT21__DISP2_PIN14               572
-MX51_PAD_DISP1_DAT21__DISP2_PIN8                573
-MX51_PAD_DISP1_DAT22__BOOT_LPB_FREQ0            574
-MX51_PAD_DISP1_DAT22__DISP1_DAT22               575
-MX51_PAD_DISP1_DAT22__DISP2_D0_CS               576
-MX51_PAD_DISP1_DAT22__DISP2_DAT16               577
-MX51_PAD_DISP1_DAT23__BOOT_LPB_FREQ1            578
-MX51_PAD_DISP1_DAT23__DISP1_DAT23               579
-MX51_PAD_DISP1_DAT23__DISP2_D1_CS               580
-MX51_PAD_DISP1_DAT23__DISP2_DAT17               581
-MX51_PAD_DISP1_DAT23__DISP2_SER_CS              582
-MX51_PAD_DI1_PIN3__DI1_PIN3                     583
-MX51_PAD_DI1_PIN2__DI1_PIN2                     584
-MX51_PAD_DI_GP2__DISP1_SER_CLK                  585
-MX51_PAD_DI_GP2__DISP2_WAIT                     586
-MX51_PAD_DI_GP3__CSI1_DATA_EN                   587
-MX51_PAD_DI_GP3__DISP1_SER_DIO                  588
-MX51_PAD_DI_GP3__FEC_TX_ER                      589
-MX51_PAD_DI2_PIN4__CSI2_DATA_EN                 590
-MX51_PAD_DI2_PIN4__DI2_PIN4                     591
-MX51_PAD_DI2_PIN4__FEC_CRS                      592
-MX51_PAD_DI2_PIN2__DI2_PIN2                     593
-MX51_PAD_DI2_PIN2__FEC_MDC                      594
-MX51_PAD_DI2_PIN3__DI2_PIN3                     595
-MX51_PAD_DI2_PIN3__FEC_MDIO                     596
-MX51_PAD_DI2_DISP_CLK__DI2_DISP_CLK             597
-MX51_PAD_DI2_DISP_CLK__FEC_RDATA1               598
-MX51_PAD_DI_GP4__DI2_PIN15                      599
-MX51_PAD_DI_GP4__DISP1_SER_DIN                  600
-MX51_PAD_DI_GP4__DISP2_PIN1                     601
-MX51_PAD_DI_GP4__FEC_RDATA2                     602
-MX51_PAD_DISP2_DAT0__DISP2_DAT0                 603
-MX51_PAD_DISP2_DAT0__FEC_RDATA3                 604
-MX51_PAD_DISP2_DAT0__KEY_COL6                   605
-MX51_PAD_DISP2_DAT0__UART3_RXD                  606
-MX51_PAD_DISP2_DAT0__USBH3_CLK                  607
-MX51_PAD_DISP2_DAT1__DISP2_DAT1                 608
-MX51_PAD_DISP2_DAT1__FEC_RX_ER                  609
-MX51_PAD_DISP2_DAT1__KEY_COL7                   610
-MX51_PAD_DISP2_DAT1__UART3_TXD                  611
-MX51_PAD_DISP2_DAT1__USBH3_DIR                  612
-MX51_PAD_DISP2_DAT2__DISP2_DAT2                 613
-MX51_PAD_DISP2_DAT3__DISP2_DAT3                 614
-MX51_PAD_DISP2_DAT4__DISP2_DAT4                 615
-MX51_PAD_DISP2_DAT5__DISP2_DAT5                 616
-MX51_PAD_DISP2_DAT6__DISP2_DAT6                 617
-MX51_PAD_DISP2_DAT6__FEC_TDATA1                 618
-MX51_PAD_DISP2_DAT6__GPIO1_19                   619
-MX51_PAD_DISP2_DAT6__KEY_ROW4                   620
-MX51_PAD_DISP2_DAT6__USBH3_STP                  621
-MX51_PAD_DISP2_DAT7__DISP2_DAT7                 622
-MX51_PAD_DISP2_DAT7__FEC_TDATA2                 623
-MX51_PAD_DISP2_DAT7__GPIO1_29                   624
-MX51_PAD_DISP2_DAT7__KEY_ROW5                   625
-MX51_PAD_DISP2_DAT7__USBH3_NXT                  626
-MX51_PAD_DISP2_DAT8__DISP2_DAT8                 627
-MX51_PAD_DISP2_DAT8__FEC_TDATA3                 628
-MX51_PAD_DISP2_DAT8__GPIO1_30                   629
-MX51_PAD_DISP2_DAT8__KEY_ROW6                   630
-MX51_PAD_DISP2_DAT8__USBH3_DATA0                631
-MX51_PAD_DISP2_DAT9__AUD6_RXC                   632
-MX51_PAD_DISP2_DAT9__DISP2_DAT9                 633
-MX51_PAD_DISP2_DAT9__FEC_TX_EN                  634
-MX51_PAD_DISP2_DAT9__GPIO1_31                   635
-MX51_PAD_DISP2_DAT9__USBH3_DATA1                636
-MX51_PAD_DISP2_DAT10__DISP2_DAT10               637
-MX51_PAD_DISP2_DAT10__DISP2_SER_CS              638
-MX51_PAD_DISP2_DAT10__FEC_COL                   639
-MX51_PAD_DISP2_DAT10__KEY_ROW7                  640
-MX51_PAD_DISP2_DAT10__USBH3_DATA2               641
-MX51_PAD_DISP2_DAT11__AUD6_TXD                  642
-MX51_PAD_DISP2_DAT11__DISP2_DAT11               643
-MX51_PAD_DISP2_DAT11__FEC_RX_CLK                644
-MX51_PAD_DISP2_DAT11__GPIO1_10                  645
-MX51_PAD_DISP2_DAT11__USBH3_DATA3               646
-MX51_PAD_DISP2_DAT12__AUD6_RXD                  647
-MX51_PAD_DISP2_DAT12__DISP2_DAT12               648
-MX51_PAD_DISP2_DAT12__FEC_RX_DV                 649
-MX51_PAD_DISP2_DAT12__USBH3_DATA4               650
-MX51_PAD_DISP2_DAT13__AUD6_TXC                  651
-MX51_PAD_DISP2_DAT13__DISP2_DAT13               652
-MX51_PAD_DISP2_DAT13__FEC_TX_CLK                653
-MX51_PAD_DISP2_DAT13__USBH3_DATA5               654
-MX51_PAD_DISP2_DAT14__AUD6_TXFS                 655
-MX51_PAD_DISP2_DAT14__DISP2_DAT14               656
-MX51_PAD_DISP2_DAT14__FEC_RDATA0                657
-MX51_PAD_DISP2_DAT14__USBH3_DATA6               658
-MX51_PAD_DISP2_DAT15__AUD6_RXFS                 659
-MX51_PAD_DISP2_DAT15__DISP1_SER_CS              660
-MX51_PAD_DISP2_DAT15__DISP2_DAT15               661
-MX51_PAD_DISP2_DAT15__FEC_TDATA0                662
-MX51_PAD_DISP2_DAT15__USBH3_DATA7               663
-MX51_PAD_SD1_CMD__AUD5_RXFS                     664
-MX51_PAD_SD1_CMD__CSPI_MOSI                     665
-MX51_PAD_SD1_CMD__SD1_CMD                       666
-MX51_PAD_SD1_CLK__AUD5_RXC                      667
-MX51_PAD_SD1_CLK__CSPI_SCLK                     668
-MX51_PAD_SD1_CLK__SD1_CLK                       669
-MX51_PAD_SD1_DATA0__AUD5_TXD                    670
-MX51_PAD_SD1_DATA0__CSPI_MISO                   671
-MX51_PAD_SD1_DATA0__SD1_DATA0                   672
-MX51_PAD_EIM_DA0__EIM_DA0                       673
-MX51_PAD_EIM_DA1__EIM_DA1                       674
-MX51_PAD_EIM_DA2__EIM_DA2                       675
-MX51_PAD_EIM_DA3__EIM_DA3                       676
-MX51_PAD_SD1_DATA1__AUD5_RXD                    677
-MX51_PAD_SD1_DATA1__SD1_DATA1                   678
-MX51_PAD_EIM_DA4__EIM_DA4                       679
-MX51_PAD_EIM_DA5__EIM_DA5                       680
-MX51_PAD_EIM_DA6__EIM_DA6                       681
-MX51_PAD_EIM_DA7__EIM_DA7                       682
-MX51_PAD_SD1_DATA2__AUD5_TXC                    683
-MX51_PAD_SD1_DATA2__SD1_DATA2                   684
-MX51_PAD_EIM_DA10__EIM_DA10                     685
-MX51_PAD_EIM_DA11__EIM_DA11                     686
-MX51_PAD_EIM_DA8__EIM_DA8                       687
-MX51_PAD_EIM_DA9__EIM_DA9                       688
-MX51_PAD_SD1_DATA3__AUD5_TXFS                   689
-MX51_PAD_SD1_DATA3__CSPI_SS1                    690
-MX51_PAD_SD1_DATA3__SD1_DATA3                   691
-MX51_PAD_GPIO1_0__CSPI_SS2                      692
-MX51_PAD_GPIO1_0__GPIO1_0                       693
-MX51_PAD_GPIO1_0__SD1_CD                        694
-MX51_PAD_GPIO1_1__CSPI_MISO                     695
-MX51_PAD_GPIO1_1__GPIO1_1                       696
-MX51_PAD_GPIO1_1__SD1_WP                        697
-MX51_PAD_EIM_DA12__EIM_DA12                     698
-MX51_PAD_EIM_DA13__EIM_DA13                     699
-MX51_PAD_EIM_DA14__EIM_DA14                     700
-MX51_PAD_EIM_DA15__EIM_DA15                     701
-MX51_PAD_SD2_CMD__CSPI_MOSI                     702
-MX51_PAD_SD2_CMD__I2C1_SCL                      703
-MX51_PAD_SD2_CMD__SD2_CMD                       704
-MX51_PAD_SD2_CLK__CSPI_SCLK                     705
-MX51_PAD_SD2_CLK__I2C1_SDA                      706
-MX51_PAD_SD2_CLK__SD2_CLK                       707
-MX51_PAD_SD2_DATA0__CSPI_MISO                   708
-MX51_PAD_SD2_DATA0__SD1_DAT4                    709
-MX51_PAD_SD2_DATA0__SD2_DATA0                   710
-MX51_PAD_SD2_DATA1__SD1_DAT5                    711
-MX51_PAD_SD2_DATA1__SD2_DATA1                   712
-MX51_PAD_SD2_DATA1__USBH3_H2_DP                 713
-MX51_PAD_SD2_DATA2__SD1_DAT6                    714
-MX51_PAD_SD2_DATA2__SD2_DATA2                   715
-MX51_PAD_SD2_DATA2__USBH3_H2_DM                 716
-MX51_PAD_SD2_DATA3__CSPI_SS2                    717
-MX51_PAD_SD2_DATA3__SD1_DAT7                    718
-MX51_PAD_SD2_DATA3__SD2_DATA3                   719
-MX51_PAD_GPIO1_2__CCM_OUT_2                     720
-MX51_PAD_GPIO1_2__GPIO1_2                       721
-MX51_PAD_GPIO1_2__I2C2_SCL                      722
-MX51_PAD_GPIO1_2__PLL1_BYP                      723
-MX51_PAD_GPIO1_2__PWM1_PWMO                     724
-MX51_PAD_GPIO1_3__GPIO1_3                       725
-MX51_PAD_GPIO1_3__I2C2_SDA                      726
-MX51_PAD_GPIO1_3__PLL2_BYP                      727
-MX51_PAD_GPIO1_3__PWM2_PWMO                     728
-MX51_PAD_PMIC_INT_REQ__PMIC_INT_REQ             729
-MX51_PAD_PMIC_INT_REQ__PMIC_PMU_IRQ_B           730
-MX51_PAD_GPIO1_4__DISP2_EXT_CLK                 731
-MX51_PAD_GPIO1_4__EIM_RDY                       732
-MX51_PAD_GPIO1_4__GPIO1_4                       733
-MX51_PAD_GPIO1_4__WDOG1_WDOG_B                  734
-MX51_PAD_GPIO1_5__CSI2_MCLK                     735
-MX51_PAD_GPIO1_5__DISP2_PIN16                   736
-MX51_PAD_GPIO1_5__GPIO1_5                       737
-MX51_PAD_GPIO1_5__WDOG2_WDOG_B                  738
-MX51_PAD_GPIO1_6__DISP2_PIN17                   739
-MX51_PAD_GPIO1_6__GPIO1_6                       740
-MX51_PAD_GPIO1_6__REF_EN_B                      741
-MX51_PAD_GPIO1_7__CCM_OUT_0                     742
-MX51_PAD_GPIO1_7__GPIO1_7                       743
-MX51_PAD_GPIO1_7__SD2_WP                        744
-MX51_PAD_GPIO1_7__SPDIF_OUT1                    745
-MX51_PAD_GPIO1_8__CSI2_DATA_EN                  746
-MX51_PAD_GPIO1_8__GPIO1_8                       747
-MX51_PAD_GPIO1_8__SD2_CD                        748
-MX51_PAD_GPIO1_8__USBH3_PWR                     749
-MX51_PAD_GPIO1_9__CCM_OUT_1                     750
-MX51_PAD_GPIO1_9__DISP2_D1_CS                   751
-MX51_PAD_GPIO1_9__DISP2_SER_CS                  752
-MX51_PAD_GPIO1_9__GPIO1_9                       753
-MX51_PAD_GPIO1_9__SD2_LCTL                      754
-MX51_PAD_GPIO1_9__USBH3_OC                      755
+Refer to imx51-pinfunc.h in device tree source folder for all available
+imx51 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
index ca85ca432ef0..25dcb77cfaf7 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
@@ -28,1175 +28,5 @@ PAD_CTL_DSE_MAX			(3 << 1)
 PAD_CTL_SRE_FAST                (1 << 0)
 PAD_CTL_SRE_SLOW                (0 << 0)
 
-See below for available PIN_FUNC_ID for imx53:
-MX53_PAD_GPIO_19__KPP_COL_5                             0
-MX53_PAD_GPIO_19__GPIO4_5                               1
-MX53_PAD_GPIO_19__CCM_CLKO                              2
-MX53_PAD_GPIO_19__SPDIF_OUT1                            3
-MX53_PAD_GPIO_19__RTC_CE_RTC_EXT_TRIG2                  4
-MX53_PAD_GPIO_19__ECSPI1_RDY                            5
-MX53_PAD_GPIO_19__FEC_TDATA_3                           6
-MX53_PAD_GPIO_19__SRC_INT_BOOT                          7
-MX53_PAD_KEY_COL0__KPP_COL_0                            8
-MX53_PAD_KEY_COL0__GPIO4_6                              9
-MX53_PAD_KEY_COL0__AUDMUX_AUD5_TXC                      10
-MX53_PAD_KEY_COL0__UART4_TXD_MUX                        11
-MX53_PAD_KEY_COL0__ECSPI1_SCLK                          12
-MX53_PAD_KEY_COL0__FEC_RDATA_3                          13
-MX53_PAD_KEY_COL0__SRC_ANY_PU_RST                       14
-MX53_PAD_KEY_ROW0__KPP_ROW_0                            15
-MX53_PAD_KEY_ROW0__GPIO4_7                              16
-MX53_PAD_KEY_ROW0__AUDMUX_AUD5_TXD                      17
-MX53_PAD_KEY_ROW0__UART4_RXD_MUX                        18
-MX53_PAD_KEY_ROW0__ECSPI1_MOSI                          19
-MX53_PAD_KEY_ROW0__FEC_TX_ER                            20
-MX53_PAD_KEY_COL1__KPP_COL_1                            21
-MX53_PAD_KEY_COL1__GPIO4_8                              22
-MX53_PAD_KEY_COL1__AUDMUX_AUD5_TXFS                     23
-MX53_PAD_KEY_COL1__UART5_TXD_MUX                        24
-MX53_PAD_KEY_COL1__ECSPI1_MISO                          25
-MX53_PAD_KEY_COL1__FEC_RX_CLK                           26
-MX53_PAD_KEY_COL1__USBPHY1_TXREADY                      27
-MX53_PAD_KEY_ROW1__KPP_ROW_1                            28
-MX53_PAD_KEY_ROW1__GPIO4_9                              29
-MX53_PAD_KEY_ROW1__AUDMUX_AUD5_RXD                      30
-MX53_PAD_KEY_ROW1__UART5_RXD_MUX                        31
-MX53_PAD_KEY_ROW1__ECSPI1_SS0                           32
-MX53_PAD_KEY_ROW1__FEC_COL                              33
-MX53_PAD_KEY_ROW1__USBPHY1_RXVALID                      34
-MX53_PAD_KEY_COL2__KPP_COL_2                            35
-MX53_PAD_KEY_COL2__GPIO4_10                             36
-MX53_PAD_KEY_COL2__CAN1_TXCAN                           37
-MX53_PAD_KEY_COL2__FEC_MDIO                             38
-MX53_PAD_KEY_COL2__ECSPI1_SS1                           39
-MX53_PAD_KEY_COL2__FEC_RDATA_2                          40
-MX53_PAD_KEY_COL2__USBPHY1_RXACTIVE                     41
-MX53_PAD_KEY_ROW2__KPP_ROW_2                            42
-MX53_PAD_KEY_ROW2__GPIO4_11                             43
-MX53_PAD_KEY_ROW2__CAN1_RXCAN                           44
-MX53_PAD_KEY_ROW2__FEC_MDC                              45
-MX53_PAD_KEY_ROW2__ECSPI1_SS2                           46
-MX53_PAD_KEY_ROW2__FEC_TDATA_2                          47
-MX53_PAD_KEY_ROW2__USBPHY1_RXERROR                      48
-MX53_PAD_KEY_COL3__KPP_COL_3                            49
-MX53_PAD_KEY_COL3__GPIO4_12                             50
-MX53_PAD_KEY_COL3__USBOH3_H2_DP                         51
-MX53_PAD_KEY_COL3__SPDIF_IN1                            52
-MX53_PAD_KEY_COL3__I2C2_SCL                             53
-MX53_PAD_KEY_COL3__ECSPI1_SS3                           54
-MX53_PAD_KEY_COL3__FEC_CRS                              55
-MX53_PAD_KEY_COL3__USBPHY1_SIECLOCK                     56
-MX53_PAD_KEY_ROW3__KPP_ROW_3                            57
-MX53_PAD_KEY_ROW3__GPIO4_13                             58
-MX53_PAD_KEY_ROW3__USBOH3_H2_DM                         59
-MX53_PAD_KEY_ROW3__CCM_ASRC_EXT_CLK                     60
-MX53_PAD_KEY_ROW3__I2C2_SDA                             61
-MX53_PAD_KEY_ROW3__OSC32K_32K_OUT                       62
-MX53_PAD_KEY_ROW3__CCM_PLL4_BYP                         63
-MX53_PAD_KEY_ROW3__USBPHY1_LINESTATE_0                  64
-MX53_PAD_KEY_COL4__KPP_COL_4                            65
-MX53_PAD_KEY_COL4__GPIO4_14                             66
-MX53_PAD_KEY_COL4__CAN2_TXCAN                           67
-MX53_PAD_KEY_COL4__IPU_SISG_4                           68
-MX53_PAD_KEY_COL4__UART5_RTS                            69
-MX53_PAD_KEY_COL4__USBOH3_USBOTG_OC                     70
-MX53_PAD_KEY_COL4__USBPHY1_LINESTATE_1                  71
-MX53_PAD_KEY_ROW4__KPP_ROW_4                            72
-MX53_PAD_KEY_ROW4__GPIO4_15                             73
-MX53_PAD_KEY_ROW4__CAN2_RXCAN                           74
-MX53_PAD_KEY_ROW4__IPU_SISG_5                           75
-MX53_PAD_KEY_ROW4__UART5_CTS                            76
-MX53_PAD_KEY_ROW4__USBOH3_USBOTG_PWR                    77
-MX53_PAD_KEY_ROW4__USBPHY1_VBUSVALID                    78
-MX53_PAD_DI0_DISP_CLK__IPU_DI0_DISP_CLK                 79
-MX53_PAD_DI0_DISP_CLK__GPIO4_16                         80
-MX53_PAD_DI0_DISP_CLK__USBOH3_USBH2_DIR                 81
-MX53_PAD_DI0_DISP_CLK__SDMA_DEBUG_CORE_STATE_0          82
-MX53_PAD_DI0_DISP_CLK__EMI_EMI_DEBUG_0                  83
-MX53_PAD_DI0_DISP_CLK__USBPHY1_AVALID                   84
-MX53_PAD_DI0_PIN15__IPU_DI0_PIN15                       85
-MX53_PAD_DI0_PIN15__GPIO4_17                            86
-MX53_PAD_DI0_PIN15__AUDMUX_AUD6_TXC                     87
-MX53_PAD_DI0_PIN15__SDMA_DEBUG_CORE_STATE_1             88
-MX53_PAD_DI0_PIN15__EMI_EMI_DEBUG_1                     89
-MX53_PAD_DI0_PIN15__USBPHY1_BVALID                      90
-MX53_PAD_DI0_PIN2__IPU_DI0_PIN2                         91
-MX53_PAD_DI0_PIN2__GPIO4_18                             92
-MX53_PAD_DI0_PIN2__AUDMUX_AUD6_TXD                      93
-MX53_PAD_DI0_PIN2__SDMA_DEBUG_CORE_STATE_2              94
-MX53_PAD_DI0_PIN2__EMI_EMI_DEBUG_2                      95
-MX53_PAD_DI0_PIN2__USBPHY1_ENDSESSION                   96
-MX53_PAD_DI0_PIN3__IPU_DI0_PIN3                         97
-MX53_PAD_DI0_PIN3__GPIO4_19                             98
-MX53_PAD_DI0_PIN3__AUDMUX_AUD6_TXFS                     99
-MX53_PAD_DI0_PIN3__SDMA_DEBUG_CORE_STATE_3              100
-MX53_PAD_DI0_PIN3__EMI_EMI_DEBUG_3                      101
-MX53_PAD_DI0_PIN3__USBPHY1_IDDIG                        102
-MX53_PAD_DI0_PIN4__IPU_DI0_PIN4                         103
-MX53_PAD_DI0_PIN4__GPIO4_20                             104
-MX53_PAD_DI0_PIN4__AUDMUX_AUD6_RXD                      105
-MX53_PAD_DI0_PIN4__ESDHC1_WP                            106
-MX53_PAD_DI0_PIN4__SDMA_DEBUG_YIELD                     107
-MX53_PAD_DI0_PIN4__EMI_EMI_DEBUG_4                      108
-MX53_PAD_DI0_PIN4__USBPHY1_HOSTDISCONNECT               109
-MX53_PAD_DISP0_DAT0__IPU_DISP0_DAT_0                    110
-MX53_PAD_DISP0_DAT0__GPIO4_21                           111
-MX53_PAD_DISP0_DAT0__CSPI_SCLK                          112
-MX53_PAD_DISP0_DAT0__USBOH3_USBH2_DATA_0                113
-MX53_PAD_DISP0_DAT0__SDMA_DEBUG_CORE_RUN                114
-MX53_PAD_DISP0_DAT0__EMI_EMI_DEBUG_5                    115
-MX53_PAD_DISP0_DAT0__USBPHY2_TXREADY                    116
-MX53_PAD_DISP0_DAT1__IPU_DISP0_DAT_1                    117
-MX53_PAD_DISP0_DAT1__GPIO4_22                           118
-MX53_PAD_DISP0_DAT1__CSPI_MOSI                          119
-MX53_PAD_DISP0_DAT1__USBOH3_USBH2_DATA_1                120
-MX53_PAD_DISP0_DAT1__SDMA_DEBUG_EVENT_CHANNEL_SEL       121
-MX53_PAD_DISP0_DAT1__EMI_EMI_DEBUG_6                    122
-MX53_PAD_DISP0_DAT1__USBPHY2_RXVALID                    123
-MX53_PAD_DISP0_DAT2__IPU_DISP0_DAT_2                    124
-MX53_PAD_DISP0_DAT2__GPIO4_23                           125
-MX53_PAD_DISP0_DAT2__CSPI_MISO                          126
-MX53_PAD_DISP0_DAT2__USBOH3_USBH2_DATA_2                127
-MX53_PAD_DISP0_DAT2__SDMA_DEBUG_MODE                    128
-MX53_PAD_DISP0_DAT2__EMI_EMI_DEBUG_7                    129
-MX53_PAD_DISP0_DAT2__USBPHY2_RXACTIVE                   130
-MX53_PAD_DISP0_DAT3__IPU_DISP0_DAT_3                    131
-MX53_PAD_DISP0_DAT3__GPIO4_24                           132
-MX53_PAD_DISP0_DAT3__CSPI_SS0                           133
-MX53_PAD_DISP0_DAT3__USBOH3_USBH2_DATA_3                134
-MX53_PAD_DISP0_DAT3__SDMA_DEBUG_BUS_ERROR               135
-MX53_PAD_DISP0_DAT3__EMI_EMI_DEBUG_8                    136
-MX53_PAD_DISP0_DAT3__USBPHY2_RXERROR                    137
-MX53_PAD_DISP0_DAT4__IPU_DISP0_DAT_4                    138
-MX53_PAD_DISP0_DAT4__GPIO4_25                           139
-MX53_PAD_DISP0_DAT4__CSPI_SS1                           140
-MX53_PAD_DISP0_DAT4__USBOH3_USBH2_DATA_4                141
-MX53_PAD_DISP0_DAT4__SDMA_DEBUG_BUS_RWB                 142
-MX53_PAD_DISP0_DAT4__EMI_EMI_DEBUG_9                    143
-MX53_PAD_DISP0_DAT4__USBPHY2_SIECLOCK                   144
-MX53_PAD_DISP0_DAT5__IPU_DISP0_DAT_5                    145
-MX53_PAD_DISP0_DAT5__GPIO4_26                           146
-MX53_PAD_DISP0_DAT5__CSPI_SS2                           147
-MX53_PAD_DISP0_DAT5__USBOH3_USBH2_DATA_5                148
-MX53_PAD_DISP0_DAT5__SDMA_DEBUG_MATCHED_DMBUS           149
-MX53_PAD_DISP0_DAT5__EMI_EMI_DEBUG_10                   150
-MX53_PAD_DISP0_DAT5__USBPHY2_LINESTATE_0                151
-MX53_PAD_DISP0_DAT6__IPU_DISP0_DAT_6                    152
-MX53_PAD_DISP0_DAT6__GPIO4_27                           153
-MX53_PAD_DISP0_DAT6__CSPI_SS3                           154
-MX53_PAD_DISP0_DAT6__USBOH3_USBH2_DATA_6                155
-MX53_PAD_DISP0_DAT6__SDMA_DEBUG_RTBUFFER_WRITE          156
-MX53_PAD_DISP0_DAT6__EMI_EMI_DEBUG_11                   157
-MX53_PAD_DISP0_DAT6__USBPHY2_LINESTATE_1                158
-MX53_PAD_DISP0_DAT7__IPU_DISP0_DAT_7                    159
-MX53_PAD_DISP0_DAT7__GPIO4_28                           160
-MX53_PAD_DISP0_DAT7__CSPI_RDY                           161
-MX53_PAD_DISP0_DAT7__USBOH3_USBH2_DATA_7                162
-MX53_PAD_DISP0_DAT7__SDMA_DEBUG_EVENT_CHANNEL_0         163
-MX53_PAD_DISP0_DAT7__EMI_EMI_DEBUG_12                   164
-MX53_PAD_DISP0_DAT7__USBPHY2_VBUSVALID                  165
-MX53_PAD_DISP0_DAT8__IPU_DISP0_DAT_8                    166
-MX53_PAD_DISP0_DAT8__GPIO4_29                           167
-MX53_PAD_DISP0_DAT8__PWM1_PWMO                          168
-MX53_PAD_DISP0_DAT8__WDOG1_WDOG_B                       169
-MX53_PAD_DISP0_DAT8__SDMA_DEBUG_EVENT_CHANNEL_1         170
-MX53_PAD_DISP0_DAT8__EMI_EMI_DEBUG_13                   171
-MX53_PAD_DISP0_DAT8__USBPHY2_AVALID                     172
-MX53_PAD_DISP0_DAT9__IPU_DISP0_DAT_9                    173
-MX53_PAD_DISP0_DAT9__GPIO4_30                           174
-MX53_PAD_DISP0_DAT9__PWM2_PWMO                          175
-MX53_PAD_DISP0_DAT9__WDOG2_WDOG_B                       176
-MX53_PAD_DISP0_DAT9__SDMA_DEBUG_EVENT_CHANNEL_2         177
-MX53_PAD_DISP0_DAT9__EMI_EMI_DEBUG_14                   178
-MX53_PAD_DISP0_DAT9__USBPHY2_VSTATUS_0                  179
-MX53_PAD_DISP0_DAT10__IPU_DISP0_DAT_10                  180
-MX53_PAD_DISP0_DAT10__GPIO4_31                          181
-MX53_PAD_DISP0_DAT10__USBOH3_USBH2_STP                  182
-MX53_PAD_DISP0_DAT10__SDMA_DEBUG_EVENT_CHANNEL_3        183
-MX53_PAD_DISP0_DAT10__EMI_EMI_DEBUG_15                  184
-MX53_PAD_DISP0_DAT10__USBPHY2_VSTATUS_1                 185
-MX53_PAD_DISP0_DAT11__IPU_DISP0_DAT_11                  186
-MX53_PAD_DISP0_DAT11__GPIO5_5                           187
-MX53_PAD_DISP0_DAT11__USBOH3_USBH2_NXT                  188
-MX53_PAD_DISP0_DAT11__SDMA_DEBUG_EVENT_CHANNEL_4        189
-MX53_PAD_DISP0_DAT11__EMI_EMI_DEBUG_16                  190
-MX53_PAD_DISP0_DAT11__USBPHY2_VSTATUS_2                 191
-MX53_PAD_DISP0_DAT12__IPU_DISP0_DAT_12                  192
-MX53_PAD_DISP0_DAT12__GPIO5_6                           193
-MX53_PAD_DISP0_DAT12__USBOH3_USBH2_CLK                  194
-MX53_PAD_DISP0_DAT12__SDMA_DEBUG_EVENT_CHANNEL_5        195
-MX53_PAD_DISP0_DAT12__EMI_EMI_DEBUG_17                  196
-MX53_PAD_DISP0_DAT12__USBPHY2_VSTATUS_3                 197
-MX53_PAD_DISP0_DAT13__IPU_DISP0_DAT_13                  198
-MX53_PAD_DISP0_DAT13__GPIO5_7                           199
-MX53_PAD_DISP0_DAT13__AUDMUX_AUD5_RXFS                  200
-MX53_PAD_DISP0_DAT13__SDMA_DEBUG_EVT_CHN_LINES_0        201
-MX53_PAD_DISP0_DAT13__EMI_EMI_DEBUG_18                  202
-MX53_PAD_DISP0_DAT13__USBPHY2_VSTATUS_4                 203
-MX53_PAD_DISP0_DAT14__IPU_DISP0_DAT_14                  204
-MX53_PAD_DISP0_DAT14__GPIO5_8                           205
-MX53_PAD_DISP0_DAT14__AUDMUX_AUD5_RXC                   206
-MX53_PAD_DISP0_DAT14__SDMA_DEBUG_EVT_CHN_LINES_1        207
-MX53_PAD_DISP0_DAT14__EMI_EMI_DEBUG_19                  208
-MX53_PAD_DISP0_DAT14__USBPHY2_VSTATUS_5                 209
-MX53_PAD_DISP0_DAT15__IPU_DISP0_DAT_15                  210
-MX53_PAD_DISP0_DAT15__GPIO5_9                           211
-MX53_PAD_DISP0_DAT15__ECSPI1_SS1                        212
-MX53_PAD_DISP0_DAT15__ECSPI2_SS1                        213
-MX53_PAD_DISP0_DAT15__SDMA_DEBUG_EVT_CHN_LINES_2        214
-MX53_PAD_DISP0_DAT15__EMI_EMI_DEBUG_20                  215
-MX53_PAD_DISP0_DAT15__USBPHY2_VSTATUS_6                 216
-MX53_PAD_DISP0_DAT16__IPU_DISP0_DAT_16                  217
-MX53_PAD_DISP0_DAT16__GPIO5_10                          218
-MX53_PAD_DISP0_DAT16__ECSPI2_MOSI                       219
-MX53_PAD_DISP0_DAT16__AUDMUX_AUD5_TXC                   220
-MX53_PAD_DISP0_DAT16__SDMA_EXT_EVENT_0                  221
-MX53_PAD_DISP0_DAT16__SDMA_DEBUG_EVT_CHN_LINES_3        222
-MX53_PAD_DISP0_DAT16__EMI_EMI_DEBUG_21                  223
-MX53_PAD_DISP0_DAT16__USBPHY2_VSTATUS_7                 224
-MX53_PAD_DISP0_DAT17__IPU_DISP0_DAT_17                  225
-MX53_PAD_DISP0_DAT17__GPIO5_11                          226
-MX53_PAD_DISP0_DAT17__ECSPI2_MISO                       227
-MX53_PAD_DISP0_DAT17__AUDMUX_AUD5_TXD                   228
-MX53_PAD_DISP0_DAT17__SDMA_EXT_EVENT_1                  229
-MX53_PAD_DISP0_DAT17__SDMA_DEBUG_EVT_CHN_LINES_4        230
-MX53_PAD_DISP0_DAT17__EMI_EMI_DEBUG_22                  231
-MX53_PAD_DISP0_DAT18__IPU_DISP0_DAT_18                  232
-MX53_PAD_DISP0_DAT18__GPIO5_12                          233
-MX53_PAD_DISP0_DAT18__ECSPI2_SS0                        234
-MX53_PAD_DISP0_DAT18__AUDMUX_AUD5_TXFS                  235
-MX53_PAD_DISP0_DAT18__AUDMUX_AUD4_RXFS                  236
-MX53_PAD_DISP0_DAT18__SDMA_DEBUG_EVT_CHN_LINES_5        237
-MX53_PAD_DISP0_DAT18__EMI_EMI_DEBUG_23                  238
-MX53_PAD_DISP0_DAT18__EMI_WEIM_CS_2                     239
-MX53_PAD_DISP0_DAT19__IPU_DISP0_DAT_19                  240
-MX53_PAD_DISP0_DAT19__GPIO5_13                          241
-MX53_PAD_DISP0_DAT19__ECSPI2_SCLK                       242
-MX53_PAD_DISP0_DAT19__AUDMUX_AUD5_RXD                   243
-MX53_PAD_DISP0_DAT19__AUDMUX_AUD4_RXC                   244
-MX53_PAD_DISP0_DAT19__SDMA_DEBUG_EVT_CHN_LINES_6        245
-MX53_PAD_DISP0_DAT19__EMI_EMI_DEBUG_24                  246
-MX53_PAD_DISP0_DAT19__EMI_WEIM_CS_3                     247
-MX53_PAD_DISP0_DAT20__IPU_DISP0_DAT_20                  248
-MX53_PAD_DISP0_DAT20__GPIO5_14                          249
-MX53_PAD_DISP0_DAT20__ECSPI1_SCLK                       250
-MX53_PAD_DISP0_DAT20__AUDMUX_AUD4_TXC                   251
-MX53_PAD_DISP0_DAT20__SDMA_DEBUG_EVT_CHN_LINES_7        252
-MX53_PAD_DISP0_DAT20__EMI_EMI_DEBUG_25                  253
-MX53_PAD_DISP0_DAT20__SATA_PHY_TDI                      254
-MX53_PAD_DISP0_DAT21__IPU_DISP0_DAT_21                  255
-MX53_PAD_DISP0_DAT21__GPIO5_15                          256
-MX53_PAD_DISP0_DAT21__ECSPI1_MOSI                       257
-MX53_PAD_DISP0_DAT21__AUDMUX_AUD4_TXD                   258
-MX53_PAD_DISP0_DAT21__SDMA_DEBUG_BUS_DEVICE_0           259
-MX53_PAD_DISP0_DAT21__EMI_EMI_DEBUG_26                  260
-MX53_PAD_DISP0_DAT21__SATA_PHY_TDO                      261
-MX53_PAD_DISP0_DAT22__IPU_DISP0_DAT_22                  262
-MX53_PAD_DISP0_DAT22__GPIO5_16                          263
-MX53_PAD_DISP0_DAT22__ECSPI1_MISO                       264
-MX53_PAD_DISP0_DAT22__AUDMUX_AUD4_TXFS                  265
-MX53_PAD_DISP0_DAT22__SDMA_DEBUG_BUS_DEVICE_1           266
-MX53_PAD_DISP0_DAT22__EMI_EMI_DEBUG_27                  267
-MX53_PAD_DISP0_DAT22__SATA_PHY_TCK                      268
-MX53_PAD_DISP0_DAT23__IPU_DISP0_DAT_23                  269
-MX53_PAD_DISP0_DAT23__GPIO5_17                          270
-MX53_PAD_DISP0_DAT23__ECSPI1_SS0                        271
-MX53_PAD_DISP0_DAT23__AUDMUX_AUD4_RXD                   272
-MX53_PAD_DISP0_DAT23__SDMA_DEBUG_BUS_DEVICE_2           273
-MX53_PAD_DISP0_DAT23__EMI_EMI_DEBUG_28                  274
-MX53_PAD_DISP0_DAT23__SATA_PHY_TMS                      275
-MX53_PAD_CSI0_PIXCLK__IPU_CSI0_PIXCLK                   276
-MX53_PAD_CSI0_PIXCLK__GPIO5_18                          277
-MX53_PAD_CSI0_PIXCLK__SDMA_DEBUG_PC_0                   278
-MX53_PAD_CSI0_PIXCLK__EMI_EMI_DEBUG_29                  279
-MX53_PAD_CSI0_MCLK__IPU_CSI0_HSYNC                      280
-MX53_PAD_CSI0_MCLK__GPIO5_19                            281
-MX53_PAD_CSI0_MCLK__CCM_CSI0_MCLK                       282
-MX53_PAD_CSI0_MCLK__SDMA_DEBUG_PC_1                     283
-MX53_PAD_CSI0_MCLK__EMI_EMI_DEBUG_30                    284
-MX53_PAD_CSI0_MCLK__TPIU_TRCTL                          285
-MX53_PAD_CSI0_DATA_EN__IPU_CSI0_DATA_EN                 286
-MX53_PAD_CSI0_DATA_EN__GPIO5_20                         287
-MX53_PAD_CSI0_DATA_EN__SDMA_DEBUG_PC_2                  288
-MX53_PAD_CSI0_DATA_EN__EMI_EMI_DEBUG_31                 289
-MX53_PAD_CSI0_DATA_EN__TPIU_TRCLK                       290
-MX53_PAD_CSI0_VSYNC__IPU_CSI0_VSYNC                     291
-MX53_PAD_CSI0_VSYNC__GPIO5_21                           292
-MX53_PAD_CSI0_VSYNC__SDMA_DEBUG_PC_3                    293
-MX53_PAD_CSI0_VSYNC__EMI_EMI_DEBUG_32                   294
-MX53_PAD_CSI0_VSYNC__TPIU_TRACE_0                       295
-MX53_PAD_CSI0_DAT4__IPU_CSI0_D_4                        296
-MX53_PAD_CSI0_DAT4__GPIO5_22                            297
-MX53_PAD_CSI0_DAT4__KPP_COL_5                           298
-MX53_PAD_CSI0_DAT4__ECSPI1_SCLK                         299
-MX53_PAD_CSI0_DAT4__USBOH3_USBH3_STP                    300
-MX53_PAD_CSI0_DAT4__AUDMUX_AUD3_TXC                     301
-MX53_PAD_CSI0_DAT4__EMI_EMI_DEBUG_33                    302
-MX53_PAD_CSI0_DAT4__TPIU_TRACE_1                        303
-MX53_PAD_CSI0_DAT5__IPU_CSI0_D_5                        304
-MX53_PAD_CSI0_DAT5__GPIO5_23                            305
-MX53_PAD_CSI0_DAT5__KPP_ROW_5                           306
-MX53_PAD_CSI0_DAT5__ECSPI1_MOSI                         307
-MX53_PAD_CSI0_DAT5__USBOH3_USBH3_NXT                    308
-MX53_PAD_CSI0_DAT5__AUDMUX_AUD3_TXD                     309
-MX53_PAD_CSI0_DAT5__EMI_EMI_DEBUG_34                    310
-MX53_PAD_CSI0_DAT5__TPIU_TRACE_2                        311
-MX53_PAD_CSI0_DAT6__IPU_CSI0_D_6                        312
-MX53_PAD_CSI0_DAT6__GPIO5_24                            313
-MX53_PAD_CSI0_DAT6__KPP_COL_6                           314
-MX53_PAD_CSI0_DAT6__ECSPI1_MISO                         315
-MX53_PAD_CSI0_DAT6__USBOH3_USBH3_CLK                    316
-MX53_PAD_CSI0_DAT6__AUDMUX_AUD3_TXFS                    317
-MX53_PAD_CSI0_DAT6__EMI_EMI_DEBUG_35                    318
-MX53_PAD_CSI0_DAT6__TPIU_TRACE_3                        319
-MX53_PAD_CSI0_DAT7__IPU_CSI0_D_7                        320
-MX53_PAD_CSI0_DAT7__GPIO5_25                            321
-MX53_PAD_CSI0_DAT7__KPP_ROW_6                           322
-MX53_PAD_CSI0_DAT7__ECSPI1_SS0                          323
-MX53_PAD_CSI0_DAT7__USBOH3_USBH3_DIR                    324
-MX53_PAD_CSI0_DAT7__AUDMUX_AUD3_RXD                     325
-MX53_PAD_CSI0_DAT7__EMI_EMI_DEBUG_36                    326
-MX53_PAD_CSI0_DAT7__TPIU_TRACE_4                        327
-MX53_PAD_CSI0_DAT8__IPU_CSI0_D_8                        328
-MX53_PAD_CSI0_DAT8__GPIO5_26                            329
-MX53_PAD_CSI0_DAT8__KPP_COL_7                           330
-MX53_PAD_CSI0_DAT8__ECSPI2_SCLK                         331
-MX53_PAD_CSI0_DAT8__USBOH3_USBH3_OC                     332
-MX53_PAD_CSI0_DAT8__I2C1_SDA                            333
-MX53_PAD_CSI0_DAT8__EMI_EMI_DEBUG_37                    334
-MX53_PAD_CSI0_DAT8__TPIU_TRACE_5                        335
-MX53_PAD_CSI0_DAT9__IPU_CSI0_D_9                        336
-MX53_PAD_CSI0_DAT9__GPIO5_27                            337
-MX53_PAD_CSI0_DAT9__KPP_ROW_7                           338
-MX53_PAD_CSI0_DAT9__ECSPI2_MOSI                         339
-MX53_PAD_CSI0_DAT9__USBOH3_USBH3_PWR                    340
-MX53_PAD_CSI0_DAT9__I2C1_SCL                            341
-MX53_PAD_CSI0_DAT9__EMI_EMI_DEBUG_38                    342
-MX53_PAD_CSI0_DAT9__TPIU_TRACE_6                        343
-MX53_PAD_CSI0_DAT10__IPU_CSI0_D_10                      344
-MX53_PAD_CSI0_DAT10__GPIO5_28                           345
-MX53_PAD_CSI0_DAT10__UART1_TXD_MUX                      346
-MX53_PAD_CSI0_DAT10__ECSPI2_MISO                        347
-MX53_PAD_CSI0_DAT10__AUDMUX_AUD3_RXC                    348
-MX53_PAD_CSI0_DAT10__SDMA_DEBUG_PC_4                    349
-MX53_PAD_CSI0_DAT10__EMI_EMI_DEBUG_39                   350
-MX53_PAD_CSI0_DAT10__TPIU_TRACE_7                       351
-MX53_PAD_CSI0_DAT11__IPU_CSI0_D_11                      352
-MX53_PAD_CSI0_DAT11__GPIO5_29                           353
-MX53_PAD_CSI0_DAT11__UART1_RXD_MUX                      354
-MX53_PAD_CSI0_DAT11__ECSPI2_SS0                         355
-MX53_PAD_CSI0_DAT11__AUDMUX_AUD3_RXFS                   356
-MX53_PAD_CSI0_DAT11__SDMA_DEBUG_PC_5                    357
-MX53_PAD_CSI0_DAT11__EMI_EMI_DEBUG_40                   358
-MX53_PAD_CSI0_DAT11__TPIU_TRACE_8                       359
-MX53_PAD_CSI0_DAT12__IPU_CSI0_D_12                      360
-MX53_PAD_CSI0_DAT12__GPIO5_30                           361
-MX53_PAD_CSI0_DAT12__UART4_TXD_MUX                      362
-MX53_PAD_CSI0_DAT12__USBOH3_USBH3_DATA_0                363
-MX53_PAD_CSI0_DAT12__SDMA_DEBUG_PC_6                    364
-MX53_PAD_CSI0_DAT12__EMI_EMI_DEBUG_41                   365
-MX53_PAD_CSI0_DAT12__TPIU_TRACE_9                       366
-MX53_PAD_CSI0_DAT13__IPU_CSI0_D_13                      367
-MX53_PAD_CSI0_DAT13__GPIO5_31                           368
-MX53_PAD_CSI0_DAT13__UART4_RXD_MUX                      369
-MX53_PAD_CSI0_DAT13__USBOH3_USBH3_DATA_1                370
-MX53_PAD_CSI0_DAT13__SDMA_DEBUG_PC_7                    371
-MX53_PAD_CSI0_DAT13__EMI_EMI_DEBUG_42                   372
-MX53_PAD_CSI0_DAT13__TPIU_TRACE_10                      373
-MX53_PAD_CSI0_DAT14__IPU_CSI0_D_14                      374
-MX53_PAD_CSI0_DAT14__GPIO6_0                            375
-MX53_PAD_CSI0_DAT14__UART5_TXD_MUX                      376
-MX53_PAD_CSI0_DAT14__USBOH3_USBH3_DATA_2                377
-MX53_PAD_CSI0_DAT14__SDMA_DEBUG_PC_8                    378
-MX53_PAD_CSI0_DAT14__EMI_EMI_DEBUG_43                   379
-MX53_PAD_CSI0_DAT14__TPIU_TRACE_11                      380
-MX53_PAD_CSI0_DAT15__IPU_CSI0_D_15                      381
-MX53_PAD_CSI0_DAT15__GPIO6_1                            382
-MX53_PAD_CSI0_DAT15__UART5_RXD_MUX                      383
-MX53_PAD_CSI0_DAT15__USBOH3_USBH3_DATA_3                384
-MX53_PAD_CSI0_DAT15__SDMA_DEBUG_PC_9                    385
-MX53_PAD_CSI0_DAT15__EMI_EMI_DEBUG_44                   386
-MX53_PAD_CSI0_DAT15__TPIU_TRACE_12                      387
-MX53_PAD_CSI0_DAT16__IPU_CSI0_D_16                      388
-MX53_PAD_CSI0_DAT16__GPIO6_2                            389
-MX53_PAD_CSI0_DAT16__UART4_RTS                          390
-MX53_PAD_CSI0_DAT16__USBOH3_USBH3_DATA_4                391
-MX53_PAD_CSI0_DAT16__SDMA_DEBUG_PC_10                   392
-MX53_PAD_CSI0_DAT16__EMI_EMI_DEBUG_45                   393
-MX53_PAD_CSI0_DAT16__TPIU_TRACE_13                      394
-MX53_PAD_CSI0_DAT17__IPU_CSI0_D_17                      395
-MX53_PAD_CSI0_DAT17__GPIO6_3                            396
-MX53_PAD_CSI0_DAT17__UART4_CTS                          397
-MX53_PAD_CSI0_DAT17__USBOH3_USBH3_DATA_5                398
-MX53_PAD_CSI0_DAT17__SDMA_DEBUG_PC_11                   399
-MX53_PAD_CSI0_DAT17__EMI_EMI_DEBUG_46                   400
-MX53_PAD_CSI0_DAT17__TPIU_TRACE_14                      401
-MX53_PAD_CSI0_DAT18__IPU_CSI0_D_18                      402
-MX53_PAD_CSI0_DAT18__GPIO6_4                            403
-MX53_PAD_CSI0_DAT18__UART5_RTS                          404
-MX53_PAD_CSI0_DAT18__USBOH3_USBH3_DATA_6                405
-MX53_PAD_CSI0_DAT18__SDMA_DEBUG_PC_12                   406
-MX53_PAD_CSI0_DAT18__EMI_EMI_DEBUG_47                   407
-MX53_PAD_CSI0_DAT18__TPIU_TRACE_15                      408
-MX53_PAD_CSI0_DAT19__IPU_CSI0_D_19                      409
-MX53_PAD_CSI0_DAT19__GPIO6_5                            410
-MX53_PAD_CSI0_DAT19__UART5_CTS                          411
-MX53_PAD_CSI0_DAT19__USBOH3_USBH3_DATA_7                412
-MX53_PAD_CSI0_DAT19__SDMA_DEBUG_PC_13                   413
-MX53_PAD_CSI0_DAT19__EMI_EMI_DEBUG_48                   414
-MX53_PAD_CSI0_DAT19__USBPHY2_BISTOK                     415
-MX53_PAD_EIM_A25__EMI_WEIM_A_25                         416
-MX53_PAD_EIM_A25__GPIO5_2                               417
-MX53_PAD_EIM_A25__ECSPI2_RDY                            418
-MX53_PAD_EIM_A25__IPU_DI1_PIN12                         419
-MX53_PAD_EIM_A25__CSPI_SS1                              420
-MX53_PAD_EIM_A25__IPU_DI0_D1_CS                         421
-MX53_PAD_EIM_A25__USBPHY1_BISTOK                        422
-MX53_PAD_EIM_EB2__EMI_WEIM_EB_2                         423
-MX53_PAD_EIM_EB2__GPIO2_30                              424
-MX53_PAD_EIM_EB2__CCM_DI1_EXT_CLK                       425
-MX53_PAD_EIM_EB2__IPU_SER_DISP1_CS                      426
-MX53_PAD_EIM_EB2__ECSPI1_SS0                            427
-MX53_PAD_EIM_EB2__I2C2_SCL                              428
-MX53_PAD_EIM_D16__EMI_WEIM_D_16                         429
-MX53_PAD_EIM_D16__GPIO3_16                              430
-MX53_PAD_EIM_D16__IPU_DI0_PIN5                          431
-MX53_PAD_EIM_D16__IPU_DISPB1_SER_CLK                    432
-MX53_PAD_EIM_D16__ECSPI1_SCLK                           433
-MX53_PAD_EIM_D16__I2C2_SDA                              434
-MX53_PAD_EIM_D17__EMI_WEIM_D_17                         435
-MX53_PAD_EIM_D17__GPIO3_17                              436
-MX53_PAD_EIM_D17__IPU_DI0_PIN6                          437
-MX53_PAD_EIM_D17__IPU_DISPB1_SER_DIN                    438
-MX53_PAD_EIM_D17__ECSPI1_MISO                           439
-MX53_PAD_EIM_D17__I2C3_SCL                              440
-MX53_PAD_EIM_D18__EMI_WEIM_D_18                         441
-MX53_PAD_EIM_D18__GPIO3_18                              442
-MX53_PAD_EIM_D18__IPU_DI0_PIN7                          443
-MX53_PAD_EIM_D18__IPU_DISPB1_SER_DIO                    444
-MX53_PAD_EIM_D18__ECSPI1_MOSI                           445
-MX53_PAD_EIM_D18__I2C3_SDA                              446
-MX53_PAD_EIM_D18__IPU_DI1_D0_CS                         447
-MX53_PAD_EIM_D19__EMI_WEIM_D_19                         448
-MX53_PAD_EIM_D19__GPIO3_19                              449
-MX53_PAD_EIM_D19__IPU_DI0_PIN8                          450
-MX53_PAD_EIM_D19__IPU_DISPB1_SER_RS                     451
-MX53_PAD_EIM_D19__ECSPI1_SS1                            452
-MX53_PAD_EIM_D19__EPIT1_EPITO                           453
-MX53_PAD_EIM_D19__UART1_CTS                             454
-MX53_PAD_EIM_D19__USBOH3_USBH2_OC                       455
-MX53_PAD_EIM_D20__EMI_WEIM_D_20                         456
-MX53_PAD_EIM_D20__GPIO3_20                              457
-MX53_PAD_EIM_D20__IPU_DI0_PIN16                         458
-MX53_PAD_EIM_D20__IPU_SER_DISP0_CS                      459
-MX53_PAD_EIM_D20__CSPI_SS0                              460
-MX53_PAD_EIM_D20__EPIT2_EPITO                           461
-MX53_PAD_EIM_D20__UART1_RTS                             462
-MX53_PAD_EIM_D20__USBOH3_USBH2_PWR                      463
-MX53_PAD_EIM_D21__EMI_WEIM_D_21                         464
-MX53_PAD_EIM_D21__GPIO3_21                              465
-MX53_PAD_EIM_D21__IPU_DI0_PIN17                         466
-MX53_PAD_EIM_D21__IPU_DISPB0_SER_CLK                    467
-MX53_PAD_EIM_D21__CSPI_SCLK                             468
-MX53_PAD_EIM_D21__I2C1_SCL                              469
-MX53_PAD_EIM_D21__USBOH3_USBOTG_OC                      470
-MX53_PAD_EIM_D22__EMI_WEIM_D_22                         471
-MX53_PAD_EIM_D22__GPIO3_22                              472
-MX53_PAD_EIM_D22__IPU_DI0_PIN1                          473
-MX53_PAD_EIM_D22__IPU_DISPB0_SER_DIN                    474
-MX53_PAD_EIM_D22__CSPI_MISO                             475
-MX53_PAD_EIM_D22__USBOH3_USBOTG_PWR                     476
-MX53_PAD_EIM_D23__EMI_WEIM_D_23                         477
-MX53_PAD_EIM_D23__GPIO3_23                              478
-MX53_PAD_EIM_D23__UART3_CTS                             479
-MX53_PAD_EIM_D23__UART1_DCD                             480
-MX53_PAD_EIM_D23__IPU_DI0_D0_CS                         481
-MX53_PAD_EIM_D23__IPU_DI1_PIN2                          482
-MX53_PAD_EIM_D23__IPU_CSI1_DATA_EN                      483
-MX53_PAD_EIM_D23__IPU_DI1_PIN14                         484
-MX53_PAD_EIM_EB3__EMI_WEIM_EB_3                         485
-MX53_PAD_EIM_EB3__GPIO2_31                              486
-MX53_PAD_EIM_EB3__UART3_RTS                             487
-MX53_PAD_EIM_EB3__UART1_RI                              488
-MX53_PAD_EIM_EB3__IPU_DI1_PIN3                          489
-MX53_PAD_EIM_EB3__IPU_CSI1_HSYNC                        490
-MX53_PAD_EIM_EB3__IPU_DI1_PIN16                         491
-MX53_PAD_EIM_D24__EMI_WEIM_D_24                         492
-MX53_PAD_EIM_D24__GPIO3_24                              493
-MX53_PAD_EIM_D24__UART3_TXD_MUX                         494
-MX53_PAD_EIM_D24__ECSPI1_SS2                            495
-MX53_PAD_EIM_D24__CSPI_SS2                              496
-MX53_PAD_EIM_D24__AUDMUX_AUD5_RXFS                      497
-MX53_PAD_EIM_D24__ECSPI2_SS2                            498
-MX53_PAD_EIM_D24__UART1_DTR                             499
-MX53_PAD_EIM_D25__EMI_WEIM_D_25                         500
-MX53_PAD_EIM_D25__GPIO3_25                              501
-MX53_PAD_EIM_D25__UART3_RXD_MUX                         502
-MX53_PAD_EIM_D25__ECSPI1_SS3                            503
-MX53_PAD_EIM_D25__CSPI_SS3                              504
-MX53_PAD_EIM_D25__AUDMUX_AUD5_RXC                       505
-MX53_PAD_EIM_D25__ECSPI2_SS3                            506
-MX53_PAD_EIM_D25__UART1_DSR                             507
-MX53_PAD_EIM_D26__EMI_WEIM_D_26                         508
-MX53_PAD_EIM_D26__GPIO3_26                              509
-MX53_PAD_EIM_D26__UART2_TXD_MUX                         510
-MX53_PAD_EIM_D26__FIRI_RXD                              511
-MX53_PAD_EIM_D26__IPU_CSI0_D_1                          512
-MX53_PAD_EIM_D26__IPU_DI1_PIN11                         513
-MX53_PAD_EIM_D26__IPU_SISG_2                            514
-MX53_PAD_EIM_D26__IPU_DISP1_DAT_22                      515
-MX53_PAD_EIM_D27__EMI_WEIM_D_27                         516
-MX53_PAD_EIM_D27__GPIO3_27                              517
-MX53_PAD_EIM_D27__UART2_RXD_MUX                         518
-MX53_PAD_EIM_D27__FIRI_TXD                              519
-MX53_PAD_EIM_D27__IPU_CSI0_D_0                          520
-MX53_PAD_EIM_D27__IPU_DI1_PIN13                         521
-MX53_PAD_EIM_D27__IPU_SISG_3                            522
-MX53_PAD_EIM_D27__IPU_DISP1_DAT_23                      523
-MX53_PAD_EIM_D28__EMI_WEIM_D_28                         524
-MX53_PAD_EIM_D28__GPIO3_28                              525
-MX53_PAD_EIM_D28__UART2_CTS                             526
-MX53_PAD_EIM_D28__IPU_DISPB0_SER_DIO                    527
-MX53_PAD_EIM_D28__CSPI_MOSI                             528
-MX53_PAD_EIM_D28__I2C1_SDA                              529
-MX53_PAD_EIM_D28__IPU_EXT_TRIG                          530
-MX53_PAD_EIM_D28__IPU_DI0_PIN13                         531
-MX53_PAD_EIM_D29__EMI_WEIM_D_29                         532
-MX53_PAD_EIM_D29__GPIO3_29                              533
-MX53_PAD_EIM_D29__UART2_RTS                             534
-MX53_PAD_EIM_D29__IPU_DISPB0_SER_RS                     535
-MX53_PAD_EIM_D29__CSPI_SS0                              536
-MX53_PAD_EIM_D29__IPU_DI1_PIN15                         537
-MX53_PAD_EIM_D29__IPU_CSI1_VSYNC                        538
-MX53_PAD_EIM_D29__IPU_DI0_PIN14                         539
-MX53_PAD_EIM_D30__EMI_WEIM_D_30                         540
-MX53_PAD_EIM_D30__GPIO3_30                              541
-MX53_PAD_EIM_D30__UART3_CTS                             542
-MX53_PAD_EIM_D30__IPU_CSI0_D_3                          543
-MX53_PAD_EIM_D30__IPU_DI0_PIN11                         544
-MX53_PAD_EIM_D30__IPU_DISP1_DAT_21                      545
-MX53_PAD_EIM_D30__USBOH3_USBH1_OC                       546
-MX53_PAD_EIM_D30__USBOH3_USBH2_OC                       547
-MX53_PAD_EIM_D31__EMI_WEIM_D_31                         548
-MX53_PAD_EIM_D31__GPIO3_31                              549
-MX53_PAD_EIM_D31__UART3_RTS                             550
-MX53_PAD_EIM_D31__IPU_CSI0_D_2                          551
-MX53_PAD_EIM_D31__IPU_DI0_PIN12                         552
-MX53_PAD_EIM_D31__IPU_DISP1_DAT_20                      553
-MX53_PAD_EIM_D31__USBOH3_USBH1_PWR                      554
-MX53_PAD_EIM_D31__USBOH3_USBH2_PWR                      555
-MX53_PAD_EIM_A24__EMI_WEIM_A_24                         556
-MX53_PAD_EIM_A24__GPIO5_4                               557
-MX53_PAD_EIM_A24__IPU_DISP1_DAT_19                      558
-MX53_PAD_EIM_A24__IPU_CSI1_D_19                         559
-MX53_PAD_EIM_A24__IPU_SISG_2                            560
-MX53_PAD_EIM_A24__USBPHY2_BVALID                        561
-MX53_PAD_EIM_A23__EMI_WEIM_A_23                         562
-MX53_PAD_EIM_A23__GPIO6_6                               563
-MX53_PAD_EIM_A23__IPU_DISP1_DAT_18                      564
-MX53_PAD_EIM_A23__IPU_CSI1_D_18                         565
-MX53_PAD_EIM_A23__IPU_SISG_3                            566
-MX53_PAD_EIM_A23__USBPHY2_ENDSESSION                    567
-MX53_PAD_EIM_A22__EMI_WEIM_A_22                         568
-MX53_PAD_EIM_A22__GPIO2_16                              569
-MX53_PAD_EIM_A22__IPU_DISP1_DAT_17                      570
-MX53_PAD_EIM_A22__IPU_CSI1_D_17                         571
-MX53_PAD_EIM_A22__SRC_BT_CFG1_7                         572
-MX53_PAD_EIM_A21__EMI_WEIM_A_21                         573
-MX53_PAD_EIM_A21__GPIO2_17                              574
-MX53_PAD_EIM_A21__IPU_DISP1_DAT_16                      575
-MX53_PAD_EIM_A21__IPU_CSI1_D_16                         576
-MX53_PAD_EIM_A21__SRC_BT_CFG1_6                         577
-MX53_PAD_EIM_A20__EMI_WEIM_A_20                         578
-MX53_PAD_EIM_A20__GPIO2_18                              579
-MX53_PAD_EIM_A20__IPU_DISP1_DAT_15                      580
-MX53_PAD_EIM_A20__IPU_CSI1_D_15                         581
-MX53_PAD_EIM_A20__SRC_BT_CFG1_5                         582
-MX53_PAD_EIM_A19__EMI_WEIM_A_19                         583
-MX53_PAD_EIM_A19__GPIO2_19                              584
-MX53_PAD_EIM_A19__IPU_DISP1_DAT_14                      585
-MX53_PAD_EIM_A19__IPU_CSI1_D_14                         586
-MX53_PAD_EIM_A19__SRC_BT_CFG1_4                         587
-MX53_PAD_EIM_A18__EMI_WEIM_A_18                         588
-MX53_PAD_EIM_A18__GPIO2_20                              589
-MX53_PAD_EIM_A18__IPU_DISP1_DAT_13                      590
-MX53_PAD_EIM_A18__IPU_CSI1_D_13                         591
-MX53_PAD_EIM_A18__SRC_BT_CFG1_3                         592
-MX53_PAD_EIM_A17__EMI_WEIM_A_17                         593
-MX53_PAD_EIM_A17__GPIO2_21                              594
-MX53_PAD_EIM_A17__IPU_DISP1_DAT_12                      595
-MX53_PAD_EIM_A17__IPU_CSI1_D_12                         596
-MX53_PAD_EIM_A17__SRC_BT_CFG1_2                         597
-MX53_PAD_EIM_A16__EMI_WEIM_A_16                         598
-MX53_PAD_EIM_A16__GPIO2_22                              599
-MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK                      600
-MX53_PAD_EIM_A16__IPU_CSI1_PIXCLK                       601
-MX53_PAD_EIM_A16__SRC_BT_CFG1_1                         602
-MX53_PAD_EIM_CS0__EMI_WEIM_CS_0                         603
-MX53_PAD_EIM_CS0__GPIO2_23                              604
-MX53_PAD_EIM_CS0__ECSPI2_SCLK                           605
-MX53_PAD_EIM_CS0__IPU_DI1_PIN5                          606
-MX53_PAD_EIM_CS1__EMI_WEIM_CS_1                         607
-MX53_PAD_EIM_CS1__GPIO2_24                              608
-MX53_PAD_EIM_CS1__ECSPI2_MOSI                           609
-MX53_PAD_EIM_CS1__IPU_DI1_PIN6                          610
-MX53_PAD_EIM_OE__EMI_WEIM_OE                            611
-MX53_PAD_EIM_OE__GPIO2_25                               612
-MX53_PAD_EIM_OE__ECSPI2_MISO                            613
-MX53_PAD_EIM_OE__IPU_DI1_PIN7                           614
-MX53_PAD_EIM_OE__USBPHY2_IDDIG                          615
-MX53_PAD_EIM_RW__EMI_WEIM_RW                            616
-MX53_PAD_EIM_RW__GPIO2_26                               617
-MX53_PAD_EIM_RW__ECSPI2_SS0                             618
-MX53_PAD_EIM_RW__IPU_DI1_PIN8                           619
-MX53_PAD_EIM_RW__USBPHY2_HOSTDISCONNECT                 620
-MX53_PAD_EIM_LBA__EMI_WEIM_LBA                          621
-MX53_PAD_EIM_LBA__GPIO2_27                              622
-MX53_PAD_EIM_LBA__ECSPI2_SS1                            623
-MX53_PAD_EIM_LBA__IPU_DI1_PIN17                         624
-MX53_PAD_EIM_LBA__SRC_BT_CFG1_0                         625
-MX53_PAD_EIM_EB0__EMI_WEIM_EB_0                         626
-MX53_PAD_EIM_EB0__GPIO2_28                              627
-MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11                      628
-MX53_PAD_EIM_EB0__IPU_CSI1_D_11                         629
-MX53_PAD_EIM_EB0__GPC_PMIC_RDY                          630
-MX53_PAD_EIM_EB0__SRC_BT_CFG2_7                         631
-MX53_PAD_EIM_EB1__EMI_WEIM_EB_1                         632
-MX53_PAD_EIM_EB1__GPIO2_29                              633
-MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10                      634
-MX53_PAD_EIM_EB1__IPU_CSI1_D_10                         635
-MX53_PAD_EIM_EB1__SRC_BT_CFG2_6                         636
-MX53_PAD_EIM_DA0__EMI_NAND_WEIM_DA_0                    637
-MX53_PAD_EIM_DA0__GPIO3_0                               638
-MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9                       639
-MX53_PAD_EIM_DA0__IPU_CSI1_D_9                          640
-MX53_PAD_EIM_DA0__SRC_BT_CFG2_5                         641
-MX53_PAD_EIM_DA1__EMI_NAND_WEIM_DA_1                    642
-MX53_PAD_EIM_DA1__GPIO3_1                               643
-MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8                       644
-MX53_PAD_EIM_DA1__IPU_CSI1_D_8                          645
-MX53_PAD_EIM_DA1__SRC_BT_CFG2_4                         646
-MX53_PAD_EIM_DA2__EMI_NAND_WEIM_DA_2                    647
-MX53_PAD_EIM_DA2__GPIO3_2                               648
-MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7                       649
-MX53_PAD_EIM_DA2__IPU_CSI1_D_7                          650
-MX53_PAD_EIM_DA2__SRC_BT_CFG2_3                         651
-MX53_PAD_EIM_DA3__EMI_NAND_WEIM_DA_3                    652
-MX53_PAD_EIM_DA3__GPIO3_3                               653
-MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6                       654
-MX53_PAD_EIM_DA3__IPU_CSI1_D_6                          655
-MX53_PAD_EIM_DA3__SRC_BT_CFG2_2                         656
-MX53_PAD_EIM_DA4__EMI_NAND_WEIM_DA_4                    657
-MX53_PAD_EIM_DA4__GPIO3_4                               658
-MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5                       659
-MX53_PAD_EIM_DA4__IPU_CSI1_D_5                          660
-MX53_PAD_EIM_DA4__SRC_BT_CFG3_7                         661
-MX53_PAD_EIM_DA5__EMI_NAND_WEIM_DA_5                    662
-MX53_PAD_EIM_DA5__GPIO3_5                               663
-MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4                       664
-MX53_PAD_EIM_DA5__IPU_CSI1_D_4                          665
-MX53_PAD_EIM_DA5__SRC_BT_CFG3_6                         666
-MX53_PAD_EIM_DA6__EMI_NAND_WEIM_DA_6                    667
-MX53_PAD_EIM_DA6__GPIO3_6                               668
-MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3                       669
-MX53_PAD_EIM_DA6__IPU_CSI1_D_3                          670
-MX53_PAD_EIM_DA6__SRC_BT_CFG3_5                         671
-MX53_PAD_EIM_DA7__EMI_NAND_WEIM_DA_7                    672
-MX53_PAD_EIM_DA7__GPIO3_7                               673
-MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2                       674
-MX53_PAD_EIM_DA7__IPU_CSI1_D_2                          675
-MX53_PAD_EIM_DA7__SRC_BT_CFG3_4                         676
-MX53_PAD_EIM_DA8__EMI_NAND_WEIM_DA_8                    677
-MX53_PAD_EIM_DA8__GPIO3_8                               678
-MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1                       679
-MX53_PAD_EIM_DA8__IPU_CSI1_D_1                          680
-MX53_PAD_EIM_DA8__SRC_BT_CFG3_3                         681
-MX53_PAD_EIM_DA9__EMI_NAND_WEIM_DA_9                    682
-MX53_PAD_EIM_DA9__GPIO3_9                               683
-MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0                       684
-MX53_PAD_EIM_DA9__IPU_CSI1_D_0                          685
-MX53_PAD_EIM_DA9__SRC_BT_CFG3_2                         686
-MX53_PAD_EIM_DA10__EMI_NAND_WEIM_DA_10                  687
-MX53_PAD_EIM_DA10__GPIO3_10                             688
-MX53_PAD_EIM_DA10__IPU_DI1_PIN15                        689
-MX53_PAD_EIM_DA10__IPU_CSI1_DATA_EN                     690
-MX53_PAD_EIM_DA10__SRC_BT_CFG3_1                        691
-MX53_PAD_EIM_DA11__EMI_NAND_WEIM_DA_11                  692
-MX53_PAD_EIM_DA11__GPIO3_11                             693
-MX53_PAD_EIM_DA11__IPU_DI1_PIN2                         694
-MX53_PAD_EIM_DA11__IPU_CSI1_HSYNC                       695
-MX53_PAD_EIM_DA12__EMI_NAND_WEIM_DA_12                  696
-MX53_PAD_EIM_DA12__GPIO3_12                             697
-MX53_PAD_EIM_DA12__IPU_DI1_PIN3                         698
-MX53_PAD_EIM_DA12__IPU_CSI1_VSYNC                       699
-MX53_PAD_EIM_DA13__EMI_NAND_WEIM_DA_13                  700
-MX53_PAD_EIM_DA13__GPIO3_13                             701
-MX53_PAD_EIM_DA13__IPU_DI1_D0_CS                        702
-MX53_PAD_EIM_DA13__CCM_DI1_EXT_CLK                      703
-MX53_PAD_EIM_DA14__EMI_NAND_WEIM_DA_14                  704
-MX53_PAD_EIM_DA14__GPIO3_14                             705
-MX53_PAD_EIM_DA14__IPU_DI1_D1_CS                        706
-MX53_PAD_EIM_DA14__CCM_DI0_EXT_CLK                      707
-MX53_PAD_EIM_DA15__EMI_NAND_WEIM_DA_15                  708
-MX53_PAD_EIM_DA15__GPIO3_15                             709
-MX53_PAD_EIM_DA15__IPU_DI1_PIN1                         710
-MX53_PAD_EIM_DA15__IPU_DI1_PIN4                         711
-MX53_PAD_NANDF_WE_B__EMI_NANDF_WE_B                     712
-MX53_PAD_NANDF_WE_B__GPIO6_12                           713
-MX53_PAD_NANDF_RE_B__EMI_NANDF_RE_B                     714
-MX53_PAD_NANDF_RE_B__GPIO6_13                           715
-MX53_PAD_EIM_WAIT__EMI_WEIM_WAIT                        716
-MX53_PAD_EIM_WAIT__GPIO5_0                              717
-MX53_PAD_EIM_WAIT__EMI_WEIM_DTACK_B                     718
-MX53_PAD_LVDS1_TX3_P__GPIO6_22                          719
-MX53_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3                     720
-MX53_PAD_LVDS1_TX2_P__GPIO6_24                          721
-MX53_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2                     722
-MX53_PAD_LVDS1_CLK_P__GPIO6_26                          723
-MX53_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK                     724
-MX53_PAD_LVDS1_TX1_P__GPIO6_28                          725
-MX53_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1                     726
-MX53_PAD_LVDS1_TX0_P__GPIO6_30                          727
-MX53_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0                     728
-MX53_PAD_LVDS0_TX3_P__GPIO7_22                          729
-MX53_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3                     730
-MX53_PAD_LVDS0_CLK_P__GPIO7_24                          731
-MX53_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK                     732
-MX53_PAD_LVDS0_TX2_P__GPIO7_26                          733
-MX53_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2                     734
-MX53_PAD_LVDS0_TX1_P__GPIO7_28                          735
-MX53_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1                     736
-MX53_PAD_LVDS0_TX0_P__GPIO7_30                          737
-MX53_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0                     738
-MX53_PAD_GPIO_10__GPIO4_0                               739
-MX53_PAD_GPIO_10__OSC32k_32K_OUT                        740
-MX53_PAD_GPIO_11__GPIO4_1                               741
-MX53_PAD_GPIO_12__GPIO4_2                               742
-MX53_PAD_GPIO_13__GPIO4_3                               743
-MX53_PAD_GPIO_14__GPIO4_4                               744
-MX53_PAD_NANDF_CLE__EMI_NANDF_CLE                       745
-MX53_PAD_NANDF_CLE__GPIO6_7                             746
-MX53_PAD_NANDF_CLE__USBPHY1_VSTATUS_0                   747
-MX53_PAD_NANDF_ALE__EMI_NANDF_ALE                       748
-MX53_PAD_NANDF_ALE__GPIO6_8                             749
-MX53_PAD_NANDF_ALE__USBPHY1_VSTATUS_1                   750
-MX53_PAD_NANDF_WP_B__EMI_NANDF_WP_B                     751
-MX53_PAD_NANDF_WP_B__GPIO6_9                            752
-MX53_PAD_NANDF_WP_B__USBPHY1_VSTATUS_2                  753
-MX53_PAD_NANDF_RB0__EMI_NANDF_RB_0                      754
-MX53_PAD_NANDF_RB0__GPIO6_10                            755
-MX53_PAD_NANDF_RB0__USBPHY1_VSTATUS_3                   756
-MX53_PAD_NANDF_CS0__EMI_NANDF_CS_0                      757
-MX53_PAD_NANDF_CS0__GPIO6_11                            758
-MX53_PAD_NANDF_CS0__USBPHY1_VSTATUS_4                   759
-MX53_PAD_NANDF_CS1__EMI_NANDF_CS_1                      760
-MX53_PAD_NANDF_CS1__GPIO6_14                            761
-MX53_PAD_NANDF_CS1__MLB_MLBCLK                          762
-MX53_PAD_NANDF_CS1__USBPHY1_VSTATUS_5                   763
-MX53_PAD_NANDF_CS2__EMI_NANDF_CS_2                      764
-MX53_PAD_NANDF_CS2__GPIO6_15                            765
-MX53_PAD_NANDF_CS2__IPU_SISG_0                          766
-MX53_PAD_NANDF_CS2__ESAI1_TX0                           767
-MX53_PAD_NANDF_CS2__EMI_WEIM_CRE                        768
-MX53_PAD_NANDF_CS2__CCM_CSI0_MCLK                       769
-MX53_PAD_NANDF_CS2__MLB_MLBSIG                          770
-MX53_PAD_NANDF_CS2__USBPHY1_VSTATUS_6                   771
-MX53_PAD_NANDF_CS3__EMI_NANDF_CS_3                      772
-MX53_PAD_NANDF_CS3__GPIO6_16                            773
-MX53_PAD_NANDF_CS3__IPU_SISG_1                          774
-MX53_PAD_NANDF_CS3__ESAI1_TX1                           775
-MX53_PAD_NANDF_CS3__EMI_WEIM_A_26                       776
-MX53_PAD_NANDF_CS3__MLB_MLBDAT                          777
-MX53_PAD_NANDF_CS3__USBPHY1_VSTATUS_7                   778
-MX53_PAD_FEC_MDIO__FEC_MDIO                             779
-MX53_PAD_FEC_MDIO__GPIO1_22                             780
-MX53_PAD_FEC_MDIO__ESAI1_SCKR                           781
-MX53_PAD_FEC_MDIO__FEC_COL                              782
-MX53_PAD_FEC_MDIO__RTC_CE_RTC_PS2                       783
-MX53_PAD_FEC_MDIO__SDMA_DEBUG_BUS_DEVICE_3              784
-MX53_PAD_FEC_MDIO__EMI_EMI_DEBUG_49                     785
-MX53_PAD_FEC_REF_CLK__FEC_TX_CLK                        786
-MX53_PAD_FEC_REF_CLK__GPIO1_23                          787
-MX53_PAD_FEC_REF_CLK__ESAI1_FSR                         788
-MX53_PAD_FEC_REF_CLK__SDMA_DEBUG_BUS_DEVICE_4           789
-MX53_PAD_FEC_REF_CLK__EMI_EMI_DEBUG_50                  790
-MX53_PAD_FEC_RX_ER__FEC_RX_ER                           791
-MX53_PAD_FEC_RX_ER__GPIO1_24                            792
-MX53_PAD_FEC_RX_ER__ESAI1_HCKR                          793
-MX53_PAD_FEC_RX_ER__FEC_RX_CLK                          794
-MX53_PAD_FEC_RX_ER__RTC_CE_RTC_PS3                      795
-MX53_PAD_FEC_CRS_DV__FEC_RX_DV                          796
-MX53_PAD_FEC_CRS_DV__GPIO1_25                           797
-MX53_PAD_FEC_CRS_DV__ESAI1_SCKT                         798
-MX53_PAD_FEC_RXD1__FEC_RDATA_1                          799
-MX53_PAD_FEC_RXD1__GPIO1_26                             800
-MX53_PAD_FEC_RXD1__ESAI1_FST                            801
-MX53_PAD_FEC_RXD1__MLB_MLBSIG                           802
-MX53_PAD_FEC_RXD1__RTC_CE_RTC_PS1                       803
-MX53_PAD_FEC_RXD0__FEC_RDATA_0                          804
-MX53_PAD_FEC_RXD0__GPIO1_27                             805
-MX53_PAD_FEC_RXD0__ESAI1_HCKT                           806
-MX53_PAD_FEC_RXD0__OSC32k_32K_OUT                       807
-MX53_PAD_FEC_TX_EN__FEC_TX_EN                           808
-MX53_PAD_FEC_TX_EN__GPIO1_28                            809
-MX53_PAD_FEC_TX_EN__ESAI1_TX3_RX2                       810
-MX53_PAD_FEC_TXD1__FEC_TDATA_1                          811
-MX53_PAD_FEC_TXD1__GPIO1_29                             812
-MX53_PAD_FEC_TXD1__ESAI1_TX2_RX3                        813
-MX53_PAD_FEC_TXD1__MLB_MLBCLK                           814
-MX53_PAD_FEC_TXD1__RTC_CE_RTC_PRSC_CLK                  815
-MX53_PAD_FEC_TXD0__FEC_TDATA_0                          816
-MX53_PAD_FEC_TXD0__GPIO1_30                             817
-MX53_PAD_FEC_TXD0__ESAI1_TX4_RX1                        818
-MX53_PAD_FEC_TXD0__USBPHY2_DATAOUT_0                    819
-MX53_PAD_FEC_MDC__FEC_MDC                               820
-MX53_PAD_FEC_MDC__GPIO1_31                              821
-MX53_PAD_FEC_MDC__ESAI1_TX5_RX0                         822
-MX53_PAD_FEC_MDC__MLB_MLBDAT                            823
-MX53_PAD_FEC_MDC__RTC_CE_RTC_ALARM1_TRIG                824
-MX53_PAD_FEC_MDC__USBPHY2_DATAOUT_1                     825
-MX53_PAD_PATA_DIOW__PATA_DIOW                           826
-MX53_PAD_PATA_DIOW__GPIO6_17                            827
-MX53_PAD_PATA_DIOW__UART1_TXD_MUX                       828
-MX53_PAD_PATA_DIOW__USBPHY2_DATAOUT_2                   829
-MX53_PAD_PATA_DMACK__PATA_DMACK                         830
-MX53_PAD_PATA_DMACK__GPIO6_18                           831
-MX53_PAD_PATA_DMACK__UART1_RXD_MUX                      832
-MX53_PAD_PATA_DMACK__USBPHY2_DATAOUT_3                  833
-MX53_PAD_PATA_DMARQ__PATA_DMARQ                         834
-MX53_PAD_PATA_DMARQ__GPIO7_0                            835
-MX53_PAD_PATA_DMARQ__UART2_TXD_MUX                      836
-MX53_PAD_PATA_DMARQ__CCM_CCM_OUT_0                      837
-MX53_PAD_PATA_DMARQ__USBPHY2_DATAOUT_4                  838
-MX53_PAD_PATA_BUFFER_EN__PATA_BUFFER_EN                 839
-MX53_PAD_PATA_BUFFER_EN__GPIO7_1                        840
-MX53_PAD_PATA_BUFFER_EN__UART2_RXD_MUX                  841
-MX53_PAD_PATA_BUFFER_EN__CCM_CCM_OUT_1                  842
-MX53_PAD_PATA_BUFFER_EN__USBPHY2_DATAOUT_5              843
-MX53_PAD_PATA_INTRQ__PATA_INTRQ                         844
-MX53_PAD_PATA_INTRQ__GPIO7_2                            845
-MX53_PAD_PATA_INTRQ__UART2_CTS                          846
-MX53_PAD_PATA_INTRQ__CAN1_TXCAN                         847
-MX53_PAD_PATA_INTRQ__CCM_CCM_OUT_2                      848
-MX53_PAD_PATA_INTRQ__USBPHY2_DATAOUT_6                  849
-MX53_PAD_PATA_DIOR__PATA_DIOR                           850
-MX53_PAD_PATA_DIOR__GPIO7_3                             851
-MX53_PAD_PATA_DIOR__UART2_RTS                           852
-MX53_PAD_PATA_DIOR__CAN1_RXCAN                          853
-MX53_PAD_PATA_DIOR__USBPHY2_DATAOUT_7                   854
-MX53_PAD_PATA_RESET_B__PATA_PATA_RESET_B                855
-MX53_PAD_PATA_RESET_B__GPIO7_4                          856
-MX53_PAD_PATA_RESET_B__ESDHC3_CMD                       857
-MX53_PAD_PATA_RESET_B__UART1_CTS                        858
-MX53_PAD_PATA_RESET_B__CAN2_TXCAN                       859
-MX53_PAD_PATA_RESET_B__USBPHY1_DATAOUT_0                860
-MX53_PAD_PATA_IORDY__PATA_IORDY                         861
-MX53_PAD_PATA_IORDY__GPIO7_5                            862
-MX53_PAD_PATA_IORDY__ESDHC3_CLK                         863
-MX53_PAD_PATA_IORDY__UART1_RTS                          864
-MX53_PAD_PATA_IORDY__CAN2_RXCAN                         865
-MX53_PAD_PATA_IORDY__USBPHY1_DATAOUT_1                  866
-MX53_PAD_PATA_DA_0__PATA_DA_0                           867
-MX53_PAD_PATA_DA_0__GPIO7_6                             868
-MX53_PAD_PATA_DA_0__ESDHC3_RST                          869
-MX53_PAD_PATA_DA_0__OWIRE_LINE                          870
-MX53_PAD_PATA_DA_0__USBPHY1_DATAOUT_2                   871
-MX53_PAD_PATA_DA_1__PATA_DA_1                           872
-MX53_PAD_PATA_DA_1__GPIO7_7                             873
-MX53_PAD_PATA_DA_1__ESDHC4_CMD                          874
-MX53_PAD_PATA_DA_1__UART3_CTS                           875
-MX53_PAD_PATA_DA_1__USBPHY1_DATAOUT_3                   876
-MX53_PAD_PATA_DA_2__PATA_DA_2                           877
-MX53_PAD_PATA_DA_2__GPIO7_8                             878
-MX53_PAD_PATA_DA_2__ESDHC4_CLK                          879
-MX53_PAD_PATA_DA_2__UART3_RTS                           880
-MX53_PAD_PATA_DA_2__USBPHY1_DATAOUT_4                   881
-MX53_PAD_PATA_CS_0__PATA_CS_0                           882
-MX53_PAD_PATA_CS_0__GPIO7_9                             883
-MX53_PAD_PATA_CS_0__UART3_TXD_MUX                       884
-MX53_PAD_PATA_CS_0__USBPHY1_DATAOUT_5                   885
-MX53_PAD_PATA_CS_1__PATA_CS_1                           886
-MX53_PAD_PATA_CS_1__GPIO7_10                            887
-MX53_PAD_PATA_CS_1__UART3_RXD_MUX                       888
-MX53_PAD_PATA_CS_1__USBPHY1_DATAOUT_6                   889
-MX53_PAD_PATA_DATA0__PATA_DATA_0                        890
-MX53_PAD_PATA_DATA0__GPIO2_0                            891
-MX53_PAD_PATA_DATA0__EMI_NANDF_D_0                      892
-MX53_PAD_PATA_DATA0__ESDHC3_DAT4                        893
-MX53_PAD_PATA_DATA0__GPU3d_GPU_DEBUG_OUT_0              894
-MX53_PAD_PATA_DATA0__IPU_DIAG_BUS_0                     895
-MX53_PAD_PATA_DATA0__USBPHY1_DATAOUT_7                  896
-MX53_PAD_PATA_DATA1__PATA_DATA_1                        897
-MX53_PAD_PATA_DATA1__GPIO2_1                            898
-MX53_PAD_PATA_DATA1__EMI_NANDF_D_1                      899
-MX53_PAD_PATA_DATA1__ESDHC3_DAT5                        900
-MX53_PAD_PATA_DATA1__GPU3d_GPU_DEBUG_OUT_1              901
-MX53_PAD_PATA_DATA1__IPU_DIAG_BUS_1                     902
-MX53_PAD_PATA_DATA2__PATA_DATA_2                        903
-MX53_PAD_PATA_DATA2__GPIO2_2                            904
-MX53_PAD_PATA_DATA2__EMI_NANDF_D_2                      905
-MX53_PAD_PATA_DATA2__ESDHC3_DAT6                        906
-MX53_PAD_PATA_DATA2__GPU3d_GPU_DEBUG_OUT_2              907
-MX53_PAD_PATA_DATA2__IPU_DIAG_BUS_2                     908
-MX53_PAD_PATA_DATA3__PATA_DATA_3                        909
-MX53_PAD_PATA_DATA3__GPIO2_3                            910
-MX53_PAD_PATA_DATA3__EMI_NANDF_D_3                      911
-MX53_PAD_PATA_DATA3__ESDHC3_DAT7                        912
-MX53_PAD_PATA_DATA3__GPU3d_GPU_DEBUG_OUT_3              913
-MX53_PAD_PATA_DATA3__IPU_DIAG_BUS_3                     914
-MX53_PAD_PATA_DATA4__PATA_DATA_4                        915
-MX53_PAD_PATA_DATA4__GPIO2_4                            916
-MX53_PAD_PATA_DATA4__EMI_NANDF_D_4                      917
-MX53_PAD_PATA_DATA4__ESDHC4_DAT4                        918
-MX53_PAD_PATA_DATA4__GPU3d_GPU_DEBUG_OUT_4              919
-MX53_PAD_PATA_DATA4__IPU_DIAG_BUS_4                     920
-MX53_PAD_PATA_DATA5__PATA_DATA_5                        921
-MX53_PAD_PATA_DATA5__GPIO2_5                            922
-MX53_PAD_PATA_DATA5__EMI_NANDF_D_5                      923
-MX53_PAD_PATA_DATA5__ESDHC4_DAT5                        924
-MX53_PAD_PATA_DATA5__GPU3d_GPU_DEBUG_OUT_5              925
-MX53_PAD_PATA_DATA5__IPU_DIAG_BUS_5                     926
-MX53_PAD_PATA_DATA6__PATA_DATA_6                        927
-MX53_PAD_PATA_DATA6__GPIO2_6                            928
-MX53_PAD_PATA_DATA6__EMI_NANDF_D_6                      929
-MX53_PAD_PATA_DATA6__ESDHC4_DAT6                        930
-MX53_PAD_PATA_DATA6__GPU3d_GPU_DEBUG_OUT_6              931
-MX53_PAD_PATA_DATA6__IPU_DIAG_BUS_6                     932
-MX53_PAD_PATA_DATA7__PATA_DATA_7                        933
-MX53_PAD_PATA_DATA7__GPIO2_7                            934
-MX53_PAD_PATA_DATA7__EMI_NANDF_D_7                      935
-MX53_PAD_PATA_DATA7__ESDHC4_DAT7                        936
-MX53_PAD_PATA_DATA7__GPU3d_GPU_DEBUG_OUT_7              937
-MX53_PAD_PATA_DATA7__IPU_DIAG_BUS_7                     938
-MX53_PAD_PATA_DATA8__PATA_DATA_8                        939
-MX53_PAD_PATA_DATA8__GPIO2_8                            940
-MX53_PAD_PATA_DATA8__ESDHC1_DAT4                        941
-MX53_PAD_PATA_DATA8__EMI_NANDF_D_8                      942
-MX53_PAD_PATA_DATA8__ESDHC3_DAT0                        943
-MX53_PAD_PATA_DATA8__GPU3d_GPU_DEBUG_OUT_8              944
-MX53_PAD_PATA_DATA8__IPU_DIAG_BUS_8                     945
-MX53_PAD_PATA_DATA9__PATA_DATA_9                        946
-MX53_PAD_PATA_DATA9__GPIO2_9                            947
-MX53_PAD_PATA_DATA9__ESDHC1_DAT5                        948
-MX53_PAD_PATA_DATA9__EMI_NANDF_D_9                      949
-MX53_PAD_PATA_DATA9__ESDHC3_DAT1                        950
-MX53_PAD_PATA_DATA9__GPU3d_GPU_DEBUG_OUT_9              951
-MX53_PAD_PATA_DATA9__IPU_DIAG_BUS_9                     952
-MX53_PAD_PATA_DATA10__PATA_DATA_10                      953
-MX53_PAD_PATA_DATA10__GPIO2_10                          954
-MX53_PAD_PATA_DATA10__ESDHC1_DAT6                       955
-MX53_PAD_PATA_DATA10__EMI_NANDF_D_10                    956
-MX53_PAD_PATA_DATA10__ESDHC3_DAT2                       957
-MX53_PAD_PATA_DATA10__GPU3d_GPU_DEBUG_OUT_10            958
-MX53_PAD_PATA_DATA10__IPU_DIAG_BUS_10                   959
-MX53_PAD_PATA_DATA11__PATA_DATA_11                      960
-MX53_PAD_PATA_DATA11__GPIO2_11                          961
-MX53_PAD_PATA_DATA11__ESDHC1_DAT7                       962
-MX53_PAD_PATA_DATA11__EMI_NANDF_D_11                    963
-MX53_PAD_PATA_DATA11__ESDHC3_DAT3                       964
-MX53_PAD_PATA_DATA11__GPU3d_GPU_DEBUG_OUT_11            965
-MX53_PAD_PATA_DATA11__IPU_DIAG_BUS_11                   966
-MX53_PAD_PATA_DATA12__PATA_DATA_12                      967
-MX53_PAD_PATA_DATA12__GPIO2_12                          968
-MX53_PAD_PATA_DATA12__ESDHC2_DAT4                       969
-MX53_PAD_PATA_DATA12__EMI_NANDF_D_12                    970
-MX53_PAD_PATA_DATA12__ESDHC4_DAT0                       971
-MX53_PAD_PATA_DATA12__GPU3d_GPU_DEBUG_OUT_12            972
-MX53_PAD_PATA_DATA12__IPU_DIAG_BUS_12                   973
-MX53_PAD_PATA_DATA13__PATA_DATA_13                      974
-MX53_PAD_PATA_DATA13__GPIO2_13                          975
-MX53_PAD_PATA_DATA13__ESDHC2_DAT5                       976
-MX53_PAD_PATA_DATA13__EMI_NANDF_D_13                    977
-MX53_PAD_PATA_DATA13__ESDHC4_DAT1                       978
-MX53_PAD_PATA_DATA13__GPU3d_GPU_DEBUG_OUT_13            979
-MX53_PAD_PATA_DATA13__IPU_DIAG_BUS_13                   980
-MX53_PAD_PATA_DATA14__PATA_DATA_14                      981
-MX53_PAD_PATA_DATA14__GPIO2_14                          982
-MX53_PAD_PATA_DATA14__ESDHC2_DAT6                       983
-MX53_PAD_PATA_DATA14__EMI_NANDF_D_14                    984
-MX53_PAD_PATA_DATA14__ESDHC4_DAT2                       985
-MX53_PAD_PATA_DATA14__GPU3d_GPU_DEBUG_OUT_14            986
-MX53_PAD_PATA_DATA14__IPU_DIAG_BUS_14                   987
-MX53_PAD_PATA_DATA15__PATA_DATA_15                      988
-MX53_PAD_PATA_DATA15__GPIO2_15                          989
-MX53_PAD_PATA_DATA15__ESDHC2_DAT7                       990
-MX53_PAD_PATA_DATA15__EMI_NANDF_D_15                    991
-MX53_PAD_PATA_DATA15__ESDHC4_DAT3                       992
-MX53_PAD_PATA_DATA15__GPU3d_GPU_DEBUG_OUT_15            993
-MX53_PAD_PATA_DATA15__IPU_DIAG_BUS_15                   994
-MX53_PAD_SD1_DATA0__ESDHC1_DAT0                         995
-MX53_PAD_SD1_DATA0__GPIO1_16                            996
-MX53_PAD_SD1_DATA0__GPT_CAPIN1                          997
-MX53_PAD_SD1_DATA0__CSPI_MISO                           998
-MX53_PAD_SD1_DATA0__CCM_PLL3_BYP                        999
-MX53_PAD_SD1_DATA1__ESDHC1_DAT1                         1000
-MX53_PAD_SD1_DATA1__GPIO1_17                            1001
-MX53_PAD_SD1_DATA1__GPT_CAPIN2                          1002
-MX53_PAD_SD1_DATA1__CSPI_SS0                            1003
-MX53_PAD_SD1_DATA1__CCM_PLL4_BYP                        1004
-MX53_PAD_SD1_CMD__ESDHC1_CMD                            1005
-MX53_PAD_SD1_CMD__GPIO1_18                              1006
-MX53_PAD_SD1_CMD__GPT_CMPOUT1                           1007
-MX53_PAD_SD1_CMD__CSPI_MOSI                             1008
-MX53_PAD_SD1_CMD__CCM_PLL1_BYP                          1009
-MX53_PAD_SD1_DATA2__ESDHC1_DAT2                         1010
-MX53_PAD_SD1_DATA2__GPIO1_19                            1011
-MX53_PAD_SD1_DATA2__GPT_CMPOUT2                         1012
-MX53_PAD_SD1_DATA2__PWM2_PWMO                           1013
-MX53_PAD_SD1_DATA2__WDOG1_WDOG_B                        1014
-MX53_PAD_SD1_DATA2__CSPI_SS1                            1015
-MX53_PAD_SD1_DATA2__WDOG1_WDOG_RST_B_DEB                1016
-MX53_PAD_SD1_DATA2__CCM_PLL2_BYP                        1017
-MX53_PAD_SD1_CLK__ESDHC1_CLK                            1018
-MX53_PAD_SD1_CLK__GPIO1_20                              1019
-MX53_PAD_SD1_CLK__OSC32k_32K_OUT                        1020
-MX53_PAD_SD1_CLK__GPT_CLKIN                             1021
-MX53_PAD_SD1_CLK__CSPI_SCLK                             1022
-MX53_PAD_SD1_CLK__SATA_PHY_DTB_0                        1023
-MX53_PAD_SD1_DATA3__ESDHC1_DAT3                         1024
-MX53_PAD_SD1_DATA3__GPIO1_21                            1025
-MX53_PAD_SD1_DATA3__GPT_CMPOUT3                         1026
-MX53_PAD_SD1_DATA3__PWM1_PWMO                           1027
-MX53_PAD_SD1_DATA3__WDOG2_WDOG_B                        1028
-MX53_PAD_SD1_DATA3__CSPI_SS2                            1029
-MX53_PAD_SD1_DATA3__WDOG2_WDOG_RST_B_DEB                1030
-MX53_PAD_SD1_DATA3__SATA_PHY_DTB_1                      1031
-MX53_PAD_SD2_CLK__ESDHC2_CLK                            1032
-MX53_PAD_SD2_CLK__GPIO1_10                              1033
-MX53_PAD_SD2_CLK__KPP_COL_5                             1034
-MX53_PAD_SD2_CLK__AUDMUX_AUD4_RXFS                      1035
-MX53_PAD_SD2_CLK__CSPI_SCLK                             1036
-MX53_PAD_SD2_CLK__SCC_RANDOM_V                          1037
-MX53_PAD_SD2_CMD__ESDHC2_CMD                            1038
-MX53_PAD_SD2_CMD__GPIO1_11                              1039
-MX53_PAD_SD2_CMD__KPP_ROW_5                             1040
-MX53_PAD_SD2_CMD__AUDMUX_AUD4_RXC                       1041
-MX53_PAD_SD2_CMD__CSPI_MOSI                             1042
-MX53_PAD_SD2_CMD__SCC_RANDOM                            1043
-MX53_PAD_SD2_DATA3__ESDHC2_DAT3                         1044
-MX53_PAD_SD2_DATA3__GPIO1_12                            1045
-MX53_PAD_SD2_DATA3__KPP_COL_6                           1046
-MX53_PAD_SD2_DATA3__AUDMUX_AUD4_TXC                     1047
-MX53_PAD_SD2_DATA3__CSPI_SS2                            1048
-MX53_PAD_SD2_DATA3__SJC_DONE                            1049
-MX53_PAD_SD2_DATA2__ESDHC2_DAT2                         1050
-MX53_PAD_SD2_DATA2__GPIO1_13                            1051
-MX53_PAD_SD2_DATA2__KPP_ROW_6                           1052
-MX53_PAD_SD2_DATA2__AUDMUX_AUD4_TXD                     1053
-MX53_PAD_SD2_DATA2__CSPI_SS1                            1054
-MX53_PAD_SD2_DATA2__SJC_FAIL                            1055
-MX53_PAD_SD2_DATA1__ESDHC2_DAT1                         1056
-MX53_PAD_SD2_DATA1__GPIO1_14                            1057
-MX53_PAD_SD2_DATA1__KPP_COL_7                           1058
-MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS                    1059
-MX53_PAD_SD2_DATA1__CSPI_SS0                            1060
-MX53_PAD_SD2_DATA1__RTIC_SEC_VIO                        1061
-MX53_PAD_SD2_DATA0__ESDHC2_DAT0                         1062
-MX53_PAD_SD2_DATA0__GPIO1_15                            1063
-MX53_PAD_SD2_DATA0__KPP_ROW_7                           1064
-MX53_PAD_SD2_DATA0__AUDMUX_AUD4_RXD                     1065
-MX53_PAD_SD2_DATA0__CSPI_MISO                           1066
-MX53_PAD_SD2_DATA0__RTIC_DONE_INT                       1067
-MX53_PAD_GPIO_0__CCM_CLKO                               1068
-MX53_PAD_GPIO_0__GPIO1_0                                1069
-MX53_PAD_GPIO_0__KPP_COL_5                              1070
-MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK                       1071
-MX53_PAD_GPIO_0__EPIT1_EPITO                            1072
-MX53_PAD_GPIO_0__SRTC_ALARM_DEB                         1073
-MX53_PAD_GPIO_0__USBOH3_USBH1_PWR                       1074
-MX53_PAD_GPIO_0__CSU_TD                                 1075
-MX53_PAD_GPIO_1__ESAI1_SCKR                             1076
-MX53_PAD_GPIO_1__GPIO1_1                                1077
-MX53_PAD_GPIO_1__KPP_ROW_5                              1078
-MX53_PAD_GPIO_1__CCM_SSI_EXT2_CLK                       1079
-MX53_PAD_GPIO_1__PWM2_PWMO                              1080
-MX53_PAD_GPIO_1__WDOG2_WDOG_B                           1081
-MX53_PAD_GPIO_1__ESDHC1_CD                              1082
-MX53_PAD_GPIO_1__SRC_TESTER_ACK                         1083
-MX53_PAD_GPIO_9__ESAI1_FSR                              1084
-MX53_PAD_GPIO_9__GPIO1_9                                1085
-MX53_PAD_GPIO_9__KPP_COL_6                              1086
-MX53_PAD_GPIO_9__CCM_REF_EN_B                           1087
-MX53_PAD_GPIO_9__PWM1_PWMO                              1088
-MX53_PAD_GPIO_9__WDOG1_WDOG_B                           1089
-MX53_PAD_GPIO_9__ESDHC1_WP                              1090
-MX53_PAD_GPIO_9__SCC_FAIL_STATE                         1091
-MX53_PAD_GPIO_3__ESAI1_HCKR                             1092
-MX53_PAD_GPIO_3__GPIO1_3                                1093
-MX53_PAD_GPIO_3__I2C3_SCL                               1094
-MX53_PAD_GPIO_3__DPLLIP1_TOG_EN                         1095
-MX53_PAD_GPIO_3__CCM_CLKO2                              1096
-MX53_PAD_GPIO_3__OBSERVE_MUX_OBSRV_INT_OUT0             1097
-MX53_PAD_GPIO_3__USBOH3_USBH1_OC                        1098
-MX53_PAD_GPIO_3__MLB_MLBCLK                             1099
-MX53_PAD_GPIO_6__ESAI1_SCKT                             1100
-MX53_PAD_GPIO_6__GPIO1_6                                1101
-MX53_PAD_GPIO_6__I2C3_SDA                               1102
-MX53_PAD_GPIO_6__CCM_CCM_OUT_0                          1103
-MX53_PAD_GPIO_6__CSU_CSU_INT_DEB                        1104
-MX53_PAD_GPIO_6__OBSERVE_MUX_OBSRV_INT_OUT1             1105
-MX53_PAD_GPIO_6__ESDHC2_LCTL                            1106
-MX53_PAD_GPIO_6__MLB_MLBSIG                             1107
-MX53_PAD_GPIO_2__ESAI1_FST                              1108
-MX53_PAD_GPIO_2__GPIO1_2                                1109
-MX53_PAD_GPIO_2__KPP_ROW_6                              1110
-MX53_PAD_GPIO_2__CCM_CCM_OUT_1                          1111
-MX53_PAD_GPIO_2__CSU_CSU_ALARM_AUT_0                    1112
-MX53_PAD_GPIO_2__OBSERVE_MUX_OBSRV_INT_OUT2             1113
-MX53_PAD_GPIO_2__ESDHC2_WP                              1114
-MX53_PAD_GPIO_2__MLB_MLBDAT                             1115
-MX53_PAD_GPIO_4__ESAI1_HCKT                             1116
-MX53_PAD_GPIO_4__GPIO1_4                                1117
-MX53_PAD_GPIO_4__KPP_COL_7                              1118
-MX53_PAD_GPIO_4__CCM_CCM_OUT_2                          1119
-MX53_PAD_GPIO_4__CSU_CSU_ALARM_AUT_1                    1120
-MX53_PAD_GPIO_4__OBSERVE_MUX_OBSRV_INT_OUT3             1121
-MX53_PAD_GPIO_4__ESDHC2_CD                              1122
-MX53_PAD_GPIO_4__SCC_SEC_STATE                          1123
-MX53_PAD_GPIO_5__ESAI1_TX2_RX3                          1124
-MX53_PAD_GPIO_5__GPIO1_5                                1125
-MX53_PAD_GPIO_5__KPP_ROW_7                              1126
-MX53_PAD_GPIO_5__CCM_CLKO                               1127
-MX53_PAD_GPIO_5__CSU_CSU_ALARM_AUT_2                    1128
-MX53_PAD_GPIO_5__OBSERVE_MUX_OBSRV_INT_OUT4             1129
-MX53_PAD_GPIO_5__I2C3_SCL                               1130
-MX53_PAD_GPIO_5__CCM_PLL1_BYP                           1131
-MX53_PAD_GPIO_7__ESAI1_TX4_RX1                          1132
-MX53_PAD_GPIO_7__GPIO1_7                                1133
-MX53_PAD_GPIO_7__EPIT1_EPITO                            1134
-MX53_PAD_GPIO_7__CAN1_TXCAN                             1135
-MX53_PAD_GPIO_7__UART2_TXD_MUX                          1136
-MX53_PAD_GPIO_7__FIRI_RXD                               1137
-MX53_PAD_GPIO_7__SPDIF_PLOCK                            1138
-MX53_PAD_GPIO_7__CCM_PLL2_BYP                           1139
-MX53_PAD_GPIO_8__ESAI1_TX5_RX0                          1140
-MX53_PAD_GPIO_8__GPIO1_8                                1141
-MX53_PAD_GPIO_8__EPIT2_EPITO                            1142
-MX53_PAD_GPIO_8__CAN1_RXCAN                             1143
-MX53_PAD_GPIO_8__UART2_RXD_MUX                          1144
-MX53_PAD_GPIO_8__FIRI_TXD                               1145
-MX53_PAD_GPIO_8__SPDIF_SRCLK                            1146
-MX53_PAD_GPIO_8__CCM_PLL3_BYP                           1147
-MX53_PAD_GPIO_16__ESAI1_TX3_RX2                         1148
-MX53_PAD_GPIO_16__GPIO7_11                              1149
-MX53_PAD_GPIO_16__TZIC_PWRFAIL_INT                      1150
-MX53_PAD_GPIO_16__RTC_CE_RTC_EXT_TRIG1                  1151
-MX53_PAD_GPIO_16__SPDIF_IN1                             1152
-MX53_PAD_GPIO_16__I2C3_SDA                              1153
-MX53_PAD_GPIO_16__SJC_DE_B                              1154
-MX53_PAD_GPIO_17__ESAI1_TX0                             1155
-MX53_PAD_GPIO_17__GPIO7_12                              1156
-MX53_PAD_GPIO_17__SDMA_EXT_EVENT_0                      1157
-MX53_PAD_GPIO_17__GPC_PMIC_RDY                          1158
-MX53_PAD_GPIO_17__RTC_CE_RTC_FSV_TRIG                   1159
-MX53_PAD_GPIO_17__SPDIF_OUT1                            1160
-MX53_PAD_GPIO_17__IPU_SNOOP2                            1161
-MX53_PAD_GPIO_17__SJC_JTAG_ACT                          1162
-MX53_PAD_GPIO_18__ESAI1_TX1                             1163
-MX53_PAD_GPIO_18__GPIO7_13                              1164
-MX53_PAD_GPIO_18__SDMA_EXT_EVENT_1                      1165
-MX53_PAD_GPIO_18__OWIRE_LINE                            1166
-MX53_PAD_GPIO_18__RTC_CE_RTC_ALARM2_TRIG                1167
-MX53_PAD_GPIO_18__CCM_ASRC_EXT_CLK                      1168
-MX53_PAD_GPIO_18__ESDHC1_LCTL                           1169
-MX53_PAD_GPIO_18__SRC_SYSTEM_RST                        1170
+Refer to imx53-pinfunc.h in device tree source folder for all available
+imx53 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
new file mode 100644
index 000000000000..0ac5bee87505
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
@@ -0,0 +1,38 @@
+* Freescale IMX6 DualLite/Solo IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx6dl-iomuxc"
+- fsl,pins: two integers array, represents a group of pins mux and config
+  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
+  pin working on a specific function, CONFIG is the pad setting value like
+  pull-up for this pin. Please refer to imx6dl datasheet for the valid pad
+  config settings.
+
+CONFIG bits definition:
+PAD_CTL_HYS                     (1 << 16)
+PAD_CTL_PUS_100K_DOWN           (0 << 14)
+PAD_CTL_PUS_47K_UP              (1 << 14)
+PAD_CTL_PUS_100K_UP             (2 << 14)
+PAD_CTL_PUS_22K_UP              (3 << 14)
+PAD_CTL_PUE                     (1 << 13)
+PAD_CTL_PKE                     (1 << 12)
+PAD_CTL_ODE                     (1 << 11)
+PAD_CTL_SPEED_LOW               (1 << 6)
+PAD_CTL_SPEED_MED               (2 << 6)
+PAD_CTL_SPEED_HIGH              (3 << 6)
+PAD_CTL_DSE_DISABLE             (0 << 3)
+PAD_CTL_DSE_240ohm              (1 << 3)
+PAD_CTL_DSE_120ohm              (2 << 3)
+PAD_CTL_DSE_80ohm               (3 << 3)
+PAD_CTL_DSE_60ohm               (4 << 3)
+PAD_CTL_DSE_48ohm               (5 << 3)
+PAD_CTL_DSE_40ohm               (6 << 3)
+PAD_CTL_DSE_34ohm               (7 << 3)
+PAD_CTL_SRE_FAST                (1 << 0)
+PAD_CTL_SRE_SLOW                (0 << 0)
+
+Refer to imx6dl-pinfunc.h in device tree source folder for all available
+imx6dl PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
index a4119f6422d9..546610cf2ae7 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
@@ -34,1597 +34,5 @@ PAD_CTL_DSE_34ohm               (7 << 3)
 PAD_CTL_SRE_FAST                (1 << 0)
 PAD_CTL_SRE_SLOW                (0 << 0)
 
-See below for available PIN_FUNC_ID for imx6q:
-MX6Q_PAD_SD2_DAT1__USDHC2_DAT1                  0
-MX6Q_PAD_SD2_DAT1__ECSPI5_SS0                   1
-MX6Q_PAD_SD2_DAT1__WEIM_WEIM_CS_2               2
-MX6Q_PAD_SD2_DAT1__AUDMUX_AUD4_TXFS             3
-MX6Q_PAD_SD2_DAT1__KPP_COL_7                    4
-MX6Q_PAD_SD2_DAT1__GPIO_1_14                    5
-MX6Q_PAD_SD2_DAT1__CCM_WAIT                     6
-MX6Q_PAD_SD2_DAT1__ANATOP_TESTO_0               7
-MX6Q_PAD_SD2_DAT2__USDHC2_DAT2                  8
-MX6Q_PAD_SD2_DAT2__ECSPI5_SS1                   9
-MX6Q_PAD_SD2_DAT2__WEIM_WEIM_CS_3               10
-MX6Q_PAD_SD2_DAT2__AUDMUX_AUD4_TXD              11
-MX6Q_PAD_SD2_DAT2__KPP_ROW_6                    12
-MX6Q_PAD_SD2_DAT2__GPIO_1_13                    13
-MX6Q_PAD_SD2_DAT2__CCM_STOP                     14
-MX6Q_PAD_SD2_DAT2__ANATOP_TESTO_1               15
-MX6Q_PAD_SD2_DAT0__USDHC2_DAT0                  16
-MX6Q_PAD_SD2_DAT0__ECSPI5_MISO                  17
-MX6Q_PAD_SD2_DAT0__AUDMUX_AUD4_RXD              18
-MX6Q_PAD_SD2_DAT0__KPP_ROW_7                    19
-MX6Q_PAD_SD2_DAT0__GPIO_1_15                    20
-MX6Q_PAD_SD2_DAT0__DCIC2_DCIC_OUT               21
-MX6Q_PAD_SD2_DAT0__TESTO_2                      22
-MX6Q_PAD_RGMII_TXC__USBOH3_H2_DATA              23
-MX6Q_PAD_RGMII_TXC__ENET_RGMII_TXC              24
-MX6Q_PAD_RGMII_TXC__SPDIF_SPDIF_EXTCLK          25
-MX6Q_PAD_RGMII_TXC__GPIO_6_19                   26
-MX6Q_PAD_RGMII_TXC__MIPI_CORE_DPHY_IN_0         27
-MX6Q_PAD_RGMII_TXC__ANATOP_24M_OUT              28
-MX6Q_PAD_RGMII_TD0__MIPI_HSI_CRL_TX_RDY         29
-MX6Q_PAD_RGMII_TD0__ENET_RGMII_TD0              30
-MX6Q_PAD_RGMII_TD0__GPIO_6_20                   31
-MX6Q_PAD_RGMII_TD0__MIPI_CORE_DPHY_IN_1         32
-MX6Q_PAD_RGMII_TD1__MIPI_HSI_CRL_RX_FLG         33
-MX6Q_PAD_RGMII_TD1__ENET_RGMII_TD1              34
-MX6Q_PAD_RGMII_TD1__GPIO_6_21                   35
-MX6Q_PAD_RGMII_TD1__MIPI_CORE_DPHY_IN_2         36
-MX6Q_PAD_RGMII_TD1__CCM_PLL3_BYP                37
-MX6Q_PAD_RGMII_TD2__MIPI_HSI_CRL_RX_DTA         38
-MX6Q_PAD_RGMII_TD2__ENET_RGMII_TD2              39
-MX6Q_PAD_RGMII_TD2__GPIO_6_22                   40
-MX6Q_PAD_RGMII_TD2__MIPI_CORE_DPHY_IN_3         41
-MX6Q_PAD_RGMII_TD2__CCM_PLL2_BYP                42
-MX6Q_PAD_RGMII_TD3__MIPI_HSI_CRL_RX_WAK         43
-MX6Q_PAD_RGMII_TD3__ENET_RGMII_TD3              44
-MX6Q_PAD_RGMII_TD3__GPIO_6_23                   45
-MX6Q_PAD_RGMII_TD3__MIPI_CORE_DPHY_IN_4         46
-MX6Q_PAD_RGMII_RX_CTL__USBOH3_H3_DATA           47
-MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL             48
-MX6Q_PAD_RGMII_RX_CTL__GPIO_6_24                49
-MX6Q_PAD_RGMII_RX_CTL__MIPI_DPHY_IN_5           50
-MX6Q_PAD_RGMII_RD0__MIPI_HSI_CRL_RX_RDY         51
-MX6Q_PAD_RGMII_RD0__ENET_RGMII_RD0              52
-MX6Q_PAD_RGMII_RD0__GPIO_6_25                   53
-MX6Q_PAD_RGMII_RD0__MIPI_CORE_DPHY_IN_6         54
-MX6Q_PAD_RGMII_TX_CTL__USBOH3_H2_STROBE         55
-MX6Q_PAD_RGMII_TX_CTL__RGMII_TX_CTL             56
-MX6Q_PAD_RGMII_TX_CTL__GPIO_6_26                57
-MX6Q_PAD_RGMII_TX_CTL__CORE_DPHY_IN_7           58
-MX6Q_PAD_RGMII_TX_CTL__ANATOP_REF_OUT           59
-MX6Q_PAD_RGMII_RD1__MIPI_HSI_CTRL_TX_FL         60
-MX6Q_PAD_RGMII_RD1__ENET_RGMII_RD1              61
-MX6Q_PAD_RGMII_RD1__GPIO_6_27                   62
-MX6Q_PAD_RGMII_RD1__CORE_DPHY_TEST_IN_8         63
-MX6Q_PAD_RGMII_RD1__SJC_FAIL                    64
-MX6Q_PAD_RGMII_RD2__MIPI_HSI_CRL_TX_DTA         65
-MX6Q_PAD_RGMII_RD2__ENET_RGMII_RD2              66
-MX6Q_PAD_RGMII_RD2__GPIO_6_28                   67
-MX6Q_PAD_RGMII_RD2__MIPI_CORE_DPHY_IN_9         68
-MX6Q_PAD_RGMII_RD3__MIPI_HSI_CRL_TX_WAK         69
-MX6Q_PAD_RGMII_RD3__ENET_RGMII_RD3              70
-MX6Q_PAD_RGMII_RD3__GPIO_6_29                   71
-MX6Q_PAD_RGMII_RD3__MIPI_CORE_DPHY_IN10         72
-MX6Q_PAD_RGMII_RXC__USBOH3_H3_STROBE            73
-MX6Q_PAD_RGMII_RXC__ENET_RGMII_RXC              74
-MX6Q_PAD_RGMII_RXC__GPIO_6_30                   75
-MX6Q_PAD_RGMII_RXC__MIPI_CORE_DPHY_IN11         76
-MX6Q_PAD_EIM_A25__WEIM_WEIM_A_25                77
-MX6Q_PAD_EIM_A25__ECSPI4_SS1                    78
-MX6Q_PAD_EIM_A25__ECSPI2_RDY                    79
-MX6Q_PAD_EIM_A25__IPU1_DI1_PIN12                80
-MX6Q_PAD_EIM_A25__IPU1_DI0_D1_CS                81
-MX6Q_PAD_EIM_A25__GPIO_5_2                      82
-MX6Q_PAD_EIM_A25__HDMI_TX_CEC_LINE              83
-MX6Q_PAD_EIM_A25__PL301_PER1_HBURST_0           84
-MX6Q_PAD_EIM_EB2__WEIM_WEIM_EB_2                85
-MX6Q_PAD_EIM_EB2__ECSPI1_SS0                    86
-MX6Q_PAD_EIM_EB2__CCM_DI1_EXT_CLK               87
-MX6Q_PAD_EIM_EB2__IPU2_CSI1_D_19                88
-MX6Q_PAD_EIM_EB2__HDMI_TX_DDC_SCL               89
-MX6Q_PAD_EIM_EB2__GPIO_2_30                     90
-MX6Q_PAD_EIM_EB2__I2C2_SCL                      91
-MX6Q_PAD_EIM_EB2__SRC_BT_CFG_30                 92
-MX6Q_PAD_EIM_D16__WEIM_WEIM_D_16                93
-MX6Q_PAD_EIM_D16__ECSPI1_SCLK                   94
-MX6Q_PAD_EIM_D16__IPU1_DI0_PIN5                 95
-MX6Q_PAD_EIM_D16__IPU2_CSI1_D_18                96
-MX6Q_PAD_EIM_D16__HDMI_TX_DDC_SDA               97
-MX6Q_PAD_EIM_D16__GPIO_3_16                     98
-MX6Q_PAD_EIM_D16__I2C2_SDA                      99
-MX6Q_PAD_EIM_D17__WEIM_WEIM_D_17                100
-MX6Q_PAD_EIM_D17__ECSPI1_MISO                   101
-MX6Q_PAD_EIM_D17__IPU1_DI0_PIN6                 102
-MX6Q_PAD_EIM_D17__IPU2_CSI1_PIXCLK              103
-MX6Q_PAD_EIM_D17__DCIC1_DCIC_OUT                104
-MX6Q_PAD_EIM_D17__GPIO_3_17                     105
-MX6Q_PAD_EIM_D17__I2C3_SCL                      106
-MX6Q_PAD_EIM_D17__PL301_PER1_HBURST_1           107
-MX6Q_PAD_EIM_D18__WEIM_WEIM_D_18                108
-MX6Q_PAD_EIM_D18__ECSPI1_MOSI                   109
-MX6Q_PAD_EIM_D18__IPU1_DI0_PIN7                 110
-MX6Q_PAD_EIM_D18__IPU2_CSI1_D_17                111
-MX6Q_PAD_EIM_D18__IPU1_DI1_D0_CS                112
-MX6Q_PAD_EIM_D18__GPIO_3_18                     113
-MX6Q_PAD_EIM_D18__I2C3_SDA                      114
-MX6Q_PAD_EIM_D18__PL301_PER1_HBURST_2           115
-MX6Q_PAD_EIM_D19__WEIM_WEIM_D_19                116
-MX6Q_PAD_EIM_D19__ECSPI1_SS1                    117
-MX6Q_PAD_EIM_D19__IPU1_DI0_PIN8                 118
-MX6Q_PAD_EIM_D19__IPU2_CSI1_D_16                119
-MX6Q_PAD_EIM_D19__UART1_CTS                     120
-MX6Q_PAD_EIM_D19__GPIO_3_19                     121
-MX6Q_PAD_EIM_D19__EPIT1_EPITO                   122
-MX6Q_PAD_EIM_D19__PL301_PER1_HRESP              123
-MX6Q_PAD_EIM_D20__WEIM_WEIM_D_20                124
-MX6Q_PAD_EIM_D20__ECSPI4_SS0                    125
-MX6Q_PAD_EIM_D20__IPU1_DI0_PIN16                126
-MX6Q_PAD_EIM_D20__IPU2_CSI1_D_15                127
-MX6Q_PAD_EIM_D20__UART1_RTS                     128
-MX6Q_PAD_EIM_D20__GPIO_3_20                     129
-MX6Q_PAD_EIM_D20__EPIT2_EPITO                   130
-MX6Q_PAD_EIM_D21__WEIM_WEIM_D_21                131
-MX6Q_PAD_EIM_D21__ECSPI4_SCLK                   132
-MX6Q_PAD_EIM_D21__IPU1_DI0_PIN17                133
-MX6Q_PAD_EIM_D21__IPU2_CSI1_D_11                134
-MX6Q_PAD_EIM_D21__USBOH3_USBOTG_OC              135
-MX6Q_PAD_EIM_D21__GPIO_3_21                     136
-MX6Q_PAD_EIM_D21__I2C1_SCL                      137
-MX6Q_PAD_EIM_D21__SPDIF_IN1                     138
-MX6Q_PAD_EIM_D22__WEIM_WEIM_D_22                139
-MX6Q_PAD_EIM_D22__ECSPI4_MISO                   140
-MX6Q_PAD_EIM_D22__IPU1_DI0_PIN1                 141
-MX6Q_PAD_EIM_D22__IPU2_CSI1_D_10                142
-MX6Q_PAD_EIM_D22__USBOH3_USBOTG_PWR             143
-MX6Q_PAD_EIM_D22__GPIO_3_22                     144
-MX6Q_PAD_EIM_D22__SPDIF_OUT1                    145
-MX6Q_PAD_EIM_D22__PL301_PER1_HWRITE             146
-MX6Q_PAD_EIM_D23__WEIM_WEIM_D_23                147
-MX6Q_PAD_EIM_D23__IPU1_DI0_D0_CS                148
-MX6Q_PAD_EIM_D23__UART3_CTS                     149
-MX6Q_PAD_EIM_D23__UART1_DCD                     150
-MX6Q_PAD_EIM_D23__IPU2_CSI1_DATA_EN             151
-MX6Q_PAD_EIM_D23__GPIO_3_23                     152
-MX6Q_PAD_EIM_D23__IPU1_DI1_PIN2                 153
-MX6Q_PAD_EIM_D23__IPU1_DI1_PIN14                154
-MX6Q_PAD_EIM_EB3__WEIM_WEIM_EB_3                155
-MX6Q_PAD_EIM_EB3__ECSPI4_RDY                    156
-MX6Q_PAD_EIM_EB3__UART3_RTS                     157
-MX6Q_PAD_EIM_EB3__UART1_RI                      158
-MX6Q_PAD_EIM_EB3__IPU2_CSI1_HSYNC               159
-MX6Q_PAD_EIM_EB3__GPIO_2_31                     160
-MX6Q_PAD_EIM_EB3__IPU1_DI1_PIN3                 161
-MX6Q_PAD_EIM_EB3__SRC_BT_CFG_31                 162
-MX6Q_PAD_EIM_D24__WEIM_WEIM_D_24                163
-MX6Q_PAD_EIM_D24__ECSPI4_SS2                    164
-MX6Q_PAD_EIM_D24__UART3_TXD                     165
-MX6Q_PAD_EIM_D24__ECSPI1_SS2                    166
-MX6Q_PAD_EIM_D24__ECSPI2_SS2                    167
-MX6Q_PAD_EIM_D24__GPIO_3_24                     168
-MX6Q_PAD_EIM_D24__AUDMUX_AUD5_RXFS              169
-MX6Q_PAD_EIM_D24__UART1_DTR                     170
-MX6Q_PAD_EIM_D25__WEIM_WEIM_D_25                171
-MX6Q_PAD_EIM_D25__ECSPI4_SS3                    172
-MX6Q_PAD_EIM_D25__UART3_RXD                     173
-MX6Q_PAD_EIM_D25__ECSPI1_SS3                    174
-MX6Q_PAD_EIM_D25__ECSPI2_SS3                    175
-MX6Q_PAD_EIM_D25__GPIO_3_25                     176
-MX6Q_PAD_EIM_D25__AUDMUX_AUD5_RXC               177
-MX6Q_PAD_EIM_D25__UART1_DSR                     178
-MX6Q_PAD_EIM_D26__WEIM_WEIM_D_26                179
-MX6Q_PAD_EIM_D26__IPU1_DI1_PIN11                180
-MX6Q_PAD_EIM_D26__IPU1_CSI0_D_1                 181
-MX6Q_PAD_EIM_D26__IPU2_CSI1_D_14                182
-MX6Q_PAD_EIM_D26__UART2_TXD                     183
-MX6Q_PAD_EIM_D26__GPIO_3_26                     184
-MX6Q_PAD_EIM_D26__IPU1_SISG_2                   185
-MX6Q_PAD_EIM_D26__IPU1_DISP1_DAT_22             186
-MX6Q_PAD_EIM_D27__WEIM_WEIM_D_27                187
-MX6Q_PAD_EIM_D27__IPU1_DI1_PIN13                188
-MX6Q_PAD_EIM_D27__IPU1_CSI0_D_0                 189
-MX6Q_PAD_EIM_D27__IPU2_CSI1_D_13                190
-MX6Q_PAD_EIM_D27__UART2_RXD                     191
-MX6Q_PAD_EIM_D27__GPIO_3_27                     192
-MX6Q_PAD_EIM_D27__IPU1_SISG_3                   193
-MX6Q_PAD_EIM_D27__IPU1_DISP1_DAT_23             194
-MX6Q_PAD_EIM_D28__WEIM_WEIM_D_28                195
-MX6Q_PAD_EIM_D28__I2C1_SDA                      196
-MX6Q_PAD_EIM_D28__ECSPI4_MOSI                   197
-MX6Q_PAD_EIM_D28__IPU2_CSI1_D_12                198
-MX6Q_PAD_EIM_D28__UART2_CTS                     199
-MX6Q_PAD_EIM_D28__GPIO_3_28                     200
-MX6Q_PAD_EIM_D28__IPU1_EXT_TRIG                 201
-MX6Q_PAD_EIM_D28__IPU1_DI0_PIN13                202
-MX6Q_PAD_EIM_D29__WEIM_WEIM_D_29                203
-MX6Q_PAD_EIM_D29__IPU1_DI1_PIN15                204
-MX6Q_PAD_EIM_D29__ECSPI4_SS0                    205
-MX6Q_PAD_EIM_D29__UART2_RTS                     206
-MX6Q_PAD_EIM_D29__GPIO_3_29                     207
-MX6Q_PAD_EIM_D29__IPU2_CSI1_VSYNC               208
-MX6Q_PAD_EIM_D29__IPU1_DI0_PIN14                209
-MX6Q_PAD_EIM_D30__WEIM_WEIM_D_30                210
-MX6Q_PAD_EIM_D30__IPU1_DISP1_DAT_21             211
-MX6Q_PAD_EIM_D30__IPU1_DI0_PIN11                212
-MX6Q_PAD_EIM_D30__IPU1_CSI0_D_3                 213
-MX6Q_PAD_EIM_D30__UART3_CTS                     214
-MX6Q_PAD_EIM_D30__GPIO_3_30                     215
-MX6Q_PAD_EIM_D30__USBOH3_USBH1_OC               216
-MX6Q_PAD_EIM_D30__PL301_PER1_HPROT_0            217
-MX6Q_PAD_EIM_D31__WEIM_WEIM_D_31                218
-MX6Q_PAD_EIM_D31__IPU1_DISP1_DAT_20             219
-MX6Q_PAD_EIM_D31__IPU1_DI0_PIN12                220
-MX6Q_PAD_EIM_D31__IPU1_CSI0_D_2                 221
-MX6Q_PAD_EIM_D31__UART3_RTS                     222
-MX6Q_PAD_EIM_D31__GPIO_3_31                     223
-MX6Q_PAD_EIM_D31__USBOH3_USBH1_PWR              224
-MX6Q_PAD_EIM_D31__PL301_PER1_HPROT_1            225
-MX6Q_PAD_EIM_A24__WEIM_WEIM_A_24                226
-MX6Q_PAD_EIM_A24__IPU1_DISP1_DAT_19             227
-MX6Q_PAD_EIM_A24__IPU2_CSI1_D_19                228
-MX6Q_PAD_EIM_A24__IPU2_SISG_2                   229
-MX6Q_PAD_EIM_A24__IPU1_SISG_2                   230
-MX6Q_PAD_EIM_A24__GPIO_5_4                      231
-MX6Q_PAD_EIM_A24__PL301_PER1_HPROT_2            232
-MX6Q_PAD_EIM_A24__SRC_BT_CFG_24                 233
-MX6Q_PAD_EIM_A23__WEIM_WEIM_A_23                234
-MX6Q_PAD_EIM_A23__IPU1_DISP1_DAT_18             235
-MX6Q_PAD_EIM_A23__IPU2_CSI1_D_18                236
-MX6Q_PAD_EIM_A23__IPU2_SISG_3                   237
-MX6Q_PAD_EIM_A23__IPU1_SISG_3                   238
-MX6Q_PAD_EIM_A23__GPIO_6_6                      239
-MX6Q_PAD_EIM_A23__PL301_PER1_HPROT_3            240
-MX6Q_PAD_EIM_A23__SRC_BT_CFG_23                 241
-MX6Q_PAD_EIM_A22__WEIM_WEIM_A_22                242
-MX6Q_PAD_EIM_A22__IPU1_DISP1_DAT_17             243
-MX6Q_PAD_EIM_A22__IPU2_CSI1_D_17                244
-MX6Q_PAD_EIM_A22__GPIO_2_16                     245
-MX6Q_PAD_EIM_A22__TPSMP_HDATA_0                 246
-MX6Q_PAD_EIM_A22__SRC_BT_CFG_22                 247
-MX6Q_PAD_EIM_A21__WEIM_WEIM_A_21                248
-MX6Q_PAD_EIM_A21__IPU1_DISP1_DAT_16             249
-MX6Q_PAD_EIM_A21__IPU2_CSI1_D_16                250
-MX6Q_PAD_EIM_A21__RESERVED_RESERVED             251
-MX6Q_PAD_EIM_A21__MIPI_CORE_DPHY_OUT_18         252
-MX6Q_PAD_EIM_A21__GPIO_2_17                     253
-MX6Q_PAD_EIM_A21__TPSMP_HDATA_1                 254
-MX6Q_PAD_EIM_A21__SRC_BT_CFG_21                 255
-MX6Q_PAD_EIM_A20__WEIM_WEIM_A_20                256
-MX6Q_PAD_EIM_A20__IPU1_DISP1_DAT_15             257
-MX6Q_PAD_EIM_A20__IPU2_CSI1_D_15                258
-MX6Q_PAD_EIM_A20__RESERVED_RESERVED             259
-MX6Q_PAD_EIM_A20__MIPI_CORE_DPHY_OUT_19         260
-MX6Q_PAD_EIM_A20__GPIO_2_18                     261
-MX6Q_PAD_EIM_A20__TPSMP_HDATA_2                 262
-MX6Q_PAD_EIM_A20__SRC_BT_CFG_20                 263
-MX6Q_PAD_EIM_A19__WEIM_WEIM_A_19                264
-MX6Q_PAD_EIM_A19__IPU1_DISP1_DAT_14             265
-MX6Q_PAD_EIM_A19__IPU2_CSI1_D_14                266
-MX6Q_PAD_EIM_A19__RESERVED_RESERVED             267
-MX6Q_PAD_EIM_A19__MIPI_CORE_DPHY_OUT_20         268
-MX6Q_PAD_EIM_A19__GPIO_2_19                     269
-MX6Q_PAD_EIM_A19__TPSMP_HDATA_3                 270
-MX6Q_PAD_EIM_A19__SRC_BT_CFG_19                 271
-MX6Q_PAD_EIM_A18__WEIM_WEIM_A_18                272
-MX6Q_PAD_EIM_A18__IPU1_DISP1_DAT_13             273
-MX6Q_PAD_EIM_A18__IPU2_CSI1_D_13                274
-MX6Q_PAD_EIM_A18__RESERVED_RESERVED             275
-MX6Q_PAD_EIM_A18__MIPI_CORE_DPHY_OUT_21         276
-MX6Q_PAD_EIM_A18__GPIO_2_20                     277
-MX6Q_PAD_EIM_A18__TPSMP_HDATA_4                 278
-MX6Q_PAD_EIM_A18__SRC_BT_CFG_18                 279
-MX6Q_PAD_EIM_A17__WEIM_WEIM_A_17                280
-MX6Q_PAD_EIM_A17__IPU1_DISP1_DAT_12             281
-MX6Q_PAD_EIM_A17__IPU2_CSI1_D_12                282
-MX6Q_PAD_EIM_A17__RESERVED_RESERVED             283
-MX6Q_PAD_EIM_A17__MIPI_CORE_DPHY_OUT_22         284
-MX6Q_PAD_EIM_A17__GPIO_2_21                     285
-MX6Q_PAD_EIM_A17__TPSMP_HDATA_5                 286
-MX6Q_PAD_EIM_A17__SRC_BT_CFG_17                 287
-MX6Q_PAD_EIM_A16__WEIM_WEIM_A_16                288
-MX6Q_PAD_EIM_A16__IPU1_DI1_DISP_CLK             289
-MX6Q_PAD_EIM_A16__IPU2_CSI1_PIXCLK              290
-MX6Q_PAD_EIM_A16__MIPI_CORE_DPHY_OUT_23         291
-MX6Q_PAD_EIM_A16__GPIO_2_22                     292
-MX6Q_PAD_EIM_A16__TPSMP_HDATA_6                 293
-MX6Q_PAD_EIM_A16__SRC_BT_CFG_16                 294
-MX6Q_PAD_EIM_CS0__WEIM_WEIM_CS_0                295
-MX6Q_PAD_EIM_CS0__IPU1_DI1_PIN5                 296
-MX6Q_PAD_EIM_CS0__ECSPI2_SCLK                   297
-MX6Q_PAD_EIM_CS0__MIPI_CORE_DPHY_OUT_24         298
-MX6Q_PAD_EIM_CS0__GPIO_2_23                     299
-MX6Q_PAD_EIM_CS0__TPSMP_HDATA_7                 300
-MX6Q_PAD_EIM_CS1__WEIM_WEIM_CS_1                301
-MX6Q_PAD_EIM_CS1__IPU1_DI1_PIN6                 302
-MX6Q_PAD_EIM_CS1__ECSPI2_MOSI                   303
-MX6Q_PAD_EIM_CS1__MIPI_CORE_DPHY_OUT_25         304
-MX6Q_PAD_EIM_CS1__GPIO_2_24                     305
-MX6Q_PAD_EIM_CS1__TPSMP_HDATA_8                 306
-MX6Q_PAD_EIM_OE__WEIM_WEIM_OE                   307
-MX6Q_PAD_EIM_OE__IPU1_DI1_PIN7                  308
-MX6Q_PAD_EIM_OE__ECSPI2_MISO                    309
-MX6Q_PAD_EIM_OE__MIPI_CORE_DPHY_OUT_26          310
-MX6Q_PAD_EIM_OE__GPIO_2_25                      311
-MX6Q_PAD_EIM_OE__TPSMP_HDATA_9                  312
-MX6Q_PAD_EIM_RW__WEIM_WEIM_RW                   313
-MX6Q_PAD_EIM_RW__IPU1_DI1_PIN8                  314
-MX6Q_PAD_EIM_RW__ECSPI2_SS0                     315
-MX6Q_PAD_EIM_RW__MIPI_CORE_DPHY_OUT_27          316
-MX6Q_PAD_EIM_RW__GPIO_2_26                      317
-MX6Q_PAD_EIM_RW__TPSMP_HDATA_10                 318
-MX6Q_PAD_EIM_RW__SRC_BT_CFG_29                  319
-MX6Q_PAD_EIM_LBA__WEIM_WEIM_LBA                 320
-MX6Q_PAD_EIM_LBA__IPU1_DI1_PIN17                321
-MX6Q_PAD_EIM_LBA__ECSPI2_SS1                    322
-MX6Q_PAD_EIM_LBA__GPIO_2_27                     323
-MX6Q_PAD_EIM_LBA__TPSMP_HDATA_11                324
-MX6Q_PAD_EIM_LBA__SRC_BT_CFG_26                 325
-MX6Q_PAD_EIM_EB0__WEIM_WEIM_EB_0                326
-MX6Q_PAD_EIM_EB0__IPU1_DISP1_DAT_11             327
-MX6Q_PAD_EIM_EB0__IPU2_CSI1_D_11                328
-MX6Q_PAD_EIM_EB0__MIPI_CORE_DPHY_OUT_0          329
-MX6Q_PAD_EIM_EB0__CCM_PMIC_RDY                  330
-MX6Q_PAD_EIM_EB0__GPIO_2_28                     331
-MX6Q_PAD_EIM_EB0__TPSMP_HDATA_12                332
-MX6Q_PAD_EIM_EB0__SRC_BT_CFG_27                 333
-MX6Q_PAD_EIM_EB1__WEIM_WEIM_EB_1                334
-MX6Q_PAD_EIM_EB1__IPU1_DISP1_DAT_10             335
-MX6Q_PAD_EIM_EB1__IPU2_CSI1_D_10                336
-MX6Q_PAD_EIM_EB1__MIPI_CORE_DPHY__OUT_1         337
-MX6Q_PAD_EIM_EB1__GPIO_2_29                     338
-MX6Q_PAD_EIM_EB1__TPSMP_HDATA_13                339
-MX6Q_PAD_EIM_EB1__SRC_BT_CFG_28                 340
-MX6Q_PAD_EIM_DA0__WEIM_WEIM_DA_A_0              341
-MX6Q_PAD_EIM_DA0__IPU1_DISP1_DAT_9              342
-MX6Q_PAD_EIM_DA0__IPU2_CSI1_D_9                 343
-MX6Q_PAD_EIM_DA0__MIPI_CORE_DPHY__OUT_2         344
-MX6Q_PAD_EIM_DA0__GPIO_3_0                      345
-MX6Q_PAD_EIM_DA0__TPSMP_HDATA_14                346
-MX6Q_PAD_EIM_DA0__SRC_BT_CFG_0                  347
-MX6Q_PAD_EIM_DA1__WEIM_WEIM_DA_A_1              348
-MX6Q_PAD_EIM_DA1__IPU1_DISP1_DAT_8              349
-MX6Q_PAD_EIM_DA1__IPU2_CSI1_D_8                 350
-MX6Q_PAD_EIM_DA1__MIPI_CORE_DPHY_OUT_3          351
-MX6Q_PAD_EIM_DA1__USBPHY1_TX_LS_MODE            352
-MX6Q_PAD_EIM_DA1__GPIO_3_1                      353
-MX6Q_PAD_EIM_DA1__TPSMP_HDATA_15                354
-MX6Q_PAD_EIM_DA1__SRC_BT_CFG_1                  355
-MX6Q_PAD_EIM_DA2__WEIM_WEIM_DA_A_2              356
-MX6Q_PAD_EIM_DA2__IPU1_DISP1_DAT_7              357
-MX6Q_PAD_EIM_DA2__IPU2_CSI1_D_7                 358
-MX6Q_PAD_EIM_DA2__MIPI_CORE_DPHY_OUT_4          359
-MX6Q_PAD_EIM_DA2__USBPHY1_TX_HS_MODE            360
-MX6Q_PAD_EIM_DA2__GPIO_3_2                      361
-MX6Q_PAD_EIM_DA2__TPSMP_HDATA_16                362
-MX6Q_PAD_EIM_DA2__SRC_BT_CFG_2                  363
-MX6Q_PAD_EIM_DA3__WEIM_WEIM_DA_A_3              364
-MX6Q_PAD_EIM_DA3__IPU1_DISP1_DAT_6              365
-MX6Q_PAD_EIM_DA3__IPU2_CSI1_D_6                 366
-MX6Q_PAD_EIM_DA3__MIPI_CORE_DPHY_OUT_5          367
-MX6Q_PAD_EIM_DA3__USBPHY1_TX_HIZ                368
-MX6Q_PAD_EIM_DA3__GPIO_3_3                      369
-MX6Q_PAD_EIM_DA3__TPSMP_HDATA_17                370
-MX6Q_PAD_EIM_DA3__SRC_BT_CFG_3                  371
-MX6Q_PAD_EIM_DA4__WEIM_WEIM_DA_A_4              372
-MX6Q_PAD_EIM_DA4__IPU1_DISP1_DAT_5              373
-MX6Q_PAD_EIM_DA4__IPU2_CSI1_D_5                 374
-MX6Q_PAD_EIM_DA4__MIPI_CORE_DPHY_OUT_6          375
-MX6Q_PAD_EIM_DA4__ANATOP_USBPHY1_TX_EN          376
-MX6Q_PAD_EIM_DA4__GPIO_3_4                      377
-MX6Q_PAD_EIM_DA4__TPSMP_HDATA_18                378
-MX6Q_PAD_EIM_DA4__SRC_BT_CFG_4                  379
-MX6Q_PAD_EIM_DA5__WEIM_WEIM_DA_A_5              380
-MX6Q_PAD_EIM_DA5__IPU1_DISP1_DAT_4              381
-MX6Q_PAD_EIM_DA5__IPU2_CSI1_D_4                 382
-MX6Q_PAD_EIM_DA5__MIPI_CORE_DPHY_OUT_7          383
-MX6Q_PAD_EIM_DA5__ANATOP_USBPHY1_TX_DP          384
-MX6Q_PAD_EIM_DA5__GPIO_3_5                      385
-MX6Q_PAD_EIM_DA5__TPSMP_HDATA_19                386
-MX6Q_PAD_EIM_DA5__SRC_BT_CFG_5                  387
-MX6Q_PAD_EIM_DA6__WEIM_WEIM_DA_A_6              388
-MX6Q_PAD_EIM_DA6__IPU1_DISP1_DAT_3              389
-MX6Q_PAD_EIM_DA6__IPU2_CSI1_D_3                 390
-MX6Q_PAD_EIM_DA6__MIPI_CORE_DPHY_OUT_8          391
-MX6Q_PAD_EIM_DA6__ANATOP_USBPHY1_TX_DN          392
-MX6Q_PAD_EIM_DA6__GPIO_3_6                      393
-MX6Q_PAD_EIM_DA6__TPSMP_HDATA_20                394
-MX6Q_PAD_EIM_DA6__SRC_BT_CFG_6                  395
-MX6Q_PAD_EIM_DA7__WEIM_WEIM_DA_A_7              396
-MX6Q_PAD_EIM_DA7__IPU1_DISP1_DAT_2              397
-MX6Q_PAD_EIM_DA7__IPU2_CSI1_D_2                 398
-MX6Q_PAD_EIM_DA7__MIPI_CORE_DPHY_OUT_9          399
-MX6Q_PAD_EIM_DA7__GPIO_3_7                      400
-MX6Q_PAD_EIM_DA7__TPSMP_HDATA_21                401
-MX6Q_PAD_EIM_DA7__SRC_BT_CFG_7                  402
-MX6Q_PAD_EIM_DA8__WEIM_WEIM_DA_A_8              403
-MX6Q_PAD_EIM_DA8__IPU1_DISP1_DAT_1              404
-MX6Q_PAD_EIM_DA8__IPU2_CSI1_D_1                 405
-MX6Q_PAD_EIM_DA8__MIPI_CORE_DPHY_OUT_10         406
-MX6Q_PAD_EIM_DA8__GPIO_3_8                      407
-MX6Q_PAD_EIM_DA8__TPSMP_HDATA_22                408
-MX6Q_PAD_EIM_DA8__SRC_BT_CFG_8                  409
-MX6Q_PAD_EIM_DA9__WEIM_WEIM_DA_A_9              410
-MX6Q_PAD_EIM_DA9__IPU1_DISP1_DAT_0              411
-MX6Q_PAD_EIM_DA9__IPU2_CSI1_D_0                 412
-MX6Q_PAD_EIM_DA9__MIPI_CORE_DPHY_OUT_11         413
-MX6Q_PAD_EIM_DA9__GPIO_3_9                      414
-MX6Q_PAD_EIM_DA9__TPSMP_HDATA_23                415
-MX6Q_PAD_EIM_DA9__SRC_BT_CFG_9                  416
-MX6Q_PAD_EIM_DA10__WEIM_WEIM_DA_A_10            417
-MX6Q_PAD_EIM_DA10__IPU1_DI1_PIN15               418
-MX6Q_PAD_EIM_DA10__IPU2_CSI1_DATA_EN            419
-MX6Q_PAD_EIM_DA10__MIPI_CORE_DPHY_OUT12         420
-MX6Q_PAD_EIM_DA10__GPIO_3_10                    421
-MX6Q_PAD_EIM_DA10__TPSMP_HDATA_24               422
-MX6Q_PAD_EIM_DA10__SRC_BT_CFG_10                423
-MX6Q_PAD_EIM_DA11__WEIM_WEIM_DA_A_11            424
-MX6Q_PAD_EIM_DA11__IPU1_DI1_PIN2                425
-MX6Q_PAD_EIM_DA11__IPU2_CSI1_HSYNC              426
-MX6Q_PAD_EIM_DA11__MIPI_CORE_DPHY_OUT13         427
-MX6Q_PAD_EIM_DA11__SDMA_DBG_EVT_CHN_6           428
-MX6Q_PAD_EIM_DA11__GPIO_3_11                    429
-MX6Q_PAD_EIM_DA11__TPSMP_HDATA_25               430
-MX6Q_PAD_EIM_DA11__SRC_BT_CFG_11                431
-MX6Q_PAD_EIM_DA12__WEIM_WEIM_DA_A_12            432
-MX6Q_PAD_EIM_DA12__IPU1_DI1_PIN3                433
-MX6Q_PAD_EIM_DA12__IPU2_CSI1_VSYNC              434
-MX6Q_PAD_EIM_DA12__MIPI_CORE_DPHY_OUT14         435
-MX6Q_PAD_EIM_DA12__SDMA_DEBUG_EVT_CHN_3         436
-MX6Q_PAD_EIM_DA12__GPIO_3_12                    437
-MX6Q_PAD_EIM_DA12__TPSMP_HDATA_26               438
-MX6Q_PAD_EIM_DA12__SRC_BT_CFG_12                439
-MX6Q_PAD_EIM_DA13__WEIM_WEIM_DA_A_13            440
-MX6Q_PAD_EIM_DA13__IPU1_DI1_D0_CS               441
-MX6Q_PAD_EIM_DA13__CCM_DI1_EXT_CLK              442
-MX6Q_PAD_EIM_DA13__MIPI_CORE_DPHY_OUT15         443
-MX6Q_PAD_EIM_DA13__SDMA_DEBUG_EVT_CHN_4         444
-MX6Q_PAD_EIM_DA13__GPIO_3_13                    445
-MX6Q_PAD_EIM_DA13__TPSMP_HDATA_27               446
-MX6Q_PAD_EIM_DA13__SRC_BT_CFG_13                447
-MX6Q_PAD_EIM_DA14__WEIM_WEIM_DA_A_14            448
-MX6Q_PAD_EIM_DA14__IPU1_DI1_D1_CS               449
-MX6Q_PAD_EIM_DA14__CCM_DI0_EXT_CLK              450
-MX6Q_PAD_EIM_DA14__MIPI_CORE_DPHY_OUT16         451
-MX6Q_PAD_EIM_DA14__SDMA_DEBUG_EVT_CHN_5         452
-MX6Q_PAD_EIM_DA14__GPIO_3_14                    453
-MX6Q_PAD_EIM_DA14__TPSMP_HDATA_28               454
-MX6Q_PAD_EIM_DA14__SRC_BT_CFG_14                455
-MX6Q_PAD_EIM_DA15__WEIM_WEIM_DA_A_15            456
-MX6Q_PAD_EIM_DA15__IPU1_DI1_PIN1                457
-MX6Q_PAD_EIM_DA15__IPU1_DI1_PIN4                458
-MX6Q_PAD_EIM_DA15__MIPI_CORE_DPHY_OUT17         459
-MX6Q_PAD_EIM_DA15__GPIO_3_15                    460
-MX6Q_PAD_EIM_DA15__TPSMP_HDATA_29               461
-MX6Q_PAD_EIM_DA15__SRC_BT_CFG_15                462
-MX6Q_PAD_EIM_WAIT__WEIM_WEIM_WAIT               463
-MX6Q_PAD_EIM_WAIT__WEIM_WEIM_DTACK_B            464
-MX6Q_PAD_EIM_WAIT__GPIO_5_0                     465
-MX6Q_PAD_EIM_WAIT__TPSMP_HDATA_30               466
-MX6Q_PAD_EIM_WAIT__SRC_BT_CFG_25                467
-MX6Q_PAD_EIM_BCLK__WEIM_WEIM_BCLK               468
-MX6Q_PAD_EIM_BCLK__IPU1_DI1_PIN16               469
-MX6Q_PAD_EIM_BCLK__GPIO_6_31                    470
-MX6Q_PAD_EIM_BCLK__TPSMP_HDATA_31               471
-MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DSP_CLK         472
-MX6Q_PAD_DI0_DISP_CLK__IPU2_DI0_DSP_CLK         473
-MX6Q_PAD_DI0_DISP_CLK__MIPI_CR_DPY_OT28         474
-MX6Q_PAD_DI0_DISP_CLK__SDMA_DBG_CR_STA0         475
-MX6Q_PAD_DI0_DISP_CLK__GPIO_4_16                476
-MX6Q_PAD_DI0_DISP_CLK__MMDC_DEBUG_0             477
-MX6Q_PAD_DI0_PIN15__IPU1_DI0_PIN15              478
-MX6Q_PAD_DI0_PIN15__IPU2_DI0_PIN15              479
-MX6Q_PAD_DI0_PIN15__AUDMUX_AUD6_TXC             480
-MX6Q_PAD_DI0_PIN15__MIPI_CR_DPHY_OUT_29         481
-MX6Q_PAD_DI0_PIN15__SDMA_DBG_CORE_STA_1         482
-MX6Q_PAD_DI0_PIN15__GPIO_4_17                   483
-MX6Q_PAD_DI0_PIN15__MMDC_MMDC_DEBUG_1           484
-MX6Q_PAD_DI0_PIN2__IPU1_DI0_PIN2                485
-MX6Q_PAD_DI0_PIN2__IPU2_DI0_PIN2                486
-MX6Q_PAD_DI0_PIN2__AUDMUX_AUD6_TXD              487
-MX6Q_PAD_DI0_PIN2__MIPI_CR_DPHY_OUT_30          488
-MX6Q_PAD_DI0_PIN2__SDMA_DBG_CORE_STA_2          489
-MX6Q_PAD_DI0_PIN2__GPIO_4_18                    490
-MX6Q_PAD_DI0_PIN2__MMDC_DEBUG_2                 491
-MX6Q_PAD_DI0_PIN2__PL301_PER1_HADDR_9           492
-MX6Q_PAD_DI0_PIN3__IPU1_DI0_PIN3                493
-MX6Q_PAD_DI0_PIN3__IPU2_DI0_PIN3                494
-MX6Q_PAD_DI0_PIN3__AUDMUX_AUD6_TXFS             495
-MX6Q_PAD_DI0_PIN3__MIPI_CORE_DPHY_OUT31         496
-MX6Q_PAD_DI0_PIN3__SDMA_DBG_CORE_STA_3          497
-MX6Q_PAD_DI0_PIN3__GPIO_4_19                    498
-MX6Q_PAD_DI0_PIN3__MMDC_MMDC_DEBUG_3            499
-MX6Q_PAD_DI0_PIN3__PL301_PER1_HADDR_10          500
-MX6Q_PAD_DI0_PIN4__IPU1_DI0_PIN4                501
-MX6Q_PAD_DI0_PIN4__IPU2_DI0_PIN4                502
-MX6Q_PAD_DI0_PIN4__AUDMUX_AUD6_RXD              503
-MX6Q_PAD_DI0_PIN4__USDHC1_WP                    504
-MX6Q_PAD_DI0_PIN4__SDMA_DEBUG_YIELD             505
-MX6Q_PAD_DI0_PIN4__GPIO_4_20                    506
-MX6Q_PAD_DI0_PIN4__MMDC_MMDC_DEBUG_4            507
-MX6Q_PAD_DI0_PIN4__PL301_PER1_HADDR_11          508
-MX6Q_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0           509
-MX6Q_PAD_DISP0_DAT0__IPU2_DISP0_DAT_0           510
-MX6Q_PAD_DISP0_DAT0__ECSPI3_SCLK                511
-MX6Q_PAD_DISP0_DAT0__USDHC1_USDHC_DBG_0         512
-MX6Q_PAD_DISP0_DAT0__SDMA_DBG_CORE_RUN          513
-MX6Q_PAD_DISP0_DAT0__GPIO_4_21                  514
-MX6Q_PAD_DISP0_DAT0__MMDC_MMDC_DEBUG_5          515
-MX6Q_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1           516
-MX6Q_PAD_DISP0_DAT1__IPU2_DISP0_DAT_1           517
-MX6Q_PAD_DISP0_DAT1__ECSPI3_MOSI                518
-MX6Q_PAD_DISP0_DAT1__USDHC1_USDHC_DBG_1         519
-MX6Q_PAD_DISP0_DAT1__SDMA_DBG_EVT_CHNSL         520
-MX6Q_PAD_DISP0_DAT1__GPIO_4_22                  521
-MX6Q_PAD_DISP0_DAT1__MMDC_DEBUG_6               522
-MX6Q_PAD_DISP0_DAT1__PL301_PER1_HADR_12         523
-MX6Q_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2           524
-MX6Q_PAD_DISP0_DAT2__IPU2_DISP0_DAT_2           525
-MX6Q_PAD_DISP0_DAT2__ECSPI3_MISO                526
-MX6Q_PAD_DISP0_DAT2__USDHC1_USDHC_DBG_2         527
-MX6Q_PAD_DISP0_DAT2__SDMA_DEBUG_MODE            528
-MX6Q_PAD_DISP0_DAT2__GPIO_4_23                  529
-MX6Q_PAD_DISP0_DAT2__MMDC_DEBUG_7               530
-MX6Q_PAD_DISP0_DAT2__PL301_PER1_HADR_13         531
-MX6Q_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3           532
-MX6Q_PAD_DISP0_DAT3__IPU2_DISP0_DAT_3           533
-MX6Q_PAD_DISP0_DAT3__ECSPI3_SS0                 534
-MX6Q_PAD_DISP0_DAT3__USDHC1_USDHC_DBG_3         535
-MX6Q_PAD_DISP0_DAT3__SDMA_DBG_BUS_ERROR         536
-MX6Q_PAD_DISP0_DAT3__GPIO_4_24                  537
-MX6Q_PAD_DISP0_DAT3__MMDC_MMDC_DBG_8            538
-MX6Q_PAD_DISP0_DAT3__PL301_PER1_HADR_14         539
-MX6Q_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4           540
-MX6Q_PAD_DISP0_DAT4__IPU2_DISP0_DAT_4           541
-MX6Q_PAD_DISP0_DAT4__ECSPI3_SS1                 542
-MX6Q_PAD_DISP0_DAT4__USDHC1_USDHC_DBG_4         543
-MX6Q_PAD_DISP0_DAT4__SDMA_DEBUG_BUS_RWB         544
-MX6Q_PAD_DISP0_DAT4__GPIO_4_25                  545
-MX6Q_PAD_DISP0_DAT4__MMDC_MMDC_DEBUG_9          546
-MX6Q_PAD_DISP0_DAT4__PL301_PER1_HADR_15         547
-MX6Q_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5           548
-MX6Q_PAD_DISP0_DAT5__IPU2_DISP0_DAT_5           549
-MX6Q_PAD_DISP0_DAT5__ECSPI3_SS2                 550
-MX6Q_PAD_DISP0_DAT5__AUDMUX_AUD6_RXFS           551
-MX6Q_PAD_DISP0_DAT5__SDMA_DBG_MCH_DMBUS         552
-MX6Q_PAD_DISP0_DAT5__GPIO_4_26                  553
-MX6Q_PAD_DISP0_DAT5__MMDC_DEBUG_10              554
-MX6Q_PAD_DISP0_DAT5__PL301_PER1_HADR_16         555
-MX6Q_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6           556
-MX6Q_PAD_DISP0_DAT6__IPU2_DISP0_DAT_6           557
-MX6Q_PAD_DISP0_DAT6__ECSPI3_SS3                 558
-MX6Q_PAD_DISP0_DAT6__AUDMUX_AUD6_RXC            559
-MX6Q_PAD_DISP0_DAT6__SDMA_DBG_RTBUF_WRT         560
-MX6Q_PAD_DISP0_DAT6__GPIO_4_27                  561
-MX6Q_PAD_DISP0_DAT6__MMDC_DEBUG_11              562
-MX6Q_PAD_DISP0_DAT6__PL301_PER1_HADR_17         563
-MX6Q_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7           564
-MX6Q_PAD_DISP0_DAT7__IPU2_DISP0_DAT_7           565
-MX6Q_PAD_DISP0_DAT7__ECSPI3_RDY                 566
-MX6Q_PAD_DISP0_DAT7__USDHC1_USDHC_DBG_5         567
-MX6Q_PAD_DISP0_DAT7__SDMA_DBG_EVT_CHN_0         568
-MX6Q_PAD_DISP0_DAT7__GPIO_4_28                  569
-MX6Q_PAD_DISP0_DAT7__MMDC_DEBUG_12              570
-MX6Q_PAD_DISP0_DAT7__PL301_PER1_HADR_18         571
-MX6Q_PAD_DISP0_DAT8__IPU1_DISP0_DAT_8           572
-MX6Q_PAD_DISP0_DAT8__IPU2_DISP0_DAT_8           573
-MX6Q_PAD_DISP0_DAT8__PWM1_PWMO                  574
-MX6Q_PAD_DISP0_DAT8__WDOG1_WDOG_B               575
-MX6Q_PAD_DISP0_DAT8__SDMA_DBG_EVT_CHN_1         576
-MX6Q_PAD_DISP0_DAT8__GPIO_4_29                  577
-MX6Q_PAD_DISP0_DAT8__MMDC_DEBUG_13              578
-MX6Q_PAD_DISP0_DAT8__PL301_PER1_HADR_19         579
-MX6Q_PAD_DISP0_DAT9__IPU1_DISP0_DAT_9           580
-MX6Q_PAD_DISP0_DAT9__IPU2_DISP0_DAT_9           581
-MX6Q_PAD_DISP0_DAT9__PWM2_PWMO                  582
-MX6Q_PAD_DISP0_DAT9__WDOG2_WDOG_B               583
-MX6Q_PAD_DISP0_DAT9__SDMA_DBG_EVT_CHN_2         584
-MX6Q_PAD_DISP0_DAT9__GPIO_4_30                  585
-MX6Q_PAD_DISP0_DAT9__MMDC_DEBUG_14              586
-MX6Q_PAD_DISP0_DAT9__PL301_PER1_HADR_20         587
-MX6Q_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10         588
-MX6Q_PAD_DISP0_DAT10__IPU2_DISP0_DAT_10         589
-MX6Q_PAD_DISP0_DAT10__USDHC1_DBG_6              590
-MX6Q_PAD_DISP0_DAT10__SDMA_DBG_EVT_CHN3         591
-MX6Q_PAD_DISP0_DAT10__GPIO_4_31                 592
-MX6Q_PAD_DISP0_DAT10__MMDC_DEBUG_15             593
-MX6Q_PAD_DISP0_DAT10__PL301_PER1_HADR21         594
-MX6Q_PAD_DISP0_DAT11__IPU1_DISP0_DAT_11         595
-MX6Q_PAD_DISP0_DAT11__IPU2_DISP0_DAT_11         596
-MX6Q_PAD_DISP0_DAT11__USDHC1_USDHC_DBG7         597
-MX6Q_PAD_DISP0_DAT11__SDMA_DBG_EVT_CHN4         598
-MX6Q_PAD_DISP0_DAT11__GPIO_5_5                  599
-MX6Q_PAD_DISP0_DAT11__MMDC_DEBUG_16             600
-MX6Q_PAD_DISP0_DAT11__PL301_PER1_HADR22         601
-MX6Q_PAD_DISP0_DAT12__IPU1_DISP0_DAT_12         602
-MX6Q_PAD_DISP0_DAT12__IPU2_DISP0_DAT_12         603
-MX6Q_PAD_DISP0_DAT12__RESERVED_RESERVED         604
-MX6Q_PAD_DISP0_DAT12__SDMA_DBG_EVT_CHN5         605
-MX6Q_PAD_DISP0_DAT12__GPIO_5_6                  606
-MX6Q_PAD_DISP0_DAT12__MMDC_DEBUG_17             607
-MX6Q_PAD_DISP0_DAT12__PL301_PER1_HADR23         608
-MX6Q_PAD_DISP0_DAT13__IPU1_DISP0_DAT_13         609
-MX6Q_PAD_DISP0_DAT13__IPU2_DISP0_DAT_13         610
-MX6Q_PAD_DISP0_DAT13__AUDMUX_AUD5_RXFS          611
-MX6Q_PAD_DISP0_DAT13__SDMA_DBG_EVT_CHN0         612
-MX6Q_PAD_DISP0_DAT13__GPIO_5_7                  613
-MX6Q_PAD_DISP0_DAT13__MMDC_DEBUG_18             614
-MX6Q_PAD_DISP0_DAT13__PL301_PER1_HADR24         615
-MX6Q_PAD_DISP0_DAT14__IPU1_DISP0_DAT_14         616
-MX6Q_PAD_DISP0_DAT14__IPU2_DISP0_DAT_14         617
-MX6Q_PAD_DISP0_DAT14__AUDMUX_AUD5_RXC           618
-MX6Q_PAD_DISP0_DAT14__SDMA_DBG_EVT_CHN1         619
-MX6Q_PAD_DISP0_DAT14__GPIO_5_8                  620
-MX6Q_PAD_DISP0_DAT14__MMDC_DEBUG_19             621
-MX6Q_PAD_DISP0_DAT15__IPU1_DISP0_DAT_15         622
-MX6Q_PAD_DISP0_DAT15__IPU2_DISP0_DAT_15         623
-MX6Q_PAD_DISP0_DAT15__ECSPI1_SS1                624
-MX6Q_PAD_DISP0_DAT15__ECSPI2_SS1                625
-MX6Q_PAD_DISP0_DAT15__SDMA_DBG_EVT_CHN2         626
-MX6Q_PAD_DISP0_DAT15__GPIO_5_9                  627
-MX6Q_PAD_DISP0_DAT15__MMDC_DEBUG_20             628
-MX6Q_PAD_DISP0_DAT15__PL301_PER1_HADR25         629
-MX6Q_PAD_DISP0_DAT16__IPU1_DISP0_DAT_16         630
-MX6Q_PAD_DISP0_DAT16__IPU2_DISP0_DAT_16         631
-MX6Q_PAD_DISP0_DAT16__ECSPI2_MOSI               632
-MX6Q_PAD_DISP0_DAT16__AUDMUX_AUD5_TXC           633
-MX6Q_PAD_DISP0_DAT16__SDMA_EXT_EVENT_0          634
-MX6Q_PAD_DISP0_DAT16__GPIO_5_10                 635
-MX6Q_PAD_DISP0_DAT16__MMDC_DEBUG_21             636
-MX6Q_PAD_DISP0_DAT16__PL301_PER1_HADR26         637
-MX6Q_PAD_DISP0_DAT17__IPU1_DISP0_DAT_17         638
-MX6Q_PAD_DISP0_DAT17__IPU2_DISP0_DAT_17         639
-MX6Q_PAD_DISP0_DAT17__ECSPI2_MISO               640
-MX6Q_PAD_DISP0_DAT17__AUDMUX_AUD5_TXD           641
-MX6Q_PAD_DISP0_DAT17__SDMA_EXT_EVENT_1          642
-MX6Q_PAD_DISP0_DAT17__GPIO_5_11                 643
-MX6Q_PAD_DISP0_DAT17__MMDC_DEBUG_22             644
-MX6Q_PAD_DISP0_DAT17__PL301_PER1_HADR27         645
-MX6Q_PAD_DISP0_DAT18__IPU1_DISP0_DAT_18         646
-MX6Q_PAD_DISP0_DAT18__IPU2_DISP0_DAT_18         647
-MX6Q_PAD_DISP0_DAT18__ECSPI2_SS0                648
-MX6Q_PAD_DISP0_DAT18__AUDMUX_AUD5_TXFS          649
-MX6Q_PAD_DISP0_DAT18__AUDMUX_AUD4_RXFS          650
-MX6Q_PAD_DISP0_DAT18__GPIO_5_12                 651
-MX6Q_PAD_DISP0_DAT18__MMDC_DEBUG_23             652
-MX6Q_PAD_DISP0_DAT18__WEIM_WEIM_CS_2            653
-MX6Q_PAD_DISP0_DAT19__IPU1_DISP0_DAT_19         654
-MX6Q_PAD_DISP0_DAT19__IPU2_DISP0_DAT_19         655
-MX6Q_PAD_DISP0_DAT19__ECSPI2_SCLK               656
-MX6Q_PAD_DISP0_DAT19__AUDMUX_AUD5_RXD           657
-MX6Q_PAD_DISP0_DAT19__AUDMUX_AUD4_RXC           658
-MX6Q_PAD_DISP0_DAT19__GPIO_5_13                 659
-MX6Q_PAD_DISP0_DAT19__MMDC_DEBUG_24             660
-MX6Q_PAD_DISP0_DAT19__WEIM_WEIM_CS_3            661
-MX6Q_PAD_DISP0_DAT20__IPU1_DISP0_DAT_20         662
-MX6Q_PAD_DISP0_DAT20__IPU2_DISP0_DAT_20         663
-MX6Q_PAD_DISP0_DAT20__ECSPI1_SCLK               664
-MX6Q_PAD_DISP0_DAT20__AUDMUX_AUD4_TXC           665
-MX6Q_PAD_DISP0_DAT20__SDMA_DBG_EVT_CHN7         666
-MX6Q_PAD_DISP0_DAT20__GPIO_5_14                 667
-MX6Q_PAD_DISP0_DAT20__MMDC_DEBUG_25             668
-MX6Q_PAD_DISP0_DAT20__PL301_PER1_HADR28         669
-MX6Q_PAD_DISP0_DAT21__IPU1_DISP0_DAT_21         670
-MX6Q_PAD_DISP0_DAT21__IPU2_DISP0_DAT_21         671
-MX6Q_PAD_DISP0_DAT21__ECSPI1_MOSI               672
-MX6Q_PAD_DISP0_DAT21__AUDMUX_AUD4_TXD           673
-MX6Q_PAD_DISP0_DAT21__SDMA_DBG_BUS_DEV0         674
-MX6Q_PAD_DISP0_DAT21__GPIO_5_15                 675
-MX6Q_PAD_DISP0_DAT21__MMDC_DEBUG_26             676
-MX6Q_PAD_DISP0_DAT21__PL301_PER1_HADR29         677
-MX6Q_PAD_DISP0_DAT22__IPU1_DISP0_DAT_22         678
-MX6Q_PAD_DISP0_DAT22__IPU2_DISP0_DAT_22         679
-MX6Q_PAD_DISP0_DAT22__ECSPI1_MISO               680
-MX6Q_PAD_DISP0_DAT22__AUDMUX_AUD4_TXFS          681
-MX6Q_PAD_DISP0_DAT22__SDMA_DBG_BUS_DEV1         682
-MX6Q_PAD_DISP0_DAT22__GPIO_5_16                 683
-MX6Q_PAD_DISP0_DAT22__MMDC_DEBUG_27             684
-MX6Q_PAD_DISP0_DAT22__PL301_PER1_HADR30         685
-MX6Q_PAD_DISP0_DAT23__IPU1_DISP0_DAT_23         686
-MX6Q_PAD_DISP0_DAT23__IPU2_DISP0_DAT_23         687
-MX6Q_PAD_DISP0_DAT23__ECSPI1_SS0                688
-MX6Q_PAD_DISP0_DAT23__AUDMUX_AUD4_RXD           689
-MX6Q_PAD_DISP0_DAT23__SDMA_DBG_BUS_DEV2         690
-MX6Q_PAD_DISP0_DAT23__GPIO_5_17                 691
-MX6Q_PAD_DISP0_DAT23__MMDC_DEBUG_28             692
-MX6Q_PAD_DISP0_DAT23__PL301_PER1_HADR31         693
-MX6Q_PAD_ENET_MDIO__RESERVED_RESERVED           694
-MX6Q_PAD_ENET_MDIO__ENET_MDIO                   695
-MX6Q_PAD_ENET_MDIO__ESAI1_SCKR                  696
-MX6Q_PAD_ENET_MDIO__SDMA_DEBUG_BUS_DEV3         697
-MX6Q_PAD_ENET_MDIO__ENET_1588_EVT1_OUT          698
-MX6Q_PAD_ENET_MDIO__GPIO_1_22                   699
-MX6Q_PAD_ENET_MDIO__SPDIF_PLOCK                 700
-MX6Q_PAD_ENET_REF_CLK__RESERVED_RSRVED          701
-MX6Q_PAD_ENET_REF_CLK__ENET_TX_CLK              702
-MX6Q_PAD_ENET_REF_CLK__ESAI1_FSR                703
-MX6Q_PAD_ENET_REF_CLK__SDMA_DBGBUS_DEV4         704
-MX6Q_PAD_ENET_REF_CLK__GPIO_1_23                705
-MX6Q_PAD_ENET_REF_CLK__SPDIF_SRCLK              706
-MX6Q_PAD_ENET_REF_CLK__USBPHY1_RX_SQH           707
-MX6Q_PAD_ENET_RX_ER__ENET_RX_ER                 708
-MX6Q_PAD_ENET_RX_ER__ESAI1_HCKR                 709
-MX6Q_PAD_ENET_RX_ER__SPDIF_IN1                  710
-MX6Q_PAD_ENET_RX_ER__ENET_1588_EVT2_OUT         711
-MX6Q_PAD_ENET_RX_ER__GPIO_1_24                  712
-MX6Q_PAD_ENET_RX_ER__PHY_TDI                    713
-MX6Q_PAD_ENET_RX_ER__USBPHY1_RX_HS_RXD          714
-MX6Q_PAD_ENET_CRS_DV__RESERVED_RSRVED           715
-MX6Q_PAD_ENET_CRS_DV__ENET_RX_EN                716
-MX6Q_PAD_ENET_CRS_DV__ESAI1_SCKT                717
-MX6Q_PAD_ENET_CRS_DV__SPDIF_EXTCLK              718
-MX6Q_PAD_ENET_CRS_DV__GPIO_1_25                 719
-MX6Q_PAD_ENET_CRS_DV__PHY_TDO                   720
-MX6Q_PAD_ENET_CRS_DV__USBPHY1_RX_FS_RXD         721
-MX6Q_PAD_ENET_RXD1__MLB_MLBSIG                  722
-MX6Q_PAD_ENET_RXD1__ENET_RDATA_1                723
-MX6Q_PAD_ENET_RXD1__ESAI1_FST                   724
-MX6Q_PAD_ENET_RXD1__ENET_1588_EVT3_OUT          725
-MX6Q_PAD_ENET_RXD1__GPIO_1_26                   726
-MX6Q_PAD_ENET_RXD1__PHY_TCK                     727
-MX6Q_PAD_ENET_RXD1__USBPHY1_RX_DISCON           728
-MX6Q_PAD_ENET_RXD0__OSC32K_32K_OUT              729
-MX6Q_PAD_ENET_RXD0__ENET_RDATA_0                730
-MX6Q_PAD_ENET_RXD0__ESAI1_HCKT                  731
-MX6Q_PAD_ENET_RXD0__SPDIF_OUT1                  732
-MX6Q_PAD_ENET_RXD0__GPIO_1_27                   733
-MX6Q_PAD_ENET_RXD0__PHY_TMS                     734
-MX6Q_PAD_ENET_RXD0__USBPHY1_PLL_CK20DIV         735
-MX6Q_PAD_ENET_TX_EN__RESERVED_RSRVED            736
-MX6Q_PAD_ENET_TX_EN__ENET_TX_EN                 737
-MX6Q_PAD_ENET_TX_EN__ESAI1_TX3_RX2              738
-MX6Q_PAD_ENET_TX_EN__GPIO_1_28                  739
-MX6Q_PAD_ENET_TX_EN__SATA_PHY_TDI               740
-MX6Q_PAD_ENET_TX_EN__USBPHY2_RX_SQH             741
-MX6Q_PAD_ENET_TXD1__MLB_MLBCLK                  742
-MX6Q_PAD_ENET_TXD1__ENET_TDATA_1                743
-MX6Q_PAD_ENET_TXD1__ESAI1_TX2_RX3               744
-MX6Q_PAD_ENET_TXD1__ENET_1588_EVENT0_IN         745
-MX6Q_PAD_ENET_TXD1__GPIO_1_29                   746
-MX6Q_PAD_ENET_TXD1__SATA_PHY_TDO                747
-MX6Q_PAD_ENET_TXD1__USBPHY2_RX_HS_RXD           748
-MX6Q_PAD_ENET_TXD0__RESERVED_RSRVED             749
-MX6Q_PAD_ENET_TXD0__ENET_TDATA_0                750
-MX6Q_PAD_ENET_TXD0__ESAI1_TX4_RX1               751
-MX6Q_PAD_ENET_TXD0__GPIO_1_30                   752
-MX6Q_PAD_ENET_TXD0__SATA_PHY_TCK                753
-MX6Q_PAD_ENET_TXD0__USBPHY2_RX_FS_RXD           754
-MX6Q_PAD_ENET_MDC__MLB_MLBDAT                   755
-MX6Q_PAD_ENET_MDC__ENET_MDC                     756
-MX6Q_PAD_ENET_MDC__ESAI1_TX5_RX0                757
-MX6Q_PAD_ENET_MDC__ENET_1588_EVENT1_IN          758
-MX6Q_PAD_ENET_MDC__GPIO_1_31                    759
-MX6Q_PAD_ENET_MDC__SATA_PHY_TMS                 760
-MX6Q_PAD_ENET_MDC__USBPHY2_RX_DISCON            761
-MX6Q_PAD_DRAM_D40__MMDC_DRAM_D_40               762
-MX6Q_PAD_DRAM_D41__MMDC_DRAM_D_41               763
-MX6Q_PAD_DRAM_D42__MMDC_DRAM_D_42               764
-MX6Q_PAD_DRAM_D43__MMDC_DRAM_D_43               765
-MX6Q_PAD_DRAM_D44__MMDC_DRAM_D_44               766
-MX6Q_PAD_DRAM_D45__MMDC_DRAM_D_45               767
-MX6Q_PAD_DRAM_D46__MMDC_DRAM_D_46               768
-MX6Q_PAD_DRAM_D47__MMDC_DRAM_D_47               769
-MX6Q_PAD_DRAM_SDQS5__MMDC_DRAM_SDQS_5           770
-MX6Q_PAD_DRAM_DQM5__MMDC_DRAM_DQM_5             771
-MX6Q_PAD_DRAM_D32__MMDC_DRAM_D_32               772
-MX6Q_PAD_DRAM_D33__MMDC_DRAM_D_33               773
-MX6Q_PAD_DRAM_D34__MMDC_DRAM_D_34               774
-MX6Q_PAD_DRAM_D35__MMDC_DRAM_D_35               775
-MX6Q_PAD_DRAM_D36__MMDC_DRAM_D_36               776
-MX6Q_PAD_DRAM_D37__MMDC_DRAM_D_37               777
-MX6Q_PAD_DRAM_D38__MMDC_DRAM_D_38               778
-MX6Q_PAD_DRAM_D39__MMDC_DRAM_D_39               779
-MX6Q_PAD_DRAM_DQM4__MMDC_DRAM_DQM_4             780
-MX6Q_PAD_DRAM_SDQS4__MMDC_DRAM_SDQS_4           781
-MX6Q_PAD_DRAM_D24__MMDC_DRAM_D_24               782
-MX6Q_PAD_DRAM_D25__MMDC_DRAM_D_25               783
-MX6Q_PAD_DRAM_D26__MMDC_DRAM_D_26               784
-MX6Q_PAD_DRAM_D27__MMDC_DRAM_D_27               785
-MX6Q_PAD_DRAM_D28__MMDC_DRAM_D_28               786
-MX6Q_PAD_DRAM_D29__MMDC_DRAM_D_29               787
-MX6Q_PAD_DRAM_SDQS3__MMDC_DRAM_SDQS_3           788
-MX6Q_PAD_DRAM_D30__MMDC_DRAM_D_30               789
-MX6Q_PAD_DRAM_D31__MMDC_DRAM_D_31               790
-MX6Q_PAD_DRAM_DQM3__MMDC_DRAM_DQM_3             791
-MX6Q_PAD_DRAM_D16__MMDC_DRAM_D_16               792
-MX6Q_PAD_DRAM_D17__MMDC_DRAM_D_17               793
-MX6Q_PAD_DRAM_D18__MMDC_DRAM_D_18               794
-MX6Q_PAD_DRAM_D19__MMDC_DRAM_D_19               795
-MX6Q_PAD_DRAM_D20__MMDC_DRAM_D_20               796
-MX6Q_PAD_DRAM_D21__MMDC_DRAM_D_21               797
-MX6Q_PAD_DRAM_D22__MMDC_DRAM_D_22               798
-MX6Q_PAD_DRAM_SDQS2__MMDC_DRAM_SDQS_2           799
-MX6Q_PAD_DRAM_D23__MMDC_DRAM_D_23               800
-MX6Q_PAD_DRAM_DQM2__MMDC_DRAM_DQM_2             801
-MX6Q_PAD_DRAM_A0__MMDC_DRAM_A_0                 802
-MX6Q_PAD_DRAM_A1__MMDC_DRAM_A_1                 803
-MX6Q_PAD_DRAM_A2__MMDC_DRAM_A_2                 804
-MX6Q_PAD_DRAM_A3__MMDC_DRAM_A_3                 805
-MX6Q_PAD_DRAM_A4__MMDC_DRAM_A_4                 806
-MX6Q_PAD_DRAM_A5__MMDC_DRAM_A_5                 807
-MX6Q_PAD_DRAM_A6__MMDC_DRAM_A_6                 808
-MX6Q_PAD_DRAM_A7__MMDC_DRAM_A_7                 809
-MX6Q_PAD_DRAM_A8__MMDC_DRAM_A_8                 810
-MX6Q_PAD_DRAM_A9__MMDC_DRAM_A_9                 811
-MX6Q_PAD_DRAM_A10__MMDC_DRAM_A_10               812
-MX6Q_PAD_DRAM_A11__MMDC_DRAM_A_11               813
-MX6Q_PAD_DRAM_A12__MMDC_DRAM_A_12               814
-MX6Q_PAD_DRAM_A13__MMDC_DRAM_A_13               815
-MX6Q_PAD_DRAM_A14__MMDC_DRAM_A_14               816
-MX6Q_PAD_DRAM_A15__MMDC_DRAM_A_15               817
-MX6Q_PAD_DRAM_CAS__MMDC_DRAM_CAS                818
-MX6Q_PAD_DRAM_CS0__MMDC_DRAM_CS_0               819
-MX6Q_PAD_DRAM_CS1__MMDC_DRAM_CS_1               820
-MX6Q_PAD_DRAM_RAS__MMDC_DRAM_RAS                821
-MX6Q_PAD_DRAM_RESET__MMDC_DRAM_RESET            822
-MX6Q_PAD_DRAM_SDBA0__MMDC_DRAM_SDBA_0           823
-MX6Q_PAD_DRAM_SDBA1__MMDC_DRAM_SDBA_1           824
-MX6Q_PAD_DRAM_SDCLK_0__MMDC_DRAM_SDCLK0         825
-MX6Q_PAD_DRAM_SDBA2__MMDC_DRAM_SDBA_2           826
-MX6Q_PAD_DRAM_SDCKE0__MMDC_DRAM_SDCKE_0         827
-MX6Q_PAD_DRAM_SDCLK_1__MMDC_DRAM_SDCLK1         828
-MX6Q_PAD_DRAM_SDCKE1__MMDC_DRAM_SDCKE_1         829
-MX6Q_PAD_DRAM_SDODT0__MMDC_DRAM_ODT_0           830
-MX6Q_PAD_DRAM_SDODT1__MMDC_DRAM_ODT_1           831
-MX6Q_PAD_DRAM_SDWE__MMDC_DRAM_SDWE              832
-MX6Q_PAD_DRAM_D0__MMDC_DRAM_D_0                 833
-MX6Q_PAD_DRAM_D1__MMDC_DRAM_D_1                 834
-MX6Q_PAD_DRAM_D2__MMDC_DRAM_D_2                 835
-MX6Q_PAD_DRAM_D3__MMDC_DRAM_D_3                 836
-MX6Q_PAD_DRAM_D4__MMDC_DRAM_D_4                 837
-MX6Q_PAD_DRAM_D5__MMDC_DRAM_D_5                 838
-MX6Q_PAD_DRAM_SDQS0__MMDC_DRAM_SDQS_0           839
-MX6Q_PAD_DRAM_D6__MMDC_DRAM_D_6                 840
-MX6Q_PAD_DRAM_D7__MMDC_DRAM_D_7                 841
-MX6Q_PAD_DRAM_DQM0__MMDC_DRAM_DQM_0             842
-MX6Q_PAD_DRAM_D8__MMDC_DRAM_D_8                 843
-MX6Q_PAD_DRAM_D9__MMDC_DRAM_D_9                 844
-MX6Q_PAD_DRAM_D10__MMDC_DRAM_D_10               845
-MX6Q_PAD_DRAM_D11__MMDC_DRAM_D_11               846
-MX6Q_PAD_DRAM_D12__MMDC_DRAM_D_12               847
-MX6Q_PAD_DRAM_D13__MMDC_DRAM_D_13               848
-MX6Q_PAD_DRAM_D14__MMDC_DRAM_D_14               849
-MX6Q_PAD_DRAM_SDQS1__MMDC_DRAM_SDQS_1           850
-MX6Q_PAD_DRAM_D15__MMDC_DRAM_D_15               851
-MX6Q_PAD_DRAM_DQM1__MMDC_DRAM_DQM_1             852
-MX6Q_PAD_DRAM_D48__MMDC_DRAM_D_48               853
-MX6Q_PAD_DRAM_D49__MMDC_DRAM_D_49               854
-MX6Q_PAD_DRAM_D50__MMDC_DRAM_D_50               855
-MX6Q_PAD_DRAM_D51__MMDC_DRAM_D_51               856
-MX6Q_PAD_DRAM_D52__MMDC_DRAM_D_52               857
-MX6Q_PAD_DRAM_D53__MMDC_DRAM_D_53               858
-MX6Q_PAD_DRAM_D54__MMDC_DRAM_D_54               859
-MX6Q_PAD_DRAM_D55__MMDC_DRAM_D_55               860
-MX6Q_PAD_DRAM_SDQS6__MMDC_DRAM_SDQS_6           861
-MX6Q_PAD_DRAM_DQM6__MMDC_DRAM_DQM_6             862
-MX6Q_PAD_DRAM_D56__MMDC_DRAM_D_56               863
-MX6Q_PAD_DRAM_SDQS7__MMDC_DRAM_SDQS_7           864
-MX6Q_PAD_DRAM_D57__MMDC_DRAM_D_57               865
-MX6Q_PAD_DRAM_D58__MMDC_DRAM_D_58               866
-MX6Q_PAD_DRAM_D59__MMDC_DRAM_D_59               867
-MX6Q_PAD_DRAM_D60__MMDC_DRAM_D_60               868
-MX6Q_PAD_DRAM_DQM7__MMDC_DRAM_DQM_7             869
-MX6Q_PAD_DRAM_D61__MMDC_DRAM_D_61               870
-MX6Q_PAD_DRAM_D62__MMDC_DRAM_D_62               871
-MX6Q_PAD_DRAM_D63__MMDC_DRAM_D_63               872
-MX6Q_PAD_KEY_COL0__ECSPI1_SCLK                  873
-MX6Q_PAD_KEY_COL0__ENET_RDATA_3                 874
-MX6Q_PAD_KEY_COL0__AUDMUX_AUD5_TXC              875
-MX6Q_PAD_KEY_COL0__KPP_COL_0                    876
-MX6Q_PAD_KEY_COL0__UART4_TXD                    877
-MX6Q_PAD_KEY_COL0__GPIO_4_6                     878
-MX6Q_PAD_KEY_COL0__DCIC1_DCIC_OUT               879
-MX6Q_PAD_KEY_COL0__SRC_ANY_PU_RST               880
-MX6Q_PAD_KEY_ROW0__ECSPI1_MOSI                  881
-MX6Q_PAD_KEY_ROW0__ENET_TDATA_3                 882
-MX6Q_PAD_KEY_ROW0__AUDMUX_AUD5_TXD              883
-MX6Q_PAD_KEY_ROW0__KPP_ROW_0                    884
-MX6Q_PAD_KEY_ROW0__UART4_RXD                    885
-MX6Q_PAD_KEY_ROW0__GPIO_4_7                     886
-MX6Q_PAD_KEY_ROW0__DCIC2_DCIC_OUT               887
-MX6Q_PAD_KEY_ROW0__PL301_PER1_HADR_0            888
-MX6Q_PAD_KEY_COL1__ECSPI1_MISO                  889
-MX6Q_PAD_KEY_COL1__ENET_MDIO                    890
-MX6Q_PAD_KEY_COL1__AUDMUX_AUD5_TXFS             891
-MX6Q_PAD_KEY_COL1__KPP_COL_1                    892
-MX6Q_PAD_KEY_COL1__UART5_TXD                    893
-MX6Q_PAD_KEY_COL1__GPIO_4_8                     894
-MX6Q_PAD_KEY_COL1__USDHC1_VSELECT               895
-MX6Q_PAD_KEY_COL1__PL301MX_PER1_HADR_1          896
-MX6Q_PAD_KEY_ROW1__ECSPI1_SS0                   897
-MX6Q_PAD_KEY_ROW1__ENET_COL                     898
-MX6Q_PAD_KEY_ROW1__AUDMUX_AUD5_RXD              899
-MX6Q_PAD_KEY_ROW1__KPP_ROW_1                    900
-MX6Q_PAD_KEY_ROW1__UART5_RXD                    901
-MX6Q_PAD_KEY_ROW1__GPIO_4_9                     902
-MX6Q_PAD_KEY_ROW1__USDHC2_VSELECT               903
-MX6Q_PAD_KEY_ROW1__PL301_PER1_HADDR_2           904
-MX6Q_PAD_KEY_COL2__ECSPI1_SS1                   905
-MX6Q_PAD_KEY_COL2__ENET_RDATA_2                 906
-MX6Q_PAD_KEY_COL2__CAN1_TXCAN                   907
-MX6Q_PAD_KEY_COL2__KPP_COL_2                    908
-MX6Q_PAD_KEY_COL2__ENET_MDC                     909
-MX6Q_PAD_KEY_COL2__GPIO_4_10                    910
-MX6Q_PAD_KEY_COL2__USBOH3_H1_PWRCTL_WKP         911
-MX6Q_PAD_KEY_COL2__PL301_PER1_HADDR_3           912
-MX6Q_PAD_KEY_ROW2__ECSPI1_SS2                   913
-MX6Q_PAD_KEY_ROW2__ENET_TDATA_2                 914
-MX6Q_PAD_KEY_ROW2__CAN1_RXCAN                   915
-MX6Q_PAD_KEY_ROW2__KPP_ROW_2                    916
-MX6Q_PAD_KEY_ROW2__USDHC2_VSELECT               917
-MX6Q_PAD_KEY_ROW2__GPIO_4_11                    918
-MX6Q_PAD_KEY_ROW2__HDMI_TX_CEC_LINE             919
-MX6Q_PAD_KEY_ROW2__PL301_PER1_HADR_4            920
-MX6Q_PAD_KEY_COL3__ECSPI1_SS3                   921
-MX6Q_PAD_KEY_COL3__ENET_CRS                     922
-MX6Q_PAD_KEY_COL3__HDMI_TX_DDC_SCL              923
-MX6Q_PAD_KEY_COL3__KPP_COL_3                    924
-MX6Q_PAD_KEY_COL3__I2C2_SCL                     925
-MX6Q_PAD_KEY_COL3__GPIO_4_12                    926
-MX6Q_PAD_KEY_COL3__SPDIF_IN1                    927
-MX6Q_PAD_KEY_COL3__PL301_PER1_HADR_5            928
-MX6Q_PAD_KEY_ROW3__OSC32K_32K_OUT               929
-MX6Q_PAD_KEY_ROW3__ASRC_ASRC_EXT_CLK            930
-MX6Q_PAD_KEY_ROW3__HDMI_TX_DDC_SDA              931
-MX6Q_PAD_KEY_ROW3__KPP_ROW_3                    932
-MX6Q_PAD_KEY_ROW3__I2C2_SDA                     933
-MX6Q_PAD_KEY_ROW3__GPIO_4_13                    934
-MX6Q_PAD_KEY_ROW3__USDHC1_VSELECT               935
-MX6Q_PAD_KEY_ROW3__PL301_PER1_HADR_6            936
-MX6Q_PAD_KEY_COL4__CAN2_TXCAN                   937
-MX6Q_PAD_KEY_COL4__IPU1_SISG_4                  938
-MX6Q_PAD_KEY_COL4__USBOH3_USBOTG_OC             939
-MX6Q_PAD_KEY_COL4__KPP_COL_4                    940
-MX6Q_PAD_KEY_COL4__UART5_RTS                    941
-MX6Q_PAD_KEY_COL4__GPIO_4_14                    942
-MX6Q_PAD_KEY_COL4__MMDC_DEBUG_49                943
-MX6Q_PAD_KEY_COL4__PL301_PER1_HADDR_7           944
-MX6Q_PAD_KEY_ROW4__CAN2_RXCAN                   945
-MX6Q_PAD_KEY_ROW4__IPU1_SISG_5                  946
-MX6Q_PAD_KEY_ROW4__USBOH3_USBOTG_PWR            947
-MX6Q_PAD_KEY_ROW4__KPP_ROW_4                    948
-MX6Q_PAD_KEY_ROW4__UART5_CTS                    949
-MX6Q_PAD_KEY_ROW4__GPIO_4_15                    950
-MX6Q_PAD_KEY_ROW4__MMDC_DEBUG_50                951
-MX6Q_PAD_KEY_ROW4__PL301_PER1_HADR_8            952
-MX6Q_PAD_GPIO_0__CCM_CLKO                       953
-MX6Q_PAD_GPIO_0__KPP_COL_5                      954
-MX6Q_PAD_GPIO_0__ASRC_ASRC_EXT_CLK              955
-MX6Q_PAD_GPIO_0__EPIT1_EPITO                    956
-MX6Q_PAD_GPIO_0__GPIO_1_0                       957
-MX6Q_PAD_GPIO_0__USBOH3_USBH1_PWR               958
-MX6Q_PAD_GPIO_0__SNVS_HP_WRAP_SNVS_VIO5         959
-MX6Q_PAD_GPIO_1__ESAI1_SCKR                     960
-MX6Q_PAD_GPIO_1__WDOG2_WDOG_B                   961
-MX6Q_PAD_GPIO_1__KPP_ROW_5                      962
-MX6Q_PAD_GPIO_1__PWM2_PWMO                      963
-MX6Q_PAD_GPIO_1__GPIO_1_1                       964
-MX6Q_PAD_GPIO_1__USDHC1_CD                      965
-MX6Q_PAD_GPIO_1__SRC_TESTER_ACK                 966
-MX6Q_PAD_GPIO_9__ESAI1_FSR                      967
-MX6Q_PAD_GPIO_9__WDOG1_WDOG_B                   968
-MX6Q_PAD_GPIO_9__KPP_COL_6                      969
-MX6Q_PAD_GPIO_9__CCM_REF_EN_B                   970
-MX6Q_PAD_GPIO_9__PWM1_PWMO                      971
-MX6Q_PAD_GPIO_9__GPIO_1_9                       972
-MX6Q_PAD_GPIO_9__USDHC1_WP                      973
-MX6Q_PAD_GPIO_9__SRC_EARLY_RST                  974
-MX6Q_PAD_GPIO_3__ESAI1_HCKR                     975
-MX6Q_PAD_GPIO_3__OBSERVE_MUX_INT_OUT0           976
-MX6Q_PAD_GPIO_3__I2C3_SCL                       977
-MX6Q_PAD_GPIO_3__ANATOP_24M_OUT                 978
-MX6Q_PAD_GPIO_3__CCM_CLKO2                      979
-MX6Q_PAD_GPIO_3__GPIO_1_3                       980
-MX6Q_PAD_GPIO_3__USBOH3_USBH1_OC                981
-MX6Q_PAD_GPIO_3__MLB_MLBCLK                     982
-MX6Q_PAD_GPIO_6__ESAI1_SCKT                     983
-MX6Q_PAD_GPIO_6__OBSERVE_MUX_INT_OUT1           984
-MX6Q_PAD_GPIO_6__I2C3_SDA                       985
-MX6Q_PAD_GPIO_6__CCM_CCM_OUT_0                  986
-MX6Q_PAD_GPIO_6__CSU_CSU_INT_DEB                987
-MX6Q_PAD_GPIO_6__GPIO_1_6                       988
-MX6Q_PAD_GPIO_6__USDHC2_LCTL                    989
-MX6Q_PAD_GPIO_6__MLB_MLBSIG                     990
-MX6Q_PAD_GPIO_2__ESAI1_FST                      991
-MX6Q_PAD_GPIO_2__OBSERVE_MUX_INT_OUT2           992
-MX6Q_PAD_GPIO_2__KPP_ROW_6                      993
-MX6Q_PAD_GPIO_2__CCM_CCM_OUT_1                  994
-MX6Q_PAD_GPIO_2__CSU_CSU_ALARM_AUT_0            995
-MX6Q_PAD_GPIO_2__GPIO_1_2                       996
-MX6Q_PAD_GPIO_2__USDHC2_WP                      997
-MX6Q_PAD_GPIO_2__MLB_MLBDAT                     998
-MX6Q_PAD_GPIO_4__ESAI1_HCKT                     999
-MX6Q_PAD_GPIO_4__OBSERVE_MUX_INT_OUT3           1000
-MX6Q_PAD_GPIO_4__KPP_COL_7                      1001
-MX6Q_PAD_GPIO_4__CCM_CCM_OUT_2                  1002
-MX6Q_PAD_GPIO_4__CSU_CSU_ALARM_AUT_1            1003
-MX6Q_PAD_GPIO_4__GPIO_1_4                       1004
-MX6Q_PAD_GPIO_4__USDHC2_CD                      1005
-MX6Q_PAD_GPIO_4__OCOTP_CRL_WRAR_FUSE_LA         1006
-MX6Q_PAD_GPIO_5__ESAI1_TX2_RX3                  1007
-MX6Q_PAD_GPIO_5__OBSERVE_MUX_INT_OUT4           1008
-MX6Q_PAD_GPIO_5__KPP_ROW_7                      1009
-MX6Q_PAD_GPIO_5__CCM_CLKO                       1010
-MX6Q_PAD_GPIO_5__CSU_CSU_ALARM_AUT_2            1011
-MX6Q_PAD_GPIO_5__GPIO_1_5                       1012
-MX6Q_PAD_GPIO_5__I2C3_SCL                       1013
-MX6Q_PAD_GPIO_5__CHEETAH_EVENTI                 1014
-MX6Q_PAD_GPIO_7__ESAI1_TX4_RX1                  1015
-MX6Q_PAD_GPIO_7__ECSPI5_RDY                     1016
-MX6Q_PAD_GPIO_7__EPIT1_EPITO                    1017
-MX6Q_PAD_GPIO_7__CAN1_TXCAN                     1018
-MX6Q_PAD_GPIO_7__UART2_TXD                      1019
-MX6Q_PAD_GPIO_7__GPIO_1_7                       1020
-MX6Q_PAD_GPIO_7__SPDIF_PLOCK                    1021
-MX6Q_PAD_GPIO_7__USBOH3_OTGUSB_HST_MODE         1022
-MX6Q_PAD_GPIO_8__ESAI1_TX5_RX0                  1023
-MX6Q_PAD_GPIO_8__ANATOP_ANATOP_32K_OUT          1024
-MX6Q_PAD_GPIO_8__EPIT2_EPITO                    1025
-MX6Q_PAD_GPIO_8__CAN1_RXCAN                     1026
-MX6Q_PAD_GPIO_8__UART2_RXD                      1027
-MX6Q_PAD_GPIO_8__GPIO_1_8                       1028
-MX6Q_PAD_GPIO_8__SPDIF_SRCLK                    1029
-MX6Q_PAD_GPIO_8__USBOH3_OTG_PWRCTL_WAK          1030
-MX6Q_PAD_GPIO_16__ESAI1_TX3_RX2                 1031
-MX6Q_PAD_GPIO_16__ENET_1588_EVENT2_IN           1032
-MX6Q_PAD_GPIO_16__ENET_ETHERNET_REF_OUT         1033
-MX6Q_PAD_GPIO_16__USDHC1_LCTL                   1034
-MX6Q_PAD_GPIO_16__SPDIF_IN1                     1035
-MX6Q_PAD_GPIO_16__GPIO_7_11                     1036
-MX6Q_PAD_GPIO_16__I2C3_SDA                      1037
-MX6Q_PAD_GPIO_16__SJC_DE_B                      1038
-MX6Q_PAD_GPIO_17__ESAI1_TX0                     1039
-MX6Q_PAD_GPIO_17__ENET_1588_EVENT3_IN           1040
-MX6Q_PAD_GPIO_17__CCM_PMIC_RDY                  1041
-MX6Q_PAD_GPIO_17__SDMA_SDMA_EXT_EVENT_0         1042
-MX6Q_PAD_GPIO_17__SPDIF_OUT1                    1043
-MX6Q_PAD_GPIO_17__GPIO_7_12                     1044
-MX6Q_PAD_GPIO_17__SJC_JTAG_ACT                  1045
-MX6Q_PAD_GPIO_18__ESAI1_TX1                     1046
-MX6Q_PAD_GPIO_18__ENET_RX_CLK                   1047
-MX6Q_PAD_GPIO_18__USDHC3_VSELECT                1048
-MX6Q_PAD_GPIO_18__SDMA_SDMA_EXT_EVENT_1         1049
-MX6Q_PAD_GPIO_18__ASRC_ASRC_EXT_CLK             1050
-MX6Q_PAD_GPIO_18__GPIO_7_13                     1051
-MX6Q_PAD_GPIO_18__SNVS_HP_WRA_SNVS_VIO5         1052
-MX6Q_PAD_GPIO_18__SRC_SYSTEM_RST                1053
-MX6Q_PAD_GPIO_19__KPP_COL_5                     1054
-MX6Q_PAD_GPIO_19__ENET_1588_EVENT0_OUT          1055
-MX6Q_PAD_GPIO_19__SPDIF_OUT1                    1056
-MX6Q_PAD_GPIO_19__CCM_CLKO                      1057
-MX6Q_PAD_GPIO_19__ECSPI1_RDY                    1058
-MX6Q_PAD_GPIO_19__GPIO_4_5                      1059
-MX6Q_PAD_GPIO_19__ENET_TX_ER                    1060
-MX6Q_PAD_GPIO_19__SRC_INT_BOOT                  1061
-MX6Q_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK          1062
-MX6Q_PAD_CSI0_PIXCLK__PCIE_CTRL_MUX_12          1063
-MX6Q_PAD_CSI0_PIXCLK__SDMA_DEBUG_PC_0           1064
-MX6Q_PAD_CSI0_PIXCLK__GPIO_5_18                 1065
-MX6Q_PAD_CSI0_PIXCLK___MMDC_DEBUG_29            1066
-MX6Q_PAD_CSI0_PIXCLK__CHEETAH_EVENTO            1067
-MX6Q_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC             1068
-MX6Q_PAD_CSI0_MCLK__PCIE_CTRL_MUX_13            1069
-MX6Q_PAD_CSI0_MCLK__CCM_CLKO                    1070
-MX6Q_PAD_CSI0_MCLK__SDMA_DEBUG_PC_1             1071
-MX6Q_PAD_CSI0_MCLK__GPIO_5_19                   1072
-MX6Q_PAD_CSI0_MCLK__MMDC_MMDC_DEBUG_30          1073
-MX6Q_PAD_CSI0_MCLK__CHEETAH_TRCTL               1074
-MX6Q_PAD_CSI0_DATA_EN__IPU1_CSI0_DA_EN          1075
-MX6Q_PAD_CSI0_DATA_EN__WEIM_WEIM_D_0            1076
-MX6Q_PAD_CSI0_DATA_EN__PCIE_CTRL_MUX_14         1077
-MX6Q_PAD_CSI0_DATA_EN__SDMA_DEBUG_PC_2          1078
-MX6Q_PAD_CSI0_DATA_EN__GPIO_5_20                1079
-MX6Q_PAD_CSI0_DATA_EN__MMDC_DEBUG_31            1080
-MX6Q_PAD_CSI0_DATA_EN__CHEETAH_TRCLK            1081
-MX6Q_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC            1082
-MX6Q_PAD_CSI0_VSYNC__WEIM_WEIM_D_1              1083
-MX6Q_PAD_CSI0_VSYNC__PCIE_CTRL_MUX_15           1084
-MX6Q_PAD_CSI0_VSYNC__SDMA_DEBUG_PC_3            1085
-MX6Q_PAD_CSI0_VSYNC__GPIO_5_21                  1086
-MX6Q_PAD_CSI0_VSYNC__MMDC_DEBUG_32              1087
-MX6Q_PAD_CSI0_VSYNC__CHEETAH_TRACE_0            1088
-MX6Q_PAD_CSI0_DAT4__IPU1_CSI0_D_4               1089
-MX6Q_PAD_CSI0_DAT4__WEIM_WEIM_D_2               1090
-MX6Q_PAD_CSI0_DAT4__ECSPI1_SCLK                 1091
-MX6Q_PAD_CSI0_DAT4__KPP_COL_5                   1092
-MX6Q_PAD_CSI0_DAT4__AUDMUX_AUD3_TXC             1093
-MX6Q_PAD_CSI0_DAT4__GPIO_5_22                   1094
-MX6Q_PAD_CSI0_DAT4__MMDC_DEBUG_43               1095
-MX6Q_PAD_CSI0_DAT4__CHEETAH_TRACE_1             1096
-MX6Q_PAD_CSI0_DAT5__IPU1_CSI0_D_5               1097
-MX6Q_PAD_CSI0_DAT5__WEIM_WEIM_D_3               1098
-MX6Q_PAD_CSI0_DAT5__ECSPI1_MOSI                 1099
-MX6Q_PAD_CSI0_DAT5__KPP_ROW_5                   1100
-MX6Q_PAD_CSI0_DAT5__AUDMUX_AUD3_TXD             1101
-MX6Q_PAD_CSI0_DAT5__GPIO_5_23                   1102
-MX6Q_PAD_CSI0_DAT5__MMDC_MMDC_DEBUG_44          1103
-MX6Q_PAD_CSI0_DAT5__CHEETAH_TRACE_2             1104
-MX6Q_PAD_CSI0_DAT6__IPU1_CSI0_D_6               1105
-MX6Q_PAD_CSI0_DAT6__WEIM_WEIM_D_4               1106
-MX6Q_PAD_CSI0_DAT6__ECSPI1_MISO                 1107
-MX6Q_PAD_CSI0_DAT6__KPP_COL_6                   1108
-MX6Q_PAD_CSI0_DAT6__AUDMUX_AUD3_TXFS            1109
-MX6Q_PAD_CSI0_DAT6__GPIO_5_24                   1110
-MX6Q_PAD_CSI0_DAT6__MMDC_MMDC_DEBUG_45          1111
-MX6Q_PAD_CSI0_DAT6__CHEETAH_TRACE_3             1112
-MX6Q_PAD_CSI0_DAT7__IPU1_CSI0_D_7               1113
-MX6Q_PAD_CSI0_DAT7__WEIM_WEIM_D_5               1114
-MX6Q_PAD_CSI0_DAT7__ECSPI1_SS0                  1115
-MX6Q_PAD_CSI0_DAT7__KPP_ROW_6                   1116
-MX6Q_PAD_CSI0_DAT7__AUDMUX_AUD3_RXD             1117
-MX6Q_PAD_CSI0_DAT7__GPIO_5_25                   1118
-MX6Q_PAD_CSI0_DAT7__MMDC_MMDC_DEBUG_46          1119
-MX6Q_PAD_CSI0_DAT7__CHEETAH_TRACE_4             1120
-MX6Q_PAD_CSI0_DAT8__IPU1_CSI0_D_8               1121
-MX6Q_PAD_CSI0_DAT8__WEIM_WEIM_D_6               1122
-MX6Q_PAD_CSI0_DAT8__ECSPI2_SCLK                 1123
-MX6Q_PAD_CSI0_DAT8__KPP_COL_7                   1124
-MX6Q_PAD_CSI0_DAT8__I2C1_SDA                    1125
-MX6Q_PAD_CSI0_DAT8__GPIO_5_26                   1126
-MX6Q_PAD_CSI0_DAT8__MMDC_MMDC_DEBUG_47          1127
-MX6Q_PAD_CSI0_DAT8__CHEETAH_TRACE_5             1128
-MX6Q_PAD_CSI0_DAT9__IPU1_CSI0_D_9               1129
-MX6Q_PAD_CSI0_DAT9__WEIM_WEIM_D_7               1130
-MX6Q_PAD_CSI0_DAT9__ECSPI2_MOSI                 1131
-MX6Q_PAD_CSI0_DAT9__KPP_ROW_7                   1132
-MX6Q_PAD_CSI0_DAT9__I2C1_SCL                    1133
-MX6Q_PAD_CSI0_DAT9__GPIO_5_27                   1134
-MX6Q_PAD_CSI0_DAT9__MMDC_MMDC_DEBUG_48          1135
-MX6Q_PAD_CSI0_DAT9__CHEETAH_TRACE_6             1136
-MX6Q_PAD_CSI0_DAT10__IPU1_CSI0_D_10             1137
-MX6Q_PAD_CSI0_DAT10__AUDMUX_AUD3_RXC            1138
-MX6Q_PAD_CSI0_DAT10__ECSPI2_MISO                1139
-MX6Q_PAD_CSI0_DAT10__UART1_TXD                  1140
-MX6Q_PAD_CSI0_DAT10__SDMA_DEBUG_PC_4            1141
-MX6Q_PAD_CSI0_DAT10__GPIO_5_28                  1142
-MX6Q_PAD_CSI0_DAT10__MMDC_MMDC_DEBUG_33         1143
-MX6Q_PAD_CSI0_DAT10__CHEETAH_TRACE_7            1144
-MX6Q_PAD_CSI0_DAT11__IPU1_CSI0_D_11             1145
-MX6Q_PAD_CSI0_DAT11__AUDMUX_AUD3_RXFS           1146
-MX6Q_PAD_CSI0_DAT11__ECSPI2_SS0                 1147
-MX6Q_PAD_CSI0_DAT11__UART1_RXD                  1148
-MX6Q_PAD_CSI0_DAT11__SDMA_DEBUG_PC_5            1149
-MX6Q_PAD_CSI0_DAT11__GPIO_5_29                  1150
-MX6Q_PAD_CSI0_DAT11__MMDC_MMDC_DEBUG_34         1151
-MX6Q_PAD_CSI0_DAT11__CHEETAH_TRACE_8            1152
-MX6Q_PAD_CSI0_DAT12__IPU1_CSI0_D_12             1153
-MX6Q_PAD_CSI0_DAT12__WEIM_WEIM_D_8              1154
-MX6Q_PAD_CSI0_DAT12__PCIE_CTRL_MUX_16           1155
-MX6Q_PAD_CSI0_DAT12__UART4_TXD                  1156
-MX6Q_PAD_CSI0_DAT12__SDMA_DEBUG_PC_6            1157
-MX6Q_PAD_CSI0_DAT12__GPIO_5_30                  1158
-MX6Q_PAD_CSI0_DAT12__MMDC_MMDC_DEBUG_35         1159
-MX6Q_PAD_CSI0_DAT12__CHEETAH_TRACE_9            1160
-MX6Q_PAD_CSI0_DAT13__IPU1_CSI0_D_13             1161
-MX6Q_PAD_CSI0_DAT13__WEIM_WEIM_D_9              1162
-MX6Q_PAD_CSI0_DAT13__PCIE_CTRL_MUX_17           1163
-MX6Q_PAD_CSI0_DAT13__UART4_RXD                  1164
-MX6Q_PAD_CSI0_DAT13__SDMA_DEBUG_PC_7            1165
-MX6Q_PAD_CSI0_DAT13__GPIO_5_31                  1166
-MX6Q_PAD_CSI0_DAT13__MMDC_MMDC_DEBUG_36         1167
-MX6Q_PAD_CSI0_DAT13__CHEETAH_TRACE_10           1168
-MX6Q_PAD_CSI0_DAT14__IPU1_CSI0_D_14             1169
-MX6Q_PAD_CSI0_DAT14__WEIM_WEIM_D_10             1170
-MX6Q_PAD_CSI0_DAT14__PCIE_CTRL_MUX_18           1171
-MX6Q_PAD_CSI0_DAT14__UART5_TXD                  1172
-MX6Q_PAD_CSI0_DAT14__SDMA_DEBUG_PC_8            1173
-MX6Q_PAD_CSI0_DAT14__GPIO_6_0                   1174
-MX6Q_PAD_CSI0_DAT14__MMDC_MMDC_DEBUG_37         1175
-MX6Q_PAD_CSI0_DAT14__CHEETAH_TRACE_11           1176
-MX6Q_PAD_CSI0_DAT15__IPU1_CSI0_D_15             1177
-MX6Q_PAD_CSI0_DAT15__WEIM_WEIM_D_11             1178
-MX6Q_PAD_CSI0_DAT15__PCIE_CTRL_MUX_19           1179
-MX6Q_PAD_CSI0_DAT15__UART5_RXD                  1180
-MX6Q_PAD_CSI0_DAT15__SDMA_DEBUG_PC_9            1181
-MX6Q_PAD_CSI0_DAT15__GPIO_6_1                   1182
-MX6Q_PAD_CSI0_DAT15__MMDC_MMDC_DEBUG_38         1183
-MX6Q_PAD_CSI0_DAT15__CHEETAH_TRACE_12           1184
-MX6Q_PAD_CSI0_DAT16__IPU1_CSI0_D_16             1185
-MX6Q_PAD_CSI0_DAT16__WEIM_WEIM_D_12             1186
-MX6Q_PAD_CSI0_DAT16__PCIE_CTRL_MUX_20           1187
-MX6Q_PAD_CSI0_DAT16__UART4_RTS                  1188
-MX6Q_PAD_CSI0_DAT16__SDMA_DEBUG_PC_10           1189
-MX6Q_PAD_CSI0_DAT16__GPIO_6_2                   1190
-MX6Q_PAD_CSI0_DAT16__MMDC_MMDC_DEBUG_39         1191
-MX6Q_PAD_CSI0_DAT16__CHEETAH_TRACE_13           1192
-MX6Q_PAD_CSI0_DAT17__IPU1_CSI0_D_17             1193
-MX6Q_PAD_CSI0_DAT17__WEIM_WEIM_D_13             1194
-MX6Q_PAD_CSI0_DAT17__PCIE_CTRL_MUX_21           1195
-MX6Q_PAD_CSI0_DAT17__UART4_CTS                  1196
-MX6Q_PAD_CSI0_DAT17__SDMA_DEBUG_PC_11           1197
-MX6Q_PAD_CSI0_DAT17__GPIO_6_3                   1198
-MX6Q_PAD_CSI0_DAT17__MMDC_MMDC_DEBUG_40         1199
-MX6Q_PAD_CSI0_DAT17__CHEETAH_TRACE_14           1200
-MX6Q_PAD_CSI0_DAT18__IPU1_CSI0_D_18             1201
-MX6Q_PAD_CSI0_DAT18__WEIM_WEIM_D_14             1202
-MX6Q_PAD_CSI0_DAT18__PCIE_CTRL_MUX_22           1203
-MX6Q_PAD_CSI0_DAT18__UART5_RTS                  1204
-MX6Q_PAD_CSI0_DAT18__SDMA_DEBUG_PC_12           1205
-MX6Q_PAD_CSI0_DAT18__GPIO_6_4                   1206
-MX6Q_PAD_CSI0_DAT18__MMDC_MMDC_DEBUG_41         1207
-MX6Q_PAD_CSI0_DAT18__CHEETAH_TRACE_15           1208
-MX6Q_PAD_CSI0_DAT19__IPU1_CSI0_D_19             1209
-MX6Q_PAD_CSI0_DAT19__WEIM_WEIM_D_15             1210
-MX6Q_PAD_CSI0_DAT19__PCIE_CTRL_MUX_23           1211
-MX6Q_PAD_CSI0_DAT19__UART5_CTS                  1212
-MX6Q_PAD_CSI0_DAT19__SDMA_DEBUG_PC_13           1213
-MX6Q_PAD_CSI0_DAT19__GPIO_6_5                   1214
-MX6Q_PAD_CSI0_DAT19__MMDC_MMDC_DEBUG_42         1215
-MX6Q_PAD_CSI0_DAT19__ANATOP_TESTO_9             1216
-MX6Q_PAD_JTAG_TMS__SJC_TMS                      1217
-MX6Q_PAD_JTAG_MOD__SJC_MOD                      1218
-MX6Q_PAD_JTAG_TRSTB__SJC_TRSTB                  1219
-MX6Q_PAD_JTAG_TDI__SJC_TDI                      1220
-MX6Q_PAD_JTAG_TCK__SJC_TCK                      1221
-MX6Q_PAD_JTAG_TDO__SJC_TDO                      1222
-MX6Q_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3             1223
-MX6Q_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2             1224
-MX6Q_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK             1225
-MX6Q_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1             1226
-MX6Q_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0             1227
-MX6Q_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3             1228
-MX6Q_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK             1229
-MX6Q_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2             1230
-MX6Q_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1             1231
-MX6Q_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0             1232
-MX6Q_PAD_TAMPER__SNVS_LP_WRAP_SNVS_TD1          1233
-MX6Q_PAD_PMIC_ON_REQ__SNVS_LPWRAP_WKALM         1234
-MX6Q_PAD_PMIC_STBY_REQ__CCM_PMIC_STBYRQ         1235
-MX6Q_PAD_POR_B__SRC_POR_B                       1236
-MX6Q_PAD_BOOT_MODE1__SRC_BOOT_MODE_1            1237
-MX6Q_PAD_RESET_IN_B__SRC_RESET_B                1238
-MX6Q_PAD_BOOT_MODE0__SRC_BOOT_MODE_0            1239
-MX6Q_PAD_TEST_MODE__TCU_TEST_MODE               1240
-MX6Q_PAD_SD3_DAT7__USDHC3_DAT7                  1241
-MX6Q_PAD_SD3_DAT7__UART1_TXD                    1242
-MX6Q_PAD_SD3_DAT7__PCIE_CTRL_MUX_24             1243
-MX6Q_PAD_SD3_DAT7__USBOH3_UH3_DFD_OUT_0         1244
-MX6Q_PAD_SD3_DAT7__USBOH3_UH2_DFD_OUT_0         1245
-MX6Q_PAD_SD3_DAT7__GPIO_6_17                    1246
-MX6Q_PAD_SD3_DAT7__MIPI_CORE_DPHY_IN_12         1247
-MX6Q_PAD_SD3_DAT7__USBPHY2_CLK20DIV             1248
-MX6Q_PAD_SD3_DAT6__USDHC3_DAT6                  1249
-MX6Q_PAD_SD3_DAT6__UART1_RXD                    1250
-MX6Q_PAD_SD3_DAT6__PCIE_CTRL_MUX_25             1251
-MX6Q_PAD_SD3_DAT6__USBOH3_UH3_DFD_OUT_1         1252
-MX6Q_PAD_SD3_DAT6__USBOH3_UH2_DFD_OUT_1         1253
-MX6Q_PAD_SD3_DAT6__GPIO_6_18                    1254
-MX6Q_PAD_SD3_DAT6__MIPI_CORE_DPHY_IN_13         1255
-MX6Q_PAD_SD3_DAT6__ANATOP_TESTO_10              1256
-MX6Q_PAD_SD3_DAT5__USDHC3_DAT5                  1257
-MX6Q_PAD_SD3_DAT5__UART2_TXD                    1258
-MX6Q_PAD_SD3_DAT5__PCIE_CTRL_MUX_26             1259
-MX6Q_PAD_SD3_DAT5__USBOH3_UH3_DFD_OUT_2         1260
-MX6Q_PAD_SD3_DAT5__USBOH3_UH2_DFD_OUT_2         1261
-MX6Q_PAD_SD3_DAT5__GPIO_7_0                     1262
-MX6Q_PAD_SD3_DAT5__MIPI_CORE_DPHY_IN_14         1263
-MX6Q_PAD_SD3_DAT5__ANATOP_TESTO_11              1264
-MX6Q_PAD_SD3_DAT4__USDHC3_DAT4                  1265
-MX6Q_PAD_SD3_DAT4__UART2_RXD                    1266
-MX6Q_PAD_SD3_DAT4__PCIE_CTRL_MUX_27             1267
-MX6Q_PAD_SD3_DAT4__USBOH3_UH3_DFD_OUT_3         1268
-MX6Q_PAD_SD3_DAT4__USBOH3_UH2_DFD_OUT_3         1269
-MX6Q_PAD_SD3_DAT4__GPIO_7_1                     1270
-MX6Q_PAD_SD3_DAT4__MIPI_CORE_DPHY_IN_15         1271
-MX6Q_PAD_SD3_DAT4__ANATOP_TESTO_12              1272
-MX6Q_PAD_SD3_CMD__USDHC3_CMD                    1273
-MX6Q_PAD_SD3_CMD__UART2_CTS                     1274
-MX6Q_PAD_SD3_CMD__CAN1_TXCAN                    1275
-MX6Q_PAD_SD3_CMD__USBOH3_UH3_DFD_OUT_4          1276
-MX6Q_PAD_SD3_CMD__USBOH3_UH2_DFD_OUT_4          1277
-MX6Q_PAD_SD3_CMD__GPIO_7_2                      1278
-MX6Q_PAD_SD3_CMD__MIPI_CORE_DPHY_IN_16          1279
-MX6Q_PAD_SD3_CMD__ANATOP_TESTO_13               1280
-MX6Q_PAD_SD3_CLK__USDHC3_CLK                    1281
-MX6Q_PAD_SD3_CLK__UART2_RTS                     1282
-MX6Q_PAD_SD3_CLK__CAN1_RXCAN                    1283
-MX6Q_PAD_SD3_CLK__USBOH3_UH3_DFD_OUT_5          1284
-MX6Q_PAD_SD3_CLK__USBOH3_UH2_DFD_OUT_5          1285
-MX6Q_PAD_SD3_CLK__GPIO_7_3                      1286
-MX6Q_PAD_SD3_CLK__MIPI_CORE_DPHY_IN_17          1287
-MX6Q_PAD_SD3_CLK__ANATOP_TESTO_14               1288
-MX6Q_PAD_SD3_DAT0__USDHC3_DAT0                  1289
-MX6Q_PAD_SD3_DAT0__UART1_CTS                    1290
-MX6Q_PAD_SD3_DAT0__CAN2_TXCAN                   1291
-MX6Q_PAD_SD3_DAT0__USBOH3_UH3_DFD_OUT_6         1292
-MX6Q_PAD_SD3_DAT0__USBOH3_UH2_DFD_OUT_6         1293
-MX6Q_PAD_SD3_DAT0__GPIO_7_4                     1294
-MX6Q_PAD_SD3_DAT0__MIPI_CORE_DPHY_IN_18         1295
-MX6Q_PAD_SD3_DAT0__ANATOP_TESTO_15              1296
-MX6Q_PAD_SD3_DAT1__USDHC3_DAT1                  1297
-MX6Q_PAD_SD3_DAT1__UART1_RTS                    1298
-MX6Q_PAD_SD3_DAT1__CAN2_RXCAN                   1299
-MX6Q_PAD_SD3_DAT1__USBOH3_UH3_DFD_OUT_7         1300
-MX6Q_PAD_SD3_DAT1__USBOH3_UH2_DFD_OUT_7         1301
-MX6Q_PAD_SD3_DAT1__GPIO_7_5                     1302
-MX6Q_PAD_SD3_DAT1__MIPI_CORE_DPHY_IN_19         1303
-MX6Q_PAD_SD3_DAT1__ANATOP_TESTI_0               1304
-MX6Q_PAD_SD3_DAT2__USDHC3_DAT2                  1305
-MX6Q_PAD_SD3_DAT2__PCIE_CTRL_MUX_28             1306
-MX6Q_PAD_SD3_DAT2__USBOH3_UH3_DFD_OUT_8         1307
-MX6Q_PAD_SD3_DAT2__USBOH3_UH2_DFD_OUT_8         1308
-MX6Q_PAD_SD3_DAT2__GPIO_7_6                     1309
-MX6Q_PAD_SD3_DAT2__MIPI_CORE_DPHY_IN_20         1310
-MX6Q_PAD_SD3_DAT2__ANATOP_TESTI_1               1311
-MX6Q_PAD_SD3_DAT3__USDHC3_DAT3                  1312
-MX6Q_PAD_SD3_DAT3__UART3_CTS                    1313
-MX6Q_PAD_SD3_DAT3__PCIE_CTRL_MUX_29             1314
-MX6Q_PAD_SD3_DAT3__USBOH3_UH3_DFD_OUT_9         1315
-MX6Q_PAD_SD3_DAT3__USBOH3_UH2_DFD_OUT_9         1316
-MX6Q_PAD_SD3_DAT3__GPIO_7_7                     1317
-MX6Q_PAD_SD3_DAT3__MIPI_CORE_DPHY_IN_21         1318
-MX6Q_PAD_SD3_DAT3__ANATOP_TESTI_2               1319
-MX6Q_PAD_SD3_RST__USDHC3_RST                    1320
-MX6Q_PAD_SD3_RST__UART3_RTS                     1321
-MX6Q_PAD_SD3_RST__PCIE_CTRL_MUX_30              1322
-MX6Q_PAD_SD3_RST__USBOH3_UH3_DFD_OUT_10         1323
-MX6Q_PAD_SD3_RST__USBOH3_UH2_DFD_OUT_10         1324
-MX6Q_PAD_SD3_RST__GPIO_7_8                      1325
-MX6Q_PAD_SD3_RST__MIPI_CORE_DPHY_IN_22          1326
-MX6Q_PAD_SD3_RST__ANATOP_ANATOP_TESTI_3         1327
-MX6Q_PAD_NANDF_CLE__RAWNAND_CLE                 1328
-MX6Q_PAD_NANDF_CLE__IPU2_SISG_4                 1329
-MX6Q_PAD_NANDF_CLE__PCIE_CTRL_MUX_31            1330
-MX6Q_PAD_NANDF_CLE__USBOH3_UH3_DFD_OT11         1331
-MX6Q_PAD_NANDF_CLE__USBOH3_UH2_DFD_OT11         1332
-MX6Q_PAD_NANDF_CLE__GPIO_6_7                    1333
-MX6Q_PAD_NANDF_CLE__MIPI_CORE_DPHY_IN23         1334
-MX6Q_PAD_NANDF_CLE__TPSMP_HTRANS_0              1335
-MX6Q_PAD_NANDF_ALE__RAWNAND_ALE                 1336
-MX6Q_PAD_NANDF_ALE__USDHC4_RST                  1337
-MX6Q_PAD_NANDF_ALE__PCIE_CTRL_MUX_0             1338
-MX6Q_PAD_NANDF_ALE__USBOH3_UH3_DFD_OT12         1339
-MX6Q_PAD_NANDF_ALE__USBOH3_UH2_DFD_OT12         1340
-MX6Q_PAD_NANDF_ALE__GPIO_6_8                    1341
-MX6Q_PAD_NANDF_ALE__MIPI_CR_DPHY_IN_24          1342
-MX6Q_PAD_NANDF_ALE__TPSMP_HTRANS_1              1343
-MX6Q_PAD_NANDF_WP_B__RAWNAND_RESETN             1344
-MX6Q_PAD_NANDF_WP_B__IPU2_SISG_5                1345
-MX6Q_PAD_NANDF_WP_B__PCIE_CTRL__MUX_1           1346
-MX6Q_PAD_NANDF_WP_B__USBOH3_UH3_DFDOT13         1347
-MX6Q_PAD_NANDF_WP_B__USBOH3_UH2_DFDOT13         1348
-MX6Q_PAD_NANDF_WP_B__GPIO_6_9                   1349
-MX6Q_PAD_NANDF_WP_B__MIPI_CR_DPHY_OUT32         1350
-MX6Q_PAD_NANDF_WP_B__PL301_PER1_HSIZE_0         1351
-MX6Q_PAD_NANDF_RB0__RAWNAND_READY0              1352
-MX6Q_PAD_NANDF_RB0__IPU2_DI0_PIN1               1353
-MX6Q_PAD_NANDF_RB0__PCIE_CTRL_MUX_2             1354
-MX6Q_PAD_NANDF_RB0__USBOH3_UH3_DFD_OT14         1355
-MX6Q_PAD_NANDF_RB0__USBOH3_UH2_DFD_OT14         1356
-MX6Q_PAD_NANDF_RB0__GPIO_6_10                   1357
-MX6Q_PAD_NANDF_RB0__MIPI_CR_DPHY_OUT_33         1358
-MX6Q_PAD_NANDF_RB0__PL301_PER1_HSIZE_1          1359
-MX6Q_PAD_NANDF_CS0__RAWNAND_CE0N                1360
-MX6Q_PAD_NANDF_CS0__USBOH3_UH3_DFD_OT15         1361
-MX6Q_PAD_NANDF_CS0__USBOH3_UH2_DFD_OT15         1362
-MX6Q_PAD_NANDF_CS0__GPIO_6_11                   1363
-MX6Q_PAD_NANDF_CS0__PL301_PER1_HSIZE_2          1364
-MX6Q_PAD_NANDF_CS1__RAWNAND_CE1N                1365
-MX6Q_PAD_NANDF_CS1__USDHC4_VSELECT              1366
-MX6Q_PAD_NANDF_CS1__USDHC3_VSELECT              1367
-MX6Q_PAD_NANDF_CS1__PCIE_CTRL_MUX_3             1368
-MX6Q_PAD_NANDF_CS1__GPIO_6_14                   1369
-MX6Q_PAD_NANDF_CS1__PL301_PER1_HRDYOUT          1370
-MX6Q_PAD_NANDF_CS2__RAWNAND_CE2N                1371
-MX6Q_PAD_NANDF_CS2__IPU1_SISG_0                 1372
-MX6Q_PAD_NANDF_CS2__ESAI1_TX0                   1373
-MX6Q_PAD_NANDF_CS2__WEIM_WEIM_CRE               1374
-MX6Q_PAD_NANDF_CS2__CCM_CLKO2                   1375
-MX6Q_PAD_NANDF_CS2__GPIO_6_15                   1376
-MX6Q_PAD_NANDF_CS2__IPU2_SISG_0                 1377
-MX6Q_PAD_NANDF_CS3__RAWNAND_CE3N                1378
-MX6Q_PAD_NANDF_CS3__IPU1_SISG_1                 1379
-MX6Q_PAD_NANDF_CS3__ESAI1_TX1                   1380
-MX6Q_PAD_NANDF_CS3__WEIM_WEIM_A_26              1381
-MX6Q_PAD_NANDF_CS3__PCIE_CTRL_MUX_4             1382
-MX6Q_PAD_NANDF_CS3__GPIO_6_16                   1383
-MX6Q_PAD_NANDF_CS3__IPU2_SISG_1                 1384
-MX6Q_PAD_NANDF_CS3__TPSMP_CLK                   1385
-MX6Q_PAD_SD4_CMD__USDHC4_CMD                    1386
-MX6Q_PAD_SD4_CMD__RAWNAND_RDN                   1387
-MX6Q_PAD_SD4_CMD__UART3_TXD                     1388
-MX6Q_PAD_SD4_CMD__PCIE_CTRL_MUX_5               1389
-MX6Q_PAD_SD4_CMD__GPIO_7_9                      1390
-MX6Q_PAD_SD4_CMD__TPSMP_HDATA_DIR               1391
-MX6Q_PAD_SD4_CLK__USDHC4_CLK                    1392
-MX6Q_PAD_SD4_CLK__RAWNAND_WRN                   1393
-MX6Q_PAD_SD4_CLK__UART3_RXD                     1394
-MX6Q_PAD_SD4_CLK__PCIE_CTRL_MUX_6               1395
-MX6Q_PAD_SD4_CLK__GPIO_7_10                     1396
-MX6Q_PAD_NANDF_D0__RAWNAND_D0                   1397
-MX6Q_PAD_NANDF_D0__USDHC1_DAT4                  1398
-MX6Q_PAD_NANDF_D0__GPU3D_GPU_DBG_OUT_0          1399
-MX6Q_PAD_NANDF_D0__USBOH3_UH2_DFD_OUT16         1400
-MX6Q_PAD_NANDF_D0__USBOH3_UH3_DFD_OUT16         1401
-MX6Q_PAD_NANDF_D0__GPIO_2_0                     1402
-MX6Q_PAD_NANDF_D0__IPU1_IPU_DIAG_BUS_0          1403
-MX6Q_PAD_NANDF_D0__IPU2_IPU_DIAG_BUS_0          1404
-MX6Q_PAD_NANDF_D1__RAWNAND_D1                   1405
-MX6Q_PAD_NANDF_D1__USDHC1_DAT5                  1406
-MX6Q_PAD_NANDF_D1__GPU3D_GPU_DEBUG_OUT1         1407
-MX6Q_PAD_NANDF_D1__USBOH3_UH2_DFD_OUT17         1408
-MX6Q_PAD_NANDF_D1__USBOH3_UH3_DFD_OUT17         1409
-MX6Q_PAD_NANDF_D1__GPIO_2_1                     1410
-MX6Q_PAD_NANDF_D1__IPU1_IPU_DIAG_BUS_1          1411
-MX6Q_PAD_NANDF_D1__IPU2_IPU_DIAG_BUS_1          1412
-MX6Q_PAD_NANDF_D2__RAWNAND_D2                   1413
-MX6Q_PAD_NANDF_D2__USDHC1_DAT6                  1414
-MX6Q_PAD_NANDF_D2__GPU3D_GPU_DBG_OUT_2          1415
-MX6Q_PAD_NANDF_D2__USBOH3_UH2_DFD_OUT18         1416
-MX6Q_PAD_NANDF_D2__USBOH3_UH3_DFD_OUT18         1417
-MX6Q_PAD_NANDF_D2__GPIO_2_2                     1418
-MX6Q_PAD_NANDF_D2__IPU1_IPU_DIAG_BUS_2          1419
-MX6Q_PAD_NANDF_D2__IPU2_IPU_DIAG_BUS_2          1420
-MX6Q_PAD_NANDF_D3__RAWNAND_D3                   1421
-MX6Q_PAD_NANDF_D3__USDHC1_DAT7                  1422
-MX6Q_PAD_NANDF_D3__GPU3D_GPU_DBG_OUT_3          1423
-MX6Q_PAD_NANDF_D3__USBOH3_UH2_DFD_OUT19         1424
-MX6Q_PAD_NANDF_D3__USBOH3_UH3_DFD_OUT19         1425
-MX6Q_PAD_NANDF_D3__GPIO_2_3                     1426
-MX6Q_PAD_NANDF_D3__IPU1_IPU_DIAG_BUS_3          1427
-MX6Q_PAD_NANDF_D3__IPU2_IPU_DIAG_BUS_3          1428
-MX6Q_PAD_NANDF_D4__RAWNAND_D4                   1429
-MX6Q_PAD_NANDF_D4__USDHC2_DAT4                  1430
-MX6Q_PAD_NANDF_D4__GPU3D_GPU_DBG_OUT_4          1431
-MX6Q_PAD_NANDF_D4__USBOH3_UH2_DFD_OUT20         1432
-MX6Q_PAD_NANDF_D4__USBOH3_UH3_DFD_OUT20         1433
-MX6Q_PAD_NANDF_D4__GPIO_2_4                     1434
-MX6Q_PAD_NANDF_D4__IPU1_IPU_DIAG_BUS_4          1435
-MX6Q_PAD_NANDF_D4__IPU2_IPU_DIAG_BUS_4          1436
-MX6Q_PAD_NANDF_D5__RAWNAND_D5                   1437
-MX6Q_PAD_NANDF_D5__USDHC2_DAT5                  1438
-MX6Q_PAD_NANDF_D5__GPU3D_GPU_DBG_OUT_5          1439
-MX6Q_PAD_NANDF_D5__USBOH3_UH2_DFD_OUT21         1440
-MX6Q_PAD_NANDF_D5__USBOH3_UH3_DFD_OUT21         1441
-MX6Q_PAD_NANDF_D5__GPIO_2_5                     1442
-MX6Q_PAD_NANDF_D5__IPU1_IPU_DIAG_BUS_5          1443
-MX6Q_PAD_NANDF_D5__IPU2_IPU_DIAG_BUS_5          1444
-MX6Q_PAD_NANDF_D6__RAWNAND_D6                   1445
-MX6Q_PAD_NANDF_D6__USDHC2_DAT6                  1446
-MX6Q_PAD_NANDF_D6__GPU3D_GPU_DBG_OUT_6          1447
-MX6Q_PAD_NANDF_D6__USBOH3_UH2_DFD_OUT22         1448
-MX6Q_PAD_NANDF_D6__USBOH3_UH3_DFD_OUT22         1449
-MX6Q_PAD_NANDF_D6__GPIO_2_6                     1450
-MX6Q_PAD_NANDF_D6__IPU1_IPU_DIAG_BUS_6          1451
-MX6Q_PAD_NANDF_D6__IPU2_IPU_DIAG_BUS_6          1452
-MX6Q_PAD_NANDF_D7__RAWNAND_D7                   1453
-MX6Q_PAD_NANDF_D7__USDHC2_DAT7                  1454
-MX6Q_PAD_NANDF_D7__GPU3D_GPU_DBG_OUT_7          1455
-MX6Q_PAD_NANDF_D7__USBOH3_UH2_DFD_OUT23         1456
-MX6Q_PAD_NANDF_D7__USBOH3_UH3_DFD_OUT23         1457
-MX6Q_PAD_NANDF_D7__GPIO_2_7                     1458
-MX6Q_PAD_NANDF_D7__IPU1_IPU_DIAG_BUS_7          1459
-MX6Q_PAD_NANDF_D7__IPU2_IPU_DIAG_BUS_7          1460
-MX6Q_PAD_SD4_DAT0__RAWNAND_D8                   1461
-MX6Q_PAD_SD4_DAT0__USDHC4_DAT0                  1462
-MX6Q_PAD_SD4_DAT0__RAWNAND_DQS                  1463
-MX6Q_PAD_SD4_DAT0__USBOH3_UH2_DFD_OUT24         1464
-MX6Q_PAD_SD4_DAT0__USBOH3_UH3_DFD_OUT24         1465
-MX6Q_PAD_SD4_DAT0__GPIO_2_8                     1466
-MX6Q_PAD_SD4_DAT0__IPU1_IPU_DIAG_BUS_8          1467
-MX6Q_PAD_SD4_DAT0__IPU2_IPU_DIAG_BUS_8          1468
-MX6Q_PAD_SD4_DAT1__RAWNAND_D9                   1469
-MX6Q_PAD_SD4_DAT1__USDHC4_DAT1                  1470
-MX6Q_PAD_SD4_DAT1__PWM3_PWMO                    1471
-MX6Q_PAD_SD4_DAT1__USBOH3_UH2_DFD_OUT25         1472
-MX6Q_PAD_SD4_DAT1__USBOH3_UH3_DFD_OUT25         1473
-MX6Q_PAD_SD4_DAT1__GPIO_2_9                     1474
-MX6Q_PAD_SD4_DAT1__IPU1_IPU_DIAG_BUS_9          1475
-MX6Q_PAD_SD4_DAT1__IPU2_IPU_DIAG_BUS_9          1476
-MX6Q_PAD_SD4_DAT2__RAWNAND_D10                  1477
-MX6Q_PAD_SD4_DAT2__USDHC4_DAT2                  1478
-MX6Q_PAD_SD4_DAT2__PWM4_PWMO                    1479
-MX6Q_PAD_SD4_DAT2__USBOH3_UH2_DFD_OUT26         1480
-MX6Q_PAD_SD4_DAT2__USBOH3_UH3_DFD_OUT26         1481
-MX6Q_PAD_SD4_DAT2__GPIO_2_10                    1482
-MX6Q_PAD_SD4_DAT2__IPU1_IPU_DIAG_BUS_10         1483
-MX6Q_PAD_SD4_DAT2__IPU2_IPU_DIAG_BUS_10         1484
-MX6Q_PAD_SD4_DAT3__RAWNAND_D11                  1485
-MX6Q_PAD_SD4_DAT3__USDHC4_DAT3                  1486
-MX6Q_PAD_SD4_DAT3__USBOH3_UH2_DFD_OUT27         1487
-MX6Q_PAD_SD4_DAT3__USBOH3_UH3_DFD_OUT27         1488
-MX6Q_PAD_SD4_DAT3__GPIO_2_11                    1489
-MX6Q_PAD_SD4_DAT3__IPU1_IPU_DIAG_BUS_11         1490
-MX6Q_PAD_SD4_DAT3__IPU2_IPU_DIAG_BUS_11         1491
-MX6Q_PAD_SD4_DAT4__RAWNAND_D12                  1492
-MX6Q_PAD_SD4_DAT4__USDHC4_DAT4                  1493
-MX6Q_PAD_SD4_DAT4__UART2_RXD                    1494
-MX6Q_PAD_SD4_DAT4__USBOH3_UH2_DFD_OUT28         1495
-MX6Q_PAD_SD4_DAT4__USBOH3_UH3_DFD_OUT28         1496
-MX6Q_PAD_SD4_DAT4__GPIO_2_12                    1497
-MX6Q_PAD_SD4_DAT4__IPU1_IPU_DIAG_BUS_12         1498
-MX6Q_PAD_SD4_DAT4__IPU2_IPU_DIAG_BUS_12         1499
-MX6Q_PAD_SD4_DAT5__RAWNAND_D13                  1500
-MX6Q_PAD_SD4_DAT5__USDHC4_DAT5                  1501
-MX6Q_PAD_SD4_DAT5__UART2_RTS                    1502
-MX6Q_PAD_SD4_DAT5__USBOH3_UH2_DFD_OUT29         1503
-MX6Q_PAD_SD4_DAT5__USBOH3_UH3_DFD_OUT29         1504
-MX6Q_PAD_SD4_DAT5__GPIO_2_13                    1505
-MX6Q_PAD_SD4_DAT5__IPU1_IPU_DIAG_BUS_13         1506
-MX6Q_PAD_SD4_DAT5__IPU2_IPU_DIAG_BUS_13         1507
-MX6Q_PAD_SD4_DAT6__RAWNAND_D14                  1508
-MX6Q_PAD_SD4_DAT6__USDHC4_DAT6                  1509
-MX6Q_PAD_SD4_DAT6__UART2_CTS                    1510
-MX6Q_PAD_SD4_DAT6__USBOH3_UH2_DFD_OUT30         1511
-MX6Q_PAD_SD4_DAT6__USBOH3_UH3_DFD_OUT30         1512
-MX6Q_PAD_SD4_DAT6__GPIO_2_14                    1513
-MX6Q_PAD_SD4_DAT6__IPU1_IPU_DIAG_BUS_14         1514
-MX6Q_PAD_SD4_DAT6__IPU2_IPU_DIAG_BUS_14         1515
-MX6Q_PAD_SD4_DAT7__RAWNAND_D15                  1516
-MX6Q_PAD_SD4_DAT7__USDHC4_DAT7                  1517
-MX6Q_PAD_SD4_DAT7__UART2_TXD                    1518
-MX6Q_PAD_SD4_DAT7__USBOH3_UH2_DFD_OUT31         1519
-MX6Q_PAD_SD4_DAT7__USBOH3_UH3_DFD_OUT31         1520
-MX6Q_PAD_SD4_DAT7__GPIO_2_15                    1521
-MX6Q_PAD_SD4_DAT7__IPU1_IPU_DIAG_BUS_15         1522
-MX6Q_PAD_SD4_DAT7__IPU2_IPU_DIAG_BUS_15         1523
-MX6Q_PAD_SD1_DAT1__USDHC1_DAT1                  1524
-MX6Q_PAD_SD1_DAT1__ECSPI5_SS0                   1525
-MX6Q_PAD_SD1_DAT1__PWM3_PWMO                    1526
-MX6Q_PAD_SD1_DAT1__GPT_CAPIN2                   1527
-MX6Q_PAD_SD1_DAT1__PCIE_CTRL_MUX_7              1528
-MX6Q_PAD_SD1_DAT1__GPIO_1_17                    1529
-MX6Q_PAD_SD1_DAT1__HDMI_TX_OPHYDTB_0            1530
-MX6Q_PAD_SD1_DAT1__ANATOP_TESTO_8               1531
-MX6Q_PAD_SD1_DAT0__USDHC1_DAT0                  1532
-MX6Q_PAD_SD1_DAT0__ECSPI5_MISO                  1533
-MX6Q_PAD_SD1_DAT0__CAAM_WRAP_RNG_OSCOBS         1534
-MX6Q_PAD_SD1_DAT0__GPT_CAPIN1                   1535
-MX6Q_PAD_SD1_DAT0__PCIE_CTRL_MUX_8              1536
-MX6Q_PAD_SD1_DAT0__GPIO_1_16                    1537
-MX6Q_PAD_SD1_DAT0__HDMI_TX_OPHYDTB_1            1538
-MX6Q_PAD_SD1_DAT0__ANATOP_TESTO_7               1539
-MX6Q_PAD_SD1_DAT3__USDHC1_DAT3                  1540
-MX6Q_PAD_SD1_DAT3__ECSPI5_SS2                   1541
-MX6Q_PAD_SD1_DAT3__GPT_CMPOUT3                  1542
-MX6Q_PAD_SD1_DAT3__PWM1_PWMO                    1543
-MX6Q_PAD_SD1_DAT3__WDOG2_WDOG_B                 1544
-MX6Q_PAD_SD1_DAT3__GPIO_1_21                    1545
-MX6Q_PAD_SD1_DAT3__WDOG2_WDOG_RST_B_DEB         1546
-MX6Q_PAD_SD1_DAT3__ANATOP_TESTO_6               1547
-MX6Q_PAD_SD1_CMD__USDHC1_CMD                    1548
-MX6Q_PAD_SD1_CMD__ECSPI5_MOSI                   1549
-MX6Q_PAD_SD1_CMD__PWM4_PWMO                     1550
-MX6Q_PAD_SD1_CMD__GPT_CMPOUT1                   1551
-MX6Q_PAD_SD1_CMD__GPIO_1_18                     1552
-MX6Q_PAD_SD1_CMD__ANATOP_TESTO_5                1553
-MX6Q_PAD_SD1_DAT2__USDHC1_DAT2                  1554
-MX6Q_PAD_SD1_DAT2__ECSPI5_SS1                   1555
-MX6Q_PAD_SD1_DAT2__GPT_CMPOUT2                  1556
-MX6Q_PAD_SD1_DAT2__PWM2_PWMO                    1557
-MX6Q_PAD_SD1_DAT2__WDOG1_WDOG_B                 1558
-MX6Q_PAD_SD1_DAT2__GPIO_1_19                    1559
-MX6Q_PAD_SD1_DAT2__WDOG1_WDOG_RST_B_DEB         1560
-MX6Q_PAD_SD1_DAT2__ANATOP_TESTO_4               1561
-MX6Q_PAD_SD1_CLK__USDHC1_CLK                    1562
-MX6Q_PAD_SD1_CLK__ECSPI5_SCLK                   1563
-MX6Q_PAD_SD1_CLK__OSC32K_32K_OUT                1564
-MX6Q_PAD_SD1_CLK__GPT_CLKIN                     1565
-MX6Q_PAD_SD1_CLK__GPIO_1_20                     1566
-MX6Q_PAD_SD1_CLK__PHY_DTB_0                     1567
-MX6Q_PAD_SD1_CLK__SATA_PHY_DTB_0                1568
-MX6Q_PAD_SD2_CLK__USDHC2_CLK                    1569
-MX6Q_PAD_SD2_CLK__ECSPI5_SCLK                   1570
-MX6Q_PAD_SD2_CLK__KPP_COL_5                     1571
-MX6Q_PAD_SD2_CLK__AUDMUX_AUD4_RXFS              1572
-MX6Q_PAD_SD2_CLK__PCIE_CTRL_MUX_9               1573
-MX6Q_PAD_SD2_CLK__GPIO_1_10                     1574
-MX6Q_PAD_SD2_CLK__PHY_DTB_1                     1575
-MX6Q_PAD_SD2_CLK__SATA_PHY_DTB_1                1576
-MX6Q_PAD_SD2_CMD__USDHC2_CMD                    1577
-MX6Q_PAD_SD2_CMD__ECSPI5_MOSI                   1578
-MX6Q_PAD_SD2_CMD__KPP_ROW_5                     1579
-MX6Q_PAD_SD2_CMD__AUDMUX_AUD4_RXC               1580
-MX6Q_PAD_SD2_CMD__PCIE_CTRL_MUX_10              1581
-MX6Q_PAD_SD2_CMD__GPIO_1_11                     1582
-MX6Q_PAD_SD2_DAT3__USDHC2_DAT3                  1583
-MX6Q_PAD_SD2_DAT3__ECSPI5_SS3                   1584
-MX6Q_PAD_SD2_DAT3__KPP_COL_6                    1585
-MX6Q_PAD_SD2_DAT3__AUDMUX_AUD4_TXC              1586
-MX6Q_PAD_SD2_DAT3__PCIE_CTRL_MUX_11             1587
-MX6Q_PAD_SD2_DAT3__GPIO_1_12                    1588
-MX6Q_PAD_SD2_DAT3__SJC_DONE                     1589
-MX6Q_PAD_SD2_DAT3__ANATOP_TESTO_3               1590
-MX6Q_PAD_ENET_RX_ER__ANATOP_USBOTG_ID           1591
-MX6Q_PAD_GPIO_1__ANATOP_USBOTG_ID               1592
+Refer to imx6q-pinfunc.h in device tree source folder for all available
+imx6q PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
new file mode 100644
index 000000000000..e5f6d1f065a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
@@ -0,0 +1,39 @@
+* Freescale IMX6 SoloLite IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx6sl-iomuxc"
+- fsl,pins: two integers array, represents a group of pins mux and config
+  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
+  pin working on a specific function, CONFIG is the pad setting value like
+  pull-up for this pin. Please refer to imx6sl datasheet for the valid pad
+  config settings.
+
+CONFIG bits definition:
+PAD_CTL_LVE                     (1 << 22)
+PAD_CTL_HYS                     (1 << 16)
+PAD_CTL_PUS_100K_DOWN           (0 << 14)
+PAD_CTL_PUS_47K_UP              (1 << 14)
+PAD_CTL_PUS_100K_UP             (2 << 14)
+PAD_CTL_PUS_22K_UP              (3 << 14)
+PAD_CTL_PUE                     (1 << 13)
+PAD_CTL_PKE                     (1 << 12)
+PAD_CTL_ODE                     (1 << 11)
+PAD_CTL_SPEED_LOW               (1 << 6)
+PAD_CTL_SPEED_MED               (2 << 6)
+PAD_CTL_SPEED_HIGH              (3 << 6)
+PAD_CTL_DSE_DISABLE             (0 << 3)
+PAD_CTL_DSE_240ohm              (1 << 3)
+PAD_CTL_DSE_120ohm              (2 << 3)
+PAD_CTL_DSE_80ohm               (3 << 3)
+PAD_CTL_DSE_60ohm               (4 << 3)
+PAD_CTL_DSE_48ohm               (5 << 3)
+PAD_CTL_DSE_40ohm               (6 << 3)
+PAD_CTL_DSE_34ohm               (7 << 3)
+PAD_CTL_SRE_FAST                (1 << 0)
+PAD_CTL_SRE_SLOW                (0 << 0)
+
+Refer to imx6sl-pinfunc.h in device tree source folder for all available
+imx6sl PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
index f7e8e8f4d9a3..3077370c89af 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
@@ -70,6 +70,10 @@ Optional subnode-properties:
     0: Disable the internal pull-up
     1: Enable the internal pull-up
 
+Note that when enabling the pull-up, the internal pad keeper gets disabled.
+Also, some pins doesn't have a pull up, in that case, setting the fsl,pull-up
+will only disable the internal pad keeper.
+
 Examples:
 
 pinctrl@80018000 {
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 2c81e45f1374..08f0c3d01575 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -1,7 +1,9 @@
 One-register-per-pin type device tree based pinctrl driver
 
 Required properties:
-- compatible : "pinctrl-single"
+- compatible : "pinctrl-single" or "pinconf-single".
+  "pinctrl-single" means that pinconf isn't supported.
+  "pinconf-single" means that generic pinconf is supported.
 
 - reg : offset and length of the register set for the mux registers
 
@@ -14,9 +16,61 @@ Optional properties:
 - pinctrl-single,function-off : function off mode for disabled state if
   available and same for all registers; if not specified, disabling of
   pin functions is ignored
+
 - pinctrl-single,bit-per-mux : boolean to indicate that one register controls
   more than one pin
 
+- pinctrl-single,drive-strength : array of value that are used to configure
+  drive strength in the pinmux register. They're value of drive strength
+  current and drive strength mask.
+
+                /* drive strength current, mask */
+                pinctrl-single,power-source = <0x30 0xf0>;
+
+- pinctrl-single,bias-pullup : array of value that are used to configure the
+  input bias pullup in the pinmux register.
+
+                /* input, enabled pullup bits, disabled pullup bits, mask */
+                pinctrl-single,bias-pullup = <0 1 0 1>;
+
+- pinctrl-single,bias-pulldown : array of value that are used to configure the
+  input bias pulldown in the pinmux register.
+
+                /* input, enabled pulldown bits, disabled pulldown bits, mask */
+                pinctrl-single,bias-pulldown = <2 2 0 2>;
+
+  * Two bits to control input bias pullup and pulldown: User should use
+    pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. One bit means
+    pullup, and the other one bit means pulldown.
+  * Three bits to control input bias enable, pullup and pulldown. User should
+    use pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. Input bias
+    enable bit should be included in pullup or pulldown bits.
+  * Although driver could set PIN_CONFIG_BIAS_DISABLE, there's no property as
+    pinctrl-single,bias-disable. Because pinctrl single driver could implement
+    it by calling pulldown, pullup disabled.
+
+- pinctrl-single,input-schmitt : array of value that are used to configure
+  input schmitt in the pinmux register. In some silicons, there're two input
+  schmitt value (rising-edge & falling-edge) in the pinmux register.
+
+                /* input schmitt value, mask */
+                pinctrl-single,input-schmitt = <0x30 0x70>;
+
+- pinctrl-single,input-schmitt-enable : array of value that are used to
+  configure input schmitt enable or disable in the pinmux register.
+
+                /* input, enable bits, disable bits, mask */
+                pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>;
+
+- pinctrl-single,gpio-range : list of value that are used to configure a GPIO
+  range. They're value of subnode phandle, pin base in pinctrl device, pin
+  number in this range, GPIO function value of this GPIO range.
+  The number of parameters is depend on #pinctrl-single,gpio-range-cells
+  property.
+
+                /* pin base, nr pins & gpio function */
+                pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
+
 This driver assumes that there is only one register for each pin (unless the
 pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
 specified in the pinctrl-bindings.txt document in this directory.
@@ -42,6 +96,20 @@ Where 0xdc is the offset from the pinctrl register base address for the
 device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
 be used when applying this change to the register.
 
+
+Optional sub-node: In case some pins could be configured as GPIO in the pinmux
+register, those pins could be defined as a GPIO range. This sub-node is required
+by pinctrl-single,gpio-range property.
+
+Required properties in sub-node:
+- #pinctrl-single,gpio-range-cells : the number of parameters after phandle in
+  pinctrl-single,gpio-range property.
+
+        range: gpio-range {
+                #pinctrl-single,gpio-range-cells = <3>;
+        };
+
+
 Example:
 
 /* SoC common file */
@@ -58,7 +126,7 @@ pmx_core: pinmux@4a100040 {
 
 /* second controller instance for pins in wkup domain */
 pmx_wkup: pinmux@4a31e040 {
-        compatible = "pinctrl-single;
+        compatible = "pinctrl-single";
         reg = <0x4a31e040 0x0038>;
         #address-cells = <1>;
         #size-cells = <0>;
@@ -76,6 +144,29 @@ control_devconf0: pinmux@48002274 {
         pinctrl-single,function-mask = <0x5F>;
 };
 
+/* third controller instance for pins in gpio domain */
+pmx_gpio: pinmux@d401e000 {
+        compatible = "pinconf-single";
+        reg = <0xd401e000 0x0330>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+
+        pinctrl-single,register-width = <32>;
+        pinctrl-single,function-mask = <7>;
+
+        /* sparse GPIO range could be supported */
+        pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1
+                                &range 12 1 0 &range 13 29 1
+                                &range 43 1 0 &range 44 49 1
+                                &range 94 1 1 &range 96 2 1>;
+
+        range: gpio-range {
+                #pinctrl-single,gpio-range-cells = <3>;
+        };
+};
+
+
 /* board specific .dts file */
 
 &pmx_core {
@@ -96,6 +187,15 @@ control_devconf0: pinmux@48002274 {
                 >;
         };
 
+        uart0_pins: pinmux_uart0_pins {
+                pinctrl-single,pins = <
+                        0x208 0         /* UART0_RXD (IOCFG138) */
+                        0x20c 0         /* UART0_TXD (IOCFG139) */
+                >;
+                pinctrl-single,bias-pulldown = <0 2 2>;
+                pinctrl-single,bias-pullup = <0 1 1>;
+        };
+
         /* map uart2 pins */
         uart2_pins: pinmux_uart2_pins {
                 pinctrl-single,pins = <
@@ -122,6 +222,11 @@ control_devconf0: pinmux@48002274 {
 
 };
 
+&uart1 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&uart0_pins>;
+};
+
 &uart2 {
        pinctrl-names = "default";
        pinctrl-0 = <&uart2_pins>;
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
new file mode 100644
index 000000000000..b3aa90f0ce44
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
@@ -0,0 +1,57 @@
+VIA VT8500 and Wondermedia WM8xxx-series pinmux/gpio controller
+
+These SoCs contain a combined Pinmux/GPIO module. Each pin may operate as
+either a GPIO in, GPIO out or as an alternate function (I2C, SPI etc).
+
+Required properties:
+- compatible: "via,vt8500-pinctrl", "wm,wm8505-pinctrl", "wm,wm8650-pinctrl",
+        "wm8750-pinctrl" or "wm,wm8850-pinctrl"
+- reg: Should contain the physical address of the module's registers.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+  second cell is used to specify optional parameters.
+        bit 0 - active low
+
+Please refer to ../gpio/gpio.txt for a general description of GPIO 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".
+
+Each pin configuration node lists the pin(s) to which it applies, and one or
+more of the mux functions to select on those pin(s), and pull-up/down
+configuration. Each subnode only affects those parameters that are explicitly
+listed. In other words, a subnode that lists only a mux function implies no
+information about any pull configuration. Similarly, a subnode that lists only
+a pull parameter implies no information about the mux function.
+
+Required subnode-properties:
+- wm,pins: An array of cells. Each cell contains the ID of a pin.
+
+Optional subnode-properties:
+- wm,function: Integer, containing the function to mux to the pin(s):
+  0: GPIO in
+  1: GPIO out
+  2: alternate
+
+- wm,pull: Integer, representing the pull-down/up to apply to the pin(s):
+  0: none
+  1: down
+  2: up
+
+Each of wm,function and wm,pull may contain either a single value which
+will be applied to all pins in wm,pins, or one value for each entry in
+wm,pins.
+
+Example:
+
+        pinctrl: pinctrl {
+                compatible = "wm,wm8505-pinctrl";
+                reg = <0xD8110000 0x10000>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+                gpio-controller;
+                #gpio-cells = <2>;
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 4598a47aa0cd..c70fca146e91 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -7,6 +7,7 @@ on-chip controllers onto these pads.
 
 Required Properties:
 - compatible: should be one of the following.
+  - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
   - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
   - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
   - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
@@ -105,6 +106,8 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a
 
    - compatible: identifies the type of the external wakeup interrupt controller
      The possible values are:
+     - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
+       found on Samsung S3C64xx SoCs,
      - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
        found on Samsung Exynos4210 SoC.
    - interrupt-parent: phandle of the interrupt parent to which the external
diff --git a/Documentation/devicetree/bindings/power_supply/power_supply.txt b/Documentation/devicetree/bindings/power_supply/power_supply.txt
new file mode 100644
index 000000000000..8391bfa0edac
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/power_supply.txt
@@ -0,0 +1,23 @@
+Power Supply Core Support
+
+Optional Properties:
+ - power-supplies : This property is added to a supply in order to list the
+   devices which supply it power, referenced by their phandles.
+
+Example:
+
+        usb-charger: power@e {
+                compatible = "some,usb-charger";
+                ...
+        };
+
+        ac-charger: power@c {
+                compatible = "some,ac-charger";
+                ...
+        };
+
+        battery@b {
+                compatible = "some,battery";
+                ...
+                power-supplies = <&usb-charger>, <&ac-charger>;
+        };
diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
index 9a599d27bd75..0347d8350d94 100644
--- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
+++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
@@ -2,7 +2,7 @@
 
 QNAP NAS devices have a microcontroller controlling the main power
 supply. This microcontroller is connected to UART1 of the Kirkwood and
-Orion5x SoCs. Sending the charactor 'A', at 19200 baud, tells the
+Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the
 microcontroller to turn the power off. This driver adds a handler to
 pm_power_off which is called to turn the power off.
 
diff --git a/Documentation/devicetree/bindings/power_supply/tps65090.txt b/Documentation/devicetree/bindings/power_supply/tps65090.txt
new file mode 100644
index 000000000000..8e5e0d3910df
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/tps65090.txt
@@ -0,0 +1,17 @@
+TPS65090 Frontend PMU with Switchmode Charger
+
+Required Properties:
+-compatible: "ti,tps65090-charger"
+
+Optional Properties:
+-ti,enable-low-current-chrg: Enables charging when a low current is detected
+ while the default logic is to stop charging.
+
+This node is a subnode of the tps65090 PMIC.
+
+Example:
+
+        tps65090-charger {
+                compatible = "ti,tps65090-charger";
+                ti,enable-low-current-chrg;
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
new file mode 100644
index 000000000000..922c30ad90d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
@@ -0,0 +1,22 @@
+===================================================================
+Power Architecture CPU Binding
+Copyright 2013 Freescale Semiconductor Inc.
+
+Power Architecture CPUs in Freescale SOCs are represented in device trees as
+per the definition in ePAPR.
+
+In addition to the ePAPR definitions, the properties defined below may be
+present on CPU nodes.
+
+PROPERTIES
+
+   - fsl,eref-*
+        Usage: optional
+        Value type: <empty>
+        Definition: The EREF (EREF: A Programmer.s Reference Manual for
+        Freescale Power Architecture) defines the architecture for Freescale
+        Power CPUs.  The EREF defines some architecture categories not defined
+        by the Power ISA.  For these EREF-specific categories, the existence of
+        a property named fsl,eref-[CAT], where [CAT] is the abbreviated category
+        name with all uppercase letters converted to lowercase, indicates that
+        the category is supported by the implementation.
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
new file mode 100644
index 000000000000..ac67c687a327
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -0,0 +1,43 @@
+* Samsung PWM timers
+
+Samsung SoCs contain PWM timer blocks which can be used for system clock source
+and clock event timers, as well as to drive SoC outputs with PWM signal. Each
+PWM timer block provides 5 PWM channels (not all of them can drive physical
+outputs - see SoC and board manual).
+
+Be aware that the clocksource driver supports only uniprocessor systems.
+
+Required properties:
+- compatible : should be one of following:
+    samsung,s3c2410-pwm - for 16-bit timers present on S3C24xx SoCs
+    samsung,s3c6400-pwm - for 32-bit timers present on S3C64xx SoCs
+    samsung,s5p6440-pwm - for 32-bit timers present on S5P64x0 SoCs
+    samsung,s5pc100-pwm - for 32-bit timers present on S5PC100, S5PV210,
+                          Exynos4210 rev0 SoCs
+    samsung,exynos4210-pwm - for 32-bit timers present on Exynos4210,
+                          Exynos4x12 and Exynos5250 SoCs
+- reg: base address and size of register area
+- interrupts: list of timer interrupts (one interrupt per timer, starting at
+  timer 0)
+- #pwm-cells: number of cells used for PWM specifier - must be 3
+   the specifier format is as follows:
+     - phandle to PWM controller node
+     - index of PWM channel (from 0 to 4)
+     - PWM signal period in nanoseconds
+     - bitmask of optional PWM flags:
+        0x1 - invert PWM signal
+
+Optional properties:
+- samsung,pwm-outputs: list of PWM channels used as PWM outputs on particular
+    platform - an array of up to 5 elements being indices of PWM channels
+    (from 0 to 4), the order does not matter.
+
+Example:
+        pwm@7f006000 {
+                compatible = "samsung,s3c6400-pwm";
+                reg = <0x7f006000 0x1000>;
+                interrupt-parent = <&vic0>;
+                interrupts = <23>, <24>, <25>, <27>, <28>;
+                samsung,pwm-outputs = <0>, <1>;
+                #pwm-cells = <3>;
+        }
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
index 131e8c11d26f..681afad73778 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -1,7 +1,9 @@
 TI SOC ECAP based APWM controller
 
 Required properties:
-- compatible: Must be "ti,am33xx-ecap"
+- compatible: Must be "ti,<soc>-ecap".
+  for am33xx - compatible = "ti,am33xx-ecap";
+  for da850  - compatible = "ti,da850-ecap", "ti,am33xx-ecap";
 - #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
   First cell specifies the per-chip index of the PWM to use, the second
   cell is the period in nanoseconds and bit 0 in the third cell is used to
@@ -15,9 +17,15 @@ Optional properties:
 
 Example:
 
-ecap0: ecap@0 {
+ecap0: ecap@0 { /* ECAP on am33xx */
         compatible = "ti,am33xx-ecap";
         #pwm-cells = <3>;
         reg = <0x48300100 0x80>;
         ti,hwmods = "ecap0";
 };
+
+ecap0: ecap@0 { /* ECAP on da850 */
+        compatible = "ti,da850-ecap", "ti,am33xx-ecap";
+        #pwm-cells = <3>;
+        reg = <0x306000 0x80>;
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
index 4fc7079d822e..337c6fc65d3f 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -1,7 +1,9 @@
 TI SOC EHRPWM based PWM controller
 
 Required properties:
-- compatible : Must be "ti,am33xx-ehrpwm"
+- compatible: Must be "ti,<soc>-ehrpwm".
+  for am33xx - compatible = "ti,am33xx-ehrpwm";
+  for da850  - compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
 - #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
   First cell specifies the per-chip index of the PWM to use, the second
   cell is the period in nanoseconds and bit 0 in the third cell is used to
@@ -15,9 +17,15 @@ Optional properties:
 
 Example:
 
-ehrpwm0: ehrpwm@0 {
+ehrpwm0: ehrpwm@0 { /* EHRPWM on am33xx */
         compatible = "ti,am33xx-ehrpwm";
         #pwm-cells = <3>;
         reg = <0x48300200 0x100>;
         ti,hwmods = "ehrpwm0";
 };
+
+ehrpwm0: ehrpwm@0 { /* EHRPWM on da850 */
+        compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
+        #pwm-cells = <3>;
+        reg = <0x300000 0x2000>;
+};
diff --git a/Documentation/devicetree/bindings/regulator/max8952.txt b/Documentation/devicetree/bindings/regulator/max8952.txt
new file mode 100644
index 000000000000..866fcdd0f4eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max8952.txt
@@ -0,0 +1,52 @@
+Maxim MAX8952 voltage regulator
+
+Required properties:
+- compatible: must be equal to "maxim,max8952"
+- reg: I2C slave address, usually 0x60
+- max8952,dvs-mode-microvolt: array of 4 integer values defining DVS voltages
+  in microvolts. All values must be from range <770000, 1400000>
+- any required generic properties defined in regulator.txt
+
+Optional properties:
+- max8952,vid-gpios: array of two GPIO pins used for DVS voltage selection
+- max8952,en-gpio: GPIO used to control enable status of regulator
+- max8952,default-mode: index of default DVS voltage, from <0, 3> range
+- max8952,sync-freq: sync frequency, must be one of following values:
+    - 0: 26 MHz
+    - 1: 13 MHz
+    - 2: 19.2 MHz
+  Defaults to 26 MHz if not specified.
+- max8952,ramp-speed: voltage ramp speed, must be one of following values:
+    - 0: 32mV/us
+    - 1: 16mV/us
+    - 2: 8mV/us
+    - 3: 4mV/us
+    - 4: 2mV/us
+    - 5: 1mV/us
+    - 6: 0.5mV/us
+    - 7: 0.25mV/us
+  Defaults to 32mV/us if not specified.
+- any available generic properties defined in regulator.txt
+
+Example:
+
+        vdd_arm_reg: pmic@60 {
+                compatible = "maxim,max8952";
+                reg = <0x60>;
+
+                /* max8952-specific properties */
+                max8952,vid-gpios = <&gpx0 3 0>, <&gpx0 4 0>;
+                max8952,en-gpio = <&gpx0 1 0>;
+                max8952,default-mode = <0>;
+                max8952,dvs-mode-microvolt = <1250000>, <1200000>,
+                                                <1050000>, <950000>;
+                max8952,sync-freq = <0>;
+                max8952,ramp-speed = <0>;
+
+                /* generic regulator properties */
+                regulator-name = "vdd_arm";
+                regulator-min-microvolt = <770000>;
+                regulator-max-microvolt = <1400000>;
+                regulator-always-on;
+                regulator-boot-on;
+        };
diff --git a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
index 9fd69a18b0ba..9e5e51d78868 100644
--- a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
@@ -28,7 +28,7 @@ Required properties:
     safe operating voltage).
 
     If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
-    property is specified, then all the eigth voltage values for the
+    property is specified, then all the eight voltage values for the
     'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified.
 
 Optional properties:
diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
new file mode 100644
index 000000000000..13301777e11c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt
@@ -0,0 +1,49 @@
+Freescale i.MX System Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "fsl,<chip>-src"
+- reg: should be register base and length as documented in the
+  datasheet
+- interrupts: Should contain SRC interrupt and CPU WDOG interrupt,
+  in this order.
+- #reset-cells: 1, see below
+
+example:
+
+src: src@020d8000 {
+        compatible = "fsl,imx6q-src";
+        reg = <0x020d8000 0x4000>;
+        interrupts = <0 91 0x04 0 96 0x04>;
+        #reset-cells = <1>;
+};
+
+Specifying reset lines connected to IP modules
+==============================================
+
+The system reset controller can be used to reset the GPU, VPU,
+IPU, and OpenVG IP modules on i.MX5 and i.MX6 ICs. Those device
+nodes should specify the reset line on the SRC in their resets
+property, containing a phandle to the SRC device node and a
+RESET_INDEX specifying which module to reset, as described in
+reset.txt
+
+example:
+
+        ipu1: ipu@02400000 {
+                resets = <&src 2>;
+        };
+        ipu2: ipu@02800000 {
+                resets = <&src 4>;
+        };
+
+The following RESET_INDEX values are valid for i.MX5:
+GPU_RESET     0
+VPU_RESET     1
+IPU1_RESET    2
+OPEN_VG_RESET 3
+The following additional RESET_INDEX value is valid for i.MX6:
+IPU2_RESET    4
diff --git a/Documentation/devicetree/bindings/reset/reset.txt b/Documentation/devicetree/bindings/reset/reset.txt
new file mode 100644
index 000000000000..31db6ff84908
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/reset.txt
@@ -0,0 +1,75 @@
+= Reset Signal Device Tree Bindings =
+
+This binding is intended to represent the hardware reset signals present
+internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
+standalone chips are most likely better represented as GPIOs, although there
+are likely to be exceptions to this rule.
+
+Hardware blocks typically receive a reset signal. This signal is generated by
+a reset provider (e.g. power management or clock module) and received by a
+reset consumer (the module being reset, or a module managing when a sub-
+ordinate module is reset). This binding exists to represent the provider and
+consumer, and provide a way to couple the two together.
+
+A reset signal is represented by the phandle of the provider, plus a reset
+specifier - a list of DT cells that represents the reset signal within the
+provider. The length (number of cells) and semantics of the reset specifier
+are dictated by the binding of the reset provider, although common schemes
+are described below.
+
+A word on where to place reset signal consumers in device tree: It is possible
+in hardware for a reset signal to affect multiple logically separate HW blocks
+at once. In this case, it would be unwise to represent this reset signal in
+the DT node of each affected HW block, since if activated, an unrelated block
+may be reset. Instead, reset signals should be represented in the DT node
+where it makes most sense to control it; this may be a bus node if all
+children of the bus are affected by the reset signal, or an individual HW
+block node for dedicated reset signals. The intent of this binding is to give
+appropriate software access to the reset signals in order to manage the HW,
+rather than to slavishly enumerate the reset signal that affects each HW
+block.
+
+= Reset providers =
+
+Required properties:
+#reset-cells:   Number of cells in a reset specifier; Typically 0 for nodes
+                with a single reset output and 1 for nodes with multiple
+                reset outputs.
+
+For example:
+
+        rst: reset-controller {
+                #reset-cells = <1>;
+        };
+
+= Reset consumers =
+
+Required properties:
+resets:         List of phandle and reset specifier pairs, one pair
+                for each reset signal that affects the device, or that the
+                device manages. Note: if the reset provider specifies '0' for
+                #reset-cells, then only the phandle portion of the pair will
+                appear.
+
+Optional properties:
+reset-names:    List of reset signal name strings sorted in the same order as
+                the resets property. Consumers drivers will use reset-names to
+                match reset signal names with reset specifiers.
+
+For example:
+
+        device {
+                resets = <&rst 20>;
+                reset-names = "reset";
+        };
+
+This represents a device with a single reset signal named "reset".
+
+        bus {
+                resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>;
+                reset-names = "i2s1", "i2s2", "dma", "mixer";
+        };
+
+This represents a bus that controls the reset signal of each of four sub-
+ordinate devices. Consider for example a bus that fails to operate unless no
+child device has reset asserted.
diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
new file mode 100644
index 000000000000..07ccdaa68324
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
@@ -0,0 +1,13 @@
+BCM2835 Random number generator
+
+Required properties:
+
+- compatible : should be "brcm,bcm2835-rng"
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+rng {
+        compatible = "brcm,bcm2835-rng";
+        reg = <0x7e104000 0x10>;
+};
diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
new file mode 100644
index 000000000000..2a3feabd3b22
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
@@ -0,0 +1,15 @@
+Atmel AT91RM9200 Real Time Clock
+
+Required properties:
+- compatible: should be: "atmel,at91rm9200-rtc"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: rtc alarm/event interrupt
+
+Example:
+
+rtc@fffffe00 {
+        compatible = "atmel,at91rm9200-rtc";
+        reg = <0xfffffe00 0x100>;
+        interrupts = <1 4 7>;
+};
diff --git a/Documentation/devicetree/bindings/serial/pl011.txt b/Documentation/devicetree/bindings/serial/pl011.txt
new file mode 100644
index 000000000000..5d2e840ae65c
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/pl011.txt
@@ -0,0 +1,17 @@
+* ARM AMBA Primecell PL011 serial UART
+
+Required properties:
+- compatible: must be "arm,primecell", "arm,pl011"
+- reg: exactly one register range with length 0x1000
+- interrupts: exactly one interrupt specifier
+
+Optional properties:
+- pinctrl: When present, must have one state named "sleep"
+           and one state named "default"
+- clocks:  When present, must refer to exactly one clock named
+           "apb_pclk"
+- dmas:    When present, may have one or two dma channels.
+           The first one must be named "rx", the second one
+           must be named "tx".
+
+See also bindings/arm/primecell.txt
diff --git a/Documentation/devicetree/bindings/serio/snps-arc_ps2.txt b/Documentation/devicetree/bindings/serio/snps-arc_ps2.txt
new file mode 100644
index 000000000000..38c2f21e8044
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/snps-arc_ps2.txt
@@ -0,0 +1,16 @@
+* ARC PS/2 driver: PS/2 block used in some ARC FPGA's & nSIM OSCI model
+
+Required properties:
+- compatible            : "snps,arc_ps2"
+- reg                   : offset and length (always 0x14) of registers
+- interrupts            : interrupt
+- interrupt-names       : name of interrupt, must be "arc_ps2_irq"
+
+Example:
+
+serio@c9000400 {
+        compatible = "snps,arc_ps2";
+        reg = <0xc9000400 0x14>;
+        interrupts = <13>;
+        interrupt-names = "arc_ps2_irq";
+}
diff --git a/Documentation/devicetree/bindings/sound/ak5386.txt b/Documentation/devicetree/bindings/sound/ak5386.txt
new file mode 100644
index 000000000000..dc3914fe6ce8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ak5386.txt
@@ -0,0 +1,19 @@
+AK5386 Single-ended 24-Bit 192kHz delta-sigma ADC
+
+This device has no control interface.
+
+Required properties:
+
+  - compatible : "asahi-kasei,ak5386"
+
+Optional properties:
+
+  - reset-gpio : a GPIO spec for the reset/power down pin.
+                 If specified, it will be deasserted at probe time.
+
+Example:
+
+spdif: ak5386@0 {
+        compatible = "asahi-kasei,ak5386";
+        reset-gpio = <&gpio0 23>;
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
index b77a97c9101e..05ffecb57103 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
@@ -2,6 +2,11 @@ NVIDIA Tegra audio complex
 
 Required properties:
 - compatible : "nvidia,tegra-audio-alc5632"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+  "pll_a" (The Tegra clock of that name),
+  "pll_a_out0" (The Tegra clock of that name),
+  "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
 - nvidia,model : The user-visible name of this sound complex.
 - nvidia,audio-routing : A list of the connections between audio components.
   Each entry is a pair of strings, the first being the connection's sink,
@@ -56,4 +61,7 @@ sound {
 
         nvidia,i2s-controller = <&tegra_i2s1>;
         nvidia,audio-codec = <&alc5632>;
+
+        clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+        clock-names = "pll_a", "pll_a_out0", "mclk";
 };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt
index 04b14cfb1f16..ef1fe7358279 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt
@@ -2,6 +2,11 @@ NVIDIA Tegra audio complex for TrimSlice
 
 Required properties:
 - compatible : "nvidia,tegra-audio-trimslice"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+  "pll_a" (The Tegra clock of that name),
+  "pll_a_out0" (The Tegra clock of that name),
+  "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
 - nvidia,i2s-controller : The phandle of the Tegra I2S1 controller
 - nvidia,audio-codec : The phandle of the WM8903 audio codec
 
@@ -11,4 +16,6 @@ sound {
         compatible = "nvidia,tegra-audio-trimslice";
         nvidia,i2s-controller = <&tegra_i2s1>;
         nvidia,audio-codec = <&codec>;
+        clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+        clock-names = "pll_a", "pll_a_out0", "mclk";
 };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
index c4dd39ce6165..d14510613a7f 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
@@ -2,6 +2,11 @@ NVIDIA Tegra audio complex
 
 Required properties:
 - compatible : "nvidia,tegra-audio-wm8753"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+  "pll_a" (The Tegra clock of that name),
+  "pll_a_out0" (The Tegra clock of that name),
+  "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
 - nvidia,model : The user-visible name of this sound complex.
 - nvidia,audio-routing : A list of the connections between audio components.
   Each entry is a pair of strings, the first being the connection's sink,
@@ -50,5 +55,8 @@ sound {
 
         nvidia,i2s-controller = <&i2s1>;
         nvidia,audio-codec = <&wm8753>;
+
+        clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+        clock-names = "pll_a", "pll_a_out0", "mclk";
 };
 
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
index d5b0da8bf1d8..3bf722deb722 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
@@ -2,6 +2,11 @@ NVIDIA Tegra audio complex
 
 Required properties:
 - compatible : "nvidia,tegra-audio-wm8903"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+  "pll_a" (The Tegra clock of that name),
+  "pll_a_out0" (The Tegra clock of that name),
+  "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
 - nvidia,model : The user-visible name of this sound complex.
 - nvidia,audio-routing : A list of the connections between audio components.
   Each entry is a pair of strings, the first being the connection's sink,
@@ -67,5 +72,8 @@ sound {
         nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
         nvidia,int-mic-en-gpios = <&gpio 184 0>; /*gpio PX0 */
         nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
+
+        clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+        clock-names = "pll_a", "pll_a_out0", "mclk";
 };
 
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
index be35d34e8b26..ad589b163639 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
@@ -2,6 +2,11 @@ NVIDIA Tegra audio complex
 
 Required properties:
 - compatible : "nvidia,tegra-audio-wm9712"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+  "pll_a" (The Tegra clock of that name),
+  "pll_a_out0" (The Tegra clock of that name),
+  "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
 - nvidia,model : The user-visible name of this sound complex.
 - nvidia,audio-routing : A list of the connections between audio components.
   Each entry is a pair of strings, the first being the connection's sink,
@@ -48,4 +53,7 @@ sound {
                 "Mic", "MIC1";
 
         nvidia,ac97-controller = <&ac97>;
+
+        clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>;
+        clock-names = "pll_a", "pll_a_out0", "mclk";
 };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
index 1ac7b1642186..0e5c12c66523 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
@@ -1,12 +1,22 @@
 NVIDIA Tegra30 AHUB (Audio Hub)
 
 Required properties:
-- compatible : "nvidia,tegra30-ahub"
+- compatible : "nvidia,tegra30-ahub", "nvidia,tegra114-ahub", etc.
 - reg : Should contain the register physical address and length for each of
-  the AHUB's APBIF registers and the AHUB's own registers.
+  the AHUB's register blocks.
+  - Tegra30 requires 2 entries, for the APBIF and AHUB/AUDIO register blocks.
+  - Tegra114 requires an additional entry, for the APBIF2 register block.
 - interrupts : Should contain AHUB interrupt
-- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
-  request selector for the first APBIF channel.
+- nvidia,dma-request-selector : A list of the DMA channel specifiers. Each
+  entry contains the Tegra DMA controller's phandle and request selector.
+  If a single entry is present, the request selectors for the channels are
+  assumed to be contiguous, and increment from this value.
+  If multiple values are given, one value must be given per channel.
+- clocks : Must contain an entry for each required entry in clock-names.
+- clock-names : Must include the following entries:
+  - Tegra30: Requires d_audio, apbif, i2s0, i2s1, i2s2, i2s3, i2s4, dam0,
+    dam1, dam2, spdif_in.
+  - Tegra114: Additionally requires amx, adx.
 - ranges : The bus address mapping for the configlink register bus.
   Can be empty since the mapping is 1:1.
 - #address-cells : For the configlink bus. Should be <1>;
@@ -25,7 +35,13 @@ ahub@70080000 {
         reg = <0x70080000 0x200 0x70080200 0x100>;
         interrupts = < 0 103 0x04 >;
         nvidia,dma-request-selector = <&apbdma 1>;
-
+        clocks = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>,
+                <&tegra_car 11>, <&tegra_car 18>, <&tegra_car 101>,
+                <&tegra_car 102>, <&tegra_car 108>, <&tegra_car 109>,
+                <&tegra_car 110>, <&tegra_car 162>;
+        clock-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2",
+                "i2s3", "i2s4", "dam0", "dam1", "dam2",
+                "spdif_in";
         ranges;
         #address-cells = <1>;
         #size-cells = <1>;
diff --git a/Documentation/devicetree/bindings/sound/ti,tas5086.txt b/Documentation/devicetree/bindings/sound/ti,tas5086.txt
new file mode 100644
index 000000000000..8ea4f5b4818d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas5086.txt
@@ -0,0 +1,32 @@
+Texas Instruments TAS5086 6-channel PWM Processor
+
+Required properties:
+
+ - compatible:          Should contain "ti,tas5086".
+ - reg:                 The i2c address. Should contain <0x1b>.
+
+Optional properties:
+
+ - reset-gpio:          A GPIO spec to define which pin is connected to the
+                        chip's !RESET pin. If specified, the driver will
+                        assert a hardware reset at probe time.
+
+ - ti,charge-period:    This property should contain the time in microseconds
+                        that closely matches the external single-ended
+                        split-capacitor charge period. The hardware chip
+                        waits for this period of time before starting the
+                        PWM signals. This helps reduce pops and clicks.
+
+                        When not specified, the hardware default of 1300ms
+                        is retained.
+
+Examples:
+
+        i2c_bus {
+                tas5086@1b {
+                        compatible = "ti,tas5086";
+                        reg = <0x1b>;
+                        reset-gpio = <&gpio 23 0>;
+                        ti,charge-period = <156000>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt b/Documentation/devicetree/bindings/sound/wm8994.txt
index 7a7eb1e7bda6..f2f3e80934d2 100644
--- a/Documentation/devicetree/bindings/sound/wm8994.txt
+++ b/Documentation/devicetree/bindings/sound/wm8994.txt
@@ -5,14 +5,70 @@ on the board).
 
 Required properties:
 
-  - compatible : "wlf,wm1811", "wlf,wm8994", "wlf,wm8958"
+  - compatible : One of "wlf,wm1811", "wlf,wm8994" or "wlf,wm8958".
 
   - reg : the I2C address of the device for I2C, the chip select
           number for SPI.
 
+  - gpio-controller : Indicates this device is a GPIO controller.
+  - #gpio-cells : Must be 2. The first cell is the pin number and the
+    second cell is used to specify optional parameters (currently unused).
+
+  - AVDD2-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
+    SPKVDD1-supply, SPKVDD2-supply : power supplies for the device, as covered
+    in Documentation/devicetree/bindings/regulator/regulator.txt
+
+Optional properties:
+
+  - interrupts : The interrupt line the IRQ signal for the device is
+    connected to.  This is optional, if it is not connected then none
+    of the interrupt related properties should be specified.
+  - interrupt-controller : These devices contain interrupt controllers
+    and may provide interrupt services to other devices if they have an
+    interrupt line connected.
+  - interrupt-parent : The parent interrupt controller.
+  - #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
+    The first cell is the IRQ number.
+    The second cell is the flags, encoded as the trigger masks from
+    Documentation/devicetree/bindings/interrupts.txt
+
+  - wlf,gpio-cfg : A list of GPIO configuration register values. If absent,
+    no configuration of these registers is performed. If any value is
+    over 0xffff then the register will be left as default. If present 11
+    values must be supplied.
+
+  - wlf,micbias-cfg : Two MICBIAS register values for WM1811 or
+    WM8958.  If absent the register defaults will be used.
+
+  - wlf,ldo1ena : GPIO specifier for control of LDO1ENA input to device.
+  - wlf,ldo2ena : GPIO specifier for control of LDO2ENA input to device.
+
+  - wlf,lineout1-se : If present LINEOUT1 is in single ended mode.
+  - wlf,lineout2-se : If present LINEOUT2 is in single ended mode.
+
+  - wlf,lineout1-feedback : If present LINEOUT1 has common mode feedback
+    connected.
+  - wlf,lineout2-feedback : If present LINEOUT2 has common mode feedback
+    connected.
+
+  - wlf,ldoena-always-driven : If present LDOENA is always driven.
+
 Example:
 
 codec: wm8994@1a {
         compatible = "wlf,wm8994";
         reg = <0x1a>;
+
+        gpio-controller;
+        #gpio-cells = <2>;
+
+        lineout1-se;
+
+        AVDD2-supply = <&regulator>;
+        CPVDD-supply = <&regulator>;
+        DBVDD1-supply = <&regulator>;
+        DBVDD2-supply = <&regulator>;
+        DBVDD3-supply = <&regulator>;
+        SPKVDD1-supply = <&regulator>;
+        SPKVDD2-supply = <&regulator>;
 };
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
new file mode 100644
index 000000000000..8bf89c643640
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
@@ -0,0 +1,22 @@
+Broadcom BCM2835 SPI0 controller
+
+The BCM2835 contains two forms of SPI master controller, one known simply as
+SPI0, and the other known as the "Universal SPI Master"; part of the
+auxilliary block. This binding applies to the SPI0 controller.
+
+Required properties:
+- compatible: Should be "brcm,bcm2835-spi".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks: The clock feeding the SPI controller.
+
+Example:
+
+spi@20204000 {
+        compatible = "brcm,bcm2835-spi";
+        reg = <0x7e204000 0x1000>;
+        interrupts = <2 22>;
+        clocks = <&clk_spi>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+};
diff --git a/Documentation/devicetree/bindings/spi/fsl-spi.txt b/Documentation/devicetree/bindings/spi/fsl-spi.txt
index 777abd7399d5..b032dd76e9d2 100644
--- a/Documentation/devicetree/bindings/spi/fsl-spi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-spi.txt
@@ -4,7 +4,7 @@ Required properties:
 - cell-index : QE SPI subblock index.
                 0: QE subblock SPI1
                 1: QE subblock SPI2
-- compatible : should be "fsl,spi".
+- compatible : should be "fsl,spi" or "aeroflexgaisler,spictrl".
 - mode : the SPI operation mode, it can be "cpu" or "cpu-qe".
 - reg : Offset and length of the register set for the device
 - interrupts : <a b> where a is the interrupt number and b is a
@@ -14,6 +14,7 @@ Required properties:
   controller you have.
 - interrupt-parent : the phandle for the interrupt controller that
   services interrupts for this device.
+- clock-frequency : input clock frequency to non FSL_SOC cores
 
 Optional properties:
 - gpios : specifies the gpio pins to be used for chipselects.
diff --git a/Documentation/devicetree/bindings/spi/mxs-spi.txt b/Documentation/devicetree/bindings/spi/mxs-spi.txt
index e2e13957c2a4..3499b73293c2 100644
--- a/Documentation/devicetree/bindings/spi/mxs-spi.txt
+++ b/Documentation/devicetree/bindings/spi/mxs-spi.txt
@@ -3,8 +3,11 @@
 Required properties:
 - compatible: Should be "fsl,<soc>-spi", where soc is "imx23" or "imx28"
 - reg: Offset and length of the register set for the device
-- interrupts: Should contain SSP interrupts (error irq first, dma irq second)
-- fsl,ssp-dma-channel: APBX DMA channel for the SSP
+- interrupts: Should contain SSP ERROR interrupt
+- dmas: DMA specifier, consisting of a phandle to DMA controller node
+  and SSP DMA channel ID.
+  Refer to dma.txt and fsl-mxs-dma.txt for details.
+- dma-names: Must be "rx-tx".
 
 Optional properties:
 - clock-frequency : Input clock frequency to the SPI block in Hz.
@@ -17,6 +20,7 @@ ssp0: ssp@80010000 {
         #size-cells = <0>;
         compatible = "fsl,imx28-spi";
         reg = <0x80010000 0x2000>;
-        interrupts = <96 82>;
-        fsl,ssp-dma-channel = <0>;
+        interrupts = <96>;
+        dmas = <&dma_apbh 0>;
+        dma-names = "rx-tx";
 };
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
new file mode 100644
index 000000000000..91ff771c7e77
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
@@ -0,0 +1,26 @@
+NVIDIA Tegra114 SPI controller.
+
+Required properties:
+- compatible : should be "nvidia,tegra114-spi".
+- reg: Should contain SPI registers location and length.
+- interrupts: Should contain SPI interrupts.
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+  request selector for this SPI controller.
+- This is also require clock named "spi" as per binding document
+  Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Recommended properties:
+- spi-max-frequency: Definition as per
+                     Documentation/devicetree/bindings/spi/spi-bus.txt
+Example:
+
+spi@7000d600 {
+        compatible = "nvidia,tegra114-spi";
+        reg = <0x7000d600 0x200>;
+        interrupts = <0 82 0x04>;
+        nvidia,dma-request-selector = <&apbdma 16>;
+        spi-max-frequency = <25000000>;
+        #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
new file mode 100644
index 000000000000..6d0ac8d0ad9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt
@@ -0,0 +1,51 @@
+Davinci SPI controller device bindings
+
+Required properties:
+- #address-cells: number of cells required to define a chip select
+        address on the SPI bus. Should be set to 1.
+- #size-cells: should be zero.
+- compatible:
+        - "ti,dm6441-spi" for SPI used similar to that on DM644x SoC family
+        - "ti,da830-spi" for SPI used similar to that on DA8xx SoC family
+- reg: Offset and length of SPI controller register space
+- num-cs: Number of chip selects
+- ti,davinci-spi-intr-line: interrupt line used to connect the SPI
+        IP to the interrupt controller within the SoC. Possible values
+        are 0 and 1. Manual says one of the two possible interrupt
+        lines can be tied to the interrupt controller. Set this
+        based on a specifc SoC configuration.
+- interrupts: interrupt number mapped to CPU.
+- clocks: spi clk phandle
+
+Example of a NOR flash slave device (n25q032) connected to DaVinci
+SPI controller device over the SPI bus.
+
+spi0:spi@20BF0000 {
+        #address-cells                  = <1>;
+        #size-cells                     = <0>;
+        compatible                      = "ti,dm6446-spi";
+        reg                             = <0x20BF0000 0x1000>;
+        num-cs                          = <4>;
+        ti,davinci-spi-intr-line        = <0>;
+        interrupts                      = <338>;
+        clocks                          = <&clkspi>;
+
+        flash: n25q032@0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                compatible = "st,m25p32";
+                spi-max-frequency = <25000000>;
+                reg = <0>;
+
+                partition@0 {
+                        label = "u-boot-spl";
+                        reg = <0x0 0x80000>;
+                        read-only;
+                };
+
+                partition@1 {
+                        label = "test";
+                        reg = <0x80000 0x380000>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt b/Documentation/devicetree/bindings/spi/spi-samsung.txt
index a15ffeddfba4..86aa061f069f 100644
--- a/Documentation/devicetree/bindings/spi/spi-samsung.txt
+++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt
@@ -31,9 +31,6 @@ Required Board Specific Properties:
 
 - #address-cells: should be 1.
 - #size-cells: should be 0.
-- gpios: The gpio specifier for clock, mosi and miso interface lines (in the
-  order specified). The format of the gpio specifier depends on the gpio
-  controller.
 
 Optional Board Specific Properties:
 
@@ -86,9 +83,8 @@ Example:
         spi_0: spi@12d20000 {
                 #address-cells = <1>;
                 #size-cells = <0>;
-                gpios = <&gpa2 4 2 3 0>,
-                        <&gpa2 6 2 3 0>,
-                        <&gpa2 7 2 3 0>;
+                pinctrl-names = "default";
+                pinctrl-0 = <&spi0_bus>;
 
                 w25q80bw@0 {
                         #address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt b/Documentation/devicetree/bindings/spi/spi_pl022.txt
index f158fd31cfda..22ed6797216d 100644
--- a/Documentation/devicetree/bindings/spi/spi_pl022.txt
+++ b/Documentation/devicetree/bindings/spi/spi_pl022.txt
@@ -16,6 +16,11 @@ Optional properties:
                             device will be suspended immediately
 - pl022,rt : indicates the controller should run the message pump with realtime
              priority to minimise the transfer latency on the bus (boolean)
+- dmas : Two or more DMA channel specifiers following the convention outlined
+         in bindings/dma/dma.txt
+- dma-names: Names for the dma channels, if present. There must be at
+             least one channel named "tx" for transmit and named "rx" for
+             receive.
 
 
 SPI slave nodes must be children of the SPI master node and can
@@ -32,3 +37,34 @@ contain the following properties.
 - pl022,wait-state : Microwire interface: Wait state
 - pl022,duplex : Microwire interface: Full/Half duplex
 
+
+Example:
+
+        spi@e0100000 {
+                compatible = "arm,pl022", "arm,primecell";
+                reg = <0xe0100000 0x1000>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+                interrupts = <0 31 0x4>;
+                dmas = <&dma-controller 23 1>,
+                        <&dma-controller 24 0>;
+                dma-names = "rx", "tx";
+
+                m25p80@1 {
+                        compatible = "st,m25p80";
+                        reg = <1>;
+                        spi-max-frequency = <12000000>;
+                        spi-cpol;
+                        spi-cpha;
+                        pl022,hierarchy = <0>;
+                        pl022,interface = <0>;
+                        pl022,slave-tx-disable;
+                        pl022,com-mode = <0x2>;
+                        pl022,rx-level-trig = <0>;
+                        pl022,tx-level-trig = <0>;
+                        pl022,ctrl-len = <0x11>;
+                        pl022,wait-state = <0>;
+                        pl022,duplex = <0>;
+                };
+        };
+        
diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt b/Documentation/devicetree/bindings/staging/dwc2.txt
new file mode 100644
index 000000000000..1a1b7cfa4845
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -0,0 +1,15 @@
+Platform DesignWare HS OTG USB 2.0 controller
+-----------------------------------------------------
+
+Required properties:
+- compatible : "snps,dwc2"
+- reg : Should contain 1 register range (address and length)
+- interrupts : Should contain 1 interrupt
+
+Example:
+
+        usb@101c0000 {
+                compatible = "ralink,rt3050-usb, snps,dwc2";
+                reg = <0x101c0000 40000>;
+                interrupts = <18>;
+        };
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index 07654f0338b6..b876d4925a57 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -8,6 +8,8 @@ Required properties:
 - interrupts: Should contain sync interrupt and error interrupt,
   in this order.
 - #crtc-cells: 1, See below
+- resets: phandle pointing to the system reset controller and
+          reset line index, see reset/fsl,imx-src.txt for details
 
 example:
 
@@ -16,6 +18,7 @@ ipu: ipu@18000000 {
         compatible = "fsl,imx53-ipu";
         reg = <0x18000000 0x080000000>;
         interrupts = <11 10>;
+        resets = <&src 2>;
 };
 
 Parallel display support
@@ -26,7 +29,7 @@ Required properties:
 - crtc: the crtc this display is connected to, see below
 Optional properties:
 - interface_pix_fmt: How this display is connected to the
-  crtc. Currently supported types: "rgb24", "rgb565"
+  crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
 - edid: verbatim EDID data block describing attached display.
 - ddc: phandle describing the i2c bus handling the display data
   channel
diff --git a/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
index 0c7b64e95a61..48aeb7884ed3 100644
--- a/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
@@ -2,7 +2,7 @@ Allwinner A1X SoCs Timer Controller
 
 Required properties:
 
-- compatible : should be "allwinner,sunxi-timer"
+- compatible : should be "allwinner,sun4i-timer"
 - reg : Specifies base physical address and size of the registers.
 - interrupts : The interrupt of the first timer
 - clocks: phandle to the source clock (usually a 24 MHz fixed clock)
@@ -10,7 +10,7 @@ Required properties:
 Example:
 
 timer {
-        compatible = "allwinner,sunxi-timer";
+        compatible = "allwinner,sun4i-timer";
         reg = <0x01c20c00 0x400>;
         interrupts = <22>;
         clocks = <&osc>;
diff --git a/Documentation/devicetree/bindings/timer/arm,sp804.txt b/Documentation/devicetree/bindings/timer/arm,sp804.txt
new file mode 100644
index 000000000000..5cd8eee74af1
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/arm,sp804.txt
@@ -0,0 +1,29 @@
+ARM sp804 Dual Timers
+---------------------------------------
+
+Required properties:
+- compatible: Should be "arm,sp804" & "arm,primecell"
+- interrupts: Should contain the list of Dual Timer interrupts. This is the
+        interrupt for timer 1 and timer 2. In the case of a single entry, it is
+        the combined interrupt or if "arm,sp804-has-irq" is present that
+        specifies which timer interrupt is connected.
+- reg: Should contain location and length for dual timer register.
+- clocks: clocks driving the dual timer hardware. This list should be 1 or 3
+        clocks. With 3 clocks, the order is timer0 clock, timer1 clock,
+        apb_pclk. A single clock can also be specified if the same clock is
+        used for all clock inputs.
+
+Optional properties:
+- arm,sp804-has-irq = <#>: In the case of only 1 timer irq line connected, this
+        specifies if the irq connection is for timer 1 or timer 2. A value of 1
+        or 2 should be used.
+
+Example:
+
+        timer0: timer@fc800000 {
+                compatible = "arm,sp804", "arm,primecell";
+                reg = <0xfc800000 0x1000>;
+                interrupts = <0 0 4>, <0 1 4>;
+                clocks = <&timclk1 &timclk2 &pclk>;
+                clock-names = "timer1", "timer2", "apb_pclk";
+        };
diff --git a/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
new file mode 100644
index 000000000000..993695c659e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
@@ -0,0 +1,17 @@
+Cadence TTC - Triple Timer Counter
+
+Required properties:
+- compatible : Should be "cdns,ttc".
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 3 interrupts; one per timer channel.
+- clocks: phandle to the source clock
+
+Example:
+
+ttc0: ttc0@f8001000 {
+        interrupt-parent = <&intc>;
+        interrupts = < 0 10 4 0 11 4 0 12 4 >;
+        compatible = "cdns,ttc";
+        reg = <0xF8001000 0x1000>;
+        clocks = <&cpu_clk 3>;
+};
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
new file mode 100644
index 000000000000..9809b11f7180
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
@@ -0,0 +1,18 @@
+Freescale i.MX General Purpose Timer (GPT)
+
+Required properties:
+
+- compatible : should be "fsl,<soc>-gpt"
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 4 interrupts; one per timer channel.
+- clocks : The clocks provided by the SoC to drive the timer.
+
+Example:
+
+gpt1: timer@10003000 {
+        compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+        reg = <0x10003000 0x1000>;
+        interrupts = <26>;
+        clocks = <&clks 46>, <&clks 61>;
+        clock-names = "ipg", "per";
+};
diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
new file mode 100644
index 000000000000..cb47bfbcaeea
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
@@ -0,0 +1,68 @@
+Samsung's Multi Core Timer (MCT)
+
+The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
+global timer and CPU local timers. The global timer is a 64-bit free running
+up-counter and can generate 4 interrupts when the counter reaches one of the
+four preset counter values. The CPU local timers are 32-bit free running
+down-counters and generate an interrupt when the counter expires. There is
+one CPU local timer instantiated in MCT for every CPU in the system.
+
+Required properties:
+
+- compatible: should be "samsung,exynos4210-mct".
+  (a) "samsung,exynos4210-mct", for mct compatible with Exynos4210 mct.
+  (b) "samsung,exynos4412-mct", for mct compatible with Exynos4412 mct.
+
+- reg: base address of the mct controller and length of the address space
+  it occupies.
+
+- interrupts: the list of interrupts generated by the controller. The following
+  should be the order of the interrupts specified. The local timer interrupts
+  should be specified after the four global timer interrupts have been
+  specified.
+
+        0: Global Timer Interrupt 0
+        1: Global Timer Interrupt 1
+        2: Global Timer Interrupt 2
+        3: Global Timer Interrupt 3
+        4: Local Timer Interrupt 0
+        5: Local Timer Interrupt 1
+        6: ..
+        7: ..
+        i: Local Timer Interrupt n
+
+Example 1: In this example, the system uses only the first global timer
+           interrupt generated by MCT and the remaining three global timer
+           interrupts are unused. Two local timer interrupts have been
+           specified.
+
+        mct@10050000 {
+                compatible = "samsung,exynos4210-mct";
+                reg = <0x10050000 0x800>;
+                interrupts = <0 57 0>, <0 0 0>, <0 0 0>, <0 0 0>,
+                             <0 42 0>, <0 48 0>;
+        };
+
+Example 2: In this example, the MCT global and local timer interrupts are
+           connected to two seperate interrupt controllers. Hence, an
+           interrupt-map is created to map the interrupts to the respective
+           interrupt controllers.
+
+        mct@101C0000 {
+                compatible = "samsung,exynos4210-mct";
+                reg = <0x101C0000 0x800>;
+                interrupt-controller;
+                #interrups-cells = <2>;
+                interrupt-parent = <&mct_map>;
+                interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
+                             <4 0>, <5 0>;
+
+                mct_map: mct-map {
+                        #interrupt-cells = <2>;
+                        #address-cells = <0>;
+                        #size-cells = <0>;
+                        interrupt-map = <0x0 0 &combiner 23 3>,
+                                        <0x4 0 &gic 0 120 0>,
+                                        <0x5 0 &gic 0 121 0>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
index 273a8d5b3300..2c00ec64628e 100644
--- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
@@ -5,20 +5,18 @@ Required properties:
   imx23 and imx28.
 - reg : Address and length of the register set for the device
 - interrupts : Should contain the auart interrupt numbers
-
-Optional properties:
-- fsl,auart-dma-channel : The DMA channels, the first is for RX, the other
-                is for TX. If you add this property, it also means that you
-                will enable the DMA support for the auart.
-                Note: due to the hardware bug in imx23(see errata : 2836),
-                only the imx28 can enable the DMA support for the auart.
+- dmas: DMA specifier, consisting of a phandle to DMA controller node
+  and AUART DMA channel ID.
+  Refer to dma.txt and fsl-mxs-dma.txt for details.
+- dma-names: "rx" for RX channel, "tx" for TX channel.
 
 Example:
 auart0: serial@8006a000 {
         compatible = "fsl,imx28-auart", "fsl,imx23-auart";
         reg = <0x8006a000 0x2000>;
-        interrupts = <112 70 71>;
-        fsl,auart-dma-channel = <8 9>;
+        interrupts = <112>;
+        dmas = <&dma_apbx 8>, <&dma_apbx 9>;
+        dma-names = "rx", "tx";
 };
 
 Note: Each auart port should have an alias correctly numbered in "aliases"
diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
index 1e1145ca4f3c..1928a3e83cd0 100644
--- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
@@ -11,6 +11,9 @@ Required properties:
         - "nvidia,tegra20-uart"
         - "nxp,lpc3220-uart"
         - "ibm,qpace-nwp-serial"
+        - "altr,16550-FIFO32"
+        - "altr,16550-FIFO64"
+        - "altr,16550-FIFO128"
         - "serial" if the port type is unknown.
 - reg : offset and length of the register set for the device.
 - interrupts : should contain uart interrupt.
@@ -30,6 +33,10 @@ Optional properties:
   RTAS and should not be registered.
 - no-loopback-test: set to indicate that the port does not implements loopback
   test mode
+- fifo-size: the fifo size of the UART.
+- auto-flow-control: one way to enable automatic flow control support. The
+  driver is allowed to detect support for the capability even without this
+  property.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
index 5778b9c83bd8..1c04a4c9515f 100644
--- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
+++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
@@ -11,6 +11,7 @@ Optional properties:
   that indicate usb controller index
 - vbus-supply: regulator for vbus
 - disable-over-current: disable over current detect
+- external-vbus-divider: enables off-chip resistor divider for Vbus
 
 Examples:
 usb@02184000 { /* USB OTG */
@@ -20,4 +21,5 @@ usb@02184000 { /* USB OTG */
         fsl,usbphy = <&usbphy1>;
         fsl,usbmisc = <&usbmisc 0>;
         disable-over-current;
+        external-vbus-divider;
 };
diff --git a/Documentation/devicetree/bindings/usb/ehci-omap.txt b/Documentation/devicetree/bindings/usb/ehci-omap.txt
new file mode 100644
index 000000000000..485a9a1efa7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ehci-omap.txt
@@ -0,0 +1,32 @@
+OMAP HS USB EHCI controller
+
+This device is usually the child of the omap-usb-host
+Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+
+Required properties:
+
+- compatible: should be "ti,ehci-omap"
+- reg: should contain one register range i.e. start and length
+- interrupts: description of the interrupt line
+
+Optional properties:
+
+- phys: list of phandles to PHY nodes.
+  This property is required if at least one of the ports are in
+  PHY mode i.e. OMAP_EHCI_PORT_MODE_PHY
+
+To specify the port mode, see
+Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+
+Example for OMAP4:
+
+usbhsehci: ehci@4a064c00 {
+        compatible = "ti,ehci-omap", "usb-ehci";
+        reg = <0x4a064c00 0x400>;
+        interrupts = <0 77 0x4>;
+};
+
+&usbhsehci {
+        phys = <&hsusb1_phy 0 &hsusb3_phy>;
+};
+
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 000000000000..b3abde736017
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,50 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
+   EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+   region.
+ - interrupts: interrupt number to the cpu.
+ - clocks: from common clock binding: handle to usb clock.
+ - clock-names: from common clock binding: Shall be "usbhost".
+
+Optional properties:
+ - samsung,vbus-gpio:  if present, specifies the GPIO that
+   needs to be pulled up for the bus to be powered.
+
+Example:
+
+        usb@12110000 {
+                compatible = "samsung,exynos4210-ehci";
+                reg = <0x12110000 0x100>;
+                interrupts = <0 71 0>;
+                samsung,vbus-gpio = <&gpx2 6 1 3 3>;
+
+                clocks = <&clock 285>;
+                clock-names = "usbhost";
+        };
+
+OHCI
+Required properties:
+ - compatible: should be "samsung,exynos4210-ohci" for USB 2.0
+   OHCI companion controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+   region.
+ - interrupts: interrupt number to the cpu.
+ - clocks: from common clock binding: handle to usb clock.
+ - clock-names: from common clock binding: Shall be "usbhost".
+
+Example:
+        usb@12120000 {
+                compatible = "samsung,exynos4210-ohci";
+                reg = <0x12120000 0x100>;
+                interrupts = <0 71 0>;
+
+                clocks = <&clock 285>;
+                clock-names = "usbhost";
+        };
diff --git a/Documentation/devicetree/bindings/usb/ohci-omap3.txt b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
new file mode 100644
index 000000000000..14ab42812a8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
@@ -0,0 +1,15 @@
+OMAP HS USB OHCI controller (OMAP3 and later)
+
+Required properties:
+
+- compatible: should be "ti,ohci-omap3"
+- reg: should contain one register range i.e. start and length
+- interrupts: description of the interrupt line
+
+Example for OMAP4:
+
+usbhsohci: ohci@4a064800 {
+        compatible = "ti,ohci-omap3", "usb-ohci";
+        reg = <0x4a064800 0x400>;
+        interrupts = <0 76 0x4>;
+};
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 1ef0ce71f8fa..d4769f343d6c 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -8,16 +8,17 @@ OMAP MUSB GLUE
    and disconnect.
  - multipoint : Should be "1" indicating the musb controller supports
    multipoint. This is a MUSB configuration-specific setting.
- - num_eps : Specifies the number of endpoints. This is also a
+ - num-eps : Specifies the number of endpoints. This is also a
    MUSB configuration-specific setting. Should be set to "16"
- - ram_bits : Specifies the ram address size. Should be set to "12"
- - interface_type : This is a board specific setting to describe the type of
+ - ram-bits : Specifies the ram address size. Should be set to "12"
+ - interface-type : This is a board specific setting to describe the type of
    interface between the controller and the phy. It should be "0" or "1"
    specifying ULPI and UTMI respectively.
  - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
    represents PERIPHERAL.
  - power : Should be "50". This signifies the controller can supply upto
    100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -29,18 +30,46 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
         ti,hwmods = "usb_otg_hs";
         ti,has-mailbox;
         multipoint = <1>;
-        num_eps = <16>;
-        ram_bits = <12>;
+        num-eps = <16>;
+        ram-bits = <12>;
         ctrl-module = <&omap_control_usb>;
 };
 
 Board specific device node entry
 &usb_otg_hs {
-        interface_type = <1>;
+        interface-type = <1>;
         mode = <3>;
         power = <50>;
 };
 
+OMAP DWC3 GLUE
+ - compatible : Should be "ti,dwc3"
+ - ti,hwmods : Should be "usb_otg_ss"
+ - reg : Address and length of the register set for the device.
+ - interrupts : The irq number of this device that is used to interrupt the
+   MPU
+ - #address-cells, #size-cells : Must be present if the device has sub-nodes
+ - utmi-mode : controls the source of UTMI/PIPE status for VBUS and OTG ID.
+   It should be set to "1" for HW mode and "2" for SW mode.
+ - ranges: the child address space are mapped 1:1 onto the parent address space
+
+Sub-nodes:
+The dwc3 core should be added as subnode to omap dwc3 glue.
+- dwc3 :
+   The binding details of dwc3 can be found in:
+   Documentation/devicetree/bindings/usb/dwc3.txt
+
+omap_dwc3 {
+        compatible = "ti,dwc3";
+        ti,hwmods = "usb_otg_ss";
+        reg = <0x4a020000 0x1ff>;
+        interrupts = <0 93 4>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        utmi-mode = <2>;
+        ranges;
+};
+
 OMAP CONTROL USB
 
 Required properties:
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 033194934f64..33fd3543f3f8 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -1,20 +1,25 @@
-* Samsung's usb phy transceiver
+SAMSUNG USB-PHY controllers
 
-The Samsung's phy transceiver is used for controlling usb phy for
-s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers
-across Samsung SOCs.
+** Samsung's usb 2.0 phy transceiver
+
+The Samsung's usb 2.0 phy transceiver is used for controlling
+usb 2.0 phy for s3c-hsotg as well as ehci-s5p and ohci-exynos
+usb controllers across Samsung SOCs.
 TODO: Adding the PHY binding with controller(s) according to the under
-developement generic PHY driver.
+development generic PHY driver.
 
 Required properties:
 
 Exynos4210:
-- compatible : should be "samsung,exynos4210-usbphy"
+- compatible : should be "samsung,exynos4210-usb2phy"
 - reg : base physical address of the phy registers and length of memory mapped
         region.
+- clocks: Clock IDs array as required by the controller.
+- clock-names: names of clock correseponding IDs clock property as requested
+               by the controller driver.
 
 Exynos5250:
-- compatible : should be "samsung,exynos5250-usbphy"
+- compatible : should be "samsung,exynos5250-usb2phy"
 - reg : base physical address of the phy registers and length of memory mapped
         region.
 
@@ -44,12 +49,69 @@ Example:
         usbphy@125B0000 {
                 #address-cells = <1>;
                 #size-cells = <1>;
-                compatible = "samsung,exynos4210-usbphy";
+                compatible = "samsung,exynos4210-usb2phy";
                 reg = <0x125B0000 0x100>;
                 ranges;
 
+                clocks = <&clock 2>, <&clock 305>;
+                clock-names = "xusbxti", "otg";
+
                 usbphy-sys {
                         /* USB device and host PHY_CONTROL registers */
                         reg = <0x10020704 0x8>;
                 };
         };
+
+
+** Samsung's usb 3.0 phy transceiver
+
+Starting exynso5250, Samsung's SoC have usb 3.0 phy transceiver
+which is used for controlling usb 3.0 phy for dwc3-exynos usb 3.0
+controllers across Samsung SOCs.
+
+Required properties:
+
+Exynos5250:
+- compatible : should be "samsung,exynos5250-usb3phy"
+- reg : base physical address of the phy registers and length of memory mapped
+        region.
+- clocks: Clock IDs array as required by the controller.
+- clock-names: names of clocks correseponding to IDs in the clock property
+               as requested by the controller driver.
+
+Optional properties:
+- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+                  property.
+- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+               property.
+- ranges: allows valid translation between child's address space and parent's
+          address space.
+
+- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
+  interface for usb-phy. It should provide the following information required by
+  usb-phy controller to control phy.
+  - reg : base physical address of PHY_CONTROL registers.
+          The size of this register is the total sum of size of all PHY_CONTROL
+          registers that the SoC has. For example, the size will be
+          '0x4' in case we have only one PHY_CONTROL register (e.g.
+          OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
+          and, '0x8' in case we have two PHY_CONTROL registers (e.g.
+          USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
+          and so on.
+
+Example:
+        usbphy@12100000 {
+                compatible = "samsung,exynos5250-usb3phy";
+                reg = <0x12100000 0x100>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ranges;
+
+                clocks = <&clock 1>, <&clock 286>;
+                clock-names = "ext_xtal", "usbdrd30";
+
+                usbphy-sys {
+                        /* USB device and host PHY_CONTROL registers */
+                        reg = <0x10040704 0x8>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
new file mode 100644
index 000000000000..d7e272671c7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -0,0 +1,34 @@
+USB NOP PHY
+
+Required properties:
+- compatible: should be usb-nop-xceiv
+
+Optional properties:
+- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
+  /bindings/clock/clock-bindings.txt
+  This property is required if clock-frequency is specified.
+
+- clock-names: Should be "main_clk"
+
+- clock-frequency: the clock frequency (in Hz) that the PHY clock must
+  be configured to.
+
+- vcc-supply: phandle to the regulator that provides RESET to the PHY.
+
+- reset-supply: phandle to the regulator that provides power to the PHY.
+
+Example:
+
+        hsusb1_phy {
+                compatible = "usb-nop-xceiv";
+                clock-frequency = <19200000>;
+                clocks = <&osc 0>;
+                clock-names = "main_clk";
+                vcc-supply = <&hsusb1_vcc_regulator>;
+                reset-supply = <&hsusb1_reset_regulator>;
+        };
+
+hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
+and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
+hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
+controls RESET.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 19e1ef73ab0d..4d1919bf2332 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -5,6 +5,7 @@ using them to avoid name-space collisions.
 
 ad      Avionic Design GmbH
 adi     Analog Devices, Inc.
+aeroflexgaisler Aeroflex Gaisler AB
 ak      Asahi Kasei Corp.
 amcc    Applied Micro Circuits Corporation (APM, formally AMCC)
 apm     Applied Micro Circuits Corporation (APM)
@@ -48,6 +49,7 @@ samsung	Samsung Semiconductor
 sbs     Smart Battery System
 schindler       Schindler
 sil     Silicon Image
+silabs  Silicon Laboratories
 simtek
 sirf    SiRF Technology, Inc.
 snps    Synopsys, Inc.
diff --git a/Documentation/devicetree/bindings/video/backlight/lp855x.txt b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
new file mode 100644
index 000000000000..1482103d288f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
@@ -0,0 +1,41 @@
+lp855x bindings
+
+Required properties:
+  - compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553",
+                "ti,lp8556", "ti,lp8557"
+  - reg: I2C slave address (u8)
+  - dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device.
+
+Optional properties:
+  - bl-name: Backlight device name (string)
+  - init-brt: Initial value of backlight brightness (u8)
+  - pwm-period: PWM period value. Set only PWM input mode used (u32)
+  - rom-addr: Register address of ROM area to be updated (u8)
+  - rom-val: Register value to be updated (u8)
+
+Example:
+
+        /* LP8556 */
+        backlight@2c {
+                compatible = "ti,lp8556";
+                reg = <0x2c>;
+
+                bl-name = "lcd-bl";
+                dev-ctrl = /bits/ 8 <0x85>;
+                init-brt = /bits/ 8 <0x10>;
+        };
+
+        /* LP8557 */
+        backlight@2c {
+                compatible = "ti,lp8557";
+                reg = <0x2c>;
+
+                dev-ctrl = /bits/ 8 <0x41>;
+                init-brt = /bits/ 8 <0x0a>;
+
+                /* 4V OV, 4 output LED string enabled */
+                rom_14h {
+                        rom-addr = /bits/ 8 <0x14>;
+                        rom-val = /bits/ 8 <0xcf>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt b/Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt
new file mode 100644
index 000000000000..5fb9279ac287
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt
@@ -0,0 +1,27 @@
+TPS65217 family of regulators
+
+The TPS65217 chip contains a boost converter and current sinks which can be
+used to drive LEDs for use as backlights.
+
+Required properties:
+- compatible: "ti,tps65217"
+- reg: I2C slave address
+- backlight: node for specifying WLED1 and WLED2 lines in TPS65217
+- isel: selection bit, valid values: 1 for ISEL1 (low-level) and 2 for ISEL2 (high-level)
+- fdim: PWM dimming frequency, valid values: 100, 200, 500, 1000
+- default-brightness: valid values: 0-100
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+        tps: tps@24 {
+                reg = <0x24>;
+                compatible = "ti,tps65217";
+                backlight {
+                        isel = <1>;  /* 1 - ISET1, 2 ISET2 */
+                        fdim = <100>; /* TPS65217_BL_FDIM_100HZ */
+                        default-brightness = <50>;
+                };
+        };
+
diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt
new file mode 100644
index 000000000000..778838a0336a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -0,0 +1,65 @@
+Device-Tree bindings for Samsung SoC display controller (FIMD)
+
+FIMD (Fully Interactive Mobile Display) is the Display Controller for the
+Samsung series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+                "samsung,s3c2443-fimd"; /* for S3C24XX SoCs */
+                "samsung,s3c6400-fimd"; /* for S3C64XX SoCs */
+                "samsung,s5p6440-fimd"; /* for S5P64X0 SoCs */
+                "samsung,s5pc100-fimd"; /* for S5PC100 SoC  */
+                "samsung,s5pv210-fimd"; /* for S5PV210 SoC */
+                "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
+                "samsung,exynos5250-fimd"; /* for Exynos5 SoCs */
+
+- reg: physical base address and length of the FIMD registers set.
+
+- interrupt-parent: should be the phandle of the fimd controller's
+                parent interrupt controller.
+
+- interrupts: should contain a list of all FIMD IP block interrupts in the
+                 order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+                 format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: "fifo", "vsync",
+        "lcd_sys", in the same order as they were listed in the interrupts
+        property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a "default" entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+         clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+               property. Must contain "sclk_fimd" and "fimd".
+
+Optional Properties:
+- samsung,power-domain: a phandle to FIMD power domain node.
+
+Example:
+
+SoC specific DT entry:
+
+        fimd@11c00000 {
+                compatible = "samsung,exynos4210-fimd";
+                interrupt-parent = <&combiner>;
+                reg = <0x11c00000 0x20000>;
+                interrupt-names = "fifo", "vsync", "lcd_sys";
+                interrupts = <11 0>, <11 1>, <11 2>;
+                clocks = <&clock 140>, <&clock 283>;
+                clock-names = "sclk_fimd", "fimd";
+                samsung,power-domain = <&pd_lcd0>;
+                status = "disabled";
+        };
+
+Board specific DT entry:
+
+        fimd@11c00000 {
+                pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>;
+                pinctrl-names = "default";
+                status = "okay";
+        };
diff --git a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
index c870b6478ec8..2871e218a0fb 100644
--- a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+++ b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
@@ -5,58 +5,32 @@ Required properties:
 - compatible : "via,vt8500-fb"
 - reg : Should contain 1 register ranges(address and length)
 - interrupts : framebuffer controller interrupt
-- display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
 
-Required nodes:
-- display: a display node is required to initialize the lcd panel
-        This should be in the board dts.
-- default-mode: a videomode within the display with timing parameters
-        as specified below.
+Required subnodes:
+- display-timings: see display-timing.txt for information
 
 Example:
 
-        fb@d800e400 {
+        fb@d8050800 {
                 compatible = "via,vt8500-fb";
                 reg = <0xd800e400 0x400>;
                 interrupts = <12>;
-                display = <&display>;
-                default-mode = <&mode0>;
-        };
-
-VIA VT8500 Display
------------------------------------------------------
-Required properties (as per of_videomode_helper):
-
- - hactive, vactive: Display resolution
- - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
-   in pixels
-   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
-   lines
- - clock: displayclock in Hz
- - bpp: lcd panel bit-depth.
-        <16> for RGB565, <32> for RGB888
-
-Optional properties (as per of_videomode_helper):
- - width-mm, height-mm: Display dimensions in mm
- - hsync-active-high (bool): Hsync pulse is active high
- - vsync-active-high (bool): Vsync pulse is active high
- - interlaced (bool): This is an interlaced mode
- - doublescan (bool): This is a doublescan mode
+                bits-per-pixel = <16>;
 
-Example:
-        display: display@0 {
-                modes {
-                        mode0: mode@0 {
+                display-timings {
+                        native-mode = <&timing0>;
+                        timing0: 800x480 {
+                                clock-frequency = <0>; /* unused but required */
                                 hactive = <800>;
                                 vactive = <480>;
-                                hback-porch = <88>;
                                 hfront-porch = <40>;
+                                hback-porch = <88>;
                                 hsync-len = <0>;
                                 vback-porch = <32>;
                                 vfront-porch = <11>;
                                 vsync-len = <1>;
-                                clock = <0>;    /* unused but required */
-                                bpp = <16>;     /* non-standard but required */
                         };
                 };
         };
+
diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
index 3d325e1d11ee..0bcadb2840a5 100644
--- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
+++ b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
@@ -4,20 +4,30 @@ Wondermedia WM8505 Framebuffer
 Required properties:
 - compatible : "wm,wm8505-fb"
 - reg : Should contain 1 register ranges(address and length)
-- via,display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
 
-Required nodes:
-- display: a display node is required to initialize the lcd panel
-        This should be in the board dts. See definition in
-        Documentation/devicetree/bindings/video/via,vt8500-fb.txt
-- default-mode: a videomode node as specified in
-        Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+Required subnodes:
+- display-timings: see display-timing.txt for information
 
 Example:
 
-        fb@d8050800 {
+        fb@d8051700 {
                 compatible = "wm,wm8505-fb";
-                reg = <0xd8050800 0x200>;
-                display = <&display>;
-                default-mode = <&mode0>;
+                reg = <0xd8051700 0x200>;
+                bits-per-pixel = <16>;
+
+                display-timings {
+                        native-mode = <&timing0>;
+                        timing0: 800x480 {
+                                clock-frequency = <0>; /* unused but required */
+                                hactive = <800>;
+                                vactive = <480>;
+                                hfront-porch = <40>;
+                                hback-porch = <88>;
+                                hsync-len = <0>;
+                                vback-porch = <32>;
+                                vfront-porch = <11>;
+                                vsync-len = <1>;
+                        };
+                };
         };
diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
index 0b2717775600..ecd650adff31 100644
--- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
@@ -1,13 +1,13 @@
-Allwinner sunXi Watchdog timer
+Allwinner sun4i Watchdog timer
 
 Required properties:
 
-- compatible : should be "allwinner,sunxi-wdt"
+- compatible : should be "allwinner,sun4i-wdt"
 - reg : Specifies base physical address and size of the registers.
 
 Example:
 
 wdt: watchdog@01c20c90 {
-        compatible = "allwinner,sunxi-wdt";
+        compatible = "allwinner,sun4i-wdt";
         reg = <0x01c20c90 0x10>;
 };
diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt
index 4966b1be42ac..0b23261561d2 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -52,14 +52,23 @@ The dma_buf buffer sharing API usage contains the following steps:
    associated with this buffer.
 
    Interface:
-      struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
-                                     size_t size, int flags)
+      struct dma_buf *dma_buf_export_named(void *priv, struct dma_buf_ops *ops,
+                                     size_t size, int flags,
+                                     const char *exp_name)
 
    If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a
    pointer to the same. It also associates an anonymous file with this buffer,
    so it can be exported. On failure to allocate the dma_buf object, it returns
    NULL.
 
+   'exp_name' is the name of exporter - to facilitate information while
+   debugging.
+
+   Exporting modules which do not wish to provide any specific name may use the
+   helper define 'dma_buf_export()', with the same arguments as above, but
+   without the last argument; a __FILE__ pre-processor directive will be
+   inserted in place of 'exp_name' instead.
+
 2. Userspace gets a handle to pass around to potential buffer-users
 
    Userspace entity requests for a file-descriptor (fd) which is a handle to the
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt
index 34ea4f1fa6ea..f7cbf574a875 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -494,6 +494,17 @@ Files in /sys/fs/ext4/<devname>
  session_write_kbytes         This file is read-only and shows the number of
                               kilobytes of data that have been written to this
                               filesystem since it was mounted.
+
+ reserved_clusters            This is RW file and contains number of reserved
+                              clusters in the file system which will be used
+                              in the specific situations to avoid costly
+                              zeroout, unexpected ENOSPC, or possible data
+                              loss. The default is 2% or 4096 clusters,
+                              whichever is smaller and this can be changed
+                              however it can never exceed number of clusters
+                              in the file system. If there is not enough space
+                              for the reserved space when mounting the file
+                              mount will _not_ fail.
 ..............................................................................
 
 Ioctls
@@ -587,6 +598,16 @@ Table of Ext4 specific ioctls
                               bitmaps and inode table, the userspace tool thus
                               just passes the new number of blocks.
 
+EXT4_IOC_SWAP_BOOT            Swap i_blocks and associated attributes
+                              (like i_blocks, i_size, i_flags, ...) from
+                              the specified inode with inode
+                              EXT4_BOOT_LOADER_INO (#5). This is typically
+                              used to store a boot loader in a secure part of
+                              the filesystem, where it can't be changed by a
+                              normal user by accident.
+                              The data blocks of the previous boot loader
+                              will be associated with the given inode.
+
 ..............................................................................
 
 References
diff --git a/Documentation/filesystems/nfs/00-INDEX b/Documentation/filesystems/nfs/00-INDEX
index 1716874a651e..66eb6c8c5334 100644
--- a/Documentation/filesystems/nfs/00-INDEX
+++ b/Documentation/filesystems/nfs/00-INDEX
@@ -20,3 +20,5 @@ rpc-cache.txt
         - introduction to the caching mechanisms in the sunrpc layer.
 idmapper.txt
         - information for configuring request-keys to be used by idmapper
+knfsd-rpcgss.txt
+        - Information on GSS authentication support in the NFS Server
diff --git a/Documentation/filesystems/nfs/rpc-server-gss.txt b/Documentation/filesystems/nfs/rpc-server-gss.txt
new file mode 100644
index 000000000000..716f4be8e8b3
--- /dev/null
+++ b/Documentation/filesystems/nfs/rpc-server-gss.txt
@@ -0,0 +1,91 @@
+
+rpcsec_gss support for kernel RPC servers
+=========================================
+
+This document gives references to the standards and protocols used to
+implement RPCGSS authentication in kernel RPC servers such as the NFS
+server and the NFS client's NFSv4.0 callback server.  (But note that
+NFSv4.1 and higher don't require the client to act as a server for the
+purposes of authentication.)
+
+RPCGSS is specified in a few IETF documents:
+ - RFC2203 v1: http://tools.ietf.org/rfc/rfc2203.txt
+ - RFC5403 v2: http://tools.ietf.org/rfc/rfc5403.txt
+and there is a 3rd version  being proposed:
+ - http://tools.ietf.org/id/draft-williams-rpcsecgssv3.txt
+   (At draft n. 02 at the time of writing)
+
+Background
+----------
+
+The RPCGSS Authentication method describes a way to perform GSSAPI
+Authentication for NFS.  Although GSSAPI is itself completely mechanism
+agnostic, in many cases only the KRB5 mechanism is supported by NFS
+implementations.
+
+The Linux kernel, at the moment, supports only the KRB5 mechanism, and
+depends on GSSAPI extensions that are KRB5 specific.
+
+GSSAPI is a complex library, and implementing it completely in kernel is
+unwarranted. However GSSAPI operations are fundementally separable in 2
+parts:
+- initial context establishment
+- integrity/privacy protection (signing and encrypting of individual
+  packets)
+
+The former is more complex and policy-independent, but less
+performance-sensitive.  The latter is simpler and needs to be very fast.
+
+Therefore, we perform per-packet integrity and privacy protection in the
+kernel, but leave the initial context establishment to userspace.  We
+need upcalls to request userspace to perform context establishment.
+
+NFS Server Legacy Upcall Mechanism
+----------------------------------
+
+The classic upcall mechanism uses a custom text based upcall mechanism
+to talk to a custom daemon called rpc.svcgssd that is provide by the
+nfs-utils package.
+
+This upcall mechanism has 2 limitations:
+
+A) It can handle tokens that are no bigger than 2KiB
+
+In some Kerberos deployment GSSAPI tokens can be quite big, up and
+beyond 64KiB in size due to various authorization extensions attacked to
+the Kerberos tickets, that needs to be sent through the GSS layer in
+order to perform context establishment.
+
+B) It does not properly handle creds where the user is member of more
+than a few housand groups (the current hard limit in the kernel is 65K
+groups) due to limitation on the size of the buffer that can be send
+back to the kernel (4KiB).
+
+NFS Server New RPC Upcall Mechanism
+-----------------------------------
+
+The newer upcall mechanism uses RPC over a unix socket to a daemon
+called gss-proxy, implemented by a userspace program called Gssproxy.
+
+The gss_proxy RPC protocol is currently documented here:
+
+        https://fedorahosted.org/gss-proxy/wiki/ProtocolDocumentation
+
+This upcall mechanism uses the kernel rpc client and connects to the gssproxy
+userspace program over a regular unix socket. The gssproxy protocol does not
+suffer from the size limitations of the legacy protocol.
+
+Negotiating Upcall Mechanisms
+-----------------------------
+
+To provide backward compatibility, the kernel defaults to using the
+legacy mechanism.  To switch to the new mechanism, gss-proxy must bind
+to /var/run/gssproxy.sock and then write "1" to
+/proc/net/rpc/use-gss-proxy.  If gss-proxy dies, it must repeat both
+steps.
+
+Once the upcall mechanism is chosen, it cannot be changed.  To prevent
+locking into the legacy mechanisms, the above steps must be performed
+before starting nfsd.  Whoever starts nfsd can guarantee this by reading
+from /proc/net/rpc/use-gss-proxy and checking that it contains a
+"1"--the read will block until gss-proxy has done its write to the file.
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index d230dd9c99b0..4a93e98b290a 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -150,12 +150,28 @@ discard       -- If set, issues discard/TRIM commands to the block
                  device when blocks are freed. This is useful for SSD devices
                  and sparse/thinly-provisoned LUNs.
 
-nfs           -- This option maintains an index (cache) of directory
-                 inodes by i_logstart which is used by the nfs-related code to
-                 improve look-ups.
+nfs=stale_rw|nostale_ro
+                Enable this only if you want to export the FAT filesystem
+                over NFS.
+
+                stale_rw: This option maintains an index (cache) of directory
+                inodes by i_logstart which is used by the nfs-related code to
+                improve look-ups. Full file operations (read/write) over NFS is
+                supported but with cache eviction at NFS server, this could
+                result in ESTALE issues.
+
+                nostale_ro: This option bases the inode number and filehandle
+                on the on-disk location of a file in the MS-DOS directory entry.
+                This ensures that ESTALE will not be returned after a file is
+                evicted from the inode cache. However, it means that operations
+                such as rename, create and unlink could cause filehandles that
+                previously pointed at one file to point at a different file,
+                potentially causing data corruption. For this reason, this
+                option also mounts the filesystem readonly.
+
+                To maintain backward compatibility, '-o nfs' is also accepted,
+                defaulting to stale_rw
 
-                 Enable this only if you want to export the FAT filesystem
-                 over NFS
 
 <bool>: 0,1,yes,no,true,false
 
diff --git a/Documentation/filesystems/xfs-self-describing-metadata.txt b/Documentation/filesystems/xfs-self-describing-metadata.txt
new file mode 100644
index 000000000000..05aa455163e3
--- /dev/null
+++ b/Documentation/filesystems/xfs-self-describing-metadata.txt
@@ -0,0 +1,350 @@
+XFS Self Describing Metadata
+----------------------------
+
+Introduction
+------------
+
+The largest scalability problem facing XFS is not one of algorithmic
+scalability, but of verification of the filesystem structure. Scalabilty of the
+structures and indexes on disk and the algorithms for iterating them are
+adequate for supporting PB scale filesystems with billions of inodes, however it
+is this very scalability that causes the verification problem.
+
+Almost all metadata on XFS is dynamically allocated. The only fixed location
+metadata is the allocation group headers (SB, AGF, AGFL and AGI), while all
+other metadata structures need to be discovered by walking the filesystem
+structure in different ways. While this is already done by userspace tools for
+validating and repairing the structure, there are limits to what they can
+verify, and this in turn limits the supportable size of an XFS filesystem.
+
+For example, it is entirely possible to manually use xfs_db and a bit of
+scripting to analyse the structure of a 100TB filesystem when trying to
+determine the root cause of a corruption problem, but it is still mainly a
+manual task of verifying that things like single bit errors or misplaced writes
+weren't the ultimate cause of a corruption event. It may take a few hours to a
+few days to perform such forensic analysis, so for at this scale root cause
+analysis is entirely possible.
+
+However, if we scale the filesystem up to 1PB, we now have 10x as much metadata
+to analyse and so that analysis blows out towards weeks/months of forensic work.
+Most of the analysis work is slow and tedious, so as the amount of analysis goes
+up, the more likely that the cause will be lost in the noise.  Hence the primary
+concern for supporting PB scale filesystems is minimising the time and effort
+required for basic forensic analysis of the filesystem structure.
+
+
+Self Describing Metadata
+------------------------
+
+One of the problems with the current metadata format is that apart from the
+magic number in the metadata block, we have no other way of identifying what it
+is supposed to be. We can't even identify if it is the right place. Put simply,
+you can't look at a single metadata block in isolation and say "yes, it is
+supposed to be there and the contents are valid".
+
+Hence most of the time spent on forensic analysis is spent doing basic
+verification of metadata values, looking for values that are in range (and hence
+not detected by automated verification checks) but are not correct. Finding and
+understanding how things like cross linked block lists (e.g. sibling
+pointers in a btree end up with loops in them) are the key to understanding what
+went wrong, but it is impossible to tell what order the blocks were linked into
+each other or written to disk after the fact.
+
+Hence we need to record more information into the metadata to allow us to
+quickly determine if the metadata is intact and can be ignored for the purpose
+of analysis. We can't protect against every possible type of error, but we can
+ensure that common types of errors are easily detectable.  Hence the concept of
+self describing metadata.
+
+The first, fundamental requirement of self describing metadata is that the
+metadata object contains some form of unique identifier in a well known
+location. This allows us to identify the expected contents of the block and
+hence parse and verify the metadata object. IF we can't independently identify
+the type of metadata in the object, then the metadata doesn't describe itself
+very well at all!
+
+Luckily, almost all XFS metadata has magic numbers embedded already - only the
+AGFL, remote symlinks and remote attribute blocks do not contain identifying
+magic numbers. Hence we can change the on-disk format of all these objects to
+add more identifying information and detect this simply by changing the magic
+numbers in the metadata objects. That is, if it has the current magic number,
+the metadata isn't self identifying. If it contains a new magic number, it is
+self identifying and we can do much more expansive automated verification of the
+metadata object at runtime, during forensic analysis or repair.
+
+As a primary concern, self describing metadata needs some form of overall
+integrity checking. We cannot trust the metadata if we cannot verify that it has
+not been changed as a result of external influences. Hence we need some form of
+integrity check, and this is done by adding CRC32c validation to the metadata
+block. If we can verify the block contains the metadata it was intended to
+contain, a large amount of the manual verification work can be skipped.
+
+CRC32c was selected as metadata cannot be more than 64k in length in XFS and
+hence a 32 bit CRC is more than sufficient to detect multi-bit errors in
+metadata blocks. CRC32c is also now hardware accelerated on common CPUs so it is
+fast. So while CRC32c is not the strongest of possible integrity checks that
+could be used, it is more than sufficient for our needs and has relatively
+little overhead. Adding support for larger integrity fields and/or algorithms
+does really provide any extra value over CRC32c, but it does add a lot of
+complexity and so there is no provision for changing the integrity checking
+mechanism.
+
+Self describing metadata needs to contain enough information so that the
+metadata block can be verified as being in the correct place without needing to
+look at any other metadata. This means it needs to contain location information.
+Just adding a block number to the metadata is not sufficient to protect against
+mis-directed writes - a write might be misdirected to the wrong LUN and so be
+written to the "correct block" of the wrong filesystem. Hence location
+information must contain a filesystem identifier as well as a block number.
+
+Another key information point in forensic analysis is knowing who the metadata
+block belongs to. We already know the type, the location, that it is valid
+and/or corrupted, and how long ago that it was last modified. Knowing the owner
+of the block is important as it allows us to find other related metadata to
+determine the scope of the corruption. For example, if we have a extent btree
+object, we don't know what inode it belongs to and hence have to walk the entire
+filesystem to find the owner of the block. Worse, the corruption could mean that
+no owner can be found (i.e. it's an orphan block), and so without an owner field
+in the metadata we have no idea of the scope of the corruption. If we have an
+owner field in the metadata object, we can immediately do top down validation to
+determine the scope of the problem.
+
+Different types of metadata have different owner identifiers. For example,
+directory, attribute and extent tree blocks are all owned by an inode, whilst
+freespace btree blocks are owned by an allocation group. Hence the size and
+contents of the owner field are determined by the type of metadata object we are
+looking at.  The owner information can also identify misplaced writes (e.g.
+freespace btree block written to the wrong AG).
+
+Self describing metadata also needs to contain some indication of when it was
+written to the filesystem. One of the key information points when doing forensic
+analysis is how recently the block was modified. Correlation of set of corrupted
+metadata blocks based on modification times is important as it can indicate
+whether the corruptions are related, whether there's been multiple corruption
+events that lead to the eventual failure, and even whether there are corruptions
+present that the run-time verification is not detecting.
+
+For example, we can determine whether a metadata object is supposed to be free
+space or still allocated if it is still referenced by its owner by looking at
+when the free space btree block that contains the block was last written
+compared to when the metadata object itself was last written.  If the free space
+block is more recent than the object and the object's owner, then there is a
+very good chance that the block should have been removed from the owner.
+
+To provide this "written timestamp", each metadata block gets the Log Sequence
+Number (LSN) of the most recent transaction it was modified on written into it.
+This number will always increase over the life of the filesystem, and the only
+thing that resets it is running xfs_repair on the filesystem. Further, by use of
+the LSN we can tell if the corrupted metadata all belonged to the same log
+checkpoint and hence have some idea of how much modification occurred between
+the first and last instance of corrupt metadata on disk and, further, how much
+modification occurred between the corruption being written and when it was
+detected.
+
+Runtime Validation
+------------------
+
+Validation of self-describing metadata takes place at runtime in two places:
+
+        - immediately after a successful read from disk
+        - immediately prior to write IO submission
+
+The verification is completely stateless - it is done independently of the
+modification process, and seeks only to check that the metadata is what it says
+it is and that the metadata fields are within bounds and internally consistent.
+As such, we cannot catch all types of corruption that can occur within a block
+as there may be certain limitations that operational state enforces of the
+metadata, or there may be corruption of interblock relationships (e.g. corrupted
+sibling pointer lists). Hence we still need stateful checking in the main code
+body, but in general most of the per-field validation is handled by the
+verifiers.
+
+For read verification, the caller needs to specify the expected type of metadata
+that it should see, and the IO completion process verifies that the metadata
+object matches what was expected. If the verification process fails, then it
+marks the object being read as EFSCORRUPTED. The caller needs to catch this
+error (same as for IO errors), and if it needs to take special action due to a
+verification error it can do so by catching the EFSCORRUPTED error value. If we
+need more discrimination of error type at higher levels, we can define new
+error numbers for different errors as necessary.
+
+The first step in read verification is checking the magic number and determining
+whether CRC validating is necessary. If it is, the CRC32c is calculated and
+compared against the value stored in the object itself. Once this is validated,
+further checks are made against the location information, followed by extensive
+object specific metadata validation. If any of these checks fail, then the
+buffer is considered corrupt and the EFSCORRUPTED error is set appropriately.
+
+Write verification is the opposite of the read verification - first the object
+is extensively verified and if it is OK we then update the LSN from the last
+modification made to the object, After this, we calculate the CRC and insert it
+into the object. Once this is done the write IO is allowed to continue. If any
+error occurs during this process, the buffer is again marked with a EFSCORRUPTED
+error for the higher layers to catch.
+
+Structures
+----------
+
+A typical on-disk structure needs to contain the following information:
+
+struct xfs_ondisk_hdr {
+        __be32  magic;          /* magic number */
+        __be32  crc;            /* CRC, not logged */
+        uuid_t  uuid;           /* filesystem identifier */
+        __be64  owner;          /* parent object */
+        __be64  blkno;          /* location on disk */
+        __be64  lsn;            /* last modification in log, not logged */
+};
+
+Depending on the metadata, this information may be part of a header structure
+separate to the metadata contents, or may be distributed through an existing
+structure. The latter occurs with metadata that already contains some of this
+information, such as the superblock and AG headers.
+
+Other metadata may have different formats for the information, but the same
+level of information is generally provided. For example:
+
+        - short btree blocks have a 32 bit owner (ag number) and a 32 bit block
+          number for location. The two of these combined provide the same
+          information as @owner and @blkno in eh above structure, but using 8
+          bytes less space on disk.
+
+        - directory/attribute node blocks have a 16 bit magic number, and the
+          header that contains the magic number has other information in it as
+          well. hence the additional metadata headers change the overall format
+          of the metadata.
+
+A typical buffer read verifier is structured as follows:
+
+#define XFS_FOO_CRC_OFF         offsetof(struct xfs_ondisk_hdr, crc)
+
+static void
+xfs_foo_read_verify(
+        struct xfs_buf  *bp)
+{
+       struct xfs_mount *mp = bp->b_target->bt_mount;
+
+        if ((xfs_sb_version_hascrc(&mp->m_sb) &&
+             !xfs_verify_cksum(bp->b_addr, BBTOB(bp->b_length),
+                                        XFS_FOO_CRC_OFF)) ||
+            !xfs_foo_verify(bp)) {
+                XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, bp->b_addr);
+                xfs_buf_ioerror(bp, EFSCORRUPTED);
+        }
+}
+
+The code ensures that the CRC is only checked if the filesystem has CRCs enabled
+by checking the superblock of the feature bit, and then if the CRC verifies OK
+(or is not needed) it verifies the actual contents of the block.
+
+The verifier function will take a couple of different forms, depending on
+whether the magic number can be used to determine the format of the block. In
+the case it can't, the code is structured as follows:
+
+static bool
+xfs_foo_verify(
+        struct xfs_buf          *bp)
+{
+        struct xfs_mount        *mp = bp->b_target->bt_mount;
+        struct xfs_ondisk_hdr   *hdr = bp->b_addr;
+
+        if (hdr->magic != cpu_to_be32(XFS_FOO_MAGIC))
+                return false;
+
+        if (!xfs_sb_version_hascrc(&mp->m_sb)) {
+                if (!uuid_equal(&hdr->uuid, &mp->m_sb.sb_uuid))
+                        return false;
+                if (bp->b_bn != be64_to_cpu(hdr->blkno))
+                        return false;
+                if (hdr->owner == 0)
+                        return false;
+        }
+
+        /* object specific verification checks here */
+
+        return true;
+}
+
+If there are different magic numbers for the different formats, the verifier
+will look like:
+
+static bool
+xfs_foo_verify(
+        struct xfs_buf          *bp)
+{
+        struct xfs_mount        *mp = bp->b_target->bt_mount;
+        struct xfs_ondisk_hdr   *hdr = bp->b_addr;
+
+        if (hdr->magic == cpu_to_be32(XFS_FOO_CRC_MAGIC)) {
+                if (!uuid_equal(&hdr->uuid, &mp->m_sb.sb_uuid))
+                        return false;
+                if (bp->b_bn != be64_to_cpu(hdr->blkno))
+                        return false;
+                if (hdr->owner == 0)
+                        return false;
+        } else if (hdr->magic != cpu_to_be32(XFS_FOO_MAGIC))
+                return false;
+
+        /* object specific verification checks here */
+
+        return true;
+}
+
+Write verifiers are very similar to the read verifiers, they just do things in
+the opposite order to the read verifiers. A typical write verifier:
+
+static void
+xfs_foo_write_verify(
+        struct xfs_buf  *bp)
+{
+        struct xfs_mount        *mp = bp->b_target->bt_mount;
+        struct xfs_buf_log_item *bip = bp->b_fspriv;
+
+        if (!xfs_foo_verify(bp)) {
+                XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, bp->b_addr);
+                xfs_buf_ioerror(bp, EFSCORRUPTED);
+                return;
+        }
+
+        if (!xfs_sb_version_hascrc(&mp->m_sb))
+                return;
+
+
+        if (bip) {
+                struct xfs_ondisk_hdr   *hdr = bp->b_addr;
+                hdr->lsn = cpu_to_be64(bip->bli_item.li_lsn);
+        }
+        xfs_update_cksum(bp->b_addr, BBTOB(bp->b_length), XFS_FOO_CRC_OFF);
+}
+
+This will verify the internal structure of the metadata before we go any
+further, detecting corruptions that have occurred as the metadata has been
+modified in memory. If the metadata verifies OK, and CRCs are enabled, we then
+update the LSN field (when it was last modified) and calculate the CRC on the
+metadata. Once this is done, we can issue the IO.
+
+Inodes and Dquots
+-----------------
+
+Inodes and dquots are special snowflakes. They have per-object CRC and
+self-identifiers, but they are packed so that there are multiple objects per
+buffer. Hence we do not use per-buffer verifiers to do the work of per-object
+verification and CRC calculations. The per-buffer verifiers simply perform basic
+identification of the buffer - that they contain inodes or dquots, and that
+there are magic numbers in all the expected spots. All further CRC and
+verification checks are done when each inode is read from or written back to the
+buffer.
+
+The structure of the verifiers and the identifiers checks is very similar to the
+buffer code described above. The only difference is where they are called. For
+example, inode read verification is done in xfs_iread() when the inode is first
+read out of the buffer and the struct xfs_inode is instantiated. The inode is
+already extensively verified during writeback in xfs_iflush_int, so the only
+addition here is to add the LSN and CRC to the inode as it is copied back into
+the buffer.
+
+XXX: inode unlinked list modification doesn't recalculate the inode CRC! None of
+the unlinked list modifications check or update CRCs, neither during unlink nor
+log recovery. So, it's gone unnoticed until now. This won't matter immediately -
+repair will probably complain about it - but it needs to be fixed.
+
diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt
index 690f52550c80..026e237bbc87 100644
--- a/Documentation/hw_random.txt
+++ b/Documentation/hw_random.txt
@@ -63,7 +63,7 @@ Intel RNG Driver notes:
 
         * FIXME: support poll(2)
 
-        NOTE: request_mem_region was removed, for two reasons:
+        NOTE: request_mem_region was removed, for three reasons:
         1) Only one RNG is supported by this driver, 2) The location
         used by the RNG is a fixed location in MMIO-addressable memory,
         3) users with properly working BIOS e820 handling will always
diff --git a/Documentation/hwmon/ab8500 b/Documentation/hwmon/ab8500
new file mode 100644
index 000000000000..cf169c8ef4e3
--- /dev/null
+++ b/Documentation/hwmon/ab8500
@@ -0,0 +1,22 @@
+Kernel driver ab8500
+====================
+
+Supported chips:
+  * ST-Ericsson AB8500
+    Prefix: 'ab8500'
+    Addresses scanned: -
+    Datasheet: http://www.stericsson.com/developers/documentation.jsp
+
+Authors:
+        Martin Persson <martin.persson@stericsson.com>
+        Hongbo Zhang <hongbo.zhang@linaro.org>
+
+Description
+-----------
+
+See also Documentation/hwmon/abx500. This is the ST-Ericsson AB8500 specific
+driver.
+
+Currently only the AB8500 internal sensor and one external sensor for battery
+temperature are monitored. Other GPADC channels can also be monitored if needed
+in future.
diff --git a/Documentation/hwmon/abx500 b/Documentation/hwmon/abx500
new file mode 100644
index 000000000000..319a058cec7c
--- /dev/null
+++ b/Documentation/hwmon/abx500
@@ -0,0 +1,28 @@
+Kernel driver abx500
+====================
+
+Supported chips:
+  * ST-Ericsson ABx500 series
+    Prefix: 'abx500'
+    Addresses scanned: -
+    Datasheet: http://www.stericsson.com/developers/documentation.jsp
+
+Authors:
+        Martin Persson <martin.persson@stericsson.com>
+        Hongbo Zhang <hongbo.zhang@linaro.org>
+
+Description
+-----------
+
+Every ST-Ericsson Ux500 SOC consists of both ABx500 and DBx500 physically,
+this is kernel hwmon driver for ABx500.
+
+There are some GPADCs inside ABx500 which are designed for connecting to
+thermal sensors, and there is also a thermal sensor inside ABx500 too, which
+raises interrupt when critical temperature reached.
+
+This abx500 is a common layer which can monitor all of the sensors, every
+specific abx500 chip has its special configurations in its own file, e.g. some
+sensors can be configured invisible if they are not available on that chip, and
+the corresponding gpadc_addr should be set to 0, thus this sensor won't be
+polled.
diff --git a/Documentation/hwmon/adm1275 b/Documentation/hwmon/adm1275
index 2cfa25667123..15b4a20d5062 100644
--- a/Documentation/hwmon/adm1275
+++ b/Documentation/hwmon/adm1275
@@ -15,7 +15,7 @@ Supported chips:
     Addresses scanned: -
     Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1276.pdf
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/adt7410 b/Documentation/hwmon/adt7410
index 96004000dc2a..9817941e5f19 100644
--- a/Documentation/hwmon/adt7410
+++ b/Documentation/hwmon/adt7410
@@ -4,28 +4,50 @@ Kernel driver adt7410
 Supported chips:
   * Analog Devices ADT7410
     Prefix: 'adt7410'
-    Addresses scanned: I2C 0x48 - 0x4B
+    Addresses scanned: None
     Datasheet: Publicly available at the Analog Devices website
                http://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf
+  * Analog Devices ADT7420
+    Prefix: 'adt7420'
+    Addresses scanned: None
+    Datasheet: Publicly available at the Analog Devices website
+               http://www.analog.com/static/imported-files/data_sheets/ADT7420.pdf
+  * Analog Devices ADT7310
+    Prefix: 'adt7310'
+    Addresses scanned: None
+    Datasheet: Publicly available at the Analog Devices website
+               http://www.analog.com/static/imported-files/data_sheets/ADT7310.pdf
+  * Analog Devices ADT7320
+    Prefix: 'adt7320'
+    Addresses scanned: None
+    Datasheet: Publicly available at the Analog Devices website
+               http://www.analog.com/static/imported-files/data_sheets/ADT7320.pdf
 
 Author: Hartmut Knaack <knaack.h@gmx.de>
 
 Description
 -----------
 
-The ADT7410 is a temperature sensor with rated temperature range of -55°C to
-+150°C. It has a high accuracy of +/-0.5°C and can be operated at a resolution
-of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an INT pin to
-indicate that a minimum or maximum temperature set point has been exceeded, as
-well as a critical temperature (CT) pin to indicate that the critical
-temperature set point has been exceeded. Both pins can be set up with a common
-hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events. Both
-pins can individually set to be active-low or active-high, while the whole
-device can either run in comparator mode or interrupt mode. The ADT7410
-supports continous temperature sampling, as well as sampling one temperature
-value per second or even justget one sample on demand for power saving.
-Besides, it can completely power down its ADC, if power management is
-required.
+The ADT7310/ADT7410 is a temperature sensor with rated temperature range of
+-55°C to +150°C. It has a high accuracy of +/-0.5°C and can be operated at a
+resolution of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an
+INT pin to indicate that a minimum or maximum temperature set point has been
+exceeded, as well as a critical temperature (CT) pin to indicate that the
+critical temperature set point has been exceeded. Both pins can be set up with a
+common hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events.
+Both pins can individually set to be active-low or active-high, while the whole
+device can either run in comparator mode or interrupt mode. The ADT7410 supports
+continuous temperature sampling, as well as sampling one temperature value per
+second or even just get one sample on demand for power saving. Besides, it can
+completely power down its ADC, if power management is required.
+
+The ADT7320/ADT7420 is register compatible, the only differences being the
+package, a slightly narrower operating temperature range (-40°C to +150°C), and
+a better accuracy (0.25°C instead of 0.50°C.)
+
+The difference between the ADT7310/ADT7320 and ADT7410/ADT7420 is the control
+interface, the ADT7310 and ADT7320 use SPI while the ADT7410 and ADT7420 use
+I2C.
 
 Configuration Notes
 -------------------
diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42
index 165077121238..868d74d6b773 100644
--- a/Documentation/hwmon/jc42
+++ b/Documentation/hwmon/jc42
@@ -49,7 +49,7 @@ Supported chips:
     Addresses scanned: I2C 0x18 - 0x1f
 
 Author:
-        Guenter Roeck <guenter.roeck@ericsson.com>
+        Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/lineage-pem b/Documentation/hwmon/lineage-pem
index 2ba5ed126858..83b2ddc160c8 100644
--- a/Documentation/hwmon/lineage-pem
+++ b/Documentation/hwmon/lineage-pem
@@ -8,7 +8,7 @@ Supported devices:
     Documentation:
         http://www.lineagepower.com/oem/pdf/CPLI2C.pdf
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/lm25066 b/Documentation/hwmon/lm25066
index a21db81c4591..c1b57d72efc3 100644
--- a/Documentation/hwmon/lm25066
+++ b/Documentation/hwmon/lm25066
@@ -1,7 +1,13 @@
-Kernel driver max8688
+Kernel driver lm25066
 =====================
 
 Supported chips:
+  * TI LM25056
+    Prefix: 'lm25056'
+    Addresses scanned: -
+    Datasheets:
+        http://www.ti.com/lit/gpn/lm25056
+        http://www.ti.com/lit/gpn/lm25056a
   * National Semiconductor LM25066
     Prefix: 'lm25066'
     Addresses scanned: -
@@ -19,14 +25,15 @@ Supported chips:
     Datasheet:
         http://www.national.com/pf/LM/LM5066.html
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
 -----------
 
-This driver supports hardware montoring for National Semiconductor LM25066,
-LM5064, and LM5064 Power Management, Monitoring, Control, and Protection ICs.
+This driver supports hardware montoring for National Semiconductor / TI LM25056,
+LM25066, LM5064, and LM5064 Power Management, Monitoring, Control, and
+Protection ICs.
 
 The driver is a client driver to the core PMBus driver. Please see
 Documentation/hwmon/pmbus for details on PMBus client drivers.
@@ -60,14 +67,19 @@ in1_max			Maximum input voltage.
 in1_min_alarm           Input voltage low alarm.
 in1_max_alarm           Input voltage high alarm.
 
-in2_label               "vout1"
-in2_input               Measured output voltage.
-in2_average             Average measured output voltage.
-in2_min                 Minimum output voltage.
-in2_min_alarm           Output voltage low alarm.
-
-in3_label               "vout2"
-in3_input               Measured voltage on vaux pin
+in2_label               "vmon"
+in2_input               Measured voltage on VAUX pin
+in2_min                 Minimum VAUX voltage (LM25056 only).
+in2_max                 Maximum VAUX voltage (LM25056 only).
+in2_min_alarm           VAUX voltage low alarm (LM25056 only).
+in2_max_alarm           VAUX voltage high alarm (LM25056 only).
+
+in3_label               "vout1"
+                        Not supported on LM25056.
+in3_input               Measured output voltage.
+in3_average             Average measured output voltage.
+in3_min                 Minimum output voltage.
+in3_min_alarm           Output voltage low alarm.
 
 curr1_label             "iin"
 curr1_input             Measured input current.
diff --git a/Documentation/hwmon/lm75 b/Documentation/hwmon/lm75
index c91a1d15fa28..2560a9c6d445 100644
--- a/Documentation/hwmon/lm75
+++ b/Documentation/hwmon/lm75
@@ -12,18 +12,18 @@ Supported chips:
     Addresses scanned: I2C 0x48 - 0x4f
     Datasheet: Publicly available at the National Semiconductor website
                http://www.national.com/
-  * Dallas Semiconductor DS75, DS1775
-    Prefixes: 'ds75', 'ds1775'
+  * Dallas Semiconductor (now Maxim) DS75, DS1775, DS7505
+    Prefixes: 'ds75', 'ds1775', 'ds7505'
     Addresses scanned: none
-    Datasheet: Publicly available at the Dallas Semiconductor website
-               http://www.maxim-ic.com/
+    Datasheet: Publicly available at the Maxim website
+               http://www.maximintegrated.com/
   * Maxim MAX6625, MAX6626
     Prefixes: 'max6625', 'max6626'
     Addresses scanned: none
     Datasheet: Publicly available at the Maxim website
                http://www.maxim-ic.com/
   * Microchip (TelCom) TCN75
-    Prefix: 'lm75'
+    Prefix: 'tcn75'
     Addresses scanned: none
     Datasheet: Publicly available at the Microchip website
                http://www.microchip.com/
@@ -67,7 +67,8 @@ the temperature falls below the Hysteresis value.
 All temperatures are in degrees Celsius, and are guaranteed within a
 range of -55 to +125 degrees.
 
-The LM75 only updates its values each 1.5 seconds; reading it more often
+The driver caches the values for a period varying between 1 second for the
+slowest chips and 125 ms for the fastest chips; reading it more often
 will do no harm, but will return 'old' values.
 
 The original LM75 was typically used in combination with LM78-like chips
@@ -78,8 +79,8 @@ The LM75 is essentially an industry standard; there may be other
 LM75 clones not listed here, with or without various enhancements,
 that are supported. The clones are not detected by the driver, unless
 they reproduce the exact register tricks of the original LM75, and must
-therefore be instantiated explicitly. The specific enhancements (such as
-higher resolution) are not currently supported by the driver.
+therefore be instantiated explicitly. Higher resolution up to 12-bit
+is supported by this driver, other specific enhancements are not.
 
 The LM77 is not supported, contrary to what we pretended for a long time.
 Both chips are simply not compatible, value encoding differs.
diff --git a/Documentation/hwmon/lm95234 b/Documentation/hwmon/lm95234
new file mode 100644
index 000000000000..a0e95ddfd372
--- /dev/null
+++ b/Documentation/hwmon/lm95234
@@ -0,0 +1,36 @@
+Kernel driver lm95234
+=====================
+
+Supported chips:
+  * National Semiconductor / Texas Instruments LM95234
+    Addresses scanned: I2C 0x18, 0x4d, 0x4e
+    Datasheet: Publicly available at the Texas Instruments website
+               http://www.ti.com/product/lm95234
+
+
+Author: Guenter Roeck <linux@roeck-us.net>
+
+Description
+-----------
+
+LM95234 is an 11-bit digital temperature sensor with a 2-wire System Management
+Bus (SMBus) interface and TrueTherm technology that can very accurately monitor
+the temperature of four remote diodes as well as its own temperature.
+The four remote diodes can be external devices such as microprocessors,
+graphics processors or diode-connected 2N3904s. The LM95234's TruTherm
+beta compensation technology allows sensing of 90 nm or 65 nm process
+thermal diodes accurately.
+
+All temperature values are given in millidegrees Celsius. Temperature
+is provided within a range of -127 to +255 degrees (+127.875 degrees for
+the internal sensor). Resolution depends on temperature input and range.
+
+Each sensor has its own maximum limit, but the hysteresis is common to all
+channels. The hysteresis is configurable with the tem1_max_hyst attribute and
+affects the hysteresis on all channels. The first two external sensors also
+have a critical limit.
+
+The lm95234 driver can change its update interval to a fixed set of values.
+It will round up to the next selectable interval. See the datasheet for exact
+values. Reading sensor values more often will do no harm, but will return
+'old' values.
diff --git a/Documentation/hwmon/ltc2978 b/Documentation/hwmon/ltc2978
index c365f9beb5dd..dc0d08c61305 100644
--- a/Documentation/hwmon/ltc2978
+++ b/Documentation/hwmon/ltc2978
@@ -2,24 +2,32 @@ Kernel driver ltc2978
 =====================
 
 Supported chips:
+  * Linear Technology LTC2974
+    Prefix: 'ltc2974'
+    Addresses scanned: -
+    Datasheet: http://www.linear.com/product/ltc2974
   * Linear Technology LTC2978
     Prefix: 'ltc2978'
     Addresses scanned: -
-    Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
+    Datasheet: http://www.linear.com/product/ltc2978
   * Linear Technology LTC3880
     Prefix: 'ltc3880'
     Addresses scanned: -
-    Datasheet: http://cds.linear.com/docs/Datasheet/3880f.pdf
+    Datasheet: http://www.linear.com/product/ltc3880
+  * Linear Technology LTC3883
+    Prefix: 'ltc3883'
+    Addresses scanned: -
+    Datasheet: http://www.linear.com/product/ltc3883
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
 -----------
 
-The LTC2978 is an octal power supply monitor, supervisor, sequencer and
-margin controller. The LTC3880 is a dual, PolyPhase DC/DC synchronous
-step-down switching regulator controller.
+LTC2974 is a quad digital power supply manager. LTC2978 is an octal power supply
+monitor. LTC3880 is a dual output poly-phase step-down DC/DC controller. LTC3883
+is a single phase step-down DC/DC controller.
 
 
 Usage Notes
@@ -41,63 +49,90 @@ Sysfs attributes
 in1_label               "vin"
 in1_input               Measured input voltage.
 in1_min                 Minimum input voltage.
-in1_max                 Maximum input voltage.
-in1_lcrit               Critical minimum input voltage.
+in1_max                 Maximum input voltage. LTC2974 and LTC2978 only.
+in1_lcrit               Critical minimum input voltage. LTC2974 and LTC2978
+                        only.
 in1_crit                Critical maximum input voltage.
 in1_min_alarm           Input voltage low alarm.
-in1_max_alarm           Input voltage high alarm.
-in1_lcrit_alarm         Input voltage critical low alarm.
+in1_max_alarm           Input voltage high alarm. LTC2974 and LTC2978 only.
+in1_lcrit_alarm         Input voltage critical low alarm. LTC2974 and LTC2978
+                        only.
 in1_crit_alarm          Input voltage critical high alarm.
-in1_lowest              Lowest input voltage. LTC2978 only.
+in1_lowest              Lowest input voltage. LTC2974 and LTC2978 only.
 in1_highest             Highest input voltage.
-in1_reset_history       Reset history. Writing into this attribute will reset
-                        history for all attributes.
-
-in[2-9]_label           "vout[1-8]". Channels 3 to 9 on LTC2978 only.
-in[2-9]_input           Measured output voltage.
-in[2-9]_min             Minimum output voltage.
-in[2-9]_max             Maximum output voltage.
-in[2-9]_lcrit           Critical minimum output voltage.
-in[2-9]_crit            Critical maximum output voltage.
-in[2-9]_min_alarm       Output voltage low alarm.
-in[2-9]_max_alarm       Output voltage high alarm.
-in[2-9]_lcrit_alarm     Output voltage critical low alarm.
-in[2-9]_crit_alarm      Output voltage critical high alarm.
-in[2-9]_lowest          Lowest output voltage. LTC2978 only.
-in[2-9]_highest         Lowest output voltage.
-in[2-9]_reset_history   Reset history. Writing into this attribute will reset
-                        history for all attributes.
-
-temp[1-3]_input         Measured temperature.
+in1_reset_history       Reset input voltage history.
+
+in[N]_label             "vout[1-8]".
+                        LTC2974: N=2-5
+                        LTC2978: N=2-9
+                        LTC3880: N=2-3
+                        LTC3883: N=2
+in[N]_input             Measured output voltage.
+in[N]_min               Minimum output voltage.
+in[N]_max               Maximum output voltage.
+in[N]_lcrit             Critical minimum output voltage.
+in[N]_crit              Critical maximum output voltage.
+in[N]_min_alarm         Output voltage low alarm.
+in[N]_max_alarm         Output voltage high alarm.
+in[N]_lcrit_alarm       Output voltage critical low alarm.
+in[N]_crit_alarm        Output voltage critical high alarm.
+in[N]_lowest            Lowest output voltage. LTC2974 and LTC2978 only.
+in[N]_highest           Highest output voltage.
+in[N]_reset_history     Reset output voltage history.
+
+temp[N]_input           Measured temperature.
+                        On LTC2974, temp[1-4] report external temperatures,
+                        and temp5 reports the chip temperature.
                         On LTC2978, only one temperature measurement is
-                        supported and reflects the internal temperature.
+                        supported and reports the chip temperature.
                         On LTC3880, temp1 and temp2 report external
-                        temperatures, and temp3 reports the internal
-                        temperature.
-temp[1-3]_min           Mimimum temperature.
-temp[1-3]_max           Maximum temperature.
-temp[1-3]_lcrit         Critical low temperature.
-temp[1-3]_crit          Critical high temperature.
-temp[1-3]_min_alarm     Chip temperature low alarm.
-temp[1-3]_max_alarm     Chip temperature high alarm.
-temp[1-3]_lcrit_alarm   Chip temperature critical low alarm.
-temp[1-3]_crit_alarm    Chip temperature critical high alarm.
-temp[1-3]_lowest        Lowest measured temperature. LTC2978 only.
-temp[1-3]_highest       Highest measured temperature.
-temp[1-3]_reset_history Reset history. Writing into this attribute will reset
-                        history for all attributes.
-
-power[1-2]_label        "pout[1-2]". LTC3880 only.
-power[1-2]_input        Measured power.
-
-curr1_label             "iin". LTC3880 only.
+                        temperatures, and temp3 reports the chip temperature.
+                        On LTC3883, temp1 reports an external temperature,
+                        and temp2 reports the chip temperature.
+temp[N]_min             Mimimum temperature. LTC2974 and LTC2978 only.
+temp[N]_max             Maximum temperature.
+temp[N]_lcrit           Critical low temperature.
+temp[N]_crit            Critical high temperature.
+temp[N]_min_alarm       Temperature low alarm. LTC2974 and LTC2978 only.
+temp[N]_max_alarm       Temperature high alarm.
+temp[N]_lcrit_alarm     Temperature critical low alarm.
+temp[N]_crit_alarm      Temperature critical high alarm.
+temp[N]_lowest          Lowest measured temperature. LTC2974 and LTC2978 only.
+                        Not supported for chip temperature sensor on LTC2974.
+temp[N]_highest         Highest measured temperature. Not supported for chip
+                        temperature sensor on LTC2974.
+temp[N]_reset_history   Reset temperature history. Not supported for chip
+                        temperature sensor on LTC2974.
+
+power1_label            "pin". LTC3883 only.
+power1_input            Measured input power.
+
+power[N]_label          "pout[1-4]".
+                        LTC2974: N=1-4
+                        LTC2978: Not supported
+                        LTC3880: N=1-2
+                        LTC3883: N=2
+power[N]_input          Measured output power.
+
+curr1_label             "iin". LTC3880 and LTC3883 only.
 curr1_input             Measured input current.
 curr1_max               Maximum input current.
 curr1_max_alarm         Input current high alarm.
-
-curr[2-3]_label         "iout[1-2]". LTC3880 only.
-curr[2-3]_input         Measured input current.
-curr[2-3]_max           Maximum input current.
-curr[2-3]_crit          Critical input current.
-curr[2-3]_max_alarm     Input current high alarm.
-curr[2-3]_crit_alarm    Input current critical high alarm.
+curr1_highest           Highest input current. LTC3883 only.
+curr1_reset_history     Reset input current history. LTC3883 only.
+
+curr[N]_label           "iout[1-4]".
+                        LTC2974: N=1-4
+                        LTC2978: not supported
+                        LTC3880: N=2-3
+                        LTC3883: N=2
+curr[N]_input           Measured output current.
+curr[N]_max             Maximum output current.
+curr[N]_crit            Critical high output current.
+curr[N]_lcrit           Critical low output current. LTC2974 only.
+curr[N]_max_alarm       Output current high alarm.
+curr[N]_crit_alarm      Output current critical high alarm.
+curr[N]_lcrit_alarm     Output current critical low alarm. LTC2974 only.
+curr[N]_lowest          Lowest output current. LTC2974 only.
+curr[N]_highest         Highest output current.
+curr[N]_reset_history   Reset output current history.
diff --git a/Documentation/hwmon/ltc4261 b/Documentation/hwmon/ltc4261
index eba2e2c4b94d..9378a75c6134 100644
--- a/Documentation/hwmon/ltc4261
+++ b/Documentation/hwmon/ltc4261
@@ -8,7 +8,7 @@ Supported chips:
     Datasheet:
         http://cds.linear.com/docs/Datasheet/42612fb.pdf
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/max16064 b/Documentation/hwmon/max16064
index f8b478076f6d..d59cc7829bec 100644
--- a/Documentation/hwmon/max16064
+++ b/Documentation/hwmon/max16064
@@ -7,7 +7,7 @@ Supported chips:
     Addresses scanned: -
     Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/max16065 b/Documentation/hwmon/max16065
index c11f64a1f2ad..208a29e43010 100644
--- a/Documentation/hwmon/max16065
+++ b/Documentation/hwmon/max16065
@@ -24,7 +24,7 @@ Supported chips:
         http://datasheets.maxim-ic.com/en/ds/MAX16070-MAX16071.pdf
 
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/max34440 b/Documentation/hwmon/max34440
index 47651ff341ae..37cbf472a19d 100644
--- a/Documentation/hwmon/max34440
+++ b/Documentation/hwmon/max34440
@@ -27,7 +27,7 @@ Supported chips:
     Addresses scanned: -
     Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/max8688 b/Documentation/hwmon/max8688
index fe849871df32..e78078638b91 100644
--- a/Documentation/hwmon/max8688
+++ b/Documentation/hwmon/max8688
@@ -7,7 +7,7 @@ Supported chips:
     Addresses scanned: -
     Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/nct6775 b/Documentation/hwmon/nct6775
new file mode 100644
index 000000000000..4e9ef60e8c6c
--- /dev/null
+++ b/Documentation/hwmon/nct6775
@@ -0,0 +1,188 @@
+Note
+====
+
+This driver supersedes the NCT6775F and NCT6776F support in the W83627EHF
+driver.
+
+Kernel driver NCT6775
+=====================
+
+Supported chips:
+  * Nuvoton NCT5572D/NCT6771F/NCT6772F/NCT6775F/W83677HG-I
+    Prefix: 'nct6775'
+    Addresses scanned: ISA address retrieved from Super I/O registers
+    Datasheet: Available from Nuvoton upon request
+  * Nuvoton NCT5577D/NCT6776D/NCT6776F
+    Prefix: 'nct6776'
+    Addresses scanned: ISA address retrieved from Super I/O registers
+    Datasheet: Available from Nuvoton upon request
+  * Nuvoton NCT5532D/NCT6779D
+    Prefix: 'nct6779'
+    Addresses scanned: ISA address retrieved from Super I/O registers
+    Datasheet: Available from Nuvoton upon request
+
+Authors:
+        Guenter Roeck <linux@roeck-us.net>
+
+Description
+-----------
+
+This driver implements support for the Nuvoton NCT6775F, NCT6776F, and NCT6779D
+and compatible super I/O chips.
+
+The chips support up to 25 temperature monitoring sources. Up to 6 of those are
+direct temperature sensor inputs, the others are special sources such as PECI,
+PCH, and SMBUS. Depending on the chip type, 2 to 6 of the temperature sources
+can be monitored and compared against minimum, maximum, and critical
+temperatures. The driver reports up to 10 of the temperatures to the user.
+There are 4 to 5 fan rotation speed sensors, 8 to 15 analog voltage sensors,
+one VID, alarms with beep warnings (control unimplemented), and some automatic
+fan regulation strategies (plus manual fan control mode).
+
+The temperature sensor sources on all chips are configurable. The configured
+source for each of the temperature sensors is provided in tempX_label.
+
+Temperatures are measured in degrees Celsius and measurement resolution is
+either 1 degC or 0.5 degC, depending on the temperature source and
+configuration. An alarm is triggered when the temperature gets higher than
+the high limit; it stays on until the temperature falls below the hysteresis
+value. Alarms are only supported for temp1 to temp6, depending on the chip type.
+
+Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
+triggered if the rotation speed has dropped below a programmable limit. On
+NCT6775F, fan readings can be divided by a programmable divider (1, 2, 4, 8,
+16, 32, 64 or 128) to give the readings more range or accuracy; the other chips
+do not have a fan speed divider. The driver sets the most suitable fan divisor
+itself; specifically, it increases the divider value each time a fan speed
+reading returns an invalid value, and it reduces it if the fan speed reading
+is lower than optimal. Some fans might not be present because they share pins
+with other functions.
+
+Voltage sensors (also known as IN sensors) report their values in millivolts.
+An alarm is triggered if the voltage has crossed a programmable minimum
+or maximum limit.
+
+The driver supports automatic fan control mode known as Thermal Cruise.
+In this mode, the chip attempts to keep the measured temperature in a
+predefined temperature range. If the temperature goes out of range, fan
+is driven slower/faster to reach the predefined range again.
+
+The mode works for fan1-fan5.
+
+sysfs attributes
+----------------
+
+pwm[1-5] - this file stores PWM duty cycle or DC value (fan speed) in range:
+           0 (lowest speed) to 255 (full)
+
+pwm[1-5]_enable - this file controls mode of fan/temperature control:
+        * 0 Fan control disabled (fans set to maximum speed)
+        * 1 Manual mode, write to pwm[0-5] any value 0-255
+        * 2 "Thermal Cruise" mode
+        * 3 "Fan Speed Cruise" mode
+        * 4 "Smart Fan III" mode (NCT6775F only)
+        * 5 "Smart Fan IV" mode
+
+pwm[1-5]_mode - controls if output is PWM or DC level
+        * 0 DC output
+        * 1 PWM output
+
+Common fan control attributes
+-----------------------------
+
+pwm[1-5]_temp_sel       Temperature source. Value is temperature sensor index.
+                        For example, select '1' for temp1_input.
+pwm[1-5]_weight_temp_sel
+                        Secondary temperature source. Value is temperature
+                        sensor index. For example, select '1' for temp1_input.
+                        Set to 0 to disable secondary temperature control.
+
+If secondary temperature functionality is enabled, it is controlled with the
+following attributes.
+
+pwm[1-5]_weight_duty_step
+                        Duty step size.
+pwm[1-5]_weight_temp_step
+                        Temperature step size. With each step over
+                        temp_step_base, the value of weight_duty_step is added
+                        to the current pwm value.
+pwm[1-5]_weight_temp_step_base
+                        Temperature at which secondary temperature control kicks
+                        in.
+pwm[1-5]_weight_temp_step_tol
+                        Temperature step tolerance.
+
+Thermal Cruise mode (2)
+-----------------------
+
+If the temperature is in the range defined by:
+
+pwm[1-5]_target_temp    Target temperature, unit millidegree Celsius
+                        (range 0 - 127000)
+pwm[1-5]_temp_tolerance
+                        Target temperature tolerance, unit millidegree Celsius
+
+there are no changes to fan speed. Once the temperature leaves the interval, fan
+speed increases (if temperature is higher that desired) or decreases (if
+temperature is lower than desired), using the following limits and time
+intervals.
+
+pwm[1-5]_start          fan pwm start value (range 1 - 255), to start fan
+                        when the temperature is above defined range.
+pwm[1-5]_floor          lowest fan pwm (range 0 - 255) if temperature is below
+                        the defined range. If set to 0, the fan is expected to
+                        stop if the temperature is below the defined range.
+pwm[1-5]_step_up_time   milliseconds before fan speed is increased
+pwm[1-5]_step_down_time milliseconds before fan speed is decreased
+pwm[1-5]_stop_time      how many milliseconds must elapse to switch
+                        corresponding fan off (when the temperature was below
+                        defined range).
+
+Speed Cruise mode (3)
+---------------------
+
+This modes tries to keep the fan speed constant.
+
+fan[1-5]_target         Target fan speed
+fan[1-5]_tolerance
+                        Target speed tolerance
+
+
+Untested; use at your own risk.
+
+Smart Fan IV mode (5)
+---------------------
+
+This mode offers multiple slopes to control the fan speed. The slopes can be
+controlled by setting the pwm and temperature attributes. When the temperature
+rises, the chip will calculate the DC/PWM output based on the current slope.
+There are up to seven data points depending on the chip type. Subsequent data
+points should be set to higher temperatures and higher pwm values to achieve
+higher fan speeds with increasing temperature. The last data point reflects
+critical temperature mode, in which the fans should run at full speed.
+
+pwm[1-5]_auto_point[1-7]_pwm
+                        pwm value to be set if temperature reaches matching
+                        temperature range.
+pwm[1-5]_auto_point[1-7]_temp
+                        Temperature over which the matching pwm is enabled.
+pwm[1-5]_temp_tolerance
+                        Temperature tolerance, unit millidegree Celsius
+pwm[1-5]_crit_temp_tolerance
+                        Temperature tolerance for critical temperature,
+                        unit millidegree Celsius
+
+pwm[1-5]_step_up_time   milliseconds before fan speed is increased
+pwm[1-5]_step_down_time milliseconds before fan speed is decreased
+
+Usage Notes
+-----------
+
+On various ASUS boards with NCT6776F, it appears that CPUTIN is not really
+connected to anything and floats, or that it is connected to some non-standard
+temperature measurement device. As a result, the temperature reported on CPUTIN
+will not reflect a usable value. It often reports unreasonably high
+temperatures, and in some cases the reported temperature declines if the actual
+temperature increases (similar to the raw PECI temperature value - see PECI
+specification for details). CPUTIN should therefore be be ignored on ASUS
+boards. The CPU temperature on ASUS boards is reported from PECI 0.
diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus
index 3d3a0f97f966..cf756ed48ff9 100644
--- a/Documentation/hwmon/pmbus
+++ b/Documentation/hwmon/pmbus
@@ -34,7 +34,7 @@ Supported chips:
     Addresses scanned: -
     Datasheet: n.a.
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/sht15 b/Documentation/hwmon/sht15
index 02850bdfac18..778987d1856f 100644
--- a/Documentation/hwmon/sht15
+++ b/Documentation/hwmon/sht15
@@ -40,7 +40,7 @@ bits for humidity, or 12 bits for temperature and 8 bits for humidity.
 The humidity calibration coefficients are programmed into an OTP memory on the
 chip. These coefficients are used to internally calibrate the signals from the
 sensors. Disabling the reload of those coefficients allows saving 10ms for each
-measurement and decrease power consumption, while loosing on precision.
+measurement and decrease power consumption, while losing on precision.
 
 Some options may be set directly in the sht15_platform_data structure
 or via sysfs attributes.
diff --git a/Documentation/hwmon/smm665 b/Documentation/hwmon/smm665
index 59e316140542..a341eeedab75 100644
--- a/Documentation/hwmon/smm665
+++ b/Documentation/hwmon/smm665
@@ -29,7 +29,7 @@ Supported chips:
       http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf
       http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Module Parameters
diff --git a/Documentation/hwmon/tmp401 b/Documentation/hwmon/tmp401
index 9fc447249212..f91e3fa7e5ec 100644
--- a/Documentation/hwmon/tmp401
+++ b/Documentation/hwmon/tmp401
@@ -8,8 +8,16 @@ Supported chips:
     Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp401.html
   * Texas Instruments TMP411
     Prefix: 'tmp411'
-    Addresses scanned: I2C 0x4c
+    Addresses scanned: I2C 0x4c, 0x4d, 0x4e
     Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp411.html
+  * Texas Instruments TMP431
+    Prefix: 'tmp431'
+    Addresses scanned: I2C 0x4c, 0x4d
+    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp431.html
+  * Texas Instruments TMP432
+    Prefix: 'tmp432'
+    Addresses scanned: I2C 0x4c, 0x4d
+    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp432.html
 
 Authors:
          Hans de Goede <hdegoede@redhat.com>
@@ -18,19 +26,19 @@ Authors:
 Description
 -----------
 
-This driver implements support for Texas Instruments TMP401 and
-TMP411 chips. These chips implements one remote and one local
-temperature sensor. Temperature is measured in degrees
+This driver implements support for Texas Instruments TMP401, TMP411,
+TMP431, and TMP432 chips. These chips implement one or two remote and
+one local temperature sensors. Temperature is measured in degrees
 Celsius. Resolution of the remote sensor is 0.0625 degree. Local
 sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
 supported by the driver so far, so using the default resolution of 0.5
 degree).
 
 The driver provides the common sysfs-interface for temperatures (see
-/Documentation/hwmon/sysfs-interface under Temperatures).
+Documentation/hwmon/sysfs-interface under Temperatures).
 
-The TMP411 chip is compatible with TMP401. It provides some additional
-features.
+The TMP411 and TMP431 chips are compatible with TMP401. TMP411 provides
+some additional features.
 
 * Minimum and Maximum temperature measured since power-on, chip-reset
 
@@ -40,3 +48,6 @@ features.
 
   Exported via sysfs attribute temp_reset_history. Writing 1 to this
   file triggers a reset.
+
+TMP432 is compatible with TMP401 and TMP431. It supports two external
+temperature sensors.
diff --git a/Documentation/hwmon/ucd9000 b/Documentation/hwmon/ucd9000
index 0df5f276505b..805e33edb978 100644
--- a/Documentation/hwmon/ucd9000
+++ b/Documentation/hwmon/ucd9000
@@ -11,7 +11,7 @@ Supported chips:
         http://focus.ti.com/lit/ds/symlink/ucd9090.pdf
         http://focus.ti.com/lit/ds/symlink/ucd90910.pdf
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/ucd9200 b/Documentation/hwmon/ucd9200
index fd7d07b1908a..1e8060e631bd 100644
--- a/Documentation/hwmon/ucd9200
+++ b/Documentation/hwmon/ucd9200
@@ -15,7 +15,7 @@ Supported chips:
         http://focus.ti.com/lit/ds/symlink/ucd9246.pdf
         http://focus.ti.com/lit/ds/symlink/ucd9248.pdf
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
diff --git a/Documentation/hwmon/zl6100 b/Documentation/hwmon/zl6100
index 3d924b6b59e9..33908a4d68ff 100644
--- a/Documentation/hwmon/zl6100
+++ b/Documentation/hwmon/zl6100
@@ -54,7 +54,7 @@ http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146401
 http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256
 
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 
 Description
@@ -125,7 +125,7 @@ in2_label		"vmon"
 in2_input               Measured voltage on VMON (ZL2004) or VDRV (ZL9101M,
                         ZL9117M) pin. Reported voltage is 16x the voltage on the
                         pin (adjusted internally by the chip).
-in2_lcrit               Critical minumum VMON/VDRV Voltage.
+in2_lcrit               Critical minimum VMON/VDRV Voltage.
 in2_crit                Critical maximum VMON/VDRV voltage.
 in2_lcrit_alarm         VMON/VDRV voltage critical low alarm.
 in2_crit_alarm          VMON/VDRV voltage critical high alarm.
diff --git a/Documentation/i2c/busses/i2c-diolan-u2c b/Documentation/i2c/busses/i2c-diolan-u2c
index 30fe4bb9a069..0d6018c316c7 100644
--- a/Documentation/i2c/busses/i2c-diolan-u2c
+++ b/Documentation/i2c/busses/i2c-diolan-u2c
@@ -5,7 +5,7 @@ Supported adapters:
     Documentation:
         http://www.diolan.com/i2c/u2c12.html
 
-Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Author: Guenter Roeck <linux@roeck-us.net>
 
 Description
 -----------
diff --git a/Documentation/ia64/err_inject.txt b/Documentation/ia64/err_inject.txt
index 223e4f0582d0..9f651c181429 100644
--- a/Documentation/ia64/err_inject.txt
+++ b/Documentation/ia64/err_inject.txt
@@ -882,7 +882,7 @@ int err_inj()
                         cpu=parameters[i].cpu;
                         k = cpu%64;
                         j = cpu/64;
-                        mask[j]=1<<k;
+                        mask[j] = 1UL << k;
 
                         if (sched_setaffinity(0, MASK_SIZE*8, mask)==-1) {
                                 perror("Error sched_setaffinity:");
diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt
index 3262b6e4d686..e544c7ff8cfa 100644
--- a/Documentation/input/alps.txt
+++ b/Documentation/input/alps.txt
@@ -3,10 +3,26 @@ ALPS Touchpad Protocol
 
 Introduction
 ------------
-
-Currently the ALPS touchpad driver supports four protocol versions in use by
-ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various
-protocol versions is contained in the following sections.
+Currently the ALPS touchpad driver supports five protocol versions in use by
+ALPS touchpads, called versions 1, 2, 3, 4 and 5.
+
+Since roughly mid-2010 several new ALPS touchpads have been released and
+integrated into a variety of laptops and netbooks.  These new touchpads
+have enough behavior differences that the alps_model_data definition
+table, describing the properties of the different versions, is no longer
+adequate.  The design choices were to re-define the alps_model_data
+table, with the risk of regression testing existing devices, or isolate
+the new devices outside of the alps_model_data table.  The latter design
+choice was made.  The new touchpad signatures are named: "Rushmore",
+"Pinnacle", and "Dolphin", which you will see in the alps.c code.
+For the purposes of this document, this group of ALPS touchpads will
+generically be called "new ALPS touchpads".
+
+We experimented with probing the ACPI interface _HID (Hardware ID)/_CID
+(Compatibility ID) definition as a way to uniquely identify the
+different ALPS variants but there did not appear to be a 1:1 mapping.
+In fact, it appeared to be an m:n mapping between the _HID and actual
+hardware type.
 
 Detection
 ---------
@@ -20,9 +36,13 @@ If the E6 report is successful, the touchpad model is identified using the "E7
 report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is
 matched against known models in the alps_model_data_array.
 
-With protocol versions 3 and 4, the E7 report model signature is always
-73-02-64. To differentiate between these versions, the response from the
-"Enter Command Mode" sequence must be inspected as described below.
+For older touchpads supporting protocol versions 3 and 4, the E7 report
+model signature is always 73-02-64. To differentiate between these
+versions, the response from the "Enter Command Mode" sequence must be
+inspected as described below.
+
+The new ALPS touchpads have an E7 signature of 73-03-50 or 73-03-0A but
+seem to be better differentiated by the EC Command Mode response.
 
 Command Mode
 ------------
@@ -47,6 +67,14 @@ address of the register being read, and the third contains the value of the
 register. Registers are written by writing the value one nibble at a time
 using the same encoding used for addresses.
 
+For the new ALPS touchpads, the EC command is used to enter command
+mode. The response in the new ALPS touchpads is significantly different,
+and more important in determining the behavior.  This code has been
+separated from the original alps_model_data table and put in the
+alps_identify function.  For example, there seem to be two hardware init
+sequences for the "Dolphin" touchpads as determined by the second byte
+of the EC response.
+
 Packet Format
 -------------
 
@@ -187,3 +215,28 @@ There are several things worth noting here.
     well.
 
 So far no v4 devices with tracksticks have been encountered.
+
+ALPS Absolute Mode - Protocol Version 5
+---------------------------------------
+This is basically Protocol Version 3 but with different logic for packet
+decode.  It uses the same alps_process_touchpad_packet_v3 call with a
+specialized decode_fields function pointer to correctly interpret the
+packets.  This appears to only be used by the Dolphin devices.
+
+For single-touch, the 6-byte packet format is:
+
+ byte 0:    1    1    0    0    1    0    0    0
+ byte 1:    0   x6   x5   x4   x3   x2   x1   x0
+ byte 2:    0   y6   y5   y4   y3   y2   y1   y0
+ byte 3:    0    M    R    L    1    m    r    l
+ byte 4:   y10  y9   y8   y7  x10   x9   x8   x7
+ byte 5:    0   z6   z5   z4   z3   z2   z1   z0
+
+For mt, the format is:
+
+ byte 0:    1    1    1    n3   1   n2   n1   x24
+ byte 1:    1   y7   y6    y5  y4   y3   y2    y1
+ byte 2:    ?   x2   x1   y12 y11  y10   y9    y8
+ byte 3:    0  x23  x22   x21 x20  x19  x18   x17
+ byte 4:    0   x9   x8    x7  x6   x5   x4    x3
+ byte 5:    0  x16  x15   x14 x13  x12  x11   x10
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 3210540f8bd3..237acab169dd 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -131,6 +131,7 @@ Code  Seq#(hex)	Include File		Comments
 'H'     40-4F   sound/hdspm.h           conflict!
 'H'     40-4F   sound/hdsp.h            conflict!
 'H'     90      sound/usb/usx2y/usb_stream.h
+'H'     A0      uapi/linux/usb/cdc-wdm.h
 'H'     C0-F0   net/bluetooth/hci.h     conflict!
 'H'     C0-DF   net/bluetooth/hidp/hidp.h       conflict!
 'H'     C0-DF   net/bluetooth/cmtp/cmtp.h       conflict!
diff --git a/Documentation/iostats.txt b/Documentation/iostats.txt
index c76c21d87e85..65f694f2d1c9 100644
--- a/Documentation/iostats.txt
+++ b/Documentation/iostats.txt
@@ -71,6 +71,8 @@ Field  4 -- # of milliseconds spent reading
     measured from __make_request() to end_that_request_last()).
 Field  5 -- # of writes completed
     This is the total number of writes completed successfully.
+Field  6 -- # of writes merged
+    See the description of field 2.
 Field  7 -- # of sectors written
     This is the total number of sectors written successfully.
 Field  8 -- # of milliseconds spent writing
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index b8b77bbc784f..3f429ed8b3b8 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -90,6 +90,42 @@ disable the options that are explicitly listed in the specified
 mini-config files.
 
 ______________________________________________________________________
+Environment variables for 'randconfig'
+
+KCONFIG_SEED
+--------------------------------------------------
+You can set this to the integer value used to seed the RNG, if you want
+to somehow debug the behaviour of the kconfig parser/frontends.
+If not set, the current time will be used.
+
+KCONFIG_PROBABILITY
+--------------------------------------------------
+This variable can be used to skew the probabilities. This variable can
+be unset or empty, or set to three different formats:
+        KCONFIG_PROBABILITY     y:n split           y:m:n split
+        -----------------------------------------------------------------
+        unset or empty          50  : 50            33  : 33  : 34
+        N                        N  : 100-N         N/2 : N/2 : 100-N
+    [1] N:M                     N+M : 100-(N+M)      N  :  M  : 100-(N+M)
+    [2] N:M:L                    N  : 100-N          M  :  L  : 100-(M+L)
+
+where N, M and L are integers (in base 10) in the range [0,100], and so
+that:
+    [1] N+M is in the range [0,100]
+    [2] M+L is in the range [0,100]
+
+Examples:
+        KCONFIG_PROBABILITY=10
+                10% of booleans will be set to 'y', 90% to 'n'
+                5% of tristates will be set to 'y', 5% to 'm', 90% to 'n'
+        KCONFIG_PROBABILITY=15:25
+                40% of booleans will be set to 'y', 60% to 'n'
+                15% of tristates will be set to 'y', 25% to 'm', 60% to 'n'
+        KCONFIG_PROBABILITY=10:15:15
+                10% of booleans will be set to 'y', 90% to 'n'
+                15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
+
+______________________________________________________________________
 Environment variables for 'silentoldconfig'
 
 KCONFIG_NOSILENTUPDATE
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 5198b742fde1..d567a7cc552b 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -593,7 +593,7 @@ more details, with real examples.
 
         Example:
                 #Makefile
-                LDFLAGS_vmlinux += $(call really-ld-option, -X)
+                LDFLAGS_vmlinux += $(call ld-option, -X)
 
 
 === 4 Host Program support
@@ -921,8 +921,9 @@ When kbuild executes, the following steps are followed (roughly):
         Often, the KBUILD_CFLAGS variable depends on the configuration.
 
         Example:
-                #arch/x86/Makefile
-                cflags-$(CONFIG_M386) += -march=i386
+                #arch/x86/boot/compressed/Makefile
+                cflags-$(CONFIG_X86_32) := -march=i386
+                cflags-$(CONFIG_X86_64) := -mcmodel=small
                 KBUILD_CFLAGS += $(cflags-y)
 
         Many arch Makefiles dynamically run the target C compiler to
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 13f1aa09b938..9c7fd988e299 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -297,6 +297,7 @@ Boot into System Kernel
    On ia64, 256M@256M is a generous value that typically works.
    The region may be automatically placed on ia64, see the
    dump-capture kernel config option notes above.
+   If use sparse memory, the size should be rounded to GRANULE boundaries.
 
    On s390x, typically use "crashkernel=xxM". The value of xx is dependent
    on the memory consumption of the kdump system. In general this is not
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4609e81dbc37..c3bfacb92910 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -44,6 +44,8 @@ parameter is applicable:
         AVR32   AVR32 architecture is enabled.
         AX25    Appropriate AX.25 support is enabled.
         BLACKFIN Blackfin architecture is enabled.
+        CLK     Common clock infrastructure is enabled.
+        CMA     Contiguous Memory Area support is enabled.
         DRM     Direct Rendering Management support is enabled.
         DYNAMIC_DEBUG Build in debug messages and enable them at runtime
         EDD     BIOS Enhanced Disk Drive Services (EDD) is enabled
@@ -320,6 +322,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         on: enable for both 32- and 64-bit processes
                         off: disable for both 32- and 64-bit processes
 
+        alloc_snapshot  [FTRACE]
+                        Allocate the ftrace snapshot buffer on boot up when the
+                        main buffer is allocated. This is handy if debugging
+                        and you need to use tracing_snapshot() on boot up, and
+                        do not want to use tracing_snapshot_alloc() as it needs
+                        to be done where GFP_KERNEL allocations are allowed.
+
         amd_iommu=      [HW,X86-64]
                         Pass parameters to the AMD IOMMU driver in the system.
                         Possible values are:
@@ -465,6 +474,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
         cio_ignore=     [S390]
                         See Documentation/s390/CommonIO for details.
+        clk_ignore_unused
+                        [CLK]
+                        Keep all clocks already enabled by bootloader on,
+                        even if no driver has claimed them. This is useful
+                        for debug and development, but should not be
+                        needed on a platform with proper driver support.
+                        For more information, see Documentation/clk.txt.
 
         clock=          [BUGS=X86-32, HW] gettimeofday clocksource override.
                         [Deprecated]
@@ -596,9 +612,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         is selected automatically. Check
                         Documentation/kdump/kdump.txt for further details.
 
-        crashkernel_low=size[KMG]
-                        [KNL, x86] parts under 4G.
-
         crashkernel=range1:size1[,range2:size2,...][@offset]
                         [KNL] Same as above, but depends on the memory
                         in the running system. The syntax of range is
@@ -606,6 +619,26 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         a memory unit (amount[KMG]). See also
                         Documentation/kdump/kdump.txt for an example.
 
+        crashkernel=size[KMG],high
+                        [KNL, x86_64] range could be above 4G. Allow kernel
+                        to allocate physical memory region from top, so could
+                        be above 4G if system have more than 4G ram installed.
+                        Otherwise memory region will be allocated below 4G, if
+                        available.
+                        It will be ignored if crashkernel=X is specified.
+        crashkernel=size[KMG],low
+                        [KNL, x86_64] range under 4G. When crashkernel=X,high
+                        is passed, kernel could allocate physical memory region
+                        above 4G, that cause second kernel crash on system
+                        that require some amount of low memory, e.g. swiotlb
+                        requires at least 64M+32K low memory.  Kernel would
+                        try to allocate 72M below 4G automatically.
+                        This one let user to specify own low range under 4G
+                        for second kernel instead.
+                        0: to disable low allocation.
+                        It will be ignored when crashkernel=X,high is not used
+                        or memory reserved is below 4G.
+
         cs89x0_dma=     [HW,NET]
                         Format: <dma>
 
@@ -757,19 +790,31 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         (mmio) or 32-bit (mmio32).
                         The options are the same as for ttyS, above.
 
-        earlyprintk=    [X86,SH,BLACKFIN]
+        earlyprintk=    [X86,SH,BLACKFIN,ARM]
                         earlyprintk=vga
                         earlyprintk=xen
                         earlyprintk=serial[,ttySn[,baudrate]]
+                        earlyprintk=serial[,0x...[,baudrate]]
                         earlyprintk=ttySn[,baudrate]
                         earlyprintk=dbgp[debugController#]
 
+                        earlyprintk is useful when the kernel crashes before
+                        the normal console is initialized. It is not enabled by
+                        default because it has some cosmetic problems.
+
                         Append ",keep" to not disable it when the real console
                         takes over.
 
                         Only vga or serial or usb debug port at a time.
 
-                        Currently only ttyS0 and ttyS1 are supported.
+                        Currently only ttyS0 and ttyS1 may be specified by
+                        name.  Other I/O ports may be explicitly specified
+                        on some architectures (x86 and arm at least) by
+                        replacing ttySn with an I/O port address, like this:
+                                earlyprintk=serial,0x1008,115200
+                        You can find the port for a given device in
+                        /proc/tty/driver/serial:
+                                2: uart:ST16650V2 port:00001008 irq:18 ...
 
                         Interaction with the standard serial driver is not
                         very good.
@@ -788,6 +833,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         edd=            [EDD]
                         Format: {"off" | "on" | "skip[mbr]"}
 
+        efi_no_storage_paranoia [EFI; X86]
+                        Using this parameter you can use more than 50% of
+                        your efi variable storage. Use this parameter only if
+                        you are really sure that your UEFI does sane gc and
+                        fulfills the spec otherwise your board may brick.
+
         eisa_irq_edge=  [PARISC,HW]
                         See header of drivers/parisc/eisa.c.
 
@@ -1226,6 +1277,20 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
         iucv=           [HW,NET]
 
+        ivrs_ioapic     [HW,X86_64]
+                        Provide an override to the IOAPIC-ID<->DEVICE-ID
+                        mapping provided in the IVRS ACPI table. For
+                        example, to map IOAPIC-ID decimal 10 to
+                        PCI device 00:14.0 write the parameter as:
+                                ivrs_ioapic[10]=00:14.0
+
+        ivrs_hpet       [HW,X86_64]
+                        Provide an override to the HPET-ID<->DEVICE-ID
+                        mapping provided in the IVRS ACPI table. For
+                        example, to map HPET-ID decimal 0 to
+                        PCI device 00:14.0 write the parameter as:
+                                ivrs_hpet[0]=00:14.0
+
         js=             [HW,JOY] Analog joystick
                         See Documentation/input/joystick.txt.
 
@@ -1625,7 +1690,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         module.sig_enforce
                         [KNL] When CONFIG_MODULE_SIG is set, this means that
                         modules without (valid) signatures will fail to load.
-                        Note that if CONFIG_MODULE_SIG_ENFORCE is set, that
+                        Note that if CONFIG_MODULE_SIG_FORCE is set, that
                         is always true, so this option does nothing.
 
         mousedev.tap_time=
@@ -1913,6 +1978,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         Valid arguments: on, off
                         Default: on
 
+        nohz_full=      [KNL,BOOT]
+                        In kernels built with CONFIG_NO_HZ_FULL=y, set
+                        the specified list of CPUs whose tick will be stopped
+                        whenever possible. The boot CPU will be forced outside
+                        the range to maintain the timekeeping.
+                        The CPUs in this range must also be included in the
+                        rcu_nocbs= set.
+
         noiotrap        [SH] Disables trapped I/O port accesses.
 
         noirqdebug      [X86-32] Disables the code which attempts to detect and
@@ -1974,8 +2047,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         noreplace-smp   [X86-32,SMP] Don't replace SMP instructions
                         with UP alternatives
 
-        noresidual      [PPC] Don't use residual data on PReP machines.
-
         nordrand        [X86] Disable the direct use of the RDRAND
                         instruction even if it is supported by the
                         processor.  RDRAND is still available to user
@@ -2461,9 +2532,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         In kernels built with CONFIG_RCU_NOCB_CPU=y, set
                         the specified list of CPUs to be no-callback CPUs.
                         Invocation of these CPUs' RCU callbacks will
-                        be offloaded to "rcuoN" kthreads created for
-                        that purpose.  This reduces OS jitter on the
+                        be offloaded to "rcuox/N" kthreads created for
+                        that purpose, where "x" is "b" for RCU-bh, "p"
+                        for RCU-preempt, and "s" for RCU-sched, and "N"
+                        is the CPU number.  This reduces OS jitter on the
                         offloaded CPUs, which can be useful for HPC and
+
                         real-time workloads.  It can also improve energy
                         efficiency for asymmetric multiprocessors.
 
@@ -2487,6 +2561,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         leaf rcu_node structure.  Useful for very large
                         systems.
 
+        rcutree.jiffies_till_first_fqs= [KNL,BOOT]
+                        Set delay from grace-period initialization to
+                        first attempt to force quiescent states.
+                        Units are jiffies, minimum value is zero,
+                        and maximum value is HZ.
+
+        rcutree.jiffies_till_next_fqs= [KNL,BOOT]
+                        Set delay between subsequent attempts to force
+                        quiescent states.  Units are jiffies, minimum
+                        value is one, and maximum value is HZ.
+
         rcutree.qhimark=        [KNL,BOOT]
                         Set threshold of queued
                         RCU callbacks over which batch limiting is disabled.
@@ -2501,16 +2586,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         rcutree.rcu_cpu_stall_timeout= [KNL,BOOT]
                         Set timeout for RCU CPU stall warning messages.
 
-        rcutree.jiffies_till_first_fqs= [KNL,BOOT]
-                        Set delay from grace-period initialization to
-                        first attempt to force quiescent states.
-                        Units are jiffies, minimum value is zero,
-                        and maximum value is HZ.
+        rcutree.rcu_idle_gp_delay=      [KNL,BOOT]
+                        Set wakeup interval for idle CPUs that have
+                        RCU callbacks (RCU_FAST_NO_HZ=y).
 
-        rcutree.jiffies_till_next_fqs= [KNL,BOOT]
-                        Set delay between subsequent attempts to force
-                        quiescent states.  Units are jiffies, minimum
-                        value is one, and maximum value is HZ.
+        rcutree.rcu_idle_lazy_gp_delay= [KNL,BOOT]
+                        Set wakeup interval for idle CPUs that have
+                        only "lazy" RCU callbacks (RCU_FAST_NO_HZ=y).
+                        Lazy RCU callbacks are those which RCU can
+                        prove do nothing more than free memory.
 
         rcutorture.fqs_duration= [KNL,BOOT]
                         Set duration of force_quiescent_state bursts.
@@ -2663,6 +2747,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         Useful for devices that are detected asynchronously
                         (e.g. USB and MMC devices).
 
+        rproc_mem=nn[KMG][@address]
+                        [KNL,ARM,CMA] Remoteproc physical memory block.
+                        Memory area to be used by remote processor image,
+                        managed by CMA.
+
         rw              [KNL] Mount root device read-write on boot
 
         S               [KNL] Run init in single mode
@@ -3222,6 +3311,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         or other driver-specific files in the
                         Documentation/watchdog/ directory.
 
+        workqueue.disable_numa
+                        By default, all work items queued to unbound
+                        workqueues are affine to the NUMA nodes they're
+                        issued on, which results in better behavior in
+                        general.  If NUMA affinity needs to be disabled for
+                        whatever reason, this option can be used.  Note
+                        that this also can be controlled per-workqueue for
+                        workqueues visible under /sys/bus/workqueue/.
+
         x2apic_phys     [X86-64,APIC] Use x2apic physical mode instead of
                         default x2apic cluster mode on platforms
                         supporting x2apic.
diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX
index 5246090ef15c..1ecd1596633e 100644
--- a/Documentation/leds/00-INDEX
+++ b/Documentation/leds/00-INDEX
@@ -6,6 +6,8 @@ leds-lp5521.txt
         - notes on how to use the leds-lp5521 driver.
 leds-lp5523.txt
         - notes on how to use the leds-lp5523 driver.
+leds-lp5562.txt
+        - notes on how to use the leds-lp5562 driver.
 leds-lp55xx.txt
         - description about lp55xx common driver.
 leds-lm3556.txt
diff --git a/Documentation/leds/leds-lp5521.txt b/Documentation/leds/leds-lp5521.txt
index 270f57196339..79e4c2e6e5e8 100644
--- a/Documentation/leds/leds-lp5521.txt
+++ b/Documentation/leds/leds-lp5521.txt
@@ -81,22 +81,3 @@ static struct lp55xx_platform_data lp5521_platform_data = {
 
 If the current is set to 0 in the platform data, that channel is
 disabled and it is not visible in the sysfs.
-
-The 'update_config' : CONFIG register (ADDR 08h)
-This value is platform-specific data.
-If update_config is not defined, the CONFIG register is set with
-'LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT'.
-(Enable auto-powersave, set charge pump to auto, red to battery)
-
-example of update_config :
-
-#define LP5521_CONFIGS  (LP5521_PWM_HF | LP5521_PWRSAVE_EN | \
-                        LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
-                        LP5521_CLK_INT)
-
-static struct lp55xx_platform_data lp5521_pdata = {
-        .led_config = lp5521_led_config,
-        .num_channels = ARRAY_SIZE(lp5521_led_config),
-        .clock_mode = LP55XX_CLOCK_INT,
-        .update_config = LP5521_CONFIGS,
-};
diff --git a/Documentation/leds/leds-lp5562.txt b/Documentation/leds/leds-lp5562.txt
new file mode 100644
index 000000000000..5a823ff6b393
--- /dev/null
+++ b/Documentation/leds/leds-lp5562.txt
@@ -0,0 +1,120 @@
+Kernel driver for LP5562
+========================
+
+* TI LP5562 LED Driver
+
+Author: Milo(Woogyom) Kim <milo.kim@ti.com>
+
+Description
+
+  LP5562 can drive up to 4 channels. R/G/B and White.
+  LEDs can be controlled directly via the led class control interface.
+
+  All four channels can be also controlled using the engine micro programs.
+  LP5562 has the internal program memory for running various LED patterns.
+  For the details, please refer to 'firmware' section in leds-lp55xx.txt
+
+Device attribute: engine_mux
+
+  3 Engines are allocated in LP5562, but the number of channel is 4.
+  Therefore each channel should be mapped to the engine number.
+  Value : RGB or W
+
+  This attribute is used for programming LED data with the firmware interface.
+  Unlike the LP5521/LP5523/55231, LP5562 has unique feature for the engine mux,
+  so additional sysfs is required.
+
+  LED Map
+  Red   ... Engine 1 (fixed)
+  Green ... Engine 2 (fixed)
+  Blue  ... Engine 3 (fixed)
+  White ... Engine 1 or 2 or 3 (selective)
+
+How to load the program data using engine_mux
+
+  Before loading the LP5562 program data, engine_mux should be written between
+  the engine selection and loading the firmware.
+  Engine mux has two different mode, RGB and W.
+  RGB is used for loading RGB program data, W is used for W program data.
+
+  For example, run blinking green channel pattern,
+  echo 2 > /sys/bus/i2c/devices/xxxx/select_engine     # 2 is for green channel
+  echo "RGB" > /sys/bus/i2c/devices/xxxx/engine_mux    # engine mux for RGB
+  echo 1 > /sys/class/firmware/lp5562/loading
+  echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
+  echo 0 > /sys/class/firmware/lp5562/loading
+  echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+
+  To run a blinking white pattern,
+  echo 1 or 2 or 3 > /sys/bus/i2c/devices/xxxx/select_engine
+  echo "W" > /sys/bus/i2c/devices/xxxx/engine_mux
+  echo 1 > /sys/class/firmware/lp5562/loading
+  echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
+  echo 0 > /sys/class/firmware/lp5562/loading
+  echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
+
+How to load the predefined patterns
+
+  Please refer to 'leds-lp55xx.txt"
+
+Setting Current of Each Channel
+
+  Like LP5521 and LP5523/55231, LP5562 provides LED current settings.
+  The 'led_current' and 'max_current' are used.
+
+(Example of Platform data)
+
+To configure the platform specific data, lp55xx_platform_data structure is used.
+
+static struct lp55xx_led_config lp5562_led_config[] = {
+        {
+                .name           = "R",
+                .chan_nr        = 0,
+                .led_current    = 20,
+                .max_current    = 40,
+        },
+        {
+                .name           = "G",
+                .chan_nr        = 1,
+                .led_current    = 20,
+                .max_current    = 40,
+        },
+        {
+                .name           = "B",
+                .chan_nr        = 2,
+                .led_current    = 20,
+                .max_current    = 40,
+        },
+        {
+                .name           = "W",
+                .chan_nr        = 3,
+                .led_current    = 20,
+                .max_current    = 40,
+        },
+};
+
+static int lp5562_setup(void)
+{
+        /* setup HW resources */
+}
+
+static void lp5562_release(void)
+{
+        /* Release HW resources */
+}
+
+static void lp5562_enable(bool state)
+{
+        /* Control of chip enable signal */
+}
+
+static struct lp55xx_platform_data lp5562_platform_data = {
+        .led_config     = lp5562_led_config,
+        .num_channels   = ARRAY_SIZE(lp5562_led_config),
+        .setup_resources   = lp5562_setup,
+        .release_resources = lp5562_release,
+        .enable            = lp5562_enable,
+};
+
+If the current is set to 0 in the platform data, that channel is
+disabled and it is not visible in the sysfs.
diff --git a/Documentation/leds/leds-lp55xx.txt b/Documentation/leds/leds-lp55xx.txt
index ced41868d2d1..eec8fa2ffe4e 100644
--- a/Documentation/leds/leds-lp55xx.txt
+++ b/Documentation/leds/leds-lp55xx.txt
@@ -5,7 +5,7 @@ Authors: Milo(Woogyom) Kim <milo.kim@ti.com>
 
 Description
 -----------
-LP5521, LP5523/55231 have common features as below.
+LP5521, LP5523/55231 and LP5562 have common features as below.
 
   Register access via the I2C
   Device initialization/deinitialization
@@ -116,3 +116,47 @@ To support this, 'run_engine' and 'firmware_cb' are configurable in each driver.
 run_engine  : Control the selected engine
 firmware_cb : The callback function after loading the firmware is done.
               Chip specific commands for loading and updating program memory.
+
+( Predefined pattern data )
+
+Without the firmware interface, LP55xx driver provides another method for
+loading a LED pattern. That is 'predefined' pattern.
+A predefined pattern is defined in the platform data and load it(or them)
+via the sysfs if needed.
+To use the predefined pattern concept, 'patterns' and 'num_patterns' should be
+configured.
+
+  Example of predefined pattern data:
+
+  /* mode_1: blinking data */
+  static const u8 mode_1[] = {
+                0x40, 0x00, 0x60, 0x00, 0x40, 0xFF, 0x60, 0x00,
+                };
+
+  /* mode_2: always on */
+  static const u8 mode_2[] = { 0x40, 0xFF, };
+
+  struct lp55xx_predef_pattern board_led_patterns[] = {
+        {
+                .r = mode_1,
+                .size_r = ARRAY_SIZE(mode_1),
+        },
+        {
+                .b = mode_2,
+                .size_b = ARRAY_SIZE(mode_2),
+        },
+  }
+
+  struct lp55xx_platform_data lp5562_pdata = {
+  ...
+        .patterns      = board_led_patterns,
+        .num_patterns  = ARRAY_SIZE(board_led_patterns),
+  };
+
+Then, mode_1 and mode_2 can be run via through the sysfs.
+
+  echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern    # red blinking LED pattern
+  echo 2 > /sys/bus/i2c/devices/xxxx/led_pattern    # blue LED always on
+
+To stop running pattern,
+  echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern
diff --git a/Documentation/md.txt b/Documentation/md.txt
index 993fba37b7d1..e0ddd327632d 100644
--- a/Documentation/md.txt
+++ b/Documentation/md.txt
@@ -119,7 +119,7 @@ device to add.
 The array is started with the RUN_ARRAY ioctl.
 
 Once started, new devices can be added.  They should have an
-appropriate superblock written to them, and then passed be in with
+appropriate superblock written to them, and then be passed in with
 ADD_NEW_DISK.
 
 Devices that have failed or are not yet active can be detached from an
@@ -131,7 +131,7 @@ Specific Rules that apply to format-0 super block arrays, and
 -------------------------------------------------------------
 
 An array can be 'created' by describing the array (level, chunksize
-etc) in a SET_ARRAY_INFO ioctl.  This must has major_version==0 and
+etc) in a SET_ARRAY_INFO ioctl.  This must have major_version==0 and
 raid_disks != 0.
 
 Then uninitialized devices can be added with ADD_NEW_DISK.  The
@@ -426,7 +426,7 @@ Each directory contains:
       offset
         This gives the location in the device (in sectors from the
         start) where data from the array will be stored.  Any part of
-        the device before this offset us not touched, unless it is
+        the device before this offset is not touched, unless it is
         used for storing metadata (Formats 1.1 and 1.2).
 
       size
@@ -440,7 +440,7 @@ Each directory contains:
         When the device is not 'in_sync', this records the number of
         sectors from the start of the device which are known to be
         correct.  This is normally zero, but during a recovery
-        operation is will steadily increase, and if the recovery is
+        operation it will steadily increase, and if the recovery is
         interrupted, restoring this value can cause recovery to
         avoid repeating the earlier blocks.  With v1.x metadata, this
         value is saved and restored automatically.
@@ -468,7 +468,7 @@ Each directory contains:
 
 
 
-An active md device will also contain and entry for each active device
+An active md device will also contain an entry for each active device
 in the array.  These are named
 
     rdNN
@@ -482,7 +482,7 @@ will show 'in_sync' on every line.
 
 
 
-Active md devices for levels that support data redundancy (1,4,5,6)
+Active md devices for levels that support data redundancy (1,4,5,6,10)
 also have
 
    sync_action
@@ -494,7 +494,7 @@ also have
                        failed/missing device
        idle          - nothing is happening
        check         - A full check of redundancy was requested and is
-                       happening.  This reads all block and checks
+                       happening.  This reads all blocks and checks
                        them. A repair may also happen for some raid
                        levels.
        repair        - A full check and repair is happening.  This is
@@ -522,7 +522,7 @@ also have
 
    degraded
       This contains a count of the number of devices by which the
-      arrays is degraded.  So an optimal array with show '0'.  A
+      arrays is degraded.  So an optimal array will show '0'.  A
       single failed/missing drive will show '1', etc.
       This file responds to select/poll, any increase or decrease
       in the count of missing devices will trigger an event.
diff --git a/Documentation/misc-devices/mei/mei-client-bus.txt b/Documentation/misc-devices/mei/mei-client-bus.txt
new file mode 100644
index 000000000000..f83910a8ce76
--- /dev/null
+++ b/Documentation/misc-devices/mei/mei-client-bus.txt
@@ -0,0 +1,138 @@
+Intel(R) Management Engine (ME) Client bus API
+===============================================
+
+
+Rationale
+=========
+MEI misc character device is useful for dedicated applications to send and receive
+data to the many FW appliance found in Intel's ME from the user space.
+However for some of the ME functionalities it make sense to leverage existing software
+stack and expose them through existing kernel subsystems.
+
+In order to plug seamlessly into the kernel device driver model we add kernel virtual
+bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers
+for the various MEI features as a stand alone entities found in their respective subsystem.
+Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to
+the existing code.
+
+
+MEI CL bus API
+===========
+A driver implementation for an MEI Client is very similar to existing bus
+based device drivers. The driver registers itself as an MEI CL bus driver through
+the mei_cl_driver structure:
+
+struct mei_cl_driver {
+        struct device_driver driver;
+        const char *name;
+
+        const struct mei_cl_device_id *id_table;
+
+        int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id);
+        int (*remove)(struct mei_cl_device *dev);
+};
+
+struct mei_cl_id {
+        char name[MEI_NAME_SIZE];
+        kernel_ulong_t driver_info;
+};
+
+The mei_cl_id structure allows the driver to bind itself against a device name.
+
+To actually register a driver on the ME Client bus one must call the mei_cl_add_driver()
+API. This is typically called at module init time.
+
+Once registered on the ME Client bus, a driver will typically try to do some I/O on
+this bus and this should be done through the mei_cl_send() and mei_cl_recv()
+routines. The latter is synchronous (blocks and sleeps until data shows up).
+In order for drivers to be notified of pending events waiting for them (e.g.
+an Rx event) they can register an event handler through the
+mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event
+will trigger an event handler call and the driver implementation is supposed
+to call mei_recv() from the event handler in order to fetch the pending
+received buffers.
+
+
+Example
+=======
+As a theoretical example let's pretend the ME comes with a "contact" NFC IP.
+The driver init and exit routines for this device would look like:
+
+#define CONTACT_DRIVER_NAME "contact"
+
+static struct mei_cl_device_id contact_mei_cl_tbl[] = {
+        { CONTACT_DRIVER_NAME, },
+
+        /* required last entry */
+        { }
+};
+MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl);
+
+static struct mei_cl_driver contact_driver = {
+       .id_table = contact_mei_tbl,
+       .name = CONTACT_DRIVER_NAME,
+
+       .probe = contact_probe,
+       .remove = contact_remove,
+};
+
+static int contact_init(void)
+{
+        int r;
+
+        r = mei_cl_driver_register(&contact_driver);
+        if (r) {
+                pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n");
+                return r;
+        }
+
+        return 0;
+}
+
+static void __exit contact_exit(void)
+{
+        mei_cl_driver_unregister(&contact_driver);
+}
+
+module_init(contact_init);
+module_exit(contact_exit);
+
+And the driver's simplified probe routine would look like that:
+
+int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id)
+{
+        struct contact_driver *contact;
+
+        [...]
+        mei_cl_enable_device(dev);
+
+        mei_cl_register_event_cb(dev, contact_event_cb, contact);
+
+        return 0;
+ }
+
+In the probe routine the driver first enable the MEI device and then registers
+an ME bus event handler which is as close as it can get to registering a
+threaded IRQ handler.
+The handler implementation will typically call some I/O routine depending on
+the pending events:
+
+#define MAX_NFC_PAYLOAD 128
+
+static void contact_event_cb(struct mei_cl_device *dev, u32 events,
+                             void *context)
+{
+        struct contact_driver *contact = context;
+
+        if (events & BIT(MEI_EVENT_RX)) {
+                u8 payload[MAX_NFC_PAYLOAD];
+                int payload_size;
+
+                payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD);
+                if (payload_size <= 0)
+                        return;
+
+                /* Hook to the NFC subsystem */
+                nfc_hci_recv_frame(contact->hdev, payload, payload_size);
+        }
+}
diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt
index 0d98fac8893b..189bab09255a 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -22,6 +22,7 @@ All attributes are read-only.
         manfid                  Manufacturer ID (from CID Register)
         name                    Product Name (from CID Register)
         oemid                   OEM/Application ID (from CID Register)
+        prv                     Product Revision (from CID Register) (SD and MMCv4 only)
         serial                  Product Serial Number (from CID Register)
         erase_size              Erase group size
         preferred_erase_size    Preferred erase size
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 703cf4370c79..67a9cb259d40 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -71,8 +71,9 @@ submits skb to qdisc), so if you need something from that cb later, you should
 store info in the skb->data on your own.
 
 To hook the MLME interface you have to populate the ml_priv field of your
-net_device with a pointer to struct ieee802154_mlme_ops instance. All fields are
-required.
+net_device with a pointer to struct ieee802154_mlme_ops instance. The fields
+assoc_req, assoc_resp, disassoc_req, start_req, and scan_req are optional.
+All other fields are required.
 
 We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c
 
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index dc2dc87d2557..f98ca633b528 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -29,7 +29,7 @@ route/max_size - INTEGER
 neigh/default/gc_thresh1 - INTEGER
         Minimum number of entries to keep.  Garbage collector will not
         purge entries if there are fewer than this number.
-        Default: 256
+        Default: 128
 
 neigh/default/gc_thresh3 - INTEGER
         Maximum number of neighbor entries allowed.  Increase this
@@ -175,14 +175,6 @@ tcp_congestion_control - STRING
         is inherited.
         [see setsockopt(listenfd, SOL_TCP, TCP_CONGESTION, "name" ...) ]
 
-tcp_cookie_size - INTEGER
-        Default size of TCP Cookie Transactions (TCPCT) option, that may be
-        overridden on a per socket basis by the TCPCT socket option.
-        Values greater than the maximum (16) are interpreted as the maximum.
-        Values greater than zero and less than the minimum (8) are interpreted
-        as the minimum.  Odd values are interpreted as the next even value.
-        Default: 0 (off).
-
 tcp_dsack - BOOLEAN
         Allows TCP to send "duplicate" SACKs.
 
@@ -190,7 +182,9 @@ tcp_early_retrans - INTEGER
         Enable Early Retransmit (ER), per RFC 5827. ER lowers the threshold
         for triggering fast retransmit when the amount of outstanding data is
         small and when no previously unsent data can be transmitted (such
-        that limited transmit could be used).
+        that limited transmit could be used). Also controls the use of
+        Tail loss probe (TLP) that converts RTOs occuring due to tail
+        losses into fast recovery (draft-dukkipati-tcpm-tcp-loss-probe-01).
         Possible values:
                 0 disables ER
                 1 enables ER
@@ -198,7 +192,9 @@ tcp_early_retrans - INTEGER
                   by a fourth of RTT. This mitigates connection falsely
                   recovers when network has a small degree of reordering
                   (less than 3 packets).
-        Default: 2
+                3 enables delayed ER and TLP.
+                4 enables TLP only.
+        Default: 3
 
 tcp_ecn - INTEGER
         Control use of Explicit Congestion Notification (ECN) by TCP.
@@ -229,36 +225,13 @@ tcp_fin_timeout - INTEGER
         Default: 60 seconds
 
 tcp_frto - INTEGER
-        Enables Forward RTO-Recovery (F-RTO) defined in RFC4138.
+        Enables Forward RTO-Recovery (F-RTO) defined in RFC5682.
         F-RTO is an enhanced recovery algorithm for TCP retransmission
-        timeouts.  It is particularly beneficial in wireless environments
-        where packet loss is typically due to random radio interference
-        rather than intermediate router congestion.  F-RTO is sender-side
-        only modification. Therefore it does not require any support from
-        the peer.
-
-        If set to 1, basic version is enabled.  2 enables SACK enhanced
-        F-RTO if flow uses SACK.  The basic version can be used also when
-        SACK is in use though scenario(s) with it exists where F-RTO
-        interacts badly with the packet counting of the SACK enabled TCP
-        flow.
-
-tcp_frto_response - INTEGER
-        When F-RTO has detected that a TCP retransmission timeout was
-        spurious (i.e, the timeout would have been avoided had TCP set a
-        longer retransmission timeout), TCP has several options what to do
-        next. Possible values are:
-                0 Rate halving based; a smooth and conservative response,
-                  results in halved cwnd and ssthresh after one RTT
-                1 Very conservative response; not recommended because even
-                  though being valid, it interacts poorly with the rest of
-                  Linux TCP, halves cwnd and ssthresh immediately
-                2 Aggressive response; undoes congestion control measures
-                  that are now known to be unnecessary (ignoring the
-                  possibility of a lost retransmission that would require
-                  TCP to be more cautious), cwnd and ssthresh are restored
-                  to the values prior timeout
-        Default: 0 (rate halving based)
+        timeouts.  It is particularly beneficial in networks where the
+        RTT fluctuates (e.g., wireless). F-RTO is sender-side only
+        modification. It does not require any support from the peer.
+
+        By default it's enabled with a non-zero value. 0 disables F-RTO.
 
 tcp_keepalive_time - INTEGER
         How often TCP sends out keepalive messages when keepalive is enabled.
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index f2a2488f1bf3..9573d0c48c6e 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -15,6 +15,13 @@ amemthresh - INTEGER
         enabled and the variable is automatically set to 2, otherwise
         the strategy is disabled and the variable is  set  to 1.
 
+backup_only - BOOLEAN
+        0 - disabled (default)
+        not 0 - enabled
+
+        If set, disable the director function while the server is
+        in backup mode to avoid packet loops for DR/TUN methods.
+
 conntrack - BOOLEAN
         0 - disabled (default)
         not 0 - enabled
diff --git a/Documentation/networking/netlink_mmap.txt b/Documentation/networking/netlink_mmap.txt
new file mode 100644
index 000000000000..1c2dab409625
--- /dev/null
+++ b/Documentation/networking/netlink_mmap.txt
@@ -0,0 +1,339 @@
+This file documents how to use memory mapped I/O with netlink.
+
+Author: Patrick McHardy <kaber@trash.net>
+
+Overview
+--------
+
+Memory mapped netlink I/O can be used to increase throughput and decrease
+overhead of unicast receive and transmit operations. Some netlink subsystems
+require high throughput, these are mainly the netfilter subsystems
+nfnetlink_queue and nfnetlink_log, but it can also help speed up large
+dump operations of f.i. the routing database.
+
+Memory mapped netlink I/O used two circular ring buffers for RX and TX which
+are mapped into the processes address space.
+
+The RX ring is used by the kernel to directly construct netlink messages into
+user-space memory without copying them as done with regular socket I/O,
+additionally as long as the ring contains messages no recvmsg() or poll()
+syscalls have to be issued by user-space to get more message.
+
+The TX ring is used to process messages directly from user-space memory, the
+kernel processes all messages contained in the ring using a single sendmsg()
+call.
+
+Usage overview
+--------------
+
+In order to use memory mapped netlink I/O, user-space needs three main changes:
+
+- ring setup
+- conversion of the RX path to get messages from the ring instead of recvmsg()
+- conversion of the TX path to construct messages into the ring
+
+Ring setup is done using setsockopt() to provide the ring parameters to the
+kernel, then a call to mmap() to map the ring into the processes address space:
+
+- setsockopt(fd, SOL_NETLINK, NETLINK_RX_RING, &params, sizeof(params));
+- setsockopt(fd, SOL_NETLINK, NETLINK_TX_RING, &params, sizeof(params));
+- ring = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0)
+
+Usage of either ring is optional, but even if only the RX ring is used the
+mapping still needs to be writable in order to update the frame status after
+processing.
+
+Conversion of the reception path involves calling poll() on the file
+descriptor, once the socket is readable the frames from the ring are
+processsed in order until no more messages are available, as indicated by
+a status word in the frame header.
+
+On kernel side, in order to make use of memory mapped I/O on receive, the
+originating netlink subsystem needs to support memory mapped I/O, otherwise
+it will use an allocated socket buffer as usual and the contents will be
+ copied to the ring on transmission, nullifying most of the performance gains.
+Dumps of kernel databases automatically support memory mapped I/O.
+
+Conversion of the transmit path involves changing message contruction to
+use memory from the TX ring instead of (usually) a buffer declared on the
+stack and setting up the frame header approriately. Optionally poll() can
+be used to wait for free frames in the TX ring.
+
+Structured and definitions for using memory mapped I/O are contained in
+<linux/netlink.h>.
+
+RX and TX rings
+----------------
+
+Each ring contains a number of continous memory blocks, containing frames of
+fixed size dependant on the parameters used for ring setup.
+
+Ring:   [ block 0 ]
+                [ frame 0 ]
+                [ frame 1 ]
+        [ block 1 ]
+                [ frame 2 ]
+                [ frame 3 ]
+        ...
+        [ block n ]
+                [ frame 2 * n ]
+                [ frame 2 * n + 1 ]
+
+The blocks are only visible to the kernel, from the point of view of user-space
+the ring just contains the frames in a continous memory zone.
+
+The ring parameters used for setting up the ring are defined as follows:
+
+struct nl_mmap_req {
+        unsigned int    nm_block_size;
+        unsigned int    nm_block_nr;
+        unsigned int    nm_frame_size;
+        unsigned int    nm_frame_nr;
+};
+
+Frames are grouped into blocks, where each block is a continous region of memory
+and holds nm_block_size / nm_frame_size frames. The total number of frames in
+the ring is nm_frame_nr. The following invariants hold:
+
+- frames_per_block = nm_block_size / nm_frame_size
+
+- nm_frame_nr = frames_per_block * nm_block_nr
+
+Some parameters are constrained, specifically:
+
+- nm_block_size must be a multiple of the architectures memory page size.
+  The getpagesize() function can be used to get the page size.
+
+- nm_frame_size must be equal or larger to NL_MMAP_HDRLEN, IOW a frame must be
+  able to hold at least the frame header
+
+- nm_frame_size must be smaller or equal to nm_block_size
+
+- nm_frame_size must be a multiple of NL_MMAP_MSG_ALIGNMENT
+
+- nm_frame_nr must equal the actual number of frames as specified above.
+
+When the kernel can't allocate phsyically continous memory for a ring block,
+it will fall back to use physically discontinous memory. This might affect
+performance negatively, in order to avoid this the nm_frame_size parameter
+should be chosen to be as small as possible for the required frame size and
+the number of blocks should be increased instead.
+
+Ring frames
+------------
+
+Each frames contain a frame header, consisting of a synchronization word and some
+meta-data, and the message itself.
+
+Frame:  [ header message ]
+
+The frame header is defined as follows:
+
+struct nl_mmap_hdr {
+        unsigned int    nm_status;
+        unsigned int    nm_len;
+        __u32           nm_group;
+        /* credentials */
+        __u32           nm_pid;
+        __u32           nm_uid;
+        __u32           nm_gid;
+};
+
+- nm_status is used for synchronizing processing between the kernel and user-
+  space and specifies ownership of the frame as well as the operation to perform
+
+- nm_len contains the length of the message contained in the data area
+
+- nm_group specified the destination multicast group of message
+
+- nm_pid, nm_uid and nm_gid contain the netlink pid, UID and GID of the sending
+  process. These values correspond to the data available using SOCK_PASSCRED in
+  the SCM_CREDENTIALS cmsg.
+
+The possible values in the status word are:
+
+- NL_MMAP_STATUS_UNUSED:
+        RX ring:        frame belongs to the kernel and contains no message
+                        for user-space. Approriate action is to invoke poll()
+                        to wait for new messages.
+
+        TX ring:        frame belongs to user-space and can be used for
+                        message construction.
+
+- NL_MMAP_STATUS_RESERVED:
+        RX ring only:   frame is currently used by the kernel for message
+                        construction and contains no valid message yet.
+                        Appropriate action is to invoke poll() to wait for
+                        new messages.
+
+- NL_MMAP_STATUS_VALID:
+        RX ring:        frame contains a valid message. Approriate action is
+                        to process the message and release the frame back to
+                        the kernel by setting the status to
+                        NL_MMAP_STATUS_UNUSED or queue the frame by setting the
+                        status to NL_MMAP_STATUS_SKIP.
+
+        TX ring:        the frame contains a valid message from user-space to
+                        be processed by the kernel. After completing processing
+                        the kernel will release the frame back to user-space by
+                        setting the status to NL_MMAP_STATUS_UNUSED.
+
+- NL_MMAP_STATUS_COPY:
+        RX ring only:   a message is ready to be processed but could not be
+                        stored in the ring, either because it exceeded the
+                        frame size or because the originating subsystem does
+                        not support memory mapped I/O. Appropriate action is
+                        to invoke recvmsg() to receive the message and release
+                        the frame back to the kernel by setting the status to
+                        NL_MMAP_STATUS_UNUSED.
+
+- NL_MMAP_STATUS_SKIP:
+        RX ring only:   user-space queued the message for later processing, but
+                        processed some messages following it in the ring. The
+                        kernel should skip this frame when looking for unused
+                        frames.
+
+The data area of a frame begins at a offset of NL_MMAP_HDRLEN relative to the
+frame header.
+
+TX limitations
+--------------
+
+Kernel processing usually involves validation of the message received by
+user-space, then processing its contents. The kernel must assure that
+userspace is not able to modify the message contents after they have been
+validated. In order to do so, the message is copied from the ring frame
+to an allocated buffer if either of these conditions is false:
+
+- only a single mapping of the ring exists
+- the file descriptor is not shared between processes
+
+This means that for threaded programs, the kernel will fall back to copying.
+
+Example
+-------
+
+Ring setup:
+
+        unsigned int block_size = 16 * getpagesize();
+        struct nl_mmap_req req = {
+                .nm_block_size          = block_size,
+                .nm_block_nr            = 64,
+                .nm_frame_size          = 16384,
+                .nm_frame_nr            = 64 * block_size / 16384,
+        };
+        unsigned int ring_size;
+        void *rx_ring, *tx_ring;
+
+        /* Configure ring parameters */
+        if (setsockopt(fd, NETLINK_RX_RING, &req, sizeof(req)) < 0)
+                exit(1);
+        if (setsockopt(fd, NETLINK_TX_RING, &req, sizeof(req)) < 0)
+                exit(1)
+
+        /* Calculate size of each invididual ring */
+        ring_size = req.nm_block_nr * req.nm_block_size;
+
+        /* Map RX/TX rings. The TX ring is located after the RX ring */
+        rx_ring = mmap(NULL, 2 * ring_size, PROT_READ | PROT_WRITE,
+                       MAP_SHARED, fd, 0);
+        if ((long)rx_ring == -1L)
+                exit(1);
+        tx_ring = rx_ring + ring_size:
+
+Message reception:
+
+This example assumes some ring parameters of the ring setup are available.
+
+        unsigned int frame_offset = 0;
+        struct nl_mmap_hdr *hdr;
+        struct nlmsghdr *nlh;
+        unsigned char buf[16384];
+        ssize_t len;
+
+        while (1) {
+                struct pollfd pfds[1];
+
+                pfds[0].fd      = fd;
+                pfds[0].events  = POLLIN | POLLERR;
+                pfds[0].revents = 0;
+
+                if (poll(pfds, 1, -1) < 0 && errno != -EINTR)
+                        exit(1);
+
+                /* Check for errors. Error handling omitted */
+                if (pfds[0].revents & POLLERR)
+                        <handle error>
+
+                /* If no new messages, poll again */
+                if (!(pfds[0].revents & POLLIN))
+                        continue;
+
+                /* Process all frames */
+                while (1) {
+                        /* Get next frame header */
+                        hdr = rx_ring + frame_offset;
+
+                        if (hdr->nm_status == NL_MMAP_STATUS_VALID)
+                                /* Regular memory mapped frame */
+                                nlh = (void *hdr) + NL_MMAP_HDRLEN;
+                                len = hdr->nm_len;
+
+                                /* Release empty message immediately. May happen
+                                 * on error during message construction.
+                                 */
+                                if (len == 0)
+                                        goto release;
+                        } else if (hdr->nm_status == NL_MMAP_STATUS_COPY) {
+                                /* Frame queued to socket receive queue */
+                                len = recv(fd, buf, sizeof(buf), MSG_DONTWAIT);
+                                if (len <= 0)
+                                        break;
+                                nlh = buf;
+                        } else
+                                /* No more messages to process, continue polling */
+                                break;
+
+                        process_msg(nlh);
+release:
+                        /* Release frame back to the kernel */
+                        hdr->nm_status = NL_MMAP_STATUS_UNUSED;
+
+                        /* Advance frame offset to next frame */
+                        frame_offset = (frame_offset + frame_size) % ring_size;
+                }
+        }
+
+Message transmission:
+
+This example assumes some ring parameters of the ring setup are available.
+A single message is constructed and transmitted, to send multiple messages
+at once they would be constructed in consecutive frames before a final call
+to sendto().
+
+        unsigned int frame_offset = 0;
+        struct nl_mmap_hdr *hdr;
+        struct nlmsghdr *nlh;
+        struct sockaddr_nl addr = {
+                .nl_family      = AF_NETLINK,
+        };
+
+        hdr = tx_ring + frame_offset;
+        if (hdr->nm_status != NL_MMAP_STATUS_UNUSED)
+                /* No frame available. Use poll() to avoid. */
+                exit(1);
+
+        nlh = (void *)hdr + NL_MMAP_HDRLEN;
+
+        /* Build message */
+        build_message(nlh);
+
+        /* Fill frame header: length and status need to be set */
+        hdr->nm_len     = nlh->nlmsg_len;
+        hdr->nm_status  = NL_MMAP_STATUS_VALID;
+
+        if (sendto(fd, NULL, 0, 0, &addr, sizeof(addr)) < 0)
+                exit(1);
+
+        /* Advance frame offset to next frame */
+        frame_offset = (frame_offset + frame_size) % ring_size;
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 94444b152fbc..23dd80e82b8e 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -685,14 +685,342 @@ int main(int argc, char **argp)
 }
 
 -------------------------------------------------------------------------------
++ AF_PACKET TPACKET_V3 example
+-------------------------------------------------------------------------------
+
+AF_PACKET's TPACKET_V3 ring buffer can be configured to use non-static frame
+sizes by doing it's own memory management. It is based on blocks where polling
+works on a per block basis instead of per ring as in TPACKET_V2 and predecessor.
+
+It is said that TPACKET_V3 brings the following benefits:
+ *) ~15 - 20% reduction in CPU-usage
+ *) ~20% increase in packet capture rate
+ *) ~2x increase in packet density
+ *) Port aggregation analysis
+ *) Non static frame size to capture entire packet payload
+
+So it seems to be a good candidate to be used with packet fanout.
+
+Minimal example code by Daniel Borkmann based on Chetan Loke's lolpcap (compile
+it with gcc -Wall -O2 blob.c, and try things like "./a.out eth0", etc.):
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <string.h>
+#include <assert.h>
+#include <net/if.h>
+#include <arpa/inet.h>
+#include <netdb.h>
+#include <poll.h>
+#include <unistd.h>
+#include <signal.h>
+#include <inttypes.h>
+#include <sys/socket.h>
+#include <sys/mman.h>
+#include <linux/if_packet.h>
+#include <linux/if_ether.h>
+#include <linux/ip.h>
+
+#define BLOCK_SIZE              (1 << 22)
+#define FRAME_SIZE              2048
+
+#define NUM_BLOCKS              64
+#define NUM_FRAMES              ((BLOCK_SIZE * NUM_BLOCKS) / FRAME_SIZE)
+
+#define BLOCK_RETIRE_TOV_IN_MS  64
+#define BLOCK_PRIV_AREA_SZ      13
+
+#define ALIGN_8(x)              (((x) + 8 - 1) & ~(8 - 1))
+
+#define BLOCK_STATUS(x)         ((x)->h1.block_status)
+#define BLOCK_NUM_PKTS(x)       ((x)->h1.num_pkts)
+#define BLOCK_O2FP(x)           ((x)->h1.offset_to_first_pkt)
+#define BLOCK_LEN(x)            ((x)->h1.blk_len)
+#define BLOCK_SNUM(x)           ((x)->h1.seq_num)
+#define BLOCK_O2PRIV(x)         ((x)->offset_to_priv)
+#define BLOCK_PRIV(x)           ((void *) ((uint8_t *) (x) + BLOCK_O2PRIV(x)))
+#define BLOCK_HDR_LEN           (ALIGN_8(sizeof(struct block_desc)))
+#define BLOCK_PLUS_PRIV(sz_pri) (BLOCK_HDR_LEN + ALIGN_8((sz_pri)))
+
+#ifndef likely
+# define likely(x)              __builtin_expect(!!(x), 1)
+#endif
+#ifndef unlikely
+# define unlikely(x)            __builtin_expect(!!(x), 0)
+#endif
+
+struct block_desc {
+        uint32_t version;
+        uint32_t offset_to_priv;
+        struct tpacket_hdr_v1 h1;
+};
+
+struct ring {
+        struct iovec *rd;
+        uint8_t *map;
+        struct tpacket_req3 req;
+};
+
+static unsigned long packets_total = 0, bytes_total = 0;
+static sig_atomic_t sigint = 0;
+
+void sighandler(int num)
+{
+        sigint = 1;
+}
+
+static int setup_socket(struct ring *ring, char *netdev)
+{
+        int err, i, fd, v = TPACKET_V3;
+        struct sockaddr_ll ll;
+
+        fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
+        if (fd < 0) {
+                perror("socket");
+                exit(1);
+        }
+
+        err = setsockopt(fd, SOL_PACKET, PACKET_VERSION, &v, sizeof(v));
+        if (err < 0) {
+                perror("setsockopt");
+                exit(1);
+        }
+
+        memset(&ring->req, 0, sizeof(ring->req));
+        ring->req.tp_block_size = BLOCK_SIZE;
+        ring->req.tp_frame_size = FRAME_SIZE;
+        ring->req.tp_block_nr = NUM_BLOCKS;
+        ring->req.tp_frame_nr = NUM_FRAMES;
+        ring->req.tp_retire_blk_tov = BLOCK_RETIRE_TOV_IN_MS;
+        ring->req.tp_sizeof_priv = BLOCK_PRIV_AREA_SZ;
+        ring->req.tp_feature_req_word |= TP_FT_REQ_FILL_RXHASH;
+
+        err = setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &ring->req,
+                         sizeof(ring->req));
+        if (err < 0) {
+                perror("setsockopt");
+                exit(1);
+        }
+
+        ring->map = mmap(NULL, ring->req.tp_block_size * ring->req.tp_block_nr,
+                         PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED,
+                         fd, 0);
+        if (ring->map == MAP_FAILED) {
+                perror("mmap");
+                exit(1);
+        }
+
+        ring->rd = malloc(ring->req.tp_block_nr * sizeof(*ring->rd));
+        assert(ring->rd);
+        for (i = 0; i < ring->req.tp_block_nr; ++i) {
+                ring->rd[i].iov_base = ring->map + (i * ring->req.tp_block_size);
+                ring->rd[i].iov_len = ring->req.tp_block_size;
+        }
+
+        memset(&ll, 0, sizeof(ll));
+        ll.sll_family = PF_PACKET;
+        ll.sll_protocol = htons(ETH_P_ALL);
+        ll.sll_ifindex = if_nametoindex(netdev);
+        ll.sll_hatype = 0;
+        ll.sll_pkttype = 0;
+        ll.sll_halen = 0;
+
+        err = bind(fd, (struct sockaddr *) &ll, sizeof(ll));
+        if (err < 0) {
+                perror("bind");
+                exit(1);
+        }
+
+        return fd;
+}
+
+#ifdef __checked
+static uint64_t prev_block_seq_num = 0;
+
+void assert_block_seq_num(struct block_desc *pbd)
+{
+        if (unlikely(prev_block_seq_num + 1 != BLOCK_SNUM(pbd))) {
+                printf("prev_block_seq_num:%"PRIu64", expected seq:%"PRIu64" != "
+                       "actual seq:%"PRIu64"\n", prev_block_seq_num,
+                       prev_block_seq_num + 1, (uint64_t) BLOCK_SNUM(pbd));
+                exit(1);
+        }
+
+        prev_block_seq_num = BLOCK_SNUM(pbd);
+}
+
+static void assert_block_len(struct block_desc *pbd, uint32_t bytes, int block_num)
+{
+        if (BLOCK_NUM_PKTS(pbd)) {
+                if (unlikely(bytes != BLOCK_LEN(pbd))) {
+                        printf("block:%u with %upackets, expected len:%u != actual len:%u\n",
+                               block_num, BLOCK_NUM_PKTS(pbd), bytes, BLOCK_LEN(pbd));
+                        exit(1);
+                }
+        } else {
+                if (unlikely(BLOCK_LEN(pbd) != BLOCK_PLUS_PRIV(BLOCK_PRIV_AREA_SZ))) {
+                        printf("block:%u, expected len:%lu != actual len:%u\n",
+                               block_num, BLOCK_HDR_LEN, BLOCK_LEN(pbd));
+                        exit(1);
+                }
+        }
+}
+
+static void assert_block_header(struct block_desc *pbd, const int block_num)
+{
+        uint32_t block_status = BLOCK_STATUS(pbd);
+
+        if (unlikely((block_status & TP_STATUS_USER) == 0)) {
+                printf("block:%u, not in TP_STATUS_USER\n", block_num);
+                exit(1);
+        }
+
+        assert_block_seq_num(pbd);
+}
+#else
+static inline void assert_block_header(struct block_desc *pbd, const int block_num)
+{
+}
+static void assert_block_len(struct block_desc *pbd, uint32_t bytes, int block_num)
+{
+}
+#endif
+
+static void display(struct tpacket3_hdr *ppd)
+{
+        struct ethhdr *eth = (struct ethhdr *) ((uint8_t *) ppd + ppd->tp_mac);
+        struct iphdr *ip = (struct iphdr *) ((uint8_t *) eth + ETH_HLEN);
+
+        if (eth->h_proto == htons(ETH_P_IP)) {
+                struct sockaddr_in ss, sd;
+                char sbuff[NI_MAXHOST], dbuff[NI_MAXHOST];
+
+                memset(&ss, 0, sizeof(ss));
+                ss.sin_family = PF_INET;
+                ss.sin_addr.s_addr = ip->saddr;
+                getnameinfo((struct sockaddr *) &ss, sizeof(ss),
+                            sbuff, sizeof(sbuff), NULL, 0, NI_NUMERICHOST);
+
+                memset(&sd, 0, sizeof(sd));
+                sd.sin_family = PF_INET;
+                sd.sin_addr.s_addr = ip->daddr;
+                getnameinfo((struct sockaddr *) &sd, sizeof(sd),
+                            dbuff, sizeof(dbuff), NULL, 0, NI_NUMERICHOST);
+
+                printf("%s -> %s, ", sbuff, dbuff);
+        }
+
+        printf("rxhash: 0x%x\n", ppd->hv1.tp_rxhash);
+}
+
+static void walk_block(struct block_desc *pbd, const int block_num)
+{
+        int num_pkts = BLOCK_NUM_PKTS(pbd), i;
+        unsigned long bytes = 0;
+        unsigned long bytes_with_padding = BLOCK_PLUS_PRIV(BLOCK_PRIV_AREA_SZ);
+        struct tpacket3_hdr *ppd;
+
+        assert_block_header(pbd, block_num);
+
+        ppd = (struct tpacket3_hdr *) ((uint8_t *) pbd + BLOCK_O2FP(pbd));
+        for (i = 0; i < num_pkts; ++i) {
+                bytes += ppd->tp_snaplen;
+                if (ppd->tp_next_offset)
+                        bytes_with_padding += ppd->tp_next_offset;
+                else
+                        bytes_with_padding += ALIGN_8(ppd->tp_snaplen + ppd->tp_mac);
+
+                display(ppd);
+
+                ppd = (struct tpacket3_hdr *) ((uint8_t *) ppd + ppd->tp_next_offset);
+                __sync_synchronize();
+        }
+
+        assert_block_len(pbd, bytes_with_padding, block_num);
+
+        packets_total += num_pkts;
+        bytes_total += bytes;
+}
+
+void flush_block(struct block_desc *pbd)
+{
+        BLOCK_STATUS(pbd) = TP_STATUS_KERNEL;
+        __sync_synchronize();
+}
+
+static void teardown_socket(struct ring *ring, int fd)
+{
+        munmap(ring->map, ring->req.tp_block_size * ring->req.tp_block_nr);
+        free(ring->rd);
+        close(fd);
+}
+
+int main(int argc, char **argp)
+{
+        int fd, err;
+        socklen_t len;
+        struct ring ring;
+        struct pollfd pfd;
+        unsigned int block_num = 0;
+        struct block_desc *pbd;
+        struct tpacket_stats_v3 stats;
+
+        if (argc != 2) {
+                fprintf(stderr, "Usage: %s INTERFACE\n", argp[0]);
+                return EXIT_FAILURE;
+        }
+
+        signal(SIGINT, sighandler);
+
+        memset(&ring, 0, sizeof(ring));
+        fd = setup_socket(&ring, argp[argc - 1]);
+        assert(fd > 0);
+
+        memset(&pfd, 0, sizeof(pfd));
+        pfd.fd = fd;
+        pfd.events = POLLIN | POLLERR;
+        pfd.revents = 0;
+
+        while (likely(!sigint)) {
+                pbd = (struct block_desc *) ring.rd[block_num].iov_base;
+retry_block:
+                if ((BLOCK_STATUS(pbd) & TP_STATUS_USER) == 0) {
+                        poll(&pfd, 1, -1);
+                        goto retry_block;
+                }
+
+                walk_block(pbd, block_num);
+                flush_block(pbd);
+                block_num = (block_num + 1) % NUM_BLOCKS;
+        }
+
+        len = sizeof(stats);
+        err = getsockopt(fd, SOL_PACKET, PACKET_STATISTICS, &stats, &len);
+        if (err < 0) {
+                perror("getsockopt");
+                exit(1);
+        }
+
+        fflush(stdout);
+        printf("\nReceived %u packets, %lu bytes, %u dropped, freeze_q_cnt: %u\n",
+               stats.tp_packets, bytes_total, stats.tp_drops,
+               stats.tp_freeze_q_cnt);
+
+        teardown_socket(&ring, fd);
+        return 0;
+}
+
+-------------------------------------------------------------------------------
 + PACKET_TIMESTAMP
 -------------------------------------------------------------------------------
 
 The PACKET_TIMESTAMP setting determines the source of the timestamp in
-the packet meta information.  If your NIC is capable of timestamping
-packets in hardware, you can request those hardware timestamps to used.
-Note: you may need to enable the generation of hardware timestamps with
-SIOCSHWTSTAMP.
+the packet meta information for mmap(2)ed RX_RING and TX_RINGs.  If your
+NIC is capable of timestamping packets in hardware, you can request those
+hardware timestamps to be used. Note: you may need to enable the generation
+of hardware timestamps with SIOCSHWTSTAMP (see related information from
+Documentation/networking/timestamping.txt).
 
 PACKET_TIMESTAMP accepts the same integer bit field as
 SO_TIMESTAMPING.  However, only the SOF_TIMESTAMPING_SYS_HARDWARE
@@ -704,8 +1032,36 @@ SOF_TIMESTAMPING_RAW_HARDWARE if both bits are set.
     req |= SOF_TIMESTAMPING_SYS_HARDWARE;
     setsockopt(fd, SOL_PACKET, PACKET_TIMESTAMP, (void *) &req, sizeof(req))
 
-If PACKET_TIMESTAMP is not set, a software timestamp generated inside
-the networking stack is used (the behavior before this setting was added).
+For the mmap(2)ed ring buffers, such timestamps are stored in the
+tpacket{,2,3}_hdr structure's tp_sec and tp_{n,u}sec members. To determine
+what kind of timestamp has been reported, the tp_status field is binary |'ed
+with the following possible bits ...
+
+    TP_STATUS_TS_SYS_HARDWARE
+    TP_STATUS_TS_RAW_HARDWARE
+    TP_STATUS_TS_SOFTWARE
+
+... that are equivalent to its SOF_TIMESTAMPING_* counterparts. For the
+RX_RING, if none of those 3 are set (i.e. PACKET_TIMESTAMP is not set),
+then this means that a software fallback was invoked *within* PF_PACKET's
+processing code (less precise).
+
+Getting timestamps for the TX_RING works as follows: i) fill the ring frames,
+ii) call sendto() e.g. in blocking mode, iii) wait for status of relevant
+frames to be updated resp. the frame handed over to the application, iv) walk
+through the frames to pick up the individual hw/sw timestamps.
+
+Only (!) if transmit timestamping is enabled, then these bits are combined
+with binary | with TP_STATUS_AVAILABLE, so you must check for that in your
+application (e.g. !(tp_status & (TP_STATUS_SEND_REQUEST | TP_STATUS_SENDING))
+in a first step to see if the frame belongs to the application, and then
+one can extract the type of timestamp in a second step from tp_status)!
+
+If you don't care about them, thus having it disabled, checking for
+TP_STATUS_AVAILABLE resp. TP_STATUS_WRONG_FORMAT is sufficient. If in the
+TX_RING part only TP_STATUS_AVAILABLE is set, then the tp_sec and tp_{n,u}sec
+members do not contain a valid value. For TX_RINGs, by default no timestamp
+is generated!
 
 See include/linux/net_tstamp.h and Documentation/networking/timestamping
 for more information on hardware timestamps.
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index f9fa6db40a52..654d2e55c8cb 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -1,6 +1,6 @@
        STMicroelectronics 10/100/1000 Synopsys Ethernet driver
 
-Copyright (C) 2007-2010  STMicroelectronics Ltd
+Copyright (C) 2007-2013  STMicroelectronics Ltd
 Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>
 
 This is the driver for the MAC 10/100/1000 on-chip Ethernet controllers
@@ -10,7 +10,7 @@ Currently this network device driver is for all STM embedded MAC/GMAC
 (i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XLINX XC2V3000
 FF1152AMT0221 D1215994A VIRTEX FPGA board.
 
-DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether
+DWC Ether MAC 10/100/1000 Universal version 3.70a (and older) and DWC Ether
 MAC 10/100 Universal version 4.0 have been used for developing this driver.
 
 This driver supports both the platform bus and PCI.
@@ -32,6 +32,8 @@ The kernel configuration option is STMMAC_ETH:
         watchdog: transmit timeout (in milliseconds);
         flow_ctrl: Flow control ability [on/off];
         pause: Flow Control Pause Time;
+        eee_timer: tx EEE timer;
+        chain_mode: select chain mode instead of ring.
 
 3) Command line options
 Driver parameters can be also passed in command line by using:
@@ -164,12 +166,12 @@ Where:
  o bus_setup: perform HW setup of the bus. For example, on some ST platforms
              this field is used to configure the AMBA  bridge to generate more
              efficient STBus traffic.
- o init/exit: callbacks used for calling a custom initialisation;
+ o init/exit: callbacks used for calling a custom initialization;
              this is sometime necessary on some platforms (e.g. ST boxes)
              where the HW needs to have set some PIO lines or system cfg
              registers.
  o custom_cfg/custom_data: this is a custom configuration that can be passed
-                           while initialising the resources.
+                           while initializing the resources.
  o bsp_priv: another private poiter.
 
 For MDIO bus The we have:
@@ -273,6 +275,8 @@ reset procedure etc).
  o norm_desc.c: functions for handling normal descriptors;
  o chain_mode.c/ring_mode.c:: functions to manage RING/CHAINED modes;
  o mmc_core.c/mmc.h: Management MAC Counters;
+ o stmmac_hwtstamp.c: HW timestamp support for PTP
+ o stmmac_ptp.c: PTP 1588 clock
 
 5) Debug Information
 
@@ -326,6 +330,35 @@ To enter in Tx LPI mode the driver needs to have a software timer
 that enable and disable the LPI mode when there is nothing to be
 transmitted.
 
-7) TODO:
+7) Extended descriptors
+The extended descriptors give us information about the receive Ethernet payload
+when it is carrying PTP packets or TCP/UDP/ICMP over IP.
+These are not available on GMAC Synopsys chips older than the 3.50.
+At probe time the driver will decide if these can be actually used.
+This support also is mandatory for PTPv2 because the extra descriptors 6 and 7
+are used for saving the hardware timestamps.
+
+8) Precision Time Protocol (PTP)
+The driver supports the IEEE 1588-2002, Precision Time Protocol (PTP),
+which enables precise synchronization of clocks in measurement and
+control systems implemented with technologies such as network
+communication.
+
+In addition to the basic timestamp features mentioned in IEEE 1588-2002
+Timestamps, new GMAC cores support the advanced timestamp features.
+IEEE 1588-2008 that can be enabled when configure the Kernel.
+
+9) SGMII/RGMII supports
+New GMAC devices provide own way to manage RGMII/SGMII.
+This information is available at run-time by looking at the
+HW capability register. This means that the stmmac can manage
+auto-negotiation and link status w/o using the PHYLIB stuff
+In fact, the HW provides a subset of extended registers to
+restart the ANE, verify Full/Half duplex mode and Speed.
+Also thanks to these registers it is possible to look at the
+Auto-negotiated Link Parter Ability.
+
+10) TODO:
  o XGMAC is not supported.
- o Add the PTP - precision time protocol
+ o Complete the TBI & RTBI support.
+ o extened VLAN support for 3.70a SYNP GMAC.
diff --git a/Documentation/networking/tuntap.txt b/Documentation/networking/tuntap.txt
index c0aab985bad9..949d5dcdd9a3 100644
--- a/Documentation/networking/tuntap.txt
+++ b/Documentation/networking/tuntap.txt
@@ -105,6 +105,83 @@ Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
      Proto [2 bytes]
      Raw protocol(IP, IPv6, etc) frame.
 
+  3.3 Multiqueue tuntap interface:
+
+  From version 3.8, Linux supports multiqueue tuntap which can uses multiple
+  file descriptors (queues) to parallelize packets sending or receiving. The
+  device allocation is the same as before, and if user wants to create multiple
+  queues, TUNSETIFF with the same device name must be called many times with
+  IFF_MULTI_QUEUE flag.
+
+  char *dev should be the name of the device, queues is the number of queues to
+  be created, fds is used to store and return the file descriptors (queues)
+  created to the caller. Each file descriptor were served as the interface of a
+  queue which could be accessed by userspace.
+
+  #include <linux/if.h>
+  #include <linux/if_tun.h>
+
+  int tun_alloc_mq(char *dev, int queues, int *fds)
+  {
+      struct ifreq ifr;
+      int fd, err, i;
+
+      if (!dev)
+          return -1;
+
+      memset(&ifr, 0, sizeof(ifr));
+      /* Flags: IFF_TUN   - TUN device (no Ethernet headers)
+       *        IFF_TAP   - TAP device
+       *
+       *        IFF_NO_PI - Do not provide packet information
+       *        IFF_MULTI_QUEUE - Create a queue of multiqueue device
+       */
+      ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_MULTI_QUEUE;
+      strcpy(ifr.ifr_name, dev);
+
+      for (i = 0; i < queues; i++) {
+          if ((fd = open("/dev/net/tun", O_RDWR)) < 0)
+             goto err;
+          err = ioctl(fd, TUNSETIFF, (void *)&ifr);
+          if (err) {
+             close(fd);
+             goto err;
+          }
+          fds[i] = fd;
+      }
+
+      return 0;
+  err:
+      for (--i; i >= 0; i--)
+          close(fds[i]);
+      return err;
+  }
+
+  A new ioctl(TUNSETQUEUE) were introduced to enable or disable a queue. When
+  calling it with IFF_DETACH_QUEUE flag, the queue were disabled. And when
+  calling it with IFF_ATTACH_QUEUE flag, the queue were enabled. The queue were
+  enabled by default after it was created through TUNSETIFF.
+
+  fd is the file descriptor (queue) that we want to enable or disable, when
+  enable is true we enable it, otherwise we disable it
+
+  #include <linux/if.h>
+  #include <linux/if_tun.h>
+
+  int tun_set_queue(int fd, int enable)
+  {
+      struct ifreq ifr;
+
+      memset(&ifr, 0, sizeof(ifr));
+
+      if (enable)
+         ifr.ifr_flags = IFF_ATTACH_QUEUE;
+      else
+         ifr.ifr_flags = IFF_DETACH_QUEUE;
+
+      return ioctl(fd, TUNSETQUEUE, (void *)&ifr);
+  }
+
 Universal TUN/TAP device driver Frequently Asked Question.
    
 1. What platforms are supported by TUN/TAP driver ?
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index a2b57e0a1db0..447fd4cd54ec 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -736,6 +736,13 @@ All the above functions are mandatory to implement for a pinmux driver.
 Pin control interaction with the GPIO subsystem
 ===============================================
 
+Note that the following implies that the use case is to use a certain pin
+from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
+and similar functions. There are cases where you may be using something
+that your datasheet calls "GPIO mode" but actually is just an electrical
+configuration for a certain device. See the section below named
+"GPIO mode pitfalls" for more details on this scenario.
+
 The public pinmux API contains two functions named pinctrl_request_gpio()
 and pinctrl_free_gpio(). These two functions shall *ONLY* be called from
 gpiolib-based drivers as part of their gpio_request() and
@@ -774,6 +781,111 @@ obtain the function "gpioN" where "N" is the global GPIO pin number if no
 special GPIO-handler is registered.
 
 
+GPIO mode pitfalls
+==================
+
+Sometime the developer may be confused by a datasheet talking about a pin
+being possible to set into "GPIO mode". It appears that what hardware
+engineers mean with "GPIO mode" is not necessarily the use case that is
+implied in the kernel interface <linux/gpio.h>: a pin that you grab from
+kernel code and then either listen for input or drive high/low to
+assert/deassert some external line.
+
+Rather hardware engineers think that "GPIO mode" means that you can
+software-control a few electrical properties of the pin that you would
+not be able to control if the pin was in some other mode, such as muxed in
+for a device.
+
+Example: a pin is usually muxed in to be used as a UART TX line. But during
+system sleep, we need to put this pin into "GPIO mode" and ground it.
+
+If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
+to think that you need to come up with something real complex, that the
+pin shall be used for UART TX and GPIO at the same time, that you will grab
+a pin control handle and set it to a certain state to enable UART TX to be
+muxed in, then twist it over to GPIO mode and use gpio_direction_output()
+to drive it low during sleep, then mux it over to UART TX again when you
+wake up and maybe even gpio_request/gpio_free as part of this cycle. This
+all gets very complicated.
+
+The solution is to not think that what the datasheet calls "GPIO mode"
+has to be handled by the <linux/gpio.h> interface. Instead view this as
+a certain pin config setting. Look in e.g. <linux/pinctrl/pinconf-generic.h>
+and you find this in the documentation:
+
+  PIN_CONFIG_OUTPUT: this will configure the pin in output, use argument
+     1 to indicate high level, argument 0 to indicate low level.
+
+So it is perfectly possible to push a pin into "GPIO mode" and drive the
+line low as part of the usual pin control map. So for example your UART
+driver may look like this:
+
+#include <linux/pinctrl/consumer.h>
+
+struct pinctrl          *pinctrl;
+struct pinctrl_state    *pins_default;
+struct pinctrl_state    *pins_sleep;
+
+pins_default = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_DEFAULT);
+pins_sleep = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_SLEEP);
+
+/* Normal mode */
+retval = pinctrl_select_state(pinctrl, pins_default);
+/* Sleep mode */
+retval = pinctrl_select_state(pinctrl, pins_sleep);
+
+And your machine configuration may look like this:
+--------------------------------------------------
+
+static unsigned long uart_default_mode[] = {
+    PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
+};
+
+static unsigned long uart_sleep_mode[] = {
+    PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
+};
+
+static struct pinctrl_map __initdata pinmap[] = {
+    PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
+                      "u0_group", "u0"),
+    PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
+                        "UART_TX_PIN", uart_default_mode),
+    PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
+                      "u0_group", "gpio-mode"),
+    PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
+                        "UART_TX_PIN", uart_sleep_mode),
+};
+
+foo_init(void) {
+    pinctrl_register_mappings(pinmap, ARRAY_SIZE(pinmap));
+}
+
+Here the pins we want to control are in the "u0_group" and there is some
+function called "u0" that can be enabled on this group of pins, and then
+everything is UART business as usual. But there is also some function
+named "gpio-mode" that can be mapped onto the same pins to move them into
+GPIO mode.
+
+This will give the desired effect without any bogus interaction with the
+GPIO subsystem. It is just an electrical configuration used by that device
+when going to sleep, it might imply that the pin is set into something the
+datasheet calls "GPIO mode" but that is not the point: it is still used
+by that UART device to control the pins that pertain to that very UART
+driver, putting them into modes needed by the UART. GPIO in the Linux
+kernel sense are just some 1-bit line, and is a different use case.
+
+How the registers are poked to attain the push/pull and output low
+configuration and the muxing of the "u0" or "gpio-mode" group onto these
+pins is a question for the driver.
+
+Some datasheets will be more helpful and refer to the "GPIO mode" as
+"low power mode" rather than anything to do with GPIO. This often means
+the same thing electrically speaking, but in this latter case the
+software engineers will usually quickly identify that this is some
+specific muxing/configuration rather than anything related to the GPIO
+API.
+
+
 Board/machine configuration
 ==================================
 
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index 3035d00757ad..425c51d56aef 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -1,6 +1,5 @@
-*=============*
-* OPP Library *
-*=============*
+Operating Performance Points (OPP) Library
+==========================================
 
 (C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated
 
@@ -16,15 +15,31 @@ Contents
 
 1. Introduction
 ===============
+1.1 What is an Operating Performance Point (OPP)?
+
 Complex SoCs of today consists of a multiple sub-modules working in conjunction.
 In an operational system executing varied use cases, not all modules in the SoC
 need to function at their highest performing frequency all the time. To
 facilitate this, sub-modules in a SoC are grouped into domains, allowing some
-domains to run at lower voltage and frequency while other domains are loaded
-more. The set of discrete tuples consisting of frequency and voltage pairs that
+domains to run at lower voltage and frequency while other domains run at
+voltage/frequency pairs that are higher.
+
+The set of discrete tuples consisting of frequency and voltage pairs that
 the device will support per domain are called Operating Performance Points or
 OPPs.
 
+As an example:
+Let us consider an MPU device which supports the following:
+{300MHz at minimum voltage of 1V}, {800MHz at minimum voltage of 1.2V},
+{1GHz at minimum voltage of 1.3V}
+
+We can represent these as three OPPs as the following {Hz, uV} tuples:
+{300000000, 1000000}
+{800000000, 1200000}
+{1000000000, 1300000}
+
+1.2 Operating Performance Points Library
+
 OPP library provides a set of helper functions to organize and query the OPP
 information. The library is located in drivers/base/power/opp.c and the header
 is located in include/linux/opp.h. OPP library can be enabled by enabling
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index 5620fb5ac425..dd9e92802ec0 100644
--- a/Documentation/powerpc/00-INDEX
+++ b/Documentation/powerpc/00-INDEX
@@ -14,10 +14,6 @@ hvcs.txt
         - IBM "Hypervisor Virtual Console Server" Installation Guide
 mpc52xx.txt
         - Linux 2.6.x on MPC52xx family
-sound.txt
-        - info on sound support under Linux/PPC
-zImage_layout.txt
-        - info on the kernel images for Linux/PPC
 qe_firmware.txt
         - describes the layout of firmware binaries for the Freescale QUICC
           Engine and the code that parses and uploads the microcode therein.
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
index f2a7a3919772..99c5ce88d0fe 100644
--- a/Documentation/powerpc/ptrace.txt
+++ b/Documentation/powerpc/ptrace.txt
@@ -40,6 +40,7 @@ features will have bits indicating whether there is support for:
 #define PPC_DEBUG_FEATURE_INSN_BP_MASK          0x2
 #define PPC_DEBUG_FEATURE_DATA_BP_RANGE         0x4
 #define PPC_DEBUG_FEATURE_DATA_BP_MASK          0x8
+#define PPC_DEBUG_FEATURE_DATA_BP_DAWR          0x10
 
 2. PTRACE_SETHWDEBUG
 
diff --git a/Documentation/powerpc/sound.txt b/Documentation/powerpc/sound.txt
deleted file mode 100644
index df23d95e03a0..000000000000
--- a/Documentation/powerpc/sound.txt
+++ /dev/null
@@ -1,81 +0,0 @@
-            Information about PowerPC Sound support
-=====================================================================
-
-Please mail me (Cort Dougan, cort@fsmlabs.com) if you have questions,
-comments or corrections.
-
-Last Change: 6.16.99
-
-This just covers sound on the PReP and CHRP systems for now and later
-will contain information on the PowerMac's.
-
-Sound on PReP has been tested and is working with the PowerStack and IBM
-Power Series onboard sound systems which are based on the cs4231(2) chip.
-The sound options when doing the make config are a bit different from
-the default, though.
-
-The I/O base, irq and dma lines that you enter during the make config
-are ignored and are set when booting according to the machine type.
-This is so that one binary can be used for Motorola and IBM machines
-which use different values and isn't allowed by the driver, so things
-are hacked together in such a way as to allow this information to be
-set automatically on boot.
-
-1. Motorola PowerStack PReP machines
-
-  Enable support for "Crystal CS4232 based (PnP) cards" and for the
-  Microsoft Sound System.  The MSS isn't used, but some of the routines
-  that the CS4232 driver uses are in it.
-
-  Although the options you set are ignored and determined automatically
-  on boot these are included for information only:
-
-  (830) CS4232 audio I/O base 530, 604, E80 or F40
-  (10) CS4232 audio IRQ 5, 7, 9, 11, 12 or 15
-  (6) CS4232 audio DMA 0, 1 or 3
-  (7) CS4232 second (duplex) DMA 0, 1 or 3
-
-  This will allow simultaneous record and playback, as 2 different dma
-  channels are used.
-
-  The sound will be all left channel and very low volume since the
-  auxiliary input isn't muted by default.  I had the changes necessary
-  for this in the kernel but the sound driver maintainer didn't want
-  to include them since it wasn't common in other machines.  To fix this
-  you need to mute it using a mixer utility of some sort (if you find one
-  please let me know) or by patching the driver yourself and recompiling.
-
-  There is a problem on the PowerStack 2's (PowerStack Pro's) using a
-  different irq/drq than the kernel expects.  Unfortunately, I don't know
-  which irq/drq it is so if anyone knows please email me.
-
-  Midi is not supported since the cs4232 driver doesn't support midi yet.
-
-2. IBM PowerPersonal PReP machines
-
-  I've only tested sound on the Power Personal Series of IBM workstations
-  so if you try it on others please let me know the result.  I'm especially
-  interested in the 43p's sound system, which I know nothing about.
-
-  Enable support for "Crystal CS4232 based (PnP) cards" and for the
-  Microsoft Sound System.  The MSS isn't used, but some of the routines
-  that the CS4232 driver uses are in it.
-
-  Although the options you set are ignored and determined automatically
-  on boot these are included for information only:
-
-  (530) CS4232 audio I/O base 530, 604, E80 or F40
-  (5) CS4232 audio IRQ 5, 7, 9, 11, 12 or 15
-  (1) CS4232 audio DMA 0, 1 or 3
-  (7) CS4232 second (duplex) DMA 0, 1 or 3
-  (330) CS4232 MIDI I/O base 330, 370, 3B0 or 3F0
-  (9) CS4232 MIDI IRQ 5, 7, 9, 11, 12 or 15
-
-  This setup does _NOT_ allow for recording yet.
-
-  Midi is not supported since the cs4232 driver doesn't support midi yet.
-
-2. IBM CHRP
-
-  I have only tested this on the 43P-150.  Build the kernel with the cs4232
-  set as a module and load the module with irq=9 dma=1 dma2=2 io=0x550
diff --git a/Documentation/powerpc/zImage_layout.txt b/Documentation/powerpc/zImage_layout.txt
deleted file mode 100644
index 048e0150f571..000000000000
--- a/Documentation/powerpc/zImage_layout.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-          Information about the Linux/PPC kernel images
-=====================================================================
-
-Please mail me (Cort Dougan, cort@fsmlabs.com) if you have questions,
-comments or corrections.
-
-This document is meant to answer several questions I've had about how
-the PReP system boots and how Linux/PPC interacts with that mechanism.
-It would be nice if we could have information on how other architectures
-boot here as well.  If you have anything to contribute, please
-let me know.
-
-
-1. PReP boot file
-
-  This is the file necessary to boot PReP systems from floppy or
-  hard drive.  The firmware reads the PReP partition table entry
-  and will load the image accordingly.
-
-  To boot the zImage, copy it onto a floppy with dd if=zImage of=/dev/fd0h1440
-  or onto a PReP hard drive partition with dd if=zImage of=/dev/sda4
-  assuming you've created a PReP partition (type 0x41) with fdisk on
-  /dev/sda4.
-
-  The layout of the image format is:
-
-  0x0     +------------+
-          |            | PReP partition table entry
-          |            |
-  0x400   +------------+
-          |            | Bootstrap program code + data
-          |            |
-          |            |
-          +------------+
-          |            | compressed kernel, elf header removed
-          +------------+
-          |            | initrd (if loaded)
-          +------------+
-          |            | Elf section table for bootstrap program
-          +------------+
-
-
-2. MBX boot file
-
-  The MBX boards can load an elf image, and relocate it to the
-  proper location in memory - it copies the image to the location it was
-  linked at.
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index e8a6aa473bab..3af5ae6c9c11 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -17,6 +17,8 @@ Symbols/Function Pointers:
         %pF     versatile_init+0x0/0x110
         %pf     versatile_init
         %pS     versatile_init+0x0/0x110
+        %pSR    versatile_init+0x9/0x110
+                (with __builtin_extract_return_addr() translation)
         %ps     versatile_init
         %pB     prev_fn_of_versatile_init+0x88/0x88
 
@@ -170,5 +172,5 @@ Reminder: sizeof() result is of type size_t.
 Thank you for your cooperation and attention.
 
 
-By Randy Dunlap <rdunlap@xenotime.net> and
+By Randy Dunlap <rdunlap@infradead.org> and
 Andrew Murray <amurray@mpc-data.co.uk>
diff --git a/Documentation/s390/CommonIO b/Documentation/s390/CommonIO
index d378cba66456..6e0f63f343b4 100644
--- a/Documentation/s390/CommonIO
+++ b/Documentation/s390/CommonIO
@@ -8,9 +8,9 @@ Command line parameters
 
   Enable logging of debug information in case of ccw device timeouts.
 
-* cio_ignore = {all} |
-               {<device> | <range of devices>} |
-               {!<device> | !<range of devices>}
+* cio_ignore = device[,device[,..]]
+
+        device := {all | [!]ipldev | [!]condev | [!]<devno> | [!]<devno>-<devno>}
 
   The given devices will be ignored by the common I/O-layer; no detection
   and device sensing will be done on any of those devices. The subchannel to 
@@ -24,8 +24,10 @@ Command line parameters
   device numbers (0xabcd or abcd, for 2.4 backward compatibility). If you
   give a device number 0xabcd, it will be interpreted as 0.0.abcd.
 
-  You can use the 'all' keyword to ignore all devices.
-  The '!' operator will cause the I/O-layer to _not_ ignore a device.
+  You can use the 'all' keyword to ignore all devices. The 'ipldev' and 'condev'
+  keywords can be used to refer to the CCW based boot device and CCW console
+  device respectively (these are probably useful only when combined with the '!'
+  operator). The '!' operator will cause the I/O-layer to _not_ ignore a device.
   The command line is parsed from left to right.
 
   For example, 
diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt
index ae66f9b90a25..fcaf0b4efba2 100644
--- a/Documentation/s390/s390dbf.txt
+++ b/Documentation/s390/s390dbf.txt
@@ -143,7 +143,8 @@ Parameter:     id:   handle for debug log
 
 Return Value:  none 
 
-Description:   frees memory for a debug log     
+Description:   frees memory for a debug log and removes all registered debug
+               views.
                Must not be called within an interrupt handler 
 
 ---------------------------------------------------------------------------
diff --git a/Documentation/scsi/LICENSE.qla2xxx b/Documentation/scsi/LICENSE.qla2xxx
index 27a91cf43d6d..5020b7b5a244 100644
--- a/Documentation/scsi/LICENSE.qla2xxx
+++ b/Documentation/scsi/LICENSE.qla2xxx
@@ -1,4 +1,4 @@
-Copyright (c) 2003-2012 QLogic Corporation
+Copyright (c) 2003-2013 QLogic Corporation
 QLogic Linux FC-FCoE Driver
 
 This program includes a device driver for Linux 3.x.
diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt
index 8a177e4b6e21..7a2d30c132e3 100644
--- a/Documentation/security/Smack.txt
+++ b/Documentation/security/Smack.txt
@@ -117,6 +117,17 @@ access2
 ambient
         This contains the Smack label applied to unlabeled network
         packets.
+change-rule
+        This interface allows modification of existing access control rules.
+        The format accepted on write is:
+                "%s %s %s %s"
+        where the first string is the subject label, the second the
+        object label, the third the access to allow and the fourth the
+        access to deny. The access strings may contain only the characters
+        "rwxat-". If a rule for a given subject and object exists it will be
+        modified by enabling the permissions in the third string and disabling
+        those in the fourth string. If there is no such rule it will be
+        created using the access specified in the third and the fourth strings.
 cipso
         This interface allows a specific CIPSO header to be assigned
         to a Smack label. The format accepted on write is:
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index ce6581c8ca26..95731a08f257 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -890,9 +890,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
     enable_msi  - Enable Message Signaled Interrupt (MSI) (default = off)
     power_save  - Automatic power-saving timeout (in second, 0 =
                 disable)
-    power_save_controller - Support runtime D3 of HD-audio controller
-                (-1 = on for supported chip (default), false = off,
-                 true = force to on even for unsupported hardware)
+    power_save_controller - Reset HD-audio controller in power-saving mode
+                (default = on)
     align_buffer_size - Force rounding of buffer/period sizes to multiples
                       of 128 bytes. This is more efficient in terms of memory
                       access but isn't required by the HDA spec and prevents
@@ -912,7 +911,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
     models depending on the codec chip.  The list of available models
     is found in HD-Audio-Models.txt
 
-    The model name "genric" is treated as a special case.  When this
+    The model name "generic" is treated as a special case.  When this
     model is given, the driver uses the generic codec parser without
     "codec-patch".  It's sometimes good for testing and debugging.
 
diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt
index d4faa63ff352..c3c912d023cc 100644
--- a/Documentation/sound/alsa/HD-Audio.txt
+++ b/Documentation/sound/alsa/HD-Audio.txt
@@ -461,11 +461,13 @@ The generic parser supports the following hints:
   the corresponding mixer control, if available
 - add_stereo_mix_input (bool): add the stereo mix (analog-loopback
   mix) to the input mux if available
-- add_out_jack_modes (bool): add "xxx Jack Mode" enum controls to each
-  output jack for allowing to change the headphone amp capability
-- add_in_jack_modes (bool): add "xxx Jack Mode" enum controls to each
-  input jack for allowing to change the mic bias vref
+- add_jack_modes (bool): add "xxx Jack Mode" enum controls to each
+  I/O jack for allowing to change the headphone amp and mic bias VREF
+  capabilities
 - power_down_unused (bool): power down the unused widgets
+- add_hp_mic (bool): add the headphone to capture source if possible
+- hp_mic_detect (bool): enable/disable the hp/mic shared input for a
+  single built-in mic case; default true
 - mixer_nid (int): specifies the widget NID of the analog-loopback
   mixer
 
diff --git a/Documentation/sound/alsa/seq_oss.html b/Documentation/sound/alsa/seq_oss.html
index d9776cf60c07..9663b45f6fde 100644
--- a/Documentation/sound/alsa/seq_oss.html
+++ b/Documentation/sound/alsa/seq_oss.html
@@ -285,7 +285,7 @@ sample data.
 <H4>
 7.2.4 Close Callback</H4>
 The <TT>close</TT> callback is called when this device is closed by the
-applicaion. If any private data was allocated in open callback, it must
+application. If any private data was allocated in open callback, it must
 be released in the close callback. The deletion of ALSA port should be
 done here, too. This callback must not be NULL.
 <H4>
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 078701fdbd4d..dcc75a9ed919 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -18,6 +18,7 @@ files can be found in mm/swap.c.
 
 Currently, these files are in /proc/sys/vm:
 
+- admin_reserve_kbytes
 - block_dump
 - compact_memory
 - dirty_background_bytes
@@ -53,11 +54,41 @@ Currently, these files are in /proc/sys/vm:
 - percpu_pagelist_fraction
 - stat_interval
 - swappiness
+- user_reserve_kbytes
 - vfs_cache_pressure
 - zone_reclaim_mode
 
 ==============================================================
 
+admin_reserve_kbytes
+
+The amount of free memory in the system that should be reserved for users
+with the capability cap_sys_admin.
+
+admin_reserve_kbytes defaults to min(3% of free pages, 8MB)
+
+That should provide enough for the admin to log in and kill a process,
+if necessary, under the default overcommit 'guess' mode.
+
+Systems running under overcommit 'never' should increase this to account
+for the full Virtual Memory Size of programs used to recover. Otherwise,
+root may not be able to log in to recover the system.
+
+How do you calculate a minimum useful reserve?
+
+sshd or login + bash (or some other shell) + top (or ps, kill, etc.)
+
+For overcommit 'guess', we can sum resident set sizes (RSS).
+On x86_64 this is about 8MB.
+
+For overcommit 'never', we can take the max of their virtual sizes (VSZ)
+and add the sum of their RSS.
+On x86_64 this is about 128MB.
+
+Changing this takes effect whenever an application requests memory.
+
+==============================================================
+
 block_dump
 
 block_dump enables block I/O debugging when set to a nonzero value. More
@@ -542,6 +573,7 @@ memory until it actually runs out.
 
 When this flag is 2, the kernel uses a "never overcommit"
 policy that attempts to prevent any overcommit of memory.
+Note that user_reserve_kbytes affects this policy.
 
 This feature can be very useful because there are a lot of
 programs that malloc() huge amounts of memory "just-in-case"
@@ -645,6 +677,24 @@ The default value is 60.
 
 ==============================================================
 
+- user_reserve_kbytes
+
+When overcommit_memory is set to 2, "never overommit" mode, reserve
+min(3% of current process size, user_reserve_kbytes) of free memory.
+This is intended to prevent a user from starting a single memory hogging
+process, such that they cannot recover (kill the hog).
+
+user_reserve_kbytes defaults to min(3% of the current process size, 128MB).
+
+If this is reduced to zero, then the user will be allowed to allocate
+all free memory with a single process, minus admin_reserve_kbytes.
+Any subsequent attempts to execute a command will result in
+"fork: Cannot allocate memory".
+
+Changing this takes effect whenever an application requests memory.
+
+==============================================================
+
 vfs_cache_pressure
 ------------------
 
diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt
index 2a4cdda4828e..8cb4d7842a5f 100644
--- a/Documentation/sysrq.txt
+++ b/Documentation/sysrq.txt
@@ -129,9 +129,9 @@ On all -  write a character to /proc/sysrq-trigger.  e.g.:
 
 *  Okay, so what can I use them for?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Well, un'R'aw is very handy when your X server or a svgalib program crashes.
+Well, unraw(r) is very handy when your X server or a svgalib program crashes.
 
-sa'K' (Secure Access Key) is useful when you want to be sure there is no
+sak(k) (Secure Access Key) is useful when you want to be sure there is no
 trojan program running at console which could grab your password
 when you would try to login. It will kill all programs on given console,
 thus letting you make sure that the login prompt you see is actually
@@ -143,20 +143,20 @@ IMPORTANT: such.                                                   :IMPORTANT
 useful when you want to exit a program that will not let you switch consoles.
 (For example, X or a svgalib program.)
 
-re'B'oot is good when you're unable to shut down. But you should also 'S'ync
-and 'U'mount first.
+reboot(b) is good when you're unable to shut down. But you should also
+sync(s) and umount(u) first.
 
-'C'rash can be used to manually trigger a crashdump when the system is hung.
+crash(c) can be used to manually trigger a crashdump when the system is hung.
 Note that this just triggers a crash if there is no dump mechanism available.
 
-'S'ync is great when your system is locked up, it allows you to sync your
+sync(s) is great when your system is locked up, it allows you to sync your
 disks and will certainly lessen the chance of data loss and fscking. Note
 that the sync hasn't taken place until you see the "OK" and "Done" appear
 on the screen. (If the kernel is really in strife, you may not ever get the
 OK or Done message...)
 
-'U'mount is basically useful in the same ways as 'S'ync. I generally 'S'ync,
-'U'mount, then re'B'oot when my system locks. It's saved me many a fsck.
+umount(u) is basically useful in the same ways as sync(s). I generally sync(s),
+umount(u), then reboot(b) when my system locks. It's saved me many a fsck.
 Again, the unmount (remount read-only) hasn't taken place until you see the
 "OK" and "Done" message appear on the screen.
 
@@ -165,11 +165,11 @@ kernel messages you do not want to see. Selecting '0' will prevent all but
 the most urgent kernel messages from reaching your console. (They will
 still be logged if syslogd/klogd are alive, though.)
 
-t'E'rm and k'I'll are useful if you have some sort of runaway process you
+term(e) and kill(i) are useful if you have some sort of runaway process you
 are unable to kill any other way, especially if it's spawning other
 processes.
 
-"'J'ust thaw it" is useful if your system becomes unresponsive due to a frozen
+"just thaw it(j)" is useful if your system becomes unresponsive due to a frozen
 (probably root) filesystem via the FIFREEZE ioctl.
 
 *  Sometimes SysRq seems to get 'stuck' after using it, what can I do?
diff --git a/Documentation/this_cpu_ops.txt b/Documentation/this_cpu_ops.txt
new file mode 100644
index 000000000000..1a4ce7e3e05f
--- /dev/null
+++ b/Documentation/this_cpu_ops.txt
@@ -0,0 +1,205 @@
+this_cpu operations
+-------------------
+
+this_cpu operations are a way of optimizing access to per cpu
+variables associated with the *currently* executing processor through
+the use of segment registers (or a dedicated register where the cpu
+permanently stored the beginning of the per cpu area for a specific
+processor).
+
+The this_cpu operations add a per cpu variable offset to the processor
+specific percpu base and encode that operation in the instruction
+operating on the per cpu variable.
+
+This means there are no atomicity issues between the calculation of
+the offset and the operation on the data. Therefore it is not
+necessary to disable preempt or interrupts to ensure that the
+processor is not changed between the calculation of the address and
+the operation on the data.
+
+Read-modify-write operations are of particular interest. Frequently
+processors have special lower latency instructions that can operate
+without the typical synchronization overhead but still provide some
+sort of relaxed atomicity guarantee. The x86 for example can execute
+RMV (Read Modify Write) instructions like inc/dec/cmpxchg without the
+lock prefix and the associated latency penalty.
+
+Access to the variable without the lock prefix is not synchronized but
+synchronization is not necessary since we are dealing with per cpu
+data specific to the currently executing processor. Only the current
+processor should be accessing that variable and therefore there are no
+concurrency issues with other processors in the system.
+
+On x86 the fs: or the gs: segment registers contain the base of the
+per cpu area. It is then possible to simply use the segment override
+to relocate a per cpu relative address to the proper per cpu area for
+the processor. So the relocation to the per cpu base is encoded in the
+instruction via a segment register prefix.
+
+For example:
+
+        DEFINE_PER_CPU(int, x);
+        int z;
+
+        z = this_cpu_read(x);
+
+results in a single instruction
+
+        mov ax, gs:[x]
+
+instead of a sequence of calculation of the address and then a fetch
+from that address which occurs with the percpu operations. Before
+this_cpu_ops such sequence also required preempt disable/enable to
+prevent the kernel from moving the thread to a different processor
+while the calculation is performed.
+
+The main use of the this_cpu operations has been to optimize counter
+operations.
+
+        this_cpu_inc(x)
+
+results in the following single instruction (no lock prefix!)
+
+        inc gs:[x]
+
+instead of the following operations required if there is no segment
+register.
+
+        int *y;
+        int cpu;
+
+        cpu = get_cpu();
+        y = per_cpu_ptr(&x, cpu);
+        (*y)++;
+        put_cpu();
+
+Note that these operations can only be used on percpu data that is
+reserved for a specific processor. Without disabling preemption in the
+surrounding code this_cpu_inc() will only guarantee that one of the
+percpu counters is correctly incremented. However, there is no
+guarantee that the OS will not move the process directly before or
+after the this_cpu instruction is executed. In general this means that
+the value of the individual counters for each processor are
+meaningless. The sum of all the per cpu counters is the only value
+that is of interest.
+
+Per cpu variables are used for performance reasons. Bouncing cache
+lines can be avoided if multiple processors concurrently go through
+the same code paths.  Since each processor has its own per cpu
+variables no concurrent cacheline updates take place. The price that
+has to be paid for this optimization is the need to add up the per cpu
+counters when the value of the counter is needed.
+
+
+Special operations:
+-------------------
+
+        y = this_cpu_ptr(&x)
+
+Takes the offset of a per cpu variable (&x !) and returns the address
+of the per cpu variable that belongs to the currently executing
+processor.  this_cpu_ptr avoids multiple steps that the common
+get_cpu/put_cpu sequence requires. No processor number is
+available. Instead the offset of the local per cpu area is simply
+added to the percpu offset.
+
+
+
+Per cpu variables and offsets
+-----------------------------
+
+Per cpu variables have *offsets* to the beginning of the percpu
+area. They do not have addresses although they look like that in the
+code. Offsets cannot be directly dereferenced. The offset must be
+added to a base pointer of a percpu area of a processor in order to
+form a valid address.
+
+Therefore the use of x or &x outside of the context of per cpu
+operations is invalid and will generally be treated like a NULL
+pointer dereference.
+
+In the context of per cpu operations
+
+        x is a per cpu variable. Most this_cpu operations take a cpu
+        variable.
+
+        &x is the *offset* a per cpu variable. this_cpu_ptr() takes
+        the offset of a per cpu variable which makes this look a bit
+        strange.
+
+
+
+Operations on a field of a per cpu structure
+--------------------------------------------
+
+Let's say we have a percpu structure
+
+        struct s {
+                int n,m;
+        };
+
+        DEFINE_PER_CPU(struct s, p);
+
+
+Operations on these fields are straightforward
+
+        this_cpu_inc(p.m)
+
+        z = this_cpu_cmpxchg(p.m, 0, 1);
+
+
+If we have an offset to struct s:
+
+        struct s __percpu *ps = &p;
+
+        z = this_cpu_dec(ps->m);
+
+        z = this_cpu_inc_return(ps->n);
+
+
+The calculation of the pointer may require the use of this_cpu_ptr()
+if we do not make use of this_cpu ops later to manipulate fields:
+
+        struct s *pp;
+
+        pp = this_cpu_ptr(&p);
+
+        pp->m--;
+
+        z = pp->n++;
+
+
+Variants of this_cpu ops
+-------------------------
+
+this_cpu ops are interrupt safe. Some architecture do not support
+these per cpu local operations. In that case the operation must be
+replaced by code that disables interrupts, then does the operations
+that are guaranteed to be atomic and then reenable interrupts. Doing
+so is expensive. If there are other reasons why the scheduler cannot
+change the processor we are executing on then there is no reason to
+disable interrupts. For that purpose the __this_cpu operations are
+provided. For example.
+
+        __this_cpu_inc(x);
+
+Will increment x and will not fallback to code that disables
+interrupts on platforms that cannot accomplish atomicity through
+address relocation and a Read-Modify-Write operation in the same
+instruction.
+
+
+
+&this_cpu_ptr(pp)->n vs this_cpu_ptr(&pp->n)
+--------------------------------------------
+
+The first operation takes the offset and forms an address and then
+adds the offset of the n field.
+
+The second one first adds the two offsets and then does the
+relocation.  IMHO the second form looks cleaner and has an easier time
+with (). The second form also is consistent with the way
+this_cpu_read() and friends are used.
+
+
+Christoph Lameter, April 3rd, 2013
diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt
new file mode 100644
index 000000000000..5b5322024067
--- /dev/null
+++ b/Documentation/timers/NO_HZ.txt
@@ -0,0 +1,273 @@
+                NO_HZ: Reducing Scheduling-Clock Ticks
+
+
+This document describes Kconfig options and boot parameters that can
+reduce the number of scheduling-clock interrupts, thereby improving energy
+efficiency and reducing OS jitter.  Reducing OS jitter is important for
+some types of computationally intensive high-performance computing (HPC)
+applications and for real-time applications.
+
+There are two main contexts in which the number of scheduling-clock
+interrupts can be reduced compared to the old-school approach of sending
+a scheduling-clock interrupt to all CPUs every jiffy whether they need
+it or not (CONFIG_HZ_PERIODIC=y or CONFIG_NO_HZ=n for older kernels):
+
+1.      Idle CPUs (CONFIG_NO_HZ_IDLE=y or CONFIG_NO_HZ=y for older kernels).
+
+2.      CPUs having only one runnable task (CONFIG_NO_HZ_FULL=y).
+
+These two cases are described in the following two sections, followed
+by a third section on RCU-specific considerations and a fourth and final
+section listing known issues.
+
+
+IDLE CPUs
+
+If a CPU is idle, there is little point in sending it a scheduling-clock
+interrupt.  After all, the primary purpose of a scheduling-clock interrupt
+is to force a busy CPU to shift its attention among multiple duties,
+and an idle CPU has no duties to shift its attention among.
+
+The CONFIG_NO_HZ_IDLE=y Kconfig option causes the kernel to avoid sending
+scheduling-clock interrupts to idle CPUs, which is critically important
+both to battery-powered devices and to highly virtualized mainframes.
+A battery-powered device running a CONFIG_HZ_PERIODIC=y kernel would
+drain its battery very quickly, easily 2-3 times as fast as would the
+same device running a CONFIG_NO_HZ_IDLE=y kernel.  A mainframe running
+1,500 OS instances might find that half of its CPU time was consumed by
+unnecessary scheduling-clock interrupts.  In these situations, there
+is strong motivation to avoid sending scheduling-clock interrupts to
+idle CPUs.  That said, dyntick-idle mode is not free:
+
+1.      It increases the number of instructions executed on the path
+        to and from the idle loop.
+
+2.      On many architectures, dyntick-idle mode also increases the
+        number of expensive clock-reprogramming operations.
+
+Therefore, systems with aggressive real-time response constraints often
+run CONFIG_HZ_PERIODIC=y kernels (or CONFIG_NO_HZ=n for older kernels)
+in order to avoid degrading from-idle transition latencies.
+
+An idle CPU that is not receiving scheduling-clock interrupts is said to
+be "dyntick-idle", "in dyntick-idle mode", "in nohz mode", or "running
+tickless".  The remainder of this document will use "dyntick-idle mode".
+
+There is also a boot parameter "nohz=" that can be used to disable
+dyntick-idle mode in CONFIG_NO_HZ_IDLE=y kernels by specifying "nohz=off".
+By default, CONFIG_NO_HZ_IDLE=y kernels boot with "nohz=on", enabling
+dyntick-idle mode.
+
+
+CPUs WITH ONLY ONE RUNNABLE TASK
+
+If a CPU has only one runnable task, there is little point in sending it
+a scheduling-clock interrupt because there is no other task to switch to.
+
+The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid
+sending scheduling-clock interrupts to CPUs with a single runnable task,
+and such CPUs are said to be "adaptive-ticks CPUs".  This is important
+for applications with aggressive real-time response constraints because
+it allows them to improve their worst-case response times by the maximum
+duration of a scheduling-clock interrupt.  It is also important for
+computationally intensive short-iteration workloads:  If any CPU is
+delayed during a given iteration, all the other CPUs will be forced to
+wait idle while the delayed CPU finishes.  Thus, the delay is multiplied
+by one less than the number of CPUs.  In these situations, there is
+again strong motivation to avoid sending scheduling-clock interrupts.
+
+By default, no CPU will be an adaptive-ticks CPU.  The "nohz_full="
+boot parameter specifies the adaptive-ticks CPUs.  For example,
+"nohz_full=1,6-8" says that CPUs 1, 6, 7, and 8 are to be adaptive-ticks
+CPUs.  Note that you are prohibited from marking all of the CPUs as
+adaptive-tick CPUs:  At least one non-adaptive-tick CPU must remain
+online to handle timekeeping tasks in order to ensure that system calls
+like gettimeofday() returns accurate values on adaptive-tick CPUs.
+(This is not an issue for CONFIG_NO_HZ_IDLE=y because there are no
+running user processes to observe slight drifts in clock rate.)
+Therefore, the boot CPU is prohibited from entering adaptive-ticks
+mode.  Specifying a "nohz_full=" mask that includes the boot CPU will
+result in a boot-time error message, and the boot CPU will be removed
+from the mask.
+
+Alternatively, the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter specifies
+that all CPUs other than the boot CPU are adaptive-ticks CPUs.  This
+Kconfig parameter will be overridden by the "nohz_full=" boot parameter,
+so that if both the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter and
+the "nohz_full=1" boot parameter is specified, the boot parameter will
+prevail so that only CPU 1 will be an adaptive-ticks CPU.
+
+Finally, adaptive-ticks CPUs must have their RCU callbacks offloaded.
+This is covered in the "RCU IMPLICATIONS" section below.
+
+Normally, a CPU remains in adaptive-ticks mode as long as possible.
+In particular, transitioning to kernel mode does not automatically change
+the mode.  Instead, the CPU will exit adaptive-ticks mode only if needed,
+for example, if that CPU enqueues an RCU callback.
+
+Just as with dyntick-idle mode, the benefits of adaptive-tick mode do
+not come for free:
+
+1.      CONFIG_NO_HZ_FULL selects CONFIG_NO_HZ_COMMON, so you cannot run
+        adaptive ticks without also running dyntick idle.  This dependency
+        extends down into the implementation, so that all of the costs
+        of CONFIG_NO_HZ_IDLE are also incurred by CONFIG_NO_HZ_FULL.
+
+2.      The user/kernel transitions are slightly more expensive due
+        to the need to inform kernel subsystems (such as RCU) about
+        the change in mode.
+
+3.      POSIX CPU timers on adaptive-tick CPUs may miss their deadlines
+        (perhaps indefinitely) because they currently rely on
+        scheduling-tick interrupts.  This will likely be fixed in
+        one of two ways: (1) Prevent CPUs with POSIX CPU timers from
+        entering adaptive-tick mode, or (2) Use hrtimers or other
+        adaptive-ticks-immune mechanism to cause the POSIX CPU timer to
+        fire properly.
+
+4.      If there are more perf events pending than the hardware can
+        accommodate, they are normally round-robined so as to collect
+        all of them over time.  Adaptive-tick mode may prevent this
+        round-robining from happening.  This will likely be fixed by
+        preventing CPUs with large numbers of perf events pending from
+        entering adaptive-tick mode.
+
+5.      Scheduler statistics for adaptive-tick CPUs may be computed
+        slightly differently than those for non-adaptive-tick CPUs.
+        This might in turn perturb load-balancing of real-time tasks.
+
+6.      The LB_BIAS scheduler feature is disabled by adaptive ticks.
+
+Although improvements are expected over time, adaptive ticks is quite
+useful for many types of real-time and compute-intensive applications.
+However, the drawbacks listed above mean that adaptive ticks should not
+(yet) be enabled by default.
+
+
+RCU IMPLICATIONS
+
+There are situations in which idle CPUs cannot be permitted to
+enter either dyntick-idle mode or adaptive-tick mode, the most
+common being when that CPU has RCU callbacks pending.
+
+The CONFIG_RCU_FAST_NO_HZ=y Kconfig option may be used to cause such CPUs
+to enter dyntick-idle mode or adaptive-tick mode anyway.  In this case,
+a timer will awaken these CPUs every four jiffies in order to ensure
+that the RCU callbacks are processed in a timely fashion.
+
+Another approach is to offload RCU callback processing to "rcuo" kthreads
+using the CONFIG_RCU_NOCB_CPU=y Kconfig option.  The specific CPUs to
+offload may be selected via several methods:
+
+1.      One of three mutually exclusive Kconfig options specify a
+        build-time default for the CPUs to offload:
+
+        a.      The CONFIG_RCU_NOCB_CPU_NONE=y Kconfig option results in
+                no CPUs being offloaded.
+
+        b.      The CONFIG_RCU_NOCB_CPU_ZERO=y Kconfig option causes
+                CPU 0 to be offloaded.
+
+        c.      The CONFIG_RCU_NOCB_CPU_ALL=y Kconfig option causes all
+                CPUs to be offloaded.  Note that the callbacks will be
+                offloaded to "rcuo" kthreads, and that those kthreads
+                will in fact run on some CPU.  However, this approach
+                gives fine-grained control on exactly which CPUs the
+                callbacks run on, along with their scheduling priority
+                (including the default of SCHED_OTHER), and it further
+                allows this control to be varied dynamically at runtime.
+
+2.      The "rcu_nocbs=" kernel boot parameter, which takes a comma-separated
+        list of CPUs and CPU ranges, for example, "1,3-5" selects CPUs 1,
+        3, 4, and 5.  The specified CPUs will be offloaded in addition to
+        any CPUs specified as offloaded by CONFIG_RCU_NOCB_CPU_ZERO=y or
+        CONFIG_RCU_NOCB_CPU_ALL=y.  This means that the "rcu_nocbs=" boot
+        parameter has no effect for kernels built with RCU_NOCB_CPU_ALL=y.
+
+The offloaded CPUs will never queue RCU callbacks, and therefore RCU
+never prevents offloaded CPUs from entering either dyntick-idle mode
+or adaptive-tick mode.  That said, note that it is up to userspace to
+pin the "rcuo" kthreads to specific CPUs if desired.  Otherwise, the
+scheduler will decide where to run them, which might or might not be
+where you want them to run.
+
+
+KNOWN ISSUES
+
+o       Dyntick-idle slows transitions to and from idle slightly.
+        In practice, this has not been a problem except for the most
+        aggressive real-time workloads, which have the option of disabling
+        dyntick-idle mode, an option that most of them take.  However,
+        some workloads will no doubt want to use adaptive ticks to
+        eliminate scheduling-clock interrupt latencies.  Here are some
+        options for these workloads:
+
+        a.      Use PMQOS from userspace to inform the kernel of your
+                latency requirements (preferred).
+
+        b.      On x86 systems, use the "idle=mwait" boot parameter.
+
+        c.      On x86 systems, use the "intel_idle.max_cstate=" to limit
+        `       the maximum C-state depth.
+
+        d.      On x86 systems, use the "idle=poll" boot parameter.
+                However, please note that use of this parameter can cause
+                your CPU to overheat, which may cause thermal throttling
+                to degrade your latencies -- and that this degradation can
+                be even worse than that of dyntick-idle.  Furthermore,
+                this parameter effectively disables Turbo Mode on Intel
+                CPUs, which can significantly reduce maximum performance.
+
+o       Adaptive-ticks slows user/kernel transitions slightly.
+        This is not expected to be a problem for computationally intensive
+        workloads, which have few such transitions.  Careful benchmarking
+        will be required to determine whether or not other workloads
+        are significantly affected by this effect.
+
+o       Adaptive-ticks does not do anything unless there is only one
+        runnable task for a given CPU, even though there are a number
+        of other situations where the scheduling-clock tick is not
+        needed.  To give but one example, consider a CPU that has one
+        runnable high-priority SCHED_FIFO task and an arbitrary number
+        of low-priority SCHED_OTHER tasks.  In this case, the CPU is
+        required to run the SCHED_FIFO task until it either blocks or
+        some other higher-priority task awakens on (or is assigned to)
+        this CPU, so there is no point in sending a scheduling-clock
+        interrupt to this CPU.  However, the current implementation
+        nevertheless sends scheduling-clock interrupts to CPUs having a
+        single runnable SCHED_FIFO task and multiple runnable SCHED_OTHER
+        tasks, even though these interrupts are unnecessary.
+
+        Better handling of these sorts of situations is future work.
+
+o       A reboot is required to reconfigure both adaptive idle and RCU
+        callback offloading.  Runtime reconfiguration could be provided
+        if needed, however, due to the complexity of reconfiguring RCU at
+        runtime, there would need to be an earthshakingly good reason.
+        Especially given that you have the straightforward option of
+        simply offloading RCU callbacks from all CPUs and pinning them
+        where you want them whenever you want them pinned.
+
+o       Additional configuration is required to deal with other sources
+        of OS jitter, including interrupts and system-utility tasks
+        and processes.  This configuration normally involves binding
+        interrupts and tasks to particular CPUs.
+
+o       Some sources of OS jitter can currently be eliminated only by
+        constraining the workload.  For example, the only way to eliminate
+        OS jitter due to global TLB shootdowns is to avoid the unmapping
+        operations (such as kernel module unload operations) that
+        result in these shootdowns.  For another example, page faults
+        and TLB misses can be reduced (and in some cases eliminated) by
+        using huge pages and by constraining the amount of memory used
+        by the application.  Pre-faulting the working set can also be
+        helpful, especially when combined with the mlock() and mlockall()
+        system calls.
+
+o       Unless all CPUs are idle, at least one CPU must keep the
+        scheduling-clock interrupt going in order to support accurate
+        timekeeping.
+
+o       If there are adaptive-ticks CPUs, there will be at least one
+        CPU keeping the scheduling-clock interrupt going, even if all
+        CPUs are otherwise idle.
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index 53d6a3c51d87..bfe8c29b1f1d 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -8,6 +8,7 @@ Copyright 2008 Red Hat Inc.
 Reviewers:   Elias Oltmanns, Randy Dunlap, Andrew Morton,
              John Kacur, and David Teigland.
 Written for: 2.6.28-rc2
+Updated for: 3.10
 
 Introduction
 ------------
@@ -17,13 +18,16 @@ designers of systems to find what is going on inside the kernel.
 It can be used for debugging or analyzing latencies and
 performance issues that take place outside of user-space.
 
-Although ftrace is the function tracer, it also includes an
-infrastructure that allows for other types of tracing. Some of
-the tracers that are currently in ftrace include a tracer to
-trace context switches, the time it takes for a high priority
-task to run after it was woken up, the time interrupts are
-disabled, and more (ftrace allows for tracer plugins, which
-means that the list of tracers can always grow).
+Although ftrace is typically considered the function tracer, it
+is really a frame work of several assorted tracing utilities.
+There's latency tracing to examine what occurs between interrupts
+disabled and enabled, as well as for preemption and from a time
+a task is woken to the task is actually scheduled in.
+
+One of the most common uses of ftrace is the event tracing.
+Through out the kernel is hundreds of static event points that
+can be enabled via the debugfs file system to see what is
+going on in certain parts of the kernel.
 
 
 Implementation Details
@@ -61,7 +65,7 @@ the extended "/sys/kernel/debug/tracing" path name.
 
 That's it! (assuming that you have ftrace configured into your kernel)
 
-After mounting the debugfs, you can see a directory called
+After mounting debugfs, you can see a directory called
 "tracing".  This directory contains the control and output files
 of ftrace. Here is a list of some of the key files:
 
@@ -84,7 +88,9 @@ of ftrace. Here is a list of some of the key files:
 
         This sets or displays whether writing to the trace
         ring buffer is enabled. Echo 0 into this file to disable
-        the tracer or 1 to enable it.
+        the tracer or 1 to enable it. Note, this only disables
+        writing to the ring buffer, the tracing overhead may
+        still be occurring.
 
   trace:
 
@@ -109,7 +115,15 @@ of ftrace. Here is a list of some of the key files:
 
         This file lets the user control the amount of data
         that is displayed in one of the above output
-        files.
+        files. Options also exist to modify how a tracer
+        or events work (stack traces, timestamps, etc).
+
+  options:
+
+        This is a directory that has a file for every available
+        trace option (also in trace_options). Options may also be set
+        or cleared by writing a "1" or "0" respectively into the
+        corresponding file with the option name.
 
   tracing_max_latency:
 
@@ -121,10 +135,17 @@ of ftrace. Here is a list of some of the key files:
         latency is greater than the value in this
         file. (in microseconds)
 
+  tracing_thresh:
+
+        Some latency tracers will record a trace whenever the
+        latency is greater than the number in this file.
+        Only active when the file contains a number greater than 0.
+        (in microseconds)
+
   buffer_size_kb:
 
         This sets or displays the number of kilobytes each CPU
-        buffer can hold. The tracer buffers are the same size
+        buffer holds. By default, the trace buffers are the same size
         for each CPU. The displayed number is the size of the
         CPU buffer and not total size of all buffers. The
         trace buffers are allocated in pages (blocks of memory
@@ -133,16 +154,30 @@ of ftrace. Here is a list of some of the key files:
         than requested, the rest of the page will be used,
         making the actual allocation bigger than requested.
         ( Note, the size may not be a multiple of the page size
-          due to buffer management overhead. )
+          due to buffer management meta-data. )
 
-        This can only be updated when the current_tracer
-        is set to "nop".
+  buffer_total_size_kb:
+
+        This displays the total combined size of all the trace buffers.
+
+  free_buffer:
+
+        If a process is performing the tracing, and the ring buffer
+        should be shrunk "freed" when the process is finished, even
+        if it were to be killed by a signal, this file can be used
+        for that purpose. On close of this file, the ring buffer will
+        be resized to its minimum size. Having a process that is tracing
+        also open this file, when the process exits its file descriptor
+        for this file will be closed, and in doing so, the ring buffer
+        will be "freed".
+
+        It may also stop tracing if disable_on_free option is set.
 
   tracing_cpumask:
 
         This is a mask that lets the user only trace
-        on specified CPUS. The format is a hex string
-        representing the CPUS.
+        on specified CPUs. The format is a hex string
+        representing the CPUs.
 
   set_ftrace_filter:
 
@@ -183,6 +218,261 @@ of ftrace. Here is a list of some of the key files:
         "set_ftrace_notrace". (See the section "dynamic ftrace"
         below for more details.)
 
+  enabled_functions:
+
+        This file is more for debugging ftrace, but can also be useful
+        in seeing if any function has a callback attached to it.
+        Not only does the trace infrastructure use ftrace function
+        trace utility, but other subsystems might too. This file
+        displays all functions that have a callback attached to them
+        as well as the number of callbacks that have been attached.
+        Note, a callback may also call multiple functions which will
+        not be listed in this count.
+
+        If the callback registered to be traced by a function with
+        the "save regs" attribute (thus even more overhead), a 'R'
+        will be displayed on the same line as the function that
+        is returning registers.
+
+  function_profile_enabled:
+
+        When set it will enable all functions with either the function
+        tracer, or if enabled, the function graph tracer. It will
+        keep a histogram of the number of functions that were called
+        and if run with the function graph tracer, it will also keep
+        track of the time spent in those functions. The histogram
+        content can be displayed in the files:
+
+        trace_stats/function<cpu> ( function0, function1, etc).
+
+  trace_stats:
+
+        A directory that holds different tracing stats.
+
+  kprobe_events:
+ 
+        Enable dynamic trace points. See kprobetrace.txt.
+
+  kprobe_profile:
+
+        Dynamic trace points stats. See kprobetrace.txt.
+
+  max_graph_depth:
+
+        Used with the function graph tracer. This is the max depth
+        it will trace into a function. Setting this to a value of
+        one will show only the first kernel function that is called
+        from user space.
+
+  printk_formats:
+
+        This is for tools that read the raw format files. If an event in
+        the ring buffer references a string (currently only trace_printk()
+        does this), only a pointer to the string is recorded into the buffer
+        and not the string itself. This prevents tools from knowing what
+        that string was. This file displays the string and address for
+        the string allowing tools to map the pointers to what the
+        strings were.
+
+  saved_cmdlines:
+
+        Only the pid of the task is recorded in a trace event unless
+        the event specifically saves the task comm as well. Ftrace
+        makes a cache of pid mappings to comms to try to display
+        comms for events. If a pid for a comm is not listed, then
+        "<...>" is displayed in the output.
+
+  snapshot:
+
+        This displays the "snapshot" buffer and also lets the user
+        take a snapshot of the current running trace.
+        See the "Snapshot" section below for more details.
+
+  stack_max_size:
+
+        When the stack tracer is activated, this will display the
+        maximum stack size it has encountered.
+        See the "Stack Trace" section below.
+
+  stack_trace:
+
+        This displays the stack back trace of the largest stack
+        that was encountered when the stack tracer is activated.
+        See the "Stack Trace" section below.
+
+  stack_trace_filter:
+
+        This is similar to "set_ftrace_filter" but it limits what
+        functions the stack tracer will check.
+
+  trace_clock:
+
+        Whenever an event is recorded into the ring buffer, a
+        "timestamp" is added. This stamp comes from a specified
+        clock. By default, ftrace uses the "local" clock. This
+        clock is very fast and strictly per cpu, but on some
+        systems it may not be monotonic with respect to other
+        CPUs. In other words, the local clocks may not be in sync
+        with local clocks on other CPUs.
+
+        Usual clocks for tracing:
+
+          # cat trace_clock
+          [local] global counter x86-tsc
+
+          local: Default clock, but may not be in sync across CPUs
+
+          global: This clock is in sync with all CPUs but may
+                  be a bit slower than the local clock.
+
+          counter: This is not a clock at all, but literally an atomic
+                   counter. It counts up one by one, but is in sync
+                   with all CPUs. This is useful when you need to
+                   know exactly the order events occurred with respect to
+                   each other on different CPUs.
+
+          uptime: This uses the jiffies counter and the time stamp
+                  is relative to the time since boot up.
+
+          perf: This makes ftrace use the same clock that perf uses.
+                Eventually perf will be able to read ftrace buffers
+                and this will help out in interleaving the data.
+
+          x86-tsc: Architectures may define their own clocks. For
+                   example, x86 uses its own TSC cycle clock here.
+
+        To set a clock, simply echo the clock name into this file.
+
+          echo global > trace_clock
+
+  trace_marker:
+
+        This is a very useful file for synchronizing user space
+        with events happening in the kernel. Writing strings into
+        this file will be written into the ftrace buffer.
+
+        It is useful in applications to open this file at the start
+        of the application and just reference the file descriptor
+        for the file.
+
+        void trace_write(const char *fmt, ...)
+        {
+                va_list ap;
+                char buf[256];
+                int n;
+
+                if (trace_fd < 0)
+                        return;
+
+                va_start(ap, fmt);
+                n = vsnprintf(buf, 256, fmt, ap);
+                va_end(ap);
+
+                write(trace_fd, buf, n);
+        }
+
+        start:
+
+                trace_fd = open("trace_marker", WR_ONLY);
+
+  uprobe_events:
+ 
+        Add dynamic tracepoints in programs.
+        See uprobetracer.txt
+
+  uprobe_profile:
+
+        Uprobe statistics. See uprobetrace.txt
+
+  instances:
+
+        This is a way to make multiple trace buffers where different
+        events can be recorded in different buffers.
+        See "Instances" section below.
+
+  events:
+
+        This is the trace event directory. It holds event tracepoints
+        (also known as static tracepoints) that have been compiled
+        into the kernel. It shows what event tracepoints exist
+        and how they are grouped by system. There are "enable"
+        files at various levels that can enable the tracepoints
+        when a "1" is written to them.
+
+        See events.txt for more information.
+
+  per_cpu:
+
+        This is a directory that contains the trace per_cpu information.
+
+  per_cpu/cpu0/buffer_size_kb:
+
+        The ftrace buffer is defined per_cpu. That is, there's a separate
+        buffer for each CPU to allow writes to be done atomically,
+        and free from cache bouncing. These buffers may have different
+        size buffers. This file is similar to the buffer_size_kb
+        file, but it only displays or sets the buffer size for the
+        specific CPU. (here cpu0).
+
+  per_cpu/cpu0/trace:
+
+        This is similar to the "trace" file, but it will only display
+        the data specific for the CPU. If written to, it only clears
+        the specific CPU buffer.
+
+  per_cpu/cpu0/trace_pipe
+
+        This is similar to the "trace_pipe" file, and is a consuming
+        read, but it will only display (and consume) the data specific
+        for the CPU.
+
+  per_cpu/cpu0/trace_pipe_raw
+
+        For tools that can parse the ftrace ring buffer binary format,
+        the trace_pipe_raw file can be used to extract the data
+        from the ring buffer directly. With the use of the splice()
+        system call, the buffer data can be quickly transferred to
+        a file or to the network where a server is collecting the
+        data.
+
+        Like trace_pipe, this is a consuming reader, where multiple
+        reads will always produce different data.
+
+  per_cpu/cpu0/snapshot:
+
+        This is similar to the main "snapshot" file, but will only
+        snapshot the current CPU (if supported). It only displays
+        the content of the snapshot for a given CPU, and if
+        written to, only clears this CPU buffer.
+
+  per_cpu/cpu0/snapshot_raw:
+
+        Similar to the trace_pipe_raw, but will read the binary format
+        from the snapshot buffer for the given CPU.
+
+  per_cpu/cpu0/stats:
+
+        This displays certain stats about the ring buffer:
+
+         entries: The number of events that are still in the buffer.
+
+         overrun: The number of lost events due to overwriting when
+                  the buffer was full.
+
+         commit overrun: Should always be zero.
+                This gets set if so many events happened within a nested
+                event (ring buffer is re-entrant), that it fills the
+                buffer and starts dropping events.
+
+         bytes: Bytes actually read (not overwritten).
+
+         oldest event ts: The oldest timestamp in the buffer
+
+         now ts: The current timestamp
+
+         dropped events: Events lost due to overwrite option being off.
+
+         read events: The number of events read.
 
 The Tracers
 -----------
@@ -234,11 +524,6 @@ Here is the list of current tracers that may be configured.
         RT tasks (as the current "wakeup" does). This is useful
         for those interested in wake up timings of RT tasks.
 
-  "hw-branch-tracer"
-
-        Uses the BTS CPU feature on x86 CPUs to traces all
-        branches executed.
-
   "nop"
 
         This is the "trace nothing" tracer. To remove all
@@ -261,70 +546,100 @@ Here is an example of the output format of the file "trace"
                              --------
 # tracer: function
 #
-#           TASK-PID   CPU#    TIMESTAMP  FUNCTION
-#              | |      |          |         |
-            bash-4251  [01] 10152.583854: path_put <-path_walk
-            bash-4251  [01] 10152.583855: dput <-path_put
-            bash-4251  [01] 10152.583855: _atomic_dec_and_lock <-dput
+# entries-in-buffer/entries-written: 140080/250280   #P:4
+#
+#                              _-----=> irqs-off
+#                             / _----=> need-resched
+#                            | / _---=> hardirq/softirq
+#                            || / _--=> preempt-depth
+#                            ||| /     delay
+#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+#              | |       |   ||||       |         |
+            bash-1977  [000] .... 17284.993652: sys_close <-system_call_fastpath
+            bash-1977  [000] .... 17284.993653: __close_fd <-sys_close
+            bash-1977  [000] .... 17284.993653: _raw_spin_lock <-__close_fd
+            sshd-1974  [003] .... 17284.993653: __srcu_read_unlock <-fsnotify
+            bash-1977  [000] .... 17284.993654: add_preempt_count <-_raw_spin_lock
+            bash-1977  [000] ...1 17284.993655: _raw_spin_unlock <-__close_fd
+            bash-1977  [000] ...1 17284.993656: sub_preempt_count <-_raw_spin_unlock
+            bash-1977  [000] .... 17284.993657: filp_close <-__close_fd
+            bash-1977  [000] .... 17284.993657: dnotify_flush <-filp_close
+            sshd-1974  [003] .... 17284.993658: sys_select <-system_call_fastpath
                              --------
 
 A header is printed with the tracer name that is represented by
-the trace. In this case the tracer is "function". Then a header
-showing the format. Task name "bash", the task PID "4251", the
-CPU that it was running on "01", the timestamp in <secs>.<usecs>
-format, the function name that was traced "path_put" and the
-parent function that called this function "path_walk". The
-timestamp is the time at which the function was entered.
+the trace. In this case the tracer is "function". Then it shows the
+number of events in the buffer as well as the total number of entries
+that were written. The difference is the number of entries that were
+lost due to the buffer filling up (250280 - 140080 = 110200 events
+lost).
+
+The header explains the content of the events. Task name "bash", the task
+PID "1977", the CPU that it was running on "000", the latency format
+(explained below), the timestamp in <secs>.<usecs> format, the
+function name that was traced "sys_close" and the parent function that
+called this function "system_call_fastpath". The timestamp is the time
+at which the function was entered.
 
 Latency trace format
 --------------------
 
-When the latency-format option is enabled, the trace file gives
-somewhat more information to see why a latency happened.
-Here is a typical trace.
+When the latency-format option is enabled or when one of the latency
+tracers is set, the trace file gives somewhat more information to see
+why a latency happened. Here is a typical trace.
 
 # tracer: irqsoff
 #
-irqsoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 97 us, #3/3, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
-    -----------------
-    | task: swapper-0 (uid:0 nice:0 policy:0 rt_prio:0)
-    -----------------
- => started at: apic_timer_interrupt
- => ended at:   do_softirq
-
-#                _------=> CPU#
-#               / _-----=> irqs-off
-#              | / _----=> need-resched
-#              || / _---=> hardirq/softirq
-#              ||| / _--=> preempt-depth
-#              |||| /
-#              |||||     delay
-#  cmd     pid ||||| time  |   caller
-#     \   /    |||||   \   |   /
-  <idle>-0     0d..1    0us+: trace_hardirqs_off_thunk (apic_timer_interrupt)
-  <idle>-0     0d.s.   97us : __do_softirq (do_softirq)
-  <idle>-0     0d.s1   98us : trace_hardirqs_on (do_softirq)
+# irqsoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 259 us, #4/4, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: ps-6143 (uid:0 nice:0 policy:0 rt_prio:0)
+#    -----------------
+#  => started at: __lock_task_sighand
+#  => ended at:   _raw_spin_unlock_irqrestore
+#
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+      ps-6143    2d...    0us!: trace_hardirqs_off <-__lock_task_sighand
+      ps-6143    2d..1  259us+: trace_hardirqs_on <-_raw_spin_unlock_irqrestore
+      ps-6143    2d..1  263us+: time_hardirqs_on <-_raw_spin_unlock_irqrestore
+      ps-6143    2d..1  306us : <stack trace>
+ => trace_hardirqs_on_caller
+ => trace_hardirqs_on
+ => _raw_spin_unlock_irqrestore
+ => do_task_stat
+ => proc_tgid_stat
+ => proc_single_show
+ => seq_read
+ => vfs_read
+ => sys_read
+ => system_call_fastpath
 
 
 This shows that the current tracer is "irqsoff" tracing the time
-for which interrupts were disabled. It gives the trace version
-and the version of the kernel upon which this was executed on
-(2.6.26-rc8). Then it displays the max latency in microsecs (97
-us). The number of trace entries displayed and the total number
-recorded (both are three: #3/3). The type of preemption that was
-used (PREEMPT). VP, KP, SP, and HP are always zero and are
-reserved for later use. #P is the number of online CPUS (#P:2).
+for which interrupts were disabled. It gives the trace version (which
+never changes) and the version of the kernel upon which this was executed on
+(3.10). Then it displays the max latency in microseconds (259 us). The number
+of trace entries displayed and the total number (both are four: #4/4).
+VP, KP, SP, and HP are always zero and are reserved for later use.
+#P is the number of online CPUs (#P:4).
 
 The task is the process that was running when the latency
-occurred. (swapper pid: 0).
+occurred. (ps pid: 6143).
 
 The start and stop (the functions in which the interrupts were
 disabled and enabled respectively) that caused the latencies:
 
-  apic_timer_interrupt is where the interrupts were disabled.
-  do_softirq is where they were enabled again.
+ __lock_task_sighand is where the interrupts were disabled.
+ _raw_spin_unlock_irqrestore is where they were enabled again.
 
 The next lines after the header are the trace itself. The header
 explains which is which.
@@ -367,16 +682,43 @@ The above is mostly meaningful for kernel developers.
 
   The rest is the same as the 'trace' file.
 
+  Note, the latency tracers will usually end with a back trace
+  to easily find where the latency occurred.
 
 trace_options
 -------------
 
-The trace_options file is used to control what gets printed in
-the trace output. To see what is available, simply cat the file:
+The trace_options file (or the options directory) is used to control
+what gets printed in the trace output, or manipulate the tracers.
+To see what is available, simply cat the file:
 
   cat trace_options
-  print-parent nosym-offset nosym-addr noverbose noraw nohex nobin \
-  noblock nostacktrace nosched-tree nouserstacktrace nosym-userobj
+print-parent
+nosym-offset
+nosym-addr
+noverbose
+noraw
+nohex
+nobin
+noblock
+nostacktrace
+trace_printk
+noftrace_preempt
+nobranch
+annotate
+nouserstacktrace
+nosym-userobj
+noprintk-msg-only
+context-info
+latency-format
+sleep-time
+graph-time
+record-cmd
+overwrite
+nodisable_on_free
+irq-info
+markers
+function-trace
 
 To disable one of the options, echo in the option prepended with
 "no".
@@ -428,13 +770,34 @@ Here are the available options:
 
   bin - This will print out the formats in raw binary.
 
-  block - TBD (needs update)
+  block - When set, reading trace_pipe will not block when polled.
 
   stacktrace - This is one of the options that changes the trace
                itself. When a trace is recorded, so is the stack
                of functions. This allows for back traces of
                trace sites.
 
+  trace_printk - Can disable trace_printk() from writing into the buffer.
+
+  branch - Enable branch tracing with the tracer.
+
+  annotate - It is sometimes confusing when the CPU buffers are full
+             and one CPU buffer had a lot of events recently, thus
+             a shorter time frame, were another CPU may have only had
+             a few events, which lets it have older events. When
+             the trace is reported, it shows the oldest events first,
+             and it may look like only one CPU ran (the one with the
+             oldest events). When the annotate option is set, it will
+             display when a new CPU buffer started:
+
+          <idle>-0     [001] dNs4 21169.031481: wake_up_idle_cpu <-add_timer_on
+          <idle>-0     [001] dNs4 21169.031482: _raw_spin_unlock_irqrestore <-add_timer_on
+          <idle>-0     [001] .Ns4 21169.031484: sub_preempt_count <-_raw_spin_unlock_irqrestore
+##### CPU 2 buffer started ####
+          <idle>-0     [002] .N.1 21169.031484: rcu_idle_exit <-cpu_idle
+          <idle>-0     [001] .Ns3 21169.031484: _raw_spin_unlock <-clocksource_watchdog
+          <idle>-0     [001] .Ns3 21169.031485: sub_preempt_count <-_raw_spin_unlock
+
   userstacktrace - This option changes the trace. It records a
                    stacktrace of the current userspace thread.
 
@@ -451,9 +814,13 @@ Here are the available options:
                 a.out-1623  [000] 40874.465068: /root/a.out[+0x480] <-/root/a.out[+0
 x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6]
 
-  sched-tree - trace all tasks that are on the runqueue, at
-               every scheduling event. Will add overhead if
-               there's a lot of tasks running at once.
+
+  printk-msg-only - When set, trace_printk()s will only show the format
+                    and not their parameters (if trace_bprintk() or
+                    trace_bputs() was used to save the trace_printk()).
+
+  context-info - Show only the event data. Hides the comm, PID,
+                 timestamp, CPU, and other useful data.
 
   latency-format - This option changes the trace. When
                    it is enabled, the trace displays
@@ -461,31 +828,61 @@ x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6]
                    latencies, as described in "Latency
                    trace format".
 
+  sleep-time - When running function graph tracer, to include
+               the time a task schedules out in its function.
+               When enabled, it will account time the task has been
+               scheduled out as part of the function call.
+
+  graph-time - When running function graph tracer, to include the
+               time to call nested functions. When this is not set,
+               the time reported for the function will only include
+               the time the function itself executed for, not the time
+               for functions that it called.
+
+  record-cmd - When any event or tracer is enabled, a hook is enabled
+               in the sched_switch trace point to fill comm cache
+               with mapped pids and comms. But this may cause some
+               overhead, and if you only care about pids, and not the
+               name of the task, disabling this option can lower the
+               impact of tracing.
+
   overwrite - This controls what happens when the trace buffer is
               full. If "1" (default), the oldest events are
               discarded and overwritten. If "0", then the newest
               events are discarded.
+                (see per_cpu/cpu0/stats for overrun and dropped)
 
-ftrace_enabled
---------------
+  disable_on_free - When the free_buffer is closed, tracing will
+                    stop (tracing_on set to 0).
 
-The following tracers (listed below) give different output
-depending on whether or not the sysctl ftrace_enabled is set. To
-set ftrace_enabled, one can either use the sysctl function or
-set it via the proc file system interface.
+  irq-info - Shows the interrupt, preempt count, need resched data.
+             When disabled, the trace looks like:
 
-  sysctl kernel.ftrace_enabled=1
+# tracer: function
+#
+# entries-in-buffer/entries-written: 144405/9452052   #P:4
+#
+#           TASK-PID   CPU#      TIMESTAMP  FUNCTION
+#              | |       |          |         |
+          <idle>-0     [002]  23636.756054: ttwu_do_activate.constprop.89 <-try_to_wake_up
+          <idle>-0     [002]  23636.756054: activate_task <-ttwu_do_activate.constprop.89
+          <idle>-0     [002]  23636.756055: enqueue_task <-activate_task
 
- or
 
-  echo 1 > /proc/sys/kernel/ftrace_enabled
+  markers - When set, the trace_marker is writable (only by root).
+            When disabled, the trace_marker will error with EINVAL
+            on write.
+
+
+  function-trace - The latency tracers will enable function tracing
+            if this option is enabled (default it is). When
+            it is disabled, the latency tracers do not trace
+            functions. This keeps the overhead of the tracer down
+            when performing latency tests.
 
-To disable ftrace_enabled simply replace the '1' with '0' in the
-above commands.
+ Note: Some tracers have their own options. They only appear
+       when the tracer is active.
 
-When ftrace_enabled is set the tracers will also record the
-functions that are within the trace. The descriptions of the
-tracers will also show an example with ftrace enabled.
 
 
 irqsoff
@@ -506,95 +903,133 @@ new trace is saved.
 To reset the maximum, echo 0 into tracing_max_latency. Here is
 an example:
 
+ # echo 0 > options/function-trace
  # echo irqsoff > current_tracer
- # echo latency-format > trace_options
- # echo 0 > tracing_max_latency
  # echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
  # ls -ltr
  [...]
  # echo 0 > tracing_on
  # cat trace
 # tracer: irqsoff
 #
-irqsoff latency trace v1.1.5 on 2.6.26
---------------------------------------------------------------------
- latency: 12 us, #3/3, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
-    -----------------
-    | task: bash-3730 (uid:0 nice:0 policy:0 rt_prio:0)
-    -----------------
- => started at: sys_setpgid
- => ended at:   sys_setpgid
-
-#                _------=> CPU#
-#               / _-----=> irqs-off
-#              | / _----=> need-resched
-#              || / _---=> hardirq/softirq
-#              ||| / _--=> preempt-depth
-#              |||| /
-#              |||||     delay
-#  cmd     pid ||||| time  |   caller
-#     \   /    |||||   \   |   /
-    bash-3730  1d...    0us : _write_lock_irq (sys_setpgid)
-    bash-3730  1d..1    1us+: _write_unlock_irq (sys_setpgid)
-    bash-3730  1d..2   14us : trace_hardirqs_on (sys_setpgid)
-
-
-Here we see that that we had a latency of 12 microsecs (which is
-very good). The _write_lock_irq in sys_setpgid disabled
-interrupts. The difference between the 12 and the displayed
-timestamp 14us occurred because the clock was incremented
+# irqsoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 16 us, #4/4, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: swapper/0-0 (uid:0 nice:0 policy:0 rt_prio:0)
+#    -----------------
+#  => started at: run_timer_softirq
+#  => ended at:   run_timer_softirq
+#
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+  <idle>-0       0d.s2    0us+: _raw_spin_lock_irq <-run_timer_softirq
+  <idle>-0       0dNs3   17us : _raw_spin_unlock_irq <-run_timer_softirq
+  <idle>-0       0dNs3   17us+: trace_hardirqs_on <-run_timer_softirq
+  <idle>-0       0dNs3   25us : <stack trace>
+ => _raw_spin_unlock_irq
+ => run_timer_softirq
+ => __do_softirq
+ => call_softirq
+ => do_softirq
+ => irq_exit
+ => smp_apic_timer_interrupt
+ => apic_timer_interrupt
+ => rcu_idle_exit
+ => cpu_idle
+ => rest_init
+ => start_kernel
+ => x86_64_start_reservations
+ => x86_64_start_kernel
+
+Here we see that that we had a latency of 16 microseconds (which is
+very good). The _raw_spin_lock_irq in run_timer_softirq disabled
+interrupts. The difference between the 16 and the displayed
+timestamp 25us occurred because the clock was incremented
 between the time of recording the max latency and the time of
 recording the function that had that latency.
 
-Note the above example had ftrace_enabled not set. If we set the
-ftrace_enabled, we get a much larger output:
+Note the above example had function-trace not set. If we set
+function-trace, we get a much larger output:
+
+ with echo 1 > options/function-trace
 
 # tracer: irqsoff
 #
-irqsoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 50 us, #101/101, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
-    -----------------
-    | task: ls-4339 (uid:0 nice:0 policy:0 rt_prio:0)
-    -----------------
- => started at: __alloc_pages_internal
- => ended at:   __alloc_pages_internal
-
-#                _------=> CPU#
-#               / _-----=> irqs-off
-#              | / _----=> need-resched
-#              || / _---=> hardirq/softirq
-#              ||| / _--=> preempt-depth
-#              |||| /
-#              |||||     delay
-#  cmd     pid ||||| time  |   caller
-#     \   /    |||||   \   |   /
-      ls-4339  0...1    0us+: get_page_from_freelist (__alloc_pages_internal)
-      ls-4339  0d..1    3us : rmqueue_bulk (get_page_from_freelist)
-      ls-4339  0d..1    3us : _spin_lock (rmqueue_bulk)
-      ls-4339  0d..1    4us : add_preempt_count (_spin_lock)
-      ls-4339  0d..2    4us : __rmqueue (rmqueue_bulk)
-      ls-4339  0d..2    5us : __rmqueue_smallest (__rmqueue)
-      ls-4339  0d..2    5us : __mod_zone_page_state (__rmqueue_smallest)
-      ls-4339  0d..2    6us : __rmqueue (rmqueue_bulk)
-      ls-4339  0d..2    6us : __rmqueue_smallest (__rmqueue)
-      ls-4339  0d..2    7us : __mod_zone_page_state (__rmqueue_smallest)
-      ls-4339  0d..2    7us : __rmqueue (rmqueue_bulk)
-      ls-4339  0d..2    8us : __rmqueue_smallest (__rmqueue)
+# irqsoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 71 us, #168/168, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: bash-2042 (uid:0 nice:0 policy:0 rt_prio:0)
+#    -----------------
+#  => started at: ata_scsi_queuecmd
+#  => ended at:   ata_scsi_queuecmd
+#
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+    bash-2042    3d...    0us : _raw_spin_lock_irqsave <-ata_scsi_queuecmd
+    bash-2042    3d...    0us : add_preempt_count <-_raw_spin_lock_irqsave
+    bash-2042    3d..1    1us : ata_scsi_find_dev <-ata_scsi_queuecmd
+    bash-2042    3d..1    1us : __ata_scsi_find_dev <-ata_scsi_find_dev
+    bash-2042    3d..1    2us : ata_find_dev.part.14 <-__ata_scsi_find_dev
+    bash-2042    3d..1    2us : ata_qc_new_init <-__ata_scsi_queuecmd
+    bash-2042    3d..1    3us : ata_sg_init <-__ata_scsi_queuecmd
+    bash-2042    3d..1    4us : ata_scsi_rw_xlat <-__ata_scsi_queuecmd
+    bash-2042    3d..1    4us : ata_build_rw_tf <-ata_scsi_rw_xlat
 [...]
-      ls-4339  0d..2   46us : __rmqueue_smallest (__rmqueue)
-      ls-4339  0d..2   47us : __mod_zone_page_state (__rmqueue_smallest)
-      ls-4339  0d..2   47us : __rmqueue (rmqueue_bulk)
-      ls-4339  0d..2   48us : __rmqueue_smallest (__rmqueue)
-      ls-4339  0d..2   48us : __mod_zone_page_state (__rmqueue_smallest)
-      ls-4339  0d..2   49us : _spin_unlock (rmqueue_bulk)
-      ls-4339  0d..2   49us : sub_preempt_count (_spin_unlock)
-      ls-4339  0d..1   50us : get_page_from_freelist (__alloc_pages_internal)
-      ls-4339  0d..2   51us : trace_hardirqs_on (__alloc_pages_internal)
-
-
-
-Here we traced a 50 microsecond latency. But we also see all the
+    bash-2042    3d..1   67us : delay_tsc <-__delay
+    bash-2042    3d..1   67us : add_preempt_count <-delay_tsc
+    bash-2042    3d..2   67us : sub_preempt_count <-delay_tsc
+    bash-2042    3d..1   67us : add_preempt_count <-delay_tsc
+    bash-2042    3d..2   68us : sub_preempt_count <-delay_tsc
+    bash-2042    3d..1   68us+: ata_bmdma_start <-ata_bmdma_qc_issue
+    bash-2042    3d..1   71us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd
+    bash-2042    3d..1   71us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd
+    bash-2042    3d..1   72us+: trace_hardirqs_on <-ata_scsi_queuecmd
+    bash-2042    3d..1  120us : <stack trace>
+ => _raw_spin_unlock_irqrestore
+ => ata_scsi_queuecmd
+ => scsi_dispatch_cmd
+ => scsi_request_fn
+ => __blk_run_queue_uncond
+ => __blk_run_queue
+ => blk_queue_bio
+ => generic_make_request
+ => submit_bio
+ => submit_bh
+ => __ext3_get_inode_loc
+ => ext3_iget
+ => ext3_lookup
+ => lookup_real
+ => __lookup_hash
+ => walk_component
+ => lookup_last
+ => path_lookupat
+ => filename_lookup
+ => user_path_at_empty
+ => user_path_at
+ => vfs_fstatat
+ => vfs_stat
+ => sys_newstat
+ => system_call_fastpath
+
+
+Here we traced a 71 microsecond latency. But we also see all the
 functions that were called during that time. Note that by
 enabling function tracing, we incur an added overhead. This
 overhead may extend the latency times. But nevertheless, this
@@ -614,120 +1049,122 @@ Like the irqsoff tracer, it records the maximum latency for
 which preemption was disabled. The control of preemptoff tracer
 is much like the irqsoff tracer.
 
+ # echo 0 > options/function-trace
  # echo preemptoff > current_tracer
- # echo latency-format > trace_options
- # echo 0 > tracing_max_latency
  # echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
  # ls -ltr
  [...]
  # echo 0 > tracing_on
  # cat trace
 # tracer: preemptoff
 #
-preemptoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 29 us, #3/3, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
-    -----------------
-    | task: sshd-4261 (uid:0 nice:0 policy:0 rt_prio:0)
-    -----------------
- => started at: do_IRQ
- => ended at:   __do_softirq
-
-#                _------=> CPU#
-#               / _-----=> irqs-off
-#              | / _----=> need-resched
-#              || / _---=> hardirq/softirq
-#              ||| / _--=> preempt-depth
-#              |||| /
-#              |||||     delay
-#  cmd     pid ||||| time  |   caller
-#     \   /    |||||   \   |   /
-    sshd-4261  0d.h.    0us+: irq_enter (do_IRQ)
-    sshd-4261  0d.s.   29us : _local_bh_enable (__do_softirq)
-    sshd-4261  0d.s1   30us : trace_preempt_on (__do_softirq)
+# preemptoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 46 us, #4/4, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: sshd-1991 (uid:0 nice:0 policy:0 rt_prio:0)
+#    -----------------
+#  => started at: do_IRQ
+#  => ended at:   do_IRQ
+#
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+    sshd-1991    1d.h.    0us+: irq_enter <-do_IRQ
+    sshd-1991    1d..1   46us : irq_exit <-do_IRQ
+    sshd-1991    1d..1   47us+: trace_preempt_on <-do_IRQ
+    sshd-1991    1d..1   52us : <stack trace>
+ => sub_preempt_count
+ => irq_exit
+ => do_IRQ
+ => ret_from_intr
 
 
 This has some more changes. Preemption was disabled when an
-interrupt came in (notice the 'h'), and was enabled while doing
-a softirq. (notice the 's'). But we also see that interrupts
-have been disabled when entering the preempt off section and
-leaving it (the 'd'). We do not know if interrupts were enabled
-in the mean time.
+interrupt came in (notice the 'h'), and was enabled on exit.
+But we also see that interrupts have been disabled when entering
+the preempt off section and leaving it (the 'd'). We do not know if
+interrupts were enabled in the mean time or shortly after this
+was over.
 
 # tracer: preemptoff
 #
-preemptoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 63 us, #87/87, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
-    -----------------
-    | task: sshd-4261 (uid:0 nice:0 policy:0 rt_prio:0)
-    -----------------
- => started at: remove_wait_queue
- => ended at:   __do_softirq
-
-#                _------=> CPU#
-#               / _-----=> irqs-off
-#              | / _----=> need-resched
-#              || / _---=> hardirq/softirq
-#              ||| / _--=> preempt-depth
-#              |||| /
-#              |||||     delay
-#  cmd     pid ||||| time  |   caller
-#     \   /    |||||   \   |   /
-    sshd-4261  0d..1    0us : _spin_lock_irqsave (remove_wait_queue)
-    sshd-4261  0d..1    1us : _spin_unlock_irqrestore (remove_wait_queue)
-    sshd-4261  0d..1    2us : do_IRQ (common_interrupt)
-    sshd-4261  0d..1    2us : irq_enter (do_IRQ)
-    sshd-4261  0d..1    2us : idle_cpu (irq_enter)
-    sshd-4261  0d..1    3us : add_preempt_count (irq_enter)
-    sshd-4261  0d.h1    3us : idle_cpu (irq_enter)
-    sshd-4261  0d.h.    4us : handle_fasteoi_irq (do_IRQ)
+# preemptoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 83 us, #241/241, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: bash-1994 (uid:0 nice:0 policy:0 rt_prio:0)
+#    -----------------
+#  => started at: wake_up_new_task
+#  => ended at:   task_rq_unlock
+#
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+    bash-1994    1d..1    0us : _raw_spin_lock_irqsave <-wake_up_new_task
+    bash-1994    1d..1    0us : select_task_rq_fair <-select_task_rq
+    bash-1994    1d..1    1us : __rcu_read_lock <-select_task_rq_fair
+    bash-1994    1d..1    1us : source_load <-select_task_rq_fair
+    bash-1994    1d..1    1us : source_load <-select_task_rq_fair
 [...]
-    sshd-4261  0d.h.   12us : add_preempt_count (_spin_lock)
-    sshd-4261  0d.h1   12us : ack_ioapic_quirk_irq (handle_fasteoi_irq)
-    sshd-4261  0d.h1   13us : move_native_irq (ack_ioapic_quirk_irq)
-    sshd-4261  0d.h1   13us : _spin_unlock (handle_fasteoi_irq)
-    sshd-4261  0d.h1   14us : sub_preempt_count (_spin_unlock)
-    sshd-4261  0d.h1   14us : irq_exit (do_IRQ)
-    sshd-4261  0d.h1   15us : sub_preempt_count (irq_exit)
-    sshd-4261  0d..2   15us : do_softirq (irq_exit)
-    sshd-4261  0d...   15us : __do_softirq (do_softirq)
-    sshd-4261  0d...   16us : __local_bh_disable (__do_softirq)
-    sshd-4261  0d...   16us+: add_preempt_count (__local_bh_disable)
-    sshd-4261  0d.s4   20us : add_preempt_count (__local_bh_disable)
-    sshd-4261  0d.s4   21us : sub_preempt_count (local_bh_enable)
-    sshd-4261  0d.s5   21us : sub_preempt_count (local_bh_enable)
+    bash-1994    1d..1   12us : irq_enter <-smp_apic_timer_interrupt
+    bash-1994    1d..1   12us : rcu_irq_enter <-irq_enter
+    bash-1994    1d..1   13us : add_preempt_count <-irq_enter
+    bash-1994    1d.h1   13us : exit_idle <-smp_apic_timer_interrupt
+    bash-1994    1d.h1   13us : hrtimer_interrupt <-smp_apic_timer_interrupt
+    bash-1994    1d.h1   13us : _raw_spin_lock <-hrtimer_interrupt
+    bash-1994    1d.h1   14us : add_preempt_count <-_raw_spin_lock
+    bash-1994    1d.h2   14us : ktime_get_update_offsets <-hrtimer_interrupt
 [...]
-    sshd-4261  0d.s6   41us : add_preempt_count (__local_bh_disable)
-    sshd-4261  0d.s6   42us : sub_preempt_count (local_bh_enable)
-    sshd-4261  0d.s7   42us : sub_preempt_count (local_bh_enable)
-    sshd-4261  0d.s5   43us : add_preempt_count (__local_bh_disable)
-    sshd-4261  0d.s5   43us : sub_preempt_count (local_bh_enable_ip)
-    sshd-4261  0d.s6   44us : sub_preempt_count (local_bh_enable_ip)
-    sshd-4261  0d.s5   44us : add_preempt_count (__local_bh_disable)
-    sshd-4261  0d.s5   45us : sub_preempt_count (local_bh_enable)
+    bash-1994    1d.h1   35us : lapic_next_event <-clockevents_program_event
+    bash-1994    1d.h1   35us : irq_exit <-smp_apic_timer_interrupt
+    bash-1994    1d.h1   36us : sub_preempt_count <-irq_exit
+    bash-1994    1d..2   36us : do_softirq <-irq_exit
+    bash-1994    1d..2   36us : __do_softirq <-call_softirq
+    bash-1994    1d..2   36us : __local_bh_disable <-__do_softirq
+    bash-1994    1d.s2   37us : add_preempt_count <-_raw_spin_lock_irq
+    bash-1994    1d.s3   38us : _raw_spin_unlock <-run_timer_softirq
+    bash-1994    1d.s3   39us : sub_preempt_count <-_raw_spin_unlock
+    bash-1994    1d.s2   39us : call_timer_fn <-run_timer_softirq
 [...]
-    sshd-4261  0d.s.   63us : _local_bh_enable (__do_softirq)
-    sshd-4261  0d.s1   64us : trace_preempt_on (__do_softirq)
+    bash-1994    1dNs2   81us : cpu_needs_another_gp <-rcu_process_callbacks
+    bash-1994    1dNs2   82us : __local_bh_enable <-__do_softirq
+    bash-1994    1dNs2   82us : sub_preempt_count <-__local_bh_enable
+    bash-1994    1dN.2   82us : idle_cpu <-irq_exit
+    bash-1994    1dN.2   83us : rcu_irq_exit <-irq_exit
+    bash-1994    1dN.2   83us : sub_preempt_count <-irq_exit
+    bash-1994    1.N.1   84us : _raw_spin_unlock_irqrestore <-task_rq_unlock
+    bash-1994    1.N.1   84us+: trace_preempt_on <-task_rq_unlock
+    bash-1994    1.N.1  104us : <stack trace>
+ => sub_preempt_count
+ => _raw_spin_unlock_irqrestore
+ => task_rq_unlock
+ => wake_up_new_task
+ => do_fork
+ => sys_clone
+ => stub_clone
 
 
 The above is an example of the preemptoff trace with
-ftrace_enabled set. Here we see that interrupts were disabled
+function-trace set. Here we see that interrupts were not disabled
 the entire time. The irq_enter code lets us know that we entered
 an interrupt 'h'. Before that, the functions being traced still
 show that it is not in an interrupt, but we can see from the
 functions themselves that this is not the case.
 
-Notice that __do_softirq when called does not have a
-preempt_count. It may seem that we missed a preempt enabling.
-What really happened is that the preempt count is held on the
-thread's stack and we switched to the softirq stack (4K stacks
-in effect). The code does not copy the preempt count, but
-because interrupts are disabled, we do not need to worry about
-it. Having a tracer like this is good for letting people know
-what really happens inside the kernel.
-
-
 preemptirqsoff
 --------------
 
@@ -762,38 +1199,57 @@ tracer.
 Again, using this trace is much like the irqsoff and preemptoff
 tracers.
 
+ # echo 0 > options/function-trace
  # echo preemptirqsoff > current_tracer
- # echo latency-format > trace_options
- # echo 0 > tracing_max_latency
  # echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
  # ls -ltr
  [...]
  # echo 0 > tracing_on
  # cat trace
 # tracer: preemptirqsoff
 #
-preemptirqsoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 293 us, #3/3, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
-    -----------------
-    | task: ls-4860 (uid:0 nice:0 policy:0 rt_prio:0)
-    -----------------
- => started at: apic_timer_interrupt
- => ended at:   __do_softirq
-
-#                _------=> CPU#
-#               / _-----=> irqs-off
-#              | / _----=> need-resched
-#              || / _---=> hardirq/softirq
-#              ||| / _--=> preempt-depth
-#              |||| /
-#              |||||     delay
-#  cmd     pid ||||| time  |   caller
-#     \   /    |||||   \   |   /
-      ls-4860  0d...    0us!: trace_hardirqs_off_thunk (apic_timer_interrupt)
-      ls-4860  0d.s.  294us : _local_bh_enable (__do_softirq)
-      ls-4860  0d.s1  294us : trace_preempt_on (__do_softirq)
-
+# preemptirqsoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 100 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: ls-2230 (uid:0 nice:0 policy:0 rt_prio:0)
+#    -----------------
+#  => started at: ata_scsi_queuecmd
+#  => ended at:   ata_scsi_queuecmd
+#
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+      ls-2230    3d...    0us+: _raw_spin_lock_irqsave <-ata_scsi_queuecmd
+      ls-2230    3...1  100us : _raw_spin_unlock_irqrestore <-ata_scsi_queuecmd
+      ls-2230    3...1  101us+: trace_preempt_on <-ata_scsi_queuecmd
+      ls-2230    3...1  111us : <stack trace>
+ => sub_preempt_count
+ => _raw_spin_unlock_irqrestore
+ => ata_scsi_queuecmd
+ => scsi_dispatch_cmd
+ => scsi_request_fn
+ => __blk_run_queue_uncond
+ => __blk_run_queue
+ => blk_queue_bio
+ => generic_make_request
+ => submit_bio
+ => submit_bh
+ => ext3_bread
+ => ext3_dir_bread
+ => htree_dirblock_to_tree
+ => ext3_htree_fill_tree
+ => ext3_readdir
+ => vfs_readdir
+ => sys_getdents
+ => system_call_fastpath
 
 
 The trace_hardirqs_off_thunk is called from assembly on x86 when
@@ -802,105 +1258,158 @@ function tracing, we do not know if interrupts were enabled
 within the preemption points. We do see that it started with
 preemption enabled.
 
-Here is a trace with ftrace_enabled set:
-
+Here is a trace with function-trace set:
 
 # tracer: preemptirqsoff
 #
-preemptirqsoff latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 105 us, #183/183, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
-    -----------------
-    | task: sshd-4261 (uid:0 nice:0 policy:0 rt_prio:0)
-    -----------------
- => started at: write_chan
- => ended at:   __do_softirq
-
-#                _------=> CPU#
-#               / _-----=> irqs-off
-#              | / _----=> need-resched
-#              || / _---=> hardirq/softirq
-#              ||| / _--=> preempt-depth
-#              |||| /
-#              |||||     delay
-#  cmd     pid ||||| time  |   caller
-#     \   /    |||||   \   |   /
-      ls-4473  0.N..    0us : preempt_schedule (write_chan)
-      ls-4473  0dN.1    1us : _spin_lock (schedule)
-      ls-4473  0dN.1    2us : add_preempt_count (_spin_lock)
-      ls-4473  0d..2    2us : put_prev_task_fair (schedule)
-[...]
-      ls-4473  0d..2   13us : set_normalized_timespec (ktime_get_ts)
-      ls-4473  0d..2   13us : __switch_to (schedule)
-    sshd-4261  0d..2   14us : finish_task_switch (schedule)
-    sshd-4261  0d..2   14us : _spin_unlock_irq (finish_task_switch)
-    sshd-4261  0d..1   15us : add_preempt_count (_spin_lock_irqsave)
-    sshd-4261  0d..2   16us : _spin_unlock_irqrestore (hrtick_set)
-    sshd-4261  0d..2   16us : do_IRQ (common_interrupt)
-    sshd-4261  0d..2   17us : irq_enter (do_IRQ)
-    sshd-4261  0d..2   17us : idle_cpu (irq_enter)
-    sshd-4261  0d..2   18us : add_preempt_count (irq_enter)
-    sshd-4261  0d.h2   18us : idle_cpu (irq_enter)
-    sshd-4261  0d.h.   18us : handle_fasteoi_irq (do_IRQ)
-    sshd-4261  0d.h.   19us : _spin_lock (handle_fasteoi_irq)
-    sshd-4261  0d.h.   19us : add_preempt_count (_spin_lock)
-    sshd-4261  0d.h1   20us : _spin_unlock (handle_fasteoi_irq)
-    sshd-4261  0d.h1   20us : sub_preempt_count (_spin_unlock)
-[...]
-    sshd-4261  0d.h1   28us : _spin_unlock (handle_fasteoi_irq)
-    sshd-4261  0d.h1   29us : sub_preempt_count (_spin_unlock)
-    sshd-4261  0d.h2   29us : irq_exit (do_IRQ)
-    sshd-4261  0d.h2   29us : sub_preempt_count (irq_exit)
-    sshd-4261  0d..3   30us : do_softirq (irq_exit)
-    sshd-4261  0d...   30us : __do_softirq (do_softirq)
-    sshd-4261  0d...   31us : __local_bh_disable (__do_softirq)
-    sshd-4261  0d...   31us+: add_preempt_count (__local_bh_disable)
-    sshd-4261  0d.s4   34us : add_preempt_count (__local_bh_disable)
+# preemptirqsoff latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 161 us, #339/339, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: ls-2269 (uid:0 nice:0 policy:0 rt_prio:0)
+#    -----------------
+#  => started at: schedule
+#  => ended at:   mutex_unlock
+#
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+kworker/-59      3...1    0us : __schedule <-schedule
+kworker/-59      3d..1    0us : rcu_preempt_qs <-rcu_note_context_switch
+kworker/-59      3d..1    1us : add_preempt_count <-_raw_spin_lock_irq
+kworker/-59      3d..2    1us : deactivate_task <-__schedule
+kworker/-59      3d..2    1us : dequeue_task <-deactivate_task
+kworker/-59      3d..2    2us : update_rq_clock <-dequeue_task
+kworker/-59      3d..2    2us : dequeue_task_fair <-dequeue_task
+kworker/-59      3d..2    2us : update_curr <-dequeue_task_fair
+kworker/-59      3d..2    2us : update_min_vruntime <-update_curr
+kworker/-59      3d..2    3us : cpuacct_charge <-update_curr
+kworker/-59      3d..2    3us : __rcu_read_lock <-cpuacct_charge
+kworker/-59      3d..2    3us : __rcu_read_unlock <-cpuacct_charge
+kworker/-59      3d..2    3us : update_cfs_rq_blocked_load <-dequeue_task_fair
+kworker/-59      3d..2    4us : clear_buddies <-dequeue_task_fair
+kworker/-59      3d..2    4us : account_entity_dequeue <-dequeue_task_fair
+kworker/-59      3d..2    4us : update_min_vruntime <-dequeue_task_fair
+kworker/-59      3d..2    4us : update_cfs_shares <-dequeue_task_fair
+kworker/-59      3d..2    5us : hrtick_update <-dequeue_task_fair
+kworker/-59      3d..2    5us : wq_worker_sleeping <-__schedule
+kworker/-59      3d..2    5us : kthread_data <-wq_worker_sleeping
+kworker/-59      3d..2    5us : put_prev_task_fair <-__schedule
+kworker/-59      3d..2    6us : pick_next_task_fair <-pick_next_task
+kworker/-59      3d..2    6us : clear_buddies <-pick_next_task_fair
+kworker/-59      3d..2    6us : set_next_entity <-pick_next_task_fair
+kworker/-59      3d..2    6us : update_stats_wait_end <-set_next_entity
+      ls-2269    3d..2    7us : finish_task_switch <-__schedule
+      ls-2269    3d..2    7us : _raw_spin_unlock_irq <-finish_task_switch
+      ls-2269    3d..2    8us : do_IRQ <-ret_from_intr
+      ls-2269    3d..2    8us : irq_enter <-do_IRQ
+      ls-2269    3d..2    8us : rcu_irq_enter <-irq_enter
+      ls-2269    3d..2    9us : add_preempt_count <-irq_enter
+      ls-2269    3d.h2    9us : exit_idle <-do_IRQ
 [...]
-    sshd-4261  0d.s3   43us : sub_preempt_count (local_bh_enable_ip)
-    sshd-4261  0d.s4   44us : sub_preempt_count (local_bh_enable_ip)
-    sshd-4261  0d.s3   44us : smp_apic_timer_interrupt (apic_timer_interrupt)
-    sshd-4261  0d.s3   45us : irq_enter (smp_apic_timer_interrupt)
-    sshd-4261  0d.s3   45us : idle_cpu (irq_enter)
-    sshd-4261  0d.s3   46us : add_preempt_count (irq_enter)
-    sshd-4261  0d.H3   46us : idle_cpu (irq_enter)
-    sshd-4261  0d.H3   47us : hrtimer_interrupt (smp_apic_timer_interrupt)
-    sshd-4261  0d.H3   47us : ktime_get (hrtimer_interrupt)
+      ls-2269    3d.h3   20us : sub_preempt_count <-_raw_spin_unlock
+      ls-2269    3d.h2   20us : irq_exit <-do_IRQ
+      ls-2269    3d.h2   21us : sub_preempt_count <-irq_exit
+      ls-2269    3d..3   21us : do_softirq <-irq_exit
+      ls-2269    3d..3   21us : __do_softirq <-call_softirq
+      ls-2269    3d..3   21us+: __local_bh_disable <-__do_softirq
+      ls-2269    3d.s4   29us : sub_preempt_count <-_local_bh_enable_ip
+      ls-2269    3d.s5   29us : sub_preempt_count <-_local_bh_enable_ip
+      ls-2269    3d.s5   31us : do_IRQ <-ret_from_intr
+      ls-2269    3d.s5   31us : irq_enter <-do_IRQ
+      ls-2269    3d.s5   31us : rcu_irq_enter <-irq_enter
 [...]
-    sshd-4261  0d.H3   81us : tick_program_event (hrtimer_interrupt)
-    sshd-4261  0d.H3   82us : ktime_get (tick_program_event)
-    sshd-4261  0d.H3   82us : ktime_get_ts (ktime_get)
-    sshd-4261  0d.H3   83us : getnstimeofday (ktime_get_ts)
-    sshd-4261  0d.H3   83us : set_normalized_timespec (ktime_get_ts)
-    sshd-4261  0d.H3   84us : clockevents_program_event (tick_program_event)
-    sshd-4261  0d.H3   84us : lapic_next_event (clockevents_program_event)
-    sshd-4261  0d.H3   85us : irq_exit (smp_apic_timer_interrupt)
-    sshd-4261  0d.H3   85us : sub_preempt_count (irq_exit)
-    sshd-4261  0d.s4   86us : sub_preempt_count (irq_exit)
-    sshd-4261  0d.s3   86us : add_preempt_count (__local_bh_disable)
+      ls-2269    3d.s5   31us : rcu_irq_enter <-irq_enter
+      ls-2269    3d.s5   32us : add_preempt_count <-irq_enter
+      ls-2269    3d.H5   32us : exit_idle <-do_IRQ
+      ls-2269    3d.H5   32us : handle_irq <-do_IRQ
+      ls-2269    3d.H5   32us : irq_to_desc <-handle_irq
+      ls-2269    3d.H5   33us : handle_fasteoi_irq <-handle_irq
 [...]
-    sshd-4261  0d.s1   98us : sub_preempt_count (net_rx_action)
-    sshd-4261  0d.s.   99us : add_preempt_count (_spin_lock_irq)
-    sshd-4261  0d.s1   99us+: _spin_unlock_irq (run_timer_softirq)
-    sshd-4261  0d.s.  104us : _local_bh_enable (__do_softirq)
-    sshd-4261  0d.s.  104us : sub_preempt_count (_local_bh_enable)
-    sshd-4261  0d.s.  105us : _local_bh_enable (__do_softirq)
-    sshd-4261  0d.s1  105us : trace_preempt_on (__do_softirq)
-
-
-This is a very interesting trace. It started with the preemption
-of the ls task. We see that the task had the "need_resched" bit
-set via the 'N' in the trace.  Interrupts were disabled before
-the spin_lock at the beginning of the trace. We see that a
-schedule took place to run sshd.  When the interrupts were
-enabled, we took an interrupt. On return from the interrupt
-handler, the softirq ran. We took another interrupt while
-running the softirq as we see from the capital 'H'.
+      ls-2269    3d.s5  158us : _raw_spin_unlock_irqrestore <-rtl8139_poll
+      ls-2269    3d.s3  158us : net_rps_action_and_irq_enable.isra.65 <-net_rx_action
+      ls-2269    3d.s3  159us : __local_bh_enable <-__do_softirq
+      ls-2269    3d.s3  159us : sub_preempt_count <-__local_bh_enable
+      ls-2269    3d..3  159us : idle_cpu <-irq_exit
+      ls-2269    3d..3  159us : rcu_irq_exit <-irq_exit
+      ls-2269    3d..3  160us : sub_preempt_count <-irq_exit
+      ls-2269    3d...  161us : __mutex_unlock_slowpath <-mutex_unlock
+      ls-2269    3d...  162us+: trace_hardirqs_on <-mutex_unlock
+      ls-2269    3d...  186us : <stack trace>
+ => __mutex_unlock_slowpath
+ => mutex_unlock
+ => process_output
+ => n_tty_write
+ => tty_write
+ => vfs_write
+ => sys_write
+ => system_call_fastpath
+
+This is an interesting trace. It started with kworker running and
+scheduling out and ls taking over. But as soon as ls released the
+rq lock and enabled interrupts (but not preemption) an interrupt
+triggered. When the interrupt finished, it started running softirqs.
+But while the softirq was running, another interrupt triggered.
+When an interrupt is running inside a softirq, the annotation is 'H'.
 
 
 wakeup
 ------
 
+One common case that people are interested in tracing is the
+time it takes for a task that is woken to actually wake up.
+Now for non Real-Time tasks, this can be arbitrary. But tracing
+it none the less can be interesting. 
+
+Without function tracing:
+
+ # echo 0 > options/function-trace
+ # echo wakeup > current_tracer
+ # echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
+ # chrt -f 5 sleep 1
+ # echo 0 > tracing_on
+ # cat trace
+# tracer: wakeup
+#
+# wakeup latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 15 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: kworker/3:1H-312 (uid:0 nice:-20 policy:0 rt_prio:0)
+#    -----------------
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+  <idle>-0       3dNs7    0us :      0:120:R   + [003]   312:100:R kworker/3:1H
+  <idle>-0       3dNs7    1us+: ttwu_do_activate.constprop.87 <-try_to_wake_up
+  <idle>-0       3d..3   15us : __schedule <-schedule
+  <idle>-0       3d..3   15us :      0:120:R ==> [003]   312:100:R kworker/3:1H
+
+The tracer only traces the highest priority task in the system
+to avoid tracing the normal circumstances. Here we see that
+the kworker with a nice priority of -20 (not very nice), took
+just 15 microseconds from the time it woke up, to the time it
+ran.
+
+Non Real-Time tasks are not that interesting. A more interesting
+trace is to concentrate only on Real-Time tasks.
+
+wakeup_rt
+---------
+
 In a Real-Time environment it is very important to know the
 wakeup time it takes for the highest priority task that is woken
 up to the time that it executes. This is also known as "schedule
@@ -914,124 +1423,229 @@ Real-Time environments are interested in the worst case latency.
 That is the longest latency it takes for something to happen,
 and not the average. We can have a very fast scheduler that may
 only have a large latency once in a while, but that would not
-work well with Real-Time tasks.  The wakeup tracer was designed
+work well with Real-Time tasks.  The wakeup_rt tracer was designed
 to record the worst case wakeups of RT tasks. Non-RT tasks are
 not recorded because the tracer only records one worst case and
 tracing non-RT tasks that are unpredictable will overwrite the
-worst case latency of RT tasks.
+worst case latency of RT tasks (just run the normal wakeup
+tracer for a while to see that effect).
 
 Since this tracer only deals with RT tasks, we will run this
 slightly differently than we did with the previous tracers.
 Instead of performing an 'ls', we will run 'sleep 1' under
 'chrt' which changes the priority of the task.
 
- # echo wakeup > current_tracer
- # echo latency-format > trace_options
- # echo 0 > tracing_max_latency
+ # echo 0 > options/function-trace
+ # echo wakeup_rt > current_tracer
  # echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
  # chrt -f 5 sleep 1
  # echo 0 > tracing_on
  # cat trace
 # tracer: wakeup
 #
-wakeup latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 4 us, #2/2, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
-    -----------------
-    | task: sleep-4901 (uid:0 nice:0 policy:1 rt_prio:5)
-    -----------------
-
-#                _------=> CPU#
-#               / _-----=> irqs-off
-#              | / _----=> need-resched
-#              || / _---=> hardirq/softirq
-#              ||| / _--=> preempt-depth
-#              |||| /
-#              |||||     delay
-#  cmd     pid ||||| time  |   caller
-#     \   /    |||||   \   |   /
-  <idle>-0     1d.h4    0us+: try_to_wake_up (wake_up_process)
-  <idle>-0     1d..4    4us : schedule (cpu_idle)
-
-
-Running this on an idle system, we see that it only took 4
-microseconds to perform the task switch.  Note, since the trace
-marker in the schedule is before the actual "switch", we stop
-the tracing when the recorded task is about to schedule in. This
-may change if we add a new marker at the end of the scheduler.
-
-Notice that the recorded task is 'sleep' with the PID of 4901
+# tracer: wakeup_rt
+#
+# wakeup_rt latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 5 us, #4/4, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: sleep-2389 (uid:0 nice:0 policy:1 rt_prio:5)
+#    -----------------
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+  <idle>-0       3d.h4    0us :      0:120:R   + [003]  2389: 94:R sleep
+  <idle>-0       3d.h4    1us+: ttwu_do_activate.constprop.87 <-try_to_wake_up
+  <idle>-0       3d..3    5us : __schedule <-schedule
+  <idle>-0       3d..3    5us :      0:120:R ==> [003]  2389: 94:R sleep
+
+
+Running this on an idle system, we see that it only took 5 microseconds
+to perform the task switch.  Note, since the trace point in the schedule
+is before the actual "switch", we stop the tracing when the recorded task
+is about to schedule in. This may change if we add a new marker at the
+end of the scheduler.
+
+Notice that the recorded task is 'sleep' with the PID of 2389
 and it has an rt_prio of 5. This priority is user-space priority
 and not the internal kernel priority. The policy is 1 for
 SCHED_FIFO and 2 for SCHED_RR.
 
-Doing the same with chrt -r 5 and ftrace_enabled set.
+Note, that the trace data shows the internal priority (99 - rtprio).
 
-# tracer: wakeup
+  <idle>-0       3d..3    5us :      0:120:R ==> [003]  2389: 94:R sleep
+
+The 0:120:R means idle was running with a nice priority of 0 (120 - 20)
+and in the running state 'R'. The sleep task was scheduled in with
+2389: 94:R. That is the priority is the kernel rtprio (99 - 5 = 94)
+and it too is in the running state.
+
+Doing the same with chrt -r 5 and function-trace set.
+
+  echo 1 > options/function-trace
+
+# tracer: wakeup_rt
 #
-wakeup latency trace v1.1.5 on 2.6.26-rc8
---------------------------------------------------------------------
- latency: 50 us, #60/60, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:2)
-    -----------------
-    | task: sleep-4068 (uid:0 nice:0 policy:2 rt_prio:5)
-    -----------------
-
-#                _------=> CPU#
-#               / _-----=> irqs-off
-#              | / _----=> need-resched
-#              || / _---=> hardirq/softirq
-#              ||| / _--=> preempt-depth
-#              |||| /
-#              |||||     delay
-#  cmd     pid ||||| time  |   caller
-#     \   /    |||||   \   |   /
-ksoftirq-7     1d.H3    0us : try_to_wake_up (wake_up_process)
-ksoftirq-7     1d.H4    1us : sub_preempt_count (marker_probe_cb)
-ksoftirq-7     1d.H3    2us : check_preempt_wakeup (try_to_wake_up)
-ksoftirq-7     1d.H3    3us : update_curr (check_preempt_wakeup)
-ksoftirq-7     1d.H3    4us : calc_delta_mine (update_curr)
-ksoftirq-7     1d.H3    5us : __resched_task (check_preempt_wakeup)
-ksoftirq-7     1d.H3    6us : task_wake_up_rt (try_to_wake_up)
-ksoftirq-7     1d.H3    7us : _spin_unlock_irqrestore (try_to_wake_up)
-[...]
-ksoftirq-7     1d.H2   17us : irq_exit (smp_apic_timer_interrupt)
-ksoftirq-7     1d.H2   18us : sub_preempt_count (irq_exit)
-ksoftirq-7     1d.s3   19us : sub_preempt_count (irq_exit)
-ksoftirq-7     1..s2   20us : rcu_process_callbacks (__do_softirq)
-[...]
-ksoftirq-7     1..s2   26us : __rcu_process_callbacks (rcu_process_callbacks)
-ksoftirq-7     1d.s2   27us : _local_bh_enable (__do_softirq)
-ksoftirq-7     1d.s2   28us : sub_preempt_count (_local_bh_enable)
-ksoftirq-7     1.N.3   29us : sub_preempt_count (ksoftirqd)
-ksoftirq-7     1.N.2   30us : _cond_resched (ksoftirqd)
-ksoftirq-7     1.N.2   31us : __cond_resched (_cond_resched)
-ksoftirq-7     1.N.2   32us : add_preempt_count (__cond_resched)
-ksoftirq-7     1.N.2   33us : schedule (__cond_resched)
-ksoftirq-7     1.N.2   33us : add_preempt_count (schedule)
-ksoftirq-7     1.N.3   34us : hrtick_clear (schedule)
-ksoftirq-7     1dN.3   35us : _spin_lock (schedule)
-ksoftirq-7     1dN.3   36us : add_preempt_count (_spin_lock)
-ksoftirq-7     1d..4   37us : put_prev_task_fair (schedule)
-ksoftirq-7     1d..4   38us : update_curr (put_prev_task_fair)
-[...]
-ksoftirq-7     1d..5   47us : _spin_trylock (tracing_record_cmdline)
-ksoftirq-7     1d..5   48us : add_preempt_count (_spin_trylock)
-ksoftirq-7     1d..6   49us : _spin_unlock (tracing_record_cmdline)
-ksoftirq-7     1d..6   49us : sub_preempt_count (_spin_unlock)
-ksoftirq-7     1d..4   50us : schedule (__cond_resched)
-
-The interrupt went off while running ksoftirqd. This task runs
-at SCHED_OTHER. Why did not we see the 'N' set early? This may
-be a harmless bug with x86_32 and 4K stacks. On x86_32 with 4K
-stacks configured, the interrupt and softirq run with their own
-stack. Some information is held on the top of the task's stack
-(need_resched and preempt_count are both stored there). The
-setting of the NEED_RESCHED bit is done directly to the task's
-stack, but the reading of the NEED_RESCHED is done by looking at
-the current stack, which in this case is the stack for the hard
-interrupt. This hides the fact that NEED_RESCHED has been set.
-We do not see the 'N' until we switch back to the task's
-assigned stack.
+# wakeup_rt latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 29 us, #85/85, CPU#3 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: sleep-2448 (uid:0 nice:0 policy:1 rt_prio:5)
+#    -----------------
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+  <idle>-0       3d.h4    1us+:      0:120:R   + [003]  2448: 94:R sleep
+  <idle>-0       3d.h4    2us : ttwu_do_activate.constprop.87 <-try_to_wake_up
+  <idle>-0       3d.h3    3us : check_preempt_curr <-ttwu_do_wakeup
+  <idle>-0       3d.h3    3us : resched_task <-check_preempt_curr
+  <idle>-0       3dNh3    4us : task_woken_rt <-ttwu_do_wakeup
+  <idle>-0       3dNh3    4us : _raw_spin_unlock <-try_to_wake_up
+  <idle>-0       3dNh3    4us : sub_preempt_count <-_raw_spin_unlock
+  <idle>-0       3dNh2    5us : ttwu_stat <-try_to_wake_up
+  <idle>-0       3dNh2    5us : _raw_spin_unlock_irqrestore <-try_to_wake_up
+  <idle>-0       3dNh2    6us : sub_preempt_count <-_raw_spin_unlock_irqrestore
+  <idle>-0       3dNh1    6us : _raw_spin_lock <-__run_hrtimer
+  <idle>-0       3dNh1    6us : add_preempt_count <-_raw_spin_lock
+  <idle>-0       3dNh2    7us : _raw_spin_unlock <-hrtimer_interrupt
+  <idle>-0       3dNh2    7us : sub_preempt_count <-_raw_spin_unlock
+  <idle>-0       3dNh1    7us : tick_program_event <-hrtimer_interrupt
+  <idle>-0       3dNh1    7us : clockevents_program_event <-tick_program_event
+  <idle>-0       3dNh1    8us : ktime_get <-clockevents_program_event
+  <idle>-0       3dNh1    8us : lapic_next_event <-clockevents_program_event
+  <idle>-0       3dNh1    8us : irq_exit <-smp_apic_timer_interrupt
+  <idle>-0       3dNh1    9us : sub_preempt_count <-irq_exit
+  <idle>-0       3dN.2    9us : idle_cpu <-irq_exit
+  <idle>-0       3dN.2    9us : rcu_irq_exit <-irq_exit
+  <idle>-0       3dN.2   10us : rcu_eqs_enter_common.isra.45 <-rcu_irq_exit
+  <idle>-0       3dN.2   10us : sub_preempt_count <-irq_exit
+  <idle>-0       3.N.1   11us : rcu_idle_exit <-cpu_idle
+  <idle>-0       3dN.1   11us : rcu_eqs_exit_common.isra.43 <-rcu_idle_exit
+  <idle>-0       3.N.1   11us : tick_nohz_idle_exit <-cpu_idle
+  <idle>-0       3dN.1   12us : menu_hrtimer_cancel <-tick_nohz_idle_exit
+  <idle>-0       3dN.1   12us : ktime_get <-tick_nohz_idle_exit
+  <idle>-0       3dN.1   12us : tick_do_update_jiffies64 <-tick_nohz_idle_exit
+  <idle>-0       3dN.1   13us : update_cpu_load_nohz <-tick_nohz_idle_exit
+  <idle>-0       3dN.1   13us : _raw_spin_lock <-update_cpu_load_nohz
+  <idle>-0       3dN.1   13us : add_preempt_count <-_raw_spin_lock
+  <idle>-0       3dN.2   13us : __update_cpu_load <-update_cpu_load_nohz
+  <idle>-0       3dN.2   14us : sched_avg_update <-__update_cpu_load
+  <idle>-0       3dN.2   14us : _raw_spin_unlock <-update_cpu_load_nohz
+  <idle>-0       3dN.2   14us : sub_preempt_count <-_raw_spin_unlock
+  <idle>-0       3dN.1   15us : calc_load_exit_idle <-tick_nohz_idle_exit
+  <idle>-0       3dN.1   15us : touch_softlockup_watchdog <-tick_nohz_idle_exit
+  <idle>-0       3dN.1   15us : hrtimer_cancel <-tick_nohz_idle_exit
+  <idle>-0       3dN.1   15us : hrtimer_try_to_cancel <-hrtimer_cancel
+  <idle>-0       3dN.1   16us : lock_hrtimer_base.isra.18 <-hrtimer_try_to_cancel
+  <idle>-0       3dN.1   16us : _raw_spin_lock_irqsave <-lock_hrtimer_base.isra.18
+  <idle>-0       3dN.1   16us : add_preempt_count <-_raw_spin_lock_irqsave
+  <idle>-0       3dN.2   17us : __remove_hrtimer <-remove_hrtimer.part.16
+  <idle>-0       3dN.2   17us : hrtimer_force_reprogram <-__remove_hrtimer
+  <idle>-0       3dN.2   17us : tick_program_event <-hrtimer_force_reprogram
+  <idle>-0       3dN.2   18us : clockevents_program_event <-tick_program_event
+  <idle>-0       3dN.2   18us : ktime_get <-clockevents_program_event
+  <idle>-0       3dN.2   18us : lapic_next_event <-clockevents_program_event
+  <idle>-0       3dN.2   19us : _raw_spin_unlock_irqrestore <-hrtimer_try_to_cancel
+  <idle>-0       3dN.2   19us : sub_preempt_count <-_raw_spin_unlock_irqrestore
+  <idle>-0       3dN.1   19us : hrtimer_forward <-tick_nohz_idle_exit
+  <idle>-0       3dN.1   20us : ktime_add_safe <-hrtimer_forward
+  <idle>-0       3dN.1   20us : ktime_add_safe <-hrtimer_forward
+  <idle>-0       3dN.1   20us : hrtimer_start_range_ns <-hrtimer_start_expires.constprop.11
+  <idle>-0       3dN.1   20us : __hrtimer_start_range_ns <-hrtimer_start_range_ns
+  <idle>-0       3dN.1   21us : lock_hrtimer_base.isra.18 <-__hrtimer_start_range_ns
+  <idle>-0       3dN.1   21us : _raw_spin_lock_irqsave <-lock_hrtimer_base.isra.18
+  <idle>-0       3dN.1   21us : add_preempt_count <-_raw_spin_lock_irqsave
+  <idle>-0       3dN.2   22us : ktime_add_safe <-__hrtimer_start_range_ns
+  <idle>-0       3dN.2   22us : enqueue_hrtimer <-__hrtimer_start_range_ns
+  <idle>-0       3dN.2   22us : tick_program_event <-__hrtimer_start_range_ns
+  <idle>-0       3dN.2   23us : clockevents_program_event <-tick_program_event
+  <idle>-0       3dN.2   23us : ktime_get <-clockevents_program_event
+  <idle>-0       3dN.2   23us : lapic_next_event <-clockevents_program_event
+  <idle>-0       3dN.2   24us : _raw_spin_unlock_irqrestore <-__hrtimer_start_range_ns
+  <idle>-0       3dN.2   24us : sub_preempt_count <-_raw_spin_unlock_irqrestore
+  <idle>-0       3dN.1   24us : account_idle_ticks <-tick_nohz_idle_exit
+  <idle>-0       3dN.1   24us : account_idle_time <-account_idle_ticks
+  <idle>-0       3.N.1   25us : sub_preempt_count <-cpu_idle
+  <idle>-0       3.N..   25us : schedule <-cpu_idle
+  <idle>-0       3.N..   25us : __schedule <-preempt_schedule
+  <idle>-0       3.N..   26us : add_preempt_count <-__schedule
+  <idle>-0       3.N.1   26us : rcu_note_context_switch <-__schedule
+  <idle>-0       3.N.1   26us : rcu_sched_qs <-rcu_note_context_switch
+  <idle>-0       3dN.1   27us : rcu_preempt_qs <-rcu_note_context_switch
+  <idle>-0       3.N.1   27us : _raw_spin_lock_irq <-__schedule
+  <idle>-0       3dN.1   27us : add_preempt_count <-_raw_spin_lock_irq
+  <idle>-0       3dN.2   28us : put_prev_task_idle <-__schedule
+  <idle>-0       3dN.2   28us : pick_next_task_stop <-pick_next_task
+  <idle>-0       3dN.2   28us : pick_next_task_rt <-pick_next_task
+  <idle>-0       3dN.2   29us : dequeue_pushable_task <-pick_next_task_rt
+  <idle>-0       3d..3   29us : __schedule <-preempt_schedule
+  <idle>-0       3d..3   30us :      0:120:R ==> [003]  2448: 94:R sleep
+
+This isn't that big of a trace, even with function tracing enabled,
+so I included the entire trace.
+
+The interrupt went off while when the system was idle. Somewhere
+before task_woken_rt() was called, the NEED_RESCHED flag was set,
+this is indicated by the first occurrence of the 'N' flag.
+
+Latency tracing and events
+--------------------------
+As function tracing can induce a much larger latency, but without
+seeing what happens within the latency it is hard to know what
+caused it. There is a middle ground, and that is with enabling
+events.
+
+ # echo 0 > options/function-trace
+ # echo wakeup_rt > current_tracer
+ # echo 1 > events/enable
+ # echo 1 > tracing_on
+ # echo 0 > tracing_max_latency
+ # chrt -f 5 sleep 1
+ # echo 0 > tracing_on
+ # cat trace
+# tracer: wakeup_rt
+#
+# wakeup_rt latency trace v1.1.5 on 3.8.0-test+
+# --------------------------------------------------------------------
+# latency: 6 us, #12/12, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
+#    -----------------
+#    | task: sleep-5882 (uid:0 nice:0 policy:1 rt_prio:5)
+#    -----------------
+#
+#                  _------=> CPU#            
+#                 / _-----=> irqs-off        
+#                | / _----=> need-resched    
+#                || / _---=> hardirq/softirq 
+#                ||| / _--=> preempt-depth   
+#                |||| /     delay             
+#  cmd     pid   ||||| time  |   caller      
+#     \   /      |||||  \    |   /           
+  <idle>-0       2d.h4    0us :      0:120:R   + [002]  5882: 94:R sleep
+  <idle>-0       2d.h4    0us : ttwu_do_activate.constprop.87 <-try_to_wake_up
+  <idle>-0       2d.h4    1us : sched_wakeup: comm=sleep pid=5882 prio=94 success=1 target_cpu=002
+  <idle>-0       2dNh2    1us : hrtimer_expire_exit: hrtimer=ffff88007796feb8
+  <idle>-0       2.N.2    2us : power_end: cpu_id=2
+  <idle>-0       2.N.2    3us : cpu_idle: state=4294967295 cpu_id=2
+  <idle>-0       2dN.3    4us : hrtimer_cancel: hrtimer=ffff88007d50d5e0
+  <idle>-0       2dN.3    4us : hrtimer_start: hrtimer=ffff88007d50d5e0 function=tick_sched_timer expires=34311211000000 softexpires=34311211000000
+  <idle>-0       2.N.2    5us : rcu_utilization: Start context switch
+  <idle>-0       2.N.2    5us : rcu_utilization: End context switch
+  <idle>-0       2d..3    6us : __schedule <-schedule
+  <idle>-0       2d..3    6us :      0:120:R ==> [002]  5882: 94:R sleep
+
 
 function
 --------
@@ -1039,6 +1653,7 @@ function
 This tracer is the function tracer. Enabling the function tracer
 can be done from the debug file system. Make sure the
 ftrace_enabled is set; otherwise this tracer is a nop.
+See the "ftrace_enabled" section below.
 
  # sysctl kernel.ftrace_enabled=1
  # echo function > current_tracer
@@ -1048,23 +1663,23 @@ ftrace_enabled is set; otherwise this tracer is a nop.
  # cat trace
 # tracer: function
 #
-#           TASK-PID   CPU#    TIMESTAMP  FUNCTION
-#              | |      |          |         |
-            bash-4003  [00]   123.638713: finish_task_switch <-schedule
-            bash-4003  [00]   123.638714: _spin_unlock_irq <-finish_task_switch
-            bash-4003  [00]   123.638714: sub_preempt_count <-_spin_unlock_irq
-            bash-4003  [00]   123.638715: hrtick_set <-schedule
-            bash-4003  [00]   123.638715: _spin_lock_irqsave <-hrtick_set
-            bash-4003  [00]   123.638716: add_preempt_count <-_spin_lock_irqsave
-            bash-4003  [00]   123.638716: _spin_unlock_irqrestore <-hrtick_set
-            bash-4003  [00]   123.638717: sub_preempt_count <-_spin_unlock_irqrestore
-            bash-4003  [00]   123.638717: hrtick_clear <-hrtick_set
-            bash-4003  [00]   123.638718: sub_preempt_count <-schedule
-            bash-4003  [00]   123.638718: sub_preempt_count <-preempt_schedule
-            bash-4003  [00]   123.638719: wait_for_completion <-__stop_machine_run
-            bash-4003  [00]   123.638719: wait_for_common <-wait_for_completion
-            bash-4003  [00]   123.638720: _spin_lock_irq <-wait_for_common
-            bash-4003  [00]   123.638720: add_preempt_count <-_spin_lock_irq
+# entries-in-buffer/entries-written: 24799/24799   #P:4
+#
+#                              _-----=> irqs-off
+#                             / _----=> need-resched
+#                            | / _---=> hardirq/softirq
+#                            || / _--=> preempt-depth
+#                            ||| /     delay
+#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+#              | |       |   ||||       |         |
+            bash-1994  [002] ....  3082.063030: mutex_unlock <-rb_simple_write
+            bash-1994  [002] ....  3082.063031: __mutex_unlock_slowpath <-mutex_unlock
+            bash-1994  [002] ....  3082.063031: __fsnotify_parent <-fsnotify_modify
+            bash-1994  [002] ....  3082.063032: fsnotify <-fsnotify_modify
+            bash-1994  [002] ....  3082.063032: __srcu_read_lock <-fsnotify
+            bash-1994  [002] ....  3082.063032: add_preempt_count <-__srcu_read_lock
+            bash-1994  [002] ...1  3082.063032: sub_preempt_count <-__srcu_read_lock
+            bash-1994  [002] ....  3082.063033: __srcu_read_unlock <-fsnotify
 [...]
 
 
@@ -1214,79 +1829,19 @@ int main (int argc, char **argv)
         return 0;
 }
 
+Or this simple script!
 
-hw-branch-tracer (x86 only)
----------------------------
-
-This tracer uses the x86 last branch tracing hardware feature to
-collect a branch trace on all cpus with relatively low overhead.
-
-The tracer uses a fixed-size circular buffer per cpu and only
-traces ring 0 branches. The trace file dumps that buffer in the
-following format:
-
-# tracer: hw-branch-tracer
-#
-# CPU#        TO  <-  FROM
-   0  scheduler_tick+0xb5/0x1bf   <-  task_tick_idle+0x5/0x6
-   2  run_posix_cpu_timers+0x2b/0x72a     <-  run_posix_cpu_timers+0x25/0x72a
-   0  scheduler_tick+0x139/0x1bf          <-  scheduler_tick+0xed/0x1bf
-   0  scheduler_tick+0x17c/0x1bf          <-  scheduler_tick+0x148/0x1bf
-   2  run_posix_cpu_timers+0x9e/0x72a     <-  run_posix_cpu_timers+0x5e/0x72a
-   0  scheduler_tick+0x1b6/0x1bf          <-  scheduler_tick+0x1aa/0x1bf
-
-
-The tracer may be used to dump the trace for the oops'ing cpu on
-a kernel oops into the system log. To enable this,
-ftrace_dump_on_oops must be set. To set ftrace_dump_on_oops, one
-can either use the sysctl function or set it via the proc system
-interface.
-
-  sysctl kernel.ftrace_dump_on_oops=n
-
-or
-
-  echo n > /proc/sys/kernel/ftrace_dump_on_oops
-
-If n = 1, ftrace will dump buffers of all CPUs, if n = 2 ftrace will
-only dump the buffer of the CPU that triggered the oops.
-
-Here's an example of such a dump after a null pointer
-dereference in a kernel module:
-
-[57848.105921] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
-[57848.106019] IP: [<ffffffffa0000006>] open+0x6/0x14 [oops]
-[57848.106019] PGD 2354e9067 PUD 2375e7067 PMD 0
-[57848.106019] Oops: 0002 [#1] SMP
-[57848.106019] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:20:05.0/local_cpus
-[57848.106019] Dumping ftrace buffer:
-[57848.106019] ---------------------------------
-[...]
-[57848.106019]    0  chrdev_open+0xe6/0x165       <-  cdev_put+0x23/0x24
-[57848.106019]    0  chrdev_open+0x117/0x165      <-  chrdev_open+0xfa/0x165
-[57848.106019]    0  chrdev_open+0x120/0x165      <-  chrdev_open+0x11c/0x165
-[57848.106019]    0  chrdev_open+0x134/0x165      <-  chrdev_open+0x12b/0x165
-[57848.106019]    0  open+0x0/0x14 [oops]         <-  chrdev_open+0x144/0x165
-[57848.106019]    0  page_fault+0x0/0x30          <-  open+0x6/0x14 [oops]
-[57848.106019]    0  error_entry+0x0/0x5b         <-  page_fault+0x4/0x30
-[57848.106019]    0  error_kernelspace+0x0/0x31   <-  error_entry+0x59/0x5b
-[57848.106019]    0  error_sti+0x0/0x1    <-  error_kernelspace+0x2d/0x31
-[57848.106019]    0  page_fault+0x9/0x30          <-  error_sti+0x0/0x1
-[57848.106019]    0  do_page_fault+0x0/0x881      <-  page_fault+0x1a/0x30
-[...]
-[57848.106019]    0  do_page_fault+0x66b/0x881    <-  is_prefetch+0x1ee/0x1f2
-[57848.106019]    0  do_page_fault+0x6e0/0x881    <-  do_page_fault+0x67a/0x881
-[57848.106019]    0  oops_begin+0x0/0x96          <-  do_page_fault+0x6e0/0x881
-[57848.106019]    0  trace_hw_branch_oops+0x0/0x2d        <-  oops_begin+0x9/0x96
-[...]
-[57848.106019]    0  ds_suspend_bts+0x2a/0xe3     <-  ds_suspend_bts+0x1a/0xe3
-[57848.106019] ---------------------------------
-[57848.106019] CPU 0
-[57848.106019] Modules linked in: oops
-[57848.106019] Pid: 5542, comm: cat Tainted: G        W  2.6.28 #23
-[57848.106019] RIP: 0010:[<ffffffffa0000006>]  [<ffffffffa0000006>] open+0x6/0x14 [oops]
-[57848.106019] RSP: 0018:ffff880235457d48  EFLAGS: 00010246
-[...]
+------
+#!/bin/bash
+
+debugfs=`sed -ne 's/^debugfs \(.*\) debugfs.*/\1/p' /proc/mounts`
+echo nop > $debugfs/tracing/current_tracer
+echo 0 > $debugfs/tracing/tracing_on
+echo $$ > $debugfs/tracing/set_ftrace_pid
+echo function > $debugfs/tracing/current_tracer
+echo 1 > $debugfs/tracing/tracing_on
+exec "$@"
+------
 
 
 function graph tracer
@@ -1473,16 +2028,18 @@ starts of pointing to a simple return. (Enabling FTRACE will
 include the -pg switch in the compiling of the kernel.)
 
 At compile time every C file object is run through the
-recordmcount.pl script (located in the scripts directory). This
-script will process the C object using objdump to find all the
-locations in the .text section that call mcount. (Note, only the
-.text section is processed, since processing other sections like
-.init.text may cause races due to those sections being freed).
+recordmcount program (located in the scripts directory). This
+program will parse the ELF headers in the C object to find all
+the locations in the .text section that call mcount. (Note, only
+white listed .text sections are processed, since processing other
+sections like .init.text may cause races due to those sections
+being freed unexpectedly).
 
 A new section called "__mcount_loc" is created that holds
 references to all the mcount call sites in the .text section.
-This section is compiled back into the original object. The
-final linker will add all these references into a single table.
+The recordmcount program re-links this section back into the
+original object. The final linking stage of the kernel will add all these
+references into a single table.
 
 On boot up, before SMP is initialized, the dynamic ftrace code
 scans this table and updates all the locations into nops. It
@@ -1493,13 +2050,25 @@ unloaded, it also removes its functions from the ftrace function
 list. This is automatic in the module unload code, and the
 module author does not need to worry about it.
 
-When tracing is enabled, kstop_machine is called to prevent
-races with the CPUS executing code being modified (which can
-cause the CPU to do undesirable things), and the nops are
+When tracing is enabled, the process of modifying the function
+tracepoints is dependent on architecture. The old method is to use
+kstop_machine to prevent races with the CPUs executing code being
+modified (which can cause the CPU to do undesirable things, especially
+if the modified code crosses cache (or page) boundaries), and the nops are
 patched back to calls. But this time, they do not call mcount
 (which is just a function stub). They now call into the ftrace
 infrastructure.
 
+The new method of modifying the function tracepoints is to place
+a breakpoint at the location to be modified, sync all CPUs, modify
+the rest of the instruction not covered by the breakpoint. Sync
+all CPUs again, and then remove the breakpoint with the finished
+version to the ftrace call site.
+
+Some archs do not even need to monkey around with the synchronization,
+and can just slap the new code on top of the old without any
+problems with other CPUs executing it at the same time.
+
 One special side-effect to the recording of the functions being
 traced is that we can now selectively choose which functions we
 wish to trace and which ones we want the mcount calls to remain
@@ -1530,20 +2099,28 @@ mutex_lock
 
 If I am only interested in sys_nanosleep and hrtimer_interrupt:
 
- # echo sys_nanosleep hrtimer_interrupt \
-                > set_ftrace_filter
+ # echo sys_nanosleep hrtimer_interrupt > set_ftrace_filter
  # echo function > current_tracer
  # echo 1 > tracing_on
  # usleep 1
  # echo 0 > tracing_on
  # cat trace
-# tracer: ftrace
+# tracer: function
+#
+# entries-in-buffer/entries-written: 5/5   #P:4
 #
-#           TASK-PID   CPU#    TIMESTAMP  FUNCTION
-#              | |      |          |         |
-          usleep-4134  [00]  1317.070017: hrtimer_interrupt <-smp_apic_timer_interrupt
-          usleep-4134  [00]  1317.070111: sys_nanosleep <-syscall_call
-          <idle>-0     [00]  1317.070115: hrtimer_interrupt <-smp_apic_timer_interrupt
+#                              _-----=> irqs-off
+#                             / _----=> need-resched
+#                            | / _---=> hardirq/softirq
+#                            || / _--=> preempt-depth
+#                            ||| /     delay
+#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+#              | |       |   ||||       |         |
+          usleep-2665  [001] ....  4186.475355: sys_nanosleep <-system_call_fastpath
+          <idle>-0     [001] d.h1  4186.475409: hrtimer_interrupt <-smp_apic_timer_interrupt
+          usleep-2665  [001] d.h1  4186.475426: hrtimer_interrupt <-smp_apic_timer_interrupt
+          <idle>-0     [003] d.h1  4186.475426: hrtimer_interrupt <-smp_apic_timer_interrupt
+          <idle>-0     [002] d.h1  4186.475427: hrtimer_interrupt <-smp_apic_timer_interrupt
 
 To see which functions are being traced, you can cat the file:
 
@@ -1571,20 +2148,25 @@ Note: It is better to use quotes to enclose the wild cards,
 
 Produces:
 
-# tracer: ftrace
+# tracer: function
 #
-#           TASK-PID   CPU#    TIMESTAMP  FUNCTION
-#              | |      |          |         |
-            bash-4003  [00]  1480.611794: hrtimer_init <-copy_process
-            bash-4003  [00]  1480.611941: hrtimer_start <-hrtick_set
-            bash-4003  [00]  1480.611956: hrtimer_cancel <-hrtick_clear
-            bash-4003  [00]  1480.611956: hrtimer_try_to_cancel <-hrtimer_cancel
-          <idle>-0     [00]  1480.612019: hrtimer_get_next_event <-get_next_timer_interrupt
-          <idle>-0     [00]  1480.612025: hrtimer_get_next_event <-get_next_timer_interrupt
-          <idle>-0     [00]  1480.612032: hrtimer_get_next_event <-get_next_timer_interrupt
-          <idle>-0     [00]  1480.612037: hrtimer_get_next_event <-get_next_timer_interrupt
-          <idle>-0     [00]  1480.612382: hrtimer_get_next_event <-get_next_timer_interrupt
-
+# entries-in-buffer/entries-written: 897/897   #P:4
+#
+#                              _-----=> irqs-off
+#                             / _----=> need-resched
+#                            | / _---=> hardirq/softirq
+#                            || / _--=> preempt-depth
+#                            ||| /     delay
+#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+#              | |       |   ||||       |         |
+          <idle>-0     [003] dN.1  4228.547803: hrtimer_cancel <-tick_nohz_idle_exit
+          <idle>-0     [003] dN.1  4228.547804: hrtimer_try_to_cancel <-hrtimer_cancel
+          <idle>-0     [003] dN.2  4228.547805: hrtimer_force_reprogram <-__remove_hrtimer
+          <idle>-0     [003] dN.1  4228.547805: hrtimer_forward <-tick_nohz_idle_exit
+          <idle>-0     [003] dN.1  4228.547805: hrtimer_start_range_ns <-hrtimer_start_expires.constprop.11
+          <idle>-0     [003] d..1  4228.547858: hrtimer_get_next_event <-get_next_timer_interrupt
+          <idle>-0     [003] d..1  4228.547859: hrtimer_start <-__tick_nohz_idle_enter
+          <idle>-0     [003] d..2  4228.547860: hrtimer_force_reprogram <-__rem
 
 Notice that we lost the sys_nanosleep.
 
@@ -1651,19 +2233,29 @@ traced.
 
 Produces:
 
-# tracer: ftrace
+# tracer: function
+#
+# entries-in-buffer/entries-written: 39608/39608   #P:4
 #
-#           TASK-PID   CPU#    TIMESTAMP  FUNCTION
-#              | |      |          |         |
-            bash-4043  [01]   115.281644: finish_task_switch <-schedule
-            bash-4043  [01]   115.281645: hrtick_set <-schedule
-            bash-4043  [01]   115.281645: hrtick_clear <-hrtick_set
-            bash-4043  [01]   115.281646: wait_for_completion <-__stop_machine_run
-            bash-4043  [01]   115.281647: wait_for_common <-wait_for_completion
-            bash-4043  [01]   115.281647: kthread_stop <-stop_machine_run
-            bash-4043  [01]   115.281648: init_waitqueue_head <-kthread_stop
-            bash-4043  [01]   115.281648: wake_up_process <-kthread_stop
-            bash-4043  [01]   115.281649: try_to_wake_up <-wake_up_process
+#                              _-----=> irqs-off
+#                             / _----=> need-resched
+#                            | / _---=> hardirq/softirq
+#                            || / _--=> preempt-depth
+#                            ||| /     delay
+#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+#              | |       |   ||||       |         |
+            bash-1994  [000] ....  4342.324896: file_ra_state_init <-do_dentry_open
+            bash-1994  [000] ....  4342.324897: open_check_o_direct <-do_last
+            bash-1994  [000] ....  4342.324897: ima_file_check <-do_last
+            bash-1994  [000] ....  4342.324898: process_measurement <-ima_file_check
+            bash-1994  [000] ....  4342.324898: ima_get_action <-process_measurement
+            bash-1994  [000] ....  4342.324898: ima_match_policy <-ima_get_action
+            bash-1994  [000] ....  4342.324899: do_truncate <-do_last
+            bash-1994  [000] ....  4342.324899: should_remove_suid <-do_truncate
+            bash-1994  [000] ....  4342.324899: notify_change <-do_truncate
+            bash-1994  [000] ....  4342.324900: current_fs_time <-notify_change
+            bash-1994  [000] ....  4342.324900: current_kernel_time <-current_fs_time
+            bash-1994  [000] ....  4342.324900: timespec_trunc <-current_fs_time
 
 We can see that there's no more lock or preempt tracing.
 
@@ -1729,6 +2321,28 @@ this special filter via:
  echo > set_graph_function
 
 
+ftrace_enabled
+--------------
+
+Note, the proc sysctl ftrace_enable is a big on/off switch for the
+function tracer. By default it is enabled (when function tracing is
+enabled in the kernel). If it is disabled, all function tracing is
+disabled. This includes not only the function tracers for ftrace, but
+also for any other uses (perf, kprobes, stack tracing, profiling, etc).
+
+Please disable this with care.
+
+This can be disable (and enabled) with:
+
+  sysctl kernel.ftrace_enabled=0
+  sysctl kernel.ftrace_enabled=1
+
+ or
+
+  echo 0 > /proc/sys/kernel/ftrace_enabled
+  echo 1 > /proc/sys/kernel/ftrace_enabled
+
+
 Filter commands
 ---------------
 
@@ -1763,12 +2377,58 @@ The following commands are supported:
 
    echo '__schedule_bug:traceoff:5' > set_ftrace_filter
 
+  To always disable tracing when __schedule_bug is hit:
+
+   echo '__schedule_bug:traceoff' > set_ftrace_filter
+
   These commands are cumulative whether or not they are appended
   to set_ftrace_filter. To remove a command, prepend it by '!'
   and drop the parameter:
 
+   echo '!__schedule_bug:traceoff:0' > set_ftrace_filter
+
+    The above removes the traceoff command for __schedule_bug
+    that have a counter. To remove commands without counters:
+
    echo '!__schedule_bug:traceoff' > set_ftrace_filter
 
+- snapshot
+  Will cause a snapshot to be triggered when the function is hit.
+
+   echo 'native_flush_tlb_others:snapshot' > set_ftrace_filter
+
+  To only snapshot once:
+
+   echo 'native_flush_tlb_others:snapshot:1' > set_ftrace_filter
+
+  To remove the above commands:
+
+   echo '!native_flush_tlb_others:snapshot' > set_ftrace_filter
+   echo '!native_flush_tlb_others:snapshot:0' > set_ftrace_filter
+
+- enable_event/disable_event
+  These commands can enable or disable a trace event. Note, because
+  function tracing callbacks are very sensitive, when these commands
+  are registered, the trace point is activated, but disabled in
+  a "soft" mode. That is, the tracepoint will be called, but
+  just will not be traced. The event tracepoint stays in this mode
+  as long as there's a command that triggers it.
+
+   echo 'try_to_wake_up:enable_event:sched:sched_switch:2' > \
+         set_ftrace_filter
+
+  The format is:
+
+    <function>:enable_event:<system>:<event>[:count]
+    <function>:disable_event:<system>:<event>[:count]
+
+  To remove the events commands:
+
+
+   echo '!try_to_wake_up:enable_event:sched:sched_switch:0' > \
+         set_ftrace_filter
+   echo '!schedule:disable_event:sched:sched_switch' > \
+         set_ftrace_filter
 
 trace_pipe
 ----------
@@ -1787,28 +2447,31 @@ different. The trace is live.
  # cat trace
 # tracer: function
 #
-#           TASK-PID   CPU#    TIMESTAMP  FUNCTION
-#              | |      |          |         |
+# entries-in-buffer/entries-written: 0/0   #P:4
+#
+#                              _-----=> irqs-off
+#                             / _----=> need-resched
+#                            | / _---=> hardirq/softirq
+#                            || / _--=> preempt-depth
+#                            ||| /     delay
+#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+#              | |       |   ||||       |         |
 
  #
  # cat /tmp/trace.out
-            bash-4043  [00] 41.267106: finish_task_switch <-schedule
-            bash-4043  [00] 41.267106: hrtick_set <-schedule
-            bash-4043  [00] 41.267107: hrtick_clear <-hrtick_set
-            bash-4043  [00] 41.267108: wait_for_completion <-__stop_machine_run
-            bash-4043  [00] 41.267108: wait_for_common <-wait_for_completion
-            bash-4043  [00] 41.267109: kthread_stop <-stop_machine_run
-            bash-4043  [00] 41.267109: init_waitqueue_head <-kthread_stop
-            bash-4043  [00] 41.267110: wake_up_process <-kthread_stop
-            bash-4043  [00] 41.267110: try_to_wake_up <-wake_up_process
-            bash-4043  [00] 41.267111: select_task_rq_rt <-try_to_wake_up
+            bash-1994  [000] ....  5281.568961: mutex_unlock <-rb_simple_write
+            bash-1994  [000] ....  5281.568963: __mutex_unlock_slowpath <-mutex_unlock
+            bash-1994  [000] ....  5281.568963: __fsnotify_parent <-fsnotify_modify
+            bash-1994  [000] ....  5281.568964: fsnotify <-fsnotify_modify
+            bash-1994  [000] ....  5281.568964: __srcu_read_lock <-fsnotify
+            bash-1994  [000] ....  5281.568964: add_preempt_count <-__srcu_read_lock
+            bash-1994  [000] ...1  5281.568965: sub_preempt_count <-__srcu_read_lock
+            bash-1994  [000] ....  5281.568965: __srcu_read_unlock <-fsnotify
+            bash-1994  [000] ....  5281.568967: sys_dup2 <-system_call_fastpath
 
 
 Note, reading the trace_pipe file will block until more input is
-added. By changing the tracer, trace_pipe will issue an EOF. We
-needed to set the function tracer _before_ we "cat" the
-trace_pipe file.
-
+added.
 
 trace entries
 -------------
@@ -1817,31 +2480,50 @@ Having too much or not enough data can be troublesome in
 diagnosing an issue in the kernel. The file buffer_size_kb is
 used to modify the size of the internal trace buffers. The
 number listed is the number of entries that can be recorded per
-CPU. To know the full size, multiply the number of possible CPUS
+CPU. To know the full size, multiply the number of possible CPUs
 with the number of entries.
 
  # cat buffer_size_kb
 1408 (units kilobytes)
 
-Note, to modify this, you must have tracing completely disabled.
-To do that, echo "nop" into the current_tracer. If the
-current_tracer is not set to "nop", an EINVAL error will be
-returned.
+Or simply read buffer_total_size_kb
+
+ # cat buffer_total_size_kb 
+5632
+
+To modify the buffer, simple echo in a number (in 1024 byte segments).
 
- # echo nop > current_tracer
  # echo 10000 > buffer_size_kb
  # cat buffer_size_kb
 10000 (units kilobytes)
 
-The number of pages which will be allocated is limited to a
-percentage of available memory. Allocating too much will produce
-an error.
+It will try to allocate as much as possible. If you allocate too
+much, it can cause Out-Of-Memory to trigger.
 
  # echo 1000000000000 > buffer_size_kb
 -bash: echo: write error: Cannot allocate memory
  # cat buffer_size_kb
 85
 
+The per_cpu buffers can be changed individually as well:
+
+ # echo 10000 > per_cpu/cpu0/buffer_size_kb
+ # echo 100 > per_cpu/cpu1/buffer_size_kb
+
+When the per_cpu buffers are not the same, the buffer_size_kb
+at the top level will just show an X
+
+ # cat buffer_size_kb
+X
+
+This is where the buffer_total_size_kb is useful:
+
+ # cat buffer_total_size_kb 
+12916
+
+Writing to the top level buffer_size_kb will reset all the buffers
+to be the same again.
+
 Snapshot
 --------
 CONFIG_TRACER_SNAPSHOT makes a generic snapshot feature
@@ -1873,7 +2555,7 @@ feature:
 
         status\input  |     0      |     1      |    else    |
         --------------+------------+------------+------------+
-        not allocated |(do nothing)| alloc+swap |   EINVAL   |
+        not allocated |(do nothing)| alloc+swap |(do nothing)|
         --------------+------------+------------+------------+
         allocated     |    free    |    swap    |   clear    |
         --------------+------------+------------+------------+
@@ -1925,7 +2607,188 @@ bash: echo: write error: Device or resource busy
  # cat snapshot
 cat: snapshot: Device or resource busy
 
+
+Instances
+---------
+In the debugfs tracing directory is a directory called "instances".
+This directory can have new directories created inside of it using
+mkdir, and removing directories with rmdir. The directory created
+with mkdir in this directory will already contain files and other
+directories after it is created.
+
+ # mkdir instances/foo
+ # ls instances/foo
+buffer_size_kb  buffer_total_size_kb  events  free_buffer  per_cpu
+set_event  snapshot  trace  trace_clock  trace_marker  trace_options
+trace_pipe  tracing_on
+
+As you can see, the new directory looks similar to the tracing directory
+itself. In fact, it is very similar, except that the buffer and
+events are agnostic from the main director, or from any other
+instances that are created.
+
+The files in the new directory work just like the files with the
+same name in the tracing directory except the buffer that is used
+is a separate and new buffer. The files affect that buffer but do not
+affect the main buffer with the exception of trace_options. Currently,
+the trace_options affect all instances and the top level buffer
+the same, but this may change in future releases. That is, options
+may become specific to the instance they reside in.
+
+Notice that none of the function tracer files are there, nor is
+current_tracer and available_tracers. This is because the buffers
+can currently only have events enabled for them.
+
+ # mkdir instances/foo
+ # mkdir instances/bar
+ # mkdir instances/zoot
+ # echo 100000 > buffer_size_kb
+ # echo 1000 > instances/foo/buffer_size_kb
+ # echo 5000 > instances/bar/per_cpu/cpu1/buffer_size_kb
+ # echo function > current_trace
+ # echo 1 > instances/foo/events/sched/sched_wakeup/enable
+ # echo 1 > instances/foo/events/sched/sched_wakeup_new/enable
+ # echo 1 > instances/foo/events/sched/sched_switch/enable
+ # echo 1 > instances/bar/events/irq/enable
+ # echo 1 > instances/zoot/events/syscalls/enable
+ # cat trace_pipe
+CPU:2 [LOST 11745 EVENTS]
+            bash-2044  [002] .... 10594.481032: _raw_spin_lock_irqsave <-get_page_from_freelist
+            bash-2044  [002] d... 10594.481032: add_preempt_count <-_raw_spin_lock_irqsave
+            bash-2044  [002] d..1 10594.481032: __rmqueue <-get_page_from_freelist
+            bash-2044  [002] d..1 10594.481033: _raw_spin_unlock <-get_page_from_freelist
+            bash-2044  [002] d..1 10594.481033: sub_preempt_count <-_raw_spin_unlock
+            bash-2044  [002] d... 10594.481033: get_pageblock_flags_group <-get_pageblock_migratetype
+            bash-2044  [002] d... 10594.481034: __mod_zone_page_state <-get_page_from_freelist
+            bash-2044  [002] d... 10594.481034: zone_statistics <-get_page_from_freelist
+            bash-2044  [002] d... 10594.481034: __inc_zone_state <-zone_statistics
+            bash-2044  [002] d... 10594.481034: __inc_zone_state <-zone_statistics
+            bash-2044  [002] .... 10594.481035: arch_dup_task_struct <-copy_process
+[...]
+
+ # cat instances/foo/trace_pipe
+            bash-1998  [000] d..4   136.676759: sched_wakeup: comm=kworker/0:1 pid=59 prio=120 success=1 target_cpu=000
+            bash-1998  [000] dN.4   136.676760: sched_wakeup: comm=bash pid=1998 prio=120 success=1 target_cpu=000
+          <idle>-0     [003] d.h3   136.676906: sched_wakeup: comm=rcu_preempt pid=9 prio=120 success=1 target_cpu=003
+          <idle>-0     [003] d..3   136.676909: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=rcu_preempt next_pid=9 next_prio=120
+     rcu_preempt-9     [003] d..3   136.676916: sched_switch: prev_comm=rcu_preempt prev_pid=9 prev_prio=120 prev_state=S ==> next_comm=swapper/3 next_pid=0 next_prio=120
+            bash-1998  [000] d..4   136.677014: sched_wakeup: comm=kworker/0:1 pid=59 prio=120 success=1 target_cpu=000
+            bash-1998  [000] dN.4   136.677016: sched_wakeup: comm=bash pid=1998 prio=120 success=1 target_cpu=000
+            bash-1998  [000] d..3   136.677018: sched_switch: prev_comm=bash prev_pid=1998 prev_prio=120 prev_state=R+ ==> next_comm=kworker/0:1 next_pid=59 next_prio=120
+     kworker/0:1-59    [000] d..4   136.677022: sched_wakeup: comm=sshd pid=1995 prio=120 success=1 target_cpu=001
+     kworker/0:1-59    [000] d..3   136.677025: sched_switch: prev_comm=kworker/0:1 prev_pid=59 prev_prio=120 prev_state=S ==> next_comm=bash next_pid=1998 next_prio=120
+[...]
+
+ # cat instances/bar/trace_pipe
+     migration/1-14    [001] d.h3   138.732674: softirq_raise: vec=3 [action=NET_RX]
+          <idle>-0     [001] dNh3   138.732725: softirq_raise: vec=3 [action=NET_RX]
+            bash-1998  [000] d.h1   138.733101: softirq_raise: vec=1 [action=TIMER]
+            bash-1998  [000] d.h1   138.733102: softirq_raise: vec=9 [action=RCU]
+            bash-1998  [000] ..s2   138.733105: softirq_entry: vec=1 [action=TIMER]
+            bash-1998  [000] ..s2   138.733106: softirq_exit: vec=1 [action=TIMER]
+            bash-1998  [000] ..s2   138.733106: softirq_entry: vec=9 [action=RCU]
+            bash-1998  [000] ..s2   138.733109: softirq_exit: vec=9 [action=RCU]
+            sshd-1995  [001] d.h1   138.733278: irq_handler_entry: irq=21 name=uhci_hcd:usb4
+            sshd-1995  [001] d.h1   138.733280: irq_handler_exit: irq=21 ret=unhandled
+            sshd-1995  [001] d.h1   138.733281: irq_handler_entry: irq=21 name=eth0
+            sshd-1995  [001] d.h1   138.733283: irq_handler_exit: irq=21 ret=handled
+[...]
+
+ # cat instances/zoot/trace
+# tracer: nop
+#
+# entries-in-buffer/entries-written: 18996/18996   #P:4
+#
+#                              _-----=> irqs-off
+#                             / _----=> need-resched
+#                            | / _---=> hardirq/softirq
+#                            || / _--=> preempt-depth
+#                            ||| /     delay
+#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
+#              | |       |   ||||       |         |
+            bash-1998  [000] d...   140.733501: sys_write -> 0x2
+            bash-1998  [000] d...   140.733504: sys_dup2(oldfd: a, newfd: 1)
+            bash-1998  [000] d...   140.733506: sys_dup2 -> 0x1
+            bash-1998  [000] d...   140.733508: sys_fcntl(fd: a, cmd: 1, arg: 0)
+            bash-1998  [000] d...   140.733509: sys_fcntl -> 0x1
+            bash-1998  [000] d...   140.733510: sys_close(fd: a)
+            bash-1998  [000] d...   140.733510: sys_close -> 0x0
+            bash-1998  [000] d...   140.733514: sys_rt_sigprocmask(how: 0, nset: 0, oset: 6e2768, sigsetsize: 8)
+            bash-1998  [000] d...   140.733515: sys_rt_sigprocmask -> 0x0
+            bash-1998  [000] d...   140.733516: sys_rt_sigaction(sig: 2, act: 7fff718846f0, oact: 7fff71884650, sigsetsize: 8)
+            bash-1998  [000] d...   140.733516: sys_rt_sigaction -> 0x0
+
+You can see that the trace of the top most trace buffer shows only
+the function tracing. The foo instance displays wakeups and task
+switches.
+
+To remove the instances, simply delete their directories:
+
+ # rmdir instances/foo
+ # rmdir instances/bar
+ # rmdir instances/zoot
+
+Note, if a process has a trace file open in one of the instance
+directories, the rmdir will fail with EBUSY.
+
+
+Stack trace
 -----------
+Since the kernel has a fixed sized stack, it is important not to
+waste it in functions. A kernel developer must be conscience of
+what they allocate on the stack. If they add too much, the system
+can be in danger of a stack overflow, and corruption will occur,
+usually leading to a system panic.
+
+There are some tools that check this, usually with interrupts
+periodically checking usage. But if you can perform a check
+at every function call that will become very useful. As ftrace provides
+a function tracer, it makes it convenient to check the stack size
+at every function call. This is enabled via the stack tracer.
+
+CONFIG_STACK_TRACER enables the ftrace stack tracing functionality.
+To enable it, write a '1' into /proc/sys/kernel/stack_tracer_enabled.
+
+ # echo 1 > /proc/sys/kernel/stack_tracer_enabled
+
+You can also enable it from the kernel command line to trace
+the stack size of the kernel during boot up, by adding "stacktrace"
+to the kernel command line parameter.
+
+After running it for a few minutes, the output looks like:
+
+ # cat stack_max_size
+2928
+
+ # cat stack_trace
+        Depth    Size   Location    (18 entries)
+        -----    ----   --------
+  0)     2928     224   update_sd_lb_stats+0xbc/0x4ac
+  1)     2704     160   find_busiest_group+0x31/0x1f1
+  2)     2544     256   load_balance+0xd9/0x662
+  3)     2288      80   idle_balance+0xbb/0x130
+  4)     2208     128   __schedule+0x26e/0x5b9
+  5)     2080      16   schedule+0x64/0x66
+  6)     2064     128   schedule_timeout+0x34/0xe0
+  7)     1936     112   wait_for_common+0x97/0xf1
+  8)     1824      16   wait_for_completion+0x1d/0x1f
+  9)     1808     128   flush_work+0xfe/0x119
+ 10)     1680      16   tty_flush_to_ldisc+0x1e/0x20
+ 11)     1664      48   input_available_p+0x1d/0x5c
+ 12)     1616      48   n_tty_poll+0x6d/0x134
+ 13)     1568      64   tty_poll+0x64/0x7f
+ 14)     1504     880   do_select+0x31e/0x511
+ 15)      624     400   core_sys_select+0x177/0x216
+ 16)      224      96   sys_select+0x91/0xb9
+ 17)      128     128   system_call_fastpath+0x16/0x1b
+
+Note, if -mfentry is being used by gcc, functions get traced before
+they set up the stack frame. This means that leaf level functions
+are not tested by the stack tracer when -mfentry is used.
+
+Currently, -mfentry is used by gcc 4.6.0 and above on x86 only.
+
+---------
 
 More details can be found in the source code, in the
 kernel/trace/*.c files.
diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt
index c0e1ceed75a4..da49437d5aeb 100644
--- a/Documentation/trace/tracepoints.txt
+++ b/Documentation/trace/tracepoints.txt
@@ -81,7 +81,6 @@ tracepoint_synchronize_unregister() must be called before the end of
 the module exit function to make sure there is no caller left using
 the probe. This, and the fact that preemption is disabled around the
 probe call, make sure that probe removal and module unload are safe.
-See the "Probe example" section below for a sample probe module.
 
 The tracepoint mechanism supports inserting multiple instances of the
 same tracepoint, but a single definition must be made of a given
@@ -100,17 +99,3 @@ core kernel image or in modules.
 If the tracepoint has to be used in kernel modules, an
 EXPORT_TRACEPOINT_SYMBOL_GPL() or EXPORT_TRACEPOINT_SYMBOL() can be
 used to export the defined tracepoints.
-
-* Probe / tracepoint example
-
-See the example provided in samples/tracepoints
-
-Compile them with your kernel.  They are built during 'make' (not
-'make modules') when CONFIG_SAMPLE_TRACEPOINTS=m.
-
-Run, as root :
-modprobe tracepoint-sample (insmod order is not important)
-modprobe tracepoint-probe-sample
-cat /proc/tracepoint-sample (returns an expected error)
-rmmod tracepoint-sample tracepoint-probe-sample
-dmesg
diff --git a/Documentation/trace/uprobetracer.txt b/Documentation/trace/uprobetracer.txt
index 24ce6823a09e..d9c3e682312c 100644
--- a/Documentation/trace/uprobetracer.txt
+++ b/Documentation/trace/uprobetracer.txt
@@ -1,6 +1,8 @@
-                Uprobe-tracer: Uprobe-based Event Tracing
-                =========================================
-                 Documentation written by Srikar Dronamraju
+            Uprobe-tracer: Uprobe-based Event Tracing
+            =========================================
+
+           Documentation written by Srikar Dronamraju
+
 
 Overview
 --------
@@ -13,78 +15,94 @@ current_tracer. Instead of that, add probe points via
 /sys/kernel/debug/tracing/events/uprobes/<EVENT>/enabled.
 
 However unlike kprobe-event tracer, the uprobe event interface expects the
-user to calculate the offset of the probepoint in the object
+user to calculate the offset of the probepoint in the object.
 
 Synopsis of uprobe_tracer
 -------------------------
-  p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS]        : Set a probe
+  p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a uprobe
+  r[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a return uprobe (uretprobe)
+  -:[GRP/]EVENT                                  : Clear uprobe or uretprobe event
 
- GRP            : Group name. If omitted, use "uprobes" for it.
- EVENT          : Event name. If omitted, the event name is generated
-                  based on SYMBOL+offs.
- PATH           : path to an executable or a library.
- SYMBOL[+offs]  : Symbol+offset where the probe is inserted.
+  GRP           : Group name. If omitted, "uprobes" is the default value.
+  EVENT         : Event name. If omitted, the event name is generated based
+                  on SYMBOL+offs.
+  PATH          : Path to an executable or a library.
+  SYMBOL[+offs] : Symbol+offset where the probe is inserted.
 
- FETCHARGS      : Arguments. Each probe can have up to 128 args.
-  %REG          : Fetch register REG
+  FETCHARGS     : Arguments. Each probe can have up to 128 args.
+   %REG         : Fetch register REG
 
 Event Profiling
 ---------------
- You can check the total number of probe hits and probe miss-hits via
+You can check the total number of probe hits and probe miss-hits via
 /sys/kernel/debug/tracing/uprobe_profile.
- The first column is event name, the second is the number of probe hits,
+The first column is event name, the second is the number of probe hits,
 the third is the number of probe miss-hits.
 
 Usage examples
 --------------
-To add a probe as a new event, write a new definition to uprobe_events
-as below.
+ * Add a probe as a new uprobe event, write a new definition to uprobe_events
+as below: (sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash)
+
+    echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
+
+ * Add a probe as a new uretprobe event:
+
+    echo 'r: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
+
+ * Unset registered event:
 
-  echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
+    echo '-:bash_0x4245c0' >> /sys/kernel/debug/tracing/uprobe_events
 
- This sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash
+ * Print out the events that are registered:
 
-  echo > /sys/kernel/debug/tracing/uprobe_events
+    cat /sys/kernel/debug/tracing/uprobe_events
 
- This clears all probe points.
+ * Clear all events:
 
-The following example shows how to dump the instruction pointer and %ax
-a register at the probed text address.  Here we are trying to probe
-function zfree in /bin/zsh
+    echo > /sys/kernel/debug/tracing/uprobe_events
+
+Following example shows how to dump the instruction pointer and %ax register
+at the probed text address. Probe zfree function in /bin/zsh:
 
     # cd /sys/kernel/debug/tracing/
-    # cat /proc/`pgrep  zsh`/maps | grep /bin/zsh | grep r-xp
+    # cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp
     00400000-0048a000 r-xp 00000000 08:03 130904 /bin/zsh
     # objdump -T /bin/zsh | grep -w zfree
     0000000000446420 g    DF .text  0000000000000012  Base        zfree
 
-0x46420 is the offset of zfree in object /bin/zsh that is loaded at
-0x00400000. Hence the command to probe would be :
+  0x46420 is the offset of zfree in object /bin/zsh that is loaded at
+  0x00400000. Hence the command to uprobe would be:
+
+    # echo 'p:zfree_entry /bin/zsh:0x46420 %ip %ax' > uprobe_events
+
+  And the same for the uretprobe would be:
 
-    # echo 'p /bin/zsh:0x46420 %ip %ax' > uprobe_events
+    # echo 'r:zfree_exit /bin/zsh:0x46420 %ip %ax' >> uprobe_events
 
-Please note: User has to explicitly calculate the offset of the probepoint
+Please note: User has to explicitly calculate the offset of the probe-point
 in the object. We can see the events that are registered by looking at the
 uprobe_events file.
 
     # cat uprobe_events
-    p:uprobes/p_zsh_0x46420 /bin/zsh:0x00046420 arg1=%ip arg2=%ax
+    p:uprobes/zfree_entry /bin/zsh:0x00046420 arg1=%ip arg2=%ax
+    r:uprobes/zfree_exit /bin/zsh:0x00046420 arg1=%ip arg2=%ax
 
-The format of events can be seen by viewing the file events/uprobes/p_zsh_0x46420/format
+Format of events can be seen by viewing the file events/uprobes/zfree_entry/format
 
-    # cat events/uprobes/p_zsh_0x46420/format
-    name: p_zsh_0x46420
+    # cat events/uprobes/zfree_entry/format
+    name: zfree_entry
     ID: 922
     format:
-        field:unsigned short common_type;       offset:0;       size:2; signed:0;
-        field:unsigned char common_flags;       offset:2;       size:1; signed:0;
-        field:unsigned char common_preempt_count;       offset:3;       size:1; signed:0;
-        field:int common_pid;   offset:4;       size:4; signed:1;
-        field:int common_padding;       offset:8;       size:4; signed:1;
+         field:unsigned short common_type;         offset:0;  size:2; signed:0;
+         field:unsigned char common_flags;         offset:2;  size:1; signed:0;
+         field:unsigned char common_preempt_count; offset:3;  size:1; signed:0;
+         field:int common_pid;                     offset:4;  size:4; signed:1;
+         field:int common_padding;                 offset:8;  size:4; signed:1;
 
-        field:unsigned long __probe_ip; offset:12;      size:4; signed:0;
-        field:u32 arg1; offset:16;      size:4; signed:0;
-        field:u32 arg2; offset:20;      size:4; signed:0;
+         field:unsigned long __probe_ip;           offset:12; size:4; signed:0;
+         field:u32 arg1;                           offset:16; size:4; signed:0;
+         field:u32 arg2;                           offset:20; size:4; signed:0;
 
     print fmt: "(%lx) arg1=%lx arg2=%lx", REC->__probe_ip, REC->arg1, REC->arg2
 
@@ -94,6 +112,7 @@ events, you need to enable it by:
     # echo 1 > events/uprobes/enable
 
 Lets disable the event after sleeping for some time.
+
     # sleep 20
     # echo 0 > events/uprobes/enable
 
@@ -104,10 +123,11 @@ And you can see the traced information via /sys/kernel/debug/tracing/trace.
     #
     #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
     #              | |       |          |         |
-                 zsh-24842 [006] 258544.995456: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
-                 zsh-24842 [007] 258545.000270: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
-                 zsh-24842 [002] 258545.043929: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
-                 zsh-24842 [004] 258547.046129: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
-
-Each line shows us probes were triggered for a pid 24842 with ip being
-0x446421 and contents of ax register being 79.
+                 zsh-24842 [006] 258544.995456: zfree_entry: (0x446420) arg1=446420 arg2=79
+                 zsh-24842 [007] 258545.000270: zfree_exit:  (0x446540 <- 0x446420) arg1=446540 arg2=0
+                 zsh-24842 [002] 258545.043929: zfree_entry: (0x446420) arg1=446420 arg2=79
+                 zsh-24842 [004] 258547.046129: zfree_exit:  (0x446540 <- 0x446420) arg1=446540 arg2=0
+
+Output shows us uprobe was triggered for a pid 24842 with ip being 0x446420
+and contents of ax register being 79. And uretprobe was triggered with ip at
+0x446540 with counterpart function entry at 0x446420.
diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt
index 4204eb01fd38..1392b61d6ebe 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -33,6 +33,10 @@ built with CONFIG_USB_SUSPEND enabled (which depends on
 CONFIG_PM_RUNTIME).  System PM support is present only if the kernel
 was built with CONFIG_SUSPEND or CONFIG_HIBERNATION enabled.
 
+(Starting with the 3.10 kernel release, dynamic PM support for USB is
+present whenever the kernel was built with CONFIG_PM_RUNTIME enabled.
+The CONFIG_USB_SUSPEND option has been eliminated.)
+
 
         What is Remote Wakeup?
         ----------------------
@@ -206,10 +210,8 @@ initialized to 5.  (The idle-delay values for already existing devices
 will not be affected.)
 
 Setting the initial default idle-delay to -1 will prevent any
-autosuspend of any USB device.  This is a simple alternative to
-disabling CONFIG_USB_SUSPEND and rebuilding the kernel, and it has the
-added benefit of allowing you to enable autosuspend for selected
-devices.
+autosuspend of any USB device.  This has the benefit of allowing you
+then to enable autosuspend for selected devices.
 
 
         Warnings
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index 3f12865b2a88..e81864405102 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -76,7 +76,7 @@
  76 -> KWorld PlusTV 340U or UB435-Q (ATSC)     (em2870)        [1b80:a340]
  77 -> EM2874 Leadership ISDBT                  (em2874)
  78 -> PCTV nanoStick T2 290e                   (em28174)
- 79 -> Terratec Cinergy H5                      (em2884)        [0ccd:10a2,0ccd:10ad]
+ 79 -> Terratec Cinergy H5                      (em2884)        [0ccd:10a2,0ccd:10ad,0ccd:10b6]
  80 -> PCTV DVB-S2 Stick (460e)                 (em28174)
  81 -> Hauppauge WinTV HVR 930C                 (em2884)        [2040:1605]
  82 -> Terratec Cinergy HTC Stick               (em2884)        [0ccd:00b2]
@@ -85,3 +85,4 @@
  85 -> PCTV QuatroStick (510e)                  (em2884)        [2304:0242]
  86 -> PCTV QuatroStick nano (520e)             (em2884)        [2013:0251]
  87 -> Terratec Cinergy HTC USB XS              (em2884)        [0ccd:008e,0ccd:00ac]
+ 88 -> C3 Tech Digital Duo HDTV/SDTV USB        (em2884)        [1b80:e755]
diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner
index c83f6e418879..5b83a3ff15c2 100644
--- a/Documentation/video4linux/CARDLIST.tuner
+++ b/Documentation/video4linux/CARDLIST.tuner
@@ -86,3 +86,6 @@ tuner=85 - Philips FQ1236 MK5
 tuner=86 - Tena TNF5337 MFD
 tuner=87 - Xceive 4000 tuner
 tuner=88 - Xceive 5000C tuner
+tuner=89 - Sony PAL+SECAM (BTF-PG472Z)
+tuner=90 - Sony NTSC-M-JP (BTF-PK467Z)
+tuner=91 - Sony NTSC-M (BTF-PB463Z)
diff --git a/Documentation/video4linux/si476x.txt b/Documentation/video4linux/si476x.txt
new file mode 100644
index 000000000000..d1a08db2cbd9
--- /dev/null
+++ b/Documentation/video4linux/si476x.txt
@@ -0,0 +1,187 @@
+SI476x Driver Readme
+------------------------------------------------
+        Copyright (C) 2013 Andrey Smirnov <andrew.smirnov@gmail.com>
+
+TODO for the driver
+------------------------------
+
+- According to the SiLabs' datasheet it is possible to update the
+  firmware of the radio chip in the run-time, thus bringing it to the
+  most recent version. Unfortunately I couldn't find any mentioning of
+  the said firmware update for the old chips that I tested the driver
+  against, so for chips like that the driver only exposes the old
+  functionality.
+
+
+Parameters exposed over debugfs
+-------------------------------
+SI476x allow user to get multiple characteristics that can be very
+useful for EoL testing/RF performance estimation, parameters that have
+very little to do with V4L2 subsystem. Such parameters are exposed via
+debugfs and can be accessed via regular file I/O operations.
+
+The drivers exposes following files:
+
+* /sys/kernel/debug/<device-name>/acf
+  This file contains ACF(Automatically Controlled Features) status
+  information. The contents of the file is binary data of the
+  following layout:
+
+  Offset        | Name          | Description
+  ====================================================================
+  0x00          | blend_int     | Flag, set when stereo separation has
+                |               | crossed below the blend threshold
+  --------------------------------------------------------------------
+  0x01          | hblend_int    | Flag, set when HiBlend cutoff
+                |               | frequency is lower than threshold
+  --------------------------------------------------------------------
+  0x02          | hicut_int     | Flag, set when HiCut cutoff
+                |               | frequency is lower than threshold
+  --------------------------------------------------------------------
+  0x03          | chbw_int      | Flag, set when channel filter
+                |               | bandwidth is less than threshold
+  --------------------------------------------------------------------
+  0x04          | softmute_int  | Flag indicating that softmute
+                |               | attenuation has increased above
+                |               | softmute threshold
+  --------------------------------------------------------------------
+  0x05          | smute         | 0 - Audio is not soft muted
+                |               | 1 - Audio is soft muted
+  --------------------------------------------------------------------
+  0x06          | smattn        | Soft mute attenuation level in dB
+  --------------------------------------------------------------------
+  0x07          | chbw          | Channel filter bandwidth in kHz
+  --------------------------------------------------------------------
+  0x08          | hicut         | HiCut cutoff frequency in units of
+                |               | 100Hz
+  --------------------------------------------------------------------
+  0x09          | hiblend       | HiBlend cutoff frequency in units
+                |               | of 100 Hz
+  --------------------------------------------------------------------
+  0x10          | pilot         | 0 - Stereo pilot is not present
+                |               | 1 - Stereo pilot is present
+  --------------------------------------------------------------------
+  0x11          | stblend       | Stereo blend in %
+  --------------------------------------------------------------------
+
+
+* /sys/kernel/debug/<device-name>/rds_blckcnt
+  This file contains statistics about RDS receptions. It's binary data
+  has the following layout:
+
+  Offset        | Name          | Description
+  ====================================================================
+  0x00          | expected      | Number of expected RDS blocks
+  --------------------------------------------------------------------
+  0x02          | received      | Number of received RDS blocks
+  --------------------------------------------------------------------
+  0x04          | uncorrectable | Number of uncorrectable RDS blocks
+  --------------------------------------------------------------------
+
+* /sys/kernel/debug/<device-name>/agc
+  This file contains information about parameters pertaining to
+  AGC(Automatic Gain Control)
+
+  The layout is:
+  Offset        | Name          | Description
+  ====================================================================
+  0x00          | mxhi          | 0 - FM Mixer PD high threshold is
+                |               | not tripped
+                |               | 1 - FM Mixer PD high threshold is
+                |               | tripped
+  --------------------------------------------------------------------
+  0x01          | mxlo          | ditto for FM Mixer PD low
+  --------------------------------------------------------------------
+  0x02          | lnahi         | ditto for FM LNA PD high
+  --------------------------------------------------------------------
+  0x03          | lnalo         | ditto for FM LNA PD low
+  --------------------------------------------------------------------
+  0x04          | fmagc1        | FMAGC1 attenuator resistance
+                |               | (see datasheet for more detail)
+  --------------------------------------------------------------------
+  0x05          | fmagc2        | ditto for FMAGC2
+  --------------------------------------------------------------------
+  0x06          | pgagain       | PGA gain in dB
+  --------------------------------------------------------------------
+  0x07          | fmwblang      | FM/WB LNA Gain in dB
+  --------------------------------------------------------------------
+
+* /sys/kernel/debug/<device-name>/rsq
+  This file contains information about parameters pertaining to
+  RSQ(Received Signal Quality)
+
+  The layout is:
+  Offset        | Name          | Description
+  ====================================================================
+  0x00          | multhint      | 0 - multipath value has not crossed
+                |               | the Multipath high threshold
+                |               | 1 - multipath value has crossed
+                |               | the Multipath high threshold
+  --------------------------------------------------------------------
+  0x01          | multlint      | ditto for Multipath low threshold
+  --------------------------------------------------------------------
+  0x02          | snrhint       | 0 - received signal's SNR has not
+                |               | crossed high threshold
+                |               | 1 - received signal's SNR has
+                |               | crossed high threshold
+  --------------------------------------------------------------------
+  0x03          | snrlint       | ditto for low threshold
+  --------------------------------------------------------------------
+  0x04          | rssihint      | ditto for RSSI high threshold
+  --------------------------------------------------------------------
+  0x05          | rssilint      | ditto for RSSI low threshold
+  --------------------------------------------------------------------
+  0x06          | bltf          | Flag indicating if seek command
+                |               | reached/wrapped seek band limit
+  --------------------------------------------------------------------
+  0x07          | snr_ready     | Indicates that SNR metrics is ready
+  --------------------------------------------------------------------
+  0x08          | rssiready     | ditto for RSSI metrics
+  --------------------------------------------------------------------
+  0x09          | injside       | 0 - Low-side injection is being used
+                |               | 1 - High-side injection is used
+  --------------------------------------------------------------------
+  0x10          | afcrl         | Flag indicating if AFC rails
+  --------------------------------------------------------------------
+  0x11          | valid         | Flag indicating if channel is valid
+  --------------------------------------------------------------------
+  0x12          | readfreq      | Current tuned frequency
+  --------------------------------------------------------------------
+  0x14          | freqoff       | Singed frequency offset in units of
+                |               | 2ppm
+  --------------------------------------------------------------------
+  0x15          | rssi          | Signed value of RSSI in dBuV
+  --------------------------------------------------------------------
+  0x16          | snr           | Signed RF SNR in dB
+  --------------------------------------------------------------------
+  0x17          | issi          | Signed Image Strength Signal
+                |               | indicator
+  --------------------------------------------------------------------
+  0x18          | lassi         | Signed Low side adjacent Channel
+                |               | Strength indicator
+  --------------------------------------------------------------------
+  0x19          | hassi         | ditto fpr High side
+  --------------------------------------------------------------------
+  0x20          | mult          | Multipath indicator
+  --------------------------------------------------------------------
+  0x21          | dev           | Frequency deviation
+  --------------------------------------------------------------------
+  0x24          | assi          | Adjascent channel SSI
+  --------------------------------------------------------------------
+  0x25          | usn           | Ultrasonic noise indicator
+  --------------------------------------------------------------------
+  0x26          | pilotdev      | Pilot deviation in units of 100 Hz
+  --------------------------------------------------------------------
+  0x27          | rdsdev        | ditto for RDS
+  --------------------------------------------------------------------
+  0x28          | assidev       | ditto for ASSI
+  --------------------------------------------------------------------
+  0x29          | strongdev     | Frequency deviation
+  --------------------------------------------------------------------
+  0x30          | rdspi         | RDS PI code
+  --------------------------------------------------------------------
+
+* /sys/kernel/debug/<device-name>/rsq_primary
+  This file contains information about parameters pertaining to
+  RSQ(Received Signal Quality) for primary tuner only. Layout is as
+  the one above.
diff --git a/Documentation/virtual/00-INDEX b/Documentation/virtual/00-INDEX
index 924bd462675e..e952d30bbf0f 100644
--- a/Documentation/virtual/00-INDEX
+++ b/Documentation/virtual/00-INDEX
@@ -6,6 +6,3 @@ kvm/
         - Kernel Virtual Machine.  See also http://linux-kvm.org
 uml/
         - User Mode Linux, builds/runs Linux kernel as a userspace program.
-virtio.txt
-        - Text version of draft virtio spec.
-          See http://ozlabs.org/~rusty/virtio-spec
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 119358dfb742..5f91eda91647 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1486,15 +1486,23 @@ struct kvm_ioeventfd {
         __u8  pad[36];
 };
 
+For the special case of virtio-ccw devices on s390, the ioevent is matched
+to a subchannel/virtqueue tuple instead.
+
 The following flags are defined:
 
 #define KVM_IOEVENTFD_FLAG_DATAMATCH (1 << kvm_ioeventfd_flag_nr_datamatch)
 #define KVM_IOEVENTFD_FLAG_PIO       (1 << kvm_ioeventfd_flag_nr_pio)
 #define KVM_IOEVENTFD_FLAG_DEASSIGN  (1 << kvm_ioeventfd_flag_nr_deassign)
+#define KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY \
+        (1 << kvm_ioeventfd_flag_nr_virtio_ccw_notify)
 
 If datamatch flag is set, the event will be signaled only if the written value
 to the registered address is equal to datamatch in struct kvm_ioeventfd.
 
+For virtio-ccw devices, addr contains the subchannel id and datamatch the
+virtqueue index.
+
 
 4.60 KVM_DIRTY_TLB
 
@@ -1780,27 +1788,48 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_VPA_DTL   | 128
   PPC   | KVM_REG_PPC_EPCR      | 32
   PPC   | KVM_REG_PPC_EPR       | 32
+  PPC   | KVM_REG_PPC_TCR       | 32
+  PPC   | KVM_REG_PPC_TSR       | 32
+  PPC   | KVM_REG_PPC_OR_TSR    | 32
+  PPC   | KVM_REG_PPC_CLEAR_TSR | 32
+  PPC   | KVM_REG_PPC_MAS0      | 32
+  PPC   | KVM_REG_PPC_MAS1      | 32
+  PPC   | KVM_REG_PPC_MAS2      | 64
+  PPC   | KVM_REG_PPC_MAS7_3    | 64
+  PPC   | KVM_REG_PPC_MAS4      | 32
+  PPC   | KVM_REG_PPC_MAS6      | 32
+  PPC   | KVM_REG_PPC_MMUCFG    | 32
+  PPC   | KVM_REG_PPC_TLB0CFG   | 32
+  PPC   | KVM_REG_PPC_TLB1CFG   | 32
+  PPC   | KVM_REG_PPC_TLB2CFG   | 32
+  PPC   | KVM_REG_PPC_TLB3CFG   | 32
+  PPC   | KVM_REG_PPC_TLB0PS    | 32
+  PPC   | KVM_REG_PPC_TLB1PS    | 32
+  PPC   | KVM_REG_PPC_TLB2PS    | 32
+  PPC   | KVM_REG_PPC_TLB3PS    | 32
+  PPC   | KVM_REG_PPC_EPTCFG    | 32
+  PPC   | KVM_REG_PPC_ICP_STATE | 64
 
 ARM registers are mapped using the lower 32 bits.  The upper 16 of that
 is the register group type, or coprocessor number:
 
 ARM core registers have the following id bit patterns:
-  0x4002 0000 0010 <index into the kvm_regs struct:16>
+  0x4020 0000 0010 <index into the kvm_regs struct:16>
 
 ARM 32-bit CP15 registers have the following id bit patterns:
-  0x4002 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
+  0x4020 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
 
 ARM 64-bit CP15 registers have the following id bit patterns:
-  0x4003 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
+  0x4030 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
 
 ARM CCSIDR registers are demultiplexed by CSSELR value:
-  0x4002 0000 0011 00 <csselr:8>
+  0x4020 0000 0011 00 <csselr:8>
 
 ARM 32-bit VFP control registers have the following id bit patterns:
-  0x4002 0000 0012 1 <regno:12>
+  0x4020 0000 0012 1 <regno:12>
 
 ARM 64-bit FP registers have the following id bit patterns:
-  0x4002 0000 0012 0 <regno:12>
+  0x4030 0000 0012 0 <regno:12>
 
 4.69 KVM_GET_ONE_REG
 
@@ -2161,6 +2190,76 @@ header; first `n_valid' valid entries with contents from the data
 written, then `n_invalid' invalid entries, invalidating any previously
 valid entries found.
 
+4.79 KVM_CREATE_DEVICE
+
+Capability: KVM_CAP_DEVICE_CTRL
+Type: vm ioctl
+Parameters: struct kvm_create_device (in/out)
+Returns: 0 on success, -1 on error
+Errors:
+  ENODEV: The device type is unknown or unsupported
+  EEXIST: Device already created, and this type of device may not
+          be instantiated multiple times
+
+  Other error conditions may be defined by individual device types or
+  have their standard meanings.
+
+Creates an emulated device in the kernel.  The file descriptor returned
+in fd can be used with KVM_SET/GET/HAS_DEVICE_ATTR.
+
+If the KVM_CREATE_DEVICE_TEST flag is set, only test whether the
+device type is supported (not necessarily whether it can be created
+in the current vm).
+
+Individual devices should not define flags.  Attributes should be used
+for specifying any behavior that is not implied by the device type
+number.
+
+struct kvm_create_device {
+        __u32   type;   /* in: KVM_DEV_TYPE_xxx */
+        __u32   fd;     /* out: device handle */
+        __u32   flags;  /* in: KVM_CREATE_DEVICE_xxx */
+};
+
+4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
+
+Capability: KVM_CAP_DEVICE_CTRL
+Type: device ioctl
+Parameters: struct kvm_device_attr
+Returns: 0 on success, -1 on error
+Errors:
+  ENXIO:  The group or attribute is unknown/unsupported for this device
+  EPERM:  The attribute cannot (currently) be accessed this way
+          (e.g. read-only attribute, or attribute that only makes
+          sense when the device is in a different state)
+
+  Other error conditions may be defined by individual device types.
+
+Gets/sets a specified piece of device configuration and/or state.  The
+semantics are device-specific.  See individual device documentation in
+the "devices" directory.  As with ONE_REG, the size of the data
+transferred is defined by the particular attribute.
+
+struct kvm_device_attr {
+        __u32   flags;          /* no flags currently defined */
+        __u32   group;          /* device-defined */
+        __u64   attr;           /* group-defined */
+        __u64   addr;           /* userspace address of attr data */
+};
+
+4.81 KVM_HAS_DEVICE_ATTR
+
+Capability: KVM_CAP_DEVICE_CTRL
+Type: device ioctl
+Parameters: struct kvm_device_attr
+Returns: 0 on success, -1 on error
+Errors:
+  ENXIO:  The group or attribute is unknown/unsupported for this device
+
+Tests whether a device supports a particular attribute.  A successful
+return indicates the attribute is implemented.  It does not necessarily
+indicate that the attribute can be read or written in the device's
+current state.  "addr" is ignored.
 
 4.77 KVM_ARM_VCPU_INIT
 
@@ -2243,6 +2342,25 @@ and distributor interface, the ioctl must be called after calling
 KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs.  Calling
 this ioctl twice for any of the base addresses will return -EEXIST.
 
+4.82 KVM_PPC_RTAS_DEFINE_TOKEN
+
+Capability: KVM_CAP_PPC_RTAS
+Architectures: ppc
+Type: vm ioctl
+Parameters: struct kvm_rtas_token_args
+Returns: 0 on success, -1 on error
+
+Defines a token value for a RTAS (Run Time Abstraction Services)
+service in order to allow it to be handled in the kernel.  The
+argument struct gives the name of the service, which must be the name
+of a service that has a kernel-side implementation.  If the token
+value is non-zero, it will be associated with that service, and
+subsequent RTAS calls by the guest specifying that token will be
+handled by the kernel.  If the token value is 0, then any token
+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.
+
 
 5. The kvm_run structure
 ------------------------
@@ -2646,3 +2764,19 @@ to receive the topmost interrupt vector.
 When disabled (args[0] == 0), behavior is as if this facility is unsupported.
 
 When this capability is enabled, KVM_EXIT_EPR can occur.
+
+6.6 KVM_CAP_IRQ_MPIC
+
+Architectures: ppc
+Parameters: args[0] is the MPIC device fd
+            args[1] is the MPIC CPU number for this vcpu
+
+This capability connects the vcpu to an in-kernel MPIC device.
+
+6.7 KVM_CAP_IRQ_XICS
+
+Architectures: ppc
+Parameters: args[0] is the XICS device fd
+            args[1] is the XICS CPU number (server ID) for this vcpu
+
+This capability connects the vcpu to an in-kernel XICS device.
diff --git a/Documentation/virtual/kvm/devices/README b/Documentation/virtual/kvm/devices/README
new file mode 100644
index 000000000000..34a69834124a
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/README
@@ -0,0 +1 @@
+This directory contains specific device bindings for KVM_CAP_DEVICE_CTRL.
diff --git a/Documentation/virtual/kvm/devices/mpic.txt b/Documentation/virtual/kvm/devices/mpic.txt
new file mode 100644
index 000000000000..8257397adc3c
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/mpic.txt
@@ -0,0 +1,53 @@
+MPIC interrupt controller
+=========================
+
+Device types supported:
+  KVM_DEV_TYPE_FSL_MPIC_20     Freescale MPIC v2.0
+  KVM_DEV_TYPE_FSL_MPIC_42     Freescale MPIC v4.2
+
+Only one MPIC instance, of any type, may be instantiated.  The created
+MPIC will act as the system interrupt controller, connecting to each
+vcpu's interrupt inputs.
+
+Groups:
+  KVM_DEV_MPIC_GRP_MISC
+  Attributes:
+    KVM_DEV_MPIC_BASE_ADDR (rw, 64-bit)
+      Base address of the 256 KiB MPIC register space.  Must be
+      naturally aligned.  A value of zero disables the mapping.
+      Reset value is zero.
+
+  KVM_DEV_MPIC_GRP_REGISTER (rw, 32-bit)
+    Access an MPIC register, as if the access were made from the guest.
+    "attr" is the byte offset into the MPIC register space.  Accesses
+    must be 4-byte aligned.
+
+    MSIs may be signaled by using this attribute group to write
+    to the relevant MSIIR.
+
+  KVM_DEV_MPIC_GRP_IRQ_ACTIVE (rw, 32-bit)
+    IRQ input line for each standard openpic source.  0 is inactive and 1
+    is active, regardless of interrupt sense.
+
+    For edge-triggered interrupts:  Writing 1 is considered an activating
+    edge, and writing 0 is ignored.  Reading returns 1 if a previously
+    signaled edge has not been acknowledged, and 0 otherwise.
+
+    "attr" is the IRQ number.  IRQ numbers for standard sources are the
+    byte offset of the relevant IVPR from EIVPR0, divided by 32.
+
+IRQ Routing:
+
+  The MPIC emulation supports IRQ routing. Only a single MPIC device can
+  be instantiated. Once that device has been created, it's available as
+  irqchip id 0.
+
+  This irqchip 0 has 256 interrupt pins, which expose the interrupts in
+  the main array of interrupt sources (a.k.a. "SRC" interrupts).
+
+  The numbering is the same as the MPIC device tree binding -- based on
+  the register offset from the beginning of the sources array, without
+  regard to any subdivisions in chip documentation such as "internal"
+  or "external" interrupts.
+
+  Access to non-SRC interrupts is not implemented through IRQ routing mechanisms.
diff --git a/Documentation/virtual/kvm/devices/xics.txt b/Documentation/virtual/kvm/devices/xics.txt
new file mode 100644
index 000000000000..42864935ac5d
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/xics.txt
@@ -0,0 +1,66 @@
+XICS interrupt controller
+
+Device type supported: KVM_DEV_TYPE_XICS
+
+Groups:
+  KVM_DEV_XICS_SOURCES
+  Attributes: One per interrupt source, indexed by the source number.
+
+This device emulates the XICS (eXternal Interrupt Controller
+Specification) defined in PAPR.  The XICS has a set of interrupt
+sources, each identified by a 20-bit source number, and a set of
+Interrupt Control Presentation (ICP) entities, also called "servers",
+each associated with a virtual CPU.
+
+The ICP entities are created by enabling the KVM_CAP_IRQ_ARCH
+capability for each vcpu, specifying KVM_CAP_IRQ_XICS in args[0] and
+the interrupt server number (i.e. the vcpu number from the XICS's
+point of view) in args[1] of the kvm_enable_cap struct.  Each ICP has
+64 bits of state which can be read and written using the
+KVM_GET_ONE_REG and KVM_SET_ONE_REG ioctls on the vcpu.  The 64 bit
+state word has the following bitfields, starting at the
+least-significant end of the word:
+
+* Unused, 16 bits
+
+* Pending interrupt priority, 8 bits
+  Zero is the highest priority, 255 means no interrupt is pending.
+
+* Pending IPI (inter-processor interrupt) priority, 8 bits
+  Zero is the highest priority, 255 means no IPI is pending.
+
+* Pending interrupt source number, 24 bits
+  Zero means no interrupt pending, 2 means an IPI is pending
+
+* Current processor priority, 8 bits
+  Zero is the highest priority, meaning no interrupts can be
+  delivered, and 255 is the lowest priority.
+
+Each source has 64 bits of state that can be read and written using
+the KVM_GET_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls, specifying the
+KVM_DEV_XICS_SOURCES attribute group, with the attribute number being
+the interrupt source number.  The 64 bit state word has the following
+bitfields, starting from the least-significant end of the word:
+
+* Destination (server number), 32 bits
+  This specifies where the interrupt should be sent, and is the
+  interrupt server number specified for the destination vcpu.
+
+* Priority, 8 bits
+  This is the priority specified for this interrupt source, where 0 is
+  the highest priority and 255 is the lowest.  An interrupt with a
+  priority of 255 will never be delivered.
+
+* Level sensitive flag, 1 bit
+  This bit is 1 for a level-sensitive interrupt source, or 0 for
+  edge-sensitive (or MSI).
+
+* Masked flag, 1 bit
+  This bit is set to 1 if the interrupt is masked (cannot be delivered
+  regardless of its priority), for example by the ibm,int-off RTAS
+  call, or 0 if it is not masked.
+
+* Pending flag, 1 bit
+  This bit is 1 if the source has a pending interrupt, otherwise 0.
+
+Only one XICS instance may be created per VM.
diff --git a/Documentation/virtual/virtio-spec.txt b/Documentation/virtual/virtio-spec.txt
deleted file mode 100644
index 0d6ec85481cb..000000000000
--- a/Documentation/virtual/virtio-spec.txt
+++ /dev/null
@@ -1,3210 +0,0 @@
-[Generated file: see http://ozlabs.org/~rusty/virtio-spec/]
-Virtio PCI Card Specification
-v0.9.5 DRAFT
--
-
-Rusty Russell <rusty@rustcorp.com.au> IBM Corporation (Editor)
-
-2012 May 7.
-
-Purpose and Description
-
-This document describes the specifications of the “virtio” family
-of PCI[LaTeX Command: nomenclature] devices. These are devices
-are found in virtual environments[LaTeX Command: nomenclature],
-yet by design they are not all that different from physical PCI
-devices, and this document treats them as such. This allows the
-guest to use standard PCI drivers and discovery mechanisms.
-
-The purpose of virtio and this specification is that virtual
-environments and guests should have a straightforward, efficient,
-standard and extensible mechanism for virtual devices, rather
-than boutique per-environment or per-OS mechanisms.
-
-  Straightforward: Virtio PCI devices use normal PCI mechanisms
-  of interrupts and DMA which should be familiar to any device
-  driver author. There is no exotic page-flipping or COW
-  mechanism: it's just a PCI device.[footnote:
-This lack of page-sharing implies that the implementation of the
-device (e.g. the hypervisor or host) needs full access to the
-guest memory. Communication with untrusted parties (i.e.
-inter-guest communication) requires copying.
-]
-
-  Efficient: Virtio PCI devices consist of rings of descriptors
-  for input and output, which are neatly separated to avoid cache
-  effects from both guest and device writing to the same cache
-  lines.
-
-  Standard: Virtio PCI makes no assumptions about the environment
-  in which it operates, beyond supporting PCI. In fact the virtio
-  devices specified in the appendices do not require PCI at all:
-  they have been implemented on non-PCI buses.[footnote:
-The Linux implementation further separates the PCI virtio code
-from the specific virtio drivers: these drivers are shared with
-the non-PCI implementations (currently lguest and S/390).
-]
-
-  Extensible: Virtio PCI devices contain feature bits which are
-  acknowledged by the guest operating system during device setup.
-  This allows forwards and backwards compatibility: the device
-  offers all the features it knows about, and the driver
-  acknowledges those it understands and wishes to use.
-
-  Virtqueues
-
-The mechanism for bulk data transport on virtio PCI devices is
-pretentiously called a virtqueue. Each device can have zero or
-more virtqueues: for example, the network device has one for
-transmit and one for receive.
-
-Each virtqueue occupies two or more physically-contiguous pages
-(defined, for the purposes of this specification, as 4096 bytes),
-and consists of three parts:
-
-
-+-------------------+-----------------------------------+-----------+
-| Descriptor Table  |   Available Ring     (padding)    | Used Ring |
-+-------------------+-----------------------------------+-----------+
-
-
-When the driver wants to send a buffer to the device, it fills in
-a slot in the descriptor table (or chains several together), and
-writes the descriptor index into the available ring. It then
-notifies the device. When the device has finished a buffer, it
-writes the descriptor into the used ring, and sends an interrupt.
-
-Specification
-
-  PCI Discovery
-
-Any PCI device with Vendor ID 0x1AF4, and Device ID 0x1000
-through 0x103F inclusive is a virtio device[footnote:
-The actual value within this range is ignored
-]. The device must also have a Revision ID of 0 to match this
-specification.
-
-The Subsystem Device ID indicates which virtio device is
-supported by the device. The Subsystem Vendor ID should reflect
-the PCI Vendor ID of the environment (it's currently only used
-for informational purposes by the guest).
-
-
-+----------------------+--------------------+---------------+
-| Subsystem Device ID  |   Virtio Device    | Specification |
-+----------------------+--------------------+---------------+
-+----------------------+--------------------+---------------+
-|          1           |   network card     |  Appendix C   |
-+----------------------+--------------------+---------------+
-|          2           |   block device     |  Appendix D   |
-+----------------------+--------------------+---------------+
-|          3           |      console       |  Appendix E   |
-+----------------------+--------------------+---------------+
-|          4           |  entropy source    |  Appendix F   |
-+----------------------+--------------------+---------------+
-|          5           | memory ballooning  |  Appendix G   |
-+----------------------+--------------------+---------------+
-|          6           |     ioMemory       |       -       |
-+----------------------+--------------------+---------------+
-|          7           |       rpmsg        |  Appendix H   |
-+----------------------+--------------------+---------------+
-|          8           |     SCSI host      |  Appendix I   |
-+----------------------+--------------------+---------------+
-|          9           |   9P transport     |       -       |
-+----------------------+--------------------+---------------+
-|         10           |   mac80211 wlan    |       -       |
-+----------------------+--------------------+---------------+
-
-
-  Device Configuration
-
-To configure the device, we use the first I/O region of the PCI
-device. This contains a virtio header followed by a
-device-specific region.
-
-There may be different widths of accesses to the I/O region; the “
-natural” access method for each field in the virtio header must
-be used (i.e. 32-bit accesses for 32-bit fields, etc), but the
-device-specific region can be accessed using any width accesses,
-and should obtain the same results.
-
-Note that this is possible because while the virtio header is PCI
-(i.e. little) endian, the device-specific region is encoded in
-the native endian of the guest (where such distinction is
-applicable).
-
-  Device Initialization Sequence<sub:Device-Initialization-Sequence>
-
-We start with an overview of device initialization, then expand
-on the details of the device and how each step is preformed.
-
-  Reset the device. This is not required on initial start up.
-
-  The ACKNOWLEDGE status bit is set: we have noticed the device.
-
-  The DRIVER status bit is set: we know how to drive the device.
-
-  Device-specific setup, including reading the Device Feature
-  Bits, discovery of virtqueues for the device, optional MSI-X
-  setup, and reading and possibly writing the virtio
-  configuration space.
-
-  The subset of Device Feature Bits understood by the driver is
-  written to the device.
-
-  The DRIVER_OK status bit is set.
-
-  The device can now be used (ie. buffers added to the
-  virtqueues)[footnote:
-Historically, drivers have used the device before steps 5 and 6.
-This is only allowed if the driver does not use any features
-which would alter this early use of the device.
-]
-
-If any of these steps go irrecoverably wrong, the guest should
-set the FAILED status bit to indicate that it has given up on the
-device (it can reset the device later to restart if desired).
-
-We now cover the fields required for general setup in detail.
-
-  Virtio Header
-
-The virtio header looks as follows:
-
-
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-| Bits       || 32                  | 32                  | 32       | 16     | 16      | 16      | 8       | 8      |
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-| Read/Write || R                   | R+W                 | R+W      | R      | R+W     | R+W     | R+W     | R      |
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-| Purpose    || Device              | Guest               | Queue    | Queue  | Queue   | Queue   | Device  | ISR    |
-|            || Features bits 0:31  | Features bits 0:31  | Address  | Size   | Select  | Notify  | Status  | Status |
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-
-
-If MSI-X is enabled for the device, two additional fields
-immediately follow this header:[footnote:
-ie. once you enable MSI-X on the device, the other fields move.
-If you turn it off again, they move back!
-]
-
-
-+------------++----------------+--------+
-| Bits       || 16             | 16     |
-              +----------------+--------+
-+------------++----------------+--------+
-| Read/Write || R+W            | R+W    |
-+------------++----------------+--------+
-| Purpose    || Configuration  | Queue  |
-| (MSI-X)    || Vector         | Vector |
-+------------++----------------+--------+
-
-
-Immediately following these general headers, there may be
-device-specific headers:
-
-
-+------------++--------------------+
-| Bits       || Device Specific    |
-              +--------------------+
-+------------++--------------------+
-| Read/Write || Device Specific    |
-+------------++--------------------+
-| Purpose    || Device Specific... |
-|            ||                    |
-+------------++--------------------+
-
-
-  Device Status
-
-The Device Status field is updated by the guest to indicate its
-progress. This provides a simple low-level diagnostic: it's most
-useful to imagine them hooked up to traffic lights on the console
-indicating the status of each device.
-
-The device can be reset by writing a 0 to this field, otherwise
-at least one bit should be set:
-
-  ACKNOWLEDGE (1) Indicates that the guest OS has found the
-  device and recognized it as a valid virtio device.
-
-  DRIVER (2) Indicates that the guest OS knows how to drive the
-  device. Under Linux, drivers can be loadable modules so there
-  may be a significant (or infinite) delay before setting this
-  bit.
-
-  DRIVER_OK (4) Indicates that the driver is set up and ready to
-  drive the device.
-
-  FAILED (128) Indicates that something went wrong in the guest,
-  and it has given up on the device. This could be an internal
-  error, or the driver didn't like the device for some reason, or
-  even a fatal error during device operation. The device must be
-  reset before attempting to re-initialize.
-
-  Feature Bits<sub:Feature-Bits>
-
-Thefirst configuration field indicates the features that the
-device supports. The bits are allocated as follows:
-
-  0 to 23 Feature bits for the specific device type
-
-  24 to 32 Feature bits reserved for extensions to the queue and
-  feature negotiation mechanisms
-
-For example, feature bit 0 for a network device (i.e. Subsystem
-Device ID 1) indicates that the device supports checksumming of
-packets.
-
-The feature bits are negotiated: the device lists all the
-features it understands in the Device Features field, and the
-guest writes the subset that it understands into the Guest
-Features field. The only way to renegotiate is to reset the
-device.
-
-In particular, new fields in the device configuration header are
-indicated by offering a feature bit, so the guest can check
-before accessing that part of the configuration space.
-
-This allows for forwards and backwards compatibility: if the
-device is enhanced with a new feature bit, older guests will not
-write that feature bit back to the Guest Features field and it
-can go into backwards compatibility mode. Similarly, if a guest
-is enhanced with a feature that the device doesn't support, it
-will not see that feature bit in the Device Features field and
-can go into backwards compatibility mode (or, for poor
-implementations, set the FAILED Device Status bit).
-
-  Configuration/Queue Vectors
-
-When MSI-X capability is present and enabled in the device
-(through standard PCI configuration space) 4 bytes at byte offset
-20 are used to map configuration change and queue interrupts to
-MSI-X vectors. In this case, the ISR Status field is unused, and
-device specific configuration starts at byte offset 24 in virtio
-header structure. When MSI-X capability is not enabled, device
-specific configuration starts at byte offset 20 in virtio header.
-
-Writing a valid MSI-X Table entry number, 0 to 0x7FF, to one of
-Configuration/Queue Vector registers, maps interrupts triggered
-by the configuration change/selected queue events respectively to
-the corresponding MSI-X vector. To disable interrupts for a
-specific event type, unmap it by writing a special NO_VECTOR
-value:
-
-/* Vector value used to disable MSI for queue */
-
-#define VIRTIO_MSI_NO_VECTOR            0xffff
-
-Reading these registers returns vector mapped to a given event,
-or NO_VECTOR if unmapped. All queue and configuration change
-events are unmapped by default.
-
-Note that mapping an event to vector might require allocating
-internal device resources, and might fail. Devices report such
-failures by returning the NO_VECTOR value when the relevant
-Vector field is read. After mapping an event to vector, the
-driver must verify success by reading the Vector field value: on
-success, the previously written value is returned, and on
-failure, NO_VECTOR is returned. If a mapping failure is detected,
-the driver can retry mapping with fewervectors, or disable MSI-X.
-
-  Virtqueue Configuration<sec:Virtqueue-Configuration>
-
-As a device can have zero or more virtqueues for bulk data
-transport (for example, the network driver has two), the driver
-needs to configure them as part of the device-specific
-configuration.
-
-This is done as follows, for each virtqueue a device has:
-
-  Write the virtqueue index (first queue is 0) to the Queue
-  Select field.
-
-  Read the virtqueue size from the Queue Size field, which is
-  always a power of 2. This controls how big the virtqueue is
-  (see below). If this field is 0, the virtqueue does not exist.
-
-  Allocate and zero virtqueue in contiguous physical memory, on a
-  4096 byte alignment. Write the physical address, divided by
-  4096 to the Queue Address field.[footnote:
-The 4096 is based on the x86 page size, but it's also large
-enough to ensure that the separate parts of the virtqueue are on
-separate cache lines.
-]
-
-  Optionally, if MSI-X capability is present and enabled on the
-  device, select a vector to use to request interrupts triggered
-  by virtqueue events. Write the MSI-X Table entry number
-  corresponding to this vector in Queue Vector field. Read the
-  Queue Vector field: on success, previously written value is
-  returned; on failure, NO_VECTOR value is returned.
-
-The Queue Size field controls the total number of bytes required
-for the virtqueue according to the following formula:
-
-#define ALIGN(x) (((x) + 4095) & ~4095)
-
-static inline unsigned vring_size(unsigned int qsz)
-
-{
-
-     return ALIGN(sizeof(struct vring_desc)*qsz + sizeof(u16)*(2
-+ qsz))
-
-          + ALIGN(sizeof(struct vring_used_elem)*qsz);
-
-}
-
-This currently wastes some space with padding, but also allows
-future extensions. The virtqueue layout structure looks like this
-(qsz is the Queue Size field, which is a variable, so this code
-won't compile):
-
-struct vring {
-
-    /* The actual descriptors (16 bytes each) */
-
-    struct vring_desc desc[qsz];
-
-
-
-    /* A ring of available descriptor heads with free-running
-index. */
-
-    struct vring_avail avail;
-
-
-
-    // Padding to the next 4096 boundary.
-
-    char pad[];
-
-
-
-    // A ring of used descriptor heads with free-running index.
-
-    struct vring_used used;
-
-};
-
-  A Note on Virtqueue Endianness
-
-Note that the endian of these fields and everything else in the
-virtqueue is the native endian of the guest, not little-endian as
-PCI normally is. This makes for simpler guest code, and it is
-assumed that the host already has to be deeply aware of the guest
-endian so such an “endian-aware” device is not a significant
-issue.
-
-  Descriptor Table
-
-The descriptor table refers to the buffers the guest is using for
-the device. The addresses are physical addresses, and the buffers
-can be chained via the next field. Each descriptor describes a
-buffer which is read-only or write-only, but a chain of
-descriptors can contain both read-only and write-only buffers.
-
-No descriptor chain may be more than 2^32 bytes long in total.struct vring_desc {
-
-    /* Address (guest-physical). */
-
-    u64 addr;
-
-    /* Length. */
-
-    u32 len;
-
-/* This marks a buffer as continuing via the next field. */
-
-#define VRING_DESC_F_NEXT   1
-
-/* This marks a buffer as write-only (otherwise read-only). */
-
-#define VRING_DESC_F_WRITE     2
-
-/* This means the buffer contains a list of buffer descriptors.
-*/
-
-#define VRING_DESC_F_INDIRECT   4
-
-    /* The flags as indicated above. */
-
-    u16 flags;
-
-    /* Next field if flags & NEXT */
-
-    u16 next;
-
-};
-
-The number of descriptors in the table is specified by the Queue
-Size field for this virtqueue.
-
-  <sub:Indirect-Descriptors>Indirect Descriptors
-
-Some devices benefit by concurrently dispatching a large number
-of large requests. The VIRTIO_RING_F_INDIRECT_DESC feature can be
-used to allow this (see [cha:Reserved-Feature-Bits]). To increase
-ring capacity it is possible to store a table of indirect
-descriptors anywhere in memory, and insert a descriptor in main
-virtqueue (with flags&INDIRECT on) that refers to memory buffer
-containing this indirect descriptor table; fields addr and len
-refer to the indirect table address and length in bytes,
-respectively. The indirect table layout structure looks like this
-(len is the length of the descriptor that refers to this table,
-which is a variable, so this code won't compile):
-
-struct indirect_descriptor_table {
-
-    /* The actual descriptors (16 bytes each) */
-
-    struct vring_desc desc[len / 16];
-
-};
-
-The first indirect descriptor is located at start of the indirect
-descriptor table (index 0), additional indirect descriptors are
-chained by next field. An indirect descriptor without next field
-(with flags&NEXT off) signals the end of the indirect descriptor
-table, and transfers control back to the main virtqueue. An
-indirect descriptor can not refer to another indirect descriptor
-table (flags&INDIRECT must be off). A single indirect descriptor
-table can include both read-only and write-only descriptors;
-write-only flag (flags&WRITE) in the descriptor that refers to it
-is ignored.
-
-  Available Ring
-
-The available ring refers to what descriptors we are offering the
-device: it refers to the head of a descriptor chain. The “flags”
-field is currently 0 or 1: 1 indicating that we do not need an
-interrupt when the device consumes a descriptor from the
-available ring. Alternatively, the guest can ask the device to
-delay interrupts until an entry with an index specified by the “
-used_event” field is written in the used ring (equivalently,
-until the idx field in the used ring will reach the value
-used_event + 1). The method employed by the device is controlled
-by the VIRTIO_RING_F_EVENT_IDX feature bit (see [cha:Reserved-Feature-Bits]
-). This interrupt suppression is merely an optimization; it may
-not suppress interrupts entirely.
-
-The “idx” field indicates where we would put the next descriptor
-entry (modulo the ring size). This starts at 0, and increases.
-
-struct vring_avail {
-
-#define VRING_AVAIL_F_NO_INTERRUPT      1
-
-   u16 flags;
-
-   u16 idx;
-
-   u16 ring[qsz]; /* qsz is the Queue Size field read from device
-*/
-
-   u16 used_event;
-
-};
-
-  Used Ring
-
-The used ring is where the device returns buffers once it is done
-with them. The flags field can be used by the device to hint that
-no notification is necessary when the guest adds to the available
-ring. Alternatively, the “avail_event” field can be used by the
-device to hint that no notification is necessary until an entry
-with an index specified by the “avail_event” is written in the
-available ring (equivalently, until the idx field in the
-available ring will reach the value avail_event + 1). The method
-employed by the device is controlled by the guest through the
-VIRTIO_RING_F_EVENT_IDX feature bit (see [cha:Reserved-Feature-Bits]
-). [footnote:
-These fields are kept here because this is the only part of the
-virtqueue written by the device
-].
-
-Each entry in the ring is a pair: the head entry of the
-descriptor chain describing the buffer (this matches an entry
-placed in the available ring by the guest earlier), and the total
-of bytes written into the buffer. The latter is extremely useful
-for guests using untrusted buffers: if you do not know exactly
-how much has been written by the device, you usually have to zero
-the buffer to ensure no data leakage occurs.
-
-/* u32 is used here for ids for padding reasons. */
-
-struct vring_used_elem {
-
-    /* Index of start of used descriptor chain. */
-
-    u32 id;
-
-    /* Total length of the descriptor chain which was used
-(written to) */
-
-    u32 len;
-
-};
-
-
-
-struct vring_used {
-
-#define VRING_USED_F_NO_NOTIFY  1
-
-    u16 flags;
-
-    u16 idx;
-
-    struct vring_used_elem ring[qsz];
-
-    u16 avail_event;
-
-};
-
-  Helpers for Managing Virtqueues
-
-The Linux Kernel Source code contains the definitions above and
-helper routines in a more usable form, in
-include/linux/virtio_ring.h. This was explicitly licensed by IBM
-and Red Hat under the (3-clause) BSD license so that it can be
-freely used by all other projects, and is reproduced (with slight
-variation to remove Linux assumptions) in Appendix A.
-
-  Device Operation<sec:Device-Operation>
-
-There are two parts to device operation: supplying new buffers to
-the device, and processing used buffers from the device. As an
-example, the virtio network device has two virtqueues: the
-transmit virtqueue and the receive virtqueue. The driver adds
-outgoing (read-only) packets to the transmit virtqueue, and then
-frees them after they are used. Similarly, incoming (write-only)
-buffers are added to the receive virtqueue, and processed after
-they are used.
-
-  Supplying Buffers to The Device
-
-Actual transfer of buffers from the guest OS to the device
-operates as follows:
-
-  Place the buffer(s) into free descriptor(s).
-
-  If there are no free descriptors, the guest may choose to
-    notify the device even if notifications are suppressed (to
-    reduce latency).[footnote:
-The Linux drivers do this only for read-only buffers: for
-write-only buffers, it is assumed that the driver is merely
-trying to keep the receive buffer ring full, and no notification
-of this expected condition is necessary.
-]
-
-  Place the id of the buffer in the next ring entry of the
-  available ring.
-
-  The steps (1) and (2) may be performed repeatedly if batching
-  is possible.
-
-  A memory barrier should be executed to ensure the device sees
-  the updated descriptor table and available ring before the next
-  step.
-
-  The available “idx” field should be increased by the number of
-  entries added to the available ring.
-
-  A memory barrier should be executed to ensure that we update
-  the idx field before checking for notification suppression.
-
-  If notifications are not suppressed, the device should be
-  notified of the new buffers.
-
-Note that the above code does not take precautions against the
-available ring buffer wrapping around: this is not possible since
-the ring buffer is the same size as the descriptor table, so step
-(1) will prevent such a condition.
-
-In addition, the maximum queue size is 32768 (it must be a power
-of 2 which fits in 16 bits), so the 16-bit “idx” value can always
-distinguish between a full and empty buffer.
-
-Here is a description of each stage in more detail.
-
-  Placing Buffers Into The Descriptor Table
-
-A buffer consists of zero or more read-only physically-contiguous
-elements followed by zero or more physically-contiguous
-write-only elements (it must have at least one element). This
-algorithm maps it into the descriptor table:
-
-  for each buffer element, b:
-
-  Get the next free descriptor table entry, d
-
-  Set d.addr to the physical address of the start of b
-
-  Set d.len to the length of b.
-
-  If b is write-only, set d.flags to VRING_DESC_F_WRITE,
-    otherwise 0.
-
-  If there is a buffer element after this:
-
-    Set d.next to the index of the next free descriptor element.
-
-    Set the VRING_DESC_F_NEXT bit in d.flags.
-
-In practice, the d.next fields are usually used to chain free
-descriptors, and a separate count kept to check there are enough
-free descriptors before beginning the mappings.
-
-  Updating The Available Ring
-
-The head of the buffer we mapped is the first d in the algorithm
-above. A naive implementation would do the following:
-
-avail->ring[avail->idx % qsz] = head;
-
-However, in general we can add many descriptors before we update
-the “idx” field (at which point they become visible to the
-device), so we keep a counter of how many we've added:
-
-avail->ring[(avail->idx + added++) % qsz] = head;
-
-  Updating The Index Field
-
-Once the idx field of the virtqueue is updated, the device will
-be able to access the descriptor entries we've created and the
-memory they refer to. This is why a memory barrier is generally
-used before the idx update, to ensure it sees the most up-to-date
-copy.
-
-The idx field always increments, and we let it wrap naturally at
-65536:
-
-avail->idx += added;
-
-  <sub:Notifying-The-Device>Notifying The Device
-
-Device notification occurs by writing the 16-bit virtqueue index
-of this virtqueue to the Queue Notify field of the virtio header
-in the first I/O region of the PCI device. This can be expensive,
-however, so the device can suppress such notifications if it
-doesn't need them. We have to be careful to expose the new idx
-value before checking the suppression flag: it's OK to notify
-gratuitously, but not to omit a required notification. So again,
-we use a memory barrier here before reading the flags or the
-avail_event field.
-
-If the VIRTIO_F_RING_EVENT_IDX feature is not negotiated, and if
-the VRING_USED_F_NOTIFY flag is not set, we go ahead and write to
-the PCI configuration space.
-
-If the VIRTIO_F_RING_EVENT_IDX feature is negotiated, we read the
-avail_event field in the available ring structure. If the
-available index crossed_the avail_event field value since the
-last notification, we go ahead and write to the PCI configuration
-space. The avail_event field wraps naturally at 65536 as well:
-
-(u16)(new_idx - avail_event - 1) < (u16)(new_idx - old_idx)
-
-  <sub:Receiving-Used-Buffers>Receiving Used Buffers From The
-  Device
-
-Once the device has used a buffer (read from or written to it, or
-parts of both, depending on the nature of the virtqueue and the
-device), it sends an interrupt, following an algorithm very
-similar to the algorithm used for the driver to send the device a
-buffer:
-
-  Write the head descriptor number to the next field in the used
-  ring.
-
-  Update the used ring idx.
-
-  Determine whether an interrupt is necessary:
-
-  If the VIRTIO_F_RING_EVENT_IDX feature is not negotiated: check
-    if f the VRING_AVAIL_F_NO_INTERRUPT flag is not set in avail-
-    >flags
-
-  If the VIRTIO_F_RING_EVENT_IDX feature is negotiated: check
-    whether the used index crossed the used_event field value
-    since the last update. The used_event field wraps naturally
-    at 65536 as well:(u16)(new_idx - used_event - 1) < (u16)(new_idx - old_idx)
-
-  If an interrupt is necessary:
-
-  If MSI-X capability is disabled:
-
-    Set the lower bit of the ISR Status field for the device.
-
-    Send the appropriate PCI interrupt for the device.
-
-  If MSI-X capability is enabled:
-
-    Request the appropriate MSI-X interrupt message for the
-      device, Queue Vector field sets the MSI-X Table entry
-      number.
-
-    If Queue Vector field value is NO_VECTOR, no interrupt
-      message is requested for this event.
-
-The guest interrupt handler should:
-
-  If MSI-X capability is disabled: read the ISR Status field,
-  which will reset it to zero. If the lower bit is zero, the
-  interrupt was not for this device. Otherwise, the guest driver
-  should look through the used rings of each virtqueue for the
-  device, to see if any progress has been made by the device
-  which requires servicing.
-
-  If MSI-X capability is enabled: look through the used rings of
-  each virtqueue mapped to the specific MSI-X vector for the
-  device, to see if any progress has been made by the device
-  which requires servicing.
-
-For each ring, guest should then disable interrupts by writing
-VRING_AVAIL_F_NO_INTERRUPT flag in avail structure, if required.
-It can then process used ring entries finally enabling interrupts
-by clearing the VRING_AVAIL_F_NO_INTERRUPT flag or updating the
-EVENT_IDX field in the available structure, Guest should then
-execute a memory barrier, and then recheck the ring empty
-condition. This is necessary to handle the case where, after the
-last check and before enabling interrupts, an interrupt has been
-suppressed by the device:
-
-vring_disable_interrupts(vq);
-
-for (;;) {
-
-    if (vq->last_seen_used != vring->used.idx) {
-
-                vring_enable_interrupts(vq);
-
-                mb();
-
-                if (vq->last_seen_used != vring->used.idx)
-
-                        break;
-
-    }
-
-    struct vring_used_elem *e =
-vring.used->ring[vq->last_seen_used%vsz];
-
-    process_buffer(e);
-
-    vq->last_seen_used++;
-
-}
-
-  Dealing With Configuration Changes<sub:Dealing-With-Configuration>
-
-Some virtio PCI devices can change the device configuration
-state, as reflected in the virtio header in the PCI configuration
-space. In this case:
-
-  If MSI-X capability is disabled: an interrupt is delivered and
-  the second highest bit is set in the ISR Status field to
-  indicate that the driver should re-examine the configuration
-  space.Note that a single interrupt can indicate both that one
-  or more virtqueue has been used and that the configuration
-  space has changed: even if the config bit is set, virtqueues
-  must be scanned.
-
-  If MSI-X capability is enabled: an interrupt message is
-  requested. The Configuration Vector field sets the MSI-X Table
-  entry number to use. If Configuration Vector field value is
-  NO_VECTOR, no interrupt message is requested for this event.
-
-Creating New Device Types
-
-Various considerations are necessary when creating a new device
-type:
-
-  How Many Virtqueues?
-
-It is possible that a very simple device will operate entirely
-through its configuration space, but most will need at least one
-virtqueue in which it will place requests. A device with both
-input and output (eg. console and network devices described here)
-need two queues: one which the driver fills with buffers to
-receive input, and one which the driver places buffers to
-transmit output.
-
-  What Configuration Space Layout?
-
-Configuration space is generally used for rarely-changing or
-initialization-time parameters. But it is a limited resource, so
-it might be better to use a virtqueue to update configuration
-information (the network device does this for filtering,
-otherwise the table in the config space could potentially be very
-large).
-
-Note that this space is generally the guest's native endian,
-rather than PCI's little-endian.
-
-  What Device Number?
-
-Currently device numbers are assigned quite freely: a simple
-request mail to the author of this document or the Linux
-virtualization mailing list[footnote:
-
-https://lists.linux-foundation.org/mailman/listinfo/virtualization
-] will be sufficient to secure a unique one.
-
-Meanwhile for experimental drivers, use 65535 and work backwards.
-
-  How many MSI-X vectors?
-
-Using the optional MSI-X capability devices can speed up
-interrupt processing by removing the need to read ISR Status
-register by guest driver (which might be an expensive operation),
-reducing interrupt sharing between devices and queues within the
-device, and handling interrupts from multiple CPUs. However, some
-systems impose a limit (which might be as low as 256) on the
-total number of MSI-X vectors that can be allocated to all
-devices. Devices and/or device drivers should take this into
-account, limiting the number of vectors used unless the device is
-expected to cause a high volume of interrupts. Devices can
-control the number of vectors used by limiting the MSI-X Table
-Size or not presenting MSI-X capability in PCI configuration
-space. Drivers can control this by mapping events to as small
-number of vectors as possible, or disabling MSI-X capability
-altogether.
-
-  Message Framing
-
-The descriptors used for a buffer should not effect the semantics
-of the message, except for the total length of the buffer. For
-example, a network buffer consists of a 10 byte header followed
-by the network packet. Whether this is presented in the ring
-descriptor chain as (say) a 10 byte buffer and a 1514 byte
-buffer, or a single 1524 byte buffer, or even three buffers,
-should have no effect.
-
-In particular, no implementation should use the descriptor
-boundaries to determine the size of any header in a request.[footnote:
-The current qemu device implementations mistakenly insist that
-the first descriptor cover the header in these cases exactly, so
-a cautious driver should arrange it so.
-]
-
-  Device Improvements
-
-Any change to configuration space, or new virtqueues, or
-behavioural changes, should be indicated by negotiation of a new
-feature bit. This establishes clarity[footnote:
-Even if it does mean documenting design or implementation
-mistakes!
-] and avoids future expansion problems.
-
-Clusters of functionality which are always implemented together
-can use a single bit, but if one feature makes sense without the
-others they should not be gratuitously grouped together to
-conserve feature bits. We can always extend the spec when the
-first person needs more than 24 feature bits for their device.
-
-[LaTeX Command: printnomenclature]
-
-Appendix A: virtio_ring.h
-
-#ifndef VIRTIO_RING_H
-
-#define VIRTIO_RING_H
-
-/* An interface for efficient virtio implementation.
-
- *
-
- * This header is BSD licensed so anyone can use the definitions
-
- * to implement compatible drivers/servers.
-
- *
-
- * Copyright 2007, 2009, IBM Corporation
-
- * Copyright 2011, Red Hat, Inc
-
- * All rights reserved.
-
- *
-
- * Redistribution and use in source and binary forms, with or
-without
-
- * modification, are permitted provided that the following
-conditions
-
- * are met:
-
- * 1. Redistributions of source code must retain the above
-copyright
-
- *    notice, this list of conditions and the following
-disclaimer.
-
- * 2. Redistributions in binary form must reproduce the above
-copyright
-
- *    notice, this list of conditions and the following
-disclaimer in the
-
- *    documentation and/or other materials provided with the
-distribution.
-
- * 3. Neither the name of IBM nor the names of its contributors
-
- *    may be used to endorse or promote products derived from
-this software
-
- *    without specific prior written permission.
-
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
-CONTRIBUTORS ``AS IS'' AND
-
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
-TO, THE
-
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
-PARTICULAR PURPOSE
-
- * ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR CONTRIBUTORS BE
-LIABLE
-
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-CONSEQUENTIAL
-
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-SUBSTITUTE GOODS
-
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-INTERRUPTION)
-
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
-CONTRACT, STRICT
-
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
-IN ANY WAY
-
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-POSSIBILITY OF
-
- * SUCH DAMAGE.
-
- */
-
-
-
-/* This marks a buffer as continuing via the next field. */
-
-#define VRING_DESC_F_NEXT       1
-
-/* This marks a buffer as write-only (otherwise read-only). */
-
-#define VRING_DESC_F_WRITE      2
-
-
-
-/* The Host uses this in used->flags to advise the Guest: don't
-kick me
-
- * when you add a buffer.  It's unreliable, so it's simply an
-
- * optimization.  Guest will still kick if it's out of buffers.
-*/
-
-#define VRING_USED_F_NO_NOTIFY  1
-
-/* The Guest uses this in avail->flags to advise the Host: don't
-
- * interrupt me when you consume a buffer.  It's unreliable, so
-it's
-
- * simply an optimization.  */
-
-#define VRING_AVAIL_F_NO_INTERRUPT      1
-
-
-
-/* Virtio ring descriptors: 16 bytes.
-
- * These can chain together via "next". */
-
-struct vring_desc {
-
-        /* Address (guest-physical). */
-
-        uint64_t addr;
-
-        /* Length. */
-
-        uint32_t len;
-
-        /* The flags as indicated above. */
-
-        uint16_t flags;
-
-        /* We chain unused descriptors via this, too */
-
-        uint16_t next;
-
-};
-
-
-
-struct vring_avail {
-
-        uint16_t flags;
-
-        uint16_t idx;
-
-        uint16_t ring[];
-
-        uint16_t used_event;
-
-};
-
-
-
-/* u32 is used here for ids for padding reasons. */
-
-struct vring_used_elem {
-
-        /* Index of start of used descriptor chain. */
-
-        uint32_t id;
-
-        /* Total length of the descriptor chain which was written
-to. */
-
-        uint32_t len;
-
-};
-
-
-
-struct vring_used {
-
-        uint16_t flags;
-
-        uint16_t idx;
-
-        struct vring_used_elem ring[];
-
-        uint16_t avail_event;
-
-};
-
-
-
-struct vring {
-
-        unsigned int num;
-
-
-
-        struct vring_desc *desc;
-
-        struct vring_avail *avail;
-
-        struct vring_used *used;
-
-};
-
-
-
-/* The standard layout for the ring is a continuous chunk of
-memory which
-
- * looks like this.  We assume num is a power of 2.
-
- *
-
- * struct vring {
-
- *      // The actual descriptors (16 bytes each)
-
- *      struct vring_desc desc[num];
-
- *
-
- *      // A ring of available descriptor heads with free-running
-index.
-
- *      __u16 avail_flags;
-
- *      __u16 avail_idx;
-
- *      __u16 available[num];
-
- *
-
- *      // Padding to the next align boundary.
-
- *      char pad[];
-
- *
-
- *      // A ring of used descriptor heads with free-running
-index.
-
- *      __u16 used_flags;
-
- *      __u16 EVENT_IDX;
-
- *      struct vring_used_elem used[num];
-
- * };
-
- * Note: for virtio PCI, align is 4096.
-
- */
-
-static inline void vring_init(struct vring *vr, unsigned int num,
-void *p,
-
-                              unsigned long align)
-
-{
-
-        vr->num = num;
-
-        vr->desc = p;
-
-        vr->avail = p + num*sizeof(struct vring_desc);
-
-        vr->used = (void *)(((unsigned long)&vr->avail->ring[num]
-
-                              + align-1)
-
-                            & ~(align - 1));
-
-}
-
-
-
-static inline unsigned vring_size(unsigned int num, unsigned long
-align)
-
-{
-
-        return ((sizeof(struct vring_desc)*num +
-sizeof(uint16_t)*(2+num)
-
-                 + align - 1) & ~(align - 1))
-
-                + sizeof(uint16_t)*3 + sizeof(struct
-vring_used_elem)*num;
-
-}
-
-
-
-static inline int vring_need_event(uint16_t event_idx, uint16_t
-new_idx, uint16_t old_idx)
-
-{
-
-         return (uint16_t)(new_idx - event_idx - 1) <
-(uint16_t)(new_idx - old_idx);
-
-}
-
-#endif /* VIRTIO_RING_H */
-
-<cha:Reserved-Feature-Bits>Appendix B: Reserved Feature Bits
-
-Currently there are five device-independent feature bits defined:
-
-  VIRTIO_F_NOTIFY_ON_EMPTY (24) Negotiating this feature
-  indicates that the driver wants an interrupt if the device runs
-  out of available descriptors on a virtqueue, even though
-  interrupts are suppressed using the VRING_AVAIL_F_NO_INTERRUPT
-  flag or the used_event field. An example of this is the
-  networking driver: it doesn't need to know every time a packet
-  is transmitted, but it does need to free the transmitted
-  packets a finite time after they are transmitted. It can avoid
-  using a timer if the device interrupts it when all the packets
-  are transmitted.
-
-  VIRTIO_F_RING_INDIRECT_DESC (28) Negotiating this feature
-  indicates that the driver can use descriptors with the
-  VRING_DESC_F_INDIRECT flag set, as described in [sub:Indirect-Descriptors]
-  .
-
-  VIRTIO_F_RING_EVENT_IDX(29) This feature enables the used_event
-  and the avail_event fields. If set, it indicates that the
-  device should ignore the flags field in the available ring
-  structure. Instead, the used_event field in this structure is
-  used by guest to suppress device interrupts. Further, the
-  driver should ignore the flags field in the used ring
-  structure. Instead, the avail_event field in this structure is
-  used by the device to suppress notifications. If unset, the
-  driver should ignore the used_event field; the device should
-  ignore the avail_event field; the flags field is used
-
-Appendix C: Network Device
-
-The virtio network device is a virtual ethernet card, and is the
-most complex of the devices supported so far by virtio. It has
-enhanced rapidly and demonstrates clearly how support for new
-features should be added to an existing device. Empty buffers are
-placed in one virtqueue for receiving packets, and outgoing
-packets are enqueued into another for transmission in that order.
-A third command queue is used to control advanced filtering
-features.
-
-  Configuration
-
-  Subsystem Device ID 1
-
-  Virtqueues 0:receiveq. 1:transmitq. 2:controlq[footnote:
-Only if VIRTIO_NET_F_CTRL_VQ set
-]
-
-  Feature bits
-
-  VIRTIO_NET_F_CSUM (0) Device handles packets with partial
-    checksum
-
-  VIRTIO_NET_F_GUEST_CSUM (1) Guest handles packets with partial
-    checksum
-
-  VIRTIO_NET_F_MAC (5) Device has given MAC address.
-
-  VIRTIO_NET_F_GSO (6) (Deprecated) device handles packets with
-    any GSO type.[footnote:
-It was supposed to indicate segmentation offload support, but
-upon further investigation it became clear that multiple bits
-were required.
-]
-
-  VIRTIO_NET_F_GUEST_TSO4 (7) Guest can receive TSOv4.
-
-  VIRTIO_NET_F_GUEST_TSO6 (8) Guest can receive TSOv6.
-
-  VIRTIO_NET_F_GUEST_ECN (9) Guest can receive TSO with ECN.
-
-  VIRTIO_NET_F_GUEST_UFO (10) Guest can receive UFO.
-
-  VIRTIO_NET_F_HOST_TSO4 (11) Device can receive TSOv4.
-
-  VIRTIO_NET_F_HOST_TSO6 (12) Device can receive TSOv6.
-
-  VIRTIO_NET_F_HOST_ECN (13) Device can receive TSO with ECN.
-
-  VIRTIO_NET_F_HOST_UFO (14) Device can receive UFO.
-
-  VIRTIO_NET_F_MRG_RXBUF (15) Guest can merge receive buffers.
-
-  VIRTIO_NET_F_STATUS (16) Configuration status field is
-    available.
-
-  VIRTIO_NET_F_CTRL_VQ (17) Control channel is available.
-
-  VIRTIO_NET_F_CTRL_RX (18) Control channel RX mode support.
-
-  VIRTIO_NET_F_CTRL_VLAN (19) Control channel VLAN filtering.
-
-  VIRTIO_NET_F_GUEST_ANNOUNCE(21) Guest can send gratuitous
-    packets.
-
-  Device configuration layout Two configuration fields are
-  currently defined. The mac address field always exists (though
-  is only valid if VIRTIO_NET_F_MAC is set), and the status field
-  only exists if VIRTIO_NET_F_STATUS is set. Two read-only bits
-  are currently defined for the status field:
-  VIRTIO_NET_S_LINK_UP and VIRTIO_NET_S_ANNOUNCE. #define VIRTIO_NET_S_LINK_UP  1
-
-#define VIRTIO_NET_S_ANNOUNCE   2
-
-
-
-struct virtio_net_config {
-
-    u8 mac[6];
-
-    u16 status;
-
-};
-
-  Device Initialization
-
-  The initialization routine should identify the receive and
-  transmission virtqueues.
-
-  If the VIRTIO_NET_F_MAC feature bit is set, the configuration
-  space “mac” entry indicates the “physical” address of the the
-  network card, otherwise a private MAC address should be
-  assigned. All guests are expected to negotiate this feature if
-  it is set.
-
-  If the VIRTIO_NET_F_CTRL_VQ feature bit is negotiated, identify
-  the control virtqueue.
-
-  If the VIRTIO_NET_F_STATUS feature bit is negotiated, the link
-  status can be read from the bottom bit of the “status” config
-  field. Otherwise, the link should be assumed active.
-
-  The receive virtqueue should be filled with receive buffers.
-  This is described in detail below in “Setting Up Receive
-  Buffers”.
-
-  A driver can indicate that it will generate checksumless
-  packets by negotating the VIRTIO_NET_F_CSUM feature. This “
-  checksum offload” is a common feature on modern network cards.
-
-  If that feature is negotiated[footnote:
-ie. VIRTIO_NET_F_HOST_TSO* and VIRTIO_NET_F_HOST_UFO are
-dependent on VIRTIO_NET_F_CSUM; a dvice which offers the offload
-features must offer the checksum feature, and a driver which
-accepts the offload features must accept the checksum feature.
-Similar logic applies to the VIRTIO_NET_F_GUEST_TSO4 features
-depending on VIRTIO_NET_F_GUEST_CSUM.
-], a driver can use TCP or UDP segmentation offload by
-  negotiating the VIRTIO_NET_F_HOST_TSO4 (IPv4 TCP),
-  VIRTIO_NET_F_HOST_TSO6 (IPv6 TCP) and VIRTIO_NET_F_HOST_UFO
-  (UDP fragmentation) features. It should not send TCP packets
-  requiring segmentation offload which have the Explicit
-  Congestion Notification bit set, unless the
-  VIRTIO_NET_F_HOST_ECN feature is negotiated.[footnote:
-This is a common restriction in real, older network cards.
-]
-
-  The converse features are also available: a driver can save the
-  virtual device some work by negotiating these features.[footnote:
-For example, a network packet transported between two guests on
-the same system may not require checksumming at all, nor
-segmentation, if both guests are amenable.
-] The VIRTIO_NET_F_GUEST_CSUM feature indicates that partially
-  checksummed packets can be received, and if it can do that then
-  the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6,
-  VIRTIO_NET_F_GUEST_UFO and VIRTIO_NET_F_GUEST_ECN are the input
-  equivalents of the features described above. See “Receiving
-  Packets” below.
-
-  Device Operation
-
-Packets are transmitted by placing them in the transmitq, and
-buffers for incoming packets are placed in the receiveq. In each
-case, the packet itself is preceeded by a header:
-
-struct virtio_net_hdr {
-
-#define VIRTIO_NET_HDR_F_NEEDS_CSUM    1
-
-        u8 flags;
-
-#define VIRTIO_NET_HDR_GSO_NONE        0
-
-#define VIRTIO_NET_HDR_GSO_TCPV4       1
-
-#define VIRTIO_NET_HDR_GSO_UDP           3
-
-#define VIRTIO_NET_HDR_GSO_TCPV6       4
-
-#define VIRTIO_NET_HDR_GSO_ECN      0x80
-
-        u8 gso_type;
-
-        u16 hdr_len;
-
-        u16 gso_size;
-
-        u16 csum_start;
-
-        u16 csum_offset;
-
-/* Only if VIRTIO_NET_F_MRG_RXBUF: */
-
-        u16 num_buffers
-
-};
-
-The controlq is used to control device features such as
-filtering.
-
-  Packet Transmission
-
-Transmitting a single packet is simple, but varies depending on
-the different features the driver negotiated.
-
-  If the driver negotiated VIRTIO_NET_F_CSUM, and the packet has
-  not been fully checksummed, then the virtio_net_hdr's fields
-  are set as follows. Otherwise, the packet must be fully
-  checksummed, and flags is zero.
-
-  flags has the VIRTIO_NET_HDR_F_NEEDS_CSUM set,
-
-  <ite:csum_start-is-set>csum_start is set to the offset within
-    the packet to begin checksumming, and
-
-  csum_offset indicates how many bytes after the csum_start the
-    new (16 bit ones' complement) checksum should be placed.[footnote:
-For example, consider a partially checksummed TCP (IPv4) packet.
-It will have a 14 byte ethernet header and 20 byte IP header
-followed by the TCP header (with the TCP checksum field 16 bytes
-into that header). csum_start will be 14+20 = 34 (the TCP
-checksum includes the header), and csum_offset will be 16. The
-value in the TCP checksum field should be initialized to the sum
-of the TCP pseudo header, so that replacing it by the ones'
-complement checksum of the TCP header and body will give the
-correct result.
-]
-
-  <enu:If-the-driver>If the driver negotiated
-  VIRTIO_NET_F_HOST_TSO4, TSO6 or UFO, and the packet requires
-  TCP segmentation or UDP fragmentation, then the “gso_type”
-  field is set to VIRTIO_NET_HDR_GSO_TCPV4, TCPV6 or UDP.
-  (Otherwise, it is set to VIRTIO_NET_HDR_GSO_NONE). In this
-  case, packets larger than 1514 bytes can be transmitted: the
-  metadata indicates how to replicate the packet header to cut it
-  into smaller packets. The other gso fields are set:
-
-  hdr_len is a hint to the device as to how much of the header
-    needs to be kept to copy into each packet, usually set to the
-    length of the headers, including the transport header.[footnote:
-Due to various bugs in implementations, this field is not useful
-as a guarantee of the transport header size.
-]
-
-  gso_size is the maximum size of each packet beyond that header
-    (ie. MSS).
-
-  If the driver negotiated the VIRTIO_NET_F_HOST_ECN feature, the
-    VIRTIO_NET_HDR_GSO_ECN bit may be set in “gso_type” as well,
-    indicating that the TCP packet has the ECN bit set.[footnote:
-This case is not handled by some older hardware, so is called out
-specifically in the protocol.
-]
-
-  If the driver negotiated the VIRTIO_NET_F_MRG_RXBUF feature,
-  the num_buffers field is set to zero.
-
-  The header and packet are added as one output buffer to the
-  transmitq, and the device is notified of the new entry (see [sub:Notifying-The-Device]
-  ).[footnote:
-Note that the header will be two bytes longer for the
-VIRTIO_NET_F_MRG_RXBUF case.
-]
-
-  Packet Transmission Interrupt
-
-Often a driver will suppress transmission interrupts using the
-VRING_AVAIL_F_NO_INTERRUPT flag (see [sub:Receiving-Used-Buffers]
-) and check for used packets in the transmit path of following
-packets. However, it will still receive interrupts if the
-VIRTIO_F_NOTIFY_ON_EMPTY feature is negotiated, indicating that
-the transmission queue is completely emptied.
-
-The normal behavior in this interrupt handler is to retrieve and
-new descriptors from the used ring and free the corresponding
-headers and packets.
-
-  Setting Up Receive Buffers
-
-It is generally a good idea to keep the receive virtqueue as
-fully populated as possible: if it runs out, network performance
-will suffer.
-
-If the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6 or
-VIRTIO_NET_F_GUEST_UFO features are used, the Guest will need to
-accept packets of up to 65550 bytes long (the maximum size of a
-TCP or UDP packet, plus the 14 byte ethernet header), otherwise
-1514 bytes. So unless VIRTIO_NET_F_MRG_RXBUF is negotiated, every
-buffer in the receive queue needs to be at least this length [footnote:
-Obviously each one can be split across multiple descriptor
-elements.
-].
-
-If VIRTIO_NET_F_MRG_RXBUF is negotiated, each buffer must be at
-least the size of the struct virtio_net_hdr.
-
-  Packet Receive Interrupt
-
-When a packet is copied into a buffer in the receiveq, the
-optimal path is to disable further interrupts for the receiveq
-(see [sub:Receiving-Used-Buffers]) and process packets until no
-more are found, then re-enable them.
-
-Processing packet involves:
-
-  If the driver negotiated the VIRTIO_NET_F_MRG_RXBUF feature,
-  then the “num_buffers” field indicates how many descriptors
-  this packet is spread over (including this one). This allows
-  receipt of large packets without having to allocate large
-  buffers. In this case, there will be at least “num_buffers” in
-  the used ring, and they should be chained together to form a
-  single packet. The other buffers will not begin with a struct
-  virtio_net_hdr.
-
-  If the VIRTIO_NET_F_MRG_RXBUF feature was not negotiated, or
-  the “num_buffers” field is one, then the entire packet will be
-  contained within this buffer, immediately following the struct
-  virtio_net_hdr.
-
-  If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
-  VIRTIO_NET_HDR_F_NEEDS_CSUM bit in the “flags” field may be
-  set: if so, the checksum on the packet is incomplete and the “
-  csum_start” and “csum_offset” fields indicate how to calculate
-  it (see [ite:csum_start-is-set]).
-
-  If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
-  negotiated, then the “gso_type” may be something other than
-  VIRTIO_NET_HDR_GSO_NONE, and the “gso_size” field indicates the
-  desired MSS (see [enu:If-the-driver]).
-
-  Control Virtqueue
-
-The driver uses the control virtqueue (if VIRTIO_NET_F_VTRL_VQ is
-negotiated) to send commands to manipulate various features of
-the device which would not easily map into the configuration
-space.
-
-All commands are of the following form:
-
-struct virtio_net_ctrl {
-
-        u8 class;
-
-        u8 command;
-
-        u8 command-specific-data[];
-
-        u8 ack;
-
-};
-
-
-
-/* ack values */
-
-#define VIRTIO_NET_OK     0
-
-#define VIRTIO_NET_ERR    1
-
-The class, command and command-specific-data are set by the
-driver, and the device sets the ack byte. There is little it can
-do except issue a diagnostic if the ack byte is not
-VIRTIO_NET_OK.
-
-  Packet Receive Filtering
-
-If the VIRTIO_NET_F_CTRL_RX feature is negotiated, the driver can
-send control commands for promiscuous mode, multicast receiving,
-and filtering of MAC addresses.
-
-Note that in general, these commands are best-effort: unwanted
-packets may still arrive.
-
-  Setting Promiscuous Mode
-
-#define VIRTIO_NET_CTRL_RX    0
-
- #define VIRTIO_NET_CTRL_RX_PROMISC      0
-
- #define VIRTIO_NET_CTRL_RX_ALLMULTI     1
-
-The class VIRTIO_NET_CTRL_RX has two commands:
-VIRTIO_NET_CTRL_RX_PROMISC turns promiscuous mode on and off, and
-VIRTIO_NET_CTRL_RX_ALLMULTI turns all-multicast receive on and
-off. The command-specific-data is one byte containing 0 (off) or
-1 (on).
-
-  Setting MAC Address Filtering
-
-struct virtio_net_ctrl_mac {
-
-        u32 entries;
-
-        u8 macs[entries][ETH_ALEN];
-
-};
-
-
-
-#define VIRTIO_NET_CTRL_MAC    1
-
- #define VIRTIO_NET_CTRL_MAC_TABLE_SET        0
-
-The device can filter incoming packets by any number of
-destination MAC addresses.[footnote:
-Since there are no guarentees, it can use a hash filter
-orsilently switch to allmulti or promiscuous mode if it is given
-too many addresses.
-] This table is set using the class VIRTIO_NET_CTRL_MAC and the
-command VIRTIO_NET_CTRL_MAC_TABLE_SET. The command-specific-data
-is two variable length tables of 6-byte MAC addresses. The first
-table contains unicast addresses, and the second contains
-multicast addresses.
-
-  VLAN Filtering
-
-If the driver negotiates the VIRTION_NET_F_CTRL_VLAN feature, it
-can control a VLAN filter table in the device.
-
-#define VIRTIO_NET_CTRL_VLAN       2
-
- #define VIRTIO_NET_CTRL_VLAN_ADD             0
-
- #define VIRTIO_NET_CTRL_VLAN_DEL             1
-
-Both the VIRTIO_NET_CTRL_VLAN_ADD and VIRTIO_NET_CTRL_VLAN_DEL
-command take a 16-bit VLAN id as the command-specific-data.
-
-  Gratuitous Packet Sending
-
-If the driver negotiates the VIRTIO_NET_F_GUEST_ANNOUNCE (depends
-on VIRTIO_NET_F_CTRL_VQ), it can ask the guest to send gratuitous
-packets; this is usually done after the guest has been physically
-migrated, and needs to announce its presence on the new network
-links. (As hypervisor does not have the knowledge of guest
-network configuration (eg. tagged vlan) it is simplest to prod
-the guest in this way).
-
-#define VIRTIO_NET_CTRL_ANNOUNCE       3
-
- #define VIRTIO_NET_CTRL_ANNOUNCE_ACK             0
-
-The Guest needs to check VIRTIO_NET_S_ANNOUNCE bit in status
-field when it notices the changes of device configuration. The
-command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that
-driver has recevied the notification and device would clear the
-VIRTIO_NET_S_ANNOUNCE bit in the status filed after it received
-this command.
-
-Processing this notification involves:
-
-  Sending the gratuitous packets or marking there are pending
-  gratuitous packets to be sent and letting deferred routine to
-  send them.
-
-  Sending VIRTIO_NET_CTRL_ANNOUNCE_ACK command through control
-  vq.
-
-  .
-
-Appendix D: Block Device
-
-The virtio block device is a simple virtual block device (ie.
-disk). Read and write requests (and other exotic requests) are
-placed in the queue, and serviced (probably out of order) by the
-device except where noted.
-
-  Configuration
-
-  Subsystem Device ID 2
-
-  Virtqueues 0:requestq.
-
-  Feature bits
-
-  VIRTIO_BLK_F_BARRIER (0) Host supports request barriers.
-
-  VIRTIO_BLK_F_SIZE_MAX (1) Maximum size of any single segment is
-    in “size_max”.
-
-  VIRTIO_BLK_F_SEG_MAX (2) Maximum number of segments in a
-    request is in “seg_max”.
-
-  VIRTIO_BLK_F_GEOMETRY (4) Disk-style geometry specified in “
-    geometry”.
-
-  VIRTIO_BLK_F_RO (5) Device is read-only.
-
-  VIRTIO_BLK_F_BLK_SIZE (6) Block size of disk is in “blk_size”.
-
-  VIRTIO_BLK_F_SCSI (7) Device supports scsi packet commands.
-
-  VIRTIO_BLK_F_FLUSH (9) Cache flush command support.
-
-  Device configuration layout The capacity of the device
-  (expressed in 512-byte sectors) is always present. The
-  availability of the others all depend on various feature bits
-  as indicated above. struct virtio_blk_config {
-
-        u64 capacity;
-
-        u32 size_max;
-
-        u32 seg_max;
-
-        struct virtio_blk_geometry {
-
-                u16 cylinders;
-
-                u8 heads;
-
-                u8 sectors;
-
-        } geometry;
-
-        u32 blk_size;
-
-
-
-};
-
-  Device Initialization
-
-  The device size should be read from the “capacity”
-  configuration field. No requests should be submitted which goes
-  beyond this limit.
-
-  If the VIRTIO_BLK_F_BLK_SIZE feature is negotiated, the
-  blk_size field can be read to determine the optimal sector size
-  for the driver to use. This does not effect the units used in
-  the protocol (always 512 bytes), but awareness of the correct
-  value can effect performance.
-
-  If the VIRTIO_BLK_F_RO feature is set by the device, any write
-  requests will fail.
-
-  Device Operation
-
-The driver queues requests to the virtqueue, and they are used by
-the device (not necessarily in order). Each request is of form:
-
-struct virtio_blk_req {
-
-
-
-        u32 type;
-
-        u32 ioprio;
-
-        u64 sector;
-
-        char data[][512];
-
-        u8 status;
-
-};
-
-If the device has VIRTIO_BLK_F_SCSI feature, it can also support
-scsi packet command requests, each of these requests is of form:struct virtio_scsi_pc_req {
-
-        u32 type;
-
-        u32 ioprio;
-
-        u64 sector;
-
-    char cmd[];
-
-        char data[][512];
-
-#define SCSI_SENSE_BUFFERSIZE   96
-
-    u8 sense[SCSI_SENSE_BUFFERSIZE];
-
-    u32 errors;
-
-    u32 data_len;
-
-    u32 sense_len;
-
-    u32 residual;
-
-        u8 status;
-
-};
-
-The type of the request is either a read (VIRTIO_BLK_T_IN), a
-write (VIRTIO_BLK_T_OUT), a scsi packet command
-(VIRTIO_BLK_T_SCSI_CMD or VIRTIO_BLK_T_SCSI_CMD_OUT[footnote:
-the SCSI_CMD and SCSI_CMD_OUT types are equivalent, the device
-does not distinguish between them
-]) or a flush (VIRTIO_BLK_T_FLUSH or VIRTIO_BLK_T_FLUSH_OUT[footnote:
-the FLUSH and FLUSH_OUT types are equivalent, the device does not
-distinguish between them
-]). If the device has VIRTIO_BLK_F_BARRIER feature the high bit
-(VIRTIO_BLK_T_BARRIER) indicates that this request acts as a
-barrier and that all preceeding requests must be complete before
-this one, and all following requests must not be started until
-this is complete. Note that a barrier does not flush caches in
-the underlying backend device in host, and thus does not serve as
-data consistency guarantee. Driver must use FLUSH request to
-flush the host cache.
-
-#define VIRTIO_BLK_T_IN           0
-
-#define VIRTIO_BLK_T_OUT          1
-
-#define VIRTIO_BLK_T_SCSI_CMD     2
-
-#define VIRTIO_BLK_T_SCSI_CMD_OUT 3
-
-#define VIRTIO_BLK_T_FLUSH        4
-
-#define VIRTIO_BLK_T_FLUSH_OUT    5
-
-#define VIRTIO_BLK_T_BARRIER     0x80000000
-
-The ioprio field is a hint about the relative priorities of
-requests to the device: higher numbers indicate more important
-requests.
-
-The sector number indicates the offset (multiplied by 512) where
-the read or write is to occur. This field is unused and set to 0
-for scsi packet commands and for flush commands.
-
-The cmd field is only present for scsi packet command requests,
-and indicates the command to perform. This field must reside in a
-single, separate read-only buffer; command length can be derived
-from the length of this buffer.
-
-Note that these first three (four for scsi packet commands)
-fields are always read-only: the data field is either read-only
-or write-only, depending on the request. The size of the read or
-write can be derived from the total size of the request buffers.
-
-The sense field is only present for scsi packet command requests,
-and indicates the buffer for scsi sense data.
-
-The data_len field is only present for scsi packet command
-requests, this field is deprecated, and should be ignored by the
-driver. Historically, devices copied data length there.
-
-The sense_len field is only present for scsi packet command
-requests and indicates the number of bytes actually written to
-the sense buffer.
-
-The residual field is only present for scsi packet command
-requests and indicates the residual size, calculated as data
-length - number of bytes actually transferred.
-
-The final status byte is written by the device: either
-VIRTIO_BLK_S_OK for success, VIRTIO_BLK_S_IOERR for host or guest
-error or VIRTIO_BLK_S_UNSUPP for a request unsupported by host:#define VIRTIO_BLK_S_OK        0
-
-#define VIRTIO_BLK_S_IOERR     1
-
-#define VIRTIO_BLK_S_UNSUPP    2
-
-Historically, devices assumed that the fields type, ioprio and
-sector reside in a single, separate read-only buffer; the fields
-errors, data_len, sense_len and residual reside in a single,
-separate write-only buffer; the sense field in a separate
-write-only buffer of size 96 bytes, by itself; the fields errors,
-data_len, sense_len and residual in a single write-only buffer;
-and the status field is a separate read-only buffer of size 1
-byte, by itself.
-
-Appendix E: Console Device
-
-The virtio console device is a simple device for data input and
-output. A device may have one or more ports. Each port has a pair
-of input and output virtqueues. Moreover, a device has a pair of
-control IO virtqueues. The control virtqueues are used to
-communicate information between the device and the driver about
-ports being opened and closed on either side of the connection,
-indication from the host about whether a particular port is a
-console port, adding new ports, port hot-plug/unplug, etc., and
-indication from the guest about whether a port or a device was
-successfully added, port open/close, etc.. For data IO, one or
-more empty buffers are placed in the receive queue for incoming
-data and outgoing characters are placed in the transmit queue.
-
-  Configuration
-
-  Subsystem Device ID 3
-
-  Virtqueues 0:receiveq(port0). 1:transmitq(port0), 2:control
-  receiveq[footnote:
-Ports 2 onwards only if VIRTIO_CONSOLE_F_MULTIPORT is set
-], 3:control transmitq, 4:receiveq(port1), 5:transmitq(port1),
-  ...
-
-  Feature bits
-
-  VIRTIO_CONSOLE_F_SIZE (0) Configuration cols and rows fields
-    are valid.
-
-  VIRTIO_CONSOLE_F_MULTIPORT(1) Device has support for multiple
-    ports; configuration fields nr_ports and max_nr_ports are
-    valid and control virtqueues will be used.
-
-  Device configuration layout The size of the console is supplied
-  in the configuration space if the VIRTIO_CONSOLE_F_SIZE feature
-  is set. Furthermore, if the VIRTIO_CONSOLE_F_MULTIPORT feature
-  is set, the maximum number of ports supported by the device can
-  be fetched.struct virtio_console_config {
-
-        u16 cols;
-
-        u16 rows;
-
-
-
-        u32 max_nr_ports;
-
-};
-
-  Device Initialization
-
-  If the VIRTIO_CONSOLE_F_SIZE feature is negotiated, the driver
-  can read the console dimensions from the configuration fields.
-
-  If the VIRTIO_CONSOLE_F_MULTIPORT feature is negotiated, the
-  driver can spawn multiple ports, not all of which may be
-  attached to a console. Some could be generic ports. In this
-  case, the control virtqueues are enabled and according to the
-  max_nr_ports configuration-space value, the appropriate number
-  of virtqueues are created. A control message indicating the
-  driver is ready is sent to the host. The host can then send
-  control messages for adding new ports to the device. After
-  creating and initializing each port, a
-  VIRTIO_CONSOLE_PORT_READY control message is sent to the host
-  for that port so the host can let us know of any additional
-  configuration options set for that port.
-
-  The receiveq for each port is populated with one or more
-  receive buffers.
-
-  Device Operation
-
-  For output, a buffer containing the characters is placed in the
-  port's transmitq.[footnote:
-Because this is high importance and low bandwidth, the current
-Linux implementation polls for the buffer to be used, rather than
-waiting for an interrupt, simplifying the implementation
-significantly. However, for generic serial ports with the
-O_NONBLOCK flag set, the polling limitation is relaxed and the
-consumed buffers are freed upon the next write or poll call or
-when a port is closed or hot-unplugged.
-]
-
-  When a buffer is used in the receiveq (signalled by an
-  interrupt), the contents is the input to the port associated
-  with the virtqueue for which the notification was received.
-
-  If the driver negotiated the VIRTIO_CONSOLE_F_SIZE feature, a
-  configuration change interrupt may occur. The updated size can
-  be read from the configuration fields.
-
-  If the driver negotiated the VIRTIO_CONSOLE_F_MULTIPORT
-  feature, active ports are announced by the host using the
-  VIRTIO_CONSOLE_PORT_ADD control message. The same message is
-  used for port hot-plug as well.
-
-  If the host specified a port `name', a sysfs attribute is
-  created with the name filled in, so that udev rules can be
-  written that can create a symlink from the port's name to the
-  char device for port discovery by applications in the guest.
-
-  Changes to ports' state are effected by control messages.
-  Appropriate action is taken on the port indicated in the
-  control message. The layout of the structure of the control
-  buffer and the events associated are:struct virtio_console_control {
-
-        uint32_t id;    /* Port number */
-
-        uint16_t event; /* The kind of control event */
-
-        uint16_t value; /* Extra information for the event */
-
-};
-
-
-
-/* Some events for the internal messages (control packets) */
-
-
-
-#define VIRTIO_CONSOLE_DEVICE_READY     0
-
-#define VIRTIO_CONSOLE_PORT_ADD         1
-
-#define VIRTIO_CONSOLE_PORT_REMOVE      2
-
-#define VIRTIO_CONSOLE_PORT_READY       3
-
-#define VIRTIO_CONSOLE_CONSOLE_PORT     4
-
-#define VIRTIO_CONSOLE_RESIZE           5
-
-#define VIRTIO_CONSOLE_PORT_OPEN        6
-
-#define VIRTIO_CONSOLE_PORT_NAME        7
-
-Appendix F: Entropy Device
-
-The virtio entropy device supplies high-quality randomness for
-guest use.
-
-  Configuration
-
-  Subsystem Device ID 4
-
-  Virtqueues 0:requestq.
-
-  Feature bits None currently defined
-
-  Device configuration layout None currently defined.
-
-  Device Initialization
-
-  The virtqueue is initialized
-
-  Device Operation
-
-When the driver requires random bytes, it places the descriptor
-of one or more buffers in the queue. It will be completely filled
-by random data by the device.
-
-Appendix G: Memory Balloon Device
-
-The virtio memory balloon device is a primitive device for
-managing guest memory: the device asks for a certain amount of
-memory, and the guest supplies it (or withdraws it, if the device
-has more than it asks for). This allows the guest to adapt to
-changes in allowance of underlying physical memory. If the
-feature is negotiated, the device can also be used to communicate
-guest memory statistics to the host.
-
-  Configuration
-
-  Subsystem Device ID 5
-
-  Virtqueues 0:inflateq. 1:deflateq. 2:statsq.[footnote:
-Only if VIRTIO_BALLON_F_STATS_VQ set
-]
-
-  Feature bits
-
-  VIRTIO_BALLOON_F_MUST_TELL_HOST (0) Host must be told before
-    pages from the balloon are used.
-
-  VIRTIO_BALLOON_F_STATS_VQ (1) A virtqueue for reporting guest
-    memory statistics is present.
-
-  Device configuration layout Both fields of this configuration
-  are always available. Note that they are little endian, despite
-  convention that device fields are guest endian:struct virtio_balloon_config {
-
-        u32 num_pages;
-
-        u32 actual;
-
-};
-
-  Device Initialization
-
-  The inflate and deflate virtqueues are identified.
-
-  If the VIRTIO_BALLOON_F_STATS_VQ feature bit is negotiated:
-
-  Identify the stats virtqueue.
-
-  Add one empty buffer to the stats virtqueue and notify the
-    host.
-
-Device operation begins immediately.
-
-  Device Operation
-
-  Memory Ballooning The device is driven by the receipt of a
-  configuration change interrupt.
-
-  The “num_pages” configuration field is examined. If this is
-  greater than the “actual” number of pages, memory must be given
-  to the balloon. If it is less than the “actual” number of
-  pages, memory may be taken back from the balloon for general
-  use.
-
-  To supply memory to the balloon (aka. inflate):
-
-  The driver constructs an array of addresses of unused memory
-    pages. These addresses are divided by 4096[footnote:
-This is historical, and independent of the guest page size
-] and the descriptor describing the resulting 32-bit array is
-    added to the inflateq.
-
-  To remove memory from the balloon (aka. deflate):
-
-  The driver constructs an array of addresses of memory pages it
-    has previously given to the balloon, as described above. This
-    descriptor is added to the deflateq.
-
-  If the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is set, the
-    guest may not use these requested pages until that descriptor
-    in the deflateq has been used by the device.
-
-  Otherwise, the guest may begin to re-use pages previously given
-    to the balloon before the device has acknowledged their
-    withdrawl. [footnote:
-In this case, deflation advice is merely a courtesy
-]
-
-  In either case, once the device has completed the inflation or
-  deflation, the “actual” field of the configuration should be
-  updated to reflect the new number of pages in the balloon.[footnote:
-As updates to configuration space are not atomic, this field
-isn't particularly reliable, but can be used to diagnose buggy
-guests.
-]
-
-  Memory Statistics
-
-The stats virtqueue is atypical because communication is driven
-by the device (not the driver). The channel becomes active at
-driver initialization time when the driver adds an empty buffer
-and notifies the device. A request for memory statistics proceeds
-as follows:
-
-  The device pushes the buffer onto the used ring and sends an
-  interrupt.
-
-  The driver pops the used buffer and discards it.
-
-  The driver collects memory statistics and writes them into a
-  new buffer.
-
-  The driver adds the buffer to the virtqueue and notifies the
-  device.
-
-  The device pops the buffer (retaining it to initiate a
-  subsequent request) and consumes the statistics.
-
-  Memory Statistics Format Each statistic consists of a 16 bit
-  tag and a 64 bit value. Both quantities are represented in the
-  native endian of the guest. All statistics are optional and the
-  driver may choose which ones to supply. To guarantee backwards
-  compatibility, unsupported statistics should be omitted.
-
-  struct virtio_balloon_stat {
-
-#define VIRTIO_BALLOON_S_SWAP_IN  0
-
-#define VIRTIO_BALLOON_S_SWAP_OUT 1
-
-#define VIRTIO_BALLOON_S_MAJFLT   2
-
-#define VIRTIO_BALLOON_S_MINFLT   3
-
-#define VIRTIO_BALLOON_S_MEMFREE  4
-
-#define VIRTIO_BALLOON_S_MEMTOT   5
-
-        u16 tag;
-
-        u64 val;
-
-} __attribute__((packed));
-
-  Tags
-
-  VIRTIO_BALLOON_S_SWAP_IN The amount of memory that has been
-  swapped in (in bytes).
-
-  VIRTIO_BALLOON_S_SWAP_OUT The amount of memory that has been
-  swapped out to disk (in bytes).
-
-  VIRTIO_BALLOON_S_MAJFLT The number of major page faults that
-  have occurred.
-
-  VIRTIO_BALLOON_S_MINFLT The number of minor page faults that
-  have occurred.
-
-  VIRTIO_BALLOON_S_MEMFREE The amount of memory not being used
-  for any purpose (in bytes).
-
-  VIRTIO_BALLOON_S_MEMTOT The total amount of memory available
-  (in bytes).
-
-Appendix H: Rpmsg: Remote Processor Messaging
-
-Virtio rpmsg devices represent remote processors on the system
-which run in asymmetric multi-processing (AMP) configuration, and
-which are usually used to offload cpu-intensive tasks from the
-main application processor (a typical SoC methodology).
-
-Virtio is being used to communicate with those remote processors;
-empty buffers are placed in one virtqueue for receiving messages,
-and non-empty buffers, containing outbound messages, are enqueued
-in a second virtqueue for transmission.
-
-Numerous communication channels can be multiplexed over those two
-virtqueues, so different entities, running on the application and
-remote processor, can directly communicate in a point-to-point
-fashion.
-
-  Configuration
-
-  Subsystem Device ID 7
-
-  Virtqueues 0:receiveq. 1:transmitq.
-
-  Feature bits
-
-  VIRTIO_RPMSG_F_NS (0) Device sends (and capable of receiving)
-    name service messages announcing the creation (or
-    destruction) of a channel:/**
-
- * struct rpmsg_ns_msg - dynamic name service announcement
-message
-
- * @name: name of remote service that is published
-
- * @addr: address of remote service that is published
-
- * @flags: indicates whether service is created or destroyed
-
- *
-
- * This message is sent across to publish a new service (or
-announce
-
- * about its removal). When we receives these messages, an
-appropriate
-
- * rpmsg channel (i.e device) is created/destroyed.
-
- */
-
-struct rpmsg_ns_msgoon_config {
-
-        char name[RPMSG_NAME_SIZE];
-
-        u32 addr;
-
-        u32 flags;
-
-} __packed;
-
-
-
-/**
-
- * enum rpmsg_ns_flags - dynamic name service announcement flags
-
- *
-
- * @RPMSG_NS_CREATE: a new remote service was just created
-
- * @RPMSG_NS_DESTROY: a remote service was just destroyed
-
- */
-
-enum rpmsg_ns_flags {
-
-        RPMSG_NS_CREATE = 0,
-
-        RPMSG_NS_DESTROY = 1,
-
-};
-
-  Device configuration layout
-
-At his point none currently defined.
-
-  Device Initialization
-
-  The initialization routine should identify the receive and
-  transmission virtqueues.
-
-  The receive virtqueue should be filled with receive buffers.
-
-  Device Operation
-
-Messages are transmitted by placing them in the transmitq, and
-buffers for inbound messages are placed in the receiveq. In any
-case, messages are always preceded by the following header: /**
-
- * struct rpmsg_hdr - common header for all rpmsg messages
-
- * @src: source address
-
- * @dst: destination address
-
- * @reserved: reserved for future use
-
- * @len: length of payload (in bytes)
-
- * @flags: message flags
-
- * @data: @len bytes of message payload data
-
- *
-
- * Every message sent(/received) on the rpmsg bus begins with
-this header.
-
- */
-
-struct rpmsg_hdr {
-
-        u32 src;
-
-        u32 dst;
-
-        u32 reserved;
-
-        u16 len;
-
-        u16 flags;
-
-        u8 data[0];
-
-} __packed;
-
-Appendix I: SCSI Host Device
-
-The virtio SCSI host device groups together one or more virtual
-logical units (such as disks), and allows communicating to them
-using the SCSI protocol. An instance of the device represents a
-SCSI host to which many targets and LUNs are attached.
-
-The virtio SCSI device services two kinds of requests:
-
-  command requests for a logical unit;
-
-  task management functions related to a logical unit, target or
-  command.
-
-The device is also able to send out notifications about added and
-removed logical units. Together, these capabilities provide a
-SCSI transport protocol that uses virtqueues as the transfer
-medium. In the transport protocol, the virtio driver acts as the
-initiator, while the virtio SCSI host provides one or more
-targets that receive and process the requests.
-
-  Configuration
-
-  Subsystem Device ID 8
-
-  Virtqueues 0:controlq; 1:eventq; 2..n:request queues.
-
-  Feature bits
-
-  VIRTIO_SCSI_F_INOUT (0) A single request can include both
-    read-only and write-only data buffers.
-
-  VIRTIO_SCSI_F_HOTPLUG (1) The host should enable
-    hot-plug/hot-unplug of new LUNs and targets on the SCSI bus.
-
-  Device configuration layout All fields of this configuration
-  are always available. sense_size and cdb_size are writable by
-  the guest.struct virtio_scsi_config {
-
-    u32 num_queues;
-
-    u32 seg_max;
-
-    u32 max_sectors;
-
-    u32 cmd_per_lun;
-
-    u32 event_info_size;
-
-    u32 sense_size;
-
-    u32 cdb_size;
-
-    u16 max_channel;
-
-    u16 max_target;
-
-    u32 max_lun;
-
-};
-
-  num_queues is the total number of request virtqueues exposed by
-    the device. The driver is free to use only one request queue,
-    or it can use more to achieve better performance.
-
-  seg_max is the maximum number of segments that can be in a
-    command. A bidirectional command can include seg_max input
-    segments and seg_max output segments.
-
-  max_sectors is a hint to the guest about the maximum transfer
-    size it should use.
-
-  cmd_per_lun is a hint to the guest about the maximum number of
-    linked commands it should send to one LUN. The actual value
-    to be used is the minimum of cmd_per_lun and the virtqueue
-    size.
-
-  event_info_size is the maximum size that the device will fill
-    for buffers that the driver places in the eventq. The driver
-    should always put buffers at least of this size. It is
-    written by the device depending on the set of negotated
-    features.
-
-  sense_size is the maximum size of the sense data that the
-    device will write. The default value is written by the device
-    and will always be 96, but the driver can modify it. It is
-    restored to the default when the device is reset.
-
-  cdb_size is the maximum size of the CDB that the driver will
-    write. The default value is written by the device and will
-    always be 32, but the driver can likewise modify it. It is
-    restored to the default when the device is reset.
-
-  max_channel, max_target and max_lun can be used by the driver
-    as hints to constrain scanning the logical units on the
-    host.h
-
-  Device Initialization
-
-The initialization routine should first of all discover the
-device's virtqueues.
-
-If the driver uses the eventq, it should then place at least a
-buffer in the eventq.
-
-The driver can immediately issue requests (for example, INQUIRY
-or REPORT LUNS) or task management functions (for example, I_T
-RESET).
-
-  Device Operation: request queues
-
-The driver queues requests to an arbitrary request queue, and
-they are used by the device on that same queue. It is the
-responsibility of the driver to ensure strict request ordering
-for commands placed on different queues, because they will be
-consumed with no order constraints.
-
-Requests have the following format:
-
-struct virtio_scsi_req_cmd {
-
-    // Read-only
-
-    u8 lun[8];
-
-    u64 id;
-
-    u8 task_attr;
-
-    u8 prio;
-
-    u8 crn;
-
-    char cdb[cdb_size];
-
-    char dataout[];
-
-    // Write-only part
-
-    u32 sense_len;
-
-    u32 residual;
-
-    u16 status_qualifier;
-
-    u8 status;
-
-    u8 response;
-
-    u8 sense[sense_size];
-
-    char datain[];
-
-};
-
-
-
-/* command-specific response values */
-
-#define VIRTIO_SCSI_S_OK                0
-
-#define VIRTIO_SCSI_S_OVERRUN           1
-
-#define VIRTIO_SCSI_S_ABORTED           2
-
-#define VIRTIO_SCSI_S_BAD_TARGET        3
-
-#define VIRTIO_SCSI_S_RESET             4
-
-#define VIRTIO_SCSI_S_BUSY              5
-
-#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6
-
-#define VIRTIO_SCSI_S_TARGET_FAILURE    7
-
-#define VIRTIO_SCSI_S_NEXUS_FAILURE     8
-
-#define VIRTIO_SCSI_S_FAILURE           9
-
-
-
-/* task_attr */
-
-#define VIRTIO_SCSI_S_SIMPLE            0
-
-#define VIRTIO_SCSI_S_ORDERED           1
-
-#define VIRTIO_SCSI_S_HEAD              2
-
-#define VIRTIO_SCSI_S_ACA               3
-
-The lun field addresses a target and logical unit in the
-virtio-scsi device's SCSI domain. The only supported format for
-the LUN field is: first byte set to 1, second byte set to target,
-third and fourth byte representing a single level LUN structure,
-followed by four zero bytes. With this representation, a
-virtio-scsi device can serve up to 256 targets and 16384 LUNs per
-target.
-
-The id field is the command identifier (“tag”).
-
-task_attr, prio and crn should be left to zero. task_attr defines
-the task attribute as in the table above, but all task attributes
-may be mapped to SIMPLE by the device; crn may also be provided
-by clients, but is generally expected to be 0. The maximum CRN
-value defined by the protocol is 255, since CRN is stored in an
-8-bit integer.
-
-All of these fields are defined in SAM. They are always
-read-only, as are the cdb and dataout field. The cdb_size is
-taken from the configuration space.
-
-sense and subsequent fields are always write-only. The sense_len
-field indicates the number of bytes actually written to the sense
-buffer. The residual field indicates the residual size,
-calculated as “data_length - number_of_transferred_bytes”, for
-read or write operations. For bidirectional commands, the
-number_of_transferred_bytes includes both read and written bytes.
-A residual field that is less than the size of datain means that
-the dataout field was processed entirely. A residual field that
-exceeds the size of datain means that the dataout field was
-processed partially and the datain field was not processed at
-all.
-
-The status byte is written by the device to be the status code as
-defined in SAM.
-
-The response byte is written by the device to be one of the
-following:
-
-  VIRTIO_SCSI_S_OK when the request was completed and the status
-  byte is filled with a SCSI status code (not necessarily
-  "GOOD").
-
-  VIRTIO_SCSI_S_OVERRUN if the content of the CDB requires
-  transferring more data than is available in the data buffers.
-
-  VIRTIO_SCSI_S_ABORTED if the request was cancelled due to an
-  ABORT TASK or ABORT TASK SET task management function.
-
-  VIRTIO_SCSI_S_BAD_TARGET if the request was never processed
-  because the target indicated by the lun field does not exist.
-
-  VIRTIO_SCSI_S_RESET if the request was cancelled due to a bus
-  or device reset (including a task management function).
-
-  VIRTIO_SCSI_S_TRANSPORT_FAILURE if the request failed due to a
-  problem in the connection between the host and the target
-  (severed link).
-
-  VIRTIO_SCSI_S_TARGET_FAILURE if the target is suffering a
-  failure and the guest should not retry on other paths.
-
-  VIRTIO_SCSI_S_NEXUS_FAILURE if the nexus is suffering a failure
-  but retrying on other paths might yield a different result.
-
-  VIRTIO_SCSI_S_BUSY if the request failed but retrying on the
-  same path should work.
-
-  VIRTIO_SCSI_S_FAILURE for other host or guest error. In
-  particular, if neither dataout nor datain is empty, and the
-  VIRTIO_SCSI_F_INOUT feature has not been negotiated, the
-  request will be immediately returned with a response equal to
-  VIRTIO_SCSI_S_FAILURE.
-
-  Device Operation: controlq
-
-The controlq is used for other SCSI transport operations.
-Requests have the following format:
-
-struct virtio_scsi_ctrl {
-
-    u32 type;
-
-    ...
-
-    u8 response;
-
-};
-
-
-
-/* response values valid for all commands */
-
-#define VIRTIO_SCSI_S_OK                       0
-
-#define VIRTIO_SCSI_S_BAD_TARGET               3
-
-#define VIRTIO_SCSI_S_BUSY                     5
-
-#define VIRTIO_SCSI_S_TRANSPORT_FAILURE        6
-
-#define VIRTIO_SCSI_S_TARGET_FAILURE           7
-
-#define VIRTIO_SCSI_S_NEXUS_FAILURE            8
-
-#define VIRTIO_SCSI_S_FAILURE                  9
-
-#define VIRTIO_SCSI_S_INCORRECT_LUN            12
-
-The type identifies the remaining fields.
-
-The following commands are defined:
-
-  Task management function
-#define VIRTIO_SCSI_T_TMF                      0
-
-
-
-#define VIRTIO_SCSI_T_TMF_ABORT_TASK           0
-
-#define VIRTIO_SCSI_T_TMF_ABORT_TASK_SET       1
-
-#define VIRTIO_SCSI_T_TMF_CLEAR_ACA            2
-
-#define VIRTIO_SCSI_T_TMF_CLEAR_TASK_SET       3
-
-#define VIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET      4
-
-#define VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET   5
-
-#define VIRTIO_SCSI_T_TMF_QUERY_TASK           6
-
-#define VIRTIO_SCSI_T_TMF_QUERY_TASK_SET       7
-
-
-
-struct virtio_scsi_ctrl_tmf
-
-{
-
-    // Read-only part
-
-    u32 type;
-
-    u32 subtype;
-
-    u8 lun[8];
-
-    u64 id;
-
-    // Write-only part
-
-    u8 response;
-
-}
-
-
-
-/* command-specific response values */
-
-#define VIRTIO_SCSI_S_FUNCTION_COMPLETE        0
-
-#define VIRTIO_SCSI_S_FUNCTION_SUCCEEDED       10
-
-#define VIRTIO_SCSI_S_FUNCTION_REJECTED        11
-
-  The type is VIRTIO_SCSI_T_TMF; the subtype field defines. All
-  fields except response are filled by the driver. The subtype
-  field must always be specified and identifies the requested
-  task management function.
-
-  Other fields may be irrelevant for the requested TMF; if so,
-  they are ignored but they should still be present. The lun
-  field is in the same format specified for request queues; the
-  single level LUN is ignored when the task management function
-  addresses a whole I_T nexus. When relevant, the value of the id
-  field is matched against the id values passed on the requestq.
-
-  The outcome of the task management function is written by the
-  device in the response field. The command-specific response
-  values map 1-to-1 with those defined in SAM.
-
-  Asynchronous notification query
-#define VIRTIO_SCSI_T_AN_QUERY                    1
-
-
-
-struct virtio_scsi_ctrl_an {
-
-    // Read-only part
-
-    u32 type;
-
-    u8  lun[8];
-
-    u32 event_requested;
-
-    // Write-only part
-
-    u32 event_actual;
-
-    u8  response;
-
-}
-
-
-
-#define VIRTIO_SCSI_EVT_ASYNC_OPERATIONAL_CHANGE  2
-
-#define VIRTIO_SCSI_EVT_ASYNC_POWER_MGMT          4
-
-#define VIRTIO_SCSI_EVT_ASYNC_EXTERNAL_REQUEST    8
-
-#define VIRTIO_SCSI_EVT_ASYNC_MEDIA_CHANGE        16
-
-#define VIRTIO_SCSI_EVT_ASYNC_MULTI_HOST          32
-
-#define VIRTIO_SCSI_EVT_ASYNC_DEVICE_BUSY         64
-
-  By sending this command, the driver asks the device which
-  events the given LUN can report, as described in paragraphs 6.6
-  and A.6 of the SCSI MMC specification. The driver writes the
-  events it is interested in into the event_requested; the device
-  responds by writing the events that it supports into
-  event_actual.
-
-  The type is VIRTIO_SCSI_T_AN_QUERY. The lun and event_requested
-  fields are written by the driver. The event_actual and response
-  fields are written by the device.
-
-  No command-specific values are defined for the response byte.
-
-  Asynchronous notification subscription
-#define VIRTIO_SCSI_T_AN_SUBSCRIBE                2
-
-
-
-struct virtio_scsi_ctrl_an {
-
-    // Read-only part
-
-    u32 type;
-
-    u8  lun[8];
-
-    u32 event_requested;
-
-    // Write-only part
-
-    u32 event_actual;
-
-    u8  response;
-
-}
-
-  By sending this command, the driver asks the specified LUN to
-  report events for its physical interface, again as described in
-  the SCSI MMC specification. The driver writes the events it is
-  interested in into the event_requested; the device responds by
-  writing the events that it supports into event_actual.
-
-  Event types are the same as for the asynchronous notification
-  query message.
-
-  The type is VIRTIO_SCSI_T_AN_SUBSCRIBE. The lun and
-  event_requested fields are written by the driver. The
-  event_actual and response fields are written by the device.
-
-  No command-specific values are defined for the response byte.
-
-  Device Operation: eventq
-
-The eventq is used by the device to report information on logical
-units that are attached to it. The driver should always leave a
-few buffers ready in the eventq. In general, the device will not
-queue events to cope with an empty eventq, and will end up
-dropping events if it finds no buffer ready. However, when
-reporting events for many LUNs (e.g. when a whole target
-disappears), the device can throttle events to avoid dropping
-them. For this reason, placing 10-15 buffers on the event queue
-should be enough.
-
-Buffers are placed in the eventq and filled by the device when
-interesting events occur. The buffers should be strictly
-write-only (device-filled) and the size of the buffers should be
-at least the value given in the device's configuration
-information.
-
-Buffers returned by the device on the eventq will be referred to
-as "events" in the rest of this section. Events have the
-following format:
-
-#define VIRTIO_SCSI_T_EVENTS_MISSED   0x80000000
-
-
-
-struct virtio_scsi_event {
-
-    // Write-only part
-
-    u32 event;
-
-    ...
-
-}
-
-If bit 31 is set in the event field, the device failed to report
-an event due to missing buffers. In this case, the driver should
-poll the logical units for unit attention conditions, and/or do
-whatever form of bus scan is appropriate for the guest operating
-system.
-
-Other data that the device writes to the buffer depends on the
-contents of the event field. The following events are defined:
-
-  No event
-#define VIRTIO_SCSI_T_NO_EVENT         0
-
-  This event is fired in the following cases:
-
-  When the device detects in the eventq a buffer that is shorter
-    than what is indicated in the configuration field, it might
-    use it immediately and put this dummy value in the event
-    field. A well-written driver will never observe this
-    situation.
-
-  When events are dropped, the device may signal this event as
-    soon as the drivers makes a buffer available, in order to
-    request action from the driver. In this case, of course, this
-    event will be reported with the VIRTIO_SCSI_T_EVENTS_MISSED
-    flag.
-
-  Transport reset
-#define VIRTIO_SCSI_T_TRANSPORT_RESET  1
-
-
-
-struct virtio_scsi_event_reset {
-
-    // Write-only part
-
-    u32 event;
-
-    u8  lun[8];
-
-    u32 reason;
-
-}
-
-
-
-#define VIRTIO_SCSI_EVT_RESET_HARD         0
-
-#define VIRTIO_SCSI_EVT_RESET_RESCAN       1
-
-#define VIRTIO_SCSI_EVT_RESET_REMOVED      2
-
-  By sending this event, the device signals that a logical unit
-  on a target has been reset, including the case of a new device
-  appearing or disappearing on the bus.The device fills in all
-  fields. The event field is set to
-  VIRTIO_SCSI_T_TRANSPORT_RESET. The lun field addresses a
-  logical unit in the SCSI host.
-
-  The reason value is one of the three #define values appearing
-  above:
-
-  VIRTIO_SCSI_EVT_RESET_REMOVED (“LUN/target removed”) is used if
-    the target or logical unit is no longer able to receive
-    commands.
-
-  VIRTIO_SCSI_EVT_RESET_HARD (“LUN hard reset”) is used if the
-    logical unit has been reset, but is still present.
-
-  VIRTIO_SCSI_EVT_RESET_RESCAN (“rescan LUN/target”) is used if a
-    target or logical unit has just appeared on the device.
-
-  The “removed” and “rescan” events, when sent for LUN 0, may
-  apply to the entire target. After receiving them the driver
-  should ask the initiator to rescan the target, in order to
-  detect the case when an entire target has appeared or
-  disappeared. These two events will never be reported unless the
-  VIRTIO_SCSI_F_HOTPLUG feature was negotiated between the host
-  and the guest.
-
-  Events will also be reported via sense codes (this obviously
-  does not apply to newly appeared buses or targets, since the
-  application has never discovered them):
-
-  “LUN/target removed” maps to sense key ILLEGAL REQUEST, asc
-    0x25, ascq 0x00 (LOGICAL UNIT NOT SUPPORTED)
-
-  “LUN hard reset” maps to sense key UNIT ATTENTION, asc 0x29
-    (POWER ON, RESET OR BUS DEVICE RESET OCCURRED)
-
-  “rescan LUN/target” maps to sense key UNIT ATTENTION, asc 0x3f,
-    ascq 0x0e (REPORTED LUNS DATA HAS CHANGED)
-
-  The preferred way to detect transport reset is always to use
-  events, because sense codes are only seen by the driver when it
-  sends a SCSI command to the logical unit or target. However, in
-  case events are dropped, the initiator will still be able to
-  synchronize with the actual state of the controller if the
-  driver asks the initiator to rescan of the SCSI bus. During the
-  rescan, the initiator will be able to observe the above sense
-  codes, and it will process them as if it the driver had
-  received the equivalent event.
-
-  Asynchronous notification
-#define VIRTIO_SCSI_T_ASYNC_NOTIFY     2
-
-
-
-struct virtio_scsi_event_an {
-
-    // Write-only part
-
-    u32 event;
-
-    u8  lun[8];
-
-    u32 reason;
-
-}
-
-  By sending this event, the device signals that an asynchronous
-  event was fired from a physical interface.
-
-  All fields are written by the device. The event field is set to
-  VIRTIO_SCSI_T_ASYNC_NOTIFY. The lun field addresses a logical
-  unit in the SCSI host. The reason field is a subset of the
-  events that the driver has subscribed to via the "Asynchronous
-  notification subscription" command.
-
-  When dropped events are reported, the driver should poll for
-  asynchronous events manually using SCSI commands.
-
-Appendix X: virtio-mmio
-
-Virtual environments without PCI support (a common situation in
-embedded devices models) might use simple memory mapped device (“
-virtio-mmio”) instead of the PCI device.
-
-The memory mapped virtio device behaviour is based on the PCI
-device specification. Therefore most of operations like device
-initialization, queues configuration and buffer transfers are
-nearly identical. Existing differences are described in the
-following sections.
-
-  Device Initialization
-
-Instead of using the PCI IO space for virtio header, the “
-virtio-mmio” device provides a set of memory mapped control
-registers, all 32 bits wide, followed by device-specific
-configuration space. The following list presents their layout:
-
-  Offset from the device base address | Direction | Name
- Description
-
-  0x000 | R | MagicValue
- “virt” string.
-
-  0x004 | R | Version
- Device version number. Currently must be 1.
-
-  0x008 | R | DeviceID
- Virtio Subsystem Device ID (ie. 1 for network card).
-
-  0x00c | R | VendorID
- Virtio Subsystem Vendor ID.
-
-  0x010 | R | HostFeatures
- Flags representing features the device supports.
- Reading from this register returns 32 consecutive flag bits,
-  first bit depending on the last value written to
-  HostFeaturesSel register. Access to this register returns bits HostFeaturesSel*32
-
-   to (HostFeaturesSel*32)+31
-, eg. feature bits 0 to 31 if
-  HostFeaturesSel is set to 0 and features bits 32 to 63 if
-  HostFeaturesSel is set to 1. Also see [sub:Feature-Bits]
-
-  0x014 | W | HostFeaturesSel
- Device (Host) features word selection.
- Writing to this register selects a set of 32 device feature bits
-  accessible by reading from HostFeatures register. Device driver
-  must write a value to the HostFeaturesSel register before
-  reading from the HostFeatures register.
-
-  0x020 | W | GuestFeatures
- Flags representing device features understood and activated by
-  the driver.
- Writing to this register sets 32 consecutive flag bits, first
-  bit depending on the last value written to GuestFeaturesSel
-  register. Access to this register sets bits GuestFeaturesSel*32
-
-   to (GuestFeaturesSel*32)+31
-, eg. feature bits 0 to 31 if
-  GuestFeaturesSel is set to 0 and features bits 32 to 63 if
-  GuestFeaturesSel is set to 1. Also see [sub:Feature-Bits]
-
-  0x024 | W | GuestFeaturesSel
- Activated (Guest) features word selection.
- Writing to this register selects a set of 32 activated feature
-  bits accessible by writing to the GuestFeatures register.
-  Device driver must write a value to the GuestFeaturesSel
-  register before writing to the GuestFeatures register.
-
-  0x028 | W | GuestPageSize
- Guest page size.
- Device driver must write the guest page size in bytes to the
-  register during initialization, before any queues are used.
-  This value must be a power of 2 and is used by the Host to
-  calculate Guest address of the first queue page (see QueuePFN).
-
-  0x030 | W | QueueSel
- Virtual queue index (first queue is 0).
- Writing to this register selects the virtual queue that the
-  following operations on QueueNum, QueueAlign and QueuePFN apply
-  to.
-
-  0x034 | R | QueueNumMax
- Maximum virtual queue size.
- Reading from the register returns the maximum size of the queue
-  the Host is ready to process or zero (0x0) if the queue is not
-  available. This applies to the queue selected by writing to
-  QueueSel and is allowed only when QueuePFN is set to zero
-  (0x0), so when the queue is not actively used.
-
-  0x038 | W | QueueNum
- Virtual queue size.
- Queue size is a number of elements in the queue, therefore size
-  of the descriptor table and both available and used rings.
- Writing to this register notifies the Host what size of the
-  queue the Guest will use. This applies to the queue selected by
-  writing to QueueSel.
-
-  0x03c | W | QueueAlign
- Used Ring alignment in the virtual queue.
- Writing to this register notifies the Host about alignment
-  boundary of the Used Ring in bytes. This value must be a power
-  of 2 and applies to the queue selected by writing to QueueSel.
-
-  0x040 | RW | QueuePFN
- Guest physical page number of the virtual queue.
- Writing to this register notifies the host about location of the
-  virtual queue in the Guest's physical address space. This value
-  is the index number of a page starting with the queue
-  Descriptor Table. Value zero (0x0) means physical address zero
-  (0x00000000) and is illegal. When the Guest stops using the
-  queue it must write zero (0x0) to this register.
- Reading from this register returns the currently used page
-  number of the queue, therefore a value other than zero (0x0)
-  means that the queue is in use.
- Both read and write accesses apply to the queue selected by
-  writing to QueueSel.
-
-  0x050 | W | QueueNotify
- Queue notifier.
- Writing a queue index to this register notifies the Host that
-  there are new buffers to process in the queue.
-
-  0x60 | R | InterruptStatus
-Interrupt status.
-Reading from this register returns a bit mask of interrupts
-  asserted by the device. An interrupt is asserted if the
-  corresponding bit is set, ie. equals one (1).
-
-  Bit 0 | Used Ring Update
-This interrupt is asserted when the Host has updated the Used
-    Ring in at least one of the active virtual queues.
-
-  Bit 1 | Configuration change
-This interrupt is asserted when configuration of the device has
-    changed.
-
-  0x064 | W | InterruptACK
- Interrupt acknowledge.
- Writing to this register notifies the Host that the Guest
-  finished handling interrupts. Set bits in the value clear the
-  corresponding bits of the InterruptStatus register.
-
-  0x070 | RW | Status
- Device status.
- Reading from this register returns the current device status
-  flags.
- Writing non-zero values to this register sets the status flags,
-  indicating the Guest progress. Writing zero (0x0) to this
-  register triggers a device reset.
- Also see [sub:Device-Initialization-Sequence]
-
-  0x100+ | RW | Config
- Device-specific configuration space starts at an offset 0x100
-  and is accessed with byte alignment. Its meaning and size
-  depends on the device and the driver.
-
-Virtual queue size is a number of elements in the queue,
-therefore size of the descriptor table and both available and
-used rings.
-
-The endianness of the registers follows the native endianness of
-the Guest. Writing to registers described as “R” and reading from
-registers described as “W” is not permitted and can cause
-undefined behavior.
-
-The device initialization is performed as described in [sub:Device-Initialization-Sequence]
- with one exception: the Guest must notify the Host about its
-page size, writing the size in bytes to GuestPageSize register
-before the initialization is finished.
-
-The memory mapped virtio devices generate single interrupt only,
-therefore no special configuration is required.
-
-  Virtqueue Configuration
-
-The virtual queue configuration is performed in a similar way to
-the one described in [sec:Virtqueue-Configuration] with a few
-additional operations:
-
-  Select the queue writing its index (first queue is 0) to the
-  QueueSel register.
-
-  Check if the queue is not already in use: read QueuePFN
-  register, returned value should be zero (0x0).
-
-  Read maximum queue size (number of elements) from the
-  QueueNumMax register. If the returned value is zero (0x0) the
-  queue is not available.
-
-  Allocate and zero the queue pages in contiguous virtual memory,
-  aligning the Used Ring to an optimal boundary (usually page
-  size). Size of the allocated queue may be smaller than or equal
-  to the maximum size returned by the Host.
-
-  Notify the Host about the queue size by writing the size to
-  QueueNum register.
-
-  Notify the Host about the used alignment by writing its value
-  in bytes to QueueAlign register.
-
-  Write the physical number of the first page of the queue to the
-  QueuePFN register.
-
-The queue and the device are ready to begin normal operations
-now.
-
-  Device Operation
-
-The memory mapped virtio device behaves in the same way as
-described in [sec:Device-Operation], with the following
-exceptions:
-
-  The device is notified about new buffers available in a queue
-  by writing the queue index to register QueueNum instead of the
-  virtio header in PCI I/O space ([sub:Notifying-The-Device]).
-
-  The memory mapped virtio device is using single, dedicated
-  interrupt signal, which is raised when at least one of the
-  interrupts described in the InterruptStatus register
-  description is asserted. After receiving an interrupt, the
-  driver must read the InterruptStatus register to check what
-  caused the interrupt (see the register description). After the
-  interrupt is handled, the driver must acknowledge it by writing
-  a bit mask corresponding to the serviced interrupt to the
-  InterruptACK register.
-
diff --git a/Documentation/vm/overcommit-accounting b/Documentation/vm/overcommit-accounting
index 706d7ed9d8d2..8eaa2fc4b8fa 100644
--- a/Documentation/vm/overcommit-accounting
+++ b/Documentation/vm/overcommit-accounting
@@ -8,7 +8,9 @@ The Linux kernel supports the following overcommit handling modes
                 default.
 
 1       -       Always overcommit. Appropriate for some scientific
-                applications.
+                applications. Classic example is code using sparse arrays
+                and just relying on the virtual memory consisting almost
+                entirely of zero pages.
 
 2       -       Don't overcommit. The total address space commit
                 for the system is not permitted to exceed swap + a
@@ -18,6 +20,10 @@ The Linux kernel supports the following overcommit handling modes
                 pages but will receive errors on memory allocation as
                 appropriate.
 
+                Useful for applications that want to guarantee their
+                memory allocations will be available in the future
+                without having to initialize every page.
+
 The overcommit policy is set via the sysctl `vm.overcommit_memory'.
 
 The overcommit percentage is set via `vm.overcommit_ratio'.
diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt
index e015a83c3996..e9e8ddbbf376 100644
--- a/Documentation/x86/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt
@@ -91,20 +91,6 @@ APICs
                  apicmaintimer. Useful when your PIT timer is totally
                  broken.
 
-Early Console
-
-   syntax: earlyprintk=vga
-           earlyprintk=serial[,ttySn[,baudrate]]
-
-   The early console is useful when the kernel crashes before the
-   normal console is initialized. It is not enabled by
-   default because it has some cosmetic problems.
-   Append ,keep to not disable it when the real console takes over.
-   Only vga or serial at a time, not both.
-   Currently only ttyS0 and ttyS1 are supported.
-   Interaction with the standard serial driver is not very good.
-   The VGA output is eventually overwritten by the real console.
-
 Timing
 
   notsc
diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index d6498e3cd713..881582f75c9c 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -13,7 +13,9 @@ ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
 ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
 ... unused hole ...
 ffffffff80000000 - ffffffffa0000000 (=512 MB)  kernel text mapping, from phys 0
-ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space
+ffffffffa0000000 - ffffffffff5fffff (=1525 MB) module mapping space
+ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
+ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
 
 The direct mapping covers all memory in the system up to the highest
 memory address (this means in some cases it can also include PCI memory