Bring in Ian Campbell's pruned dts repo.

From git://xenbits.xen.org/people/ianc/device-tree-rebasing.git
commit efa963ec806366c9628dfd1269316bb93b7ecb15
Merge: a72ba09 459c249
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Feb 26 08:39:16 2014 +0000

    Merge tag 'v3.14-rc4-dts'

    Linux 3.14-rc4
This commit is contained in:
Warner Losh 2014-02-27 19:39:44 +00:00
commit 0d4a4b1301
2011 changed files with 261054 additions and 0 deletions

39
Bindings/ABI.txt Normal file
View File

@ -0,0 +1,39 @@
Devicetree (DT) ABI
I. Regarding stable bindings/ABI, we quote from the 2013 ARM mini-summit
summary document:
"That still leaves the question of, what does a stable binding look
like? Certainly a stable binding means that a newer kernel will not
break on an older device tree, but that doesn't mean the binding is
frozen for all time. Grant said there are ways to change bindings that
don't result in breakage. For instance, if a new property is added,
then default to the previous behaviour if it is missing. If a binding
truly needs an incompatible change, then change the compatible string
at the same time. The driver can bind against both the old and the
new. These guidelines aren't new, but they desperately need to be
documented."
II. General binding rules
1) Maintainers, don't let perfect be the enemy of good. Don't hold up a
binding because it isn't perfect.
2) Use specific compatible strings so that if we need to add a feature (DMA)
in the future, we can create a new compatible string. See I.
3) Bindings can be augmented, but the driver shouldn't break when given
the old binding. ie. add additional properties, but don't change the
meaning of an existing property. For drivers, default to the original
behaviour when a newly added property is missing.
4) Don't submit bindings for staging or unstable. That will be decided by
the devicetree maintainers *after* discussion on the mailinglist.
III. Notes
1) This document is intended as a general familiarization with the process as
decided at the 2013 Kernel Summit. When in doubt, the current word of the
devicetree maintainers overrules this document. In that situation, a patch
updating this document would be appreciated.

View File

@ -0,0 +1,24 @@
* ARC700 incore Interrupt Controller
The core interrupt controller provides 32 prioritised interrupts (2 levels)
to ARC700 core.
Properties:
- compatible: "snps,arc700-intc"
- interrupt-controller: This is an interrupt controller.
- #interrupt-cells: Must be <1>.
Single Cell "interrupts" property of a device specifies the IRQ number
between 0 to 31
intc accessed via the special ARC AUX register interface, hence "reg" property
is not specified.
Example:
intc: interrupt-controller {
compatible = "snps,arc700-intc";
interrupt-controller;
#interrupt-cells = <1>;
};

24
Bindings/arc/pmu.txt Normal file
View File

@ -0,0 +1,24 @@
* ARC Performance Monitor Unit
The ARC 700 can be configured with a pipeline performance monitor for counting
CPU and cache events like cache misses and hits.
Note that:
* ARC 700 refers to a family of ARC processor cores;
- There is only one type of PMU available for the whole family;
- The PMU may support different sets of events; supported events are probed
at boot time, as required by the reference manual.
* The ARC 700 PMU does not support interrupts; although HW events may be
counted, the HW events themselves cannot serve as a trigger for a sample.
Required properties:
- compatible : should contain
"snps,arc700-pmu"
Example:
pmu {
compatible = "snps,arc700-pmu";
};

View File

@ -0,0 +1,11 @@
Altera SOCFPGA Clock Manager
Required properties:
- compatible : "altr,clk-mgr"
- reg : Should contain base address and length for Clock Manager
Example:
clkmgr@ffd04000 {
compatible = "altr,clk-mgr";
reg = <0xffd04000 0x1000>;
};

View File

@ -0,0 +1,11 @@
Altera SOCFPGA Reset Manager
Required properties:
- compatible : "altr,rst-mgr"
- reg : Should contain 1 register ranges(address and length)
Example:
rstmgr@ffd05000 {
compatible = "altr,rst-mgr";
reg = <0xffd05000 0x1000>;
};

View File

@ -0,0 +1,13 @@
Altera SOCFPGA System Manager
Required properties:
- compatible : "altr,sys-mgr"
- reg : Should contain 1 register ranges(address and length)
- cpu1-start-addr : CPU1 start address in hex.
Example:
sysmgr@ffd08000 {
compatible = "altr,sys-mgr";
reg = <0xffd08000 0x1000>;
cpu1-start-addr = <0xffd080c4>;
};

View File

@ -0,0 +1,81 @@
* ARM architected timer
ARM cores may have a per-core architected timer, which provides per-cpu timers,
or a memory mapped architected timer, which provides up to 8 frames with a
physical and optional virtual timer per frame.
The per-core architected timer is attached to a GIC to deliver its
per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC
to deliver its interrupts via SPIs.
** CP15 Timer node properties:
- compatible : Should at least contain one of
"arm,armv7-timer"
"arm,armv8-timer"
- interrupts : Interrupt list for secure, non-secure, virtual and
hypervisor timers, in that order.
- clock-frequency : The frequency of the main counter, in Hz. Optional.
Example:
timer {
compatible = "arm,cortex-a15-timer",
"arm,armv7-timer";
interrupts = <1 13 0xf08>,
<1 14 0xf08>,
<1 11 0xf08>,
<1 10 0xf08>;
clock-frequency = <100000000>;
};
** Memory mapped timer node properties:
- compatible : Should at least contain "arm,armv7-timer-mem".
- clock-frequency : The frequency of the main counter, in Hz. Optional.
- reg : The control frame base address.
Note that #address-cells, #size-cells, and ranges shall be present to ensure
the CPU can address a frame's registers.
A timer node has up to 8 frame sub-nodes, each with the following properties:
- frame-number: 0 to 7.
- interrupts : Interrupt list for physical and virtual timers in that order.
The virtual timer interrupt is optional.
- reg : The first and second view base addresses in that order. The second view
base address is optional.
- status : "disabled" indicates the frame is not available for use. Optional.
Example:
timer@f0000000 {
compatible = "arm,armv7-timer-mem";
#address-cells = <1>;
#size-cells = <1>;
ranges;
reg = <0xf0000000 0x1000>;
clock-frequency = <50000000>;
frame@f0001000 {
frame-number = <0>
interrupts = <0 13 0x8>,
<0 14 0x8>;
reg = <0xf0001000 0x1000>,
<0xf0002000 0x1000>;
};
frame@f0003000 {
frame-number = <1>
interrupts = <0 15 0x8>;
reg = <0xf0003000 0x1000>;
status = "disabled";
};
};

88
Bindings/arm/arm-boards Normal file
View File

@ -0,0 +1,88 @@
ARM Integrator/AP (Application Platform) and Integrator/CP (Compact Platform)
-----------------------------------------------------------------------------
ARM's oldest Linux-supported platform with connectors for different core
tiles of ARMv4, ARMv5 and ARMv6 type.
Required properties (in root node):
compatible = "arm,integrator-ap"; /* Application Platform */
compatible = "arm,integrator-cp"; /* Compact Platform */
FPGA type interrupt controllers, see the versatile-fpga-irq binding doc.
Required nodes:
- core-module: the root node to the Integrator platforms must have
a core-module with regs and the compatible string
"arm,core-module-integrator"
- external-bus-interface: the root node to the Integrator platforms
must have an external bus interface with regs and the
compatible-string "arm,external-bus-interface"
Required properties for the core module:
- regs: the location and size of the core module registers, one
range of 0x200 bytes.
- syscon: the root node of the Integrator platforms must have a
system controller node pointong to the control registers,
with the compatible string
"arm,integrator-ap-syscon"
"arm,integrator-cp-syscon"
respectively.
Required properties for the system controller:
- regs: the location and size of the system controller registers,
one range of 0x100 bytes.
Required properties for the AP system controller:
- interrupts: the AP syscon node must include the logical module
interrupts, stated in order of module instance <module 0>,
<module 1>, <module 2> ... for the CP system controller this
is not required not of any use.
/dts-v1/;
/include/ "integrator.dtsi"
/ {
model = "ARM Integrator/AP";
compatible = "arm,integrator-ap";
core-module@10000000 {
compatible = "arm,core-module-integrator";
reg = <0x10000000 0x200>;
};
ebi@12000000 {
compatible = "arm,external-bus-interface";
reg = <0x12000000 0x100>;
};
syscon {
compatible = "arm,integrator-ap-syscon";
reg = <0x11000000 0x100>;
interrupt-parent = <&pic>;
/* These are the logic module IRQs */
interrupts = <9>, <10>, <11>, <12>;
};
};
ARM Versatile Application and Platform Baseboards
-------------------------------------------------
ARM's development hardware platform with connectors for customizable
core tiles. The hardware configuration of the Versatile boards is
highly customizable.
Required properties (in root node):
compatible = "arm,versatile-ab"; /* Application baseboard */
compatible = "arm,versatile-pb"; /* Platform baseboard */
Interrupt controllers:
- VIC required properties:
compatible = "arm,versatile-vic";
interrupt-controller;
#interrupt-cells = <1>;
- SIC required properties:
compatible = "arm,versatile-sic";
interrupt-controller;
#interrupt-cells = <1>;

View File

@ -0,0 +1,32 @@
Marvell Armada 370 and Armada XP Interrupt Controller
-----------------------------------------------------
Required properties:
- compatible: Should be "marvell,mpic"
- interrupt-controller: Identifies the node as an interrupt controller.
- msi-controller: Identifies the node as an PCI Message Signaled
Interrupt controller.
- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
The cell is the IRQ number
- reg: Should contain PMIC registers location and length. First pair
for the main interrupt registers, second pair for the per-CPU
interrupt registers. For this last pair, to be compliant with SMP
support, the "virtual" must be use (For the record, these registers
automatically map to the interrupt controller registers of the
current CPU)
Example:
mpic: interrupt-controller@d0020000 {
compatible = "marvell,mpic";
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <1>;
interrupt-controller;
msi-controller;
reg = <0xd0020a00 0x1d0>,
<0xd0021070 0x58>;
};

View File

@ -0,0 +1,20 @@
Power Management Service Unit(PMSU)
-----------------------------------
Available on Marvell SOCs: Armada 370 and Armada XP
Required properties:
- compatible: "marvell,armada-370-xp-pmsu"
- reg: Should contain PMSU registers location and length. First pair
for the per-CPU SW Reset Control registers, second pair for the
Power Management Service Unit.
Example:
armada-370-xp-pmsu@d0022000 {
compatible = "marvell,armada-370-xp-pmsu";
reg = <0xd0022100 0x430>,
<0xd0020800 0x20>;
};

View File

@ -0,0 +1,24 @@
Marvell Armada 370 and Armada XP Platforms Device Tree Bindings
---------------------------------------------------------------
Boards with a SoC of the Marvell Armada 370 and Armada XP families
shall have the following property:
Required root node property:
compatible: must contain "marvell,armada-370-xp"
In addition, boards using the Marvell Armada 370 SoC shall have the
following property:
Required root node property:
compatible: must contain "marvell,armada370"
In addition, boards using the Marvell Armada XP SoC shall have the
following property:
Required root node property:
compatible: must contain "marvell,armadaxp"

View File

@ -0,0 +1,6 @@
Armadeus i.MX Platforms Device Tree Bindings
-----------------------------------------------
APF51: i.MX51 based module.
Required root node properties:
- compatible = "armadeus,imx51-apf51", "fsl,imx51";

View File

@ -0,0 +1,81 @@
* AT91's Analog to Digital Converter (ADC)
Required properties:
- compatible: Should be "atmel,<chip>-adc"
<chip> can be "at91sam9260", "at91sam9g45" or "at91sam9x5"
- reg: Should contain ADC registers location and length
- interrupts: Should contain the IRQ line for the ADC
- atmel,adc-channels-used: Bitmask of the channels muxed and enable for this
device
- atmel,adc-startup-time: Startup Time of the ADC in microseconds as
defined in the datasheet
- atmel,adc-vref: Reference voltage in millivolts for the conversions
- atmel,adc-res: List of resolution in bits supported by the ADC. List size
must be two at least.
- atmel,adc-res-names: Contains one identifier string for each resolution
in atmel,adc-res property. "lowres" and "highres"
identifiers are required.
Optional properties:
- atmel,adc-use-external: Boolean to enable of external triggers
- atmel,adc-use-res: String corresponding to an identifier from
atmel,adc-res-names property. If not specified, the highest
resolution will be used.
- atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
- atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
- atmel,adc-ts-wires: Number of touch screen wires. Should be 4 or 5. If this
value is set, then adc driver will enable touch screen
support.
NOTE: when adc touch screen enabled, the adc hardware trigger will be
disabled. Since touch screen will occupied the trigger register.
- atmel,adc-ts-pressure-threshold: a pressure threshold for touchscreen. It
make touch detect more precision.
Optional trigger Nodes:
- Required properties:
* trigger-name: Name of the trigger exposed to the user
* trigger-value: Value to put in the Trigger register
to activate this trigger
- Optional properties:
* trigger-external: Is the trigger an external trigger?
Examples:
adc0: adc@fffb0000 {
compatible = "atmel,at91sam9260-adc";
reg = <0xfffb0000 0x100>;
interrupts = <20 4>;
atmel,adc-channel-base = <0x30>;
atmel,adc-channels-used = <0xff>;
atmel,adc-drdy-mask = <0x10000>;
atmel,adc-num-channels = <8>;
atmel,adc-startup-time = <40>;
atmel,adc-status-register = <0x1c>;
atmel,adc-trigger-register = <0x08>;
atmel,adc-use-external;
atmel,adc-vref = <3300>;
atmel,adc-res = <8 10>;
atmel,adc-res-names = "lowres", "highres";
atmel,adc-use-res = "lowres";
trigger@0 {
trigger-name = "external-rising";
trigger-value = <0x1>;
trigger-external;
};
trigger@1 {
trigger-name = "external-falling";
trigger-value = <0x2>;
trigger-external;
};
trigger@2 {
trigger-name = "external-any";
trigger-value = <0x3>;
trigger-external;
};
trigger@3 {
trigger-name = "continuous";
trigger-value = <0x6>;
};
};

