R0dn3yS/android_kernel_xiaomi_sm7250
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation: devicetree: Remove devicetree bindings from kernel

Browse Source 
Remove devicetree bindings from kernel.

Change-Id: I77029ee01a59f08bdbd8abe99e4ffb7e3c3ea390
Signed-off-by: Venkata Narendra Kumar Gutta <vnkgutta@codeaurora.org>
This commit is contained in:
Venkata Narendra Kumar Gutta 2019-04-24 12:32:59 -07:00
parent f3dd4aaeb3
commit 728aba9a9d
3403 changed files with 1 additions and 204593 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
Documentation/devicetree/bindings Symbolic link
View File

@ -0,0 +1 @@
../../arch/arm64/boot/dts/vendor/bindings

39
Documentation/devicetree/bindings/ABI.txt
View File

@ -1,39 +0,0 @@
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.

17
Documentation/devicetree/bindings/arc/archs-pct.txt
View File

@ -1,17 +0,0 @@
* ARC HS Performance Counters
The ARC HS can be configured with a pipeline performance monitor for counting
CPU and cache events like cache misses and hits. Like conventional PCT there
are 100+ hardware conditions dynamically mapped to up to 32 counters.
It also supports overflow interrupts.
Required properties:
- compatible : should contain
"snps,archs-pct"
Example:
pmu {
compatible = "snps,archs-pct";
};

7
Documentation/devicetree/bindings/arc/axs101.txt
View File

@ -1,7 +0,0 @@
Synopsys DesignWare ARC Software Development Platforms Device Tree Bindings
---------------------------------------------------------------------------
SDP Main Board with an AXC001 CPU Card hoisting ARC700 core in silicon
Required root node properties:
- compatible = "snps,axs101", "snps,arc-sdp";

8
Documentation/devicetree/bindings/arc/axs103.txt
View File

@ -1,8 +0,0 @@
Synopsys DesignWare ARC Software Development Platforms Device Tree Bindings
---------------------------------------------------------------------------
SDP Main Board with an AXC003 FPGA Card which can contain various flavours of
HS38x cores.
Required root node properties:
- compatible = "snps,axs103", "snps,arc-sdp";

7
Documentation/devicetree/bindings/arc/eznps.txt
View File

@ -1,7 +0,0 @@
EZchip NPS Network Processor Platforms Device Tree Bindings
---------------------------------------------------------------------------
Appliance main board with NPS400 ASIC.
Required root node properties:
- compatible = "ezchip,arc-nps";

7
Documentation/devicetree/bindings/arc/hsdk.txt
View File

@ -1,7 +0,0 @@
Synopsys DesignWare ARC HS Development Kit Device Tree Bindings
---------------------------------------------------------------------------
ARC HSDK Board with quad-core ARC HS38x4 in silicon.
Required root node properties:
- compatible = "snps,hsdk";

20
Documentation/devicetree/bindings/arc/pct.txt
View File

@ -1,20 +0,0 @@
* ARC Performance Counters
The ARC700 can be configured with a pipeline performance monitor for counting
CPU and cache events like cache misses and hits. Like conventional PCT there
are 100+ hardware conditions dynamically mapped to up to 32 counters
Note that:
* The ARC 700 PCT 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-pct"
Example:
pmu {
compatible = "snps,arc700-pct";
};

56
Documentation/devicetree/bindings/arm/actions.txt
View File

@ -1,56 +0,0 @@
Actions Semi platforms device tree bindings
-------------------------------------------
S500 SoC
========
Required root node properties:
- compatible : must contain "actions,s500"
Modules:
Root node property compatible must contain, depending on module:
- LeMaker Guitar: "lemaker,guitar"
Boards:
Root node property compatible must contain, depending on board:
- Allo.com Sparky: "allo,sparky"
- Cubietech CubieBoard6: "cubietech,cubieboard6"
- LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", "lemaker,guitar"
S700 SoC
========
Required root node properties:
- compatible : must contain "actions,s700"
Boards:
Root node property compatible must contain, depending on board:
- Cubietech CubieBoard7: "cubietech,cubieboard7"
S900 SoC
========
Required root node properties:
- compatible : must contain "actions,s900"
Boards:
Root node property compatible must contain, depending on board:
- uCRobotics Bubblegum-96: "ucrobotics,bubblegum-96"

88
Documentation/devicetree/bindings/arm/al,alpine.txt
View File

@ -1,88 +0,0 @@
Annapurna Labs Alpine Platform Device Tree Bindings
---------------------------------------------------------------
Boards in the Alpine family shall have the following properties:
* Required root node properties:
compatible: must contain "al,alpine"
* Example:
/ {
model = "Annapurna Labs Alpine Dev Board";
compatible = "al,alpine";
...
}
* CPU node:
The Alpine platform includes cortex-a15 cores.
enable-method: must be "al,alpine-smp" to allow smp [1]
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "al,alpine-smp";
cpu@0 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <0>;
};
cpu@1 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <1>;
};
cpu@2 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <2>;
};
cpu@3 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <3>;
};
};
* Alpine CPU resume registers
The CPU resume register are used to define required resume address after
reset.
Properties:
- compatible : Should contain "al,alpine-cpu-resume".
- reg : Offset and length of the register set for the device
Example:
cpu_resume {
compatible = "al,alpine-cpu-resume";
reg = <0xfbff5ed0 0x30>;
};
* Alpine System-Fabric Service Registers
The System-Fabric Service Registers allow various operation on CPU and
system fabric, like powering CPUs off.
Properties:
- compatible : Should contain "al,alpine-sysfabric-service" and "syscon".
- reg : Offset and length of the register set for the device
Example:
nb_service {
compatible = "al,alpine-sysfabric-service", "syscon";
reg = <0xfb070000 0x10000>;
};
[1] arm/cpu-enable-method/al,alpine-smp

14
Documentation/devicetree/bindings/arm/altera.txt
View File

@ -1,14 +0,0 @@
Altera's SoCFPGA platform device tree bindings
---------------------------------------------
Boards with Cyclone 5 SoC:
Required root node properties:
compatible = "altr,socfpga-cyclone5", "altr,socfpga";
Boards with Arria 5 SoC:
Required root node properties:
compatible = "altr,socfpga-arria5", "altr,socfpga";
Boards with Arria 10 SoC:
Required root node properties:
compatible = "altr,socfpga-arria10", "altr,socfpga";

11
Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt
View File

@ -1,11 +0,0 @@
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>;
};

12
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
View File

@ -1,12 +0,0 @@
Altera SOCFPGA SDRAM Controller
Required properties:
- compatible : Should contain "altr,sdr-ctl" and "syscon".
syscon is required by the Altera SOCFPGA SDRAM EDAC.
- reg : Should contain 1 register range (address and length)
Example:
sdr: sdr@ffc25000 {
compatible = "altr,sdr-ctl", "syscon";
reg = <0xffc25000 0x1000>;
};

15
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
View File

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

13
Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
View File

@ -1,13 +0,0 @@
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>;
};

20
Documentation/devicetree/bindings/arm/amlogic,scpi.txt
View File

@ -1,20 +0,0 @@
System Control and Power Interface (SCPI) Message Protocol
(in addition to the standard binding in [0])
----------------------------------------------------------
Required properties
- compatible : should be "amlogic,meson-gxbb-scpi"
AMLOGIC SRAM and Shared Memory for SCPI
------------------------------------
Required properties:
- compatible : should be "amlogic,meson-gxbb-sram"
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
memory on Amlogic GXBB SoC.
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt

131
Documentation/devicetree/bindings/arm/amlogic.txt
View File

@ -1,131 +0,0 @@
Amlogic MesonX device tree bindings
-------------------------------------------
Work in progress statement:
Device tree files and bindings applying to Amlogic SoCs and boards are
considered "unstable". Any Amlogic device tree binding may change at
any time. Be sure to use a device tree binary and a kernel image
generated from the same source tree.
Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a
stable binding/ABI.
---------------------------------------------------------------
Boards with the Amlogic Meson6 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson6"
Boards with the Amlogic Meson8 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8";
Boards with the Amlogic Meson8b SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8b";
Boards with the Amlogic Meson8m2 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8m2";
Boards with the Amlogic Meson GXBaby SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson-gxbb";
Boards with the Amlogic Meson GXL S905X SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s905x", "amlogic,meson-gxl";
Boards with the Amlogic Meson GXL S905D SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s905d", "amlogic,meson-gxl";
Boards with the Amlogic Meson GXL S805X SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s805x", "amlogic,meson-gxl";
Boards with the Amlogic Meson GXL S905W SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s905w", "amlogic,meson-gxl";
Boards with the Amlogic Meson GXM S912 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s912", "amlogic,meson-gxm";
Boards with the Amlogic Meson AXG A113D SoC shall have the following properties:
Required root node property:
compatible: "amlogic,a113d", "amlogic,meson-axg";
Board compatible values (alphabetically, grouped by SoC):
- "geniatech,atv1200" (Meson6)
- "minix,neo-x8" (Meson8)
- "hardkernel,odroid-c1" (Meson8b)
- "tronfy,mxq" (Meson8b)
- "tronsmart,mxiii-plus" (Meson8m2)
- "amlogic,p200" (Meson gxbb)
- "amlogic,p201" (Meson gxbb)
- "friendlyarm,nanopi-k2" (Meson gxbb)
- "hardkernel,odroid-c2" (Meson gxbb)
- "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
- "tronsmart,vega-s95-pro", "tronsmart,vega-s95" (Meson gxbb)
- "tronsmart,vega-s95-meta", "tronsmart,vega-s95" (Meson gxbb)
- "tronsmart,vega-s95-telos", "tronsmart,vega-s95" (Meson gxbb)
- "wetek,hub" (Meson gxbb)
- "wetek,play2" (Meson gxbb)
- "amlogic,p212" (Meson gxl s905x)
- "hwacom,amazetv" (Meson gxl s905x)
- "khadas,vim" (Meson gxl s905x)
- "libretech,cc" (Meson gxl s905x)
- "amlogic,p230" (Meson gxl s905d)
- "amlogic,p231" (Meson gxl s905d)
- "amlogic,p241" (Meson gxl s805x)
- "amlogic,p281" (Meson gxl s905w)
- "oranth,tx3-mini" (Meson gxl s905w)
- "amlogic,q200" (Meson gxm s912)
- "amlogic,q201" (Meson gxm s912)
- "khadas,vim2" (Meson gxm s912)
- "kingnovel,r-box-pro" (Meson gxm S912)
- "nexbox,a1" (Meson gxm s912)
- "tronsmart,vega-s96" (Meson gxm s912)
- "amlogic,s400" (Meson axg a113d)
Amlogic Meson Firmware registers Interface
------------------------------------------
The Meson SoCs have a register bank with status and data shared with the
secure firmware.
Required properties:
- compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon"
Properties should indentify components of this register interface :
Meson GX SoC Information
------------------------
A firmware register encodes the SoC type, package and revision information on
the Meson GX SoCs.
If present, the following property should be added :
Optional properties:
- amlogic,has-chip-id: If present, the interface gives the current SoC version.
Example
-------
ao-secure@140 {
compatible = "amlogic,meson-gx-ao-secure", "syscon";
reg = <0x0 0x140 0x0 0x140>;
amlogic,has-chip-id;
};

20
Documentation/devicetree/bindings/arm/amlogic/analog-top.txt
View File

@ -1,20 +0,0 @@
Amlogic Meson8 and Meson8b "analog top" registers:
--------------------------------------------------
The analog top registers contain information about the so-called
"metal revision" (which encodes the "minor version") of the SoC.
Required properties:
- reg: the register range of the analog top registers
- compatible: depending on the SoC this should be one of:
- "amlogic,meson8-analog-top"
- "amlogic,meson8b-analog-top"
along with "syscon"
Example:
analog_top: analog-top@81a8 {
compatible = "amlogic,meson8-analog-top", "syscon";
reg = <0x81a8 0x14>;
};

17
Documentation/devicetree/bindings/arm/amlogic/assist.txt
View File

@ -1,17 +0,0 @@
Amlogic Meson6/Meson8/Meson8b assist registers:
-----------------------------------------------
The assist registers contain basic information about the SoC,
for example the encoded SoC part number.
Required properties:
- reg: the register range of the assist registers
- compatible: should be "amlogic,meson-mx-assist" along with "syscon"
Example:
assist: assist@7c00 {
compatible = "amlogic,meson-mx-assist", "syscon";
reg = <0x7c00 0x200>;
};

17
Documentation/devicetree/bindings/arm/amlogic/bootrom.txt
View File

@ -1,17 +0,0 @@
Amlogic Meson6/Meson8/Meson8b bootrom:
--------------------------------------
The bootrom register area can be used to access SoC specific
information, such as the "misc version".
Required properties:
- reg: the register range of the bootrom registers
- compatible: should be "amlogic,meson-mx-bootrom" along with "syscon"
Example:
bootrom: bootrom@d9040000 {
compatible = "amlogic,meson-mx-bootrom", "syscon";
reg = <0xd9040000 0x10000>;
};

18
Documentation/devicetree/bindings/arm/amlogic/pmu.txt
View File

@ -1,18 +0,0 @@
Amlogic Meson8 and Meson8b power-management-unit:
-------------------------------------------------
The pmu is used to turn off and on different power domains of the SoCs
This includes the power to the CPU cores.
Required node properties:
- compatible value : depending on the SoC this should be one of:
"amlogic,meson8-pmu"
"amlogic,meson8b-pmu"
- reg : physical base address and the size of the registers window
Example:
pmu@c81000e4 {
compatible = "amlogic,meson8b-pmu", "syscon";
reg = <0xc81000e0 0x18>;
};

32
Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt
View File

@ -1,32 +0,0 @@
Amlogic Meson8 and Meson8b SRAM for smp bringup:
------------------------------------------------
Amlogic's SMP-capable SoCs use part of the sram for the bringup of the cores.
Once the core gets powered up it executes the code that is residing at a
specific location.
Therefore a reserved section sub-node has to be added to the mmio-sram
declaration.
Required sub-node properties:
- compatible : depending on the SoC this should be one of:
"amlogic,meson8-smp-sram"
"amlogic,meson8b-smp-sram"
The rest of the properties should follow the generic mmio-sram discription
found in ../../misc/sram.txt
Example:
sram: sram@d9000000 {
compatible = "mmio-sram";
reg = <0xd9000000 0x20000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0xd9000000 0x20000>;
smp-sram@1ff80 {
compatible = "amlogic,meson8b-smp-sram";
reg = <0x1ff80 0x8>;
};
};

17
Documentation/devicetree/bindings/arm/apm/scu.txt
View File

@ -1,17 +0,0 @@
APM X-GENE SoC series SCU Registers
This system clock unit contain various register that control block resets,
clock enable/disables, clock divisors and other deepsleep registers.
Properties:
- compatible : should contain two values. First value must be:
- "apm,xgene-scu"
second value must be always "syscon".
- reg : offset and length of the register set.
Example :
scu: system-clk-controller@17000000 {
compatible = "apm,xgene-scu","syscon";
reg = <0x0 0x17000000 0x0 0x400>;
};

179
Documentation/devicetree/bindings/arm/arm,scmi.txt
View File

