mirror/freebsd
1
0
Fork 0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-03 09:00:21 +00:00
Code Issues Releases Activity

Import from device-tree git://xenbits.xen.org/people/ianc/device-tree-rebasing.git @c8c1b3a77934768c7f7a4a9c10140c8bec529059

Browse Source
This commit is contained in:
Warner Losh 2015-02-27 22:16:54 +00:00
parent ab9104d367
commit da75c2cc58
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/vendor/device-tree/dist/; revision=279377
svn path=/vendor/device-tree/ian-c8c1b3a7/; revision=279379; tag=vendor/device-tree/ian-c8c1b3a7
1494 changed files with 231094 additions and 3001 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
Bindings/arm/altera/socfpga-sdram-edac.txt Normal file
View File

@ -0,0 +1,15 @@
Altera SOCFPGA SDRAM Error Detection & Correction [EDAC]
The EDAC accesses a range of registers in the SDRAM controller.
Required properties:
- compatible : should contain "altr,sdram-edac";
- altr,sdr-syscon : phandle of the sdr module
- interrupts : Should contain the SDRAM ECC IRQ in the
appropriate format for the IRQ controller.
Example:
sdramedac {
compatible = "altr,sdram-edac";
altr,sdr-syscon = <&sdr>;
interrupts = <0 39 4>;
};

10
Bindings/arm/amlogic.txt Normal file
View File

@ -0,0 +1,10 @@
Amlogic MesonX device tree bindings
-------------------------------------------
Boards with the Amlogic Meson6 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson6"
Boards with the Amlogic Meson8 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8";

8
Bindings/arm/arch_timer.txt
View File

@ -22,6 +22,14 @@ to deliver its interrupts via SPIs.
- always-on : a boolean property. If present, the timer is powered through an
always-on power domain, therefore it never loses context.
** Optional properties:
- arm,cpu-registers-not-fw-configured : Firmware does not initialize
any of the generic timer CPU registers, which contain their
architecturally-defined reset values. Only supported for 32-bit
systems which follow the ARMv7 architected reset values.
Example:
timer {

67
Bindings/arm/arm-boards
View File

@ -23,7 +23,7 @@ Required nodes:
range of 0x200 bytes.
- syscon: the root node of the Integrator platforms must have a
system controller node pointong to the control registers,
system controller node pointing to the control registers,
with the compatible string
"arm,integrator-ap-syscon"
"arm,integrator-cp-syscon"
@ -92,3 +92,68 @@ Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
ARM RealView Boards
-------------------
The RealView boards cover tailored evaluation boards that are used to explore
the ARM11 and Cortex A-8 and Cortex A-9 processors.
Required properties (in root node):
/* RealView Emulation Baseboard */
compatible = "arm,realview-eb";
/* RealView Platform Baseboard for ARM1176JZF-S */
compatible = "arm,realview-pb1176";
/* RealView Platform Baseboard for ARM11 MPCore */
compatible = "arm,realview-pb11mp";
/* RealView Platform Baseboard for Cortex A-8 */
compatible = "arm,realview-pba8";
/* RealView Platform Baseboard Explore for Cortex A-9 */
compatible = "arm,realview-pbx";
Required nodes:
- soc: some node of the RealView platforms must be the SoC
node that contain the SoC-specific devices, withe the compatible
string set to one of these tuples:
"arm,realview-eb-soc", "simple-bus"
"arm,realview-pb1176-soc", "simple-bus"
"arm,realview-pb11mp-soc", "simple-bus"
"arm,realview-pba8-soc", "simple-bus"
"arm,realview-pbx-soc", "simple-bus"
- syscon: some subnode of the RealView SoC node must be a
system controller node pointing to the control registers,
with the compatible string set to one of these tuples:
"arm,realview-eb-syscon", "syscon"
"arm,realview-pb1176-syscon", "syscon"
"arm,realview-pb11mp-syscon", "syscon"
"arm,realview-pba8-syscon", "syscon"
"arm,realview-pbx-syscon", "syscon"
Required properties for the system controller:
- regs: the location and size of the system controller registers,
one range of 0x1000 bytes.
Example:
/dts-v1/;
#include <dt-bindings/interrupt-controller/irq.h>
#include "skeleton.dtsi"
/ {
model = "ARM RealView PB1176 with device tree";
compatible = "arm,realview-pb1176";
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "arm,realview-pb1176-soc", "simple-bus";
ranges;
syscon: syscon@10000000 {
compatible = "arm,realview-syscon", "syscon";
reg = <0x10000000 0x1000>;
};
};
};

7
Bindings/arm/armada-38x.txt
View File

@ -15,6 +15,13 @@ Required root node property:
compatible: must contain "marvell,armada385"
In addition, boards using the Marvell Armada 388 SoC shall have the
following property before the previous one:
Required root node property:
compatible: must contain "marvell,armada388"
Example:
compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";

62
Bindings/arm/atmel-at91.txt
View File

@ -1,6 +1,44 @@
Atmel AT91 device tree bindings.
================================
Boards with a SoC of the Atmel AT91 or SMART family shall have the following
properties:
Required root node properties:
compatible: must be one of:
* "atmel,at91rm9200"
* "atmel,at91sam9" for SoCs using an ARM926EJ-S core, shall be extended with
the specific SoC family or compatible:
o "atmel,at91sam9260"
o "atmel,at91sam9261"
o "atmel,at91sam9263"
o "atmel,at91sam9x5" for the 5 series, shall be extended with the specific
SoC compatible:
- "atmel,at91sam9g15"
- "atmel,at91sam9g25"
- "atmel,at91sam9g35"
- "atmel,at91sam9x25"
- "atmel,at91sam9x35"
o "atmel,at91sam9g20"
o "atmel,at91sam9g45"
o "atmel,at91sam9n12"
o "atmel,at91sam9rl"
o "atmel,at91sam9xe"
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
SoC family:
o "atmel,sama5d3" shall be extended with the specific SoC compatible:
- "atmel,sama5d31"
- "atmel,sama5d33"
- "atmel,sama5d34"
- "atmel,sama5d35"
- "atmel,sama5d36"
o "atmel,sama5d4" shall be extended with the specific SoC compatible:
- "atmel,sama5d41"
- "atmel,sama5d42"
- "atmel,sama5d43"
- "atmel,sama5d44"
PIT Timer required properties:
- compatible: Should be "atmel,at91sam9260-pit"
- reg: Should contain registers location and length
@ -61,8 +99,8 @@ RAMC SDRAM/DDR Controller required properties:
- compatible: Should be "atmel,at91rm9200-sdramc",
"atmel,at91sam9260-sdramc",
"atmel,at91sam9g45-ddramc",
"atmel,sama5d3-ddramc",
- reg: Should contain registers location and length
For at91sam9263 and at91sam9g45 you must specify 2 entries.
Examples:
@ -71,12 +109,6 @@ Examples:
reg = <0xffffe800 0x200>;
};
ramc0: ramc@ffffe400 {
compatible = "atmel,at91sam9g45-ddramc";
reg = <0xffffe400 0x200
0xffffe600 0x200>;
};
SHDWC Shutdown Controller
required properties:
@ -105,3 +137,19 @@ Example:
compatible = "atmel,at91sam9260-rstc";
reg = <0xfffffd00 0x10>;
};
Special Function Registers (SFR)
Special Function Registers (SFR) manage specific aspects of the integrated
memory, bridge implementations, processor and other functionality not controlled
elsewhere.
required properties:
- compatible: Should be "atmel,<chip>-sfr", "syscon".
<chip> can be "sama5d3" or "sama5d4".
- reg: Should contain registers location and length
sfr@f0038000 {
compatible = "atmel,sama5d3-sfr", "syscon";
reg = <0xf0038000 0x60>;
};

9
Bindings/arm/bcm/bcm63138.txt Normal file
View File

@ -0,0 +1,9 @@
Broadcom BCM63138 DSL System-on-a-Chip device tree bindings
-----------------------------------------------------------
Boards compatible with the BCM63138 DSL System-on-a-Chip should have the
following properties:
Required root node property:
compatible: should be "brcm,bcm63138"

31
Bindings/arm/bcm/cygnus.txt Normal file
View File

@ -0,0 +1,31 @@
Broadcom Cygnus device tree bindings
------------------------------------
Boards with Cygnus SoCs shall have the following properties:
Required root node property:
BCM11300
compatible = "brcm,bcm11300", "brcm,cygnus";
BCM11320
compatible = "brcm,bcm11320", "brcm,cygnus";
BCM11350
compatible = "brcm,bcm11350", "brcm,cygnus";
BCM11360
compatible = "brcm,bcm11360", "brcm,cygnus";
BCM58300
compatible = "brcm,bcm58300", "brcm,cygnus";
BCM58302
compatible = "brcm,bcm58302", "brcm,cygnus";
BCM58303
compatible = "brcm,bcm58303", "brcm,cygnus";
BCM58305
compatible = "brcm,bcm58305", "brcm,cygnus";

4
Bindings/arm/brcm-brcmstb.txt
View File

@ -79,7 +79,9 @@ reboot
Required properties
- compatible
The string property "brcm,brcmstb-reboot".
The string property "brcm,brcmstb-reboot" for 40nm/28nm chips with
the new SYS_CTRL interface, or "brcm,bcm7038-reboot" for 65nm
chips with the old SUN_TOP_CTRL interface.
- syscon
A phandle / integer array that points to the syscon node which describes

10
Bindings/arm/cavium-thunder.txt Normal file
View File

@ -0,0 +1,10 @@
Cavium Thunder platform device tree bindings
--------------------------------------------
Boards with Cavium's Thunder SoC shall have following properties.
Root Node
---------
Required root node properties:
- compatible = "cavium,thunder-88xx";

200
Bindings/arm/coresight.txt Normal file
View File

@ -0,0 +1,200 @@
* CoreSight Components:
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink. Each CoreSight component device should use these properties to describe
its hardware characteristcs.
* Required properties for all components *except* non-configurable replicators:
* compatible: These have to be supplemented with "arm,primecell" as
drivers are using the AMBA bus interface. Possible values include:
- "arm,coresight-etb10", "arm,primecell";
- "arm,coresight-tpiu", "arm,primecell";
- "arm,coresight-tmc", "arm,primecell";
- "arm,coresight-funnel", "arm,primecell";
- "arm,coresight-etm3x", "arm,primecell";
* reg: physical base address and length of the register
set(s) of the component.
* clocks: the clock associated to this component.
* clock-names: the name of the clock as referenced by the code.
Since we are using the AMBA framework, the name should be
"apb_pclk".
* port or ports: The representation of the component's port
layout using the generic DT graph presentation found in
"bindings/graph.txt".
* Required properties for devices that don't show up on the AMBA bus, such as
non-configurable replicators:
* compatible: Currently supported value is (note the absence of the
AMBA markee):
- "arm,coresight-replicator"
* port or ports: same as above.
* Optional properties for ETM/PTMs:
* arm,cp14: must be present if the system accesses ETM/PTM management
registers via co-processor 14.
* cpu: the cpu phandle this ETM/PTM is affined to. When omitted the
source is considered to belong to CPU0.
* Optional property for TMC:
* arm,buffer-size: size of contiguous buffer space for TMC ETR
(embedded trace router)
Example:
1. Sinks
etb@20010000 {
compatible = "arm,coresight-etb10", "arm,primecell";
reg = <0 0x20010000 0 0x1000>;
coresight-default-sink;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
etb_in_port: endpoint@0 {
slave-mode;
remote-endpoint = <&replicator_out_port0>;
};
};
};
tpiu@20030000 {
compatible = "arm,coresight-tpiu", "arm,primecell";
reg = <0 0x20030000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
tpiu_in_port: endpoint@0 {
slave-mode;
remote-endpoint = <&replicator_out_port1>;
};
};
};
2. Links
replicator {
/* non-configurable replicators don't show up on the
* AMBA bus. As such no need to add "arm,primecell".
*/
compatible = "arm,coresight-replicator";
ports {
#address-cells = <1>;
#size-cells = <0>;
/* replicator output ports */
port@0 {
reg = <0>;
replicator_out_port0: endpoint {
remote-endpoint = <&etb_in_port>;
};
};
port@1 {
reg = <1>;
replicator_out_port1: endpoint {
remote-endpoint = <&tpiu_in_port>;
};
};
/* replicator input port */
port@2 {
reg = <0>;
replicator_in_port0: endpoint {
slave-mode;
remote-endpoint = <&funnel_out_port0>;
};
};
};
};
funnel@20040000 {
compatible = "arm,coresight-funnel", "arm,primecell";
reg = <0 0x20040000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
ports {
#address-cells = <1>;
#size-cells = <0>;
/* funnel output port */
port@0 {
reg = <0>;
funnel_out_port0: endpoint {
remote-endpoint =
<&replicator_in_port0>;
};
};
/* funnel input ports */
port@1 {
reg = <0>;
funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&ptm0_out_port>;
};
};
port@2 {
reg = <1>;
funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&ptm1_out_port>;
};
};
port@3 {
reg = <2>;
funnel_in_port2: endpoint {
slave-mode;
remote-endpoint = <&etm0_out_port>;
};
};
};
};
3. Sources
ptm@2201c000 {
compatible = "arm,coresight-etm3x", "arm,primecell";
reg = <0 0x2201c000 0 0x1000>;
cpu = <&cpu0>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
ptm0_out_port: endpoint {
remote-endpoint = <&funnel_in_port0>;
};
};
};
ptm@2201d000 {
compatible = "arm,coresight-etm3x", "arm,primecell";
reg = <0 0x2201d000 0 0x1000>;
cpu = <&cpu1>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
ptm1_out_port: endpoint {
remote-endpoint = <&funnel_in_port1>;
};
};
};

19
Bindings/arm/cpus.txt
View File

