| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20170810192838.prslgnjvxv3xvyes@rob-hp-laptop>
Date: Thu, 10 Aug 2017 14:28:38 -0500
From: Rob Herring <robh@...nel.org>
To: Sudeep Holla <sudeep.holla@....com>
Cc: ALKML <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>,
DTML <devicetree@...r.kernel.org>,
Roy Franz <roy.franz@...ium.com>,
Harb Abdulhamid <harba@...eaurora.org>,
Nishanth Menon <nm@...com>, Arnd Bergmann <arnd@...db.de>,
Loc Ho <lho@....com>, Alexey Klimov <alexey.klimov@....com>,
Ryan Harkin <Ryan.Harkin@....com>,
Jassi Brar <jassisinghbrar@...il.com>,
Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH v2 02/18] dt-bindings: arm: add support for ARM System
Control and Management Interface(SCMI) protocol
On Fri, Aug 04, 2017 at 03:31:28PM +0100, Sudeep Holla wrote:
> 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@...nel.org>
> Cc: Mark Rutland <mark.rutland@....com>
> Signed-off-by: Sudeep Holla <sudeep.holla@....com>
> ---
> Documentation/devicetree/bindings/arm/arm,scmi.txt | 174 +++++++++++++++++++++
> 1 file changed, 174 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
> new file mode 100644
> index 000000000000..33c16be58e72
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt
> @@ -0,0 +1,174 @@
> +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:
Please define this is a subnode of /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 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 SCMI commands.
> +
> +PM domain consumers
> +===================
How consumers work is already defined elsewhere.
> +
> +Required properties:
> + - power-domains : A phandle and PM domain specifier as defined by bindings of
> + the power controller specified by phandle.
> +
> +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[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.
> +
> +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 [3]
> +
> +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/thermal/thermal.txt
> +[3] Documentation/devicetree/bindings/sram/sram.txt
> +[4] Documentation/devicetree/bindings/power/power_domain.txt
> +
> +Example:
> +
> +sram: sram@...00000 {
> + 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: mailbox0@...00000 {
> + ....
> + #mbox-cells = <1>;
> +};
> +
> +scmi_protocol: scmi@...00000 {
The unit address is not valid.
> + compatible = "arm,scmi";
> + method = "mailbox-doorbell";
Is this not implied by the mboxes property?
> + 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@...60000 {
> + ...
> + 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>;
> + ...
> + };
> +};
> --
> 2.7.4
>
Powered by blists - more mailing lists