@ -1,179 +0,0 @@
System Control and Management Interface (SCMI) Message Protocol
----------------------------------------------------------
The SCMI is intended to allow agents such as OSPM to manage various functions
that are provided by the hardware platform it is running on, including power
and performance functions.
This binding is intended to define the interface the firmware implementing
the SCMI as described in ARM document number ARM DUI 0922B ("ARM System Control
and Management Interface Platform Design Document")[0] provide for OSPM in
the device tree.
Required properties:
The scmi node with the following properties shall be under the /firmware/ node.
- compatible : shall be "arm,scmi"
- mboxes: List of phandle and mailbox channel specifiers. It should contain
exactly one or two mailboxes, one for transmitting messages("tx")
and another optional for receiving the notifications("rx") if
supported.
- shmem : List of phandle pointing to the shared memory(SHM) area as per
generic mailbox client binding.
- #address-cells : should be '1' if the device has sub-nodes, maps to
protocol identifier for a given sub-node.
- #size-cells : should be '0' as 'reg' property doesn't have any size
associated with it.
Optional properties:
- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
about the generic mailbox controller and client driver bindings.
The mailbox is the only permitted method of calling the SCMI firmware.
Mailbox doorbell is used as a mechanism to alert the presence of a
messages and/or notification.
Each protocol supported shall have a sub-node with corresponding compatible
as described in the following sections. If the platform supports dedicated
communication channel for a particular protocol, the 3 properties namely:
mboxes, mbox-names and shmem shall be present in the sub-node corresponding
to that protocol.
Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol
------------------------------------------------------------
This binding uses the common clock binding[1].
Required properties:
- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands.
Power domain bindings for the power domains based on SCMI Message Protocol
------------------------------------------------------------
This binding for the SCMI power domain providers uses the generic power
domain binding[2].
Required properties:
- #power-domain-cells : Should be 1. Contains the device or the power
domain ID value used by SCMI commands.
Sensor bindings for the sensors based on SCMI Message Protocol
--------------------------------------------------------------
SCMI provides an API to access the various sensors on the SoC.
Required properties:
- #thermal-sensor-cells: should be set to 1. This property follows the
thermal device tree bindings[3].
Valid cell values are raw identifiers (Sensor ID)
as used by the firmware. Refer to platform details
for your implementation for the IDs to use.
SRAM and Shared Memory for SCMI
-------------------------------
A small area of SRAM is reserved for SCMI communication between application
processors and SCP.
The properties should follow the generic mmio-sram description found in [4]
Each sub-node represents the reserved area for SCMI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based
shared memory
[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/power/power_domain.txt
[3] Documentation/devicetree/bindings/thermal/thermal.txt
[4] Documentation/devicetree/bindings/sram/sram.txt
Example:
sram@50000000 {
compatible = "mmio-sram";
reg = <0x0 0x50000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x10000>;
cpu_scp_lpri: scp-shmem@0 {
compatible = "arm,scmi-shmem";
reg = <0x0 0x200>;
};
cpu_scp_hpri: scp-shmem@200 {
compatible = "arm,scmi-shmem";
reg = <0x200 0x200>;
};
};
mailbox@40000000 {
....
#mbox-cells = <1>;
reg = <0x0 0x40000000 0x0 0x10000>;
};
firmware {
...
scmi {
compatible = "arm,scmi";
mboxes = <&mailbox 0 &mailbox 1>;
mbox-names = "tx", "rx";
shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
#address-cells = <1>;
#size-cells = <0>;
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
scmi_dvfs: protocol@13 {
reg = <0x13>;
#clock-cells = <1>;
};
scmi_clk: protocol@14 {
reg = <0x14>;
#clock-cells = <1>;
};
scmi_sensors0: protocol@15 {
reg = <0x15>;
#thermal-sensor-cells = <1>;
};
};
};
cpu@0 {
...
reg = <0 0>;
clocks = <&scmi_dvfs 0>;
};
hdlcd@7ff60000 {
...
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scmi_clk 4>;
power-domains = <&scmi_devpd 1>;
};
thermal-zones {
soc_thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
/* sensor ID */
thermal-sensors = <&scmi_sensors0 3>;
...
};
};

219
Documentation/devicetree/bindings/arm/arm,scpi.txt
View File

@ -1,219 +0,0 @@
System Control and Power Interface (SCPI) Message Protocol
----------------------------------------------------------
Firmware implementing the SCPI described in ARM document number ARM DUI 0922B
("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used
by Linux to initiate various system control and power operations.
Required properties:
- compatible : should be
* "arm,scpi" : For implementations complying to SCPI v1.0 or above
* "arm,scpi-pre-1.0" : For implementations complying to all
unversioned releases prior to SCPI v1.0
- mboxes: List of phandle and mailbox channel specifiers
All the channels reserved by remote SCP firmware for use by
SCPI message protocol should be specified in any order
- shmem : List of phandle pointing to the shared memory(SHM) area between the
processors using these mailboxes for IPC, one for each mailbox
SHM can be any memory reserved for the purpose of this communication
between the processors.
See Documentation/devicetree/bindings/mailbox/mailbox.txt
for more details about the generic mailbox controller and
client driver bindings.
Clock bindings for the clocks based on SCPI Message Protocol
------------------------------------------------------------
This binding uses the common clock binding[1].
Container Node
==============
Required properties:
- compatible : should be "arm,scpi-clocks"
All the clocks provided by SCP firmware via SCPI message
protocol much be listed as sub-nodes under this node.
Sub-nodes
=========
Required properties:
- compatible : shall include one of the following
"arm,scpi-dvfs-clocks" - all the clocks that are variable and index based.
These clocks don't provide an entire range of values between the
limits but only discrete points within the range. The firmware
provides the mapping for each such operating frequency and the
index associated with it. The firmware also manages the
voltage scaling appropriately with the clock scaling.
"arm,scpi-variable-clocks" - all the clocks that are variable and provide full
range within the specified range. The firmware provides the
range of values within a specified range.
Other required properties for all clocks(all from common clock binding):
- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands.
- clock-output-names : shall be the corresponding names of the outputs.
- clock-indices: The identifying number for the clocks(i.e.clock_id) in the
node. It can be non linear and hence provide the mapping of identifiers
into the clock-output-names array.
SRAM and Shared Memory for SCPI
-------------------------------
A small area of SRAM is reserved for SCPI communication between application
processors and SCP.
The properties should follow the generic mmio-sram description found in [3]
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,scp-shmem" for Non-secure SRAM based
shared memory
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
Required properties:
- compatible : should be "arm,scpi-sensors".
- #thermal-sensor-cells: should be set to 1. This property follows the
thermal device tree bindings[2].
Valid cell values are raw identifiers (Sensor ID)
as used by the firmware. Refer to platform details
for your implementation for the IDs to use.
Power domain bindings for the power domains based on SCPI Message Protocol
------------------------------------------------------------
This binding uses the generic power domain binding[4].
PM domain providers
===================
Required properties:
- #power-domain-cells : Should be 1. Contains the device or the power
domain ID value used by SCPI commands.
- num-domains: Total number of power domains provided by SCPI. This is
needed as the SCPI message protocol lacks a mechanism to
query this information at runtime.
PM domain consumers
===================
Required properties:
- power-domains : A phandle and PM domain specifier as defined by bindings of
the power controller specified by phandle.
[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/thermal/thermal.txt
[3] Documentation/devicetree/bindings/sram/sram.txt
[4] Documentation/devicetree/bindings/power/power_domain.txt
Example:
sram: sram@50000000 {
compatible = "arm,juno-sram-ns", "mmio-sram";
reg = <0x0 0x50000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x10000>;
cpu_scp_lpri: scp-shmem@0 {
compatible = "arm,juno-scp-shmem";
reg = <0x0 0x200>;
};
cpu_scp_hpri: scp-shmem@200 {
compatible = "arm,juno-scp-shmem";
reg = <0x200 0x200>;
};
};
mailbox: mailbox0@40000000 {
....
#mbox-cells = <1>;
};
scpi_protocol: scpi@2e000000 {
compatible = "arm,scpi";
mboxes = <&mailbox 0 &mailbox 1>;
shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
clocks {
compatible = "arm,scpi-clocks";
scpi_dvfs: scpi_clocks@0 {
compatible = "arm,scpi-dvfs-clocks";
#clock-cells = <1>;
clock-indices = <0>, <1>, <2>;
clock-output-names = "atlclk", "aplclk","gpuclk";
};
scpi_clk: scpi_clocks@3 {
compatible = "arm,scpi-variable-clocks";
#clock-cells = <1>;
clock-indices = <3>, <4>;
clock-output-names = "pxlclk0", "pxlclk1";
};
};
scpi_sensors0: sensors {
compatible = "arm,scpi-sensors";
#thermal-sensor-cells = <1>;
};
scpi_devpd: scpi-power-domains {
compatible = "arm,scpi-power-domains";
num-domains = <2>;
#power-domain-cells = <1>;
};
};
cpu@0 {
...
reg = <0 0>;
clocks = <&scpi_dvfs 0>;
};
hdlcd@7ff60000 {
...
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scpi_clk 4>;
power-domains = <&scpi_devpd 1>;
};
thermal-zones {
soc_thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
/* sensor ID */
thermal-sensors = <&scpi_sensors0 3>;
...
};
};
In the above example, the #clock-cells is set to 1 as required.
scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0,
1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0
and pxlclk1 with 3 and 4 as clock-indices.
The first consumer in the example is cpu@0 and it has '0' as the clock
specifier which points to the first entry in the output clocks of
scpi_dvfs i.e. "atlclk".
Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input
clock. '4' in the clock specifier here points to the second entry
in the output clocks of scpi_clocks i.e. "pxlclk1"
The thermal-sensors property in the soc_thermal node uses the
temperature sensor provided by SCP firmware to setup a thermal
zone. The ID "3" is the sensor identifier for the temperature sensor
as used by the firmware.
The num-domains property in scpi-power-domains domain specifies that
SCPI provides 2 power domains. The hdlcd node uses the power domain with
domain ID 1.

237
Documentation/devicetree/bindings/arm/arm-boards
View File

@ -1,237 +0,0 @@
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 pointing 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>;
Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
Optional nodes:
- arm,versatile-ib2-syscon : if the Versatile has an IB2 interface
board mounted, this has a separate system controller that is
defined in this node.
Required properties:
compatible = "arm,versatile-ib2-syscon", "syscon"
ARM RealView Boards
-------------------
The RealView boards cover tailored evaluation boards that are used to explore
the ARM11 and Cortex A-8 and Cortex A-9 processors.
Required properties (in root node):
/* RealView Emulation Baseboard */
compatible = "arm,realview-eb";
/* RealView Platform Baseboard for ARM1176JZF-S */
compatible = "arm,realview-pb1176";
/* RealView Platform Baseboard for ARM11 MPCore */
compatible = "arm,realview-pb11mp";
/* RealView Platform Baseboard for Cortex A-8 */
compatible = "arm,realview-pba8";
/* RealView Platform Baseboard Explore for Cortex A-9 */
compatible = "arm,realview-pbx";
Required nodes:
- soc: some node of the RealView platforms must be the SoC
node that contain the SoC-specific devices, withe the compatible
string set to one of these tuples:
"arm,realview-eb-soc", "simple-bus"
"arm,realview-pb1176-soc", "simple-bus"
"arm,realview-pb11mp-soc", "simple-bus"
"arm,realview-pba8-soc", "simple-bus"
"arm,realview-pbx-soc", "simple-bus"
- syscon: some subnode of the RealView SoC node must be a
system controller node pointing to the control registers,
with the compatible string set to one of these:
"arm,realview-eb11mp-revb-syscon", "arm,realview-eb-syscon", "syscon"
"arm,realview-eb11mp-revc-syscon", "arm,realview-eb-syscon", "syscon"
"arm,realview-eb-syscon", "syscon"
"arm,realview-pb1176-syscon", "syscon"
"arm,realview-pb11mp-syscon", "syscon"
"arm,realview-pba8-syscon", "syscon"
"arm,realview-pbx-syscon", "syscon"
Required properties for the system controller:
- regs: the location and size of the system controller registers,
one range of 0x1000 bytes.
Example:
/dts-v1/;
#include <dt-bindings/interrupt-controller/irq.h>
/ {
model = "ARM RealView PB1176 with device tree";
compatible = "arm,realview-pb1176";
#address-cells = <1>;
#size-cells = <1>;
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "arm,realview-pb1176-soc", "simple-bus";
ranges;
syscon: syscon@10000000 {
compatible = "arm,realview-syscon", "syscon";
reg = <0x10000000 0x1000>;
};
};
};
ARM Versatile Express Boards
-----------------------------
For details on the device tree bindings for ARM Versatile Express boards
please consult the vexpress.txt file in the same directory as this file.
ARM Juno Boards
----------------
The Juno boards are targeting development for AArch64 systems. The first
iteration, Juno r0, is a vehicle for evaluating big.LITTLE on AArch64,
with the second iteration, Juno r1, mainly aimed at development of PCIe
based systems. Juno r1 also has support for AXI masters placed on the TLX
connectors to join the coherency domain.
Juno boards are described in a similar way to ARM Versatile Express boards,
with the motherboard part of the hardware being described in a separate file
to highlight the fact that is part of the support infrastructure for the SoC.
Juno device tree bindings also share the Versatile Express bindings as
described under the RS1 memory mapping.
Required properties (in root node):
compatible = "arm,juno"; /* For Juno r0 board */
compatible = "arm,juno-r1"; /* For Juno r1 board */
compatible = "arm,juno-r2"; /* For Juno r2 board */
Required nodes:
The description for the board must include:
- a "psci" node describing the boot method used for the secondary CPUs.
A detailed description of the bindings used for "psci" nodes is present
in the psci.txt file.
- a "cpus" node describing the available cores and their associated
"enable-method"s. For more details see cpus.txt file.
Example:
/dts-v1/;
/ {
model = "ARM Juno development board (r0)";
compatible = "arm,juno", "arm,vexpress";
interrupt-parent = <&gic>;
#address-cells = <2>;
#size-cells = <2>;
cpus {
#address-cells = <2>;
#size-cells = <0>;
A57_0: cpu@0 {
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x0 0x0>;
device_type = "cpu";
enable-method = "psci";
};
.....
A53_0: cpu@100 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x100>;
device_type = "cpu";
enable-method = "psci";
};
.....
};
};

27
Documentation/devicetree/bindings/arm/arm-dsu-pmu.txt
View File

@ -1,27 +0,0 @@
* ARM DynamIQ Shared Unit (DSU) Performance Monitor Unit (PMU)
ARM DyanmIQ Shared Unit (DSU) integrates one or more CPU cores
with a shared L3 memory system, control logic and external interfaces to
form a multicore cluster. The PMU enables to gather various statistics on
the operations of the DSU. The PMU provides independent 32bit counters that
can count any of the supported events, along with a 64bit cycle counter.
The PMU is accessed via CPU system registers and has no MMIO component.
** DSU PMU required properties:
- compatible : should be one of :
"arm,dsu-pmu"
- interrupts : Exactly 1 SPI must be listed.
- cpus : List of phandles for the CPUs connected to this DSU instance.
** Example:
dsu-pmu-0 {
compatible = "arm,dsu-pmu";
interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>;
cpus = <&cpu_0>, <&cpu_1>;
};

6
Documentation/devicetree/bindings/arm/armadeus.txt
View File

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

242
Documentation/devicetree/bindings/arm/atmel-at91.txt
View File

@ -1,242 +0,0 @@
Atmel AT91 device tree bindings.
================================
Boards with a SoC of the Atmel AT91 or SMART family shall have the following
properties:
Required root node properties:
compatible: must be one of:
* "atmel,at91rm9200"
* "atmel,at91sam9" for SoCs using an ARM926EJ-S core, shall be extended with
the specific SoC family or compatible:
o "atmel,at91sam9260"
o "atmel,at91sam9261"
o "atmel,at91sam9263"
o "atmel,at91sam9x5" for the 5 series, shall be extended with the specific
SoC compatible:
- "atmel,at91sam9g15"
- "atmel,at91sam9g25"
- "atmel,at91sam9g35"
- "atmel,at91sam9x25"
- "atmel,at91sam9x35"
o "atmel,at91sam9g20"
o "atmel,at91sam9g45"
o "atmel,at91sam9n12"
o "atmel,at91sam9rl"
o "atmel,at91sam9xe"
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
SoC family:
o "atmel,sama5d2" shall be extended with the specific SoC compatible:
- "atmel,sama5d27"
o "atmel,sama5d3" shall be extended with the specific SoC compatible:
- "atmel,sama5d31"
- "atmel,sama5d33"
- "atmel,sama5d34"
- "atmel,sama5d35"
- "atmel,sama5d36"
o "atmel,sama5d4" shall be extended with the specific SoC compatible:
- "atmel,sama5d41"
- "atmel,sama5d42"
- "atmel,sama5d43"
- "atmel,sama5d44"
* "atmel,samv7" for MCUs using a Cortex-M7, shall be extended with the specific
SoC family:
o "atmel,sams70" shall be extended with the specific MCU compatible:
- "atmel,sams70j19"
- "atmel,sams70j20"
- "atmel,sams70j21"
- "atmel,sams70n19"
- "atmel,sams70n20"
- "atmel,sams70n21"
- "atmel,sams70q19"
- "atmel,sams70q20"
- "atmel,sams70q21"
o "atmel,samv70" shall be extended with the specific MCU compatible:
- "atmel,samv70j19"
- "atmel,samv70j20"
- "atmel,samv70n19"
- "atmel,samv70n20"
- "atmel,samv70q19"
- "atmel,samv70q20"
o "atmel,samv71" shall be extended with the specific MCU compatible:
- "atmel,samv71j19"
- "atmel,samv71j20"
- "atmel,samv71j21"
- "atmel,samv71n19"
- "atmel,samv71n20"
- "atmel,samv71n21"
- "atmel,samv71q19"
- "atmel,samv71q20"
- "atmel,samv71q21"
Chipid required properties:
- compatible: Should be "atmel,sama5d2-chipid"
- reg : Should contain registers location and length
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", "syscon", "simple-mfd"
- 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.
- clocks: phandle to input clock.
Its subnodes can be:
- watchdog: compatible should be "atmel,at91rm9200-wdt"
RSTC Reset Controller required properties:
- compatible: Should be "atmel,<chip>-rstc".
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"
- reg: Should contain registers location and length
- clocks: phandle to input clock.
Example:
rstc@fffffd00 {
compatible = "atmel,at91sam9260-rstc";
reg = <0xfffffd00 0x10>;
clocks = <&clk32k>;
};
RAMC SDRAM/DDR Controller required properties:
- compatible: Should be "atmel,at91rm9200-sdramc", "syscon"
"atmel,at91sam9260-sdramc",
"atmel,at91sam9g45-ddramc",
"atmel,sama5d3-ddramc",
- reg: Should contain registers location and length
Examples:
ramc0: ramc@ffffe800 {
compatible = "atmel,at91sam9g45-ddramc";
reg = <0xffffe800 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
- clocks: phandle to input clock.
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:
shdwc@fffffd10 {
compatible = "atmel,at91sam9260-shdwc";
reg = <0xfffffd10 0x10>;
clocks = <&clk32k>;
};
SHDWC SAMA5D2-Compatible Shutdown Controller
1) shdwc node
required properties:
- compatible: should be "atmel,sama5d2-shdwc".
- reg: should contain registers location and length
- clocks: phandle to input clock.
- #address-cells: should be one. The cell is the wake-up input index.
- #size-cells: should be zero.
optional properties:
- debounce-delay-us: minimum wake-up inputs debouncer period in
microseconds. It's usually a board-related property.
- atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up.
The node contains child nodes for each wake-up input that the platform uses.
2) input nodes
Wake-up input nodes are usually described in the "board" part of the Device
Tree. Note also that input 0 is linked to the wake-up pin and is frequently
used.
Required properties:
- reg: should contain the wake-up input index [0 - 15].
Optional properties:
- atmel,wakeup-active-high: boolean, the corresponding wake-up input described
by the child, forces the wake-up of the core power supply on a high level.
The default is to be active low.
Example:
On the SoC side:
shdwc@f8048010 {
compatible = "atmel,sama5d2-shdwc";
reg = <0xf8048010 0x10>;
clocks = <&clk32k>;
#address-cells = <1>;
#size-cells = <0>;
atmel,wakeup-rtc-timer;
};
On the board side:
shdwc@f8048010 {
debounce-delay-us = <976>;
input@0 {
reg = <0>;
};
input@1 {
reg = <1>;
atmel,wakeup-active-high;
};
};
Special Function Registers (SFR)
Special Function Registers (SFR) manage specific aspects of the integrated
memory, bridge implementations, processor and other functionality not controlled
elsewhere.
required properties:
- compatible: Should be "atmel,<chip>-sfr", "syscon" or
"atmel,<chip>-sfrbu", "syscon"
<chip> can be "sama5d3", "sama5d4" or "sama5d2".
- reg: Should contain registers location and length
sfr@f0038000 {
compatible = "atmel,sama5d3-sfr", "syscon";
reg = <0xf0038000 0x60>;
};
Security Module (SECUMOD)
The Security Module macrocell provides all necessary secure functions to avoid
voltage, temperature, frequency and mechanical attacks on the chip. It also
embeds secure memories that can be scrambled
required properties:
- compatible: Should be "atmel,<chip>-secumod", "syscon".
<chip> can be "sama5d2".
- reg: Should contain registers location and length
secumod@fc040000 {
compatible = "atmel,sama5d2-secumod", "syscon";
reg = <0xfc040000 0x100>;
};

