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

Commit f46f11dc authored by Arnd Bergmann's avatar Arnd Bergmann
Browse files

Merge tag 'scmi-updates-4.17' of... 

Merge tag 'scmi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers

Pull "ARM SCMI support for v4.17" from Sudeep Holla:

ARM System Control and Management Interface(SCMI)[1] is more flexible and
easily extensible than any of the existing interfaces.

Few existing as well as future ARM platforms provide micro-controllers
to abstract various power and other system management tasks which have
similar interfaces, both in terms of the functions that are provided by
them, and in terms of how requests are communicated to them.

There are quite a few protocols like ARM SCPI, TI SCI, QCOM RPM, Nvidia Tegra
BPMP, and so on already. This specification is to standardize and avoid any
further fragmentation in the design of such interface by various vendors.

The current SCMI driver implementation is very basic and initial support.
It lacks support for notifications, asynchronous/delayed response, perf/power
statistics region and sensor register region.

Mailbox is the only form of transport supported currently in the driver.
SCMI supports interrupt based mailbox communication, where, on completion
of the processing of a message, the caller receives an interrupt as well as
polling for completion.

SCMI is designed to minimize the dependency on the mailbox/transport
hardware. So in terms of SCMI, each channel in the mailbox includes
memory area, doorbell and completion interrupt.

However the doorbell and completion interrupt is highly mailbox dependent
which was bit of controversial as part of SCMI/mailbox discussions.

Arnd and me discussed about the few aspects of SCMI and the mailbox framework:

1. Use of mailbox framework for doorbell type mailbox controller:
   - Such hardware may not require any data to be sent to signal the remote
     about the presence of a message. The channel will have in-built
     information on how to trigger the signal to the remote.
     There are few mailbox controller drivers which are purely doorbell based.
     e.g.QCOM IPC, STM, Tegra, ACPI PCC,..etc

2. Supporting other mailbox controller:
   - SCMI just needs a mechanism to signal the remote firmware. Such
     controller may need fixed message to be sent to trigger a doorbell.
     In such case we may need to get that data from DT and pass the same
     to the controller. It's not covered in the current DT binding, but
     can be extended as optional property in future.

     However handling notifications may be interesting on such mailbox, but
     again there is no way to interpret what the data field(remote message)
     means, it could be a bit mask or a number or don't-care.

Arnd mentioned that he doesn't like the way the mailbox binding deals
with doorbell-type hardware, but we do have quite a few precedent drivers
already and changing the binding to add a data field would not make it any
better, but could cause other problems. So he is happy with the status quo
of SCMI implementation.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0056a/index.html

* tag 'scmi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  cpufreq: scmi: add support for fast frequency switching
  cpufreq: add support for CPU DVFS based on SCMI message protocol
  hwmon: add support for sensors exported via ARM SCMI
  hwmon: (core) Add hwmon_max to hwmon_sensor_types enumeration
  clk: add support for clocks provided by SCMI
  firmware: arm_scmi: add device power domain support using genpd
  firmware: arm_scmi: add per-protocol channels support using idr objects
  firmware: arm_scmi: refactor in preparation to support per-protocol channels
  firmware: arm_scmi: add option for polling based performance domain operations
  firmware: arm_scmi: add support for polling based SCMI transfers
  firmware: arm_scmi: probe and initialise all the supported protocols
  firmware: arm_scmi: add initial support for sensor protocol
  firmware: arm_scmi: add initial support for power protocol
  firmware: arm_scmi: add initial support for clock protocol
  firmware: arm_scmi: add initial support for performance protocol
  firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices
  firmware: arm_scmi: add common infrastructure and support for base protocol
  firmware: arm_scmi: add basic driver infrastructure for SCMI
  dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol
  dt-bindings: mailbox: add support for mailbox client shared memory
parents 819d38e9 02f208c5

Documentation/devicetree/bindings/arm/arm,scmi.txt

0 → 100644
+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>;

		...

	};

};

Documentation/devicetree/bindings/mailbox/mailbox.txt

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

		..

	};

MAINTAINERS

+6 −5
Original line number Diff line number Diff line
@@ -13395,15 +13395,16 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
S:	Supported

F:	drivers/mfd/syscon.c



SYSTEM CONTROL & POWER INTERFACE (SCPI) Message Protocol drivers

SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE (SCPI/SCMI) Message Protocol drivers

M:	Sudeep Holla <sudeep.holla@arm.com>

L:	linux-arm-kernel@lists.infradead.org

S:	Maintained

F:	Documentation/devicetree/bindings/arm/arm,scpi.txt

F:	drivers/clk/clk-scpi.c

F:	drivers/cpufreq/scpi-cpufreq.c

F:	Documentation/devicetree/bindings/arm/arm,sc[mp]i.txt

F:	drivers/clk/clk-sc[mp]i.c

F:	drivers/cpufreq/sc[mp]i-cpufreq.c

F:	drivers/firmware/arm_scpi.c

F:	include/linux/scpi_protocol.h

F:	drivers/firmware/arm_scmi/

F:	include/linux/sc[mp]i_protocol.h



SYSTEM RESET/SHUTDOWN DRIVERS

M:	Sebastian Reichel <sre@kernel.org>

drivers/clk/Kconfig

+10 −0
Original line number Diff line number Diff line
@@ -62,6 +62,16 @@ config COMMON_CLK_HI655X 
	  multi-function device has one fixed-rate oscillator, clocked

	  at 32KHz.



config COMMON_CLK_SCMI

	tristate "Clock driver controlled via SCMI interface"

	depends on ARM_SCMI_PROTOCOL || COMPILE_TEST

	  ---help---

	  This driver provides support for clocks that are controlled

	  by firmware that implements the SCMI interface.



	  This driver uses SCMI Message Protocol to interact with the

	  firmware providing all the clock controls.



config COMMON_CLK_SCPI

	tristate "Clock driver controlled via SCPI interface"

	depends on ARM_SCPI_PROTOCOL || COMPILE_TEST

drivers/clk/Makefile

+1 −0
Original line number Diff line number Diff line
@@ -41,6 +41,7 @@ obj-$(CONFIG_CLK_QORIQ) += clk-qoriq.o 
obj-$(CONFIG_COMMON_CLK_RK808)		+= clk-rk808.o

obj-$(CONFIG_COMMON_CLK_HI655X)		+= clk-hi655x.o

obj-$(CONFIG_COMMON_CLK_S2MPS11)	+= clk-s2mps11.o

obj-$(CONFIG_COMMON_CLK_SCMI)           += clk-scmi.o

obj-$(CONFIG_COMMON_CLK_SCPI)           += clk-scpi.o

obj-$(CONFIG_COMMON_CLK_SI5351)		+= clk-si5351.o

obj-$(CONFIG_COMMON_CLK_SI514)		+= clk-si514.o