@ -166,6 +166,7 @@ nodes to be present and contain the properties described below.
"arm,cortex-r5"
"arm,cortex-r7"
"brcm,brahma-b15"
"cavium,thunder"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
@ -174,6 +175,7 @@ nodes to be present and contain the properties described below.
"marvell,pj4a"
"marvell,pj4b"
"marvell,sheeva-v5"
"nvidia,tegra132-denver"
"qcom,krait"
"qcom,scorpion"
- enable-method
@ -219,6 +221,21 @@ nodes to be present and contain the properties described below.
Value type: <phandle>
Definition: Specifies the ACC[2] node associated with this CPU.
- cpu-idle-states
Usage: Optional
Value type: <prop-encoded-array>
Definition:
# List of phandles to idle state nodes supported
by this cpu [3].
- rockchip,pmu
Usage: optional for systems that have an "enable-method"
property value of "rockchip,rk3066-smp"
While optional, it is the preferred way to get access to
the cpu-core power-domains.
Value type: <phandle>
Definition: Specifies the syscon node controlling the cpu core
power domains.
Example 1 (dual-cluster big.LITTLE system 32-bit):
@ -415,3 +432,5 @@ cpus {
--
[1] arm/msm/qcom,saw2.txt
[2] arm/msm/qcom,kpss-acc.txt
[3] ARM Linux kernel documentation - idle states bindings
Documentation/devicetree/bindings/arm/idle-states.txt

6
Bindings/arm/digicolor.txt Normal file
View File

@ -0,0 +1,6 @@
Conexant Digicolor Platforms Device Tree Bindings
Each device tree must specify which Conexant Digicolor SoC it uses.
Must be the following compatible string:
cnxt,cx92755

15
Bindings/arm/exynos/power_domain.txt
View File

@ -8,6 +8,8 @@ Required Properties:
* samsung,exynos4210-pd - for exynos4210 type power domain.
- reg: physical base address of the controller and length of memory mapped
region.
- #power-domain-cells: number of cells in power domain specifier;
must be 0.
Optional Properties:
- clocks: List of clock handles. The parent clocks of the input clocks to the
@ -21,7 +23,7 @@ Optional Properties:
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
are supported currently.
Node of a device using power domains must have a samsung,power-domain property
Node of a device using power domains must have a power-domains property
defined with a phandle to respective power domain.
Example:
@ -29,6 +31,7 @@ Example:
lcd0: power-domain-lcd0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C00 0x10>;
#power-domain-cells = <0>;
};
mfc_pd: power-domain@10044060 {
@ -37,12 +40,8 @@ Example:
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
<&clock CLK_MOUT_USER_ACLK333>;
clock-names = "oscclk", "pclk0", "clk0";
#power-domain-cells = <0>;
};
Example of the node using power domain:
node {
/* ... */
samsung,power-domain = <&lcd0>;
/* ... */
};
See Documentation/devicetree/bindings/power/power_domain.txt for description
of consumer-side bindings.

58
Bindings/arm/fsl.txt
View File

@ -74,3 +74,61 @@ Required root node properties:
i.MX6q generic board
Required root node properties:
- compatible = "fsl,imx6q";
Freescale Vybrid Platform Device Tree Bindings
----------------------------------------------
For the Vybrid SoC familiy all variants with DDR controller are supported,
which is the VF5xx and VF6xx series. Out of historical reasons, in most
places the kernel uses vf610 to refer to the whole familiy.
Required root node compatible property (one of them):
- compatible = "fsl,vf500";
- compatible = "fsl,vf510";
- compatible = "fsl,vf600";
- compatible = "fsl,vf610";
Freescale LS1021A Platform Device Tree Bindings
------------------------------------------------
Required root node compatible properties:
- compatible = "fsl,ls1021a";
Freescale LS1021A SoC-specific Device Tree Bindings
-------------------------------------------
Freescale SCFG
SCFG is the supplemental configuration unit, that provides SoC specific
configuration and status registers for the chip. Such as getting PEX port
status.
Required properties:
- compatible: should be "fsl,ls1021a-scfg"
- reg: should contain base address and length of SCFG memory-mapped registers
Example:
scfg: scfg@1570000 {
compatible = "fsl,ls1021a-scfg";
reg = <0x0 0x1570000 0x0 0x10000>;
};
Freescale DCFG
DCFG is the device configuration unit, that provides general purpose
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- compatible: should be "fsl,ls1021a-dcfg"
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1021a-dcfg";
reg = <0x0 0x1ee0000 0x0 0x10000>;
};
Freescale LS2085A SoC Device Tree Bindings
------------------------------------------
LS2085A ARMv8 based Simulator model
Required root node properties:
- compatible = "fsl,ls2085a-simu", "fsl,ls2085a";

72
Bindings/arm/fw-cfg.txt Normal file
View File

@ -0,0 +1,72 @@
* QEMU Firmware Configuration bindings for ARM
QEMU's arm-softmmu and aarch64-softmmu emulation / virtualization targets
provide the following Firmware Configuration interface on the "virt" machine
type:
- A write-only, 16-bit wide selector (or control) register,
- a read-write, 64-bit wide data register.
QEMU exposes the control and data register to ARM guests as memory mapped
registers; their location is communicated to the guest's UEFI firmware in the
DTB that QEMU places at the bottom of the guest's DRAM.
The guest writes a selector value (a key) to the selector register, and then
can read the corresponding data (produced by QEMU) via the data register. If
the selected entry is writable, the guest can rewrite it through the data
register.
The selector register takes keys in big endian byte order.
The data register allows accesses with 8, 16, 32 and 64-bit width (only at
offset 0 of the register). Accesses larger than a byte are interpreted as
arrays, bundled together only for better performance. The bytes constituting
such a word, in increasing address order, correspond to the bytes that would
have been transferred by byte-wide accesses in chronological order.
The interface allows guest firmware to download various parameters and blobs
that affect how the firmware works and what tables it installs for the guest
OS. For example, boot order of devices, ACPI tables, SMBIOS tables, kernel and
initrd images for direct kernel booting, virtual machine UUID, SMP information,
virtual NUMA topology, and so on.
The authoritative registry of the valid selector values and their meanings is
the QEMU source code; the structure of the data blobs corresponding to the
individual key values is also defined in the QEMU source code.
The presence of the registers can be verified by selecting the "signature" blob
with key 0x0000, and reading four bytes from the data register. The returned
signature is "QEMU".
The outermost protocol (involving the write / read sequences of the control and
data registers) is expected to be versioned, and/or described by feature bits.
The interface revision / feature bitmap can be retrieved with key 0x0001. The
blob to be read from the data register has size 4, and it is to be interpreted
as a uint32_t value in little endian byte order. The current value
(corresponding to the above outer protocol) is zero.
The guest kernel is not expected to use these registers (although it is
certainly allowed to); the device tree bindings are documented here because
this is where device tree bindings reside in general.
Required properties:
- compatible: "qemu,fw-cfg-mmio".
- reg: the MMIO region used by the device.
* Bytes 0x0 to 0x7 cover the data register.
* Bytes 0x8 to 0x9 cover the selector register.
* Further registers may be appended to the region in case of future interface
revisions / feature bits.
Example:
/ {
#size-cells = <0x2>;
#address-cells = <0x2>;
fw-cfg@9020000 {
compatible = "qemu,fw-cfg-mmio";
reg = <0x0 0x9020000 0x0 0xa>;
};
};

5
Bindings/arm/geniatech.txt Normal file
View File

@ -0,0 +1,5 @@
Geniatech platforms device tree bindings
-------------------------------------------
Geniatech ATV1200
- compatible = "geniatech,atv1200"

39
Bindings/arm/gic-v3.txt
View File

@ -49,11 +49,29 @@ Optional
occupied by the redistributors. Required if more than one such
region is present.
Sub-nodes:
GICv3 has one or more Interrupt Translation Services (ITS) that are
used to route Message Signalled Interrupts (MSI) to the CPUs.
These nodes must have the following properties:
- compatible : Should at least contain "arm,gic-v3-its".
- msi-controller : Boolean property. Identifies the node as an MSI controller
- reg: Specifies the base physical address and size of the ITS
registers.
The main GIC node must contain the appropriate #address-cells,
#size-cells and ranges properties for the reg property of all ITS
nodes.
Examples:
gic: interrupt-controller@2cf00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
interrupt-controller;
reg = <0x0 0x2f000000 0 0x10000>, // GICD
<0x0 0x2f100000 0 0x200000>, // GICR
@ -61,11 +79,20 @@ Examples:
<0x0 0x2c010000 0 0x2000>, // GICH
<0x0 0x2c020000 0 0x2000>; // GICV
interrupts = <1 9 4>;
gic-its@2c200000 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0x2c200000 0 0x200000>;
};
};
gic: interrupt-controller@2c010000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
interrupt-controller;
redistributor-stride = <0x0 0x40000>; // 256kB stride
#redistributor-regions = <2>;
@ -76,4 +103,16 @@ Examples:
<0x0 0x2c060000 0 0x2000>, // GICH
<0x0 0x2c080000 0 0x2000>; // GICV
interrupts = <1 9 4>;
gic-its@2c200000 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0x2c200000 0 0x200000>;
};
gic-its@2c400000 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0x2c400000 0 0x200000>;
};
};

62
Bindings/arm/gic.txt
View File

@ -17,6 +17,7 @@ Main node required properties:
"arm,cortex-a7-gic"
"arm,arm11mp-gic"
"brcm,brahma-b15-gic"
"arm,arm1176jzf-devchip-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.
@ -31,12 +32,16 @@ Main node required properties:
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered
2 = high-to-low edge triggered (invalid for SPIs)
4 = active high level-sensitive
8 = active low level-sensitive
8 = active low level-sensitive (invalid for SPIs).
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
the interrupt is wired to that CPU. Only valid for PPI interrupts.
Also note that the configurability of PPI interrupts is IMPLEMENTATION
DEFINED and as such not guaranteed to be present (most SoC available
in 2014 seem to ignore the setting of this flag and use the hardware
default value).
- reg : Specifies base physical address(s) and size of the GIC registers. The
first region is the GIC distributor register base and size. The 2nd region is
@ -96,3 +101,56 @@ Example:
<0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
};
* GICv2m extension for MSI/MSI-x support (Optional)
Certain revisions of GIC-400 supports MSI/MSI-x via V2M register frame(s).
This is enabled by specifying v2m sub-node(s).
Required properties:
- compatible : The value here should contain "arm,gic-v2m-frame".
- msi-controller : Identifies the node as an MSI controller.
- reg : GICv2m MSI interface register base and size
Optional properties:
- arm,msi-base-spi : When the MSI_TYPER register contains an incorrect
value, this property should contain the SPI base of
the MSI frame, overriding the HW value.
- arm,msi-num-spis : When the MSI_TYPER register contains an incorrect
value, this property should contain the number of
SPIs assigned to the frame, overriding the HW value.
Example:
interrupt-controller@e1101000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
interrupt-controller;
interrupts = <1 8 0xf04>;
ranges = <0 0 0 0xe1100000 0 0x100000>;
reg = <0x0 0xe1110000 0 0x01000>,
<0x0 0xe112f000 0 0x02000>,
<0x0 0xe1140000 0 0x10000>,
<0x0 0xe1160000 0 0x10000>;
v2m0: v2m@0x8000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x80000 0 0x1000>;
};
....
v2mN: v2m@0x9000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x90000 0 0x1000>;
};
};

48
Bindings/arm/hisilicon/hisilicon.txt
View File

@ -5,6 +5,15 @@ Hi4511 Board
Required root node properties:
- compatible = "hisilicon,hi3620-hi4511";
HiP04 D01 Board
Required root node properties:
- compatible = "hisilicon,hip04-d01";
HiP01 ca9x2 Board
Required root node properties:
- compatible = "hisilicon,hip01-ca9x2";
Hisilicon system controller
Required properties:
@ -31,6 +40,27 @@ Example:
reboot-offset = <0x4>;
};
-----------------------------------------------------------------------
Hisilicon HiP01 system controller
Required properties:
- compatible : "hisilicon,hip01-sysctrl"
- reg : Register address and size
The HiP01 system controller is mostly compatible with hisilicon
system controller,but it has some specific control registers for
HIP01 SoC family, such as slave core boot, and also some same
registers located at different offset.
Example:
/* for hip01-ca9x2 */
sysctrl: system-controller@10000000 {
compatible = "hisilicon,hip01-sysctrl", "hisilicon,sysctrl";
reg = <0x10000000 0x1000>;
reboot-offset = <0x4>;
};
-----------------------------------------------------------------------
Hisilicon CPU controller
@ -55,3 +85,21 @@ Example:
compatible = "hisilicon,pctrl";
reg = <0xfca09000 0x1000>;
};
-----------------------------------------------------------------------
Fabric:
Required Properties:
- compatible: "hisilicon,hip04-fabric";
- reg: Address and size of Fabric
-----------------------------------------------------------------------
Bootwrapper boot method (software protocol on SMP):
Required Properties:
- compatible: "hisilicon,hip04-bootwrapper";
- boot-method: Address and size of boot method.
[0]: bootwrapper physical address
[1]: bootwrapper size
[2]: relocation physical address
[3]: relocation size

699
Bindings/arm/idle-states.txt Normal file
View File