28
Documentation/devicetree/bindings/arm/axentia.txt
View File

@ -1,28 +0,0 @@
Device tree bindings for Axentia ARM devices
============================================
Linea CPU module
----------------
Required root node properties:
compatible = "axentia,linea",
"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
and following the rules from atmel-at91.txt for a sama5d31 SoC.
Nattis v2 board with Natte v2 power board
-----------------------------------------
Required root node properties:
compatible = "axentia,nattis-2", "axentia,natte-2", "axentia,linea",
"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
and following the rules from above for the axentia,linea CPU module.
TSE-850 v3 board
----------------
Required root node properties:
compatible = "axentia,tse850v3", "axentia,linea",
"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
and following the rules from above for the axentia,linea CPU module.

29
Documentation/devicetree/bindings/arm/axis.txt
View File

@ -1,29 +0,0 @@
Axis Communications AB
ARTPEC series SoC Device Tree Bindings
ARTPEC-6 ARM SoC
================
Required root node properties:
- compatible = "axis,artpec6";
ARTPEC-6 System Controller
--------------------------
The ARTPEC-6 has a system controller with mixed functions controlling DMA, PCIe
and resets.
Required properties:
- compatible: "axis,artpec6-syscon", "syscon"
- reg: Address and length of the register bank.
Example:
syscon {
compatible = "axis,artpec6-syscon", "syscon";
reg = <0xf8000000 0x48>;
};
ARTPEC-6 Development board:
---------------------------
Required root node properties:
- compatible = "axis,artpec6-dev-board", "axis,artpec6";

12
Documentation/devicetree/bindings/arm/axxia.txt
View File

@ -1,12 +0,0 @@
Axxia AXM55xx device tree bindings
Boards using the AXM55xx SoC need to have the following properties:
Required root node property:
- compatible = "lsi,axm5516"
Boards:
LSI AXM5516 Validation board (Amarillo)
compatible = "lsi,axm5516-amarillo", "lsi,axm5516"

36
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method.txt
View File

@ -1,36 +0,0 @@
Broadcom Kona Family CPU Enable Method
--------------------------------------
This binding defines the enable method used for starting secondary
CPUs in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664
The enable method is specified by defining the following required
properties in the "cpu" device tree node:
- enable-method = "brcm,bcm11351-cpu-method";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
enable-method = "brcm,bcm11351-cpu-method";
secondary-boot-reg = <0x3500417c>;
};
};

10
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.txt
View File

@ -1,10 +0,0 @@
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";

15
Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.txt
View File

@ -1,15 +0,0 @@
Broadcom BCM21664 device tree bindings
--------------------------------------
This document describes the device tree bindings for boards with the BCM21664
SoC.
Required root node property:
- compatible: brcm,bcm21664
Example:
/ {
model = "BCM21664 SoC";
compatible = "brcm,bcm21664";
[...]
}

36
Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550-cpu-method.txt
View File

@ -1,36 +0,0 @@
Broadcom Kona Family CPU Enable Method
--------------------------------------
This binding defines the enable method used for starting secondary
CPUs in the following Broadcom SoCs:
BCM23550
The enable method is specified by defining the following required
properties in the "cpu" device tree node:
- enable-method = "brcm,bcm23550";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
enable-method = "brcm,bcm23550";
secondary-boot-reg = <0x3500417c>;
};
};

15
Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.txt
View File

@ -1,15 +0,0 @@
Broadcom BCM23550 device tree bindings
--------------------------------------
This document describes the device tree bindings for boards with the BCM23550
SoC.
Required root node property:
- compatible: brcm,bcm23550
Example:
/ {
model = "BCM23550 SoC";
compatible = "brcm,bcm23550";
[...]
}

55
Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt
View File

@ -1,55 +0,0 @@
Broadcom BCM2835 device tree bindings
-------------------------------------------
Raspberry Pi Model A
Required root node properties:
compatible = "raspberrypi,model-a", "brcm,bcm2835";
Raspberry Pi Model A+
Required root node properties:
compatible = "raspberrypi,model-a-plus", "brcm,bcm2835";
Raspberry Pi Model B
Required root node properties:
compatible = "raspberrypi,model-b", "brcm,bcm2835";
Raspberry Pi Model B (no P5)
early model B with I2C0 rather than I2C1 routed to the expansion header
Required root node properties:
compatible = "raspberrypi,model-b-i2c0", "brcm,bcm2835";
Raspberry Pi Model B rev2
Required root node properties:
compatible = "raspberrypi,model-b-rev2", "brcm,bcm2835";
Raspberry Pi Model B+
Required root node properties:
compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
Raspberry Pi 2 Model B
Required root node properties:
compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
Raspberry Pi 3 Model B
Required root node properties:
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
Raspberry Pi 3 Model B+
Required root node properties:
compatible = "raspberrypi,3-model-b-plus", "brcm,bcm2837";
Raspberry Pi Compute Module
Required root node properties:
compatible = "raspberrypi,compute-module", "brcm,bcm2835";
Raspberry Pi Zero
Required root node properties:
compatible = "raspberrypi,model-zero", "brcm,bcm2835";
Raspberry Pi Zero W
Required root node properties:
compatible = "raspberrypi,model-zero-w", "brcm,bcm2835";
Generic BCM2835 board
Required root node properties:
compatible = "brcm,bcm2835";

15
Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
View File

@ -1,15 +0,0 @@
Broadcom BCM4708 device tree bindings
-------------------------------------------
Boards with the BCM4708 SoC shall have the following properties:
Required root node property:
bcm4708
compatible = "brcm,bcm4708";
bcm4709
compatible = "brcm,bcm4709";
bcm53012
compatible = "brcm,bcm53012";

85
Documentation/devicetree/bindings/arm/bcm/brcm,bcm63138.txt
View File

@ -1,85 +0,0 @@
Broadcom BCM63138 DSL System-on-a-Chip device tree bindings
-----------------------------------------------------------
Boards compatible with the BCM63138 DSL System-on-a-Chip should have the
following properties:
Required root node property:
compatible: should be "brcm,bcm63138"
An optional Boot lookup table Device Tree node is required for secondary CPU
initialization as well as a 'resets' phandle to the correct PMB controller as
defined in reset/brcm,bcm63138-pmb.txt for this secondary CPU, and an
'enable-method' property.
Required properties for the Boot lookup table node:
- compatible: should be "brcm,bcm63138-bootlut"
- reg: register base address and length for the Boot Lookup table
Optional properties for the primary CPU node:
- enable-method: should be "brcm,bcm63138"
Optional properties for the secondary CPU node:
- enable-method: should be "brcm,bcm63138"
- resets: phandle to the relevant PMB controller, one integer indicating the internal
bus number, and a second integer indicating the address of the CPU in the PMB
internal bus number.
Example:
cpus {
cpu@0 {
compatible = "arm,cotex-a9";
reg = <0>;
...
enable-method = "brcm,bcm63138";
};
cpu@1 {
compatible = "arm,cortex-a9";
reg = <1>;
...
enable-method = "brcm,bcm63138";
resets = <&pmb0 4 1>;
};
};
bootlut: bootlut@8000 {
compatible = "brcm,bcm63138-bootlut";
reg = <0x8000 0x50>;
};
=======
reboot
------
Two nodes are required for software reboot: a timer node and a syscon-reboot node.
Timer node:
- compatible: Must be "brcm,bcm6328-timer", "syscon"
- reg: Register base address and length
Syscon reboot node:
See Documentation/devicetree/bindings/power/reset/syscon-reboot.txt for the
detailed list of properties, the two values defined below are specific to the
BCM6328-style timer:
- offset: Should be 0x34 to denote the offset of the TIMER_WD_TIMER_RESET register
from the beginning of the TIMER block
- mask: Should be 1 for the SoftRst bit.
Example:
timer: timer@80 {
compatible = "brcm,bcm6328-timer", "syscon";
reg = <0x80 0x3c>;
};
reboot {
compatible = "syscon-reboot";
regmap = <&timer>;
offset = <0x34>;
mask = <0x1>;
};

265
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
View File

@ -1,265 +0,0 @@
ARM Broadcom STB platforms Device Tree Bindings
-----------------------------------------------
Boards with Broadcom Brahma15 ARM-based BCMxxxx (generally BCM7xxx variants)
SoC shall have the following DT organization:
Required root node properties:
- compatible: "brcm,bcm<chip_id>", "brcm,brcmstb"
example:
/ {
#address-cells = <2>;
#size-cells = <2>;
model = "Broadcom STB (bcm7445)";
compatible = "brcm,bcm7445", "brcm,brcmstb";
Further, syscon nodes that map platform-specific registers used for general
system control is required:
- compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-cpu-biu-ctrl",
"brcm,brcmstb-cpu-biu-ctrl",
"syscon"
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
cpu-biu-ctrl node
-------------------
SoCs with Broadcom Brahma15 ARM-based and Brahma53 ARM64-based CPUs have a
specific Bus Interface Unit (BIU) block which controls and interfaces the CPU
complex to the different Memory Controller Ports (MCP), one per memory
controller (MEMC). This BIU block offers a feature called Write Pairing which
consists in collapsing two adjacent cache lines into a single (bursted) write
transaction towards the memory controller (MEMC) to maximize write bandwidth.
Required properties:
- compatible: must be "brcm,bcm7445-cpu-biu-ctrl", "brcm,brcmstb-cpu-biu-ctrl", "syscon"
Optional properties:
- brcm,write-pairing:
Boolean property, which when present indicates that the chip
supports write-pairing.
example:
rdb {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
ranges = <0 0x00 0xf0000000 0x1000000>;
sun_top_ctrl: syscon@404000 {
compatible = "brcm,bcm7445-sun-top-ctrl", "syscon";
reg = <0x404000 0x51c>;
};
hif_cpubiuctrl: syscon@3e2400 {
compatible = "brcm,bcm7445-cpu-biu-ctrl", "brcm,brcmstb-cpu-biu-ctrl", "syscon";
reg = <0x3e2400 0x5b4>;
brcm,write-pairing;
};
hif_continuation: syscon@452000 {
compatible = "brcm,bcm7445-hif-continuation", "syscon";
reg = <0x452000 0x100>;
};
};
Nodes that allow for support of SMP initialization and reboot are required:
smpboot
-------
Required properties:
- compatible
The string "brcm,brcmstb-smpboot".
- syscon-cpu
A phandle / integer array property which lets the BSP know the location
of certain CPU power-on registers.
The layout of the property is as follows:
o a phandle to the "hif_cpubiuctrl" syscon node
o offset to the base CPU power zone register
o offset to the base CPU reset register
- syscon-cont
A phandle pointing to the syscon node which describes the CPU boot
continuation registers.
o a phandle to the "hif_continuation" syscon node
example:
smpboot {
compatible = "brcm,brcmstb-smpboot";
syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>;
syscon-cont = <&hif_continuation>;
};
reboot
-------
Required properties
- compatible
The string property "brcm,brcmstb-reboot" for 40nm/28nm chips with
the new SYS_CTRL interface, or "brcm,bcm7038-reboot" for 65nm
chips with the old SUN_TOP_CTRL interface.
- syscon
A phandle / integer array that points to the syscon node which describes
the general system reset registers.
o a phandle to "sun_top_ctrl"
o offset to the "reset source enable" register
o offset to the "software master reset" register
example:
reboot {
compatible = "brcm,brcmstb-reboot";
syscon = <&sun_top_ctrl 0x304 0x308>;
};
Power management
----------------
For power management (particularly, S2/S3/S5 system suspend), the following SoC
components are needed:
= Always-On control block (AON CTRL)
This hardware provides control registers for the "always-on" (even in low-power
modes) hardware, such as the Power Management State Machine (PMSM).
Required properties:
- compatible : should contain "brcm,brcmstb-aon-ctrl"
- reg : the register start and length for the AON CTRL block
Example:
aon-ctrl@410000 {
compatible = "brcm,brcmstb-aon-ctrl";
reg = <0x410000 0x400>;
};
= Memory controllers
A Broadcom STB SoC typically has a number of independent memory controllers,
each of which may have several associated hardware blocks, which are versioned
independently (control registers, DDR PHYs, etc.). One might consider
describing these controllers as a parent "memory controllers" block, which
contains N sub-nodes (one for each controller in the system), each of which is
associated with a number of hardware register resources (e.g., its PHY). See
the example device tree snippet below.
== MEMC (MEMory Controller)
Represents a single memory controller instance.
Required properties:
- compatible : should contain "brcm,brcmstb-memc" and "simple-bus"
Should contain subnodes for any of the following relevant hardware resources:
== DDR PHY control
Control registers for this memory controller's DDR PHY.
Required properties:
- compatible : should contain one of these
"brcm,brcmstb-ddr-phy-v71.1"
"brcm,brcmstb-ddr-phy-v72.0"
"brcm,brcmstb-ddr-phy-v225.1"
"brcm,brcmstb-ddr-phy-v240.1"
"brcm,brcmstb-ddr-phy-v240.2"
- reg : the DDR PHY register range
== DDR SHIMPHY
Control registers for this memory controller's DDR SHIMPHY.
Required properties:
- compatible : should contain "brcm,brcmstb-ddr-shimphy-v1.0"
- reg : the DDR SHIMPHY register range
== MEMC DDR control
Sequencer DRAM parameters and control registers. Used for Self-Refresh
Power-Down (SRPD), among other things.
Required properties:
- compatible : should contain one of these
"brcm,brcmstb-memc-ddr-rev-b.2.1"
"brcm,brcmstb-memc-ddr-rev-b.2.2"
"brcm,brcmstb-memc-ddr-rev-b.2.3"
"brcm,brcmstb-memc-ddr-rev-b.3.0"
"brcm,brcmstb-memc-ddr-rev-b.3.1"
"brcm,brcmstb-memc-ddr"
- reg : the MEMC DDR register range
Example:
memory_controllers {
ranges;
compatible = "simple-bus";
memc@0 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1106000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1106000 0x21c>;
};
shimphy@f1108000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1108000 0xe4>;
};
memc-ddr@f1102000 {
reg = <0xf1102000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
memc@1 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1186000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1186000 0x21c>;
};
shimphy@f1188000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1188000 0xe4>;
};
memc-ddr@f1182000 {
reg = <0xf1182000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
memc@2 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1206000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1206000 0x21c>;
};
shimphy@f1208000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1208000 0xe4>;
};
memc-ddr@f1202000 {
reg = <0xf1202000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
};

31
Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.txt
View File

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

14
Documentation/devicetree/bindings/arm/bcm/brcm,hr2.txt
View File

@ -1,14 +0,0 @@
Broadcom Hurricane 2 device tree bindings
---------------------------------------
Broadcom Hurricane 2 family of SoCs are used for switching control. These SoCs
are based on Broadcom's iProc SoC architecture and feature a single core Cortex
A9 ARM CPUs, DDR2/DDR3 memory, PCIe GEN-2, USB 2.0 and USB 3.0, serial and NAND
flash and a PCIe attached integrated switching engine.
Boards with Hurricane SoCs shall have the following properties:
Required root node property:
BCM53342
compatible = "brcm,bcm53342", "brcm,hr2";

9
Documentation/devicetree/bindings/arm/bcm/brcm,ns2.txt
View File

@ -1,9 +0,0 @@
Broadcom North Star 2 (NS2) device tree bindings
------------------------------------------------
Boards with NS2 shall have the following properties:
Required root node property:
NS2 SVK board
compatible = "brcm,ns2-svk", "brcm,ns2";

39
Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
View File

@ -1,39 +0,0 @@
Broadcom Northstar Plus SoC CPU Enable Method
---------------------------------------------
This binding defines the enable method used for starting secondary
CPU in the following Broadcom SoCs:
BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
The enable method is specified by defining the following required
properties in the corresponding secondary "cpu" device tree node:
- enable-method = "brcm,bcm-nsp-smp";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register which should hold the common
entry point for a secondary CPU. This entry is cpu node specific
and should be added per cpu. E.g., in case of NSP (BCM58625) which
is a dual core CPU SoC, this entry should be added to cpu1 node.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
next-level-cache = <&L2>;
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
next-level-cache = <&L2>;
enable-method = "brcm,bcm-nsp-smp";
secondary-boot-reg = <0xffff042c>;
reg = <1>;
};
};

34
Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt
View File

@ -1,34 +0,0 @@
Broadcom Northstar Plus device tree bindings
--------------------------------------------
Broadcom Northstar Plus family of SoCs are used for switching control
and management applications as well as residential router/gateway
applications. The SoC features dual core Cortex A9 ARM CPUs, integrating
several peripheral interfaces including multiple Gigabit Ethernet PHYs,
DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash,
SATA and several other IO controllers.
Boards with Northstar Plus SoCs shall have the following properties:
Required root node property:
BCM58522
compatible = "brcm,bcm58522", "brcm,nsp";
BCM58525
compatible = "brcm,bcm58525", "brcm,nsp";
BCM58535
compatible = "brcm,bcm58535", "brcm,nsp";
BCM58622
compatible = "brcm,bcm58622", "brcm,nsp";
BCM58623
compatible = "brcm,bcm58623", "brcm,nsp";
BCM58625
compatible = "brcm,bcm58625", "brcm,nsp";
BCM88312
compatible = "brcm,bcm88312", "brcm,nsp";

12
Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
View File

@ -1,12 +0,0 @@
Broadcom Stingray device tree bindings
------------------------------------------------
Boards with Stingray shall have the following properties:
Required root node property:
Stingray Combo SVK board
compatible = "brcm,bcm958742k", "brcm,stingray";
Stingray SST100 board
compatible = "brcm,bcm958742t", "brcm,stingray";

