xiaomi-unicorn2/android_kernel_xiaomi_sm8450-devicetrees
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

bindings: Merge android-mainline (cbf07d5) into msm-waipio

Browse Source 
Merge snapshot of bindings from android-mainline commit cbf07d5
("FROMLIST: clk: sunxi-ng: add support for the Allwinner A100 CCU").

Change-Id: Ica9bc8abf055fb28bdcd33dad244e3ba5fe1a04b
This commit is contained in:
Elliot Berman
2020-09-08 21:08:35 -07:00
parent 49a6419f62
commit b54d17c2f5
1494 changed files with 48786 additions and 33604 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
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.

38
bindings/arm/actions.yaml Normal file
View File

@@ -0,0 +1,38 @@
# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/actions.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Actions Semi platforms device tree bindings
maintainers:
- Andreas Färber <afaerber@suse.de>
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
properties:
compatible:
oneOf:
# The Actions Semi S500 is a quad-core ARM Cortex-A9 SoC.
- items:
- enum:
- allo,sparky # Allo.com Sparky
- cubietech,cubieboard6 # Cubietech CubieBoard6
- const: actions,s500
- items:
- enum:
- lemaker,guitar-bb-rev-b # LeMaker Guitar Base Board rev. B
- const: lemaker,guitar
- const: actions,s500
# The Actions Semi S700 is a quad-core ARM Cortex-A53 SoC.
- items:
- enum:
- cubietech,cubieboard7 # Cubietech CubieBoard7
- const: actions,s700
# The Actions Semi S900 is a quad-core ARM Cortex-A53 SoC.
- items:
- enum:
- ucrobotics,bubblegum-96 # uCRobotics Bubblegum-96
- const: actions,s900

4
bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
View File

@@ -25,7 +25,7 @@ select:
properties:
compatible:
items:
items:
- const: amlogic,meson-gx-ao-secure
- const: syscon
@@ -43,6 +43,8 @@ required:
- compatible
- reg
additionalProperties: false
examples:
- |
ao-secure@140 {

32
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>;
};
};

86
bindings/arm/arm,integrator.yaml Normal file
View File

@@ -0,0 +1,86 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,integrator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Integrator Boards Device Tree Bindings
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
These were the first ARM platforms officially supported by ARM Ltd.
They are ARMv4, ARMv5 and ARMv6-capable using different core tiles,
so the system is modular and can host a variety of CPU tiles called
"core tiles" and referred to in the device tree as "core modules".
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: ARM Integrator Application Platform, this board has a PCI
host and several PCI slots, as well as a number of slots for logical
expansion modules, it is referred to as an "ASIC Development
Motherboard" and is extended with custom FPGA and is intended for
rapid prototyping. See ARM DUI 0098B. This board can physically come
pre-packaged in a PC Tower form factor called Integrator/PP1 or a
special metal fixture called Integrator/PP2, see ARM DUI 0169A.
items:
- const: arm,integrator-ap
- description: ARM Integrator Compact Platform (HBI-0086), this board has
a compact form factor and mainly consists of the bare minimum
peripherals to make use of the core module. See ARM DUI 0159B.
items:
- const: arm,integrator-cp
- description: ARM Integrator Standard Development Board (SDB) Platform,
this board is a PCI-based board conforming to the Microsoft SDB
(HARP) specification. See ARM DUI 0099A.
items:
- const: arm,integrator-sp
core-module@10000000:
type: object
description: the root node in the Integrator platforms must contain
a core module child node. They are always at physical address
0x10000000 in all the Integrator variants.
properties:
compatible:
items:
- const: arm,core-module-integrator
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
required:
- compatible
- reg
patternProperties:
"^syscon@[0-9a-f]+$":
description: All Integrator boards must provide a system controller as a
node in the root of the device tree.
type: object
properties:
compatible:
items:
- enum:
- arm,integrator-ap-syscon
- arm,integrator-cp-syscon
- arm,integrator-sp-syscon
- const: syscon
reg:
maxItems: 1
required:
- compatible
- reg
required:
- compatible
- core-module@10000000
...

123
bindings/arm/arm,realview.yaml Normal file
View File

@@ -0,0 +1,123 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,realview.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM RealView Boards Device Tree Bindings
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
The ARM RealView series of reference designs were built to explore the ARM
11, Cortex A-8 and Cortex A-9 CPUs. This included new features compared to
the earlier CPUs such as TrustZone and multicore (MPCore).
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: ARM RealView Emulation Baseboard (HBI-0140) was created
as a generic platform to test different FPGA designs, and has
pluggable CPU modules, see ARM DUI 0303E.
items:
- const: arm,realview-eb
- description: ARM RealView Platform Baseboard for ARM1176JZF-S
(HBI-0147) was created as a development board to test ARM TrustZone,
CoreSight and Intelligent Energy Management (IEM) see ARM DUI 0425F.
items:
- const: arm,realview-pb1176
- description: ARM RealView Platform Baseboard for ARM 11 MPCore
(HBI-0159, HBI-0175 and HBI-0176) was created to showcase
multiprocessing with ARM11 using MPCore using symmetric
multiprocessing (SMP). See ARM DUI 0351E.
items:
- const: arm,realview-pb11mp
- description: ARM RealView Platform Baseboard for Cortex-A8 (HBI-0178,
HBI-0176 and HBI-0175) was the first reference platform for the
Cortex CPU family, including a Cortex-A8 test chip.
items:
- const: arm,realview-pba8
- description: ARM RealView Platform Baseboard Explore for Cortex-A9
(HBI-0182 and HBI-0183) was the reference platform for the Cortex-A9
CPU.
items:
- const: arm,realview-pbx
soc:
description: All RealView boards must provide a soc node in the root of the
device tree, representing the System-on-Chip since these test chips are
rather complex.
type: object
properties:
compatible:
oneOf:
- items:
- const: arm,realview-eb-soc
- const: simple-bus
- items:
- const: arm,realview-pb1176-soc
- const: simple-bus
- items:
- const: arm,realview-pb11mp-soc
- const: simple-bus
- items:
- const: arm,realview-pba8-soc
- const: simple-bus
- items:
- const: arm,realview-pbx-soc
- const: simple-bus
patternProperties:
"^.*syscon@[0-9a-f]+$":
type: object
description: All RealView boards must provide a syscon system controller
node inside the soc node.
properties:
compatible:
oneOf:
- items:
- const: arm,realview-eb11mp-revb-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-eb11mp-revc-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pb1176-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pb11mp-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pba8-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pbx-syscon
- const: syscon
- const: simple-mfd
required:
- compatible
- reg
required:
- compatible
required:
- compatible
- soc
...

7
bindings/arm/arm,scmi.txt
View File

@@ -14,7 +14,7 @@ Required properties:
The scmi node with the following properties shall be under the /firmware/ node.
- compatible : shall be "arm,scmi"
- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports
- 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
@@ -25,6 +25,7 @@ The scmi node with the following properties shall be under the /firmware/ node.
protocol identifier for a given sub-node.
- #size-cells : should be '0' as 'reg' property doesn't have any size
associated with it.
- arm,smc-id : SMC id required when using smc or hvc transports
Optional properties:
@@ -101,8 +102,8 @@ Required sub-node properties:
[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.yaml
[3] Documentation/devicetree/bindings/thermal/thermal.txt
[4] Documentation/devicetree/bindings/sram/sram.txt
[3] Documentation/devicetree/bindings/thermal/thermal*.yaml
[4] Documentation/devicetree/bindings/sram/sram.yaml
[5] Documentation/devicetree/bindings/reset/reset.txt
Example:

4
bindings/arm/arm,scpi.txt
View File

@@ -108,8 +108,8 @@ Required properties:
[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
[2] Documentation/devicetree/bindings/thermal/thermal*.yaml
[3] Documentation/devicetree/bindings/sram/sram.yaml
[4] Documentation/devicetree/bindings/power/power-domain.yaml
Example:

71
bindings/arm/arm,versatile.yaml Normal file
View File

@@ -0,0 +1,71 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,versatile.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Boards Device Tree Bindings
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
The ARM Versatile boards are two variants of ARM926EJ-S evaluation boards
with various pluggable interface boards, in essence the Versatile PB version
is a superset of the Versatile AB version.
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: The ARM Versatile Application Baseboard (HBI-0118) is an
evaluation board specifically for the ARM926EJ-S. It can be connected
to an IB1 interface board for a touchscreen-type use case or an IB2
for a candybar phone-type use case. See ARM DUI 0225D.
items:
- const: arm,versatile-ab
- description: The ARM Versatile Platform Baseboard (HBI-0117) is an
extension of the Versatile Application Baseboard that includes a
PCI host controller. Like the sibling board, it is done specifically
for ARM926EJ-S. See ARM DUI 0224B.
items:
- const: arm,versatile-pb
core-module@10000000:
type: object
description: the root node in the Versatile platforms must contain
a core module child node. They are always at physical address
0x10000000 in all the Versatile variants.
properties:
compatible:
items:
- const: arm,core-module-versatile
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
required:
- compatible
- reg
patternProperties:
"^syscon@[0-9a-f]+$":
type: object
description: When fitted with the IB2 Interface Board, the Versatile
AB will present an optional system controller node which controls the
extra peripherals on the interface board.
properties:
compatible:
contains:
const: arm,versatile-ib2-syscon
required:
- compatible
- reg
required:
- compatible
- core-module@10000000
...

219
bindings/arm/arm,vexpress-juno.yaml Normal file
View File

@@ -0,0 +1,219 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,vexpress-juno.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Express and Juno Boards Device Tree Bindings
maintainers:
- Sudeep Holla <sudeep.holla@arm.com>
- Linus Walleij <linus.walleij@linaro.org>
description: |+
ARM's Versatile Express platform were built as reference designs for exploring
multicore Cortex-A class systems. The Versatile Express family contains both
32 bit (Aarch32) and 64 bit (Aarch64) systems.
The board consist of a motherboard and one or more daughterboards (tiles). The
motherboard provides a set of peripherals. Processor and RAM "live" on the
tiles.
The motherboard and each core tile should be described by a separate Device
Tree source file, with the tile's description including the motherboard file
using an include directive. As the motherboard can be initialized in one of
two different configurations ("memory maps"), care must be taken to include
the correct one.
When a new generation of boards were introduced under the name "Juno", these
shared to many common characteristics with the Versatile Express that the
"arm,vexpress" compatible was retained in the root node, and these are
included in this binding schema as well.
The root node indicates the CPU SoC on the core tile, and this
is a daughterboard to the main motherboard. The name used in the compatible
string shall match the name given in the core tile's technical reference
manual, followed by "arm,vexpress" as an additional compatible value. If
further subvariants are released of the core tile, even more fine-granular
compatible strings with up to three compatible strings are used.
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: CoreTile Express A9x4 (V2P-CA9) has 4 Cortex A9 CPU cores
in MPCore configuration in a test chip on the core tile. See ARM
DUI 0448I. This was the first Versatile Express platform.
items:
- const: arm,vexpress,v2p-ca9
- const: arm,vexpress
- description: CoreTile Express A5x2 (V2P-CA5s) has 2 Cortex A5 CPU cores
in a test chip on the core tile. It is intended to evaluate NEON, FPU
and Jazelle support in the Cortex A5 family. See ARM DUI 0541C.
items:
- const: arm,vexpress,v2p-ca5s
- const: arm,vexpress
- description: Coretile Express A15x2 (V2P-CA15) has 2 Cortex A15 CPU
cores in a MPCore configuration in a test chip on the core tile. See
ARM DUI 0604F.
items:
- const: arm,vexpress,v2p-ca15
- const: arm,vexpress
- description: CoreTile Express A15x4 (V2P-CA15, HBI-0237A) has 4 Cortex
A15 CPU cores in a test chip on the core tile. This is the first test
chip called "TC1".
items:
- const: arm,vexpress,v2p-ca15,tc1
- const: arm,vexpress,v2p-ca15
- const: arm,vexpress
- description: Coretile Express A15x2 A7x3 (V2P-CA15_A7) has 2 Cortex A15
CPU cores and 3 Cortex A7 cores in a big.LITTLE MPCore configuration
in a test chip on the core tile. See ARM DDI 0503I.
items:
- const: arm,vexpress,v2p-ca15_a7
- const: arm,vexpress
- description: LogicTile Express 20MG (V2F-1XV7) has 2 Cortex A53 CPU
cores in a test chip on the core tile. See ARM DDI 0498D.
items:
- const: arm,vexpress,v2f-1xv7,ca53x2
- const: arm,vexpress,v2f-1xv7
- const: arm,vexpress
- description: Arm Versatile Express Juno "r0" (the first Juno board,
V2M-Juno) was introduced as a vehicle for evaluating big.LITTLE on
AArch64 CPU cores. It has 2 Cortex A57 CPU cores and 4 Cortex A53
cores in a big.LITTLE configuration. It also features the MALI T624
GPU. See ARM document 100113_0000_07_en.
items:
- const: arm,juno
- const: arm,vexpress
- description: Arm Versatile Express Juno r1 Development Platform
(V2M-Juno r1) was introduced 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. Otherwise it is the
same configuration as Juno r0. See ARM document 100122_0100_06_en.
items:
- const: arm,juno-r1
- const: arm,juno
- const: arm,vexpress
- description: Arm Versatile Express Juno r2 Development Platform
(V2M-Juno r2). It has the same feature set as Juno r0 and r1. See
ARM document 100114_0200_04_en.
items:
- const: arm,juno-r2
- const: arm,juno
- const: arm,vexpress
- description: Arm AEMv8a Versatile Express Real-Time System Model
(VE RTSM) is a programmers view of the Versatile Express with Arm
v8A hardware. See ARM DUI 0575D.
items:
- const: arm,rtsm_ve,aemv8a
- const: arm,vexpress
- description: Arm FVP (Fixed Virtual Platform) base model revision C
See ARM Document 100964_1190_00_en.
items:
- const: arm,fvp-base-revc
- const: arm,vexpress
- description: Arm Foundation model for Aarch64
items:
- const: arm,foundation-aarch64
- const: arm,vexpress
arm,hbi:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: This indicates the ARM HBI (Hardware Board ID), this is
ARM's unique board model ID, visible on the PCB's silkscreen.
arm,vexpress,site:
description: As Versatile Express can be configured in number of physically
different setups, the device tree should describe platform topology.
For this reason the root node and main motherboard node must define this
property, describing the physical location of the children nodes.
0 means motherboard site, while 1 and 2 are daughterboard sites, and
0xf means "sisterboard" which is the site containing the main CPU tile.
$ref: '/schemas/types.yaml#/definitions/uint32'
minimum: 0
maximum: 15
arm,vexpress,position:
description: When daughterboards are stacked on one site, their position
in the stack be be described this attribute.
$ref: '/schemas/types.yaml#/definitions/uint32'
minimum: 0
maximum: 3
arm,vexpress,dcc:
description: When describing tiles consisting of more than one DCC, its
number can be specified with this attribute.
$ref: '/schemas/types.yaml#/definitions/uint32'
minimum: 0
maximum: 3
patternProperties:
"^bus@[0-9a-f]+$":
description: Static Memory Bus (SMB) node, if this exists it describes
the connection between the motherboard and any tiles. Sometimes the
compatible is placed directly under this node, sometimes it is placed
in a subnode named "motherboard". Sometimes the compatible includes
"arm,vexpress,v2?-p1" sometimes (on software models) is is just
"simple-bus". If the compatible is placed in the "motherboard" node,
it is stricter and always has two compatibles.
type: object
$ref: '/schemas/simple-bus.yaml'
properties:
compatible:
oneOf:
- items:
- enum:
- arm,vexpress,v2m-p1
- arm,vexpress,v2p-p1
- const: simple-bus
- const: simple-bus
motherboard:
type: object
description: The motherboard description provides a single "motherboard"
node using 2 address cells corresponding to the Static Memory Bus
used between the motherboard and the tile. The first cell defines the
Chip Select (CS) line number, the second cell address offset within
the CS. All interrupt lines between the motherboard and the tile
are active high and are described using single cell.
properties:
"#address-cells":
const: 2
"#size-cells":
const: 1
compatible:
items:
- enum:
- arm,vexpress,v2m-p1
- arm,vexpress,v2p-p1
- const: simple-bus
arm,v2m-memory-map:
description: This describes the memory map type.
$ref: '/schemas/types.yaml#/definitions/string'
enum:
- rs1
- rs2
required:
- compatible
required:
- compatible
allOf:
- if:
properties:
compatible:
contains:
enum:
- arm,vexpress,v2p-ca9
- arm,vexpress,v2p-ca5s
- arm,vexpress,v2p-ca15
- arm,vexpress,v2p-ca15_a7
- arm,vexpress,v2f-1xv7,ca53x2
then:
required:
- arm,hbi
...

237
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, with 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.yaml file.
- a "cpus" node describing the available cores and their associated
"enable-method"s. For more details see cpus.yaml 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";
reg = <0x0 0x0>;
device_type = "cpu";
enable-method = "psci";
};
.....
A53_0: cpu@100 {
compatible = "arm,cortex-a53";
reg = <0x0 0x100>;
device_type = "cpu";
enable-method = "psci";
};
.....
};
};