View File

@ -0,0 +1,42 @@
* Advanced Interrupt Controller (AIC)
Required properties:
- compatible: Should be "atmel,<chip>-aic"
<chip> can be "at91rm9200" or "sama5d3"
- interrupt-controller: Identifies the node as an interrupt controller.
- interrupt-parent: For single AIC system, it is an empty property.
- #interrupt-cells: The number of cells to define the interrupts. It should be 3.
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
Default flag for internal sources should be set to 4 (active high).
The third cell is used to specify the irq priority from 0 (lowest) to 7
(highest).
- reg: Should contain AIC registers location and length
- atmel,external-irqs: u32 array of external irqs.
Examples:
/*
* AIC
*/
aic: interrupt-controller@fffff000 {
compatible = "atmel,at91rm9200-aic";
interrupt-controller;
interrupt-parent;
#interrupt-cells = <3>;
reg = <0xfffff000 0x200>;
};
/*
* An interrupt generating device that is wired to an AIC.
*/
dma: dma-controller@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <21 4 5>;
};

107
Bindings/arm/atmel-at91.txt Normal file
View File

@ -0,0 +1,107 @@
Atmel AT91 device tree bindings.
================================
PIT Timer required properties:
- compatible: Should be "atmel,at91sam9260-pit"
- reg: Should contain registers location and length
- interrupts: Should contain interrupt for the PIT which is the IRQ line
shared across all System Controller members.
System Timer (ST) required properties:
- compatible: Should be "atmel,at91rm9200-st"
- reg: Should contain registers location and length
- interrupts: Should contain interrupt for the ST which is the IRQ line
shared across all System Controller members.
TC/TCLIB Timer required properties:
- compatible: Should be "atmel,<chip>-tcb".
<chip> can be "at91rm9200" or "at91sam9x5"
- reg: Should contain registers location and length
- interrupts: Should contain all interrupts for the TC block
Note that you can specify several interrupt cells if the TC
block has one interrupt per channel.
- clock-names: tuple listing input clock names.
Required elements: "t0_clk"
Optional elements: "t1_clk", "t2_clk"
- clocks: phandles to input clocks.
Examples:
One interrupt per TC block:
tcb0: timer@fff7c000 {
compatible = "atmel,at91rm9200-tcb";
reg = <0xfff7c000 0x100>;
interrupts = <18 4>;
clocks = <&tcb0_clk>;
clock-names = "t0_clk";
};
One interrupt per TC channel in a TC block:
tcb1: timer@fffdc000 {
compatible = "atmel,at91rm9200-tcb";
reg = <0xfffdc000 0x100>;
interrupts = <26 4 27 4 28 4>;
clocks = <&tcb1_clk>;
clock-names = "t0_clk";
};
RSTC Reset Controller required properties:
- compatible: Should be "atmel,<chip>-rstc".
<chip> can be "at91sam9260" or "at91sam9g45"
- reg: Should contain registers location and length
Example:
rstc@fffffd00 {
compatible = "atmel,at91sam9260-rstc";
reg = <0xfffffd00 0x10>;
};
RAMC SDRAM/DDR Controller required properties:
- compatible: Should be "atmel,at91rm9200-sdramc",
"atmel,at91sam9260-sdramc",
"atmel,at91sam9g45-ddramc",
- reg: Should contain registers location and length
For at91sam9263 and at91sam9g45 you must specify 2 entries.
Examples:
ramc0: ramc@ffffe800 {
compatible = "atmel,at91sam9g45-ddramc";
reg = <0xffffe800 0x200>;
};
ramc0: ramc@ffffe400 {
compatible = "atmel,at91sam9g45-ddramc";
reg = <0xffffe400 0x200
0xffffe600 0x200>;
};
SHDWC Shutdown Controller
required properties:
- compatible: Should be "atmel,<chip>-shdwc".
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
- reg: Should contain registers location and length
optional properties:
- atmel,wakeup-mode: String, operation mode of the wakeup mode.
Supported values are: "none", "high", "low", "any".
- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf).
optional at91sam9260 properties:
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
optional at91sam9rl properties:
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
optional at91sam9x5 properties:
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
Example:
rstc@fffffd00 {
compatible = "atmel,at91sam9260-rstc";
reg = <0xfffffd00 0x10>;
};

View File

@ -0,0 +1,11 @@
* Power Management Controller (PMC)
Required properties:
- compatible: Should be "atmel,at91rm9200-pmc"
- reg: Should contain PMC registers location and length
Examples:
pmc: pmc@fffffc00 {
compatible = "atmel,at91rm9200-pmc";
reg = <0xfffffc00 0x100>;
};

View File

@ -0,0 +1,10 @@
Broadcom BCM11351 device tree bindings
-------------------------------------------
Boards with the bcm281xx SoC family (which includes bcm11130, bcm11140,
bcm11351, bcm28145, bcm28155 SoCs) shall have the following properties:
Required root node property:
compatible = "brcm,bcm11351";
DEPRECATED: compatible = "bcm,bcm11351";

View File

@ -0,0 +1,25 @@
Broadcom Kona Family timer
-----------------------------------------------------
This timer is used in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
Required properties:
- compatible : "brcm,kona-timer"
- DEPRECATED: compatible : "bcm,kona-timer"
- reg : Register range for the timer
- interrupts : interrupt for the timer
- clocks: phandle + clock specifier pair of the external clock
- clock-frequency: frequency that the clock operates
Only one of clocks or clock-frequency should be specified.
Refer to clocks/clock-bindings.txt for generic clock consumer properties.
Example:
timer@35006000 {
compatible = "brcm,kona-timer";
reg = <0x35006000 0x1000>;
interrupts = <0x0 7 0x4>;
clocks = <&hub_timer_clk>;
};

View File

@ -0,0 +1,15 @@
Broadcom Kona Family Watchdog Timer
-----------------------------------
This watchdog timer is used in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
Required properties:
- compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt";
- reg: memory address & range
Example:
watchdog@35002f40 {
compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt";
reg = <0x35002f40 0x6c>;
};

8
Bindings/arm/bcm2835.txt Normal file
View File

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

15
Bindings/arm/calxeda.txt Normal file
View File

@ -0,0 +1,15 @@
Calxeda Platforms Device Tree Bindings
-----------------------------------------------
Boards with Calxeda Cortex-A9 based ECX-1000 (Highbank) SOC shall have the
following properties.
Required root node properties:
- compatible = "calxeda,highbank";
Boards with Calxeda Cortex-A15 based ECX-2000 SOC shall have the following
properties.
Required root node properties:
- compatible = "calxeda,ecx-2000";

View File

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

View File

@ -0,0 +1,15 @@
Calxeda Highbank L2 cache ECC
Properties:
- compatible : Should be "calxeda,hb-sregs-l2-ecc"
- reg : Address and size for ECC error interrupt clear registers.
- interrupts : Should be single bit error interrupt, then double bit error
interrupt.
Example:
sregs@fff3c200 {
compatible = "calxeda,hb-sregs-l2-ecc";
reg = <0xfff3c200 0x100>;
interrupts = <0 71 4 0 72 4>;
};

View File

@ -0,0 +1,16 @@
Calxeda DDR memory controller
Properties:
- compatible : Should be:
- "calxeda,hb-ddr-ctrl" for ECX-1000
- "calxeda,ecx-2000-ddr-ctrl" for ECX-2000
- reg : Address and size for DDR controller registers.
- interrupts : Interrupt for DDR controller.
Example:
memory-controller@fff00000 {
compatible = "calxeda,hb-ddr-ctrl";
reg = <0xfff00000 0x1000>;
interrupts = <0 91 4>;
};

224
Bindings/arm/cci.txt Normal file
View File

@ -0,0 +1,224 @@
=======================================================
ARM CCI cache coherent interconnect binding description
=======================================================
ARM multi-cluster systems maintain intra-cluster coherency through a
cache coherent interconnect (CCI) that is capable of monitoring bus
transactions and manage coherency, TLB invalidations and memory barriers.
It allows snooping and distributed virtual memory message broadcast across
clusters, through memory mapped interface, with a global control register
space and multiple sets of interface control registers, one per slave
interface.
Bindings for the CCI node follow the ePAPR standard, available from:
www.power.org/documentation/epapr-version-1-1/
with the addition of the bindings described in this document which are
specific to ARM.
* CCI interconnect node
Description: Describes a CCI cache coherent Interconnect component
Node name must be "cci".
Node's parent must be the root node /, and the address space visible
through the CCI interconnect is the same as the one seen from the
root node (ie from CPUs perspective as per DT standard).
Every CCI node has to define the following properties:
- compatible
Usage: required
Value type: <string>
Definition: must be set to
"arm,cci-400"
- reg
Usage: required
Value type: Integer cells. A register entry, expressed as a pair
of cells, containing base and size.
Definition: A standard property. Specifies base physical
address of CCI control registers common to all
interfaces.
- ranges:
Usage: required
Value type: Integer cells. An array of range entries, expressed
as a tuple of cells, containing child address,
parent address and the size of the region in the
child address space.
Definition: A standard property. Follow rules in the ePAPR for
hierarchical bus addressing. CCI interfaces
addresses refer to the parent node addressing
scheme to declare their register bases.
CCI interconnect node can define the following child nodes:
- CCI control interface nodes
Node name must be "slave-if".
Parent node must be CCI interconnect node.
A CCI control interface node must contain the following
properties:
- compatible
Usage: required
Value type: <string>
Definition: must be set to
"arm,cci-400-ctrl-if"
- interface-type:
Usage: required
Value type: <string>
Definition: must be set to one of {"ace", "ace-lite"}
depending on the interface type the node
represents.
- reg:
Usage: required
Value type: Integer cells. A register entry, expressed
as a pair of cells, containing base and
size.
Definition: the base address and size of the
corresponding interface programming
registers.
- CCI PMU node
Parent node must be CCI interconnect node.
A CCI pmu node must contain the following properties:
- compatible
Usage: required
Value type: <string>
Definition: must be "arm,cci-400-pmu"
- reg:
Usage: required
Value type: Integer cells. A register entry, expressed
as a pair of cells, containing base and
size.
Definition: the base address and size of the
corresponding interface programming
registers.
- interrupts:
Usage: required
Value type: Integer cells. Array of interrupt specifier
entries, as defined in
../interrupt-controller/interrupts.txt.
Definition: list of counter overflow interrupts, one per
counter. The interrupts must be specified
starting with the cycle counter overflow
interrupt, followed by counter0 overflow
interrupt, counter1 overflow interrupt,...
,counterN overflow interrupt.
The CCI PMU has an interrupt signal for each
counter. The number of interrupts must be
equal to the number of counters.
* CCI interconnect bus masters
Description: masters in the device tree connected to a CCI port
(inclusive of CPUs and their cpu nodes).
A CCI interconnect bus master node must contain the following
properties:
- cci-control-port:
Usage: required
Value type: <phandle>
Definition: a phandle containing the CCI control interface node
the master is connected to.
Example:
cpus {
#size-cells = <0>;
#address-cells = <1>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
cci-control-port = <&cci_control1>;
reg = <0x0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
cci-control-port = <&cci_control1>;
reg = <0x1>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
cci-control-port = <&cci_control2>;
reg = <0x100>;
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
cci-control-port = <&cci_control2>;
reg = <0x101>;
};
};
dma0: dma@3000000 {
compatible = "arm,pl330", "arm,primecell";
cci-control-port = <&cci_control0>;
reg = <0x0 0x3000000 0x0 0x1000>;
interrupts = <10>;
#dma-cells = <1>;
#dma-channels = <8>;
#dma-requests = <32>;
};
cci@2c090000 {
compatible = "arm,cci-400";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0 0x2c090000 0 0x1000>;
ranges = <0x0 0x0 0x2c090000 0x10000>;
cci_control0: slave-if@1000 {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace-lite";
reg = <0x1000 0x1000>;
};
cci_control1: slave-if@4000 {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace";
reg = <0x4000 0x1000>;
};
cci_control2: slave-if@5000 {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace";
reg = <0x5000 0x1000>;
};
pmu@9000 {
compatible = "arm,cci-400-pmu";
reg = <0x9000 0x5000>;
interrupts = <0 101 4>,
<0 102 4>,
<0 103 4>,
<0 104 4>,
<0 105 4>;
};
};
This CCI node corresponds to a CCI component whose control registers sits
at address 0x000000002c090000.
CCI slave interface @0x000000002c091000 is connected to dma controller dma0.
CCI slave interface @0x000000002c094000 is connected to CPUs {CPU0, CPU1};
CCI slave interface @0x000000002c095000 is connected to CPUs {CPU2, CPU3};