@ -0,0 +1,699 @@
==========================================
ARM idle states binding description
==========================================
==========================================
1 - Introduction
==========================================
ARM systems contain HW capable of managing power consumption dynamically,
where cores can be put in different low-power states (ranging from simple
wfi to power gating) according to OS PM policies. The CPU states representing
the range of dynamic idle states that a processor can enter at run-time, can be
specified through device tree bindings representing the parameters required
to enter/exit specific idle states on a given processor.
According to the Server Base System Architecture document (SBSA, [3]), the
power states an ARM CPU can be put into are identified by the following list:
- Running
- Idle_standby
- Idle_retention
- Sleep
- Off
The power states described in the SBSA document define the basic CPU states on
top of which ARM platforms implement power management schemes that allow an OS
PM implementation to put the processor in different idle states (which include
states listed above; "off" state is not an idle state since it does not have
wake-up capabilities, hence it is not considered in this document).
Idle state parameters (eg entry latency) are platform specific and need to be
characterized with bindings that provide the required information to OS PM
code so that it can build the required tables and use them at runtime.
The device tree binding definition for ARM idle states is the subject of this
document.
===========================================
2 - idle-states definitions
===========================================
Idle states are characterized for a specific system through a set of
timing and energy related properties, that underline the HW behaviour
triggered upon idle states entry and exit.
The following diagram depicts the CPU execution phases and related timing
properties required to enter and exit an idle state:
..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__..
| | | | |
|<------ entry ------->|
| latency |
|<- exit ->|
| latency |
|<-------- min-residency -------->|
|<------- wakeup-latency ------->|
Diagram 1: CPU idle state execution phases
EXEC: Normal CPU execution.
PREP: Preparation phase before committing the hardware to idle mode
like cache flushing. This is abortable on pending wake-up
event conditions. The abort latency is assumed to be negligible
(i.e. less than the ENTRY + EXIT duration). If aborted, CPU
goes back to EXEC. This phase is optional. If not abortable,
this should be included in the ENTRY phase instead.
ENTRY: The hardware is committed to idle mode. This period must run
to completion up to IDLE before anything else can happen.
IDLE: This is the actual energy-saving idle period. This may last
between 0 and infinite time, until a wake-up event occurs.
EXIT: Period during which the CPU is brought back to operational
mode (EXEC).
entry-latency: Worst case latency required to enter the idle state. The
exit-latency may be guaranteed only after entry-latency has passed.
min-residency: Minimum period, including preparation and entry, for a given
idle state to be worthwhile energywise.
wakeup-latency: Maximum delay between the signaling of a wake-up event and the
CPU being able to execute normal code again. If not specified, this is assumed
to be entry-latency + exit-latency.
These timing parameters can be used by an OS in different circumstances.
An idle CPU requires the expected min-residency time to select the most
appropriate idle state based on the expected expiry time of the next IRQ
(ie wake-up) that causes the CPU to return to the EXEC phase.
An operating system scheduler may need to compute the shortest wake-up delay
for CPUs in the system by detecting how long will it take to get a CPU out
of an idle state, eg:
wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
In other words, the scheduler can make its scheduling decision by selecting
(eg waking-up) the CPU with the shortest wake-up latency.
The wake-up latency must take into account the entry latency if that period
has not expired. The abortable nature of the PREP period can be ignored
if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
the worst case since it depends on the CPU operating conditions, ie caches
state).
An OS has to reliably probe the wakeup-latency since some devices can enforce
latency constraints guarantees to work properly, so the OS has to detect the
worst case wake-up latency it can incur if a CPU is allowed to enter an
idle state, and possibly to prevent that to guarantee reliable device
functioning.
The min-residency time parameter deserves further explanation since it is
expressed in time units but must factor in energy consumption coefficients.
The energy consumption of a cpu when it enters a power state can be roughly
characterised by the following graph:
|
|
|
e |
n | /---
e | /------
r | /------
g | /-----
y | /------
| ----
| /|
| / |
| / |
| / |
| / |
| / |
|/ |
-----|-------+----------------------------------
0| 1 time(ms)
Graph 1: Energy vs time example
The graph is split in two parts delimited by time 1ms on the X-axis.
The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope
and denotes the energy costs incurred whilst entering and leaving the idle
state.
The graph curve in the area delimited by X-axis values = {x | x > 1ms } has
shallower slope and essentially represents the energy consumption of the idle
state.
min-residency is defined for a given idle state as the minimum expected
residency time for a state (inclusive of preparation and entry) after
which choosing that state become the most energy efficient option. A good
way to visualise this, is by taking the same graph above and comparing some
states energy consumptions plots.
For sake of simplicity, let's consider a system with two idle states IDLE1,
and IDLE2:
|
|
|
| /-- IDLE1
e | /---
n | /----
e | /---
r | /-----/--------- IDLE2
g | /-------/---------
y | ------------ /---|
| / /---- |
| / /--- |
| / /---- |
| / /--- |
| --- |
| / |
| / |
|/ | time
---/----------------------------+------------------------
|IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy
|
IDLE2-min-residency
Graph 2: idle states min-residency example
In graph 2 above, that takes into account idle states entry/exit energy
costs, it is clear that if the idle state residency time (ie time till next
wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
choice energywise.
This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
than IDLE2.
However, the lower power consumption (ie shallower energy curve slope) of idle
state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
efficient.
The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
shallower states in a system with multiple idle states) is defined
IDLE2-min-residency and corresponds to the time when energy consumption of
IDLE1 and IDLE2 states breaks even.
The definitions provided in this section underpin the idle states
properties specification that is the subject of the following sections.
===========================================
3 - idle-states node
===========================================
ARM processor idle states are defined within the idle-states node, which is
a direct child of the cpus node [1] and provides a container where the
processor idle states, defined as device tree nodes, are listed.
- idle-states node
Usage: Optional - On ARM systems, it is a container of processor idle
states nodes. If the system does not provide CPU
power management capabilities or the processor just
supports idle_standby an idle-states node is not
required.
Description: idle-states node is a container node, where its
subnodes describe the CPU idle states.
Node name must be "idle-states".
The idle-states node's parent node must be the cpus node.
The idle-states node's child nodes can be:
- one or more state nodes
Any other configuration is considered invalid.
An idle-states node defines the following properties:
- entry-method
Value type: <stringlist>
Usage and definition depend on ARM architecture version.
# On ARM v8 64-bit this property is required and must
be one of:
- "psci" (see bindings in [2])
# On ARM 32-bit systems this property is optional
The nodes describing the idle states (state) can only be defined within the
idle-states node, any other configuration is considered invalid and therefore
must be ignored.
===========================================
4 - state node
===========================================
A state node represents an idle state description and must be defined as
follows:
- state node
Description: must be child of the idle-states node
The state node name shall follow standard device tree naming
rules ([5], 2.2.1 "Node names"), in particular state nodes which
are siblings within a single common parent must be given a unique name.
The idle state entered by executing the wfi instruction (idle_standby
SBSA,[3][4]) is considered standard on all ARM platforms and therefore
must not be listed.
With the definitions provided above, the following list represents
the valid properties for a state node:
- compatible
Usage: Required
Value type: <stringlist>
Definition: Must be "arm,idle-state".
- local-timer-stop
Usage: See definition
Value type: <none>
Definition: if present the CPU local timer control logic is
lost on state entry, otherwise it is retained.
- entry-latency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing worst case latency in
microseconds required to enter the idle state.
The exit-latency-us duration may be guaranteed
only after entry-latency-us has passed.
- exit-latency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing worst case latency
in microseconds required to exit the idle state.
- min-residency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing minimum residency duration
in microseconds, inclusive of preparation and
entry, for this idle state to be considered
worthwhile energy wise (refer to section 2 of
this document for a complete description).
- wakeup-latency-us:
Usage: Optional
Value type: <prop-encoded-array>
Definition: u32 value representing maximum delay between the
signaling of a wake-up event and the CPU being
able to execute normal code again. If omitted,
this is assumed to be equal to:
entry-latency-us + exit-latency-us
It is important to supply this value on systems
where the duration of PREP phase (see diagram 1,
section 2) is non-neglibigle.
In such systems entry-latency-us + exit-latency-us
will exceed wakeup-latency-us by this duration.
- status:
Usage: Optional
Value type: <string>
Definition: A standard device tree property [5] that indicates
the operational status of an idle-state.
If present, it shall be:
"okay": to indicate that the idle state is
operational.
"disabled": to indicate that the idle state has
been disabled in firmware so it is not
operational.
If the property is not present the idle-state must
be considered operational.
- idle-state-name:
Usage: Optional
Value type: <string>
Definition: A string used as a descriptive name for the idle
state.
In addition to the properties listed above, a state node may require
additional properties specifics to the entry-method defined in the
idle-states node, please refer to the entry-method bindings
documentation for properties definitions.
===========================================
4 - Examples
===========================================
Example 1 (ARM 64-bit, 16-cpu system, PSCI enable-method):
cpus {
#size-cells = <0>;
#address-cells = <2>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU4: cpu@10000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10000>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU5: cpu@10001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10001>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU6: cpu@10100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU7: cpu@10101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU8: cpu@100000000 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x0>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU9: cpu@100000001 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x1>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU10: cpu@100000100 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU11: cpu@100000101 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU12: cpu@100010000 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10000>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU13: cpu@100010001 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10001>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU14: cpu@100010100 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU15: cpu@100010101 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
idle-states {
entry-method = "arm,psci";
CPU_RETENTION_0_0: cpu-retention-0-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <20>;
exit-latency-us = <40>;
min-residency-us = <80>;
};
CLUSTER_RETENTION_0: cluster-retention-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <50>;
exit-latency-us = <100>;
min-residency-us = <250>;
wakeup-latency-us = <130>;
};
CPU_SLEEP_0_0: cpu-sleep-0-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <250>;
exit-latency-us = <500>;
min-residency-us = <950>;
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <600>;
exit-latency-us = <1100>;
min-residency-us = <2700>;
wakeup-latency-us = <1500>;
};
CPU_RETENTION_1_0: cpu-retention-1-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <20>;
exit-latency-us = <40>;
min-residency-us = <90>;
};
CLUSTER_RETENTION_1: cluster-retention-1 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <50>;
exit-latency-us = <100>;
min-residency-us = <270>;
wakeup-latency-us = <100>;
};
CPU_SLEEP_1_0: cpu-sleep-1-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <70>;
exit-latency-us = <100>;
min-residency-us = <300>;
wakeup-latency-us = <150>;
};
CLUSTER_SLEEP_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <500>;
exit-latency-us = <1200>;
min-residency-us = <3500>;
wakeup-latency-us = <1300>;
};
};
};
Example 2 (ARM 32-bit, 8-cpu system, two clusters):
cpus {
#size-cells = <0>;
#address-cells = <1>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU4: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
CPU5: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
CPU6: cpu@102 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
CPU7: cpu@103 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
idle-states {
CPU_SLEEP_0_0: cpu-sleep-0-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <200>;
exit-latency-us = <100>;
min-residency-us = <400>;
wakeup-latency-us = <250>;
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <500>;
exit-latency-us = <1500>;
min-residency-us = <2500>;
wakeup-latency-us = <1700>;
};
CPU_SLEEP_1_0: cpu-sleep-1-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <300>;
exit-latency-us = <500>;
min-residency-us = <900>;
wakeup-latency-us = <600>;
};
CLUSTER_SLEEP_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <800>;
exit-latency-us = <2000>;
min-residency-us = <6500>;
wakeup-latency-us = <2300>;
};
};
};
===========================================
5 - References
===========================================
[1] ARM Linux Kernel documentation - CPUs bindings
Documentation/devicetree/bindings/arm/cpus.txt
[2] ARM Linux Kernel documentation - PSCI bindings
Documentation/devicetree/bindings/arm/psci.txt
[3] ARM Server Base System Architecture (SBSA)
http://infocenter.arm.com/help/index.jsp
[4] ARM Architecture Reference Manuals
http://infocenter.arm.com/help/index.jsp
[5] ePAPR standard
https://www.power.org/documentation/epapr-version-1-1/

20
Bindings/arm/l2cc.txt
View File

@ -2,6 +2,10 @@
ARM cores often have a separate level 2 cache controller. There are various
implementations of the L2 cache controller with compatible programming models.
Some of the properties that are just prefixed "cache-*" are taken from section
3.7.3 of the ePAPR v1.1 specification which can be found at:
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
The ARM L2 cache representation in the device tree should be done as follows:
Required properties:
@ -44,9 +48,25 @@ Optional properties:
I/O coherent mode. Valid only when the arm,pl310-cache compatible
string is used.
- interrupts : 1 combined interrupt.
- cache-size : specifies the size in bytes of the cache
- cache-sets : specifies the number of associativity sets of the cache
- cache-block-size : specifies the size in bytes of a cache block
- cache-line-size : specifies the size in bytes of a line in the cache,
if this is not specified, the line size is assumed to be equal to the
cache block size
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
- arm,double-linefill : Override double linefill enable setting. Enable if
non-zero, disable if zero.
- arm,double-linefill-incr : Override double linefill on INCR read. Enable
if non-zero, disable if zero.
- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
if non-zero, disable if zero.
- arm,prefetch-drop : Override prefetch drop enable setting. Enable if non-zero,
disable if zero.
- arm,prefetch-offset : Override prefetch offset value. Valid values are
0-7, 15, 23, and 31.
Example:

10
Bindings/arm/marvell,berlin.txt
View File

@ -106,11 +106,21 @@ Required subnode-properties:
- groups: a list of strings describing the group names.
- function: a string describing the function used to mux the groups.
* Reset controller binding
A reset controller is part of the chip control registers set. The chip control
node also provides the reset. The register set is not at the same offset between
Berlin SoCs.
Required property:
- #reset-cells: must be set to 2
Example:
chip: chip-control@ea0000 {
compatible = "marvell,berlin2-chip-ctrl";
#clock-cells = <1>;
#reset-cells = <2>;
reg = <0xea0000 0x400>;
clocks = <&refclk>, <&externaldev 0>;
clock-names = "refclk", "video_ext0";

29
Bindings/arm/mediatek.txt
View File

@ -1,8 +1,31 @@
Mediatek MT6589 Platforms Device Tree Bindings
MediaTek mt65xx & mt81xx Platforms Device Tree Bindings
Boards with a SoC of the Mediatek MT6589 shall have the following property:
Boards with a MediaTek mt65xx/mt81xx SoC shall have the following property:
Required root node property:
compatible: must contain "mediatek,mt6589"
compatible: Must contain one of
"mediatek,mt6589"
"mediatek,mt6592"
"mediatek,mt8127"
"mediatek,mt8135"
"mediatek,mt8173"
Supported boards:
- bq Aquaris5 smart phone:
Required root node properties:
- compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
- Evaluation board for MT6592:
Required root node properties:
- compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
- MTK mt8127 tablet moose EVB:
Required root node properties:
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
- MTK mt8135 tablet EVB:
Required root node properties:
- compatible = "mediatek,mt8135-evbp1", "mediatek,mt8135";
- MTK mt8173 tablet EVB:
Required root node properties:
- compatible = "mediatek,mt8173-evb", "mediatek,mt8173";

30
Bindings/arm/mediatek/mediatek,sysirq.txt Normal file
View File

@ -0,0 +1,30 @@
Mediatek 65xx/81xx sysirq
Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI
interrupt.
Required properties:
- compatible: should be one of:
"mediatek,mt8173-sysirq"
"mediatek,mt8135-sysirq"
"mediatek,mt8127-sysirq"
"mediatek,mt6592-sysirq"
"mediatek,mt6589-sysirq"
"mediatek,mt6582-sysirq"
"mediatek,mt6577-sysirq"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Use the same format as specified by GIC in
Documentation/devicetree/bindings/arm/gic.txt
- interrupt-parent: phandle of irq parent for sysirq. The parent must
use the same interrupt-cells format as GIC.
- reg: Physical base address of the intpol registers and length of memory
mapped region.
Example:
sysirq: interrupt-controller@10200100 {
compatible = "mediatek,mt6589-sysirq", "mediatek,mt6577-sysirq";
interrupt-controller;
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
reg = <0 0x10200100 0 0x1c>;
};

2
Bindings/arm/msm/timer.txt
View File

@ -8,7 +8,7 @@ Properties:
"qcom,kpss-timer" - krait subsystem
"qcom,scss-timer" - scorpion subsystem
- interrupts : Interrupts for the the debug timer, the first general purpose
- interrupts : Interrupts for the debug timer, the first general purpose
timer, and optionally a second general purpose timer in that
order.

3
Bindings/arm/omap/mpu.txt
View File

@ -10,6 +10,9 @@ Required properties:
Should be "ti,omap5-mpu" for OMAP5
- ti,hwmods: "mpu"
Optional properties:
- sram: Phandle to the ocmcram node
Examples:
- For an OMAP5 SMP system:

15
Bindings/arm/omap/omap.txt
View File

@ -85,6 +85,18 @@ SoCs:
- DRA722
compatible = "ti,dra722", "ti,dra72", "ti,dra7"
- AM5728
compatible = "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
- AM5726
compatible = "ti,am5726", "ti,dra742", "ti,dra74", "ti,dra7"
- AM5718
compatible = "ti,am5718", "ti,dra722", "ti,dra72", "ti,dra7"
- AM5716
compatible = "ti,am5716", "ti,dra722", "ti,dra72", "ti,dra7"
- AM4372
compatible = "ti,am4372", "ti,am43"
@ -120,6 +132,9 @@ Boards:
- AM335X Bone : Low cost community board
compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
- AM335X OrionLXm : Substation Automation Platform
compatible = "novatech,am335x-lxm", "ti,am33xx"
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"

14
Bindings/arm/psci.txt
View File

@ -50,6 +50,16 @@ Main node optional properties:
- migrate : Function ID for MIGRATE operation
Device tree nodes that require usage of PSCI CPU_SUSPEND function (ie idle
state nodes, as per bindings in [1]) must specify the following properties:
- arm,psci-suspend-param
Usage: Required for state nodes[1] if the corresponding
idle-states node entry-method property is set
to "psci".
Value type: <u32>
Definition: power_state parameter to pass to the PSCI
suspend call.
Example:
@ -64,7 +74,6 @@ Case 1: PSCI v0.1 only.
migrate = <0x95c10003>;
};
Case 2: PSCI v0.2 only
psci {
@ -88,3 +97,6 @@ Case 3: PSCI v0.2 and PSCI v0.1.
...
};
[1] Kernel documentation - ARM idle states bindings
Documentation/devicetree/bindings/arm/idle-states.txt