28
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.

36
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
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
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
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
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";
[...]
}

67
bindings/arm/bcm/brcm,bcm2835.txt
View File

@@ -1,67 +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 A+
Required root node properties:
compatible = "raspberrypi,3-model-a-plus", "brcm,bcm2837";
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 Compute Module 3
Required root node properties:
compatible = "raspberrypi,3-compute-module", "brcm,bcm2837";
Raspberry Pi Compute Module 3 Lite
Required root node properties:
compatible = "raspberrypi,3-compute-module-lite", "brcm,bcm2837";
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
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";

2
bindings/arm/bcm/brcm,bcm63138.txt
View File

@@ -62,7 +62,7 @@ Timer node:
Syscon reboot node:
See Documentation/devicetree/bindings/power/reset/syscon-reboot.txt for the
See Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml for the
detailed list of properties, the two values defined below are specific to the
BCM6328-style timer:

31
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
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
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
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
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
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
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
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>;
};

49
bindings/arm/calxeda/hb-sregs.yaml Normal file
View File

@@ -0,0 +1,49 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/calxeda/hb-sregs.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Calxeda Highbank system registers
description: |
The Calxeda Highbank system has a block of MMIO registers controlling
several generic system aspects. Those can be used to control some power
management, they also contain some gate and PLL clocks.
maintainers:
- Andre Przywara <andre.przywara@arm.com>
properties:
compatible:
const: calxeda,hb-sregs
reg:
maxItems: 1
clocks:
type: object
required:
- compatible
- reg
additionalProperties: false
examples:
- |
sregs@fff3c000 {
compatible = "calxeda,hb-sregs";
reg = <0xfff3c000 0x1000>;
clocks {
#address-cells = <1>;
#size-cells = <0>;
osc: oscillator {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <33333000>;
};
};
};

15
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>;
};

42
bindings/arm/calxeda/l2ecc.yaml Normal file
View File

@@ -0,0 +1,42 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/calxeda/l2ecc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Calxeda Highbank L2 cache ECC
description: |
Binding for the Calxeda Highbank L2 cache controller ECC device.
This does not cover the actual L2 cache controller control registers,
but just the error reporting functionality.
maintainers:
- Andre Przywara <andre.przywara@arm.com>
properties:
compatible:
const: "calxeda,hb-sregs-l2-ecc"
reg:
maxItems: 1
interrupts:
items:
- description: single bit error interrupt
- description: double bit error interrupt
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
sregs@fff3c200 {
compatible = "calxeda,hb-sregs-l2-ecc";
reg = <0xfff3c200 0x100>;
interrupts = <0 71 4>, <0 72 4>;
};

330
bindings/arm/coresight-cti.yaml Normal file
View File

@@ -0,0 +1,330 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/coresight-cti.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Coresight Cross Trigger Interface (CTI) device.
description: |
The CoreSight Embedded Cross Trigger (ECT) consists of CTI devices connected
to one or more CoreSight components and/or a CPU, with CTIs interconnected in
a star topology via the Cross Trigger Matrix (CTM), which is not programmable.
The ECT components are not part of the trace generation data path and are thus
not part of the CoreSight graph described in the general CoreSight bindings
file coresight.txt.
The CTI component properties define the connections between the individual
CTI and the components it is directly connected to, consisting of input and
output hardware trigger signals. CTIs can have a maximum number of input and
output hardware trigger signals (8 each for v1 CTI, 32 each for v2 CTI). The
number is defined at design time, the maximum of each defined in the DEVID
register.
CTIs are interconnected in a star topology via the CTM, using a number of
programmable channels, usually 4, but again implementation defined and
described in the DEVID register. The star topology is not required to be
described in the bindings as the actual connections are software
programmable.
In general the connections between CTI and components via the trigger signals
are implementation defined, except when the CTI is connected to an ARM v8
architecture core and optional ETM.
In this case the ARM v8 architecture defines the required signal connections
between CTI and the CPU core and ETM if present. In the case of a v8
architecturally connected CTI an additional compatible string is used to
indicate this feature (arm,coresight-cti-v8-arch).
When CTI trigger connection information is unavailable then a minimal driver
binding can be declared with no explicit trigger signals. This will result
the driver detecting the maximum available triggers and channels from the
DEVID register and make them all available for use as a single default
connection. Any user / client application will require additional information
on the connections between the CTI and other components for correct operation.
This information might be found by enabling the Integration Test registers in
the driver (set CONFIG_CORESIGHT_CTI_INTEGRATION_TEST in Kernel
configuration). These registers may be used to explore the trigger connections
between CTI and other CoreSight components.
Certain triggers between CoreSight devices and the CTI have specific types
and usages. These can be defined along with the signal indexes with the
constants defined in <dt-bindings/arm/coresight-cti-dt.h>
For example a CTI connected to a core will usually have a DBGREQ signal. This
is defined in the binding as type PE_EDBGREQ. These types will appear in an
optional array alongside the signal indexes. Omitting types will default all
signals to GEN_IO.
Note that some hardware trigger signals can be connected to non-CoreSight
components (e.g. UART etc) depending on hardware implementation.
maintainers:
- Mike Leach <mike.leach@linaro.org>
allOf:
- $ref: /schemas/arm/primecell.yaml#
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
compatible:
contains:
enum:
- arm,coresight-cti
required:
- compatible
properties:
$nodename:
pattern: "^cti(@[0-9a-f]+)$"
compatible:
oneOf:
- items:
- const: arm,coresight-cti
- const: arm,primecell
- items:
- const: arm,coresight-cti-v8-arch
- const: arm,coresight-cti
- const: arm,primecell
reg:
maxItems: 1
cpu:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Handle to cpu this device is associated with. This must appear in the
base cti node if compatible string arm,coresight-cti-v8-arch is used,
or may appear in a trig-conns child node when appropriate.
arm,cti-ctm-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Defines the CTM this CTI is connected to, in large systems with multiple
separate CTI/CTM nets. Typically multi-socket systems where the CTM is
propagated between sockets.
arm,cs-dev-assoc:
$ref: /schemas/types.yaml#/definitions/phandle
description:
defines a phandle reference to an associated CoreSight trace device.
When the associated trace device is enabled, then the respective CTI
will be enabled. Use in a trig-conns node, or in CTI base node when
compatible string arm,coresight-cti-v8-arch used. If the associated
device has not been registered then the node name will be stored as
the connection name for later resolution. If the associated device is
not a CoreSight device or not registered then the node name will remain
the connection name and automatic enabling will not occur.
# size cells and address cells required if trig-conns node present.
"#size-cells":
const: 0
"#address-cells":
const: 1
patternProperties:
'^trig-conns@([0-9]+)$':
type: object
description:
A trigger connections child node which describes the trigger signals
between this CTI and another hardware device. This device may be a CPU,
CoreSight device, any other hardware device or simple external IO lines.
The connection may have both input and output triggers, or only one or the
other.
properties:
reg:
maxItems: 1
arm,trig-in-sigs:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger in signal numbers in use by a trig-conns node.
arm,trig-in-types:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of constants representing the types for the CTI trigger in
signals. Types in this array match to the corresponding signal in the
arm,trig-in-sigs array. If the -types array is smaller, or omitted
completely, then the types will default to GEN_IO.
arm,trig-out-sigs:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger out signal numbers in use by a trig-conns node.
arm,trig-out-types:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of constants representing the types for the CTI trigger out
signals. Types in this array match to the corresponding signal
in the arm,trig-out-sigs array. If the "-types" array is smaller,
or omitted completely, then the types will default to GEN_IO.
arm,trig-filters:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger out signals that will be blocked from becoming
active, unless filtering is disabled on the driver.
arm,trig-conn-name:
$ref: /schemas/types.yaml#/definitions/string
description:
Defines a connection name that will be displayed, if the cpu or
arm,cs-dev-assoc properties are not being used in this connection.
Principle use for CTI that are connected to non-CoreSight devices, or
external IO.
anyOf:
- required:
- arm,trig-in-sigs
- required:
- arm,trig-out-sigs
oneOf:
- required:
- arm,trig-conn-name
- required:
- cpu
- required:
- arm,cs-dev-assoc
required:
- reg
required:
- compatible
- reg
- clocks
- clock-names
if:
properties:
compatible:
contains:
const: arm,coresight-cti-v8-arch
then:
required:
- cpu
examples:
# minimum CTI definition. DEVID register used to set number of triggers.
- |
cti@20020000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x20020000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
};
# v8 architecturally defined CTI - CPU + ETM connections generated by the
# driver according to the v8 architecture specification.
- |
cti@859000 {
compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
"arm,primecell";
reg = <0x859000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
cpu = <&CPU1>;
arm,cs-dev-assoc = <&etm1>;
};
# Implementation defined CTI - CPU + ETM connections explicitly defined..
# Shows use of type constants from dt-bindings/arm/coresight-cti-dt.h
# #size-cells and #address-cells are required if trig-conns@ nodes present.
- |
#include <dt-bindings/arm/coresight-cti-dt.h>
cti@858000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x858000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
arm,cti-ctm-id = <1>;
#address-cells = <1>;
#size-cells = <0>;
trig-conns@0 {
reg = <0>;
arm,trig-in-sigs = <4 5 6 7>;
arm,trig-in-types = <ETM_EXTOUT
ETM_EXTOUT
ETM_EXTOUT
ETM_EXTOUT>;
arm,trig-out-sigs = <4 5 6 7>;
arm,trig-out-types = <ETM_EXTIN
ETM_EXTIN
ETM_EXTIN
ETM_EXTIN>;
arm,cs-dev-assoc = <&etm0>;
};
trig-conns@1 {
reg = <1>;
cpu = <&CPU0>;
arm,trig-in-sigs = <0 1>;
arm,trig-in-types = <PE_DBGTRIGGER
PE_PMUIRQ>;
arm,trig-out-sigs=<0 1 2 >;
arm,trig-out-types = <PE_EDBGREQ
PE_DBGRESTART
PE_CTIIRQ>;
arm,trig-filters = <0>;
};
};
# Implementation defined CTI - non CoreSight component connections.
- |
cti@20110000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x20110000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
#address-cells = <1>;
#size-cells = <0>;
trig-conns@0 {
reg = <0>;
arm,trig-in-sigs=<0>;
arm,trig-in-types=<GEN_INTREQ>;
arm,trig-out-sigs=<0>;
arm,trig-out-types=<GEN_HALTREQ>;
arm,trig-conn-name = "sys_profiler";
};
trig-conns@1 {
reg = <1>;
arm,trig-out-sigs=<2 3>;
arm,trig-out-types=<GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "watchdog";
};
trig-conns@2 {
reg = <2>;
arm,trig-in-sigs=<1 6>;
arm,trig-in-types=<GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "g_counter";
};
};
...

22
bindings/arm/coresight.txt
View File

