samsung_sm8750/android_kernel_samsung_sm8750-devicetrees
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

dt-bindings: Add devicetree bindings

Browse Source 
Add snapshot of device tree bindings from keystone common kernel, branch
"android-mainline-keystone-qcom-release" at c4c12103f9c0 ("Snap for 9228065
from e32903b9a63bb558df8b803b076619c53c16baad to
android-mainline-keystone-qcom-release").

Change-Id: I7682079615cbd9f29340a5c1f2a1d84ec441a1f1
Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
This commit is contained in:
Melody Olvera
2023-04-03 14:38:11 -07:00
parent c334acf377
commit 6f18ce8026
4878 changed files with 424312 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

87
bindings/bus/allwinner,sun50i-a64-de2.yaml Normal file
View File

@@ -0,0 +1,87 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/allwinner,sun50i-a64-de2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A64 Display Engine Bus
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
properties:
$nodename:
pattern: "^bus(@[0-9a-f]+)?$"
"#address-cells":
const: 1
"#size-cells":
const: 1
compatible:
oneOf:
- const: allwinner,sun50i-a64-de2
- items:
- const: allwinner,sun50i-h6-de3
- const: allwinner,sun50i-a64-de2
reg:
maxItems: 1
allwinner,sram:
description:
The SRAM that needs to be claimed to access the display engine
bus.
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to SRAM
- description: register value for device
ranges: true
patternProperties:
# All other properties should be child nodes with unit-address and 'reg'
"^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+$":
type: object
properties:
reg:
maxItems: 1
required:
- reg
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- ranges
- allwinner,sram
additionalProperties: false
examples:
- |
bus@1000000 {
compatible = "allwinner,sun50i-a64-de2";
reg = <0x1000000 0x400000>;
allwinner,sram = <&de2_sram 1>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1000000 0x400000>;
display_clocks: clock@0 {
compatible = "allwinner,sun50i-a64-de2-clk";
reg = <0x0 0x100000>;
clocks = <&ccu 52>, <&ccu 99>;
clock-names = "bus", "mod";
resets = <&ccu 30>;
#clock-cells = <1>;
#reset-cells = <1>;
};
};
...

81
bindings/bus/allwinner,sun8i-a23-rsb.yaml Normal file
View File

@@ -0,0 +1,81 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/allwinner,sun8i-a23-rsb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A23 RSB
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
compatible:
oneOf:
- const: allwinner,sun8i-a23-rsb
- items:
- enum:
- allwinner,sun8i-a83t-rsb
- allwinner,sun50i-h616-rsb
- const: allwinner,sun8i-a23-rsb
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
resets:
maxItems: 1
clock-frequency:
minimum: 1
maximum: 20000000
patternProperties:
"^.*@[0-9a-fA-F]+$":
type: object
properties:
reg:
maxItems: 1
required:
- reg
required:
- compatible
- reg
- interrupts
- clocks
- resets
examples:
- |
rsb@1f03400 {
compatible = "allwinner,sun8i-a23-rsb";
reg = <0x01f03400 0x400>;
interrupts = <0 39 4>;
clocks = <&apb0_gates 3>;
clock-frequency = <3000000>;
resets = <&apb0_rst 3>;
#address-cells = <1>;
#size-cells = <0>;
pmic@3e3 {
reg = <0x3e3>;
/* ... */
};
};
additionalProperties: false

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

53
bindings/bus/brcm,bus-axi.txt Normal file
View File

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

66
bindings/bus/brcm,gisb-arb.yaml Normal file
View File

@@ -0,0 +1,66 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/brcm,gisb-arb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom GISB bus Arbiter controller
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
compatible:
oneOf:
- items:
- enum:
- brcm,bcm7445-gisb-arb # for other 28nm chips
- const: brcm,gisb-arb
- items:
- enum:
- brcm,bcm7278-gisb-arb # for V7 28nm chips
- brcm,bcm7435-gisb-arb # for newer 40nm chips
- brcm,bcm7400-gisb-arb # for older 40nm chips and all 65nm chips
- brcm,bcm7038-gisb-arb # for 130nm chips
- brcm,gisb-arb # fallback compatible
reg:
maxItems: 1
interrupts:
minItems: 2
items:
- description: timeout interrupt line
- description: target abort interrupt line
- description: breakpoint interrupt line
brcm,gisb-arb-master-mask:
$ref: /schemas/types.yaml#/definitions/uint32
description: >
32-bits wide bitmask used to specify which GISB masters are valid at the
system level
brcm,gisb-arb-master-names:
$ref: /schemas/types.yaml#/definitions/string-array
description: >
String list of the litteral name of the GISB masters. Should match the
number of bits set in brcm,gisb-master-mask and the order in which they
appear from MSB to LSB.
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
gisb-arb@f0400000 {
compatible = "brcm,gisb-arb";
reg = <0xf0400000 0x800>;
interrupts = <0>, <2>;
interrupt-parent = <&sun_l2_intc>;
brcm,gisb-arb-master-mask = <0x7>;
brcm,gisb-arb-master-names = "bsp_0", "scpu_0", "cpu_0";
};

68
bindings/bus/fsl,spba-bus.yaml Normal file
View File

@@ -0,0 +1,68 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/fsl,spba-bus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Shared Peripherals Bus Interface
maintainers:
- Shawn Guo <shawnguo@kernel.org>
description: |
A simple bus enabling access to shared peripherals.
The "spba-bus" follows the "simple-bus" set of properties, as
specified in the Devicetree Specification. It is an extension of
"simple-bus" because the SDMA controller uses this compatible flag to
determine which peripherals are available to it and the range over which
the SDMA can access. There are no special clocks for the bus, because
the SDMA controller itself has its interrupt and clock assignments.
select:
properties:
compatible:
contains:
const: fsl,spba-bus
required:
- compatible
properties:
$nodename:
pattern: "^spba-bus(@[0-9a-f]+)?$"
compatible:
items:
- const: fsl,spba-bus
- const: simple-bus
'#address-cells':
enum: [ 1, 2 ]
'#size-cells':
enum: [ 1, 2 ]
reg:
maxItems: 1
ranges: true
required:
- compatible
- '#address-cells'
- '#size-cells'
- reg
- ranges
additionalProperties:
type: object
examples:
- |
spba-bus@30000000 {
compatible = "fsl,spba-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x30000000 0x100000>;
ranges;
};

117
bindings/bus/imx-weim.txt Normal file
View File

@@ -0,0 +1,117 @@
Device tree bindings for i.MX Wireless External Interface Module (WEIM)
The term "wireless" does not imply that the WEIM is literally an interface
without wires. It simply means that this module was originally designed for
wireless and mobile applications that use low-power technology.
The actual devices are instantiated from the child nodes of a WEIM node.
Required properties:
- compatible: Should contain one of the following:
"fsl,imx1-weim"
"fsl,imx27-weim"
"fsl,imx51-weim"
"fsl,imx50-weim"
"fsl,imx6q-weim"
- reg: A resource specifier for the register space
(see the example below)
- clocks: the clock, see the example below.
- #address-cells: Must be set to 2 to allow memory address translation
- #size-cells: Must be set to 1 to allow CS address passing
- ranges: Must be set up to reflect the memory layout with four
integer values for each chip-select line in use:
<cs-number> 0 <physical address of mapping> <size>
Optional properties:
- fsl,weim-cs-gpr: For "fsl,imx50-weim" and "fsl,imx6q-weim" type of
devices, it should be the phandle to the system General
Purpose Register controller that contains WEIM CS GPR
register, e.g. IOMUXC_GPR1 on i.MX6Q. IOMUXC_GPR1[11:0]
should be set up as one of the following 4 possible
values depending on the CS space configuration.
IOMUXC_GPR1[11:0] CS0 CS1 CS2 CS3
---------------------------------------------
05 128M 0M 0M 0M
033 64M 64M 0M 0M
0113 64M 32M 32M 0M
01111 32M 32M 32M 32M
In case that the property is absent, the reset value or
what bootloader sets up in IOMUXC_GPR1[11:0] will be
used.
- fsl,burst-clk-enable For "fsl,imx50-weim" and "fsl,imx6q-weim" type of
devices, the presence of this property indicates that
the weim bus should operate in Burst Clock Mode.
- fsl,continuous-burst-clk Make Burst Clock to output continuous clock.
Without this option Burst Clock will output clock
only when necessary. This takes effect only if
"fsl,burst-clk-enable" is set.
Timing property for child nodes. It is mandatory, not optional.
- fsl,weim-cs-timing: The timing array, contains timing values for the
child node. We get the CS indexes from the address
ranges in the child node's "reg" property.
The number of registers depends on the selected chip:
For i.MX1, i.MX21 ("fsl,imx1-weim") there are two
registers: CSxU, CSxL.
For i.MX25, i.MX27, i.MX31 and i.MX35 ("fsl,imx27-weim")
there are three registers: CSCRxU, CSCRxL, CSCRxA.
For i.MX50, i.MX53 ("fsl,imx50-weim"),
i.MX51 ("fsl,imx51-weim") and i.MX6Q ("fsl,imx6q-weim")
there are six registers: CSxGCR1, CSxGCR2, CSxRCR1,
CSxRCR2, CSxWCR1, CSxWCR2.
Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM:
weim: weim@21b8000 {
compatible = "fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
clocks = <&clks 196>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x08000000 0x08000000>;
fsl,weim-cs-gpr = <&gpr>;
nor@0,0 {
compatible = "cfi-flash";
reg = <0 0 0x02000000>;
#address-cells = <1>;
#size-cells = <1>;
bank-width = <2>;
fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
0x0000c000 0x1404a38e 0x00000000>;
};
};
Example for an imx6q-based board, a multi-chipselect device connected to WEIM:
In this case, both chip select 0 and 1 will be configured with the same timing
array values.
weim: weim@21b8000 {
compatible = "fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
clocks = <&clks 196>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x08000000 0x02000000
1 0 0x0a000000 0x02000000
2 0 0x0c000000 0x02000000
3 0 0x0e000000 0x02000000>;
fsl,weim-cs-gpr = <&gpr>;
acme@0 {
compatible = "acme,whatever";
reg = <0 0 0x100>, <0 0x400000 0x800>,
<1 0x400000 0x800>;
fsl,weim-cs-timing = <0x024400b1 0x00001010 0x20081100
0x00000000 0xa0000240 0x00000000>;
};
};

168
bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml Normal file
View File

@@ -0,0 +1,168 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/intel,ixp4xx-expansion-bus-controller.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel IXP4xx Expansion Bus Controller
description: |
The IXP4xx expansion bus controller handles access to devices on the
memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
including IXP42x, IXP43x, IXP45x and IXP46x.
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
properties:
$nodename:
pattern: '^bus@[0-9a-f]+$'
compatible:
items:
- enum:
- intel,ixp42x-expansion-bus-controller
- intel,ixp43x-expansion-bus-controller
- intel,ixp45x-expansion-bus-controller
- intel,ixp46x-expansion-bus-controller
- const: syscon
reg:
description: Control registers for the expansion bus, these are not
inside the memory range handled by the expansion bus.
maxItems: 1
native-endian:
$ref: /schemas/types.yaml#/definitions/flag
description: The IXP4xx has a peculiar MMIO access scheme, as it changes
the access pattern for words (swizzling) on the bus depending on whether
the SoC is running in big-endian or little-endian mode. Thus the
registers must always be accessed using native endianness.
"#address-cells":
description: |
The first cell is the chip select number.
The second cell is the address offset within the bank.
const: 2
"#size-cells":
const: 1
ranges: true
dma-ranges: true
patternProperties:
"^.*@[0-7],[0-9a-f]+$":
description: Devices attached to chip selects are represented as
subnodes.
type: object
properties:
intel,ixp4xx-eb-t1:
description: Address timing, extend address phase with n cycles.
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 3
intel,ixp4xx-eb-t2:
description: Setup chip select timing, extend setup phase with n cycles.
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 3
intel,ixp4xx-eb-t3:
description: Strobe timing, extend strobe phase with n cycles.
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 15
intel,ixp4xx-eb-t4:
description: Hold timing, extend hold phase with n cycles.
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 3
intel,ixp4xx-eb-t5:
description: Recovery timing, extend recovery phase with n cycles.
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 15
intel,ixp4xx-eb-cycle-type:
description: The type of cycles to use on the expansion bus for this
chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
intel,ixp4xx-eb-byte-access-on-halfword:
description: Allow byte read access on half word devices.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
intel,ixp4xx-eb-hpi-hrdy-pol-high:
description: Set HPI HRDY polarity to active high when using HPI.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
intel,ixp4xx-eb-mux-address-and-data:
description: Multiplex address and data on the data bus.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
intel,ixp4xx-eb-ahb-split-transfers:
description: Enable AHB split transfers.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
intel,ixp4xx-eb-write-enable:
description: Enable write cycles.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
intel,ixp4xx-eb-byte-access:
description: Expansion bus uses only 8 bits. The default is to use
16 bits.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1]
required:
- compatible
- reg
- native-endian
- "#address-cells"
- "#size-cells"
- ranges
- dma-ranges
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
bus@50000000 {
compatible = "intel,ixp42x-expansion-bus-controller", "syscon";
reg = <0xc4000000 0x28>;
native-endian;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x01000000>,
<1 0x0 0x51000000 0x01000000>;
dma-ranges = <0 0x0 0x50000000 0x01000000>,
<1 0x0 0x51000000 0x01000000>;
flash@0,0 {
compatible = "intel,ixp4xx-flash", "cfi-flash";
bank-width = <2>;
reg = <0 0x00000000 0x1000000>;
intel,ixp4xx-eb-t3 = <3>;
intel,ixp4xx-eb-cycle-type = <0>;
intel,ixp4xx-eb-byte-access-on-halfword = <1>;
intel,ixp4xx-eb-write-enable = <1>;
intel,ixp4xx-eb-byte-access = <0>;
};
serial@1,0 {
compatible = "exar,xr16l2551", "ns8250";
reg = <1 0x00000000 0x10>;
interrupt-parent = <&gpio0>;
interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
clock-frequency = <1843200>;
intel,ixp4xx-eb-t3 = <3>;
intel,ixp4xx-eb-cycle-type = <1>;
intel,ixp4xx-eb-write-enable = <1>;
intel,ixp4xx-eb-byte-access = <1>;
};
};

