Merge branch 'disintegrate-asm-generic' of git://git.infradead.org/users/dhowells/linux-headers into asm-generic

Patches from David Howells <dhowells@redhat.com>:

This is to complete part of the UAPI disintegration for which the
preparatory patches were pulled recently.

Note that there are some fixup patches which are at the base of the
branch aimed at you, plus all arches get the asm-generic branch merged in too.

* 'disintegrate-asm-generic' of git://git.infradead.org/users/dhowells/linux-headers:
  UAPI: (Scripted) Disintegrate include/asm-generic
  UAPI: Fix conditional header installation handling (notably kvm_para.h on m68k)
  c6x: remove c6x signal.h
  UAPI: Split compound conditionals containing __KERNEL__ in Arm64
  UAPI: Fix the guards on various asm/unistd.h files

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This commit is contained in:
Arnd Bergmann 2012-10-04 22:57:00 +02:00
commit c37d6154c0
6983 changed files with 378767 additions and 209522 deletions

View File

@ -12,11 +12,14 @@ Description:
then closing the file. The new policy takes effect after
the file ima/policy is closed.
IMA appraisal, if configured, uses these file measurements
for local measurement appraisal.
rule format: action [condition ...]
action: measure | dont_measure
action: measure | dont_measure | appraise | dont_appraise | audit
condition:= base | lsm
base: [[func=] [mask=] [fsmagic=] [uid=]]
base: [[func=] [mask=] [fsmagic=] [uid=] [fowner]]
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
@ -24,36 +27,50 @@ Description:
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
fsmagic:= hex value
uid:= decimal value
fowner:=decimal value
lsm: are LSM specific
default policy:
# PROC_SUPER_MAGIC
dont_measure fsmagic=0x9fa0
dont_appraise fsmagic=0x9fa0
# SYSFS_MAGIC
dont_measure fsmagic=0x62656572
dont_appraise fsmagic=0x62656572
# DEBUGFS_MAGIC
dont_measure fsmagic=0x64626720
dont_appraise fsmagic=0x64626720
# TMPFS_MAGIC
dont_measure fsmagic=0x01021994
dont_appraise fsmagic=0x01021994
# RAMFS_MAGIC
dont_measure fsmagic=0x858458f6
dont_appraise fsmagic=0x858458f6
# SECURITYFS_MAGIC
dont_measure fsmagic=0x73636673
dont_appraise fsmagic=0x73636673
measure func=BPRM_CHECK
measure func=FILE_MMAP mask=MAY_EXEC
measure func=FILE_CHECK mask=MAY_READ uid=0
appraise fowner=0
The default policy measures all executables in bprm_check,
all files mmapped executable in file_mmap, and all files
open for read by root in do_filp_open.
open for read by root in do_filp_open. The default appraisal
policy appraises all files owned by root.
Examples of LSM specific definitions:
SELinux:
# SELINUX_MAGIC
dont_measure fsmagic=0xF97CFF8C
dont_measure fsmagic=0xf97cff8c
dont_appraise fsmagic=0xf97cff8c
dont_measure obj_type=var_log_t
dont_appraise obj_type=var_log_t
dont_measure obj_type=auditd_log_t
dont_appraise obj_type=auditd_log_t
measure subj_user=system_u func=FILE_CHECK mask=MAY_READ
measure subj_role=system_r func=FILE_CHECK mask=MAY_READ

View File

@ -220,3 +220,10 @@ Description:
If the device doesn't support LTM, the file will read "no".
The file will be present for all speeds of USB devices, and will
always read "no" for USB 1.1 and USB 2.0 devices.
What: /sys/bus/usb/devices/.../(hub interface)/portX
Date: August 2012
Contact: Lan Tianyu <tianyu.lan@intel.com>
Description:
The /sys/bus/usb/devices/.../(hub interface)/portX
is usb port device's sysfs directory.

View File

@ -13,7 +13,7 @@ Description:
accessory cables have such capability. For example,
the 30-pin port of Nuri board (/arch/arm/mach-exynos)
may have both HDMI and Charger attached, or analog audio,
video, and USB cables attached simulteneously.
video, and USB cables attached simultaneously.
If there are cables mutually exclusive with each other,
such binary relations may be expressed with extcon_dev's
@ -35,7 +35,7 @@ Description:
The /sys/class/extcon/.../state shows and stores the cable
attach/detach information of the corresponding extcon object.
If the extcon object has an optional callback "show_state"
defined, the showing function is overriden with the optional
defined, the showing function is overridden with the optional
callback.
If the default callback for showing function is used, the
@ -46,19 +46,19 @@ Description:
TA=1
EAR_JACK=0
#
In this example, the extcon device have USB_OTG and TA
In this example, the extcon device has USB_OTG and TA
cables attached and HDMI and EAR_JACK cables detached.
In order to update the state of an extcon device, enter a hex
state number starting with 0x.
echo 0xHEX > state
state number starting with 0x:
# echo 0xHEX > state
This updates the whole state of the extcon dev.
This updates the whole state of the extcon device.
Inputs of all the methods are required to meet the
mutually_exclusive contidions if they exist.
mutually_exclusive conditions if they exist.
It is recommended to use this "global" state interface if
you need to enter the value atomically. The later state
you need to set the value atomically. The later state
interface associated with each cable cannot update
multiple cable states of an extcon device simultaneously.
@ -73,7 +73,7 @@ What: /sys/class/extcon/.../cable.x/state
Date: February 2012
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/extcon/.../cable.x/name shows and stores the
The /sys/class/extcon/.../cable.x/state shows and stores the
state of cable "x" (integer between 0 and 31) of an extcon
device. The state value is either 0 (detached) or 1
(attached).
@ -83,8 +83,8 @@ Date: December 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
Shows the relations of mutually exclusiveness. For example,
if the mutually_exclusive array of extcon_dev is
{0x3, 0x5, 0xC, 0x0}, the, the output is:
if the mutually_exclusive array of extcon device is
{0x3, 0x5, 0xC, 0x0}, then the output is:
# ls mutually_exclusive/
0x3
0x5

View File

@ -349,3 +349,24 @@ Description:
This will be one of the same strings reported by
the "state" attribute.
What: /sys/class/regulator/.../bypass
Date: September 2012
KernelVersion: 3.7
Contact: Mark Brown <broonie@opensource.wolfsonmicro.com>
Description:
Some regulator directories will contain a field called
bypass. This indicates if the device is in bypass mode.
This will be one of the following strings:
'enabled'
'disabled'
'unknown'
'enabled' means the regulator is in bypass mode.
'disabled' means that the regulator is regulating.
'unknown' means software cannot determine the state, or
the reported state is invalid.

View File

@ -176,3 +176,14 @@ Description: Disable L3 cache indices
All AMD processors with L3 caches provide this functionality.
For details, see BKDGs at
http://developer.amd.com/documentation/guides/Pages/default.aspx
What: /sys/devices/system/cpu/cpufreq/boost
Date: August 2012
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Processor frequency boosting control
This switch controls the boost setting for the whole system.
Boosting allows the CPU and the firmware to run at a frequency
beyound it's nominal limit.
More details can be found in Documentation/cpu-freq/boost.txt

View File

@ -0,0 +1,70 @@
What: /sys/devices/pnp0/<bus-num>/ppi/
Date: August 2012
Kernel Version: 3.6
Contact: xiaoyan.zhang@intel.com
Description:
This folder includes the attributes related with PPI (Physical
Presence Interface). Only if TPM is supported by BIOS, this
folder makes sence. The folder path can be got by command
'find /sys/ -name 'pcrs''. For the detail information of PPI,
please refer to the PPI specification from
http://www.trustedcomputinggroup.org/
What: /sys/devices/pnp0/<bus-num>/ppi/version
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
This attribute shows the version of the PPI supported by the
platform.
This file is readonly.
What: /sys/devices/pnp0/<bus-num>/ppi/request
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
This attribute shows the request for an operation to be
executed in the pre-OS environment. It is the only input from
the OS to the pre-OS environment. The request should be an
integer value range from 1 to 160, and 0 means no request.
This file can be read and written.
What: /sys/devices/pnp0/00:<bus-num>/ppi/response
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
This attribute shows the response to the most recent operation
request it acted upon. The format is "<request> <response num>
: <response description>".
This file is readonly.
What: /sys/devices/pnp0/<bus-num>/ppi/transition_action
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
This attribute shows the platform-specific action that should
take place in order to transition to the BIOS for execution of
a requested operation. The format is "<action num>: <action
description>".
This file is readonly.
What: /sys/devices/pnp0/<bus-num>/ppi/tcg_operations
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
This attribute shows whether it is allowed to request an
operation to be executed in the pre-OS environment by the BIOS
for the requests defined by TCG, i.e. requests from 1 to 22.
The format is "<request> <status num>: <status description>".
This attribute is only supported by PPI version 1.2+.
This file is readonly.
What: /sys/devices/pnp0/<bus-num>/ppi/vs_operations
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
This attribute shows whether it is allowed to request an
operation to be executed in the pre-OS environment by the BIOS
for the verdor specific requests, i.e. requests from 128 to
255. The format is same with tcg_operations. This attribute
is also only supported by PPI version 1.2+.
This file is readonly.

View File

@ -1,3 +1,16 @@
WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
Date: June 2012
Contact: linux-bluetooth@vger.kernel.org
Description:
The /sys/class/hidraw/hidraw*/device/oled*_img files control
OLED mocro displays on Intuos4 Wireless tablet. Accepted image
has to contain 256 bytes (64x32 px 1 bit colour). The format
is the same as PBM image 62x32px without header (64 bits per
horizontal line, 32 lines). An example of setting OLED No. 0:
dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
The attribute is read only and no local copy of the image is
stored.
What: /sys/class/hidraw/hidraw*/device/speed
Date: April 2010
Kernel Version: 2.6.35

View File

@ -19,7 +19,11 @@ Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file contains the name of the PTP hardware clock
as a human readable string.
as a human readable string. The purpose of this
attribute is to provide the user with a "friendly
name" and to help distinguish PHY based devices from
MAC based ones. The string does not necessarily have
to be any kind of unique id.
What: /sys/class/ptp/ptpN/max_adjustment
Date: September 2010

View File

@ -17,3 +17,12 @@ Description:
device, like 'tty1'.
The file supports poll() to detect virtual
console switches.
What: /sys/class/tty/ttyS0/uartclk
Date: Sep 2012
Contact: Tomas Hlavacek <tmshlvck@gmail.com>
Description:
Shows the current uartclk value associated with the
UART port in serial_core, that is bound to TTY like ttyS0.
uartclk = 16 * baud_base

File diff suppressed because it is too large Load Diff

View File

@ -310,6 +310,12 @@ over a rather long period of time, but improvements are always welcome!
code under the influence of preempt_disable(), you instead
need to use synchronize_irq() or synchronize_sched().
This same limitation also applies to synchronize_rcu_bh()
and synchronize_srcu(), as well as to the asynchronous and
expedited forms of the three primitives, namely call_rcu(),
call_rcu_bh(), call_srcu(), synchronize_rcu_expedited(),
synchronize_rcu_bh_expedited(), and synchronize_srcu_expedited().
12. Any lock acquired by an RCU callback must be acquired elsewhere
with softirq disabled, e.g., via spin_lock_irqsave(),
spin_lock_bh(), etc. Failing to disable irq on a given

View File

@ -99,7 +99,7 @@ In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
printed:
INFO: rcu_preempt detected stall on CPU
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer=-1
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
(t=65000 jiffies)
The "(64628 ticks this GP)" indicates that this CPU has taken more
@ -116,13 +116,13 @@ number between the two "/"s is the value of the nesting, which will
be a small positive number if in the idle loop and a very large positive
number (as shown above) otherwise.
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the
CPU is not in the process of trying to force itself into dyntick-idle
state, the "." indicates that the CPU has not given up forcing RCU
into dyntick-idle mode (it would be "H" otherwise), and the "timer=-1"
indicates that the CPU has not recented forced RCU into dyntick-idle
mode (it would otherwise indicate the number of microseconds remaining
in this forced state).
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
not in the process of trying to force itself into dyntick-idle state, the
"." indicates that the CPU has not given up forcing RCU into dyntick-idle
mode (it would be "H" otherwise), and the "timer not pending" indicates
that the CPU has not recently forced RCU into dyntick-idle mode (it
would otherwise indicate the number of microseconds remaining in this
forced state).
Multiple Warnings From One Stall

View File

@ -333,23 +333,23 @@ o Each element of the form "1/1 0:127 ^0" represents one struct
The output of "cat rcu/rcu_pending" looks as follows:
rcu_sched:
0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nf=6445 nn=146741
1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nf=5912 nn=155792
2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nf=1201 nn=136629
3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nf=207 nn=137723
4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nf=3529 nn=123110
5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nf=201 nn=137456
6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nf=4202 nn=120834
7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nf=41 nn=144888
0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nn=146741
1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nn=155792
2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nn=136629
3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nn=137723
4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nn=123110
5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nn=137456
6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nn=120834
7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nn=144888
rcu_bh:
0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nf=2 nn=145314
1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nf=3 nn=143180
2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nf=0 nn=117936
3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nf=0 nn=134863
4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nf=0 nn=110671
5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nf=0 nn=133235
6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nf=2 nn=110921
7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nf=0 nn=118542
0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nn=145314
1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nn=143180
2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nn=117936
3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nn=134863
4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nn=110671
5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nn=133235
6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nn=110921
7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nn=118542
As always, this is once again split into "rcu_sched" and "rcu_bh"
portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional
@ -377,17 +377,6 @@ o "gpc" is the number of times that an old grace period had
o "gps" is the number of times that a new grace period had started,
but this CPU was not yet aware of it.
o "nf" is the number of times that this CPU suspected that the
current grace period had run for too long, and thus needed to
be forced.
Please note that "forcing" consists of sending resched IPIs
to holdout CPUs. If that CPU really still is in an old RCU
read-side critical section, then we really do have to wait for it.
The assumption behing "forcing" is that the CPU is not still in
an old RCU read-side critical section, but has not yet responded
for some other reason.
o "nn" is the number of times that this CPU needed nothing. Alert
readers will note that the rcu "nn" number for a given CPU very
closely matches the rcu_bh "np" number for that same CPU. This

View File

@ -873,7 +873,7 @@ d. Do you need to treat NMI handlers, hardirq handlers,
and code segments with preemption disabled (whether
via preempt_disable(), local_irq_save(), local_bh_disable(),
or some other mechanism) as if they were explicit RCU readers?
If so, you need RCU-sched.
If so, RCU-sched is the only choice that will work for you.
e. Do you need RCU grace periods to complete even in the face
of softirq monopolization of one or more of the CPUs? For
@ -884,7 +884,12 @@ f. Is your workload too update-intensive for normal use of
RCU, but inappropriate for other synchronization mechanisms?
If so, consider SLAB_DESTROY_BY_RCU. But please be careful!
g. Otherwise, use RCU.
g. Do you need read-side critical sections that are respected
even though they are in the middle of the idle loop, during
user-mode execution, or on an offlined CPU? If so, SRCU is the
only choice that will work for you.
h. Otherwise, use RCU.
Of course, this all assumes that you have determined that RCU is in fact
the right tool for your job.

View File