14
Bindings/arm/rockchip.txt
View File

@ -1,10 +1,24 @@
Rockchip platforms device tree bindings
---------------------------------------
- MarsBoard RK3066 board:
Required root node properties:
- compatible = "haoyu,marsboard-rk3066", "rockchip,rk3066a";
- bq Curie 2 tablet:
Required root node properties:
- compatible = "mundoreader,bq-curie2", "rockchip,rk3066a";
- ChipSPARK Rayeager PX2 board:
Required root node properties:
- compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
- Radxa Rock board:
Required root node properties:
- compatible = "radxa,rock", "rockchip,rk3188";
- Firefly Firefly-RK3288 board:
Required root node properties:
- compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
or
- compatible = "firefly,firefly-rk3288-beta", "rockchip,rk3288";

16
Bindings/arm/rockchip/pmu-sram.txt Normal file
View File

@ -0,0 +1,16 @@
Rockchip SRAM for pmu:
------------------------------
The sram of pmu is used to store the function of resume from maskrom(the 1st
level loader). This is a common use of the "pmu-sram" because it keeps power
even in low power states in the system.
Required node properties:
- compatible : should be "rockchip,rk3288-pmu-sram"
- reg : physical base address and the size of the registers window
Example:
sram@ff720000 {
compatible = "rockchip,rk3288-pmu-sram", "mmio-sram";
reg = <0xff720000 0x1000>;
};

19
Bindings/arm/samsung-boards.txt
View File

@ -1,11 +1,20 @@
* Samsung's Exynos4210 based SMDKV310 evaluation board
SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC.
* Samsung's Exynos SoC based boards
Required root node properties:
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
- "samsung,monk" - for Exynos3250-based Samsung Simband board.
- "samsung,rinato" - for Exynos3250-based Samsung Gear2 board.
- "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board.
- "samsung,trats" - for Exynos4210-based Tizen Reference board.
- "samsung,universal_c210" - for Exynos4210-based Samsung board.
- "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board.
- "samsung,trats2" - for Exynos4412-based Tizen Reference board.
- "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board.
- "samsung,xyref5260" - for Exynos5260-based Samsung board.
- "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board.
- "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board.
- "samsung,sd5v1" - for Exynos5440-based Samsung board.
- "samsung,ssdk5440" - for Exynos5440-based Samsung board.
Optional:
- firmware node, specifying presence and type of secure firmware:

29
Bindings/arm/samsung/exynos-adc.txt
View File