46
bindings/bus/moxtet.txt Normal file
View File

@@ -0,0 +1,46 @@
Turris Mox module status and configuration bus (over SPI)
Required properties:
- compatible : Should be "cznic,moxtet"
- #address-cells : Has to be 1
- #size-cells : Has to be 0
- spi-cpol : Required inverted clock polarity
- spi-cpha : Required shifted clock phase
- interrupts : Must contain reference to the shared interrupt line
- interrupt-controller : Required
- #interrupt-cells : Has to be 1
For other required and optional properties of SPI slave nodes please refer to
../spi/spi-bus.txt.
Required properties of subnodes:
- reg : Should be position on the Moxtet bus (how many Moxtet
modules are between this module and CPU module, so
either 0 or a positive integer)
The driver finds the devices connected to the bus by itself, but it may be
needed to reference some of them from other parts of the device tree. In that
case the devices can be defined as subnodes of the moxtet node.
Example:
moxtet@1 {
compatible = "cznic,moxtet";
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
spi-max-frequency = <10000000>;
spi-cpol;
spi-cpha;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&gpiosb>;
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
moxtet_sfp: gpio@0 {
compatible = "cznic,moxtet-gpio";
gpio-controller;
#gpio-cells = <2>;
reg = <0>;
}
};

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

@@ -0,0 +1,37 @@
# 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
additionalProperties: false
examples:
- |
cdmm@1bde8000 {
compatible = "mti,mips-cdmm";
reg = <0x1bde8000 0x8000>;
};
...