View File

@ -0,0 +1,21 @@
Coherency fabric
----------------
Available on Marvell SOCs: Armada 370 and Armada XP
Required properties:
- compatible: "marvell,coherency-fabric"
- reg: Should contain coherency fabric registers location and
length. First pair for the coherency fabric registers, second pair
for the per-CPU fabric registers registers.
Example:
coherency-fabric@d0020200 {
compatible = "marvell,coherency-fabric";
reg = <0xd0020200 0xb0>,
<0xd0021810 0x1c>;
};

384
Bindings/arm/cpus.txt Normal file
View File

@ -0,0 +1,384 @@
=================
ARM CPUs bindings
=================
The device tree allows to describe the layout of CPUs in a system through
the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
defining properties for every cpu.
Bindings for CPU nodes follow the ePAPR v1.1 standard, available from:
https://www.power.org/documentation/epapr-version-1-1/
with updates for 32-bit and 64-bit ARM systems provided in this document.
================================
Convention used in this document
================================
This document follows the conventions described in the ePAPR v1.1, with
the addition:
- square brackets define bitfields, eg reg[7:0] value of the bitfield in
the reg property contained in bits 7 down to 0
=====================================
cpus and cpu node bindings definition
=====================================
The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu
nodes to be present and contain the properties described below.
- cpus node
Description: Container of cpu nodes
The node name must be "cpus".
A cpus node must define the following properties:
- #address-cells
Usage: required
Value type: <u32>
Definition depends on ARM architecture version and
configuration:
# On uniprocessor ARM architectures previous to v7
value must be 1, to enable a simple enumeration
scheme for processors that do not have a HW CPU
identification register.
# On 32-bit ARM 11 MPcore, ARM v7 or later systems
value must be 1, that corresponds to CPUID/MPIDR
registers sizes.
# On ARM v8 64-bit systems value should be set to 2,
that corresponds to the MPIDR_EL1 register size.
If MPIDR_EL1[63:32] value is equal to 0 on all CPUs
in the system, #address-cells can be set to 1, since
MPIDR_EL1[63:32] bits are not used for CPUs
identification.
- #size-cells
Usage: required
Value type: <u32>
Definition: must be set to 0
- cpu node
Description: Describes a CPU in an ARM based system
PROPERTIES
- device_type
Usage: required
Value type: <string>
Definition: must be "cpu"
- reg
Usage and definition depend on ARM architecture version and
configuration:
# On uniprocessor ARM architectures previous to v7
this property is required and must be set to 0.
# On ARM 11 MPcore based systems this property is
required and matches the CPUID[11:0] register bits.
Bits [11:0] in the reg cell must be set to
bits [11:0] in CPU ID register.
All other bits in the reg cell must be set to 0.
# On 32-bit ARM v7 or later systems this property is
required and matches the CPU MPIDR[23:0] register
bits.
Bits [23:0] in the reg cell must be set to
bits [23:0] in MPIDR.
All other bits in the reg cell must be set to 0.
# On ARM v8 64-bit systems this property is required
and matches the MPIDR_EL1 register affinity bits.
* If cpus node's #address-cells property is set to 2
The first reg cell bits [7:0] must be set to
bits [39:32] of MPIDR_EL1.
The second reg cell bits [23:0] must be set to
bits [23:0] of MPIDR_EL1.
* If cpus node's #address-cells property is set to 1
The reg cell bits [23:0] must be set to bits [23:0]
of MPIDR_EL1.
All other bits in the reg cells must be set to 0.
- compatible:
Usage: required
Value type: <string>
Definition: should be one of:
"arm,arm710t"
"arm,arm720t"
"arm,arm740t"
"arm,arm7ej-s"
"arm,arm7tdmi"
"arm,arm7tdmi-s"
"arm,arm9es"
"arm,arm9ej-s"
"arm,arm920t"
"arm,arm922t"
"arm,arm925"
"arm,arm926e-s"
"arm,arm926ej-s"
"arm,arm940t"
"arm,arm946e-s"
"arm,arm966e-s"
"arm,arm968e-s"
"arm,arm9tdmi"
"arm,arm1020e"
"arm,arm1020t"
"arm,arm1022e"
"arm,arm1026ej-s"
"arm,arm1136j-s"
"arm,arm1136jf-s"
"arm,arm1156t2-s"
"arm,arm1156t2f-s"
"arm,arm1176jzf"
"arm,arm1176jz-s"
"arm,arm1176jzf-s"
"arm,arm11mpcore"
"arm,cortex-a5"
"arm,cortex-a7"
"arm,cortex-a8"
"arm,cortex-a9"
"arm,cortex-a15"
"arm,cortex-a53"
"arm,cortex-a57"
"arm,cortex-m0"
"arm,cortex-m0+"
"arm,cortex-m1"
"arm,cortex-m3"
"arm,cortex-m4"
"arm,cortex-r4"
"arm,cortex-r5"
"arm,cortex-r7"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
"marvell,feroceon"
"marvell,mohawk"
"marvell,pj4a"
"marvell,pj4b"
"marvell,sheeva-v5"
"qcom,krait"
"qcom,scorpion"
- enable-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:
"spin-table"
"psci"
# On ARM 32-bit systems this property is optional.
- cpu-release-addr
Usage: required for systems that have an "enable-method"
property value of "spin-table".
Value type: <prop-encoded-array>
Definition:
# On ARM v8 64-bit systems must be a two cell
property identifying a 64-bit zero-initialised
memory location.
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
};
cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
};
cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
};
};
Example 2 (Cortex-A8 uniprocessor 32-bit system):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a8";
reg = <0x0>;
};
};
Example 3 (ARM 926EJ-S uniprocessor 32-bit system):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu@0 {
device_type = "cpu";
compatible = "arm,arm926ej-s";
reg = <0x0>;
};
};
Example 4 (ARM Cortex-A57 64-bit system):
cpus {
#size-cells = <0>;
#address-cells = <2>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
};

17
Bindings/arm/davinci.txt Normal file
View File

@ -0,0 +1,17 @@
Texas Instruments DaVinci Platforms Device Tree Bindings
--------------------------------------------------------
DA850/OMAP-L138/AM18x Evaluation Module (EVM) board
Required root node properties:
- compatible = "ti,da850-evm", "ti,da850";
EnBW AM1808 based CMC board
Required root node properties:
- compatible = "enbw,cmc", "ti,da850;
Generic DaVinci Boards
----------------------
DA850/OMAP-L138/AM18x generic board
Required root node properties:
- compatible = "ti,da850";

View File

@ -0,0 +1,27 @@
* TI Common Platform Interrupt Controller
Common Platform Interrupt Controller (cp_intc) is used on
OMAP-L1x SoCs and can support several configurable number
of interrupts.
Main node required properties:
- compatible : should be:
"ti,cp-intc"
- 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 1.
The cell contains the interrupt number in the range [0-128].
- ti,intc-size: Number of interrupts handled by the interrupt controller.
- reg: physical base address and size of the intc registers map.
Example:
intc: interrupt-controller@1 {
compatible = "ti,cp-intc";
interrupt-controller;
#interrupt-cells = <1>;
ti,intc-size = <101>;
reg = <0xfffee000 0x2000>;
};

View File

@ -0,0 +1,28 @@
* Samsung Exynos Power Domains
Exynos processors include support for multiple power domains which are used
to gate power to one or more peripherals on the processor.
Required Properties:
- compatible: should be one of the following.
* samsung,exynos4210-pd - for exynos4210 type power domain.
- reg: physical base address of the controller and length of memory mapped
region.
Node of a device using power domains must have a samsung,power-domain property
defined with a phandle to respective power domain.
Example:
lcd0: power-domain-lcd0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C00 0x10>;
};
Example of the node using power domain:
node {
/* ... */
samsung,power-domain = <&lcd0>;
/* ... */
};

View File

@ -0,0 +1,20 @@
Trusted Foundations
-------------------
Boards that use the Trusted Foundations secure monitor can signal its
presence by declaring a node compatible with "tlm,trusted-foundations"
under the /firmware/ node
Required properties:
- compatible: "tlm,trusted-foundations"
- tlm,version-major: major version number of Trusted Foundations firmware
- tlm,version-minor: minor version number of Trusted Foundations firmware
Example:
firmware {
trusted-foundations {
compatible = "tlm,trusted-foundations";
tlm,version-major = <2>;
tlm,version-minor = <8>;
};
};

76
Bindings/arm/fsl.txt Normal file
View File

@ -0,0 +1,76 @@
Freescale i.MX Platforms Device Tree Bindings
-----------------------------------------------
i.MX23 Evaluation Kit
Required root node properties:
- compatible = "fsl,imx23-evk", "fsl,imx23";
i.MX25 Product Development Kit
Required root node properties:
- compatible = "fsl,imx25-pdk", "fsl,imx25";
i.MX27 Product Development Kit
Required root node properties:
- compatible = "fsl,imx27-pdk", "fsl,imx27";
i.MX28 Evaluation Kit
Required root node properties:
- compatible = "fsl,imx28-evk", "fsl,imx28";
i.MX51 Babbage Board
Required root node properties:
- compatible = "fsl,imx51-babbage", "fsl,imx51";
i.MX53 Automotive Reference Design Board
Required root node properties:
- compatible = "fsl,imx53-ard", "fsl,imx53";
i.MX53 Evaluation Kit
Required root node properties:
- compatible = "fsl,imx53-evk", "fsl,imx53";
i.MX53 Quick Start Board
Required root node properties:
- compatible = "fsl,imx53-qsb", "fsl,imx53";
i.MX53 Smart Mobile Reference Design Board
Required root node properties:
- compatible = "fsl,imx53-smd", "fsl,imx53";
i.MX6 Quad Armadillo2 Board
Required root node properties:
- compatible = "fsl,imx6q-arm2", "fsl,imx6q";
i.MX6 Quad SABRE Lite Board
Required root node properties:
- compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";
i.MX6 Quad SABRE Smart Device Board
Required root node properties:
- compatible = "fsl,imx6q-sabresd", "fsl,imx6q";
i.MX6 Quad SABRE Automotive Board
Required root node properties:
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
Generic i.MX boards
-------------------
No iomux setup is done for these boards, so this must have been configured
by the bootloader for boards to work with the generic bindings.
i.MX27 generic board
Required root node properties:
- compatible = "fsl,imx27";
i.MX51 generic board
Required root node properties:
- compatible = "fsl,imx51";
i.MX53 generic board
Required root node properties:
- compatible = "fsl,imx53";
i.MX6q generic board
Required root node properties:
- compatible = "fsl,imx6q";

91
Bindings/arm/gic.txt Normal file
View File

@ -0,0 +1,91 @@
* ARM Generic Interrupt Controller
ARM SMP cores are often associated with a GIC, providing per processor
interrupts (PPI), shared processor interrupts (SPI) and software
generated interrupts (SGI).
Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
Secondary GICs are cascaded into the upward interrupt controller and do not
have PPIs or SGIs.
Main node required properties:
- compatible : should be one of:
"arm,gic-400"
"arm,cortex-a15-gic"
"arm,cortex-a9-gic"
"arm,cortex-a7-gic"
"arm,arm11mp-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
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
4 = active high level-sensitive
8 = active low level-sensitive
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.
- 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
the GIC cpu interface register base and size.
Optional
- interrupts : Interrupt source of the parent interrupt controller on
secondary GICs, or VGIC maintenance interrupt on primary GIC (see
below).
- cpu-offset : per-cpu offset within the distributor and cpu interface
regions, used when the GIC doesn't have banked registers. The offset is
cpu-offset * cpu-nr.
Example:
intc: interrupt-controller@fff11000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
#address-cells = <1>;
interrupt-controller;
reg = <0xfff11000 0x1000>,
<0xfff10100 0x100>;
};
* GIC virtualization extensions (VGIC)
For ARM cores that support the virtualization extensions, additional
properties must be described (they only exist if the GIC is the
primary interrupt controller).
Required properties:
- reg : Additional regions specifying the base physical address and
size of the VGIC registers. The first additional region is the GIC
virtual interface control register base and size. The 2nd additional
region is the GIC virtual cpu interface register base and size.
- interrupts : VGIC maintenance interrupt.
Example:
interrupt-controller@2c001000 {
compatible = "arm,cortex-a15-gic";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x2c001000 0x1000>,
<0x2c002000 0x1000>,
<0x2c004000 0x2000>,
<0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
};

View File

@ -0,0 +1,24 @@
* ARM Global Timer
Cortex-A9 are often associated with a per-core Global timer.
** Timer node required properties:
- compatible : Should be "arm,cortex-a9-global-timer"
Driver supports versions r2p0 and above.
- interrupts : One interrupt to each core
- reg : Specify the base address and the size of the GT timer
register window.
- clocks : Should be phandle to a clock.
Example:
timer@2c000600 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x2c000600 0x20>;
interrupts = <1 13 0xf01>;
clocks = <&arm_periph_clk>;
};

View File