@ -11,13 +11,27 @@ New driver handles the following
Required properties:
- compatible: Must be "samsung,exynos-adc-v1"
for exynos4412/5250 controllers.
for exynos4412/5250 and s5pv210 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
Must be "samsung,exynos3250-adc" for
controllers compatible with ADC of Exynos3250.
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
Must be "samsung,exynos7-adc" for
the ADC in Exynos7 and compatibles
Must be "samsung,s3c2410-adc" for
the ADC in s3c2410 and compatibles
Must be "samsung,s3c2416-adc" for
the ADC in s3c2416 and compatibles
Must be "samsung,s3c2440-adc" for
the ADC in s3c2440 and compatibles
Must be "samsung,s3c2443-adc" for
the ADC in s3c2443 and compatibles
Must be "samsung,s3c6410-adc" for
the ADC in s3c6410 and compatibles
- reg: List of ADC register address range
- The base address and range of ADC register
- The base address and range of ADC_PHY register (every
SoC except for s3c24xx/s3c64xx ADC)
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the Samsung device uses.
@ -31,13 +45,16 @@ Required properties:
compatible ADC block)
- vdd-supply VDD input supply.
- samsung,syscon-phandle Contains the PMU system controller node
(To access the ADC_PHY register on Exynos5250/5420/5800/3250)
Note: child nodes can be added for auto probing from device tree.
Example: adding device info in dtsi file
adc: adc@12D10000 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D10000 0x100>, <0x10040718 0x4>;
reg = <0x12D10000 0x100>;
interrupts = <0 106 0>;
#io-channel-cells = <1>;
io-channel-ranges;
@ -46,13 +63,14 @@ adc: adc@12D10000 {
clock-names = "adc";
vdd-supply = <&buck5_reg>;
samsung,syscon-phandle = <&pmu_system_controller>;
};
Example: adding device info in dtsi file for Exynos3250 with additional sclk
adc: adc@126C0000 {
compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2;
reg = <0x126C0000 0x100>, <0x10020718 0x4>;
reg = <0x126C0000 0x100>;
interrupts = <0 137 0>;
#io-channel-cells = <1>;
io-channel-ranges;
@ -61,6 +79,7 @@ adc: adc@126C0000 {
clock-names = "adc", "sclk";
vdd-supply = <&buck5_reg>;
samsung,syscon-phandle = <&pmu_system_controller>;
};
Example: Adding child nodes in dts file

12
Bindings/arm/samsung/exynos-chipid.txt Normal file
View File

@ -0,0 +1,12 @@
SAMSUNG Exynos SoCs Chipid driver.
Required properties:
- compatible : Should at least contain "samsung,exynos4210-chipid".
- reg: offset and length of the register set
Example:
chipid@10000000 {
compatible = "samsung,exynos4210-chipid";
reg = <0x10000000 0x100>;
};

1
Bindings/arm/samsung/pmu.txt
View File

@ -10,6 +10,7 @@ Properties:
- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
- "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
- reg : offset and length of the register set.

71
Bindings/arm/shmobile.txt Normal file
View File

@ -0,0 +1,71 @@
Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings
--------------------------------------------------------------------
SoCs:
- Emma Mobile EV2
compatible = "renesas,emev2"
- RZ/A1H (R7S72100)
compatible = "renesas,r7s72100"
- SH-Mobile AP4 (R8A73720/SH7372)
compatible = "renesas,sh7372"
- SH-Mobile AG5 (R8A73A00/SH73A0)
compatible = "renesas,sh73a0"
- R-Mobile APE6 (R8A73A40)
compatible = "renesas,r8a73a4"
- R-Mobile A1 (R8A77400)
compatible = "renesas,r8a7740"
- R-Car M1A (R8A77781)
compatible = "renesas,r8a7778"
- R-Car H1 (R8A77790)
compatible = "renesas,r8a7779"
- R-Car H2 (R8A77900)
compatible = "renesas,r8a7790"
- R-Car M2-W (R8A77910)
compatible = "renesas,r8a7791"
- R-Car V2H (R8A77920)
compatible = "renesas,r8a7792"
- R-Car M2-N (R8A77930)
compatible = "renesas,r8a7793"
- R-Car E2 (R8A77940)
compatible = "renesas,r8a7794"
Boards:
- Alt
compatible = "renesas,alt", "renesas,r8a7794"
- APE6-EVM
compatible = "renesas,ape6evm", "renesas,r8a73a4"
- APE6-EVM - Reference Device Tree Implementation
compatible = "renesas,ape6evm-reference", "renesas,r8a73a4"
- Atmark Techno Armadillo-800 EVA
compatible = "renesas,armadillo800eva"
- BOCK-W
compatible = "renesas,bockw", "renesas,r8a7778"
- BOCK-W - Reference Device Tree Implementation
compatible = "renesas,bockw-reference", "renesas,r8a7778"
- Genmai (RTK772100BC00000BR)
compatible = "renesas,genmai", "renesas,r7s72100"
- Gose
compatible = "renesas,gose", "renesas,r8a7793"
- Henninger
compatible = "renesas,henninger", "renesas,r8a7791"
- Koelsch (RTP0RC7791SEB00010S)
compatible = "renesas,koelsch", "renesas,r8a7791"
- Kyoto Microcomputer Co. KZM-A9-Dual
compatible = "renesas,kzm9d", "renesas,emev2"
- Kyoto Microcomputer Co. KZM-A9-GT
compatible = "renesas,kzm9g", "renesas,sh73a0"
- Kyoto Microcomputer Co. KZM-A9-GT - Reference Device Tree Implementation
compatible = "renesas,kzm9g-reference", "renesas,sh73a0"
- Lager (RTP0RC7790SEB00010S)
compatible = "renesas,lager", "renesas,r8a7790"
- Mackerel (R0P7372LC0016RL, AP4 EVM 2nd)
compatible = "renesas,mackerel"
- Marzen
compatible = "renesas,marzen", "renesas,r8a7779"
Note: Reference Device Tree Implementations are temporary implementations
to ease the migration from platform devices to Device Tree, and are
intended to be removed in the future.

6
Bindings/arm/sirf.txt
View File

@ -3,7 +3,9 @@ CSR SiRFprimaII and SiRFmarco device tree bindings.
Required root node properties:
- compatible:
- "sirf,atlas6-cb" : atlas6 "cb" evaluation board
- "sirf,atlas6" : atlas6 device based board
- "sirf,atlas7-cb" : atlas7 "cb" evaluation board
- "sirf,atlas7" : atlas7 device based board
- "sirf,prima2-cb" : prima2 "cb" evaluation board
- "sirf,marco-cb" : marco "cb" evaluation board
- "sirf,prima2" : prima2 device based board
- "sirf,marco" : marco device based board

11
Bindings/arm/sprd.txt Normal file
View File

@ -0,0 +1,11 @@
Spreadtrum SoC Platforms Device Tree Bindings
----------------------------------------------------
Sharkl64 is a Spreadtrum's SoC Platform which is based
on ARM 64-bit processor.
SC9836 openphone board with SC9836 SoC based on the
Sharkl64 Platform shall have the following properties.
Required root node properties:
- compatible = "sprd,sc9836-openphone", "sprd,sc9836";

6
Bindings/arm/ste-nomadik.txt
View File

@ -10,6 +10,12 @@ Required root node property: src
Boards with the Nomadik SoC include:
Nomadik NHK-15 board manufactured by ST Microelectronics:
Required root node property:
compatible="st,nomadik-nhk-15";
S8815 "MiniKit" manufactured by Calao Systems:
Required root node property:

4
Bindings/arm/sti.txt
View File

@ -13,3 +13,7 @@ Boards with the ST STiH407 SoC shall have the following properties:
Required root node property:
compatible = "st,stih407";
Boards with the ST STiH418 SoC shall have the following properties:
Required root node property:
compatible = "st,stih418";

12
Bindings/arm/sunxi.txt Normal file
View File

@ -0,0 +1,12 @@
Allwinner sunXi Platforms Device Tree Bindings
Each device tree must specify which Allwinner SoC it uses,
using one of the following compatible strings:
allwinner,sun4i-a10
allwinner,sun5i-a10s
allwinner,sun5i-a13
allwinner,sun6i-a31
allwinner,sun7i-a20
allwinner,sun8i-a23
allwinner,sun9i-a80

5
Bindings/arm/tegra/nvidia,tegra20-ahb.txt
View File

@ -1,7 +1,10 @@
NVIDIA Tegra AHB
Required properties:
- compatible : "nvidia,tegra20-ahb" or "nvidia,tegra30-ahb"
- compatible : For Tegra20, must contain "nvidia,tegra20-ahb". For
Tegra30, must contain "nvidia,tegra30-ahb". Otherwise, must contain
'"nvidia,<chip>-ahb", "nvidia,tegra30-ahb"' where <chip> is tegra124,
tegra132, or tegra210.
- reg : Should contain 1 register ranges(address and length)
Example:

12
Bindings/arm/tegra/nvidia,tegra20-flowctrl.txt Normal file
View File

@ -0,0 +1,12 @@
NVIDIA Tegra Flow Controller
Required properties:
- compatible: Should be "nvidia,tegra<chip>-flowctrl"
- reg: Should contain one register range (address and length)
Example:
flow-controller@60007000 {
compatible = "nvidia,tegra20-flowctrl";
reg = <0x60007000 0x1000>;
};

32
Bindings/arm/tegra/nvidia,tegra20-pmc.txt
View File

@ -6,7 +6,11 @@ modes. It provides power-gating controllers for SoC and CPU power-islands.
Required properties:
- name : Should be pmc
- compatible : Should contain "nvidia,tegra<chip>-pmc".
- compatible : For Tegra20, must contain "nvidia,tegra20-pmc". For Tegra30,
must contain "nvidia,tegra30-pmc". For Tegra114, must contain
"nvidia,tegra114-pmc". For Tegra124, must contain "nvidia,tegra124-pmc".
Otherwise, must contain "nvidia,<chip>-pmc", plus at least one of the
above, where <chip> is tegra132.
- reg : Offset and length of the register set for the device
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
@ -47,6 +51,23 @@ Required properties when nvidia,suspend-mode=<0>:
sleep mode, the warm boot code will restore some PLLs, clocks and then
bring up CPU0 for resuming the system.
Hardware-triggered thermal reset:
On Tegra30, Tegra114 and Tegra124, if the 'i2c-thermtrip' subnode exists,
hardware-triggered thermal reset will be enabled.
Required properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'):
- nvidia,i2c-controller-id : ID of I2C controller to send poweroff command to. Valid values are
described in section 9.2.148 "APBDEV_PMC_SCRATCH53_0" of the
Tegra K1 Technical Reference Manual.
- nvidia,bus-addr : Bus address of the PMU on the I2C bus
- nvidia,reg-addr : I2C register address to write poweroff command to
- nvidia,reg-data : Poweroff command to write to PMU
Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'):
- nvidia,pinmux-id : Pinmux used by the hardware when issuing poweroff command.
Defaults to 0. Valid values are described in section 12.5.2
"Pinmux Support" of the Tegra4 Technical Reference Manual.
Example:
/ SoC dts including file
@ -68,6 +89,15 @@ pmc@7000f400 {
/ Tegra board dts file
{
...
pmc@7000f400 {
i2c-thermtrip {
nvidia,i2c-controller-id = <4>;
nvidia,bus-addr = <0x40>;
nvidia,reg-addr = <0x36>;
nvidia,reg-data = <0x2>;
};
};
...
clocks {
compatible = "simple-bus";

35
Bindings/arm/ux500/power_domain.txt Normal file
View File

@ -0,0 +1,35 @@
* ST-Ericsson UX500 PM Domains
UX500 supports multiple PM domains which are used to gate power to one or
more peripherals on the SOC.
The implementation of PM domains for UX500 are based upon the generic PM domain
and use the corresponding DT bindings.
==PM domain providers==
Required properties:
- compatible: Must be "stericsson,ux500-pm-domains".
- #power-domain-cells : Number of cells in a power domain specifier, must be 1.
Example:
pm_domains: pm_domains0 {
compatible = "stericsson,ux500-pm-domains";
#power-domain-cells = <1>;
};
==PM domain consumers==
Required properties:
- power-domains: A phandle and PM domain specifier. Below are the list of
valid specifiers:
Index Specifier
----- ---------
0 DOMAIN_VAPE
Example:
sdi0_per1@80126000 {
compatible = "arm,pl18x", "arm,primecell";
power-domains = <&pm_domains DOMAIN_VAPE>
};

10
Bindings/arm/versatile-sysreg.txt Normal file
View File

@ -0,0 +1,10 @@
ARM Versatile system registers
--------------------------------------
This is a system control registers block, providing multiple low level
platform functions like board detection and identification, software
interrupt generation, MMC and NOR Flash control etc.
Required node properties:
- compatible value : = "arm,versatile-sysreg", "syscon"
- reg : physical base address and the size of the registers window

9
Bindings/ata/ahci-platform.txt
View File

@ -37,9 +37,10 @@ Required properties when using sub-nodes:
Sub-nodes required properties:
- reg : the port number
- phys : reference to the SATA PHY node
- reg : the port number
And at least one of the following properties:
- phys : reference to the SATA PHY node
- target-supply : regulator for SATA target power
Examples:
sata@ffe08000 {
@ -68,10 +69,12 @@ With sub-nodes:
sata0: sata-port@0 {
reg = <0>;
phys = <&sata_phy 0>;
target-supply = <&reg_sata0>;
};
sata1: sata-port@1 {
reg = <1>;
phys = <&sata_phy 1>;
target-supply = <&reg_sata1>;;
};
};

2
Bindings/ata/cavium-compact-flash.txt
View File

@ -9,7 +9,7 @@ Properties:
Compatibility with many Cavium evaluation boards.
- reg: The base address of the the CF chip select banks. Depending on
- reg: The base address of the CF chip select banks. Depending on
the device configuration, there may be one or two banks.
- cavium,bus-width: The width of the connection to the CF devices. Valid

6
Bindings/ata/marvell.txt
View File

@ -6,11 +6,17 @@ Required Properties:
- interrupts : Interrupt controller is using
- nr-ports : Number of SATA ports in use.
Optional Properties:
- phys : List of phandles to sata phys
- phy-names : Should be "0", "1", etc, one number per phandle
Example:
sata@80000 {
compatible = "marvell,orion-sata";
reg = <0x80000 0x5000>;
interrupts = <21>;
phys = <&sata_phy0>, <&sata_phy1>;
phy-names = "0", "1";
nr-ports = <2>;
}

48
Bindings/ata/qcom-sata.txt Normal file
View File

@ -0,0 +1,48 @@
* Qualcomm AHCI SATA Controller
SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
Required properties:
- compatible : compatible list, must contain "generic-ahci"
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>
- phys : Must contain exactly one entry as specified
in phy-bindings.txt
- phy-names : Must be "sata-phy"
Required properties for "qcom,ipq806x-ahci" compatible:
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Shall be:
"slave_iface" - Fabric port AHB clock for SATA
"iface" - AHB clock
"core" - core clock
"rxoob" - RX out-of-band clock
"pmalive" - Power Module Alive clock
- assigned-clocks : Shall be:
SATA_RXOOB_CLK
SATA_PMALIVE_CLK
- assigned-clock-rates : Shall be:
100Mhz (100000000) for SATA_RXOOB_CLK
100Mhz (100000000) for SATA_PMALIVE_CLK
Example:
sata@29000000 {
compatible = "qcom,ipq806x-ahci", "generic-ahci";
reg = <0x29000000 0x180>;
interrupts = <0 209 0x0>;
clocks = <&gcc SFAB_SATA_S_H_CLK>,
<&gcc SATA_H_CLK>,
<&gcc SATA_A_CLK>,
<&gcc SATA_RXOOB_CLK>,
<&gcc SATA_PMALIVE_CLK>;
clock-names = "slave_iface", "iface", "core",
"rxoob", "pmalive";
assigned-clocks = <&gcc SATA_RXOOB_CLK>, <&gcc SATA_PMALIVE_CLK>;
assigned-clock-rates = <100000000>, <100000000>;
phys = <&sata_phy>;
phy-names = "sata-phy";
};

17
Bindings/ata/sata_rcar.txt
View File

@ -3,16 +3,21 @@
Required properties:
- compatible : should contain one of the following:
- "renesas,sata-r8a7779" for R-Car H1
- "renesas,sata-r8a7790" for R-Car H2
- "renesas,sata-r8a7791" for R-Car M2
("renesas,rcar-sata" is deprecated)
- "renesas,sata-r8a7790-es1" for R-Car H2 ES1
- "renesas,sata-r8a7790" for R-Car H2 other than ES1
- "renesas,sata-r8a7791" for R-Car M2-W
- "renesas,sata-r8a7793" for R-Car M2-N
- reg : address and length of the SATA registers;
- interrupts : must consist of one interrupt specifier.
- clocks : must contain a reference to the functional clock.
Example:
sata: sata@fc600000 {
compatible = "renesas,sata-r8a7779";
reg = <0xfc600000 0x2000>;
sata0: sata@ee300000 {
compatible = "renesas,sata-r8a7791";
reg = <0 0xee300000 0 0x2000>;
interrupt-parent = <&gic>;
interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp8_clks R8A7791_CLK_SATA0>;
};

4
Bindings/ata/tegra-sata.txt
View File

@ -1,7 +1,9 @@
Tegra124 SoC SATA AHCI controller
Required properties :
- compatible : "nvidia,tegra124-ahci".
- compatible : For Tegra124, must contain "nvidia,tegra124-ahci". Otherwise,
must contain '"nvidia,<chip>-ahci", "nvidia,tegra124-ahci"', where <chip>
is tegra132.
- reg : Should contain 2 entries:
- AHCI register set (SATA BAR5)
- SATA register set

29
Bindings/btmrvl.txt Normal file
View File

@ -0,0 +1,29 @@
btmrvl
------
Required properties:
- compatible : must be "btmrvl,cfgdata"
Optional properties:
- btmrvl,cal-data : Calibration data downloaded to the device during
initialization. This is an array of 28 values(u8).
- btmrvl,gpio-gap : gpio and gap (in msecs) combination to be
configured.
Example:
GPIO pin 13 is configured as a wakeup source and GAP is set to 100 msecs
in below example.
btmrvl {
compatible = "btmrvl,cfgdata";
btmrvl,cal-data = /bits/ 8 <
0x37 0x01 0x1c 0x00 0xff 0xff 0xff 0xff 0x01 0x7f 0x04 0x02
0x00 0x00 0xba 0xce 0xc0 0xc6 0x2d 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0xf0 0x00>;
btmrvl,gpio-gap = <0x0d64>;
};

53
Bindings/bus/bcma.txt Normal file
View File

@ -0,0 +1,53 @@
Driver for ARM AXI Bus with Broadcom Plugins (bcma)
Required properties:
- compatible : brcm,bus-axi
- reg : iomem address range of chipcommon core
The cores on the AXI bus are automatically detected by bcma with the
memory ranges they are using and they get registered afterwards.
Automatic detection of the IRQ number is not working on
BCM47xx/BCM53xx ARM SoCs. To assign IRQ numbers to the cores, provide
them manually through device tree. Use an interrupt-map to specify the
IRQ used by the devices on the bus. The first address is just an index,
because we do not have any special register.
The top-level axi bus may contain children representing attached cores
(devices). This is needed since some hardware details can't be auto
detected (e.g. IRQ numbers). Also some of the cores may be responsible
for extra things, e.g. ChipCommon providing access to the GPIO chip.
Example:
axi@18000000 {
compatible = "brcm,bus-axi";
reg = <0x18000000 0x1000>;
ranges = <0x00000000 0x18000000 0x00100000>;
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <1>;
interrupt-map-mask = <0x000fffff 0xffff>;
interrupt-map =
/* Ethernet Controller 0 */
<0x00024000 0 &gic GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
/* Ethernet Controller 1 */
<0x00025000 0 &gic GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
/* PCIe Controller 0 */
<0x00012000 0 &gic GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
<0x00012000 1 &gic GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>,
<0x00012000 2 &gic GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
<0x00012000 3 &gic GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
<0x00012000 4 &gic GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
<0x00012000 5 &gic GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
chipcommon {
reg = <0x00000000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
};
};

6
Bindings/bus/brcm,gisb-arb.txt
View File

@ -2,7 +2,11 @@ Broadcom GISB bus Arbiter controller
Required properties:
- compatible: should be "brcm,gisb-arb"
- compatible:
"brcm,gisb-arb" or "brcm,bcm7445-gisb-arb" for 28nm chips
"brcm,bcm7435-gisb-arb" for newer 40nm chips
"brcm,bcm7400-gisb-arb" for older 40nm chips and all 65nm chips
"brcm,bcm7038-gisb-arb" for 130nm chips
- reg: specifies the base physical address and size of the registers
- interrupt-parent: specifies the phandle to the parent interrupt controller
this arbiter gets interrupt line from

21
Bindings/bus/mvebu-mbus.txt
View File

@ -6,8 +6,8 @@ Required properties:
- compatible: Should be set to one of the following:
marvell,armada370-mbus
marvell,armadaxp-mbus
marvell,armada370-mbus
marvell,armadaxp-mbus
marvell,armada375-mbus
marvell,armada380-mbus
marvell,kirkwood-mbus
marvell,dove-mbus
marvell,orion5x-88f5281-mbus
@ -48,9 +48,12 @@ Required properties:
- compatible: Should be set to "marvell,mbus-controller".
- reg: Device's register space.
Two entries are expected (see the examples below):
the first one controls the devices decoding window and
the second one controls the SDRAM decoding window.
Two or three entries are expected (see the examples below):
the first one controls the devices decoding window,
the second one controls the SDRAM decoding window and
the third controls the MBus bridge (only with the
marvell,armada370-mbus and marvell,armadaxp-mbus
compatible strings)
Example:
@ -67,7 +70,7 @@ Example:
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
@ -126,7 +129,7 @@ are skipped.
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
@ -170,7 +173,7 @@ Using this macro, the above example would be:
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* other children */
@ -266,7 +269,7 @@ See the example below, where a more complete device tree is shown:
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
mbusc: mbus-controller@20000 {
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
interrupt-controller@20000 {

2
Bindings/c6x/dscr.txt
View File

@ -12,7 +12,7 @@ configuration register for writes. These configuration register may be used to
enable (and disable in some cases) SoC pin drivers, select peripheral clock
sources (internal or pin), etc. In some cases, a configuration register is
write once or the individual bits are write once. In addition to device config,
the DSCR block may provide registers which which are used to reset peripherals,
the DSCR block may provide registers which are used to reset peripherals,
provide device ID information, provide ethernet MAC addresses, as well as other
miscellaneous functions.

46
Bindings/chosen.txt Normal file
View File

@ -0,0 +1,46 @@
The chosen node
---------------
The chosen node does not represent a real device, but serves as a place
for passing data between firmware and the operating system, like boot
arguments. Data in the chosen node does not represent the hardware.
stdout-path property
--------------------
Device trees may specify the device to be used for boot console output
with a stdout-path property under /chosen, as described in ePAPR, e.g.
/ {
chosen {
stdout-path = "/serial@f00:115200";
};
serial@f00 {
compatible = "vendor,some-uart";
reg = <0xf00 0x10>;
};
};
If the character ":" is present in the value, this terminates the path.
The meaning of any characters following the ":" is device-specific, and
must be specified in the relevant binding documentation.
For UART devices, the preferred binding is a string in the form:
<baud>{<parity>{<bits>{<flow>}}}
where
baud - baud rate in decimal
parity - 'n' (none), 'o', (odd) or 'e' (even)
bits - number of data bits
flow - 'r' (rts)
For example: 115200n8r
Implementation note: Linux will look for the property "linux,stdout-path" or
on PowerPC "stdout" if "stdout-path" is not found. However, the
"linux,stdout-path" and "stdout" properties are deprecated. New platforms
should only use the "stdout-path" property.

115
Bindings/clock/alphascale,acc.txt Normal file
View File

@ -0,0 +1,115 @@
Alphascale Clock Controller
The ACC (Alphascale Clock Controller) is responsible of choising proper
clock source, setting deviders and clock gates.
Required properties for the ACC node:
- compatible: must be "alphascale,asm9260-clock-controller"
- reg: must contain the ACC register base and size
- #clock-cells : shall be set to 1.
Simple one-cell clock specifier format is used, where the only cell is used
as an index of the clock inside the provider.
It is encouraged to use dt-binding for clock index definitions. SoC specific
dt-binding should be included to the device tree descriptor. For example
Alphascale ASM9260:
#include <dt-bindings/clock/alphascale,asm9260.h>
This binding contains two types of clock providers:
_AHB_ - AHB gate;
_SYS_ - adjustable clock source. Not all peripheral have _SYS_ clock provider.
All clock specific details can be found in the SoC documentation.
CLKID_AHB_ROM 0
CLKID_AHB_RAM 1
CLKID_AHB_GPIO 2
CLKID_AHB_MAC 3
CLKID_AHB_EMI 4
CLKID_AHB_USB0 5
CLKID_AHB_USB1 6
CLKID_AHB_DMA0 7
CLKID_AHB_DMA1 8
CLKID_AHB_UART0 9
CLKID_AHB_UART1 10
CLKID_AHB_UART2 11
CLKID_AHB_UART3 12
CLKID_AHB_UART4 13
CLKID_AHB_UART5 14
CLKID_AHB_UART6 15
CLKID_AHB_UART7 16
CLKID_AHB_UART8 17
CLKID_AHB_UART9 18
CLKID_AHB_I2S0 19
CLKID_AHB_I2C0 20
CLKID_AHB_I2C1 21
CLKID_AHB_SSP0 22
CLKID_AHB_IOCONFIG 23
CLKID_AHB_WDT 24
CLKID_AHB_CAN0 25
CLKID_AHB_CAN1 26
CLKID_AHB_MPWM 27
CLKID_AHB_SPI0 28
CLKID_AHB_SPI1 29
CLKID_AHB_QEI 30
CLKID_AHB_QUADSPI0 31
CLKID_AHB_CAMIF 32
CLKID_AHB_LCDIF 33
CLKID_AHB_TIMER0 34
CLKID_AHB_TIMER1 35
CLKID_AHB_TIMER2 36
CLKID_AHB_TIMER3 37
CLKID_AHB_IRQ 38
CLKID_AHB_RTC 39
CLKID_AHB_NAND 40
CLKID_AHB_ADC0 41
CLKID_AHB_LED 42
CLKID_AHB_DAC0 43
CLKID_AHB_LCD 44
CLKID_AHB_I2S1 45
CLKID_AHB_MAC1 46
CLKID_SYS_CPU 47
CLKID_SYS_AHB 48
CLKID_SYS_I2S0M 49
CLKID_SYS_I2S0S 50
CLKID_SYS_I2S1M 51
CLKID_SYS_I2S1S 52
CLKID_SYS_UART0 53
CLKID_SYS_UART1 54
CLKID_SYS_UART2 55
CLKID_SYS_UART3 56
CLKID_SYS_UART4 56
CLKID_SYS_UART5 57
CLKID_SYS_UART6 58
CLKID_SYS_UART7 59
CLKID_SYS_UART8 60
CLKID_SYS_UART9 61
CLKID_SYS_SPI0 62
CLKID_SYS_SPI1 63
CLKID_SYS_QUADSPI 64
CLKID_SYS_SSP0 65
CLKID_SYS_NAND 66
CLKID_SYS_TRACE 67
CLKID_SYS_CAMM 68
CLKID_SYS_WDT 69
CLKID_SYS_CLKOUT 70
CLKID_SYS_MAC 71
CLKID_SYS_LCD 72
CLKID_SYS_ADCANA 73
Example of clock consumer with _SYS_ and _AHB_ sinks.
uart4: serial@80010000 {
compatible = "alphascale,asm9260-uart";
reg = <0x80010000 0x4000>;
clocks = <&acc CLKID_SYS_UART4>, <&acc CLKID_AHB_UART4>;
interrupts = <19>;
status = "disabled";
};
Clock consumer with only one, _AHB_ sink.
timer0: timer@80088000 {
compatible = "alphascale,asm9260-timer";
reg = <0x80088000 0x4000>;
clocks = <&acc CLKID_AHB_TIMER0>;
interrupts = <29>;
};

2
Bindings/clock/arm-integrator.txt
View File

@ -1,6 +1,6 @@
Clock bindings for ARM Integrator and Versatile Core Module clocks
Auxilary Oscillator Clock
Auxiliary Oscillator Clock
This is a configurable clock fed from a 24 MHz chrystal,
used for generating e.g. video clocks. It is located on the

14
Bindings/clock/at91-clock.txt
View File

@ -74,6 +74,9 @@ Required properties:
"atmel,at91sam9x5-clk-utmi":
at91 utmi clock
"atmel,sama5d4-clk-h32mx":
at91 h32mx clock
Required properties for SCKC node:
- reg : defines the IO memory reserved for the SCKC.
- #size-cells : shall be 0 (reg is used to encode clk id).
@ -447,3 +450,14 @@ For example:
#clock-cells = <0>;
clocks = <&main>;
};
Required properties for 32 bits bus Matrix clock (h32mx clock):
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : shall be the master clock source phandle.
For example:
h32ck: h32mxck {
#clock-cells = <0>;
compatible = "atmel,sama5d4-clk-h32mx";
clocks = <&mck>;
};

34
Bindings/clock/bcm-cygnus-clock.txt Normal file
View File

@ -0,0 +1,34 @@
Broadcom Cygnus Clocks
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
Currently various "fixed" clocks are declared for peripheral drivers that use
the common clock framework to reference their core clocks. Proper support of
these clocks will be added later
Device tree example:
clocks {
#address-cells = <1>;
#size-cells = <1>;
ranges;
osc: oscillator {
compatible = "fixed-clock";
#clock-cells = <1>;
clock-frequency = <25000000>;
};
apb_clk: apb_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1000000000>;
};
periph_clk: periph_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <500000000>;
};
};

10
Bindings/clock/exynos3250-clock.txt
View File

@ -7,6 +7,8 @@ Required Properties:
- compatible: should be one of the following.
- "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
- "samsung,exynos3250-cmu-dmc" - controller compatible with
Exynos3250 SoC for Dynamic Memory Controller domain.
- reg: physical base address of the controller and length of memory mapped
region.
@ -20,7 +22,7 @@ All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos3250.h header and can be used in device
tree sources.
Example 1: An example of a clock controller node is listed below.
Example 1: Examples of clock controller nodes are listed below.
cmu: clock-controller@10030000 {
compatible = "samsung,exynos3250-cmu";
@ -28,6 +30,12 @@ Example 1: An example of a clock controller node is listed below.
#clock-cells = <1>;
};
cmu_dmc: clock-controller@105C0000 {
compatible = "samsung,exynos3250-cmu-dmc";
reg = <0x105C0000 0x2000>;
#clock-cells = <1>;
};
Example 2: UART controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.

38
Bindings/clock/exynos4415-clock.txt Normal file
View File

@ -0,0 +1,38 @@
* Samsung Exynos4415 Clock Controller
The Exynos4415 clock controller generates and supplies clock to various
consumer devices within the Exynos4415 SoC.
Required properties:
- compatible: should be one of the following:
- "samsung,exynos4415-cmu" - for the main system clocks controller
(CMU_LEFTBUS, CMU_RIGHTBUS, CMU_TOP, CMU_CPU clock domains).
- "samsung,exynos4415-cmu-dmc" - for the Exynos4415 SoC DRAM Memory
Controller (DMC) domain clock controller.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos4415.h header and can be used in device
tree sources.
Example 1: An example of a clock controller node is listed below.
cmu: clock-controller@10030000 {
compatible = "samsung,exynos4415-cmu";
reg = <0x10030000 0x18000>;
#clock-cells = <1>;
};
cmu-dmc: clock-controller@105C0000 {
compatible = "samsung,exynos4415-cmu-dmc";
reg = <0x105C0000 0x3000>;
#clock-cells = <1>;
};

108
Bindings/clock/exynos7-clock.txt Normal file
View File

@ -0,0 +1,108 @@
* Samsung Exynos7 Clock Controller
Exynos7 clock controller has various blocks which are instantiated
independently from the device-tree. These clock controllers
generate and supply clocks to various hardware blocks within
the SoC.
Each clock is assigned an identifier and client nodes can use
this identifier to specify the clock which they consume. All
available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos7-clk.h header and can be used in
device tree sources.
External clocks:
There are several clocks that are generated outside the SoC. It
is expected that they are defined using standard clock bindings
with following clock-output-names:
- "fin_pll" - PLL input clock from XXTI
Required Properties for Clock Controller:
- compatible: clock controllers will use one of the following
compatible strings to indicate the clock controller
functionality.
- "samsung,exynos7-clock-topc"
- "samsung,exynos7-clock-top0"
- "samsung,exynos7-clock-top1"
- "samsung,exynos7-clock-ccore"
- "samsung,exynos7-clock-peric0"
- "samsung,exynos7-clock-peric1"
- "samsung,exynos7-clock-peris"
- "samsung,exynos7-clock-fsys0"
- "samsung,exynos7-clock-fsys1"
- "samsung,exynos7-clock-mscl"
- "samsung,exynos7-clock-aud"
- reg: physical base address of the controller and the length of
memory mapped region.
- #clock-cells: should be 1.
- clocks: list of clock identifiers which are fed as the input to
the given clock controller. Please refer the next section to
find the input clocks for a given controller.
- clock-names: list of names of clocks which are fed as the input
to the given clock controller.
Input clocks for top0 clock controller:
- fin_pll
- dout_sclk_bus0_pll
- dout_sclk_bus1_pll
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
- dout_sclk_aud_pll
Input clocks for top1 clock controller:
- fin_pll
- dout_sclk_bus0_pll
- dout_sclk_bus1_pll
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
Input clocks for ccore clock controller:
- fin_pll
- dout_aclk_ccore_133
Input clocks for peric0 clock controller:
- fin_pll
- dout_aclk_peric0_66
- sclk_uart0
Input clocks for peric1 clock controller:
- fin_pll
- dout_aclk_peric1_66
- sclk_uart1
- sclk_uart2
- sclk_uart3
- sclk_spi0
- sclk_spi1
- sclk_spi2
- sclk_spi3
- sclk_spi4
- sclk_i2s1
- sclk_pcm1
- sclk_spdif
Input clocks for peris clock controller:
- fin_pll
- dout_aclk_peris_66
Input clocks for fsys0 clock controller:
- fin_pll
- dout_aclk_fsys0_200
- dout_sclk_mmc2
Input clocks for fsys1 clock controller:
- fin_pll
- dout_aclk_fsys1_200
- dout_sclk_mmc0
- dout_sclk_mmc1
Input clocks for aud clock controller:
- fin_pll
- fout_aud_pll

21
Bindings/clock/gpio-gate-clock.txt Normal file
View File

@ -0,0 +1,21 @@
Binding for simple gpio gated clock.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "gpio-gate-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- enable-gpios : GPIO reference for enabling and disabling the clock.
Optional properties:
- clocks: Maximum of one parent clock is supported.
Example:
clock {
compatible = "gpio-gate-clock";
clocks = <&parentclk>;
#clock-cells = <0>;
enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
};

21
Bindings/clock/marvell,mmp2.txt Normal file
View File

@ -0,0 +1,21 @@
* Marvell MMP2 Clock Controller
The MMP2 clock subsystem generates and supplies clock to various
controllers within the MMP2 SoC.
Required Properties:
- compatible: should be one of the following.
- "marvell,mmp2-clock" - controller compatible with MMP2 SoC.
- reg: physical base address of the clock subsystem and length of memory mapped
region. There are 3 places in SOC has clock control logic:
"mpmu", "apmu", "apbc". So three reg spaces need to be defined.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume.
All these identifier could be found in <dt-bindings/clock/marvell-mmp2.h>.

21
Bindings/clock/marvell,pxa168.txt Normal file
View File

@ -0,0 +1,21 @@
* Marvell PXA168 Clock Controller
The PXA168 clock subsystem generates and supplies clock to various
controllers within the PXA168 SoC.
Required Properties:
- compatible: should be one of the following.
- "marvell,pxa168-clock" - controller compatible with PXA168 SoC.
- reg: physical base address of the clock subsystem and length of memory mapped
region. There are 3 places in SOC has clock control logic:
"mpmu", "apmu", "apbc". So three reg spaces need to be defined.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume.
All these identifier could be found in <dt-bindings/clock/marvell,pxa168.h>.

21
Bindings/clock/marvell,pxa910.txt Normal file
View File

@ -0,0 +1,21 @@
* Marvell PXA910 Clock Controller
The PXA910 clock subsystem generates and supplies clock to various
controllers within the PXA910 SoC.
Required Properties:
- compatible: should be one of the following.
- "marvell,pxa910-clock" - controller compatible with PXA910 SoC.
- reg: physical base address of the clock subsystem and length of memory mapped
region. There are 4 places in SOC has clock control logic:
"mpmu", "apmu", "apbc", "apbcp". So four reg spaces need to be defined.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume.
All these identifier could be found in <dt-bindings/clock/marvell-pxa910.h>.

16
Bindings/clock/maxim,max77686.txt
View File

@ -9,13 +9,21 @@ The MAX77686 contains three 32.768khz clock outputs that can be controlled
Following properties should be presend in main device node of the MFD chip.
Required properties:
- #clock-cells: simple one-cell clock specifier format is used, where the
only cell is used as an index of the clock inside the provider. Following
indices are allowed:
- #clock-cells: from common clock binding; shall be set to 1.
Optional properties:
- clock-output-names: From common clock binding.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. Following indices are allowed:
- 0: 32khz_ap clock,
- 1: 32khz_cp clock,
- 2: 32khz_pmic clock.
Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max77686.h
header and can be used in device tree sources.
Example: Node of the MFD chip
max77686: max77686@09 {
@ -34,5 +42,5 @@ Example: Clock consumer node
compatible = "bar,foo";
/* ... */
clock-names = "my-clock";
clocks = <&max77686 2>;
clocks = <&max77686 MAX77686_CLK_PMIC>;
};

44
Bindings/clock/maxim,max77802.txt Normal file
View File

@ -0,0 +1,44 @@
Binding for Maxim MAX77802 32k clock generator block
This is a part of device tree bindings of MAX77802 multi-function device.
More information can be found in bindings/mfd/max77802.txt file.
The MAX77802 contains two 32.768khz clock outputs that can be controlled
(gated/ungated) over I2C.
Following properties should be present in main device node of the MFD chip.
Required properties:
- #clock-cells: From common clock binding; shall be set to 1.
Optional properties:
- clock-output-names: From common clock binding.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. Following indices are allowed:
- 0: 32khz_ap clock,
- 1: 32khz_cp clock.
Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max77802.h
header and can be used in device tree sources.
Example: Node of the MFD chip
max77802: max77802@09 {
compatible = "maxim,max77802";
interrupt-parent = <&wakeup_eint>;
interrupts = <26 0>;
reg = <0x09>;
#clock-cells = <1>;
/* ... */
};
Example: Clock consumer node
foo@0 {
compatible = "bar,foo";
/* ... */
clock-names = "my-clock";
clocks = <&max77802 MAX77802_CLK_32K_AP>;
};

10
Bindings/clock/nvidia,tegra124-car.txt
View File

@ -1,4 +1,4 @@
NVIDIA Tegra124 Clock And Reset Controller
NVIDIA Tegra124 and Tegra132 Clock And Reset Controller
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
@ -7,14 +7,16 @@ The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
for muxing and gating Tegra's clocks, and setting their rates.
Required properties :
- compatible : Should be "nvidia,tegra124-car"
- compatible : Should be "nvidia,tegra124-car" or "nvidia,tegra132-car"
- reg : Should contain CAR registers location and length
- clocks : Should contain phandle and clock specifiers for two clocks:
the 32 KHz "32k_in", and the board-specific oscillator "osc".
- #clock-cells : Should be 1.
In clock consumers, this cell represents the clock ID exposed by the
CAR. The assignments may be found in header file
<dt-bindings/clock/tegra124-car.h>.
CAR. The assignments may be found in the header files
<dt-bindings/clock/tegra124-car-common.h> (which covers IDs common
to Tegra124 and Tegra132) and <dt-bindings/clock/tegra124-car.h>
(for Tegra124-specific clocks).
- #reset-cells : Should be 1.
In clock consumers, this cell represents the bit number in the CAR's
array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.

16
Bindings/clock/pxa-clock.txt Normal file
View File

@ -0,0 +1,16 @@
* Clock bindings for Marvell PXA chips
Required properties:
- compatible: Should be "marvell,pxa-clocks"
- #clock-cells: Should be <1>
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell (see include/.../pxa-clock.h).
Examples:
pxa2xx_clks: pxa2xx_clks@41300004 {
compatible = "marvell,pxa-clocks";
#clock-cells = <1>;
status = "okay";
};

21
Bindings/clock/qcom,lcc.txt Normal file
View File

@ -0,0 +1,21 @@
Qualcomm LPASS Clock & Reset Controller Binding
------------------------------------------------
Required properties :
- compatible : shall contain only one of the following:
"qcom,lcc-msm8960"
"qcom,lcc-apq8064"
"qcom,lcc-ipq8064"
- reg : shall contain base register location and length
- #clock-cells : shall contain 1
- #reset-cells : shall contain 1
Example:
clock-controller@28000000 {
compatible = "qcom,lcc-ipq8064";
reg = <0x28000000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

19
Bindings/clock/qoriq-clock.txt
View File

@ -1,6 +1,6 @@
* Clock Block on Freescale CoreNet Platforms
* Clock Block on Freescale QorIQ Platforms
Freescale CoreNet chips take primary clocking input from the external
Freescale qoriq chips take primary clocking input from the external
SYSCLK signal. The SYSCLK input (frequency) is multiplied using
multiple phase locked loops (PLL) to create a variety of frequencies
which can then be passed to a variety of internal logic, including
@ -29,6 +29,7 @@ Required properties:
* "fsl,t4240-clockgen"
* "fsl,b4420-clockgen"
* "fsl,b4860-clockgen"
* "fsl,ls1021a-clockgen"
Chassis clock strings include:
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
* "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
@ -62,6 +63,8 @@ Required properties:
It takes parent's clock-frequency as its clock.
* "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
It takes parent's clock-frequency as its clock.
* "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
* "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0)
- #clock-cells: From common clock binding. The number of cells in a
clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
@ -128,8 +131,16 @@ Example for clock block and clock provider:
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
clock-output-names = "cmux1";
};
platform-pll: platform-pll@c00 {
#clock-cells = <1>;
reg = <0xc00 0x4>;
compatible = "fsl,qoriq-platform-pll-1.0";
clocks = <&sysclk>;
clock-output-names = "platform-pll", "platform-pll-div2";
};
};
}
};
Example for clock consumer:
@ -139,4 +150,4 @@ Example for clock consumer:
clocks = <&mux0>;
...
};
}
};

