285 files changed, 20359 insertions, 3224 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 2214f123a976..49c051380daf 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -218,8 +218,6 @@ m68k/
         - directory with info about Linux on Motorola 68k architecture.
 magic-number.txt
         - list of magic numbers used to mark/protect kernel data structures.
-mca.txt
-        - info on supporting Micro Channel Architecture (e.g. PS/2) systems.
 md.txt
         - info on boot arguments for the multiple devices driver.
 memory-barriers.txt
diff --git a/Documentation/ABI/removed/ip_queue b/Documentation/ABI/removed/ip_queue
new file mode 100644
index 000000000000..3243613bc2d2
--- /dev/null
+++ b/Documentation/ABI/removed/ip_queue
@@ -0,0 +1,9 @@
+What:           ip_queue
+Date:           finally removed in kernel v3.5.0
+Contact:        Pablo Neira Ayuso <pablo@netfilter.org>
+Description:
+        ip_queue has been replaced by nfnetlink_queue which provides
+        more advanced queueing mechanism to user-space. The ip_queue
+        module was already announced to become obsolete years ago.
+
+Users:
diff --git a/Documentation/ABI/testing/debugfs-pfo-nx-crypto b/Documentation/ABI/testing/debugfs-pfo-nx-crypto
new file mode 100644
index 000000000000..685d5a448423
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-pfo-nx-crypto
@@ -0,0 +1,45 @@
+What:           /sys/kernel/debug/nx-crypto/*
+Date:           March 2012
+KernelVersion:  3.4
+Contact:        Kent Yoder <key@linux.vnet.ibm.com>
+Description:
+
+  These debugfs interfaces are built by the nx-crypto driver, built in
+arch/powerpc/crypto/nx.
+
+Error Detection
+===============
+
+errors:
+- A u32 providing a total count of errors since the driver was loaded. The
+only errors counted here are those returned from the hcall, H_COP_OP.
+
+last_error:
+- The most recent non-zero return code from the H_COP_OP hcall. -EBUSY is not
+recorded here (the hcall will retry until -EBUSY goes away).
+
+last_error_pid:
+- The process ID of the process who received the most recent error from the
+hcall.
+
+Device Use
+==========
+
+aes_bytes:
+- The total number of bytes encrypted using AES in any of the driver's
+supported modes.
+
+aes_ops:
+- The total number of AES operations submitted to the hardware.
+
+sha256_bytes:
+- The total number of bytes hashed by the hardware using SHA-256.
+
+sha256_ops:
+- The total number of SHA-256 operations submitted to the hardware.
+
+sha512_bytes:
+- The total number of bytes hashed by the hardware using SHA-512.
+
+sha512_ops:
+- The total number of SHA-512 operations submitted to the hardware.
diff --git a/Documentation/ABI/testing/dev-kmsg b/Documentation/ABI/testing/dev-kmsg
new file mode 100644
index 000000000000..281ecc5f9709
--- /dev/null
+++ b/Documentation/ABI/testing/dev-kmsg
@@ -0,0 +1,90 @@
+What:           /dev/kmsg
+Date:           Mai 2012
+KernelVersion:  3.5
+Contact:        Kay Sievers <kay@vrfy.org>
+Description:    The /dev/kmsg character device node provides userspace access
+                to the kernel's printk buffer.
+
+                Injecting messages:
+                Every write() to the opened device node places a log entry in
+                the kernel's printk buffer.
+
+                The logged line can be prefixed with a <N> syslog prefix, which
+                carries the syslog priority and facility. The single decimal
+                prefix number is composed of the 3 lowest bits being the syslog
+                priority and the higher bits the syslog facility number.
+
+                If no prefix is given, the priority number is the default kernel
+                log priority and the facility number is set to LOG_USER (1). It
+                is not possible to inject messages from userspace with the
+                facility number LOG_KERN (0), to make sure that the origin of
+                the messages can always be reliably determined.
+
+                Accessing the buffer:
+                Every read() from the opened device node receives one record
+                of the kernel's printk buffer.
+
+                The first read() directly following an open() always returns
+                first message in the buffer; there is no kernel-internal
+                persistent state; many readers can concurrently open the device
+                and read from it, without affecting other readers.
+
+                Every read() will receive the next available record. If no more
+                records are available read() will block, or if O_NONBLOCK is
+                used -EAGAIN returned.
+
+                Messages in the record ring buffer get overwritten as whole,
+                there are never partial messages received by read().
+
+                In case messages get overwritten in the circular buffer while
+                the device is kept open, the next read() will return -EPIPE,
+                and the seek position be updated to the next available record.
+                Subsequent reads() will return available records again.
+
+                Unlike the classic syslog() interface, the 64 bit record
+                sequence numbers allow to calculate the amount of lost
+                messages, in case the buffer gets overwritten. And they allow
+                to reconnect to the buffer and reconstruct the read position
+                if needed, without limiting the interface to a single reader.
+
+                The device supports seek with the following parameters:
+                SEEK_SET, 0
+                  seek to the first entry in the buffer
+                SEEK_END, 0
+                  seek after the last entry in the buffer
+                SEEK_DATA, 0
+                  seek after the last record available at the time
+                  the last SYSLOG_ACTION_CLEAR was issued.
+
+                The output format consists of a prefix carrying the syslog
+                prefix including priority and facility, the 64 bit message
+                sequence number and the monotonic timestamp in microseconds.
+                The values are separated by a ','. Future extensions might
+                add more comma separated values before the terminating ';'.
+                Unknown values should be gracefully ignored.
+
+                The human readable text string starts directly after the ';'
+                and is terminated by a '\n'. Untrusted values derived from
+                hardware or other facilities are printed, therefore
+                all non-printable characters in the log message are escaped
+                by "\x00" C-style hex encoding.
+
+                A line starting with ' ', is a continuation line, adding
+                key/value pairs to the log message, which provide the machine
+                readable context of the message, for reliable processing in
+                userspace.
+
+                Example:
+                7,160,424069;pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7] (ignored)
+                 SUBSYSTEM=acpi
+                 DEVICE=+acpi:PNP0A03:00
+                6,339,5140900;NET: Registered protocol family 10
+                30,340,5690716;udevd[80]: starting version 181
+
+                The DEVICE= key uniquely identifies devices the following way:
+                  b12:8        - block dev_t
+                  c127:3       - char dev_t
+                  n8           - netdev ifindex
+                  +sound:card0 - subsystem:devname
+
+Users:          dmesg(1), userspace kernel log consumers
diff --git a/Documentation/ABI/testing/sysfs-block-rssd b/Documentation/ABI/testing/sysfs-block-rssd
index d535757799fe..beef30c046b0 100644
--- a/Documentation/ABI/testing/sysfs-block-rssd
+++ b/Documentation/ABI/testing/sysfs-block-rssd
@@ -1,18 +1,5 @@
-What:           /sys/block/rssd*/registers
-Date:           March 2012
-KernelVersion:  3.3
-Contact:        Asai Thambi S P <asamymuthupa@micron.com>
-Description:    This is a read-only file. Dumps below driver information and
-                hardware registers.
-                    - S ACTive
-                    - Command Issue
-                    - Allocated
-                    - Completed
-                    - PORT IRQ STAT
-                    - HOST IRQ STAT
-
 What:           /sys/block/rssd*/status
 Date:           April 2012
 KernelVersion:  3.4
 Contact:        Asai Thambi S P <asamymuthupa@micron.com>
-Description:   This is a read-only file. Indicates the status of the device.
+Description:    This is a read-only file. Indicates the status of the device.
diff --git a/Documentation/ABI/testing/sysfs-bus-fcoe b/Documentation/ABI/testing/sysfs-bus-fcoe
new file mode 100644
index 000000000000..469d09c02f6b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-fcoe
@@ -0,0 +1,77 @@
+What:           /sys/bus/fcoe/ctlr_X
+Date:           March 2012
+KernelVersion:  TBD
+Contact:        Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
+Description:    'FCoE Controller' instances on the fcoe bus
+Attributes:
+
+        fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
+                          this value will change the dev_loss_tmo for all
+                          FCFs discovered by this controller.
+
+        lesb_link_fail:   Link Error Status Block (LESB) link failure count.
+
+        lesb_vlink_fail:  Link Error Status Block (LESB) virtual link
+                          failure count.
+
+        lesb_miss_fka:    Link Error Status Block (LESB) missed FCoE
+                          Initialization Protocol (FIP) Keep-Alives (FKA).
+
+        lesb_symb_err:    Link Error Status Block (LESB) symbolic error count.
+
+        lesb_err_block:   Link Error Status Block (LESB) block error count.
+
+        lesb_fcs_error:   Link Error Status Block (LESB) Fibre Channel
+                          Serivces error count.
+
+Notes: ctlr_X (global increment starting at 0)
+
+What:           /sys/bus/fcoe/fcf_X
+Date:           March 2012
+KernelVersion:  TBD
+Contact:        Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
+Description:    'FCoE FCF' instances on the fcoe bus. A FCF is a Fibre Channel
+                Forwarder, which is a FCoE switch that can accept FCoE
+                (Ethernet) packets, unpack them, and forward the embedded
+                Fibre Channel frames into a FC fabric. It can also take
+                outbound FC frames and pack them in Ethernet packets to
+                be sent to their destination on the Ethernet segment.
+Attributes:
+
+        fabric_name: Identifies the fabric that the FCF services.
+
+        switch_name: Identifies the FCF.
+
+        priority:    The switch's priority amongst other FCFs on the same
+                     fabric.
+
+        selected:    1 indicates that the switch has been selected for use;
+                     0 indicates that the swich will not be used.
+
+        fc_map:      The Fibre Channel MAP
+
+        vfid:        The Virtual Fabric ID
+
+        mac:         The FCF's MAC address
+
+        fka_peroid:  The FIP Keep-Alive peroid
+
+        fabric_state: The internal kernel state
+                      "Unknown" - Initialization value
+                      "Disconnected" - No link to the FCF/fabric
+                      "Connected" - Host is connected to the FCF
+                      "Deleted" - FCF is being removed from the system
+
+        dev_loss_tmo: The device loss timeout peroid for this FCF.
+
+Notes: A device loss infrastructre similar to the FC Transport's
+       is present in fcoe_sysfs. It is nice to have so that a
+       link flapping adapter doesn't continually advance the count
+       used to identify the discovered FCF. FCFs will exist in a
+       "Disconnected" state until either the timer expires and the
+       FCF becomes "Deleted" or the FCF is rediscovered and becomes
+       "Connected."
+
+
+Users: The first user of this interface will be the fcoeadm application,
+       which is commonly packaged in the fcoe-utils package.
diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533 b/Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
new file mode 100644
index 000000000000..1b62230b33b9
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533
@@ -0,0 +1,15 @@
+What:           /sys/bus/i2c/devices/.../output_hvled[n]
+Date:           April 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Set the controlling backlight device for high-voltage current
+                sink HVLED[n] (n = 1, 2) (0, 1).
+
+What:           /sys/bus/i2c/devices/.../output_lvled[n]
+Date:           April 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Set the controlling led device for low-voltage current sink
+                LVLED[n] (n = 1..5) (0..3).
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
new file mode 100644
index 000000000000..cfedf63cce15
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -0,0 +1,768 @@
+What:           /sys/bus/iio/devices/iio:deviceX
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Hardware chip or device accessed by one communication port.
+                Corresponds to a grouping of sensor channels. X is the IIO
+                index of the device.
+
+What:           /sys/bus/iio/devices/triggerX
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                An event driven driver of data capture to an in kernel buffer.
+                May be provided by a device driver that also has an IIO device
+                based on hardware generated events (e.g. data ready) or
+                provided by a separate driver for other hardware (e.g.
+                periodic timer, GPIO or high resolution timer).
+                Contains trigger type specific elements. These do not
+                generalize well and hence are not documented in this file.
+                X is the IIO index of the trigger.
+
+What:           /sys/bus/iio/devices/iio:deviceX/buffer
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Directory of attributes relating to the buffer for the device.
+
+What:           /sys/bus/iio/devices/iio:deviceX/name
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Description of the physical chip / device for device X.
+                Typically a part number.
+
+What:           /sys/bus/iio/devices/iio:deviceX/sampling_frequency
+What:           /sys/bus/iio/devices/iio:deviceX/buffer/sampling_frequency
+What:           /sys/bus/iio/devices/triggerX/sampling_frequency
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Some devices have internal clocks.  This parameter sets the
+                resulting sampling frequency.  In many devices this
+                parameter has an effect on input filters etc rather than
+                simply controlling when the input is sampled.  As this
+                effects datardy triggers, hardware buffers and the sysfs
+                direct access interfaces, it may be found in any of the
+                relevant directories.  If it effects all of the above
+                then it is to be found in the base device directory.
+
+What:           /sys/bus/iio/devices/iio:deviceX/sampling_frequency_available
+What:           /sys/.../iio:deviceX/buffer/sampling_frequency_available
+What:           /sys/bus/iio/devices/triggerX/sampling_frequency_available
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                When the internal sampling clock can only take a small
+                discrete set of values, this file lists those available.
+
+What:           /sys/bus/iio/devices/iio:deviceX/oversampling_ratio
+KernelVersion:  2.6.38
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Hardware dependent ADC oversampling. Controls the sampling ratio
+                of the digital filter if available.
+
+What:           /sys/bus/iio/devices/iio:deviceX/oversampling_ratio_available
+KernelVersion:  2.6.38
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Hardware dependent values supported by the oversampling filter.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_voltageY_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_raw
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Raw (unscaled no bias removal etc) voltage measurement from
+                channel Y. In special cases where the channel does not
+                correspond to externally available input one of the named
+                versions may be used. The number must always be specified and
+                unique to allow association with event codes. Units after
+                application of scale and offset are microvolts.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_raw
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Raw (unscaled) differential voltage measurement equivalent to
+                channel Y - channel Z where these channel numbers apply to the
+                physically equivalent inputs when non differential readings are
+                separately available. In differential only parts, then all that
+                is required is a consistent labeling.  Units after application
+                of scale and offset are microvolts.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
+KernelVersion:  3.2
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Raw capacitance measurement from channel Y. Units after
+                application of scale and offset are nanofarads.
+
+What:           /sys/.../iio:deviceX/in_capacitanceY-in_capacitanceZ_raw
+KernelVersion:  3.2
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Raw differential capacitance measurement equivalent to
+                channel Y - channel Z where these channel numbers apply to the
+                physically equivalent inputs when non differential readings are
+                separately available. In differential only parts, then all that
+                is required is a consistent labeling.  Units after application
+                of scale and offset are nanofarads.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_temp_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_tempX_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_temp_x_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_temp_y_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_temp_z_raw
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Raw (unscaled no bias removal etc) temperature measurement.
+                If an axis is specified it generally means that the temperature
+                sensor is associated with one part of a compound device (e.g.
+                a gyroscope axis). Units after application of scale and offset
+                are milli degrees Celsuis.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_tempX_input
+KernelVersion:  2.6.38
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Scaled temperature measurement in milli degrees Celsius.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_x_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_y_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_z_raw
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Acceleration in direction x, y or z (may be arbitrarily assigned
+                but should match other such assignments on device).
+                Has all of the equivalent parameters as per voltageY. Units
+                after application of scale and offset are m/s^2.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_raw
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Angular velocity about axis x, y or z (may be arbitrarily
+                assigned) Data converted by application of offset then scale to
+                radians per second. Has all the equivalent parameters as
+                per voltageY. Units after application of scale and offset are
+                radians per second.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_incli_x_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_incli_y_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_incli_z_raw
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Inclination raw reading about axis x, y or z (may be
+                arbitrarily assigned). Data converted by application of offset
+                and scale to Degrees.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_magn_x_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_magn_y_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_magn_z_raw
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Magnetic field along axis x, y or z (may be arbitrarily
+                assigned).  Data converted by application of offset
+                then scale to Gauss.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_x_peak_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_y_peak_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_z_peak_raw
+KernelVersion:  2.6.36
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Highest value since some reset condition.  These
+                attributes allow access to this and are otherwise
+                the direct equivalent of the <type>Y[_name]_raw attributes.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_xyz_squared_peak_raw
+KernelVersion:  2.6.36
+Contact:        linux-iio@vger.kernel.org
+Description:
+                A computed peak value based on the sum squared magnitude of
+                the underlying value in the specified directions.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_offset
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_z_offset
+What:           /sys/bus/iio/devices/iio:deviceX/in_voltageY_offset
+What:           /sys/bus/iio/devices/iio:deviceX/in_voltage_offset
+What:           /sys/bus/iio/devices/iio:deviceX/in_tempY_offset
+What:           /sys/bus/iio/devices/iio:deviceX/in_temp_offset
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                If known for a device, offset to be added to <type>[Y]_raw prior
+                to scaling by <type>[Y]_scale in order to obtain value in the
+                <type> units as specified in <type>[y]_raw documentation.
+                Not present if the offset is always 0 or unknown. If Y or
+                axis <x|y|z> is not present, then the offset applies to all
+                in channels of <type>.
+                May be writable if a variable offset can be applied on the
+                device. Note that this is different to calibbias which
+                is for devices (or drivers) that apply offsets to compensate
+                for variation between different instances of the part, typically
+                adjusted by using some hardware supported calibration procedure.
+                Calibbias is applied internally, offset is applied in userspace
+                to the _raw output.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_voltageY_scale
+What:           /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale
+What:           /sys/bus/iio/devices/iio:deviceX/in_voltage_scale
+What:           /sys/bus/iio/devices/iio:deviceX/out_voltageY_scale
+What:           /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_scale
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
+What:           /sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
+What:           /sys/bus/iio/devices/iio:deviceX/in_magn_scale
+What:           /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
+What:           /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
+What:           /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                If known for a device, scale to be applied to <type>Y[_name]_raw
+                post addition of <type>[Y][_name]_offset in order to obtain the
+                measured value in <type> units as specified in
+                <type>[Y][_name]_raw documentation.  If shared across all in
+                channels then Y and <x|y|z> are not present and the value is
+                called <type>[Y][_name]_scale. The peak modifier means this
+                value is applied to <type>Y[_name]_peak_raw values.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias
+What:           /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias
+What:           /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias
+What:           /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias
+What:           /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibbias
+What:           /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Hardware applied calibration offset. (assumed to fix production
+                inaccuracies).
+
+What            /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale
+What            /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale
+What            /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale
+What            /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale
+What            /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale
+What            /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibscale
+What            /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibscale
+What            /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibscale
+What            /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibscale
+what            /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibscale
+what            /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Hardware applied calibration scale factor. (assumed to fix
+                production inaccuracies).  If shared across all channels,
+                <type>_calibscale is used.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_accel_scale_available
+What:           /sys/.../iio:deviceX/in_voltageX_scale_available
+What:           /sys/.../iio:deviceX/in_voltage-voltage_scale_available
+What:           /sys/.../iio:deviceX/out_voltageX_scale_available
+What:           /sys/.../iio:deviceX/out_altvoltageX_scale_available
+What:           /sys/.../iio:deviceX/in_capacitance_scale_available
+KernelVersion:  2.635
+Contact:        linux-iio@vger.kernel.org
+Description:
+                If a discrete set of scale values are available, they
+                are listed in this attribute.
+
+What            /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Hardware applied gain factor. If shared across all channels,
+                <type>_hardwaregain is used.
+
+What:           /sys/.../in_accel_filter_low_pass_3db_frequency
+What:           /sys/.../in_magn_filter_low_pass_3db_frequency
+What:           /sys/.../in_anglvel_filter_low_pass_3db_frequency
+KernelVersion:  3.2
+Contact:        linux-iio@vger.kernel.org
+Description:
+                If a known or controllable low pass filter is applied
+                to the underlying data channel, then this parameter
+                gives the 3dB frequency of the filter in Hz.
+
+What:           /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw
+What:           /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_raw
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Raw (unscaled, no bias etc.) output voltage for
+                channel Y.  The number must always be specified and
+                unique if the output corresponds to a single channel.
+                While DAC like devices typically use out_voltage,
+                a continuous frequency generating device, such as
+                a DDS or PLL should use out_altvoltage.
+
+What:           /sys/bus/iio/devices/iio:deviceX/out_voltageY&Z_raw
+What:           /sys/bus/iio/devices/iio:deviceX/out_altvoltageY&Z_raw
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Raw (unscaled, no bias etc.) output voltage for an aggregate of
+                channel Y, channel Z, etc.  This interface is available in cases
+                where a single output sets the value for multiple channels
+                simultaneously.
+
+What:           /sys/bus/iio/devices/iio:deviceX/out_voltageY_powerdown_mode
+What:           /sys/bus/iio/devices/iio:deviceX/out_voltage_powerdown_mode
+What:           /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown_mode
+What:           /sys/bus/iio/devices/iio:deviceX/out_altvoltage_powerdown_mode
+KernelVersion:  2.6.38
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Specifies the output powerdown mode.
+                DAC output stage is disconnected from the amplifier and
+                1kohm_to_gnd: connected to ground via an 1kOhm resistor
+                100kohm_to_gnd: connected to ground via an 100kOhm resistor
+                three_state: left floating
+                For a list of available output power down options read
+                outX_powerdown_mode_available. If Y is not present the
+                mode is shared across all outputs.
+
+What:           /sys/.../iio:deviceX/out_votlageY_powerdown_mode_available
+What:           /sys/.../iio:deviceX/out_voltage_powerdown_mode_available
+What:           /sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available
+What:           /sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available
+KernelVersion:  2.6.38
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Lists all available output power down modes.
+                If Y is not present the mode is shared across all outputs.
+
+What:           /sys/bus/iio/devices/iio:deviceX/out_voltageY_powerdown
+What:           /sys/bus/iio/devices/iio:deviceX/out_voltage_powerdown
+What:           /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown
+What:           /sys/bus/iio/devices/iio:deviceX/out_altvoltage_powerdown
+KernelVersion:  2.6.38
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Writing 1 causes output Y to enter the power down mode specified
+                by the corresponding outY_powerdown_mode. Clearing returns to
+                normal operation. Y may be suppressed if all outputs are
+                controlled together.
+
+What:           /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency
+KernelVersion:  3.4.0
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Output frequency for channel Y in Hz. The number must always be
+                specified and unique if the output corresponds to a single
+                channel.
+
+What:           /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase
+KernelVersion:  3.4.0
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Phase in radians of one frequency/clock output Y
+                (out_altvoltageY) relative to another frequency/clock output
+                (out_altvoltageZ) of the device X. The number must always be
+                specified and unique if the output corresponds to a single
+                channel.
+
+What:           /sys/bus/iio/devices/iio:deviceX/events
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Configuration of which hardware generated events are passed up
+                to user-space.
+
+What:           /sys/.../iio:deviceX/events/in_accel_x_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_x_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_accel_y_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_y_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_accel_z_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_z_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_x_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_x_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_y_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_y_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_z_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_z_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_magn_x_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_magn_x_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
+What:           /sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
+What:           /sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Event generated when channel passes a threshold in the specified
+                (_rising|_falling) direction. If the direction is not specified,
+                then either the device will report an event which ever direction
+                a single threshold value is passed in (e.g.
+                <type>[Y][_name]_<raw|input>_thresh_value) or
+                <type>[Y][_name]_<raw|input>_thresh_rising_value and
+                <type>[Y][_name]_<raw|input>_thresh_falling_value may take
+                different values, but the device can only enable both thresholds
+                or neither.
+                Note the driver will assume the last p events requested are
+                to be enabled where p is however many it supports (which may
+                vary depending on the exact set requested. So if you want to be
+                sure you have set what you think you have, check the contents of
+                these attributes after everything is configured. Drivers may
+                have to buffer any parameters so that they are consistent when
+                a given event type is enabled a future point (and not those for
+                whatever event was previously enabled).
+
+What:           /sys/.../iio:deviceX/events/in_accel_x_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_x_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_accel_y_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_y_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_accel_z_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_z_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_x_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_x_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_y_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_y_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_z_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_anglvel_z_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_magn_x_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_magn_x_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_magn_y_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_voltageY_roc_falling_en
+What:           /sys/.../iio:deviceX/events/in_tempY_roc_rising_en
+What:           /sys/.../iio:deviceX/events/in_tempY_roc_falling_en
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Event generated when channel passes a threshold on the rate of
+                change (1st differential) in the specified (_rising|_falling)
+                direction. If the direction is not specified, then either the
+                device will report an event which ever direction a single
+                threshold value is passed in (e.g.
+                <type>[Y][_name]_<raw|input>_roc_value) or
+                <type>[Y][_name]_<raw|input>_roc_rising_value and
+                <type>[Y][_name]_<raw|input>_roc_falling_value may take
+                different values, but the device can only enable both rate of
+                change thresholds or neither.
+                Note the driver will assume the last p events requested are
+                to be enabled where p is however many it supports (which may
+                vary depending on the exact set requested. So if you want to be
+                sure you have set what you think you have, check the contents of
+                these attributes after everything is configured. Drivers may
+                have to buffer any parameters so that they are consistent when
+                a given event type is enabled a future point (and not those for
+                whatever event was previously enabled).
+
+What:           /sys/.../events/in_accel_x_raw_thresh_rising_value
+What:           /sys/.../events/in_accel_x_raw_thresh_falling_value
+What:           /sys/.../events/in_accel_y_raw_thresh_rising_value
+What:           /sys/.../events/in_accel_y_raw_thresh_falling_value
+What:           /sys/.../events/in_accel_z_raw_thresh_rising_value
+What:           /sys/.../events/in_accel_z_raw_thresh_falling_value
+What:           /sys/.../events/in_anglvel_x_raw_thresh_rising_value
+What:           /sys/.../events/in_anglvel_x_raw_thresh_falling_value
+What:           /sys/.../events/in_anglvel_y_raw_thresh_rising_value
+What:           /sys/.../events/in_anglvel_y_raw_thresh_falling_value
+What:           /sys/.../events/in_anglvel_z_raw_thresh_rising_value
+What:           /sys/.../events/in_anglvel_z_raw_thresh_falling_value
+What:           /sys/.../events/in_magn_x_raw_thresh_rising_value
+What:           /sys/.../events/in_magn_x_raw_thresh_falling_value
+What:           /sys/.../events/in_magn_y_raw_thresh_rising_value
+What:           /sys/.../events/in_magn_y_raw_thresh_falling_value
+What:           /sys/.../events/in_magn_z_raw_thresh_rising_value
+What:           /sys/.../events/in_magn_z_raw_thresh_falling_value
+What:           /sys/.../events/in_voltageY_supply_raw_thresh_rising_value
+What:           /sys/.../events/in_voltageY_supply_raw_thresh_falling_value
+What:           /sys/.../events/in_voltageY_raw_thresh_rising_value
+What:           /sys/.../events/in_voltageY_raw_thresh_falling_value
+What:           /sys/.../events/in_tempY_raw_thresh_rising_value
+What:           /sys/.../events/in_tempY_raw_thresh_falling_value
+What:           /sys/.../events/in_illuminance0_thresh_falling_value
+what:           /sys/.../events/in_illuminance0_thresh_rising_value
+what:           /sys/.../events/in_proximity0_thresh_falling_value
+what:           /sys/.../events/in_proximity0_thresh_rising_value
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Specifies the value of threshold that the device is comparing
+                against for the events enabled by
+                <type>Y[_name]_thresh[_rising|falling]_en.
+                If separate attributes exist for the two directions, but
+                direction is not specified for this attribute, then a single
+                threshold value applies to both directions.
+                The raw or input element of the name indicates whether the
+                value is in raw device units or in processed units (as _raw
+                and _input do on sysfs direct channel read attributes).
+
+What:           /sys/.../events/in_accel_x_raw_roc_rising_value
+What:           /sys/.../events/in_accel_x_raw_roc_falling_value
+What:           /sys/.../events/in_accel_y_raw_roc_rising_value
+What:           /sys/.../events/in_accel_y_raw_roc_falling_value
+What:           /sys/.../events/in_accel_z_raw_roc_rising_value
+What:           /sys/.../events/in_accel_z_raw_roc_falling_value
+What:           /sys/.../events/in_anglvel_x_raw_roc_rising_value
+What:           /sys/.../events/in_anglvel_x_raw_roc_falling_value
+What:           /sys/.../events/in_anglvel_y_raw_roc_rising_value
+What:           /sys/.../events/in_anglvel_y_raw_roc_falling_value
+What:           /sys/.../events/in_anglvel_z_raw_roc_rising_value
+What:           /sys/.../events/in_anglvel_z_raw_roc_falling_value
+What:           /sys/.../events/in_magn_x_raw_roc_rising_value
+What:           /sys/.../events/in_magn_x_raw_roc_falling_value
+What:           /sys/.../events/in_magn_y_raw_roc_rising_value
+What:           /sys/.../events/in_magn_y_raw_roc_falling_value
+What:           /sys/.../events/in_magn_z_raw_roc_rising_value
+What:           /sys/.../events/in_magn_z_raw_roc_falling_value
+What:           /sys/.../events/in_voltageY_supply_raw_roc_rising_value
+What:           /sys/.../events/in_voltageY_supply_raw_roc_falling_value
+What:           /sys/.../events/in_voltageY_raw_roc_rising_value
+What:           /sys/.../events/in_voltageY_raw_roc_falling_value
+What:           /sys/.../events/in_tempY_raw_roc_rising_value
+What:           /sys/.../events/in_tempY_raw_roc_falling_value
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Specifies the value of rate of change threshold that the
+                device is comparing against for the events enabled by
+                <type>[Y][_name]_roc[_rising|falling]_en.
+                If separate attributes exist for the two directions,
+                but direction is not specified for this attribute,
+                then a single threshold value applies to both directions.
+                The raw or input element of the name indicates whether the
+                value is in raw device units or in processed units (as _raw
+                and _input do on sysfs direct channel read attributes).
+
+What:           /sys/.../events/in_accel_x_thresh_rising_period
+What:           /sys/.../events/in_accel_x_thresh_falling_period
+hat:            /sys/.../events/in_accel_x_roc_rising_period
+What:           /sys/.../events/in_accel_x_roc_falling_period
+What:           /sys/.../events/in_accel_y_thresh_rising_period
+What:           /sys/.../events/in_accel_y_thresh_falling_period
+What:           /sys/.../events/in_accel_y_roc_rising_period
+What:           /sys/.../events/in_accel_y_roc_falling_period
+What:           /sys/.../events/in_accel_z_thresh_rising_period
+What:           /sys/.../events/in_accel_z_thresh_falling_period
+What:           /sys/.../events/in_accel_z_roc_rising_period
+What:           /sys/.../events/in_accel_z_roc_falling_period
+What:           /sys/.../events/in_anglvel_x_thresh_rising_period
+What:           /sys/.../events/in_anglvel_x_thresh_falling_period
+What:           /sys/.../events/in_anglvel_x_roc_rising_period
+What:           /sys/.../events/in_anglvel_x_roc_falling_period
+What:           /sys/.../events/in_anglvel_y_thresh_rising_period
+What:           /sys/.../events/in_anglvel_y_thresh_falling_period
+What:           /sys/.../events/in_anglvel_y_roc_rising_period
+What:           /sys/.../events/in_anglvel_y_roc_falling_period
+What:           /sys/.../events/in_anglvel_z_thresh_rising_period
+What:           /sys/.../events/in_anglvel_z_thresh_falling_period
+What:           /sys/.../events/in_anglvel_z_roc_rising_period
+What:           /sys/.../events/in_anglvel_z_roc_falling_period
+What:           /sys/.../events/in_magn_x_thresh_rising_period
+What:           /sys/.../events/in_magn_x_thresh_falling_period
+What:           /sys/.../events/in_magn_x_roc_rising_period
+What:           /sys/.../events/in_magn_x_roc_falling_period
+What:           /sys/.../events/in_magn_y_thresh_rising_period
+What:           /sys/.../events/in_magn_y_thresh_falling_period
+What:           /sys/.../events/in_magn_y_roc_rising_period
+What:           /sys/.../events/in_magn_y_roc_falling_period
+What:           /sys/.../events/in_magn_z_thresh_rising_period
+What:           /sys/.../events/in_magn_z_thresh_falling_period
+What:           /sys/.../events/in_magn_z_roc_rising_period
+What:           /sys/.../events/in_magn_z_roc_falling_period
+What:           /sys/.../events/in_voltageY_supply_thresh_rising_period
+What:           /sys/.../events/in_voltageY_supply_thresh_falling_period
+What:           /sys/.../events/in_voltageY_supply_roc_rising_period
+What:           /sys/.../events/in_voltageY_supply_roc_falling_period
+What:           /sys/.../events/in_voltageY_thresh_rising_period
+What:           /sys/.../events/in_voltageY_thresh_falling_period
+What:           /sys/.../events/in_voltageY_roc_rising_period
+What:           /sys/.../events/in_voltageY_roc_falling_period
+What:           /sys/.../events/in_tempY_thresh_rising_period
+What:           /sys/.../events/in_tempY_thresh_falling_period
+What:           /sys/.../events/in_tempY_roc_rising_period
+What:           /sys/.../events/in_tempY_roc_falling_period
+What:           /sys/.../events/in_accel_x&y&z_mag_falling_period
+What:           /sys/.../events/in_intensity0_thresh_period
+What:           /sys/.../events/in_proximity0_thresh_period
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Period of time (in seconds) for which the condition must be
+                met before an event is generated. If direction is not
+                specified then this period applies to both directions.
+
+What:           /sys/.../iio:deviceX/events/in_accel_mag_en
+What:           /sys/.../iio:deviceX/events/in_accel_mag_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_mag_falling_en
+What:           /sys/.../iio:deviceX/events/in_accel_x_mag_en
+What:           /sys/.../iio:deviceX/events/in_accel_x_mag_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_x_mag_falling_en
+What:           /sys/.../iio:deviceX/events/in_accel_y_mag_en
+What:           /sys/.../iio:deviceX/events/in_accel_y_mag_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_y_mag_falling_en
+What:           /sys/.../iio:deviceX/events/in_accel_z_mag_en
+What:           /sys/.../iio:deviceX/events/in_accel_z_mag_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_z_mag_falling_en
+What:           /sys/.../iio:deviceX/events/in_accel_x&y&z_mag_rising_en
+What:           /sys/.../iio:deviceX/events/in_accel_x&y&z_mag_falling_en
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Similar to in_accel_x_thresh[_rising|_falling]_en, but here the
+                magnitude of the channel is compared to the threshold, not its
+                signed value.
+
+What:           /sys/.../events/in_accel_raw_mag_value
+What:           /sys/.../events/in_accel_x_raw_mag_rising_value
+What:           /sys/.../events/in_accel_y_raw_mag_rising_value
+What:           /sys/.../events/in_accel_z_raw_mag_rising_value
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                The value to which the magnitude of the channel is compared. If
+                number or direction is not specified, applies to all channels of
+                this type.
+
+What:           /sys/bus/iio/devices/iio:deviceX/trigger/current_trigger
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                The name of the trigger source being used, as per string given
+                in /sys/class/iio/triggerY/name.
+
+What:           /sys/bus/iio/devices/iio:deviceX/buffer/length
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Number of scans contained by the buffer.
+
+What:           /sys/bus/iio/devices/iio:deviceX/buffer/bytes_per_datum
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Bytes per scan.  Due to alignment fun, the scan may be larger
+                than implied directly by the scan_element parameters.
+
+What:           /sys/bus/iio/devices/iio:deviceX/buffer/enable
+KernelVersion:  2.6.35
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Actually start the buffer capture up.  Will start trigger
+                if first device and appropriate.
+
+What:           /sys/bus/iio/devices/iio:deviceX/buffer/scan_elements
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Directory containing interfaces for elements that will be
+                captured for a single triggered sample set in the buffer.
+
+What:           /sys/.../buffer/scan_elements/in_accel_x_en
+What:           /sys/.../buffer/scan_elements/in_accel_y_en
+What:           /sys/.../buffer/scan_elements/in_accel_z_en
+What:           /sys/.../buffer/scan_elements/in_anglvel_x_en
+What:           /sys/.../buffer/scan_elements/in_anglvel_y_en
+What:           /sys/.../buffer/scan_elements/in_anglvel_z_en
+What:           /sys/.../buffer/scan_elements/in_magn_x_en
+What:           /sys/.../buffer/scan_elements/in_magn_y_en
+What:           /sys/.../buffer/scan_elements/in_magn_z_en
+What:           /sys/.../buffer/scan_elements/in_timestamp_en
+What:           /sys/.../buffer/scan_elements/in_voltageY_supply_en
+What:           /sys/.../buffer/scan_elements/in_voltageY_en
+What:           /sys/.../buffer/scan_elements/in_voltageY-voltageZ_en
+What:           /sys/.../buffer/scan_elements/in_incli_x_en
+What:           /sys/.../buffer/scan_elements/in_incli_y_en
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Scan element control for triggered data capture.
+
+What:           /sys/.../buffer/scan_elements/in_accel_type
+What:           /sys/.../buffer/scan_elements/in_anglvel_type
+What:           /sys/.../buffer/scan_elements/in_magn_type
+What:           /sys/.../buffer/scan_elements/in_incli_type
+What:           /sys/.../buffer/scan_elements/in_voltageY_type
+What:           /sys/.../buffer/scan_elements/in_voltage-in_type
+What:           /sys/.../buffer/scan_elements/in_voltageY_supply_type
+What:           /sys/.../buffer/scan_elements/in_timestamp_type
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Description of the scan element data storage within the buffer
+                and hence the form in which it is read from user-space.
+                Form is [be|le]:[s|u]bits/storagebits[>>shift].
+                be or le specifies big or little endian. s or u specifies if
+                signed (2's complement) or unsigned. bits is the number of bits
+                of data and storagebits is the space (after padding) that it
+                occupies in the buffer. shift if specified, is the shift that
+                needs to be applied prior to masking out unused bits. Some
+                devices put their data in the middle of the transferred elements
+                with additional information on both sides.  Note that some
+                devices will have additional information in the unused bits
+                so to get a clean value, the bits value must be used to mask
+                the buffer output value appropriately.  The storagebits value
+                also specifies the data alignment.  So s48/64>>2 will be a
+                signed 48 bit integer stored in a 64 bit location aligned to
+                a a64 bit boundary. To obtain the clean value, shift right 2
+                and apply a mask to zero the top 16 bits of the result.
+                For other storage combinations this attribute will be extended
+                appropriately.
+
+What:           /sys/.../buffer/scan_elements/in_accel_type_available
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                If the type parameter can take one of a small set of values,
+                this attribute lists them.
+
+What:           /sys/.../buffer/scan_elements/in_voltageY_index
+What:           /sys/.../buffer/scan_elements/in_voltageY_supply_index
+What:           /sys/.../buffer/scan_elements/in_accel_x_index
+What:           /sys/.../buffer/scan_elements/in_accel_y_index
+What:           /sys/.../buffer/scan_elements/in_accel_z_index
+What:           /sys/.../buffer/scan_elements/in_anglvel_x_index
+What:           /sys/.../buffer/scan_elements/in_anglvel_y_index
+What:           /sys/.../buffer/scan_elements/in_anglvel_z_index
+What:           /sys/.../buffer/scan_elements/in_magn_x_index
+What:           /sys/.../buffer/scan_elements/in_magn_y_index
+What:           /sys/.../buffer/scan_elements/in_magn_z_index
+What:           /sys/.../buffer/scan_elements/in_incli_x_index
+What:           /sys/.../buffer/scan_elements/in_incli_y_index
+What:           /sys/.../buffer/scan_elements/in_timestamp_index
+KernelVersion:  2.6.37
+Contact:        linux-iio@vger.kernel.org
+Description:
+                A single positive integer specifying the position of this
+                scan element in the buffer. Note these are not dependent on
+                what is enabled and may not be contiguous. Thus for user-space
+                to establish the full layout these must be used in conjunction
+                with all _en attributes to establish which channels are present,
+                and the relevant _type attributes to establish the data storage
+                format.
+
+What:           /sys/.../iio:deviceX/in_anglvel_z_quadrature_correction_raw
+KernelVersion:  2.6.38
+Contact:        linux-iio@vger.kernel.org
+Description:
+                This attribute is used to read the amount of quadrature error
+                present in the device at a given time.
diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd
index dbedafb095e2..bcd88eb7ebcd 100644
--- a/Documentation/ABI/testing/sysfs-bus-rbd
+++ b/Documentation/ABI/testing/sysfs-bus-rbd
@@ -65,11 +65,11 @@ snap_*
 Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
 -------------------------------------------------------------
 
-id
+snap_id
 
         The rados internal snapshot id assigned for this snapshot
 
-size
+snap_size
 
         The size of the image when this snapshot was taken.
 
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index 7c22a532fdfb..6df4e6f57560 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -135,6 +135,17 @@ Description:
                 for the device and attempt to bind to it.  For example:
                 # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
 
+                Reading from this file will list all dynamically added
+                device IDs in the same format, with one entry per
+                line. For example:
+                # cat /sys/bus/usb/drivers/foo/new_id
+                8086 10f5
+                dead beef 06
+                f00d cafe
+
+                The list will be truncated at PAGE_SIZE bytes due to
+                sysfs restrictions.
+
 What:           /sys/bus/usb-serial/drivers/.../new_id
 Date:           October 2011
 Contact:        linux-usb@vger.kernel.org
@@ -157,6 +168,10 @@ Description:
                 match the driver to the device.  For example:
                 # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id
 
+                Reading from this file will list the dynamically added
+                device IDs, exactly like reading from the entry
+                "/sys/bus/usb/drivers/.../new_id"
+
 What:           /sys/bus/usb/device/.../avoid_reset_quirk
 Date:           December 2009
 Contact:        Oliver Neukum <oliver@neukum.org>
@@ -189,7 +204,7 @@ Contact:	Matthew Garrett <mjg@redhat.com>
 Description:
                 Some information about whether a given USB device is
                 physically fixed to the platform can be inferred from a
-                combination of hub decriptor bits and platform-specific data
+                combination of hub descriptor bits and platform-specific data
                 such as ACPI. This file will read either "removable" or
                 "fixed" if the information is available, and "unknown"
-                otherwise.
\ No newline at end of file
+                otherwise.
diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533 b/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
new file mode 100644
index 000000000000..77cf7ac949af
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533
@@ -0,0 +1,48 @@
+What:           /sys/class/backlight/<backlight>/als_channel
+Date:           May 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Get the ALS output channel used as input in
+                ALS-current-control mode (0, 1), where
+
+                0 - out_current0 (backlight 0)
+                1 - out_current1 (backlight 1)
+
+What:           /sys/class/backlight/<backlight>/als_en
+Date:           May 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Enable ALS-current-control mode (0, 1).
+
+What:           /sys/class/backlight/<backlight>/id
+Date:           April 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Get the id of this backlight (0, 1).
+
+What:           /sys/class/backlight/<backlight>/linear
+Date:           April 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Set the brightness-mapping mode (0, 1), where
+
+                0 - exponential mode
+                1 - linear mode
+
+What:           /sys/class/backlight/<backlight>/pwm
+Date:           April 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Set the PWM-input control mask (5 bits), where
+
+                bit 5 - PWM-input enabled in Zone 4
+                bit 4 - PWM-input enabled in Zone 3
+                bit 3 - PWM-input enabled in Zone 2
+                bit 2 - PWM-input enabled in Zone 1
+                bit 1 - PWM-input enabled in Zone 0
+                bit 0 - PWM-input enabled
diff --git a/Documentation/ABI/testing/sysfs-class-extcon b/Documentation/ABI/testing/sysfs-class-extcon
new file mode 100644
index 000000000000..20ab361bd8c6
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-extcon
@@ -0,0 +1,97 @@
+What:           /sys/class/extcon/.../
+Date:           February 2012
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                Provide a place in sysfs for the extcon objects.
+                This allows accessing extcon specific variables.
+                The name of extcon object denoted as ... is the name given
+                with extcon_dev_register.
+
+                One extcon device denotes a single external connector
+                port. An external connector may have multiple cables
+                attached simultaneously. Many of docks, cradles, and
+                accessory cables have such capability. For example,
+                the 30-pin port of Nuri board (/arch/arm/mach-exynos)
+                may have both HDMI and Charger attached, or analog audio,
+                video, and USB cables attached simulteneously.
+
+                If there are cables mutually exclusive with each other,
+                such binary relations may be expressed with extcon_dev's
+                mutually_exclusive array.
+
+What:           /sys/class/extcon/.../name
+Date:           February 2012
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                The /sys/class/extcon/.../name shows the name of the extcon
+                object. If the extcon object has an optional callback
+                "show_name" defined, the callback will provide the name with
+                this sysfs node.
+
+What:           /sys/class/extcon/.../state
+Date:           February 2012
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                The /sys/class/extcon/.../state shows and stores the cable
+                attach/detach information of the corresponding extcon object.
+                If the extcon object has an optional callback "show_state"
+                defined, the showing function is overriden with the optional
+                callback.
+
+                If the default callback for showing function is used, the
+                format is like this:
+                # cat state
+                USB_OTG=1
+                HDMI=0
+                TA=1
+                EAR_JACK=0
+                #
+                In this example, the extcon device have USB_OTG and TA
+                cables attached and HDMI and EAR_JACK cables detached.
+
+                In order to update the state of an extcon device, enter a hex
+                state number starting with 0x.
+                 echo 0xHEX > state
+
+                This updates the whole state of the extcon dev.
+                Inputs of all the methods are required to meet the
+                mutually_exclusive contidions if they exist.
+
+                It is recommended to use this "global" state interface if
+                you need to enter the value atomically. The later state
+                interface associated with each cable cannot update
+                multiple cable states of an extcon device simultaneously.
+
+What:           /sys/class/extcon/.../cable.x/name
+Date:           February 2012
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                The /sys/class/extcon/.../cable.x/name shows the name of cable
+                "x" (integer between 0 and 31) of an extcon device.
+
+What:           /sys/class/extcon/.../cable.x/state
+Date:           February 2012
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                The /sys/class/extcon/.../cable.x/name shows and stores the
+                state of cable "x" (integer between 0 and 31) of an extcon
+                device. The state value is either 0 (detached) or 1
+                (attached).
+
+What:           /sys/class/extcon/.../mutually_exclusive/...
+Date:           December 2011
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                Shows the relations of mutually exclusiveness. For example,
+                if the mutually_exclusive array of extcon_dev is
+                {0x3, 0x5, 0xC, 0x0}, the, the output is:
+                # ls mutually_exclusive/
+                0x3
+                0x5
+                0xc
+                #
+
+                Note that mutually_exclusive is a sub-directory of the extcon
+                device and the file names under the mutually_exclusive
+                directory show the mutually-exclusive sets, not the contents
+                of the files.
diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-lm3533 b/Documentation/ABI/testing/sysfs-class-led-driver-lm3533
new file mode 100644
index 000000000000..620ebb3b9baa
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-driver-lm3533
@@ -0,0 +1,65 @@
+What:           /sys/class/leds/<led>/als_channel
+Date:           May 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Set the ALS output channel to use as input in
+                ALS-current-control mode (1, 2), where
+
+                1 - out_current1
+                2 - out_current2
+
+What:           /sys/class/leds/<led>/als_en
+Date:           May 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Enable ALS-current-control mode (0, 1).
+
+What:           /sys/class/leds/<led>/falltime
+What:           /sys/class/leds/<led>/risetime
+Date:           April 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Set the pattern generator fall and rise times (0..7), where
+
+                0 - 2048 us
+                1 - 262 ms
+                2 - 524 ms
+                3 - 1.049 s
+                4 - 2.097 s
+                5 - 4.194 s
+                6 - 8.389 s
+                7 - 16.78 s
+
+What:           /sys/class/leds/<led>/id
+Date:           April 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Get the id of this led (0..3).
+
+What:           /sys/class/leds/<led>/linear
+Date:           April 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Set the brightness-mapping mode (0, 1), where
+
+                0 - exponential mode
+                1 - linear mode
+
+What:           /sys/class/leds/<led>/pwm
+Date:           April 2012
+KernelVersion:  3.5
+Contact:        Johan Hovold <jhovold@gmail.com>
+Description:
+                Set the PWM-input control mask (5 bits), where
+
+                bit 5 - PWM-input enabled in Zone 4
+                bit 4 - PWM-input enabled in Zone 3
+                bit 3 - PWM-input enabled in Zone 2
+                bit 2 - PWM-input enabled in Zone 1
+                bit 1 - PWM-input enabled in Zone 0
+                bit 0 - PWM-input enabled
diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
index 4d55a1888981..938ef71e2035 100644
--- a/Documentation/ABI/testing/sysfs-class-mtd
+++ b/Documentation/ABI/testing/sysfs-class-mtd
@@ -123,3 +123,55 @@ Description:
                 half page, or a quarter page).
 
                 In the case of ECC NOR, it is the ECC block size.
+
+What:           /sys/class/mtd/mtdX/ecc_strength
+Date:           April 2012
+KernelVersion:  3.4
+Contact:        linux-mtd@lists.infradead.org
+Description:
+                Maximum number of bit errors that the device is capable of
+                correcting within each region covering an ecc step.  This will
+                always be a non-negative integer.  Note that some devices will
+                have multiple ecc steps within each writesize region.
+
+                In the case of devices lacking any ECC capability, it is 0.
+
+What:           /sys/class/mtd/mtdX/bitflip_threshold
+Date:           April 2012
+KernelVersion:  3.4
+Contact:        linux-mtd@lists.infradead.org
+Description:
+                This allows the user to examine and adjust the criteria by which
+                mtd returns -EUCLEAN from mtd_read() and mtd_read_oob().  If the
+                maximum number of bit errors that were corrected on any single
+                region comprising an ecc step (as reported by the driver) equals
+                or exceeds this value, -EUCLEAN is returned.  Otherwise, absent
+                an error, 0 is returned.  Higher layers (e.g., UBI) use this
+                return code as an indication that an erase block may be
+                degrading and should be scrutinized as a candidate for being
+                marked as bad.
+
+                The initial value may be specified by the flash device driver.
+                If not, then the default value is ecc_strength.
+
+                The introduction of this feature brings a subtle change to the
+                meaning of the -EUCLEAN return code.  Previously, it was
+                interpreted to mean simply "one or more bit errors were
+                corrected".  Its new interpretation can be phrased as "a
+                dangerously high number of bit errors were corrected on one or
+                more regions comprising an ecc step".  The precise definition of
+                "dangerously high" can be adjusted by the user with
+                bitflip_threshold.  Users are discouraged from doing this,
+                however, unless they know what they are doing and have intimate
+                knowledge of the properties of their device.  Broadly speaking,
+                bitflip_threshold should be low enough to detect genuine erase
+                block degradation, but high enough to avoid the consequences of
+                a persistent return value of -EUCLEAN on devices where sticky
+                bitflips occur.  Note that if bitflip_threshold exceeds
+                ecc_strength, -EUCLEAN is never returned by the read operations.
+                Conversely, if bitflip_threshold is zero, -EUCLEAN is always
+                returned, absent a hard error.
+
+                This is generally applicable only to NAND flash devices with ECC
+                capability.  It is ignored on devices lacking ECC capability;
+                i.e., devices for which ecc_strength is zero.
diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh
index b218e0f8bdb3..c81fe89c4c46 100644
--- a/Documentation/ABI/testing/sysfs-class-net-mesh
+++ b/Documentation/ABI/testing/sysfs-class-net-mesh
@@ -14,6 +14,15 @@ Description:
                 mesh will be sent using multiple interfaces at the
                 same time (if available).
 
+What:           /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
+Date:           November 2011
+Contact:        Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
+Description:
+                Indicates whether the bridge loop avoidance feature
+                is enabled. This feature detects and avoids loops
+                between the mesh and devices bridged with the soft
+                interface <mesh_iface>.
+
 What:           /sys/class/net/<mesh_iface>/mesh/fragmentation
 Date:           October 2010
 Contact:        Andreas Langer <an.langer@gmx.de>
diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power
index 840f7d64d483..45000f0db4d4 100644
--- a/Documentation/ABI/testing/sysfs-devices-power
+++ b/Documentation/ABI/testing/sysfs-devices-power
@@ -96,16 +96,26 @@ Description:
                 is read-only.  If the device is not enabled to wake up the
                 system from sleep states, this attribute is not present.
 
-What:           /sys/devices/.../power/wakeup_hit_count
-Date:           September 2010
+What:           /sys/devices/.../power/wakeup_abort_count
+Date:           February 2012
 Contact:        Rafael J. Wysocki <rjw@sisk.pl>
 Description:
-                The /sys/devices/.../wakeup_hit_count attribute contains the
+                The /sys/devices/.../wakeup_abort_count attribute contains the
                 number of times the processing of a wakeup event associated with
-                the device might prevent the system from entering a sleep state.
-                This attribute is read-only.  If the device is not enabled to
-                wake up the system from sleep states, this attribute is not
-                present.
+                the device might have aborted system transition into a sleep
+                state in progress.  This attribute is read-only.  If the device
+                is not enabled to wake up the system from sleep states, this
+                attribute is not present.
+
+What:           /sys/devices/.../power/wakeup_expire_count
+Date:           February 2012
+Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Description:
+                The /sys/devices/.../wakeup_expire_count attribute contains the
+                number of times a wakeup event associated with the device has
+                been reported with a timeout that expired.  This attribute is
+                read-only.  If the device is not enabled to wake up the system
+                from sleep states, this attribute is not present.
 
 What:           /sys/devices/.../power/wakeup_active
 Date:           September 2010
@@ -148,6 +158,17 @@ Description:
                 not enabled to wake up the system from sleep states, this
                 attribute is not present.
 
+What:           /sys/devices/.../power/wakeup_prevent_sleep_time_ms
+Date:           February 2012
+Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Description:
+                The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
+                contains the total time the device has been preventing
+                opportunistic transitions to sleep states from occuring.
+                This attribute is read-only.  If the device is not enabled to
+                wake up the system from sleep states, this attribute is not
+                present.
+
 What:           /sys/devices/.../power/autosuspend_delay_ms
 Date:           September 2010
 Contact:        Alan Stern <stern@rowland.harvard.edu>
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index e7be75b96e4b..5dab36448b44 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -9,31 +9,6 @@ Description:
 
                 /sys/devices/system/cpu/cpu#/
 
-What:           /sys/devices/system/cpu/sched_mc_power_savings
-                /sys/devices/system/cpu/sched_smt_power_savings
-Date:           June 2006
-Contact:        Linux kernel mailing list <linux-kernel@vger.kernel.org>
-Description:    Discover and adjust the kernel's multi-core scheduler support.
-
-                Possible values are:
-
-                0 - No power saving load balance (default value)
-                1 - Fill one thread/core/package first for long running threads
-                2 - Also bias task wakeups to semi-idle cpu package for power
-                    savings
-
-                sched_mc_power_savings is dependent upon SCHED_MC, which is
-                itself architecture dependent.
-
-                sched_smt_power_savings is dependent upon SCHED_SMT, which
-                is itself architecture dependent.
-
-                The two files are independent of each other. It is possible
-                that one file may be present without the other.
-
-                Introduced by git commit 5c45bf27.
-
-
 What:           /sys/devices/system/cpu/kernel_max
                 /sys/devices/system/cpu/offline
                 /sys/devices/system/cpu/online
diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom
index 0130d6683c14..8d55a83d6921 100644
--- a/Documentation/ABI/testing/sysfs-driver-wacom
+++ b/Documentation/ABI/testing/sysfs-driver-wacom
@@ -9,15 +9,24 @@ Description:
                 or 0 otherwise. Writing to this file one of these values
                 switches reporting speed.
 
+What:           /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/
+Date:           May 2012
+Kernel Version: 3.5
+Contact:        linux-bluetooth@vger.kernel.org
+Description:
+                LED selector for Intuos4 WL. There are 4 leds, but only one LED
+                can be lit at a time. Max brightness is 127.
+
 What:           /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
 Date:           August 2011
 Contact:        linux-input@vger.kernel.org
 Description:
                 Attribute group for control of the status LEDs and the OLEDs.
                 This attribute group is only available for Intuos 4 M, L,
-                and XL (with LEDs and OLEDs) and Cintiq 21UX2 and Cintiq 24HD
-                (LEDs only). Therefore its presence implicitly signifies the
-                presence of said LEDs and OLEDs on the tablet device.
+                and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
+                21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
+                implicitly signifies the presence of said LEDs and OLEDs on the
+                tablet device.
 
 What:           /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
 Date:           August 2011
@@ -40,10 +49,10 @@ What:		/sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0
 Date:           August 2011
 Contact:        linux-input@vger.kernel.org
 Description:
-                Writing to this file sets which one of the four (for Intuos 4)
-                or of the right four (for Cintiq 21UX2 and Cintiq 24HD) status
-                LEDs is active (0..3). The other three LEDs on the same side are
-                always inactive.
+                Writing to this file sets which one of the four (for Intuos 4
+                and Intuos 5) or of the right four (for Cintiq 21UX2 and Cintiq
+                24HD) status LEDs is active (0..3). The other three LEDs on the
+                same side are always inactive.
 
 What:           /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
 Date:           September 2011
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index b464d12761ba..31725ffeeb3a 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -172,3 +172,62 @@ Description:
 
                 Reading from this file will display the current value, which is
                 set to 1 MB by default.
+
+What:           /sys/power/autosleep
+Date:           April 2012
+Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Description:
+                The /sys/power/autosleep file can be written one of the strings
+                returned by reads from /sys/power/state.  If that happens, a
+                work item attempting to trigger a transition of the system to
+                the sleep state represented by that string is queued up.  This
+                attempt will only succeed if there are no active wakeup sources
+                in the system at that time.  After every execution, regardless
+                of whether or not the attempt to put the system to sleep has
+                succeeded, the work item requeues itself until user space
+                writes "off" to /sys/power/autosleep.
+
+                Reading from this file causes the last string successfully
+                written to it to be returned.
+
+What:           /sys/power/wake_lock
+Date:           February 2012
+Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Description:
+                The /sys/power/wake_lock file allows user space to create
+                wakeup source objects and activate them on demand (if one of
+                those wakeup sources is active, reads from the
+                /sys/power/wakeup_count file block or return false).  When a
+                string without white space is written to /sys/power/wake_lock,
+                it will be assumed to represent a wakeup source name.  If there
+                is a wakeup source object with that name, it will be activated
+                (unless active already).  Otherwise, a new wakeup source object
+                will be registered, assigned the given name and activated.
+                If a string written to /sys/power/wake_lock contains white
+                space, the part of the string preceding the white space will be
+                regarded as a wakeup source name and handled as descrived above.
+                The other part of the string will be regarded as a timeout (in
+                nanoseconds) such that the wakeup source will be automatically
+                deactivated after it has expired.  The timeout, if present, is
+                set regardless of the current state of the wakeup source object
+                in question.
+
+                Reads from this file return a string consisting of the names of
+                wakeup sources created with the help of it that are active at
+                the moment, separated with spaces.
+
+
+What:           /sys/power/wake_unlock
+Date:           February 2012
+Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Description:
+                The /sys/power/wake_unlock file allows user space to deactivate
+                wakeup sources created with the help of /sys/power/wake_lock.
+                When a string is written to /sys/power/wake_unlock, it will be
+                assumed to represent the name of a wakeup source to deactivate.
+                If a wakeup source object of that name exists and is active at
+                the moment, it will be deactivated.
+
+                Reads from this file return a string consisting of the names of
+                wakeup sources created with the help of /sys/power/wake_lock
+                that are inactive at the moment, separated with spaces.
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index c58b236bbe04..cb9258b8fd35 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -671,8 +671,9 @@ ones already enabled by DEBUG.
                 Chapter 14: Allocating memory
 
 The kernel provides the following general purpose memory allocators:
-kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc().  Please refer to
-the API documentation for further information about them.
+kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and
+vzalloc().  Please refer to the API documentation for further information
+about them.
 
 The preferred form for passing a size of a struct is the following:
 
@@ -686,6 +687,17 @@ Casting the return value which is a void pointer is redundant. The conversion
 from void pointer to any other pointer type is guaranteed by the C programming
 language.
 
+The preferred form for allocating an array is the following:
+
+        p = kmalloc_array(n, sizeof(...), ...);
+
+The preferred form for allocating a zeroed array is the following:
+
+        p = kcalloc(n, sizeof(...), ...);
+
+Both forms check for overflow on the allocation size n * sizeof(...),
+and return NULL if that occurred.
+
 
                 Chapter 15: The inline disease
 
diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl
index c5ac6929c41c..f3e214f9e256 100644
--- a/Documentation/DocBook/80211.tmpl
+++ b/Documentation/DocBook/80211.tmpl
@@ -516,7 +516,7 @@
 !Finclude/net/mac80211.h ieee80211_start_tx_ba_cb_irqsafe
 !Finclude/net/mac80211.h ieee80211_stop_tx_ba_session
 !Finclude/net/mac80211.h ieee80211_stop_tx_ba_cb_irqsafe
-!Finclude/net/mac80211.h rate_control_changed
+!Finclude/net/mac80211.h ieee80211_rate_control_changed
 !Finclude/net/mac80211.h ieee80211_tx_rate_control
 !Finclude/net/mac80211.h rate_control_send_low
       </chapter>
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 66725a3d30dc..bc3d9f8c0a90 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -6,7 +6,7 @@
 # To add a new book the only step required is to add the book to the
 # list of DOCBOOKS.
 
-DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
+DOCBOOKS := z8530book.xml device-drivers.xml \
             kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
             writing_usb_driver.xml networking.xml \
             kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index 7160652a8736..00687ee9d363 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -212,19 +212,6 @@ X!Edrivers/pci/hotplug.c
      <sect1><title>PCI Hotplug Support Library</title>
 !Edrivers/pci/hotplug/pci_hotplug_core.c
      </sect1>
-     <sect1><title>MCA Architecture</title>
-        <sect2><title>MCA Device Functions</title>
-           <para>
-              Refer to the file arch/x86/kernel/mca_32.c for more information.
-           </para>
-<!-- FIXME: Removed for now since no structured comments in source
-X!Earch/x86/kernel/mca_32.c
--->
-        </sect2>
-        <sect2><title>MCA Bus DMA</title>
-!Iarch/x86/include/asm/mca_dma.h
-        </sect2>
-     </sect1>
   </chapter>
 
   <chapter id="firmware">
diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl
index 07a9c48de5a2..eee71426ecb8 100644
--- a/Documentation/DocBook/kernel-hacking.tmpl
+++ b/Documentation/DocBook/kernel-hacking.tmpl
@@ -1289,7 +1289,7 @@ static struct block_device_operations opt_fops = {
  * Sparc assembly will do this to ya.
  */
 C_LABEL(cputypvar):
-        .asciz "compatability"
+        .asciz "compatibility"
 
 /* Tested on SS-5, SS-10. Probably someone at Sun applied a spell-checker. */
         .align 4
diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl
index 31df1aa00710..deb71baed328 100644
--- a/Documentation/DocBook/libata.tmpl
+++ b/Documentation/DocBook/libata.tmpl
@@ -918,7 +918,7 @@ and other resources, etc.
         <title>HSM violation</title>
         <para>
         This error is indicated when STATUS value doesn't match HSM
-        requirement during issuing or excution any ATA/ATAPI command.
+        requirement during issuing or execution any ATA/ATAPI command.
         </para>
 
         <itemizedlist>
diff --git a/Documentation/DocBook/mcabook.tmpl b/Documentation/DocBook/mcabook.tmpl
deleted file mode 100644
index 467ccac6ec50..000000000000
--- a/Documentation/DocBook/mcabook.tmpl
+++ /dev/null
@@ -1,107 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
-        "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
-
-<book id="MCAGuide">
- <bookinfo>
-  <title>MCA Driver Programming Interface</title>
-  
-  <authorgroup>
-   <author>
-    <firstname>Alan</firstname>
-    <surname>Cox</surname>
-    <affiliation>
-     <address>
-      <email>alan@lxorguk.ukuu.org.uk</email>
-     </address>
-    </affiliation>
-   </author>
-   <author>
-    <firstname>David</firstname>
-    <surname>Weinehall</surname>
-   </author>
-   <author>
-    <firstname>Chris</firstname>
-    <surname>Beauregard</surname>
-   </author>
-  </authorgroup>
-
-  <copyright>
-   <year>2000</year>
-   <holder>Alan Cox</holder>
-   <holder>David Weinehall</holder>
-   <holder>Chris Beauregard</holder>
-  </copyright>
-
-  <legalnotice>
-   <para>
-     This documentation 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.
-   </para>
-      
-   <para>
-     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.
-   </para>
-      
-   <para>
-     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., 59 Temple Place, Suite 330, Boston,
-     MA 02111-1307 USA
-   </para>
-      
-   <para>
-     For more details see the file COPYING in the source
-     distribution of Linux.
-   </para>
-  </legalnotice>
- </bookinfo>
-
-<toc></toc>
-
-  <chapter id="intro">
-      <title>Introduction</title>
-  <para>
-        The MCA bus functions provide a generalised interface to find MCA
-        bus cards, to claim them for a driver, and to read and manipulate POS 
-        registers without being aware of the motherboard internals or 
-        certain deep magic specific to onboard devices.
-  </para>
-  <para>
-        The basic interface to the MCA bus devices is the slot. Each slot
-        is numbered and virtual slot numbers are assigned to the internal
-        devices. Using a pci_dev as other busses do does not really make
-        sense in the MCA context as the MCA bus resources require card
-        specific interpretation.
-  </para>
-  <para>
-        Finally the MCA bus functions provide a parallel set of DMA
-        functions mimicing the ISA bus DMA functions as closely as possible,
-        although also supporting the additional DMA functionality on the
-        MCA bus controllers.
-  </para>
-  </chapter>
-  <chapter id="bugs">
-     <title>Known Bugs And Assumptions</title>
-  <para>
-        None.   
-  </para>
-  </chapter>
-
-  <chapter id="pubfunctions">
-     <title>Public Functions Provided</title>
-!Edrivers/mca/mca-legacy.c
-  </chapter>
-
-  <chapter id="dmafunctions">
-     <title>DMA Functions Provided</title>
-!Iarch/x86/include/asm/mca_dma.h
-  </chapter>
-
-</book>
diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile
index 6628b4b9cac4..362520992ced 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -70,6 +70,8 @@ IOCTLS = \
         VIDIOC_SUBDEV_ENUM_MBUS_CODE \
         VIDIOC_SUBDEV_ENUM_FRAME_SIZE \
         VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL \
+        VIDIOC_SUBDEV_G_SELECTION \
+        VIDIOC_SUBDEV_S_SELECTION \
 
 TYPES = \
         $(shell perl -ne 'print "$$1 " if /^typedef\s+[^\s]+\s+([^\s]+)\;/' $(srctree)/include/linux/videodev2.h) \
@@ -193,7 +195,7 @@ DVB_DOCUMENTED = \
 #
 
 install_media_images = \
-        $(Q)cp $(OBJIMGFILES) $(MEDIA_OBJ_DIR)/media_api
+        $(Q)cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
 
 $(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64
         $(Q)base64 -d $< >$@
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml
index c7a4ca517859..e633c097a8d1 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -531,6 +531,139 @@ typedef enum fe_delivery_system {
                                 here are referring to what can be found in the TMCC-structure -
                                 independent of the mode.</para>
                 </section>
+                <section id="DTV-ATSCMH-FIC-VER">
+                        <title><constant>DTV_ATSCMH_FIC_VER</constant></title>
+                        <para>Version number of the FIC (Fast Information Channel) signaling data.</para>
+                        <para>FIC is used for relaying information to allow rapid service acquisition by the receiver.</para>
+                        <para>Possible values: 0, 1, 2, 3, ..., 30, 31</para>
+                </section>
+                <section id="DTV-ATSCMH-PARADE-ID">
+                        <title><constant>DTV_ATSCMH_PARADE_ID</constant></title>
+                        <para>Parade identification number</para>
+                        <para>A parade is a collection of up to eight MH groups, conveying one or two ensembles.</para>
+                        <para>Possible values: 0, 1, 2, 3, ..., 126, 127</para>
+                </section>
+                <section id="DTV-ATSCMH-NOG">
+                        <title><constant>DTV_ATSCMH_NOG</constant></title>
+                        <para>Number of MH groups per MH subframe for a designated parade.</para>
+                        <para>Possible values: 1, 2, 3, 4, 5, 6, 7, 8</para>
+                </section>
+                <section id="DTV-ATSCMH-TNOG">
+                        <title><constant>DTV_ATSCMH_TNOG</constant></title>
+                        <para>Total number of MH groups including all MH groups belonging to all MH parades in one MH subframe.</para>
+                        <para>Possible values: 0, 1, 2, 3, ..., 30, 31</para>
+                </section>
+                <section id="DTV-ATSCMH-SGN">
+                        <title><constant>DTV_ATSCMH_SGN</constant></title>
+                        <para>Start group number.</para>
+                        <para>Possible values: 0, 1, 2, 3, ..., 14, 15</para>
+                </section>
+                <section id="DTV-ATSCMH-PRC">
+                        <title><constant>DTV_ATSCMH_PRC</constant></title>
+                        <para>Parade repetition cycle.</para>
+                        <para>Possible values: 1, 2, 3, 4, 5, 6, 7, 8</para>
+                </section>
+                <section id="DTV-ATSCMH-RS-FRAME-MODE">
+                        <title><constant>DTV_ATSCMH_RS_FRAME_MODE</constant></title>
+                        <para>RS frame mode.</para>
+                        <para>Possible values are:</para>
+<programlisting>
+typedef enum atscmh_rs_frame_mode {
+        ATSCMH_RSFRAME_PRI_ONLY  = 0,
+        ATSCMH_RSFRAME_PRI_SEC   = 1,
+} atscmh_rs_frame_mode_t;
+</programlisting>
+                </section>
+                <section id="DTV-ATSCMH-RS-FRAME-ENSEMBLE">
+                        <title><constant>DTV_ATSCMH_RS_FRAME_ENSEMBLE</constant></title>
+                        <para>RS frame ensemble.</para>
+                        <para>Possible values are:</para>
+<programlisting>
+typedef enum atscmh_rs_frame_ensemble {
+        ATSCMH_RSFRAME_ENS_PRI   = 0,
+        ATSCMH_RSFRAME_ENS_SEC   = 1,
+} atscmh_rs_frame_ensemble_t;
+</programlisting>
+                </section>
+                <section id="DTV-ATSCMH-RS-CODE-MODE-PRI">
+                        <title><constant>DTV_ATSCMH_RS_CODE_MODE_PRI</constant></title>
+                        <para>RS code mode (primary).</para>
+                        <para>Possible values are:</para>
+<programlisting>
+typedef enum atscmh_rs_code_mode {
+        ATSCMH_RSCODE_211_187    = 0,
+        ATSCMH_RSCODE_223_187    = 1,
+        ATSCMH_RSCODE_235_187    = 2,
+} atscmh_rs_code_mode_t;
+</programlisting>
+                </section>
+                <section id="DTV-ATSCMH-RS-CODE-MODE-SEC">
+                        <title><constant>DTV_ATSCMH_RS_CODE_MODE_SEC</constant></title>
+                        <para>RS code mode (secondary).</para>
+                        <para>Possible values are:</para>
+<programlisting>
+typedef enum atscmh_rs_code_mode {
+        ATSCMH_RSCODE_211_187    = 0,
+        ATSCMH_RSCODE_223_187    = 1,
+        ATSCMH_RSCODE_235_187    = 2,
+} atscmh_rs_code_mode_t;
+</programlisting>
+                </section>
+                <section id="DTV-ATSCMH-SCCC-BLOCK-MODE">
+                        <title><constant>DTV_ATSCMH_SCCC_BLOCK_MODE</constant></title>
+                        <para>Series Concatenated Convolutional Code Block Mode.</para>
+                        <para>Possible values are:</para>
+<programlisting>
+typedef enum atscmh_sccc_block_mode {
+        ATSCMH_SCCC_BLK_SEP      = 0,
+        ATSCMH_SCCC_BLK_COMB     = 1,
+} atscmh_sccc_block_mode_t;
+</programlisting>
+                </section>
+                <section id="DTV-ATSCMH-SCCC-CODE-MODE-A">
+                        <title><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></title>
+                        <para>Series Concatenated Convolutional Code Rate.</para>
+                        <para>Possible values are:</para>
+<programlisting>
+typedef enum atscmh_sccc_code_mode {
+        ATSCMH_SCCC_CODE_HLF     = 0,
+        ATSCMH_SCCC_CODE_QTR     = 1,
+} atscmh_sccc_code_mode_t;
+</programlisting>
+                </section>
+                <section id="DTV-ATSCMH-SCCC-CODE-MODE-B">
+                        <title><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></title>
+                        <para>Series Concatenated Convolutional Code Rate.</para>
+                        <para>Possible values are:</para>
+<programlisting>
+typedef enum atscmh_sccc_code_mode {
+        ATSCMH_SCCC_CODE_HLF     = 0,
+        ATSCMH_SCCC_CODE_QTR     = 1,
+} atscmh_sccc_code_mode_t;
+</programlisting>
+                </section>
+                <section id="DTV-ATSCMH-SCCC-CODE-MODE-C">
+                        <title><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></title>
+                        <para>Series Concatenated Convolutional Code Rate.</para>
+                        <para>Possible values are:</para>
+<programlisting>
+typedef enum atscmh_sccc_code_mode {
+        ATSCMH_SCCC_CODE_HLF     = 0,
+        ATSCMH_SCCC_CODE_QTR     = 1,
+} atscmh_sccc_code_mode_t;
+</programlisting>
+                </section>
+                <section id="DTV-ATSCMH-SCCC-CODE-MODE-D">
+                        <title><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></title>
+                        <para>Series Concatenated Convolutional Code Rate.</para>
+                        <para>Possible values are:</para>
+<programlisting>
+typedef enum atscmh_sccc_code_mode {
+        ATSCMH_SCCC_CODE_HLF     = 0,
+        ATSCMH_SCCC_CODE_QTR     = 1,
+} atscmh_sccc_code_mode_t;
+</programlisting>
+                </section>
         </section>
         <section id="DTV-API-VERSION">
         <title><constant>DTV_API_VERSION</constant></title>
@@ -774,6 +907,33 @@ typedef enum fe_hierarchy {
                                 <listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
                         </itemizedlist>
                 </section>
+                <section id="atscmh-params">
+                        <title>ATSC-MH delivery system</title>
+                        <para>The following parameters are valid for ATSC-MH:</para>
+                        <itemizedlist mark='opencircle'>
+                                <listitem><para><link linkend="DTV-API-VERSION"><constant>DTV_API_VERSION</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-DELIVERY-SYSTEM"><constant>DTV_DELIVERY_SYSTEM</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-TUNE"><constant>DTV_TUNE</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-CLEAR"><constant>DTV_CLEAR</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-FIC-VER"><constant>DTV_ATSCMH_FIC_VER</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-PARADE-ID"><constant>DTV_ATSCMH_PARADE_ID</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-NOG"><constant>DTV_ATSCMH_NOG</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-TNOG"><constant>DTV_ATSCMH_TNOG</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-SGN"><constant>DTV_ATSCMH_SGN</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-PRC"><constant>DTV_ATSCMH_PRC</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-RS-FRAME-MODE"><constant>DTV_ATSCMH_RS_FRAME_MODE</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-RS-FRAME-ENSEMBLE"><constant>DTV_ATSCMH_RS_FRAME_ENSEMBLE</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-CODE-MODE-PRI"><constant>DTV_ATSCMH_CODE_MODE_PRI</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-CODE-MODE-SEC"><constant>DTV_ATSCMH_CODE_MODE_SEC</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-SCCC-BLOCK-MODE"><constant>DTV_ATSCMH_SCCC_BLOCK_MODE</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-A"><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-B"><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
+                                <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
+                        </itemizedlist>
+                </section>
         </section>
         <section id="frontend-property-cable-systems">
         <title>Properties used on cable delivery systems</title>
diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml
index 7dc65c592a87..7c49facecd25 100644
--- a/Documentation/DocBook/media/v4l/biblio.xml
+++ b/Documentation/DocBook/media/v4l/biblio.xml
@@ -197,4 +197,33 @@ in the frequency range from 87,5 to 108,0 MHz</title>
       <title>NTSC-4: United States RBDS Standard</title>
     </biblioentry>
 
+    <biblioentry id="iso12232">
+      <abbrev>ISO&nbsp;12232:2006</abbrev>
+      <authorgroup>
+        <corpauthor>International Organization for Standardization
+(<ulink url="http://www.iso.org">http://www.iso.org</ulink>)</corpauthor>
+      </authorgroup>
+      <title>Photography &mdash; Digital still cameras &mdash; Determination
+      of exposure index, ISO speed ratings, standard output sensitivity, and
+      recommended exposure index</title>
+    </biblioentry>
+
+    <biblioentry id="cea861">
+      <abbrev>CEA-861-E</abbrev>
+      <authorgroup>
+        <corpauthor>Consumer Electronics Association
+(<ulink url="http://www.ce.org">http://www.ce.org</ulink>)</corpauthor>
+      </authorgroup>
+      <title>A DTV Profile for Uncompressed High Speed Digital Interfaces</title>
+    </biblioentry>
+
+    <biblioentry id="vesadmt">
+      <abbrev>VESA&nbsp;DMT</abbrev>
+      <authorgroup>
+        <corpauthor>Video Electronics Standards Association
+(<ulink url="http://www.vesa.org">http://www.vesa.org</ulink>)</corpauthor>
+      </authorgroup>
+      <title>VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT)</title>
+    </biblioentry>
+
   </bibliography>
diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml
index c79278acfb0e..4101aeb56540 100644
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -724,41 +724,49 @@ if (-1 == ioctl (fd, &VIDIOC-S-STD;, &amp;std_id)) {
 }
       </programlisting>
     </example>
+  </section>
   <section id="dv-timings">
         <title>Digital Video (DV) Timings</title>
         <para>
-        The video standards discussed so far has been dealing with Analog TV and the
+        The video standards discussed so far have been dealing with Analog TV and the
 corresponding video timings. Today there are many more different hardware interfaces
 such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry
 video signals and there is a need to extend the API to select the video timings
 for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to
-the limited bits available, a new set of IOCTLs is added to set/get video timings at
+the limited bits available, a new set of IOCTLs was added to set/get video timings at
 the input and output: </para><itemizedlist>
         <listitem>
-        <para>DV Presets: Digital Video (DV) presets. These are IDs representing a
+        <para>DV Timings: This will allow applications to define detailed
+video timings for the interface. This includes parameters such as width, height,
+polarities, frontporch, backporch etc. The <filename>linux/v4l2-dv-timings.h</filename>
+header can be used to get the timings of the formats in the <xref linkend="cea861" /> and
+<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.</para>
-        </listitem>
-        <listitem>
-        <para>Custom DV Timings: This will allow applications to define more detailed
-custom video timings for the interface. This includes parameters such as width, height,
-polarities, frontporch, backporch etc.
-        </para>
+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.
+        To set DV timings for the device, applications use the
+&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.</para>
-        <para>To set custom DV timings for the device, applications use the
-&VIDIOC-S-DV-TIMINGS; ioctl and to get current custom DV timings they use the
-&VIDIOC-G-DV-TIMINGS; ioctl.</para>
+&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>
-        </section>
   </section>
 
   &sub-controls;
diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
index bce97c50391b..ea42ef824948 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2407,6 +2407,54 @@ details.</para>
           <para>Added <link linkend="jpeg-controls">JPEG compression control
           class</link>.</para>
         </listitem>
+        <listitem>
+          <para>Extended the DV Timings API:
+          &VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and
+          &VIDIOC-DV-TIMINGS-CAP;.</para>
+        </listitem>
+      </orderedlist>
+    </section>
+
+    <section>
+      <title>V4L2 in Linux 3.5</title>
+      <orderedlist>
+        <listitem>
+          <para>Added integer menus, the new type will be
+          V4L2_CTRL_TYPE_INTEGER_MENU.</para>
+        </listitem>
+        <listitem>
+          <para>Added selection API for V4L2 subdev interface:
+          &VIDIOC-SUBDEV-G-SELECTION; and
+          &VIDIOC-SUBDEV-S-SELECTION;.</para>
+        </listitem>
+        <listitem>
+          <para> Added <constant>V4L2_COLORFX_ANTIQUE</constant>,
+          <constant>V4L2_COLORFX_ART_FREEZE</constant>,
+          <constant>V4L2_COLORFX_AQUA</constant>,
+          <constant>V4L2_COLORFX_SILHOUETTE</constant>,
+          <constant>V4L2_COLORFX_SOLARIZATION</constant>,
+          <constant>V4L2_COLORFX_VIVID</constant> and
+          <constant>V4L2_COLORFX_ARBITRARY_CBCR</constant> menu items
+          to the <constant>V4L2_CID_COLORFX</constant> control.</para>
+        </listitem>
+        <listitem>
+          <para> Added <constant>V4L2_CID_COLORFX_CBCR</constant> control.</para>
+        </listitem>
+        <listitem>
+          <para> Added camera controls <constant>V4L2_CID_AUTO_EXPOSURE_BIAS</constant>,
+          <constant>V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE</constant>,
+          <constant>V4L2_CID_IMAGE_STABILIZATION</constant>,
+          <constant>V4L2_CID_ISO_SENSITIVITY</constant>,
+          <constant>V4L2_CID_ISO_SENSITIVITY_AUTO</constant>,
+          <constant>V4L2_CID_EXPOSURE_METERING</constant>,
+          <constant>V4L2_CID_SCENE_MODE</constant>,
+          <constant>V4L2_CID_3A_LOCK</constant>,
+          <constant>V4L2_CID_AUTO_FOCUS_START</constant>,
+          <constant>V4L2_CID_AUTO_FOCUS_STOP</constant>,
+          <constant>V4L2_CID_AUTO_FOCUS_STATUS</constant> and
+          <constant>V4L2_CID_AUTO_FOCUS_RANGE</constant>.
+          </para>
+        </listitem>
       </orderedlist>
     </section>
 
@@ -2508,6 +2556,10 @@ and may change in the future.</para>
 ioctls.</para>
         </listitem>
         <listitem>
+          <para>&VIDIOC-DECODER-CMD; and &VIDIOC-TRY-DECODER-CMD;
+ioctls.</para>
+        </listitem>
+        <listitem>
           <para>&VIDIOC-DBG-G-REGISTER; and &VIDIOC-DBG-S-REGISTER;
 ioctls.</para>
         </listitem>
@@ -2515,6 +2567,10 @@ ioctls.</para>
           <para>&VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para>
         </listitem>
         <listitem>
+          <para>&VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and
+          &VIDIOC-DV-TIMINGS-CAP; ioctls.</para>
+        </listitem>
+        <listitem>
           <para>Flash API. <xref linkend="flash-controls" /></para>
         </listitem>
         <listitem>
@@ -2523,6 +2579,14 @@ ioctls.</para>
         <listitem>
           <para>Selection API. <xref linkend="selection-api" /></para>
         </listitem>
+        <listitem>
+          <para>Sub-device selection API: &VIDIOC-SUBDEV-G-SELECTION;
+          and &VIDIOC-SUBDEV-S-SELECTION; ioctls.</para>
+        </listitem>
+        <listitem>
+          <para><link linkend="v4l2-auto-focus-area"><constant>
+          V4L2_CID_AUTO_FOCUS_AREA</constant></link> control.</para>
+        </listitem>
       </itemizedlist>
     </section>
 
@@ -2538,6 +2602,17 @@ interfaces and should not be implemented in new drivers.</para>
 <constant>VIDIOC_S_MPEGCOMP</constant> ioctls. Use Extended Controls,
 <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>
+        </listitem>
+        <listitem>
+          <para><constant>VIDIOC_SUBDEV_G_CROP</constant> and
+          <constant>VIDIOC_SUBDEV_S_CROP</constant> ioctls. Use
+          <constant>VIDIOC_SUBDEV_G_SELECTION</constant> and
+          <constant>VIDIOC_SUBDEV_S_SELECTION</constant>, <xref
+          linkend="vidioc-subdev-g-selection" />.</para>
+        </listitem>
       </itemizedlist>
     </section>
   </section>
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index b84f25e9cc87..cda0dfb6769a 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -285,18 +285,92 @@ minimum value disables backlight compensation.</entry>
           <row id="v4l2-colorfx">
             <entry><constant>V4L2_CID_COLORFX</constant></entry>
             <entry>enum</entry>
-            <entry>Selects a color effect. Possible values for
-<constant>enum v4l2_colorfx</constant> are:
-<constant>V4L2_COLORFX_NONE</constant> (0),
-<constant>V4L2_COLORFX_BW</constant> (1),
-<constant>V4L2_COLORFX_SEPIA</constant> (2),
-<constant>V4L2_COLORFX_NEGATIVE</constant> (3),
-<constant>V4L2_COLORFX_EMBOSS</constant> (4),
-<constant>V4L2_COLORFX_SKETCH</constant> (5),
-<constant>V4L2_COLORFX_SKY_BLUE</constant> (6),
-<constant>V4L2_COLORFX_GRASS_GREEN</constant> (7),
-<constant>V4L2_COLORFX_SKIN_WHITEN</constant> (8) and
-<constant>V4L2_COLORFX_VIVID</constant> (9).</entry>
+            <entry>Selects a color effect. The following values are defined:
+            </entry>
+          </row><row>
+          <entry></entry>
+          <entry></entry>
+            <entrytbl spanname="descr" cols="2">
+              <tbody valign="top">
+                <row>
+                  <entry><constant>V4L2_COLORFX_NONE</constant>&nbsp;</entry>
+                  <entry>Color effect is disabled.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_ANTIQUE</constant>&nbsp;</entry>
+                  <entry>An aging (old photo) effect.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_ART_FREEZE</constant>&nbsp;</entry>
+                  <entry>Frost color effect.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_AQUA</constant>&nbsp;</entry>
+                  <entry>Water color, cool tone.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_BW</constant>&nbsp;</entry>
+                  <entry>Black and white.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_EMBOSS</constant>&nbsp;</entry>
+                  <entry>Emboss, the highlights and shadows replace light/dark boundaries
+                  and low contrast areas are set to a gray background.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_GRASS_GREEN</constant>&nbsp;</entry>
+                  <entry>Grass green.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_NEGATIVE</constant>&nbsp;</entry>
+                  <entry>Negative.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_SEPIA</constant>&nbsp;</entry>
+                  <entry>Sepia tone.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_SKETCH</constant>&nbsp;</entry>
+                  <entry>Sketch.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_SKIN_WHITEN</constant>&nbsp;</entry>
+                  <entry>Skin whiten.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_SKY_BLUE</constant>&nbsp;</entry>
+                  <entry>Sky blue.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_SOLARIZATION</constant>&nbsp;</entry>
+                  <entry>Solarization, the image is partially reversed in tone,
+                  only color values above or below a certain threshold are inverted.
+                  </entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_SILHOUETTE</constant>&nbsp;</entry>
+                  <entry>Silhouette (outline).</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_VIVID</constant>&nbsp;</entry>
+                  <entry>Vivid colors.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_COLORFX_SET_CBCR</constant>&nbsp;</entry>
+                  <entry>The Cb and Cr chroma components are replaced by fixed
+                  coefficients determined by <constant>V4L2_CID_COLORFX_CBCR</constant>
+                  control.</entry>
+                </row>
+              </tbody>
+            </entrytbl>
+          </row>
+          <row>
+            <entry><constant>V4L2_CID_COLORFX_CBCR</constant></entry>
+            <entry>integer</entry>
+            <entry>Determines the Cb and Cr coefficients for <constant>V4L2_COLORFX_SET_CBCR</constant>
+            color effect. Bits [7:0] of the supplied 32 bit value are interpreted as
+            Cr component, bits [15:8] as Cb component and bits [31:16] must be zero.
+          </entry>
           </row>
           <row>
             <entry><constant>V4L2_CID_ROTATE</constant></entry>
@@ -2023,7 +2097,7 @@ Possible values are:</entry>
                 <entry>integer</entry>
               </row>
               <row><entry spanname="descr">Cyclic intra macroblock refresh. This is the number of continuous macroblocks
-refreshed every frame. Each frame a succesive set of macroblocks is refreshed until the cycle completes and starts from the
+refreshed every frame. Each frame a successive set of macroblocks is refreshed until the cycle completes and starts from the
 top of the frame. Applicable to H264, H263 and MPEG4 encoder.</entry>
               </row>
 
@@ -2183,7 +2257,7 @@ Applicable to the MPEG4 and H264 encoders.</entry>
                 <entry>integer</entry>
               </row>
               <row><entry spanname="descr">The Video Buffer Verifier size in kilobytes, it is used as a limitation of frame skip.
-The VBV is defined in the standard as a mean to verify that the produced stream will be succesfully decoded.
+The VBV is defined in the standard as a mean to verify that the produced stream will be successfully decoded.
 The standard describes it as "Part of a hypothetical decoder that is conceptually connected to the
 output of the encoder. Its purpose is to provide a constraint on the variability of the data rate that an
 encoder or editing process may produce.".
@@ -2196,7 +2270,7 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
                 <entry>integer</entry>
               </row>
               <row><entry spanname="descr">The Coded Picture Buffer size in kilobytes, it is used as a limitation of frame skip.
-The CPB is defined in the H264 standard as a mean to verify that the produced stream will be succesfully decoded.
+The CPB is defined in the H264 standard as a mean to verify that the produced stream will be successfully decoded.
 Applicable to the H264 encoder.</entry>
               </row>
 
@@ -2775,6 +2849,51 @@ remain constant.</entry>
           <row><entry></entry></row>
 
           <row>
+            <entry spanname="id"><constant>V4L2_CID_EXPOSURE_BIAS</constant>&nbsp;</entry>
+            <entry>integer menu</entry>
+          </row><row><entry spanname="descr"> Determines the automatic
+exposure compensation, it is effective only when <constant>V4L2_CID_EXPOSURE_AUTO</constant>
+control is set to <constant>AUTO</constant>, <constant>SHUTTER_PRIORITY </constant>
+or <constant>APERTURE_PRIORITY</constant>.
+It is expressed in terms of EV, drivers should interpret the values as 0.001 EV
+units, where the value 1000 stands for +1 EV.
+<para>Increasing the exposure compensation value is equivalent to decreasing
+the exposure value (EV) and will increase the amount of light at the image
+sensor. The camera performs the exposure compensation by adjusting absolute
+exposure time and/or aperture.</para></entry>
+          </row>
+          <row><entry></entry></row>
+
+          <row id="v4l2-exposure-metering">
+            <entry spanname="id"><constant>V4L2_CID_EXPOSURE_METERING</constant>&nbsp;</entry>
+            <entry>enum&nbsp;v4l2_exposure_metering</entry>
+          </row><row><entry spanname="descr">Determines how the camera measures
+the amount of light available for the frame exposure. Possible values are:</entry>
+          </row>
+          <row>
+            <entrytbl spanname="descr" cols="2">
+              <tbody valign="top">
+                <row>
+                  <entry><constant>V4L2_EXPOSURE_METERING_AVERAGE</constant>&nbsp;</entry>
+                  <entry>Use the light information coming from the entire frame
+and average giving no weighting to any particular portion of the metered area.
+                  </entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_EXPOSURE_METERING_CENTER_WEIGHTED</constant>&nbsp;</entry>
+                  <entry>Average the light information coming from the entire frame
+giving priority to the center of the metered area.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_EXPOSURE_METERING_SPOT</constant>&nbsp;</entry>
+                  <entry>Measure only very small area at the center of the frame.</entry>
+                </row>
+              </tbody>
+            </entrytbl>
+          </row>
+          <row><entry></entry></row>
+
+          <row>
             <entry spanname="id"><constant>V4L2_CID_PAN_RELATIVE</constant>&nbsp;</entry>
             <entry>integer</entry>
           </row><row><entry spanname="descr">This control turns the
@@ -2857,13 +2976,107 @@ negative values towards infinity. This is a write-only control.</entry>
           <row>
             <entry spanname="id"><constant>V4L2_CID_FOCUS_AUTO</constant>&nbsp;</entry>
             <entry>boolean</entry>
-          </row><row><entry spanname="descr">Enables automatic focus
-adjustments. The effect of manual focus adjustments while this feature
+          </row><row><entry spanname="descr">Enables continuous automatic
+focus adjustments. The effect of manual focus adjustments while this feature
 is enabled is undefined, drivers should ignore such requests.</entry>
           </row>
           <row><entry></entry></row>
 
           <row>
+            <entry spanname="id"><constant>V4L2_CID_AUTO_FOCUS_START</constant>&nbsp;</entry>
+            <entry>button</entry>
+          </row><row><entry spanname="descr">Starts single auto focus process.
+The effect of setting this control when <constant>V4L2_CID_FOCUS_AUTO</constant>
+is set to <constant>TRUE</constant> (1) is undefined, drivers should ignore
+such requests.</entry>
+          </row>
+          <row><entry></entry></row>
+
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_AUTO_FOCUS_STOP</constant>&nbsp;</entry>
+            <entry>button</entry>
+          </row><row><entry spanname="descr">Aborts automatic focusing
+started with <constant>V4L2_CID_AUTO_FOCUS_START</constant> control. It is
+effective only when the continuous autofocus is disabled, that is when
+<constant>V4L2_CID_FOCUS_AUTO</constant> control is set to <constant>FALSE
+</constant> (0).</entry>
+          </row>
+          <row><entry></entry></row>
+
+          <row id="v4l2-auto-focus-status">
+            <entry spanname="id">
+              <constant>V4L2_CID_AUTO_FOCUS_STATUS</constant>&nbsp;</entry>
+            <entry>bitmask</entry>
+          </row>
+          <row><entry spanname="descr">The automatic focus status. This is a read-only
+          control.</entry>
+          </row>
+          <row>
+            <entrytbl spanname="descr" cols="2">
+              <tbody valign="top">
+                <row>
+                  <entry><constant>V4L2_AUTO_FOCUS_STATUS_IDLE</constant>&nbsp;</entry>
+                  <entry>Automatic focus is not active.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_AUTO_FOCUS_STATUS_BUSY</constant>&nbsp;</entry>
+                  <entry>Automatic focusing is in progress.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_AUTO_FOCUS_STATUS_REACHED</constant>&nbsp;</entry>
+                  <entry>Focus has been reached.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_AUTO_FOCUS_STATUS_FAILED</constant>&nbsp;</entry>
+                  <entry>Automatic focus has failed, the driver will not
+                  transition from this state until another action is
+                  performed by an application.</entry>
+                </row>
+              </tbody>
+            </entrytbl>
+          </row>
+          <row><entry spanname="descr">
+Setting <constant>V4L2_LOCK_FOCUS</constant> lock bit of the <constant>V4L2_CID_3A_LOCK
+</constant> control may stop updates of the <constant>V4L2_CID_AUTO_FOCUS_STATUS</constant>
+control value.</entry>
+          </row>
+          <row><entry></entry></row>
+
+          <row id="v4l2-auto-focus-range">
+            <entry spanname="id">
+              <constant>V4L2_CID_AUTO_FOCUS_RANGE</constant>&nbsp;</entry>
+            <entry>enum&nbsp;v4l2_auto_focus_range</entry>
+          </row>
+          <row><entry spanname="descr">Determines auto focus distance range
+for which lens may be adjusted. </entry>
+          </row>
+          <row>
+            <entrytbl spanname="descr" cols="2">
+              <tbody valign="top">
+                <row>
+                  <entry><constant>V4L2_AUTO_FOCUS_RANGE_AUTO</constant>&nbsp;</entry>
+                  <entry>The camera automatically selects the focus range.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_AUTO_FOCUS_RANGE_NORMAL</constant>&nbsp;</entry>
+                  <entry>Normal distance range, limited for best automatic focus
+performance.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_AUTO_FOCUS_RANGE_MACRO</constant>&nbsp;</entry>
+                  <entry>Macro (close-up) auto focus. The camera will
+use its minimum possible distance for auto focus.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_AUTO_FOCUS_RANGE_INFINITY</constant>&nbsp;</entry>
+                  <entry>The lens is set to focus on an object at infinite distance.</entry>
+                </row>
+              </tbody>
+            </entrytbl>
+          </row>
+          <row><entry></entry></row>
+
+          <row>
             <entry spanname="id"><constant>V4L2_CID_ZOOM_ABSOLUTE</constant>&nbsp;</entry>
             <entry>integer</entry>
           </row><row><entry spanname="descr">Specify the objective lens
@@ -2932,6 +3145,295 @@ camera sensor on or off, or specify its strength. Such band-stop filters can
 be used, for example, to filter out the fluorescent light component.</entry>
           </row>
           <row><entry></entry></row>
+
+          <row id="v4l2-auto-n-preset-white-balance">
+            <entry spanname="id"><constant>V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE</constant>&nbsp;</entry>
+            <entry>enum&nbsp;v4l2_auto_n_preset_white_balance</entry>
+          </row><row><entry spanname="descr">Sets white balance to automatic,
+manual or a preset. The presets determine color temperature of the light as
+a hint to the camera for white balance adjustments resulting in most accurate
+color representation. The following white balance presets are listed in order
+of increasing color temperature.</entry>
+          </row>
+          <row>
+            <entrytbl spanname="descr" cols="2">
+              <tbody valign="top">
+                <row>
+                  <entry><constant>V4L2_WHITE_BALANCE_MANUAL</constant>&nbsp;</entry>
+                  <entry>Manual white balance.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_WHITE_BALANCE_AUTO</constant>&nbsp;</entry>
+                  <entry>Automatic white balance adjustments.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_WHITE_BALANCE_INCANDESCENT</constant>&nbsp;</entry>
+                  <entry>White balance setting for incandescent (tungsten) lighting.
+It generally cools down the colors and corresponds approximately to 2500...3500 K
+color temperature range.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_WHITE_BALANCE_FLUORESCENT</constant>&nbsp;</entry>
+                  <entry>White balance preset for fluorescent lighting.
+It corresponds approximately to 4000...5000 K color temperature.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_WHITE_BALANCE_FLUORESCENT_H</constant>&nbsp;</entry>
+                  <entry>With this setting the camera will compensate for
+fluorescent H lighting.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_WHITE_BALANCE_HORIZON</constant>&nbsp;</entry>
+                  <entry>White balance setting for horizon daylight.
+It corresponds approximately to 5000 K color temperature.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_WHITE_BALANCE_DAYLIGHT</constant>&nbsp;</entry>
+                  <entry>White balance preset for daylight (with clear sky).
+It corresponds approximately to 5000...6500 K color temperature.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_WHITE_BALANCE_FLASH</constant>&nbsp;</entry>
+                  <entry>With this setting the camera will compensate for the flash
+light. It slightly warms up the colors and corresponds roughly to 5000...5500 K
+color temperature.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_WHITE_BALANCE_CLOUDY</constant>&nbsp;</entry>
+                  <entry>White balance preset for moderately overcast sky.
+This option corresponds approximately to 6500...8000 K color temperature
+range.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_WHITE_BALANCE_SHADE</constant>&nbsp;</entry>
+                  <entry>White balance preset for shade or heavily overcast
+sky. It corresponds approximately to 9000...10000 K color temperature.
+</entry>
+                </row>
+              </tbody>
+            </entrytbl>
+          </row>
+          <row><entry></entry></row>
+
+          <row id="v4l2-wide-dynamic-range">
+            <entry spanname="id"><constant>V4L2_CID_WIDE_DYNAMIC_RANGE</constant></entry>
+            <entry>boolean</entry>
+          </row>
+          <row>
+            <entry spanname="descr">Enables or disables the camera's wide dynamic
+range feature. This feature allows to obtain clear images in situations where
+intensity of the illumination varies significantly throughout the scene, i.e.
+there are simultaneously very dark and very bright areas. It is most commonly
+realized in cameras by combining two subsequent frames with different exposure
+times. <footnote id="ctypeconv"><para> This control may be changed to a menu
+control in the future, if more options are required.</para></footnote></entry>
+          </row>
+          <row><entry></entry></row>
+
+          <row id="v4l2-image-stabilization">
+            <entry spanname="id"><constant>V4L2_CID_IMAGE_STABILIZATION</constant></entry>
+            <entry>boolean</entry>
+          </row>
+          <row>
+            <entry spanname="descr">Enables or disables image stabilization.
+              <footnoteref linkend="ctypeconv"/></entry>
+          </row>
+          <row><entry></entry></row>
+
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_ISO_SENSITIVITY</constant>&nbsp;</entry>
+            <entry>integer menu</entry>
+          </row><row><entry spanname="descr">Determines ISO equivalent of an
+image sensor indicating the sensor's sensitivity to light. The numbers are
+expressed in arithmetic scale, as per <xref linkend="iso12232" /> standard,
+where doubling the sensor sensitivity is represented by doubling the numerical
+ISO value. Applications should interpret the values as standard ISO values
+multiplied by 1000, e.g. control value 800 stands for ISO 0.8. Drivers will
+usually support only a subset of standard ISO values. The effect of setting
+this control while the <constant>V4L2_CID_ISO_SENSITIVITY_AUTO</constant>
+control is set to a value other than <constant>V4L2_CID_ISO_SENSITIVITY_MANUAL
+</constant> is undefined, drivers should ignore such requests.</entry>
+          </row>
+          <row><entry></entry></row>
+
+          <row id="v4l2-iso-sensitivity-auto-type">
+            <entry spanname="id"><constant>V4L2_CID_ISO_SENSITIVITY_AUTO</constant>&nbsp;</entry>
+            <entry>enum&nbsp;v4l2_iso_sensitivity_type</entry>
+          </row><row><entry spanname="descr">Enables or disables automatic ISO
+sensitivity adjustments.</entry>
+          </row>
+          <row>
+            <entrytbl spanname="descr" cols="2">
+              <tbody valign="top">
+                <row>
+                  <entry><constant>V4L2_CID_ISO_SENSITIVITY_MANUAL</constant>&nbsp;</entry>
+                  <entry>Manual ISO sensitivity.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_CID_ISO_SENSITIVITY_AUTO</constant>&nbsp;</entry>
+                  <entry>Automatic ISO sensitivity adjustments.</entry>
+                </row>
+              </tbody>
+            </entrytbl>
+          </row>
+          <row><entry></entry></row>
+
+          <row id="v4l2-scene-mode">
+            <entry spanname="id"><constant>V4L2_CID_SCENE_MODE</constant>&nbsp;</entry>
+            <entry>enum&nbsp;v4l2_scene_mode</entry>
+          </row><row><entry spanname="descr">This control allows to select
+scene programs as the camera automatic modes optimized for common shooting
+scenes. Within these modes the camera determines best exposure, aperture,
+focusing, light metering, white balance and equivalent sensitivity. The
+controls of those parameters are influenced by the scene mode control.
+An exact behavior in each mode is subject to the camera specification.
+
+<para>When the scene mode feature is not used, this control should be set to
+<constant>V4L2_SCENE_MODE_NONE</constant> to make sure the other possibly
+related controls are accessible. The following scene programs are defined:
+</para>
+</entry>
+          </row>
+          <row>
+            <entrytbl spanname="descr" cols="2">
+              <tbody valign="top">
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_NONE</constant>&nbsp;</entry>
+                  <entry>The scene mode feature is disabled.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_BACKLIGHT</constant>&nbsp;</entry>
+                  <entry>Backlight. Compensates for dark shadows when light is
+                  coming from behind a subject, also by automatically turning
+                  on the flash.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_BEACH_SNOW</constant>&nbsp;</entry>
+                  <entry>Beach and snow. This mode compensates for all-white or
+bright scenes, which tend to look gray and low contrast, when camera's automatic
+exposure is based on an average scene brightness. To compensate, this mode
+automatically slightly overexposes the frames. The white balance may also be
+adjusted to compensate for the fact that reflected snow looks bluish rather
+than white.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_CANDLELIGHT</constant>&nbsp;</entry>
+                  <entry>Candle light. The camera generally raises the ISO
+sensitivity and lowers the shutter speed. This mode compensates for relatively
+close subject in the scene. The flash is disabled in order to preserve the
+ambiance of the light.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_DAWN_DUSK</constant>&nbsp;</entry>
+                  <entry>Dawn and dusk. Preserves the colors seen in low
+natural light before dusk and after down. The camera may turn off the flash,
+and automatically focus at infinity. It will usually boost saturation and
+lower the shutter speed.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_FALL_COLORS</constant>&nbsp;</entry>
+                  <entry>Fall colors. Increases saturation and adjusts white
+balance for color enhancement. Pictures of autumn leaves get saturated reds
+and yellows.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_FIREWORKS</constant>&nbsp;</entry>
+                  <entry>Fireworks. Long exposure times are used to capture
+the expanding burst of light from a firework. The camera may invoke image
+stabilization.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_LANDSCAPE</constant>&nbsp;</entry>
+                  <entry>Landscape. The camera may choose a small aperture to
+provide deep depth of field and long exposure duration to help capture detail
+in dim light conditions. The focus is fixed at infinity. Suitable for distant
+and wide scenery.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_NIGHT</constant>&nbsp;</entry>
+                  <entry>Night, also known as Night Landscape. Designed for low
+light conditions, it preserves detail in the dark areas without blowing out bright
+objects. The camera generally sets itself to a medium-to-high ISO sensitivity,
+with a relatively long exposure time, and turns flash off. As such, there will be
+increased image noise and the possibility of blurred image.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_PARTY_INDOOR</constant>&nbsp;</entry>
+                  <entry>Party and indoor. Designed to capture indoor scenes
+that are lit by indoor background lighting as well as the flash. The camera
+usually increases ISO sensitivity, and adjusts exposure for the low light
+conditions.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_PORTRAIT</constant>&nbsp;</entry>
+                  <entry>Portrait. The camera adjusts the aperture so that the
+depth of field is reduced, which helps to isolate the subject against a smooth
+background. Most cameras recognize the presence of faces in the scene and focus
+on them. The color hue is adjusted to enhance skin tones. The intensity of the
+flash is often reduced.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_SPORTS</constant>&nbsp;</entry>
+                  <entry>Sports. Significantly increases ISO and uses a fast
+shutter speed to freeze motion of rapidly-moving subjects. Increased image
+noise may be seen in this mode.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_SUNSET</constant>&nbsp;</entry>
+                  <entry>Sunset. Preserves deep hues seen in sunsets and
+sunrises. It bumps up the saturation.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_SCENE_MODE_TEXT</constant>&nbsp;</entry>
+                  <entry>Text. It applies extra contrast and sharpness, it is
+typically a black-and-white mode optimized for readability. Automatic focus
+may be switched to close-up mode and this setting may also involve some
+lens-distortion correction.</entry>
+                </row>
+              </tbody>
+            </entrytbl>
+          </row>
+          <row><entry></entry></row>
+
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_3A_LOCK</constant></entry>
+            <entry>bitmask</entry>
+          </row>
+          <row>
+            <entry spanname="descr">This control locks or unlocks the automatic
+focus, exposure and white balance. The automatic adjustments can be paused
+independently by setting the corresponding lock bit to 1. The camera then retains
+the settings until the lock bit is cleared. The following lock bits are defined:
+</entry>
+          </row>
+          <row>
+            <entrytbl spanname="descr" cols="2">
+              <tbody valign="top">
+                <row>
+                  <entry><constant>V4L2_LOCK_EXPOSURE</constant></entry>
+                  <entry>Automatic exposure adjustments lock.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_LOCK_WHITE_BALANCE</constant></entry>
+                  <entry>Automatic white balance adjustments lock.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_LOCK_FOCUS</constant></entry>
+                  <entry>Automatic focus lock.</entry>
+                </row>
+              </tbody>
+            </entrytbl>
+          </row>
+          <row><entry spanname="descr">
+When a given algorithm is not enabled, drivers should ignore requests
+to lock it and should return no error. An example might be an application
+setting bit <constant>V4L2_LOCK_WHITE_BALANCE</constant> when the
+<constant>V4L2_CID_AUTO_WHITE_BALANCE</constant> control is set to
+<constant>FALSE</constant>. The value of this control may be changed
+by exposure, white balance or focus controls.</entry>
+          </row>
+          <row><entry></entry></row>
+
         </tbody>
       </tgroup>
     </table>
@@ -3476,7 +3978,7 @@ interface and may change in the future.</para>
             <entry spanname="id"><constant>V4L2_CID_JPEG_CHROMA_SUBSAMPLING</constant></entry>
             <entry>menu</entry>
           </row>
-          <row id="jpeg-chroma-subsampling-control">
+          <row id="v4l2-jpeg-chroma-subsampling">
             <entry spanname="descr">The chroma subsampling factors describe how
             each component of an input image is sampled, in respect to maximum
             sample rate in each spatial dimension. See <xref linkend="itu-t81"/>,
@@ -3538,12 +4040,12 @@ interface and may change in the future.</para>
             </entry>
           </row>
           <row id="jpeg-quality-control">
-            <entry spanname="id"><constant>V4L2_CID_JPEG_COMPRESION_QUALITY</constant></entry>
+            <entry spanname="id"><constant>V4L2_CID_JPEG_COMPRESSION_QUALITY</constant></entry>
             <entry>integer</entry>
           </row>
           <row>
             <entry spanname="descr">
-              <constant>V4L2_CID_JPEG_COMPRESION_QUALITY</constant> control
+              <constant>V4L2_CID_JPEG_COMPRESSION_QUALITY</constant> control
               determines trade-off between image quality and size.
               It provides simpler method for applications to control image quality,
               without a need for direct reconfiguration of luminance and chrominance
@@ -3551,7 +4053,7 @@ interface and may change in the future.</para>
 
               In cases where a driver uses quantization tables configured directly
               by an application, using interfaces defined elsewhere, <constant>
-              V4L2_CID_JPEG_COMPRESION_QUALITY</constant> control should be set
+              V4L2_CID_JPEG_COMPRESSION_QUALITY</constant> control should be set
               by driver to 0.
 
               <para>The value range of this control is driver-specific. Only
@@ -3599,4 +4101,172 @@ interface and may change in the future.</para>
       to <xref linkend="itu-t81"/>, <xref linkend="jfif"/>,
       <xref linkend="w3c-jpeg-jfif"/>.</para>
     </section>
+
+    <section id="image-source-controls">
+      <title>Image Source Control Reference</title>
+
+      <note>
+        <title>Experimental</title>
+
+        <para>This is an <link
+        linkend="experimental">experimental</link> interface and may
+        change in the future.</para>
+      </note>
+
+      <para>
+        The Image Source control class is intended for low-level
+        control of image source devices such as image sensors. The
+        devices feature an analogue to digital converter and a bus
+        transmitter to transmit the image data out of the device.
+      </para>
+
+      <table pgwide="1" frame="none" id="image-source-control-id">
+      <title>Image Source 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_IMAGE_SOURCE_CLASS</constant></entry>
+            <entry>class</entry>
+          </row>
+          <row>
+            <entry spanname="descr">The IMAGE_SOURCE class descriptor.</entry>
+          </row>
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_VBLANK</constant></entry>
+            <entry>integer</entry>
+          </row>
+          <row>
+            <entry spanname="descr">Vertical blanking. The idle period
+            after every frame during which no image data is produced.
+            The unit of vertical blanking is a line. Every line has
+            length of the image width plus horizontal blanking at the
+            pixel rate defined by
+            <constant>V4L2_CID_PIXEL_RATE</constant> control in the
+            same sub-device.</entry>
+          </row>
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_HBLANK</constant></entry>
+            <entry>integer</entry>
+          </row>
+          <row>
+            <entry spanname="descr">Horizontal blanking. The idle
+            period after every line of image data during which no
+            image data is produced. The unit of horizontal blanking is
+            pixels.</entry>
+          </row>
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_ANALOGUE_GAIN</constant></entry>
+            <entry>integer</entry>
+          </row>
+          <row>
+            <entry spanname="descr">Analogue gain is gain affecting
+            all colour components in the pixel matrix. The gain
+            operation is performed in the analogue domain before A/D
+            conversion.
+            </entry>
+          </row>
+          <row><entry></entry></row>
+        </tbody>
+      </tgroup>
+      </table>
+
+    </section>
+
+    <section id="image-process-controls">
+      <title>Image Process Control Reference</title>
+
+      <note>
+        <title>Experimental</title>
+
+        <para>This is an <link
+        linkend="experimental">experimental</link> interface and may
+        change in the future.</para>
+      </note>
+
+      <para>
+        The Image Source control class is intended for low-level control of
+        image processing functions. Unlike
+        <constant>V4L2_CID_IMAGE_SOURCE_CLASS</constant>, the controls in
+        this class affect processing the image, and do not control capturing
+        of it.
+      </para>
+
+      <table pgwide="1" frame="none" id="image-process-control-id">
+      <title>Image Source 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_IMAGE_PROC_CLASS</constant></entry>
+            <entry>class</entry>
+          </row>
+          <row>
+            <entry spanname="descr">The IMAGE_PROC class descriptor.</entry>
+          </row>
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_LINK_FREQ</constant></entry>
+            <entry>integer menu</entry>
+          </row>
+          <row>
+            <entry spanname="descr">Data bus frequency. Together with the
+            media bus pixel code, bus type (clock cycles per sample), the
+            data bus frequency defines the pixel rate
+            (<constant>V4L2_CID_PIXEL_RATE</constant>) in the
+            pixel array (or possibly elsewhere, if the device is not an
+            image sensor). The frame rate can be calculated from the pixel
+            clock, image width and height and horizontal and vertical
+            blanking. While the pixel rate control may be defined elsewhere
+            than in the subdev containing the pixel array, the frame rate
+            cannot be obtained from that information. This is because only
+            on the pixel array it can be assumed that the vertical and
+            horizontal blanking information is exact: no other blanking is
+            allowed in the pixel array. The selection of frame rate is
+            performed by selecting the desired horizontal and vertical
+            blanking. The unit of this control is Hz. </entry>
+          </row>
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_PIXEL_RATE</constant></entry>
+            <entry>64-bit integer</entry>
+          </row>
+          <row>
+            <entry spanname="descr">Pixel rate in the source pads of
+            the subdev. This control is read-only and its unit is
+            pixels / second.
+            </entry>
+          </row>
+          <row><entry></entry></row>
+        </tbody>
+      </tgroup>
+      </table>
+
+    </section>
 </section>
diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml b/Documentation/DocBook/media/v4l/dev-subdev.xml
index 0916a7343a16..4afcbbec5eda 100644
--- a/Documentation/DocBook/media/v4l/dev-subdev.xml
+++ b/Documentation/DocBook/media/v4l/dev-subdev.xml
@@ -76,11 +76,12 @@
     <wordasword>format</wordasword> means the combination of media bus data
     format, frame width and frame height.</para></note>
 
-    <para>Image formats are typically negotiated on video capture and output
-    devices using the <link linkend="crop">cropping and scaling</link> ioctls.
-    The driver is responsible for configuring every block in the video pipeline
-    according to the requested format at the pipeline input and/or
-    output.</para>
+    <para>Image formats are typically negotiated on video capture and
+    output devices using the format and <link
+    linkend="vidioc-subdev-g-selection">selection</link> ioctls. The
+    driver is responsible for configuring every block in the video
+    pipeline according to the requested format at the pipeline input
+    and/or output.</para>
 
     <para>For complex devices, such as often found in embedded systems,
     identical image sizes at the output of a pipeline can be achieved using
@@ -276,11 +277,11 @@
     </section>
 
     <section>
-      <title>Cropping and scaling</title>
+      <title>Selections: cropping, scaling and composition</title>
 
       <para>Many sub-devices support cropping frames on their input or output
       pads (or possible even on both). Cropping is used to select the area of
-      interest in an image, typically on a video sensor or video decoder. It can
+      interest in an image, typically on an image sensor or a video decoder. It can
       also be used as part of digital zoom implementations to select the area of
       the image that will be scaled up.</para>
 
@@ -288,26 +289,179 @@
       &v4l2-rect; by the coordinates of the top left corner and the rectangle
       size. Both the coordinates and sizes are expressed in pixels.</para>
 
-      <para>The crop rectangle is retrieved and set using the
-      &VIDIOC-SUBDEV-G-CROP; and &VIDIOC-SUBDEV-S-CROP; ioctls. Like for pad
-      formats, drivers store try and active crop rectangles. The format
-      negotiation mechanism applies to crop settings as well.</para>
-
-      <para>On input pads, cropping is applied relatively to the current pad
-      format. The pad format represents the image size as received by the
-      sub-device from the previous block in the pipeline, and the crop rectangle
-      represents the sub-image that will be transmitted further inside the
-      sub-device for processing. The crop rectangle be entirely containted
-      inside the input image size.</para>
-
-      <para>Input crop rectangle are reset to their default value when the input
-      image format is modified. Drivers should use the input image size as the
-      crop rectangle default value, but hardware requirements may prevent this.
-      </para>
+      <para>As for pad formats, drivers store try and active
+      rectangles for the selection targets of ACTUAL type <xref
+      linkend="v4l2-subdev-selection-targets">.</xref></para>
+
+      <para>On sink pads, cropping is applied relative to the
+      current pad format. The pad format represents the image size as
+      received by the sub-device from the previous block in the
+      pipeline, and the crop rectangle represents the sub-image that
+      will be transmitted further inside the sub-device for
+      processing.</para>
+
+      <para>The scaling operation changes the size of the image by
+      scaling it to new dimensions. The scaling ratio isn't specified
+      explicitly, but is implied from the original and scaled image
+      sizes. Both sizes are represented by &v4l2-rect;.</para>
+
+      <para>Scaling support is optional. When supported by a subdev,
+      the crop rectangle on the subdev's sink pad is scaled to the
+      size configured using the &VIDIOC-SUBDEV-S-SELECTION; IOCTL
+      using <constant>V4L2_SUBDEV_SEL_COMPOSE_ACTUAL</constant>
+      selection target on the same pad. If the subdev supports scaling
+      but not composing, the top and left values are not used and must
+      always be set to zero.</para>
+
+      <para>On source pads, cropping is similar to sink pads, with the
+      exception that the source size from which the cropping is
+      performed, is the COMPOSE rectangle on the sink pad. In both
+      sink and source pads, the crop rectangle must be entirely
+      contained inside the source image size for the crop
+      operation.</para>
+
+      <para>The drivers should always use the closest possible
+      rectangle the user requests on all selection targets, unless
+      specifically told otherwise.
+      <constant>V4L2_SUBDEV_SEL_FLAG_SIZE_GE</constant> and
+      <constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant> flags may be
+      used to round the image size either up or down. <xref
+      linkend="v4l2-subdev-selection-flags"></xref></para>
+    </section>
+
+    <section>
+      <title>Types of selection targets</title>
+
+      <section>
+        <title>ACTUAL targets</title>
+
+        <para>ACTUAL targets reflect the actual hardware configuration
+        at any point of time. There is a BOUNDS target
+        corresponding to every ACTUAL.</para>
+      </section>
+
+      <section>
+        <title>BOUNDS targets</title>
+
+        <para>BOUNDS targets is the smallest rectangle that contains
+        all valid ACTUAL rectangles. It may not be possible to set the
+        ACTUAL rectangle as large as the BOUNDS rectangle, however.
+        This may be because e.g. a sensor's pixel array is not
+        rectangular but cross-shaped or round. The maximum size may
+        also be smaller than the BOUNDS rectangle.</para>
+      </section>
 
-      <para>Cropping behaviour on output pads is not defined.</para>
+    </section>
+
+    <section>
+      <title>Order of configuration and format propagation</title>
+
+      <para>Inside subdevs, the order of image processing steps will
+      always be from the sink pad towards the source pad. This is also
+      reflected in the order in which the configuration must be
+      performed by the user: the changes made will be propagated to
+      any subsequent stages. If this behaviour is not desired, the
+      user must set
+      <constant>V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG</constant> flag. This
+      flag causes no propagation of the changes are allowed in any
+      circumstances. This may also cause the accessed rectangle to be
+      adjusted by the driver, depending on the properties of the
+      underlying hardware.</para>
+
+      <para>The coordinates to a step always refer to the actual size
+      of the previous step. The exception to this rule is the source
+      compose rectangle, which refers to the sink compose bounds
+      rectangle --- if it is supported by the hardware.</para>
+
+      <orderedlist>
+        <listitem>Sink pad format. The user configures the sink pad
+        format. This format defines the parameters of the image the
+        entity receives through the pad for further processing.</listitem>
+
+        <listitem>Sink pad actual crop selection. The sink pad crop
+        defines the crop performed to the sink pad format.</listitem>
+
+        <listitem>Sink pad actual compose selection. The size of the
+        sink pad compose rectangle defines the scaling ratio compared
+        to the size of the sink pad crop rectangle. The location of
+        the compose rectangle specifies the location of the actual
+        sink compose rectangle in the sink compose bounds
+        rectangle.</listitem>
+
+        <listitem>Source pad actual crop selection. Crop on the source
+        pad defines crop performed to the image in the sink compose
+        bounds rectangle.</listitem>
+
+        <listitem>Source pad format. The source pad format defines the
+        output pixel format of the subdev, as well as the other
+        parameters with the exception of the image width and height.
+        Width and height are defined by the size of the source pad
+        actual crop selection.</listitem>
+      </orderedlist>
+
+      <para>Accessing any of the above rectangles not supported by the
+      subdev will return <constant>EINVAL</constant>. Any rectangle
+      referring to a previous unsupported rectangle coordinates will
+      instead refer to the previous supported rectangle. For example,
+      if sink crop is not supported, the compose selection will refer
+      to the sink pad format dimensions instead.</para>
+
+      <figure id="subdev-image-processing-crop">
+        <title>Image processing in subdevs: simple crop example</title>
+        <mediaobject>
+          <imageobject>
+            <imagedata fileref="subdev-image-processing-crop.svg"
+            format="SVG" scale="200" />
+          </imageobject>
+        </mediaobject>
+      </figure>
+
+      <para>In the above example, the subdev supports cropping on its
+      sink pad. To configure it, the user sets the media bus format on
+      the subdev's sink pad. Now the actual crop rectangle can be set
+      on the sink pad --- the location and size of this rectangle
+      reflect the location and size of a rectangle to be cropped from
+      the sink format. The size of the sink crop rectangle will also
+      be the size of the format of the subdev's source pad.</para>
+
+      <figure id="subdev-image-processing-scaling-multi-source">
+        <title>Image processing in subdevs: scaling with multiple sources</title>
+        <mediaobject>
+          <imageobject>
+            <imagedata fileref="subdev-image-processing-scaling-multi-source.svg"
+            format="SVG" scale="200" />
+          </imageobject>
+        </mediaobject>
+      </figure>
+
+      <para>In this example, the subdev is capable of first cropping,
+      then scaling and finally cropping for two source pads
+      individually from the resulting scaled image. The location of
+      the scaled image in the cropped image is ignored in sink compose
+      target. Both of the locations of the source crop rectangles
+      refer to the sink scaling rectangle, independently cropping an
+      area at location specified by the source crop rectangle from
+      it.</para>
+
+      <figure id="subdev-image-processing-full">
+        <title>Image processing in subdevs: scaling and composition
+        with multiple sinks and sources</title>
+        <mediaobject>
+          <imageobject>
+            <imagedata fileref="subdev-image-processing-full.svg"
+            format="SVG" scale="200" />
+          </imageobject>
+        </mediaobject>
+      </figure>
+
+      <para>The subdev driver supports two sink pads and two source
+      pads. The images from both of the sink pads are individually
+      cropped, then scaled and further composed on the composition
+      bounds rectangle. From that, two independent streams are cropped
+      and sent out of the subdev from the source pads.</para>
 
     </section>
+
   </section>
 
   &sub-subdev-formats;
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index b815929b5bba..fd6aca2922b6 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -543,12 +543,13 @@ and can range from zero to the number of buffers allocated
 with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.</entry>
           </row>
           <row>
-            <entry>&v4l2-buf-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry></entry>
             <entry>Type of the buffer, same as &v4l2-format;
 <structfield>type</structfield> or &v4l2-requestbuffers;
-<structfield>type</structfield>, set by the application.</entry>
+<structfield>type</structfield>, set by the application. See <xref
+linkend="v4l2-buf-type" /></entry>
           </row>
           <row>
             <entry>__u32</entry>
@@ -568,7 +569,7 @@ refers to an input stream, applications when an output stream.</entry>
 linkend="buffer-flags" />.</entry>
           </row>
           <row>
-            <entry>&v4l2-field;</entry>
+            <entry>__u32</entry>
             <entry><structfield>field</structfield></entry>
             <entry></entry>
             <entry>Indicates the field order of the image in the
@@ -630,11 +631,12 @@ bandwidth. These devices identify by not enumerating any video
 standards, see <xref linkend="standard" />.</para></entry>
           </row>
           <row>
-            <entry>&v4l2-memory;</entry>
+            <entry>__u32</entry>
             <entry><structfield>memory</structfield></entry>
             <entry></entry>
             <entry>This field must be set by applications and/or drivers
-in accordance with the selected I/O method.</entry>
+in accordance with the selected I/O method. See <xref linkend="v4l2-memory"
+            /></entry>
           </row>
           <row>
             <entry>union</entry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
index 7b274092e60c..c1c62a9acc2a 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
@@ -1,4 +1,4 @@
-    <refentry>
+    <refentry id="pixfmt-srggb10">
       <refmeta>
         <refentrytitle>V4L2_PIX_FMT_SRGGB10 ('RG10'),
          V4L2_PIX_FMT_SGRBG10 ('BA10'),
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
new file mode 100644
index 000000000000..8eace3e2e7d4
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
@@ -0,0 +1,29 @@
+    <refentry id="pixfmt-srggb10dpcm8">
+      <refmeta>
+        <refentrytitle>
+         V4L2_PIX_FMT_SBGGR10DPCM8 ('bBA8'),
+         V4L2_PIX_FMT_SGBRG10DPCM8 ('bGA8'),
+         V4L2_PIX_FMT_SGRBG10DPCM8 ('BD10'),
+         V4L2_PIX_FMT_SRGGB10DPCM8 ('bRA8'),
+         </refentrytitle>
+        &manvol;
+      </refmeta>
+      <refnamediv>
+        <refname id="V4L2-PIX-FMT-SBGGR10DPCM8"><constant>V4L2_PIX_FMT_SBGGR10DPCM8</constant></refname>
+        <refname id="V4L2-PIX-FMT-SGBRG10DPCM8"><constant>V4L2_PIX_FMT_SGBRG10DPCM8</constant></refname>
+        <refname id="V4L2-PIX-FMT-SGRBG10DPCM8"><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></refname>
+        <refname id="V4L2-PIX-FMT-SRGGB10DPCM8"><constant>V4L2_PIX_FMT_SRGGB10DPCM8</constant></refname>
+        <refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose>
+      </refnamediv>
+      <refsect1>
+        <title>Description</title>
+
+        <para>The following four pixel formats are raw sRGB / Bayer formats
+        with 10 bits per colour compressed to 8 bits each, using DPCM
+        compression. DPCM, differential pulse-code modulation, is lossy.
+        Each colour component consumes 8 bits of memory. In other respects
+        this format is similar to <xref
+        linkend="pixfmt-srggb10">.</xref></para>
+
+      </refsect1>
+    </refentry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index 31eaae2469f9..e58934c92895 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
     &sub-srggb8;
     &sub-sbggr16;
     &sub-srggb10;
+    &sub-srggb10dpcm8;
     &sub-srggb12;
   </section>
 
@@ -876,11 +877,6 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
             <entry>'S561'</entry>
             <entry>Compressed GBRG Bayer format used by the gspca driver.</entry>
           </row>
-          <row id="V4L2-PIX-FMT-SGRBG10DPCM8">
-            <entry><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></entry>
-            <entry>'DB10'</entry>
-            <entry>10 bit raw Bayer DPCM compressed to 8 bits.</entry>
-          </row>
           <row id="V4L2-PIX-FMT-PAC207">
             <entry><constant>V4L2_PIX_FMT_PAC207</constant></entry>
             <entry>'P207'</entry>
@@ -990,13 +986,13 @@ http://www.thedirks.org/winnov/</ulink></para></entry>
           <row id="V4L2-PIX-FMT-Y4">
             <entry><constant>V4L2_PIX_FMT_Y4</constant></entry>
             <entry>'Y04 '</entry>
-            <entry>Old 4-bit greyscale format. Only the least significant 4 bits of each byte are used,
+            <entry>Old 4-bit greyscale format. Only the most significant 4 bits of each byte are used,
 the other bits are set to 0.</entry>
           </row>
           <row id="V4L2-PIX-FMT-Y6">
             <entry><constant>V4L2_PIX_FMT_Y6</constant></entry>
             <entry>'Y06 '</entry>
-            <entry>Old 6-bit greyscale format. Only the least significant 6 bits of each byte are used,
+            <entry>Old 6-bit greyscale format. Only the most significant 6 bits of each byte are used,
 the other bits are set to 0.</entry>
           </row>
         </tbody>
diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-crop.dia b/Documentation/DocBook/media/v4l/subdev-image-processing-crop.dia
new file mode 100644
index 000000000000..e32ba5362e1d
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/subdev-image-processing-crop.dia
@@ -0,0 +1,614 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<dia:diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/">
+  <dia:diagramdata>
+    <dia:attribute name="background">
+      <dia:color val="#ffffff"/>
+    </dia:attribute>
+    <dia:attribute name="pagebreak">
+      <dia:color val="#000099"/>
+    </dia:attribute>
+    <dia:attribute name="paper">
+      <dia:composite type="paper">
+        <dia:attribute name="name">
+          <dia:string>#A4#</dia:string>
+        </dia:attribute>
+        <dia:attribute name="tmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="bmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="lmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="rmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="is_portrait">
+          <dia:boolean val="false"/>
+        </dia:attribute>
+        <dia:attribute name="scaling">
+          <dia:real val="0.49000000953674316"/>
+        </dia:attribute>
+        <dia:attribute name="fitto">
+          <dia:boolean val="false"/>
+        </dia:attribute>
+      </dia:composite>
+    </dia:attribute>
+    <dia:attribute name="grid">
+      <dia:composite type="grid">
+        <dia:attribute name="width_x">
+          <dia:real val="1"/>
+        </dia:attribute>
+        <dia:attribute name="width_y">
+          <dia:real val="1"/>
+        </dia:attribute>
+        <dia:attribute name="visible_x">
+          <dia:int val="1"/>
+        </dia:attribute>
+        <dia:attribute name="visible_y">
+          <dia:int val="1"/>
+        </dia:attribute>
+        <dia:composite type="color"/>
+      </dia:composite>
+    </dia:attribute>
+    <dia:attribute name="color">
+      <dia:color val="#d8e5e5"/>
+    </dia:attribute>
+    <dia:attribute name="guides">
+      <dia:composite type="guides">
+        <dia:attribute name="hguides"/>
+        <dia:attribute name="vguides"/>
+      </dia:composite>
+    </dia:attribute>
+  </dia:diagramdata>
+  <dia:layer name="Background" visible="true" active="true">
+    <dia:object type="Standard - Box" version="0" id="O0">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-0.4,6.5"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-0.45,6.45;23.1387,16.2"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="-0.4,6.5"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="23.48871579904775"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="9.6500000000000004"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O1">
+      <dia:attribute name="obj_pos">
+        <dia:point val="0.225,9.45"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="0.175,9.4;8.225,14.7"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="0.225,9.45"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="7.9499999999999975"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="5.1999999999999975"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#a52a2a"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O2">
+      <dia:attribute name="obj_pos">
+        <dia:point val="3.175,10.55"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="3.125,10.5;7.925,14.45"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="3.175,10.55"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="4.6999999999999975"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.8499999999999979"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#0000ff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O3">
+      <dia:attribute name="obj_pos">
+        <dia:point val="3.725,11.3875"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="3.725,10.7925;6.6025,13.14"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#sink
+crop
+selection#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="3.725,11.3875"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#0000ff"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O4">
+      <dia:attribute name="obj_pos">
+        <dia:point val="1.475,7.9"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="1.475,7.305;1.475,8.0525"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>##</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="1.475,7.9"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O5">
+      <dia:attribute name="obj_pos">
+        <dia:point val="0.426918,7.89569"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="0.426918,7.30069;3.90942,8.84819"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#sink media
+bus format#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="0.426918,7.89569"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#a52a2a"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O6">
+      <dia:attribute name="obj_pos">
+        <dia:point val="17.4887,7.75"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="17.4887,7.155;21.8112,8.7025"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#source media
+bus format#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="17.4887,7.75"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#8b6914"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O7">
+      <dia:attribute name="obj_pos">
+        <dia:point val="17.5244,9.5417"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="17.4744,9.4917;22.2387,13.35"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="17.5244,9.5417"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="4.6643157990477508"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.758300000000002"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#8b6914"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O8">
+      <dia:attribute name="obj_pos">
+        <dia:point val="17.5244,13.3"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="3.12132,13.2463;17.5781,14.4537"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="17.5244,13.3"/>
+        <dia:point val="3.175,14.4"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O7" connection="5"/>
+        <dia:connection handle="1" to="O2" connection="5"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O9">
+      <dia:attribute name="obj_pos">
+        <dia:point val="17.5244,9.5417"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="3.12162,9.48832;17.5778,10.6034"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="17.5244,9.5417"/>
+        <dia:point val="3.175,10.55"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O7" connection="0"/>
+        <dia:connection handle="1" to="O2" connection="0"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O10">
+      <dia:attribute name="obj_pos">
+        <dia:point val="22.1887,13.3"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="7.82132,13.2463;22.2424,14.4537"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="22.1887,13.3"/>
+        <dia:point val="7.875,14.4"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O7" connection="7"/>
+        <dia:connection handle="1" to="O2" connection="7"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O11">
+      <dia:attribute name="obj_pos">
+        <dia:point val="22.1887,9.5417"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="7.82161,9.48831;22.2421,10.6034"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="22.1887,9.5417"/>
+        <dia:point val="7.875,10.55"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O7" connection="2"/>
+        <dia:connection handle="1" to="O2" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Geometric - Perfect Circle" version="1" id="O12">
+      <dia:attribute name="obj_pos">
+        <dia:point val="23.23,10.5742"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="23.18,10.5242;24.13,11.4742"/>
+      </dia:attribute>
+      <dia:attribute name="meta">
+        <dia:composite type="dict"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="23.23,10.5742"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="line_width">
+        <dia:real val="0.10000000000000001"/>
+      </dia:attribute>
+      <dia:attribute name="line_colour">
+        <dia:color val="#000000"/>
+      </dia:attribute>
+      <dia:attribute name="fill_colour">
+        <dia:color val="#ffffff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="0"/>
+        <dia:real val="1"/>
+      </dia:attribute>
+      <dia:attribute name="flip_horizontal">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="flip_vertical">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="subscale">
+        <dia:real val="1"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O13">
+      <dia:attribute name="obj_pos">
+        <dia:point val="24.08,10.9992"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="24.03,10.6388;32.4953,11.3624"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="24.08,10.9992"/>
+        <dia:point val="32.3835,11.0007"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O12" connection="3"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O14">
+      <dia:attribute name="obj_pos">
+        <dia:point val="25.3454,10.49"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="25.3454,9.895;29.9904,10.6425"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#pad 1 (source)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="25.3454,10.49"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Geometric - Perfect Circle" version="1" id="O15">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-1.44491,11.6506"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-1.49491,11.6006;-0.54491,12.5506"/>
+      </dia:attribute>
+      <dia:attribute name="meta">
+        <dia:composite type="dict"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="-1.44491,11.6506"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="line_width">
+        <dia:real val="0.10000000000000001"/>
+      </dia:attribute>
+      <dia:attribute name="line_colour">
+        <dia:color val="#000000"/>
+      </dia:attribute>
+      <dia:attribute name="fill_colour">
+        <dia:color val="#ffffff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="0"/>
+        <dia:real val="1"/>
+      </dia:attribute>
+      <dia:attribute name="flip_horizontal">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="flip_vertical">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="subscale">
+        <dia:real val="1"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O16">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-9.61991,12.09"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-9.67,11.7149;-1.33311,12.4385"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="-9.61991,12.09"/>
+        <dia:point val="-1.44491,12.0756"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="1" to="O15" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O17">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-7.39291,11.49"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-7.39291,10.895;-3.58791,11.6425"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#pad 0 (sink)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="-7.39291,11.49"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+  </dia:layer>
+</dia:diagram>
diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-crop.svg b/Documentation/DocBook/media/v4l/subdev-image-processing-crop.svg
new file mode 100644
index 000000000000..18b0f5de9ed2
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/subdev-image-processing-crop.svg
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
+<svg width="43cm" height="10cm" viewBox="-194 128 844 196" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+  <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="-8" y="130" width="469.774" height="193"/>
+  <g>
+    <rect style="fill: #ffffff" x="4.5" y="189" width="159" height="104"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a52a2a" x="4.5" y="189" width="159" height="104"/>
+  </g>
+  <g>
+    <rect style="fill: #ffffff" x="63.5" y="211" width="94" height="77"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #0000ff" x="63.5" y="211" width="94" height="77"/>
+  </g>
+  <text style="fill: #0000ff;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="74.5" y="227.75">
+    <tspan x="74.5" y="227.75">sink</tspan>
+    <tspan x="74.5" y="243.75">crop</tspan>
+    <tspan x="74.5" y="259.75">selection</tspan>
+  </text>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="29.5" y="158">
+    <tspan x="29.5" y="158"></tspan>
+  </text>
+  <text style="fill: #a52a2a;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="8.53836" y="157.914">
+    <tspan x="8.53836" y="157.914">sink media</tspan>
+    <tspan x="8.53836" y="173.914">bus format</tspan>
+  </text>
+  <text style="fill: #8b6914;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="349.774" y="155">
+    <tspan x="349.774" y="155">source media</tspan>
+    <tspan x="349.774" y="171">bus format</tspan>
+  </text>
+  <g>
+    <rect style="fill: #ffffff" x="350.488" y="190.834" width="93.2863" height="75.166"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #8b6914" x="350.488" y="190.834" width="93.2863" height="75.166"/>
+  </g>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="350.488" y1="266" x2="63.5" y2="288"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="350.488" y1="190.834" x2="63.5" y2="211"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="443.774" y1="266" x2="157.5" y2="288"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="443.774" y1="190.834" x2="157.5" y2="211"/>
+  <g>
+    <ellipse style="fill: #ffffff" cx="473.1" cy="219.984" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="473.1" cy="219.984" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="473.1" cy="219.984" rx="8.5" ry="8.5"/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="481.6" y1="219.984" x2="637.934" y2="220.012"/>
+    <polygon style="fill: #000000" points="645.434,220.014 635.433,225.012 637.934,220.012 635.435,215.012 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="645.434,220.014 635.433,225.012 637.934,220.012 635.435,215.012 "/>
+  </g>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="506.908" y="209.8">
+    <tspan x="506.908" y="209.8">pad 1 (source)</tspan>
+  </text>
+  <g>
+    <ellipse style="fill: #ffffff" cx="-20.3982" cy="241.512" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="-20.3982" cy="241.512" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="-20.3982" cy="241.512" rx="8.5" ry="8.5"/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="-192.398" y1="241.8" x2="-38.6343" y2="241.529"/>
+    <polygon style="fill: #000000" points="-31.1343,241.516 -41.1254,246.534 -38.6343,241.529 -41.1431,236.534 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="-31.1343,241.516 -41.1254,246.534 -38.6343,241.529 -41.1431,236.534 "/>
+  </g>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="-147.858" y="229.8">
+    <tspan x="-147.858" y="229.8">pad 0 (sink)</tspan>
+  </text>
+</svg>
diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-full.dia b/Documentation/DocBook/media/v4l/subdev-image-processing-full.dia
new file mode 100644
index 000000000000..a0d782927840
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/subdev-image-processing-full.dia
@@ -0,0 +1,1588 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<dia:diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/">
+  <dia:diagramdata>
+    <dia:attribute name="background">
+      <dia:color val="#ffffff"/>
+    </dia:attribute>
+    <dia:attribute name="pagebreak">
+      <dia:color val="#000099"/>
+    </dia:attribute>
+    <dia:attribute name="paper">
+      <dia:composite type="paper">
+        <dia:attribute name="name">
+          <dia:string>#A4#</dia:string>
+        </dia:attribute>
+        <dia:attribute name="tmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="bmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="lmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="rmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="is_portrait">
+          <dia:boolean val="false"/>
+        </dia:attribute>
+        <dia:attribute name="scaling">
+          <dia:real val="0.49000000953674316"/>
+        </dia:attribute>
+        <dia:attribute name="fitto">
+          <dia:boolean val="false"/>
+        </dia:attribute>
+      </dia:composite>
+    </dia:attribute>
+    <dia:attribute name="grid">
+      <dia:composite type="grid">
+        <dia:attribute name="width_x">
+          <dia:real val="1"/>
+        </dia:attribute>
+        <dia:attribute name="width_y">
+          <dia:real val="1"/>
+        </dia:attribute>
+        <dia:attribute name="visible_x">
+          <dia:int val="1"/>
+        </dia:attribute>
+        <dia:attribute name="visible_y">
+          <dia:int val="1"/>
+        </dia:attribute>
+        <dia:composite type="color"/>
+      </dia:composite>
+    </dia:attribute>
+    <dia:attribute name="color">
+      <dia:color val="#d8e5e5"/>
+    </dia:attribute>
+    <dia:attribute name="guides">
+      <dia:composite type="guides">
+        <dia:attribute name="hguides"/>
+        <dia:attribute name="vguides"/>
+      </dia:composite>
+    </dia:attribute>
+  </dia:diagramdata>
+  <dia:layer name="Background" visible="true" active="true">
+    <dia:object type="Standard - Box" version="0" id="O0">
+      <dia:attribute name="obj_pos">
+        <dia:point val="15.945,6.45"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="15.895,6.4;26.4,18.95"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="15.945,6.45"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="10.404999999254942"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="12.449999999999992"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#ff765a"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O1">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-0.1,3.65"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-0.15,3.6;40.25,20.85"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="-0.1,3.65"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="40.300000000000004"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="17.149999999999999"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Geometric - Perfect Circle" version="1" id="O2">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-1.05,7.9106"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-1.1,7.8606;-0.15,8.8106"/>
+      </dia:attribute>
+      <dia:attribute name="meta">
+        <dia:composite type="dict"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="-1.05,7.9106"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="line_width">
+        <dia:real val="0.10000000000000001"/>
+      </dia:attribute>
+      <dia:attribute name="line_colour">
+        <dia:color val="#000000"/>
+      </dia:attribute>
+      <dia:attribute name="fill_colour">
+        <dia:color val="#ffffff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="0"/>
+        <dia:real val="1"/>
+      </dia:attribute>
+      <dia:attribute name="flip_horizontal">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="flip_vertical">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="subscale">
+        <dia:real val="1"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Geometric - Perfect Circle" version="1" id="O3">
+      <dia:attribute name="obj_pos">
+        <dia:point val="40.3366,9.8342"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="40.2866,9.7842;41.2366,10.7342"/>
+      </dia:attribute>
+      <dia:attribute name="meta">
+        <dia:composite type="dict"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="40.3366,9.8342"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="line_width">
+        <dia:real val="0.10000000000000001"/>
+      </dia:attribute>
+      <dia:attribute name="line_colour">
+        <dia:color val="#000000"/>
+      </dia:attribute>
+      <dia:attribute name="fill_colour">
+        <dia:color val="#ffffff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="0"/>
+        <dia:real val="1"/>
+      </dia:attribute>
+      <dia:attribute name="flip_horizontal">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="flip_vertical">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="subscale">
+        <dia:real val="1"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O4">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-9.225,8.35"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-9.27509,7.97487;-0.938197,8.69848"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="-9.225,8.35"/>
+        <dia:point val="-1.05,8.3356"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="1" to="O2" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O5">
+      <dia:attribute name="obj_pos">
+        <dia:point val="41.1866,10.2592"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="41.1366,9.89879;49.6019,10.6224"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="41.1866,10.2592"/>
+        <dia:point val="49.4901,10.2607"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O3" connection="3"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O6">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-6.998,7.75"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-6.998,7.155;-3.193,7.9025"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#pad 0 (sink)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="-6.998,7.75"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O7">
+      <dia:attribute name="obj_pos">
+        <dia:point val="42.452,9.75"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="42.452,9.155;47.097,9.9025"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#pad 2 (source)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="42.452,9.75"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O8">
+      <dia:attribute name="obj_pos">
+        <dia:point val="0.275,6"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="0.225,5.95;8.275,11.25"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="0.275,6"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="7.9499999999999975"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="5.1999999999999975"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#a52a2a"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O9">
+      <dia:attribute name="obj_pos">
+        <dia:point val="3.125,6.8"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="3.075,6.75;7.875,10.7"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="3.125,6.8"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="4.6999999999999975"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.8499999999999979"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#0000ff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O10">
+      <dia:attribute name="obj_pos">
+        <dia:point val="1.525,4.45"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="1.525,3.855;1.525,4.6025"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>##</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="1.525,4.45"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O11">
+      <dia:attribute name="obj_pos">
+        <dia:point val="0.476918,4.44569"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="0.476918,3.85069;3.95942,5.39819"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#sink media
+bus format#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="0.476918,4.44569"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#a52a2a"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O12">
+      <dia:attribute name="obj_pos">
+        <dia:point val="16.6822,9.28251"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="16.6322,9.23251;24.9922,17.9564"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="16.6822,9.28251"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="8.2600228398861297"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="8.6238900617957164"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#00ff00"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O13">
+      <dia:attribute name="obj_pos">
+        <dia:point val="16.6822,17.9064"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="3.05732,10.5823;16.7499,17.9741"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="16.6822,17.9064"/>
+        <dia:point val="3.125,10.65"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O12" connection="5"/>
+        <dia:connection handle="1" to="O9" connection="5"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O14">
+      <dia:attribute name="obj_pos">
+        <dia:point val="16.6822,9.28251"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="3.06681,6.74181;16.7404,9.3407"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="16.6822,9.28251"/>
+        <dia:point val="3.125,6.8"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O12" connection="0"/>
+        <dia:connection handle="1" to="O9" connection="0"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O15">
+      <dia:attribute name="obj_pos">
+        <dia:point val="24.9422,17.9064"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="7.75945,10.5845;25.0077,17.9719"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="24.9422,17.9064"/>
+        <dia:point val="7.825,10.65"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O12" connection="7"/>
+        <dia:connection handle="1" to="O9" connection="7"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O16">
+      <dia:attribute name="obj_pos">
+        <dia:point val="24.9422,9.28251"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="7.76834,6.74334;24.9989,9.33917"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="24.9422,9.28251"/>
+        <dia:point val="7.825,6.8"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O12" connection="2"/>
+        <dia:connection handle="1" to="O9" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O17">
+      <dia:attribute name="obj_pos">
+        <dia:point val="16.7352,7.47209"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="16.7352,6.87709;22.5602,8.42459"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#sink compose
+selection (scaling)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="16.7352,7.47209"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#00ff00"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O18">
+      <dia:attribute name="obj_pos">
+        <dia:point val="20.4661,9.72825"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="20.4161,9.67825;25.5254,13.3509"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="20.4661,9.72825"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="5.009308462554376"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.5726155970598077"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#a020f0"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O19">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.475,5.2564"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="34.475,4.6614;38.7975,6.2089"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#source media
+bus format#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="34.475,5.2564"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#8b6914"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O20">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.4244,8.6917"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="34.3744,8.6417;39.4837,12.3143"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="34.4244,8.6917"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="5.009308462554376"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.5726155970598077"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#8b6914"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O21">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.4244,12.2643"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="20.4125,12.2107;34.478,13.3545"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="34.4244,12.2643"/>
+        <dia:point val="20.4661,13.3009"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O20" connection="5"/>
+        <dia:connection handle="1" to="O18" connection="5"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O22">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.4244,8.6917"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="20.4125,8.63813;34.478,9.78182"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="34.4244,8.6917"/>
+        <dia:point val="20.4661,9.72825"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O20" connection="0"/>
+        <dia:connection handle="1" to="O18" connection="0"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O23">
+      <dia:attribute name="obj_pos">
+        <dia:point val="39.4337,12.2643"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="25.4218,12.2107;39.4873,13.3545"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="39.4337,12.2643"/>
+        <dia:point val="25.4754,13.3009"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O20" connection="7"/>
+        <dia:connection handle="1" to="O18" connection="7"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O24">
+      <dia:attribute name="obj_pos">
+        <dia:point val="39.4337,8.6917"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="25.4218,8.63813;39.4873,9.78182"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="39.4337,8.6917"/>
+        <dia:point val="25.4754,9.72825"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O20" connection="2"/>
+        <dia:connection handle="1" to="O18" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O25">
+      <dia:attribute name="obj_pos">
+        <dia:point val="16.25,5.15"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="16.25,4.555;21.68,6.1025"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#sink compose
+bounds selection#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="16.25,5.15"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#ff765a"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Geometric - Perfect Circle" version="1" id="O26">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-1.02991,16.6506"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-1.07991,16.6006;-0.12991,17.5506"/>
+      </dia:attribute>
+      <dia:attribute name="meta">
+        <dia:composite type="dict"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="-1.02991,16.6506"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="line_width">
+        <dia:real val="0.10000000000000001"/>
+      </dia:attribute>
+      <dia:attribute name="line_colour">
+        <dia:color val="#000000"/>
+      </dia:attribute>
+      <dia:attribute name="fill_colour">
+        <dia:color val="#ffffff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="0"/>
+        <dia:real val="1"/>
+      </dia:attribute>
+      <dia:attribute name="flip_horizontal">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="flip_vertical">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="subscale">
+        <dia:real val="1"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O27">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-9.20491,17.09"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-9.255,16.7149;-0.918107,17.4385"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="-9.20491,17.09"/>
+        <dia:point val="-1.02991,17.0756"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="1" to="O26" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O28">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-6.95,16.45"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-6.95,15.855;-3.145,16.6025"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#pad 1 (sink)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="-6.95,16.45"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O29">
+      <dia:attribute name="obj_pos">
+        <dia:point val="0.390412,14.64"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="0.340412,14.59;6.045,18.8"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="0.390412,14.64"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="5.604587512785236"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="4.1099999999999994"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#a52a2a"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O30">
+      <dia:attribute name="obj_pos">
+        <dia:point val="2.645,15.74"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="2.595,15.69;5.6,18.3"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="2.645,15.74"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="2.904999999254942"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="2.5100000000000016"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#0000ff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O31">
+      <dia:attribute name="obj_pos">
+        <dia:point val="1.595,12.99"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="1.595,12.395;1.595,13.1425"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>##</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="1.595,12.99"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O32">
+      <dia:attribute name="obj_pos">
+        <dia:point val="17.945,12.595"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="2.58596,12.536;18.004,15.799"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="17.945,12.595"/>
+        <dia:point val="2.645,15.74"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O36" connection="0"/>
+        <dia:connection handle="1" to="O30" connection="0"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O33">
+      <dia:attribute name="obj_pos">
+        <dia:point val="17.945,15.8"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="2.58772,15.7427;18.0023,18.3073"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="17.945,15.8"/>
+        <dia:point val="2.645,18.25"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O36" connection="5"/>
+        <dia:connection handle="1" to="O30" connection="5"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O34">
+      <dia:attribute name="obj_pos">
+        <dia:point val="21.7,15.8"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="5.49307,15.7431;21.7569,18.3069"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="21.7,15.8"/>
+        <dia:point val="5.55,18.25"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O36" connection="7"/>
+        <dia:connection handle="1" to="O30" connection="7"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O35">
+      <dia:attribute name="obj_pos">
+        <dia:point val="21.7,12.595"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="5.49136,12.5364;21.7586,15.7986"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="21.7,12.595"/>
+        <dia:point val="5.55,15.74"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O36" connection="2"/>
+        <dia:connection handle="1" to="O30" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O36">
+      <dia:attribute name="obj_pos">
+        <dia:point val="17.945,12.595"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="17.895,12.545;21.75,15.85"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="17.945,12.595"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="3.7549999992549452"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.2049999992549427"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#00ff00"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O37">
+      <dia:attribute name="obj_pos">
+        <dia:point val="22.1631,14.2233"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="22.1131,14.1733;25.45,16.7"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="22.1631,14.2233"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="3.2369000000000021"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="2.4267000000000003"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#a020f0"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O38">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.6714,16.2367"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="34.6214,16.1867;37.9,18.75"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="34.6714,16.2367"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="3.178600000000003"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="2.4632999999999967"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#8b6914"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O39">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.6714,18.7"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="22.1057,16.5926;34.7288,18.7574"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="34.6714,18.7"/>
+        <dia:point val="22.1631,16.65"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O38" connection="5"/>
+        <dia:connection handle="1" to="O37" connection="5"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O40">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.6714,16.2367"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="22.1058,14.166;34.7287,16.294"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="34.6714,16.2367"/>
+        <dia:point val="22.1631,14.2233"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O38" connection="0"/>
+        <dia:connection handle="1" to="O37" connection="0"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O41">
+      <dia:attribute name="obj_pos">
+        <dia:point val="37.85,18.7"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="25.3425,16.5925;37.9075,18.7575"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="37.85,18.7"/>
+        <dia:point val="25.4,16.65"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O38" connection="7"/>
+        <dia:connection handle="1" to="O37" connection="7"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O42">
+      <dia:attribute name="obj_pos">
+        <dia:point val="37.85,16.2367"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="25.3427,14.166;37.9073,16.294"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="37.85,16.2367"/>
+        <dia:point val="25.4,14.2233"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O38" connection="2"/>
+        <dia:connection handle="1" to="O37" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Geometric - Perfect Circle" version="1" id="O43">
+      <dia:attribute name="obj_pos">
+        <dia:point val="40.347,16.7742"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="40.297,16.7242;41.247,17.6742"/>
+      </dia:attribute>
+      <dia:attribute name="meta">
+        <dia:composite type="dict"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="40.347,16.7742"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="line_width">
+        <dia:real val="0.10000000000000001"/>
+      </dia:attribute>
+      <dia:attribute name="line_colour">
+        <dia:color val="#000000"/>
+      </dia:attribute>
+      <dia:attribute name="fill_colour">
+        <dia:color val="#ffffff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="0"/>
+        <dia:real val="1"/>
+      </dia:attribute>
+      <dia:attribute name="flip_horizontal">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="flip_vertical">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="subscale">
+        <dia:real val="1"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O44">
+      <dia:attribute name="obj_pos">
+        <dia:point val="41.197,17.1992"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="41.147,16.8388;49.6123,17.5624"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="41.197,17.1992"/>
+        <dia:point val="49.5005,17.2007"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O43" connection="3"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O45">
+      <dia:attribute name="obj_pos">
+        <dia:point val="42.4624,16.69"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="42.4624,16.095;47.1074,16.8425"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#pad 3 (source)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="42.4624,16.69"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O46">
+      <dia:attribute name="obj_pos">
+        <dia:point val="9.85,4.55"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="9.85,3.955;12.7275,6.3025"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#sink
+crop
+selection#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="9.85,4.55"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#0000ff"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O47">
+      <dia:attribute name="obj_pos">
+        <dia:point val="27.65,4.75"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="27.65,4.155;30.5275,6.5025"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#source
+crop
+selection#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="27.65,4.75"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#a020f0"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O48">
+      <dia:attribute name="obj_pos">
+        <dia:point val="10.55,6.6"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="7.7135,6.39438;10.6035,7.11605"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="10.55,6.6"/>
+        <dia:point val="7.825,6.8"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#0000ff"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="1" to="O9" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O49">
+      <dia:attribute name="obj_pos">
+        <dia:point val="10.45,6.55"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="5.48029,6.48236;10.5176,15.8387"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="10.45,6.55"/>
+        <dia:point val="5.55,15.74"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#0000ff"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="1" to="O30" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O50">
+      <dia:attribute name="obj_pos">
+        <dia:point val="27.5246,6.66071"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="25.406,6.59136;27.594,9.82122"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="27.5246,6.66071"/>
+        <dia:point val="25.4754,9.72825"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#a020f0"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="1" to="O18" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O51">
+      <dia:attribute name="obj_pos">
+        <dia:point val="27.5036,6.68935"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="25.2161,6.62775;27.5652,14.331"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="27.5036,6.68935"/>
+        <dia:point val="25.4,14.2233"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#a020f0"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="1" to="O37" connection="2"/>
+      </dia:connections>
+    </dia:object>
+  </dia:layer>
+</dia:diagram>
diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-full.svg b/Documentation/DocBook/media/v4l/subdev-image-processing-full.svg
new file mode 100644
index 000000000000..3322cf4c0093
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/subdev-image-processing-full.svg
@@ -0,0 +1,163 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
+<svg width="59cm" height="18cm" viewBox="-186 71 1178 346" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+  <g>
+    <rect style="fill: #ffffff" x="318.9" y="129" width="208.1" height="249"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff765a" x="318.9" y="129" width="208.1" height="249"/>
+  </g>
+  <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="-2" y="73" width="806" height="343"/>
+  <g>
+    <ellipse style="fill: #ffffff" cx="-12.5" cy="166.712" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="-12.5" cy="166.712" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="-12.5" cy="166.712" rx="8.5" ry="8.5"/>
+  </g>
+  <g>
+    <ellipse style="fill: #ffffff" cx="815.232" cy="205.184" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="815.232" cy="205.184" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="815.232" cy="205.184" rx="8.5" ry="8.5"/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="-184.5" y1="167" x2="-30.7361" y2="166.729"/>
+    <polygon style="fill: #000000" points="-23.2361,166.716 -33.2272,171.734 -30.7361,166.729 -33.2449,161.734 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="-23.2361,166.716 -33.2272,171.734 -30.7361,166.729 -33.2449,161.734 "/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="823.732" y1="205.184" x2="980.066" y2="205.212"/>
+    <polygon style="fill: #000000" points="987.566,205.214 977.565,210.212 980.066,205.212 977.567,200.212 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="987.566,205.214 977.565,210.212 980.066,205.212 977.567,200.212 "/>
+  </g>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="-139.96" y="155">
+    <tspan x="-139.96" y="155">pad 0 (sink)</tspan>
+  </text>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="849.04" y="195">
+    <tspan x="849.04" y="195">pad 2 (source)</tspan>
+  </text>
+  <g>
+    <rect style="fill: #ffffff" x="5.5" y="120" width="159" height="104"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a52a2a" x="5.5" y="120" width="159" height="104"/>
+  </g>
+  <g>
+    <rect style="fill: #ffffff" x="62.5" y="136" width="94" height="77"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #0000ff" x="62.5" y="136" width="94" height="77"/>
+  </g>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="30.5" y="89">
+    <tspan x="30.5" y="89"></tspan>
+  </text>
+  <text style="fill: #a52a2a;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="9.53836" y="88.9138">
+    <tspan x="9.53836" y="88.9138">sink media</tspan>
+    <tspan x="9.53836" y="104.914">bus format</tspan>
+  </text>
+  <g>
+    <rect style="fill: #ffffff" x="333.644" y="185.65" width="165.2" height="172.478"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #00ff00" x="333.644" y="185.65" width="165.2" height="172.478"/>
+  </g>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="333.644" y1="358.128" x2="62.5" y2="213"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="333.644" y1="185.65" x2="62.5" y2="136"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="498.844" y1="358.128" x2="156.5" y2="213"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="498.844" y1="185.65" x2="156.5" y2="136"/>
+  <text style="fill: #00ff00;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="334.704" y="149.442">
+    <tspan x="334.704" y="149.442">sink compose</tspan>
+    <tspan x="334.704" y="165.442">selection (scaling)</tspan>
+  </text>
+  <g>
+    <rect style="fill: #ffffff" x="409.322" y="194.565" width="100.186" height="71.4523"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" x="409.322" y="194.565" width="100.186" height="71.4523"/>
+  </g>
+  <text style="fill: #8b6914;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="689.5" y="105.128">
+    <tspan x="689.5" y="105.128">source media</tspan>
+    <tspan x="689.5" y="121.128">bus format</tspan>
+  </text>
+  <g>
+    <rect style="fill: #ffffff" x="688.488" y="173.834" width="100.186" height="71.4523"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #8b6914" x="688.488" y="173.834" width="100.186" height="71.4523"/>
+  </g>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="688.488" y1="245.286" x2="409.322" y2="266.018"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="688.488" y1="173.834" x2="409.322" y2="194.565"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="788.674" y1="245.286" x2="509.508" y2="266.018"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="788.674" y1="173.834" x2="509.508" y2="194.565"/>
+  <text style="fill: #ff765a;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="325" y="103">
+    <tspan x="325" y="103">sink compose</tspan>
+    <tspan x="325" y="119">bounds selection</tspan>
+  </text>
+  <g>
+    <ellipse style="fill: #ffffff" cx="-12.0982" cy="341.512" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="-12.0982" cy="341.512" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="-12.0982" cy="341.512" rx="8.5" ry="8.5"/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="-184.098" y1="341.8" x2="-30.3343" y2="341.529"/>
+    <polygon style="fill: #000000" points="-22.8343,341.516 -32.8254,346.534 -30.3343,341.529 -32.8431,336.534 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="-22.8343,341.516 -32.8254,346.534 -30.3343,341.529 -32.8431,336.534 "/>
+  </g>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="-139" y="329">
+    <tspan x="-139" y="329">pad 1 (sink)</tspan>
+  </text>
+  <g>
+    <rect style="fill: #ffffff" x="7.80824" y="292.8" width="112.092" height="82.2"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a52a2a" x="7.80824" y="292.8" width="112.092" height="82.2"/>
+  </g>
+  <g>
+    <rect style="fill: #ffffff" x="52.9" y="314.8" width="58.1" height="50.2"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #0000ff" x="52.9" y="314.8" width="58.1" height="50.2"/>
+  </g>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="31.9" y="259.8">
+    <tspan x="31.9" y="259.8"></tspan>
+  </text>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="358.9" y1="251.9" x2="52.9" y2="314.8"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="358.9" y1="316" x2="52.9" y2="365"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="434" y1="316" x2="111" y2="365"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="434" y1="251.9" x2="111" y2="314.8"/>
+  <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #00ff00" x="358.9" y="251.9" width="75.1" height="64.1"/>
+  <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" x="443.262" y="284.466" width="64.738" height="48.534"/>
+  <g>
+    <rect style="fill: #ffffff" x="693.428" y="324.734" width="63.572" height="49.266"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #8b6914" x="693.428" y="324.734" width="63.572" height="49.266"/>
+  </g>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="693.428" y1="374" x2="443.262" y2="333"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="693.428" y1="324.734" x2="443.262" y2="284.466"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="757" y1="374" x2="508" y2="333"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="757" y1="324.734" x2="508" y2="284.466"/>
+  <g>
+    <ellipse style="fill: #ffffff" cx="815.44" cy="343.984" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="815.44" cy="343.984" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="815.44" cy="343.984" rx="8.5" ry="8.5"/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="823.94" y1="343.984" x2="980.274" y2="344.012"/>
+    <polygon style="fill: #000000" points="987.774,344.014 977.773,349.012 980.274,344.012 977.775,339.012 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="987.774,344.014 977.773,349.012 980.274,344.012 977.775,339.012 "/>
+  </g>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="849.248" y="333.8">
+    <tspan x="849.248" y="333.8">pad 3 (source)</tspan>
+  </text>
+  <text style="fill: #0000ff;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="197" y="91">
+    <tspan x="197" y="91">sink</tspan>
+    <tspan x="197" y="107">crop</tspan>
+    <tspan x="197" y="123">selection</tspan>
+  </text>
+  <text style="fill: #a020f0;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="553" y="95">
+    <tspan x="553" y="95">source</tspan>
+    <tspan x="553" y="111">crop</tspan>
+    <tspan x="553" y="127">selection</tspan>
+  </text>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #0000ff" x1="211" y1="132" x2="166.21" y2="135.287"/>
+    <polygon style="fill: #0000ff" points="158.73,135.836 168.337,130.118 166.21,135.287 169.069,140.091 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #0000ff" points="158.73,135.836 168.337,130.118 166.21,135.287 169.069,140.091 "/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #0000ff" x1="209" y1="131" x2="115.581" y2="306.209"/>
+    <polygon style="fill: #0000ff" points="112.052,312.827 112.345,301.65 115.581,306.209 121.169,306.355 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #0000ff" points="112.052,312.827 112.345,301.65 115.581,306.209 121.169,306.355 "/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" x1="550.492" y1="133.214" x2="514.916" y2="186.469"/>
+    <polygon style="fill: #a020f0" points="510.75,192.706 512.147,181.613 514.916,186.469 520.463,187.168 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" points="510.75,192.706 512.147,181.613 514.916,186.469 520.463,187.168 "/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" x1="550.072" y1="133.787" x2="510.618" y2="275.089"/>
+    <polygon style="fill: #a020f0" points="508.601,282.312 506.475,271.336 510.618,275.089 516.106,274.025 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" points="508.601,282.312 506.475,271.336 510.618,275.089 516.106,274.025 "/>
+  </g>
+</svg>
diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.dia b/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.dia
new file mode 100644
index 000000000000..0cd50a7bda80
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.dia
@@ -0,0 +1,1152 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<dia:diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/">
+  <dia:diagramdata>
+    <dia:attribute name="background">
+      <dia:color val="#ffffff"/>
+    </dia:attribute>
+    <dia:attribute name="pagebreak">
+      <dia:color val="#000099"/>
+    </dia:attribute>
+    <dia:attribute name="paper">
+      <dia:composite type="paper">
+        <dia:attribute name="name">
+          <dia:string>#A4#</dia:string>
+        </dia:attribute>
+        <dia:attribute name="tmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="bmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="lmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="rmargin">
+          <dia:real val="2.8222000598907471"/>
+        </dia:attribute>
+        <dia:attribute name="is_portrait">
+          <dia:boolean val="false"/>
+        </dia:attribute>
+        <dia:attribute name="scaling">
+          <dia:real val="0.49000000953674316"/>
+        </dia:attribute>
+        <dia:attribute name="fitto">
+          <dia:boolean val="false"/>
+        </dia:attribute>
+      </dia:composite>
+    </dia:attribute>
+    <dia:attribute name="grid">
+      <dia:composite type="grid">
+        <dia:attribute name="width_x">
+          <dia:real val="1"/>
+        </dia:attribute>
+        <dia:attribute name="width_y">
+          <dia:real val="1"/>
+        </dia:attribute>
+        <dia:attribute name="visible_x">
+          <dia:int val="1"/>
+        </dia:attribute>
+        <dia:attribute name="visible_y">
+          <dia:int val="1"/>
+        </dia:attribute>
+        <dia:composite type="color"/>
+      </dia:composite>
+    </dia:attribute>
+    <dia:attribute name="color">
+      <dia:color val="#d8e5e5"/>
+    </dia:attribute>
+    <dia:attribute name="guides">
+      <dia:composite type="guides">
+        <dia:attribute name="hguides"/>
+        <dia:attribute name="vguides"/>
+      </dia:composite>
+    </dia:attribute>
+  </dia:diagramdata>
+  <dia:layer name="Background" visible="true" active="true">
+    <dia:object type="Standard - Box" version="0" id="O0">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-0.4,6.5"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-0.45,6.45;39.95,22.9"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="-0.4,6.5"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="40.299999999999997"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="16.349999999999998"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O1">
+      <dia:attribute name="obj_pos">
+        <dia:point val="0.225,9.45"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="0.175,9.4;8.225,14.7"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="0.225,9.45"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="7.9499999999999975"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="5.1999999999999975"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#a52a2a"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O2">
+      <dia:attribute name="obj_pos">
+        <dia:point val="2.475,10.2"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="2.425,10.15;7.225,14.1"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="2.475,10.2"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="4.6999999999999975"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.8499999999999979"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#0000ff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O3">
+      <dia:attribute name="obj_pos">
+        <dia:point val="3,11.2"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="3,10.605;5.8775,12.9525"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#sink
+crop
+selection#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="3,11.2"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#0000ff"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O4">
+      <dia:attribute name="obj_pos">
+        <dia:point val="1.475,7.9"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="1.475,7.305;1.475,8.0525"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>##</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="1.475,7.9"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O5">
+      <dia:attribute name="obj_pos">
+        <dia:point val="0.426918,7.89569"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="0.426918,7.30069;3.90942,8.84819"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#sink media
+bus format#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="0.426918,7.89569"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#a52a2a"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O6">
+      <dia:attribute name="obj_pos">
+        <dia:point val="16.6822,9.28251"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="16.6322,9.23251;24.9922,17.9564"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="16.6822,9.28251"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="8.2600228398861297"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="8.6238900617957164"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#00ff00"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O7">
+      <dia:attribute name="obj_pos">
+        <dia:point val="16.6822,17.9064"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="2.41365,13.9886;16.7436,17.9678"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="16.6822,17.9064"/>
+        <dia:point val="2.475,14.05"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O6" connection="5"/>
+        <dia:connection handle="1" to="O2" connection="5"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O8">
+      <dia:attribute name="obj_pos">
+        <dia:point val="16.6822,9.28251"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="2.42188,9.22939;16.7353,10.2531"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="16.6822,9.28251"/>
+        <dia:point val="2.475,10.2"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O6" connection="0"/>
+        <dia:connection handle="1" to="O2" connection="0"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O9">
+      <dia:attribute name="obj_pos">
+        <dia:point val="24.9422,17.9064"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="7.11553,13.9905;25.0017,17.9659"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="24.9422,17.9064"/>
+        <dia:point val="7.175,14.05"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O6" connection="7"/>
+        <dia:connection handle="1" to="O2" connection="7"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O10">
+      <dia:attribute name="obj_pos">
+        <dia:point val="24.9422,9.28251"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="7.12249,9.23;24.9947,10.2525"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="24.9422,9.28251"/>
+        <dia:point val="7.175,10.2"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O6" connection="2"/>
+        <dia:connection handle="1" to="O2" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O11">
+      <dia:attribute name="obj_pos">
+        <dia:point val="16.7352,7.47209"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="16.7352,6.87709;22.5602,8.42459"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#sink compose
+selection (scaling)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="16.7352,7.47209"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#00ff00"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O12">
+      <dia:attribute name="obj_pos">
+        <dia:point val="19.1161,9.97825"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="19.0661,9.92825;24.1754,13.6009"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="19.1161,9.97825"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="5.009308462554376"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.5726155970598077"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#a020f0"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O13">
+      <dia:attribute name="obj_pos">
+        <dia:point val="27.1661,7.47209"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="27.1661,6.87709;30.0436,9.22459"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#source
+crop
+selection#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="27.1661,7.47209"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#a020f0"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O14">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.575,7.8564"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="34.575,7.2614;38.8975,8.8089"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#source media
+bus format#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="34.575,7.8564"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#8b6914"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O15">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.5244,11.2917"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="34.4744,11.2417;39.5837,14.9143"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="34.5244,11.2917"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="5.009308462554376"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.5726155970598077"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#8b6914"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O16">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.5244,14.8643"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="19.062,13.4968;34.5785,14.9184"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="34.5244,14.8643"/>
+        <dia:point val="19.1161,13.5509"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O15" connection="5"/>
+        <dia:connection handle="1" to="O12" connection="5"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O17">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.5244,11.2917"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="19.062,9.92418;34.5785,11.3458"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="34.5244,11.2917"/>
+        <dia:point val="19.1161,9.97825"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O15" connection="0"/>
+        <dia:connection handle="1" to="O12" connection="0"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O18">
+      <dia:attribute name="obj_pos">
+        <dia:point val="39.5337,14.8643"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="24.0713,13.4968;39.5878,14.9184"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="39.5337,14.8643"/>
+        <dia:point val="24.1254,13.5509"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O15" connection="7"/>
+        <dia:connection handle="1" to="O12" connection="7"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O19">
+      <dia:attribute name="obj_pos">
+        <dia:point val="39.5337,11.2917"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="24.0713,9.92418;39.5878,11.3458"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="39.5337,11.2917"/>
+        <dia:point val="24.1254,9.97825"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O15" connection="2"/>
+        <dia:connection handle="1" to="O12" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Geometric - Perfect Circle" version="1" id="O20">
+      <dia:attribute name="obj_pos">
+        <dia:point val="39.98,12.0742"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="39.93,12.0242;40.88,12.9742"/>
+      </dia:attribute>
+      <dia:attribute name="meta">
+        <dia:composite type="dict"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="39.98,12.0742"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="line_width">
+        <dia:real val="0.10000000000000001"/>
+      </dia:attribute>
+      <dia:attribute name="line_colour">
+        <dia:color val="#000000"/>
+      </dia:attribute>
+      <dia:attribute name="fill_colour">
+        <dia:color val="#ffffff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="0"/>
+        <dia:real val="1"/>
+      </dia:attribute>
+      <dia:attribute name="flip_horizontal">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="flip_vertical">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="subscale">
+        <dia:real val="1"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O21">
+      <dia:attribute name="obj_pos">
+        <dia:point val="40.83,12.4992"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="40.78,12.1388;49.2453,12.8624"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="40.83,12.4992"/>
+        <dia:point val="49.1335,12.5007"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O20" connection="3"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O22">
+      <dia:attribute name="obj_pos">
+        <dia:point val="42.0954,11.99"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="42.0954,11.395;46.7404,12.1425"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#pad 1 (source)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="42.0954,11.99"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Geometric - Perfect Circle" version="1" id="O23">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-1.44491,11.6506"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-1.49491,11.6006;-0.54491,12.5506"/>
+      </dia:attribute>
+      <dia:attribute name="meta">
+        <dia:composite type="dict"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="-1.44491,11.6506"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="line_width">
+        <dia:real val="0.10000000000000001"/>
+      </dia:attribute>
+      <dia:attribute name="line_colour">
+        <dia:color val="#000000"/>
+      </dia:attribute>
+      <dia:attribute name="fill_colour">
+        <dia:color val="#ffffff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="0"/>
+        <dia:real val="1"/>
+      </dia:attribute>
+      <dia:attribute name="flip_horizontal">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="flip_vertical">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="subscale">
+        <dia:real val="1"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O24">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-9.61991,12.09"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-9.67,11.7149;-1.33311,12.4385"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="-9.61991,12.09"/>
+        <dia:point val="-1.44491,12.0756"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="1" to="O23" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O25">
+      <dia:attribute name="obj_pos">
+        <dia:point val="-7.39291,11.49"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="-7.39291,10.895;-3.58791,11.6425"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#pad 0 (sink)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="-7.39291,11.49"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O26">
+      <dia:attribute name="obj_pos">
+        <dia:point val="19.4911,13.8333"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="19.4411,13.7833;24.5504,17.4559"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="19.4911,13.8333"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="5.009308462554376"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.5726155970598077"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#a020f0"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Box" version="0" id="O27">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.4994,17.2967"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="34.4494,17.2467;39.5587,20.9193"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="34.4994,17.2967"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="5.009308462554376"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="3.5726155970598077"/>
+      </dia:attribute>
+      <dia:attribute name="border_width">
+        <dia:real val="0.10000000149011612"/>
+      </dia:attribute>
+      <dia:attribute name="border_color">
+        <dia:color val="#8b6914"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O28">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.4994,20.8693"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="19.4311,17.3459;34.5594,20.9293"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="34.4994,20.8693"/>
+        <dia:point val="19.4911,17.4059"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O27" connection="5"/>
+        <dia:connection handle="1" to="O26" connection="5"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O29">
+      <dia:attribute name="obj_pos">
+        <dia:point val="34.4994,17.2967"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="19.4311,13.7733;34.5594,17.3567"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="34.4994,17.2967"/>
+        <dia:point val="19.4911,13.8333"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O27" connection="0"/>
+        <dia:connection handle="1" to="O26" connection="0"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O30">
+      <dia:attribute name="obj_pos">
+        <dia:point val="39.5087,20.8693"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="24.4404,17.3459;39.5687,20.9293"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="39.5087,20.8693"/>
+        <dia:point val="24.5004,17.4059"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O27" connection="7"/>
+        <dia:connection handle="1" to="O26" connection="7"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O31">
+      <dia:attribute name="obj_pos">
+        <dia:point val="39.5087,17.2967"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="24.4404,13.7733;39.5687,17.3567"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="39.5087,17.2967"/>
+        <dia:point val="24.5004,13.8333"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#e60505"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="4"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O27" connection="2"/>
+        <dia:connection handle="1" to="O26" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Geometric - Perfect Circle" version="1" id="O32">
+      <dia:attribute name="obj_pos">
+        <dia:point val="39.855,18.7792"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="39.805,18.7292;40.755,19.6792"/>
+      </dia:attribute>
+      <dia:attribute name="meta">
+        <dia:composite type="dict"/>
+      </dia:attribute>
+      <dia:attribute name="elem_corner">
+        <dia:point val="39.855,18.7792"/>
+      </dia:attribute>
+      <dia:attribute name="elem_width">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="elem_height">
+        <dia:real val="0.84999999999999787"/>
+      </dia:attribute>
+      <dia:attribute name="line_width">
+        <dia:real val="0.10000000000000001"/>
+      </dia:attribute>
+      <dia:attribute name="line_colour">
+        <dia:color val="#000000"/>
+      </dia:attribute>
+      <dia:attribute name="fill_colour">
+        <dia:color val="#ffffff"/>
+      </dia:attribute>
+      <dia:attribute name="show_background">
+        <dia:boolean val="true"/>
+      </dia:attribute>
+      <dia:attribute name="line_style">
+        <dia:enum val="0"/>
+        <dia:real val="1"/>
+      </dia:attribute>
+      <dia:attribute name="flip_horizontal">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="flip_vertical">
+        <dia:boolean val="false"/>
+      </dia:attribute>
+      <dia:attribute name="subscale">
+        <dia:real val="1"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O33">
+      <dia:attribute name="obj_pos">
+        <dia:point val="40.705,19.2042"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="40.655,18.8438;49.1203,19.5674"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="40.705,19.2042"/>
+        <dia:point val="49.0085,19.2057"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="0" to="O32" connection="3"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Text" version="1" id="O34">
+      <dia:attribute name="obj_pos">
+        <dia:point val="41.9704,18.695"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="41.9704,18.1;46.6154,18.8475"/>
+      </dia:attribute>
+      <dia:attribute name="text">
+        <dia:composite type="text">
+          <dia:attribute name="string">
+            <dia:string>#pad 2 (source)#</dia:string>
+          </dia:attribute>
+          <dia:attribute name="font">
+            <dia:font family="sans" style="0" name="Helvetica"/>
+          </dia:attribute>
+          <dia:attribute name="height">
+            <dia:real val="0.80000000000000004"/>
+          </dia:attribute>
+          <dia:attribute name="pos">
+            <dia:point val="41.9704,18.695"/>
+          </dia:attribute>
+          <dia:attribute name="color">
+            <dia:color val="#000000"/>
+          </dia:attribute>
+          <dia:attribute name="alignment">
+            <dia:enum val="0"/>
+          </dia:attribute>
+        </dia:composite>
+      </dia:attribute>
+      <dia:attribute name="valign">
+        <dia:enum val="3"/>
+      </dia:attribute>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O35">
+      <dia:attribute name="obj_pos">
+        <dia:point val="27.3,9.55"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="24.0146,9.49376;27.3562,10.255"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="27.3,9.55"/>
+        <dia:point val="24.1254,9.97825"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#a020f0"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="1" to="O12" connection="2"/>
+      </dia:connections>
+    </dia:object>
+    <dia:object type="Standard - Line" version="0" id="O36">
+      <dia:attribute name="obj_pos">
+        <dia:point val="27.3454,9.53624"/>
+      </dia:attribute>
+      <dia:attribute name="obj_bb">
+        <dia:rectangle val="24.4311,9.46695;27.4147,13.9265"/>
+      </dia:attribute>
+      <dia:attribute name="conn_endpoints">
+        <dia:point val="27.3454,9.53624"/>
+        <dia:point val="24.5004,13.8333"/>
+      </dia:attribute>
+      <dia:attribute name="numcp">
+        <dia:int val="1"/>
+      </dia:attribute>
+      <dia:attribute name="line_color">
+        <dia:color val="#a020f0"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow">
+        <dia:enum val="22"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_length">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:attribute name="end_arrow_width">
+        <dia:real val="0.5"/>
+      </dia:attribute>
+      <dia:connections>
+        <dia:connection handle="1" to="O26" connection="2"/>
+      </dia:connections>
+    </dia:object>
+  </dia:layer>
+</dia:diagram>
diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.svg b/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.svg
new file mode 100644
index 000000000000..2340c0f8bc92
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.svg
@@ -0,0 +1,116 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
+<svg width="59cm" height="17cm" viewBox="-194 128 1179 330" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+  <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="-8" y="130" width="806" height="327"/>
+  <g>
+    <rect style="fill: #ffffff" x="4.5" y="189" width="159" height="104"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a52a2a" x="4.5" y="189" width="159" height="104"/>
+  </g>
+  <g>
+    <rect style="fill: #ffffff" x="49.5" y="204" width="94" height="77"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #0000ff" x="49.5" y="204" width="94" height="77"/>
+  </g>
+  <text style="fill: #0000ff;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="60" y="224">
+    <tspan x="60" y="224">sink</tspan>
+    <tspan x="60" y="240">crop</tspan>
+    <tspan x="60" y="256">selection</tspan>
+  </text>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="29.5" y="158">
+    <tspan x="29.5" y="158"></tspan>
+  </text>
+  <text style="fill: #a52a2a;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="8.53836" y="157.914">
+    <tspan x="8.53836" y="157.914">sink media</tspan>
+    <tspan x="8.53836" y="173.914">bus format</tspan>
+  </text>
+  <g>
+    <rect style="fill: #ffffff" x="333.644" y="185.65" width="165.2" height="172.478"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #00ff00" x="333.644" y="185.65" width="165.2" height="172.478"/>
+  </g>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="333.644" y1="358.128" x2="49.5" y2="281"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="333.644" y1="185.65" x2="49.5" y2="204"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="498.844" y1="358.128" x2="143.5" y2="281"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="498.844" y1="185.65" x2="143.5" y2="204"/>
+  <text style="fill: #00ff00;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="334.704" y="149.442">
+    <tspan x="334.704" y="149.442">sink compose</tspan>
+    <tspan x="334.704" y="165.442">selection (scaling)</tspan>
+  </text>
+  <g>
+    <rect style="fill: #ffffff" x="382.322" y="199.565" width="100.186" height="71.4523"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" x="382.322" y="199.565" width="100.186" height="71.4523"/>
+  </g>
+  <text style="fill: #a020f0;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="543.322" y="149.442">
+    <tspan x="543.322" y="149.442">source</tspan>
+    <tspan x="543.322" y="165.442">crop</tspan>
+    <tspan x="543.322" y="181.442">selection</tspan>
+  </text>
+  <text style="fill: #8b6914;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="691.5" y="157.128">
+    <tspan x="691.5" y="157.128">source media</tspan>
+    <tspan x="691.5" y="173.128">bus format</tspan>
+  </text>
+  <g>
+    <rect style="fill: #ffffff" x="690.488" y="225.834" width="100.186" height="71.4523"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #8b6914" x="690.488" y="225.834" width="100.186" height="71.4523"/>
+  </g>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="690.488" y1="297.286" x2="382.322" y2="271.018"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="690.488" y1="225.834" x2="382.322" y2="199.565"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="790.674" y1="297.286" x2="482.508" y2="271.018"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="790.674" y1="225.834" x2="482.508" y2="199.565"/>
+  <g>
+    <ellipse style="fill: #ffffff" cx="808.1" cy="249.984" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="808.1" cy="249.984" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="808.1" cy="249.984" rx="8.5" ry="8.5"/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="816.6" y1="249.984" x2="972.934" y2="250.012"/>
+    <polygon style="fill: #000000" points="980.434,250.014 970.433,255.012 972.934,250.012 970.435,245.012 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="980.434,250.014 970.433,255.012 972.934,250.012 970.435,245.012 "/>
+  </g>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="841.908" y="239.8">
+    <tspan x="841.908" y="239.8">pad 1 (source)</tspan>
+  </text>
+  <g>
+    <ellipse style="fill: #ffffff" cx="-20.3982" cy="241.512" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="-20.3982" cy="241.512" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="-20.3982" cy="241.512" rx="8.5" ry="8.5"/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="-192.398" y1="241.8" x2="-38.6343" y2="241.529"/>
+    <polygon style="fill: #000000" points="-31.1343,241.516 -41.1254,246.534 -38.6343,241.529 -41.1431,236.534 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="-31.1343,241.516 -41.1254,246.534 -38.6343,241.529 -41.1431,236.534 "/>
+  </g>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="-147.858" y="229.8">
+    <tspan x="-147.858" y="229.8">pad 0 (sink)</tspan>
+  </text>
+  <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" x="389.822" y="276.666" width="100.186" height="71.4523"/>
+  <g>
+    <rect style="fill: #ffffff" x="689.988" y="345.934" width="100.186" height="71.4523"/>
+    <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #8b6914" x="689.988" y="345.934" width="100.186" height="71.4523"/>
+  </g>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="689.988" y1="417.386" x2="389.822" y2="348.118"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="689.988" y1="345.934" x2="389.822" y2="276.666"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="790.174" y1="417.386" x2="490.008" y2="348.118"/>
+  <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 4; stroke: #e60505" x1="790.174" y1="345.934" x2="490.008" y2="276.666"/>
+  <g>
+    <ellipse style="fill: #ffffff" cx="805.6" cy="384.084" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="805.6" cy="384.084" rx="8.5" ry="8.5"/>
+    <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="805.6" cy="384.084" rx="8.5" ry="8.5"/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="814.1" y1="384.084" x2="970.434" y2="384.112"/>
+    <polygon style="fill: #000000" points="977.934,384.114 967.933,389.112 970.434,384.112 967.935,379.112 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="977.934,384.114 967.933,389.112 970.434,384.112 967.935,379.112 "/>
+  </g>
+  <text style="fill: #000000;text-anchor:start;font-size:12.8;font-family:sanserif;font-style:normal;font-weight:normal" x="839.408" y="373.9">
+    <tspan x="839.408" y="373.9">pad 2 (source)</tspan>
+  </text>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" x1="546" y1="191" x2="492.157" y2="198.263"/>
+    <polygon style="fill: #a020f0" points="484.724,199.266 493.966,192.974 492.157,198.263 495.303,202.884 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" points="484.724,199.266 493.966,192.974 492.157,198.263 495.303,202.884 "/>
+  </g>
+  <g>
+    <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" x1="546.908" y1="190.725" x2="495.383" y2="268.548"/>
+    <polygon style="fill: #a020f0" points="491.242,274.802 492.594,263.703 495.383,268.548 500.932,269.224 "/>
+    <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #a020f0" points="491.242,274.802 492.594,263.703 495.383,268.548 500.932,269.224 "/>
+  </g>
+</svg>
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index 8ae38876172e..008c2d73a484 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -28,8 +28,8 @@ documentation.</contrib>
         <firstname>Hans</firstname>
         <surname>Verkuil</surname>
         <contrib>Designed and documented the VIDIOC_LOG_STATUS ioctl,
-the extended control ioctls and major parts of the sliced VBI
-API.</contrib>
+the extended control ioctls, major parts of the sliced VBI API, the
+MPEG encoder and decoder APIs and the DV Timings API.</contrib>
         <affiliation>
           <address>
             <email>hverkuil@xs4all.nl</email>
@@ -96,6 +96,17 @@ Remote Controller chapter.</contrib>
           </address>
         </affiliation>
       </author>
+
+      <author>
+        <firstname>Sakari</firstname>
+        <surname>Ailus</surname>
+        <contrib>Subdev selections API.</contrib>
+        <affiliation>
+          <address>
+            <email>sakari.ailus@iki.fi</email>
+          </address>
+        </affiliation>
+      </author>
     </authorgroup>
 
     <copyright>
@@ -112,6 +123,7 @@ Remote Controller chapter.</contrib>
       <year>2009</year>
       <year>2010</year>
       <year>2011</year>
+      <year>2012</year>
       <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
 Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
         Pawel Osciak</holder>
@@ -128,6 +140,28 @@ structs, ioctls) must be noted in more detail in the history chapter
 applications. -->
 
       <revision>
+        <revnumber>3.5</revnumber>
+        <date>2012-05-07</date>
+        <authorinitials>sa, sn</authorinitials>
+        <revremark>Added V4L2_CTRL_TYPE_INTEGER_MENU and V4L2 subdev
+            selections API. Improved the description of V4L2_CID_COLORFX
+            control, added V4L2_CID_COLORFX_CBCR control.
+            Added camera controls V4L2_CID_AUTO_EXPOSURE_BIAS,
+            V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE, V4L2_CID_IMAGE_STABILIZATION,
+            V4L2_CID_ISO_SENSITIVITY, V4L2_CID_ISO_SENSITIVITY_AUTO,
+            V4L2_CID_EXPOSURE_METERING, V4L2_CID_SCENE_MODE,
+            V4L2_CID_3A_LOCK, V4L2_CID_AUTO_FOCUS_START,
+            V4L2_CID_AUTO_FOCUS_STOP, V4L2_CID_AUTO_FOCUS_STATUS
+            and V4L2_CID_AUTO_FOCUS_RANGE.
+        </revremark>
+        <date>2012-05-01</date>
+        <authorinitials>hv</authorinitials>
+        <revremark>Added VIDIOC_ENUM_DV_TIMINGS, VIDIOC_QUERY_DV_TIMINGS and
+        VIDIOC_DV_TIMINGS_CAP.
+        </revremark>
+      </revision>
+
+      <revision>
         <revnumber>3.4</revnumber>
         <date>2012-01-25</date>
         <authorinitials>sn</authorinitials>
@@ -433,7 +467,7 @@ and discussions on the V4L mailing list.</revremark>
 </partinfo>
 
 <title>Video for Linux Two API Specification</title>
- <subtitle>Revision 3.3</subtitle>
+ <subtitle>Revision 3.5</subtitle>
 
   <chapter id="common">
     &sub-common;
@@ -491,10 +525,12 @@ and discussions on the V4L mailing list.</revremark>
     &sub-dbg-g-register;
     &sub-decoder-cmd;
     &sub-dqevent;
+    &sub-dv-timings-cap;
     &sub-encoder-cmd;
     &sub-enumaudio;
     &sub-enumaudioout;
     &sub-enum-dv-presets;
+    &sub-enum-dv-timings;
     &sub-enum-fmt;
     &sub-enum-framesizes;
     &sub-enum-frameintervals;
@@ -524,13 +560,14 @@ and discussions on the V4L mailing list.</revremark>
     &sub-g-tuner;
     &sub-log-status;
     &sub-overlay;
+    &sub-prepare-buf;
     &sub-qbuf;
     &sub-querybuf;
     &sub-querycap;
     &sub-queryctrl;
     &sub-query-dv-preset;
+    &sub-query-dv-timings;
     &sub-querystd;
-    &sub-prepare-buf;
     &sub-reqbufs;
     &sub-s-hw-freq-seek;
     &sub-streamon;
@@ -540,6 +577,7 @@ and discussions on the V4L mailing list.</revremark>
     &sub-subdev-g-crop;
     &sub-subdev-g-fmt;
     &sub-subdev-g-frame-interval;
+    &sub-subdev-g-selection;
     &sub-subscribe-event;
     <!-- End of ioctls. -->
     &sub-mmap;
diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
index 73ae8a6cd004..a2474ecb574a 100644
--- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
@@ -48,6 +48,12 @@
   <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>This ioctl is used to create buffers for <link linkend="mmap">memory
 mapped</link> or <link linkend="userp">user pointer</link>
 I/O. It can be used as an alternative or in addition to the
@@ -94,14 +100,15 @@ information.</para>
             <entry>The number of buffers requested or granted.</entry>
           </row>
           <row>
-            <entry>&v4l2-memory;</entry>
+            <entry>__u32</entry>
             <entry><structfield>memory</structfield></entry>
             <entry>Applications set this field to
 <constant>V4L2_MEMORY_MMAP</constant> or
-<constant>V4L2_MEMORY_USERPTR</constant>.</entry>
+<constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory"
+/></entry>
           </row>
           <row>
-            <entry>&v4l2-format;</entry>
+            <entry>struct&nbsp;v4l2_format</entry>
             <entry><structfield>format</structfield></entry>
             <entry>Filled in by the application, preserved by the driver.</entry>
           </row>
diff --git a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml
index b4f2f255211e..f1bac2c6e978 100644
--- a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml
@@ -65,7 +65,7 @@ output.</para>
         &cs-str;
         <tbody valign="top">
           <row>
-            <entry>&v4l2-buf-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry>Type of the data stream, set by the application.
 Only these types are valid here:
@@ -73,7 +73,7 @@ Only these types are valid here:
 <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
 <constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
 defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
-and higher.</entry>
+and higher. See <xref linkend="v4l2-buf-type" />.</entry>
           </row>
           <row>
             <entry>struct <link linkend="v4l2-rect-crop">v4l2_rect</link></entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index e8714aa16433..98a856f9ec30 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -89,7 +89,7 @@
           <row>
             <entry></entry>
             <entry>&v4l2-event-frame-sync;</entry>
-            <entry><structfield>frame</structfield></entry>
+            <entry><structfield>frame_sync</structfield></entry>
             <entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
           </row>
           <row>
diff --git a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml
new file mode 100644
index 000000000000..6673ce582050
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml
@@ -0,0 +1,211 @@
+<refentry id="vidioc-dv-timings-cap">
+  <refmeta>
+    <refentrytitle>ioctl VIDIOC_DV_TIMINGS_CAP</refentrytitle>
+    &manvol;
+  </refmeta>
+
+  <refnamediv>
+    <refname>VIDIOC_DV_TIMINGS_CAP</refname>
+    <refpurpose>The capabilities of the Digital Video receiver/transmitter</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_timings_cap *<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_DV_TIMINGS_CAP</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>To query the available timings, applications initialize the
+<structfield>index</structfield> field and zero the reserved array of &v4l2-dv-timings-cap;
+and call the <constant>VIDIOC_DV_TIMINGS_CAP</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 supported DV timings,
+applications shall begin at index zero, incrementing by one until the
+driver returns <errorcode>EINVAL</errorcode>. Note that drivers may enumerate a
+different set of DV timings after switching the video input or
+output.</para>
+
+    <table pgwide="1" frame="none" id="v4l2-bt-timings-cap">
+      <title>struct <structname>v4l2_bt_timings_cap</structname></title>
+      <tgroup cols="3">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>min_width</structfield></entry>
+            <entry>Minimum width of the active video in pixels.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>max_width</structfield></entry>
+            <entry>Maximum width of the active video in pixels.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>min_height</structfield></entry>
+            <entry>Minimum height of the active video in lines.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>max_height</structfield></entry>
+            <entry>Maximum height of the active video in lines.</entry>
+          </row>
+          <row>
+            <entry>__u64</entry>
+            <entry><structfield>min_pixelclock</structfield></entry>
+            <entry>Minimum pixelclock frequency in Hz.</entry>
+          </row>
+          <row>
+            <entry>__u64</entry>
+            <entry><structfield>max_pixelclock</structfield></entry>
+            <entry>Maximum pixelclock frequency in Hz.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>standards</structfield></entry>
+            <entry>The video standard(s) supported by the hardware.
+            See <xref linkend="dv-bt-standards"/> for a list of standards.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>capabilities</structfield></entry>
+            <entry>Several flags giving more information about the capabilities.
+            See <xref linkend="dv-bt-cap-capabilities"/> for a description of the flags.
+            </entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>reserved</structfield>[16]</entry>
+            <entry></entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <table pgwide="1" frame="none" id="v4l2-dv-timings-cap">
+      <title>struct <structname>v4l2_dv_timings_cap</structname></title>
+      <tgroup cols="4">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>type</structfield></entry>
+            <entry>Type of DV timings as listed in <xref linkend="dv-timing-types"/>.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>reserved</structfield>[3]</entry>
+            <entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
+          </row>
+          <row>
+            <entry>union</entry>
+            <entry><structfield></structfield></entry>
+            <entry></entry>
+          </row>
+          <row>
+            <entry></entry>
+            <entry>&v4l2-bt-timings-cap;</entry>
+            <entry><structfield>bt</structfield></entry>
+            <entry>BT.656/1120 timings capabilities of the hardware.</entry>
+          </row>
+          <row>
+            <entry></entry>
+            <entry>__u32</entry>
+            <entry><structfield>raw_data</structfield>[32]</entry>
+            <entry></entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <table pgwide="1" frame="none" id="dv-bt-cap-capabilities">
+      <title>DV BT Timing capabilities</title>
+      <tgroup cols="2">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>Flag</entry>
+            <entry>Description</entry>
+          </row>
+          <row>
+            <entry></entry>
+            <entry></entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_BT_CAP_INTERLACED</entry>
+            <entry>Interlaced formats are supported.
+            </entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_BT_CAP_PROGRESSIVE</entry>
+            <entry>Progressive formats are supported.
+            </entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_BT_CAP_REDUCED_BLANKING</entry>
+            <entry>CVT/GTF specific: the timings can make use of reduced blanking (CVT)
+or the 'Secondary GTF' curve (GTF).
+            </entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_BT_CAP_CUSTOM</entry>
+            <entry>Can support non-standard timings, i.e. timings not belonging to the
+standards set in the <structfield>standards</structfield> field.
+            </entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    &return-value;
+  </refsect1>
+</refentry>
+
+<!--
+Local Variables:
+mode: sgml
+sgml-parent-document: "v4l2.sgml"
+indent-tabs-mode: nil
+End:
+-->
diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml
index 0be17c232d3a..509f0012d2a6 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml
@@ -48,6 +48,10 @@
   <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
diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml
new file mode 100644
index 000000000000..24c3bf4fd29a
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml
@@ -0,0 +1,119 @@
+<refentry id="vidioc-enum-dv-timings">
+  <refmeta>
+    <refentrytitle>ioctl VIDIOC_ENUM_DV_TIMINGS</refentrytitle>
+    &manvol;
+  </refmeta>
+
+  <refnamediv>
+    <refname>VIDIOC_ENUM_DV_TIMINGS</refname>
+    <refpurpose>Enumerate supported Digital Video timings</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_enum_dv_timings *<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_TIMINGS</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>While some DV receivers or transmitters support a wide range of timings, others
+support only a limited number of timings. With this ioctl applications can enumerate a list
+of known supported timings. Call &VIDIOC-DV-TIMINGS-CAP; to check if it also supports other
+standards or even custom timings that are not in this list.</para>
+
+    <para>To query the available timings, applications initialize the
+<structfield>index</structfield> field and zero the reserved array of &v4l2-enum-dv-timings;
+and call the <constant>VIDIOC_ENUM_DV_TIMINGS</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 supported DV timings,
+applications shall begin at index zero, incrementing by one until the
+driver returns <errorcode>EINVAL</errorcode>. Note that drivers may enumerate a
+different set of DV timings after switching the video input or
+output.</para>
+
+    <table pgwide="1" frame="none" id="v4l2-enum-dv-timings">
+      <title>struct <structname>v4l2_enum_dv_timings</structname></title>
+      <tgroup cols="3">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>index</structfield></entry>
+            <entry>Number of the DV timings, set by the
+application.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>reserved</structfield>[3]</entry>
+            <entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
+          </row>
+          <row>
+            <entry>&v4l2-dv-timings;</entry>
+            <entry><structfield>timings</structfield></entry>
+            <entry>The timings.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    &return-value;
+
+    <variablelist>
+      <varlistentry>
+        <term><errorcode>EINVAL</errorcode></term>
+        <listitem>
+          <para>The &v4l2-enum-dv-timings; <structfield>index</structfield>
+is out of bounds.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+</refentry>
+
+<!--
+Local Variables:
+mode: sgml
+sgml-parent-document: "v4l2.sgml"
+indent-tabs-mode: nil
+End:
+-->
diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml
index 347d142e7431..81ebe48317fe 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml
@@ -71,7 +71,7 @@ the application. This is in no way related to the <structfield>
 pixelformat</structfield> field.</entry>
           </row>
           <row>
-            <entry>&v4l2-buf-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry>Type of the data stream, set by the application.
 Only these types are valid here:
@@ -81,7 +81,7 @@ Only these types are valid here:
 <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>,
 <constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
 defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
-and higher.</entry>
+and higher. See <xref linkend="v4l2-buf-type" />.</entry>
           </row>
           <row>
             <entry>__u32</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
index 9b8efcd6e947..46d5a044a537 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml
@@ -285,7 +285,7 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
           <row>
             <entry><constant>V4L2_IN_CAP_CUSTOM_TIMINGS</constant></entry>
             <entry>0x00000002</entry>
-            <entry>This input supports setting custom video timings by using VIDIOC_S_DV_TIMINGS.</entry>
+            <entry>This input supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
           </row>
           <row>
             <entry><constant>V4L2_IN_CAP_STD</constant></entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
index a64d5ef103fa..428020000ef0 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
@@ -170,7 +170,7 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
           <row>
             <entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry>
             <entry>0x00000002</entry>
-            <entry>This output supports setting custom video timings by using VIDIOC_S_DV_TIMINGS.</entry>
+            <entry>This output supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry>
           </row>
           <row>
             <entry><constant>V4L2_OUT_CAP_STD</constant></entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-crop.xml b/Documentation/DocBook/media/v4l/vidioc-g-crop.xml
index 01a50640dce0..c4ff3b1887fb 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-crop.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-crop.xml
@@ -100,14 +100,14 @@ changed and <constant>VIDIOC_S_CROP</constant> returns the
         &cs-str;
         <tbody valign="top">
           <row>
-            <entry>&v4l2-buf-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry>Type of the data stream, set by the application.
 Only these types are valid here: <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
 <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
 <constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
 defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
-and higher.</entry>
+and higher. See <xref linkend="v4l2-buf-type" />.</entry>
           </row>
           <row>
             <entry>&v4l2-rect;</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml b/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml
index 7940c1149393..61be9fa3803a 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml
@@ -48,6 +48,12 @@
 
   <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.
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml
index 4a8648ae9a63..eda1a2991bbe 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml
@@ -7,7 +7,7 @@
   <refnamediv>
     <refname>VIDIOC_G_DV_TIMINGS</refname>
     <refname>VIDIOC_S_DV_TIMINGS</refname>
-    <refpurpose>Get or set custom DV timings for input or output</refpurpose>
+    <refpurpose>Get or set DV timings for input or output</refpurpose>
   </refnamediv>
 
   <refsynopsisdiv>
@@ -48,12 +48,15 @@
 
   <refsect1>
     <title>Description</title>
-    <para>To set custom DV timings for the input or output, applications use the
-<constant>VIDIOC_S_DV_TIMINGS</constant> ioctl and to get the current custom timings,
+    <para>To set DV timings for the input or output, applications use the
+<constant>VIDIOC_S_DV_TIMINGS</constant> ioctl and to get the current timings,
 applications use the <constant>VIDIOC_G_DV_TIMINGS</constant> ioctl. The detailed timing
 information is filled in using the structure &v4l2-dv-timings;. These ioctls take
 a pointer to the &v4l2-dv-timings; structure as argument. If the ioctl is not supported
 or the timing values are not correct, the driver returns &EINVAL;.</para>
+<para>The <filename>linux/v4l2-dv-timings.h</filename> header can be used to get the
+timings of the formats in the <xref linkend="cea861" /> and <xref linkend="vesadmt" />
+standards.</para>
   </refsect1>
 
   <refsect1>
@@ -83,12 +86,13 @@ or the timing values are not correct, the driver returns &EINVAL;.</para>
           <row>
             <entry>__u32</entry>
             <entry><structfield>width</structfield></entry>
-            <entry>Width of the active video in pixels</entry>
+            <entry>Width of the active video in pixels.</entry>
           </row>
           <row>
             <entry>__u32</entry>
             <entry><structfield>height</structfield></entry>
-            <entry>Height of the active video in lines</entry>
+            <entry>Height of the active video frame in lines. So for interlaced formats the
+            height of the active video in each field is <structfield>height</structfield>/2.</entry>
           </row>
           <row>
             <entry>__u32</entry>
@@ -125,32 +129,52 @@ bit 0 (V4L2_DV_VSYNC_POS_POL) is for vertical sync polarity and bit 1 (V4L2_DV_H
           <row>
             <entry>__u32</entry>
             <entry><structfield>vfrontporch</structfield></entry>
-            <entry>Vertical front porch in lines</entry>
+            <entry>Vertical front porch in lines. For interlaced formats this refers to the
+            odd field (aka field 1).</entry>
           </row>
           <row>
             <entry>__u32</entry>
             <entry><structfield>vsync</structfield></entry>
-            <entry>Vertical sync length in lines</entry>
+            <entry>Vertical sync length in lines. For interlaced formats this refers to the
+            odd field (aka field 1).</entry>
           </row>
           <row>
             <entry>__u32</entry>
             <entry><structfield>vbackporch</structfield></entry>
-            <entry>Vertical back porch in lines</entry>
+            <entry>Vertical back porch in lines. For interlaced formats this refers to the
+            odd field (aka field 1).</entry>
           </row>
           <row>
             <entry>__u32</entry>
             <entry><structfield>il_vfrontporch</structfield></entry>
-            <entry>Vertical front porch in lines for bottom field of interlaced field formats</entry>
+            <entry>Vertical front porch in lines for the even field (aka field 2) of
+            interlaced field formats.</entry>
           </row>
           <row>
             <entry>__u32</entry>
             <entry><structfield>il_vsync</structfield></entry>
-            <entry>Vertical sync length in lines for bottom field of interlaced field formats</entry>
+            <entry>Vertical sync length in lines for the even field (aka field 2) of
+            interlaced field formats.</entry>
           </row>
           <row>
             <entry>__u32</entry>
             <entry><structfield>il_vbackporch</structfield></entry>
-            <entry>Vertical back porch in lines for bottom field of interlaced field formats</entry>
+            <entry>Vertical back porch in lines for the even field (aka field 2) of
+            interlaced field formats.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>standards</structfield></entry>
+            <entry>The video standard(s) this format belongs to. This will be filled in by
+            the driver. Applications must set this to 0. See <xref linkend="dv-bt-standards"/>
+            for a list of standards.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>flags</structfield></entry>
+            <entry>Several flags giving more information about the format.
+            See <xref linkend="dv-bt-flags"/> for a description of the flags.
+            </entry>
           </row>
         </tbody>
       </tgroup>
@@ -211,6 +235,90 @@ bit 0 (V4L2_DV_VSYNC_POS_POL) is for vertical sync polarity and bit 1 (V4L2_DV_H
         </tbody>
       </tgroup>
     </table>
+    <table pgwide="1" frame="none" id="dv-bt-standards">
+      <title>DV BT Timing standards</title>
+      <tgroup cols="2">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>Timing standard</entry>
+            <entry>Description</entry>
+          </row>
+          <row>
+            <entry></entry>
+            <entry></entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_BT_STD_CEA861</entry>
+            <entry>The timings follow the CEA-861 Digital TV Profile standard</entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_BT_STD_DMT</entry>
+            <entry>The timings follow the VESA Discrete Monitor Timings standard</entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_BT_STD_CVT</entry>
+            <entry>The timings follow the VESA Coordinated Video Timings standard</entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_BT_STD_GTF</entry>
+            <entry>The timings follow the VESA Generalized Timings Formula standard</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+    <table pgwide="1" frame="none" id="dv-bt-flags">
+      <title>DV BT Timing flags</title>
+      <tgroup cols="2">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>Flag</entry>
+            <entry>Description</entry>
+          </row>
+          <row>
+            <entry></entry>
+            <entry></entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_FL_REDUCED_BLANKING</entry>
+            <entry>CVT/GTF specific: the timings use reduced blanking (CVT) or the 'Secondary
+GTF' curve (GTF). In both cases the horizontal and/or vertical blanking
+intervals are reduced, allowing a higher resolution over the same
+bandwidth. This is a read-only flag, applications must not set this.
+            </entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_FL_CAN_REDUCE_FPS</entry>
+            <entry>CEA-861 specific: set for CEA-861 formats with a framerate that is a multiple
+of six. These formats can be optionally played at 1 / 1.001 speed to
+be compatible with 60 Hz based standards such as NTSC and PAL-M that use a framerate of
+29.97 frames per second. If the transmitter can't generate such frequencies, then the
+flag will also be cleared. This is a read-only flag, applications must not set this.
+            </entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_FL_REDUCED_FPS</entry>
+            <entry>CEA-861 specific: only valid for video transmitters, the flag is cleared
+by receivers. It is also only valid for formats with the V4L2_DV_FL_CAN_REDUCE_FPS flag
+set, for other formats the flag will be cleared by the driver.
+
+If the application sets this flag, then the pixelclock used to set up the transmitter is
+divided by 1.001 to make it compatible with NTSC framerates. If the transmitter
+can't generate such frequencies, then the flag will also be cleared.
+            </entry>
+          </row>
+          <row>
+            <entry>V4L2_DV_FL_HALF_LINE</entry>
+            <entry>Specific to interlaced formats: if set, then field 1 (aka the odd field)
+is really one half-line longer and field 2 (aka the even field) is really one half-line
+shorter, so each field has exactly the same number of half-lines. Whether half-lines can be
+detected or used depends on the hardware.
+            </entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
   </refsect1>
   <refsect1>
     &return-value;
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
index b17a7aac6997..0a4b90fcf2da 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
@@ -265,6 +265,25 @@ These controls are described in <xref
 These controls are described in <xref
                 linkend="flash-controls" />.</entry>
           </row>
+          <row>
+            <entry><constant>V4L2_CTRL_CLASS_JPEG</constant></entry>
+            <entry>0x9d0000</entry>
+            <entry>The class containing JPEG compression controls.
+These controls are described in <xref
+                linkend="jpeg-controls" />.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_CTRL_CLASS_IMAGE_SOURCE</constant></entry>
+            <entry>0x9e0000</entry> <entry>The class containing image
+            source controls. These controls are described in <xref
+            linkend="image-source-controls" />.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_CTRL_CLASS_IMAGE_PROC</constant></entry>
+            <entry>0x9f0000</entry> <entry>The class containing image
+            processing controls. These controls are described in <xref
+            linkend="image-process-controls" />.</entry>
+          </row>
         </tbody>
       </tgroup>
     </table>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml
index 17fbda15137b..52acff193a6f 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml
@@ -116,7 +116,7 @@ this ioctl.</para>
         <colspec colname="c4" />
         <tbody valign="top">
           <row>
-            <entry>&v4l2-buf-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry></entry>
             <entry>Type of the data stream, see <xref
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
index 66e9a5257861..69c178a4d205 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
@@ -95,14 +95,14 @@ the &v4l2-output; <structfield>modulator</structfield> field and the
 &v4l2-modulator; <structfield>index</structfield> field.</entry>
           </row>
           <row>
-            <entry>&v4l2-tuner-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry>The tuner type. This is the same value as in the
-&v4l2-tuner; <structfield>type</structfield> field. The type must be set
+&v4l2-tuner; <structfield>type</structfield> field. See The type must be set
 to <constant>V4L2_TUNER_RADIO</constant> for <filename>/dev/radioX</filename>
 device nodes, and to <constant>V4L2_TUNER_ANALOG_TV</constant>
 for all others. The field is not applicable to modulators, &ie; ignored
-by drivers.</entry>
+by drivers. See <xref linkend="v4l2-tuner-type" /></entry>
           </row>
           <row>
             <entry>__u32</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-parm.xml b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml
index 19b1d85dd668..f83d2cdd1185 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-parm.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml
@@ -75,11 +75,12 @@ devices.</para>
         &cs-ustr;
         <tbody valign="top">
           <row>
-            <entry>&v4l2-buf-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry></entry>
             <entry>The buffer (stream) type, same as &v4l2-format;
-<structfield>type</structfield>, set by the application.</entry>
+<structfield>type</structfield>, set by the application. See <xref
+            linkend="v4l2-buf-type" /></entry>
           </row>
           <row>
             <entry>union</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml b/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml
index 71741daaf725..bd015d1563ff 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml
@@ -148,7 +148,7 @@ using the &VIDIOC-S-FMT; ioctl as described in <xref
 <structfield>service_lines</structfield>[1][0] to zero.</entry>
           </row>
           <row>
-            <entry>&v4l2-buf-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry>Type of the data stream, see <xref
                   linkend="v4l2-buf-type" />. Should be
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
index 91ec2fb658f8..62a1aa200a36 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
@@ -107,7 +107,7 @@ user.<!-- FIXME Video inputs already have a name, the purpose of this
 field is not quite clear.--></para></entry>
           </row>
           <row>
-            <entry>&v4l2-tuner-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry spanname="hspan">Type of the tuner, see <xref
                 linkend="v4l2-tuner-type" />.</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml b/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
index 7bde698760e4..fa7ad7e33228 100644
--- a/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
@@ -48,6 +48,12 @@
   <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>Applications can optionally call the
 <constant>VIDIOC_PREPARE_BUF</constant> ioctl to pass ownership of the buffer
 to the driver before actually enqueuing it, using the
diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml
index 23b17f604211..1bc8aeb3ff1f 100644
--- a/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml
@@ -49,6 +49,10 @@ input</refpurpose>
   <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
diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml
new file mode 100644
index 000000000000..44935a0ffcf0
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml
@@ -0,0 +1,104 @@
+<refentry id="vidioc-query-dv-timings">
+  <refmeta>
+    <refentrytitle>ioctl VIDIOC_QUERY_DV_TIMINGS</refentrytitle>
+    &manvol;
+  </refmeta>
+
+  <refnamediv>
+    <refname>VIDIOC_QUERY_DV_TIMINGS</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_timings *<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_TIMINGS</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>The hardware may be able to detect the current DV timings
+automatically, similar to sensing the video standard. To do so, applications
+call <constant>VIDIOC_QUERY_DV_TIMINGS</constant> with a pointer to a
+&v4l2-dv-timings;. Once the hardware detects the timings, it will fill in the
+timings structure.
+
+If the timings could not be detected because there was no signal, then
+<errorcode>ENOLINK</errorcode> is returned. If a signal was detected, but
+it was unstable and the receiver could not lock to the signal, then
+<errorcode>ENOLCK</errorcode> is returned. If the receiver could lock to the signal,
+but the format is unsupported (e.g. because the pixelclock is out of range
+of the hardware capabilities), then the driver fills in whatever timings it
+could find and returns <errorcode>ERANGE</errorcode>. In that case the application
+can call &VIDIOC-DV-TIMINGS-CAP; to compare the found timings with the hardware's
+capabilities in order to give more precise feedback to the user.
+</para>
+  </refsect1>
+
+  <refsect1>
+    &return-value;
+
+    <variablelist>
+      <varlistentry>
+        <term><errorcode>ENOLINK</errorcode></term>
+        <listitem>
+          <para>No timings could be detected because no signal was found.
+</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><errorcode>ENOLCK</errorcode></term>
+        <listitem>
+          <para>The signal was unstable and the hardware could not lock on to it.
+</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><errorcode>ERANGE</errorcode></term>
+        <listitem>
+          <para>Timings were found, but they are out of range of the hardware
+capabilities.
+</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
index 36660d311b51..e6645b996558 100644
--- a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
@@ -127,7 +127,7 @@ the first control with a higher ID. Drivers which do not support this
 flag yet always return an &EINVAL;.</entry>
           </row>
           <row>
-            <entry>&v4l2-ctrl-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry>Type of control, see <xref
                 linkend="v4l2-ctrl-type" />.</entry>
@@ -215,11 +215,12 @@ the array to zero.</entry>
 
     <table pgwide="1" frame="none" id="v4l2-querymenu">
       <title>struct <structname>v4l2_querymenu</structname></title>
-      <tgroup cols="3">
+      <tgroup cols="4">
         &cs-str;
         <tbody valign="top">
           <row>
             <entry>__u32</entry>
+            <entry></entry>
             <entry><structfield>id</structfield></entry>
             <entry>Identifies the control, set by the application
 from the respective &v4l2-queryctrl;
@@ -227,18 +228,38 @@ from the respective &v4l2-queryctrl;
           </row>
           <row>
             <entry>__u32</entry>
+            <entry></entry>
             <entry><structfield>index</structfield></entry>
             <entry>Index of the menu item, starting at zero, set by
             the application.</entry>
           </row>
           <row>
+            <entry>union</entry>
+            <entry></entry>
+            <entry></entry>
+            <entry></entry>
+          </row>
+          <row>
+            <entry></entry>
             <entry>__u8</entry>
             <entry><structfield>name</structfield>[32]</entry>
             <entry>Name of the menu item, a NUL-terminated ASCII
-string. This information is intended for the user.</entry>
+string. This information is intended for the user. This field is valid
+for <constant>V4L2_CTRL_FLAG_MENU</constant> type controls.</entry>
+          </row>
+          <row>
+            <entry></entry>
+            <entry>__s64</entry>
+            <entry><structfield>value</structfield></entry>
+            <entry>
+              Value of the integer menu item. This field is valid for
+              <constant>V4L2_CTRL_FLAG_INTEGER_MENU</constant> type
+              controls.
+            </entry>
           </row>
           <row>
             <entry>__u32</entry>
+            <entry></entry>
             <entry><structfield>reserved</structfield></entry>
             <entry>Reserved for future extensions. Drivers must set
 the array to zero.</entry>
@@ -292,6 +313,20 @@ the menu items can be enumerated with the
 <constant>VIDIOC_QUERYMENU</constant> ioctl.</entry>
           </row>
           <row>
+            <entry><constant>V4L2_CTRL_TYPE_INTEGER_MENU</constant></entry>
+            <entry>&ge; 0</entry>
+            <entry>1</entry>
+            <entry>N-1</entry>
+            <entry>
+              The control has a menu of N choices. The values of the
+              menu items can be enumerated with the
+              <constant>VIDIOC_QUERYMENU</constant> ioctl. This is
+              similar to <constant>V4L2_CTRL_TYPE_MENU</constant>
+              except that instead of strings, the menu items are
+              signed 64-bit integers.
+            </entry>
+          </row>
+          <row>
             <entry><constant>V4L2_CTRL_TYPE_BITMASK</constant></entry>
             <entry>0</entry>
             <entry>n/a</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml
index 7be4b1d29b90..d7c95057bc51 100644
--- a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml
@@ -92,18 +92,19 @@ streamoff.--></para>
             <entry>The number of buffers requested or granted.</entry>
           </row>
           <row>
-            <entry>&v4l2-buf-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry>Type of the stream or buffers, this is the same
 as the &v4l2-format; <structfield>type</structfield> field. See <xref
                 linkend="v4l2-buf-type" /> for valid values.</entry>
           </row>
           <row>
-            <entry>&v4l2-memory;</entry>
+            <entry>__u32</entry>
             <entry><structfield>memory</structfield></entry>
             <entry>Applications set this field to
 <constant>V4L2_MEMORY_MMAP</constant> or
-<constant>V4L2_MEMORY_USERPTR</constant>.</entry>
+<constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory"
+/>.</entry>
           </row>
           <row>
             <entry>__u32</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
index 18b1a8266f7c..407dfceb71f0 100644
--- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
@@ -73,10 +73,11 @@ same value as in the &v4l2-input; <structfield>tuner</structfield>
 field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
           </row>
           <row>
-            <entry>&v4l2-tuner-type;</entry>
+            <entry>__u32</entry>
             <entry><structfield>type</structfield></entry>
             <entry>The tuner type. This is the same value as in the
-&v4l2-tuner; <structfield>type</structfield> field.</entry>
+&v4l2-tuner; <structfield>type</structfield> field. See <xref
+            linkend="v4l2-tuner-type" /></entry>
           </row>
           <row>
             <entry>__u32</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-crop.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-crop.xml
index 06197323a8cc..4cddd788c589 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-crop.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-crop.xml
@@ -58,9 +58,12 @@
     <title>Description</title>
 
     <note>
-      <title>Experimental</title>
-      <para>This is an <link linkend="experimental">experimental</link>
-      interface and may change in the future.</para>
+      <title>Obsolete</title>
+
+      <para>This is an <link linkend="obsolete">obsolete</link>
+      interface and may be removed in the future. It is superseded by
+      <link linkend="vidioc-subdev-g-selection">the selection
+      API</link>.</para>
     </note>
 
     <para>To retrieve the current crop rectangle applications set the
diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
new file mode 100644
index 000000000000..208e9f0da3f3
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
@@ -0,0 +1,228 @@
+<refentry id="vidioc-subdev-g-selection">
+  <refmeta>
+    <refentrytitle>ioctl VIDIOC_SUBDEV_G_SELECTION, VIDIOC_SUBDEV_S_SELECTION</refentrytitle>
+    &manvol;
+  </refmeta>
+
+  <refnamediv>
+    <refname>VIDIOC_SUBDEV_G_SELECTION</refname>
+    <refname>VIDIOC_SUBDEV_S_SELECTION</refname>
+    <refpurpose>Get or set selection rectangles on a subdev pad</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_subdev_selection *<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_SUBDEV_G_SELECTION, VIDIOC_SUBDEV_S_SELECTION</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>The selections are used to configure various image
+    processing functionality performed by the subdevs which affect the
+    image size. This currently includes cropping, scaling and
+    composition.</para>
+
+    <para>The selection API replaces <link
+    linkend="vidioc-subdev-g-crop">the old subdev crop API</link>. All
+    the function of the crop API, and more, are supported by the
+    selections API.</para>
+
+    <para>See <xref linkend="subdev"></xref> for
+    more information on how each selection target affects the image
+    processing pipeline inside the subdevice.</para>
+
+    <section>
+      <title>Types of selection targets</title>
+
+      <para>There are two types of selection targets: actual and bounds.
+      The ACTUAL targets are the targets which configure the hardware.
+      The BOUNDS target will return a rectangle that contain all
+      possible ACTUAL rectangles.</para>
+    </section>
+
+    <section>
+      <title>Discovering supported features</title>
+
+      <para>To discover which targets are supported, the user can
+      perform <constant>VIDIOC_SUBDEV_G_SELECTION</constant> on them.
+      Any unsupported target will return
+      <constant>EINVAL</constant>.</para>
+    </section>
+
+    <table pgwide="1" frame="none" id="v4l2-subdev-selection-targets">
+      <title>V4L2 subdev selection targets</title>
+      <tgroup cols="3">
+        &cs-def;
+        <tbody valign="top">
+          <row>
+            <entry><constant>V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL</constant></entry>
+            <entry>0x0000</entry>
+            <entry>Actual crop. Defines the cropping
+            performed by the processing step.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS</constant></entry>
+            <entry>0x0002</entry>
+            <entry>Bounds of the crop rectangle.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL</constant></entry>
+            <entry>0x0100</entry>
+            <entry>Actual compose rectangle. Used to configure scaling
+            on sink pads and composition on source pads.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
+            <entry>0x0102</entry>
+            <entry>Bounds of the compose rectangle.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <table pgwide="1" frame="none" id="v4l2-subdev-selection-flags">
+      <title>V4L2 subdev selection flags</title>
+      <tgroup cols="3">
+        &cs-def;
+        <tbody valign="top">
+          <row>
+            <entry><constant>V4L2_SUBDEV_SEL_FLAG_SIZE_GE</constant></entry>
+            <entry>(1 &lt;&lt; 0)</entry> <entry>Suggest the driver it
+            should choose greater or equal rectangle (in size) than
+            was requested. Albeit the driver may choose a lesser size,
+            it will only do so due to hardware limitations. Without
+            this flag (and
+            <constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant>) the
+            behaviour is to choose the closest possible
+            rectangle.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant></entry>
+            <entry>(1 &lt;&lt; 1)</entry> <entry>Suggest the driver it
+            should choose lesser or equal rectangle (in size) than was
+            requested. Albeit the driver may choose a greater size, it
+            will only do so due to hardware limitations.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG</constant></entry>
+            <entry>(1 &lt;&lt; 2)</entry>
+            <entry>The configuration should not be propagated to any
+            further processing steps. If this flag is not given, the
+            configuration is propagated inside the subdevice to all
+            further processing steps.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <table pgwide="1" frame="none" id="v4l2-subdev-selection">
+      <title>struct <structname>v4l2_subdev_selection</structname></title>
+      <tgroup cols="3">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>which</structfield></entry>
+            <entry>Active or try selection, from
+            &v4l2-subdev-format-whence;.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>pad</structfield></entry>
+            <entry>Pad number as reported by the media framework.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>target</structfield></entry>
+            <entry>Target selection rectangle. See
+            <xref linkend="v4l2-subdev-selection-targets">.</xref>.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>flags</structfield></entry>
+            <entry>Flags. See
+            <xref linkend="v4l2-subdev-selection-flags">.</xref></entry>
+          </row>
+          <row>
+            <entry>&v4l2-rect;</entry>
+            <entry><structfield>rect</structfield></entry>
+            <entry>Selection rectangle, in pixels.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>reserved</structfield>[8]</entry>
+            <entry>Reserved for future extensions. Applications and drivers must
+            set the array to zero.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+  </refsect1>
+
+  <refsect1>
+    &return-value;
+
+    <variablelist>
+      <varlistentry>
+        <term><errorcode>EBUSY</errorcode></term>
+        <listitem>
+          <para>The selection rectangle can't be changed because the
+          pad is currently busy. This can be caused, for instance, by
+          an active video stream on the pad. The ioctl must not be
+          retried without performing another action to fix the problem
+          first. Only returned by
+          <constant>VIDIOC_SUBDEV_S_SELECTION</constant></para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><errorcode>EINVAL</errorcode></term>
+        <listitem>
+          <para>The &v4l2-subdev-selection;
+          <structfield>pad</structfield> references a non-existing
+          pad, the <structfield>which</structfield> field references a
+          non-existing format, or the selection target is not
+          supported on the given subdev pad.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl
index 0c674be0d3c6..e0aedb7a7827 100644
--- a/Documentation/DocBook/mtdnand.tmpl
+++ b/Documentation/DocBook/mtdnand.tmpl
@@ -1119,8 +1119,6 @@ in this page</entry>
                 These constants are defined in nand.h. They are ored together to describe
                 the chip functionality.
                 <programlisting>
-/* Chip can not auto increment pages */
-#define NAND_NO_AUTOINCR        0x00000001
 /* Buswitdh is 16 bit */
 #define NAND_BUSWIDTH_16        0x00000002
 /* Device supports partial programming without padding */
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index f7ade3b3b40d..59c080f084ef 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -218,16 +218,16 @@ The development process
 Linux kernel development process currently consists of a few different
 main kernel "branches" and lots of different subsystem-specific kernel
 branches.  These different branches are:
-  - main 2.6.x kernel tree
-  - 2.6.x.y -stable kernel tree
-  - 2.6.x -git kernel patches
+  - main 3.x kernel tree
+  - 3.x.y -stable kernel tree
+  - 3.x -git kernel patches
   - subsystem specific kernel trees and patches
-  - the 2.6.x -next kernel tree for integration tests
+  - the 3.x -next kernel tree for integration tests
 
-2.6.x kernel tree
+3.x kernel tree
 -----------------
-2.6.x kernels are maintained by Linus Torvalds, and can be found on
-kernel.org in the pub/linux/kernel/v2.6/ directory.  Its development
+3.x kernels are maintained by Linus Torvalds, and can be found on
+kernel.org in the pub/linux/kernel/v3.x/ directory.  Its development
 process is as follows:
   - As soon as a new kernel is released a two weeks window is open,
     during this period of time maintainers can submit big diffs to
@@ -262,20 +262,20 @@ mailing list about kernel releases:
         released according to perceived bug status, not according to a
         preconceived timeline."
 
-2.6.x.y -stable kernel tree
+3.x.y -stable kernel tree
 ---------------------------
-Kernels with 4-part versions are -stable kernels. They contain
+Kernels with 3-part versions are -stable kernels. They contain
 relatively small and critical fixes for security problems or significant
-regressions discovered in a given 2.6.x kernel.
+regressions discovered in a given 3.x kernel.
 
 This is the recommended branch for users who want the most recent stable
 kernel and are not interested in helping test development/experimental
 versions.
 
-If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
+If no 3.x.y kernel is available, then the highest numbered 3.x
 kernel is the current stable kernel.
 
-2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
+3.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
 are released as needs dictate.  The normal release period is approximately
 two weeks, but it can be longer if there are no pressing problems.  A
 security-related problem, instead, can cause a release to happen almost
@@ -285,7 +285,7 @@ The file Documentation/stable_kernel_rules.txt in the kernel tree
 documents what kinds of changes are acceptable for the -stable tree, and
 how the release process works.
 
-2.6.x -git patches
+3.x -git patches
 ------------------
 These are daily snapshots of Linus' kernel tree which are managed in a
 git repository (hence the name.) These patches are usually released
@@ -317,13 +317,13 @@ revisions to it, and maintainers can mark patches as under review,
 accepted, or rejected.  Most of these patchwork sites are listed at
 http://patchwork.kernel.org/.
 
-2.6.x -next kernel tree for integration tests
+3.x -next kernel tree for integration tests
 ---------------------------------------------
-Before updates from subsystem trees are merged into the mainline 2.6.x
+Before updates from subsystem trees are merged into the mainline 3.x
 tree, they need to be integration-tested.  For this purpose, a special
 testing repository exists into which virtually all subsystem trees are
 pulled on an almost daily basis:
-        http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
+        http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
         http://linux.f-seidel.de/linux-next/pmwiki/
 
 This way, the -next kernel gives a summary outlook onto what will be
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 30b656ece7aa..31d302bc5863 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,3 +1,3 @@
 obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
         filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \
-        pcmcia/ spi/ timers/ watchdog/src/
+        pcmcia/ spi/ timers/ watchdog/src/ misc-devices/mei/
diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt
index 375d3fb71437..4ddf3913fd8c 100644
--- a/Documentation/RCU/torture.txt
+++ b/Documentation/RCU/torture.txt
@@ -47,6 +47,16 @@ irqreader	Says to invoke RCU readers from irq level.  This is currently
                 permit this.  (Or, more accurately, variants of RCU that do
                 -not- permit this know to ignore this variable.)
 
+n_barrier_cbs   If this is nonzero, RCU barrier testing will be conducted,
+                in which case n_barrier_cbs specifies the number of
+                RCU callbacks (and corresponding kthreads) to use for
+                this testing.  The value cannot be negative.  If you
+                specify this to be non-zero when torture_type indicates a
+                synchronous RCU implementation (one for which a member of
+                the synchronize_rcu() rather than the call_rcu() family is
+                used -- see the documentation for torture_type below), an
+                error will be reported and no testing will be carried out.
+
 nfakewriters    This is the number of RCU fake writer threads to run.  Fake
                 writer threads repeatedly use the synchronous "wait for
                 current readers" function of the interface selected by
@@ -188,7 +198,7 @@ OUTPUT
 The statistics output is as follows:
 
         rcu-torture:--- Start of test: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4
-        rcu-torture: rtc:           (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767
+        rcu-torture: rtc:           (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767
         rcu-torture: Reader Pipe:  727860534 34213 0 0 0 0 0 0 0 0 0
         rcu-torture: Reader Batch:  727877838 17003 0 0 0 0 0 0 0 0 0
         rcu-torture: Free-Block Circulation:  155440 155440 155440 155440 155440 155440 155440 155440 155440 155440 0
@@ -230,6 +240,9 @@ o	"rtmbe": A non-zero value indicates that rcutorture believes that
         rcu_assign_pointer() and rcu_dereference() are not working
         correctly.  This value should be zero.
 
+o       "rtbe": A non-zero value indicates that one of the rcu_barrier()
+        family of functions is not working correctly.
+
 o       "rtbke": rcutorture was unable to create the real-time kthreads
         used to force RCU priority inversion.  This value should be zero.
 
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 4468ce24427c..c379a2a6949f 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -150,7 +150,8 @@ be able to justify all violations that remain in your patch.
 
 Look through the MAINTAINERS file and the source code, and determine
 if your change applies to a specific subsystem of the kernel, with
-an assigned maintainer.  If so, e-mail that person.
+an assigned maintainer.  If so, e-mail that person.  The script
+scripts/get_maintainer.pl can be very useful at this step.
 
 If no maintainer is listed, or the maintainer does not respond, send
 your patch to the primary Linux kernel developer's mailing list,
diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX
index 91c24a1e8a9e..36420e116c90 100644
--- a/Documentation/arm/00-INDEX
+++ b/Documentation/arm/00-INDEX
@@ -4,8 +4,6 @@ Booting
         - requirements for booting
 Interrupts
         - ARM Interrupt subsystem documentation
-IXP2000
-        - Release Notes for Linux on Intel's IXP2000 Network Processor
 msm
         - MSM specific documentation
 Netwinder
diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000
deleted file mode 100644
index 68d21d92a30b..000000000000
--- a/Documentation/arm/IXP2000
+++ /dev/null
@@ -1,69 +0,0 @@
-
--------------------------------------------------------------------------
-Release Notes for Linux on Intel's IXP2000 Network Processor
-
-Maintained by Deepak Saxena <dsaxena@plexity.net>
--------------------------------------------------------------------------
-
-1. Overview
-
-Intel's IXP2000 family of NPUs (IXP2400, IXP2800, IXP2850) is designed
-for high-performance network applications such high-availability
-telecom systems. In addition to an XScale core, it contains up to 8
-"MicroEngines" that run special code, several high-end networking 
-interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port,
-flash interface, and some other odds and ends. For more information, see:
-
-http://developer.intel.com
-
-2. Linux Support
-
-Linux currently supports the following features on the IXP2000 NPUs:
-
-- On-chip serial
-- PCI
-- Flash (MTD/JFFS2)
-- I2C through GPIO
-- Timers (watchdog, OS)
-
-That is about all we can support under Linux ATM b/c the core networking
-components of the chip are accessed via Intel's closed source SDK. 
-Please contact Intel directly on issues with using those. There is
-also a mailing list run by some folks at Princeton University that might
-be of help:  https://lists.cs.princeton.edu/mailman/listinfo/ixp2xxx
-
-WHATEVER YOU DO, DO NOT POST EMAIL TO THE LINUX-ARM OR LINUX-ARM-KERNEL
-MAILING LISTS REGARDING THE INTEL SDK.
-
-3. Supported Platforms
-
-- Intel IXDP2400 Reference Platform
-- Intel IXDP2800 Reference Platform
-- Intel IXDP2401 Reference Platform
-- Intel IXDP2801 Reference Platform
-- RadiSys ENP-2611
-
-4. Usage Notes
-
-- The IXP2000 platforms usually have rather complex PCI bus topologies
-  with large memory space requirements. In addition, b/c of the way the
-  Intel SDK is designed, devices are enumerated in a very specific
-  way. B/c of this this, we use "pci=firmware" option in the kernel
-  command line so that we do not re-enumerate the bus.
-
-- IXDP2x01 systems have variable clock tick rates that we cannot determine 
-  via HW registers. The "ixdp2x01_clk=XXX" cmd line options allow you
-  to pass the clock rate to the board port.
-
-5. Thanks
-
-The IXP2000 work has been funded by Intel Corp. and MontaVista Software, Inc.
-
-The following people have contributed patches/comments/etc:
-
-Naeem F. Afzal
-Lennert Buytenhek
-Jeffrey Daly
-
--------------------------------------------------------------------------
-Last Update: 8/09/2004
diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index 888ae7b83ae4..a564ceea9e98 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -47,6 +47,51 @@ flexible way to enable non-common multi-display configuration. In addition to
 modelling the hardware overlays, omapdss supports virtual overlays and overlay
 managers. These can be used when updating a display with CPU or system DMA.
 
+omapdss driver support for audio
+--------------------------------
+There exist several display technologies and standards that support audio as
+well. Hence, it is relevant to update the DSS device driver to provide an audio
+interface that may be used by an audio driver or any other driver interested in
+the functionality.
+
+The audio_enable function is intended to prepare the relevant
+IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
+some IP, enabling companion chips, etc). It is intended to be called before
+audio_start. The audio_disable function performs the reverse operation and is
+intended to be called after audio_stop.
+
+While a given DSS device driver may support audio, it is possible that for
+certain configurations audio is not supported (e.g., an HDMI display using a
+VESA video timing). The audio_supported function is intended to query whether
+the current configuration of the display supports audio.
+
+The audio_config function is intended to configure all the relevant audio
+parameters of the display. In order to make the function independent of any
+specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
+is to contain all the required parameters for audio configuration. At the
+moment, such structure contains pointers to IEC-60958 channel status word
+and CEA-861 audio infoframe structures. This should be enough to support
+HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.
+
+The audio_enable/disable, audio_config and audio_supported functions could be
+implemented as functions that may sleep. Hence, they should not be called
+while holding a spinlock or a readlock.
+
+The audio_start/audio_stop function is intended to effectively start/stop audio
+playback after the configuration has taken place. These functions are designed
+to be used in an atomic context. Hence, audio_start should return quickly and be
+called only after all the needed resources for audio playback (audio FIFOs,
+DMA channels, companion chips, etc) have been enabled to begin data transfers.
+audio_stop is designed to only stop the audio transfers. The resources used
+for playback are released using audio_disable.
+
+The enum omap_dss_audio_state may be used to help the implementations of
+the interface to keep track of the audio state. The initial state is _DISABLED;
+then, the state transitions to _CONFIGURED, and then, when it is ready to
+play audio, to _ENABLED. The state _PLAYING is used when the audio is being
+rendered.
+
+
 Panel and controller drivers
 ----------------------------
 
@@ -156,6 +201,7 @@ timings		Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)
                 "pal" and "ntsc"
 panel_name
 tear_elim       Tearing elimination 0=off, 1=on
+output_type     Output type (video encoder only): "composite" or "svideo"
 
 There are also some debugfs files at <debugfs>/omapdss/ which show information
 about clocks and registers.
diff --git a/Documentation/arm/SPEAr/overview.txt b/Documentation/arm/SPEAr/overview.txt
index 253a35c6f782..65610bf52ebf 100644
--- a/Documentation/arm/SPEAr/overview.txt
+++ b/Documentation/arm/SPEAr/overview.txt
@@ -8,53 +8,56 @@ Introduction
   weblink : http://www.st.com/spear
 
   The ST Microelectronics SPEAr range of ARM9/CortexA9 System-on-Chip CPUs are
-  supported by the 'spear' platform of ARM Linux. Currently SPEAr300,
-  SPEAr310, SPEAr320 and SPEAr600 SOCs are supported. Support for the SPEAr13XX
-  series is in progress.
+  supported by the 'spear' platform of ARM Linux. Currently SPEAr1310,
+  SPEAr1340, SPEAr300, SPEAr310, SPEAr320 and SPEAr600 SOCs are supported.
 
   Hierarchy in SPEAr is as follows:
 
   SPEAr (Platform)
         - SPEAr3XX (3XX SOC series, based on ARM9)
                 - SPEAr300 (SOC)
-                        - SPEAr300_EVB (Evaluation Board)
+                        - SPEAr300 Evaluation Board
                 - SPEAr310 (SOC)
-                        - SPEAr310_EVB (Evaluation Board)
+                        - SPEAr310 Evaluation Board
                 - SPEAr320 (SOC)
-                        - SPEAr320_EVB (Evaluation Board)
+                        - SPEAr320 Evaluation Board
         - SPEAr6XX (6XX SOC series, based on ARM9)
                 - SPEAr600 (SOC)
-                        - SPEAr600_EVB (Evaluation Board)
+                        - SPEAr600 Evaluation Board
         - SPEAr13XX (13XX SOC series, based on ARM CORTEXA9)
-                - SPEAr1300 (SOC)
+                - SPEAr1310 (SOC)
+                        - SPEAr1310 Evaluation Board
+                - SPEAr1340 (SOC)
+                        - SPEAr1340 Evaluation Board
 
   Configuration
   -------------
 
   A generic configuration is provided for each machine, and can be used as the
   default by
-        make spear600_defconfig
-        make spear300_defconfig
-        make spear310_defconfig
-        make spear320_defconfig
+        make spear13xx_defconfig
+        make spear3xx_defconfig
+        make spear6xx_defconfig
 
   Layout
   ------
 
-  The common files for multiple machine families (SPEAr3XX, SPEAr6XX and
-  SPEAr13XX) are located in the platform code contained in arch/arm/plat-spear
+  The common files for multiple machine families (SPEAr3xx, SPEAr6xx and
+  SPEAr13xx) are located in the platform code contained in arch/arm/plat-spear
   with headers in plat/.
 
   Each machine series have a directory with name arch/arm/mach-spear followed by
   series name. Like mach-spear3xx, mach-spear6xx and mach-spear13xx.
 
-  Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c and for
-  spear6xx is mach-spear6xx/spear6xx.c. mach-spear* also contain soc/machine
-  specific files, like spear300.c, spear310.c, spear320.c and spear600.c.
-  mach-spear* also contains board specific files for each machine type.
+  Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c, for
+  spear6xx is mach-spear6xx/spear6xx.c and for spear13xx family is
+  mach-spear13xx/spear13xx.c. mach-spear* also contain soc/machine specific
+  files, like spear1310.c, spear1340.c spear300.c, spear310.c, spear320.c and
+  spear600.c.  mach-spear* doesn't contains board specific files as they fully
+  support Flattened Device Tree.
 
 
   Document Author
   ---------------
 
-  Viresh Kumar, (c) 2010 ST Microelectronics
+  Viresh Kumar <viresh.linux@gmail.com>, (c) 2010-2012 ST Microelectronics
diff --git a/Documentation/blackfin/bfin-gpio-notes.txt b/Documentation/blackfin/bfin-gpio-notes.txt
index d36b01f778b9..d245f39c3d01 100644
--- a/Documentation/blackfin/bfin-gpio-notes.txt
+++ b/Documentation/blackfin/bfin-gpio-notes.txt
@@ -53,7 +53,7 @@
 
 3. But there are some exceptions
     - Kernel permit the identical GPIO be requested both as GPIO and GPIO
-    interrut.
+    interrupt.
     Some drivers, like gpio-keys, need this behavior. Kernel only print out
     warning messages like,
         bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index 9b1067afb224..dd88540bb995 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -184,12 +184,14 @@ behind this approach is that a cgroup that aggressively uses a shared
 page will eventually get charged for it (once it is uncharged from
 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_MEM_RES_CTLR_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.
 
-
 2.4 Swap Extension (CONFIG_CGROUP_MEM_RES_CTLR_SWAP)
 
 Swap Extension allows you to record charge for swap. A swapped-in page is
@@ -374,14 +376,15 @@ cgroup might have some charge associated with it, even though all
 tasks have migrated away from it. (because we charge against pages, not
 against tasks.)
 
-Such charges are freed or moved to their parent. At moving, both of RSS
-and CACHES are moved to parent.
-rmdir() may return -EBUSY if freeing/moving fails. See 5.1 also.
+We move the stats to root (if use_hierarchy==0) or parent (if
+use_hierarchy==1), and no change on the charge except uncharging
+from the child.
 
 Charges recorded in swap information is not updated at removal of cgroup.
 Recorded information is discarded and a cgroup which uses swap (swapcache)
 will be charged as a new owner of it.
 
+About use_hierarchy, see Section 6.
 
 5. Misc. interfaces.
 
@@ -394,13 +397,15 @@ will be charged as a new owner of it.
 
   Almost all pages tracked by this memory cgroup will be unmapped and freed.
   Some pages cannot be freed because they are locked or in-use. Such pages are
-  moved to parent and this cgroup will be empty. This may return -EBUSY if
-  VM is too busy to free/move all pages immediately.
+  moved to parent(if use_hierarchy==1) or root (if use_hierarchy==0) and this
+  cgroup will be empty.
 
   Typical use case of this interface is that calling this before rmdir().
   Because rmdir() moves all pages to parent, some out-of-use page caches can be
   moved to the parent. If you want to avoid that, force_empty will be useful.
 
+  About use_hierarchy, see Section 6.
+
 5.2 stat file
 
 memory.stat file includes following statistics
@@ -430,17 +435,10 @@ hierarchical_memory_limit - # of bytes of memory limit with regard to hierarchy
 hierarchical_memsw_limit - # of bytes of memory+swap limit with regard to
                         hierarchy under which memory cgroup is.
 
-total_cache             - sum of all children's "cache"
-total_rss               - sum of all children's "rss"
-total_mapped_file       - sum of all children's "cache"
-total_pgpgin            - sum of all children's "pgpgin"
-total_pgpgout           - sum of all children's "pgpgout"
-total_swap              - sum of all children's "swap"
-total_inactive_anon     - sum of all children's "inactive_anon"
-total_active_anon       - sum of all children's "active_anon"
-total_inactive_file     - sum of all children's "inactive_file"
-total_active_file       - sum of all children's "active_file"
-total_unevictable       - sum of all children's "unevictable"
+total_<counter>         - # hierarchical version of <counter>, which in
+                        addition to the cgroup's own value includes the
+                        sum of all hierarchical children's values of
+                        <counter>, i.e. total_cache
 
 # The following additional stats are dependent on CONFIG_DEBUG_VM.
 
@@ -622,8 +620,7 @@ memory cgroup.
   bit | what type of charges would be moved ?
  -----+------------------------------------------------------------------------
    0  | A charge of an anonymous page(or swap of it) used by the target task.
-      | Those pages and swaps must be used only by the target task. You must
-      | enable Swap Extension(see 2.4) to enable move of swap charges.
+      | You must enable Swap Extension(see 2.4) to enable move of swap charges.
  -----+------------------------------------------------------------------------
    1  | A charge of file pages(normal file, tmpfs file(e.g. ipc shared memory)
       | and swaps of tmpfs file) mmapped by the target task. Unlike the case of
@@ -636,8 +633,6 @@ memory cgroup.
 
 8.3 TODO
 
-- Implement madvise(2) to let users decide the vma to be moved or not to be
-  moved.
 - All of moving charge operations are done under cgroup_mutex. It's not good
   behavior to hold the mutex too long, so we may need some trick.
 
diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt
index 95b24d766eab..0c4a344e78fa 100644
--- a/Documentation/cgroups/resource_counter.txt
+++ b/Documentation/cgroups/resource_counter.txt
@@ -77,11 +77,11 @@ to work with it.
         where the charging failed.
 
  d. int res_counter_charge_locked
-                        (struct res_counter *rc, unsigned long val)
+                        (struct res_counter *rc, unsigned long val, bool force)
 
         The same as res_counter_charge(), but it must not acquire/release the
         res_counter->lock internally (it must be called with res_counter->lock
-        held).
+        held). The force parameter indicates whether we can bypass the limit.
 
  e. void res_counter_uncharge[_locked]
                         (struct res_counter *rc, unsigned long val)
@@ -92,6 +92,14 @@ to work with it.
 
         The _locked routines imply that the res_counter->lock is taken.
 
+ f. void res_counter_uncharge_until
+                (struct res_counter *rc, struct res_counter *top,
+                 unsinged long val)
+
+        Almost same as res_cunter_uncharge() but propagation of uncharge
+        stops when rc == top. This is useful when kill a res_coutner in
+        child cgroup.
+
  2.1 Other accounting routines
 
     There are more routines that may help you with common needs, like
diff --git a/Documentation/cris/README b/Documentation/cris/README
index d9b086869a60..8dbdb1a44429 100644
--- a/Documentation/cris/README
+++ b/Documentation/cris/README
@@ -1,38 +1,34 @@
-Linux 2.4 on the CRIS architecture
-==================================
-$Id: README,v 1.7 2001/04/19 12:38:32 bjornw Exp $
+Linux on the CRIS architecture
+==============================
 
-This is a port of Linux 2.4 to Axis Communications ETRAX 100LX embedded 
-network CPU. For more information about CRIS and ETRAX please see further
-below.
+This is a port of Linux to Axis Communications ETRAX 100LX,
+ETRAX FS and ARTPEC-3 embedded network CPUs.
+
+For more information about CRIS and ETRAX please see further below.
 
 In order to compile this you need a version of gcc with support for the
-ETRAX chip family. Please see this link for more information on how to 
+ETRAX chip family. Please see this link for more information on how to
 download the compiler and other tools useful when building and booting
 software for the ETRAX platform:
 
-http://developer.axis.com/doc/software/devboard_lx/install-howto.html
-
-<more specific information should come in this document later>
+http://developer.axis.com/wiki/doku.php?id=axis:install-howto-2_20
 
 What is CRIS ?
 --------------
 
 CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU
 architecture in Axis Communication AB's range of embedded network CPU's,
-called ETRAX. The latest CPU is called ETRAX 100LX, where LX stands for
-'Linux' because the chip was designed to be a good host for the Linux
-operating system.
+called ETRAX.
 
 The ETRAX 100LX chip
 --------------------
 
-For reference, please see the press-release:
+For reference, please see the following link:
 
-http://www.axis.com/news/us/001101_etrax.htm
+http://www.axis.com/products/dev_etrax_100lx/index.htm
 
-The ETRAX 100LX is a 100 MIPS processor with 8kB cache, MMU, and a very broad 
-range of  built-in interfaces, all with modern scatter/gather DMA.
+The ETRAX 100LX is a 100 MIPS processor with 8kB cache, MMU, and a very broad
+range of built-in interfaces, all with modern scatter/gather DMA.
 
 Memory interfaces:
 
@@ -51,20 +47,28 @@ I/O interfaces:
         * SCSI
         * two parallel-ports
         * two generic 8-bit ports
-        
-        (not all interfaces are available at the same time due to chip pin 
+
+        (not all interfaces are available at the same time due to chip pin
          multiplexing)
 
-The previous version of the ETRAX, the ETRAX 100, sits in almost all of
-Axis shipping thin-servers like the Axis 2100 web camera or the ETRAX 100
-developer-board. It lacks an MMU so the Linux we run on that is a version
-of uClinux (Linux 2.0 without MM-support) ported to the CRIS architecture.
-The new Linux 2.4 port has full MM and needs a CPU with an MMU, so it will
-not run on the ETRAX 100.
+ETRAX 100LX is CRISv10 architecture.
+
+
+The ETRAX FS and ARTPEC-3 chips
+-------------------------------
 
-A version of the Axis developer-board with ETRAX 100LX (running Linux
-2.4) is now available. For more information please see developer.axis.com.
+The ETRAX FS is a 200MHz 32-bit RISC processor with on-chip 16kB
+I-cache and 16kB D-cache and with a wide range of device interfaces
+including multiple high speed serial ports and an integrated USB 1.1 PHY.
 
+The ARTPEC-3 is a variant of the ETRAX FS with additional IO-units
+used by the Axis Communications network cameras.
+
+See below link for more information:
+
+http://www.axis.com/products/dev_etrax_fs/index.htm
+
+ETRAX FS and ARTPEC-3 are both CRISv32 architectures.
 
 Bootlog
 -------
@@ -182,10 +186,6 @@ SwapFree:            0 kB
 -rwxr-xr-x  1 342      100         16252  Jan 01 00:00 telnetd
 
 
-(All programs are statically linked to the libc at this point - we have not ported the
- shared libraries yet)
-
-
 
 
 
diff --git a/Documentation/device-mapper/thin-provisioning.txt b/Documentation/device-mapper/thin-provisioning.txt
index 3370bc4d7b98..f5cfc62b7ad3 100644
--- a/Documentation/device-mapper/thin-provisioning.txt
+++ b/Documentation/device-mapper/thin-provisioning.txt
@@ -287,6 +287,17 @@ iii) Messages
         the current transaction id is when you change it with this
         compare-and-swap message.
 
+    reserve_metadata_snap
+
+        Reserve a copy of the data mapping btree for use by userland.
+        This allows userland to inspect the mappings as they were when
+        this message was executed.  Use the pool's status command to
+        get the root block associated with the metadata snapshot.
+
+    release_metadata_snap
+
+        Release a previously reserved copy of the data mapping btree.
+
 'thin' target
 -------------
 
diff --git a/Documentation/device-mapper/verity.txt b/Documentation/device-mapper/verity.txt
index 32e48797a14f..9884681535ee 100644
--- a/Documentation/device-mapper/verity.txt
+++ b/Documentation/device-mapper/verity.txt
@@ -7,39 +7,39 @@ This target is read-only.
 
 Construction Parameters
 =======================
-    <version> <dev> <hash_dev> <hash_start>
+    <version> <dev> <hash_dev>
     <data_block_size> <hash_block_size>
     <num_data_blocks> <hash_start_block>
     <algorithm> <digest> <salt>
 
 <version>
-    This is the version number of the on-disk format.
+    This is the type of the on-disk hash format.
 
     0 is the original format used in the Chromium OS.
-        The salt is appended when hashing, digests are stored continuously and
-        the rest of the block is padded with zeros.
+      The salt is appended when hashing, digests are stored continuously and
+      the rest of the block is padded with zeros.
 
     1 is the current format that should be used for new devices.
-        The salt is prepended when hashing and each digest is
-        padded with zeros to the power of two.
+      The salt is prepended when hashing and each digest is
+      padded with zeros to the power of two.
 
 <dev>
-    This is the device containing the data the integrity of which needs to be
+    This is the device containing data, the integrity of which needs to be
     checked.  It may be specified as a path, like /dev/sdaX, or a device number,
     <major>:<minor>.
 
 <hash_dev>
-    This is the device that that supplies the hash tree data.  It may be
+    This is the device that supplies the hash tree data.  It may be
     specified similarly to the device path and may be the same device.  If the
-    same device is used, the hash_start should be outside of the dm-verity
-    configured device size.
+    same device is used, the hash_start should be outside the configured
+    dm-verity device.
 
 <data_block_size>
-    The block size on a data device.  Each block corresponds to one digest on
-    the hash device.
+    The block size on a data device in bytes.
+    Each block corresponds to one digest on the hash device.
 
 <hash_block_size>
-    The size of a hash block.
+    The size of a hash block in bytes.
 
 <num_data_blocks>
     The number of data blocks on the data device.  Additional blocks are
@@ -65,7 +65,7 @@ Construction Parameters
 Theory of operation
 ===================
 
-dm-verity is meant to be setup as part of a verified boot path.  This
+dm-verity is meant to be set up as part of a verified boot path.  This
 may be anything ranging from a boot using tboot or trustedgrub to just
 booting from a known-good device (like a USB drive or CD).
 
@@ -73,20 +73,20 @@ When a dm-verity device is configured, it is expected that the caller
 has been authenticated in some way (cryptographic signatures, etc).
 After instantiation, all hashes will be verified on-demand during
 disk access.  If they cannot be verified up to the root node of the
-tree, the root hash, then the I/O will fail.  This should identify
+tree, the root hash, then the I/O will fail.  This should detect
 tampering with any data on the device and the hash data.
 
 Cryptographic hashes are used to assert the integrity of the device on a
-per-block basis.  This allows for a lightweight hash computation on first read
-into the page cache.  Block hashes are stored linearly-aligned to the nearest
-block the size of a page.
+per-block basis. This allows for a lightweight hash computation on first read
+into the page cache. Block hashes are stored linearly, aligned to the nearest
+block size.
 
 Hash Tree
 ---------
 
 Each node in the tree is a cryptographic hash.  If it is a leaf node, the hash
-is of some block data on disk.  If it is an intermediary node, then the hash is
-of a number of child nodes.
+of some data block on disk is calculated. If it is an intermediary node,
+the hash of a number of child nodes is calculated.
 
 Each entry in the tree is a collection of neighboring nodes that fit in one
 block.  The number is determined based on block_size and the size of the
@@ -110,63 +110,23 @@ alg = sha256, num_blocks = 32768, block_size = 4096
 On-disk format
 ==============
 
-Below is the recommended on-disk format. The verity kernel code does not
-read the on-disk header. It only reads the hash blocks which directly
-follow the header. It is expected that a user-space tool will verify the
-integrity of the verity_header and then call dmsetup with the correct
-parameters. Alternatively, the header can be omitted and the dmsetup
-parameters can be passed via the kernel command-line in a rooted chain
-of trust where the command-line is verified.
+The verity kernel code does not read the verity metadata on-disk header.
+It only reads the hash blocks which directly follow the header.
+It is expected that a user-space tool will verify the integrity of the
+verity header.
 
-The on-disk format is especially useful in cases where the hash blocks
-are on a separate partition. The magic number allows easy identification
-of the partition contents. Alternatively, the hash blocks can be stored
-in the same partition as the data to be verified. In such a configuration
-the filesystem on the partition would be sized a little smaller than
-the full-partition, leaving room for the hash blocks.
-
-struct superblock {
-        uint8_t signature[8]
-                "verity\0\0";
-
-        uint8_t version;
-                1 - current format
-
-        uint8_t data_block_bits;
-                log2(data block size)
-
-        uint8_t hash_block_bits;
-                log2(hash block size)
-
-        uint8_t pad1[1];
-                zero padding
-
-        uint16_t salt_size;
-                big-endian salt size
-
-        uint8_t pad2[2];
-                zero padding
-
-        uint32_t data_blocks_hi;
-                big-endian high 32 bits of the 64-bit number of data blocks
-
-        uint32_t data_blocks_lo;
-                big-endian low 32 bits of the 64-bit number of data blocks
-
-        uint8_t algorithm[16];
-                cryptographic algorithm
-
-        uint8_t salt[384];
-                salt (the salt size is specified above)
-
-        uint8_t pad3[88];
-                zero padding to 512-byte boundary
-}
+Alternatively, the header can be omitted and the dmsetup parameters can
+be passed via the kernel command-line in a rooted chain of trust where
+the command-line is verified.
 
 Directly following the header (and with sector number padded to the next hash
 block boundary) are the hash blocks which are stored a depth at a time
 (starting from the root), sorted in order of increasing index.
 
+The full specification of kernel parameters and on-disk metadata format
+is available at the cryptsetup project's wiki page
+  http://code.google.com/p/cryptsetup/wiki/DMVerity
+
 Status
 ======
 V (for Valid) is returned if every check performed so far was valid.
@@ -174,21 +134,22 @@ If any check failed, C (for Corruption) is returned.
 
 Example
 =======
-
-Setup a device:
-  dmsetup create vroot --table \
-    "0 2097152 "\
-    "verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\
+Set up a device:
+  # dmsetup create vroot --readonly --table \
+    "0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\
     "4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
     "1234000000000000000000000000000000000000000000000000000000000000"
 
 A command line tool veritysetup is available to compute or verify
-the hash tree or activate the kernel driver.  This is available from
-the LVM2 upstream repository and may be supplied as a package called
-device-mapper-verity-tools:
-    git://sources.redhat.com/git/lvm2
-    http://sourceware.org/git/?p=lvm2.git
-    http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2
-
-veritysetup -a vroot /dev/sda1 /dev/sda2 \
-        4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
+the hash tree or activate the kernel device. This is available from
+the cryptsetup upstream repository http://code.google.com/p/cryptsetup/
+(as a libcryptsetup extension).
+
+Create hash on the device:
+  # veritysetup format /dev/sda1 /dev/sda2
+  ...
+  Root hash: 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
+
+Activate the device:
+  # veritysetup create vroot /dev/sda1 /dev/sda2 \
+    4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 00383186d8fb..47a154f30290 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -98,7 +98,8 @@ Your cooperation is appreciated.
                   8 = /dev/random       Nondeterministic random number gen.
                   9 = /dev/urandom      Faster, less secure random number gen.
                  10 = /dev/aio          Asynchronous I/O notification interface
-                 11 = /dev/kmsg         Writes to this come out as printk's
+                 11 = /dev/kmsg         Writes to this come out as printk's, reads
+                                        export the buffered printk records.
                  12 = /dev/oldmem       Used by crashdump kernels to access
                                         the memory of the kernel that crashed.
 
@@ -846,13 +847,7 @@ Your cooperation is appreciated.
                     ...
                  31 = /dev/tap15        16th Ethertap device
 
- 36 block       MCA ESDI hard disk
-                  0 = /dev/eda          First ESDI disk whole disk
-                 64 = /dev/edb          Second ESDI disk whole disk
-                    ...
-
-                Partitions are handled in the same way as IDE disks
-                (see major number 3).
+ 36 block       OBSOLETE (was MCA ESDI hard disk)
 
  37 char        IDE tape
                   0 = /dev/ht0          First IDE tape
diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
new file mode 100644
index 000000000000..52478c83d0cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -0,0 +1,27 @@
+* ARM architected timer
+
+ARM Cortex-A7 and Cortex-A15 have a per-core architected timer, which
+provides per-cpu timers.
+
+The timer is attached to a GIC to deliver its per-processor interrupts.
+
+** Timer node properties:
+
+- compatible : Should at least contain "arm,armv7-timer".
+
+- interrupts : Interrupt list for secure, non-secure, virtual and
+  hypervisor timers, in that order.
+
+- clock-frequency : The frequency of the main counter, in Hz. Optional.
+
+Example:
+
+        timer {
+                compatible = "arm,cortex-a15-timer",
+                             "arm,armv7-timer";
+                interrupts = <1 13 0xf08>,
+                             <1 14 0xf08>,
+                             <1 11 0xf08>,
+                             <1 10 0xf08>;
+                clock-frequency = <100000000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
new file mode 100644
index 000000000000..c63097d6afeb
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
@@ -0,0 +1,65 @@
+* AT91's Analog to Digital Converter (ADC)
+
+Required properties:
+  - compatible: Should be "atmel,at91sam9260-adc"
+  - reg: Should contain ADC registers location and length
+  - interrupts: Should contain the IRQ line for the ADC
+  - atmel,adc-channel-base: Offset of the first channel data register
+  - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this
+    device
+  - atmel,adc-drdy-mask: Mask of the DRDY interruption in the ADC
+  - atmel,adc-num-channels: Number of channels available in the ADC
+  - atmel,adc-startup-time: Startup Time of the ADC in microseconds as
+    defined in the datasheet
+  - atmel,adc-status-register: Offset of the Interrupt Status Register
+  - atmel,adc-trigger-register: Offset of the Trigger Register
+  - atmel,adc-vref: Reference voltage in millivolts for the conversions
+
+Optional properties:
+  - atmel,adc-use-external: Boolean to enable of external triggers
+ 
+Optional trigger Nodes:
+  - Required properties:
+    * trigger-name: Name of the trigger exposed to the user
+    * trigger-value: Value to put in the Trigger register
+      to activate this trigger
+  - Optional properties:
+    * trigger-external: Is the trigger an external trigger?
+
+Examples:
+adc0: adc@fffb0000 {
+        compatible = "atmel,at91sam9260-adc";
+        reg = <0xfffb0000 0x100>;
+        interrupts = <20 4>;
+        atmel,adc-channel-base = <0x30>;
+        atmel,adc-channels-used = <0xff>;
+        atmel,adc-drdy-mask = <0x10000>;
+        atmel,adc-num-channels = <8>;
+        atmel,adc-startup-time = <40>;
+        atmel,adc-status-register = <0x1c>;
+        atmel,adc-trigger-register = <0x08>;
+        atmel,adc-use-external;
+        atmel,adc-vref = <3300>;
+
+        trigger@0 {
+                trigger-name = "external-rising";
+                trigger-value = <0x1>;
+                trigger-external;
+        };
+        trigger@1 {
+                trigger-name = "external-falling";
+                trigger-value = <0x2>;
+                trigger-external;
+        };
+
+        trigger@2 {
+                trigger-name = "external-any";
+                trigger-value = <0x3>;
+                trigger-external;
+        };
+
+        trigger@3 {
+                trigger-name = "continuous";
+                trigger-value = <0x6>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index bfbc771a65f8..ac9e7516756e 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -1,6 +1,14 @@
 Freescale i.MX Platforms Device Tree Bindings
 -----------------------------------------------
 
+i.MX23 Evaluation Kit
+Required root node properties:
+    - compatible = "fsl,imx23-evk", "fsl,imx23";
+
+i.MX28 Evaluation Kit
+Required root node properties:
+    - compatible = "fsl,imx28-evk", "fsl,imx28";
+
 i.MX51 Babbage Board
 Required root node properties:
     - compatible = "fsl,imx51-babbage", "fsl,imx51";
@@ -29,6 +37,10 @@ i.MX6 Quad SABRE Lite Board
 Required root node properties:
     - compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";
 
+i.MX6 Quad SABRE Smart Device Board
+Required root node properties:
+    - compatible = "fsl,imx6q-sabresd", "fsl,imx6q";
+
 Generic i.MX boards
 -------------------
 
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index 9b4b82a721b6..62eb8df1e08d 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -11,7 +11,9 @@ have PPIs or SGIs.
 Main node required properties:
 
 - compatible : should be one of:
+        "arm,cortex-a15-gic"
         "arm,cortex-a9-gic"
+        "arm,cortex-a7-gic"
         "arm,arm11mp-gic"
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
@@ -39,8 +41,9 @@ Main node required properties:
   the GIC cpu interface register base and size.
 
 Optional
-- interrupts    : Interrupt source of the parent interrupt controller. Only
-  present on secondary GICs.
+- interrupts    : Interrupt source of the parent interrupt controller on
+  secondary GICs, or VGIC maintainance interrupt on primary GIC (see
+  below).
 
 - cpu-offset    : per-cpu offset within the distributor and cpu interface
   regions, used when the GIC doesn't have banked registers. The offset is
@@ -57,3 +60,31 @@ Example:
                       <0xfff10100 0x100>;
         };
 
+
+* GIC virtualization extensions (VGIC)
+
+For ARM cores that support the virtualization extensions, additional
+properties must be described (they only exist if the GIC is the
+primary interrupt controller).
+
+Required properties:
+
+- reg : Additional regions specifying the base physical address and
+  size of the VGIC registers. The first additional region is the GIC
+  virtual interface control register base and size. The 2nd additional
+  region is the GIC virtual cpu interface register base and size.
+
+- interrupts : VGIC maintainance interrupt.
+
+Example:
+
+        interrupt-controller@2c001000 {
+                compatible = "arm,cortex-a15-gic";
+                #interrupt-cells = <3>;
+                interrupt-controller;
+                reg = <0x2c001000 0x1000>,
+                      <0x2c002000 0x1000>,
+                      <0x2c004000 0x2000>,
+                      <0x2c006000 0x2000>;
+                interrupts = <1 9 0xf04>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt b/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt
new file mode 100644
index 000000000000..539adca19e8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt
@@ -0,0 +1,38 @@
+* NXP LPC32xx Main Interrupt Controller
+  (MIC, including SIC1 and SIC2 secondary controllers)
+
+Required properties:
+- compatible: Should be "nxp,lpc3220-mic"
+- interrupt-controller: Identifies the node as an interrupt controller.
+- interrupt-parent: Empty for the interrupt controller itself
+- #interrupt-cells: The number of cells to define the interrupts. Should be 2.
+  The first cell is the IRQ number
+  The second cell is used to specify mode:
+      1 = low-to-high edge triggered
+      2 = high-to-low edge triggered
+      4 = active high level-sensitive
+      8 = active low level-sensitive
+      Default for internal sources should be set to 4 (active high).
+- reg: Should contain MIC registers location and length
+
+Examples:
+        /*
+         * MIC
+         */
+        mic: interrupt-controller@40008000 {
+                compatible = "nxp,lpc3220-mic";
+                interrupt-controller;
+                interrupt-parent;
+                #interrupt-cells = <2>;
+                reg = <0x40008000 0xC000>;
+        };
+
+        /*
+         * ADC
+         */
+        adc@40048000 {
+                compatible = "nxp,lpc3220-adc";
+                reg = <0x40048000 0x1000>;
+                interrupt-parent = <&mic>;
+                interrupts = <39 4>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/lpc32xx.txt b/Documentation/devicetree/bindings/arm/lpc32xx.txt
new file mode 100644
index 000000000000..56ec8ddc4a3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/lpc32xx.txt
@@ -0,0 +1,8 @@
+NXP LPC32xx Platforms Device Tree Bindings
+------------------------------------------
+
+Boards with the NXP LPC32xx SoC shall have the following properties:
+
+Required root node property:
+
+compatible: must be "nxp,lpc3220", "nxp,lpc3230", "nxp,lpc3240" or "nxp,lpc3250"
diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
new file mode 100644
index 000000000000..80b9a94d9a23
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -0,0 +1,40 @@
+* Marvell MMP Interrupt controller
+
+Required properties:
+- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
+  "mrvl,mmp2-mux-intc"
+- reg : Address and length of the register set of the interrupt controller.
+  If the interrupt controller is intc, address and length means the range
+  of the whold interrupt controller. If the interrupt controller is mux-intc,
+  address and length means one register. Since address of mux-intc is in the
+  range of intc. mux-intc is secondary interrupt controller.
+- reg-names : Name of the register set of the interrupt controller. It's
+  only required in mux-intc interrupt controller.
+- interrupts : Should be the port interrupt shared by mux interrupts. It's
+  only required in mux-intc interrupt controller.
+- interrupt-controller : Identifies the node as an interrupt controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source.
+- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
+  controller.
+- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
+  detection first.
+
+Example:
+        intc: interrupt-controller@d4282000 {
+                compatible = "mrvl,mmp2-intc";
+                interrupt-controller;
+                #interrupt-cells = <1>;
+                reg = <0xd4282000 0x1000>;
+                mrvl,intc-nr-irqs = <64>;
+        };
+
+        intcmux4@d4282150 {
+                compatible = "mrvl,mmp2-mux-intc";
+                interrupts = <4>;
+                interrupt-controller;
+                #interrupt-cells = <1>;
+                reg = <0x150 0x4>, <0x168 0x4>;
+                reg-names = "mux status", "mux mask";
+                mrvl,intc-nr-irqs = <2>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
index d8de933e9d81..117d741a2e4f 100644
--- a/Documentation/devicetree/bindings/arm/mrvl.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
@@ -4,3 +4,11 @@ Marvell Platforms Device Tree Bindings
 PXA168 Aspenite Board
 Required root node properties:
         - compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
+
+PXA910 DKB Board
+Required root node properties:
+        - compatible = "mrvl,pxa910-dkb";
+
+MMP2 Brownstone Board
+Required root node properties:
+        - compatible = "mrvl,mmp2-brownstone";
diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
new file mode 100644
index 000000000000..9a6e251462e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
@@ -0,0 +1,13 @@
+* Marvell MMP Timer controller
+
+Required properties:
+- compatible : Should be "mrvl,mmp-timer".
+- reg : Address and length of the register set of timer controller.
+- interrupts : Should be the interrupt number.
+
+Example:
+        timer0: timer@d4014000 {
+                compatible = "mrvl,mmp-timer";
+                reg = <0xd4014000 0x100>;
+                interrupts = <13>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt b/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt
new file mode 100644
index 000000000000..f2f2171e530e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt
@@ -0,0 +1,52 @@
+* Samsung Exynos Interrupt Combiner Controller
+
+Samsung's Exynos4 architecture includes a interrupt combiner controller which
+can combine interrupt sources as a group and provide a single interrupt request
+for the group. The interrupt request from each group are connected to a parent
+interrupt controller, such as GIC in case of Exynos4210.
+
+The interrupt combiner controller consists of multiple combiners. Upto eight
+interrupt sources can be connected to a combiner. The combiner outputs one
+combined interrupt for its eight interrupt sources. The combined interrupt
+is usually connected to a parent interrupt controller.
+
+A single node in the device tree is used to describe the interrupt combiner
+controller module (which includes multiple combiners). A combiner in the
+interrupt controller module shares config/control registers with other
+combiners. For example, a 32-bit interrupt enable/disable config register
+can accommodate upto 4 interrupt combiners (with each combiner supporting
+upto 8 interrupt sources).
+
+Required properties:
+- compatible: should be "samsung,exynos4210-combiner".
+- interrupt-controller: Identifies the node as an interrupt controller.
+- #interrupt-cells: should be <2>. The meaning of the cells are
+        * First Cell: Combiner Group Number.
+        * Second Cell: Interrupt number within the group.
+- reg: Base address and size of interrupt combiner registers.
+- interrupts: The list of interrupts generated by the combiners which are then
+    connected to a parent interrupt controller. The format of the interrupt
+    specifier depends in the interrupt parent controller.
+
+Optional properties:
+- samsung,combiner-nr: The number of interrupt combiners supported. If this
+  property is not specified, the default number of combiners is assumed
+  to be 16.
+- interrupt-parent: pHandle of the parent interrupt controller, if not
+  inherited from the parent node.
+
+
+Example:
+
+        The following is a an example from the Exynos4210 SoC dtsi file.
+
+        combiner:interrupt-controller@10440000 {
+                compatible = "samsung,exynos4210-combiner";
+                interrupt-controller;
+                #interrupt-cells = <2>;
+                reg = <0x10440000 0x1000>;
+                interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+                             <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
+                             <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+                             <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/spear-timer.txt b/Documentation/devicetree/bindings/arm/spear-timer.txt
new file mode 100644
index 000000000000..c0017221cf55
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/spear-timer.txt
@@ -0,0 +1,18 @@
+* SPEAr ARM Timer
+
+** Timer node required properties:
+
+- compatible : Should be:
+        "st,spear-timer"
+- reg: Address range of the timer registers
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+- interrupt: Should contain the timer interrupt number
+
+Example:
+
+        timer@f0000000 {
+                compatible = "st,spear-timer";
+                reg = <0xf0000000 0x400>;
+                interrupts = <2>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/spear.txt b/Documentation/devicetree/bindings/arm/spear.txt
index f8e54f092328..0d42949df6c2 100644
--- a/Documentation/devicetree/bindings/arm/spear.txt
+++ b/Documentation/devicetree/bindings/arm/spear.txt
@@ -2,7 +2,25 @@ ST SPEAr Platforms Device Tree Bindings
 ---------------------------------------
 
 Boards with the ST SPEAr600 SoC shall have the following properties:
+Required root node property:
+compatible = "st,spear600";
 
+Boards with the ST SPEAr300 SoC shall have the following properties:
 Required root node property:
+compatible = "st,spear300";
 
-compatible = "st,spear600";
+Boards with the ST SPEAr310 SoC shall have the following properties:
+Required root node property:
+compatible = "st,spear310";
+
+Boards with the ST SPEAr320 SoC shall have the following properties:
+Required root node property:
+compatible = "st,spear320";
+
+Boards with the ST SPEAr1310 SoC shall have the following properties:
+Required root node property:
+compatible = "st,spear1310";
+
+Boards with the ST SPEAr1340 SoC shall have the following properties:
+Required root node property:
+compatible = "st,spear1340";
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
new file mode 100644
index 000000000000..234406d41c12
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt
@@ -0,0 +1,11 @@
+NVIDIA Tegra AHB
+
+Required properties:
+- compatible : "nvidia,tegra20-ahb" or "nvidia,tegra30-ahb"
+- reg : Should contain 1 register ranges(address and length)
+
+Example:
+        ahb: ahb@6000c004 {
+                compatible = "nvidia,tegra20-ahb";
+                reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */
+        };
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt
new file mode 100644
index 000000000000..c25a0a55151d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt
@@ -0,0 +1,16 @@
+NVIDIA Tegra20 MC(Memory Controller)
+
+Required properties:
+- compatible : "nvidia,tegra20-mc"
+- reg : Should contain 2 register ranges(address and length); see the
+  example below. Note that the MC registers are interleaved with the
+  GART registers, and hence must be represented as multiple ranges.
+- interrupts : Should contain MC General interrupt.
+
+Example:
+        mc {
+                compatible = "nvidia,tegra20-mc";
+                reg = <0x7000f000 0x024
+                       0x7000f03c 0x3c4>;
+                interrupts = <0 77 0x04>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt
new file mode 100644
index 000000000000..e47e73f612f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt
@@ -0,0 +1,18 @@
+NVIDIA Tegra30 MC(Memory Controller)
+
+Required properties:
+- compatible : "nvidia,tegra30-mc"
+- reg : Should contain 4 register ranges(address and length); see the
+  example below. Note that the MC registers are interleaved with the
+  SMMU registers, and hence must be represented as multiple ranges.
+- interrupts : Should contain MC General interrupt.
+
+Example:
+        mc {
+                compatible = "nvidia,tegra30-mc";
+                reg = <0x7000f000 0x010
+                       0x7000f03c 0x1b4
+                       0x7000f200 0x028
+                       0x7000f284 0x17c>;
+                interrupts = <0 77 0x04>;
+        };
diff --git a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
new file mode 100644
index 000000000000..ded0398d3bdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
@@ -0,0 +1,19 @@
+* Freescale MXS DMA
+
+Required properties:
+- compatible : Should be "fsl,<chip>-dma-apbh" or "fsl,<chip>-dma-apbx"
+- reg : Should contain registers location and length
+
+Supported chips:
+imx23, imx28.
+
+Examples:
+dma-apbh@80004000 {
+        compatible = "fsl,imx28-dma-apbh";
+        reg = <0x80004000 2000>;
+};
+
+dma-apbx@80024000 {
+        compatible = "fsl,imx28-dma-apbx";
+        reg = <0x80024000 2000>;
+};
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
new file mode 100644
index 000000000000..c0d85dbcada5
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -0,0 +1,17 @@
+* Synopsys Designware DMA Controller
+
+Required properties:
+- compatible: "snps,dma-spear1340"
+- reg: Address range of the DMAC registers
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+- interrupt: Should contain the DMAC interrupt number
+
+Example:
+
+        dma@fc000000 {
+                compatible = "snps,dma-spear1340";
+                reg = <0xfc000000 0x1000>;
+                interrupt-parent = <&vic1>;
+                interrupts = <12>;
+        };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt b/Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt
new file mode 100644
index 000000000000..f93d51478d5a
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt
@@ -0,0 +1,38 @@
+Lantiq SoC External Bus memory mapped GPIO controller
+
+By attaching hardware latches to the EBU it is possible to create output
+only gpios. This driver configures a special memory address, which when
+written to outputs 16 bit to the latches.
+
+The node describing the memory mapped GPIOs needs to be a child of the node
+describing the "lantiq,localbus".
+
+Required properties:
+- compatible : Should be "lantiq,gpio-mm-lantiq"
+- reg : Address and length of the register set for the device
+- #gpio-cells : Should be two.  The first cell is the pin number and
+  the second cell is used to specify optional parameters (currently
+  unused).
+- gpio-controller : Marks the device node as a gpio controller.
+
+Optional properties:
+- lantiq,shadow : The default value that we shall assume as already set on the
+  shift register cascade.
+
+Example:
+
+localbus@0 {
+        #address-cells = <2>;
+        #size-cells = <1>;
+        ranges = <0 0 0x0 0x3ffffff /* addrsel0 */
+                1 0 0x4000000 0x4000010>; /* addsel1 */
+        compatible = "lantiq,localbus", "simple-bus";
+
+        gpio_mm0: gpio@4000000 {
+                compatible = "lantiq,gpio-mm";
+                reg = <1 0x0 0x10>;
+                gpio-controller;
+                #gpio-cells = <2>;
+                lantiq,shadow = <0x77f>
+        };
+}
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mxs.txt b/Documentation/devicetree/bindings/gpio/gpio-mxs.txt
new file mode 100644
index 000000000000..0c35673f7a3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mxs.txt
@@ -0,0 +1,87 @@
+* Freescale MXS GPIO controller
+
+The Freescale MXS GPIO controller is part of MXS PIN controller.  The
+GPIOs are organized in port/bank.  Each port consists of 32 GPIOs.
+
+As the GPIO controller is embedded in the PIN controller and all the
+GPIO ports share the same IO space with PIN controller, the GPIO node
+will be represented as sub-nodes of MXS pinctrl node.
+
+Required properties for GPIO node:
+- compatible : Should be "fsl,<soc>-gpio".  The supported SoCs include
+  imx23 and imx28.
+- interrupts : Should be the port interrupt shared by all 32 pins.
+- 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 (currently
+  unused).
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells : Should be 2.  The first cell is the GPIO number.
+  The second cell bits[3:0] is used to specify trigger type and level flags:
+      1 = low-to-high edge triggered.
+      2 = high-to-low edge triggered.
+      4 = active high level-sensitive.
+      8 = active low level-sensitive.
+
+Note: Each GPIO port should have an alias correctly numbered in "aliases"
+node.
+
+Examples:
+
+aliases {
+        gpio0 = &gpio0;
+        gpio1 = &gpio1;
+        gpio2 = &gpio2;
+        gpio3 = &gpio3;
+        gpio4 = &gpio4;
+};
+
+pinctrl@80018000 {
+        compatible = "fsl,imx28-pinctrl", "simple-bus";
+        reg = <0x80018000 2000>;
+
+        gpio0: gpio@0 {
+                compatible = "fsl,imx28-gpio";
+                interrupts = <127>;
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+        };
+
+        gpio1: gpio@1 {
+                compatible = "fsl,imx28-gpio";
+                interrupts = <126>;
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+        };
+
+        gpio2: gpio@2 {
+                compatible = "fsl,imx28-gpio";
+                interrupts = <125>;
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+        };
+
+        gpio3: gpio@3 {
+                compatible = "fsl,imx28-gpio";
+                interrupts = <124>;
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+        };
+
+        gpio4: gpio@4 {
+                compatible = "fsl,imx28-gpio";
+                interrupts = <123>;
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
new file mode 100644
index 000000000000..ee87467ad8d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
@@ -0,0 +1,31 @@
+Nomadik GPIO controller
+
+Required properties:
+- compatible            : Should be "st,nomadik-gpio".
+- reg                   : Physical base address and length of the controller's registers.
+- interrupts            : The interrupt outputs from the controller.
+- #gpio-cells           : Should be two:
+                            The first cell is the pin number.
+                            The second cell is used to specify optional parameters:
+                              - bits[3:0] trigger type and level flags:
+                                  1 = low-to-high edge triggered.
+                                  2 = high-to-low edge triggered.
+                                  4 = active high level-sensitive.
+                                  8 = active low level-sensitive.
+- gpio-controller       : Marks the device node as a GPIO controller.
+- interrupt-controller  : Marks the device node as an interrupt controller.
+- gpio-bank             : Specifies which bank a controller owns.
+- st,supports-sleepmode : Specifies whether controller can sleep or not
+
+Example:
+
+                gpio1: gpio@8012e080 {
+                        compatible = "st,nomadik-gpio";
+                        reg =  <0x8012e080 0x80>;
+                        interrupts = <0 120 0x4>;
+                        #gpio-cells = <2>;
+                        gpio-controller;
+                        interrupt-controller;
+                        supports-sleepmode;
+                        gpio-bank = <1>;
+                };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt
new file mode 100644
index 000000000000..854de130a971
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt
@@ -0,0 +1,42 @@
+Lantiq SoC Serial To Parallel (STP) GPIO controller
+
+The Serial To Parallel (STP) is found on MIPS based Lantiq socs. It is a
+peripheral controller used to drive external shift register cascades. At most
+3 groups of 8 bits can be driven. The hardware is able to allow the DSL modem
+to drive the 2 LSBs of the cascade automatically.
+
+
+Required properties:
+- compatible : Should be "lantiq,gpio-stp-xway"
+- reg : Address and length of the register set for the device
+- #gpio-cells : Should be two.  The first cell is the pin number and
+  the second cell is used to specify optional parameters (currently
+  unused).
+- gpio-controller : Marks the device node as a gpio controller.
+
+Optional properties:
+- lantiq,shadow : The default value that we shall assume as already set on the
+  shift register cascade.
+- lantiq,groups : Set the 3 bit mask to select which of the 3 groups are enabled
+  in the shift register cascade.
+- lantiq,dsl : The dsl core can control the 2 LSBs of the gpio cascade. This 2 bit
+  property can enable this feature.
+- lantiq,phy1 : The gphy1 core can control 3 bits of the gpio cascade.
+- lantiq,phy2 : The gphy2 core can control 3 bits of the gpio cascade.
+- lantiq,rising : use rising instead of falling edge for the shift register
+
+Example:
+
+gpio1: stp@E100BB0 {
+        compatible = "lantiq,gpio-stp-xway";
+        reg = <0xE100BB0 0x40>;
+        #gpio-cells = <2>;
+        gpio-controller;
+
+        lantiq,shadow = <0xffff>;
+        lantiq,groups = <0x7>;
+        lantiq,dsl = <0x3>;
+        lantiq,phy1 = <0x7>;
+        lantiq,phy2 = <0x7>;
+        /* lantiq,rising; */
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt b/Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt
new file mode 100644
index 000000000000..49819367a011
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt
@@ -0,0 +1,43 @@
+NXP LPC32xx SoC GPIO controller
+
+Required properties:
+- compatible: must be "nxp,lpc3220-gpio"
+- reg: Physical base address and length of the controller's registers.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be 3:
+   1) bank:
+      0: GPIO P0
+      1: GPIO P1
+      2: GPIO P2
+      3: GPIO P3
+      4: GPI P3
+      5: GPO P3
+   2) pin number
+   3) optional parameters:
+      - bit 0 specifies polarity (0 for normal, 1 for inverted)
+- reg: Index of the GPIO group
+
+Example:
+
+        gpio: gpio@40028000 {
+                compatible = "nxp,lpc3220-gpio";
+                reg = <0x40028000 0x1000>;
+                gpio-controller;
+                #gpio-cells = <3>; /* bank, pin, flags */
+        };
+
+        leds {
+                compatible = "gpio-leds";
+
+                led0 {
+                        gpios = <&gpio 5 1 1>; /* GPO_P3 1, active low */
+                        linux,default-trigger = "heartbeat";
+                        default-state = "off";
+                };
+
+                led1 {
+                        gpios = <&gpio 5 14 1>; /* GPO_P3 14, active low */
+                        linux,default-trigger = "timer";
+                        default-state = "off";
+                };
+        };
diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index 1e34cfe5ebea..05428f39d9ac 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -3,19 +3,25 @@
 Required properties:
 - compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio"
 - reg : Address and length of the register set for the device
-- interrupts : Should be the port interrupt shared by all gpio pins, if
-- interrupt-name : Should be the name of irq resource.
-  one number.
+- interrupts : Should be the port interrupt shared by all gpio pins.
+  There're three gpio interrupts in arch-pxa, and they're gpio0,
+  gpio1 and gpio_mux. There're only one gpio interrupt in arch-mmp,
+  gpio_mux.
+- interrupt-name : Should be the name of irq resource. Each interrupt
+  binds its interrupt-name.
+- interrupt-controller : Identifies the node as an interrupt controller.
+- #interrupt-cells: Specifies the number of cells needed to encode an
+  interrupt source.
 - gpio-controller : Marks the device node as a gpio controller.
 - #gpio-cells : Should be one.  It is the pin number.
 
 Example:
 
         gpio: gpio@d4019000 {
-                compatible = "mrvl,mmp-gpio", "mrvl,pxa-gpio";
+                compatible = "mrvl,mmp-gpio";
                 reg = <0xd4019000 0x1000>;
-                interrupts = <49>, <17>, <18>;
-                interrupt-name = "gpio_mux", "gpio0", "gpio1";
+                interrupts = <49>;
+                interrupt-name = "gpio_mux";
                 gpio-controller;
                 #gpio-cells = <1>;
                 interrupt-controller;
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt
new file mode 100644
index 000000000000..ae8af1694e95
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt
@@ -0,0 +1,93 @@
+Pinctrl-based I2C Bus Mux
+
+This binding describes an I2C bus multiplexer that uses pin multiplexing to
+route the I2C signals, and represents the pin multiplexing configuration
+using the pinctrl device tree bindings.
+
+                                 +-----+  +-----+
+                                 | dev |  | dev |
+    +------------------------+   +-----+  +-----+
+    | SoC                    |      |        |
+    |                   /----|------+--------+
+    |   +---+   +------+     | child bus A, on first set of pins
+    |   |I2C|---|Pinmux|     |
+    |   +---+   +------+     | child bus B, on second set of pins
+    |                   \----|------+--------+--------+
+    |                        |      |        |        |
+    +------------------------+  +-----+  +-----+  +-----+
+                                | dev |  | dev |  | dev |
+                                +-----+  +-----+  +-----+
+
+Required properties:
+- compatible: i2c-mux-pinctrl
+- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
+  port is connected to.
+
+Also required are:
+
+* Standard pinctrl properties that specify the pin mux state for each child
+  bus. See ../pinctrl/pinctrl-bindings.txt.
+
+* Standard I2C mux properties. See mux.txt in this directory.
+
+* I2C child bus nodes. See mux.txt in this directory.
+
+For each named state defined in the pinctrl-names property, an I2C child bus
+will be created. I2C child bus numbers are assigned based on the index into
+the pinctrl-names property.
+
+The only exception is that no bus will be created for a state named "idle". If
+such a state is defined, it must be the last entry in pinctrl-names. For
+example:
+
+        pinctrl-names = "ddc", "pta", "idle"  ->  ddc = bus 0, pta = bus 1
+        pinctrl-names = "ddc", "idle", "pta"  ->  Invalid ("idle" not last)
+        pinctrl-names = "idle", "ddc", "pta"  ->  Invalid ("idle" not last)
+
+Whenever an access is made to a device on a child bus, the relevant pinctrl
+state will be programmed into hardware.
+
+If an idle state is defined, whenever an access is not being made to a device
+on a child bus, the idle pinctrl state will be programmed into hardware.
+
+If an idle state is not defined, the most recently used pinctrl state will be
+left programmed into hardware whenever no access is being made of a device on
+a child bus.
+
+Example:
+
+        i2cmux {
+                compatible = "i2c-mux-pinctrl";
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                i2c-parent = <&i2c1>;
+
+                pinctrl-names = "ddc", "pta", "idle";
+                pinctrl-0 = <&state_i2cmux_ddc>;
+                pinctrl-1 = <&state_i2cmux_pta>;
+                pinctrl-2 = <&state_i2cmux_idle>;
+
+                i2c@0 {
+                        reg = <0>;
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        eeprom {
+                                compatible = "eeprom";
+                                reg = <0x50>;
+                        };
+                };
+
+                i2c@1 {
+                        reg = <1>;
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        eeprom {
+                                compatible = "eeprom";
+                                reg = <0x50>;
+                        };
+                };
+        };
+
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
new file mode 100644
index 000000000000..1bfc02de1b0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
@@ -0,0 +1,16 @@
+* Freescale MXS Inter IC (I2C) Controller
+
+Required properties:
+- compatible: Should be "fsl,<chip>-i2c"
+- reg: Should contain registers location and length
+- interrupts: Should contain ERROR and DMA interrupts
+
+Examples:
+
+i2c0: i2c@80058000 {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        compatible = "fsl,imx28-i2c";
+        reg = <0x80058000 2000>;
+        interrupts = <111 68>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
index 071eb3caae91..b891ee218354 100644
--- a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
@@ -3,34 +3,31 @@
 Required properties :
 
  - reg : Offset and length of the register set for the device
- - compatible : should be "mrvl,mmp-twsi" where CHIP is the name of a
+ - compatible : should be "mrvl,mmp-twsi" where mmp is the name of a
    compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
    For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
    as shown in the example below.
 
 Recommended properties :
 
- - interrupts : <a b> where a is the interrupt number and b is a
-   field that represents an encoding of the sense and level
-   information for the interrupt.  This should be encoded based on
-   the information in section 2) depending on the type of interrupt
-   controller you have.
+ - interrupts : the interrupt number
  - interrupt-parent : the phandle for the interrupt controller that
-   services interrupts for this device.
+   services interrupts for this device. If the parent is the default
+   interrupt controller in device tree, it could be ignored.
  - mrvl,i2c-polling : Disable interrupt of i2c controller. Polling
    status register of i2c controller instead.
  - mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
 
 Examples:
         twsi1: i2c@d4011000 {
-                compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
+                compatible = "mrvl,mmp-twsi";
                 reg = <0xd4011000 0x1000>;
                 interrupts = <7>;
                 mrvl,i2c-fast-mode;
         };
         
         twsi2: i2c@d4025000 {
-                compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
+                compatible = "mrvl,mmp-twsi";
                 reg = <0xd4025000 0x1000>;
                 interrupts = <58>;
         };
diff --git a/Documentation/devicetree/bindings/i2c/mux.txt b/Documentation/devicetree/bindings/i2c/mux.txt
new file mode 100644
index 000000000000..af84cce5cd7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/mux.txt
@@ -0,0 +1,60 @@
+Common i2c bus multiplexer/switch properties.
+
+An i2c bus multiplexer/switch will have several child busses that are
+numbered uniquely in a device dependent manner.  The nodes for an i2c bus
+multiplexer/switch will have one child node for each child
+bus.
+
+Required properties:
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Required properties for child nodes:
+- #address-cells = <1>;
+- #size-cells = <0>;
+- reg : The sub-bus number.
+
+Optional properties for child nodes:
+- Other properties specific to the multiplexer/switch hardware.
+- Child nodes conforming to i2c bus binding
+
+
+Example :
+
+        /*
+           An NXP pca9548 8 channel I2C multiplexer at address 0x70
+           with two NXP pca8574 GPIO expanders attached, one each to
+           ports 3 and 4.
+         */
+
+        mux@70 {
+                compatible = "nxp,pca9548";
+                reg = <0x70>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                i2c@3 {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        reg = <3>;
+
+                        gpio1: gpio@38 {
+                                compatible = "nxp,pca8574";
+                                reg = <0x38>;
+                                #gpio-cells = <2>;
+                                gpio-controller;
+                        };
+                };
+                i2c@4 {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        reg = <4>;
+
+                        gpio2: gpio@38 {
+                                compatible = "nxp,pca8574";
+                                reg = <0x38>;
+                                #gpio-cells = <2>;
+                                gpio-controller;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/i2c/pnx.txt b/Documentation/devicetree/bindings/i2c/pnx.txt
new file mode 100644
index 000000000000..fe98ada33ee4
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/pnx.txt
@@ -0,0 +1,36 @@
+* NXP PNX I2C Controller
+
+Required properties:
+
+ - reg: Offset and length of the register set for the device
+ - compatible: should be "nxp,pnx-i2c"
+ - interrupts: configure one interrupt line
+ - #address-cells: always 1 (for i2c addresses)
+ - #size-cells: always 0
+ - interrupt-parent: the phandle for the interrupt controller that
+   services interrupts for this device.
+
+Optional properties:
+
+ - clock-frequency: desired I2C bus clock frequency in Hz, Default: 100000 Hz
+
+Examples:
+
+        i2c1: i2c@400a0000 {
+                compatible = "nxp,pnx-i2c";
+                reg = <0x400a0000 0x100>;
+                interrupt-parent = <&mic>;
+                interrupts = <51 0>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
+
+        i2c2: i2c@400a8000 {
+                compatible = "nxp,pnx-i2c";
+                reg = <0x400a8000 0x100>;
+                interrupt-parent = <&mic>;
+                interrupts = <50 0>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+                clock-frequency = <100000>;
+        };
diff --git a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt
index 38832c712919..b6cb5a12c672 100644
--- a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt
@@ -6,14 +6,18 @@ Required properties:
   - compatible: value should be either of the following.
       (a) "samsung, s3c2410-i2c", for i2c compatible with s3c2410 i2c.
       (b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c.
+      (c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used
+          inside HDMIPHY block found on several samsung SoCs
   - reg: physical base address of the controller and length of memory mapped
     region.
   - interrupts: interrupt number to the cpu.
   - samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges.
-  - gpios: The order of the gpios should be the following: <SDA, SCL>.
-    The gpio specifier depends on the gpio controller.
 
 Optional properties:
+  - gpios: The order of the gpios should be the following: <SDA, SCL>.
+    The gpio specifier depends on the gpio controller. Required in all
+    cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output
+    lines are permanently wired to the respective client
   - samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not
     specified, default value is 0.
   - samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
diff --git a/Documentation/devicetree/bindings/i2c/xiic.txt b/Documentation/devicetree/bindings/i2c/xiic.txt
new file mode 100644
index 000000000000..ceabbe91ae44
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/xiic.txt
@@ -0,0 +1,22 @@
+Xilinx IIC controller:
+
+Required properties:
+- compatible : Must be "xlnx,xps-iic-2.00.a"
+- reg : IIC register location and length
+- interrupts : IIC controller unterrupt
+- #address-cells = <1>
+- #size-cells = <0>
+
+Optional properties:
+- Child nodes conforming to i2c bus binding
+
+Example:
+
+        axi_iic_0: i2c@40800000 {
+                compatible = "xlnx,xps-iic-2.00.a";
+                interrupts = < 1 2 >;
+                reg = < 0x40800000 0x10000 >;
+
+                #size-cells = <0>;
+                #address-cells = <1>;
+        };
diff --git a/Documentation/devicetree/bindings/input/fsl-mma8450.txt b/Documentation/devicetree/bindings/input/fsl-mma8450.txt
index a00c94ccbdee..0b96e5737d3a 100644
--- a/Documentation/devicetree/bindings/input/fsl-mma8450.txt
+++ b/Documentation/devicetree/bindings/input/fsl-mma8450.txt
@@ -2,6 +2,7 @@
 
 Required properties:
 - compatible : "fsl,mma8450".
+- reg: the I2C address of MMA8450
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/input/spear-keyboard.txt b/Documentation/devicetree/bindings/input/spear-keyboard.txt
new file mode 100644
index 000000000000..4a846d26da23
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/spear-keyboard.txt
@@ -0,0 +1,20 @@
+* SPEAr keyboard controller
+
+Required properties:
+- compatible: "st,spear300-kbd"
+
+Optional properties, in addition to those specified by the shared
+matrix-keyboard bindings:
+- autorepeat: bool: enables key autorepeat
+- st,mode: keyboard mode: 0 - 9x9, 1 - 6x6, 2 - 2x2
+
+Example:
+
+kbd@fc400000 {
+        compatible = "st,spear300-kbd";
+        reg = <0xfc400000 0x100>;
+        linux,keymap = < 0x00030012
+                         0x0102003a >;
+        autorepeat;
+        st,mode = <0>;
+};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt b/Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt
new file mode 100644
index 000000000000..41cbf4b7a670
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt
@@ -0,0 +1,16 @@
+* NXP LPC32xx SoC Touchscreen Controller (TSC)
+
+Required properties:
+- compatible: must be "nxp,lpc3220-tsc"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: The TSC/ADC interrupt
+
+Example:
+
+        tsc@40048000 {
+                compatible = "nxp,lpc3220-tsc";
+                reg = <0x40048000 0x1000>;
+                interrupt-parent = <&mic>;
+                interrupts = <39 0>;
+        };
diff --git a/Documentation/devicetree/bindings/input/twl6040-vibra.txt b/Documentation/devicetree/bindings/input/twl6040-vibra.txt
new file mode 100644
index 000000000000..5b1918b818fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/twl6040-vibra.txt
@@ -0,0 +1,37 @@
+Vibra driver for the twl6040 family
+
+The vibra driver is a child of the twl6040 MFD dirver.
+Documentation/devicetree/bindings/mfd/twl6040.txt
+
+Required properties:
+- compatible : Must be "ti,twl6040-vibra";
+- interrupts: 4, Vibra overcurrent interrupt
+- vddvibl-supply: Regulator supplying the left vibra motor
+- vddvibr-supply: Regulator supplying the right vibra motor
+- vibldrv_res: Board specific left driver resistance
+- vibrdrv_res: Board specific right driver resistance
+- viblmotor_res: Board specific left motor resistance
+- vibrmotor_res: Board specific right motor resistance
+
+Optional properties:
+- vddvibl_uV: If the vddvibl default voltage need to be changed
+- vddvibr_uV: If the vddvibr default voltage need to be changed
+
+Example:
+/*
+ * 8-channel high quality low-power audio codec
+ * http://www.ti.com/lit/ds/symlink/twl6040.pdf
+ */
+twl6040: twl6040@4b {
+        ...
+        twl6040_vibra: twl6040@1 {
+                compatible = "ti,twl6040-vibra";
+                interrupts = <4>;
+                vddvibl-supply = <&vbat>;
+                vddvibr-supply = <&vbat>;
+                vibldrv_res = <8>;
+                vibrdrv_res = <3>;
+                viblmotor_res = <10>;
+                vibrmotor_res = <10>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt
new file mode 100644
index 000000000000..099d9362ebc1
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt
@@ -0,0 +1,14 @@
+NVIDIA Tegra 20 GART
+
+Required properties:
+- compatible: "nvidia,tegra20-gart"
+- reg: Two pairs of cells specifying the physical address and size of
+  the memory controller registers and the GART aperture respectively.
+
+Example:
+
+        gart {
+                compatible = "nvidia,tegra20-gart";
+                reg = <0x7000f024 0x00000018    /* controller registers */
+                       0x58000000 0x02000000>;  /* GART aperture */
+        };
diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
new file mode 100644
index 000000000000..1857f4a6b9a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
@@ -0,0 +1,60 @@
+* Dialog DA9052/53 Power Management Integrated Circuit (PMIC)
+
+Required properties:
+- compatible : Should be "dlg,da9052", "dlg,da9053-aa",
+                         "dlg,da9053-ab", or "dlg,da9053-bb"
+
+Sub-nodes:
+- regulators : Contain the regulator nodes. The DA9052/53 regulators are
+  bound using their names as listed below:
+
+    buck0     : regulator BUCK0
+    buck1     : regulator BUCK1
+    buck2     : regulator BUCK2
+    buck3     : regulator BUCK3
+    ldo4      : regulator LDO4
+    ldo5      : regulator LDO5
+    ldo6      : regulator LDO6
+    ldo7      : regulator LDO7
+    ldo8      : regulator LDO8
+    ldo9      : regulator LDO9
+    ldo10     : regulator LDO10
+    ldo11     : regulator LDO11
+    ldo12     : regulator LDO12
+    ldo13     : regulator LDO13
+
+  The bindings details of individual regulator device can be found in:
+  Documentation/devicetree/bindings/regulator/regulator.txt
+
+Examples:
+
+i2c@63fc8000 { /* I2C1 */
+        status = "okay";
+
+        pmic: dialog@48 {
+                compatible = "dlg,da9053-aa";
+                reg = <0x48>;
+
+                regulators {
+                        buck0 {
+                                regulator-min-microvolt = <500000>;
+                                regulator-max-microvolt = <2075000>;
+                        };
+
+                        buck1 {
+                                regulator-min-microvolt = <500000>;
+                                regulator-max-microvolt = <2075000>;
+                        };
+
+                        buck2 {
+                                regulator-min-microvolt = <925000>;
+                                regulator-max-microvolt = <2500000>;
+                        };
+
+                        buck3 {
+                                regulator-min-microvolt = <925000>;
+                                regulator-max-microvolt = <2500000>;
+                        };
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
index 19f6af47a792..baf07987ae68 100644
--- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt
+++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
@@ -46,8 +46,8 @@ Examples:
 
 ecspi@70010000 { /* ECSPI1 */
         fsl,spi-num-chipselects = <2>;
-        cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
-                   <&gpio3 25 0>; /* GPIO4_25 */
+        cs-gpios = <&gpio4 24 0>, /* GPIO4_24 */
+                   <&gpio4 25 0>; /* GPIO4_25 */
         status = "okay";
 
         pmic: mc13892@0 {
diff --git a/Documentation/devicetree/bindings/mfd/tps65910.txt b/Documentation/devicetree/bindings/mfd/tps65910.txt
new file mode 100644
index 000000000000..645f5eaadb3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65910.txt
@@ -0,0 +1,133 @@
+TPS65910 Power Management Integrated Circuit
+
+Required properties:
+- compatible: "ti,tps65910" or "ti,tps65911"
+- reg: I2C slave address
+- interrupts: the interrupt outputs of the controller
+- #gpio-cells: number of cells to describe a GPIO, this should be 2.
+  The first cell is the GPIO number.
+  The second cell is used to specify additional options <unused>.
+- gpio-controller: mark the device as a GPIO 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
+- regulators: This is the list of child nodes that specify the regulator
+  initialization data for defined regulators. Not all regulators for the given
+  device need to be present. The definition for each of these nodes is defined
+  using the standard binding for regulators found at
+  Documentation/devicetree/bindings/regulator/regulator.txt.
+
+  The valid names for regulators are:
+  tps65910: vrtc, vio, vdd1, vdd2, vdd3, vdig1, vdig2, vpll, vdac, vaux1,
+            vaux2, vaux33, vmmc
+  tps65911: vrtc, vio, vdd1, vdd3, vddctrl, ldo1, ldo2, ldo3, ldo4, ldo5,
+            ldo6, ldo7, ldo8
+
+Optional properties:
+- ti,vmbch-threshold: (tps65911) main battery charged threshold
+  comparator. (see VMBCH_VSEL in TPS65910 datasheet)
+- ti,vmbch2-threshold: (tps65911) main battery discharged threshold
+  comparator. (see VMBCH_VSEL in TPS65910 datasheet)
+- ti,en-gpio-sleep: enable sleep control for gpios
+  There should be 9 entries here, one for each gpio.
+
+Regulator Optional properties:
+- ti,regulator-ext-sleep-control: enable external sleep
+  control through external inputs [0 (not enabled), 1 (EN1), 2 (EN2) or 4(EN3)]
+  If this property is not defined, it defaults to 0 (not enabled).
+
+Example:
+
+        pmu: tps65910@d2 {
+                compatible = "ti,tps65910";
+                reg = <0xd2>;
+                interrupt-parent = <&intc>;
+                interrupts = < 0 118 0x04 >;
+
+                #gpio-cells = <2>;
+                gpio-controller;
+
+                #interrupt-cells = <2>;
+                interrupt-controller;
+
+                ti,vmbch-threshold = 0;
+                ti,vmbch2-threshold = 0;
+
+                ti,en-gpio-sleep = <0 0 1 0 0 0 0 0 0>;
+
+                regulators {
+                        vdd1_reg: vdd1 {
+                                regulator-min-microvolt = < 600000>;
+                                regulator-max-microvolt = <1500000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                                ti,regulator-ext-sleep-control = <0>;
+                        };
+                        vdd2_reg: vdd2 {
+                                regulator-min-microvolt = < 600000>;
+                                regulator-max-microvolt = <1500000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                                ti,regulator-ext-sleep-control = <4>;
+                        };
+                        vddctrl_reg: vddctrl {
+                                regulator-min-microvolt = < 600000>;
+                                regulator-max-microvolt = <1400000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                                ti,regulator-ext-sleep-control = <0>;
+                        };
+                        vio_reg: vio {
+                                regulator-min-microvolt = <1500000>;
+                                regulator-max-microvolt = <1800000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                                ti,regulator-ext-sleep-control = <1>;
+                        };
+                        ldo1_reg: ldo1 {
+                                regulator-min-microvolt = <1000000>;
+                                regulator-max-microvolt = <3300000>;
+                                ti,regulator-ext-sleep-control = <0>;
+                        };
+                        ldo2_reg: ldo2 {
+                                regulator-min-microvolt = <1050000>;
+                                regulator-max-microvolt = <1050000>;
+                                ti,regulator-ext-sleep-control = <0>;
+                        };
+                        ldo3_reg: ldo3 {
+                                regulator-min-microvolt = <1000000>;
+                                regulator-max-microvolt = <3300000>;
+                                ti,regulator-ext-sleep-control = <0>;
+                        };
+                        ldo4_reg: ldo4 {
+                                regulator-min-microvolt = <1000000>;
+                                regulator-max-microvolt = <3300000>;
+                                regulator-always-on;
+                                ti,regulator-ext-sleep-control = <0>;
+                        };
+                        ldo5_reg: ldo5 {
+                                regulator-min-microvolt = <1000000>;
+                                regulator-max-microvolt = <3300000>;
+                                ti,regulator-ext-sleep-control = <0>;
+                        };
+                        ldo6_reg: ldo6 {
+                                regulator-min-microvolt = <1200000>;
+                                regulator-max-microvolt = <1200000>;
+                                ti,regulator-ext-sleep-control = <0>;
+                        };
+                        ldo7_reg: ldo7 {
+                                regulator-min-microvolt = <1200000>;
+                                regulator-max-microvolt = <1200000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                                ti,regulator-ext-sleep-control = <1>;
+                        };
+                        ldo8_reg: ldo8 {
+                                regulator-min-microvolt = <1000000>;
+                                regulator-max-microvolt = <3300000>;
+                                regulator-always-on;
+                                ti,regulator-ext-sleep-control = <1>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt
new file mode 100644
index 000000000000..bc67c6f424aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl6040.txt
@@ -0,0 +1,62 @@
+Texas Instruments TWL6040 family
+
+The TWL6040s are 8-channel high quality low-power audio codecs providing audio
+and vibra functionality on OMAP4+ platforms.
+They are connected ot the host processor via i2c for commands, McPDM for audio
+data and commands.
+
+Required properties:
+- compatible : Must be "ti,twl6040";
+- reg: must be 0x4b for i2c address
+- interrupts: twl6040 has one interrupt line connecteded to the main SoC
+- interrupt-parent: The parent interrupt controller
+- twl6040,audpwron-gpio: Power on GPIO line for the twl6040
+
+- vio-supply: Regulator for the twl6040 VIO supply
+- v2v1-supply: Regulator for the twl6040 V2V1 supply
+
+Optional properties, nodes:
+- enable-active-high: To power on the twl6040 during boot.
+
+Vibra functionality
+Required properties:
+- vddvibl-supply: Regulator for the left vibra motor
+- vddvibr-supply: Regulator for the right vibra motor
+- vibra { }: Configuration section for vibra parameters containing the following
+             properties:
+- ti,vibldrv-res: Resistance parameter for left driver
+- ti,vibrdrv-res: Resistance parameter for right driver
+- ti,viblmotor-res: Resistance parameter for left motor
+- ti,viblmotor-res: Resistance parameter for right motor
+
+Optional properties within vibra { } section:
+- vddvibl_uV: If the vddvibl default voltage need to be changed
+- vddvibr_uV: If the vddvibr default voltage need to be changed
+
+Example:
+&i2c1 {
+        twl6040: twl@4b {
+                compatible = "ti,twl6040";
+                reg = <0x4b>;
+
+                interrupts = <0 119 4>;
+                interrupt-parent = <&gic>;
+                twl6040,audpwron-gpio = <&gpio4 31 0>;
+
+                vio-supply = <&v1v8>;
+                v2v1-supply = <&v2v1>;
+                enable-active-high;
+
+                /* regulators for vibra motor */
+                vddvibl-supply = <&vbat>;
+                vddvibr-supply = <&vbat>;
+
+                vibra {
+                        /* Vibra driver, motor resistance parameters */
+                        ti,vibldrv-res = <8>;
+                        ti,vibrdrv-res = <3>;
+                        ti,viblmotor-res = <10>;
+                        ti,vibrmotor-res = <10>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/misc/bmp085.txt b/Documentation/devicetree/bindings/misc/bmp085.txt
new file mode 100644
index 000000000000..91dfda2e4e11
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/bmp085.txt
@@ -0,0 +1,20 @@
+BMP085/BMP18x digital pressure sensors
+
+Required properties:
+- compatible: bosch,bmp085
+
+Optional properties:
+- chip-id: configurable chip id for non-default chip revisions
+- temp-measurement-period: temperature measurement period (milliseconds)
+- default-oversampling: default oversampling value to be used at startup,
+  value range is 0-3 with rising sensitivity.
+
+Example:
+
+pressure@77 {
+        compatible = "bosch,bmp085";
+        reg = <0x77>;
+        chip-id = <10>;
+        temp-measurement-period = <100>;
+        default-oversampling = <2>;
+};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
index 64bcb8be973c..0d93b4b0e0e3 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
+++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
@@ -11,9 +11,11 @@ Required properties:
   - interrupt-parent : interrupt source phandle.
   - clock-frequency : specifies eSDHC base clock frequency.
   - sdhci,wp-inverted : (optional) specifies that eSDHC controller
-    reports inverted write-protect state;
+    reports inverted write-protect state; New devices should use
+    the generic "wp-inverted" property.
   - sdhci,1-bit-only : (optional) specifies that a controller can
-    only handle 1-bit data transfers.
+    only handle 1-bit data transfers. New devices should use the
+    generic "bus-width = <1>" property.
   - sdhci,auto-cmd12: (optional) specifies that a controller can
     only handle auto CMD12.
 
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
index ab22fe6e73ab..fea541ee8b34 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
@@ -9,7 +9,7 @@ Required properties:
 - interrupts : Should contain eSDHC interrupt
 
 Optional properties:
-- fsl,card-wired : Indicate the card is wired to host permanently
+- non-removable : Indicate the card is wired to host permanently
 - fsl,cd-internal : Indicate to use controller internal card detection
 - fsl,wp-internal : Indicate to use controller internal write protection
 - cd-gpios : Specify GPIOs for card detection
@@ -29,6 +29,6 @@ esdhc@70008000 {
         compatible = "fsl,imx51-esdhc";
         reg = <0x70008000 0x4000>;
         interrupts = <2>;
-        cd-gpios = <&gpio0 6 0>; /* GPIO1_6 */
-        wp-gpios = <&gpio0 5 0>; /* GPIO1_5 */
+        cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */
+        wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */
 };
diff --git a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt
index 89a0084df2f7..d64aea5a4203 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt
@@ -10,7 +10,8 @@ Required properties:
 
 Optional properties:
 - gpios : may specify GPIOs in this order: Card-Detect GPIO,
-  Write-Protect GPIO.
+  Write-Protect GPIO. Note that this does not follow the
+  binding from mmc.txt, for historic reasons.
 - interrupts : the interrupt of a card detect interrupt.
 - interrupt-parent : the phandle for the interrupt controller that
   services interrupts for this device.
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
new file mode 100644
index 000000000000..6e70dcde0a71
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -0,0 +1,27 @@
+These properties are common to multiple MMC host controllers. Any host
+that requires the respective functionality should implement them using
+these definitions.
+
+Required properties:
+- bus-width: Number of data lines, can be <1>, <4>, or <8>
+
+Optional properties:
+- cd-gpios : Specify GPIOs for card detection, see gpio binding
+- wp-gpios : Specify GPIOs for write protection, see gpio binding
+- cd-inverted: when present, polarity on the wp gpio line is inverted
+- wp-inverted: when present, polarity on the wp gpio line is inverted
+- non-removable: non-removable slot (like eMMC)
+- max-frequency: maximum operating clock frequency
+
+Example:
+
+sdhci@ab000000 {
+        compatible = "sdhci";
+        reg = <0xab000000 0x200>;
+        interrupts = <23>;
+        bus-width = <4>;
+        cd-gpios = <&gpio 69 0>;
+        cd-inverted;
+        wp-gpios = <&gpio 70 0>;
+        max-frequency = <50000000>;
+}
diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
new file mode 100644
index 000000000000..14a81d526118
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmci.txt
@@ -0,0 +1,19 @@
+* ARM PrimeCell MultiMedia Card Interface (MMCI) PL180/1
+
+The ARM PrimeCell MMCI PL180 and PL181 provides and interface for
+reading and writing to MultiMedia and SD cards alike.
+
+Required properties:
+- compatible             : contains "arm,pl18x", "arm,primecell".
+- reg                    : contains pl18x registers and length.
+- interrupts             : contains the device IRQ(s).
+- arm,primecell-periphid : contains the PrimeCell Peripheral ID.
+
+Optional properties:
+- wp-gpios               : contains any write protect (ro) gpios
+- cd-gpios               : contains any card detection gpios
+- cd-inverted            : indicates whether the cd gpio is inverted
+- max-frequency          : contains the maximum operating frequency
+- bus-width              : number of data lines, can be <1>, <4>, or <8>
+- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
+- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
new file mode 100644
index 000000000000..14d870a9e3db
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt
@@ -0,0 +1,25 @@
+* Freescale MXS MMC controller
+
+The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller
+to support MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible: Should be "fsl,<chip>-mmc".  The supported chips include
+  imx23 and imx28.
+- reg: Should contain registers location and length
+- interrupts: Should contain ERROR and DMA interrupts
+- fsl,ssp-dma-channel: APBH DMA channel for the SSP
+- bus-width: Number of data lines, can be <1>, <4>, or <8>
+
+Optional properties:
+- wp-gpios: Specify GPIOs for write protection
+
+Examples:
+
+ssp0: ssp@80010000 {
+        compatible = "fsl,imx28-mmc";
+        reg = <0x80010000 2000>;
+        interrupts = <96 82>;
+        fsl,ssp-dma-channel = <0>;
+        bus-width = <8>;
+};
diff --git a/Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt b/Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt
index 7e51154679a6..f77c3031607f 100644
--- a/Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt
@@ -7,12 +7,12 @@ Required properties:
 - compatible : Should be "nvidia,<chip>-sdhci"
 - reg : Should contain SD/MMC registers location and length
 - interrupts : Should contain SD/MMC interrupt
+- bus-width : Number of data lines, can be <1>, <4>, or <8>
 
 Optional properties:
 - cd-gpios : Specify GPIOs for card detection
 - wp-gpios : Specify GPIOs for write protection
 - power-gpios : Specify GPIOs for power control
-- support-8bit : Boolean, indicates if 8-bit mode should be used.
 
 Example:
 
@@ -23,5 +23,5 @@ sdhci@c8000200 {
         cd-gpios = <&gpio 69 0>; /* gpio PI5 */
         wp-gpios = <&gpio 57 0>; /* gpio PH1 */
         power-gpios = <&gpio 155 0>; /* gpio PT3 */
-        support-8bit;
+        bus-width = <8>;
 };
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index dbd4368ab8cc..8a53958c9a9f 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -15,7 +15,7 @@ Optional properties:
 ti,dual-volt: boolean, supports dual voltage cards
 <supply-name>-supply: phandle to the regulator device tree node
 "supply-name" examples are "vmmc", "vmmc_aux" etc
-ti,bus-width: Number of data lines, default assumed is 1 if the property is missing.
+bus-width: Number of data lines, default assumed is 1 if the property is missing.
 cd-gpios: GPIOs for card detection
 wp-gpios: GPIOs for write protection
 ti,non-removable: non-removable slot (like eMMC)
@@ -27,7 +27,7 @@ Example:
                 reg = <0x4809c000 0x400>;
                 ti,hwmods = "mmc1";
                 ti,dual-volt;
-                ti,bus-width = <4>;
+                bus-width = <4>;
                 vmmc-supply = <&vmmc>; /* phandle to regulator node */
                 ti,non-removable;
         };
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
new file mode 100644
index 000000000000..1a5bbd346d22
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
@@ -0,0 +1,33 @@
+* Freescale General-Purpose Media Interface (GPMI)
+
+The GPMI nand controller provides an interface to control the
+NAND flash chips. We support only one NAND chip now.
+
+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.
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Examples:
+
+gpmi-nand@8000c000 {
+        compatible = "fsl,imx28-gpmi-nand";
+        #address-cells = <1>;
+        #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>;
+
+        partition@0 {
+        ...
+        };
+};
diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.txt b/Documentation/devicetree/bindings/mtd/mxc-nand.txt
new file mode 100644
index 000000000000..b5833d11c7be
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mxc-nand.txt
@@ -0,0 +1,19 @@
+* Freescale's mxc_nand
+
+Required properties:
+- compatible: "fsl,imxXX-nand"
+- reg: address range of the nfc block
+- interrupts: irq to be used
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+- nand-on-flash-bbt: see nand.txt
+
+Example:
+
+        nand@d8000000 {
+                compatible = "fsl,imx27-nand";
+                reg = <0xd8000000 0x1000>;
+                interrupts = <29>;
+                nand-bus-width = <8>;
+                nand-ecc-mode = "hw";
+        };
diff --git a/Documentation/devicetree/bindings/mtd/orion-nand.txt b/Documentation/devicetree/bindings/mtd/orion-nand.txt
new file mode 100644
index 000000000000..b2356b7d2fa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/orion-nand.txt
@@ -0,0 +1,50 @@
+NAND support for Marvell Orion SoC platforms
+
+Required properties:
+- compatible : "mrvl,orion-nand".
+- reg : Base physical address of the NAND and length of memory mapped
+        region
+
+Optional properties:
+- cle : Address line number connected to CLE. Default is 0
+- ale : Address line number connected to ALE. Default is 1
+- bank-width : Width in bytes of the device. Default is 1
+- chip-delay : Chip dependent delay for transferring data from array to read
+               registers in usecs
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+nand@f4000000 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        cle = <0>;
+        ale = <1>;
+        bank-width = <1>;
+        chip-delay = <25>;
+        compatible = "mrvl,orion-nand";
+        reg = <0xf4000000 0x400>;
+
+        partition@0 {
+                label = "u-boot";
+                reg = <0x0000000 0x100000>;
+                read-only;
+        };
+
+        partition@100000 {
+                label = "uImage";
+                reg = <0x0100000 0x200000>;
+        };
+
+        partition@300000 {
+                label = "dtb";
+                reg = <0x0300000 0x100000>;
+        };
+
+        partition@400000 {
+                label = "root";
+                reg = <0x0400000 0x7d00000>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 1ad80d5865a9..f31b686d4556 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -1,4 +1,4 @@
-Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
+Flexcan CAN controller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
 
 Required properties:
 
diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt
index de439517dff0..4616fc28ee86 100644
--- a/Documentation/devicetree/bindings/net/fsl-fec.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
@@ -14,11 +14,11 @@ Optional properties:
 
 Example:
 
-fec@83fec000 {
+ethernet@83fec000 {
         compatible = "fsl,imx51-fec", "fsl,imx27-fec";
         reg = <0x83fec000 0x4000>;
         interrupts = <87>;
         phy-mode = "mii";
-        phy-reset-gpios = <&gpio1 14 0>; /* GPIO2_14 */
+        phy-reset-gpios = <&gpio2 14 0>; /* GPIO2_14 */
         local-mac-address = [00 04 9F 01 1B B9];
 };
diff --git a/Documentation/devicetree/bindings/net/lpc-eth.txt b/Documentation/devicetree/bindings/net/lpc-eth.txt
new file mode 100644
index 000000000000..585021acd178
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/lpc-eth.txt
@@ -0,0 +1,24 @@
+* NXP LPC32xx SoC Ethernet Controller
+
+Required properties:
+- compatible: Should be "nxp,lpc-eth"
+- reg: Address and length of the register set for the device
+- interrupts: Should contain ethernet controller interrupt
+
+Optional properties:
+- phy-mode: String, operation mode of the PHY interface.
+  Supported values are: "mii", "rmii" (default)
+- use-iram: Use LPC32xx internal SRAM (IRAM) for DMA buffering
+- local-mac-address : 6 bytes, mac address
+
+Example:
+
+        mac: ethernet@31060000 {
+                compatible = "nxp,lpc-eth";
+                reg = <0x31060000 0x1000>;
+                interrupt-parent = <&mic>;
+                interrupts = <29 0>;
+
+                phy-mode = "rmii";
+                use-iram;
+        };
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt
new file mode 100644
index 000000000000..79384113c2b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt
@@ -0,0 +1,127 @@
+Properties for an MDIO bus multiplexer/switch controlled by GPIO pins.
+
+This is a special case of a MDIO bus multiplexer.  One or more GPIO
+lines are used to control which child bus is connected.
+
+Required properties in addition to the generic multiplexer properties:
+
+- compatible : mdio-mux-gpio.
+- gpios : GPIO specifiers for each GPIO line.  One or more must be specified.
+
+
+Example :
+
+        /* The parent MDIO bus. */
+        smi1: mdio@1180000001900 {
+                compatible = "cavium,octeon-3860-mdio";
+                #address-cells = <1>;
+                #size-cells = <0>;
+                reg = <0x11800 0x00001900 0x0 0x40>;
+        };
+
+        /*
+           An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
+           pair of GPIO lines.  Child busses 2 and 3 populated with 4
+           PHYs each.
+         */
+        mdio-mux {
+                compatible = "mdio-mux-gpio";
+                gpios = <&gpio1 3 0>, <&gpio1 4 0>;
+                mdio-parent-bus = <&smi1>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                mdio@2 {
+                        reg = <2>;
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        phy11: ethernet-phy@1 {
+                                reg = <1>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <10 8>; /* Pin 10, active low */
+                        };
+                        phy12: ethernet-phy@2 {
+                                reg = <2>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <10 8>; /* Pin 10, active low */
+                        };
+                        phy13: ethernet-phy@3 {
+                                reg = <3>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <10 8>; /* Pin 10, active low */
+                        };
+                        phy14: ethernet-phy@4 {
+                                reg = <4>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <10 8>; /* Pin 10, active low */
+                        };
+                };
+
+                mdio@3 {
+                        reg = <3>;
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        phy21: ethernet-phy@1 {
+                                reg = <1>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <12 8>; /* Pin 12, active low */
+                        };
+                        phy22: ethernet-phy@2 {
+                                reg = <2>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <12 8>; /* Pin 12, active low */
+                        };
+                        phy23: ethernet-phy@3 {
+                                reg = <3>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <12 8>; /* Pin 12, active low */
+                        };
+                        phy24: ethernet-phy@4 {
+                                reg = <4>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <12 8>; /* Pin 12, active low */
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt
new file mode 100644
index 000000000000..f65606f8d632
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mdio-mux.txt
@@ -0,0 +1,136 @@
+Common MDIO bus multiplexer/switch properties.
+
+An MDIO bus multiplexer/switch will have several child busses that are
+numbered uniquely in a device dependent manner.  The nodes for an MDIO
+bus multiplexer/switch will have one child node for each child bus.
+
+Required properties:
+- mdio-parent-bus : phandle to the parent MDIO bus.
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties:
+- Other properties specific to the multiplexer/switch hardware.
+
+Required properties for child nodes:
+- #address-cells = <1>;
+- #size-cells = <0>;
+- reg : The sub-bus number.
+
+
+Example :
+
+        /* The parent MDIO bus. */
+        smi1: mdio@1180000001900 {
+                compatible = "cavium,octeon-3860-mdio";
+                #address-cells = <1>;
+                #size-cells = <0>;
+                reg = <0x11800 0x00001900 0x0 0x40>;
+        };
+
+        /*
+           An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
+           pair of GPIO lines.  Child busses 2 and 3 populated with 4
+           PHYs each.
+         */
+        mdio-mux {
+                compatible = "mdio-mux-gpio";
+                gpios = <&gpio1 3 0>, <&gpio1 4 0>;
+                mdio-parent-bus = <&smi1>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                mdio@2 {
+                        reg = <2>;
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        phy11: ethernet-phy@1 {
+                                reg = <1>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <10 8>; /* Pin 10, active low */
+                        };
+                        phy12: ethernet-phy@2 {
+                                reg = <2>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <10 8>; /* Pin 10, active low */
+                        };
+                        phy13: ethernet-phy@3 {
+                                reg = <3>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <10 8>; /* Pin 10, active low */
+                        };
+                        phy14: ethernet-phy@4 {
+                                reg = <4>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <10 8>; /* Pin 10, active low */
+                        };
+                };
+
+                mdio@3 {
+                        reg = <3>;
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        phy21: ethernet-phy@1 {
+                                reg = <1>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <12 8>; /* Pin 12, active low */
+                        };
+                        phy22: ethernet-phy@2 {
+                                reg = <2>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <12 8>; /* Pin 12, active low */
+                        };
+                        phy23: ethernet-phy@3 {
+                                reg = <3>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <12 8>; /* Pin 12, active low */
+                        };
+                        phy24: ethernet-phy@4 {
+                                reg = <4>;
+                                compatible = "marvell,88e1149r";
+                                marvell,reg-init = <3 0x10 0 0x5777>,
+                                        <3 0x11 0 0x00aa>,
+                                        <3 0x12 0 0x4105>,
+                                        <3 0x13 0 0x0a60>;
+                                interrupt-parent = <&gpio>;
+                                interrupts = <12 8>; /* Pin 12, active low */
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
new file mode 100644
index 000000000000..ab19e6bc7d3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
@@ -0,0 +1,95 @@
+* Freescale IOMUX Controller (IOMUXC) for i.MX
+
+The IOMUX Controller (IOMUXC), together with the IOMUX, 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 ALT modes). Since different modules require
+different PAD settings (like pull up, keeper, etc) the IOMUXC controls
+also the PAD settings parameters.
+
+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".
+
+Freescale IMX pin configuration node is a node of a group of pins which can be
+used for a specific device or function. This node represents both mux and config
+of the pins in that group. The 'mux' selects the function mode(also named mux
+mode) this pin can work on and the 'config' configures various pad settings
+such as pull-up, open drain, drive strength, etc.
+
+Required properties for iomux controller:
+- compatible: "fsl,<soc>-iomuxc"
+  Please refer to each fsl,<soc>-pinctrl.txt binding doc for supported SoCs.
+
+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.
+
+Bits used for CONFIG:
+NO_PAD_CTL(1 << 31): indicate this pin does not need config.
+
+SION(1 << 30): Software Input On Field.
+Force the selected mux mode input path no matter of MUX_MODE functionality.
+By default the input path is determined by functionality of the selected
+mux mode (regular).
+
+Other bits are used for PAD setting.
+Please refer to each fsl,<soc>-pinctrl,txt binding doc for SoC specific part
+of bits definitions.
+
+NOTE:
+Some requirements for using fsl,imx-pinctrl binding:
+1. We have pin function node defined under iomux controller node to represent
+   what pinmux functions this SoC supports.
+2. The pin configuration node intends to work on a specific function should
+   to be defined under that specific function node.
+   The function node's name should represent well about what function
+   this group of pins in this pin configuration node are working on.
+3. The driver can use the function node's name and pin configuration node's
+   name describe the pin function and group hierarchy.
+   For example, Linux IMX pinctrl driver takes the function node's name
+   as the function name and pin configuration node's name as group name to
+   create the map table.
+4. Each pin configuration node should have a phandle, devices can set pins
+   configurations by referring to the phandle of that pin configuration node.
+
+Examples:
+usdhc@0219c000 { /* uSDHC4 */
+        fsl,card-wired;
+        vmmc-supply = <&reg_3p3v>;
+        status = "okay";
+        pinctrl-names = "default";
+        pinctrl-0 = <&pinctrl_usdhc4_1>;
+};
+
+iomuxc@020e0000 {
+        compatible = "fsl,imx6q-iomuxc";
+        reg = <0x020e0000 0x4000>;
+
+        /* shared pinctrl settings */
+        usdhc4 {
+                pinctrl_usdhc4_1: usdhc4grp-1 {
+                        fsl,pins = <1386 0x17059        /* MX6Q_PAD_SD4_CMD__USDHC4_CMD */
+                                    1392 0x10059        /* MX6Q_PAD_SD4_CLK__USDHC4_CLK */
+                                    1462 0x17059        /* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */
+                                    1470 0x17059        /* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */
+                                    1478 0x17059        /* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */
+                                    1486 0x17059        /* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */
+                                    1493 0x17059        /* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */
+                                    1501 0x17059        /* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */
+                                    1509 0x17059        /* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */
+                                    1517 0x17059>;      /* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */
+                };
+        };
+        ....
+};
+Refer to the IOMUXC controller chapter in imx6q datasheet,
+0x17059 means enable hysteresis, 47KOhm Pull Up, 50Mhz speed,
+80Ohm driver strength and Fast Slew Rate.
+User should refer to each SoC spec to set the correct value.
+
+TODO: when dtc macro support is available, we can change above raw data
+to dt macro which can get better readability in dts file.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
new file mode 100644
index 000000000000..b96fa4c31745
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
@@ -0,0 +1,787 @@
+* Freescale IMX51 IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx51-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 imx51 datasheet for the valid pad
+  config settings.
+
+CONFIG bits definition:
+PAD_CTL_HVE                     (1 << 13)
+PAD_CTL_HYS                     (1 << 8)
+PAD_CTL_PKE                     (1 << 7)
+PAD_CTL_PUE                     (1 << 6)
+PAD_CTL_PUS_100K_DOWN           (0 << 4)
+PAD_CTL_PUS_47K_UP              (1 << 4)
+PAD_CTL_PUS_100K_UP             (2 << 4)
+PAD_CTL_PUS_22K_UP              (3 << 4)
+PAD_CTL_ODE                     (1 << 3)
+PAD_CTL_DSE_LOW                 (0 << 1)
+PAD_CTL_DSE_MED                 (1 << 1)
+PAD_CTL_DSE_HIGH                (2 << 1)
+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
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
new file mode 100644
index 000000000000..ca85ca432ef0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
@@ -0,0 +1,1202 @@
+* Freescale IMX53 IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx53-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 imx53 datasheet for the valid pad
+  config settings.
+
+CONFIG bits definition:
+PAD_CTL_HVE                     (1 << 13)
+PAD_CTL_HYS                     (1 << 8)
+PAD_CTL_PKE                     (1 << 7)
+PAD_CTL_PUE                     (1 << 6)
+PAD_CTL_PUS_100K_DOWN           (0 << 4)
+PAD_CTL_PUS_47K_UP              (1 << 4)
+PAD_CTL_PUS_100K_UP             (2 << 4)
+PAD_CTL_PUS_22K_UP              (3 << 4)
+PAD_CTL_ODE                     (1 << 3)
+PAD_CTL_DSE_LOW                 (0 << 1)
+PAD_CTL_DSE_MED                 (1 << 1)
+PAD_CTL_DSE_HIGH                (2 << 1)
+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
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
new file mode 100644
index 000000000000..a4119f6422d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
@@ -0,0 +1,1630 @@
+* Freescale IMX6Q IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx6q-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 imx6q 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)
+
+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
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
new file mode 100644
index 000000000000..f7e8e8f4d9a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
@@ -0,0 +1,918 @@
+* Freescale MXS Pin Controller
+
+The pins controlled by mxs pin controller are organized in banks, each bank
+has 32 pins.  Each pin has 4 multiplexing functions, and generally, the 4th
+function is GPIO.  The configuration on the pins includes drive strength,
+voltage and pull-up.
+
+Required properties:
+- compatible: "fsl,imx23-pinctrl" or "fsl,imx28-pinctrl"
+- reg: Should contain the register physical address and length for the
+  pin controller.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+The node of mxs pin controller acts as a container for an arbitrary number of
+subnodes.  Each of these subnodes represents some desired configuration for
+a group of pins, and only affects those parameters that are explicitly listed.
+In other words, a subnode that describes a drive strength parameter implies no
+information about pull-up. For this reason, even seemingly boolean values are
+actually tristates in this binding: unspecified, off, or on. Unspecified is
+represented as an absent property, and off/on are represented as integer
+values 0 and 1.
+
+Those subnodes under mxs pin controller node will fall into two categories.
+One is to set up a group of pins for a function, both mux selection and pin
+configurations, and it's called group node in the binding document.   The other
+one is to adjust the pin configuration for some particular pins that need a
+different configuration than what is defined in group node.  The binding
+document calls this type of node config node.
+
+On mxs, there is no hardware pin group. The pin group in this binding only
+means a group of pins put together for particular peripheral to work in
+particular function, like SSP0 functioning as mmc0-8bit.  That said, the
+group node should include all the pins needed for one function rather than
+having these pins defined in several group nodes.  It also means each of
+"pinctrl-*" phandle in client device node should only have one group node
+pointed in there, while the phandle can have multiple config node referenced
+there to adjust configurations for some pins in the group.
+
+Required subnode-properties:
+- fsl,pinmux-ids: An integer array.  Each integer in the array specify a pin
+  with given mux function, with bank, pin and mux packed as below.
+
+    [15..12] : bank number
+    [11..4]  : pin number
+    [3..0]   : mux selection
+
+  This integer with mux selection packed is used as an entity by both group
+  and config nodes to identify a pin.  The mux selection in the integer takes
+  effects only on group node, and will get ignored by driver with config node,
+  since config node is only meant to set up pin configurations.
+
+  Valid values for these integers are listed below.
+
+- reg: Should be the index of the group nodes for same function.  This property
+  is required only for group nodes, and should not be present in any config
+  nodes.
+
+Optional subnode-properties:
+- fsl,drive-strength: Integer.
+    0: 4 mA
+    1: 8 mA
+    2: 12 mA
+    3: 16 mA
+- fsl,voltage: Integer.
+    0: 1.8 V
+    1: 3.3 V
+- fsl,pull-up: Integer.
+    0: Disable the internal pull-up
+    1: Enable the internal pull-up
+
+Examples:
+
+pinctrl@80018000 {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        compatible = "fsl,imx28-pinctrl";
+        reg = <0x80018000 2000>;
+
+        mmc0_8bit_pins_a: mmc0-8bit@0 {
+                reg = <0>;
+                fsl,pinmux-ids = <
+                        0x2000 0x2010 0x2020 0x2030
+                        0x2040 0x2050 0x2060 0x2070
+                        0x2080 0x2090 0x20a0>;
+                fsl,drive-strength = <1>;
+                fsl,voltage = <1>;
+                fsl,pull-up = <1>;
+        };
+
+        mmc_cd_cfg: mmc-cd-cfg {
+                fsl,pinmux-ids = <0x2090>;
+                fsl,pull-up = <0>;
+        };
+
+        mmc_sck_cfg: mmc-sck-cfg {
+                fsl,pinmux-ids = <0x20a0>;
+                fsl,drive-strength = <2>;
+                fsl,pull-up = <0>;
+        };
+};
+
+In this example, group node mmc0-8bit defines a group of pins for mxs SSP0
+to function as a 8-bit mmc device, with 8mA, 3.3V and pull-up configurations
+applied on all these pins.  And config nodes mmc-cd-cfg and mmc-sck-cfg are
+adjusting the configuration for pins card-detection and clock from what group
+node mmc0-8bit defines.  Only the configuration properties to be adjusted need
+to be listed in the config nodes.
+
+Valid values for i.MX28 pinmux-id:
+
+pinmux                                          id
+------                                          --
+MX28_PAD_GPMI_D00__GPMI_D0                      0x0000
+MX28_PAD_GPMI_D01__GPMI_D1                      0x0010
+MX28_PAD_GPMI_D02__GPMI_D2                      0x0020
+MX28_PAD_GPMI_D03__GPMI_D3                      0x0030
+MX28_PAD_GPMI_D04__GPMI_D4                      0x0040
+MX28_PAD_GPMI_D05__GPMI_D5                      0x0050
+MX28_PAD_GPMI_D06__GPMI_D6                      0x0060
+MX28_PAD_GPMI_D07__GPMI_D7                      0x0070
+MX28_PAD_GPMI_CE0N__GPMI_CE0N                   0x0100
+MX28_PAD_GPMI_CE1N__GPMI_CE1N                   0x0110
+MX28_PAD_GPMI_CE2N__GPMI_CE2N                   0x0120
+MX28_PAD_GPMI_CE3N__GPMI_CE3N                   0x0130
+MX28_PAD_GPMI_RDY0__GPMI_READY0                 0x0140
+MX28_PAD_GPMI_RDY1__GPMI_READY1                 0x0150
+MX28_PAD_GPMI_RDY2__GPMI_READY2                 0x0160
+MX28_PAD_GPMI_RDY3__GPMI_READY3                 0x0170
+MX28_PAD_GPMI_RDN__GPMI_RDN                     0x0180
+MX28_PAD_GPMI_WRN__GPMI_WRN                     0x0190
+MX28_PAD_GPMI_ALE__GPMI_ALE                     0x01a0
+MX28_PAD_GPMI_CLE__GPMI_CLE                     0x01b0
+MX28_PAD_GPMI_RESETN__GPMI_RESETN               0x01c0
+MX28_PAD_LCD_D00__LCD_D0                        0x1000
+MX28_PAD_LCD_D01__LCD_D1                        0x1010
+MX28_PAD_LCD_D02__LCD_D2                        0x1020
+MX28_PAD_LCD_D03__LCD_D3                        0x1030
+MX28_PAD_LCD_D04__LCD_D4                        0x1040
+MX28_PAD_LCD_D05__LCD_D5                        0x1050
+MX28_PAD_LCD_D06__LCD_D6                        0x1060
+MX28_PAD_LCD_D07__LCD_D7                        0x1070
+MX28_PAD_LCD_D08__LCD_D8                        0x1080
+MX28_PAD_LCD_D09__LCD_D9                        0x1090
+MX28_PAD_LCD_D10__LCD_D10                       0x10a0
+MX28_PAD_LCD_D11__LCD_D11                       0x10b0
+MX28_PAD_LCD_D12__LCD_D12                       0x10c0
+MX28_PAD_LCD_D13__LCD_D13                       0x10d0
+MX28_PAD_LCD_D14__LCD_D14                       0x10e0
+MX28_PAD_LCD_D15__LCD_D15                       0x10f0
+MX28_PAD_LCD_D16__LCD_D16                       0x1100
+MX28_PAD_LCD_D17__LCD_D17                       0x1110
+MX28_PAD_LCD_D18__LCD_D18                       0x1120
+MX28_PAD_LCD_D19__LCD_D19                       0x1130
+MX28_PAD_LCD_D20__LCD_D20                       0x1140
+MX28_PAD_LCD_D21__LCD_D21                       0x1150
+MX28_PAD_LCD_D22__LCD_D22                       0x1160
+MX28_PAD_LCD_D23__LCD_D23                       0x1170
+MX28_PAD_LCD_RD_E__LCD_RD_E                     0x1180
+MX28_PAD_LCD_WR_RWN__LCD_WR_RWN                 0x1190
+MX28_PAD_LCD_RS__LCD_RS                         0x11a0
+MX28_PAD_LCD_CS__LCD_CS                         0x11b0
+MX28_PAD_LCD_VSYNC__LCD_VSYNC                   0x11c0
+MX28_PAD_LCD_HSYNC__LCD_HSYNC                   0x11d0
+MX28_PAD_LCD_DOTCLK__LCD_DOTCLK                 0x11e0
+MX28_PAD_LCD_ENABLE__LCD_ENABLE                 0x11f0
+MX28_PAD_SSP0_DATA0__SSP0_D0                    0x2000
+MX28_PAD_SSP0_DATA1__SSP0_D1                    0x2010
+MX28_PAD_SSP0_DATA2__SSP0_D2                    0x2020
+MX28_PAD_SSP0_DATA3__SSP0_D3                    0x2030
+MX28_PAD_SSP0_DATA4__SSP0_D4                    0x2040
+MX28_PAD_SSP0_DATA5__SSP0_D5                    0x2050
+MX28_PAD_SSP0_DATA6__SSP0_D6                    0x2060
+MX28_PAD_SSP0_DATA7__SSP0_D7                    0x2070
+MX28_PAD_SSP0_CMD__SSP0_CMD                     0x2080
+MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT          0x2090
+MX28_PAD_SSP0_SCK__SSP0_SCK                     0x20a0
+MX28_PAD_SSP1_SCK__SSP1_SCK                     0x20c0
+MX28_PAD_SSP1_CMD__SSP1_CMD                     0x20d0
+MX28_PAD_SSP1_DATA0__SSP1_D0                    0x20e0
+MX28_PAD_SSP1_DATA3__SSP1_D3                    0x20f0
+MX28_PAD_SSP2_SCK__SSP2_SCK                     0x2100
+MX28_PAD_SSP2_MOSI__SSP2_CMD                    0x2110
+MX28_PAD_SSP2_MISO__SSP2_D0                     0x2120
+MX28_PAD_SSP2_SS0__SSP2_D3                      0x2130
+MX28_PAD_SSP2_SS1__SSP2_D4                      0x2140
+MX28_PAD_SSP2_SS2__SSP2_D5                      0x2150
+MX28_PAD_SSP3_SCK__SSP3_SCK                     0x2180
+MX28_PAD_SSP3_MOSI__SSP3_CMD                    0x2190
+MX28_PAD_SSP3_MISO__SSP3_D0                     0x21a0
+MX28_PAD_SSP3_SS0__SSP3_D3                      0x21b0
+MX28_PAD_AUART0_RX__AUART0_RX                   0x3000
+MX28_PAD_AUART0_TX__AUART0_TX                   0x3010
+MX28_PAD_AUART0_CTS__AUART0_CTS                 0x3020
+MX28_PAD_AUART0_RTS__AUART0_RTS                 0x3030
+MX28_PAD_AUART1_RX__AUART1_RX                   0x3040
+MX28_PAD_AUART1_TX__AUART1_TX                   0x3050
+MX28_PAD_AUART1_CTS__AUART1_CTS                 0x3060
+MX28_PAD_AUART1_RTS__AUART1_RTS                 0x3070
+MX28_PAD_AUART2_RX__AUART2_RX                   0x3080
+MX28_PAD_AUART2_TX__AUART2_TX                   0x3090
+MX28_PAD_AUART2_CTS__AUART2_CTS                 0x30a0
+MX28_PAD_AUART2_RTS__AUART2_RTS                 0x30b0
+MX28_PAD_AUART3_RX__AUART3_RX                   0x30c0
+MX28_PAD_AUART3_TX__AUART3_TX                   0x30d0
+MX28_PAD_AUART3_CTS__AUART3_CTS                 0x30e0
+MX28_PAD_AUART3_RTS__AUART3_RTS                 0x30f0
+MX28_PAD_PWM0__PWM_0                            0x3100
+MX28_PAD_PWM1__PWM_1                            0x3110
+MX28_PAD_PWM2__PWM_2                            0x3120
+MX28_PAD_SAIF0_MCLK__SAIF0_MCLK                 0x3140
+MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK               0x3150
+MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK             0x3160
+MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0             0x3170
+MX28_PAD_I2C0_SCL__I2C0_SCL                     0x3180
+MX28_PAD_I2C0_SDA__I2C0_SDA                     0x3190
+MX28_PAD_SAIF1_SDATA0__SAIF1_SDATA0             0x31a0
+MX28_PAD_SPDIF__SPDIF_TX                        0x31b0
+MX28_PAD_PWM3__PWM_3                            0x31c0
+MX28_PAD_PWM4__PWM_4                            0x31d0
+MX28_PAD_LCD_RESET__LCD_RESET                   0x31e0
+MX28_PAD_ENET0_MDC__ENET0_MDC                   0x4000
+MX28_PAD_ENET0_MDIO__ENET0_MDIO                 0x4010
+MX28_PAD_ENET0_RX_EN__ENET0_RX_EN               0x4020
+MX28_PAD_ENET0_RXD0__ENET0_RXD0                 0x4030
+MX28_PAD_ENET0_RXD1__ENET0_RXD1                 0x4040
+MX28_PAD_ENET0_TX_CLK__ENET0_TX_CLK             0x4050
+MX28_PAD_ENET0_TX_EN__ENET0_TX_EN               0x4060
+MX28_PAD_ENET0_TXD0__ENET0_TXD0                 0x4070
+MX28_PAD_ENET0_TXD1__ENET0_TXD1                 0x4080
+MX28_PAD_ENET0_RXD2__ENET0_RXD2                 0x4090
+MX28_PAD_ENET0_RXD3__ENET0_RXD3                 0x40a0
+MX28_PAD_ENET0_TXD2__ENET0_TXD2                 0x40b0
+MX28_PAD_ENET0_TXD3__ENET0_TXD3                 0x40c0
+MX28_PAD_ENET0_RX_CLK__ENET0_RX_CLK             0x40d0
+MX28_PAD_ENET0_COL__ENET0_COL                   0x40e0
+MX28_PAD_ENET0_CRS__ENET0_CRS                   0x40f0
+MX28_PAD_ENET_CLK__CLKCTRL_ENET                 0x4100
+MX28_PAD_JTAG_RTCK__JTAG_RTCK                   0x4140
+MX28_PAD_EMI_D00__EMI_DATA0                     0x5000
+MX28_PAD_EMI_D01__EMI_DATA1                     0x5010
+MX28_PAD_EMI_D02__EMI_DATA2                     0x5020
+MX28_PAD_EMI_D03__EMI_DATA3                     0x5030
+MX28_PAD_EMI_D04__EMI_DATA4                     0x5040
+MX28_PAD_EMI_D05__EMI_DATA5                     0x5050
+MX28_PAD_EMI_D06__EMI_DATA6                     0x5060
+MX28_PAD_EMI_D07__EMI_DATA7                     0x5070
+MX28_PAD_EMI_D08__EMI_DATA8                     0x5080
+MX28_PAD_EMI_D09__EMI_DATA9                     0x5090
+MX28_PAD_EMI_D10__EMI_DATA10                    0x50a0
+MX28_PAD_EMI_D11__EMI_DATA11                    0x50b0
+MX28_PAD_EMI_D12__EMI_DATA12                    0x50c0
+MX28_PAD_EMI_D13__EMI_DATA13                    0x50d0
+MX28_PAD_EMI_D14__EMI_DATA14                    0x50e0
+MX28_PAD_EMI_D15__EMI_DATA15                    0x50f0
+MX28_PAD_EMI_ODT0__EMI_ODT0                     0x5100
+MX28_PAD_EMI_DQM0__EMI_DQM0                     0x5110
+MX28_PAD_EMI_ODT1__EMI_ODT1                     0x5120
+MX28_PAD_EMI_DQM1__EMI_DQM1                     0x5130
+MX28_PAD_EMI_DDR_OPEN_FB__EMI_DDR_OPEN_FEEDBACK 0x5140
+MX28_PAD_EMI_CLK__EMI_CLK                       0x5150
+MX28_PAD_EMI_DQS0__EMI_DQS0                     0x5160
+MX28_PAD_EMI_DQS1__EMI_DQS1                     0x5170
+MX28_PAD_EMI_DDR_OPEN__EMI_DDR_OPEN             0x51a0
+MX28_PAD_EMI_A00__EMI_ADDR0                     0x6000
+MX28_PAD_EMI_A01__EMI_ADDR1                     0x6010
+MX28_PAD_EMI_A02__EMI_ADDR2                     0x6020
+MX28_PAD_EMI_A03__EMI_ADDR3                     0x6030
+MX28_PAD_EMI_A04__EMI_ADDR4                     0x6040
+MX28_PAD_EMI_A05__EMI_ADDR5                     0x6050
+MX28_PAD_EMI_A06__EMI_ADDR6                     0x6060
+MX28_PAD_EMI_A07__EMI_ADDR7                     0x6070
+MX28_PAD_EMI_A08__EMI_ADDR8                     0x6080
+MX28_PAD_EMI_A09__EMI_ADDR9                     0x6090
+MX28_PAD_EMI_A10__EMI_ADDR10                    0x60a0
+MX28_PAD_EMI_A11__EMI_ADDR11                    0x60b0
+MX28_PAD_EMI_A12__EMI_ADDR12                    0x60c0
+MX28_PAD_EMI_A13__EMI_ADDR13                    0x60d0
+MX28_PAD_EMI_A14__EMI_ADDR14                    0x60e0
+MX28_PAD_EMI_BA0__EMI_BA0                       0x6100
+MX28_PAD_EMI_BA1__EMI_BA1                       0x6110
+MX28_PAD_EMI_BA2__EMI_BA2                       0x6120
+MX28_PAD_EMI_CASN__EMI_CASN                     0x6130
+MX28_PAD_EMI_RASN__EMI_RASN                     0x6140
+MX28_PAD_EMI_WEN__EMI_WEN                       0x6150
+MX28_PAD_EMI_CE0N__EMI_CE0N                     0x6160
+MX28_PAD_EMI_CE1N__EMI_CE1N                     0x6170
+MX28_PAD_EMI_CKE__EMI_CKE                       0x6180
+MX28_PAD_GPMI_D00__SSP1_D0                      0x0001
+MX28_PAD_GPMI_D01__SSP1_D1                      0x0011
+MX28_PAD_GPMI_D02__SSP1_D2                      0x0021
+MX28_PAD_GPMI_D03__SSP1_D3                      0x0031
+MX28_PAD_GPMI_D04__SSP1_D4                      0x0041
+MX28_PAD_GPMI_D05__SSP1_D5                      0x0051
+MX28_PAD_GPMI_D06__SSP1_D6                      0x0061
+MX28_PAD_GPMI_D07__SSP1_D7                      0x0071
+MX28_PAD_GPMI_CE0N__SSP3_D0                     0x0101
+MX28_PAD_GPMI_CE1N__SSP3_D3                     0x0111
+MX28_PAD_GPMI_CE2N__CAN1_TX                     0x0121
+MX28_PAD_GPMI_CE3N__CAN1_RX                     0x0131
+MX28_PAD_GPMI_RDY0__SSP1_CARD_DETECT            0x0141
+MX28_PAD_GPMI_RDY1__SSP1_CMD                    0x0151
+MX28_PAD_GPMI_RDY2__CAN0_TX                     0x0161
+MX28_PAD_GPMI_RDY3__CAN0_RX                     0x0171
+MX28_PAD_GPMI_RDN__SSP3_SCK                     0x0181
+MX28_PAD_GPMI_WRN__SSP1_SCK                     0x0191
+MX28_PAD_GPMI_ALE__SSP3_D1                      0x01a1
+MX28_PAD_GPMI_CLE__SSP3_D2                      0x01b1
+MX28_PAD_GPMI_RESETN__SSP3_CMD                  0x01c1
+MX28_PAD_LCD_D03__ETM_DA8                       0x1031
+MX28_PAD_LCD_D04__ETM_DA9                       0x1041
+MX28_PAD_LCD_D08__ETM_DA3                       0x1081
+MX28_PAD_LCD_D09__ETM_DA4                       0x1091
+MX28_PAD_LCD_D20__ENET1_1588_EVENT2_OUT         0x1141
+MX28_PAD_LCD_D21__ENET1_1588_EVENT2_IN          0x1151
+MX28_PAD_LCD_D22__ENET1_1588_EVENT3_OUT         0x1161
+MX28_PAD_LCD_D23__ENET1_1588_EVENT3_IN          0x1171
+MX28_PAD_LCD_RD_E__LCD_VSYNC                    0x1181
+MX28_PAD_LCD_WR_RWN__LCD_HSYNC                  0x1191
+MX28_PAD_LCD_RS__LCD_DOTCLK                     0x11a1
+MX28_PAD_LCD_CS__LCD_ENABLE                     0x11b1
+MX28_PAD_LCD_VSYNC__SAIF1_SDATA0                0x11c1
+MX28_PAD_LCD_HSYNC__SAIF1_SDATA1                0x11d1
+MX28_PAD_LCD_DOTCLK__SAIF1_MCLK                 0x11e1
+MX28_PAD_SSP0_DATA4__SSP2_D0                    0x2041
+MX28_PAD_SSP0_DATA5__SSP2_D3                    0x2051
+MX28_PAD_SSP0_DATA6__SSP2_CMD                   0x2061
+MX28_PAD_SSP0_DATA7__SSP2_SCK                   0x2071
+MX28_PAD_SSP1_SCK__SSP2_D1                      0x20c1
+MX28_PAD_SSP1_CMD__SSP2_D2                      0x20d1
+MX28_PAD_SSP1_DATA0__SSP2_D6                    0x20e1
+MX28_PAD_SSP1_DATA3__SSP2_D7                    0x20f1
+MX28_PAD_SSP2_SCK__AUART2_RX                    0x2101
+MX28_PAD_SSP2_MOSI__AUART2_TX                   0x2111
+MX28_PAD_SSP2_MISO__AUART3_RX                   0x2121
+MX28_PAD_SSP2_SS0__AUART3_TX                    0x2131
+MX28_PAD_SSP2_SS1__SSP2_D1                      0x2141
+MX28_PAD_SSP2_SS2__SSP2_D2                      0x2151
+MX28_PAD_SSP3_SCK__AUART4_TX                    0x2181
+MX28_PAD_SSP3_MOSI__AUART4_RX                   0x2191
+MX28_PAD_SSP3_MISO__AUART4_RTS                  0x21a1
+MX28_PAD_SSP3_SS0__AUART4_CTS                   0x21b1
+MX28_PAD_AUART0_RX__I2C0_SCL                    0x3001
+MX28_PAD_AUART0_TX__I2C0_SDA                    0x3011
+MX28_PAD_AUART0_CTS__AUART4_RX                  0x3021
+MX28_PAD_AUART0_RTS__AUART4_TX                  0x3031
+MX28_PAD_AUART1_RX__SSP2_CARD_DETECT            0x3041
+MX28_PAD_AUART1_TX__SSP3_CARD_DETECT            0x3051
+MX28_PAD_AUART1_CTS__USB0_OVERCURRENT           0x3061
+MX28_PAD_AUART1_RTS__USB0_ID                    0x3071
+MX28_PAD_AUART2_RX__SSP3_D1                     0x3081
+MX28_PAD_AUART2_TX__SSP3_D2                     0x3091
+MX28_PAD_AUART2_CTS__I2C1_SCL                   0x30a1
+MX28_PAD_AUART2_RTS__I2C1_SDA                   0x30b1
+MX28_PAD_AUART3_RX__CAN0_TX                     0x30c1
+MX28_PAD_AUART3_TX__CAN0_RX                     0x30d1
+MX28_PAD_AUART3_CTS__CAN1_TX                    0x30e1
+MX28_PAD_AUART3_RTS__CAN1_RX                    0x30f1
+MX28_PAD_PWM0__I2C1_SCL                         0x3101
+MX28_PAD_PWM1__I2C1_SDA                         0x3111
+MX28_PAD_PWM2__USB0_ID                          0x3121
+MX28_PAD_SAIF0_MCLK__PWM_3                      0x3141
+MX28_PAD_SAIF0_LRCLK__PWM_4                     0x3151
+MX28_PAD_SAIF0_BITCLK__PWM_5                    0x3161
+MX28_PAD_SAIF0_SDATA0__PWM_6                    0x3171
+MX28_PAD_I2C0_SCL__TIMROT_ROTARYA               0x3181
+MX28_PAD_I2C0_SDA__TIMROT_ROTARYB               0x3191
+MX28_PAD_SAIF1_SDATA0__PWM_7                    0x31a1
+MX28_PAD_LCD_RESET__LCD_VSYNC                   0x31e1
+MX28_PAD_ENET0_MDC__GPMI_CE4N                   0x4001
+MX28_PAD_ENET0_MDIO__GPMI_CE5N                  0x4011
+MX28_PAD_ENET0_RX_EN__GPMI_CE6N                 0x4021
+MX28_PAD_ENET0_RXD0__GPMI_CE7N                  0x4031
+MX28_PAD_ENET0_RXD1__GPMI_READY4                0x4041
+MX28_PAD_ENET0_TX_CLK__HSADC_TRIGGER            0x4051
+MX28_PAD_ENET0_TX_EN__GPMI_READY5               0x4061
+MX28_PAD_ENET0_TXD0__GPMI_READY6                0x4071
+MX28_PAD_ENET0_TXD1__GPMI_READY7                0x4081
+MX28_PAD_ENET0_RXD2__ENET1_RXD0                 0x4091
+MX28_PAD_ENET0_RXD3__ENET1_RXD1                 0x40a1
+MX28_PAD_ENET0_TXD2__ENET1_TXD0                 0x40b1
+MX28_PAD_ENET0_TXD3__ENET1_TXD1                 0x40c1
+MX28_PAD_ENET0_RX_CLK__ENET0_RX_ER              0x40d1
+MX28_PAD_ENET0_COL__ENET1_TX_EN                 0x40e1
+MX28_PAD_ENET0_CRS__ENET1_RX_EN                 0x40f1
+MX28_PAD_GPMI_CE2N__ENET0_RX_ER                 0x0122
+MX28_PAD_GPMI_CE3N__SAIF1_MCLK                  0x0132
+MX28_PAD_GPMI_RDY0__USB0_ID                     0x0142
+MX28_PAD_GPMI_RDY2__ENET0_TX_ER                 0x0162
+MX28_PAD_GPMI_RDY3__HSADC_TRIGGER               0x0172
+MX28_PAD_GPMI_ALE__SSP3_D4                      0x01a2
+MX28_PAD_GPMI_CLE__SSP3_D5                      0x01b2
+MX28_PAD_LCD_D00__ETM_DA0                       0x1002
+MX28_PAD_LCD_D01__ETM_DA1                       0x1012
+MX28_PAD_LCD_D02__ETM_DA2                       0x1022
+MX28_PAD_LCD_D03__ETM_DA3                       0x1032
+MX28_PAD_LCD_D04__ETM_DA4                       0x1042
+MX28_PAD_LCD_D05__ETM_DA5                       0x1052
+MX28_PAD_LCD_D06__ETM_DA6                       0x1062
+MX28_PAD_LCD_D07__ETM_DA7                       0x1072
+MX28_PAD_LCD_D08__ETM_DA8                       0x1082
+MX28_PAD_LCD_D09__ETM_DA9                       0x1092
+MX28_PAD_LCD_D10__ETM_DA10                      0x10a2
+MX28_PAD_LCD_D11__ETM_DA11                      0x10b2
+MX28_PAD_LCD_D12__ETM_DA12                      0x10c2
+MX28_PAD_LCD_D13__ETM_DA13                      0x10d2
+MX28_PAD_LCD_D14__ETM_DA14                      0x10e2
+MX28_PAD_LCD_D15__ETM_DA15                      0x10f2
+MX28_PAD_LCD_D16__ETM_DA7                       0x1102
+MX28_PAD_LCD_D17__ETM_DA6                       0x1112
+MX28_PAD_LCD_D18__ETM_DA5                       0x1122
+MX28_PAD_LCD_D19__ETM_DA4                       0x1132
+MX28_PAD_LCD_D20__ETM_DA3                       0x1142
+MX28_PAD_LCD_D21__ETM_DA2                       0x1152
+MX28_PAD_LCD_D22__ETM_DA1                       0x1162
+MX28_PAD_LCD_D23__ETM_DA0                       0x1172
+MX28_PAD_LCD_RD_E__ETM_TCTL                     0x1182
+MX28_PAD_LCD_WR_RWN__ETM_TCLK                   0x1192
+MX28_PAD_LCD_HSYNC__ETM_TCTL                    0x11d2
+MX28_PAD_LCD_DOTCLK__ETM_TCLK                   0x11e2
+MX28_PAD_SSP1_SCK__ENET0_1588_EVENT2_OUT        0x20c2
+MX28_PAD_SSP1_CMD__ENET0_1588_EVENT2_IN         0x20d2
+MX28_PAD_SSP1_DATA0__ENET0_1588_EVENT3_OUT      0x20e2
+MX28_PAD_SSP1_DATA3__ENET0_1588_EVENT3_IN       0x20f2
+MX28_PAD_SSP2_SCK__SAIF0_SDATA1                 0x2102
+MX28_PAD_SSP2_MOSI__SAIF0_SDATA2                0x2112
+MX28_PAD_SSP2_MISO__SAIF1_SDATA1                0x2122
+MX28_PAD_SSP2_SS0__SAIF1_SDATA2                 0x2132
+MX28_PAD_SSP2_SS1__USB1_OVERCURRENT             0x2142
+MX28_PAD_SSP2_SS2__USB0_OVERCURRENT             0x2152
+MX28_PAD_SSP3_SCK__ENET1_1588_EVENT0_OUT        0x2182
+MX28_PAD_SSP3_MOSI__ENET1_1588_EVENT0_IN        0x2192
+MX28_PAD_SSP3_MISO__ENET1_1588_EVENT1_OUT       0x21a2
+MX28_PAD_SSP3_SS0__ENET1_1588_EVENT1_IN         0x21b2
+MX28_PAD_AUART0_RX__DUART_CTS                   0x3002
+MX28_PAD_AUART0_TX__DUART_RTS                   0x3012
+MX28_PAD_AUART0_CTS__DUART_RX                   0x3022
+MX28_PAD_AUART0_RTS__DUART_TX                   0x3032
+MX28_PAD_AUART1_RX__PWM_0                       0x3042
+MX28_PAD_AUART1_TX__PWM_1                       0x3052
+MX28_PAD_AUART1_CTS__TIMROT_ROTARYA             0x3062
+MX28_PAD_AUART1_RTS__TIMROT_ROTARYB             0x3072
+MX28_PAD_AUART2_RX__SSP3_D4                     0x3082
+MX28_PAD_AUART2_TX__SSP3_D5                     0x3092
+MX28_PAD_AUART2_CTS__SAIF1_BITCLK               0x30a2
+MX28_PAD_AUART2_RTS__SAIF1_LRCLK                0x30b2
+MX28_PAD_AUART3_RX__ENET0_1588_EVENT0_OUT       0x30c2
+MX28_PAD_AUART3_TX__ENET0_1588_EVENT0_IN        0x30d2
+MX28_PAD_AUART3_CTS__ENET0_1588_EVENT1_OUT      0x30e2
+MX28_PAD_AUART3_RTS__ENET0_1588_EVENT1_IN       0x30f2
+MX28_PAD_PWM0__DUART_RX                         0x3102
+MX28_PAD_PWM1__DUART_TX                         0x3112
+MX28_PAD_PWM2__USB1_OVERCURRENT                 0x3122
+MX28_PAD_SAIF0_MCLK__AUART4_CTS                 0x3142
+MX28_PAD_SAIF0_LRCLK__AUART4_RTS                0x3152
+MX28_PAD_SAIF0_BITCLK__AUART4_RX                0x3162
+MX28_PAD_SAIF0_SDATA0__AUART4_TX                0x3172
+MX28_PAD_I2C0_SCL__DUART_RX                     0x3182
+MX28_PAD_I2C0_SDA__DUART_TX                     0x3192
+MX28_PAD_SAIF1_SDATA0__SAIF0_SDATA1             0x31a2
+MX28_PAD_SPDIF__ENET1_RX_ER                     0x31b2
+MX28_PAD_ENET0_MDC__SAIF0_SDATA1                0x4002
+MX28_PAD_ENET0_MDIO__SAIF0_SDATA2               0x4012
+MX28_PAD_ENET0_RX_EN__SAIF1_SDATA1              0x4022
+MX28_PAD_ENET0_RXD0__SAIF1_SDATA2               0x4032
+MX28_PAD_ENET0_TX_CLK__ENET0_1588_EVENT2_OUT    0x4052
+MX28_PAD_ENET0_RXD2__ENET0_1588_EVENT0_OUT      0x4092
+MX28_PAD_ENET0_RXD3__ENET0_1588_EVENT0_IN       0x40a2
+MX28_PAD_ENET0_TXD2__ENET0_1588_EVENT1_OUT      0x40b2
+MX28_PAD_ENET0_TXD3__ENET0_1588_EVENT1_IN       0x40c2
+MX28_PAD_ENET0_RX_CLK__ENET0_1588_EVENT2_IN     0x40d2
+MX28_PAD_ENET0_COL__ENET0_1588_EVENT3_OUT       0x40e2
+MX28_PAD_ENET0_CRS__ENET0_1588_EVENT3_IN        0x40f2
+MX28_PAD_GPMI_D00__GPIO_0_0                     0x0003
+MX28_PAD_GPMI_D01__GPIO_0_1                     0x0013
+MX28_PAD_GPMI_D02__GPIO_0_2                     0x0023
+MX28_PAD_GPMI_D03__GPIO_0_3                     0x0033
+MX28_PAD_GPMI_D04__GPIO_0_4                     0x0043
+MX28_PAD_GPMI_D05__GPIO_0_5                     0x0053
+MX28_PAD_GPMI_D06__GPIO_0_6                     0x0063
+MX28_PAD_GPMI_D07__GPIO_0_7                     0x0073
+MX28_PAD_GPMI_CE0N__GPIO_0_16                   0x0103
+MX28_PAD_GPMI_CE1N__GPIO_0_17                   0x0113
+MX28_PAD_GPMI_CE2N__GPIO_0_18                   0x0123
+MX28_PAD_GPMI_CE3N__GPIO_0_19                   0x0133
+MX28_PAD_GPMI_RDY0__GPIO_0_20                   0x0143
+MX28_PAD_GPMI_RDY1__GPIO_0_21                   0x0153
+MX28_PAD_GPMI_RDY2__GPIO_0_22                   0x0163
+MX28_PAD_GPMI_RDY3__GPIO_0_23                   0x0173
+MX28_PAD_GPMI_RDN__GPIO_0_24                    0x0183
+MX28_PAD_GPMI_WRN__GPIO_0_25                    0x0193
+MX28_PAD_GPMI_ALE__GPIO_0_26                    0x01a3
+MX28_PAD_GPMI_CLE__GPIO_0_27                    0x01b3
+MX28_PAD_GPMI_RESETN__GPIO_0_28                 0x01c3
+MX28_PAD_LCD_D00__GPIO_1_0                      0x1003
+MX28_PAD_LCD_D01__GPIO_1_1                      0x1013
+MX28_PAD_LCD_D02__GPIO_1_2                      0x1023
+MX28_PAD_LCD_D03__GPIO_1_3                      0x1033
+MX28_PAD_LCD_D04__GPIO_1_4                      0x1043
+MX28_PAD_LCD_D05__GPIO_1_5                      0x1053
+MX28_PAD_LCD_D06__GPIO_1_6                      0x1063
+MX28_PAD_LCD_D07__GPIO_1_7                      0x1073
+MX28_PAD_LCD_D08__GPIO_1_8                      0x1083
+MX28_PAD_LCD_D09__GPIO_1_9                      0x1093
+MX28_PAD_LCD_D10__GPIO_1_10                     0x10a3
+MX28_PAD_LCD_D11__GPIO_1_11                     0x10b3
+MX28_PAD_LCD_D12__GPIO_1_12                     0x10c3
+MX28_PAD_LCD_D13__GPIO_1_13                     0x10d3
+MX28_PAD_LCD_D14__GPIO_1_14                     0x10e3
+MX28_PAD_LCD_D15__GPIO_1_15                     0x10f3
+MX28_PAD_LCD_D16__GPIO_1_16                     0x1103
+MX28_PAD_LCD_D17__GPIO_1_17                     0x1113
+MX28_PAD_LCD_D18__GPIO_1_18                     0x1123
+MX28_PAD_LCD_D19__GPIO_1_19                     0x1133
+MX28_PAD_LCD_D20__GPIO_1_20                     0x1143
+MX28_PAD_LCD_D21__GPIO_1_21                     0x1153
+MX28_PAD_LCD_D22__GPIO_1_22                     0x1163
+MX28_PAD_LCD_D23__GPIO_1_23                     0x1173
+MX28_PAD_LCD_RD_E__GPIO_1_24                    0x1183
+MX28_PAD_LCD_WR_RWN__GPIO_1_25                  0x1193
+MX28_PAD_LCD_RS__GPIO_1_26                      0x11a3
+MX28_PAD_LCD_CS__GPIO_1_27                      0x11b3
+MX28_PAD_LCD_VSYNC__GPIO_1_28                   0x11c3
+MX28_PAD_LCD_HSYNC__GPIO_1_29                   0x11d3
+MX28_PAD_LCD_DOTCLK__GPIO_1_30                  0x11e3
+MX28_PAD_LCD_ENABLE__GPIO_1_31                  0x11f3
+MX28_PAD_SSP0_DATA0__GPIO_2_0                   0x2003
+MX28_PAD_SSP0_DATA1__GPIO_2_1                   0x2013
+MX28_PAD_SSP0_DATA2__GPIO_2_2                   0x2023
+MX28_PAD_SSP0_DATA3__GPIO_2_3                   0x2033
+MX28_PAD_SSP0_DATA4__GPIO_2_4                   0x2043
+MX28_PAD_SSP0_DATA5__GPIO_2_5                   0x2053
+MX28_PAD_SSP0_DATA6__GPIO_2_6                   0x2063
+MX28_PAD_SSP0_DATA7__GPIO_2_7                   0x2073
+MX28_PAD_SSP0_CMD__GPIO_2_8                     0x2083
+MX28_PAD_SSP0_DETECT__GPIO_2_9                  0x2093
+MX28_PAD_SSP0_SCK__GPIO_2_10                    0x20a3
+MX28_PAD_SSP1_SCK__GPIO_2_12                    0x20c3
+MX28_PAD_SSP1_CMD__GPIO_2_13                    0x20d3
+MX28_PAD_SSP1_DATA0__GPIO_2_14                  0x20e3
+MX28_PAD_SSP1_DATA3__GPIO_2_15                  0x20f3
+MX28_PAD_SSP2_SCK__GPIO_2_16                    0x2103
+MX28_PAD_SSP2_MOSI__GPIO_2_17                   0x2113
+MX28_PAD_SSP2_MISO__GPIO_2_18                   0x2123
+MX28_PAD_SSP2_SS0__GPIO_2_19                    0x2133
+MX28_PAD_SSP2_SS1__GPIO_2_20                    0x2143
+MX28_PAD_SSP2_SS2__GPIO_2_21                    0x2153
+MX28_PAD_SSP3_SCK__GPIO_2_24                    0x2183
+MX28_PAD_SSP3_MOSI__GPIO_2_25                   0x2193
+MX28_PAD_SSP3_MISO__GPIO_2_26                   0x21a3
+MX28_PAD_SSP3_SS0__GPIO_2_27                    0x21b3
+MX28_PAD_AUART0_RX__GPIO_3_0                    0x3003
+MX28_PAD_AUART0_TX__GPIO_3_1                    0x3013
+MX28_PAD_AUART0_CTS__GPIO_3_2                   0x3023
+MX28_PAD_AUART0_RTS__GPIO_3_3                   0x3033
+MX28_PAD_AUART1_RX__GPIO_3_4                    0x3043
+MX28_PAD_AUART1_TX__GPIO_3_5                    0x3053
+MX28_PAD_AUART1_CTS__GPIO_3_6                   0x3063
+MX28_PAD_AUART1_RTS__GPIO_3_7                   0x3073
+MX28_PAD_AUART2_RX__GPIO_3_8                    0x3083
+MX28_PAD_AUART2_TX__GPIO_3_9                    0x3093
+MX28_PAD_AUART2_CTS__GPIO_3_10                  0x30a3
+MX28_PAD_AUART2_RTS__GPIO_3_11                  0x30b3
+MX28_PAD_AUART3_RX__GPIO_3_12                   0x30c3
+MX28_PAD_AUART3_TX__GPIO_3_13                   0x30d3
+MX28_PAD_AUART3_CTS__GPIO_3_14                  0x30e3
+MX28_PAD_AUART3_RTS__GPIO_3_15                  0x30f3
+MX28_PAD_PWM0__GPIO_3_16                        0x3103
+MX28_PAD_PWM1__GPIO_3_17                        0x3113
+MX28_PAD_PWM2__GPIO_3_18                        0x3123
+MX28_PAD_SAIF0_MCLK__GPIO_3_20                  0x3143
+MX28_PAD_SAIF0_LRCLK__GPIO_3_21                 0x3153
+MX28_PAD_SAIF0_BITCLK__GPIO_3_22                0x3163
+MX28_PAD_SAIF0_SDATA0__GPIO_3_23                0x3173
+MX28_PAD_I2C0_SCL__GPIO_3_24                    0x3183
+MX28_PAD_I2C0_SDA__GPIO_3_25                    0x3193
+MX28_PAD_SAIF1_SDATA0__GPIO_3_26                0x31a3
+MX28_PAD_SPDIF__GPIO_3_27                       0x31b3
+MX28_PAD_PWM3__GPIO_3_28                        0x31c3
+MX28_PAD_PWM4__GPIO_3_29                        0x31d3
+MX28_PAD_LCD_RESET__GPIO_3_30                   0x31e3
+MX28_PAD_ENET0_MDC__GPIO_4_0                    0x4003
+MX28_PAD_ENET0_MDIO__GPIO_4_1                   0x4013
+MX28_PAD_ENET0_RX_EN__GPIO_4_2                  0x4023
+MX28_PAD_ENET0_RXD0__GPIO_4_3                   0x4033
+MX28_PAD_ENET0_RXD1__GPIO_4_4                   0x4043
+MX28_PAD_ENET0_TX_CLK__GPIO_4_5                 0x4053
+MX28_PAD_ENET0_TX_EN__GPIO_4_6                  0x4063
+MX28_PAD_ENET0_TXD0__GPIO_4_7                   0x4073
+MX28_PAD_ENET0_TXD1__GPIO_4_8                   0x4083
+MX28_PAD_ENET0_RXD2__GPIO_4_9                   0x4093
+MX28_PAD_ENET0_RXD3__GPIO_4_10                  0x40a3
+MX28_PAD_ENET0_TXD2__GPIO_4_11                  0x40b3
+MX28_PAD_ENET0_TXD3__GPIO_4_12                  0x40c3
+MX28_PAD_ENET0_RX_CLK__GPIO_4_13                0x40d3
+MX28_PAD_ENET0_COL__GPIO_4_14                   0x40e3
+MX28_PAD_ENET0_CRS__GPIO_4_15                   0x40f3
+MX28_PAD_ENET_CLK__GPIO_4_16                    0x4103
+MX28_PAD_JTAG_RTCK__GPIO_4_20                   0x4143
+
+Valid values for i.MX23 pinmux-id:
+
+pinmux                                          id
+------                                          --
+MX23_PAD_GPMI_D00__GPMI_D00                     0x0000
+MX23_PAD_GPMI_D01__GPMI_D01                     0x0010
+MX23_PAD_GPMI_D02__GPMI_D02                     0x0020
+MX23_PAD_GPMI_D03__GPMI_D03                     0x0030
+MX23_PAD_GPMI_D04__GPMI_D04                     0x0040
+MX23_PAD_GPMI_D05__GPMI_D05                     0x0050
+MX23_PAD_GPMI_D06__GPMI_D06                     0x0060
+MX23_PAD_GPMI_D07__GPMI_D07                     0x0070
+MX23_PAD_GPMI_D08__GPMI_D08                     0x0080
+MX23_PAD_GPMI_D09__GPMI_D09                     0x0090
+MX23_PAD_GPMI_D10__GPMI_D10                     0x00a0
+MX23_PAD_GPMI_D11__GPMI_D11                     0x00b0
+MX23_PAD_GPMI_D12__GPMI_D12                     0x00c0
+MX23_PAD_GPMI_D13__GPMI_D13                     0x00d0
+MX23_PAD_GPMI_D14__GPMI_D14                     0x00e0
+MX23_PAD_GPMI_D15__GPMI_D15                     0x00f0
+MX23_PAD_GPMI_CLE__GPMI_CLE                     0x0100
+MX23_PAD_GPMI_ALE__GPMI_ALE                     0x0110
+MX23_PAD_GPMI_CE2N__GPMI_CE2N                   0x0120
+MX23_PAD_GPMI_RDY0__GPMI_RDY0                   0x0130
+MX23_PAD_GPMI_RDY1__GPMI_RDY1                   0x0140
+MX23_PAD_GPMI_RDY2__GPMI_RDY2                   0x0150
+MX23_PAD_GPMI_RDY3__GPMI_RDY3                   0x0160
+MX23_PAD_GPMI_WPN__GPMI_WPN                     0x0170
+MX23_PAD_GPMI_WRN__GPMI_WRN                     0x0180
+MX23_PAD_GPMI_RDN__GPMI_RDN                     0x0190
+MX23_PAD_AUART1_CTS__AUART1_CTS                 0x01a0
+MX23_PAD_AUART1_RTS__AUART1_RTS                 0x01b0
+MX23_PAD_AUART1_RX__AUART1_RX                   0x01c0
+MX23_PAD_AUART1_TX__AUART1_TX                   0x01d0
+MX23_PAD_I2C_SCL__I2C_SCL                       0x01e0
+MX23_PAD_I2C_SDA__I2C_SDA                       0x01f0
+MX23_PAD_LCD_D00__LCD_D00                       0x1000
+MX23_PAD_LCD_D01__LCD_D01                       0x1010
+MX23_PAD_LCD_D02__LCD_D02                       0x1020
+MX23_PAD_LCD_D03__LCD_D03                       0x1030
+MX23_PAD_LCD_D04__LCD_D04                       0x1040
+MX23_PAD_LCD_D05__LCD_D05                       0x1050
+MX23_PAD_LCD_D06__LCD_D06                       0x1060
+MX23_PAD_LCD_D07__LCD_D07                       0x1070
+MX23_PAD_LCD_D08__LCD_D08                       0x1080
+MX23_PAD_LCD_D09__LCD_D09                       0x1090
+MX23_PAD_LCD_D10__LCD_D10                       0x10a0
+MX23_PAD_LCD_D11__LCD_D11                       0x10b0
+MX23_PAD_LCD_D12__LCD_D12                       0x10c0
+MX23_PAD_LCD_D13__LCD_D13                       0x10d0
+MX23_PAD_LCD_D14__LCD_D14                       0x10e0
+MX23_PAD_LCD_D15__LCD_D15                       0x10f0
+MX23_PAD_LCD_D16__LCD_D16                       0x1100
+MX23_PAD_LCD_D17__LCD_D17                       0x1110
+MX23_PAD_LCD_RESET__LCD_RESET                   0x1120
+MX23_PAD_LCD_RS__LCD_RS                         0x1130
+MX23_PAD_LCD_WR__LCD_WR                         0x1140
+MX23_PAD_LCD_CS__LCD_CS                         0x1150
+MX23_PAD_LCD_DOTCK__LCD_DOTCK                   0x1160
+MX23_PAD_LCD_ENABLE__LCD_ENABLE                 0x1170
+MX23_PAD_LCD_HSYNC__LCD_HSYNC                   0x1180
+MX23_PAD_LCD_VSYNC__LCD_VSYNC                   0x1190
+MX23_PAD_PWM0__PWM0                             0x11a0
+MX23_PAD_PWM1__PWM1                             0x11b0
+MX23_PAD_PWM2__PWM2                             0x11c0
+MX23_PAD_PWM3__PWM3                             0x11d0
+MX23_PAD_PWM4__PWM4                             0x11e0
+MX23_PAD_SSP1_CMD__SSP1_CMD                     0x2000
+MX23_PAD_SSP1_DETECT__SSP1_DETECT               0x2010
+MX23_PAD_SSP1_DATA0__SSP1_DATA0                 0x2020
+MX23_PAD_SSP1_DATA1__SSP1_DATA1                 0x2030
+MX23_PAD_SSP1_DATA2__SSP1_DATA2                 0x2040
+MX23_PAD_SSP1_DATA3__SSP1_DATA3                 0x2050
+MX23_PAD_SSP1_SCK__SSP1_SCK                     0x2060
+MX23_PAD_ROTARYA__ROTARYA                       0x2070
+MX23_PAD_ROTARYB__ROTARYB                       0x2080
+MX23_PAD_EMI_A00__EMI_A00                       0x2090
+MX23_PAD_EMI_A01__EMI_A01                       0x20a0
+MX23_PAD_EMI_A02__EMI_A02                       0x20b0
+MX23_PAD_EMI_A03__EMI_A03                       0x20c0
+MX23_PAD_EMI_A04__EMI_A04                       0x20d0
+MX23_PAD_EMI_A05__EMI_A05                       0x20e0
+MX23_PAD_EMI_A06__EMI_A06                       0x20f0
+MX23_PAD_EMI_A07__EMI_A07                       0x2100
+MX23_PAD_EMI_A08__EMI_A08                       0x2110
+MX23_PAD_EMI_A09__EMI_A09                       0x2120
+MX23_PAD_EMI_A10__EMI_A10                       0x2130
+MX23_PAD_EMI_A11__EMI_A11                       0x2140
+MX23_PAD_EMI_A12__EMI_A12                       0x2150
+MX23_PAD_EMI_BA0__EMI_BA0                       0x2160
+MX23_PAD_EMI_BA1__EMI_BA1                       0x2170
+MX23_PAD_EMI_CASN__EMI_CASN                     0x2180
+MX23_PAD_EMI_CE0N__EMI_CE0N                     0x2190
+MX23_PAD_EMI_CE1N__EMI_CE1N                     0x21a0
+MX23_PAD_GPMI_CE1N__GPMI_CE1N                   0x21b0
+MX23_PAD_GPMI_CE0N__GPMI_CE0N                   0x21c0
+MX23_PAD_EMI_CKE__EMI_CKE                       0x21d0
+MX23_PAD_EMI_RASN__EMI_RASN                     0x21e0
+MX23_PAD_EMI_WEN__EMI_WEN                       0x21f0
+MX23_PAD_EMI_D00__EMI_D00                       0x3000
+MX23_PAD_EMI_D01__EMI_D01                       0x3010
+MX23_PAD_EMI_D02__EMI_D02                       0x3020
+MX23_PAD_EMI_D03__EMI_D03                       0x3030
+MX23_PAD_EMI_D04__EMI_D04                       0x3040
+MX23_PAD_EMI_D05__EMI_D05                       0x3050
+MX23_PAD_EMI_D06__EMI_D06                       0x3060
+MX23_PAD_EMI_D07__EMI_D07                       0x3070
+MX23_PAD_EMI_D08__EMI_D08                       0x3080
+MX23_PAD_EMI_D09__EMI_D09                       0x3090
+MX23_PAD_EMI_D10__EMI_D10                       0x30a0
+MX23_PAD_EMI_D11__EMI_D11                       0x30b0
+MX23_PAD_EMI_D12__EMI_D12                       0x30c0
+MX23_PAD_EMI_D13__EMI_D13                       0x30d0
+MX23_PAD_EMI_D14__EMI_D14                       0x30e0
+MX23_PAD_EMI_D15__EMI_D15                       0x30f0
+MX23_PAD_EMI_DQM0__EMI_DQM0                     0x3100
+MX23_PAD_EMI_DQM1__EMI_DQM1                     0x3110
+MX23_PAD_EMI_DQS0__EMI_DQS0                     0x3120
+MX23_PAD_EMI_DQS1__EMI_DQS1                     0x3130
+MX23_PAD_EMI_CLK__EMI_CLK                       0x3140
+MX23_PAD_EMI_CLKN__EMI_CLKN                     0x3150
+MX23_PAD_GPMI_D00__LCD_D8                       0x0001
+MX23_PAD_GPMI_D01__LCD_D9                       0x0011
+MX23_PAD_GPMI_D02__LCD_D10                      0x0021
+MX23_PAD_GPMI_D03__LCD_D11                      0x0031
+MX23_PAD_GPMI_D04__LCD_D12                      0x0041
+MX23_PAD_GPMI_D05__LCD_D13                      0x0051
+MX23_PAD_GPMI_D06__LCD_D14                      0x0061
+MX23_PAD_GPMI_D07__LCD_D15                      0x0071
+MX23_PAD_GPMI_D08__LCD_D18                      0x0081
+MX23_PAD_GPMI_D09__LCD_D19                      0x0091
+MX23_PAD_GPMI_D10__LCD_D20                      0x00a1
+MX23_PAD_GPMI_D11__LCD_D21                      0x00b1
+MX23_PAD_GPMI_D12__LCD_D22                      0x00c1
+MX23_PAD_GPMI_D13__LCD_D23                      0x00d1
+MX23_PAD_GPMI_D14__AUART2_RX                    0x00e1
+MX23_PAD_GPMI_D15__AUART2_TX                    0x00f1
+MX23_PAD_GPMI_CLE__LCD_D16                      0x0101
+MX23_PAD_GPMI_ALE__LCD_D17                      0x0111
+MX23_PAD_GPMI_CE2N__ATA_A2                      0x0121
+MX23_PAD_AUART1_RTS__IR_CLK                     0x01b1
+MX23_PAD_AUART1_RX__IR_RX                       0x01c1
+MX23_PAD_AUART1_TX__IR_TX                       0x01d1
+MX23_PAD_I2C_SCL__GPMI_RDY2                     0x01e1
+MX23_PAD_I2C_SDA__GPMI_CE2N                     0x01f1
+MX23_PAD_LCD_D00__ETM_DA8                       0x1001
+MX23_PAD_LCD_D01__ETM_DA9                       0x1011
+MX23_PAD_LCD_D02__ETM_DA10                      0x1021
+MX23_PAD_LCD_D03__ETM_DA11                      0x1031
+MX23_PAD_LCD_D04__ETM_DA12                      0x1041
+MX23_PAD_LCD_D05__ETM_DA13                      0x1051
+MX23_PAD_LCD_D06__ETM_DA14                      0x1061
+MX23_PAD_LCD_D07__ETM_DA15                      0x1071
+MX23_PAD_LCD_D08__ETM_DA0                       0x1081
+MX23_PAD_LCD_D09__ETM_DA1                       0x1091
+MX23_PAD_LCD_D10__ETM_DA2                       0x10a1
+MX23_PAD_LCD_D11__ETM_DA3                       0x10b1
+MX23_PAD_LCD_D12__ETM_DA4                       0x10c1
+MX23_PAD_LCD_D13__ETM_DA5                       0x10d1
+MX23_PAD_LCD_D14__ETM_DA6                       0x10e1
+MX23_PAD_LCD_D15__ETM_DA7                       0x10f1
+MX23_PAD_LCD_RESET__ETM_TCTL                    0x1121
+MX23_PAD_LCD_RS__ETM_TCLK                       0x1131
+MX23_PAD_LCD_DOTCK__GPMI_RDY3                   0x1161
+MX23_PAD_LCD_ENABLE__I2C_SCL                    0x1171
+MX23_PAD_LCD_HSYNC__I2C_SDA                     0x1181
+MX23_PAD_LCD_VSYNC__LCD_BUSY                    0x1191
+MX23_PAD_PWM0__ROTARYA                          0x11a1
+MX23_PAD_PWM1__ROTARYB                          0x11b1
+MX23_PAD_PWM2__GPMI_RDY3                        0x11c1
+MX23_PAD_PWM3__ETM_TCTL                         0x11d1
+MX23_PAD_PWM4__ETM_TCLK                         0x11e1
+MX23_PAD_SSP1_DETECT__GPMI_CE3N                 0x2011
+MX23_PAD_SSP1_DATA1__I2C_SCL                    0x2031
+MX23_PAD_SSP1_DATA2__I2C_SDA                    0x2041
+MX23_PAD_ROTARYA__AUART2_RTS                    0x2071
+MX23_PAD_ROTARYB__AUART2_CTS                    0x2081
+MX23_PAD_GPMI_D00__SSP2_DATA0                   0x0002
+MX23_PAD_GPMI_D01__SSP2_DATA1                   0x0012
+MX23_PAD_GPMI_D02__SSP2_DATA2                   0x0022
+MX23_PAD_GPMI_D03__SSP2_DATA3                   0x0032
+MX23_PAD_GPMI_D04__SSP2_DATA4                   0x0042
+MX23_PAD_GPMI_D05__SSP2_DATA5                   0x0052
+MX23_PAD_GPMI_D06__SSP2_DATA6                   0x0062
+MX23_PAD_GPMI_D07__SSP2_DATA7                   0x0072
+MX23_PAD_GPMI_D08__SSP1_DATA4                   0x0082
+MX23_PAD_GPMI_D09__SSP1_DATA5                   0x0092
+MX23_PAD_GPMI_D10__SSP1_DATA6                   0x00a2
+MX23_PAD_GPMI_D11__SSP1_DATA7                   0x00b2
+MX23_PAD_GPMI_D15__GPMI_CE3N                    0x00f2
+MX23_PAD_GPMI_RDY0__SSP2_DETECT                 0x0132
+MX23_PAD_GPMI_RDY1__SSP2_CMD                    0x0142
+MX23_PAD_GPMI_WRN__SSP2_SCK                     0x0182
+MX23_PAD_AUART1_CTS__SSP1_DATA4                 0x01a2
+MX23_PAD_AUART1_RTS__SSP1_DATA5                 0x01b2
+MX23_PAD_AUART1_RX__SSP1_DATA6                  0x01c2
+MX23_PAD_AUART1_TX__SSP1_DATA7                  0x01d2
+MX23_PAD_I2C_SCL__AUART1_TX                     0x01e2
+MX23_PAD_I2C_SDA__AUART1_RX                     0x01f2
+MX23_PAD_LCD_D08__SAIF2_SDATA0                  0x1082
+MX23_PAD_LCD_D09__SAIF1_SDATA0                  0x1092
+MX23_PAD_LCD_D10__SAIF_MCLK_BITCLK              0x10a2
+MX23_PAD_LCD_D11__SAIF_LRCLK                    0x10b2
+MX23_PAD_LCD_D12__SAIF2_SDATA1                  0x10c2
+MX23_PAD_LCD_D13__SAIF2_SDATA2                  0x10d2
+MX23_PAD_LCD_D14__SAIF1_SDATA2                  0x10e2
+MX23_PAD_LCD_D15__SAIF1_SDATA1                  0x10f2
+MX23_PAD_LCD_D16__SAIF_ALT_BITCLK               0x1102
+MX23_PAD_LCD_RESET__GPMI_CE3N                   0x1122
+MX23_PAD_PWM0__DUART_RX                         0x11a2
+MX23_PAD_PWM1__DUART_TX                         0x11b2
+MX23_PAD_PWM3__AUART1_CTS                       0x11d2
+MX23_PAD_PWM4__AUART1_RTS                       0x11e2
+MX23_PAD_SSP1_CMD__JTAG_TDO                     0x2002
+MX23_PAD_SSP1_DETECT__USB_OTG_ID                0x2012
+MX23_PAD_SSP1_DATA0__JTAG_TDI                   0x2022
+MX23_PAD_SSP1_DATA1__JTAG_TCLK                  0x2032
+MX23_PAD_SSP1_DATA2__JTAG_RTCK                  0x2042
+MX23_PAD_SSP1_DATA3__JTAG_TMS                   0x2052
+MX23_PAD_SSP1_SCK__JTAG_TRST                    0x2062
+MX23_PAD_ROTARYA__SPDIF                         0x2072
+MX23_PAD_ROTARYB__GPMI_CE3N                     0x2082
+MX23_PAD_GPMI_D00__GPIO_0_0                     0x0003
+MX23_PAD_GPMI_D01__GPIO_0_1                     0x0013
+MX23_PAD_GPMI_D02__GPIO_0_2                     0x0023
+MX23_PAD_GPMI_D03__GPIO_0_3                     0x0033
+MX23_PAD_GPMI_D04__GPIO_0_4                     0x0043
+MX23_PAD_GPMI_D05__GPIO_0_5                     0x0053
+MX23_PAD_GPMI_D06__GPIO_0_6                     0x0063
+MX23_PAD_GPMI_D07__GPIO_0_7                     0x0073
+MX23_PAD_GPMI_D08__GPIO_0_8                     0x0083
+MX23_PAD_GPMI_D09__GPIO_0_9                     0x0093
+MX23_PAD_GPMI_D10__GPIO_0_10                    0x00a3
+MX23_PAD_GPMI_D11__GPIO_0_11                    0x00b3
+MX23_PAD_GPMI_D12__GPIO_0_12                    0x00c3
+MX23_PAD_GPMI_D13__GPIO_0_13                    0x00d3
+MX23_PAD_GPMI_D14__GPIO_0_14                    0x00e3
+MX23_PAD_GPMI_D15__GPIO_0_15                    0x00f3
+MX23_PAD_GPMI_CLE__GPIO_0_16                    0x0103
+MX23_PAD_GPMI_ALE__GPIO_0_17                    0x0113
+MX23_PAD_GPMI_CE2N__GPIO_0_18                   0x0123
+MX23_PAD_GPMI_RDY0__GPIO_0_19                   0x0133
+MX23_PAD_GPMI_RDY1__GPIO_0_20                   0x0143
+MX23_PAD_GPMI_RDY2__GPIO_0_21                   0x0153
+MX23_PAD_GPMI_RDY3__GPIO_0_22                   0x0163
+MX23_PAD_GPMI_WPN__GPIO_0_23                    0x0173
+MX23_PAD_GPMI_WRN__GPIO_0_24                    0x0183
+MX23_PAD_GPMI_RDN__GPIO_0_25                    0x0193
+MX23_PAD_AUART1_CTS__GPIO_0_26                  0x01a3
+MX23_PAD_AUART1_RTS__GPIO_0_27                  0x01b3
+MX23_PAD_AUART1_RX__GPIO_0_28                   0x01c3
+MX23_PAD_AUART1_TX__GPIO_0_29                   0x01d3
+MX23_PAD_I2C_SCL__GPIO_0_30                     0x01e3
+MX23_PAD_I2C_SDA__GPIO_0_31                     0x01f3
+MX23_PAD_LCD_D00__GPIO_1_0                      0x1003
+MX23_PAD_LCD_D01__GPIO_1_1                      0x1013
+MX23_PAD_LCD_D02__GPIO_1_2                      0x1023
+MX23_PAD_LCD_D03__GPIO_1_3                      0x1033
+MX23_PAD_LCD_D04__GPIO_1_4                      0x1043
+MX23_PAD_LCD_D05__GPIO_1_5                      0x1053
+MX23_PAD_LCD_D06__GPIO_1_6                      0x1063
+MX23_PAD_LCD_D07__GPIO_1_7                      0x1073
+MX23_PAD_LCD_D08__GPIO_1_8                      0x1083
+MX23_PAD_LCD_D09__GPIO_1_9                      0x1093
+MX23_PAD_LCD_D10__GPIO_1_10                     0x10a3
+MX23_PAD_LCD_D11__GPIO_1_11                     0x10b3
+MX23_PAD_LCD_D12__GPIO_1_12                     0x10c3
+MX23_PAD_LCD_D13__GPIO_1_13                     0x10d3
+MX23_PAD_LCD_D14__GPIO_1_14                     0x10e3
+MX23_PAD_LCD_D15__GPIO_1_15                     0x10f3
+MX23_PAD_LCD_D16__GPIO_1_16                     0x1103
+MX23_PAD_LCD_D17__GPIO_1_17                     0x1113
+MX23_PAD_LCD_RESET__GPIO_1_18                   0x1123
+MX23_PAD_LCD_RS__GPIO_1_19                      0x1133
+MX23_PAD_LCD_WR__GPIO_1_20                      0x1143
+MX23_PAD_LCD_CS__GPIO_1_21                      0x1153
+MX23_PAD_LCD_DOTCK__GPIO_1_22                   0x1163
+MX23_PAD_LCD_ENABLE__GPIO_1_23                  0x1173
+MX23_PAD_LCD_HSYNC__GPIO_1_24                   0x1183
+MX23_PAD_LCD_VSYNC__GPIO_1_25                   0x1193
+MX23_PAD_PWM0__GPIO_1_26                        0x11a3
+MX23_PAD_PWM1__GPIO_1_27                        0x11b3
+MX23_PAD_PWM2__GPIO_1_28                        0x11c3
+MX23_PAD_PWM3__GPIO_1_29                        0x11d3
+MX23_PAD_PWM4__GPIO_1_30                        0x11e3
+MX23_PAD_SSP1_CMD__GPIO_2_0                     0x2003
+MX23_PAD_SSP1_DETECT__GPIO_2_1                  0x2013
+MX23_PAD_SSP1_DATA0__GPIO_2_2                   0x2023
+MX23_PAD_SSP1_DATA1__GPIO_2_3                   0x2033
+MX23_PAD_SSP1_DATA2__GPIO_2_4                   0x2043
+MX23_PAD_SSP1_DATA3__GPIO_2_5                   0x2053
+MX23_PAD_SSP1_SCK__GPIO_2_6                     0x2063
+MX23_PAD_ROTARYA__GPIO_2_7                      0x2073
+MX23_PAD_ROTARYB__GPIO_2_8                      0x2083
+MX23_PAD_EMI_A00__GPIO_2_9                      0x2093
+MX23_PAD_EMI_A01__GPIO_2_10                     0x20a3
+MX23_PAD_EMI_A02__GPIO_2_11                     0x20b3
+MX23_PAD_EMI_A03__GPIO_2_12                     0x20c3
+MX23_PAD_EMI_A04__GPIO_2_13                     0x20d3
+MX23_PAD_EMI_A05__GPIO_2_14                     0x20e3
+MX23_PAD_EMI_A06__GPIO_2_15                     0x20f3
+MX23_PAD_EMI_A07__GPIO_2_16                     0x2103
+MX23_PAD_EMI_A08__GPIO_2_17                     0x2113
+MX23_PAD_EMI_A09__GPIO_2_18                     0x2123
+MX23_PAD_EMI_A10__GPIO_2_19                     0x2133
+MX23_PAD_EMI_A11__GPIO_2_20                     0x2143
+MX23_PAD_EMI_A12__GPIO_2_21                     0x2153
+MX23_PAD_EMI_BA0__GPIO_2_22                     0x2163
+MX23_PAD_EMI_BA1__GPIO_2_23                     0x2173
+MX23_PAD_EMI_CASN__GPIO_2_24                    0x2183
+MX23_PAD_EMI_CE0N__GPIO_2_25                    0x2193
+MX23_PAD_EMI_CE1N__GPIO_2_26                    0x21a3
+MX23_PAD_GPMI_CE1N__GPIO_2_27                   0x21b3
+MX23_PAD_GPMI_CE0N__GPIO_2_28                   0x21c3
+MX23_PAD_EMI_CKE__GPIO_2_29                     0x21d3
+MX23_PAD_EMI_RASN__GPIO_2_30                    0x21e3
+MX23_PAD_EMI_WEN__GPIO_2_31                     0x21f3
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt
new file mode 100644
index 000000000000..c8e578263ce2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt
@@ -0,0 +1,132 @@
+NVIDIA Tegra20 pinmux controller
+
+Required properties:
+- compatible: "nvidia,tegra20-pinmux"
+- reg: Should contain the register physical address and length for each of
+  the tri-state, mux, pull-up/down, and pad control register sets.
+
+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".
+
+Tegra's pin configuration nodes act as a container for an abitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, tristate, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function or tristate parameter. For this
+reason, even seemingly boolean values are actually tristates in this binding:
+unspecified, off, or on. Unspecified is represented as an absent property,
+and off/on are represented as integer values 0 and 1.
+
+Required subnode-properties:
+- nvidia,pins : An array of strings. Each string contains the name of a pin or
+    group. Valid values for these names are listed below.
+
+Optional subnode-properties:
+- nvidia,function: A string containing the name of the function to mux to the
+  pin or group. Valid values for function names are listed below. See the Tegra
+  TRM to determine which are valid for each pin or group.
+- nvidia,pull: Integer, representing the pull-down/up to apply to the pin.
+    0: none, 1: down, 2: up.
+- nvidia,tristate: Integer.
+    0: drive, 1: tristate.
+- nvidia,high-speed-mode: Integer. Enable high speed mode the pins.
+    0: no, 1: yes.
+- nvidia,schmitt: Integer. Enables Schmitt Trigger on the input.
+    0: no, 1: yes.
+- nvidia,low-power-mode: Integer. Valid values 0-3. 0 is least power, 3 is
+    most power. Controls the drive power or current. See "Low Power Mode"
+    or "LPMD1" and "LPMD0" in the Tegra TRM.
+- nvidia,pull-down-strength: Integer. Controls drive strength. 0 is weakest.
+    The range of valid values depends on the pingroup. See "CAL_DRVDN" in the
+    Tegra TRM.
+- nvidia,pull-up-strength: Integer. Controls drive strength. 0 is weakest.
+    The range of valid values depends on the pingroup. See "CAL_DRVUP" in the
+    Tegra TRM.
+- nvidia,slew-rate-rising: Integer. Controls rising signal slew rate. 0 is
+    fastest. The range of valid values depends on the pingroup. See
+    "DRVDN_SLWR" in the Tegra TRM.
+- nvidia,slew-rate-falling: Integer. Controls falling signal slew rate. 0 is
+    fastest. The range of valid values depends on the pingroup. See
+    "DRVUP_SLWF" in the Tegra TRM.
+
+Note that many of these properties are only valid for certain specific pins
+or groups. See the Tegra TRM and various pinmux spreadsheets for complete
+details regarding which groups support which functionality. The Linux pinctrl
+driver may also be a useful reference, since it consolidates, disambiguates,
+and corrects data from all those sources.
+
+Valid values for pin and group names are:
+
+  mux groups:
+
+    These all support nvidia,function, nvidia,tristate, and many support
+    nvidia,pull.
+
+    ata, atb, atc, atd, ate, cdev1, cdev2, crtp, csus, dap1, dap2, dap3, dap4,
+    ddc, dta, dtb, dtc, dtd, dte, dtf, gma, gmb, gmc, gmd, gme, gpu, gpu7,
+    gpv, hdint, i2cp, irrx, irtx, kbca, kbcb, kbcc, kbcd, kbce, kbcf, lcsn,
+    ld0, ld1, ld2, ld3, ld4, ld5, ld6, ld7, ld8, ld9, ld10, ld11, ld12, ld13,
+    ld14, ld15, ld16, ld17, ldc, ldi, lhp0, lhp1, lhp2, lhs, lm0, lm1, lpp,
+    lpw0, lpw1, lpw2, lsc0, lsc1, lsck, lsda, lsdi, lspi, lvp0, lvp1, lvs,
+    owc, pmc, pta, rm, sdb, sdc, sdd, sdio1, slxa, slxc, slxd, slxk, spdi,
+    spdo, spia, spib, spic, spid, spie, spif, spig, spih, uaa, uab, uac, uad,
+    uca, ucb, uda.
+
+  tristate groups:
+
+    These only support nvidia,pull.
+
+    ck32, ddrc, pmca, pmcb, pmcc, pmcd, pmce, xm2c, xm2d, ls, lc, ld17_0,
+    ld19_18, ld21_20, ld23_22.
+
+  drive groups:
+
+    With some exceptions, these support nvidia,high-speed-mode,
+    nvidia,schmitt, nvidia,low-power-mode, nvidia,pull-down-strength,
+    nvidia,pull-up-strength, nvidia,slew_rate-rising, nvidia,slew_rate-falling.
+
+    drive_ao1, drive_ao2, drive_at1, drive_at2, drive_cdev1, drive_cdev2,
+    drive_csus, drive_dap1, drive_dap2, drive_dap3, drive_dap4, drive_dbg,
+    drive_lcd1, drive_lcd2, drive_sdmmc2, drive_sdmmc3, drive_spi, drive_uaa,
+    drive_uab, drive_uart2, drive_uart3, drive_vi1, drive_vi2, drive_xm2a,
+    drive_xm2c, drive_xm2d, drive_xm2clk, drive_sdio1, drive_crt, drive_ddc,
+    drive_gma, drive_gmb, drive_gmc, drive_gmd, drive_gme, drive_owr,
+    drive_uda.
+
+Example:
+
+        pinctrl@70000000 {
+                compatible = "nvidia,tegra20-pinmux";
+                reg = < 0x70000014 0x10    /* Tri-state registers */
+                        0x70000080 0x20    /* Mux registers */
+                        0x700000a0 0x14    /* Pull-up/down registers */
+                        0x70000868 0xa8 >; /* Pad control registers */
+        };
+
+Example board file extract:
+
+        pinctrl@70000000 {
+                sdio4_default: sdio4_default {
+                        atb {
+                                nvidia,pins = "atb", "gma", "gme";
+                                nvidia,function = "sdio4";
+                                nvidia,pull = <0>;
+                                nvidia,tristate = <0>;
+                        };
+                };
+        };
+
+        sdhci@c8000600 {
+                pinctrl-names = "default";
+                pinctrl-0 = <&sdio4_default>;
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt
new file mode 100644
index 000000000000..c275b70349c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt
@@ -0,0 +1,132 @@
+NVIDIA Tegra30 pinmux controller
+
+The Tegra30 pinctrl binding is very similar to the Tegra20 pinctrl binding,
+as described in nvidia,tegra20-pinmux.txt. In fact, this document assumes
+that binding as a baseline, and only documents the differences between the
+two bindings.
+
+Required properties:
+- compatible: "nvidia,tegra30-pinmux"
+- reg: Should contain the register physical address and length for each of
+  the pad control and mux registers.
+
+Tegra30 adds the following optional properties for pin configuration subnodes:
+- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes.
+- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes.
+- nvidia,lock: Integer. Lock the pin configuration against further changes
+    until reset. 0: no, 1: yes.
+- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes.
+
+As with Tegra20, see the Tegra TRM for complete details regarding which groups
+support which functionality.
+
+Valid values for pin and group names are:
+
+  per-pin mux groups:
+
+    These all support nvidia,function, nvidia,tristate, nvidia,pull,
+    nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain,
+    nvidia,io-reset.
+
+    clk_32k_out_pa0, uart3_cts_n_pa1, dap2_fs_pa2, dap2_sclk_pa3,
+    dap2_din_pa4, dap2_dout_pa5, sdmmc3_clk_pa6, sdmmc3_cmd_pa7, gmi_a17_pb0,
+    gmi_a18_pb1, lcd_pwr0_pb2, lcd_pclk_pb3, sdmmc3_dat3_pb4, sdmmc3_dat2_pb5,
+    sdmmc3_dat1_pb6, sdmmc3_dat0_pb7, uart3_rts_n_pc0, lcd_pwr1_pc1,
+    uart2_txd_pc2, uart2_rxd_pc3, gen1_i2c_scl_pc4, gen1_i2c_sda_pc5,
+    lcd_pwr2_pc6, gmi_wp_n_pc7, sdmmc3_dat5_pd0, sdmmc3_dat4_pd1, lcd_dc1_pd2,
+    sdmmc3_dat6_pd3, sdmmc3_dat7_pd4, vi_d1_pd5, vi_vsync_pd6, vi_hsync_pd7,
+    lcd_d0_pe0, lcd_d1_pe1, lcd_d2_pe2, lcd_d3_pe3, lcd_d4_pe4, lcd_d5_pe5,
+    lcd_d6_pe6, lcd_d7_pe7, lcd_d8_pf0, lcd_d9_pf1, lcd_d10_pf2, lcd_d11_pf3,
+    lcd_d12_pf4, lcd_d13_pf5, lcd_d14_pf6, lcd_d15_pf7, gmi_ad0_pg0,
+    gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5,
+    gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2,
+    gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7,
+    gmi_wr_n_pi0, gmi_oe_n_pi1, gmi_dqs_pi2, gmi_cs6_n_pi3, gmi_rst_n_pi4,
+    gmi_iordy_pi5, gmi_cs7_n_pi6, gmi_wait_pi7, gmi_cs0_n_pj0, lcd_de_pj1,
+    gmi_cs1_n_pj2, lcd_hsync_pj3, lcd_vsync_pj4, uart2_cts_n_pj5,
+    uart2_rts_n_pj6, gmi_a16_pj7, gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs4_n_pk2,
+    gmi_cs2_n_pk3, gmi_cs3_n_pk4, spdif_out_pk5, spdif_in_pk6, gmi_a19_pk7,
+    vi_d2_pl0, vi_d3_pl1, vi_d4_pl2, vi_d5_pl3, vi_d6_pl4, vi_d7_pl5,
+    vi_d8_pl6, vi_d9_pl7, lcd_d16_pm0, lcd_d17_pm1, lcd_d18_pm2, lcd_d19_pm3,
+    lcd_d20_pm4, lcd_d21_pm5, lcd_d22_pm6, lcd_d23_pm7, dap1_fs_pn0,
+    dap1_din_pn1, dap1_dout_pn2, dap1_sclk_pn3, lcd_cs0_n_pn4, lcd_sdout_pn5,
+    lcd_dc0_pn6, hdmi_int_pn7, ulpi_data7_po0, ulpi_data0_po1, ulpi_data1_po2,
+    ulpi_data2_po3, ulpi_data3_po4, ulpi_data4_po5, ulpi_data5_po6,
+    ulpi_data6_po7, dap3_fs_pp0, dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3,
+    dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, kb_col0_pq0,
+    kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5,
+    kb_col6_pq6, kb_col7_pq7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2,
+    kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7,
+    kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4,
+    kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, vi_pclk_pt0, vi_mclk_pt1,
+    vi_d10_pt2, vi_d11_pt3, vi_d0_pt4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6,
+    sdmmc4_cmd_pt7, pu0, pu1, pu2, pu3, pu4, pu5, pu6, jtag_rtck_pu7, pv0,
+    pv1, pv2, pv3, ddc_scl_pv4, ddc_sda_pv5, crt_hsync_pv6, crt_vsync_pv7,
+    lcd_cs1_n_pw0, lcd_m1_pw1, spi2_cs1_n_pw2, spi2_cs2_n_pw3, clk1_out_pw4,
+    clk2_out_pw5, uart3_txd_pw6, uart3_rxd_pw7, spi2_mosi_px0, spi2_miso_px1,
+    spi2_sck_px2, spi2_cs0_n_px3, spi1_mosi_px4, spi1_sck_px5, spi1_cs0_n_px6,
+    spi1_miso_px7, ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3,
+    sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6, sdmmc1_dat0_py7,
+    sdmmc1_clk_pz0, sdmmc1_cmd_pz1, lcd_sdin_pz2, lcd_wr_n_pz3, lcd_sck_pz4,
+    sys_clk_req_pz5, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, sdmmc4_dat0_paa0,
+    sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4,
+    sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, pbb0,
+    cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7,
+    cam_mclk_pcc0, pcc1, pcc2, sdmmc4_rst_n_pcc3, sdmmc4_clk_pcc4,
+    clk2_req_pcc5, pex_l2_rst_n_pcc6, pex_l2_clkreq_n_pcc7,
+    pex_l0_prsnt_n_pdd0, pex_l0_rst_n_pdd1, pex_l0_clkreq_n_pdd2,
+    pex_wake_n_pdd3, pex_l1_prsnt_n_pdd4, pex_l1_rst_n_pdd5,
+    pex_l1_clkreq_n_pdd6, pex_l2_prsnt_n_pdd7, clk3_out_pee0, clk3_req_pee1,
+    clk1_req_pee2, hdmi_cec_pee3, clk_32k_in, core_pwr_req, cpu_pwr_req, owr,
+    pwr_int_n.
+
+  drive groups:
+
+    These all support nvidia,pull-down-strength, nvidia,pull-up-strength,
+    nvidia,slew_rate-rising, nvidia,slew_rate-falling. Most but not all
+    support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode.
+
+    ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, cec, crt, csus, dap1,
+    dap2, dap3, dap4, dbg, ddc, dev3, gma, gmb, gmc, gmd, gme, gmf, gmg,
+    gmh, gpv, lcd1, lcd2, owr, sdio1, sdio2, sdio3, spi, uaa, uab, uart2,
+    uart3, uda, vi1.
+
+Example:
+
+        pinctrl@70000000 {
+                compatible = "nvidia,tegra30-pinmux";
+                reg = < 0x70000868 0xd0     /* Pad control registers */
+                        0x70003000 0x3e0 >; /* Mux registers */
+        };
+
+Example board file extract:
+
+        pinctrl@70000000 {
+                sdmmc4_default: pinmux {
+                        sdmmc4_clk_pcc4 {
+                                nvidia,pins =   "sdmmc4_clk_pcc4",
+                                                "sdmmc4_rst_n_pcc3";
+                                nvidia,function = "sdmmc4";
+                                nvidia,pull = <0>;
+                                nvidia,tristate = <0>;
+                        };
+                        sdmmc4_dat0_paa0 {
+                                nvidia,pins =   "sdmmc4_dat0_paa0",
+                                                "sdmmc4_dat1_paa1",
+                                                "sdmmc4_dat2_paa2",
+                                                "sdmmc4_dat3_paa3",
+                                                "sdmmc4_dat4_paa4",
+                                                "sdmmc4_dat5_paa5",
+                                                "sdmmc4_dat6_paa6",
+                                                "sdmmc4_dat7_paa7";
+                                nvidia,function = "sdmmc4";
+                                nvidia,pull = <2>;
+                                nvidia,tristate = <0>;
+                        };
+                };
+        };
+
+        sdhci@78000400 {
+                pinctrl-names = "default";
+                pinctrl-0 = <&sdmmc4_default>;
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
new file mode 100644
index 000000000000..c95ea8278f87
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -0,0 +1,128 @@
+== Introduction ==
+
+Hardware modules that control pin multiplexing or configuration parameters
+such as pull-up/down, tri-state, drive-strength etc are designated as pin
+controllers. Each pin controller must be represented as a node in device tree,
+just like any other hardware module.
+
+Hardware modules whose signals are affected by pin configuration are
+designated client devices. Again, each client device must be represented as a
+node in device tree, just like any other hardware module.
+
+For a client device to operate correctly, certain pin controllers must
+set up certain specific pin configurations. Some client devices need a
+single static pin configuration, e.g. set up during initialization. Others
+need to reconfigure pins at run-time, for example to tri-state pins when the
+device is inactive. Hence, each client device can define a set of named
+states. The number and names of those states is defined by the client device's
+own binding.
+
+The common pinctrl bindings defined in this file provide an infrastructure
+for client device device tree nodes to map those state names to the pin
+configuration used by those states.
+
+Note that pin controllers themselves may also be client devices of themselves.
+For example, a pin controller may set up its own "active" state when the
+driver loads. This would allow representing a board's static pin configuration
+in a single place, rather than splitting it across multiple client device
+nodes. The decision to do this or not somewhat rests with the author of
+individual board device tree files, and any requirements imposed by the
+bindings for the individual client devices in use by that board, i.e. whether
+they require certain specific named states for dynamic pin configuration.
+
+== Pinctrl client devices ==
+
+For each client device individually, every pin state is assigned an integer
+ID. These numbers start at 0, and are contiguous. For each state ID, a unique
+property exists to define the pin configuration. Each state may also be
+assigned a name. When names are used, another property exists to map from
+those names to the integer IDs.
+
+Each client device's own binding determines the set of states the must be
+defined in its device tree node, and whether to define the set of state
+IDs that must be provided, or whether to define the set of state names that
+must be provided.
+
+Required properties:
+pinctrl-0:      List of phandles, each pointing at a pin configuration
+                node. These referenced pin configuration nodes must be child
+                nodes of the pin controller that they configure. Multiple
+                entries may exist in this list so that multiple pin
+                controllers may be configured, or so that a state may be built
+                from multiple nodes for a single pin controller, each
+                contributing part of the overall configuration. See the next
+                section of this document for details of the format of these
+                pin configuration nodes.
+
+                In some cases, it may be useful to define a state, but for it
+                to be empty. This may be required when a common IP block is
+                used in an SoC either without a pin controller, or where the
+                pin controller does not affect the HW module in question. If
+                the binding for that IP block requires certain pin states to
+                exist, they must still be defined, but may be left empty.
+
+Optional properties:
+pinctrl-1:      List of phandles, each pointing at a pin configuration
+                node within a pin controller.
+...
+pinctrl-n:      List of phandles, each pointing at a pin configuration
+                node within a pin controller.
+pinctrl-names:  The list of names to assign states. List entry 0 defines the
+                name for integer state ID 0, list entry 1 for state ID 1, and
+                so on.
+
+For example:
+
+        /* For a client device requiring named states */
+        device {
+                pinctrl-names = "active", "idle";
+                pinctrl-0 = <&state_0_node_a>;
+                pinctrl-1 = <&state_1_node_a &state_1_node_b>;
+        };
+
+        /* For the same device if using state IDs */
+        device {
+                pinctrl-0 = <&state_0_node_a>;
+                pinctrl-1 = <&state_1_node_a &state_1_node_b>;
+        };
+
+        /*
+         * For an IP block whose binding supports pin configuration,
+         * but in use on an SoC that doesn't have any pin control hardware
+         */
+        device {
+                pinctrl-names = "active", "idle";
+                pinctrl-0 = <>;
+                pinctrl-1 = <>;
+        };
+
+== Pin controller devices ==
+
+Pin controller devices should contain the pin configuration nodes that client
+devices reference.
+
+For example:
+
+        pincontroller {
+                ... /* Standard DT properties for the device itself elided */
+
+                state_0_node_a {
+                        ...
+                };
+                state_1_node_a {
+                        ...
+                };
+                state_1_node_b {
+                        ...
+                };
+        }
+
+The contents of each of those pin configuration child nodes is defined
+entirely by the binding for the individual pin controller device. There
+exists no common standard for this content.
+
+The pin configuration nodes need not be direct children of the pin controller
+device; they may be grandchildren, for example. Whether this is legal, and
+whether there is any interaction between the child and intermediate parent
+nodes, is again defined entirely by the binding for the individual pin
+controller device.
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl_spear.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl_spear.txt
new file mode 100644
index 000000000000..b4480d5c3aca
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl_spear.txt
@@ -0,0 +1,155 @@
+ST Microelectronics, SPEAr pinmux controller
+
+Required properties:
+- compatible    : "st,spear300-pinmux"
+                : "st,spear310-pinmux"
+                : "st,spear320-pinmux"
+                : "st,spear1310-pinmux"
+                : "st,spear1340-pinmux"
+- reg           : Address range of the pinctrl registers
+- st,pinmux-mode: Mandatory for SPEAr300 and SPEAr320 and invalid for others.
+        - Its values for SPEAr300:
+                - NAND_MODE             : <0>
+                - NOR_MODE              : <1>
+                - PHOTO_FRAME_MODE      : <2>
+                - LEND_IP_PHONE_MODE    : <3>
+                - HEND_IP_PHONE_MODE    : <4>
+                - LEND_WIFI_PHONE_MODE  : <5>
+                - HEND_WIFI_PHONE_MODE  : <6>
+                - ATA_PABX_WI2S_MODE    : <7>
+                - ATA_PABX_I2S_MODE     : <8>
+                - CAML_LCDW_MODE        : <9>
+                - CAMU_LCD_MODE         : <10>
+                - CAMU_WLCD_MODE        : <11>
+                - CAML_LCD_MODE         : <12>
+        - Its values for SPEAr320:
+                - AUTO_NET_SMII_MODE    : <0>
+                - AUTO_NET_MII_MODE     : <1>
+                - AUTO_EXP_MODE         : <2>
+                - SMALL_PRINTERS_MODE   : <3>
+                - EXTENDED_MODE         : <4>
+
+Please refer to pinctrl-bindings.txt in this directory for details of the common
+pinctrl bindings used by client devices.
+
+SPEAr's pinmux nodes act as a container for an abitrary number of subnodes. Each
+of these subnodes represents muxing for a pin, a group, or a list of pins or
+groups.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Required subnode-properties:
+- st,pins : An array of strings. Each string contains the name of a pin or
+  group.
+- st,function: A string containing the name of the function to mux to the pin or
+  group. See the SPEAr's TRM to determine which are valid for each pin or group.
+
+  Valid values for group and function names can be found from looking at the
+  group and function arrays in driver files:
+  drivers/pinctrl/spear/pinctrl-spear3*0.c
+
+Valid values for group names are:
+For All SPEAr3xx machines:
+        "firda_grp", "i2c0_grp", "ssp_cs_grp", "ssp0_grp", "mii0_grp",
+        "gpio0_pin0_grp", "gpio0_pin1_grp", "gpio0_pin2_grp", "gpio0_pin3_grp",
+        "gpio0_pin4_grp", "gpio0_pin5_grp", "uart0_ext_grp", "uart0_grp",
+        "timer_0_1_grp", timer_0_1_pins, "timer_2_3_grp"
+
+For SPEAr300 machines:
+        "fsmc_2chips_grp", "fsmc_4chips_grp", "clcd_lcdmode_grp",
+        "clcd_pfmode_grp", "tdm_grp", "i2c_clk_grp_grp", "caml_grp", "camu_grp",
+        "dac_grp", "i2s_grp", "sdhci_4bit_grp", "sdhci_8bit_grp",
+        "gpio1_0_to_3_grp", "gpio1_4_to_7_grp"
+
+For SPEAr310 machines:
+        "emi_cs_0_to_5_grp", "uart1_grp", "uart2_grp", "uart3_grp", "uart4_grp",
+        "uart5_grp", "fsmc_grp", "rs485_0_grp", "rs485_1_grp", "tdm_grp"
+
+For SPEAr320 machines:
+        "clcd_grp", "emi_grp", "fsmc_8bit_grp", "fsmc_16bit_grp", "spp_grp",
+        "sdhci_led_grp", "sdhci_cd_12_grp", "sdhci_cd_51_grp", "i2s_grp",
+        "uart1_grp", "uart1_modem_2_to_7_grp", "uart1_modem_31_to_36_grp",
+        "uart1_modem_34_to_45_grp", "uart1_modem_80_to_85_grp", "uart2_grp",
+        "uart3_8_9_grp", "uart3_15_16_grp", "uart3_41_42_grp",
+        "uart3_52_53_grp", "uart3_73_74_grp", "uart3_94_95_grp",
+        "uart3_98_99_grp", "uart4_6_7_grp", "uart4_13_14_grp",
+        "uart4_39_40_grp", "uart4_71_72_grp", "uart4_92_93_grp",
+        "uart4_100_101_grp", "uart5_4_5_grp", "uart5_37_38_grp",
+        "uart5_69_70_grp", "uart5_90_91_grp", "uart6_2_3_grp",
+        "uart6_88_89_grp", "rs485_grp", "touchscreen_grp", "can0_grp",
+        "can1_grp", "pwm0_1_pin_8_9_grp", "pwm0_1_pin_14_15_grp",
+        "pwm0_1_pin_30_31_grp", "pwm0_1_pin_37_38_grp", "pwm0_1_pin_42_43_grp",
+        "pwm0_1_pin_59_60_grp", "pwm0_1_pin_88_89_grp", "pwm2_pin_7_grp",
+        "pwm2_pin_13_grp", "pwm2_pin_29_grp", "pwm2_pin_34_grp",
+        "pwm2_pin_41_grp", "pwm2_pin_58_grp", "pwm2_pin_87_grp",
+        "pwm3_pin_6_grp", "pwm3_pin_12_grp", "pwm3_pin_28_grp",
+        "pwm3_pin_40_grp", "pwm3_pin_57_grp", "pwm3_pin_86_grp",
+        "ssp1_17_20_grp", "ssp1_36_39_grp", "ssp1_48_51_grp", "ssp1_65_68_grp",
+        "ssp1_94_97_grp", "ssp2_13_16_grp", "ssp2_32_35_grp", "ssp2_44_47_grp",
+        "ssp2_61_64_grp", "ssp2_90_93_grp", "mii2_grp", "smii0_1_grp",
+        "rmii0_1_grp", "i2c1_8_9_grp", "i2c1_98_99_grp", "i2c2_0_1_grp",
+        "i2c2_2_3_grp", "i2c2_19_20_grp", "i2c2_75_76_grp", "i2c2_96_97_grp"
+
+For SPEAr1310 machines:
+        "i2c0_grp", "ssp0_grp", "ssp0_cs0_grp", "ssp0_cs1_2_grp", "i2s0_grp",
+        "i2s1_grp", "clcd_grp", "clcd_high_res_grp", "arm_gpio_grp",
+        "smi_2_chips_grp", "smi_4_chips_grp", "gmii_grp", "rgmii_grp",
+        "smii_0_1_2_grp", "ras_mii_txclk_grp", "nand_8bit_grp",
+        "nand_16bit_grp", "nand_4_chips_grp", "keyboard_6x6_grp",
+        "keyboard_rowcol6_8_grp", "uart0_grp", "uart0_modem_grp",
+        "gpt0_tmr0_grp", "gpt0_tmr1_grp", "gpt1_tmr0_grp", "gpt1_tmr1_grp",
+        "sdhci_grp", "cf_grp", "xd_grp", "touch_xy_grp",
+        "uart1_disable_i2c_grp", "uart1_disable_sd_grp", "uart2_3_grp",
+        "uart4_grp", "uart5_grp", "rs485_0_1_tdm_0_1_grp", "i2c_1_2_grp",
+        "i2c3_dis_smi_clcd_grp", "i2c3_dis_sd_i2s0_grp", "i2c_4_5_dis_smi_grp",
+        "i2c4_dis_sd_grp", "i2c5_dis_sd_grp", "i2c_6_7_dis_kbd_grp",
+        "i2c6_dis_sd_grp", "i2c7_dis_sd_grp", "can0_dis_nor_grp",
+        "can0_dis_sd_grp", "can1_dis_sd_grp", "can1_dis_kbd_grp", "pcie0_grp",
+        "pcie1_grp", "pcie2_grp", "sata0_grp", "sata1_grp", "sata2_grp",
+        "ssp1_dis_kbd_grp", "ssp1_dis_sd_grp", "gpt64_grp"
+
+For SPEAr1340 machines:
+        "pads_as_gpio_grp", "fsmc_8bit_grp", "fsmc_16bit_grp", "fsmc_pnor_grp",
+        "keyboard_row_col_grp", "keyboard_col5_grp", "spdif_in_grp",
+        "spdif_out_grp", "gpt_0_1_grp", "pwm0_grp", "pwm1_grp", "pwm2_grp",
+        "pwm3_grp", "vip_mux_grp", "vip_mux_cam0_grp", "vip_mux_cam1_grp",
+        "vip_mux_cam2_grp", "vip_mux_cam3_grp", "cam0_grp", "cam1_grp",
+        "cam2_grp", "cam3_grp", "smi_grp", "ssp0_grp", "ssp0_cs1_grp",
+        "ssp0_cs2_grp", "ssp0_cs3_grp", "uart0_grp", "uart0_enh_grp",
+        "uart1_grp", "i2s_in_grp", "i2s_out_grp", "gmii_grp", "rgmii_grp",
+        "rmii_grp", "sgmii_grp", "i2c0_grp", "i2c1_grp", "cec0_grp", "cec1_grp",
+        "sdhci_grp", "cf_grp", "xd_grp", "clcd_grp", "arm_trace_grp",
+        "miphy_dbg_grp", "pcie_grp", "sata_grp"
+
+Valid values for function names are:
+For All SPEAr3xx machines:
+        "firda", "i2c0", "ssp_cs", "ssp0", "mii0", "gpio0", "uart0_ext",
+        "uart0", "timer_0_1", "timer_2_3"
+
+For SPEAr300 machines:
+        "fsmc", "clcd", "tdm", "i2c1", "cam", "dac", "i2s", "sdhci", "gpio1"
+
+For SPEAr310 machines:
+        "emi", "uart1", "uart2", "uart3", "uart4", "uart5", "fsmc", "rs485_0",
+        "rs485_1", "tdm"
+
+For SPEAr320 machines:
+        "clcd", "emi", "fsmc", "spp", "sdhci", "i2s", "uart1", "uart1_modem",
+        "uart2", "uart3", "uart4", "uart5", "uart6", "rs485", "touchscreen",
+        "can0", "can1", "pwm0_1", "pwm2", "pwm3", "ssp1", "ssp2", "mii2",
+        "mii0_1", "i2c1", "i2c2"
+
+
+For SPEAr1310 machines:
+        "i2c0", "ssp0", "i2s0", "i2s1", "clcd", "arm_gpio", "smi", "gmii",
+        "rgmii", "smii_0_1_2", "ras_mii_txclk", "nand", "keyboard", "uart0",
+        "gpt0", "gpt1", "sdhci", "cf", "xd", "touchscreen", "uart1", "uart2_3",
+        "uart4", "uart5", "rs485_0_1_tdm_0_1", "i2c_1_2", "i2c3_i2s1",
+        "i2c_4_5", "i2c_6_7", "can0", "can1", "pci", "sata", "ssp1", "gpt64"
+
+For SPEAr1340 machines:
+        "pads_as_gpio", "fsmc", "keyboard", "spdif_in", "spdif_out", "gpt_0_1",
+        "pwm", "vip", "cam0", "cam1", "cam2", "cam3", "smi", "ssp0", "uart0",
+        "uart1", "i2s", "gmac", "i2c0", "i2c1", "cec0", "cec1", "sdhci", "cf",
+        "xd", "clcd", "arm_trace", "miphy_dbg", "pcie", "sata"
diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
deleted file mode 100644
index 36f82dbdd14d..000000000000
--- a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-NVIDIA Tegra 2 pinmux controller
-
-Required properties:
-- compatible : "nvidia,tegra20-pinmux"
-
diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
index 9cf57fd042d2..2f5b6b1ba15f 100644
--- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
@@ -8,6 +8,8 @@ Optional properties:
 - startup-delay-us: startup time in microseconds
 - enable-active-high: Polarity of GPIO is Active high
 If this property is missing, the default assumed is Active low.
+- gpio-open-drain: GPIO is open drain type.
+  If this property is missing then default assumption is false.
 
 Any property defined as part of the core regulator
 binding, defined in regulator.txt, can also be used.
@@ -25,5 +27,6 @@ Example:
                 gpio = <&gpio1 16 0>;
                 startup-delay-us = <70000>;
                 enable-active-high;
-                regulator-boot-on
+                regulator-boot-on;
+                gpio-open-drain;
         };
diff --git a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt
new file mode 100644
index 000000000000..c8ca6b8f6582
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt
@@ -0,0 +1,44 @@
+TPS62360 Voltage regulators
+
+Required properties:
+- compatible: Must be one of the following.
+        "ti,tps62360"
+        "ti,tps62361",
+        "ti,tps62362",
+        "ti,tps62363",
+- reg: I2C slave address
+
+Optional properties:
+- ti,enable-vout-discharge: Enable output discharge. This is boolean value.
+- ti,enable-pull-down: Enable pull down. This is boolean value.
+- ti,vsel0-gpio: GPIO for controlling VSEL0 line.
+  If this property is missing, then assume that there is no GPIO
+  for vsel0 control.
+- ti,vsel1-gpio: Gpio for controlling VSEL1 line.
+  If this property is missing, then assume that there is no GPIO
+  for vsel1 control.
+- ti,vsel0-state-high: Inital state of vsel0 input is high.
+  If this property is missing, then assume the state as low (0).
+- ti,vsel1-state-high: Inital state of vsel1 input is high.
+  If this property is missing, then assume the state as low (0).
+
+Any property defined as part of the core regulator binding, defined in
+regulator.txt, can also be used.
+
+Example:
+
+        abc: tps62360 {
+                compatible = "ti,tps62361";
+                reg =  <0x60>;
+                regulator-name = "tps62361-vout";
+                regulator-min-microvolt = <500000>;
+                regulator-max-microvolt = <1500000>;
+                regulator-boot-on
+                ti,vsel0-gpio = <&gpio1 16 0>;
+                ti,vsel1-gpio = <&gpio1 17 0>;
+                ti,vsel0-state-high;
+                ti,vsel1-state-high;
+                ti,enable-pull-down;
+                ti,enable-force-pwm;
+                ti,enable-vout-discharge;
+        };
diff --git a/Documentation/devicetree/bindings/regulator/tps6586x.txt b/Documentation/devicetree/bindings/regulator/tps6586x.txt
new file mode 100644
index 000000000000..0fcabaa3baa3
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps6586x.txt
@@ -0,0 +1,97 @@
+TPS6586x family of regulators
+
+Required properties:
+- compatible: "ti,tps6586x"
+- reg: I2C slave address
+- interrupts: the interrupt outputs of the controller
+- #gpio-cells: number of cells to describe a GPIO
+- gpio-controller: mark the device as a GPIO controller
+- regulators: list of regulators provided by this controller, must be named
+  after their hardware counterparts: sm[0-2], ldo[0-9] and ldo_rtc
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+        pmu: tps6586x@34 {
+                compatible = "ti,tps6586x";
+                reg = <0x34>;
+                interrupts = <0 88 0x4>;
+
+                #gpio-cells = <2>;
+                gpio-controller;
+
+                regulators {
+                        sm0_reg: sm0 {
+                                regulator-min-microvolt = < 725000>;
+                                regulator-max-microvolt = <1500000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        sm1_reg: sm1 {
+                                regulator-min-microvolt = < 725000>;
+                                regulator-max-microvolt = <1500000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        sm2_reg: sm2 {
+                                regulator-min-microvolt = <3000000>;
+                                regulator-max-microvolt = <4550000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        ldo0_reg: ldo0 {
+                                regulator-name = "PCIE CLK";
+                                regulator-min-microvolt = <3300000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+
+                        ldo1_reg: ldo1 {
+                                regulator-min-microvolt = < 725000>;
+                                regulator-max-microvolt = <1500000>;
+                        };
+
+                        ldo2_reg: ldo2 {
+                                regulator-min-microvolt = < 725000>;
+                                regulator-max-microvolt = <1500000>;
+                        };
+
+                        ldo3_reg: ldo3 {
+                                regulator-min-microvolt = <1250000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+
+                        ldo4_reg: ldo4 {
+                                regulator-min-microvolt = <1700000>;
+                                regulator-max-microvolt = <2475000>;
+                        };
+
+                        ldo5_reg: ldo5 {
+                                regulator-min-microvolt = <1250000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+
+                        ldo6_reg: ldo6 {
+                                regulator-min-microvolt = <1250000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+
+                        ldo7_reg: ldo7 {
+                                regulator-min-microvolt = <1250000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+
+                        ldo8_reg: ldo8 {
+                                regulator-min-microvolt = <1250000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+
+                        ldo9_reg: ldo9 {
+                                regulator-min-microvolt = <1250000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt b/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
new file mode 100644
index 000000000000..a87a1e9bc060
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt
@@ -0,0 +1,15 @@
+* NXP LPC32xx SoC Real Time Clock controller
+
+Required properties:
+- compatible: must be "nxp,lpc3220-rtc"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: The RTC interrupt
+
+Example:
+
+        rtc@40024000 {
+                compatible = "nxp,lpc3220-rtc";
+                reg = <0x40024000 0x1000>;
+                interrupts = <52 0>;
+        };
diff --git a/Documentation/devicetree/bindings/rtc/spear-rtc.txt b/Documentation/devicetree/bindings/rtc/spear-rtc.txt
new file mode 100644
index 000000000000..ca67ac62108e
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/spear-rtc.txt
@@ -0,0 +1,17 @@
+* SPEAr RTC
+
+Required properties:
+- compatible : "st,spear600-rtc"
+- reg : Address range of the rtc registers
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+- interrupt: Should contain the rtc interrupt number
+
+Example:
+
+        rtc@fc000000 {
+                compatible = "st,spear600-rtc";
+                reg = <0xfc000000 0x1000>;
+                interrupt-parent = <&vic1>;
+                interrupts = <12>;
+        };
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt b/Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt
new file mode 100644
index 000000000000..e4acdd891e49
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt
@@ -0,0 +1,49 @@
+Freescale i.MX audio complex with SGTL5000 codec
+
+Required properties:
+- compatible : "fsl,imx-audio-sgtl5000"
+- model : The user-visible name of this sound complex
+- ssi-controller : The phandle of the i.MX SSI controller
+- audio-codec : The phandle of the SGTL5000 audio codec
+- audio-routing : A list of the connections between audio components.
+  Each entry is a pair of strings, the first being the connection's sink,
+  the second being the connection's source. Valid names could be power
+  supplies, SGTL5000 pins, and the jacks on the board:
+
+  Power supplies:
+   * Mic Bias
+
+  SGTL5000 pins:
+   * MIC_IN
+   * LINE_IN
+   * HP_OUT
+   * LINE_OUT
+
+  Board connectors:
+   * Mic Jack
+   * Line In Jack
+   * Headphone Jack
+   * Line Out Jack
+   * Ext Spk
+
+- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX)
+- mux-ext-port : The external port of the i.MX audio muxer
+
+Note: The AUDMUX port numbering should start at 1, which is consistent with
+hardware manual.
+
+Example:
+
+sound {
+        compatible = "fsl,imx51-babbage-sgtl5000",
+                     "fsl,imx-audio-sgtl5000";
+        model = "imx51-babbage-sgtl5000";
+        ssi-controller = <&ssi1>;
+        audio-codec = <&sgtl5000>;
+        audio-routing =
+                "MIC_IN", "Mic Jack",
+                "Mic Jack", "Mic Bias",
+                "Headphone Jack", "HP_OUT";
+        mux-int-port = <1>;
+        mux-ext-port = <3>;
+};
diff --git a/Documentation/devicetree/bindings/sound/mxs-audio-sgtl5000.txt b/Documentation/devicetree/bindings/sound/mxs-audio-sgtl5000.txt
new file mode 100644
index 000000000000..601c518eddaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mxs-audio-sgtl5000.txt
@@ -0,0 +1,17 @@
+* Freescale MXS audio complex with SGTL5000 codec
+
+Required properties:
+- compatible: "fsl,mxs-audio-sgtl5000"
+- model: The user-visible name of this sound complex
+- saif-controllers: The phandle list of the MXS SAIF controller
+- audio-codec: The phandle of the SGTL5000 audio codec
+
+Example:
+
+sound {
+        compatible = "fsl,imx28-evk-sgtl5000",
+                     "fsl,mxs-audio-sgtl5000";
+        model = "imx28-evk-sgtl5000";
+        saif-controllers = <&saif0 &saif1>;
+        audio-codec = <&sgtl5000>;
+};
diff --git a/Documentation/devicetree/bindings/sound/mxs-saif.txt b/Documentation/devicetree/bindings/sound/mxs-saif.txt
new file mode 100644
index 000000000000..c37ba6143d9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mxs-saif.txt
@@ -0,0 +1,36 @@
+* Freescale MXS Serial Audio Interface (SAIF)
+
+Required properties:
+- compatible: Should be "fsl,<chip>-saif"
+- reg: Should contain registers location and length
+- interrupts: Should contain ERROR and DMA interrupts
+- fsl,saif-dma-channel: APBX DMA channel for the SAIF
+
+Optional properties:
+- fsl,saif-master: phandle to the master SAIF.  It's only required for
+  the slave SAIF.
+
+Note: Each SAIF controller should have an alias correctly numbered
+in "aliases" node.
+
+Example:
+
+aliases {
+        saif0 = &saif0;
+        saif1 = &saif1;
+};
+
+saif0: saif@80042000 {
+        compatible = "fsl,imx28-saif";
+        reg = <0x80042000 2000>;
+        interrupts = <59 80>;
+        fsl,saif-dma-channel = <4>;
+};
+
+saif1: saif@80046000 {
+        compatible = "fsl,imx28-saif";
+        reg = <0x80046000 2000>;
+        interrupts = <58 81>;
+        fsl,saif-dma-channel = <5>;
+        fsl,saif-master = <&saif0>;
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
new file mode 100644
index 000000000000..1ac7b1642186
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
@@ -0,0 +1,32 @@
+NVIDIA Tegra30 AHUB (Audio Hub)
+
+Required properties:
+- compatible : "nvidia,tegra30-ahub"
+- reg : Should contain the register physical address and length for each of
+  the AHUB's APBIF registers and the AHUB's own registers.
+- interrupts : Should contain AHUB interrupt
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+  request selector for the first APBIF channel.
+- 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>;
+- #size-cells : For the configlink bus. Should be <1>.
+
+AHUB client modules need to specify the IDs of their CIFs (Client InterFaces).
+For RX CIFs, the numbers indicate the register number within AHUB routing
+register space (APBIF 0..3 RX, I2S 0..5 RX, DAM 0..2 RX 0..1, SPDIF RX 0..1).
+For TX CIFs, the numbers indicate the bit position within the AHUB routing
+registers (APBIF 0..3 TX, I2S 0..5 TX, DAM 0..2 TX, SPDIF TX 0..1).
+
+Example:
+
+ahub@70080000 {
+        compatible = "nvidia,tegra30-ahub";
+        reg = <0x70080000 0x200 0x70080200 0x100>;
+        interrupts = < 0 103 0x04 >;
+        nvidia,dma-request-selector = <&apbdma 1>;
+
+        ranges;
+        #address-cells = <1>;
+        #size-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt
new file mode 100644
index 000000000000..dfa6c037124a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt
@@ -0,0 +1,15 @@
+NVIDIA Tegra30 I2S controller
+
+Required properties:
+- compatible : "nvidia,tegra30-i2s"
+- reg : Should contain I2S registers location and length
+- nvidia,ahub-cif-ids : The list of AHUB CIF IDs for this port, rx (playback)
+  first, tx (capture) second. See nvidia,tegra30-ahub.txt for values.
+
+Example:
+
+i2s@70002800 {
+        compatible = "nvidia,tegra30-i2s";
+        reg = <0x70080300 0x100>;
+        nvidia,ahub-cif-ids = <4 4>;
+};
diff --git a/Documentation/devicetree/bindings/sound/omap-dmic.txt b/Documentation/devicetree/bindings/sound/omap-dmic.txt
new file mode 100644
index 000000000000..fd8105f18978
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/omap-dmic.txt
@@ -0,0 +1,21 @@
+* Texas Instruments OMAP4+ Digital Microphone Module
+
+Required properties:
+- compatible: "ti,omap4-dmic"
+- reg: Register location and size as an array:
+       <MPU access base address, size>,
+       <L3 interconnect address, size>;
+- interrupts: Interrupt number for DMIC
+- interrupt-parent: The parent interrupt controller
+- ti,hwmods: Name of the hwmod associated with OMAP dmic IP
+
+Example:
+
+dmic: dmic@4012e000 {
+        compatible = "ti,omap4-dmic";
+        reg = <0x4012e000 0x7f>, /* MPU private access */
+              <0x4902e000 0x7f>; /* L3 Interconnect */
+        interrupts = <0 114 0x4>;
+        interrupt-parent = <&gic>;
+        ti,hwmods = "dmic";
+};
diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
new file mode 100644
index 000000000000..0741dff048dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
@@ -0,0 +1,21 @@
+* Texas Instruments OMAP4+ McPDM
+
+Required properties:
+- compatible: "ti,omap4-mcpdm"
+- reg: Register location and size as an array:
+       <MPU access base address, size>,
+       <L3 interconnect address, size>;
+- interrupts: Interrupt number for McPDM
+- interrupt-parent: The parent interrupt controller
+- ti,hwmods: Name of the hwmod associated to the McPDM
+
+Example:
+
+mcpdm: mcpdm@40132000 {
+        compatible = "ti,omap4-mcpdm";
+        reg = <0x40132000 0x7f>, /* MPU private access */
+              <0x49032000 0x7f>; /* L3 Interconnect */
+        interrupts = <0 112 0x4>;
+        interrupt-parent = <&gic>;
+        ti,hwmods = "mcpdm";
+};
diff --git a/Documentation/devicetree/bindings/sound/tegra-audio-trimslice.txt b/Documentation/devicetree/bindings/sound/tegra-audio-trimslice.txt
new file mode 100644
index 000000000000..04b14cfb1f16
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tegra-audio-trimslice.txt
@@ -0,0 +1,14 @@
+NVIDIA Tegra audio complex for TrimSlice
+
+Required properties:
+- compatible : "nvidia,tegra-audio-trimslice"
+- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller
+- nvidia,audio-codec : The phandle of the WM8903 audio codec
+
+Example:
+
+sound {
+        compatible = "nvidia,tegra-audio-trimslice";
+        nvidia,i2s-controller = <&tegra_i2s1>;
+        nvidia,audio-codec = <&codec>;
+};
diff --git a/Documentation/devicetree/bindings/sound/tegra-audio-wm8753.txt b/Documentation/devicetree/bindings/sound/tegra-audio-wm8753.txt
new file mode 100644
index 000000000000..c4dd39ce6165
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tegra-audio-wm8753.txt
@@ -0,0 +1,54 @@
+NVIDIA Tegra audio complex
+
+Required properties:
+- compatible : "nvidia,tegra-audio-wm8753"
+- 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,
+  the second being the connection's source. Valid names for sources and
+  sinks are the WM8753's pins, and the jacks on the board:
+
+  WM8753 pins:
+
+  * LOUT1
+  * LOUT2
+  * ROUT1
+  * ROUT2
+  * MONO1
+  * MONO2
+  * OUT3
+  * OUT4
+  * LINE1
+  * LINE2
+  * RXP
+  * RXN
+  * ACIN
+  * ACOP
+  * MIC1N
+  * MIC1
+  * MIC2N
+  * MIC2
+  * Mic Bias
+
+  Board connectors:
+
+  * Headphone Jack
+  * Mic Jack
+
+- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller
+- nvidia,audio-codec : The phandle of the WM8753 audio codec
+Example:
+
+sound {
+        compatible = "nvidia,tegra-audio-wm8753-whistler",
+                     "nvidia,tegra-audio-wm8753"
+        nvidia,model = "tegra-wm8753-harmony";
+
+        nvidia,audio-routing =
+                "Headphone Jack", "LOUT1",
+                "Headphone Jack", "ROUT1";
+
+        nvidia,i2s-controller = <&i2s1>;
+        nvidia,audio-codec = <&wm8753>;
+};
+
diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
index 9841057d112b..4256a6df9b79 100644
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
@@ -17,6 +17,6 @@ ecspi@70010000 {
         reg = <0x70010000 0x4000>;
         interrupts = <36>;
         fsl,spi-num-chipselects = <2>;
-        cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
-                   <&gpio3 25 0>; /* GPIO4_25 */
+        cs-gpios = <&gpio3 24 0>, /* GPIO3_24 */
+                   <&gpio3 25 0>; /* GPIO3_25 */
 };
diff --git a/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt b/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt
new file mode 100644
index 000000000000..b3629d3a9adf
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt
@@ -0,0 +1,16 @@
+* NXP LPC32xx SoC ADC controller
+
+Required properties:
+- compatible: must be "nxp,lpc3220-adc"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: The ADC interrupt
+
+Example:
+
+        adc@40048000 {
+                compatible = "nxp,lpc3220-adc";
+                reg = <0x40048000 0x1000>;
+                interrupt-parent = <&mic>;
+                interrupts = <39 0>;
+        };
diff --git a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
new file mode 100644
index 000000000000..02ea23a63f20
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
@@ -0,0 +1,26 @@
+* ST SPEAr ADC device driver
+
+Required properties:
+- compatible: Should be "st,spear600-adc"
+- reg: Address and length of the register set for the device
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+- interrupts: Should contain the ADC interrupt
+- sampling-frequency: Default sampling frequency
+
+Optional properties:
+- vref-external: External voltage reference in milli-volts. If omitted
+  the internal voltage reference will be used.
+- average-samples: Number of samples to generate an average value. If
+  omitted, single data conversion will be used.
+
+Examples:
+
+        adc: adc@d8200000 {
+                compatible = "st,spear600-adc";
+                reg = <0xd8200000 0x1000>;
+                interrupt-parent = <&vic1>;
+                interrupts = <6>;
+                sampling-frequency = <5000000>;
+                vref-external = <2500>; /* 2.5V VRef */
+        };
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
index a9c0406280e8..b462d0c54823 100644
--- a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
@@ -11,7 +11,7 @@ Optional properties:
 
 Example:
 
-uart@73fbc000 {
+serial@73fbc000 {
         compatible = "fsl,imx51-uart", "fsl,imx21-uart";
         reg = <0x73fbc000 0x4000>;
         interrupts = <31>;
diff --git a/Documentation/devicetree/bindings/usb/isp1301.txt b/Documentation/devicetree/bindings/usb/isp1301.txt
new file mode 100644
index 000000000000..5405d99d9aaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/isp1301.txt
@@ -0,0 +1,25 @@
+* NXP ISP1301 USB transceiver
+
+Required properties:
+- compatible: must be "nxp,isp1301"
+- reg: I2C address of the ISP1301 device
+
+Optional properties of devices using ISP1301:
+- transceiver: phandle of isp1301 - this helps the ISP1301 driver to find the
+               ISP1301 instance associated with the respective USB driver
+
+Example:
+
+        isp1301: usb-transceiver@2c {
+                compatible = "nxp,isp1301";
+                reg = <0x2c>;
+        };
+
+        usbd@31020000 {
+                compatible = "nxp,lpc3220-udc";
+                reg = <0x31020000 0x300>;
+                interrupt-parent = <&mic>;
+                interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
+                transceiver = <&isp1301>;
+                status = "okay";
+        };
diff --git a/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt b/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt
new file mode 100644
index 000000000000..29f12a533f66
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt
@@ -0,0 +1,28 @@
+* NXP LPC32xx SoC USB Device Controller (UDC)
+
+Required properties:
+- compatible: Must be "nxp,lpc3220-udc"
+- reg: Physical base address of the controller and length of memory mapped
+  region.
+- interrupts: The USB interrupts:
+              * USB Device Low Priority Interrupt
+              * USB Device High Priority Interrupt
+              * USB Device DMA Interrupt
+              * External USB Transceiver Interrupt (OTG ATX)
+- transceiver: phandle of the associated ISP1301 device - this is necessary for
+               the UDC controller for connecting to the USB physical layer
+
+Example:
+
+        isp1301: usb-transceiver@2c {
+                compatible = "nxp,isp1301";
+                reg = <0x2c>;
+        };
+
+        usbd@31020000 {
+                compatible = "nxp,lpc3220-udc";
+                reg = <0x31020000 0x300>;
+                interrupt-parent = <&mic>;
+                interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>;
+                transceiver = <&isp1301>;
+        };
diff --git a/Documentation/devicetree/bindings/usb/ohci-nxp.txt b/Documentation/devicetree/bindings/usb/ohci-nxp.txt
new file mode 100644
index 000000000000..71e28c1017ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ohci-nxp.txt
@@ -0,0 +1,24 @@
+* OHCI controller, NXP ohci-nxp variant
+
+Required properties:
+- compatible: must be "nxp,ohci-nxp"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: The OHCI interrupt
+- transceiver: phandle of the associated ISP1301 device - this is necessary for
+               the UDC controller for connecting to the USB physical layer
+
+Example (LPC32xx):
+
+        isp1301: usb-transceiver@2c {
+                compatible = "nxp,isp1301";
+                reg = <0x2c>;
+        };
+
+        ohci@31020000 {
+                compatible = "nxp,ohci-nxp";
+                reg = <0x31020000 0x300>;
+                interrupt-parent = <&mic>;
+                interrupts = <0x3b 0>;
+                transceiver = <&isp1301>;
+        };
diff --git a/Documentation/devicetree/bindings/usb/spear-usb.txt b/Documentation/devicetree/bindings/usb/spear-usb.txt
new file mode 100644
index 000000000000..f8a464a25653
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/spear-usb.txt
@@ -0,0 +1,39 @@
+ST SPEAr SoC USB controllers:
+-----------------------------
+
+EHCI:
+-----
+
+Required properties:
+- compatible: "st,spear600-ehci"
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+- interrupts: Should contain the EHCI interrupt
+
+Example:
+
+        ehci@e1800000 {
+                compatible = "st,spear600-ehci", "usb-ehci";
+                reg = <0xe1800000 0x1000>;
+                interrupt-parent = <&vic1>;
+                interrupts = <27>;
+        };
+
+
+OHCI:
+-----
+
+Required properties:
+- compatible: "st,spear600-ohci"
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+- interrupts: Should contain the OHCI interrupt
+
+Example:
+
+        ohci@e1900000 {
+                compatible = "st,spear600-ohci", "usb-ohci";
+                reg = <0xe1800000 0x1000>;
+                interrupt-parent = <&vic1>;
+                interrupts = <26>;
+        };
diff --git a/Documentation/devicetree/bindings/usb/tegra-usb.txt b/Documentation/devicetree/bindings/usb/tegra-usb.txt
index 007005ddbe12..e9b005dc7625 100644
--- a/Documentation/devicetree/bindings/usb/tegra-usb.txt
+++ b/Documentation/devicetree/bindings/usb/tegra-usb.txt
@@ -12,6 +12,9 @@ Required properties :
  - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
    activated for the bus to be powered.
 
+Required properties for phy_type == ulpi:
+  - nvidia,phy-reset-gpio : The GPIO used to reset the PHY.
+
 Optional properties:
   - dr_mode : dual role mode. Indicates the working mode for
    nvidia,tegra20-ehci compatible controllers.  Can be "host", "peripheral",
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 82ac057a24a9..db4d3af3643c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -3,16 +3,19 @@ Device tree binding vendor prefix registry.  Keep list in alphabetical order.
 This isn't an exhaustive list, but you should add new prefixes to it before
 using them to avoid name-space collisions.
 
+ad      Avionic Design GmbH
 adi     Analog Devices, Inc.
 amcc    Applied Micro Circuits Corporation (APM, formally AMCC)
 apm     Applied Micro Circuits Corporation (APM)
 arm     ARM Ltd.
 atmel   Atmel Corporation
+bosch   Bosch Sensortec GmbH
 cavium  Cavium, Inc.
 chrp    Common Hardware Reference Platform
 cortina Cortina Systems, Inc.
 dallas  Maxim Integrated Products (formerly Dallas Semiconductor)
 denx    Denx Software Engineering
+emmicro EM Microelectronic
 epson   Seiko Epson Corp.
 est     ESTeem Wireless Modems
 fsl     Freescale Semiconductor
diff --git a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
new file mode 100644
index 000000000000..7c7f6887c796
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt
@@ -0,0 +1,13 @@
+* NXP PNX watchdog timer
+
+Required properties:
+- compatible: must be "nxp,pnx4008-wdt"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+Example:
+
+        watchdog@4003C000 {
+                compatible = "nxp,pnx4008-wdt";
+                reg = <0x4003C000 0x1000>;
+        };
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
index da0bfeb4253d..d4d66757354e 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -551,12 +551,13 @@ Here is an example of a simple device-tree. In this example, an "o"
 designates a node followed by the node unit name. Properties are
 presented with their name followed by their content. "content"
 represents an ASCII string (zero terminated) value, while <content>
-represents a 32-bit hexadecimal value. The various nodes in this
-example will be discussed in a later chapter. At this point, it is
-only meant to give you a idea of what a device-tree looks like. I have
-purposefully kept the "name" and "linux,phandle" properties which
-aren't necessary in order to give you a better idea of what the tree
-looks like in practice.
+represents a 32-bit value, specified in decimal or hexadecimal (the
+latter prefixed 0x). The various nodes in this example will be
+discussed in a later chapter. At this point, it is only meant to give
+you a idea of what a device-tree looks like. I have purposefully kept
+the "name" and "linux,phandle" properties which aren't necessary in
+order to give you a better idea of what the tree looks like in
+practice.
 
   / o device-tree
       |- name = "device-tree"
@@ -576,14 +577,14 @@ looks like in practice.
       |   |- name = "PowerPC,970"
       |   |- device_type = "cpu"
       |   |- reg = <0>
-      |   |- clock-frequency = <5f5e1000>
+      |   |- clock-frequency = <0x5f5e1000>
       |   |- 64-bit
       |   |- linux,phandle = <2>
       |
       o memory@0
       | |- name = "memory"
       | |- device_type = "memory"
-      | |- reg = <00000000 00000000 00000000 20000000>
+      | |- reg = <0x00000000 0x00000000 0x00000000 0x20000000>
       | |- linux,phandle = <3>
       |
       o chosen
@@ -1010,8 +1011,8 @@ compatibility.
                 #size-cells = <1>;
                 #interrupt-cells = <2>;
                 device_type = "soc";
-                ranges = <00000000 e0000000 00100000>
-                reg = <e0000000 00003000>;
+                ranges = <0x00000000 0xe0000000 0x00100000>
+                reg = <0xe0000000 0x00003000>;
                 bus-frequency = <0>;
         }
 
@@ -1085,16 +1086,16 @@ supported currently at the toplevel.
                                  * terminated string
                                  */
 
-  property2 = <1234abcd>;       /* define a property containing a
+  property2 = <0x1234abcd>;     /* define a property containing a
                                  * numerical 32-bit value (hexadecimal)
                                  */
 
-  property3 = <12345678 12345678 deadbeef>;
+  property3 = <0x12345678 0x12345678 0xdeadbeef>;
                                 /* define a property containing 3
                                  * numerical 32-bit values (cells) in
                                  * hexadecimal
                                  */
-  property4 = [0a 0b 0c 0d de ea ad be ef];
+  property4 = [0x0a 0x0b 0x0c 0x0d 0xde 0xea 0xad 0xbe 0xef];
                                 /* define a property whose content is
                                  * an arbitrary array of bytes
                                  */
@@ -1350,10 +1351,10 @@ Appendix A - Sample SOC node for MPC8540
                         model = "TSEC";
                         compatible = "gianfar", "simple-bus";
                         reg = <0x24000 0x1000>;
-                        local-mac-address = [ 00 E0 0C 00 73 00 ];
-                        interrupts = <29 2 30 2 34 2>;
+                        local-mac-address = [ 0x00 0xE0 0x0C 0x00 0x73 0x00 ];
+                        interrupts = <0x29 2 0x30 2 0x34 2>;
                         phy-handle = <&phy0>;
-                        sleep = <&pmc 00000080>;
+                        sleep = <&pmc 0x00000080>;
                         ranges;
 
                         mdio@24520 {
@@ -1385,10 +1386,10 @@ Appendix A - Sample SOC node for MPC8540
                         model = "TSEC";
                         compatible = "gianfar";
                         reg = <0x25000 0x1000>;
-                        local-mac-address = [ 00 E0 0C 00 73 01 ];
-                        interrupts = <13 2 14 2 18 2>;
+                        local-mac-address = [ 0x00 0xE0 0x0C 0x00 0x73 0x01 ];
+                        interrupts = <0x13 2 0x14 2 0x18 2>;
                         phy-handle = <&phy1>;
-                        sleep = <&pmc 00000040>;
+                        sleep = <&pmc 0x00000040>;
                 };
 
                 ethernet@26000 {
@@ -1396,17 +1397,17 @@ Appendix A - Sample SOC node for MPC8540
                         model = "FEC";
                         compatible = "gianfar";
                         reg = <0x26000 0x1000>;
-                        local-mac-address = [ 00 E0 0C 00 73 02 ];
-                        interrupts = <41 2>;
+                        local-mac-address = [ 0x00 0xE0 0x0C 0x00 0x73 0x02 ];
+                        interrupts = <0x41 2>;
                         phy-handle = <&phy3>;
-                        sleep = <&pmc 00000020>;
+                        sleep = <&pmc 0x00000020>;
                 };
 
                 serial@4500 {
                         #address-cells = <1>;
                         #size-cells = <1>;
                         compatible = "fsl,mpc8540-duart", "simple-bus";
-                        sleep = <&pmc 00000002>;
+                        sleep = <&pmc 0x00000002>;
                         ranges;
 
                         serial@4500 {
@@ -1414,7 +1415,7 @@ Appendix A - Sample SOC node for MPC8540
                                 compatible = "ns16550";
                                 reg = <0x4500 0x100>;
                                 clock-frequency = <0>;
-                                interrupts = <42 2>;
+                                interrupts = <0x42 2>;
                         };
 
                         serial@4600 {
@@ -1422,7 +1423,7 @@ Appendix A - Sample SOC node for MPC8540
                                 compatible = "ns16550";
                                 reg = <0x4600 0x100>;
                                 clock-frequency = <0>;
-                                interrupts = <42 2>;
+                                interrupts = <0x42 2>;
                         };
                 };
 
@@ -1436,11 +1437,11 @@ Appendix A - Sample SOC node for MPC8540
                 };
 
                 i2c@3000 {
-                        interrupts = <43 2>;
+                        interrupts = <0x43 2>;
                         reg = <0x3000 0x100>;
                         compatible  = "fsl-i2c";
                         dfsrr;
-                        sleep = <&pmc 00000004>;
+                        sleep = <&pmc 0x00000004>;
                 };
 
                 pmc: power@e0070 {
diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt
index 3bbd5c51605a..ad86fb86c9a0 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -29,13 +29,6 @@ The buffer-user
    in memory, mapped into its own address space, so it can access the same area
    of memory.
 
-*IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details]
-For this first version, A buffer shared using the dma_buf sharing API:
-- *may* be exported to user space using "mmap" *ONLY* by exporter, outside of
-  this framework.
-- with this new iteration of the dma-buf api cpu access from the kernel has been
-  enable, see below for the details.
-
 dma-buf operations for device dma only
 --------------------------------------
 
@@ -300,6 +293,17 @@ Access to a dma_buf from the kernel context involves three steps:
    Note that these calls need to always succeed. The exporter needs to complete
    any preparations that might fail in begin_cpu_access.
 
+   For some cases the overhead of kmap can be too high, a vmap interface
+   is introduced. This interface should be used very carefully, as vmalloc
+   space is a limited resources on many architectures.
+
+   Interfaces:
+      void *dma_buf_vmap(struct dma_buf *dmabuf)
+      void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+
+   The vmap call can fail if there is no vmap support in the exporter, or if it
+   runs out of vmalloc space. Fallback to kmap should be implemented.
+
 3. Finish access
 
    When the importer is done accessing the range specified in begin_cpu_access,
@@ -313,6 +317,83 @@ Access to a dma_buf from the kernel context involves three steps:
                                   enum dma_data_direction dir);
 
 
+Direct Userspace Access/mmap Support
+------------------------------------
+
+Being able to mmap an export dma-buf buffer object has 2 main use-cases:
+- CPU fallback processing in a pipeline and
+- supporting existing mmap interfaces in importers.
+
+1. CPU fallback processing in a pipeline
+
+   In many processing pipelines it is sometimes required that the cpu can access
+   the data in a dma-buf (e.g. for thumbnail creation, snapshots, ...). To avoid
+   the need to handle this specially in userspace frameworks for buffer sharing
+   it's ideal if the dma_buf fd itself can be used to access the backing storage
+   from userspace using mmap.
+
+   Furthermore Android's ION framework already supports this (and is otherwise
+   rather similar to dma-buf from a userspace consumer side with using fds as
+   handles, too). So it's beneficial to support this in a similar fashion on
+   dma-buf to have a good transition path for existing Android userspace.
+
+   No special interfaces, userspace simply calls mmap on the dma-buf fd.
+
+2. Supporting existing mmap interfaces in exporters
+
+   Similar to the motivation for kernel cpu access it is again important that
+   the userspace code of a given importing subsystem can use the same interfaces
+   with a imported dma-buf buffer object as with a native buffer object. This is
+   especially important for drm where the userspace part of contemporary OpenGL,
+   X, and other drivers is huge, and reworking them to use a different way to
+   mmap a buffer rather invasive.
+
+   The assumption in the current dma-buf interfaces is that redirecting the
+   initial mmap is all that's needed. A survey of some of the existing
+   subsystems shows that no driver seems to do any nefarious thing like syncing
+   up with outstanding asynchronous processing on the device or allocating
+   special resources at fault time. So hopefully this is good enough, since
+   adding interfaces to intercept pagefaults and allow pte shootdowns would
+   increase the complexity quite a bit.
+
+   Interface:
+      int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
+                       unsigned long);
+
+   If the importing subsystem simply provides a special-purpose mmap call to set
+   up a mapping in userspace, calling do_mmap with dma_buf->file will equally
+   achieve that for a dma-buf object.
+
+3. Implementation notes for exporters
+
+   Because dma-buf buffers have invariant size over their lifetime, the dma-buf
+   core checks whether a vma is too large and rejects such mappings. The
+   exporter hence does not need to duplicate this check.
+
+   Because existing importing subsystems might presume coherent mappings for
+   userspace, the exporter needs to set up a coherent mapping. If that's not
+   possible, it needs to fake coherency by manually shooting down ptes when
+   leaving the cpu domain and flushing caches at fault time. Note that all the
+   dma_buf files share the same anon inode, hence the exporter needs to replace
+   the dma_buf file stored in vma->vm_file with it's own if pte shootdown is
+   requred. This is because the kernel uses the underlying inode's address_space
+   for vma tracking (and hence pte tracking at shootdown time with
+   unmap_mapping_range).
+
+   If the above shootdown dance turns out to be too expensive in certain
+   scenarios, we can extend dma-buf with a more explicit cache tracking scheme
+   for userspace mappings. But the current assumption is that using mmap is
+   always a slower path, so some inefficiencies should be acceptable.
+
+   Exporters that shoot down mappings (for any reasons) shall not do any
+   synchronization at fault time with outstanding device operations.
+   Synchronization is an orthogonal issue to sharing the backing storage of a
+   buffer and hence should not be handled by dma-buf itself. This is explictly
+   mentioned here because many people seem to want something like this, but if
+   different exporters handle this differently, buffer sharing can fail in
+   interesting ways depending upong the exporter (if userspace starts depending
+   upon this implicit synchronization).
+
 Miscellaneous notes
 -------------------
 
@@ -336,6 +417,20 @@ Miscellaneous notes
   the exporting driver to create a dmabuf fd must provide a way to let
   userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd().
 
+- If an exporter needs to manually flush caches and hence needs to fake
+  coherency for mmap support, it needs to be able to zap all the ptes pointing
+  at the backing storage. Now linux mm needs a struct address_space associated
+  with the struct file stored in vma->vm_file to do that with the function
+  unmap_mapping_range. But the dma_buf framework only backs every dma_buf fd
+  with the anon_file struct file, i.e. all dma_bufs share the same file.
+
+  Hence exporters need to setup their own file (and address_space) association
+  by setting vma->vm_file and adjusting vma->vm_pgoff in the dma_buf mmap
+  callback. In the specific case of a gem driver the exporter could use the
+  shmem file already provided by gem (and set vm_pgoff = 0). Exporters can then
+  zap ptes by unmapping the corresponding range of the struct address_space
+  associated with their own file.
+
 References:
 [1] struct dma_buf_ops in include/linux/dma-buf.h
 [2] All interfaces mentioned above defined in include/linux/dma-buf.h
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 2a596a4fc23e..950856bd2e39 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -276,3 +276,11 @@ REGULATOR
   devm_regulator_get()
   devm_regulator_put()
   devm_regulator_bulk_get()
+
+CLOCK
+  devm_clk_get()
+  devm_clk_put()
+
+PINCTRL
+  devm_pinctrl_get()
+  devm_pinctrl_put()
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index d1d4a179a382..fbb241174486 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -28,7 +28,8 @@ use IO::Handle;
                 "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
                 "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
                 "lme2510c_s7395_old", "drxk", "drxk_terratec_h5",
-                "drxk_hauppauge_hvr930c", "tda10071", "it9135", "it9137");
+                "drxk_hauppauge_hvr930c", "tda10071", "it9135", "it9137",
+                "drxk_pctv");
 
 # Check args
 syntax() if (scalar(@ARGV) != 1);
@@ -730,6 +731,23 @@ sub tda10071 {
     "$fwfile";
 }
 
+sub drxk_pctv {
+    my $sourcefile = "PCTV_460e_reference.zip";
+    my $url = "ftp://ftp.pctvsystems.com/TV/driver/PCTV%2070e%2080e%20100e%20320e%20330e%20800e/";
+    my $hash = "4403de903bf2593464c8d74bbc200a57";
+    my $fwfile = "dvb-demod-drxk-pctv.fw";
+    my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
+
+    checkstandard();
+
+    wgetfile($sourcefile, $url . $sourcefile);
+    verify($sourcefile, $hash);
+    unzip($sourcefile, $tmpdir);
+    extract("$tmpdir/PCTV\ 70e\ 80e\ 100e\ 320e\ 330e\ 800e/32\ bit/emOEM.sys", 0x72b80, 42692, $fwfile);
+
+    "$fwfile";
+}
+
 # ---------------------------------------------------------------
 # Utilities
 
diff --git a/Documentation/dvb/opera-firmware.txt b/Documentation/dvb/opera-firmware.txt
index 93e784c2607b..fb6683188ef7 100644
--- a/Documentation/dvb/opera-firmware.txt
+++ b/Documentation/dvb/opera-firmware.txt
@@ -8,7 +8,7 @@ from the windriver disk into this directory.
 
 Then run
 
-./get_dvb_firware opera1
+./get_dvb_firmware opera1
 
 and after that you have 2 files:
 
@@ -24,4 +24,4 @@ After that the driver can load the firmware
 in kernel config and have hotplug running).
 
 
-Marco Gittler <g.marco@freenet.de>
\ No newline at end of file
+Marco Gittler <g.marco@freenet.de>
diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt
index 74e6c7782678..6e1684981da2 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -2,17 +2,17 @@
 Introduction
 ============
 
-This document describes how to use the dynamic debug (ddebug) feature.
+This document describes how to use the dynamic debug (dyndbg) feature.
 
-Dynamic debug is designed to allow you to dynamically enable/disable kernel
-code to obtain additional kernel information. Currently, if
-CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can be
-dynamically enabled per-callsite.
+Dynamic debug is designed to allow you to dynamically enable/disable
+kernel code to obtain additional kernel information.  Currently, if
+CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can
+be dynamically enabled per-callsite.
 
 Dynamic debug has even more useful features:
 
- * Simple query language allows turning on and off debugging statements by
-   matching any combination of 0 or 1 of:
+ * Simple query language allows turning on and off debugging
+   statements by matching any combination of 0 or 1 of:
 
    - source filename
    - function name
@@ -20,17 +20,19 @@ Dynamic debug has even more useful features:
    - module name
    - format string
 
- * Provides a debugfs control file: <debugfs>/dynamic_debug/control which can be
-   read to display the complete list of known debug statements, to help guide you
+ * Provides a debugfs control file: <debugfs>/dynamic_debug/control
+   which can be read to display the complete list of known debug
+   statements, to help guide you
 
 Controlling dynamic debug Behaviour
 ===================================
 
 The behaviour of pr_debug()/dev_dbg()s are controlled via writing to a
-control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs
-filesystem, in order to make use of this feature. Subsequently, we refer to the
-control file as: <debugfs>/dynamic_debug/control. For example, if you want to
-enable printing from source file 'svcsock.c', line 1603 you simply do:
+control file in the 'debugfs' filesystem. Thus, you must first mount
+the debugfs filesystem, in order to make use of this feature.
+Subsequently, we refer to the control file as:
+<debugfs>/dynamic_debug/control. For example, if you want to enable
+printing from source file 'svcsock.c', line 1603 you simply do:
 
 nullarbor:~ # echo 'file svcsock.c line 1603 +p' >
                                 <debugfs>/dynamic_debug/control
@@ -44,15 +46,15 @@ nullarbor:~ # echo 'file svcsock.c wtf 1 +p' >
 Viewing Dynamic Debug Behaviour
 ===========================
 
-You can view the currently configured behaviour of all the debug statements
-via:
+You can view the currently configured behaviour of all the debug
+statements via:
 
 nullarbor:~ # cat <debugfs>/dynamic_debug/control
 # filename:lineno [module]function flags format
-/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup - "SVCRDMA Module Removed, deregister RPC RDMA transport\012"
-/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init - "\011max_inline       : %d\012"
-/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init - "\011sq_depth         : %d\012"
-/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init - "\011max_requests     : %d\012"
+/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012"
+/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline       : %d\012"
+/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth         : %d\012"
+/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests     : %d\012"
 ...
 
 
@@ -65,12 +67,12 @@ nullarbor:~ # grep -i rdma <debugfs>/dynamic_debug/control  | wc -l
 nullarbor:~ # grep -i tcp <debugfs>/dynamic_debug/control | wc -l
 42
 
-Note in particular that the third column shows the enabled behaviour
-flags for each debug statement callsite (see below for definitions of the
-flags).  The default value, no extra behaviour enabled, is "-".  So
-you can view all the debug statement callsites with any non-default flags:
+The third column shows the currently enabled flags for each debug
+statement callsite (see below for definitions of the flags).  The
+default value, with no flags enabled, is "=_".  So you can view all
+the debug statement callsites with any non-default flags:
 
-nullarbor:~ # awk '$3 != "-"' <debugfs>/dynamic_debug/control
+nullarbor:~ # awk '$3 != "=_"' <debugfs>/dynamic_debug/control
 # filename:lineno [module]function flags format
 /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012"
 
@@ -103,15 +105,14 @@ specifications, followed by a flags change specification.
 
 command ::= match-spec* flags-spec
 
-The match-spec's are used to choose a subset of the known dprintk()
+The match-spec's are used to choose a subset of the known pr_debug()
 callsites to which to apply the flags-spec.  Think of them as a query
 with implicit ANDs between each pair.  Note that an empty list of
-match-specs is possible, but is not very useful because it will not
-match any debug statement callsites.
+match-specs will select all debug statement callsites.
 
-A match specification comprises a keyword, which controls the attribute
-of the callsite to be compared, and a value to compare against.  Possible
-keywords are:
+A match specification comprises a keyword, which controls the
+attribute of the callsite to be compared, and a value to compare
+against.  Possible keywords are:
 
 match-spec ::= 'func' string |
                'file' string |
@@ -164,15 +165,15 @@ format
     characters (") or single quote characters (').
     Examples:
 
-    format svcrdma:         // many of the NFS/RDMA server dprintks
-    format readahead        // some dprintks in the readahead cache
+    format svcrdma:         // many of the NFS/RDMA server pr_debugs
+    format readahead        // some pr_debugs in the readahead cache
     format nfsd:\040SETATTR // one way to match a format with whitespace
     format "nfsd: SETATTR"  // a neater way to match a format with whitespace
     format 'nfsd: SETATTR'  // yet another way to match a format with whitespace
 
 line
     The given line number or range of line numbers is compared
-    against the line number of each dprintk() callsite.  A single
+    against the line number of each pr_debug() callsite.  A single
     line number matches the callsite line number exactly.  A
     range of line numbers matches any callsite between the first
     and last line number inclusive.  An empty first number means
@@ -188,51 +189,93 @@ The flags specification comprises a change operation followed
 by one or more flag characters.  The change operation is one
 of the characters:
 
--
-    remove the given flags
-
-+
-    add the given flags
-
-=
-    set the flags to the given flags
+  -    remove the given flags
+  +    add the given flags
+  =    set the flags to the given flags
 
 The flags are:
 
-f
-    Include the function name in the printed message
-l
-    Include line number in the printed message
-m
-    Include module name in the printed message
-p
-    Causes a printk() message to be emitted to dmesg
-t
-    Include thread ID in messages not generated from interrupt context
+  p    enables the pr_debug() callsite.
+  f    Include the function name in the printed message
+  l    Include line number in the printed message
+  m    Include module name in the printed message
+  t    Include thread ID in messages not generated from interrupt context
+  _    No flags are set. (Or'd with others on input)
+
+For display, the flags are preceded by '='
+(mnemonic: what the flags are currently equal to).
 
-Note the regexp ^[-+=][flmpt]+$ matches a flags specification.
-Note also that there is no convenient syntax to remove all
-the flags at once, you need to use "-flmpt".
+Note the regexp ^[-+=][flmpt_]+$ matches a flags specification.
+To clear all flags at once, use "=_" or "-flmpt".
 
 
-Debug messages during boot process
+Debug messages during Boot Process
 ==================================
 
-To be able to activate debug messages during the boot process,
-even before userspace and debugfs exists, use the boot parameter:
-ddebug_query="QUERY"
+To activate debug messages for core code and built-in modules during
+the boot process, even before userspace and debugfs exists, use
+dyndbg="QUERY", module.dyndbg="QUERY", or ddebug_query="QUERY"
+(ddebug_query is obsoleted by dyndbg, and deprecated).  QUERY follows
+the syntax described above, but must not exceed 1023 characters.  Your
+bootloader may impose lower limits.
+
+These dyndbg params are processed just after the ddebug tables are
+processed, as part of the arch_initcall.  Thus you can enable debug
+messages in all code run after this arch_initcall via this boot
+parameter.
 
-QUERY follows the syntax described above, but must not exceed 1023
-characters. The enablement of debug messages is done as an arch_initcall.
-Thus you can enable debug messages in all code processed after this
-arch_initcall via this boot parameter.
 On an x86 system for example ACPI enablement is a subsys_initcall and
-ddebug_query="file ec.c +p"
+   dyndbg="file ec.c +p"
 will show early Embedded Controller transactions during ACPI setup if
 your machine (typically a laptop) has an Embedded Controller.
 PCI (or other devices) initialization also is a hot candidate for using
 this boot parameter for debugging purposes.
 
+If foo module is not built-in, foo.dyndbg will still be processed at
+boot time, without effect, but will be reprocessed when module is
+loaded later.  dyndbg_query= and bare dyndbg= are only processed at
+boot.
+
+
+Debug Messages at Module Initialization Time
+============================================
+
+When "modprobe foo" is called, modprobe scans /proc/cmdline for
+foo.params, strips "foo.", and passes them to the kernel along with
+params given in modprobe args or /etc/modprob.d/*.conf files,
+in the following order:
+
+1. # parameters given via /etc/modprobe.d/*.conf
+   options foo dyndbg=+pt
+   options foo dyndbg # defaults to +p
+
+2. # foo.dyndbg as given in boot args, "foo." is stripped and passed
+   foo.dyndbg=" func bar +p; func buz +mp"
+
+3. # args to modprobe
+   modprobe foo dyndbg==pmf # override previous settings
+
+These dyndbg queries are applied in order, with last having final say.
+This allows boot args to override or modify those from /etc/modprobe.d
+(sensible, since 1 is system wide, 2 is kernel or boot specific), and
+modprobe args to override both.
+
+In the foo.dyndbg="QUERY" form, the query must exclude "module foo".
+"foo" is extracted from the param-name, and applied to each query in
+"QUERY", and only 1 match-spec of each type is allowed.
+
+The dyndbg option is a "fake" module parameter, which means:
+
+- modules do not need to define it explicitly
+- every module gets it tacitly, whether they use pr_debug or not
+- it doesnt appear in /sys/module/$module/parameters/
+  To see it, grep the control file, or inspect /proc/cmdline.
+
+For CONFIG_DYNAMIC_DEBUG kernels, any settings given at boot-time (or
+enabled by -DDEBUG flag during compilation) can be disabled later via
+the sysfs interface if the debug messages are no longer needed:
+
+   echo "module module_name -p" > <debugfs>/dynamic_debug/control
 
 Examples
 ========
@@ -260,3 +303,18 @@ nullarbor:~ # echo -n 'func svc_process -p' >
 // enable messages for NFS calls READ, READLINK, READDIR and READDIR+.
 nullarbor:~ # echo -n 'format "nfsd: READ" +p' >
                                 <debugfs>/dynamic_debug/control
+
+// enable all messages
+nullarbor:~ # echo -n '+p' > <debugfs>/dynamic_debug/control
+
+// add module, function to all enabled messages
+nullarbor:~ # echo -n '+mf' > <debugfs>/dynamic_debug/control
+
+// boot-args example, with newlines and comments for readability
+Kernel command line: ...
+  // see whats going on in dyndbg=value processing
+  dynamic_debug.verbose=1
+  // enable pr_debugs in 2 builtins, #cmt is stripped
+  dyndbg="module params +p #cmt ; module sys +p"
+  // enable pr_debugs in 2 functions in a module loaded later
+  pc87360.dyndbg="func pc87360_init_device +p; func pc87360_find +p"
diff --git a/Documentation/edac.txt b/Documentation/edac.txt
index c25f086a6960..56c7e936430f 100644
--- a/Documentation/edac.txt
+++ b/Documentation/edac.txt
@@ -638,7 +638,7 @@ were done at i7core_edac driver. This chapter will cover those differences
    associated with a physical CPU socket.
 
    Each MC have 3 physical read channels, 3 physical write channels and
-   3 logic channels. The driver currenty sees it as just 3 channels.
+   3 logic channels. The driver currently sees it as just 3 channels.
    Each channel can have up to 3 DIMMs.
 
    The minimum known unity is DIMMs. There are no information about csrows.
diff --git a/Documentation/eisa.txt b/Documentation/eisa.txt
index 38cf0c7b559f..a55e4910924e 100644
--- a/Documentation/eisa.txt
+++ b/Documentation/eisa.txt
@@ -179,7 +179,7 @@ CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.
 
 Converting an EISA driver to the new API mostly involves *deleting*
 code (since probing is now in the core EISA code). Unfortunately, most
-drivers share their probing routine between ISA, MCA and EISA. Special
+drivers share their probing routine between ISA, and EISA. Special
 care must be taken when ripping out the EISA code, so other busses
 won't suffer from these surgical strikes...
 
diff --git a/Documentation/extcon/porting-android-switch-class b/Documentation/extcon/porting-android-switch-class
new file mode 100644
index 000000000000..eb0fa5f4fe88
--- /dev/null
+++ b/Documentation/extcon/porting-android-switch-class
@@ -0,0 +1,124 @@
+
+        Staging/Android Switch Class Porting Guide
+        (linux/drivers/staging/android/switch)
+        (c) Copyright 2012 Samsung Electronics
+
+AUTHORS
+MyungJoo Ham <myungjoo.ham@samsung.com>
+
+/*****************************************************************
+ * CHAPTER 1.                                                    *
+ * PORTING SWITCH CLASS DEVICE DRIVERS                           *
+ *****************************************************************/
+
+****** STEP 1. Basic Functionality
+        No extcon extended feature, but switch features only.
+
+- struct switch_dev (fed to switch_dev_register/unregister)
+    @name: no change
+    @dev: no change
+    @index: drop (not used in switch device driver side anyway)
+    @state: no change
+        If you have used @state with magic numbers, keep it
+        at this step.
+    @print_name: no change but type change (switch_dev->extcon_dev)
+    @print_state: no change but type change (switch_dev->extcon_dev)
+
+- switch_dev_register(sdev, dev)
+        => extcon_dev_register(edev, dev)
+        : no change but type change (sdev->edev)
+- switch_dev_unregister(sdev)
+        => extcon_dev_unregister(edev)
+        : no change but type change (sdev->edev)
+- switch_get_state(sdev)
+        => extcon_get_state(edev)
+        : no change but type change (sdev->edev) and (return: int->u32)
+- switch_set_state(sdev, state)
+        => extcon_set_state(edev, state)
+        : no change but type change (sdev->edev) and (state: int->u32)
+
+With this changes, the ex-switch extcon class device works as it once
+worked as switch class device. However, it will now have additional
+interfaces (both ABI and in-kernel API) and different ABI locations.
+However, if CONFIG_ANDROID is enabled without CONFIG_ANDROID_SWITCH,
+/sys/class/switch/* will be symbolically linked to /sys/class/extcon/
+so that they are still compatible with legacy userspace processes.
+
+****** STEP 2. Multistate (no more magic numbers in state value)
+        Extcon's extended features for switch device drivers with
+        complex features usually required magic numbers in state
+        value of switch_dev. With extcon, such magic numbers that
+        support multiple cables (
+
+  1. Define cable names at edev->supported_cable.
+  2. (Recommended) remove print_state callback.
+  3. Use extcon_get_cable_state_(edev, index) or
+   extcon_get_cable_state(edev, cable_name) instead of
+   extcon_get_state(edev) if you intend to get a state of a specific
+   cable. Same for set_state. This way, you can remove the usage of
+   magic numbers in state value.
+  4. Use extcon_update_state() if you are updating specific bits of
+   the state value.
+
+Example: a switch device driver w/ magic numbers for two cables.
+        "0x00": no cables connected.
+        "0x01": cable 1 connected
+        "0x02": cable 2 connected
+        "0x03": cable 1 and 2 connected
+  1. edev->supported_cable = {"1", "2", NULL};
+  2. edev->print_state = NULL;
+  3. extcon_get_cable_state_(edev, 0) shows cable 1's state.
+     extcon_get_cable_state(edev, "1") shows cable 1's state.
+     extcon_set_cable_state_(edev, 1) sets cable 2's state.
+     extcon_set_cable_state(edev, "2") sets cable 2's state
+  4. extcon_update_state(edev, 0x01, 0) sets the least bit's 0.
+
+****** STEP 3. Notify other device drivers
+
+  You can notify others of the cable attach/detach events with
+notifier chains.
+
+  At the side of other device drivers (the extcon device itself
+does not need to get notified of its own events), there are two
+methods to register notifier_block for cable events:
+(a) for a specific cable or (b) for every cable.
+
+  (a) extcon_register_interest(obj, extcon_name, cable_name, nb)
+        Example: want to get news of "MAX8997_MUIC"'s "USB" cable
+
+        obj = kzalloc(sizeof(struct extcon_specific_cable_nb),
+                      GFP_KERNEL);
+        nb->notifier_call = the_callback_to_handle_usb;
+
+        extcon_register_intereset(obj, "MAX8997_MUIC", "USB", nb);
+
+  (b) extcon_register_notifier(edev, nb)
+        Call nb for any changes in edev.
+
+  Please note that in order to properly behave with method (a),
+the extcon device driver should support multistate feature (STEP 2).
+
+****** STEP 4. Inter-cable relation (mutually exclusive)
+
+  You can provide inter-cable mutually exclusiveness information
+for an extcon device. When cables A and B are declared to be mutually
+exclusive, the two cables cannot be in ATTACHED state simulteneously.
+
+
+/*****************************************************************
+ * CHAPTER 2.                                                    *
+ * PORTING USERSPACE w/ SWITCH CLASS DEVICE SUPPORT              *
+ *****************************************************************/
+
+****** ABI Location
+
+  If "CONFIG_ANDROID" is enabled and "CONFIG_ANDROID_SWITCH" is
+disabled, /sys/class/switch/* are created as symbolic links to
+/sys/class/extcon/*. Because CONFIG_ANDROID_SWITCH creates
+/sys/class/switch directory, we disable symboling linking if
+CONFIG_ANDROID_SWITCH is enabled.
+
+  The two files of switch class, name and state, are provided with
+extcon, too. When the multistate support (STEP 2 of CHAPTER 1.) is
+not enabled or print_state callback is supplied, the output of
+state ABI is same with switch class.
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index e4b57756b9f5..56000b33340b 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -2,7 +2,14 @@ The following is a list of files and features that are going to be
 removed in the kernel source tree.  Every entry should contain what
 exactly is going away, why it is happening, and who is going to be doing
 the work.  When the feature is removed from the kernel, it should also
-be removed from this file.
+be removed from this file.  The suggested deprecation period is 3 releases.
+
+---------------------------
+
+What:   ddebug_query="query" boot cmdline param
+When:   v3.8
+Why:    obsoleted by dyndbg="query" and module.dyndbg="query"
+Who:    Jim Cromie <jim.cromie@gmail.com>, Jason Baron <jbaron@redhat.com>
 
 ---------------------------
 
@@ -534,6 +541,18 @@ Who:	Kees Cook <keescook@chromium.org>
 
 ----------------------------
 
+What:   Removing the pn544 raw driver.
+When:   3.6
+Why:    With the introduction of the NFC HCI and SHDL kernel layers, pn544.c
+        is being replaced by pn544_hci.c which is accessible through the netlink
+        and socket NFC APIs. Moreover, pn544.c is outdated and does not seem to
+        work properly with the latest Android stacks.
+        Having 2 drivers for the same hardware is confusing and as such we
+        should only keep the one following the kernel NFC APIs.
+Who:    Samuel Ortiz <sameo@linux.intel.com>
+
+----------------------------
+
 What:   setitimer accepts user NULL pointer (value)
 When:   3.6
 Why:    setitimer is not returning -EFAULT if user pointer is NULL. This
@@ -542,6 +561,15 @@ Who:	Sasikantha Babu <sasikanth.v19@gmail.com>
 
 ----------------------------
 
+What:   remove bogus DV presets V4L2_DV_1080I29_97, V4L2_DV_1080I30 and
+        V4L2_DV_1080I25
+When:   3.6
+Why:    These HDTV formats do not exist and were added by a confused mind
+        (that was me, to be precise...)
+Who:    Hans Verkuil <hans.verkuil@cisco.com>
+
+----------------------------
+
 What:   V4L2_CID_HCENTER, V4L2_CID_VCENTER V4L2 controls
 When:   3.7
 Why:    The V4L2_CID_VCENTER, V4L2_CID_HCENTER controls have been deprecated
@@ -549,3 +577,38 @@ Why:	The V4L2_CID_VCENTER, V4L2_CID_HCENTER controls have been deprecated
         There are newer controls (V4L2_CID_PAN*, V4L2_CID_TILT*) that provide
         similar functionality.
 Who:    Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
+
+----------------------------
+
+What:   cgroup option updates via remount
+When:   March 2013
+Why:    Remount currently allows changing bound subsystems and
+        release_agent.  Rebinding is hardly useful as it only works
+        when the hierarchy is empty and release_agent itself should be
+        replaced with conventional fsnotify.
+
+----------------------------
+
+What:   KVM debugfs statistics
+When:   2013
+Why:    KVM tracepoints provide mostly equivalent information in a much more
+        flexible fashion.
+
+----------------------------
+
+What:   at91-mci driver ("CONFIG_MMC_AT91")
+When:   3.7
+Why:    There are two mci drivers: at91-mci and atmel-mci. The PDC support
+        was added to atmel-mci as a first step to support more chips.
+        Then at91-mci was kept only for old IP versions (on at91rm9200 and
+        at91sam9261). The support of these IP versions has just been added
+        to atmel-mci, so atmel-mci can be used for all chips.
+Who:    Ludovic Desroches <ludovic.desroches@atmel.com>
+
+----------------------------
+
+What:   net/wanrouter/
+When:   June 2013
+Why:    Unsupported/unmaintained/unused since 2.6
+
+----------------------------
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 4fca82e5276e..8e2da1e06e3b 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -60,8 +60,8 @@ ata *);
         ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);
         ssize_t (*listxattr) (struct dentry *, char *, size_t);
         int (*removexattr) (struct dentry *, const char *);
-        void (*truncate_range)(struct inode *, loff_t, loff_t);
         int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
+        void (*update_time)(struct inode *, struct timespec *, int);
 
 locking rules:
         all may block
@@ -87,8 +87,9 @@ setxattr:	yes
 getxattr:       no
 listxattr:      no
 removexattr:    yes
-truncate_range: yes
 fiemap:         no
+update_time:    no
+
         Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
 victim.
         cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt
index b100adc38adb..293855e95000 100644
--- a/Documentation/filesystems/ext3.txt
+++ b/Documentation/filesystems/ext3.txt
@@ -59,9 +59,9 @@ commit=nrsec	(*)	Ext3 can be told to sync all its data and metadata
                         Setting it to very large values will improve
                         performance.
 
-barrier=<0(*)|1>        This enables/disables the use of write barriers in
-barrier                 the jbd code.  barrier=0 disables, barrier=1 enables.
-nobarrier       (*)     This also requires an IO stack which can support
+barrier=<0|1(*)>        This enables/disables the use of write barriers in
+barrier (*)             the jbd code.  barrier=0 disables, barrier=1 enables.
+nobarrier               This also requires an IO stack which can support
                         barriers, and if jbd gets an error on a barrier
                         write, it will disable again with a warning.
                         Write barriers enforce proper on-disk ordering
diff --git a/Documentation/filesystems/gfs2-glocks.txt b/Documentation/filesystems/gfs2-glocks.txt
index 0494f78d87e4..fcc79957be63 100644
--- a/Documentation/filesystems/gfs2-glocks.txt
+++ b/Documentation/filesystems/gfs2-glocks.txt
@@ -61,7 +61,9 @@ go_unlock        | Called on the final local unlock of a lock
 go_dump          | Called to print content of object for debugfs file, or on
                  | error to dump glock to the log.
 go_type          | The type of the glock, LM_TYPE_.....
-go_min_hold_time | The minimum hold time
+go_callback      | Called if the DLM sends a callback to drop this lock
+go_flags         | GLOF_ASPACE is set, if the glock has an address space
+                 | associated with it
 
 The minimum hold time for each lock is the time after a remote lock
 grant for which we ignore remote demote requests. This is in order to
@@ -89,6 +91,7 @@ go_demote_ok  |       Sometimes         |       Yes
 go_lock       |       Yes               |       No
 go_unlock     |       Yes               |       No
 go_dump       |       Sometimes         |       Yes
+go_callback   |       Sometimes (N/A)   |       Yes
 
 N.B. Operations must not drop either the bit lock or the spinlock
 if its held on entry. go_dump and do_demote_ok must never block.
@@ -111,4 +114,118 @@ itself (locking order as above), and the other, known as the iopen
 glock is used in conjunction with the i_nlink field in the inode to
 determine the lifetime of the inode in question. Locking of inodes
 is on a per-inode basis. Locking of rgrps is on a per rgrp basis.
+In general we prefer to lock local locks prior to cluster locks.
+
+                            Glock Statistics
+                           ------------------
+
+The stats are divided into two sets: those relating to the
+super block and those relating to an individual glock. The
+super block stats are done on a per cpu basis in order to
+try and reduce the overhead of gathering them. They are also
+further divided by glock type. All timings are in nanoseconds.
+
+In the case of both the super block and glock statistics,
+the same information is gathered in each case. The super
+block timing statistics are used to provide default values for
+the glock timing statistics, so that newly created glocks
+should have, as far as possible, a sensible starting point.
+The per-glock counters are initialised to zero when the
+glock is created. The per-glock statistics are lost when
+the glock is ejected from memory.
+
+The statistics are divided into three pairs of mean and
+variance, plus two counters. The mean/variance pairs are
+smoothed exponential estimates and the algorithm used is
+one which will be very familiar to those used to calculation
+of round trip times in network code. See "TCP/IP Illustrated,
+Volume 1", W. Richard Stevens, sect 21.3, "Round-Trip Time Measurement",
+p. 299 and onwards. Also, Volume 2, Sect. 25.10, p. 838 and onwards.
+Unlike the TCP/IP Illustrated case, the mean and variance are
+not scaled, but are in units of integer nanoseconds.
+
+The three pairs of mean/variance measure the following
+things:
+
+ 1. DLM lock time (non-blocking requests)
+ 2. DLM lock time (blocking requests)
+ 3. Inter-request time (again to the DLM)
+
+A non-blocking request is one which will complete right
+away, whatever the state of the DLM lock in question. That
+currently means any requests when (a) the current state of
+the lock is exclusive, i.e. a lock demotion (b) the requested
+state is either null or unlocked (again, a demotion) or (c) the
+"try lock" flag is set. A blocking request covers all the other
+lock requests.
+
+There are two counters. The first is there primarily to show
+how many lock requests have been made, and thus how much data
+has gone into the mean/variance calculations. The other counter
+is counting queuing of holders at the top layer of the glock
+code. Hopefully that number will be a lot larger than the number
+of dlm lock requests issued.
+
+So why gather these statistics? There are several reasons
+we'd like to get a better idea of these timings:
+
+1. To be able to better set the glock "min hold time"
+2. To spot performance issues more easily
+3. To improve the algorithm for selecting resource groups for
+allocation (to base it on lock wait time, rather than blindly
+using a "try lock")
+
+Due to the smoothing action of the updates, a step change in
+some input quantity being sampled will only fully be taken
+into account after 8 samples (or 4 for the variance) and this
+needs to be carefully considered when interpreting the
+results.
+
+Knowing both the time it takes a lock request to complete and
+the average time between lock requests for a glock means we
+can compute the total percentage of the time for which the
+node is able to use a glock vs. time that the rest of the
+cluster has its share. That will be very useful when setting
+the lock min hold time.
+
+Great care has been taken to ensure that we
+measure exactly the quantities that we want, as accurately
+as possible. There are always inaccuracies in any
+measuring system, but I hope this is as accurate as we
+can reasonably make it.
+
+Per sb stats can be found here:
+/sys/kernel/debug/gfs2/<fsname>/sbstats
+Per glock stats can be found here:
+/sys/kernel/debug/gfs2/<fsname>/glstats
+
+Assuming that debugfs is mounted on /sys/kernel/debug and also
+that <fsname> is replaced with the name of the gfs2 filesystem
+in question.
+
+The abbreviations used in the output as are follows:
+
+srtt     - Smoothed round trip time for non-blocking dlm requests
+srttvar  - Variance estimate for srtt
+srttb    - Smoothed round trip time for (potentially) blocking dlm requests
+srttvarb - Variance estimate for srttb
+sirt     - Smoothed inter-request time (for dlm requests)
+sirtvar  - Variance estimate for sirt
+dlm      - Number of dlm requests made (dcnt in glstats file)
+queue    - Number of glock requests queued (qcnt in glstats file)
+
+The sbstats file contains a set of these stats for each glock type (so 8 lines
+for each type) and for each cpu (one column per cpu). The glstats file contains
+a set of these stats for each glock in a similar format to the glocks file, but
+using the format mean/variance for each of the timing stats.
+
+The gfs2_glock_lock_time tracepoint prints out the current values of the stats
+for the glock in question, along with some addition information on each dlm
+reply that is received:
+
+status - The status of the dlm request
+flags  - The dlm request flags
+tdiff  - The time taken by this specific request
+(remaining fields as per above list)
+
 
diff --git a/Documentation/filesystems/gfs2.txt b/Documentation/filesystems/gfs2.txt
index 4cda926628aa..cc4f2306609e 100644
--- a/Documentation/filesystems/gfs2.txt
+++ b/Documentation/filesystems/gfs2.txt
@@ -1,7 +1,7 @@
 Global File System
 ------------------
 
-http://sources.redhat.com/cluster/wiki/
+https://fedorahosted.org/cluster/wiki/HomePage
 
 GFS is a cluster file system. It allows a cluster of computers to
 simultaneously use a block device that is shared between them (with FC,
@@ -30,7 +30,8 @@ needed, simply:
 
 If you are using Fedora, you need to install the gfs2-utils package
 and, for lock_dlm, you will also need to install the cman package
-and write a cluster.conf as per the documentation.
+and write a cluster.conf as per the documentation. For F17 and above
+cman has been replaced by the dlm package.
 
 GFS2 is not on-disk compatible with previous versions of GFS, but it
 is pretty close.
@@ -39,8 +40,6 @@ The following man pages can be found at the URL above:
   fsck.gfs2             to repair a filesystem
   gfs2_grow             to expand a filesystem online
   gfs2_jadd             to add journals to a filesystem online
-  gfs2_tool             to manipulate, examine and tune a filesystem
-  gfs2_quota    to examine and change quota values in a filesystem
+  tunegfs2              to manipulate, examine and tune a filesystem
   gfs2_convert  to convert a gfs filesystem to gfs2 in-place
-  mount.gfs2    to help mount(8) mount a filesystem
   mkfs.gfs2             to make a filesystem
diff --git a/Documentation/filesystems/nfs/pnfs.txt b/Documentation/filesystems/nfs/pnfs.txt
index c7919c6e3bea..52ae07f5f578 100644
--- a/Documentation/filesystems/nfs/pnfs.txt
+++ b/Documentation/filesystems/nfs/pnfs.txt
@@ -93,7 +93,7 @@ The API to the login script is as follows:
                                 (allways exists)
                                 (More protocols can be defined in the future.
                                  The client does not interpret this string it is
-                                 passed unchanged as recieved from the Server)
+                                 passed unchanged as received from the Server)
                 -o              osdname of the requested target OSD
                                 (Might be empty)
                                 (A string which denotes the OSD name, there is a
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index 74acd9618819..8c91d1057d9a 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -297,7 +297,8 @@ in the beginning of ->setattr unconditionally.
 be used instead.  It gets called whenever the inode is evicted, whether it has
 remaining links or not.  Caller does *not* evict the pagecache or inode-associated
 metadata buffers; getting rid of those is responsibility of method, as it had
-been for ->delete_inode().
+been for ->delete_inode(). Caller makes sure async writeback cannot be running
+for the inode while (or after) ->evict_inode() is called.
 
         ->drop_inode() returns int now; it's called on final iput() with
 inode->i_lock held and it returns true if filesystems wants the inode to be
@@ -306,14 +307,11 @@ updated appropriately.  generic_delete_inode() is also alive and it consists
 simply of return 1.  Note that all actual eviction work is done by caller after
 ->drop_inode() returns.
 
-        clear_inode() is gone; use end_writeback() instead.  As before, it must
-be called exactly once on each call of ->evict_inode() (as it used to be for
-each call of ->delete_inode()).  Unlike before, if you are using inode-associated
-metadata buffers (i.e. mark_buffer_dirty_inode()), it's your responsibility to
-call invalidate_inode_buffers() before end_writeback().
-        No async writeback (and thus no calls of ->write_inode()) will happen
-after end_writeback() returns, so actions that should not overlap with ->write_inode()
-(e.g. freeing on-disk inode if i_nlink is 0) ought to be done after that call.
+        As before, clear_inode() must be called exactly once on each call of
+->evict_inode() (as it used to be for each call of ->delete_inode()).  Unlike
+before, if you are using inode-associated metadata buffers (i.e.
+mark_buffer_dirty_inode()), it's your responsibility to call
+invalidate_inode_buffers() before clear_inode().
 
         NOTE: checking i_nlink in the beginning of ->write_inode() and bailing out
 if it's zero is not *and* *never* *had* *been* enough.  Final unlink() and iput()
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index b7413cb46dcb..fb0a6aeb936c 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -40,6 +40,7 @@ Table of Contents
   3.4   /proc/<pid>/coredump_filter - Core dump filtering settings
   3.5   /proc/<pid>/mountinfo - Information about mounts
   3.6   /proc/<pid>/comm  & /proc/<pid>/task/<tid>/comm
+  3.7   /proc/<pid>/task/<tid>/children - Information about task children
 
   4     Configuring procfs
   4.1   Mount options
@@ -310,6 +311,11 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
   start_data    address above which program data+bss is placed
   end_data      address below which program data+bss is placed
   start_brk     address above which program heap can be expanded with brk()
+  arg_start     address above which program command line is placed
+  arg_end       address below which program command line is placed
+  env_start     address above which program environment is placed
+  env_end       address below which program environment is placed
+  exit_code     the thread's exit_code in the form reported by the waitpid system call
 ..............................................................................
 
 The /proc/PID/maps file containing the currently mapped memory regions and
@@ -743,6 +749,7 @@ Committed_AS:   100056 kB
 VmallocTotal:   112216 kB
 VmallocUsed:       428 kB
 VmallocChunk:   111088 kB
+AnonHugePages:   49152 kB
 
     MemTotal: Total usable ram (i.e. physical ram minus a few reserved
               bits and the kernel binary code)
@@ -776,6 +783,7 @@ VmallocChunk:   111088 kB
        Dirty: Memory which is waiting to get written back to the disk
    Writeback: Memory which is actively being written back to the disk
    AnonPages: Non-file backed pages mapped into userspace page tables
+AnonHugePages: Non-file backed huge pages mapped into userspace page tables
       Mapped: files which have been mmaped, such as libraries
         Slab: in-kernel data structures cache
 SReclaimable: Part of Slab, that might be reclaimed, such as caches
@@ -996,7 +1004,6 @@ Table 1-9: Network info in /proc/net
  snmp          SNMP data                                                       
  sockstat      Socket statistics                                               
  tcp           TCP  sockets                                                    
- tr_rif        Token ring RIF routing table                                    
  udp           UDP sockets                                                     
  unix          UNIX domain sockets                                             
  wireless      Wireless interface data (Wavelan etc)                           
@@ -1577,6 +1584,23 @@ then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated
 comm value.
 
 
+3.7     /proc/<pid>/task/<tid>/children - Information about task children
+-------------------------------------------------------------------------
+This file provides a fast way to retrieve first level children pids
+of a task pointed by <pid>/<tid> pair. The format is a space separated
+stream of pids.
+
+Note the "first level" here -- if a child has own children they will
+not be listed here, one needs to read /proc/<children-pid>/task/<tid>/children
+to obtain the descendants.
+
+Since this interface is intended to be fast and cheap it doesn't
+guarantee to provide precise results and some children might be
+skipped, especially if they've exited right after we printed their
+pids, so one need to either stop or freeze processes being inspected
+if precise results are needed.
+
+
 ------------------------------------------------------------------------------
 Configuring procfs
 ------------------------------------------------------------------------------
diff --git a/Documentation/filesystems/qnx6.txt b/Documentation/filesystems/qnx6.txt
index 050223ea03c7..e59f2f09f56e 100644
--- a/Documentation/filesystems/qnx6.txt
+++ b/Documentation/filesystems/qnx6.txt
@@ -17,7 +17,7 @@ concepts of blocks, inodes and directories.
 On QNX it is possible to create little endian and big endian qnx6 filesystems.
 This feature makes it possible to create and use a different endianness fs
 for the target (QNX is used on quite a range of embedded systems) plattform
-running on a different endianess.
+running on a different endianness.
 The Linux driver handles endianness transparently. (LE and BE)
 
 Blocks
@@ -26,7 +26,7 @@ Blocks
 The space in the device or file is split up into blocks. These are a fixed
 size of 512, 1024, 2048 or 4096, which is decided when the filesystem is
 created.
-Blockpointers are 32bit, so the maximum space that can be adressed is
+Blockpointers are 32bit, so the maximum space that can be addressed is
 2^32 * 4096 bytes or 16TB
 
 The superblocks
@@ -47,16 +47,16 @@ inactive superblock.
 Each superblock holds a set of root inodes for the different filesystem
 parts. (Inode, Bitmap and Longfilenames)
 Each of these root nodes holds information like total size of the stored
-data and the adressing levels in that specific tree.
-If the level value is 0, up to 16 direct blocks can be adressed by each
+data and the addressing levels in that specific tree.
+If the level value is 0, up to 16 direct blocks can be addressed by each
 node.
-Level 1 adds an additional indirect adressing level where each indirect
-adressing block holds up to blocksize / 4 bytes pointers to data blocks.
-Level 2 adds an additional indirect adressig block level (so, already up
-to 16 * 256 * 256 = 1048576 blocks that can be adressed by such a tree)a
+Level 1 adds an additional indirect addressing level where each indirect
+addressing block holds up to blocksize / 4 bytes pointers to data blocks.
+Level 2 adds an additional indirect addressing block level (so, already up
+to 16 * 256 * 256 = 1048576 blocks that can be addressed by such a tree).
 
 Unused block pointers are always set to ~0 - regardless of root node,
-indirect adressing blocks or inodes.
+indirect addressing blocks or inodes.
 Data leaves are always on the lowest level. So no data is stored on upper
 tree levels.
 
@@ -64,7 +64,7 @@ The first Superblock is located at 0x2000. (0x2000 is the bootblock size)
 The Audi MMI 3G first superblock directly starts at byte 0.
 Second superblock position can either be calculated from the superblock
 information (total number of filesystem blocks) or by taking the highest
-device address, zeroing the last 3 bytes and then substracting 0x1000 from
+device address, zeroing the last 3 bytes and then subtracting 0x1000 from
 that address.
 
 0x1000 is the size reserved for each superblock - regardless of the
@@ -83,8 +83,8 @@ size, number of blocks used, access time, change time and modification time.
 Object mode field is POSIX format. (which makes things easier)
 
 There are also pointers to the first 16 blocks, if the object data can be
-adressed with 16 direct blocks.
-For more than 16 blocks an indirect adressing in form of another tree is
+addressed with 16 direct blocks.
+For more than 16 blocks an indirect addressing in form of another tree is
 used. (scheme is the same as the one used for the superblock root nodes)
 
 The filesize is stored 64bit. Inode counting starts with 1. (whilst long
@@ -118,13 +118,13 @@ no block pointers and the directory file record pointing to the target file
 inode.
 
 Character and block special devices do not exist in QNX as those files
-are handled by the QNX kernel/drivers and created in /dev independant of the
+are handled by the QNX kernel/drivers and created in /dev independent of the
 underlaying filesystem.
 
 Long filenames
 --------------
 
-Long filenames are stored in a seperate adressing tree. The staring point
+Long filenames are stored in a separate addressing tree. The staring point
 is the longfilename root node in the active superblock.
 Each data block (tree leaves) holds one long filename. That filename is
 limited to 510 bytes. The first two starting bytes are used as length field
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 0d0492028082..efd23f481704 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -363,7 +363,7 @@ struct inode_operations {
         ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);
         ssize_t (*listxattr) (struct dentry *, char *, size_t);
         int (*removexattr) (struct dentry *, const char *);
-        void (*truncate_range)(struct inode *, loff_t, loff_t);
+        void (*update_time)(struct inode *, struct timespec *, int);
 };
 
 Again, all methods are called without any locks being held, unless
@@ -472,9 +472,9 @@ otherwise noted.
   removexattr: called by the VFS to remove an extended attribute from
         a file. This method is called by removexattr(2) system call.
 
-  truncate_range: a method provided by the underlying filesystem to truncate a
-        range of blocks , i.e. punch a hole somewhere in a file.
-
+  update_time: called by the VFS to update a specific time or the i_version of
+        an inode.  If this is not defined the VFS will update the inode itself
+        and call mark_inode_dirty_sync.
 
 The Address Space Object
 ========================
@@ -760,7 +760,7 @@ struct file_operations
 ----------------------
 
 This describes how the VFS can manipulate an open file. As of kernel
-2.6.22, the following members are defined:
+3.5, the following members are defined:
 
 struct file_operations {
         struct module *owner;
@@ -790,6 +790,8 @@ struct file_operations {
         int (*flock) (struct file *, int, struct file_lock *);
         ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned int);
         ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int);
+        int (*setlease)(struct file *, long arg, struct file_lock **);
+        long (*fallocate)(struct file *, int mode, loff_t offset, loff_t len);
 };
 
 Again, all methods are called without any locks being held, unless
@@ -858,6 +860,11 @@ otherwise noted.
   splice_read: called by the VFS to splice data from file to a pipe. This
                method is used by the splice(2) system call
 
+  setlease: called by the VFS to set or release a file lock lease.
+            setlease has the file_lock_lock held and must not sleep.
+
+  fallocate: called by the VFS to preallocate blocks or punch a hole.
+
 Note that the file operations are implemented by the specific
 filesystem in which the inode resides. When opening a device node
 (character or block special) most filesystems will call special
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index 620a07844e8c..e08a883de36e 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -322,6 +322,9 @@ where 'flags' is currently defined to specify the following properties:
         * GPIOF_OPEN_DRAIN      - gpio pin is open drain type.
         * GPIOF_OPEN_SOURCE     - gpio pin is open source type.
 
+        * GPIOF_EXPORT_DIR_FIXED        - export gpio to sysfs, keep direction
+        * GPIOF_EXPORT_DIR_CHANGEABLE   - also export, allow changing direction
+
 since GPIOF_INIT_* are only valid when configured as output, so group valid
 combinations as:
 
diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp
index 84d46c0c71a3..c86b50c03ea8 100644
--- a/Documentation/hwmon/coretemp
+++ b/Documentation/hwmon/coretemp
@@ -6,7 +6,9 @@ Supported chips:
     Prefix: 'coretemp'
     CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm),
                               0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm),
-                              0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield)
+                              0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield),
+                              0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom),
+                              0x36 (Cedar Trail Atom)
     Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
                Volume 3A: System Programming Guide
                http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
@@ -52,6 +54,17 @@ Some information comes from ark.intel.com
 
 Process         Processor                                       TjMax(C)
 
+22nm            Core i5/i7 Processors
+                i7 3920XM, 3820QM, 3720QM, 3667U, 3520M         105
+                i5 3427U, 3360M/3320M                           105
+                i7 3770/3770K                                   105
+                i5 3570/3570K, 3550, 3470/3450                  105
+                i7 3770S                                        103
+                i5 3570S/3550S, 3475S/3470S/3450S               103
+                i7 3770T                                        94
+                i5 3570T                                        94
+                i5 3470T                                        91
+
 32nm            Core i3/i5/i7 Processors
                 i7 660UM/640/620, 640LM/620, 620M, 610E         105
                 i5 540UM/520/430, 540M/520/450/430              105
@@ -65,6 +78,11 @@ Process		Processor					TjMax(C)
                 U3400                                           105
                 P4505/P4500                                     90
 
+32nm            Atom Processors
+                Z2460                                           90
+                D2700/2550/2500                                 100
+                N2850/2800/2650/2600                            100
+
 45nm            Xeon Processors 5400 Quad-Core
                 X5492, X5482, X5472, X5470, X5460, X5450        85
                 E5472, E5462, E5450/40/30/20/10/05              85
@@ -85,6 +103,8 @@ Process		Processor					TjMax(C)
                 N475/470/455/450                                100
                 N280/270                                        90
                 330/230                                         125
+                E680/660/640/620                                90
+                E680T/660T/640T/620T                            110
 
 45nm            Core2 Processors
                 Solo ULV SU3500/3300                            100
diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
new file mode 100644
index 000000000000..f50a6cc27616
--- /dev/null
+++ b/Documentation/hwmon/ina2xx
@@ -0,0 +1,29 @@
+Kernel driver ina2xx
+====================
+
+Supported chips:
+  * Texas Instruments INA219
+    Prefix: 'ina219'
+    Addresses: I2C 0x40 - 0x4f
+    Datasheet: Publicly available at the Texas Instruments website
+               http://www.ti.com/
+
+  * Texas Instruments INA226
+    Prefix: 'ina226'
+    Addresses: I2C 0x40 - 0x4f
+    Datasheet: Publicly available at the Texas Instruments website
+               http://www.ti.com/
+
+Author: Lothar Felten <l-felten@ti.com>
+
+Description
+-----------
+
+The INA219 is a high-side current shunt and power monitor with an I2C
+interface. The INA219 monitors both shunt drop and supply voltage, with
+programmable conversion times and filtering.
+
+The INA226 is a current shunt and power monitor with an I2C interface.
+The INA226 monitors both a shunt voltage drop and bus supply voltage.
+
+The shunt value in micro-ohms can be set via platform data.
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87
index 23b7def21ba8..87850d86c559 100644
--- a/Documentation/hwmon/it87
+++ b/Documentation/hwmon/it87
@@ -30,6 +30,14 @@ Supported chips:
     Prefix: 'it8728'
     Addresses scanned: from Super I/O config space (8 I/O ports)
     Datasheet: Not publicly available
+  * IT8782F
+    Prefix: 'it8782'
+    Addresses scanned: from Super I/O config space (8 I/O ports)
+    Datasheet: Not publicly available
+  * IT8783E/F
+    Prefix: 'it8783'
+    Addresses scanned: from Super I/O config space (8 I/O ports)
+    Datasheet: Not publicly available
   * SiS950   [clone of IT8705F]
     Prefix: 'it87'
     Addresses scanned: from Super I/O config space (8 I/O ports)
@@ -63,7 +71,7 @@ Module Parameters
 Hardware Interfaces
 -------------------
 
-All the chips suported by this driver are LPC Super-I/O chips, accessed
+All the chips supported by this driver are LPC Super-I/O chips, accessed
 through the LPC bus (ISA-like I/O ports). The IT8712F additionally has an
 SMBus interface to the hardware monitoring functions. This driver no
 longer supports this interface though, as it is slower and less reliable
@@ -75,7 +83,8 @@ Description
 -----------
 
 This driver implements support for the IT8705F, IT8712F, IT8716F,
-IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E and SiS950 chips.
+IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8781F, IT8782F,
+IT8783E/F, and SiS950 chips.
 
 These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
 joysticks and other miscellaneous stuff. For hardware monitoring, they
@@ -99,11 +108,11 @@ The IT8716F, IT8718F, IT8720F, IT8721F/IT8758E and later IT8712F revisions
 have support for 2 additional fans. The additional fans are supported by the
 driver.
 
-The IT8716F, IT8718F, IT8720F and IT8721F/IT8758E, and late IT8712F and
-IT8705F also have optional 16-bit tachometer counters for fans 1 to 3. This
-is better (no more fan clock divider mess) but not compatible with the older
-chips and revisions. The 16-bit tachometer mode is enabled by the driver when
-one of the above chips is detected.
+The IT8716F, IT8718F, IT8720F, IT8721F/IT8758E, IT8782F, IT8783E/F, and late
+IT8712F and IT8705F also have optional 16-bit tachometer counters for fans 1 to
+3. This is better (no more fan clock divider mess) but not compatible with the
+older chips and revisions. The 16-bit tachometer mode is enabled by the driver
+when one of the above chips is detected.
 
 The IT8726F is just bit enhanced IT8716F with additional hardware
 for AMD power sequencing. Therefore the chip will appear as IT8716F
@@ -131,9 +140,10 @@ inputs can measure voltages between 0 and 4.08 volts, with a resolution of
 0.016 volt (except IT8721F/IT8758E and IT8728F: 0.012 volt.) The battery
 voltage in8 does not have limit registers.
 
-On the IT8721F/IT8758E, some voltage inputs are internal and scaled inside
-the chip (in7, in8 and optionally in3). The driver handles this transparently
-so user-space doesn't have to care.
+On the IT8721F/IT8758E, IT8782F, and IT8783E/F, some voltage inputs are
+internal and scaled inside the chip (in7 (optional for IT8782F and IT8783E/F),
+in8 and optionally in3). The driver handles this transparently so user-space
+doesn't have to care.
 
 The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value:
 the voltage level your processor should work with. This is hardcoded by
diff --git a/Documentation/hwmon/wm831x b/Documentation/hwmon/wm831x
index 24f47d8f6a42..11446757c8c8 100644
--- a/Documentation/hwmon/wm831x
+++ b/Documentation/hwmon/wm831x
@@ -22,7 +22,7 @@ reporting of all the input values but does not provide any alarms.
 Voltage Monitoring
 ------------------
 
-Voltages are sampled by a 12 bit ADC.  Voltages in milivolts are 1.465
+Voltages are sampled by a 12 bit ADC.  Voltages in millivolts are 1.465
 times the ADC value.
 
 Temperature Monitoring
diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality
index 42c17c1fb3cd..b0ff2ab596ce 100644
--- a/Documentation/i2c/functionality
+++ b/Documentation/i2c/functionality
@@ -18,9 +18,9 @@ For the most up-to-date list of functionality constants, please check
                                   adapters typically can not do these)
   I2C_FUNC_10BIT_ADDR             Handles the 10-bit address extensions
   I2C_FUNC_PROTOCOL_MANGLING      Knows about the I2C_M_IGNORE_NAK,
-                                  I2C_M_REV_DIR_ADDR, I2C_M_NOSTART and
-                                  I2C_M_NO_RD_ACK flags (which modify the
-                                  I2C protocol!)
+                                  I2C_M_REV_DIR_ADDR and I2C_M_NO_RD_ACK
+                                  flags (which modify the I2C protocol!)
+  I2C_FUNC_NOSTART                Can skip repeated start sequence
   I2C_FUNC_SMBUS_QUICK            Handles the SMBus write_quick command
   I2C_FUNC_SMBUS_READ_BYTE        Handles the SMBus read_byte command
   I2C_FUNC_SMBUS_WRITE_BYTE       Handles the SMBus write_byte command
@@ -50,6 +50,9 @@ A few combinations of the above flags are also defined for your convenience:
                                   emulated by a real I2C adapter (using
                                   the transparent emulation layer)
 
+In kernel versions prior to 3.5 I2C_FUNC_NOSTART was implemented as
+part of I2C_FUNC_PROTOCOL_MANGLING.
+
 
 ADAPTER IMPLEMENTATION
 ----------------------
diff --git a/Documentation/i2c/i2c-protocol b/Documentation/i2c/i2c-protocol
index 10518dd58814..0b3e62d1f77a 100644
--- a/Documentation/i2c/i2c-protocol
+++ b/Documentation/i2c/i2c-protocol
@@ -49,7 +49,9 @@ a byte read, followed by a byte write:
 Modified transactions
 =====================
 
-We have found some I2C devices that needs the following modifications:
+The following modifications to the I2C protocol can also be generated,
+with the exception of I2C_M_NOSTART these are usually only needed to
+work around device issues:
 
   Flag I2C_M_NOSTART: 
     In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some
@@ -60,6 +62,11 @@ We have found some I2C devices that needs the following modifications:
     we do not generate Addr, but we do generate the startbit S. This will
     probably confuse all other clients on your bus, so don't try this.
 
+    This is often used to gather transmits from multiple data buffers in
+    system memory into something that appears as a single transfer to the
+    I2C device but may also be used between direction changes by some
+    rare devices.
+
   Flags I2C_M_REV_DIR_ADDR
     This toggles the Rd/Wr flag. That is, if you want to do a write, but
     need to emit an Rd instead of a Wr, or vice versa, you set this
diff --git a/Documentation/i2c/muxes/gpio-i2cmux b/Documentation/i2c/muxes/i2c-mux-gpio
index 811cd78d4cdc..bd9b2299b739 100644
--- a/Documentation/i2c/muxes/gpio-i2cmux
+++ b/Documentation/i2c/muxes/i2c-mux-gpio
@@ -1,11 +1,11 @@
-Kernel driver gpio-i2cmux
+Kernel driver i2c-gpio-mux
 
 Author: Peter Korsgaard <peter.korsgaard@barco.com>
 
 Description
 -----------
 
-gpio-i2cmux is an i2c mux driver providing access to I2C bus segments
+i2c-gpio-mux is an i2c mux driver providing access to I2C bus segments
 from a master I2C bus and a hardware MUX controlled through GPIO pins.
 
 E.G.:
@@ -26,16 +26,16 @@ according to the settings of the GPIO pins 1..N.
 Usage
 -----
 
-gpio-i2cmux uses the platform bus, so you need to provide a struct
+i2c-gpio-mux uses the platform bus, so you need to provide a struct
 platform_device with the platform_data pointing to a struct
 gpio_i2cmux_platform_data with the I2C adapter number of the master
 bus, the number of bus segments to create and the GPIO pins used
-to control it. See include/linux/gpio-i2cmux.h for details.
+to control it. See include/linux/i2c-gpio-mux.h for details.
 
 E.G. something like this for a MUX providing 4 bus segments
 controlled through 3 GPIO pins:
 
-#include <linux/gpio-i2cmux.h>
+#include <linux/i2c-gpio-mux.h>
 #include <linux/platform_device.h>
 
 static const unsigned myboard_gpiomux_gpios[] = {
@@ -57,7 +57,7 @@ static struct gpio_i2cmux_platform_data myboard_i2cmux_data = {
 };
 
 static struct platform_device myboard_i2cmux = {
-        .name           = "gpio-i2cmux",
+        .name           = "i2c-gpio-mux",
         .id             = 0,
         .dev            = {
                 .platform_data  = &myboard_i2cmux_data,
diff --git a/Documentation/initrd.txt b/Documentation/initrd.txt
index 1ba84f3584e3..4e1839ccb555 100644
--- a/Documentation/initrd.txt
+++ b/Documentation/initrd.txt
@@ -362,5 +362,5 @@ Resources
     http://www.almesberger.net/cv/papers/ols2k-9.ps.gz
 [2] newlib package (experimental), with initrd example
     http://sources.redhat.com/newlib/
-[3] Brouwer, Andries; "util-linux: Miscellaneous utilities for Linux"
-    ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/
+[3] util-linux: Miscellaneous utilities for Linux
+    http://www.kernel.org/pub/linux/utils/util-linux/
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index e34b531dc316..915f28c470e9 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -120,6 +120,7 @@ Code  Seq#(hex)	Include File		Comments
 'G'     00-0F   linux/gigaset_dev.h     conflict!
 'H'     00-7F   linux/hiddev.h          conflict!
 'H'     00-0F   linux/hidraw.h          conflict!
+'H'     01      linux/mei.h             conflict!
 'H'     00-0F   sound/asound.h          conflict!
 'H'     20-40   sound/asound_fm.h       conflict!
 'H'     80-8F   sound/sfnt_info.h       conflict!
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt
index 68e32bb6bd80..6466704d47b5 100644
--- a/Documentation/kbuild/kbuild.txt
+++ b/Documentation/kbuild/kbuild.txt
@@ -50,6 +50,10 @@ LDFLAGS_MODULE
 --------------------------------------------------
 Additional options used for $(LD) when linking modules.
 
+LDFLAGS_vmlinux
+--------------------------------------------------
+Additional options passed to final link of vmlinux.
+
 KBUILD_VERBOSE
 --------------------------------------------------
 Set the kbuild verbosity. Can be assigned same values as "V=...".
@@ -214,3 +218,18 @@ KBUILD_BUILD_USER, KBUILD_BUILD_HOST
 These two variables allow to override the user@host string displayed during
 boot and in /proc/version. The default value is the output of the commands
 whoami and host, respectively.
+
+KBUILD_LDS
+--------------------------------------------------
+The linker script with full path. Assigned by the top-level Makefile.
+
+KBUILD_VMLINUX_INIT
+--------------------------------------------------
+All object files for the init (first) part of vmlinux.
+Files specified with KBUILD_VMLINUX_INIT are linked first.
+
+KBUILD_VMLINUX_MAIN
+--------------------------------------------------
+All object files for the main part of vmlinux.
+KBUILD_VMLINUX_INIT and KBUILD_VMLINUX_MAIN together specify
+all the object files used to link vmlinux.
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index 9d5f2a90dca9..a09f1a6a830c 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -53,15 +53,15 @@ KCONFIG_ALLCONFIG
 --------------------------------------------------
 (partially based on lkml email from/by Rob Landley, re: miniconfig)
 --------------------------------------------------
-The allyesconfig/allmodconfig/allnoconfig/randconfig variants can
-also use the environment variable KCONFIG_ALLCONFIG as a flag or a
-filename that contains config symbols that the user requires to be
-set to a specific value.  If KCONFIG_ALLCONFIG is used without a
-filename, "make *config" checks for a file named
-"all{yes/mod/no/def/random}.config" (corresponding to the *config command
-that was used) for symbol values that are to be forced.  If this file
-is not found, it checks for a file named "all.config" to contain forced
-values.
+The allyesconfig/allmodconfig/allnoconfig/randconfig variants can also
+use the environment variable KCONFIG_ALLCONFIG as a flag or a filename
+that contains config symbols that the user requires to be set to a
+specific value.  If KCONFIG_ALLCONFIG is used without a filename where
+KCONFIG_ALLCONFIG == "" or KCONFIG_ALLCONFIG == "1", "make *config"
+checks for a file named "all{yes/mod/no/def/random}.config"
+(corresponding to the *config command that was used) for symbol values
+that are to be forced.  If this file is not found, it checks for a
+file named "all.config" to contain forced values.
 
 This enables you to create "miniature" config (miniconfig) or custom
 config files containing just the config symbols that you are interested
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 506c7390c2b9..13f1aa09b938 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -86,7 +86,7 @@ There is also a gitweb interface available at
 http://www.kernel.org/git/?p=utils/kernel/kexec/kexec-tools.git
 
 More information about kexec-tools can be found at
-http://www.kernel.org/pub/linux/utils/kernel/kexec/README.html
+http://horms.net/projects/kexec/
 
 3) Unpack the tarball with the tar command, as follows:
 
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index c1601e5a8b71..a92c5ebf373e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -70,7 +70,6 @@ parameter is applicable:
         M68k    M68k architecture is enabled.
                         These options have more detailed description inside of
                         Documentation/m68k/kernel-options.txt.
-        MCA     MCA bus support is enabled.
         MDA     MDA console support is enabled.
         MIPS    MIPS architecture is enabled.
         MOUSE   Appropriate mouse support is enabled.
@@ -110,6 +109,7 @@ parameter is applicable:
         USB     USB support is enabled.
         USBHID  USB Human Interface Device support is enabled.
         V4L     Video For Linux support is enabled.
+        VMMIO   Driver for memory mapped virtio devices is enabled.
         VGA     The VGA console has been enabled.
         VT      Virtual terminal support is enabled.
         WDT     Watchdog support is enabled.
@@ -335,6 +335,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                                           requirements as needed. This option
                                           does not override iommu=pt
 
+        amd_iommu_dump= [HW,X86-64]
+                        Enable AMD IOMMU driver option to dump the ACPI table
+                        for AMD IOMMU. With this option enabled, AMD IOMMU
+                        driver will print ACPI tables for AMD IOMMU during
+                        IOMMU initialization.
+
         amijoy.map=     [HW,JOY] Amiga joystick support
                         Map of devices attached to JOY0DAT and JOY1DAT
                         Format: <a>,<b>
@@ -397,8 +403,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         atkbd.softrepeat= [HW]
                         Use software keyboard repeat
 
-        autotest        [IA-64]
-
         baycom_epp=     [HW,AX25]
                         Format: <io>,<mode>
 
@@ -508,6 +512,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         Also note the kernel might malfunction if you disable
                         some critical bits.
 
+        cma=nn[MG]      [ARM,KNL]
+                        Sets the size of kernel global memory area for contiguous
+                        memory allocations. For more information, see
+                        include/linux/dma-contiguous.h
+
         cmo_free_hint=  [PPC] Format: { yes | no }
                         Specify whether pages are marked as being inactive
                         when they are freed.  This is used in CMO environments
@@ -515,6 +524,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         a hypervisor.
                         Default: yes
 
+        coherent_pool=nn[KMG]   [ARM,KNL]
+                        Sets the size of memory pool for coherent, atomic dma
+                        allocations if Contiguous Memory Allocator (CMA) is used.
+
         code_bytes      [X86] How many bytes of object code to print
                         in an oops report.
                         Range: 0 - 8192
@@ -610,7 +623,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
         ddebug_query=   [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
                         time. See Documentation/dynamic-debug-howto.txt for
-                        details.
+                        details.  Deprecated, see dyndbg.
 
         debug           [KNL] Enable kernel debugging (events log level).
 
@@ -730,6 +743,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
         dscc4.setup=    [NET]
 
+        dyndbg[="val"]          [KNL,DYNAMIC_DEBUG]
+        module.dyndbg[="val"]
+                        Enable debug messages at boot time.  See
+                        Documentation/dynamic-debug-howto.txt for details.
+
         earlycon=       [KNL] Output early console device and options.
                 uart[8250],io,<addr>[,options]
                 uart[8250],mmio,<addr>[,options]
@@ -982,6 +1000,20 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         i8k.restricted  [HW] Allow controlling fans only if SYS_ADMIN
                         capability is set.
 
+        i915.invert_brightness=
+                        [DRM] Invert the sense of the variable that is used to
+                        set the brightness of the panel backlight. Normally a
+                        brightness value of 0 indicates backlight switched off,
+                        and the maximum of the brightness value sets the backlight
+                        to maximum brightness. If this parameter is set to 0
+                        (default) and the machine requires it, or this parameter
+                        is set to 1, a brightness value of 0 sets the backlight
+                        to maximum brightness, and the maximum of the brightness
+                        value switches the backlight off.
+                        -1 -- never invert brightness
+                         0 -- machine default
+                         1 -- force brightness inversion
+
         icn=            [HW,ISDN]
                         Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
 
@@ -1425,8 +1457,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         devices can be requested on-demand with the
                         /dev/loop-control interface.
 
-        mcatest=        [IA-64]
-
         mce             [X86-32] Machine Check Exception
 
         mce=option      [X86-64] See Documentation/x86/x86_64/boot-options.txt
@@ -2161,6 +2191,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                                 on: Turn realloc on
                 realloc         same as realloc=on
                 noari           do not use PCIe ARI.
+                pcie_scan_all   Scan all possible PCIe devices.  Otherwise we
+                                only look for one device below a PCIe downstream
+                                port.
 
         pcie_aspm=      [PCIE] Forcibly enable or disable PCIe Active State Power
                         Management.
@@ -2330,18 +2363,100 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         ramdisk_size=   [RAM] Sizes of RAM disks in kilobytes
                         See Documentation/blockdev/ramdisk.txt.
 
-        rcupdate.blimit=        [KNL,BOOT]
+        rcutree.blimit= [KNL,BOOT]
                         Set maximum number of finished RCU callbacks to process
                         in one batch.
 
-        rcupdate.qhimark=       [KNL,BOOT]
+        rcutree.qhimark=        [KNL,BOOT]
                         Set threshold of queued
                         RCU callbacks over which batch limiting is disabled.
 
-        rcupdate.qlowmark=      [KNL,BOOT]
+        rcutree.qlowmark=       [KNL,BOOT]
                         Set threshold of queued RCU callbacks below which
                         batch limiting is re-enabled.
 
+        rcutree.rcu_cpu_stall_suppress= [KNL,BOOT]
+                        Suppress RCU CPU stall warning messages.
+
+        rcutree.rcu_cpu_stall_timeout= [KNL,BOOT]
+                        Set timeout for RCU CPU stall warning messages.
+
+        rcutorture.fqs_duration= [KNL,BOOT]
+                        Set duration of force_quiescent_state bursts.
+
+        rcutorture.fqs_holdoff= [KNL,BOOT]
+                        Set holdoff time within force_quiescent_state bursts.
+
+        rcutorture.fqs_stutter= [KNL,BOOT]
+                        Set wait time between force_quiescent_state bursts.
+
+        rcutorture.irqreader= [KNL,BOOT]
+                        Test RCU readers from irq handlers.
+
+        rcutorture.n_barrier_cbs= [KNL,BOOT]
+                        Set callbacks/threads for rcu_barrier() testing.
+
+        rcutorture.nfakewriters= [KNL,BOOT]
+                        Set number of concurrent RCU writers.  These just
+                        stress RCU, they don't participate in the actual
+                        test, hence the "fake".
+
+        rcutorture.nreaders= [KNL,BOOT]
+                        Set number of RCU readers.
+
+        rcutorture.onoff_holdoff= [KNL,BOOT]
+                        Set time (s) after boot for CPU-hotplug testing.
+
+        rcutorture.onoff_interval= [KNL,BOOT]
+                        Set time (s) between CPU-hotplug operations, or
+                        zero to disable CPU-hotplug testing.
+
+        rcutorture.shuffle_interval= [KNL,BOOT]
+                        Set task-shuffle interval (s).  Shuffling tasks
+                        allows some CPUs to go into dyntick-idle mode
+                        during the rcutorture test.
+
+        rcutorture.shutdown_secs= [KNL,BOOT]
+                        Set time (s) after boot system shutdown.  This
+                        is useful for hands-off automated testing.
+
+        rcutorture.stall_cpu= [KNL,BOOT]
+                        Duration of CPU stall (s) to test RCU CPU stall
+                        warnings, zero to disable.
+
+        rcutorture.stall_cpu_holdoff= [KNL,BOOT]
+                        Time to wait (s) after boot before inducing stall.
+
+        rcutorture.stat_interval= [KNL,BOOT]
+                        Time (s) between statistics printk()s.
+
+        rcutorture.stutter= [KNL,BOOT]
+                        Time (s) to stutter testing, for example, specifying
+                        five seconds causes the test to run for five seconds,
+                        wait for five seconds, and so on.  This tests RCU's
+                        ability to transition abruptly to and from idle.
+
+        rcutorture.test_boost= [KNL,BOOT]
+                        Test RCU priority boosting?  0=no, 1=maybe, 2=yes.
+                        "Maybe" means test if the RCU implementation
+                        under test support RCU priority boosting.
+
+        rcutorture.test_boost_duration= [KNL,BOOT]
+                        Duration (s) of each individual boost test.
+
+        rcutorture.test_boost_interval= [KNL,BOOT]
+                        Interval (s) between each boost test.
+
+        rcutorture.test_no_idle_hz= [KNL,BOOT]
+                        Test RCU's dyntick-idle handling.  See also the
+                        rcutorture.shuffle_interval parameter.
+
+        rcutorture.torture_type= [KNL,BOOT]
+                        Specify the RCU implementation to test.
+
+        rcutorture.verbose= [KNL,BOOT]
+                        Enable additional printk() statements.
+
         rdinit=         [KNL]
                         Format: <full_path>
                         Run specified binary instead of /init from the ramdisk,
@@ -2372,6 +2487,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
         resume=         [SWSUSP]
                         Specify the partition device for software suspend
+                        Format:
+                        {/dev/<dev> | PARTUUID=<uuid> | <int>:<int> | <hex>}
 
         resume_offset=  [SWSUSP]
                         Specify the offset from the beginning of the partition
@@ -2426,6 +2543,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
         sched_debug     [KNL] Enables verbose scheduler debug messages.
 
+        skew_tick=      [KNL] Offset the periodic timer tick per cpu to mitigate
+                        xtime_lock contention on larger systems, and/or RCU lock
+                        contention on all systems with CONFIG_MAXSMP set.
+                        Format: { "0" | "1" }
+                        0 -- disable. (may be 1 via CONFIG_CMDLINE="skew_tick=1"
+                        1 -- enable.
+                        Note: increases power consumption, thus should only be
+                        enabled if running jitter sensitive (HPC/RT) workloads.
+
         security=       [SECURITY] Choose a security module to enable at boot.
                         If this boot parameter is not specified, only the first
                         security module asking for security registration will be
@@ -2847,6 +2973,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         video=          [FB] Frame buffer configuration
                         See Documentation/fb/modedb.txt.
 
+        virtio_mmio.device=
+                        [VMMIO] Memory mapped virtio (platform) device.
+
+                                <size>@<baseaddr>:<irq>[:<id>]
+                        where:
+                                <size>     := size (can use standard suffixes
+                                                like K, M and G)
+                                <baseaddr> := physical base address
+                                <irq>      := interrupt number (as passed to
+                                                request_irq())
+                                <id>       := (optional) platform device id
+                        example:
+                                virtio_mmio.device=1K@0x100b0000:48:7
+
+                        Can be used multiple times for multiple devices.
+
         vga=            [BOOT,X86-32] Select a particular video mode
                         See Documentation/x86/boot.txt and
                         Documentation/svga.txt.
diff --git a/Documentation/leds/ledtrig-transient.txt b/Documentation/leds/ledtrig-transient.txt
new file mode 100644
index 000000000000..3bd38b487df1
--- /dev/null
+++ b/Documentation/leds/ledtrig-transient.txt
@@ -0,0 +1,152 @@
+LED Transient Trigger
+=====================
+
+The leds timer trigger does not currently have an interface to activate
+a one shot timer. The current support allows for setting two timers, one for
+specifying how long a state to be on, and the second for how long the state
+to be off. The delay_on value specifies the time period an LED should stay
+in on state, followed by a delay_off value that specifies how long the LED
+should stay in off state. The on and off cycle repeats until the trigger
+gets deactivated. There is no provision for one time activation to implement
+features that require an on or off state to be held just once and then stay in
+the original state forever.
+
+Without one shot timer interface, user space can still use timer trigger to
+set a timer to hold a state, however when user space application crashes or
+goes away without deactivating the timer, the hardware will be left in that
+state permanently.
+
+As a specific example of this use-case, let's look at vibrate feature on
+phones. Vibrate function on phones is implemented using PWM pins on SoC or
+PMIC. There is a need to activate one shot timer to control the vibrate
+feature, to prevent user space crashes leaving the phone in vibrate mode
+permanently causing the battery to drain.
+
+Transient trigger addresses the need for one shot timer activation. The
+transient trigger can be enabled and disabled just like the other leds
+triggers.
+
+When an led class device driver registers itself, it can specify all leds
+triggers it supports and a default trigger. During registration, activation
+routine for the default trigger gets called. During registration of an led
+class device, the LED state does not change.
+
+When the driver unregisters, deactivation routine for the currently active
+trigger will be called, and LED state is changed to LED_OFF.
+
+Driver suspend changes the LED state to LED_OFF and resume doesn't change
+the state. Please note that there is no explicit interaction between the
+suspend and resume actions and the currently enabled trigger. LED state
+changes are suspended while the driver is in suspend state. Any timers
+that are active at the time driver gets suspended, continue to run, without
+being able to actually change the LED state. Once driver is resumed, triggers
+start functioning again.
+
+LED state changes are controlled using brightness which is a common led
+class device property. When brightness is set to 0 from user space via
+echo 0 > brightness, it will result in deactivating the current trigger.
+
+Transient trigger uses standard register and unregister interfaces. During
+trigger registration, for each led class device that specifies this trigger
+as its default trigger, trigger activation routine will get called. During
+registration, the LED state does not change, unless there is another trigger
+active, in which case LED state changes to LED_OFF.
+
+During trigger unregistration, LED state gets changed to LED_OFF.
+
+Transient trigger activation routine doesn't change the LED state. It
+creates its properties and does its initialization. Transient trigger
+deactivation routine, will cancel any timer that is active before it cleans
+up and removes the properties it created. It will restore the LED state to
+non-transient state. When driver gets suspended, irrespective of the transient
+state, the LED state changes to LED_OFF.
+
+Transient trigger can be enabled and disabled from user space on led class
+devices, that support this trigger as shown below:
+
+echo transient > trigger
+echo none > trigger
+
+NOTE: Add a new property trigger state to control the state.
+
+This trigger exports three properties, activate, state, and duration. When
+transient trigger is activated these properties are set to default values.
+
+- duration allows setting timer value in msecs. The initial value is 0.
+- activate allows activating and deactivating the timer specified by
+  duration as needed. The initial and default value is 0.  This will allow
+  duration to be set after trigger activation.
+- state allows user to specify a transient state to be held for the specified
+  duration.
+
+        activate - one shot timer activate mechanism.
+                1 when activated, 0 when deactivated.
+                default value is zero when transient trigger is enabled,
+                to allow duration to be set.
+
+                activate state indicates a timer with a value of specified
+                duration running.
+                deactivated state indicates that there is no active timer
+                running.
+
+        duration - one shot timer value. When activate is set, duration value
+                is used to start a timer that runs once. This value doesn't
+                get changed by the trigger unless user does a set via
+                echo new_value > duration
+
+        state - transient state to be held. It has two values 0 or 1. 0 maps
+                to LED_OFF and 1 maps to LED_FULL. The specified state is
+                held for the duration of the one shot timer and then the
+                state gets changed to the non-transient state which is the
+                inverse of transient state.
+                If state = LED_FULL, when the timer runs out the state will
+                go back to LED_OFF.
+                If state = LED_OFF, when the timer runs out the state will
+                go back to LED_FULL.
+                Please note that current LED state is not checked prior to
+                changing the state to the specified state.
+                Driver could map these values to inverted depending on the
+                default states it defines for the LED in its brightness_set()
+                interface which is called from the led brightness_set()
+                interfaces to control the LED state.
+
+When timer expires activate goes back to deactivated state, duration is left
+at the set value to be used when activate is set at a future time. This will
+allow user app to set the time once and activate it to run it once for the
+specified value as needed. When timer expires, state is restored to the
+non-transient state which is the inverse of the transient state.
+
+        echo 1 > activate - starts timer = duration when duration is not 0.
+        echo 0 > activate - cancels currently running timer.
+        echo n > duration - stores timer value to be used upon next
+                            activate. Currently active timer if
+                            any, continues to run for the specified time.
+        echo 0 > duration - stores timer value to be used upon next
+                            activate. Currently active timer if any,
+                            continues to run for the specified time.
+        echo 1 > state    - stores desired transient state LED_FULL to be
+                            held for the specified duration.
+        echo 0 > state    - stores desired transient state LED_OFF to be
+                            held for the specified duration.
+
+What is not supported:
+======================
+- Timer activation is one shot and extending and/or shortening the timer
+  is not supported.
+
+Example use-case 1:
+        echo transient > trigger
+        echo n > duration
+        echo 1 > state
+repeat the following step as needed:
+        echo 1 > activate - start timer = duration to run once
+        echo 1 > activate - start timer = duration to run once
+        echo none > trigger
+
+This trigger is intended to be used for for the following example use cases:
+ - Control of vibrate (phones, tablets etc.) hardware by user space app.
+ - Use of LED by user space app as activity indicator.
+ - Use of LED by user space app as a kind of watchdog indicator -- as
+       long as the app is alive, it can keep the LED illuminated, if it dies
+       the LED will be extinguished automatically.
+ - Use by any user space app that needs a transient GPIO output.
diff --git a/Documentation/mca.txt b/Documentation/mca.txt
deleted file mode 100644
index dfd130c2207d..000000000000
--- a/Documentation/mca.txt
+++ /dev/null
@@ -1,313 +0,0 @@
-i386 Micro Channel Architecture Support
-=======================================
-
-MCA support is enabled using the CONFIG_MCA define.  A machine with a MCA
-bus will have the kernel variable MCA_bus set, assuming the BIOS feature
-bits are set properly (see arch/i386/boot/setup.S for information on
-how this detection is done).
-
-Adapter Detection
-=================
-
-The ideal MCA adapter detection is done through the use of the
-Programmable Option Select registers.  Generic functions for doing
-this have been added in include/linux/mca.h and arch/x86/kernel/mca_32.c.
-Everything needed to detect adapters and read (and write) configuration
-information is there.  A number of MCA-specific drivers already use
-this.  The typical probe code looks like the following:
-
-        #include <linux/mca.h>
-
-        unsigned char pos2, pos3, pos4, pos5;
-        struct net_device* dev;
-        int slot;
-
-        if( MCA_bus ) {
-                slot = mca_find_adapter( ADAPTER_ID, 0 );
-                if( slot == MCA_NOTFOUND ) {
-                        return -ENODEV;
-                }
-                /* optional - see below */
-                mca_set_adapter_name( slot, "adapter name & description" );
-                mca_set_adapter_procfn( slot, dev_getinfo, dev );
-
-                /* read the POS registers.  Most devices only use 2 and 3 */
-                pos2 = mca_read_stored_pos( slot, 2 );
-                pos3 = mca_read_stored_pos( slot, 3 );
-                pos4 = mca_read_stored_pos( slot, 4 );
-                pos5 = mca_read_stored_pos( slot, 5 );
-        } else {
-                return -ENODEV;
-        }
-
-        /* extract configuration from pos[2345] and set everything up */
-
-Loadable modules should modify this to test that the specified IRQ and
-IO ports (plus whatever other stuff) match.  See 3c523.c for example
-code (actually, smc-mca.c has a slightly more complex example that can
-handle a list of adapter ids).
-
-Keep in mind that devices should never directly access the POS registers
-(via inb(), outb(), etc).  While it's generally safe, there is a small
-potential for blowing up hardware when it's done at the wrong time.
-Furthermore, accessing a POS register disables a device temporarily.
-This is usually okay during startup, but do _you_ want to rely on it?
-During initial configuration, mca_init() reads all the POS registers
-into memory.  mca_read_stored_pos() accesses that data.  mca_read_pos()
-and mca_write_pos() are also available for (safer) direct POS access,
-but their use is _highly_ discouraged.  mca_write_pos() is particularly
-dangerous, as it is possible for adapters to be put in inconsistent
-states (i.e. sharing IO address, etc) and may result in crashes, toasted
-hardware, and blindness.
-
-User level drivers (such as the AGX X server) can use /proc/mca/pos to
-find adapters (see below).
-
-Some MCA adapters can also be detected via the usual ISA-style device
-probing (many SCSI adapters, for example).  This sort of thing is highly
-discouraged.  Perfectly good information is available telling you what's
-there, so there's no excuse for messing with random IO ports.  However,
-we MCA people still appreciate any ISA-style driver that will work with
-our hardware.  You take what you can get...
-
-Level-Triggered Interrupts
-==========================
-
-Because MCA uses level-triggered interrupts, a few problems arise with
-what might best be described as the ISA mindset and its effects on
-drivers.  These sorts of problems are expected to become less common as
-more people use shared IRQs on PCI machines.
-
-In general, an interrupt must be acknowledged not only at the ICU (which
-is done automagically by the kernel), but at the device level.  In
-particular, IRQ 0 must be reset after a timer interrupt (now done in
-arch/x86/kernel/time.c) or the first timer interrupt hangs the system.
-There were also problems with the 1.3.x floppy drivers, but that seems
-to have been fixed.
-
-IRQs are also shareable, and most MCA-specific devices should be coded
-with shared IRQs in mind.
-
-/proc/mca
-=========
-
-/proc/mca is a directory containing various files for adapters and
-other stuff.
-
-        /proc/mca/pos           Straight listing of POS registers
-        /proc/mca/slot[1-8]     Information on adapter in specific slot
-        /proc/mca/video         Same for integrated video
-        /proc/mca/scsi          Same for integrated SCSI
-        /proc/mca/machine       Machine information
-
-See Appendix A for a sample.
-
-Device drivers can easily add their own information function for
-specific slots (including integrated ones) via the
-mca_set_adapter_procfn() call.  Drivers that support this are ESDI, IBM
-SCSI, and 3c523.  If a device is also a module, make sure that the proc
-function is removed in the module cleanup.  This will require storing
-the slot information in a private structure somewhere.  See the 3c523
-driver for details.
-
-Your typical proc function will look something like this:
-
-        static int
-        dev_getinfo( char* buf, int slot, void* d ) {
-                struct net_device* dev = (struct net_device*) d;
-                int len = 0;
-
-                len += sprintf( buf+len, "Device: %s\n", dev->name );
-                len += sprintf( buf+len, "IRQ: %d\n", dev->irq );
-                len += sprintf( buf+len, "IO Port: %#lx-%#lx\n", ... );
-                ...
-
-                return len;
-        }
-
-Some of the standard MCA information will already be printed, so don't
-bother repeating it.  Don't try putting in more than 3K of information.
-
-Enable this function with:
-        mca_set_adapter_procfn( slot, dev_getinfo, dev );
-
-Disable it with:
-        mca_set_adapter_procfn( slot, NULL, NULL );
-
-It is also recommended that, even if you don't write a proc function, to
-set the name of the adapter (i.e. "PS/2 ESDI Controller") via
-mca_set_adapter_name( int slot, char* name ).
-
-MCA Device Drivers
-==================
-
-Currently, there are a number of MCA-specific device drivers.
-
-1) PS/2 SCSI
-        drivers/scsi/ibmmca.c
-        drivers/scsi/ibmmca.h
-   The driver for the IBM SCSI subsystem.  Includes both integrated
-   controllers and adapter cards.  May require command-line arg
-   "ibmmcascsi=io_port" to force detection of an adapter.  If you have a
-   machine with a front-panel display (i.e. model 95), you can use
-   "ibmmcascsi=display" to enable a drive activity indicator.
-
-2) 3c523
-        drivers/net/3c523.c
-        drivers/net/3c523.h
-   3Com 3c523 Etherlink/MC ethernet driver.
-
-3) SMC Ultra/MCA and IBM Adapter/A
-        drivers/net/smc-mca.c
-        drivers/net/smc-mca.h
-        Driver for the MCA version of the SMC Ultra and various other
-        OEM'ed and work-alike cards (Elite, Adapter/A, etc).
-
-4) NE/2
-        driver/net/ne2.c
-        driver/net/ne2.h
-        The NE/2 is the MCA version of the NE2000.  This may not work
-        with clones that have a different adapter id than the original
-        NE/2.
-
-5) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Adapter/A and
-   Reply Sound Blaster/SCSI (SCSI part)
-        Better support for these cards than the driver for ISA.
-   Supports multiple cards with IRQ sharing.
-
-Also added boot time option of scsi-probe, which can do reordering of
-SCSI host adapters. This will direct the kernel on the order which
-SCSI adapter should be detected. Example:
-  scsi-probe=ibmmca,fd_mcs,adaptec1542,buslogic
-
-The serial drivers were modified to support the extended IO port range
-of the typical MCA system (also #ifdef CONFIG_MCA).
-
-The following devices work with existing drivers:
-1) Token-ring
-2) Future Domain SCSI (MCS-600, MCS-700, not MCS-350, OEM'ed IBM SCSI)
-3) Adaptec 1640 SCSI (using the aha1542 driver)
-4) Bustek/Buslogic SCSI (various)
-5) Probably all Arcnet cards.
-6) Some, possibly all, MCA IDE controllers.
-7) 3Com 3c529 (MCA version of 3c509) (patched)
-
-8) Intel EtherExpressMC  (patched version)
-   You need to have CONFIG_MCA defined to have EtherExpressMC support.
-9) Reply Sound Blaster/SCSI (SB part) (patched version)
-
-Bugs & Other Weirdness
-======================
-
-NMIs tend to occur with MCA machines because of various hardware
-weirdness, bus timeouts, and many other non-critical things.  Some basic
-code to handle them (inspired by the NetBSD MCA code) has been added to
-detect the guilty device, but it's pretty incomplete.  If NMIs are a
-persistent problem (on some model 70 or 80s, they occur every couple
-shell commands), the CONFIG_IGNORE_NMI flag will take care of that.
-
-Various Pentium machines have had serious problems with the FPU test in
-bugs.h.  Basically, the machine hangs after the HLT test.  This occurs,
-as far as we know, on the Pentium-equipped 85s, 95s, and some PC Servers.
-The PCI/MCA PC 750s are fine as far as I can tell.  The ``mca-pentium''
-boot-prompt flag will disable the FPU bug check if this is a problem
-with your machine.
-
-The model 80 has a raft of problems that are just too weird and unique
-to get into here.  Some people have no trouble while others have nothing
-but problems.  I'd suspect some problems are related to the age of the
-average 80 and accompanying hardware deterioration, although others
-are definitely design problems with the hardware.  Among the problems
-include SCSI controller problems, ESDI controller problems, and serious
-screw-ups in the floppy controller.  Oh, and the parallel port is also
-pretty flaky.  There were about 5 or 6 different model 80 motherboards
-produced to fix various obscure problems.  As far as I know, it's pretty
-much impossible to tell which bugs a particular model 80 has (other than
-triggering them, that is).
-
-Drivers are required for some MCA memory adapters.  If you're suddenly
-short a few megs of RAM, this might be the reason.  The (I think) Enhanced
-Memory Adapter commonly found on the model 70 is one.  There's a very
-alpha driver floating around, but it's pretty ugly (disassembled from
-the DOS driver, actually).  See the MCA Linux web page (URL below)
-for more current memory info.
-
-The Thinkpad 700 and 720 will work, but various components are either
-non-functional, flaky, or we don't know anything about them.  The
-graphics controller is supposed to be some WD, but we can't get things
-working properly.  The PCMCIA slots don't seem to work.  Ditto for APM.
-The serial ports work, but detection seems to be flaky.
-
-Credits
-=======
-A whole pile of people have contributed to the MCA code.  I'd include
-their names here, but I don't have a list handy.  Check the MCA Linux
-home page (URL below) for a perpetually out-of-date list.
-
-=====================================================================
-MCA Linux Home Page: http://www.dgmicro.com/mca/
-
-Christophe Beauregard
-chrisb@truespectra.com
-cpbeaure@calum.csclub.uwaterloo.ca
-
-=====================================================================
-Appendix A: Sample /proc/mca
-
-This is from my model 8595.  Slot 1 contains the standard IBM SCSI
-adapter, slot 3 is an Adaptec AHA-1640, slot 5 is a XGA-1 video adapter,
-and slot 7 is the 3c523 Etherlink/MC.
-
-/proc/mca/machine:
-Model Id: 0xf8
-Submodel Id: 0x14
-BIOS Revision: 0x5
-
-/proc/mca/pos:
-Slot 1: ff 8e f1 fc a0 ff ff ff  IBM SCSI Adapter w/Cache
-Slot 2: ff ff ff ff ff ff ff ff  
-Slot 3: 1f 0f 81 3b bf b6 ff ff  
-Slot 4: ff ff ff ff ff ff ff ff  
-Slot 5: db 8f 1d 5e fd c0 00 00  
-Slot 6: ff ff ff ff ff ff ff ff  
-Slot 7: 42 60 ff 08 ff ff ff ff  3Com 3c523 Etherlink/MC
-Slot 8: ff ff ff ff ff ff ff ff  
-Video : ff ff ff ff ff ff ff ff  
-SCSI  : ff ff ff ff ff ff ff ff  
-
-/proc/mca/slot1:
-Slot: 1
-Adapter Name: IBM SCSI Adapter w/Cache
-Id: 8eff
-Enabled: Yes
-POS: ff 8e f1 fc a0 ff ff ff 
-Subsystem PUN: 7
-Detected at boot: Yes
-
-/proc/mca/slot3:
-Slot: 3
-Adapter Name: Unknown
-Id: 0f1f
-Enabled: Yes
-POS: 1f 0f 81 3b bf b6 ff ff 
-
-/proc/mca/slot5:
-Slot: 5
-Adapter Name: Unknown
-Id: 8fdb
-Enabled: Yes
-POS: db 8f 1d 5e fd c0 00 00 
-
-/proc/mca/slot7:
-Slot: 7
-Adapter Name: 3Com 3c523 Etherlink/MC
-Id: 6042
-Enabled: Yes
-POS: 42 60 ff 08 ff ff ff ff 
-Revision: 0xe
-IRQ: 9
-IO Address: 0x3300-0x3308
-Memory: 0xd8000-0xdbfff
-Transceiver: External
-Device: eth0
-Hardware Address: 02 60 8c 45 c4 2a
diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt
index 3a0f879533ce..802875413873 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -335,6 +335,9 @@ the media_entity pipe field.
 Calls to media_entity_pipeline_start() can be nested. The pipeline pointer must
 be identical for all nested calls to the function.
 
+media_entity_pipeline_start() may return an error. In that case, it will
+clean up any the changes it did by itself.
+
 When stopping the stream, drivers must notify the entities with
 
         media_entity_pipeline_stop(struct media_entity *entity);
@@ -351,3 +354,19 @@ If other operations need to be disallowed on streaming entities (such as
 changing entities configuration parameters) drivers can explicitly check the
 media_entity stream_count field to find out if an entity is streaming. This
 operation must be done with the media_device graph_mutex held.
+
+
+Link validation
+---------------
+
+Link validation is performed by media_entity_pipeline_start() for any
+entity which has sink pads in the pipeline. The
+media_entity::link_validate() callback is used for that purpose. In
+link_validate() callback, entity driver should check that the properties of
+the source pad of the connected entity and its own sink pad match. It is up
+to the type of the entity (and in the end, the properties of the hardware)
+what matching actually means.
+
+Subsystems should facilitate link validation by providing subsystem specific
+helper functions to provide easy access for commonly needed information, and
+in the end provide a way to use driver-specific callbacks.
diff --git a/Documentation/memory-devices/ti-emif.txt b/Documentation/memory-devices/ti-emif.txt
new file mode 100644
index 000000000000..f4ad9a7d0f4b
--- /dev/null
+++ b/Documentation/memory-devices/ti-emif.txt
@@ -0,0 +1,57 @@
+TI EMIF SDRAM Controller Driver:
+
+Author
+========
+Aneesh V <aneesh@ti.com>
+
+Location
+============
+driver/memory/emif.c
+
+Supported SoCs:
+===================
+TI OMAP44xx
+TI OMAP54xx
+
+Menuconfig option:
+==========================
+Device Drivers
+        Memory devices
+                Texas Instruments EMIF driver
+
+Description
+===========
+This driver is for the EMIF module available in Texas Instruments
+SoCs. EMIF is an SDRAM controller that, based on its revision,
+supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols.
+This driver takes care of only LPDDR2 memories presently. The
+functions of the driver includes re-configuring AC timing
+parameters and other settings during frequency, voltage and
+temperature changes
+
+Platform Data (see include/linux/platform_data/emif_plat.h):
+=====================================================================
+DDR device details and other board dependent and SoC dependent
+information can be passed through platform data (struct emif_platform_data)
+- DDR device details: 'struct ddr_device_info'
+- Device AC timings: 'struct lpddr2_timings' and 'struct lpddr2_min_tck'
+- Custom configurations: customizable policy options through
+  'struct emif_custom_configs'
+- IP revision
+- PHY type
+
+Interface to the external world:
+================================
+EMIF driver registers notifiers for voltage and frequency changes
+affecting EMIF and takes appropriate actions when these are invoked.
+- freq_pre_notify_handling()
+- freq_post_notify_handling()
+- volt_notify_handling()
+
+Debugfs
+========
+The driver creates two debugfs entries per device.
+- regcache_dump : dump of register values calculated and saved for all
+  frequencies used so far.
+- mr4 : last polled value of MR4 register in the LPDDR2 device. MR4
+  indicates the current temperature level of the device.
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 8f485d72cf25..6d0c2519cf47 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -341,7 +341,7 @@ Need more implementation yet....
 --------------------------------
 8. Memory hotplug event notifier
 --------------------------------
-Memory hotplug has event notifer. There are 6 types of notification.
+Memory hotplug has event notifier. There are 6 types of notification.
 
 MEMORY_GOING_ONLINE
   Generated before new memory becomes available in order to be able to
diff --git a/Documentation/misc-devices/mei/.gitignore b/Documentation/misc-devices/mei/.gitignore
new file mode 100644
index 000000000000..f356b81ca1ec
--- /dev/null
+++ b/Documentation/misc-devices/mei/.gitignore
@@ -0,0 +1 @@
+mei-amt-version
diff --git a/Documentation/misc-devices/mei/Makefile b/Documentation/misc-devices/mei/Makefile
new file mode 100644
index 000000000000..00e8c3e836ff
--- /dev/null
+++ b/Documentation/misc-devices/mei/Makefile
@@ -0,0 +1,8 @@
+# kbuild trick to avoid linker error. Can be omitted if a module is built.
+obj- := dummy.o
+
+# List of programs to build
+hostprogs-y := mei-amt-version
+HOSTCFLAGS_mei-amt-version.o += -I$(objtree)/usr/include
+# Tell kbuild to always build the programs
+always := $(hostprogs-y)
diff --git a/Documentation/misc-devices/mei/TODO b/Documentation/misc-devices/mei/TODO
new file mode 100644
index 000000000000..6b3625d3058c
--- /dev/null
+++ b/Documentation/misc-devices/mei/TODO
@@ -0,0 +1,2 @@
+TODO:
+        - Cleanup and split the timer function
diff --git a/Documentation/misc-devices/mei/mei-amt-version.c b/Documentation/misc-devices/mei/mei-amt-version.c
new file mode 100644
index 000000000000..01804f216312
--- /dev/null
+++ b/Documentation/misc-devices/mei/mei-amt-version.c
@@ -0,0 +1,481 @@
+/******************************************************************************
+ * Intel Management Engine Interface (Intel MEI) Linux driver
+ * Intel MEI Interface Header
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2012 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * 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 Street, Fifth Floor, Boston, MA 02110,
+ * USA
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.GPL.
+ *
+ * Contact Information:
+ *      Intel Corporation.
+ *      linux-mei@linux.intel.com
+ *      http://www.intel.com
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2003 - 2012 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *  * Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ *  * 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.
+ *  * Neither the name Intel Corporation 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 THE COPYRIGHT
+ * OWNER 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.
+ *
+ *****************************************************************************/
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <fcntl.h>
+#include <sys/ioctl.h>
+#include <unistd.h>
+#include <errno.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <bits/wordsize.h>
+#include <linux/mei.h>
+
+/*****************************************************************************
+ * Intel Management Engine Interface
+ *****************************************************************************/
+
+#define mei_msg(_me, fmt, ARGS...) do {         \
+        if (_me->verbose)                       \
+                fprintf(stderr, fmt, ##ARGS);   \
+} while (0)
+
+#define mei_err(_me, fmt, ARGS...) do {         \
+        fprintf(stderr, "Error: " fmt, ##ARGS); \
+} while (0)
+
+struct mei {
+        uuid_le guid;
+        bool initialized;
+        bool verbose;
+        unsigned int buf_size;
+        unsigned char prot_ver;
+        int fd;
+};
+
+static void mei_deinit(struct mei *cl)
+{
+        if (cl->fd != -1)
+                close(cl->fd);
+        cl->fd = -1;
+        cl->buf_size = 0;
+        cl->prot_ver = 0;
+        cl->initialized = false;
+}
+
+static bool mei_init(struct mei *me, const uuid_le *guid,
+                unsigned char req_protocol_version, bool verbose)
+{
+        int result;
+        struct mei_client *cl;
+        struct mei_connect_client_data data;
+
+        mei_deinit(me);
+
+        me->verbose = verbose;
+
+        me->fd = open("/dev/mei", O_RDWR);
+        if (me->fd == -1) {
+                mei_err(me, "Cannot establish a handle to the Intel MEI driver\n");
+                goto err;
+        }
+        memcpy(&me->guid, guid, sizeof(*guid));
+        memset(&data, 0, sizeof(data));
+        me->initialized = true;
+
+        memcpy(&data.in_client_uuid, &me->guid, sizeof(me->guid));
+        result = ioctl(me->fd, IOCTL_MEI_CONNECT_CLIENT, &data);
+        if (result) {
+                mei_err(me, "IOCTL_MEI_CONNECT_CLIENT receive message. err=%d\n", result);
+                goto err;
+        }
+        cl = &data.out_client_properties;
+        mei_msg(me, "max_message_length %d\n", cl->max_msg_length);
+        mei_msg(me, "protocol_version %d\n", cl->protocol_version);
+
+        if ((req_protocol_version > 0) &&
+             (cl->protocol_version != req_protocol_version)) {
+                mei_err(me, "Intel MEI protocol version not supported\n");
+                goto err;
+        }
+
+        me->buf_size = cl->max_msg_length;
+        me->prot_ver = cl->protocol_version;
+
+        return true;
+err:
+        mei_deinit(me);
+        return false;
+}
+
+static ssize_t mei_recv_msg(struct mei *me, unsigned char *buffer,
+                        ssize_t len, unsigned long timeout)
+{
+        ssize_t rc;
+
+        mei_msg(me, "call read length = %zd\n", len);
+
+        rc = read(me->fd, buffer, len);
+        if (rc < 0) {
+                mei_err(me, "read failed with status %zd %s\n",
+                                rc, strerror(errno));
+                mei_deinit(me);
+        } else {
+                mei_msg(me, "read succeeded with result %zd\n", rc);
+        }
+        return rc;
+}
+
+static ssize_t mei_send_msg(struct mei *me, const unsigned char *buffer,
+                        ssize_t len, unsigned long timeout)
+{
+        struct timeval tv;
+        ssize_t written;
+        ssize_t rc;
+        fd_set set;
+
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = (timeout % 1000) * 1000000;
+
+        mei_msg(me, "call write length = %zd\n", len);
+
+        written = write(me->fd, buffer, len);
+        if (written < 0) {
+                rc = -errno;
+                mei_err(me, "write failed with status %zd %s\n",
+                        written, strerror(errno));
+                goto out;
+        }
+
+        FD_ZERO(&set);
+        FD_SET(me->fd, &set);
+        rc = select(me->fd + 1 , &set, NULL, NULL, &tv);
+        if (rc > 0 && FD_ISSET(me->fd, &set)) {
+                mei_msg(me, "write success\n");
+        } else if (rc == 0) {
+                mei_err(me, "write failed on timeout with status\n");
+                goto out;
+        } else { /* rc < 0 */
+                mei_err(me, "write failed on select with status %zd\n", rc);
+                goto out;
+        }
+
+        rc = written;
+out:
+        if (rc < 0)
+                mei_deinit(me);
+
+        return rc;
+}
+
+/***************************************************************************
+ * Intel Advanced Management Technolgy ME Client
+ ***************************************************************************/
+
+#define AMT_MAJOR_VERSION 1
+#define AMT_MINOR_VERSION 1
+
+#define AMT_STATUS_SUCCESS                0x0
+#define AMT_STATUS_INTERNAL_ERROR         0x1
+#define AMT_STATUS_NOT_READY              0x2
+#define AMT_STATUS_INVALID_AMT_MODE       0x3
+#define AMT_STATUS_INVALID_MESSAGE_LENGTH 0x4
+
+#define AMT_STATUS_HOST_IF_EMPTY_RESPONSE  0x4000
+#define AMT_STATUS_SDK_RESOURCES      0x1004
+
+
+#define AMT_BIOS_VERSION_LEN   65
+#define AMT_VERSIONS_NUMBER    50
+#define AMT_UNICODE_STRING_LEN 20
+
+struct amt_unicode_string {
+        uint16_t length;
+        char string[AMT_UNICODE_STRING_LEN];
+} __attribute__((packed));
+
+struct amt_version_type {
+        struct amt_unicode_string description;
+        struct amt_unicode_string version;
+} __attribute__((packed));
+
+struct amt_version {
+        uint8_t major;
+        uint8_t minor;
+} __attribute__((packed));
+
+struct amt_code_versions {
+        uint8_t bios[AMT_BIOS_VERSION_LEN];
+        uint32_t count;
+        struct amt_version_type versions[AMT_VERSIONS_NUMBER];
+} __attribute__((packed));
+
+/***************************************************************************
+ * Intel Advanced Management Technolgy Host Interface
+ ***************************************************************************/
+
+struct amt_host_if_msg_header {
+        struct amt_version version;
+        uint16_t _reserved;
+        uint32_t command;
+        uint32_t length;
+} __attribute__((packed));
+
+struct amt_host_if_resp_header {
+        struct amt_host_if_msg_header header;
+        uint32_t status;
+        unsigned char data[0];
+} __attribute__((packed));
+
+const uuid_le MEI_IAMTHIF = UUID_LE(0x12f80028, 0xb4b7, 0x4b2d,  \
+                                0xac, 0xa8, 0x46, 0xe0, 0xff, 0x65, 0x81, 0x4c);
+
+#define AMT_HOST_IF_CODE_VERSIONS_REQUEST  0x0400001A
+#define AMT_HOST_IF_CODE_VERSIONS_RESPONSE 0x0480001A
+
+const struct amt_host_if_msg_header CODE_VERSION_REQ = {
+        .version = {AMT_MAJOR_VERSION, AMT_MINOR_VERSION},
+        ._reserved = 0,
+        .command = AMT_HOST_IF_CODE_VERSIONS_REQUEST,
+        .length = 0
+};
+
+
+struct amt_host_if {
+        struct mei mei_cl;
+        unsigned long send_timeout;
+        bool initialized;
+};
+
+
+static bool amt_host_if_init(struct amt_host_if *acmd,
+                      unsigned long send_timeout, bool verbose)
+{
+        acmd->send_timeout = (send_timeout) ? send_timeout : 20000;
+        acmd->initialized = mei_init(&acmd->mei_cl, &MEI_IAMTHIF, 0, verbose);
+        return acmd->initialized;
+}
+
+static void amt_host_if_deinit(struct amt_host_if *acmd)
+{
+        mei_deinit(&acmd->mei_cl);
+        acmd->initialized = false;
+}
+
+static uint32_t amt_verify_code_versions(const struct amt_host_if_resp_header *resp)
+{
+        uint32_t status = AMT_STATUS_SUCCESS;
+        struct amt_code_versions *code_ver;
+        size_t code_ver_len;
+        uint32_t ver_type_cnt;
+        uint32_t len;
+        uint32_t i;
+
+        code_ver = (struct amt_code_versions *)resp->data;
+        /* length - sizeof(status) */
+        code_ver_len = resp->header.length - sizeof(uint32_t);
+        ver_type_cnt = code_ver_len -
+                        sizeof(code_ver->bios) -
+                        sizeof(code_ver->count);
+        if (code_ver->count != ver_type_cnt / sizeof(struct amt_version_type)) {
+                status = AMT_STATUS_INTERNAL_ERROR;
+                goto out;
+        }
+
+        for (i = 0; i < code_ver->count; i++) {
+                len = code_ver->versions[i].description.length;
+
+                if (len > AMT_UNICODE_STRING_LEN) {
+                        status = AMT_STATUS_INTERNAL_ERROR;
+                        goto out;
+                }
+
+                len = code_ver->versions[i].version.length;
+                if (code_ver->versions[i].version.string[len] != '\0' ||
+                    len != strlen(code_ver->versions[i].version.string)) {
+                        status = AMT_STATUS_INTERNAL_ERROR;
+                        goto out;
+                }
+        }
+out:
+        return status;
+}
+
+static uint32_t amt_verify_response_header(uint32_t command,
+                                const struct amt_host_if_msg_header *resp_hdr,
+                                uint32_t response_size)
+{
+        if (response_size < sizeof(struct amt_host_if_resp_header)) {
+                return AMT_STATUS_INTERNAL_ERROR;
+        } else if (response_size != (resp_hdr->length +
+                                sizeof(struct amt_host_if_msg_header))) {
+                return AMT_STATUS_INTERNAL_ERROR;
+        } else if (resp_hdr->command != command) {
+                return AMT_STATUS_INTERNAL_ERROR;
+        } else if (resp_hdr->_reserved != 0) {
+                return AMT_STATUS_INTERNAL_ERROR;
+        } else if (resp_hdr->version.major != AMT_MAJOR_VERSION ||
+                   resp_hdr->version.minor < AMT_MINOR_VERSION) {
+                return AMT_STATUS_INTERNAL_ERROR;
+        }
+        return AMT_STATUS_SUCCESS;
+}
+
+static uint32_t amt_host_if_call(struct amt_host_if *acmd,
+                        const unsigned char *command, ssize_t command_sz,
+                        uint8_t **read_buf, uint32_t rcmd,
+                        unsigned int expected_sz)
+{
+        uint32_t in_buf_sz;
+        uint32_t out_buf_sz;
+        ssize_t written;
+        uint32_t status;
+        struct amt_host_if_resp_header *msg_hdr;
+
+        in_buf_sz = acmd->mei_cl.buf_size;
+        *read_buf = (uint8_t *)malloc(sizeof(uint8_t) * in_buf_sz);
+        if (*read_buf == NULL)
+                return AMT_STATUS_SDK_RESOURCES;
+        memset(*read_buf, 0, in_buf_sz);
+        msg_hdr = (struct amt_host_if_resp_header *)*read_buf;
+
+        written = mei_send_msg(&acmd->mei_cl,
+                                command, command_sz, acmd->send_timeout);
+        if (written != command_sz)
+                return AMT_STATUS_INTERNAL_ERROR;
+
+        out_buf_sz = mei_recv_msg(&acmd->mei_cl, *read_buf, in_buf_sz, 2000);
+        if (out_buf_sz <= 0)
+                return AMT_STATUS_HOST_IF_EMPTY_RESPONSE;
+
+        status = msg_hdr->status;
+        if (status != AMT_STATUS_SUCCESS)
+                return status;
+
+        status = amt_verify_response_header(rcmd,
+                                &msg_hdr->header, out_buf_sz);
+        if (status != AMT_STATUS_SUCCESS)
+                return status;
+
+        if (expected_sz && expected_sz != out_buf_sz)
+                return AMT_STATUS_INTERNAL_ERROR;
+
+        return AMT_STATUS_SUCCESS;
+}
+
+
+static uint32_t amt_get_code_versions(struct amt_host_if *cmd,
+                               struct amt_code_versions *versions)
+{
+        struct amt_host_if_resp_header *response = NULL;
+        uint32_t status;
+
+        status = amt_host_if_call(cmd,
+                        (const unsigned char *)&CODE_VERSION_REQ,
+                        sizeof(CODE_VERSION_REQ),
+                        (uint8_t **)&response,
+                        AMT_HOST_IF_CODE_VERSIONS_RESPONSE, 0);
+
+        if (status != AMT_STATUS_SUCCESS)
+                goto out;
+
+        status = amt_verify_code_versions(response);
+        if (status != AMT_STATUS_SUCCESS)
+                goto out;
+
+        memcpy(versions, response->data, sizeof(struct amt_code_versions));
+out:
+        if (response != NULL)
+                free(response);
+
+        return status;
+}
+
+/************************** end of amt_host_if_command ***********************/
+int main(int argc, char **argv)
+{
+        struct amt_code_versions ver;
+        struct amt_host_if acmd;
+        unsigned int i;
+        uint32_t status;
+        int ret;
+        bool verbose;
+
+        verbose = (argc > 1 && strcmp(argv[1], "-v") == 0);
+
+        if (!amt_host_if_init(&acmd, 5000, verbose)) {
+                ret = 1;
+                goto out;
+        }
+
+        status = amt_get_code_versions(&acmd, &ver);
+
+        amt_host_if_deinit(&acmd);
+
+        switch (status) {
+        case AMT_STATUS_HOST_IF_EMPTY_RESPONSE:
+                printf("Intel AMT: DISABLED\n");
+                ret = 0;
+                break;
+        case AMT_STATUS_SUCCESS:
+                printf("Intel AMT: ENABLED\n");
+                for (i = 0; i < ver.count; i++) {
+                        printf("%s:\t%s\n", ver.versions[i].description.string,
+                                ver.versions[i].version.string);
+                }
+                ret = 0;
+                break;
+        default:
+                printf("An error has occurred\n");
+                ret = 1;
+                break;
+        }
+
+out:
+        return ret;
+}
diff --git a/Documentation/misc-devices/mei/mei.txt b/Documentation/misc-devices/mei/mei.txt
new file mode 100644
index 000000000000..2785697da59d
--- /dev/null
+++ b/Documentation/misc-devices/mei/mei.txt
@@ -0,0 +1,215 @@
+Intel(R) Management Engine Interface (Intel(R) MEI)
+=======================
+
+Introduction
+=======================
+
+The Intel Management Engine (Intel ME) is an isolated and protected computing
+resource (Co-processor) residing inside certain Intel chipsets. The Intel ME
+provides support for computer/IT management features. The feature set
+depends on the Intel chipset SKU.
+
+The Intel Management Engine Interface (Intel MEI, previously known as HECI)
+is the interface between the Host and Intel ME. This interface is exposed
+to the host as a PCI device. The Intel MEI Driver is in charge of the
+communication channel between a host application and the Intel ME feature.
+
+Each Intel ME feature (Intel ME Client) is addressed by a GUID/UUID and
+each client has its own protocol. The protocol is message-based with a
+header and payload up to 512 bytes.
+
+Prominent usage of the Intel ME Interface is to communicate with Intel(R)
+Active Management Technology (Intel AMT)implemented in firmware running on
+the Intel ME.
+
+Intel AMT provides the ability to manage a host remotely out-of-band (OOB)
+even when the operating system running on the host processor has crashed or
+is in a sleep state.
+
+Some examples of Intel AMT usage are:
+   - Monitoring hardware state and platform components
+   - Remote power off/on (useful for green computing or overnight IT
+     maintenance)
+   - OS updates
+   - Storage of useful platform information such as software assets
+   - Built-in hardware KVM
+   - Selective network isolation of Ethernet and IP protocol flows based
+     on policies set by a remote management console
+   - IDE device redirection from remote management console
+
+Intel AMT (OOB) communication is based on SOAP (deprecated
+starting with Release 6.0) over HTTP/S or WS-Management protocol over
+HTTP/S that are received from a remote management console application.
+
+For more information about Intel AMT:
+http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
+
+Intel MEI Driver
+=======================
+
+The driver exposes a misc device called /dev/mei.
+
+An application maintains communication with an Intel ME feature while
+/dev/mei is open. The binding to a specific features is performed by calling
+MEI_CONNECT_CLIENT_IOCTL, which passes the desired UUID.
+The number of instances of an Intel ME feature that can be opened
+at the same time depends on the Intel ME feature, but most of the
+features allow only a single instance.
+
+The Intel AMT Host Interface (Intel AMTHI) feature supports multiple
+simultaneous user applications. Therefore, the Intel MEI driver handles
+this internally by maintaining request queues for the applications.
+
+The driver is oblivious to data that is passed between firmware feature
+and host application.
+
+Because some of the Intel ME features can change the system
+configuration, the driver by default allows only a privileged
+user to access it.
+
+A code snippet for an application communicating with
+Intel AMTHI client:
+        struct mei_connect_client_data data;
+        fd = open(MEI_DEVICE);
+
+        data.d.in_client_uuid = AMTHI_UUID;
+
+        ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &data);
+
+        printf("Ver=%d, MaxLen=%ld\n",
+                        data.d.in_client_uuid.protocol_version,
+                        data.d.in_client_uuid.max_msg_length);
+
+        [...]
+
+        write(fd, amthi_req_data, amthi_req_data_len);
+
+        [...]
+
+        read(fd, &amthi_res_data, amthi_res_data_len);
+
+        [...]
+        close(fd);
+
+IOCTL:
+======
+The Intel MEI Driver supports the following IOCTL command:
+        IOCTL_MEI_CONNECT_CLIENT        Connect to firmware Feature (client).
+
+        usage:
+                struct mei_connect_client_data clientData;
+                ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &clientData);
+
+        inputs:
+                mei_connect_client_data struct contain the following
+                input field:
+
+                in_client_uuid -        UUID of the FW Feature that needs
+                                        to connect to.
+        outputs:
+                out_client_properties - Client Properties: MTU and Protocol Version.
+
+        error returns:
+                EINVAL  Wrong IOCTL Number
+                ENODEV  Device or Connection is not initialized or ready.
+                        (e.g. Wrong UUID)
+                ENOMEM  Unable to allocate memory to client internal data.
+                EFAULT  Fatal Error (e.g. Unable to access user input data)
+                EBUSY   Connection Already Open
+
+        Notes:
+        max_msg_length (MTU) in client properties describes the maximum
+        data that can be sent or received. (e.g. if MTU=2K, can send
+        requests up to bytes 2k and received responses upto 2k bytes).
+
+Intel ME Applications:
+==============
+
+1) Intel Local Management Service (Intel LMS)
+
+        Applications running locally on the platform communicate with Intel AMT Release
+        2.0 and later releases in the same way that network applications do via SOAP
+        over HTTP (deprecated starting with Release 6.0) or with WS-Management over
+        SOAP over HTTP. This means that some Intel AMT features can be accessed from a
+        local application using the same network interface as a remote application
+        communicating with Intel AMT over the network.
+
+        When a local application sends a message addressed to the local Intel AMT host
+        name, the Intel LMS, which listens for traffic directed to the host name,
+        intercepts the message and routes it to the Intel MEI.
+        For more information:
+        http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
+        Under "About Intel AMT" => "Local Access"
+
+        For downloading Intel LMS:
+        http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
+
+        The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS
+        firmware feature using a defined UUID and then communicates with the feature
+        using a protocol called Intel AMT Port Forwarding Protocol(Intel APF protocol).
+        The protocol is used to maintain multiple sessions with Intel AMT from a
+        single application.
+
+        See the protocol specification in the Intel AMT Software Development Kit(SDK)
+        http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
+        Under "SDK Resources" => "Intel(R) vPro(TM) Gateway(MPS)"
+        => "Information for Intel(R) vPro(TM) Gateway Developers"
+        => "Description of the Intel AMT Port Forwarding (APF)Protocol"
+
+  2) Intel AMT Remote configuration using a Local Agent
+        A Local Agent enables IT personnel to configure Intel AMT out-of-the-box
+        without requiring installing additional data to enable setup. The remote
+        configuration process may involve an ISV-developed remote configuration
+        agent that runs on the host.
+        For more information:
+        http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
+        Under "Setup and Configuration of Intel AMT" =>
+        "SDK Tools Supporting Setup and Configuration" =>
+        "Using the Local Agent Sample"
+
+        An open source Intel AMT configuration utility, implementing a local agent
+        that accesses the Intel MEI driver, can be found here:
+        http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
+
+
+Intel AMT OS Health Watchdog:
+=============================
+The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog.
+Whenever the OS hangs or crashes, Intel AMT will send an event
+to any subscriber to this event. This mechanism means that
+IT knows when a platform crashes even when there is a hard failure on the host.
+
+The Intel AMT Watchdog is composed of two parts:
+        1) Firmware feature - receives the heartbeats
+           and sends an event when the heartbeats stop.
+        2) Intel MEI driver - connects to the watchdog feature, configures the
+           watchdog and sends the heartbeats.
+
+The Intel MEI driver uses the kernel watchdog to configure the Intel AMT
+Watchdog and to send heartbeats to it. The default timeout of the
+watchdog is 120 seconds.
+
+If the Intel AMT Watchdog feature does not exist (i.e. the connection failed),
+the Intel MEI driver will disable the sending of heartbeats.
+
+Supported Chipsets:
+==================
+7 Series Chipset Family
+6 Series Chipset Family
+5 Series Chipset Family
+4 Series Chipset Family
+Mobile 4 Series Chipset Family
+ICH9
+82946GZ/GL
+82G35 Express
+82Q963/Q965
+82P965/G965
+Mobile PM965/GM965
+Mobile GME965/GLE960
+82Q35 Express
+82G33/G31/P35/P31 Express
+82Q33 Express
+82X38/X48 Express
+
+---
+linux-mei@linux.intel.com
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 9ad9ddeb384c..2cc3c7733a2f 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -1,7 +1,5 @@
 00-INDEX
         - this file
-3c359.txt
-        - information on the 3Com TokenLink Velocity XL (3c5359) driver.
 3c505.txt
         - information on the 3Com EtherLink Plus (3c505) driver.
 3c509.txt
@@ -142,8 +140,6 @@ netif-msg.txt
         - Design of the network interface message level setting (NETIF_MSG_*).
 nfc.txt
         - The Linux Near Field Communication (NFS) subsystem.
-olympic.txt
-        - IBM PCI Pit/Pit-Phy/Olympic Token Ring driver info.
 openvswitch.txt
         - Open vSwitch developer documentation.
 operstates.txt
@@ -184,8 +180,6 @@ skfp.txt
         - SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info.
 smc9.txt
         - the driver for SMC's 9000 series of Ethernet cards
-smctr.txt
-        - SMC TokenCard TokenRing Linux driver info.
 spider-net.txt
         - README for the Spidernet Driver (as found in PS3 / Cell BE).
 stmmac.txt
@@ -200,8 +194,6 @@ tcp-thin.txt
         - kernel tuning options for low rate 'thin' TCP streams.
 tlan.txt
         - ThunderLAN (Compaq Netelligent 10/100, Olicom OC-2xxx) driver info.
-tms380tr.txt
-        - SysKonnect Token Ring ISA/PCI adapter driver info.
 tproxy.txt
         - Transparent proxy support user guide.
 tuntap.txt
diff --git a/Documentation/networking/3c359.txt b/Documentation/networking/3c359.txt
deleted file mode 100644
index dadfe8147ab8..000000000000
--- a/Documentation/networking/3c359.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-
-3COM PCI TOKEN LINK VELOCITY XL TOKEN RING CARDS README
-
-Release 0.9.0 - Release   
-        Jul 17th 2000 Mike Phillips 
-
-        1.2.0 - Final
-        Feb 17th 2002 Mike Phillips 
-        Updated for submission to the 2.4.x kernel.
-
-Thanks:
-        Terry Murphy from 3Com for tech docs and support,
-        Adam D. Ligas for testing the driver.
- 
-Note:
-        This driver will NOT work with the 3C339 Token Ring cards, you need
-to use the tms380 driver instead.
-
-Options:
-
-The driver accepts three options: ringspeed, pkt_buf_sz and message_level.
-
-These options can be specified differently for each card found. 
-
-ringspeed:  Has one of three settings 0 (default), 4 or 16.  0 will 
-make the card autosense the ringspeed and join at the appropriate speed, 
-this will be the default option for most people.  4 or 16 allow you to 
-explicitly force the card to operate at a certain speed.  The card will fail 
-if you try to insert it at the wrong speed. (Although some hubs will allow 
-this so be *very* careful).  The main purpose for explicitly setting the ring
-speed is for when the card is first on the ring.  In autosense mode, if the card
-cannot detect any active monitors on the ring it will open at the same speed as
-its last opening. This can be hazardous if this speed does not match the speed
-you want the ring to operate at.  
-
-pkt_buf_sz:  This is this initial receive buffer allocation size.  This will
-default to 4096 if no value is entered. You may increase performance of the 
-driver by setting this to a value larger than the network packet size, although
-the driver now re-sizes buffers based on MTU settings as well. 
-
-message_level: Controls level of messages created by the driver. Defaults to 0:
-which only displays start-up and critical messages.  Presently any non-zero 
-value will display all soft messages as well.  NB This does not turn 
-debugging messages on, that must be done by modified the source code.
-
-Variable MTU size:
-
-The driver can handle a MTU size up to either 4500 or 18000 depending upon 
-ring speed.  The driver also changes the size of the receive buffers as part
-of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
-to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring 
-position = 296,000 bytes of memory space, plus of course anything 
-necessary for the tx sk_buff's.  Remember this is per card, so if you are
-building routers, gateway's etc, you could start to use a lot of memory
-real fast.
-
-2/17/02 Mike Phillips
-
diff --git a/Documentation/networking/3c509.txt b/Documentation/networking/3c509.txt
index dcc9eaf59395..fbf722e15ac3 100644
--- a/Documentation/networking/3c509.txt
+++ b/Documentation/networking/3c509.txt
@@ -25,7 +25,6 @@ models:
   3c509B (later revision of the ISA card; supports full-duplex)
   3c589 (PCMCIA)
   3c589B (later revision of the 3c589; supports full-duplex)
-  3c529 (MCA)
   3c579 (EISA)
 
 Large portions of this documentation were heavily borrowed from the guide
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt
index 221ad0cdf11f..75a592365af9 100644
--- a/Documentation/networking/batman-adv.txt
+++ b/Documentation/networking/batman-adv.txt
@@ -1,5 +1,3 @@
-[state: 21-08-2011]
-
 BATMAN-ADV
 ----------
 
@@ -67,18 +65,19 @@ To deactivate an interface you have  to  write  "none"  into  its
 All  mesh  wide  settings  can be found in batman's own interface
 folder:
 
-#  ls  /sys/class/net/bat0/mesh/
-# aggregated_ogms   fragmentation gw_sel_class   vis_mode
-# ap_isolation      gw_bandwidth  hop_penalty
-# bonding           gw_mode       orig_interval
+# ls /sys/class/net/bat0/mesh/
+# aggregated_ogms        gw_bandwidth           log_level
+# ap_isolation           gw_mode                orig_interval
+# bonding                gw_sel_class           routing_algo
+# bridge_loop_avoidance  hop_penalty            vis_mode
+# fragmentation
 
 
 There is a special folder for debugging information:
 
 #  ls /sys/kernel/debug/batman_adv/bat0/
-#  gateways     socket        transtable_global  vis_data
-#  originators  softif_neigh  transtable_local
-
+# bla_claim_table    log                socket             transtable_local
+# gateways           originators        transtable_global  vis_data
 
 Some of the files contain all sort of status information  regard-
 ing  the  mesh  network.  For  example, you can view the table of
@@ -202,12 +201,13 @@ abled  during run time. Following log_levels are defined:
 1 - Enable messages related to routing / flooding / broadcasting
 2 - Enable messages related to route added / changed / deleted
 4 - Enable messages related to translation table operations
-7 - Enable all messages
+8 - Enable messages related to bridge loop avoidance
+15 - enable all messages
 
 The debug output can be changed at runtime  using  the  file
 /sys/class/net/bat0/mesh/log_level. e.g.
 
-# echo 2 > /sys/class/net/bat0/mesh/log_level
+# echo 6 > /sys/class/net/bat0/mesh/log_level
 
 will enable debug messages for when routes change.
 
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index 56ca3b75376e..ac295399f0d4 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -649,7 +649,7 @@ solution for a couple of reasons:
   The CAN device must be configured via netlink interface. The supported
   netlink message types are defined and briefly described in
   "include/linux/can/netlink.h". CAN link support for the program "ip"
-  of the IPROUTE2 utility suite is avaiable and it can be used as shown
+  of the IPROUTE2 utility suite is available and it can be used as shown
   below:
 
   - Setting CAN device properties:
diff --git a/Documentation/networking/fore200e.txt b/Documentation/networking/fore200e.txt
index f648eb265188..d52af53efdc5 100644
--- a/Documentation/networking/fore200e.txt
+++ b/Documentation/networking/fore200e.txt
@@ -11,12 +11,10 @@ i386, alpha (untested), powerpc, sparc and sparc64 archs.
 
 The intent is to enable the use of different models of FORE adapters at the
 same time, by hosts that have several bus interfaces (such as PCI+SBUS,
-PCI+MCA or PCI+EISA).
+or PCI+EISA).
 
 Only PCI and SBUS devices are currently supported by the driver, but support
-for other bus interfaces such as EISA should not be too hard to add (this may
-be more tricky for the MCA bus, though, as FORE made some MCA-specific
-modifications to the adapter's AALI interface).
+for other bus interfaces such as EISA should not be too hard to add.
 
 
 Firmware Copyright Notice
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 1dc1c24a7547..703cf4370c79 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -4,15 +4,22 @@
 
 Introduction
 ============
+The IEEE 802.15.4 working group focuses on standartization of bottom
+two layers: Medium Accsess Control (MAC) and Physical (PHY). And there
+are mainly two options available for upper layers:
+ - ZigBee - proprietary protocol from ZigBee Alliance
+ - 6LowPAN - IPv6 networking over low rate personal area networks
 
 The Linux-ZigBee project goal is to provide complete implementation
-of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack
+of IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack
 of protocols for organizing Low-Rate Wireless Personal Area Networks.
 
-Currently only IEEE 802.15.4 layer is implemented. We have chosen
-to use plain Berkeley socket API, the generic Linux networking stack
-to transfer IEEE 802.15.4 messages and a special protocol over genetlink
-for configuration/management
+The stack is composed of three main parts:
+ - IEEE 802.15.4 layer;  We have chosen to use plain Berkeley socket API,
+   the generic Linux networking stack to transfer IEEE 802.15.4 messages
+   and a special protocol over genetlink for configuration/management
+ - MAC - provides access to shared channel and reliable data delivery
+ - PHY - represents device drivers
 
 
 Socket API
@@ -29,15 +36,6 @@ or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee).
 One can use SOCK_RAW for passing raw data towards device xmit function. YMMV.
 
 
-MLME - MAC Level Management
-============================
-
-Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands.
-See the include/net/nl802154.h header. Our userspace tools package
-(see above) provides CLI configuration utility for radio interfaces and simple
-coordinator for IEEE 802.15.4 networks as an example users of MLME protocol.
-
-
 Kernel side
 =============
 
@@ -51,6 +49,15 @@ Like with WiFi, there are several types of devices implementing IEEE 802.15.4.
 Those types of devices require different approach to be hooked into Linux kernel.
 
 
+MLME - MAC Level Management
+============================
+
+Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands.
+See the include/net/nl802154.h header. Our userspace tools package
+(see above) provides CLI configuration utility for radio interfaces and simple
+coordinator for IEEE 802.15.4 networks as an example users of MLME protocol.
+
+
 HardMAC
 =======
 
@@ -73,11 +80,47 @@ We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c
 SoftMAC
 =======
 
-We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
-in software. This is currently WIP.
+The MAC is the middle layer in the IEEE 802.15.4 Linux stack. This moment it
+provides interface for drivers registration and management of slave interfaces.
+
+NOTE: Currently the only monitor device type is supported - it's IEEE 802.15.4
+stack interface for network sniffers (e.g. WireShark).
+
+This layer is going to be extended soon.
 
 See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
 
+
+Device drivers API
+==================
+
+The include/net/mac802154.h defines following functions:
+ - struct ieee802154_dev *ieee802154_alloc_device
+   (size_t priv_size, struct ieee802154_ops *ops):
+   allocation of IEEE 802.15.4 compatible device
+
+ - void ieee802154_free_device(struct ieee802154_dev *dev):
+   freeing allocated device
+
+ - int ieee802154_register_device(struct ieee802154_dev *dev):
+   register PHY in the system
+
+ - void ieee802154_unregister_device(struct ieee802154_dev *dev):
+   freeing registered PHY
+
+Moreover IEEE 802.15.4 device operations structure should be filled.
+
+Fake drivers
+============
+
+In addition there are two drivers available which simulate real devices with
+HardMAC (fakehard) and SoftMAC (fakelb - IEEE 802.15.4 loopback driver)
+interfaces. This option provides possibility to test and debug stack without
+usage of real hardware.
+
+See sources in drivers/ieee802154 folder for more details.
+
+
 6LoWPAN Linux implementation
 ============================
 
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 1619a8c80873..6f896b94abdc 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -190,6 +190,20 @@ tcp_cookie_size - INTEGER
 tcp_dsack - BOOLEAN
         Allows TCP to send "duplicate" SACKs.
 
+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).
+        Possible values:
+                0 disables ER
+                1 enables ER
+                2 enables ER but delays fast recovery and fast retransmit
+                  by a fourth of RTT. This mitigates connection falsely
+                  recovers when network has a small degree of reordering
+                  (less than 3 packets).
+        Default: 2
+
 tcp_ecn - INTEGER
         Enable Explicit Congestion Notification (ECN) in TCP. ECN is only
         used when both ends of the TCP flow support it. It is useful to
@@ -1287,13 +1301,22 @@ bridge-nf-call-ip6tables - BOOLEAN
 bridge-nf-filter-vlan-tagged - BOOLEAN
         1 : pass bridged vlan-tagged ARP/IP/IPv6 traffic to {arp,ip,ip6}tables.
         0 : disable this.
-        Default: 1
+        Default: 0
 
 bridge-nf-filter-pppoe-tagged - BOOLEAN
         1 : pass bridged pppoe-tagged IP/IPv6 traffic to {ip,ip6}tables.
         0 : disable this.
-        Default: 1
+        Default: 0
 
+bridge-nf-pass-vlan-input-dev - BOOLEAN
+        1: if bridge-nf-filter-vlan-tagged is enabled, try to find a vlan
+        interface on the bridge and set the netfilter input device to the vlan.
+        This allows use of e.g. "iptables -i br0.1" and makes the REDIRECT
+        target work with vlan-on-top-of-bridge interfaces.  When no matching
+        vlan interface is found, or this switch is off, the input device is
+        set to the bridge interface.
+        0: disable bridge netfilter vlan interface lookup.
+        Default: 0
 
 proc/sys/net/sctp/* Variables:
 
@@ -1484,11 +1507,8 @@ addr_scope_policy - INTEGER
 
 
 /proc/sys/net/core/*
-dev_weight - INTEGER
-        The maximum number of packets that kernel can handle on a NAPI
-        interrupt, it's a Per-CPU variable.
+        Please see: Documentation/sysctl/net.txt for descriptions of these entries.
 
-        Default: 64
 
 /proc/sys/net/unix/*
 max_dgram_qlen - INTEGER
diff --git a/Documentation/networking/mac80211-auth-assoc-deauth.txt b/Documentation/networking/mac80211-auth-assoc-deauth.txt
index e0a2aa585ca3..d7a15fe91bf7 100644
--- a/Documentation/networking/mac80211-auth-assoc-deauth.txt
+++ b/Documentation/networking/mac80211-auth-assoc-deauth.txt
@@ -23,7 +23,7 @@ BA session stop & deauth/disassoc frames
 end note
 end
 
-mac80211->driver: config(channel, non-HT)
+mac80211->driver: config(channel, channel type)
 mac80211->driver: bss_info_changed(set BSSID, basic rate bitmap)
 mac80211->driver: sta_state(AP, exists)
 
@@ -51,7 +51,7 @@ note over mac80211,driver: cleanup like for authenticate
 end
 
 alt not previously authenticated (FT)
-mac80211->driver: config(channel, non-HT)
+mac80211->driver: config(channel, channel type)
 mac80211->driver: bss_info_changed(set BSSID, basic rate bitmap)
 mac80211->driver: sta_state(AP, exists)
 mac80211->driver: sta_state(AP, authenticated)
@@ -67,10 +67,6 @@ end
 
 mac80211->driver: set up QoS parameters
 
-alt is HT channel
-mac80211->driver: config(channel, HT params)
-end
-
 mac80211->driver: bss_info_changed(QoS, HT, associated with AID)
 mac80211->userspace: associated
 
@@ -95,5 +91,5 @@ mac80211->driver: sta_state(AP,exists)
 mac80211->driver: sta_state(AP,not-exists)
 mac80211->driver: turn off powersave
 mac80211->driver: bss_info_changed(clear BSSID, not associated, no QoS, ...)
-mac80211->driver: config(non-HT channel type)
+mac80211->driver: config(channel type to non-HT)
 mac80211->userspace: disconnected
diff --git a/Documentation/networking/olympic.txt b/Documentation/networking/olympic.txt
deleted file mode 100644
index b95b5bf96751..000000000000
--- a/Documentation/networking/olympic.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-
-IBM PCI Pit/Pit-Phy/Olympic CHIPSET BASED TOKEN RING CARDS README
-
-Release 0.2.0 - Release    
-        June 8th 1999 Peter De Schrijver & Mike Phillips
-Release 0.9.C - Release
-        April 18th 2001 Mike Phillips
-
-Thanks:
-Erik De Cock, Adrian Bridgett and Frank Fiene for their 
-patience and testing.
-Donald Champion for the cardbus support
-Kyle Lucke for the dma api changes.   
-Jonathon Bitner for hardware support. 
-Everybody on linux-tr for their continued support.  
- 
-Options:
-
-The driver accepts four options: ringspeed, pkt_buf_sz,  
-message_level and network_monitor.
-
-These options can be specified differently for each card found. 
-
-ringspeed:  Has one of three settings 0 (default), 4 or 16.  0 will 
-make the card autosense the ringspeed and join at the appropriate speed, 
-this will be the default option for most people.  4 or 16 allow you to 
-explicitly force the card to operate at a certain speed.  The card will fail 
-if you try to insert it at the wrong speed. (Although some hubs will allow 
-this so be *very* careful).  The main purpose for explicitly setting the ring
-speed is for when the card is first on the ring.  In autosense mode, if the card
-cannot detect any active monitors on the ring it will not open, so you must 
-re-init the card at the appropriate speed.  Unfortunately at present the only
-way of doing this is rmmod and insmod which is a bit tough if it is compiled
-in the kernel.
-
-pkt_buf_sz:  This is this initial receive buffer allocation size.  This will
-default to 4096 if no value is entered. You may increase performance of the 
-driver by setting this to a value larger than the network packet size, although
-the driver now re-sizes buffers based on MTU settings as well. 
-
-message_level: Controls level of messages created by the driver. Defaults to 0:
-which only displays start-up and critical messages.  Presently any non-zero 
-value will display all soft messages as well.  NB This does not turn 
-debugging messages on, that must be done by modified the source code.
-
-network_monitor: Any non-zero value will provide a quasi network monitoring 
-mode.  All unexpected MAC frames (beaconing etc.) will be received
-by the driver and the source and destination addresses printed. 
-Also an entry will be added in  /proc/net called olympic_tr%d, where tr%d
-is the registered device name, i.e tr0, tr1, etc. This displays low
-level information about the configuration of the ring and the adapter.
-This feature has been designed for network administrators to assist in 
-the diagnosis of network / ring problems. (This used to OLYMPIC_NETWORK_MONITOR,
-but has now changed to allow each adapter to be configured differently and
-to alleviate the necessity to re-compile olympic to turn the option on).
-
-Multi-card:
-
-The driver will detect multiple cards and will work with shared interrupts,
-each card is assigned the next token ring device, i.e. tr0 , tr1, tr2.  The 
-driver should also happily reside in the system with other drivers.  It has 
-been tested with ibmtr.c running, and I personally have had one Olicom PCI 
-card and two IBM olympic cards (all on the same interrupt), all running
-together. 
-
-Variable MTU size:
-
-The driver can handle a MTU size up to either 4500 or 18000 depending upon 
-ring speed.  The driver also changes the size of the receive buffers as part
-of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
-to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring 
-position = 296,000 bytes of memory space, plus of course anything 
-necessary for the tx sk_buff's.  Remember this is per card, so if you are
-building routers, gateway's etc, you could start to use a lot of memory
-real fast.
-
-
-6/8/99 Peter De Schrijver and Mike Phillips
-
diff --git a/Documentation/networking/smctr.txt b/Documentation/networking/smctr.txt
deleted file mode 100644
index 9af25b810c1f..000000000000
--- a/Documentation/networking/smctr.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Text File for the SMC TokenCard TokenRing Linux driver (smctr.c).
-        By Jay Schulist <jschlst@samba.org>
-
-The Linux SMC Token Ring driver works with the SMC TokenCard Elite (8115T) 
-ISA and SMC TokenCard Elite/A (8115T/A) MCA adapters.
-
-Latest information on this driver can be obtained on the Linux-SNA WWW site.
-Please point your browser to: http://www.linux-sna.org
-
-This driver is rather simple to use. Select Y to Token Ring adapter support
-in the kernel configuration. A choice for SMC Token Ring adapters will
-appear. This drives supports all SMC ISA/MCA adapters. Choose this
-option. I personally recommend compiling the driver as a module (M), but if you
-you would like to compile it statically answer Y instead.
-
-This driver supports multiple adapters without the need to load multiple copies
-of the driver. You should be able to load up to 7 adapters without any kernel
-modifications, if you are in need of more please contact the maintainer of this
-driver.
-
-Load the driver either by lilo/loadlin or as a module. When a module using the
-following command will suffice for most:
-
-# modprobe smctr
-smctr.c: v1.00 12/6/99 by jschlst@samba.org
-tr0: SMC TokenCard 8115T at Io 0x300, Irq 10, Rom 0xd8000, Ram 0xcc000.
-
-Now just setup the device via ifconfig and set and routes you may have. After
-this you are ready to start sending some tokens.
-
-Errata:
-1). For anyone wondering where to pick up the SMC adapters please browse
-    to http://www.smc.com
-
-2). If you are the first/only Token Ring Client on a Token Ring LAN, please
-    specify the ringspeed with the ringspeed=[4/16] module option. If no
-    ringspeed is specified the driver will attempt to autodetect the ring
-    speed and/or if the adapter is the first/only station on the ring take
-    the appropriate actions. 
-
-    NOTE: Default ring speed is 16MB UTP.
-
-3). PnP support for this adapter sucks. I recommend hard setting the 
-    IO/MEM/IRQ by the jumpers on the adapter. If this is not possible
-    load the module with the following io=[ioaddr] mem=[mem_addr]
-    irq=[irq_num].
-
-    The following IRQ, IO, and MEM settings are supported.
-
-    IO ports:
-    0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0, 0x300,
-    0x320, 0x340, 0x360, 0x380.
-
-    IRQs:
-    2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15
-
-    Memory addresses:
-    0xA0000, 0xA4000, 0xA8000, 0xAC000, 0xB0000, 0xB4000,
-    0xB8000, 0xBC000, 0xC0000, 0xC4000, 0xC8000, 0xCC000,
-    0xD0000, 0xD4000, 0xD8000, 0xDC000, 0xE0000, 0xE4000,
-    0xE8000, 0xEC000, 0xF0000, 0xF4000, 0xF8000, 0xFC000
-
-This driver is under the GNU General Public License. Its Firmware image is
-included as an initialized C-array and is licensed by SMC to the Linux
-users of this driver. However no warranty about its fitness is expressed or
-implied by SMC.
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index d0aeeadd264b..5cb9a1972460 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -10,8 +10,8 @@ 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 MAC 10/100
-Universal version 4.0 have been used for developing this driver.
+DWC Ether MAC 10/100/1000 Universal version 3.60a (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.
 
@@ -54,27 +54,27 @@ net_device structure enabling the scatter/gather feature.
 When one or more packets are received, an interrupt happens. The interrupts
 are not queued so the driver has to scan all the descriptors in the ring during
 the receive process.
-This is based on NAPI so the interrupt handler signals only if there is work to be
-done, and it exits.
+This is based on NAPI so the interrupt handler signals only if there is work
+to be done, and it exits.
 Then the poll method will be scheduled at some future point.
 The incoming packets are stored, by the DMA, in a list of pre-allocated socket
 buffers in order to avoid the memcpy (Zero-copy).
 
 4.3) Timer-Driver Interrupt
-Instead of having the device that asynchronously notifies the frame receptions, the
-driver configures a timer to generate an interrupt at regular intervals.
-Based on the granularity of the timer, the frames that are received by the device
-will experience different levels of latency. Some NICs have dedicated timer
-device to perform this task. STMMAC can use either the RTC device or the TMU
-channel 2  on STLinux platforms.
+Instead of having the device that asynchronously notifies the frame receptions,
+the driver configures a timer to generate an interrupt at regular intervals.
+Based on the granularity of the timer, the frames that are received by the
+device will experience different levels of latency. Some NICs have dedicated
+timer device to perform this task. STMMAC can use either the RTC device or the
+TMU channel 2  on STLinux platforms.
 The timers frequency can be passed to the driver as parameter; when change it,
 take care of both hardware capability and network stability/performance impact.
-Several performance tests on STM platforms showed this optimisation allows to spare
-the CPU while having the maximum throughput.
+Several performance tests on STM platforms showed this optimisation allows to
+spare the CPU while having the maximum throughput.
 
 4.4) WOL
-Wake up on Lan feature through Magic and Unicast frames are supported for the GMAC
-core.
+Wake up on Lan feature through Magic and Unicast frames are supported for the
+GMAC core.
 
 4.5) DMA descriptors
 Driver handles both normal and enhanced descriptors. The latter has been only
@@ -106,16 +106,18 @@ Several driver's information can be passed through the platform
 These are included in the include/linux/stmmac.h header file
 and detailed below as well:
 
- struct plat_stmmacenet_data {
+struct plat_stmmacenet_data {
+        char *phy_bus_name;
         int bus_id;
         int phy_addr;
         int interface;
         struct stmmac_mdio_bus_data *mdio_bus_data;
-        int pbl;
+        struct stmmac_dma_cfg *dma_cfg;
         int clk_csr;
         int has_gmac;
         int enh_desc;
         int tx_coe;
+        int rx_coe;
         int bugged_jumbo;
         int pmt;
         int force_sf_dma_mode;
@@ -123,23 +125,30 @@ and detailed below as well:
         void (*bus_setup)(void __iomem *ioaddr);
         int (*init)(struct platform_device *pdev);
         void (*exit)(struct platform_device *pdev);
+        void *custom_cfg;
+        void *custom_data;
         void *bsp_priv;
  };
 
 Where:
+ o phy_bus_name: phy bus name to attach to the stmmac.
  o bus_id: bus identifier.
  o phy_addr: the physical address can be passed from the platform.
             If it is set to -1 the driver will automatically
             detect it at run-time by probing all the 32 addresses.
  o interface: PHY device's interface.
  o mdio_bus_data: specific platform fields for the MDIO bus.
- o pbl: the Programmable Burst Length is maximum number of beats to
+ o dma_cfg: internal DMA parameters
+   o pbl: the Programmable Burst Length is maximum number of beats to
        be transferred in one DMA transaction.
        GMAC also enables the 4xPBL by default.
- o clk_csr: CSR Clock range selection.
+   o fixed_burst/mixed_burst/burst_len
+ o clk_csr: fixed CSR Clock range selection.
  o has_gmac: uses the GMAC core.
  o enh_desc: if sets the MAC will use the enhanced descriptor structure.
  o tx_coe: core is able to perform the tx csum in HW.
+ o rx_coe: the supports three check sum offloading engine types:
+           type_1, type_2 (full csum) and no RX coe.
  o bugged_jumbo: some HWs are not able to perform the csum in HW for
                 over-sized frames due to limited buffer sizes.
                 Setting this flag the csum will be done in SW on
@@ -157,10 +166,11 @@ Where:
              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: this is a custom configuration that can be passed while
-              initialising the resources.
+ o custom_cfg/custom_data: this is a custom configuration that can be passed
+                           while initialising the resources.
+ o bsp_priv: another private poiter.
 
-The we have:
+For MDIO bus The we have:
 
  struct stmmac_mdio_bus_data {
         int bus_id;
@@ -177,10 +187,27 @@ Where:
  o irqs: list of IRQs, one per PHY.
  o probed_phy_irq: if irqs is NULL, use this for probed PHY.
 
+For DMA engine we have the following internal fields that should be
+tuned according to the HW capabilities.
+
+struct stmmac_dma_cfg {
+        int pbl;
+        int fixed_burst;
+        int burst_len_supported;
+};
+
+Where:
+ o pbl: Programmable Burst Length
+ o fixed_burst: program the DMA to use the fixed burst mode
+ o burst_len: this is the value we put in the register
+              supported values are provided as macros in
+              linux/stmmac.h header file.
+
+---
+
 Below an example how the structures above are using on ST platforms.
 
  static struct plat_stmmacenet_data stxYYY_ethernet_platform_data = {
-        .pbl = 32,
         .has_gmac = 0,
         .enh_desc = 0,
         .fix_mac_speed = stxYYY_ethernet_fix_mac_speed,
diff --git a/Documentation/networking/tms380tr.txt b/Documentation/networking/tms380tr.txt
deleted file mode 100644
index 1f73e13058df..000000000000
--- a/Documentation/networking/tms380tr.txt
+++ /dev/null
@@ -1,147 +0,0 @@
-Text file for the Linux SysKonnect Token Ring ISA/PCI Adapter Driver.
-        Text file by: Jay Schulist <jschlst@samba.org>
-
-The Linux SysKonnect Token Ring driver works with the SysKonnect TR4/16(+) ISA,
-SysKonnect TR4/16(+) PCI, SysKonnect TR4/16 PCI, and older revisions of the
-SK NET TR4/16 ISA card.
-
-Latest information on this driver can be obtained on the Linux-SNA WWW site.
-Please point your browser to: 
-http://www.linux-sna.org
-
-Many thanks to Christoph Goos for his excellent work on this driver and
-SysKonnect for donating the adapters to Linux-SNA for the testing and 
-maintenance of this device driver.
-
-Important information to be noted:
-1. Adapters can be slow to open (~20 secs) and close (~5 secs), please be 
-   patient.
-2. This driver works very well when autoprobing for adapters. Why even 
-   think about those nasty io/int/dma settings of modprobe when the driver 
-   will do it all for you!
-
-This driver is rather simple to use. Select Y to Token Ring adapter support
-in the kernel configuration. A choice for SysKonnect Token Ring adapters will
-appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this
-option. I personally recommend compiling the driver as a module (M), but if you
-you would like to compile it statically answer Y instead.
-
-This driver supports multiple adapters without the need to load multiple copies
-of the driver. You should be able to load up to 7 adapters without any kernel
-modifications, if you are in need of more please contact the maintainer of this
-driver.
-
-Load the driver either by lilo/loadlin or as a module. When a module using the
-following command will suffice for most:
-
-# modprobe sktr
-
-This will produce output similar to the following: (Output is user specific)
-
-sktr.c: v1.01 08/29/97 by Christoph Goos
-tr0: SK NET TR 4/16 PCI found at 0x6100, using IRQ 17.
-tr1: SK NET TR 4/16 PCI found at 0x6200, using IRQ 16.
-tr2: SK NET TR 4/16 ISA found at 0xa20, using IRQ 10 and DMA 5.
-
-Now just setup the device via ifconfig and set and routes you may have. After
-this you are ready to start sending some tokens.
-
-Errata:
-For anyone wondering where to pick up the SysKonnect adapters please browse
-to http://www.syskonnect.com
-
-This driver is under the GNU General Public License. Its Firmware image is 
-included as an initialized C-array and is licensed by SysKonnect to the Linux 
-users of this driver. However no warranty about its fitness is expressed or 
-implied by SysKonnect.
-
-Below find attached the setting for the SK NET TR 4/16 ISA adapters
--------------------------------------------------------------------
-
-                    ***************************
-                    ***   C O N T E N T S   ***
-                    ***************************
-
-                1) Location of DIP-Switch W1
-                2) Default settings
-                3) DIP-Switch W1 description
-
-
-  ==============================================================
-  CHAPTER 1     LOCATION OF DIP-SWITCH
-  ==============================================================
-
-UÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
-þUÄÄÄÄÄÄ¿                         UÄÄÄÄÄ¿            UÄÄÄ¿         þ
-þAÄÄÄÄÄÄU                      W1 AÄÄÄÄÄU     UÄÄÄÄ¿ þ   þ         þ
-þUÄÄÄÄÄÄ¿                                     þ    þ þ   þ      UÄÄÅ¿
-þAÄÄÄÄÄÄU              UÄÄÄÄÄÄÄÄÄÄÄ¿          AÄÄÄÄU þ   þ      þ  þþ
-þUÄÄÄÄÄÄ¿              þ           þ          UÄÄÄ¿  AÄÄÄU      AÄÄÅU
-þAÄÄÄÄÄÄU              þ TMS380C26 þ          þ   þ                þ
-þUÄÄÄÄÄÄ¿              þ           þ          AÄÄÄU                AÄ¿
-þAÄÄÄÄÄÄU              þ           þ                               þ þ
-þ                      AÄÄÄÄÄÄÄÄÄÄÄU                               þ þ
-þ                                                                  þ þ
-þ                                                                  AÄU
-þ                                                                  þ
-þ                                                                  þ
-þ                                                                  þ
-þ                                                                  þ
-AÄÄÄÄÄÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄAÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄU
-             AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄU  AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄU
-
-  ==============================================================
-  CHAPTER 2     DEFAULT SETTINGS
-  ==============================================================
-
-          W1    1  2  3  4  5  6  7  8
-        +------------------------------+
-        | ON    X                      |
-        | OFF      X  X  X  X  X  X  X |
-        +------------------------------+
-
-        W1.1 = ON               Adapter drives address lines SA17..19
-        W1.2 - 1.5 = OFF        BootROM disabled
-        W1.6 - 1.8 = OFF        I/O address 0A20h
-
-  ==============================================================
-  CHAPTER 3     DIP SWITCH W1 DESCRIPTION
-  ==============================================================
-
-      UÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄ¿  ON
-      þ 1 þ 2 þ 3 þ 4 þ 5 þ 6 þ 7 þ 8 þ
-      AÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄU  OFF
-      |AD | BootROM Addr. |  I/O      |
-      +-+-+-------+-------+-----+-----+
-        |         |             |
-        |         |             +------ 6     7     8
-        |         |                     ON    ON    ON       1900h
-        |         |                     ON    ON    OFF      0900h
-        |         |                     ON    OFF   ON       1980h
-        |         |                     ON    OFF   OFF      0980h
-        |         |                     OFF   ON    ON       1b20h
-        |         |                     OFF   ON    OFF      0b20h
-        |         |                     OFF   OFF   ON       1a20h
-        |         |                     OFF   OFF   OFF      0a20h    (+)
-        |         |
-        |         |
-        |         +-------- 2     3     4     5
-        |                   OFF   x     x     x       disabled  (+)
-        |                   ON    ON    ON    ON      C0000
-        |                   ON    ON    ON    OFF     C4000
-        |                   ON    ON    OFF   ON      C8000
-        |                   ON    ON    OFF   OFF     CC000
-        |                   ON    OFF   ON    ON      D0000
-        |                   ON    OFF   ON    OFF     D4000
-        |                   ON    OFF   OFF   ON      D8000
-        |                   ON    OFF   OFF   OFF     DC000
-        |
-        |
-        +----- 1
-               OFF    adapter does NOT drive SA<17..19>
-               ON     adapter drives SA<17..19>  (+)
-
-
-        (+) means default setting
-
-                       ********************************
diff --git a/Documentation/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt
new file mode 100644
index 000000000000..320f9336c781
--- /dev/null
+++ b/Documentation/nfc/nfc-hci.txt
@@ -0,0 +1,180 @@
+HCI backend for NFC Core
+
+Author: Eric Lapuyade, Samuel Ortiz
+Contact: eric.lapuyade@intel.com, samuel.ortiz@intel.com
+
+General
+-------
+
+The HCI layer implements much of the ETSI TS 102 622 V10.2.0 specification. It
+enables easy writing of HCI-based NFC drivers. The HCI layer runs as an NFC Core
+backend, implementing an abstract nfc device and translating NFC Core API
+to HCI commands and events.
+
+HCI
+---
+
+HCI registers as an nfc device with NFC Core. Requests coming from userspace are
+routed through netlink sockets to NFC Core and then to HCI. From this point,
+they are translated in a sequence of HCI commands sent to the HCI layer in the
+host controller (the chip). The sending context blocks while waiting for the
+response to arrive.
+HCI events can also be received from the host controller. They will be handled
+and a translation will be forwarded to NFC Core as needed.
+HCI uses 2 execution contexts:
+- one for executing commands : nfc_hci_msg_tx_work(). Only one command
+can be executing at any given moment.
+- one for dispatching received events and commands : nfc_hci_msg_rx_work().
+
+HCI Session initialization:
+---------------------------
+
+The Session initialization is an HCI standard which must unfortunately
+support proprietary gates. This is the reason why the driver will pass a list
+of proprietary gates that must be part of the session. HCI will ensure all
+those gates have pipes connected when the hci device is set up.
+
+HCI Gates and Pipes
+-------------------
+
+A gate defines the 'port' where some service can be found. In order to access
+a service, one must create a pipe to that gate and open it. In this
+implementation, pipes are totally hidden. The public API only knows gates.
+This is consistent with the driver need to send commands to proprietary gates
+without knowing the pipe connected to it.
+
+Driver interface
+----------------
+
+A driver would normally register itself with HCI and provide the following
+entry points:
+
+struct nfc_hci_ops {
+        int (*open)(struct nfc_hci_dev *hdev);
+        void (*close)(struct nfc_hci_dev *hdev);
+        int (*hci_ready) (struct nfc_hci_dev *hdev);
+        int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb);
+        int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols);
+        int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate,
+                                struct nfc_target *target);
+        int (*complete_target_discovered) (struct nfc_hci_dev *hdev, u8 gate,
+                                           struct nfc_target *target);
+        int (*data_exchange) (struct nfc_hci_dev *hdev,
+                              struct nfc_target *target,
+                              struct sk_buff *skb, struct sk_buff **res_skb);
+        int (*check_presence)(struct nfc_hci_dev *hdev,
+                              struct nfc_target *target);
+};
+
+- open() and close() shall turn the hardware on and off.
+- hci_ready() is an optional entry point that is called right after the hci
+session has been set up. The driver can use it to do additional initialization
+that must be performed using HCI commands.
+- xmit() shall simply write a frame to the chip.
+- start_poll() is an optional entrypoint that shall set the hardware in polling
+mode. This must be implemented only if the hardware uses proprietary gates or a
+mechanism slightly different from the HCI standard.
+- target_from_gate() is an optional entrypoint to return the nfc protocols
+corresponding to a proprietary gate.
+- complete_target_discovered() is an optional entry point to let the driver
+perform additional proprietary processing necessary to auto activate the
+discovered target.
+- data_exchange() must be implemented by the driver if proprietary HCI commands
+are required to send data to the tag. Some tag types will require custom
+commands, others can be written to using the standard HCI commands. The driver
+can check the tag type and either do proprietary processing, or return 1 to ask
+for standard processing.
+- check_presence() is an optional entry point that will be called regularly
+by the core to check that an activated tag is still in the field. If this is
+not implemented, the core will not be able to push tag_lost events to the user
+space
+
+On the rx path, the driver is responsible to push incoming HCP frames to HCI
+using nfc_hci_recv_frame(). HCI will take care of re-aggregation and handling
+This must be done from a context that can sleep.
+
+SHDLC
+-----
+
+Most chips use shdlc to ensure integrity and delivery ordering of the HCP
+frames between the host controller (the chip) and hosts (entities connected
+to the chip, like the cpu). In order to simplify writing the driver, an shdlc
+layer is available for use by the driver.
+When used, the driver actually registers with shdlc, and shdlc will register
+with HCI. HCI sees shdlc as the driver and thus send its HCP frames
+through shdlc->xmit.
+SHDLC adds a new execution context (nfc_shdlc_sm_work()) to run its state
+machine and handle both its rx and tx path.
+
+Included Drivers
+----------------
+
+An HCI based driver for an NXP PN544, connected through I2C bus, and using
+shdlc is included.
+
+Execution Contexts
+------------------
+
+The execution contexts are the following:
+- IRQ handler (IRQH):
+fast, cannot sleep. stores incoming frames into an shdlc rx queue
+
+- SHDLC State Machine worker (SMW)
+handles shdlc rx & tx queues. Dispatches HCI cmd responses.
+
+- HCI Tx Cmd worker (MSGTXWQ)
+Serializes execution of HCI commands. Completes execution in case of response
+timeout.
+
+- HCI Rx worker (MSGRXWQ)
+Dispatches incoming HCI commands or events.
+
+- Syscall context from a userspace call (SYSCALL)
+Any entrypoint in HCI called from NFC Core
+
+Workflow executing an HCI command (using shdlc)
+-----------------------------------------------
+
+Executing an HCI command can easily be performed synchronously using the
+following API:
+
+int nfc_hci_send_cmd (struct nfc_hci_dev *hdev, u8 gate, u8 cmd,
+                        const u8 *param, size_t param_len, struct sk_buff **skb)
+
+The API must be invoked from a context that can sleep. Most of the time, this
+will be the syscall context. skb will return the result that was received in
+the response.
+
+Internally, execution is asynchronous. So all this API does is to enqueue the
+HCI command, setup a local wait queue on stack, and wait_event() for completion.
+The wait is not interruptible because it is guaranteed that the command will
+complete after some short timeout anyway.
+
+MSGTXWQ context will then be scheduled and invoke nfc_hci_msg_tx_work().
+This function will dequeue the next pending command and send its HCP fragments
+to the lower layer which happens to be shdlc. It will then start a timer to be
+able to complete the command with a timeout error if no response arrive.
+
+SMW context gets scheduled and invokes nfc_shdlc_sm_work(). This function
+handles shdlc framing in and out. It uses the driver xmit to send frames and
+receives incoming frames in an skb queue filled from the driver IRQ handler.
+SHDLC I(nformation) frames payload are HCP fragments. They are aggregated to
+form complete HCI frames, which can be a response, command, or event.
+
+HCI Responses are dispatched immediately from this context to unblock
+waiting command execution. Response processing involves invoking the completion
+callback that was provided by nfc_hci_msg_tx_work() when it sent the command.
+The completion callback will then wake the syscall context.
+
+Workflow receiving an HCI event or command
+------------------------------------------
+
+HCI commands or events are not dispatched from SMW context. Instead, they are
+queued to HCI rx_queue and will be dispatched from HCI rx worker
+context (MSGRXWQ). This is done this way to allow a cmd or event handler
+to also execute other commands (for example, handling the
+NFC_HCI_EVT_TARGET_DISCOVERED event from PN544 requires to issue an
+ANY_GET_PARAMETER to the reader A gate to get information on the target
+that was discovered).
+
+Typically, such an event will be propagated to NFC Core from MSGRXWQ context.
diff --git a/Documentation/parisc/debugging b/Documentation/parisc/debugging
index d728594058e5..7d75223fa18d 100644
--- a/Documentation/parisc/debugging
+++ b/Documentation/parisc/debugging
@@ -34,6 +34,6 @@ registers interruption handlers read to find out where the machine
 was interrupted - so if you get an interruption between the instruction
 that clears the Q bit and the RFI that sets it again you don't know
 where exactly it happened.  If you're lucky the IAOQ will point to the
-instrucion that cleared the Q bit, if you're not it points anywhere
+instruction that cleared the Q bit, if you're not it points anywhere
 at all.  Usually Q bit problems will show themselves in unexplainable
 system hangs or running off the end of physical memory.
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index d97bccf46147..e40f4b4e1977 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -152,11 +152,9 @@ static const struct foo_group foo_groups[] = {
 };
 
 
-static int foo_list_groups(struct pinctrl_dev *pctldev, unsigned selector)
+static int foo_get_groups_count(struct pinctrl_dev *pctldev)
 {
-        if (selector >= ARRAY_SIZE(foo_groups))
-                return -EINVAL;
-        return 0;
+        return ARRAY_SIZE(foo_groups);
 }
 
 static const char *foo_get_group_name(struct pinctrl_dev *pctldev,
@@ -175,7 +173,7 @@ static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,
 }
 
 static struct pinctrl_ops foo_pctrl_ops = {
-        .list_groups = foo_list_groups,
+        .get_groups_count = foo_get_groups_count,
         .get_group_name = foo_get_group_name,
         .get_group_pins = foo_get_group_pins,
 };
@@ -186,13 +184,12 @@ static struct pinctrl_desc foo_desc = {
        .pctlops = &foo_pctrl_ops,
 };
 
-The pin control subsystem will call the .list_groups() function repeatedly
-beginning on 0 until it returns non-zero to determine legal selectors, then
-it will call the other functions to retrieve the name and pins of the group.
-Maintaining the data structure of the groups is up to the driver, this is
-just a simple example - in practice you may need more entries in your group
-structure, for example specific register ranges associated with each group
-and so on.
+The pin control subsystem will call the .get_groups_count() function to
+determine total number of legal selectors, then it will call the other functions
+to retrieve the name and pins of the group. Maintaining the data structure of
+the groups is up to the driver, this is just a simple example - in practice you
+may need more entries in your group structure, for example specific register
+ranges associated with each group and so on.
 
 
 Pin configuration
@@ -606,11 +603,9 @@ static const struct foo_group foo_groups[] = {
 };
 
 
-static int foo_list_groups(struct pinctrl_dev *pctldev, unsigned selector)
+static int foo_get_groups_count(struct pinctrl_dev *pctldev)
 {
-        if (selector >= ARRAY_SIZE(foo_groups))
-                return -EINVAL;
-        return 0;
+        return ARRAY_SIZE(foo_groups);
 }
 
 static const char *foo_get_group_name(struct pinctrl_dev *pctldev,
@@ -629,7 +624,7 @@ static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,
 }
 
 static struct pinctrl_ops foo_pctrl_ops = {
-        .list_groups = foo_list_groups,
+        .get_groups_count = foo_get_groups_count,
         .get_group_name = foo_get_group_name,
         .get_group_pins = foo_get_group_pins,
 };
@@ -640,7 +635,7 @@ struct foo_pmx_func {
         const unsigned num_groups;
 };
 
-static const char * const spi0_groups[] = { "spi0_1_grp" };
+static const char * const spi0_groups[] = { "spi0_0_grp", "spi0_1_grp" };
 static const char * const i2c0_groups[] = { "i2c0_grp" };
 static const char * const mmc0_groups[] = { "mmc0_1_grp", "mmc0_2_grp",
                                         "mmc0_3_grp" };
@@ -663,11 +658,9 @@ static const struct foo_pmx_func foo_functions[] = {
         },
 };
 
-int foo_list_funcs(struct pinctrl_dev *pctldev, unsigned selector)
+int foo_get_functions_count(struct pinctrl_dev *pctldev)
 {
-        if (selector >= ARRAY_SIZE(foo_functions))
-                return -EINVAL;
-        return 0;
+        return ARRAY_SIZE(foo_functions);
 }
 
 const char *foo_get_fname(struct pinctrl_dev *pctldev, unsigned selector)
@@ -703,7 +696,7 @@ void foo_disable(struct pinctrl_dev *pctldev, unsigned selector,
 }
 
 struct pinmux_ops foo_pmxops = {
-        .list_functions = foo_list_funcs,
+        .get_functions_count = foo_get_functions_count,
         .get_function_name = foo_get_fname,
         .get_function_groups = foo_get_groups,
         .enable = foo_enable,
@@ -786,7 +779,7 @@ and spi on the second function mapping:
 
 #include <linux/pinctrl/machine.h>
 
-static const struct pinctrl_map __initdata mapping[] = {
+static const struct pinctrl_map mapping[] __initconst = {
         {
                 .dev_name = "foo-spi.0",
                 .name = PINCTRL_STATE_DEFAULT,
@@ -952,13 +945,13 @@ case), we define a mapping like this:
 The result of grabbing this mapping from the device with something like
 this (see next paragraph):
 
-        p = pinctrl_get(dev);
+        p = devm_pinctrl_get(dev);
         s = pinctrl_lookup_state(p, "8bit");
         ret = pinctrl_select_state(p, s);
 
 or more simply:
 
-        p = pinctrl_get_select(dev, "8bit");
+        p = devm_pinctrl_get_select(dev, "8bit");
 
 Will be that you activate all the three bottom records in the mapping at
 once. Since they share the same name, pin controller device, function and
@@ -992,7 +985,7 @@ foo_probe()
         /* Allocate a state holder named "foo" etc */
         struct foo_state *foo = ...;
 
-        foo->p = pinctrl_get(&device);
+        foo->p = devm_pinctrl_get(&device);
         if (IS_ERR(foo->p)) {
                 /* FIXME: clean up "foo" here */
                 return PTR_ERR(foo->p);
@@ -1000,24 +993,17 @@ foo_probe()
 
         foo->s = pinctrl_lookup_state(foo->p, PINCTRL_STATE_DEFAULT);
         if (IS_ERR(foo->s)) {
-                pinctrl_put(foo->p);
                 /* FIXME: clean up "foo" here */
                 return PTR_ERR(s);
         }
 
         ret = pinctrl_select_state(foo->s);
         if (ret < 0) {
-                pinctrl_put(foo->p);
                 /* FIXME: clean up "foo" here */
                 return ret;
         }
 }
 
-foo_remove()
-{
-        pinctrl_put(state->p);
-}
-
 This get/lookup/select/put sequence can just as well be handled by bus drivers
 if you don't want each and every driver to handle it and you know the
 arrangement on your bus.
@@ -1029,6 +1015,11 @@ The semantics of the pinctrl APIs are:
   kernel memory to hold the pinmux state. All mapping table parsing or similar
   slow operations take place within this API.
 
+- devm_pinctrl_get() is a variant of pinctrl_get() that causes pinctrl_put()
+  to be called automatically on the retrieved pointer when the associated
+  device is removed. It is recommended to use this function over plain
+  pinctrl_get().
+
 - pinctrl_lookup_state() is called in process context to obtain a handle to a
   specific state for a the client device. This operation may be slow too.
 
@@ -1041,14 +1032,30 @@ The semantics of the pinctrl APIs are:
 
 - pinctrl_put() frees all information associated with a pinctrl handle.
 
+- devm_pinctrl_put() is a variant of pinctrl_put() that may be used to
+  explicitly destroy a pinctrl object returned by devm_pinctrl_get().
+  However, use of this function will be rare, due to the automatic cleanup
+  that will occur even without calling it.
+
+  pinctrl_get() must be paired with a plain pinctrl_put().
+  pinctrl_get() may not be paired with devm_pinctrl_put().
+  devm_pinctrl_get() can optionally be paired with devm_pinctrl_put().
+  devm_pinctrl_get() may not be paired with plain pinctrl_put().
+
 Usually the pin control core handled the get/put pair and call out to the
 device drivers bookkeeping operations, like checking available functions and
 the associated pins, whereas the enable/disable pass on to the pin controller
 driver which takes care of activating and/or deactivating the mux setting by
 quickly poking some registers.
 
-The pins are allocated for your device when you issue the pinctrl_get() call,
-after this you should be able to see this in the debugfs listing of all pins.
+The pins are allocated for your device when you issue the devm_pinctrl_get()
+call, after this you should be able to see this in the debugfs listing of all
+pins.
+
+NOTE: the pinctrl system will return -EPROBE_DEFER if it cannot find the
+requested pinctrl handles, for example if the pinctrl driver has not yet
+registered. Thus make sure that the error path in your driver gracefully
+cleans up and is ready to retry the probing later in the startup process.
 
 
 System pin control hogging
@@ -1094,13 +1101,13 @@ it, disables and releases it, and muxes it in on the pins defined by group B:
 
 #include <linux/pinctrl/consumer.h>
 
-foo_switch()
-{
-        struct pinctrl *p;
-        struct pinctrl_state *s1, *s2;
+struct pinctrl *p;
+struct pinctrl_state *s1, *s2;
 
+foo_probe()
+{
         /* Setup */
-        p = pinctrl_get(&device);
+        p = devm_pinctrl_get(&device);
         if (IS_ERR(p))
                 ...
 
@@ -1111,7 +1118,10 @@ foo_switch()
         s2 = pinctrl_lookup_state(foo->p, "pos-B");
         if (IS_ERR(s2))
                 ...
+}
 
+foo_switch()
+{
         /* Enable on position A */
         ret = pinctrl_select_state(s1);
         if (ret < 0)
@@ -1125,8 +1135,6 @@ foo_switch()
             ...
 
         ...
-
-        pinctrl_put(p);
 }
 
 The above has to be done from process context.
diff --git a/Documentation/power/charger-manager.txt b/Documentation/power/charger-manager.txt
index fdcca991df30..b4f7f4b23f64 100644
--- a/Documentation/power/charger-manager.txt
+++ b/Documentation/power/charger-manager.txt
@@ -44,6 +44,16 @@ Charger Manager supports the following:
         Normally, the platform will need to resume and suspend some devices
         that are used by Charger Manager.
 
+* Support for premature full-battery event handling
+        If the battery voltage drops by "fullbatt_vchkdrop_uV" after
+        "fullbatt_vchkdrop_ms" from the full-battery event, the framework
+        restarts charging. This check is also performed while suspended by
+        setting wakeup time accordingly and using suspend_again.
+
+* Support for uevent-notify
+        With the charger-related events, the device sends
+        notification to users with UEVENT.
+
 2. Global Charger-Manager Data related with suspend_again
 ========================================================
 In order to setup Charger Manager with suspend-again feature
@@ -55,7 +65,7 @@ if there are multiple batteries. If there are multiple batteries, the
 multiple instances of Charger Manager share the same charger_global_desc
 and it will manage in-suspend monitoring for all instances of Charger Manager.
 
-The user needs to provide all the two entries properly in order to activate
+The user needs to provide all the three entries properly in order to activate
 in-suspend monitoring:
 
 struct charger_global_desc {
@@ -74,6 +84,11 @@ bool (*rtc_only_wakeup)(void);
         same struct. If there is any other wakeup source triggered the
         wakeup, it should return false. If the "rtc" is the only wakeup
         reason, it should return true.
+
+bool assume_timer_stops_in_suspend;
+        : if true, Charger Manager assumes that
+        the timer (CM uses jiffies as timer) stops during suspend. Then, CM
+        assumes that the suspend-duration is same as the alarm length.
 };
 
 3. How to setup suspend_again
@@ -111,6 +126,16 @@ enum polling_modes polling_mode;
           CM_POLL_CHARGING_ONLY: poll this battery if and only if the
                                  battery is being charged.
 
+unsigned int fullbatt_vchkdrop_ms;
+unsigned int fullbatt_vchkdrop_uV;
+        : If both have non-zero values, Charger Manager will check the
+        battery voltage drop fullbatt_vchkdrop_ms after the battery is fully
+        charged. If the voltage drop is over fullbatt_vchkdrop_uV, Charger
+        Manager will try to recharge the battery by disabling and enabling
+        chargers. Recharge with voltage drop condition only (without delay
+        condition) is needed to be implemented with hardware interrupts from
+        fuel gauges or charger devices/chips.
+
 unsigned int fullbatt_uV;
         : If specified with a non-zero value, Charger Manager assumes
         that the battery is full (capacity = 100) if the battery is not being
@@ -122,6 +147,8 @@ unsigned int polling_interval_ms;
         this battery every polling_interval_ms or more frequently.
 
 enum data_source battery_present;
+        : CM_BATTERY_PRESENT: assume that the battery exists.
+        CM_NO_BATTERY: assume that the battery does not exists.
         CM_FUEL_GAUGE: get battery presence information from fuel gauge.
         CM_CHARGER_STAT: get battery presence from chargers.
 
@@ -151,7 +178,17 @@ bool measure_battery_temp;
         the value of measure_battery_temp.
 };
 
-5. Other Considerations
+5. Notify Charger-Manager of charger events: cm_notify_event()
+=========================================================
+If there is an charger event is required to notify
+Charger Manager, a charger device driver that triggers the event can call
+cm_notify_event(psy, type, msg) to notify the corresponding Charger Manager.
+In the function, psy is the charger driver's power_supply pointer, which is
+associated with Charger-Manager. The parameter "type"
+is the same as irq's type (enum cm_event_types). The event message "msg" is
+optional and is effective only if the event type is "UNDESCRIBED" or "OTHERS".
+
+6. Other Considerations
 =======================
 
 At the charger/battery-related events such as battery-pulled-out,
diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt
index 9f16c5178b66..211831d4095f 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -84,6 +84,8 @@ are already charged or discharging, 'n/a' can be displayed (or
 HEALTH - represents health of the battery, values corresponds to
 POWER_SUPPLY_HEALTH_*, defined in battery.h.
 
+VOLTAGE_OCV - open circuit voltage of the battery.
+
 VOLTAGE_MAX_DESIGN, VOLTAGE_MIN_DESIGN - design values for maximal and
 minimal power supply voltages. Maximal/minimal means values of voltages
 when battery considered "full"/"empty" at normal conditions. Yes, there is
diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt
index e272d9909e39..13902778ae44 100644
--- a/Documentation/power/regulator/regulator.txt
+++ b/Documentation/power/regulator/regulator.txt
@@ -11,8 +11,7 @@ Registration
 Drivers can register a regulator by calling :-
 
 struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
-        struct device *dev, struct regulator_init_data *init_data,
-        void *driver_data, struct device_node *of_node);
+                                         const struct regulator_config *config);
 
 This will register the regulators capabilities and operations to the regulator
 core.
diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.txt
index f28f9a6f0347..e13dafc8e8f1 100644
--- a/Documentation/power/suspend-and-cpuhotplug.txt
+++ b/Documentation/power/suspend-and-cpuhotplug.txt
@@ -29,7 +29,7 @@ More details follow:
 
                                   Write 'mem' to
                                 /sys/power/state
-                                    syfs file
+                                    sysfs file
                                         |
                                         v
                                Acquire pm_mutex lock
diff --git a/Documentation/prctl/no_new_privs.txt b/Documentation/prctl/no_new_privs.txt
new file mode 100644
index 000000000000..f7be84fba910
--- /dev/null
+++ b/Documentation/prctl/no_new_privs.txt
@@ -0,0 +1,57 @@
+The execve system call can grant a newly-started program privileges that
+its parent did not have.  The most obvious examples are setuid/setgid
+programs and file capabilities.  To prevent the parent program from
+gaining these privileges as well, the kernel and user code must be
+careful to prevent the parent from doing anything that could subvert the
+child.  For example:
+
+ - The dynamic loader handles LD_* environment variables differently if
+   a program is setuid.
+
+ - chroot is disallowed to unprivileged processes, since it would allow
+   /etc/passwd to be replaced from the point of view of a process that
+   inherited chroot.
+
+ - The exec code has special handling for ptrace.
+
+These are all ad-hoc fixes.  The no_new_privs bit (since Linux 3.5) is a
+new, generic mechanism to make it safe for a process to modify its
+execution environment in a manner that persists across execve.  Any task
+can set no_new_privs.  Once the bit is set, it is inherited across fork,
+clone, and execve and cannot be unset.  With no_new_privs set, execve
+promises not to grant the privilege to do anything that could not have
+been done without the execve call.  For example, the setuid and setgid
+bits will no longer change the uid or gid; file capabilities will not
+add to the permitted set, and LSMs will not relax constraints after
+execve.
+
+To set no_new_privs, use prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0).
+
+Be careful, though: LSMs might also not tighten constraints on exec
+in no_new_privs mode.  (This means that setting up a general-purpose
+service launcher to set no_new_privs before execing daemons may
+interfere with LSM-based sandboxing.)
+
+Note that no_new_privs does not prevent privilege changes that do not
+involve execve.  An appropriately privileged task can still call
+setuid(2) and receive SCM_RIGHTS datagrams.
+
+There are two main use cases for no_new_privs so far:
+
+ - Filters installed for the seccomp mode 2 sandbox persist across
+   execve and can change the behavior of newly-executed programs.
+   Unprivileged users are therefore only allowed to install such filters
+   if no_new_privs is set.
+
+ - By itself, no_new_privs can be used to reduce the attack surface
+   available to an unprivileged user.  If everything running with a
+   given uid has no_new_privs set, then that uid will be unable to
+   escalate its privileges by directly attacking setuid, setgid, and
+   fcap-using binaries; it will need to compromise something without the
+   no_new_privs bit set first.
+
+In the future, other potentially dangerous kernel features could become
+available to unprivileged tasks if no_new_privs is set.  In principle,
+several options to unshare(2) and clone(2) would be safe when
+no_new_privs is set, and no_new_privs + chroot is considerable less
+dangerous than chroot by itself.
diff --git a/Documentation/prctl/seccomp_filter.txt b/Documentation/prctl/seccomp_filter.txt
new file mode 100644
index 000000000000..597c3c581375
--- /dev/null
+++ b/Documentation/prctl/seccomp_filter.txt
@@ -0,0 +1,163 @@
+                SECure COMPuting with filters
+                =============================
+
+Introduction
+------------
+
+A large number of system calls are exposed to every userland process
+with many of them going unused for the entire lifetime of the process.
+As system calls change and mature, bugs are found and eradicated.  A
+certain subset of userland applications benefit by having a reduced set
+of available system calls.  The resulting set reduces the total kernel
+surface exposed to the application.  System call filtering is meant for
+use with those applications.
+
+Seccomp filtering provides a means for a process to specify a filter for
+incoming system calls.  The filter is expressed as a Berkeley Packet
+Filter (BPF) program, as with socket filters, except that the data
+operated on is related to the system call being made: system call
+number and the system call arguments.  This allows for expressive
+filtering of system calls using a filter program language with a long
+history of being exposed to userland and a straightforward data set.
+
+Additionally, BPF makes it impossible for users of seccomp to fall prey
+to time-of-check-time-of-use (TOCTOU) attacks that are common in system
+call interposition frameworks.  BPF programs may not dereference
+pointers which constrains all filters to solely evaluating the system
+call arguments directly.
+
+What it isn't
+-------------
+
+System call filtering isn't a sandbox.  It provides a clearly defined
+mechanism for minimizing the exposed kernel surface.  It is meant to be
+a tool for sandbox developers to use.  Beyond that, policy for logical
+behavior and information flow should be managed with a combination of
+other system hardening techniques and, potentially, an LSM of your
+choosing.  Expressive, dynamic filters provide further options down this
+path (avoiding pathological sizes or selecting which of the multiplexed
+system calls in socketcall() is allowed, for instance) which could be
+construed, incorrectly, as a more complete sandboxing solution.
+
+Usage
+-----
+
+An additional seccomp mode is added and is enabled using the same
+prctl(2) call as the strict seccomp.  If the architecture has
+CONFIG_HAVE_ARCH_SECCOMP_FILTER, then filters may be added as below:
+
+PR_SET_SECCOMP:
+        Now takes an additional argument which specifies a new filter
+        using a BPF program.
+        The BPF program will be executed over struct seccomp_data
+        reflecting the system call number, arguments, and other
+        metadata.  The BPF program must then return one of the
+        acceptable values to inform the kernel which action should be
+        taken.
+
+        Usage:
+                prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, prog);
+
+        The 'prog' argument is a pointer to a struct sock_fprog which
+        will contain the filter program.  If the program is invalid, the
+        call will return -1 and set errno to EINVAL.
+
+        If fork/clone and execve are allowed by @prog, any child
+        processes will be constrained to the same filters and system
+        call ABI as the parent.
+
+        Prior to use, the task must call prctl(PR_SET_NO_NEW_PRIVS, 1) or
+        run with CAP_SYS_ADMIN privileges in its namespace.  If these are not
+        true, -EACCES will be returned.  This requirement ensures that filter
+        programs cannot be applied to child processes with greater privileges
+        than the task that installed them.
+
+        Additionally, if prctl(2) is allowed by the attached filter,
+        additional filters may be layered on which will increase evaluation
+        time, but allow for further decreasing the attack surface during
+        execution of a process.
+
+The above call returns 0 on success and non-zero on error.
+
+Return values
+-------------
+A seccomp filter may return any of the following values. If multiple
+filters exist, the return value for the evaluation of a given system
+call will always use the highest precedent value. (For example,
+SECCOMP_RET_KILL will always take precedence.)
+
+In precedence order, they are:
+
+SECCOMP_RET_KILL:
+        Results in the task exiting immediately without executing the
+        system call.  The exit status of the task (status & 0x7f) will
+        be SIGSYS, not SIGKILL.
+
+SECCOMP_RET_TRAP:
+        Results in the kernel sending a SIGSYS signal to the triggering
+        task without executing the system call.  The kernel will
+        rollback the register state to just before the system call
+        entry such that a signal handler in the task will be able to
+        inspect the ucontext_t->uc_mcontext registers and emulate
+        system call success or failure upon return from the signal
+        handler.
+
+        The SECCOMP_RET_DATA portion of the return value will be passed
+        as si_errno.
+
+        SIGSYS triggered by seccomp will have a si_code of SYS_SECCOMP.
+
+SECCOMP_RET_ERRNO:
+        Results in the lower 16-bits of the return value being passed
+        to userland as the errno without executing the system call.
+
+SECCOMP_RET_TRACE:
+        When returned, this value will cause the kernel to attempt to
+        notify a ptrace()-based tracer prior to executing the system
+        call.  If there is no tracer present, -ENOSYS is returned to
+        userland and the system call is not executed.
+
+        A tracer will be notified if it requests PTRACE_O_TRACESECCOMP
+        using ptrace(PTRACE_SETOPTIONS).  The tracer will be notified
+        of a PTRACE_EVENT_SECCOMP and the SECCOMP_RET_DATA portion of
+        the BPF program return value will be available to the tracer
+        via PTRACE_GETEVENTMSG.
+
+SECCOMP_RET_ALLOW:
+        Results in the system call being executed.
+
+If multiple filters exist, the return value for the evaluation of a
+given system call will always use the highest precedent value.
+
+Precedence is only determined using the SECCOMP_RET_ACTION mask.  When
+multiple filters return values of the same precedence, only the
+SECCOMP_RET_DATA from the most recently installed filter will be
+returned.
+
+Pitfalls
+--------
+
+The biggest pitfall to avoid during use is filtering on system call
+number without checking the architecture value.  Why?  On any
+architecture that supports multiple system call invocation conventions,
+the system call numbers may vary based on the specific invocation.  If
+the numbers in the different calling conventions overlap, then checks in
+the filters may be abused.  Always check the arch value!
+
+Example
+-------
+
+The samples/seccomp/ directory contains both an x86-specific example
+and a more generic example of a higher level macro interface for BPF
+program generation.
+
+
+
+Adding architecture support
+-----------------------
+
+See arch/Kconfig for the authoritative requirements.  In general, if an
+architecture supports both ptrace_event and seccomp, it will be able to
+support seccomp filter with minor fixup: SIGSYS support and seccomp return
+value checking.  Then it must just add CONFIG_HAVE_ARCH_SECCOMP_FILTER
+to its arch-specific Kconfig.
diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 8fb1ba7fe7bf..4ba7db231cb2 100644
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
 Sergiu Iordache <sergiu@chromium.org>
 
-Updated: 8 August 2011
+Updated: 17 November 2011
 
 0. Introduction
 
@@ -30,6 +30,11 @@ variable while setting 0 in that variable dumps only the panics.
 The module uses a counter to record multiple dumps but the counter gets reset
 on restart (i.e. new dumps after the restart will overwrite old ones).
 
+Ramoops also supports software ECC protection of persistent memory regions.
+This might be useful when a hardware reset was used to bring the machine back
+to life (i.e. a watchdog triggered). In such cases, RAM may be somewhat
+corrupt, but usually it is restorable.
+
 2. Setting the parameters
 
 Setting the ramoops parameters can be done in 2 different manners:
@@ -38,7 +43,7 @@ Setting the ramoops parameters can be done in 2 different manners:
  2. Use a platform device and set the platform data. The parameters can then
  be set through that platform data. An example of doing that is:
 
-#include <linux/ramoops.h>
+#include <linux/pstore_ram.h>
 [...]
 
 static struct ramoops_platform_data ramoops_data = {
@@ -46,6 +51,7 @@ static struct ramoops_platform_data ramoops_data = {
         .mem_address            = <...>,
         .record_size            = <...>,
         .dump_oops              = <...>,
+        .ecc                    = <...>,
 };
 
 static struct platform_device ramoops_dev = {
@@ -71,6 +77,6 @@ timestamp and a new line. The dump then continues with the actual data.
 
 4. Reading the data
 
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the data, can
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for these
+files is "dmesg-ramoops-N", where N is the record number in memory. To delete
+a stored record from RAM, simply unlink the respective pstore file.
diff --git a/Documentation/scheduler/sched-design-CFS.txt b/Documentation/scheduler/sched-design-CFS.txt
index 91ecff07cede..d529e02d928d 100644
--- a/Documentation/scheduler/sched-design-CFS.txt
+++ b/Documentation/scheduler/sched-design-CFS.txt
@@ -130,7 +130,7 @@ CFS implements three scheduling policies:
     idle timer scheduler in order to avoid to get into priority
     inversion problems which would deadlock the machine.
 
-SCHED_FIFO/_RR are implemented in sched_rt.c and are as specified by
+SCHED_FIFO/_RR are implemented in sched/rt.c and are as specified by
 POSIX.
 
 The command chrt from util-linux-ng 2.13.1.1 can set all of these except
@@ -145,9 +145,9 @@ Classes," an extensible hierarchy of scheduler modules.  These modules
 encapsulate scheduling policy details and are handled by the scheduler core
 without the core code assuming too much about them.
 
-sched_fair.c implements the CFS scheduler described above.
+sched/fair.c implements the CFS scheduler described above.
 
-sched_rt.c implements SCHED_FIFO and SCHED_RR semantics, in a simpler way than
+sched/rt.c implements SCHED_FIFO and SCHED_RR semantics, in a simpler way than
 the previous vanilla scheduler did.  It uses 100 runqueues (for all 100 RT
 priority levels, instead of 140 in the previous scheduler) and it needs no
 expired array.
diff --git a/Documentation/scheduler/sched-domains.txt b/Documentation/scheduler/sched-domains.txt
index b7ee379b651b..443f0c76bab4 100644
--- a/Documentation/scheduler/sched-domains.txt
+++ b/Documentation/scheduler/sched-domains.txt
@@ -61,10 +61,6 @@ The implementor should read comments in include/linux/sched.h:
 struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an idea of
 the specifics and what to tune.
 
-For SMT, the architecture must define CONFIG_SCHED_SMT and provide a
-cpumask_t cpu_sibling_map[NR_CPUS], where cpu_sibling_map[i] is the mask of
-all "i"'s siblings as well as "i" itself.
-
 Architectures may retain the regular override the default SD_*_INIT flags
 while using the generic domain builder in kernel/sched.c if they wish to
 retain the traditional SMT->SMP->NUMA topology (or some subset of that). This
diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX
index b7dd6502bec5..9b0787f965e9 100644
--- a/Documentation/scsi/00-INDEX
+++ b/Documentation/scsi/00-INDEX
@@ -56,8 +56,6 @@ g_NCR5380.txt
         - info on driver for NCR5380 and NCR53c400 based adapters
 hptiop.txt
         - HIGHPOINT ROCKETRAID 3xxx RAID DRIVER
-ibmmca.txt
-        - info on driver for IBM adapters with MCA bus
 in2000.txt
         - info on in2000 driver
 libsas.txt
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas
index 83f8ea8b79eb..80441ab608e4 100644
--- a/Documentation/scsi/ChangeLog.megaraid_sas
+++ b/Documentation/scsi/ChangeLog.megaraid_sas
@@ -1,3 +1,11 @@
+Release Date    : Mon. Mar 19, 2012 17:00:00 PST 2012 -
+                        (emaild-id:megaraidlinux@lsi.com)
+                        Adam Radford
+Current Version : 00.00.06.15-rc1
+Old Version     : 00.00.06.14-rc1
+    1. Optimize HostMSIxVectors setting.
+    2. Add fpRead/WriteCapable, fpRead/WriteAcrossStripe checks.
+-------------------------------------------------------------------------------
 Release Date    : Fri. Jan 6, 2012 17:00:00 PST 2010 -
                         (emaild-id:megaraidlinux@lsi.com)
                         Adam Radford
diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt
deleted file mode 100644
index ac41a9fcac77..000000000000
--- a/Documentation/scsi/ibmmca.txt
+++ /dev/null
@@ -1,1402 +0,0 @@
-
-               -=< The IBM Microchannel SCSI-Subsystem >=-
-               
-                         for the IBM PS/2 series
-                 
-                   Low Level Software-Driver for Linux
-                 
-     Copyright (c) 1995 Strom Systems, Inc. under the terms of the GNU 
-  General Public License. Originally written by Martin Kolinek, December 1995.
-   Officially modified and maintained by Michael Lang since January 1999.
-           
-                               Version 4.0a
-        
-   Last update: January 3, 2001
-   
-   Before you Start
-   ----------------
-   This is the common README.ibmmca file for all driver releases of the 
-   IBM MCA SCSI driver for Linux. Please note, that driver releases 4.0
-   or newer do not work with kernel versions older than 2.4.0, while driver
-   versions older than 4.0 do not work with kernels 2.4.0 or later! If you
-   try to compile your kernel with the wrong driver source, the 
-   compilation is aborted and you get a corresponding error message. This is
-   no bug in the driver; it prevents you from using the wrong source code
-   with the wrong kernel version.
-
-   Authors of this Driver
-   ----------------------
-    - Chris Beauregard (improvement of the SCSI-device mapping by the driver)
-    - Martin Kolinek (origin, first release of this driver)
-    - Klaus Kudielka (multiple SCSI-host management/detection, adaption to
-                      Linux Kernel 2.1.x, module support)
-    - Michael Lang (assigning original pun/lun mapping, dynamical ldn
-                    assignment, rewritten adapter detection, this file, 
-                    patches, official driver maintenance and subsequent 
-                    debugging, related with the driver)
-
-   Table of Contents
-   -----------------
-   1 Abstract
-   2 Driver Description
-     2.1  IBM SCSI-Subsystem Detection
-     2.2  Physical Units, Logical Units, and Logical Devices
-     2.3  SCSI-Device Recognition and dynamical ldn Assignment
-     2.4  SCSI-Device Order
-     2.5  Regular SCSI-Command-Processing
-     2.6  Abort & Reset Commands
-     2.7  Disk Geometry
-     2.8  Kernel Boot Option
-     2.9  Driver Module Support
-     2.10 Multiple Hostadapter Support
-     2.11 /proc/scsi-Filesystem Information
-     2.12 /proc/mca-Filesystem Information
-     2.13 Supported IBM SCSI-Subsystems
-     2.14 Linux Kernel Versions
-   3 Code History
-   4 To do
-   5 Users' Manual
-     5.1 Commandline Parameters
-     5.2 Troubleshooting
-     5.3 Bug reports
-     5.4 Support WWW-page
-   6 References
-   7 Credits to
-     7.1 People
-     7.2 Sponsors & Supporters
-   8 Trademarks
-   9 Disclaimer
-
-                              * * *
-
-   1 Abstract
-   ----------
-   This README-file describes the IBM SCSI-subsystem low level driver for
-   Linux. The descriptions which were formerly kept in the source code have
-   been taken out of this file to simplify the codes readability. The driver
-   description has been updated, as most of the former description was already
-   quite outdated. The history of the driver development is also kept inside
-   here. Multiple historical developments have been summarized to shorten the
-   text size a bit. At the end of this file you can find a small manual for
-   this driver and hints to get it running on your machine.
-
-   2 Driver Description
-   --------------------
-   2.1 IBM SCSI-Subsystem Detection
-   --------------------------------
-   This is done in the ibmmca_detect() function. It first checks, if the
-   Microchannel-bus support is enabled, as the IBM SCSI-subsystem needs the
-   Microchannel. In a next step, a free interrupt is chosen and the main
-   interrupt handler is connected to it to handle answers of the SCSI-
-   subsystem(s). If the F/W SCSI-adapter is forced by the BIOS to use IRQ11
-   instead of IRQ14, IRQ11 is used for the IBM SCSI-2 F/W adapter. In a 
-   further step it is checked, if the adapter gets detected by force from
-   the kernel commandline, where the I/O port and the SCSI-subsystem id can 
-   be specified. The next step checks if there is an integrated SCSI-subsystem
-   installed. This register area is fixed through all IBM PS/2 MCA-machines 
-   and appears as something like a virtual slot 10 of the MCA-bus. On most
-   PS/2 machines, the POS registers of slot 10 are set to 0xff or 0x00 if not
-   integrated SCSI-controller is available. But on certain PS/2s, like model 
-   9595, this slot 10 is used to store other information which at earlier
-   stage confused the driver and resulted in the detection of some ghost-SCSI. 
-   If POS-register 2 and 3 are not 0x00 and not 0xff, but all other POS
-   registers are either 0xff or 0x00, there must be an integrated SCSI-
-   subsystem present and it will be registered as IBM Integrated SCSI-
-   Subsystem. The next step checks, if there is a slot-adapter installed on 
-   the MCA-bus. To get this, the first two POS-registers, that represent the 
-   adapter ID are checked. If they fit to one of the ids, stored in the 
-   adapter list, a SCSI-subsystem is assumed to be found in a slot and will be 
-   registered. This check is done through all possible MCA-bus slots to allow 
-   more than one SCSI-adapter to be present in the PS/2-system and this is 
-   already the first point of problems. Looking into the technical reference 
-   manual for the IBM PS/2 common interfaces, the POS2 register must have 
-   different interpretation of its single bits to avoid overlapping I/O
-   regions. While one can assume, that the integrated subsystem has a fix 
-   I/O-address at 0x3540 - 0x3547, further installed IBM SCSI-adapters must 
-   use a different I/O-address. This is expressed by bit 1 to 3 of POS2 
-   (multiplied by 8 + 0x3540). Bits 2 and 3 are reserved for the integrated 
-   subsystem, but not for the adapters! The following list shows, how the 
-   bits of POS2 and POS3 should be interpreted.
-   
-   The POS2-register of all PS/2 models' integrated SCSI-subsystems has the 
-   following interpretation of bits:
-                           Bit 7 - 4 : Chip Revision ID (Release)
-                           Bit 3 - 2 : Reserved
-                           Bit 1     : 8k NVRAM Disabled
-                           Bit 0     : Chip Enable (EN-Signal)
-   The POS3-register is interpreted as follows (for most IBM SCSI-subsys.):
-                           Bit 7 - 5 : SCSI ID
-                           Bit 4 - 0 : Reserved = 0
-   The slot-adapters have different interpretation of these bits. The IBM SCSI
-   adapter (w/Cache) and the IBM SCSI-2 F/W adapter use the following
-   interpretation of the POS2 register:
-                           Bit 7 - 4 : ROM Segment Address Select
-                           Bit 3 - 1 : Adapter I/O Address Select (*8+0x3540)
-                           Bit 0     : Adapter Enable (EN-Signal)
-   and for the POS3 register:
-                           Bit 7 - 5 : SCSI ID 
-                           Bit 4     : Fairness Enable (SCSI ID3 f. F/W)
-                           Bit 3 - 0 : Arbitration Level
-   The most modern product of the series is the IBM SCSI-2 F/W adapter, it 
-   allows dual-bus SCSI and SCSI-wide addressing, which means, PUNs may be
-   between 0 and 15. Here, Bit 4 is the high-order bit of the 4-bit wide
-   adapter PUN expression. In short words, this means, that IBM PS/2 machines 
-   can only support 1 single integrated subsystem by default. Additional
-   slot-adapters get ports assigned by the automatic configuration tool.
-
-   One day I found a patch in ibmmca_detect(), forcing the I/O-address to be 
-   0x3540 for integrated SCSI-subsystems, there was a remark placed, that on 
-   integrated IBM SCSI-subsystems of model 56, the POS2 register was showing 5.
-   This means, that really for these models, POS2 has to be interpreted
-   sticking to the technical reference guide. In this case, the bit 2 (4) is 
-   a reserved bit and may not be interpreted. These differences between the 
-   adapters and the integrated controllers are taken into account by the 
-   detection routine of the driver on from version >3.0g. 
-
-   Every time, a SCSI-subsystem is discovered, the ibmmca_register() function
-   is called. This function checks first, if the requested area for the I/O-
-   address of this SCSI-subsystem is still available and assigns this I/O-
-   area to the SCSI-subsystem. There are always 8 sequential I/O-addresses
-   taken for each individual SCSI-subsystem found, which are:
-   
-     Offset            Type                  Permissions
-       0     Command Interface Register 1    Read/Write
-       1     Command Interface Register 2    Read/Write
-       2     Command Interface Register 3    Read/Write
-       3     Command Interface Register 4    Read/Write
-       4     Attention Register              Read/Write
-       5     Basic Control Register          Read/Write
-       6     Interrupt Status Register       Read
-       7     Basic Status Register           Read
-   
-   After the I/O-address range is assigned, the host-adapter is assigned
-   to a local structure which keeps all adapter information needed for the
-   driver itself and the mid- and higher-level SCSI-drivers. The SCSI pun/lun
-   and the adapters' ldn tables are initialized and get probed afterwards by
-   the check_devices() function. If no further adapters are found, 
-   ibmmca_detect() quits.
-   
-   2.2 Physical Units, Logical Units, and Logical Devices
-   ------------------------------------------------------
-   There can be up to 56 devices on the SCSI bus (besides the adapter):
-   there are up to 7 "physical units" (each identified by physical unit 
-   number or pun, also called the scsi id, this is the number you select
-   with hardware jumpers), and each physical unit can have up to 8 
-   "logical units" (each identified by logical unit number, or lun, 
-   between 0 and 7). The IBM SCSI-2 F/W adapter offers this on up to two
-   busses and provides support for 30 logical devices at the same time, where
-   in wide-addressing mode you can have 16 puns with 32 luns on each device.
-   This section describes the handling of devices on non-F/W adapters.
-   Just imagine, that you can have 16 * 32 = 512 devices on a F/W adapter
-   which means a lot of possible devices for such a small machine.
-
-   Typically the adapter has pun=7, so puns of other physical units
-   are between 0 and 6(15). On a wide-adapter a pun higher than 7 is
-   possible, but is normally not used. Almost all physical units have only 
-   one logical unit, with lun=0. A CD-ROM jukebox would be an example of a 
-   physical unit with more than one logical unit.
-
-   The embedded microprocessor of the IBM SCSI-subsystem hides the complex
-   two-dimensional (pun,lun) organization from the operating system.
-   When the machine is powered-up (or rebooted), the embedded microprocessor 
-   checks, on its own, all 56 possible (pun,lun) combinations, and the first 
-   15 devices found are assigned into a one-dimensional array of so-called 
-   "logical devices", identified by "logical device numbers" or ldn. The last 
-   ldn=15 is reserved for the subsystem itself. Wide adapters may have 
-   to check up to 15 * 8 = 120 pun/lun combinations.
-   
-   2.3 SCSI-Device Recognition and Dynamical ldn Assignment
-   --------------------------------------------------------
-   One consequence of information hiding is that the real (pun,lun)    
-   numbers are also hidden. The two possibilities to get around this problem
-   are to offer fake pun/lun combinations to the operating system or to 
-   delete the whole mapping of the adapter and to reassign the ldns, using
-   the immediate assign command of the SCSI-subsystem for probing through
-   all possible pun/lun combinations.  An ldn is a "logical device number"
-   which is used by IBM SCSI-subsystems to access some valid SCSI-device.
-   At the beginning of the development of this driver, the following approach 
-   was used:
-   
-   First, the driver checked the ldn's (0 to 6) to find out which ldn's
-   have devices assigned. This was done by the functions check_devices() and
-   device_exists(). The interrupt handler has a special paragraph of code
-   (see local_checking_phase_flag) to assist in the checking. Assume, for
-   example, that three logical devices were found assigned at ldn 0, 1, 2.
-   These are presented to the upper layer of Linux SCSI driver
-   as devices with bogus (pun, lun) equal to (0,0), (1,0), (2,0). 
-   On the other hand, if the upper layer issues a command to device
-   say (4,0), this driver returns DID_NO_CONNECT error.
-
-   In a second step of the driver development, the following improvement has
-   been applied: The first approach limited the number of devices to 7, far
-   fewer than the 15 that it could use, then it just mapped ldn -> 
-   (ldn/8,ldn%8) for pun,lun.  We ended up with a real mishmash of puns
-   and luns, but it all seemed to work.
-
-   The latest development, which is implemented from the driver version 3.0
-   and later, realizes the device recognition in the following way:
-   The physical SCSI-devices on the SCSI-bus are probed via immediate_assign- 
-   and device_inquiry-commands, that is all implemented in a completely new
-   made check_devices() subroutine. This delivers an exact map of the physical
-   SCSI-world that is now stored in the get_scsi[][]-array. This means,
-   that the once hidden pun,lun assignment is now known to this driver.
-   It no longer believes in default-settings of the subsystem and maps all
-   ldns to existing pun,lun "by foot". This assures full control of the ldn
-   mapping and allows dynamical remapping of ldns to different pun,lun, if
-   there are more SCSI-devices installed than ldns available (n>15). The
-   ldns from 0 to 6 get 'hardwired' by this driver to puns 0 to 7 at lun=0,
-   excluding the pun of the subsystem. This assures, that at least simple 
-   SCSI-installations have optimum access-speed and are not touched by
-   dynamical remapping. The ldns 7 to 14 are put to existing devices with 
-   lun>0 or to non-existing devices, in order to satisfy the subsystem, if 
-   there are less than 15 SCSI-devices connected. In the case of more than 15 
-   devices, the dynamical mapping goes active. If the get_scsi[][] reports a 
-   device to be existent, but it has no ldn assigned, it gets an ldn out of 7
-   to 14. The numbers are assigned in cyclic order, therefore it takes 8 
-   dynamical reassignments on the SCSI-devices until a certain device 
-   loses its ldn again. This assures that dynamical remapping is avoided 
-   during intense I/O between up to 15 SCSI-devices (means pun,lun 
-   combinations). A further advantage of this method is that people who
-   build their kernel without probing on all luns will get what they expect,
-   because the driver just won't assign everything with lun>0 when 
-   multiple lun probing is inactive.
- 
-   2.4 SCSI-Device Order
-   ---------------------
-   Because of the now correct recognition of physical pun,lun, and 
-   their report to mid-level- and higher-level-drivers, the new reported puns
-   can be different from the old, faked puns. Therefore, Linux will eventually
-   change /dev/sdXXX assignments and prompt you for corrupted superblock
-   repair on boottime. In this case DO NOT PANIC, YOUR DISKS ARE STILL OK!!!
-   You have to reboot (CTRL-D) with an old kernel and set the /etc/fstab-file
-   entries right. After that, the system should come up as errorfree as before.
-   If your boot-partition is not coming up, also edit the /etc/lilo.conf-file
-   in a Linux session booted on old kernel and run lilo before reboot. Check
-   lilo.conf anyway to get boot on other partitions with foreign OSes right
-   again. But there exists a feature of this driver that allows you to change
-   the assignment order of the SCSI-devices by flipping the PUN-assignment.
-   See the next paragraph for a description.
- 
-   The problem for this is, that Linux does not assign the SCSI-devices in the
-   way as described in the ANSI-SCSI-standard. Linux assigns /dev/sda to 
-   the device with at minimum id 0. But the first drive should be at id 6,
-   because for historical reasons, drive at id 6 has, by hardware, the highest
-   priority and a drive at id 0 the lowest. IBM was one of the rare producers,
-   where the BIOS assigns drives belonging to the ANSI-SCSI-standard. Most 
-   other producers' BIOS does not (I think even Adaptec-BIOS). The 
-   IBMMCA_SCSI_ORDER_STANDARD flag, which you set while configuring the
-   kernel enables to choose the preferred way of SCSI-device-assignment. 
-   Defining this flag would result in Linux determining the devices in the 
-   same order as DOS and OS/2 does on your MCA-machine. This is also standard 
-   on most industrial computers and OSes, like e.g. OS-9. Leaving this flag 
-   undefined will get your devices ordered in the default way of Linux. See 
-   also the remarks of Chris Beauregard from Dec 15, 1997 and the followups 
-   in section 3.
-   
-   2.5 Regular SCSI-Command-Processing
-   -----------------------------------
-   Only three functions get involved: ibmmca_queuecommand(), issue_cmd(),
-   and interrupt_handler().
-
-   The upper layer issues a scsi command by calling function 
-   ibmmca_queuecommand(). This function fills a "subsystem control block"
-   (scb) and calls a local function issue_cmd(), which writes a scb 
-   command into subsystem I/O ports. Once the scb command is carried out, 
-   the interrupt_handler() is invoked. If a device is determined to be 
-   existent and it has not assigned any ldn, it gets one dynamically.
-   For this, the whole stuff is done in ibmmca_queuecommand().
-
-   2.6 Abort & Reset Commands
-   --------------------------
-   These are implemented with busy waiting for interrupt to arrive.
-   ibmmca_reset() and ibmmca_abort() do not work sufficiently well
-   up to now and need still a lot of development work. This seems
-   to be a problem with other low-level SCSI drivers too, however
-   this should be no excuse.
-
-   2.7 Disk Geometry
-   -----------------
-   The ibmmca_biosparams() function should return the same disk geometry 
-   as the bios. This is needed for fdisk, etc. The returned geometry is 
-   certainly correct for disks smaller than 1 gigabyte. In the meantime,
-   it has been proved, that this works fine even with disks larger than
-   1 gigabyte.
-
-   2.8 Kernel Boot Option
-   ----------------------
-   The function ibmmca_scsi_setup() is called if option ibmmcascsi=n 
-   is passed to the kernel. See file linux/init/main.c for details.
-   
-   2.9 Driver Module Support
-   -------------------------
-   Is implemented and tested by K. Kudielka. This could probably not work
-   on kernels <2.1.0.
-  
-   2.10 Multiple Hostadapter Support
-   ---------------------------------
-   This driver supports up to eight interfaces of type IBM-SCSI-Subsystem. 
-   Integrated-, and MCA-adapters are automatically recognized. Unrecognizable
-   IBM-SCSI-Subsystem interfaces can be specified as kernel-parameters.
- 
-   2.11 /proc/scsi-Filesystem Information
-   --------------------------------------
-   Information about the driver condition is given in 
-   /proc/scsi/ibmmca/<host_no>. ibmmca_proc_info() provides this information.
-   
-   This table is quite informative for interested users. It shows the load
-   of commands on the subsystem and whether you are running the bypassed
-   (software) or integrated (hardware) SCSI-command set (see below). The
-   amount of accesses is shown. Read, write, modeselect is shown separately
-   in order to help debugging problems with CD-ROMs or tapedrives.
-   
-   The following table shows the list of 15 logical device numbers, that are
-   used by the SCSI-subsystem. The load on each ldn is shown in the table,
-   again, read and write commands are split. The last column shows the amount
-   of reassignments, that have been applied to the ldns, if you have more than
-   15 pun/lun combinations available on the SCSI-bus.
-   
-   The last two tables show the pun/lun map and the positions of the ldns
-   on this pun/lun map. This may change during operation, when a ldn is
-   reassigned to another pun/lun combination. If the necessity for dynamical
-   assignments is set to 'no', the ldn structure keeps static.
-   
-   2.12 /proc/mca-Filesystem Information
-   -------------------------------------
-   The slot-file contains all default entries and in addition chip and I/O-
-   address information of the SCSI-subsystem. This information is provided
-   by ibmmca_getinfo().
-   
-   2.13 Supported IBM SCSI-Subsystems
-   ----------------------------------
-   The following IBM SCSI-subsystems are supported by this driver:
-   
-     - IBM Fast/Wide SCSI-2 Adapter
-     - IBM 7568 Industrial Computer SCSI Adapter w/Cache
-     - IBM Expansion Unit SCSI Controller
-     - IBM SCSI Adapter w/Cache
-     - IBM SCSI Adapter
-     - IBM Integrated SCSI Controller
-     - All clones, 100% compatible with the chipset and subsystem command
-       system of IBM SCSI-adapters (forced detection)
-     
-   2.14 Linux Kernel Versions
-   --------------------------
-   The IBM SCSI-subsystem low level driver is prepared to be used with
-   all versions of Linux between 2.0.x and 2.4.x. The compatibility checks
-   are fully implemented up from version 3.1e of the driver. This means, that
-   you just need the latest ibmmca.h and ibmmca.c file and copy it in the
-   linux/drivers/scsi directory. The code is automatically adapted during 
-   kernel compilation. This is different from kernel 2.4.0! Here version 
-   4.0 or later of the driver must be used for kernel 2.4.0 or later. Version
-   4.0 or later does not work together with older kernels! Driver versions
-   older than 4.0 do not work together with kernel 2.4.0 or later. They work
-   on all older kernels.
-
-   3 Code History
-   --------------
-   Jan 15 1996:  First public release.
-   - Martin Kolinek
-
-   Jan 23 1996:  Scrapped code which reassigned scsi devices to logical
-   device numbers. Instead, the existing assignment (created
-   when the machine is powered-up or rebooted) is used. 
-   A side effect is that the upper layer of Linux SCSI 
-   device driver gets bogus scsi ids (this is benign), 
-   and also the hard disks are ordered under Linux the 
-   same way as they are under dos (i.e., C: disk is sda, 
-   D: disk is sdb, etc.).
-   - Martin Kolinek
-
-   I think that the CD-ROM is now detected only if a CD is 
-   inside CD_ROM while Linux boots. This can be fixed later,
-   once the driver works on all types of PS/2's.
-   - Martin Kolinek
-
-   Feb 7 1996:   Modified biosparam function. Fixed the CD-ROM detection. 
-   For now, devices other than harddisk and CD_ROM are 
-   ignored. Temporarily modified abort() function 
-   to behave like reset().
-   - Martin Kolinek
-
-   Mar 31 1996:  The integrated scsi subsystem is correctly found
-   in PS/2 models 56,57, but not in model 76. Therefore
-   the ibmmca_scsi_setup() function has been added today.
-   This function allows the user to force detection of
-   scsi subsystem. The kernel option has format
-   ibmmcascsi=n
-   where n is the scsi_id (pun) of the subsystem. Most likely, n is 7.
-   - Martin Kolinek
-
-   Aug 21 1996:  Modified the code which maps ldns to (pun,0).  It was
-   insufficient for those of us with CD-ROM changers.
-   - Chris Beauregard
- 
-   Dec 14 1996: More improvements to the ldn mapping.  See check_devices
-   for details.  Did more fiddling with the integrated SCSI detection,
-   but I think it's ultimately hopeless without actually testing the
-   model of the machine.  The 56, 57, 76 and 95 (ultimedia) all have
-   different integrated SCSI register configurations.  However, the 56
-   and 57 are the only ones that have problems with forced detection.
-   - Chris Beauregard
- 
-   Mar 8-16 1997: Modified driver to run as a module and to support 
-   multiple adapters. A structure, called ibmmca_hostdata, is now
-   present, containing all the variables, that were once only
-   available for one single adapter. The find_subsystem-routine has vanished.
-   The hardware recognition is now done in ibmmca_detect directly.
-   This routine checks for presence of MCA-bus, checks the interrupt
-   level and continues with checking the installed hardware.
-   Certain PS/2-models do not recognize a SCSI-subsystem automatically.
-   Hence, the setup defined by command-line-parameters is checked first.
-   Thereafter, the routine probes for an integrated SCSI-subsystem.
-   Finally, adapters are checked. This method has the advantage to cover all
-   possible combinations of multiple SCSI-subsystems on one MCA-board. Up to
-   eight SCSI-subsystems can be recognized and announced to the upper-level
-   drivers with this improvement. A set of defines made changes to other
-   routines as small as possible.
-   - Klaus Kudielka
-   
-   May 30 1997: (v1.5b)
-   1) SCSI-command capability enlarged by the recognition of MODE_SELECT.
-      This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which 
-      allows data to be written from the system to the device. It is a
-      necessary step to be allowed to set blocksize of SCSI-tape-drives and 
-      the tape-speed, without confusing the SCSI-Subsystem.
-   2) The recognition of a tape is included in the check_devices routine.
-      This is done by checking for TYPE_TAPE, that is already defined in
-      the kernel-scsi-environment. The markup of a tape is done in the 
-      global ldn_is_tape[] array. If the entry on index ldn 
-      is 1, there is a tapedrive connected.
-   3) The ldn_is_tape[] array is necessary to distinguish between tape- and 
-      other devices. Fixed blocklength devices should not cause a problem
-      with the SCB-command for read and write in the ibmmca_queuecommand
-      subroutine. Therefore, I only derivate the READ_XX, WRITE_XX for
-      the tape-devices, as recommended by IBM in this Technical Reference,
-      mentioned below. (IBM recommends to avoid using the read/write of the
-      subsystem, but the fact was, that read/write causes a command error from
-      the subsystem and this causes kernel-panic.)
-   4) In addition, I propose to use the ldn instead of a fix char for the
-      display of PS2_DISK_LED_ON(). On 95, one can distinguish between the
-      devices that are accessed. It shows activity and easyfies debugging.   
-   The tape-support has been tested with a SONY SDT-5200 and a HP DDS-2
-   (I do not know yet the type). Optimization and CD-ROM audio-support, 
-   I am working on ...
-   - Michael Lang
-   
-   June 19 1997: (v1.6b)
-   1) Submitting the extra-array ldn_is_tape[] -> to the local ld[]
-      device-array. 
-   2) CD-ROM Audio-Play seems to work now.
-   3) When using DDS-2 (120M) DAT-Tapes, mtst shows still density-code
-      0x13 for ordinary DDS (61000 BPM) instead 0x24 for DDS-2. This appears 
-      also on Adaptec 2940 adaptor in a PCI-System. Therefore, I assume that 
-      the problem is independent of the low-level-driver/bus-architecture.
-   4) Hexadecimal ldn on PS/2-95 LED-display.
-   5) Fixing of the PS/2-LED on/off that it works right with tapedrives and
-      does not confuse the disk_rw_in_progress counter.
-   - Michael Lang
-  
-   June 21 1997: (v1.7b)
-   1) Adding of a proc_info routine to inform in /proc/scsi/ibmmca/<host> the
-      outer-world about operational load statistics on the different ldns,
-      seen by the driver. Everybody that has more than one IBM-SCSI should
-      test this, because I only have one and cannot see what happens with more
-      than one IBM-SCSI hosts.
-   2) Definition of a driver version-number to have a better recognition of 
-      the source when there are existing too much releases that may confuse
-      the user, when reading about release-specific problems. Up to know,
-      I calculated the version-number to be 1.7. Because we are in BETA-test
-      yet, it is today 1.7b.
-   3) Sorry for the heavy bug I programmed on June 19 1997! After that, the
-      CD-ROM did not work any more! The C7-command was a fake impression
-      I got while programming. Now, the READ and WRITE commands for CD-ROM are
-      no longer running over the subsystem, but just over 
-      IM_OTHER_SCSI_CMD_CMD. On my observations (PS/2-95), now CD-ROM mounts
-      much faster(!) and hopefully all fancy multimedia-functions, like direct
-      digital recording from audio-CDs also work. (I tried it with cdda2wav
-      from the cdwtools-package and it filled up the harddisk immediately :-).)
-      To easify boolean logics, a further local device-type in ld[], called
-      is_cdrom has been included.
-   4) If one uses a SCSI-device of unsupported type/commands, one
-      immediately runs into a kernel-panic caused by Command Error. To better
-      understand which SCSI-command caused the problem, I extended this
-      specific panic-message slightly.
-   - Michael Lang
- 
-   June 25 1997: (v1.8b)
-   1) Some cosmetic changes for the handling of SCSI-device-types.
-      Now, also CD-Burners / WORMs and SCSI-scanners should work. For
-      MO-drives I have no experience, therefore not yet supported.
-      In logical_devices I changed from different type-variables to one
-      called 'device_type' where the values, corresponding to scsi.h,
-      of a SCSI-device are stored.
-   2) There existed a small bug, that maps a device, coming after a SCSI-tape
-      wrong. Therefore, e.g. a CD-ROM changer would have been mapped wrong
-      -> problem removed.
-   3) Extension of the logical_device structure. Now it contains also device,
-      vendor and revision-level of a SCSI-device for internal usage.
-   - Michael Lang
-
-   June 26-29 1997: (v2.0b)
-   1) The release number 2.0b is necessary because of the completely new done
-      recognition and handling of SCSI-devices with the adapter. As I got
-      from Chris the hint, that the subsystem can reassign ldns dynamically,
-      I remembered this immediate_assign-command, I found once in the handbook.
-      Now, the driver first kills all ldn assignments that are set by default
-      on the SCSI-subsystem. After that, it probes on all puns and luns for
-      devices by going through all combinations with immediate_assign and
-      probing for devices, using device_inquiry. The found physical(!) pun,lun
-      structure is stored in get_scsi[][] as device types. This is followed
-      by the assignment of all ldns to existing SCSI-devices. If more ldns
-      than devices are available, they are assigned to non existing pun,lun
-      combinations to satisfy the adapter. With this, the dynamical mapping
-      was possible to implement. (For further info see the text in the 
-      source code and in the description below. Read the description
-      below BEFORE installing this driver on your system!)
-   2) Changed the name IBMMCA_DRIVER_VERSION to IBMMCA_SCSI_DRIVER_VERSION.
-   3) The LED-display shows on PS/2-95 no longer the ldn, but the SCSI-ID
-      (pun) of the accessed SCSI-device. This is now senseful, because the 
-      pun known within the driver is exactly the pun of the physical device
-      and no longer a fake one.
-   4) The /proc/scsi/ibmmca/<host_no> consists now of the first part, where
-      hit-statistics of ldns is shown and a second part, where the maps of 
-      physical and logical SCSI-devices are displayed. This could be very 
-      interesting, when one is using more than 15 SCSI-devices in order to 
-      follow the dynamical remapping of ldns.
-   - Michael Lang
- 
-   June 26-29 1997: (v2.0b-1)
-   1) I forgot to switch the local_checking_phase_flag to 1 and back to 0
-      in the dynamical remapping part in ibmmca_queuecommand for the 
-      device_exist routine. Sorry.
-   - Michael Lang
- 
-   July 1-13 1997: (v3.0b,c)
-   1) Merging of the driver-developments of Klaus Kudielka and Michael Lang 
-      in order to get a optimum and unified driver-release for the 
-      IBM-SCSI-Subsystem-Adapter(s).
-         For people, using the Kernel-release >=2.1.0, module-support should 
-      be no problem. For users, running under <2.1.0, module-support may not 
-      work, because the methods have changed between 2.0.x and 2.1.x.
-   2) Added some more effective statistics for /proc-output.
-   3) Change typecasting at necessary points from (unsigned long) to
-      virt_to_bus().
-   4) Included #if... at special points to have specific adaption of the
-      driver to kernel 2.0.x and 2.1.x. It should therefore also run with 
-      later releases.
-   5) Magneto-Optical drives and medium-changers are also recognized, now.
-      Therefore, we have a completely gapfree recognition of all SCSI-
-      device-types, that are known by Linux up to kernel 2.1.31.
-   6) The flag SCSI_IBMMCA_DEV_RESET has been inserted. If it is set within
-      the configuration, each connected SCSI-device will get a reset command
-      during boottime. This can be necessary for some special SCSI-devices.
-      This flag should be included in Config.in.
-      (See also the new Config.in file.)
-   Probable next improvement: bad disk handler.
-   - Michael Lang
- 
-   Sept 14 1997: (v3.0c)
-   1) Some debugging and speed optimization applied.
-   - Michael Lang
-
-   Dec 15, 1997
-    - chrisb@truespectra.com
-    - made the front panel display thingy optional, specified from the
-    command-line via ibmmcascsi=display.  Along the lines of the /LED
-    option for the OS/2 driver.
-    - fixed small bug in the LED display that would hang some machines.
-    - reversed ordering of the drives (using the
-    IBMMCA_SCSI_ORDER_STANDARD define).  This is necessary for two main
-    reasons:
-        - users who've already installed Linux won't be screwed.  Keep
-        in mind that not everyone is a kernel hacker.
-        - be consistent with the BIOS ordering of the drives.  In the
-        BIOS, id 6 is C:, id 0 might be D:.  With this scheme, they'd be
-        backwards.  This confuses the crap out of those heathens who've
-        got a impure Linux installation (which, <wince>, I'm one of).
-    This whole problem arises because IBM is actually non-standard with
-    the id to BIOS mappings.  You'll find, in fdomain.c, a similar
-    comment about a few FD BIOS revisions.  The Linux (and apparently
-    industry) standard is that C: maps to scsi id (0,0).  Let's stick
-    with that standard.
-    - Since this is technically a branch of my own, I changed the
-    version number to 3.0e-cpb.
-
-   Jan 17, 1998: (v3.0f)
-   1) Addition of some statistical info for /proc in proc_info.
-   2) Taking care of the SCSI-assignment problem, dealed by Chris at Dec 15
-      1997. In fact, IBM is right, concerning the assignment of SCSI-devices 
-      to driveletters. It is conform to the ANSI-definition of the SCSI-
-      standard to assign drive C: to SCSI-id 6, because it is the highest
-      hardware priority after the hostadapter (that has still today by
-      default everywhere id 7). Also realtime-operating systems that I use, 
-      like LynxOS and OS9, which are quite industrial systems use top-down
-      numbering of the harddisks, that is also starting at id 6. Now, one
-      sits a bit between two chairs. On one hand side, using the define
-      IBMMCA_SCSI_ORDER_STANDARD makes Linux assigning disks conform to
-      the IBM- and ANSI-SCSI-standard and keeps this driver downward
-      compatible to older releases, on the other hand side, people is quite
-      habituated in believing that C: is assigned to (0,0) and much other
-      SCSI-BIOS do so. Therefore, I moved the IBMMCA_SCSI_ORDER_STANDARD 
-      define out of the driver and put it into Config.in as subitem of 
-      'IBM SCSI support'. A help, added to Documentation/Configure.help 
-      explains the differences between saying 'y' or 'n' to the user, when 
-      IBMMCA_SCSI_ORDER_STANDARD prompts, so the ordinary user is enabled to 
-      choose the way of assignment, depending on his own situation and gusto.
-   3) Adapted SCSI_IBMMCA_DEV_RESET to the local naming convention, so it is
-      now called IBMMCA_SCSI_DEV_RESET.
-   4) Optimization of proc_info and its subroutines.
-   5) Added more in-source-comments and extended the driver description by
-      some explanation about the SCSI-device-assignment problem.
-   - Michael Lang
-   
-   Jan 18, 1998: (v3.0g)
-   1) Correcting names to be absolutely conform to the later 2.1.x releases.
-      This is necessary for 
-            IBMMCA_SCSI_DEV_RESET -> CONFIG_IBMMCA_SCSI_DEV_RESET
-            IBMMCA_SCSI_ORDER_STANDARD -> CONFIG_IBMMCA_SCSI_ORDER_STANDARD
-   - Michael Lang
- 
-   Jan 18, 1999: (v3.1 MCA-team internal)
-   1) The multiple hosts structure is accessed from every subroutine, so there
-      is no longer the address of the device structure passed from function
-      to function, but only the hostindex. A call by value, nothing more. This
-      should really be understood by the compiler and the subsystem should get
-      the right values and addresses.
-   2) The SCSI-subsystem detection was not complete and quite hugely buggy up
-      to now, compared to the technical manual. The interpretation of the pos2
-      register is not as assumed by people before, therefore, I dropped a note
-      in the ibmmca_detect function to show the registers' interpretation.
-      The pos-registers of integrated SCSI-subsystems do not contain any 
-      information concerning the IO-port offset, really. Instead, they contain
-      some info about the adapter, the chip, the NVRAM .... The I/O-port is
-      fixed to 0x3540 - 0x3547. There can be more than one adapters in the 
-      slots and they get an offset for the I/O area in order to get their own
-      I/O-address area. See chapter 2 for detailed description. At least, the 
-      detection should now work right, even on models other than 95. The 95ers
-      came happily around the bug, as their pos2 register contains always 0 
-      in the critical area. Reserved bits are not allowed to be interpreted, 
-      therefore, IBM is allowed to set those bits as they like and they may 
-      really vary between different PS/2 models. So, now, no interpretation 
-      of reserved bits - hopefully no trouble here anymore.
-   3) The command error, which you may get on models 55, 56, 57, 70, 77 and
-      P70 may have been caused by the fact, that adapters of older design do
-      not like sending commands to non-existing SCSI-devices and will react
-      with a command error as a sign of protest. While this error is not
-      present on IBM SCSI Adapter w/cache, it appears on IBM Integrated SCSI
-      Adapters. Therefore, I implemented a workaround to forgive those 
-      adapters their protests, but it is marked up in the statistics, so
-      after a successful boot, you can see in /proc/scsi/ibmmca/<host_number>
-      how often the command errors have been forgiven to the SCSI-subsystem.
-      If the number is bigger than 0, you have a SCSI subsystem of older
-      design, what should no longer matter.
-   4) ibmmca_getinfo() has been adapted very carefully, so it shows in the 
-      slotn file really, what is senseful to be presented.
-   5) ibmmca_register() has been extended in its parameter list in order to
-      pass the right name of the SCSI-adapter to Linux.
-   - Michael Lang
-
-   Feb 6, 1999: (v3.1)
-   1) Finally, after some 3.1Beta-releases, the 3.1 release. Sorry, for 
-      the delayed release, but it was not finished with the release of 
-      Kernel 2.2.0.
-   - Michael Lang
-   
-   Feb 10, 1999 (v3.1)
-   1) Added a new commandline parameter called 'bypass' in order to bypass
-      every integrated subsystem SCSI-command consequently in case of
-      troubles.
-   2) Concatenated read_capacity requests to the harddisks. It gave a lot
-      of troubles with some controllers and after I wanted to apply some
-      extensions, it jumped out in the same situation, on my w/cache, as like 
-      on D. Weinehalls' Model 56, having integrated SCSI. This gave me the 
-      decisive hint to move the code-part out and declare it global. Now
-      it seems to work far better and more stable. Let us see what
-      the world thinks of it...
-   3) By the way, only Sony DAT-drives seem to show density code 0x13. A
-      test with a HP drive gave right results, so the problem is vendor-
-      specific and not a problem of the OS or the driver.
-   - Michael Lang
-   
-   Feb 18, 1999 (v3.1d)
-   1) The abort command and the reset function have been checked for 
-      inconsistencies. From the logical point of thinking, they work
-      at their optimum, now, but as the subsystem does not answer with an
-      interrupt, abort never finishes, sigh...
-   2) Everything, that is accessed by a busmaster request from the adapter
-      is now declared as global variable, even the return-buffer in the
-      local checking phase. This assures, that no accesses to undefined memory
-      areas are performed.
-   3) In ibmmca.h, the line unchecked_isa_dma is added with 1 in order to
-      avoid memory-pointers for the areas higher than 16MByte in order to
-      be sure, it also works on 16-Bit Microchannel bus systems.
-   4) A lot of small things have been found, but nothing that endangered the
-      driver operations. Just it should be more stable, now.
-   - Michael Lang
-      
-   Feb 20, 1999 (v3.1e)
-   1) I took the warning from the Linux Kernel Hackers Guide serious and 
-      checked the cmd->result return value to the done-function very carefully.
-      It is obvious, that the IBM SCSI only delivers the tsb.dev_status, if
-      some error appeared, else it is undefined. Now, this is fixed. Before
-      any SCB command gets queued, the tsb.dev_status is set to 0, so the 
-      cmd->result won't screw up Linux higher level drivers.
-   2) The reset-function has slightly improved. This is still planned for 
-      abort. During the abort and the reset function, no interrupts are 
-      allowed. This is however quite hard to cope with, so the INT-status
-      register is read. When the interrupt gets queued, one can find its
-      status immediately on that register and is enabled to continue in the
-      reset function. I had no chance to test this really, only in a bogus 
-      situation, I got this function running, but the situation was too much
-      worse for Linux :-(, so tests will continue.
-   3) Buffers got now consistent. No open address mapping, as before and
-      therefore no further troubles with the unassigned memory segmentation
-      faults that scrambled probes on 95XX series and even on 85XX series,
-      when the kernel is done in a not so perfectly fitting way.
-   4) Spontaneous interrupts from the subsystem, appearing without any
-      command previously queued are answered with a DID_BAD_INTR result.
-   5) Taken into account ZP Gus' proposals to reverse the SCSI-device
-      scan order. As it does not work on Kernel 2.1.x or 2.2.x, as proposed
-      by him, I implemented it in a slightly derived way, which offers in 
-      addition more flexibility.
-   - Michael Lang
-
-   Apr 23, 2000 (v3.2pre1)
-   1) During a very long time, I collected a huge amount of bug reports from
-      various people, trying really quite different things on their SCSI-
-      PS/2s. Today, all these bug reports are taken into account and should be
-      mostly solved. The major topics were:
-      - Driver crashes during boottime by no obvious reason.
-      - Driver panics while the midlevel-SCSI-driver is trying to inquire
-        the SCSI-device properties, even though hardware is in perfect state.
-      - Displayed info for the various slot-cards is interpreted wrong.
-      The main reasons for the crashes were two:
-      1) The commands to check for device information like INQUIRY, 
-         TEST_UNIT_READY, REQUEST_SENSE and MODE_SENSE cause the devices
-         to deliver information of up to 255 bytes. Midlevel drivers offer
-         1024 bytes of space for the answer, but the IBM-SCSI-adapters do
-         not accept this, as they stick quite near to ANSI-SCSI and report
-         a COMMAND_ERROR message which causes the driver to panic. The main
-         problem was located around the INQUIRY command. Now, for all the
-         mentioned commands, the buffersize sent to the adapter is at 
-         maximum 255 which seems to be a quite reasonable solution. 
-         TEST_UNIT_READY gets a buffersize of 0 to make sure that no 
-         data is transferred in order to avoid any possible command failure.
-      2) On unsuccessful TEST_UNIT_READY, the mid-level driver has to send
-         a REQUEST_SENSE in order to see where the problem is located. This
-         REQUEST_SENSE may have various length in its answer-buffer. IBM
-         SCSI-subsystems report a command failure if the returned buffersize
-         is different from the sent buffersize, but this can be suppressed by
-         a special bit, which is now done and problems seem to be solved.
-   2) Code adaption to all kernel-releases. Now, the 3.2 code compiles on 
-      2.0.x, 2.1.x, 2.2.x and 2.3.x kernel releases without any code-changes.
-   3) Commandline-parameters are recognized again, even under Kernel 2.3.x or
-      higher.
-   - Michael Lang   
-
-   April 27, 2000 (v3.2pre2)
-   1) Bypassed commands get read by the adapter by one cycle instead of two.
-      This increases SCSI-performance.
-   2) Synchronous datatransfer is provided for sure to be 5 MHz on older
-      SCSI and 10 MHz on internal F/W SCSI-adapter.
-   3) New commandline parameters allow to force the adapter to slow down while
-      in synchronous transfer. Could be helpful for very old devices.
-   - Michael Lang
-   
-   June 2, 2000 (v3.2pre5)
-   1) Added Jim Shorney's contribution to make the activity indicator
-      flashing in addition to the LED-alphanumeric display-panel on
-      models 95A. To be enabled to choose this feature freely, a new
-      commandline parameter is added, called 'activity'.
-   2) Added the READ_CONTROL bit for test_unit_ready SCSI-command.
-   3) Added some suppress_exception bits to read_device_capacity and
-      all device_inquiry occurrences in the driver code.
-   4) Complaints about the various KERNEL_VERSION implementations are
-      taken into account. Every local_LinuxKernelVersion occurrence is
-      now replaced by KERNEL_VERSION, defined in linux/version.h. 
-      Corresponding changes were applied to ibmmca.h, too. This was a
-      contribution to all kernel-parts by Philipp Hahn.
-   - Michael Lang
-   
-   July 17, 2000 (v3.2pre8)
-   A long period of collecting bug reports from all corners of the world
-   now lead to the following corrections to the code:
-   1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this 
-      was that it is possible to disable Fast-SCSI for the external bus.
-      The feature-control command, where this crash appeared regularly, tried
-      to set the maximum speed of 10MHz synchronous transfer speed and that
-      reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now,
-      the feature-command probes down from maximum speed until the adapter 
-      stops to complain, which is at the same time the maximum possible
-      speed selected in the reference program. So, F/W external can run at
-      5 MHz (slow-) or 10 MHz (fast-SCSI). During feature probing, the 
-      COMMAND ERROR message is used to detect if the adapter does not complain.
-   2) Up to now, only combined busmode is supported, if you use external
-      SCSI-devices, attached to the F/W-controller. If dual bus is selected,
-      only the internal SCSI-devices get accessed by Linux. For most 
-      applications, this should do fine. 
-   3) Wide-SCSI-addressing (16-Bit) is now possible for the internal F/W
-      bus on the F/W adapter. If F/W adapter is detected, the driver
-      automatically uses the extended PUN/LUN <-> LDN mapping tables, which
-      are now new from 3.2pre8. This allows PUNs between 0 and 15 and should
-      provide more fun with the F/W adapter.
-   4) Several machines use the SCSI: POS registers for internal/undocumented
-      storage of system relevant info. This confused the driver, mainly on
-      models 9595, as it expected no onboard SCSI only, if all POS in
-      the integrated SCSI-area are set to 0x00 or 0xff. Now, the mechanism
-      to check for integrated SCSI is much more restrictive and these problems
-      should be history.
-   - Michael Lang          
-
-   July 18, 2000 (v3.2pre9)
-   This develop rather quickly at the moment. Two major things were still
-   missing in 3.2pre8:
-   1) The adapter PUN for F/W adapters has 4-bits, while all other adapters
-      have 3-bits. This is now taken into account for F/W.
-   2) When you select CONFIG_IBMMCA_SCSI_ORDER_STANDARD, you should 
-      normally get the inverse probing order of your devices on the SCSI-bus.
-      The ANSI device order gets scrambled in version 3.2pre8!! Now, a new
-      and tested algorithm inverts the device-order on the SCSI-bus and
-      automatically avoids accidental access to whatever SCSI PUN the adapter 
-      is set and works with SCSI- and Wide-SCSI-addressing.
-   - Michael Lang
-
-   July 23, 2000 (v3.2pre10 unpublished) 
-   1) LED panel display supports wide-addressing in ibmmca=display mode.
-   2) Adapter-information and autoadaption to address-space is done.
-   3) Auto-probing for maximum synchronous SCSI transfer rate is working.
-   4) Optimization to some embedded function calls is applied.
-   5) Added some comment for the user to wait for SCSI-devices being probed.
-   6) Finished version 3.2 for Kernel 2.4.0. It least, I thought it is but...
-   - Michael Lang
-   
-   July 26, 2000 (v3.2pre11)
-   1) I passed a horrible weekend getting mad with NMIs on kernel 2.2.14 and
-      a model 9595. Asking around in the community, nobody except of me has
-      seen such errors. Weird, but I am trying to recompile everything on
-      the model 9595. Maybe, as I use a specially modified gcc, that could
-      cause problems. But, it was not the reason. The true background was,
-      that the kernel was compiled for i386 and the 9595 has a 486DX-2. 
-      Normally, no troubles should appear, but for this special machine,
-      only the right processor support is working fine!
-   2) Previous problems with synchronous speed, slowing down from one adapter 
-      to the next during probing are corrected. Now, local variables store
-      the synchronous bitmask for every single adapter found on the MCA bus.
-   3) LED alphanumeric panel support for XX95 systems is now showing some
-      alive rotator during boottime. This makes sense, when no monitor is 
-      connected to the system. You can get rid of all display activity, if
-      you do not use any parameter or just ibmmcascsi=activity, for the 
-      harddrive activity LED, existent on all PS/2, except models 8595-XXX.
-      If no monitor is available, please use ibmmcascsi=display, which works
-      fine together with the linuxinfo utility for the LED-panel.
-   - Michael Lang
-   
-   July 29, 2000 (v3.2)
-   1) Submission of this driver for kernel 2.4test-XX and 2.2.17.
-   - Michael Lang
-   
-   December 28, 2000 (v3.2d / v4.0)
-   1) The interrupt handler had some wrong statement to wait for. This
-      was done due to experimental reasons during 3.2 development but it
-      has shown that this is not stable enough. Going back to wait for the
-      adapter to be not busy is best.
-   2) Inquiry requests can be shorter than 255 bytes of return buffer. Due
-      to a bug in the ibmmca_queuecommand routine, this buffer was forced
-      to 255 at minimum. If the memory address, this return buffer is pointing
-      to does not offer more space, invalid memory accesses destabilized the
-      kernel.
-   3) version 4.0 is only valid for kernel 2.4.0 or later. This is necessary
-      to remove old kernel version dependent waste from the driver. 3.2d is
-      only distributed with older kernels but keeps compatibility with older
-      kernel versions. 4.0 and higher versions cannot be used with older 
-      kernels anymore!! You must have at least kernel 2.4.0!!
-   4) The commandline argument 'bypass' and all its functionality got removed
-      in version 4.0. This was never really necessary, as all troubles were
-      based on non-command related reasons up to now, so bypassing commands
-      did not help to avoid any bugs. It is kept in 3.2X for debugging reasons.
-   5) Dynamic reassignment of ldns was again verified and analyzed to be
-      completely inoperational. This is corrected and should work now.
-   6) All commands that get sent to the SCSI adapter were verified and
-      completed in such a way, that they are now completely conform to the
-      demands in the technical description of IBM. Main candidates were the
-      DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
-      be transferred by bypassing the internal command buffer of the adapter
-      or else the response can be a random result. GET_POS_INFO would be more
-      safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this
-      is not allowed by the technical references of IBM. (Sorry, folks, the
-      model 80 problem is still a task to be solved in a different way.)
-   7) v3.2d is still hold back for some days for testing, while 4.0 is 
-      released.
-   - Michael Lang
-   
-   January 3, 2001 (v4.0a)
-   1) A lot of complains after the 2.4.0-prerelease kernel came in about
-      the impossibility to compile the driver as a module. This problem is
-      solved. In combination with that problem, some unprecise declaration
-      of the function option_setup() gave some warnings during compilation.
-      This is solved, too by a forward declaration in ibmmca.c.
-   2) #ifdef argument concerning CONFIG_SCSI_IBMMCA is no longer needed and
-      was entirely removed.
-   3) Some switch statements got optimized in code, as some minor variables
-      in internal SCSI-command handlers.
-   - Michael Lang
-
-   4 To do
-   -------
-        - IBM SCSI-2 F/W external SCSI bus support in separate mode!
-        - It seems that the handling of bad disks is really bad -
-          non-existent, in fact. However, a low-level driver cannot help
-          much, if such things happen.
-
-   5 Users' Manual
-   ---------------
-   5.1 Commandline Parameters
-   --------------------------
-   There exist several features for the IBM SCSI-subsystem driver.
-   The commandline parameter format is:
-   
-         ibmmcascsi=<command1>,<command2>,<command3>,...
-         
-   where commandN can be one of the following:
-   
-         display    Owners of a model 95 or other PS/2 systems with an
-                    alphanumeric LED display may set this to have their
-                    display showing the following output of the 8 digits:
-                      
-                                ------DA
-                                
-                    where '-' stays dark, 'D' shows the SCSI-device id
-                    and 'A' shows the SCSI hostindex, being currently 
-                    accessed. During boottime, this will give the message
-                    
-                                SCSIini*
-                                
-                    on the LED-panel, where the * represents a rotator, 
-                    showing the activity during the probing phase of the
-                    driver which can take up to two minutes per SCSI-adapter.
-         adisplay   This works like display, but gives more optical overview 
-                    of the activities on the SCSI-bus. The display will have
-                    the following output:
-                    
-                                6543210A
-                                
-                    where the numbers 0 to 6 light up at the shown position,
-                    when the SCSI-device is accessed. 'A' shows again the SCSI
-                    hostindex. If display nor adisplay is set, the internal
-                    PS/2 harddisk LED is used for media-activities. So, if
-                    you really do not have a system with a LED-display, you
-                    should not set display or adisplay. Keep in mind, that
-                    display and adisplay can only be used alternatively. It
-                    is not recommended to use this option, if you have some
-                    wide-addressed devices e.g. at the SCSI-2 F/W adapter in
-                    your system. In addition, the usage of the display for
-                    other tasks in parallel, like the linuxinfo-utility makes 
-                    no sense with this option.
-         activity   This enables the PS/2 harddisk LED activity indicator.
-                    Most PS/2 have no alphanumeric LED display, but some
-                    indicator. So you should use this parameter to activate it.
-                    If you own model 9595 (Server95), you can have both, the 
-                    LED panel and the activity indicator in parallel. However,
-                    some PS/2s, like the 8595 do not have any harddisk LED 
-                    activity indicator, which means, that you must use the
-                    alphanumeric LED display if you want to monitor SCSI-
-                    activity.
-         bypass     This is obsolete from driver version 4.0, as the adapters
-                    got that far understood, that the selection between 
-                    integrated and bypassed commands should now work completely
-                    correct! For historical reasons, the old description is
-                    kept here:
-                    This commandline parameter forces the driver never to use
-                    SCSI-subsystems' integrated SCSI-command set. Except of
-                    the immediate assign, which is of vital importance for
-                    every IBM SCSI-subsystem to set its ldns right. Instead,
-                    the ordinary ANSI-SCSI-commands are used and passed by the
-                    controller to the SCSI-devices, therefore 'bypass'. The
-                    effort, done by the subsystem is quite bogus and at a
-                    minimum and therefore it should work everywhere. This
-                    could maybe solve troubles with old or integrated SCSI-
-                    controllers and nasty harddisks. Keep in mind, that using 
-                    this flag will slow-down SCSI-accesses slightly, as the 
-                    software generated commands are always slower than the 
-                    hardware. Non-harddisk devices always get read/write-
-                    commands in bypass mode. On the most recent releases of 
-                    the Linux IBM-SCSI-driver, the bypass command should be
-                    no longer a necessary thing, if you are sure about your
-                    SCSI-hardware!
-         normal     This is the parameter, introduced on the 2.0.x development
-                    rail by ZP Gu. This parameter defines the SCSI-device
-                    scan order in the new industry standard. This means, that
-                    the first SCSI-device is the one with the lowest pun.
-                    E.g. harddisk at pun=0 is scanned before harddisk at
-                    pun=6, which means, that harddisk at pun=0 gets sda
-                    and the one at pun=6 gets sdb.
-         ansi       The ANSI-standard for the right scan order, as done by
-                    IBM, Microware and Microsoft, scans SCSI-devices starting
-                    at the highest pun, which means, that e.g. harddisk at
-                    pun=6 gets sda and a harddisk at pun=0 gets sdb. If you
-                    like to have the same SCSI-device order, as in DOS, OS-9
-                    or OS/2, just use this parameter.
-         fast       SCSI-I/O in synchronous mode is done at 5 MHz for IBM-
-                    SCSI-devices. SCSI-2 Fast/Wide Adapter/A external bus
-                    should then run at 10 MHz if Fast-SCSI is enabled,
-                    and at 5 MHz if Fast-SCSI is disabled on the external
-                    bus. This is the default setting when nothing is 
-                    specified here.
-         medium     Synchronous rate is at 50% approximately, which means
-                    2.5 MHz for IBM SCSI-adapters and 5.0 MHz for F/W ext.
-                    SCSI-bus (when Fast-SCSI speed enabled on external bus).
-         slow       The slowest possible synchronous transfer rate is set. 
-                    This means 1.82 MHz for IBM SCSI-adapters and 2.0 MHz
-                    for F/W external bus at Fast-SCSI speed on the external
-                    bus.
-                    
-   A further option is that you can force the SCSI-driver to accept a SCSI-
-   subsystem at a certain I/O-address with a predefined adapter PUN. This
-   is done by entering 
-
-                  commandN   = I/O-base
-                  commandN+1 = adapter PUN
-                  
-   e.g. ibmmcascsi=0x3540,7 will force the driver to detect a SCSI-subsystem 
-   at I/O-address 0x3540 with adapter PUN 7. Please only use this method, if
-   the driver does really not recognize your SCSI-adapter! With driver version
-   3.2, this recognition of various adapters was hugely improved and you
-   should try first to remove your commandline arguments of such type with a 
-   newer driver. I bet, it will be recognized correctly. Even multiple and 
-   different types of IBM SCSI-adapters should be recognized correctly, too.
-   Use the forced detection method only as last solution!
-   
-   Examples:
-   
-        ibmmcascsi=adisplay
-        
-   This will use the advanced display mode for the model 95 LED alphanumeric
-   display.
-   
-        ibmmcascsi=display,0x3558,7
-        
-   This will activate the default display mode for the model 95 LED display
-   and will force the driver to accept a SCSI-subsystem at I/O-base 0x3558
-   with adapter PUN 7.
-   
-   5.2 Troubleshooting
-   -------------------
-   The following FAQs should help you to solve some major problems with this
-   driver.
-   
-     Q: "Reset SCSI-devices at boottime" halts the system at boottime, why?
-     A: This is only tested with the IBM SCSI Adapter w/cache. It is not
-        yet proven to run on other adapters, however you may be lucky.
-        In version 3.1d this has been hugely improved and should work better,
-        now. Normally you really won't need to activate this flag in the
-        kernel configuration, as all post 1989 SCSI-devices should accept
-        the reset-signal, when the computer is switched on. The SCSI-
-        subsystem generates this reset while being initialized. This flag
-        is really reserved for users with very old, very strange or self-made
-        SCSI-devices.
-     Q: Why is the SCSI-order of my drives mirrored to the device-order
-        seen from OS/2 or DOS ?
-     A: It depends on the operating system, if it looks at the devices in
-        ANSI-SCSI-standard (starting from pun 6 and going down to pun 0) or
-        if it just starts at pun 0 and counts up. If you want to be conform
-        with OS/2 and DOS, you have to activate this flag in the kernel
-        configuration or you should set 'ansi' as parameter for the kernel.
-        The parameter 'normal' sets the new industry standard, starting
-        from pun 0, scanning up to pun 6. This allows you to change your 
-        opinion still after having already compiled the kernel.
-     Q: Why can't I find IBM MCA SCSI support in the config menu?
-     A: You have to activate MCA bus support, first.
-     Q: Where can I find the latest info about this driver?
-     A: See the file MAINTAINERS for the current WWW-address, which offers
-        updates, info and Q/A lists. At this file's origin, the webaddress
-        was: http://www.staff.uni-mainz.de/mlang/linux.html
-     Q: My SCSI-adapter is not recognized by the driver, what can I do?
-     A: Just force it to be recognized by kernel parameters. See section 5.1.
-        If this really happens, do also send e-mail to the maintainer, as
-        forced detection should be never necessary. Forced detection is in
-        principal some flaw of the driver adapter detection and goes into 
-        bug reports.
-     Q: The driver screws up, if it starts to probe SCSI-devices, is there
-        some way out of it?
-     A: Yes, that was some recognition problem of the correct SCSI-adapter
-        and its I/O base addresses. Upgrade your driver to the latest release
-        and it should be fine again.
-     Q: I get a message: panic IBM MCA SCSI: command error .... , what can
-        I do against this?
-     A: Previously, I followed the way by ignoring command errors by using
-        ibmmcascsi=forgiveall, but this command no longer exists and is
-        obsolete. If such a problem appears, it is caused by some segmentation
-        fault of the driver, which maps to some unallowed area. The latest 
-        version of the driver should be ok, as most bugs have been solved.
-     Q: There are still kernel panics, even after having set 
-        ibmmcascsi=forgiveall. Are there other possibilities to prevent
-        such panics?
-     A: No, get just the latest release of the driver and it should work 
-        better and better with increasing version number. Forget about this
-        ibmmcascsi=forgiveall, as also ignorecmd are obsolete.!
-     Q: Linux panics or stops without any comment, but it is probable, that my
-        harddisk(s) have bad blocks.
-     A: Sorry, the bad-block handling is still a feeble point of this driver,
-        but is on the schedule for development in the near future.
-     Q: Linux panics while dynamically assigning SCSI-ids or ldns.
-     A: If you disconnect a SCSI-device from the machine, while Linux is up
-        and the driver uses dynamical reassignment of logical device numbers
-        (ldn), it really gets "angry" if it won't find devices, that were still
-        present at boottime and stops Linux.
-     Q: The system does not recover after an abort-command has been generated.
-     A: This is regrettably true, as it is not yet understood, why the 
-        SCSI-adapter does really NOT generate any interrupt at the end of
-        the abort-command. As no interrupt is generated, the abort command
-        cannot get finished and the system hangs, sorry, but checks are 
-        running to hunt down this problem. If there is a real pending command,
-        the interrupt MUST get generated after abort. In this case, it
-        should finish well.
-     Q: The system gets in bad shape after a SCSI-reset, is this known?
-     A: Yes, as there are a lot of prescriptions (see the Linux Hackers'
-        Guide) what has to be done for reset, we still share the bad shape of
-        the reset functions with all other low level SCSI-drivers. 
-        Astonishingly, reset works in most cases quite ok, but the harddisks
-        won't run in synchronous mode anymore after a reset, until you reboot.
-     Q: Why does my XXX w/Cache adapter not use read-prefetch?
-     A: Ok, that is not completely possible. If a cache is present, the 
-        adapter tries to use it internally. Explicitly, one can use the cache
-        with a read prefetch command, maybe in future, but this requires
-        some major overhead of SCSI-commands that risks the performance to
-        go down more than it gets improved. Tests with that are running.
-     Q: I have a IBM SCSI-2 Fast/Wide adapter, it boots in some way and hangs.
-     A: Yes, that is understood, as for sure, your SCSI-2 Fast/Wide adapter
-        was in such a case recognized as integrated SCSI-adapter or something 
-        else, but not as the correct adapter. As the I/O-ports get assigned 
-        wrongly by that reason, the system should crash in most cases. You 
-        should upgrade to the latest release of the SCSI-driver. The 
-        recommended version is 3.2 or later. Here, the F/W support is in
-        a stable and reliable condition. Wide-addressing is in addition 
-        supported.
-     Q: I get an Oops message and something like "killing interrupt".
-     A: The reason for this is that the IBM SCSI-subsystem only sends a 
-        termination status back, if some error appeared. In former releases
-        of the driver, it was not checked, if the termination status block
-        is NULL. From version 3.2, it is taken care of this.
-     Q: I have a F/W adapter and the driver sees my internal SCSI-devices,
-        but ignores the external ones.
-     A: Select combined busmode in the IBM config-program and check for that
-        no SCSI-id on the external devices appears on internal devices.
-        Reboot afterwards. Dual busmode is supported, but works only for the
-        internal bus, yet. External bus is still ignored. Take care for your
-        SCSI-ids. If combined bus-mode is activated, on some adapters, 
-        the wide-addressing is not possible, so devices with ids between 8 
-        and 15 get ignored by the driver & adapter!
-     Q: I have a 9595 and I get a NMI during heavy SCSI I/O e.g. during fsck.
-        A COMMAND ERROR is reported and characters on the screen are missing.
-        Warm reboot is not possible. Things look like quite weird.
-     A: Check the processor type of your 9595. If you have an 80486 or 486DX-2
-        processor complex on your mainboard and you compiled a kernel that
-        supports 80386 processors, it is possible, that the kernel cannot
-        keep track of the PS/2 interrupt handling and stops on an NMI. Just
-        compile a kernel for the correct processor type of your PS/2 and
-        everything should be fine. This is necessary even if one assumes,
-        that some 80486 system should be downward compatible to 80386
-        software.
-     Q: Some commands hang and interrupts block the machine. After some
-        timeout, the syslog reports that it tries to call abort, but the
-        machine is frozen.
-     A: This can be a busy wait bug in the interrupt handler of driver 
-        version 3.2. You should at least upgrade to 3.2c if you use 
-        kernel < 2.4.0 and driver version 4.0 if you use kernel 2.4.0 or 
-        later (including all test releases).
-     Q: I have a PS/2 model 80 and more than 16 MBytes of RAM. The driver
-        completely refuses to work, reports NMIs, COMMAND ERRORs or other
-        ambiguous stuff. When reducing the RAM size down below 16 MB, 
-        everything is running smoothly.
-     A: No real answer, yet. In any case, one should force the kernel to
-        present SCBs only below the 16 MBytes barrier. Maybe this solves the
-        problem. Not yet tried, but guessing that it could work. To get this,
-        set unchecked_isa_dma argument of ibmmca.h from 0 to 1.
-
-   5.3 Bug reports
-   --------------
-   If you really find bugs in the source code or the driver will successfully
-   refuse to work on your machine, you should send a bug report to me. The
-   best for this is to follow the instructions on the WWW-page for this
-   driver. Fill out the bug-report form, placed on the WWW-page and ship it,
-   so the bugs can be taken into account with maximum efforts. But, please
-   do not send bug reports about this driver to Linus Torvalds or Leonard
-   Zubkoff, as Linus is buried in E-Mail and Leonard is supervising all
-   SCSI-drivers and won't have the time left to look inside every single
-   driver to fix a bug and especially DO NOT send modified code to Linus
-   Torvalds or Alan J. Cox which has not been checked here!!! They are both
-   quite buried in E-mail (as me, sometimes, too) and one should first check
-   for problems on my local teststand. Recently, I got a lot of 
-   bug reports for errors in the ibmmca.c code, which I could not imagine, but
-   a look inside some Linux-distribution showed me quite often some modified
-   code, which did no longer work on most other machines than the one of the
-   modifier. Ok, so now that there is maintenance service available for this
-   driver, please use this address first in order to keep the level of
-   confusion low. Thank you!
-   
-   When you get a SCSI-error message that panics your system, a list of
-   register-entries of the SCSI-subsystem is shown (from Version 3.1d). With 
-   this list, it is very easy for the maintainer to localize the problem in 
-   the driver or in the configuration of the user. Please write down all the 
-   values from this report and send them to the maintainer. This would really 
-   help a lot and makes life easier concerning misunderstandings.
-   
-   Use the bug-report form (see 5.4 for its address) to send all the bug-
-   stuff to the maintainer or write e-mail with the values from the table. 
-   
-   5.4 Support WWW-page
-   --------------------
-   The address of the IBM SCSI-subsystem supporting WWW-page is:
-   
-        http://www.staff.uni-mainz.de/mlang/linux.html
-        
-   Here you can find info about the background of this driver, patches,
-   troubleshooting support, news and a bugreport form. Please check that
-   WWW-page regularly for latest hints. If ever this URL changes, please 
-   refer to the MAINTAINERS file in order to get the latest address.
-   
-   For the bugreport, please fill out the formular on the corresponding
-   WWW-page. Read the dedicated instructions and write as much as you
-   know about your problem. If you do not like such formulars, please send
-   some e-mail directly, but at least with the same information as required by
-   the formular.
-   
-   If you have extensive bug reports, including Oops messages and
-   screen-shots, please feel free to send it directly to the address
-   of the maintainer, too. The current address of the maintainer is:
-   
-            Michael Lang <langa2@kph.uni-mainz.de>
-   
-   6 References
-   ------------
-   IBM Corp., "Update for the PS/2 Hardware Interface Technical Reference, 
-   Common Interfaces", Armonk, September 1991, PN 04G3281, 
-   (available in the U.S. for $21.75 at 1-800-IBM-PCTB or in Germany for
-   around 40,-DM at "Hallo IBM").
-  
-   IBM Corp., "Personal System/2 Micro Channel SCSI
-   Adapter with Cache Technical Reference", Armonk, March 1990, PN 68X2365.
-
-   IBM Corp., "Personal System/2 Micro Channel SCSI
-   Adapter Technical Reference", Armonk, March 1990, PN 68X2397.
-
-   IBM Corp., "SCSI-2 Fast/Wide Adapter/A Technical Reference - Dual Bus",
-   Armonk, March 1994, PN 83G7545.
- 
-   Friedhelm Schmidt, "SCSI-Bus und IDE-Schnittstelle - Moderne Peripherie-
-   Schnittstellen: Hardware, Protokollbeschreibung und Anwendung", 2. Aufl.
-   Addison Wesley, 1996.
-   
-   Michael K. Johnson, "The Linux Kernel Hackers' Guide", Version 0.6, Chapel
-   Hill - North Carolina, 1995
-   
-   Andreas Kaiser, "SCSI TAPE BACKUP for OS/2 2.0", Version 2.12, Stuttgart
-   1993
-   
-   Helmut Rompel, "IBM Computerwelt GUIDE", What is what bei IBM., Systeme *
-   Programme * Begriffe, IWT-Verlag GmbH - Muenchen, 1988
-   
-   7 Credits to
-   ------------
-   7.1 People
-   ----------
-   Klaus Grimm
-                who already a long time ago gave me the old code from the
-                SCSI-driver in order to get it running for some old machine
-                in our institute.
-   Martin Kolinek
-                who wrote the first release of the IBM SCSI-subsystem driver.
-   Chris Beauregard
-                who for a long time maintained MCA-Linux and the SCSI-driver
-                in the beginning. Chris, wherever you are: Cheers to you!
-   Klaus Kudielka
-                with whom in the 2.1.x times, I had a quite fruitful
-                cooperation to get the driver running as a module and to get
-                it running with multiple SCSI-adapters.
-   David Weinehall
-                for his excellent maintenance of the MCA-stuff and the quite 
-                detailed bug reports and ideas for this driver (and his 
-                patience ;-)).
-   Alan J. Cox  
-                for his bug reports and his bold activities in cross-checking
-                the driver-code with his teststand.
-                
-   7.2 Sponsors & Supporters
-   -------------------------
-   "Hallo IBM",
-   IBM-Deutschland GmbH
-                the service of IBM-Deutschland for customers. Their E-Mail
-                service is unbeatable. Whatever old stuff I asked for, I 
-                always got some helpful answers.
-   Karl-Otto Reimers,
-   IBM Klub - Sparte IBM Geschichte, Sindelfingen
-                for sending me a copy of the w/Cache manual from the 
-                IBM-Deutschland archives.
-   Harald Staiger
-                for his extensive hardware donations which allows me today
-                still to test the driver in various constellations.
-   Erich Fritscher
-                for his very kind sponsoring.
-   Louis Ohland,
-   Charles Lasitter
-                for support by shipping me an IBM SCSI-2 Fast/Wide manual.
-                In addition, the contribution of various hardware is quite 
-                decessive and will make it possible to add FWSR (RAID)
-                adapter support to the driver in the near future! So,
-                complaints about no RAID support won't remain forever.
-                Yes, folks, that is no joke, RAID support is going to rise!
-   Erik Weber
-                for the great deal we made about a model 9595 and the nice
-                surrounding equipment and the cool trip to Mannheim
-                second-hand computer market. In addition, I would like
-                to thank him for his exhaustive SCSI-driver testing on his 
-                95er PS/2 park.
-   Anthony Hogbin
-                for his direct shipment of a SCSI F/W adapter, which allowed
-                me immediately on the first stage to try it on model 8557
-                together with onboard SCSI adapter and some SCSI w/Cache.
-   Andreas Hotz
-                for his support by memory and an IBM SCSI-adapter. Collecting
-                all this together now allows me to try really things with
-                the driver at maximum load and variety on various models in
-                a very quick and efficient way.
-   Peter Jennewein
-                for his model 30, which serves me as part of my teststand
-                and his cool remark about how you make an ordinary diskette
-                drive working and how to connect it to an IBM-diskette port.
-   Johannes Gutenberg-Universitaet, Mainz &
-   Institut fuer Kernphysik, Mainz Microtron (MAMI)
-                for the offered space, the link, placed on the central
-                homepage and the space to store and offer the driver and 
-                related material and the free working times, which allow
-                me to answer all your e-mail.
-                   
-   8 Trademarks
-   ------------
-   IBM, PS/2, OS/2, Microchannel are registered trademarks of International 
-   Business Machines Corporation
-   
-   MS-DOS is a registered trademark of Microsoft Corporation
-   
-   Microware, OS-9 are registered trademarks of Microware Systems
-   
-   9 Disclaimer
-   ------------
-   Beside the GNU General Public License and the dependent disclaimers and disclaimers
-   concerning the Linux-kernel in special, this SCSI-driver comes without any
-   warranty. Its functionality is tested as good as possible on certain 
-   machines and combinations of computer hardware, which does not exclude,
-   that data loss or severe damage of hardware is possible while using this
-   part of software on some arbitrary computer hardware or in combination 
-   with other software packages. It is highly recommended to make backup
-   copies of your data before using this software. Furthermore, personal
-   injuries by hardware defects, that could be caused by this SCSI-driver are
-   not excluded and it is highly recommended to handle this driver with a
-   maximum of carefulness.
-   
-   This driver supports hardware, produced by International Business Machines
-   Corporation (IBM).
-   
-------
-Michael Lang 
-(langa2@kph.uni-mainz.de)
diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt
index 21e5798526ee..2bfd6f6d2d3d 100644
--- a/Documentation/scsi/scsi-parameters.txt
+++ b/Documentation/scsi/scsi-parameters.txt
@@ -37,9 +37,6 @@ parameters may be changed at runtime by the command
 
         eata=           [HW,SCSI]
 
-        fd_mcs=         [HW,SCSI]
-                        See header of drivers/scsi/fd_mcs.c.
-
         fdomain=        [HW,SCSI]
                         See header of drivers/scsi/fdomain.c.
 
@@ -48,9 +45,6 @@ parameters may be changed at runtime by the command
 
         gvp11=          [HW,SCSI]
 
-        ibmmcascsi=     [HW,MCA,SCSI] IBM MicroChannel SCSI adapter
-                        See Documentation/mca.txt.
-
         in2000=         [HW,SCSI]
                         See header of drivers/scsi/in2000.c.
 
diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt
index a340b18cd4eb..2b06aba4fa0f 100644
--- a/Documentation/scsi/scsi_mid_low_api.txt
+++ b/Documentation/scsi/scsi_mid_low_api.txt
@@ -30,7 +30,7 @@ the motherboard (or both). Some aic7xxx based HBAs are dual controllers
 and thus represent two hosts. Like most modern HBAs, each aic7xxx host
 has its own PCI device address. [The one-to-one correspondence between
 a SCSI host and a PCI device is common but not required (e.g. with
-ISA or MCA adapters).]
+ISA adapters).]
 
 The SCSI mid level isolates an LLD from other layers such as the SCSI
 upper layer drivers and the block layer.
diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt
index d2f72ae66432..a416479b8a1c 100644
--- a/Documentation/security/Smack.txt
+++ b/Documentation/security/Smack.txt
@@ -15,7 +15,7 @@ at hand.
 
 Smack consists of three major components:
     - The kernel
-    - A start-up script and a few modified applications
+    - Basic utilities, which are helpful but not required
     - Configuration data
 
 The kernel component of Smack is implemented as a Linux
@@ -23,37 +23,28 @@ Security Modules (LSM) module. It requires netlabel and
 works best with file systems that support extended attributes,
 although xattr support is not strictly required.
 It is safe to run a Smack kernel under a "vanilla" distribution.
+
 Smack kernels use the CIPSO IP option. Some network
 configurations are intolerant of IP options and can impede
 access to systems that use them as Smack does.
 
-The startup script etc-init.d-smack should be installed
-in /etc/init.d/smack and should be invoked early in the
-start-up process. On Fedora rc5.d/S02smack is recommended.
-This script ensures that certain devices have the correct
-Smack attributes and loads the Smack configuration if
-any is defined. This script invokes two programs that
-ensure configuration data is properly formatted. These
-programs are /usr/sbin/smackload and /usr/sin/smackcipso.
-The system will run just fine without these programs,
-but it will be difficult to set access rules properly.
-
-A version of "ls" that provides a "-M" option to display
-Smack labels on long listing is available.
+The current git repositories for Smack user space are:
 
-A hacked version of sshd that allows network logins by users
-with specific Smack labels is available. This version does
-not work for scp. You must set the /etc/ssh/sshd_config
-line:
-   UsePrivilegeSeparation no
+        git@gitorious.org:meego-platform-security/smackutil.git
+        git@gitorious.org:meego-platform-security/libsmack.git
 
-The format of /etc/smack/usr is:
+These should make and install on most modern distributions.
+There are three commands included in smackutil:
 
-   username smack
+smackload  - properly formats data for writing to /smack/load
+smackcipso - properly formats data for writing to /smack/cipso
+chsmack    - display or set Smack extended attribute values
 
 In keeping with the intent of Smack, configuration data is
 minimal and not strictly required. The most important
 configuration step is mounting the smackfs pseudo filesystem.
+If smackutil is installed the startup script will take care
+of this, but it can be manually as well.
 
 Add this line to /etc/fstab:
 
@@ -61,19 +52,148 @@ Add this line to /etc/fstab:
 
 and create the /smack directory for mounting.
 
-Smack uses extended attributes (xattrs) to store file labels.
-The command to set a Smack label on a file is:
+Smack uses extended attributes (xattrs) to store labels on filesystem
+objects. The attributes are stored in the extended attribute security
+name space. A process must have CAP_MAC_ADMIN to change any of these
+attributes.
+
+The extended attributes that Smack uses are:
+
+SMACK64
+        Used to make access control decisions. In almost all cases
+        the label given to a new filesystem object will be the label
+        of the process that created it.
+SMACK64EXEC
+        The Smack label of a process that execs a program file with
+        this attribute set will run with this attribute's value.
+SMACK64MMAP
+        Don't allow the file to be mmapped by a process whose Smack
+        label does not allow all of the access permitted to a process
+        with the label contained in this attribute. This is a very
+        specific use case for shared libraries.
+SMACK64TRANSMUTE
+        Can only have the value "TRUE". If this attribute is present
+        on a directory when an object is created in the directory and
+        the Smack rule (more below) that permitted the write access
+        to the directory includes the transmute ("t") mode the object
+        gets the label of the directory instead of the label of the
+        creating process. If the object being created is a directory
+        the SMACK64TRANSMUTE attribute is set as well.
+SMACK64IPIN
+        This attribute is only available on file descriptors for sockets.
+        Use the Smack label in this attribute for access control
+        decisions on packets being delivered to this socket.
+SMACK64IPOUT
+        This attribute is only available on file descriptors for sockets.
+        Use the Smack label in this attribute for access control
+        decisions on packets coming from this socket.
+
+There are multiple ways to set a Smack label on a file:
 
     # attr -S -s SMACK64 -V "value" path
+    # chsmack -a value path
 
-NOTE: Smack labels are limited to 23 characters. The attr command
-      does not enforce this restriction and can be used to set
-      invalid Smack labels on files.
-
-If you don't do anything special all users will get the floor ("_")
-label when they log in. If you do want to log in via the hacked ssh
-at other labels use the attr command to set the smack value on the
-home directory and its contents.
+A process can see the smack label it is running with by
+reading /proc/self/attr/current. A process with CAP_MAC_ADMIN
+can set the process smack by writing there.
+
+Most Smack configuration is accomplished by writing to files
+in the smackfs filesystem. This pseudo-filesystem is usually
+mounted on /smack.
+
+access
+        This interface reports whether a subject with the specified
+        Smack label has a particular access to an object with a
+        specified Smack label. Write a fixed format access rule to
+        this file. The next read will indicate whether the access
+        would be permitted. The text will be either "1" indicating
+        access, or "0" indicating denial.
+access2
+        This interface reports whether a subject with the specified
+        Smack label has a particular access to an object with a
+        specified Smack label. Write a long format access rule to
+        this file. The next read will indicate whether the access
+        would be permitted. The text will be either "1" indicating
+        access, or "0" indicating denial.
+ambient
+        This contains the Smack label applied to unlabeled network
+        packets.
+cipso
+        This interface allows a specific CIPSO header to be assigned
+        to a Smack label. The format accepted on write is:
+                "%24s%4d%4d"["%4d"]...
+        The first string is a fixed Smack label. The first number is
+        the level to use. The second number is the number of categories.
+        The following numbers are the categories.
+        "level-3-cats-5-19          3   2   5  19"
+cipso2
+        This interface allows a specific CIPSO header to be assigned
+        to a Smack label. The format accepted on write is:
+        "%s%4d%4d"["%4d"]...
+        The first string is a long Smack label. The first number is
+        the level to use. The second number is the number of categories.
+        The following numbers are the categories.
+        "level-3-cats-5-19   3   2   5  19"
+direct
+        This contains the CIPSO level used for Smack direct label
+        representation in network packets.
+doi
+        This contains the CIPSO domain of interpretation used in
+        network packets.
+load
+        This interface allows access control rules in addition to
+        the system defined rules to be specified. The format accepted
+        on write is:
+                "%24s%24s%5s"
+        where the first string is the subject label, the second the
+        object label, and the third the requested access. The access
+        string may contain only the characters "rwxat-", and specifies
+        which sort of access is allowed. The "-" is a placeholder for
+        permissions that are not allowed. The string "r-x--" would
+        specify read and execute access. Labels are limited to 23
+        characters in length.
+load2
+        This interface allows access control rules in addition to
+        the system defined rules to be specified. The format accepted
+        on write is:
+                "%s %s %s"
+        where the first string is the subject label, the second the
+        object label, and the third the requested access. The access
+        string may contain only the characters "rwxat-", and specifies
+        which sort of access is allowed. The "-" is a placeholder for
+        permissions that are not allowed. The string "r-x--" would
+        specify read and execute access.
+load-self
+        This interface allows process specific access rules to be
+        defined. These rules are only consulted if access would
+        otherwise be permitted, and are intended to provide additional
+        restrictions on the process. The format is the same as for
+        the load interface.
+load-self2
+        This interface allows process specific access rules to be
+        defined. These rules are only consulted if access would
+        otherwise be permitted, and are intended to provide additional
+        restrictions on the process. The format is the same as for
+        the load2 interface.
+logging
+        This contains the Smack logging state.
+mapped
+        This contains the CIPSO level used for Smack mapped label
+        representation in network packets.
+netlabel
+        This interface allows specific internet addresses to be
+        treated as single label hosts. Packets are sent to single
+        label hosts without CIPSO headers, but only from processes
+        that have Smack write access to the host label. All packets
+        received from single label hosts are given the specified
+        label. The format accepted on write is:
+                "%d.%d.%d.%d label" or "%d.%d.%d.%d/%d label".
+onlycap
+        This contains the label processes must have for CAP_MAC_ADMIN
+        and CAP_MAC_OVERRIDE to be effective. If this file is empty
+        these capabilities are effective at for processes with any
+        label. The value is set by writing the desired label to the
+        file or cleared by writing "-" to the file.
 
 You can add access rules in /etc/smack/accesses. They take the form:
 
@@ -83,10 +203,6 @@ access is a combination of the letters rwxa which specify the
 kind of access permitted a subject with subjectlabel on an
 object with objectlabel. If there is no rule no access is allowed.
 
-A process can see the smack label it is running with by
-reading /proc/self/attr/current. A privileged process can
-set the process smack by writing there.
-
 Look for additional programs on http://schaufler-ca.com
 
 From the Smack Whitepaper:
@@ -186,7 +302,7 @@ team. Smack labels are unstructured, case sensitive, and the only operation
 ever performed on them is comparison for equality. Smack labels cannot
 contain unprintable characters, the "/" (slash), the "\" (backslash), the "'"
 (quote) and '"' (double-quote) characters.
-Smack labels cannot begin with a '-', which is reserved for special options.
+Smack labels cannot begin with a '-'. This is reserved for special options.
 
 There are some predefined labels:
 
@@ -194,7 +310,7 @@ There are some predefined labels:
         ^       Pronounced "hat", a single circumflex character.
         *       Pronounced "star", a single asterisk character.
         ?       Pronounced "huh", a single question mark character.
-        @       Pronounced "Internet", a single at sign character.
+        @       Pronounced "web", a single at sign character.
 
 Every task on a Smack system is assigned a label. System tasks, such as
 init(8) and systems daemons, are run with the floor ("_") label. User tasks
@@ -246,13 +362,14 @@ The format of an access rule is:
 
 Where subject-label is the Smack label of the task, object-label is the Smack
 label of the thing being accessed, and access is a string specifying the sort
-of access allowed. The Smack labels are limited to 23 characters. The access
-specification is searched for letters that describe access modes:
+of access allowed. The access specification is searched for letters that
+describe access modes:
 
         a: indicates that append access should be granted.
         r: indicates that read access should be granted.
         w: indicates that write access should be granted.
         x: indicates that execute access should be granted.
+        t: indicates that the rule requests transmutation.
 
 Uppercase values for the specification letters are allowed as well.
 Access mode specifications can be in any order. Examples of acceptable rules
@@ -273,7 +390,7 @@ Examples of unacceptable rules are:
 
 Spaces are not allowed in labels. Since a subject always has access to files
 with the same label specifying a rule for that case is pointless. Only
-valid letters (rwxaRWXA) and the dash ('-') character are allowed in
+valid letters (rwxatRWXAT) and the dash ('-') character are allowed in
 access specifications. The dash is a placeholder, so "a-r" is the same
 as "ar". A lone dash is used to specify that no access should be allowed.
 
@@ -297,6 +414,13 @@ but not any of its attributes by the circumstance of having read access to the
 containing directory but not to the differently labeled file. This is an
 artifact of the file name being data in the directory, not a part of the file.
 
+If a directory is marked as transmuting (SMACK64TRANSMUTE=TRUE) and the
+access rule that allows a process to create an object in that directory
+includes 't' access the label assigned to the new object will be that
+of the directory, not the creating process. This makes it much easier
+for two processes with different labels to share data without granting
+access to all of their files.
+
 IPC objects, message queues, semaphore sets, and memory segments exist in flat
 namespaces and access requests are only required to match the object in
 question.
diff --git a/Documentation/security/Yama.txt b/Documentation/security/Yama.txt
index a9511f179069..e369de2d48cd 100644
--- a/Documentation/security/Yama.txt
+++ b/Documentation/security/Yama.txt
@@ -34,7 +34,7 @@ parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
 work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"
 still work as root).
 
-For software that has defined application-specific relationships
+In mode 1, software that has defined application-specific relationships
 between a debugging process and its inferior (crash handlers, etc),
 prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which
 other process (and its descendents) are allowed to call PTRACE_ATTACH
@@ -46,6 +46,8 @@ restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)
 so that any otherwise allowed process (even those in external pid namespaces)
 may attach.
 
+These restrictions do not change how ptrace via PTRACE_TRACEME operates.
+
 The sysctl settings are:
 
 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
@@ -60,6 +62,12 @@ The sysctl settings are:
     inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
     an allowed debugger PID to call PTRACE_ATTACH on the inferior.
 
+2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
+    with PTRACE_ATTACH.
+
+3 - no attach: no processes may use ptrace with PTRACE_ATTACH. Once set,
+    this sysctl cannot be changed to a lower value.
+
 The original children-only logic was based on the restrictions in grsecurity.
 
 ==============================================================
diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt
index d389acd31e19..aa0dbd74b71b 100644
--- a/Documentation/security/keys.txt
+++ b/Documentation/security/keys.txt
@@ -805,6 +805,23 @@ The keyctl syscall functions are:
      kernel and resumes executing userspace.
 
 
+ (*) Invalidate a key.
+
+        long keyctl(KEYCTL_INVALIDATE, key_serial_t key);
+
+     This function marks a key as being invalidated and then wakes up the
+     garbage collector.  The garbage collector immediately removes invalidated
+     keys from all keyrings and deletes the key when its reference count
+     reaches zero.
+
+     Keys that are marked invalidated become invisible to normal key operations
+     immediately, though they are still visible in /proc/keys until deleted
+     (they're marked with an 'i' flag).
+
+     A process must have search permission on the key for this function to be
+     successful.
+
+
 ===============
 KERNEL SERVICES
 ===============
diff --git a/Documentation/serial/stallion.txt b/Documentation/serial/stallion.txt
index 55090914a9c5..4d798c0cb5cb 100644
--- a/Documentation/serial/stallion.txt
+++ b/Documentation/serial/stallion.txt
@@ -20,10 +20,10 @@ There are two drivers that work with the different families of Stallion
 multiport serial boards. One is for the Stallion smart boards - that is
 EasyIO, EasyConnection 8/32 and EasyConnection 8/64-PCI, the other for
 the true Stallion intelligent multiport boards - EasyConnection 8/64
-(ISA, EISA, MCA), EasyConnection/RA-PCI, ONboard and Brumby.
+(ISA, EISA), EasyConnection/RA-PCI, ONboard and Brumby.
 
 If you are using any of the Stallion intelligent multiport boards (Brumby,
-ONboard, EasyConnection 8/64 (ISA, EISA, MCA), EasyConnection/RA-PCI) with
+ONboard, EasyConnection 8/64 (ISA, EISA), EasyConnection/RA-PCI) with
 Linux you will need to get the driver utility package.  This contains a
 firmware loader and the firmware images necessary to make the devices operate.
 
@@ -40,7 +40,7 @@ If you are using the EasyIO, EasyConnection 8/32 or EasyConnection 8/64-PCI
 boards then you don't need this package, although it does have a serial stats
 display program.
 
-If you require DIP switch settings, EISA or MCA configuration files, or any
+If you require DIP switch settings, or EISA configuration files, or any
 other information related to Stallion boards then have a look at Stallion's
 web pages at http://www.stallion.com.
 
@@ -51,13 +51,13 @@ web pages at http://www.stallion.com.
 The drivers can be used as loadable modules or compiled into the kernel.
 You can choose which when doing a "config" on the kernel.
 
-All ISA, EISA and MCA boards that you want to use need to be configured into
+All ISA, and EISA boards that you want to use need to be configured into
 the driver(s). All PCI boards will be automatically detected when you load
 the driver - so they do not need to be entered into the driver(s)
 configuration structure. Note that kernel PCI support is required to use PCI
 boards.
 
-There are two methods of configuring ISA, EISA and MCA boards into the drivers.
+There are two methods of configuring ISA and EISA boards into the drivers.
 If using the driver as a loadable module then the simplest method is to pass
 the driver configuration as module arguments. The other method is to modify
 the driver source to add configuration lines for each board in use.
@@ -71,12 +71,12 @@ That makes things pretty simple to get going.
 2.1 MODULE DRIVER CONFIGURATION:
 
 The simplest configuration for modules is to use the module load arguments
-to configure any ISA, EISA or MCA boards. PCI boards are automatically
+to configure any ISA or EISA boards. PCI boards are automatically
 detected, so do not need any additional configuration at all.
 
-If using EasyIO, EasyConnection 8/32 ISA or MCA, or EasyConnection 8/63-PCI
+If using EasyIO, EasyConnection 8/32 ISA, or EasyConnection 8/63-PCI
 boards then use the "stallion" driver module, Otherwise if you are using
-an EasyConnection 8/64 ISA, EISA or MCA, EasyConnection/RA-PCI, ONboard,
+an EasyConnection 8/64 ISA or EISA, EasyConnection/RA-PCI, ONboard,
 Brumby or original Stallion board then use the "istallion" driver module.
 
 Typically to load up the smart board driver use:
@@ -146,7 +146,7 @@ on each system boot. Typically configuration files are put in the
 2.2 STATIC DRIVER CONFIGURATION:
 
 For static driver configuration you need to modify the driver source code.
-Entering ISA, EISA and MCA boards into the driver(s) configuration structure
+Entering ISA and EISA boards into the driver(s) configuration structure
 involves editing the driver(s) source file. It's pretty easy if you follow
 the instructions below. Both drivers can support up to 4 boards. The smart
 card driver (the stallion.c driver) supports any combination of EasyIO and
@@ -157,7 +157,7 @@ supports any combination of ONboards, Brumbys, Stallions and EasyConnection
 To set up the driver(s) for the boards that you want to use you need to
 edit the appropriate driver file and add configuration entries.
 
-If using EasyIO or EasyConnection 8/32 ISA or MCA boards,
+If using EasyIO or EasyConnection 8/32 ISA boards,
    In drivers/char/stallion.c:
       - find the definition of the stl_brdconf array (of structures)
         near the top of the file
@@ -243,7 +243,7 @@ change it on the board.
 On EasyIO and EasyConnection 8/32 boards the IRQ is software programmable, so
 if there is a conflict you may need to change the IRQ used for a board. There
 are no interrupts to worry about for ONboard, Brumby or EasyConnection 8/64
-(ISA, EISA and MCA) boards. The memory region on EasyConnection 8/64 and
+(ISA and EISA) boards. The memory region on EasyConnection 8/64 and
 ONboard boards is software programmable, but not on the Brumby boards.
 
 
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index 8c16d50f6cb6..221b81016dba 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -1545,7 +1545,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
 
     Module for sound cards based on the C-Media CMI8786/8787/8788 chip:
     * Asound A-8788
-    * Asus Xonar DG
+    * Asus Xonar DG/DGX
     * AuzenTech X-Meridian
     * AuzenTech X-Meridian 2G
     * Bgears b-Enspirer
diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt
index c83a835350f0..90e9b3a11abc 100644
--- a/Documentation/sound/alsa/compress_offload.txt
+++ b/Documentation/sound/alsa/compress_offload.txt
@@ -18,7 +18,7 @@ processing. Support for such hardware has not been very good in Linux,
 mostly because of a lack of a generic API available in the mainline
 kernel.
 
-Rather than requiring a compability break with an API change of the
+Rather than requiring a compatibility break with an API change of the
 ALSA PCM interface, a new 'Compressed Data' API is introduced to
 provide a control and data-streaming interface for audio DSPs.
 
diff --git a/Documentation/sound/oss/ALS b/Documentation/sound/oss/ALS
index d01ffbfd5808..bf10bed4574b 100644
--- a/Documentation/sound/oss/ALS
+++ b/Documentation/sound/oss/ALS
@@ -57,10 +57,10 @@ The resulting sound driver will provide the following capabilities:
     DSP/PCM/audio out (L&R), FM (L&R) and Mic in (mono).
 
 Jonathan Woithe
-jwoithe@physics.adelaide.edu.au
+jwoithe@just42.net
 30 March 1998
 
 Modified 2000-02-26 by Dave Forrest, drf5n@virginia.edu to add ALS100/ALS200
 Modified 2000-04-10 by Paul Laufer, pelaufer@csupomona.edu to add ISAPnP info.
-Modified 2000-11-19 by Jonathan Woithe, jwoithe@physics.adelaide.edu.au
+Modified 2000-11-19 by Jonathan Woithe, jwoithe@just42.net
  - updated information for kernel 2.4.x.
diff --git a/Documentation/sparc/README-2.5 b/Documentation/sparc/README-2.5
deleted file mode 100644
index 806fe490a56d..000000000000
--- a/Documentation/sparc/README-2.5
+++ /dev/null
@@ -1,46 +0,0 @@
-BTFIXUP
--------
-
-To build new kernels you have to issue "make image". The ready kernel
-in ELF format is placed in arch/sparc/boot/image. Explanation is below.
-
-BTFIXUP is a unique feature of Linux/sparc among other architectures,
-developed by Jakub Jelinek (I think... Obviously David S. Miller took
-part, too). It allows to boot the same kernel at different 
-sub-architectures, such as sun4c, sun4m, sun4d, where SunOS uses
-different kernels. This feature is convinient for people who you move
-disks between boxes and for distrution builders.
-
-To function, BTFIXUP must link the kernel "in the draft" first,
-analyze the result, write a special stub code based on that, and
-build the final kernel with the stub (btfix.o).
-
-Kai Germaschewski improved the build system of the kernel in the 2.5 series
-significantly. Unfortunately, the traditional way of running the draft
-linking from architecture specific Makefile before the actual linking
-by generic Makefile is nearly impossible to support properly in the
-new build system. Therefore, the way we integrate BTFIXUP with the
-build system was changed in 2.5.40. Now, generic Makefile performs
-the draft linking and stores the result in file vmlinux. Architecture
-specific post-processing invokes BTFIXUP machinery and final linking
-in the same way as other architectures do bootstraps.
-
-Implications of that change are as follows.
-
-1. Hackers must type "make image" now, instead of just "make", in the same
-   way as s390 people do now. It is analogous to "make bzImage" on i386.
-   This does NOT affect sparc64, you continue to use "make" to build sparc64
-   kernels.
-
-2. vmlinux is not the final kernel, so RPM builders have to adjust
-   their spec files (if they delivered vmlinux for debugging).
-   System.map generated for vmlinux is still valid.
-
-3. Scripts that produce a.out images have to be changed. First, if they
-   invoke make, they have to use "make image". Second, they have to pick up
-   the new kernel in arch/sparc/boot/image instead of vmlinux.
-
-4. Since we are compliant with Kai's build system now, make -j is permitted.
-
--- Pete Zaitcev
-zaitcev@yahoo.com
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index f0ab5cf28fca..4a7b54bd37e8 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -12,6 +12,12 @@ Rules on what kind of patches are accepted, and which ones are not, into the
    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
    security issue, or some "oh, that's not good" issue.  In short, something
    critical.
+ - Serious issues as reported by a user of a distribution kernel may also
+   be considered if they fix a notable performance or interactivity issue.
+   As these fixes are not as obvious and have a higher risk of a subtle
+   regression they should only be submitted by a distribution kernel
+   maintainer and include an addendum linking to a bugzilla entry if it
+   exists and additional information on the user-visible impact.
  - New device IDs and quirks are also accepted.
  - No "theoretical race condition" issues, unless an explanation of how the
    race can be exploited is also provided.
diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt
index d93f3c00f245..9f5263d3152c 100644
--- a/Documentation/static-keys.txt
+++ b/Documentation/static-keys.txt
@@ -235,7 +235,7 @@ label case adds:
 6 (mov) + 2 (test) + 2 (jne) = 10 - 5 (5 byte jump 0) = 5 addition bytes.
 
 If we then include the padding bytes, the jump label code saves, 16 total bytes
-of instruction memory for this small fucntion. In this case the non-jump label
+of instruction memory for this small function. In this case the non-jump label
 function is 80 bytes long. Thus, we have have saved 20% of the instruction
 footprint. We can in fact improve this even further, since the 5-byte no-op
 really can be a 2-byte no-op since we can reach the branch with a 2-byte jmp.
diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt
index 88fd7f5c8dcd..13d6166d7a27 100644
--- a/Documentation/sysctl/fs.txt
+++ b/Documentation/sysctl/fs.txt
@@ -225,6 +225,13 @@ a queue must be less or equal then msg_max.
 maximum  message size value (it is every  message queue's attribute set during
 its creation).
 
+/proc/sys/fs/mqueue/msg_default is  a read/write  file for setting/getting the
+default number of messages in a queue value if attr parameter of mq_open(2) is
+NULL. If it exceed msg_max, the default value is initialized msg_max.
+
+/proc/sys/fs/mqueue/msgsize_default is a read/write file for setting/getting
+the default message size value if attr parameter of mq_open(2) is NULL. If it
+exceed msgsize_max, the default value is initialized msgsize_max.
 
 4. /proc/sys/fs/epoll - Configuration options for the epoll interface
 --------------------------------------------------------
diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt
index 3201a7097e4d..98335b7a5337 100644
--- a/Documentation/sysctl/net.txt
+++ b/Documentation/sysctl/net.txt
@@ -43,6 +43,13 @@ Values :
         1 - enable the JIT
         2 - enable the JIT and ask the compiler to emit traces on kernel log.
 
+dev_weight
+--------------
+
+The maximum number of packets that kernel can handle on a NAPI interrupt,
+it's a Per-CPU variable.
+Default: 64
+
 rmem_default
 ------------
 
diff --git a/Documentation/trace/uprobetracer.txt b/Documentation/trace/uprobetracer.txt
new file mode 100644
index 000000000000..24ce6823a09e
--- /dev/null
+++ b/Documentation/trace/uprobetracer.txt
@@ -0,0 +1,113 @@
+                Uprobe-tracer: Uprobe-based Event Tracing
+                =========================================
+                 Documentation written by Srikar Dronamraju
+
+Overview
+--------
+Uprobe based trace events are similar to kprobe based trace events.
+To enable this feature, build your kernel with CONFIG_UPROBE_EVENT=y.
+
+Similar to the kprobe-event tracer, this doesn't need to be activated via
+current_tracer. Instead of that, add probe points via
+/sys/kernel/debug/tracing/uprobe_events, and enable it 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
+
+Synopsis of uprobe_tracer
+-------------------------
+  p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS]        : Set a probe
+
+ 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.
+
+ 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
+/sys/kernel/debug/tracing/uprobe_profile.
+ 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.
+
+  echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
+
+ This sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash
+
+  echo > /sys/kernel/debug/tracing/uprobe_events
+
+ This clears all probe points.
+
+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
+
+    # cd /sys/kernel/debug/tracing/
+    # 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 :
+
+    # echo 'p /bin/zsh:0x46420 %ip %ax' > uprobe_events
+
+Please note: User has to explicitly calculate the offset of the probepoint
+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
+
+The format of events can be seen by viewing the file events/uprobes/p_zsh_0x46420/format
+
+    # cat events/uprobes/p_zsh_0x46420/format
+    name: p_zsh_0x46420
+    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 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
+
+Right after definition, each event is disabled by default. For tracing these
+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
+
+And you can see the traced information via /sys/kernel/debug/tracing/trace.
+
+    # cat trace
+    # tracer: nop
+    #
+    #           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.
diff --git a/Documentation/usb/dwc3.txt b/Documentation/usb/dwc3.txt
index 7b590edae145..1d02c01d1c7c 100644
--- a/Documentation/usb/dwc3.txt
+++ b/Documentation/usb/dwc3.txt
@@ -28,7 +28,7 @@ Please pick something while reading :)
       none
 
     - primary handler of the EP-interrupt
-      reads the event and tries to process it. Everything that requries
+      reads the event and tries to process it. Everything that requires
       sleeping is handed over to the Thread. The event is saved in an
       per-endpoint data-structure.
       We probably have to pay attention not to process events once we
diff --git a/Documentation/usb/functionfs.txt b/Documentation/usb/functionfs.txt
new file mode 100644
index 000000000000..eaaaea019fc7
--- /dev/null
+++ b/Documentation/usb/functionfs.txt
@@ -0,0 +1,67 @@
+*How FunctionFS works*
+
+From kernel point of view it is just a composite function with some
+unique behaviour.  It may be added to an USB configuration only after
+the user space driver has registered by writing descriptors and
+strings (the user space program has to provide the same information
+that kernel level composite functions provide when they are added to
+the configuration).
+
+This in particular means that the composite initialisation functions
+may not be in init section (ie. may not use the __init tag).
+
+From user space point of view it is a file system which when
+mounted provides an "ep0" file.  User space driver need to
+write descriptors and strings to that file.  It does not need
+to worry about endpoints, interfaces or strings numbers but
+simply provide descriptors such as if the function was the
+only one (endpoints and strings numbers starting from one and
+interface numbers starting from zero).  The FunctionFS changes
+them as needed also handling situation when numbers differ in
+different configurations.
+
+When descriptors and strings are written "ep#" files appear
+(one for each declared endpoint) which handle communication on
+a single endpoint.  Again, FunctionFS takes care of the real
+numbers and changing of the configuration (which means that
+"ep1" file may be really mapped to (say) endpoint 3 (and when
+configuration changes to (say) endpoint 2)).  "ep0" is used
+for receiving events and handling setup requests.
+
+When all files are closed the function disables itself.
+
+What I also want to mention is that the FunctionFS is designed in such
+a way that it is possible to mount it several times so in the end
+a gadget could use several FunctionFS functions. The idea is that
+each FunctionFS instance is identified by the device name used
+when mounting.
+
+One can imagine a gadget that has an Ethernet, MTP and HID interfaces
+where the last two are implemented via FunctionFS.  On user space
+level it would look like this:
+
+$ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid
+$ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp
+$ ( cd /dev/ffs-mtp && mtp-daemon ) &
+$ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid
+$ ( cd /dev/ffs-hid && hid-daemon ) &
+
+On kernel level the gadget checks ffs_data->dev_name to identify
+whether it's FunctionFS designed for MTP ("mtp") or HID ("hid").
+
+If no "functions" module parameters is supplied, the driver accepts
+just one function with any name.
+
+When "functions" module parameter is supplied, only functions
+with listed names are accepted. In particular, if the "functions"
+parameter's value is just a one-element list, then the behaviour
+is similar to when there is no "functions" at all; however,
+only a function with the specified name is accepted.
+
+The gadget is registered only after all the declared function
+filesystems have been mounted and USB descriptors of all functions
+have been written to their ep0's.
+
+Conversely, the gadget is unregistered after the first USB function
+closes its endpoints.
+
diff --git a/Documentation/usb/wusb-cbaf b/Documentation/usb/wusb-cbaf
index 426ddaaef96f..8b3d43efce90 100644
--- a/Documentation/usb/wusb-cbaf
+++ b/Documentation/usb/wusb-cbaf
@@ -36,7 +36,7 @@ COMMAND/ARGS are
 
  get-cdid DEVICE
 
-   Get the device ID associated to the HOST-CHDI we sent with
+   Get the device ID associated to the HOST-CHID we sent with
    'set-chid'. We might not know about it.
 
  set-cc DEVICE
diff --git a/Documentation/video4linux/4CCs.txt b/Documentation/video4linux/4CCs.txt
new file mode 100644
index 000000000000..41241af1ebfe
--- /dev/null
+++ b/Documentation/video4linux/4CCs.txt
@@ -0,0 +1,32 @@
+Guidelines for Linux4Linux pixel format 4CCs
+============================================
+
+Guidelines for Video4Linux 4CC codes defined using v4l2_fourcc() are
+specified in this document. First of the characters defines the nature of
+the pixel format, compression and colour space. The interpretation of the
+other three characters depends on the first one.
+
+Existing 4CCs may not obey these guidelines.
+
+Formats
+=======
+
+Raw bayer
+---------
+
+The following first characters are used by raw bayer formats:
+
+        B: raw bayer, uncompressed
+        b: raw bayer, DPCM compressed
+        a: A-law compressed
+        u: u-law compressed
+
+2nd character: pixel order
+        B: BGGR
+        G: GBRG
+        g: GRBG
+        R: RGGB
+
+3rd character: uncompressed bits-per-pixel 0--9, A--
+
+4th character: compressed bits-per-pixel 0--9, A--
diff --git a/Documentation/video4linux/README.cpia2 b/Documentation/video4linux/README.cpia2
index ce8213d28b67..38e742fd0df7 100644
--- a/Documentation/video4linux/README.cpia2
+++ b/Documentation/video4linux/README.cpia2
@@ -12,7 +12,7 @@ gqcam application to view this stream.
         The driver is implemented as two kernel modules. The cpia2 module
 contains the camera functions and the V4L interface.  The cpia2_usb module
 contains usb specific functions.  The main reason for this was the size of the
-module was getting out of hand, so I separted them.  It is not likely that
+module was getting out of hand, so I separated them.  It is not likely that
 there will be a parallel port version.
 
 FEATURES:
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt
index e6c2842407a4..1e6b6531bbcc 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -276,6 +276,7 @@ pac7302		093a:2622	Genius Eye 312
 pac7302         093a:2624       PAC7302
 pac7302         093a:2625       Genius iSlim 310
 pac7302         093a:2626       Labtec 2200
+pac7302         093a:2627       Genius FaceCam 300
 pac7302         093a:2628       Genius iLook 300
 pac7302         093a:2629       Genious iSlim 300
 pac7302         093a:262a       Webcam 300k
diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt
index e2492a9d1027..43da22b89728 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -130,8 +130,18 @@ Menu controls are added by calling v4l2_ctrl_new_std_menu:
                         const struct v4l2_ctrl_ops *ops,
                         u32 id, s32 max, s32 skip_mask, s32 def);
 
+Or alternatively for integer menu controls, by calling v4l2_ctrl_new_int_menu:
+
+        struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl,
+                        const struct v4l2_ctrl_ops *ops,
+                        u32 id, s32 max, s32 def, const s64 *qmenu_int);
+
 These functions are typically called right after the v4l2_ctrl_handler_init:
 
+        static const s64 exp_bias_qmenu[] = {
+               -2, -1, 0, 1, 2
+        };
+
         v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls);
         v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops,
                         V4L2_CID_BRIGHTNESS, 0, 255, 1, 128);
@@ -141,6 +151,11 @@ These functions are typically called right after the v4l2_ctrl_handler_init:
                         V4L2_CID_POWER_LINE_FREQUENCY,
                         V4L2_CID_POWER_LINE_FREQUENCY_60HZ, 0,
                         V4L2_CID_POWER_LINE_FREQUENCY_DISABLED);
+        v4l2_ctrl_new_int_menu(&foo->ctrl_handler, &foo_ctrl_ops,
+                        V4L2_CID_EXPOSURE_BIAS,
+                        ARRAY_SIZE(exp_bias_qmenu) - 1,
+                        ARRAY_SIZE(exp_bias_qmenu) / 2 - 1,
+                        exp_bias_qmenu);
         ...
         if (foo->ctrl_handler.error) {
                 int err = foo->ctrl_handler.error;
@@ -164,6 +179,12 @@ controls. There is no min argument since that is always 0 for menu controls,
 and instead of a step there is a skip_mask argument: if bit X is 1, then menu
 item X is skipped.
 
+The v4l2_ctrl_new_int_menu function creates a new standard integer menu
+control with driver-specific items in the menu. It differs from
+v4l2_ctrl_new_std_menu in that it doesn't have the mask argument and takes
+as the last argument an array of signed 64-bit integers that form an exact
+menu item list.
+
 Note that if something fails, the function will return NULL or an error and
 set ctrl_handler->error to the error code. If ctrl_handler->error was already
 set, then it will just return and do nothing. This is also true for
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index 659b2ba12a4f..1f5905270050 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -182,11 +182,11 @@ static int __devinit drv_probe(struct pci_dev *pdev,
 }
 
 If you have multiple device nodes then it can be difficult to know when it is
-safe to unregister v4l2_device. For this purpose v4l2_device has refcounting
-support. The refcount is increased whenever video_register_device is called and
-it is decreased whenever that device node is released. When the refcount reaches
-zero, then the v4l2_device release() callback is called. You can do your final
-cleanup there.
+safe to unregister v4l2_device for hotpluggable devices. For this purpose
+v4l2_device has refcounting support. The refcount is increased whenever
+video_register_device is called and it is decreased whenever that device node
+is released. When the refcount reaches zero, then the v4l2_device release()
+callback is called. You can do your final cleanup there.
 
 If other device nodes (e.g. ALSA) are created, then you can increase and
 decrease the refcount manually as well by calling:
@@ -197,6 +197,10 @@ or:
 
 int v4l2_device_put(struct v4l2_device *v4l2_dev);
 
+Since the initial refcount is 1 you also need to call v4l2_device_put in the
+disconnect() callback (for USB devices) or in the remove() callback (for e.g.
+PCI devices), otherwise the refcount will never reach 0.
+
 struct v4l2_subdev
 ------------------
 
@@ -262,11 +266,16 @@ struct v4l2_subdev_video_ops {
         ...
 };
 
+struct v4l2_subdev_pad_ops {
+        ...
+};
+
 struct v4l2_subdev_ops {
         const struct v4l2_subdev_core_ops  *core;
         const struct v4l2_subdev_tuner_ops *tuner;
         const struct v4l2_subdev_audio_ops *audio;
         const struct v4l2_subdev_video_ops *video;
+        const struct v4l2_subdev_pad_ops *video;
 };
 
 The core ops are common to all subdevs, the other categories are implemented
@@ -303,6 +312,22 @@ Don't forget to cleanup the media entity before the sub-device is destroyed:
 
         media_entity_cleanup(&sd->entity);
 
+If the subdev driver intends to process video and integrate with the media
+framework, it must implement format related functionality using
+v4l2_subdev_pad_ops instead of v4l2_subdev_video_ops.
+
+In that case, the subdev driver may set the link_validate field to provide
+its own link validation function. The link validation function is called for
+every link in the pipeline where both of the ends of the links are V4L2
+sub-devices. The driver is still responsible for validating the correctness
+of the format configuration between sub-devices and video nodes.
+
+If link_validate op is not set, the default function
+v4l2_subdev_link_validate_default() is used instead. This function ensures
+that width, height and the media bus pixel code are equal on both source and
+sink of the link. Subdev drivers are also free to use this function to
+perform the checks mentioned above in addition to their own checks.
+
 A device (bridge) driver needs to register the v4l2_subdev with the
 v4l2_device:
 
@@ -555,19 +580,25 @@ allocated memory.
 You should also set these fields:
 
 - v4l2_dev: set to the v4l2_device parent device.
+
 - name: set to something descriptive and unique.
+
 - fops: set to the v4l2_file_operations struct.
+
 - ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance
   (highly recommended to use this and it might become compulsory in the
   future!), then set this to your v4l2_ioctl_ops struct.
+
 - lock: leave to NULL if you want to do all the locking in the driver.
-  Otherwise you give it a pointer to a struct mutex_lock and before any
-  of the v4l2_file_operations is called this lock will be taken by the
-  core and released afterwards.
+  Otherwise you give it a pointer to a struct mutex_lock and before the
+  unlocked_ioctl file operation is called this lock will be taken by the
+  core and released afterwards. See the next section for more details.
+
 - prio: keeps track of the priorities. Used to implement VIDIOC_G/S_PRIORITY.
   If left to NULL, then it will use the struct v4l2_prio_state in v4l2_device.
   If you want to have a separate priority state per (group of) device node(s),
   then you can point it to your own struct v4l2_prio_state.
+
 - parent: you only set this if v4l2_device was registered with NULL as
   the parent device struct. This only happens in cases where one hardware
   device has multiple PCI devices that all share the same v4l2_device core.
@@ -577,6 +608,7 @@ You should also set these fields:
   (cx8802). Since the v4l2_device cannot be associated with a particular
   PCI device it is setup without a parent device. But when the struct
   video_device is setup you do know which parent PCI device to use.
+
 - flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework
   handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct
   v4l2_fh. Eventually this flag will disappear once all drivers use the core
@@ -587,6 +619,16 @@ in your v4l2_file_operations struct.
 
 Do not use .ioctl! This is deprecated and will go away in the future.
 
+In some cases you want to tell the core that a function you had specified in
+your v4l2_ioctl_ops should be ignored. You can mark such ioctls by calling this
+function before video_device_register is called:
+
+void v4l2_disable_ioctl(struct video_device *vdev, unsigned int cmd);
+
+This tends to be needed if based on external factors (e.g. which card is
+being used) you want to turns off certain features in v4l2_ioctl_ops without
+having to make a new struct.
+
 The v4l2_file_operations struct is a subset of file_operations. The main
 difference is that the inode argument is omitted since it is never used.
 
@@ -609,8 +651,22 @@ v4l2_file_operations and locking
 --------------------------------
 
 You can set a pointer to a mutex_lock in struct video_device. Usually this
-will be either a top-level mutex or a mutex per device node. If you want
-finer-grained locking then you have to set it to NULL and do you own locking.
+will be either a top-level mutex or a mutex per device node. By default this
+lock will be used for unlocked_ioctl, but you can disable locking for
+selected ioctls by calling:
+
+        void v4l2_disable_ioctl_locking(struct video_device *vdev, unsigned int cmd);
+
+E.g.: v4l2_disable_ioctl_locking(vdev, VIDIOC_DQBUF);
+
+You have to call this before you register the video_device.
+
+Particularly with USB drivers where certain commands such as setting controls
+can take a long time you may want to do your own locking for the buffer queuing
+ioctls.
+
+If you want still finer-grained locking then you have to set mutex_lock to NULL
+and do you own locking completely.
 
 It is up to the driver developer to decide which method to use. However, if
 your driver has high-latency operations (for example, changing the exposure
@@ -618,7 +674,7 @@ of a USB webcam might take a long time), then you might be better off with
 doing your own locking if you want to allow the user to do other things with
 the device while waiting for the high-latency command to finish.
 
-If a lock is specified then all file operations will be serialized on that
+If a lock is specified then all ioctl commands will be serialized on that
 lock. If you use videobuf then you must pass the same lock to the videobuf
 queue initialize function: if videobuf has to wait for a frame to arrive, then
 it will temporarily unlock the lock and relock it afterwards. If your driver
@@ -941,21 +997,35 @@ fast.
 
 Useful functions:
 
-- v4l2_event_queue()
+void v4l2_event_queue(struct video_device *vdev, const struct v4l2_event *ev)
 
   Queue events to video device. The driver's only responsibility is to fill
   in the type and the data fields. The other fields will be filled in by
   V4L2.
 
-- v4l2_event_subscribe()
+int v4l2_event_subscribe(struct v4l2_fh *fh,
+                         struct v4l2_event_subscription *sub, unsigned elems,
+                         const struct v4l2_subscribed_event_ops *ops)
 
   The video_device->ioctl_ops->vidioc_subscribe_event must check the driver
   is able to produce events with specified event id. Then it calls
-  v4l2_event_subscribe() to subscribe the event. The last argument is the
-  size of the event queue for this event. If it is 0, then the framework
-  will fill in a default value (this depends on the event type).
+  v4l2_event_subscribe() to subscribe the event.
+
+  The elems argument is the size of the event queue for this event. If it is 0,
+  then the framework will fill in a default value (this depends on the event
+  type).
+
+  The ops argument allows the driver to specify a number of callbacks:
+  * add:     called when a new listener gets added (subscribing to the same
+             event twice will only cause this callback to get called once)
+  * del:     called when a listener stops listening
+  * replace: replace event 'old' with event 'new'.
+  * merge:   merge event 'old' into event 'new'.
+  All 4 callbacks are optional, if you don't want to specify any callbacks
+  the ops argument itself maybe NULL.
 
-- v4l2_event_unsubscribe()
+int v4l2_event_unsubscribe(struct v4l2_fh *fh,
+                           struct v4l2_event_subscription *sub)
 
   vidioc_unsubscribe_event in struct v4l2_ioctl_ops. A driver may use
   v4l2_event_unsubscribe() directly unless it wants to be involved in
@@ -964,7 +1034,7 @@ Useful functions:
   The special type V4L2_EVENT_ALL may be used to unsubscribe all events. The
   drivers may want to handle this in a special way.
 
-- v4l2_event_pending()
+int v4l2_event_pending(struct v4l2_fh *fh)
 
   Returns the number of pending events. Useful when implementing poll.
 
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 6386f8c0482e..2c9948379469 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2,6 +2,7 @@ The Definitive KVM (Kernel-based Virtual Machine) API Documentation
 ===================================================================
 
 1. General description
+----------------------
 
 The kvm API is a set of ioctls that are issued to control various aspects
 of a virtual machine.  The ioctls belong to three classes
@@ -23,7 +24,9 @@ of a virtual machine.  The ioctls belong to three classes
    Only run vcpu ioctls from the same thread that was used to create the
    vcpu.
 
+
 2. File descriptors
+-------------------
 
 The kvm API is centered around file descriptors.  An initial
 open("/dev/kvm") obtains a handle to the kvm subsystem; this handle
@@ -41,7 +44,9 @@ not cause harm to the host, their actual behavior is not guaranteed by
 the API.  The only supported use is one virtual machine per process,
 and one vcpu per thread.
 
+
 3. Extensions
+-------------
 
 As of Linux 2.6.22, the KVM ABI has been stabilized: no backward
 incompatible change are allowed.  However, there is an extension
@@ -53,7 +58,9 @@ Instead, kvm defines extension identifiers and a facility to query
 whether a particular extension identifier is available.  If it is, a
 set of ioctls is available for application use.
 
+
 4. API description
+------------------
 
 This section describes ioctls that can be used to control kvm guests.
 For each ioctl, the following information is provided along with a
@@ -75,6 +82,7 @@ description:
   Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)
       are not detailed, but errors with specific meanings are.
 
+
 4.1 KVM_GET_API_VERSION
 
 Capability: basic
@@ -90,6 +98,7 @@ supported.  Applications should refuse to run if KVM_GET_API_VERSION
 returns a value other than 12.  If this check passes, all ioctls
 described as 'basic' will be available.
 
+
 4.2 KVM_CREATE_VM
 
 Capability: basic
@@ -109,6 +118,7 @@ In order to create user controlled virtual machines on S390, check
 KVM_CAP_S390_UCONTROL and use the flag KVM_VM_S390_UCONTROL as
 privileged user (CAP_SYS_ADMIN).
 
+
 4.3 KVM_GET_MSR_INDEX_LIST
 
 Capability: basic
@@ -135,6 +145,7 @@ Note: if kvm indicates supports MCE (KVM_CAP_MCE), then the MCE bank MSRs are
 not returned in the MSR list, as different vcpus can have a different number
 of banks, as set via the KVM_X86_SETUP_MCE ioctl.
 
+
 4.4 KVM_CHECK_EXTENSION
 
 Capability: basic
@@ -149,6 +160,7 @@ receives an integer that describes the extension availability.
 Generally 0 means no and 1 means yes, but some extensions may report
 additional information in the integer return value.
 
+
 4.5 KVM_GET_VCPU_MMAP_SIZE
 
 Capability: basic
@@ -161,6 +173,7 @@ The KVM_RUN ioctl (cf.) communicates with userspace via a shared
 memory region.  This ioctl returns the size of that region.  See the
 KVM_RUN documentation for details.
 
+
 4.6 KVM_SET_MEMORY_REGION
 
 Capability: basic
@@ -171,6 +184,7 @@ Returns: 0 on success, -1 on error
 
 This ioctl is obsolete and has been removed.
 
+
 4.7 KVM_CREATE_VCPU
 
 Capability: basic
@@ -223,6 +237,7 @@ machines, the resulting vcpu fd can be memory mapped at page offset
 KVM_S390_SIE_PAGE_OFFSET in order to obtain a memory map of the virtual
 cpu's hardware control block.
 
+
 4.8 KVM_GET_DIRTY_LOG (vm ioctl)
 
 Capability: basic
@@ -246,6 +261,7 @@ since the last call to this ioctl.  Bit 0 is the first page in the
 memory slot.  Ensure the entire structure is cleared to avoid padding
 issues.
 
+
 4.9 KVM_SET_MEMORY_ALIAS
 
 Capability: basic
@@ -256,6 +272,7 @@ Returns: 0 (success), -1 (error)
 
 This ioctl is obsolete and has been removed.
 
+
 4.10 KVM_RUN
 
 Capability: basic
@@ -272,6 +289,7 @@ obtained by mmap()ing the vcpu fd at offset 0, with the size given by
 KVM_GET_VCPU_MMAP_SIZE.  The parameter block is formatted as a 'struct
 kvm_run' (see below).
 
+
 4.11 KVM_GET_REGS
 
 Capability: basic
@@ -292,6 +310,7 @@ struct kvm_regs {
         __u64 rip, rflags;
 };
 
+
 4.12 KVM_SET_REGS
 
 Capability: basic
@@ -304,6 +323,7 @@ Writes the general purpose registers into the vcpu.
 
 See KVM_GET_REGS for the data structure.
 
+
 4.13 KVM_GET_SREGS
 
 Capability: basic
@@ -331,6 +351,7 @@ interrupt_bitmap is a bitmap of pending external interrupts.  At most
 one bit may be set.  This interrupt has been acknowledged by the APIC
 but not yet injected into the cpu core.
 
+
 4.14 KVM_SET_SREGS
 
 Capability: basic
@@ -342,6 +363,7 @@ Returns: 0 on success, -1 on error
 Writes special registers into the vcpu.  See KVM_GET_SREGS for the
 data structures.
 
+
 4.15 KVM_TRANSLATE
 
 Capability: basic
@@ -365,6 +387,7 @@ struct kvm_translation {
         __u8  pad[5];
 };
 
+
 4.16 KVM_INTERRUPT
 
 Capability: basic
@@ -413,6 +436,7 @@ c) KVM_INTERRUPT_SET_LEVEL
 Note that any value for 'irq' other than the ones stated above is invalid
 and incurs unexpected behavior.
 
+
 4.17 KVM_DEBUG_GUEST
 
 Capability: basic
@@ -423,6 +447,7 @@ Returns: -1 on error
 
 Support for this has been removed.  Use KVM_SET_GUEST_DEBUG instead.
 
+
 4.18 KVM_GET_MSRS
 
 Capability: basic
@@ -451,6 +476,7 @@ Application code should set the 'nmsrs' member (which indicates the
 size of the entries array) and the 'index' member of each array entry.
 kvm will fill in the 'data' member.
 
+
 4.19 KVM_SET_MSRS
 
 Capability: basic
@@ -466,6 +492,7 @@ Application code should set the 'nmsrs' member (which indicates the
 size of the entries array), and the 'index' and 'data' members of each
 array entry.
 
+
 4.20 KVM_SET_CPUID
 
 Capability: basic
@@ -494,6 +521,7 @@ struct kvm_cpuid {
         struct kvm_cpuid_entry entries[0];
 };
 
+
 4.21 KVM_SET_SIGNAL_MASK
 
 Capability: basic
@@ -516,6 +544,7 @@ struct kvm_signal_mask {
         __u8  sigset[0];
 };
 
+
 4.22 KVM_GET_FPU
 
 Capability: basic
@@ -541,6 +570,7 @@ struct kvm_fpu {
         __u32 pad2;
 };
 
+
 4.23 KVM_SET_FPU
 
 Capability: basic
@@ -566,6 +596,7 @@ struct kvm_fpu {
         __u32 pad2;
 };
 
+
 4.24 KVM_CREATE_IRQCHIP
 
 Capability: KVM_CAP_IRQCHIP
@@ -579,6 +610,7 @@ ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
 local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
 only go to the IOAPIC.  On ia64, a IOSAPIC is created.
 
+
 4.25 KVM_IRQ_LINE
 
 Capability: KVM_CAP_IRQCHIP
@@ -600,6 +632,7 @@ struct kvm_irq_level {
         __u32 level;           /* 0 or 1 */
 };
 
+
 4.26 KVM_GET_IRQCHIP
 
 Capability: KVM_CAP_IRQCHIP
@@ -621,6 +654,7 @@ struct kvm_irqchip {
         } chip;
 };
 
+
 4.27 KVM_SET_IRQCHIP
 
 Capability: KVM_CAP_IRQCHIP
@@ -642,6 +676,7 @@ struct kvm_irqchip {
         } chip;
 };
 
+
 4.28 KVM_XEN_HVM_CONFIG
 
 Capability: KVM_CAP_XEN_HVM
@@ -666,6 +701,7 @@ struct kvm_xen_hvm_config {
         __u8 pad2[30];
 };
 
+
 4.29 KVM_GET_CLOCK
 
 Capability: KVM_CAP_ADJUST_CLOCK
@@ -684,6 +720,7 @@ struct kvm_clock_data {
         __u32 pad[9];
 };
 
+
 4.30 KVM_SET_CLOCK
 
 Capability: KVM_CAP_ADJUST_CLOCK
@@ -702,6 +739,7 @@ struct kvm_clock_data {
         __u32 pad[9];
 };
 
+
 4.31 KVM_GET_VCPU_EVENTS
 
 Capability: KVM_CAP_VCPU_EVENTS
@@ -741,6 +779,7 @@ struct kvm_vcpu_events {
 KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that
 interrupt.shadow contains a valid state. Otherwise, this field is undefined.
 
+
 4.32 KVM_SET_VCPU_EVENTS
 
 Capability: KVM_CAP_VCPU_EVENTS
@@ -767,6 +806,7 @@ If KVM_CAP_INTR_SHADOW is available, KVM_VCPUEVENT_VALID_SHADOW can be set in
 the flags field to signal that interrupt.shadow contains a valid state and
 shall be written into the VCPU.
 
+
 4.33 KVM_GET_DEBUGREGS
 
 Capability: KVM_CAP_DEBUGREGS
@@ -785,6 +825,7 @@ struct kvm_debugregs {
         __u64 reserved[9];
 };
 
+
 4.34 KVM_SET_DEBUGREGS
 
 Capability: KVM_CAP_DEBUGREGS
@@ -798,6 +839,7 @@ Writes debug registers into the vcpu.
 See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
 yet and must be cleared on entry.
 
+
 4.35 KVM_SET_USER_MEMORY_REGION
 
 Capability: KVM_CAP_USER_MEM
@@ -844,6 +886,7 @@ It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.
 The KVM_SET_MEMORY_REGION does not allow fine grained control over memory
 allocation and is deprecated.
 
+
 4.36 KVM_SET_TSS_ADDR
 
 Capability: KVM_CAP_SET_TSS_ADDR
@@ -862,6 +905,7 @@ This ioctl is required on Intel-based hosts.  This is needed on Intel hardware
 because of a quirk in the virtualization implementation (see the internals
 documentation when it pops into existence).
 
+
 4.37 KVM_ENABLE_CAP
 
 Capability: KVM_CAP_ENABLE_CAP
@@ -897,6 +941,7 @@ function properly, this is the place to put them.
        __u8  pad[64];
 };
 
+
 4.38 KVM_GET_MP_STATE
 
 Capability: KVM_CAP_MP_STATE
@@ -927,6 +972,7 @@ Possible values are:
 This ioctl is only useful after KVM_CREATE_IRQCHIP.  Without an in-kernel
 irqchip, the multiprocessing state must be maintained by userspace.
 
+
 4.39 KVM_SET_MP_STATE
 
 Capability: KVM_CAP_MP_STATE
@@ -941,6 +987,7 @@ arguments.
 This ioctl is only useful after KVM_CREATE_IRQCHIP.  Without an in-kernel
 irqchip, the multiprocessing state must be maintained by userspace.
 
+
 4.40 KVM_SET_IDENTITY_MAP_ADDR
 
 Capability: KVM_CAP_SET_IDENTITY_MAP_ADDR
@@ -959,6 +1006,7 @@ This ioctl is required on Intel-based hosts.  This is needed on Intel hardware
 because of a quirk in the virtualization implementation (see the internals
 documentation when it pops into existence).
 
+
 4.41 KVM_SET_BOOT_CPU_ID
 
 Capability: KVM_CAP_SET_BOOT_CPU_ID
@@ -971,6 +1019,7 @@ Define which vcpu is the Bootstrap Processor (BSP).  Values are the same
 as the vcpu id in KVM_CREATE_VCPU.  If this ioctl is not called, the default
 is vcpu 0.
 
+
 4.42 KVM_GET_XSAVE
 
 Capability: KVM_CAP_XSAVE
@@ -985,6 +1034,7 @@ struct kvm_xsave {
 
 This ioctl would copy current vcpu's xsave struct to the userspace.
 
+
 4.43 KVM_SET_XSAVE
 
 Capability: KVM_CAP_XSAVE
@@ -999,6 +1049,7 @@ struct kvm_xsave {
 
 This ioctl would copy userspace's xsave struct to the kernel.
 
+
 4.44 KVM_GET_XCRS
 
 Capability: KVM_CAP_XCRS
@@ -1022,6 +1073,7 @@ struct kvm_xcrs {
 
 This ioctl would copy current vcpu's xcrs to the userspace.
 
+
 4.45 KVM_SET_XCRS
 
 Capability: KVM_CAP_XCRS
@@ -1045,6 +1097,7 @@ struct kvm_xcrs {
 
 This ioctl would set vcpu's xcr to the value userspace specified.
 
+
 4.46 KVM_GET_SUPPORTED_CPUID
 
 Capability: KVM_CAP_EXT_CPUID
@@ -1119,6 +1172,7 @@ support.  Instead it is reported via
 if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the
 feature in userspace, then you can enable the feature for KVM_SET_CPUID2.
 
+
 4.47 KVM_PPC_GET_PVINFO
 
 Capability: KVM_CAP_PPC_GET_PVINFO
@@ -1142,6 +1196,7 @@ of 4 instructions that make up a hypercall.
 If any additional field gets added to this structure later on, a bit for that
 additional piece of information will be set in the flags bitmap.
 
+
 4.48 KVM_ASSIGN_PCI_DEVICE
 
 Capability: KVM_CAP_DEVICE_ASSIGNMENT
@@ -1185,6 +1240,7 @@ Only PCI header type 0 devices with PCI BAR resources are supported by
 device assignment.  The user requesting this ioctl must have read/write
 access to the PCI sysfs resource files associated with the device.
 
+
 4.49 KVM_DEASSIGN_PCI_DEVICE
 
 Capability: KVM_CAP_DEVICE_DEASSIGNMENT
@@ -1198,6 +1254,7 @@ Ends PCI device assignment, releasing all associated resources.
 See KVM_CAP_DEVICE_ASSIGNMENT for the data structure. Only assigned_dev_id is
 used in kvm_assigned_pci_dev to identify the device.
 
+
 4.50 KVM_ASSIGN_DEV_IRQ
 
 Capability: KVM_CAP_ASSIGN_DEV_IRQ
@@ -1231,6 +1288,7 @@ The following flags are defined:
 It is not valid to specify multiple types per host or guest IRQ. However, the
 IRQ type of host and guest can differ or can even be null.
 
+
 4.51 KVM_DEASSIGN_DEV_IRQ
 
 Capability: KVM_CAP_ASSIGN_DEV_IRQ
@@ -1245,6 +1303,7 @@ See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified
 by assigned_dev_id, flags must correspond to the IRQ type specified on
 KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed.
 
+
 4.52 KVM_SET_GSI_ROUTING
 
 Capability: KVM_CAP_IRQ_ROUTING
@@ -1293,6 +1352,7 @@ struct kvm_irq_routing_msi {
         __u32 pad;
 };
 
+
 4.53 KVM_ASSIGN_SET_MSIX_NR
 
 Capability: KVM_CAP_DEVICE_MSIX
@@ -1314,6 +1374,7 @@ struct kvm_assigned_msix_nr {
 
 #define KVM_MAX_MSIX_PER_DEV            256
 
+
 4.54 KVM_ASSIGN_SET_MSIX_ENTRY
 
 Capability: KVM_CAP_DEVICE_MSIX
@@ -1332,7 +1393,8 @@ struct kvm_assigned_msix_entry {
         __u16 padding[3];
 };
 
-4.54 KVM_SET_TSC_KHZ
+
+4.55 KVM_SET_TSC_KHZ
 
 Capability: KVM_CAP_TSC_CONTROL
 Architectures: x86
@@ -1343,7 +1405,8 @@ Returns: 0 on success, -1 on error
 Specifies the tsc frequency for the virtual machine. The unit of the
 frequency is KHz.
 
-4.55 KVM_GET_TSC_KHZ
+
+4.56 KVM_GET_TSC_KHZ
 
 Capability: KVM_CAP_GET_TSC_KHZ
 Architectures: x86
@@ -1355,7 +1418,8 @@ Returns the tsc frequency of the guest. The unit of the return value is
 KHz. If the host has unstable tsc this ioctl returns -EIO instead as an
 error.
 
-4.56 KVM_GET_LAPIC
+
+4.57 KVM_GET_LAPIC
 
 Capability: KVM_CAP_IRQCHIP
 Architectures: x86
@@ -1371,7 +1435,8 @@ struct kvm_lapic_state {
 Reads the Local APIC registers and copies them into the input argument.  The
 data format and layout are the same as documented in the architecture manual.
 
-4.57 KVM_SET_LAPIC
+
+4.58 KVM_SET_LAPIC
 
 Capability: KVM_CAP_IRQCHIP
 Architectures: x86
@@ -1387,7 +1452,8 @@ struct kvm_lapic_state {
 Copies the input argument into the the Local APIC registers.  The data format
 and layout are the same as documented in the architecture manual.
 
-4.58 KVM_IOEVENTFD
+
+4.59 KVM_IOEVENTFD
 
 Capability: KVM_CAP_IOEVENTFD
 Architectures: all
@@ -1417,7 +1483,8 @@ The following flags are defined:
 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.
 
-4.59 KVM_DIRTY_TLB
+
+4.60 KVM_DIRTY_TLB
 
 Capability: KVM_CAP_SW_TLB
 Architectures: ppc
@@ -1449,7 +1516,8 @@ The "num_dirty" field is a performance hint for KVM to determine whether it
 should skip processing the bitmap and just invalidate everything.  It must
 be set to the number of set bits in the bitmap.
 
-4.60 KVM_ASSIGN_SET_INTX_MASK
+
+4.61 KVM_ASSIGN_SET_INTX_MASK
 
 Capability: KVM_CAP_PCI_2_3
 Architectures: x86
@@ -1482,6 +1550,7 @@ See KVM_ASSIGN_DEV_IRQ for the data structure.  The target device is specified
 by assigned_dev_id.  In the flags field, only KVM_DEV_ASSIGN_MASK_INTX is
 evaluated.
 
+
 4.62 KVM_CREATE_SPAPR_TCE
 
 Capability: KVM_CAP_SPAPR_TCE
@@ -1517,6 +1586,7 @@ the entries written by kernel-handled H_PUT_TCE calls, and also lets
 userspace update the TCE table directly which is useful in some
 circumstances.
 
+
 4.63 KVM_ALLOCATE_RMA
 
 Capability: KVM_CAP_PPC_RMA
@@ -1549,6 +1619,7 @@ is supported; 2 if the processor requires all virtual machines to have
 an RMA, or 1 if the processor can use an RMA but doesn't require it,
 because it supports the Virtual RMA (VRMA) facility.
 
+
 4.64 KVM_NMI
 
 Capability: KVM_CAP_USER_NMI
@@ -1574,6 +1645,7 @@ following algorithm:
 Some guests configure the LINT1 NMI input to cause a panic, aiding in
 debugging.
 
+
 4.65 KVM_S390_UCAS_MAP
 
 Capability: KVM_CAP_S390_UCONTROL
@@ -1593,6 +1665,7 @@ This ioctl maps the memory at "user_addr" with the length "length" to
 the vcpu's address space starting at "vcpu_addr". All parameters need to
 be alligned by 1 megabyte.
 
+
 4.66 KVM_S390_UCAS_UNMAP
 
 Capability: KVM_CAP_S390_UCONTROL
@@ -1612,6 +1685,7 @@ This ioctl unmaps the memory in the vcpu's address space starting at
 "vcpu_addr" with the length "length". The field "user_addr" is ignored.
 All parameters need to be alligned by 1 megabyte.
 
+
 4.67 KVM_S390_VCPU_FAULT
 
 Capability: KVM_CAP_S390_UCONTROL
@@ -1628,6 +1702,7 @@ table upfront. This is useful to handle validity intercepts for user
 controlled virtual machines to fault in the virtual cpu's lowcore pages
 prior to calling the KVM_RUN ioctl.
 
+
 4.68 KVM_SET_ONE_REG
 
 Capability: KVM_CAP_ONE_REG
@@ -1653,6 +1728,7 @@ registers, find a list below:
         |                       |
   PPC   | KVM_REG_PPC_HIOR      | 64
 
+
 4.69 KVM_GET_ONE_REG
 
 Capability: KVM_CAP_ONE_REG
@@ -1669,7 +1745,210 @@ at the memory location pointed to by "addr".
 The list of registers accessible using this interface is identical to the
 list in 4.64.
 
+
+4.70 KVM_KVMCLOCK_CTRL
+
+Capability: KVM_CAP_KVMCLOCK_CTRL
+Architectures: Any that implement pvclocks (currently x86 only)
+Type: vcpu ioctl
+Parameters: None
+Returns: 0 on success, -1 on error
+
+This signals to the host kernel that the specified guest is being paused by
+userspace.  The host will set a flag in the pvclock structure that is checked
+from the soft lockup watchdog.  The flag is part of the pvclock structure that
+is shared between guest and host, specifically the second bit of the flags
+field of the pvclock_vcpu_time_info structure.  It will be set exclusively by
+the host and read/cleared exclusively by the guest.  The guest operation of
+checking and clearing the flag must an atomic operation so
+load-link/store-conditional, or equivalent must be used.  There are two cases
+where the guest will clear the flag: when the soft lockup watchdog timer resets
+itself or when a soft lockup is detected.  This ioctl can be called any time
+after pausing the vcpu, but before it is resumed.
+
+
+4.71 KVM_SIGNAL_MSI
+
+Capability: KVM_CAP_SIGNAL_MSI
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msi (in)
+Returns: >0 on delivery, 0 if guest blocked the MSI, and -1 on error
+
+Directly inject a MSI message. Only valid with in-kernel irqchip that handles
+MSI messages.
+
+struct kvm_msi {
+        __u32 address_lo;
+        __u32 address_hi;
+        __u32 data;
+        __u32 flags;
+        __u8  pad[16];
+};
+
+No flags are defined so far. The corresponding field must be 0.
+
+
+4.71 KVM_CREATE_PIT2
+
+Capability: KVM_CAP_PIT2
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_pit_config (in)
+Returns: 0 on success, -1 on error
+
+Creates an in-kernel device model for the i8254 PIT. This call is only valid
+after enabling in-kernel irqchip support via KVM_CREATE_IRQCHIP. The following
+parameters have to be passed:
+
+struct kvm_pit_config {
+        __u32 flags;
+        __u32 pad[15];
+};
+
+Valid flags are:
+
+#define KVM_PIT_SPEAKER_DUMMY     1 /* emulate speaker port stub */
+
+PIT timer interrupts may use a per-VM kernel thread for injection. If it
+exists, this thread will have a name of the following pattern:
+
+kvm-pit/<owner-process-pid>
+
+When running a guest with elevated priorities, the scheduling parameters of
+this thread may have to be adjusted accordingly.
+
+This IOCTL replaces the obsolete KVM_CREATE_PIT.
+
+
+4.72 KVM_GET_PIT2
+
+Capability: KVM_CAP_PIT_STATE2
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_pit_state2 (out)
+Returns: 0 on success, -1 on error
+
+Retrieves the state of the in-kernel PIT model. Only valid after
+KVM_CREATE_PIT2. The state is returned in the following structure:
+
+struct kvm_pit_state2 {
+        struct kvm_pit_channel_state channels[3];
+        __u32 flags;
+        __u32 reserved[9];
+};
+
+Valid flags are:
+
+/* disable PIT in HPET legacy mode */
+#define KVM_PIT_FLAGS_HPET_LEGACY  0x00000001
+
+This IOCTL replaces the obsolete KVM_GET_PIT.
+
+
+4.73 KVM_SET_PIT2
+
+Capability: KVM_CAP_PIT_STATE2
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_pit_state2 (in)
+Returns: 0 on success, -1 on error
+
+Sets the state of the in-kernel PIT model. Only valid after KVM_CREATE_PIT2.
+See KVM_GET_PIT2 for details on struct kvm_pit_state2.
+
+This IOCTL replaces the obsolete KVM_SET_PIT.
+
+
+4.74 KVM_PPC_GET_SMMU_INFO
+
+Capability: KVM_CAP_PPC_GET_SMMU_INFO
+Architectures: powerpc
+Type: vm ioctl
+Parameters: None
+Returns: 0 on success, -1 on error
+
+This populates and returns a structure describing the features of
+the "Server" class MMU emulation supported by KVM.
+This can in turn be used by userspace to generate the appropariate
+device-tree properties for the guest operating system.
+
+The structure contains some global informations, followed by an
+array of supported segment page sizes:
+
+      struct kvm_ppc_smmu_info {
+             __u64 flags;
+             __u32 slb_size;
+             __u32 pad;
+             struct kvm_ppc_one_seg_page_size sps[KVM_PPC_PAGE_SIZES_MAX_SZ];
+      };
+
+The supported flags are:
+
+    - KVM_PPC_PAGE_SIZES_REAL:
+        When that flag is set, guest page sizes must "fit" the backing
+        store page sizes. When not set, any page size in the list can
+        be used regardless of how they are backed by userspace.
+
+    - KVM_PPC_1T_SEGMENTS
+        The emulated MMU supports 1T segments in addition to the
+        standard 256M ones.
+
+The "slb_size" field indicates how many SLB entries are supported
+
+The "sps" array contains 8 entries indicating the supported base
+page sizes for a segment in increasing order. Each entry is defined
+as follow:
+
+   struct kvm_ppc_one_seg_page_size {
+        __u32 page_shift;       /* Base page shift of segment (or 0) */
+        __u32 slb_enc;          /* SLB encoding for BookS */
+        struct kvm_ppc_one_page_size enc[KVM_PPC_PAGE_SIZES_MAX_SZ];
+   };
+
+An entry with a "page_shift" of 0 is unused. Because the array is
+organized in increasing order, a lookup can stop when encoutering
+such an entry.
+
+The "slb_enc" field provides the encoding to use in the SLB for the
+page size. The bits are in positions such as the value can directly
+be OR'ed into the "vsid" argument of the slbmte instruction.
+
+The "enc" array is a list which for each of those segment base page
+size provides the list of supported actual page sizes (which can be
+only larger or equal to the base page size), along with the
+corresponding encoding in the hash PTE. Similarily, the array is
+8 entries sorted by increasing sizes and an entry with a "0" shift
+is an empty entry and a terminator:
+
+   struct kvm_ppc_one_page_size {
+        __u32 page_shift;       /* Page shift (or 0) */
+        __u32 pte_enc;          /* Encoding in the HPTE (>>12) */
+   };
+
+The "pte_enc" field provides a value that can OR'ed into the hash
+PTE's RPN field (ie, it needs to be shifted left by 12 to OR it
+into the hash PTE second double word).
+
+4.75 KVM_IRQFD
+
+Capability: KVM_CAP_IRQFD
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_irqfd (in)
+Returns: 0 on success, -1 on error
+
+Allows setting an eventfd to directly trigger a guest interrupt.
+kvm_irqfd.fd specifies the file descriptor to use as the eventfd and
+kvm_irqfd.gsi specifies the irqchip pin toggled by this event.  When
+an event is tiggered on the eventfd, an interrupt is injected into
+the guest using the specified gsi pin.  The irqfd is removed using
+the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
+and kvm_irqfd.gsi.
+
+
 5. The kvm_run structure
+------------------------
 
 Application code obtains a pointer to the kvm_run structure by
 mmap()ing a vcpu fd.  From that point, application code can control
@@ -1910,7 +2189,9 @@ and usually define the validity of a groups of registers. (e.g. one bit
 
 };
 
+
 6. Capabilities that can be enabled
+-----------------------------------
 
 There are certain capabilities that change the behavior of the virtual CPU when
 enabled. To enable them, please see section 4.37. Below you can find a list of
@@ -1926,6 +2207,7 @@ The following information is provided along with the description:
   Returns: the return value.  General error numbers (EBADF, ENOMEM, EINVAL)
       are not detailed, but errors with specific meanings are.
 
+
 6.1 KVM_CAP_PPC_OSI
 
 Architectures: ppc
@@ -1939,6 +2221,7 @@ between the guest and the host.
 
 When this capability is enabled, KVM_EXIT_OSI can occur.
 
+
 6.2 KVM_CAP_PPC_PAPR
 
 Architectures: ppc
@@ -1957,6 +2240,7 @@ HTAB invisible to the guest.
 
 When this capability is enabled, KVM_EXIT_PAPR_HCALL can occur.
 
+
 6.3 KVM_CAP_SW_TLB
 
 Architectures: ppc
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
index 882068538c9c..83afe65d4966 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -10,11 +10,15 @@ a guest.
 KVM cpuid functions are:
 
 function: KVM_CPUID_SIGNATURE (0x40000000)
-returns : eax = 0,
+returns : eax = 0x40000001,
           ebx = 0x4b4d564b,
           ecx = 0x564b4d56,
           edx = 0x4d.
 Note that this value in ebx, ecx and edx corresponds to the string "KVMKVMKVM".
+The value in eax corresponds to the maximum cpuid function present in this leaf,
+and will be updated if more functions are added in the future.
+Note also that old hosts set eax value to 0x0. This should
+be interpreted as if the value was 0x40000001.
 This function queries the presence of KVM cpuid leafs.
 
 
diff --git a/Documentation/virtual/kvm/msr.txt b/Documentation/virtual/kvm/msr.txt
index 50317809113d..96b41bd97523 100644
--- a/Documentation/virtual/kvm/msr.txt
+++ b/Documentation/virtual/kvm/msr.txt
@@ -109,6 +109,10 @@ MSR_KVM_SYSTEM_TIME_NEW:  0x4b564d01
                      0      |      24      | multiple cpus are guaranteed to
                             |              | be monotonic
                 -------------------------------------------------------------
+                            |              | guest vcpu has been paused by
+                     1      |     N/A      | the host
+                            |              | See 4.70 in api.txt
+                -------------------------------------------------------------
 
         Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid
         leaf prior to usage.
diff --git a/Documentation/virtual/virtio-spec.txt b/Documentation/virtual/virtio-spec.txt
index da094737e2f8..0d6ec85481cb 100644
--- a/Documentation/virtual/virtio-spec.txt
+++ b/Documentation/virtual/virtio-spec.txt
@@ -1,11 +1,11 @@
 [Generated file: see http://ozlabs.org/~rusty/virtio-spec/]
 Virtio PCI Card Specification
-v0.9.1 DRAFT
+v0.9.5 DRAFT
 -
 
-Rusty Russell <rusty@rustcorp.com.au>IBM Corporation (Editor)
+Rusty Russell <rusty@rustcorp.com.au> IBM Corporation (Editor)
 
-2011 August 1.
+2012 May 7.
 
 Purpose and Description
 
@@ -68,11 +68,11 @@ and consists of three parts:
 +-------------------+-----------------------------------+-----------+
 
 
-When the driver wants to send buffers to the device, it puts them
-in one or more slots in the descriptor table, and writes the
-descriptor indices into the available ring. It then notifies the
-device. When the device has finished with the buffers, it writes
-the descriptors into the used ring, and sends an interrupt.
+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
 
@@ -106,8 +106,14 @@ for informational purposes by the guest).
 +----------------------+--------------------+---------------+
 |          6           |     ioMemory       |       -       |
 +----------------------+--------------------+---------------+
+|          7           |       rpmsg        |  Appendix H   |
++----------------------+--------------------+---------------+
+|          8           |     SCSI host      |  Appendix I   |
++----------------------+--------------------+---------------+
 |          9           |   9P transport     |       -       |
 +----------------------+--------------------+---------------+
+|         10           |   mac80211 wlan    |       -       |
++----------------------+--------------------+---------------+
 
 
   Device Configuration
@@ -127,7 +133,7 @@ Note that this is possible because while the virtio header is PCI
 the native endian of the guest (where such distinction is
 applicable).
 
-  Device Initialization Sequence
+  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.
@@ -177,7 +183,10 @@ The virtio header looks as follows:
 
 
 If MSI-X is enabled for the device, two additional fields
-immediately follow this header:
+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!
+]
 
 
 +------------++----------------+--------+
@@ -191,20 +200,6 @@ immediately follow this header:
 +------------++----------------+--------+
 
 
-Finally, if feature bits (VIRTIO_F_FEATURES_HI) this is
-immediately followed by two additional fields:
-
-
-+------------++----------------------+----------------------
-| Bits       || 32                   | 32
-+------------++----------------------+----------------------
-| Read/Write || R                    | R+W
-+------------++----------------------+----------------------
-| Purpose    || Device               | Guest
-|            || Features bits 32:63  | Features bits 32:63
-+------------++----------------------+----------------------
-
-
 Immediately following these general headers, there may be
 device-specific headers:
 
@@ -238,31 +233,25 @@ at least one bit should be set:
   may be a significant (or infinite) delay before setting this
   bit.
 
-  DRIVER_OK (3) Indicates that the driver is set up and ready to
+  DRIVER_OK (4) Indicates that the driver is set up and ready to
   drive the device.
 
-  FAILED (8) Indicates that something went wrong in the guest,
+  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
+  Feature Bits<sub:Feature-Bits>
 
-The least significant 31 bits of the first configuration field
-indicates the features that the device supports (the high bit is
-reserved, and will be used to indicate the presence of future
-feature bits elsewhere). If more than 31 feature bits are
-supported, the device indicates so by setting feature bit 31 (see
-[cha:Reserved-Feature-Bits]). The bits are allocated as follows:
+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 40 Feature bits reserved for extensions to the queue and
+  24 to 32 Feature bits reserved for extensions to the queue and
   feature negotiation mechanisms
 
-  41 to 63 Feature bits reserved for future extensions
-
 For example, feature bit 0 for a network device (i.e. Subsystem
 Device ID 1) indicates that the device supports checksumming of
 packets.
@@ -286,10 +275,6 @@ 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).
 
-Access to feature bits 32 to 63 is enabled by Guest by setting
-feature bit 31. If this bit is unset, Device must assume that all
-feature bits > 31 are unset.
-
   Configuration/Queue Vectors
 
 When MSI-X capability is present and enabled in the device
@@ -324,7 +309,7 @@ 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
+  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
@@ -587,7 +572,7 @@ 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
+  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
@@ -813,7 +798,7 @@ vring.used->ring[vq->last_seen_used%vsz];
 
 }
 
-  Dealing With Configuration Changes
+  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
@@ -1260,18 +1245,6 @@ Currently there are five device-independent feature bits defined:
   driver should ignore the used_event field; the device should
   ignore the avail_event field; the flags field is used
 
-  VIRTIO_F_BAD_FEATURE(30) This feature should never be
-  negotiated by the guest; doing so is an indication that the
-  guest is faulty[footnote:
-An experimental virtio PCI driver contained in Linux version
-2.6.25 had this problem, and this feature bit can be used to
-detect it.
-]
-
-  VIRTIO_F_FEATURES_HIGH(31) This feature indicates that the
-  device supports feature bits 32:63. If unset, feature bits
-  32:63 are unset.
-
 Appendix C: Network Device
 
 The virtio network device is a virtual ethernet card, and is the
@@ -1335,11 +1308,17 @@ were required.
 
   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. Only one bit is
-  currently defined for the status field: VIRTIO_NET_S_LINK_UP. #define VIRTIO_NET_S_LINK_UP    1
+  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
 
 
 
@@ -1377,12 +1356,19 @@ struct virtio_net_config {
   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, 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
+  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.
 ]
@@ -1403,7 +1389,7 @@ segmentation, if both guests are amenable.
 
 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 preceded by a header:
+case, the packet itself is preceeded by a header:
 
 struct virtio_net_hdr {
 
@@ -1462,9 +1448,10 @@ 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 will be 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.
+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
@@ -1483,8 +1470,8 @@ Due to various bugs in implementations, this field is not useful
 as a guarantee of the transport header size.
 ]
 
-  gso_size is the size of the packet beyond that header (ie.
-    MSS).
+  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,
@@ -1567,7 +1554,9 @@ Processing packet involves:
   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
+  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
@@ -1642,7 +1631,7 @@ struct virtio_net_ctrl_mac {
 
 The device can filter incoming packets by any number of
 destination MAC addresses.[footnote:
-Since there are no guarantees, it can use a hash filter
+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
@@ -1665,6 +1654,38 @@ can control a VLAN filter table in the device.
 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.
@@ -1699,8 +1720,6 @@ device except where noted.
 
   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
@@ -1743,8 +1762,6 @@ device except where noted.
   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
@@ -1805,7 +1822,7 @@ 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 preceding requests must be complete before
+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
@@ -2118,7 +2135,7 @@ This is historical, and independent of the guest page size
 
   Otherwise, the guest may begin to re-use pages previously given
     to the balloon before the device has acknowledged their
-    withdrawal. [footnote:
+    withdrawl. [footnote:
 In this case, deflation advice is merely a courtesy
 ]
 
@@ -2198,3 +2215,996 @@ as follows:
   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/frontswap.txt b/Documentation/vm/frontswap.txt
new file mode 100644
index 000000000000..37067cf455f4
--- /dev/null
+++ b/Documentation/vm/frontswap.txt
@@ -0,0 +1,278 @@
+Frontswap provides a "transcendent memory" interface for swap pages.
+In some environments, dramatic performance savings may be obtained because
+swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
+
+(Note, frontswap -- and cleancache (merged at 3.0) -- are the "frontends"
+and the only necessary changes to the core kernel for transcendent memory;
+all other supporting code -- the "backends" -- is implemented as drivers.
+See the LWN.net article "Transcendent memory in a nutshell" for a detailed
+overview of frontswap and related kernel parts:
+https://lwn.net/Articles/454795/ )
+
+Frontswap is so named because it can be thought of as the opposite of
+a "backing" store for a swap device.  The storage is assumed to be
+a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming
+to the requirements of transcendent memory (such as Xen's "tmem", or
+in-kernel compressed memory, aka "zcache", or future RAM-like devices);
+this pseudo-RAM device is not directly accessible or addressable by the
+kernel and is of unknown and possibly time-varying size.  The driver
+links itself to frontswap by calling frontswap_register_ops to set the
+frontswap_ops funcs appropriately and the functions it provides must
+conform to certain policies as follows:
+
+An "init" prepares the device to receive frontswap pages associated
+with the specified swap device number (aka "type").  A "store" will
+copy the page to transcendent memory and associate it with the type and
+offset associated with the page. A "load" will copy the page, if found,
+from transcendent memory into kernel memory, but will NOT remove the page
+from from transcendent memory.  An "invalidate_page" will remove the page
+from transcendent memory and an "invalidate_area" will remove ALL pages
+associated with the swap type (e.g., like swapoff) and notify the "device"
+to refuse further stores with that swap type.
+
+Once a page is successfully stored, a matching load on the page will normally
+succeed.  So when the kernel finds itself in a situation where it needs
+to swap out a page, it first attempts to use frontswap.  If the store returns
+success, the data has been successfully saved to transcendent memory and
+a disk write and, if the data is later read back, a disk read are avoided.
+If a store returns failure, transcendent memory has rejected the data, and the
+page can be written to swap as usual.
+
+If a backend chooses, frontswap can be configured as a "writethrough
+cache" by calling frontswap_writethrough().  In this mode, the reduction
+in swap device writes is lost (and also a non-trivial performance advantage)
+in order to allow the backend to arbitrarily "reclaim" space used to
+store frontswap pages to more completely manage its memory usage.
+
+Note that if a page is stored and the page already exists in transcendent memory
+(a "duplicate" store), either the store succeeds and the data is overwritten,
+or the store fails AND the page is invalidated.  This ensures stale data may
+never be obtained from frontswap.
+
+If properly configured, monitoring of frontswap is done via debugfs in
+the /sys/kernel/debug/frontswap directory.  The effectiveness of
+frontswap can be measured (across all swap devices) with:
+
+failed_stores   - how many store attempts have failed
+loads           - how many loads were attempted (all should succeed)
+succ_stores     - how many store attempts have succeeded
+invalidates     - how many invalidates were attempted
+
+A backend implementation may provide additional metrics.
+
+FAQ
+
+1) Where's the value?
+
+When a workload starts swapping, performance falls through the floor.
+Frontswap significantly increases performance in many such workloads by
+providing a clean, dynamic interface to read and write swap pages to
+"transcendent memory" that is otherwise not directly addressable to the kernel.
+This interface is ideal when data is transformed to a different form
+and size (such as with compression) or secretly moved (as might be
+useful for write-balancing for some RAM-like devices).  Swap pages (and
+evicted page-cache pages) are a great use for this kind of slower-than-RAM-
+but-much-faster-than-disk "pseudo-RAM device" and the frontswap (and
+cleancache) interface to transcendent memory provides a nice way to read
+and write -- and indirectly "name" -- the pages.
+
+Frontswap -- and cleancache -- with a fairly small impact on the kernel,
+provides a huge amount of flexibility for more dynamic, flexible RAM
+utilization in various system configurations:
+
+In the single kernel case, aka "zcache", pages are compressed and
+stored in local memory, thus increasing the total anonymous pages
+that can be safely kept in RAM.  Zcache essentially trades off CPU
+cycles used in compression/decompression for better memory utilization.
+Benchmarks have shown little or no impact when memory pressure is
+low while providing a significant performance improvement (25%+)
+on some workloads under high memory pressure.
+
+"RAMster" builds on zcache by adding "peer-to-peer" transcendent memory
+support for clustered systems.  Frontswap pages are locally compressed
+as in zcache, but then "remotified" to another system's RAM.  This
+allows RAM to be dynamically load-balanced back-and-forth as needed,
+i.e. when system A is overcommitted, it can swap to system B, and
+vice versa.  RAMster can also be configured as a memory server so
+many servers in a cluster can swap, dynamically as needed, to a single
+server configured with a large amount of RAM... without pre-configuring
+how much of the RAM is available for each of the clients!
+
+In the virtual case, the whole point of virtualization is to statistically
+multiplex physical resources acrosst the varying demands of multiple
+virtual machines.  This is really hard to do with RAM and efforts to do
+it well with no kernel changes have essentially failed (except in some
+well-publicized special-case workloads).
+Specifically, the Xen Transcendent Memory backend allows otherwise
+"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
+virtual machines, but the pages can be compressed and deduplicated to
+optimize RAM utilization.  And when guest OS's are induced to surrender
+underutilized RAM (e.g. with "selfballooning"), sudden unexpected
+memory pressure may result in swapping; frontswap allows those pages
+to be swapped to and from hypervisor RAM (if overall host system memory
+conditions allow), thus mitigating the potentially awful performance impact
+of unplanned swapping.
+
+A KVM implementation is underway and has been RFC'ed to lkml.  And,
+using frontswap, investigation is also underway on the use of NVM as
+a memory extension technology.
+
+2) Sure there may be performance advantages in some situations, but
+   what's the space/time overhead of frontswap?
+
+If CONFIG_FRONTSWAP is disabled, every frontswap hook compiles into
+nothingness and the only overhead is a few extra bytes per swapon'ed
+swap device.  If CONFIG_FRONTSWAP is enabled but no frontswap "backend"
+registers, there is one extra global variable compared to zero for
+every swap page read or written.  If CONFIG_FRONTSWAP is enabled
+AND a frontswap backend registers AND the backend fails every "store"
+request (i.e. provides no memory despite claiming it might),
+CPU overhead is still negligible -- and since every frontswap fail
+precedes a swap page write-to-disk, the system is highly likely
+to be I/O bound and using a small fraction of a percent of a CPU
+will be irrelevant anyway.
+
+As for space, if CONFIG_FRONTSWAP is enabled AND a frontswap backend
+registers, one bit is allocated for every swap page for every swap
+device that is swapon'd.  This is added to the EIGHT bits (which
+was sixteen until about 2.6.34) that the kernel already allocates
+for every swap page for every swap device that is swapon'd.  (Hugh
+Dickins has observed that frontswap could probably steal one of
+the existing eight bits, but let's worry about that minor optimization
+later.)  For very large swap disks (which are rare) on a standard
+4K pagesize, this is 1MB per 32GB swap.
+
+When swap pages are stored in transcendent memory instead of written
+out to disk, there is a side effect that this may create more memory
+pressure that can potentially outweigh the other advantages.  A
+backend, such as zcache, must implement policies to carefully (but
+dynamically) manage memory limits to ensure this doesn't happen.
+
+3) OK, how about a quick overview of what this frontswap patch does
+   in terms that a kernel hacker can grok?
+
+Let's assume that a frontswap "backend" has registered during
+kernel initialization; this registration indicates that this
+frontswap backend has access to some "memory" that is not directly
+accessible by the kernel.  Exactly how much memory it provides is
+entirely dynamic and random.
+
+Whenever a swap-device is swapon'd frontswap_init() is called,
+passing the swap device number (aka "type") as a parameter.
+This notifies frontswap to expect attempts to "store" swap pages
+associated with that number.
+
+Whenever the swap subsystem is readying a page to write to a swap
+device (c.f swap_writepage()), frontswap_store is called.  Frontswap
+consults with the frontswap backend and if the backend says it does NOT
+have room, frontswap_store returns -1 and the kernel swaps the page
+to the swap device as normal.  Note that the response from the frontswap
+backend is unpredictable to the kernel; it may choose to never accept a
+page, it could accept every ninth page, or it might accept every
+page.  But if the backend does accept a page, the data from the page
+has already been copied and associated with the type and offset,
+and the backend guarantees the persistence of the data.  In this case,
+frontswap sets a bit in the "frontswap_map" for the swap device
+corresponding to the page offset on the swap device to which it would
+otherwise have written the data.
+
+When the swap subsystem needs to swap-in a page (swap_readpage()),
+it first calls frontswap_load() which checks the frontswap_map to
+see if the page was earlier accepted by the frontswap backend.  If
+it was, the page of data is filled from the frontswap backend and
+the swap-in is complete.  If not, the normal swap-in code is
+executed to obtain the page of data from the real swap device.
+
+So every time the frontswap backend accepts a page, a swap device read
+and (potentially) a swap device write are replaced by a "frontswap backend
+store" and (possibly) a "frontswap backend loads", which are presumably much
+faster.
+
+4) Can't frontswap be configured as a "special" swap device that is
+   just higher priority than any real swap device (e.g. like zswap,
+   or maybe swap-over-nbd/NFS)?
+
+No.  First, the existing swap subsystem doesn't allow for any kind of
+swap hierarchy.  Perhaps it could be rewritten to accomodate a hierarchy,
+but this would require fairly drastic changes.  Even if it were
+rewritten, the existing swap subsystem uses the block I/O layer which
+assumes a swap device is fixed size and any page in it is linearly
+addressable.  Frontswap barely touches the existing swap subsystem,
+and works around the constraints of the block I/O subsystem to provide
+a great deal of flexibility and dynamicity.
+
+For example, the acceptance of any swap page by the frontswap backend is
+entirely unpredictable. This is critical to the definition of frontswap
+backends because it grants completely dynamic discretion to the
+backend.  In zcache, one cannot know a priori how compressible a page is.
+"Poorly" compressible pages can be rejected, and "poorly" can itself be
+defined dynamically depending on current memory constraints.
+
+Further, frontswap is entirely synchronous whereas a real swap
+device is, by definition, asynchronous and uses block I/O.  The
+block I/O layer is not only unnecessary, but may perform "optimizations"
+that are inappropriate for a RAM-oriented device including delaying
+the write of some pages for a significant amount of time.  Synchrony is
+required to ensure the dynamicity of the backend and to avoid thorny race
+conditions that would unnecessarily and greatly complicate frontswap
+and/or the block I/O subsystem.  That said, only the initial "store"
+and "load" operations need be synchronous.  A separate asynchronous thread
+is free to manipulate the pages stored by frontswap.  For example,
+the "remotification" thread in RAMster uses standard asynchronous
+kernel sockets to move compressed frontswap pages to a remote machine.
+Similarly, a KVM guest-side implementation could do in-guest compression
+and use "batched" hypercalls.
+
+In a virtualized environment, the dynamicity allows the hypervisor
+(or host OS) to do "intelligent overcommit".  For example, it can
+choose to accept pages only until host-swapping might be imminent,
+then force guests to do their own swapping.
+
+There is a downside to the transcendent memory specifications for
+frontswap:  Since any "store" might fail, there must always be a real
+slot on a real swap device to swap the page.  Thus frontswap must be
+implemented as a "shadow" to every swapon'd device with the potential
+capability of holding every page that the swap device might have held
+and the possibility that it might hold no pages at all.  This means
+that frontswap cannot contain more pages than the total of swapon'd
+swap devices.  For example, if NO swap device is configured on some
+installation, frontswap is useless.  Swapless portable devices
+can still use frontswap but a backend for such devices must configure
+some kind of "ghost" swap device and ensure that it is never used.
+
+5) Why this weird definition about "duplicate stores"?  If a page
+   has been previously successfully stored, can't it always be
+   successfully overwritten?
+
+Nearly always it can, but no, sometimes it cannot.  Consider an example
+where data is compressed and the original 4K page has been compressed
+to 1K.  Now an attempt is made to overwrite the page with data that
+is non-compressible and so would take the entire 4K.  But the backend
+has no more space.  In this case, the store must be rejected.  Whenever
+frontswap rejects a store that would overwrite, it also must invalidate
+the old data and ensure that it is no longer accessible.  Since the
+swap subsystem then writes the new data to the read swap device,
+this is the correct course of action to ensure coherency.
+
+6) What is frontswap_shrink for?
+
+When the (non-frontswap) swap subsystem swaps out a page to a real
+swap device, that page is only taking up low-value pre-allocated disk
+space.  But if frontswap has placed a page in transcendent memory, that
+page may be taking up valuable real estate.  The frontswap_shrink
+routine allows code outside of the swap subsystem to force pages out
+of the memory managed by frontswap and back into kernel-addressable memory.
+For example, in RAMster, a "suction driver" thread will attempt
+to "repatriate" pages sent to a remote machine back to the local machine;
+this is driven using the frontswap_shrink mechanism when memory pressure
+subsides.
+
+7) Why does the frontswap patch create the new include file swapfile.h?
+
+The frontswap code depends on some swap-subsystem-internal data
+structures that have, over the years, moved back and forth between
+static and global.  This seemed a reasonable compromise:  Define
+them as global but declare them in a new include file that isn't
+included by the large number of source files that include swap.h.
+
+Dan Magenheimer, last updated April 9, 2012
diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt
index 4600cbe3d6be..7587493c67f1 100644
--- a/Documentation/vm/pagemap.txt
+++ b/Documentation/vm/pagemap.txt
@@ -16,7 +16,7 @@ There are three components to pagemap:
     * Bits 0-4   swap type if swapped
     * Bits 5-54  swap offset if swapped
     * Bits 55-60 page shift (page size = 1<<page shift)
-    * Bit  61    reserved for future use
+    * Bit  61    page is file-page or shared-anon
     * Bit  62    page swapped
     * Bit  63    page present
 
diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt
index 6752870c4970..b0c6d1bbb434 100644
--- a/Documentation/vm/slub.txt
+++ b/Documentation/vm/slub.txt
@@ -17,7 +17,7 @@ data and perform operation on the slabs. By default slabinfo only lists
 slabs that have data in them. See "slabinfo -h" for more options when
 running the command. slabinfo can be compiled with
 
-gcc -o slabinfo tools/slub/slabinfo.c
+gcc -o slabinfo tools/vm/slabinfo.c
 
 Some of the modes of operation of slabinfo require that slub debugging
 be enabled on the command line. F.e. no tracking information will be
diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index 29bdf62aac09..f734bb2a78dc 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -166,6 +166,68 @@ behavior. So to make them effective you need to restart any
 application that could have been using hugepages. This also applies to
 the regions registered in khugepaged.
 
+== Monitoring usage ==
+
+The number of transparent huge pages currently used by the system is
+available by reading the AnonHugePages field in /proc/meminfo. To
+identify what applications are using transparent huge pages, it is
+necessary to read /proc/PID/smaps and count the AnonHugePages fields
+for each mapping. Note that reading the smaps file is expensive and
+reading it frequently will incur overhead.
+
+There are a number of counters in /proc/vmstat that may be used to
+monitor how successfully the system is providing huge pages for use.
+
+thp_fault_alloc is incremented every time a huge page is successfully
+        allocated to handle a page fault. This applies to both the
+        first time a page is faulted and for COW faults.
+
+thp_collapse_alloc is incremented by khugepaged when it has found
+        a range of pages to collapse into one huge page and has
+        successfully allocated a new huge page to store the data.
+
+thp_fault_fallback is incremented if a page fault fails to allocate
+        a huge page and instead falls back to using small pages.
+
+thp_collapse_alloc_failed is incremented if khugepaged found a range
+        of pages that should be collapsed into one huge page but failed
+        the allocation.
+
+thp_split is incremented every time a huge page is split into base
+        pages. This can happen for a variety of reasons but a common
+        reason is that a huge page is old and is being reclaimed.
+
+As the system ages, allocating huge pages may be expensive as the
+system uses memory compaction to copy data around memory to free a
+huge page for use. There are some counters in /proc/vmstat to help
+monitor this overhead.
+
+compact_stall is incremented every time a process stalls to run
+        memory compaction so that a huge page is free for use.
+
+compact_success is incremented if the system compacted memory and
+        freed a huge page for use.
+
+compact_fail is incremented if the system tries to compact memory
+        but failed.
+
+compact_pages_moved is incremented each time a page is moved. If
+        this value is increasing rapidly, it implies that the system
+        is copying a lot of data to satisfy the huge page allocation.
+        It is possible that the cost of copying exceeds any savings
+        from reduced TLB misses.
+
+compact_pagemigrate_failed is incremented when the underlying mechanism
+        for moving a page failed.
+
+compact_blocks_moved is incremented each time memory compaction examines
+        a huge page aligned range of pages.
+
+It is possible to establish how long the stalls were using the function
+tracer to record how long was spent in __alloc_pages_nodemask and
+using the mm_page_alloc tracepoint to identify which allocations were
+for huge pages.
+
 == get_user_pages and follow_page ==
 
 get_user_pages and follow_page if run on a hugepage, will return the
diff --git a/Documentation/vme_api.txt b/Documentation/vme_api.txt
new file mode 100644
index 000000000000..856efa35f6e3
--- /dev/null
+++ b/Documentation/vme_api.txt
@@ -0,0 +1,396 @@
+                        VME Device Driver API
+                        =====================
+
+Driver registration
+===================
+
+As with other subsystems within the Linux kernel, VME device drivers register
+with the VME subsystem, typically called from the devices init routine.  This is
+achieved via a call to the following function:
+
+        int vme_register_driver (struct vme_driver *driver);
+
+If driver registration is successful this function returns zero, if an error
+occurred a negative error code will be returned.
+
+A pointer to a structure of type 'vme_driver' must be provided to the
+registration function. The structure is as follows:
+
+        struct vme_driver {
+                struct list_head node;
+                const char *name;
+                int (*match)(struct vme_dev *);
+                int (*probe)(struct vme_dev *);
+                int (*remove)(struct vme_dev *);
+                void (*shutdown)(void);
+                struct device_driver driver;
+                struct list_head devices;
+                unsigned int ndev;
+        };
+
+At the minimum, the '.name', '.match' and '.probe' elements of this structure
+should be correctly set. The '.name' element is a pointer to a string holding
+the device driver's name.
+
+The '.match' function allows controlling the number of devices that need to
+be registered. The match function should return 1 if a device should be
+probed and 0 otherwise. This example match function (from vme_user.c) limits
+the number of devices probed to one:
+
+        #define USER_BUS_MAX    1
+        ...
+        static int vme_user_match(struct vme_dev *vdev)
+        {
+                if (vdev->id.num >= USER_BUS_MAX)
+                        return 0;
+                return 1;
+        }
+
+The '.probe' element should contain a pointer to the probe routine. The
+probe routine is passed a 'struct vme_dev' pointer as an argument. The
+'struct vme_dev' structure looks like the following:
+
+        struct vme_dev {
+                int num;
+                struct vme_bridge *bridge;
+                struct device dev;
+                struct list_head drv_list;
+                struct list_head bridge_list;
+        };
+
+Here, the 'num' field refers to the sequential device ID for this specific
+driver. The bridge number (or bus number) can be accessed using
+dev->bridge->num.
+
+A function is also provided to unregister the driver from the VME core and is
+usually called from the device driver's exit routine:
+
+        void vme_unregister_driver (struct vme_driver *driver);
+
+
+Resource management
+===================
+
+Once a driver has registered with the VME core the provided match routine will
+be called the number of times specified during the registration. If a match
+succeeds, a non-zero value should be returned. A zero return value indicates
+failure. For all successful matches, the probe routine of the corresponding
+driver is called. The probe routine is passed a pointer to the devices
+device structure. This pointer should be saved, it will be required for
+requesting VME resources.
+
+The driver can request ownership of one or more master windows, slave windows
+and/or dma channels. Rather than allowing the device driver to request a
+specific window or DMA channel (which may be used by a different driver) this
+driver allows a resource to be assigned based on the required attributes of the
+driver in question:
+
+        struct vme_resource * vme_master_request(struct vme_dev *dev,
+                u32 aspace, u32 cycle, u32 width);
+
+        struct vme_resource * vme_slave_request(struct vme_dev *dev, u32 aspace,
+                u32 cycle);
+
+        struct vme_resource *vme_dma_request(struct vme_dev *dev, u32 route);
+
+For slave windows these attributes are split into the VME address spaces that
+need to be accessed in 'aspace' and VME bus cycle types required in 'cycle'.
+Master windows add a further set of attributes in 'width' specifying the
+required data transfer widths. These attributes are defined as bitmasks and as
+such any combination of the attributes can be requested for a single window,
+the core will assign a window that meets the requirements, returning a pointer
+of type vme_resource that should be used to identify the allocated resource
+when it is used. For DMA controllers, the request function requires the
+potential direction of any transfers to be provided in the route attributes.
+This is typically VME-to-MEM and/or MEM-to-VME, though some hardware can
+support VME-to-VME and MEM-to-MEM transfers as well as test pattern generation.
+If an unallocated window fitting the requirements can not be found a NULL
+pointer will be returned.
+
+Functions are also provided to free window allocations once they are no longer
+required. These functions should be passed the pointer to the resource provided
+during resource allocation:
+
+        void vme_master_free(struct vme_resource *res);
+
+        void vme_slave_free(struct vme_resource *res);
+
+        void vme_dma_free(struct vme_resource *res);
+
+
+Master windows
+==============
+
+Master windows provide access from the local processor[s] out onto the VME bus.
+The number of windows available and the available access modes is dependent on
+the underlying chipset. A window must be configured before it can be used.
+
+
+Master window configuration
+---------------------------
+
+Once a master window has been assigned the following functions can be used to
+configure it and retrieve the current settings:
+
+        int vme_master_set (struct vme_resource *res, int enabled,
+                unsigned long long base, unsigned long long size, u32 aspace,
+                u32 cycle, u32 width);
+
+        int vme_master_get (struct vme_resource *res, int *enabled,
+                unsigned long long *base, unsigned long long *size, u32 *aspace,
+                u32 *cycle, u32 *width);
+
+The address spaces, transfer widths and cycle types are the same as described
+under resource management, however some of the options are mutually exclusive.
+For example, only one address space may be specified.
+
+These functions return 0 on success or an error code should the call fail.
+
+
+Master window access
+--------------------
+
+The following functions can be used to read from and write to configured master
+windows. These functions return the number of bytes copied:
+
+        ssize_t vme_master_read(struct vme_resource *res, void *buf,
+                size_t count, loff_t offset);
+
+        ssize_t vme_master_write(struct vme_resource *res, void *buf,
+                size_t count, loff_t offset);
+
+In addition to simple reads and writes, a function is provided to do a
+read-modify-write transaction. This function returns the original value of the
+VME bus location :
+
+        unsigned int vme_master_rmw (struct vme_resource *res,
+                unsigned int mask, unsigned int compare, unsigned int swap,
+                loff_t offset);
+
+This functions by reading the offset, applying the mask. If the bits selected in
+the mask match with the values of the corresponding bits in the compare field,
+the value of swap is written the specified offset.
+
+
+Slave windows
+=============
+
+Slave windows provide devices on the VME bus access into mapped portions of the
+local memory. The number of windows available and the access modes that can be
+used is dependent on the underlying chipset. A window must be configured before
+it can be used.
+
+
+Slave window configuration
+--------------------------
+
+Once a slave window has been assigned the following functions can be used to
+configure it and retrieve the current settings:
+
+        int vme_slave_set (struct vme_resource *res, int enabled,
+                unsigned long long base, unsigned long long size,
+                dma_addr_t mem, u32 aspace, u32 cycle);
+
+        int vme_slave_get (struct vme_resource *res, int *enabled,
+                unsigned long long *base, unsigned long long *size,
+                dma_addr_t *mem, u32 *aspace, u32 *cycle);
+
+The address spaces, transfer widths and cycle types are the same as described
+under resource management, however some of the options are mutually exclusive.
+For example, only one address space may be specified.
+
+These functions return 0 on success or an error code should the call fail.
+
+
+Slave window buffer allocation
+------------------------------
+
+Functions are provided to allow the user to allocate and free a contiguous
+buffers which will be accessible by the VME bridge. These functions do not have
+to be used, other methods can be used to allocate a buffer, though care must be
+taken to ensure that they are contiguous and accessible by the VME bridge:
+
+        void * vme_alloc_consistent(struct vme_resource *res, size_t size,
+                dma_addr_t *mem);
+
+        void vme_free_consistent(struct vme_resource *res, size_t size,
+                void *virt,     dma_addr_t mem);
+
+
+Slave window access
+-------------------
+
+Slave windows map local memory onto the VME bus, the standard methods for
+accessing memory should be used.
+
+
+DMA channels
+============
+
+The VME DMA transfer provides the ability to run link-list DMA transfers. The
+API introduces the concept of DMA lists. Each DMA list is a link-list which can
+be passed to a DMA controller. Multiple lists can be created, extended,
+executed, reused and destroyed.
+
+
+List Management
+---------------
+
+The following functions are provided to create and destroy DMA lists. Execution
+of a list will not automatically destroy the list, thus enabling a list to be
+reused for repetitive tasks:
+
+        struct vme_dma_list *vme_new_dma_list(struct vme_resource *res);
+
+        int vme_dma_list_free(struct vme_dma_list *list);
+
+
+List Population
+---------------
+
+An item can be added to a list using the following function ( the source and
+destination attributes need to be created before calling this function, this is
+covered under "Transfer Attributes"):
+
+        int vme_dma_list_add(struct vme_dma_list *list,
+                struct vme_dma_attr *src, struct vme_dma_attr *dest,
+                size_t count);
+
+NOTE:   The detailed attributes of the transfers source and destination
+        are not checked until an entry is added to a DMA list, the request
+        for a DMA channel purely checks the directions in which the
+        controller is expected to transfer data. As a result it is
+        possible for this call to return an error, for example if the
+        source or destination is in an unsupported VME address space.
+
+Transfer Attributes
+-------------------
+
+The attributes for the source and destination are handled separately from adding
+an item to a list. This is due to the diverse attributes required for each type
+of source and destination. There are functions to create attributes for PCI, VME
+and pattern sources and destinations (where appropriate):
+
+Pattern source:
+
+        struct vme_dma_attr *vme_dma_pattern_attribute(u32 pattern, u32 type);
+
+PCI source or destination:
+
+        struct vme_dma_attr *vme_dma_pci_attribute(dma_addr_t mem);
+
+VME source or destination:
+
+        struct vme_dma_attr *vme_dma_vme_attribute(unsigned long long base,
+                u32 aspace, u32 cycle, u32 width);
+
+The following function should be used to free an attribute:
+
+        void vme_dma_free_attribute(struct vme_dma_attr *attr);
+
+
+List Execution
+--------------
+
+The following function queues a list for execution. The function will return
+once the list has been executed:
+
+        int vme_dma_list_exec(struct vme_dma_list *list);
+
+
+Interrupts
+==========
+
+The VME API provides functions to attach and detach callbacks to specific VME
+level and status ID combinations and for the generation of VME interrupts with
+specific VME level and status IDs.
+
+
+Attaching Interrupt Handlers
+----------------------------
+
+The following functions can be used to attach and free a specific VME level and
+status ID combination. Any given combination can only be assigned a single
+callback function. A void pointer parameter is provided, the value of which is
+passed to the callback function, the use of this pointer is user undefined:
+
+        int vme_irq_request(struct vme_dev *dev, int level, int statid,
+                void (*callback)(int, int, void *), void *priv);
+
+        void vme_irq_free(struct vme_dev *dev, int level, int statid);
+
+The callback parameters are as follows. Care must be taken in writing a callback
+function, callback functions run in interrupt context:
+
+        void callback(int level, int statid, void *priv);
+
+
+Interrupt Generation
+--------------------
+
+The following function can be used to generate a VME interrupt at a given VME
+level and VME status ID:
+
+        int vme_irq_generate(struct vme_dev *dev, int level, int statid);
+
+
+Location monitors
+=================
+
+The VME API provides the following functionality to configure the location
+monitor.
+
+
+Location Monitor Management
+---------------------------
+
+The following functions are provided to request the use of a block of location
+monitors and to free them after they are no longer required:
+
+        struct vme_resource * vme_lm_request(struct vme_dev *dev);
+
+        void vme_lm_free(struct vme_resource * res);
+
+Each block may provide a number of location monitors, monitoring adjacent
+locations. The following function can be used to determine how many locations
+are provided:
+
+        int vme_lm_count(struct vme_resource * res);
+
+
+Location Monitor Configuration
+------------------------------
+
+Once a bank of location monitors has been allocated, the following functions
+are provided to configure the location and mode of the location monitor:
+
+        int vme_lm_set(struct vme_resource *res, unsigned long long base,
+                u32 aspace, u32 cycle);
+
+        int vme_lm_get(struct vme_resource *res, unsigned long long *base,
+                u32 *aspace, u32 *cycle);
+
+
+Location Monitor Use
+--------------------
+
+The following functions allow a callback to be attached and detached from each
+location monitor location. Each location monitor can monitor a number of
+adjacent locations:
+
+        int vme_lm_attach(struct vme_resource *res, int num,
+                void (*callback)(int));
+
+        int vme_lm_detach(struct vme_resource *res, int num);
+
+The callback function is declared as follows.
+
+        void callback(int num);
+
+
+Slot Detection
+==============
+
+This function returns the slot ID of the provided bridge.
+
+        int vme_slot_get(struct vme_dev *dev);
diff --git a/Documentation/watchdog/src/watchdog-test.c b/Documentation/watchdog/src/watchdog-test.c
index 63fdc34ceb98..73ff5cc93e05 100644
--- a/Documentation/watchdog/src/watchdog-test.c
+++ b/Documentation/watchdog/src/watchdog-test.c
@@ -7,6 +7,7 @@
 #include <string.h>
 #include <unistd.h>
 #include <fcntl.h>
+#include <signal.h>
 #include <sys/ioctl.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
@@ -29,6 +30,14 @@ static void keep_alive(void)
  * The main program.  Run the program with "-d" to disable the card,
  * or "-e" to enable the card.
  */
+
+void term(int sig)
+{
+    close(fd);
+    fprintf(stderr, "Stopping watchdog ticks...\n");
+    exit(0);
+}
+
 int main(int argc, char *argv[])
 {
     int flags;
@@ -47,26 +56,31 @@ int main(int argc, char *argv[])
             ioctl(fd, WDIOC_SETOPTIONS, &flags);
             fprintf(stderr, "Watchdog card disabled.\n");
             fflush(stderr);
-            exit(0);
+            goto end;
         } else if (!strncasecmp(argv[1], "-e", 2)) {
             flags = WDIOS_ENABLECARD;
             ioctl(fd, WDIOC_SETOPTIONS, &flags);
             fprintf(stderr, "Watchdog card enabled.\n");
             fflush(stderr);
-            exit(0);
+            goto end;
         } else {
             fprintf(stderr, "-d to disable, -e to enable.\n");
             fprintf(stderr, "run by itself to tick the card.\n");
             fflush(stderr);
-            exit(0);
+            goto end;
         }
     } else {
         fprintf(stderr, "Watchdog Ticking Away!\n");
         fflush(stderr);
     }
 
+    signal(SIGINT, term);
+
     while(1) {
         keep_alive();
         sleep(1);
     }
+end:
+    close(fd);
+    return 0;
 }
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt
index 227f6cd0e5fa..086638f6c82d 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -1,6 +1,6 @@
 The Linux WatchDog Timer Driver Core kernel API.
 ===============================================
-Last reviewed: 16-Mar-2012
+Last reviewed: 22-May-2012
 
 Wim Van Sebroeck <wim@iguana.be>
 
@@ -39,6 +39,10 @@ watchdog_device structure.
 The watchdog device structure looks like this:
 
 struct watchdog_device {
+        int id;
+        struct cdev cdev;
+        struct device *dev;
+        struct device *parent;
         const struct watchdog_info *info;
         const struct watchdog_ops *ops;
         unsigned int bootstatus;
@@ -46,10 +50,20 @@ struct watchdog_device {
         unsigned int min_timeout;
         unsigned int max_timeout;
         void *driver_data;
+        struct mutex lock;
         unsigned long status;
 };
 
 It contains following fields:
+* id: set by watchdog_register_device, id 0 is special. It has both a
+  /dev/watchdog0 cdev (dynamic major, minor 0) as well as the old
+  /dev/watchdog miscdev. The id is set automatically when calling
+  watchdog_register_device.
+* cdev: cdev for the dynamic /dev/watchdog<id> device nodes. This
+  field is also populated by watchdog_register_device.
+* dev: device under the watchdog class (created by watchdog_register_device).
+* parent: set this to the parent device (or NULL) before calling
+  watchdog_register_device.
 * info: a pointer to a watchdog_info structure. This structure gives some
   additional information about the watchdog timer itself. (Like it's unique name)
 * ops: a pointer to the list of watchdog operations that the watchdog supports.
@@ -59,8 +73,9 @@ It contains following fields:
 * bootstatus: status of the device after booting (reported with watchdog
   WDIOF_* status bits).
 * driver_data: a pointer to the drivers private data of a watchdog device.
-  This data should only be accessed via the watchdog_set_drvadata and
+  This data should only be accessed via the watchdog_set_drvdata and
   watchdog_get_drvdata routines.
+* lock: Mutex for WatchDog Timer Driver Core internal use only.
 * status: this field contains a number of status bits that give extra
   information about the status of the device (Like: is the watchdog timer
   running/active, is the nowayout bit set, is the device opened via
@@ -78,6 +93,8 @@ struct watchdog_ops {
         unsigned int (*status)(struct watchdog_device *);
         int (*set_timeout)(struct watchdog_device *, unsigned int);
         unsigned int (*get_timeleft)(struct watchdog_device *);
+        void (*ref)(struct watchdog_device *);
+        void (*unref)(struct watchdog_device *);
         long (*ioctl)(struct watchdog_device *, unsigned int, unsigned long);
 };
 
@@ -85,6 +102,21 @@ It is important that you first define the module owner of the watchdog timer
 driver's operations. This module owner will be used to lock the module when
 the watchdog is active. (This to avoid a system crash when you unload the
 module and /dev/watchdog is still open).
+
+If the watchdog_device struct is dynamically allocated, just locking the module
+is not enough and a driver also needs to define the ref and unref operations to
+ensure the structure holding the watchdog_device does not go away.
+
+The simplest (and usually sufficient) implementation of this is to:
+1) Add a kref struct to the same structure which is holding the watchdog_device
+2) Define a release callback for the kref which frees the struct holding both
+3) Call kref_init on this kref *before* calling watchdog_register_device()
+4) Define a ref operation calling kref_get on this kref
+5) Define a unref operation calling kref_put on this kref
+6) When it is time to cleanup:
+ * Do not kfree() the struct holding both, the last kref_put will do this!
+ * *After* calling watchdog_unregister_device() call kref_put on the kref
+
 Some operations are mandatory and some are optional. The mandatory operations
 are:
 * start: this is a pointer to the routine that starts the watchdog timer
@@ -125,6 +157,10 @@ they are supported. These optional routines/operations are:
   (Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the
   watchdog's info structure).
 * get_timeleft: this routines returns the time that's left before a reset.
+* ref: the operation that calls kref_get on the kref of a dynamically
+  allocated watchdog_device struct.
+* unref: the operation that calls kref_put on the kref of a dynamically
+  allocated watchdog_device struct.
 * ioctl: if this routine is present then it will be called first before we do
   our own internal ioctl call handling. This routine should return -ENOIOCTLCMD
   if a command is not supported. The parameters that are passed to the ioctl
@@ -144,6 +180,11 @@ bit-operations. The status bits that are defined are:
   (This bit should only be used by the WatchDog Timer Driver Core).
 * WDOG_NO_WAY_OUT: this bit stores the nowayout setting for the watchdog.
   If this bit is set then the watchdog timer will not be able to stop.
+* WDOG_UNREGISTERED: this bit gets set by the WatchDog Timer Driver Core
+  after calling watchdog_unregister_device, and then checked before calling
+  any watchdog_ops, so that you can be sure that no operations (other then
+  unref) will get called after unregister, even if userspace still holds a
+  reference to /dev/watchdog
 
   To set the WDOG_NO_WAY_OUT status bit (before registering your watchdog
   timer device) you can either:
diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
index 17ddd822b456..04fddbacdbde 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -78,6 +78,11 @@ wd0_timeout: Default watchdog0 timeout in 1/10secs
 wd1_timeout: Default watchdog1 timeout in 1/10secs
 wd2_timeout: Default watchdog2 timeout in 1/10secs
 -------------------------------------------------
+da9052wdt:
+timeout: Watchdog timeout in seconds. 2<= timeout <=131, default=2.048s
+nowayout: Watchdog cannot be stopped once started
+        (default=kernel config parameter)
+-------------------------------------------------
 davinci_wdt:
 heartbeat: Watchdog heartbeat period in seconds from 1 to 600, default 60
 -------------------------------------------------
diff --git a/Documentation/x86/efi-stub.txt b/Documentation/x86/efi-stub.txt
new file mode 100644
index 000000000000..44e6bb6ead10
--- /dev/null
+++ b/Documentation/x86/efi-stub.txt
@@ -0,0 +1,65 @@
+                          The EFI Boot Stub
+                     ---------------------------
+
+On the x86 platform, a bzImage can masquerade as a PE/COFF image,
+thereby convincing EFI firmware loaders to load it as an EFI
+executable. The code that modifies the bzImage header, along with the
+EFI-specific entry point that the firmware loader jumps to are
+collectively known as the "EFI boot stub", and live in
+arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
+respectively.
+
+By using the EFI boot stub it's possible to boot a Linux kernel
+without the use of a conventional EFI boot loader, such as grub or
+elilo. Since the EFI boot stub performs the jobs of a boot loader, in
+a certain sense it *IS* the boot loader.
+
+The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
+
+
+**** How to install bzImage.efi
+
+The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
+System Partiion (ESP) and renamed with the extension ".efi". Without
+the extension the EFI firmware loader will refuse to execute it. It's
+not possible to execute bzImage.efi from the usual Linux file systems
+because EFI firmware doesn't have support for them.
+
+
+**** Passing kernel parameters from the EFI shell
+
+Arguments to the kernel can be passed after bzImage.efi, e.g.
+
+        fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
+
+
+**** The "initrd=" option
+
+Like most boot loaders, the EFI stub allows the user to specify
+multiple initrd files using the "initrd=" option. This is the only EFI
+stub-specific command line parameter, everything else is passed to the
+kernel when it boots.
+
+The path to the initrd file must be an absolute path from the
+beginning of the ESP, relative path names do not work. Also, the path
+is an EFI-style path and directory elements must be separated with
+backslashes (\). For example, given the following directory layout,
+
+fs0:>
+        Kernels\
+                        bzImage.efi
+                        initrd-large.img
+
+        Ramdisks\
+                        initrd-small.img
+                        initrd-medium.img
+
+to boot with the initrd-large.img file if the current working
+directory is fs0:\Kernels, the following command must be used,
+
+        fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img
+
+Notice how bzImage.efi can be specified with a relative path. That's
+because the image we're executing is interpreted by the EFI shell,
+which understands relative paths, whereas the rest of the command line
+is passed to bzImage.efi.
diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt
index f606ba8598cf..4263022f5002 100644
--- a/Documentation/zh_CN/magic-number.txt
+++ b/Documentation/zh_CN/magic-number.txt
@@ -160,7 +160,7 @@ QUEUE_MAGIC_USED      0xf7e1cc33  queue_entry       drivers/scsi/arm/queue.c
 HTB_CMAGIC            0xFEFAFEF1  htb_class         net/sched/sch_htb.c
 NMI_MAGIC             0x48414d4d455201 nmi_s        arch/mips/include/asm/sn/nmi.h
 
-请注意，在声音记忆管理中仍然有每一些被定义的驱动魔术值。查看include/sound/sndmagic.h来获取他们完整的列表信息。很多OSS声音驱动拥有自己从声卡PCI ID构建的魔术值-他们也没有被列在这里。
+请注意，在声音记忆管理中仍然有一些特殊的为每个驱动定义的魔术值。查看include/sound/sndmagic.h来获取他们完整的列表信息。很多OSS声音驱动拥有自己从声卡PCI ID构建的魔术值-他们也没有被列在这里。
 
 IrDA子系统也使用了大量的自己的魔术值，查看include/net/irda/irda.h来获取他们完整的信息。