@@ -45,6 +45,10 @@ its hardware characteristcs.
- Coresight Address Translation Unit (CATU)
"arm,coresight-catu", "arm,primecell";
- Coresight Cross Trigger Interface (CTI):
"arm,coresight-cti", "arm,primecell";
See coresight-cti.yaml for full CTI definitions.
* reg: physical base address and length of the register
set(s) of the component.
@@ -72,6 +76,9 @@ its hardware characteristcs.
* reg-names: the only acceptable values are "stm-base" and
"stm-stimulus-base", each corresponding to the areas defined in "reg".
* Required properties for Coresight Cross Trigger Interface (CTI)
See coresight-cti.yaml for full CTI definitions.
* Required properties for devices that don't show up on the AMBA bus, such as
non-configurable replicators and non-configurable funnels:
@@ -138,6 +145,13 @@ its hardware characteristcs.
* qcom,tupwr-disable: For ETM, don't keep trace unit powered across
power collapse.
* qcom,skip-power-up: boolean. Indicates that an implementation can
skip powering up the trace unit. TRCPDCR.PU does not have to be set
on Qualcomm Technologies Inc. systems since ETMs are in the same power
domain as their CPU cores. This property is required to identify such
systems with hardware errata where the CPU watchdog counter is stopped
when TRCPDCR.PU is set.
* Optional property for TMC:
* arm,buffer-size: size of contiguous buffer space for TMC ETR
@@ -151,6 +165,7 @@ its hardware characteristcs.
* interrupts : Exactly one SPI may be listed for reporting the address
error
<<<<<<< HEAD
* Required property for TPDAs:
* qcom,tpda-atid: must be present. Specifies the ATID for TPDA.
@@ -221,6 +236,13 @@ its hardware characteristcs.
* reg-names: funnel-base-real: actual register space for the
duplicate funnel.
=======
* Optional property for configurable replicators:
* qcom,replicator-loses-context: boolean. Indicates that the replicator
will lose register context when AMBA clock is removed which is observed
in some replicator designs.
>>>>>>> android-mainline
Graph bindings for Coresight
-------------------------------

26
bindings/arm/freescale/fsl,scu.txt
View File

@@ -47,7 +47,7 @@ Required properties:
&lsio_mu1 1 2
&lsio_mu1 1 3
&lsio_mu1 3 3>;
See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
See Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
for detailed mailbox binding.
Note: Each mu which supports general interrupt should have an alias correctly
@@ -108,7 +108,8 @@ This binding uses the i.MX common pinctrl binding[3].
Required properties:
- compatible: Should be one of:
"fsl,imx8qm-iomuxc",
"fsl,imx8qxp-iomuxc".
"fsl,imx8qxp-iomuxc",
"fsl,imx8dxl-iomuxc".
Required properties for Pinctrl sub nodes:
- fsl,pins: Each entry consists of 3 integers which represents
@@ -116,7 +117,8 @@ Required properties for Pinctrl sub nodes:
integers <pin_id mux_mode> are specified using a
PIN_FUNC_ID macro, which can be found in
<dt-bindings/pinctrl/pads-imx8qm.h>,
<dt-bindings/pinctrl/pads-imx8qxp.h>.
<dt-bindings/pinctrl/pads-imx8qxp.h>,
<dt-bindings/pinctrl/pads-imx8dxl.h>.
The last integer CONFIG is the pad setting value like
pull-up on this pin.
@@ -164,7 +166,18 @@ Required properties:
- compatible: should be:
"fsl,imx8qxp-sc-key"
followed by "fsl,imx-sc-key";
- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
- linux,keycodes: See Documentation/devicetree/bindings/input/input.yaml
Thermal bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
- compatible: Should be :
"fsl,imx8qxp-sc-thermal"
followed by "fsl,imx-sc-thermal";
- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml
for a description.
Example (imx8qxp):
-------------
@@ -238,6 +251,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
};
tsens: thermal-sensor {
compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal";
#thermal-sensor-cells = <1>;
};
};
};

2
bindings/arm/hisilicon/hi3519-sysctrl.txt
View File

@@ -1,7 +1,7 @@
* Hisilicon Hi3519 System Controller Block
This bindings use the following binding:
Documentation/devicetree/bindings/mfd/syscon.txt
Documentation/devicetree/bindings/mfd/syscon.yaml
Required properties:
- compatible: "hisilicon,hi3519-sysctrl".

706
bindings/arm/idle-states.txt
View File

@@ -1,706 +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 while 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
This assumes that the "enable-method" property is set to "psci" in the cpu
node[6] that is responsible for setting up CPU idle management in the OS
implementation.
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.yaml
[2] ARM Linux Kernel documentation - PSCI bindings
Documentation/devicetree/bindings/arm/psci.yaml
[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/
[6] ARM Linux Kernel documentation - Booting AArch64 Linux
Documentation/arm64/booting.rst

19
bindings/arm/intel,keembay.yaml Normal file
View File

@@ -0,0 +1,19 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/intel,keembay.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Keem Bay platform device tree bindings
maintainers:
- Paul J. Murphy <paul.j.murphy@intel.com>
- Daniele Alessandrelli <daniele.alessandrelli@intel.com>
properties:
compatible:
items:
- enum:
- intel,keembay-evm
- const: intel,keembay
...

44
bindings/arm/keystone/ti,k3-sci-common.yaml Normal file
View File

@@ -0,0 +1,44 @@
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/keystone/ti,k3-sci-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common K3 TI-SCI bindings
maintainers:
- Nishanth Menon <nm@ti.com>
description: |
The TI K3 family of SoCs usually have a central System Controller Processor
that is responsible for managing various SoC-level resources like clocks,
resets, interrupts etc. The communication with that processor is performed
through the TI-SCI protocol.
Each specific device management node like a clock controller node, a reset
controller node or an interrupt-controller node should define a common set
of properties that enables them to implement the corresponding functionality
over the TI-SCI protocol. The following are some of the common properties
needed by such individual nodes. The required properties for each device
management node is defined in the respective binding.
properties:
ti,sci:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Should be a phandle to the TI-SCI System Controller node
ti,sci-dev-id:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Should contain the TI-SCI device id corresponding to the device. Please
refer to the corresponding System Controller documentation for valid
values for the desired device.
ti,sci-proc-ids:
description: Should contain a single tuple of <proc_id host_id>.
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- description: TI-SCI processor id for the remote processor device
- description: TI-SCI host id to which processor control ownership
should be transferred to

177
bindings/arm/marvell/ap806-system-controller.txt
View File

@@ -1,177 +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/AP807 system controller
provides a number of clocks:
- 0: reference clock of CPU cluster 0
- 1: reference clock of CPU cluster 1
- 2: fixed PLL at 1200 Mhz
- 3: MSS clock, derived from the fixed PLL
Required properties:
- compatible: must be one of:
* "marvell,ap806-clock"
* "marvell,ap807-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.
It is possible to setup an overheat interrupt by giving at least one
critical point to any subnode of the thermal-zone node.
Required properties:
- compatible: must be one of:
* marvell,armada-ap806-thermal
- reg: register range associated with the thermal functions.
Optional properties:
- interrupts: overheat interrupt handle. Should point to line 18 of the
SEI irqchip. See interrupt-controller/interrupts.txt
- #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>;
interrupt-parent = <&sei>;
interrupts = <18>;
#thermal-sensor-cells = <1>;
};
};
Cluster clocks:
---------------
Device Tree Clock bindings for cluster clock of Marvell
AP806/AP807. Each cluster contain up to 2 CPUs running at the same
frequency.
Required properties:
- compatible: must be one of:
* "marvell,ap806-cpu-clock"
* "marvell,ap807-cpu-clock"
- #clock-cells : should be set to 1.
- clocks : shall be the input parent clock(s) phandle for the clock
(one per cluster)
- reg: register range associated with the cluster clocks
ap_syscon1: system-controller@6f8000 {
compatible = "marvell,armada-ap806-syscon1", "syscon", "simple-mfd";
reg = <0x6f8000 0x1000>;
cpu_clk: clock-cpu@278 {
compatible = "marvell,ap806-cpu-clock";
clocks = <&ap_clk 0>, <&ap_clk 1>;
#clock-cells = <1>;
reg = <0x278 0xa30>;
};
};

2
bindings/arm/marvell/ap80x-system-controller.txt
View File

@@ -111,7 +111,7 @@ Thermal:
--------
For common binding part and usage, refer to
Documentation/devicetree/bindings/thermal/thermal.txt
Documentation/devicetree/bindings/thermal/thermal*.yaml
The thermal IP can probe the temperature all around the processor. It
may feature several channels, each of them wired to one sensor.

24
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";

2
bindings/arm/marvell/cp110-system-controller.txt
View File

@@ -203,7 +203,7 @@ It is possible to setup an overheat interrupt by giving at least one
critical point to any subnode of the thermal-zone node.
For common binding part and usage, refer to
Documentation/devicetree/bindings/thermal/thermal.txt
Documentation/devicetree/bindings/thermal/thermal*.yaml
Required properties:
- compatible: must be one of:

1
bindings/arm/mediatek/mediatek,apmixedsys.txt
View File

@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-apmixedsys"
- "mediatek,mt2712-apmixedsys", "syscon"
- "mediatek,mt6765-apmixedsys", "syscon"
- "mediatek,mt6779-apmixedsys", "syscon"
- "mediatek,mt6797-apmixedsys"
- "mediatek,mt7622-apmixedsys"

1
bindings/arm/mediatek/mediatek,audsys.txt
View File

@@ -7,6 +7,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-audsys", "syscon"
- "mediatek,mt6765-audsys", "syscon"
- "mediatek,mt6779-audio", "syscon"
- "mediatek,mt7622-audsys", "syscon"
- "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon"

1
bindings/arm/mediatek/mediatek,camsys.txt
View File

@@ -6,6 +6,7 @@ The MediaTek camsys controller provides various clocks to the system.
Required Properties:
- compatible: Should be one of:
- "mediatek,mt6765-camsys", "syscon"
- "mediatek,mt6779-camsys", "syscon"
- "mediatek,mt8183-camsys", "syscon"
- #clock-cells: Must be 1

1
bindings/arm/mediatek/mediatek,imgsys.txt
View File

@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-imgsys", "syscon"
- "mediatek,mt2712-imgsys", "syscon"
- "mediatek,mt6765-imgsys", "syscon"
- "mediatek,mt6779-imgsys", "syscon"
- "mediatek,mt6797-imgsys", "syscon"
- "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon"

1
bindings/arm/mediatek/mediatek,infracfg.txt
View File

@@ -9,6 +9,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-infracfg", "syscon"
- "mediatek,mt2712-infracfg", "syscon"
- "mediatek,mt6765-infracfg", "syscon"
- "mediatek,mt6779-infracfg_ao", "syscon"
- "mediatek,mt6797-infracfg", "syscon"
- "mediatek,mt7622-infracfg", "syscon"

28
bindings/arm/mediatek/mediatek,mipi0a.txt Normal file
View File

@@ -0,0 +1,28 @@
Mediatek mipi0a (mipi_rx_ana_csi0a) controller
============================
The Mediatek mipi0a controller provides various clocks
to the system.
Required Properties:
- compatible: Should be one of:
- "mediatek,mt6765-mipi0a", "syscon"
- #clock-cells: Must be 1
The mipi0a controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
The mipi0a controller also uses the common power domain from
Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
The available power doamins are defined in dt-bindings/power/mt*-power.h.
Example:
mipi0a: clock-controller@11c10000 {
compatible = "mediatek,mt6765-mipi0a", "syscon";
reg = <0 0x11c10000 0 0x1000>;
power-domains = <&scpsys MT6765_POWER_DOMAIN_CAM>;
#clock-cells = <1>;
};

8
bindings/arm/mediatek/mediatek,mmsys.txt
View File