18
Bindings/clock/renesas,cpg-div6-clocks.txt
View File

@ -7,11 +7,16 @@ to 64.
Required Properties:
- compatible: Must be one of the following
- "renesas,r8a73a4-div6-clock" for R8A73A4 (R-Mobile APE6) DIV6 clocks
- "renesas,r8a7740-div6-clock" for R8A7740 (R-Mobile A1) DIV6 clocks
- "renesas,r8a7790-div6-clock" for R8A7790 (R-Car H2) DIV6 clocks
- "renesas,r8a7791-div6-clock" for R8A7791 (R-Car M2) DIV6 clocks
- "renesas,sh73a0-div6-clock" for SH73A0 (SH-Mobile AG5) DIV6 clocks
- "renesas,cpg-div6-clock" for generic DIV6 clocks
- reg: Base address and length of the memory resource used by the DIV6 clock
- clocks: Reference to the parent clock
- clocks: Reference to the parent clock(s); either one, four, or eight
clocks must be specified. For clocks with multiple parents, invalid
settings must be specified as "<0>".
- #clock-cells: Must be 0
- clock-output-names: The name of the clock as a free-form string
@ -19,10 +24,11 @@ Required Properties:
Example
-------
sd2_clk: sd2_clk@e6150078 {
compatible = "renesas,r8a7790-div6-clock", "renesas,cpg-div6-clock";
reg = <0 0xe6150078 0 4>;
clocks = <&pll1_div2_clk>;
sdhi2_clk: sdhi2_clk@e615007c {
compatible = "renesas,r8a73a4-div6-clock", "renesas,cpg-div6-clock";
reg = <0 0xe615007c 0 4>;
clocks = <&pll1_div2_clk>, <&cpg_clocks R8A73A4_CLK_PLL2S>,
<0>, <&extal2_clk>;
#clock-cells = <0>;
clock-output-names = "sd2";
clock-output-names = "sdhi2ck";
};

12
Bindings/clock/renesas,cpg-mstp-clocks.txt
View File

@ -11,9 +11,13 @@ Required Properties:
- compatible: Must be one of the following
- "renesas,r7s72100-mstp-clocks" for R7S72100 (RZ) MSTP gate clocks
- "renesas,r8a73a4-mstp-clocks" for R8A73A4 (R-Mobile APE6) MSTP gate clocks
- "renesas,r8a7740-mstp-clocks" for R8A7740 (R-Mobile A1) MSTP gate clocks
- "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks
- "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks
- "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2) MSTP gate clocks
- "renesas,r8a7794-mstp-clocks" for R8A7794 (R-Car E2) MSTP gate clocks
- "renesas,sh73a0-mstp-clocks" for SH73A0 (SH-MobileAG5) MSTP gate clocks
- "renesas,cpg-mstp-clock" for generic MSTP gate clocks
- reg: Base address and length of the I/O mapped registers used by the MSTP
clocks. The first register is the clock control register and is mandatory.
@ -23,11 +27,11 @@ Required Properties:
must appear in the same order as the output clocks.
- #clock-cells: Must be 1
- clock-output-names: The name of the clocks as free-form strings
- renesas,clock-indices: Indices of the gate clocks into the group (0 to 31)
- clock-indices: Indices of the gate clocks into the group (0 to 31)
The clocks, clock-output-names and renesas,clock-indices properties contain one
entry per gate clock. The MSTP groups are sparsely populated. Unimplemented
gate clocks must not be declared.
The clocks, clock-output-names and clock-indices properties contain one entry
per gate clock. The MSTP groups are sparsely populated. Unimplemented gate
clocks must not be declared.
Example

33
Bindings/clock/renesas,r8a73a4-cpg-clocks.txt Normal file
View File

@ -0,0 +1,33 @@
* Renesas R8A73A4 Clock Pulse Generator (CPG)
The CPG generates core clocks for the R8A73A4 SoC. It includes five PLLs
and several fixed ratio dividers.
Required Properties:
- compatible: Must be "renesas,r8a73a4-cpg-clocks"
- reg: Base address and length of the memory resource used by the CPG
- clocks: Reference to the parent clocks ("extal1" and "extal2")
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "main",
"pll0", "pll1", "pll2", "pll2s", "pll2h", "z", "z2", "i", "m3", "b",
"m1", "m2", "zx", "zs", and "hp".
Example
-------
cpg_clocks: cpg_clocks@e6150000 {
compatible = "renesas,r8a73a4-cpg-clocks";
reg = <0 0xe6150000 0 0x10000>;
clocks = <&extal1_clk>, <&extal2_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0", "pll1", "pll2",
"pll2s", "pll2h", "z", "z2",
"i", "m3", "b", "m1", "m2",
"zx", "zs", "hp";
};

13
Bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
View File

@ -8,14 +8,18 @@ Required Properties:
- compatible: Must be one of
- "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
- "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
- "renesas,r8a7793-cpg-clocks" for the r8a7793 CPG
- "renesas,r8a7794-cpg-clocks" for the r8a7794 CPG
- "renesas,rcar-gen2-cpg-clocks" for the generic R-Car Gen2 CPG
- reg: Base address and length of the memory resource used by the CPG
- clocks: Reference to the parent clock
- clocks: References to the parent clocks: first to the EXTAL clock, second
to the USB_EXTAL clock
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "main",
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1" and "z"
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z", "rcan", and
"adsp"
Example
@ -25,8 +29,9 @@ Example
compatible = "renesas,r8a7790-cpg-clocks",
"renesas,rcar-gen2-cpg-clocks";
reg = <0 0xe6150000 0 0x1000>;
clocks = <&extal_clk>;
clocks = <&extal_clk &usb_extal_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0, "pll1", "pll3",
"lb", "qspi", "sdh", "sd0", "sd1", "z";
"lb", "qspi", "sdh", "sd0", "sd1", "z",
"rcan", "adsp";
};

