Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 38c23685 authored by Linus Torvalds's avatar Linus Torvalds
Browse files
Pull ARM SoC driver updates from Arnd Bergmann:
 "The main addition this time around is the new ARM "SCMI" framework,
  which is the latest in a series of standards coming from ARM to do
  power management in a platform independent way.

  This has been through many review cycles, and it relies on a rather
  interesting way of using the mailbox subsystem, but in the end I
  agreed that Sudeep's version was the best we could do after all.

  Other changes include:

   - the ARM CCN driver is moved out of drivers/bus into drivers/perf,
     which makes more sense. Similarly, the performance monitoring
     portion of the CCI driver are moved the same way and cleaned up a
     little more.

   - a series of updates to the SCPI framework

   - support for the Mediatek mt7623a SoC in drivers/soc

   - support for additional NVIDIA Tegra hardware in drivers/soc

   - a new reset driver for Socionext Uniphier

   - lesser bug fixes in drivers/soc, drivers/tee, drivers/memory, and
     drivers/firmware and drivers/reset across platforms"

* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (87 commits)
  reset: uniphier: add ethernet reset control support for PXs3
  reset: stm32mp1: Enable stm32mp1 reset driver
  dt-bindings: reset: add STM32MP1 resets
  reset: uniphier: add Pro4/Pro5/PXs2 audio systems reset control
  reset: imx7: add 'depends on HAS_IOMEM' to fix unmet dependency
  reset: modify the way reset lookup works for board files
  reset: add support for non-DT systems
  clk: scmi: use devm_of_clk_add_hw_provider() API and drop scmi_clocks_remove
  firmware: arm_scmi: prevent accessing rate_discrete uninitialized
  hwmon: (scmi) return -EINVAL when sensor information is unavailable
  amlogic: meson-gx-socinfo: Update soc ids
  soc/tegra: pmc: Use the new reset APIs to manage reset controllers
  soc: mediatek: update power domain data of MT2712
  dt-bindings: soc: update MT2712 power dt-bindings
  cpufreq: scmi: add thermal dependency
  soc: mediatek: fix the mistaken pointer accessed when subdomains are added
  soc: mediatek: add SCPSYS power domain driver for MediaTek MT7623A SoC
  soc: mediatek: avoid hardcoded value with bus_prot_mask
  dt-bindings: soc: add header files required for MT7623A SCPSYS dt-binding
  dt-bindings: soc: add SCPSYS binding for MT7623 and MT7623A SoC
  ...
parents 16756934 7df3f0bb
Loading
Loading
Loading
Loading
+179 −0
Original line number Diff line number Diff line
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 DUI 0922B ("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"
- 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.

Optional properties:

- mbox-names: shall be "tx" or "rx" depending on mboxes entries.

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.

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.

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.txt
[3] Documentation/devicetree/bindings/thermal/thermal.txt
[4] Documentation/devicetree/bindings/sram/sram.txt

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

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

thermal-zones {
	soc_thermal {
		polling-delay-passive = <100>;
		polling-delay = <1000>;
					/* sensor ID */
		thermal-sensors = <&scmi_sensors0 3>;
		...
	};
};
+6 −0
Original line number Diff line number Diff line
@@ -43,6 +43,12 @@ following properties:
- interrupt-parent: a phandle indicating which interrupt controller
  this PMU signals interrupts to.


Optional nodes:

- nodes defining the restart and poweroff syscon children


Example :
pmu_system_controller: system-controller@10040000 {
	compatible = "samsung,exynos5250-pmu", "syscon";
+28 −0
Original line number Diff line number Diff line
@@ -23,6 +23,11 @@ Required property:

Optional property:
- mbox-names: List of identifier strings for each mailbox channel.
- shmem : List of phandle pointing to the shared memory(SHM) area between the
	  users of these mailboxes for IPC, one for each mailbox. This shared
	  memory can be part of any memory reserved for the purpose of this
	  communication between the mailbox client and the remote.


Example:
	pwr_cntrl: power {
@@ -30,3 +35,26 @@ Example:
		mbox-names = "pwr-ctrl", "rpc";
		mboxes = <&mailbox 0 &mailbox 1>;
	};

Example with shared memory(shmem):

	sram: sram@50000000 {
		compatible = "mmio-sram";
		reg = <0x50000000 0x10000>;

		#address-cells = <1>;
		#size-cells = <1>;
		ranges = <0 0x50000000 0x10000>;

		cl_shmem: shmem@0 {
			compatible = "client-shmem";
			reg = <0x0 0x200>;
		};
	};

	client@2e000000 {
		...
		mboxes = <&mailbox 0>;
		shmem = <&cl_shmem>;
		..
	};
+21 −0
Original line number Diff line number Diff line
@@ -176,3 +176,24 @@ lhc: lhc@20 {
	compatible = "aspeed,ast2500-lhc";
	reg = <0x20 0x24 0x48 0x8>;
};

LPC reset control
-----------------

The UARTs present in the ASPEED SoC can have their resets tied to the reset
state of the LPC bus. Some systems may chose to modify this configuration.

Required properties:

 - compatible:		"aspeed,ast2500-lpc-reset" or
			"aspeed,ast2400-lpc-reset"
 - reg:			offset and length of the IP in the LHC memory region
 - #reset-controller	indicates the number of reset cells expected

Example:

lpc_reset: reset-controller@18 {
        compatible = "aspeed,ast2500-lpc-reset";
        reg = <0x18 0x4>;
        #reset-cells = <1>;
};
Loading