aboutsummaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/DocBook/writing-an-alsa-driver.tmpl12
-rw-r--r--Documentation/EDID/1600x1200.S44
-rw-r--r--Documentation/EDID/HOWTO.txt12
-rw-r--r--Documentation/RCU/stallwarn.txt2
-rw-r--r--Documentation/arm/cluster-pm-race-avoidance.txt498
-rw-r--r--Documentation/arm/firmware.txt88
-rw-r--r--Documentation/arm/vlocks.txt211
-rw-r--r--Documentation/cpu-freq/governors.txt4
-rw-r--r--Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt11
-rw-r--r--Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt19
-rw-r--r--Documentation/devicetree/bindings/arm/msm/timer.txt41
-rw-r--r--Documentation/devicetree/bindings/arm/samsung-boards.txt10
-rw-r--r--Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt67
-rw-r--r--Documentation/devicetree/bindings/bus/ti-gpmc.txt103
-rw-r--r--Documentation/devicetree/bindings/clock/altr_socfpga.txt18
-rw-r--r--Documentation/devicetree/bindings/clock/exynos4-clock.txt288
-rw-r--r--Documentation/devicetree/bindings/clock/exynos5250-clock.txt177
-rw-r--r--Documentation/devicetree/bindings/clock/exynos5440-clock.txt61
-rw-r--r--Documentation/devicetree/bindings/clock/imx27-clock.txt117
-rw-r--r--Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt303
-rw-r--r--Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt4
-rw-r--r--Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt15
-rw-r--r--Documentation/devicetree/bindings/drm/exynos/g2d.txt22
-rw-r--r--Documentation/devicetree/bindings/gpio/gpio-vt8500.txt24
-rw-r--r--Documentation/devicetree/bindings/gpio/mrvl-gpio.txt7
-rw-r--r--Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt18
-rw-r--r--Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt80
-rw-r--r--Documentation/devicetree/bindings/input/cros-ec-keyb.txt72
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt (renamed from Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt)4
-rw-r--r--Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt53
-rw-r--r--Documentation/devicetree/bindings/media/s5p-mfc.txt21
-rw-r--r--Documentation/devicetree/bindings/mfd/as3711.txt73
-rw-r--r--Documentation/devicetree/bindings/mfd/cros-ec.txt56
-rw-r--r--Documentation/devicetree/bindings/mfd/omap-usb-host.txt80
-rw-r--r--Documentation/devicetree/bindings/mfd/omap-usb-tll.txt17
-rw-r--r--Documentation/devicetree/bindings/misc/smc.txt14
-rw-r--r--Documentation/devicetree/bindings/mmc/davinci_mmc.txt33
-rw-r--r--Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt24
-rw-r--r--Documentation/devicetree/bindings/mmc/samsung-sdhci.txt35
-rw-r--r--Documentation/devicetree/bindings/mmc/sdhci-sirf.txt18
-rw-r--r--Documentation/devicetree/bindings/mtd/gpmc-nor.txt98
-rw-r--r--Documentation/devicetree/bindings/mtd/gpmc-onenand.txt3
-rw-r--r--Documentation/devicetree/bindings/net/gpmc-eth.txt97
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt6
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt955
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt759
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt1174
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt38
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt1596
-rw-r--r--Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt39
-rw-r--r--Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt57
-rw-r--r--Documentation/devicetree/bindings/powerpc/fsl/cpus.txt22
-rw-r--r--Documentation/devicetree/bindings/reset/reset.txt75
-rw-r--r--Documentation/devicetree/bindings/rng/brcm,bcm2835.txt13
-rw-r--r--Documentation/devicetree/bindings/sound/ak5386.txt19
-rw-r--r--Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt26
-rw-r--r--Documentation/devicetree/bindings/sound/ti,tas5086.txt32
-rw-r--r--Documentation/devicetree/bindings/sound/wm8994.txt58
-rw-r--r--Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt (renamed from Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt)4
-rw-r--r--Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt17
-rw-r--r--Documentation/devicetree/bindings/timer/fsl,imxgpt.txt18
-rw-r--r--Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt68
-rw-r--r--Documentation/devicetree/bindings/usb/exynos-usb.txt40
-rw-r--r--Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt (renamed from Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt)6
-rw-r--r--Documentation/filesystems/nfs/00-INDEX2
-rw-r--r--Documentation/filesystems/nfs/rpc-server-gss.txt91
-rw-r--r--Documentation/filesystems/xfs-self-describing-metadata.txt350
-rw-r--r--Documentation/hw_random.txt2
-rw-r--r--Documentation/hwmon/lm7515
-rw-r--r--Documentation/kernel-parameters.txt14
-rw-r--r--Documentation/mmc/mmc-dev-attrs.txt1
-rw-r--r--Documentation/powerpc/00-INDEX4
-rw-r--r--Documentation/powerpc/ptrace.txt1
-rw-r--r--Documentation/powerpc/sound.txt81
-rw-r--r--Documentation/powerpc/zImage_layout.txt47
-rw-r--r--Documentation/sound/alsa/HD-Audio.txt10
-rw-r--r--Documentation/timers/NO_HZ.txt273
-rw-r--r--Documentation/virtual/00-INDEX3
-rw-r--r--Documentation/virtual/kvm/api.txt146
-rw-r--r--Documentation/virtual/kvm/devices/README1
-rw-r--r--Documentation/virtual/kvm/devices/mpic.txt53
-rw-r--r--Documentation/virtual/kvm/devices/xics.txt66
-rw-r--r--Documentation/virtual/virtio-spec.txt3210
83 files changed, 4344 insertions, 8002 deletions
diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl
index bd6fee22c4dd..06741e925985 100644
--- a/Documentation/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl
@@ -6164,14 +6164,12 @@ struct _snd_pcm_runtime {
<para>
The macro takes an conditional expression to evaluate.
- When <constant>CONFIG_SND_DEBUG</constant>, is set, the
- expression is actually evaluated. If it's non-zero, it shows
- the warning message such as
+ When <constant>CONFIG_SND_DEBUG</constant>, is set, if the
+ expression is non-zero, it shows the warning message such as
<computeroutput>BUG? (xxx)</computeroutput>
- normally followed by stack trace. It returns the evaluated
- value.
- When no <constant>CONFIG_SND_DEBUG</constant> is set, this
- macro always returns zero.
+ normally followed by stack trace.
+
+ In both cases it returns the evaluated value.
</para>
</section>
diff --git a/Documentation/EDID/1600x1200.S b/Documentation/EDID/1600x1200.S
new file mode 100644
index 000000000000..0ded64cfd1f5
--- /dev/null
+++ b/Documentation/EDID/1600x1200.S
@@ -0,0 +1,44 @@
+/*
+ 1600x1200.S: EDID data set for standard 1600x1200 60 Hz monitor
+
+ Copyright (C) 2013 Carsten Emde <C.Emde@osadl.org>
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License
+ as published by the Free Software Foundation; either version 2
+ of the License, or (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 162000 /* kHz */
+#define XPIX 1600
+#define YPIX 1200
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 560
+#define YBLANK 50
+#define XOFFSET 64
+#define XPULSE 192
+#define YOFFSET (63+1)
+#define YPULSE (63+3)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux UXGA"
+#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+#define HSYNC_POL 1
+#define VSYNC_POL 1
+#define CRC 0x9d
+
+#include "edid.S"
diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt
index 2d0a8f09475d..7146db1d9e8c 100644
--- a/Documentation/EDID/HOWTO.txt
+++ b/Documentation/EDID/HOWTO.txt
@@ -18,12 +18,12 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
individually prepared or corrected EDID data set in the /lib/firmware
directory from where it is loaded via the firmware interface. The code
(see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
-commonly used screen resolutions (1024x768, 1280x1024, 1680x1050,
-1920x1080) as binary blobs, but the kernel source tree does not contain
-code to create these data. In order to elucidate the origin of the
-built-in binary EDID blobs and to facilitate the creation of individual
-data for a specific misbehaving monitor, commented sources and a
-Makefile environment are given here.
+commonly used screen resolutions (1024x768, 1280x1024, 1600x1200,
+1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
+not contain code to create these data. In order to elucidate the origin
+of the built-in binary EDID blobs and to facilitate the creation of
+individual data for a specific misbehaving monitor, commented sources
+and a Makefile environment are given here.
To create binary EDID and C source code files from the existing data
material, simply type "make".
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index e38b8df3d727..8e9359de1d28 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -191,7 +191,7 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
o A hardware or software issue shuts off the scheduler-clock
interrupt on a CPU that is not in dyntick-idle mode. This
problem really has happened, and seems to be most likely to
- result in RCU CPU stall warnings for CONFIG_NO_HZ=n kernels.
+ result in RCU CPU stall warnings for CONFIG_NO_HZ_COMMON=n kernels.
o A bug in the RCU implementation.
diff --git a/Documentation/arm/cluster-pm-race-avoidance.txt b/Documentation/arm/cluster-pm-race-avoidance.txt
new file mode 100644
index 000000000000..750b6fc24af9
--- /dev/null
+++ b/Documentation/arm/cluster-pm-race-avoidance.txt
@@ -0,0 +1,498 @@
+Cluster-wide Power-up/power-down race avoidance algorithm
+=========================================================
+
+This file documents the algorithm which is used to coordinate CPU and
+cluster setup and teardown operations and to manage hardware coherency
+controls safely.
+
+The section "Rationale" explains what the algorithm is for and why it is
+needed. "Basic model" explains general concepts using a simplified view
+of the system. The other sections explain the actual details of the
+algorithm in use.
+
+
+Rationale
+---------
+
+In a system containing multiple CPUs, it is desirable to have the
+ability to turn off individual CPUs when the system is idle, reducing
+power consumption and thermal dissipation.
+
+In a system containing multiple clusters of CPUs, it is also desirable
+to have the ability to turn off entire clusters.
+
+Turning entire clusters off and on is a risky business, because it
+involves performing potentially destructive operations affecting a group
+of independently running CPUs, while the OS continues to run. This
+means that we need some coordination in order to ensure that critical
+cluster-level operations are only performed when it is truly safe to do
+so.
+
+Simple locking may not be sufficient to solve this problem, because
+mechanisms like Linux spinlocks may rely on coherency mechanisms which
+are not immediately enabled when a cluster powers up. Since enabling or
+disabling those mechanisms may itself be a non-atomic operation (such as
+writing some hardware registers and invalidating large caches), other
+methods of coordination are required in order to guarantee safe
+power-down and power-up at the cluster level.
+
+The mechanism presented in this document describes a coherent memory
+based protocol for performing the needed coordination. It aims to be as
+lightweight as possible, while providing the required safety properties.
+
+
+Basic model
+-----------
+
+Each cluster and CPU is assigned a state, as follows:
+
+ DOWN
+ COMING_UP
+ UP
+ GOING_DOWN
+
+ +---------> UP ----------+
+ | v
+
+ COMING_UP GOING_DOWN
+
+ ^ |
+ +--------- DOWN <--------+
+
+
+DOWN: The CPU or cluster is not coherent, and is either powered off or
+ suspended, or is ready to be powered off or suspended.
+
+COMING_UP: The CPU or cluster has committed to moving to the UP state.
+ It may be part way through the process of initialisation and
+ enabling coherency.
+
+UP: The CPU or cluster is active and coherent at the hardware
+ level. A CPU in this state is not necessarily being used
+ actively by the kernel.
+
+GOING_DOWN: The CPU or cluster has committed to moving to the DOWN
+ state. It may be part way through the process of teardown and
+ coherency exit.
+
+
+Each CPU has one of these states assigned to it at any point in time.
+The CPU states are described in the "CPU state" section, below.
+
+Each cluster is also assigned a state, but it is necessary to split the
+state value into two parts (the "cluster" state and "inbound" state) and
+to introduce additional states in order to avoid races between different
+CPUs in the cluster simultaneously modifying the state. The cluster-
+level states are described in the "Cluster state" section.
+
+To help distinguish the CPU states from cluster states in this
+discussion, the state names are given a CPU_ prefix for the CPU states,
+and a CLUSTER_ or INBOUND_ prefix for the cluster states.
+
+
+CPU state
+---------
+
+In this algorithm, each individual core in a multi-core processor is
+referred to as a "CPU". CPUs are assumed to be single-threaded:
+therefore, a CPU can only be doing one thing at a single point in time.
+
+This means that CPUs fit the basic model closely.
+
+The algorithm defines the following states for each CPU in the system:
+
+ CPU_DOWN
+ CPU_COMING_UP
+ CPU_UP
+ CPU_GOING_DOWN
+
+ cluster setup and
+ CPU setup complete policy decision
+ +-----------> CPU_UP ------------+
+ | v
+
+ CPU_COMING_UP CPU_GOING_DOWN
+
+ ^ |
+ +----------- CPU_DOWN <----------+
+ policy decision CPU teardown complete
+ or hardware event
+
+
+The definitions of the four states correspond closely to the states of
+the basic model.
+
+Transitions between states occur as follows.
+
+A trigger event (spontaneous) means that the CPU can transition to the
+next state as a result of making local progress only, with no
+requirement for any external event to happen.
+
+
+CPU_DOWN:
+
+ A CPU reaches the CPU_DOWN state when it is ready for
+ power-down. On reaching this state, the CPU will typically
+ power itself down or suspend itself, via a WFI instruction or a
+ firmware call.
+
+ Next state: CPU_COMING_UP
+ Conditions: none
+
+ Trigger events:
+
+ a) an explicit hardware power-up operation, resulting
+ from a policy decision on another CPU;
+
+ b) a hardware event, such as an interrupt.
+
+
+CPU_COMING_UP:
+
+ A CPU cannot start participating in hardware coherency until the
+ cluster is set up and coherent. If the cluster is not ready,
+ then the CPU will wait in the CPU_COMING_UP state until the
+ cluster has been set up.
+
+ Next state: CPU_UP
+ Conditions: The CPU's parent cluster must be in CLUSTER_UP.
+ Trigger events: Transition of the parent cluster to CLUSTER_UP.
+
+ Refer to the "Cluster state" section for a description of the
+ CLUSTER_UP state.
+
+
+CPU_UP:
+ When a CPU reaches the CPU_UP state, it is safe for the CPU to
+ start participating in local coherency.
+
+ This is done by jumping to the kernel's CPU resume code.
+
+ Note that the definition of this state is slightly different
+ from the basic model definition: CPU_UP does not mean that the
+ CPU is coherent yet, but it does mean that it is safe to resume
+ the kernel. The kernel handles the rest of the resume
+ procedure, so the remaining steps are not visible as part of the
+ race avoidance algorithm.
+
+ The CPU remains in this state until an explicit policy decision
+ is made to shut down or suspend the CPU.
+
+ Next state: CPU_GOING_DOWN
+ Conditions: none
+ Trigger events: explicit policy decision
+
+
+CPU_GOING_DOWN:
+
+ While in this state, the CPU exits coherency, including any
+ operations required to achieve this (such as cleaning data
+ caches).
+
+ Next state: CPU_DOWN
+ Conditions: local CPU teardown complete
+ Trigger events: (spontaneous)
+
+
+Cluster state
+-------------
+
+A cluster is a group of connected CPUs with some common resources.
+Because a cluster contains multiple CPUs, it can be doing multiple
+things at the same time. This has some implications. In particular, a
+CPU can start up while another CPU is tearing the cluster down.
+
+In this discussion, the "outbound side" is the view of the cluster state
+as seen by a CPU tearing the cluster down. The "inbound side" is the
+view of the cluster state as seen by a CPU setting the CPU up.
+
+In order to enable safe coordination in such situations, it is important
+that a CPU which is setting up the cluster can advertise its state
+independently of the CPU which is tearing down the cluster. For this
+reason, the cluster state is split into two parts:
+
+ "cluster" state: The global state of the cluster; or the state
+ on the outbound side:
+
+ CLUSTER_DOWN
+ CLUSTER_UP
+ CLUSTER_GOING_DOWN
+
+ "inbound" state: The state of the cluster on the inbound side.
+
+ INBOUND_NOT_COMING_UP
+ INBOUND_COMING_UP
+
+
+ The different pairings of these states results in six possible
+ states for the cluster as a whole:
+
+ CLUSTER_UP
+ +==========> INBOUND_NOT_COMING_UP -------------+
+ # |
+ |
+ CLUSTER_UP <----+ |
+ INBOUND_COMING_UP | v
+
+ ^ CLUSTER_GOING_DOWN CLUSTER_GOING_DOWN
+ # INBOUND_COMING_UP <=== INBOUND_NOT_COMING_UP
+
+ CLUSTER_DOWN | |
+ INBOUND_COMING_UP <----+ |
+ |
+ ^ |
+ +=========== CLUSTER_DOWN <------------+
+ INBOUND_NOT_COMING_UP
+
+ Transitions -----> can only be made by the outbound CPU, and
+ only involve changes to the "cluster" state.
+
+ Transitions ===##> can only be made by the inbound CPU, and only
+ involve changes to the "inbound" state, except where there is no
+ further transition possible on the outbound side (i.e., the
+ outbound CPU has put the cluster into the CLUSTER_DOWN state).
+
+ The race avoidance algorithm does not provide a way to determine
+ which exact CPUs within the cluster play these roles. This must
+ be decided in advance by some other means. Refer to the section
+ "Last man and first man selection" for more explanation.
+
+
+ CLUSTER_DOWN/INBOUND_NOT_COMING_UP is the only state where the
+ cluster can actually be powered down.
+
+ The parallelism of the inbound and outbound CPUs is observed by
+ the existence of two different paths from CLUSTER_GOING_DOWN/
+ INBOUND_NOT_COMING_UP (corresponding to GOING_DOWN in the basic
+ model) to CLUSTER_DOWN/INBOUND_COMING_UP (corresponding to
+ COMING_UP in the basic model). The second path avoids cluster
+ teardown completely.
+
+ CLUSTER_UP/INBOUND_COMING_UP is equivalent to UP in the basic
+ model. The final transition to CLUSTER_UP/INBOUND_NOT_COMING_UP
+ is trivial and merely resets the state machine ready for the
+ next cycle.
+
+ Details of the allowable transitions follow.
+
+ The next state in each case is notated
+
+ <cluster state>/<inbound state> (<transitioner>)
+
+ where the <transitioner> is the side on which the transition
+ can occur; either the inbound or the outbound side.
+
+
+CLUSTER_DOWN/INBOUND_NOT_COMING_UP:
+
+ Next state: CLUSTER_DOWN/INBOUND_COMING_UP (inbound)
+ Conditions: none
+ Trigger events:
+
+ a) an explicit hardware power-up operation, resulting
+ from a policy decision on another CPU;
+
+ b) a hardware event, such as an interrupt.
+
+
+CLUSTER_DOWN/INBOUND_COMING_UP:
+
+ In this state, an inbound CPU sets up the cluster, including
+ enabling of hardware coherency at the cluster level and any
+ other operations (such as cache invalidation) which are required
+ in order to achieve this.
+
+ The purpose of this state is to do sufficient cluster-level
+ setup to enable other CPUs in the cluster to enter coherency
+ safely.
+
+ Next state: CLUSTER_UP/INBOUND_COMING_UP (inbound)
+ Conditions: cluster-level setup and hardware coherency complete
+ Trigger events: (spontaneous)
+
+
+CLUSTER_UP/INBOUND_COMING_UP:
+
+ Cluster-level setup is complete and hardware coherency is
+ enabled for the cluster. Other CPUs in the cluster can safely
+ enter coherency.
+
+ This is a transient state, leading immediately to
+ CLUSTER_UP/INBOUND_NOT_COMING_UP. All other CPUs on the cluster
+ should consider treat these two states as equivalent.
+
+ Next state: CLUSTER_UP/INBOUND_NOT_COMING_UP (inbound)
+ Conditions: none
+ Trigger events: (spontaneous)
+
+
+CLUSTER_UP/INBOUND_NOT_COMING_UP:
+
+ Cluster-level setup is complete and hardware coherency is
+ enabled for the cluster. Other CPUs in the cluster can safely
+ enter coherency.
+
+ The cluster will remain in this state until a policy decision is
+ made to power the cluster down.
+
+ Next state: CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP (outbound)
+ Conditions: none
+ Trigger events: policy decision to power down the cluster
+
+
+CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP:
+
+ An outbound CPU is tearing the cluster down. The selected CPU
+ must wait in this state until all CPUs in the cluster are in the
+ CPU_DOWN state.
+
+ When all CPUs are in the CPU_DOWN state, the cluster can be torn
+ down, for example by cleaning data caches and exiting
+ cluster-level coherency.
+
+ To avoid wasteful unnecessary teardown operations, the outbound
+ should check the inbound cluster state for asynchronous
+ transitions to INBOUND_COMING_UP. Alternatively, individual
+ CPUs can be checked for entry into CPU_COMING_UP or CPU_UP.
+
+
+ Next states:
+
+ CLUSTER_DOWN/INBOUND_NOT_COMING_UP (outbound)
+ Conditions: cluster torn down and ready to power off
+ Trigger events: (spontaneous)
+
+ CLUSTER_GOING_DOWN/INBOUND_COMING_UP (inbound)
+ Conditions: none
+ Trigger events:
+
+ a) an explicit hardware power-up operation,
+ resulting from a policy decision on another
+ CPU;
+
+ b) a hardware event, such as an interrupt.
+
+
+CLUSTER_GOING_DOWN/INBOUND_COMING_UP:
+
+ The cluster is (or was) being torn down, but another CPU has
+ come online in the meantime and is trying to set up the cluster
+ again.
+
+ If the outbound CPU observes this state, it has two choices:
+
+ a) back out of teardown, restoring the cluster to the
+ CLUSTER_UP state;
+
+ b) finish tearing the cluster down and put the cluster
+ in the CLUSTER_DOWN state; the inbound CPU will
+ set up the cluster again from there.
+
+ Choice (a) permits the removal of some latency by avoiding
+ unnecessary teardown and setup operations in situations where
+ the cluster is not really going to be powered down.
+
+
+ Next states:
+
+ CLUSTER_UP/INBOUND_COMING_UP (outbound)
+ Conditions: cluster-level setup and hardware
+ coherency complete
+ Trigger events: (spontaneous)
+
+ CLUSTER_DOWN/INBOUND_COMING_UP (outbound)
+ Conditions: cluster torn down and ready to power off
+ Trigger events: (spontaneous)
+
+
+Last man and First man selection
+--------------------------------
+
+The CPU which performs cluster tear-down operations on the outbound side
+is commonly referred to as the "last man".
+
+The CPU which performs cluster setup on the inbound side is commonly
+referred to as the "first man".
+
+The race avoidance algorithm documented above does not provide a
+mechanism to choose which CPUs should play these roles.
+
+
+Last man:
+
+When shutting down the cluster, all the CPUs involved are initially
+executing Linux and hence coherent. Therefore, ordinary spinlocks can
+be used to select a last man safely, before the CPUs become
+non-coherent.
+
+
+First man:
+
+Because CPUs may power up asynchronously in response to external wake-up
+events, a dynamic mechanism is needed to make sure that only one CPU
+attempts to play the first man role and do the cluster-level
+initialisation: any other CPUs must wait for this to complete before
+proceeding.
+
+Cluster-level initialisation may involve actions such as configuring
+coherency controls in the bus fabric.
+
+The current implementation in mcpm_head.S uses a separate mutual exclusion
+mechanism to do this arbitration. This mechanism is documented in
+detail in vlocks.txt.
+
+
+Features and Limitations
+------------------------
+
+Implementation:
+
+ The current ARM-based implementation is split between
+ arch/arm/common/mcpm_head.S (low-level inbound CPU operations) and
+ arch/arm/common/mcpm_entry.c (everything else):
+
+ __mcpm_cpu_going_down() signals the transition of a CPU to the
+ CPU_GOING_DOWN state.
+
+ __mcpm_cpu_down() signals the transition of a CPU to the CPU_DOWN
+ state.
+
+ A CPU transitions to CPU_COMING_UP and then to CPU_UP via the
+ low-level power-up code in mcpm_head.S. This could
+ involve CPU-specific setup code, but in the current
+ implementation it does not.
+
+ __mcpm_outbound_enter_critical() and __mcpm_outbound_leave_critical()
+ handle transitions from CLUSTER_UP to CLUSTER_GOING_DOWN
+ and from there to CLUSTER_DOWN or back to CLUSTER_UP (in
+ the case of an aborted cluster power-down).
+
+ These functions are more complex than the __mcpm_cpu_*()
+ functions due to the extra inter-CPU coordination which
+ is needed for safe transitions at the cluster level.
+
+ A cluster transitions from CLUSTER_DOWN back to CLUSTER_UP via
+ the low-level power-up code in mcpm_head.S. This
+ typically involves platform-specific setup code,
+ provided by the platform-specific power_up_setup
+ function registered via mcpm_sync_init.
+
+Deep topologies:
+
+ As currently described and implemented, the algorithm does not
+ support CPU topologies involving more than two levels (i.e.,
+ clusters of clusters are not supported). The algorithm could be
+ extended by replicating the cluster-level states for the
+ additional topological levels, and modifying the transition
+ rules for the intermediate (non-outermost) cluster levels.
+
+
+Colophon
+--------
+
+Originally created and documented by Dave Martin for Linaro Limited, in
+collaboration with Nicolas Pitre and Achin Gupta.
+
+Copyright (C) 2012-2013 Linaro Limited
+Distributed under the terms of Version 2 of the GNU General Public
+License, as defined in linux/COPYING.
diff --git a/Documentation/arm/firmware.txt b/Documentation/arm/firmware.txt
new file mode 100644
index 000000000000..c2e468fe7b0b
--- /dev/null
+++ b/Documentation/arm/firmware.txt
@@ -0,0 +1,88 @@
+Interface for registering and calling firmware-specific operations for ARM.
+----
+Written by Tomasz Figa <t.figa@samsung.com>
+
+Some boards are running with secure firmware running in TrustZone secure
+world, which changes the way some things have to be initialized. This makes
+a need to provide an interface for such platforms to specify available firmware
+operations and call them when needed.
+
+Firmware operations can be specified using struct firmware_ops
+
+ struct firmware_ops {
+ /*
+ * Enters CPU idle mode
+ */
+ int (*do_idle)(void);
+ /*
+ * Sets boot address of specified physical CPU
+ */
+ int (*set_cpu_boot_addr)(int cpu, unsigned long boot_addr);
+ /*
+ * Boots specified physical CPU
+ */
+ int (*cpu_boot)(int cpu);
+ /*
+ * Initializes L2 cache
+ */
+ int (*l2x0_init)(void);
+ };
+
+and then registered with register_firmware_ops function
+
+ void register_firmware_ops(const struct firmware_ops *ops)
+
+the ops pointer must be non-NULL.
+
+There is a default, empty set of operations provided, so there is no need to
+set anything if platform does not require firmware operations.
+
+To call a firmware operation, a helper macro is provided
+
+ #define call_firmware_op(op, ...) \
+ ((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
+
+the macro checks if the operation is provided and calls it or otherwise returns
+-ENOSYS to signal that given operation is not available (for example, to allow
+fallback to legacy operation).
+
+Example of registering firmware operations:
+
+ /* board file */
+
+ static int platformX_do_idle(void)
+ {
+ /* tell platformX firmware to enter idle */
+ return 0;
+ }
+
+ static int platformX_cpu_boot(int i)
+ {
+ /* tell platformX firmware to boot CPU i */
+ return 0;
+ }
+
+ static const struct firmware_ops platformX_firmware_ops = {
+ .do_idle = exynos_do_idle,
+ .cpu_boot = exynos_cpu_boot,
+ /* other operations not available on platformX */
+ };
+
+ /* init_early callback of machine descriptor */
+ static void __init board_init_early(void)
+ {
+ register_firmware_ops(&platformX_firmware_ops);
+ }
+
+Example of using a firmware operation:
+
+ /* some platform code, e.g. SMP initialization */
+
+ __raw_writel(virt_to_phys(exynos4_secondary_startup),
+ CPU1_BOOT_REG);
+
+ /* Call Exynos specific smc call */
+ if (call_firmware_op(cpu_boot, cpu) == -ENOSYS)
+ cpu_boot_legacy(...); /* Try legacy way */
+
+ gic_raise_softirq(cpumask_of(cpu), 1);
diff --git a/Documentation/arm/vlocks.txt b/Documentation/arm/vlocks.txt
new file mode 100644
index 000000000000..415960a9bab0
--- /dev/null
+++ b/Documentation/arm/vlocks.txt
@@ -0,0 +1,211 @@
+vlocks for Bare-Metal Mutual Exclusion
+======================================
+
+Voting Locks, or "vlocks" provide a simple low-level mutual exclusion
+mechanism, with reasonable but minimal requirements on the memory
+system.
+
+These are intended to be used to coordinate critical activity among CPUs
+which are otherwise non-coherent, in situations where the hardware
+provides no other mechanism to support this and ordinary spinlocks
+cannot be used.
+
+
+vlocks make use of the atomicity provided by the memory system for
+writes to a single memory location. To arbitrate, every CPU "votes for
+itself", by storing a unique number to a common memory location. The
+final value seen in that memory location when all the votes have been
+cast identifies the winner.
+
+In order to make sure that the election produces an unambiguous result
+in finite time, a CPU will only enter the election in the first place if
+no winner has been chosen and the election does not appear to have
+started yet.
+
+
+Algorithm
+---------
+
+The easiest way to explain the vlocks algorithm is with some pseudo-code:
+
+
+ int currently_voting[NR_CPUS] = { 0, };
+ int last_vote = -1; /* no votes yet */
+
+ bool vlock_trylock(int this_cpu)
+ {
+ /* signal our desire to vote */
+ currently_voting[this_cpu] = 1;
+ if (last_vote != -1) {
+ /* someone already volunteered himself */
+ currently_voting[this_cpu] = 0;
+ return false; /* not ourself */
+ }
+
+ /* let's suggest ourself */
+ last_vote = this_cpu;
+ currently_voting[this_cpu] = 0;
+
+ /* then wait until everyone else is done voting */
+ for_each_cpu(i) {
+ while (currently_voting[i] != 0)
+ /* wait */;
+ }
+
+ /* result */
+ if (last_vote == this_cpu)
+ return true; /* we won */
+ return false;
+ }
+
+ bool vlock_unlock(void)
+ {
+ last_vote = -1;
+ }
+
+
+The currently_voting[] array provides a way for the CPUs to determine
+whether an election is in progress, and plays a role analogous to the
+"entering" array in Lamport's bakery algorithm [1].
+
+However, once the election has started, the underlying memory system
+atomicity is used to pick the winner. This avoids the need for a static
+priority rule to act as a tie-breaker, or any counters which could
+overflow.
+
+As long as the last_vote variable is globally visible to all CPUs, it
+will contain only one value that won't change once every CPU has cleared
+its currently_voting flag.
+
+
+Features and limitations
+------------------------
+
+ * vlocks are not intended to be fair. In the contended case, it is the
+ _last_ CPU which attempts to get the lock which will be most likely
+ to win.
+
+ vlocks are therefore best suited to situations where it is necessary
+ to pick a unique winner, but it does not matter which CPU actually
+ wins.
+
+ * Like other similar mechanisms, vlocks will not scale well to a large
+ number of CPUs.
+
+ vlocks can be cascaded in a voting hierarchy to permit better scaling
+ if necessary, as in the following hypothetical example for 4096 CPUs:
+
+ /* first level: local election */
+ my_town = towns[(this_cpu >> 4) & 0xf];
+ I_won = vlock_trylock(my_town, this_cpu & 0xf);
+ if (I_won) {
+ /* we won the town election, let's go for the state */
+ my_state = states[(this_cpu >> 8) & 0xf];
+ I_won = vlock_lock(my_state, this_cpu & 0xf));
+ if (I_won) {
+ /* and so on */
+ I_won = vlock_lock(the_whole_country, this_cpu & 0xf];
+ if (I_won) {
+ /* ... */
+ }
+ vlock_unlock(the_whole_country);
+ }
+ vlock_unlock(my_state);
+ }
+ vlock_unlock(my_town);
+
+
+ARM implementation
+------------------
+
+The current ARM implementation [2] contains some optimisations beyond
+the basic algorithm:
+
+ * By packing the members of the currently_voting array close together,
+ we can read the whole array in one transaction (providing the number
+ of CPUs potentially contending the lock is small enough). This
+ reduces the number of round-trips required to external memory.
+
+ In the ARM implementation, this means that we can use a single load
+ and comparison:
+
+ LDR Rt, [Rn]
+ CMP Rt, #0
+
+ ...in place of code equivalent to:
+
+ LDRB Rt, [Rn]
+ CMP Rt, #0
+ LDRBEQ Rt, [Rn, #1]
+ CMPEQ Rt, #0
+ LDRBEQ Rt, [Rn, #2]
+ CMPEQ Rt, #0
+ LDRBEQ Rt, [Rn, #3]
+ CMPEQ Rt, #0
+
+ This cuts down on the fast-path latency, as well as potentially
+ reducing bus contention in contended cases.
+
+ The optimisation relies on the fact that the ARM memory system
+ guarantees coherency between overlapping memory accesses of
+ different sizes, similarly to many other architectures. Note that
+ we do not care which element of currently_voting appears in which
+ bits of Rt, so there is no need to worry about endianness in this
+ optimisation.
+
+ If there are too many CPUs to read the currently_voting array in
+ one transaction then multiple transations are still required. The
+ implementation uses a simple loop of word-sized loads for this
+ case. The number of transactions is still fewer than would be
+ required if bytes were loaded individually.
+
+
+ In principle, we could aggregate further by using LDRD or LDM, but
+ to keep the code simple this was not attempted in the initial
+ implementation.
+
+
+ * vlocks are currently only used to coordinate between CPUs which are
+ unable to enable their caches yet. This means that the
+ implementation removes many of the barriers which would be required
+ when executing the algorithm in cached memory.
+
+ packing of the currently_voting array does not work with cached
+ memory unless all CPUs contending the lock are cache-coherent, due
+ to cache writebacks from one CPU clobbering values written by other
+ CPUs. (Though if all the CPUs are cache-coherent, you should be
+ probably be using proper spinlocks instead anyway).
+
+
+ * The "no votes yet" value used for the last_vote variable is 0 (not
+ -1 as in the pseudocode). This allows statically-allocated vlocks
+ to be implicitly initialised to an unlocked state simply by putting
+ them in .bss.
+
+ An offset is added to each CPU's ID for the purpose of setting this
+ variable, so that no CPU uses the value 0 for its ID.
+
+
+Colophon
+--------
+
+Originally created and documented by Dave Martin for Linaro Limited, for
+use in ARM-based big.LITTLE platforms, with review and input gratefully
+received from Nicolas Pitre and Achin Gupta. Thanks to Nicolas for
+grabbing most of this text out of the relevant mail thread and writing
+up the pseudocode.
+
+Copyright (C) 2012-2013 Linaro Limited
+Distributed under the terms of Version 2 of the GNU General Public
+License, as defined in linux/COPYING.
+
+
+References
+----------
+
+[1] Lamport, L. "A New Solution of Dijkstra's Concurrent Programming
+ Problem", Communications of the ACM 17, 8 (August 1974), 453-455.
+
+ http://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm
+
+[2] linux/arch/arm/common/vlock.S, www.kernel.org.
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt
index 66f9cc310686..219970ba54b7 100644
--- a/Documentation/cpu-freq/governors.txt
+++ b/Documentation/cpu-freq/governors.txt
@@ -131,8 +131,8 @@ sampling_rate_min:
The sampling rate is limited by the HW transition latency:
transition_latency * 100
Or by kernel restrictions:
-If CONFIG_NO_HZ is set, the limit is 10ms fixed.
-If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the
+If CONFIG_NO_HZ_COMMON is set, the limit is 10ms fixed.
+If CONFIG_NO_HZ_COMMON is not set or nohz=off boot parameter is used, the
limits depend on the CONFIG_HZ option:
HZ=1000: min=20000us (20ms)
HZ=250: min=80000us (80ms)
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
new file mode 100644
index 000000000000..2c28f1d12f45
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
@@ -0,0 +1,11 @@
+Altera SOCFPGA Clock Manager
+
+Required properties:
+- compatible : "altr,clk-mgr"
+- reg : Should contain base address and length for Clock Manager
+
+Example:
+ clkmgr@ffd04000 {
+ compatible = "altr,clk-mgr";
+ reg = <0xffd04000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt b/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt
new file mode 100644
index 000000000000..59fa6e68d4f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt
@@ -0,0 +1,19 @@
+Broadcom Kona Family timer
+-----------------------------------------------------
+This timer is used in the following Broadcom SoCs:
+ BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
+
+Required properties:
+- compatible : "bcm,kona-timer"
+- reg : Register range for the timer
+- interrupts : interrupt for the timer
+- clock-frequency: frequency that the clock operates
+
+Example:
+ timer@35006000 {
+ compatible = "bcm,kona-timer";
+ reg = <0x35006000 0x1000>;
+ interrupts = <0x0 7 0x4>;
+ clock-frequency = <32768>;
+ };
+
diff --git a/Documentation/devicetree/bindings/arm/msm/timer.txt b/Documentation/devicetree/bindings/arm/msm/timer.txt
index 8c5907b9cae8..c6ef8f13dc7e 100644
--- a/Documentation/devicetree/bindings/arm/msm/timer.txt
+++ b/Documentation/devicetree/bindings/arm/msm/timer.txt
@@ -3,36 +3,35 @@
Properties:
- compatible : Should at least contain "qcom,msm-timer". More specific
- properties such as "qcom,msm-gpt" and "qcom,msm-dgt" specify a general
- purpose timer and a debug timer respectively.
+ properties specify which subsystem the timers are paired with.
-- interrupts : Interrupt indicating a match event.
+ "qcom,kpss-timer" - krait subsystem
+ "qcom,scss-timer" - scorpion subsystem
-- reg : Specifies the base address of the timer registers. The second region
- specifies an optional register used to configure the clock divider.
+- interrupts : Interrupts for the the debug timer, the first general purpose
+ timer, and optionally a second general purpose timer in that
+ order.
-- clock-frequency : The frequency of the timer in Hz.
+- reg : Specifies the base address of the timer registers.
+
+- clock-frequency : The frequency of the debug timer and the general purpose
+ timer(s) in Hz in that order.
Optional:
- cpu-offset : per-cpu offset used when the timer is accessed without the
- CPU remapping facilities. The offset is cpu-offset * cpu-nr.
+ CPU remapping facilities. The offset is
+ cpu-offset + (0x10000 * cpu-nr).
Example:
- timer@200a004 {
- compatible = "qcom,msm-gpt", "qcom,msm-timer";
- interrupts = <1 2 0x301>;
- reg = <0x0200a004 0x10>;
- clock-frequency = <32768>;
- cpu-offset = <0x40000>;
- };
-
- timer@200a024 {
- compatible = "qcom,msm-dgt", "qcom,msm-timer";
- interrupts = <1 3 0x301>;
- reg = <0x0200a024 0x10>,
- <0x0200a034 0x4>;
- clock-frequency = <6750000>;
+ timer@200a000 {
+ compatible = "qcom,scss-timer", "qcom,msm-timer";
+ interrupts = <1 1 0x301>,
+ <1 2 0x301>,
+ <1 3 0x301>;
+ reg = <0x0200a000 0x100>;
+ clock-frequency = <19200000>,
+ <32768>;
cpu-offset = <0x40000>;
};
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 0bf68be56fd1..2168ed31e1b0 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -6,3 +6,13 @@ Required root node properties:
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
+
+Optional:
+ - firmware node, specifying presence and type of secure firmware:
+ - compatible: only "samsung,secure-firmware" is currently supported
+ - reg: address of non-secure SYSRAM used for communication with firmware
+
+ firmware@0203F000 {
+ compatible = "samsung,secure-firmware";
+ reg = <0x0203F000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
index b5846e21cc2e..1608a54e90e1 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
@@ -1,19 +1,84 @@
NVIDIA Tegra Power Management Controller (PMC)
-Properties:
+The PMC block interacts with an external Power Management Unit. The PMC
+mostly controls the entry and exit of the system from different sleep
+modes. It provides power-gating controllers for SoC and CPU power-islands.
+
+Required properties:
- name : Should be pmc
- compatible : Should contain "nvidia,tegra<chip>-pmc".
- reg : Offset and length of the register set for the device
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+ "pclk" (The Tegra clock of that name),
+ "clk32k_in" (The 32KHz clock input to Tegra).
+
+Optional properties:
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
The PMU is an external Power Management Unit, whose interrupt output
signal is fed into the PMC. This signal is optionally inverted, and then
fed into the ARM GIC. The PMC is not involved in the detection or
handling of this interrupt signal, merely its inversion.
+- nvidia,suspend-mode : The suspend mode that the platform should use.
+ Valid values are 0, 1 and 2:
+ 0 (LP0): CPU + Core voltage off and DRAM in self-refresh
+ 1 (LP1): CPU voltage off and DRAM in self-refresh
+ 2 (LP2): CPU voltage off
+- nvidia,core-power-req-active-high : Boolean, core power request active-high
+- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high
+- nvidia,combined-power-req : Boolean, combined power request for CPU & Core
+- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
+ is enabled.
+
+Required properties when nvidia,suspend-mode is specified:
+- nvidia,cpu-pwr-good-time : CPU power good time in uS.
+- nvidia,cpu-pwr-off-time : CPU power off time in uS.
+- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
+ Core power good time in uS.
+- nvidia,core-pwr-off-time : Core power off time in uS.
+
+Required properties when nvidia,suspend-mode=<0>:
+- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector
+ The LP0 vector contains the warm boot code that is executed by AVP when
+ resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7
+ processor and always being the first boot processor when chip is power on
+ or resume from deep sleep mode. When the system is resumed from the deep
+ sleep mode, the warm boot code will restore some PLLs, clocks and then
+ bring up CPU0 for resuming the system.
Example:
+/ SoC dts including file
pmc@7000f400 {
compatible = "nvidia,tegra20-pmc";
reg = <0x7000e400 0x400>;
+ clocks = <&tegra_car 110>, <&clk32k_in>;
+ clock-names = "pclk", "clk32k_in";
nvidia,invert-interrupt;
+ nvidia,suspend-mode = <1>;
+ nvidia,cpu-pwr-good-time = <2000>;
+ nvidia,cpu-pwr-off-time = <100>;
+ nvidia,core-pwr-good-time = <3845 3845>;
+ nvidia,core-pwr-off-time = <458>;
+ nvidia,core-power-req-active-high;
+ nvidia,sys-clock-req-active-high;
+ nvidia,lp0-vec = <0xbdffd000 0x2000>;
+};
+
+/ Tegra board dts file
+{
+ ...
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clk32k_in: clock {
+ compatible = "fixed-clock";
+ reg=<0>;
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+ };
+ ...
};
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 5ddb2e9efaaa..4b87ea1194e3 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -35,36 +35,83 @@ Required properties:
Timing properties for child nodes. All are optional and default to 0.
- - gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
-
- Chip-select signal timings corresponding to GPMC_CONFIG2:
- - gpmc,cs-on: Assertion time
- - gpmc,cs-rd-off: Read deassertion time
- - gpmc,cs-wr-off: Write deassertion time
-
- ADV signal timings corresponding to GPMC_CONFIG3:
- - gpmc,adv-on: Assertion time
- - gpmc,adv-rd-off: Read deassertion time
- - gpmc,adv-wr-off: Write deassertion time
-
- WE signals timings corresponding to GPMC_CONFIG4:
- - gpmc,we-on: Assertion time
- - gpmc,we-off: Deassertion time
-
- OE signals timings corresponding to GPMC_CONFIG4:
- - gpmc,oe-on: Assertion time
- - gpmc,oe-off: Deassertion time
-
- Access time and cycle time timings corresponding to GPMC_CONFIG5:
- - gpmc,page-burst-access: Multiple access word delay
- - gpmc,access: Start-cycle to first data valid delay
- - gpmc,rd-cycle: Total read cycle time
- - gpmc,wr-cycle: Total write cycle time
+ - gpmc,sync-clk-ps: Minimum clock period for synchronous mode, in picoseconds
+
+ Chip-select signal timings (in nanoseconds) corresponding to GPMC_CONFIG2:
+ - gpmc,cs-on-ns: Assertion time
+ - gpmc,cs-rd-off-ns: Read deassertion time
+ - gpmc,cs-wr-off-ns: Write deassertion time
+
+ ADV signal timings (in nanoseconds) corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on-ns: Assertion time
+ - gpmc,adv-rd-off-ns: Read deassertion time
+ - gpmc,adv-wr-off-ns: Write deassertion time
+
+ WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
+ - gpmc,we-on-ns Assertion time
+ - gpmc,we-off-ns: Deassertion time
+
+ OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
+ - gpmc,oe-on-ns: Assertion time
+ - gpmc,oe-off-ns: Deassertion time
+
+ Access time and cycle time timings (in nanoseconds) corresponding to
+ GPMC_CONFIG5:
+ - gpmc,page-burst-access-ns: Multiple access word delay
+ - gpmc,access-ns: Start-cycle to first data valid delay
+ - gpmc,rd-cycle-ns: Total read cycle time
+ - gpmc,wr-cycle-ns: Total write cycle time
+ - gpmc,bus-turnaround-ns: Turn-around time between successive accesses
+ - gpmc,cycle2cycle-delay-ns: Delay between chip-select pulses
+ - gpmc,clk-activation-ns: GPMC clock activation time
+ - gpmc,wait-monitoring-ns: Start of wait monitoring with regard to valid
+ data
+
+Boolean timing parameters. If property is present parameter enabled and
+disabled if omitted:
+ - gpmc,adv-extra-delay: ADV signal is delayed by half GPMC clock
+ - gpmc,cs-extra-delay: CS signal is delayed by half GPMC clock
+ - gpmc,cycle2cycle-diffcsen: Add "cycle2cycle-delay" between successive
+ accesses to a different CS
+ - gpmc,cycle2cycle-samecsen: Add "cycle2cycle-delay" between successive
+ accesses to the same CS
+ - gpmc,oe-extra-delay: OE signal is delayed by half GPMC clock
+ - gpmc,we-extra-delay: WE signal is delayed by half GPMC clock
+ - gpmc,time-para-granularity: Multiply all access times by 2
The following are only applicable to OMAP3+ and AM335x:
- - gpmc,wr-access
- - gpmc,wr-data-mux-bus
-
+ - gpmc,wr-access-ns: In synchronous write mode, for single or
+ burst accesses, defines the number of
+ GPMC_FCLK cycles from start access time
+ to the GPMC_CLK rising edge used by the
+ memory device for the first data capture.
+ - gpmc,wr-data-mux-bus-ns: In address-data multiplex mode, specifies
+ the time when the first data is driven on
+ the address-data bus.
+
+GPMC chip-select settings properties for child nodes. All are optional.
+
+- gpmc,burst-length Page/burst length. Must be 4, 8 or 16.
+- gpmc,burst-wrap Enables wrap bursting
+- gpmc,burst-read Enables read page/burst mode
+- gpmc,burst-write Enables write page/burst mode
+- gpmc,device-nand Device is NAND
+- gpmc,device-width Total width of device(s) connected to a GPMC
+ chip-select in bytes. The GPMC supports 8-bit
+ and 16-bit devices and so this property must be
+ 1 or 2.
+- gpmc,mux-add-data Address and data multiplexing configuration.
+ Valid values are 1 for address-address-data
+ multiplexing mode and 2 for address-data
+ multiplexing mode.
+- gpmc,sync-read Enables synchronous read. Defaults to asynchronous
+ is this is not set.
+- gpmc,sync-write Enables synchronous writes. Defaults to asynchronous
+ is this is not set.
+- gpmc,wait-pin Wait-pin used by client. Must be less than
+ "gpmc,num-waitpins".
+- gpmc,wait-on-read Enables wait monitoring on reads.
+- gpmc,wait-on-write Enables wait monitoring on writes.
Example for an AM33xx board:
diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
new file mode 100644
index 000000000000..bd0c8416a5c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
@@ -0,0 +1,18 @@
+Device Tree Clock bindings for Altera's SoCFPGA platform
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of the following:
+ "altr,socfpga-pll-clock" - for a PLL clock
+ "altr,socfpga-perip-clock" - The peripheral clock divided from the
+ PLL clock.
+- reg : shall be the control register offset from CLOCK_MANAGER's base for the clock.
+- clocks : shall be the input parent clock phandle for the clock. This is
+ either an oscillator or a pll output.
+- #clock-cells : from common clock binding, shall be set to 0.
+
+Optional properties:
+- fixed-divider : If clocks have a fixed divider value, use this property.
diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
new file mode 100644
index 000000000000..ea5e26f16aec
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
@@ -0,0 +1,288 @@
+* Samsung Exynos4 Clock Controller
+
+The Exynos4 clock controller generates and supplies clock to various controllers
+within the Exynos4 SoC. The clock binding described here is applicable to all
+SoC's in the Exynos4 family.
+
+Required Properties:
+
+- comptible: should be one of the following.
+ - "samsung,exynos4210-clock" - controller compatible with Exynos4210 SoC.
+ - "samsung,exynos4412-clock" - controller compatible with Exynos4412 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume. Some of the clocks are available only on a particular
+Exynos4 SoC and this is specified where applicable.
+
+
+ [Core Clocks]
+
+ Clock ID SoC (if specific)
+ -----------------------------------------------
+
+ xxti 1
+ xusbxti 2
+ fin_pll 3
+ fout_apll 4
+ fout_mpll 5
+ fout_epll 6
+ fout_vpll 7
+ sclk_apll 8
+ sclk_mpll 9
+ sclk_epll 10
+ sclk_vpll 11
+ arm_clk 12
+ aclk200 13
+ aclk100 14
+ aclk160 15
+ aclk133 16
+ mout_mpll_user_t 17 Exynos4x12
+ mout_mpll_user_c 18 Exynos4x12
+ mout_core 19
+ mout_apll 20
+
+
+ [Clock Gate for Special Clocks]
+
+ Clock ID SoC (if specific)
+ -----------------------------------------------
+
+ sclk_fimc0 128
+ sclk_fimc1 129
+ sclk_fimc2 130
+ sclk_fimc3 131
+ sclk_cam0 132
+ sclk_cam1 133
+ sclk_csis0 134
+ sclk_csis1 135
+ sclk_hdmi 136
+ sclk_mixer 137
+ sclk_dac 138
+ sclk_pixel 139
+ sclk_fimd0 140
+ sclk_mdnie0 141 Exynos4412
+ sclk_mdnie_pwm0 12 142 Exynos4412
+ sclk_mipi0 143
+ sclk_audio0 144
+ sclk_mmc0 145
+ sclk_mmc1 146
+ sclk_mmc2 147
+ sclk_mmc3 148
+ sclk_mmc4 149
+ sclk_sata 150 Exynos4210
+ sclk_uart0 151
+ sclk_uart1 152
+ sclk_uart2 153
+ sclk_uart3 154
+ sclk_uart4 155
+ sclk_audio1 156
+ sclk_audio2 157
+ sclk_spdif 158
+ sclk_spi0 159
+ sclk_spi1 160
+ sclk_spi2 161
+ sclk_slimbus 162
+ sclk_fimd1 163 Exynos4210
+ sclk_mipi1 164 Exynos4210
+ sclk_pcm1 165
+ sclk_pcm2 166
+ sclk_i2s1 167
+ sclk_i2s2 168
+ sclk_mipihsi 169 Exynos4412
+ sclk_mfc 170
+ sclk_pcm0 171
+ sclk_g3d 172
+ sclk_pwm_isp 173 Exynos4x12
+ sclk_spi0_isp 174 Exynos4x12
+ sclk_spi1_isp 175 Exynos4x12
+ sclk_uart_isp 176 Exynos4x12
+
+ [Peripheral Clock Gates]
+
+ Clock ID SoC (if specific)
+ -----------------------------------------------
+
+ fimc0 256
+ fimc1 257
+ fimc2 258
+ fimc3 259
+ csis0 260
+ csis1 261
+ jpeg 262
+ smmu_fimc0 263
+ smmu_fimc1 264
+ smmu_fimc2 265
+ smmu_fimc3 266
+ smmu_jpeg 267
+ vp 268
+ mixer 269
+ tvenc 270 Exynos4210
+ hdmi 271
+ smmu_tv 272
+ mfc 273
+ smmu_mfcl 274
+ smmu_mfcr 275
+ g3d 276
+ g2d 277 Exynos4210
+ rotator 278 Exynos4210
+ mdma 279 Exynos4210
+ smmu_g2d 280 Exynos4210
+ smmu_rotator 281 Exynos4210
+ smmu_mdma 282 Exynos4210
+ fimd0 283
+ mie0 284
+ mdnie0 285 Exynos4412
+ dsim0 286
+ smmu_fimd0 287
+ fimd1 288 Exynos4210
+ mie1 289 Exynos4210
+ dsim1 290 Exynos4210
+ smmu_fimd1 291 Exynos4210
+ pdma0 292
+ pdma1 293
+ pcie_phy 294
+ sata_phy 295 Exynos4210
+ tsi 296
+ sdmmc0 297
+ sdmmc1 298
+ sdmmc2 299
+ sdmmc3 300
+ sdmmc4 301
+ sata 302 Exynos4210
+ sromc 303
+ usb_host 304
+ usb_device 305
+ pcie 306
+ onenand 307
+ nfcon 308
+ smmu_pcie 309
+ gps 310
+ smmu_gps 311
+ uart0 312
+ uart1 313
+ uart2 314
+ uart3 315
+ uart4 316
+ i2c0 317
+ i2c1 318
+ i2c2 319
+ i2c3 320
+ i2c4 321
+ i2c5 322
+ i2c6 323
+ i2c7 324
+ i2c_hdmi 325
+ tsadc 326
+ spi0 327
+ spi1 328
+ spi2 329
+ i2s1 330
+ i2s2 331
+ pcm0 332
+ i2s0 333
+ pcm1 334
+ pcm2 335
+ pwm 336
+ slimbus 337
+ spdif 338
+ ac97 339
+ modemif 340
+ chipid 341
+ sysreg 342
+ hdmi_cec 343
+ mct 344
+ wdt 345
+ rtc 346
+ keyif 347
+ audss 348
+ mipi_hsi 349 Exynos4210
+ mdma2 350 Exynos4210
+ pixelasyncm0 351
+ pixelasyncm1 352
+ fimc_lite0 353 Exynos4x12
+ fimc_lite1 354 Exynos4x12
+ ppmuispx 355 Exynos4x12
+ ppmuispmx 356 Exynos4x12
+ fimc_isp 357 Exynos4x12
+ fimc_drc 358 Exynos4x12
+ fimc_fd 359 Exynos4x12
+ mcuisp 360 Exynos4x12
+ gicisp 361 Exynos4x12
+ smmu_isp 362 Exynos4x12
+ smmu_drc 363 Exynos4x12
+ smmu_fd 364 Exynos4x12
+ smmu_lite0 365 Exynos4x12
+ smmu_lite1 366 Exynos4x12
+ mcuctl_isp 367 Exynos4x12
+ mpwm_isp 368 Exynos4x12
+ i2c0_isp 369 Exynos4x12
+ i2c1_isp 370 Exynos4x12
+ mtcadc_isp 371 Exynos4x12
+ pwm_isp 372 Exynos4x12
+ wdt_isp 373 Exynos4x12
+ uart_isp 374 Exynos4x12
+ asyncaxim 375 Exynos4x12
+ smmu_ispcx 376 Exynos4x12
+ spi0_isp 377 Exynos4x12
+ spi1_isp 378 Exynos4x12
+ pwm_isp_sclk 379 Exynos4x12
+ spi0_isp_sclk 380 Exynos4x12
+ spi1_isp_sclk 381 Exynos4x12
+ uart_isp_sclk 382 Exynos4x12
+
+ [Mux Clocks]
+
+ Clock ID SoC (if specific)
+ -----------------------------------------------
+
+ mout_fimc0 384
+ mout_fimc1 385
+ mout_fimc2 386
+ mout_fimc3 387
+ mout_cam0 388
+ mout_cam1 389
+ mout_csis0 390
+ mout_csis1 391
+ mout_g3d0 392
+ mout_g3d1 393
+ mout_g3d 394
+ aclk400_mcuisp 395 Exynos4x12
+
+ [Div Clocks]
+
+ Clock ID SoC (if specific)
+ -----------------------------------------------
+
+ div_isp0 450 Exynos4x12
+ div_isp1 451 Exynos4x12
+ div_mcuisp0 452 Exynos4x12
+ div_mcuisp1 453 Exynos4x12
+ div_aclk200 454 Exynos4x12
+ div_aclk400_mcuisp 455 Exynos4x12
+
+
+Example 1: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x10030000 {
+ compatible = "samsung,exynos4210-clock";
+ reg = <0x10030000 0x20000>;
+ #clock-cells = <1>;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@13820000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x13820000 0x100>;
+ interrupts = <0 54 0>;
+ clocks = <&clock 314>, <&clock 153>;
+ clock-names = "uart", "clk_uart_baud0";
+ };
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
new file mode 100644
index 000000000000..781a6276adf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -0,0 +1,177 @@
+* Samsung Exynos5250 Clock Controller
+
+The Exynos5250 clock controller generates and supplies clock to various
+controllers within the Exynos5250 SoC.
+
+Required Properties:
+
+- comptible: should be one of the following.
+ - "samsung,exynos5250-clock" - controller compatible with Exynos5250 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume.
+
+
+ [Core Clocks]
+
+ Clock ID
+ ----------------------------
+
+ fin_pll 1
+
+ [Clock Gate for Special Clocks]
+
+ Clock ID
+ ----------------------------
+
+ sclk_cam_bayer 128
+ sclk_cam0 129
+ sclk_cam1 130
+ sclk_gscl_wa 131
+ sclk_gscl_wb 132
+ sclk_fimd1 133
+ sclk_mipi1 134
+ sclk_dp 135
+ sclk_hdmi 136
+ sclk_pixel 137
+ sclk_audio0 138
+ sclk_mmc0 139
+ sclk_mmc1 140
+ sclk_mmc2 141
+ sclk_mmc3 142
+ sclk_sata 143
+ sclk_usb3 144
+ sclk_jpeg 145
+ sclk_uart0 146
+ sclk_uart1 147
+ sclk_uart2 148
+ sclk_uart3 149
+ sclk_pwm 150
+ sclk_audio1 151
+ sclk_audio2 152
+ sclk_spdif 153
+ sclk_spi0 154
+ sclk_spi1 155
+ sclk_spi2 156
+
+
+ [Peripheral Clock Gates]
+
+ Clock ID
+ ----------------------------
+
+ gscl0 256
+ gscl1 257
+ gscl2 258
+ gscl3 259
+ gscl_wa 260
+ gscl_wb 261
+ smmu_gscl0 262
+ smmu_gscl1 263
+ smmu_gscl2 264
+ smmu_gscl3 265
+ mfc 266
+ smmu_mfcl 267
+ smmu_mfcr 268
+ rotator 269
+ jpeg 270
+ mdma1 271
+ smmu_rotator 272
+ smmu_jpeg 273
+ smmu_mdma1 274
+ pdma0 275
+ pdma1 276
+ sata 277
+ usbotg 278
+ mipi_hsi 279
+ sdmmc0 280
+ sdmmc1 281
+ sdmmc2 282
+ sdmmc3 283
+ sromc 284
+ usb2 285
+ usb3 286
+ sata_phyctrl 287
+ sata_phyi2c 288
+ uart0 289
+ uart1 290
+ uart2 291
+ uart3 292
+ uart4 293
+ i2c0 294
+ i2c1 295
+ i2c2 296
+ i2c3 297
+ i2c4 298
+ i2c5 299
+ i2c6 300
+ i2c7 301
+ i2c_hdmi 302
+ adc 303
+ spi0 304
+ spi1 305
+ spi2 306
+ i2s1 307
+ i2s2 308
+ pcm1 309
+ pcm2 310
+ pwm 311
+ spdif 312
+ ac97 313
+ hsi2c0 314
+ hsi2c1 315
+ hs12c2 316
+ hs12c3 317
+ chipid 318
+ sysreg 319
+ pmu 320
+ cmu_top 321
+ cmu_core 322
+ cmu_mem 323
+ tzpc0 324
+ tzpc1 325
+ tzpc2 326
+ tzpc3 327
+ tzpc4 328
+ tzpc5 329
+ tzpc6 330
+ tzpc7 331
+ tzpc8 332
+ tzpc9 333
+ hdmi_cec 334
+ mct 335
+ wdt 336
+ rtc 337
+ tmu 338
+ fimd1 339
+ mie1 340
+ dsim0 341
+ dp 342
+ mixer 343
+ hdmi 345
+
+Example 1: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x10010000 {
+ compatible = "samsung,exynos5250-clock";
+ reg = <0x10010000 0x30000>;
+ #clock-cells = <1>;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@13820000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x13820000 0x100>;
+ interrupts = <0 54 0>;
+ clocks = <&clock 314>, <&clock 153>;
+ clock-names = "uart", "clk_uart_baud0";
+ };
diff --git a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
new file mode 100644
index 000000000000..4499e9966bc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
@@ -0,0 +1,61 @@
+* Samsung Exynos5440 Clock Controller
+
+The Exynos5440 clock controller generates and supplies clock to various
+controllers within the Exynos5440 SoC.
+
+Required Properties:
+
+- comptible: should be "samsung,exynos5440-clock".
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+The following is the list of clocks generated by the controller. Each clock is
+assigned an identifier and client nodes use this identifier to specify the
+clock which they consume.
+
+
+ [Core Clocks]
+
+ Clock ID
+ ----------------------------
+
+ xtal 1
+ arm_clk 2
+
+ [Peripheral Clock Gates]
+
+ Clock ID
+ ----------------------------
+
+ spi_baud 16
+ pb0_250 17
+ pr0_250 18
+ pr1_250 19
+ b_250 20
+ b_125 21
+ b_200 22
+ sata 23
+ usb 24
+ gmac0 25
+ cs250 26
+ pb0_250_o 27
+ pr0_250_o 28
+ pr1_250_o 29
+ b_250_o 30
+ b_125_o 31
+ b_200_o 32
+ sata_o 33
+ usb_o 34
+ gmac0_o 35
+ cs250_o 36
+
+Example: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x10010000 {
+ compatible = "samsung,exynos5440-clock";
+ reg = <0x160000 0x10000>;
+ #clock-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt
new file mode 100644
index 000000000000..ab1a56e9de9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx27-clock.txt
@@ -0,0 +1,117 @@
+* Clock bindings for Freescale i.MX27
+
+Required properties:
+- compatible: Should be "fsl,imx27-ccm"
+- reg: Address and length of the register set
+- interrupts: Should contain CCM interrupt
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. The following is a full list of i.MX27
+clocks and IDs.
+
+ Clock ID
+ -----------------------
+ dummy 0
+ ckih 1
+ ckil 2
+ mpll 3
+ spll 4
+ mpll_main2 5
+ ahb 6
+ ipg 7
+ nfc_div 8
+ per1_div 9
+ per2_div 10
+ per3_div 11
+ per4_div 12
+ vpu_sel 13
+ vpu_div 14
+ usb_div 15
+ cpu_sel 16
+ clko_sel 17
+ cpu_div 18
+ clko_div 19
+ ssi1_sel 20
+ ssi2_sel 21
+ ssi1_div 22
+ ssi2_div 23
+ clko_en 24
+ ssi2_ipg_gate 25
+ ssi1_ipg_gate 26
+ slcdc_ipg_gate 27
+ sdhc3_ipg_gate 28
+ sdhc2_ipg_gate 29
+ sdhc1_ipg_gate 30
+ scc_ipg_gate 31
+ sahara_ipg_gate 32
+ rtc_ipg_gate 33
+ pwm_ipg_gate 34
+ owire_ipg_gate 35
+ lcdc_ipg_gate 36
+ kpp_ipg_gate 37
+ iim_ipg_gate 38
+ i2c2_ipg_gate 39
+ i2c1_ipg_gate 40
+ gpt6_ipg_gate 41
+ gpt5_ipg_gate 42
+ gpt4_ipg_gate 43
+ gpt3_ipg_gate 44
+ gpt2_ipg_gate 45
+ gpt1_ipg_gate 46
+ gpio_ipg_gate 47
+ fec_ipg_gate 48
+ emma_ipg_gate 49
+ dma_ipg_gate 50
+ cspi3_ipg_gate 51
+ cspi2_ipg_gate 52
+ cspi1_ipg_gate 53
+ nfc_baud_gate 54
+ ssi2_baud_gate 55
+ ssi1_baud_gate 56
+ vpu_baud_gate 57
+ per4_gate 58
+ per3_gate 59
+ per2_gate 60
+ per1_gate 61
+ usb_ahb_gate 62
+ slcdc_ahb_gate 63
+ sahara_ahb_gate 64
+ lcdc_ahb_gate 65
+ vpu_ahb_gate 66
+ fec_ahb_gate 67
+ emma_ahb_gate 68
+ emi_ahb_gate 69
+ dma_ahb_gate 70
+ csi_ahb_gate 71
+ brom_ahb_gate 72
+ ata_ahb_gate 73
+ wdog_ipg_gate 74
+ usb_ipg_gate 75
+ uart6_ipg_gate 76
+ uart5_ipg_gate 77
+ uart4_ipg_gate 78
+ uart3_ipg_gate 79
+ uart2_ipg_gate 80
+ uart1_ipg_gate 81
+ ckih_div1p5 82
+ fpm 83
+ mpll_osc_sel 84
+ mpll_sel 85
+
+Examples:
+
+clks: ccm@10027000{
+ compatible = "fsl,imx27-ccm";
+ reg = <0x10027000 0x1000>;
+ #clock-cells = <1>;
+};
+
+uart1: serial@1000a000 {
+ compatible = "fsl,imx27-uart", "fsl,imx21-uart";
+ reg = <0x1000a000 0x1000>;
+ interrupts = <20>;
+ clocks = <&clks 81>, <&clks 61>;
+ clock-names = "ipg", "per";
+ status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
new file mode 100644
index 000000000000..d6cb083b90a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
@@ -0,0 +1,303 @@
+NVIDIA Tegra114 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,tegra114-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the CAR.
+
+ The first 160 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+ registers. These IDs often match those in the CAR's RST_DEVICES registers,
+ but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
+ this case, those clocks are assigned IDs above 160 in order to highlight
+ this issue. Implementations that interpret these clock IDs as bit values
+ within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
+ explicitly handle these special cases.
+
+ The balance of the clocks controlled by the CAR are assigned IDs of 160 and
+ above.
+
+ 0 unassigned
+ 1 unassigned
+ 2 unassigned
+ 3 unassigned
+ 4 rtc
+ 5 timer
+ 6 uarta
+ 7 unassigned (register bit affects uartb and vfir)
+ 8 unassigned
+ 9 sdmmc2
+ 10 unassigned (register bit affects spdif_in and spdif_out)
+ 11 i2s1
+ 12 i2c1
+ 13 ndflash
+ 14 sdmmc1
+ 15 sdmmc4
+ 16 unassigned
+ 17 pwm
+ 18 i2s2
+ 19 epp
+ 20 unassigned (register bit affects vi and vi_sensor)
+ 21 2d
+ 22 usbd
+ 23 isp
+ 24 3d
+ 25 unassigned
+ 26 disp2
+ 27 disp1
+ 28 host1x
+ 29 vcp
+ 30 i2s0
+ 31 unassigned
+
+ 32 unassigned
+ 33 unassigned
+ 34 apbdma
+ 35 unassigned
+ 36 kbc
+ 37 unassigned
+ 38 unassigned
+ 39 unassigned (register bit affects fuse and fuse_burn)
+ 40 kfuse
+ 41 sbc1
+ 42 nor
+ 43 unassigned
+ 44 sbc2
+ 45 unassigned
+ 46 sbc3
+ 47 i2c5
+ 48 dsia
+ 49 unassigned
+ 50 mipi
+ 51 hdmi
+ 52 csi
+ 53 unassigned
+ 54 i2c2
+ 55 uartc
+ 56 mipi-cal
+ 57 emc
+ 58 usb2
+ 59 usb3
+ 60 msenc
+ 61 vde
+ 62 bsea
+ 63 bsev
+
+ 64 unassigned
+ 65 uartd
+ 66 unassigned
+ 67 i2c3
+ 68 sbc4
+ 69 sdmmc3
+ 70 unassigned
+ 71 owr
+ 72 afi
+ 73 csite
+ 74 unassigned
+ 75 unassigned
+ 76 la
+ 77 trace
+ 78 soc_therm
+ 79 dtv
+ 80 ndspeed
+ 81 i2cslow
+ 82 dsib
+ 83 tsec
+ 84 unassigned
+ 85 unassigned
+ 86 unassigned
+ 87 unassigned
+ 88 unassigned
+ 89 xusb_host
+ 90 unassigned
+ 91 msenc
+ 92 csus
+ 93 unassigned
+ 94 unassigned
+ 95 unassigned (bit affects xusb_dev and xusb_dev_src)
+
+ 96 unassigned
+ 97 unassigned
+ 98 unassigned
+ 99 mselect
+ 100 tsensor
+ 101 i2s3
+ 102 i2s4
+ 103 i2c4
+ 104 sbc5
+ 105 sbc6
+ 106 d_audio
+ 107 apbif
+ 108 dam0
+ 109 dam1
+ 110 dam2
+ 111 hda2codec_2x
+ 112 unassigned
+ 113 audio0_2x
+ 114 audio1_2x
+ 115 audio2_2x
+ 116 audio3_2x
+ 117 audio4_2x
+ 118 spdif_2x
+ 119 actmon
+ 120 extern1
+ 121 extern2
+ 122 extern3
+ 123 unassigned
+ 124 unassigned
+ 125 hda
+ 126 unassigned
+ 127 se
+
+ 128 hda2hdmi
+ 129 unassigned
+ 130 unassigned
+ 131 unassigned
+ 132 unassigned
+ 133 unassigned
+ 134 unassigned
+ 135 unassigned
+ 136 unassigned
+ 137 unassigned
+ 138 unassigned
+ 139 unassigned
+ 140 unassigned
+ 141 unassigned
+ 142 unassigned
+ 143 unassigned (bit affects xusb_falcon_src, xusb_fs_src,
+ xusb_host_src and xusb_ss_src)
+ 144 cilab
+ 145 cilcd
+ 146 cile
+ 147 dsialp
+ 148 dsiblp
+ 149 unassigned
+ 150 dds
+ 151 unassigned
+ 152 dp2
+ 153 amx
+ 154 adx
+ 155 unassigned (bit affects dfll_ref and dfll_soc)
+ 156 xusb_ss
+
+ 192 uartb
+ 193 vfir
+ 194 spdif_in
+ 195 spdif_out
+ 196 vi
+ 197 vi_sensor
+ 198 fuse
+ 199 fuse_burn
+ 200 clk_32k
+ 201 clk_m
+ 202 clk_m_div2
+ 203 clk_m_div4
+ 204 pll_ref
+ 205 pll_c
+ 206 pll_c_out1
+ 207 pll_c2
+ 208 pll_c3
+ 209 pll_m
+ 210 pll_m_out1
+ 211 pll_p
+ 212 pll_p_out1
+ 213 pll_p_out2
+ 214 pll_p_out3
+ 215 pll_p_out4
+ 216 pll_a
+ 217 pll_a_out0
+ 218 pll_d
+ 219 pll_d_out0
+ 220 pll_d2
+ 221 pll_d2_out0
+ 222 pll_u
+ 223 pll_u_480M
+ 224 pll_u_60M
+ 225 pll_u_48M
+ 226 pll_u_12M
+ 227 pll_x
+ 228 pll_x_out0
+ 229 pll_re_vco
+ 230 pll_re_out
+ 231 pll_e_out0
+ 232 spdif_in_sync
+ 233 i2s0_sync
+ 234 i2s1_sync
+ 235 i2s2_sync
+ 236 i2s3_sync
+ 237 i2s4_sync
+ 238 vimclk_sync
+ 239 audio0
+ 240 audio1
+ 241 audio2
+ 242 audio3
+ 243 audio4
+ 244 spdif
+ 245 clk_out_1
+ 246 clk_out_2
+ 247 clk_out_3
+ 248 blink
+ 252 xusb_host_src
+ 253 xusb_falcon_src
+ 254 xusb_fs_src
+ 255 xusb_ss_src
+ 256 xusb_dev_src
+ 257 xusb_dev
+ 258 xusb_hs_src
+ 259 sclk
+ 260 hclk
+ 261 pclk
+ 262 cclk_g
+ 263 cclk_lp
+ 264 dfll_ref
+ 265 dfll_soc
+
+Example SoC include file:
+
+/ {
+ tegra_car: clock {
+ compatible = "nvidia,tegra114-car";
+ reg = <0x60006000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ usb@c5004000 {
+ clocks = <&tegra_car 58>; /* usb2 */
+ };
+};
+
+Example board file:
+
+/ {
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc: clock@0 {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <12000000>;
+ };
+
+ clk_32k: clock@1 {
+ compatible = "fixed-clock";
+ reg = <1>;
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+ };
+
+ &tegra_car {
+ clocks = <&clk_32k> <&osc>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
index 0921fac73528..e885680f6b45 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -120,8 +120,8 @@ Required properties :
90 clk_d
91 unassigned
92 sus
- 93 cdev1
- 94 cdev2
+ 93 cdev2
+ 94 cdev1
95 unassigned
96 uart2
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
new file mode 100644
index 000000000000..5c65eccd0e56
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
@@ -0,0 +1,15 @@
+Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
+Currently only i.MX27 is supported.
+
+Required properties:
+- compatible : Should be "fsl,<soc>-sahara"
+- reg : Should contain SAHARA registers location and length
+- interrupts : Should contain SAHARA interrupt number
+
+Example:
+
+sah@10025000 {
+ compatible = "fsl,imx27-sahara";
+ reg = < 0x10025000 0x800>;
+ interrupts = <75>;
+};
diff --git a/Documentation/devicetree/bindings/drm/exynos/g2d.txt b/Documentation/devicetree/bindings/drm/exynos/g2d.txt
deleted file mode 100644
index 1eb124d35a99..000000000000
--- a/Documentation/devicetree/bindings/drm/exynos/g2d.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Samsung 2D Graphic Accelerator using DRM frame work
-
-Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer.
-We set the drawing-context registers for configuring rendering parameters and
-then start rendering.
-This driver is for SOCs which contain G2D IPs with version 4.1.
-
-Required properties:
- -compatible:
- should be "samsung,exynos-g2d-41".
- -reg:
- physical base address of the controller and length
- of memory mapped region.
- -interrupts:
- interrupt combiner values.
-
-Example:
- g2d {
- compatible = "samsung,exynos-g2d-41";
- reg = <0x10850000 0x1000>;
- interrupts = <0 91 0>;
- };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt b/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
deleted file mode 100644
index f4dc5233167e..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-VIA/Wondermedia VT8500 GPIO Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-gpio", "wm,wm8505-gpio"
- or "wm,wm8650-gpio" depending on your SoC
-- reg : Should contain 1 register range (address and length)
-- #gpio-cells : should be <3>.
- 1) bank
- 2) pin number
- 3) flags - should be 0
-
-Example:
-
- gpio: gpio-controller@d8110000 {
- compatible = "via,vt8500-gpio";
- gpio-controller;
- reg = <0xd8110000 0x10000>;
- #gpio-cells = <3>;
- };
-
- vibrate {
- gpios = <&gpio 0 1 0>; /* Bank 0, Pin 1, No flags */
- };
diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index e13787498bcf..9b3f1d4a88d6 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -1,7 +1,10 @@
* Marvell PXA GPIO controller
Required properties:
-- compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio"
+- compatible : Should be "intel,pxa25x-gpio", "intel,pxa26x-gpio",
+ "intel,pxa27x-gpio", "intel,pxa3xx-gpio",
+ "marvell,pxa93x-gpio", "marvell,mmp-gpio" or
+ "marvell,mmp2-gpio".
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all gpio pins.
There're three gpio interrupts in arch-pxa, and they're gpio0,
@@ -18,7 +21,7 @@ Required properties:
Example:
gpio: gpio@d4019000 {
- compatible = "mrvl,mmp-gpio";
+ compatible = "marvell,mmp-gpio";
reg = <0xd4019000 0x1000>;
interrupts = <49>;
interrupt-name = "gpio_mux";
diff --git a/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt b/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt
new file mode 100644
index 000000000000..6616d15866a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt
@@ -0,0 +1,18 @@
+HWRNG support for the timeriomem_rng driver
+
+Required properties:
+- compatible : "timeriomem_rng"
+- reg : base address to sample from
+- period : wait time in microseconds to use between samples
+
+N.B. currently 'reg' must be four bytes wide and aligned
+
+Example:
+
+hwrng@44 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "timeriomem_rng";
+ reg = <0x44 0x04>;
+ period = <1000000>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
new file mode 100644
index 000000000000..1ac8ea8ade1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
@@ -0,0 +1,80 @@
+GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
+=================================================================
+This uses GPIO lines and a challenge & response mechanism to arbitrate who is
+the master of an I2C bus in a multimaster situation.
+
+In many cases using GPIOs to arbitrate is not needed and a design can use
+the standard I2C multi-master rules. Using GPIOs is generally useful in
+the case where there is a device on the bus that has errata and/or bugs
+that makes standard multimaster mode not feasible.
+
+
+Algorithm:
+
+All masters on the bus have a 'bus claim' line which is an output that the
+others can see. These are all active low with pull-ups enabled. We'll
+describe these lines as:
+
+- OUR_CLAIM: output from us signaling to other hosts that we want the bus
+- THEIR_CLAIMS: output from others signaling that they want the bus
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say we want to claim the bus. We:
+1. Assert OUR_CLAIM.
+2. Waits a little bit for the other sides to notice (slew time, say 10
+ microseconds).
+3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we are
+ done.
+4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arb-gpio-challenge
+- our-claim-gpio: The GPIO that we use to claim the bus.
+- their-claim-gpios: The GPIOs that the other sides use to claim the bus.
+ Note that some implementations may only support a single other master.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+ Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
+
+
+Example:
+ i2c@12CA0000 {
+ compatible = "acme,some-i2c-device";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c-arbitrator {
+ compatible = "i2c-arb-gpio-challenge";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c-parent = <&{/i2c@12CA0000}>;
+
+ our-claim-gpio = <&gpf0 3 1>;
+ their-claim-gpios = <&gpe0 4 1>;
+ slew-delay-us = <10>;
+ wait-retry-us = <3000>;
+ wait-free-us = <50000>;
+
+ i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@52 {
+ // Normal I2C device
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000000000000..0f6355ce39b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: "google,cros-ec-keyb"
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ keypad,num-rows = <8>;
+ keypad,num-columns = <13>;
+ google,needs-ghost-filter;
+ /*
+ * Keymap entries take the form of 0xRRCCKKKK where
+ * RR=Row CC=Column KKKK=Key Code
+ * The values below are for a US keyboard layout and
+ * are taken from the Linux driver. Note that the
+ * 102ND key is not used for US keyboards.
+ */
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003b 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACE L_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x0200001d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x04000061 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002 0x06020004 0x06030005 0x06040003
+ /* 8 7 0 9 */
+ 0x06050009 0x06060008 0x0608000b 0x0609000a
+ /* L_ALT DOWN RIGHT Q */
+ 0x060a0038 0x060b006c 0x060c006a 0x07010010
+ /* E R W I */
+ 0x07020012 0x07030013 0x07040011 0x07050017
+ /* U R_SHIFT P O */
+ 0x07060016 0x07070036 0x07080019 0x07090018
+ /* UP LEFT */
+ 0x070b0067 0x070c0069>;
+};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
index 7f9fb85f5456..e7f4dc14eff2 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
@@ -2,7 +2,7 @@ Allwinner Sunxi Interrupt Controller
Required properties:
-- compatible : should be "allwinner,sunxi-ic"
+- compatible : should be "allwinner,sun4i-ic"
- reg : Specifies base physical address and size of the registers.
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
@@ -97,7 +97,7 @@ The interrupt sources are as follows:
Example:
intc: interrupt-controller {
- compatible = "allwinner,sunxi-ic";
+ compatible = "allwinner,sun4i-ic";
reg = <0x01c20400 0x400>;
interrupt-controller;
#interrupt-cells = <2>;
diff --git a/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
new file mode 100644
index 000000000000..c54c5a9a2a90
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt
@@ -0,0 +1,53 @@
+Samsung S3C24XX Interrupt Controllers
+
+The S3C24XX SoCs contain a custom set of interrupt controllers providing a
+varying number of interrupt sources. The set consists of a main- and sub-
+controller and on newer SoCs even a second main controller.
+
+Required properties:
+- compatible: Compatible property value should be "samsung,s3c2410-irq"
+ for machines before s3c2416 and "samsung,s3c2416-irq" for s3c2416 and later.
+
+- reg: Physical base address of the controller and length of memory mapped
+ region.
+
+- interrupt-controller : Identifies the node as an interrupt controller
+
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value shall be 4 and interrupt descriptor shall
+ have the following format:
+ <ctrl_num parent_irq ctrl_irq type>
+
+ ctrl_num contains the controller to use:
+ - 0 ... main controller
+ - 1 ... sub controller
+ - 2 ... second main controller on s3c2416 and s3c2450
+ parent_irq contains the parent bit in the main controller and will be
+ ignored in main controllers
+ ctrl_irq contains the interrupt bit of the controller
+ type contains the trigger type to use
+
+Example:
+
+ interrupt-controller@4a000000 {
+ compatible = "samsung,s3c2410-irq";
+ reg = <0x4a000000 0x100>;
+ interrupt-controller;
+ #interrupt-cells=<4>;
+ };
+
+ [...]
+
+ serial@50000000 {
+ compatible = "samsung,s3c2410-uart";
+ reg = <0x50000000 0x4000>;
+ interrupt-parent = <&subintc>;
+ interrupts = <1 28 0 4>, <1 28 1 4>;
+ };
+
+ rtc@57000000 {
+ compatible = "samsung,s3c2410-rtc";
+ reg = <0x57000000 0x100>;
+ interrupt-parent = <&intc>;
+ interrupts = <0 30 0 3>, <0 8 0 3>;
+ };
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 67ec3d4ccc7f..bf0182d8da25 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -21,3 +21,24 @@ Required properties:
- samsung,mfc-l : Base address of the second memory bank used by MFC
for DMA contiguous memory allocation and its size.
+
+Optional properties:
+ - samsung,power-domain : power-domain property defined with a phandle
+ to respective power domain.
+
+Example:
+SoC specific DT entry:
+
+mfc: codec@13400000 {
+ compatible = "samsung,mfc-v5";
+ reg = <0x13400000 0x10000>;
+ interrupts = <0 94 0>;
+ samsung,power-domain = <&pd_mfc>;
+};
+
+Board specific DT entry:
+
+codec@13400000 {
+ samsung,mfc-r = <0x43000000 0x800000>;
+ samsung,mfc-l = <0x51000000 0x800000>;
+};
diff --git a/Documentation/devicetree/bindings/mfd/as3711.txt b/Documentation/devicetree/bindings/mfd/as3711.txt
new file mode 100644
index 000000000000..d98cf18c721c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/as3711.txt
@@ -0,0 +1,73 @@
+AS3711 is an I2C PMIC from Austria MicroSystems with multiple DCDC and LDO power
+supplies, a battery charger and an RTC. So far only bindings for the two stepup
+DCDC converters are defined. Other DCDC and LDO supplies are configured, using
+standard regulator properties, they must belong to a sub-node, called
+"regulators" and be called "sd1" to "sd4" and "ldo1" to "ldo8." Stepup converter
+configuration should be placed in a subnode, called "backlight."
+
+Compulsory properties:
+- compatible : must be "ams,as3711"
+- reg : specifies the I2C address
+
+To use the SU1 converter as a backlight source the following two properties must
+be provided:
+- su1-dev : framebuffer phandle
+- su1-max-uA : maximum current
+
+To use the SU2 converter as a backlight source the following two properties must
+be provided:
+- su2-dev : framebuffer phandle
+- su1-max-uA : maximum current
+
+Additionally one of these properties must be provided to select the type of
+feedback used:
+- su2-feedback-voltage : voltage feedback is used
+- su2-feedback-curr1 : CURR1 input used for current feedback
+- su2-feedback-curr2 : CURR2 input used for current feedback
+- su2-feedback-curr3 : CURR3 input used for current feedback
+- su2-feedback-curr-auto: automatic current feedback selection
+
+and one of these to select the over-voltage protection pin
+- su2-fbprot-lx-sd4 : LX_SD4 is used for over-voltage protection
+- su2-fbprot-gpio2 : GPIO2 is used for over-voltage protection
+- su2-fbprot-gpio3 : GPIO3 is used for over-voltage protection
+- su2-fbprot-gpio4 : GPIO4 is used for over-voltage protection
+
+If "su2-feedback-curr-auto" is selected, one or more of the following properties
+have to be specified:
+- su2-auto-curr1 : use CURR1 input for current feedback
+- su2-auto-curr2 : use CURR2 input for current feedback
+- su2-auto-curr3 : use CURR3 input for current feedback
+
+Example:
+
+as3711@40 {
+ compatible = "ams,as3711";
+ reg = <0x40>;
+
+ regulators {
+ sd4 {
+ regulator-name = "1.215V";
+ regulator-min-microvolt = <1215000>;
+ regulator-max-microvolt = <1235000>;
+ };
+ ldo2 {
+ regulator-name = "2.8V CPU";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+
+ backlight {
+ compatible = "ams,as3711-bl";
+ su2-dev = <&lcdc>;
+ su2-max-uA = <36000>;
+ su2-feedback-curr-auto;
+ su2-fbprot-gpio4;
+ su2-auto-curr1;
+ su2-auto-curr2;
+ su2-auto-curr3;
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt
new file mode 100644
index 000000000000..e0e59c58a1f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -0,0 +1,56 @@
+ChromeOS Embedded Controller
+
+Google's ChromeOS EC is a Cortex-M device which talks to the AP and
+implements various function such as keyboard and battery charging.
+
+The EC can be connect through various means (I2C, SPI, LPC) and the
+compatible string used depends on the inteface. Each connection method has
+its own driver which connects to the top level interface-agnostic EC driver.
+Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
+the top-level driver.
+
+Required properties (I2C):
+- compatible: "google,cros-ec-i2c"
+- reg: I2C slave address
+
+Required properties (SPI):
+- compatible: "google,cros-ec-spi"
+- reg: SPI chip select
+
+Required properties (LPC):
+- compatible: "google,cros-ec-lpc"
+- reg: List of (IO address, size) pairs defining the interface uses
+
+
+Example for I2C:
+
+i2c@12CA0000 {
+ cros-ec@1e {
+ reg = <0x1e>;
+ compatible = "google,cros-ec-i2c";
+ interrupts = <14 0>;
+ interrupt-parent = <&wakeup_eint>;
+ wakeup-source;
+ };
+
+
+Example for SPI:
+
+spi@131b0000 {
+ ec@0 {
+ compatible = "google,cros-ec-spi";
+ reg = <0x0>;
+ interrupts = <14 0>;
+ interrupt-parent = <&wakeup_eint>;
+ wakeup-source;
+ spi-max-frequency = <5000000>;
+ controller-data {
+ cs-gpio = <&gpf0 3 4 3 0>;
+ samsung,spi-cs;
+ samsung,spi-feedback-delay = <2>;
+ };
+ };
+};
+
+
+Example for LPC is not supplied as it is not yet implemented.
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 000000000000..b381fa696bf9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,80 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be "ti,usbhs-host"
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain "usb_host_hs"
+
+Optional properties:
+
+- num-ports: number of USB ports. Usually this is automatically detected
+ from the IP's revision register but can be overridden by specifying
+ this property. A maximum of 3 ports are supported at the moment.
+
+- portN-mode: String specifying the port mode for port N, where N can be
+ from 1 to 3. If the port mode is not specified, that port is treated
+ as unused. When specified, it must be one of the following.
+ "ehci-phy",
+ "ehci-tll",
+ "ehci-hsic",
+ "ohci-phy-6pin-datse0",
+ "ohci-phy-6pin-dpdm",
+ "ohci-phy-3pin-datse0",
+ "ohci-phy-4pin-dpdm",
+ "ohci-tll-6pin-datse0",
+ "ohci-tll-6pin-dpdm",
+ "ohci-tll-3pin-datse0",
+ "ohci-tll-4pin-dpdm",
+ "ohci-tll-2pin-datse0",
+ "ohci-tll-2pin-dpdm",
+
+- single-ulpi-bypass: Must be present if the controller contains a single
+ ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+usbhshost: usbhshost@4a064000 {
+ compatible = "ti,usbhs-host";
+ reg = <0x4a064000 0x800>;
+ ti,hwmods = "usb_host_hs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = "ti,ohci-omap3", "usb-ohci";
+ reg = <0x4a064800 0x400>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 76 0x4>;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible = "ti,ehci-omap", "usb-ehci";
+ reg = <0x4a064c00 0x400>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 77 0x4>;
+ };
+};
+
+&usbhshost {
+ port1-mode = "ehci-phy";
+ port2-mode = "ehci-tll";
+ port3-mode = "ehci-phy";
+};
+
+&usbhsehci {
+ phys = <&hsusb1_phy 0 &hsusb3_phy>;
+};
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
new file mode 100644
index 000000000000..62fe69724e3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -0,0 +1,17 @@
+OMAP HS USB Host TLL (Transceiver-Less Interface)
+
+Required properties:
+
+- compatible : should be "ti,usbhs-tll"
+- reg : should contain one register range i.e. start and length
+- interrupts : should contain the TLL module's interrupt
+- ti,hwmod : must contain "usb_tll_hs"
+
+Example:
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = "ti,usbhs-tll";
+ reg = <0x4a062000 0x1000>;
+ interrupts = <78>;
+ ti,hwmods = "usb_tll_hs";
+ };
diff --git a/Documentation/devicetree/bindings/misc/smc.txt b/Documentation/devicetree/bindings/misc/smc.txt
new file mode 100644
index 000000000000..02b428136177
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/smc.txt
@@ -0,0 +1,14 @@
+Broadcom Secure Monitor Bounce buffer
+-----------------------------------------------------
+This binding defines the location of the bounce buffer
+used for non-secure to secure communications.
+
+Required properties:
+- compatible : "bcm,kona-smc"
+- reg : Location and size of bounce buffer
+
+Example:
+ smc@0x3404c000 {
+ compatible = "bcm,bcm11351-smc", "bcm,kona-smc";
+ reg = <0x3404c000 0x400>; //1 KiB in SRAM
+ };
diff --git a/Documentation/devicetree/bindings/mmc/davinci_mmc.txt b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
new file mode 100644
index 000000000000..e5a0140b2381
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/davinci_mmc.txt
@@ -0,0 +1,33 @@
+* TI Highspeed MMC host controller for DaVinci
+
+The Highspeed MMC Host Controller on TI DaVinci family
+provides an interface for MMC, SD and SDIO types of memory cards.
+
+This file documents the properties used by the davinci_mmc driver.
+
+Required properties:
+- compatible:
+ Should be "ti,da830-mmc": for da830, da850, dm365
+ Should be "ti,dm355-mmc": for dm355, dm644x
+
+Optional properties:
+- bus-width: Number of data lines, can be <1>, <4>, or <8>, default <1>
+- max-frequency: Maximum operating clock frequency, default 25MHz.
+- dmas: List of DMA specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required.
+- dma-names: RX and TX DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed in dmas.
+
+Example:
+mmc0: mmc@1c40000 {
+ compatible = "ti,da830-mmc",
+ reg = <0x40000 0x1000>;
+ interrupts = <16>;
+ status = "okay";
+ bus-width = <4>;
+ max-frequency = <50000000>;
+ dmas = <&edma 16
+ &edma 17>;
+ dma-names = "rx", "tx";
+};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
new file mode 100644
index 000000000000..db442355cd24
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt
@@ -0,0 +1,24 @@
+* Freescale Secure Digital Host Controller for i.MX2/3 series
+
+This file documents differences to the properties defined in mmc.txt.
+
+Required properties:
+- compatible : Should be "fsl,<chip>-mmc", chip can be imx21 or imx31
+
+Optional properties:
+- dmas: One DMA phandle with arguments as defined by the devicetree bindings
+ of the used DMA controller.
+- dma-names: Has to be "rx-tx".
+
+Example:
+
+sdhci1: sdhci@10014000 {
+ compatible = "fsl,imx27-mmc", "fsl,imx21-mmc";
+ reg = <0x10014000 0x1000>;
+ interrupts = <11>;
+ dmas = <&dma 7>;
+ dma-names = "rx-tx";
+ bus-width = <4>;
+ cd-gpios = <&gpio3 29>;
+ status = "okay";
+};
diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
index 3b3a1ee055ff..328e990d2546 100644
--- a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -5,13 +5,6 @@ MMC, SD and eMMC storage mediums. This file documents differences between the
core mmc properties described by mmc.txt and the properties used by the
Samsung implmentation of the SDHCI controller.
-Note: The mmc core bindings documentation states that if none of the core
-card-detect bindings are used, then the standard sdhci card detect mechanism
-is used. The Samsung's SDHCI controller bindings extends this as listed below.
-
-[A] The property "samsung,cd-pinmux-gpio" can be used as stated in the
- "Optional Board Specific Properties" section below.
-
Required SoC Specific Properties:
- compatible: should be one of the following
- "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
@@ -20,18 +13,8 @@ Required SoC Specific Properties:
controller.
Required Board Specific Properties:
-- Samsung GPIO variant (will be completely replaced by pinctrl):
- - gpios: Should specify the gpios used for clock, command and data lines. The
- gpio specifier format depends on the gpio controller.
-- Pinctrl variant (preferred if available):
- - pinctrl-0: Should specify pin control groups used for this controller.
- - pinctrl-names: Should contain only one value - "default".
-
-Optional Board Specific Properties:
-- samsung,cd-pinmux-gpio: Specifies the card detect line that is routed
- through a pinmux to the card-detect pin of the card slot. This property
- should be used only if none of the mmc core card-detect properties are
- used. Only for Samsung GPIO variant.
+- pinctrl-0: Should specify pin control groups used for this controller.
+- pinctrl-names: Should contain only one value - "default".
Example:
sdhci@12530000 {
@@ -39,19 +22,9 @@ Example:
reg = <0x12530000 0x100>;
interrupts = <0 75 0>;
bus-width = <4>;
- cd-gpios = <&gpk2 2 2 3 3>;
-
- /* Samsung GPIO variant */
- gpios = <&gpk2 0 2 0 3>, /* clock line */
- <&gpk2 1 2 0 3>, /* command line */
- <&gpk2 3 2 3 3>, /* data line 0 */
- <&gpk2 4 2 3 3>, /* data line 1 */
- <&gpk2 5 2 3 3>, /* data line 2 */
- <&gpk2 6 2 3 3>; /* data line 3 */
-
- /* Pinctrl variant */
- pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>;
+ cd-gpios = <&gpk2 2 0>;
pinctrl-names = "default";
+ pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>;
};
Note: This example shows both SoC specific and board specific properties
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-sirf.txt b/Documentation/devicetree/bindings/mmc/sdhci-sirf.txt
new file mode 100644
index 000000000000..dd6ed464bcb8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-sirf.txt
@@ -0,0 +1,18 @@
+* SiRFprimII/marco/atlas6 SDHCI Controller
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-sirf driver.
+
+Required properties:
+- compatible: sirf,prima2-sdhc
+
+Optional properties:
+- cd-gpios: card detect gpio, with zero flags.
+
+Example:
+
+ sd0: sdhci@56000000 {
+ compatible = "sirf,prima2-sdhc";
+ reg = <0xcd000000 0x100000>;
+ cd-gpios = <&gpio 6 0>;
+ };
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
new file mode 100644
index 000000000000..420b3ab18890
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
@@ -0,0 +1,98 @@
+Device tree bindings for NOR flash connect to TI GPMC
+
+NOR flash connected to the TI GPMC (found on OMAP boards) are represented as
+child nodes of the GPMC controller with a name of "nor".
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width: Width of NOR flash in bytes. GPMC supports 8-bit and
+ 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+- gpmc,cs-on-ns: Chip-select assertion time
+- gpmc,cs-rd-off-ns: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off-ns: Chip-select de-assertion time for writes
+- gpmc,oe-on-ns: Output-enable assertion time
+- gpmc,oe-off-ns: Output-enable de-assertion time
+- gpmc,we-on-ns Write-enable assertion time
+- gpmc,we-off-ns: Write-enable de-assertion time
+- gpmc,access-ns: Start cycle to first data capture (read access)
+- gpmc,rd-cycle-ns: Total read cycle time
+- gpmc,wr-cycle-ns: Total write cycle time
+- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+- reg: Chip-select, base address (relative to chip-select)
+ and size of NOR flash. Note that base address will be
+ typically 0 as this is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e000000 {
+ compatible = "ti,omap3430-gpmc", "simple-bus";
+ ti,hwmods = "gpmc";
+ reg = <0x6e000000 0x1000>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ ranges = <0 0 0x10000000 0x08000000>;
+
+ nor@0,0 {
+ compatible = "cfi-flash";
+ linux,mtd-name= "intel,pf48f6000m0y1be";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0 0 0x08000000>;
+ bank-width = <2>;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <186>;
+ gpmc,cs-wr-off-ns = <186>;
+ gpmc,adv-on-ns = <12>;
+ gpmc,adv-rd-off-ns = <48>;
+ gpmc,adv-wr-off-ns = <48>;
+ gpmc,oe-on-ns = <54>;
+ gpmc,oe-off-ns = <168>;
+ gpmc,we-on-ns = <54>;
+ gpmc,we-off-ns = <168>;
+ gpmc,rd-cycle-ns = <186>;
+ gpmc,wr-cycle-ns = <186>;
+ gpmc,access-ns = <114>;
+ gpmc,page-burst-access-ns = <6>;
+ gpmc,bus-turnaround-ns = <12>;
+ gpmc,cycle2cycle-delay-ns = <18>;
+ gpmc,wr-data-mux-bus-ns = <90>;
+ gpmc,wr-access-ns = <186>;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ partition@0 {
+ label = "bootloader-nor";
+ reg = <0 0x40000>;
+ };
+ partition@0x40000 {
+ label = "params-nor";
+ reg = <0x40000 0x40000>;
+ };
+ partition@0x80000 {
+ label = "kernel-nor";
+ reg = <0x80000 0x200000>;
+ };
+ partition@0x280000 {
+ label = "filesystem-nor";
+ reg = <0x240000 0x7d80000>;
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
index deec9da224a2..b7529424ac88 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -10,6 +10,8 @@ Documentation/devicetree/bindings/bus/ti-gpmc.txt
Required properties:
- reg: The CS line the peripheral is connected to
+ - gpmc,device-width Width of the ONENAND device connected to the GPMC
+ in bytes. Must be 1 or 2.
Optional properties:
@@ -34,6 +36,7 @@ Example for an OMAP3430 board:
onenand@0 {
reg = <0 0 0>; /* CS0, offset 0 */
+ gpmc,device-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000000000000..24cb4e46f675
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,97 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an "ethernet" name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For the properties relevant to the ethernet controller connected to the GPMC
+refer to the binding documentation of the device. For example, the documentation
+for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt
+
+Child nodes need to specify the GPMC bus address width using the "bank-width"
+property but is possible that an ethernet controller also has a property to
+specify the I/O registers address width. Even when the GPMC has a maximum 16-bit
+address width, it supports devices with 32-bit word registers.
+For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an
+OMAP2+ board, "bank-width = <2>;" and "reg-io-width = <4>;".
+
+Required properties:
+- bank-width: Address width of the device in bytes. GPMC supports 8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Compatible string property for the ethernet child device.
+- gpmc,cs-on: Chip-select assertion time
+- gpmc,cs-rd-off: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off: Chip-select de-assertion time for writes
+- gpmc,oe-on: Output-enable assertion time
+- gpmc,oe-off Output-enable de-assertion time
+- gpmc,we-on: Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- reg: Chip-select, base address (relative to chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Example:
+
+gpmc: gpmc@6e000000 {
+ compatible = "ti,omap3430-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x6e000000 0x1000>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ ranges = <5 0 0x2c000000 0x1000000>;
+
+ ethernet@5,0 {
+ compatible = "smsc,lan9221", "smsc,lan9115";
+ reg = <5 0 0xff>;
+ bank-width = <2>;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = <0>;
+ gpmc,cs-rd-off = <186>;
+ gpmc,cs-wr-off = <186>;
+ gpmc,adv-on = <12>;
+ gpmc,adv-rd-off = <48>;
+ gpmc,adv-wr-off = <48>;
+ gpmc,oe-on = <54>;
+ gpmc,oe-off = <168>;
+ gpmc,we-on = <54>;
+ gpmc,we-off = <168>;
+ gpmc,rd-cycle = <186>;
+ gpmc,wr-cycle = <186>;
+ gpmc,access = <114>;
+ gpmc,page-burst-access = <6>;
+ gpmc,bus-turnaround = <12>;
+ gpmc,cycle2cycle-delay = <18>;
+ gpmc,wr-data-mux-bus = <90>;
+ gpmc,wr-access = <186>;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = <&gpio6>;
+ interrupts = <16>;
+ vmmc-supply = <&vddvario>;
+ vmmc_aux-supply = <&vdd33a>;
+ reg-io-width = <4>;
+
+ smsc,save-mac-address;
+ };
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
index ab19e6bc7d3b..bcfdab5d442e 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
@@ -24,9 +24,9 @@ Required properties for iomux controller:
Required properties for pin configuration node:
- fsl,pins: two integers array, represents a group of pins mux and config
setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
- pin working on a specific function, CONFIG is the pad setting value like
- pull-up on this pin. Please refer to fsl,<soc>-pinctrl.txt for the valid
- pins and functions of each SoC.
+ pin working on a specific function, which consists of a tuple of
+ <mux_reg conf_reg input_reg mux_val input_val>. CONFIG is the pad setting
+ value like pull-up on this pin.
Bits used for CONFIG:
NO_PAD_CTL(1 << 31): indicate this pin does not need config.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
index 1183f1a3be33..c083dfd25db9 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.txt
@@ -29,956 +29,5 @@ PAD_CTL_DSE_MAX (2 << 1)
PAD_CTL_SRE_FAST (1 << 0)
PAD_CTL_SRE_SLOW (0 << 0)
-See below for available PIN_FUNC_ID for imx35:
-0 MX35_PAD_CAPTURE__GPT_CAPIN1
-1 MX35_PAD_CAPTURE__GPT_CMPOUT2
-2 MX35_PAD_CAPTURE__CSPI2_SS1
-3 MX35_PAD_CAPTURE__EPIT1_EPITO
-4 MX35_PAD_CAPTURE__CCM_CLK32K
-5 MX35_PAD_CAPTURE__GPIO1_4
-6 MX35_PAD_COMPARE__GPT_CMPOUT1
-7 MX35_PAD_COMPARE__GPT_CAPIN2
-8 MX35_PAD_COMPARE__GPT_CMPOUT3
-9 MX35_PAD_COMPARE__EPIT2_EPITO
-10 MX35_PAD_COMPARE__GPIO1_5
-11 MX35_PAD_COMPARE__SDMA_EXTDMA_2
-12 MX35_PAD_WDOG_RST__WDOG_WDOG_B
-13 MX35_PAD_WDOG_RST__IPU_FLASH_STROBE
-14 MX35_PAD_WDOG_RST__GPIO1_6
-15 MX35_PAD_GPIO1_0__GPIO1_0
-16 MX35_PAD_GPIO1_0__CCM_PMIC_RDY
-17 MX35_PAD_GPIO1_0__OWIRE_LINE
-18 MX35_PAD_GPIO1_0__SDMA_EXTDMA_0
-19 MX35_PAD_GPIO1_1__GPIO1_1
-20 MX35_PAD_GPIO1_1__PWM_PWMO
-21 MX35_PAD_GPIO1_1__CSPI1_SS2
-22 MX35_PAD_GPIO1_1__SCC_TAMPER_DETECT
-23 MX35_PAD_GPIO1_1__SDMA_EXTDMA_1
-24 MX35_PAD_GPIO2_0__GPIO2_0
-25 MX35_PAD_GPIO2_0__USB_TOP_USBOTG_CLK
-26 MX35_PAD_GPIO3_0__GPIO3_0
-27 MX35_PAD_GPIO3_0__USB_TOP_USBH2_CLK
-28 MX35_PAD_RESET_IN_B__CCM_RESET_IN_B
-29 MX35_PAD_POR_B__CCM_POR_B
-30 MX35_PAD_CLKO__CCM_CLKO
-31 MX35_PAD_CLKO__GPIO1_8
-32 MX35_PAD_BOOT_MODE0__CCM_BOOT_MODE_0
-33 MX35_PAD_BOOT_MODE1__CCM_BOOT_MODE_1
-34 MX35_PAD_CLK_MODE0__CCM_CLK_MODE_0
-35 MX35_PAD_CLK_MODE1__CCM_CLK_MODE_1
-36 MX35_PAD_POWER_FAIL__CCM_DSM_WAKEUP_INT_26
-37 MX35_PAD_VSTBY__CCM_VSTBY
-38 MX35_PAD_VSTBY__GPIO1_7
-39 MX35_PAD_A0__EMI_EIM_DA_L_0
-40 MX35_PAD_A1__EMI_EIM_DA_L_1
-41 MX35_PAD_A2__EMI_EIM_DA_L_2
-42 MX35_PAD_A3__EMI_EIM_DA_L_3
-43 MX35_PAD_A4__EMI_EIM_DA_L_4
-44 MX35_PAD_A5__EMI_EIM_DA_L_5
-45 MX35_PAD_A6__EMI_EIM_DA_L_6
-46 MX35_PAD_A7__EMI_EIM_DA_L_7
-47 MX35_PAD_A8__EMI_EIM_DA_H_8
-48 MX35_PAD_A9__EMI_EIM_DA_H_9
-49 MX35_PAD_A10__EMI_EIM_DA_H_10
-50 MX35_PAD_MA10__EMI_MA10
-51 MX35_PAD_A11__EMI_EIM_DA_H_11
-52 MX35_PAD_A12__EMI_EIM_DA_H_12
-53 MX35_PAD_A13__EMI_EIM_DA_H_13
-54 MX35_PAD_A14__EMI_EIM_DA_H2_14
-55 MX35_PAD_A15__EMI_EIM_DA_H2_15
-56 MX35_PAD_A16__EMI_EIM_A_16
-57 MX35_PAD_A17__EMI_EIM_A_17
-58 MX35_PAD_A18__EMI_EIM_A_18
-59 MX35_PAD_A19__EMI_EIM_A_19
-60 MX35_PAD_A20__EMI_EIM_A_20
-61 MX35_PAD_A21__EMI_EIM_A_21
-62 MX35_PAD_A22__EMI_EIM_A_22
-63 MX35_PAD_A23__EMI_EIM_A_23
-64 MX35_PAD_A24__EMI_EIM_A_24
-65 MX35_PAD_A25__EMI_EIM_A_25
-66 MX35_PAD_SDBA1__EMI_EIM_SDBA1
-67 MX35_PAD_SDBA0__EMI_EIM_SDBA0
-68 MX35_PAD_SD0__EMI_DRAM_D_0
-69 MX35_PAD_SD1__EMI_DRAM_D_1
-70 MX35_PAD_SD2__EMI_DRAM_D_2
-71 MX35_PAD_SD3__EMI_DRAM_D_3
-72 MX35_PAD_SD4__EMI_DRAM_D_4
-73 MX35_PAD_SD5__EMI_DRAM_D_5
-74 MX35_PAD_SD6__EMI_DRAM_D_6
-75 MX35_PAD_SD7__EMI_DRAM_D_7
-76 MX35_PAD_SD8__EMI_DRAM_D_8
-77 MX35_PAD_SD9__EMI_DRAM_D_9
-78 MX35_PAD_SD10__EMI_DRAM_D_10
-79 MX35_PAD_SD11__EMI_DRAM_D_11
-80 MX35_PAD_SD12__EMI_DRAM_D_12
-81 MX35_PAD_SD13__EMI_DRAM_D_13
-82 MX35_PAD_SD14__EMI_DRAM_D_14
-83 MX35_PAD_SD15__EMI_DRAM_D_15
-84 MX35_PAD_SD16__EMI_DRAM_D_16
-85 MX35_PAD_SD17__EMI_DRAM_D_17
-86 MX35_PAD_SD18__EMI_DRAM_D_18
-87 MX35_PAD_SD19__EMI_DRAM_D_19
-88 MX35_PAD_SD20__EMI_DRAM_D_20
-89 MX35_PAD_SD21__EMI_DRAM_D_21
-90 MX35_PAD_SD22__EMI_DRAM_D_22
-91 MX35_PAD_SD23__EMI_DRAM_D_23
-92 MX35_PAD_SD24__EMI_DRAM_D_24
-93 MX35_PAD_SD25__EMI_DRAM_D_25
-94 MX35_PAD_SD26__EMI_DRAM_D_26
-95 MX35_PAD_SD27__EMI_DRAM_D_27
-96 MX35_PAD_SD28__EMI_DRAM_D_28
-97 MX35_PAD_SD29__EMI_DRAM_D_29
-98 MX35_PAD_SD30__EMI_DRAM_D_30
-99 MX35_PAD_SD31__EMI_DRAM_D_31
-100 MX35_PAD_DQM0__EMI_DRAM_DQM_0
-101 MX35_PAD_DQM1__EMI_DRAM_DQM_1
-102 MX35_PAD_DQM2__EMI_DRAM_DQM_2
-103 MX35_PAD_DQM3__EMI_DRAM_DQM_3
-104 MX35_PAD_EB0__EMI_EIM_EB0_B
-105 MX35_PAD_EB1__EMI_EIM_EB1_B
-106 MX35_PAD_OE__EMI_EIM_OE
-107 MX35_PAD_CS0__EMI_EIM_CS0
-108 MX35_PAD_CS1__EMI_EIM_CS1
-109 MX35_PAD_CS1__EMI_NANDF_CE3
-110 MX35_PAD_CS2__EMI_EIM_CS2
-111 MX35_PAD_CS3__EMI_EIM_CS3
-112 MX35_PAD_CS4__EMI_EIM_CS4
-113 MX35_PAD_CS4__EMI_DTACK_B
-114 MX35_PAD_CS4__EMI_NANDF_CE1
-115 MX35_PAD_CS4__GPIO1_20
-116 MX35_PAD_CS5__EMI_EIM_CS5
-117 MX35_PAD_CS5__CSPI2_SS2
-118 MX35_PAD_CS5__CSPI1_SS2
-119 MX35_PAD_CS5__EMI_NANDF_CE2
-120 MX35_PAD_CS5__GPIO1_21
-121 MX35_PAD_NF_CE0__EMI_NANDF_CE0
-122 MX35_PAD_NF_CE0__GPIO1_22
-123 MX35_PAD_ECB__EMI_EIM_ECB
-124 MX35_PAD_LBA__EMI_EIM_LBA
-125 MX35_PAD_BCLK__EMI_EIM_BCLK
-126 MX35_PAD_RW__EMI_EIM_RW
-127 MX35_PAD_RAS__EMI_DRAM_RAS
-128 MX35_PAD_CAS__EMI_DRAM_CAS
-129 MX35_PAD_SDWE__EMI_DRAM_SDWE
-130 MX35_PAD_SDCKE0__EMI_DRAM_SDCKE_0
-131 MX35_PAD_SDCKE1__EMI_DRAM_SDCKE_1
-132 MX35_PAD_SDCLK__EMI_DRAM_SDCLK
-133 MX35_PAD_SDQS0__EMI_DRAM_SDQS_0
-134 MX35_PAD_SDQS1__EMI_DRAM_SDQS_1
-135 MX35_PAD_SDQS2__EMI_DRAM_SDQS_2
-136 MX35_PAD_SDQS3__EMI_DRAM_SDQS_3
-137 MX35_PAD_NFWE_B__EMI_NANDF_WE_B
-138 MX35_PAD_NFWE_B__USB_TOP_USBH2_DATA_3
-139 MX35_PAD_NFWE_B__IPU_DISPB_D0_VSYNC
-140 MX35_PAD_NFWE_B__GPIO2_18
-141 MX35_PAD_NFWE_B__ARM11P_TOP_TRACE_0
-142 MX35_PAD_NFRE_B__EMI_NANDF_RE_B
-143 MX35_PAD_NFRE_B__USB_TOP_USBH2_DIR
-144 MX35_PAD_NFRE_B__IPU_DISPB_BCLK
-145 MX35_PAD_NFRE_B__GPIO2_19
-146 MX35_PAD_NFRE_B__ARM11P_TOP_TRACE_1
-147 MX35_PAD_NFALE__EMI_NANDF_ALE
-148 MX35_PAD_NFALE__USB_TOP_USBH2_STP
-149 MX35_PAD_NFALE__IPU_DISPB_CS0
-150 MX35_PAD_NFALE__GPIO2_20
-151 MX35_PAD_NFALE__ARM11P_TOP_TRACE_2
-152 MX35_PAD_NFCLE__EMI_NANDF_CLE
-153 MX35_PAD_NFCLE__USB_TOP_USBH2_NXT
-154 MX35_PAD_NFCLE__IPU_DISPB_PAR_RS
-155 MX35_PAD_NFCLE__GPIO2_21
-156 MX35_PAD_NFCLE__ARM11P_TOP_TRACE_3
-157 MX35_PAD_NFWP_B__EMI_NANDF_WP_B
-158 MX35_PAD_NFWP_B__USB_TOP_USBH2_DATA_7
-159 MX35_PAD_NFWP_B__IPU_DISPB_WR
-160 MX35_PAD_NFWP_B__GPIO2_22
-161 MX35_PAD_NFWP_B__ARM11P_TOP_TRCTL
-162 MX35_PAD_NFRB__EMI_NANDF_RB
-163 MX35_PAD_NFRB__IPU_DISPB_RD
-164 MX35_PAD_NFRB__GPIO2_23
-165 MX35_PAD_NFRB__ARM11P_TOP_TRCLK
-166 MX35_PAD_D15__EMI_EIM_D_15
-167 MX35_PAD_D14__EMI_EIM_D_14
-168 MX35_PAD_D13__EMI_EIM_D_13
-169 MX35_PAD_D12__EMI_EIM_D_12
-170 MX35_PAD_D11__EMI_EIM_D_11
-171 MX35_PAD_D10__EMI_EIM_D_10
-172 MX35_PAD_D9__EMI_EIM_D_9
-173 MX35_PAD_D8__EMI_EIM_D_8
-174 MX35_PAD_D7__EMI_EIM_D_7
-175 MX35_PAD_D6__EMI_EIM_D_6
-176 MX35_PAD_D5__EMI_EIM_D_5
-177 MX35_PAD_D4__EMI_EIM_D_4
-178 MX35_PAD_D3__EMI_EIM_D_3
-179 MX35_PAD_D2__EMI_EIM_D_2
-180 MX35_PAD_D1__EMI_EIM_D_1
-181 MX35_PAD_D0__EMI_EIM_D_0
-182 MX35_PAD_CSI_D8__IPU_CSI_D_8
-183 MX35_PAD_CSI_D8__KPP_COL_0
-184 MX35_PAD_CSI_D8__GPIO1_20
-185 MX35_PAD_CSI_D8__ARM11P_TOP_EVNTBUS_13
-186 MX35_PAD_CSI_D9__IPU_CSI_D_9
-187 MX35_PAD_CSI_D9__KPP_COL_1
-188 MX35_PAD_CSI_D9__GPIO1_21
-189 MX35_PAD_CSI_D9__ARM11P_TOP_EVNTBUS_14
-190 MX35_PAD_CSI_D10__IPU_CSI_D_10
-191 MX35_PAD_CSI_D10__KPP_COL_2
-192 MX35_PAD_CSI_D10__GPIO1_22
-193 MX35_PAD_CSI_D10__ARM11P_TOP_EVNTBUS_15
-194 MX35_PAD_CSI_D11__IPU_CSI_D_11
-195 MX35_PAD_CSI_D11__KPP_COL_3
-196 MX35_PAD_CSI_D11__GPIO1_23
-197 MX35_PAD_CSI_D12__IPU_CSI_D_12
-198 MX35_PAD_CSI_D12__KPP_ROW_0
-199 MX35_PAD_CSI_D12__GPIO1_24
-200 MX35_PAD_CSI_D13__IPU_CSI_D_13
-201 MX35_PAD_CSI_D13__KPP_ROW_1
-202 MX35_PAD_CSI_D13__GPIO1_25
-203 MX35_PAD_CSI_D14__IPU_CSI_D_14
-204 MX35_PAD_CSI_D14__KPP_ROW_2
-205 MX35_PAD_CSI_D14__GPIO1_26
-206 MX35_PAD_CSI_D15__IPU_CSI_D_15
-207 MX35_PAD_CSI_D15__KPP_ROW_3
-208 MX35_PAD_CSI_D15__GPIO1_27
-209 MX35_PAD_CSI_MCLK__IPU_CSI_MCLK
-210 MX35_PAD_CSI_MCLK__GPIO1_28
-211 MX35_PAD_CSI_VSYNC__IPU_CSI_VSYNC
-212 MX35_PAD_CSI_VSYNC__GPIO1_29
-213 MX35_PAD_CSI_HSYNC__IPU_CSI_HSYNC
-214 MX35_PAD_CSI_HSYNC__GPIO1_30
-215 MX35_PAD_CSI_PIXCLK__IPU_CSI_PIXCLK
-216 MX35_PAD_CSI_PIXCLK__GPIO1_31
-217 MX35_PAD_I2C1_CLK__I2C1_SCL
-218 MX35_PAD_I2C1_CLK__GPIO2_24
-219 MX35_PAD_I2C1_CLK__CCM_USB_BYP_CLK
-220 MX35_PAD_I2C1_DAT__I2C1_SDA
-221 MX35_PAD_I2C1_DAT__GPIO2_25
-222 MX35_PAD_I2C2_CLK__I2C2_SCL
-223 MX35_PAD_I2C2_CLK__CAN1_TXCAN
-224 MX35_PAD_I2C2_CLK__USB_TOP_USBH2_PWR
-225 MX35_PAD_I2C2_CLK__GPIO2_26
-226 MX35_PAD_I2C2_CLK__SDMA_DEBUG_BUS_DEVICE_2
-227 MX35_PAD_I2C2_DAT__I2C2_SDA
-228 MX35_PAD_I2C2_DAT__CAN1_RXCAN
-229 MX35_PAD_I2C2_DAT__USB_TOP_USBH2_OC
-230 MX35_PAD_I2C2_DAT__GPIO2_27
-231 MX35_PAD_I2C2_DAT__SDMA_DEBUG_BUS_DEVICE_3
-232 MX35_PAD_STXD4__AUDMUX_AUD4_TXD
-233 MX35_PAD_STXD4__GPIO2_28
-234 MX35_PAD_STXD4__ARM11P_TOP_ARM_COREASID0
-235 MX35_PAD_SRXD4__AUDMUX_AUD4_RXD
-236 MX35_PAD_SRXD4__GPIO2_29
-237 MX35_PAD_SRXD4__ARM11P_TOP_ARM_COREASID1
-238 MX35_PAD_SCK4__AUDMUX_AUD4_TXC
-239 MX35_PAD_SCK4__GPIO2_30
-240 MX35_PAD_SCK4__ARM11P_TOP_ARM_COREASID2
-241 MX35_PAD_STXFS4__AUDMUX_AUD4_TXFS
-242 MX35_PAD_STXFS4__GPIO2_31
-243 MX35_PAD_STXFS4__ARM11P_TOP_ARM_COREASID3
-244 MX35_PAD_STXD5__AUDMUX_AUD5_TXD
-245 MX35_PAD_STXD5__SPDIF_SPDIF_OUT1
-246 MX35_PAD_STXD5__CSPI2_MOSI
-247 MX35_PAD_STXD5__GPIO1_0
-248 MX35_PAD_STXD5__ARM11P_TOP_ARM_COREASID4
-249 MX35_PAD_SRXD5__AUDMUX_AUD5_RXD
-250 MX35_PAD_SRXD5__SPDIF_SPDIF_IN1
-251 MX35_PAD_SRXD5__CSPI2_MISO
-252 MX35_PAD_SRXD5__GPIO1_1
-253 MX35_PAD_SRXD5__ARM11P_TOP_ARM_COREASID5
-254 MX35_PAD_SCK5__AUDMUX_AUD5_TXC
-255 MX35_PAD_SCK5__SPDIF_SPDIF_EXTCLK
-256 MX35_PAD_SCK5__CSPI2_SCLK
-257 MX35_PAD_SCK5__GPIO1_2
-258 MX35_PAD_SCK5__ARM11P_TOP_ARM_COREASID6
-259 MX35_PAD_STXFS5__AUDMUX_AUD5_TXFS
-260 MX35_PAD_STXFS5__CSPI2_RDY
-261 MX35_PAD_STXFS5__GPIO1_3
-262 MX35_PAD_STXFS5__ARM11P_TOP_ARM_COREASID7
-263 MX35_PAD_SCKR__ESAI_SCKR
-264 MX35_PAD_SCKR__GPIO1_4
-265 MX35_PAD_SCKR__ARM11P_TOP_EVNTBUS_10
-266 MX35_PAD_FSR__ESAI_FSR
-267 MX35_PAD_FSR__GPIO1_5
-268 MX35_PAD_FSR__ARM11P_TOP_EVNTBUS_11
-269 MX35_PAD_HCKR__ESAI_HCKR
-270 MX35_PAD_HCKR__AUDMUX_AUD5_RXFS
-271 MX35_PAD_HCKR__CSPI2_SS0
-272 MX35_PAD_HCKR__IPU_FLASH_STROBE
-273 MX35_PAD_HCKR__GPIO1_6
-274 MX35_PAD_HCKR__ARM11P_TOP_EVNTBUS_12
-275 MX35_PAD_SCKT__ESAI_SCKT
-276 MX35_PAD_SCKT__GPIO1_7
-277 MX35_PAD_SCKT__IPU_CSI_D_0
-278 MX35_PAD_SCKT__KPP_ROW_2
-279 MX35_PAD_FST__ESAI_FST
-280 MX35_PAD_FST__GPIO1_8
-281 MX35_PAD_FST__IPU_CSI_D_1
-282 MX35_PAD_FST__KPP_ROW_3
-283 MX35_PAD_HCKT__ESAI_HCKT
-284 MX35_PAD_HCKT__AUDMUX_AUD5_RXC
-285 MX35_PAD_HCKT__GPIO1_9
-286 MX35_PAD_HCKT__IPU_CSI_D_2
-287 MX35_PAD_HCKT__KPP_COL_3
-288 MX35_PAD_TX5_RX0__ESAI_TX5_RX0
-289 MX35_PAD_TX5_RX0__AUDMUX_AUD4_RXC
-290 MX35_PAD_TX5_RX0__CSPI2_SS2
-291 MX35_PAD_TX5_RX0__CAN2_TXCAN
-292 MX35_PAD_TX5_RX0__UART2_DTR
-293 MX35_PAD_TX5_RX0__GPIO1_10
-294 MX35_PAD_TX5_RX0__EMI_M3IF_CHOSEN_MASTER_0
-295 MX35_PAD_TX4_RX1__ESAI_TX4_RX1
-296 MX35_PAD_TX4_RX1__AUDMUX_AUD4_RXFS
-297 MX35_PAD_TX4_RX1__CSPI2_SS3
-298 MX35_PAD_TX4_RX1__CAN2_RXCAN
-299 MX35_PAD_TX4_RX1__UART2_DSR
-300 MX35_PAD_TX4_RX1__GPIO1_11
-301 MX35_PAD_TX4_RX1__IPU_CSI_D_3
-302 MX35_PAD_TX4_RX1__KPP_ROW_0
-303 MX35_PAD_TX3_RX2__ESAI_TX3_RX2
-304 MX35_PAD_TX3_RX2__I2C3_SCL
-305 MX35_PAD_TX3_RX2__EMI_NANDF_CE1
-306 MX35_PAD_TX3_RX2__GPIO1_12
-307 MX35_PAD_TX3_RX2__IPU_CSI_D_4
-308 MX35_PAD_TX3_RX2__KPP_ROW_1
-309 MX35_PAD_TX2_RX3__ESAI_TX2_RX3
-310 MX35_PAD_TX2_RX3__I2C3_SDA
-311 MX35_PAD_TX2_RX3__EMI_NANDF_CE2
-312 MX35_PAD_TX2_RX3__GPIO1_13
-313 MX35_PAD_TX2_RX3__IPU_CSI_D_5
-314 MX35_PAD_TX2_RX3__KPP_COL_0
-315 MX35_PAD_TX1__ESAI_TX1
-316 MX35_PAD_TX1__CCM_PMIC_RDY
-317 MX35_PAD_TX1__CSPI1_SS2
-318 MX35_PAD_TX1__EMI_NANDF_CE3
-319 MX35_PAD_TX1__UART2_RI
-320 MX35_PAD_TX1__GPIO1_14
-321 MX35_PAD_TX1__IPU_CSI_D_6
-322 MX35_PAD_TX1__KPP_COL_1
-323 MX35_PAD_TX0__ESAI_TX0
-324 MX35_PAD_TX0__SPDIF_SPDIF_EXTCLK
-325 MX35_PAD_TX0__CSPI1_SS3
-326 MX35_PAD_TX0__EMI_DTACK_B
-327 MX35_PAD_TX0__UART2_DCD
-328 MX35_PAD_TX0__GPIO1_15
-329 MX35_PAD_TX0__IPU_CSI_D_7
-330 MX35_PAD_TX0__KPP_COL_2
-331 MX35_PAD_CSPI1_MOSI__CSPI1_MOSI
-332 MX35_PAD_CSPI1_MOSI__GPIO1_16
-333 MX35_PAD_CSPI1_MOSI__ECT_CTI_TRIG_OUT1_2
-334 MX35_PAD_CSPI1_MISO__CSPI1_MISO
-335 MX35_PAD_CSPI1_MISO__GPIO1_17
-336 MX35_PAD_CSPI1_MISO__ECT_CTI_TRIG_OUT1_3
-337 MX35_PAD_CSPI1_SS0__CSPI1_SS0
-338 MX35_PAD_CSPI1_SS0__OWIRE_LINE
-339 MX35_PAD_CSPI1_SS0__CSPI2_SS3
-340 MX35_PAD_CSPI1_SS0__GPIO1_18
-341 MX35_PAD_CSPI1_SS0__ECT_CTI_TRIG_OUT1_4
-342 MX35_PAD_CSPI1_SS1__CSPI1_SS1
-343 MX35_PAD_CSPI1_SS1__PWM_PWMO
-344 MX35_PAD_CSPI1_SS1__CCM_CLK32K
-345 MX35_PAD_CSPI1_SS1__GPIO1_19
-346 MX35_PAD_CSPI1_SS1__IPU_DIAGB_29
-347 MX35_PAD_CSPI1_SS1__ECT_CTI_TRIG_OUT1_5
-348 MX35_PAD_CSPI1_SCLK__CSPI1_SCLK
-349 MX35_PAD_CSPI1_SCLK__GPIO3_4
-350 MX35_PAD_CSPI1_SCLK__IPU_DIAGB_30
-351 MX35_PAD_CSPI1_SCLK__EMI_M3IF_CHOSEN_MASTER_1
-352 MX35_PAD_CSPI1_SPI_RDY__CSPI1_RDY
-353 MX35_PAD_CSPI1_SPI_RDY__GPIO3_5
-354 MX35_PAD_CSPI1_SPI_RDY__IPU_DIAGB_31
-355 MX35_PAD_CSPI1_SPI_RDY__EMI_M3IF_CHOSEN_MASTER_2
-356 MX35_PAD_RXD1__UART1_RXD_MUX
-357 MX35_PAD_RXD1__CSPI2_MOSI
-358 MX35_PAD_RXD1__KPP_COL_4
-359 MX35_PAD_RXD1__GPIO3_6
-360 MX35_PAD_RXD1__ARM11P_TOP_EVNTBUS_16
-361 MX35_PAD_TXD1__UART1_TXD_MUX
-362 MX35_PAD_TXD1__CSPI2_MISO
-363 MX35_PAD_TXD1__KPP_COL_5
-364 MX35_PAD_TXD1__GPIO3_7
-365 MX35_PAD_TXD1__ARM11P_TOP_EVNTBUS_17
-366 MX35_PAD_RTS1__UART1_RTS
-367 MX35_PAD_RTS1__CSPI2_SCLK
-368 MX35_PAD_RTS1__I2C3_SCL
-369 MX35_PAD_RTS1__IPU_CSI_D_0
-370 MX35_PAD_RTS1__KPP_COL_6
-371 MX35_PAD_RTS1__GPIO3_8
-372 MX35_PAD_RTS1__EMI_NANDF_CE1
-373 MX35_PAD_RTS1__ARM11P_TOP_EVNTBUS_18
-374 MX35_PAD_CTS1__UART1_CTS
-375 MX35_PAD_CTS1__CSPI2_RDY
-376 MX35_PAD_CTS1__I2C3_SDA
-377 MX35_PAD_CTS1__IPU_CSI_D_1
-378 MX35_PAD_CTS1__KPP_COL_7
-379 MX35_PAD_CTS1__GPIO3_9
-380 MX35_PAD_CTS1__EMI_NANDF_CE2
-381 MX35_PAD_CTS1__ARM11P_TOP_EVNTBUS_19
-382 MX35_PAD_RXD2__UART2_RXD_MUX
-383 MX35_PAD_RXD2__KPP_ROW_4
-384 MX35_PAD_RXD2__GPIO3_10
-385 MX35_PAD_TXD2__UART2_TXD_MUX
-386 MX35_PAD_TXD2__SPDIF_SPDIF_EXTCLK
-387 MX35_PAD_TXD2__KPP_ROW_5
-388 MX35_PAD_TXD2__GPIO3_11
-389 MX35_PAD_RTS2__UART2_RTS
-390 MX35_PAD_RTS2__SPDIF_SPDIF_IN1
-391 MX35_PAD_RTS2__CAN2_RXCAN
-392 MX35_PAD_RTS2__IPU_CSI_D_2
-393 MX35_PAD_RTS2__KPP_ROW_6
-394 MX35_PAD_RTS2__GPIO3_12
-395 MX35_PAD_RTS2__AUDMUX_AUD5_RXC
-396 MX35_PAD_RTS2__UART3_RXD_MUX
-397 MX35_PAD_CTS2__UART2_CTS
-398 MX35_PAD_CTS2__SPDIF_SPDIF_OUT1
-399 MX35_PAD_CTS2__CAN2_TXCAN
-400 MX35_PAD_CTS2__IPU_CSI_D_3
-401 MX35_PAD_CTS2__KPP_ROW_7
-402 MX35_PAD_CTS2__GPIO3_13
-403 MX35_PAD_CTS2__AUDMUX_AUD5_RXFS
-404 MX35_PAD_CTS2__UART3_TXD_MUX
-405 MX35_PAD_RTCK__ARM11P_TOP_RTCK
-406 MX35_PAD_TCK__SJC_TCK
-407 MX35_PAD_TMS__SJC_TMS
-408 MX35_PAD_TDI__SJC_TDI
-409 MX35_PAD_TDO__SJC_TDO
-410 MX35_PAD_TRSTB__SJC_TRSTB
-411 MX35_PAD_DE_B__SJC_DE_B
-412 MX35_PAD_SJC_MOD__SJC_MOD
-413 MX35_PAD_USBOTG_PWR__USB_TOP_USBOTG_PWR
-414 MX35_PAD_USBOTG_PWR__USB_TOP_USBH2_PWR
-415 MX35_PAD_USBOTG_PWR__GPIO3_14
-416 MX35_PAD_USBOTG_OC__USB_TOP_USBOTG_OC
-417 MX35_PAD_USBOTG_OC__USB_TOP_USBH2_OC
-418 MX35_PAD_USBOTG_OC__GPIO3_15
-419 MX35_PAD_LD0__IPU_DISPB_DAT_0
-420 MX35_PAD_LD0__GPIO2_0
-421 MX35_PAD_LD0__SDMA_SDMA_DEBUG_PC_0
-422 MX35_PAD_LD1__IPU_DISPB_DAT_1
-423 MX35_PAD_LD1__GPIO2_1
-424 MX35_PAD_LD1__SDMA_SDMA_DEBUG_PC_1
-425 MX35_PAD_LD2__IPU_DISPB_DAT_2
-426 MX35_PAD_LD2__GPIO2_2
-427 MX35_PAD_LD2__SDMA_SDMA_DEBUG_PC_2
-428 MX35_PAD_LD3__IPU_DISPB_DAT_3
-429 MX35_PAD_LD3__GPIO2_3
-430 MX35_PAD_LD3__SDMA_SDMA_DEBUG_PC_3
-431 MX35_PAD_LD4__IPU_DISPB_DAT_4
-432 MX35_PAD_LD4__GPIO2_4
-433 MX35_PAD_LD4__SDMA_SDMA_DEBUG_PC_4
-434 MX35_PAD_LD5__IPU_DISPB_DAT_5
-435 MX35_PAD_LD5__GPIO2_5
-436 MX35_PAD_LD5__SDMA_SDMA_DEBUG_PC_5
-437 MX35_PAD_LD6__IPU_DISPB_DAT_6
-438 MX35_PAD_LD6__GPIO2_6
-439 MX35_PAD_LD6__SDMA_SDMA_DEBUG_PC_6
-440 MX35_PAD_LD7__IPU_DISPB_DAT_7
-441 MX35_PAD_LD7__GPIO2_7
-442 MX35_PAD_LD7__SDMA_SDMA_DEBUG_PC_7
-443 MX35_PAD_LD8__IPU_DISPB_DAT_8
-444 MX35_PAD_LD8__GPIO2_8
-445 MX35_PAD_LD8__SDMA_SDMA_DEBUG_PC_8
-446 MX35_PAD_LD9__IPU_DISPB_DAT_9
-447 MX35_PAD_LD9__GPIO2_9
-448 MX35_PAD_LD9__SDMA_SDMA_DEBUG_PC_9
-449 MX35_PAD_LD10__IPU_DISPB_DAT_10
-450 MX35_PAD_LD10__GPIO2_10
-451 MX35_PAD_LD10__SDMA_SDMA_DEBUG_PC_10
-452 MX35_PAD_LD11__IPU_DISPB_DAT_11
-453 MX35_PAD_LD11__GPIO2_11
-454 MX35_PAD_LD11__SDMA_SDMA_DEBUG_PC_11
-455 MX35_PAD_LD11__ARM11P_TOP_TRACE_4
-456 MX35_PAD_LD12__IPU_DISPB_DAT_12
-457 MX35_PAD_LD12__GPIO2_12
-458 MX35_PAD_LD12__SDMA_SDMA_DEBUG_PC_12
-459 MX35_PAD_LD12__ARM11P_TOP_TRACE_5
-460 MX35_PAD_LD13__IPU_DISPB_DAT_13
-461 MX35_PAD_LD13__GPIO2_13
-462 MX35_PAD_LD13__SDMA_SDMA_DEBUG_PC_13
-463 MX35_PAD_LD13__ARM11P_TOP_TRACE_6
-464 MX35_PAD_LD14__IPU_DISPB_DAT_14
-465 MX35_PAD_LD14__GPIO2_14
-466 MX35_PAD_LD14__SDMA_SDMA_DEBUG_EVENT_CHANNEL_0
-467 MX35_PAD_LD14__ARM11P_TOP_TRACE_7
-468 MX35_PAD_LD15__IPU_DISPB_DAT_15
-469 MX35_PAD_LD15__GPIO2_15
-470 MX35_PAD_LD15__SDMA_SDMA_DEBUG_EVENT_CHANNEL_1
-471 MX35_PAD_LD15__ARM11P_TOP_TRACE_8
-472 MX35_PAD_LD16__IPU_DISPB_DAT_16
-473 MX35_PAD_LD16__IPU_DISPB_D12_VSYNC
-474 MX35_PAD_LD16__GPIO2_16
-475 MX35_PAD_LD16__SDMA_SDMA_DEBUG_EVENT_CHANNEL_2
-476 MX35_PAD_LD16__ARM11P_TOP_TRACE_9
-477 MX35_PAD_LD17__IPU_DISPB_DAT_17
-478 MX35_PAD_LD17__IPU_DISPB_CS2
-479 MX35_PAD_LD17__GPIO2_17
-480 MX35_PAD_LD17__SDMA_SDMA_DEBUG_EVENT_CHANNEL_3
-481 MX35_PAD_LD17__ARM11P_TOP_TRACE_10
-482 MX35_PAD_LD18__IPU_DISPB_DAT_18
-483 MX35_PAD_LD18__IPU_DISPB_D0_VSYNC
-484 MX35_PAD_LD18__IPU_DISPB_D12_VSYNC
-485 MX35_PAD_LD18__ESDHC3_CMD
-486 MX35_PAD_LD18__USB_TOP_USBOTG_DATA_3
-487 MX35_PAD_LD18__GPIO3_24
-488 MX35_PAD_LD18__SDMA_SDMA_DEBUG_EVENT_CHANNEL_4
-489 MX35_PAD_LD18__ARM11P_TOP_TRACE_11
-490 MX35_PAD_LD19__IPU_DISPB_DAT_19
-491 MX35_PAD_LD19__IPU_DISPB_BCLK
-492 MX35_PAD_LD19__IPU_DISPB_CS1
-493 MX35_PAD_LD19__ESDHC3_CLK
-494 MX35_PAD_LD19__USB_TOP_USBOTG_DIR
-495 MX35_PAD_LD19__GPIO3_25
-496 MX35_PAD_LD19__SDMA_SDMA_DEBUG_EVENT_CHANNEL_5
-497 MX35_PAD_LD19__ARM11P_TOP_TRACE_12
-498 MX35_PAD_LD20__IPU_DISPB_DAT_20
-499 MX35_PAD_LD20__IPU_DISPB_CS0
-500 MX35_PAD_LD20__IPU_DISPB_SD_CLK
-501 MX35_PAD_LD20__ESDHC3_DAT0
-502 MX35_PAD_LD20__GPIO3_26
-503 MX35_PAD_LD20__SDMA_SDMA_DEBUG_CORE_STATUS_3
-504 MX35_PAD_LD20__ARM11P_TOP_TRACE_13
-505 MX35_PAD_LD21__IPU_DISPB_DAT_21
-506 MX35_PAD_LD21__IPU_DISPB_PAR_RS
-507 MX35_PAD_LD21__IPU_DISPB_SER_RS
-508 MX35_PAD_LD21__ESDHC3_DAT1
-509 MX35_PAD_LD21__USB_TOP_USBOTG_STP
-510 MX35_PAD_LD21__GPIO3_27
-511 MX35_PAD_LD21__SDMA_DEBUG_EVENT_CHANNEL_SEL
-512 MX35_PAD_LD21__ARM11P_TOP_TRACE_14
-513 MX35_PAD_LD22__IPU_DISPB_DAT_22
-514 MX35_PAD_LD22__IPU_DISPB_WR
-515 MX35_PAD_LD22__IPU_DISPB_SD_D_I
-516 MX35_PAD_LD22__ESDHC3_DAT2
-517 MX35_PAD_LD22__USB_TOP_USBOTG_NXT
-518 MX35_PAD_LD22__GPIO3_28
-519 MX35_PAD_LD22__SDMA_DEBUG_BUS_ERROR
-520 MX35_PAD_LD22__ARM11P_TOP_TRCTL
-521 MX35_PAD_LD23__IPU_DISPB_DAT_23
-522 MX35_PAD_LD23__IPU_DISPB_RD
-523 MX35_PAD_LD23__IPU_DISPB_SD_D_IO
-524 MX35_PAD_LD23__ESDHC3_DAT3
-525 MX35_PAD_LD23__USB_TOP_USBOTG_DATA_7
-526 MX35_PAD_LD23__GPIO3_29
-527 MX35_PAD_LD23__SDMA_DEBUG_MATCHED_DMBUS
-528 MX35_PAD_LD23__ARM11P_TOP_TRCLK
-529 MX35_PAD_D3_HSYNC__IPU_DISPB_D3_HSYNC
-530 MX35_PAD_D3_HSYNC__IPU_DISPB_SD_D_IO
-531 MX35_PAD_D3_HSYNC__GPIO3_30
-532 MX35_PAD_D3_HSYNC__SDMA_DEBUG_RTBUFFER_WRITE
-533 MX35_PAD_D3_HSYNC__ARM11P_TOP_TRACE_15
-534 MX35_PAD_D3_FPSHIFT__IPU_DISPB_D3_CLK
-535 MX35_PAD_D3_FPSHIFT__IPU_DISPB_SD_CLK
-536 MX35_PAD_D3_FPSHIFT__GPIO3_31
-537 MX35_PAD_D3_FPSHIFT__SDMA_SDMA_DEBUG_CORE_STATUS_0
-538 MX35_PAD_D3_FPSHIFT__ARM11P_TOP_TRACE_16
-539 MX35_PAD_D3_DRDY__IPU_DISPB_D3_DRDY
-540 MX35_PAD_D3_DRDY__IPU_DISPB_SD_D_O
-541 MX35_PAD_D3_DRDY__GPIO1_0
-542 MX35_PAD_D3_DRDY__SDMA_SDMA_DEBUG_CORE_STATUS_1
-543 MX35_PAD_D3_DRDY__ARM11P_TOP_TRACE_17
-544 MX35_PAD_CONTRAST__IPU_DISPB_CONTR
-545 MX35_PAD_CONTRAST__GPIO1_1
-546 MX35_PAD_CONTRAST__SDMA_SDMA_DEBUG_CORE_STATUS_2
-547 MX35_PAD_CONTRAST__ARM11P_TOP_TRACE_18
-548 MX35_PAD_D3_VSYNC__IPU_DISPB_D3_VSYNC
-549 MX35_PAD_D3_VSYNC__IPU_DISPB_CS1
-550 MX35_PAD_D3_VSYNC__GPIO1_2
-551 MX35_PAD_D3_VSYNC__SDMA_DEBUG_YIELD
-552 MX35_PAD_D3_VSYNC__ARM11P_TOP_TRACE_19
-553 MX35_PAD_D3_REV__IPU_DISPB_D3_REV
-554 MX35_PAD_D3_REV__IPU_DISPB_SER_RS
-555 MX35_PAD_D3_REV__GPIO1_3
-556 MX35_PAD_D3_REV__SDMA_DEBUG_BUS_RWB
-557 MX35_PAD_D3_REV__ARM11P_TOP_TRACE_20
-558 MX35_PAD_D3_CLS__IPU_DISPB_D3_CLS
-559 MX35_PAD_D3_CLS__IPU_DISPB_CS2
-560 MX35_PAD_D3_CLS__GPIO1_4
-561 MX35_PAD_D3_CLS__SDMA_DEBUG_BUS_DEVICE_0
-562 MX35_PAD_D3_CLS__ARM11P_TOP_TRACE_21
-563 MX35_PAD_D3_SPL__IPU_DISPB_D3_SPL
-564 MX35_PAD_D3_SPL__IPU_DISPB_D12_VSYNC
-565 MX35_PAD_D3_SPL__GPIO1_5
-566 MX35_PAD_D3_SPL__SDMA_DEBUG_BUS_DEVICE_1
-567 MX35_PAD_D3_SPL__ARM11P_TOP_TRACE_22
-568 MX35_PAD_SD1_CMD__ESDHC1_CMD
-569 MX35_PAD_SD1_CMD__MSHC_SCLK
-570 MX35_PAD_SD1_CMD__IPU_DISPB_D0_VSYNC
-571 MX35_PAD_SD1_CMD__USB_TOP_USBOTG_DATA_4
-572 MX35_PAD_SD1_CMD__GPIO1_6
-573 MX35_PAD_SD1_CMD__ARM11P_TOP_TRCTL
-574 MX35_PAD_SD1_CLK__ESDHC1_CLK
-575 MX35_PAD_SD1_CLK__MSHC_BS
-576 MX35_PAD_SD1_CLK__IPU_DISPB_BCLK
-577 MX35_PAD_SD1_CLK__USB_TOP_USBOTG_DATA_5
-578 MX35_PAD_SD1_CLK__GPIO1_7
-579 MX35_PAD_SD1_CLK__ARM11P_TOP_TRCLK
-580 MX35_PAD_SD1_DATA0__ESDHC1_DAT0
-581 MX35_PAD_SD1_DATA0__MSHC_DATA_0
-582 MX35_PAD_SD1_DATA0__IPU_DISPB_CS0
-583 MX35_PAD_SD1_DATA0__USB_TOP_USBOTG_DATA_6
-584 MX35_PAD_SD1_DATA0__GPIO1_8
-585 MX35_PAD_SD1_DATA0__ARM11P_TOP_TRACE_23
-586 MX35_PAD_SD1_DATA1__ESDHC1_DAT1
-587 MX35_PAD_SD1_DATA1__MSHC_DATA_1
-588 MX35_PAD_SD1_DATA1__IPU_DISPB_PAR_RS
-589 MX35_PAD_SD1_DATA1__USB_TOP_USBOTG_DATA_0
-590 MX35_PAD_SD1_DATA1__GPIO1_9
-591 MX35_PAD_SD1_DATA1__ARM11P_TOP_TRACE_24
-592 MX35_PAD_SD1_DATA2__ESDHC1_DAT2
-593 MX35_PAD_SD1_DATA2__MSHC_DATA_2
-594 MX35_PAD_SD1_DATA2__IPU_DISPB_WR
-595 MX35_PAD_SD1_DATA2__USB_TOP_USBOTG_DATA_1
-596 MX35_PAD_SD1_DATA2__GPIO1_10
-597 MX35_PAD_SD1_DATA2__ARM11P_TOP_TRACE_25
-598 MX35_PAD_SD1_DATA3__ESDHC1_DAT3
-599 MX35_PAD_SD1_DATA3__MSHC_DATA_3
-600 MX35_PAD_SD1_DATA3__IPU_DISPB_RD
-601 MX35_PAD_SD1_DATA3__USB_TOP_USBOTG_DATA_2
-602 MX35_PAD_SD1_DATA3__GPIO1_11
-603 MX35_PAD_SD1_DATA3__ARM11P_TOP_TRACE_26
-604 MX35_PAD_SD2_CMD__ESDHC2_CMD
-605 MX35_PAD_SD2_CMD__I2C3_SCL
-606 MX35_PAD_SD2_CMD__ESDHC1_DAT4
-607 MX35_PAD_SD2_CMD__IPU_CSI_D_2
-608 MX35_PAD_SD2_CMD__USB_TOP_USBH2_DATA_4
-609 MX35_PAD_SD2_CMD__GPIO2_0
-610 MX35_PAD_SD2_CMD__SPDIF_SPDIF_OUT1
-611 MX35_PAD_SD2_CMD__IPU_DISPB_D12_VSYNC
-612 MX35_PAD_SD2_CLK__ESDHC2_CLK
-613 MX35_PAD_SD2_CLK__I2C3_SDA
-614 MX35_PAD_SD2_CLK__ESDHC1_DAT5
-615 MX35_PAD_SD2_CLK__IPU_CSI_D_3
-616 MX35_PAD_SD2_CLK__USB_TOP_USBH2_DATA_5
-617 MX35_PAD_SD2_CLK__GPIO2_1
-618 MX35_PAD_SD2_CLK__SPDIF_SPDIF_IN1
-619 MX35_PAD_SD2_CLK__IPU_DISPB_CS2
-620 MX35_PAD_SD2_DATA0__ESDHC2_DAT0
-621 MX35_PAD_SD2_DATA0__UART3_RXD_MUX
-622 MX35_PAD_SD2_DATA0__ESDHC1_DAT6
-623 MX35_PAD_SD2_DATA0__IPU_CSI_D_4
-624 MX35_PAD_SD2_DATA0__USB_TOP_USBH2_DATA_6
-625 MX35_PAD_SD2_DATA0__GPIO2_2
-626 MX35_PAD_SD2_DATA0__SPDIF_SPDIF_EXTCLK
-627 MX35_PAD_SD2_DATA1__ESDHC2_DAT1
-628 MX35_PAD_SD2_DATA1__UART3_TXD_MUX
-629 MX35_PAD_SD2_DATA1__ESDHC1_DAT7
-630 MX35_PAD_SD2_DATA1__IPU_CSI_D_5
-631 MX35_PAD_SD2_DATA1__USB_TOP_USBH2_DATA_0
-632 MX35_PAD_SD2_DATA1__GPIO2_3
-633 MX35_PAD_SD2_DATA2__ESDHC2_DAT2
-634 MX35_PAD_SD2_DATA2__UART3_RTS
-635 MX35_PAD_SD2_DATA2__CAN1_RXCAN
-636 MX35_PAD_SD2_DATA2__IPU_CSI_D_6
-637 MX35_PAD_SD2_DATA2__USB_TOP_USBH2_DATA_1
-638 MX35_PAD_SD2_DATA2__GPIO2_4
-639 MX35_PAD_SD2_DATA3__ESDHC2_DAT3
-640 MX35_PAD_SD2_DATA3__UART3_CTS
-641 MX35_PAD_SD2_DATA3__CAN1_TXCAN
-642 MX35_PAD_SD2_DATA3__IPU_CSI_D_7
-643 MX35_PAD_SD2_DATA3__USB_TOP_USBH2_DATA_2
-644 MX35_PAD_SD2_DATA3__GPIO2_5
-645 MX35_PAD_ATA_CS0__ATA_CS0
-646 MX35_PAD_ATA_CS0__CSPI1_SS3
-647 MX35_PAD_ATA_CS0__IPU_DISPB_CS1
-648 MX35_PAD_ATA_CS0__GPIO2_6
-649 MX35_PAD_ATA_CS0__IPU_DIAGB_0
-650 MX35_PAD_ATA_CS0__ARM11P_TOP_MAX1_HMASTER_0
-651 MX35_PAD_ATA_CS1__ATA_CS1
-652 MX35_PAD_ATA_CS1__IPU_DISPB_CS2
-653 MX35_PAD_ATA_CS1__CSPI2_SS0
-654 MX35_PAD_ATA_CS1__GPIO2_7
-655 MX35_PAD_ATA_CS1__IPU_DIAGB_1
-656 MX35_PAD_ATA_CS1__ARM11P_TOP_MAX1_HMASTER_1
-657 MX35_PAD_ATA_DIOR__ATA_DIOR
-658 MX35_PAD_ATA_DIOR__ESDHC3_DAT0
-659 MX35_PAD_ATA_DIOR__USB_TOP_USBOTG_DIR
-660 MX35_PAD_ATA_DIOR__IPU_DISPB_BE0
-661 MX35_PAD_ATA_DIOR__CSPI2_SS1
-662 MX35_PAD_ATA_DIOR__GPIO2_8
-663 MX35_PAD_ATA_DIOR__IPU_DIAGB_2
-664 MX35_PAD_ATA_DIOR__ARM11P_TOP_MAX1_HMASTER_2
-665 MX35_PAD_ATA_DIOW__ATA_DIOW
-666 MX35_PAD_ATA_DIOW__ESDHC3_DAT1
-667 MX35_PAD_ATA_DIOW__USB_TOP_USBOTG_STP
-668 MX35_PAD_ATA_DIOW__IPU_DISPB_BE1
-669 MX35_PAD_ATA_DIOW__CSPI2_MOSI
-670 MX35_PAD_ATA_DIOW__GPIO2_9
-671 MX35_PAD_ATA_DIOW__IPU_DIAGB_3
-672 MX35_PAD_ATA_DIOW__ARM11P_TOP_MAX1_HMASTER_3
-673 MX35_PAD_ATA_DMACK__ATA_DMACK
-674 MX35_PAD_ATA_DMACK__ESDHC3_DAT2
-675 MX35_PAD_ATA_DMACK__USB_TOP_USBOTG_NXT
-676 MX35_PAD_ATA_DMACK__CSPI2_MISO
-677 MX35_PAD_ATA_DMACK__GPIO2_10
-678 MX35_PAD_ATA_DMACK__IPU_DIAGB_4
-679 MX35_PAD_ATA_DMACK__ARM11P_TOP_MAX0_HMASTER_0
-680 MX35_PAD_ATA_RESET_B__ATA_RESET_B
-681 MX35_PAD_ATA_RESET_B__ESDHC3_DAT3
-682 MX35_PAD_ATA_RESET_B__USB_TOP_USBOTG_DATA_0
-683 MX35_PAD_ATA_RESET_B__IPU_DISPB_SD_D_O
-684 MX35_PAD_ATA_RESET_B__CSPI2_RDY
-685 MX35_PAD_ATA_RESET_B__GPIO2_11
-686 MX35_PAD_ATA_RESET_B__IPU_DIAGB_5
-687 MX35_PAD_ATA_RESET_B__ARM11P_TOP_MAX0_HMASTER_1
-688 MX35_PAD_ATA_IORDY__ATA_IORDY
-689 MX35_PAD_ATA_IORDY__ESDHC3_DAT4
-690 MX35_PAD_ATA_IORDY__USB_TOP_USBOTG_DATA_1
-691 MX35_PAD_ATA_IORDY__IPU_DISPB_SD_D_IO
-692 MX35_PAD_ATA_IORDY__ESDHC2_DAT4
-693 MX35_PAD_ATA_IORDY__GPIO2_12
-694 MX35_PAD_ATA_IORDY__IPU_DIAGB_6
-695 MX35_PAD_ATA_IORDY__ARM11P_TOP_MAX0_HMASTER_2
-696 MX35_PAD_ATA_DATA0__ATA_DATA_0
-697 MX35_PAD_ATA_DATA0__ESDHC3_DAT5
-698 MX35_PAD_ATA_DATA0__USB_TOP_USBOTG_DATA_2
-699 MX35_PAD_ATA_DATA0__IPU_DISPB_D12_VSYNC
-700 MX35_PAD_ATA_DATA0__ESDHC2_DAT5
-701 MX35_PAD_ATA_DATA0__GPIO2_13
-702 MX35_PAD_ATA_DATA0__IPU_DIAGB_7
-703 MX35_PAD_ATA_DATA0__ARM11P_TOP_MAX0_HMASTER_3
-704 MX35_PAD_ATA_DATA1__ATA_DATA_1
-705 MX35_PAD_ATA_DATA1__ESDHC3_DAT6
-706 MX35_PAD_ATA_DATA1__USB_TOP_USBOTG_DATA_3
-707 MX35_PAD_ATA_DATA1__IPU_DISPB_SD_CLK
-708 MX35_PAD_ATA_DATA1__ESDHC2_DAT6
-709 MX35_PAD_ATA_DATA1__GPIO2_14
-710 MX35_PAD_ATA_DATA1__IPU_DIAGB_8
-711 MX35_PAD_ATA_DATA1__ARM11P_TOP_TRACE_27
-712 MX35_PAD_ATA_DATA2__ATA_DATA_2
-713 MX35_PAD_ATA_DATA2__ESDHC3_DAT7
-714 MX35_PAD_ATA_DATA2__USB_TOP_USBOTG_DATA_4
-715 MX35_PAD_ATA_DATA2__IPU_DISPB_SER_RS
-716 MX35_PAD_ATA_DATA2__ESDHC2_DAT7
-717 MX35_PAD_ATA_DATA2__GPIO2_15
-718 MX35_PAD_ATA_DATA2__IPU_DIAGB_9
-719 MX35_PAD_ATA_DATA2__ARM11P_TOP_TRACE_28
-720 MX35_PAD_ATA_DATA3__ATA_DATA_3
-721 MX35_PAD_ATA_DATA3__ESDHC3_CLK
-722 MX35_PAD_ATA_DATA3__USB_TOP_USBOTG_DATA_5
-723 MX35_PAD_ATA_DATA3__CSPI2_SCLK
-724 MX35_PAD_ATA_DATA3__GPIO2_16
-725 MX35_PAD_ATA_DATA3__IPU_DIAGB_10
-726 MX35_PAD_ATA_DATA3__ARM11P_TOP_TRACE_29
-727 MX35_PAD_ATA_DATA4__ATA_DATA_4
-728 MX35_PAD_ATA_DATA4__ESDHC3_CMD
-729 MX35_PAD_ATA_DATA4__USB_TOP_USBOTG_DATA_6
-730 MX35_PAD_ATA_DATA4__GPIO2_17
-731 MX35_PAD_ATA_DATA4__IPU_DIAGB_11
-732 MX35_PAD_ATA_DATA4__ARM11P_TOP_TRACE_30
-733 MX35_PAD_ATA_DATA5__ATA_DATA_5
-734 MX35_PAD_ATA_DATA5__USB_TOP_USBOTG_DATA_7
-735 MX35_PAD_ATA_DATA5__GPIO2_18
-736 MX35_PAD_ATA_DATA5__IPU_DIAGB_12
-737 MX35_PAD_ATA_DATA5__ARM11P_TOP_TRACE_31
-738 MX35_PAD_ATA_DATA6__ATA_DATA_6
-739 MX35_PAD_ATA_DATA6__CAN1_TXCAN
-740 MX35_PAD_ATA_DATA6__UART1_DTR
-741 MX35_PAD_ATA_DATA6__AUDMUX_AUD6_TXD
-742 MX35_PAD_ATA_DATA6__GPIO2_19
-743 MX35_PAD_ATA_DATA6__IPU_DIAGB_13
-744 MX35_PAD_ATA_DATA7__ATA_DATA_7
-745 MX35_PAD_ATA_DATA7__CAN1_RXCAN
-746 MX35_PAD_ATA_DATA7__UART1_DSR
-747 MX35_PAD_ATA_DATA7__AUDMUX_AUD6_RXD
-748 MX35_PAD_ATA_DATA7__GPIO2_20
-749 MX35_PAD_ATA_DATA7__IPU_DIAGB_14
-750 MX35_PAD_ATA_DATA8__ATA_DATA_8
-751 MX35_PAD_ATA_DATA8__UART3_RTS
-752 MX35_PAD_ATA_DATA8__UART1_RI
-753 MX35_PAD_ATA_DATA8__AUDMUX_AUD6_TXC
-754 MX35_PAD_ATA_DATA8__GPIO2_21
-755 MX35_PAD_ATA_DATA8__IPU_DIAGB_15
-756 MX35_PAD_ATA_DATA9__ATA_DATA_9
-757 MX35_PAD_ATA_DATA9__UART3_CTS
-758 MX35_PAD_ATA_DATA9__UART1_DCD
-759 MX35_PAD_ATA_DATA9__AUDMUX_AUD6_TXFS
-760 MX35_PAD_ATA_DATA9__GPIO2_22
-761 MX35_PAD_ATA_DATA9__IPU_DIAGB_16
-762 MX35_PAD_ATA_DATA10__ATA_DATA_10
-763 MX35_PAD_ATA_DATA10__UART3_RXD_MUX
-764 MX35_PAD_ATA_DATA10__AUDMUX_AUD6_RXC
-765 MX35_PAD_ATA_DATA10__GPIO2_23
-766 MX35_PAD_ATA_DATA10__IPU_DIAGB_17
-767 MX35_PAD_ATA_DATA11__ATA_DATA_11
-768 MX35_PAD_ATA_DATA11__UART3_TXD_MUX
-769 MX35_PAD_ATA_DATA11__AUDMUX_AUD6_RXFS
-770 MX35_PAD_ATA_DATA11__GPIO2_24
-771 MX35_PAD_ATA_DATA11__IPU_DIAGB_18
-772 MX35_PAD_ATA_DATA12__ATA_DATA_12
-773 MX35_PAD_ATA_DATA12__I2C3_SCL
-774 MX35_PAD_ATA_DATA12__GPIO2_25
-775 MX35_PAD_ATA_DATA12__IPU_DIAGB_19
-776 MX35_PAD_ATA_DATA13__ATA_DATA_13
-777 MX35_PAD_ATA_DATA13__I2C3_SDA
-778 MX35_PAD_ATA_DATA13__GPIO2_26
-779 MX35_PAD_ATA_DATA13__IPU_DIAGB_20
-780 MX35_PAD_ATA_DATA14__ATA_DATA_14
-781 MX35_PAD_ATA_DATA14__IPU_CSI_D_0
-782 MX35_PAD_ATA_DATA14__KPP_ROW_0
-783 MX35_PAD_ATA_DATA14__GPIO2_27
-784 MX35_PAD_ATA_DATA14__IPU_DIAGB_21
-785 MX35_PAD_ATA_DATA15__ATA_DATA_15
-786 MX35_PAD_ATA_DATA15__IPU_CSI_D_1
-787 MX35_PAD_ATA_DATA15__KPP_ROW_1
-788 MX35_PAD_ATA_DATA15__GPIO2_28
-789 MX35_PAD_ATA_DATA15__IPU_DIAGB_22
-790 MX35_PAD_ATA_INTRQ__ATA_INTRQ
-791 MX35_PAD_ATA_INTRQ__IPU_CSI_D_2
-792 MX35_PAD_ATA_INTRQ__KPP_ROW_2
-793 MX35_PAD_ATA_INTRQ__GPIO2_29
-794 MX35_PAD_ATA_INTRQ__IPU_DIAGB_23
-795 MX35_PAD_ATA_BUFF_EN__ATA_BUFFER_EN
-796 MX35_PAD_ATA_BUFF_EN__IPU_CSI_D_3
-797 MX35_PAD_ATA_BUFF_EN__KPP_ROW_3
-798 MX35_PAD_ATA_BUFF_EN__GPIO2_30
-799 MX35_PAD_ATA_BUFF_EN__IPU_DIAGB_24
-800 MX35_PAD_ATA_DMARQ__ATA_DMARQ
-801 MX35_PAD_ATA_DMARQ__IPU_CSI_D_4
-802 MX35_PAD_ATA_DMARQ__KPP_COL_0
-803 MX35_PAD_ATA_DMARQ__GPIO2_31
-804 MX35_PAD_ATA_DMARQ__IPU_DIAGB_25
-805 MX35_PAD_ATA_DMARQ__ECT_CTI_TRIG_IN1_4
-806 MX35_PAD_ATA_DA0__ATA_DA_0
-807 MX35_PAD_ATA_DA0__IPU_CSI_D_5
-808 MX35_PAD_ATA_DA0__KPP_COL_1
-809 MX35_PAD_ATA_DA0__GPIO3_0
-810 MX35_PAD_ATA_DA0__IPU_DIAGB_26
-811 MX35_PAD_ATA_DA0__ECT_CTI_TRIG_IN1_5
-812 MX35_PAD_ATA_DA1__ATA_DA_1
-813 MX35_PAD_ATA_DA1__IPU_CSI_D_6
-814 MX35_PAD_ATA_DA1__KPP_COL_2
-815 MX35_PAD_ATA_DA1__GPIO3_1
-816 MX35_PAD_ATA_DA1__IPU_DIAGB_27
-817 MX35_PAD_ATA_DA1__ECT_CTI_TRIG_IN1_6
-818 MX35_PAD_ATA_DA2__ATA_DA_2
-819 MX35_PAD_ATA_DA2__IPU_CSI_D_7
-820 MX35_PAD_ATA_DA2__KPP_COL_3
-821 MX35_PAD_ATA_DA2__GPIO3_2
-822 MX35_PAD_ATA_DA2__IPU_DIAGB_28
-823 MX35_PAD_ATA_DA2__ECT_CTI_TRIG_IN1_7
-824 MX35_PAD_MLB_CLK__MLB_MLBCLK
-825 MX35_PAD_MLB_CLK__GPIO3_3
-826 MX35_PAD_MLB_DAT__MLB_MLBDAT
-827 MX35_PAD_MLB_DAT__GPIO3_4
-828 MX35_PAD_MLB_SIG__MLB_MLBSIG
-829 MX35_PAD_MLB_SIG__GPIO3_5
-830 MX35_PAD_FEC_TX_CLK__FEC_TX_CLK
-831 MX35_PAD_FEC_TX_CLK__ESDHC1_DAT4
-832 MX35_PAD_FEC_TX_CLK__UART3_RXD_MUX
-833 MX35_PAD_FEC_TX_CLK__USB_TOP_USBH2_DIR
-834 MX35_PAD_FEC_TX_CLK__CSPI2_MOSI
-835 MX35_PAD_FEC_TX_CLK__GPIO3_6
-836 MX35_PAD_FEC_TX_CLK__IPU_DISPB_D12_VSYNC
-837 MX35_PAD_FEC_TX_CLK__ARM11P_TOP_EVNTBUS_0
-838 MX35_PAD_FEC_RX_CLK__FEC_RX_CLK
-839 MX35_PAD_FEC_RX_CLK__ESDHC1_DAT5
-840 MX35_PAD_FEC_RX_CLK__UART3_TXD_MUX
-841 MX35_PAD_FEC_RX_CLK__USB_TOP_USBH2_STP
-842 MX35_PAD_FEC_RX_CLK__CSPI2_MISO
-843 MX35_PAD_FEC_RX_CLK__GPIO3_7
-844 MX35_PAD_FEC_RX_CLK__IPU_DISPB_SD_D_I
-845 MX35_PAD_FEC_RX_CLK__ARM11P_TOP_EVNTBUS_1
-846 MX35_PAD_FEC_RX_DV__FEC_RX_DV
-847 MX35_PAD_FEC_RX_DV__ESDHC1_DAT6
-848 MX35_PAD_FEC_RX_DV__UART3_RTS
-849 MX35_PAD_FEC_RX_DV__USB_TOP_USBH2_NXT
-850 MX35_PAD_FEC_RX_DV__CSPI2_SCLK
-851 MX35_PAD_FEC_RX_DV__GPIO3_8
-852 MX35_PAD_FEC_RX_DV__IPU_DISPB_SD_CLK
-853 MX35_PAD_FEC_RX_DV__ARM11P_TOP_EVNTBUS_2
-854 MX35_PAD_FEC_COL__FEC_COL
-855 MX35_PAD_FEC_COL__ESDHC1_DAT7
-856 MX35_PAD_FEC_COL__UART3_CTS
-857 MX35_PAD_FEC_COL__USB_TOP_USBH2_DATA_0
-858 MX35_PAD_FEC_COL__CSPI2_RDY
-859 MX35_PAD_FEC_COL__GPIO3_9
-860 MX35_PAD_FEC_COL__IPU_DISPB_SER_RS
-861 MX35_PAD_FEC_COL__ARM11P_TOP_EVNTBUS_3
-862 MX35_PAD_FEC_RDATA0__FEC_RDATA_0
-863 MX35_PAD_FEC_RDATA0__PWM_PWMO
-864 MX35_PAD_FEC_RDATA0__UART3_DTR
-865 MX35_PAD_FEC_RDATA0__USB_TOP_USBH2_DATA_1
-866 MX35_PAD_FEC_RDATA0__CSPI2_SS0
-867 MX35_PAD_FEC_RDATA0__GPIO3_10
-868 MX35_PAD_FEC_RDATA0__IPU_DISPB_CS1
-869 MX35_PAD_FEC_RDATA0__ARM11P_TOP_EVNTBUS_4
-870 MX35_PAD_FEC_TDATA0__FEC_TDATA_0
-871 MX35_PAD_FEC_TDATA0__SPDIF_SPDIF_OUT1
-872 MX35_PAD_FEC_TDATA0__UART3_DSR
-873 MX35_PAD_FEC_TDATA0__USB_TOP_USBH2_DATA_2
-874 MX35_PAD_FEC_TDATA0__CSPI2_SS1
-875 MX35_PAD_FEC_TDATA0__GPIO3_11
-876 MX35_PAD_FEC_TDATA0__IPU_DISPB_CS0
-877 MX35_PAD_FEC_TDATA0__ARM11P_TOP_EVNTBUS_5
-878 MX35_PAD_FEC_TX_EN__FEC_TX_EN
-879 MX35_PAD_FEC_TX_EN__SPDIF_SPDIF_IN1
-880 MX35_PAD_FEC_TX_EN__UART3_RI
-881 MX35_PAD_FEC_TX_EN__USB_TOP_USBH2_DATA_3
-882 MX35_PAD_FEC_TX_EN__GPIO3_12
-883 MX35_PAD_FEC_TX_EN__IPU_DISPB_PAR_RS
-884 MX35_PAD_FEC_TX_EN__ARM11P_TOP_EVNTBUS_6
-885 MX35_PAD_FEC_MDC__FEC_MDC
-886 MX35_PAD_FEC_MDC__CAN2_TXCAN
-887 MX35_PAD_FEC_MDC__UART3_DCD
-888 MX35_PAD_FEC_MDC__USB_TOP_USBH2_DATA_4
-889 MX35_PAD_FEC_MDC__GPIO3_13
-890 MX35_PAD_FEC_MDC__IPU_DISPB_WR
-891 MX35_PAD_FEC_MDC__ARM11P_TOP_EVNTBUS_7
-892 MX35_PAD_FEC_MDIO__FEC_MDIO
-893 MX35_PAD_FEC_MDIO__CAN2_RXCAN
-894 MX35_PAD_FEC_MDIO__USB_TOP_USBH2_DATA_5
-895 MX35_PAD_FEC_MDIO__GPIO3_14
-896 MX35_PAD_FEC_MDIO__IPU_DISPB_RD
-897 MX35_PAD_FEC_MDIO__ARM11P_TOP_EVNTBUS_8
-898 MX35_PAD_FEC_TX_ERR__FEC_TX_ERR
-899 MX35_PAD_FEC_TX_ERR__OWIRE_LINE
-900 MX35_PAD_FEC_TX_ERR__SPDIF_SPDIF_EXTCLK
-901 MX35_PAD_FEC_TX_ERR__USB_TOP_USBH2_DATA_6
-902 MX35_PAD_FEC_TX_ERR__GPIO3_15
-903 MX35_PAD_FEC_TX_ERR__IPU_DISPB_D0_VSYNC
-904 MX35_PAD_FEC_TX_ERR__ARM11P_TOP_EVNTBUS_9
-905 MX35_PAD_FEC_RX_ERR__FEC_RX_ERR
-906 MX35_PAD_FEC_RX_ERR__IPU_CSI_D_0
-907 MX35_PAD_FEC_RX_ERR__USB_TOP_USBH2_DATA_7
-908 MX35_PAD_FEC_RX_ERR__KPP_COL_4
-909 MX35_PAD_FEC_RX_ERR__GPIO3_16
-910 MX35_PAD_FEC_RX_ERR__IPU_DISPB_SD_D_IO
-911 MX35_PAD_FEC_CRS__FEC_CRS
-912 MX35_PAD_FEC_CRS__IPU_CSI_D_1
-913 MX35_PAD_FEC_CRS__USB_TOP_USBH2_PWR
-914 MX35_PAD_FEC_CRS__KPP_COL_5
-915 MX35_PAD_FEC_CRS__GPIO3_17
-916 MX35_PAD_FEC_CRS__IPU_FLASH_STROBE
-917 MX35_PAD_FEC_RDATA1__FEC_RDATA_1
-918 MX35_PAD_FEC_RDATA1__IPU_CSI_D_2
-919 MX35_PAD_FEC_RDATA1__AUDMUX_AUD6_RXC
-920 MX35_PAD_FEC_RDATA1__USB_TOP_USBH2_OC
-921 MX35_PAD_FEC_RDATA1__KPP_COL_6
-922 MX35_PAD_FEC_RDATA1__GPIO3_18
-923 MX35_PAD_FEC_RDATA1__IPU_DISPB_BE0
-924 MX35_PAD_FEC_TDATA1__FEC_TDATA_1
-925 MX35_PAD_FEC_TDATA1__IPU_CSI_D_3
-926 MX35_PAD_FEC_TDATA1__AUDMUX_AUD6_RXFS
-927 MX35_PAD_FEC_TDATA1__KPP_COL_7
-928 MX35_PAD_FEC_TDATA1__GPIO3_19
-929 MX35_PAD_FEC_TDATA1__IPU_DISPB_BE1
-930 MX35_PAD_FEC_RDATA2__FEC_RDATA_2
-931 MX35_PAD_FEC_RDATA2__IPU_CSI_D_4
-932 MX35_PAD_FEC_RDATA2__AUDMUX_AUD6_TXD
-933 MX35_PAD_FEC_RDATA2__KPP_ROW_4
-934 MX35_PAD_FEC_RDATA2__GPIO3_20
-935 MX35_PAD_FEC_TDATA2__FEC_TDATA_2
-936 MX35_PAD_FEC_TDATA2__IPU_CSI_D_5
-937 MX35_PAD_FEC_TDATA2__AUDMUX_AUD6_RXD
-938 MX35_PAD_FEC_TDATA2__KPP_ROW_5
-939 MX35_PAD_FEC_TDATA2__GPIO3_21
-940 MX35_PAD_FEC_RDATA3__FEC_RDATA_3
-941 MX35_PAD_FEC_RDATA3__IPU_CSI_D_6
-942 MX35_PAD_FEC_RDATA3__AUDMUX_AUD6_TXC
-943 MX35_PAD_FEC_RDATA3__KPP_ROW_6
-944 MX35_PAD_FEC_RDATA3__GPIO3_22
-945 MX35_PAD_FEC_TDATA3__FEC_TDATA_3
-946 MX35_PAD_FEC_TDATA3__IPU_CSI_D_7
-947 MX35_PAD_FEC_TDATA3__AUDMUX_AUD6_TXFS
-948 MX35_PAD_FEC_TDATA3__KPP_ROW_7
-949 MX35_PAD_FEC_TDATA3__GPIO3_23
-950 MX35_PAD_EXT_ARMCLK__CCM_EXT_ARMCLK
-951 MX35_PAD_TEST_MODE__TCU_TEST_MODE
+Refer to imx35-pinfunc.h in device tree source folder for all available
+imx35 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
index b96fa4c31745..4d1408fcc99c 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt
@@ -28,760 +28,5 @@ PAD_CTL_DSE_MAX (3 << 1)
PAD_CTL_SRE_FAST (1 << 0)
PAD_CTL_SRE_SLOW (0 << 0)
-See below for available PIN_FUNC_ID for imx51:
-MX51_PAD_EIM_D16__AUD4_RXFS 0
-MX51_PAD_EIM_D16__AUD5_TXD 1
-MX51_PAD_EIM_D16__EIM_D16 2
-MX51_PAD_EIM_D16__GPIO2_0 3
-MX51_PAD_EIM_D16__I2C1_SDA 4
-MX51_PAD_EIM_D16__UART2_CTS 5
-MX51_PAD_EIM_D16__USBH2_DATA0 6
-MX51_PAD_EIM_D17__AUD5_RXD 7
-MX51_PAD_EIM_D17__EIM_D17 8
-MX51_PAD_EIM_D17__GPIO2_1 9
-MX51_PAD_EIM_D17__UART2_RXD 10
-MX51_PAD_EIM_D17__UART3_CTS 11
-MX51_PAD_EIM_D17__USBH2_DATA1 12
-MX51_PAD_EIM_D18__AUD5_TXC 13
-MX51_PAD_EIM_D18__EIM_D18 14
-MX51_PAD_EIM_D18__GPIO2_2 15
-MX51_PAD_EIM_D18__UART2_TXD 16
-MX51_PAD_EIM_D18__UART3_RTS 17
-MX51_PAD_EIM_D18__USBH2_DATA2 18
-MX51_PAD_EIM_D19__AUD4_RXC 19
-MX51_PAD_EIM_D19__AUD5_TXFS 20
-MX51_PAD_EIM_D19__EIM_D19 21
-MX51_PAD_EIM_D19__GPIO2_3 22
-MX51_PAD_EIM_D19__I2C1_SCL 23
-MX51_PAD_EIM_D19__UART2_RTS 24
-MX51_PAD_EIM_D19__USBH2_DATA3 25
-MX51_PAD_EIM_D20__AUD4_TXD 26
-MX51_PAD_EIM_D20__EIM_D20 27
-MX51_PAD_EIM_D20__GPIO2_4 28
-MX51_PAD_EIM_D20__SRTC_ALARM_DEB 29
-MX51_PAD_EIM_D20__USBH2_DATA4 30
-MX51_PAD_EIM_D21__AUD4_RXD 31
-MX51_PAD_EIM_D21__EIM_D21 32
-MX51_PAD_EIM_D21__GPIO2_5 33
-MX51_PAD_EIM_D21__SRTC_ALARM_DEB 34
-MX51_PAD_EIM_D21__USBH2_DATA5 35
-MX51_PAD_EIM_D22__AUD4_TXC 36
-MX51_PAD_EIM_D22__EIM_D22 37
-MX51_PAD_EIM_D22__GPIO2_6 38
-MX51_PAD_EIM_D22__USBH2_DATA6 39
-MX51_PAD_EIM_D23__AUD4_TXFS 40
-MX51_PAD_EIM_D23__EIM_D23 41
-MX51_PAD_EIM_D23__GPIO2_7 42
-MX51_PAD_EIM_D23__SPDIF_OUT1 43
-MX51_PAD_EIM_D23__USBH2_DATA7 44
-MX51_PAD_EIM_D24__AUD6_RXFS 45
-MX51_PAD_EIM_D24__EIM_D24 46
-MX51_PAD_EIM_D24__GPIO2_8 47
-MX51_PAD_EIM_D24__I2C2_SDA 48
-MX51_PAD_EIM_D24__UART3_CTS 49
-MX51_PAD_EIM_D24__USBOTG_DATA0 50
-MX51_PAD_EIM_D25__EIM_D25 51
-MX51_PAD_EIM_D25__KEY_COL6 52
-MX51_PAD_EIM_D25__UART2_CTS 53
-MX51_PAD_EIM_D25__UART3_RXD 54
-MX51_PAD_EIM_D25__USBOTG_DATA1 55
-MX51_PAD_EIM_D26__EIM_D26 56
-MX51_PAD_EIM_D26__KEY_COL7 57
-MX51_PAD_EIM_D26__UART2_RTS 58
-MX51_PAD_EIM_D26__UART3_TXD 59
-MX51_PAD_EIM_D26__USBOTG_DATA2 60
-MX51_PAD_EIM_D27__AUD6_RXC 61
-MX51_PAD_EIM_D27__EIM_D27 62
-MX51_PAD_EIM_D27__GPIO2_9 63
-MX51_PAD_EIM_D27__I2C2_SCL 64
-MX51_PAD_EIM_D27__UART3_RTS 65
-MX51_PAD_EIM_D27__USBOTG_DATA3 66
-MX51_PAD_EIM_D28__AUD6_TXD 67
-MX51_PAD_EIM_D28__EIM_D28 68
-MX51_PAD_EIM_D28__KEY_ROW4 69
-MX51_PAD_EIM_D28__USBOTG_DATA4 70
-MX51_PAD_EIM_D29__AUD6_RXD 71
-MX51_PAD_EIM_D29__EIM_D29 72
-MX51_PAD_EIM_D29__KEY_ROW5 73
-MX51_PAD_EIM_D29__USBOTG_DATA5 74
-MX51_PAD_EIM_D30__AUD6_TXC 75
-MX51_PAD_EIM_D30__EIM_D30 76
-MX51_PAD_EIM_D30__KEY_ROW6 77
-MX51_PAD_EIM_D30__USBOTG_DATA6 78
-MX51_PAD_EIM_D31__AUD6_TXFS 79
-MX51_PAD_EIM_D31__EIM_D31 80
-MX51_PAD_EIM_D31__KEY_ROW7 81
-MX51_PAD_EIM_D31__USBOTG_DATA7 82
-MX51_PAD_EIM_A16__EIM_A16 83
-MX51_PAD_EIM_A16__GPIO2_10 84
-MX51_PAD_EIM_A16__OSC_FREQ_SEL0 85
-MX51_PAD_EIM_A17__EIM_A17 86
-MX51_PAD_EIM_A17__GPIO2_11 87
-MX51_PAD_EIM_A17__OSC_FREQ_SEL1 88
-MX51_PAD_EIM_A18__BOOT_LPB0 89
-MX51_PAD_EIM_A18__EIM_A18 90
-MX51_PAD_EIM_A18__GPIO2_12 91
-MX51_PAD_EIM_A19__BOOT_LPB1 92
-MX51_PAD_EIM_A19__EIM_A19 93
-MX51_PAD_EIM_A19__GPIO2_13 94
-MX51_PAD_EIM_A20__BOOT_UART_SRC0 95
-MX51_PAD_EIM_A20__EIM_A20 96
-MX51_PAD_EIM_A20__GPIO2_14 97
-MX51_PAD_EIM_A21__BOOT_UART_SRC1 98
-MX51_PAD_EIM_A21__EIM_A21 99
-MX51_PAD_EIM_A21__GPIO2_15 100
-MX51_PAD_EIM_A22__EIM_A22 101
-MX51_PAD_EIM_A22__GPIO2_16 102
-MX51_PAD_EIM_A23__BOOT_HPN_EN 103
-MX51_PAD_EIM_A23__EIM_A23 104
-MX51_PAD_EIM_A23__GPIO2_17 105
-MX51_PAD_EIM_A24__EIM_A24 106
-MX51_PAD_EIM_A24__GPIO2_18 107
-MX51_PAD_EIM_A24__USBH2_CLK 108
-MX51_PAD_EIM_A25__DISP1_PIN4 109
-MX51_PAD_EIM_A25__EIM_A25 110
-MX51_PAD_EIM_A25__GPIO2_19 111
-MX51_PAD_EIM_A25__USBH2_DIR 112
-MX51_PAD_EIM_A26__CSI1_DATA_EN 113
-MX51_PAD_EIM_A26__DISP2_EXT_CLK 114
-MX51_PAD_EIM_A26__EIM_A26 115
-MX51_PAD_EIM_A26__GPIO2_20 116
-MX51_PAD_EIM_A26__USBH2_STP 117
-MX51_PAD_EIM_A27__CSI2_DATA_EN 118
-MX51_PAD_EIM_A27__DISP1_PIN1 119
-MX51_PAD_EIM_A27__EIM_A27 120
-MX51_PAD_EIM_A27__GPIO2_21 121
-MX51_PAD_EIM_A27__USBH2_NXT 122
-MX51_PAD_EIM_EB0__EIM_EB0 123
-MX51_PAD_EIM_EB1__EIM_EB1 124
-MX51_PAD_EIM_EB2__AUD5_RXFS 125
-MX51_PAD_EIM_EB2__CSI1_D2 126
-MX51_PAD_EIM_EB2__EIM_EB2 127
-MX51_PAD_EIM_EB2__FEC_MDIO 128
-MX51_PAD_EIM_EB2__GPIO2_22 129
-MX51_PAD_EIM_EB2__GPT_CMPOUT1 130
-MX51_PAD_EIM_EB3__AUD5_RXC 131
-MX51_PAD_EIM_EB3__CSI1_D3 132
-MX51_PAD_EIM_EB3__EIM_EB3 133
-MX51_PAD_EIM_EB3__FEC_RDATA1 134
-MX51_PAD_EIM_EB3__GPIO2_23 135
-MX51_PAD_EIM_EB3__GPT_CMPOUT2 136
-MX51_PAD_EIM_OE__EIM_OE 137
-MX51_PAD_EIM_OE__GPIO2_24 138
-MX51_PAD_EIM_CS0__EIM_CS0 139
-MX51_PAD_EIM_CS0__GPIO2_25 140
-MX51_PAD_EIM_CS1__EIM_CS1 141
-MX51_PAD_EIM_CS1__GPIO2_26 142
-MX51_PAD_EIM_CS2__AUD5_TXD 143
-MX51_PAD_EIM_CS2__CSI1_D4 144
-MX51_PAD_EIM_CS2__EIM_CS2 145
-MX51_PAD_EIM_CS2__FEC_RDATA2 146
-MX51_PAD_EIM_CS2__GPIO2_27 147
-MX51_PAD_EIM_CS2__USBOTG_STP 148
-MX51_PAD_EIM_CS3__AUD5_RXD 149
-MX51_PAD_EIM_CS3__CSI1_D5 150
-MX51_PAD_EIM_CS3__EIM_CS3 151
-MX51_PAD_EIM_CS3__FEC_RDATA3 152
-MX51_PAD_EIM_CS3__GPIO2_28 153
-MX51_PAD_EIM_CS3__USBOTG_NXT 154
-MX51_PAD_EIM_CS4__AUD5_TXC 155
-MX51_PAD_EIM_CS4__CSI1_D6 156
-MX51_PAD_EIM_CS4__EIM_CS4 157
-MX51_PAD_EIM_CS4__FEC_RX_ER 158
-MX51_PAD_EIM_CS4__GPIO2_29 159
-MX51_PAD_EIM_CS4__USBOTG_CLK 160
-MX51_PAD_EIM_CS5__AUD5_TXFS 161
-MX51_PAD_EIM_CS5__CSI1_D7 162
-MX51_PAD_EIM_CS5__DISP1_EXT_CLK 163
-MX51_PAD_EIM_CS5__EIM_CS5 164
-MX51_PAD_EIM_CS5__FEC_CRS 165
-MX51_PAD_EIM_CS5__GPIO2_30 166
-MX51_PAD_EIM_CS5__USBOTG_DIR 167
-MX51_PAD_EIM_DTACK__EIM_DTACK 168
-MX51_PAD_EIM_DTACK__GPIO2_31 169
-MX51_PAD_EIM_LBA__EIM_LBA 170
-MX51_PAD_EIM_LBA__GPIO3_1 171
-MX51_PAD_EIM_CRE__EIM_CRE 172
-MX51_PAD_EIM_CRE__GPIO3_2 173
-MX51_PAD_DRAM_CS1__DRAM_CS1 174
-MX51_PAD_NANDF_WE_B__GPIO3_3 175
-MX51_PAD_NANDF_WE_B__NANDF_WE_B 176
-MX51_PAD_NANDF_WE_B__PATA_DIOW 177
-MX51_PAD_NANDF_WE_B__SD3_DATA0 178
-MX51_PAD_NANDF_RE_B__GPIO3_4 179
-MX51_PAD_NANDF_RE_B__NANDF_RE_B 180
-MX51_PAD_NANDF_RE_B__PATA_DIOR 181
-MX51_PAD_NANDF_RE_B__SD3_DATA1 182
-MX51_PAD_NANDF_ALE__GPIO3_5 183
-MX51_PAD_NANDF_ALE__NANDF_ALE 184
-MX51_PAD_NANDF_ALE__PATA_BUFFER_EN 185
-MX51_PAD_NANDF_CLE__GPIO3_6 186
-MX51_PAD_NANDF_CLE__NANDF_CLE 187
-MX51_PAD_NANDF_CLE__PATA_RESET_B 188
-MX51_PAD_NANDF_WP_B__GPIO3_7 189
-MX51_PAD_NANDF_WP_B__NANDF_WP_B 190
-MX51_PAD_NANDF_WP_B__PATA_DMACK 191
-MX51_PAD_NANDF_WP_B__SD3_DATA2 192
-MX51_PAD_NANDF_RB0__ECSPI2_SS1 193
-MX51_PAD_NANDF_RB0__GPIO3_8 194
-MX51_PAD_NANDF_RB0__NANDF_RB0 195
-MX51_PAD_NANDF_RB0__PATA_DMARQ 196
-MX51_PAD_NANDF_RB0__SD3_DATA3 197
-MX51_PAD_NANDF_RB1__CSPI_MOSI 198
-MX51_PAD_NANDF_RB1__ECSPI2_RDY 199
-MX51_PAD_NANDF_RB1__GPIO3_9 200
-MX51_PAD_NANDF_RB1__NANDF_RB1 201
-MX51_PAD_NANDF_RB1__PATA_IORDY 202
-MX51_PAD_NANDF_RB1__SD4_CMD 203
-MX51_PAD_NANDF_RB2__DISP2_WAIT 204
-MX51_PAD_NANDF_RB2__ECSPI2_SCLK 205
-MX51_PAD_NANDF_RB2__FEC_COL 206
-MX51_PAD_NANDF_RB2__GPIO3_10 207
-MX51_PAD_NANDF_RB2__NANDF_RB2 208
-MX51_PAD_NANDF_RB2__USBH3_H3_DP 209
-MX51_PAD_NANDF_RB2__USBH3_NXT 210
-MX51_PAD_NANDF_RB3__DISP1_WAIT 211
-MX51_PAD_NANDF_RB3__ECSPI2_MISO 212
-MX51_PAD_NANDF_RB3__FEC_RX_CLK 213
-MX51_PAD_NANDF_RB3__GPIO3_11 214
-MX51_PAD_NANDF_RB3__NANDF_RB3 215
-MX51_PAD_NANDF_RB3__USBH3_CLK 216
-MX51_PAD_NANDF_RB3__USBH3_H3_DM 217
-MX51_PAD_GPIO_NAND__GPIO_NAND 218
-MX51_PAD_GPIO_NAND__PATA_INTRQ 219
-MX51_PAD_NANDF_CS0__GPIO3_16 220
-MX51_PAD_NANDF_CS0__NANDF_CS0 221
-MX51_PAD_NANDF_CS1__GPIO3_17 222
-MX51_PAD_NANDF_CS1__NANDF_CS1 223
-MX51_PAD_NANDF_CS2__CSPI_SCLK 224
-MX51_PAD_NANDF_CS2__FEC_TX_ER 225
-MX51_PAD_NANDF_CS2__GPIO3_18 226
-MX51_PAD_NANDF_CS2__NANDF_CS2 227
-MX51_PAD_NANDF_CS2__PATA_CS_0 228
-MX51_PAD_NANDF_CS2__SD4_CLK 229
-MX51_PAD_NANDF_CS2__USBH3_H1_DP 230
-MX51_PAD_NANDF_CS3__FEC_MDC 231
-MX51_PAD_NANDF_CS3__GPIO3_19 232
-MX51_PAD_NANDF_CS3__NANDF_CS3 233
-MX51_PAD_NANDF_CS3__PATA_CS_1 234
-MX51_PAD_NANDF_CS3__SD4_DAT0 235
-MX51_PAD_NANDF_CS3__USBH3_H1_DM 236
-MX51_PAD_NANDF_CS4__FEC_TDATA1 237
-MX51_PAD_NANDF_CS4__GPIO3_20 238
-MX51_PAD_NANDF_CS4__NANDF_CS4 239
-MX51_PAD_NANDF_CS4__PATA_DA_0 240
-MX51_PAD_NANDF_CS4__SD4_DAT1 241
-MX51_PAD_NANDF_CS4__USBH3_STP 242
-MX51_PAD_NANDF_CS5__FEC_TDATA2 243
-MX51_PAD_NANDF_CS5__GPIO3_21 244
-MX51_PAD_NANDF_CS5__NANDF_CS5 245
-MX51_PAD_NANDF_CS5__PATA_DA_1 246
-MX51_PAD_NANDF_CS5__SD4_DAT2 247
-MX51_PAD_NANDF_CS5__USBH3_DIR 248
-MX51_PAD_NANDF_CS6__CSPI_SS3 249
-MX51_PAD_NANDF_CS6__FEC_TDATA3 250
-MX51_PAD_NANDF_CS6__GPIO3_22 251
-MX51_PAD_NANDF_CS6__NANDF_CS6 252
-MX51_PAD_NANDF_CS6__PATA_DA_2 253
-MX51_PAD_NANDF_CS6__SD4_DAT3 254
-MX51_PAD_NANDF_CS7__FEC_TX_EN 255
-MX51_PAD_NANDF_CS7__GPIO3_23 256
-MX51_PAD_NANDF_CS7__NANDF_CS7 257
-MX51_PAD_NANDF_CS7__SD3_CLK 258
-MX51_PAD_NANDF_RDY_INT__ECSPI2_SS0 259
-MX51_PAD_NANDF_RDY_INT__FEC_TX_CLK 260
-MX51_PAD_NANDF_RDY_INT__GPIO3_24 261
-MX51_PAD_NANDF_RDY_INT__NANDF_RDY_INT 262
-MX51_PAD_NANDF_RDY_INT__SD3_CMD 263
-MX51_PAD_NANDF_D15__ECSPI2_MOSI 264
-MX51_PAD_NANDF_D15__GPIO3_25 265
-MX51_PAD_NANDF_D15__NANDF_D15 266
-MX51_PAD_NANDF_D15__PATA_DATA15 267
-MX51_PAD_NANDF_D15__SD3_DAT7 268
-MX51_PAD_NANDF_D14__ECSPI2_SS3 269
-MX51_PAD_NANDF_D14__GPIO3_26 270
-MX51_PAD_NANDF_D14__NANDF_D14 271
-MX51_PAD_NANDF_D14__PATA_DATA14 272
-MX51_PAD_NANDF_D14__SD3_DAT6 273
-MX51_PAD_NANDF_D13__ECSPI2_SS2 274
-MX51_PAD_NANDF_D13__GPIO3_27 275
-MX51_PAD_NANDF_D13__NANDF_D13 276
-MX51_PAD_NANDF_D13__PATA_DATA13 277
-MX51_PAD_NANDF_D13__SD3_DAT5 278
-MX51_PAD_NANDF_D12__ECSPI2_SS1 279
-MX51_PAD_NANDF_D12__GPIO3_28 280
-MX51_PAD_NANDF_D12__NANDF_D12 281
-MX51_PAD_NANDF_D12__PATA_DATA12 282
-MX51_PAD_NANDF_D12__SD3_DAT4 283
-MX51_PAD_NANDF_D11__FEC_RX_DV 284
-MX51_PAD_NANDF_D11__GPIO3_29 285
-MX51_PAD_NANDF_D11__NANDF_D11 286
-MX51_PAD_NANDF_D11__PATA_DATA11 287
-MX51_PAD_NANDF_D11__SD3_DATA3 288
-MX51_PAD_NANDF_D10__GPIO3_30 289
-MX51_PAD_NANDF_D10__NANDF_D10 290
-MX51_PAD_NANDF_D10__PATA_DATA10 291
-MX51_PAD_NANDF_D10__SD3_DATA2 292
-MX51_PAD_NANDF_D9__FEC_RDATA0 293
-MX51_PAD_NANDF_D9__GPIO3_31 294
-MX51_PAD_NANDF_D9__NANDF_D9 295
-MX51_PAD_NANDF_D9__PATA_DATA9 296
-MX51_PAD_NANDF_D9__SD3_DATA1 297
-MX51_PAD_NANDF_D8__FEC_TDATA0 298
-MX51_PAD_NANDF_D8__GPIO4_0 299
-MX51_PAD_NANDF_D8__NANDF_D8 300
-MX51_PAD_NANDF_D8__PATA_DATA8 301
-MX51_PAD_NANDF_D8__SD3_DATA0 302
-MX51_PAD_NANDF_D7__GPIO4_1 303
-MX51_PAD_NANDF_D7__NANDF_D7 304
-MX51_PAD_NANDF_D7__PATA_DATA7 305
-MX51_PAD_NANDF_D7__USBH3_DATA0 306
-MX51_PAD_NANDF_D6__GPIO4_2 307
-MX51_PAD_NANDF_D6__NANDF_D6 308
-MX51_PAD_NANDF_D6__PATA_DATA6 309
-MX51_PAD_NANDF_D6__SD4_LCTL 310
-MX51_PAD_NANDF_D6__USBH3_DATA1 311
-MX51_PAD_NANDF_D5__GPIO4_3 312
-MX51_PAD_NANDF_D5__NANDF_D5 313
-MX51_PAD_NANDF_D5__PATA_DATA5 314
-MX51_PAD_NANDF_D5__SD4_WP 315
-MX51_PAD_NANDF_D5__USBH3_DATA2 316
-MX51_PAD_NANDF_D4__GPIO4_4 317
-MX51_PAD_NANDF_D4__NANDF_D4 318
-MX51_PAD_NANDF_D4__PATA_DATA4 319
-MX51_PAD_NANDF_D4__SD4_CD 320
-MX51_PAD_NANDF_D4__USBH3_DATA3 321
-MX51_PAD_NANDF_D3__GPIO4_5 322
-MX51_PAD_NANDF_D3__NANDF_D3 323
-MX51_PAD_NANDF_D3__PATA_DATA3 324
-MX51_PAD_NANDF_D3__SD4_DAT4 325
-MX51_PAD_NANDF_D3__USBH3_DATA4 326
-MX51_PAD_NANDF_D2__GPIO4_6 327
-MX51_PAD_NANDF_D2__NANDF_D2 328
-MX51_PAD_NANDF_D2__PATA_DATA2 329
-MX51_PAD_NANDF_D2__SD4_DAT5 330
-MX51_PAD_NANDF_D2__USBH3_DATA5 331
-MX51_PAD_NANDF_D1__GPIO4_7 332
-MX51_PAD_NANDF_D1__NANDF_D1 333
-MX51_PAD_NANDF_D1__PATA_DATA1 334
-MX51_PAD_NANDF_D1__SD4_DAT6 335
-MX51_PAD_NANDF_D1__USBH3_DATA6 336
-MX51_PAD_NANDF_D0__GPIO4_8 337
-MX51_PAD_NANDF_D0__NANDF_D0 338
-MX51_PAD_NANDF_D0__PATA_DATA0 339
-MX51_PAD_NANDF_D0__SD4_DAT7 340
-MX51_PAD_NANDF_D0__USBH3_DATA7 341
-MX51_PAD_CSI1_D8__CSI1_D8 342
-MX51_PAD_CSI1_D8__GPIO3_12 343
-MX51_PAD_CSI1_D9__CSI1_D9 344
-MX51_PAD_CSI1_D9__GPIO3_13 345
-MX51_PAD_CSI1_D10__CSI1_D10 346
-MX51_PAD_CSI1_D11__CSI1_D11 347
-MX51_PAD_CSI1_D12__CSI1_D12 348
-MX51_PAD_CSI1_D13__CSI1_D13 349
-MX51_PAD_CSI1_D14__CSI1_D14 350
-MX51_PAD_CSI1_D15__CSI1_D15 351
-MX51_PAD_CSI1_D16__CSI1_D16 352
-MX51_PAD_CSI1_D17__CSI1_D17 353
-MX51_PAD_CSI1_D18__CSI1_D18 354
-MX51_PAD_CSI1_D19__CSI1_D19 355
-MX51_PAD_CSI1_VSYNC__CSI1_VSYNC 356
-MX51_PAD_CSI1_VSYNC__GPIO3_14 357
-MX51_PAD_CSI1_HSYNC__CSI1_HSYNC 358
-MX51_PAD_CSI1_HSYNC__GPIO3_15 359
-MX51_PAD_CSI1_PIXCLK__CSI1_PIXCLK 360
-MX51_PAD_CSI1_MCLK__CSI1_MCLK 361
-MX51_PAD_CSI2_D12__CSI2_D12 362
-MX51_PAD_CSI2_D12__GPIO4_9 363
-MX51_PAD_CSI2_D13__CSI2_D13 364
-MX51_PAD_CSI2_D13__GPIO4_10 365
-MX51_PAD_CSI2_D14__CSI2_D14 366
-MX51_PAD_CSI2_D15__CSI2_D15 367
-MX51_PAD_CSI2_D16__CSI2_D16 368
-MX51_PAD_CSI2_D17__CSI2_D17 369
-MX51_PAD_CSI2_D18__CSI2_D18 370
-MX51_PAD_CSI2_D18__GPIO4_11 371
-MX51_PAD_CSI2_D19__CSI2_D19 372
-MX51_PAD_CSI2_D19__GPIO4_12 373
-MX51_PAD_CSI2_VSYNC__CSI2_VSYNC 374
-MX51_PAD_CSI2_VSYNC__GPIO4_13 375
-MX51_PAD_CSI2_HSYNC__CSI2_HSYNC 376
-MX51_PAD_CSI2_HSYNC__GPIO4_14 377
-MX51_PAD_CSI2_PIXCLK__CSI2_PIXCLK 378
-MX51_PAD_CSI2_PIXCLK__GPIO4_15 379
-MX51_PAD_I2C1_CLK__GPIO4_16 380
-MX51_PAD_I2C1_CLK__I2C1_CLK 381
-MX51_PAD_I2C1_DAT__GPIO4_17 382
-MX51_PAD_I2C1_DAT__I2C1_DAT 383
-MX51_PAD_AUD3_BB_TXD__AUD3_TXD 384
-MX51_PAD_AUD3_BB_TXD__GPIO4_18 385
-MX51_PAD_AUD3_BB_RXD__AUD3_RXD 386
-MX51_PAD_AUD3_BB_RXD__GPIO4_19 387
-MX51_PAD_AUD3_BB_RXD__UART3_RXD 388
-MX51_PAD_AUD3_BB_CK__AUD3_TXC 389
-MX51_PAD_AUD3_BB_CK__GPIO4_20 390
-MX51_PAD_AUD3_BB_FS__AUD3_TXFS 391
-MX51_PAD_AUD3_BB_FS__GPIO4_21 392
-MX51_PAD_AUD3_BB_FS__UART3_TXD 393
-MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI 394
-MX51_PAD_CSPI1_MOSI__GPIO4_22 395
-MX51_PAD_CSPI1_MOSI__I2C1_SDA 396
-MX51_PAD_CSPI1_MISO__AUD4_RXD 397
-MX51_PAD_CSPI1_MISO__ECSPI1_MISO 398
-MX51_PAD_CSPI1_MISO__GPIO4_23 399
-MX51_PAD_CSPI1_SS0__AUD4_TXC 400
-MX51_PAD_CSPI1_SS0__ECSPI1_SS0 401
-MX51_PAD_CSPI1_SS0__GPIO4_24 402
-MX51_PAD_CSPI1_SS1__AUD4_TXD 403
-MX51_PAD_CSPI1_SS1__ECSPI1_SS1 404
-MX51_PAD_CSPI1_SS1__GPIO4_25 405
-MX51_PAD_CSPI1_RDY__AUD4_TXFS 406
-MX51_PAD_CSPI1_RDY__ECSPI1_RDY 407
-MX51_PAD_CSPI1_RDY__GPIO4_26 408
-MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK 409
-MX51_PAD_CSPI1_SCLK__GPIO4_27 410
-MX51_PAD_CSPI1_SCLK__I2C1_SCL 411
-MX51_PAD_UART1_RXD__GPIO4_28 412
-MX51_PAD_UART1_RXD__UART1_RXD 413
-MX51_PAD_UART1_TXD__GPIO4_29 414
-MX51_PAD_UART1_TXD__PWM2_PWMO 415
-MX51_PAD_UART1_TXD__UART1_TXD 416
-MX51_PAD_UART1_RTS__GPIO4_30 417
-MX51_PAD_UART1_RTS__UART1_RTS 418
-MX51_PAD_UART1_CTS__GPIO4_31 419
-MX51_PAD_UART1_CTS__UART1_CTS 420
-MX51_PAD_UART2_RXD__FIRI_TXD 421
-MX51_PAD_UART2_RXD__GPIO1_20 422
-MX51_PAD_UART2_RXD__UART2_RXD 423
-MX51_PAD_UART2_TXD__FIRI_RXD 424
-MX51_PAD_UART2_TXD__GPIO1_21 425
-MX51_PAD_UART2_TXD__UART2_TXD 426
-MX51_PAD_UART3_RXD__CSI1_D0 427
-MX51_PAD_UART3_RXD__GPIO1_22 428
-MX51_PAD_UART3_RXD__UART1_DTR 429
-MX51_PAD_UART3_RXD__UART3_RXD 430
-MX51_PAD_UART3_TXD__CSI1_D1 431
-MX51_PAD_UART3_TXD__GPIO1_23 432
-MX51_PAD_UART3_TXD__UART1_DSR 433
-MX51_PAD_UART3_TXD__UART3_TXD 434
-MX51_PAD_OWIRE_LINE__GPIO1_24 435
-MX51_PAD_OWIRE_LINE__OWIRE_LINE 436
-MX51_PAD_OWIRE_LINE__SPDIF_OUT 437
-MX51_PAD_KEY_ROW0__KEY_ROW0 438
-MX51_PAD_KEY_ROW1__KEY_ROW1 439
-MX51_PAD_KEY_ROW2__KEY_ROW2 440
-MX51_PAD_KEY_ROW3__KEY_ROW3 441
-MX51_PAD_KEY_COL0__KEY_COL0 442
-MX51_PAD_KEY_COL0__PLL1_BYP 443
-MX51_PAD_KEY_COL1__KEY_COL1 444
-MX51_PAD_KEY_COL1__PLL2_BYP 445
-MX51_PAD_KEY_COL2__KEY_COL2 446
-MX51_PAD_KEY_COL2__PLL3_BYP 447
-MX51_PAD_KEY_COL3__KEY_COL3 448
-MX51_PAD_KEY_COL4__I2C2_SCL 449
-MX51_PAD_KEY_COL4__KEY_COL4 450
-MX51_PAD_KEY_COL4__SPDIF_OUT1 451
-MX51_PAD_KEY_COL4__UART1_RI 452
-MX51_PAD_KEY_COL4__UART3_RTS 453
-MX51_PAD_KEY_COL5__I2C2_SDA 454
-MX51_PAD_KEY_COL5__KEY_COL5 455
-MX51_PAD_KEY_COL5__UART1_DCD 456
-MX51_PAD_KEY_COL5__UART3_CTS 457
-MX51_PAD_USBH1_CLK__CSPI_SCLK 458
-MX51_PAD_USBH1_CLK__GPIO1_25 459
-MX51_PAD_USBH1_CLK__I2C2_SCL 460
-MX51_PAD_USBH1_CLK__USBH1_CLK 461
-MX51_PAD_USBH1_DIR__CSPI_MOSI 462
-MX51_PAD_USBH1_DIR__GPIO1_26 463
-MX51_PAD_USBH1_DIR__I2C2_SDA 464
-MX51_PAD_USBH1_DIR__USBH1_DIR 465
-MX51_PAD_USBH1_STP__CSPI_RDY 466
-MX51_PAD_USBH1_STP__GPIO1_27 467
-MX51_PAD_USBH1_STP__UART3_RXD 468
-MX51_PAD_USBH1_STP__USBH1_STP 469
-MX51_PAD_USBH1_NXT__CSPI_MISO 470
-MX51_PAD_USBH1_NXT__GPIO1_28 471
-MX51_PAD_USBH1_NXT__UART3_TXD 472
-MX51_PAD_USBH1_NXT__USBH1_NXT 473
-MX51_PAD_USBH1_DATA0__GPIO1_11 474
-MX51_PAD_USBH1_DATA0__UART2_CTS 475
-MX51_PAD_USBH1_DATA0__USBH1_DATA0 476
-MX51_PAD_USBH1_DATA1__GPIO1_12 477
-MX51_PAD_USBH1_DATA1__UART2_RXD 478
-MX51_PAD_USBH1_DATA1__USBH1_DATA1 479
-MX51_PAD_USBH1_DATA2__GPIO1_13 480
-MX51_PAD_USBH1_DATA2__UART2_TXD 481
-MX51_PAD_USBH1_DATA2__USBH1_DATA2 482
-MX51_PAD_USBH1_DATA3__GPIO1_14 483
-MX51_PAD_USBH1_DATA3__UART2_RTS 484
-MX51_PAD_USBH1_DATA3__USBH1_DATA3 485
-MX51_PAD_USBH1_DATA4__CSPI_SS0 486
-MX51_PAD_USBH1_DATA4__GPIO1_15 487
-MX51_PAD_USBH1_DATA4__USBH1_DATA4 488
-MX51_PAD_USBH1_DATA5__CSPI_SS1 489
-MX51_PAD_USBH1_DATA5__GPIO1_16 490
-MX51_PAD_USBH1_DATA5__USBH1_DATA5 491
-MX51_PAD_USBH1_DATA6__CSPI_SS3 492
-MX51_PAD_USBH1_DATA6__GPIO1_17 493
-MX51_PAD_USBH1_DATA6__USBH1_DATA6 494
-MX51_PAD_USBH1_DATA7__ECSPI1_SS3 495
-MX51_PAD_USBH1_DATA7__ECSPI2_SS3 496
-MX51_PAD_USBH1_DATA7__GPIO1_18 497
-MX51_PAD_USBH1_DATA7__USBH1_DATA7 498
-MX51_PAD_DI1_PIN11__DI1_PIN11 499
-MX51_PAD_DI1_PIN11__ECSPI1_SS2 500
-MX51_PAD_DI1_PIN11__GPIO3_0 501
-MX51_PAD_DI1_PIN12__DI1_PIN12 502
-MX51_PAD_DI1_PIN12__GPIO3_1 503
-MX51_PAD_DI1_PIN13__DI1_PIN13 504
-MX51_PAD_DI1_PIN13__GPIO3_2 505
-MX51_PAD_DI1_D0_CS__DI1_D0_CS 506
-MX51_PAD_DI1_D0_CS__GPIO3_3 507
-MX51_PAD_DI1_D1_CS__DI1_D1_CS 508
-MX51_PAD_DI1_D1_CS__DISP1_PIN14 509
-MX51_PAD_DI1_D1_CS__DISP1_PIN5 510
-MX51_PAD_DI1_D1_CS__GPIO3_4 511
-MX51_PAD_DISPB2_SER_DIN__DISP1_PIN1 512
-MX51_PAD_DISPB2_SER_DIN__DISPB2_SER_DIN 513
-MX51_PAD_DISPB2_SER_DIN__GPIO3_5 514
-MX51_PAD_DISPB2_SER_DIO__DISP1_PIN6 515
-MX51_PAD_DISPB2_SER_DIO__DISPB2_SER_DIO 516
-MX51_PAD_DISPB2_SER_DIO__GPIO3_6 517
-MX51_PAD_DISPB2_SER_CLK__DISP1_PIN17 518
-MX51_PAD_DISPB2_SER_CLK__DISP1_PIN7 519
-MX51_PAD_DISPB2_SER_CLK__DISPB2_SER_CLK 520
-MX51_PAD_DISPB2_SER_CLK__GPIO3_7 521
-MX51_PAD_DISPB2_SER_RS__DISP1_EXT_CLK 522
-MX51_PAD_DISPB2_SER_RS__DISP1_PIN16 523
-MX51_PAD_DISPB2_SER_RS__DISP1_PIN8 524
-MX51_PAD_DISPB2_SER_RS__DISPB2_SER_RS 525
-MX51_PAD_DISPB2_SER_RS__DISPB2_SER_RS 526
-MX51_PAD_DISPB2_SER_RS__GPIO3_8 527
-MX51_PAD_DISP1_DAT0__DISP1_DAT0 528
-MX51_PAD_DISP1_DAT1__DISP1_DAT1 529
-MX51_PAD_DISP1_DAT2__DISP1_DAT2 530
-MX51_PAD_DISP1_DAT3__DISP1_DAT3 531
-MX51_PAD_DISP1_DAT4__DISP1_DAT4 532
-MX51_PAD_DISP1_DAT5__DISP1_DAT5 533
-MX51_PAD_DISP1_DAT6__BOOT_USB_SRC 534
-MX51_PAD_DISP1_DAT6__DISP1_DAT6 535
-MX51_PAD_DISP1_DAT7__BOOT_EEPROM_CFG 536
-MX51_PAD_DISP1_DAT7__DISP1_DAT7 537
-MX51_PAD_DISP1_DAT8__BOOT_SRC0 538
-MX51_PAD_DISP1_DAT8__DISP1_DAT8 539
-MX51_PAD_DISP1_DAT9__BOOT_SRC1 540
-MX51_PAD_DISP1_DAT9__DISP1_DAT9 541
-MX51_PAD_DISP1_DAT10__BOOT_SPARE_SIZE 542
-MX51_PAD_DISP1_DAT10__DISP1_DAT10 543
-MX51_PAD_DISP1_DAT11__BOOT_LPB_FREQ2 544
-MX51_PAD_DISP1_DAT11__DISP1_DAT11 545
-MX51_PAD_DISP1_DAT12__BOOT_MLC_SEL 546
-MX51_PAD_DISP1_DAT12__DISP1_DAT12 547
-MX51_PAD_DISP1_DAT13__BOOT_MEM_CTL0 548
-MX51_PAD_DISP1_DAT13__DISP1_DAT13 549
-MX51_PAD_DISP1_DAT14__BOOT_MEM_CTL1 550
-MX51_PAD_DISP1_DAT14__DISP1_DAT14 551
-MX51_PAD_DISP1_DAT15__BOOT_BUS_WIDTH 552
-MX51_PAD_DISP1_DAT15__DISP1_DAT15 553
-MX51_PAD_DISP1_DAT16__BOOT_PAGE_SIZE0 554
-MX51_PAD_DISP1_DAT16__DISP1_DAT16 555
-MX51_PAD_DISP1_DAT17__BOOT_PAGE_SIZE1 556
-MX51_PAD_DISP1_DAT17__DISP1_DAT17 557
-MX51_PAD_DISP1_DAT18__BOOT_WEIM_MUXED0 558
-MX51_PAD_DISP1_DAT18__DISP1_DAT18 559
-MX51_PAD_DISP1_DAT18__DISP2_PIN11 560
-MX51_PAD_DISP1_DAT18__DISP2_PIN5 561
-MX51_PAD_DISP1_DAT19__BOOT_WEIM_MUXED1 562
-MX51_PAD_DISP1_DAT19__DISP1_DAT19 563
-MX51_PAD_DISP1_DAT19__DISP2_PIN12 564
-MX51_PAD_DISP1_DAT19__DISP2_PIN6 565
-MX51_PAD_DISP1_DAT20__BOOT_MEM_TYPE0 566
-MX51_PAD_DISP1_DAT20__DISP1_DAT20 567
-MX51_PAD_DISP1_DAT20__DISP2_PIN13 568
-MX51_PAD_DISP1_DAT20__DISP2_PIN7 569
-MX51_PAD_DISP1_DAT21__BOOT_MEM_TYPE1 570
-MX51_PAD_DISP1_DAT21__DISP1_DAT21 571
-MX51_PAD_DISP1_DAT21__DISP2_PIN14 572
-MX51_PAD_DISP1_DAT21__DISP2_PIN8 573
-MX51_PAD_DISP1_DAT22__BOOT_LPB_FREQ0 574
-MX51_PAD_DISP1_DAT22__DISP1_DAT22 575
-MX51_PAD_DISP1_DAT22__DISP2_D0_CS 576
-MX51_PAD_DISP1_DAT22__DISP2_DAT16 577
-MX51_PAD_DISP1_DAT23__BOOT_LPB_FREQ1 578
-MX51_PAD_DISP1_DAT23__DISP1_DAT23 579
-MX51_PAD_DISP1_DAT23__DISP2_D1_CS 580
-MX51_PAD_DISP1_DAT23__DISP2_DAT17 581
-MX51_PAD_DISP1_DAT23__DISP2_SER_CS 582
-MX51_PAD_DI1_PIN3__DI1_PIN3 583
-MX51_PAD_DI1_PIN2__DI1_PIN2 584
-MX51_PAD_DI_GP2__DISP1_SER_CLK 585
-MX51_PAD_DI_GP2__DISP2_WAIT 586
-MX51_PAD_DI_GP3__CSI1_DATA_EN 587
-MX51_PAD_DI_GP3__DISP1_SER_DIO 588
-MX51_PAD_DI_GP3__FEC_TX_ER 589
-MX51_PAD_DI2_PIN4__CSI2_DATA_EN 590
-MX51_PAD_DI2_PIN4__DI2_PIN4 591
-MX51_PAD_DI2_PIN4__FEC_CRS 592
-MX51_PAD_DI2_PIN2__DI2_PIN2 593
-MX51_PAD_DI2_PIN2__FEC_MDC 594
-MX51_PAD_DI2_PIN3__DI2_PIN3 595
-MX51_PAD_DI2_PIN3__FEC_MDIO 596
-MX51_PAD_DI2_DISP_CLK__DI2_DISP_CLK 597
-MX51_PAD_DI2_DISP_CLK__FEC_RDATA1 598
-MX51_PAD_DI_GP4__DI2_PIN15 599
-MX51_PAD_DI_GP4__DISP1_SER_DIN 600
-MX51_PAD_DI_GP4__DISP2_PIN1 601
-MX51_PAD_DI_GP4__FEC_RDATA2 602
-MX51_PAD_DISP2_DAT0__DISP2_DAT0 603
-MX51_PAD_DISP2_DAT0__FEC_RDATA3 604
-MX51_PAD_DISP2_DAT0__KEY_COL6 605
-MX51_PAD_DISP2_DAT0__UART3_RXD 606
-MX51_PAD_DISP2_DAT0__USBH3_CLK 607
-MX51_PAD_DISP2_DAT1__DISP2_DAT1 608
-MX51_PAD_DISP2_DAT1__FEC_RX_ER 609
-MX51_PAD_DISP2_DAT1__KEY_COL7 610
-MX51_PAD_DISP2_DAT1__UART3_TXD 611
-MX51_PAD_DISP2_DAT1__USBH3_DIR 612
-MX51_PAD_DISP2_DAT2__DISP2_DAT2 613
-MX51_PAD_DISP2_DAT3__DISP2_DAT3 614
-MX51_PAD_DISP2_DAT4__DISP2_DAT4 615
-MX51_PAD_DISP2_DAT5__DISP2_DAT5 616
-MX51_PAD_DISP2_DAT6__DISP2_DAT6 617
-MX51_PAD_DISP2_DAT6__FEC_TDATA1 618
-MX51_PAD_DISP2_DAT6__GPIO1_19 619
-MX51_PAD_DISP2_DAT6__KEY_ROW4 620
-MX51_PAD_DISP2_DAT6__USBH3_STP 621
-MX51_PAD_DISP2_DAT7__DISP2_DAT7 622
-MX51_PAD_DISP2_DAT7__FEC_TDATA2 623
-MX51_PAD_DISP2_DAT7__GPIO1_29 624
-MX51_PAD_DISP2_DAT7__KEY_ROW5 625
-MX51_PAD_DISP2_DAT7__USBH3_NXT 626
-MX51_PAD_DISP2_DAT8__DISP2_DAT8 627
-MX51_PAD_DISP2_DAT8__FEC_TDATA3 628
-MX51_PAD_DISP2_DAT8__GPIO1_30 629
-MX51_PAD_DISP2_DAT8__KEY_ROW6 630
-MX51_PAD_DISP2_DAT8__USBH3_DATA0 631
-MX51_PAD_DISP2_DAT9__AUD6_RXC 632
-MX51_PAD_DISP2_DAT9__DISP2_DAT9 633
-MX51_PAD_DISP2_DAT9__FEC_TX_EN 634
-MX51_PAD_DISP2_DAT9__GPIO1_31 635
-MX51_PAD_DISP2_DAT9__USBH3_DATA1 636
-MX51_PAD_DISP2_DAT10__DISP2_DAT10 637
-MX51_PAD_DISP2_DAT10__DISP2_SER_CS 638
-MX51_PAD_DISP2_DAT10__FEC_COL 639
-MX51_PAD_DISP2_DAT10__KEY_ROW7 640
-MX51_PAD_DISP2_DAT10__USBH3_DATA2 641
-MX51_PAD_DISP2_DAT11__AUD6_TXD 642
-MX51_PAD_DISP2_DAT11__DISP2_DAT11 643
-MX51_PAD_DISP2_DAT11__FEC_RX_CLK 644
-MX51_PAD_DISP2_DAT11__GPIO1_10 645
-MX51_PAD_DISP2_DAT11__USBH3_DATA3 646
-MX51_PAD_DISP2_DAT12__AUD6_RXD 647
-MX51_PAD_DISP2_DAT12__DISP2_DAT12 648
-MX51_PAD_DISP2_DAT12__FEC_RX_DV 649
-MX51_PAD_DISP2_DAT12__USBH3_DATA4 650
-MX51_PAD_DISP2_DAT13__AUD6_TXC 651
-MX51_PAD_DISP2_DAT13__DISP2_DAT13 652
-MX51_PAD_DISP2_DAT13__FEC_TX_CLK 653
-MX51_PAD_DISP2_DAT13__USBH3_DATA5 654
-MX51_PAD_DISP2_DAT14__AUD6_TXFS 655
-MX51_PAD_DISP2_DAT14__DISP2_DAT14 656
-MX51_PAD_DISP2_DAT14__FEC_RDATA0 657
-MX51_PAD_DISP2_DAT14__USBH3_DATA6 658
-MX51_PAD_DISP2_DAT15__AUD6_RXFS 659
-MX51_PAD_DISP2_DAT15__DISP1_SER_CS 660
-MX51_PAD_DISP2_DAT15__DISP2_DAT15 661
-MX51_PAD_DISP2_DAT15__FEC_TDATA0 662
-MX51_PAD_DISP2_DAT15__USBH3_DATA7 663
-MX51_PAD_SD1_CMD__AUD5_RXFS 664
-MX51_PAD_SD1_CMD__CSPI_MOSI 665
-MX51_PAD_SD1_CMD__SD1_CMD 666
-MX51_PAD_SD1_CLK__AUD5_RXC 667
-MX51_PAD_SD1_CLK__CSPI_SCLK 668
-MX51_PAD_SD1_CLK__SD1_CLK 669
-MX51_PAD_SD1_DATA0__AUD5_TXD 670
-MX51_PAD_SD1_DATA0__CSPI_MISO 671
-MX51_PAD_SD1_DATA0__SD1_DATA0 672
-MX51_PAD_EIM_DA0__EIM_DA0 673
-MX51_PAD_EIM_DA1__EIM_DA1 674
-MX51_PAD_EIM_DA2__EIM_DA2 675
-MX51_PAD_EIM_DA3__EIM_DA3 676
-MX51_PAD_SD1_DATA1__AUD5_RXD 677
-MX51_PAD_SD1_DATA1__SD1_DATA1 678
-MX51_PAD_EIM_DA4__EIM_DA4 679
-MX51_PAD_EIM_DA5__EIM_DA5 680
-MX51_PAD_EIM_DA6__EIM_DA6 681
-MX51_PAD_EIM_DA7__EIM_DA7 682
-MX51_PAD_SD1_DATA2__AUD5_TXC 683
-MX51_PAD_SD1_DATA2__SD1_DATA2 684
-MX51_PAD_EIM_DA10__EIM_DA10 685
-MX51_PAD_EIM_DA11__EIM_DA11 686
-MX51_PAD_EIM_DA8__EIM_DA8 687
-MX51_PAD_EIM_DA9__EIM_DA9 688
-MX51_PAD_SD1_DATA3__AUD5_TXFS 689
-MX51_PAD_SD1_DATA3__CSPI_SS1 690
-MX51_PAD_SD1_DATA3__SD1_DATA3 691
-MX51_PAD_GPIO1_0__CSPI_SS2 692
-MX51_PAD_GPIO1_0__GPIO1_0 693
-MX51_PAD_GPIO1_0__SD1_CD 694
-MX51_PAD_GPIO1_1__CSPI_MISO 695
-MX51_PAD_GPIO1_1__GPIO1_1 696
-MX51_PAD_GPIO1_1__SD1_WP 697
-MX51_PAD_EIM_DA12__EIM_DA12 698
-MX51_PAD_EIM_DA13__EIM_DA13 699
-MX51_PAD_EIM_DA14__EIM_DA14 700
-MX51_PAD_EIM_DA15__EIM_DA15 701
-MX51_PAD_SD2_CMD__CSPI_MOSI 702
-MX51_PAD_SD2_CMD__I2C1_SCL 703
-MX51_PAD_SD2_CMD__SD2_CMD 704
-MX51_PAD_SD2_CLK__CSPI_SCLK 705
-MX51_PAD_SD2_CLK__I2C1_SDA 706
-MX51_PAD_SD2_CLK__SD2_CLK 707
-MX51_PAD_SD2_DATA0__CSPI_MISO 708
-MX51_PAD_SD2_DATA0__SD1_DAT4 709
-MX51_PAD_SD2_DATA0__SD2_DATA0 710
-MX51_PAD_SD2_DATA1__SD1_DAT5 711
-MX51_PAD_SD2_DATA1__SD2_DATA1 712
-MX51_PAD_SD2_DATA1__USBH3_H2_DP 713
-MX51_PAD_SD2_DATA2__SD1_DAT6 714
-MX51_PAD_SD2_DATA2__SD2_DATA2 715
-MX51_PAD_SD2_DATA2__USBH3_H2_DM 716
-MX51_PAD_SD2_DATA3__CSPI_SS2 717
-MX51_PAD_SD2_DATA3__SD1_DAT7 718
-MX51_PAD_SD2_DATA3__SD2_DATA3 719
-MX51_PAD_GPIO1_2__CCM_OUT_2 720
-MX51_PAD_GPIO1_2__GPIO1_2 721
-MX51_PAD_GPIO1_2__I2C2_SCL 722
-MX51_PAD_GPIO1_2__PLL1_BYP 723
-MX51_PAD_GPIO1_2__PWM1_PWMO 724
-MX51_PAD_GPIO1_3__GPIO1_3 725
-MX51_PAD_GPIO1_3__I2C2_SDA 726
-MX51_PAD_GPIO1_3__PLL2_BYP 727
-MX51_PAD_GPIO1_3__PWM2_PWMO 728
-MX51_PAD_PMIC_INT_REQ__PMIC_INT_REQ 729
-MX51_PAD_PMIC_INT_REQ__PMIC_PMU_IRQ_B 730
-MX51_PAD_GPIO1_4__DISP2_EXT_CLK 731
-MX51_PAD_GPIO1_4__EIM_RDY 732
-MX51_PAD_GPIO1_4__GPIO1_4 733
-MX51_PAD_GPIO1_4__WDOG1_WDOG_B 734
-MX51_PAD_GPIO1_5__CSI2_MCLK 735
-MX51_PAD_GPIO1_5__DISP2_PIN16 736
-MX51_PAD_GPIO1_5__GPIO1_5 737
-MX51_PAD_GPIO1_5__WDOG2_WDOG_B 738
-MX51_PAD_GPIO1_6__DISP2_PIN17 739
-MX51_PAD_GPIO1_6__GPIO1_6 740
-MX51_PAD_GPIO1_6__REF_EN_B 741
-MX51_PAD_GPIO1_7__CCM_OUT_0 742
-MX51_PAD_GPIO1_7__GPIO1_7 743
-MX51_PAD_GPIO1_7__SD2_WP 744
-MX51_PAD_GPIO1_7__SPDIF_OUT1 745
-MX51_PAD_GPIO1_8__CSI2_DATA_EN 746
-MX51_PAD_GPIO1_8__GPIO1_8 747
-MX51_PAD_GPIO1_8__SD2_CD 748
-MX51_PAD_GPIO1_8__USBH3_PWR 749
-MX51_PAD_GPIO1_9__CCM_OUT_1 750
-MX51_PAD_GPIO1_9__DISP2_D1_CS 751
-MX51_PAD_GPIO1_9__DISP2_SER_CS 752
-MX51_PAD_GPIO1_9__GPIO1_9 753
-MX51_PAD_GPIO1_9__SD2_LCTL 754
-MX51_PAD_GPIO1_9__USBH3_OC 755
+Refer to imx51-pinfunc.h in device tree source folder for all available
+imx51 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
index ca85ca432ef0..25dcb77cfaf7 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt
@@ -28,1175 +28,5 @@ PAD_CTL_DSE_MAX (3 << 1)
PAD_CTL_SRE_FAST (1 << 0)
PAD_CTL_SRE_SLOW (0 << 0)
-See below for available PIN_FUNC_ID for imx53:
-MX53_PAD_GPIO_19__KPP_COL_5 0
-MX53_PAD_GPIO_19__GPIO4_5 1
-MX53_PAD_GPIO_19__CCM_CLKO 2
-MX53_PAD_GPIO_19__SPDIF_OUT1 3
-MX53_PAD_GPIO_19__RTC_CE_RTC_EXT_TRIG2 4
-MX53_PAD_GPIO_19__ECSPI1_RDY 5
-MX53_PAD_GPIO_19__FEC_TDATA_3 6
-MX53_PAD_GPIO_19__SRC_INT_BOOT 7
-MX53_PAD_KEY_COL0__KPP_COL_0 8
-MX53_PAD_KEY_COL0__GPIO4_6 9
-MX53_PAD_KEY_COL0__AUDMUX_AUD5_TXC 10
-MX53_PAD_KEY_COL0__UART4_TXD_MUX 11
-MX53_PAD_KEY_COL0__ECSPI1_SCLK 12
-MX53_PAD_KEY_COL0__FEC_RDATA_3 13
-MX53_PAD_KEY_COL0__SRC_ANY_PU_RST 14
-MX53_PAD_KEY_ROW0__KPP_ROW_0 15
-MX53_PAD_KEY_ROW0__GPIO4_7 16
-MX53_PAD_KEY_ROW0__AUDMUX_AUD5_TXD 17
-MX53_PAD_KEY_ROW0__UART4_RXD_MUX 18
-MX53_PAD_KEY_ROW0__ECSPI1_MOSI 19
-MX53_PAD_KEY_ROW0__FEC_TX_ER 20
-MX53_PAD_KEY_COL1__KPP_COL_1 21
-MX53_PAD_KEY_COL1__GPIO4_8 22
-MX53_PAD_KEY_COL1__AUDMUX_AUD5_TXFS 23
-MX53_PAD_KEY_COL1__UART5_TXD_MUX 24
-MX53_PAD_KEY_COL1__ECSPI1_MISO 25
-MX53_PAD_KEY_COL1__FEC_RX_CLK 26
-MX53_PAD_KEY_COL1__USBPHY1_TXREADY 27
-MX53_PAD_KEY_ROW1__KPP_ROW_1 28
-MX53_PAD_KEY_ROW1__GPIO4_9 29
-MX53_PAD_KEY_ROW1__AUDMUX_AUD5_RXD 30
-MX53_PAD_KEY_ROW1__UART5_RXD_MUX 31
-MX53_PAD_KEY_ROW1__ECSPI1_SS0 32
-MX53_PAD_KEY_ROW1__FEC_COL 33
-MX53_PAD_KEY_ROW1__USBPHY1_RXVALID 34
-MX53_PAD_KEY_COL2__KPP_COL_2 35
-MX53_PAD_KEY_COL2__GPIO4_10 36
-MX53_PAD_KEY_COL2__CAN1_TXCAN 37
-MX53_PAD_KEY_COL2__FEC_MDIO 38
-MX53_PAD_KEY_COL2__ECSPI1_SS1 39
-MX53_PAD_KEY_COL2__FEC_RDATA_2 40
-MX53_PAD_KEY_COL2__USBPHY1_RXACTIVE 41
-MX53_PAD_KEY_ROW2__KPP_ROW_2 42
-MX53_PAD_KEY_ROW2__GPIO4_11 43
-MX53_PAD_KEY_ROW2__CAN1_RXCAN 44
-MX53_PAD_KEY_ROW2__FEC_MDC 45
-MX53_PAD_KEY_ROW2__ECSPI1_SS2 46
-MX53_PAD_KEY_ROW2__FEC_TDATA_2 47
-MX53_PAD_KEY_ROW2__USBPHY1_RXERROR 48
-MX53_PAD_KEY_COL3__KPP_COL_3 49
-MX53_PAD_KEY_COL3__GPIO4_12 50
-MX53_PAD_KEY_COL3__USBOH3_H2_DP 51
-MX53_PAD_KEY_COL3__SPDIF_IN1 52
-MX53_PAD_KEY_COL3__I2C2_SCL 53
-MX53_PAD_KEY_COL3__ECSPI1_SS3 54
-MX53_PAD_KEY_COL3__FEC_CRS 55
-MX53_PAD_KEY_COL3__USBPHY1_SIECLOCK 56
-MX53_PAD_KEY_ROW3__KPP_ROW_3 57
-MX53_PAD_KEY_ROW3__GPIO4_13 58
-MX53_PAD_KEY_ROW3__USBOH3_H2_DM 59
-MX53_PAD_KEY_ROW3__CCM_ASRC_EXT_CLK 60
-MX53_PAD_KEY_ROW3__I2C2_SDA 61
-MX53_PAD_KEY_ROW3__OSC32K_32K_OUT 62
-MX53_PAD_KEY_ROW3__CCM_PLL4_BYP 63
-MX53_PAD_KEY_ROW3__USBPHY1_LINESTATE_0 64
-MX53_PAD_KEY_COL4__KPP_COL_4 65
-MX53_PAD_KEY_COL4__GPIO4_14 66
-MX53_PAD_KEY_COL4__CAN2_TXCAN 67
-MX53_PAD_KEY_COL4__IPU_SISG_4 68
-MX53_PAD_KEY_COL4__UART5_RTS 69
-MX53_PAD_KEY_COL4__USBOH3_USBOTG_OC 70
-MX53_PAD_KEY_COL4__USBPHY1_LINESTATE_1 71
-MX53_PAD_KEY_ROW4__KPP_ROW_4 72
-MX53_PAD_KEY_ROW4__GPIO4_15 73
-MX53_PAD_KEY_ROW4__CAN2_RXCAN 74
-MX53_PAD_KEY_ROW4__IPU_SISG_5 75
-MX53_PAD_KEY_ROW4__UART5_CTS 76
-MX53_PAD_KEY_ROW4__USBOH3_USBOTG_PWR 77
-MX53_PAD_KEY_ROW4__USBPHY1_VBUSVALID 78
-MX53_PAD_DI0_DISP_CLK__IPU_DI0_DISP_CLK 79
-MX53_PAD_DI0_DISP_CLK__GPIO4_16 80
-MX53_PAD_DI0_DISP_CLK__USBOH3_USBH2_DIR 81
-MX53_PAD_DI0_DISP_CLK__SDMA_DEBUG_CORE_STATE_0 82
-MX53_PAD_DI0_DISP_CLK__EMI_EMI_DEBUG_0 83
-MX53_PAD_DI0_DISP_CLK__USBPHY1_AVALID 84
-MX53_PAD_DI0_PIN15__IPU_DI0_PIN15 85
-MX53_PAD_DI0_PIN15__GPIO4_17 86
-MX53_PAD_DI0_PIN15__AUDMUX_AUD6_TXC 87
-MX53_PAD_DI0_PIN15__SDMA_DEBUG_CORE_STATE_1 88
-MX53_PAD_DI0_PIN15__EMI_EMI_DEBUG_1 89
-MX53_PAD_DI0_PIN15__USBPHY1_BVALID 90
-MX53_PAD_DI0_PIN2__IPU_DI0_PIN2 91
-MX53_PAD_DI0_PIN2__GPIO4_18 92
-MX53_PAD_DI0_PIN2__AUDMUX_AUD6_TXD 93
-MX53_PAD_DI0_PIN2__SDMA_DEBUG_CORE_STATE_2 94
-MX53_PAD_DI0_PIN2__EMI_EMI_DEBUG_2 95
-MX53_PAD_DI0_PIN2__USBPHY1_ENDSESSION 96
-MX53_PAD_DI0_PIN3__IPU_DI0_PIN3 97
-MX53_PAD_DI0_PIN3__GPIO4_19 98
-MX53_PAD_DI0_PIN3__AUDMUX_AUD6_TXFS 99
-MX53_PAD_DI0_PIN3__SDMA_DEBUG_CORE_STATE_3 100
-MX53_PAD_DI0_PIN3__EMI_EMI_DEBUG_3 101
-MX53_PAD_DI0_PIN3__USBPHY1_IDDIG 102
-MX53_PAD_DI0_PIN4__IPU_DI0_PIN4 103
-MX53_PAD_DI0_PIN4__GPIO4_20 104
-MX53_PAD_DI0_PIN4__AUDMUX_AUD6_RXD 105
-MX53_PAD_DI0_PIN4__ESDHC1_WP 106
-MX53_PAD_DI0_PIN4__SDMA_DEBUG_YIELD 107
-MX53_PAD_DI0_PIN4__EMI_EMI_DEBUG_4 108
-MX53_PAD_DI0_PIN4__USBPHY1_HOSTDISCONNECT 109
-MX53_PAD_DISP0_DAT0__IPU_DISP0_DAT_0 110
-MX53_PAD_DISP0_DAT0__GPIO4_21 111
-MX53_PAD_DISP0_DAT0__CSPI_SCLK 112
-MX53_PAD_DISP0_DAT0__USBOH3_USBH2_DATA_0 113
-MX53_PAD_DISP0_DAT0__SDMA_DEBUG_CORE_RUN 114
-MX53_PAD_DISP0_DAT0__EMI_EMI_DEBUG_5 115
-MX53_PAD_DISP0_DAT0__USBPHY2_TXREADY 116
-MX53_PAD_DISP0_DAT1__IPU_DISP0_DAT_1 117
-MX53_PAD_DISP0_DAT1__GPIO4_22 118
-MX53_PAD_DISP0_DAT1__CSPI_MOSI 119
-MX53_PAD_DISP0_DAT1__USBOH3_USBH2_DATA_1 120
-MX53_PAD_DISP0_DAT1__SDMA_DEBUG_EVENT_CHANNEL_SEL 121
-MX53_PAD_DISP0_DAT1__EMI_EMI_DEBUG_6 122
-MX53_PAD_DISP0_DAT1__USBPHY2_RXVALID 123
-MX53_PAD_DISP0_DAT2__IPU_DISP0_DAT_2 124
-MX53_PAD_DISP0_DAT2__GPIO4_23 125
-MX53_PAD_DISP0_DAT2__CSPI_MISO 126
-MX53_PAD_DISP0_DAT2__USBOH3_USBH2_DATA_2 127
-MX53_PAD_DISP0_DAT2__SDMA_DEBUG_MODE 128
-MX53_PAD_DISP0_DAT2__EMI_EMI_DEBUG_7 129
-MX53_PAD_DISP0_DAT2__USBPHY2_RXACTIVE 130
-MX53_PAD_DISP0_DAT3__IPU_DISP0_DAT_3 131
-MX53_PAD_DISP0_DAT3__GPIO4_24 132
-MX53_PAD_DISP0_DAT3__CSPI_SS0 133
-MX53_PAD_DISP0_DAT3__USBOH3_USBH2_DATA_3 134
-MX53_PAD_DISP0_DAT3__SDMA_DEBUG_BUS_ERROR 135
-MX53_PAD_DISP0_DAT3__EMI_EMI_DEBUG_8 136
-MX53_PAD_DISP0_DAT3__USBPHY2_RXERROR 137
-MX53_PAD_DISP0_DAT4__IPU_DISP0_DAT_4 138
-MX53_PAD_DISP0_DAT4__GPIO4_25 139
-MX53_PAD_DISP0_DAT4__CSPI_SS1 140
-MX53_PAD_DISP0_DAT4__USBOH3_USBH2_DATA_4 141
-MX53_PAD_DISP0_DAT4__SDMA_DEBUG_BUS_RWB 142
-MX53_PAD_DISP0_DAT4__EMI_EMI_DEBUG_9 143
-MX53_PAD_DISP0_DAT4__USBPHY2_SIECLOCK 144
-MX53_PAD_DISP0_DAT5__IPU_DISP0_DAT_5 145
-MX53_PAD_DISP0_DAT5__GPIO4_26 146
-MX53_PAD_DISP0_DAT5__CSPI_SS2 147
-MX53_PAD_DISP0_DAT5__USBOH3_USBH2_DATA_5 148
-MX53_PAD_DISP0_DAT5__SDMA_DEBUG_MATCHED_DMBUS 149
-MX53_PAD_DISP0_DAT5__EMI_EMI_DEBUG_10 150
-MX53_PAD_DISP0_DAT5__USBPHY2_LINESTATE_0 151
-MX53_PAD_DISP0_DAT6__IPU_DISP0_DAT_6 152
-MX53_PAD_DISP0_DAT6__GPIO4_27 153
-MX53_PAD_DISP0_DAT6__CSPI_SS3 154
-MX53_PAD_DISP0_DAT6__USBOH3_USBH2_DATA_6 155
-MX53_PAD_DISP0_DAT6__SDMA_DEBUG_RTBUFFER_WRITE 156
-MX53_PAD_DISP0_DAT6__EMI_EMI_DEBUG_11 157
-MX53_PAD_DISP0_DAT6__USBPHY2_LINESTATE_1 158
-MX53_PAD_DISP0_DAT7__IPU_DISP0_DAT_7 159
-MX53_PAD_DISP0_DAT7__GPIO4_28 160
-MX53_PAD_DISP0_DAT7__CSPI_RDY 161
-MX53_PAD_DISP0_DAT7__USBOH3_USBH2_DATA_7 162
-MX53_PAD_DISP0_DAT7__SDMA_DEBUG_EVENT_CHANNEL_0 163
-MX53_PAD_DISP0_DAT7__EMI_EMI_DEBUG_12 164
-MX53_PAD_DISP0_DAT7__USBPHY2_VBUSVALID 165
-MX53_PAD_DISP0_DAT8__IPU_DISP0_DAT_8 166
-MX53_PAD_DISP0_DAT8__GPIO4_29 167
-MX53_PAD_DISP0_DAT8__PWM1_PWMO 168
-MX53_PAD_DISP0_DAT8__WDOG1_WDOG_B 169
-MX53_PAD_DISP0_DAT8__SDMA_DEBUG_EVENT_CHANNEL_1 170
-MX53_PAD_DISP0_DAT8__EMI_EMI_DEBUG_13 171
-MX53_PAD_DISP0_DAT8__USBPHY2_AVALID 172
-MX53_PAD_DISP0_DAT9__IPU_DISP0_DAT_9 173
-MX53_PAD_DISP0_DAT9__GPIO4_30 174
-MX53_PAD_DISP0_DAT9__PWM2_PWMO 175
-MX53_PAD_DISP0_DAT9__WDOG2_WDOG_B 176
-MX53_PAD_DISP0_DAT9__SDMA_DEBUG_EVENT_CHANNEL_2 177
-MX53_PAD_DISP0_DAT9__EMI_EMI_DEBUG_14 178
-MX53_PAD_DISP0_DAT9__USBPHY2_VSTATUS_0 179
-MX53_PAD_DISP0_DAT10__IPU_DISP0_DAT_10 180
-MX53_PAD_DISP0_DAT10__GPIO4_31 181
-MX53_PAD_DISP0_DAT10__USBOH3_USBH2_STP 182
-MX53_PAD_DISP0_DAT10__SDMA_DEBUG_EVENT_CHANNEL_3 183
-MX53_PAD_DISP0_DAT10__EMI_EMI_DEBUG_15 184
-MX53_PAD_DISP0_DAT10__USBPHY2_VSTATUS_1 185
-MX53_PAD_DISP0_DAT11__IPU_DISP0_DAT_11 186
-MX53_PAD_DISP0_DAT11__GPIO5_5 187
-MX53_PAD_DISP0_DAT11__USBOH3_USBH2_NXT 188
-MX53_PAD_DISP0_DAT11__SDMA_DEBUG_EVENT_CHANNEL_4 189
-MX53_PAD_DISP0_DAT11__EMI_EMI_DEBUG_16 190
-MX53_PAD_DISP0_DAT11__USBPHY2_VSTATUS_2 191
-MX53_PAD_DISP0_DAT12__IPU_DISP0_DAT_12 192
-MX53_PAD_DISP0_DAT12__GPIO5_6 193
-MX53_PAD_DISP0_DAT12__USBOH3_USBH2_CLK 194
-MX53_PAD_DISP0_DAT12__SDMA_DEBUG_EVENT_CHANNEL_5 195
-MX53_PAD_DISP0_DAT12__EMI_EMI_DEBUG_17 196
-MX53_PAD_DISP0_DAT12__USBPHY2_VSTATUS_3 197
-MX53_PAD_DISP0_DAT13__IPU_DISP0_DAT_13 198
-MX53_PAD_DISP0_DAT13__GPIO5_7 199
-MX53_PAD_DISP0_DAT13__AUDMUX_AUD5_RXFS 200
-MX53_PAD_DISP0_DAT13__SDMA_DEBUG_EVT_CHN_LINES_0 201
-MX53_PAD_DISP0_DAT13__EMI_EMI_DEBUG_18 202
-MX53_PAD_DISP0_DAT13__USBPHY2_VSTATUS_4 203
-MX53_PAD_DISP0_DAT14__IPU_DISP0_DAT_14 204
-MX53_PAD_DISP0_DAT14__GPIO5_8 205
-MX53_PAD_DISP0_DAT14__AUDMUX_AUD5_RXC 206
-MX53_PAD_DISP0_DAT14__SDMA_DEBUG_EVT_CHN_LINES_1 207
-MX53_PAD_DISP0_DAT14__EMI_EMI_DEBUG_19 208
-MX53_PAD_DISP0_DAT14__USBPHY2_VSTATUS_5 209
-MX53_PAD_DISP0_DAT15__IPU_DISP0_DAT_15 210
-MX53_PAD_DISP0_DAT15__GPIO5_9 211
-MX53_PAD_DISP0_DAT15__ECSPI1_SS1 212
-MX53_PAD_DISP0_DAT15__ECSPI2_SS1 213
-MX53_PAD_DISP0_DAT15__SDMA_DEBUG_EVT_CHN_LINES_2 214
-MX53_PAD_DISP0_DAT15__EMI_EMI_DEBUG_20 215
-MX53_PAD_DISP0_DAT15__USBPHY2_VSTATUS_6 216
-MX53_PAD_DISP0_DAT16__IPU_DISP0_DAT_16 217
-MX53_PAD_DISP0_DAT16__GPIO5_10 218
-MX53_PAD_DISP0_DAT16__ECSPI2_MOSI 219
-MX53_PAD_DISP0_DAT16__AUDMUX_AUD5_TXC 220
-MX53_PAD_DISP0_DAT16__SDMA_EXT_EVENT_0 221
-MX53_PAD_DISP0_DAT16__SDMA_DEBUG_EVT_CHN_LINES_3 222
-MX53_PAD_DISP0_DAT16__EMI_EMI_DEBUG_21 223
-MX53_PAD_DISP0_DAT16__USBPHY2_VSTATUS_7 224
-MX53_PAD_DISP0_DAT17__IPU_DISP0_DAT_17 225
-MX53_PAD_DISP0_DAT17__GPIO5_11 226
-MX53_PAD_DISP0_DAT17__ECSPI2_MISO 227
-MX53_PAD_DISP0_DAT17__AUDMUX_AUD5_TXD 228
-MX53_PAD_DISP0_DAT17__SDMA_EXT_EVENT_1 229
-MX53_PAD_DISP0_DAT17__SDMA_DEBUG_EVT_CHN_LINES_4 230
-MX53_PAD_DISP0_DAT17__EMI_EMI_DEBUG_22 231
-MX53_PAD_DISP0_DAT18__IPU_DISP0_DAT_18 232
-MX53_PAD_DISP0_DAT18__GPIO5_12 233
-MX53_PAD_DISP0_DAT18__ECSPI2_SS0 234
-MX53_PAD_DISP0_DAT18__AUDMUX_AUD5_TXFS 235
-MX53_PAD_DISP0_DAT18__AUDMUX_AUD4_RXFS 236
-MX53_PAD_DISP0_DAT18__SDMA_DEBUG_EVT_CHN_LINES_5 237
-MX53_PAD_DISP0_DAT18__EMI_EMI_DEBUG_23 238
-MX53_PAD_DISP0_DAT18__EMI_WEIM_CS_2 239
-MX53_PAD_DISP0_DAT19__IPU_DISP0_DAT_19 240
-MX53_PAD_DISP0_DAT19__GPIO5_13 241
-MX53_PAD_DISP0_DAT19__ECSPI2_SCLK 242
-MX53_PAD_DISP0_DAT19__AUDMUX_AUD5_RXD 243
-MX53_PAD_DISP0_DAT19__AUDMUX_AUD4_RXC 244
-MX53_PAD_DISP0_DAT19__SDMA_DEBUG_EVT_CHN_LINES_6 245
-MX53_PAD_DISP0_DAT19__EMI_EMI_DEBUG_24 246
-MX53_PAD_DISP0_DAT19__EMI_WEIM_CS_3 247
-MX53_PAD_DISP0_DAT20__IPU_DISP0_DAT_20 248
-MX53_PAD_DISP0_DAT20__GPIO5_14 249
-MX53_PAD_DISP0_DAT20__ECSPI1_SCLK 250
-MX53_PAD_DISP0_DAT20__AUDMUX_AUD4_TXC 251
-MX53_PAD_DISP0_DAT20__SDMA_DEBUG_EVT_CHN_LINES_7 252
-MX53_PAD_DISP0_DAT20__EMI_EMI_DEBUG_25 253
-MX53_PAD_DISP0_DAT20__SATA_PHY_TDI 254
-MX53_PAD_DISP0_DAT21__IPU_DISP0_DAT_21 255
-MX53_PAD_DISP0_DAT21__GPIO5_15 256
-MX53_PAD_DISP0_DAT21__ECSPI1_MOSI 257
-MX53_PAD_DISP0_DAT21__AUDMUX_AUD4_TXD 258
-MX53_PAD_DISP0_DAT21__SDMA_DEBUG_BUS_DEVICE_0 259
-MX53_PAD_DISP0_DAT21__EMI_EMI_DEBUG_26 260
-MX53_PAD_DISP0_DAT21__SATA_PHY_TDO 261
-MX53_PAD_DISP0_DAT22__IPU_DISP0_DAT_22 262
-MX53_PAD_DISP0_DAT22__GPIO5_16 263
-MX53_PAD_DISP0_DAT22__ECSPI1_MISO 264
-MX53_PAD_DISP0_DAT22__AUDMUX_AUD4_TXFS 265
-MX53_PAD_DISP0_DAT22__SDMA_DEBUG_BUS_DEVICE_1 266
-MX53_PAD_DISP0_DAT22__EMI_EMI_DEBUG_27 267
-MX53_PAD_DISP0_DAT22__SATA_PHY_TCK 268
-MX53_PAD_DISP0_DAT23__IPU_DISP0_DAT_23 269
-MX53_PAD_DISP0_DAT23__GPIO5_17 270
-MX53_PAD_DISP0_DAT23__ECSPI1_SS0 271
-MX53_PAD_DISP0_DAT23__AUDMUX_AUD4_RXD 272
-MX53_PAD_DISP0_DAT23__SDMA_DEBUG_BUS_DEVICE_2 273
-MX53_PAD_DISP0_DAT23__EMI_EMI_DEBUG_28 274
-MX53_PAD_DISP0_DAT23__SATA_PHY_TMS 275
-MX53_PAD_CSI0_PIXCLK__IPU_CSI0_PIXCLK 276
-MX53_PAD_CSI0_PIXCLK__GPIO5_18 277
-MX53_PAD_CSI0_PIXCLK__SDMA_DEBUG_PC_0 278
-MX53_PAD_CSI0_PIXCLK__EMI_EMI_DEBUG_29 279
-MX53_PAD_CSI0_MCLK__IPU_CSI0_HSYNC 280
-MX53_PAD_CSI0_MCLK__GPIO5_19 281
-MX53_PAD_CSI0_MCLK__CCM_CSI0_MCLK 282
-MX53_PAD_CSI0_MCLK__SDMA_DEBUG_PC_1 283
-MX53_PAD_CSI0_MCLK__EMI_EMI_DEBUG_30 284
-MX53_PAD_CSI0_MCLK__TPIU_TRCTL 285
-MX53_PAD_CSI0_DATA_EN__IPU_CSI0_DATA_EN 286
-MX53_PAD_CSI0_DATA_EN__GPIO5_20 287
-MX53_PAD_CSI0_DATA_EN__SDMA_DEBUG_PC_2 288
-MX53_PAD_CSI0_DATA_EN__EMI_EMI_DEBUG_31 289
-MX53_PAD_CSI0_DATA_EN__TPIU_TRCLK 290
-MX53_PAD_CSI0_VSYNC__IPU_CSI0_VSYNC 291
-MX53_PAD_CSI0_VSYNC__GPIO5_21 292
-MX53_PAD_CSI0_VSYNC__SDMA_DEBUG_PC_3 293
-MX53_PAD_CSI0_VSYNC__EMI_EMI_DEBUG_32 294
-MX53_PAD_CSI0_VSYNC__TPIU_TRACE_0 295
-MX53_PAD_CSI0_DAT4__IPU_CSI0_D_4 296
-MX53_PAD_CSI0_DAT4__GPIO5_22 297
-MX53_PAD_CSI0_DAT4__KPP_COL_5 298
-MX53_PAD_CSI0_DAT4__ECSPI1_SCLK 299
-MX53_PAD_CSI0_DAT4__USBOH3_USBH3_STP 300
-MX53_PAD_CSI0_DAT4__AUDMUX_AUD3_TXC 301
-MX53_PAD_CSI0_DAT4__EMI_EMI_DEBUG_33 302
-MX53_PAD_CSI0_DAT4__TPIU_TRACE_1 303
-MX53_PAD_CSI0_DAT5__IPU_CSI0_D_5 304
-MX53_PAD_CSI0_DAT5__GPIO5_23 305
-MX53_PAD_CSI0_DAT5__KPP_ROW_5 306
-MX53_PAD_CSI0_DAT5__ECSPI1_MOSI 307
-MX53_PAD_CSI0_DAT5__USBOH3_USBH3_NXT 308
-MX53_PAD_CSI0_DAT5__AUDMUX_AUD3_TXD 309
-MX53_PAD_CSI0_DAT5__EMI_EMI_DEBUG_34 310
-MX53_PAD_CSI0_DAT5__TPIU_TRACE_2 311
-MX53_PAD_CSI0_DAT6__IPU_CSI0_D_6 312
-MX53_PAD_CSI0_DAT6__GPIO5_24 313
-MX53_PAD_CSI0_DAT6__KPP_COL_6 314
-MX53_PAD_CSI0_DAT6__ECSPI1_MISO 315
-MX53_PAD_CSI0_DAT6__USBOH3_USBH3_CLK 316
-MX53_PAD_CSI0_DAT6__AUDMUX_AUD3_TXFS 317
-MX53_PAD_CSI0_DAT6__EMI_EMI_DEBUG_35 318
-MX53_PAD_CSI0_DAT6__TPIU_TRACE_3 319
-MX53_PAD_CSI0_DAT7__IPU_CSI0_D_7 320
-MX53_PAD_CSI0_DAT7__GPIO5_25 321
-MX53_PAD_CSI0_DAT7__KPP_ROW_6 322
-MX53_PAD_CSI0_DAT7__ECSPI1_SS0 323
-MX53_PAD_CSI0_DAT7__USBOH3_USBH3_DIR 324
-MX53_PAD_CSI0_DAT7__AUDMUX_AUD3_RXD 325
-MX53_PAD_CSI0_DAT7__EMI_EMI_DEBUG_36 326
-MX53_PAD_CSI0_DAT7__TPIU_TRACE_4 327
-MX53_PAD_CSI0_DAT8__IPU_CSI0_D_8 328
-MX53_PAD_CSI0_DAT8__GPIO5_26 329
-MX53_PAD_CSI0_DAT8__KPP_COL_7 330
-MX53_PAD_CSI0_DAT8__ECSPI2_SCLK 331
-MX53_PAD_CSI0_DAT8__USBOH3_USBH3_OC 332
-MX53_PAD_CSI0_DAT8__I2C1_SDA 333
-MX53_PAD_CSI0_DAT8__EMI_EMI_DEBUG_37 334
-MX53_PAD_CSI0_DAT8__TPIU_TRACE_5 335
-MX53_PAD_CSI0_DAT9__IPU_CSI0_D_9 336
-MX53_PAD_CSI0_DAT9__GPIO5_27 337
-MX53_PAD_CSI0_DAT9__KPP_ROW_7 338
-MX53_PAD_CSI0_DAT9__ECSPI2_MOSI 339
-MX53_PAD_CSI0_DAT9__USBOH3_USBH3_PWR 340
-MX53_PAD_CSI0_DAT9__I2C1_SCL 341
-MX53_PAD_CSI0_DAT9__EMI_EMI_DEBUG_38 342
-MX53_PAD_CSI0_DAT9__TPIU_TRACE_6 343
-MX53_PAD_CSI0_DAT10__IPU_CSI0_D_10 344
-MX53_PAD_CSI0_DAT10__GPIO5_28 345
-MX53_PAD_CSI0_DAT10__UART1_TXD_MUX 346
-MX53_PAD_CSI0_DAT10__ECSPI2_MISO 347
-MX53_PAD_CSI0_DAT10__AUDMUX_AUD3_RXC 348
-MX53_PAD_CSI0_DAT10__SDMA_DEBUG_PC_4 349
-MX53_PAD_CSI0_DAT10__EMI_EMI_DEBUG_39 350
-MX53_PAD_CSI0_DAT10__TPIU_TRACE_7 351
-MX53_PAD_CSI0_DAT11__IPU_CSI0_D_11 352
-MX53_PAD_CSI0_DAT11__GPIO5_29 353
-MX53_PAD_CSI0_DAT11__UART1_RXD_MUX 354
-MX53_PAD_CSI0_DAT11__ECSPI2_SS0 355
-MX53_PAD_CSI0_DAT11__AUDMUX_AUD3_RXFS 356
-MX53_PAD_CSI0_DAT11__SDMA_DEBUG_PC_5 357
-MX53_PAD_CSI0_DAT11__EMI_EMI_DEBUG_40 358
-MX53_PAD_CSI0_DAT11__TPIU_TRACE_8 359
-MX53_PAD_CSI0_DAT12__IPU_CSI0_D_12 360
-MX53_PAD_CSI0_DAT12__GPIO5_30 361
-MX53_PAD_CSI0_DAT12__UART4_TXD_MUX 362
-MX53_PAD_CSI0_DAT12__USBOH3_USBH3_DATA_0 363
-MX53_PAD_CSI0_DAT12__SDMA_DEBUG_PC_6 364
-MX53_PAD_CSI0_DAT12__EMI_EMI_DEBUG_41 365
-MX53_PAD_CSI0_DAT12__TPIU_TRACE_9 366
-MX53_PAD_CSI0_DAT13__IPU_CSI0_D_13 367
-MX53_PAD_CSI0_DAT13__GPIO5_31 368
-MX53_PAD_CSI0_DAT13__UART4_RXD_MUX 369
-MX53_PAD_CSI0_DAT13__USBOH3_USBH3_DATA_1 370
-MX53_PAD_CSI0_DAT13__SDMA_DEBUG_PC_7 371
-MX53_PAD_CSI0_DAT13__EMI_EMI_DEBUG_42 372
-MX53_PAD_CSI0_DAT13__TPIU_TRACE_10 373
-MX53_PAD_CSI0_DAT14__IPU_CSI0_D_14 374
-MX53_PAD_CSI0_DAT14__GPIO6_0 375
-MX53_PAD_CSI0_DAT14__UART5_TXD_MUX 376
-MX53_PAD_CSI0_DAT14__USBOH3_USBH3_DATA_2 377
-MX53_PAD_CSI0_DAT14__SDMA_DEBUG_PC_8 378
-MX53_PAD_CSI0_DAT14__EMI_EMI_DEBUG_43 379
-MX53_PAD_CSI0_DAT14__TPIU_TRACE_11 380
-MX53_PAD_CSI0_DAT15__IPU_CSI0_D_15 381
-MX53_PAD_CSI0_DAT15__GPIO6_1 382
-MX53_PAD_CSI0_DAT15__UART5_RXD_MUX 383
-MX53_PAD_CSI0_DAT15__USBOH3_USBH3_DATA_3 384
-MX53_PAD_CSI0_DAT15__SDMA_DEBUG_PC_9 385
-MX53_PAD_CSI0_DAT15__EMI_EMI_DEBUG_44 386
-MX53_PAD_CSI0_DAT15__TPIU_TRACE_12 387
-MX53_PAD_CSI0_DAT16__IPU_CSI0_D_16 388
-MX53_PAD_CSI0_DAT16__GPIO6_2 389
-MX53_PAD_CSI0_DAT16__UART4_RTS 390
-MX53_PAD_CSI0_DAT16__USBOH3_USBH3_DATA_4 391
-MX53_PAD_CSI0_DAT16__SDMA_DEBUG_PC_10 392
-MX53_PAD_CSI0_DAT16__EMI_EMI_DEBUG_45 393
-MX53_PAD_CSI0_DAT16__TPIU_TRACE_13 394
-MX53_PAD_CSI0_DAT17__IPU_CSI0_D_17 395
-MX53_PAD_CSI0_DAT17__GPIO6_3 396
-MX53_PAD_CSI0_DAT17__UART4_CTS 397
-MX53_PAD_CSI0_DAT17__USBOH3_USBH3_DATA_5 398
-MX53_PAD_CSI0_DAT17__SDMA_DEBUG_PC_11 399
-MX53_PAD_CSI0_DAT17__EMI_EMI_DEBUG_46 400
-MX53_PAD_CSI0_DAT17__TPIU_TRACE_14 401
-MX53_PAD_CSI0_DAT18__IPU_CSI0_D_18 402
-MX53_PAD_CSI0_DAT18__GPIO6_4 403
-MX53_PAD_CSI0_DAT18__UART5_RTS 404
-MX53_PAD_CSI0_DAT18__USBOH3_USBH3_DATA_6 405
-MX53_PAD_CSI0_DAT18__SDMA_DEBUG_PC_12 406
-MX53_PAD_CSI0_DAT18__EMI_EMI_DEBUG_47 407
-MX53_PAD_CSI0_DAT18__TPIU_TRACE_15 408
-MX53_PAD_CSI0_DAT19__IPU_CSI0_D_19 409
-MX53_PAD_CSI0_DAT19__GPIO6_5 410
-MX53_PAD_CSI0_DAT19__UART5_CTS 411
-MX53_PAD_CSI0_DAT19__USBOH3_USBH3_DATA_7 412
-MX53_PAD_CSI0_DAT19__SDMA_DEBUG_PC_13 413
-MX53_PAD_CSI0_DAT19__EMI_EMI_DEBUG_48 414
-MX53_PAD_CSI0_DAT19__USBPHY2_BISTOK 415
-MX53_PAD_EIM_A25__EMI_WEIM_A_25 416
-MX53_PAD_EIM_A25__GPIO5_2 417
-MX53_PAD_EIM_A25__ECSPI2_RDY 418
-MX53_PAD_EIM_A25__IPU_DI1_PIN12 419
-MX53_PAD_EIM_A25__CSPI_SS1 420
-MX53_PAD_EIM_A25__IPU_DI0_D1_CS 421
-MX53_PAD_EIM_A25__USBPHY1_BISTOK 422
-MX53_PAD_EIM_EB2__EMI_WEIM_EB_2 423
-MX53_PAD_EIM_EB2__GPIO2_30 424
-MX53_PAD_EIM_EB2__CCM_DI1_EXT_CLK 425
-MX53_PAD_EIM_EB2__IPU_SER_DISP1_CS 426
-MX53_PAD_EIM_EB2__ECSPI1_SS0 427
-MX53_PAD_EIM_EB2__I2C2_SCL 428
-MX53_PAD_EIM_D16__EMI_WEIM_D_16 429
-MX53_PAD_EIM_D16__GPIO3_16 430
-MX53_PAD_EIM_D16__IPU_DI0_PIN5 431
-MX53_PAD_EIM_D16__IPU_DISPB1_SER_CLK 432
-MX53_PAD_EIM_D16__ECSPI1_SCLK 433
-MX53_PAD_EIM_D16__I2C2_SDA 434
-MX53_PAD_EIM_D17__EMI_WEIM_D_17 435
-MX53_PAD_EIM_D17__GPIO3_17 436
-MX53_PAD_EIM_D17__IPU_DI0_PIN6 437
-MX53_PAD_EIM_D17__IPU_DISPB1_SER_DIN 438
-MX53_PAD_EIM_D17__ECSPI1_MISO 439
-MX53_PAD_EIM_D17__I2C3_SCL 440
-MX53_PAD_EIM_D18__EMI_WEIM_D_18 441
-MX53_PAD_EIM_D18__GPIO3_18 442
-MX53_PAD_EIM_D18__IPU_DI0_PIN7 443
-MX53_PAD_EIM_D18__IPU_DISPB1_SER_DIO 444
-MX53_PAD_EIM_D18__ECSPI1_MOSI 445
-MX53_PAD_EIM_D18__I2C3_SDA 446
-MX53_PAD_EIM_D18__IPU_DI1_D0_CS 447
-MX53_PAD_EIM_D19__EMI_WEIM_D_19 448
-MX53_PAD_EIM_D19__GPIO3_19 449
-MX53_PAD_EIM_D19__IPU_DI0_PIN8 450
-MX53_PAD_EIM_D19__IPU_DISPB1_SER_RS 451
-MX53_PAD_EIM_D19__ECSPI1_SS1 452
-MX53_PAD_EIM_D19__EPIT1_EPITO 453
-MX53_PAD_EIM_D19__UART1_CTS 454
-MX53_PAD_EIM_D19__USBOH3_USBH2_OC 455
-MX53_PAD_EIM_D20__EMI_WEIM_D_20 456
-MX53_PAD_EIM_D20__GPIO3_20 457
-MX53_PAD_EIM_D20__IPU_DI0_PIN16 458
-MX53_PAD_EIM_D20__IPU_SER_DISP0_CS 459
-MX53_PAD_EIM_D20__CSPI_SS0 460
-MX53_PAD_EIM_D20__EPIT2_EPITO 461
-MX53_PAD_EIM_D20__UART1_RTS 462
-MX53_PAD_EIM_D20__USBOH3_USBH2_PWR 463
-MX53_PAD_EIM_D21__EMI_WEIM_D_21 464
-MX53_PAD_EIM_D21__GPIO3_21 465
-MX53_PAD_EIM_D21__IPU_DI0_PIN17 466
-MX53_PAD_EIM_D21__IPU_DISPB0_SER_CLK 467
-MX53_PAD_EIM_D21__CSPI_SCLK 468
-MX53_PAD_EIM_D21__I2C1_SCL 469
-MX53_PAD_EIM_D21__USBOH3_USBOTG_OC 470
-MX53_PAD_EIM_D22__EMI_WEIM_D_22 471
-MX53_PAD_EIM_D22__GPIO3_22 472
-MX53_PAD_EIM_D22__IPU_DI0_PIN1 473
-MX53_PAD_EIM_D22__IPU_DISPB0_SER_DIN 474
-MX53_PAD_EIM_D22__CSPI_MISO 475
-MX53_PAD_EIM_D22__USBOH3_USBOTG_PWR 476
-MX53_PAD_EIM_D23__EMI_WEIM_D_23 477
-MX53_PAD_EIM_D23__GPIO3_23 478
-MX53_PAD_EIM_D23__UART3_CTS 479
-MX53_PAD_EIM_D23__UART1_DCD 480
-MX53_PAD_EIM_D23__IPU_DI0_D0_CS 481
-MX53_PAD_EIM_D23__IPU_DI1_PIN2 482
-MX53_PAD_EIM_D23__IPU_CSI1_DATA_EN 483
-MX53_PAD_EIM_D23__IPU_DI1_PIN14 484
-MX53_PAD_EIM_EB3__EMI_WEIM_EB_3 485
-MX53_PAD_EIM_EB3__GPIO2_31 486
-MX53_PAD_EIM_EB3__UART3_RTS 487
-MX53_PAD_EIM_EB3__UART1_RI 488
-MX53_PAD_EIM_EB3__IPU_DI1_PIN3 489
-MX53_PAD_EIM_EB3__IPU_CSI1_HSYNC 490
-MX53_PAD_EIM_EB3__IPU_DI1_PIN16 491
-MX53_PAD_EIM_D24__EMI_WEIM_D_24 492
-MX53_PAD_EIM_D24__GPIO3_24 493
-MX53_PAD_EIM_D24__UART3_TXD_MUX 494
-MX53_PAD_EIM_D24__ECSPI1_SS2 495
-MX53_PAD_EIM_D24__CSPI_SS2 496
-MX53_PAD_EIM_D24__AUDMUX_AUD5_RXFS 497
-MX53_PAD_EIM_D24__ECSPI2_SS2 498
-MX53_PAD_EIM_D24__UART1_DTR 499
-MX53_PAD_EIM_D25__EMI_WEIM_D_25 500
-MX53_PAD_EIM_D25__GPIO3_25 501
-MX53_PAD_EIM_D25__UART3_RXD_MUX 502
-MX53_PAD_EIM_D25__ECSPI1_SS3 503
-MX53_PAD_EIM_D25__CSPI_SS3 504
-MX53_PAD_EIM_D25__AUDMUX_AUD5_RXC 505
-MX53_PAD_EIM_D25__ECSPI2_SS3 506
-MX53_PAD_EIM_D25__UART1_DSR 507
-MX53_PAD_EIM_D26__EMI_WEIM_D_26 508
-MX53_PAD_EIM_D26__GPIO3_26 509
-MX53_PAD_EIM_D26__UART2_TXD_MUX 510
-MX53_PAD_EIM_D26__FIRI_RXD 511
-MX53_PAD_EIM_D26__IPU_CSI0_D_1 512
-MX53_PAD_EIM_D26__IPU_DI1_PIN11 513
-MX53_PAD_EIM_D26__IPU_SISG_2 514
-MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 515
-MX53_PAD_EIM_D27__EMI_WEIM_D_27 516
-MX53_PAD_EIM_D27__GPIO3_27 517
-MX53_PAD_EIM_D27__UART2_RXD_MUX 518
-MX53_PAD_EIM_D27__FIRI_TXD 519
-MX53_PAD_EIM_D27__IPU_CSI0_D_0 520
-MX53_PAD_EIM_D27__IPU_DI1_PIN13 521
-MX53_PAD_EIM_D27__IPU_SISG_3 522
-MX53_PAD_EIM_D27__IPU_DISP1_DAT_23 523
-MX53_PAD_EIM_D28__EMI_WEIM_D_28 524
-MX53_PAD_EIM_D28__GPIO3_28 525
-MX53_PAD_EIM_D28__UART2_CTS 526
-MX53_PAD_EIM_D28__IPU_DISPB0_SER_DIO 527
-MX53_PAD_EIM_D28__CSPI_MOSI 528
-MX53_PAD_EIM_D28__I2C1_SDA 529
-MX53_PAD_EIM_D28__IPU_EXT_TRIG 530
-MX53_PAD_EIM_D28__IPU_DI0_PIN13 531
-MX53_PAD_EIM_D29__EMI_WEIM_D_29 532
-MX53_PAD_EIM_D29__GPIO3_29 533
-MX53_PAD_EIM_D29__UART2_RTS 534
-MX53_PAD_EIM_D29__IPU_DISPB0_SER_RS 535
-MX53_PAD_EIM_D29__CSPI_SS0 536
-MX53_PAD_EIM_D29__IPU_DI1_PIN15 537
-MX53_PAD_EIM_D29__IPU_CSI1_VSYNC 538
-MX53_PAD_EIM_D29__IPU_DI0_PIN14 539
-MX53_PAD_EIM_D30__EMI_WEIM_D_30 540
-MX53_PAD_EIM_D30__GPIO3_30 541
-MX53_PAD_EIM_D30__UART3_CTS 542
-MX53_PAD_EIM_D30__IPU_CSI0_D_3 543
-MX53_PAD_EIM_D30__IPU_DI0_PIN11 544
-MX53_PAD_EIM_D30__IPU_DISP1_DAT_21 545
-MX53_PAD_EIM_D30__USBOH3_USBH1_OC 546
-MX53_PAD_EIM_D30__USBOH3_USBH2_OC 547
-MX53_PAD_EIM_D31__EMI_WEIM_D_31 548
-MX53_PAD_EIM_D31__GPIO3_31 549
-MX53_PAD_EIM_D31__UART3_RTS 550
-MX53_PAD_EIM_D31__IPU_CSI0_D_2 551
-MX53_PAD_EIM_D31__IPU_DI0_PIN12 552
-MX53_PAD_EIM_D31__IPU_DISP1_DAT_20 553
-MX53_PAD_EIM_D31__USBOH3_USBH1_PWR 554
-MX53_PAD_EIM_D31__USBOH3_USBH2_PWR 555
-MX53_PAD_EIM_A24__EMI_WEIM_A_24 556
-MX53_PAD_EIM_A24__GPIO5_4 557
-MX53_PAD_EIM_A24__IPU_DISP1_DAT_19 558
-MX53_PAD_EIM_A24__IPU_CSI1_D_19 559
-MX53_PAD_EIM_A24__IPU_SISG_2 560
-MX53_PAD_EIM_A24__USBPHY2_BVALID 561
-MX53_PAD_EIM_A23__EMI_WEIM_A_23 562
-MX53_PAD_EIM_A23__GPIO6_6 563
-MX53_PAD_EIM_A23__IPU_DISP1_DAT_18 564
-MX53_PAD_EIM_A23__IPU_CSI1_D_18 565
-MX53_PAD_EIM_A23__IPU_SISG_3 566
-MX53_PAD_EIM_A23__USBPHY2_ENDSESSION 567
-MX53_PAD_EIM_A22__EMI_WEIM_A_22 568
-MX53_PAD_EIM_A22__GPIO2_16 569
-MX53_PAD_EIM_A22__IPU_DISP1_DAT_17 570
-MX53_PAD_EIM_A22__IPU_CSI1_D_17 571
-MX53_PAD_EIM_A22__SRC_BT_CFG1_7 572
-MX53_PAD_EIM_A21__EMI_WEIM_A_21 573
-MX53_PAD_EIM_A21__GPIO2_17 574
-MX53_PAD_EIM_A21__IPU_DISP1_DAT_16 575
-MX53_PAD_EIM_A21__IPU_CSI1_D_16 576
-MX53_PAD_EIM_A21__SRC_BT_CFG1_6 577
-MX53_PAD_EIM_A20__EMI_WEIM_A_20 578
-MX53_PAD_EIM_A20__GPIO2_18 579
-MX53_PAD_EIM_A20__IPU_DISP1_DAT_15 580
-MX53_PAD_EIM_A20__IPU_CSI1_D_15 581
-MX53_PAD_EIM_A20__SRC_BT_CFG1_5 582
-MX53_PAD_EIM_A19__EMI_WEIM_A_19 583
-MX53_PAD_EIM_A19__GPIO2_19 584
-MX53_PAD_EIM_A19__IPU_DISP1_DAT_14 585
-MX53_PAD_EIM_A19__IPU_CSI1_D_14 586
-MX53_PAD_EIM_A19__SRC_BT_CFG1_4 587
-MX53_PAD_EIM_A18__EMI_WEIM_A_18 588
-MX53_PAD_EIM_A18__GPIO2_20 589
-MX53_PAD_EIM_A18__IPU_DISP1_DAT_13 590
-MX53_PAD_EIM_A18__IPU_CSI1_D_13 591
-MX53_PAD_EIM_A18__SRC_BT_CFG1_3 592
-MX53_PAD_EIM_A17__EMI_WEIM_A_17 593
-MX53_PAD_EIM_A17__GPIO2_21 594
-MX53_PAD_EIM_A17__IPU_DISP1_DAT_12 595
-MX53_PAD_EIM_A17__IPU_CSI1_D_12 596
-MX53_PAD_EIM_A17__SRC_BT_CFG1_2 597
-MX53_PAD_EIM_A16__EMI_WEIM_A_16 598
-MX53_PAD_EIM_A16__GPIO2_22 599
-MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 600
-MX53_PAD_EIM_A16__IPU_CSI1_PIXCLK 601
-MX53_PAD_EIM_A16__SRC_BT_CFG1_1 602
-MX53_PAD_EIM_CS0__EMI_WEIM_CS_0 603
-MX53_PAD_EIM_CS0__GPIO2_23 604
-MX53_PAD_EIM_CS0__ECSPI2_SCLK 605
-MX53_PAD_EIM_CS0__IPU_DI1_PIN5 606
-MX53_PAD_EIM_CS1__EMI_WEIM_CS_1 607
-MX53_PAD_EIM_CS1__GPIO2_24 608
-MX53_PAD_EIM_CS1__ECSPI2_MOSI 609
-MX53_PAD_EIM_CS1__IPU_DI1_PIN6 610
-MX53_PAD_EIM_OE__EMI_WEIM_OE 611
-MX53_PAD_EIM_OE__GPIO2_25 612
-MX53_PAD_EIM_OE__ECSPI2_MISO 613
-MX53_PAD_EIM_OE__IPU_DI1_PIN7 614
-MX53_PAD_EIM_OE__USBPHY2_IDDIG 615
-MX53_PAD_EIM_RW__EMI_WEIM_RW 616
-MX53_PAD_EIM_RW__GPIO2_26 617
-MX53_PAD_EIM_RW__ECSPI2_SS0 618
-MX53_PAD_EIM_RW__IPU_DI1_PIN8 619
-MX53_PAD_EIM_RW__USBPHY2_HOSTDISCONNECT 620
-MX53_PAD_EIM_LBA__EMI_WEIM_LBA 621
-MX53_PAD_EIM_LBA__GPIO2_27 622
-MX53_PAD_EIM_LBA__ECSPI2_SS1 623
-MX53_PAD_EIM_LBA__IPU_DI1_PIN17 624
-MX53_PAD_EIM_LBA__SRC_BT_CFG1_0 625
-MX53_PAD_EIM_EB0__EMI_WEIM_EB_0 626
-MX53_PAD_EIM_EB0__GPIO2_28 627
-MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11 628
-MX53_PAD_EIM_EB0__IPU_CSI1_D_11 629
-MX53_PAD_EIM_EB0__GPC_PMIC_RDY 630
-MX53_PAD_EIM_EB0__SRC_BT_CFG2_7 631
-MX53_PAD_EIM_EB1__EMI_WEIM_EB_1 632
-MX53_PAD_EIM_EB1__GPIO2_29 633
-MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10 634
-MX53_PAD_EIM_EB1__IPU_CSI1_D_10 635
-MX53_PAD_EIM_EB1__SRC_BT_CFG2_6 636
-MX53_PAD_EIM_DA0__EMI_NAND_WEIM_DA_0 637
-MX53_PAD_EIM_DA0__GPIO3_0 638
-MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9 639
-MX53_PAD_EIM_DA0__IPU_CSI1_D_9 640
-MX53_PAD_EIM_DA0__SRC_BT_CFG2_5 641
-MX53_PAD_EIM_DA1__EMI_NAND_WEIM_DA_1 642
-MX53_PAD_EIM_DA1__GPIO3_1 643
-MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8 644
-MX53_PAD_EIM_DA1__IPU_CSI1_D_8 645
-MX53_PAD_EIM_DA1__SRC_BT_CFG2_4 646
-MX53_PAD_EIM_DA2__EMI_NAND_WEIM_DA_2 647
-MX53_PAD_EIM_DA2__GPIO3_2 648
-MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7 649
-MX53_PAD_EIM_DA2__IPU_CSI1_D_7 650
-MX53_PAD_EIM_DA2__SRC_BT_CFG2_3 651
-MX53_PAD_EIM_DA3__EMI_NAND_WEIM_DA_3 652
-MX53_PAD_EIM_DA3__GPIO3_3 653
-MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6 654
-MX53_PAD_EIM_DA3__IPU_CSI1_D_6 655
-MX53_PAD_EIM_DA3__SRC_BT_CFG2_2 656
-MX53_PAD_EIM_DA4__EMI_NAND_WEIM_DA_4 657
-MX53_PAD_EIM_DA4__GPIO3_4 658
-MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5 659
-MX53_PAD_EIM_DA4__IPU_CSI1_D_5 660
-MX53_PAD_EIM_DA4__SRC_BT_CFG3_7 661
-MX53_PAD_EIM_DA5__EMI_NAND_WEIM_DA_5 662
-MX53_PAD_EIM_DA5__GPIO3_5 663
-MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4 664
-MX53_PAD_EIM_DA5__IPU_CSI1_D_4 665
-MX53_PAD_EIM_DA5__SRC_BT_CFG3_6 666
-MX53_PAD_EIM_DA6__EMI_NAND_WEIM_DA_6 667
-MX53_PAD_EIM_DA6__GPIO3_6 668
-MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3 669
-MX53_PAD_EIM_DA6__IPU_CSI1_D_3 670
-MX53_PAD_EIM_DA6__SRC_BT_CFG3_5 671
-MX53_PAD_EIM_DA7__EMI_NAND_WEIM_DA_7 672
-MX53_PAD_EIM_DA7__GPIO3_7 673
-MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2 674
-MX53_PAD_EIM_DA7__IPU_CSI1_D_2 675
-MX53_PAD_EIM_DA7__SRC_BT_CFG3_4 676
-MX53_PAD_EIM_DA8__EMI_NAND_WEIM_DA_8 677
-MX53_PAD_EIM_DA8__GPIO3_8 678
-MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1 679
-MX53_PAD_EIM_DA8__IPU_CSI1_D_1 680
-MX53_PAD_EIM_DA8__SRC_BT_CFG3_3 681
-MX53_PAD_EIM_DA9__EMI_NAND_WEIM_DA_9 682
-MX53_PAD_EIM_DA9__GPIO3_9 683
-MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 684
-MX53_PAD_EIM_DA9__IPU_CSI1_D_0 685
-MX53_PAD_EIM_DA9__SRC_BT_CFG3_2 686
-MX53_PAD_EIM_DA10__EMI_NAND_WEIM_DA_10 687
-MX53_PAD_EIM_DA10__GPIO3_10 688
-MX53_PAD_EIM_DA10__IPU_DI1_PIN15 689
-MX53_PAD_EIM_DA10__IPU_CSI1_DATA_EN 690
-MX53_PAD_EIM_DA10__SRC_BT_CFG3_1 691
-MX53_PAD_EIM_DA11__EMI_NAND_WEIM_DA_11 692
-MX53_PAD_EIM_DA11__GPIO3_11 693
-MX53_PAD_EIM_DA11__IPU_DI1_PIN2 694
-MX53_PAD_EIM_DA11__IPU_CSI1_HSYNC 695
-MX53_PAD_EIM_DA12__EMI_NAND_WEIM_DA_12 696
-MX53_PAD_EIM_DA12__GPIO3_12 697
-MX53_PAD_EIM_DA12__IPU_DI1_PIN3 698
-MX53_PAD_EIM_DA12__IPU_CSI1_VSYNC 699
-MX53_PAD_EIM_DA13__EMI_NAND_WEIM_DA_13 700
-MX53_PAD_EIM_DA13__GPIO3_13 701
-MX53_PAD_EIM_DA13__IPU_DI1_D0_CS 702
-MX53_PAD_EIM_DA13__CCM_DI1_EXT_CLK 703
-MX53_PAD_EIM_DA14__EMI_NAND_WEIM_DA_14 704
-MX53_PAD_EIM_DA14__GPIO3_14 705
-MX53_PAD_EIM_DA14__IPU_DI1_D1_CS 706
-MX53_PAD_EIM_DA14__CCM_DI0_EXT_CLK 707
-MX53_PAD_EIM_DA15__EMI_NAND_WEIM_DA_15 708
-MX53_PAD_EIM_DA15__GPIO3_15 709
-MX53_PAD_EIM_DA15__IPU_DI1_PIN1 710
-MX53_PAD_EIM_DA15__IPU_DI1_PIN4 711
-MX53_PAD_NANDF_WE_B__EMI_NANDF_WE_B 712
-MX53_PAD_NANDF_WE_B__GPIO6_12 713
-MX53_PAD_NANDF_RE_B__EMI_NANDF_RE_B 714
-MX53_PAD_NANDF_RE_B__GPIO6_13 715
-MX53_PAD_EIM_WAIT__EMI_WEIM_WAIT 716
-MX53_PAD_EIM_WAIT__GPIO5_0 717
-MX53_PAD_EIM_WAIT__EMI_WEIM_DTACK_B 718
-MX53_PAD_LVDS1_TX3_P__GPIO6_22 719
-MX53_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3 720
-MX53_PAD_LVDS1_TX2_P__GPIO6_24 721
-MX53_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2 722
-MX53_PAD_LVDS1_CLK_P__GPIO6_26 723
-MX53_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK 724
-MX53_PAD_LVDS1_TX1_P__GPIO6_28 725
-MX53_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1 726
-MX53_PAD_LVDS1_TX0_P__GPIO6_30 727
-MX53_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0 728
-MX53_PAD_LVDS0_TX3_P__GPIO7_22 729
-MX53_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3 730
-MX53_PAD_LVDS0_CLK_P__GPIO7_24 731
-MX53_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK 732
-MX53_PAD_LVDS0_TX2_P__GPIO7_26 733
-MX53_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2 734
-MX53_PAD_LVDS0_TX1_P__GPIO7_28 735
-MX53_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1 736
-MX53_PAD_LVDS0_TX0_P__GPIO7_30 737
-MX53_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0 738
-MX53_PAD_GPIO_10__GPIO4_0 739
-MX53_PAD_GPIO_10__OSC32k_32K_OUT 740
-MX53_PAD_GPIO_11__GPIO4_1 741
-MX53_PAD_GPIO_12__GPIO4_2 742
-MX53_PAD_GPIO_13__GPIO4_3 743
-MX53_PAD_GPIO_14__GPIO4_4 744
-MX53_PAD_NANDF_CLE__EMI_NANDF_CLE 745
-MX53_PAD_NANDF_CLE__GPIO6_7 746
-MX53_PAD_NANDF_CLE__USBPHY1_VSTATUS_0 747
-MX53_PAD_NANDF_ALE__EMI_NANDF_ALE 748
-MX53_PAD_NANDF_ALE__GPIO6_8 749
-MX53_PAD_NANDF_ALE__USBPHY1_VSTATUS_1 750
-MX53_PAD_NANDF_WP_B__EMI_NANDF_WP_B 751
-MX53_PAD_NANDF_WP_B__GPIO6_9 752
-MX53_PAD_NANDF_WP_B__USBPHY1_VSTATUS_2 753
-MX53_PAD_NANDF_RB0__EMI_NANDF_RB_0 754
-MX53_PAD_NANDF_RB0__GPIO6_10 755
-MX53_PAD_NANDF_RB0__USBPHY1_VSTATUS_3 756
-MX53_PAD_NANDF_CS0__EMI_NANDF_CS_0 757
-MX53_PAD_NANDF_CS0__GPIO6_11 758
-MX53_PAD_NANDF_CS0__USBPHY1_VSTATUS_4 759
-MX53_PAD_NANDF_CS1__EMI_NANDF_CS_1 760
-MX53_PAD_NANDF_CS1__GPIO6_14 761
-MX53_PAD_NANDF_CS1__MLB_MLBCLK 762
-MX53_PAD_NANDF_CS1__USBPHY1_VSTATUS_5 763
-MX53_PAD_NANDF_CS2__EMI_NANDF_CS_2 764
-MX53_PAD_NANDF_CS2__GPIO6_15 765
-MX53_PAD_NANDF_CS2__IPU_SISG_0 766
-MX53_PAD_NANDF_CS2__ESAI1_TX0 767
-MX53_PAD_NANDF_CS2__EMI_WEIM_CRE 768
-MX53_PAD_NANDF_CS2__CCM_CSI0_MCLK 769
-MX53_PAD_NANDF_CS2__MLB_MLBSIG 770
-MX53_PAD_NANDF_CS2__USBPHY1_VSTATUS_6 771
-MX53_PAD_NANDF_CS3__EMI_NANDF_CS_3 772
-MX53_PAD_NANDF_CS3__GPIO6_16 773
-MX53_PAD_NANDF_CS3__IPU_SISG_1 774
-MX53_PAD_NANDF_CS3__ESAI1_TX1 775
-MX53_PAD_NANDF_CS3__EMI_WEIM_A_26 776
-MX53_PAD_NANDF_CS3__MLB_MLBDAT 777
-MX53_PAD_NANDF_CS3__USBPHY1_VSTATUS_7 778
-MX53_PAD_FEC_MDIO__FEC_MDIO 779
-MX53_PAD_FEC_MDIO__GPIO1_22 780
-MX53_PAD_FEC_MDIO__ESAI1_SCKR 781
-MX53_PAD_FEC_MDIO__FEC_COL 782
-MX53_PAD_FEC_MDIO__RTC_CE_RTC_PS2 783
-MX53_PAD_FEC_MDIO__SDMA_DEBUG_BUS_DEVICE_3 784
-MX53_PAD_FEC_MDIO__EMI_EMI_DEBUG_49 785
-MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 786
-MX53_PAD_FEC_REF_CLK__GPIO1_23 787
-MX53_PAD_FEC_REF_CLK__ESAI1_FSR 788
-MX53_PAD_FEC_REF_CLK__SDMA_DEBUG_BUS_DEVICE_4 789
-MX53_PAD_FEC_REF_CLK__EMI_EMI_DEBUG_50 790
-MX53_PAD_FEC_RX_ER__FEC_RX_ER 791
-MX53_PAD_FEC_RX_ER__GPIO1_24 792
-MX53_PAD_FEC_RX_ER__ESAI1_HCKR 793
-MX53_PAD_FEC_RX_ER__FEC_RX_CLK 794
-MX53_PAD_FEC_RX_ER__RTC_CE_RTC_PS3 795
-MX53_PAD_FEC_CRS_DV__FEC_RX_DV 796
-MX53_PAD_FEC_CRS_DV__GPIO1_25 797
-MX53_PAD_FEC_CRS_DV__ESAI1_SCKT 798
-MX53_PAD_FEC_RXD1__FEC_RDATA_1 799
-MX53_PAD_FEC_RXD1__GPIO1_26 800
-MX53_PAD_FEC_RXD1__ESAI1_FST 801
-MX53_PAD_FEC_RXD1__MLB_MLBSIG 802
-MX53_PAD_FEC_RXD1__RTC_CE_RTC_PS1 803
-MX53_PAD_FEC_RXD0__FEC_RDATA_0 804
-MX53_PAD_FEC_RXD0__GPIO1_27 805
-MX53_PAD_FEC_RXD0__ESAI1_HCKT 806
-MX53_PAD_FEC_RXD0__OSC32k_32K_OUT 807
-MX53_PAD_FEC_TX_EN__FEC_TX_EN 808
-MX53_PAD_FEC_TX_EN__GPIO1_28 809
-MX53_PAD_FEC_TX_EN__ESAI1_TX3_RX2 810
-MX53_PAD_FEC_TXD1__FEC_TDATA_1 811
-MX53_PAD_FEC_TXD1__GPIO1_29 812
-MX53_PAD_FEC_TXD1__ESAI1_TX2_RX3 813
-MX53_PAD_FEC_TXD1__MLB_MLBCLK 814
-MX53_PAD_FEC_TXD1__RTC_CE_RTC_PRSC_CLK 815
-MX53_PAD_FEC_TXD0__FEC_TDATA_0 816
-MX53_PAD_FEC_TXD0__GPIO1_30 817
-MX53_PAD_FEC_TXD0__ESAI1_TX4_RX1 818
-MX53_PAD_FEC_TXD0__USBPHY2_DATAOUT_0 819
-MX53_PAD_FEC_MDC__FEC_MDC 820
-MX53_PAD_FEC_MDC__GPIO1_31 821
-MX53_PAD_FEC_MDC__ESAI1_TX5_RX0 822
-MX53_PAD_FEC_MDC__MLB_MLBDAT 823
-MX53_PAD_FEC_MDC__RTC_CE_RTC_ALARM1_TRIG 824
-MX53_PAD_FEC_MDC__USBPHY2_DATAOUT_1 825
-MX53_PAD_PATA_DIOW__PATA_DIOW 826
-MX53_PAD_PATA_DIOW__GPIO6_17 827
-MX53_PAD_PATA_DIOW__UART1_TXD_MUX 828
-MX53_PAD_PATA_DIOW__USBPHY2_DATAOUT_2 829
-MX53_PAD_PATA_DMACK__PATA_DMACK 830
-MX53_PAD_PATA_DMACK__GPIO6_18 831
-MX53_PAD_PATA_DMACK__UART1_RXD_MUX 832
-MX53_PAD_PATA_DMACK__USBPHY2_DATAOUT_3 833
-MX53_PAD_PATA_DMARQ__PATA_DMARQ 834
-MX53_PAD_PATA_DMARQ__GPIO7_0 835
-MX53_PAD_PATA_DMARQ__UART2_TXD_MUX 836
-MX53_PAD_PATA_DMARQ__CCM_CCM_OUT_0 837
-MX53_PAD_PATA_DMARQ__USBPHY2_DATAOUT_4 838
-MX53_PAD_PATA_BUFFER_EN__PATA_BUFFER_EN 839
-MX53_PAD_PATA_BUFFER_EN__GPIO7_1 840
-MX53_PAD_PATA_BUFFER_EN__UART2_RXD_MUX 841
-MX53_PAD_PATA_BUFFER_EN__CCM_CCM_OUT_1 842
-MX53_PAD_PATA_BUFFER_EN__USBPHY2_DATAOUT_5 843
-MX53_PAD_PATA_INTRQ__PATA_INTRQ 844
-MX53_PAD_PATA_INTRQ__GPIO7_2 845
-MX53_PAD_PATA_INTRQ__UART2_CTS 846
-MX53_PAD_PATA_INTRQ__CAN1_TXCAN 847
-MX53_PAD_PATA_INTRQ__CCM_CCM_OUT_2 848
-MX53_PAD_PATA_INTRQ__USBPHY2_DATAOUT_6 849
-MX53_PAD_PATA_DIOR__PATA_DIOR 850
-MX53_PAD_PATA_DIOR__GPIO7_3 851
-MX53_PAD_PATA_DIOR__UART2_RTS 852
-MX53_PAD_PATA_DIOR__CAN1_RXCAN 853
-MX53_PAD_PATA_DIOR__USBPHY2_DATAOUT_7 854
-MX53_PAD_PATA_RESET_B__PATA_PATA_RESET_B 855
-MX53_PAD_PATA_RESET_B__GPIO7_4 856
-MX53_PAD_PATA_RESET_B__ESDHC3_CMD 857
-MX53_PAD_PATA_RESET_B__UART1_CTS 858
-MX53_PAD_PATA_RESET_B__CAN2_TXCAN 859
-MX53_PAD_PATA_RESET_B__USBPHY1_DATAOUT_0 860
-MX53_PAD_PATA_IORDY__PATA_IORDY 861
-MX53_PAD_PATA_IORDY__GPIO7_5 862
-MX53_PAD_PATA_IORDY__ESDHC3_CLK 863
-MX53_PAD_PATA_IORDY__UART1_RTS 864
-MX53_PAD_PATA_IORDY__CAN2_RXCAN 865
-MX53_PAD_PATA_IORDY__USBPHY1_DATAOUT_1 866
-MX53_PAD_PATA_DA_0__PATA_DA_0 867
-MX53_PAD_PATA_DA_0__GPIO7_6 868
-MX53_PAD_PATA_DA_0__ESDHC3_RST 869
-MX53_PAD_PATA_DA_0__OWIRE_LINE 870
-MX53_PAD_PATA_DA_0__USBPHY1_DATAOUT_2 871
-MX53_PAD_PATA_DA_1__PATA_DA_1 872
-MX53_PAD_PATA_DA_1__GPIO7_7 873
-MX53_PAD_PATA_DA_1__ESDHC4_CMD 874
-MX53_PAD_PATA_DA_1__UART3_CTS 875
-MX53_PAD_PATA_DA_1__USBPHY1_DATAOUT_3 876
-MX53_PAD_PATA_DA_2__PATA_DA_2 877
-MX53_PAD_PATA_DA_2__GPIO7_8 878
-MX53_PAD_PATA_DA_2__ESDHC4_CLK 879
-MX53_PAD_PATA_DA_2__UART3_RTS 880
-MX53_PAD_PATA_DA_2__USBPHY1_DATAOUT_4 881
-MX53_PAD_PATA_CS_0__PATA_CS_0 882
-MX53_PAD_PATA_CS_0__GPIO7_9 883
-MX53_PAD_PATA_CS_0__UART3_TXD_MUX 884
-MX53_PAD_PATA_CS_0__USBPHY1_DATAOUT_5 885
-MX53_PAD_PATA_CS_1__PATA_CS_1 886
-MX53_PAD_PATA_CS_1__GPIO7_10 887
-MX53_PAD_PATA_CS_1__UART3_RXD_MUX 888
-MX53_PAD_PATA_CS_1__USBPHY1_DATAOUT_6 889
-MX53_PAD_PATA_DATA0__PATA_DATA_0 890
-MX53_PAD_PATA_DATA0__GPIO2_0 891
-MX53_PAD_PATA_DATA0__EMI_NANDF_D_0 892
-MX53_PAD_PATA_DATA0__ESDHC3_DAT4 893
-MX53_PAD_PATA_DATA0__GPU3d_GPU_DEBUG_OUT_0 894
-MX53_PAD_PATA_DATA0__IPU_DIAG_BUS_0 895
-MX53_PAD_PATA_DATA0__USBPHY1_DATAOUT_7 896
-MX53_PAD_PATA_DATA1__PATA_DATA_1 897
-MX53_PAD_PATA_DATA1__GPIO2_1 898
-MX53_PAD_PATA_DATA1__EMI_NANDF_D_1 899
-MX53_PAD_PATA_DATA1__ESDHC3_DAT5 900
-MX53_PAD_PATA_DATA1__GPU3d_GPU_DEBUG_OUT_1 901
-MX53_PAD_PATA_DATA1__IPU_DIAG_BUS_1 902
-MX53_PAD_PATA_DATA2__PATA_DATA_2 903
-MX53_PAD_PATA_DATA2__GPIO2_2 904
-MX53_PAD_PATA_DATA2__EMI_NANDF_D_2 905
-MX53_PAD_PATA_DATA2__ESDHC3_DAT6 906
-MX53_PAD_PATA_DATA2__GPU3d_GPU_DEBUG_OUT_2 907
-MX53_PAD_PATA_DATA2__IPU_DIAG_BUS_2 908
-MX53_PAD_PATA_DATA3__PATA_DATA_3 909
-MX53_PAD_PATA_DATA3__GPIO2_3 910
-MX53_PAD_PATA_DATA3__EMI_NANDF_D_3 911
-MX53_PAD_PATA_DATA3__ESDHC3_DAT7 912
-MX53_PAD_PATA_DATA3__GPU3d_GPU_DEBUG_OUT_3 913
-MX53_PAD_PATA_DATA3__IPU_DIAG_BUS_3 914
-MX53_PAD_PATA_DATA4__PATA_DATA_4 915
-MX53_PAD_PATA_DATA4__GPIO2_4 916
-MX53_PAD_PATA_DATA4__EMI_NANDF_D_4 917
-MX53_PAD_PATA_DATA4__ESDHC4_DAT4 918
-MX53_PAD_PATA_DATA4__GPU3d_GPU_DEBUG_OUT_4 919
-MX53_PAD_PATA_DATA4__IPU_DIAG_BUS_4 920
-MX53_PAD_PATA_DATA5__PATA_DATA_5 921
-MX53_PAD_PATA_DATA5__GPIO2_5 922
-MX53_PAD_PATA_DATA5__EMI_NANDF_D_5 923
-MX53_PAD_PATA_DATA5__ESDHC4_DAT5 924
-MX53_PAD_PATA_DATA5__GPU3d_GPU_DEBUG_OUT_5 925
-MX53_PAD_PATA_DATA5__IPU_DIAG_BUS_5 926
-MX53_PAD_PATA_DATA6__PATA_DATA_6 927
-MX53_PAD_PATA_DATA6__GPIO2_6 928
-MX53_PAD_PATA_DATA6__EMI_NANDF_D_6 929
-MX53_PAD_PATA_DATA6__ESDHC4_DAT6 930
-MX53_PAD_PATA_DATA6__GPU3d_GPU_DEBUG_OUT_6 931
-MX53_PAD_PATA_DATA6__IPU_DIAG_BUS_6 932
-MX53_PAD_PATA_DATA7__PATA_DATA_7 933
-MX53_PAD_PATA_DATA7__GPIO2_7 934
-MX53_PAD_PATA_DATA7__EMI_NANDF_D_7 935
-MX53_PAD_PATA_DATA7__ESDHC4_DAT7 936
-MX53_PAD_PATA_DATA7__GPU3d_GPU_DEBUG_OUT_7 937
-MX53_PAD_PATA_DATA7__IPU_DIAG_BUS_7 938
-MX53_PAD_PATA_DATA8__PATA_DATA_8 939
-MX53_PAD_PATA_DATA8__GPIO2_8 940
-MX53_PAD_PATA_DATA8__ESDHC1_DAT4 941
-MX53_PAD_PATA_DATA8__EMI_NANDF_D_8 942
-MX53_PAD_PATA_DATA8__ESDHC3_DAT0 943
-MX53_PAD_PATA_DATA8__GPU3d_GPU_DEBUG_OUT_8 944
-MX53_PAD_PATA_DATA8__IPU_DIAG_BUS_8 945
-MX53_PAD_PATA_DATA9__PATA_DATA_9 946
-MX53_PAD_PATA_DATA9__GPIO2_9 947
-MX53_PAD_PATA_DATA9__ESDHC1_DAT5 948
-MX53_PAD_PATA_DATA9__EMI_NANDF_D_9 949
-MX53_PAD_PATA_DATA9__ESDHC3_DAT1 950
-MX53_PAD_PATA_DATA9__GPU3d_GPU_DEBUG_OUT_9 951
-MX53_PAD_PATA_DATA9__IPU_DIAG_BUS_9 952
-MX53_PAD_PATA_DATA10__PATA_DATA_10 953
-MX53_PAD_PATA_DATA10__GPIO2_10 954
-MX53_PAD_PATA_DATA10__ESDHC1_DAT6 955
-MX53_PAD_PATA_DATA10__EMI_NANDF_D_10 956
-MX53_PAD_PATA_DATA10__ESDHC3_DAT2 957
-MX53_PAD_PATA_DATA10__GPU3d_GPU_DEBUG_OUT_10 958
-MX53_PAD_PATA_DATA10__IPU_DIAG_BUS_10 959
-MX53_PAD_PATA_DATA11__PATA_DATA_11 960
-MX53_PAD_PATA_DATA11__GPIO2_11 961
-MX53_PAD_PATA_DATA11__ESDHC1_DAT7 962
-MX53_PAD_PATA_DATA11__EMI_NANDF_D_11 963
-MX53_PAD_PATA_DATA11__ESDHC3_DAT3 964
-MX53_PAD_PATA_DATA11__GPU3d_GPU_DEBUG_OUT_11 965
-MX53_PAD_PATA_DATA11__IPU_DIAG_BUS_11 966
-MX53_PAD_PATA_DATA12__PATA_DATA_12 967
-MX53_PAD_PATA_DATA12__GPIO2_12 968
-MX53_PAD_PATA_DATA12__ESDHC2_DAT4 969
-MX53_PAD_PATA_DATA12__EMI_NANDF_D_12 970
-MX53_PAD_PATA_DATA12__ESDHC4_DAT0 971
-MX53_PAD_PATA_DATA12__GPU3d_GPU_DEBUG_OUT_12 972
-MX53_PAD_PATA_DATA12__IPU_DIAG_BUS_12 973
-MX53_PAD_PATA_DATA13__PATA_DATA_13 974
-MX53_PAD_PATA_DATA13__GPIO2_13 975
-MX53_PAD_PATA_DATA13__ESDHC2_DAT5 976
-MX53_PAD_PATA_DATA13__EMI_NANDF_D_13 977
-MX53_PAD_PATA_DATA13__ESDHC4_DAT1 978
-MX53_PAD_PATA_DATA13__GPU3d_GPU_DEBUG_OUT_13 979
-MX53_PAD_PATA_DATA13__IPU_DIAG_BUS_13 980
-MX53_PAD_PATA_DATA14__PATA_DATA_14 981
-MX53_PAD_PATA_DATA14__GPIO2_14 982
-MX53_PAD_PATA_DATA14__ESDHC2_DAT6 983
-MX53_PAD_PATA_DATA14__EMI_NANDF_D_14 984
-MX53_PAD_PATA_DATA14__ESDHC4_DAT2 985
-MX53_PAD_PATA_DATA14__GPU3d_GPU_DEBUG_OUT_14 986
-MX53_PAD_PATA_DATA14__IPU_DIAG_BUS_14 987
-MX53_PAD_PATA_DATA15__PATA_DATA_15 988
-MX53_PAD_PATA_DATA15__GPIO2_15 989
-MX53_PAD_PATA_DATA15__ESDHC2_DAT7 990
-MX53_PAD_PATA_DATA15__EMI_NANDF_D_15 991
-MX53_PAD_PATA_DATA15__ESDHC4_DAT3 992
-MX53_PAD_PATA_DATA15__GPU3d_GPU_DEBUG_OUT_15 993
-MX53_PAD_PATA_DATA15__IPU_DIAG_BUS_15 994
-MX53_PAD_SD1_DATA0__ESDHC1_DAT0 995
-MX53_PAD_SD1_DATA0__GPIO1_16 996
-MX53_PAD_SD1_DATA0__GPT_CAPIN1 997
-MX53_PAD_SD1_DATA0__CSPI_MISO 998
-MX53_PAD_SD1_DATA0__CCM_PLL3_BYP 999
-MX53_PAD_SD1_DATA1__ESDHC1_DAT1 1000
-MX53_PAD_SD1_DATA1__GPIO1_17 1001
-MX53_PAD_SD1_DATA1__GPT_CAPIN2 1002
-MX53_PAD_SD1_DATA1__CSPI_SS0 1003
-MX53_PAD_SD1_DATA1__CCM_PLL4_BYP 1004
-MX53_PAD_SD1_CMD__ESDHC1_CMD 1005
-MX53_PAD_SD1_CMD__GPIO1_18 1006
-MX53_PAD_SD1_CMD__GPT_CMPOUT1 1007
-MX53_PAD_SD1_CMD__CSPI_MOSI 1008
-MX53_PAD_SD1_CMD__CCM_PLL1_BYP 1009
-MX53_PAD_SD1_DATA2__ESDHC1_DAT2 1010
-MX53_PAD_SD1_DATA2__GPIO1_19 1011
-MX53_PAD_SD1_DATA2__GPT_CMPOUT2 1012
-MX53_PAD_SD1_DATA2__PWM2_PWMO 1013
-MX53_PAD_SD1_DATA2__WDOG1_WDOG_B 1014
-MX53_PAD_SD1_DATA2__CSPI_SS1 1015
-MX53_PAD_SD1_DATA2__WDOG1_WDOG_RST_B_DEB 1016
-MX53_PAD_SD1_DATA2__CCM_PLL2_BYP 1017
-MX53_PAD_SD1_CLK__ESDHC1_CLK 1018
-MX53_PAD_SD1_CLK__GPIO1_20 1019
-MX53_PAD_SD1_CLK__OSC32k_32K_OUT 1020
-MX53_PAD_SD1_CLK__GPT_CLKIN 1021
-MX53_PAD_SD1_CLK__CSPI_SCLK 1022
-MX53_PAD_SD1_CLK__SATA_PHY_DTB_0 1023
-MX53_PAD_SD1_DATA3__ESDHC1_DAT3 1024
-MX53_PAD_SD1_DATA3__GPIO1_21 1025
-MX53_PAD_SD1_DATA3__GPT_CMPOUT3 1026
-MX53_PAD_SD1_DATA3__PWM1_PWMO 1027
-MX53_PAD_SD1_DATA3__WDOG2_WDOG_B 1028
-MX53_PAD_SD1_DATA3__CSPI_SS2 1029
-MX53_PAD_SD1_DATA3__WDOG2_WDOG_RST_B_DEB 1030
-MX53_PAD_SD1_DATA3__SATA_PHY_DTB_1 1031
-MX53_PAD_SD2_CLK__ESDHC2_CLK 1032
-MX53_PAD_SD2_CLK__GPIO1_10 1033
-MX53_PAD_SD2_CLK__KPP_COL_5 1034
-MX53_PAD_SD2_CLK__AUDMUX_AUD4_RXFS 1035
-MX53_PAD_SD2_CLK__CSPI_SCLK 1036
-MX53_PAD_SD2_CLK__SCC_RANDOM_V 1037
-MX53_PAD_SD2_CMD__ESDHC2_CMD 1038
-MX53_PAD_SD2_CMD__GPIO1_11 1039
-MX53_PAD_SD2_CMD__KPP_ROW_5 1040
-MX53_PAD_SD2_CMD__AUDMUX_AUD4_RXC 1041
-MX53_PAD_SD2_CMD__CSPI_MOSI 1042
-MX53_PAD_SD2_CMD__SCC_RANDOM 1043
-MX53_PAD_SD2_DATA3__ESDHC2_DAT3 1044
-MX53_PAD_SD2_DATA3__GPIO1_12 1045
-MX53_PAD_SD2_DATA3__KPP_COL_6 1046
-MX53_PAD_SD2_DATA3__AUDMUX_AUD4_TXC 1047
-MX53_PAD_SD2_DATA3__CSPI_SS2 1048
-MX53_PAD_SD2_DATA3__SJC_DONE 1049
-MX53_PAD_SD2_DATA2__ESDHC2_DAT2 1050
-MX53_PAD_SD2_DATA2__GPIO1_13 1051
-MX53_PAD_SD2_DATA2__KPP_ROW_6 1052
-MX53_PAD_SD2_DATA2__AUDMUX_AUD4_TXD 1053
-MX53_PAD_SD2_DATA2__CSPI_SS1 1054
-MX53_PAD_SD2_DATA2__SJC_FAIL 1055
-MX53_PAD_SD2_DATA1__ESDHC2_DAT1 1056
-MX53_PAD_SD2_DATA1__GPIO1_14 1057
-MX53_PAD_SD2_DATA1__KPP_COL_7 1058
-MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS 1059
-MX53_PAD_SD2_DATA1__CSPI_SS0 1060
-MX53_PAD_SD2_DATA1__RTIC_SEC_VIO 1061
-MX53_PAD_SD2_DATA0__ESDHC2_DAT0 1062
-MX53_PAD_SD2_DATA0__GPIO1_15 1063
-MX53_PAD_SD2_DATA0__KPP_ROW_7 1064
-MX53_PAD_SD2_DATA0__AUDMUX_AUD4_RXD 1065
-MX53_PAD_SD2_DATA0__CSPI_MISO 1066
-MX53_PAD_SD2_DATA0__RTIC_DONE_INT 1067
-MX53_PAD_GPIO_0__CCM_CLKO 1068
-MX53_PAD_GPIO_0__GPIO1_0 1069
-MX53_PAD_GPIO_0__KPP_COL_5 1070
-MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 1071
-MX53_PAD_GPIO_0__EPIT1_EPITO 1072
-MX53_PAD_GPIO_0__SRTC_ALARM_DEB 1073
-MX53_PAD_GPIO_0__USBOH3_USBH1_PWR 1074
-MX53_PAD_GPIO_0__CSU_TD 1075
-MX53_PAD_GPIO_1__ESAI1_SCKR 1076
-MX53_PAD_GPIO_1__GPIO1_1 1077
-MX53_PAD_GPIO_1__KPP_ROW_5 1078
-MX53_PAD_GPIO_1__CCM_SSI_EXT2_CLK 1079
-MX53_PAD_GPIO_1__PWM2_PWMO 1080
-MX53_PAD_GPIO_1__WDOG2_WDOG_B 1081
-MX53_PAD_GPIO_1__ESDHC1_CD 1082
-MX53_PAD_GPIO_1__SRC_TESTER_ACK 1083
-MX53_PAD_GPIO_9__ESAI1_FSR 1084
-MX53_PAD_GPIO_9__GPIO1_9 1085
-MX53_PAD_GPIO_9__KPP_COL_6 1086
-MX53_PAD_GPIO_9__CCM_REF_EN_B 1087
-MX53_PAD_GPIO_9__PWM1_PWMO 1088
-MX53_PAD_GPIO_9__WDOG1_WDOG_B 1089
-MX53_PAD_GPIO_9__ESDHC1_WP 1090
-MX53_PAD_GPIO_9__SCC_FAIL_STATE 1091
-MX53_PAD_GPIO_3__ESAI1_HCKR 1092
-MX53_PAD_GPIO_3__GPIO1_3 1093
-MX53_PAD_GPIO_3__I2C3_SCL 1094
-MX53_PAD_GPIO_3__DPLLIP1_TOG_EN 1095
-MX53_PAD_GPIO_3__CCM_CLKO2 1096
-MX53_PAD_GPIO_3__OBSERVE_MUX_OBSRV_INT_OUT0 1097
-MX53_PAD_GPIO_3__USBOH3_USBH1_OC 1098
-MX53_PAD_GPIO_3__MLB_MLBCLK 1099
-MX53_PAD_GPIO_6__ESAI1_SCKT 1100
-MX53_PAD_GPIO_6__GPIO1_6 1101
-MX53_PAD_GPIO_6__I2C3_SDA 1102
-MX53_PAD_GPIO_6__CCM_CCM_OUT_0 1103
-MX53_PAD_GPIO_6__CSU_CSU_INT_DEB 1104
-MX53_PAD_GPIO_6__OBSERVE_MUX_OBSRV_INT_OUT1 1105
-MX53_PAD_GPIO_6__ESDHC2_LCTL 1106
-MX53_PAD_GPIO_6__MLB_MLBSIG 1107
-MX53_PAD_GPIO_2__ESAI1_FST 1108
-MX53_PAD_GPIO_2__GPIO1_2 1109
-MX53_PAD_GPIO_2__KPP_ROW_6 1110
-MX53_PAD_GPIO_2__CCM_CCM_OUT_1 1111
-MX53_PAD_GPIO_2__CSU_CSU_ALARM_AUT_0 1112
-MX53_PAD_GPIO_2__OBSERVE_MUX_OBSRV_INT_OUT2 1113
-MX53_PAD_GPIO_2__ESDHC2_WP 1114
-MX53_PAD_GPIO_2__MLB_MLBDAT 1115
-MX53_PAD_GPIO_4__ESAI1_HCKT 1116
-MX53_PAD_GPIO_4__GPIO1_4 1117
-MX53_PAD_GPIO_4__KPP_COL_7 1118
-MX53_PAD_GPIO_4__CCM_CCM_OUT_2 1119
-MX53_PAD_GPIO_4__CSU_CSU_ALARM_AUT_1 1120
-MX53_PAD_GPIO_4__OBSERVE_MUX_OBSRV_INT_OUT3 1121
-MX53_PAD_GPIO_4__ESDHC2_CD 1122
-MX53_PAD_GPIO_4__SCC_SEC_STATE 1123
-MX53_PAD_GPIO_5__ESAI1_TX2_RX3 1124
-MX53_PAD_GPIO_5__GPIO1_5 1125
-MX53_PAD_GPIO_5__KPP_ROW_7 1126
-MX53_PAD_GPIO_5__CCM_CLKO 1127
-MX53_PAD_GPIO_5__CSU_CSU_ALARM_AUT_2 1128
-MX53_PAD_GPIO_5__OBSERVE_MUX_OBSRV_INT_OUT4 1129
-MX53_PAD_GPIO_5__I2C3_SCL 1130
-MX53_PAD_GPIO_5__CCM_PLL1_BYP 1131
-MX53_PAD_GPIO_7__ESAI1_TX4_RX1 1132
-MX53_PAD_GPIO_7__GPIO1_7 1133
-MX53_PAD_GPIO_7__EPIT1_EPITO 1134
-MX53_PAD_GPIO_7__CAN1_TXCAN 1135
-MX53_PAD_GPIO_7__UART2_TXD_MUX 1136
-MX53_PAD_GPIO_7__FIRI_RXD 1137
-MX53_PAD_GPIO_7__SPDIF_PLOCK 1138
-MX53_PAD_GPIO_7__CCM_PLL2_BYP 1139
-MX53_PAD_GPIO_8__ESAI1_TX5_RX0 1140
-MX53_PAD_GPIO_8__GPIO1_8 1141
-MX53_PAD_GPIO_8__EPIT2_EPITO 1142
-MX53_PAD_GPIO_8__CAN1_RXCAN 1143
-MX53_PAD_GPIO_8__UART2_RXD_MUX 1144
-MX53_PAD_GPIO_8__FIRI_TXD 1145
-MX53_PAD_GPIO_8__SPDIF_SRCLK 1146
-MX53_PAD_GPIO_8__CCM_PLL3_BYP 1147
-MX53_PAD_GPIO_16__ESAI1_TX3_RX2 1148
-MX53_PAD_GPIO_16__GPIO7_11 1149
-MX53_PAD_GPIO_16__TZIC_PWRFAIL_INT 1150
-MX53_PAD_GPIO_16__RTC_CE_RTC_EXT_TRIG1 1151
-MX53_PAD_GPIO_16__SPDIF_IN1 1152
-MX53_PAD_GPIO_16__I2C3_SDA 1153
-MX53_PAD_GPIO_16__SJC_DE_B 1154
-MX53_PAD_GPIO_17__ESAI1_TX0 1155
-MX53_PAD_GPIO_17__GPIO7_12 1156
-MX53_PAD_GPIO_17__SDMA_EXT_EVENT_0 1157
-MX53_PAD_GPIO_17__GPC_PMIC_RDY 1158
-MX53_PAD_GPIO_17__RTC_CE_RTC_FSV_TRIG 1159
-MX53_PAD_GPIO_17__SPDIF_OUT1 1160
-MX53_PAD_GPIO_17__IPU_SNOOP2 1161
-MX53_PAD_GPIO_17__SJC_JTAG_ACT 1162
-MX53_PAD_GPIO_18__ESAI1_TX1 1163
-MX53_PAD_GPIO_18__GPIO7_13 1164
-MX53_PAD_GPIO_18__SDMA_EXT_EVENT_1 1165
-MX53_PAD_GPIO_18__OWIRE_LINE 1166
-MX53_PAD_GPIO_18__RTC_CE_RTC_ALARM2_TRIG 1167
-MX53_PAD_GPIO_18__CCM_ASRC_EXT_CLK 1168
-MX53_PAD_GPIO_18__ESDHC1_LCTL 1169
-MX53_PAD_GPIO_18__SRC_SYSTEM_RST 1170
+Refer to imx53-pinfunc.h in device tree source folder for all available
+imx53 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
new file mode 100644
index 000000000000..0ac5bee87505
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6dl-pinctrl.txt
@@ -0,0 +1,38 @@
+* Freescale IMX6 DualLite/Solo IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx6dl-iomuxc"
+- fsl,pins: two integers array, represents a group of pins mux and config
+ setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
+ pin working on a specific function, CONFIG is the pad setting value like
+ pull-up for this pin. Please refer to imx6dl datasheet for the valid pad
+ config settings.
+
+CONFIG bits definition:
+PAD_CTL_HYS (1 << 16)
+PAD_CTL_PUS_100K_DOWN (0 << 14)
+PAD_CTL_PUS_47K_UP (1 << 14)
+PAD_CTL_PUS_100K_UP (2 << 14)
+PAD_CTL_PUS_22K_UP (3 << 14)
+PAD_CTL_PUE (1 << 13)
+PAD_CTL_PKE (1 << 12)
+PAD_CTL_ODE (1 << 11)
+PAD_CTL_SPEED_LOW (1 << 6)
+PAD_CTL_SPEED_MED (2 << 6)
+PAD_CTL_SPEED_HIGH (3 << 6)
+PAD_CTL_DSE_DISABLE (0 << 3)
+PAD_CTL_DSE_240ohm (1 << 3)
+PAD_CTL_DSE_120ohm (2 << 3)
+PAD_CTL_DSE_80ohm (3 << 3)
+PAD_CTL_DSE_60ohm (4 << 3)
+PAD_CTL_DSE_48ohm (5 << 3)
+PAD_CTL_DSE_40ohm (6 << 3)
+PAD_CTL_DSE_34ohm (7 << 3)
+PAD_CTL_SRE_FAST (1 << 0)
+PAD_CTL_SRE_SLOW (0 << 0)
+
+Refer to imx6dl-pinfunc.h in device tree source folder for all available
+imx6dl PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
index a4119f6422d9..546610cf2ae7 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt
@@ -34,1597 +34,5 @@ PAD_CTL_DSE_34ohm (7 << 3)
PAD_CTL_SRE_FAST (1 << 0)
PAD_CTL_SRE_SLOW (0 << 0)
-See below for available PIN_FUNC_ID for imx6q:
-MX6Q_PAD_SD2_DAT1__USDHC2_DAT1 0
-MX6Q_PAD_SD2_DAT1__ECSPI5_SS0 1
-MX6Q_PAD_SD2_DAT1__WEIM_WEIM_CS_2 2
-MX6Q_PAD_SD2_DAT1__AUDMUX_AUD4_TXFS 3
-MX6Q_PAD_SD2_DAT1__KPP_COL_7 4
-MX6Q_PAD_SD2_DAT1__GPIO_1_14 5
-MX6Q_PAD_SD2_DAT1__CCM_WAIT 6
-MX6Q_PAD_SD2_DAT1__ANATOP_TESTO_0 7
-MX6Q_PAD_SD2_DAT2__USDHC2_DAT2 8
-MX6Q_PAD_SD2_DAT2__ECSPI5_SS1 9
-MX6Q_PAD_SD2_DAT2__WEIM_WEIM_CS_3 10
-MX6Q_PAD_SD2_DAT2__AUDMUX_AUD4_TXD 11
-MX6Q_PAD_SD2_DAT2__KPP_ROW_6 12
-MX6Q_PAD_SD2_DAT2__GPIO_1_13 13
-MX6Q_PAD_SD2_DAT2__CCM_STOP 14
-MX6Q_PAD_SD2_DAT2__ANATOP_TESTO_1 15
-MX6Q_PAD_SD2_DAT0__USDHC2_DAT0 16
-MX6Q_PAD_SD2_DAT0__ECSPI5_MISO 17
-MX6Q_PAD_SD2_DAT0__AUDMUX_AUD4_RXD 18
-MX6Q_PAD_SD2_DAT0__KPP_ROW_7 19
-MX6Q_PAD_SD2_DAT0__GPIO_1_15 20
-MX6Q_PAD_SD2_DAT0__DCIC2_DCIC_OUT 21
-MX6Q_PAD_SD2_DAT0__TESTO_2 22
-MX6Q_PAD_RGMII_TXC__USBOH3_H2_DATA 23
-MX6Q_PAD_RGMII_TXC__ENET_RGMII_TXC 24
-MX6Q_PAD_RGMII_TXC__SPDIF_SPDIF_EXTCLK 25
-MX6Q_PAD_RGMII_TXC__GPIO_6_19 26
-MX6Q_PAD_RGMII_TXC__MIPI_CORE_DPHY_IN_0 27
-MX6Q_PAD_RGMII_TXC__ANATOP_24M_OUT 28
-MX6Q_PAD_RGMII_TD0__MIPI_HSI_CRL_TX_RDY 29
-MX6Q_PAD_RGMII_TD0__ENET_RGMII_TD0 30
-MX6Q_PAD_RGMII_TD0__GPIO_6_20 31
-MX6Q_PAD_RGMII_TD0__MIPI_CORE_DPHY_IN_1 32
-MX6Q_PAD_RGMII_TD1__MIPI_HSI_CRL_RX_FLG 33
-MX6Q_PAD_RGMII_TD1__ENET_RGMII_TD1 34
-MX6Q_PAD_RGMII_TD1__GPIO_6_21 35
-MX6Q_PAD_RGMII_TD1__MIPI_CORE_DPHY_IN_2 36
-MX6Q_PAD_RGMII_TD1__CCM_PLL3_BYP 37
-MX6Q_PAD_RGMII_TD2__MIPI_HSI_CRL_RX_DTA 38
-MX6Q_PAD_RGMII_TD2__ENET_RGMII_TD2 39
-MX6Q_PAD_RGMII_TD2__GPIO_6_22 40
-MX6Q_PAD_RGMII_TD2__MIPI_CORE_DPHY_IN_3 41
-MX6Q_PAD_RGMII_TD2__CCM_PLL2_BYP 42
-MX6Q_PAD_RGMII_TD3__MIPI_HSI_CRL_RX_WAK 43
-MX6Q_PAD_RGMII_TD3__ENET_RGMII_TD3 44
-MX6Q_PAD_RGMII_TD3__GPIO_6_23 45
-MX6Q_PAD_RGMII_TD3__MIPI_CORE_DPHY_IN_4 46
-MX6Q_PAD_RGMII_RX_CTL__USBOH3_H3_DATA 47
-MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL 48
-MX6Q_PAD_RGMII_RX_CTL__GPIO_6_24 49
-MX6Q_PAD_RGMII_RX_CTL__MIPI_DPHY_IN_5 50
-MX6Q_PAD_RGMII_RD0__MIPI_HSI_CRL_RX_RDY 51
-MX6Q_PAD_RGMII_RD0__ENET_RGMII_RD0 52
-MX6Q_PAD_RGMII_RD0__GPIO_6_25 53
-MX6Q_PAD_RGMII_RD0__MIPI_CORE_DPHY_IN_6 54
-MX6Q_PAD_RGMII_TX_CTL__USBOH3_H2_STROBE 55
-MX6Q_PAD_RGMII_TX_CTL__RGMII_TX_CTL 56
-MX6Q_PAD_RGMII_TX_CTL__GPIO_6_26 57
-MX6Q_PAD_RGMII_TX_CTL__CORE_DPHY_IN_7 58
-MX6Q_PAD_RGMII_TX_CTL__ANATOP_REF_OUT 59
-MX6Q_PAD_RGMII_RD1__MIPI_HSI_CTRL_TX_FL 60
-MX6Q_PAD_RGMII_RD1__ENET_RGMII_RD1 61
-MX6Q_PAD_RGMII_RD1__GPIO_6_27 62
-MX6Q_PAD_RGMII_RD1__CORE_DPHY_TEST_IN_8 63
-MX6Q_PAD_RGMII_RD1__SJC_FAIL 64
-MX6Q_PAD_RGMII_RD2__MIPI_HSI_CRL_TX_DTA 65
-MX6Q_PAD_RGMII_RD2__ENET_RGMII_RD2 66
-MX6Q_PAD_RGMII_RD2__GPIO_6_28 67
-MX6Q_PAD_RGMII_RD2__MIPI_CORE_DPHY_IN_9 68
-MX6Q_PAD_RGMII_RD3__MIPI_HSI_CRL_TX_WAK 69
-MX6Q_PAD_RGMII_RD3__ENET_RGMII_RD3 70
-MX6Q_PAD_RGMII_RD3__GPIO_6_29 71
-MX6Q_PAD_RGMII_RD3__MIPI_CORE_DPHY_IN10 72
-MX6Q_PAD_RGMII_RXC__USBOH3_H3_STROBE 73
-MX6Q_PAD_RGMII_RXC__ENET_RGMII_RXC 74
-MX6Q_PAD_RGMII_RXC__GPIO_6_30 75
-MX6Q_PAD_RGMII_RXC__MIPI_CORE_DPHY_IN11 76
-MX6Q_PAD_EIM_A25__WEIM_WEIM_A_25 77
-MX6Q_PAD_EIM_A25__ECSPI4_SS1 78
-MX6Q_PAD_EIM_A25__ECSPI2_RDY 79
-MX6Q_PAD_EIM_A25__IPU1_DI1_PIN12 80
-MX6Q_PAD_EIM_A25__IPU1_DI0_D1_CS 81
-MX6Q_PAD_EIM_A25__GPIO_5_2 82
-MX6Q_PAD_EIM_A25__HDMI_TX_CEC_LINE 83
-MX6Q_PAD_EIM_A25__PL301_PER1_HBURST_0 84
-MX6Q_PAD_EIM_EB2__WEIM_WEIM_EB_2 85
-MX6Q_PAD_EIM_EB2__ECSPI1_SS0 86
-MX6Q_PAD_EIM_EB2__CCM_DI1_EXT_CLK 87
-MX6Q_PAD_EIM_EB2__IPU2_CSI1_D_19 88
-MX6Q_PAD_EIM_EB2__HDMI_TX_DDC_SCL 89
-MX6Q_PAD_EIM_EB2__GPIO_2_30 90
-MX6Q_PAD_EIM_EB2__I2C2_SCL 91
-MX6Q_PAD_EIM_EB2__SRC_BT_CFG_30 92
-MX6Q_PAD_EIM_D16__WEIM_WEIM_D_16 93
-MX6Q_PAD_EIM_D16__ECSPI1_SCLK 94
-MX6Q_PAD_EIM_D16__IPU1_DI0_PIN5 95
-MX6Q_PAD_EIM_D16__IPU2_CSI1_D_18 96
-MX6Q_PAD_EIM_D16__HDMI_TX_DDC_SDA 97
-MX6Q_PAD_EIM_D16__GPIO_3_16 98
-MX6Q_PAD_EIM_D16__I2C2_SDA 99
-MX6Q_PAD_EIM_D17__WEIM_WEIM_D_17 100
-MX6Q_PAD_EIM_D17__ECSPI1_MISO 101
-MX6Q_PAD_EIM_D17__IPU1_DI0_PIN6 102
-MX6Q_PAD_EIM_D17__IPU2_CSI1_PIXCLK 103
-MX6Q_PAD_EIM_D17__DCIC1_DCIC_OUT 104
-MX6Q_PAD_EIM_D17__GPIO_3_17 105
-MX6Q_PAD_EIM_D17__I2C3_SCL 106
-MX6Q_PAD_EIM_D17__PL301_PER1_HBURST_1 107
-MX6Q_PAD_EIM_D18__WEIM_WEIM_D_18 108
-MX6Q_PAD_EIM_D18__ECSPI1_MOSI 109
-MX6Q_PAD_EIM_D18__IPU1_DI0_PIN7 110
-MX6Q_PAD_EIM_D18__IPU2_CSI1_D_17 111
-MX6Q_PAD_EIM_D18__IPU1_DI1_D0_CS 112
-MX6Q_PAD_EIM_D18__GPIO_3_18 113
-MX6Q_PAD_EIM_D18__I2C3_SDA 114
-MX6Q_PAD_EIM_D18__PL301_PER1_HBURST_2 115
-MX6Q_PAD_EIM_D19__WEIM_WEIM_D_19 116
-MX6Q_PAD_EIM_D19__ECSPI1_SS1 117
-MX6Q_PAD_EIM_D19__IPU1_DI0_PIN8 118
-MX6Q_PAD_EIM_D19__IPU2_CSI1_D_16 119
-MX6Q_PAD_EIM_D19__UART1_CTS 120
-MX6Q_PAD_EIM_D19__GPIO_3_19 121
-MX6Q_PAD_EIM_D19__EPIT1_EPITO 122
-MX6Q_PAD_EIM_D19__PL301_PER1_HRESP 123
-MX6Q_PAD_EIM_D20__WEIM_WEIM_D_20 124
-MX6Q_PAD_EIM_D20__ECSPI4_SS0 125
-MX6Q_PAD_EIM_D20__IPU1_DI0_PIN16 126
-MX6Q_PAD_EIM_D20__IPU2_CSI1_D_15 127
-MX6Q_PAD_EIM_D20__UART1_RTS 128
-MX6Q_PAD_EIM_D20__GPIO_3_20 129
-MX6Q_PAD_EIM_D20__EPIT2_EPITO 130
-MX6Q_PAD_EIM_D21__WEIM_WEIM_D_21 131
-MX6Q_PAD_EIM_D21__ECSPI4_SCLK 132
-MX6Q_PAD_EIM_D21__IPU1_DI0_PIN17 133
-MX6Q_PAD_EIM_D21__IPU2_CSI1_D_11 134
-MX6Q_PAD_EIM_D21__USBOH3_USBOTG_OC 135
-MX6Q_PAD_EIM_D21__GPIO_3_21 136
-MX6Q_PAD_EIM_D21__I2C1_SCL 137
-MX6Q_PAD_EIM_D21__SPDIF_IN1 138
-MX6Q_PAD_EIM_D22__WEIM_WEIM_D_22 139
-MX6Q_PAD_EIM_D22__ECSPI4_MISO 140
-MX6Q_PAD_EIM_D22__IPU1_DI0_PIN1 141
-MX6Q_PAD_EIM_D22__IPU2_CSI1_D_10 142
-MX6Q_PAD_EIM_D22__USBOH3_USBOTG_PWR 143
-MX6Q_PAD_EIM_D22__GPIO_3_22 144
-MX6Q_PAD_EIM_D22__SPDIF_OUT1 145
-MX6Q_PAD_EIM_D22__PL301_PER1_HWRITE 146
-MX6Q_PAD_EIM_D23__WEIM_WEIM_D_23 147
-MX6Q_PAD_EIM_D23__IPU1_DI0_D0_CS 148
-MX6Q_PAD_EIM_D23__UART3_CTS 149
-MX6Q_PAD_EIM_D23__UART1_DCD 150
-MX6Q_PAD_EIM_D23__IPU2_CSI1_DATA_EN 151
-MX6Q_PAD_EIM_D23__GPIO_3_23 152
-MX6Q_PAD_EIM_D23__IPU1_DI1_PIN2 153
-MX6Q_PAD_EIM_D23__IPU1_DI1_PIN14 154
-MX6Q_PAD_EIM_EB3__WEIM_WEIM_EB_3 155
-MX6Q_PAD_EIM_EB3__ECSPI4_RDY 156
-MX6Q_PAD_EIM_EB3__UART3_RTS 157
-MX6Q_PAD_EIM_EB3__UART1_RI 158
-MX6Q_PAD_EIM_EB3__IPU2_CSI1_HSYNC 159
-MX6Q_PAD_EIM_EB3__GPIO_2_31 160
-MX6Q_PAD_EIM_EB3__IPU1_DI1_PIN3 161
-MX6Q_PAD_EIM_EB3__SRC_BT_CFG_31 162
-MX6Q_PAD_EIM_D24__WEIM_WEIM_D_24 163
-MX6Q_PAD_EIM_D24__ECSPI4_SS2 164
-MX6Q_PAD_EIM_D24__UART3_TXD 165
-MX6Q_PAD_EIM_D24__ECSPI1_SS2 166
-MX6Q_PAD_EIM_D24__ECSPI2_SS2 167
-MX6Q_PAD_EIM_D24__GPIO_3_24 168
-MX6Q_PAD_EIM_D24__AUDMUX_AUD5_RXFS 169
-MX6Q_PAD_EIM_D24__UART1_DTR 170
-MX6Q_PAD_EIM_D25__WEIM_WEIM_D_25 171
-MX6Q_PAD_EIM_D25__ECSPI4_SS3 172
-MX6Q_PAD_EIM_D25__UART3_RXD 173
-MX6Q_PAD_EIM_D25__ECSPI1_SS3 174
-MX6Q_PAD_EIM_D25__ECSPI2_SS3 175
-MX6Q_PAD_EIM_D25__GPIO_3_25 176
-MX6Q_PAD_EIM_D25__AUDMUX_AUD5_RXC 177
-MX6Q_PAD_EIM_D25__UART1_DSR 178
-MX6Q_PAD_EIM_D26__WEIM_WEIM_D_26 179
-MX6Q_PAD_EIM_D26__IPU1_DI1_PIN11 180
-MX6Q_PAD_EIM_D26__IPU1_CSI0_D_1 181
-MX6Q_PAD_EIM_D26__IPU2_CSI1_D_14 182
-MX6Q_PAD_EIM_D26__UART2_TXD 183
-MX6Q_PAD_EIM_D26__GPIO_3_26 184
-MX6Q_PAD_EIM_D26__IPU1_SISG_2 185
-MX6Q_PAD_EIM_D26__IPU1_DISP1_DAT_22 186
-MX6Q_PAD_EIM_D27__WEIM_WEIM_D_27 187
-MX6Q_PAD_EIM_D27__IPU1_DI1_PIN13 188
-MX6Q_PAD_EIM_D27__IPU1_CSI0_D_0 189
-MX6Q_PAD_EIM_D27__IPU2_CSI1_D_13 190
-MX6Q_PAD_EIM_D27__UART2_RXD 191
-MX6Q_PAD_EIM_D27__GPIO_3_27 192
-MX6Q_PAD_EIM_D27__IPU1_SISG_3 193
-MX6Q_PAD_EIM_D27__IPU1_DISP1_DAT_23 194
-MX6Q_PAD_EIM_D28__WEIM_WEIM_D_28 195
-MX6Q_PAD_EIM_D28__I2C1_SDA 196
-MX6Q_PAD_EIM_D28__ECSPI4_MOSI 197
-MX6Q_PAD_EIM_D28__IPU2_CSI1_D_12 198
-MX6Q_PAD_EIM_D28__UART2_CTS 199
-MX6Q_PAD_EIM_D28__GPIO_3_28 200
-MX6Q_PAD_EIM_D28__IPU1_EXT_TRIG 201
-MX6Q_PAD_EIM_D28__IPU1_DI0_PIN13 202
-MX6Q_PAD_EIM_D29__WEIM_WEIM_D_29 203
-MX6Q_PAD_EIM_D29__IPU1_DI1_PIN15 204
-MX6Q_PAD_EIM_D29__ECSPI4_SS0 205
-MX6Q_PAD_EIM_D29__UART2_RTS 206
-MX6Q_PAD_EIM_D29__GPIO_3_29 207
-MX6Q_PAD_EIM_D29__IPU2_CSI1_VSYNC 208
-MX6Q_PAD_EIM_D29__IPU1_DI0_PIN14 209
-MX6Q_PAD_EIM_D30__WEIM_WEIM_D_30 210
-MX6Q_PAD_EIM_D30__IPU1_DISP1_DAT_21 211
-MX6Q_PAD_EIM_D30__IPU1_DI0_PIN11 212
-MX6Q_PAD_EIM_D30__IPU1_CSI0_D_3 213
-MX6Q_PAD_EIM_D30__UART3_CTS 214
-MX6Q_PAD_EIM_D30__GPIO_3_30 215
-MX6Q_PAD_EIM_D30__USBOH3_USBH1_OC 216
-MX6Q_PAD_EIM_D30__PL301_PER1_HPROT_0 217
-MX6Q_PAD_EIM_D31__WEIM_WEIM_D_31 218
-MX6Q_PAD_EIM_D31__IPU1_DISP1_DAT_20 219
-MX6Q_PAD_EIM_D31__IPU1_DI0_PIN12 220
-MX6Q_PAD_EIM_D31__IPU1_CSI0_D_2 221
-MX6Q_PAD_EIM_D31__UART3_RTS 222
-MX6Q_PAD_EIM_D31__GPIO_3_31 223
-MX6Q_PAD_EIM_D31__USBOH3_USBH1_PWR 224
-MX6Q_PAD_EIM_D31__PL301_PER1_HPROT_1 225
-MX6Q_PAD_EIM_A24__WEIM_WEIM_A_24 226
-MX6Q_PAD_EIM_A24__IPU1_DISP1_DAT_19 227
-MX6Q_PAD_EIM_A24__IPU2_CSI1_D_19 228
-MX6Q_PAD_EIM_A24__IPU2_SISG_2 229
-MX6Q_PAD_EIM_A24__IPU1_SISG_2 230
-MX6Q_PAD_EIM_A24__GPIO_5_4 231
-MX6Q_PAD_EIM_A24__PL301_PER1_HPROT_2 232
-MX6Q_PAD_EIM_A24__SRC_BT_CFG_24 233
-MX6Q_PAD_EIM_A23__WEIM_WEIM_A_23 234
-MX6Q_PAD_EIM_A23__IPU1_DISP1_DAT_18 235
-MX6Q_PAD_EIM_A23__IPU2_CSI1_D_18 236
-MX6Q_PAD_EIM_A23__IPU2_SISG_3 237
-MX6Q_PAD_EIM_A23__IPU1_SISG_3 238
-MX6Q_PAD_EIM_A23__GPIO_6_6 239
-MX6Q_PAD_EIM_A23__PL301_PER1_HPROT_3 240
-MX6Q_PAD_EIM_A23__SRC_BT_CFG_23 241
-MX6Q_PAD_EIM_A22__WEIM_WEIM_A_22 242
-MX6Q_PAD_EIM_A22__IPU1_DISP1_DAT_17 243
-MX6Q_PAD_EIM_A22__IPU2_CSI1_D_17 244
-MX6Q_PAD_EIM_A22__GPIO_2_16 245
-MX6Q_PAD_EIM_A22__TPSMP_HDATA_0 246
-MX6Q_PAD_EIM_A22__SRC_BT_CFG_22 247
-MX6Q_PAD_EIM_A21__WEIM_WEIM_A_21 248
-MX6Q_PAD_EIM_A21__IPU1_DISP1_DAT_16 249
-MX6Q_PAD_EIM_A21__IPU2_CSI1_D_16 250
-MX6Q_PAD_EIM_A21__RESERVED_RESERVED 251
-MX6Q_PAD_EIM_A21__MIPI_CORE_DPHY_OUT_18 252
-MX6Q_PAD_EIM_A21__GPIO_2_17 253
-MX6Q_PAD_EIM_A21__TPSMP_HDATA_1 254
-MX6Q_PAD_EIM_A21__SRC_BT_CFG_21 255
-MX6Q_PAD_EIM_A20__WEIM_WEIM_A_20 256
-MX6Q_PAD_EIM_A20__IPU1_DISP1_DAT_15 257
-MX6Q_PAD_EIM_A20__IPU2_CSI1_D_15 258
-MX6Q_PAD_EIM_A20__RESERVED_RESERVED 259
-MX6Q_PAD_EIM_A20__MIPI_CORE_DPHY_OUT_19 260
-MX6Q_PAD_EIM_A20__GPIO_2_18 261
-MX6Q_PAD_EIM_A20__TPSMP_HDATA_2 262
-MX6Q_PAD_EIM_A20__SRC_BT_CFG_20 263
-MX6Q_PAD_EIM_A19__WEIM_WEIM_A_19 264
-MX6Q_PAD_EIM_A19__IPU1_DISP1_DAT_14 265
-MX6Q_PAD_EIM_A19__IPU2_CSI1_D_14 266
-MX6Q_PAD_EIM_A19__RESERVED_RESERVED 267
-MX6Q_PAD_EIM_A19__MIPI_CORE_DPHY_OUT_20 268
-MX6Q_PAD_EIM_A19__GPIO_2_19 269
-MX6Q_PAD_EIM_A19__TPSMP_HDATA_3 270
-MX6Q_PAD_EIM_A19__SRC_BT_CFG_19 271
-MX6Q_PAD_EIM_A18__WEIM_WEIM_A_18 272
-MX6Q_PAD_EIM_A18__IPU1_DISP1_DAT_13 273
-MX6Q_PAD_EIM_A18__IPU2_CSI1_D_13 274
-MX6Q_PAD_EIM_A18__RESERVED_RESERVED 275
-MX6Q_PAD_EIM_A18__MIPI_CORE_DPHY_OUT_21 276
-MX6Q_PAD_EIM_A18__GPIO_2_20 277
-MX6Q_PAD_EIM_A18__TPSMP_HDATA_4 278
-MX6Q_PAD_EIM_A18__SRC_BT_CFG_18 279
-MX6Q_PAD_EIM_A17__WEIM_WEIM_A_17 280
-MX6Q_PAD_EIM_A17__IPU1_DISP1_DAT_12 281
-MX6Q_PAD_EIM_A17__IPU2_CSI1_D_12 282
-MX6Q_PAD_EIM_A17__RESERVED_RESERVED 283
-MX6Q_PAD_EIM_A17__MIPI_CORE_DPHY_OUT_22 284
-MX6Q_PAD_EIM_A17__GPIO_2_21 285
-MX6Q_PAD_EIM_A17__TPSMP_HDATA_5 286
-MX6Q_PAD_EIM_A17__SRC_BT_CFG_17 287
-MX6Q_PAD_EIM_A16__WEIM_WEIM_A_16 288
-MX6Q_PAD_EIM_A16__IPU1_DI1_DISP_CLK 289
-MX6Q_PAD_EIM_A16__IPU2_CSI1_PIXCLK 290
-MX6Q_PAD_EIM_A16__MIPI_CORE_DPHY_OUT_23 291
-MX6Q_PAD_EIM_A16__GPIO_2_22 292
-MX6Q_PAD_EIM_A16__TPSMP_HDATA_6 293
-MX6Q_PAD_EIM_A16__SRC_BT_CFG_16 294
-MX6Q_PAD_EIM_CS0__WEIM_WEIM_CS_0 295
-MX6Q_PAD_EIM_CS0__IPU1_DI1_PIN5 296
-MX6Q_PAD_EIM_CS0__ECSPI2_SCLK 297
-MX6Q_PAD_EIM_CS0__MIPI_CORE_DPHY_OUT_24 298
-MX6Q_PAD_EIM_CS0__GPIO_2_23 299
-MX6Q_PAD_EIM_CS0__TPSMP_HDATA_7 300
-MX6Q_PAD_EIM_CS1__WEIM_WEIM_CS_1 301
-MX6Q_PAD_EIM_CS1__IPU1_DI1_PIN6 302
-MX6Q_PAD_EIM_CS1__ECSPI2_MOSI 303
-MX6Q_PAD_EIM_CS1__MIPI_CORE_DPHY_OUT_25 304
-MX6Q_PAD_EIM_CS1__GPIO_2_24 305
-MX6Q_PAD_EIM_CS1__TPSMP_HDATA_8 306
-MX6Q_PAD_EIM_OE__WEIM_WEIM_OE 307
-MX6Q_PAD_EIM_OE__IPU1_DI1_PIN7 308
-MX6Q_PAD_EIM_OE__ECSPI2_MISO 309
-MX6Q_PAD_EIM_OE__MIPI_CORE_DPHY_OUT_26 310
-MX6Q_PAD_EIM_OE__GPIO_2_25 311
-MX6Q_PAD_EIM_OE__TPSMP_HDATA_9 312
-MX6Q_PAD_EIM_RW__WEIM_WEIM_RW 313
-MX6Q_PAD_EIM_RW__IPU1_DI1_PIN8 314
-MX6Q_PAD_EIM_RW__ECSPI2_SS0 315
-MX6Q_PAD_EIM_RW__MIPI_CORE_DPHY_OUT_27 316
-MX6Q_PAD_EIM_RW__GPIO_2_26 317
-MX6Q_PAD_EIM_RW__TPSMP_HDATA_10 318
-MX6Q_PAD_EIM_RW__SRC_BT_CFG_29 319
-MX6Q_PAD_EIM_LBA__WEIM_WEIM_LBA 320
-MX6Q_PAD_EIM_LBA__IPU1_DI1_PIN17 321
-MX6Q_PAD_EIM_LBA__ECSPI2_SS1 322
-MX6Q_PAD_EIM_LBA__GPIO_2_27 323
-MX6Q_PAD_EIM_LBA__TPSMP_HDATA_11 324
-MX6Q_PAD_EIM_LBA__SRC_BT_CFG_26 325
-MX6Q_PAD_EIM_EB0__WEIM_WEIM_EB_0 326
-MX6Q_PAD_EIM_EB0__IPU1_DISP1_DAT_11 327
-MX6Q_PAD_EIM_EB0__IPU2_CSI1_D_11 328
-MX6Q_PAD_EIM_EB0__MIPI_CORE_DPHY_OUT_0 329
-MX6Q_PAD_EIM_EB0__CCM_PMIC_RDY 330
-MX6Q_PAD_EIM_EB0__GPIO_2_28 331
-MX6Q_PAD_EIM_EB0__TPSMP_HDATA_12 332
-MX6Q_PAD_EIM_EB0__SRC_BT_CFG_27 333
-MX6Q_PAD_EIM_EB1__WEIM_WEIM_EB_1 334
-MX6Q_PAD_EIM_EB1__IPU1_DISP1_DAT_10 335
-MX6Q_PAD_EIM_EB1__IPU2_CSI1_D_10 336
-MX6Q_PAD_EIM_EB1__MIPI_CORE_DPHY__OUT_1 337
-MX6Q_PAD_EIM_EB1__GPIO_2_29 338
-MX6Q_PAD_EIM_EB1__TPSMP_HDATA_13 339
-MX6Q_PAD_EIM_EB1__SRC_BT_CFG_28 340
-MX6Q_PAD_EIM_DA0__WEIM_WEIM_DA_A_0 341
-MX6Q_PAD_EIM_DA0__IPU1_DISP1_DAT_9 342
-MX6Q_PAD_EIM_DA0__IPU2_CSI1_D_9 343
-MX6Q_PAD_EIM_DA0__MIPI_CORE_DPHY__OUT_2 344
-MX6Q_PAD_EIM_DA0__GPIO_3_0 345
-MX6Q_PAD_EIM_DA0__TPSMP_HDATA_14 346
-MX6Q_PAD_EIM_DA0__SRC_BT_CFG_0 347
-MX6Q_PAD_EIM_DA1__WEIM_WEIM_DA_A_1 348
-MX6Q_PAD_EIM_DA1__IPU1_DISP1_DAT_8 349
-MX6Q_PAD_EIM_DA1__IPU2_CSI1_D_8 350
-MX6Q_PAD_EIM_DA1__MIPI_CORE_DPHY_OUT_3 351
-MX6Q_PAD_EIM_DA1__USBPHY1_TX_LS_MODE 352
-MX6Q_PAD_EIM_DA1__GPIO_3_1 353
-MX6Q_PAD_EIM_DA1__TPSMP_HDATA_15 354
-MX6Q_PAD_EIM_DA1__SRC_BT_CFG_1 355
-MX6Q_PAD_EIM_DA2__WEIM_WEIM_DA_A_2 356
-MX6Q_PAD_EIM_DA2__IPU1_DISP1_DAT_7 357
-MX6Q_PAD_EIM_DA2__IPU2_CSI1_D_7 358
-MX6Q_PAD_EIM_DA2__MIPI_CORE_DPHY_OUT_4 359
-MX6Q_PAD_EIM_DA2__USBPHY1_TX_HS_MODE 360
-MX6Q_PAD_EIM_DA2__GPIO_3_2 361
-MX6Q_PAD_EIM_DA2__TPSMP_HDATA_16 362
-MX6Q_PAD_EIM_DA2__SRC_BT_CFG_2 363
-MX6Q_PAD_EIM_DA3__WEIM_WEIM_DA_A_3 364
-MX6Q_PAD_EIM_DA3__IPU1_DISP1_DAT_6 365
-MX6Q_PAD_EIM_DA3__IPU2_CSI1_D_6 366
-MX6Q_PAD_EIM_DA3__MIPI_CORE_DPHY_OUT_5 367
-MX6Q_PAD_EIM_DA3__USBPHY1_TX_HIZ 368
-MX6Q_PAD_EIM_DA3__GPIO_3_3 369
-MX6Q_PAD_EIM_DA3__TPSMP_HDATA_17 370
-MX6Q_PAD_EIM_DA3__SRC_BT_CFG_3 371
-MX6Q_PAD_EIM_DA4__WEIM_WEIM_DA_A_4 372
-MX6Q_PAD_EIM_DA4__IPU1_DISP1_DAT_5 373
-MX6Q_PAD_EIM_DA4__IPU2_CSI1_D_5 374
-MX6Q_PAD_EIM_DA4__MIPI_CORE_DPHY_OUT_6 375
-MX6Q_PAD_EIM_DA4__ANATOP_USBPHY1_TX_EN 376
-MX6Q_PAD_EIM_DA4__GPIO_3_4 377
-MX6Q_PAD_EIM_DA4__TPSMP_HDATA_18 378
-MX6Q_PAD_EIM_DA4__SRC_BT_CFG_4 379
-MX6Q_PAD_EIM_DA5__WEIM_WEIM_DA_A_5 380
-MX6Q_PAD_EIM_DA5__IPU1_DISP1_DAT_4 381
-MX6Q_PAD_EIM_DA5__IPU2_CSI1_D_4 382
-MX6Q_PAD_EIM_DA5__MIPI_CORE_DPHY_OUT_7 383
-MX6Q_PAD_EIM_DA5__ANATOP_USBPHY1_TX_DP 384
-MX6Q_PAD_EIM_DA5__GPIO_3_5 385
-MX6Q_PAD_EIM_DA5__TPSMP_HDATA_19 386
-MX6Q_PAD_EIM_DA5__SRC_BT_CFG_5 387
-MX6Q_PAD_EIM_DA6__WEIM_WEIM_DA_A_6 388
-MX6Q_PAD_EIM_DA6__IPU1_DISP1_DAT_3 389
-MX6Q_PAD_EIM_DA6__IPU2_CSI1_D_3 390
-MX6Q_PAD_EIM_DA6__MIPI_CORE_DPHY_OUT_8 391
-MX6Q_PAD_EIM_DA6__ANATOP_USBPHY1_TX_DN 392
-MX6Q_PAD_EIM_DA6__GPIO_3_6 393
-MX6Q_PAD_EIM_DA6__TPSMP_HDATA_20 394
-MX6Q_PAD_EIM_DA6__SRC_BT_CFG_6 395
-MX6Q_PAD_EIM_DA7__WEIM_WEIM_DA_A_7 396
-MX6Q_PAD_EIM_DA7__IPU1_DISP1_DAT_2 397
-MX6Q_PAD_EIM_DA7__IPU2_CSI1_D_2 398
-MX6Q_PAD_EIM_DA7__MIPI_CORE_DPHY_OUT_9 399
-MX6Q_PAD_EIM_DA7__GPIO_3_7 400
-MX6Q_PAD_EIM_DA7__TPSMP_HDATA_21 401
-MX6Q_PAD_EIM_DA7__SRC_BT_CFG_7 402
-MX6Q_PAD_EIM_DA8__WEIM_WEIM_DA_A_8 403
-MX6Q_PAD_EIM_DA8__IPU1_DISP1_DAT_1 404
-MX6Q_PAD_EIM_DA8__IPU2_CSI1_D_1 405
-MX6Q_PAD_EIM_DA8__MIPI_CORE_DPHY_OUT_10 406
-MX6Q_PAD_EIM_DA8__GPIO_3_8 407
-MX6Q_PAD_EIM_DA8__TPSMP_HDATA_22 408
-MX6Q_PAD_EIM_DA8__SRC_BT_CFG_8 409
-MX6Q_PAD_EIM_DA9__WEIM_WEIM_DA_A_9 410
-MX6Q_PAD_EIM_DA9__IPU1_DISP1_DAT_0 411
-MX6Q_PAD_EIM_DA9__IPU2_CSI1_D_0 412
-MX6Q_PAD_EIM_DA9__MIPI_CORE_DPHY_OUT_11 413
-MX6Q_PAD_EIM_DA9__GPIO_3_9 414
-MX6Q_PAD_EIM_DA9__TPSMP_HDATA_23 415
-MX6Q_PAD_EIM_DA9__SRC_BT_CFG_9 416
-MX6Q_PAD_EIM_DA10__WEIM_WEIM_DA_A_10 417
-MX6Q_PAD_EIM_DA10__IPU1_DI1_PIN15 418
-MX6Q_PAD_EIM_DA10__IPU2_CSI1_DATA_EN 419
-MX6Q_PAD_EIM_DA10__MIPI_CORE_DPHY_OUT12 420
-MX6Q_PAD_EIM_DA10__GPIO_3_10 421
-MX6Q_PAD_EIM_DA10__TPSMP_HDATA_24 422
-MX6Q_PAD_EIM_DA10__SRC_BT_CFG_10 423
-MX6Q_PAD_EIM_DA11__WEIM_WEIM_DA_A_11 424
-MX6Q_PAD_EIM_DA11__IPU1_DI1_PIN2 425
-MX6Q_PAD_EIM_DA11__IPU2_CSI1_HSYNC 426
-MX6Q_PAD_EIM_DA11__MIPI_CORE_DPHY_OUT13 427
-MX6Q_PAD_EIM_DA11__SDMA_DBG_EVT_CHN_6 428
-MX6Q_PAD_EIM_DA11__GPIO_3_11 429
-MX6Q_PAD_EIM_DA11__TPSMP_HDATA_25 430
-MX6Q_PAD_EIM_DA11__SRC_BT_CFG_11 431
-MX6Q_PAD_EIM_DA12__WEIM_WEIM_DA_A_12 432
-MX6Q_PAD_EIM_DA12__IPU1_DI1_PIN3 433
-MX6Q_PAD_EIM_DA12__IPU2_CSI1_VSYNC 434
-MX6Q_PAD_EIM_DA12__MIPI_CORE_DPHY_OUT14 435
-MX6Q_PAD_EIM_DA12__SDMA_DEBUG_EVT_CHN_3 436
-MX6Q_PAD_EIM_DA12__GPIO_3_12 437
-MX6Q_PAD_EIM_DA12__TPSMP_HDATA_26 438
-MX6Q_PAD_EIM_DA12__SRC_BT_CFG_12 439
-MX6Q_PAD_EIM_DA13__WEIM_WEIM_DA_A_13 440
-MX6Q_PAD_EIM_DA13__IPU1_DI1_D0_CS 441
-MX6Q_PAD_EIM_DA13__CCM_DI1_EXT_CLK 442
-MX6Q_PAD_EIM_DA13__MIPI_CORE_DPHY_OUT15 443
-MX6Q_PAD_EIM_DA13__SDMA_DEBUG_EVT_CHN_4 444
-MX6Q_PAD_EIM_DA13__GPIO_3_13 445
-MX6Q_PAD_EIM_DA13__TPSMP_HDATA_27 446
-MX6Q_PAD_EIM_DA13__SRC_BT_CFG_13 447
-MX6Q_PAD_EIM_DA14__WEIM_WEIM_DA_A_14 448
-MX6Q_PAD_EIM_DA14__IPU1_DI1_D1_CS 449
-MX6Q_PAD_EIM_DA14__CCM_DI0_EXT_CLK 450
-MX6Q_PAD_EIM_DA14__MIPI_CORE_DPHY_OUT16 451
-MX6Q_PAD_EIM_DA14__SDMA_DEBUG_EVT_CHN_5 452
-MX6Q_PAD_EIM_DA14__GPIO_3_14 453
-MX6Q_PAD_EIM_DA14__TPSMP_HDATA_28 454
-MX6Q_PAD_EIM_DA14__SRC_BT_CFG_14 455
-MX6Q_PAD_EIM_DA15__WEIM_WEIM_DA_A_15 456
-MX6Q_PAD_EIM_DA15__IPU1_DI1_PIN1 457
-MX6Q_PAD_EIM_DA15__IPU1_DI1_PIN4 458
-MX6Q_PAD_EIM_DA15__MIPI_CORE_DPHY_OUT17 459
-MX6Q_PAD_EIM_DA15__GPIO_3_15 460
-MX6Q_PAD_EIM_DA15__TPSMP_HDATA_29 461
-MX6Q_PAD_EIM_DA15__SRC_BT_CFG_15 462
-MX6Q_PAD_EIM_WAIT__WEIM_WEIM_WAIT 463
-MX6Q_PAD_EIM_WAIT__WEIM_WEIM_DTACK_B 464
-MX6Q_PAD_EIM_WAIT__GPIO_5_0 465
-MX6Q_PAD_EIM_WAIT__TPSMP_HDATA_30 466
-MX6Q_PAD_EIM_WAIT__SRC_BT_CFG_25 467
-MX6Q_PAD_EIM_BCLK__WEIM_WEIM_BCLK 468
-MX6Q_PAD_EIM_BCLK__IPU1_DI1_PIN16 469
-MX6Q_PAD_EIM_BCLK__GPIO_6_31 470
-MX6Q_PAD_EIM_BCLK__TPSMP_HDATA_31 471
-MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DSP_CLK 472
-MX6Q_PAD_DI0_DISP_CLK__IPU2_DI0_DSP_CLK 473
-MX6Q_PAD_DI0_DISP_CLK__MIPI_CR_DPY_OT28 474
-MX6Q_PAD_DI0_DISP_CLK__SDMA_DBG_CR_STA0 475
-MX6Q_PAD_DI0_DISP_CLK__GPIO_4_16 476
-MX6Q_PAD_DI0_DISP_CLK__MMDC_DEBUG_0 477
-MX6Q_PAD_DI0_PIN15__IPU1_DI0_PIN15 478
-MX6Q_PAD_DI0_PIN15__IPU2_DI0_PIN15 479
-MX6Q_PAD_DI0_PIN15__AUDMUX_AUD6_TXC 480
-MX6Q_PAD_DI0_PIN15__MIPI_CR_DPHY_OUT_29 481
-MX6Q_PAD_DI0_PIN15__SDMA_DBG_CORE_STA_1 482
-MX6Q_PAD_DI0_PIN15__GPIO_4_17 483
-MX6Q_PAD_DI0_PIN15__MMDC_MMDC_DEBUG_1 484
-MX6Q_PAD_DI0_PIN2__IPU1_DI0_PIN2 485
-MX6Q_PAD_DI0_PIN2__IPU2_DI0_PIN2 486
-MX6Q_PAD_DI0_PIN2__AUDMUX_AUD6_TXD 487
-MX6Q_PAD_DI0_PIN2__MIPI_CR_DPHY_OUT_30 488
-MX6Q_PAD_DI0_PIN2__SDMA_DBG_CORE_STA_2 489
-MX6Q_PAD_DI0_PIN2__GPIO_4_18 490
-MX6Q_PAD_DI0_PIN2__MMDC_DEBUG_2 491
-MX6Q_PAD_DI0_PIN2__PL301_PER1_HADDR_9 492
-MX6Q_PAD_DI0_PIN3__IPU1_DI0_PIN3 493
-MX6Q_PAD_DI0_PIN3__IPU2_DI0_PIN3 494
-MX6Q_PAD_DI0_PIN3__AUDMUX_AUD6_TXFS 495
-MX6Q_PAD_DI0_PIN3__MIPI_CORE_DPHY_OUT31 496
-MX6Q_PAD_DI0_PIN3__SDMA_DBG_CORE_STA_3 497
-MX6Q_PAD_DI0_PIN3__GPIO_4_19 498
-MX6Q_PAD_DI0_PIN3__MMDC_MMDC_DEBUG_3 499
-MX6Q_PAD_DI0_PIN3__PL301_PER1_HADDR_10 500
-MX6Q_PAD_DI0_PIN4__IPU1_DI0_PIN4 501
-MX6Q_PAD_DI0_PIN4__IPU2_DI0_PIN4 502
-MX6Q_PAD_DI0_PIN4__AUDMUX_AUD6_RXD 503
-MX6Q_PAD_DI0_PIN4__USDHC1_WP 504
-MX6Q_PAD_DI0_PIN4__SDMA_DEBUG_YIELD 505
-MX6Q_PAD_DI0_PIN4__GPIO_4_20 506
-MX6Q_PAD_DI0_PIN4__MMDC_MMDC_DEBUG_4 507
-MX6Q_PAD_DI0_PIN4__PL301_PER1_HADDR_11 508
-MX6Q_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0 509
-MX6Q_PAD_DISP0_DAT0__IPU2_DISP0_DAT_0 510
-MX6Q_PAD_DISP0_DAT0__ECSPI3_SCLK 511
-MX6Q_PAD_DISP0_DAT0__USDHC1_USDHC_DBG_0 512
-MX6Q_PAD_DISP0_DAT0__SDMA_DBG_CORE_RUN 513
-MX6Q_PAD_DISP0_DAT0__GPIO_4_21 514
-MX6Q_PAD_DISP0_DAT0__MMDC_MMDC_DEBUG_5 515
-MX6Q_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1 516
-MX6Q_PAD_DISP0_DAT1__IPU2_DISP0_DAT_1 517
-MX6Q_PAD_DISP0_DAT1__ECSPI3_MOSI 518
-MX6Q_PAD_DISP0_DAT1__USDHC1_USDHC_DBG_1 519
-MX6Q_PAD_DISP0_DAT1__SDMA_DBG_EVT_CHNSL 520
-MX6Q_PAD_DISP0_DAT1__GPIO_4_22 521
-MX6Q_PAD_DISP0_DAT1__MMDC_DEBUG_6 522
-MX6Q_PAD_DISP0_DAT1__PL301_PER1_HADR_12 523
-MX6Q_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2 524
-MX6Q_PAD_DISP0_DAT2__IPU2_DISP0_DAT_2 525
-MX6Q_PAD_DISP0_DAT2__ECSPI3_MISO 526
-MX6Q_PAD_DISP0_DAT2__USDHC1_USDHC_DBG_2 527
-MX6Q_PAD_DISP0_DAT2__SDMA_DEBUG_MODE 528
-MX6Q_PAD_DISP0_DAT2__GPIO_4_23 529
-MX6Q_PAD_DISP0_DAT2__MMDC_DEBUG_7 530
-MX6Q_PAD_DISP0_DAT2__PL301_PER1_HADR_13 531
-MX6Q_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3 532
-MX6Q_PAD_DISP0_DAT3__IPU2_DISP0_DAT_3 533
-MX6Q_PAD_DISP0_DAT3__ECSPI3_SS0 534
-MX6Q_PAD_DISP0_DAT3__USDHC1_USDHC_DBG_3 535
-MX6Q_PAD_DISP0_DAT3__SDMA_DBG_BUS_ERROR 536
-MX6Q_PAD_DISP0_DAT3__GPIO_4_24 537
-MX6Q_PAD_DISP0_DAT3__MMDC_MMDC_DBG_8 538
-MX6Q_PAD_DISP0_DAT3__PL301_PER1_HADR_14 539
-MX6Q_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4 540
-MX6Q_PAD_DISP0_DAT4__IPU2_DISP0_DAT_4 541
-MX6Q_PAD_DISP0_DAT4__ECSPI3_SS1 542
-MX6Q_PAD_DISP0_DAT4__USDHC1_USDHC_DBG_4 543
-MX6Q_PAD_DISP0_DAT4__SDMA_DEBUG_BUS_RWB 544
-MX6Q_PAD_DISP0_DAT4__GPIO_4_25 545
-MX6Q_PAD_DISP0_DAT4__MMDC_MMDC_DEBUG_9 546
-MX6Q_PAD_DISP0_DAT4__PL301_PER1_HADR_15 547
-MX6Q_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5 548
-MX6Q_PAD_DISP0_DAT5__IPU2_DISP0_DAT_5 549
-MX6Q_PAD_DISP0_DAT5__ECSPI3_SS2 550
-MX6Q_PAD_DISP0_DAT5__AUDMUX_AUD6_RXFS 551
-MX6Q_PAD_DISP0_DAT5__SDMA_DBG_MCH_DMBUS 552
-MX6Q_PAD_DISP0_DAT5__GPIO_4_26 553
-MX6Q_PAD_DISP0_DAT5__MMDC_DEBUG_10 554
-MX6Q_PAD_DISP0_DAT5__PL301_PER1_HADR_16 555
-MX6Q_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6 556
-MX6Q_PAD_DISP0_DAT6__IPU2_DISP0_DAT_6 557
-MX6Q_PAD_DISP0_DAT6__ECSPI3_SS3 558
-MX6Q_PAD_DISP0_DAT6__AUDMUX_AUD6_RXC 559
-MX6Q_PAD_DISP0_DAT6__SDMA_DBG_RTBUF_WRT 560
-MX6Q_PAD_DISP0_DAT6__GPIO_4_27 561
-MX6Q_PAD_DISP0_DAT6__MMDC_DEBUG_11 562
-MX6Q_PAD_DISP0_DAT6__PL301_PER1_HADR_17 563
-MX6Q_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7 564
-MX6Q_PAD_DISP0_DAT7__IPU2_DISP0_DAT_7 565
-MX6Q_PAD_DISP0_DAT7__ECSPI3_RDY 566
-MX6Q_PAD_DISP0_DAT7__USDHC1_USDHC_DBG_5 567
-MX6Q_PAD_DISP0_DAT7__SDMA_DBG_EVT_CHN_0 568
-MX6Q_PAD_DISP0_DAT7__GPIO_4_28 569
-MX6Q_PAD_DISP0_DAT7__MMDC_DEBUG_12 570
-MX6Q_PAD_DISP0_DAT7__PL301_PER1_HADR_18 571
-MX6Q_PAD_DISP0_DAT8__IPU1_DISP0_DAT_8 572
-MX6Q_PAD_DISP0_DAT8__IPU2_DISP0_DAT_8 573
-MX6Q_PAD_DISP0_DAT8__PWM1_PWMO 574
-MX6Q_PAD_DISP0_DAT8__WDOG1_WDOG_B 575
-MX6Q_PAD_DISP0_DAT8__SDMA_DBG_EVT_CHN_1 576
-MX6Q_PAD_DISP0_DAT8__GPIO_4_29 577
-MX6Q_PAD_DISP0_DAT8__MMDC_DEBUG_13 578
-MX6Q_PAD_DISP0_DAT8__PL301_PER1_HADR_19 579
-MX6Q_PAD_DISP0_DAT9__IPU1_DISP0_DAT_9 580
-MX6Q_PAD_DISP0_DAT9__IPU2_DISP0_DAT_9 581
-MX6Q_PAD_DISP0_DAT9__PWM2_PWMO 582
-MX6Q_PAD_DISP0_DAT9__WDOG2_WDOG_B 583
-MX6Q_PAD_DISP0_DAT9__SDMA_DBG_EVT_CHN_2 584
-MX6Q_PAD_DISP0_DAT9__GPIO_4_30 585
-MX6Q_PAD_DISP0_DAT9__MMDC_DEBUG_14 586
-MX6Q_PAD_DISP0_DAT9__PL301_PER1_HADR_20 587
-MX6Q_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10 588
-MX6Q_PAD_DISP0_DAT10__IPU2_DISP0_DAT_10 589
-MX6Q_PAD_DISP0_DAT10__USDHC1_DBG_6 590
-MX6Q_PAD_DISP0_DAT10__SDMA_DBG_EVT_CHN3 591
-MX6Q_PAD_DISP0_DAT10__GPIO_4_31 592
-MX6Q_PAD_DISP0_DAT10__MMDC_DEBUG_15 593
-MX6Q_PAD_DISP0_DAT10__PL301_PER1_HADR21 594
-MX6Q_PAD_DISP0_DAT11__IPU1_DISP0_DAT_11 595
-MX6Q_PAD_DISP0_DAT11__IPU2_DISP0_DAT_11 596
-MX6Q_PAD_DISP0_DAT11__USDHC1_USDHC_DBG7 597
-MX6Q_PAD_DISP0_DAT11__SDMA_DBG_EVT_CHN4 598
-MX6Q_PAD_DISP0_DAT11__GPIO_5_5 599
-MX6Q_PAD_DISP0_DAT11__MMDC_DEBUG_16 600
-MX6Q_PAD_DISP0_DAT11__PL301_PER1_HADR22 601
-MX6Q_PAD_DISP0_DAT12__IPU1_DISP0_DAT_12 602
-MX6Q_PAD_DISP0_DAT12__IPU2_DISP0_DAT_12 603
-MX6Q_PAD_DISP0_DAT12__RESERVED_RESERVED 604
-MX6Q_PAD_DISP0_DAT12__SDMA_DBG_EVT_CHN5 605
-MX6Q_PAD_DISP0_DAT12__GPIO_5_6 606
-MX6Q_PAD_DISP0_DAT12__MMDC_DEBUG_17 607
-MX6Q_PAD_DISP0_DAT12__PL301_PER1_HADR23 608
-MX6Q_PAD_DISP0_DAT13__IPU1_DISP0_DAT_13 609
-MX6Q_PAD_DISP0_DAT13__IPU2_DISP0_DAT_13 610
-MX6Q_PAD_DISP0_DAT13__AUDMUX_AUD5_RXFS 611
-MX6Q_PAD_DISP0_DAT13__SDMA_DBG_EVT_CHN0 612
-MX6Q_PAD_DISP0_DAT13__GPIO_5_7 613
-MX6Q_PAD_DISP0_DAT13__MMDC_DEBUG_18 614
-MX6Q_PAD_DISP0_DAT13__PL301_PER1_HADR24 615
-MX6Q_PAD_DISP0_DAT14__IPU1_DISP0_DAT_14 616
-MX6Q_PAD_DISP0_DAT14__IPU2_DISP0_DAT_14 617
-MX6Q_PAD_DISP0_DAT14__AUDMUX_AUD5_RXC 618
-MX6Q_PAD_DISP0_DAT14__SDMA_DBG_EVT_CHN1 619
-MX6Q_PAD_DISP0_DAT14__GPIO_5_8 620
-MX6Q_PAD_DISP0_DAT14__MMDC_DEBUG_19 621
-MX6Q_PAD_DISP0_DAT15__IPU1_DISP0_DAT_15 622
-MX6Q_PAD_DISP0_DAT15__IPU2_DISP0_DAT_15 623
-MX6Q_PAD_DISP0_DAT15__ECSPI1_SS1 624
-MX6Q_PAD_DISP0_DAT15__ECSPI2_SS1 625
-MX6Q_PAD_DISP0_DAT15__SDMA_DBG_EVT_CHN2 626
-MX6Q_PAD_DISP0_DAT15__GPIO_5_9 627
-MX6Q_PAD_DISP0_DAT15__MMDC_DEBUG_20 628
-MX6Q_PAD_DISP0_DAT15__PL301_PER1_HADR25 629
-MX6Q_PAD_DISP0_DAT16__IPU1_DISP0_DAT_16 630
-MX6Q_PAD_DISP0_DAT16__IPU2_DISP0_DAT_16 631
-MX6Q_PAD_DISP0_DAT16__ECSPI2_MOSI 632
-MX6Q_PAD_DISP0_DAT16__AUDMUX_AUD5_TXC 633
-MX6Q_PAD_DISP0_DAT16__SDMA_EXT_EVENT_0 634
-MX6Q_PAD_DISP0_DAT16__GPIO_5_10 635
-MX6Q_PAD_DISP0_DAT16__MMDC_DEBUG_21 636
-MX6Q_PAD_DISP0_DAT16__PL301_PER1_HADR26 637
-MX6Q_PAD_DISP0_DAT17__IPU1_DISP0_DAT_17 638
-MX6Q_PAD_DISP0_DAT17__IPU2_DISP0_DAT_17 639
-MX6Q_PAD_DISP0_DAT17__ECSPI2_MISO 640
-MX6Q_PAD_DISP0_DAT17__AUDMUX_AUD5_TXD 641
-MX6Q_PAD_DISP0_DAT17__SDMA_EXT_EVENT_1 642
-MX6Q_PAD_DISP0_DAT17__GPIO_5_11 643
-MX6Q_PAD_DISP0_DAT17__MMDC_DEBUG_22 644
-MX6Q_PAD_DISP0_DAT17__PL301_PER1_HADR27 645
-MX6Q_PAD_DISP0_DAT18__IPU1_DISP0_DAT_18 646
-MX6Q_PAD_DISP0_DAT18__IPU2_DISP0_DAT_18 647
-MX6Q_PAD_DISP0_DAT18__ECSPI2_SS0 648
-MX6Q_PAD_DISP0_DAT18__AUDMUX_AUD5_TXFS 649
-MX6Q_PAD_DISP0_DAT18__AUDMUX_AUD4_RXFS 650
-MX6Q_PAD_DISP0_DAT18__GPIO_5_12 651
-MX6Q_PAD_DISP0_DAT18__MMDC_DEBUG_23 652
-MX6Q_PAD_DISP0_DAT18__WEIM_WEIM_CS_2 653
-MX6Q_PAD_DISP0_DAT19__IPU1_DISP0_DAT_19 654
-MX6Q_PAD_DISP0_DAT19__IPU2_DISP0_DAT_19 655
-MX6Q_PAD_DISP0_DAT19__ECSPI2_SCLK 656
-MX6Q_PAD_DISP0_DAT19__AUDMUX_AUD5_RXD 657
-MX6Q_PAD_DISP0_DAT19__AUDMUX_AUD4_RXC 658
-MX6Q_PAD_DISP0_DAT19__GPIO_5_13 659
-MX6Q_PAD_DISP0_DAT19__MMDC_DEBUG_24 660
-MX6Q_PAD_DISP0_DAT19__WEIM_WEIM_CS_3 661
-MX6Q_PAD_DISP0_DAT20__IPU1_DISP0_DAT_20 662
-MX6Q_PAD_DISP0_DAT20__IPU2_DISP0_DAT_20 663
-MX6Q_PAD_DISP0_DAT20__ECSPI1_SCLK 664
-MX6Q_PAD_DISP0_DAT20__AUDMUX_AUD4_TXC 665
-MX6Q_PAD_DISP0_DAT20__SDMA_DBG_EVT_CHN7 666
-MX6Q_PAD_DISP0_DAT20__GPIO_5_14 667
-MX6Q_PAD_DISP0_DAT20__MMDC_DEBUG_25 668
-MX6Q_PAD_DISP0_DAT20__PL301_PER1_HADR28 669
-MX6Q_PAD_DISP0_DAT21__IPU1_DISP0_DAT_21 670
-MX6Q_PAD_DISP0_DAT21__IPU2_DISP0_DAT_21 671
-MX6Q_PAD_DISP0_DAT21__ECSPI1_MOSI 672
-MX6Q_PAD_DISP0_DAT21__AUDMUX_AUD4_TXD 673
-MX6Q_PAD_DISP0_DAT21__SDMA_DBG_BUS_DEV0 674
-MX6Q_PAD_DISP0_DAT21__GPIO_5_15 675
-MX6Q_PAD_DISP0_DAT21__MMDC_DEBUG_26 676
-MX6Q_PAD_DISP0_DAT21__PL301_PER1_HADR29 677
-MX6Q_PAD_DISP0_DAT22__IPU1_DISP0_DAT_22 678
-MX6Q_PAD_DISP0_DAT22__IPU2_DISP0_DAT_22 679
-MX6Q_PAD_DISP0_DAT22__ECSPI1_MISO 680
-MX6Q_PAD_DISP0_DAT22__AUDMUX_AUD4_TXFS 681
-MX6Q_PAD_DISP0_DAT22__SDMA_DBG_BUS_DEV1 682
-MX6Q_PAD_DISP0_DAT22__GPIO_5_16 683
-MX6Q_PAD_DISP0_DAT22__MMDC_DEBUG_27 684
-MX6Q_PAD_DISP0_DAT22__PL301_PER1_HADR30 685
-MX6Q_PAD_DISP0_DAT23__IPU1_DISP0_DAT_23 686
-MX6Q_PAD_DISP0_DAT23__IPU2_DISP0_DAT_23 687
-MX6Q_PAD_DISP0_DAT23__ECSPI1_SS0 688
-MX6Q_PAD_DISP0_DAT23__AUDMUX_AUD4_RXD 689
-MX6Q_PAD_DISP0_DAT23__SDMA_DBG_BUS_DEV2 690
-MX6Q_PAD_DISP0_DAT23__GPIO_5_17 691
-MX6Q_PAD_DISP0_DAT23__MMDC_DEBUG_28 692
-MX6Q_PAD_DISP0_DAT23__PL301_PER1_HADR31 693
-MX6Q_PAD_ENET_MDIO__RESERVED_RESERVED 694
-MX6Q_PAD_ENET_MDIO__ENET_MDIO 695
-MX6Q_PAD_ENET_MDIO__ESAI1_SCKR 696
-MX6Q_PAD_ENET_MDIO__SDMA_DEBUG_BUS_DEV3 697
-MX6Q_PAD_ENET_MDIO__ENET_1588_EVT1_OUT 698
-MX6Q_PAD_ENET_MDIO__GPIO_1_22 699
-MX6Q_PAD_ENET_MDIO__SPDIF_PLOCK 700
-MX6Q_PAD_ENET_REF_CLK__RESERVED_RSRVED 701
-MX6Q_PAD_ENET_REF_CLK__ENET_TX_CLK 702
-MX6Q_PAD_ENET_REF_CLK__ESAI1_FSR 703
-MX6Q_PAD_ENET_REF_CLK__SDMA_DBGBUS_DEV4 704
-MX6Q_PAD_ENET_REF_CLK__GPIO_1_23 705
-MX6Q_PAD_ENET_REF_CLK__SPDIF_SRCLK 706
-MX6Q_PAD_ENET_REF_CLK__USBPHY1_RX_SQH 707
-MX6Q_PAD_ENET_RX_ER__ENET_RX_ER 708
-MX6Q_PAD_ENET_RX_ER__ESAI1_HCKR 709
-MX6Q_PAD_ENET_RX_ER__SPDIF_IN1 710
-MX6Q_PAD_ENET_RX_ER__ENET_1588_EVT2_OUT 711
-MX6Q_PAD_ENET_RX_ER__GPIO_1_24 712
-MX6Q_PAD_ENET_RX_ER__PHY_TDI 713
-MX6Q_PAD_ENET_RX_ER__USBPHY1_RX_HS_RXD 714
-MX6Q_PAD_ENET_CRS_DV__RESERVED_RSRVED 715
-MX6Q_PAD_ENET_CRS_DV__ENET_RX_EN 716
-MX6Q_PAD_ENET_CRS_DV__ESAI1_SCKT 717
-MX6Q_PAD_ENET_CRS_DV__SPDIF_EXTCLK 718
-MX6Q_PAD_ENET_CRS_DV__GPIO_1_25 719
-MX6Q_PAD_ENET_CRS_DV__PHY_TDO 720
-MX6Q_PAD_ENET_CRS_DV__USBPHY1_RX_FS_RXD 721
-MX6Q_PAD_ENET_RXD1__MLB_MLBSIG 722
-MX6Q_PAD_ENET_RXD1__ENET_RDATA_1 723
-MX6Q_PAD_ENET_RXD1__ESAI1_FST 724
-MX6Q_PAD_ENET_RXD1__ENET_1588_EVT3_OUT 725
-MX6Q_PAD_ENET_RXD1__GPIO_1_26 726
-MX6Q_PAD_ENET_RXD1__PHY_TCK 727
-MX6Q_PAD_ENET_RXD1__USBPHY1_RX_DISCON 728
-MX6Q_PAD_ENET_RXD0__OSC32K_32K_OUT 729
-MX6Q_PAD_ENET_RXD0__ENET_RDATA_0 730
-MX6Q_PAD_ENET_RXD0__ESAI1_HCKT 731
-MX6Q_PAD_ENET_RXD0__SPDIF_OUT1 732
-MX6Q_PAD_ENET_RXD0__GPIO_1_27 733
-MX6Q_PAD_ENET_RXD0__PHY_TMS 734
-MX6Q_PAD_ENET_RXD0__USBPHY1_PLL_CK20DIV 735
-MX6Q_PAD_ENET_TX_EN__RESERVED_RSRVED 736
-MX6Q_PAD_ENET_TX_EN__ENET_TX_EN 737
-MX6Q_PAD_ENET_TX_EN__ESAI1_TX3_RX2 738
-MX6Q_PAD_ENET_TX_EN__GPIO_1_28 739
-MX6Q_PAD_ENET_TX_EN__SATA_PHY_TDI 740
-MX6Q_PAD_ENET_TX_EN__USBPHY2_RX_SQH 741
-MX6Q_PAD_ENET_TXD1__MLB_MLBCLK 742
-MX6Q_PAD_ENET_TXD1__ENET_TDATA_1 743
-MX6Q_PAD_ENET_TXD1__ESAI1_TX2_RX3 744
-MX6Q_PAD_ENET_TXD1__ENET_1588_EVENT0_IN 745
-MX6Q_PAD_ENET_TXD1__GPIO_1_29 746
-MX6Q_PAD_ENET_TXD1__SATA_PHY_TDO 747
-MX6Q_PAD_ENET_TXD1__USBPHY2_RX_HS_RXD 748
-MX6Q_PAD_ENET_TXD0__RESERVED_RSRVED 749
-MX6Q_PAD_ENET_TXD0__ENET_TDATA_0 750
-MX6Q_PAD_ENET_TXD0__ESAI1_TX4_RX1 751
-MX6Q_PAD_ENET_TXD0__GPIO_1_30 752
-MX6Q_PAD_ENET_TXD0__SATA_PHY_TCK 753
-MX6Q_PAD_ENET_TXD0__USBPHY2_RX_FS_RXD 754
-MX6Q_PAD_ENET_MDC__MLB_MLBDAT 755
-MX6Q_PAD_ENET_MDC__ENET_MDC 756
-MX6Q_PAD_ENET_MDC__ESAI1_TX5_RX0 757
-MX6Q_PAD_ENET_MDC__ENET_1588_EVENT1_IN 758
-MX6Q_PAD_ENET_MDC__GPIO_1_31 759
-MX6Q_PAD_ENET_MDC__SATA_PHY_TMS 760
-MX6Q_PAD_ENET_MDC__USBPHY2_RX_DISCON 761
-MX6Q_PAD_DRAM_D40__MMDC_DRAM_D_40 762
-MX6Q_PAD_DRAM_D41__MMDC_DRAM_D_41 763
-MX6Q_PAD_DRAM_D42__MMDC_DRAM_D_42 764
-MX6Q_PAD_DRAM_D43__MMDC_DRAM_D_43 765
-MX6Q_PAD_DRAM_D44__MMDC_DRAM_D_44 766
-MX6Q_PAD_DRAM_D45__MMDC_DRAM_D_45 767
-MX6Q_PAD_DRAM_D46__MMDC_DRAM_D_46 768
-MX6Q_PAD_DRAM_D47__MMDC_DRAM_D_47 769
-MX6Q_PAD_DRAM_SDQS5__MMDC_DRAM_SDQS_5 770
-MX6Q_PAD_DRAM_DQM5__MMDC_DRAM_DQM_5 771
-MX6Q_PAD_DRAM_D32__MMDC_DRAM_D_32 772
-MX6Q_PAD_DRAM_D33__MMDC_DRAM_D_33 773
-MX6Q_PAD_DRAM_D34__MMDC_DRAM_D_34 774
-MX6Q_PAD_DRAM_D35__MMDC_DRAM_D_35 775
-MX6Q_PAD_DRAM_D36__MMDC_DRAM_D_36 776
-MX6Q_PAD_DRAM_D37__MMDC_DRAM_D_37 777
-MX6Q_PAD_DRAM_D38__MMDC_DRAM_D_38 778
-MX6Q_PAD_DRAM_D39__MMDC_DRAM_D_39 779
-MX6Q_PAD_DRAM_DQM4__MMDC_DRAM_DQM_4 780
-MX6Q_PAD_DRAM_SDQS4__MMDC_DRAM_SDQS_4 781
-MX6Q_PAD_DRAM_D24__MMDC_DRAM_D_24 782
-MX6Q_PAD_DRAM_D25__MMDC_DRAM_D_25 783
-MX6Q_PAD_DRAM_D26__MMDC_DRAM_D_26 784
-MX6Q_PAD_DRAM_D27__MMDC_DRAM_D_27 785
-MX6Q_PAD_DRAM_D28__MMDC_DRAM_D_28 786
-MX6Q_PAD_DRAM_D29__MMDC_DRAM_D_29 787
-MX6Q_PAD_DRAM_SDQS3__MMDC_DRAM_SDQS_3 788
-MX6Q_PAD_DRAM_D30__MMDC_DRAM_D_30 789
-MX6Q_PAD_DRAM_D31__MMDC_DRAM_D_31 790
-MX6Q_PAD_DRAM_DQM3__MMDC_DRAM_DQM_3 791
-MX6Q_PAD_DRAM_D16__MMDC_DRAM_D_16 792
-MX6Q_PAD_DRAM_D17__MMDC_DRAM_D_17 793
-MX6Q_PAD_DRAM_D18__MMDC_DRAM_D_18 794
-MX6Q_PAD_DRAM_D19__MMDC_DRAM_D_19 795
-MX6Q_PAD_DRAM_D20__MMDC_DRAM_D_20 796
-MX6Q_PAD_DRAM_D21__MMDC_DRAM_D_21 797
-MX6Q_PAD_DRAM_D22__MMDC_DRAM_D_22 798
-MX6Q_PAD_DRAM_SDQS2__MMDC_DRAM_SDQS_2 799
-MX6Q_PAD_DRAM_D23__MMDC_DRAM_D_23 800
-MX6Q_PAD_DRAM_DQM2__MMDC_DRAM_DQM_2 801
-MX6Q_PAD_DRAM_A0__MMDC_DRAM_A_0 802
-MX6Q_PAD_DRAM_A1__MMDC_DRAM_A_1 803
-MX6Q_PAD_DRAM_A2__MMDC_DRAM_A_2 804
-MX6Q_PAD_DRAM_A3__MMDC_DRAM_A_3 805
-MX6Q_PAD_DRAM_A4__MMDC_DRAM_A_4 806
-MX6Q_PAD_DRAM_A5__MMDC_DRAM_A_5 807
-MX6Q_PAD_DRAM_A6__MMDC_DRAM_A_6 808
-MX6Q_PAD_DRAM_A7__MMDC_DRAM_A_7 809
-MX6Q_PAD_DRAM_A8__MMDC_DRAM_A_8 810
-MX6Q_PAD_DRAM_A9__MMDC_DRAM_A_9 811
-MX6Q_PAD_DRAM_A10__MMDC_DRAM_A_10 812
-MX6Q_PAD_DRAM_A11__MMDC_DRAM_A_11 813
-MX6Q_PAD_DRAM_A12__MMDC_DRAM_A_12 814
-MX6Q_PAD_DRAM_A13__MMDC_DRAM_A_13 815
-MX6Q_PAD_DRAM_A14__MMDC_DRAM_A_14 816
-MX6Q_PAD_DRAM_A15__MMDC_DRAM_A_15 817
-MX6Q_PAD_DRAM_CAS__MMDC_DRAM_CAS 818
-MX6Q_PAD_DRAM_CS0__MMDC_DRAM_CS_0 819
-MX6Q_PAD_DRAM_CS1__MMDC_DRAM_CS_1 820
-MX6Q_PAD_DRAM_RAS__MMDC_DRAM_RAS 821
-MX6Q_PAD_DRAM_RESET__MMDC_DRAM_RESET 822
-MX6Q_PAD_DRAM_SDBA0__MMDC_DRAM_SDBA_0 823
-MX6Q_PAD_DRAM_SDBA1__MMDC_DRAM_SDBA_1 824
-MX6Q_PAD_DRAM_SDCLK_0__MMDC_DRAM_SDCLK0 825
-MX6Q_PAD_DRAM_SDBA2__MMDC_DRAM_SDBA_2 826
-MX6Q_PAD_DRAM_SDCKE0__MMDC_DRAM_SDCKE_0 827
-MX6Q_PAD_DRAM_SDCLK_1__MMDC_DRAM_SDCLK1 828
-MX6Q_PAD_DRAM_SDCKE1__MMDC_DRAM_SDCKE_1 829
-MX6Q_PAD_DRAM_SDODT0__MMDC_DRAM_ODT_0 830
-MX6Q_PAD_DRAM_SDODT1__MMDC_DRAM_ODT_1 831
-MX6Q_PAD_DRAM_SDWE__MMDC_DRAM_SDWE 832
-MX6Q_PAD_DRAM_D0__MMDC_DRAM_D_0 833
-MX6Q_PAD_DRAM_D1__MMDC_DRAM_D_1 834
-MX6Q_PAD_DRAM_D2__MMDC_DRAM_D_2 835
-MX6Q_PAD_DRAM_D3__MMDC_DRAM_D_3 836
-MX6Q_PAD_DRAM_D4__MMDC_DRAM_D_4 837
-MX6Q_PAD_DRAM_D5__MMDC_DRAM_D_5 838
-MX6Q_PAD_DRAM_SDQS0__MMDC_DRAM_SDQS_0 839
-MX6Q_PAD_DRAM_D6__MMDC_DRAM_D_6 840
-MX6Q_PAD_DRAM_D7__MMDC_DRAM_D_7 841
-MX6Q_PAD_DRAM_DQM0__MMDC_DRAM_DQM_0 842
-MX6Q_PAD_DRAM_D8__MMDC_DRAM_D_8 843
-MX6Q_PAD_DRAM_D9__MMDC_DRAM_D_9 844
-MX6Q_PAD_DRAM_D10__MMDC_DRAM_D_10 845
-MX6Q_PAD_DRAM_D11__MMDC_DRAM_D_11 846
-MX6Q_PAD_DRAM_D12__MMDC_DRAM_D_12 847
-MX6Q_PAD_DRAM_D13__MMDC_DRAM_D_13 848
-MX6Q_PAD_DRAM_D14__MMDC_DRAM_D_14 849
-MX6Q_PAD_DRAM_SDQS1__MMDC_DRAM_SDQS_1 850
-MX6Q_PAD_DRAM_D15__MMDC_DRAM_D_15 851
-MX6Q_PAD_DRAM_DQM1__MMDC_DRAM_DQM_1 852
-MX6Q_PAD_DRAM_D48__MMDC_DRAM_D_48 853
-MX6Q_PAD_DRAM_D49__MMDC_DRAM_D_49 854
-MX6Q_PAD_DRAM_D50__MMDC_DRAM_D_50 855
-MX6Q_PAD_DRAM_D51__MMDC_DRAM_D_51 856
-MX6Q_PAD_DRAM_D52__MMDC_DRAM_D_52 857
-MX6Q_PAD_DRAM_D53__MMDC_DRAM_D_53 858
-MX6Q_PAD_DRAM_D54__MMDC_DRAM_D_54 859
-MX6Q_PAD_DRAM_D55__MMDC_DRAM_D_55 860
-MX6Q_PAD_DRAM_SDQS6__MMDC_DRAM_SDQS_6 861
-MX6Q_PAD_DRAM_DQM6__MMDC_DRAM_DQM_6 862
-MX6Q_PAD_DRAM_D56__MMDC_DRAM_D_56 863
-MX6Q_PAD_DRAM_SDQS7__MMDC_DRAM_SDQS_7 864
-MX6Q_PAD_DRAM_D57__MMDC_DRAM_D_57 865
-MX6Q_PAD_DRAM_D58__MMDC_DRAM_D_58 866
-MX6Q_PAD_DRAM_D59__MMDC_DRAM_D_59 867
-MX6Q_PAD_DRAM_D60__MMDC_DRAM_D_60 868
-MX6Q_PAD_DRAM_DQM7__MMDC_DRAM_DQM_7 869
-MX6Q_PAD_DRAM_D61__MMDC_DRAM_D_61 870
-MX6Q_PAD_DRAM_D62__MMDC_DRAM_D_62 871
-MX6Q_PAD_DRAM_D63__MMDC_DRAM_D_63 872
-MX6Q_PAD_KEY_COL0__ECSPI1_SCLK 873
-MX6Q_PAD_KEY_COL0__ENET_RDATA_3 874
-MX6Q_PAD_KEY_COL0__AUDMUX_AUD5_TXC 875
-MX6Q_PAD_KEY_COL0__KPP_COL_0 876
-MX6Q_PAD_KEY_COL0__UART4_TXD 877
-MX6Q_PAD_KEY_COL0__GPIO_4_6 878
-MX6Q_PAD_KEY_COL0__DCIC1_DCIC_OUT 879
-MX6Q_PAD_KEY_COL0__SRC_ANY_PU_RST 880
-MX6Q_PAD_KEY_ROW0__ECSPI1_MOSI 881
-MX6Q_PAD_KEY_ROW0__ENET_TDATA_3 882
-MX6Q_PAD_KEY_ROW0__AUDMUX_AUD5_TXD 883
-MX6Q_PAD_KEY_ROW0__KPP_ROW_0 884
-MX6Q_PAD_KEY_ROW0__UART4_RXD 885
-MX6Q_PAD_KEY_ROW0__GPIO_4_7 886
-MX6Q_PAD_KEY_ROW0__DCIC2_DCIC_OUT 887
-MX6Q_PAD_KEY_ROW0__PL301_PER1_HADR_0 888
-MX6Q_PAD_KEY_COL1__ECSPI1_MISO 889
-MX6Q_PAD_KEY_COL1__ENET_MDIO 890
-MX6Q_PAD_KEY_COL1__AUDMUX_AUD5_TXFS 891
-MX6Q_PAD_KEY_COL1__KPP_COL_1 892
-MX6Q_PAD_KEY_COL1__UART5_TXD 893
-MX6Q_PAD_KEY_COL1__GPIO_4_8 894
-MX6Q_PAD_KEY_COL1__USDHC1_VSELECT 895
-MX6Q_PAD_KEY_COL1__PL301MX_PER1_HADR_1 896
-MX6Q_PAD_KEY_ROW1__ECSPI1_SS0 897
-MX6Q_PAD_KEY_ROW1__ENET_COL 898
-MX6Q_PAD_KEY_ROW1__AUDMUX_AUD5_RXD 899
-MX6Q_PAD_KEY_ROW1__KPP_ROW_1 900
-MX6Q_PAD_KEY_ROW1__UART5_RXD 901
-MX6Q_PAD_KEY_ROW1__GPIO_4_9 902
-MX6Q_PAD_KEY_ROW1__USDHC2_VSELECT 903
-MX6Q_PAD_KEY_ROW1__PL301_PER1_HADDR_2 904
-MX6Q_PAD_KEY_COL2__ECSPI1_SS1 905
-MX6Q_PAD_KEY_COL2__ENET_RDATA_2 906
-MX6Q_PAD_KEY_COL2__CAN1_TXCAN 907
-MX6Q_PAD_KEY_COL2__KPP_COL_2 908
-MX6Q_PAD_KEY_COL2__ENET_MDC 909
-MX6Q_PAD_KEY_COL2__GPIO_4_10 910
-MX6Q_PAD_KEY_COL2__USBOH3_H1_PWRCTL_WKP 911
-MX6Q_PAD_KEY_COL2__PL301_PER1_HADDR_3 912
-MX6Q_PAD_KEY_ROW2__ECSPI1_SS2 913
-MX6Q_PAD_KEY_ROW2__ENET_TDATA_2 914
-MX6Q_PAD_KEY_ROW2__CAN1_RXCAN 915
-MX6Q_PAD_KEY_ROW2__KPP_ROW_2 916
-MX6Q_PAD_KEY_ROW2__USDHC2_VSELECT 917
-MX6Q_PAD_KEY_ROW2__GPIO_4_11 918
-MX6Q_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 919
-MX6Q_PAD_KEY_ROW2__PL301_PER1_HADR_4 920
-MX6Q_PAD_KEY_COL3__ECSPI1_SS3 921
-MX6Q_PAD_KEY_COL3__ENET_CRS 922
-MX6Q_PAD_KEY_COL3__HDMI_TX_DDC_SCL 923
-MX6Q_PAD_KEY_COL3__KPP_COL_3 924
-MX6Q_PAD_KEY_COL3__I2C2_SCL 925
-MX6Q_PAD_KEY_COL3__GPIO_4_12 926
-MX6Q_PAD_KEY_COL3__SPDIF_IN1 927
-MX6Q_PAD_KEY_COL3__PL301_PER1_HADR_5 928
-MX6Q_PAD_KEY_ROW3__OSC32K_32K_OUT 929
-MX6Q_PAD_KEY_ROW3__ASRC_ASRC_EXT_CLK 930
-MX6Q_PAD_KEY_ROW3__HDMI_TX_DDC_SDA 931
-MX6Q_PAD_KEY_ROW3__KPP_ROW_3 932
-MX6Q_PAD_KEY_ROW3__I2C2_SDA 933
-MX6Q_PAD_KEY_ROW3__GPIO_4_13 934
-MX6Q_PAD_KEY_ROW3__USDHC1_VSELECT 935
-MX6Q_PAD_KEY_ROW3__PL301_PER1_HADR_6 936
-MX6Q_PAD_KEY_COL4__CAN2_TXCAN 937
-MX6Q_PAD_KEY_COL4__IPU1_SISG_4 938
-MX6Q_PAD_KEY_COL4__USBOH3_USBOTG_OC 939
-MX6Q_PAD_KEY_COL4__KPP_COL_4 940
-MX6Q_PAD_KEY_COL4__UART5_RTS 941
-MX6Q_PAD_KEY_COL4__GPIO_4_14 942
-MX6Q_PAD_KEY_COL4__MMDC_DEBUG_49 943
-MX6Q_PAD_KEY_COL4__PL301_PER1_HADDR_7 944
-MX6Q_PAD_KEY_ROW4__CAN2_RXCAN 945
-MX6Q_PAD_KEY_ROW4__IPU1_SISG_5 946
-MX6Q_PAD_KEY_ROW4__USBOH3_USBOTG_PWR 947
-MX6Q_PAD_KEY_ROW4__KPP_ROW_4 948
-MX6Q_PAD_KEY_ROW4__UART5_CTS 949
-MX6Q_PAD_KEY_ROW4__GPIO_4_15 950
-MX6Q_PAD_KEY_ROW4__MMDC_DEBUG_50 951
-MX6Q_PAD_KEY_ROW4__PL301_PER1_HADR_8 952
-MX6Q_PAD_GPIO_0__CCM_CLKO 953
-MX6Q_PAD_GPIO_0__KPP_COL_5 954
-MX6Q_PAD_GPIO_0__ASRC_ASRC_EXT_CLK 955
-MX6Q_PAD_GPIO_0__EPIT1_EPITO 956
-MX6Q_PAD_GPIO_0__GPIO_1_0 957
-MX6Q_PAD_GPIO_0__USBOH3_USBH1_PWR 958
-MX6Q_PAD_GPIO_0__SNVS_HP_WRAP_SNVS_VIO5 959
-MX6Q_PAD_GPIO_1__ESAI1_SCKR 960
-MX6Q_PAD_GPIO_1__WDOG2_WDOG_B 961
-MX6Q_PAD_GPIO_1__KPP_ROW_5 962
-MX6Q_PAD_GPIO_1__PWM2_PWMO 963
-MX6Q_PAD_GPIO_1__GPIO_1_1 964
-MX6Q_PAD_GPIO_1__USDHC1_CD 965
-MX6Q_PAD_GPIO_1__SRC_TESTER_ACK 966
-MX6Q_PAD_GPIO_9__ESAI1_FSR 967
-MX6Q_PAD_GPIO_9__WDOG1_WDOG_B 968
-MX6Q_PAD_GPIO_9__KPP_COL_6 969
-MX6Q_PAD_GPIO_9__CCM_REF_EN_B 970
-MX6Q_PAD_GPIO_9__PWM1_PWMO 971
-MX6Q_PAD_GPIO_9__GPIO_1_9 972
-MX6Q_PAD_GPIO_9__USDHC1_WP 973
-MX6Q_PAD_GPIO_9__SRC_EARLY_RST 974
-MX6Q_PAD_GPIO_3__ESAI1_HCKR 975
-MX6Q_PAD_GPIO_3__OBSERVE_MUX_INT_OUT0 976
-MX6Q_PAD_GPIO_3__I2C3_SCL 977
-MX6Q_PAD_GPIO_3__ANATOP_24M_OUT 978
-MX6Q_PAD_GPIO_3__CCM_CLKO2 979
-MX6Q_PAD_GPIO_3__GPIO_1_3 980
-MX6Q_PAD_GPIO_3__USBOH3_USBH1_OC 981
-MX6Q_PAD_GPIO_3__MLB_MLBCLK 982
-MX6Q_PAD_GPIO_6__ESAI1_SCKT 983
-MX6Q_PAD_GPIO_6__OBSERVE_MUX_INT_OUT1 984
-MX6Q_PAD_GPIO_6__I2C3_SDA 985
-MX6Q_PAD_GPIO_6__CCM_CCM_OUT_0 986
-MX6Q_PAD_GPIO_6__CSU_CSU_INT_DEB 987
-MX6Q_PAD_GPIO_6__GPIO_1_6 988
-MX6Q_PAD_GPIO_6__USDHC2_LCTL 989
-MX6Q_PAD_GPIO_6__MLB_MLBSIG 990
-MX6Q_PAD_GPIO_2__ESAI1_FST 991
-MX6Q_PAD_GPIO_2__OBSERVE_MUX_INT_OUT2 992
-MX6Q_PAD_GPIO_2__KPP_ROW_6 993
-MX6Q_PAD_GPIO_2__CCM_CCM_OUT_1 994
-MX6Q_PAD_GPIO_2__CSU_CSU_ALARM_AUT_0 995
-MX6Q_PAD_GPIO_2__GPIO_1_2 996
-MX6Q_PAD_GPIO_2__USDHC2_WP 997
-MX6Q_PAD_GPIO_2__MLB_MLBDAT 998
-MX6Q_PAD_GPIO_4__ESAI1_HCKT 999
-MX6Q_PAD_GPIO_4__OBSERVE_MUX_INT_OUT3 1000
-MX6Q_PAD_GPIO_4__KPP_COL_7 1001
-MX6Q_PAD_GPIO_4__CCM_CCM_OUT_2 1002
-MX6Q_PAD_GPIO_4__CSU_CSU_ALARM_AUT_1 1003
-MX6Q_PAD_GPIO_4__GPIO_1_4 1004
-MX6Q_PAD_GPIO_4__USDHC2_CD 1005
-MX6Q_PAD_GPIO_4__OCOTP_CRL_WRAR_FUSE_LA 1006
-MX6Q_PAD_GPIO_5__ESAI1_TX2_RX3 1007
-MX6Q_PAD_GPIO_5__OBSERVE_MUX_INT_OUT4 1008
-MX6Q_PAD_GPIO_5__KPP_ROW_7 1009
-MX6Q_PAD_GPIO_5__CCM_CLKO 1010
-MX6Q_PAD_GPIO_5__CSU_CSU_ALARM_AUT_2 1011
-MX6Q_PAD_GPIO_5__GPIO_1_5 1012
-MX6Q_PAD_GPIO_5__I2C3_SCL 1013
-MX6Q_PAD_GPIO_5__CHEETAH_EVENTI 1014
-MX6Q_PAD_GPIO_7__ESAI1_TX4_RX1 1015
-MX6Q_PAD_GPIO_7__ECSPI5_RDY 1016
-MX6Q_PAD_GPIO_7__EPIT1_EPITO 1017
-MX6Q_PAD_GPIO_7__CAN1_TXCAN 1018
-MX6Q_PAD_GPIO_7__UART2_TXD 1019
-MX6Q_PAD_GPIO_7__GPIO_1_7 1020
-MX6Q_PAD_GPIO_7__SPDIF_PLOCK 1021
-MX6Q_PAD_GPIO_7__USBOH3_OTGUSB_HST_MODE 1022
-MX6Q_PAD_GPIO_8__ESAI1_TX5_RX0 1023
-MX6Q_PAD_GPIO_8__ANATOP_ANATOP_32K_OUT 1024
-MX6Q_PAD_GPIO_8__EPIT2_EPITO 1025
-MX6Q_PAD_GPIO_8__CAN1_RXCAN 1026
-MX6Q_PAD_GPIO_8__UART2_RXD 1027
-MX6Q_PAD_GPIO_8__GPIO_1_8 1028
-MX6Q_PAD_GPIO_8__SPDIF_SRCLK 1029
-MX6Q_PAD_GPIO_8__USBOH3_OTG_PWRCTL_WAK 1030
-MX6Q_PAD_GPIO_16__ESAI1_TX3_RX2 1031
-MX6Q_PAD_GPIO_16__ENET_1588_EVENT2_IN 1032
-MX6Q_PAD_GPIO_16__ENET_ETHERNET_REF_OUT 1033
-MX6Q_PAD_GPIO_16__USDHC1_LCTL 1034
-MX6Q_PAD_GPIO_16__SPDIF_IN1 1035
-MX6Q_PAD_GPIO_16__GPIO_7_11 1036
-MX6Q_PAD_GPIO_16__I2C3_SDA 1037
-MX6Q_PAD_GPIO_16__SJC_DE_B 1038
-MX6Q_PAD_GPIO_17__ESAI1_TX0 1039
-MX6Q_PAD_GPIO_17__ENET_1588_EVENT3_IN 1040
-MX6Q_PAD_GPIO_17__CCM_PMIC_RDY 1041
-MX6Q_PAD_GPIO_17__SDMA_SDMA_EXT_EVENT_0 1042
-MX6Q_PAD_GPIO_17__SPDIF_OUT1 1043
-MX6Q_PAD_GPIO_17__GPIO_7_12 1044
-MX6Q_PAD_GPIO_17__SJC_JTAG_ACT 1045
-MX6Q_PAD_GPIO_18__ESAI1_TX1 1046
-MX6Q_PAD_GPIO_18__ENET_RX_CLK 1047
-MX6Q_PAD_GPIO_18__USDHC3_VSELECT 1048
-MX6Q_PAD_GPIO_18__SDMA_SDMA_EXT_EVENT_1 1049
-MX6Q_PAD_GPIO_18__ASRC_ASRC_EXT_CLK 1050
-MX6Q_PAD_GPIO_18__GPIO_7_13 1051
-MX6Q_PAD_GPIO_18__SNVS_HP_WRA_SNVS_VIO5 1052
-MX6Q_PAD_GPIO_18__SRC_SYSTEM_RST 1053
-MX6Q_PAD_GPIO_19__KPP_COL_5 1054
-MX6Q_PAD_GPIO_19__ENET_1588_EVENT0_OUT 1055
-MX6Q_PAD_GPIO_19__SPDIF_OUT1 1056
-MX6Q_PAD_GPIO_19__CCM_CLKO 1057
-MX6Q_PAD_GPIO_19__ECSPI1_RDY 1058
-MX6Q_PAD_GPIO_19__GPIO_4_5 1059
-MX6Q_PAD_GPIO_19__ENET_TX_ER 1060
-MX6Q_PAD_GPIO_19__SRC_INT_BOOT 1061
-MX6Q_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 1062
-MX6Q_PAD_CSI0_PIXCLK__PCIE_CTRL_MUX_12 1063
-MX6Q_PAD_CSI0_PIXCLK__SDMA_DEBUG_PC_0 1064
-MX6Q_PAD_CSI0_PIXCLK__GPIO_5_18 1065
-MX6Q_PAD_CSI0_PIXCLK___MMDC_DEBUG_29 1066
-MX6Q_PAD_CSI0_PIXCLK__CHEETAH_EVENTO 1067
-MX6Q_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 1068
-MX6Q_PAD_CSI0_MCLK__PCIE_CTRL_MUX_13 1069
-MX6Q_PAD_CSI0_MCLK__CCM_CLKO 1070
-MX6Q_PAD_CSI0_MCLK__SDMA_DEBUG_PC_1 1071
-MX6Q_PAD_CSI0_MCLK__GPIO_5_19 1072
-MX6Q_PAD_CSI0_MCLK__MMDC_MMDC_DEBUG_30 1073
-MX6Q_PAD_CSI0_MCLK__CHEETAH_TRCTL 1074
-MX6Q_PAD_CSI0_DATA_EN__IPU1_CSI0_DA_EN 1075
-MX6Q_PAD_CSI0_DATA_EN__WEIM_WEIM_D_0 1076
-MX6Q_PAD_CSI0_DATA_EN__PCIE_CTRL_MUX_14 1077
-MX6Q_PAD_CSI0_DATA_EN__SDMA_DEBUG_PC_2 1078
-MX6Q_PAD_CSI0_DATA_EN__GPIO_5_20 1079
-MX6Q_PAD_CSI0_DATA_EN__MMDC_DEBUG_31 1080
-MX6Q_PAD_CSI0_DATA_EN__CHEETAH_TRCLK 1081
-MX6Q_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 1082
-MX6Q_PAD_CSI0_VSYNC__WEIM_WEIM_D_1 1083
-MX6Q_PAD_CSI0_VSYNC__PCIE_CTRL_MUX_15 1084
-MX6Q_PAD_CSI0_VSYNC__SDMA_DEBUG_PC_3 1085
-MX6Q_PAD_CSI0_VSYNC__GPIO_5_21 1086
-MX6Q_PAD_CSI0_VSYNC__MMDC_DEBUG_32 1087
-MX6Q_PAD_CSI0_VSYNC__CHEETAH_TRACE_0 1088
-MX6Q_PAD_CSI0_DAT4__IPU1_CSI0_D_4 1089
-MX6Q_PAD_CSI0_DAT4__WEIM_WEIM_D_2 1090
-MX6Q_PAD_CSI0_DAT4__ECSPI1_SCLK 1091
-MX6Q_PAD_CSI0_DAT4__KPP_COL_5 1092
-MX6Q_PAD_CSI0_DAT4__AUDMUX_AUD3_TXC 1093
-MX6Q_PAD_CSI0_DAT4__GPIO_5_22 1094
-MX6Q_PAD_CSI0_DAT4__MMDC_DEBUG_43 1095
-MX6Q_PAD_CSI0_DAT4__CHEETAH_TRACE_1 1096
-MX6Q_PAD_CSI0_DAT5__IPU1_CSI0_D_5 1097
-MX6Q_PAD_CSI0_DAT5__WEIM_WEIM_D_3 1098
-MX6Q_PAD_CSI0_DAT5__ECSPI1_MOSI 1099
-MX6Q_PAD_CSI0_DAT5__KPP_ROW_5 1100
-MX6Q_PAD_CSI0_DAT5__AUDMUX_AUD3_TXD 1101
-MX6Q_PAD_CSI0_DAT5__GPIO_5_23 1102
-MX6Q_PAD_CSI0_DAT5__MMDC_MMDC_DEBUG_44 1103
-MX6Q_PAD_CSI0_DAT5__CHEETAH_TRACE_2 1104
-MX6Q_PAD_CSI0_DAT6__IPU1_CSI0_D_6 1105
-MX6Q_PAD_CSI0_DAT6__WEIM_WEIM_D_4 1106
-MX6Q_PAD_CSI0_DAT6__ECSPI1_MISO 1107
-MX6Q_PAD_CSI0_DAT6__KPP_COL_6 1108
-MX6Q_PAD_CSI0_DAT6__AUDMUX_AUD3_TXFS 1109
-MX6Q_PAD_CSI0_DAT6__GPIO_5_24 1110
-MX6Q_PAD_CSI0_DAT6__MMDC_MMDC_DEBUG_45 1111
-MX6Q_PAD_CSI0_DAT6__CHEETAH_TRACE_3 1112
-MX6Q_PAD_CSI0_DAT7__IPU1_CSI0_D_7 1113
-MX6Q_PAD_CSI0_DAT7__WEIM_WEIM_D_5 1114
-MX6Q_PAD_CSI0_DAT7__ECSPI1_SS0 1115
-MX6Q_PAD_CSI0_DAT7__KPP_ROW_6 1116
-MX6Q_PAD_CSI0_DAT7__AUDMUX_AUD3_RXD 1117
-MX6Q_PAD_CSI0_DAT7__GPIO_5_25 1118
-MX6Q_PAD_CSI0_DAT7__MMDC_MMDC_DEBUG_46 1119
-MX6Q_PAD_CSI0_DAT7__CHEETAH_TRACE_4 1120
-MX6Q_PAD_CSI0_DAT8__IPU1_CSI0_D_8 1121
-MX6Q_PAD_CSI0_DAT8__WEIM_WEIM_D_6 1122
-MX6Q_PAD_CSI0_DAT8__ECSPI2_SCLK 1123
-MX6Q_PAD_CSI0_DAT8__KPP_COL_7 1124
-MX6Q_PAD_CSI0_DAT8__I2C1_SDA 1125
-MX6Q_PAD_CSI0_DAT8__GPIO_5_26 1126
-MX6Q_PAD_CSI0_DAT8__MMDC_MMDC_DEBUG_47 1127
-MX6Q_PAD_CSI0_DAT8__CHEETAH_TRACE_5 1128
-MX6Q_PAD_CSI0_DAT9__IPU1_CSI0_D_9 1129
-MX6Q_PAD_CSI0_DAT9__WEIM_WEIM_D_7 1130
-MX6Q_PAD_CSI0_DAT9__ECSPI2_MOSI 1131
-MX6Q_PAD_CSI0_DAT9__KPP_ROW_7 1132
-MX6Q_PAD_CSI0_DAT9__I2C1_SCL 1133
-MX6Q_PAD_CSI0_DAT9__GPIO_5_27 1134
-MX6Q_PAD_CSI0_DAT9__MMDC_MMDC_DEBUG_48 1135
-MX6Q_PAD_CSI0_DAT9__CHEETAH_TRACE_6 1136
-MX6Q_PAD_CSI0_DAT10__IPU1_CSI0_D_10 1137
-MX6Q_PAD_CSI0_DAT10__AUDMUX_AUD3_RXC 1138
-MX6Q_PAD_CSI0_DAT10__ECSPI2_MISO 1139
-MX6Q_PAD_CSI0_DAT10__UART1_TXD 1140
-MX6Q_PAD_CSI0_DAT10__SDMA_DEBUG_PC_4 1141
-MX6Q_PAD_CSI0_DAT10__GPIO_5_28 1142
-MX6Q_PAD_CSI0_DAT10__MMDC_MMDC_DEBUG_33 1143
-MX6Q_PAD_CSI0_DAT10__CHEETAH_TRACE_7 1144
-MX6Q_PAD_CSI0_DAT11__IPU1_CSI0_D_11 1145
-MX6Q_PAD_CSI0_DAT11__AUDMUX_AUD3_RXFS 1146
-MX6Q_PAD_CSI0_DAT11__ECSPI2_SS0 1147
-MX6Q_PAD_CSI0_DAT11__UART1_RXD 1148
-MX6Q_PAD_CSI0_DAT11__SDMA_DEBUG_PC_5 1149
-MX6Q_PAD_CSI0_DAT11__GPIO_5_29 1150
-MX6Q_PAD_CSI0_DAT11__MMDC_MMDC_DEBUG_34 1151
-MX6Q_PAD_CSI0_DAT11__CHEETAH_TRACE_8 1152
-MX6Q_PAD_CSI0_DAT12__IPU1_CSI0_D_12 1153
-MX6Q_PAD_CSI0_DAT12__WEIM_WEIM_D_8 1154
-MX6Q_PAD_CSI0_DAT12__PCIE_CTRL_MUX_16 1155
-MX6Q_PAD_CSI0_DAT12__UART4_TXD 1156
-MX6Q_PAD_CSI0_DAT12__SDMA_DEBUG_PC_6 1157
-MX6Q_PAD_CSI0_DAT12__GPIO_5_30 1158
-MX6Q_PAD_CSI0_DAT12__MMDC_MMDC_DEBUG_35 1159
-MX6Q_PAD_CSI0_DAT12__CHEETAH_TRACE_9 1160
-MX6Q_PAD_CSI0_DAT13__IPU1_CSI0_D_13 1161
-MX6Q_PAD_CSI0_DAT13__WEIM_WEIM_D_9 1162
-MX6Q_PAD_CSI0_DAT13__PCIE_CTRL_MUX_17 1163
-MX6Q_PAD_CSI0_DAT13__UART4_RXD 1164
-MX6Q_PAD_CSI0_DAT13__SDMA_DEBUG_PC_7 1165
-MX6Q_PAD_CSI0_DAT13__GPIO_5_31 1166
-MX6Q_PAD_CSI0_DAT13__MMDC_MMDC_DEBUG_36 1167
-MX6Q_PAD_CSI0_DAT13__CHEETAH_TRACE_10 1168
-MX6Q_PAD_CSI0_DAT14__IPU1_CSI0_D_14 1169
-MX6Q_PAD_CSI0_DAT14__WEIM_WEIM_D_10 1170
-MX6Q_PAD_CSI0_DAT14__PCIE_CTRL_MUX_18 1171
-MX6Q_PAD_CSI0_DAT14__UART5_TXD 1172
-MX6Q_PAD_CSI0_DAT14__SDMA_DEBUG_PC_8 1173
-MX6Q_PAD_CSI0_DAT14__GPIO_6_0 1174
-MX6Q_PAD_CSI0_DAT14__MMDC_MMDC_DEBUG_37 1175
-MX6Q_PAD_CSI0_DAT14__CHEETAH_TRACE_11 1176
-MX6Q_PAD_CSI0_DAT15__IPU1_CSI0_D_15 1177
-MX6Q_PAD_CSI0_DAT15__WEIM_WEIM_D_11 1178
-MX6Q_PAD_CSI0_DAT15__PCIE_CTRL_MUX_19 1179
-MX6Q_PAD_CSI0_DAT15__UART5_RXD 1180
-MX6Q_PAD_CSI0_DAT15__SDMA_DEBUG_PC_9 1181
-MX6Q_PAD_CSI0_DAT15__GPIO_6_1 1182
-MX6Q_PAD_CSI0_DAT15__MMDC_MMDC_DEBUG_38 1183
-MX6Q_PAD_CSI0_DAT15__CHEETAH_TRACE_12 1184
-MX6Q_PAD_CSI0_DAT16__IPU1_CSI0_D_16 1185
-MX6Q_PAD_CSI0_DAT16__WEIM_WEIM_D_12 1186
-MX6Q_PAD_CSI0_DAT16__PCIE_CTRL_MUX_20 1187
-MX6Q_PAD_CSI0_DAT16__UART4_RTS 1188
-MX6Q_PAD_CSI0_DAT16__SDMA_DEBUG_PC_10 1189
-MX6Q_PAD_CSI0_DAT16__GPIO_6_2 1190
-MX6Q_PAD_CSI0_DAT16__MMDC_MMDC_DEBUG_39 1191
-MX6Q_PAD_CSI0_DAT16__CHEETAH_TRACE_13 1192
-MX6Q_PAD_CSI0_DAT17__IPU1_CSI0_D_17 1193
-MX6Q_PAD_CSI0_DAT17__WEIM_WEIM_D_13 1194
-MX6Q_PAD_CSI0_DAT17__PCIE_CTRL_MUX_21 1195
-MX6Q_PAD_CSI0_DAT17__UART4_CTS 1196
-MX6Q_PAD_CSI0_DAT17__SDMA_DEBUG_PC_11 1197
-MX6Q_PAD_CSI0_DAT17__GPIO_6_3 1198
-MX6Q_PAD_CSI0_DAT17__MMDC_MMDC_DEBUG_40 1199
-MX6Q_PAD_CSI0_DAT17__CHEETAH_TRACE_14 1200
-MX6Q_PAD_CSI0_DAT18__IPU1_CSI0_D_18 1201
-MX6Q_PAD_CSI0_DAT18__WEIM_WEIM_D_14 1202
-MX6Q_PAD_CSI0_DAT18__PCIE_CTRL_MUX_22 1203
-MX6Q_PAD_CSI0_DAT18__UART5_RTS 1204
-MX6Q_PAD_CSI0_DAT18__SDMA_DEBUG_PC_12 1205
-MX6Q_PAD_CSI0_DAT18__GPIO_6_4 1206
-MX6Q_PAD_CSI0_DAT18__MMDC_MMDC_DEBUG_41 1207
-MX6Q_PAD_CSI0_DAT18__CHEETAH_TRACE_15 1208
-MX6Q_PAD_CSI0_DAT19__IPU1_CSI0_D_19 1209
-MX6Q_PAD_CSI0_DAT19__WEIM_WEIM_D_15 1210
-MX6Q_PAD_CSI0_DAT19__PCIE_CTRL_MUX_23 1211
-MX6Q_PAD_CSI0_DAT19__UART5_CTS 1212
-MX6Q_PAD_CSI0_DAT19__SDMA_DEBUG_PC_13 1213
-MX6Q_PAD_CSI0_DAT19__GPIO_6_5 1214
-MX6Q_PAD_CSI0_DAT19__MMDC_MMDC_DEBUG_42 1215
-MX6Q_PAD_CSI0_DAT19__ANATOP_TESTO_9 1216
-MX6Q_PAD_JTAG_TMS__SJC_TMS 1217
-MX6Q_PAD_JTAG_MOD__SJC_MOD 1218
-MX6Q_PAD_JTAG_TRSTB__SJC_TRSTB 1219
-MX6Q_PAD_JTAG_TDI__SJC_TDI 1220
-MX6Q_PAD_JTAG_TCK__SJC_TCK 1221
-MX6Q_PAD_JTAG_TDO__SJC_TDO 1222
-MX6Q_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3 1223
-MX6Q_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2 1224
-MX6Q_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK 1225
-MX6Q_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1 1226
-MX6Q_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0 1227
-MX6Q_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3 1228
-MX6Q_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK 1229
-MX6Q_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2 1230
-MX6Q_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1 1231
-MX6Q_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0 1232
-MX6Q_PAD_TAMPER__SNVS_LP_WRAP_SNVS_TD1 1233
-MX6Q_PAD_PMIC_ON_REQ__SNVS_LPWRAP_WKALM 1234
-MX6Q_PAD_PMIC_STBY_REQ__CCM_PMIC_STBYRQ 1235
-MX6Q_PAD_POR_B__SRC_POR_B 1236
-MX6Q_PAD_BOOT_MODE1__SRC_BOOT_MODE_1 1237
-MX6Q_PAD_RESET_IN_B__SRC_RESET_B 1238
-MX6Q_PAD_BOOT_MODE0__SRC_BOOT_MODE_0 1239
-MX6Q_PAD_TEST_MODE__TCU_TEST_MODE 1240
-MX6Q_PAD_SD3_DAT7__USDHC3_DAT7 1241
-MX6Q_PAD_SD3_DAT7__UART1_TXD 1242
-MX6Q_PAD_SD3_DAT7__PCIE_CTRL_MUX_24 1243
-MX6Q_PAD_SD3_DAT7__USBOH3_UH3_DFD_OUT_0 1244
-MX6Q_PAD_SD3_DAT7__USBOH3_UH2_DFD_OUT_0 1245
-MX6Q_PAD_SD3_DAT7__GPIO_6_17 1246
-MX6Q_PAD_SD3_DAT7__MIPI_CORE_DPHY_IN_12 1247
-MX6Q_PAD_SD3_DAT7__USBPHY2_CLK20DIV 1248
-MX6Q_PAD_SD3_DAT6__USDHC3_DAT6 1249
-MX6Q_PAD_SD3_DAT6__UART1_RXD 1250
-MX6Q_PAD_SD3_DAT6__PCIE_CTRL_MUX_25 1251
-MX6Q_PAD_SD3_DAT6__USBOH3_UH3_DFD_OUT_1 1252
-MX6Q_PAD_SD3_DAT6__USBOH3_UH2_DFD_OUT_1 1253
-MX6Q_PAD_SD3_DAT6__GPIO_6_18 1254
-MX6Q_PAD_SD3_DAT6__MIPI_CORE_DPHY_IN_13 1255
-MX6Q_PAD_SD3_DAT6__ANATOP_TESTO_10 1256
-MX6Q_PAD_SD3_DAT5__USDHC3_DAT5 1257
-MX6Q_PAD_SD3_DAT5__UART2_TXD 1258
-MX6Q_PAD_SD3_DAT5__PCIE_CTRL_MUX_26 1259
-MX6Q_PAD_SD3_DAT5__USBOH3_UH3_DFD_OUT_2 1260
-MX6Q_PAD_SD3_DAT5__USBOH3_UH2_DFD_OUT_2 1261
-MX6Q_PAD_SD3_DAT5__GPIO_7_0 1262
-MX6Q_PAD_SD3_DAT5__MIPI_CORE_DPHY_IN_14 1263
-MX6Q_PAD_SD3_DAT5__ANATOP_TESTO_11 1264
-MX6Q_PAD_SD3_DAT4__USDHC3_DAT4 1265
-MX6Q_PAD_SD3_DAT4__UART2_RXD 1266
-MX6Q_PAD_SD3_DAT4__PCIE_CTRL_MUX_27 1267
-MX6Q_PAD_SD3_DAT4__USBOH3_UH3_DFD_OUT_3 1268
-MX6Q_PAD_SD3_DAT4__USBOH3_UH2_DFD_OUT_3 1269
-MX6Q_PAD_SD3_DAT4__GPIO_7_1 1270
-MX6Q_PAD_SD3_DAT4__MIPI_CORE_DPHY_IN_15 1271
-MX6Q_PAD_SD3_DAT4__ANATOP_TESTO_12 1272
-MX6Q_PAD_SD3_CMD__USDHC3_CMD 1273
-MX6Q_PAD_SD3_CMD__UART2_CTS 1274
-MX6Q_PAD_SD3_CMD__CAN1_TXCAN 1275
-MX6Q_PAD_SD3_CMD__USBOH3_UH3_DFD_OUT_4 1276
-MX6Q_PAD_SD3_CMD__USBOH3_UH2_DFD_OUT_4 1277
-MX6Q_PAD_SD3_CMD__GPIO_7_2 1278
-MX6Q_PAD_SD3_CMD__MIPI_CORE_DPHY_IN_16 1279
-MX6Q_PAD_SD3_CMD__ANATOP_TESTO_13 1280
-MX6Q_PAD_SD3_CLK__USDHC3_CLK 1281
-MX6Q_PAD_SD3_CLK__UART2_RTS 1282
-MX6Q_PAD_SD3_CLK__CAN1_RXCAN 1283
-MX6Q_PAD_SD3_CLK__USBOH3_UH3_DFD_OUT_5 1284
-MX6Q_PAD_SD3_CLK__USBOH3_UH2_DFD_OUT_5 1285
-MX6Q_PAD_SD3_CLK__GPIO_7_3 1286
-MX6Q_PAD_SD3_CLK__MIPI_CORE_DPHY_IN_17 1287
-MX6Q_PAD_SD3_CLK__ANATOP_TESTO_14 1288
-MX6Q_PAD_SD3_DAT0__USDHC3_DAT0 1289
-MX6Q_PAD_SD3_DAT0__UART1_CTS 1290
-MX6Q_PAD_SD3_DAT0__CAN2_TXCAN 1291
-MX6Q_PAD_SD3_DAT0__USBOH3_UH3_DFD_OUT_6 1292
-MX6Q_PAD_SD3_DAT0__USBOH3_UH2_DFD_OUT_6 1293
-MX6Q_PAD_SD3_DAT0__GPIO_7_4 1294
-MX6Q_PAD_SD3_DAT0__MIPI_CORE_DPHY_IN_18 1295
-MX6Q_PAD_SD3_DAT0__ANATOP_TESTO_15 1296
-MX6Q_PAD_SD3_DAT1__USDHC3_DAT1 1297
-MX6Q_PAD_SD3_DAT1__UART1_RTS 1298
-MX6Q_PAD_SD3_DAT1__CAN2_RXCAN 1299
-MX6Q_PAD_SD3_DAT1__USBOH3_UH3_DFD_OUT_7 1300
-MX6Q_PAD_SD3_DAT1__USBOH3_UH2_DFD_OUT_7 1301
-MX6Q_PAD_SD3_DAT1__GPIO_7_5 1302
-MX6Q_PAD_SD3_DAT1__MIPI_CORE_DPHY_IN_19 1303
-MX6Q_PAD_SD3_DAT1__ANATOP_TESTI_0 1304
-MX6Q_PAD_SD3_DAT2__USDHC3_DAT2 1305
-MX6Q_PAD_SD3_DAT2__PCIE_CTRL_MUX_28 1306
-MX6Q_PAD_SD3_DAT2__USBOH3_UH3_DFD_OUT_8 1307
-MX6Q_PAD_SD3_DAT2__USBOH3_UH2_DFD_OUT_8 1308
-MX6Q_PAD_SD3_DAT2__GPIO_7_6 1309
-MX6Q_PAD_SD3_DAT2__MIPI_CORE_DPHY_IN_20 1310
-MX6Q_PAD_SD3_DAT2__ANATOP_TESTI_1 1311
-MX6Q_PAD_SD3_DAT3__USDHC3_DAT3 1312
-MX6Q_PAD_SD3_DAT3__UART3_CTS 1313
-MX6Q_PAD_SD3_DAT3__PCIE_CTRL_MUX_29 1314
-MX6Q_PAD_SD3_DAT3__USBOH3_UH3_DFD_OUT_9 1315
-MX6Q_PAD_SD3_DAT3__USBOH3_UH2_DFD_OUT_9 1316
-MX6Q_PAD_SD3_DAT3__GPIO_7_7 1317
-MX6Q_PAD_SD3_DAT3__MIPI_CORE_DPHY_IN_21 1318
-MX6Q_PAD_SD3_DAT3__ANATOP_TESTI_2 1319
-MX6Q_PAD_SD3_RST__USDHC3_RST 1320
-MX6Q_PAD_SD3_RST__UART3_RTS 1321
-MX6Q_PAD_SD3_RST__PCIE_CTRL_MUX_30 1322
-MX6Q_PAD_SD3_RST__USBOH3_UH3_DFD_OUT_10 1323
-MX6Q_PAD_SD3_RST__USBOH3_UH2_DFD_OUT_10 1324
-MX6Q_PAD_SD3_RST__GPIO_7_8 1325
-MX6Q_PAD_SD3_RST__MIPI_CORE_DPHY_IN_22 1326
-MX6Q_PAD_SD3_RST__ANATOP_ANATOP_TESTI_3 1327
-MX6Q_PAD_NANDF_CLE__RAWNAND_CLE 1328
-MX6Q_PAD_NANDF_CLE__IPU2_SISG_4 1329
-MX6Q_PAD_NANDF_CLE__PCIE_CTRL_MUX_31 1330
-MX6Q_PAD_NANDF_CLE__USBOH3_UH3_DFD_OT11 1331
-MX6Q_PAD_NANDF_CLE__USBOH3_UH2_DFD_OT11 1332
-MX6Q_PAD_NANDF_CLE__GPIO_6_7 1333
-MX6Q_PAD_NANDF_CLE__MIPI_CORE_DPHY_IN23 1334
-MX6Q_PAD_NANDF_CLE__TPSMP_HTRANS_0 1335
-MX6Q_PAD_NANDF_ALE__RAWNAND_ALE 1336
-MX6Q_PAD_NANDF_ALE__USDHC4_RST 1337
-MX6Q_PAD_NANDF_ALE__PCIE_CTRL_MUX_0 1338
-MX6Q_PAD_NANDF_ALE__USBOH3_UH3_DFD_OT12 1339
-MX6Q_PAD_NANDF_ALE__USBOH3_UH2_DFD_OT12 1340
-MX6Q_PAD_NANDF_ALE__GPIO_6_8 1341
-MX6Q_PAD_NANDF_ALE__MIPI_CR_DPHY_IN_24 1342
-MX6Q_PAD_NANDF_ALE__TPSMP_HTRANS_1 1343
-MX6Q_PAD_NANDF_WP_B__RAWNAND_RESETN 1344
-MX6Q_PAD_NANDF_WP_B__IPU2_SISG_5 1345
-MX6Q_PAD_NANDF_WP_B__PCIE_CTRL__MUX_1 1346
-MX6Q_PAD_NANDF_WP_B__USBOH3_UH3_DFDOT13 1347
-MX6Q_PAD_NANDF_WP_B__USBOH3_UH2_DFDOT13 1348
-MX6Q_PAD_NANDF_WP_B__GPIO_6_9 1349
-MX6Q_PAD_NANDF_WP_B__MIPI_CR_DPHY_OUT32 1350
-MX6Q_PAD_NANDF_WP_B__PL301_PER1_HSIZE_0 1351
-MX6Q_PAD_NANDF_RB0__RAWNAND_READY0 1352
-MX6Q_PAD_NANDF_RB0__IPU2_DI0_PIN1 1353
-MX6Q_PAD_NANDF_RB0__PCIE_CTRL_MUX_2 1354
-MX6Q_PAD_NANDF_RB0__USBOH3_UH3_DFD_OT14 1355
-MX6Q_PAD_NANDF_RB0__USBOH3_UH2_DFD_OT14 1356
-MX6Q_PAD_NANDF_RB0__GPIO_6_10 1357
-MX6Q_PAD_NANDF_RB0__MIPI_CR_DPHY_OUT_33 1358
-MX6Q_PAD_NANDF_RB0__PL301_PER1_HSIZE_1 1359
-MX6Q_PAD_NANDF_CS0__RAWNAND_CE0N 1360
-MX6Q_PAD_NANDF_CS0__USBOH3_UH3_DFD_OT15 1361
-MX6Q_PAD_NANDF_CS0__USBOH3_UH2_DFD_OT15 1362
-MX6Q_PAD_NANDF_CS0__GPIO_6_11 1363
-MX6Q_PAD_NANDF_CS0__PL301_PER1_HSIZE_2 1364
-MX6Q_PAD_NANDF_CS1__RAWNAND_CE1N 1365
-MX6Q_PAD_NANDF_CS1__USDHC4_VSELECT 1366
-MX6Q_PAD_NANDF_CS1__USDHC3_VSELECT 1367
-MX6Q_PAD_NANDF_CS1__PCIE_CTRL_MUX_3 1368
-MX6Q_PAD_NANDF_CS1__GPIO_6_14 1369
-MX6Q_PAD_NANDF_CS1__PL301_PER1_HRDYOUT 1370
-MX6Q_PAD_NANDF_CS2__RAWNAND_CE2N 1371
-MX6Q_PAD_NANDF_CS2__IPU1_SISG_0 1372
-MX6Q_PAD_NANDF_CS2__ESAI1_TX0 1373
-MX6Q_PAD_NANDF_CS2__WEIM_WEIM_CRE 1374
-MX6Q_PAD_NANDF_CS2__CCM_CLKO2 1375
-MX6Q_PAD_NANDF_CS2__GPIO_6_15 1376
-MX6Q_PAD_NANDF_CS2__IPU2_SISG_0 1377
-MX6Q_PAD_NANDF_CS3__RAWNAND_CE3N 1378
-MX6Q_PAD_NANDF_CS3__IPU1_SISG_1 1379
-MX6Q_PAD_NANDF_CS3__ESAI1_TX1 1380
-MX6Q_PAD_NANDF_CS3__WEIM_WEIM_A_26 1381
-MX6Q_PAD_NANDF_CS3__PCIE_CTRL_MUX_4 1382
-MX6Q_PAD_NANDF_CS3__GPIO_6_16 1383
-MX6Q_PAD_NANDF_CS3__IPU2_SISG_1 1384
-MX6Q_PAD_NANDF_CS3__TPSMP_CLK 1385
-MX6Q_PAD_SD4_CMD__USDHC4_CMD 1386
-MX6Q_PAD_SD4_CMD__RAWNAND_RDN 1387
-MX6Q_PAD_SD4_CMD__UART3_TXD 1388
-MX6Q_PAD_SD4_CMD__PCIE_CTRL_MUX_5 1389
-MX6Q_PAD_SD4_CMD__GPIO_7_9 1390
-MX6Q_PAD_SD4_CMD__TPSMP_HDATA_DIR 1391
-MX6Q_PAD_SD4_CLK__USDHC4_CLK 1392
-MX6Q_PAD_SD4_CLK__RAWNAND_WRN 1393
-MX6Q_PAD_SD4_CLK__UART3_RXD 1394
-MX6Q_PAD_SD4_CLK__PCIE_CTRL_MUX_6 1395
-MX6Q_PAD_SD4_CLK__GPIO_7_10 1396
-MX6Q_PAD_NANDF_D0__RAWNAND_D0 1397
-MX6Q_PAD_NANDF_D0__USDHC1_DAT4 1398
-MX6Q_PAD_NANDF_D0__GPU3D_GPU_DBG_OUT_0 1399
-MX6Q_PAD_NANDF_D0__USBOH3_UH2_DFD_OUT16 1400
-MX6Q_PAD_NANDF_D0__USBOH3_UH3_DFD_OUT16 1401
-MX6Q_PAD_NANDF_D0__GPIO_2_0 1402
-MX6Q_PAD_NANDF_D0__IPU1_IPU_DIAG_BUS_0 1403
-MX6Q_PAD_NANDF_D0__IPU2_IPU_DIAG_BUS_0 1404
-MX6Q_PAD_NANDF_D1__RAWNAND_D1 1405
-MX6Q_PAD_NANDF_D1__USDHC1_DAT5 1406
-MX6Q_PAD_NANDF_D1__GPU3D_GPU_DEBUG_OUT1 1407
-MX6Q_PAD_NANDF_D1__USBOH3_UH2_DFD_OUT17 1408
-MX6Q_PAD_NANDF_D1__USBOH3_UH3_DFD_OUT17 1409
-MX6Q_PAD_NANDF_D1__GPIO_2_1 1410
-MX6Q_PAD_NANDF_D1__IPU1_IPU_DIAG_BUS_1 1411
-MX6Q_PAD_NANDF_D1__IPU2_IPU_DIAG_BUS_1 1412
-MX6Q_PAD_NANDF_D2__RAWNAND_D2 1413
-MX6Q_PAD_NANDF_D2__USDHC1_DAT6 1414
-MX6Q_PAD_NANDF_D2__GPU3D_GPU_DBG_OUT_2 1415
-MX6Q_PAD_NANDF_D2__USBOH3_UH2_DFD_OUT18 1416
-MX6Q_PAD_NANDF_D2__USBOH3_UH3_DFD_OUT18 1417
-MX6Q_PAD_NANDF_D2__GPIO_2_2 1418
-MX6Q_PAD_NANDF_D2__IPU1_IPU_DIAG_BUS_2 1419
-MX6Q_PAD_NANDF_D2__IPU2_IPU_DIAG_BUS_2 1420
-MX6Q_PAD_NANDF_D3__RAWNAND_D3 1421
-MX6Q_PAD_NANDF_D3__USDHC1_DAT7 1422
-MX6Q_PAD_NANDF_D3__GPU3D_GPU_DBG_OUT_3 1423
-MX6Q_PAD_NANDF_D3__USBOH3_UH2_DFD_OUT19 1424
-MX6Q_PAD_NANDF_D3__USBOH3_UH3_DFD_OUT19 1425
-MX6Q_PAD_NANDF_D3__GPIO_2_3 1426
-MX6Q_PAD_NANDF_D3__IPU1_IPU_DIAG_BUS_3 1427
-MX6Q_PAD_NANDF_D3__IPU2_IPU_DIAG_BUS_3 1428
-MX6Q_PAD_NANDF_D4__RAWNAND_D4 1429
-MX6Q_PAD_NANDF_D4__USDHC2_DAT4 1430
-MX6Q_PAD_NANDF_D4__GPU3D_GPU_DBG_OUT_4 1431
-MX6Q_PAD_NANDF_D4__USBOH3_UH2_DFD_OUT20 1432
-MX6Q_PAD_NANDF_D4__USBOH3_UH3_DFD_OUT20 1433
-MX6Q_PAD_NANDF_D4__GPIO_2_4 1434
-MX6Q_PAD_NANDF_D4__IPU1_IPU_DIAG_BUS_4 1435
-MX6Q_PAD_NANDF_D4__IPU2_IPU_DIAG_BUS_4 1436
-MX6Q_PAD_NANDF_D5__RAWNAND_D5 1437
-MX6Q_PAD_NANDF_D5__USDHC2_DAT5 1438
-MX6Q_PAD_NANDF_D5__GPU3D_GPU_DBG_OUT_5 1439
-MX6Q_PAD_NANDF_D5__USBOH3_UH2_DFD_OUT21 1440
-MX6Q_PAD_NANDF_D5__USBOH3_UH3_DFD_OUT21 1441
-MX6Q_PAD_NANDF_D5__GPIO_2_5 1442
-MX6Q_PAD_NANDF_D5__IPU1_IPU_DIAG_BUS_5 1443
-MX6Q_PAD_NANDF_D5__IPU2_IPU_DIAG_BUS_5 1444
-MX6Q_PAD_NANDF_D6__RAWNAND_D6 1445
-MX6Q_PAD_NANDF_D6__USDHC2_DAT6 1446
-MX6Q_PAD_NANDF_D6__GPU3D_GPU_DBG_OUT_6 1447
-MX6Q_PAD_NANDF_D6__USBOH3_UH2_DFD_OUT22 1448
-MX6Q_PAD_NANDF_D6__USBOH3_UH3_DFD_OUT22 1449
-MX6Q_PAD_NANDF_D6__GPIO_2_6 1450
-MX6Q_PAD_NANDF_D6__IPU1_IPU_DIAG_BUS_6 1451
-MX6Q_PAD_NANDF_D6__IPU2_IPU_DIAG_BUS_6 1452
-MX6Q_PAD_NANDF_D7__RAWNAND_D7 1453
-MX6Q_PAD_NANDF_D7__USDHC2_DAT7 1454
-MX6Q_PAD_NANDF_D7__GPU3D_GPU_DBG_OUT_7 1455
-MX6Q_PAD_NANDF_D7__USBOH3_UH2_DFD_OUT23 1456
-MX6Q_PAD_NANDF_D7__USBOH3_UH3_DFD_OUT23 1457
-MX6Q_PAD_NANDF_D7__GPIO_2_7 1458
-MX6Q_PAD_NANDF_D7__IPU1_IPU_DIAG_BUS_7 1459
-MX6Q_PAD_NANDF_D7__IPU2_IPU_DIAG_BUS_7 1460
-MX6Q_PAD_SD4_DAT0__RAWNAND_D8 1461
-MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 1462
-MX6Q_PAD_SD4_DAT0__RAWNAND_DQS 1463
-MX6Q_PAD_SD4_DAT0__USBOH3_UH2_DFD_OUT24 1464
-MX6Q_PAD_SD4_DAT0__USBOH3_UH3_DFD_OUT24 1465
-MX6Q_PAD_SD4_DAT0__GPIO_2_8 1466
-MX6Q_PAD_SD4_DAT0__IPU1_IPU_DIAG_BUS_8 1467
-MX6Q_PAD_SD4_DAT0__IPU2_IPU_DIAG_BUS_8 1468
-MX6Q_PAD_SD4_DAT1__RAWNAND_D9 1469
-MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 1470
-MX6Q_PAD_SD4_DAT1__PWM3_PWMO 1471
-MX6Q_PAD_SD4_DAT1__USBOH3_UH2_DFD_OUT25 1472
-MX6Q_PAD_SD4_DAT1__USBOH3_UH3_DFD_OUT25 1473
-MX6Q_PAD_SD4_DAT1__GPIO_2_9 1474
-MX6Q_PAD_SD4_DAT1__IPU1_IPU_DIAG_BUS_9 1475
-MX6Q_PAD_SD4_DAT1__IPU2_IPU_DIAG_BUS_9 1476
-MX6Q_PAD_SD4_DAT2__RAWNAND_D10 1477
-MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 1478
-MX6Q_PAD_SD4_DAT2__PWM4_PWMO 1479
-MX6Q_PAD_SD4_DAT2__USBOH3_UH2_DFD_OUT26 1480
-MX6Q_PAD_SD4_DAT2__USBOH3_UH3_DFD_OUT26 1481
-MX6Q_PAD_SD4_DAT2__GPIO_2_10 1482
-MX6Q_PAD_SD4_DAT2__IPU1_IPU_DIAG_BUS_10 1483
-MX6Q_PAD_SD4_DAT2__IPU2_IPU_DIAG_BUS_10 1484
-MX6Q_PAD_SD4_DAT3__RAWNAND_D11 1485
-MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 1486
-MX6Q_PAD_SD4_DAT3__USBOH3_UH2_DFD_OUT27 1487
-MX6Q_PAD_SD4_DAT3__USBOH3_UH3_DFD_OUT27 1488
-MX6Q_PAD_SD4_DAT3__GPIO_2_11 1489
-MX6Q_PAD_SD4_DAT3__IPU1_IPU_DIAG_BUS_11 1490
-MX6Q_PAD_SD4_DAT3__IPU2_IPU_DIAG_BUS_11 1491
-MX6Q_PAD_SD4_DAT4__RAWNAND_D12 1492
-MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 1493
-MX6Q_PAD_SD4_DAT4__UART2_RXD 1494
-MX6Q_PAD_SD4_DAT4__USBOH3_UH2_DFD_OUT28 1495
-MX6Q_PAD_SD4_DAT4__USBOH3_UH3_DFD_OUT28 1496
-MX6Q_PAD_SD4_DAT4__GPIO_2_12 1497
-MX6Q_PAD_SD4_DAT4__IPU1_IPU_DIAG_BUS_12 1498
-MX6Q_PAD_SD4_DAT4__IPU2_IPU_DIAG_BUS_12 1499
-MX6Q_PAD_SD4_DAT5__RAWNAND_D13 1500
-MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 1501
-MX6Q_PAD_SD4_DAT5__UART2_RTS 1502
-MX6Q_PAD_SD4_DAT5__USBOH3_UH2_DFD_OUT29 1503
-MX6Q_PAD_SD4_DAT5__USBOH3_UH3_DFD_OUT29 1504
-MX6Q_PAD_SD4_DAT5__GPIO_2_13 1505
-MX6Q_PAD_SD4_DAT5__IPU1_IPU_DIAG_BUS_13 1506
-MX6Q_PAD_SD4_DAT5__IPU2_IPU_DIAG_BUS_13 1507
-MX6Q_PAD_SD4_DAT6__RAWNAND_D14 1508
-MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 1509
-MX6Q_PAD_SD4_DAT6__UART2_CTS 1510
-MX6Q_PAD_SD4_DAT6__USBOH3_UH2_DFD_OUT30 1511
-MX6Q_PAD_SD4_DAT6__USBOH3_UH3_DFD_OUT30 1512
-MX6Q_PAD_SD4_DAT6__GPIO_2_14 1513
-MX6Q_PAD_SD4_DAT6__IPU1_IPU_DIAG_BUS_14 1514
-MX6Q_PAD_SD4_DAT6__IPU2_IPU_DIAG_BUS_14 1515
-MX6Q_PAD_SD4_DAT7__RAWNAND_D15 1516
-MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 1517
-MX6Q_PAD_SD4_DAT7__UART2_TXD 1518
-MX6Q_PAD_SD4_DAT7__USBOH3_UH2_DFD_OUT31 1519
-MX6Q_PAD_SD4_DAT7__USBOH3_UH3_DFD_OUT31 1520
-MX6Q_PAD_SD4_DAT7__GPIO_2_15 1521
-MX6Q_PAD_SD4_DAT7__IPU1_IPU_DIAG_BUS_15 1522
-MX6Q_PAD_SD4_DAT7__IPU2_IPU_DIAG_BUS_15 1523
-MX6Q_PAD_SD1_DAT1__USDHC1_DAT1 1524
-MX6Q_PAD_SD1_DAT1__ECSPI5_SS0 1525
-MX6Q_PAD_SD1_DAT1__PWM3_PWMO 1526
-MX6Q_PAD_SD1_DAT1__GPT_CAPIN2 1527
-MX6Q_PAD_SD1_DAT1__PCIE_CTRL_MUX_7 1528
-MX6Q_PAD_SD1_DAT1__GPIO_1_17 1529
-MX6Q_PAD_SD1_DAT1__HDMI_TX_OPHYDTB_0 1530
-MX6Q_PAD_SD1_DAT1__ANATOP_TESTO_8 1531
-MX6Q_PAD_SD1_DAT0__USDHC1_DAT0 1532
-MX6Q_PAD_SD1_DAT0__ECSPI5_MISO 1533
-MX6Q_PAD_SD1_DAT0__CAAM_WRAP_RNG_OSCOBS 1534
-MX6Q_PAD_SD1_DAT0__GPT_CAPIN1 1535
-MX6Q_PAD_SD1_DAT0__PCIE_CTRL_MUX_8 1536
-MX6Q_PAD_SD1_DAT0__GPIO_1_16 1537
-MX6Q_PAD_SD1_DAT0__HDMI_TX_OPHYDTB_1 1538
-MX6Q_PAD_SD1_DAT0__ANATOP_TESTO_7 1539
-MX6Q_PAD_SD1_DAT3__USDHC1_DAT3 1540
-MX6Q_PAD_SD1_DAT3__ECSPI5_SS2 1541
-MX6Q_PAD_SD1_DAT3__GPT_CMPOUT3 1542
-MX6Q_PAD_SD1_DAT3__PWM1_PWMO 1543
-MX6Q_PAD_SD1_DAT3__WDOG2_WDOG_B 1544
-MX6Q_PAD_SD1_DAT3__GPIO_1_21 1545
-MX6Q_PAD_SD1_DAT3__WDOG2_WDOG_RST_B_DEB 1546
-MX6Q_PAD_SD1_DAT3__ANATOP_TESTO_6 1547
-MX6Q_PAD_SD1_CMD__USDHC1_CMD 1548
-MX6Q_PAD_SD1_CMD__ECSPI5_MOSI 1549
-MX6Q_PAD_SD1_CMD__PWM4_PWMO 1550
-MX6Q_PAD_SD1_CMD__GPT_CMPOUT1 1551
-MX6Q_PAD_SD1_CMD__GPIO_1_18 1552
-MX6Q_PAD_SD1_CMD__ANATOP_TESTO_5 1553
-MX6Q_PAD_SD1_DAT2__USDHC1_DAT2 1554
-MX6Q_PAD_SD1_DAT2__ECSPI5_SS1 1555
-MX6Q_PAD_SD1_DAT2__GPT_CMPOUT2 1556
-MX6Q_PAD_SD1_DAT2__PWM2_PWMO 1557
-MX6Q_PAD_SD1_DAT2__WDOG1_WDOG_B 1558
-MX6Q_PAD_SD1_DAT2__GPIO_1_19 1559
-MX6Q_PAD_SD1_DAT2__WDOG1_WDOG_RST_B_DEB 1560
-MX6Q_PAD_SD1_DAT2__ANATOP_TESTO_4 1561
-MX6Q_PAD_SD1_CLK__USDHC1_CLK 1562
-MX6Q_PAD_SD1_CLK__ECSPI5_SCLK 1563
-MX6Q_PAD_SD1_CLK__OSC32K_32K_OUT 1564
-MX6Q_PAD_SD1_CLK__GPT_CLKIN 1565
-MX6Q_PAD_SD1_CLK__GPIO_1_20 1566
-MX6Q_PAD_SD1_CLK__PHY_DTB_0 1567
-MX6Q_PAD_SD1_CLK__SATA_PHY_DTB_0 1568
-MX6Q_PAD_SD2_CLK__USDHC2_CLK 1569
-MX6Q_PAD_SD2_CLK__ECSPI5_SCLK 1570
-MX6Q_PAD_SD2_CLK__KPP_COL_5 1571
-MX6Q_PAD_SD2_CLK__AUDMUX_AUD4_RXFS 1572
-MX6Q_PAD_SD2_CLK__PCIE_CTRL_MUX_9 1573
-MX6Q_PAD_SD2_CLK__GPIO_1_10 1574
-MX6Q_PAD_SD2_CLK__PHY_DTB_1 1575
-MX6Q_PAD_SD2_CLK__SATA_PHY_DTB_1 1576
-MX6Q_PAD_SD2_CMD__USDHC2_CMD 1577
-MX6Q_PAD_SD2_CMD__ECSPI5_MOSI 1578
-MX6Q_PAD_SD2_CMD__KPP_ROW_5 1579
-MX6Q_PAD_SD2_CMD__AUDMUX_AUD4_RXC 1580
-MX6Q_PAD_SD2_CMD__PCIE_CTRL_MUX_10 1581
-MX6Q_PAD_SD2_CMD__GPIO_1_11 1582
-MX6Q_PAD_SD2_DAT3__USDHC2_DAT3 1583
-MX6Q_PAD_SD2_DAT3__ECSPI5_SS3 1584
-MX6Q_PAD_SD2_DAT3__KPP_COL_6 1585
-MX6Q_PAD_SD2_DAT3__AUDMUX_AUD4_TXC 1586
-MX6Q_PAD_SD2_DAT3__PCIE_CTRL_MUX_11 1587
-MX6Q_PAD_SD2_DAT3__GPIO_1_12 1588
-MX6Q_PAD_SD2_DAT3__SJC_DONE 1589
-MX6Q_PAD_SD2_DAT3__ANATOP_TESTO_3 1590
-MX6Q_PAD_ENET_RX_ER__ANATOP_USBOTG_ID 1591
-MX6Q_PAD_GPIO_1__ANATOP_USBOTG_ID 1592
+Refer to imx6q-pinfunc.h in device tree source folder for all available
+imx6q PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
new file mode 100644
index 000000000000..e5f6d1f065a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sl-pinctrl.txt
@@ -0,0 +1,39 @@
+* Freescale IMX6 SoloLite IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx6sl-iomuxc"
+- fsl,pins: two integers array, represents a group of pins mux and config
+ setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a
+ pin working on a specific function, CONFIG is the pad setting value like
+ pull-up for this pin. Please refer to imx6sl datasheet for the valid pad
+ config settings.
+
+CONFIG bits definition:
+PAD_CTL_LVE (1 << 22)
+PAD_CTL_HYS (1 << 16)
+PAD_CTL_PUS_100K_DOWN (0 << 14)
+PAD_CTL_PUS_47K_UP (1 << 14)
+PAD_CTL_PUS_100K_UP (2 << 14)
+PAD_CTL_PUS_22K_UP (3 << 14)
+PAD_CTL_PUE (1 << 13)
+PAD_CTL_PKE (1 << 12)
+PAD_CTL_ODE (1 << 11)
+PAD_CTL_SPEED_LOW (1 << 6)
+PAD_CTL_SPEED_MED (2 << 6)
+PAD_CTL_SPEED_HIGH (3 << 6)
+PAD_CTL_DSE_DISABLE (0 << 3)
+PAD_CTL_DSE_240ohm (1 << 3)
+PAD_CTL_DSE_120ohm (2 << 3)
+PAD_CTL_DSE_80ohm (3 << 3)
+PAD_CTL_DSE_60ohm (4 << 3)
+PAD_CTL_DSE_48ohm (5 << 3)
+PAD_CTL_DSE_40ohm (6 << 3)
+PAD_CTL_DSE_34ohm (7 << 3)
+PAD_CTL_SRE_FAST (1 << 0)
+PAD_CTL_SRE_SLOW (0 << 0)
+
+Refer to imx6sl-pinfunc.h in device tree source folder for all available
+imx6sl PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
new file mode 100644
index 000000000000..b3aa90f0ce44
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-vt8500.txt
@@ -0,0 +1,57 @@
+VIA VT8500 and Wondermedia WM8xxx-series pinmux/gpio controller
+
+These SoCs contain a combined Pinmux/GPIO module. Each pin may operate as
+either a GPIO in, GPIO out or as an alternate function (I2C, SPI etc).
+
+Required properties:
+- compatible: "via,vt8500-pinctrl", "wm,wm8505-pinctrl", "wm,wm8650-pinctrl",
+ "wm8750-pinctrl" or "wm,wm8850-pinctrl"
+- reg: Should contain the physical address of the module's registers.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional parameters.
+ bit 0 - active low
+
+Please refer to ../gpio/gpio.txt for a general description of GPIO bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Each pin configuration node lists the pin(s) to which it applies, and one or
+more of the mux functions to select on those pin(s), and pull-up/down
+configuration. Each subnode only affects those parameters that are explicitly
+listed. In other words, a subnode that lists only a mux function implies no
+information about any pull configuration. Similarly, a subnode that lists only
+a pull parameter implies no information about the mux function.
+
+Required subnode-properties:
+- wm,pins: An array of cells. Each cell contains the ID of a pin.
+
+Optional subnode-properties:
+- wm,function: Integer, containing the function to mux to the pin(s):
+ 0: GPIO in
+ 1: GPIO out
+ 2: alternate
+
+- wm,pull: Integer, representing the pull-down/up to apply to the pin(s):
+ 0: none
+ 1: down
+ 2: up
+
+Each of wm,function and wm,pull may contain either a single value which
+will be applied to all pins in wm,pins, or one value for each entry in
+wm,pins.
+
+Example:
+
+ pinctrl: pinctrl {
+ compatible = "wm,wm8505-pinctrl";
+ reg = <0xD8110000 0x10000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
new file mode 100644
index 000000000000..922c30ad90d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
@@ -0,0 +1,22 @@
+===================================================================
+Power Architecture CPU Binding
+Copyright 2013 Freescale Semiconductor Inc.
+
+Power Architecture CPUs in Freescale SOCs are represented in device trees as
+per the definition in ePAPR.
+
+In addition to the ePAPR definitions, the properties defined below may be
+present on CPU nodes.
+
+PROPERTIES
+
+ - fsl,eref-*
+ Usage: optional
+ Value type: <empty>
+ Definition: The EREF (EREF: A Programmer.s Reference Manual for
+ Freescale Power Architecture) defines the architecture for Freescale
+ Power CPUs. The EREF defines some architecture categories not defined
+ by the Power ISA. For these EREF-specific categories, the existence of
+ a property named fsl,eref-[CAT], where [CAT] is the abbreviated category
+ name with all uppercase letters converted to lowercase, indicates that
+ the category is supported by the implementation.
diff --git a/Documentation/devicetree/bindings/reset/reset.txt b/Documentation/devicetree/bindings/reset/reset.txt
new file mode 100644
index 000000000000..31db6ff84908
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/reset.txt
@@ -0,0 +1,75 @@
+= Reset Signal Device Tree Bindings =
+
+This binding is intended to represent the hardware reset signals present
+internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
+standalone chips are most likely better represented as GPIOs, although there
+are likely to be exceptions to this rule.
+
+Hardware blocks typically receive a reset signal. This signal is generated by
+a reset provider (e.g. power management or clock module) and received by a
+reset consumer (the module being reset, or a module managing when a sub-
+ordinate module is reset). This binding exists to represent the provider and
+consumer, and provide a way to couple the two together.
+
+A reset signal is represented by the phandle of the provider, plus a reset
+specifier - a list of DT cells that represents the reset signal within the
+provider. The length (number of cells) and semantics of the reset specifier
+are dictated by the binding of the reset provider, although common schemes
+are described below.
+
+A word on where to place reset signal consumers in device tree: It is possible
+in hardware for a reset signal to affect multiple logically separate HW blocks
+at once. In this case, it would be unwise to represent this reset signal in
+the DT node of each affected HW block, since if activated, an unrelated block
+may be reset. Instead, reset signals should be represented in the DT node
+where it makes most sense to control it; this may be a bus node if all
+children of the bus are affected by the reset signal, or an individual HW
+block node for dedicated reset signals. The intent of this binding is to give
+appropriate software access to the reset signals in order to manage the HW,
+rather than to slavishly enumerate the reset signal that affects each HW
+block.
+
+= Reset providers =
+
+Required properties:
+#reset-cells: Number of cells in a reset specifier; Typically 0 for nodes
+ with a single reset output and 1 for nodes with multiple
+ reset outputs.
+
+For example:
+
+ rst: reset-controller {
+ #reset-cells = <1>;
+ };
+
+= Reset consumers =
+
+Required properties:
+resets: List of phandle and reset specifier pairs, one pair
+ for each reset signal that affects the device, or that the
+ device manages. Note: if the reset provider specifies '0' for
+ #reset-cells, then only the phandle portion of the pair will
+ appear.
+
+Optional properties:
+reset-names: List of reset signal name strings sorted in the same order as
+ the resets property. Consumers drivers will use reset-names to
+ match reset signal names with reset specifiers.
+
+For example:
+
+ device {
+ resets = <&rst 20>;
+ reset-names = "reset";
+ };
+
+This represents a device with a single reset signal named "reset".
+
+ bus {
+ resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>;
+ reset-names = "i2s1", "i2s2", "dma", "mixer";
+ };
+
+This represents a bus that controls the reset signal of each of four sub-
+ordinate devices. Consider for example a bus that fails to operate unless no
+child device has reset asserted.
diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
new file mode 100644
index 000000000000..07ccdaa68324
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
@@ -0,0 +1,13 @@
+BCM2835 Random number generator
+
+Required properties:
+
+- compatible : should be "brcm,bcm2835-rng"
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+rng {
+ compatible = "brcm,bcm2835-rng";
+ reg = <0x7e104000 0x10>;
+};
diff --git a/Documentation/devicetree/bindings/sound/ak5386.txt b/Documentation/devicetree/bindings/sound/ak5386.txt
new file mode 100644
index 000000000000..dc3914fe6ce8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ak5386.txt
@@ -0,0 +1,19 @@
+AK5386 Single-ended 24-Bit 192kHz delta-sigma ADC
+
+This device has no control interface.
+
+Required properties:
+
+ - compatible : "asahi-kasei,ak5386"
+
+Optional properties:
+
+ - reset-gpio : a GPIO spec for the reset/power down pin.
+ If specified, it will be deasserted at probe time.
+
+Example:
+
+spdif: ak5386@0 {
+ compatible = "asahi-kasei,ak5386";
+ reset-gpio = <&gpio0 23>;
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
index 1ac7b1642186..0e5c12c66523 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
@@ -1,12 +1,22 @@
NVIDIA Tegra30 AHUB (Audio Hub)
Required properties:
-- compatible : "nvidia,tegra30-ahub"
+- compatible : "nvidia,tegra30-ahub", "nvidia,tegra114-ahub", etc.
- reg : Should contain the register physical address and length for each of
- the AHUB's APBIF registers and the AHUB's own registers.
+ the AHUB's register blocks.
+ - Tegra30 requires 2 entries, for the APBIF and AHUB/AUDIO register blocks.
+ - Tegra114 requires an additional entry, for the APBIF2 register block.
- interrupts : Should contain AHUB interrupt
-- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
- request selector for the first APBIF channel.
+- nvidia,dma-request-selector : A list of the DMA channel specifiers. Each
+ entry contains the Tegra DMA controller's phandle and request selector.
+ If a single entry is present, the request selectors for the channels are
+ assumed to be contiguous, and increment from this value.
+ If multiple values are given, one value must be given per channel.
+- clocks : Must contain an entry for each required entry in clock-names.
+- clock-names : Must include the following entries:
+ - Tegra30: Requires d_audio, apbif, i2s0, i2s1, i2s2, i2s3, i2s4, dam0,
+ dam1, dam2, spdif_in.
+ - Tegra114: Additionally requires amx, adx.
- ranges : The bus address mapping for the configlink register bus.
Can be empty since the mapping is 1:1.
- #address-cells : For the configlink bus. Should be <1>;
@@ -25,7 +35,13 @@ ahub@70080000 {
reg = <0x70080000 0x200 0x70080200 0x100>;
interrupts = < 0 103 0x04 >;
nvidia,dma-request-selector = <&apbdma 1>;
-
+ clocks = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>,
+ <&tegra_car 11>, <&tegra_car 18>, <&tegra_car 101>,
+ <&tegra_car 102>, <&tegra_car 108>, <&tegra_car 109>,
+ <&tegra_car 110>, <&tegra_car 162>;
+ clock-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2",
+ "i2s3", "i2s4", "dam0", "dam1", "dam2",
+ "spdif_in";
ranges;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/Documentation/devicetree/bindings/sound/ti,tas5086.txt b/Documentation/devicetree/bindings/sound/ti,tas5086.txt
new file mode 100644
index 000000000000..8ea4f5b4818d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,tas5086.txt
@@ -0,0 +1,32 @@
+Texas Instruments TAS5086 6-channel PWM Processor
+
+Required properties:
+
+ - compatible: Should contain "ti,tas5086".
+ - reg: The i2c address. Should contain <0x1b>.
+
+Optional properties:
+
+ - reset-gpio: A GPIO spec to define which pin is connected to the
+ chip's !RESET pin. If specified, the driver will
+ assert a hardware reset at probe time.
+
+ - ti,charge-period: This property should contain the time in microseconds
+ that closely matches the external single-ended
+ split-capacitor charge period. The hardware chip
+ waits for this period of time before starting the
+ PWM signals. This helps reduce pops and clicks.
+
+ When not specified, the hardware default of 1300ms
+ is retained.
+
+Examples:
+
+ i2c_bus {
+ tas5086@1b {
+ compatible = "ti,tas5086";
+ reg = <0x1b>;
+ reset-gpio = <&gpio 23 0>;
+ ti,charge-period = <156000>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt b/Documentation/devicetree/bindings/sound/wm8994.txt
index 7a7eb1e7bda6..f2f3e80934d2 100644
--- a/Documentation/devicetree/bindings/sound/wm8994.txt
+++ b/Documentation/devicetree/bindings/sound/wm8994.txt
@@ -5,14 +5,70 @@ on the board).
Required properties:
- - compatible : "wlf,wm1811", "wlf,wm8994", "wlf,wm8958"
+ - compatible : One of "wlf,wm1811", "wlf,wm8994" or "wlf,wm8958".
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
+ - gpio-controller : Indicates this device is a GPIO controller.
+ - #gpio-cells : Must be 2. The first cell is the pin number and the
+ second cell is used to specify optional parameters (currently unused).
+
+ - AVDD2-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
+ SPKVDD1-supply, SPKVDD2-supply : power supplies for the device, as covered
+ in Documentation/devicetree/bindings/regulator/regulator.txt
+
+Optional properties:
+
+ - interrupts : The interrupt line the IRQ signal for the device is
+ connected to. This is optional, if it is not connected then none
+ of the interrupt related properties should be specified.
+ - interrupt-controller : These devices contain interrupt controllers
+ and may provide interrupt services to other devices if they have an
+ interrupt line connected.
+ - interrupt-parent : The parent interrupt controller.
+ - #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
+ The first cell is the IRQ number.
+ The second cell is the flags, encoded as the trigger masks from
+ Documentation/devicetree/bindings/interrupts.txt
+
+ - wlf,gpio-cfg : A list of GPIO configuration register values. If absent,
+ no configuration of these registers is performed. If any value is
+ over 0xffff then the register will be left as default. If present 11
+ values must be supplied.
+
+ - wlf,micbias-cfg : Two MICBIAS register values for WM1811 or
+ WM8958. If absent the register defaults will be used.
+
+ - wlf,ldo1ena : GPIO specifier for control of LDO1ENA input to device.
+ - wlf,ldo2ena : GPIO specifier for control of LDO2ENA input to device.
+
+ - wlf,lineout1-se : If present LINEOUT1 is in single ended mode.
+ - wlf,lineout2-se : If present LINEOUT2 is in single ended mode.
+
+ - wlf,lineout1-feedback : If present LINEOUT1 has common mode feedback
+ connected.
+ - wlf,lineout2-feedback : If present LINEOUT2 has common mode feedback
+ connected.
+
+ - wlf,ldoena-always-driven : If present LDOENA is always driven.
+
Example:
codec: wm8994@1a {
compatible = "wlf,wm8994";
reg = <0x1a>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ lineout1-se;
+
+ AVDD2-supply = <&regulator>;
+ CPVDD-supply = <&regulator>;
+ DBVDD1-supply = <&regulator>;
+ DBVDD2-supply = <&regulator>;
+ DBVDD3-supply = <&regulator>;
+ SPKVDD1-supply = <&regulator>;
+ SPKVDD2-supply = <&regulator>;
};
diff --git a/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
index 0c7b64e95a61..48aeb7884ed3 100644
--- a/Documentation/devicetree/bindings/timer/allwinner,sunxi-timer.txt
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
@@ -2,7 +2,7 @@ Allwinner A1X SoCs Timer Controller
Required properties:
-- compatible : should be "allwinner,sunxi-timer"
+- compatible : should be "allwinner,sun4i-timer"
- reg : Specifies base physical address and size of the registers.
- interrupts : The interrupt of the first timer
- clocks: phandle to the source clock (usually a 24 MHz fixed clock)
@@ -10,7 +10,7 @@ Required properties:
Example:
timer {
- compatible = "allwinner,sunxi-timer";
+ compatible = "allwinner,sun4i-timer";
reg = <0x01c20c00 0x400>;
interrupts = <22>;
clocks = <&osc>;
diff --git a/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
new file mode 100644
index 000000000000..993695c659e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/cadence,ttc-timer.txt
@@ -0,0 +1,17 @@
+Cadence TTC - Triple Timer Counter
+
+Required properties:
+- compatible : Should be "cdns,ttc".
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 3 interrupts; one per timer channel.
+- clocks: phandle to the source clock
+
+Example:
+
+ttc0: ttc0@f8001000 {
+ interrupt-parent = <&intc>;
+ interrupts = < 0 10 4 0 11 4 0 12 4 >;
+ compatible = "cdns,ttc";
+ reg = <0xF8001000 0x1000>;
+ clocks = <&cpu_clk 3>;
+};
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
new file mode 100644
index 000000000000..9809b11f7180
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
@@ -0,0 +1,18 @@
+Freescale i.MX General Purpose Timer (GPT)
+
+Required properties:
+
+- compatible : should be "fsl,<soc>-gpt"
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 4 interrupts; one per timer channel.
+- clocks : The clocks provided by the SoC to drive the timer.
+
+Example:
+
+gpt1: timer@10003000 {
+ compatible = "fsl,imx27-gpt", "fsl,imx1-gpt";
+ reg = <0x10003000 0x1000>;
+ interrupts = <26>;
+ clocks = <&clks 46>, <&clks 61>;
+ clock-names = "ipg", "per";
+};
diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
new file mode 100644
index 000000000000..cb47bfbcaeea
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
@@ -0,0 +1,68 @@
+Samsung's Multi Core Timer (MCT)
+
+The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
+global timer and CPU local timers. The global timer is a 64-bit free running
+up-counter and can generate 4 interrupts when the counter reaches one of the
+four preset counter values. The CPU local timers are 32-bit free running
+down-counters and generate an interrupt when the counter expires. There is
+one CPU local timer instantiated in MCT for every CPU in the system.
+
+Required properties:
+
+- compatible: should be "samsung,exynos4210-mct".
+ (a) "samsung,exynos4210-mct", for mct compatible with Exynos4210 mct.
+ (b) "samsung,exynos4412-mct", for mct compatible with Exynos4412 mct.
+
+- reg: base address of the mct controller and length of the address space
+ it occupies.
+
+- interrupts: the list of interrupts generated by the controller. The following
+ should be the order of the interrupts specified. The local timer interrupts
+ should be specified after the four global timer interrupts have been
+ specified.
+
+ 0: Global Timer Interrupt 0
+ 1: Global Timer Interrupt 1
+ 2: Global Timer Interrupt 2
+ 3: Global Timer Interrupt 3
+ 4: Local Timer Interrupt 0
+ 5: Local Timer Interrupt 1
+ 6: ..
+ 7: ..
+ i: Local Timer Interrupt n
+
+Example 1: In this example, the system uses only the first global timer
+ interrupt generated by MCT and the remaining three global timer
+ interrupts are unused. Two local timer interrupts have been
+ specified.
+
+ mct@10050000 {
+ compatible = "samsung,exynos4210-mct";
+ reg = <0x10050000 0x800>;
+ interrupts = <0 57 0>, <0 0 0>, <0 0 0>, <0 0 0>,
+ <0 42 0>, <0 48 0>;
+ };
+
+Example 2: In this example, the MCT global and local timer interrupts are
+ connected to two seperate interrupt controllers. Hence, an
+ interrupt-map is created to map the interrupts to the respective
+ interrupt controllers.
+
+ mct@101C0000 {
+ compatible = "samsung,exynos4210-mct";
+ reg = <0x101C0000 0x800>;
+ interrupt-controller;
+ #interrups-cells = <2>;
+ interrupt-parent = <&mct_map>;
+ interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
+ <4 0>, <5 0>;
+
+ mct_map: mct-map {
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0x0 0 &combiner 23 3>,
+ <0x4 0 &gic 0 120 0>,
+ <0x5 0 &gic 0 121 0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 000000000000..f66fcddba46f
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,40 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
+ EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Optional properties:
+ - samsung,vbus-gpio: if present, specifies the GPIO that
+ needs to be pulled up for the bus to be powered.
+
+Example:
+
+ usb@12110000 {
+ compatible = "samsung,exynos4210-ehci";
+ reg = <0x12110000 0x100>;
+ interrupts = <0 71 0>;
+ samsung,vbus-gpio = <&gpx2 6 1 3 3>;
+ };
+
+OHCI
+Required properties:
+ - compatible: should be "samsung,exynos4210-ohci" for USB 2.0
+ OHCI companion controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Example:
+ usb@12120000 {
+ compatible = "samsung,exynos4210-ohci";
+ reg = <0x12120000 0x100>;
+ interrupts = <0 71 0>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
index 0b2717775600..ecd650adff31 100644
--- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/sun4i-wdt.txt
@@ -1,13 +1,13 @@
-Allwinner sunXi Watchdog timer
+Allwinner sun4i Watchdog timer
Required properties:
-- compatible : should be "allwinner,sunxi-wdt"
+- compatible : should be "allwinner,sun4i-wdt"
- reg : Specifies base physical address and size of the registers.
Example:
wdt: watchdog@01c20c90 {
- compatible = "allwinner,sunxi-wdt";
+ compatible = "allwinner,sun4i-wdt";
reg = <0x01c20c90 0x10>;
};
diff --git a/Documentation/filesystems/nfs/00-INDEX b/Documentation/filesystems/nfs/00-INDEX
index 1716874a651e..66eb6c8c5334 100644
--- a/Documentation/filesystems/nfs/00-INDEX
+++ b/Documentation/filesystems/nfs/00-INDEX
@@ -20,3 +20,5 @@ rpc-cache.txt
- introduction to the caching mechanisms in the sunrpc layer.
idmapper.txt
- information for configuring request-keys to be used by idmapper
+knfsd-rpcgss.txt
+ - Information on GSS authentication support in the NFS Server
diff --git a/Documentation/filesystems/nfs/rpc-server-gss.txt b/Documentation/filesystems/nfs/rpc-server-gss.txt
new file mode 100644
index 000000000000..716f4be8e8b3
--- /dev/null
+++ b/Documentation/filesystems/nfs/rpc-server-gss.txt
@@ -0,0 +1,91 @@
+
+rpcsec_gss support for kernel RPC servers
+=========================================
+
+This document gives references to the standards and protocols used to
+implement RPCGSS authentication in kernel RPC servers such as the NFS
+server and the NFS client's NFSv4.0 callback server. (But note that
+NFSv4.1 and higher don't require the client to act as a server for the
+purposes of authentication.)
+
+RPCGSS is specified in a few IETF documents:
+ - RFC2203 v1: http://tools.ietf.org/rfc/rfc2203.txt
+ - RFC5403 v2: http://tools.ietf.org/rfc/rfc5403.txt
+and there is a 3rd version being proposed:
+ - http://tools.ietf.org/id/draft-williams-rpcsecgssv3.txt
+ (At draft n. 02 at the time of writing)
+
+Background
+----------
+
+The RPCGSS Authentication method describes a way to perform GSSAPI
+Authentication for NFS. Although GSSAPI is itself completely mechanism
+agnostic, in many cases only the KRB5 mechanism is supported by NFS
+implementations.
+
+The Linux kernel, at the moment, supports only the KRB5 mechanism, and
+depends on GSSAPI extensions that are KRB5 specific.
+
+GSSAPI is a complex library, and implementing it completely in kernel is
+unwarranted. However GSSAPI operations are fundementally separable in 2
+parts:
+- initial context establishment
+- integrity/privacy protection (signing and encrypting of individual
+ packets)
+
+The former is more complex and policy-independent, but less
+performance-sensitive. The latter is simpler and needs to be very fast.
+
+Therefore, we perform per-packet integrity and privacy protection in the
+kernel, but leave the initial context establishment to userspace. We
+need upcalls to request userspace to perform context establishment.
+
+NFS Server Legacy Upcall Mechanism
+----------------------------------
+
+The classic upcall mechanism uses a custom text based upcall mechanism
+to talk to a custom daemon called rpc.svcgssd that is provide by the
+nfs-utils package.
+
+This upcall mechanism has 2 limitations:
+
+A) It can handle tokens that are no bigger than 2KiB
+
+In some Kerberos deployment GSSAPI tokens can be quite big, up and
+beyond 64KiB in size due to various authorization extensions attacked to
+the Kerberos tickets, that needs to be sent through the GSS layer in
+order to perform context establishment.
+
+B) It does not properly handle creds where the user is member of more
+than a few housand groups (the current hard limit in the kernel is 65K
+groups) due to limitation on the size of the buffer that can be send
+back to the kernel (4KiB).
+
+NFS Server New RPC Upcall Mechanism
+-----------------------------------
+
+The newer upcall mechanism uses RPC over a unix socket to a daemon
+called gss-proxy, implemented by a userspace program called Gssproxy.
+
+The gss_proxy RPC protocol is currently documented here:
+
+ https://fedorahosted.org/gss-proxy/wiki/ProtocolDocumentation
+
+This upcall mechanism uses the kernel rpc client and connects to the gssproxy
+userspace program over a regular unix socket. The gssproxy protocol does not
+suffer from the size limitations of the legacy protocol.
+
+Negotiating Upcall Mechanisms
+-----------------------------
+
+To provide backward compatibility, the kernel defaults to using the
+legacy mechanism. To switch to the new mechanism, gss-proxy must bind
+to /var/run/gssproxy.sock and then write "1" to
+/proc/net/rpc/use-gss-proxy. If gss-proxy dies, it must repeat both
+steps.
+
+Once the upcall mechanism is chosen, it cannot be changed. To prevent
+locking into the legacy mechanisms, the above steps must be performed
+before starting nfsd. Whoever starts nfsd can guarantee this by reading
+from /proc/net/rpc/use-gss-proxy and checking that it contains a
+"1"--the read will block until gss-proxy has done its write to the file.
diff --git a/Documentation/filesystems/xfs-self-describing-metadata.txt b/Documentation/filesystems/xfs-self-describing-metadata.txt
new file mode 100644
index 000000000000..05aa455163e3
--- /dev/null
+++ b/Documentation/filesystems/xfs-self-describing-metadata.txt
@@ -0,0 +1,350 @@
+XFS Self Describing Metadata
+----------------------------
+
+Introduction
+------------
+
+The largest scalability problem facing XFS is not one of algorithmic
+scalability, but of verification of the filesystem structure. Scalabilty of the
+structures and indexes on disk and the algorithms for iterating them are
+adequate for supporting PB scale filesystems with billions of inodes, however it
+is this very scalability that causes the verification problem.
+
+Almost all metadata on XFS is dynamically allocated. The only fixed location
+metadata is the allocation group headers (SB, AGF, AGFL and AGI), while all
+other metadata structures need to be discovered by walking the filesystem
+structure in different ways. While this is already done by userspace tools for
+validating and repairing the structure, there are limits to what they can
+verify, and this in turn limits the supportable size of an XFS filesystem.
+
+For example, it is entirely possible to manually use xfs_db and a bit of
+scripting to analyse the structure of a 100TB filesystem when trying to
+determine the root cause of a corruption problem, but it is still mainly a
+manual task of verifying that things like single bit errors or misplaced writes
+weren't the ultimate cause of a corruption event. It may take a few hours to a
+few days to perform such forensic analysis, so for at this scale root cause
+analysis is entirely possible.
+
+However, if we scale the filesystem up to 1PB, we now have 10x as much metadata
+to analyse and so that analysis blows out towards weeks/months of forensic work.
+Most of the analysis work is slow and tedious, so as the amount of analysis goes
+up, the more likely that the cause will be lost in the noise. Hence the primary
+concern for supporting PB scale filesystems is minimising the time and effort
+required for basic forensic analysis of the filesystem structure.
+
+
+Self Describing Metadata
+------------------------
+
+One of the problems with the current metadata format is that apart from the
+magic number in the metadata block, we have no other way of identifying what it
+is supposed to be. We can't even identify if it is the right place. Put simply,
+you can't look at a single metadata block in isolation and say "yes, it is
+supposed to be there and the contents are valid".
+
+Hence most of the time spent on forensic analysis is spent doing basic
+verification of metadata values, looking for values that are in range (and hence
+not detected by automated verification checks) but are not correct. Finding and
+understanding how things like cross linked block lists (e.g. sibling
+pointers in a btree end up with loops in them) are the key to understanding what
+went wrong, but it is impossible to tell what order the blocks were linked into
+each other or written to disk after the fact.
+
+Hence we need to record more information into the metadata to allow us to
+quickly determine if the metadata is intact and can be ignored for the purpose
+of analysis. We can't protect against every possible type of error, but we can
+ensure that common types of errors are easily detectable. Hence the concept of
+self describing metadata.
+
+The first, fundamental requirement of self describing metadata is that the
+metadata object contains some form of unique identifier in a well known
+location. This allows us to identify the expected contents of the block and
+hence parse and verify the metadata object. IF we can't independently identify
+the type of metadata in the object, then the metadata doesn't describe itself
+very well at all!
+
+Luckily, almost all XFS metadata has magic numbers embedded already - only the
+AGFL, remote symlinks and remote attribute blocks do not contain identifying
+magic numbers. Hence we can change the on-disk format of all these objects to
+add more identifying information and detect this simply by changing the magic
+numbers in the metadata objects. That is, if it has the current magic number,
+the metadata isn't self identifying. If it contains a new magic number, it is
+self identifying and we can do much more expansive automated verification of the
+metadata object at runtime, during forensic analysis or repair.
+
+As a primary concern, self describing metadata needs some form of overall
+integrity checking. We cannot trust the metadata if we cannot verify that it has
+not been changed as a result of external influences. Hence we need some form of
+integrity check, and this is done by adding CRC32c validation to the metadata
+block. If we can verify the block contains the metadata it was intended to
+contain, a large amount of the manual verification work can be skipped.
+
+CRC32c was selected as metadata cannot be more than 64k in length in XFS and
+hence a 32 bit CRC is more than sufficient to detect multi-bit errors in
+metadata blocks. CRC32c is also now hardware accelerated on common CPUs so it is
+fast. So while CRC32c is not the strongest of possible integrity checks that
+could be used, it is more than sufficient for our needs and has relatively
+little overhead. Adding support for larger integrity fields and/or algorithms
+does really provide any extra value over CRC32c, but it does add a lot of
+complexity and so there is no provision for changing the integrity checking
+mechanism.
+
+Self describing metadata needs to contain enough information so that the
+metadata block can be verified as being in the correct place without needing to
+look at any other metadata. This means it needs to contain location information.
+Just adding a block number to the metadata is not sufficient to protect against
+mis-directed writes - a write might be misdirected to the wrong LUN and so be
+written to the "correct block" of the wrong filesystem. Hence location
+information must contain a filesystem identifier as well as a block number.
+
+Another key information point in forensic analysis is knowing who the metadata
+block belongs to. We already know the type, the location, that it is valid
+and/or corrupted, and how long ago that it was last modified. Knowing the owner
+of the block is important as it allows us to find other related metadata to
+determine the scope of the corruption. For example, if we have a extent btree
+object, we don't know what inode it belongs to and hence have to walk the entire
+filesystem to find the owner of the block. Worse, the corruption could mean that
+no owner can be found (i.e. it's an orphan block), and so without an owner field
+in the metadata we have no idea of the scope of the corruption. If we have an
+owner field in the metadata object, we can immediately do top down validation to
+determine the scope of the problem.
+
+Different types of metadata have different owner identifiers. For example,
+directory, attribute and extent tree blocks are all owned by an inode, whilst
+freespace btree blocks are owned by an allocation group. Hence the size and
+contents of the owner field are determined by the type of metadata object we are
+looking at. The owner information can also identify misplaced writes (e.g.
+freespace btree block written to the wrong AG).
+
+Self describing metadata also needs to contain some indication of when it was
+written to the filesystem. One of the key information points when doing forensic
+analysis is how recently the block was modified. Correlation of set of corrupted
+metadata blocks based on modification times is important as it can indicate
+whether the corruptions are related, whether there's been multiple corruption
+events that lead to the eventual failure, and even whether there are corruptions
+present that the run-time verification is not detecting.
+
+For example, we can determine whether a metadata object is supposed to be free
+space or still allocated if it is still referenced by its owner by looking at
+when the free space btree block that contains the block was last written
+compared to when the metadata object itself was last written. If the free space
+block is more recent than the object and the object's owner, then there is a
+very good chance that the block should have been removed from the owner.
+
+To provide this "written timestamp", each metadata block gets the Log Sequence
+Number (LSN) of the most recent transaction it was modified on written into it.
+This number will always increase over the life of the filesystem, and the only
+thing that resets it is running xfs_repair on the filesystem. Further, by use of
+the LSN we can tell if the corrupted metadata all belonged to the same log
+checkpoint and hence have some idea of how much modification occurred between
+the first and last instance of corrupt metadata on disk and, further, how much
+modification occurred between the corruption being written and when it was
+detected.
+
+Runtime Validation
+------------------
+
+Validation of self-describing metadata takes place at runtime in two places:
+
+ - immediately after a successful read from disk
+ - immediately prior to write IO submission
+
+The verification is completely stateless - it is done independently of the
+modification process, and seeks only to check that the metadata is what it says
+it is and that the metadata fields are within bounds and internally consistent.
+As such, we cannot catch all types of corruption that can occur within a block
+as there may be certain limitations that operational state enforces of the
+metadata, or there may be corruption of interblock relationships (e.g. corrupted
+sibling pointer lists). Hence we still need stateful checking in the main code
+body, but in general most of the per-field validation is handled by the
+verifiers.
+
+For read verification, the caller needs to specify the expected type of metadata
+that it should see, and the IO completion process verifies that the metadata
+object matches what was expected. If the verification process fails, then it
+marks the object being read as EFSCORRUPTED. The caller needs to catch this
+error (same as for IO errors), and if it needs to take special action due to a
+verification error it can do so by catching the EFSCORRUPTED error value. If we
+need more discrimination of error type at higher levels, we can define new
+error numbers for different errors as necessary.
+
+The first step in read verification is checking the magic number and determining
+whether CRC validating is necessary. If it is, the CRC32c is calculated and
+compared against the value stored in the object itself. Once this is validated,
+further checks are made against the location information, followed by extensive
+object specific metadata validation. If any of these checks fail, then the
+buffer is considered corrupt and the EFSCORRUPTED error is set appropriately.
+
+Write verification is the opposite of the read verification - first the object
+is extensively verified and if it is OK we then update the LSN from the last
+modification made to the object, After this, we calculate the CRC and insert it
+into the object. Once this is done the write IO is allowed to continue. If any
+error occurs during this process, the buffer is again marked with a EFSCORRUPTED
+error for the higher layers to catch.
+
+Structures
+----------
+
+A typical on-disk structure needs to contain the following information:
+
+struct xfs_ondisk_hdr {
+ __be32 magic; /* magic number */
+ __be32 crc; /* CRC, not logged */
+ uuid_t uuid; /* filesystem identifier */
+ __be64 owner; /* parent object */
+ __be64 blkno; /* location on disk */
+ __be64 lsn; /* last modification in log, not logged */
+};
+
+Depending on the metadata, this information may be part of a header structure
+separate to the metadata contents, or may be distributed through an existing
+structure. The latter occurs with metadata that already contains some of this
+information, such as the superblock and AG headers.
+
+Other metadata may have different formats for the information, but the same
+level of information is generally provided. For example:
+
+ - short btree blocks have a 32 bit owner (ag number) and a 32 bit block
+ number for location. The two of these combined provide the same
+ information as @owner and @blkno in eh above structure, but using 8
+ bytes less space on disk.
+
+ - directory/attribute node blocks have a 16 bit magic number, and the
+ header that contains the magic number has other information in it as
+ well. hence the additional metadata headers change the overall format
+ of the metadata.
+
+A typical buffer read verifier is structured as follows:
+
+#define XFS_FOO_CRC_OFF offsetof(struct xfs_ondisk_hdr, crc)
+
+static void
+xfs_foo_read_verify(
+ struct xfs_buf *bp)
+{
+ struct xfs_mount *mp = bp->b_target->bt_mount;
+
+ if ((xfs_sb_version_hascrc(&mp->m_sb) &&
+ !xfs_verify_cksum(bp->b_addr, BBTOB(bp->b_length),
+ XFS_FOO_CRC_OFF)) ||
+ !xfs_foo_verify(bp)) {
+ XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, bp->b_addr);
+ xfs_buf_ioerror(bp, EFSCORRUPTED);
+ }
+}
+
+The code ensures that the CRC is only checked if the filesystem has CRCs enabled
+by checking the superblock of the feature bit, and then if the CRC verifies OK
+(or is not needed) it verifies the actual contents of the block.
+
+The verifier function will take a couple of different forms, depending on
+whether the magic number can be used to determine the format of the block. In
+the case it can't, the code is structured as follows:
+
+static bool
+xfs_foo_verify(
+ struct xfs_buf *bp)
+{
+ struct xfs_mount *mp = bp->b_target->bt_mount;
+ struct xfs_ondisk_hdr *hdr = bp->b_addr;
+
+ if (hdr->magic != cpu_to_be32(XFS_FOO_MAGIC))
+ return false;
+
+ if (!xfs_sb_version_hascrc(&mp->m_sb)) {
+ if (!uuid_equal(&hdr->uuid, &mp->m_sb.sb_uuid))
+ return false;
+ if (bp->b_bn != be64_to_cpu(hdr->blkno))
+ return false;
+ if (hdr->owner == 0)
+ return false;
+ }
+
+ /* object specific verification checks here */
+
+ return true;
+}
+
+If there are different magic numbers for the different formats, the verifier
+will look like:
+
+static bool
+xfs_foo_verify(
+ struct xfs_buf *bp)
+{
+ struct xfs_mount *mp = bp->b_target->bt_mount;
+ struct xfs_ondisk_hdr *hdr = bp->b_addr;
+
+ if (hdr->magic == cpu_to_be32(XFS_FOO_CRC_MAGIC)) {
+ if (!uuid_equal(&hdr->uuid, &mp->m_sb.sb_uuid))
+ return false;
+ if (bp->b_bn != be64_to_cpu(hdr->blkno))
+ return false;
+ if (hdr->owner == 0)
+ return false;
+ } else if (hdr->magic != cpu_to_be32(XFS_FOO_MAGIC))
+ return false;
+
+ /* object specific verification checks here */
+
+ return true;
+}
+
+Write verifiers are very similar to the read verifiers, they just do things in
+the opposite order to the read verifiers. A typical write verifier:
+
+static void
+xfs_foo_write_verify(
+ struct xfs_buf *bp)
+{
+ struct xfs_mount *mp = bp->b_target->bt_mount;
+ struct xfs_buf_log_item *bip = bp->b_fspriv;
+
+ if (!xfs_foo_verify(bp)) {
+ XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, bp->b_addr);
+ xfs_buf_ioerror(bp, EFSCORRUPTED);
+ return;
+ }
+
+ if (!xfs_sb_version_hascrc(&mp->m_sb))
+ return;
+
+
+ if (bip) {
+ struct xfs_ondisk_hdr *hdr = bp->b_addr;
+ hdr->lsn = cpu_to_be64(bip->bli_item.li_lsn);
+ }
+ xfs_update_cksum(bp->b_addr, BBTOB(bp->b_length), XFS_FOO_CRC_OFF);
+}
+
+This will verify the internal structure of the metadata before we go any
+further, detecting corruptions that have occurred as the metadata has been
+modified in memory. If the metadata verifies OK, and CRCs are enabled, we then
+update the LSN field (when it was last modified) and calculate the CRC on the
+metadata. Once this is done, we can issue the IO.
+
+Inodes and Dquots
+-----------------
+
+Inodes and dquots are special snowflakes. They have per-object CRC and
+self-identifiers, but they are packed so that there are multiple objects per
+buffer. Hence we do not use per-buffer verifiers to do the work of per-object
+verification and CRC calculations. The per-buffer verifiers simply perform basic
+identification of the buffer - that they contain inodes or dquots, and that
+there are magic numbers in all the expected spots. All further CRC and
+verification checks are done when each inode is read from or written back to the
+buffer.
+
+The structure of the verifiers and the identifiers checks is very similar to the
+buffer code described above. The only difference is where they are called. For
+example, inode read verification is done in xfs_iread() when the inode is first
+read out of the buffer and the struct xfs_inode is instantiated. The inode is
+already extensively verified during writeback in xfs_iflush_int, so the only
+addition here is to add the LSN and CRC to the inode as it is copied back into
+the buffer.
+
+XXX: inode unlinked list modification doesn't recalculate the inode CRC! None of
+the unlinked list modifications check or update CRCs, neither during unlink nor
+log recovery. So, it's gone unnoticed until now. This won't matter immediately -
+repair will probably complain about it - but it needs to be fixed.
+
diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt
index 690f52550c80..026e237bbc87 100644
--- a/Documentation/hw_random.txt
+++ b/Documentation/hw_random.txt
@@ -63,7 +63,7 @@ Intel RNG Driver notes:
* FIXME: support poll(2)
- NOTE: request_mem_region was removed, for two reasons:
+ NOTE: request_mem_region was removed, for three reasons:
1) Only one RNG is supported by this driver, 2) The location
used by the RNG is a fixed location in MMIO-addressable memory,
3) users with properly working BIOS e820 handling will always
diff --git a/Documentation/hwmon/lm75 b/Documentation/hwmon/lm75
index 69af1c7db6b7..2560a9c6d445 100644
--- a/Documentation/hwmon/lm75
+++ b/Documentation/hwmon/lm75
@@ -12,11 +12,11 @@ Supported chips:
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/
- * Dallas Semiconductor DS75, DS1775
- Prefixes: 'ds75', 'ds1775'
+ * Dallas Semiconductor (now Maxim) DS75, DS1775, DS7505
+ Prefixes: 'ds75', 'ds1775', 'ds7505'
Addresses scanned: none
- Datasheet: Publicly available at the Dallas Semiconductor website
- http://www.maxim-ic.com/
+ Datasheet: Publicly available at the Maxim website
+ http://www.maximintegrated.com/
* Maxim MAX6625, MAX6626
Prefixes: 'max6625', 'max6626'
Addresses scanned: none
@@ -67,7 +67,8 @@ the temperature falls below the Hysteresis value.
All temperatures are in degrees Celsius, and are guaranteed within a
range of -55 to +125 degrees.
-The LM75 only updates its values each 1.5 seconds; reading it more often
+The driver caches the values for a period varying between 1 second for the
+slowest chips and 125 ms for the fastest chips; reading it more often
will do no harm, but will return 'old' values.
The original LM75 was typically used in combination with LM78-like chips
@@ -78,8 +79,8 @@ The LM75 is essentially an industry standard; there may be other
LM75 clones not listed here, with or without various enhancements,
that are supported. The clones are not detected by the driver, unless
they reproduce the exact register tricks of the original LM75, and must
-therefore be instantiated explicitly. The specific enhancements (such as
-higher resolution) are not currently supported by the driver.
+therefore be instantiated explicitly. Higher resolution up to 12-bit
+is supported by this driver, other specific enhancements are not.
The LM77 is not supported, contrary to what we pretended for a long time.
Both chips are simply not compatible, value encoding differs.
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 8c01a0218a1e..8920f9f5fa9e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -45,6 +45,7 @@ parameter is applicable:
AX25 Appropriate AX.25 support is enabled.
BLACKFIN Blackfin architecture is enabled.
CLK Common clock infrastructure is enabled.
+ CMA Contiguous Memory Area support is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
@@ -1963,6 +1964,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Valid arguments: on, off
Default: on
+ nohz_full= [KNL,BOOT]
+ In kernels built with CONFIG_NO_HZ_FULL=y, set
+ the specified list of CPUs whose tick will be stopped
+ whenever possible. The boot CPU will be forced outside
+ the range to maintain the timekeeping.
+ The CPUs in this range must also be included in the
+ rcu_nocbs= set.
+
noiotrap [SH] Disables trapped I/O port accesses.
noirqdebug [X86-32] Disables the code which attempts to detect and
@@ -2724,6 +2733,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
+ rproc_mem=nn[KMG][@address]
+ [KNL,ARM,CMA] Remoteproc physical memory block.
+ Memory area to be used by remote processor image,
+ managed by CMA.
+
rw [KNL] Mount root device read-write on boot
S [KNL] Run init in single mode
diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt
index 0d98fac8893b..189bab09255a 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -22,6 +22,7 @@ All attributes are read-only.
manfid Manufacturer ID (from CID Register)
name Product Name (from CID Register)
oemid OEM/Application ID (from CID Register)
+ prv Product Revision (from CID Register) (SD and MMCv4 only)
serial Product Serial Number (from CID Register)
erase_size Erase group size
preferred_erase_size Preferred erase size
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index 5620fb5ac425..dd9e92802ec0 100644
--- a/Documentation/powerpc/00-INDEX
+++ b/Documentation/powerpc/00-INDEX
@@ -14,10 +14,6 @@ hvcs.txt
- IBM "Hypervisor Virtual Console Server" Installation Guide
mpc52xx.txt
- Linux 2.6.x on MPC52xx family
-sound.txt
- - info on sound support under Linux/PPC
-zImage_layout.txt
- - info on the kernel images for Linux/PPC
qe_firmware.txt
- describes the layout of firmware binaries for the Freescale QUICC
Engine and the code that parses and uploads the microcode therein.
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
index f2a7a3919772..99c5ce88d0fe 100644
--- a/Documentation/powerpc/ptrace.txt
+++ b/Documentation/powerpc/ptrace.txt
@@ -40,6 +40,7 @@ features will have bits indicating whether there is support for:
#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
+#define PPC_DEBUG_FEATURE_DATA_BP_DAWR 0x10
2. PTRACE_SETHWDEBUG
diff --git a/Documentation/powerpc/sound.txt b/Documentation/powerpc/sound.txt
deleted file mode 100644
index df23d95e03a0..000000000000
--- a/Documentation/powerpc/sound.txt
+++ /dev/null
@@ -1,81 +0,0 @@
- Information about PowerPC Sound support
-=====================================================================
-
-Please mail me (Cort Dougan, cort@fsmlabs.com) if you have questions,
-comments or corrections.
-
-Last Change: 6.16.99
-
-This just covers sound on the PReP and CHRP systems for now and later
-will contain information on the PowerMac's.
-
-Sound on PReP has been tested and is working with the PowerStack and IBM
-Power Series onboard sound systems which are based on the cs4231(2) chip.
-The sound options when doing the make config are a bit different from
-the default, though.
-
-The I/O base, irq and dma lines that you enter during the make config
-are ignored and are set when booting according to the machine type.
-This is so that one binary can be used for Motorola and IBM machines
-which use different values and isn't allowed by the driver, so things
-are hacked together in such a way as to allow this information to be
-set automatically on boot.
-
-1. Motorola PowerStack PReP machines
-
- Enable support for "Crystal CS4232 based (PnP) cards" and for the
- Microsoft Sound System. The MSS isn't used, but some of the routines
- that the CS4232 driver uses are in it.
-
- Although the options you set are ignored and determined automatically
- on boot these are included for information only:
-
- (830) CS4232 audio I/O base 530, 604, E80 or F40
- (10) CS4232 audio IRQ 5, 7, 9, 11, 12 or 15
- (6) CS4232 audio DMA 0, 1 or 3
- (7) CS4232 second (duplex) DMA 0, 1 or 3
-
- This will allow simultaneous record and playback, as 2 different dma
- channels are used.
-
- The sound will be all left channel and very low volume since the
- auxiliary input isn't muted by default. I had the changes necessary
- for this in the kernel but the sound driver maintainer didn't want
- to include them since it wasn't common in other machines. To fix this
- you need to mute it using a mixer utility of some sort (if you find one
- please let me know) or by patching the driver yourself and recompiling.
-
- There is a problem on the PowerStack 2's (PowerStack Pro's) using a
- different irq/drq than the kernel expects. Unfortunately, I don't know
- which irq/drq it is so if anyone knows please email me.
-
- Midi is not supported since the cs4232 driver doesn't support midi yet.
-
-2. IBM PowerPersonal PReP machines
-
- I've only tested sound on the Power Personal Series of IBM workstations
- so if you try it on others please let me know the result. I'm especially
- interested in the 43p's sound system, which I know nothing about.
-
- Enable support for "Crystal CS4232 based (PnP) cards" and for the
- Microsoft Sound System. The MSS isn't used, but some of the routines
- that the CS4232 driver uses are in it.
-
- Although the options you set are ignored and determined automatically
- on boot these are included for information only:
-
- (530) CS4232 audio I/O base 530, 604, E80 or F40
- (5) CS4232 audio IRQ 5, 7, 9, 11, 12 or 15
- (1) CS4232 audio DMA 0, 1 or 3
- (7) CS4232 second (duplex) DMA 0, 1 or 3
- (330) CS4232 MIDI I/O base 330, 370, 3B0 or 3F0
- (9) CS4232 MIDI IRQ 5, 7, 9, 11, 12 or 15
-
- This setup does _NOT_ allow for recording yet.
-
- Midi is not supported since the cs4232 driver doesn't support midi yet.
-
-2. IBM CHRP
-
- I have only tested this on the 43P-150. Build the kernel with the cs4232
- set as a module and load the module with irq=9 dma=1 dma2=2 io=0x550
diff --git a/Documentation/powerpc/zImage_layout.txt b/Documentation/powerpc/zImage_layout.txt
deleted file mode 100644
index 048e0150f571..000000000000
--- a/Documentation/powerpc/zImage_layout.txt
+++ /dev/null
@@ -1,47 +0,0 @@
- Information about the Linux/PPC kernel images
-=====================================================================
-
-Please mail me (Cort Dougan, cort@fsmlabs.com) if you have questions,
-comments or corrections.
-
-This document is meant to answer several questions I've had about how
-the PReP system boots and how Linux/PPC interacts with that mechanism.
-It would be nice if we could have information on how other architectures
-boot here as well. If you have anything to contribute, please
-let me know.
-
-
-1. PReP boot file
-
- This is the file necessary to boot PReP systems from floppy or
- hard drive. The firmware reads the PReP partition table entry
- and will load the image accordingly.
-
- To boot the zImage, copy it onto a floppy with dd if=zImage of=/dev/fd0h1440
- or onto a PReP hard drive partition with dd if=zImage of=/dev/sda4
- assuming you've created a PReP partition (type 0x41) with fdisk on
- /dev/sda4.
-
- The layout of the image format is:
-
- 0x0 +------------+
- | | PReP partition table entry
- | |
- 0x400 +------------+
- | | Bootstrap program code + data
- | |
- | |
- +------------+
- | | compressed kernel, elf header removed
- +------------+
- | | initrd (if loaded)
- +------------+
- | | Elf section table for bootstrap program
- +------------+
-
-
-2. MBX boot file
-
- The MBX boards can load an elf image, and relocate it to the
- proper location in memory - it copies the image to the location it was
- linked at.
diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt
index d4faa63ff352..c3c912d023cc 100644
--- a/Documentation/sound/alsa/HD-Audio.txt
+++ b/Documentation/sound/alsa/HD-Audio.txt
@@ -461,11 +461,13 @@ The generic parser supports the following hints:
the corresponding mixer control, if available
- add_stereo_mix_input (bool): add the stereo mix (analog-loopback
mix) to the input mux if available
-- add_out_jack_modes (bool): add "xxx Jack Mode" enum controls to each
- output jack for allowing to change the headphone amp capability
-- add_in_jack_modes (bool): add "xxx Jack Mode" enum controls to each
- input jack for allowing to change the mic bias vref
+- add_jack_modes (bool): add "xxx Jack Mode" enum controls to each
+ I/O jack for allowing to change the headphone amp and mic bias VREF
+ capabilities
- power_down_unused (bool): power down the unused widgets
+- add_hp_mic (bool): add the headphone to capture source if possible
+- hp_mic_detect (bool): enable/disable the hp/mic shared input for a
+ single built-in mic case; default true
- mixer_nid (int): specifies the widget NID of the analog-loopback
mixer
diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt
new file mode 100644
index 000000000000..5b5322024067
--- /dev/null
+++ b/Documentation/timers/NO_HZ.txt
@@ -0,0 +1,273 @@
+ NO_HZ: Reducing Scheduling-Clock Ticks
+
+
+This document describes Kconfig options and boot parameters that can
+reduce the number of scheduling-clock interrupts, thereby improving energy
+efficiency and reducing OS jitter. Reducing OS jitter is important for
+some types of computationally intensive high-performance computing (HPC)
+applications and for real-time applications.
+
+There are two main contexts in which the number of scheduling-clock
+interrupts can be reduced compared to the old-school approach of sending
+a scheduling-clock interrupt to all CPUs every jiffy whether they need
+it or not (CONFIG_HZ_PERIODIC=y or CONFIG_NO_HZ=n for older kernels):
+
+1. Idle CPUs (CONFIG_NO_HZ_IDLE=y or CONFIG_NO_HZ=y for older kernels).
+
+2. CPUs having only one runnable task (CONFIG_NO_HZ_FULL=y).
+
+These two cases are described in the following two sections, followed
+by a third section on RCU-specific considerations and a fourth and final
+section listing known issues.
+
+
+IDLE CPUs
+
+If a CPU is idle, there is little point in sending it a scheduling-clock
+interrupt. After all, the primary purpose of a scheduling-clock interrupt
+is to force a busy CPU to shift its attention among multiple duties,
+and an idle CPU has no duties to shift its attention among.
+
+The CONFIG_NO_HZ_IDLE=y Kconfig option causes the kernel to avoid sending
+scheduling-clock interrupts to idle CPUs, which is critically important
+both to battery-powered devices and to highly virtualized mainframes.
+A battery-powered device running a CONFIG_HZ_PERIODIC=y kernel would
+drain its battery very quickly, easily 2-3 times as fast as would the
+same device running a CONFIG_NO_HZ_IDLE=y kernel. A mainframe running
+1,500 OS instances might find that half of its CPU time was consumed by
+unnecessary scheduling-clock interrupts. In these situations, there
+is strong motivation to avoid sending scheduling-clock interrupts to
+idle CPUs. That said, dyntick-idle mode is not free:
+
+1. It increases the number of instructions executed on the path
+ to and from the idle loop.
+
+2. On many architectures, dyntick-idle mode also increases the
+ number of expensive clock-reprogramming operations.
+
+Therefore, systems with aggressive real-time response constraints often
+run CONFIG_HZ_PERIODIC=y kernels (or CONFIG_NO_HZ=n for older kernels)
+in order to avoid degrading from-idle transition latencies.
+
+An idle CPU that is not receiving scheduling-clock interrupts is said to
+be "dyntick-idle", "in dyntick-idle mode", "in nohz mode", or "running
+tickless". The remainder of this document will use "dyntick-idle mode".
+
+There is also a boot parameter "nohz=" that can be used to disable
+dyntick-idle mode in CONFIG_NO_HZ_IDLE=y kernels by specifying "nohz=off".
+By default, CONFIG_NO_HZ_IDLE=y kernels boot with "nohz=on", enabling
+dyntick-idle mode.
+
+
+CPUs WITH ONLY ONE RUNNABLE TASK
+
+If a CPU has only one runnable task, there is little point in sending it
+a scheduling-clock interrupt because there is no other task to switch to.
+
+The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid
+sending scheduling-clock interrupts to CPUs with a single runnable task,
+and such CPUs are said to be "adaptive-ticks CPUs". This is important
+for applications with aggressive real-time response constraints because
+it allows them to improve their worst-case response times by the maximum
+duration of a scheduling-clock interrupt. It is also important for
+computationally intensive short-iteration workloads: If any CPU is
+delayed during a given iteration, all the other CPUs will be forced to
+wait idle while the delayed CPU finishes. Thus, the delay is multiplied
+by one less than the number of CPUs. In these situations, there is
+again strong motivation to avoid sending scheduling-clock interrupts.
+
+By default, no CPU will be an adaptive-ticks CPU. The "nohz_full="
+boot parameter specifies the adaptive-ticks CPUs. For example,
+"nohz_full=1,6-8" says that CPUs 1, 6, 7, and 8 are to be adaptive-ticks
+CPUs. Note that you are prohibited from marking all of the CPUs as
+adaptive-tick CPUs: At least one non-adaptive-tick CPU must remain
+online to handle timekeeping tasks in order to ensure that system calls
+like gettimeofday() returns accurate values on adaptive-tick CPUs.
+(This is not an issue for CONFIG_NO_HZ_IDLE=y because there are no
+running user processes to observe slight drifts in clock rate.)
+Therefore, the boot CPU is prohibited from entering adaptive-ticks
+mode. Specifying a "nohz_full=" mask that includes the boot CPU will
+result in a boot-time error message, and the boot CPU will be removed
+from the mask.
+
+Alternatively, the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter specifies
+that all CPUs other than the boot CPU are adaptive-ticks CPUs. This
+Kconfig parameter will be overridden by the "nohz_full=" boot parameter,
+so that if both the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter and
+the "nohz_full=1" boot parameter is specified, the boot parameter will
+prevail so that only CPU 1 will be an adaptive-ticks CPU.
+
+Finally, adaptive-ticks CPUs must have their RCU callbacks offloaded.
+This is covered in the "RCU IMPLICATIONS" section below.
+
+Normally, a CPU remains in adaptive-ticks mode as long as possible.
+In particular, transitioning to kernel mode does not automatically change
+the mode. Instead, the CPU will exit adaptive-ticks mode only if needed,
+for example, if that CPU enqueues an RCU callback.
+
+Just as with dyntick-idle mode, the benefits of adaptive-tick mode do
+not come for free:
+
+1. CONFIG_NO_HZ_FULL selects CONFIG_NO_HZ_COMMON, so you cannot run
+ adaptive ticks without also running dyntick idle. This dependency
+ extends down into the implementation, so that all of the costs
+ of CONFIG_NO_HZ_IDLE are also incurred by CONFIG_NO_HZ_FULL.
+
+2. The user/kernel transitions are slightly more expensive due
+ to the need to inform kernel subsystems (such as RCU) about
+ the change in mode.
+
+3. POSIX CPU timers on adaptive-tick CPUs may miss their deadlines
+ (perhaps indefinitely) because they currently rely on
+ scheduling-tick interrupts. This will likely be fixed in
+ one of two ways: (1) Prevent CPUs with POSIX CPU timers from
+ entering adaptive-tick mode, or (2) Use hrtimers or other
+ adaptive-ticks-immune mechanism to cause the POSIX CPU timer to
+ fire properly.
+
+4. If there are more perf events pending than the hardware can
+ accommodate, they are normally round-robined so as to collect
+ all of them over time. Adaptive-tick mode may prevent this
+ round-robining from happening. This will likely be fixed by
+ preventing CPUs with large numbers of perf events pending from
+ entering adaptive-tick mode.
+
+5. Scheduler statistics for adaptive-tick CPUs may be computed
+ slightly differently than those for non-adaptive-tick CPUs.
+ This might in turn perturb load-balancing of real-time tasks.
+
+6. The LB_BIAS scheduler feature is disabled by adaptive ticks.
+
+Although improvements are expected over time, adaptive ticks is quite
+useful for many types of real-time and compute-intensive applications.
+However, the drawbacks listed above mean that adaptive ticks should not
+(yet) be enabled by default.
+
+
+RCU IMPLICATIONS
+
+There are situations in which idle CPUs cannot be permitted to
+enter either dyntick-idle mode or adaptive-tick mode, the most
+common being when that CPU has RCU callbacks pending.
+
+The CONFIG_RCU_FAST_NO_HZ=y Kconfig option may be used to cause such CPUs
+to enter dyntick-idle mode or adaptive-tick mode anyway. In this case,
+a timer will awaken these CPUs every four jiffies in order to ensure
+that the RCU callbacks are processed in a timely fashion.
+
+Another approach is to offload RCU callback processing to "rcuo" kthreads
+using the CONFIG_RCU_NOCB_CPU=y Kconfig option. The specific CPUs to
+offload may be selected via several methods:
+
+1. One of three mutually exclusive Kconfig options specify a
+ build-time default for the CPUs to offload:
+
+ a. The CONFIG_RCU_NOCB_CPU_NONE=y Kconfig option results in
+ no CPUs being offloaded.
+
+ b. The CONFIG_RCU_NOCB_CPU_ZERO=y Kconfig option causes
+ CPU 0 to be offloaded.
+
+ c. The CONFIG_RCU_NOCB_CPU_ALL=y Kconfig option causes all
+ CPUs to be offloaded. Note that the callbacks will be
+ offloaded to "rcuo" kthreads, and that those kthreads
+ will in fact run on some CPU. However, this approach
+ gives fine-grained control on exactly which CPUs the
+ callbacks run on, along with their scheduling priority
+ (including the default of SCHED_OTHER), and it further
+ allows this control to be varied dynamically at runtime.
+
+2. The "rcu_nocbs=" kernel boot parameter, which takes a comma-separated
+ list of CPUs and CPU ranges, for example, "1,3-5" selects CPUs 1,
+ 3, 4, and 5. The specified CPUs will be offloaded in addition to
+ any CPUs specified as offloaded by CONFIG_RCU_NOCB_CPU_ZERO=y or
+ CONFIG_RCU_NOCB_CPU_ALL=y. This means that the "rcu_nocbs=" boot
+ parameter has no effect for kernels built with RCU_NOCB_CPU_ALL=y.
+
+The offloaded CPUs will never queue RCU callbacks, and therefore RCU
+never prevents offloaded CPUs from entering either dyntick-idle mode
+or adaptive-tick mode. That said, note that it is up to userspace to
+pin the "rcuo" kthreads to specific CPUs if desired. Otherwise, the
+scheduler will decide where to run them, which might or might not be
+where you want them to run.
+
+
+KNOWN ISSUES
+
+o Dyntick-idle slows transitions to and from idle slightly.
+ In practice, this has not been a problem except for the most
+ aggressive real-time workloads, which have the option of disabling
+ dyntick-idle mode, an option that most of them take. However,
+ some workloads will no doubt want to use adaptive ticks to
+ eliminate scheduling-clock interrupt latencies. Here are some
+ options for these workloads:
+
+ a. Use PMQOS from userspace to inform the kernel of your
+ latency requirements (preferred).
+
+ b. On x86 systems, use the "idle=mwait" boot parameter.
+
+ c. On x86 systems, use the "intel_idle.max_cstate=" to limit
+ ` the maximum C-state depth.
+
+ d. On x86 systems, use the "idle=poll" boot parameter.
+ However, please note that use of this parameter can cause
+ your CPU to overheat, which may cause thermal throttling
+ to degrade your latencies -- and that this degradation can
+ be even worse than that of dyntick-idle. Furthermore,
+ this parameter effectively disables Turbo Mode on Intel
+ CPUs, which can significantly reduce maximum performance.
+
+o Adaptive-ticks slows user/kernel transitions slightly.
+ This is not expected to be a problem for computationally intensive
+ workloads, which have few such transitions. Careful benchmarking
+ will be required to determine whether or not other workloads
+ are significantly affected by this effect.
+
+o Adaptive-ticks does not do anything unless there is only one
+ runnable task for a given CPU, even though there are a number
+ of other situations where the scheduling-clock tick is not
+ needed. To give but one example, consider a CPU that has one
+ runnable high-priority SCHED_FIFO task and an arbitrary number
+ of low-priority SCHED_OTHER tasks. In this case, the CPU is
+ required to run the SCHED_FIFO task until it either blocks or
+ some other higher-priority task awakens on (or is assigned to)
+ this CPU, so there is no point in sending a scheduling-clock
+ interrupt to this CPU. However, the current implementation
+ nevertheless sends scheduling-clock interrupts to CPUs having a
+ single runnable SCHED_FIFO task and multiple runnable SCHED_OTHER
+ tasks, even though these interrupts are unnecessary.
+
+ Better handling of these sorts of situations is future work.
+
+o A reboot is required to reconfigure both adaptive idle and RCU
+ callback offloading. Runtime reconfiguration could be provided
+ if needed, however, due to the complexity of reconfiguring RCU at
+ runtime, there would need to be an earthshakingly good reason.
+ Especially given that you have the straightforward option of
+ simply offloading RCU callbacks from all CPUs and pinning them
+ where you want them whenever you want them pinned.
+
+o Additional configuration is required to deal with other sources
+ of OS jitter, including interrupts and system-utility tasks
+ and processes. This configuration normally involves binding
+ interrupts and tasks to particular CPUs.
+
+o Some sources of OS jitter can currently be eliminated only by
+ constraining the workload. For example, the only way to eliminate
+ OS jitter due to global TLB shootdowns is to avoid the unmapping
+ operations (such as kernel module unload operations) that
+ result in these shootdowns. For another example, page faults
+ and TLB misses can be reduced (and in some cases eliminated) by
+ using huge pages and by constraining the amount of memory used
+ by the application. Pre-faulting the working set can also be
+ helpful, especially when combined with the mlock() and mlockall()
+ system calls.
+
+o Unless all CPUs are idle, at least one CPU must keep the
+ scheduling-clock interrupt going in order to support accurate
+ timekeeping.
+
+o If there are adaptive-ticks CPUs, there will be at least one
+ CPU keeping the scheduling-clock interrupt going, even if all
+ CPUs are otherwise idle.
diff --git a/Documentation/virtual/00-INDEX b/Documentation/virtual/00-INDEX
index 924bd462675e..e952d30bbf0f 100644
--- a/Documentation/virtual/00-INDEX
+++ b/Documentation/virtual/00-INDEX
@@ -6,6 +6,3 @@ kvm/
- Kernel Virtual Machine. See also http://linux-kvm.org
uml/
- User Mode Linux, builds/runs Linux kernel as a userspace program.
-virtio.txt
- - Text version of draft virtio spec.
- See http://ozlabs.org/~rusty/virtio-spec
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 119358dfb742..5f91eda91647 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1486,15 +1486,23 @@ struct kvm_ioeventfd {
__u8 pad[36];
};
+For the special case of virtio-ccw devices on s390, the ioevent is matched
+to a subchannel/virtqueue tuple instead.
+
The following flags are defined:
#define KVM_IOEVENTFD_FLAG_DATAMATCH (1 << kvm_ioeventfd_flag_nr_datamatch)
#define KVM_IOEVENTFD_FLAG_PIO (1 << kvm_ioeventfd_flag_nr_pio)
#define KVM_IOEVENTFD_FLAG_DEASSIGN (1 << kvm_ioeventfd_flag_nr_deassign)
+#define KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY \
+ (1 << kvm_ioeventfd_flag_nr_virtio_ccw_notify)
If datamatch flag is set, the event will be signaled only if the written value
to the registered address is equal to datamatch in struct kvm_ioeventfd.
+For virtio-ccw devices, addr contains the subchannel id and datamatch the
+virtqueue index.
+
4.60 KVM_DIRTY_TLB
@@ -1780,27 +1788,48 @@ registers, find a list below:
PPC | KVM_REG_PPC_VPA_DTL | 128
PPC | KVM_REG_PPC_EPCR | 32
PPC | KVM_REG_PPC_EPR | 32
+ PPC | KVM_REG_PPC_TCR | 32
+ PPC | KVM_REG_PPC_TSR | 32
+ PPC | KVM_REG_PPC_OR_TSR | 32
+ PPC | KVM_REG_PPC_CLEAR_TSR | 32
+ PPC | KVM_REG_PPC_MAS0 | 32
+ PPC | KVM_REG_PPC_MAS1 | 32
+ PPC | KVM_REG_PPC_MAS2 | 64
+ PPC | KVM_REG_PPC_MAS7_3 | 64
+ PPC | KVM_REG_PPC_MAS4 | 32
+ PPC | KVM_REG_PPC_MAS6 | 32
+ PPC | KVM_REG_PPC_MMUCFG | 32
+ PPC | KVM_REG_PPC_TLB0CFG | 32
+ PPC | KVM_REG_PPC_TLB1CFG | 32
+ PPC | KVM_REG_PPC_TLB2CFG | 32
+ PPC | KVM_REG_PPC_TLB3CFG | 32
+ PPC | KVM_REG_PPC_TLB0PS | 32
+ PPC | KVM_REG_PPC_TLB1PS | 32
+ PPC | KVM_REG_PPC_TLB2PS | 32
+ PPC | KVM_REG_PPC_TLB3PS | 32
+ PPC | KVM_REG_PPC_EPTCFG | 32
+ PPC | KVM_REG_PPC_ICP_STATE | 64
ARM registers are mapped using the lower 32 bits. The upper 16 of that
is the register group type, or coprocessor number:
ARM core registers have the following id bit patterns:
- 0x4002 0000 0010 <index into the kvm_regs struct:16>
+ 0x4020 0000 0010 <index into the kvm_regs struct:16>
ARM 32-bit CP15 registers have the following id bit patterns:
- 0x4002 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
+ 0x4020 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
ARM 64-bit CP15 registers have the following id bit patterns:
- 0x4003 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
+ 0x4030 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
ARM CCSIDR registers are demultiplexed by CSSELR value:
- 0x4002 0000 0011 00 <csselr:8>
+ 0x4020 0000 0011 00 <csselr:8>
ARM 32-bit VFP control registers have the following id bit patterns:
- 0x4002 0000 0012 1 <regno:12>
+ 0x4020 0000 0012 1 <regno:12>
ARM 64-bit FP registers have the following id bit patterns:
- 0x4002 0000 0012 0 <regno:12>
+ 0x4030 0000 0012 0 <regno:12>
4.69 KVM_GET_ONE_REG
@@ -2161,6 +2190,76 @@ header; first `n_valid' valid entries with contents from the data
written, then `n_invalid' invalid entries, invalidating any previously
valid entries found.
+4.79 KVM_CREATE_DEVICE
+
+Capability: KVM_CAP_DEVICE_CTRL
+Type: vm ioctl
+Parameters: struct kvm_create_device (in/out)
+Returns: 0 on success, -1 on error
+Errors:
+ ENODEV: The device type is unknown or unsupported
+ EEXIST: Device already created, and this type of device may not
+ be instantiated multiple times
+
+ Other error conditions may be defined by individual device types or
+ have their standard meanings.
+
+Creates an emulated device in the kernel. The file descriptor returned
+in fd can be used with KVM_SET/GET/HAS_DEVICE_ATTR.
+
+If the KVM_CREATE_DEVICE_TEST flag is set, only test whether the
+device type is supported (not necessarily whether it can be created
+in the current vm).
+
+Individual devices should not define flags. Attributes should be used
+for specifying any behavior that is not implied by the device type
+number.
+
+struct kvm_create_device {
+ __u32 type; /* in: KVM_DEV_TYPE_xxx */
+ __u32 fd; /* out: device handle */
+ __u32 flags; /* in: KVM_CREATE_DEVICE_xxx */
+};
+
+4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
+
+Capability: KVM_CAP_DEVICE_CTRL
+Type: device ioctl
+Parameters: struct kvm_device_attr
+Returns: 0 on success, -1 on error
+Errors:
+ ENXIO: The group or attribute is unknown/unsupported for this device
+ EPERM: The attribute cannot (currently) be accessed this way
+ (e.g. read-only attribute, or attribute that only makes
+ sense when the device is in a different state)
+
+ Other error conditions may be defined by individual device types.
+
+Gets/sets a specified piece of device configuration and/or state. The
+semantics are device-specific. See individual device documentation in
+the "devices" directory. As with ONE_REG, the size of the data
+transferred is defined by the particular attribute.
+
+struct kvm_device_attr {
+ __u32 flags; /* no flags currently defined */
+ __u32 group; /* device-defined */
+ __u64 attr; /* group-defined */
+ __u64 addr; /* userspace address of attr data */
+};
+
+4.81 KVM_HAS_DEVICE_ATTR
+
+Capability: KVM_CAP_DEVICE_CTRL
+Type: device ioctl
+Parameters: struct kvm_device_attr
+Returns: 0 on success, -1 on error
+Errors:
+ ENXIO: The group or attribute is unknown/unsupported for this device
+
+Tests whether a device supports a particular attribute. A successful
+return indicates the attribute is implemented. It does not necessarily
+indicate that the attribute can be read or written in the device's
+current state. "addr" is ignored.
4.77 KVM_ARM_VCPU_INIT
@@ -2243,6 +2342,25 @@ and distributor interface, the ioctl must be called after calling
KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs. Calling
this ioctl twice for any of the base addresses will return -EEXIST.
+4.82 KVM_PPC_RTAS_DEFINE_TOKEN
+
+Capability: KVM_CAP_PPC_RTAS
+Architectures: ppc
+Type: vm ioctl
+Parameters: struct kvm_rtas_token_args
+Returns: 0 on success, -1 on error
+
+Defines a token value for a RTAS (Run Time Abstraction Services)
+service in order to allow it to be handled in the kernel. The
+argument struct gives the name of the service, which must be the name
+of a service that has a kernel-side implementation. If the token
+value is non-zero, it will be associated with that service, and
+subsequent RTAS calls by the guest specifying that token will be
+handled by the kernel. If the token value is 0, then any token
+associated with the service will be forgotten, and subsequent RTAS
+calls by the guest for that service will be passed to userspace to be
+handled.
+
5. The kvm_run structure
------------------------
@@ -2646,3 +2764,19 @@ to receive the topmost interrupt vector.
When disabled (args[0] == 0), behavior is as if this facility is unsupported.
When this capability is enabled, KVM_EXIT_EPR can occur.
+
+6.6 KVM_CAP_IRQ_MPIC
+
+Architectures: ppc
+Parameters: args[0] is the MPIC device fd
+ args[1] is the MPIC CPU number for this vcpu
+
+This capability connects the vcpu to an in-kernel MPIC device.
+
+6.7 KVM_CAP_IRQ_XICS
+
+Architectures: ppc
+Parameters: args[0] is the XICS device fd
+ args[1] is the XICS CPU number (server ID) for this vcpu
+
+This capability connects the vcpu to an in-kernel XICS device.
diff --git a/Documentation/virtual/kvm/devices/README b/Documentation/virtual/kvm/devices/README
new file mode 100644
index 000000000000..34a69834124a
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/README
@@ -0,0 +1 @@
+This directory contains specific device bindings for KVM_CAP_DEVICE_CTRL.
diff --git a/Documentation/virtual/kvm/devices/mpic.txt b/Documentation/virtual/kvm/devices/mpic.txt
new file mode 100644
index 000000000000..8257397adc3c
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/mpic.txt
@@ -0,0 +1,53 @@
+MPIC interrupt controller
+=========================
+
+Device types supported:
+ KVM_DEV_TYPE_FSL_MPIC_20 Freescale MPIC v2.0
+ KVM_DEV_TYPE_FSL_MPIC_42 Freescale MPIC v4.2
+
+Only one MPIC instance, of any type, may be instantiated. The created
+MPIC will act as the system interrupt controller, connecting to each
+vcpu's interrupt inputs.
+
+Groups:
+ KVM_DEV_MPIC_GRP_MISC
+ Attributes:
+ KVM_DEV_MPIC_BASE_ADDR (rw, 64-bit)
+ Base address of the 256 KiB MPIC register space. Must be
+ naturally aligned. A value of zero disables the mapping.
+ Reset value is zero.
+
+ KVM_DEV_MPIC_GRP_REGISTER (rw, 32-bit)
+ Access an MPIC register, as if the access were made from the guest.
+ "attr" is the byte offset into the MPIC register space. Accesses
+ must be 4-byte aligned.
+
+ MSIs may be signaled by using this attribute group to write
+ to the relevant MSIIR.
+
+ KVM_DEV_MPIC_GRP_IRQ_ACTIVE (rw, 32-bit)
+ IRQ input line for each standard openpic source. 0 is inactive and 1
+ is active, regardless of interrupt sense.
+
+ For edge-triggered interrupts: Writing 1 is considered an activating
+ edge, and writing 0 is ignored. Reading returns 1 if a previously
+ signaled edge has not been acknowledged, and 0 otherwise.
+
+ "attr" is the IRQ number. IRQ numbers for standard sources are the
+ byte offset of the relevant IVPR from EIVPR0, divided by 32.
+
+IRQ Routing:
+
+ The MPIC emulation supports IRQ routing. Only a single MPIC device can
+ be instantiated. Once that device has been created, it's available as
+ irqchip id 0.
+
+ This irqchip 0 has 256 interrupt pins, which expose the interrupts in
+ the main array of interrupt sources (a.k.a. "SRC" interrupts).
+
+ The numbering is the same as the MPIC device tree binding -- based on
+ the register offset from the beginning of the sources array, without
+ regard to any subdivisions in chip documentation such as "internal"
+ or "external" interrupts.
+
+ Access to non-SRC interrupts is not implemented through IRQ routing mechanisms.
diff --git a/Documentation/virtual/kvm/devices/xics.txt b/Documentation/virtual/kvm/devices/xics.txt
new file mode 100644
index 000000000000..42864935ac5d
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/xics.txt
@@ -0,0 +1,66 @@
+XICS interrupt controller
+
+Device type supported: KVM_DEV_TYPE_XICS
+
+Groups:
+ KVM_DEV_XICS_SOURCES
+ Attributes: One per interrupt source, indexed by the source number.
+
+This device emulates the XICS (eXternal Interrupt Controller
+Specification) defined in PAPR. The XICS has a set of interrupt
+sources, each identified by a 20-bit source number, and a set of
+Interrupt Control Presentation (ICP) entities, also called "servers",
+each associated with a virtual CPU.
+
+The ICP entities are created by enabling the KVM_CAP_IRQ_ARCH
+capability for each vcpu, specifying KVM_CAP_IRQ_XICS in args[0] and
+the interrupt server number (i.e. the vcpu number from the XICS's
+point of view) in args[1] of the kvm_enable_cap struct. Each ICP has
+64 bits of state which can be read and written using the
+KVM_GET_ONE_REG and KVM_SET_ONE_REG ioctls on the vcpu. The 64 bit
+state word has the following bitfields, starting at the
+least-significant end of the word:
+
+* Unused, 16 bits
+
+* Pending interrupt priority, 8 bits
+ Zero is the highest priority, 255 means no interrupt is pending.
+
+* Pending IPI (inter-processor interrupt) priority, 8 bits
+ Zero is the highest priority, 255 means no IPI is pending.
+
+* Pending interrupt source number, 24 bits
+ Zero means no interrupt pending, 2 means an IPI is pending
+
+* Current processor priority, 8 bits
+ Zero is the highest priority, meaning no interrupts can be
+ delivered, and 255 is the lowest priority.
+
+Each source has 64 bits of state that can be read and written using
+the KVM_GET_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls, specifying the
+KVM_DEV_XICS_SOURCES attribute group, with the attribute number being
+the interrupt source number. The 64 bit state word has the following
+bitfields, starting from the least-significant end of the word:
+
+* Destination (server number), 32 bits
+ This specifies where the interrupt should be sent, and is the
+ interrupt server number specified for the destination vcpu.
+
+* Priority, 8 bits
+ This is the priority specified for this interrupt source, where 0 is
+ the highest priority and 255 is the lowest. An interrupt with a
+ priority of 255 will never be delivered.
+
+* Level sensitive flag, 1 bit
+ This bit is 1 for a level-sensitive interrupt source, or 0 for
+ edge-sensitive (or MSI).
+
+* Masked flag, 1 bit
+ This bit is set to 1 if the interrupt is masked (cannot be delivered
+ regardless of its priority), for example by the ibm,int-off RTAS
+ call, or 0 if it is not masked.
+
+* Pending flag, 1 bit
+ This bit is 1 if the source has a pending interrupt, otherwise 0.
+
+Only one XICS instance may be created per VM.
diff --git a/Documentation/virtual/virtio-spec.txt b/Documentation/virtual/virtio-spec.txt
deleted file mode 100644
index eb094039b50d..000000000000
--- a/Documentation/virtual/virtio-spec.txt
+++ /dev/null
@@ -1,3210 +0,0 @@
-[Generated file: see http://ozlabs.org/~rusty/virtio-spec/]
-Virtio PCI Card Specification
-v0.9.5 DRAFT
--
-
-Rusty Russell <rusty@rustcorp.com.au> IBM Corporation (Editor)
-
-2012 May 7.
-
-Purpose and Description
-
-This document describes the specifications of the “virtio” family
-of PCI[LaTeX Command: nomenclature] devices. These are devices
-are found in virtual environments[LaTeX Command: nomenclature],
-yet by design they are not all that different from physical PCI
-devices, and this document treats them as such. This allows the
-guest to use standard PCI drivers and discovery mechanisms.
-
-The purpose of virtio and this specification is that virtual
-environments and guests should have a straightforward, efficient,
-standard and extensible mechanism for virtual devices, rather
-than boutique per-environment or per-OS mechanisms.
-
- Straightforward: Virtio PCI devices use normal PCI mechanisms
- of interrupts and DMA which should be familiar to any device
- driver author. There is no exotic page-flipping or COW
- mechanism: it's just a PCI device.[footnote:
-This lack of page-sharing implies that the implementation of the
-device (e.g. the hypervisor or host) needs full access to the
-guest memory. Communication with untrusted parties (i.e.
-inter-guest communication) requires copying.
-]
-
- Efficient: Virtio PCI devices consist of rings of descriptors
- for input and output, which are neatly separated to avoid cache
- effects from both guest and device writing to the same cache
- lines.
-
- Standard: Virtio PCI makes no assumptions about the environment
- in which it operates, beyond supporting PCI. In fact the virtio
- devices specified in the appendices do not require PCI at all:
- they have been implemented on non-PCI buses.[footnote:
-The Linux implementation further separates the PCI virtio code
-from the specific virtio drivers: these drivers are shared with
-the non-PCI implementations (currently lguest and S/390).
-]
-
- Extensible: Virtio PCI devices contain feature bits which are
- acknowledged by the guest operating system during device setup.
- This allows forwards and backwards compatibility: the device
- offers all the features it knows about, and the driver
- acknowledges those it understands and wishes to use.
-
- Virtqueues
-
-The mechanism for bulk data transport on virtio PCI devices is
-pretentiously called a virtqueue. Each device can have zero or
-more virtqueues: for example, the network device has one for
-transmit and one for receive.
-
-Each virtqueue occupies two or more physically-contiguous pages
-(defined, for the purposes of this specification, as 4096 bytes),
-and consists of three parts:
-
-
-+-------------------+-----------------------------------+-----------+
-| Descriptor Table | Available Ring (padding) | Used Ring |
-+-------------------+-----------------------------------+-----------+
-
-
-When the driver wants to send a buffer to the device, it fills in
-a slot in the descriptor table (or chains several together), and
-writes the descriptor index into the available ring. It then
-notifies the device. When the device has finished a buffer, it
-writes the descriptor into the used ring, and sends an interrupt.
-
-Specification
-
- PCI Discovery
-
-Any PCI device with Vendor ID 0x1AF4, and Device ID 0x1000
-through 0x103F inclusive is a virtio device[footnote:
-The actual value within this range is ignored
-]. The device must also have a Revision ID of 0 to match this
-specification.
-
-The Subsystem Device ID indicates which virtio device is
-supported by the device. The Subsystem Vendor ID should reflect
-the PCI Vendor ID of the environment (it's currently only used
-for informational purposes by the guest).
-
-
-+----------------------+--------------------+---------------+
-| Subsystem Device ID | Virtio Device | Specification |
-+----------------------+--------------------+---------------+
-+----------------------+--------------------+---------------+
-| 1 | network card | Appendix C |
-+----------------------+--------------------+---------------+
-| 2 | block device | Appendix D |
-+----------------------+--------------------+---------------+
-| 3 | console | Appendix E |
-+----------------------+--------------------+---------------+
-| 4 | entropy source | Appendix F |
-+----------------------+--------------------+---------------+
-| 5 | memory ballooning | Appendix G |
-+----------------------+--------------------+---------------+
-| 6 | ioMemory | - |
-+----------------------+--------------------+---------------+
-| 7 | rpmsg | Appendix H |
-+----------------------+--------------------+---------------+
-| 8 | SCSI host | Appendix I |
-+----------------------+--------------------+---------------+
-| 9 | 9P transport | - |
-+----------------------+--------------------+---------------+
-| 10 | mac80211 wlan | - |
-+----------------------+--------------------+---------------+
-
-
- Device Configuration
-
-To configure the device, we use the first I/O region of the PCI
-device. This contains a virtio header followed by a
-device-specific region.
-
-There may be different widths of accesses to the I/O region; the “
-natural” access method for each field in the virtio header must
-be used (i.e. 32-bit accesses for 32-bit fields, etc), but the
-device-specific region can be accessed using any width accesses,
-and should obtain the same results.
-
-Note that this is possible because while the virtio header is PCI
-(i.e. little) endian, the device-specific region is encoded in
-the native endian of the guest (where such distinction is
-applicable).
-
- Device Initialization Sequence<sub:Device-Initialization-Sequence>
-
-We start with an overview of device initialization, then expand
-on the details of the device and how each step is preformed.
-
- Reset the device. This is not required on initial start up.
-
- The ACKNOWLEDGE status bit is set: we have noticed the device.
-
- The DRIVER status bit is set: we know how to drive the device.
-
- Device-specific setup, including reading the Device Feature
- Bits, discovery of virtqueues for the device, optional MSI-X
- setup, and reading and possibly writing the virtio
- configuration space.
-
- The subset of Device Feature Bits understood by the driver is
- written to the device.
-
- The DRIVER_OK status bit is set.
-
- The device can now be used (ie. buffers added to the
- virtqueues)[footnote:
-Historically, drivers have used the device before steps 5 and 6.
-This is only allowed if the driver does not use any features
-which would alter this early use of the device.
-]
-
-If any of these steps go irrecoverably wrong, the guest should
-set the FAILED status bit to indicate that it has given up on the
-device (it can reset the device later to restart if desired).
-
-We now cover the fields required for general setup in detail.
-
- Virtio Header
-
-The virtio header looks as follows:
-
-
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-| Bits || 32 | 32 | 32 | 16 | 16 | 16 | 8 | 8 |
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-| Read/Write || R | R+W | R+W | R | R+W | R+W | R+W | R |
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-| Purpose || Device | Guest | Queue | Queue | Queue | Queue | Device | ISR |
-| || Features bits 0:31 | Features bits 0:31 | Address | Size | Select | Notify | Status | Status |
-+------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
-
-
-If MSI-X is enabled for the device, two additional fields
-immediately follow this header:[footnote:
-ie. once you enable MSI-X on the device, the other fields move.
-If you turn it off again, they move back!
-]
-
-
-+------------++----------------+--------+
-| Bits || 16 | 16 |
- +----------------+--------+
-+------------++----------------+--------+
-| Read/Write || R+W | R+W |
-+------------++----------------+--------+
-| Purpose || Configuration | Queue |
-| (MSI-X) || Vector | Vector |
-+------------++----------------+--------+
-
-
-Immediately following these general headers, there may be
-device-specific headers:
-
-
-+------------++--------------------+
-| Bits || Device Specific |
- +--------------------+
-+------------++--------------------+
-| Read/Write || Device Specific |
-+------------++--------------------+
-| Purpose || Device Specific... |
-| || |
-+------------++--------------------+
-
-
- Device Status
-
-The Device Status field is updated by the guest to indicate its
-progress. This provides a simple low-level diagnostic: it's most
-useful to imagine them hooked up to traffic lights on the console
-indicating the status of each device.
-
-The device can be reset by writing a 0 to this field, otherwise
-at least one bit should be set:
-
- ACKNOWLEDGE (1) Indicates that the guest OS has found the
- device and recognized it as a valid virtio device.
-
- DRIVER (2) Indicates that the guest OS knows how to drive the
- device. Under Linux, drivers can be loadable modules so there
- may be a significant (or infinite) delay before setting this
- bit.
-
- DRIVER_OK (4) Indicates that the driver is set up and ready to
- drive the device.
-
- FAILED (128) Indicates that something went wrong in the guest,
- and it has given up on the device. This could be an internal
- error, or the driver didn't like the device for some reason, or
- even a fatal error during device operation. The device must be
- reset before attempting to re-initialize.
-
- Feature Bits<sub:Feature-Bits>
-
-Thefirst configuration field indicates the features that the
-device supports. The bits are allocated as follows:
-
- 0 to 23 Feature bits for the specific device type
-
- 24 to 32 Feature bits reserved for extensions to the queue and
- feature negotiation mechanisms
-
-For example, feature bit 0 for a network device (i.e. Subsystem
-Device ID 1) indicates that the device supports checksumming of
-packets.
-
-The feature bits are negotiated: the device lists all the
-features it understands in the Device Features field, and the
-guest writes the subset that it understands into the Guest
-Features field. The only way to renegotiate is to reset the
-device.
-
-In particular, new fields in the device configuration header are
-indicated by offering a feature bit, so the guest can check
-before accessing that part of the configuration space.
-
-This allows for forwards and backwards compatibility: if the
-device is enhanced with a new feature bit, older guests will not
-write that feature bit back to the Guest Features field and it
-can go into backwards compatibility mode. Similarly, if a guest
-is enhanced with a feature that the device doesn't support, it
-will not see that feature bit in the Device Features field and
-can go into backwards compatibility mode (or, for poor
-implementations, set the FAILED Device Status bit).
-
- Configuration/Queue Vectors
-
-When MSI-X capability is present and enabled in the device
-(through standard PCI configuration space) 4 bytes at byte offset
-20 are used to map configuration change and queue interrupts to
-MSI-X vectors. In this case, the ISR Status field is unused, and
-device specific configuration starts at byte offset 24 in virtio
-header structure. When MSI-X capability is not enabled, device
-specific configuration starts at byte offset 20 in virtio header.
-
-Writing a valid MSI-X Table entry number, 0 to 0x7FF, to one of
-Configuration/Queue Vector registers, maps interrupts triggered
-by the configuration change/selected queue events respectively to
-the corresponding MSI-X vector. To disable interrupts for a
-specific event type, unmap it by writing a special NO_VECTOR
-value:
-
-/* Vector value used to disable MSI for queue */
-
-#define VIRTIO_MSI_NO_VECTOR 0xffff
-
-Reading these registers returns vector mapped to a given event,
-or NO_VECTOR if unmapped. All queue and configuration change
-events are unmapped by default.
-
-Note that mapping an event to vector might require allocating
-internal device resources, and might fail. Devices report such
-failures by returning the NO_VECTOR value when the relevant
-Vector field is read. After mapping an event to vector, the
-driver must verify success by reading the Vector field value: on
-success, the previously written value is returned, and on
-failure, NO_VECTOR is returned. If a mapping failure is detected,
-the driver can retry mapping with fewervectors, or disable MSI-X.
-
- Virtqueue Configuration<sec:Virtqueue-Configuration>
-
-As a device can have zero or more virtqueues for bulk data
-transport (for example, the network driver has two), the driver
-needs to configure them as part of the device-specific
-configuration.
-
-This is done as follows, for each virtqueue a device has:
-
- Write the virtqueue index (first queue is 0) to the Queue
- Select field.
-
- Read the virtqueue size from the Queue Size field, which is
- always a power of 2. This controls how big the virtqueue is
- (see below). If this field is 0, the virtqueue does not exist.
-
- Allocate and zero virtqueue in contiguous physical memory, on a
- 4096 byte alignment. Write the physical address, divided by
- 4096 to the Queue Address field.[footnote:
-The 4096 is based on the x86 page size, but it's also large
-enough to ensure that the separate parts of the virtqueue are on
-separate cache lines.
-]
-
- Optionally, if MSI-X capability is present and enabled on the
- device, select a vector to use to request interrupts triggered
- by virtqueue events. Write the MSI-X Table entry number
- corresponding to this vector in Queue Vector field. Read the
- Queue Vector field: on success, previously written value is
- returned; on failure, NO_VECTOR value is returned.
-
-The Queue Size field controls the total number of bytes required
-for the virtqueue according to the following formula:
-
-#define ALIGN(x) (((x) + 4095) & ~4095)
-
-static inline unsigned vring_size(unsigned int qsz)
-
-{
-
- return ALIGN(sizeof(struct vring_desc)*qsz + sizeof(u16)*(2
-+ qsz))
-
- + ALIGN(sizeof(struct vring_used_elem)*qsz);
-
-}
-
-This currently wastes some space with padding, but also allows
-future extensions. The virtqueue layout structure looks like this
-(qsz is the Queue Size field, which is a variable, so this code
-won't compile):
-
-struct vring {
-
- /* The actual descriptors (16 bytes each) */
-
- struct vring_desc desc[qsz];
-
-
-
- /* A ring of available descriptor heads with free-running
-index. */
-
- struct vring_avail avail;
-
-
-
- // Padding to the next 4096 boundary.
-
- char pad[];
-
-
-
- // A ring of used descriptor heads with free-running index.
-
- struct vring_used used;
-
-};
-
- A Note on Virtqueue Endianness
-
-Note that the endian of these fields and everything else in the
-virtqueue is the native endian of the guest, not little-endian as
-PCI normally is. This makes for simpler guest code, and it is
-assumed that the host already has to be deeply aware of the guest
-endian so such an “endian-aware” device is not a significant
-issue.
-
- Descriptor Table
-
-The descriptor table refers to the buffers the guest is using for
-the device. The addresses are physical addresses, and the buffers
-can be chained via the next field. Each descriptor describes a
-buffer which is read-only or write-only, but a chain of
-descriptors can contain both read-only and write-only buffers.
-
-No descriptor chain may be more than 2^32 bytes long in total.struct vring_desc {
-
- /* Address (guest-physical). */
-
- u64 addr;
-
- /* Length. */
-
- u32 len;
-
-/* This marks a buffer as continuing via the next field. */
-
-#define VRING_DESC_F_NEXT 1
-
-/* This marks a buffer as write-only (otherwise read-only). */
-
-#define VRING_DESC_F_WRITE 2
-
-/* This means the buffer contains a list of buffer descriptors.
-*/
-
-#define VRING_DESC_F_INDIRECT 4
-
- /* The flags as indicated above. */
-
- u16 flags;
-
- /* Next field if flags & NEXT */
-
- u16 next;
-
-};
-
-The number of descriptors in the table is specified by the Queue
-Size field for this virtqueue.
-
- <sub:Indirect-Descriptors>Indirect Descriptors
-
-Some devices benefit by concurrently dispatching a large number
-of large requests. The VIRTIO_RING_F_INDIRECT_DESC feature can be
-used to allow this (see [cha:Reserved-Feature-Bits]). To increase
-ring capacity it is possible to store a table of indirect
-descriptors anywhere in memory, and insert a descriptor in main
-virtqueue (with flags&INDIRECT on) that refers to memory buffer
-containing this indirect descriptor table; fields addr and len
-refer to the indirect table address and length in bytes,
-respectively. The indirect table layout structure looks like this
-(len is the length of the descriptor that refers to this table,
-which is a variable, so this code won't compile):
-
-struct indirect_descriptor_table {
-
- /* The actual descriptors (16 bytes each) */
-
- struct vring_desc desc[len / 16];
-
-};
-
-The first indirect descriptor is located at start of the indirect
-descriptor table (index 0), additional indirect descriptors are
-chained by next field. An indirect descriptor without next field
-(with flags&NEXT off) signals the end of the indirect descriptor
-table, and transfers control back to the main virtqueue. An
-indirect descriptor can not refer to another indirect descriptor
-table (flags&INDIRECT must be off). A single indirect descriptor
-table can include both read-only and write-only descriptors;
-write-only flag (flags&WRITE) in the descriptor that refers to it
-is ignored.
-
- Available Ring
-
-The available ring refers to what descriptors we are offering the
-device: it refers to the head of a descriptor chain. The “flags”
-field is currently 0 or 1: 1 indicating that we do not need an
-interrupt when the device consumes a descriptor from the
-available ring. Alternatively, the guest can ask the device to
-delay interrupts until an entry with an index specified by the “
-used_event” field is written in the used ring (equivalently,
-until the idx field in the used ring will reach the value
-used_event + 1). The method employed by the device is controlled
-by the VIRTIO_RING_F_EVENT_IDX feature bit (see [cha:Reserved-Feature-Bits]
-). This interrupt suppression is merely an optimization; it may
-not suppress interrupts entirely.
-
-The “idx” field indicates where we would put the next descriptor
-entry (modulo the ring size). This starts at 0, and increases.
-
-struct vring_avail {
-
-#define VRING_AVAIL_F_NO_INTERRUPT 1
-
- u16 flags;
-
- u16 idx;
-
- u16 ring[qsz]; /* qsz is the Queue Size field read from device
-*/
-
- u16 used_event;
-
-};
-
- Used Ring
-
-The used ring is where the device returns buffers once it is done
-with them. The flags field can be used by the device to hint that
-no notification is necessary when the guest adds to the available
-ring. Alternatively, the “avail_event” field can be used by the
-device to hint that no notification is necessary until an entry
-with an index specified by the “avail_event” is written in the
-available ring (equivalently, until the idx field in the
-available ring will reach the value avail_event + 1). The method
-employed by the device is controlled by the guest through the
-VIRTIO_RING_F_EVENT_IDX feature bit (see [cha:Reserved-Feature-Bits]
-). [footnote:
-These fields are kept here because this is the only part of the
-virtqueue written by the device
-].
-
-Each entry in the ring is a pair: the head entry of the
-descriptor chain describing the buffer (this matches an entry
-placed in the available ring by the guest earlier), and the total
-of bytes written into the buffer. The latter is extremely useful
-for guests using untrusted buffers: if you do not know exactly
-how much has been written by the device, you usually have to zero
-the buffer to ensure no data leakage occurs.
-
-/* u32 is used here for ids for padding reasons. */
-
-struct vring_used_elem {
-
- /* Index of start of used descriptor chain. */
-
- u32 id;
-
- /* Total length of the descriptor chain which was used
-(written to) */
-
- u32 len;
-
-};
-
-
-
-struct vring_used {
-
-#define VRING_USED_F_NO_NOTIFY 1
-
- u16 flags;
-
- u16 idx;
-
- struct vring_used_elem ring[qsz];
-
- u16 avail_event;
-
-};
-
- Helpers for Managing Virtqueues
-
-The Linux Kernel Source code contains the definitions above and
-helper routines in a more usable form, in
-include/linux/virtio_ring.h. This was explicitly licensed by IBM
-and Red Hat under the (3-clause) BSD license so that it can be
-freely used by all other projects, and is reproduced (with slight
-variation to remove Linux assumptions) in Appendix A.
-
- Device Operation<sec:Device-Operation>
-
-There are two parts to device operation: supplying new buffers to
-the device, and processing used buffers from the device. As an
-example, the virtio network device has two virtqueues: the
-transmit virtqueue and the receive virtqueue. The driver adds
-outgoing (read-only) packets to the transmit virtqueue, and then
-frees them after they are used. Similarly, incoming (write-only)
-buffers are added to the receive virtqueue, and processed after
-they are used.
-
- Supplying Buffers to The Device
-
-Actual transfer of buffers from the guest OS to the device
-operates as follows:
-
- Place the buffer(s) into free descriptor(s).
-
- If there are no free descriptors, the guest may choose to
- notify the device even if notifications are suppressed (to
- reduce latency).[footnote:
-The Linux drivers do this only for read-only buffers: for
-write-only buffers, it is assumed that the driver is merely
-trying to keep the receive buffer ring full, and no notification
-of this expected condition is necessary.
-]
-
- Place the id of the buffer in the next ring entry of the
- available ring.
-
- The steps (1) and (2) may be performed repeatedly if batching
- is possible.
-
- A memory barrier should be executed to ensure the device sees
- the updated descriptor table and available ring before the next
- step.
-
- The available “idx” field should be increased by the number of
- entries added to the available ring.
-
- A memory barrier should be executed to ensure that we update
- the idx field before checking for notification suppression.
-
- If notifications are not suppressed, the device should be
- notified of the new buffers.
-
-Note that the above code does not take precautions against the
-available ring buffer wrapping around: this is not possible since
-the ring buffer is the same size as the descriptor table, so step
-(1) will prevent such a condition.
-
-In addition, the maximum queue size is 32768 (it must be a power
-of 2 which fits in 16 bits), so the 16-bit “idx” value can always
-distinguish between a full and empty buffer.
-
-Here is a description of each stage in more detail.
-
- Placing Buffers Into The Descriptor Table
-
-A buffer consists of zero or more read-only physically-contiguous
-elements followed by zero or more physically-contiguous
-write-only elements (it must have at least one element). This
-algorithm maps it into the descriptor table:
-
- for each buffer element, b:
-
- Get the next free descriptor table entry, d
-
- Set d.addr to the physical address of the start of b
-
- Set d.len to the length of b.
-
- If b is write-only, set d.flags to VRING_DESC_F_WRITE,
- otherwise 0.
-
- If there is a buffer element after this:
-
- Set d.next to the index of the next free descriptor element.
-
- Set the VRING_DESC_F_NEXT bit in d.flags.
-
-In practice, the d.next fields are usually used to chain free
-descriptors, and a separate count kept to check there are enough
-free descriptors before beginning the mappings.
-
- Updating The Available Ring
-
-The head of the buffer we mapped is the first d in the algorithm
-above. A naive implementation would do the following:
-
-avail->ring[avail->idx % qsz] = head;
-
-However, in general we can add many descriptors before we update
-the “idx” field (at which point they become visible to the
-device), so we keep a counter of how many we've added:
-
-avail->ring[(avail->idx + added++) % qsz] = head;
-
- Updating The Index Field
-
-Once the idx field of the virtqueue is updated, the device will
-be able to access the descriptor entries we've created and the
-memory they refer to. This is why a memory barrier is generally
-used before the idx update, to ensure it sees the most up-to-date
-copy.
-
-The idx field always increments, and we let it wrap naturally at
-65536:
-
-avail->idx += added;
-
- <sub:Notifying-The-Device>Notifying The Device
-
-Device notification occurs by writing the 16-bit virtqueue index
-of this virtqueue to the Queue Notify field of the virtio header
-in the first I/O region of the PCI device. This can be expensive,
-however, so the device can suppress such notifications if it
-doesn't need them. We have to be careful to expose the new idx
-value before checking the suppression flag: it's OK to notify
-gratuitously, but not to omit a required notification. So again,
-we use a memory barrier here before reading the flags or the
-avail_event field.
-
-If the VIRTIO_F_RING_EVENT_IDX feature is not negotiated, and if
-the VRING_USED_F_NOTIFY flag is not set, we go ahead and write to
-the PCI configuration space.
-
-If the VIRTIO_F_RING_EVENT_IDX feature is negotiated, we read the
-avail_event field in the available ring structure. If the
-available index crossed_the avail_event field value since the
-last notification, we go ahead and write to the PCI configuration
-space. The avail_event field wraps naturally at 65536 as well:
-
-(u16)(new_idx - avail_event - 1) < (u16)(new_idx - old_idx)
-
- <sub:Receiving-Used-Buffers>Receiving Used Buffers From The
- Device
-
-Once the device has used a buffer (read from or written to it, or
-parts of both, depending on the nature of the virtqueue and the
-device), it sends an interrupt, following an algorithm very
-similar to the algorithm used for the driver to send the device a
-buffer:
-
- Write the head descriptor number to the next field in the used
- ring.
-
- Update the used ring idx.
-
- Determine whether an interrupt is necessary:
-
- If the VIRTIO_F_RING_EVENT_IDX feature is not negotiated: check
- if f the VRING_AVAIL_F_NO_INTERRUPT flag is not set in avail-
- >flags
-
- If the VIRTIO_F_RING_EVENT_IDX feature is negotiated: check
- whether the used index crossed the used_event field value
- since the last update. The used_event field wraps naturally
- at 65536 as well:(u16)(new_idx - used_event - 1) < (u16)(new_idx - old_idx)
-
- If an interrupt is necessary:
-
- If MSI-X capability is disabled:
-
- Set the lower bit of the ISR Status field for the device.
-
- Send the appropriate PCI interrupt for the device.
-
- If MSI-X capability is enabled:
-
- Request the appropriate MSI-X interrupt message for the
- device, Queue Vector field sets the MSI-X Table entry
- number.
-
- If Queue Vector field value is NO_VECTOR, no interrupt
- message is requested for this event.
-
-The guest interrupt handler should:
-
- If MSI-X capability is disabled: read the ISR Status field,
- which will reset it to zero. If the lower bit is zero, the
- interrupt was not for this device. Otherwise, the guest driver
- should look through the used rings of each virtqueue for the
- device, to see if any progress has been made by the device
- which requires servicing.
-
- If MSI-X capability is enabled: look through the used rings of
- each virtqueue mapped to the specific MSI-X vector for the
- device, to see if any progress has been made by the device
- which requires servicing.
-
-For each ring, guest should then disable interrupts by writing
-VRING_AVAIL_F_NO_INTERRUPT flag in avail structure, if required.
-It can then process used ring entries finally enabling interrupts
-by clearing the VRING_AVAIL_F_NO_INTERRUPT flag or updating the
-EVENT_IDX field in the available structure, Guest should then
-execute a memory barrier, and then recheck the ring empty
-condition. This is necessary to handle the case where, after the
-last check and before enabling interrupts, an interrupt has been
-suppressed by the device:
-
-vring_disable_interrupts(vq);
-
-for (;;) {
-
- if (vq->last_seen_used != vring->used.idx) {
-
- vring_enable_interrupts(vq);
-
- mb();
-
- if (vq->last_seen_used != vring->used.idx)
-
- break;
-
- }
-
- struct vring_used_elem *e =
-vring.used->ring[vq->last_seen_used%vsz];
-
- process_buffer(e);
-
- vq->last_seen_used++;
-
-}
-
- Dealing With Configuration Changes<sub:Dealing-With-Configuration>
-
-Some virtio PCI devices can change the device configuration
-state, as reflected in the virtio header in the PCI configuration
-space. In this case:
-
- If MSI-X capability is disabled: an interrupt is delivered and
- the second highest bit is set in the ISR Status field to
- indicate that the driver should re-examine the configuration
- space.Note that a single interrupt can indicate both that one
- or more virtqueue has been used and that the configuration
- space has changed: even if the config bit is set, virtqueues
- must be scanned.
-
- If MSI-X capability is enabled: an interrupt message is
- requested. The Configuration Vector field sets the MSI-X Table
- entry number to use. If Configuration Vector field value is
- NO_VECTOR, no interrupt message is requested for this event.
-
-Creating New Device Types
-
-Various considerations are necessary when creating a new device
-type:
-
- How Many Virtqueues?
-
-It is possible that a very simple device will operate entirely
-through its configuration space, but most will need at least one
-virtqueue in which it will place requests. A device with both
-input and output (eg. console and network devices described here)
-need two queues: one which the driver fills with buffers to
-receive input, and one which the driver places buffers to
-transmit output.
-
- What Configuration Space Layout?
-
-Configuration space is generally used for rarely-changing or
-initialization-time parameters. But it is a limited resource, so
-it might be better to use a virtqueue to update configuration
-information (the network device does this for filtering,
-otherwise the table in the config space could potentially be very
-large).
-
-Note that this space is generally the guest's native endian,
-rather than PCI's little-endian.
-
- What Device Number?
-
-Currently device numbers are assigned quite freely: a simple
-request mail to the author of this document or the Linux
-virtualization mailing list[footnote:
-
-https://lists.linux-foundation.org/mailman/listinfo/virtualization
-] will be sufficient to secure a unique one.
-
-Meanwhile for experimental drivers, use 65535 and work backwards.
-
- How many MSI-X vectors?
-
-Using the optional MSI-X capability devices can speed up
-interrupt processing by removing the need to read ISR Status
-register by guest driver (which might be an expensive operation),
-reducing interrupt sharing between devices and queues within the
-device, and handling interrupts from multiple CPUs. However, some
-systems impose a limit (which might be as low as 256) on the
-total number of MSI-X vectors that can be allocated to all
-devices. Devices and/or device drivers should take this into
-account, limiting the number of vectors used unless the device is
-expected to cause a high volume of interrupts. Devices can
-control the number of vectors used by limiting the MSI-X Table
-Size or not presenting MSI-X capability in PCI configuration
-space. Drivers can control this by mapping events to as small
-number of vectors as possible, or disabling MSI-X capability
-altogether.
-
- Message Framing
-
-The descriptors used for a buffer should not effect the semantics
-of the message, except for the total length of the buffer. For
-example, a network buffer consists of a 10 byte header followed
-by the network packet. Whether this is presented in the ring
-descriptor chain as (say) a 10 byte buffer and a 1514 byte
-buffer, or a single 1524 byte buffer, or even three buffers,
-should have no effect.
-
-In particular, no implementation should use the descriptor
-boundaries to determine the size of any header in a request.[footnote:
-The current qemu device implementations mistakenly insist that
-the first descriptor cover the header in these cases exactly, so
-a cautious driver should arrange it so.
-]
-
- Device Improvements
-
-Any change to configuration space, or new virtqueues, or
-behavioural changes, should be indicated by negotiation of a new
-feature bit. This establishes clarity[footnote:
-Even if it does mean documenting design or implementation
-mistakes!
-] and avoids future expansion problems.
-
-Clusters of functionality which are always implemented together
-can use a single bit, but if one feature makes sense without the
-others they should not be gratuitously grouped together to
-conserve feature bits. We can always extend the spec when the
-first person needs more than 24 feature bits for their device.
-
-[LaTeX Command: printnomenclature]
-
-Appendix A: virtio_ring.h
-
-#ifndef VIRTIO_RING_H
-
-#define VIRTIO_RING_H
-
-/* An interface for efficient virtio implementation.
-
- *
-
- * This header is BSD licensed so anyone can use the definitions
-
- * to implement compatible drivers/servers.
-
- *
-
- * Copyright 2007, 2009, IBM Corporation
-
- * Copyright 2011, Red Hat, Inc
-
- * All rights reserved.
-
- *
-
- * Redistribution and use in source and binary forms, with or
-without
-
- * modification, are permitted provided that the following
-conditions
-
- * are met:
-
- * 1. Redistributions of source code must retain the above
-copyright
-
- * notice, this list of conditions and the following
-disclaimer.
-
- * 2. Redistributions in binary form must reproduce the above
-copyright
-
- * notice, this list of conditions and the following
-disclaimer in the
-
- * documentation and/or other materials provided with the
-distribution.
-
- * 3. Neither the name of IBM nor the names of its contributors
-
- * may be used to endorse or promote products derived from
-this software
-
- * without specific prior written permission.
-
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
-CONTRIBUTORS ``AS IS'' AND
-
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
-TO, THE
-
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
-PARTICULAR PURPOSE
-
- * ARE DISCLAIMED. IN NO EVENT SHALL IBM OR CONTRIBUTORS BE
-LIABLE
-
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-CONSEQUENTIAL
-
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
-SUBSTITUTE GOODS
-
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
-INTERRUPTION)
-
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
-CONTRACT, STRICT
-
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
-IN ANY WAY
-
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-POSSIBILITY OF
-
- * SUCH DAMAGE.
-
- */
-
-
-
-/* This marks a buffer as continuing via the next field. */
-
-#define VRING_DESC_F_NEXT 1
-
-/* This marks a buffer as write-only (otherwise read-only). */
-
-#define VRING_DESC_F_WRITE 2
-
-
-
-/* The Host uses this in used->flags to advise the Guest: don't
-kick me
-
- * when you add a buffer. It's unreliable, so it's simply an
-
- * optimization. Guest will still kick if it's out of buffers.
-*/
-
-#define VRING_USED_F_NO_NOTIFY 1
-
-/* The Guest uses this in avail->flags to advise the Host: don't
-
- * interrupt me when you consume a buffer. It's unreliable, so
-it's
-
- * simply an optimization. */
-
-#define VRING_AVAIL_F_NO_INTERRUPT 1
-
-
-
-/* Virtio ring descriptors: 16 bytes.
-
- * These can chain together via "next". */
-
-struct vring_desc {
-
- /* Address (guest-physical). */
-
- uint64_t addr;
-
- /* Length. */
-
- uint32_t len;
-
- /* The flags as indicated above. */
-
- uint16_t flags;
-
- /* We chain unused descriptors via this, too */
-
- uint16_t next;
-
-};
-
-
-
-struct vring_avail {
-
- uint16_t flags;
-
- uint16_t idx;
-
- uint16_t ring[];
-
- uint16_t used_event;
-
-};
-
-
-
-/* u32 is used here for ids for padding reasons. */
-
-struct vring_used_elem {
-
- /* Index of start of used descriptor chain. */
-
- uint32_t id;
-
- /* Total length of the descriptor chain which was written
-to. */
-
- uint32_t len;
-
-};
-
-
-
-struct vring_used {
-
- uint16_t flags;
-
- uint16_t idx;
-
- struct vring_used_elem ring[];
-
- uint16_t avail_event;
-
-};
-
-
-
-struct vring {
-
- unsigned int num;
-
-
-
- struct vring_desc *desc;
-
- struct vring_avail *avail;
-
- struct vring_used *used;
-
-};
-
-
-
-/* The standard layout for the ring is a continuous chunk of
-memory which
-
- * looks like this. We assume num is a power of 2.
-
- *
-
- * struct vring {
-
- * // The actual descriptors (16 bytes each)
-
- * struct vring_desc desc[num];
-
- *
-
- * // A ring of available descriptor heads with free-running
-index.
-
- * __u16 avail_flags;
-
- * __u16 avail_idx;
-
- * __u16 available[num];
-
- *
-
- * // Padding to the next align boundary.
-
- * char pad[];
-
- *
-
- * // A ring of used descriptor heads with free-running
-index.
-
- * __u16 used_flags;
-
- * __u16 EVENT_IDX;
-
- * struct vring_used_elem used[num];
-
- * };
-
- * Note: for virtio PCI, align is 4096.
-
- */
-
-static inline void vring_init(struct vring *vr, unsigned int num,
-void *p,
-
- unsigned long align)
-
-{
-
- vr->num = num;
-
- vr->desc = p;
-
- vr->avail = p + num*sizeof(struct vring_desc);
-
- vr->used = (void *)(((unsigned long)&vr->avail->ring[num]
-
- + align-1)
-
- & ~(align - 1));
-
-}
-
-
-
-static inline unsigned vring_size(unsigned int num, unsigned long
-align)
-
-{
-
- return ((sizeof(struct vring_desc)*num +
-sizeof(uint16_t)*(2+num)
-
- + align - 1) & ~(align - 1))
-
- + sizeof(uint16_t)*3 + sizeof(struct
-vring_used_elem)*num;
-
-}
-
-
-
-static inline int vring_need_event(uint16_t event_idx, uint16_t
-new_idx, uint16_t old_idx)
-
-{
-
- return (uint16_t)(new_idx - event_idx - 1) <
-(uint16_t)(new_idx - old_idx);
-
-}
-
-#endif /* VIRTIO_RING_H */
-
-<cha:Reserved-Feature-Bits>Appendix B: Reserved Feature Bits
-
-Currently there are five device-independent feature bits defined:
-
- VIRTIO_F_NOTIFY_ON_EMPTY (24) Negotiating this feature
- indicates that the driver wants an interrupt if the device runs
- out of available descriptors on a virtqueue, even though
- interrupts are suppressed using the VRING_AVAIL_F_NO_INTERRUPT
- flag or the used_event field. An example of this is the
- networking driver: it doesn't need to know every time a packet
- is transmitted, but it does need to free the transmitted
- packets a finite time after they are transmitted. It can avoid
- using a timer if the device interrupts it when all the packets
- are transmitted.
-
- VIRTIO_F_RING_INDIRECT_DESC (28) Negotiating this feature
- indicates that the driver can use descriptors with the
- VRING_DESC_F_INDIRECT flag set, as described in [sub:Indirect-Descriptors]
- .
-
- VIRTIO_F_RING_EVENT_IDX(29) This feature enables the used_event
- and the avail_event fields. If set, it indicates that the
- device should ignore the flags field in the available ring
- structure. Instead, the used_event field in this structure is
- used by guest to suppress device interrupts. Further, the
- driver should ignore the flags field in the used ring
- structure. Instead, the avail_event field in this structure is
- used by the device to suppress notifications. If unset, the
- driver should ignore the used_event field; the device should
- ignore the avail_event field; the flags field is used
-
-Appendix C: Network Device
-
-The virtio network device is a virtual ethernet card, and is the
-most complex of the devices supported so far by virtio. It has
-enhanced rapidly and demonstrates clearly how support for new
-features should be added to an existing device. Empty buffers are
-placed in one virtqueue for receiving packets, and outgoing
-packets are enqueued into another for transmission in that order.
-A third command queue is used to control advanced filtering
-features.
-
- Configuration
-
- Subsystem Device ID 1
-
- Virtqueues 0:receiveq. 1:transmitq. 2:controlq[footnote:
-Only if VIRTIO_NET_F_CTRL_VQ set
-]
-
- Feature bits
-
- VIRTIO_NET_F_CSUM (0) Device handles packets with partial
- checksum
-
- VIRTIO_NET_F_GUEST_CSUM (1) Guest handles packets with partial
- checksum
-
- VIRTIO_NET_F_MAC (5) Device has given MAC address.
-
- VIRTIO_NET_F_GSO (6) (Deprecated) device handles packets with
- any GSO type.[footnote:
-It was supposed to indicate segmentation offload support, but
-upon further investigation it became clear that multiple bits
-were required.
-]
-
- VIRTIO_NET_F_GUEST_TSO4 (7) Guest can receive TSOv4.
-
- VIRTIO_NET_F_GUEST_TSO6 (8) Guest can receive TSOv6.
-
- VIRTIO_NET_F_GUEST_ECN (9) Guest can receive TSO with ECN.
-
- VIRTIO_NET_F_GUEST_UFO (10) Guest can receive UFO.
-
- VIRTIO_NET_F_HOST_TSO4 (11) Device can receive TSOv4.
-
- VIRTIO_NET_F_HOST_TSO6 (12) Device can receive TSOv6.
-
- VIRTIO_NET_F_HOST_ECN (13) Device can receive TSO with ECN.
-
- VIRTIO_NET_F_HOST_UFO (14) Device can receive UFO.
-
- VIRTIO_NET_F_MRG_RXBUF (15) Guest can merge receive buffers.
-
- VIRTIO_NET_F_STATUS (16) Configuration status field is
- available.
-
- VIRTIO_NET_F_CTRL_VQ (17) Control channel is available.
-
- VIRTIO_NET_F_CTRL_RX (18) Control channel RX mode support.
-
- VIRTIO_NET_F_CTRL_VLAN (19) Control channel VLAN filtering.
-
- VIRTIO_NET_F_GUEST_ANNOUNCE(21) Guest can send gratuitous
- packets.
-
- Device configuration layout Two configuration fields are
- currently defined. The mac address field always exists (though
- is only valid if VIRTIO_NET_F_MAC is set), and the status field
- only exists if VIRTIO_NET_F_STATUS is set. Two read-only bits
- are currently defined for the status field:
- VIRTIO_NET_S_LINK_UP and VIRTIO_NET_S_ANNOUNCE. #define VIRTIO_NET_S_LINK_UP 1
-
-#define VIRTIO_NET_S_ANNOUNCE 2
-
-
-
-struct virtio_net_config {
-
- u8 mac[6];
-
- u16 status;
-
-};
-
- Device Initialization
-
- The initialization routine should identify the receive and
- transmission virtqueues.
-
- If the VIRTIO_NET_F_MAC feature bit is set, the configuration
- space “mac” entry indicates the “physical” address of the the
- network card, otherwise a private MAC address should be
- assigned. All guests are expected to negotiate this feature if
- it is set.
-
- If the VIRTIO_NET_F_CTRL_VQ feature bit is negotiated, identify
- the control virtqueue.
-
- If the VIRTIO_NET_F_STATUS feature bit is negotiated, the link
- status can be read from the bottom bit of the “status” config
- field. Otherwise, the link should be assumed active.
-
- The receive virtqueue should be filled with receive buffers.
- This is described in detail below in “Setting Up Receive
- Buffers”.
-
- A driver can indicate that it will generate checksumless
- packets by negotating the VIRTIO_NET_F_CSUM feature. This “
- checksum offload” is a common feature on modern network cards.
-
- If that feature is negotiated[footnote:
-ie. VIRTIO_NET_F_HOST_TSO* and VIRTIO_NET_F_HOST_UFO are
-dependent on VIRTIO_NET_F_CSUM; a dvice which offers the offload
-features must offer the checksum feature, and a driver which
-accepts the offload features must accept the checksum feature.
-Similar logic applies to the VIRTIO_NET_F_GUEST_TSO4 features
-depending on VIRTIO_NET_F_GUEST_CSUM.
-], a driver can use TCP or UDP segmentation offload by
- negotiating the VIRTIO_NET_F_HOST_TSO4 (IPv4 TCP),
- VIRTIO_NET_F_HOST_TSO6 (IPv6 TCP) and VIRTIO_NET_F_HOST_UFO
- (UDP fragmentation) features. It should not send TCP packets
- requiring segmentation offload which have the Explicit
- Congestion Notification bit set, unless the
- VIRTIO_NET_F_HOST_ECN feature is negotiated.[footnote:
-This is a common restriction in real, older network cards.
-]
-
- The converse features are also available: a driver can save the
- virtual device some work by negotiating these features.[footnote:
-For example, a network packet transported between two guests on
-the same system may not require checksumming at all, nor
-segmentation, if both guests are amenable.
-] The VIRTIO_NET_F_GUEST_CSUM feature indicates that partially
- checksummed packets can be received, and if it can do that then
- the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6,
- VIRTIO_NET_F_GUEST_UFO and VIRTIO_NET_F_GUEST_ECN are the input
- equivalents of the features described above. See “Receiving
- Packets” below.
-
- Device Operation
-
-Packets are transmitted by placing them in the transmitq, and
-buffers for incoming packets are placed in the receiveq. In each
-case, the packet itself is preceded by a header:
-
-struct virtio_net_hdr {
-
-#define VIRTIO_NET_HDR_F_NEEDS_CSUM 1
-
- u8 flags;
-
-#define VIRTIO_NET_HDR_GSO_NONE 0
-
-#define VIRTIO_NET_HDR_GSO_TCPV4 1
-
-#define VIRTIO_NET_HDR_GSO_UDP 3
-
-#define VIRTIO_NET_HDR_GSO_TCPV6 4
-
-#define VIRTIO_NET_HDR_GSO_ECN 0x80
-
- u8 gso_type;
-
- u16 hdr_len;
-
- u16 gso_size;
-
- u16 csum_start;
-
- u16 csum_offset;
-
-/* Only if VIRTIO_NET_F_MRG_RXBUF: */
-
- u16 num_buffers
-
-};
-
-The controlq is used to control device features such as
-filtering.
-
- Packet Transmission
-
-Transmitting a single packet is simple, but varies depending on
-the different features the driver negotiated.
-
- If the driver negotiated VIRTIO_NET_F_CSUM, and the packet has
- not been fully checksummed, then the virtio_net_hdr's fields
- are set as follows. Otherwise, the packet must be fully
- checksummed, and flags is zero.
-
- flags has the VIRTIO_NET_HDR_F_NEEDS_CSUM set,
-
- <ite:csum_start-is-set>csum_start is set to the offset within
- the packet to begin checksumming, and
-
- csum_offset indicates how many bytes after the csum_start the
- new (16 bit ones' complement) checksum should be placed.[footnote:
-For example, consider a partially checksummed TCP (IPv4) packet.
-It will have a 14 byte ethernet header and 20 byte IP header
-followed by the TCP header (with the TCP checksum field 16 bytes
-into that header). csum_start will be 14+20 = 34 (the TCP
-checksum includes the header), and csum_offset will be 16. The
-value in the TCP checksum field should be initialized to the sum
-of the TCP pseudo header, so that replacing it by the ones'
-complement checksum of the TCP header and body will give the
-correct result.
-]
-
- <enu:If-the-driver>If the driver negotiated
- VIRTIO_NET_F_HOST_TSO4, TSO6 or UFO, and the packet requires
- TCP segmentation or UDP fragmentation, then the “gso_type”
- field is set to VIRTIO_NET_HDR_GSO_TCPV4, TCPV6 or UDP.
- (Otherwise, it is set to VIRTIO_NET_HDR_GSO_NONE). In this
- case, packets larger than 1514 bytes can be transmitted: the
- metadata indicates how to replicate the packet header to cut it
- into smaller packets. The other gso fields are set:
-
- hdr_len is a hint to the device as to how much of the header
- needs to be kept to copy into each packet, usually set to the
- length of the headers, including the transport header.[footnote:
-Due to various bugs in implementations, this field is not useful
-as a guarantee of the transport header size.
-]
-
- gso_size is the maximum size of each packet beyond that header
- (ie. MSS).
-
- If the driver negotiated the VIRTIO_NET_F_HOST_ECN feature, the
- VIRTIO_NET_HDR_GSO_ECN bit may be set in “gso_type” as well,
- indicating that the TCP packet has the ECN bit set.[footnote:
-This case is not handled by some older hardware, so is called out
-specifically in the protocol.
-]
-
- If the driver negotiated the VIRTIO_NET_F_MRG_RXBUF feature,
- the num_buffers field is set to zero.
-
- The header and packet are added as one output buffer to the
- transmitq, and the device is notified of the new entry (see [sub:Notifying-The-Device]
- ).[footnote:
-Note that the header will be two bytes longer for the
-VIRTIO_NET_F_MRG_RXBUF case.
-]
-
- Packet Transmission Interrupt
-
-Often a driver will suppress transmission interrupts using the
-VRING_AVAIL_F_NO_INTERRUPT flag (see [sub:Receiving-Used-Buffers]
-) and check for used packets in the transmit path of following
-packets. However, it will still receive interrupts if the
-VIRTIO_F_NOTIFY_ON_EMPTY feature is negotiated, indicating that
-the transmission queue is completely emptied.
-
-The normal behavior in this interrupt handler is to retrieve and
-new descriptors from the used ring and free the corresponding
-headers and packets.
-
- Setting Up Receive Buffers
-
-It is generally a good idea to keep the receive virtqueue as
-fully populated as possible: if it runs out, network performance
-will suffer.
-
-If the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6 or
-VIRTIO_NET_F_GUEST_UFO features are used, the Guest will need to
-accept packets of up to 65550 bytes long (the maximum size of a
-TCP or UDP packet, plus the 14 byte ethernet header), otherwise
-1514 bytes. So unless VIRTIO_NET_F_MRG_RXBUF is negotiated, every
-buffer in the receive queue needs to be at least this length [footnote:
-Obviously each one can be split across multiple descriptor
-elements.
-].
-
-If VIRTIO_NET_F_MRG_RXBUF is negotiated, each buffer must be at
-least the size of the struct virtio_net_hdr.
-
- Packet Receive Interrupt
-
-When a packet is copied into a buffer in the receiveq, the
-optimal path is to disable further interrupts for the receiveq
-(see [sub:Receiving-Used-Buffers]) and process packets until no
-more are found, then re-enable them.
-
-Processing packet involves:
-
- If the driver negotiated the VIRTIO_NET_F_MRG_RXBUF feature,
- then the “num_buffers” field indicates how many descriptors
- this packet is spread over (including this one). This allows
- receipt of large packets without having to allocate large
- buffers. In this case, there will be at least “num_buffers” in
- the used ring, and they should be chained together to form a
- single packet. The other buffers will not begin with a struct
- virtio_net_hdr.
-
- If the VIRTIO_NET_F_MRG_RXBUF feature was not negotiated, or
- the “num_buffers” field is one, then the entire packet will be
- contained within this buffer, immediately following the struct
- virtio_net_hdr.
-
- If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
- VIRTIO_NET_HDR_F_NEEDS_CSUM bit in the “flags” field may be
- set: if so, the checksum on the packet is incomplete and the “
- csum_start” and “csum_offset” fields indicate how to calculate
- it (see [ite:csum_start-is-set]).
-
- If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
- negotiated, then the “gso_type” may be something other than
- VIRTIO_NET_HDR_GSO_NONE, and the “gso_size” field indicates the
- desired MSS (see [enu:If-the-driver]).
-
- Control Virtqueue
-
-The driver uses the control virtqueue (if VIRTIO_NET_F_VTRL_VQ is
-negotiated) to send commands to manipulate various features of
-the device which would not easily map into the configuration
-space.
-
-All commands are of the following form:
-
-struct virtio_net_ctrl {
-
- u8 class;
-
- u8 command;
-
- u8 command-specific-data[];
-
- u8 ack;
-
-};
-
-
-
-/* ack values */
-
-#define VIRTIO_NET_OK 0
-
-#define VIRTIO_NET_ERR 1
-
-The class, command and command-specific-data are set by the
-driver, and the device sets the ack byte. There is little it can
-do except issue a diagnostic if the ack byte is not
-VIRTIO_NET_OK.
-
- Packet Receive Filtering
-
-If the VIRTIO_NET_F_CTRL_RX feature is negotiated, the driver can
-send control commands for promiscuous mode, multicast receiving,
-and filtering of MAC addresses.
-
-Note that in general, these commands are best-effort: unwanted
-packets may still arrive.
-
- Setting Promiscuous Mode
-
-#define VIRTIO_NET_CTRL_RX 0
-
- #define VIRTIO_NET_CTRL_RX_PROMISC 0
-
- #define VIRTIO_NET_CTRL_RX_ALLMULTI 1
-
-The class VIRTIO_NET_CTRL_RX has two commands:
-VIRTIO_NET_CTRL_RX_PROMISC turns promiscuous mode on and off, and
-VIRTIO_NET_CTRL_RX_ALLMULTI turns all-multicast receive on and
-off. The command-specific-data is one byte containing 0 (off) or
-1 (on).
-
- Setting MAC Address Filtering
-
-struct virtio_net_ctrl_mac {
-
- u32 entries;
-
- u8 macs[entries][ETH_ALEN];
-
-};
-
-
-
-#define VIRTIO_NET_CTRL_MAC 1
-
- #define VIRTIO_NET_CTRL_MAC_TABLE_SET 0
-
-The device can filter incoming packets by any number of
-destination MAC addresses.[footnote:
-Since there are no guarantees, it can use a hash filter
-orsilently switch to allmulti or promiscuous mode if it is given
-too many addresses.
-] This table is set using the class VIRTIO_NET_CTRL_MAC and the
-command VIRTIO_NET_CTRL_MAC_TABLE_SET. The command-specific-data
-is two variable length tables of 6-byte MAC addresses. The first
-table contains unicast addresses, and the second contains
-multicast addresses.
-
- VLAN Filtering
-
-If the driver negotiates the VIRTION_NET_F_CTRL_VLAN feature, it
-can control a VLAN filter table in the device.
-
-#define VIRTIO_NET_CTRL_VLAN 2
-
- #define VIRTIO_NET_CTRL_VLAN_ADD 0
-
- #define VIRTIO_NET_CTRL_VLAN_DEL 1
-
-Both the VIRTIO_NET_CTRL_VLAN_ADD and VIRTIO_NET_CTRL_VLAN_DEL
-command take a 16-bit VLAN id as the command-specific-data.
-
- Gratuitous Packet Sending
-
-If the driver negotiates the VIRTIO_NET_F_GUEST_ANNOUNCE (depends
-on VIRTIO_NET_F_CTRL_VQ), it can ask the guest to send gratuitous
-packets; this is usually done after the guest has been physically
-migrated, and needs to announce its presence on the new network
-links. (As hypervisor does not have the knowledge of guest
-network configuration (eg. tagged vlan) it is simplest to prod
-the guest in this way).
-
-#define VIRTIO_NET_CTRL_ANNOUNCE 3
-
- #define VIRTIO_NET_CTRL_ANNOUNCE_ACK 0
-
-The Guest needs to check VIRTIO_NET_S_ANNOUNCE bit in status
-field when it notices the changes of device configuration. The
-command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that
-driver has recevied the notification and device would clear the
-VIRTIO_NET_S_ANNOUNCE bit in the status filed after it received
-this command.
-
-Processing this notification involves:
-
- Sending the gratuitous packets or marking there are pending
- gratuitous packets to be sent and letting deferred routine to
- send them.
-
- Sending VIRTIO_NET_CTRL_ANNOUNCE_ACK command through control
- vq.
-
- .
-
-Appendix D: Block Device
-
-The virtio block device is a simple virtual block device (ie.
-disk). Read and write requests (and other exotic requests) are
-placed in the queue, and serviced (probably out of order) by the
-device except where noted.
-
- Configuration
-
- Subsystem Device ID 2
-
- Virtqueues 0:requestq.
-
- Feature bits
-
- VIRTIO_BLK_F_BARRIER (0) Host supports request barriers.
-
- VIRTIO_BLK_F_SIZE_MAX (1) Maximum size of any single segment is
- in “size_max”.
-
- VIRTIO_BLK_F_SEG_MAX (2) Maximum number of segments in a
- request is in “seg_max”.
-
- VIRTIO_BLK_F_GEOMETRY (4) Disk-style geometry specified in “
- geometry”.
-
- VIRTIO_BLK_F_RO (5) Device is read-only.
-
- VIRTIO_BLK_F_BLK_SIZE (6) Block size of disk is in “blk_size”.
-
- VIRTIO_BLK_F_SCSI (7) Device supports scsi packet commands.
-
- VIRTIO_BLK_F_FLUSH (9) Cache flush command support.
-
- Device configuration layout The capacity of the device
- (expressed in 512-byte sectors) is always present. The
- availability of the others all depend on various feature bits
- as indicated above. struct virtio_blk_config {
-
- u64 capacity;
-
- u32 size_max;
-
- u32 seg_max;
-
- struct virtio_blk_geometry {
-
- u16 cylinders;
-
- u8 heads;
-
- u8 sectors;
-
- } geometry;
-
- u32 blk_size;
-
-
-
-};
-
- Device Initialization
-
- The device size should be read from the “capacity”
- configuration field. No requests should be submitted which goes
- beyond this limit.
-
- If the VIRTIO_BLK_F_BLK_SIZE feature is negotiated, the
- blk_size field can be read to determine the optimal sector size
- for the driver to use. This does not effect the units used in
- the protocol (always 512 bytes), but awareness of the correct
- value can effect performance.
-
- If the VIRTIO_BLK_F_RO feature is set by the device, any write
- requests will fail.
-
- Device Operation
-
-The driver queues requests to the virtqueue, and they are used by
-the device (not necessarily in order). Each request is of form:
-
-struct virtio_blk_req {
-
-
-
- u32 type;
-
- u32 ioprio;
-
- u64 sector;
-
- char data[][512];
-
- u8 status;
-
-};
-
-If the device has VIRTIO_BLK_F_SCSI feature, it can also support
-scsi packet command requests, each of these requests is of form:struct virtio_scsi_pc_req {
-
- u32 type;
-
- u32 ioprio;
-
- u64 sector;
-
- char cmd[];
-
- char data[][512];
-
-#define SCSI_SENSE_BUFFERSIZE 96
-
- u8 sense[SCSI_SENSE_BUFFERSIZE];
-
- u32 errors;
-
- u32 data_len;
-
- u32 sense_len;
-
- u32 residual;
-
- u8 status;
-
-};
-
-The type of the request is either a read (VIRTIO_BLK_T_IN), a
-write (VIRTIO_BLK_T_OUT), a scsi packet command
-(VIRTIO_BLK_T_SCSI_CMD or VIRTIO_BLK_T_SCSI_CMD_OUT[footnote:
-the SCSI_CMD and SCSI_CMD_OUT types are equivalent, the device
-does not distinguish between them
-]) or a flush (VIRTIO_BLK_T_FLUSH or VIRTIO_BLK_T_FLUSH_OUT[footnote:
-the FLUSH and FLUSH_OUT types are equivalent, the device does not
-distinguish between them
-]). If the device has VIRTIO_BLK_F_BARRIER feature the high bit
-(VIRTIO_BLK_T_BARRIER) indicates that this request acts as a
-barrier and that all preceding requests must be complete before
-this one, and all following requests must not be started until
-this is complete. Note that a barrier does not flush caches in
-the underlying backend device in host, and thus does not serve as
-data consistency guarantee. Driver must use FLUSH request to
-flush the host cache.
-
-#define VIRTIO_BLK_T_IN 0
-
-#define VIRTIO_BLK_T_OUT 1
-
-#define VIRTIO_BLK_T_SCSI_CMD 2
-
-#define VIRTIO_BLK_T_SCSI_CMD_OUT 3
-
-#define VIRTIO_BLK_T_FLUSH 4
-
-#define VIRTIO_BLK_T_FLUSH_OUT 5
-
-#define VIRTIO_BLK_T_BARRIER 0x80000000
-
-The ioprio field is a hint about the relative priorities of
-requests to the device: higher numbers indicate more important
-requests.
-
-The sector number indicates the offset (multiplied by 512) where
-the read or write is to occur. This field is unused and set to 0
-for scsi packet commands and for flush commands.
-
-The cmd field is only present for scsi packet command requests,
-and indicates the command to perform. This field must reside in a
-single, separate read-only buffer; command length can be derived
-from the length of this buffer.
-
-Note that these first three (four for scsi packet commands)
-fields are always read-only: the data field is either read-only
-or write-only, depending on the request. The size of the read or
-write can be derived from the total size of the request buffers.
-
-The sense field is only present for scsi packet command requests,
-and indicates the buffer for scsi sense data.
-
-The data_len field is only present for scsi packet command
-requests, this field is deprecated, and should be ignored by the
-driver. Historically, devices copied data length there.
-
-The sense_len field is only present for scsi packet command
-requests and indicates the number of bytes actually written to
-the sense buffer.
-
-The residual field is only present for scsi packet command
-requests and indicates the residual size, calculated as data
-length - number of bytes actually transferred.
-
-The final status byte is written by the device: either
-VIRTIO_BLK_S_OK for success, VIRTIO_BLK_S_IOERR for host or guest
-error or VIRTIO_BLK_S_UNSUPP for a request unsupported by host:#define VIRTIO_BLK_S_OK 0
-
-#define VIRTIO_BLK_S_IOERR 1
-
-#define VIRTIO_BLK_S_UNSUPP 2
-
-Historically, devices assumed that the fields type, ioprio and
-sector reside in a single, separate read-only buffer; the fields
-errors, data_len, sense_len and residual reside in a single,
-separate write-only buffer; the sense field in a separate
-write-only buffer of size 96 bytes, by itself; the fields errors,
-data_len, sense_len and residual in a single write-only buffer;
-and the status field is a separate read-only buffer of size 1
-byte, by itself.
-
-Appendix E: Console Device
-
-The virtio console device is a simple device for data input and
-output. A device may have one or more ports. Each port has a pair
-of input and output virtqueues. Moreover, a device has a pair of
-control IO virtqueues. The control virtqueues are used to
-communicate information between the device and the driver about
-ports being opened and closed on either side of the connection,
-indication from the host about whether a particular port is a
-console port, adding new ports, port hot-plug/unplug, etc., and
-indication from the guest about whether a port or a device was
-successfully added, port open/close, etc.. For data IO, one or
-more empty buffers are placed in the receive queue for incoming
-data and outgoing characters are placed in the transmit queue.
-
- Configuration
-
- Subsystem Device ID 3
-
- Virtqueues 0:receiveq(port0). 1:transmitq(port0), 2:control
- receiveq[footnote:
-Ports 2 onwards only if VIRTIO_CONSOLE_F_MULTIPORT is set
-], 3:control transmitq, 4:receiveq(port1), 5:transmitq(port1),
- ...
-
- Feature bits
-
- VIRTIO_CONSOLE_F_SIZE (0) Configuration cols and rows fields
- are valid.
-
- VIRTIO_CONSOLE_F_MULTIPORT(1) Device has support for multiple
- ports; configuration fields nr_ports and max_nr_ports are
- valid and control virtqueues will be used.
-
- Device configuration layout The size of the console is supplied
- in the configuration space if the VIRTIO_CONSOLE_F_SIZE feature
- is set. Furthermore, if the VIRTIO_CONSOLE_F_MULTIPORT feature
- is set, the maximum number of ports supported by the device can
- be fetched.struct virtio_console_config {
-
- u16 cols;
-
- u16 rows;
-
-
-
- u32 max_nr_ports;
-
-};
-
- Device Initialization
-
- If the VIRTIO_CONSOLE_F_SIZE feature is negotiated, the driver
- can read the console dimensions from the configuration fields.
-
- If the VIRTIO_CONSOLE_F_MULTIPORT feature is negotiated, the
- driver can spawn multiple ports, not all of which may be
- attached to a console. Some could be generic ports. In this
- case, the control virtqueues are enabled and according to the
- max_nr_ports configuration-space value, the appropriate number
- of virtqueues are created. A control message indicating the
- driver is ready is sent to the host. The host can then send
- control messages for adding new ports to the device. After
- creating and initializing each port, a
- VIRTIO_CONSOLE_PORT_READY control message is sent to the host
- for that port so the host can let us know of any additional
- configuration options set for that port.
-
- The receiveq for each port is populated with one or more
- receive buffers.
-
- Device Operation
-
- For output, a buffer containing the characters is placed in the
- port's transmitq.[footnote:
-Because this is high importance and low bandwidth, the current
-Linux implementation polls for the buffer to be used, rather than
-waiting for an interrupt, simplifying the implementation
-significantly. However, for generic serial ports with the
-O_NONBLOCK flag set, the polling limitation is relaxed and the
-consumed buffers are freed upon the next write or poll call or
-when a port is closed or hot-unplugged.
-]
-
- When a buffer is used in the receiveq (signalled by an
- interrupt), the contents is the input to the port associated
- with the virtqueue for which the notification was received.
-
- If the driver negotiated the VIRTIO_CONSOLE_F_SIZE feature, a
- configuration change interrupt may occur. The updated size can
- be read from the configuration fields.
-
- If the driver negotiated the VIRTIO_CONSOLE_F_MULTIPORT
- feature, active ports are announced by the host using the
- VIRTIO_CONSOLE_PORT_ADD control message. The same message is
- used for port hot-plug as well.
-
- If the host specified a port `name', a sysfs attribute is
- created with the name filled in, so that udev rules can be
- written that can create a symlink from the port's name to the
- char device for port discovery by applications in the guest.
-
- Changes to ports' state are effected by control messages.
- Appropriate action is taken on the port indicated in the
- control message. The layout of the structure of the control
- buffer and the events associated are:struct virtio_console_control {
-
- uint32_t id; /* Port number */
-
- uint16_t event; /* The kind of control event */
-
- uint16_t value; /* Extra information for the event */
-
-};
-
-
-
-/* Some events for the internal messages (control packets) */
-
-
-
-#define VIRTIO_CONSOLE_DEVICE_READY 0
-
-#define VIRTIO_CONSOLE_PORT_ADD 1
-
-#define VIRTIO_CONSOLE_PORT_REMOVE 2
-
-#define VIRTIO_CONSOLE_PORT_READY 3
-
-#define VIRTIO_CONSOLE_CONSOLE_PORT 4
-
-#define VIRTIO_CONSOLE_RESIZE 5
-
-#define VIRTIO_CONSOLE_PORT_OPEN 6
-
-#define VIRTIO_CONSOLE_PORT_NAME 7
-
-Appendix F: Entropy Device
-
-The virtio entropy device supplies high-quality randomness for
-guest use.
-
- Configuration
-
- Subsystem Device ID 4
-
- Virtqueues 0:requestq.
-
- Feature bits None currently defined
-
- Device configuration layout None currently defined.
-
- Device Initialization
-
- The virtqueue is initialized
-
- Device Operation
-
-When the driver requires random bytes, it places the descriptor
-of one or more buffers in the queue. It will be completely filled
-by random data by the device.
-
-Appendix G: Memory Balloon Device
-
-The virtio memory balloon device is a primitive device for
-managing guest memory: the device asks for a certain amount of
-memory, and the guest supplies it (or withdraws it, if the device
-has more than it asks for). This allows the guest to adapt to
-changes in allowance of underlying physical memory. If the
-feature is negotiated, the device can also be used to communicate
-guest memory statistics to the host.
-
- Configuration
-
- Subsystem Device ID 5
-
- Virtqueues 0:inflateq. 1:deflateq. 2:statsq.[footnote:
-Only if VIRTIO_BALLON_F_STATS_VQ set
-]
-
- Feature bits
-
- VIRTIO_BALLOON_F_MUST_TELL_HOST (0) Host must be told before
- pages from the balloon are used.
-
- VIRTIO_BALLOON_F_STATS_VQ (1) A virtqueue for reporting guest
- memory statistics is present.
-
- Device configuration layout Both fields of this configuration
- are always available. Note that they are little endian, despite
- convention that device fields are guest endian:struct virtio_balloon_config {
-
- u32 num_pages;
-
- u32 actual;
-
-};
-
- Device Initialization
-
- The inflate and deflate virtqueues are identified.
-
- If the VIRTIO_BALLOON_F_STATS_VQ feature bit is negotiated:
-
- Identify the stats virtqueue.
-
- Add one empty buffer to the stats virtqueue and notify the
- host.
-
-Device operation begins immediately.
-
- Device Operation
-
- Memory Ballooning The device is driven by the receipt of a
- configuration change interrupt.
-
- The “num_pages” configuration field is examined. If this is
- greater than the “actual” number of pages, memory must be given
- to the balloon. If it is less than the “actual” number of
- pages, memory may be taken back from the balloon for general
- use.
-
- To supply memory to the balloon (aka. inflate):
-
- The driver constructs an array of addresses of unused memory
- pages. These addresses are divided by 4096[footnote:
-This is historical, and independent of the guest page size
-] and the descriptor describing the resulting 32-bit array is
- added to the inflateq.
-
- To remove memory from the balloon (aka. deflate):
-
- The driver constructs an array of addresses of memory pages it
- has previously given to the balloon, as described above. This
- descriptor is added to the deflateq.
-
- If the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is set, the
- guest may not use these requested pages until that descriptor
- in the deflateq has been used by the device.
-
- Otherwise, the guest may begin to re-use pages previously given
- to the balloon before the device has acknowledged their
- withdrawl. [footnote:
-In this case, deflation advice is merely a courtesy
-]
-
- In either case, once the device has completed the inflation or
- deflation, the “actual” field of the configuration should be
- updated to reflect the new number of pages in the balloon.[footnote:
-As updates to configuration space are not atomic, this field
-isn't particularly reliable, but can be used to diagnose buggy
-guests.
-]
-
- Memory Statistics
-
-The stats virtqueue is atypical because communication is driven
-by the device (not the driver). The channel becomes active at
-driver initialization time when the driver adds an empty buffer
-and notifies the device. A request for memory statistics proceeds
-as follows:
-
- The device pushes the buffer onto the used ring and sends an
- interrupt.
-
- The driver pops the used buffer and discards it.
-
- The driver collects memory statistics and writes them into a
- new buffer.
-
- The driver adds the buffer to the virtqueue and notifies the
- device.
-
- The device pops the buffer (retaining it to initiate a
- subsequent request) and consumes the statistics.
-
- Memory Statistics Format Each statistic consists of a 16 bit
- tag and a 64 bit value. Both quantities are represented in the
- native endian of the guest. All statistics are optional and the
- driver may choose which ones to supply. To guarantee backwards
- compatibility, unsupported statistics should be omitted.
-
- struct virtio_balloon_stat {
-
-#define VIRTIO_BALLOON_S_SWAP_IN 0
-
-#define VIRTIO_BALLOON_S_SWAP_OUT 1
-
-#define VIRTIO_BALLOON_S_MAJFLT 2
-
-#define VIRTIO_BALLOON_S_MINFLT 3
-
-#define VIRTIO_BALLOON_S_MEMFREE 4
-
-#define VIRTIO_BALLOON_S_MEMTOT 5
-
- u16 tag;
-
- u64 val;
-
-} __attribute__((packed));
-
- Tags
-
- VIRTIO_BALLOON_S_SWAP_IN The amount of memory that has been
- swapped in (in bytes).
-
- VIRTIO_BALLOON_S_SWAP_OUT The amount of memory that has been
- swapped out to disk (in bytes).
-
- VIRTIO_BALLOON_S_MAJFLT The number of major page faults that
- have occurred.
-
- VIRTIO_BALLOON_S_MINFLT The number of minor page faults that
- have occurred.
-
- VIRTIO_BALLOON_S_MEMFREE The amount of memory not being used
- for any purpose (in bytes).
-
- VIRTIO_BALLOON_S_MEMTOT The total amount of memory available
- (in bytes).
-
-Appendix H: Rpmsg: Remote Processor Messaging
-
-Virtio rpmsg devices represent remote processors on the system
-which run in asymmetric multi-processing (AMP) configuration, and
-which are usually used to offload cpu-intensive tasks from the
-main application processor (a typical SoC methodology).
-
-Virtio is being used to communicate with those remote processors;
-empty buffers are placed in one virtqueue for receiving messages,
-and non-empty buffers, containing outbound messages, are enqueued
-in a second virtqueue for transmission.
-
-Numerous communication channels can be multiplexed over those two
-virtqueues, so different entities, running on the application and
-remote processor, can directly communicate in a point-to-point
-fashion.
-
- Configuration
-
- Subsystem Device ID 7
-
- Virtqueues 0:receiveq. 1:transmitq.
-
- Feature bits
-
- VIRTIO_RPMSG_F_NS (0) Device sends (and capable of receiving)
- name service messages announcing the creation (or
- destruction) of a channel:/**
-
- * struct rpmsg_ns_msg - dynamic name service announcement
-message
-
- * @name: name of remote service that is published
-
- * @addr: address of remote service that is published
-
- * @flags: indicates whether service is created or destroyed
-
- *
-
- * This message is sent across to publish a new service (or
-announce
-
- * about its removal). When we receives these messages, an
-appropriate
-
- * rpmsg channel (i.e device) is created/destroyed.
-
- */
-
-struct rpmsg_ns_msgoon_config {
-
- char name[RPMSG_NAME_SIZE];
-
- u32 addr;
-
- u32 flags;
-
-} __packed;
-
-
-
-/**
-
- * enum rpmsg_ns_flags - dynamic name service announcement flags
-
- *
-
- * @RPMSG_NS_CREATE: a new remote service was just created
-
- * @RPMSG_NS_DESTROY: a remote service was just destroyed
-
- */
-
-enum rpmsg_ns_flags {
-
- RPMSG_NS_CREATE = 0,
-
- RPMSG_NS_DESTROY = 1,
-
-};
-
- Device configuration layout
-
-At his point none currently defined.
-
- Device Initialization
-
- The initialization routine should identify the receive and
- transmission virtqueues.
-
- The receive virtqueue should be filled with receive buffers.
-
- Device Operation
-
-Messages are transmitted by placing them in the transmitq, and
-buffers for inbound messages are placed in the receiveq. In any
-case, messages are always preceded by the following header: /**
-
- * struct rpmsg_hdr - common header for all rpmsg messages
-
- * @src: source address
-
- * @dst: destination address
-
- * @reserved: reserved for future use
-
- * @len: length of payload (in bytes)
-
- * @flags: message flags
-
- * @data: @len bytes of message payload data
-
- *
-
- * Every message sent(/received) on the rpmsg bus begins with
-this header.
-
- */
-
-struct rpmsg_hdr {
-
- u32 src;
-
- u32 dst;
-
- u32 reserved;
-
- u16 len;
-
- u16 flags;
-
- u8 data[0];
-
-} __packed;
-
-Appendix I: SCSI Host Device
-
-The virtio SCSI host device groups together one or more virtual
-logical units (such as disks), and allows communicating to them
-using the SCSI protocol. An instance of the device represents a
-SCSI host to which many targets and LUNs are attached.
-
-The virtio SCSI device services two kinds of requests:
-
- command requests for a logical unit;
-
- task management functions related to a logical unit, target or
- command.
-
-The device is also able to send out notifications about added and
-removed logical units. Together, these capabilities provide a
-SCSI transport protocol that uses virtqueues as the transfer
-medium. In the transport protocol, the virtio driver acts as the
-initiator, while the virtio SCSI host provides one or more
-targets that receive and process the requests.
-
- Configuration
-
- Subsystem Device ID 8
-
- Virtqueues 0:controlq; 1:eventq; 2..n:request queues.
-
- Feature bits
-
- VIRTIO_SCSI_F_INOUT (0) A single request can include both
- read-only and write-only data buffers.
-
- VIRTIO_SCSI_F_HOTPLUG (1) The host should enable
- hot-plug/hot-unplug of new LUNs and targets on the SCSI bus.
-
- Device configuration layout All fields of this configuration
- are always available. sense_size and cdb_size are writable by
- the guest.struct virtio_scsi_config {
-
- u32 num_queues;
-
- u32 seg_max;
-
- u32 max_sectors;
-
- u32 cmd_per_lun;
-
- u32 event_info_size;
-
- u32 sense_size;
-
- u32 cdb_size;
-
- u16 max_channel;
-
- u16 max_target;
-
- u32 max_lun;
-
-};
-
- num_queues is the total number of request virtqueues exposed by
- the device. The driver is free to use only one request queue,
- or it can use more to achieve better performance.
-
- seg_max is the maximum number of segments that can be in a
- command. A bidirectional command can include seg_max input
- segments and seg_max output segments.
-
- max_sectors is a hint to the guest about the maximum transfer
- size it should use.
-
- cmd_per_lun is a hint to the guest about the maximum number of
- linked commands it should send to one LUN. The actual value
- to be used is the minimum of cmd_per_lun and the virtqueue
- size.
-
- event_info_size is the maximum size that the device will fill
- for buffers that the driver places in the eventq. The driver
- should always put buffers at least of this size. It is
- written by the device depending on the set of negotated
- features.
-
- sense_size is the maximum size of the sense data that the
- device will write. The default value is written by the device
- and will always be 96, but the driver can modify it. It is
- restored to the default when the device is reset.
-
- cdb_size is the maximum size of the CDB that the driver will
- write. The default value is written by the device and will
- always be 32, but the driver can likewise modify it. It is
- restored to the default when the device is reset.
-
- max_channel, max_target and max_lun can be used by the driver
- as hints to constrain scanning the logical units on the
- host.h
-
- Device Initialization
-
-The initialization routine should first of all discover the
-device's virtqueues.
-
-If the driver uses the eventq, it should then place at least a
-buffer in the eventq.
-
-The driver can immediately issue requests (for example, INQUIRY
-or REPORT LUNS) or task management functions (for example, I_T
-RESET).
-
- Device Operation: request queues
-
-The driver queues requests to an arbitrary request queue, and
-they are used by the device on that same queue. It is the
-responsibility of the driver to ensure strict request ordering
-for commands placed on different queues, because they will be
-consumed with no order constraints.
-
-Requests have the following format:
-
-struct virtio_scsi_req_cmd {
-
- // Read-only
-
- u8 lun[8];
-
- u64 id;
-
- u8 task_attr;
-
- u8 prio;
-
- u8 crn;
-
- char cdb[cdb_size];
-
- char dataout[];
-
- // Write-only part
-
- u32 sense_len;
-
- u32 residual;
-
- u16 status_qualifier;
-
- u8 status;
-
- u8 response;
-
- u8 sense[sense_size];
-
- char datain[];
-
-};
-
-
-
-/* command-specific response values */
-
-#define VIRTIO_SCSI_S_OK 0
-
-#define VIRTIO_SCSI_S_OVERRUN 1
-
-#define VIRTIO_SCSI_S_ABORTED 2
-
-#define VIRTIO_SCSI_S_BAD_TARGET 3
-
-#define VIRTIO_SCSI_S_RESET 4
-
-#define VIRTIO_SCSI_S_BUSY 5
-
-#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6
-
-#define VIRTIO_SCSI_S_TARGET_FAILURE 7
-
-#define VIRTIO_SCSI_S_NEXUS_FAILURE 8
-
-#define VIRTIO_SCSI_S_FAILURE 9
-
-
-
-/* task_attr */
-
-#define VIRTIO_SCSI_S_SIMPLE 0
-
-#define VIRTIO_SCSI_S_ORDERED 1
-
-#define VIRTIO_SCSI_S_HEAD 2
-
-#define VIRTIO_SCSI_S_ACA 3
-
-The lun field addresses a target and logical unit in the
-virtio-scsi device's SCSI domain. The only supported format for
-the LUN field is: first byte set to 1, second byte set to target,
-third and fourth byte representing a single level LUN structure,
-followed by four zero bytes. With this representation, a
-virtio-scsi device can serve up to 256 targets and 16384 LUNs per
-target.
-
-The id field is the command identifier (“tag”).
-
-task_attr, prio and crn should be left to zero. task_attr defines
-the task attribute as in the table above, but all task attributes
-may be mapped to SIMPLE by the device; crn may also be provided
-by clients, but is generally expected to be 0. The maximum CRN
-value defined by the protocol is 255, since CRN is stored in an
-8-bit integer.
-
-All of these fields are defined in SAM. They are always
-read-only, as are the cdb and dataout field. The cdb_size is
-taken from the configuration space.
-
-sense and subsequent fields are always write-only. The sense_len
-field indicates the number of bytes actually written to the sense
-buffer. The residual field indicates the residual size,
-calculated as “data_length - number_of_transferred_bytes”, for
-read or write operations. For bidirectional commands, the
-number_of_transferred_bytes includes both read and written bytes.
-A residual field that is less than the size of datain means that
-the dataout field was processed entirely. A residual field that
-exceeds the size of datain means that the dataout field was
-processed partially and the datain field was not processed at
-all.
-
-The status byte is written by the device to be the status code as
-defined in SAM.
-
-The response byte is written by the device to be one of the
-following:
-
- VIRTIO_SCSI_S_OK when the request was completed and the status
- byte is filled with a SCSI status code (not necessarily
- "GOOD").
-
- VIRTIO_SCSI_S_OVERRUN if the content of the CDB requires
- transferring more data than is available in the data buffers.
-
- VIRTIO_SCSI_S_ABORTED if the request was cancelled due to an
- ABORT TASK or ABORT TASK SET task management function.
-
- VIRTIO_SCSI_S_BAD_TARGET if the request was never processed
- because the target indicated by the lun field does not exist.
-
- VIRTIO_SCSI_S_RESET if the request was cancelled due to a bus
- or device reset (including a task management function).
-
- VIRTIO_SCSI_S_TRANSPORT_FAILURE if the request failed due to a
- problem in the connection between the host and the target
- (severed link).
-
- VIRTIO_SCSI_S_TARGET_FAILURE if the target is suffering a
- failure and the guest should not retry on other paths.
-
- VIRTIO_SCSI_S_NEXUS_FAILURE if the nexus is suffering a failure
- but retrying on other paths might yield a different result.
-
- VIRTIO_SCSI_S_BUSY if the request failed but retrying on the
- same path should work.
-
- VIRTIO_SCSI_S_FAILURE for other host or guest error. In
- particular, if neither dataout nor datain is empty, and the
- VIRTIO_SCSI_F_INOUT feature has not been negotiated, the
- request will be immediately returned with a response equal to
- VIRTIO_SCSI_S_FAILURE.
-
- Device Operation: controlq
-
-The controlq is used for other SCSI transport operations.
-Requests have the following format:
-
-struct virtio_scsi_ctrl {
-
- u32 type;
-
- ...
-
- u8 response;
-
-};
-
-
-
-/* response values valid for all commands */
-
-#define VIRTIO_SCSI_S_OK 0
-
-#define VIRTIO_SCSI_S_BAD_TARGET 3
-
-#define VIRTIO_SCSI_S_BUSY 5
-
-#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6
-
-#define VIRTIO_SCSI_S_TARGET_FAILURE 7
-
-#define VIRTIO_SCSI_S_NEXUS_FAILURE 8
-
-#define VIRTIO_SCSI_S_FAILURE 9
-
-#define VIRTIO_SCSI_S_INCORRECT_LUN 12
-
-The type identifies the remaining fields.
-
-The following commands are defined:
-
- Task management function
-#define VIRTIO_SCSI_T_TMF 0
-
-
-
-#define VIRTIO_SCSI_T_TMF_ABORT_TASK 0
-
-#define VIRTIO_SCSI_T_TMF_ABORT_TASK_SET 1
-
-#define VIRTIO_SCSI_T_TMF_CLEAR_ACA 2
-
-#define VIRTIO_SCSI_T_TMF_CLEAR_TASK_SET 3
-
-#define VIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET 4
-
-#define VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET 5
-
-#define VIRTIO_SCSI_T_TMF_QUERY_TASK 6
-
-#define VIRTIO_SCSI_T_TMF_QUERY_TASK_SET 7
-
-
-
-struct virtio_scsi_ctrl_tmf
-
-{
-
- // Read-only part
-
- u32 type;
-
- u32 subtype;
-
- u8 lun[8];
-
- u64 id;
-
- // Write-only part
-
- u8 response;
-
-}
-
-
-
-/* command-specific response values */
-
-#define VIRTIO_SCSI_S_FUNCTION_COMPLETE 0
-
-#define VIRTIO_SCSI_S_FUNCTION_SUCCEEDED 10
-
-#define VIRTIO_SCSI_S_FUNCTION_REJECTED 11
-
- The type is VIRTIO_SCSI_T_TMF; the subtype field defines. All
- fields except response are filled by the driver. The subtype
- field must always be specified and identifies the requested
- task management function.
-
- Other fields may be irrelevant for the requested TMF; if so,
- they are ignored but they should still be present. The lun
- field is in the same format specified for request queues; the
- single level LUN is ignored when the task management function
- addresses a whole I_T nexus. When relevant, the value of the id
- field is matched against the id values passed on the requestq.
-
- The outcome of the task management function is written by the
- device in the response field. The command-specific response
- values map 1-to-1 with those defined in SAM.
-
- Asynchronous notification query
-#define VIRTIO_SCSI_T_AN_QUERY 1
-
-
-
-struct virtio_scsi_ctrl_an {
-
- // Read-only part
-
- u32 type;
-
- u8 lun[8];
-
- u32 event_requested;
-
- // Write-only part
-
- u32 event_actual;
-
- u8 response;
-
-}
-
-
-
-#define VIRTIO_SCSI_EVT_ASYNC_OPERATIONAL_CHANGE 2
-
-#define VIRTIO_SCSI_EVT_ASYNC_POWER_MGMT 4
-
-#define VIRTIO_SCSI_EVT_ASYNC_EXTERNAL_REQUEST 8
-
-#define VIRTIO_SCSI_EVT_ASYNC_MEDIA_CHANGE 16
-
-#define VIRTIO_SCSI_EVT_ASYNC_MULTI_HOST 32
-
-#define VIRTIO_SCSI_EVT_ASYNC_DEVICE_BUSY 64
-
- By sending this command, the driver asks the device which
- events the given LUN can report, as described in paragraphs 6.6
- and A.6 of the SCSI MMC specification. The driver writes the
- events it is interested in into the event_requested; the device
- responds by writing the events that it supports into
- event_actual.
-
- The type is VIRTIO_SCSI_T_AN_QUERY. The lun and event_requested
- fields are written by the driver. The event_actual and response
- fields are written by the device.
-
- No command-specific values are defined for the response byte.
-
- Asynchronous notification subscription
-#define VIRTIO_SCSI_T_AN_SUBSCRIBE 2
-
-
-
-struct virtio_scsi_ctrl_an {
-
- // Read-only part
-
- u32 type;
-
- u8 lun[8];
-
- u32 event_requested;
-
- // Write-only part
-
- u32 event_actual;
-
- u8 response;
-
-}
-
- By sending this command, the driver asks the specified LUN to
- report events for its physical interface, again as described in
- the SCSI MMC specification. The driver writes the events it is
- interested in into the event_requested; the device responds by
- writing the events that it supports into event_actual.
-
- Event types are the same as for the asynchronous notification
- query message.
-
- The type is VIRTIO_SCSI_T_AN_SUBSCRIBE. The lun and
- event_requested fields are written by the driver. The
- event_actual and response fields are written by the device.
-
- No command-specific values are defined for the response byte.
-
- Device Operation: eventq
-
-The eventq is used by the device to report information on logical
-units that are attached to it. The driver should always leave a
-few buffers ready in the eventq. In general, the device will not
-queue events to cope with an empty eventq, and will end up
-dropping events if it finds no buffer ready. However, when
-reporting events for many LUNs (e.g. when a whole target
-disappears), the device can throttle events to avoid dropping
-them. For this reason, placing 10-15 buffers on the event queue
-should be enough.
-
-Buffers are placed in the eventq and filled by the device when
-interesting events occur. The buffers should be strictly
-write-only (device-filled) and the size of the buffers should be
-at least the value given in the device's configuration
-information.
-
-Buffers returned by the device on the eventq will be referred to
-as "events" in the rest of this section. Events have the
-following format:
-
-#define VIRTIO_SCSI_T_EVENTS_MISSED 0x80000000
-
-
-
-struct virtio_scsi_event {
-
- // Write-only part
-
- u32 event;
-
- ...
-
-}
-
-If bit 31 is set in the event field, the device failed to report
-an event due to missing buffers. In this case, the driver should
-poll the logical units for unit attention conditions, and/or do
-whatever form of bus scan is appropriate for the guest operating
-system.
-
-Other data that the device writes to the buffer depends on the
-contents of the event field. The following events are defined:
-
- No event
-#define VIRTIO_SCSI_T_NO_EVENT 0
-
- This event is fired in the following cases:
-
- When the device detects in the eventq a buffer that is shorter
- than what is indicated in the configuration field, it might
- use it immediately and put this dummy value in the event
- field. A well-written driver will never observe this
- situation.
-
- When events are dropped, the device may signal this event as
- soon as the drivers makes a buffer available, in order to
- request action from the driver. In this case, of course, this
- event will be reported with the VIRTIO_SCSI_T_EVENTS_MISSED
- flag.
-
- Transport reset
-#define VIRTIO_SCSI_T_TRANSPORT_RESET 1
-
-
-
-struct virtio_scsi_event_reset {
-
- // Write-only part
-
- u32 event;
-
- u8 lun[8];
-
- u32 reason;
-
-}
-
-
-
-#define VIRTIO_SCSI_EVT_RESET_HARD 0
-
-#define VIRTIO_SCSI_EVT_RESET_RESCAN 1
-
-#define VIRTIO_SCSI_EVT_RESET_REMOVED 2
-
- By sending this event, the device signals that a logical unit
- on a target has been reset, including the case of a new device
- appearing or disappearing on the bus.The device fills in all
- fields. The event field is set to
- VIRTIO_SCSI_T_TRANSPORT_RESET. The lun field addresses a
- logical unit in the SCSI host.
-
- The reason value is one of the three #define values appearing
- above:
-
- VIRTIO_SCSI_EVT_RESET_REMOVED (“LUN/target removed”) is used if
- the target or logical unit is no longer able to receive
- commands.
-
- VIRTIO_SCSI_EVT_RESET_HARD (“LUN hard reset”) is used if the
- logical unit has been reset, but is still present.
-
- VIRTIO_SCSI_EVT_RESET_RESCAN (“rescan LUN/target”) is used if a
- target or logical unit has just appeared on the device.
-
- The “removed” and “rescan” events, when sent for LUN 0, may
- apply to the entire target. After receiving them the driver
- should ask the initiator to rescan the target, in order to
- detect the case when an entire target has appeared or
- disappeared. These two events will never be reported unless the
- VIRTIO_SCSI_F_HOTPLUG feature was negotiated between the host
- and the guest.
-
- Events will also be reported via sense codes (this obviously
- does not apply to newly appeared buses or targets, since the
- application has never discovered them):
-
- “LUN/target removed” maps to sense key ILLEGAL REQUEST, asc
- 0x25, ascq 0x00 (LOGICAL UNIT NOT SUPPORTED)
-
- “LUN hard reset” maps to sense key UNIT ATTENTION, asc 0x29
- (POWER ON, RESET OR BUS DEVICE RESET OCCURRED)
-
- “rescan LUN/target” maps to sense key UNIT ATTENTION, asc 0x3f,
- ascq 0x0e (REPORTED LUNS DATA HAS CHANGED)
-
- The preferred way to detect transport reset is always to use
- events, because sense codes are only seen by the driver when it
- sends a SCSI command to the logical unit or target. However, in
- case events are dropped, the initiator will still be able to
- synchronize with the actual state of the controller if the
- driver asks the initiator to rescan of the SCSI bus. During the
- rescan, the initiator will be able to observe the above sense
- codes, and it will process them as if it the driver had
- received the equivalent event.
-
- Asynchronous notification
-#define VIRTIO_SCSI_T_ASYNC_NOTIFY 2
-
-
-
-struct virtio_scsi_event_an {
-
- // Write-only part
-
- u32 event;
-
- u8 lun[8];
-
- u32 reason;
-
-}
-
- By sending this event, the device signals that an asynchronous
- event was fired from a physical interface.
-
- All fields are written by the device. The event field is set to
- VIRTIO_SCSI_T_ASYNC_NOTIFY. The lun field addresses a logical
- unit in the SCSI host. The reason field is a subset of the
- events that the driver has subscribed to via the "Asynchronous
- notification subscription" command.
-
- When dropped events are reported, the driver should poll for
- asynchronous events manually using SCSI commands.
-
-Appendix X: virtio-mmio
-
-Virtual environments without PCI support (a common situation in
-embedded devices models) might use simple memory mapped device (“
-virtio-mmio”) instead of the PCI device.
-
-The memory mapped virtio device behaviour is based on the PCI
-device specification. Therefore most of operations like device
-initialization, queues configuration and buffer transfers are
-nearly identical. Existing differences are described in the
-following sections.
-
- Device Initialization
-
-Instead of using the PCI IO space for virtio header, the “
-virtio-mmio” device provides a set of memory mapped control
-registers, all 32 bits wide, followed by device-specific
-configuration space. The following list presents their layout:
-
- Offset from the device base address | Direction | Name
- Description
-
- 0x000 | R | MagicValue
- “virt” string.
-
- 0x004 | R | Version
- Device version number. Currently must be 1.
-
- 0x008 | R | DeviceID
- Virtio Subsystem Device ID (ie. 1 for network card).
-
- 0x00c | R | VendorID
- Virtio Subsystem Vendor ID.
-
- 0x010 | R | HostFeatures
- Flags representing features the device supports.
- Reading from this register returns 32 consecutive flag bits,
- first bit depending on the last value written to
- HostFeaturesSel register. Access to this register returns bits HostFeaturesSel*32
-
- to (HostFeaturesSel*32)+31
-, eg. feature bits 0 to 31 if
- HostFeaturesSel is set to 0 and features bits 32 to 63 if
- HostFeaturesSel is set to 1. Also see [sub:Feature-Bits]
-
- 0x014 | W | HostFeaturesSel
- Device (Host) features word selection.
- Writing to this register selects a set of 32 device feature bits
- accessible by reading from HostFeatures register. Device driver
- must write a value to the HostFeaturesSel register before
- reading from the HostFeatures register.
-
- 0x020 | W | GuestFeatures
- Flags representing device features understood and activated by
- the driver.
- Writing to this register sets 32 consecutive flag bits, first
- bit depending on the last value written to GuestFeaturesSel
- register. Access to this register sets bits GuestFeaturesSel*32
-
- to (GuestFeaturesSel*32)+31
-, eg. feature bits 0 to 31 if
- GuestFeaturesSel is set to 0 and features bits 32 to 63 if
- GuestFeaturesSel is set to 1. Also see [sub:Feature-Bits]
-
- 0x024 | W | GuestFeaturesSel
- Activated (Guest) features word selection.
- Writing to this register selects a set of 32 activated feature
- bits accessible by writing to the GuestFeatures register.
- Device driver must write a value to the GuestFeaturesSel
- register before writing to the GuestFeatures register.
-
- 0x028 | W | GuestPageSize
- Guest page size.
- Device driver must write the guest page size in bytes to the
- register during initialization, before any queues are used.
- This value must be a power of 2 and is used by the Host to
- calculate Guest address of the first queue page (see QueuePFN).
-
- 0x030 | W | QueueSel
- Virtual queue index (first queue is 0).
- Writing to this register selects the virtual queue that the
- following operations on QueueNum, QueueAlign and QueuePFN apply
- to.
-
- 0x034 | R | QueueNumMax
- Maximum virtual queue size.
- Reading from the register returns the maximum size of the queue
- the Host is ready to process or zero (0x0) if the queue is not
- available. This applies to the queue selected by writing to
- QueueSel and is allowed only when QueuePFN is set to zero
- (0x0), so when the queue is not actively used.
-
- 0x038 | W | QueueNum
- Virtual queue size.
- Queue size is a number of elements in the queue, therefore size
- of the descriptor table and both available and used rings.
- Writing to this register notifies the Host what size of the
- queue the Guest will use. This applies to the queue selected by
- writing to QueueSel.
-
- 0x03c | W | QueueAlign
- Used Ring alignment in the virtual queue.
- Writing to this register notifies the Host about alignment
- boundary of the Used Ring in bytes. This value must be a power
- of 2 and applies to the queue selected by writing to QueueSel.
-
- 0x040 | RW | QueuePFN
- Guest physical page number of the virtual queue.
- Writing to this register notifies the host about location of the
- virtual queue in the Guest's physical address space. This value
- is the index number of a page starting with the queue
- Descriptor Table. Value zero (0x0) means physical address zero
- (0x00000000) and is illegal. When the Guest stops using the
- queue it must write zero (0x0) to this register.
- Reading from this register returns the currently used page
- number of the queue, therefore a value other than zero (0x0)
- means that the queue is in use.
- Both read and write accesses apply to the queue selected by
- writing to QueueSel.
-
- 0x050 | W | QueueNotify
- Queue notifier.
- Writing a queue index to this register notifies the Host that
- there are new buffers to process in the queue.
-
- 0x60 | R | InterruptStatus
-Interrupt status.
-Reading from this register returns a bit mask of interrupts
- asserted by the device. An interrupt is asserted if the
- corresponding bit is set, ie. equals one (1).
-
- Bit 0 | Used Ring Update
-This interrupt is asserted when the Host has updated the Used
- Ring in at least one of the active virtual queues.
-
- Bit 1 | Configuration change
-This interrupt is asserted when configuration of the device has
- changed.
-
- 0x064 | W | InterruptACK
- Interrupt acknowledge.
- Writing to this register notifies the Host that the Guest
- finished handling interrupts. Set bits in the value clear the
- corresponding bits of the InterruptStatus register.
-
- 0x070 | RW | Status
- Device status.
- Reading from this register returns the current device status
- flags.
- Writing non-zero values to this register sets the status flags,
- indicating the Guest progress. Writing zero (0x0) to this
- register triggers a device reset.
- Also see [sub:Device-Initialization-Sequence]
-
- 0x100+ | RW | Config
- Device-specific configuration space starts at an offset 0x100
- and is accessed with byte alignment. Its meaning and size
- depends on the device and the driver.
-
-Virtual queue size is a number of elements in the queue,
-therefore size of the descriptor table and both available and
-used rings.
-
-The endianness of the registers follows the native endianness of
-the Guest. Writing to registers described as “R” and reading from
-registers described as “W” is not permitted and can cause
-undefined behavior.
-
-The device initialization is performed as described in [sub:Device-Initialization-Sequence]
- with one exception: the Guest must notify the Host about its
-page size, writing the size in bytes to GuestPageSize register
-before the initialization is finished.
-
-The memory mapped virtio devices generate single interrupt only,
-therefore no special configuration is required.
-
- Virtqueue Configuration
-
-The virtual queue configuration is performed in a similar way to
-the one described in [sec:Virtqueue-Configuration] with a few
-additional operations:
-
- Select the queue writing its index (first queue is 0) to the
- QueueSel register.
-
- Check if the queue is not already in use: read QueuePFN
- register, returned value should be zero (0x0).
-
- Read maximum queue size (number of elements) from the
- QueueNumMax register. If the returned value is zero (0x0) the
- queue is not available.
-
- Allocate and zero the queue pages in contiguous virtual memory,
- aligning the Used Ring to an optimal boundary (usually page
- size). Size of the allocated queue may be smaller than or equal
- to the maximum size returned by the Host.
-
- Notify the Host about the queue size by writing the size to
- QueueNum register.
-
- Notify the Host about the used alignment by writing its value
- in bytes to QueueAlign register.
-
- Write the physical number of the first page of the queue to the
- QueuePFN register.
-
-The queue and the device are ready to begin normal operations
-now.
-
- Device Operation
-
-The memory mapped virtio device behaves in the same way as
-described in [sec:Device-Operation], with the following
-exceptions:
-
- The device is notified about new buffers available in a queue
- by writing the queue index to register QueueNum instead of the
- virtio header in PCI I/O space ([sub:Notifying-The-Device]).
-
- The memory mapped virtio device is using single, dedicated
- interrupt signal, which is raised when at least one of the
- interrupts described in the InterruptStatus register
- description is asserted. After receiving an interrupt, the
- driver must read the InterruptStatus register to check what
- caused the interrupt (see the register description). After the
- interrupt is handled, the driver must acknowledge it by writing
- a bit mask corresponding to the serviced interrupt to the
- InterruptACK register.
-