diff mbox series

[v3,02/22] dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol

Message ID 1506604306-20739-3-git-send-email-sudeep.holla@arm.com
State Superseded
Headers show
Series [v3,01/22] dt-bindings: mailbox: add support for mailbox client shared memory | expand

Commit Message

Sudeep Holla Sept. 28, 2017, 1:11 p.m. UTC 
This patch adds devicetree binding for System Control and Management
Interface (SCMI) Message Protocol used between the Application Cores(AP)
and the System Control Processor(SCP). The MHU peripheral provides a
mechanism for inter-processor communication between SCP's M3 processor
and AP.

SCP offers control and management of the core/cluster power states,
various power domain DVFS including the core/cluster, certain system
clocks configuration, thermal sensors and many others.

SCMI protocol is developed as better replacement to the existing SCPI
which is not flexible and easily extensible.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

---
 Documentation/devicetree/bindings/arm/arm,scmi.txt | 171 +++++++++++++++++++++
 MAINTAINERS                                        |   4 +-
 2 files changed, 173 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt

-- 
2.7.4

Comments

Jassi Brar Oct. 5, 2017, 1:20 p.m. UTC | #1 
On Wed, Oct 4, 2017 at 5:35 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Oct 4, 2017 at 1:07 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

>> On 04/10/17 11:50, Arnd Bergmann wrote:

>>> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:


>

>>>> +- shmem : List of phandle pointing to the shared memory(SHM) area as per

>>>> +         generic mailbox client binding.

>>>> +

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

>>>

>>> This looks odd: why not make the message itself part of the mailbox

>>> protocol here, and leave the shmem as a implementation detail of the

>>> mailbox driver?

>>>

>>

>> I am not sure if I follow you here. But generally shmem can be memory

>> carved out of anything in the system and it's dependent on the protocol

>> and the remote firmware rather than the mailbox hardware itself.

>

> I think the problem is the way we use the mailbox API in Linux, which

> is completely abstract at the moment: it could be a pure doorbell, a

> single-register for a data, some structured memory, or a

> variable-length message. The assumption today is that the mailbox

> user and the mailbox driver agree on the interpretation of that

> void pointer.

>

The way controllers and remote firmwares are paired there is no other
way to write reusable code.

> This breaks down here, as you require the message to be a

> variable-length message in a fixed physical location, but assume that

> the mailbox serves only as a doorbell.

>

That is a valid usecase, already supported. There's an optional
callback provided by the api to fill SHMEM
mbox_chan->mbox_client->tx_prepare()

Data passing via SHMEM is purely optional because some controllers
have deep fifos to carry data while some platforms may not have any
region of memory shared between Linux and the remote firmware.

Thanks.
Sudeep Holla Oct. 5, 2017, 2:10 p.m. UTC | #2 
On 05/10/17 14:20, Jassi Brar wrote:
> On Wed, Oct 4, 2017 at 5:35 AM, Arnd Bergmann <arnd@arndb.de> wrote:

>> On Wed, Oct 4, 2017 at 1:07 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

>>> On 04/10/17 11:50, Arnd Bergmann wrote:

>>>> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:

> 

>>

>>>>> +- shmem : List of phandle pointing to the shared memory(SHM) area as per

>>>>> +         generic mailbox client binding.

>>>>> +

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

>>>>

>>>> This looks odd: why not make the message itself part of the mailbox

>>>> protocol here, and leave the shmem as a implementation detail of the

>>>> mailbox driver?

>>>>

>>>

>>> I am not sure if I follow you here. But generally shmem can be memory

>>> carved out of anything in the system and it's dependent on the protocol

>>> and the remote firmware rather than the mailbox hardware itself.

>>

>> I think the problem is the way we use the mailbox API in Linux, which

>> is completely abstract at the moment: it could be a pure doorbell, a

>> single-register for a data, some structured memory, or a

>> variable-length message. The assumption today is that the mailbox

>> user and the mailbox driver agree on the interpretation of that

>> void pointer.

>>

> The way controllers and remote firmwares are paired there is no other

> way to write reusable code.

> 

>> This breaks down here, as you require the message to be a

>> variable-length message in a fixed physical location, but assume that

>> the mailbox serves only as a doorbell.

>>

> That is a valid usecase, already supported. There's an optional

> callback provided by the api to fill SHMEM

> mbox_chan->mbox_client->tx_prepare()

> 


Thanks, I missed to mention this earlier. But the point here is to avoid
the shim layer with each protocol for most common use case like doorbell.

But what I understood from Arnd's suggestion is to have another API
which just *sends signal* _rather_than_ *send data" to identify between
the two.
-- 
Regards,
Sudeep
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
new file mode 100644
index 000000000000..226ed2e9ac6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt
@@ -0,0 +1,171 @@ 
+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.
+- mbox-names: shall be "tx" or "rx"
+- shmem : List of phandle pointing to the shared memory(SHM) area as per
+	  generic mailbox client binding.
+
+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>;
+		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>;
+		...
+	};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 6671f375f7fc..f4b5f3967725 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12936,11 +12936,11 @@  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:	Documentation/devicetree/bindings/arm/arm,sc[mp]i.txt
 F:	drivers/clk/clk-scpi.c
 F:	drivers/cpufreq/scpi-cpufreq.c
 F:	drivers/firmware/arm_scpi.c