276
bindings/bus/mvebu-mbus.txt Normal file
View File

@@ -0,0 +1,276 @@
* Marvell MBus
Required properties:
- compatible: Should be set to one of the following:
marvell,armada370-mbus
marvell,armadaxp-mbus
marvell,armada375-mbus
marvell,armada380-mbus
marvell,kirkwood-mbus
marvell,dove-mbus
marvell,orion5x-88f5281-mbus
marvell,orion5x-88f5182-mbus
marvell,orion5x-88f5181-mbus
marvell,orion5x-88f6183-mbus
marvell,mv78xx0-mbus
- address-cells: Must be '2'. The first cell for the MBus ID encoding,
the second cell for the address offset within the window.
- size-cells: Must be '1'.
- ranges: Must be set up to provide a proper translation for each child.
See the examples below.
- controller: Contains a single phandle referring to the MBus controller
node. This allows to specify the node that contains the
registers that control the MBus, which is typically contained
within the internal register window (see below).
Optional properties:
- pcie-mem-aperture: This optional property contains the aperture for
the memory region of the PCIe driver.
If it's defined, it must encode the base address and
size for the address decoding windows allocated for
the PCIe memory region.
- pcie-io-aperture: Just as explained for the above property, this
optional property contains the aperture for the
I/O region of the PCIe driver.
* Marvell MBus controller
Required properties:
- compatible: Should be set to "marvell,mbus-controller".
- reg: Device's register space.
Two or three entries are expected (see the examples below):
the first one controls the devices decoding window,
the second one controls the SDRAM decoding window and
the third controls the MBus bridge (only with the
marvell,armada370-mbus and marvell,armadaxp-mbus
compatible strings)
Example:
soc {
compatible = "marvell,armada370-mbus", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
controller = <&mbusc>;
pcie-mem-aperture = <0xe0000000 0x8000000>;
pcie-io-aperture = <0xe8000000 0x100000>;
internal-regs {
compatible = "simple-bus";
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
};
};
** MBus address decoding window specification
The MBus children address space is comprised of two cells: the first one for
the window ID and the second one for the offset within the window.
In order to allow to describe valid and non-valid window entries, the
following encoding is used:
0xSIAA0000 0x00oooooo
Where:
S = 0x0 for a MBus valid window
S = 0xf for a non-valid window (see below)
If S = 0x0, then:
I = 4-bit window target ID
AA = windpw attribute
If S = 0xf, then:
I = don't care
AA = 1 for internal register
Following the above encoding, for each ranges entry for a MBus valid window
(S = 0x0), an address decoding window is allocated. On the other side,
entries for translation that do not correspond to valid windows (S = 0xf)
are skipped.
soc {
compatible = "marvell,armada370-mbus", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
controller = <&mbusc>;
ranges = <0xf0010000 0 0 0xd0000000 0x100000
0x01e00000 0 0 0xfff00000 0x100000>;
bootrom {
compatible = "marvell,bootrom";
reg = <0x01e00000 0 0x100000>;
};
/* other children */
...
internal-regs {
compatible = "simple-bus";
ranges = <0 0xf0010000 0 0x100000>;
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
};
};
In the shown example, the translation entry in the 'ranges' property is what
makes the MBus driver create a static decoding window for the corresponding
given child device. Note that the binding does not require child nodes to be
present. Of course, child nodes are needed to probe the devices.
Since each window is identified by its target ID and attribute ID there's
a special macro that can be use to simplify the translation entries:
#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
Using this macro, the above example would be:
soc {
compatible = "marvell,armada370-mbus", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
controller = <&mbusc>;
ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>;
bootrom {
compatible = "marvell,bootrom";
reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
};
/* other children */
...
internal-regs {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* other children */
...
};
};
** About the window base address
Remember the MBus controller allows a great deal of flexibility for choosing
the decoding window base address. When planning the device tree layout it's
possible to choose any address as the base address, provided of course there's
a region large enough available, and with the required alignment.
Yet in other words: there's nothing preventing us from setting a base address
of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is
unused.
** Window allocation policy
The mbus-node ranges property defines a set of mbus windows that are expected
to be set by the operating system and that are guaranteed to be free of overlaps
with one another or with the system memory ranges.
Each entry in the property refers to exactly one window. If the operating system
chooses to use a different set of mbus windows, it must ensure that any address
translations performed from downstream devices are adapted accordingly.
The operating system may insert additional mbus windows that do not conflict
with the ones listed in the ranges, e.g. for mapping PCIe devices.
As a special case, the internal register window must be set up by the boot
loader at the address listed in the ranges property, since access to that region
is needed to set up the other windows.
** Example
See the example below, where a more complete device tree is shown:
soc {
compatible = "marvell,armadaxp-mbus", "simple-bus";
controller = <&mbusc>;
ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 /* internal-regs */
MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
bootrom {
compatible = "marvell,bootrom";
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
devbus-bootcs {
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
/* NOR */
nor {
compatible = "cfi-flash";
reg = <0 0x8000000>;
bank-width = <2>;
};
};
pcie-controller {
compatible = "marvell,armada-xp-pcie";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
ranges =
<0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */
0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */
0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */
0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */
0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */
0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
pcie@1,0 {
/* Port 0, Lane 0 */
};
};
internal-regs {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
mbusc: mbus-controller@20000 {
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
interrupt-controller@20000 {
reg = <0x20a00 0x2d0>, <0x21070 0x58>;
};
};
};

128
bindings/bus/nvidia,tegra20-gmi.txt Normal file
View File

@@ -0,0 +1,128 @@
Device tree bindings for NVIDIA Tegra Generic Memory Interface bus
The Generic Memory Interface bus enables memory transfers between internal and
external memory. Can be used to attach various high speed devices such as
synchronous/asynchronous NOR, FPGA, UARTS and more.
The actual devices are instantiated from the child nodes of a GMI node.
Required properties:
- compatible : Should contain one of the following:
For Tegra20 must contain "nvidia,tegra20-gmi".
For Tegra30 must contain "nvidia,tegra30-gmi".
- reg: Should contain GMI controller registers location and length.
- clocks: Must contain an entry for each entry in clock-names.
- clock-names: Must include the following entries: "gmi"
- resets : Must contain an entry for each entry in reset-names.
- reset-names : Must include the following entries: "gmi"
- #address-cells: The number of cells used to represent physical base
addresses in the GMI address space. Should be 2.
- #size-cells: The number of cells used to represent the size of an address
range in the GMI address space. Should be 1.
- ranges: Must be set up to reflect the memory layout with three integer values
for each chip-select line in use (only one entry is supported, see below
comments):
<cs-number> <offset> <physical address of mapping> <size>
Note that the GMI controller does not have any internal chip-select address
decoding, because of that chip-selects either need to be managed via software
or by employing external chip-select decoding logic.
If external chip-select logic is used to support multiple devices it is assumed
that the devices use the same timing and so are probably the same type. It also
assumes that they can fit in the 256MB address range. In this case only one
child device is supported which represents the active chip-select line, see
examples for more insight.
The chip-select number is decoded from the child nodes second address cell of
'ranges' property, if 'ranges' property is not present or empty chip-select will
then be decoded from the first cell of the 'reg' property.
Optional child cs node properties:
- nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit.
- nvidia,snor-mux-mode: Enable address/data MUX mode.
- nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before data.
If omitted it will be asserted with data.
- nvidia,snor-rdy-active-high: RDY signal is active high
- nvidia,snor-adv-active-high: ADV signal is active high
- nvidia,snor-oe-active-high: WE/OE signal is active high
- nvidia,snor-cs-active-high: CS signal is active high
Note that there is some special handling for the timing values.
From Tegra TRM:
Programming 0 means 1 clock cycle: actual cycle = programmed cycle + 1
- nvidia,snor-muxed-width: Number of cycles MUX address/data asserted on the
bus. Valid values are 0-15, default is 1
- nvidia,snor-hold-width: Number of cycles CE stays asserted after the
de-assertion of WR_N (in case of SLAVE/MASTER Request) or OE_N
(in case of MASTER Request). Valid values are 0-15, default is 1
- nvidia,snor-adv-width: Number of cycles during which ADV stays asserted.
Valid values are 0-15, default is 1.
- nvidia,snor-ce-width: Number of cycles before CE is asserted.
Valid values are 0-15, default is 4
- nvidia,snor-we-width: Number of cycles during which WE stays asserted.
Valid values are 0-15, default is 1
- nvidia,snor-oe-width: Number of cycles during which OE stays asserted.
Valid values are 0-255, default is 1
- nvidia,snor-wait-width: Number of cycles before READY is asserted.
Valid values are 0-255, default is 3
Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap the
controllers with a simple-bus node since they are all connected to the same
chip-select (CS4), in this example external address decoding is provided:
gmi@70009000 {
compatible = "nvidia,tegra20-gmi";
reg = <0x70009000 0x1000>;
#address-cells = <2>;
#size-cells = <1>;
clocks = <&tegra_car TEGRA20_CLK_NOR>;
clock-names = "gmi";
resets = <&tegra_car 42>;
reset-names = "gmi";
ranges = <4 0 0xd0000000 0xfffffff>;
bus@4,0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 4 0 0x40100>;
nvidia,snor-mux-mode;
nvidia,snor-adv-active-high;
can@0 {
reg = <0 0x100>;
...
};
can@40000 {
reg = <0x40000 0x100>;
...
};
};
};
Example with one SJA1000 CAN controller connected to the GMI bus
on CS4:
gmi@70009000 {
compatible = "nvidia,tegra20-gmi";
reg = <0x70009000 0x1000>;
#address-cells = <2>;
#size-cells = <1>;
clocks = <&tegra_car TEGRA20_CLK_NOR>;
clock-names = "gmi";
resets = <&tegra_car 42>;
reset-names = "gmi";
ranges = <4 0 0xd0000000 0xfffffff>;
can@4,0 {
reg = <4 0 0x100>;
nvidia,snor-mux-mode;
nvidia,snor-adv-active-high;
...
};
};

83
bindings/bus/nvidia,tegra210-aconnect.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/nvidia,tegra210-aconnect.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra ACONNECT Bus
description: |
The Tegra ACONNECT bus is an AXI switch which is used to connnect various
components inside the Audio Processing Engine (APE). All CPU accesses to
the APE subsystem go through the ACONNECT via an APB to AXI wrapper. All
devices accessed via the ACONNNECT are described by child-nodes.
maintainers:
- Jon Hunter <jonathanh@nvidia.com>
properties:
compatible:
oneOf:
- const: nvidia,tegra210-aconnect
- items:
- enum:
- nvidia,tegra234-aconnect
- nvidia,tegra186-aconnect
- nvidia,tegra194-aconnect
- const: nvidia,tegra210-aconnect
clocks:
items:
- description: Must contain the entry for APE clock
- description: Must contain the entry for APE interface clock
clock-names:
items:
- const: ape
- const: apb2ape
power-domains:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 1
ranges: true
patternProperties:
"@[0-9a-f]+$":
type: object
required:
- compatible
- clocks
- clock-names
- power-domains
- "#address-cells"
- "#size-cells"
- ranges
additionalProperties: false
examples:
- |
#include<dt-bindings/clock/tegra210-car.h>
aconnect@702c0000 {
compatible = "nvidia,tegra210-aconnect";
clocks = <&tegra_car TEGRA210_CLK_APE>,
<&tegra_car TEGRA210_CLK_APB2APE>;
clock-names = "ape", "apb2ape";
power-domains = <&pd_audio>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x702c0000 0x702c0000 0x00040000>;
// Child device nodes follow ...
};
...

29
bindings/bus/omap-ocp2scp.txt Normal file
View File

@@ -0,0 +1,29 @@
* OMAP OCP2SCP - ocp interface to scp interface
properties:
- compatible : Should be "ti,am437x-ocp2scp" for AM437x processor
Should be "ti,omap-ocp2scp" for all others
- reg : Address and length of the register set for the device
- #address-cells, #size-cells : Must be present if the device has sub-nodes
- ranges : the child address space are mapped 1:1 onto the parent address space
- ti,hwmods : must be "ocp2scp_usb_phy"
Sub-nodes:
All the devices connected to ocp2scp are described using sub-node to ocp2scp
ocp2scp@4a0ad000 {
compatible = "ti,omap-ocp2scp";
reg = <0x4a0ad000 0x1f>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
ti,hwmods = "ocp2scp_usb_phy";
subnode1 {
...
};
subnode2 {
...
};
};

79
bindings/bus/palmbus.yaml Normal file
View File

@@ -0,0 +1,79 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/palmbus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ralink PalmBus
maintainers:
- Sergio Paracuellos <sergio.paracuellos@gmail.com>
description: |
The ralink palmbus controller can be found in all ralink MIPS
SoCs. It provides an external bus for connecting multiple
external devices to the SoC.
properties:
$nodename:
pattern: "^palmbus(@[0-9a-f]+)?$"
"#address-cells":
const: 1
"#size-cells":
const: 1
compatible:
const: palmbus
reg:
maxItems: 1
ranges: true
patternProperties:
# All other properties should be child nodes with unit-address and 'reg'
"@[0-9a-f]+$":
type: object
properties:
reg:
maxItems: 1
required:
- reg
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- ranges
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/mips-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
palmbus@1e000000 {
compatible = "palmbus";
reg = <0x1e000000 0x100000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e000000 0x0fffff>;
gpio@600 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "mediatek,mt7621-gpio";
gpio-controller;
gpio-ranges = <&pinctrl 0 0 95>;
interrupt-controller;
reg = <0x600 0x100>;
interrupt-parent = <&gic>;
interrupts = <GIC_SHARED 12 IRQ_TYPE_LEVEL_HIGH>;
};
};
...