10
Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.txt
View File

@ -1,10 +0,0 @@
Broadcom Vulcan device tree bindings
------------------------------------
Boards with Broadcom Vulcan shall have the following root property:
Broadcom Vulcan Evaluation Board:
compatible = "brcm,vulcan-eval", "brcm,vulcan-soc";
Generic Vulcan board:
compatible = "brcm,vulcan-soc";

14
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
View File

@ -1,14 +0,0 @@
Raspberry Pi VideoCore firmware driver
Required properties:
- compatible: Should be "raspberrypi,bcm2835-firmware"
- mboxes: Phandle to the firmware device's Mailbox.
(See: ../mailbox/mailbox.txt for more information)
Example:
firmware {
compatible = "raspberrypi,bcm2835-firmware";
mboxes = <&mailbox>;
};

6
Documentation/devicetree/bindings/arm/bhf.txt
View File

@ -1,6 +0,0 @@
Beckhoff Automation Platforms Device Tree Bindings
--------------------------------------------------
CX9020 Embedded PC
Required root node properties:
- compatible = "bhf,cx9020", "fsl,imx53";

195
Documentation/devicetree/bindings/arm/cache.txt
View File

@ -1,195 +0,0 @@
==========================================
ARM processors cache binding description
==========================================
Device tree bindings for ARM processor caches adhere to the cache bindings
described in [3], in section 3.8 for multi-level and shared caches.
On ARM based systems most of the cache properties related to cache
geometry are probeable in HW, hence, unless otherwise stated, the properties
defined in ePAPR for multi-level and shared caches are to be considered
optional by default.
On ARM, caches are either architected (directly controlled by the processor
through coprocessor instructions and tightly coupled with the processor
implementation) or unarchitected (controlled through a memory mapped
interface, implemented as a stand-alone IP external to the processor
implementation).
This document provides the device tree bindings for ARM architected caches.
- ARM architected cache node
Description: must be a direct child of the cpu node. A system
can contain multiple architected cache nodes per cpu node,
linked through the next-level-cache phandle. The
next-level-cache property in the cpu node points to
the first level of architected cache for the CPU.
The next-level-cache property in architected cache nodes
points to the respective next level of caching in the
hierarchy. An architected cache node with an empty or
missing next-level-cache property represents the last
architected cache level for the CPU.
On ARM v7 and v8 architectures, the order in which cache
nodes are linked through the next-level-cache phandle must
follow the ordering specified in the processors CLIDR (v7)
and CLIDR_EL1 (v8) registers, as described in [1][2],
implying that a cache node pointed at by a
next-level-cache phandle must correspond to a level
defined in CLIDR (v7) and CLIDR_EL1 (v8) greater than the
one the cache node containing the next-level-cache
phandle corresponds to.
Since on ARM most of the cache properties are probeable in HW the
properties described in [3] - section 3.8 multi-level and shared
caches - shall be considered optional, with the following properties
updates, specific for the ARM architected cache node.
- compatible
Usage: Required
Value type: <string>
Definition: value shall be "arm,arch-cache".
- interrupts
Usage: Optional
Value type: See definition
Definition: standard device tree property [3] that defines
the interrupt line associated with the cache.
The property can be accompanied by an
interrupt-names property, as described in [4].
- power-domain
Usage: Optional
Value type: phandle
Definition: A phandle and power domain specifier as defined by
bindings of power controller specified by the
phandle [5].
- qcom,dump-size
Usage: Optional
Value type: <integer>
Definition: The memory size needed to contain a copy of the
cache data and associated tag ram.
size = nways * nsets * (bytes per cache line +
bytes tag ram per line)
Example(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>;
next-level-cache = <&L1_0>;
L1_0: l1-cache {
compatible = "arm,arch-cache";
next-level-cache = <&L2_0>;
};
L2_0: l2-cache {
compatible = "arm,arch-cache";
};
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
next-level-cache = <&L1_1>;
L1_1: l1-cache {
compatible = "arm,arch-cache";
next-level-cache = <&L2_0>;
};
};
cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
next-level-cache = <&L1_2>;
L1_2: l1-cache {
compatible = "arm,arch-cache";
next-level-cache = <&L2_0>;
};
};
cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
next-level-cache = <&L1_3>;
L1_3: l1-cache {
compatible = "arm,arch-cache";
next-level-cache = <&L2_0>;
};
};
cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
next-level-cache = <&L1_4>;
L1_4: l1-cache {
compatible = "arm,arch-cache";
next-level-cache = <&L2_1>;
};
L2_1: l2-cache {
compatible = "arm,arch-cache";
};
};
cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
next-level-cache = <&L1_5>;
L1_5: l1-cache {
compatible = "arm,arch-cache";
next-level-cache = <&L2_1>;
};
};
cpu@102 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
next-level-cache = <&L1_6>;
L1_6: l1-cache {
compatible = "arm,arch-cache";
next-level-cache = <&L2_1>;
};
};
cpu@103 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
next-level-cache = <&L1_7>;
L1_7: l1-cache {
compatible = "arm,arch-cache";
next-level-cache = <&L2_1>;
};
};
};
[1] ARMv7-AR Reference Manual
http://infocenter.arm.com/help/index.jsp
[2] ARMv8-A Reference Manual
http://infocenter.arm.com/help/index.jsp
[3] ePAPR standard
https://www.power.org/documentation/epapr-version-1-1/
[4] Kernel documentation - resource property bindings
Documentation/devicetree/bindings/resource-names.txt
[5] Kernel documentation - power domain bindings
Documentation/devicetree/bindings/power/power_domain.txt

15
Documentation/devicetree/bindings/arm/calxeda.txt
View File

@ -1,15 +0,0 @@
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";

15
Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt
View File

@ -1,15 +0,0 @@
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>;
};

10
Documentation/devicetree/bindings/arm/cavium-thunder.txt
View File

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

8
Documentation/devicetree/bindings/arm/cavium-thunder2.txt
View File

@ -1,8 +0,0 @@
Cavium ThunderX2 CN99XX platform tree bindings
----------------------------------------------
Boards with Cavium ThunderX2 CN99XX SoC shall have the root property:
compatible = "cavium,thunderx2-cn9900", "brcm,vulcan-soc";
These SoC uses the "cavium,thunder2" core which will be compatible
with "brcm,vulcan".

224
Documentation/devicetree/bindings/arm/cci.txt
View File

@ -1,224 +0,0 @@
=======================================================
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.
* 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 contain one of the following:
"arm,cci-400"
"arm,cci-500"
"arm,cci-550"
- 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 Devicetree
Specification 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 contain one of:
"arm,cci-400-pmu,r0"
"arm,cci-400-pmu,r1"
"arm,cci-400-pmu" - DEPRECATED, permitted only where OS has
secure access to CCI registers
"arm,cci-500-pmu,r0"
"arm,cci-550-pmu,r0"
- 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};

25
Documentation/devicetree/bindings/arm/compulab-boards.txt
View File

@ -1,25 +0,0 @@
CompuLab SB-SOM is a multi-module baseboard capable of carrying:
- CM-T43
- CM-T54
- CM-QS600
- CL-SOM-AM57x
- CL-SOM-iMX7
modules with minor modifications to the SB-SOM assembly.
Required root node properties:
- compatible = should be "compulab,sb-som"
Compulab CL-SOM-iMX7 is a miniature System-on-Module (SoM) based on
Freescale i.MX7 ARM Cortex-A7 System-on-Chip.
Required root node properties:
- compatible = "compulab,cl-som-imx7", "fsl,imx7d";
Compulab SBC-iMX7 is a single board computer based on the
Freescale i.MX7 system-on-chip. SBC-iMX7 is implemented with
the CL-SOM-iMX7 System-on-Module providing most of the functions,
and SB-SOM-iMX7 carrier board providing additional peripheral
functions and connectors.
Required root node properties:
- compatible = "compulab,sbc-imx7", "compulab,cl-som-imx7", "fsl,imx7d";

49
Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
View File

@ -1,49 +0,0 @@
* CoreSight CPU Debug Component:
CoreSight CPU debug component are compliant with the ARMv8 architecture
reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The
external debug module is mainly used for two modes: self-hosted debug and
external debug, and it can be accessed from mmio region from Coresight
and eventually the debug module connects with CPU for debugging. And the
debug module provides sample-based profiling extension, which can be used
to sample CPU program counter, secure state and exception level, etc;
usually every CPU has one dedicated debug module to be connected.
Required properties:
- compatible : should be "arm,coresight-cpu-debug"; supplemented with
"arm,primecell" since this driver is using the AMBA bus
interface.
- reg : physical base address and length of the register set.
- clocks : the clock associated to this component.
- clock-names : the name of the clock referenced by the code. Since we are
using the AMBA framework, the name of the clock providing
the interconnect should be "apb_pclk" and the clock is
mandatory. The interface between the debug logic and the
processor core is clocked by the internal CPU clock, so it
is enabled with CPU clock by default.
- cpu : the CPU phandle the debug module is affined to. When omitted
the module is considered to belong to CPU0.
Optional properties:
- power-domains: a phandle to the debug power domain. We use "power-domains"
binding to turn on the debug logic if it has own dedicated
power domain and if necessary to use "cpuidle.off=1" or
"nohlt" in the kernel command line or sysfs node to
constrain idle states to ensure registers in the CPU power
domain are accessible.
Example:
debug@f6590000 {
compatible = "arm,coresight-cpu-debug","arm,primecell";
reg = <0 0xf6590000 0 0x1000>;
clocks = <&sys_ctrl HI6220_DAPB_CLK>;
clock-names = "apb_pclk";
cpu = <&cpu0>;
};

488
Documentation/devicetree/bindings/arm/coresight.txt
View File

@ -1,488 +0,0 @@
* CoreSight Components:
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink. Each CoreSight component device should use these properties to describe
its hardware characteristcs.
* Required properties for all components *except* non-configurable replicators:
* compatible: These have to be supplemented with "arm,primecell" as
drivers are using the AMBA bus interface. Possible values include:
- Embedded Trace Buffer (version 1.0):
"arm,coresight-etb10", "arm,primecell";
- Trace Port Interface Unit:
"arm,coresight-tpiu", "arm,primecell";
- Trace Memory Controller, used for Embedded Trace Buffer(ETB),
Embedded Trace FIFO(ETF) and Embedded Trace Router(ETR)
configuration. The configuration mode (ETB, ETF, ETR) is
discovered at boot time when the device is probed.
"arm,coresight-tmc", "arm,primecell";
- Trace Funnel:
"arm,coresight-funnel", "arm,primecell";
- Embedded Trace Macrocell (version 3.x) and
Program Flow Trace Macrocell:
"arm,coresight-etm3x", "arm,primecell";
- Embedded Trace Macrocell (version 4.x):
"arm,coresight-etm4x", "arm,primecell";
- Coresight programmable Replicator :
"arm,coresight-dynamic-replicator", "arm,primecell";
- System Trace Macrocell:
"arm,coresight-stm", "arm,primecell"; [1]
- Coresight Address Translation Unit (CATU)
"arm,coresight-catu", "arm,primecell";
- Trigger Generation Unit:
"arm,primecell";
* reg: physical base address and length of the register
set(s) of the component.
* clocks: the clocks associated to this component.
* clock-names: the name of the clocks referenced by the code.
Since we are using the AMBA framework, the name of the clock
providing the interconnect should be "apb_pclk", and some
coresight blocks also have an additional clock "atclk", which
clocks the core of that coresight component. The latter clock
is optional.
* port or ports: The representation of the component's port
layout using the generic DT graph presentation found in
"bindings/graph.txt".
* coresight-name: unique descriptive name of the component.
* Additional required properties for System Trace Macrocells (STM):
* reg: along with the physical base address and length of the register
set as described above, another entry is required to describe the
mapping of the extended stimulus port area.
* reg-names: the only acceptable values are "stm-base" and
"stm-stimulus-base", each corresponding to the areas defined in "reg".
* Required properties for devices that don't show up on the AMBA bus, such as
non-configurable replicators:
* compatible: Currently supported value is (note the absence of the
AMBA markee):
- "arm,coresight-replicator"
- "arm,coresight-cti"
- "qcom,coresight-tpda"
- "qcom,coresight-tpdm"
- "qcom,coresight-csr"
- "qcom,coresight-hwevent"
- "qcom,coresight-dummy"
- "qcom,coresight-remote-etm"
* port or ports: same as above.
* coresight-name: unique descriptive name of the component.
* Additional required property for coresight-tgu devices:
* tgu-steps: must be present. Indicates number of steps supported
by the TGU.
* tgu-conditions: must be present. Indicates the number of conditions
supported by the TGU.
* tgu-regs: must be present. Indicates the number of regs supported
by the TGU.
* tgu-timer-counters: must be present. Indicates the number of timers and
counters available in the TGU to do a comparision.
* Optional properties for all components:
* reg-names: names corresponding to each reg property value.
* qcom,proxy-regs: List of regulators required.
* qcom,proxy-clks: List of additional clocks required.
* Optional properties for ETM/PTMs:
* arm,cp14: must be present if the system accesses ETM/PTM management
registers via co-processor 14.
* cpu: the cpu phandle this ETM/PTM is affined to. When omitted the
source is considered to belong to CPU0.
* qcom,tupwr-disable: For ETM, don't keep trace unit powered across power
collapse.
* Optional property for TMC:
* arm,buffer-size: size of contiguous buffer space for TMC ETR
(embedded trace router). This property is obsolete. The buffer size
can be configured dynamically via buffer_size property in sysfs.
* arm,scatter-gather: boolean. Indicates that the TMC-ETR can safely
use the SG mode on this system.
* arm,default-sink: represents the default compile time CoreSight sink
* coresight-ctis: represents flush and reset CTIs for TMC buffer
* qcom,force-reg-dump: enables TMC reg dump support
* arm,sg-enable : indicates whether scatter gather feature is enabled
by default for TMC ETR configuration.
* Optional property for CATU :
* interrupts : Exactly one SPI may be listed for reporting the address
error
* Required property for TPDAs:
* qcom,tpda-atid: must be present. Specifies the ATID for TPDA.
* Optional properties for TPDAs:
* qcom,bc-elem-size: specifies the BC element size supported by each
monitor connected to the aggregator on each port. Should be specified
in pairs (port, bc element size).
* qcom,tc-elem-size: specifies the TC element size supported by each
monitor connected to the aggregator on each port. Should be specified
in pairs (port, tc element size).
* qcom,dsb-elem-size: specifies the DSB element size supported by each
monitor connected to the aggregator on each port. Should be specified
in pairs (port, dsb element size).
* qcom,cmb-elem-size: specifies the CMB element size supported by each
monitor connected to the aggregator on each port. Should be specified
in pairs (port, cmb element size).
* Optional properties for TPDM:
* qcom,clk-enable: specifies whether additional clock bit needs to be
set for M4M TPDM.
* qcom,msr-fix-req: boolean, indicating if MSRs need to be programmed
after enabling the subunit.
* qcom,hw-enable-check: Check if the tpdm need to be probed as some tpdms
are not enabled in secure device.
* Optional properties for CSRs:
* qcom,usb-bam-support: boolean, indicates CSR has the ability to operate on
usb bam, include enable,disable and flush.
* qcom,hwctrl-set-support: boolean, indicates CSR has the ability to operate on
to "HWCTRL" register.
* qcom,set-byte-cntr-support:boolean, indicates CSR has the ability to operate on
to "BYTECNT" register.
* qcom,timestamp-support:boolean, indicates CSR support sys interface to read
timestamp value.
* Required property for Remote ETMs:
* qcom,inst-id: must be present. QMI instance id for remote ETMs.
* Optional properties for funnels:
* source: specifies the source that binds to this output port. Only
trace from that source routes to this output port.
* qcom,duplicate-funnel: boolean, indicates its a duplicate of an
existing funnel. Funnel devices are now capable of supporting
multiple-input and multiple-output configuration with in built
hardware filtering for TPDM devices. Each set of input-output
combination is treated as independent funnel device.
funnel-base-dummy and funnel-base-real reg-names must be specified
when this property is enabled.
* reg-names: funnel-base-dummy: dummy register space used by a
duplicate funnel. Should be a valid register address space that
no other device is using.
* reg-names: funnel-base-real: actual register space for the
duplicate funnel.
Example:
1. Sinks
etb@20010000 {
compatible = "arm,coresight-etb10", "arm,primecell";
reg = <0 0x20010000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
etb_in_port: endpoint@0 {
slave-mode;
remote-endpoint = <&replicator_out_port0>;
};
};
};
tpiu@20030000 {
compatible = "arm,coresight-tpiu", "arm,primecell";
reg = <0 0x20030000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
tpiu_in_port: endpoint@0 {
slave-mode;
remote-endpoint = <&replicator_out_port1>;
};
};
};
etr@20070000 {
compatible = "arm,coresight-tmc", "arm,primecell";
reg = <0 0x20070000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
ports {
#address-cells = <1>;
#size-cells = <0>;
/* input port */
port@0 {
reg = <0>;
etr_in_port: endpoint {
slave-mode;
remote-endpoint = <&replicator2_out_port0>;
};
};
/* CATU link represented by output port */
port@1 {
reg = <1>;
etr_out_port: endpoint {
remote-endpoint = <&catu_in_port>;
};
};
};
};
2. Links
replicator {
/* non-configurable replicators don't show up on the
* AMBA bus. As such no need to add "arm,primecell".
*/
compatible = "arm,coresight-replicator";
ports {
#address-cells = <1>;
#size-cells = <0>;
/* replicator output ports */
port@0 {
reg = <0>;
replicator_out_port0: endpoint {
remote-endpoint = <&etb_in_port>;
};
};
port@1 {
reg = <1>;
replicator_out_port1: endpoint {
remote-endpoint = <&tpiu_in_port>;
};
};
/* replicator input port */
port@2 {
reg = <0>;
replicator_in_port0: endpoint {
slave-mode;
remote-endpoint = <&funnel_out_port0>;
};
};
};
};
funnel@20040000 {
compatible = "arm,coresight-funnel", "arm,primecell";
reg = <0 0x20040000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
ports {
#address-cells = <1>;
#size-cells = <0>;
/* funnel output port */
port@0 {
reg = <0>;
funnel_out_port0: endpoint {
remote-endpoint =
<&replicator_in_port0>;
};
};
/* funnel input ports */
port@1 {
reg = <0>;
funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&ptm0_out_port>;
};
};
port@2 {
reg = <1>;
funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&ptm1_out_port>;
};
};
port@3 {
reg = <2>;
funnel_in_port2: endpoint {
slave-mode;
remote-endpoint = <&etm0_out_port>;
};
};
};
};
tpda_mss: tpda@7043000 {
compatible = "qcom,coresight-tpda", "arm,primecell";
reg = <0x7043000 0x1000>;
reg-names = "tpda-base";
coresight-name = "coresight-tpda-mss";
qcom,tpda-atid = <67>;
qcom,dsb-elem-size = <0 32>;
qcom,cmb-elem-size = <0 32>;
clocks = <&clock_aop qdss_clk>;
clock-names = "apb_pclk";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
tpda_mss_out_funnel_in1: endpoint {
remote-endpoint =
<&funnel_in1_in_tpda_mss>;
};
};
port@1 {
reg = <0>;
tpda_mss_in_tpdm_mss: endpoint {
slave-mode;
remote-endpoint =
<&tpdm_mss_out_tpda_mss>;
};
};
};
};
3. Sources
ptm@2201c000 {
compatible = "arm,coresight-etm3x", "arm,primecell";
reg = <0 0x2201c000 0 0x1000>;
cpu = <&cpu0>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
ptm0_out_port: endpoint {
remote-endpoint = <&funnel_in_port0>;
};
};
};
ptm@2201d000 {
compatible = "arm,coresight-etm3x", "arm,primecell";
reg = <0 0x2201d000 0 0x1000>;
cpu = <&cpu1>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
ptm1_out_port: endpoint {
remote-endpoint = <&funnel_in_port1>;
};
};
};
4. STM
stm@20100000 {
compatible = "arm,coresight-stm", "arm,primecell";
reg = <0 0x20100000 0 0x1000>,
<0 0x28000000 0 0x180000>;
reg-names = "stm-base", "stm-stimulus-base";
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
port {
stm_out_port: endpoint {
remote-endpoint = <&main_funnel_in_port2>;
};
};
};
5. CATU
catu@207e0000 {
compatible = "arm,coresight-catu", "arm,primecell";
reg = <0 0x207e0000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
port {
catu_in_port: endpoint {
slave-mode;
remote-endpoint = <&etr_out_port>;
};
};
};
tpdm_mss: tpdm@7042000 {
compatible = "qcom,coresight-tpdm", "arm,primecell";
reg = <0x7042000 0x1000>;
reg-names = "tpdm-base";
coresight-name = "coresight-tpdm-mss";
clocks = <&clock_aop qdss_clk>;
clock-names = "apb_pclk";
port{
tpdm_mss_out_tpda_mss: endpoint {
remote-endpoint = <&tpda_mss_in_tpdm_mss>;
};
};
};
5. TGUs
ipcb_tgu: tgu@6b0c000 {
compatible = "arm,primecell";
arm,primecell-periphid = <0x0003b999>;
reg = <0x06B0C000 0x1000>;
reg-names = "tgu-base";
tgu-steps = <3>;
tgu-conditions = <4>;
tgu-regs = <4>;
tgu-timer-counters = <8>;
coresight-name = "coresight-tgu-ipcb";
clocks = <&clock_aop QDSS_CLK>;
clock-names = "apb_pclk";
};
[1]. There is currently two version of STM: STM32 and STM500. Both
have the same HW interface and as such don't need an explicit binding name.