35
Bindings/clock/renesas,sh73a0-cpg-clocks.txt Normal file
View File

@ -0,0 +1,35 @@
These bindings should be considered EXPERIMENTAL for now.
* Renesas SH73A0 Clock Pulse Generator (CPG)
The CPG generates core clocks for the SH73A0 SoC. It includes four PLLs
and several fixed ratio dividers.
Required Properties:
- compatible: Must be "renesas,sh73a0-cpg-clocks"
- reg: Base address and length of the memory resource used by the CPG
- clocks: Reference to the parent clocks ("extal1" and "extal2")
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "main",
"pll0", "pll1", "pll2", "pll3", "dsi0phy", "dsi1phy", "zg", "m3", "b",
"m1", "m2", "z", "zx", and "hp".
Example
-------
cpg_clocks: cpg_clocks@e6150000 {
compatible = "renesas,sh73a0-cpg-clocks";
reg = <0 0xe6150000 0 0x10000>;
clocks = <&extal1_clk>, <&extal2_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0", "pll1", "pll2",
"pll3", "dsi0phy", "dsi1phy",
"zg", "m3", "b", "m1", "m2",
"z", "zx", "hp";
};

2
Bindings/clock/st/st,flexgen.txt
View File

@ -11,7 +11,7 @@ Please find an example below:
Clockgen block diagram
-------------------------------------------------------------------
| Flexgen stucture |
| Flexgen structure |
| --------------------------------------------- |
| | ------- -------- -------- | |
clk_sysin | | | | | | | | |

72
Bindings/clock/sunxi.txt
View File

@ -10,43 +10,57 @@ Required properties:
"allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
"allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
"allwinner,sun9i-a80-pll4-clk" - for the peripheral PLLs on A80
"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
"allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
"allwinner,sun9i-a80-gt-clk" - for the GT bus clock on A80
"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
"allwinner,sun4i-a10-axi-clk" - for the AXI clock
"allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
"allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
"allwinner,sun4i-a10-ahb-clk" - for the AHB clock
"allwinner,sun9i-a80-ahb-clk" - for the AHB bus clocks on A80
"allwinner,sun4i-a10-ahb-gates-clk" - for the AHB gates on A10
"allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
"allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s
"allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
"allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
"allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
"allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
"allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
"allwinner,sun9i-a80-ahb1-gates-clk" - for the AHB1 gates on A80
"allwinner,sun9i-a80-ahb2-gates-clk" - for the AHB2 gates on A80
"allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
"allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
"allwinner,sun9i-a80-apb0-clk" - for the APB0 bus clock on A80
"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
"allwinner,sun4i-a10-apb1-mux-clk" - for the APB1 clock muxing
"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
"allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10
"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
"allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s
"allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
"allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
"allwinner,sun8i-a23-apb1-gates-clk" - for the APB1 gates on A23
"allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
"allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
"allwinner,sun4i-a10-mmc-clk" - for the MMC clock
"allwinner,sun9i-a80-mmc-clk" - for mmc module clocks on A80
"allwinner,sun9i-a80-mmc-config-clk" - for mmc gates + resets on A80
"allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks
"allwinner,sun9i-a80-mod0-clk" - for module 0 (storage) clocks on A80
"allwinner,sun8i-a23-mbus-clk" - for the MBUS clock on A23
"allwinner,sun7i-a20-out-clk" - for the external output clocks
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
"allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
@ -59,8 +73,11 @@ Required properties for all clocks:
multiplexed clocks, the list order must match the hardware
programming order.
- #clock-cells : from common clock binding; shall be set to 0 except for
"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk" and
"allwinner,sun4i-pll6-clk" where it shall be set to 1
the following compatibles where it shall be set to 1:
"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk",
"allwinner,*-usb-clk", "allwinner,*-mmc-clk",
"allwinner,*-mmc-config-clk"
- clock-output-names : shall be the corresponding names of the outputs.
If the clock module only has one output, the name shall be the
module name.
@ -68,6 +85,10 @@ Required properties for all clocks:
And "allwinner,*-usb-clk" clocks also require:
- reset-cells : shall be set to 1
The "allwinner,sun9i-a80-mmc-config-clk" clock also requires:
- #reset-cells : shall be set to 1
- resets : shall be the reset control phandle for the mmc block.
For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
dummy clocks at 25 MHz and 125 MHz, respectively. See example.
@ -75,6 +96,20 @@ Clock consumers should specify the desired clocks they use with a
"clocks" phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. This ID is the
offset of the bit controlling this particular gate in the register.
For the other clocks with "#clock-cells" = 1, the additional ID shall
refer to the index of the output.
For "allwinner,sun6i-a31-pll6-clk", there are 2 outputs. The first output
is the normal PLL6 output, or "pll6". The second output is rate doubled
PLL6, or "pll6x2".
The "allwinner,*-mmc-clk" clocks have three different outputs: the
main clock, with the ID 0, and the output and sample clocks, with the
IDs 1 and 2, respectively.
The "allwinner,sun9i-a80-mmc-config-clk" clock has one clock/reset output
per mmc controller. The number of outputs is determined by the size of
the address block, which is related to the overall mmc block.
For example:
@ -102,6 +137,14 @@ pll5: clk@01c20020 {
clock-output-names = "pll5_ddr", "pll5_other";
};
pll6: clk@01c20028 {
#clock-cells = <1>;
compatible = "allwinner,sun6i-a31-pll6-clk";
reg = <0x01c20028 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll6", "pll6x2";
};
cpu: cpu@01c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-cpu-clk";
@ -111,11 +154,11 @@ cpu: cpu@01c20054 {
};
mmc0_clk: clk@01c20088 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-mod0-clk";
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
reg = <0x01c20088 0x4>;
clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
clock-output-names = "mmc0";
clock-output-names = "mmc0", "mmc0_output", "mmc0_sample";
};
mii_phy_tx_clk: clk@2 {
@ -143,3 +186,16 @@ gmac_clk: clk@01c20164 {
clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
clock-output-names = "gmac";
};
mmc_config_clk: clk@01c13000 {
compatible = "allwinner,sun9i-a80-mmc-config-clk";
reg = <0x01c13000 0x10>;
clocks = <&ahb0_gates 8>;
clock-names = "ahb";
resets = <&ahb0_resets 8>;
reset-names = "ahb";
#clock-cells = <1>;
#reset-cells = <1>;
clock-output-names = "mmc0_config", "mmc1_config",
"mmc2_config", "mmc3_config";
};

42
Bindings/clock/ti,cdce706.txt Normal file
View File

@ -0,0 +1,42 @@
Bindings for Texas Instruments CDCE706 programmable 3-PLL clock
synthesizer/multiplier/divider.
Reference: http://www.ti.com/lit/ds/symlink/cdce706.pdf
I2C device node required properties:
- compatible: shall be "ti,cdce706".
- reg: i2c device address, shall be in range [0x68...0x6b].
- #clock-cells: from common clock binding; shall be set to 1.
- clocks: from common clock binding; list of parent clock
handles, shall be reference clock(s) connected to CLK_IN0
and CLK_IN1 pins.
- clock-names: shall be clk_in0 and/or clk_in1. Use clk_in0
in case of crystal oscillator or differential signal input
configuration. Use clk_in0 and clk_in1 in case of independent
single-ended LVCMOS inputs configuration.
Example:
clocks {
clk54: clk54 {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <54000000>;
};
};
...
i2c0: i2c-master@0d090000 {
...
cdce706: clock-synth@69 {
compatible = "ti,cdce706";
#clock-cells = <1>;
reg = <0x69>;
clocks = <&clk54>;
clock-names = "clk_in0";
};
};
...
simple-audio-card,codec {
...
clocks = <&cdce706 4>;
};

33
Bindings/clock/ti/fapll.txt Normal file
View File

@ -0,0 +1,33 @@
Binding for Texas Instruments FAPLL clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a
register-mapped FAPLL with usually two selectable input clocks
(reference clock and bypass clock), and one or more child
syntesizers.
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "ti,dm816-fapll-clock"
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
- reg : address and length of the register set for controlling the FAPLL.
Examples:
main_fapll: main_fapll {
#clock-cells = <1>;
compatible = "ti,dm816-fapll-clock";
reg = <0x400 0x40>;
clocks = <&sys_clkin_ck &sys_clkin_ck>;
clock-indices = <1>, <2>, <3>, <4>, <5>,
<6>, <7>;
clock-output-names = "main_pll_clk1",
"main_pll_clk2",
"main_pll_clk3",
"main_pll_clk4",
"main_pll_clk5",
"main_pll_clk6",
"main_pll_clk7";
};

15
Bindings/clock/vf610-clock.txt
View File

@ -5,6 +5,19 @@ Required properties:
- reg: Address and length of the register set
- #clock-cells: Should be <1>
Optional properties:
- clocks: list of clock identifiers which are external input clocks to the
given clock controller. Please refer the next section to find
the input clocks for a given controller.
- clock-names: list of names of clocks which are exteral input clocks to the
given clock controller.
Input clocks for top clock controller:
- sxosc (external crystal oscillator 32KHz, recommended)
- fxosc (external crystal oscillator 24MHz, recommended)
- audio_ext
- enet_ext
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/vf610-clock.h
for the full list of VF610 clock IDs.
@ -15,6 +28,8 @@ clks: ccm@4006b000 {
compatible = "fsl,vf610-ccm";
reg = <0x4006b000 0x1000>;
#clock-cells = <1>;
clocks = <&sxosc>, <&fxosc>;
clock-names = "sxosc", "fxosc";
};
uart1: serial@40028000 {

64
Bindings/cpufreq/cpufreq-dt.txt Normal file
View File

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

2
Bindings/crypto/fsl-imx-sahara.txt
View File

@ -1,5 +1,5 @@
Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
Currently only i.MX27 is supported.
Currently only i.MX27 and i.MX53 are supported.
Required properties:
- compatible : Should be "fsl,<soc>-sahara"

2
Bindings/crypto/fsl-sec6.txt
View File

@ -1,5 +1,5 @@
SEC 6 is as Freescale's Cryptographic Accelerator and Assurance Module (CAAM).
Currently Freescale powerpc chip C29X is embeded with SEC 6.
Currently Freescale powerpc chip C29X is embedded with SEC 6.
SEC 6 device tree binding include:
-SEC 6 Node
-Job Ring Node

110
Bindings/devfreq/event/exynos-ppmu.txt Normal file
View File

@ -0,0 +1,110 @@
* Samsung Exynos PPMU (Platform Performance Monitoring Unit) device
The Samsung Exynos SoC has PPMU (Platform Performance Monitoring Unit) for
each IP. PPMU provides the primitive values to get performance data. These
PPMU events provide information of the SoC's behaviors so that you may
use to analyze system performance, to make behaviors visible and to count
usages of each IP (DMC, CPU, RIGHTBUS, LEFTBUS, CAM interface, LCD, G3D, MFC).
The Exynos PPMU driver uses the devfreq-event class to provide event data
to various devfreq devices. The devfreq devices would use the event data when
derterming the current state of each IP.
Required properties:
- compatible: Should be "samsung,exynos-ppmu".
- reg: physical base address of each PPMU and length of memory mapped region.
Optional properties:
- clock-names : the name of clock used by the PPMU, "ppmu"
- clocks : phandles for clock specified in "clock-names" property
- #clock-cells: should be 1.
Example1 : PPMU nodes in exynos3250.dtsi are listed below.
ppmu_dmc0: ppmu_dmc0@106a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106a0000 0x2000>;
status = "disabled";
};
ppmu_dmc1: ppmu_dmc1@106b0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106b0000 0x2000>;
status = "disabled";
};
ppmu_cpu: ppmu_cpu@106c0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106c0000 0x2000>;
status = "disabled";
};
ppmu_rightbus: ppmu_rightbus@112a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x112a0000 0x2000>;
clocks = <&cmu CLK_PPMURIGHT>;
clock-names = "ppmu";
status = "disabled";
};
ppmu_leftbus: ppmu_leftbus0@116a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x116a0000 0x2000>;
clocks = <&cmu CLK_PPMULEFT>;
clock-names = "ppmu";
status = "disabled";
};
Example2 : Events of each PPMU node in exynos3250-rinato.dts are listed below.
&ppmu_dmc0 {
status = "okay";
events {
ppmu_dmc0_3: ppmu-event3-dmc0 {
event-name = "ppmu-event3-dmc0";
};
ppmu_dmc0_2: ppmu-event2-dmc0 {
event-name = "ppmu-event2-dmc0";
};
ppmu_dmc0_1: ppmu-event1-dmc0 {
event-name = "ppmu-event1-dmc0";
};
ppmu_dmc0_0: ppmu-event0-dmc0 {
event-name = "ppmu-event0-dmc0";
};
};
};
&ppmu_dmc1 {
status = "okay";
events {
ppmu_dmc1_3: ppmu-event3-dmc1 {
event-name = "ppmu-event3-dmc1";
};
};
};
&ppmu_leftbus {
status = "okay";
events {
ppmu_leftbus_3: ppmu-event3-leftbus {
event-name = "ppmu-event3-leftbus";
};
};
};
&ppmu_rightbus {
status = "okay";
events {
ppmu_rightbus_3: ppmu-event3-rightbus {
event-name = "ppmu-event3-rightbus";
};
};
};