138
bindings/bus/qcom,ebi2.txt Normal file
View File

@@ -0,0 +1,138 @@
Qualcomm External Bus Interface 2 (EBI2)
The EBI2 contains two peripheral blocks: XMEM and LCDC. The XMEM handles any
external memory (such as NAND or other memory-mapped peripherals) whereas
LCDC handles LCD displays.
As it says it connects devices to an external bus interface, meaning address
lines (up to 9 address lines so can only address 1KiB external memory space),
data lines (16 bits), OE (output enable), ADV (address valid, used on some
NOR flash memories), WE (write enable). This on top of 6 different chip selects
(CS0 thru CS5) so that in theory 6 different devices can be connected.
Apparently this bus is clocked at 64MHz. It has dedicated pins on the package
and the bus can only come out on these pins, however if some of the pins are
unused they can be left unconnected or remuxed to be used as GPIO or in some
cases other orthogonal functions as well.
Also CS1 and CS2 has -A and -B signals. Why they have that is unclear to me.
The chip selects have the following memory range assignments. This region of
memory is referred to as "Chip Peripheral SS FPB0" and is 168MB big.
Chip Select Physical address base
CS0 GPIO134 0x1a800000-0x1b000000 (8MB)
CS1 GPIO39 (A) / GPIO123 (B) 0x1b000000-0x1b800000 (8MB)
CS2 GPIO40 (A) / GPIO124 (B) 0x1b800000-0x1c000000 (8MB)
CS3 GPIO133 0x1d000000-0x25000000 (128 MB)
CS4 GPIO132 0x1c800000-0x1d000000 (8MB)
CS5 GPIO131 0x1c000000-0x1c800000 (8MB)
The APQ8060 Qualcomm Application Processor User Guide, 80-N7150-14 Rev. A,
August 6, 2012 contains some incomplete documentation of the EBI2.
FIXME: the manual mentions "write precharge cycles" and "precharge cycles".
We have not been able to figure out which bit fields these correspond to
in the hardware, or what valid values exist. The current hypothesis is that
this is something just used on the FAST chip selects and that the SLOW
chip selects are understood fully. There is also a "byte device enable"
flag somewhere for 8bit memories.
FIXME: The chipselects have SLOW and FAST configuration registers. It's a bit
unclear what this means, if they are mutually exclusive or can be used
together, or if some chip selects are hardwired to be FAST and others are SLOW
by design.
The XMEM registers are totally undocumented but could be partially decoded
because the Cypress AN49576 Antioch Westbridge apparently has suspiciously
similar register layout, see: http://www.cypress.com/file/105771/download
Required properties:
- compatible: should be one of:
"qcom,msm8660-ebi2"
"qcom,apq8060-ebi2"
- #address-cells: should be <2>: the first cell is the chipselect,
the second cell is the offset inside the memory range
- #size-cells: should be <1>
- ranges: should be set to:
ranges = <0 0x0 0x1a800000 0x00800000>,
<1 0x0 0x1b000000 0x00800000>,
<2 0x0 0x1b800000 0x00800000>,
<3 0x0 0x1d000000 0x08000000>,
<4 0x0 0x1c800000 0x00800000>,
<5 0x0 0x1c000000 0x00800000>;
- reg: two ranges of registers: EBI2 config and XMEM config areas
- reg-names: should be "ebi2", "xmem"
- clocks: two clocks, EBI_2X and EBI
- clock-names: should be "ebi2x", "ebi2"
Optional subnodes:
- Nodes inside the EBI2 will be considered device nodes.
The following optional properties are properties that can be tagged onto
any device subnode. We are assuming that there can be only ONE device per
chipselect subnode, else the properties will become ambiguous.
Optional properties arrays for SLOW chip selects:
- qcom,xmem-recovery-cycles: recovery cycles is the time the memory continues to
drive the data bus after OE is de-asserted, in order to avoid contention on
the data bus. They are inserted when reading one CS and switching to another
CS or read followed by write on the same CS. Valid values 0 thru 15. Minimum
value is actually 1, so a value of 0 will still yield 1 recovery cycle.
- qcom,xmem-write-hold-cycles: write hold cycles, these are extra cycles
inserted after every write minimum 1. The data out is driven from the time
WE is asserted until CS is asserted. With a hold of 1 (value = 0), the CS
stays active for 1 extra cycle etc. Valid values 0 thru 15.
- qcom,xmem-write-delta-cycles: initial latency for write cycles inserted for
the first write to a page or burst memory. Valid values 0 thru 255.
- qcom,xmem-read-delta-cycles: initial latency for read cycles inserted for the
first read to a page or burst memory. Valid values 0 thru 255.
- qcom,xmem-write-wait-cycles: number of wait cycles for every write access, 0=1
cycle. Valid values 0 thru 15.
- qcom,xmem-read-wait-cycles: number of wait cycles for every read access, 0=1
cycle. Valid values 0 thru 15.
Optional properties arrays for FAST chip selects:
- qcom,xmem-address-hold-enable: this is a boolean property stating that we
shall hold the address for an extra cycle to meet hold time requirements
with ADV assertion.
- qcom,xmem-adv-to-oe-recovery-cycles: the number of cycles elapsed before an OE
assertion, with respect to the cycle where ADV (address valid) is asserted.
2 means 2 cycles between ADV and OE. Valid values 0, 1, 2 or 3.
- qcom,xmem-read-hold-cycles: the length in cycles of the first segment of a
read transfer. For a single read transfer this will be the time from CS
assertion to OE assertion. Valid values 0 thru 15.
Example:
ebi2@1a100000 {
compatible = "qcom,apq8060-ebi2";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0x0 0x1a800000 0x00800000>,
<1 0x0 0x1b000000 0x00800000>,
<2 0x0 0x1b800000 0x00800000>,
<3 0x0 0x1d000000 0x08000000>,
<4 0x0 0x1c800000 0x00800000>,
<5 0x0 0x1c000000 0x00800000>;
reg = <0x1a100000 0x1000>, <0x1a110000 0x1000>;
reg-names = "ebi2", "xmem";
clocks = <&gcc EBI2_2X_CLK>, <&gcc EBI2_CLK>;
clock-names = "ebi2x", "ebi2";
/* Make sure to set up the pin control for the EBI2 */
pinctrl-names = "default";
pinctrl-0 = <&foo_ebi2_pins>;
foo-ebi2@2,0 {
compatible = "foo";
reg = <2 0x0 0x100>;
(...)
qcom,xmem-recovery-cycles = <0>;
qcom,xmem-write-hold-cycles = <3>;
qcom,xmem-write-delta-cycles = <31>;
qcom,xmem-read-delta-cycles = <28>;
qcom,xmem-write-wait-cycles = <9>;
qcom,xmem-read-wait-cycles = <9>;
};
};