236
Documentation/devicetree/bindings/arm/cpu-capacity.txt
View File

@ -1,236 +0,0 @@
==========================================
ARM CPUs capacity bindings
==========================================
==========================================
1 - Introduction
==========================================
ARM systems may be configured to have cpus with different power/performance
characteristics within the same chip. In this case, additional information has
to be made available to the kernel for it to be aware of such differences and
take decisions accordingly.
==========================================
2 - CPU capacity definition
==========================================
CPU capacity is a number that provides the scheduler information about CPUs
heterogeneity. Such heterogeneity can come from micro-architectural differences
(e.g., ARM big.LITTLE systems) or maximum frequency at which CPUs can run
(e.g., SMP systems with multiple frequency domains). Heterogeneity in this
context is about differing performance characteristics; this binding tries to
capture a first-order approximation of the relative performance of CPUs.
CPU capacities are obtained by running a suitable benchmark. This binding makes
no guarantees on the validity or suitability of any particular benchmark, the
final capacity should, however, be:
* A "single-threaded" or CPU affine benchmark
* Divided by the running frequency of the CPU executing the benchmark
* Not subject to dynamic frequency scaling of the CPU
For the time being we however advise usage of the Dhrystone benchmark. What
above thus becomes:
CPU capacities are obtained by running the Dhrystone benchmark on each CPU at
max frequency (with caches enabled). The obtained DMIPS score is then divided
by the frequency (in MHz) at which the benchmark has been run, so that
DMIPS/MHz are obtained. Such values are then normalized w.r.t. the highest
score obtained in the system.
==========================================
3 - capacity-dmips-mhz
==========================================
capacity-dmips-mhz is an optional cpu node [1] property: u32 value
representing CPU capacity expressed in normalized DMIPS/MHz. At boot time, the
maximum frequency available to the cpu is then used to calculate the capacity
value internally used by the kernel.
capacity-dmips-mhz property is all-or-nothing: if it is specified for a cpu
node, it has to be specified for every other cpu nodes, or the system will
fall back to the default capacity value for every CPU. If cpufreq is not
available, final capacities are calculated by directly using capacity-dmips-
mhz values (normalized w.r.t. the highest value found while parsing the DT).
===========================================
4 - Examples
===========================================
Example 1 (ARM 64-bit, 6-cpu system, two clusters):
capacities-dmips-mhz are scaled w.r.t. 1024 (cpu@0 and cpu@1)
supposing cluster0@max-freq=1100 and custer1@max-freq=850,
final capacities are 1024 for cluster0 and 446 for cluster1
cpus {
#address-cells = <2>;
#size-cells = <0>;
cpu-map {
cluster0 {
core0 {
cpu = <&A57_0>;
};
core1 {
cpu = <&A57_1>;
};
};
cluster1 {
core0 {
cpu = <&A53_0>;
};
core1 {
cpu = <&A53_1>;
};
core2 {
cpu = <&A53_2>;
};
core3 {
cpu = <&A53_3>;
};
};
};
idle-states {
entry-method = "psci";
CPU_SLEEP_0: cpu-sleep-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0010000>;
local-timer-stop;
entry-latency-us = <100>;
exit-latency-us = <250>;
min-residency-us = <150>;
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
entry-latency-us = <800>;
exit-latency-us = <700>;
min-residency-us = <2500>;
};
};
A57_0: cpu@0 {
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x0 0x0>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A57_L2>;
clocks = <&scpi_dvfs 0>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <1024>;
};
A57_1: cpu@1 {
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x0 0x1>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A57_L2>;
clocks = <&scpi_dvfs 0>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <1024>;
};
A53_0: cpu@100 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x100>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <578>;
};
A53_1: cpu@101 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x101>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <578>;
};
A53_2: cpu@102 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x102>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <578>;
};
A53_3: cpu@103 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x103>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <578>;
};
A57_L2: l2-cache0 {
compatible = "cache";
};
A53_L2: l2-cache1 {
compatible = "cache";
};
};
Example 2 (ARM 32-bit, 4-cpu system, two clusters,
cpus 0,1@1GHz, cpus 2,3@500MHz):
capacities-dmips-mhz are scaled w.r.t. 2 (cpu@0 and cpu@1), this means that first
cpu@0 and cpu@1 are twice fast than cpu@2 and cpu@3 (at the same frequency)
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0>;
capacity-dmips-mhz = <2>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <1>;
capacity-dmips-mhz = <2>;
};
cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x100>;
capacity-dmips-mhz = <1>;
};
cpu3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x101>;
capacity-dmips-mhz = <1>;
};
};
===========================================
5 - References
===========================================
[1] ARM Linux Kernel documentation - CPUs bindings
Documentation/devicetree/bindings/arm/cpus.txt

52
Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp
View File

@ -1,52 +0,0 @@
========================================================
Secondary CPU enable-method "al,alpine-smp" binding
========================================================
This document describes the "al,alpine-smp" method for
enabling secondary CPUs. To apply to all CPUs, a single
"al,alpine-smp" enable method should be defined in the
"cpus" node.
Enable method name: "al,alpine-smp"
Compatible machines: "al,alpine"
Compatible CPUs: "arm,cortex-a15"
Related properties: (none)
Note:
This enable method requires valid nodes compatible with
"al,alpine-cpu-resume" and "al,alpine-nb-service"[1].
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "al,alpine-smp";
cpu@0 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <0>;
};
cpu@1 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <1>;
};
cpu@2 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <2>;
};
cpu@3 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <3>;
};
};
--
[1] arm/al,alpine.txt

41
Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,berlin-smp
View File

@ -1,41 +0,0 @@
========================================================
Secondary CPU enable-method "marvell,berlin-smp" binding
========================================================
This document describes the "marvell,berlin-smp" method for enabling secondary
CPUs. To apply to all CPUs, a single "marvell,berlin-smp" enable method should
be defined in the "cpus" node.
Enable method name: "marvell,berlin-smp"
Compatible machines: "marvell,berlin2" and "marvell,berlin2q"
Compatible CPUs: "marvell,pj4b" and "arm,cortex-a9"
Related properties: (none)
Note:
This enable method needs valid nodes compatible with "arm,cortex-a9-scu" and
"marvell,berlin-cpu-ctrl"[1].
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "marvell,berlin-smp";
cpu@0 {
compatible = "marvell,pj4b";
device_type = "cpu";
next-level-cache = <&l2>;
reg = <0>;
};
cpu@1 {
compatible = "marvell,pj4b";
device_type = "cpu";
next-level-cache = <&l2>;
reg = <1>;
};
};
--
[1] arm/marvell,berlin.txt

42
Documentation/devicetree/bindings/arm/cpu-enable-method/nuvoton,npcm750-smp
View File

@ -1,42 +0,0 @@
=========================================================
Secondary CPU enable-method "nuvoton,npcm750-smp" binding
=========================================================
To apply to all CPUs, a single "nuvoton,npcm750-smp" enable method should be
defined in the "cpus" node.
Enable method name: "nuvoton,npcm750-smp"
Compatible machines: "nuvoton,npcm750"
Compatible CPUs: "arm,cortex-a9"
Related properties: (none)
Note:
This enable method needs valid nodes compatible with "arm,cortex-a9-scu" and
"nuvoton,npcm750-gcr".
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "nuvoton,npcm750-smp";
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
clocks = <&clk NPCM7XX_CLK_CPU>;
clock-names = "clk_cpu";
reg = <0>;
next-level-cache = <&L2>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
clocks = <&clk NPCM7XX_CLK_CPU>;
clock-names = "clk_cpu";
reg = <1>;
next-level-cache = <&L2>;
};
};

490
Documentation/devicetree/bindings/arm/cpus.txt
View File

@ -1,490 +0,0 @@
=================
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 Devicetree Specification, available from:
https://www.devicetree.org/specifications/
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 Devicetree
Specification, 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 Devicetree Specification,
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-a12"
"arm,cortex-a15"
"arm,cortex-a17"
"arm,cortex-a53"
"arm,cortex-a57"
"arm,cortex-a72"
"arm,cortex-a73"
"arm,cortex-m0"
"arm,cortex-m0+"
"arm,cortex-m1"
"arm,cortex-m3"
"arm,cortex-m4"
"arm,cortex-r4"
"arm,cortex-r5"
"arm,cortex-r7"
"brcm,brahma-b15"
"brcm,brahma-b53"
"brcm,vulcan"
"cavium,thunder"
"cavium,thunder2"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
"marvell,feroceon"
"marvell,mohawk"
"marvell,pj4a"
"marvell,pj4b"
"marvell,sheeva-v5"
"nvidia,tegra132-denver"
"nvidia,tegra186-denver"
"nvidia,tegra194-carmel"
"qcom,krait"
"qcom,kryo"
"qcom,kryo385"
"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:
"psci"
"spin-table"
# On ARM 32-bit systems this property is optional and
can be one of:
"actions,s500-smp"
"allwinner,sun6i-a31"
"allwinner,sun8i-a23"
"allwinner,sun9i-a80-smp"
"amlogic,meson8-smp"
"amlogic,meson8b-smp"
"arm,realview-smp"
"brcm,bcm11351-cpu-method"
"brcm,bcm23550"
"brcm,bcm2836-smp"
"brcm,bcm-nsp-smp"
"brcm,brahma-b15"
"marvell,armada-375-smp"
"marvell,armada-380-smp"
"marvell,armada-390-smp"
"marvell,armada-xp-smp"
"marvell,98dx3236-smp"
"mediatek,mt6589-smp"
"mediatek,mt81xx-tz-smp"
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
"renesas,apmu"
"renesas,r9a06g032-smp"
"rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
- 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.
- qcom,saw
Usage: required for systems that have an "enable-method"
property value of "qcom,kpss-acc-v1" or
"qcom,kpss-acc-v2"
Value type: <phandle>
Definition: Specifies the SAW[1] node associated with this CPU.
- qcom,acc
Usage: required for systems that have an "enable-method"
property value of "qcom,kpss-acc-v1" or
"qcom,kpss-acc-v2"
Value type: <phandle>
Definition: Specifies the ACC[2] node associated with this CPU.
- cpu-idle-states
Usage: Optional
Value type: <prop-encoded-array>
Definition:
# List of phandles to idle state nodes supported
by this cpu [3].
- capacity-dmips-mhz
Usage: Optional
Value type: <u32>
Definition:
# u32 value representing CPU capacity [4] in
DMIPS/MHz, relative to highest capacity-dmips-mhz
in the system.
- rockchip,pmu
Usage: optional for systems that have an "enable-method"
property value of "rockchip,rk3066-smp"
While optional, it is the preferred way to get access to
the cpu-core power-domains.
Value type: <phandle>
Definition: Specifies the syscon node controlling the cpu core
power domains.
- dynamic-power-coefficient
Usage: optional
Value type: <prop-encoded-array>
Definition: A u32 value that represents the running time dynamic
power coefficient in units of mW/MHz/uV^2. The
coefficient can either be calculated from power
measurements or derived by analysis.
The dynamic power consumption of the CPU is
proportional to the square of the Voltage (V) and
the clock frequency (f). The coefficient is used to
calculate the dynamic power as below -
Pdyn = dynamic-power-coefficient * V^2 * f
where voltage is in uV, frequency is in MHz.
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>;
};
};
--
[1] arm/msm/qcom,saw2.txt
[2] arm/msm/qcom,kpss-acc.txt
[3] ARM Linux kernel documentation - idle states bindings
Documentation/devicetree/bindings/arm/idle-states.txt
[4] ARM Linux kernel documentation - cpu capacity bindings
Documentation/devicetree/bindings/arm/cpu-capacity.txt

25
Documentation/devicetree/bindings/arm/davinci.txt
View File

@ -1,25 +0,0 @@
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";
DA850/OMAP-L138/AM18x L138/C6748 Development Kit (LCDK) board
Required root node properties:
- compatible = "ti,da850-lcdk", "ti,da850";
EnBW AM1808 based CMC board
Required root node properties:
- compatible = "enbw,cmc", "ti,da850;
LEGO MINDSTORMS EV3 (AM1808 based)
Required root node properties:
- compatible = "lego,ev3", "ti,da850";
Generic DaVinci Boards
----------------------
DA850/OMAP-L138/AM18x generic board
Required root node properties:
- compatible = "ti,da850";

6
Documentation/devicetree/bindings/arm/digicolor.txt
View File

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

31
Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
View File

@ -1,31 +0,0 @@
OP-TEE Device Tree Bindings
OP-TEE is a piece of software using hardware features to provide a Trusted
Execution Environment. The security can be provided with ARM TrustZone, but
also by virtualization or a separate chip.
We're using "linaro" as the first part of the compatible property for
the reference implementation maintained by Linaro.
* OP-TEE based on ARM TrustZone required properties:
- compatible : should contain "linaro,optee-tz"
- method : The method of calling the OP-TEE Trusted OS. Permitted
values are:
"smc" : SMC #0, with the register assignments specified
in drivers/tee/optee/optee_smc.h
"hvc" : HVC #0, with the register assignments specified
in drivers/tee/optee/optee_smc.h
Example:
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
};
};

42
Documentation/devicetree/bindings/arm/firmware/sdei.txt
View File

@ -1,42 +0,0 @@
* Software Delegated Exception Interface (SDEI)
Firmware implementing the SDEI functions described in ARM document number
ARM DEN 0054A ("Software Delegated Exception Interface") can be used by
Linux to receive notification of events such as those generated by
firmware-first error handling, or from an IRQ that has been promoted to
a firmware-assisted NMI.
The interface provides a number of API functions for registering callbacks
and enabling/disabling events. Functions are invoked by trapping to the
privilege level of the SDEI firmware (specified as part of the binding
below) and passing arguments in a manner specified by the "SMC Calling
Convention (ARM DEN 0028B):
r0 => 32-bit Function ID / return value
{r1 - r3} => Parameters
Note that the immediate field of the trapping instruction must be set
to #0.
The SDEI_EVENT_REGISTER function registers a callback in the kernel
text to handle the specified event number.
The sdei node should be a child node of '/firmware' and have required
properties:
- compatible : should contain:
* "arm,sdei-1.0" : For implementations complying to SDEI version 1.x.
- method : The method of calling the SDEI 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.
Example:
firmware {
sdei {
compatible = "arm,sdei-1.0";
method = "smc";
};
};

20
Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt
View File

@ -1,20 +0,0 @@
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>;
};
};

14
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
View File