@ -98,10 +98,9 @@ static int create_nl_socket(int protocol)
if (rcvbufsz)
if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF,
&rcvbufsz, sizeof(rcvbufsz)) < 0) {
fprintf(stderr, "Unable to set socket rcv buf size "
"to %d\n",
fprintf(stderr, "Unable to set socket rcv buf size to %d\n",
rcvbufsz);
return -1;
goto error;
}
memset(&local, 0, sizeof(local));

View File

@ -0,0 +1,232 @@
ARM Marvell SoCs
================
This document lists all the ARM Marvell SoCs that are currently
supported in mainline by the Linux kernel. As the Marvell families of
SoCs are large and complex, it is hard to understand where the support
for a particular SoC is available in the Linux kernel. This document
tries to help in understanding where those SoCs are supported, and to
match them with their corresponding public datasheet, when available.
Orion family
------------
Flavors:
88F5082
88F5181
88F5181L
88F5182
Datasheet : http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf
Programmer's User Guide : http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf
User Manual : http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf
88F5281
Datasheet : http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
88F6183
Core: Feroceon ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-orion5x
Linux kernel plat directory: arch/arm/plat-orion
Kirkwood family
---------------
Flavors:
88F6282 a.k.a Armada 300
Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
88F6283 a.k.a Armada 310
Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
88F6190
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
88F6192
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
88F6182
88F6180
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
88F6281
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
Homepage: http://www.marvell.com/embedded-processors/kirkwood/
Core: Feroceon ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-kirkwood
Linux kernel plat directory: arch/arm/plat-orion
Discovery family
----------------
Flavors:
MV78100
Product Brief : http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78100-003_WEB.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78100_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
MV78200
Product Brief : http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78200-002_WEB.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78200_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
MV76100
Not supported by the Linux kernel.
Core: Feroceon ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-mv78xx0
Linux kernel plat directory: arch/arm/plat-orion
EBU Armada family
-----------------
Armada 370 Flavors:
88F6710
88F6707
88F6W11
Armada XP Flavors:
MV78230
MV78260
MV78460
Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
No public datasheet available.
Core: Sheeva ARMv7 compatible
Linux kernel mach directory: arch/arm/mach-mvebu
Linux kernel plat directory: none
Avanta family
-------------
Flavors:
88F6510
88F6530P
88F6550
88F6560
Homepage : http://www.marvell.com/broadband/
Product Brief: http://www.marvell.com/broadband/assets/Marvell_Avanta_88F6510_305_060-001_product_brief.pdf
No public datasheet available.
Core: ARMv5 compatible
Linux kernel mach directory: no code in mainline yet, planned for the future
Linux kernel plat directory: no code in mainline yet, planned for the future
Dove family (application processor)
-----------------------------------
Flavors:
88AP510 a.k.a Armada 510
Product Brief : http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf
Hardware Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Hardware-Spec.pdf
Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
Homepage: http://www.marvell.com/application-processors/armada-500/
Core: ARMv7 compatible
Directory: arch/arm/mach-dove
PXA 2xx/3xx/93x/95x family
--------------------------
Flavors:
PXA21x, PXA25x, PXA26x
Application processor only
Core: ARMv5 XScale core
PXA270, PXA271, PXA272
Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
Developers manual : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_dev_man.pdf
Specification : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
Specification update : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
Application processor only
Core: ARMv5 XScale core
PXA300, PXA310, PXA320
PXA 300 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
PXA 310 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
PXA 320 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA320_PB_R4.pdf
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Design_Guide.pdf
Developers manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip
Specifications : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_EMTS.pdf
Specification Update : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
Reference Manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf
Application processor only
Core: ARMv5 XScale core
PXA930, PXA935
Application processor with Communication processor
Core: ARMv5 XScale core
PXA955
Application processor with Communication processor
Core: ARMv7 compatible Sheeva PJ4 core
Comments:
* This line of SoCs originates from the XScale family developed by
Intel and acquired by Marvell in ~2006. The PXA21x, PXA25x,
PXA26x, PXA27x, PXA3xx and PXA93x were developed by Intel, while
the later PXA95x were developed by Marvell.
* Due to their XScale origin, these SoCs have virtually nothing in
common with the other (Kirkwood, Dove, etc.) families of Marvell
SoCs, except with the MMP/MMP2 family of SoCs.
Linux kernel mach directory: arch/arm/mach-pxa
Linux kernel plat directory: arch/arm/plat-pxa
MMP/MMP2 family (communication processor)
-----------------------------------------
Flavors:
PXA168, a.k.a Armada 168
Homepage : http://www.marvell.com/application-processors/armada-100/armada-168.jsp
Product brief : http://www.marvell.com/application-processors/armada-100/assets/pxa_168_pb.pdf
Hardware manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_datasheet.pdf
Software manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_software_manual.pdf
Specification update : http://www.marvell.com/application-processors/armada-100/assets/ARMADA16x_Spec_update.pdf
Boot ROM manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
App node package : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf
Application processor only
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
PXA910
Homepage : http://www.marvell.com/communication-processors/pxa910/
Product Brief : http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf
Application processor with Communication processor
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
MMP2, a.k.a Armada 610
Product Brief : http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf
Application processor only
Core: ARMv7 compatible Sheeva PJ4 core
Comments:
* This line of SoCs originates from the XScale family developed by
Intel and acquired by Marvell in ~2006. All the processors of
this MMP/MMP2 family were developed by Marvell.
* Due to their XScale origin, these SoCs have virtually nothing in
common with the other (Kirkwood, Dove, etc.) families of Marvell
SoCs, except with the PXA family of SoCs listed above.
Linux kernel mach directory: arch/arm/mach-mmp
Linux kernel plat directory: arch/arm/plat-pxa
Long-term plans
---------------
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ and
mach-kirkwood/ into the mach-mvebu/ to support all SoCs from the
Marvell EBU (Engineering Business Unit) in a single mach-<foo>
directory. The plat-orion/ would therefore disappear.
* Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
directory. The plat-pxa/ would therefore disappear.
Credits
-------
Maen Suleiman <maen@marvell.com>
Lior Amsalem <alior@marvell.com>
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Andrew Lunn <andrew@lunn.ch>
Nicolas Pitre <nico@fluxnic.net>
Eric Miao <eric.y.miao@gmail.com>

View File

@ -1,4 +1,4 @@
S3C2410 GPIO Control
S3C24XX GPIO Control
====================
Introduction
@ -12,7 +12,7 @@ Introduction
of the s3c2410 GPIO system, please read the Samsung provided
data-sheet/users manual to find out the complete list.
See Documentation/arm/Samsung/GPIO.txt for the core implemetation.
See Documentation/arm/Samsung/GPIO.txt for the core implementation.
GPIOLIB
@ -41,8 +41,8 @@ GPIOLIB
GPIOLIB conversion
------------------
If you need to convert your board or driver to use gpiolib from the exiting
s3c2410 api, then here are some notes on the process.
If you need to convert your board or driver to use gpiolib from the phased
out s3c2410 API, then here are some notes on the process.
1) If your board is exclusively using an GPIO, say to control peripheral
power, then it will require to claim the gpio with gpio_request() before
@ -55,7 +55,7 @@ s3c2410 api, then here are some notes on the process.
as they have the same arguments, and can either take the pin specific
values, or the more generic special-function-number arguments.
3) s3c2410_gpio_pullup() changs have the problem that whilst the
3) s3c2410_gpio_pullup() changes have the problem that whilst the
s3c2410_gpio_pullup(x, 1) can be easily translated to the
s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
are not so easy.
@ -74,7 +74,7 @@ s3c2410 api, then here are some notes on the process.
when using gpio_get_value() on an output pin (s3c2410_gpio_getpin
would return the value the pin is supposed to be outputting).
6) s3c2410_gpio_getirq() should be directly replacable with the
6) s3c2410_gpio_getirq() should be directly replaceable with the
gpio_to_irq() call.
The s3c2410_gpio and gpio_ calls have always operated on the same gpio
@ -105,7 +105,7 @@ PIN Numbers
-----------
Each pin has an unique number associated with it in regs-gpio.h,
eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
e.g. S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
the GPIO functions which pin is to be used.
With the conversion to gpiolib, there is no longer a direct conversion
@ -120,31 +120,27 @@ Configuring a pin
The following function allows the configuration of a given pin to
be changed.
void s3c2410_gpio_cfgpin(unsigned int pin, unsigned int function);
void s3c_gpio_cfgpin(unsigned int pin, unsigned int function);
Eg:
e.g.:
s3c2410_gpio_cfgpin(S3C2410_GPA(0), S3C2410_GPA0_ADDR0);
s3c2410_gpio_cfgpin(S3C2410_GPE(8), S3C2410_GPE8_SDDAT1);
s3c_gpio_cfgpin(S3C2410_GPA(0), S3C_GPIO_SFN(1));
s3c_gpio_cfgpin(S3C2410_GPE(8), S3C_GPIO_SFN(2));
which would turn GPA(0) into the lowest Address line A0, and set
GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
The s3c_gpio_cfgpin() call is a functional replacement for this call.
Reading the current configuration
---------------------------------
The current configuration of a pin can be read by using:
The current configuration of a pin can be read by using standard
gpiolib function:
s3c2410_gpio_getcfg(unsigned int pin);
s3c_gpio_getcfg(unsigned int pin);
The return value will be from the same set of values which can be
passed to s3c2410_gpio_cfgpin().
The s3c_gpio_getcfg() call should be a functional replacement for
this call.
passed to s3c_gpio_cfgpin().
Configuring a pull-up resistor
@ -154,61 +150,33 @@ Configuring a pull-up resistor
pull-up resistors enabled. This can be configured by the following
function:
void s3c2410_gpio_pullup(unsigned int pin, unsigned int to);
void s3c_gpio_setpull(unsigned int pin, unsigned int to);
Where the to value is zero to set the pull-up off, and 1 to enable
the specified pull-up. Any other values are currently undefined.
The s3c_gpio_setpull() offers similar functionality, but with the
ability to encode whether the pull is up or down. Currently there
is no 'just on' state, so up or down must be selected.
Where the to value is S3C_GPIO_PULL_NONE to set the pull-up off,
and S3C_GPIO_PULL_UP to enable the specified pull-up. Any other
values are currently undefined.
Getting the state of a PIN
--------------------------
Getting and setting the state of a PIN
--------------------------------------
The state of a pin can be read by using the function:
unsigned int s3c2410_gpio_getpin(unsigned int pin);
This will return either zero or non-zero. Do not count on this
function returning 1 if the pin is set.
This call is now implemented by the relevant gpiolib calls, convert
your board or driver to use gpiolib.
Setting the state of a PIN
--------------------------
The value an pin is outputing can be modified by using the following:
void s3c2410_gpio_setpin(unsigned int pin, unsigned int to);
Which sets the given pin to the value. Use 0 to write 0, and 1 to
set the output to 1.
This call is now implemented by the relevant gpiolib calls, convert
These calls are now implemented by the relevant gpiolib calls, convert
your board or driver to use gpiolib.
Getting the IRQ number associated with a PIN
--------------------------------------------
The following function can map the given pin number to an IRQ
A standard gpiolib function can map the given pin number to an IRQ
number to pass to the IRQ system.
int s3c2410_gpio_getirq(unsigned int pin);
int gpio_to_irq(unsigned int pin);
Note, not all pins have an IRQ.
This call is now implemented by the relevant gpiolib calls, convert
your board or driver to use gpiolib.
Authour
Author
-------
Ben Dooks, 03 October 2004
Copyright 2004 Ben Dooks, Simtec Electronics

View File

@ -5,14 +5,14 @@ Introduction
------------
This outlines the Samsung GPIO implementation and the architecture
specific calls provided alongisde the drivers/gpio core.
specific calls provided alongside the drivers/gpio core.
S3C24XX (Legacy)
----------------
See Documentation/arm/Samsung-S3C24XX/GPIO.txt for more information
about these devices. Their implementation is being brought into line
about these devices. Their implementation has been brought into line
with the core samsung implementation described in this document.
@ -29,7 +29,7 @@ GPIO numbering is synchronised between the Samsung and gpiolib system.
PIN configuration
-----------------
Pin configuration is specific to the Samsung architecutre, with each SoC
Pin configuration is specific to the Samsung architecture, with each SoC
registering the necessary information for the core gpio configuration
implementation to configure pins as necessary.
@ -38,5 +38,3 @@ driver or machine to change gpio configuration.
See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information
on these functions.

View File

@ -51,6 +51,9 @@ ffc00000 ffefffff DMA memory mapping region. Memory returned
ff000000 ffbfffff Reserved for future expansion of DMA
mapping region.
fee00000 feffffff Mapping of PCI I/O space. This is a static
mapping within the vmalloc space.
VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space.
Memory returned by vmalloc/ioremap will
be dynamically placed in this region.

View File