144
bindings/bus/qcom,ssc-block-bus.yaml Normal file
View File

@@ -0,0 +1,144 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/qcom,ssc-block-bus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: The AHB Bus Providing a Global View of the SSC Block on (some) qcom SoCs
maintainers:
- Michael Srba <Michael.Srba@seznam.cz>
description: |
This binding describes the dependencies (clocks, resets, power domains) which
need to be turned on in a sequence before communication over the AHB bus
becomes possible.
Additionally, the reg property is used to pass to the driver the location of
two sadly undocumented registers which need to be poked as part of the sequence.
The SSC (Snapdragon Sensor Core) block contains a gpio controller, i2c/spi/uart
controllers, a hexagon core, and a clock controller which provides clocks for
the above.
properties:
compatible:
items:
- const: qcom,msm8998-ssc-block-bus
- const: qcom,ssc-block-bus
reg:
items:
- description: SSCAON_CONFIG0 registers
- description: SSCAON_CONFIG1 registers
reg-names:
items:
- const: mpm_sscaon_config0
- const: mpm_sscaon_config1
'#address-cells':
enum: [ 1, 2 ]
'#size-cells':
enum: [ 1, 2 ]
ranges: true
clocks:
maxItems: 6
clock-names:
items:
- const: xo
- const: aggre2
- const: gcc_im_sleep
- const: aggre2_north
- const: ssc_xo
- const: ssc_ahbs
power-domains:
items:
- description: CX power domain
- description: MX power domain
power-domain-names:
items:
- const: ssc_cx
- const: ssc_mx
resets:
items:
- description: Main reset
- description:
SSC Branch Control Register reset (associated with the ssc_xo and
ssc_ahbs clocks)
reset-names:
items:
- const: ssc_reset
- const: ssc_bcr
qcom,halt-regs:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: describes how to locate the ssc AXI halt register
items:
- items:
- description: Phandle reference to a syscon representing TCSR
- description: offset for the ssc AXI halt register
required:
- compatible
- reg
- reg-names
- '#address-cells'
- '#size-cells'
- ranges
- clocks
- clock-names
- power-domains
- power-domain-names
- resets
- reset-names
- qcom,halt-regs
additionalProperties:
type: object
examples:
- |
#include <dt-bindings/clock/qcom,gcc-msm8998.h>
#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/power/qcom-rpmpd.h>
soc {
#address-cells = <1>;
#size-cells = <1>;
// devices under this node are physically located in the SSC block, connected to an ssc-internal bus;
ssc_ahb_slave: bus@10ac008 {
#address-cells = <1>;
#size-cells = <1>;
ranges;
compatible = "qcom,msm8998-ssc-block-bus", "qcom,ssc-block-bus";
reg = <0x10ac008 0x4>, <0x10ac010 0x4>;
reg-names = "mpm_sscaon_config0", "mpm_sscaon_config1";
clocks = <&xo>,
<&rpmcc RPM_SMD_AGGR2_NOC_CLK>,
<&gcc GCC_IM_SLEEP>,
<&gcc AGGRE2_SNOC_NORTH_AXI>,
<&gcc SSC_XO>,
<&gcc SSC_CNOC_AHBS_CLK>;
clock-names = "xo", "aggre2", "gcc_im_sleep", "aggre2_north", "ssc_xo", "ssc_ahbs";
resets = <&gcc GCC_SSC_RESET>, <&gcc GCC_SSC_BCR>;
reset-names = "ssc_reset", "ssc_bcr";
power-domains = <&rpmpd MSM8998_SSCCX>, <&rpmpd MSM8998_SSCMX>;
power-domain-names = "ssc_cx", "ssc_mx";
qcom,halt-regs = <&tcsr_mutex_regs 0x26000>;
};
};