@ -1,14 +0,0 @@
Freescale Vybrid Miscellaneous System Control - CPU Configuration
The MSCM IP contains multiple sub modules, this binding describes the first
block of registers which contains CPU configuration information.
Required properties:
- compatible: "fsl,vf610-mscm-cpucfg", "syscon"
- reg: the register range of the MSCM CPU configuration registers
Example:
mscm_cpucfg: cpucfg@40001000 {
compatible = "fsl,vf610-mscm-cpucfg", "syscon";
reg = <0x40001000 0x800>;
}

30
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
View File

@ -1,30 +0,0 @@
Freescale Vybrid Miscellaneous System Control - Interrupt Router
The MSCM IP contains multiple sub modules, this binding describes the second
block of registers which control the interrupt router. The interrupt router
allows to configure the recipient of each peripheral interrupt. Furthermore
it controls the directed processor interrupts. The module is available in all
Vybrid SoC's but is only really useful in dual core configurations (VF6xx
which comes with a Cortex-A5/Cortex-M4 combination).
Required properties:
- compatible: "fsl,vf610-mscm-ir"
- reg: the register range of the MSCM Interrupt Router
- fsl,cpucfg: The handle to the MSCM CPU configuration node, required
to get the current CPU ID
- interrupt-controller: Identifies the node as an interrupt controller
- #interrupt-cells: Two cells, interrupt number and cells.
The hardware interrupt number according to interrupt
assignment of the interrupt router is required.
Flags get passed only when using GIC as parent. Flags
encoding as documented by the GIC bindings.
Example:
mscm_ir: interrupt-controller@40001800 {
compatible = "fsl,vf610-mscm-ir";
reg = <0x40001800 0x400>;
fsl,cpucfg = <&mscm_cpucfg>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
}

12
Documentation/devicetree/bindings/arm/freescale/m4if.txt
View File

@ -1,12 +0,0 @@
* Freescale Multi Master Multi Memory Interface (M4IF) module
Required properties:
- compatible : Should be "fsl,imx51-m4if"
- reg : Address and length of the register set for the device
Example:
m4if: m4if@83fd8000 {
compatible = "fsl,imx51-m4if";
reg = <0x83fd8000 0x1000>;
};

12
Documentation/devicetree/bindings/arm/freescale/tigerp.txt
View File

@ -1,12 +0,0 @@
* Freescale Tigerp platform module
Required properties:
- compatible : Should be "fsl,imx51-tigerp"
- reg : Address and length of the register set for the device
Example:
tigerp: tigerp@83fa0000 {
compatible = "fsl,imx51-tigerp";
reg = <0x83fa0000 0x28>;
};

224
Documentation/devicetree/bindings/arm/fsl.txt
View File

@ -1,224 +0,0 @@
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";
i.MX6SLL EVK board
Required root node properties:
- compatible = "fsl,imx6sll-evk", "fsl,imx6sll";
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";
Freescale Vybrid Platform Device Tree Bindings
----------------------------------------------
For the Vybrid SoC familiy all variants with DDR controller are supported,
which is the VF5xx and VF6xx series. Out of historical reasons, in most
places the kernel uses vf610 to refer to the whole familiy.
The compatible string "fsl,vf610m4" is used for the secondary Cortex-M4
core support.
Required root node compatible property (one of them):
- compatible = "fsl,vf500";
- compatible = "fsl,vf510";
- compatible = "fsl,vf600";
- compatible = "fsl,vf610";
- compatible = "fsl,vf610m4";
Freescale LS1021A Platform Device Tree Bindings
------------------------------------------------
Required root node compatible properties:
- compatible = "fsl,ls1021a";
Freescale SoC-specific Device Tree Bindings
-------------------------------------------
Freescale SCFG
SCFG is the supplemental configuration unit, that provides SoC specific
configuration and status registers for the chip. Such as getting PEX port
status.
Required properties:
- compatible: Should contain a chip-specific compatible string,
Chip-specific strings are of the form "fsl,<chip>-scfg",
The following <chip>s are known to be supported:
ls1012a, ls1021a, ls1043a, ls1046a, ls2080a.
- reg: should contain base address and length of SCFG memory-mapped registers
Example:
scfg: scfg@1570000 {
compatible = "fsl,ls1021a-scfg";
reg = <0x0 0x1570000 0x0 0x10000>;
};
Freescale DCFG
DCFG is the device configuration unit, that provides general purpose
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- compatible: Should contain a chip-specific compatible string,
Chip-specific strings are of the form "fsl,<chip>-dcfg",
The following <chip>s are known to be supported:
ls1012a, ls1021a, ls1043a, ls1046a, ls2080a.
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1021a-dcfg";
reg = <0x0 0x1ee0000 0x0 0x10000>;
};
Freescale ARMv8 based Layerscape SoC family Device Tree Bindings
----------------------------------------------------------------
LS1012A SoC
Required root node properties:
- compatible = "fsl,ls1012a";
LS1012A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls1012a-rdb", "fsl,ls1012a";
LS1012A ARMv8 based FRDM Board
Required root node properties:
- compatible = "fsl,ls1012a-frdm", "fsl,ls1012a";
LS1012A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls1012a-qds", "fsl,ls1012a";
LS1043A SoC
Required root node properties:
- compatible = "fsl,ls1043a";
LS1043A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls1043a-rdb", "fsl,ls1043a";
LS1043A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls1043a-qds", "fsl,ls1043a";
LS1046A SoC
Required root node properties:
- compatible = "fsl,ls1046a";
LS1046A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls1046a-qds", "fsl,ls1046a";
LS1046A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls1046a-rdb", "fsl,ls1046a";
LS1088A SoC
Required root node properties:
- compatible = "fsl,ls1088a";
LS1088A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls1088a-qds", "fsl,ls1088a";
LS1088A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls1088a-rdb", "fsl,ls1088a";
LS2080A SoC
Required root node properties:
- compatible = "fsl,ls2080a";
LS2080A ARMv8 based Simulator model
Required root node properties:
- compatible = "fsl,ls2080a-simu", "fsl,ls2080a";
LS2080A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls2080a-qds", "fsl,ls2080a";
LS2080A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls2080a-rdb", "fsl,ls2080a";
LS2088A SoC
Required root node properties:
- compatible = "fsl,ls2088a";
LS2088A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls2088a-qds", "fsl,ls2088a";
LS2088A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls2088a-rdb", "fsl,ls2088a";

38
Documentation/devicetree/bindings/arm/fw-cfg.txt
View File

@ -1,38 +0,0 @@
* QEMU Firmware Configuration bindings for ARM
QEMU's arm-softmmu and aarch64-softmmu emulation / virtualization targets
provide the following Firmware Configuration interface on the "virt" machine
type:
- A write-only, 16-bit wide selector (or control) register,
- a read-write, 64-bit wide data register.
QEMU exposes the control and data register to ARM guests as memory mapped
registers; their location is communicated to the guest's UEFI firmware in the
DTB that QEMU places at the bottom of the guest's DRAM.
The authoritative guest-side hardware interface documentation to the fw_cfg
device can be found in "docs/specs/fw_cfg.txt" in the QEMU source tree.
Required properties:
- compatible: "qemu,fw-cfg-mmio".
- reg: the MMIO region used by the device.
* Bytes 0x0 to 0x7 cover the data register.
* Bytes 0x8 to 0x9 cover the selector register.
* Further registers may be appended to the region in case of future interface
revisions / feature bits.
Example:
/ {
#size-cells = <0x2>;
#address-cells = <0x2>;
fw-cfg@9020000 {
compatible = "qemu,fw-cfg-mmio";
reg = <0x0 0x9020000 0x0 0xa>;
};
};

108
Documentation/devicetree/bindings/arm/gemini.txt
View File

@ -1,108 +0,0 @@
Cortina systems Gemini platforms
The Gemini SoC is the project name for an ARMv4 FA525-based SoC originally
produced by Storlink Semiconductor around 2005. The company was renamed
later renamed Storm Semiconductor. The chip product name is Storlink SL3516.
It was derived from earlier products from Storm named SL3316 (Centroid) and
SL3512 (Bulverde).
Storm Semiconductor was acquired by Cortina Systems in 2008 and the SoC was
produced and used for NAS and similar usecases. In 2014 Cortina Systems was
in turn acquired by Inphi, who seem to have discontinued this product family.
Many of the IP blocks used in the SoC comes from Faraday Technology.
Required properties (in root node):
compatible = "cortina,gemini";
Required nodes:
- soc: the SoC should be represented by a simple bus encompassing all the
onchip devices, this is referred to as the soc bus node.
- syscon: the soc bus node must have a system controller node pointing to the
global control registers, with the compatible string
"cortina,gemini-syscon", "syscon";
Required properties on the syscon:
- reg: syscon register location and size.
- #clock-cells: should be set to <1> - the system controller is also a
clock provider.
- #reset-cells: should be set to <1> - the system controller is also a
reset line provider.
The clock sources have shorthand defines in the include file:
<dt-bindings/clock/cortina,gemini-clock.h>
The reset lines have shorthand defines in the include file:
<dt-bindings/reset/cortina,gemini-reset.h>
- timer: the soc bus node must have a timer node pointing to the SoC timer
block, with the compatible string "cortina,gemini-timer"
See: clocksource/cortina,gemini-timer.txt
- interrupt-controller: the sob bus node must have an interrupt controller
node pointing to the SoC interrupt controller block, with the compatible
string "cortina,gemini-interrupt-controller"
See interrupt-controller/cortina,gemini-interrupt-controller.txt
Example:
/ {
model = "Foo Gemini Machine";
compatible = "cortina,gemini";
#address-cells = <1>;
#size-cells = <1>;
memory {
device_type = "memory";
reg = <0x00000000 0x8000000>;
};
soc {
#address-cells = <1>;
#size-cells = <1>;
ranges;
compatible = "simple-bus";
interrupt-parent = <&intcon>;
syscon: syscon@40000000 {
compatible = "cortina,gemini-syscon", "syscon";
reg = <0x40000000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
uart0: serial@42000000 {
compatible = "ns16550a";
reg = <0x42000000 0x100>;
resets = <&syscon GEMINI_RESET_UART>;
clocks = <&syscon GEMINI_CLK_UART>;
interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
};
timer@43000000 {
compatible = "cortina,gemini-timer";
reg = <0x43000000 0x1000>;
interrupt-parent = <&intcon>;
interrupts = <14 IRQ_TYPE_EDGE_FALLING>, /* Timer 1 */
<15 IRQ_TYPE_EDGE_FALLING>, /* Timer 2 */
<16 IRQ_TYPE_EDGE_FALLING>; /* Timer 3 */
resets = <&syscon GEMINI_RESET_TIMER>;
/* APB clock or RTC clock */
clocks = <&syscon GEMINI_CLK_APB>,
<&syscon GEMINI_CLK_RTC>;
clock-names = "PCLK", "EXTCLK";
syscon = <&syscon>;
};
intcon: interrupt-controller@48000000 {
compatible = "cortina,gemini-interrupt-controller";
reg = <0x48000000 0x1000>;
resets = <&syscon GEMINI_RESET_INTCON0>;
interrupt-controller;
#interrupt-cells = <2>;
};
};
};

14
Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
View File

@ -1,14 +0,0 @@
* Hisilicon Hi3519 System Controller Block
This bindings use the following binding:
Documentation/devicetree/bindings/mfd/syscon.txt
Required properties:
- compatible: "hisilicon,hi3519-sysctrl".
- reg: the register region of this block
Examples:
sysctrl: system-controller@12010000 {
compatible = "hisilicon,hi3519-sysctrl", "syscon";
reg = <0x12010000 0x1000>;
};

33
Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
View File

@ -1,33 +0,0 @@
Hisilicon Hip06 Low Pin Count device
Hisilicon Hip06 SoCs implement a Low Pin Count (LPC) controller, which
provides I/O access to some legacy ISA devices.
Hip06 is based on arm64 architecture where there is no I/O space. So, the
I/O ports here are not CPU addresses, and there is no 'ranges' property in
LPC device node.
Required properties:
- compatible: value should be as follows:
(a) "hisilicon,hip06-lpc"
(b) "hisilicon,hip07-lpc"
- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
- reg: base memory range where the LPC register set is mapped.
Note:
The node name before '@' must be "isa" to represent the binding stick to the
ISA/EISA binding specification.
Example:
isa@a01b0000 {
compatible = "hisilicon,hip06-lpc";
#address-cells = <2>;
#size-cells = <1>;
reg = <0x0 0xa01b0000 0x0 0x1000>;
ipmi0: bt@e4 {
compatible = "ipmi-bt";
device_type = "ipmi";
reg = <0x01 0xe4 0x04>;
};
};

311
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
View File

@ -1,311 +0,0 @@
Hisilicon Platforms Device Tree Bindings
----------------------------------------------------
Hi3660 SoC
Required root node properties:
- compatible = "hisilicon,hi3660";
HiKey960 Board
Required root node properties:
- compatible = "hisilicon,hi3660-hikey960", "hisilicon,hi3660";
Hi3798cv200 SoC
Required root node properties:
- compatible = "hisilicon,hi3798cv200";
Hi3798cv200 Poplar Board
Required root node properties:
- compatible = "hisilicon,hi3798cv200-poplar", "hisilicon,hi3798cv200";
Hi4511 Board
Required root node properties:
- compatible = "hisilicon,hi3620-hi4511";
Hi6220 SoC
Required root node properties:
- compatible = "hisilicon,hi6220";
HiKey Board
Required root node properties:
- compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220";
HiP01 ca9x2 Board
Required root node properties:
- compatible = "hisilicon,hip01-ca9x2";
HiP04 D01 Board
Required root node properties:
- compatible = "hisilicon,hip04-d01";
HiP05 D02 Board
Required root node properties:
- compatible = "hisilicon,hip05-d02";
HiP06 D03 Board
Required root node properties:
- compatible = "hisilicon,hip06-d03";
HiP07 D05 Board
Required root node properties:
- compatible = "hisilicon,hip07-d05";
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>;
};
-----------------------------------------------------------------------
Hisilicon Hi3798CV200 Peripheral Controller
The Hi3798CV200 Peripheral Controller controls peripherals, queries
their status, and configures some functions of peripherals.
Required properties:
- compatible: Should contain "hisilicon,hi3798cv200-perictrl", "syscon"
and "simple-mfd".
- reg: Register address and size of Peripheral Controller.
- #address-cells: Should be 1.
- #size-cells: Should be 1.
Examples:
perictrl: peripheral-controller@8a20000 {
compatible = "hisilicon,hi3798cv200-perictrl", "syscon",
"simple-mfd";
reg = <0x8a20000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
};
-----------------------------------------------------------------------
Hisilicon Hi6220 system controller
Required properties:
- compatible : "hisilicon,hi6220-sysctrl"
- reg : Register address and size
- #clock-cells: should be set to 1, many clock registers are defined
under this controller and this property must be present.
Hisilicon designs this controller as one of the system controllers,
its main functions are the same as Hisilicon system controller, but
the register offset of some core modules are different.
Example:
/*for Hi6220*/
sys_ctrl: sys_ctrl@f7030000 {
compatible = "hisilicon,hi6220-sysctrl", "syscon";
reg = <0x0 0xf7030000 0x0 0x2000>;
#clock-cells = <1>;
};
Hisilicon Hi6220 Power Always ON domain controller
Required properties:
- compatible : "hisilicon,hi6220-aoctrl"
- reg : Register address and size
- #clock-cells: should be set to 1, many clock registers are defined
under this controller and this property must be present.
Hisilicon designs this system controller to control the power always
on domain for mobile platform.
Example:
/*for Hi6220*/
ao_ctrl: ao_ctrl@f7800000 {
compatible = "hisilicon,hi6220-aoctrl", "syscon";
reg = <0x0 0xf7800000 0x0 0x2000>;
#clock-cells = <1>;
};
Hisilicon Hi6220 Media domain controller
Required properties:
- compatible : "hisilicon,hi6220-mediactrl"
- reg : Register address and size
- #clock-cells: should be set to 1, many clock registers are defined
under this controller and this property must be present.
Hisilicon designs this system controller to control the multimedia
domain(e.g. codec, G3D ...) for mobile platform.
Example:
/*for Hi6220*/
media_ctrl: media_ctrl@f4410000 {
compatible = "hisilicon,hi6220-mediactrl", "syscon";
reg = <0x0 0xf4410000 0x0 0x1000>;
#clock-cells = <1>;
};
Hisilicon Hi6220 Power Management domain controller
Required properties:
- compatible : "hisilicon,hi6220-pmctrl"
- reg : Register address and size
- #clock-cells: should be set to 1, some clock registers are define
under this controller and this property must be present.
Hisilicon designs this system controller to control the power management
domain for mobile platform.
Example:
/*for Hi6220*/
pm_ctrl: pm_ctrl@f7032000 {
compatible = "hisilicon,hi6220-pmctrl", "syscon";
reg = <0x0 0xf7032000 0x0 0x1000>;
#clock-cells = <1>;
};
Hisilicon Hi6220 SRAM controller
Required properties:
- compatible : "hisilicon,hi6220-sramctrl", "syscon"
- reg : Register address and size
Hisilicon's SoCs use sram for multiple purpose; on Hi6220 there have several
SRAM banks for power management, modem, security, etc. Further, use "syscon"
managing the common sram which can be shared by multiple modules.
Example:
/*for Hi6220*/
sram: sram@fff80000 {
compatible = "hisilicon,hi6220-sramctrl", "syscon";
reg = <0x0 0xfff80000 0x0 0x12000>;
};
-----------------------------------------------------------------------
Hisilicon HiP01 system controller
Required properties:
- compatible : "hisilicon,hip01-sysctrl"
- reg : Register address and size
The HiP01 system controller is mostly compatible with hisilicon
system controller,but it has some specific control registers for
HIP01 SoC family, such as slave core boot, and also some same
registers located at different offset.
Example:
/* for hip01-ca9x2 */
sysctrl: system-controller@10000000 {
compatible = "hisilicon,hip01-sysctrl", "hisilicon,sysctrl";
reg = <0x10000000 0x1000>;
reboot-offset = <0x4>;
};
-----------------------------------------------------------------------
Hisilicon HiP05/HiP06 PCIe-SAS sub system controller
Required properties:
- compatible : "hisilicon,pcie-sas-subctrl", "syscon";
- reg : Register address and size
The PCIe-SAS sub system controller is shared by PCIe and SAS controllers in
HiP05 or HiP06 Soc to implement some basic configurations.
Example:
/* for HiP05 PCIe-SAS sub system */
pcie_sas: system_controller@b0000000 {
compatible = "hisilicon,pcie-sas-subctrl", "syscon";
reg = <0xb0000000 0x10000>;
};
Hisilicon HiP05/HiP06 PERI sub system controller
Required properties:
- compatible : "hisilicon,peri-subctrl", "syscon";
- reg : Register address and size
The PERI sub system controller is shared by peripheral controllers in
HiP05 or HiP06 Soc to implement some basic configurations. The peripheral
controllers include mdio, ddr, iic, uart, timer and so on.
Example:
/* for HiP05 sub peri system */
peri_c_subctrl: syscon@80000000 {
compatible = "hisilicon,peri-subctrl", "syscon";
reg = <0x0 0x80000000 0x0 0x10000>;
};
Hisilicon HiP05/HiP06 DSA sub system controller
Required properties:
- compatible : "hisilicon,dsa-subctrl", "syscon";
- reg : Register address and size
The DSA sub system controller is shared by peripheral controllers in
HiP05 or HiP06 Soc to implement some basic configurations.
Example:
/* for HiP05 dsa sub system */
pcie_sas: system_controller@a0000000 {
compatible = "hisilicon,dsa-subctrl", "syscon";
reg = <0xa0000000 0x10000>;
};
-----------------------------------------------------------------------
Hisilicon CPU controller
Required properties:
- compatible : "hisilicon,cpuctrl"
- reg : Register address and size
The clock registers and power registers of secondary cores are defined
in CPU controller, especially in HIX5HD2 SoC.
-----------------------------------------------------------------------
PCTRL: Peripheral misc control register
Required Properties:
- compatible: "hisilicon,pctrl"
- reg: Address and size of pctrl.
Example:
/* for Hi3620 */
pctrl: pctrl@fca09000 {
compatible = "hisilicon,pctrl";
reg = <0xfca09000 0x1000>;
};
-----------------------------------------------------------------------
Fabric:
Required Properties:
- compatible: "hisilicon,hip04-fabric";
- reg: Address and size of Fabric
-----------------------------------------------------------------------
Bootwrapper boot method (software protocol on SMP):
Required Properties:
- compatible: "hisilicon,hip04-bootwrapper";
- boot-method: Address and size of boot method.
[0]: bootwrapper physical address
[1]: bootwrapper size
[2]: relocation physical address
[3]: relocation size

