mirror of https://gitee.com/openkylin/linux.git
Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
There's a Niagara 2 memcpy fix in this tree and I have a Kconfig fix from Dave Jones which requires the sparc-next changes which went upstream yesterday. Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
David S. Miller
commit
954f9ac43b
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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));
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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"
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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 */
|
||||
};
|
||||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
...
|
||||
|
|
@ -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;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
||||
}
|
||||
|
|
@ -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;
|
||||
};
|
||||
|
|
@ -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;
|
||||
};
|
||||
|
|
@ -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";
|
||||
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
||||
|
|
@ -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) */
|
||||
};
|
||||
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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 ];
|
||||
};
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
}
|
||||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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. */
|
||||
};
|
||||
|
|
@ -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. */
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 */
|
||||
};
|
||||
|
||||
|
|
@ -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>;
|
||||
}
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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.
|
||||
|
|
@ -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;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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 */
|
||||
};
|
||||
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
* Freescale i.MX non-core registers
|
||||
|
||||
Required properties:
|
||||
- #index-cells: Cells used to descibe usb controller index. Should be <1>
|
||||
- compatible: Should be one of below:
|
||||
"fsl,imx6q-usbmisc" for imx6q
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
Examples:
|
||||
usbmisc@02184800 {
|
||||
#index-cells = <1>;
|
||||
compatible = "fsl,imx6q-usbmisc";
|
||||
reg = <0x02184800 0x200>;
|
||||
};
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
VIA/Wondermedia VT8500 EHCI Controller
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "via,vt8500-ehci"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- interrupts : ehci controller interrupt
|
||||
|
||||
Example:
|
||||
|
||||
ehci@d8007900 {
|
||||
compatible = "via,vt8500-ehci";
|
||||
reg = <0xd8007900 0x200>;
|
||||
interrupts = <43>;
|
||||
};
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
VIA VT8500 and Wondermedia WM8xxx SoC USB controllers.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "via,vt8500-ehci" or "wm,prizm-ehci".
|
||||
- reg: Address range of the ehci registers. size should be 0x200
|
||||
- interrupts: Should contain the ehci interrupt.
|
||||
|
||||
usb: ehci@D8007100 {
|
||||
compatible = "wm,prizm-ehci", "usb-ehci";
|
||||
reg = <0xD8007100 0x200>;
|
||||
interrupts = <1>;
|
||||
};
|
||||
|
|
@ -10,6 +10,7 @@ apm Applied Micro Circuits Corporation (APM)
|
|||
arm ARM Ltd.
|
||||
atmel Atmel Corporation
|
||||
bosch Bosch Sensortec GmbH
|
||||
brcm Broadcom Corporation
|
||||
cavium Cavium, Inc.
|
||||
chrp Common Hardware Reference Platform
|
||||
cortina Cortina Systems, Inc.
|
||||
|
|
@ -47,5 +48,7 @@ sirf SiRF Technology, Inc.
|
|||
st STMicroelectronics
|
||||
stericsson ST-Ericsson
|
||||
ti Texas Instruments
|
||||
via VIA Technologies, Inc.
|
||||
wlf Wolfson Microelectronics
|
||||
wm Wondermedia Technologies, Inc.
|
||||
xlnx Xilinx
|
||||
|
|
|
|||
|
|
@ -0,0 +1,62 @@
|
|||
VIA VT8500 Framebuffer
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "via,vt8500-fb"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- interrupts : framebuffer controller interrupt
|
||||
- display: a phandle pointing to the display node
|
||||
|
||||
Required nodes:
|
||||
- display: a display node is required to initialize the lcd panel
|
||||
This should be in the board dts.
|
||||
- default-mode: a videomode within the display with timing parameters
|
||||
as specified below.
|
||||
|
||||
Example:
|
||||
|
||||
fb@d800e400 {
|
||||
compatible = "via,vt8500-fb";
|
||||
reg = <0xd800e400 0x400>;
|
||||
interrupts = <12>;
|
||||
display = <&display>;
|
||||
default-mode = <&mode0>;
|
||||
};
|
||||
|
||||
VIA VT8500 Display
|
||||
-----------------------------------------------------
|
||||
Required properties (as per of_videomode_helper):
|
||||
|
||||
- hactive, vactive: Display resolution
|
||||
- hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
|
||||
in pixels
|
||||
vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
|
||||
lines
|
||||
- clock: displayclock in Hz
|
||||
- bpp: lcd panel bit-depth.
|
||||
<16> for RGB565, <32> for RGB888
|
||||
|
||||
Optional properties (as per of_videomode_helper):
|
||||
- width-mm, height-mm: Display dimensions in mm
|
||||
- hsync-active-high (bool): Hsync pulse is active high
|
||||
- vsync-active-high (bool): Vsync pulse is active high
|
||||
- interlaced (bool): This is an interlaced mode
|
||||
- doublescan (bool): This is a doublescan mode
|
||||
|
||||
Example:
|
||||
display: display@0 {
|
||||
modes {
|
||||
mode0: mode@0 {
|
||||
hactive = <800>;
|
||||
vactive = <480>;
|
||||
hback-porch = <88>;
|
||||
hfront-porch = <40>;
|
||||
hsync-len = <0>;
|
||||
vback-porch = <32>;
|
||||
vfront-porch = <11>;
|
||||
vsync-len = <1>;
|
||||
clock = <0>; /* unused but required */
|
||||
bpp = <16>; /* non-standard but required */
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
VIA/Wondermedia Graphics Engine Controller
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "wm,prizm-ge-rops"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
|
||||
Example:
|
||||
|
||||
ge_rops@d8050400 {
|
||||
compatible = "wm,prizm-ge-rops";
|
||||
reg = <0xd8050400 0x100>;
|
||||
};
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
Wondermedia WM8505 Framebuffer
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : "wm,wm8505-fb"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- via,display: a phandle pointing to the display node
|
||||
|
||||
Required nodes:
|
||||
- display: a display node is required to initialize the lcd panel
|
||||
This should be in the board dts. See definition in
|
||||
Documentation/devicetree/bindings/video/via,vt8500-fb.txt
|
||||
- default-mode: a videomode node as specified in
|
||||
Documentation/devicetree/bindings/video/via,vt8500-fb.txt
|
||||
|
||||
Example:
|
||||
|
||||
fb@d8050800 {
|
||||
compatible = "wm,wm8505-fb";
|
||||
reg = <0xd8050800 0x200>;
|
||||
display = <&display>;
|
||||
default-mode = <&mode0>;
|
||||
};
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
w1-gpio devicetree bindings
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "w1-gpio"
|
||||
- gpios: one or two GPIO specs:
|
||||
- the first one is used as data I/O pin
|
||||
- the second one is optional. If specified, it is used as
|
||||
enable pin for an external pin pullup.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- linux,open-drain: if specified, the data pin is considered in
|
||||
open-drain mode.
|
||||
|
||||
Examples:
|
||||
|
||||
onewire@0 {
|
||||
compatible = "w1-gpio";
|
||||
gpios = <&gpio 126 0>, <&gpio 105 0>;
|
||||
};
|
||||
|
||||
|
|
@ -162,7 +162,6 @@ mach-types.h
|
|||
machtypes.h
|
||||
map
|
||||
map_hugetlb
|
||||
maui_boot.h
|
||||
media
|
||||
mconf
|
||||
miboot*
|
||||
|
|
|
|||
|
|
@ -1,639 +0,0 @@
|
|||
The following is a list of files and features that are going to be
|
||||
removed in the kernel source tree. Every entry should contain what
|
||||
exactly is going away, why it is happening, and who is going to be doing
|
||||
the work. When the feature is removed from the kernel, it should also
|
||||
be removed from this file. The suggested deprecation period is 3 releases.
|
||||
|
||||
---------------------------
|
||||
|
||||
What: ddebug_query="query" boot cmdline param
|
||||
When: v3.8
|
||||
Why: obsoleted by dyndbg="query" and module.dyndbg="query"
|
||||
Who: Jim Cromie <jim.cromie@gmail.com>, Jason Baron <jbaron@redhat.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /proc/sys/vm/nr_pdflush_threads
|
||||
When: 2012
|
||||
Why: Since pdflush is deprecated, the interface exported in /proc/sys/vm/
|
||||
should be removed.
|
||||
Who: Wanpeng Li <liwp@linux.vnet.ibm.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
|
||||
When: 2012
|
||||
Why: This optional sub-feature of APM is of dubious reliability,
|
||||
and ancient APM laptops are likely better served by calling HLT.
|
||||
Deleting CONFIG_APM_CPU_IDLE allows x86 to stop exporting
|
||||
the pm_idle function pointer to modules.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: x86_32 "no-hlt" cmdline param
|
||||
When: 2012
|
||||
Why: remove a branch from idle path, simplify code used by everybody.
|
||||
This option disabled the use of HLT in idle and machine_halt()
|
||||
for hardware that was flakey 15-years ago. Today we have
|
||||
"idle=poll" that removed HLT from idle, and so if such a machine
|
||||
is still running the upstream kernel, "idle=poll" is likely sufficient.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: x86 "idle=mwait" cmdline param
|
||||
When: 2012
|
||||
Why: simplify x86 idle code
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: PRISM54
|
||||
When: 2.6.34
|
||||
|
||||
Why: prism54 FullMAC PCI / Cardbus devices used to be supported only by the
|
||||
prism54 wireless driver. After Intersil stopped selling these
|
||||
devices in preference for the newer more flexible SoftMAC devices
|
||||
a SoftMAC device driver was required and prism54 did not support
|
||||
them. The p54pci driver now exists and has been present in the kernel for
|
||||
a while. This driver supports both SoftMAC devices and FullMAC devices.
|
||||
The main difference between these devices was the amount of memory which
|
||||
could be used for the firmware. The SoftMAC devices support a smaller
|
||||
amount of memory. Because of this the SoftMAC firmware fits into FullMAC
|
||||
devices's memory. p54pci supports not only PCI / Cardbus but also USB
|
||||
and SPI. Since p54pci supports all devices prism54 supports
|
||||
you will have a conflict. I'm not quite sure how distributions are
|
||||
handling this conflict right now. prism54 was kept around due to
|
||||
claims users may experience issues when using the SoftMAC driver.
|
||||
Time has passed users have not reported issues. If you use prism54
|
||||
and for whatever reason you cannot use p54pci please let us know!
|
||||
E-mail us at: linux-wireless@vger.kernel.org
|
||||
|
||||
For more information see the p54 wiki page:
|
||||
|
||||
http://wireless.kernel.org/en/users/Drivers/p54
|
||||
|
||||
Who: Luis R. Rodriguez <lrodriguez@atheros.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: The ieee80211_regdom module parameter
|
||||
When: March 2010 / desktop catchup
|
||||
|
||||
Why: This was inherited by the CONFIG_WIRELESS_OLD_REGULATORY code,
|
||||
and currently serves as an option for users to define an
|
||||
ISO / IEC 3166 alpha2 code for the country they are currently
|
||||
present in. Although there are userspace API replacements for this
|
||||
through nl80211 distributions haven't yet caught up with implementing
|
||||
decent alternatives through standard GUIs. Although available as an
|
||||
option through iw or wpa_supplicant its just a matter of time before
|
||||
distributions pick up good GUI options for this. The ideal solution
|
||||
would actually consist of intelligent designs which would do this for
|
||||
the user automatically even when travelling through different countries.
|
||||
Until then we leave this module parameter as a compromise.
|
||||
|
||||
When userspace improves with reasonable widely-available alternatives for
|
||||
this we will no longer need this module parameter. This entry hopes that
|
||||
by the super-futuristically looking date of "March 2010" we will have
|
||||
such replacements widely available.
|
||||
|
||||
Who: Luis R. Rodriguez <lrodriguez@atheros.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: dev->power.power_state
|
||||
When: July 2007
|
||||
Why: Broken design for runtime control over driver power states, confusing
|
||||
driver-internal runtime power management with: mechanisms to support
|
||||
system-wide sleep state transitions; event codes that distinguish
|
||||
different phases of swsusp "sleep" transitions; and userspace policy
|
||||
inputs. This framework was never widely used, and most attempts to
|
||||
use it were broken. Drivers should instead be exposing domain-specific
|
||||
interfaces either to kernel or to userspace.
|
||||
Who: Pavel Machek <pavel@ucw.cz>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /proc/<pid>/oom_adj
|
||||
When: August 2012
|
||||
Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
|
||||
badness heuristic used to determine which task to kill when the kernel
|
||||
is out of memory.
|
||||
|
||||
The badness heuristic has since been rewritten since the introduction of
|
||||
this tunable such that its meaning is deprecated. The value was
|
||||
implemented as a bitshift on a score generated by the badness()
|
||||
function that did not have any precise units of measure. With the
|
||||
rewrite, the score is given as a proportion of available memory to the
|
||||
task allocating pages, so using a bitshift which grows the score
|
||||
exponentially is, thus, impossible to tune with fine granularity.
|
||||
|
||||
A much more powerful interface, /proc/<pid>/oom_score_adj, was
|
||||
introduced with the oom killer rewrite that allows users to increase or
|
||||
decrease the badness score linearly. This interface will replace
|
||||
/proc/<pid>/oom_adj.
|
||||
|
||||
A warning will be emitted to the kernel log if an application uses this
|
||||
deprecated interface. After it is printed once, future warnings will be
|
||||
suppressed until the kernel is rebooted.
|
||||
|
||||
---------------------------
|
||||
|
||||
What: remove EXPORT_SYMBOL(kernel_thread)
|
||||
When: August 2006
|
||||
Files: arch/*/kernel/*_ksyms.c
|
||||
Check: kernel_thread
|
||||
Why: kernel_thread is a low-level implementation detail. Drivers should
|
||||
use the <linux/kthread.h> API instead which shields them from
|
||||
implementation details and provides a higherlevel interface that
|
||||
prevents bugs and code duplication
|
||||
Who: Christoph Hellwig <hch@lst.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
|
||||
(temporary transition config option provided until then)
|
||||
The transition config option will also be removed at the same time.
|
||||
When: before 2.6.19
|
||||
Why: Unused symbols are both increasing the size of the kernel binary
|
||||
and are often a sign of "wrong API"
|
||||
Who: Arjan van de Ven <arjan@linux.intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
|
||||
When: October 2008
|
||||
Why: The stacking of class devices makes these values misleading and
|
||||
inconsistent.
|
||||
Class devices should not carry any of these properties, and bus
|
||||
devices have SUBSYTEM and DRIVER as a replacement.
|
||||
Who: Kay Sievers <kay.sievers@suse.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: ACPI procfs interface
|
||||
When: July 2008
|
||||
Why: ACPI sysfs conversion should be finished by January 2008.
|
||||
ACPI procfs interface will be removed in July 2008 so that
|
||||
there is enough time for the user space to catch up.
|
||||
Who: Zhang Rui <rui.zhang@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_ACPI_PROCFS_POWER
|
||||
When: 2.6.39
|
||||
Why: sysfs I/F for ACPI power devices, including AC and Battery,
|
||||
has been working in upstream kernel since 2.6.24, Sep 2007.
|
||||
In 2.6.37, we make the sysfs I/F always built in and this option
|
||||
disabled by default.
|
||||
Remove this option and the ACPI power procfs interface in 2.6.39.
|
||||
Who: Zhang Rui <rui.zhang@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /proc/acpi/event
|
||||
When: February 2008
|
||||
Why: /proc/acpi/event has been replaced by events via the input layer
|
||||
and netlink since 2.6.23.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: i386/x86_64 bzImage symlinks
|
||||
When: April 2010
|
||||
|
||||
Why: The i386/x86_64 merge provides a symlink to the old bzImage
|
||||
location so not yet updated user space tools, e.g. package
|
||||
scripts, do not break.
|
||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: GPIO autorequest on gpio_direction_{input,output}() in gpiolib
|
||||
When: February 2010
|
||||
Why: All callers should use explicit gpio_request()/gpio_free().
|
||||
The autorequest mechanism in gpiolib was provided mostly as a
|
||||
migration aid for legacy GPIO interfaces (for SOC based GPIOs).
|
||||
Those users have now largely migrated. Platforms implementing
|
||||
the GPIO interfaces without using gpiolib will see no changes.
|
||||
Who: David Brownell <dbrownell@users.sourceforge.net>
|
||||
---------------------------
|
||||
|
||||
What: b43 support for firmware revision < 410
|
||||
When: The schedule was July 2008, but it was decided that we are going to keep the
|
||||
code as long as there are no major maintanance headaches.
|
||||
So it _could_ be removed _any_ time now, if it conflicts with something new.
|
||||
Why: The support code for the old firmware hurts code readability/maintainability
|
||||
and slightly hurts runtime performance. Bugfixes for the old firmware
|
||||
are not provided by Broadcom anymore.
|
||||
Who: Michael Buesch <m@bues.ch>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Ability for non root users to shm_get hugetlb pages based on mlock
|
||||
resource limits
|
||||
When: 2.6.31
|
||||
Why: Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or
|
||||
have CAP_IPC_LOCK to be able to allocate shm segments backed by
|
||||
huge pages. The mlock based rlimit check to allow shm hugetlb is
|
||||
inconsistent with mmap based allocations. Hence it is being
|
||||
deprecated.
|
||||
Who: Ravikiran Thirumalai <kiran@scalex86.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: sysfs ui for changing p4-clockmod parameters
|
||||
When: September 2009
|
||||
Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
|
||||
e088e4c9cdb618675874becb91b2fd581ee707e6.
|
||||
Removal is subject to fixing any remaining bugs in ACPI which may
|
||||
cause the thermal throttling not to happen at the right time.
|
||||
Who: Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com>
|
||||
|
||||
-----------------------------
|
||||
|
||||
What: fakephp and associated sysfs files in /sys/bus/pci/slots/
|
||||
When: 2011
|
||||
Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
|
||||
represent a machine's physical PCI slots. The change in semantics
|
||||
had userspace implications, as the hotplug core no longer allowed
|
||||
drivers to create multiple sysfs files per physical slot (required
|
||||
for multi-function devices, e.g.). fakephp was seen as a developer's
|
||||
tool only, and its interface changed. Too late, we learned that
|
||||
there were some users of the fakephp interface.
|
||||
|
||||
In 2.6.30, the original fakephp interface was restored. At the same
|
||||
time, the PCI core gained the ability that fakephp provided, namely
|
||||
function-level hot-remove and hot-add.
|
||||
|
||||
Since the PCI core now provides the same functionality, exposed in:
|
||||
|
||||
/sys/bus/pci/rescan
|
||||
/sys/bus/pci/devices/.../remove
|
||||
/sys/bus/pci/devices/.../rescan
|
||||
|
||||
there is no functional reason to maintain fakephp as well.
|
||||
|
||||
We will keep the existing module so that 'modprobe fakephp' will
|
||||
present the old /sys/bus/pci/slots/... interface for compatibility,
|
||||
but users are urged to migrate their applications to the API above.
|
||||
|
||||
After a reasonable transition period, we will remove the legacy
|
||||
fakephp interface.
|
||||
Who: Alex Chiang <achiang@hp.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_RFKILL_INPUT
|
||||
When: 2.6.33
|
||||
Why: Should be implemented in userspace, policy daemon.
|
||||
Who: Johannes Berg <johannes@sipsolutions.net>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: sound-slot/service-* module aliases and related clutters in
|
||||
sound/sound_core.c
|
||||
When: August 2010
|
||||
Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR
|
||||
(14) and requests modules using custom sound-slot/service-*
|
||||
module aliases. The only benefit of doing this is allowing
|
||||
use of custom module aliases which might as well be considered
|
||||
a bug at this point. This preemptive claiming prevents
|
||||
alternative OSS implementations.
|
||||
|
||||
Till the feature is removed, the kernel will be requesting
|
||||
both sound-slot/service-* and the standard char-major-* module
|
||||
aliases and allow turning off the pre-claiming selectively via
|
||||
CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss
|
||||
kernel parameter.
|
||||
|
||||
After the transition phase is complete, both the custom module
|
||||
aliases and switches to disable it will go away. This removal
|
||||
will also allow making ALSA OSS emulation independent of
|
||||
sound_core. The dependency will be broken then too.
|
||||
Who: Tejun Heo <tj@kernel.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: sysfs-class-rfkill state file
|
||||
When: Feb 2014
|
||||
Files: net/rfkill/core.c
|
||||
Why: Documented as obsolete since Feb 2010. This file is limited to 3
|
||||
states while the rfkill drivers can have 4 states.
|
||||
Who: anybody or Florian Mickler <florian@mickler.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: sysfs-class-rfkill claim file
|
||||
When: Feb 2012
|
||||
Files: net/rfkill/core.c
|
||||
Why: It is not possible to claim an rfkill driver since 2007. This is
|
||||
Documented as obsolete since Feb 2010.
|
||||
Who: anybody or Florian Mickler <florian@mickler.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: iwlwifi 50XX module parameters
|
||||
When: 3.0
|
||||
Why: The "..50" modules parameters were used to configure 5000 series and
|
||||
up devices; different set of module parameters also available for 4965
|
||||
with same functionalities. Consolidate both set into single place
|
||||
in drivers/net/wireless/iwlwifi/iwl-agn.c
|
||||
|
||||
Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: iwl4965 alias support
|
||||
When: 3.0
|
||||
Why: Internal alias support has been present in module-init-tools for some
|
||||
time, the MODULE_ALIAS("iwl4965") boilerplate aliases can be removed
|
||||
with no impact.
|
||||
|
||||
Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: xt_NOTRACK
|
||||
Files: net/netfilter/xt_NOTRACK.c
|
||||
When: April 2011
|
||||
Why: Superseded by xt_CT
|
||||
Who: Netfilter developer team <netfilter-devel@vger.kernel.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: IRQF_DISABLED
|
||||
When: 2.6.36
|
||||
Why: The flag is a NOOP as we run interrupt handlers with interrupts disabled
|
||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: PCI DMA unmap state API
|
||||
When: August 2012
|
||||
Why: PCI DMA unmap state API (include/linux/pci-dma.h) was replaced
|
||||
with DMA unmap state API (DMA unmap state API can be used for
|
||||
any bus).
|
||||
Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: iwlwifi disable_hw_scan module parameters
|
||||
When: 3.0
|
||||
Why: Hareware scan is the prefer method for iwlwifi devices for
|
||||
scanning operation. Remove software scan support for all the
|
||||
iwlwifi devices.
|
||||
|
||||
Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Legacy, non-standard chassis intrusion detection interface.
|
||||
When: June 2011
|
||||
Why: The adm9240, w83792d and w83793 hardware monitoring drivers have
|
||||
legacy interfaces for chassis intrusion detection. A standard
|
||||
interface has been added to each driver, so the legacy interface
|
||||
can be removed.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: i2c_driver.attach_adapter
|
||||
i2c_driver.detach_adapter
|
||||
When: September 2011
|
||||
Why: These legacy callbacks should no longer be used as i2c-core offers
|
||||
a variety of preferable alternative ways to instantiate I2C devices.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Opening a radio device node will no longer automatically switch the
|
||||
tuner mode from tv to radio.
|
||||
When: 3.3
|
||||
Why: Just opening a V4L device should not change the state of the hardware
|
||||
like that. It's very unexpected and against the V4L spec. Instead, you
|
||||
switch to radio mode by calling VIDIOC_S_FREQUENCY. This is the second
|
||||
and last step of the move to consistent handling of tv and radio tuners.
|
||||
Who: Hans Verkuil <hans.verkuil@cisco.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: CONFIG_CFG80211_WEXT
|
||||
When: as soon as distributions ship new wireless tools, ie. wpa_supplicant 1.0
|
||||
and NetworkManager/connman/etc. that are able to use nl80211
|
||||
Why: Wireless extensions are deprecated, and userland tools are moving to
|
||||
using nl80211. New drivers are no longer using wireless extensions,
|
||||
and while there might still be old drivers, both new drivers and new
|
||||
userland no longer needs them and they can't be used for an feature
|
||||
developed in the past couple of years. As such, compatibility with
|
||||
wireless extensions in new drivers will be removed.
|
||||
Who: Johannes Berg <johannes@sipsolutions.net>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: g_file_storage driver
|
||||
When: 3.8
|
||||
Why: This driver has been superseded by g_mass_storage.
|
||||
Who: Alan Stern <stern@rowland.harvard.edu>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: threeg and interface sysfs files in /sys/devices/platform/acer-wmi
|
||||
When: 2012
|
||||
Why: In 3.0, we can now autodetect internal 3G device and already have
|
||||
the threeg rfkill device. So, we plan to remove threeg sysfs support
|
||||
for it's no longer necessary.
|
||||
|
||||
We also plan to remove interface sysfs file that exposed which ACPI-WMI
|
||||
interface that was used by acer-wmi driver. It will replaced by
|
||||
information log when acer-wmi initial.
|
||||
Who: Lee, Chun-Yi <jlee@novell.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /sys/devices/platform/_UDC_/udc/_UDC_/is_dualspeed file and
|
||||
is_dualspeed line in /sys/devices/platform/ci13xxx_*/udc/device file.
|
||||
When: 3.8
|
||||
Why: The is_dualspeed file is superseded by maximum_speed in the same
|
||||
directory and is_dualspeed line in device file is superseded by
|
||||
max_speed line in the same file.
|
||||
|
||||
The maximum_speed/max_speed specifies maximum speed supported by UDC.
|
||||
To check if dualspeeed is supported, check if the value is >= 3.
|
||||
Various possible speeds are defined in <linux/usb/ch9.h>.
|
||||
Who: Michal Nazarewicz <mina86@mina86.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: The XFS nodelaylog mount option
|
||||
When: 3.3
|
||||
Why: The delaylog mode that has been the default since 2.6.39 has proven
|
||||
stable, and the old code is in the way of additional improvements in
|
||||
the log code.
|
||||
Who: Christoph Hellwig <hch@lst.de>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: iwlagn alias support
|
||||
When: 3.5
|
||||
Why: The iwlagn module has been renamed iwlwifi. The alias will be around
|
||||
for backward compatibility for several cycles and then dropped.
|
||||
Who: Don Fry <donald.h.fry@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: pci_scan_bus_parented()
|
||||
When: 3.5
|
||||
Why: The pci_scan_bus_parented() interface creates a new root bus. The
|
||||
bus is created with default resources (ioport_resource and
|
||||
iomem_resource) that are always wrong, so we rely on arch code to
|
||||
correct them later. Callers of pci_scan_bus_parented() should
|
||||
convert to using pci_scan_root_bus() so they can supply a list of
|
||||
bus resources when the bus is created.
|
||||
Who: Bjorn Helgaas <bhelgaas@google.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Low Performance USB Block driver ("CONFIG_BLK_DEV_UB")
|
||||
When: 3.6
|
||||
Why: This driver provides support for USB storage devices like "USB
|
||||
sticks". As of now, it is deactivated in Debian, Fedora and
|
||||
Ubuntu. All current users can switch over to usb-storage
|
||||
(CONFIG_USB_STORAGE) which only drawback is the additional SCSI
|
||||
stack.
|
||||
Who: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: get_robust_list syscall
|
||||
When: 2013
|
||||
Why: There appear to be no production users of the get_robust_list syscall,
|
||||
and it runs the risk of leaking address locations, allowing the bypass
|
||||
of ASLR. It was only ever intended for debugging, so it should be
|
||||
removed.
|
||||
Who: Kees Cook <keescook@chromium.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Removing the pn544 raw driver.
|
||||
When: 3.6
|
||||
Why: With the introduction of the NFC HCI and SHDL kernel layers, pn544.c
|
||||
is being replaced by pn544_hci.c which is accessible through the netlink
|
||||
and socket NFC APIs. Moreover, pn544.c is outdated and does not seem to
|
||||
work properly with the latest Android stacks.
|
||||
Having 2 drivers for the same hardware is confusing and as such we
|
||||
should only keep the one following the kernel NFC APIs.
|
||||
Who: Samuel Ortiz <sameo@linux.intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: setitimer accepts user NULL pointer (value)
|
||||
When: 3.6
|
||||
Why: setitimer is not returning -EFAULT if user pointer is NULL. This
|
||||
violates the spec.
|
||||
Who: Sasikantha Babu <sasikanth.v19@gmail.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: remove bogus DV presets V4L2_DV_1080I29_97, V4L2_DV_1080I30 and
|
||||
V4L2_DV_1080I25
|
||||
When: 3.6
|
||||
Why: These HDTV formats do not exist and were added by a confused mind
|
||||
(that was me, to be precise...)
|
||||
Who: Hans Verkuil <hans.verkuil@cisco.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: V4L2_CID_HCENTER, V4L2_CID_VCENTER V4L2 controls
|
||||
When: 3.7
|
||||
Why: The V4L2_CID_VCENTER, V4L2_CID_HCENTER controls have been deprecated
|
||||
for about 4 years and they are not used by any mainline driver.
|
||||
There are newer controls (V4L2_CID_PAN*, V4L2_CID_TILT*) that provide
|
||||
similar functionality.
|
||||
Who: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: cgroup option updates via remount
|
||||
When: March 2013
|
||||
Why: Remount currently allows changing bound subsystems and
|
||||
release_agent. Rebinding is hardly useful as it only works
|
||||
when the hierarchy is empty and release_agent itself should be
|
||||
replaced with conventional fsnotify.
|
||||
|
||||
----------------------------
|
||||
|
||||
What: xt_recent rev 0
|
||||
When: 2013
|
||||
Who: Pablo Neira Ayuso <pablo@netfilter.org>
|
||||
Files: net/netfilter/xt_recent.c
|
||||
|
||||
----------------------------
|
||||
|
||||
What: KVM debugfs statistics
|
||||
When: 2013
|
||||
Why: KVM tracepoints provide mostly equivalent information in a much more
|
||||
flexible fashion.
|
||||
|
||||
----------------------------
|
||||
|
||||
What: at91-mci driver ("CONFIG_MMC_AT91")
|
||||
When: 3.8
|
||||
Why: There are two mci drivers: at91-mci and atmel-mci. The PDC support
|
||||
was added to atmel-mci as a first step to support more chips.
|
||||
Then at91-mci was kept only for old IP versions (on at91rm9200 and
|
||||
at91sam9261). The support of these IP versions has just been added
|
||||
to atmel-mci, so atmel-mci can be used for all chips.
|
||||
Who: Ludovic Desroches <ludovic.desroches@atmel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: net/wanrouter/
|
||||
When: June 2013
|
||||
Why: Unsupported/unmaintained/unused since 2.6
|
||||
|
||||
----------------------------
|
||||
|
||||
What: V4L2 selections API target rectangle and flags unification, the
|
||||
following definitions will be removed: V4L2_SEL_TGT_CROP_ACTIVE,
|
||||
V4L2_SEL_TGT_COMPOSE_ACTIVE, V4L2_SUBDEV_SEL_*, V4L2_SUBDEV_SEL_FLAG_*
|
||||
in favor of common V4L2_SEL_TGT_* and V4L2_SEL_FLAG_* definitions.
|
||||
For more details see include/linux/v4l2-common.h.
|
||||
When: 3.8
|
||||
Why: The regular V4L2 selections and the subdev selection API originally
|
||||
defined distinct names for the target rectangles and flags - V4L2_SEL_*
|
||||
and V4L2_SUBDEV_SEL_*. Although, it turned out that the meaning of these
|
||||
target rectangles is virtually identical and the APIs were consolidated
|
||||
to use single set of names - V4L2_SEL_*. This didn't involve any ABI
|
||||
changes. Alias definitions were created for the original ones to avoid
|
||||
any instabilities in the user space interface. After few cycles these
|
||||
backward compatibility definitions will be removed.
|
||||
Who: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Using V4L2_CAP_VIDEO_CAPTURE and V4L2_CAP_VIDEO_OUTPUT flags
|
||||
to indicate a V4L2 memory-to-memory device capability
|
||||
When: 3.8
|
||||
Why: New drivers should use new V4L2_CAP_VIDEO_M2M capability flag
|
||||
to indicate a V4L2 video memory-to-memory (M2M) device and
|
||||
applications can now identify a M2M video device by checking
|
||||
for V4L2_CAP_VIDEO_M2M, with VIDIOC_QUERYCAP ioctl. Using ORed
|
||||
V4L2_CAP_VIDEO_CAPTURE and V4L2_CAP_VIDEO_OUTPUT flags for M2M
|
||||
devices is ambiguous and may lead, for example, to identifying
|
||||
a M2M device as a video capture or output device.
|
||||
Who: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: OMAP private DMA implementation
|
||||
When: 2013
|
||||
Why: We have a DMA engine implementation; all users should be updated
|
||||
to use this rather than persisting with the old APIs. The old APIs
|
||||
block merging the old DMA engine implementation into the DMA
|
||||
engine driver.
|
||||
Who: Russell King <linux@arm.linux.org.uk>,
|
||||
Santosh Shilimkar <santosh.shilimkar@ti.com>
|
||||
|
||||
----------------------------
|
||||
|
|
@ -15,8 +15,8 @@ Debugfs is typically mounted with a command like:
|
|||
mount -t debugfs none /sys/kernel/debug
|
||||
|
||||
(Or an equivalent /etc/fstab line).
|
||||
The debugfs root directory is accessible by anyone by default. To
|
||||
restrict access to the tree the "uid", "gid" and "mode" mount
|
||||
The debugfs root directory is accessible only to the root user by
|
||||
default. To change access to the tree the "uid", "gid" and "mode" mount
|
||||
options can be used.
|
||||
|
||||
Note that the debugfs API is exported GPL-only to modules.
|
||||
|
|
|
|||
|
|
@ -78,7 +78,8 @@ nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
|
|||
flags = hard, nointr, noposix, cto, ac
|
||||
|
||||
|
||||
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
|
||||
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
|
||||
<dns0-ip>:<dns1-ip>
|
||||
|
||||
This parameter tells the kernel how to configure IP addresses of devices
|
||||
and also how to set up the IP routing table. It was originally called
|
||||
|
|
@ -158,6 +159,13 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
|
|||
|
||||
Default: any
|
||||
|
||||
<dns0-ip> IP address of first nameserver.
|
||||
Value gets exported by /proc/net/pnp which is often linked
|
||||
on embedded systems by /etc/resolv.conf.
|
||||
|
||||
<dns1-ip> IP address of secound nameserver.
|
||||
Same as above.
|
||||
|
||||
|
||||
nfsrootdebug
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,140 @@
|
|||
|
||||
HID Sensors Framework
|
||||
======================
|
||||
HID sensor framework provides necessary interfaces to implement sensor drivers,
|
||||
which are connected to a sensor hub. The sensor hub is a HID device and it provides
|
||||
a report descriptor conforming to HID 1.12 sensor usage tables.
|
||||
|
||||
Description from the HID 1.12 "HID Sensor Usages" specification:
|
||||
"Standardization of HID usages for sensors would allow (but not require) sensor
|
||||
hardware vendors to provide a consistent Plug And Play interface at the USB boundary,
|
||||
thereby enabling some operating systems to incorporate common device drivers that
|
||||
could be reused between vendors, alleviating any need for the vendors to provide
|
||||
the drivers themselves."
|
||||
|
||||
This specification describes many usage IDs, which describe the type of sensor
|
||||
and also the individual data fields. Each sensor can have variable number of
|
||||
data fields. The length and order is specified in the report descriptor. For
|
||||
example a part of report descriptor can look like:
|
||||
|
||||
INPUT(1)[INPUT]
|
||||
..
|
||||
Field(2)
|
||||
Physical(0020.0073)
|
||||
Usage(1)
|
||||
0020.045f
|
||||
Logical Minimum(-32767)
|
||||
Logical Maximum(32767)
|
||||
Report Size(8)
|
||||
Report Count(1)
|
||||
Report Offset(16)
|
||||
Flags(Variable Absolute)
|
||||
..
|
||||
..
|
||||
|
||||
The report is indicating "sensor page (0x20)" contains an accelerometer-3D (0x73).
|
||||
This accelerometer-3D has some fields. Here for example field 2 is motion intensity
|
||||
(0x045f) with a logical minimum value of -32767 and logical maximum of 32767. The
|
||||
order of fields and length of each field is important as the input event raw
|
||||
data will use this format.
|
||||
|
||||
|
||||
Implementation
|
||||
=================
|
||||
|
||||
This specification defines many different types of sensors with different sets of
|
||||
data fields. It is difficult to have a common input event to user space applications,
|
||||
for different sensors. For example an accelerometer can send X,Y and Z data, whereas
|
||||
an ambient light sensor can send illumination data.
|
||||
So the implementation has two parts:
|
||||
- Core hid driver
|
||||
- Individual sensor processing part (sensor drivers)
|
||||
|
||||
Core driver
|
||||
-----------
|
||||
The core driver registers (hid-sensor-hub) registers as a HID driver. It parses
|
||||
report descriptors and identifies all the sensors present. It adds an MFD device
|
||||
with name HID-SENSOR-xxxx (where xxxx is usage id from the specification).
|
||||
For example
|
||||
HID-SENSOR-200073 is registered for an Accelerometer 3D driver.
|
||||
So if any driver with this name is inserted, then the probe routine for that
|
||||
function will be called. So an accelerometer processing driver can register
|
||||
with this name and will be probed if there is an accelerometer-3D detected.
|
||||
|
||||
The core driver provides a set of APIs which can be used by the processing
|
||||
drivers to register and get events for that usage id. Also it provides parsing
|
||||
functions, which get and set each input/feature/output report.
|
||||
|
||||
Individual sensor processing part (sensor drivers)
|
||||
-----------
|
||||
The processing driver will use an interface provided by the core driver to parse
|
||||
the report and get the indexes of the fields and also can get events. This driver
|
||||
can use IIO interface to use the standard ABI defined for a type of sensor.
|
||||
|
||||
|
||||
Core driver Interface
|
||||
=====================
|
||||
|
||||
Callback structure:
|
||||
Each processing driver can use this structure to set some callbacks.
|
||||
int (*suspend)(..): Callback when HID suspend is received
|
||||
int (*resume)(..): Callback when HID resume is received
|
||||
int (*capture_sample)(..): Capture a sample for one of its data fields
|
||||
int (*send_event)(..): One complete event is received which can have
|
||||
multiple data fields.
|
||||
|
||||
Registration functions:
|
||||
int sensor_hub_register_callback(struct hid_sensor_hub_device *hsdev,
|
||||
u32 usage_id,
|
||||
struct hid_sensor_hub_callbacks *usage_callback):
|
||||
|
||||
Registers callbacks for an usage id. The callback functions are not allowed
|
||||
to sleep.
|
||||
|
||||
|
||||
int sensor_hub_remove_callback(struct hid_sensor_hub_device *hsdev,
|
||||
u32 usage_id):
|
||||
|
||||
Removes callbacks for an usage id.
|
||||
|
||||
|
||||
Parsing function:
|
||||
int sensor_hub_input_get_attribute_info(struct hid_sensor_hub_device *hsdev,
|
||||
u8 type,
|
||||
u32 usage_id, u32 attr_usage_id,
|
||||
struct hid_sensor_hub_attribute_info *info);
|
||||
|
||||
A processing driver can look for some field of interest and check if it exists
|
||||
in a report descriptor. If it exists it will store necessary information
|
||||
so that fields can be set or get individually.
|
||||
These indexes avoid searching every time and getting field index to get or set.
|
||||
|
||||
|
||||
Set Feature report
|
||||
int sensor_hub_set_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,
|
||||
u32 field_index, s32 value);
|
||||
|
||||
This interface is used to set a value for a field in feature report. For example
|
||||
if there is a field report_interval, which is parsed by a call to
|
||||
sensor_hub_input_get_attribute_info before, then it can directly set that individual
|
||||
field.
|
||||
|
||||
|
||||
int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,
|
||||
u32 field_index, s32 *value);
|
||||
|
||||
This interface is used to get a value for a field in input report. For example
|
||||
if there is a field report_interval, which is parsed by a call to
|
||||
sensor_hub_input_get_attribute_info before, then it can directly get that individual
|
||||
field value.
|
||||
|
||||
|
||||
int sensor_hub_input_attr_get_raw_value(struct hid_sensor_hub_device *hsdev,
|
||||
u32 usage_id,
|
||||
u32 attr_usage_id, u32 report_id);
|
||||
|
||||
This is used to get a particular field value through input reports. For example
|
||||
accelerometer wants to poll X axis value, then it can call this function with
|
||||
the usage id of X axis. HID sensors can provide events, so this is not necessary
|
||||
to poll for any field. If there is some new sample, the core driver will call
|
||||
registered callback function to process the sample.
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
Kernel driver adt7410
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Analog Devices ADT7410
|
||||
Prefix: 'adt7410'
|
||||
Addresses scanned: I2C 0x48 - 0x4B
|
||||
Datasheet: Publicly available at the Analog Devices website
|
||||
http://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf
|
||||
|
||||
Author: Hartmut Knaack <knaack.h@gmx.de>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The ADT7410 is a temperature sensor with rated temperature range of -55°C to
|
||||
+150°C. It has a high accuracy of +/-0.5°C and can be operated at a resolution
|
||||
of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an INT pin to
|
||||
indicate that a minimum or maximum temperature set point has been exceeded, as
|
||||
well as a critical temperature (CT) pin to indicate that the critical
|
||||
temperature set point has been exceeded. Both pins can be set up with a common
|
||||
hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events. Both
|
||||
pins can individually set to be active-low or active-high, while the whole
|
||||
device can either run in comparator mode or interrupt mode. The ADT7410
|
||||
supports continous temperature sampling, as well as sampling one temperature
|
||||
value per second or even justget one sample on demand for power saving.
|
||||
Besides, it can completely power down its ADC, if power management is
|
||||
required.
|
||||
|
||||
Configuration Notes
|
||||
-------------------
|
||||
|
||||
Since the device uses one hysteresis value, which is an offset to minimum,
|
||||
maximum and critical temperature, it can only be set for temp#_max_hyst.
|
||||
However, temp#_min_hyst and temp#_crit_hyst show their corresponding
|
||||
hysteresis.
|
||||
The device is set to 16 bit resolution and comparator mode.
|
||||
|
||||
sysfs-Interface
|
||||
---------------
|
||||
|
||||
temp#_input - temperature input
|
||||
temp#_min - temperature minimum setpoint
|
||||
temp#_max - temperature maximum setpoint
|
||||
temp#_crit - critical temperature setpoint
|
||||
temp#_min_hyst - hysteresis for temperature minimum (read-only)
|
||||
temp#_max_hyst - hysteresis for temperature maximum (read/write)
|
||||
temp#_crit_hyst - hysteresis for critical temperature (read-only)
|
||||
temp#_min_alarm - temperature minimum alarm flag
|
||||
temp#_max_alarm - temperature maximum alarm flag
|
||||
temp#_crit_alarm - critical temperature alarm flag
|
||||
|
|
@ -8,12 +8,24 @@ Supported chips:
|
|||
Datasheet: Publicly available at the Texas Instruments website
|
||||
http://www.ti.com/
|
||||
|
||||
* Texas Instruments INA220
|
||||
Prefix: 'ina220'
|
||||
Addresses: I2C 0x40 - 0x4f
|
||||
Datasheet: Publicly available at the Texas Instruments website
|
||||
http://www.ti.com/
|
||||
|
||||
* Texas Instruments INA226
|
||||
Prefix: 'ina226'
|
||||
Addresses: I2C 0x40 - 0x4f
|
||||
Datasheet: Publicly available at the Texas Instruments website
|
||||
http://www.ti.com/
|
||||
|
||||
* Texas Instruments INA230
|
||||
Prefix: 'ina230'
|
||||
Addresses: I2C 0x40 - 0x4f
|
||||
Datasheet: Publicly available at the Texas Instruments website
|
||||
http://www.ti.com/
|
||||
|
||||
Author: Lothar Felten <l-felten@ti.com>
|
||||
|
||||
Description
|
||||
|
|
@ -23,7 +35,13 @@ The INA219 is a high-side current shunt and power monitor with an I2C
|
|||
interface. The INA219 monitors both shunt drop and supply voltage, with
|
||||
programmable conversion times and filtering.
|
||||
|
||||
The INA220 is a high or low side current shunt and power monitor with an I2C
|
||||
interface. The INA220 monitors both shunt drop and supply voltage.
|
||||
|
||||
The INA226 is a current shunt and power monitor with an I2C interface.
|
||||
The INA226 monitors both a shunt voltage drop and bus supply voltage.
|
||||
|
||||
The INA230 is a high or low side current shunt and power monitor with an I2C
|
||||
interface. The INA230 monitors both a shunt voltage drop and bus supply voltage.
|
||||
|
||||
The shunt value in micro-ohms can be set via platform data.
|
||||
|
|
|
|||
|
|
@ -6,6 +6,10 @@ Supported chips:
|
|||
Datasheet: http://www.national.com/pf/LM/LM70.html
|
||||
* Texas Instruments TMP121/TMP123
|
||||
Information: http://focus.ti.com/docs/prod/folders/print/tmp121.html
|
||||
* National Semiconductor LM71
|
||||
Datasheet: http://www.ti.com/product/LM71
|
||||
* National Semiconductor LM74
|
||||
Datasheet: http://www.ti.com/product/LM74
|
||||
|
||||
Author:
|
||||
Kaiwan N Billimoria <kaiwan@designergraphix.com>
|
||||
|
|
@ -31,9 +35,11 @@ As a real (in-tree) example of this "SPI protocol driver" interfacing
|
|||
with a "SPI master controller driver", see drivers/spi/spi_lm70llp.c
|
||||
and its associated documentation.
|
||||
|
||||
The TMP121/TMP123 are very similar; main differences are 4 wire SPI inter-
|
||||
face (read only) and 13-bit temperature data (0.0625 degrees celsius reso-
|
||||
lution).
|
||||
The LM74 and TMP121/TMP123 are very similar; main difference is 13-bit
|
||||
temperature data (0.0625 degrees celsius resolution).
|
||||
|
||||
The LM71 is also very similar; main difference is 14-bit temperature
|
||||
data (0.03125 degrees celsius resolution).
|
||||
|
||||
Thanks to
|
||||
---------
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue