Merge tag 'devicetree-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

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

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

		...

	};

};

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.

# 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>;

    };

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

		};

	};