summaryrefslogtreecommitdiff
path: root/Documentation/devicetree/bindings/arm
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2021-07-03 10:54:08 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2021-07-03 10:54:08 -0700
commita70bb580bfeaead9f685d4c28f7cd685c905d8c3 (patch)
tree273252a458ac5349d6a6190c9b3a748407d060db /Documentation/devicetree/bindings/arm
parent4b820e167bf6f410ace479d8df5b15a574000e75 (diff)
parent6a9a930dc4415b2e8c0bf2085b2b0b2b291053d5 (diff)
Merge tag 'devicetree-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull devicetree updates from Rob Herring: - Refine reserved memory nomap handling - Merge some PCI and non-PCI address handling implementations - Simplify of_address.h header ifdefs - Improve printk handling of some 64-bit types - Convert adi,adv7511, Arm ccree, Arm SCMI, Arm SCU, Arm TWD timer, Arm VIC, arm,sbsa-gwdt, Arm/Amlogic SCPI, Aspeed I2C, Broadcom iProc PWM, linaro,optee-tz, MDIO GPIO, Mediatek RNG, MTD physmap, NXP pcf8563/pcf85263/pcf85363, Renesas TPU, renesas,emev2-smu, renesas,r9a06g032-sysctrl, sysc-rmobile, Tegra20 EMC, TI AM56 PCI, TI OMAP mailbox, TI SCI bindings, virtio-mmio, Zynq FPGA, and ZynqMP RTC to DT schema - Convert mux and mux controller bindings to schema. This includes MDIO IIO, and I2C muxes. - Add Arm PL031 RTC binding schema - Add vendor prefixes for StarFive Technology Co. Ltd. and Insignal Ltd - Fix some stale doc references - Remove stale property-units.txt. Superseded by schema in dt-schema repo. - Fixes for 'unevaluatedProperties' handling (enabled with experimental json-schema support) - Drop redundant usage of minItems and maxItems across the tree - Update some examples to use bindings with a schema * tag 'devicetree-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (83 commits) dt-bindings: Fix 'unevaluatedProperties' errors in DT graph users dt-bindings: display: renesas,du: Fix 'ports' reference dt-bindings: media: adv7180: Add missing video-interfaces.yaml reference dt-bindings: crypto: ccree: Convert to json-schema dt-bindings: fpga: zynq: convert bindings to YAML dt-bindings: rtc: zynqmp: convert bindings to YAML dt-bindings: interrupt-controller: Convert ARM VIC to json-schema of: of_reserved_mem: mark nomap memory instead of removing of: of_reserved_mem: only call memblock_free for normal reserved memory dt-bindings: Drop redundant minItems/maxItems dt-bindings: spmi: Correct 'reg' schema of: reserved-memory: Add stub for RESERVEDMEM_OF_DECLARE() dt-bindings: clk: vc5: Fix example dt-bindings: timer: renesas,tmu: add r8a779a0 TMU support dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml dt-bindings: PCI: ti,am65: Convert PCIe host/endpoint mode dt-bindings to YAML of: Remove superfluous casts when printing u64 values of: Fix truncation of memory sizes on 32-bit platforms dt-bindings: rtc: nxp,pcf8563: Absorb pcf85263/pcf85363 bindings dt-bindings: pwm: Use examples with documented/matching schema ...
Diffstat (limited to 'Documentation/devicetree/bindings/arm')
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic,scpi.txt27
-rw-r--r--Documentation/devicetree/bindings/arm/arm,scmi.txt239
-rw-r--r--Documentation/devicetree/bindings/arm/arm,scpi.txt219
-rw-r--r--Documentation/devicetree/bindings/arm/arm,scu.yaml46
-rw-r--r--Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt31
-rw-r--r--Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml58
-rw-r--r--Documentation/devicetree/bindings/arm/intel,keembay.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/juno,scpi.txt26
-rw-r--r--Documentation/devicetree/bindings/arm/keystone/ti,sci.txt86
-rw-r--r--Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml129
-rw-r--r--Documentation/devicetree/bindings/arm/scu.txt28
-rw-r--r--Documentation/devicetree/bindings/arm/ux500/boards.txt4
12 files changed, 237 insertions, 658 deletions
diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
deleted file mode 100644
index 5ab59da052df..000000000000
--- a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-System Control and Power Interface (SCPI) Message Protocol
-(in addition to the standard binding in [0])
-----------------------------------------------------------
-Required properties
-
-- compatible : should be "amlogic,meson-gxbb-scpi"
-
-AMLOGIC SRAM and Shared Memory for SCPI
-------------------------------------
-
-Required properties:
-- compatible : should be "amlogic,meson-gxbb-sram"
-
-Each sub-node represents the reserved area for SCPI.
-
-Required sub-node properties:
-- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
- memory on Amlogic GXBB SoC.
-
-Sensor bindings for the sensors based on SCPI Message Protocol
---------------------------------------------------------------
-SCPI provides an API to access the various sensors on the SoC.
-
-Required properties:
-- compatible : should be "amlogic,meson-gxbb-scpi-sensors".
-
-[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
deleted file mode 100644
index 667d58e0a659..000000000000
--- a/Documentation/devicetree/bindings/arm/arm,scmi.txt
+++ /dev/null
@@ -1,239 +0,0 @@
-System Control and Management Interface (SCMI) Message Protocol
-----------------------------------------------------------
-
-The SCMI is intended to allow agents such as OSPM to manage various functions
-that are provided by the hardware platform it is running on, including power
-and performance functions.
-
-This binding is intended to define the interface the firmware implementing
-the SCMI as described in ARM document number ARM DEN 0056A ("ARM System Control
-and Management Interface Platform Design Document")[0] provide for OSPM in
-the device tree.
-
-Required properties:
-
-The scmi node with the following properties shall be under the /firmware/ node.
-
-- compatible : shall be "arm,scmi" 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
- supported.
-- shmem : List of phandle pointing to the shared memory(SHM) area as per
- generic mailbox client binding.
-- #address-cells : should be '1' if the device has sub-nodes, maps to
- protocol identifier for a given sub-node.
-- #size-cells : should be '0' as 'reg' property doesn't have any size
- associated with it.
-- arm,smc-id : SMC id required when using smc or hvc transports
-
-Optional properties:
-
-- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
-
-- interrupts : when using smc or hvc transports, this optional
- property indicates that msg completion by the platform is indicated
- by an interrupt rather than by the return of the smc call. This
- should not be used except when the platform requires such behavior.
-
-- interrupt-names : if "interrupts" is present, interrupt-names must also
- be present and have the value "a2p".
-
-See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
-about the generic mailbox controller and client driver bindings.
-
-The mailbox is the only permitted method of calling the SCMI firmware.
-Mailbox doorbell is used as a mechanism to alert the presence of a
-messages and/or notification.
-
-Each protocol supported shall have a sub-node with corresponding compatible
-as described in the following sections. If the platform supports dedicated
-communication channel for a particular protocol, the 3 properties namely:
-mboxes, mbox-names and shmem shall be present in the sub-node corresponding
-to that protocol.
-
-Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol
-------------------------------------------------------------
-
-This binding uses the common clock binding[1].
-
-Required properties:
-- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands.
-
-Power domain bindings for the power domains based on SCMI Message Protocol
-------------------------------------------------------------
-
-This binding for the SCMI power domain providers uses the generic power
-domain binding[2].
-
-Required properties:
- - #power-domain-cells : Should be 1. Contains the device or the power
- domain ID value used by SCMI commands.
-
-Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
-------------------------------------------------------------
-An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
-and should be always positioned as a root regulator.
-It does not support any current operation.
-
-SCMI Regulators are grouped under a 'regulators' node which in turn is a child
-of the SCMI Voltage protocol node inside the desired SCMI instance node.
-
-This binding uses the common regulator binding[6].
-
-Required properties:
- - reg : shall identify an existent SCMI Voltage Domain.
-
-Sensor bindings for the sensors based on SCMI Message Protocol
---------------------------------------------------------------
-SCMI provides an API to access the various sensors on the SoC.
-
-Required properties:
-- #thermal-sensor-cells: should be set to 1. This property follows the
- thermal device tree bindings[3].
-
- Valid cell values are raw identifiers (Sensor ID)
- as used by the firmware. Refer to platform details
- for your implementation for the IDs to use.
-
-Reset signal bindings for the reset domains based on SCMI Message Protocol
-------------------------------------------------------------
-
-This binding for the SCMI reset domain providers uses the generic reset
-signal binding[5].
-
-Required properties:
- - #reset-cells : Should be 1. Contains the reset domain ID value used
- by SCMI commands.
-
-SRAM and Shared Memory for SCMI
--------------------------------
-
-A small area of SRAM is reserved for SCMI communication between application
-processors and SCP.
-
-The properties should follow the generic mmio-sram description found in [4]
-
-Each sub-node represents the reserved area for SCMI.
-
-Required sub-node properties:
-- reg : The base offset and size of the reserved area with the SRAM
-- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based
- shared memory
-
-[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/power/power-domain.yaml
-[3] Documentation/devicetree/bindings/thermal/thermal*.yaml
-[4] Documentation/devicetree/bindings/sram/sram.yaml
-[5] Documentation/devicetree/bindings/reset/reset.txt
-[6] Documentation/devicetree/bindings/regulator/regulator.yaml
-
-Example:
-
-sram@50000000 {
- compatible = "mmio-sram";
- reg = <0x0 0x50000000 0x0 0x10000>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x0 0x50000000 0x10000>;
-
- cpu_scp_lpri: scp-shmem@0 {
- compatible = "arm,scmi-shmem";
- reg = <0x0 0x200>;
- };
-
- cpu_scp_hpri: scp-shmem@200 {
- compatible = "arm,scmi-shmem";
- reg = <0x200 0x200>;
- };
-};
-
-mailbox@40000000 {
- ....
- #mbox-cells = <1>;
- reg = <0x0 0x40000000 0x0 0x10000>;
-};
-
-firmware {
-
- ...
-
- scmi {
- compatible = "arm,scmi";
- mboxes = <&mailbox 0 &mailbox 1>;
- mbox-names = "tx", "rx";
- shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- scmi_devpd: protocol@11 {
- reg = <0x11>;
- #power-domain-cells = <1>;
- };
-
- scmi_dvfs: protocol@13 {
- reg = <0x13>;
- #clock-cells = <1>;
- };
-
- scmi_clk: protocol@14 {
- reg = <0x14>;
- #clock-cells = <1>;
- };
-
- scmi_sensors0: protocol@15 {
- reg = <0x15>;
- #thermal-sensor-cells = <1>;
- };
-
- scmi_reset: protocol@16 {
- reg = <0x16>;
- #reset-cells = <1>;
- };
-
- scmi_voltage: protocol@17 {
- reg = <0x17>;
-
- regulators {
- regulator_devX: regulator@0 {
- reg = <0x0>;
- regulator-max-microvolt = <3300000>;
- };
-
- regulator_devY: regulator@9 {
- reg = <0x9>;
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <4200000>;
- };
-
- ...
- };
- };
- };
-};
-
-cpu@0 {
- ...
- reg = <0 0>;
- clocks = <&scmi_dvfs 0>;
-};
-
-hdlcd@7ff60000 {
- ...
- reg = <0 0x7ff60000 0 0x1000>;
- clocks = <&scmi_clk 4>;
- power-domains = <&scmi_devpd 1>;
- resets = <&scmi_reset 10>;
-};
-
-thermal-zones {
- soc_thermal {
- polling-delay-passive = <100>;
- polling-delay = <1000>;
- /* sensor ID */
- thermal-sensors = <&scmi_sensors0 3>;
- ...
- };
-};
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
deleted file mode 100644
index bcd6c3ec471e..000000000000
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ /dev/null
@@ -1,219 +0,0 @@
-System Control and Power Interface (SCPI) Message Protocol
-----------------------------------------------------------
-
-Firmware implementing the SCPI described in ARM document number ARM DUI 0922B
-("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used
-by Linux to initiate various system control and power operations.
-
-Required properties:
-
-- compatible : should be
- * "arm,scpi" : For implementations complying to SCPI v1.0 or above
- * "arm,scpi-pre-1.0" : For implementations complying to all
- unversioned releases prior to SCPI v1.0
-- mboxes: List of phandle and mailbox channel specifiers
- All the channels reserved by remote SCP firmware for use by
- SCPI message protocol should be specified in any order
-- shmem : List of phandle pointing to the shared memory(SHM) area between the
- processors using these mailboxes for IPC, one for each mailbox
- SHM can be any memory reserved for the purpose of this communication
- between the processors.
-
-See Documentation/devicetree/bindings/mailbox/mailbox.txt
-for more details about the generic mailbox controller and
-client driver bindings.
-
-Clock bindings for the clocks based on SCPI Message Protocol
-------------------------------------------------------------
-
-This binding uses the common clock binding[1].
-
-Container Node
-==============
-Required properties:
-- compatible : should be "arm,scpi-clocks"
- All the clocks provided by SCP firmware via SCPI message
- protocol much be listed as sub-nodes under this node.
-
-Sub-nodes
-=========
-Required properties:
-- compatible : shall include one of the following
- "arm,scpi-dvfs-clocks" - all the clocks that are variable and index based.
- These clocks don't provide an entire range of values between the
- limits but only discrete points within the range. The firmware
- provides the mapping for each such operating frequency and the
- index associated with it. The firmware also manages the
- voltage scaling appropriately with the clock scaling.
- "arm,scpi-variable-clocks" - all the clocks that are variable and provide full
- range within the specified range. The firmware provides the
- range of values within a specified range.
-
-Other required properties for all clocks(all from common clock binding):
-- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands.
-- clock-output-names : shall be the corresponding names of the outputs.
-- clock-indices: The identifying number for the clocks(i.e.clock_id) in the
- node. It can be non linear and hence provide the mapping of identifiers
- into the clock-output-names array.
-
-SRAM and Shared Memory for SCPI
--------------------------------
-
-A small area of SRAM is reserved for SCPI communication between application
-processors and SCP.
-
-The properties should follow the generic mmio-sram description found in [3]
-
-Each sub-node represents the reserved area for SCPI.
-
-Required sub-node properties:
-- reg : The base offset and size of the reserved area with the SRAM
-- compatible : should be "arm,scp-shmem" for Non-secure SRAM based
- shared memory
-
-Sensor bindings for the sensors based on SCPI Message Protocol
---------------------------------------------------------------
-SCPI provides an API to access the various sensors on the SoC.
-
-Required properties:
-- compatible : should be "arm,scpi-sensors".
-- #thermal-sensor-cells: should be set to 1. This property follows the
- thermal device tree bindings[2].
-
- Valid cell values are raw identifiers (Sensor ID)
- as used by the firmware. Refer to platform details
- for your implementation for the IDs to use.
-
-Power domain bindings for the power domains based on SCPI Message Protocol
-------------------------------------------------------------
-
-This binding uses the generic power domain binding[4].
-
-PM domain providers
-===================
-
-Required properties:
- - #power-domain-cells : Should be 1. Contains the device or the power
- domain ID value used by SCPI commands.
- - num-domains: Total number of power domains provided by SCPI. This is
- needed as the SCPI message protocol lacks a mechanism to
- query this information at runtime.
-
-PM domain consumers
-===================
-
-Required properties:
- - power-domains : A phandle and PM domain specifier as defined by bindings of
- the power controller specified by phandle.
-
-[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/thermal/thermal*.yaml
-[3] Documentation/devicetree/bindings/sram/sram.yaml
-[4] Documentation/devicetree/bindings/power/power-domain.yaml
-
-Example:
-
-sram: sram@50000000 {
- compatible = "arm,juno-sram-ns", "mmio-sram";
- reg = <0x0 0x50000000 0x0 0x10000>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x0 0x50000000 0x10000>;
-
- cpu_scp_lpri: scp-shmem@0 {
- compatible = "arm,juno-scp-shmem";
- reg = <0x0 0x200>;
- };
-
- cpu_scp_hpri: scp-shmem@200 {
- compatible = "arm,juno-scp-shmem";
- reg = <0x200 0x200>;
- };
-};
-
-mailbox: mailbox0@40000000 {
- ....
- #mbox-cells = <1>;
-};
-
-scpi_protocol: scpi@2e000000 {
- compatible = "arm,scpi";
- mboxes = <&mailbox 0 &mailbox 1>;
- shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
-
- clocks {
- compatible = "arm,scpi-clocks";
-
- scpi_dvfs: scpi_clocks@0 {
- compatible = "arm,scpi-dvfs-clocks";
- #clock-cells = <1>;
- clock-indices = <0>, <1>, <2>;
- clock-output-names = "atlclk", "aplclk","gpuclk";
- };
- scpi_clk: scpi_clocks@3 {
- compatible = "arm,scpi-variable-clocks";
- #clock-cells = <1>;
- clock-indices = <3>, <4>;
- clock-output-names = "pxlclk0", "pxlclk1";
- };
- };
-
- scpi_sensors0: sensors {
- compatible = "arm,scpi-sensors";
- #thermal-sensor-cells = <1>;
- };
-
- scpi_devpd: scpi-power-domains {
- compatible = "arm,scpi-power-domains";
- num-domains = <2>;
- #power-domain-cells = <1>;
- };
-};
-
-cpu@0 {
- ...
- reg = <0 0>;
- clocks = <&scpi_dvfs 0>;
-};
-
-hdlcd@7ff60000 {
- ...
- reg = <0 0x7ff60000 0 0x1000>;
- clocks = <&scpi_clk 4>;
- power-domains = <&scpi_devpd 1>;
-};
-
-thermal-zones {
- soc_thermal {
- polling-delay-passive = <100>;
- polling-delay = <1000>;
-
- /* sensor ID */
- thermal-sensors = <&scpi_sensors0 3>;
- ...
- };
-};
-
-In the above example, the #clock-cells is set to 1 as required.
-scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0,
-1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0
-and pxlclk1 with 3 and 4 as clock-indices.
-
-The first consumer in the example is cpu@0 and it has '0' as the clock
-specifier which points to the first entry in the output clocks of
-scpi_dvfs i.e. "atlclk".
-
-Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input
-clock. '4' in the clock specifier here points to the second entry
-in the output clocks of scpi_clocks i.e. "pxlclk1"
-
-The thermal-sensors property in the soc_thermal node uses the
-temperature sensor provided by SCP firmware to setup a thermal
-zone. The ID "3" is the sensor identifier for the temperature sensor
-as used by the firmware.
-
-The num-domains property in scpi-power-domains domain specifies that
-SCPI provides 2 power domains. The hdlcd node uses the power domain with
-domain ID 1.
diff --git a/Documentation/devicetree/bindings/arm/arm,scu.yaml b/Documentation/devicetree/bindings/arm/arm,scu.yaml
new file mode 100644
index 000000000000..dae2aa27e641
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,scu.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/arm,scu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Snoop Control Unit (SCU)
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description: |
+ As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided
+ with a Snoop Control Unit. The register range is usually 256 (0x100)
+ bytes.
+
+ References:
+ - Cortex-A9: see DDI0407E Cortex-A9 MPCore Technical Reference Manual
+ Revision r2p0
+ - Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual
+ Revision r0p1
+ - ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference
+ Manial Revision r2p0
+
+properties:
+ compatible:
+ enum:
+ - arm,cortex-a9-scu
+ - arm,cortex-a5-scu
+ - arm,arm11mp-scu
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ scu@a0410000 {
+ compatible = "arm,cortex-a9-scu";
+ reg = <0xa0410000 0x100>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
deleted file mode 100644
index d38834c67dff..000000000000
--- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-OP-TEE Device Tree Bindings
-
-OP-TEE is a piece of software using hardware features to provide a Trusted
-Execution Environment. The security can be provided with ARM TrustZone, but
-also by virtualization or a separate chip.
-
-We're using "linaro" as the first part of the compatible property for
-the reference implementation maintained by Linaro.
-
-* OP-TEE based on ARM TrustZone required properties:
-
-- compatible : should contain "linaro,optee-tz"
-
-- method : The method of calling the OP-TEE Trusted OS. Permitted
- values are:
-
- "smc" : SMC #0, with the register assignments specified
- in drivers/tee/optee/optee_smc.h
-
- "hvc" : HVC #0, with the register assignments specified
- in drivers/tee/optee/optee_smc.h
-
-
-
-Example:
- firmware {
- optee {
- compatible = "linaro,optee-tz";
- method = "smc";
- };
- };
diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
new file mode 100644
index 000000000000..c24047c1fdd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OP-TEE Device Tree Bindings
+
+maintainers:
+ - Jens Wiklander <jens.wiklander@linaro.org>
+
+description: |
+ OP-TEE is a piece of software using hardware features to provide a Trusted
+ Execution Environment. The security can be provided with ARM TrustZone, but
+ also by virtualization or a separate chip.
+
+ We're using "linaro" as the first part of the compatible property for
+ the reference implementation maintained by Linaro.
+
+properties:
+ $nodename:
+ const: optee
+
+ compatible:
+ const: linaro,optee-tz
+
+ method:
+ enum: [smc, hvc]
+ description: |
+ The method of calling the OP-TEE Trusted OS depending on smc or hvc
+ instruction usage.
+ SMC #0, register assignments
+ or
+ HVC #0, register assignments
+ register assignments are specified in drivers/tee/optee/optee_smc.h
+
+required:
+ - compatible
+ - method
+
+additionalProperties: false
+
+examples:
+ - |
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+
+ - |
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "hvc";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arm/intel,keembay.yaml b/Documentation/devicetree/bindings/arm/intel,keembay.yaml
index 69cd30872928..107e686ab207 100644
--- a/Documentation/devicetree/bindings/arm/intel,keembay.yaml
+++ b/Documentation/devicetree/bindings/arm/intel,keembay.yaml
@@ -11,6 +11,8 @@ maintainers:
- Daniele Alessandrelli <daniele.alessandrelli@intel.com>
properties:
+ $nodename:
+ const: '/'
compatible:
items:
- enum:
diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt
deleted file mode 100644
index 2ace8696bbee..000000000000
--- a/Documentation/devicetree/bindings/arm/juno,scpi.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-System Control and Power Interface (SCPI) Message Protocol
-(in addition to the standard binding in [0])
-
-Juno SRAM and Shared Memory for SCPI
-------------------------------------
-
-Required properties:
-- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
-
-Each sub-node represents the reserved area for SCPI.
-
-Required sub-node properties:
-- reg : The base offset and size of the reserved area with the SRAM
-- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
- shared memory on Juno platforms
-
-Sensor bindings for the sensors based on SCPI Message Protocol
---------------------------------------------------------------
-Required properties:
-- compatible : should be "arm,scpi-sensors".
-- #thermal-sensor-cells: should be set to 1.
- For Juno R0 and Juno R1 refer to [1] for the
- sensor identifiers
-
-[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
-[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
deleted file mode 100644
index 6f0cd31c1520..000000000000
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Texas Instruments System Control Interface (TI-SCI) Message Protocol
---------------------------------------------------------------------
-
-Texas Instrument's processors including those belonging to Keystone generation
-of processors have separate hardware entity which is now responsible for the
-management of the System on Chip (SoC) system. These include various system
-level functions as well.
-
-An example of such an SoC is K2G, which contains the system control hardware
-block called Power Management Micro Controller (PMMC). This hardware block is
-initialized early into boot process and provides services to Operating Systems
-on multiple processors including ones running Linux.
-
-See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
-
-TI-SCI controller Device Node:
-=============================
-
-The TI-SCI node describes the Texas Instrument's System Controller entity node.
-This parent node may optionally have additional children nodes which describe
-specific functionality such as clocks, power domain, reset or additional
-functionality as may be required for the SoC. This hierarchy also describes the
-relationship between the TI-SCI parent node to the child node.
-
-Required properties:
--------------------
-- compatible: should be "ti,k2g-sci" for TI 66AK2G SoC
- should be "ti,am654-sci" for for TI AM654 SoC
-- mbox-names:
- "rx" - Mailbox corresponding to receive path
- "tx" - Mailbox corresponding to transmit path
-
-- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
- property should contain a phandle to the mailbox controller device
- node and an args specifier that will be the phandle to the intended
- sub-mailbox child node to be used for communication.
-
-See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
-about the generic mailbox controller and client driver bindings. Also see
-Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
-controller that is used to communicate with this System controllers.
-
-Optional Properties:
--------------------
-- reg-names:
- debug_messages - Map the Debug message region
-- reg: register space corresponding to the debug_messages
-- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
-- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
- for identification of host processing entities such as virtual
- machines
-
-Example (K2G):
--------------
- pmmc: pmmc {
- compatible = "ti,k2g-sci";
- ti,host-id = <2>;
- mbox-names = "rx", "tx";
- mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
- <&msgmgr &msgmgr_proxy_pmmc_tx>;
- reg-names = "debug_messages";
- reg = <0x02921800 0x800>;
- };
-
-
-TI-SCI Client Device Node:
-=========================
-
-Client nodes are maintained as children of the relevant TI-SCI device node.
-
-Example (K2G):
--------------
- pmmc: pmmc {
- compatible = "ti,k2g-sci";
- ...
-
- my_clk_node: clk_node {
- ...
- ...
- };
-
- my_pd_node: pd_node {
- ...
- ...
- };
- };
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
new file mode 100644
index 000000000000..34f5f877d444
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI controller device node bindings
+
+maintainers:
+ - Nishanth Menon <nm@ti.com>
+
+description: |
+ Texas Instrument's processors including those belonging to Keystone generation
+ of processors have separate hardware entity which is now responsible for the
+ management of the System on Chip (SoC) system. These include various system
+ level functions as well.
+
+ An example of such an SoC is K2G, which contains the system control hardware
+ block called Power Management Micro Controller (PMMC). This hardware block is
+ initialized early into boot process and provides services to Operating Systems
+ on multiple processors including ones running Linux.
+
+ See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
+
+ The TI-SCI node describes the Texas Instrument's System Controller entity node.
+ This parent node may optionally have additional children nodes which describe
+ specific functionality such as clocks, power domain, reset or additional
+ functionality as may be required for the SoC. This hierarchy also describes the
+ relationship between the TI-SCI parent node to the child node.
+
+properties:
+ $nodename:
+ pattern: "^system-controller@[0-9a-f]+$"
+
+ compatible:
+ oneOf:
+ - description: System controller on TI 66AK2G SoC and other K3 SoCs
+ items:
+ - const: ti,k2g-sci
+ - description: System controller on TI AM654 SoC
+ items:
+ - const: ti,am654-sci
+
+ reg-names:
+ description: |
+ Specifies the debug messages memory mapped region that is optionally
+ made available from TI-SCI controller.
+ const: debug_messages
+
+ reg:
+ minItems: 1
+
+ mbox-names:
+ description: |
+ Specifies the mailboxes used to communicate with TI-SCI Controller
+ made available from TI-SCI controller.
+ items:
+ - const: rx
+ - const: tx
+
+ mboxes:
+ minItems: 2
+
+ ti,system-reboot-controller:
+ description: Determines If system reboot can be triggered by SoC reboot
+ type: boolean
+
+ ti,host-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Value corresponding to the host ID assigned by Firmware
+ for identification of host processing entities such as virtual machines.
+
+ power-controller:
+ type: object
+ $ref: /schemas/soc/ti/sci-pm-domain.yaml#
+
+ clock-controller:
+ type: object
+ $ref: /schemas/clock/ti,sci-clk.yaml#
+
+ reset-controller:
+ type: object
+ $ref: /schemas/reset/ti,sci-reset.yaml#
+
+required:
+ - compatible
+ - mbox-names
+ - mboxes
+
+additionalProperties: false
+
+examples:
+ - |
+ pmmc: system-controller@2921800 {
+ compatible = "ti,k2g-sci";
+ ti,system-reboot-controller;
+ mbox-names = "rx", "tx";
+ mboxes= <&msgmgr 5 2>,
+ <&msgmgr 0 0>;
+ reg-names = "debug_messages";
+ reg = <0x02921800 0x800>;
+ };
+
+ - |
+ dmsc: system-controller@44083000 {
+ compatible = "ti,k2g-sci";
+ ti,host-id = <12>;
+ mbox-names = "rx", "tx";
+ mboxes= <&secure_proxy_main 11>,
+ <&secure_proxy_main 13>;
+ reg-names = "debug_messages";
+ reg = <0x44083000 0x1000>;
+
+ k3_pds: power-controller {
+ compatible = "ti,sci-pm-domain";
+ #power-domain-cells = <2>;
+ };
+
+ k3_clks: clock-controller {
+ compatible = "ti,k2g-sci-clk";
+ #clock-cells = <2>;
+ };
+
+ k3_reset: reset-controller {
+ compatible = "ti,sci-reset";
+ #reset-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arm/scu.txt b/Documentation/devicetree/bindings/arm/scu.txt
deleted file mode 100644
index 74d0a780ce51..000000000000
--- a/Documentation/devicetree/bindings/arm/scu.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-* ARM Snoop Control Unit (SCU)
-
-As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided
-with a Snoop Control Unit. The register range is usually 256 (0x100)
-bytes.
-
-References:
-
-- Cortex-A9: see DDI0407E Cortex-A9 MPCore Technical Reference Manual
- Revision r2p0
-- Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual
- Revision r0p1
-- ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference
- Manial Revision r2p0
-
-- compatible : Should be:
- "arm,cortex-a9-scu"
- "arm,cortex-a5-scu"
- "arm,arm11mp-scu"
-
-- reg : Specify the base address and the size of the SCU register window.
-
-Example:
-
-scu@a0410000 {
- compatible = "arm,cortex-a9-scu";
- reg = <0xa0410000 0x100>;
-};
diff --git a/Documentation/devicetree/bindings/arm/ux500/boards.txt b/Documentation/devicetree/bindings/arm/ux500/boards.txt
index 89408de55bfd..18d55532d31e 100644
--- a/Documentation/devicetree/bindings/arm/ux500/boards.txt
+++ b/Documentation/devicetree/bindings/arm/ux500/boards.txt
@@ -20,13 +20,13 @@ during retention, system won't boot without this):
compatible = "ste,dbx500-backupram"
scu:
- see binding for arm/scu.txt
+ see binding for arm/arm,scu.yaml
interrupt-controller:
see binding for interrupt-controller/arm,gic.txt
timer:
- see binding for timer/arm,twd.txt
+ see binding for timer/arm,twd-timer.yaml
clocks:
see binding for clocks/ux500.txt