62
bindings/bus/renesas,bsc.yaml Normal file
View File

@@ -0,0 +1,62 @@
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/renesas,bsc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Bus State Controller (BSC)
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
description: |
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".
allOf:
- $ref: simple-pm-bus.yaml#
properties:
compatible:
items:
- enum:
- renesas,bsc-r8a73a4 # R-Mobile APE6 (r8a73a4)
- renesas,bsc-sh73a0 # SH-Mobile AG5 (sh73a0)
- const: renesas,bsc
- {} # simple-pm-bus, but not listed here to avoid false select
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- reg
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
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>;
};

77
bindings/bus/simple-pm-bus.yaml Normal file
View File

@@ -0,0 +1,77 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/simple-pm-bus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Simple Power-Managed Bus
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
description: |
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".
properties:
$nodename:
pattern: "^bus(@[0-9a-f]+)?$"
compatible:
contains:
const: simple-pm-bus
description:
Shall contain "simple-pm-bus" in addition to a optional bus-specific
compatible strings defined in individual pm-bus bindings.
'#address-cells':
enum: [ 1, 2 ]
'#size-cells':
enum: [ 1, 2 ]
ranges: true
clocks: true
# Functional clocks
# Required if power-domains is absent, optional otherwise
power-domains:
# Required if clocks is absent, optional otherwise
minItems: 1
required:
- compatible
- '#address-cells'
- '#size-cells'
- ranges
anyOf:
- required:
- clocks
- required:
- power-domains
additionalProperties: true
examples:
- |
#include <dt-bindings/clock/qcom,gcc-msm8996.h>
#include <dt-bindings/interrupt-controller/irq.h>
bus {
power-domains = <&gcc AGGRE0_NOC_GDSC>;
compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
};