@ -0,0 +1,32 @@
Hisilicon Platforms Device Tree Bindings
----------------------------------------------------
Hi4511 Board
Required root node properties:
- compatible = "hisilicon,hi3620-hi4511";
Hisilicon system controller
Required properties:
- compatible : "hisilicon,sysctrl"
- reg : Register address and size
Optional properties:
- smp-offset : offset in sysctrl for notifying slave cpu booting
cpu 1, reg;
cpu 2, reg + 0x4;
cpu 3, reg + 0x8;
If reg value is not zero, cpun exit wfi and go
- resume-offset : offset in sysctrl for notifying cpu0 when resume
- reboot-offset : offset in sysctrl for system reboot
Example:
/* for Hi3620 */
sysctrl: system-controller@fc802000 {
compatible = "hisilicon,sysctrl";
reg = <0xfc802000 0x1000>;
smp-offset = <0x31c>;
resume-offset = <0x308>;
reboot-offset = <0x4>;
};

View File

@ -0,0 +1,8 @@
* Insignal's Exynos4210 based Origen evaluation board
Origen low-cost evaluation board is based on Samsung's Exynos4210 SoC.
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.

View File

@ -0,0 +1,10 @@
TI Keystone Platforms Device Tree Bindings
-----------------------------------------------
Boards with Keystone2 based devices (TCI66xxK2H) SOC shall have the
following properties.
Required properties:
- compatible: All TI specific devices present in Keystone SOC should be in
the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
type UART should use the specified compatible for those devices.

27
Bindings/arm/kirkwood.txt Normal file
View File

@ -0,0 +1,27 @@
Marvell Kirkwood Platforms Device Tree Bindings
-----------------------------------------------
Boards with a SoC of the Marvell Kirkwood
shall have the following property:
Required root node property:
compatible: must contain "marvell,kirkwood";
In order to support the kirkwood cpufreq driver, there must be a node
cpus/cpu@0 with three clocks, "cpu_clk", "ddrclk" and "powersave",
where the "powersave" clock is a gating clock used to switch the CPU
between the "cpu_clk" and the "ddrclk".
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "marvell,sheeva-88SV131";
clocks = <&core_clk 1>, <&core_clk 3>, <&gate_clk 11>;
clock-names = "cpu_clk", "ddrclk", "powersave";
};

59
Bindings/arm/l2cc.txt Normal file
View File

@ -0,0 +1,59 @@
* ARM L2 Cache Controller
ARM cores often have a separate level 2 cache controller. There are various
implementations of the L2 cache controller with compatible programming models.
The ARM L2 cache representation in the device tree should be done as follows:
Required properties:
- compatible : should be one of:
"arm,pl310-cache"
"arm,l220-cache"
"arm,l210-cache"
"bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
"brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
offset needs to be added to the address before passing down to the L2
cache controller
"marvell,aurora-system-cache": Marvell Controller designed to be
compatible with the ARM one, with system cache mode (meaning
maintenance operations on L1 are broadcasted to the L2 and L2
performs the same operation).
"marvell,aurora-outer-cache": Marvell Controller designed to be
compatible with the ARM one with outer cache mode.
"marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible
with arm,pl310-cache controller.
- cache-unified : Specifies the cache is a unified cache.
- cache-level : Should be set to 2 for a level 2 cache.
- reg : Physical base address and size of cache controller's memory mapped
registers.
Optional properties:
- arm,data-latency : Cycles of latency for Data RAM accesses. Specifies 3 cells of
read, write and setup latencies. Minimum valid values are 1. Controllers
without setup latency control should use a value of 0.
- arm,tag-latency : Cycles of latency for Tag RAM accesses. Specifies 3 cells of
read, write and setup latencies. Controllers without setup latency control
should use 0. Controllers without separate read and write Tag RAM latency
values should only use the first cell.
- arm,dirty-latency : Cycles of latency for Dirty RAMs. This is a single cell.
- arm,filter-ranges : <start length> Starting address and length of window to
filter. Addresses in the filter window are directed to the M1 port. Other
addresses will go to the M0 port.
- interrupts : 1 combined interrupt.
- 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
Example:
L2: cache-controller {
compatible = "arm,pl310-cache";
reg = <0xfff12000 0x1000>;
arm,data-latency = <1 1 1>;
arm,tag-latency = <2 2 2>;
arm,filter-ranges = <0x80000000 0x8000000>;
cache-unified;
cache-level = <2>;
interrupts = <45>;
};

View File

@ -0,0 +1,38 @@
* NXP LPC32xx Main Interrupt Controller
(MIC, including SIC1 and SIC2 secondary controllers)
Required properties:
- compatible: Should be "nxp,lpc3220-mic"
- interrupt-controller: Identifies the node as an interrupt controller.
- interrupt-parent: Empty for the interrupt controller itself
- #interrupt-cells: The number of cells to define the interrupts. Should be 2.
The first cell is the IRQ number
The second cell is used to specify mode:
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
Default for internal sources should be set to 4 (active high).
- reg: Should contain MIC registers location and length
Examples:
/*
* MIC
*/
mic: interrupt-controller@40008000 {
compatible = "nxp,lpc3220-mic";
interrupt-controller;
interrupt-parent;
#interrupt-cells = <2>;
reg = <0x40008000 0xC000>;
};
/*
* ADC
*/
adc@40048000 {
compatible = "nxp,lpc3220-adc";
reg = <0x40048000 0x1000>;
interrupt-parent = <&mic>;
interrupts = <39 4>;
};

8
Bindings/arm/lpc32xx.txt Normal file
View File

@ -0,0 +1,8 @@
NXP LPC32xx Platforms Device Tree Bindings
------------------------------------------
Boards with the NXP LPC32xx SoC shall have the following properties:
Required root node property:
compatible: must be "nxp,lpc3220", "nxp,lpc3230", "nxp,lpc3240" or "nxp,lpc3250"

View File

@ -0,0 +1,24 @@
Marvell Berlin SoC Family Device Tree Bindings
---------------------------------------------------------------
Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
shall have the following properties:
* Required root node properties:
compatible: must contain "marvell,berlin"
In addition, the above compatible shall be extended with the specific
SoC and board used. Currently known SoC compatibles are:
"marvell,berlin2" for Marvell Armada 1500 (BG2, 88DE3100),
"marvell,berlin2cd" for Marvell Armada 1500-mini (BG2CD, 88DE3005)
"marvell,berlin2ct" for Marvell Armada ? (BG2CT, 88DE????)
"marvell,berlin3" for Marvell Armada ? (BG3, 88DE????)
* Example:
/ {
model = "Sony NSZ-GS7";
compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
...
}

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

@ -0,0 +1,12 @@
MOXA ART device tree bindings
Boards with the MOXA ART SoC shall have the following properties:
Required root node property:
compatible = "moxa,moxart";
Boards:
- UC-7112-LX: embedded computer
compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"

View File

@ -0,0 +1,60 @@
* Marvell MMP Interrupt controller
Required properties:
- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
"mrvl,mmp2-mux-intc"
- reg : Address and length of the register set of the interrupt controller.
If the interrupt controller is intc, address and length means the range
of the whold interrupt controller. If the interrupt controller is mux-intc,
address and length means one register. Since address of mux-intc is in the
range of intc. mux-intc is secondary interrupt controller.
- reg-names : Name of the register set of the interrupt controller. It's
only required in mux-intc interrupt controller.
- interrupts : Should be the port interrupt shared by mux interrupts. It's
only required in mux-intc interrupt controller.
- interrupt-controller : Identifies the node as an interrupt controller.
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source.
- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
controller.
- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
detection first.
Example:
intc: interrupt-controller@d4282000 {
compatible = "mrvl,mmp2-intc";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0xd4282000 0x1000>;
mrvl,intc-nr-irqs = <64>;
};
intcmux4@d4282150 {
compatible = "mrvl,mmp2-mux-intc";
interrupts = <4>;
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x150 0x4>, <0x168 0x4>;
reg-names = "mux status", "mux mask";
mrvl,intc-nr-irqs = <2>;
};
* Marvell Orion Interrupt controller
Required properties
- compatible : Should be "marvell,orion-intc".
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source. Supported value is <1>.
- interrupt-controller : Declare this node to be an interrupt controller.
- reg : Interrupt mask address. A list of 4 byte ranges, one per controller.
One entry in the list represents 32 interrupts.
Example:
intc: interrupt-controller {
compatible = "marvell,orion-intc", "marvell,intc";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0xfed20204 0x04>,
<0xfed20214 0x04>;
};

View File

@ -0,0 +1,14 @@
Marvell Platforms Device Tree Bindings
----------------------------------------------------
PXA168 Aspenite Board
Required root node properties:
- compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
PXA910 DKB Board
Required root node properties:
- compatible = "mrvl,pxa910-dkb";
MMP2 Brownstone Board
Required root node properties:
- compatible = "mrvl,mmp2-brownstone";

View File

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

View File

@ -0,0 +1,13 @@
* Marvell MMP Timer controller
Required properties:
- compatible : Should be "mrvl,mmp-timer".
- reg : Address and length of the register set of timer controller.
- interrupts : Should be the interrupt number.
Example:
timer0: timer@d4014000 {
compatible = "mrvl,mmp-timer";
reg = <0xd4014000 0x100>;
interrupts = <13>;
};

18
Bindings/arm/msm/ssbi.txt Normal file
View File

@ -0,0 +1,18 @@
* Qualcomm SSBI
Some Qualcomm MSM devices contain a point-to-point serial bus used to
communicate with a limited range of devices (mostly power management
chips).
These require the following properties:
- compatible: "qcom,ssbi"
- qcom,controller-type
indicates the SSBI bus variant the controller should use to talk
with the slave device. This should be one of "ssbi", "ssbi2", or
"pmic-arbiter". The type chosen is determined by the attached
slave.
The slave device should be the single child node of the ssbi device
with a compatible field.

View File

@ -0,0 +1,37 @@
* MSM Timer
Properties:
- compatible : Should at least contain "qcom,msm-timer". More specific
properties specify which subsystem the timers are paired with.
"qcom,kpss-timer" - krait subsystem
"qcom,scss-timer" - scorpion subsystem
- interrupts : Interrupts for the the debug timer, the first general purpose
timer, and optionally a second general purpose timer in that
order.
- reg : Specifies the base address of the timer registers.
- clock-frequency : The frequency of the debug timer and the general purpose
timer(s) in Hz in that order.
Optional:
- cpu-offset : per-cpu offset used when the timer is accessed without the
CPU remapping facilities. The offset is
cpu-offset + (0x10000 * cpu-nr).
Example:
timer@200a000 {
compatible = "qcom,scss-timer", "qcom,msm-timer";
interrupts = <1 1 0x301>,
<1 2 0x301>,
<1 3 0x301>;
reg = <0x0200a000 0x100>;
clock-frequency = <19200000>,
<32768>;
cpu-offset = <0x40000>;
};

View File

@ -0,0 +1,17 @@
MVEBU System Controller
-----------------------
MVEBU (Marvell SOCs: Armada 370/XP, Dove, mv78xx0, Kirkwood, Orion5x)
Required properties:
- compatible: one of:
- "marvell,orion-system-controller"
- "marvell,armada-370-xp-system-controller"
- reg: Should contain system controller registers location and length.
Example:
system-controller@d0018200 {
compatible = "marvell,armada-370-xp-system-controller";
reg = <0xd0018200 0x500>;
};

14
Bindings/arm/nspire.txt Normal file
View File