22
Documentation/devicetree/bindings/arm/i2se.txt
View File

@ -1,22 +0,0 @@
I2SE Device Tree Bindings
-------------------------
Duckbill Board
Required root node properties:
- compatible = "i2se,duckbill", "fsl,imx28";
Duckbill 2 Board
Required root node properties:
- compatible = "i2se,duckbill-2", "fsl,imx28";
Duckbill 2 485 Board
Required root node properties:
- compatible = "i2se,duckbill-2-485", "i2se,duckbill-2", "fsl,imx28";
Duckbill 2 EnOcean Board
Required root node properties:
- compatible = "i2se,duckbill-2-enocean", "i2se,duckbill-2", "fsl,imx28";
Duckbill 2 SPI Board
Required root node properties:
- compatible = "i2se,duckbill-2-spi", "i2se,duckbill-2", "fsl,imx28";

699
Documentation/devicetree/bindings/arm/idle-states.txt
View File

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

26
Documentation/devicetree/bindings/arm/juno,scpi.txt
View File

@ -1,26 +0,0 @@
System Control and Power Interface (SCPI) Message Protocol
(in addition to the standard binding in [0])
Juno SRAM and Shared Memory for SCPI
------------------------------------
Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
shared memory on Juno platforms
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
Required properties:
- compatible : should be "arm,scpi-sensors".
- #thermal-sensor-cells: should be set to 1.
For Juno R0 and Juno R1 refer to [1] for the
sensor identifiers
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html

42
Documentation/devicetree/bindings/arm/keystone/keystone.txt
View File

@ -1,42 +0,0 @@
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.
SoC families:
- Keystone 2 generic SoC:
compatible = "ti,keystone"
SoCs:
- Keystone 2 Hawking/Kepler
compatible = "ti,k2hk", "ti,keystone"
- Keystone 2 Lamarr
compatible = "ti,k2l", "ti,keystone"
- Keystone 2 Edison
compatible = "ti,k2e", "ti,keystone"
- K2G
compatible = "ti,k2g", "ti,keystone"
Boards:
- Keystone 2 Hawking/Kepler EVM
compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone"
- Keystone 2 Lamarr EVM
compatible = "ti,k2l-evm", "ti, k2l", "ti,keystone"
- Keystone 2 Edison EVM
compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"
- K2G EVM
compatible = "ti,k2g-evm", "ti,k2g", "ti-keystone"
- K2G Industrial Communication Engine EVM
compatible = "ti,k2g-ice", "ti,k2g", "ti-keystone"

81
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
View File

@ -1,81 +0,0 @@
Texas Instruments System Control Interface (TI-SCI) Message Protocol
--------------------------------------------------------------------
Texas Instrument's processors including those belonging to Keystone generation
of processors have separate hardware entity which is now responsible for the
management of the System on Chip (SoC) system. These include various system
level functions as well.
An example of such an SoC is K2G, which contains the system control hardware
block called Power Management Micro Controller (PMMC). This hardware block is
initialized early into boot process and provides services to Operating Systems
on multiple processors including ones running Linux.
See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
TI-SCI controller Device Node:
=============================
The TI-SCI node describes the Texas Instrument's System Controller entity node.
This parent node may optionally have additional children nodes which describe
specific functionality such as clocks, power domain, reset or additional
functionality as may be required for the SoC. This hierarchy also describes the
relationship between the TI-SCI parent node to the child node.
Required properties:
-------------------
- compatible: should be "ti,k2g-sci"
- mbox-names:
"rx" - Mailbox corresponding to receive path
"tx" - Mailbox corresponding to transmit path
- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
property should contain a phandle to the mailbox controller device
node and an args specifier that will be the phandle to the intended
sub-mailbox child node to be used for communication.
See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
about the generic mailbox controller and client driver bindings. Also see
Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
controller that is used to communicate with this System controllers.
Optional Properties:
-------------------
- reg-names:
debug_messages - Map the Debug message region
- reg: register space corresponding to the debug_messages
- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
mbox-names = "rx", "tx";
mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
<&msgmgr &msgmgr_proxy_pmmc_tx>;
reg-names = "debug_messages";
reg = <0x02921800 0x800>;
};
TI-SCI Client Device Node:
=========================
Client nodes are maintained as children of the relevant TI-SCI device node.
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
...
my_clk_node: clk_node {
...
...
};
my_pd_node: pd_node {
...
...
};
};

114
Documentation/devicetree/bindings/arm/l2c2x0.txt
View File

@ -1,114 +0,0 @@
* ARM L2 Cache Controller
ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/PL220/
PL310 and variants) based level 2 cache controller. All these various implementations
of the L2 cache controller have compatible programming models (Note 1).
Some of the properties that are just prefixed "cache-*" are taken from section
3.7.3 of the Devicetree Specification which can be found at:
https://www.devicetree.org/specifications/
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.
- arm,io-coherent : indicates that the system is operating in an hardware
I/O coherent mode. Valid only when the arm,pl310-cache compatible
string is used.
- interrupts : 1 combined interrupt.
- cache-size : specifies the size in bytes of the cache
- cache-sets : specifies the number of associativity sets of the cache
- cache-block-size : specifies the size in bytes of a cache block
- cache-line-size : specifies the size in bytes of a line in the cache,
if this is not specified, the line size is assumed to be equal to the
cache block size
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
- arm,double-linefill : Override double linefill enable setting. Enable if
non-zero, disable if zero.
- arm,double-linefill-incr : Override double linefill on INCR read. Enable
if non-zero, disable if zero.
- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
if non-zero, disable if zero.
- arm,prefetch-drop : Override prefetch drop enable setting. Enable if non-zero,
disable if zero.
- arm,prefetch-offset : Override prefetch offset value. Valid values are
0-7, 15, 23, and 31.
- arm,shared-override : The default behavior of the L220 or PL310 cache
controllers with respect to the shareable attribute is to transform "normal
memory non-cacheable transactions" into "cacheable no allocate" (for reads)
or "write through no write allocate" (for writes).
On systems where this may cause DMA buffer corruption, this property must be
specified to indicate that such transforms are precluded.
- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
will randomly hang unless outer sync operations are disabled.
- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
(forcibly enable), property absent (retain settings set by firmware)
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
<1> (forcibly enable), property absent (retain settings set by
firmware)
- arm,dynamic-clock-gating : L2 dynamic clock gating. Value: <0> (forcibly
disable), <1> (forcibly enable), property absent (OS specific behavior,
preferably retain firmware settings)
- arm,standby-mode: L2 standby mode enable. Value <0> (forcibly disable),
<1> (forcibly enable), property absent (OS specific behavior,
preferably retain firmware settings)
- arm,early-bresp-disable : Disable the CA9 optimization Early BRESP (PL310)
- arm,full-line-zero-disable : Disable the CA9 optimization Full line of zero
write (PL310)
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>;
};
Note 1: The description in this document doesn't apply to integrated L2
cache controllers as found in e.g. Cortex-A15/A7/A57/A53. These
integrated L2 controllers are assumed to be all preconfigured by
early secure boot code. Thus no need to deal with their configuration
in the kernel at all.

16
Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
View File

@ -1,16 +0,0 @@
Resume Control
--------------
Available on Marvell SOCs: 98DX3336 and 98DX4251
Required properties:
- compatible: must be "marvell,98dx3336-resume-ctrl"
- reg: Should contain resume control registers location and length
Example:
resume@20980 {
compatible = "marvell,98dx3336-resume-ctrl";
reg = <0x20980 0x10>;
};

23
Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
View File

@ -1,23 +0,0 @@
Marvell 98DX3236, 98DX3336 and 98DX4251 Platforms Device Tree Bindings
----------------------------------------------------------------------
Boards with a SoC of the Marvell 98DX3236, 98DX3336 and 98DX4251 families
shall have the following property:
Required root node property:
compatible: must contain "marvell,armadaxp-98dx3236"
In addition, boards using the Marvell 98DX3336 SoC shall have the
following property:
Required root node property:
compatible: must contain "marvell,armadaxp-98dx3336"
In addition, boards using the Marvell 98DX4251 SoC shall have the
following property:
Required root node property:
compatible: must contain "marvell,armadaxp-98dx4251"

138
Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
View File

@ -1,138 +0,0 @@
Marvell Armada AP806 System Controller
======================================
The AP806 is one of the two core HW blocks of the Marvell Armada 7K/8K
SoCs. It contains system controllers, which provide several registers
giving access to numerous features: clocks, pin-muxing and many other
SoC configuration items. This DT binding allows to describe these
system controllers.
For the top level node:
- compatible: must be: "syscon", "simple-mfd";
- reg: register area of the AP806 system controller
SYSTEM CONTROLLER 0
===================
Clocks:
-------
The Device Tree node representing the AP806 system controller provides
a number of clocks:
- 0: clock of CPU cluster 0
- 1: clock of CPU cluster 1
- 2: fixed PLL at 1200 Mhz
- 3: MSS clock, derived from the fixed PLL
Required properties:
- compatible: must be: "marvell,ap806-clock"
- #clock-cells: must be set to 1
Pinctrl:
--------
For common binding part and usage, refer to
Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt.
Required properties:
- compatible must be "marvell,ap806-pinctrl",
Available mpp pins/groups and functions:
Note: brackets (x) are not part of the mpp name for marvell,function and given
only for more detailed description in this document.
name pins functions
================================================================================
mpp0 0 gpio, sdio(clk), spi0(clk)
mpp1 1 gpio, sdio(cmd), spi0(miso)
mpp2 2 gpio, sdio(d0), spi0(mosi)
mpp3 3 gpio, sdio(d1), spi0(cs0n)
mpp4 4 gpio, sdio(d2), i2c0(sda)
mpp5 5 gpio, sdio(d3), i2c0(sdk)
mpp6 6 gpio, sdio(ds)
mpp7 7 gpio, sdio(d4), uart1(rxd)
mpp8 8 gpio, sdio(d5), uart1(txd)
mpp9 9 gpio, sdio(d6), spi0(cs1n)
mpp10 10 gpio, sdio(d7)
mpp11 11 gpio, uart0(txd)
mpp12 12 gpio, sdio(pw_off), sdio(hw_rst)
mpp13 13 gpio
mpp14 14 gpio
mpp15 15 gpio
mpp16 16 gpio
mpp17 17 gpio
mpp18 18 gpio
mpp19 19 gpio, uart0(rxd), sdio(pw_off)
GPIO:
-----
For common binding part and usage, refer to
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
Required properties:
- compatible: "marvell,armada-8k-gpio"
- offset: offset address inside the syscon block
Example:
ap_syscon: system-controller@6f4000 {
compatible = "syscon", "simple-mfd";
reg = <0x6f4000 0x1000>;
ap_clk: clock {
compatible = "marvell,ap806-clock";
#clock-cells = <1>;
};
ap_pinctrl: pinctrl {
compatible = "marvell,ap806-pinctrl";
};
ap_gpio: gpio {
compatible = "marvell,armada-8k-gpio";
offset = <0x1040>;
ngpios = <19>;
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&ap_pinctrl 0 0 19>;
};
};
SYSTEM CONTROLLER 1
===================
Thermal:
--------
For common binding part and usage, refer to
Documentation/devicetree/bindings/thermal/thermal.txt
The thermal IP can probe the temperature all around the processor. It
may feature several channels, each of them wired to one sensor.
Required properties:
- compatible: must be one of:
* marvell,armada-ap806-thermal
- reg: register range associated with the thermal functions.
Optional properties:
- #thermal-sensor-cells: shall be <1> when thermal-zones subnodes refer
to this IP and represents the channel ID. There is one sensor per
channel. O refers to the thermal IP internal channel, while positive
IDs refer to each CPU.
Example:
ap_syscon1: system-controller@6f8000 {
compatible = "syscon", "simple-mfd";
reg = <0x6f8000 0x1000>;
ap_thermal: thermal-sensor@80 {
compatible = "marvell,armada-ap806-thermal";
reg = <0x80 0x10>;
#thermal-sensor-cells = <1>;
};
};

21
Documentation/devicetree/bindings/arm/marvell/armada-370-xp-pmsu.txt
View File

@ -1,21 +0,0 @@
Power Management Service Unit(PMSU)
-----------------------------------
Available on Marvell SOCs: Armada 370, Armada 38x and Armada XP
Required properties:
- compatible: should be one of:
- "marvell,armada-370-pmsu" for Armada 370 or Armada XP
- "marvell,armada-380-pmsu" for Armada 38x
- "marvell,armada-370-xp-pmsu" was used for Armada 370/XP but is now
deprecated and will be removed
- reg: Should contain PMSU registers location and length.
Example:
armada-370-xp-pmsu@22000 {
compatible = "marvell,armada-370-pmsu";
reg = <0x22000 0x1000>;
};

24
Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
View File

@ -1,24 +0,0 @@
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"

9
Documentation/devicetree/bindings/arm/marvell/armada-375.txt
View File

@ -1,9 +0,0 @@
Marvell Armada 375 Platforms Device Tree Bindings
-------------------------------------------------
Boards with a SoC of the Marvell Armada 375 family shall have the
following property:
Required root node property:
compatible: must contain "marvell,armada375"

50
Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
View File

@ -1,50 +0,0 @@
Marvell Armada 37xx Platforms Device Tree Bindings
--------------------------------------------------
Boards using a SoC of the Marvell Armada 37xx family must carry the
following root node property:
- compatible: must contain "marvell,armada3710"
In addition, boards using the Marvell Armada 3720 SoC shall have the
following property before the previous one:
- compatible: must contain "marvell,armada3720"
Example:
compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
Power management
----------------
For power management (particularly DVFS and AVS), the North Bridge
Power Management component is needed:
Required properties:
- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
- reg : the register start and length for the North Bridge
Power Management
Example:
nb_pm: syscon@14000 {
compatible = "marvell,armada-3700-nb-pm", "syscon";
reg = <0x14000 0x60>;
}
AVS
---
For AVS an other component is needed:
Required properties:
- compatible : should contain "marvell,armada-3700-avs", "syscon";
- reg : the register start and length for the AVS
Example:
avs: avs@11500 {
compatible = "marvell,armada-3700-avs", "syscon";
reg = <0x11500 0x40>;
}

14
Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
View File

@ -1,14 +0,0 @@
Marvell Armada 38x CA9 MPcore SoC Controller
============================================
Required properties:
- compatible: Should be "marvell,armada-380-mpcore-soc-ctrl".
- reg: should be the register base and length as documented in the
datasheet for the CA9 MPcore SoC Control registers
mpcore-soc-ctrl@20d20 {
compatible = "marvell,armada-380-mpcore-soc-ctrl";
reg = <0x20d20 0x6c>;
};

27
Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
View File

@ -1,27 +0,0 @@
Marvell Armada 38x Platforms Device Tree Bindings
-------------------------------------------------
Boards with a SoC of the Marvell Armada 38x family shall have the
following property:
Required root node property:
- compatible: must contain "marvell,armada380"
In addition, boards using the Marvell Armada 385 SoC shall have the
following property before the previous one:
Required root node property:
compatible: must contain "marvell,armada385"
In addition, boards using the Marvell Armada 388 SoC shall have the
following property before the previous one:
Required root node property:
compatible: must contain "marvell,armada388"
Example:
compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";

31
Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
View File