103
bindings/bus/socionext,uniphier-system-bus.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/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.
patternProperties:
"^.*@[1-5],[1-9a-f][0-9a-f]+$":
description: Devices attached to chip selects
type: object
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- ranges
additionalProperties: false
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>;
};
};

20
bindings/bus/ti,da850-mstpri.txt Normal file
View File

@@ -0,0 +1,20 @@
* Device tree bindings for Texas Instruments da8xx master peripheral
priority driver
DA8XX SoCs feature a set of registers allowing to change the priority of all
peripherals classified as masters.
Documentation:
OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
Required properties:
- compatible: "ti,da850-mstpri" - for da850 based boards
- reg: offset and length of the mstpri registers
Example for da850-lcdk is shown below.
mstpri {
compatible = "ti,da850-mstpri";
reg = <0x14110 0x0c>;
};

215
bindings/bus/ti-sysc.yaml Normal file
View File

@@ -0,0 +1,215 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/ti-sysc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments interconnect target module binding
maintainers:
- Tony Lindgren <tony@atomide.com>
description:
Texas Instruments SoCs can have a generic interconnect target module
for devices connected to various interconnects such as L3 interconnect
using Arteris NoC, and L4 interconnect using Sonics s3220. This module
is mostly used for interaction between module and Power, Reset and Clock
Manager PRCM. It participates in the OCP Disconnect Protocol, but other
than that it is mostly independent of the interconnect.
Each interconnect target module can have one or more devices connected to
it. There is a set of control registers for managing the interconnect target
module clocks, idle modes and interconnect level resets.
The interconnect target module control registers are sprinkled into the
unused register address space of the first child device IP block managed by
the interconnect target module. Typically the register names are REVISION,
SYSCONFIG and SYSSTATUS.
properties:
$nodename:
pattern: "^target-module(@[0-9a-f]+)?$"
compatible:
oneOf:
- items:
- enum:
- ti,sysc-omap2
- ti,sysc-omap4
- ti,sysc-omap4-simple
- ti,sysc-omap2-timer
- ti,sysc-omap4-timer
- ti,sysc-omap3430-sr
- ti,sysc-omap3630-sr
- ti,sysc-omap4-sr
- ti,sysc-omap3-sham
- ti,sysc-omap-aes
- ti,sysc-mcasp
- ti,sysc-dra7-mcasp
- ti,sysc-usb-host-fs
- ti,sysc-dra7-mcan
- ti,sysc-pruss
- const: ti,sysc
- items:
- const: ti,sysc
reg:
description:
Interconnect target module control registers consisting of
REVISION, SYSCONFIG and SYSSTATUS registers as defined in the
Technical Reference Manual for the SoC.
minItems: 1
maxItems: 3
reg-names:
description:
Interconnect target module control register names consisting
of "rev", "sysc" and "syss".
oneOf:
- minItems: 1
items:
- const: rev
- const: sysc
- const: syss
- items:
- const: rev
- const: syss
- enum: [ sysc, syss ]
power-domains:
description: Target module power domain if available.
maxItems: 1
clocks:
description:
Target module clocks consisting of one functional clock, one
interface clock, and up to 8 module specific optional clocks.
Some modules may have only the functional clock, and some have
no configurable clocks.
minItems: 1
maxItems: 4
clock-names:
description:
Target module clock names like "fck", "ick", "optck1", "optck2"
if the clocks are configurable.
oneOf:
- enum: [ ick, fck, sys_clk ]
- items:
- const: fck
- enum: [ ick. dbclk, osc, sys_clk, dss_clk, ahclkx ]
- items:
- const: fck
- const: phy-clk
- const: phy-clk-div
- items:
- const: fck
- const: hdmi_clk
- const: sys_clk
- const: tv_clk
- items:
- const: fck
- const: ahclkx
- const: ahclkr
resets:
description:
Target module reset bit in the RSTCTRL register if wired for the module.
Note that the other reset bits should be mapped for the child device
driver to use.
maxItems: 1
reset-names:
description:
Target module reset names in the RSTCTRL register, typically named
"rstctrl" if only one reset bit is wired for the module.
items:
- const: rstctrl
'#address-cells':
enum: [ 1, 2 ]
'#size-cells':
enum: [ 1, 2 ]
ranges: true
dma-ranges: true
ti,sysc-mask:
description: Mask of supported register bits for the SYSCONFIG register
$ref: /schemas/types.yaml#/definitions/uint32
ti,sysc-midle:
description: List of hardware supported idle modes
$ref: /schemas/types.yaml#/definitions/uint32-array
ti,sysc-sidle:
description: List of hardware supported idle modes
$ref: /schemas/types.yaml#/definitions/uint32-array
ti,syss-mask:
description: Mask of supported register bits for the SYSSTATUS register
$ref: /schemas/types.yaml#/definitions/uint32
ti,sysc-delay-us:
description: Delay needed after OCP softreset before accessing SYCONFIG
default: 0
minimum: 0
maximum: 2
ti,no-reset-on-init:
description: Interconnect target module shall not be reset at init
type: boolean
ti,no-idle-on-init:
description: Interconnect target module shall not be idled at init
type: boolean
ti,no-idle:
description: Interconnect target module shall not be idled
type: boolean
ti,hwmods:
description: Interconnect module name to use with legacy hwmod data
$ref: /schemas/types.yaml#/definitions/string
deprecated: true
required:
- compatible
- '#address-cells'
- '#size-cells'
- ranges
additionalProperties:
type: object
examples:
- |
#include <dt-bindings/bus/ti-sysc.h>
#include <dt-bindings/clock/omap4.h>
target-module@2b000 {
compatible = "ti,sysc-omap2", "ti,sysc";
ti,hwmods = "usb_otg_hs";
reg = <0x2b400 0x4>,
<0x2b404 0x4>,
<0x2b408 0x4>;
reg-names = "rev", "sysc", "syss";
clocks = <&l3_init_clkctrl OMAP4_USB_OTG_HS_CLKCTRL 0>;
clock-names = "fck";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-midle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x2b000 0x1000>;
};