@ -0,0 +1,14 @@
TI-NSPIRE calculators
Required properties:
- compatible: Compatible property value should contain "ti,nspire".
CX models should have "ti,nspire-cx"
Touchpad models should have "ti,nspire-tp"
Clickpad models should have "ti,nspire-clp"
Example:
/ {
model = "TI-NSPIRE CX";
compatible = "ti,nspire-cx";
...

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

@ -0,0 +1,6 @@
Olimex i.MX Platforms Device Tree Bindings
------------------------------------------
i.MX23 Olinuxino Low Cost Board
Required root node properties:
- compatible = "olimex,imx23-olinuxino", "fsl,imx23";

View File

@ -0,0 +1,15 @@
OMAP Counter-32K bindings
Required properties:
- compatible: Must be "ti,omap-counter32k" for OMAP controllers
- reg: Contains timer register address range (base address and length)
- ti,hwmods: Name of the hwmod associated to the counter, which is typically
"counter_32k"
Example:
counter32k: counter@4a304000 {
compatible = "ti,omap-counter32k";
reg = <0x4a304000 0x20>;
ti,hwmods = "counter_32k";
};

14
Bindings/arm/omap/dsp.txt Normal file
View File

@ -0,0 +1,14 @@
* TI - DSP (Digital Signal Processor)
TI DSP included in OMAP SoC
Required properties:
- compatible : Should be "ti,omap3-c64" for OMAP3 & 4
- ti,hwmods: "dsp"
Examples:
dsp {
compatible = "ti,omap3-c64";
ti,hwmods = "dsp";
};

View File

@ -0,0 +1,27 @@
* OMAP Interrupt Controller
OMAP2/3 are using a TI interrupt controller that can support several
configurable number of interrupts.
Main node required properties:
- compatible : should be:
"ti,omap2-intc"
- 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 1.
The cell contains the interrupt number in the range [0-128].
- ti,intc-size: Number of interrupts handled by the interrupt controller.
- reg: physical base address and size of the intc registers map.
Example:
intc: interrupt-controller@1 {
compatible = "ti,omap2-intc";
interrupt-controller;
#interrupt-cells = <1>;
ti,intc-size = <96>;
reg = <0x48200000 0x1000>;
};

19
Bindings/arm/omap/iva.txt Normal file
View File

@ -0,0 +1,19 @@
* TI - IVA (Imaging and Video Accelerator) subsystem
The IVA contain various audio, video or imaging HW accelerator
depending of the version.
Required properties:
- compatible : Should be:
- "ti,ivahd" for OMAP4
- "ti,iva2.2" for OMAP3
- "ti,iva2.1" for OMAP2430
- "ti,iva1" for OMAP2420
- ti,hwmods: "iva"
Examples:
iva {
compatible = "ti,ivahd", "ti,iva";
ti,hwmods = "iva";
};

View File

@ -0,0 +1,20 @@
* TI - L3 Network On Chip (NoC)
This version is an implementation of the generic NoC IP
provided by Arteris.
Required properties:
- compatible : Should be "ti,omap3-l3-smx" for OMAP3 family
Should be "ti,omap4-l3-noc" for OMAP4 family
- reg: Contains L3 register address range for each noc domain.
- ti,hwmods: "l3_main_1", ... One hwmod for each noc domain.
Examples:
ocp {
compatible = "ti,omap4-l3-noc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
};

35
Bindings/arm/omap/mpu.txt Normal file
View File

@ -0,0 +1,35 @@
* TI - MPU (Main Processor Unit) subsystem
The MPU subsystem contain one or several ARM cores
depending of the version.
The MPU contain CPUs, GIC, L2 cache and a local PRCM.
Required properties:
- compatible : Should be "ti,omap3-mpu" for OMAP3
Should be "ti,omap4-mpu" for OMAP4
Should be "ti,omap5-mpu" for OMAP5
- ti,hwmods: "mpu"
Examples:
- For an OMAP5 SMP system:
mpu {
compatible = "ti,omap5-mpu";
ti,hwmods = "mpu"
};
- For an OMAP4 SMP system:
mpu {
compatible = "ti,omap4-mpu";
ti,hwmods = "mpu";
};
- For an OMAP3 monocore system:
mpu {
compatible = "ti,omap3-mpu";
ti,hwmods = "mpu";
};

118
Bindings/arm/omap/omap.txt Normal file
View File

@ -0,0 +1,118 @@
* Texas Instruments OMAP
OMAP is currently using a static file per SoC family to describe the
IPs present in the SoC.
On top of that an omap_device is created to extend the platform_device
capabilities and to allow binding with one or several hwmods.
The hwmods will contain all the information to build the device:
address range, irq lines, dma lines, interconnect, PRCM register,
clock domain, input clocks.
For the moment just point to the existing hwmod, the next step will be
to move data from hwmod to device-tree representation.
Required properties:
- compatible: Every devices present in OMAP SoC should be in the
form: "ti,XXX"
- ti,hwmods: list of hwmod names (ascii strings), that comes from the OMAP
HW documentation, attached to a device. Must contain at least
one hwmod.
Optional properties:
- ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
during suspend.
- ti,no-reset-on-init: When present, the module should not be reset at init
- ti,no-idle-on-init: When present, the module should not be idled at init
Example:
spinlock@1 {
compatible = "ti,omap4-spinlock";
ti,hwmods = "spinlock";
};
SoC Type (optional):
- General Purpose devices
compatible = "ti,gp"
- High Security devices
compatible = "ti,hs"
SoC Families:
- OMAP2 generic - defaults to OMAP2420
compatible = "ti,omap2"
- OMAP3 generic - defaults to OMAP3430
compatible = "ti,omap3"
- OMAP4 generic - defaults to OMAP4430
compatible = "ti,omap4"
- OMAP5 generic - defaults to OMAP5430
compatible = "ti,omap5"
- DRA7 generic - defaults to DRA742
compatible = "ti,dra7"
- AM43x generic - defaults to AM4372
compatible = "ti,am43"
SoCs:
- OMAP2420
compatible = "ti,omap2420", "ti,omap2"
- OMAP2430
compatible = "ti,omap2430", "ti,omap2"
- OMAP3430
compatible = "ti,omap3430", "ti,omap3"
- AM3517
compatible = "ti,am3517", "ti,omap3"
- OMAP3630
compatible = "ti,omap36xx", "ti,omap3"
- AM33xx
compatible = "ti,am33xx", "ti,omap3"
- OMAP4430
compatible = "ti,omap4430", "ti,omap4"
- OMAP4460
compatible = "ti,omap4460", "ti,omap4"
- OMAP5430
compatible = "ti,omap5430", "ti,omap5"
- OMAP5432
compatible = "ti,omap5432", "ti,omap5"
- DRA742
compatible = "ti,dra7xx", "ti,dra7"
- AM4372
compatible = "ti,am4372", "ti,am43"
Boards:
- OMAP3 BeagleBoard : Low cost community board
compatible = "ti,omap3-beagle", "ti,omap3"
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3"
- OMAP4 SDP : Software Development Board
compatible = "ti,omap4-sdp", "ti,omap4430"
- OMAP4 PandaBoard : Low cost community board
compatible = "ti,omap4-panda", "ti,omap4430"
- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
compatible = "ti,omap3-evm", "ti,omap3"
- AM335X EVM : Software Development Board for AM335x
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
- AM335X Bone : Low cost community board
compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"
- AM43x EPOS EVM
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
- DRA7 EVM: Software Developement Board for DRA7XX
compatible = "ti,dra7-evm", "ti,dra7"

View File

@ -0,0 +1,44 @@
OMAP Timer bindings
Required properties:
- compatible: Should be set to one of the below. Please note that
OMAP44xx devices have timer instances that are 100%
register compatible with OMAP3xxx devices as well as
newer timers that are not 100% register compatible.
So for OMAP44xx devices timer instances may use
different compatible strings.
ti,omap2420-timer (applicable to OMAP24xx devices)
ti,omap3430-timer (applicable to OMAP3xxx/44xx devices)
ti,omap4430-timer (applicable to OMAP44xx devices)
ti,omap5430-timer (applicable to OMAP543x devices)
ti,am335x-timer (applicable to AM335x devices)
ti,am335x-timer-1ms (applicable to AM335x devices)
- reg: Contains timer register address range (base address and
length).
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the OMAP device uses.
- ti,hwmods: Name of the hwmod associated to the timer, "timer<X>",
where <X> is the instance number of the timer from the
HW spec.
Optional properties:
- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
- ti,timer-dsp: Indicates the timer can interrupt the on-chip DSP in
addition to the ARM CPU.
- ti,timer-pwm: Indicates the timer can generate a PWM output.
- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
and therefore cannot be used by the kernel.
Example:
timer12: timer@48304000 {
compatible = "ti,omap3430-timer";
reg = <0x48304000 0x400>;
interrupts = <95>;
ti,hwmods = "timer12"
ti,timer-alwon;
ti,timer-secure;
};

View File

@ -0,0 +1,24 @@
Picochip picoXcell device tree bindings.
========================================
Required root node properties:
- compatible:
- "picochip,pc7302-pc3x3" : PC7302 development board with PC3X3 device.
- "picochip,pc7302-pc3x2" : PC7302 development board with PC3X2 device.
- "picochip,pc3x3" : picoXcell PC3X3 device based board.
- "picochip,pc3x2" : picoXcell PC3X2 device based board.
Timers required properties:
- compatible = "picochip,pc3x2-timer"
- interrupts : The single IRQ line for the timer.
- clock-freq : The frequency in HZ of the timer.
- reg : The register bank for the timer.
Note: two timers are required - one for the scheduler clock and one for the
event tick/NOHZ.
VIC required properties:
- compatible = "arm,pl192-vic".
- interrupt-controller.
- reg : The register bank for the device.
- #interrupt-cells : Must be 1.

26
Bindings/arm/pmu.txt Normal file
View File

@ -0,0 +1,26 @@
* ARM Performance Monitor Units
ARM cores often have a PMU for counting cpu and cache events like cache misses
and hits. The interface to the PMU is part of the ARM ARM. The ARM PMU
representation in the device tree should be done as under:-
Required properties:
- compatible : should be one of
"arm,armv8-pmuv3"
"arm,cortex-a15-pmu"
"arm,cortex-a9-pmu"
"arm,cortex-a8-pmu"
"arm,cortex-a7-pmu"
"arm,cortex-a5-pmu"
"arm,arm11mpcore-pmu"
"arm,arm1176-pmu"
"arm,arm1136-pmu"
- interrupts : 1 combined interrupt or 1 per core.
Example:
pmu {
compatible = "arm,cortex-a9-pmu";
interrupts = <100 101>;
};

View File

@ -0,0 +1,46 @@
* ARM Primecell Peripherals
ARM, Ltd. Primecell peripherals have a standard id register that can be used to
identify the peripheral type, vendor, and revision. This value can be used for
driver matching.
Required properties:
- compatible : should be a specific name for the peripheral and
"arm,primecell". The specific name will match the ARM
engineering name for the logic block in the form: "arm,pl???"
Optional properties:
- arm,primecell-periphid : Value to override the h/w value with
- clocks : From common clock binding. First clock is phandle to clock for apb
pclk. Additional clocks are optional and specific to those peripherals.
- clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
- dmas : From common DMA binding. If present, refers to one or more dma channels.
- dma-names : From common DMA binding, needs to match the 'dmas' property.
Devices with exactly one receive and transmit channel shall name
these "rx" and "tx", respectively.
- pinctrl-<n> : Pinctrl states as described in bindings/pinctrl/pinctrl-bindings.txt
- pinctrl-names : Names corresponding to the numbered pinctrl states
- interrupts : one or more interrupt specifiers
- interrupt-names : names corresponding to the interrupts properties
Example:
serial@fff36000 {
compatible = "arm,pl011", "arm,primecell";
arm,primecell-periphid = <0x00341011>;
clocks = <&pclk>;
clock-names = "apb_pclk";
dmas = <&dma-controller 4>, <&dma-controller 5>;
dma-names = "rx", "tx";
pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
pinctrl-1 = <&uart0_sleep_mode>;
pinctrl-names = "default","sleep";
interrupts = <0 11 0x4>;
};

55
Bindings/arm/psci.txt Normal file
View File

@ -0,0 +1,55 @@
* Power State Coordination Interface (PSCI)
Firmware implementing the PSCI functions described in ARM document number
ARM DEN 0022A ("Power State Coordination Interface System Software on ARM
processors") can be used by Linux to initiate various CPU-centric power
operations.
Issue A of the specification describes functions for CPU suspend, hotplug
and migration of secure software.
Functions are invoked by trapping to the privilege level of the PSCI
firmware (specified as part of the binding below) and passing arguments
in a manner similar to that specified by AAPCS:
r0 => 32-bit Function ID / return value
{r1 - r3} => Parameters
Note that the immediate field of the trapping instruction must be set
to #0.
Main node required properties:
- compatible : Must be "arm,psci"
- method : The method of calling the PSCI firmware. Permitted
values are:
"smc" : SMC #0, with the register assignments specified
in this binding.
"hvc" : HVC #0, with the register assignments specified
in this binding.
Main node optional properties:
- cpu_suspend : Function ID for CPU_SUSPEND operation
- cpu_off : Function ID for CPU_OFF operation
- cpu_on : Function ID for CPU_ON operation
- migrate : Function ID for MIGRATE operation
Example:
psci {
compatible = "arm,psci";
method = "smc";
cpu_suspend = <0x95c10000>;
cpu_off = <0x95c10001>;
cpu_on = <0x95c10002>;
migrate = <0x95c10003>;
};

View File

@ -0,0 +1,19 @@
ARM Dual Cluster System Configuration Block
-------------------------------------------
The Dual Cluster System Configuration Block (DCSCB) provides basic
functionality for controlling clocks, resets and configuration pins in
the Dual Cluster System implemented by the Real-Time System Model (RTSM).
Required properties:
- compatible : should be "arm,rtsm,dcscb"
- reg : physical base address and the size of the registers window
Example:
dcscb@60000000 {
compatible = "arm,rtsm,dcscb";
reg = <0x60000000 0x1000>;
};

View File

@ -0,0 +1,18 @@
* Samsung's Exynos4210 based SMDKV310 evaluation board
SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC.
Required root node properties:
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
Optional:
- firmware node, specifying presence and type of secure firmware:
- compatible: only "samsung,secure-firmware" is currently supported
- reg: address of non-secure SYSRAM used for communication with firmware
firmware@0203F000 {
compatible = "samsung,secure-firmware";
reg = <0x0203F000 0x1000>;
};

View File

@ -0,0 +1,60 @@
Samsung Exynos Analog to Digital Converter bindings
The devicetree bindings are for the new ADC driver written for
Exynos4 and upward SoCs from Samsung.
New driver handles the following
1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
and future SoCs from Samsung
2. Add ADC driver under iio/adc framework
3. Also adds the Documentation for device tree bindings
Required properties:
- compatible: Must be "samsung,exynos-adc-v1"
for exynos4412/5250 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the Samsung device uses.
- #io-channel-cells = <1>; As ADC has multiple outputs
- clocks From common clock binding: handle to adc clock.
- clock-names From common clock binding: Shall be "adc".
- vdd-supply VDD input supply.
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>;
interrupts = <0 106 0>;
#io-channel-cells = <1>;
io-channel-ranges;
clocks = <&clock 303>;
clock-names = "adc";
vdd-supply = <&buck5_reg>;
};
Example: Adding child nodes in dts file
adc@12D10000 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
compatible = "ntc,ncp15wb473";
pullup-uv = <1800000>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;
io-channels = <&adc 4>;
};
};
Note: Does not apply to ADC driver under arch/arm/plat-samsung/
Note: The child node can be added under the adc node or separately.