@ -0,0 +1,152 @@
Booting AArch64 Linux
=====================
Author: Will Deacon <will.deacon@arm.com>
Date : 07 September 2012
This document is based on the ARM booting document by Russell King and
is relevant to all public releases of the AArch64 Linux kernel.
The AArch64 exception model is made up of a number of exception levels
(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure
counterpart. EL2 is the hypervisor level and exists only in non-secure
mode. EL3 is the highest priority level and exists only in secure mode.
For the purposes of this document, we will use the term `boot loader'
simply to define all software that executes on the CPU(s) before control
is passed to the Linux kernel. This may include secure monitor and
hypervisor code, or it may just be a handful of instructions for
preparing a minimal boot environment.
Essentially, the boot loader should provide (as a minimum) the
following:
1. Setup and initialise the RAM
2. Setup the device tree
3. Decompress the kernel image
4. Call the kernel image
1. Setup and initialise RAM
---------------------------
Requirement: MANDATORY
The boot loader is expected to find and initialise all RAM that the
kernel will use for volatile data storage in the system. It performs
this in a machine dependent manner. (It may use internal algorithms
to automatically locate and size all RAM, or it may use knowledge of
the RAM in the machine, or any other method the boot loader designer
sees fit.)
2. Setup the device tree
-------------------------
Requirement: MANDATORY
The device tree blob (dtb) must be no bigger than 2 megabytes in size
and placed at a 2-megabyte boundary within the first 512 megabytes from
the start of the kernel image. This is to allow the kernel to map the
blob using a single section mapping in the initial page tables.
3. Decompress the kernel image
------------------------------
Requirement: OPTIONAL
The AArch64 kernel does not currently provide a decompressor and
therefore requires decompression (gzip etc.) to be performed by the boot
loader if a compressed Image target (e.g. Image.gz) is used. For
bootloaders that do not implement this requirement, the uncompressed
Image target is available instead.
4. Call the kernel image
------------------------
Requirement: MANDATORY
The decompressed kernel image contains a 32-byte header as follows:
u32 magic = 0x14000008; /* branch to stext, little-endian */
u32 res0 = 0; /* reserved */
u64 text_offset; /* Image load offset */
u64 res1 = 0; /* reserved */
u64 res2 = 0; /* reserved */
The image must be placed at the specified offset (currently 0x80000)
from the start of the system RAM and called there. The start of the
system RAM must be aligned to 2MB.
Before jumping into the kernel, the following conditions must be met:
- Quiesce all DMA capable devices so that memory does not get
corrupted by bogus network packets or disk data. This will save
you many hours of debug.
- Primary CPU general-purpose register settings
x0 = physical address of device tree blob (dtb) in system RAM.
x1 = 0 (reserved for future use)
x2 = 0 (reserved for future use)
x3 = 0 (reserved for future use)
- CPU mode
All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
IRQ and FIQ).
The CPU must be in either EL2 (RECOMMENDED in order to have access to
the virtualisation extensions) or non-secure EL1.
- Caches, MMUs
The MMU must be off.
Instruction cache may be on or off.
Data cache must be off and invalidated.
External caches (if present) must be configured and disabled.
- Architected timers
CNTFRQ must be programmed with the timer frequency.
If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0)
set where available.
- Coherency
All CPUs to be booted by the kernel must be part of the same coherency
domain on entry to the kernel. This may require IMPLEMENTATION DEFINED
initialisation to enable the receiving of maintenance operations on
each CPU.
- System registers
All writable architected system registers at the exception level where
the kernel image will be entered must be initialised by software at a
higher exception level to prevent execution in an UNKNOWN state.
The boot loader is expected to enter the kernel on each CPU in the
following manner:
- The primary CPU must jump directly to the first instruction of the
kernel image. The device tree blob passed by this CPU must contain
for each CPU node:
1. An 'enable-method' property. Currently, the only supported value
for this field is the string "spin-table".
2. A 'cpu-release-addr' property identifying a 64-bit,
zero-initialised memory location.
It is expected that the bootloader will generate these device tree
properties and insert them into the blob prior to kernel entry.
- Any secondary CPUs must spin outside of the kernel in a reserved area
of memory (communicated to the kernel by a /memreserve/ region in the
device tree) polling their cpu-release-addr location, which must be
contained in the reserved region. A wfe instruction may be inserted
to reduce the overhead of the busy-loop and a sev will be issued by
the primary CPU. When a read of the location pointed to by the
cpu-release-addr returns a non-zero value, the CPU must jump directly
to this value.
- Secondary CPU general-purpose register settings
x0 = 0 (reserved for future use)
x1 = 0 (reserved for future use)
x2 = 0 (reserved for future use)
x3 = 0 (reserved for future use)

View File

@ -0,0 +1,73 @@
Memory Layout on AArch64 Linux
==============================
Author: Catalin Marinas <catalin.marinas@arm.com>
Date : 20 February 2012
This document describes the virtual memory layout used by the AArch64
Linux kernel. The architecture allows up to 4 levels of translation
tables with a 4KB page size and up to 3 levels with a 64KB page size.
AArch64 Linux uses 3 levels of translation tables with the 4KB page
configuration, allowing 39-bit (512GB) virtual addresses for both user
and kernel. With 64KB pages, only 2 levels of translation tables are
used but the memory layout is the same.
User addresses have bits 63:39 set to 0 while the kernel addresses have
the same bits set to 1. TTBRx selection is given by bit 63 of the
virtual address. The swapper_pg_dir contains only kernel (global)
mappings while the user pgd contains only user (non-global) mappings.
The swapper_pgd_dir address is written to TTBR1 and never written to
TTBR0.
AArch64 Linux memory layout:
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000007fffffffff 512GB user
ffffff8000000000 ffffffbbfffcffff ~240GB vmalloc
ffffffbbfffd0000 ffffffbcfffdffff 64KB [guard page]
ffffffbbfffe0000 ffffffbcfffeffff 64KB PCI I/O space
ffffffbbffff0000 ffffffbcffffffff 64KB [guard page]
ffffffbc00000000 ffffffbdffffffff 8GB vmemmap
ffffffbe00000000 ffffffbffbffffff ~8GB [guard, future vmmemap]
ffffffbffc000000 ffffffbfffffffff 64MB modules
ffffffc000000000 ffffffffffffffff 256GB memory
Translation table lookup with 4KB pages:
+--------+--------+--------+--------+--------+--------+--------+--------+
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
+--------+--------+--------+--------+--------+--------+--------+--------+
| | | | | |
| | | | | v
| | | | | [11:0] in-page offset
| | | | +-> [20:12] L3 index
| | | +-----------> [29:21] L2 index
| | +---------------------> [38:30] L1 index
| +-------------------------------> [47:39] L0 index (not used)
+-------------------------------------------------> [63] TTBR0/1
Translation table lookup with 64KB pages:
+--------+--------+--------+--------+--------+--------+--------+--------+
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
+--------+--------+--------+--------+--------+--------+--------+--------+
| | | | |
| | | | v
| | | | [15:0] in-page offset
| | | +----------> [28:16] L3 index
| | +--------------------------> [41:29] L2 index (only 38:29 used)
| +-------------------------------> [47:42] L1 index (not used)
+-------------------------------------------------> [63] TTBR0/1

View File

@ -29,7 +29,8 @@ CONTENTS:
3.1 Overview
3.2 Synchronization
3.3 Subsystem API
4. Questions
4. Extended attributes usage
5. Questions
1. Control Groups
=================
@ -62,9 +63,9 @@ an instance of the cgroup virtual filesystem associated with it.
At any one time there may be multiple active hierarchies of task
cgroups. Each hierarchy is a partition of all tasks in the system.
User level code may create and destroy cgroups by name in an
User-level code may create and destroy cgroups by name in an
instance of the cgroup virtual file system, specify and query to
which cgroup a task is assigned, and list the task pids assigned to
which cgroup a task is assigned, and list the task PIDs assigned to
a cgroup. Those creations and assignments only affect the hierarchy
associated with that instance of the cgroup file system.
@ -72,7 +73,7 @@ On their own, the only use for cgroups is for simple job
tracking. The intention is that other subsystems hook into the generic
cgroup support to provide new attributes for cgroups, such as
accounting/limiting the resources which processes in a cgroup can
access. For example, cpusets (see Documentation/cgroups/cpusets.txt) allows
access. For example, cpusets (see Documentation/cgroups/cpusets.txt) allow
you to associate a set of CPUs and a set of memory nodes with the
tasks in each cgroup.
@ -80,11 +81,11 @@ tasks in each cgroup.
----------------------------
There are multiple efforts to provide process aggregations in the
Linux kernel, mainly for resource tracking purposes. Such efforts
Linux kernel, mainly for resource-tracking purposes. Such efforts
include cpusets, CKRM/ResGroups, UserBeanCounters, and virtual server
namespaces. These all require the basic notion of a
grouping/partitioning of processes, with newly forked processes ending
in the same group (cgroup) as their parent process.
up in the same group (cgroup) as their parent process.
The kernel cgroup patch provides the minimum essential kernel
mechanisms required to efficiently implement such groups. It has
@ -127,14 +128,14 @@ following lines:
/ \
Professors (15%) students (5%)
Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go
into NFS network class.
Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd goes
into the NFS network class.
At the same time Firefox/Lynx will share an appropriate CPU/Memory class
depending on who launched it (prof/student).
With the ability to classify tasks differently for different resources
(by putting those resource subsystems in different hierarchies) then
(by putting those resource subsystems in different hierarchies),
the admin can easily set up a script which receives exec notifications
and depending on who is launching the browser he can
@ -145,19 +146,19 @@ a separate cgroup for every browser launched and associate it with
appropriate network and other resource class. This may lead to
proliferation of such cgroups.
Also lets say that the administrator would like to give enhanced network
Also let's say that the administrator would like to give enhanced network
access temporarily to a student's browser (since it is night and the user
wants to do online gaming :)) OR give one of the students simulation
apps enhanced CPU power,
wants to do online gaming :)) OR give one of the student's simulation
apps enhanced CPU power.
With ability to write pids directly to resource classes, it's just a
matter of :
With ability to write PIDs directly to resource classes, it's just a
matter of:
# echo pid > /sys/fs/cgroup/network/<new_class>/tasks
(after some time)
# echo pid > /sys/fs/cgroup/network/<orig_class>/tasks
Without this ability, he would have to split the cgroup into
Without this ability, the administrator would have to split the cgroup into
multiple separate ones and then associate the new cgroups with the
new resource classes.
@ -184,20 +185,20 @@ Control Groups extends the kernel as follows:
field of each task_struct using the css_set, anchored at
css_set->tasks.
- A cgroup hierarchy filesystem can be mounted for browsing and
- A cgroup hierarchy filesystem can be mounted for browsing and
manipulation from user space.
- You can list all the tasks (by pid) attached to any cgroup.
- You can list all the tasks (by PID) attached to any cgroup.
The implementation of cgroups requires a few, simple hooks
into the rest of the kernel, none in performance critical paths:
into the rest of the kernel, none in performance-critical paths:
- in init/main.c, to initialize the root cgroups and initial
css_set at system boot.
- in fork and exit, to attach and detach a task from its css_set.
In addition a new file system, of type "cgroup" may be mounted, to
In addition, a new file system of type "cgroup" may be mounted, to
enable browsing and modifying the cgroups presently known to the
kernel. When mounting a cgroup hierarchy, you may specify a
comma-separated list of subsystems to mount as the filesystem mount
@ -230,13 +231,13 @@ as the path relative to the root of the cgroup file system.
Each cgroup is represented by a directory in the cgroup file system
containing the following files describing that cgroup:
- tasks: list of tasks (by pid) attached to that cgroup. This list
is not guaranteed to be sorted. Writing a thread id into this file
- tasks: list of tasks (by PID) attached to that cgroup. This list
is not guaranteed to be sorted. Writing a thread ID into this file
moves the thread into this cgroup.
- cgroup.procs: list of tgids in the cgroup. This list is not
guaranteed to be sorted or free of duplicate tgids, and userspace
- cgroup.procs: list of thread group IDs in the cgroup. This list is
not guaranteed to be sorted or free of duplicate TGIDs, and userspace
should sort/uniquify the list if this property is required.
Writing a thread group id into this file moves all threads in that
Writing a thread group ID into this file moves all threads in that
group into this cgroup.
- notify_on_release flag: run the release agent on exit?
- release_agent: the path to use for release notifications (this file
@ -261,7 +262,7 @@ cgroup file system directories.
When a task is moved from one cgroup to another, it gets a new
css_set pointer - if there's an already existing css_set with the
desired collection of cgroups then that group is reused, else a new
desired collection of cgroups then that group is reused, otherwise a new
css_set is allocated. The appropriate existing css_set is located by
looking into a hash table.
@ -292,7 +293,7 @@ file system) of the abandoned cgroup. This enables automatic
removal of abandoned cgroups. The default value of
notify_on_release in the root cgroup at system boot is disabled
(0). The default value of other cgroups at creation is the current
value of their parents notify_on_release setting. The default value of
value of their parents' notify_on_release settings. The default value of
a cgroup hierarchy's release_agent path is empty.
1.5 What does clone_children do ?
@ -316,7 +317,7 @@ the "cpuset" cgroup subsystem, the steps are something like:
4) Create the new cgroup by doing mkdir's and write's (or echo's) in
the /sys/fs/cgroup virtual file system.
5) Start a task that will be the "founding father" of the new job.
6) Attach that task to the new cgroup by writing its pid to the
6) Attach that task to the new cgroup by writing its PID to the
/sys/fs/cgroup/cpuset/tasks file for that cgroup.
7) fork, exec or clone the job tasks from this founding father task.
@ -344,7 +345,7 @@ and then start a subshell 'sh' in that cgroup:
2.1 Basic Usage
---------------
Creating, modifying, using the cgroups can be done through the cgroup
Creating, modifying, using cgroups can be done through the cgroup
virtual filesystem.
To mount a cgroup hierarchy with all available subsystems, type:
@ -441,7 +442,7 @@ You can attach the current shell task by echoing 0:
# echo 0 > tasks
You can use the cgroup.procs file instead of the tasks file to move all
threads in a threadgroup at once. Echoing the pid of any task in a
threads in a threadgroup at once. Echoing the PID of any task in a
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
in the writing task's threadgroup.
@ -479,7 +480,7 @@ in /proc/mounts and /proc/<pid>/cgroups.
There is mechanism which allows to get notifications about changing
status of a cgroup.
To register new notification handler you need:
To register a new notification handler you need to:
- create a file descriptor for event notification using eventfd(2);
- open a control file to be monitored (e.g. memory.usage_in_bytes);
- write "<event_fd> <control_fd> <args>" to cgroup.event_control.
@ -488,7 +489,7 @@ To register new notification handler you need:
eventfd will be woken up by control file implementation or when the
cgroup is removed.
To unregister notification handler just close eventfd.
To unregister a notification handler just close eventfd.
NOTE: Support of notifications should be implemented for the control
file. See documentation for the subsystem.
@ -502,7 +503,7 @@ file. See documentation for the subsystem.
Each kernel subsystem that wants to hook into the generic cgroup
system needs to create a cgroup_subsys object. This contains
various methods, which are callbacks from the cgroup system, along
with a subsystem id which will be assigned by the cgroup system.
with a subsystem ID which will be assigned by the cgroup system.
Other fields in the cgroup_subsys object include:
@ -516,7 +517,7 @@ Other fields in the cgroup_subsys object include:
at system boot.
Each cgroup object created by the system has an array of pointers,
indexed by subsystem id; this pointer is entirely managed by the
indexed by subsystem ID; this pointer is entirely managed by the
subsystem; the generic cgroup code will never touch this pointer.
3.2 Synchronization
@ -639,7 +640,7 @@ void post_clone(struct cgroup *cgrp)
Called during cgroup_create() to do any parameter
initialization which might be required before a task could attach. For
example in cpusets, no task may attach before 'cpus' and 'mems' are set
example, in cpusets, no task may attach before 'cpus' and 'mems' are set
up.
void bind(struct cgroup *root)
@ -650,7 +651,26 @@ and root cgroup. Currently this will only involve movement between
the default hierarchy (which never has sub-cgroups) and a hierarchy
that is being created/destroyed (and hence has no sub-cgroups).
4. Questions
4. Extended attribute usage
===========================
cgroup filesystem supports certain types of extended attributes in its
directories and files. The current supported types are:
- Trusted (XATTR_TRUSTED)
- Security (XATTR_SECURITY)
Both require CAP_SYS_ADMIN capability to set.
Like in tmpfs, the extended attributes in cgroup filesystem are stored
using kernel memory and it's advised to keep the usage at minimum. This
is the reason why user defined extended attributes are not supported, since
any user can do it and there's no limit in the value size.
The current known users for this feature are SELinux to limit cgroup usage
in containers and systemd for assorted meta data like main PID in a cgroup
(systemd creates a cgroup per service).
5. Questions
============
Q: what's up with this '/bin/echo' ?
@ -660,5 +680,5 @@ A: bash's builtin 'echo' command does not check calls to write() against
Q: When I attach processes, only the first of the line gets really attached !
A: We can only return one error code per call to write(). So you should also
put only ONE pid.
put only ONE PID.

View File

@ -0,0 +1,93 @@
Processor boosting control
- information for users -
Quick guide for the impatient:
--------------------
/sys/devices/system/cpu/cpufreq/boost
controls the boost setting for the whole system. You can read and write
that file with either "0" (boosting disabled) or "1" (boosting allowed).
Reading or writing 1 does not mean that the system is boosting at this
very moment, but only that the CPU _may_ raise the frequency at it's
discretion.
--------------------
Introduction
-------------
Some CPUs support a functionality to raise the operating frequency of
some cores in a multi-core package if certain conditions apply, mostly
if the whole chip is not fully utilized and below it's intended thermal
budget. This is done without operating system control by a combination
of hardware and firmware.
On Intel CPUs this is called "Turbo Boost", AMD calls it "Turbo-Core",
in technical documentation "Core performance boost". In Linux we use
the term "boost" for convenience.
Rationale for disable switch
----------------------------
Though the idea is to just give better performance without any user
intervention, sometimes the need arises to disable this functionality.
Most systems offer a switch in the (BIOS) firmware to disable the
functionality at all, but a more fine-grained and dynamic control would
be desirable:
1. While running benchmarks, reproducible results are important. Since
the boosting functionality depends on the load of the whole package,
single thread performance can vary. By explicitly disabling the boost
functionality at least for the benchmark's run-time the system will run
at a fixed frequency and results are reproducible again.
2. To examine the impact of the boosting functionality it is helpful
to do tests with and without boosting.
3. Boosting means overclocking the processor, though under controlled
conditions. By raising the frequency and the voltage the processor
will consume more power than without the boosting, which may be
undesirable for instance for mobile users. Disabling boosting may
save power here, though this depends on the workload.
User controlled switch
----------------------
To allow the user to toggle the boosting functionality, the acpi-cpufreq
driver exports a sysfs knob to disable it. There is a file:
/sys/devices/system/cpu/cpufreq/boost
which can either read "0" (boosting disabled) or "1" (boosting enabled).
Reading the file is always supported, even if the processor does not
support boosting. In this case the file will be read-only and always
reads as "0". Explicitly changing the permissions and writing to that
file anyway will return EINVAL.
On supported CPUs one can write either a "0" or a "1" into this file.
This will either disable the boost functionality on all cores in the
whole system (0) or will allow the hardware to boost at will (1).
Writing a "1" does not explicitly boost the system, but just allows the
CPU (and the firmware) to boost at their discretion. Some implementations
take external factors like the chip's temperature into account, so
boosting once does not necessarily mean that it will occur every time
even using the exact same software setup.
AMD legacy cpb switch
---------------------
The AMD powernow-k8 driver used to support a very similar switch to
disable or enable the "Core Performance Boost" feature of some AMD CPUs.
This switch was instantiated in each CPU's cpufreq directory
(/sys/devices/system/cpu[0-9]*/cpufreq) and was called "cpb".
Though the per CPU existence hints at a more fine grained control, the
actual implementation only supported a system-global switch semantics,
which was simply reflected into each CPU's file. Writing a 0 or 1 into it
would pull the other CPUs to the same state.
For compatibility reasons this file and its behavior is still supported
on AMD CPUs, though it is now protected by a config switch
(X86_ACPI_CPUFREQ_CPB). On Intel CPUs this file will never be created,
even with the config option set.
This functionality is considered legacy and will be removed in some future
kernel version.
More fine grained boosting control
----------------------------------
Technically it is possible to switch the boosting functionality at least
on a per package basis, for some CPUs even per core. Currently the driver
does not support it, but this may be implemented in the future.

View File

@ -76,9 +76,17 @@ total 0
* desc : Small description about the idle state (string)
* disable : Option to disable this idle state (bool)
* disable : Option to disable this idle state (bool) -> see note below
* latency : Latency to exit out of this idle state (in microseconds)
* name : Name of the idle state (string)
* power : Power consumed while in this idle state (in milliwatts)
* time : Total time spent in this idle state (in microseconds)
* usage : Number of times this state was entered (count)
Note:
The behavior and the effect of the disable variable depends on the
implementation of a particular governor. In the ladder governor, for
example, it is not coherent, i.e. if one is disabling a light state,
then all deeper states are disabled as well, but the disable variable
does not reflect it. Likewise, if one enables a deep state but a lighter
state still is disabled, then this has no effect.

View File

@ -0,0 +1,8 @@
Broadcom BCM2835 device tree bindings
-------------------------------------------
Boards with the BCM2835 SoC shall have the following properties:
Required root node property:
compatible = "brcm,bcm2835";

View File

@ -0,0 +1,17 @@
Calxeda Highbank Combination Phys for SATA
Properties:
- compatible : Should be "calxeda,hb-combophy"
- #phy-cells: Should be 1.
- reg : Address and size for Combination Phy registers.
- phydev: device ID for programming the combophy.
Example:
combophy5: combo-phy@fff5d000 {
compatible = "calxeda,hb-combophy";
#phy-cells = <1>;
reg = <0xfff5d000 0x1000>;
phydev = <31>;
};

View File

@ -0,0 +1,17 @@
* Marvell Tauros2 Cache
Required properties:
- compatible : Should be "marvell,tauros2-cache".
- marvell,tauros2-cache-features : Specify the features supported for the
tauros2 cache.
The features including
CACHE_TAUROS2_PREFETCH_ON (1 << 0)
CACHE_TAUROS2_LINEFILL_BURST8 (1 << 1)
The definition can be found at
arch/arm/include/asm/hardware/cache-tauros2.h
Example:
L2: l2-cache {
compatible = "marvell,tauros2-cache";
marvell,tauros2-cache-features = <0x3>;
};

View File

@ -0,0 +1,38 @@
* MSM Timer
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.
- interrupts : Interrupt indicating a match event.
- reg : Specifies the base address of the timer registers. The second region
specifies an optional register used to configure the clock divider.
- clock-frequency : The frequency of the timer in Hz.
Optional:
- cpu-offset : per-cpu offset used when the timer is accessed without the
CPU remapping facilities. The offset is cpu-offset * 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>;
cpu-offset = <0x40000>;
};

View File

@ -36,6 +36,9 @@ Boards:
- OMAP3 BeagleBoard : Low cost community board
compatible = "ti,omap3-beagle", "ti,omap3"
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
- OMAP4 SDP : Software Developement Board
compatible = "ti,omap4-sdp", "ti,omap4430"

View File

@ -7,8 +7,12 @@ representation in the device tree should be done as under:-
Required properties:
- compatible : should be one of
"arm,cortex-a15-pmu"
"arm,cortex-a9-pmu"
"arm,cortex-a8-pmu"
"arm,cortex-a7-pmu"
"arm,cortex-a5-pmu"
"arm,arm11mpcore-pmu"
"arm,arm1176-pmu"
"arm,arm1136-pmu"
- interrupts : 1 combined interrupt or 1 per core.

View File

@ -0,0 +1,14 @@
VIA/Wondermedia VT8500 Platforms Device Tree Bindings
---------------------------------------
Boards with the VIA VT8500 SoC shall have the following properties:
Required root node property:
compatible = "via,vt8500";
Boards with the Wondermedia WM8505 SoC shall have the following properties:
Required root node property:
compatible = "wm,wm8505";
Boards with the Wondermedia WM8650 SoC shall have the following properties:
Required root node property:
compatible = "wm,wm8650";

View File

@ -0,0 +1,16 @@
VIA/Wondermedia VT8500 Interrupt Controller
-----------------------------------------------------
Required properties:
- compatible : "via,vt8500-intc"
- reg : Should contain 1 register ranges(address and length)
- #interrupt-cells : should be <1>
Example:
intc: interrupt-controller@d8140000 {
compatible = "via,vt8500-intc";
interrupt-controller;
reg = <0xd8140000 0x10000>;
#interrupt-cells = <1>;
};

View File

@ -0,0 +1,13 @@
VIA/Wondermedia VT8500 Power Management Controller
-----------------------------------------------------
Required properties:
- compatible : "via,vt8500-pmc"
- reg : Should contain 1 register ranges(address and length)
Example:
pmc@d8130000 {
compatible = "via,vt8500-pmc";
reg = <0xd8130000 0x1000>;
};

View File

@ -0,0 +1,15 @@
VIA/Wondermedia VT8500 Timer
-----------------------------------------------------
Required properties:
- compatible : "via,vt8500-timer"
- reg : Should contain 1 register ranges(address and length)
- interrupts : interrupt for the timer
Example:
timer@d8130100 {
compatible = "via,vt8500-timer";
reg = <0xd8130100 0x28>;
interrupts = <36>;
};

View File

@ -8,9 +8,18 @@ Required properties:
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>
Optional properties:
- calxeda,port-phys: phandle-combophy and lane assignment, which maps each
SATA port to a combophy and a lane within that
combophy
- dma-coherent : Present if dma operations are coherent
Example:
sata@ffe08000 {
compatible = "calxeda,hb-ahci";
reg = <0xffe08000 0x1000>;
interrupts = <115>;
calxeda,port-phys = <&combophy5 0 &combophy0 0 &combophy0 1
&combophy0 2 &combophy0 3>;
};

View File

@ -0,0 +1,17 @@
* ARASAN PATA COMPACT FLASH CONTROLLER
Required properties:
- compatible: "arasan,cf-spear1340"
- reg: Address range of the CF registers
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupt: Should contain the CF interrupt number
Example:
cf@fc000000 {
compatible = "arasan,cf-spear1340";
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
};

View File

@ -0,0 +1,10 @@
* OMAP OCP2SCP - ocp interface to scp interface
properties:
- compatible : Should be "ti,omap-ocp2scp"
- #address-cells, #size-cells : Must be present if the device has sub-nodes
- ranges : the child address space are mapped 1:1 onto the parent address space
- ti,hwmods : must be "ocp2scp_usb_phy"
Sub-nodes:
All the devices connected to ocp2scp are described using sub-node to ocp2scp

View File

@ -0,0 +1,76 @@
* Clock bindings for Freescale i.MX23
Required properties:
- compatible: Should be "fsl,imx23-clkctrl"
- reg: Address and length of the register set
- #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.MX23
clocks and IDs.
Clock ID
------------------
ref_xtal 0
pll 1
ref_cpu 2
ref_emi 3
ref_pix 4
ref_io 5
saif_sel 6
lcdif_sel 7
gpmi_sel 8
ssp_sel 9
emi_sel 10
cpu 11
etm_sel 12
cpu_pll 13
cpu_xtal 14
hbus 15
xbus 16
lcdif_div 17
ssp_div 18
gpmi_div 19
emi_pll 20
emi_xtal 21
etm_div 22
saif_div 23
clk32k_div 24
rtc 25
adc 26
spdif_div 27
clk32k 28
dri 29
pwm 30
filt 31
uart 32
ssp 33
gpmi 34
spdif 35
emi 36
saif 37
lcdif 38
etm 39
usb 40
usb_pwr 41
Examples:
clks: clkctrl@80040000 {
compatible = "fsl,imx23-clkctrl";
reg = <0x80040000 0x2000>;
#clock-cells = <1>;
clock-output-names =
...
"uart", /* 32 */
...
"end_of_list";
};
auart0: serial@8006c000 {
compatible = "fsl,imx23-auart";
reg = <0x8006c000 0x2000>;
interrupts = <24 25 23>;
clocks = <&clks 32>;
status = "disabled";
};

View File

@ -0,0 +1,99 @@
* Clock bindings for Freescale i.MX28
Required properties:
- compatible: Should be "fsl,imx28-clkctrl"
- reg: Address and length of the register set
- #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.MX28
clocks and IDs.
Clock ID
------------------
ref_xtal 0
pll0 1
pll1 2
pll2 3
ref_cpu 4
ref_emi 5
ref_io0 6
ref_io1 7
ref_pix 8
ref_hsadc 9
ref_gpmi 10
saif0_sel 11
saif1_sel 12
gpmi_sel 13
ssp0_sel 14
ssp1_sel 15
ssp2_sel 16
ssp3_sel 17
emi_sel 18
etm_sel 19
lcdif_sel 20
cpu 21
ptp_sel 22
cpu_pll 23
cpu_xtal 24
hbus 25
xbus 26
ssp0_div 27
ssp1_div 28
ssp2_div 29
ssp3_div 30
gpmi_div 31
emi_pll 32
emi_xtal 33
lcdif_div 34
etm_div 35
ptp 36
saif0_div 37
saif1_div 38
clk32k_div 39
rtc 40
lradc 41
spdif_div 42
clk32k 43
pwm 44
uart 45
ssp0 46
ssp1 47
ssp2 48
ssp3 49
gpmi 50
spdif 51
emi 52
saif0 53
saif1 54
lcdif 55
etm 56
fec 57
can0 58
can1 59
usb0 60
usb1 61
usb0_pwr 62
usb1_pwr 63
enet_out 64
Examples:
clks: clkctrl@80040000 {
compatible = "fsl,imx28-clkctrl";
reg = <0x80040000 0x2000>;
#clock-cells = <1>;
clock-output-names =
...
"uart", /* 45 */
...
"end_of_list";
};
auart0: serial@8006a000 {
compatible = "fsl,imx28-auart", "fsl,imx23-auart";
reg = <0x8006a000 0x2000>;
interrupts = <112 70 71>;
clocks = <&clks 45>;
status = "disabled";
};

View File

@ -0,0 +1,222 @@
* Clock bindings for Freescale i.MX6 Quad
Required properties:
- compatible: Should be "fsl,imx6q-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.MX6Q
clocks and IDs.
Clock ID
---------------------------
dummy 0
ckil 1
ckih 2
osc 3
pll2_pfd0_352m 4
pll2_pfd1_594m 5
pll2_pfd2_396m 6
pll3_pfd0_720m 7
pll3_pfd1_540m 8
pll3_pfd2_508m 9
pll3_pfd3_454m 10
pll2_198m 11
pll3_120m 12
pll3_80m 13
pll3_60m 14
twd 15
step 16
pll1_sw 17
periph_pre 18
periph2_pre 19
periph_clk2_sel 20
periph2_clk2_sel 21
axi_sel 22
esai_sel 23
asrc_sel 24
spdif_sel 25
gpu2d_axi 26
gpu3d_axi 27
gpu2d_core_sel 28
gpu3d_core_sel 29
gpu3d_shader_sel 30
ipu1_sel 31
ipu2_sel 32
ldb_di0_sel 33
ldb_di1_sel 34
ipu1_di0_pre_sel 35
ipu1_di1_pre_sel 36
ipu2_di0_pre_sel 37
ipu2_di1_pre_sel 38
ipu1_di0_sel 39
ipu1_di1_sel 40
ipu2_di0_sel 41
ipu2_di1_sel 42
hsi_tx_sel 43
pcie_axi_sel 44
ssi1_sel 45
ssi2_sel 46
ssi3_sel 47
usdhc1_sel 48
usdhc2_sel 49
usdhc3_sel 50
usdhc4_sel 51
enfc_sel 52
emi_sel 53
emi_slow_sel 54
vdo_axi_sel 55
vpu_axi_sel 56
cko1_sel 57
periph 58
periph2 59
periph_clk2 60
periph2_clk2 61
ipg 62
ipg_per 63
esai_pred 64
esai_podf 65
asrc_pred 66
asrc_podf 67
spdif_pred 68
spdif_podf 69
can_root 70
ecspi_root 71
gpu2d_core_podf 72
gpu3d_core_podf 73
gpu3d_shader 74
ipu1_podf 75
ipu2_podf 76
ldb_di0_podf 77
ldb_di1_podf 78
ipu1_di0_pre 79
ipu1_di1_pre 80
ipu2_di0_pre 81
ipu2_di1_pre 82
hsi_tx_podf 83
ssi1_pred 84
ssi1_podf 85
ssi2_pred 86
ssi2_podf 87
ssi3_pred 88
ssi3_podf 89
uart_serial_podf 90
usdhc1_podf 91
usdhc2_podf 92
usdhc3_podf 93
usdhc4_podf 94
enfc_pred 95
enfc_podf 96
emi_podf 97
emi_slow_podf 98
vpu_axi_podf 99
cko1_podf 100
axi 101
mmdc_ch0_axi_podf 102
mmdc_ch1_axi_podf 103
arm 104
ahb 105
apbh_dma 106
asrc 107
can1_ipg 108
can1_serial 109
can2_ipg 110
can2_serial 111
ecspi1 112
ecspi2 113
ecspi3 114
ecspi4 115
ecspi5 116
enet 117
esai 118
gpt_ipg 119
gpt_ipg_per 120
gpu2d_core 121
gpu3d_core 122
hdmi_iahb 123
hdmi_isfr 124
i2c1 125
i2c2 126
i2c3 127
iim 128
enfc 129
ipu1 130
ipu1_di0 131
ipu1_di1 132
ipu2 133
ipu2_di0 134
ldb_di0 135
ldb_di1 136
ipu2_di1 137
hsi_tx 138
mlb 139
mmdc_ch0_axi 140
mmdc_ch1_axi 141
ocram 142
openvg_axi 143
pcie_axi 144
pwm1 145
pwm2 146
pwm3 147
pwm4 148
per1_bch 149
gpmi_bch_apb 150
gpmi_bch 151
gpmi_io 152
gpmi_apb 153
sata 154
sdma 155
spba 156
ssi1 157
ssi2 158
ssi3 159
uart_ipg 160
uart_serial 161
usboh3 162
usdhc1 163
usdhc2 164
usdhc3 165
usdhc4 166
vdo_axi 167
vpu_axi 168
cko1 169
pll1_sys 170
pll2_bus 171
pll3_usb_otg 172
pll4_audio 173
pll5_video 174
pll6_mlb 175
pll7_usb_host 176
pll8_enet 177
ssi1_ipg 178
ssi2_ipg 179
ssi3_ipg 180
rom 181
usbphy1 182
usbphy2 183
ldb_di0_div_3_5 184
ldb_di1_div_3_5 185
Examples:
clks: ccm@020c4000 {
compatible = "fsl,imx6q-ccm";
reg = <0x020c4000 0x4000>;
interrupts = <0 87 0x04 0 88 0x04>;
#clock-cells = <1>;
clock-output-names = ...
"uart_ipg",
"uart_serial",
...;
};
uart1: serial@02020000 {
compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
reg = <0x02020000 0x4000>;
interrupts = <0 26 0x04>;
clocks = <&clks 160>, <&clks 161>;
clock-names = "ipg", "per";
status = "disabled";
};

View File

@ -0,0 +1,72 @@
Device Tree Clock bindings for arch-vt8500
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:
"via,vt8500-pll-clock" - for a VT8500/WM8505 PLL clock
"wm,wm8650-pll-clock" - for a WM8650 PLL clock
"via,vt8500-device-clock" - for a VT/WM device clock
Required properties for PLL clocks:
- reg : shall be the control register offset from PMC base for the pll clock.
- clocks : shall be the input parent clock phandle for the clock. This should
be the reference clock.
- #clock-cells : from common clock binding; shall be set to 0.
Required properties for device clocks:
- clocks : shall be the input parent clock phandle for the clock. This should
be a pll output.
- #clock-cells : from common clock binding; shall be set to 0.
Device Clocks
Device clocks are required to have one or both of the following sets of
properties:
Gated device clocks:
Required properties:
- enable-reg : shall be the register offset from PMC base for the enable
register.
- enable-bit : shall be the bit within enable-reg to enable/disable the clock.
Divisor device clocks:
Required property:
- divisor-reg : shall be the register offset from PMC base for the divisor
register.
Optional property:
- divisor-mask : shall be the mask for the divisor register. Defaults to 0x1f
if not specified.
For example:
ref25: ref25M {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <25000000>;
};
plla: plla {
#clock-cells = <0>;
compatible = "wm,wm8650-pll-clock";
clocks = <&ref25>;
reg = <0x200>;
};
sdhc: sdhc {
#clock-cells = <0>;
compatible = "via,vt8500-device-clock";
clocks = <&pllb>;
divisor-reg = <0x328>;
divisor-mask = <0x3f>;
enable-reg = <0x254>;
enable-bit = <18>;
};

View File

@ -0,0 +1,55 @@
Generic CPU0 cpufreq driver
It is a generic cpufreq driver for CPU0 frequency management. It
supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
systems which share clock and voltage across all CPUs.
Both required and optional properties listed below must be defined
under node /cpus/cpu@0.
Required properties:
- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
for details
Optional properties:
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
Examples:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a9";
reg = <0>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
transition-latency = <61036>; /* two CLK32 periods */
};
cpu@1 {
compatible = "arm,cortex-a9";
reg = <1>;
next-level-cache = <&L2>;
};
cpu@2 {
compatible = "arm,cortex-a9";
reg = <2>;
next-level-cache = <&L2>;
};
cpu@3 {
compatible = "arm,cortex-a9";
reg = <3>;
next-level-cache = <&L2>;
};
};

View File

@ -9,6 +9,9 @@ Required properties:
region.
- interrupts: interrupt number to the cpu.
Optional properties:
- dma-coherent : Present if dma operations are coherent
Example:
pdma0: pdma@12680000 {

View File

@ -0,0 +1,74 @@
* MARVELL MMP DMA controller
Marvell Peripheral DMA Controller
Used platfroms: pxa688, pxa910, pxa3xx, etc
Required properties:
- compatible: Should be "marvell,pdma-1.0"
- reg: Should contain DMA registers location and length.
- interrupts: Either contain all of the per-channel DMA interrupts
or one irq for pdma device
- #dma-channels: Number of DMA channels supported by the controller.
"marvell,pdma-1.0"
Used platfroms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
Examples:
/*
* Each channel has specific irq
* ICU parse out irq channel from ICU register,
* while DMA controller may not able to distinguish the irq channel
* Using this method, interrupt-parent is required as demuxer
* For example, pxa688 icu register 0x128, bit 0~15 is PDMA channel irq,
* 18~21 is ADMA irq
*/
pdma: dma-controller@d4000000 {
compatible = "marvell,pdma-1.0";
reg = <0xd4000000 0x10000>;
interrupts = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>;
interrupt-parent = <&intcmux32>;
#dma-channels = <16>;
};
/*
* One irq for all channels
* Dmaengine driver (DMA controller) distinguish irq channel via
* parsing internal register
*/
pdma: dma-controller@d4000000 {
compatible = "marvell,pdma-1.0";
reg = <0xd4000000 0x10000>;
interrupts = <47>;
#dma-channels = <16>;
};
Marvell Two Channel DMA Controller used specifically for audio
Used platfroms: pxa688, pxa910
Required properties:
- compatible: Should be "marvell,adma-1.0" or "marvell,pxa910-squ"
- reg: Should contain DMA registers location and length.
- interrupts: Either contain all of the per-channel DMA interrupts
or one irq for dma device
"marvell,adma-1.0" used on pxa688
"marvell,pxa910-squ" used on pxa910
Examples:
/* each channel has specific irq */
adma0: dma-controller@d42a0800 {
compatible = "marvell,adma-1.0";
reg = <0xd42a0800 0x100>;
interrupts = <18 19>;
interrupt-parent = <&intcmux32>;
};
/* One irq for all channels */
squ: dma-controller@d42a0800 {
compatible = "marvell,pxa910-squ";
reg = <0xd42a0800 0x100>;
interrupts = <46>;
};

View File

@ -0,0 +1,22 @@
* Generic 8-bits shift register GPIO driver
Required properties:
- compatible : Should be "fairchild,74hc595"
- reg : chip select number
- 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 the gpio polarity:
0 = active high
1 = active low
- registers-number: Number of daisy-chained shift registers
Example:
gpio5: gpio5@0 {
compatible = "fairchild,74hc595";
reg = <0>;
gpio-controller;
#gpio-cells = <2>;
registers-number = <4>;
spi-max-frequency = <100000>;
};

View File

@ -0,0 +1,34 @@
Avionic Design N-bit GPIO expander bindings
Required properties:
- compatible: should be "ad,gpio-adnp"
- reg: The I2C slave address for this device.
- interrupt-parent: phandle of the parent interrupt controller.
- interrupts: Interrupt specifier for the controllers interrupt.
- #gpio-cells: Should be 2. The first cell is the GPIO number and the
second cell is used to specify optional parameters:
- bit 0: polarity (0: normal, 1: inverted)
- gpio-controller: Marks the device as a GPIO controller
- nr-gpios: The number of pins supported by the controller.
The GPIO expander can optionally be used as an interrupt controller, in
which case it uses the default two cell specifier as described in
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
Example:
gpioext: gpio-controller@41 {
compatible = "ad,gpio-adnp";
reg = <0x41>;
interrupt-parent = <&gpio>;
interrupts = <160 1>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
nr-gpios = <64>;
};

View File

@ -39,3 +39,46 @@ Example:
#gpio-cells = <4>;
gpio-controller;
};
Samsung S3C24XX GPIO Controller
Required properties:
- compatible: Compatible property value should be "samsung,s3c24xx-gpio".
- reg: Physical base address of the controller and length of memory mapped
region.
- #gpio-cells: Should be 3. The syntax of the gpio specifier used by client nodes
should be the following with values derived from the SoC user manual.
<[phandle of the gpio controller node]
[pin number within the gpio controller]
[mux function]
[flags and pull up/down]
Values for gpio specifier:
- Pin number: depending on the controller a number from 0 up to 15.
- Mux function: Depending on the SoC and the gpio bank the gpio can be set
as input, output or a special function
- Flags and Pull Up/Down: the values to use differ for the individual SoCs
example S3C2416/S3C2450:
0 - Pull Up/Down Disabled.
1 - Pull Down Enabled.
2 - Pull Up Enabled.
Bit 16 (0x00010000) - Input is active low.
Consult the user manual for the correct values of Mux and Pull Up/Down.
- gpio-controller: Specifies that the node is a gpio controller.
- #address-cells: should be 1.
- #size-cells: should be 1.
Example:
gpa: gpio-controller@56000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "samsung,s3c24xx-gpio";
reg = <0x56000000 0x10>;
#gpio-cells = <3>;
gpio-controller;
};

View File

@ -11,6 +11,11 @@ Required properties:
- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is not used.
- ti,use-leds : Enables LEDA and LEDB outputs if set
- ti,debounce : if n-th bit is set, debounces GPIO-n
- ti,mmc-cd : if n-th bit is set, GPIO-n controls VMMC(n+1)
- ti,pullups : if n-th bit is set, set a pullup on GPIO-n
- ti,pulldowns : if n-th bit is set, set a pulldown on GPIO-n
Example:
@ -20,4 +25,5 @@ twl_gpio: gpio {
gpio-controller;
#interrupt-cells = <2>;
interrupt-controller;
ti,use-leds;
};

View File

@ -0,0 +1,24 @@
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 */
};

View File

@ -8,7 +8,7 @@ node's name represents the name of the corresponding LED.
LED sub-node properties:
- gpios : Should specify the LED's GPIO, see "gpios property" in
Documentation/devicetree/gpio.txt. Active low LEDs should be
Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be
indicated using flags in the GPIO specifier.
- label : (optional) The label for this LED. If omitted, the label is
taken from the node name (excluding the unit address).

View File

@ -56,3 +56,4 @@ stm,m41t00 Serial Access TIMEKEEPER
stm,m41t62 Serial real-time clock (RTC) with alarm
stm,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS
ti,tsc2003 I2C Touch-Screen Controller
ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface

View File

@ -0,0 +1,38 @@
Device-Tree bindings for input/gpio_keys_polled.c keyboard driver
Required properties:
- compatible = "gpio-keys-polled";
- poll-interval: Poll interval time in milliseconds
Optional properties:
- autorepeat: Boolean, Enable auto repeat feature of Linux input
subsystem.
Each button (key) is represented as a sub-node of "gpio-keys-polled":
Subnode properties:
- gpios: OF device-tree gpio specification.
- label: Descriptive name of the key.
- linux,code: Keycode to emit.
Optional subnode-properties:
- linux,input-type: Specify event type this button/key generates.
If not specified defaults to <1> == EV_KEY.
- debounce-interval: Debouncing interval time in milliseconds.
If not specified defaults to 5.
- gpio-key,wakeup: Boolean, button can wake-up the system.
Example nodes:
gpio_keys_polled {
compatible = "gpio-keys-polled";
#address-cells = <1>;
#size-cells = <0>;
poll-interval = <100>;
autorepeat;
button@21 {
label = "GPIO Key UP";
linux,code = <103>;
gpios = <&gpio1 0 1>;
};
...

View File

@ -0,0 +1,36 @@
Rotary encoder DT bindings
Required properties:
- gpios: a spec for two GPIOs to be used
Optional properties:
- linux,axis: the input subsystem axis to map to this rotary encoder.
Defaults to 0 (ABS_X / REL_X)
- rotary-encoder,steps: Number of steps in a full turnaround of the
encoder. Only relevant for absolute axis. Defaults to 24 which is a
typical value for such devices.
- rotary-encoder,relative-axis: register a relative axis rather than an
absolute one. Relative axis will only generate +1/-1 events on the input
device, hence no steps need to be passed.
- rotary-encoder,rollover: Automatic rollove when the rotary value becomes
greater than the specified steps or smaller than 0. For absolute axis only.
- rotary-encoder,half-period: Makes the driver work on half-period mode.
See Documentation/input/rotary-encoder.txt for more information.
Example:
rotary@0 {
compatible = "rotary-encoder";
gpios = <&gpio 19 1>, <&gpio 20 0>; /* GPIO19 is inverted */
linux,axis = <0>; /* REL_X */
rotary-encoder,relative-axis;
};
rotary@1 {
compatible = "rotary-encoder";
gpios = <&gpio 21 0>, <&gpio 22 0>;
linux,axis = <1>; /* ABS_Y */
rotary-encoder,steps = <24>;
rotary-encoder,rollover;
};

View File

@ -0,0 +1,110 @@
BCM2835 Top-Level ("ARMCTRL") Interrupt Controller
The BCM2835 contains a custom top-level interrupt controller, which supports
72 interrupt sources using a 2-level register scheme. The interrupt
controller, or the HW block containing it, is referred to occasionally
as "armctrl" in the SoC documentation, hence naming of this binding.
Required properties:
- compatible : should be "brcm,bcm2835-armctrl-ic.txt"
- 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
interrupt source. The value shall be 2.
The 1st cell is the interrupt bank; 0 for interrupts in the "IRQ basic
pending" register, or 1/2 respectively for interrupts in the "IRQ pending
1/2" register.
The 2nd cell contains the interrupt number within the bank. Valid values
are 0..7 for bank 0, and 0..31 for bank 1.
The interrupt sources are as follows:
Bank 0:
0: ARM_TIMER
1: ARM_MAILBOX
2: ARM_DOORBELL_0
3: ARM_DOORBELL_1
4: VPU0_HALTED
5: VPU1_HALTED
6: ILLEGAL_TYPE0
7: ILLEGAL_TYPE1
Bank 1:
0: TIMER0
1: TIMER1
2: TIMER2
3: TIMER3
4: CODEC0
5: CODEC1
6: CODEC2
7: VC_JPEG
8: ISP
9: VC_USB
10: VC_3D
11: TRANSPOSER
12: MULTICORESYNC0
13: MULTICORESYNC1
14: MULTICORESYNC2
15: MULTICORESYNC3
16: DMA0
17: DMA1
18: VC_DMA2
19: VC_DMA3
20: DMA4
21: DMA5
22: DMA6
23: DMA7
24: DMA8
25: DMA9
26: DMA10
27: DMA11
28: DMA12
29: AUX
30: ARM
31: VPUDMA
Bank 2:
0: HOSTPORT
1: VIDEOSCALER
2: CCP2TX
3: SDC
4: DSI0
5: AVE
6: CAM0
7: CAM1
8: HDMI0
9: HDMI1
10: PIXELVALVE1
11: I2CSPISLV
12: DSI1
13: PWA0
14: PWA1
15: CPR
16: SMI
17: GPIO0
18: GPIO1
19: GPIO2
20: GPIO3
21: VC_I2C
22: VC_SPI
23: VC_I2SPCM
24: VC_SDIO
25: VC_UART
26: SLIMBUS
27: VEC
28: CPG
29: RNG
30: VC_ARASANSDIO
31: AVSPMON
Example:
intc: interrupt-controller {
compatible = "brcm,bcm2835-armctrl-ic";
reg = <0x7e00b200 0x200>;
interrupt-controller;
#interrupt-cells = <2>;
};

View File

@ -0,0 +1,95 @@
Specifying interrupt information for devices
============================================
1) Interrupt client nodes
-------------------------
Nodes that describe devices which generate interrupts must contain an
"interrupts" property. This property must contain a list of interrupt
specifiers, one per output interrupt. The format of the interrupt specifier is
determined by the interrupt controller to which the interrupts are routed; see
section 2 below for details.
The "interrupt-parent" property is used to specify the controller to which
interrupts are routed and contains a single phandle referring to the interrupt
controller node. This property is inherited, so it may be specified in an
interrupt client node or in any of its parent nodes.
2) Interrupt controller nodes
-----------------------------
A device is marked as an interrupt controller with the "interrupt-controller"
property. This is a empty, boolean property. An additional "#interrupt-cells"
property defines the number of cells needed to specify a single interrupt.
It is the responsibility of the interrupt controller's binding to define the
length and format of the interrupt specifier. The following two variants are
commonly used:
a) one cell
-----------
The #interrupt-cells property is set to 1 and the single cell defines the
index of the interrupt within the controller.
Example:
vic: intc@10140000 {
compatible = "arm,versatile-vic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x10140000 0x1000>;
};
sic: intc@10003000 {
compatible = "arm,versatile-sic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x10003000 0x1000>;
interrupt-parent = <&vic>;
interrupts = <31>; /* Cascaded to vic */
};
b) two cells
------------
The #interrupt-cells property is set to 2 and the first cell defines the
index of the interrupt within the controller, while the second cell is used
to specify any of the following flags:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
Example:
i2c@7000c000 {
gpioext: gpio-adnp@41 {
compatible = "ad,gpio-adnp";
reg = <0x41>;
interrupt-parent = <&gpio>;
interrupts = <160 1>;
gpio-controller;
#gpio-cells = <1>;
interrupt-controller;
#interrupt-cells = <2>;
nr-gpios = <64>;
};
sx8634@2b {
compatible = "smtc,sx8634";
reg = <0x2b>;
interrupt-parent = <&gpioext>;
interrupts = <3 0x8>;
#address-cells = <1>;
#size-cells = <0>;
threshold = <0x40>;
sensitivity = <7>;
};
};

View File

@ -0,0 +1,52 @@
* AC timing parameters of LPDDR2(JESD209-2) memories for a given speed-bin
Required properties:
- compatible : Should be "jedec,lpddr2-timings"
- min-freq : minimum DDR clock frequency for the speed-bin. Type is <u32>
- max-freq : maximum DDR clock frequency for the speed-bin. Type is <u32>
Optional properties:
The following properties represent AC timing parameters from the memory
data-sheet of the device for a given speed-bin. All these properties are
of type <u32> and the default unit is ps (pico seconds). Parameters with
a different unit have a suffix indicating the unit such as 'tRAS-max-ns'
- tRCD
- tWR
- tRAS-min
- tRRD
- tWTR
- tXP
- tRTP
- tDQSCK-max
- tFAW
- tZQCS
- tZQinit
- tRPab
- tZQCL
- tCKESR
- tRAS-max-ns
- tDQSCK-max-derated
Example:
timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
compatible = "jedec,lpddr2-timings";
min-freq = <10000000>;
max-freq = <400000000>;
tRPab = <21000>;
tRCD = <18000>;
tWR = <15000>;
tRAS-min = <42000>;
tRRD = <10000>;
tWTR = <7500>;
tXP = <7500>;
tRTP = <7500>;
tCKESR = <15000>;
tDQSCK-max = <5500>;
tFAW = <50000>;
tZQCS = <90000>;
tZQCL = <360000>;
tZQinit = <1000000>;
tRAS-max-ns = <70000>;
};

View File

@ -0,0 +1,102 @@
* LPDDR2 SDRAM memories compliant to JEDEC JESD209-2
Required properties:
- compatible : Should be one of - "jedec,lpddr2-nvm", "jedec,lpddr2-s2",
"jedec,lpddr2-s4"
"ti,jedec-lpddr2-s2" should be listed if the memory part is LPDDR2-S2 type
"ti,jedec-lpddr2-s4" should be listed if the memory part is LPDDR2-S4 type
"ti,jedec-lpddr2-nvm" should be listed if the memory part is LPDDR2-NVM type
- density : <u32> representing density in Mb (Mega bits)
- io-width : <u32> representing bus width. Possible values are 8, 16, and 32
Optional properties:
The following optional properties represent the minimum value of some AC
timing parameters of the DDR device in terms of number of clock cycles.
These values shall be obtained from the device data-sheet.
- tRRD-min-tck
- tWTR-min-tck
- tXP-min-tck
- tRTP-min-tck
- tCKE-min-tck
- tRPab-min-tck
- tRCD-min-tck
- tWR-min-tck
- tRASmin-min-tck
- tCKESR-min-tck
- tFAW-min-tck
Child nodes:
- The lpddr2 node may have one or more child nodes of type "lpddr2-timings".
"lpddr2-timings" provides AC timing parameters of the device for
a given speed-bin. The user may provide the timings for as many
speed-bins as is required. Please see Documentation/devicetree/
bindings/lpddr2/lpddr2-timings.txt for more information on "lpddr2-timings"
Example:
elpida_ECB240ABACN : lpddr2 {
compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4";
density = <2048>;
io-width = <32>;
tRPab-min-tck = <3>;
tRCD-min-tck = <3>;
tWR-min-tck = <3>;
tRASmin-min-tck = <3>;
tRRD-min-tck = <2>;
tWTR-min-tck = <2>;
tXP-min-tck = <2>;
tRTP-min-tck = <2>;
tCKE-min-tck = <3>;
tCKESR-min-tck = <3>;
tFAW-min-tck = <8>;
timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
compatible = "jedec,lpddr2-timings";
min-freq = <10000000>;
max-freq = <400000000>;
tRPab = <21000>;
tRCD = <18000>;
tWR = <15000>;
tRAS-min = <42000>;
tRRD = <10000>;
tWTR = <7500>;
tXP = <7500>;
tRTP = <7500>;
tCKESR = <15000>;
tDQSCK-max = <5500>;
tFAW = <50000>;
tZQCS = <90000>;
tZQCL = <360000>;
tZQinit = <1000000>;
tRAS-max-ns = <70000>;
};
timings_elpida_ECB240ABACN_200mhz: lpddr2-timings@1 {
compatible = "jedec,lpddr2-timings";
min-freq = <10000000>;
max-freq = <200000000>;
tRPab = <21000>;
tRCD = <18000>;
tWR = <15000>;
tRAS-min = <42000>;
tRRD = <10000>;
tWTR = <10000>;
tXP = <7500>;
tRTP = <7500>;
tCKESR = <15000>;
tDQSCK-max = <5500>;
tFAW = <50000>;
tZQCS = <90000>;
tZQCL = <360000>;
tZQinit = <1000000>;
tRAS-max-ns = <70000>;
};
}

View File

@ -0,0 +1,30 @@
* Samsung Exynos5 G-Scaler device
G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
Required properties:
- compatible: should be "samsung,exynos5-gsc"
- reg: should contain G-Scaler physical address location and length.
- interrupts: should contain G-Scaler interrupt number
Example:
gsc_0: gsc@0x13e00000 {
compatible = "samsung,exynos5-gsc";
reg = <0x13e00000 0x1000>;
interrupts = <0 85 0>;
};
Aliases:
Each G-Scaler node should have a numbered alias in the aliases node,
in the form of gscN, N = 0...3. G-Scaler driver uses these aliases
to retrieve the device IDs using "of_alias_get_id()" call.
Example:
aliases {
gsc0 =&gsc_0;
gsc1 =&gsc_1;
gsc2 =&gsc_2;
gsc3 =&gsc_3;
};

View File

@ -0,0 +1,55 @@
* EMIF family of TI SDRAM controllers
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
of the EMIF IP and memory parts attached to it.
Required properties:
- compatible : Should be of the form "ti,emif-<ip-rev>" where <ip-rev>
is the IP revision of the specific EMIF instance.
- phy-type : <u32> indicating the DDR phy type. Following are the
allowed values
<1> : Attila PHY
<2> : Intelli PHY
- device-handle : phandle to a "lpddr2" node representing the memory part
- ti,hwmods : For TI hwmods processing and omap device creation
the value shall be "emif<n>" where <n> is the number of the EMIF
instance with base 1.
Optional properties:
- cs1-used : Have this property if CS1 of this EMIF
instance has a memory part attached to it. If there is a memory
part attached to CS1, it should be the same type as the one on CS0,
so there is no need to give the details of this memory part.
- cal-resistor-per-cs : Have this property if the board has one
calibration resistor per chip-select.
- hw-caps-read-idle-ctrl: Have this property if the controller
supports read idle window programming
- hw-caps-dll-calib-ctrl: Have this property if the controller
supports dll calibration control
- hw-caps-ll-interface : Have this property if the controller
has a low latency interface and corresponding interrupt events
- hw-caps-temp-alert : Have this property if the controller
has capability for generating SDRAM temperature alerts
Example:
emif1: emif@0x4c000000 {
compatible = "ti,emif-4d";
ti,hwmods = "emif2";
phy-type = <1>;
device-handle = <&elpida_ECB240ABACN>;
cs1-used;
hw-caps-read-idle-ctrl;
hw-caps-ll-interface;
hw-caps-temp-alert;
};

View File

@ -23,6 +23,7 @@ Device IRQ Names Supply Names Description
ab8500-bm : : : Battery Manager
ab8500-btemp : : : Battery Temperature
ab8500-charger : : : Battery Charger
ab8500-codec : : : Audio Codec
ab8500-fg : : : Fuel Gauge
ab8500-gpadc : HW_CONV_END : vddadc : Analogue to Digital Converter
SW_CONV_END : :
@ -52,6 +53,14 @@ Optional child device properties:
supplied in the interrupts property
- <supply_name>-supply : contains a phandle to the regulator supply node in Device Tree
Non-standard child device properties:
- Audio CODEC:
- stericsson,amic[1|2]-type-single-ended : Single-ended Analoge Mic (default: differential)
- stericsson,amic1a-bias-vamic2 : Analoge Mic wishes to use a non-standard Vamic
- stericsson,amic1b-bias-vamic2 : Analoge Mic wishes to use a non-standard Vamic
- stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic
- stericsson,earpeice-cmv : Earpeice voltage (only: 950 | 1100 | 1270 | 1580)
ab8500@5 {
compatible = "stericsson,ab8500";
reg = <5>; /* mailbox 5 is i2c */
@ -110,6 +119,12 @@ ab8500@5 {
compatible = "stericsson,ab8500-pwm";
};
codec: ab8500-codec {
compatible = "stericsson,ab8500-codec";
stericsson,earpeice-cmv = <950>; /* Units in mV. */
};
ab8500-regulators {
compatible = "stericsson,ab8500-regulator";

View File

@ -1,21 +1,35 @@
Atmel AT25 eeprom
EEPROMs (SPI) compatible with Atmel at25.
Required properties:
- compatible : "atmel,at25".
- reg : chip select number
- spi-max-frequency : max spi frequency to use
- pagesize : size of the eeprom page
- size : total eeprom size in bytes
- address-width : number of address bits (one of 8, 16, or 24)
Optional properties:
- spi-cpha : SPI shifted clock phase, as per spi-bus bindings.
- spi-cpol : SPI inverse clock polarity, as per spi-bus bindings.
- read-only : this parameter-less property disables writes to the eeprom
Obsolete legacy properties are can be used in place of "size", "pagesize",
"address-width", and "read-only":
- at25,byte-len : total eeprom size in bytes
- at25,addr-mode : addr-mode flags, as defined in include/linux/spi/eeprom.h
- at25,page-size : size of the eeprom page
Examples:
at25@0 {
compatible = "atmel,at25";
reg = <0>
spi-max-frequency = <5000000>;
Additional compatible properties are also allowed.
at25,byte-len = <0x8000>;
at25,addr-mode = <2>;
at25,page-size = <64>;
};
Example:
at25@0 {
compatible = "atmel,at25", "st,m95256";
reg = <0>
spi-max-frequency = <5000000>;
spi-cpha;
spi-cpol;
pagesize = <64>;
size = <32768>;
address-width = <16>;
};

View File

@ -0,0 +1,112 @@
LIS302 accelerometer devicetree bindings
This device is matched via its bus drivers, and has a number of properties
that apply in on the generic device (independent from the bus).
Required properties for the SPI bindings:
- compatible: should be set to "st,lis3lv02d_spi"
- reg: the chipselect index
- spi-max-frequency: maximal bus speed, should be set to 1000000 unless
constrained by external circuitry
- interrupts: the interrupt generated by the device
Required properties for the I2C bindings:
- compatible: should be set to "st,lis3lv02d"
- reg: i2c slave address
- Vdd-supply: The input supply for Vdd
- Vdd_IO-supply: The input supply for Vdd_IO
Optional properties for all bus drivers:
- st,click-single-{x,y,z}: if present, tells the device to issue an
interrupt on single click events on the
x/y/z axis.
- st,click-double-{x,y,z}: if present, tells the device to issue an
interrupt on double click events on the
x/y/z axis.
- st,click-thresh-{x,y,z}: set the x/y/z axis threshold
- st,click-click-time-limit: click time limit, from 0 to 127.5msec
with step of 0.5 msec
- st,click-latency: click latency, from 0 to 255 msec with
step of 1 msec.
- st,click-window: click window, from 0 to 255 msec with
step of 1 msec.
- st,irq{1,2}-disable: disable IRQ 1/2
- st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition
- st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition
- st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition
- st,irq{1,2}-click: raise IRQ 1/2 on click condition
- st,irq-open-drain: consider IRQ lines open-drain
- st,irq-active-low: make IRQ lines active low
- st,wu-duration-1: duration register for Free-Fall/Wake-Up
interrupt 1
- st,wu-duration-2: duration register for Free-Fall/Wake-Up
interrupt 2
- st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
upper/lower limit
- st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
highpass cut-off frequency
- st,hipass{1,2}-disable: disable highpass 1/2.
- st,default-rate=: set the default rate
- st,axis-{x,y,z}=: set the axis to map to the three coordinates
- st,{min,max}-limit-{x,y,z} set the min/max limits for x/y/z axis
(used by self-test)
Example for a SPI device node:
lis302@0 {
compatible = "st,lis302dl-spi";
reg = <0>;
spi-max-frequency = <1000000>;
interrupt-parent = <&gpio>;
interrupts = <104 0>;
st,click-single-x;
st,click-single-y;
st,click-single-z;
st,click-thresh-x = <10>;
st,click-thresh-y = <10>;
st,click-thresh-z = <10>;
st,irq1-click;
st,irq2-click;
st,wakeup-x-lo;
st,wakeup-x-hi;
st,wakeup-y-lo;
st,wakeup-y-hi;
st,wakeup-z-lo;
st,wakeup-z-hi;
};
Example for a I2C device node:
lis331dlh: lis331dlh@18 {
compatible = "st,lis331dlh", "st,lis3lv02d";
reg = <0x18>;
Vdd-supply = <&lis3_reg>;
Vdd_IO-supply = <&lis3_reg>;
st,click-single-x;
st,click-single-y;
st,click-single-z;
st,click-thresh-x = <10>;
st,click-thresh-y = <10>;
st,click-thresh-z = <10>;
st,irq1-click;
st,irq2-click;
st,wakeup-x-lo;
st,wakeup-x-hi;
st,wakeup-y-lo;
st,wakeup-y-hi;
st,wakeup-z-lo;
st,wakeup-z-hi;
st,min-limit-x = <120>;
st,min-limit-y = <120>;
st,min-limit-z = <140>;
st,max-limit-x = <550>;
st,max-limit-y = <550>;
st,max-limit-z = <750>;
};

View File

@ -0,0 +1,31 @@
PXA3xx NAND DT bindings
Required properties:
- compatible: Should be "marvell,pxa3xx-nand"
- reg: The register base for the controller
- interrupts: The interrupt to map
- #address-cells: Set to <1> if the node includes partitions
Optional properties:
- marvell,nand-enable-arbiter: Set to enable the bus arbiter
- marvell,nand-keep-config: Set to keep the NAND controller config as set
by the bootloader
- num-cs: Number of chipselect lines to usw
Example:
nand0: nand@43100000 {
compatible = "marvell,pxa3xx-nand";
reg = <0x43100000 90>;
interrupts = <45>;
#address-cells = <1>;
marvell,nand-enable-arbiter;
marvell,nand-keep-config;
num-cs = <1>;
/* partitions (optional) */
};

View File

@ -6,6 +6,9 @@ Required properties:
- interrupts : Should contain 3 xgmac interrupts. The 1st is main interrupt.
The 2nd is pwr mgt interrupt. The 3rd is low power state interrupt.
Optional properties:
- dma-coherent : Present if dma operations are coherent
Example:
ethernet@fff50000 {

View File

@ -0,0 +1,49 @@
Bosch C_CAN/D_CAN controller Device Tree Bindings
-------------------------------------------------
Required properties:
- compatible : Should be "bosch,c_can" for C_CAN controllers and
"bosch,d_can" for D_CAN controllers.
- reg : physical base address and size of the C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
number
Optional properties:
- ti,hwmods : Must be "d_can<n>" or "c_can<n>", n being the
instance number
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
Example:
Step1: SoC common .dtsi file
dcan1: d_can@481d0000 {
compatible = "bosch,d_can";
reg = <0x481d0000 0x2000>;
interrupts = <55>;
interrupt-parent = <&intc>;
status = "disabled";
};
(or)
dcan1: d_can@481d0000 {
compatible = "bosch,d_can";
ti,hwmods = "d_can1";
reg = <0x481d0000 0x2000>;
interrupts = <55>;
interrupt-parent = <&intc>;
status = "disabled";
};
Step 2: board specific .dts file
&dcan1 {
status = "okay";
};

View File

@ -0,0 +1,109 @@
TI SoC Ethernet Switch Controller Device Tree Bindings
------------------------------------------------------
Required properties:
- compatible : Should be "ti,cpsw"
- reg : physical base address and size of the cpsw
registers map
- interrupts : property with a value describing the interrupt
number
- interrupt-parent : The parent interrupt controller
- cpdma_channels : Specifies number of channels in CPDMA
- host_port_no : Specifies host port shift
- cpdma_reg_ofs : Specifies CPDMA submodule register offset
- cpdma_sram_ofs : Specifies CPDMA SRAM offset
- ale_reg_ofs : Specifies ALE submodule register offset
- ale_entries : Specifies No of entries ALE can hold
- host_port_reg_ofs : Specifies host port register offset
- hw_stats_reg_ofs : Specifies hardware statistics register offset
- bd_ram_ofs : Specifies internal desciptor RAM offset
- bd_ram_size : Specifies internal descriptor RAM size
- rx_descs : Specifies number of Rx descriptors
- mac_control : Specifies Default MAC control register content
for the specific platform
- slaves : Specifies number for slaves
- slave_reg_ofs : Specifies slave register offset
- sliver_reg_ofs : Specifies slave sliver register offset
- phy_id : Specifies slave phy id
- mac-address : Specifies slave MAC address
Optional properties:
- ti,hwmods : Must be "cpgmac0"
- no_bd_ram : Must be 0 or 1
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
Examples:
mac: ethernet@4A100000 {
compatible = "ti,cpsw";
reg = <0x4A100000 0x1000>;
interrupts = <55 0x4>;
interrupt-parent = <&intc>;
cpdma_channels = <8>;
host_port_no = <0>;
cpdma_reg_ofs = <0x800>;
cpdma_sram_ofs = <0xa00>;
ale_reg_ofs = <0xd00>;
ale_entries = <1024>;
host_port_reg_ofs = <0x108>;
hw_stats_reg_ofs = <0x900>;
bd_ram_ofs = <0x2000>;
bd_ram_size = <0x2000>;
no_bd_ram = <0>;
rx_descs = <64>;
mac_control = <0x20>;
slaves = <2>;
cpsw_emac0: slave@0 {
slave_reg_ofs = <0x208>;
sliver_reg_ofs = <0xd80>;
phy_id = "davinci_mdio.16:00";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
slave_reg_ofs = <0x308>;
sliver_reg_ofs = <0xdc0>;
phy_id = "davinci_mdio.16:01";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
};
(or)
mac: ethernet@4A100000 {
compatible = "ti,cpsw";
ti,hwmods = "cpgmac0";
cpdma_channels = <8>;
host_port_no = <0>;
cpdma_reg_ofs = <0x800>;
cpdma_sram_ofs = <0xa00>;
ale_reg_ofs = <0xd00>;
ale_entries = <1024>;
host_port_reg_ofs = <0x108>;
hw_stats_reg_ofs = <0x900>;
bd_ram_ofs = <0x2000>;
bd_ram_size = <0x2000>;
no_bd_ram = <0>;
rx_descs = <64>;
mac_control = <0x20>;
slaves = <2>;
cpsw_emac0: slave@0 {
slave_reg_ofs = <0x208>;
sliver_reg_ofs = <0xd80>;
phy_id = "davinci_mdio.16:00";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
slave_reg_ofs = <0x308>;
sliver_reg_ofs = <0xdc0>;
phy_id = "davinci_mdio.16:01";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
};

View File

@ -0,0 +1,33 @@
TI SoC Davinci MDIO Controller Device Tree Bindings
---------------------------------------------------
Required properties:
- compatible : Should be "ti,davinci_mdio"
- reg : physical base address and size of the davinci mdio
registers map
- bus_freq : Mdio Bus frequency
Optional properties:
- ti,hwmods : Must be "davinci_mdio"
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
Examples:
mdio: davinci_mdio@4A101000 {
compatible = "ti,cpsw";
reg = <0x4A101000 0x1000>;
bus_freq = <1000000>;
};
(or)
mdio: davinci_mdio@4A101000 {
compatible = "ti,cpsw";
ti,hwmods = "davinci_mdio";
bus_freq = <1000000>;
};

View File

@ -0,0 +1,75 @@
Properties for an MDIO bus multiplexer controlled by a memory-mapped device
This is a special case of a MDIO bus multiplexer. A memory-mapped device,
like an FPGA, is used to control which child bus is connected. The mdio-mux
node must be a child of the memory-mapped device. The driver currently only
supports devices with eight-bit registers.
Required properties in addition to the generic multiplexer properties:
- compatible : string, must contain "mdio-mux-mmioreg"
- reg : integer, contains the offset of the register that controls the bus
multiplexer. The size field in the 'reg' property is the size of
register, and must therefore be 1.
- mux-mask : integer, contains an eight-bit mask that specifies which
bits in the register control the actual bus multiplexer. The
'reg' property of each child mdio-mux node must be constrained by
this mask.
Example:
The FPGA node defines a memory-mapped FPGA with a register space of 0x30 bytes.
For the "EMI2" MDIO bus, register 9 (BRDCFG1) controls the mux on that bus.
A bitmask of 0x6 means that bits 1 and 2 (bit 0 is lsb) are the bits on
BRDCFG1 that control the actual mux.
/* The FPGA node */
fpga: board-control@3,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,p5020ds-fpga", "fsl,fpga-ngpixis";
reg = <3 0 0x30>;
ranges = <0 3 0 0x30>;
mdio-mux-emi2 {
compatible = "mdio-mux-mmioreg", "mdio-mux";
mdio-parent-bus = <&xmdio0>;
#address-cells = <1>;
#size-cells = <0>;
reg = <9 1>; // BRDCFG1
mux-mask = <0x6>; // EMI2
emi2_slot1: mdio@0 { // Slot 1 XAUI (FM2)
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
phy_xgmii_slot1: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c45";
reg = <4>;
};
};
emi2_slot2: mdio@2 { // Slot 2 XAUI (FM1)
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
phy_xgmii_slot2: ethernet-phy@4 {
compatible = "ethernet-phy-ieee802.3-c45";
reg = <0>;
};
};
};
};
/* The parent MDIO bus. */
xmdio0: mdio@f1000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,fman-xmdio";
reg = <0xf1000 0x1000>;
interrupts = <100 1 0 0>;
};

View File

@ -0,0 +1,74 @@
Broadcom BCM2835 GPIO (and pinmux) controller
The BCM2835 GPIO module is a combined GPIO controller, (GPIO) interrupt
controller, and pinmux/control device.
Required properties:
- compatible: "brcm,bcm2835-gpio"
- reg: Should contain the physical address of the GPIO module's registes.
- 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 specifies polarity (0 for normal, 1 for inverted)
- interrupts : The interrupt outputs from the controller. One interrupt per
individual bank followed by the "all banks" interrupt.
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
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 function 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 pul parameter implies no information about the mux function.
Required subnode-properties:
- brcm,pins: An array of cells. Each cell contains the ID of a pin. Valid IDs
are the integer GPIO IDs; 0==GPIO0, 1==GPIO1, ... 53==GPIO53.
Optional subnode-properties:
- brcm,function: Integer, containing the function to mux to the pin(s):
0: GPIO in
1: GPIO out
2: alt5
3: alt4
4: alt0
5: alt1
6: alt2
7: alt3
- brcm,pull: Integer, representing the pull-down/up to apply to the pin(s):
0: none
1: down
2: up
Each of brcm,function and brcm,pull may contain either a single value which
will be applied to all pins in brcm,pins, or 1 value for each entry in
brcm,pins.
Example:
gpio: gpio {
compatible = "brcm,bcm2835-gpio";
reg = <0x2200000 0xb4>;
interrupts = <2 17>, <2 19>, <2 18>, <2 20>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};

View File

@ -0,0 +1,984 @@
* Freescale IMX35 IOMUX Controller
Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
and usage.
Required properties:
- compatible: "fsl,imx35-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 imx35 datasheet for the valid pad
config settings.
CONFIG bits definition:
PAD_CTL_DRIVE_VOLAGAGE_18 (1 << 13)
PAD_CTL_DRIVE_VOLAGAGE_33 (0 << 13)
PAD_CTL_HYS (1 << 8)
PAD_CTL_PKE (1 << 7)
PAD_CTL_PUE (1 << 6)
PAD_CTL_PUS_100K_DOWN (0 << 4)
PAD_CTL_PUS_47K_UP (1 << 4)
PAD_CTL_PUS_100K_UP (2 << 4)
PAD_CTL_PUS_22K_UP (3 << 4)
PAD_CTL_ODE_CMOS (0 << 3)
PAD_CTL_ODE_OPENDRAIN (1 << 3)
PAD_CTL_DSE_NOMINAL (0 << 1)
PAD_CTL_DSE_HIGH (1 << 1)
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

View File

@ -14,10 +14,12 @@ Optional properties:
- pinctrl-single,function-off : function off mode for disabled state if
available and same for all registers; if not specified, disabling of
pin functions is ignored
- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
more than one pin
This driver assumes that there is only one register for each pin,
and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt
document in this directory.
This driver assumes that there is only one register for each pin (unless the
pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
specified in the pinctrl-bindings.txt document in this directory.
The pin configuration nodes for pinctrl-single are specified as pinctrl
register offset and value pairs using pinctrl-single,pins. Only the bits
@ -31,6 +33,15 @@ device pinctrl register, and 0x118 contains the desired value of the
pinctrl register. See the device example and static board pins example
below for more information.
In case when one register changes more than one pin's mux the
pinctrl-single,bits need to be used which takes three parameters:
pinctrl-single,bits = <0xdc 0x18, 0xff>;
Where 0xdc is the offset from the pinctrl register base address for the
device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
be used when applying this change to the register.
Example:
/* SoC common file */
@ -55,6 +66,15 @@ pmx_wkup: pinmux@4a31e040 {
pinctrl-single,function-mask = <0xffff>;
};
control_devconf0: pinmux@48002274 {
compatible = "pinctrl-single";
reg = <0x48002274 4>; /* Single register */
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,bit-per-mux;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x5F>;
};
/* board specific .dts file */
@ -87,6 +107,21 @@ pmx_wkup: pinmux@4a31e040 {
};
};
&control_devconf0 {
mcbsp1_pins: pinmux_mcbsp1_pins {
pinctrl-single,bits = <
0x00 0x18 0x18 /* FSR/CLKR signal from FSX/CLKX pin */
>;
};
mcbsp2_clks_pins: pinmux_mcbsp2_clks_pins {
pinctrl-single,bits = <
0x00 0x40 0x40 /* McBSP2 CLKS from McBSP_CLKS pin */
>;
};
};
&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&uart2_pins>;

View File

@ -0,0 +1,196 @@
Samsung GPIO and Pin Mux/Config controller
Samsung's ARM based SoC's integrates a GPIO and Pin mux/config hardware
controller. It controls the input/output settings on the available pads/pins
and also provides ability to multiplex and configure the output of various
on-chip controllers onto these pads.
Required Properties:
- compatible: should be one of the following.
- "samsung,pinctrl-exynos4210": for Exynos4210 compatible pin-controller.
- "samsung,pinctrl-exynos5250": for Exynos5250 compatible pin-controller.
- reg: Base address of the pin controller hardware module and length of
the address space it occupies.
- interrupts: interrupt specifier for the controller. The format and value of
the interrupt specifier depends on the interrupt parent for the controller.
- Pin mux/config groups as child nodes: The pin mux (selecting pin function
mode) and pin config (pull up/down, driver strength) settings are represented
as child nodes of the pin-controller node. There should be atleast one
child node and there is no limit on the count of these child nodes.
The child node should contain a list of pin(s) on which a particular pin
function selection or pin configuration (or both) have to applied. This
list of pins is specified using the property name "samsung,pins". There
should be atleast one pin specfied for this property and there is no upper
limit on the count of pins that can be specified. The pins are specified
using pin names which are derived from the hardware manual of the SoC. As
an example, the pins in GPA0 bank of the pin controller can be represented
as "gpa0-0", "gpa0-1", "gpa0-2" and so on. The names should be in lower case.
The format of the pin names should be (as per the hardware manual)
"[pin bank name]-[pin number within the bank]".
The pin function selection that should be applied on the pins listed in the
child node is specified using the "samsung,pin-function" property. The value
of this property that should be applied to each of the pins listed in the
"samsung,pins" property should be picked from the hardware manual of the SoC
for the specified pin group. This property is optional in the child node if
no specific function selection is desired for the pins listed in the child
node. The value of this property is used as-is to program the pin-controller
function selector register of the pin-bank.
The child node can also optionally specify one or more of the pin
configuration that should be applied on all the pins listed in the
"samsung,pins" property of the child node. The following pin configuration
properties are supported.
- samsung,pin-pud: Pull up/down configuration.
- samsung,pin-drv: Drive strength configuration.
- samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
- samsung,pin-drv-pdn: Drive strength configuration in power down mode.
The values specified by these config properties should be derived from the
hardware manual and these values are programmed as-is into the pin
pull up/down and driver strength register of the pin-controller.
Note: A child should include atleast a pin function selection property or
pin configuration property (one or more) or both.
The client nodes that require a particular pin function selection and/or
pin configuration should use the bindings listed in the "pinctrl-bindings.txt"
file.
External GPIO and Wakeup Interrupts:
The controller supports two types of external interrupts over gpio. The first
is the external gpio interrupt and second is the external wakeup interrupts.
The difference between the two is that the external wakeup interrupts can be
used as system wakeup events.
A. External GPIO Interrupts: For supporting external gpio interrupts, the
following properties should be specified in the pin-controller device node.
- interrupt-controller: identifies the controller node as interrupt-parent.
- #interrupt-cells: the value of this property should be 2.
- First Cell: represents the external gpio interrupt number local to the
external gpio interrupt space of the controller.
- Second Cell: flags to identify the type of the interrupt
- 1 = rising edge triggered
- 2 = falling edge triggered
- 3 = rising and falling edge triggered
- 4 = high level triggered
- 8 = low level triggered
B. External Wakeup Interrupts: For supporting external wakeup interrupts, a
child node representing the external wakeup interrupt controller should be
included in the pin-controller device node. This child node should include
the following properties.
- compatible: identifies the type of the external wakeup interrupt controller
The possible values are:
- samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
found on Samsung Exynos4210 SoC.
- interrupt-parent: phandle of the interrupt parent to which the external
wakeup interrupts are forwarded to.
- interrupt-controller: identifies the node as interrupt-parent.
- #interrupt-cells: the value of this property should be 2
- First Cell: represents the external wakeup interrupt number local to
the external wakeup interrupt space of the controller.
- Second Cell: flags to identify the type of the interrupt
- 1 = rising edge triggered
- 2 = falling edge triggered
- 3 = rising and falling edge triggered
- 4 = high level triggered
- 8 = low level triggered
Aliases:
All the pin controller nodes should be represented in the aliases node using
the following format 'pinctrl{n}' where n is a unique number for the alias.
Example 1: A pin-controller node with pin groups.
pinctrl_0: pinctrl@11400000 {
compatible = "samsung,pinctrl-exynos4210";
reg = <0x11400000 0x1000>;
interrupts = <0 47 0>;
uart0_data: uart0-data {
samsung,pins = "gpa0-0", "gpa0-1";
samsung,pin-function = <2>;
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
uart0_fctl: uart0-fctl {
samsung,pins = "gpa0-2", "gpa0-3";
samsung,pin-function = <2>;
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
uart1_data: uart1-data {
samsung,pins = "gpa0-4", "gpa0-5";
samsung,pin-function = <2>;
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
uart1_fctl: uart1-fctl {
samsung,pins = "gpa0-6", "gpa0-7";
samsung,pin-function = <2>;
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
i2c2_bus: i2c2-bus {
samsung,pins = "gpa0-6", "gpa0-7";
samsung,pin-function = <3>;
samsung,pin-pud = <3>;
samsung,pin-drv = <0>;
};
};
Example 2: A pin-controller node with external wakeup interrupt controller node.
pinctrl_1: pinctrl@11000000 {
compatible = "samsung,pinctrl-exynos4210";
reg = <0x11000000 0x1000>;
interrupts = <0 46 0>;
interrupt-controller;
#interrupt-cells = <2>;
wakup_eint: wakeup-interrupt-controller {
compatible = "samsung,exynos4210-wakeup-eint";
interrupt-parent = <&gic>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <0 16 0>, <0 17 0>, <0 18 0>, <0 19 0>,
<0 20 0>, <0 21 0>, <0 22 0>, <0 23 0>,
<0 24 0>, <0 25 0>, <0 26 0>, <0 27 0>,
<0 28 0>, <0 29 0>, <0 30 0>, <0 31 0>,
<0 32 0>;
};
};
Example 3: A uart client node that supports 'default' and 'flow-control' states.
uart@13800000 {
compatible = "samsung,exynos4210-uart";
reg = <0x13800000 0x100>;
interrupts = <0 52 0>;
pinctrl-names = "default", "flow-control;
pinctrl-0 = <&uart0_data>;
pinctrl-1 = <&uart0_data &uart0_fctl>;
};
Example 4: Set up the default pin state for uart controller.
static int s3c24xx_serial_probe(struct platform_device *pdev) {
struct pinctrl *pinctrl;
...
...
pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
}

View File

@ -0,0 +1,25 @@
* Generic OPP Interface
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs.
Properties:
- operating-points: An array of 2-tuples items, and each item consists
of frequency and voltage like <freq-kHz vol-uV>.
freq: clock frequency in kHz
vol: voltage in microvolt
Examples:
cpu@0 {
compatible = "arm,cortex-a9";
reg = <0>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
};

View File

@ -11,7 +11,7 @@ Example:
pwm: pwm@80064000 {
compatible = "fsl,imx28-pwm", "fsl,imx23-pwm";
reg = <0x80064000 2000>;
reg = <0x80064000 0x2000>;
#pwm-cells = <2>;
fsl,pwm-number = <8>;
};

View File

@ -11,10 +11,13 @@ Optional properties:
- regulator-boot-on: bootloader/firmware enabled regulator
- <name>-supply: phandle to the parent supply/regulator node
- regulator-ramp-delay: ramp delay for regulator(in uV/uS)
Deprecated properties:
- regulator-compatible: If a regulator chip contains multiple
regulators, and if the chip's binding contains a child node that
describes each regulator, then this property indicates which regulator
this child node is intended to configure.
this child node is intended to configure. If this property is missing,
the node's name will be used instead.
Example:

View File

@ -22,66 +22,49 @@ Example:
compatible = "ti,tps65217";
regulators {
#address-cells = <1>;
#size-cells = <0>;
dcdc1_reg: regulator@0 {
reg = <0>;
regulator-compatible = "dcdc1";
dcdc1_reg: dcdc1 {
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1800000>;
regulator-boot-on;
regulator-always-on;
};
dcdc2_reg: regulator@1 {
reg = <1>;
regulator-compatible = "dcdc2";
dcdc2_reg: dcdc2 {
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
dcdc3_reg: regulator@2 {
reg = <2>;
regulator-compatible = "dcdc3";
dcdc3_reg: dcc3 {
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1500000>;
regulator-boot-on;
regulator-always-on;
};
ldo1_reg: regulator@3 {
reg = <3>;
regulator-compatible = "ldo1";
ldo1_reg: ldo1 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
ldo2_reg: regulator@4 {
reg = <4>;
regulator-compatible = "ldo2";
ldo2_reg: ldo2 {
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
ldo3_reg: regulator@5 {
reg = <5>;
regulator-compatible = "ldo3";
ldo3_reg: ldo3 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
ldo4_reg: regulator@6 {
reg = <6>;
regulator-compatible = "ldo4";
ldo4_reg: ldo4 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;

View File

@ -6,9 +6,13 @@ Required properties:
- interrupts: the interrupt outputs of the controller
- #gpio-cells: number of cells to describe a GPIO
- gpio-controller: mark the device as a GPIO controller
- regulators: list of regulators provided by this controller, must have
property "regulator-compatible" to match their hardware counterparts:
sm[0-2], ldo[0-9] and ldo_rtc
- regulators: A node that houses a sub-node for each regulator within the
device. Each sub-node is identified using the node's name (or the deprecated
regulator-compatible property if present), with valid values listed below.
The content of each sub-node is defined by the standard binding for
regulators; see regulator.txt.
sys, sm[0-2], ldo[0-9] and ldo_rtc
- sys-supply: The input supply for SYS.
- vin-sm0-supply: The input supply for the SM0.
- vin-sm1-supply: The input supply for the SM1.
- vin-sm2-supply: The input supply for the SM2.
@ -20,6 +24,9 @@ Required properties:
Each regulator is defined using the standard binding for regulators.
Note: LDO5 and LDO_RTC is supplied by SYS regulator internally and driver
take care of making proper parent child relationship.
Example:
pmu: tps6586x@34 {
@ -30,6 +37,7 @@ Example:
#gpio-cells = <2>;
gpio-controller;
sys-supply = <&some_reg>;
vin-sm0-supply = <&some_reg>;
vin-sm1-supply = <&some_reg>;
vin-sm2-supply = <&some_reg>;
@ -40,103 +48,80 @@ Example:
vinldo9-supply = <...>;
regulators {
#address-cells = <1>;
#size-cells = <0>;
sys_reg: sys {
regulator-name = "vdd_sys";
regulator-boot-on;
regulator-always-on;
};
sm0_reg: regulator@0 {
reg = <0>;
regulator-compatible = "sm0";
sm0_reg: sm0 {
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <1500000>;
regulator-boot-on;
regulator-always-on;
};
sm1_reg: regulator@1 {
reg = <1>;
regulator-compatible = "sm1";
sm1_reg: sm1 {
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <1500000>;
regulator-boot-on;
regulator-always-on;
};
sm2_reg: regulator@2 {
reg = <2>;
regulator-compatible = "sm2";
sm2_reg: sm2 {
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <4550000>;
regulator-boot-on;
regulator-always-on;
};
ldo0_reg: regulator@3 {
reg = <3>;
regulator-compatible = "ldo0";
ldo0_reg: ldo0 {
regulator-name = "PCIE CLK";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
ldo1_reg: regulator@4 {
reg = <4>;
regulator-compatible = "ldo1";
ldo1_reg: ldo1 {
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <1500000>;
};
ldo2_reg: regulator@5 {
reg = <5>;
regulator-compatible = "ldo2";
ldo2_reg: ldo2 {
regulator-min-microvolt = < 725000>;
regulator-max-microvolt = <1500000>;
};
ldo3_reg: regulator@6 {
reg = <6>;
regulator-compatible = "ldo3";
ldo3_reg: ldo3 {
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};
ldo4_reg: regulator@7 {
reg = <7>;
regulator-compatible = "ldo4";
ldo4_reg: ldo4 {
regulator-min-microvolt = <1700000>;
regulator-max-microvolt = <2475000>;
};
ldo5_reg: regulator@8 {
reg = <8>;
regulator-compatible = "ldo5";
ldo5_reg: ldo5 {
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};
ldo6_reg: regulator@9 {
reg = <9>;
regulator-compatible = "ldo6";
ldo6_reg: ldo6 {
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};
ldo7_reg: regulator@10 {
reg = <10>;
regulator-compatible = "ldo7";
ldo7_reg: ldo7 {
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};
ldo8_reg: regulator@11 {
reg = <11>;
regulator-compatible = "ldo8";
ldo8_reg: ldo8 {
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};
ldo9_reg: regulator@12 {
reg = <12>;
regulator-compatible = "ldo9";
ldo9_reg: ldo9 {
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3300000>;
};

View File

@ -0,0 +1,14 @@
* PXA RTC
PXA specific RTC driver.
Required properties:
- compatible : Should be "marvell,pxa-rtc"
Examples:
rtc@40900000 {
compatible = "marvell,pxa-rtc";
reg = <0x40900000 0x3c>;
interrupts = <30 31>;
};

View File

@ -0,0 +1,15 @@
VIA/Wondermedia VT8500 Realtime Clock Controller
-----------------------------------------------------
Required properties:
- compatible : "via,vt8500-rtc"
- reg : Should contain 1 register ranges(address and length)
- interrupts : alarm interrupt
Example:
rtc@d8100000 {
compatible = "via,vt8500-rtc";
reg = <0xd8100000 0x10000>;
interrupts = <48>;
};

View File

@ -0,0 +1,35 @@
* Freescale i.MX UART controller
Required properties:
- compatible : should be "fsl,imx21-uart"
- reg : Address and length of the register set for the device
- interrupts : Should contain UART interrupt number
Optional properties:
- fsl,uart-has-rtscts: indicate that RTS/CTS signals are used
Note: Each uart controller should have an alias correctly numbered
in "aliases" node.
Example:
- From imx51.dtsi:
aliases {
serial0 = &uart1;
serial1 = &uart2;
serial2 = &uart3;
};
uart1: serial@73fbc000 {
compatible = "fsl,imx51-uart", "fsl,imx21-uart";
reg = <0x73fbc000 0x4000>;
interrupts = <31>;
status = "disabled";
}
- From imx51-babbage.dts:
uart1: serial@73fbc000 {
fsl,uart-has-rtscts;
status = "okay";
};

View File

@ -0,0 +1,39 @@
* MOP500 Audio Machine Driver
This node is responsible for linking together all ux500 Audio Driver components.
Required properties:
- compatible : "stericsson,snd-soc-mop500"
Non-standard properties:
- stericsson,cpu-dai : Phandle to the CPU-side DAI
- stericsson,audio-codec : Phandle to the Audio CODEC
- stericsson,card-name : Over-ride default card name
Example:
sound {
compatible = "stericsson,snd-soc-mop500";
stericsson,cpu-dai = <&msp1 &msp3>;
stericsson,audio-codec = <&codec>;
};
msp1: msp@80124000 {
compatible = "stericsson,ux500-msp-i2s";
reg = <0x80124000 0x1000>;
interrupts = <0 62 0x4>;
v-ape-supply = <&db8500_vape_reg>;
};
msp3: msp@80125000 {
compatible = "stericsson,ux500-msp-i2s";
reg = <0x80125000 0x1000>;
interrupts = <0 62 0x4>;
v-ape-supply = <&db8500_vape_reg>;
};
codec: ab8500-codec {
compatible = "stericsson,ab8500-codec";
stericsson,earpeice-cmv = <950>; /* Units in mV. */
};

View File

@ -0,0 +1,43 @@
* ux500 MSP (CPU-side Digital Audio Interface)
Required properties:
- compatible :"stericsson,ux500-msp-i2s"
- reg : Physical base address and length of the device's registers.
Optional properties:
- interrupts : The interrupt output from the device.
- interrupt-parent : The parent interrupt controller.
- <name>-supply : Phandle to the regulator <name> supply
Example:
sound {
compatible = "stericsson,snd-soc-mop500";
stericsson,platform-pcm-dma = <&pcm>;
stericsson,cpu-dai = <&msp1 &msp3>;
stericsson,audio-codec = <&codec>;
};
pcm: ux500-pcm {
compatible = "stericsson,ux500-pcm";
};
msp1: msp@80124000 {
compatible = "stericsson,ux500-msp-i2s";
reg = <0x80124000 0x1000>;
interrupts = <0 62 0x4>;
v-ape-supply = <&db8500_vape_reg>;
};
msp3: msp@80125000 {
compatible = "stericsson,ux500-msp-i2s";
reg = <0x80125000 0x1000>;
interrupts = <0 62 0x4>;
v-ape-supply = <&db8500_vape_reg>;
};
codec: ab8500-codec {
compatible = "stericsson,ab8500-codec";
stericsson,earpeice-cmv = <950>; /* Units in mV. */
};

View File

@ -0,0 +1,22 @@
* Freescale MX233/MX28 SSP/SPI
Required properties:
- compatible: Should be "fsl,<soc>-spi", where soc is "imx23" or "imx28"
- reg: Offset and length of the register set for the device
- interrupts: Should contain SSP interrupts (error irq first, dma irq second)
- fsl,ssp-dma-channel: APBX DMA channel for the SSP
Optional properties:
- clock-frequency : Input clock frequency to the SPI block in Hz.
Default is 160000000 Hz.
Example:
ssp0: ssp@80010000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx28-spi";
reg = <0x80010000 0x2000>;
interrupts = <96 82>;
fsl,ssp-dma-channel = <0>;
};

View File

@ -21,6 +21,9 @@ assumption that board specific platform code will be used to manage
chip selects. Individual drivers can define additional properties to
support describing the chip select layout.
Optional property:
- num-cs : total number of chipselects
SPI slave nodes must be children of the SPI master node and can
contain the following properties.
- reg - (required) chip select address of device.

View File

@ -0,0 +1,29 @@
SPI-GPIO devicetree bindings
Required properties:
- compatible: should be set to "spi-gpio"
- #address-cells: should be set to <0x1>
- ranges
- gpio-sck: GPIO spec for the SCK line to use
- gpio-miso: GPIO spec for the MISO line to use
- gpio-mosi: GPIO spec for the MOSI line to use
- cs-gpios: GPIOs to use for chipselect lines
- num-chipselects: number of chipselect lines
Example:
spi {
compatible = "spi-gpio";
#address-cells = <0x1>;
ranges;
gpio-sck = <&gpio 95 0>;
gpio-miso = <&gpio 98 0>;
gpio-mosi = <&gpio 97 0>;
cs-gpios = <&gpio 125 0>;
num-chipselects = <1>;
/* clients */
};

View File

@ -0,0 +1,23 @@
NXP SC18IS602/SCIS603
Required properties:
- compatible : Should be one of
"nxp,sc18is602"
"nxp,sc18is602b"
"nxp,sc18is603"
- reg: I2C bus address
Optional properties:
- clock-frequency : external oscillator clock frequency. If not
specified, the SC18IS602 default frequency (7372000) will be used.
The clock-frequency property is relevant and needed only if the chip has an
external oscillator (SC18IS603).
Example:
sc18is603@28 {
compatible = "nxp,sc18is603";
reg = <0x28>;
clock-frequency = <14744000>;
}

View File

@ -6,7 +6,29 @@ Required properties:
- interrupts : Should contain SPI controller interrupt
Optional properties:
- num-cs : total number of chipselects
- cs-gpios : should specify GPIOs used for chipselects.
The gpios will be referred to as reg = <index> in the SPI child nodes.
If unspecified, a single SPI device without a chip select can be used.
- pl022,autosuspend-delay : delay in ms following transfer completion before
the runtime power management system suspends the
device. A setting of 0 indicates no delay and the
device will be suspended immediately
- pl022,rt : indicates the controller should run the message pump with realtime
priority to minimise the transfer latency on the bus (boolean)
SPI slave nodes must be children of the SPI master node and can
contain the following properties.
- pl022,interface : interface type:
0: SPI
1: Texas Instruments Synchronous Serial Frame Format
2: Microwire (Half Duplex)
- pl022,com-mode : polling, interrupt or dma
- pl022,rx-level-trig : Rx FIFO watermark level
- pl022,tx-level-trig : Tx FIFO watermark level
- pl022,ctrl-len : Microwire interface: Control length
- pl022,wait-state : Microwire interface: Wait state
- pl022,duplex : Microwire interface: Full/Half duplex

View File

@ -0,0 +1,15 @@
* Freescale i.MX28 LRADC device driver
Required properties:
- compatible: Should be "fsl,imx28-lradc"
- reg: Address and length of the register set for the device
- interrupts: Should contain the LRADC interrupts
Examples:
lradc@80050000 {
compatible = "fsl,imx28-lradc";
reg = <0x80050000 0x2000>;
interrupts = <10 14 15 16 17 18 19
20 21 22 23 24 25>;
};

View File

@ -0,0 +1,41 @@
Freescale i.MX IPUv3
====================
Required properties:
- compatible: Should be "fsl,<chip>-ipu"
- reg: should be register base and length as documented in the
datasheet
- interrupts: Should contain sync interrupt and error interrupt,
in this order.
- #crtc-cells: 1, See below
example:
ipu: ipu@18000000 {
#crtc-cells = <1>;
compatible = "fsl,imx53-ipu";
reg = <0x18000000 0x080000000>;
interrupts = <11 10>;
};
Parallel display support
========================
Required properties:
- compatible: Should be "fsl,imx-parallel-display"
- crtc: the crtc this display is connected to, see below
Optional properties:
- interface_pix_fmt: How this display is connected to the
crtc. Currently supported types: "rgb24", "rgb565"
- edid: verbatim EDID data block describing attached display.
- ddc: phandle describing the i2c bus handling the display data
channel
example:
display@di0 {
compatible = "fsl,imx-parallel-display";
edid = [edid-data];
crtc = <&ipu 0>;
interface-pix-fmt = "rgb24";
};

View File

@ -0,0 +1,22 @@
BCM2835 System Timer
The System Timer peripheral provides four 32-bit timer channels and a
single 64-bit free running counter. Each channel has an output compare
register, which is compared against the 32 least significant bits of the
free running counter values, and generates an interrupt.
Required properties:
- compatible : should be "brcm,bcm2835-system-timer.txt"
- reg : Specifies base physical address and size of the registers.
- interrupts : A list of 4 interrupt sinks; one per timer channel.
- clock-frequency : The frequency of the clock that drives the counter, in Hz.
Example:
timer {
compatible = "brcm,bcm2835-system-timer";
reg = <0x7e003000 0x1000>;
interrupts = <1 0>, <1 1>, <1 2>, <1 3>;
clock-frequency = <1000000>;
};

View File

@ -0,0 +1,14 @@
* NXP LPC32xx SoC High Speed UART
Required properties:
- compatible: Should be "nxp,lpc3220-hsuart"
- reg: Should contain registers location and length
- interrupts: Should contain interrupt
Example:
uart1: serial@40014000 {
compatible = "nxp,lpc3220-hsuart";
reg = <0x40014000 0x1000>;
interrupts = <26 0>;
};

View File

@ -25,6 +25,8 @@ Optional properties:
accesses to the UART (e.g. TI davinci).
- used-by-rtas : set to indicate that the port is in use by the OpenFirmware
RTAS and should not be registered.
- no-loopback-test: set to indicate that the port does not implements loopback
test mode
Example:

View File

@ -0,0 +1,17 @@
VIA/Wondermedia VT8500 UART Controller
-----------------------------------------------------
Required properties:
- compatible : "via,vt8500-uart"
- reg : Should contain 1 register ranges(address and length)
- interrupts : UART interrupt
- clocks : phandle to the uart source clock (usually a 24Mhz fixed clock)
Example:
uart@d8210000 {
compatible = "via,vt8500-uart";
reg = <0xd8210000 0x1040>;
interrupts = <47>;
clocks = <&ref24>;
};

View File

@ -0,0 +1,14 @@
AM33XX MUSB GLUE
- compatible : Should be "ti,musb-am33xx"
- ti,hwmods : must be "usb_otg_hs"
- multipoint : Should be "1" indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
- num_eps : Specifies the number of endpoints. This is also a
MUSB configuration-specific setting. Should be set to "16"
- ram_bits : Specifies the ram address size. Should be set to "12"
- port0_mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
represents PERIPHERAL.
- port1_mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
represents PERIPHERAL.
- power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.

View File

@ -7,7 +7,10 @@ Required properties:
Optional properties:
- fsl,usbphy: phandler of usb phy that connects to the only one port
- fsl,usbmisc: phandler of non-core register device, with one argument
that indicate usb controller index
- vbus-supply: regulator for vbus
- disable-over-current: disable over current detect
Examples:
usb@02184000 { /* USB OTG */
@ -15,4 +18,6 @@ usb@02184000 { /* USB OTG */
reg = <0x02184000 0x200>;
interrupts = <0 43 0x04>;
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
disable-over-current;
};

View File

@ -0,0 +1,33 @@
OMAP GLUE
OMAP MUSB GLUE
- compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
- ti,hwmods : must be "usb_otg_hs"
- multipoint : Should be "1" indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
- num_eps : Specifies the number of endpoints. This is also a
MUSB configuration-specific setting. Should be set to "16"
- ram_bits : Specifies the ram address size. Should be set to "12"
- interface_type : This is a board specific setting to describe the type of
interface between the controller and the phy. It should be "0" or "1"
specifying ULPI and UTMI respectively.
- mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
represents PERIPHERAL.
- power : Should be "50". This signifies the controller can supply upto
100mA when operating in host mode.
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = "ti,omap4-musb";
ti,hwmods = "usb_otg_hs";
multipoint = <1>;
num_eps = <16>;
ram_bits = <12>;
};
Board specific device node entry
&usb_otg_hs {
interface_type = <1>;
mode = <3>;
power = <50>;
};

View File

@ -0,0 +1,15 @@
Generic Platform UHCI Controller
-----------------------------------------------------
Required properties:
- compatible : "platform-uhci"
- reg : Should contain 1 register ranges(address and length)
- interrupts : UHCI controller interrupt
Example:
uhci@d8007b00 {
compatible = "platform-uhci";
reg = <0xd8007b00 0x200>;
interrupts = <43>;
};

View File

@ -0,0 +1,31 @@
PXA USB controllers
OHCI
Required properties:
- compatible: Should be "marvell,pxa-ohci" for USB controllers
used in host mode.
Optional properties:
- "marvell,enable-port1", "marvell,enable-port2", "marvell,enable-port3"
If present, enables the appropriate USB port of the controller.
- "marvell,port-mode" selects the mode of the ports:
1 = PMM_NPS_MODE
2 = PMM_GLOBAL_MODE
3 = PMM_PERPORT_MODE
- "marvell,power-sense-low" - power sense pin is low-active.
- "marvell,power-control-low" - power control pin is low-active.
- "marvell,no-oc-protection" - disable over-current protection.
- "marvell,oc-mode-perport" - enable per-port over-current protection.
- "marvell,power_on_delay" Power On to Power Good time - in ms.
Example:
usb0: ohci@4c000000 {
compatible = "marvell,pxa-ohci", "usb-ohci";
reg = <0x4c000000 0x100000>;
interrupts = <18>;
marvell,enable-port1;
marvell,port-mode = <2>; /* PMM_GLOBAL_MODE */
};

View File

@ -0,0 +1,40 @@
USB COMPARATOR OF TWL CHIPS
TWL6030 USB COMPARATOR
- compatible : Should be "ti,twl6030-usb"
- interrupts : Two interrupt numbers to the cpu should be specified. First
interrupt number is the otg interrupt number that raises ID interrupts when
the controller has to act as host and the second interrupt number is the
usb interrupt number that raises VBUS interrupts when the controller has to
act as device
- usb-supply : phandle to the regulator device tree node. It should be vusb
if it is twl6030 or ldousb if it is twl6025 subclass.
twl6030-usb {
compatible = "ti,twl6030-usb";
interrupts = < 4 10 >;
};
Board specific device node entry
&twl6030-usb {
usb-supply = <&vusb>;
};
TWL4030 USB PHY AND COMPARATOR
- compatible : Should be "ti,twl4030-usb"
- interrupts : The interrupt numbers to the cpu should be specified. First
interrupt number is the otg interrupt number that raises ID interrupts
and VBUS interrupts. The second interrupt number is optional.
- <supply-name>-supply : phandle to the regulator device tree node.
<supply-name> should be vusb1v5, vusb1v8 and vusb3v1
- usb_mode : The mode used by the phy to connect to the controller. "1"
specifies "ULPI" mode and "2" specifies "CEA2011_3PIN" mode.
twl4030-usb {
compatible = "ti,twl4030-usb";
interrupts = < 10 4 >;
usb1v5-supply = <&vusb1v5>;
usb1v8-supply = <&vusb1v8>;
usb3v1-supply = <&vusb3v1>;
usb_mode = <1>;
};

View File

@ -0,0 +1,17 @@
USB PHY
OMAP USB2 PHY
Required properties:
- compatible: Should be "ti,omap-usb2"
- reg : Address and length of the register set for the device. Also
add the address of control module dev conf register until a driver for
control module is added
This is usually a subnode of ocp2scp to which it is connected.
usb2phy@4a0ad080 {
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>,
<0x4a002300 0x4>;
};

Some files were not shown because too many files have changed in this diff Show More