@@ -1,13 +1,15 @@
Mediatek mmsys controller
============================
The Mediatek mmsys controller provides various clocks to the system.
The Mediatek mmsys system controller provides clock control, routing control,
and miscellaneous control in mmsys partition.
Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-mmsys", "syscon"
- "mediatek,mt2712-mmsys", "syscon"
- "mediatek,mt6765-mmsys", "syscon"
- "mediatek,mt6779-mmsys", "syscon"
- "mediatek,mt6797-mmsys", "syscon"
- "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon"
@@ -15,13 +17,13 @@ Required Properties:
- "mediatek,mt8183-mmsys", "syscon"
- #clock-cells: Must be 1
The mmsys controller uses the common clk binding from
For the clock control, the mmsys controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
Example:
mmsys: clock-controller@14000000 {
mmsys: syscon@14000000 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
#clock-cells = <1>;

36
bindings/arm/mediatek/mediatek,pericfg.txt
View File

@@ -1,36 +0,0 @@
Mediatek pericfg controller
===========================
The Mediatek pericfg controller provides various clocks and reset
outputs to the system.
Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-pericfg", "syscon"
- "mediatek,mt2712-pericfg", "syscon"
- "mediatek,mt7622-pericfg", "syscon"
- "mediatek,mt7623-pericfg", "mediatek,mt2701-pericfg", "syscon"
- "mediatek,mt7629-pericfg", "syscon"
- "mediatek,mt8135-pericfg", "syscon"
- "mediatek,mt8173-pericfg", "syscon"
- "mediatek,mt8183-pericfg", "syscon"
- #clock-cells: Must be 1
- #reset-cells: Must be 1
The pericfg controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
Also it uses the common reset controller binding from
Documentation/devicetree/bindings/reset/reset.txt.
The available reset outputs are defined in
dt-bindings/reset/mt*-resets.h
Example:
pericfg: power-controller@10003000 {
compatible = "mediatek,mt8173-pericfg", "syscon";
reg = <0 0x10003000 0 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

65
bindings/arm/mediatek/mediatek,pericfg.yaml Normal file
View File

@@ -0,0 +1,65 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek Peripheral Configuration Controller
maintainers:
- Bartosz Golaszewski <bgolaszewski@baylibre.com>
description:
The Mediatek pericfg controller provides various clocks and reset outputs
to the system.
properties:
compatible:
oneOf:
- items:
- enum:
- mediatek,mt2701-pericfg
- mediatek,mt2712-pericfg
- mediatek,mt6765-pericfg
- mediatek,mt7622-pericfg
- mediatek,mt7629-pericfg
- mediatek,mt8135-pericfg
- mediatek,mt8173-pericfg
- mediatek,mt8183-pericfg
- mediatek,mt8516-pericfg
- const: syscon
- items:
# Special case for mt7623 for backward compatibility
- const: mediatek,mt7623-pericfg
- const: mediatek,mt2701-pericfg
- const: syscon
reg:
maxItems: 1
'#clock-cells':
const: 1
'#reset-cells':
const: 1
required:
- compatible
- reg
examples:
- |
pericfg@10003000 {
compatible = "mediatek,mt8173-pericfg", "syscon";
reg = <0x10003000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
- |
pericfg@10003000 {
compatible = "mediatek,mt7623-pericfg", "mediatek,mt2701-pericfg", "syscon";
reg = <0x10003000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

1
bindings/arm/mediatek/mediatek,topckgen.txt
View File

@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-topckgen"
- "mediatek,mt2712-topckgen", "syscon"
- "mediatek,mt6765-topckgen", "syscon"
- "mediatek,mt6779-topckgen", "syscon"
- "mediatek,mt6797-topckgen"
- "mediatek,mt7622-topckgen"

27
bindings/arm/mediatek/mediatek,vcodecsys.txt Normal file
View File

@@ -0,0 +1,27 @@
Mediatek vcodecsys controller
============================
The Mediatek vcodecsys controller provides various clocks to the system.
Required Properties:
- compatible: Should be one of:
- "mediatek,mt6765-vcodecsys", "syscon"
- #clock-cells: Must be 1
The vcodecsys controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
The vcodecsys controller also uses the common power domain from
Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
The available power doamins are defined in dt-bindings/power/mt*-power.h.
Example:
venc_gcon: clock-controller@17000000 {
compatible = "mediatek,mt6765-vcodecsys", "syscon";
reg = <0 0x17000000 0 0x10000>;
power-domains = <&scpsys MT6765_POWER_DOMAIN_VCODEC>;
#clock-cells = <1>;
};

65
bindings/arm/microchip,sparx5.yaml Normal file
View File

@@ -0,0 +1,65 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/microchip,sparx5.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip Sparx5 Boards Device Tree Bindings
maintainers:
- Lars Povlsen <lars.povlsen@microchip.com>
description: |+
The Microchip Sparx5 SoC is a ARMv8-based used in a family of
gigabit TSN-capable gigabit switches.
The SparX-5 Ethernet switch family provides a rich set of switching
features such as advanced TCAM-based VLAN and QoS processing
enabling delivery of differentiated services, and security through
TCAM-based frame processing using versatile content aware processor
(VCAP)
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: The Sparx5 pcb125 board is a modular board,
which has both spi-nor and eMMC storage. The modular design
allows for connection of different network ports.
items:
- const: microchip,sparx5-pcb125
- const: microchip,sparx5
- description: The Sparx5 pcb134 is a pizzabox form factor
gigabit switch with 20 SFP ports. It features spi-nor and
either spi-nand or eMMC storage (mount option).
items:
- const: microchip,sparx5-pcb134
- const: microchip,sparx5
- description: The Sparx5 pcb135 is a pizzabox form factor
gigabit switch with 48+4 Cu ports. It features spi-nor and
either spi-nand or eMMC storage (mount option).
items:
- const: microchip,sparx5-pcb135
- const: microchip,sparx5
axi@600000000:
type: object
description: the root node in the Sparx5 platforms must contain
an axi bus child node. They are always at physical address
0x600000000 in all the Sparx5 variants.
properties:
compatible:
items:
- const: simple-bus
required:
- compatible
required:
- compatible
- axi@600000000
...

14
bindings/arm/mrvl/mrvl.txt
View File

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

2
bindings/arm/msm/qcom,idle-state.txt
View File

@@ -81,4 +81,4 @@ Example:
};
};
[1]. Documentation/devicetree/bindings/arm/idle-states.txt
[1]. Documentation/devicetree/bindings/arm/idle-states.yaml

2
bindings/arm/msm/qcom,llcc.yaml
View File

@@ -43,6 +43,8 @@ required:
- reg-names
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>

44
bindings/arm/mstar/mstar,l3bridge.yaml Normal file
View File

@@ -0,0 +1,44 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2020 thingy.jp.
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mstar/mstar,l3bridge.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MStar/SigmaStar Armv7 SoC l3bridge
maintainers:
- Daniel Palmer <daniel@thingy.jp>
description: |
MStar/SigmaStar's Armv7 SoCs have a pipeline in the interface
between the CPU and memory. This means that before DMA capable
devices are allowed to run the pipeline must be flushed to ensure
everything is in memory.
The l3bridge region contains registers that allow such a flush
to be triggered.
This node is used by the platform code to find where the registers
are and install a barrier that triggers the required pipeline flush.
properties:
compatible:
items:
- const: mstar,l3bridge
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
l3bridge: l3bridge@1f204400 {
compatible = "mstar,l3bridge";
reg = <0x1f204400 0x200>;
};

33
bindings/arm/mstar/mstar.yaml Normal file
View File

@@ -0,0 +1,33 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/mstar/mstar.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MStar platforms device tree bindings
maintainers:
- Daniel Palmer <daniel@thingy.jp>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: infinity boards
items:
- enum:
- thingyjp,breadbee-crust # thingy.jp BreadBee Crust
- const: mstar,infinity
- description: infinity3 boards
items:
- enum:
- thingyjp,breadbee # thingy.jp BreadBee
- const: mstar,infinity3
- description: mercury5 boards
items:
- enum:
- 70mai,midrived08 # 70mai midrive d08
- const: mstar,mercury5

69
bindings/arm/nvidia,tegra194-ccplex.yaml Normal file
View File

@@ -0,0 +1,69 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra194 CPU Complex device tree bindings
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jonathan Hunter <jonathanh@nvidia.com>
- Sumit Gupta <sumitg@nvidia.com>
description: |+
Tegra194 SOC has homogeneous architecture where each cluster has two
symmetric cores. Compatible string in "cpus" node represents the CPU
Complex having all clusters.
properties:
$nodename:
const: cpus
compatible:
enum:
- nvidia,tegra194-ccplex
nvidia,bpmp:
$ref: '/schemas/types.yaml#/definitions/phandle'
description: |
Specifies the bpmp node that needs to be queried to get
operating point data for all CPUs.
examples:
- |
cpus {
compatible = "nvidia,tegra194-ccplex";
nvidia,bpmp = <&bpmp>;
#address-cells = <1>;
#size-cells = <0>;
cpu0_0: cpu@0 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x0>;
enable-method = "psci";
};
cpu0_1: cpu@1 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x001>;
enable-method = "psci";
};
cpu1_0: cpu@100 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x100>;
enable-method = "psci";
};
cpu1_1: cpu@101 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x101>;
enable-method = "psci";
};
};
...

2
bindings/arm/omap/mpu.txt
View File

@@ -17,7 +17,7 @@ am335x and am437x only:
- pm-sram: Phandles to ocmcram nodes to be used for power management.
First should be type 'protect-exec' for the driver to use to copy
and run PM functions, second should be regular pool to be used for
data region for code. See Documentation/devicetree/bindings/sram/sram.txt
data region for code. See Documentation/devicetree/bindings/sram/sram.yaml
for more details.
Examples:

57
bindings/arm/realtek.yaml Normal file
View File

@@ -0,0 +1,57 @@
# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/realtek.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Realtek platforms device tree bindings
maintainers:
- Andreas Färber <afaerber@suse.de>
properties:
$nodename:
const: '/'
compatible:
oneOf:
# RTD1195 SoC based boards
- items:
- enum:
- mele,x1000 # MeLE X1000
- realtek,horseradish # Realtek Horseradish EVB
- const: realtek,rtd1195
# RTD1293 SoC based boards
- items:
- enum:
- synology,ds418j # Synology DiskStation DS418j
- const: realtek,rtd1293
# RTD1295 SoC based boards
- items:
- enum:
- mele,v9 # MeLE V9
- probox2,ava # ProBox2 AVA
- xnano,x5 # Xnano X5
- zidoo,x9s # Zidoo X9S
- const: realtek,rtd1295
# RTD1296 SoC based boards
- items:
- enum:
- synology,ds418 # Synology DiskStation DS418
- const: realtek,rtd1296
# RTD1395 SoC based boards
- items:
- enum:
- bananapi,bpi-m4 # Banana Pi BPI-M4
- realtek,lion-skin # Realtek Lion Skin EVB
- const: realtek,rtd1395
# RTD1619 SoC based boards
- items:
- enum:
- realtek,mjolnir # Realtek Mjolnir EVB
- const: realtek,rtd1619
...

20
bindings/arm/renesas,prr.txt
View File

@@ -1,20 +0,0 @@
Renesas Product Register
Most Renesas ARM SoCs have a Product Register or Boundary Scan ID Register that
allows to retrieve SoC product and revision information. If present, a device
node for this register should be added.
Required properties:
- compatible: Must be one of:
"renesas,prr"
"renesas,bsid"
- reg: Base address and length of the register block.
Examples
--------
prr: chipid@ff000044 {
compatible = "renesas,prr";
reg = <0 0xff000044 0 4>;
};

12
bindings/arm/samsung/exynos-chipid.txt
View File

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

72
bindings/arm/samsung/pmu.txt
View File

@@ -1,72 +0,0 @@
SAMSUNG Exynos SoC series PMU Registers
Properties:
- compatible : should contain two values. First value must be one from following list:
- "samsung,exynos3250-pmu" - for Exynos3250 SoC,
- "samsung,exynos4210-pmu" - for Exynos4210 SoC,
- "samsung,exynos4412-pmu" - for Exynos4412 SoC,
- "samsung,exynos5250-pmu" - for Exynos5250 SoC,
- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
- "samsung,exynos5433-pmu" - for Exynos5433 SoC.
- "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
- reg : offset and length of the register set.
- #clock-cells : must be <1>, since PMU requires once cell as clock specifier.
The single specifier cell is used as index to list of clocks
provided by PMU, which is currently:
0 : SoC clock output (CLKOUT pin)
- clock-names : list of clock names for particular CLKOUT mux inputs in
following format:
"clkoutN", where N is a decimal number corresponding to
CLKOUT mux control bits value for given input, e.g.
"clkout0", "clkout7", "clkout15".
- clocks : list of phandles and specifiers to all input clocks listed in
clock-names property.
Optional properties:
Some PMUs are capable of behaving as an interrupt controller (mostly
to wake up a suspended PMU). In which case, they can have the
following properties:
- interrupt-controller: indicate that said PMU is an interrupt controller
- #interrupt-cells: must be identical to the that of the parent interrupt
controller.
Optional nodes:
- nodes defining the restart and poweroff syscon children
Example :
pmu_system_controller: system-controller@10040000 {
compatible = "samsung,exynos5250-pmu", "syscon";
reg = <0x10040000 0x5000>;
interrupt-controller;
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
#clock-cells = <1>;
clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
"clkout4", "clkout8", "clkout9";
clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
<&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
<&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
<&clock CLK_XUSBXTI>;
};
Example of clock consumer :
usb3503: usb3503@8 {
/* ... */
clock-names = "refclk";
clocks = <&pmu_system_controller 0>;
/* ... */
};

83
bindings/arm/samsung/samsung-boards.txt
View File

@@ -1,83 +0,0 @@
* Samsung's Exynos and S5P SoC based boards
Required root node properties:
- compatible = should be one or more of the following.
- "samsung,aries" - for S5PV210-based Samsung Aries board.
- "samsung,fascinate4g" - for S5PV210-based Samsung Galaxy S Fascinate 4G (SGH-T959P) board.
- "samsung,galaxys" - for S5PV210-based Samsung Galaxy S (i9000) board.
- "samsung,artik5" - for Exynos3250-based Samsung ARTIK5 module.
- "samsung,artik5-eval" - for Exynos3250-based Samsung ARTIK5 eval board.
- "samsung,monk" - for Exynos3250-based Samsung Simband board.
- "samsung,rinato" - for Exynos3250-based Samsung Gear2 board.
- "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board.
- "samsung,trats" - for Exynos4210-based Tizen Reference board.
- "samsung,universal_c210" - for Exynos4210-based Samsung board.
- "samsung,i9300" - for Exynos4412-based Samsung GT-I9300 board.
- "samsung,i9305" - for Exynos4412-based Samsung GT-I9305 board.
- "samsung,midas" - for Exynos4412-based Samsung Midas board.
- "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board.
- "samsung,n710x" - for Exynos4412-based Samsung GT-N7100/GT-N7105 board.
- "samsung,trats2" - for Exynos4412-based Tizen Reference board.
- "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board.
- "samsung,xyref5260" - for Exynos5260-based Samsung board.
- "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board.
- "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board.
- "samsung,tm2" - for Exynos5433-based Samsung TM2 board.
- "samsung,tm2e" - for Exynos5433-based Samsung TM2E board.
* Other companies Exynos SoC based
* FriendlyARM
- "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM
TINY4412 board.
* TOPEET
- "topeet,itop4412-elite" - for Exynos4412-based TOPEET
Elite base board.
* Google
- "google,pi" - for Exynos5800-based Google Peach Pi
Rev 10+ board,
also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14",
"google,pi-rev13", "google,pi-rev12", "google,pi-rev11",
"google,pi-rev10", "google,peach".
- "google,pit" - for Exynos5420-based Google Peach Pit
Rev 6+ (Exynos5420),
also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14",
"google,pit-rev13", "google,pit-rev12", "google,pit-rev11",
"google,pit-rev10", "google,pit-rev9", "google,pit-rev8",
"google,pit-rev7", "google,pit-rev6", "google,peach".
- "google,snow-rev4" - for Exynos5250-based Google Snow board,
also: "google,snow"
- "google,snow-rev5" - for Exynos5250-based Google Snow
Rev 5+ board.
- "google,spring" - for Exynos5250-based Google Spring board.
* Hardkernel
- "hardkernel,odroid-u3" - for Exynos4412-based Hardkernel Odroid U3.
- "hardkernel,odroid-x" - for Exynos4412-based Hardkernel Odroid X.
- "hardkernel,odroid-x2" - for Exynos4412-based Hardkernel Odroid X2.
- "hardkernel,odroid-xu" - for Exynos5410-based Hardkernel Odroid XU.
- "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3.
- "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel
Odroid XU3 Lite board.
- "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4.
- "hardkernel,odroid-hc1" - for Exynos5422-based Hardkernel Odroid HC1.
* Insignal
- "insignal,arndale" - for Exynos5250-based Insignal Arndale board.
- "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale
Octa board.
- "insignal,origen" - for Exynos4210-based Insignal Origen board.
- "insignal,origen4412" - for Exynos4412-based Insignal Origen board.
Optional nodes:
- firmware node, specifying presence and type of secure firmware:
- compatible: only "samsung,secure-firmware" is currently supported
- reg: address of non-secure SYSRAM used for communication with firmware
firmware@203f000 {
compatible = "samsung,secure-firmware";
reg = <0x0203F000 0x1000>;
};