View File

@ -0,0 +1,52 @@
* Samsung Exynos Interrupt Combiner Controller
Samsung's Exynos4 architecture includes a interrupt combiner controller which
can combine interrupt sources as a group and provide a single interrupt request
for the group. The interrupt request from each group are connected to a parent
interrupt controller, such as GIC in case of Exynos4210.
The interrupt combiner controller consists of multiple combiners. Up to eight
interrupt sources can be connected to a combiner. The combiner outputs one
combined interrupt for its eight interrupt sources. The combined interrupt
is usually connected to a parent interrupt controller.
A single node in the device tree is used to describe the interrupt combiner
controller module (which includes multiple combiners). A combiner in the
interrupt controller module shares config/control registers with other
combiners. For example, a 32-bit interrupt enable/disable config register
can accommodate up to 4 interrupt combiners (with each combiner supporting
up to 8 interrupt sources).
Required properties:
- compatible: should be "samsung,exynos4210-combiner".
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: should be <2>. The meaning of the cells are
* First Cell: Combiner Group Number.
* Second Cell: Interrupt number within the group.
- reg: Base address and size of interrupt combiner registers.
- interrupts: The list of interrupts generated by the combiners which are then
connected to a parent interrupt controller. The format of the interrupt
specifier depends in the interrupt parent controller.
Optional properties:
- samsung,combiner-nr: The number of interrupt combiners supported. If this
property is not specified, the default number of combiners is assumed
to be 16.
- interrupt-parent: pHandle of the parent interrupt controller, if not
inherited from the parent node.
Example:
The following is a an example from the Exynos4210 SoC dtsi file.
combiner:interrupt-controller@10440000 {
compatible = "samsung,exynos4210-combiner";
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x10440000 0x1000>;
interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
};

View File

@ -0,0 +1,12 @@
SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
Properties:
- compatible : should contain "samsung,<chip name>-sysreg", "syscon";
For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
- reg : offset and length of the register set.
Example:
syscon@10010000 {
compatible = "samsung,exynos4-sysreg", "syscon";
reg = <0x10010000 0x400>;
};

9
Bindings/arm/sirf.txt Normal file
View File

@ -0,0 +1,9 @@
CSR SiRFprimaII and SiRFmarco device tree bindings.
========================================
Required root node properties:
- compatible:
- "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

View File

@ -0,0 +1,18 @@
* SPEAr ARM Timer
** Timer node required properties:
- compatible : Should be:
"st,spear-timer"
- reg: Address range of the timer registers
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupt: Should contain the timer interrupt number
Example:
timer@f0000000 {
compatible = "st,spear-timer";
reg = <0xf0000000 0x400>;
interrupts = <2>;
};

26
Bindings/arm/spear.txt Normal file
View File

@ -0,0 +1,26 @@
ST SPEAr Platforms Device Tree Bindings
---------------------------------------
Boards with the ST SPEAr600 SoC shall have the following properties:
Required root node property:
compatible = "st,spear600";
Boards with the ST SPEAr300 SoC shall have the following properties:
Required root node property:
compatible = "st,spear300";
Boards with the ST SPEAr310 SoC shall have the following properties:
Required root node property:
compatible = "st,spear310";
Boards with the ST SPEAr320 SoC shall have the following properties:
Required root node property:
compatible = "st,spear320";
Boards with the ST SPEAr1310 SoC shall have the following properties:
Required root node property:
compatible = "st,spear1310";
Boards with the ST SPEAr1340 SoC shall have the following properties:
Required root node property:
compatible = "st,spear1340";

View File

@ -0,0 +1,48 @@
* SPEAr Shared IRQ layer (shirq)
SPEAr3xx architecture includes shared/multiplexed irqs for certain set
of devices. The multiplexor provides a single interrupt to parent
interrupt controller (VIC) on behalf of a group of devices.
There can be multiple groups available on SPEAr3xx variants but not
exceeding 4. The number of devices in a group can differ, further they
may share same set of status/mask registers spanning across different
bit masks. Also in some cases the group may not have enable or other
registers. This makes software little complex.
A single node in the device tree is used to describe the shared
interrupt multiplexor (one node for all groups). A group in the
interrupt controller shares config/control registers with other groups.
For example, a 32-bit interrupt enable/disable config register can
accommodate up to 4 interrupt groups.
Required properties:
- compatible: should be, either of
- "st,spear300-shirq"
- "st,spear310-shirq"
- "st,spear320-shirq"
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: should be <1> which basically contains the offset
(starting from 0) of interrupts for all the groups.
- reg: Base address and size of shirq registers.
- interrupts: The list of interrupts generated by the groups which are
then connected to a parent interrupt controller. Each group is
associated with one of the interrupts, hence number of interrupts (to
parent) is equal to number of groups. The format of the interrupt
specifier depends in the interrupt parent controller.
Optional properties:
- interrupt-parent: pHandle of the parent interrupt controller, if not
inherited from the parent node.
Example:
The following is an example from the SPEAr320 SoC dtsi file.
shirq: interrupt-controller@0xb3000000 {
compatible = "st,spear320-shirq";
reg = <0xb3000000 0x1000>;
interrupts = <28 29 30 1>;
#interrupt-cells = <1>;
interrupt-controller;
};

View File

@ -0,0 +1,32 @@
ST-Ericsson Nomadik Device Tree Bindings
For various board the "board" node may contain specific properties
that pertain to this particular board, such as board-specific GPIOs.
Required root node property: src
- Nomadik System and reset controller used for basic chip control, clock
and reset line control.
- compatible: must be "stericsson,nomadik,src"
Boards with the Nomadik SoC include:
S8815 "MiniKit" manufactured by Calao Systems:
Required root node property:
compatible="calaosystems,usb-s8815";
Required node: usb-s8815
Example:
usb-s8815 {
ethernet-gpio {
gpios = <&gpio3 19 0x1>;
interrupts = <19 0x1>;
interrupt-parent = <&gpio3>;
};
mmcsd-gpio {
gpios = <&gpio3 16 0x1>;
};
};

46
Bindings/arm/ste-u300.txt Normal file
View File

@ -0,0 +1,46 @@
ST-Ericsson U300 Device Tree Bindings
For various board the "board" node may contain specific properties
that pertain to this particular board, such as board-specific GPIOs
or board power regulator supplies.
Required root node property:
compatible="stericsson,u300";
Required node: syscon
This contains the system controller.
- compatible: must be "stericsson,u300-syscon".
- reg: the base address and size of the system controller.
Boards with the U300 SoC include:
S365 "Small Board U365":
Required node: s365
This contains the board-specific information.
- compatible: must be "stericsson,s365".
- vana15-supply: the regulator supplying the 1.5V to drive the
board.
- syscon: a pointer to the syscon node so we can access the
syscon registers to set the board as self-powered.
Example:
/ {
model = "ST-Ericsson U300";
compatible = "stericsson,u300";
#address-cells = <1>;
#size-cells = <1>;
s365 {
compatible = "stericsson,s365";
vana15-supply = <&ab3100_ldo_d_reg>;
syscon = <&syscon>;
};
syscon: syscon@c0011000 {
compatible = "stericsson,u300-syscon";
reg = <0xc0011000 0x1000>;
};
};

39
Bindings/arm/tegra.txt Normal file
View File

@ -0,0 +1,39 @@
NVIDIA Tegra device tree bindings
-------------------------------------------
SoCs
-------------------------------------------
Each device tree must specify which Tegra SoC it uses, using one of the
following compatible values:
nvidia,tegra20
nvidia,tegra30
Boards
-------------------------------------------
Each device tree must specify which one or more of the following
board-specific compatible values:
ad,medcom-wide
ad,plutux
ad,tamonten
ad,tec
compal,paz00
compulab,trimslice
nvidia,beaver
nvidia,cardhu
nvidia,cardhu-a02
nvidia,cardhu-a04
nvidia,harmony
nvidia,seaboard
nvidia,ventana
nvidia,whistler
toradex,colibri_t20-512
toradex,iris
Trusted Foundations
-------------------------------------------
Tegra supports the Trusted Foundation secure monitor. See the
"tlm,trusted-foundations" binding's documentation for more details.

View File

@ -0,0 +1,11 @@
NVIDIA Tegra AHB
Required properties:
- compatible : "nvidia,tegra20-ahb" or "nvidia,tegra30-ahb"
- reg : Should contain 1 register ranges(address and length)
Example:
ahb: ahb@6000c004 {
compatible = "nvidia,tegra20-ahb";
reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */
};

View File

@ -0,0 +1,100 @@
Embedded Memory Controller
Properties:
- name : Should be emc
- #address-cells : Should be 1
- #size-cells : Should be 0
- compatible : Should contain "nvidia,tegra20-emc".
- reg : Offset and length of the register set for the device
- nvidia,use-ram-code : If present, the sub-nodes will be addressed
and chosen using the ramcode board selector. If omitted, only one
set of tables can be present and said tables will be used
irrespective of ram-code configuration.
Child device nodes describe the memory settings for different configurations and clock rates.
Example:
memory-controller@7000f400 {
#address-cells = < 1 >;
#size-cells = < 0 >;
compatible = "nvidia,tegra20-emc";
reg = <0x7000f4000 0x200>;
}
Embedded Memory Controller ram-code table
If the emc node has the nvidia,use-ram-code property present, then the
next level of nodes below the emc table are used to specify which settings
apply for which ram-code settings.
If the emc node lacks the nvidia,use-ram-code property, this level is omitted
and the tables are stored directly under the emc node (see below).
Properties:
- name : Should be emc-tables
- nvidia,ram-code : the binary representation of the ram-code board strappings
for which this node (and children) are valid.
Embedded Memory Controller configuration table
This is a table containing the EMC register settings for the various
operating speeds of the memory controller. They are always located as
subnodes of the emc controller node.
There are two ways of specifying which tables to use:
* The simplest is if there is just one set of tables in the device tree,
and they will always be used (based on which frequency is used).
This is the preferred method, especially when firmware can fill in
this information based on the specific system information and just
pass it on to the kernel.
* The slightly more complex one is when more than one memory configuration
might exist on the system. The Tegra20 platform handles this during
early boot by selecting one out of possible 4 memory settings based
on a 2-pin "ram code" bootstrap setting on the board. The values of
these strappings can be read through a register in the SoC, and thus
used to select which tables to use.
Properties:
- name : Should be emc-table
- compatible : Should contain "nvidia,tegra20-emc-table".
- reg : either an opaque enumerator to tell different tables apart, or
the valid frequency for which the table should be used (in kHz).
- clock-frequency : the clock frequency for the EMC at which this
table should be used (in kHz).
- nvidia,emc-registers : a 46 word array of EMC registers to be programmed
for operation at the 'clock-frequency' setting.
The order and contents of the registers are:
RC, RFC, RAS, RP, R2W, W2R, R2P, W2P, RD_RCD, WR_RCD, RRD, REXT,
WDV, QUSE, QRST, QSAFE, RDV, REFRESH, BURST_REFRESH_NUM, PDEX2WR,
PDEX2RD, PCHG2PDEN, ACT2PDEN, AR2PDEN, RW2PDEN, TXSR, TCKE, TFAW,
TRPAB, TCLKSTABLE, TCLKSTOP, TREFBW, QUSE_EXTRA, FBIO_CFG6, ODT_WRITE,
ODT_READ, FBIO_CFG5, CFG_DIG_DLL, DLL_XFORM_DQS, DLL_XFORM_QUSE,
ZCAL_REF_CNT, ZCAL_WAIT_CNT, AUTO_CAL_INTERVAL, CFG_CLKTRIM_0,
CFG_CLKTRIM_1, CFG_CLKTRIM_2
emc-table@166000 {
reg = <166000>;
compatible = "nvidia,tegra20-emc-table";
clock-frequency = < 166000 >;
nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 >;
};
emc-table@333000 {
reg = <333000>;
compatible = "nvidia,tegra20-emc-table";
clock-frequency = < 333000 >;
nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 >;
};

View File

@ -0,0 +1,16 @@
NVIDIA Tegra20 MC(Memory Controller)
Required properties:
- compatible : "nvidia,tegra20-mc"
- reg : Should contain 2 register ranges(address and length); see the
example below. Note that the MC registers are interleaved with the
GART registers, and hence must be represented as multiple ranges.
- interrupts : Should contain MC General interrupt.
Example:
memory-controller@0x7000f000 {
compatible = "nvidia,tegra20-mc";
reg = <0x7000f000 0x024
0x7000f03c 0x3c4>;
interrupts = <0 77 0x04>;
};

View File