@ -1,31 +0,0 @@
Marvell Armada 39x Platforms Device Tree Bindings
-------------------------------------------------
Boards with a SoC of the Marvell Armada 39x family shall have the
following property:
Required root node property:
- compatible: must contain "marvell,armada390"
In addition, boards using the Marvell Armada 395 SoC shall have the
following property before the common "marvell,armada390" one:
Required root node property:
compatible: must contain "marvell,armada395"
Example:
compatible = "marvell,a395-gp", "marvell,armada395", "marvell,armada390";
Boards using the Marvell Armada 398 SoC shall have the following
property before the common "marvell,armada390" one:
Required root node property:
compatible: must contain "marvell,armada398"
Example:
compatible = "marvell,a398-db", "marvell,armada398", "marvell,armada390";

24
Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
View File

@ -1,24 +0,0 @@
Marvell Armada 7K/8K Platforms Device Tree Bindings
---------------------------------------------------
Boards using a SoC of the Marvell Armada 7K or 8K families must carry
the following root node property:
- compatible, with one of the following values:
- "marvell,armada7020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
when the SoC being used is the Armada 7020
- "marvell,armada7040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
when the SoC being used is the Armada 7040
- "marvell,armada8020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
when the SoC being used is the Armada 8020
- "marvell,armada8040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
when the SoC being used is the Armada 8040
Example:
compatible = "marvell,armada7040-db", "marvell,armada7040",
"marvell,armada-ap806-quad", "marvell,armada-ap806";

15
Documentation/devicetree/bindings/arm/marvell/armada-8kp.txt
View File

@ -1,15 +0,0 @@
Marvell Armada 8KPlus Platforms Device Tree Bindings
----------------------------------------------------
Boards using a SoC of the Marvell Armada 8KP families must carry
the following root node property:
- compatible, with one of the following values:
- "marvell,armada-8080", "marvell,armada-ap810-octa", "marvell,armada-ap810"
when the SoC being used is the Armada 8080
Example:
compatible = "marvell,armada-8080-db", "marvell,armada-8080",
"marvell,armada-ap810-octa", "marvell,armada-ap810"

14
Documentation/devicetree/bindings/arm/marvell/armada-cpu-reset.txt
View File

@ -1,14 +0,0 @@
Marvell Armada CPU reset controller
===================================
Required properties:
- compatible: Should be "marvell,armada-370-cpu-reset".
- reg: should be register base and length as documented in the
datasheet for the CPU reset registers
cpurst: cpurst@20800 {
compatible = "marvell,armada-370-cpu-reset";
reg = <0x20800 0x20>;
};

48
Documentation/devicetree/bindings/arm/marvell/coherency-fabric.txt
View File

@ -1,48 +0,0 @@
Coherency fabric
----------------
Available on Marvell SOCs: Armada 370, Armada 375, Armada 38x and Armada XP
Required properties:
- compatible: the possible values are:
* "marvell,coherency-fabric", to be used for the coherency fabric of
the Armada 370 and Armada XP.
* "marvell,armada-375-coherency-fabric", for the Armada 375 coherency
fabric.
* "marvell,armada-380-coherency-fabric", for the Armada 38x coherency
fabric.
- reg: Should contain coherency fabric registers location and
length.
* For "marvell,coherency-fabric", the first pair for the coherency
fabric registers, second pair for the per-CPU fabric registers.
* For "marvell,armada-375-coherency-fabric", only one pair is needed
for the per-CPU fabric registers.
* For "marvell,armada-380-coherency-fabric", only one pair is needed
for the per-CPU fabric registers.
Optional properties:
- broken-idle: boolean to set when the Idle mode is not supported by the
hardware.
Examples:
coherency-fabric@d0020200 {
compatible = "marvell,coherency-fabric";
reg = <0xd0020200 0xb0>,
<0xd0021810 0x1c>;
};
coherency-fabric@21810 {
compatible = "marvell,armada-375-coherency-fabric";
reg = <0x21810 0x1c>;
};

225
Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
View File

@ -1,225 +0,0 @@
Marvell Armada CP110 System Controller
======================================
The CP110 is one of the two core HW blocks of the Marvell Armada 7K/8K
SoCs. It contains system controllers, which provide several registers
giving access to numerous features: clocks, pin-muxing and many other
SoC configuration items. This DT binding allows to describe these
system controllers.
For the top level node:
- compatible: must be: "syscon", "simple-mfd";
- reg: register area of the CP110 system controller
SYSTEM CONTROLLER 0
===================
Clocks:
-------
The Device Tree node representing this System Controller 0 provides a
number of clocks:
- a set of core clocks
- a set of gatable clocks
Those clocks can be referenced by other Device Tree nodes using two
cells:
- The first cell must be 0 or 1. 0 for the core clocks and 1 for the
gatable clocks.
- The second cell identifies the particular core clock or gatable
clocks.
The following clocks are available:
- Core clocks
- 0 0 APLL
- 0 1 PPv2 core
- 0 2 EIP
- 0 3 Core
- 0 4 NAND core
- 0 5 SDIO core
- Gatable clocks
- 1 0 Audio
- 1 1 Comm Unit
- 1 2 NAND
- 1 3 PPv2
- 1 4 SDIO
- 1 5 MG Domain
- 1 6 MG Core
- 1 7 XOR1
- 1 8 XOR0
- 1 9 GOP DP
- 1 11 PCIe x1 0
- 1 12 PCIe x1 1
- 1 13 PCIe x4
- 1 14 PCIe / XOR
- 1 15 SATA
- 1 16 SATA USB
- 1 17 Main
- 1 18 SD/MMC/GOP
- 1 21 Slow IO (SPI, NOR, BootROM, I2C, UART)
- 1 22 USB3H0
- 1 23 USB3H1
- 1 24 USB3 Device
- 1 25 EIP150
- 1 26 EIP197
Required properties:
- compatible: must be:
"marvell,cp110-clock"
- #clock-cells: must be set to 2
Pinctrl:
--------
For common binding part and usage, refer to the file
Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt.
Required properties:
- compatible: "marvell,armada-7k-pinctrl",
"marvell,armada-8k-cpm-pinctrl" or "marvell,armada-8k-cps-pinctrl"
depending on the specific variant of the SoC being used.
Available mpp pins/groups and functions:
Note: brackets (x) are not part of the mpp name for marvell,function and given
only for more detailed description in this document.
name pins functions
================================================================================
mpp0 0 gpio, dev(ale1), au(i2smclk), ge0(rxd3), tdm(pclk), ptp(pulse), mss_i2c(sda), uart0(rxd), sata0(present_act), ge(mdio)
mpp1 1 gpio, dev(ale0), au(i2sdo_spdifo), ge0(rxd2), tdm(drx), ptp(clk), mss_i2c(sck), uart0(txd), sata1(present_act), ge(mdc)
mpp2 2 gpio, dev(ad15), au(i2sextclk), ge0(rxd1), tdm(dtx), mss_uart(rxd), ptp(pclk_out), i2c1(sck), uart1(rxd), sata0(present_act), xg(mdc)
mpp3 3 gpio, dev(ad14), au(i2slrclk), ge0(rxd0), tdm(fsync), mss_uart(txd), pcie(rstoutn), i2c1(sda), uart1(txd), sata1(present_act), xg(mdio)
mpp4 4 gpio, dev(ad13), au(i2sbclk), ge0(rxctl), tdm(rstn), mss_uart(rxd), uart1(cts), pcie0(clkreq), uart3(rxd), ge(mdc)
mpp5 5 gpio, dev(ad12), au(i2sdi), ge0(rxclk), tdm(intn), mss_uart(txd), uart1(rts), pcie1(clkreq), uart3(txd), ge(mdio)
mpp6 6 gpio, dev(ad11), ge0(txd3), spi0(csn2), au(i2sextclk), sata1(present_act), pcie2(clkreq), uart0(rxd), ptp(pulse)
mpp7 7 gpio, dev(ad10), ge0(txd2), spi0(csn1), spi1(csn1), sata0(present_act), led(data), uart0(txd), ptp(clk)
mpp8 8 gpio, dev(ad9), ge0(txd1), spi0(csn0), spi1(csn0), uart0(cts), led(stb), uart2(rxd), ptp(pclk_out), synce1(clk)
mpp9 9 gpio, dev(ad8), ge0(txd0), spi0(mosi), spi1(mosi), pcie(rstoutn), synce2(clk)
mpp10 10 gpio, dev(readyn), ge0(txctl), spi0(miso), spi1(miso), uart0(cts), sata1(present_act)
mpp11 11 gpio, dev(wen1), ge0(txclkout), spi0(clk), spi1(clk), uart0(rts), led(clk), uart2(txd), sata0(present_act)
mpp12 12 gpio, dev(clk_out), nf(rbn1), spi1(csn1), ge0(rxclk)
mpp13 13 gpio, dev(burstn), nf(rbn0), spi1(miso), ge0(rxctl), mss_spi(miso)
mpp14 14 gpio, dev(bootcsn), dev(csn0), spi1(csn0), spi0(csn3), au(i2sextclk), spi0(miso), sata0(present_act), mss_spi(csn)
mpp15 15 gpio, dev(ad7), spi1(mosi), spi0(mosi), mss_spi(mosi), ptp(pulse_cp2cp)
mpp16 16 gpio, dev(ad6), spi1(clk), mss_spi(clk)
mpp17 17 gpio, dev(ad5), ge0(txd3)
mpp18 18 gpio, dev(ad4), ge0(txd2), ptp(clk_cp2cp)
mpp19 19 gpio, dev(ad3), ge0(txd1), wakeup(out_cp2cp)
mpp20 20 gpio, dev(ad2), ge0(txd0)
mpp21 21 gpio, dev(ad1), ge0(txctl), sei(in_cp2cp)
mpp22 22 gpio, dev(ad0), ge0(txclkout), wakeup(in_cp2cp)
mpp23 23 gpio, dev(a1), au(i2smclk), link(rd_in_cp2cp)
mpp24 24 gpio, dev(a0), au(i2slrclk)
mpp25 25 gpio, dev(oen), au(i2sdo_spdifo)
mpp26 26 gpio, dev(wen0), au(i2sbclk)
mpp27 27 gpio, dev(csn0), spi1(miso), mss_gpio4, ge0(rxd3), spi0(csn4), ge(mdio), sata0(present_act), uart0(rts), rei(in_cp2cp)
mpp28 28 gpio, dev(csn1), spi1(csn0), mss_gpio5, ge0(rxd2), spi0(csn5), pcie2(clkreq), ptp(pulse), ge(mdc), sata1(present_act), uart0(cts), led(data)
mpp29 29 gpio, dev(csn2), spi1(mosi), mss_gpio6, ge0(rxd1), spi0(csn6), pcie1(clkreq), ptp(clk), mss_i2c(sda), sata0(present_act), uart0(rxd), led(stb)
mpp30 30 gpio, dev(csn3), spi1(clk), mss_gpio7, ge0(rxd0), spi0(csn7), pcie0(clkreq), ptp(pclk_out), mss_i2c(sck), sata1(present_act), uart0(txd), led(clk)
mpp31 31 gpio, dev(a2), mss_gpio4, pcie(rstoutn), ge(mdc)
mpp32 32 gpio, mii(col), mii(txerr), mss_spi(miso), tdm(drx), au(i2sextclk), au(i2sdi), ge(mdio), sdio(v18_en), pcie1(clkreq), mss_gpio0
mpp33 33 gpio, mii(txclk), sdio(pwr10), mss_spi(csn), tdm(fsync), au(i2smclk), sdio(bus_pwr), xg(mdio), pcie2(clkreq), mss_gpio1
mpp34 34 gpio, mii(rxerr), sdio(pwr11), mss_spi(mosi), tdm(dtx), au(i2slrclk), sdio(wr_protect), ge(mdc), pcie0(clkreq), mss_gpio2
mpp35 35 gpio, sata1(present_act), i2c1(sda), mss_spi(clk), tdm(pclk), au(i2sdo_spdifo), sdio(card_detect), xg(mdio), ge(mdio), pcie(rstoutn), mss_gpio3
mpp36 36 gpio, synce2(clk), i2c1(sck), ptp(clk), synce1(clk), au(i2sbclk), sata0(present_act), xg(mdc), ge(mdc), pcie2(clkreq), mss_gpio5
mpp37 37 gpio, uart2(rxd), i2c0(sck), ptp(pclk_out), tdm(intn), mss_i2c(sck), sata1(present_act), ge(mdc), xg(mdc), pcie1(clkreq), mss_gpio6, link(rd_out_cp2cp)
mpp38 38 gpio, uart2(txd), i2c0(sda), ptp(pulse), tdm(rstn), mss_i2c(sda), sata0(present_act), ge(mdio), xg(mdio), au(i2sextclk), mss_gpio7, ptp(pulse_cp2cp)
mpp39 39 gpio, sdio(wr_protect), au(i2sbclk), ptp(clk), spi0(csn1), sata1(present_act), mss_gpio0
mpp40 40 gpio, sdio(pwr11), synce1(clk), mss_i2c(sda), au(i2sdo_spdifo), ptp(pclk_out), spi0(clk), uart1(txd), ge(mdio), sata0(present_act), mss_gpio1
mpp41 41 gpio, sdio(pwr10), sdio(bus_pwr), mss_i2c(sck), au(i2slrclk), ptp(pulse), spi0(mosi), uart1(rxd), ge(mdc), sata1(present_act), mss_gpio2, rei(out_cp2cp)
mpp42 42 gpio, sdio(v18_en), sdio(wr_protect), synce2(clk), au(i2smclk), mss_uart(txd), spi0(miso), uart1(cts), xg(mdc), sata0(present_act), mss_gpio4
mpp43 43 gpio, sdio(card_detect), synce1(clk), au(i2sextclk), mss_uart(rxd), spi0(csn0), uart1(rts), xg(mdio), sata1(present_act), mss_gpio5, wakeup(out_cp2cp)
mpp44 44 gpio, ge1(txd2), uart0(rts), ptp(clk_cp2cp)
mpp45 45 gpio, ge1(txd3), uart0(txd), pcie(rstoutn)
mpp46 46 gpio, ge1(txd1), uart1(rts)
mpp47 47 gpio, ge1(txd0), spi1(clk), uart1(txd), ge(mdc)
mpp48 48 gpio, ge1(txctl_txen), spi1(mosi), xg(mdc), wakeup(in_cp2cp)
mpp49 49 gpio, ge1(txclkout), mii(crs), spi1(miso), uart1(rxd), ge(mdio), pcie0(clkreq), sdio(v18_en), sei(out_cp2cp)
mpp50 50 gpio, ge1(rxclk), mss_i2c(sda), spi1(csn0), uart2(txd), uart0(rxd), xg(mdio), sdio(pwr11)
mpp51 51 gpio, ge1(rxd0), mss_i2c(sck), spi1(csn1), uart2(rxd), uart0(cts), sdio(pwr10)
mpp52 52 gpio, ge1(rxd1), synce1(clk), synce2(clk), spi1(csn2), uart1(cts), led(clk), pcie(rstoutn), pcie0(clkreq)
mpp53 53 gpio, ge1(rxd2), ptp(clk), spi1(csn3), uart1(rxd), led(stb), sdio(led)
mpp54 54 gpio, ge1(rxd3), synce2(clk), ptp(pclk_out), synce1(clk), led(data), sdio(hw_rst), sdio(wr_protect)
mpp55 55 gpio, ge1(rxctl_rxdv), ptp(pulse), sdio(led), sdio(card_detect)
mpp56 56 gpio, tdm(drx), au(i2sdo_spdifo), spi0(clk), uart1(rxd), sata1(present_act), sdio(clk)
mpp57 57 gpio, mss_i2c(sda), ptp(pclk_out), tdm(intn), au(i2sbclk), spi0(mosi), uart1(txd), sata0(present_act), sdio(cmd)
mpp58 58 gpio, mss_i2c(sck), ptp(clk), tdm(rstn), au(i2sdi), spi0(miso), uart1(cts), led(clk), sdio(d0)
mpp59 59 gpio, mss_gpio7, synce2(clk), tdm(fsync), au(i2slrclk), spi0(csn0), uart0(cts), led(stb), uart1(txd), sdio(d1)
mpp60 60 gpio, mss_gpio6, ptp(pulse), tdm(dtx), au(i2smclk), spi0(csn1), uart0(rts), led(data), uart1(rxd), sdio(d2)
mpp61 61 gpio, mss_gpio5, ptp(clk), tdm(pclk), au(i2sextclk), spi0(csn2), uart0(txd), uart2(txd), sata1(present_act), ge(mdio), sdio(d3)
mpp62 62 gpio, mss_gpio4, synce1(clk), ptp(pclk_out), sata1(present_act), spi0(csn3), uart0(rxd), uart2(rxd), sata0(present_act), ge(mdc)
GPIO:
-----
For common binding part and usage, refer to
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
Required properties:
- compatible: "marvell,armada-8k-gpio"
- offset: offset address inside the syscon block
Example:
CP110_LABEL(syscon0): system-controller@440000 {
compatible = "syscon", "simple-mfd";
reg = <0x440000 0x1000>;
CP110_LABEL(clk): clock {
compatible = "marvell,cp110-clock";
#clock-cells = <2>;
};
CP110_LABEL(pinctrl): pinctrl {
compatible = "marvell,armada-8k-cpm-pinctrl";
};
CP110_LABEL(gpio1): gpio@100 {
compatible = "marvell,armada-8k-gpio";
offset = <0x100>;
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&CP110_LABEL(pinctrl) 0 0 32>;
};
};
SYSTEM CONTROLLER 1
===================
Thermal:
--------
The thermal IP can probe the temperature all around the processor. It
may feature several channels, each of them wired to one sensor.
For common binding part and usage, refer to
Documentation/devicetree/bindings/thermal/thermal.txt
Required properties:
- compatible: must be one of:
* marvell,armada-cp110-thermal
- reg: register range associated with the thermal functions.
Optional properties:
- #thermal-sensor-cells: shall be <1> when thermal-zones subnodes refer
to this IP and represents the channel ID. There is one sensor per
channel. O refers to the thermal IP internal channel.
Example:
CP110_LABEL(syscon1): system-controller@6f8000 {
compatible = "syscon", "simple-mfd";
reg = <0x6f8000 0x1000>;
CP110_LABEL(thermal): thermal-sensor@70 {
compatible = "marvell,armada-cp110-thermal";
reg = <0x70 0x10>;
#thermal-sensor-cells = <1>;
};
};

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