50
bindings/bus/ts-nbus.txt Normal file
View File

@@ -0,0 +1,50 @@
Technologic Systems NBUS
The NBUS is a bus used to interface with peripherals in the Technologic
Systems FPGA on the TS-4600 SoM.
Required properties :
- compatible : "technologic,ts-nbus"
- #address-cells : must be 1
- #size-cells : must be 0
- pwms : The PWM bound to the FPGA
- ts,data-gpios : The 8 GPIO pins connected to the data lines on the FPGA
- ts,csn-gpios : The GPIO pin connected to the csn line on the FPGA
- ts,txrx-gpios : The GPIO pin connected to the txrx line on the FPGA
- ts,strobe-gpios : The GPIO pin connected to the stobe line on the FPGA
- ts,ale-gpios : The GPIO pin connected to the ale line on the FPGA
- ts,rdy-gpios : The GPIO pin connected to the rdy line on the FPGA
Child nodes:
The NBUS node can contain zero or more child nodes representing peripherals
on the bus.
Example:
nbus {
compatible = "technologic,ts-nbus";
pinctrl-0 = <&nbus_pins>;
#address-cells = <1>;
#size-cells = <0>;
pwms = <&pwm 2 83>;
ts,data-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH
&gpio0 1 GPIO_ACTIVE_HIGH
&gpio0 2 GPIO_ACTIVE_HIGH
&gpio0 3 GPIO_ACTIVE_HIGH
&gpio0 4 GPIO_ACTIVE_HIGH
&gpio0 5 GPIO_ACTIVE_HIGH
&gpio0 6 GPIO_ACTIVE_HIGH
&gpio0 7 GPIO_ACTIVE_HIGH>;
ts,csn-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
ts,txrx-gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
ts,strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
ts,ale-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
ts,rdy-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
watchdog@2a {
compatible = "...";
/* ... */
};
};