@ -0,0 +1,85 @@
NVIDIA Tegra Power Management Controller (PMC)
The PMC block interacts with an external Power Management Unit. The PMC
mostly controls the entry and exit of the system from different sleep
modes. It provides power-gating controllers for SoC and CPU power-islands.
Required properties:
- name : Should be pmc
- compatible : Should contain "nvidia,tegra<chip>-pmc".
- reg : Offset and length of the register set for the device
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names : Must include the following entries:
"pclk" (The Tegra clock of that name),
"clk32k_in" (The 32KHz clock input to Tegra).
Optional properties:
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
The PMU is an external Power Management Unit, whose interrupt output
signal is fed into the PMC. This signal is optionally inverted, and then
fed into the ARM GIC. The PMC is not involved in the detection or
handling of this interrupt signal, merely its inversion.
- nvidia,suspend-mode : The suspend mode that the platform should use.
Valid values are 0, 1 and 2:
0 (LP0): CPU + Core voltage off and DRAM in self-refresh
1 (LP1): CPU voltage off and DRAM in self-refresh
2 (LP2): CPU voltage off
- nvidia,core-power-req-active-high : Boolean, core power request active-high
- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high
- nvidia,combined-power-req : Boolean, combined power request for CPU & Core
- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
is enabled.
Required properties when nvidia,suspend-mode is specified:
- nvidia,cpu-pwr-good-time : CPU power good time in uS.
- nvidia,cpu-pwr-off-time : CPU power off time in uS.
- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
Core power good time in uS.
- nvidia,core-pwr-off-time : Core power off time in uS.
Required properties when nvidia,suspend-mode=<0>:
- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector
The LP0 vector contains the warm boot code that is executed by AVP when
resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7
processor and always being the first boot processor when chip is power on
or resume from deep sleep mode. When the system is resumed from the deep
sleep mode, the warm boot code will restore some PLLs, clocks and then
bring up CPU0 for resuming the system.
Example:
/ SoC dts including file
pmc@7000f400 {
compatible = "nvidia,tegra20-pmc";
reg = <0x7000e400 0x400>;
clocks = <&tegra_car 110>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
nvidia,invert-interrupt;
nvidia,suspend-mode = <1>;
nvidia,cpu-pwr-good-time = <2000>;
nvidia,cpu-pwr-off-time = <100>;
nvidia,core-pwr-good-time = <3845 3845>;
nvidia,core-pwr-off-time = <458>;
nvidia,core-power-req-active-high;
nvidia,sys-clock-req-active-high;
nvidia,lp0-vec = <0xbdffd000 0x2000>;
};
/ Tegra board dts file
{
...
clocks {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
clk32k_in: clock {
compatible = "fixed-clock";
reg=<0>;
#clock-cells = <0>;
clock-frequency = <32768>;
};
};
...
};

View File

@ -0,0 +1,18 @@
NVIDIA Tegra30 MC(Memory Controller)
Required properties:
- compatible : "nvidia,tegra30-mc"
- reg : Should contain 4 register ranges(address and length); see the
example below. Note that the MC registers are interleaved with the
SMMU registers, and hence must be represented as multiple ranges.
- interrupts : Should contain MC General interrupt.
Example:
memory-controller {
compatible = "nvidia,tegra30-mc";
reg = <0x7000f000 0x010
0x7000f03c 0x1b4
0x7000f200 0x028
0x7000f284 0x17c>;
interrupts = <0 77 0x04>;
};

474
Bindings/arm/topology.txt Normal file
View File

@ -0,0 +1,474 @@
===========================================
ARM topology binding description
===========================================
===========================================
1 - Introduction
===========================================
In an ARM system, the hierarchy of CPUs is defined through three entities that
are used to describe the layout of physical CPUs in the system:
- cluster
- core
- thread
The cpu nodes (bindings defined in [1]) represent the devices that
correspond to physical CPUs and are to be mapped to the hierarchy levels.
The bottom hierarchy level sits at core or thread level depending on whether
symmetric multi-threading (SMT) is supported or not.
For instance in a system where CPUs support SMT, "cpu" nodes represent all
threads existing in the system and map to the hierarchy level "thread" above.
In systems where SMT is not supported "cpu" nodes represent all cores present
in the system and map to the hierarchy level "core" above.
ARM topology bindings allow one to associate cpu nodes with hierarchical groups
corresponding to the system hierarchy; syntactically they are defined as device
tree nodes.
The remainder of this document provides the topology bindings for ARM, based
on the ePAPR standard, available from:
http://www.power.org/documentation/epapr-version-1-1/
If not stated otherwise, whenever a reference to a cpu node phandle is made its
value must point to a cpu node compliant with the cpu node bindings as
documented in [1].
A topology description containing phandles to cpu nodes that are not compliant
with bindings standardized in [1] is therefore considered invalid.
===========================================
2 - cpu-map node
===========================================
The ARM CPU topology is defined within the cpu-map node, which is a direct
child of the cpus node and provides a container where the actual topology
nodes are listed.
- cpu-map node
Usage: Optional - On ARM SMP systems provide CPUs topology to the OS.
ARM uniprocessor systems do not require a topology
description and therefore should not define a
cpu-map node.
Description: The cpu-map node is just a container node where its
subnodes describe the CPU topology.
Node name must be "cpu-map".
The cpu-map node's parent node must be the cpus node.
The cpu-map node's child nodes can be:
- one or more cluster nodes
Any other configuration is considered invalid.
The cpu-map node can only contain three types of child nodes:
- cluster node
- core node
- thread node
whose bindings are described in paragraph 3.
The nodes describing the CPU topology (cluster/core/thread) can only be
defined within the cpu-map node.
Any other configuration is consider invalid and therefore must be ignored.
===========================================
2.1 - cpu-map child nodes naming convention
===========================================
cpu-map child nodes must follow a naming convention where the node name
must be "clusterN", "coreN", "threadN" depending on the node type (ie
cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
are siblings within a single common parent node must be given a unique and
sequential N value, starting from 0).
cpu-map child nodes which do not share a common parent node can have the same
name (ie same number N as other cpu-map child nodes at different device tree
levels) since name uniqueness will be guaranteed by the device tree hierarchy.
===========================================
3 - cluster/core/thread node bindings
===========================================
Bindings for cluster/cpu/thread nodes are defined as follows:
- cluster node
Description: must be declared within a cpu-map node, one node
per cluster. A system can contain several layers of
clustering and cluster nodes can be contained in parent
cluster nodes.
The cluster node name must be "clusterN" as described in 2.1 above.
A cluster node can not be a leaf node.
A cluster node's child nodes must be:
- one or more cluster nodes; or
- one or more core nodes
Any other configuration is considered invalid.
- core node
Description: must be declared in a cluster node, one node per core in
the cluster. If the system does not support SMT, core
nodes are leaf nodes, otherwise they become containers of
thread nodes.
The core node name must be "coreN" as described in 2.1 above.
A core node must be a leaf node if SMT is not supported.
Properties for core nodes that are leaf nodes:
- cpu
Usage: required
Value type: <phandle>
Definition: a phandle to the cpu node that corresponds to the
core node.
If a core node is not a leaf node (CPUs supporting SMT) a core node's
child nodes can be:
- one or more thread nodes
Any other configuration is considered invalid.
- thread node
Description: must be declared in a core node, one node per thread
in the core if the system supports SMT. Thread nodes are
always leaf nodes in the device tree.
The thread node name must be "threadN" as described in 2.1 above.
A thread node must be a leaf node.
A thread node must contain the following property:
- cpu
Usage: required
Value type: <phandle>
Definition: a phandle to the cpu node that corresponds to
the thread node.
===========================================
4 - Example dts
===========================================
Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
cpus {
#size-cells = <0>;
#address-cells = <2>;
cpu-map {
cluster0 {
cluster0 {
core0 {
thread0 {
cpu = <&CPU0>;
};
thread1 {
cpu = <&CPU1>;
};
};
core1 {
thread0 {
cpu = <&CPU2>;
};
thread1 {
cpu = <&CPU3>;
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <&CPU4>;
};
thread1 {
cpu = <&CPU5>;
};
};
core1 {
thread0 {
cpu = <&CPU6>;
};
thread1 {
cpu = <&CPU7>;
};
};
};
};
cluster1 {
cluster0 {
core0 {
thread0 {
cpu = <&CPU8>;
};
thread1 {
cpu = <&CPU9>;
};
};
core1 {
thread0 {
cpu = <&CPU10>;
};
thread1 {
cpu = <&CPU11>;
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <&CPU12>;
};
thread1 {
cpu = <&CPU13>;
};
};
core1 {
thread0 {
cpu = <&CPU14>;
};
thread1 {
cpu = <&CPU15>;
};
};
};
};
};
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU4: cpu@10000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU5: cpu@10001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU6: cpu@10100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU7: cpu@10101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU8: cpu@100000000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU9: cpu@100000001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU10: cpu@100000100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU11: cpu@100000101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU12: cpu@100010000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU13: cpu@100010001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU14: cpu@100010100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU15: cpu@100010101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
};
Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu-map {
cluster0 {
core0 {
cpu = <&CPU0>;
};
core1 {
cpu = <&CPU1>;
};
core2 {
cpu = <&CPU2>;
};
core3 {
cpu = <&CPU3>;
};
};
cluster1 {
core0 {
cpu = <&CPU4>;
};
core1 {
cpu = <&CPU5>;
};
core2 {
cpu = <&CPU6>;
};
core3 {
cpu = <&CPU7>;
};
};
};
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
};
CPU2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
};
CPU3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
};
CPU4: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
};
CPU5: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
};
CPU6: cpu@102 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
};
CPU7: cpu@103 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
};
};
===============================================================================
[1] ARM Linux kernel documentation
Documentation/devicetree/bindings/arm/cpus.txt

48
Bindings/arm/twd.txt Normal file
View File

@ -0,0 +1,48 @@
* ARM Timer Watchdog
ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core
Timer-Watchdog (aka TWD), which provides both a per-cpu local timer
and watchdog.
The TWD is usually attached to a GIC to deliver its two per-processor
interrupts.
** Timer node required properties:
- compatible : Should be one of:
"arm,cortex-a9-twd-timer"
"arm,cortex-a5-twd-timer"
"arm,arm11mp-twd-timer"
- interrupts : One interrupt to each core
- reg : Specify the base address and the size of the TWD timer
register window.
Example:
twd-timer@2c000600 {
compatible = "arm,arm11mp-twd-timer"";
reg = <0x2c000600 0x20>;
interrupts = <1 13 0xf01>;
};
** Watchdog node properties:
- compatible : Should be one of:
"arm,cortex-a9-twd-wdt"
"arm,cortex-a5-twd-wdt"
"arm,arm11mp-twd-wdt"
- interrupts : One interrupt to each core
- reg : Specify the base address and the size of the TWD watchdog
register window.
Example:
twd-watchdog@2c000620 {
compatible = "arm,arm11mp-twd-wdt";
reg = <0x2c000620 0x20>;
interrupts = <1 14 0xf01>;
};

View File

@ -0,0 +1,36 @@
* ARM Versatile FPGA interrupt controller
One or more FPGA IRQ controllers can be synthesized in an ARM reference board
such as the Integrator or Versatile family. The output of these different
controllers are OR:ed together and fed to the CPU tile's IRQ input. Each
instance can handle up to 32 interrupts.
Required properties:
- compatible: "arm,versatile-fpga-irq"
- interrupt-controller: Identifies the node as an interrupt controller
- #interrupt-cells: The number of cells to define the interrupts. Must be 1
as the FPGA IRQ controller has no configuration options for interrupt
sources. The cell is a u32 and defines the interrupt number.
- reg: The register bank for the FPGA interrupt controller.
- clear-mask: a u32 number representing the mask written to clear all IRQs
on the controller at boot for example.
- valid-mask: a u32 number representing a bit mask determining which of
the interrupts are valid. Unconnected/unused lines are set to 0, and
the system till not make it possible for devices to request these
interrupts.
Example:
pic: pic@14000000 {
compatible = "arm,versatile-fpga-irq";
#interrupt-cells = <1>;
interrupt-controller;
reg = <0x14000000 0x100>;
clear-mask = <0xffffffff>;
valid-mask = <0x003fffff>;
};
Optional properties:
- interrupts: if the FPGA IRQ controller is cascaded, i.e. if its IRQ
output is simply connected to the input of another IRQ controller,
then the parent IRQ shall be specified in this property.

View File