19
bindings/arm/samsung/sysreg.txt
View File

@@ -1,19 +0,0 @@
SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
Properties:
- compatible : should contain two values. First value must be one from following list:
- "samsung,exynos4-sysreg" - for Exynos4 based SoCs,
- "samsung,exynos5-sysreg" - for Exynos5 based SoCs.
second value must be always "syscon".
- reg : offset and length of the register set.
Example:
syscon@10010000 {
compatible = "samsung,exynos4-sysreg", "syscon";
reg = <0x10010000 0x400>;
};
syscon@10050000 {
compatible = "samsung,exynos5-sysreg", "syscon";
reg = <0x10050000 0x5000>;
};

60
bindings/arm/socionext/cache-uniphier.txt
View File

@@ -1,60 +0,0 @@
UniPhier outer cache controller
UniPhier SoCs are integrated with a full-custom outer cache controller system.
All of them have a level 2 cache controller, and some have a level 3 cache
controller as well.
Required properties:
- compatible: should be "socionext,uniphier-system-cache"
- reg: offsets and lengths of the register sets for the device. It should
contain 3 regions: control register, revision register, operation register,
in this order.
- cache-unified: specifies the cache is a unified cache.
- cache-size: specifies the size in bytes of the cache
- cache-sets: specifies the number of associativity sets of the cache
- cache-line-size: specifies the line size in bytes
- cache-level: specifies the level in the cache hierarchy. The value should
be 2 for L2 cache, 3 for L3 cache, etc.
Optional properties:
- next-level-cache: phandle to the next level cache if present. The next level
cache should be also compatible with "socionext,uniphier-system-cache".
The L2 cache must exist to use the L3 cache; the cache hierarchy must be
indicated correctly with "next-level-cache" properties.
Example 1 (system with L2):
l2: l2-cache@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x4>,
<0x506c0000 0x400>;
cache-unified;
cache-size = <0x80000>;
cache-sets = <256>;
cache-line-size = <128>;
cache-level = <2>;
};
Example 2 (system with L2 and L3):
l2: l2-cache@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x8>,
<0x506c0000 0x400>;
cache-unified;
cache-size = <0x200000>;
cache-sets = <512>;
cache-line-size = <128>;
cache-level = <2>;
next-level-cache = <&l3>;
};
l3: l3-cache@500c8000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
<0x506c8000 0x400>;
cache-unified;
cache-size = <0x400000>;
cache-sets = <512>;
cache-line-size = <256>;
cache-level = <3>;
};

102
bindings/arm/socionext/socionext,uniphier-system-cache.yaml Normal file
View File

@@ -0,0 +1,102 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/socionext/socionext,uniphier-system-cache.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: UniPhier outer cache controller
description: |
UniPhier ARM 32-bit SoCs are integrated with a full-custom outer cache
controller system. All of them have a level 2 cache controller, and some
have a level 3 cache controller as well.
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
properties:
compatible:
const: socionext,uniphier-system-cache
reg:
description: |
should contain 3 regions: control register, revision register,
operation register, in this order.
minItems: 3
maxItems: 3
interrupts:
description: |
Interrupts can be used to notify the completion of cache operations.
The number of interrupts should match to the number of CPU cores.
The specified interrupts correspond to CPU0, CPU1, ... in this order.
minItems: 1
maxItems: 4
cache-unified: true
cache-size: true
cache-sets: true
cache-line-size: true
cache-level:
minimum: 2
maximum: 3
next-level-cache: true
allOf:
- $ref: /schemas/cache-controller.yaml#
additionalProperties: false
required:
- compatible
- reg
- interrupts
- cache-unified
- cache-size
- cache-sets
- cache-line-size
- cache-level
examples:
- |
// System with L2.
cache-controller@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x4>, <0x506c0000 0x400>;
interrupts = <0 174 4>, <0 175 4>, <0 190 4>, <0 191 4>;
cache-unified;
cache-size = <0x140000>;
cache-sets = <512>;
cache-line-size = <128>;
cache-level = <2>;
};
- |
// System with L2 and L3.
// L2 should specify the next level cache by 'next-level-cache'.
l2: cache-controller@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x8>, <0x506c0000 0x400>;
interrupts = <0 190 4>, <0 191 4>;
cache-unified;
cache-size = <0x200000>;
cache-sets = <512>;
cache-line-size = <128>;
cache-level = <2>;
next-level-cache = <&l3>;
};
l3: cache-controller@500c8000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, <0x506c8000 0x400>;
interrupts = <0 174 4>, <0 175 4>;
cache-unified;
cache-size = <0x200000>;
cache-sets = <512>;
cache-line-size = <256>;
cache-level = <3>;
};

47
bindings/arm/socionext/uniphier.txt
View File

@@ -1,47 +0,0 @@
Socionext UniPhier SoC family
-----------------------------
Required properties in the root node:
- compatible: should contain board and SoC compatible strings
SoC and board compatible strings:
(sorted chronologically)
- LD4 SoC: "socionext,uniphier-ld4"
- Reference Board: "socionext,uniphier-ld4-ref"
- Pro4 SoC: "socionext,uniphier-pro4"
- Reference Board: "socionext,uniphier-pro4-ref"
- Ace Board: "socionext,uniphier-pro4-ace"
- Sanji Board: "socionext,uniphier-pro4-sanji"
- sLD8 SoC: "socionext,uniphier-sld8"
- Reference Board: "socionext,uniphier-sld8-ref"
- PXs2 SoC: "socionext,uniphier-pxs2"
- Gentil Board: "socionext,uniphier-pxs2-gentil"
- Vodka Board: "socionext,uniphier-pxs2-vodka"
- LD6b SoC: "socionext,uniphier-ld6b"
- Reference Board: "socionext,uniphier-ld6b-ref"
- LD11 SoC: "socionext,uniphier-ld11"
- Reference Board: "socionext,uniphier-ld11-ref"
- Global Board: "socionext,uniphier-ld11-global"
- LD20 SoC: "socionext,uniphier-ld20"
- Reference Board: "socionext,uniphier-ld20-ref"
- Global Board: "socionext,uniphier-ld20-global"
- PXs3 SoC: "socionext,uniphier-pxs3"
- Reference Board: "socionext,uniphier-pxs3-ref"
Example:
/dts-v1/;
/ {
compatible = "socionext,uniphier-ld20-ref", "socionext,uniphier-ld20";
...
};

62
bindings/arm/socionext/uniphier.yaml Normal file
View File

@@ -0,0 +1,62 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/socionext/uniphier.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Socionext UniPhier platform device tree bindings
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
properties:
$nodename:
const: /
compatible:
oneOf:
- description: LD4 SoC boards
items:
- enum:
- socionext,uniphier-ld4-ref
- const: socionext,uniphier-ld4
- description: Pro4 SoC boards
items:
- enum:
- socionext,uniphier-pro4-ace
- socionext,uniphier-pro4-ref
- socionext,uniphier-pro4-sanji
- const: socionext,uniphier-pro4
- description: sLD8 SoC boards
items:
- enum:
- socionext,uniphier-sld8-ref
- const: socionext,uniphier-sld8
- description: PXs2 SoC boards
items:
- enum:
- socionext,uniphier-pxs2-gentil
- socionext,uniphier-pxs2-vodka
- const: socionext,uniphier-pxs2
- description: LD6b SoC boards
items:
- enum:
- socionext,uniphier-ld6b-ref
- const: socionext,uniphier-ld6b
- description: LD11 SoC boards
items:
- enum:
- socionext,uniphier-ld11-global
- socionext,uniphier-ld11-ref
- const: socionext,uniphier-ld11
- description: LD20 SoC boards
items:
- enum:
- socionext,uniphier-ld20-akebi96
- socionext,uniphier-ld20-global
- socionext,uniphier-ld20-ref
- const: socionext,uniphier-ld20
- description: PXs3 SoC boards
items:
- enum:
- socionext,uniphier-pxs3-ref
- const: socionext,uniphier-pxs3

14
bindings/arm/sprd.txt
View File

@@ -1,14 +0,0 @@
Spreadtrum SoC Platforms Device Tree Bindings
----------------------------------------------------
SC9836 openphone Board
Required root node properties:
- compatible = "sprd,sc9836-openphone", "sprd,sc9836";
SC9860 SoC
Required root node properties:
- compatible = "sprd,sc9860"
SP9860G 3GFHD Board
Required root node properties:
- compatible = "sprd,sp9860g-1h10", "sprd,sc9860";

37
bindings/arm/stm32/mlahb.txt
View File

@@ -1,37 +0,0 @@
ML-AHB interconnect bindings
These bindings describe the STM32 SoCs ML-AHB interconnect bus which connects
a Cortex-M subsystem with dedicated memories.
The MCU SRAM and RETRAM memory parts can be accessed through different addresses
(see "RAM aliases" in [1]) using different buses (see [2]) : balancing the
Cortex-M firmware accesses among those ports allows to tune the system
performance.
[1]: https://www.st.com/resource/en/reference_manual/dm00327659.pdf
[2]: https://wiki.st.com/stm32mpu/wiki/STM32MP15_RAM_mapping
Required properties:
- compatible: should be "simple-bus"
- dma-ranges: describes memory addresses translation between the local CPU and
the remote Cortex-M processor. Each memory region, is declared with
3 parameters:
- param 1: device base address (Cortex-M processor address)
- param 2: physical base address (local CPU address)
- param 3: size of the memory region.
The Cortex-M remote processor accessed via the mlahb interconnect is described
by a child node.
Example:
mlahb {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
dma-ranges = <0x00000000 0x38000000 0x10000>,
<0x10000000 0x10000000 0x60000>,
<0x30000000 0x30000000 0x60000>;
m4_rproc: m4@10000000 {
...
};
};

4
bindings/arm/stm32/st,mlahb.yaml
View File

