Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

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"

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

Required properties:

- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno

The rest of the properties should follow the generic mmio-sram description

found in ../../misc/sysram.txt

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

--------------------------------------------------------------

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 documentation for your

			 implementation for the IDs to use. For Juno

			 R0 and Juno R1 refer to [3].

[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html

[1] Documentation/devicetree/bindings/clock/clock-bindings.txt

[2] Documentation/devicetree/bindings/thermal/thermal.txt

[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html

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

	};

};

cpu@0 {

	...

	reg = <0 0>;

	clocks = <&scpi_dvfs 0>;

};

hdlcd@7ff60000 {

	...

	reg = <0 0x7ff60000 0 0x1000>;

	clocks = <&scpi_clk 4>;

};

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.

					support, but are permitted to be present for compatibility with

					existing software when "arm,psci" is later in the compatible list.

				* "arm,psci-1.0" : for implementations complying to PSCI 1.0. PSCI 1.0 is

					backward compatible with PSCI 0.2 with minor specification updates,

					as defined in the PSCI specification[2].

 - method        : The method of calling the PSCI firmware. Permitted

                   values are:

[1] Kernel documentation - ARM idle states bindings

    Documentation/devicetree/bindings/arm/idle-states.txt

[2] Power State Coordination Interface (PSCI) specification

    http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf

Allwinner Reduced Serial Bus (RSB) controller

The RSB controller found on later Allwinner SoCs is an SMBus like 2 wire

serial bus with 1 master and up to 15 slaves. It is represented by a node

for the controller itself, and child nodes representing the slave devices.

Required properties :

 - reg             : Offset and length of the register set for the controller.

 - compatible      : Shall be "allwinner,sun8i-a23-rsb".

 - interrupts      : The interrupt line associated to the RSB controller.

 - clocks          : The gate clk associated to the RSB controller.

 - resets          : The reset line associated to the RSB controller.

 - #address-cells  : shall be 1

 - #size-cells     : shall be 0

Optional properties :

 - clock-frequency : Desired RSB bus clock frequency in Hz. Maximum is 20MHz.

		     If not set this defaults to 3MHz.

Child nodes:

An RSB controller node can contain zero or more child nodes representing

slave devices on the bus.  Child 'reg' properties should contain the slave

device's hardware address. The hardware address is hardwired in the device,

which can normally be found in the datasheet.

Example:

	rsb@01f03400 {

		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 {

			compatible = "...";

			reg = <0x3e3>;

			/* ... */

		};

	};

* Device tree bindings for ARM PL172 MultiPort Memory Controller

* Device tree bindings for ARM PL172/PL175/PL176 MultiPort Memory Controller

Required properties:

- compatible:		"arm,pl172", "arm,primecell"

- compatible:		Must be "arm,primecell" and exactly one from

			"arm,pl172", "arm,pl175" or "arm,pl176".

- reg:			Must contains offset/length value for controller.

- mpmc,extended-wait:	Enable extended wait.

- mpmc,buffer-enable:	Enable write buffer.

- mpmc,buffer-enable:	Enable write buffer, option is not supported by

			PL175 and PL176 controllers.

- mpmc,write-protect:	Enable write protect.

* Rockchip Power Domains

Rockchip processors include support for multiple power domains which can be

powered up/down by software based on different application scenes to save power.

Required properties for power domain controller:

- compatible: Should be one of the following.

	"rockchip,rk3288-power-controller" - for RK3288 SoCs.

- #power-domain-cells: Number of cells in a power-domain specifier.

	Should be 1 for multiple PM domains.

- #address-cells: Should be 1.

- #size-cells: Should be 0.

Required properties for power domain sub nodes:

- reg: index of the power domain, should use macros in:

	"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.

- clocks (optional): phandles to clocks which need to be enabled while power domain

	switches state.

Example:

	power: power-controller {

		compatible = "rockchip,rk3288-power-controller";

		#power-domain-cells = <1>;

		#address-cells = <1>;

		#size-cells = <0>;

		pd_gpu {

			reg = <RK3288_PD_GPU>;

			clocks = <&cru ACLK_GPU>;

		};

	};

Node of a device using power domains must have a power-domains property,

containing a phandle to the power device node and an index specifying which

power domain to use.

The index should use macros in:

	"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.

Example of the node using power domain:

	node {

		/* ... */

		power-domains = <&power RK3288_PD_GPU>;

		/* ... */

	};