@ -0,0 +1,33 @@
ARM Versatile Express Serial Configuration Controller
-----------------------------------------------------
Test chips for ARM Versatile Express platform implement SCC (Serial
Configuration Controller) interface, used to set initial conditions
for the test chip.
In some cases its registers are also mapped in normal address space
and can be used to obtain runtime information about the chip internals
(like silicon temperature sensors) and as interface to other subsystems
like platform configuration control and power management.
Required properties:
- compatible value: "arm,vexpress-scc,<model>", "arm,vexpress-scc";
where <model> is the full tile model name (as used
in the tile's Technical Reference Manual),
eg. for Coretile Express A15x2 A7x3 (V2P-CA15_A7):
compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
Optional properties:
- reg: when the SCC is memory mapped, physical address and size of the
registers window
- interrupts: when the SCC can generate a system-level interrupt
Example:
scc@7fff0000 {
compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
reg = <0 0x7fff0000 0 0x1000>;
interrupts = <0 95 4>;
};

View File

@ -0,0 +1,50 @@
ARM Versatile Express 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,vexpress,sysreg";
- reg : physical base address and the size of the registers window
- gpio-controller : specifies that the node is a GPIO controller
- #gpio-cells : size of the GPIO specifier, should be 2:
- first cell is the pseudo-GPIO line number:
0 - MMC CARDIN
1 - MMC WPROT
2 - NOR FLASH WPn
- second cell can take standard GPIO flags (currently ignored).
Example:
v2m_sysreg: sysreg@10000000 {
compatible = "arm,vexpress-sysreg";
reg = <0x10000000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
};
This block also can also act a bridge to the platform's configuration
bus via "system control" interface, addressing devices with site number,
position in the board stack, config controller, function and device
numbers - see motherboard's TRM for more details.
The node describing a config device must refer to the sysreg node via
"arm,vexpress,config-bridge" phandle (can be also defined in the node's
parent) and relies on the board topology properties - see main vexpress
node documentation for more details. It must also define the following
property:
- arm,vexpress-sysreg,func : must contain two cells:
- first cell defines function number (eg. 1 for clock generator,
2 for voltage regulators etc.)
- device number (eg. osc 0, osc 1 etc.)
Example:
mcc {
arm,vexpress,config-bridge = <&v2m_sysreg>;
osc@0 {
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 0>;
};
};

224
Bindings/arm/vexpress.txt Normal file
View File

@ -0,0 +1,224 @@
ARM Versatile Express boards family
-----------------------------------
ARM's Versatile Express platform consists of a motherboard and one
or more daughterboards (tiles). The motherboard provides a set of
peripherals. Processor and RAM "live" on the tiles.
The motherboard and each core tile should be described by a separate
Device Tree source file, with the tile's description including
the motherboard file using a /include/ directive. As the motherboard
can be initialized in one of two different configurations ("memory
maps"), care must be taken to include the correct one.
Root node
---------
Required properties in the root node:
- compatible value:
compatible = "arm,vexpress,<model>", "arm,vexpress";
where <model> is the full tile model name (as used in the tile's
Technical Reference Manual), eg.:
- for Coretile Express A5x2 (V2P-CA5s):
compatible = "arm,vexpress,v2p-ca5s", "arm,vexpress";
- for Coretile Express A9x4 (V2P-CA9):
compatible = "arm,vexpress,v2p-ca9", "arm,vexpress";
If a tile comes in several variants or can be used in more then one
configuration, the compatible value should be:
compatible = "arm,vexpress,<model>,<variant>", \
"arm,vexpress,<model>", "arm,vexpress";
eg:
- Coretile Express A15x2 (V2P-CA15) with Tech Chip 1:
compatible = "arm,vexpress,v2p-ca15,tc1", \
"arm,vexpress,v2p-ca15", "arm,vexpress";
- LogicTile Express 13MG (V2F-2XV6) running Cortex-A7 (3 cores) SMM:
compatible = "arm,vexpress,v2f-2xv6,ca7x3", \
"arm,vexpress,v2f-2xv6", "arm,vexpress";
Optional properties in the root node:
- tile model name (use name from the tile's Technical Reference
Manual, eg. "V2P-CA5s")
model = "<model>";
- tile's HBI number (unique ARM's board model ID, visible on the
PCB's silkscreen) in hexadecimal transcription:
arm,hbi = <0xhbi>
eg:
- for Coretile Express A5x2 (V2P-CA5s) HBI-0191:
arm,hbi = <0x191>;
- Coretile Express A9x4 (V2P-CA9) HBI-0225:
arm,hbi = <0x225>;
CPU nodes
---------
Top-level standard "cpus" node is required. It must contain a node
with device_type = "cpu" property for every available core, eg.:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a5";
reg = <0>;
};
};
Configuration infrastructure
----------------------------
The platform has an elaborated configuration system, consisting of
microcontrollers residing on the mother- and daughterboards known
as Motherboard/Daughterboard Configuration Controller (MCC and DCC).
The controllers are responsible for the platform initialization
(reset generation, flash programming, FPGA bitfiles loading etc.)
but also control clock generators, voltage regulators, gather
environmental data like temperature, power consumption etc. Even
the video output switch (FPGA) is controlled that way.
Nodes describing devices controlled by this infrastructure should
point at the bridge device node:
- bridge phandle:
arm,vexpress,config-bridge = <phandle>;
This property can be also defined in a parent node (eg. for a DCC)
and is effective for all children.
Platform topology
-----------------
As Versatile Express can be configured in number of physically
different setups, the device tree should describe platform topology.
Root node and main motherboard node must define the following
property, describing physical location of the children nodes:
- site number:
arm,vexpress,site = <number>;
where 0 means motherboard, 1 or 2 are daugtherboard sites,
0xf means "master" site (site containing main CPU tile)
- when daughterboards are stacked on one site, their position
in the stack be be described with:
arm,vexpress,position = <number>;
- when describing tiles consisting more than one DCC, its number
can be described with:
arm,vexpress,dcc = <number>;
Any of the numbers above defaults to zero if not defined in
the node or any of its parent.
Motherboard
-----------
The motherboard description file provides a single "motherboard" node
using 2 address cells corresponding to the Static Memory Bus used
between the motherboard and the tile. The first cell defines the Chip
Select (CS) line number, the second cell address offset within the CS.
All interrupt lines between the motherboard and the tile are active
high and are described using single cell.
Optional properties of the "motherboard" node:
- motherboard's memory map variant:
arm,v2m-memory-map = "<name>";
where name is one of:
- "rs1" - for RS1 map (i.a. peripherals on CS3); this map is also
referred to as "ARM Cortex-A Series memory map":
arm,v2m-memory-map = "rs1";
When this property is missing, the motherboard is using the original
memory map (also known as the "Legacy memory map", primarily used
with the original CoreTile Express A9x4) with peripherals on CS7.
Motherboard .dtsi files provide a set of labelled peripherals that
can be used to obtain required phandle in the tile's "aliases" node:
- UARTs, note that the numbers correspond to the physical connectors
on the motherboard's back panel:
v2m_serial0, v2m_serial1, v2m_serial2 and v2m_serial3
- I2C controllers:
v2m_i2c_dvi and v2m_i2c_pcie
- SP804 timers:
v2m_timer01 and v2m_timer23
The tile description should define a "smb" node, describing the
Static Memory Bus between the tile and motherboard. It must define
the following properties:
- "simple-bus" compatible value (to ensure creation of the children)
compatible = "simple-bus";
- mapping of the SMB CS/offset addresses into main address space:
#address-cells = <2>;
#size-cells = <1>;
ranges = <...>;
- interrupts mapping:
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 63>;
interrupt-map = <...>;
Example of a VE tile description (simplified)
---------------------------------------------
/dts-v1/;
/ {
model = "V2P-CA5s";
arm,hbi = <0x225>;
arm,vexpress,site = <0xf>;
compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress";
interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <1>;
chosen { };
aliases {
serial0 = &v2m_serial0;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a5";
reg = <0>;
};
};
gic: interrupt-controller@2c001000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
#address-cells = <0>;
interrupt-controller;
reg = <0x2c001000 0x1000>,
<0x2c000100 0x100>;
};
dcc {
compatible = "simple-bus";
arm,vexpress,config-bridge = <&v2m_sysreg>;
osc@0 {
compatible = "arm,vexpress-osc";
};
};
smb {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
/* CS0 is visible at 0x08000000 */
ranges = <0 0 0x08000000 0x04000000>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 63>;
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0 &gic 0 0 4>;
/include/ "vexpress-v2m-rs1.dtsi"
};
};

41
Bindings/arm/vic.txt Normal file
View File

@ -0,0 +1,41 @@
* ARM Vectored Interrupt Controller
One or more Vectored Interrupt Controllers (VIC's) can be connected in an ARM
system for interrupt routing. For multiple controllers they can either be
nested or have the outputs wire-OR'd together.
Required properties:
- compatible : should be one of
"arm,pl190-vic"
"arm,pl192-vic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : The number of cells to define the interrupts. Must be 1 as
the VIC has no configuration options for interrupt sources. The cell is a u32
and defines the interrupt number.
- reg : The register bank for the VIC.
Optional properties:
- interrupts : Interrupt source for parent controllers if the VIC is nested.
- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit
represents single interrupt source, starting from source 0 at LSb and ending
at source 31 at MSb. A bit that is set means that the source is wired and
clear means otherwise. If unspecified, defaults to all valid.
- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be
configured as wake up source for the system. Order of bits is the same as for
valid-mask property. A set bit means that this interrupt source can be
configured as a wake up source for the system. If unspecied, defaults to all
interrupt sources configurable as wake up sources.
Example:
vic0: interrupt-controller@60000 {
compatible = "arm,pl192-vic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x60000 0x1000>;
valid-mask = <0xffffff7f>;
valid-wakeup-mask = <0x0000ff7f>;
};

22
Bindings/arm/vt8500.txt Normal file
View File

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

View File

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

View File

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

View File

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

25
Bindings/arm/xen.txt Normal file
View File

@ -0,0 +1,25 @@
* Xen hypervisor device tree bindings
Xen ARM virtual platforms shall have a top-level "hypervisor" node with
the following properties:
- compatible:
compatible = "xen,xen-<version>", "xen,xen";
where <version> is the version of the Xen ABI of the platform.
- reg: specifies the base physical address and size of a region in
memory where the grant table should be mapped to, using an
HYPERVISOR_memory_op hypercall. The memory region is large enough to map
the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
- interrupts: the interrupt used by Xen to inject event notifications.
A GIC node is also required.
Example (assuming #address-cells = <2> and #size-cells = <2>):
hypervisor {
compatible = "xen,xen-4.3", "xen,xen";
reg = <0 0xb0000000 0 0x20000>;
interrupts = <1 15 0xf08>;
};

7
Bindings/arm/xilinx.txt Normal file
View File

@ -0,0 +1,7 @@
Xilinx Zynq EP107 Emulation Platform board
This board is an emulation platform for the Zynq product which is
based on an ARM Cortex A9 processor.
Required root node properties:
- compatible = "xlnx,zynq-ep107";

View File

@ -0,0 +1,20 @@
* 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, contains "snps,spear-ahci"
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>
Optional properties:
- dma-coherent : Present if dma operations are coherent
Example:
sata@ffe08000 {
compatible = "snps,spear-ahci";
reg = <0xffe08000 0x1000>;
interrupts = <115>;
};

View File

@ -0,0 +1,19 @@
Atmel AT91RM9200 CompactFlash
Required properties:
- compatible : "atmel,at91rm9200-cf".
- reg : should specify localbus address and size used.
- gpios : specifies the gpio pins to control the CF device. Detect
and reset gpio's are mandatory while irq and vcc gpio's are
optional and may be set to 0 if not present.
Example:
compact-flash@50000000 {
compatible = "atmel,at91rm9200-cf";
reg = <0x50000000 0x30000000>;
gpios = <&pioC 13 0 /* irq */
&pioC 15 0 /* detect */
0 /* vcc */
&pioC 5 0 /* reset */
>;
};

View File

@ -0,0 +1,30 @@
* Compact Flash
The Cavium Compact Flash device is connected to the Octeon Boot Bus,
and is thus a child of the Boot Bus device. It can read and write
industry standard compact flash devices.
Properties:
- compatible: "cavium,ebt3000-compact-flash";
Compatibility with many Cavium evaluation boards.
- reg: The base address of the 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
values are 8 and 16.
- cavium,true-ide: Optional, if present the CF connection is in True IDE mode.
- cavium,dma-engine-handle: Optional, a phandle for the DMA Engine connected
to this device.
Example:
compact-flash@5,0 {
compatible = "cavium,ebt3000-compact-flash";
reg = <5 0 0x10000>, <6 0 0x10000>;
cavium,bus-width = <16>;
cavium,true-ide;
cavium,dma-engine-handle = <&dma0>;
};

View File

@ -0,0 +1,14 @@
* Samsung SATA PHY Controller
SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
Each SATA PHY controller should have its own node.
Required properties:
- compatible : compatible list, contains "samsung,exynos5-sata-phy"
- reg : <registers mapping>
Example:
sata@ffe07000 {
compatible = "samsung,exynos5-sata-phy";
reg = <0xffe07000 0x1000>;
};

View File

@ -0,0 +1,17 @@
* Samsung 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, contains "samsung,exynos5-sata"
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>
- samsung,sata-freq : <frequency in MHz>
Example:
sata@ffe08000 {
compatible = "samsung,exynos5-sata";
reg = <0xffe08000 0x1000>;
interrupts = <115>;
};

29
Bindings/ata/fsl-sata.txt Normal file
View File

@ -0,0 +1,29 @@
* Freescale 8xxx/3.0 Gb/s SATA nodes
SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA port should have its own node.
Required properties:
- compatible : compatible list, contains 2 entries, first is
"fsl,CHIP-sata", where CHIP is the processor
(mpc8315, mpc8379, etc.) and the second is
"fsl,pq-sata"
- interrupts : <interrupt mapping for SATA IRQ>
- cell-index : controller index.
1 for controller @ 0x18000
2 for controller @ 0x19000
3 for controller @ 0x1a000
4 for controller @ 0x1b000
Optional properties:
- interrupt-parent : optional, if needed for interrupt mapping
- reg : <registers mapping>
Example:
sata@18000 {
compatible = "fsl,mpc8379-sata", "fsl,pq-sata";
reg = <0x18000 0x1000>;
cell-index = <1>;
interrupts = <2c 8>;
interrupt-parent = < &ipic >;
};

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