54
Bindings/dma/atmel-xdma.txt Normal file
View File

@ -0,0 +1,54 @@
* Atmel Extensible Direct Memory Access Controller (XDMAC)
* XDMA Controller
Required properties:
- compatible: Should be "atmel,<chip>-dma".
<chip> compatible description:
- sama5d4: first SoC adding the XDMAC
- reg: Should contain DMA registers location and length.
- interrupts: Should contain DMA interrupt.
- #dma-cells: Must be <1>, used to represent the number of integer cells in
the dmas property of client devices.
- The 1st cell specifies the channel configuration register:
- bit 13: SIF, source interface identifier, used to get the memory
interface identifier,
- bit 14: DIF, destination interface identifier, used to get the peripheral
interface identifier,
- bit 30-24: PERID, peripheral identifier.
Example:
dma1: dma-controller@f0004000 {
compatible = "atmel,sama5d4-dma";
reg = <0xf0004000 0x200>;
interrupts = <50 4 0>;
#dma-cells = <1>;
};
* DMA clients
DMA clients connected to the Atmel XDMA controller must use the format
described in the dma.txt file, using a one-cell specifier for each channel.
The two cells in order are:
1. A phandle pointing to the DMA controller.
2. Channel configuration register. Configurable fields are:
- bit 13: SIF, source interface identifier, used to get the memory
interface identifier,
- bit 14: DIF, destination interface identifier, used to get the peripheral
interface identifier,
- bit 30-24: PERID, peripheral identifier.
Example:
i2c2: i2c@f8024000 {
compatible = "atmel,at91sam9x5-i2c";
reg = <0xf8024000 0x4000>;
interrupts = <34 4 6>;
dmas = <&dma1
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(6))>,
<&dma1
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(7))>;
dma-names = "tx", "rx";
};

1
Bindings/dma/fsl-imx-sdma.txt
View File

@ -48,6 +48,7 @@ The full ID of peripheral types can be found below.
21 ESAI
22 SSI Dual FIFO (needs firmware ver >= 2)
23 Shared ASRC
24 SAI
The third cell specifies the transfer priority as below.

57
Bindings/dma/img-mdc-dma.txt Normal file
View File

@ -0,0 +1,57 @@
* IMG Multi-threaded DMA Controller (MDC)
Required properties:
- compatible: Must be "img,pistachio-mdc-dma".
- reg: Must contain the base address and length of the MDC registers.
- interrupts: Must contain all the per-channel DMA interrupts.
- clocks: Must contain an entry for each entry in clock-names.
See ../clock/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- sys: MDC system interface clock.
- img,cr-periph: Must contain a phandle to the peripheral control syscon
node which contains the DMA request to channel mapping registers.
- img,max-burst-multiplier: Must be the maximum supported burst size multiplier.
The maximum burst size is this value multiplied by the hardware-reported bus
width.
- #dma-cells: Must be 3:
- The first cell is the peripheral's DMA request line.
- The second cell is a bitmap specifying to which channels the DMA request
line may be mapped (i.e. bit N set indicates channel N is usable).
- The third cell is the thread ID to be used by the channel.
Optional properties:
- dma-channels: Number of supported DMA channels, up to 32. If not specified
the number reported by the hardware is used.
Example:
mdc: dma-controller@18143000 {
compatible = "img,pistachio-mdc-dma";
reg = <0x18143000 0x1000>;
interrupts = <GIC_SHARED 27 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 28 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 29 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 30 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 31 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 32 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 33 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 34 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 35 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 36 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 37 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SHARED 38 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&system_clk>;
clock-names = "sys";
img,max-burst-multiplier = <16>;
img,cr-periph = <&cr_periph>;
#dma-cells = <3>;
};
spi@18100f00 {
...
dmas = <&mdc 9 0xffffffff 0>, <&mdc 10 0xffffffff 0>;
dma-names = "tx", "rx";
...
};

62
Bindings/dma/qcom_adm.txt Normal file
View File

@ -0,0 +1,62 @@
QCOM ADM DMA Controller
Required properties:
- compatible: must contain "qcom,adm" for IPQ/APQ8064 and MSM8960
- reg: Address range for DMA registers
- interrupts: Should contain one interrupt shared by all channels
- #dma-cells: must be <2>. First cell denotes the channel number. Second cell
denotes CRCI (client rate control interface) flow control assignment.
- clocks: Should contain the core clock and interface clock.
- clock-names: Must contain "core" for the core clock and "iface" for the
interface clock.
- resets: Must contain an entry for each entry in reset names.
- reset-names: Must include the following entries:
- clk
- c0
- c1
- c2
- qcom,ee: indicates the security domain identifier used in the secure world.
Example:
adm_dma: dma@18300000 {
compatible = "qcom,adm";
reg = <0x18300000 0x100000>;
interrupts = <0 170 0>;
#dma-cells = <2>;
clocks = <&gcc ADM0_CLK>, <&gcc ADM0_PBUS_CLK>;
clock-names = "core", "iface";
resets = <&gcc ADM0_RESET>,
<&gcc ADM0_C0_RESET>,
<&gcc ADM0_C1_RESET>,
<&gcc ADM0_C2_RESET>;
reset-names = "clk", "c0", "c1", "c2";
qcom,ee = <0>;
};
DMA clients must use the format descripted in the dma.txt file, using a three
cell specifier for each channel.
Each dmas request consists of 3 cells:
1. phandle pointing to the DMA controller
2. channel number
3. CRCI assignment, if applicable. If no CRCI flow control is required, use 0.
The CRCI is used for flow control. It identifies the peripheral device that
is the source/destination for the transferred data.
Example:
spi4: spi@1a280000 {
status = "ok";
spi-max-frequency = <50000000>;
pinctrl-0 = <&spi_pins>;
pinctrl-names = "default";
cs-gpios = <&qcom_pinmux 20 0>;
dmas = <&adm_dma 6 9>,
<&adm_dma 5 10>;
dma-names = "rx", "tx";
};

4
Bindings/dma/qcom_bam_dma.txt
View File

@ -1,7 +1,9 @@
QCOM BAM DMA controller
Required properties:
- compatible: must contain "qcom,bam-v1.4.0" for MSM8974
- compatible: must be one of the following:
* "qcom,bam-v1.4.0" for MSM8974, APQ8074 and APQ8084
* "qcom,bam-v1.3.0" for APQ8064, IPQ8064 and MSM8960
- reg: Address range for DMA registers
- interrupts: Should contain the one interrupt shared by all channels
- #dma-cells: must be <1>, the cell in the dmas property of the client device

6
Bindings/dma/rcar-audmapp.txt
View File

@ -16,9 +16,9 @@ Example:
* DMA client
Required properties:
- dmas: a list of <[DMA multiplexer phandle] [SRS/DRS value]> pairs,
where SRS/DRS values are fixed handles, specified in the SoC
manual as the value that would be written into the PDMACHCR.
- dmas: a list of <[DMA multiplexer phandle] [SRS << 8 | DRS]> pairs.
where SRS/DRS are specified in the SoC manual.
It will be written into PDMACHCR as high 16-bit parts.
- dma-names: a list of DMA channel names, one per "dmas" entry
Example:

5
Bindings/dma/renesas,rcar-dmac.txt
View File

@ -1,13 +1,10 @@
* Renesas R-Car DMA Controller Device Tree bindings
Renesas R-Car Generation 2 SoCs have have multiple multi-channel DMA
Renesas R-Car Generation 2 SoCs have multiple multi-channel DMA
controller instances named DMAC capable of serving multiple clients. Channels
can be dedicated to specific clients or shared between a large number of
clients.
DMA clients are connected to the DMAC ports referenced by an 8-bit identifier
called MID/RID.
Each DMA client is connected to one dedicated port of the DMAC, identified by
an 8-bit port number called the MID/RID. A DMA controller can thus serve up to
256 clients in total. When the number of hardware channels is lower than the

2
Bindings/dma/snps-dma.txt
View File

@ -38,7 +38,7 @@ Example:
chan_allocation_order = <1>;
chan_priority = <1>;
block_size = <0xfff>;
data_width = <3 3 0 0>;
data_width = <3 3>;
};
DMA clients connected to the Designware DMA controller must use the format

2
Bindings/dma/sun6i-dma.txt
View File

@ -4,7 +4,7 @@ This driver follows the generic DMA bindings defined in dma.txt.
Required properties:
- compatible: Must be "allwinner,sun6i-a31-dma"
- compatible: Must be "allwinner,sun6i-a31-dma" or "allwinner,sun8i-a23-dma"
- reg: Should contain the registers base address and length
- interrupts: Should contain a reference to the interrupt used by this device
- clocks: Should contain a reference to the parent AHB clock

65
Bindings/dma/xilinx/xilinx_dma.txt Normal file
View File

@ -0,0 +1,65 @@
Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
target devices. It can be configured to have one channel or two channels.
If configured as two channels, one is to transmit to the device and another
is to receive from the device.
Required properties:
- compatible: Should be "xlnx,axi-dma-1.00.a"
- #dma-cells: Should be <1>, see "dmas" property below
- reg: Should contain DMA registers location and length.
- dma-channel child node: Should have atleast one channel and can have upto
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
Optional properties:
- xlnx,include-sg: Tells whether configured for Scatter-mode in
the hardware.
Required child node properties:
- compatible: It should be either "xlnx,axi-dma-mm2s-channel" or
"xlnx,axi-dma-s2mm-channel".
- interrupts: Should contain per channel DMA interrupts.
- xlnx,datawidth: Should contain the stream data width, take values
{32,64...1024}.
Option child node properties:
- xlnx,include-dre: Tells whether hardware is configured for Data
Realignment Engine.
Example:
++++++++
axi_dma_0: axidma@40400000 {
compatible = "xlnx,axi-dma-1.00.a";
#dma_cells = <1>;
reg = < 0x40400000 0x10000 >;
dma-channel@40400000 {
compatible = "xlnx,axi-dma-mm2s-channel";
interrupts = < 0 59 4 >;
xlnx,datawidth = <0x40>;
} ;
dma-channel@40400030 {
compatible = "xlnx,axi-dma-s2mm-channel";
interrupts = < 0 58 4 >;
xlnx,datawidth = <0x40>;
} ;
} ;
* DMA client
Required properties:
- dmas: a list of <[DMA device phandle] [Channel ID]> pairs,
where Channel ID is '0' for write/tx and '1' for read/rx
channel.
- dma-names: a list of DMA channel names, one per "dmas" entry
Example:
++++++++
dmatest_0: dmatest@0 {
compatible ="xlnx,axi-dma-test-1.00.a";
dmas = <&axi_dma_0 0
&axi_dma_0 1>;
dma-names = "dma0", "dma1";
} ;

2
Bindings/dma/xilinx/xilinx_vdma.txt
View File

@ -25,7 +25,7 @@ Required child node properties:
- compatible: It should be either "xlnx,axi-vdma-mm2s-channel" or
"xlnx,axi-vdma-s2mm-channel".
- interrupts: Should contain per channel VDMA interrupts.
- xlnx,data-width: Should contain the stream data width, take values
- xlnx,datawidth: Should contain the stream data width, take values
{32,64...1024}.
Optional child node properties:

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