@@ -20,7 +20,7 @@ description: |
[2]: https://wiki.st.com/stm32mpu/wiki/STM32MP15_RAM_mapping
allOf:
- $ref: /schemas/simple-bus.yaml#
- $ref: /schemas/simple-bus.yaml#
properties:
compatible:
@@ -52,7 +52,7 @@ required:
examples:
- |
mlahb: ahb {
mlahb: ahb@38000000 {
compatible = "st,mlahb", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;

22
bindings/arm/stm32/st,stm32-syscon.yaml
View File

@@ -14,9 +14,12 @@ properties:
compatible:
oneOf:
- items:
- enum:
- st,stm32mp157-syscfg
- const: syscon
- enum:
- st,stm32mp157-syscfg
- st,stm32mp151-pwr-mcu
- st,stm32-syscfg
- st,stm32-power-config
- const: syscon
reg:
maxItems: 1
@@ -27,7 +30,18 @@ properties:
required:
- compatible
- reg
- clocks
if:
properties:
compatible:
contains:
enum:
- st,stm32mp157-syscfg
then:
required:
- clocks
additionalProperties: false
examples:
- |

16
bindings/arm/stm32/stm32-syscon.txt
View File

@@ -1,16 +0,0 @@
STMicroelectronics STM32 Platforms System Controller
Properties:
- compatible : should contain two values. First value must be :
- " st,stm32mp157-syscfg " - for stm32mp157 based SoCs,
second value must be always "syscon".
- reg : offset and length of the register set.
- clocks: phandle to the syscfg clock
Example:
syscfg: syscon@50020000 {
compatible = "st,stm32mp157-syscfg", "syscon";
reg = <0x50020000 0x400>;
clocks = <&rcc SYSCFG>;
};

44
bindings/arm/sunxi/smp-sram.txt
View File

@@ -1,44 +0,0 @@
Allwinner SRAM for smp bringup:
------------------------------------------------
Allwinner's A80 SoC uses part of the secure sram for hotplugging of the
primary core (cpu0). Once the core gets powered up it checks if a magic
value is set at a specific location. If it is then the BROM will jump
to the software entry address, instead of executing a standard boot.
Therefore a reserved section sub-node has to be added to the mmio-sram
declaration.
Note that this is separate from the Allwinner SRAM controller found in
../../sram/sunxi-sram.txt. This SRAM is secure only and not mappable to
any device.
Also there are no "secure-only" properties. The implementation should
check if this SRAM is usable first.
Required sub-node properties:
- compatible : depending on the SoC this should be one of:
"allwinner,sun9i-a80-smp-sram"
The rest of the properties should follow the generic mmio-sram discription
found in ../../misc/sram.txt
Example:
sram_b: sram@20000 {
/* 256 KiB secure SRAM at 0x20000 */
compatible = "mmio-sram";
reg = <0x00020000 0x40000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x00020000 0x40000>;
smp-sram@1000 {
/*
* This is checked by BROM to determine if
* cpu0 should jump to SMP entry vector
*/
compatible = "allwinner,sun9i-a80-smp-sram";
reg = <0x1000 0x8>;
};
};

36
bindings/arm/sunxi/sunxi-mbus.txt
View File

@@ -1,36 +0,0 @@
Allwinner Memory Bus (MBUS) controller
The MBUS controller drives the MBUS that other devices in the SoC will
use to perform DMA. It also has a register interface that allows to
monitor and control the bandwidth and priorities for masters on that
bus.
Required properties:
- compatible: Must be one of:
- allwinner,sun5i-a13-mbus
- reg: Offset and length of the register set for the controller
- clocks: phandle to the clock driving the controller
- dma-ranges: See section 2.3.9 of the DeviceTree Specification
- #interconnect-cells: Must be one, with the argument being the MBUS
port ID
Each device having to perform their DMA through the MBUS must have the
interconnects and interconnect-names properties set to the MBUS
controller and with "dma-mem" as the interconnect name.
Example:
mbus: dram-controller@1c01000 {
compatible = "allwinner,sun5i-a13-mbus";
reg = <0x01c01000 0x1000>;
clocks = <&ccu CLK_MBUS>;
dma-ranges = <0x00000000 0x40000000 0x20000000>;
#interconnect-cells = <1>;
};
fe0: display-frontend@1e00000 {
compatible = "allwinner,sun5i-a13-display-frontend";
...
interconnects = <&mbus 19>;
interconnect-names = "dma-mem";
};

2
bindings/arm/syna.txt
View File

@@ -13,7 +13,7 @@ considered "unstable". Any Marvell Berlin 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
Please refer to Documentation/devicetree/bindings/ABI.rst for a definition of a
stable binding/ABI.
---------------------------------------------------------------

300
bindings/arm/tegra/nvidia,tegra20-pmc.txt
View File

@@ -1,300 +0,0 @@
NVIDIA Tegra Power Management Controller (PMC)
== Power Management Controller Node ==
The PMC block interacts with an external Power Management Unit. The PMC
mostly controls the entry and exit of the system from different sleep
modes. It provides power-gating controllers for SoC and CPU power-islands.
Required properties:
- name : Should be pmc
- compatible : Should contain one of the following:
For Tegra20 must contain "nvidia,tegra20-pmc".
For Tegra30 must contain "nvidia,tegra30-pmc".
For Tegra114 must contain "nvidia,tegra114-pmc"
For Tegra124 must contain "nvidia,tegra124-pmc"
For Tegra132 must contain "nvidia,tegra124-pmc"
For Tegra210 must contain "nvidia,tegra210-pmc"
- reg : Offset and length of the register set for the device
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names : Must include the following entries:
"pclk" (The Tegra clock of that name),
"clk32k_in" (The 32KHz clock input to Tegra).
Optional properties:
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
The PMU is an external Power Management Unit, whose interrupt output
signal is fed into the PMC. This signal is optionally inverted, and then
fed into the ARM GIC. The PMC is not involved in the detection or
handling of this interrupt signal, merely its inversion.
- nvidia,suspend-mode : The suspend mode that the platform should use.
Valid values are 0, 1 and 2:
0 (LP0): CPU + Core voltage off and DRAM in self-refresh
1 (LP1): CPU voltage off and DRAM in self-refresh
2 (LP2): CPU voltage off
- nvidia,core-power-req-active-high : Boolean, core power request active-high
- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high
- nvidia,combined-power-req : Boolean, combined power request for CPU & Core
- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
is enabled.
Required properties when nvidia,suspend-mode is specified:
- nvidia,cpu-pwr-good-time : CPU power good time in uS.
- nvidia,cpu-pwr-off-time : CPU power off time in uS.
- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
Core power good time in uS.
- nvidia,core-pwr-off-time : Core power off time in uS.
Required properties when nvidia,suspend-mode=<0>:
- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector
The LP0 vector contains the warm boot code that is executed by AVP when
resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7
processor and always being the first boot processor when chip is power on
or resume from deep sleep mode. When the system is resumed from the deep
sleep mode, the warm boot code will restore some PLLs, clocks and then
bring up CPU0 for resuming the system.
Hardware-triggered thermal reset:
On Tegra30, Tegra114 and Tegra124, if the 'i2c-thermtrip' subnode exists,
hardware-triggered thermal reset will be enabled.
Required properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'):
- nvidia,i2c-controller-id : ID of I2C controller to send poweroff command to. Valid values are
described in section 9.2.148 "APBDEV_PMC_SCRATCH53_0" of the
Tegra K1 Technical Reference Manual.
- nvidia,bus-addr : Bus address of the PMU on the I2C bus
- nvidia,reg-addr : I2C register address to write poweroff command to
- nvidia,reg-data : Poweroff command to write to PMU
Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'):
- nvidia,pinmux-id : Pinmux used by the hardware when issuing poweroff command.
Defaults to 0. Valid values are described in section 12.5.2
"Pinmux Support" of the Tegra4 Technical Reference Manual.
Optional nodes:
- powergates : This node contains a hierarchy of power domain nodes, which
should match the powergates on the Tegra SoC. See "Powergate
Nodes" below.
Example:
/ SoC dts including file
pmc@7000f400 {
compatible = "nvidia,tegra20-pmc";
reg = <0x7000e400 0x400>;
clocks = <&tegra_car 110>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
nvidia,invert-interrupt;
nvidia,suspend-mode = <1>;
nvidia,cpu-pwr-good-time = <2000>;
nvidia,cpu-pwr-off-time = <100>;
nvidia,core-pwr-good-time = <3845 3845>;
nvidia,core-pwr-off-time = <458>;
nvidia,core-power-req-active-high;
nvidia,sys-clock-req-active-high;
nvidia,lp0-vec = <0xbdffd000 0x2000>;
};
/ Tegra board dts file
{
...
pmc@7000f400 {
i2c-thermtrip {
nvidia,i2c-controller-id = <4>;
nvidia,bus-addr = <0x40>;
nvidia,reg-addr = <0x36>;
nvidia,reg-data = <0x2>;
};
};
...
clocks {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
clk32k_in: clock {
compatible = "fixed-clock";
reg=<0>;
#clock-cells = <0>;
clock-frequency = <32768>;
};
};
...
};
== Powergate Nodes ==
Each of the powergate nodes represents a power-domain on the Tegra SoC
that can be power-gated by the Tegra PMC. The name of the powergate node
should be one of the below. Note that not every powergate is applicable
to all Tegra devices and the following list shows which powergates are
applicable to which devices. Please refer to the Tegra TRM for more
details on the various powergates.
Name Description Devices Applicable
3d 3D Graphics Tegra20/114/124/210
3d0 3D Graphics 0 Tegra30
3d1 3D Graphics 1 Tegra30
aud Audio Tegra210
dfd Debug Tegra210
dis Display A Tegra114/124/210
disb Display B Tegra114/124/210
heg 2D Graphics Tegra30/114/124/210
iram Internal RAM Tegra124/210
mpe MPEG Encode All
nvdec NVIDIA Video Decode Engine Tegra210
nvjpg NVIDIA JPEG Engine Tegra210
pcie PCIE Tegra20/30/124/210
sata SATA Tegra30/124/210
sor Display interfaces Tegra124/210
ve2 Video Encode Engine 2 Tegra210
venc Video Encode Engine All
vdec Video Decode Engine Tegra20/30/114/124
vic Video Imaging Compositor Tegra124/210
xusba USB Partition A Tegra114/124/210
xusbb USB Partition B Tegra114/124/210
xusbc USB Partition C Tegra114/124/210
Required properties:
- clocks: Must contain an entry for each clock required by the PMC for
controlling a power-gate. See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each reset required by the PMC for
controlling a power-gate. See ../reset/reset.txt for details.
- #power-domain-cells: Must be 0.
Example:
pmc: pmc@7000e400 {
compatible = "nvidia,tegra210-pmc";
reg = <0x0 0x7000e400 0x0 0x400>;
clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
powergates {
pd_audio: aud {
clocks = <&tegra_car TEGRA210_CLK_APE>,
<&tegra_car TEGRA210_CLK_APB2APE>;
resets = <&tegra_car 198>;
#power-domain-cells = <0>;
};
};
};
== Powergate Clients ==
Hardware blocks belonging to a power domain should contain a "power-domains"
property that is a phandle pointing to the corresponding powergate node.
Example:
adma: adma@702e2000 {
...
power-domains = <&pd_audio>;
...
};
== Pad Control ==
On Tegra SoCs a pad is a set of pins which are configured as a group.
The pin grouping is a fixed attribute of the hardware. The PMC can be
used to set pad power state and signaling voltage. A pad can be either
in active or power down mode. The support for power state and signaling
voltage configuration varies depending on the pad in question. 3.3 V and
1.8 V signaling voltages are supported on pins where software
controllable signaling voltage switching is available.
The pad configuration state nodes are placed under the pmc node and they
are referred to by the pinctrl client properties. For more information
see Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt.
The pad name should be used as the value of the pins property in pin
configuration nodes.
The following pads are present on Tegra124 and Tegra132:
audio bb cam comp
csia csb cse dsi
dsib dsic dsid hdmi
hsic hv lvds mipi-bias
nand pex-bias pex-clk1 pex-clk2
pex-cntrl sdmmc1 sdmmc3 sdmmc4
sys_ddc uart usb0 usb1
usb2 usb_bias
The following pads are present on Tegra210:
audio audio-hv cam csia
csib csic csid csie
csif dbg debug-nonao dmic
dp dsi dsib dsic
dsid emmc emmc2 gpio
hdmi hsic lvds mipi-bias
pex-bias pex-clk1 pex-clk2 pex-cntrl
sdmmc1 sdmmc3 spi spi-hv
uart usb0 usb1 usb2
usb3 usb-bias
Required pin configuration properties:
- pins: Must contain name of the pad(s) to be configured.
Optional pin configuration properties:
- low-power-enable: Configure the pad into power down mode
- low-power-disable: Configure the pad into active mode
- power-source: Must contain either TEGRA_IO_PAD_VOLTAGE_1V8
or TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages.
The values are defined in
include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h.
Note: The power state can be configured on all of the Tegra124 and
Tegra132 pads. None of the Tegra124 or Tegra132 pads support
signaling voltage switching.
Note: All of the listed Tegra210 pads except pex-cntrl support power
state configuration. Signaling voltage switching is supported on
following Tegra210 pads: audio, audio-hv, cam, dbg, dmic, gpio,
pex-cntrl, sdmmc1, sdmmc3, spi, spi-hv, and uart.
Pad configuration state example:
pmc: pmc@7000e400 {
compatible = "nvidia,tegra210-pmc";
reg = <0x0 0x7000e400 0x0 0x400>;
clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
...
sdmmc1_3v3: sdmmc1-3v3 {
pins = "sdmmc1";
power-source = <TEGRA_IO_PAD_VOLTAGE_3V3>;
};
sdmmc1_1v8: sdmmc1-1v8 {
pins = "sdmmc1";
power-source = <TEGRA_IO_PAD_VOLTAGE_1V8>;
};
hdmi_off: hdmi-off {
pins = "hdmi";
low-power-enable;
}
hdmi_on: hdmi-on {
pins = "hdmi";
low-power-disable;
}
};
Pinctrl client example:
sdmmc1: sdhci@700b0000 {
...
pinctrl-names = "sdmmc-3v3", "sdmmc-1v8";
pinctrl-0 = <&sdmmc1_3v3>;
pinctrl-1 = <&sdmmc1_1v8>;
};
...
sor@54540000 {
...
pinctrl-0 = <&hdmi_off>;
pinctrl-1 = <&hdmi_on>;
pinctrl-names = "hdmi-on", "hdmi-off";
};

229
bindings/arm/vexpress.txt
View File

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

38
bindings/ata/faraday,ftide010.txt
View File

@@ -1,38 +0,0 @@
* Faraday Technology FTIDE010 PATA controller
This controller is the first Faraday IDE interface block, used in the
StorLink SL2312 and SL3516, later known as the Cortina Systems Gemini
platform. The controller can do PIO modes 0 through 4, Multi-word DMA
(MWDM)modes 0 through 2 and Ultra DMA modes 0 through 6.
On the Gemini platform, this PATA block is accompanied by a PATA to
SATA bridge in order to support SATA. This is why a phandle to that
controller is compulsory on that platform.
The timing properties are unique per-SoC, not per-board.
Required properties:
- compatible: should be one of
"cortina,gemini-pata", "faraday,ftide010"
"faraday,ftide010"
- interrupts: interrupt for the block
- reg: registers and size for the block
Optional properties:
- clocks: a SoC clock running the peripheral.
- clock-names: should be set to "PCLK" for the peripheral clock.
Required properties for "cortina,gemini-pata" compatible:
- sata: a phande to the Gemini PATA to SATA bridge, see
cortina,gemini-sata-bridge.txt for details.
Example:
ata@63000000 {
compatible = "cortina,gemini-pata", "faraday,ftide010";
reg = <0x63000000 0x100>;
interrupts = <4 IRQ_TYPE_EDGE_RISING>;
clocks = <&gcc GEMINI_CLK_GATE_IDE>;
clock-names = "PCLK";
sata = <&sata>;
};

4
bindings/ata/faraday,ftide010.yaml
View File

@@ -26,8 +26,8 @@ properties:
oneOf:
- const: faraday,ftide010
- items:
- const: cortina,gemini-pata
- const: faraday,ftide010
- const: cortina,gemini-pata
- const: faraday,ftide010
reg:
maxItems: 1

72
bindings/ata/renesas,rcar-sata.yaml Normal file
View File

@@ -0,0 +1,72 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/ata/renesas,rcar-sata.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Renesas R-Car Serial-ATA Interface
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
properties:
compatible:
oneOf:
- items:
- enum:
- renesas,sata-r8a7779 # R-Car H1
- items:
- enum:
- renesas,sata-r8a7742 # RZ/G1H
- renesas,sata-r8a7790-es1 # R-Car H2 ES1
- renesas,sata-r8a7790 # R-Car H2 other than ES1
- renesas,sata-r8a7791 # R-Car M2-W
- renesas,sata-r8a7793 # R-Car M2-N
- const: renesas,rcar-gen2-sata # generic R-Car Gen2
- items:
- enum:
- renesas,sata-r8a774b1 # RZ/G2N
- renesas,sata-r8a7795 # R-Car H3
- renesas,sata-r8a77965 # R-Car M3-N
- const: renesas,rcar-gen3-sata # generic R-Car Gen3 or RZ/G2
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
iommus:
maxItems: 1
power-domains:
maxItems: 1
resets:
maxItems: 1
required:
- compatible
- reg
- interrupts
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/r8a7791-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7791-sysc.h>
sata@ee300000 {
compatible = "renesas,sata-r8a7791", "renesas,rcar-gen2-sata";
reg = <0xee300000 0x200000>;
interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 815>;
power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
resets = <&cpg 815>;
};

44
bindings/ata/sata_highbank.txt
View File

@@ -1,44 +0,0 @@
* Calxeda AHCI SATA Controller
SATA nodes are defined to describe on-chip Serial ATA controllers.
The Calxeda SATA controller mostly conforms to the AHCI interface
with some special extensions to add functionality.
Each SATA controller should have its own node.
Required properties:
- compatible : compatible list, contains "calxeda,hb-ahci"
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>
Optional properties:
- dma-coherent : Present if dma operations are coherent
- calxeda,port-phys : phandle-combophy and lane assignment, which maps each
SATA port to a combophy and a lane within that
combophy
- calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off,
which indicates that the driver supports SGPIO
indicator lights using the indicated GPIOs
- calxeda,led-order : a u32 array that map port numbers to offsets within the
SGPIO bitstream.
- calxeda,tx-atten : a u32 array that contains TX attenuation override
codes, one per port. The upper 3 bytes are always
0 and thus ignored.
- calxeda,pre-clocks : a u32 that indicates the number of additional clock
cycles to transmit before sending an SGPIO pattern
- calxeda,post-clocks: a u32 that indicates the number of additional clock
cycles to transmit after sending an SGPIO pattern
Example:
sata@ffe08000 {
compatible = "calxeda,hb-ahci";
reg = <0xffe08000 0x1000>;
interrupts = <115>;
dma-coherent;
calxeda,port-phys = <&combophy5 0 &combophy0 0 &combophy0 1
&combophy0 2 &combophy0 3>;
calxeda,sgpio-gpio =<&gpioh 5 1 &gpioh 6 1 &gpioh 7 1>;
calxeda,led-order = <4 0 1 2 3>;
calxeda,tx-atten = <0xff 22 0xff 0xff 23>;
calxeda,pre-clocks = <10>;
calxeda,post-clocks = <0>;
};

92
bindings/ata/sata_highbank.yaml Normal file
View File

@@ -0,0 +1,92 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/ata/sata_highbank.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Calxeda AHCI SATA Controller
description: |
The Calxeda SATA controller mostly conforms to the AHCI interface
with some special extensions to add functionality, to map GPIOs for
activity LEDs and for mapping the ComboPHYs.
maintainers:
- Andre Przywara <andre.przywara@arm.com>
properties:
compatible:
const: calxeda,hb-ahci
reg:
maxItems: 1
interrupts:
maxItems: 1
dma-coherent: true
calxeda,pre-clocks:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Indicates the number of additional clock cycles to transmit before
sending an SGPIO pattern.
calxeda,post-clocks:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Indicates the number of additional clock cycles to transmit after
sending an SGPIO pattern.
calxeda,led-order:
description: Maps port numbers to offsets within the SGPIO bitstream.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
calxeda,port-phys:
description: |
phandle-combophy and lane assignment, which maps each SATA port to a
combophy and a lane within that combophy
$ref: /schemas/types.yaml#/definitions/phandle-array
minItems: 1
maxItems: 8
calxeda,tx-atten:
description: |
Contains TX attenuation override codes, one per port.
The upper 24 bits of each entry are always 0 and thus ignored.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
calxeda,sgpio-gpio:
description: |
phandle-gpio bank, bit offset, and default on or off, which indicates
that the driver supports SGPIO indicator lights using the indicated
GPIOs.
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
sata@ffe08000 {
compatible = "calxeda,hb-ahci";
reg = <0xffe08000 0x1000>;
interrupts = <115>;
dma-coherent;
calxeda,port-phys = <&combophy5 0>, <&combophy0 0>, <&combophy0 1>,
<&combophy0 2>, <&combophy0 3>;
calxeda,sgpio-gpio =<&gpioh 5 1>, <&gpioh 6 1>, <&gpioh 7 1>;
calxeda,led-order = <4 0 1 2 3>;
calxeda,tx-atten = <0xff 22 0xff 0xff 23>;
calxeda,pre-clocks = <10>;
calxeda,post-clocks = <0>;
};
...

36
bindings/ata/sata_rcar.txt
View File

@@ -1,36 +0,0 @@
* Renesas R-Car SATA
Required properties:
- compatible : should contain one or more of the following:
- "renesas,sata-r8a774b1" for RZ/G2N
- "renesas,sata-r8a7779" for R-Car H1
- "renesas,sata-r8a7790-es1" for R-Car H2 ES1
- "renesas,sata-r8a7790" for R-Car H2 other than ES1
- "renesas,sata-r8a7791" for R-Car M2-W
- "renesas,sata-r8a7793" for R-Car M2-N
- "renesas,sata-r8a7795" for R-Car H3
- "renesas,sata-r8a77965" for R-Car M3-N
- "renesas,rcar-gen2-sata" for a generic R-Car Gen2
compatible device
- "renesas,rcar-gen3-sata" for a generic R-Car Gen3 or
RZ/G2 compatible device
- "renesas,rcar-sata" is deprecated
When compatible with the generic version nodes
must list the SoC-specific version corresponding
to the platform first followed by the generic
version.
- reg : address and length of the SATA registers;
- interrupts : must consist of one interrupt specifier.
- clocks : must contain a reference to the functional clock.
Example:
sata0: sata@ee300000 {
compatible = "renesas,sata-r8a7791", "renesas,rcar-gen2-sata";
reg = <0 0xee300000 0 0x2000>;
interrupt-parent = <&gic>;
interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp8_clks R8A7791_CLK_SATA0>;
};

45
bindings/auxdisplay/hit,hd44780.txt
View File

@@ -1,45 +0,0 @@
DT bindings for the Hitachi HD44780 Character LCD Controller
The Hitachi HD44780 Character LCD Controller is commonly used on character LCDs
that can display one or more lines of text. It exposes an M6800 bus interface,
which can be used in either 4-bit or 8-bit mode.
Required properties:
- compatible: Must contain "hit,hd44780",
- data-gpios: Must contain an array of either 4 or 8 GPIO specifiers,
referring to the GPIO pins connected to the data signal lines DB0-DB7
(8-bit mode) or DB4-DB7 (4-bit mode) of the LCD Controller's bus interface,
- enable-gpios: Must contain a GPIO specifier, referring to the GPIO pin
connected to the "E" (Enable) signal line of the LCD Controller's bus
interface,
- rs-gpios: Must contain a GPIO specifier, referring to the GPIO pin
connected to the "RS" (Register Select) signal line of the LCD Controller's
bus interface,
- display-height-chars: Height of the display, in character cells,
- display-width-chars: Width of the display, in character cells.
Optional properties:
- rw-gpios: Must contain a GPIO specifier, referring to the GPIO pin
connected to the "RW" (Read/Write) signal line of the LCD Controller's bus
interface,
- backlight-gpios: Must contain a GPIO specifier, referring to the GPIO pin
used for enabling the LCD's backlight,
- internal-buffer-width: Internal buffer width (default is 40 for displays
with 1 or 2 lines, and display-width-chars for displays with more than 2
lines).
Example:
auxdisplay {
compatible = "hit,hd44780";
data-gpios = <&hc595 0 GPIO_ACTIVE_HIGH>,
<&hc595 1 GPIO_ACTIVE_HIGH>,
<&hc595 2 GPIO_ACTIVE_HIGH>,
<&hc595 3 GPIO_ACTIVE_HIGH>;
enable-gpios = <&hc595 4 GPIO_ACTIVE_HIGH>;
rs-gpios = <&hc595 5 GPIO_ACTIVE_HIGH>;
display-height-chars = <2>;
display-width-chars = <16>;
};

96
bindings/auxdisplay/hit,hd44780.yaml Normal file
View File

@@ -0,0 +1,96 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/auxdisplay/hit,hd44780.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Hitachi HD44780 Character LCD Controller
maintainers:
- Geert Uytterhoeven <geert@linux-m68k.org>
description:
The Hitachi HD44780 Character LCD Controller is commonly used on character
LCDs that can display one or more lines of text. It exposes an M6800 bus
interface, which can be used in either 4-bit or 8-bit mode.
properties:
compatible:
const: hit,hd44780
data-gpios:
description:
GPIO pins connected to the data signal lines DB0-DB7 (8-bit mode) or
DB4-DB7 (4-bit mode) of the LCD Controller's bus interface.
oneOf:
- maxItems: 4
- maxItems: 8
enable-gpios:
description:
GPIO pin connected to the "E" (Enable) signal line of the LCD
Controller's bus interface.
maxItems: 1
rs-gpios:
description:
GPIO pin connected to the "RS" (Register Select) signal line of the LCD
Controller's bus interface.
maxItems: 1
rw-gpios:
description:
GPIO pin connected to the "RW" (Read/Write) signal line of the LCD
Controller's bus interface.
maxItems: 1
backlight-gpios:
description: GPIO pin used for enabling the LCD's backlight.
maxItems: 1
display-height-chars:
description: Height of the display, in character cells,
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 4
display-width-chars:
description: Width of the display, in character cells.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 64
internal-buffer-width:
description:
Internal buffer width (default is 40 for displays with 1 or 2 lines, and
display-width-chars for displays with more than 2 lines).
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 64
required:
- compatible
- data-gpios
- enable-gpios
- rs-gpios
- display-height-chars
- display-width-chars
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
auxdisplay {
compatible = "hit,hd44780";
data-gpios = <&hc595 0 GPIO_ACTIVE_HIGH>,
<&hc595 1 GPIO_ACTIVE_HIGH>,
<&hc595 2 GPIO_ACTIVE_HIGH>,
<&hc595 3 GPIO_ACTIVE_HIGH>;
enable-gpios = <&hc595 4 GPIO_ACTIVE_HIGH>;
rs-gpios = <&hc595 5 GPIO_ACTIVE_HIGH>;
display-height-chars = <2>;
display-width-chars = <16>;
};

83
bindings/bus/arm,integrator-ap-lm.yaml Normal file
View File

@@ -0,0 +1,83 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/arm,integrator-ap-lm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Integrator/AP Logic Module extension bus
maintainers:
- Linus Walleij <linusw@kernel.org>
description: The Integrator/AP is a prototyping platform and as such has a
site for stacking up to four logic modules (LM) designed specifically for
use with this platform. A special system controller register can be read to
determine if a logic module is connected at index 0, 1, 2 or 3. The logic
module connector is described in this binding. The logic modules per se
then have their own specific per-module bindings and they will be described
as subnodes under this logic module extension bus.
properties:
"#address-cells":
const: 1
"#size-cells":
const: 1
compatible:
items:
- const: arm,integrator-ap-lm
ranges: true
dma-ranges: true
patternProperties:
"^bus(@[0-9a-f]*)?$":
description: Nodes on the Logic Module bus represent logic modules
and are named with bus. The first module is at 0xc0000000, the second
at 0xd0000000 and so on until the top of the memory of the system at
0xffffffff. All information about the memory used by the module is
in ranges and dma-ranges.
type: object
required:
- compatible
required:
- compatible
examples:
- |
bus@c0000000 {
compatible = "arm,integrator-ap-lm";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0xc0000000 0xc0000000 0x40000000>;
dma-ranges;
bus@c0000000 {
compatible = "simple-bus";
ranges = <0x00000000 0xc0000000 0x10000000>;
/* The Logic Modules sees the Core Module 0 RAM @80000000 */
dma-ranges = <0x00000000 0x80000000 0x10000000>;
#address-cells = <1>;
#size-cells = <1>;
serial@100000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x00100000 0x1000>;
interrupts-extended = <&impd1_vic 1>;
};
impd1_vic: interrupt-controller@3000000 {
compatible = "arm,pl192-vic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x03000000 0x1000>;
valid-mask = <0x00000bff>;
interrupts-extended = <&pic 9>;
};
};
};
additionalProperties: false

90
bindings/bus/baikal,bt1-apb.yaml Normal file
View File

@@ -0,0 +1,90 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/baikal,bt1-apb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Baikal-T1 APB-bus
maintainers:
- Serge Semin <fancer.lancer@gmail.com>
description: |
Baikal-T1 CPU or DMAC MMIO requests are handled by the AMBA 3 AXI Interconnect
which routes them to the AXI-APB bridge. This interface is a single master
multiple slaves bus in turn serializing IO accesses and routing them to the
addressed APB slave devices. In case of any APB protocol collisions, slave
device not responding on timeout an IRQ is raised with an erroneous address
reported to the APB terminator (APB Errors Handler Block).
allOf:
- $ref: /schemas/simple-bus.yaml#
properties:
compatible:
contains:
const: baikal,bt1-apb
reg:
items:
- description: APB EHB MMIO registers
- description: APB MMIO region with no any device mapped
reg-names:
items:
- const: ehb
- const: nodev
interrupts:
maxItems: 1
clocks:
items:
- description: APB reference clock
clock-names:
items:
- const: pclk
resets:
items:
- description: APB domain reset line
reset-names:
items:
- const: prst
unevaluatedProperties: false
required:
- compatible
- reg
- reg-names
- interrupts
- clocks
- clock-names
examples:
- |
#include <dt-bindings/interrupt-controller/mips-gic.h>
bus@1f059000 {
compatible = "baikal,bt1-apb", "simple-bus";
reg = <0x1f059000 0x1000>,
<0x1d000000 0x2040000>;
reg-names = "ehb", "nodev";
#address-cells = <1>;
#size-cells = <1>;
ranges;
interrupts = <GIC_SHARED 16 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu_sys 1>;
clock-names = "pclk";
resets = <&ccu_sys 1>;
reset-names = "prst";
};
...

107
bindings/bus/baikal,bt1-axi.yaml Normal file
View File

@@ -0,0 +1,107 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/baikal,bt1-axi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Baikal-T1 AXI-bus
maintainers:
- Serge Semin <fancer.lancer@gmail.com>
description: |
AXI3-bus is the main communication bus of Baikal-T1 SoC connecting all
high-speed peripheral IP-cores with RAM controller and with MIPS P5600
cores. Traffic arbitration is done by means of DW AXI Interconnect (so
called AXI Main Interconnect) routing IO requests from one block to
another: from CPU to SoC peripherals and between some SoC peripherals
(mostly between peripheral devices and RAM, but also between DMA and
some peripherals). In case of any protocol error, device not responding
an IRQ is raised and a faulty situation is reported to the AXI EHB
(Errors Handler Block) embedded on top of the DW AXI Interconnect and
accessible by means of the Baikal-T1 System Controller.
allOf:
- $ref: /schemas/simple-bus.yaml#
properties:
compatible:
contains:
const: baikal,bt1-axi
reg:
minItems: 1
items:
- description: Synopsys DesignWare AXI Interconnect QoS registers
- description: AXI EHB MMIO system controller registers
reg-names:
minItems: 1
items:
- const: qos
- const: ehb
'#interconnect-cells':
const: 1
syscon:
$ref: /schemas/types.yaml#definitions/phandle
description: Phandle to the Baikal-T1 System Controller DT node
interrupts:
maxItems: 1
clocks:
items:
- description: Main Interconnect uplink reference clock
clock-names:
items:
- const: aclk
resets:
items:
- description: Main Interconnect reset line
reset-names:
items:
- const: arst
unevaluatedProperties: false
required:
- compatible
- reg
- reg-names
- syscon
- interrupts
- clocks
- clock-names
examples:
- |
#include <dt-bindings/interrupt-controller/mips-gic.h>
bus@1f05a000 {
compatible = "baikal,bt1-axi", "simple-bus";
reg = <0x1f05a000 0x1000>,
<0x1f04d110 0x8>;
reg-names = "qos", "ehb";
#address-cells = <1>;
#size-cells = <1>;
#interconnect-cells = <1>;
syscon = <&syscon>;
ranges;
interrupts = <GIC_SHARED 127 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu_axi 0>;
clock-names = "aclk";
resets = <&ccu_axi 0>;
reset-names = "arst";
};
...

35
bindings/bus/mti,mips-cdmm.yaml Normal file
View File

@@ -0,0 +1,35 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/mti,mips-cdmm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MIPS Common Device Memory Map
description: |
Defines a location of the MIPS Common Device Memory Map registers.
maintainers:
- James Hogan <jhogan@kernel.org>
properties:
compatible:
const: mti,mips-cdmm
reg:
description: |
Base address and size of an unoccupied memory region, which will be
used to map the MIPS CDMM registers block.
maxItems: 1
required:
- compatible
- reg
examples:
- |
cdmm@1bde8000 {
compatible = "mti,mips-cdmm";
reg = <0x1bde8000 0x8000>;
};
...

46
bindings/bus/renesas,bsc.txt
View File

@@ -1,46 +0,0 @@
Renesas Bus State Controller (BSC)
==================================
The Renesas Bus State Controller (BSC, sometimes called "LBSC within Bus
Bridge", or "External Bus Interface") can be found in several Renesas ARM SoCs.
It provides an external bus for connecting multiple external devices to the
SoC, driving several chip select lines, for e.g. NOR FLASH, Ethernet and USB.
While the BSC is a fairly simple memory-mapped bus, it may be part of a PM
domain, and may have a gateable functional clock.
Before a device connected to the BSC can be accessed, the PM domain
containing the BSC must be powered on, and the functional clock
driving the BSC must be enabled.
The bindings for the BSC extend the bindings for "simple-pm-bus".
Required properties
- compatible: Must contain an SoC-specific value, and "renesas,bsc" and
"simple-pm-bus" as fallbacks.
SoC-specific values can be:
"renesas,bsc-r8a73a4" for R-Mobile APE6 (r8a73a4)
"renesas,bsc-sh73a0" for SH-Mobile AG5 (sh73a0)
- #address-cells, #size-cells, ranges: Must describe the mapping between
parent address and child address spaces.
- reg: Must contain the base address and length to access the bus controller.
Optional properties:
- interrupts: Must contain a reference to the BSC interrupt, if available.
- clocks: Must contain a reference to the functional clock, if available.
- power-domains: Must contain a reference to the PM domain, if available.
Example:
bsc: bus@fec10000 {
compatible = "renesas,bsc-sh73a0", "renesas,bsc",
"simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x20000000>;
reg = <0xfec10000 0x400>;
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&zb_clk>;
power-domains = <&pd_a4s>;
};

44
bindings/bus/simple-pm-bus.txt
View File

@@ -1,44 +0,0 @@
Simple Power-Managed Bus
========================
A Simple Power-Managed Bus is a transparent bus that doesn't need a real
driver, as it's typically initialized by the boot loader.
However, its bus controller is part of a PM domain, or under the control of a
functional clock. Hence, the bus controller's PM domain and/or clock must be
enabled for child devices connected to the bus (either on-SoC or externally)
to function.
While "simple-pm-bus" follows the "simple-bus" set of properties, as specified
in the Devicetree Specification, it is not an extension of "simple-bus".
Required properties:
- compatible: Must contain at least "simple-pm-bus".
Must not contain "simple-bus".
It's recommended to let this be preceded by one or more
vendor-specific compatible values.
- #address-cells, #size-cells, ranges: Must describe the mapping between
parent address and child address spaces.
Optional platform-specific properties for clock or PM domain control (at least
one of them is required):
- clocks: Must contain a reference to the functional clock(s),
- power-domains: Must contain a reference to the PM domain.
Please refer to the binding documentation for the clock and/or PM domain
providers for more details.
Example:
bsc: bus@fec10000 {
compatible = "renesas,bsc-sh73a0", "renesas,bsc",
"simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x20000000>;
reg = <0xfec10000 0x400>;
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&zb_clk>;
power-domains = <&pd_a4s>;
};

96
bindings/bus/socionext,uniphier-system-bus.yaml Normal file
View File

@@ -0,0 +1,96 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/socionext,uniphier-system-bus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: UniPhier System Bus
description: |
The UniPhier System Bus is an external bus that connects on-board devices to
the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
some control signals. It supports up to 8 banks (chip selects).
Before any access to the bus, the bus controller must be configured; the bus
controller registers provide the control for the translation from the offset
within each bank to the CPU-viewed address. The needed setup includes the
base address, the size of each bank. Optionally, some timing parameters can
be optimized for faster bus access.
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
properties:
compatible:
const: socionext,uniphier-system-bus
reg:
maxItems: 1
"#address-cells":
description: |
The first cell is the bank number (chip select).
The second cell is the address offset within the bank.
const: 2
"#size-cells":
const: 1
ranges:
description: |
Provide address translation from the System Bus to the parent bus.
Note:
The address region(s) that can be assigned for the System Bus is
implementation defined. Some SoCs can use 0x00000000-0x0fffffff and
0x40000000-0x4fffffff, while other SoCs only 0x40000000-0x4fffffff.
There might be additional limitations depending on SoCs and the boot mode.
The address translation is arbitrary as long as the banks are assigned in
the supported address space with the required alignment and they do not
overlap one another.
For example, it is possible to map:
bank 0 to 0x42000000-0x43ffffff, bank 5 to 0x46000000-0x46ffffff
It is also possible to map:
bank 0 to 0x48000000-0x49ffffff, bank 5 to 0x44000000-0x44ffffff
There is no reason to stick to a particular translation mapping, but the
"ranges" property should provide a "reasonable" default that is known to
work. The software should initialize the bus controller according to it.
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- ranges
examples:
- |
// In this example,
// - the Ethernet device is connected at the offset 0x01f00000 of CS1 and
// mapped to 0x43f00000 of the parent bus.
// - the UART device is connected at the offset 0x00200000 of CS5 and
// mapped to 0x46200000 of the parent bus.
system-bus@58c00000 {
compatible = "socionext,uniphier-system-bus";
reg = <0x58c00000 0x400>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <1 0x00000000 0x42000000 0x02000000>,
<5 0x00000000 0x46000000 0x01000000>;
ethernet@1,1f00000 {
compatible = "smsc,lan9115";
reg = <1 0x01f00000 0x1000>;
interrupts = <0 48 4>;
phy-mode = "mii";
};
serial@5,200000 {
compatible = "ns16550a";
reg = <5 0x00200000 0x20>;
interrupts = <0 49 4>;
clock-frequency = <12288000>;
};
};

1
bindings/bus/ti-sysc.txt
View File

@@ -38,6 +38,7 @@ Required standard properties:
"ti,sysc-dra7-mcasp"
"ti,sysc-usb-host-fs"
"ti,sysc-dra7-mcan"
"ti,sysc-pruss"
- reg shall have register areas implemented for the interconnect
target module in question such as revision, sysc and syss

66
bindings/bus/uniphier-system-bus.txt
View File

@@ -1,66 +0,0 @@
UniPhier System Bus
The UniPhier System Bus is an external bus that connects on-board devices to
the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
some control signals. It supports up to 8 banks (chip selects).
Before any access to the bus, the bus controller must be configured; the bus
controller registers provide the control for the translation from the offset
within each bank to the CPU-viewed address. The needed setup includes the base
address, the size of each bank. Optionally, some timing parameters can be
optimized for faster bus access.
Required properties:
- compatible: should be "socionext,uniphier-system-bus".
- reg: offset and length of the register set for the bus controller device.
- #address-cells: should be 2. The first cell is the bank number (chip select).
The second cell is the address offset within the bank.
- #size-cells: should be 1.
- ranges: should provide a proper address translation from the System Bus to
the parent bus.
Note:
The address region(s) that can be assigned for the System Bus is implementation
defined. Some SoCs can use 0x00000000-0x0fffffff and 0x40000000-0x4fffffff,
while other SoCs can only use 0x40000000-0x4fffffff. There might be additional
limitations depending on SoCs and the boot mode. The address translation is
arbitrary as long as the banks are assigned in the supported address space with
the required alignment and they do not overlap one another.
For example, it is possible to map:
bank 0 to 0x42000000-0x43ffffff, bank 5 to 0x46000000-0x46ffffff
It is also possible to map:
bank 0 to 0x48000000-0x49ffffff, bank 5 to 0x44000000-0x44ffffff
There is no reason to stick to a particular translation mapping, but the
"ranges" property should provide a "reasonable" default that is known to work.
The software should initialize the bus controller according to it.
Example:
system-bus {
compatible = "socionext,uniphier-system-bus";
reg = <0x58c00000 0x400>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <1 0x00000000 0x42000000 0x02000000
5 0x00000000 0x46000000 0x01000000>;
ethernet@1,01f00000 {
compatible = "smsc,lan9115";
reg = <1 0x01f00000 0x1000>;
interrupts = <0 48 4>
phy-mode = "mii";
};
uart@5,00200000 {
compatible = "ns16550a";
reg = <5 0x00200000 0x20>;
interrupts = <0 49 4>
clock-frequency = <12288000>;
};
};
In this example,
- the Ethernet device is connected at the offset 0x01f00000 of CS1 and
mapped to 0x43f00000 of the parent bus.
- the UART device is connected at the offset 0x00200000 of CS5 and
mapped to 0x46200000 of the parent bus.

54
bindings/chrome/google,cros-ec-typec.yaml Normal file
View File

@@ -0,0 +1,54 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/chrome/google,cros-ec-typec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Google Chrome OS EC(Embedded Controller) Type C port driver.
maintainers:
- Benson Leung <bleung@chromium.org>
- Prashant Malani <pmalani@chromium.org>
description:
Chrome OS devices have an Embedded Controller(EC) which has access to
Type C port state. This node is intended to allow the host to read and
control the Type C ports. The node for this device should be under a
cros-ec node like google,cros-ec-spi.
properties:
compatible:
const: google,cros-ec-typec
connector:
$ref: /schemas/connector/usb-connector.yaml#
required:
- compatible
examples:
- |+
spi0 {
#address-cells = <1>;
#size-cells = <0>;
cros_ec: ec@0 {
compatible = "google,cros-ec-spi";
reg = <0>;
typec {
compatible = "google,cros-ec-typec";
#address-cells = <1>;
#size-cells = <0>;
connector@0 {
compatible = "usb-c-connector";
reg = <0>;
power-role = "dual";
data-role = "dual";
try-power-role = "source";
};
};
};
};

103
bindings/clock/arm,syscon-icst.yaml Normal file
View File

@@ -0,0 +1,103 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/arm,syscon-icst.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM System Controller ICST Clocks
maintainers:
- Linus Walleij <linusw@kernel.org>
description: |
The ICS525 and ICS307 oscillators are produced by Integrated
Devices Technology (IDT). ARM integrated these oscillators deeply into their
reference designs by adding special control registers that manage such
oscillators to their system controllers.
The various ARM system controllers contain logic to serialize and initialize
an ICST clock request after a write to the 32 bit register at an offset
into the system controller. Furthermore, to even be able to alter one of
these frequencies, the system controller must first be unlocked by
writing a special token to another offset in the system controller.
Some ARM hardware contain special versions of the serial interface that only
connects the low 8 bits of the VDW (missing one bit), hard-wires RDW to
different values and sometimes also hard-wires the output divider. They
therefore have special compatible strings as per this table (the OD value is
the value on the pins, not the resulting output divider).
In the core modules and logic tiles, the ICST is a configurable clock fed
from a 24 MHz clock on the motherboard (usually the main crystal) used for
generating e.g. video clocks. It is located on the core module and there is
only one of these. This clock node must be a subnode of the core module.
Hardware variant RDW OD VDW
Integrator/AP 22 1 Bit 8 0, rest variable
integratorap-cm
Integrator/AP 46 3 Bit 8 0, rest variable
integratorap-sys
Integrator/AP 22 or 1 17 or (33 or 25 MHz)
integratorap-pci 14 1 14
Integrator/CP 22 variable Bit 8 0, rest variable
integratorcp-cm-core
Integrator/CP 22 variable Bit 8 0, rest variable
integratorcp-cm-mem
The ICST oscillator must be provided inside a system controller node.
properties:
"#clock-cells":
const: 0
compatible:
enum:
- arm,syscon-icst525
- arm,syscon-icst307
- arm,syscon-icst525-integratorap-cm
- arm,syscon-icst525-integratorap-sys
- arm,syscon-icst525-integratorap-pci
- arm,syscon-icst525-integratorcp-cm-core
- arm,syscon-icst525-integratorcp-cm-mem
- arm,integrator-cm-auxosc
- arm,versatile-cm-auxosc
- arm,impd-vco1
- arm,impd-vco2
clocks:
description: Parent clock for the ICST VCO
maxItems: 1
clock-output-names:
maxItems: 1
lock-offset:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: Offset to the unlocking register for the oscillator
vco-offset:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: Offset to the VCO register for the oscillator
required:
- "#clock-cells"
- compatible
- clocks
examples:
- |
vco1: clock {
compatible = "arm,impd1-vco1";
#clock-cells = <0>;
lock-offset = <0x08>;
vco-offset = <0x00>;
clocks = <&sysclk>;
clock-output-names = "IM-PD1-VCO1";
};
...

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