* [PATCH v2 0/8] dt-bindings: firmware: Convert SCPI and SCMI to json schema
@ 2021-06-01 22:48 ` Sudeep Holla
0 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:48 UTC (permalink / raw)
To: devicetree; +Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi
Hi Rob,
Thanks for the review of v1. I managed to add regulator support. Exploiting
the explicit pattern, I have used protocol@*, to make #*-cells as required.
Lots of repeated schema except the #*-cells, not sure if there is any
better way to collapse or take the common out.
Regards,
Sudeep
v1->v2:
- Fixed wrongly used "arm,scpi-shmem" with correct "arm,scp-shmem"
- Fixed support for "arm,scpi-pre-1.0" only
- Added example for amlogic,meson-gxbb-scpi
- Added regulator support, expanded all the protocol@* patters
to mark #*-cells as required property
Sudeep Holla (8):
dt-bindings: firmware: arm,scpi: Move arm,scp-shmem to json schema
dt-bindings: firmware: arm,scmi: Move arm,scmi-shmem to json schema
dt-bindings: firmware: juno,scpi: Move to sram.yaml json schema
dt-bindings: firmware: amlogic,scpi: Move arm,scpi-shmem to json schema
dt-bindings: mailbox : arm,mhu: Fix arm,scpi example used here
dt-bindings: firmware: arm,scpi: Convert to json schema
dt-bindings: firmware: amlogic,scpi: Convert to json schema
dt-bindings: firmware: arm,scmi: Convert to json schema
.../devicetree/bindings/arm/amlogic,scpi.txt | 27 -
.../devicetree/bindings/arm/arm,scmi.txt | 239 ---------
.../devicetree/bindings/arm/arm,scpi.txt | 219 --------
.../devicetree/bindings/arm/juno,scpi.txt | 26 -
.../bindings/firmware/arm,scmi.yaml | 474 ++++++++++++++++++
.../bindings/firmware/arm,scpi.yaml | 317 ++++++++++++
.../devicetree/bindings/mailbox/arm,mhu.yaml | 10 +-
.../devicetree/bindings/sram/sram.yaml | 5 +
MAINTAINERS | 2 +-
9 files changed, 805 insertions(+), 514 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
delete mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt
delete mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt
delete mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
create mode 100644 Documentation/devicetree/bindings/firmware/arm,scmi.yaml
create mode 100644 Documentation/devicetree/bindings/firmware/arm,scpi.yaml
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 1/8] dt-bindings: firmware: arm,scpi: Move arm,scp-shmem to json schema
2021-06-01 22:48 ` Sudeep Holla
@ 2021-06-01 22:48 ` Sudeep Holla
-1 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:48 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Kevin Hilman, Neil Armstrong, Jerome Brunet
Move the SRAM and shared memory binding for SCPI into the existing
Generic on-chip SRAM. We just need to update the compatible list and
there-by remove the whole old text format binding for the same.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/arm,scpi.txt | 15 ---------------
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index bcd6c3ec471e..bcb8b3d61e68 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -56,21 +56,6 @@ Sub-nodes
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.
-
-The properties should follow the generic mmio-sram description found in [3]
-
-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,scp-shmem" for Non-secure SRAM based
- shared memory
-
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index c1a5afa73cfe..7fc208692a7a 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -80,6 +80,7 @@ description: |+
- amlogic,meson8b-smp-sram
- amlogic,meson-gxbb-scp-shmem
- amlogic,meson-axg-scp-shmem
+ - arm,scp-shmem
- renesas,smp-sram
- rockchip,rk3066-smp-sram
- samsung,exynos4210-sysram
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH v2 1/8] dt-bindings: firmware: arm, scpi: Move arm, scp-shmem to json schema
@ 2021-06-01 22:48 ` Sudeep Holla
0 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:48 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Kevin Hilman, Neil Armstrong, Jerome Brunet
Move the SRAM and shared memory binding for SCPI into the existing
Generic on-chip SRAM. We just need to update the compatible list and
there-by remove the whole old text format binding for the same.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/arm,scpi.txt | 15 ---------------
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index bcd6c3ec471e..bcb8b3d61e68 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -56,21 +56,6 @@ Sub-nodes
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.
-
-The properties should follow the generic mmio-sram description found in [3]
-
-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,scp-shmem" for Non-secure SRAM based
- shared memory
-
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index c1a5afa73cfe..7fc208692a7a 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -80,6 +80,7 @@ description: |+
- amlogic,meson8b-smp-sram
- amlogic,meson-gxbb-scp-shmem
- amlogic,meson-axg-scp-shmem
+ - arm,scp-shmem
- renesas,smp-sram
- rockchip,rk3066-smp-sram
- samsung,exynos4210-sysram
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH v2 1/8] dt-bindings: firmware: arm,scpi: Move arm,scp-shmem to json schema
2021-06-01 22:48 ` [PATCH v2 1/8] dt-bindings: firmware: arm, scpi: Move arm, scp-shmem " Sudeep Holla
@ 2021-06-02 15:41 ` Rob Herring
-1 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 15:41 UTC (permalink / raw)
To: Sudeep Holla
Cc: Cristian Marussi, linux-arm-kernel, Rob Herring, Jerome Brunet,
Kevin Hilman, Neil Armstrong, devicetree
On Tue, 01 Jun 2021 23:48:57 +0100, Sudeep Holla wrote:
> Move the SRAM and shared memory binding for SCPI into the existing
> Generic on-chip SRAM. We just need to update the compatible list and
> there-by remove the whole old text format binding for the same.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/arm,scpi.txt | 15 ---------------
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 2 files changed, 1 insertion(+), 15 deletions(-)
>
Applied, thanks!
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 1/8] dt-bindings: firmware: arm,scpi: Move arm,scp-shmem to json schema
@ 2021-06-02 15:41 ` Rob Herring
0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 15:41 UTC (permalink / raw)
To: Sudeep Holla
Cc: Cristian Marussi, linux-arm-kernel, Rob Herring, Jerome Brunet,
Kevin Hilman, Neil Armstrong, devicetree
On Tue, 01 Jun 2021 23:48:57 +0100, Sudeep Holla wrote:
> Move the SRAM and shared memory binding for SCPI into the existing
> Generic on-chip SRAM. We just need to update the compatible list and
> there-by remove the whole old text format binding for the same.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/arm,scpi.txt | 15 ---------------
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 2 files changed, 1 insertion(+), 15 deletions(-)
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 2/8] dt-bindings: firmware: arm,scmi: Move arm,scmi-shmem to json schema
2021-06-01 22:48 ` Sudeep Holla
@ 2021-06-01 22:48 ` Sudeep Holla
-1 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:48 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Florian Fainelli
Move the SRAM and shared memory binding for SCMI into the existing
Generic on-chip SRAM. We just need to update the compatible list and
there-by remove the whole old text format binding for the same.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/arm,scmi.txt | 15 ---------------
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
index 667d58e0a659..b7be2000afcb 100644
--- a/Documentation/devicetree/bindings/arm/arm,scmi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt
@@ -106,21 +106,6 @@ signal binding[5].
- #reset-cells : Should be 1. Contains the reset domain ID value used
by SCMI commands.
-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.yaml
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index 7fc208692a7a..543aa400fbdf 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -80,6 +80,7 @@ description: |+
- amlogic,meson8b-smp-sram
- amlogic,meson-gxbb-scp-shmem
- amlogic,meson-axg-scp-shmem
+ - arm,scmi-shmem
- arm,scp-shmem
- renesas,smp-sram
- rockchip,rk3066-smp-sram
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH v2 2/8] dt-bindings: firmware: arm, scmi: Move arm, scmi-shmem to json schema
@ 2021-06-01 22:48 ` Sudeep Holla
0 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:48 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Florian Fainelli
Move the SRAM and shared memory binding for SCMI into the existing
Generic on-chip SRAM. We just need to update the compatible list and
there-by remove the whole old text format binding for the same.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/arm,scmi.txt | 15 ---------------
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
index 667d58e0a659..b7be2000afcb 100644
--- a/Documentation/devicetree/bindings/arm/arm,scmi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt
@@ -106,21 +106,6 @@ signal binding[5].
- #reset-cells : Should be 1. Contains the reset domain ID value used
by SCMI commands.
-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.yaml
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index 7fc208692a7a..543aa400fbdf 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -80,6 +80,7 @@ description: |+
- amlogic,meson8b-smp-sram
- amlogic,meson-gxbb-scp-shmem
- amlogic,meson-axg-scp-shmem
+ - arm,scmi-shmem
- arm,scp-shmem
- renesas,smp-sram
- rockchip,rk3066-smp-sram
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH v2 2/8] dt-bindings: firmware: arm,scmi: Move arm,scmi-shmem to json schema
2021-06-01 22:48 ` [PATCH v2 2/8] dt-bindings: firmware: arm, scmi: Move arm, scmi-shmem " Sudeep Holla
@ 2021-06-02 15:41 ` Rob Herring
-1 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 15:41 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rob Herring, Cristian Marussi, devicetree, Florian Fainelli,
linux-arm-kernel
On Tue, 01 Jun 2021 23:48:58 +0100, Sudeep Holla wrote:
> Move the SRAM and shared memory binding for SCMI into the existing
> Generic on-chip SRAM. We just need to update the compatible list and
> there-by remove the whole old text format binding for the same.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Cristian Marussi <cristian.marussi@arm.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/arm,scmi.txt | 15 ---------------
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 2 files changed, 1 insertion(+), 15 deletions(-)
>
Applied, thanks!
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 2/8] dt-bindings: firmware: arm,scmi: Move arm,scmi-shmem to json schema
@ 2021-06-02 15:41 ` Rob Herring
0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 15:41 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rob Herring, Cristian Marussi, devicetree, Florian Fainelli,
linux-arm-kernel
On Tue, 01 Jun 2021 23:48:58 +0100, Sudeep Holla wrote:
> Move the SRAM and shared memory binding for SCMI into the existing
> Generic on-chip SRAM. We just need to update the compatible list and
> there-by remove the whole old text format binding for the same.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Cristian Marussi <cristian.marussi@arm.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/arm,scmi.txt | 15 ---------------
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 2 files changed, 1 insertion(+), 15 deletions(-)
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 3/8] dt-bindings: firmware: juno,scpi: Move to sram.yaml json schema
2021-06-01 22:48 ` Sudeep Holla
@ 2021-06-01 22:48 ` Sudeep Holla
-1 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:48 UTC (permalink / raw)
To: devicetree; +Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi
Commit a90b15e0ad72 ("Documentation: bindings: decouple juno specific
details from generic binding") moved the juno specific bindings into
separate file. Though there was no need for juno specific binding, it
has been used unfortunately for whatever stupid reason I added it for.
Let us move the same to the generic sram.yaml schema and remove the
old text format binding.
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/juno,scpi.txt | 26 -------------------
.../devicetree/bindings/sram/sram.yaml | 2 ++
2 files changed, 2 insertions(+), 26 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt
deleted file mode 100644
index 2ace8696bbee..000000000000
--- a/Documentation/devicetree/bindings/arm/juno,scpi.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-System Control and Power Interface (SCPI) Message Protocol
-(in addition to the standard binding in [0])
-
-Juno SRAM and Shared Memory for SCPI
-------------------------------------
-
-Required properties:
-- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
-
-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
---------------------------------------------------------------
-Required properties:
-- compatible : should be "arm,scpi-sensors".
-- #thermal-sensor-cells: should be set to 1.
- For Juno R0 and Juno R1 refer to [1] for the
- sensor identifiers
-
-[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
-[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index 543aa400fbdf..799ed9a0e4b2 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -28,6 +28,7 @@ description: |+
contains:
enum:
- mmio-sram
+ - arm,juno-sram-ns
- atmel,sama5d2-securam
- rockchip,rk3288-pmu-sram
@@ -80,6 +81,7 @@ description: |+
- amlogic,meson8b-smp-sram
- amlogic,meson-gxbb-scp-shmem
- amlogic,meson-axg-scp-shmem
+ - arm,juno-scp-shmem
- arm,scmi-shmem
- arm,scp-shmem
- renesas,smp-sram
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH v2 3/8] dt-bindings: firmware: juno, scpi: Move to sram.yaml json schema
@ 2021-06-01 22:48 ` Sudeep Holla
0 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:48 UTC (permalink / raw)
To: devicetree; +Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi
Commit a90b15e0ad72 ("Documentation: bindings: decouple juno specific
details from generic binding") moved the juno specific bindings into
separate file. Though there was no need for juno specific binding, it
has been used unfortunately for whatever stupid reason I added it for.
Let us move the same to the generic sram.yaml schema and remove the
old text format binding.
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/juno,scpi.txt | 26 -------------------
.../devicetree/bindings/sram/sram.yaml | 2 ++
2 files changed, 2 insertions(+), 26 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt
deleted file mode 100644
index 2ace8696bbee..000000000000
--- a/Documentation/devicetree/bindings/arm/juno,scpi.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-System Control and Power Interface (SCPI) Message Protocol
-(in addition to the standard binding in [0])
-
-Juno SRAM and Shared Memory for SCPI
-------------------------------------
-
-Required properties:
-- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
-
-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
---------------------------------------------------------------
-Required properties:
-- compatible : should be "arm,scpi-sensors".
-- #thermal-sensor-cells: should be set to 1.
- For Juno R0 and Juno R1 refer to [1] for the
- sensor identifiers
-
-[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
-[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index 543aa400fbdf..799ed9a0e4b2 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -28,6 +28,7 @@ description: |+
contains:
enum:
- mmio-sram
+ - arm,juno-sram-ns
- atmel,sama5d2-securam
- rockchip,rk3288-pmu-sram
@@ -80,6 +81,7 @@ description: |+
- amlogic,meson8b-smp-sram
- amlogic,meson-gxbb-scp-shmem
- amlogic,meson-axg-scp-shmem
+ - arm,juno-scp-shmem
- arm,scmi-shmem
- arm,scp-shmem
- renesas,smp-sram
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH v2 3/8] dt-bindings: firmware: juno,scpi: Move to sram.yaml json schema
2021-06-01 22:48 ` [PATCH v2 3/8] dt-bindings: firmware: juno, scpi: " Sudeep Holla
@ 2021-06-02 15:42 ` Rob Herring
-1 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 15:42 UTC (permalink / raw)
To: Sudeep Holla; +Cc: Rob Herring, devicetree, Cristian Marussi, linux-arm-kernel
On Tue, 01 Jun 2021 23:48:59 +0100, Sudeep Holla wrote:
> Commit a90b15e0ad72 ("Documentation: bindings: decouple juno specific
> details from generic binding") moved the juno specific bindings into
> separate file. Though there was no need for juno specific binding, it
> has been used unfortunately for whatever stupid reason I added it for.
>
> Let us move the same to the generic sram.yaml schema and remove the
> old text format binding.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/juno,scpi.txt | 26 -------------------
> .../devicetree/bindings/sram/sram.yaml | 2 ++
> 2 files changed, 2 insertions(+), 26 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
>
Applied, thanks!
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v2 3/8] dt-bindings: firmware: juno,scpi: Move to sram.yaml json schema
@ 2021-06-02 15:42 ` Rob Herring
0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 15:42 UTC (permalink / raw)
To: Sudeep Holla; +Cc: Rob Herring, devicetree, Cristian Marussi, linux-arm-kernel
On Tue, 01 Jun 2021 23:48:59 +0100, Sudeep Holla wrote:
> Commit a90b15e0ad72 ("Documentation: bindings: decouple juno specific
> details from generic binding") moved the juno specific bindings into
> separate file. Though there was no need for juno specific binding, it
> has been used unfortunately for whatever stupid reason I added it for.
>
> Let us move the same to the generic sram.yaml schema and remove the
> old text format binding.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/juno,scpi.txt | 26 -------------------
> .../devicetree/bindings/sram/sram.yaml | 2 ++
> 2 files changed, 2 insertions(+), 26 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 4/8] dt-bindings: firmware: amlogic,scpi: Move arm,scpi-shmem to json schema
2021-06-01 22:48 ` Sudeep Holla
@ 2021-06-01 22:49 ` Sudeep Holla
-1 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:49 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Kevin Hilman, Neil Armstrong, Jerome Brunet
"amlogic,meson-gxbb-scp-shmem" is already in the Generic on-chip SRAM
binding though "amlogic,meson-gxbb-scpi" is missing which is now added.
Also remove the whole old text format binding for the same.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/amlogic,scpi.txt | 12 ------------
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
index 5ab59da052df..ebfe302fb747 100644
--- a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
@@ -5,18 +5,6 @@ Required properties
- compatible : should be "amlogic,meson-gxbb-scpi"
-AMLOGIC SRAM and Shared Memory for SCPI
-------------------------------------
-
-Required properties:
-- compatible : should be "amlogic,meson-gxbb-sram"
-
-Each sub-node represents the reserved area for SCPI.
-
-Required sub-node properties:
-- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
- memory on Amlogic GXBB SoC.
-
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index 799ed9a0e4b2..3eda5049d183 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -28,6 +28,7 @@ description: |+
contains:
enum:
- mmio-sram
+ - amlogic,meson-gxbb-sram
- arm,juno-sram-ns
- atmel,sama5d2-securam
- rockchip,rk3288-pmu-sram
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH v2 4/8] dt-bindings: firmware: amlogic, scpi: Move arm, scpi-shmem to json schema
@ 2021-06-01 22:49 ` Sudeep Holla
0 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:49 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Kevin Hilman, Neil Armstrong, Jerome Brunet
"amlogic,meson-gxbb-scp-shmem" is already in the Generic on-chip SRAM
binding though "amlogic,meson-gxbb-scpi" is missing which is now added.
Also remove the whole old text format binding for the same.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/amlogic,scpi.txt | 12 ------------
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
index 5ab59da052df..ebfe302fb747 100644
--- a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
@@ -5,18 +5,6 @@ Required properties
- compatible : should be "amlogic,meson-gxbb-scpi"
-AMLOGIC SRAM and Shared Memory for SCPI
-------------------------------------
-
-Required properties:
-- compatible : should be "amlogic,meson-gxbb-sram"
-
-Each sub-node represents the reserved area for SCPI.
-
-Required sub-node properties:
-- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
- memory on Amlogic GXBB SoC.
-
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index 799ed9a0e4b2..3eda5049d183 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -28,6 +28,7 @@ description: |+
contains:
enum:
- mmio-sram
+ - amlogic,meson-gxbb-sram
- arm,juno-sram-ns
- atmel,sama5d2-securam
- rockchip,rk3288-pmu-sram
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH v2 4/8] dt-bindings: firmware: amlogic,scpi: Move arm,scpi-shmem to json schema
2021-06-01 22:49 ` [PATCH v2 4/8] dt-bindings: firmware: amlogic, scpi: Move arm, scpi-shmem " Sudeep Holla
@ 2021-06-02 15:42 ` Rob Herring
-1 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 15:42 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, Jerome Brunet, linux-arm-kernel, Rob Herring,
Kevin Hilman, Neil Armstrong, Cristian Marussi
On Tue, 01 Jun 2021 23:49:00 +0100, Sudeep Holla wrote:
> "amlogic,meson-gxbb-scp-shmem" is already in the Generic on-chip SRAM
> binding though "amlogic,meson-gxbb-scpi" is missing which is now added.
> Also remove the whole old text format binding for the same.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/amlogic,scpi.txt | 12 ------------
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 2 files changed, 1 insertion(+), 12 deletions(-)
>
Applied, thanks!
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v2 4/8] dt-bindings: firmware: amlogic,scpi: Move arm,scpi-shmem to json schema
@ 2021-06-02 15:42 ` Rob Herring
0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 15:42 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, Jerome Brunet, linux-arm-kernel, Rob Herring,
Kevin Hilman, Neil Armstrong, Cristian Marussi
On Tue, 01 Jun 2021 23:49:00 +0100, Sudeep Holla wrote:
> "amlogic,meson-gxbb-scp-shmem" is already in the Generic on-chip SRAM
> binding though "amlogic,meson-gxbb-scpi" is missing which is now added.
> Also remove the whole old text format binding for the same.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/amlogic,scpi.txt | 12 ------------
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 2 files changed, 1 insertion(+), 12 deletions(-)
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 5/8] dt-bindings: mailbox : arm,mhu: Fix arm,scpi example used here
2021-06-01 22:48 ` Sudeep Holla
@ 2021-06-01 22:49 ` Sudeep Holla
-1 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:49 UTC (permalink / raw)
To: devicetree; +Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi
Once the arm,scpi binding is converted to YAML format, the following
errors will be seen when doing `make DT_CHECKER_FLAGS=-m dt_binding_check`
From schema: Documentation/devicetree/bindings/firmware/arm,scpi.yaml
Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml:
scpi@2f000000: $nodename:0: 'scpi' was expected
Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml:
scpi@2f000000: reg: [[0, 788529152, 0, 512]] is not of type 'object'
Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml:
scpi@2f000000: 'shmem' is a required property
Fix those error following the SCPI bindings.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
Documentation/devicetree/bindings/mailbox/arm,mhu.yaml | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
index d07eb00b97c8..bfdc3e33565e 100644
--- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
@@ -126,9 +126,15 @@ additionalProperties: false
clock-names = "apb_pclk";
};
- mhu_client_scpi: scpi@2f000000 {
+ scpi {
compatible = "arm,scpi";
- reg = <0 0x2f000000 0 0x200>;
mboxes = <&mhuB 1 4>; /* HP-NonSecure, 5th doorbell */
+ shmem = <&cpu_scp_hpri>; /* HP-NonSecure */
+
+ scpi_devpd: power-domains-0 {
+ compatible = "arm,scpi-power-domains";
+ num-domains = <2>;
+ #power-domain-cells = <1>;
+ };
};
};
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH v2 5/8] dt-bindings: mailbox : arm, mhu: Fix arm, scpi example used here
@ 2021-06-01 22:49 ` Sudeep Holla
0 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:49 UTC (permalink / raw)
To: devicetree; +Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi
Once the arm,scpi binding is converted to YAML format, the following
errors will be seen when doing `make DT_CHECKER_FLAGS=-m dt_binding_check`
From schema: Documentation/devicetree/bindings/firmware/arm,scpi.yaml
Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml:
scpi@2f000000: $nodename:0: 'scpi' was expected
Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml:
scpi@2f000000: reg: [[0, 788529152, 0, 512]] is not of type 'object'
Documentation/devicetree/bindings/mailbox/arm,mhu.example.dt.yaml:
scpi@2f000000: 'shmem' is a required property
Fix those error following the SCPI bindings.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
Documentation/devicetree/bindings/mailbox/arm,mhu.yaml | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
index d07eb00b97c8..bfdc3e33565e 100644
--- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
@@ -126,9 +126,15 @@ additionalProperties: false
clock-names = "apb_pclk";
};
- mhu_client_scpi: scpi@2f000000 {
+ scpi {
compatible = "arm,scpi";
- reg = <0 0x2f000000 0 0x200>;
mboxes = <&mhuB 1 4>; /* HP-NonSecure, 5th doorbell */
+ shmem = <&cpu_scp_hpri>; /* HP-NonSecure */
+
+ scpi_devpd: power-domains-0 {
+ compatible = "arm,scpi-power-domains";
+ num-domains = <2>;
+ #power-domain-cells = <1>;
+ };
};
};
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v2 6/8] dt-bindings: firmware: arm,scpi: Convert to json schema
2021-06-01 22:48 ` Sudeep Holla
@ 2021-06-01 22:49 ` Sudeep Holla
-1 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:49 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Kevin Hilman, Neil Armstrong, Jerome Brunet
Convert the old text format binding for System Control and Power Interface
(SCPI) Message Protocol into the new and shiny YAML format.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/arm,scpi.txt | 204 -------------
.../bindings/firmware/arm,scpi.yaml | 285 ++++++++++++++++++
MAINTAINERS | 2 +-
3 files changed, 286 insertions(+), 205 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt
create mode 100644 Documentation/devicetree/bindings/firmware/arm,scpi.yaml
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
deleted file mode 100644
index bcb8b3d61e68..000000000000
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ /dev/null
@@ -1,204 +0,0 @@
-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" : For implementations complying to SCPI v1.0 or above
- * "arm,scpi-pre-1.0" : For implementations complying to all
- unversioned releases prior to SCPI v1.0
-- 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.
-
-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 details
- for your implementation for the IDs to use.
-
-Power domain bindings for the power domains based on SCPI 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 SCPI commands.
- - num-domains: Total number of power domains provided by SCPI. This is
- needed as the SCPI message protocol lacks a mechanism to
- query this information at runtime.
-
-PM domain consumers
-===================
-
-Required properties:
- - power-domains : A phandle and PM domain specifier as defined by bindings of
- the power controller specified by phandle.
-
-[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*.yaml
-[3] Documentation/devicetree/bindings/sram/sram.yaml
-[4] Documentation/devicetree/bindings/power/power-domain.yaml
-
-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>;
- };
-
- scpi_devpd: scpi-power-domains {
- compatible = "arm,scpi-power-domains";
- num-domains = <2>;
- #power-domain-cells = <1>;
- };
-};
-
-cpu@0 {
- ...
- reg = <0 0>;
- clocks = <&scpi_dvfs 0>;
-};
-
-hdlcd@7ff60000 {
- ...
- reg = <0 0x7ff60000 0 0x1000>;
- clocks = <&scpi_clk 4>;
- power-domains = <&scpi_devpd 1>;
-};
-
-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.
-
-The num-domains property in scpi-power-domains domain specifies that
-SCPI provides 2 power domains. The hdlcd node uses the power domain with
-domain ID 1.
diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
new file mode 100644
index 000000000000..b44a5a7040fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
@@ -0,0 +1,285 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2021 ARM Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: System Control and Power Interface (SCPI) Message Protocol bindings
+
+maintainers:
+ - Sudeep Holla <sudeep.holla@arm.com>
+
+description: |
+ 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.
+
+ This binding is intended to define the interface the firmware implementing
+ the SCPI provide for OSPM in the device tree.
+
+ [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
+
+properties:
+ $nodename:
+ const: scpi
+
+ compatible:
+ description: |
+ SCPI compliant firmware complying to SCPI v1.0 and above OR
+ SCPI compliant firmware complying to all unversioned releases
+ prior to SCPI v1.0
+ oneOf:
+ - const: arm,scpi # SCPI v1.0 and above
+ - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0
+
+ mboxes:
+ description: |
+ 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.
+ minItems: 1
+
+ shmem:
+ description: |
+ 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.
+ minItems: 1
+
+additionalProperties:
+ type: object
+
+patternProperties:
+ "^(sensors|power-domains)(-[0-9a-f]+)?$":
+ type: object
+ description: |
+ Each sub-node represents one of the controller - power domains or sensors.
+
+ properties:
+ compatible:
+ oneOf:
+ - const: arm,scpi-sensors
+ - const: arm,scpi-power-domains
+
+ "^clocks(-[0-9a-f]+)?$":
+ type: object
+ description: |
+ "arm,scpi-clocks" - This is the container node. Each sub-node
+ represents one of the types of clock controller - indexed or full range.
+
+ "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.
+
+ properties:
+ compatible:
+ oneOf:
+ - const: arm,scpi-clocks
+ - const: arm,scpi-dvfs-clocks
+ - const: arm,scpi-variable-clocks
+
+required:
+ - compatible
+ - mboxes
+ - shmem
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: arm,scpi-sensors
+ then:
+ properties:
+ '#thermal-sensor-cells':
+ const: 1
+
+ required:
+ - '#thermal-sensor-cells'
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: arm,scpi-power-domains
+ then:
+ properties:
+ '#power-domain-cells':
+ const: 1
+
+ num-domains:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Total number of power domains provided by SCPI. This is needed as
+ the SCPI message protocol lacks a mechanism to query this
+ information at runtime.
+
+ required:
+ - '#power-domain-cells'
+ - num-domains
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - arm,scpi-dvfs-clocks
+ - arm,scpi-variable-clocks
+ then:
+ properties:
+ '#clock-cells':
+ const: 1
+ clock-output-names:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ clock-indices:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ 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.
+
+ required:
+ - '#clock-cells'
+ - clock-output-names
+ - clock-indices
+
+examples:
+ - |
+ firmware {
+ scpi {
+ compatible = "arm,scpi";
+ mboxes = <&mhuA 1>;
+ shmem = <&cpu_scp_hpri>; /* HP-NonSecure */
+
+ scpi_devpd: power-domains-0 {
+ compatible = "arm,scpi-power-domains";
+ num-domains = <2>;
+ #power-domain-cells = <1>;
+ };
+
+ clocks {
+ compatible = "arm,scpi-clocks";
+
+ scpi_dvfs: clocks-0 {
+ compatible = "arm,scpi-dvfs-clocks";
+ #clock-cells = <1>;
+ clock-indices = <0>, <1>, <2>;
+ clock-output-names = "atlclk", "aplclk","gpuclk";
+ };
+
+ scpi_clk: clocks-1 {
+ compatible = "arm,scpi-variable-clocks";
+ #clock-cells = <1>;
+ clock-indices = <3>, <4>;
+ clock-output-names = "pxlclk0", "pxlclk1";
+ };
+ };
+
+ scpi_sensors: sensors-0 {
+ compatible = "arm,scpi-sensors";
+ #thermal-sensor-cells = <1>;
+ };
+
+ };
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ 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-sram-section@0 {
+ compatible = "arm,scp-shmem";
+ reg = <0x0 0x200>;
+ };
+
+ cpu_scp_hpri: scp-sram-section@200 {
+ compatible = "arm,scp-shmem";
+ reg = <0x200 0x200>;
+ };
+ };
+
+ mhuA: mailbox@2b2f0000 {
+ #mbox-cells = <1>;
+ compatible = "arm,mhu", "arm,primecell";
+ reg = <0 0x2b2f0000 0 0x1000>;
+ interrupts = <0 36 4>, /* LP-NonSecure */
+ <0 35 4>, /* HP-NonSecure */
+ <0 37 4>; /* Secure */
+ clocks = <&clock 0 2 1>;
+ clock-names = "apb_pclk";
+ };
+
+ gpu@ffe40000 {
+ compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
+ reg = <0x0 0xffe40000 0x0 0x10000>;
+ interrupts = <0 160 4>, <0 161 4>, <0 162 4>;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&scpi_clk 1>;
+ power-domains = <&scpi_devpd 8>;
+ resets = <&scpi_reset 0>, <&scpi_reset 1>;
+ };
+
+ display@20930000 {
+ compatible = "intel,keembay-display";
+ reg = <0x0 0x20930000 0x0 0x3000>;
+ reg-names = "lcd";
+ interrupts = <0 33 4>;
+ clocks = <&scpi_clk 0x83>,
+ <&scpi_clk 0x0>;
+ clock-names = "clk_lcd", "clk_pll0";
+
+ port {
+ disp_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ };
+ };
+ };
+
+ thermal-zones {
+ soc-thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <1000>;
+ thermal-sensors = <&scpi_sensors0 3>;
+
+ trips {
+ mpu0_crit: mpu0_crit {
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = "critical";
+ };
+ };
+ };
+ };
+ };
+
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <2>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&scpi_dvfs 0>;
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index bd7aff0c120f..6a12597a86e1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17696,7 +17696,7 @@ M: Sudeep Holla <sudeep.holla@arm.com>
R: Cristian Marussi <cristian.marussi@arm.com>
L: linux-arm-kernel@lists.infradead.org
S: Maintained
-F: Documentation/devicetree/bindings/arm/arm,sc[mp]i.txt
+F: Documentation/devicetree/bindings/firmware/arm,sc[mp]i.yaml
F: drivers/clk/clk-sc[mp]i.c
F: drivers/cpufreq/sc[mp]i-cpufreq.c
F: drivers/firmware/arm_scmi/
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH v2 6/8] dt-bindings: firmware: arm, scpi: Convert to json schema
@ 2021-06-01 22:49 ` Sudeep Holla
0 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:49 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Kevin Hilman, Neil Armstrong, Jerome Brunet
Convert the old text format binding for System Control and Power Interface
(SCPI) Message Protocol into the new and shiny YAML format.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/arm,scpi.txt | 204 -------------
.../bindings/firmware/arm,scpi.yaml | 285 ++++++++++++++++++
MAINTAINERS | 2 +-
3 files changed, 286 insertions(+), 205 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt
create mode 100644 Documentation/devicetree/bindings/firmware/arm,scpi.yaml
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
deleted file mode 100644
index bcb8b3d61e68..000000000000
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ /dev/null
@@ -1,204 +0,0 @@
-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" : For implementations complying to SCPI v1.0 or above
- * "arm,scpi-pre-1.0" : For implementations complying to all
- unversioned releases prior to SCPI v1.0
-- 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.
-
-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 details
- for your implementation for the IDs to use.
-
-Power domain bindings for the power domains based on SCPI 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 SCPI commands.
- - num-domains: Total number of power domains provided by SCPI. This is
- needed as the SCPI message protocol lacks a mechanism to
- query this information at runtime.
-
-PM domain consumers
-===================
-
-Required properties:
- - power-domains : A phandle and PM domain specifier as defined by bindings of
- the power controller specified by phandle.
-
-[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*.yaml
-[3] Documentation/devicetree/bindings/sram/sram.yaml
-[4] Documentation/devicetree/bindings/power/power-domain.yaml
-
-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>;
- };
-
- scpi_devpd: scpi-power-domains {
- compatible = "arm,scpi-power-domains";
- num-domains = <2>;
- #power-domain-cells = <1>;
- };
-};
-
-cpu@0 {
- ...
- reg = <0 0>;
- clocks = <&scpi_dvfs 0>;
-};
-
-hdlcd@7ff60000 {
- ...
- reg = <0 0x7ff60000 0 0x1000>;
- clocks = <&scpi_clk 4>;
- power-domains = <&scpi_devpd 1>;
-};
-
-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.
-
-The num-domains property in scpi-power-domains domain specifies that
-SCPI provides 2 power domains. The hdlcd node uses the power domain with
-domain ID 1.
diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
new file mode 100644
index 000000000000..b44a5a7040fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
@@ -0,0 +1,285 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2021 ARM Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: System Control and Power Interface (SCPI) Message Protocol bindings
+
+maintainers:
+ - Sudeep Holla <sudeep.holla@arm.com>
+
+description: |
+ 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.
+
+ This binding is intended to define the interface the firmware implementing
+ the SCPI provide for OSPM in the device tree.
+
+ [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
+
+properties:
+ $nodename:
+ const: scpi
+
+ compatible:
+ description: |
+ SCPI compliant firmware complying to SCPI v1.0 and above OR
+ SCPI compliant firmware complying to all unversioned releases
+ prior to SCPI v1.0
+ oneOf:
+ - const: arm,scpi # SCPI v1.0 and above
+ - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0
+
+ mboxes:
+ description: |
+ 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.
+ minItems: 1
+
+ shmem:
+ description: |
+ 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.
+ minItems: 1
+
+additionalProperties:
+ type: object
+
+patternProperties:
+ "^(sensors|power-domains)(-[0-9a-f]+)?$":
+ type: object
+ description: |
+ Each sub-node represents one of the controller - power domains or sensors.
+
+ properties:
+ compatible:
+ oneOf:
+ - const: arm,scpi-sensors
+ - const: arm,scpi-power-domains
+
+ "^clocks(-[0-9a-f]+)?$":
+ type: object
+ description: |
+ "arm,scpi-clocks" - This is the container node. Each sub-node
+ represents one of the types of clock controller - indexed or full range.
+
+ "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.
+
+ properties:
+ compatible:
+ oneOf:
+ - const: arm,scpi-clocks
+ - const: arm,scpi-dvfs-clocks
+ - const: arm,scpi-variable-clocks
+
+required:
+ - compatible
+ - mboxes
+ - shmem
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: arm,scpi-sensors
+ then:
+ properties:
+ '#thermal-sensor-cells':
+ const: 1
+
+ required:
+ - '#thermal-sensor-cells'
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: arm,scpi-power-domains
+ then:
+ properties:
+ '#power-domain-cells':
+ const: 1
+
+ num-domains:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Total number of power domains provided by SCPI. This is needed as
+ the SCPI message protocol lacks a mechanism to query this
+ information at runtime.
+
+ required:
+ - '#power-domain-cells'
+ - num-domains
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - arm,scpi-dvfs-clocks
+ - arm,scpi-variable-clocks
+ then:
+ properties:
+ '#clock-cells':
+ const: 1
+ clock-output-names:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ clock-indices:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ 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.
+
+ required:
+ - '#clock-cells'
+ - clock-output-names
+ - clock-indices
+
+examples:
+ - |
+ firmware {
+ scpi {
+ compatible = "arm,scpi";
+ mboxes = <&mhuA 1>;
+ shmem = <&cpu_scp_hpri>; /* HP-NonSecure */
+
+ scpi_devpd: power-domains-0 {
+ compatible = "arm,scpi-power-domains";
+ num-domains = <2>;
+ #power-domain-cells = <1>;
+ };
+
+ clocks {
+ compatible = "arm,scpi-clocks";
+
+ scpi_dvfs: clocks-0 {
+ compatible = "arm,scpi-dvfs-clocks";
+ #clock-cells = <1>;
+ clock-indices = <0>, <1>, <2>;
+ clock-output-names = "atlclk", "aplclk","gpuclk";
+ };
+
+ scpi_clk: clocks-1 {
+ compatible = "arm,scpi-variable-clocks";
+ #clock-cells = <1>;
+ clock-indices = <3>, <4>;
+ clock-output-names = "pxlclk0", "pxlclk1";
+ };
+ };
+
+ scpi_sensors: sensors-0 {
+ compatible = "arm,scpi-sensors";
+ #thermal-sensor-cells = <1>;
+ };
+
+ };
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ 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-sram-section@0 {
+ compatible = "arm,scp-shmem";
+ reg = <0x0 0x200>;
+ };
+
+ cpu_scp_hpri: scp-sram-section@200 {
+ compatible = "arm,scp-shmem";
+ reg = <0x200 0x200>;
+ };
+ };
+
+ mhuA: mailbox@2b2f0000 {
+ #mbox-cells = <1>;
+ compatible = "arm,mhu", "arm,primecell";
+ reg = <0 0x2b2f0000 0 0x1000>;
+ interrupts = <0 36 4>, /* LP-NonSecure */
+ <0 35 4>, /* HP-NonSecure */
+ <0 37 4>; /* Secure */
+ clocks = <&clock 0 2 1>;
+ clock-names = "apb_pclk";
+ };
+
+ gpu@ffe40000 {
+ compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
+ reg = <0x0 0xffe40000 0x0 0x10000>;
+ interrupts = <0 160 4>, <0 161 4>, <0 162 4>;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&scpi_clk 1>;
+ power-domains = <&scpi_devpd 8>;
+ resets = <&scpi_reset 0>, <&scpi_reset 1>;
+ };
+
+ display@20930000 {
+ compatible = "intel,keembay-display";
+ reg = <0x0 0x20930000 0x0 0x3000>;
+ reg-names = "lcd";
+ interrupts = <0 33 4>;
+ clocks = <&scpi_clk 0x83>,
+ <&scpi_clk 0x0>;
+ clock-names = "clk_lcd", "clk_pll0";
+
+ port {
+ disp_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ };
+ };
+ };
+
+ thermal-zones {
+ soc-thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <1000>;
+ thermal-sensors = <&scpi_sensors0 3>;
+
+ trips {
+ mpu0_crit: mpu0_crit {
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = "critical";
+ };
+ };
+ };
+ };
+ };
+
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <2>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&scpi_dvfs 0>;
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index bd7aff0c120f..6a12597a86e1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17696,7 +17696,7 @@ M: Sudeep Holla <sudeep.holla@arm.com>
R: Cristian Marussi <cristian.marussi@arm.com>
L: linux-arm-kernel@lists.infradead.org
S: Maintained
-F: Documentation/devicetree/bindings/arm/arm,sc[mp]i.txt
+F: Documentation/devicetree/bindings/firmware/arm,sc[mp]i.yaml
F: drivers/clk/clk-sc[mp]i.c
F: drivers/cpufreq/sc[mp]i-cpufreq.c
F: drivers/firmware/arm_scmi/
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH v2 6/8] dt-bindings: firmware: arm,scpi: Convert to json schema
2021-06-01 22:49 ` [PATCH v2 6/8] dt-bindings: firmware: arm, scpi: " Sudeep Holla
@ 2021-06-02 15:58 ` Rob Herring
-1 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 15:58 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, linux-arm-kernel, Cristian Marussi, Kevin Hilman,
Neil Armstrong, Jerome Brunet
On Tue, Jun 01, 2021 at 11:49:02PM +0100, Sudeep Holla wrote:
> Convert the old text format binding for System Control and Power Interface
> (SCPI) Message Protocol into the new and shiny YAML format.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Cc: Viresh Kumar <viresh.kumar@linaro.org
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/arm,scpi.txt | 204 -------------
> .../bindings/firmware/arm,scpi.yaml | 285 ++++++++++++++++++
> MAINTAINERS | 2 +-
> 3 files changed, 286 insertions(+), 205 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt
> create mode 100644 Documentation/devicetree/bindings/firmware/arm,scpi.yaml
[...]
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
> new file mode 100644
> index 000000000000..b44a5a7040fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
> @@ -0,0 +1,285 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2021 ARM Ltd.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: System Control and Power Interface (SCPI) Message Protocol bindings
> +
> +maintainers:
> + - Sudeep Holla <sudeep.holla@arm.com>
> +
> +description: |
> + 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.
> +
> + This binding is intended to define the interface the firmware implementing
> + the SCPI provide for OSPM in the device tree.
> +
> + [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
> +
> +properties:
> + $nodename:
> + const: scpi
> +
> + compatible:
> + description: |
> + SCPI compliant firmware complying to SCPI v1.0 and above OR
> + SCPI compliant firmware complying to all unversioned releases
> + prior to SCPI v1.0
> + oneOf:
> + - const: arm,scpi # SCPI v1.0 and above
> + - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0
> +
> + mboxes:
> + description: |
> + 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.
> + minItems: 1
> +
> + shmem:
> + description: |
> + 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.
> + minItems: 1
> +
> +additionalProperties:
> + type: object
> +
> +patternProperties:
> + "^(sensors|power-domains)(-[0-9a-f]+)?$":
AFAICT, we only ever have 1 sensor and 1 power-domains node, so we don't
need the numbering.
Also, these should each be their own entry rather that having the
if/then schema mess below. You need an 'additionalProperties: false' in
here too.
> + type: object
> + description: |
> + Each sub-node represents one of the controller - power domains or sensors.
> +
> + properties:
> + compatible:
> + oneOf:
> + - const: arm,scpi-sensors
> + - const: arm,scpi-power-domains
> +
> + "^clocks(-[0-9a-f]+)?$":
> + type: object
> + description: |
> + "arm,scpi-clocks" - This is the container node. Each sub-node
> + represents one of the types of clock controller - indexed or full range.
> +
> + "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.
> +
> + properties:
> + compatible:
> + oneOf:
> + - const: arm,scpi-clocks
> + - const: arm,scpi-dvfs-clocks
> + - const: arm,scpi-variable-clocks
This doesn't make sense. The first one is the parent node and the last 2
are child nodes under it. The child nodes need to be defined in yet
another level.
> +
> +required:
> + - compatible
> + - mboxes
> + - shmem
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: arm,scpi-sensors
> + then:
> + properties:
> + '#thermal-sensor-cells':
> + const: 1
> +
> + required:
> + - '#thermal-sensor-cells'
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: arm,scpi-power-domains
> + then:
> + properties:
> + '#power-domain-cells':
> + const: 1
> +
> + num-domains:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + Total number of power domains provided by SCPI. This is needed as
> + the SCPI message protocol lacks a mechanism to query this
> + information at runtime.
> +
> + required:
> + - '#power-domain-cells'
> + - num-domains
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - arm,scpi-dvfs-clocks
> + - arm,scpi-variable-clocks
This would never be true unless you removed the container 'clocks' node.
> + then:
> + properties:
> + '#clock-cells':
> + const: 1
> + clock-output-names:
> + $ref: /schemas/types.yaml#/definitions/string-array
> + clock-indices:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + 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.
> +
> + required:
> + - '#clock-cells'
> + - clock-output-names
> + - clock-indices
> +
> +examples:
> + - |
> + firmware {
> + scpi {
> + compatible = "arm,scpi";
> + mboxes = <&mhuA 1>;
> + shmem = <&cpu_scp_hpri>; /* HP-NonSecure */
> +
> + scpi_devpd: power-domains-0 {
> + compatible = "arm,scpi-power-domains";
> + num-domains = <2>;
> + #power-domain-cells = <1>;
> + };
> +
> + clocks {
> + compatible = "arm,scpi-clocks";
> +
> + scpi_dvfs: clocks-0 {
> + compatible = "arm,scpi-dvfs-clocks";
> + #clock-cells = <1>;
> + clock-indices = <0>, <1>, <2>;
> + clock-output-names = "atlclk", "aplclk","gpuclk";
> + };
> +
> + scpi_clk: clocks-1 {
> + compatible = "arm,scpi-variable-clocks";
> + #clock-cells = <1>;
> + clock-indices = <3>, <4>;
> + clock-output-names = "pxlclk0", "pxlclk1";
> + };
> + };
> +
> + scpi_sensors: sensors-0 {
> + compatible = "arm,scpi-sensors";
> + #thermal-sensor-cells = <1>;
> + };
> +
> + };
> + };
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + 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-sram-section@0 {
> + compatible = "arm,scp-shmem";
> + reg = <0x0 0x200>;
> + };
> +
> + cpu_scp_hpri: scp-sram-section@200 {
> + compatible = "arm,scp-shmem";
> + reg = <0x200 0x200>;
> + };
> + };
> +
> + mhuA: mailbox@2b2f0000 {
> + #mbox-cells = <1>;
> + compatible = "arm,mhu", "arm,primecell";
> + reg = <0 0x2b2f0000 0 0x1000>;
> + interrupts = <0 36 4>, /* LP-NonSecure */
> + <0 35 4>, /* HP-NonSecure */
> + <0 37 4>; /* Secure */
> + clocks = <&clock 0 2 1>;
> + clock-names = "apb_pclk";
> + };
> +
> + gpu@ffe40000 {
> + compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
> + reg = <0x0 0xffe40000 0x0 0x10000>;
> + interrupts = <0 160 4>, <0 161 4>, <0 162 4>;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = <&scpi_clk 1>;
> + power-domains = <&scpi_devpd 8>;
> + resets = <&scpi_reset 0>, <&scpi_reset 1>;
> + };
> +
> + display@20930000 {
> + compatible = "intel,keembay-display";
> + reg = <0x0 0x20930000 0x0 0x3000>;
> + reg-names = "lcd";
> + interrupts = <0 33 4>;
> + clocks = <&scpi_clk 0x83>,
> + <&scpi_clk 0x0>;
> + clock-names = "clk_lcd", "clk_pll0";
> +
> + port {
> + disp_out: endpoint {
> + remote-endpoint = <&dsi_in>;
> + };
> + };
> + };
> +
> + thermal-zones {
> + soc-thermal {
> + polling-delay-passive = <100>;
> + polling-delay = <1000>;
> + thermal-sensors = <&scpi_sensors0 3>;
> +
> + trips {
> + mpu0_crit: mpu0_crit {
> + temperature = <125000>; /* milliCelsius */
> + hysteresis = <2000>; /* milliCelsius */
> + type = "critical";
> + };
> + };
> + };
> + };
> + };
> +
> + cpus {
> + #size-cells = <0>;
> + #address-cells = <2>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x0>;
> + enable-method = "psci";
> + clocks = <&scpi_dvfs 0>;
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bd7aff0c120f..6a12597a86e1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17696,7 +17696,7 @@ M: Sudeep Holla <sudeep.holla@arm.com>
> R: Cristian Marussi <cristian.marussi@arm.com>
> L: linux-arm-kernel@lists.infradead.org
> S: Maintained
> -F: Documentation/devicetree/bindings/arm/arm,sc[mp]i.txt
> +F: Documentation/devicetree/bindings/firmware/arm,sc[mp]i.yaml
> F: drivers/clk/clk-sc[mp]i.c
> F: drivers/cpufreq/sc[mp]i-cpufreq.c
> F: drivers/firmware/arm_scmi/
> --
> 2.25.1
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v2 6/8] dt-bindings: firmware: arm,scpi: Convert to json schema
@ 2021-06-02 15:58 ` Rob Herring
0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 15:58 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, linux-arm-kernel, Cristian Marussi, Kevin Hilman,
Neil Armstrong, Jerome Brunet
On Tue, Jun 01, 2021 at 11:49:02PM +0100, Sudeep Holla wrote:
> Convert the old text format binding for System Control and Power Interface
> (SCPI) Message Protocol into the new and shiny YAML format.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Kevin Hilman <khilman@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Cc: Viresh Kumar <viresh.kumar@linaro.org
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/arm,scpi.txt | 204 -------------
> .../bindings/firmware/arm,scpi.yaml | 285 ++++++++++++++++++
> MAINTAINERS | 2 +-
> 3 files changed, 286 insertions(+), 205 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt
> create mode 100644 Documentation/devicetree/bindings/firmware/arm,scpi.yaml
[...]
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
> new file mode 100644
> index 000000000000..b44a5a7040fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
> @@ -0,0 +1,285 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2021 ARM Ltd.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: System Control and Power Interface (SCPI) Message Protocol bindings
> +
> +maintainers:
> + - Sudeep Holla <sudeep.holla@arm.com>
> +
> +description: |
> + 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.
> +
> + This binding is intended to define the interface the firmware implementing
> + the SCPI provide for OSPM in the device tree.
> +
> + [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
> +
> +properties:
> + $nodename:
> + const: scpi
> +
> + compatible:
> + description: |
> + SCPI compliant firmware complying to SCPI v1.0 and above OR
> + SCPI compliant firmware complying to all unversioned releases
> + prior to SCPI v1.0
> + oneOf:
> + - const: arm,scpi # SCPI v1.0 and above
> + - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0
> +
> + mboxes:
> + description: |
> + 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.
> + minItems: 1
> +
> + shmem:
> + description: |
> + 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.
> + minItems: 1
> +
> +additionalProperties:
> + type: object
> +
> +patternProperties:
> + "^(sensors|power-domains)(-[0-9a-f]+)?$":
AFAICT, we only ever have 1 sensor and 1 power-domains node, so we don't
need the numbering.
Also, these should each be their own entry rather that having the
if/then schema mess below. You need an 'additionalProperties: false' in
here too.
> + type: object
> + description: |
> + Each sub-node represents one of the controller - power domains or sensors.
> +
> + properties:
> + compatible:
> + oneOf:
> + - const: arm,scpi-sensors
> + - const: arm,scpi-power-domains
> +
> + "^clocks(-[0-9a-f]+)?$":
> + type: object
> + description: |
> + "arm,scpi-clocks" - This is the container node. Each sub-node
> + represents one of the types of clock controller - indexed or full range.
> +
> + "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.
> +
> + properties:
> + compatible:
> + oneOf:
> + - const: arm,scpi-clocks
> + - const: arm,scpi-dvfs-clocks
> + - const: arm,scpi-variable-clocks
This doesn't make sense. The first one is the parent node and the last 2
are child nodes under it. The child nodes need to be defined in yet
another level.
> +
> +required:
> + - compatible
> + - mboxes
> + - shmem
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: arm,scpi-sensors
> + then:
> + properties:
> + '#thermal-sensor-cells':
> + const: 1
> +
> + required:
> + - '#thermal-sensor-cells'
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: arm,scpi-power-domains
> + then:
> + properties:
> + '#power-domain-cells':
> + const: 1
> +
> + num-domains:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + Total number of power domains provided by SCPI. This is needed as
> + the SCPI message protocol lacks a mechanism to query this
> + information at runtime.
> +
> + required:
> + - '#power-domain-cells'
> + - num-domains
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - arm,scpi-dvfs-clocks
> + - arm,scpi-variable-clocks
This would never be true unless you removed the container 'clocks' node.
> + then:
> + properties:
> + '#clock-cells':
> + const: 1
> + clock-output-names:
> + $ref: /schemas/types.yaml#/definitions/string-array
> + clock-indices:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + 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.
> +
> + required:
> + - '#clock-cells'
> + - clock-output-names
> + - clock-indices
> +
> +examples:
> + - |
> + firmware {
> + scpi {
> + compatible = "arm,scpi";
> + mboxes = <&mhuA 1>;
> + shmem = <&cpu_scp_hpri>; /* HP-NonSecure */
> +
> + scpi_devpd: power-domains-0 {
> + compatible = "arm,scpi-power-domains";
> + num-domains = <2>;
> + #power-domain-cells = <1>;
> + };
> +
> + clocks {
> + compatible = "arm,scpi-clocks";
> +
> + scpi_dvfs: clocks-0 {
> + compatible = "arm,scpi-dvfs-clocks";
> + #clock-cells = <1>;
> + clock-indices = <0>, <1>, <2>;
> + clock-output-names = "atlclk", "aplclk","gpuclk";
> + };
> +
> + scpi_clk: clocks-1 {
> + compatible = "arm,scpi-variable-clocks";
> + #clock-cells = <1>;
> + clock-indices = <3>, <4>;
> + clock-output-names = "pxlclk0", "pxlclk1";
> + };
> + };
> +
> + scpi_sensors: sensors-0 {
> + compatible = "arm,scpi-sensors";
> + #thermal-sensor-cells = <1>;
> + };
> +
> + };
> + };
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + 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-sram-section@0 {
> + compatible = "arm,scp-shmem";
> + reg = <0x0 0x200>;
> + };
> +
> + cpu_scp_hpri: scp-sram-section@200 {
> + compatible = "arm,scp-shmem";
> + reg = <0x200 0x200>;
> + };
> + };
> +
> + mhuA: mailbox@2b2f0000 {
> + #mbox-cells = <1>;
> + compatible = "arm,mhu", "arm,primecell";
> + reg = <0 0x2b2f0000 0 0x1000>;
> + interrupts = <0 36 4>, /* LP-NonSecure */
> + <0 35 4>, /* HP-NonSecure */
> + <0 37 4>; /* Secure */
> + clocks = <&clock 0 2 1>;
> + clock-names = "apb_pclk";
> + };
> +
> + gpu@ffe40000 {
> + compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
> + reg = <0x0 0xffe40000 0x0 0x10000>;
> + interrupts = <0 160 4>, <0 161 4>, <0 162 4>;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = <&scpi_clk 1>;
> + power-domains = <&scpi_devpd 8>;
> + resets = <&scpi_reset 0>, <&scpi_reset 1>;
> + };
> +
> + display@20930000 {
> + compatible = "intel,keembay-display";
> + reg = <0x0 0x20930000 0x0 0x3000>;
> + reg-names = "lcd";
> + interrupts = <0 33 4>;
> + clocks = <&scpi_clk 0x83>,
> + <&scpi_clk 0x0>;
> + clock-names = "clk_lcd", "clk_pll0";
> +
> + port {
> + disp_out: endpoint {
> + remote-endpoint = <&dsi_in>;
> + };
> + };
> + };
> +
> + thermal-zones {
> + soc-thermal {
> + polling-delay-passive = <100>;
> + polling-delay = <1000>;
> + thermal-sensors = <&scpi_sensors0 3>;
> +
> + trips {
> + mpu0_crit: mpu0_crit {
> + temperature = <125000>; /* milliCelsius */
> + hysteresis = <2000>; /* milliCelsius */
> + type = "critical";
> + };
> + };
> + };
> + };
> + };
> +
> + cpus {
> + #size-cells = <0>;
> + #address-cells = <2>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x0>;
> + enable-method = "psci";
> + clocks = <&scpi_dvfs 0>;
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bd7aff0c120f..6a12597a86e1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17696,7 +17696,7 @@ M: Sudeep Holla <sudeep.holla@arm.com>
> R: Cristian Marussi <cristian.marussi@arm.com>
> L: linux-arm-kernel@lists.infradead.org
> S: Maintained
> -F: Documentation/devicetree/bindings/arm/arm,sc[mp]i.txt
> +F: Documentation/devicetree/bindings/firmware/arm,sc[mp]i.yaml
> F: drivers/clk/clk-sc[mp]i.c
> F: drivers/cpufreq/sc[mp]i-cpufreq.c
> F: drivers/firmware/arm_scmi/
> --
> 2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v2 6/8] dt-bindings: firmware: arm,scpi: Convert to json schema
2021-06-02 15:58 ` Rob Herring
@ 2021-06-02 16:05 ` Sudeep Holla
-1 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-02 16:05 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-arm-kernel, Cristian Marussi, Kevin Hilman,
Neil Armstrong, Sudeep Holla, Jerome Brunet
On Wed, Jun 02, 2021 at 10:58:00AM -0500, Rob Herring wrote:
> On Tue, Jun 01, 2021 at 11:49:02PM +0100, Sudeep Holla wrote:
> > Convert the old text format binding for System Control and Power Interface
> > (SCPI) Message Protocol into the new and shiny YAML format.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Kevin Hilman <khilman@baylibre.com>
> > Cc: Neil Armstrong <narmstrong@baylibre.com>
> > Cc: Jerome Brunet <jbrunet@baylibre.com>
> > Cc: Viresh Kumar <viresh.kumar@linaro.org
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> > .../devicetree/bindings/arm/arm,scpi.txt | 204 -------------
> > .../bindings/firmware/arm,scpi.yaml | 285 ++++++++++++++++++
> > MAINTAINERS | 2 +-
> > 3 files changed, 286 insertions(+), 205 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt
> > create mode 100644 Documentation/devicetree/bindings/firmware/arm,scpi.yaml
>
> [...]
>
> > diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
> > new file mode 100644
> > index 000000000000..b44a5a7040fc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
> > @@ -0,0 +1,285 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright 2021 ARM Ltd.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: System Control and Power Interface (SCPI) Message Protocol bindings
> > +
> > +maintainers:
> > + - Sudeep Holla <sudeep.holla@arm.com>
> > +
> > +description: |
> > + 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.
> > +
> > + This binding is intended to define the interface the firmware implementing
> > + the SCPI provide for OSPM in the device tree.
> > +
> > + [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
> > +
> > +properties:
> > + $nodename:
> > + const: scpi
> > +
> > + compatible:
> > + description: |
> > + SCPI compliant firmware complying to SCPI v1.0 and above OR
> > + SCPI compliant firmware complying to all unversioned releases
> > + prior to SCPI v1.0
> > + oneOf:
> > + - const: arm,scpi # SCPI v1.0 and above
> > + - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0
> > +
> > + mboxes:
> > + description: |
> > + 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.
> > + minItems: 1
> > +
> > + shmem:
> > + description: |
> > + 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.
> > + minItems: 1
> > +
> > +additionalProperties:
> > + type: object
> > +
> > +patternProperties:
> > + "^(sensors|power-domains)(-[0-9a-f]+)?$":
>
> AFAICT, we only ever have 1 sensor and 1 power-domains node, so we don't
> need the numbering.
>
Right, I initially had clock too there and didn't notice the above 2 doesn't
need the numbering, will drop it.
> Also, these should each be their own entry rather that having the
> if/then schema mess below. You need an 'additionalProperties: false' in
> here too.
>
OK that sounds cleaner.
> > + type: object
> > + description: |
> > + Each sub-node represents one of the controller - power domains or sensors.
> > +
> > + properties:
> > + compatible:
> > + oneOf:
> > + - const: arm,scpi-sensors
> > + - const: arm,scpi-power-domains
> > +
> > + "^clocks(-[0-9a-f]+)?$":
> > + type: object
> > + description: |
> > + "arm,scpi-clocks" - This is the container node. Each sub-node
> > + represents one of the types of clock controller - indexed or full range.
> > +
> > + "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.
> > +
> > + properties:
> > + compatible:
> > + oneOf:
> > + - const: arm,scpi-clocks
> > + - const: arm,scpi-dvfs-clocks
> > + - const: arm,scpi-variable-clocks
>
> This doesn't make sense. The first one is the parent node and the last 2
> are child nodes under it. The child nodes need to be defined in yet
> another level.
>
Agreed, I did that for SCMI regulators, will follow that here too.
> > +
> > +required:
> > + - compatible
> > + - mboxes
> > + - shmem
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: arm,scpi-sensors
> > + then:
> > + properties:
> > + '#thermal-sensor-cells':
> > + const: 1
> > +
> > + required:
> > + - '#thermal-sensor-cells'
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: arm,scpi-power-domains
> > + then:
> > + properties:
> > + '#power-domain-cells':
> > + const: 1
> > +
> > + num-domains:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: |
> > + Total number of power domains provided by SCPI. This is needed as
> > + the SCPI message protocol lacks a mechanism to query this
> > + information at runtime.
> > +
> > + required:
> > + - '#power-domain-cells'
> > + - num-domains
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - arm,scpi-dvfs-clocks
> > + - arm,scpi-variable-clocks
>
> This would never be true unless you removed the container 'clocks' node.
>
Understood. I should have tested removing properties in the example like
I did for SCMI. I must have show less interest for SCPI as it is old and
almost deprecated 😁. I will fix it.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v2 6/8] dt-bindings: firmware: arm,scpi: Convert to json schema
@ 2021-06-02 16:05 ` Sudeep Holla
0 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-02 16:05 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-arm-kernel, Cristian Marussi, Kevin Hilman,
Neil Armstrong, Sudeep Holla, Jerome Brunet
On Wed, Jun 02, 2021 at 10:58:00AM -0500, Rob Herring wrote:
> On Tue, Jun 01, 2021 at 11:49:02PM +0100, Sudeep Holla wrote:
> > Convert the old text format binding for System Control and Power Interface
> > (SCPI) Message Protocol into the new and shiny YAML format.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Kevin Hilman <khilman@baylibre.com>
> > Cc: Neil Armstrong <narmstrong@baylibre.com>
> > Cc: Jerome Brunet <jbrunet@baylibre.com>
> > Cc: Viresh Kumar <viresh.kumar@linaro.org
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> > .../devicetree/bindings/arm/arm,scpi.txt | 204 -------------
> > .../bindings/firmware/arm,scpi.yaml | 285 ++++++++++++++++++
> > MAINTAINERS | 2 +-
> > 3 files changed, 286 insertions(+), 205 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt
> > create mode 100644 Documentation/devicetree/bindings/firmware/arm,scpi.yaml
>
> [...]
>
> > diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
> > new file mode 100644
> > index 000000000000..b44a5a7040fc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
> > @@ -0,0 +1,285 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright 2021 ARM Ltd.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: System Control and Power Interface (SCPI) Message Protocol bindings
> > +
> > +maintainers:
> > + - Sudeep Holla <sudeep.holla@arm.com>
> > +
> > +description: |
> > + 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.
> > +
> > + This binding is intended to define the interface the firmware implementing
> > + the SCPI provide for OSPM in the device tree.
> > +
> > + [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
> > +
> > +properties:
> > + $nodename:
> > + const: scpi
> > +
> > + compatible:
> > + description: |
> > + SCPI compliant firmware complying to SCPI v1.0 and above OR
> > + SCPI compliant firmware complying to all unversioned releases
> > + prior to SCPI v1.0
> > + oneOf:
> > + - const: arm,scpi # SCPI v1.0 and above
> > + - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0
> > +
> > + mboxes:
> > + description: |
> > + 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.
> > + minItems: 1
> > +
> > + shmem:
> > + description: |
> > + 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.
> > + minItems: 1
> > +
> > +additionalProperties:
> > + type: object
> > +
> > +patternProperties:
> > + "^(sensors|power-domains)(-[0-9a-f]+)?$":
>
> AFAICT, we only ever have 1 sensor and 1 power-domains node, so we don't
> need the numbering.
>
Right, I initially had clock too there and didn't notice the above 2 doesn't
need the numbering, will drop it.
> Also, these should each be their own entry rather that having the
> if/then schema mess below. You need an 'additionalProperties: false' in
> here too.
>
OK that sounds cleaner.
> > + type: object
> > + description: |
> > + Each sub-node represents one of the controller - power domains or sensors.
> > +
> > + properties:
> > + compatible:
> > + oneOf:
> > + - const: arm,scpi-sensors
> > + - const: arm,scpi-power-domains
> > +
> > + "^clocks(-[0-9a-f]+)?$":
> > + type: object
> > + description: |
> > + "arm,scpi-clocks" - This is the container node. Each sub-node
> > + represents one of the types of clock controller - indexed or full range.
> > +
> > + "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.
> > +
> > + properties:
> > + compatible:
> > + oneOf:
> > + - const: arm,scpi-clocks
> > + - const: arm,scpi-dvfs-clocks
> > + - const: arm,scpi-variable-clocks
>
> This doesn't make sense. The first one is the parent node and the last 2
> are child nodes under it. The child nodes need to be defined in yet
> another level.
>
Agreed, I did that for SCMI regulators, will follow that here too.
> > +
> > +required:
> > + - compatible
> > + - mboxes
> > + - shmem
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: arm,scpi-sensors
> > + then:
> > + properties:
> > + '#thermal-sensor-cells':
> > + const: 1
> > +
> > + required:
> > + - '#thermal-sensor-cells'
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: arm,scpi-power-domains
> > + then:
> > + properties:
> > + '#power-domain-cells':
> > + const: 1
> > +
> > + num-domains:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: |
> > + Total number of power domains provided by SCPI. This is needed as
> > + the SCPI message protocol lacks a mechanism to query this
> > + information at runtime.
> > +
> > + required:
> > + - '#power-domain-cells'
> > + - num-domains
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - arm,scpi-dvfs-clocks
> > + - arm,scpi-variable-clocks
>
> This would never be true unless you removed the container 'clocks' node.
>
Understood. I should have tested removing properties in the example like
I did for SCMI. I must have show less interest for SCPI as it is old and
almost deprecated 😁. I will fix it.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH v2 7/8] dt-bindings: firmware: amlogic,scpi: Convert to json schema
2021-06-01 22:48 ` Sudeep Holla
@ 2021-06-01 22:49 ` Sudeep Holla
-1 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:49 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Kevin Hilman, Neil Armstrong, Jerome Brunet
Convert/merge the existing text format SCPI binding additions for
amlogic,scpi into the common arm,scpi json scheme.
Couple of things to note:
"amlogic,meson-gxbb-scpi" is always used with "arm,scpi-pre-1.0" and
"amlogic,meson-gxbb-scpi-sensors" is used always with "arm,scpi-sensors"
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/amlogic,scpi.txt | 15 ---------
.../bindings/firmware/arm,scpi.yaml | 32 +++++++++++++++++++
2 files changed, 32 insertions(+), 15 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
deleted file mode 100644
index ebfe302fb747..000000000000
--- a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-System Control and Power Interface (SCPI) Message Protocol
-(in addition to the standard binding in [0])
-----------------------------------------------------------
-Required properties
-
-- compatible : should be "amlogic,meson-gxbb-scpi"
-
-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 "amlogic,meson-gxbb-scpi-sensors".
-
-[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
index b44a5a7040fc..59eea4e0fbed 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
@@ -32,6 +32,10 @@ description: |
oneOf:
- const: arm,scpi # SCPI v1.0 and above
- const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0
+ - items:
+ - enum:
+ - amlogic,meson-gxbb-scpi
+ - const: arm,scpi-pre-1.0
mboxes:
description: |
@@ -62,6 +66,10 @@ description: |
oneOf:
- const: arm,scpi-sensors
- const: arm,scpi-power-domains
+ - items:
+ - enum:
+ - amlogic,meson-gxbb-scpi-sensors
+ - const: arm,scpi-sensors
"^clocks(-[0-9a-f]+)?$":
type: object
@@ -282,4 +290,28 @@ description: |
};
};
+ - |
+ firmware {
+ scpi {
+ compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0";
+ mboxes = <&mailbox 1 &mailbox 2>;
+ shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+
+ clocks {
+ compatible = "arm,scpi-clocks";
+
+ scpi_dvfs1: clocks-0 {
+ compatible = "arm,scpi-dvfs-clocks";
+ #clock-cells = <1>;
+ clock-indices = <0>;
+ clock-output-names = "vcpu";
+ };
+ };
+
+ scpi_sensors1: sensors {
+ compatible = "amlogic,meson-gxbb-scpi-sensors", "arm,scpi-sensors";
+ #thermal-sensor-cells = <1>;
+ };
+ };
+ };
...
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH v2 7/8] dt-bindings: firmware: amlogic, scpi: Convert to json schema
@ 2021-06-01 22:49 ` Sudeep Holla
0 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:49 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Kevin Hilman, Neil Armstrong, Jerome Brunet
Convert/merge the existing text format SCPI binding additions for
amlogic,scpi into the common arm,scpi json scheme.
Couple of things to note:
"amlogic,meson-gxbb-scpi" is always used with "arm,scpi-pre-1.0" and
"amlogic,meson-gxbb-scpi-sensors" is used always with "arm,scpi-sensors"
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/amlogic,scpi.txt | 15 ---------
.../bindings/firmware/arm,scpi.yaml | 32 +++++++++++++++++++
2 files changed, 32 insertions(+), 15 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
deleted file mode 100644
index ebfe302fb747..000000000000
--- a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-System Control and Power Interface (SCPI) Message Protocol
-(in addition to the standard binding in [0])
-----------------------------------------------------------
-Required properties
-
-- compatible : should be "amlogic,meson-gxbb-scpi"
-
-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 "amlogic,meson-gxbb-scpi-sensors".
-
-[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
index b44a5a7040fc..59eea4e0fbed 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml
@@ -32,6 +32,10 @@ description: |
oneOf:
- const: arm,scpi # SCPI v1.0 and above
- const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0
+ - items:
+ - enum:
+ - amlogic,meson-gxbb-scpi
+ - const: arm,scpi-pre-1.0
mboxes:
description: |
@@ -62,6 +66,10 @@ description: |
oneOf:
- const: arm,scpi-sensors
- const: arm,scpi-power-domains
+ - items:
+ - enum:
+ - amlogic,meson-gxbb-scpi-sensors
+ - const: arm,scpi-sensors
"^clocks(-[0-9a-f]+)?$":
type: object
@@ -282,4 +290,28 @@ description: |
};
};
+ - |
+ firmware {
+ scpi {
+ compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0";
+ mboxes = <&mailbox 1 &mailbox 2>;
+ shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+
+ clocks {
+ compatible = "arm,scpi-clocks";
+
+ scpi_dvfs1: clocks-0 {
+ compatible = "arm,scpi-dvfs-clocks";
+ #clock-cells = <1>;
+ clock-indices = <0>;
+ clock-output-names = "vcpu";
+ };
+ };
+
+ scpi_sensors1: sensors {
+ compatible = "amlogic,meson-gxbb-scpi-sensors", "arm,scpi-sensors";
+ #thermal-sensor-cells = <1>;
+ };
+ };
+ };
...
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH v2 8/8] dt-bindings: firmware: arm,scmi: Convert to json schema
2021-06-01 22:48 ` Sudeep Holla
@ 2021-06-01 22:49 ` Sudeep Holla
-1 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:49 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Florian Fainelli, Jim Quinlan, Etienne Carriere, Peter Hilber
Convert the old text format binding for System Control and Management Interface
(SCMI) Message Protocol into the new and shiny YAML format.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Jim Quinlan <jim2101024@gmail.com>
Cc: Etienne Carriere <etienne.carriere@linaro.org>
Cc: Peter Hilber <peter.hilber@opensynergy.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/arm,scmi.txt | 224 ---------
.../bindings/firmware/arm,scmi.yaml | 474 ++++++++++++++++++
2 files changed, 474 insertions(+), 224 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt
create mode 100644 Documentation/devicetree/bindings/firmware/arm,scmi.yaml
diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
deleted file mode 100644
index b7be2000afcb..000000000000
--- a/Documentation/devicetree/bindings/arm/arm,scmi.txt
+++ /dev/null
@@ -1,224 +0,0 @@
-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 DEN 0056A ("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" or "arm,scmi-smc" for smc/hvc transports
-- 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.
-- arm,smc-id : SMC id required when using smc or hvc transports
-
-Optional properties:
-
-- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
-
-- interrupts : when using smc or hvc transports, this optional
- property indicates that msg completion by the platform is indicated
- by an interrupt rather than by the return of the smc call. This
- should not be used except when the platform requires such behavior.
-
-- interrupt-names : if "interrupts" is present, interrupt-names must also
- be present and have the value "a2p".
-
-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.
-
-Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
-------------------------------------------------------------
-An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
-and should be always positioned as a root regulator.
-It does not support any current operation.
-
-SCMI Regulators are grouped under a 'regulators' node which in turn is a child
-of the SCMI Voltage protocol node inside the desired SCMI instance node.
-
-This binding uses the common regulator binding[6].
-
-Required properties:
- - reg : shall identify an existent SCMI Voltage Domain.
-
-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.
-
-Reset signal bindings for the reset domains based on SCMI Message Protocol
-------------------------------------------------------------
-
-This binding for the SCMI reset domain providers uses the generic reset
-signal binding[5].
-
-Required properties:
- - #reset-cells : Should be 1. Contains the reset domain ID value used
- by SCMI commands.
-
-[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.yaml
-[3] Documentation/devicetree/bindings/thermal/thermal*.yaml
-[4] Documentation/devicetree/bindings/sram/sram.yaml
-[5] Documentation/devicetree/bindings/reset/reset.txt
-[6] Documentation/devicetree/bindings/regulator/regulator.yaml
-
-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>;
- };
-
- scmi_reset: protocol@16 {
- reg = <0x16>;
- #reset-cells = <1>;
- };
-
- scmi_voltage: protocol@17 {
- reg = <0x17>;
-
- regulators {
- regulator_devX: regulator@0 {
- reg = <0x0>;
- regulator-max-microvolt = <3300000>;
- };
-
- regulator_devY: regulator@9 {
- reg = <0x9>;
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <4200000>;
- };
-
- ...
- };
- };
- };
-};
-
-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>;
- resets = <&scmi_reset 10>;
-};
-
-thermal-zones {
- soc_thermal {
- polling-delay-passive = <100>;
- polling-delay = <1000>;
- /* sensor ID */
- thermal-sensors = <&scmi_sensors0 3>;
- ...
- };
-};
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
new file mode 100644
index 000000000000..0f5608d7e950
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -0,0 +1,474 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2021 ARM Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/arm,scmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: System Control and Management Interface (SCMI) Message Protocol bindings
+
+maintainers:
+ - Sudeep Holla <sudeep.holla@arm.com>
+
+description: |
+ 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 DEN 0056 ("ARM System Control
+ and Management Interface Platform Design Document")[0] provide for OSPM in
+ the device tree.
+
+ [0] https://developer.arm.com/documentation/den0056/latest
+
+properties:
+ $nodename:
+ const: scmi
+
+ compatible:
+ oneOf:
+ - description: SCMI compliant firmware with mailbox transport
+ items:
+ - const: arm,scmi
+ - description: SCMI compliant firmware with ARM SMC/HVC transport
+ items:
+ - const: arm,scmi-smc
+
+ mbox-names:
+ description: |
+ Specifies the mailboxes used to communicate with SCMI compliant
+ firmware.
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ description: |
+ 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.
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ description: |
+ List of phandle pointing to the shared memory(SHM) area, for each
+ transport channel specified.
+ minItems: 1
+ maxItems: 2
+
+ '#address-cells':
+ description: |
+ The address cells map to the protocol identifier for a given sub-node.
+ const: 1
+
+ '#size-cells':
+ description: |
+ The size cells are not present as 'reg' property doesn't have any
+ size associated with it.
+ const: 0
+
+ arm,smc-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ SMC id required when using smc or hvc transports
+
+additionalProperties:
+ type: object
+
+patternProperties:
+ '^protocol@[0-9a-f]+$':
+ type: object
+ description: |
+ Each sub-node represents a protocol supported. If the platform
+ supports a dedicated communication channel for a particular protocol,
+ then the corresponding transport properties must be present.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ required:
+ - reg
+
+ '^protocol@11$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ '#power-domain-cells':
+ $ref: "/schemas/power/power-domain.yaml#"
+ const: 1
+
+ required:
+ - reg
+ - '#power-domain-cells'
+
+ '^protocol@13$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+ required:
+ - reg
+ - '#clock-cells'
+
+ '^protocol@14$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+ required:
+ - reg
+ - '#clock-cells'
+
+ '^protocol@15$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ '#thermal-sensor-cells':
+ $ref: "/schemas/thermal/thermal-sensor.yaml#"
+ const: 1
+
+ required:
+ - reg
+ - '#thermal-sensor-cells'
+
+ '^protocol@16$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ '#reset-cells':
+ const: 1
+
+ required:
+ - reg
+ - '#reset-cells'
+
+ '^protocol@17$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ regulators:
+ type: object
+ description: |
+ The list of all regulators provided by this SCMI controller.
+ patternProperties:
+ '^regulators@[0-9a-f]+$':
+ type: object
+ $ref: "../regulator/regulator.yaml#"
+ properties:
+ reg:
+ maxItems: 1
+ description: Identifier for the voltage regulator.
+ required:
+ - reg
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - shmem
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: arm,scmi
+ then:
+ required:
+ - mboxes
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: arm,scmi-smc
+ then:
+ properties:
+ interrupts:
+ description: |
+ The interrupt that indicates message completion by the platform
+ rather than by the return of the smc call. This should not be used
+ except when the platform requires such behavior.
+
+ interrupt-names:
+ const: a2p
+
+ required:
+ - arm,smc-id
+
+examples:
+ - |
+ firmware {
+ scmi {
+ compatible = "arm,scmi";
+ mboxes = <&mhuB 0 0>,
+ <&mhuB 0 1>;
+ mbox-names = "tx", "rx";
+ shmem = <&cpu_scp_lpri0 &cpu_scp_lpri1>;
+
+ #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>;
+
+ mboxes = <&mhuB 1 0>,
+ <&mhuB 1 1>;
+ mbox-names = "tx", "rx";
+ shmem = <&cpu_scp_hpri0 &cpu_scp_hpri1>;
+ };
+
+ scmi_clk: protocol@14 {
+ reg = <0x14>;
+ #clock-cells = <1>;
+ };
+
+ scmi_sensors: protocol@15 {
+ reg = <0x15>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ scmi_reset: protocol@16 {
+ reg = <0x16>;
+ #reset-cells = <1>;
+ };
+
+ scmi_voltage: protocol@17 {
+ reg = <0x17>;
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator_devX: regulator@0 {
+ reg = <0x0>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ regulator_devY: regulator@9 {
+ reg = <0x9>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <4200000>;
+ };
+ };
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ sram@50000000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x50000000 0x0 0x10000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x50000000 0x10000>;
+
+ cpu_scp_lpri0: scp-sram-section@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x80>;
+ };
+
+ cpu_scp_lpri1: scp-sram-section@80 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x80 0x80>;
+ };
+
+ cpu_scp_hpri0: scp-sram-section@100 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x100 0x80>;
+ };
+
+ cpu_scp_hpri2: scp-sram-section@180 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x180 0x80>;
+ };
+ };
+
+ mhuB: mailbox@2b2f0000 {
+ #mbox-cells = <2>;
+ compatible = "arm,mhu-doorbell", "arm,primecell";
+ reg = <0 0x2b2f0000 0 0x1000>;
+ interrupts = <0 36 4>, /* LP-NonSecure */
+ <0 35 4>, /* HP-NonSecure */
+ <0 37 4>; /* Secure */
+ clocks = <&clock 0 2 1>;
+ clock-names = "apb_pclk";
+ };
+
+ gpu@ffe40000 {
+ compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
+ reg = <0x0 0xffe40000 0x0 0x10000>;
+ interrupts = <0 160 4>, <0 161 4>, <0 162 4>;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&scmi_clk 1>;
+ power-domains = <&scmi_devpd 8>;
+ resets = <&scmi_reset 0>, <&scmi_reset 1>;
+ };
+
+ display@20930000 {
+ compatible = "intel,keembay-display";
+ reg = <0x0 0x20930000 0x0 0x3000>;
+ reg-names = "lcd";
+ interrupts = <0 33 4>;
+ clocks = <&scmi_clk 0x83>,
+ <&scmi_clk 0x0>;
+ clock-names = "clk_lcd", "clk_pll0";
+
+ port {
+ disp_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ };
+ };
+ };
+
+ thermal-zones {
+ soc-thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <1000>;
+ thermal-sensors = <&scmi_sensors 3>;
+
+ trips {
+ mpu0_crit: mpu0_crit {
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = "critical";
+ };
+ };
+ };
+ };
+ };
+
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <2>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
+ };
+ };
+
+...
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* [PATCH v2 8/8] dt-bindings: firmware: arm, scmi: Convert to json schema
@ 2021-06-01 22:49 ` Sudeep Holla
0 siblings, 0 replies; 32+ messages in thread
From: Sudeep Holla @ 2021-06-01 22:49 UTC (permalink / raw)
To: devicetree
Cc: Sudeep Holla, linux-arm-kernel, Rob Herring, Cristian Marussi,
Florian Fainelli, Jim Quinlan, Etienne Carriere, Peter Hilber
Convert the old text format binding for System Control and Management Interface
(SCMI) Message Protocol into the new and shiny YAML format.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Jim Quinlan <jim2101024@gmail.com>
Cc: Etienne Carriere <etienne.carriere@linaro.org>
Cc: Peter Hilber <peter.hilber@opensynergy.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/arm,scmi.txt | 224 ---------
.../bindings/firmware/arm,scmi.yaml | 474 ++++++++++++++++++
2 files changed, 474 insertions(+), 224 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt
create mode 100644 Documentation/devicetree/bindings/firmware/arm,scmi.yaml
diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
deleted file mode 100644
index b7be2000afcb..000000000000
--- a/Documentation/devicetree/bindings/arm/arm,scmi.txt
+++ /dev/null
@@ -1,224 +0,0 @@
-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 DEN 0056A ("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" or "arm,scmi-smc" for smc/hvc transports
-- 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.
-- arm,smc-id : SMC id required when using smc or hvc transports
-
-Optional properties:
-
-- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
-
-- interrupts : when using smc or hvc transports, this optional
- property indicates that msg completion by the platform is indicated
- by an interrupt rather than by the return of the smc call. This
- should not be used except when the platform requires such behavior.
-
-- interrupt-names : if "interrupts" is present, interrupt-names must also
- be present and have the value "a2p".
-
-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.
-
-Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
-------------------------------------------------------------
-An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
-and should be always positioned as a root regulator.
-It does not support any current operation.
-
-SCMI Regulators are grouped under a 'regulators' node which in turn is a child
-of the SCMI Voltage protocol node inside the desired SCMI instance node.
-
-This binding uses the common regulator binding[6].
-
-Required properties:
- - reg : shall identify an existent SCMI Voltage Domain.
-
-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.
-
-Reset signal bindings for the reset domains based on SCMI Message Protocol
-------------------------------------------------------------
-
-This binding for the SCMI reset domain providers uses the generic reset
-signal binding[5].
-
-Required properties:
- - #reset-cells : Should be 1. Contains the reset domain ID value used
- by SCMI commands.
-
-[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.yaml
-[3] Documentation/devicetree/bindings/thermal/thermal*.yaml
-[4] Documentation/devicetree/bindings/sram/sram.yaml
-[5] Documentation/devicetree/bindings/reset/reset.txt
-[6] Documentation/devicetree/bindings/regulator/regulator.yaml
-
-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>;
- };
-
- scmi_reset: protocol@16 {
- reg = <0x16>;
- #reset-cells = <1>;
- };
-
- scmi_voltage: protocol@17 {
- reg = <0x17>;
-
- regulators {
- regulator_devX: regulator@0 {
- reg = <0x0>;
- regulator-max-microvolt = <3300000>;
- };
-
- regulator_devY: regulator@9 {
- reg = <0x9>;
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <4200000>;
- };
-
- ...
- };
- };
- };
-};
-
-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>;
- resets = <&scmi_reset 10>;
-};
-
-thermal-zones {
- soc_thermal {
- polling-delay-passive = <100>;
- polling-delay = <1000>;
- /* sensor ID */
- thermal-sensors = <&scmi_sensors0 3>;
- ...
- };
-};
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
new file mode 100644
index 000000000000..0f5608d7e950
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -0,0 +1,474 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2021 ARM Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/arm,scmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: System Control and Management Interface (SCMI) Message Protocol bindings
+
+maintainers:
+ - Sudeep Holla <sudeep.holla@arm.com>
+
+description: |
+ 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 DEN 0056 ("ARM System Control
+ and Management Interface Platform Design Document")[0] provide for OSPM in
+ the device tree.
+
+ [0] https://developer.arm.com/documentation/den0056/latest
+
+properties:
+ $nodename:
+ const: scmi
+
+ compatible:
+ oneOf:
+ - description: SCMI compliant firmware with mailbox transport
+ items:
+ - const: arm,scmi
+ - description: SCMI compliant firmware with ARM SMC/HVC transport
+ items:
+ - const: arm,scmi-smc
+
+ mbox-names:
+ description: |
+ Specifies the mailboxes used to communicate with SCMI compliant
+ firmware.
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ description: |
+ 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.
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ description: |
+ List of phandle pointing to the shared memory(SHM) area, for each
+ transport channel specified.
+ minItems: 1
+ maxItems: 2
+
+ '#address-cells':
+ description: |
+ The address cells map to the protocol identifier for a given sub-node.
+ const: 1
+
+ '#size-cells':
+ description: |
+ The size cells are not present as 'reg' property doesn't have any
+ size associated with it.
+ const: 0
+
+ arm,smc-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ SMC id required when using smc or hvc transports
+
+additionalProperties:
+ type: object
+
+patternProperties:
+ '^protocol@[0-9a-f]+$':
+ type: object
+ description: |
+ Each sub-node represents a protocol supported. If the platform
+ supports a dedicated communication channel for a particular protocol,
+ then the corresponding transport properties must be present.
+
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ required:
+ - reg
+
+ '^protocol@11$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ '#power-domain-cells':
+ $ref: "/schemas/power/power-domain.yaml#"
+ const: 1
+
+ required:
+ - reg
+ - '#power-domain-cells'
+
+ '^protocol@13$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+ required:
+ - reg
+ - '#clock-cells'
+
+ '^protocol@14$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ '#clock-cells':
+ const: 1
+
+ required:
+ - reg
+ - '#clock-cells'
+
+ '^protocol@15$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ '#thermal-sensor-cells':
+ $ref: "/schemas/thermal/thermal-sensor.yaml#"
+ const: 1
+
+ required:
+ - reg
+ - '#thermal-sensor-cells'
+
+ '^protocol@16$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ '#reset-cells':
+ const: 1
+
+ required:
+ - reg
+ - '#reset-cells'
+
+ '^protocol@17$':
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ minItems: 1
+ maxItems: 2
+
+ shmem:
+ minItems: 1
+ maxItems: 2
+
+ regulators:
+ type: object
+ description: |
+ The list of all regulators provided by this SCMI controller.
+ patternProperties:
+ '^regulators@[0-9a-f]+$':
+ type: object
+ $ref: "../regulator/regulator.yaml#"
+ properties:
+ reg:
+ maxItems: 1
+ description: Identifier for the voltage regulator.
+ required:
+ - reg
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - shmem
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: arm,scmi
+ then:
+ required:
+ - mboxes
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: arm,scmi-smc
+ then:
+ properties:
+ interrupts:
+ description: |
+ The interrupt that indicates message completion by the platform
+ rather than by the return of the smc call. This should not be used
+ except when the platform requires such behavior.
+
+ interrupt-names:
+ const: a2p
+
+ required:
+ - arm,smc-id
+
+examples:
+ - |
+ firmware {
+ scmi {
+ compatible = "arm,scmi";
+ mboxes = <&mhuB 0 0>,
+ <&mhuB 0 1>;
+ mbox-names = "tx", "rx";
+ shmem = <&cpu_scp_lpri0 &cpu_scp_lpri1>;
+
+ #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>;
+
+ mboxes = <&mhuB 1 0>,
+ <&mhuB 1 1>;
+ mbox-names = "tx", "rx";
+ shmem = <&cpu_scp_hpri0 &cpu_scp_hpri1>;
+ };
+
+ scmi_clk: protocol@14 {
+ reg = <0x14>;
+ #clock-cells = <1>;
+ };
+
+ scmi_sensors: protocol@15 {
+ reg = <0x15>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ scmi_reset: protocol@16 {
+ reg = <0x16>;
+ #reset-cells = <1>;
+ };
+
+ scmi_voltage: protocol@17 {
+ reg = <0x17>;
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator_devX: regulator@0 {
+ reg = <0x0>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ regulator_devY: regulator@9 {
+ reg = <0x9>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <4200000>;
+ };
+ };
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ sram@50000000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x50000000 0x0 0x10000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x50000000 0x10000>;
+
+ cpu_scp_lpri0: scp-sram-section@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x80>;
+ };
+
+ cpu_scp_lpri1: scp-sram-section@80 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x80 0x80>;
+ };
+
+ cpu_scp_hpri0: scp-sram-section@100 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x100 0x80>;
+ };
+
+ cpu_scp_hpri2: scp-sram-section@180 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x180 0x80>;
+ };
+ };
+
+ mhuB: mailbox@2b2f0000 {
+ #mbox-cells = <2>;
+ compatible = "arm,mhu-doorbell", "arm,primecell";
+ reg = <0 0x2b2f0000 0 0x1000>;
+ interrupts = <0 36 4>, /* LP-NonSecure */
+ <0 35 4>, /* HP-NonSecure */
+ <0 37 4>; /* Secure */
+ clocks = <&clock 0 2 1>;
+ clock-names = "apb_pclk";
+ };
+
+ gpu@ffe40000 {
+ compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
+ reg = <0x0 0xffe40000 0x0 0x10000>;
+ interrupts = <0 160 4>, <0 161 4>, <0 162 4>;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&scmi_clk 1>;
+ power-domains = <&scmi_devpd 8>;
+ resets = <&scmi_reset 0>, <&scmi_reset 1>;
+ };
+
+ display@20930000 {
+ compatible = "intel,keembay-display";
+ reg = <0x0 0x20930000 0x0 0x3000>;
+ reg-names = "lcd";
+ interrupts = <0 33 4>;
+ clocks = <&scmi_clk 0x83>,
+ <&scmi_clk 0x0>;
+ clock-names = "clk_lcd", "clk_pll0";
+
+ port {
+ disp_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ };
+ };
+ };
+
+ thermal-zones {
+ soc-thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <1000>;
+ thermal-sensors = <&scmi_sensors 3>;
+
+ trips {
+ mpu0_crit: mpu0_crit {
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = "critical";
+ };
+ };
+ };
+ };
+ };
+
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <2>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
+ };
+ };
+
+...
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH v2 8/8] dt-bindings: firmware: arm,scmi: Convert to json schema
2021-06-01 22:49 ` [PATCH v2 8/8] dt-bindings: firmware: arm, scmi: " Sudeep Holla
@ 2021-06-02 16:16 ` Rob Herring
-1 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 16:16 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, linux-arm-kernel, Cristian Marussi, Florian Fainelli,
Jim Quinlan, Etienne Carriere, Peter Hilber
On Tue, Jun 01, 2021 at 11:49:04PM +0100, Sudeep Holla wrote:
> Convert the old text format binding for System Control and Management Interface
> (SCMI) Message Protocol into the new and shiny YAML format.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Cristian Marussi <cristian.marussi@arm.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Jim Quinlan <jim2101024@gmail.com>
> Cc: Etienne Carriere <etienne.carriere@linaro.org>
> Cc: Peter Hilber <peter.hilber@opensynergy.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/arm,scmi.txt | 224 ---------
> .../bindings/firmware/arm,scmi.yaml | 474 ++++++++++++++++++
> 2 files changed, 474 insertions(+), 224 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt
> create mode 100644 Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
> deleted file mode 100644
> index b7be2000afcb..000000000000
> --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt
> +++ /dev/null
> @@ -1,224 +0,0 @@
> -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 DEN 0056A ("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" or "arm,scmi-smc" for smc/hvc transports
> -- 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.
> -- arm,smc-id : SMC id required when using smc or hvc transports
> -
> -Optional properties:
> -
> -- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
> -
> -- interrupts : when using smc or hvc transports, this optional
> - property indicates that msg completion by the platform is indicated
> - by an interrupt rather than by the return of the smc call. This
> - should not be used except when the platform requires such behavior.
> -
> -- interrupt-names : if "interrupts" is present, interrupt-names must also
> - be present and have the value "a2p".
> -
> -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.
> -
> -Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
> -------------------------------------------------------------
> -An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
> -and should be always positioned as a root regulator.
> -It does not support any current operation.
> -
> -SCMI Regulators are grouped under a 'regulators' node which in turn is a child
> -of the SCMI Voltage protocol node inside the desired SCMI instance node.
> -
> -This binding uses the common regulator binding[6].
> -
> -Required properties:
> - - reg : shall identify an existent SCMI Voltage Domain.
> -
> -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.
> -
> -Reset signal bindings for the reset domains based on SCMI Message Protocol
> -------------------------------------------------------------
> -
> -This binding for the SCMI reset domain providers uses the generic reset
> -signal binding[5].
> -
> -Required properties:
> - - #reset-cells : Should be 1. Contains the reset domain ID value used
> - by SCMI commands.
> -
> -[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.yaml
> -[3] Documentation/devicetree/bindings/thermal/thermal*.yaml
> -[4] Documentation/devicetree/bindings/sram/sram.yaml
> -[5] Documentation/devicetree/bindings/reset/reset.txt
> -[6] Documentation/devicetree/bindings/regulator/regulator.yaml
> -
> -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>;
> - };
> -
> - scmi_reset: protocol@16 {
> - reg = <0x16>;
> - #reset-cells = <1>;
> - };
> -
> - scmi_voltage: protocol@17 {
> - reg = <0x17>;
> -
> - regulators {
> - regulator_devX: regulator@0 {
> - reg = <0x0>;
> - regulator-max-microvolt = <3300000>;
> - };
> -
> - regulator_devY: regulator@9 {
> - reg = <0x9>;
> - regulator-min-microvolt = <500000>;
> - regulator-max-microvolt = <4200000>;
> - };
> -
> - ...
> - };
> - };
> - };
> -};
> -
> -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>;
> - resets = <&scmi_reset 10>;
> -};
> -
> -thermal-zones {
> - soc_thermal {
> - polling-delay-passive = <100>;
> - polling-delay = <1000>;
> - /* sensor ID */
> - thermal-sensors = <&scmi_sensors0 3>;
> - ...
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> new file mode 100644
> index 000000000000..0f5608d7e950
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -0,0 +1,474 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2021 ARM Ltd.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/arm,scmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: System Control and Management Interface (SCMI) Message Protocol bindings
> +
> +maintainers:
> + - Sudeep Holla <sudeep.holla@arm.com>
> +
> +description: |
> + 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 DEN 0056 ("ARM System Control
> + and Management Interface Platform Design Document")[0] provide for OSPM in
> + the device tree.
> +
> + [0] https://developer.arm.com/documentation/den0056/latest
> +
> +properties:
> + $nodename:
> + const: scmi
> +
> + compatible:
> + oneOf:
> + - description: SCMI compliant firmware with mailbox transport
> + items:
> + - const: arm,scmi
> + - description: SCMI compliant firmware with ARM SMC/HVC transport
> + items:
> + - const: arm,scmi-smc
> +
> + mbox-names:
> + description: |
> + Specifies the mailboxes used to communicate with SCMI compliant
> + firmware.
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + description: |
> + 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.
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + description: |
> + List of phandle pointing to the shared memory(SHM) area, for each
> + transport channel specified.
> + minItems: 1
> + maxItems: 2
> +
> + '#address-cells':
> + description: |
> + The address cells map to the protocol identifier for a given sub-node.
> + const: 1
> +
> + '#size-cells':
> + description: |
> + The size cells are not present as 'reg' property doesn't have any
> + size associated with it.
> + const: 0
> +
> + arm,smc-id:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + SMC id required when using smc or hvc transports
> +
> +additionalProperties:
> + type: object
This should be able to be 'false' as every child is covered by
'^protocol@[0-9a-f]+$', right?
> +
> +patternProperties:
> + '^protocol@[0-9a-f]+$':
> + type: object
> + description: |
> + Each sub-node represents a protocol supported. If the platform
> + supports a dedicated communication channel for a particular protocol,
> + then the corresponding transport properties must be present.
> +
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + required:
> + - reg
> +
> + '^protocol@11$':
Not a pattern, so move under 'properties'.
> + type: object
> + properties:
> + reg:
> + maxItems: 1
You can be more specific than that:
const: 0x11
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
No need to repeat all these. The '^protocol@[0-9a-f]+$' will also be
applied.
> +
> + '#power-domain-cells':
> + $ref: "/schemas/power/power-domain.yaml#"
Don't need this. Already has a type. Plus, you a applying a schema that
applies to DT nodes (objects), not a schema for a DT property. (It will
silently pass validation because the above schema doesn't have an
explicit 'type: object'.)
> + const: 1
> +
> + required:
> + - reg
Again, already covered.
> + - '#power-domain-cells'
> +
> + '^protocol@13$':
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + '#clock-cells':
> + const: 1
> +
> + required:
> + - reg
> + - '#clock-cells'
> +
> + '^protocol@14$':
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + '#clock-cells':
> + const: 1
> +
> + required:
> + - reg
> + - '#clock-cells'
> +
> + '^protocol@15$':
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + '#thermal-sensor-cells':
> + $ref: "/schemas/thermal/thermal-sensor.yaml#"
> + const: 1
> +
> + required:
> + - reg
> + - '#thermal-sensor-cells'
> +
> + '^protocol@16$':
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + '#reset-cells':
> + const: 1
> +
> + required:
> + - reg
> + - '#reset-cells'
> +
> + '^protocol@17$':
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + regulators:
> + type: object
> + description: |
> + The list of all regulators provided by this SCMI controller.
> + patternProperties:
> + '^regulators@[0-9a-f]+$':
> + type: object
> + $ref: "../regulator/regulator.yaml#"
> + properties:
> + reg:
> + maxItems: 1
> + description: Identifier for the voltage regulator.
> + required:
> + - reg
> +
> + required:
> + - reg
> +
> +required:
> + - compatible
> + - shmem
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: arm,scmi
> + then:
> + required:
> + - mboxes
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: arm,scmi-smc
wouldn't 'else' work here?
> + then:
> + properties:
> + interrupts:
> + description: |
> + The interrupt that indicates message completion by the platform
> + rather than by the return of the smc call. This should not be used
> + except when the platform requires such behavior.
> +
> + interrupt-names:
> + const: a2p
> +
> + required:
> + - arm,smc-id
> +
> +examples:
> + - |
> + firmware {
> + scmi {
> + compatible = "arm,scmi";
> + mboxes = <&mhuB 0 0>,
> + <&mhuB 0 1>;
> + mbox-names = "tx", "rx";
> + shmem = <&cpu_scp_lpri0 &cpu_scp_lpri1>;
> +
> + #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>;
> +
> + mboxes = <&mhuB 1 0>,
> + <&mhuB 1 1>;
> + mbox-names = "tx", "rx";
> + shmem = <&cpu_scp_hpri0 &cpu_scp_hpri1>;
> + };
> +
> + scmi_clk: protocol@14 {
> + reg = <0x14>;
> + #clock-cells = <1>;
> + };
> +
> + scmi_sensors: protocol@15 {
> + reg = <0x15>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + scmi_reset: protocol@16 {
> + reg = <0x16>;
> + #reset-cells = <1>;
> + };
> +
> + scmi_voltage: protocol@17 {
> + reg = <0x17>;
> + regulators {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + regulator_devX: regulator@0 {
> + reg = <0x0>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + regulator_devY: regulator@9 {
> + reg = <0x9>;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <4200000>;
> + };
> + };
> + };
> + };
> + };
> +
> + soc {
You don't have to show every client connection. It's more to potentially
fix when we add or improve schemas and there's probably already
examples for them. I'd drop perhaps all but the mmio-sram which doesn't
have other examples.
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + sram@50000000 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x50000000 0x0 0x10000>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x50000000 0x10000>;
> +
> + cpu_scp_lpri0: scp-sram-section@0 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x0 0x80>;
> + };
> +
> + cpu_scp_lpri1: scp-sram-section@80 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x80 0x80>;
> + };
> +
> + cpu_scp_hpri0: scp-sram-section@100 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x100 0x80>;
> + };
> +
> + cpu_scp_hpri2: scp-sram-section@180 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x180 0x80>;
> + };
> + };
> +
> + mhuB: mailbox@2b2f0000 {
> + #mbox-cells = <2>;
> + compatible = "arm,mhu-doorbell", "arm,primecell";
> + reg = <0 0x2b2f0000 0 0x1000>;
> + interrupts = <0 36 4>, /* LP-NonSecure */
> + <0 35 4>, /* HP-NonSecure */
> + <0 37 4>; /* Secure */
> + clocks = <&clock 0 2 1>;
> + clock-names = "apb_pclk";
> + };
> +
> + gpu@ffe40000 {
> + compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
> + reg = <0x0 0xffe40000 0x0 0x10000>;
> + interrupts = <0 160 4>, <0 161 4>, <0 162 4>;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = <&scmi_clk 1>;
> + power-domains = <&scmi_devpd 8>;
> + resets = <&scmi_reset 0>, <&scmi_reset 1>;
> + };
> +
> + display@20930000 {
> + compatible = "intel,keembay-display";
> + reg = <0x0 0x20930000 0x0 0x3000>;
> + reg-names = "lcd";
> + interrupts = <0 33 4>;
> + clocks = <&scmi_clk 0x83>,
> + <&scmi_clk 0x0>;
> + clock-names = "clk_lcd", "clk_pll0";
> +
> + port {
> + disp_out: endpoint {
> + remote-endpoint = <&dsi_in>;
> + };
> + };
> + };
> +
> + thermal-zones {
> + soc-thermal {
> + polling-delay-passive = <100>;
> + polling-delay = <1000>;
> + thermal-sensors = <&scmi_sensors 3>;
> +
> + trips {
> + mpu0_crit: mpu0_crit {
> + temperature = <125000>; /* milliCelsius */
> + hysteresis = <2000>; /* milliCelsius */
> + type = "critical";
> + };
> + };
> + };
> + };
> + };
> +
> + cpus {
> + #size-cells = <0>;
> + #address-cells = <2>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x0>;
> + enable-method = "psci";
> + clocks = <&scmi_dvfs 0>;
> + };
> + };
> +
> +...
> --
> 2.25.1
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v2 8/8] dt-bindings: firmware: arm,scmi: Convert to json schema
@ 2021-06-02 16:16 ` Rob Herring
0 siblings, 0 replies; 32+ messages in thread
From: Rob Herring @ 2021-06-02 16:16 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, linux-arm-kernel, Cristian Marussi, Florian Fainelli,
Jim Quinlan, Etienne Carriere, Peter Hilber
On Tue, Jun 01, 2021 at 11:49:04PM +0100, Sudeep Holla wrote:
> Convert the old text format binding for System Control and Management Interface
> (SCMI) Message Protocol into the new and shiny YAML format.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Cristian Marussi <cristian.marussi@arm.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Jim Quinlan <jim2101024@gmail.com>
> Cc: Etienne Carriere <etienne.carriere@linaro.org>
> Cc: Peter Hilber <peter.hilber@opensynergy.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> .../devicetree/bindings/arm/arm,scmi.txt | 224 ---------
> .../bindings/firmware/arm,scmi.yaml | 474 ++++++++++++++++++
> 2 files changed, 474 insertions(+), 224 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt
> create mode 100644 Documentation/devicetree/bindings/firmware/arm,scmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt
> deleted file mode 100644
> index b7be2000afcb..000000000000
> --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt
> +++ /dev/null
> @@ -1,224 +0,0 @@
> -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 DEN 0056A ("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" or "arm,scmi-smc" for smc/hvc transports
> -- 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.
> -- arm,smc-id : SMC id required when using smc or hvc transports
> -
> -Optional properties:
> -
> -- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
> -
> -- interrupts : when using smc or hvc transports, this optional
> - property indicates that msg completion by the platform is indicated
> - by an interrupt rather than by the return of the smc call. This
> - should not be used except when the platform requires such behavior.
> -
> -- interrupt-names : if "interrupts" is present, interrupt-names must also
> - be present and have the value "a2p".
> -
> -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.
> -
> -Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
> -------------------------------------------------------------
> -An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
> -and should be always positioned as a root regulator.
> -It does not support any current operation.
> -
> -SCMI Regulators are grouped under a 'regulators' node which in turn is a child
> -of the SCMI Voltage protocol node inside the desired SCMI instance node.
> -
> -This binding uses the common regulator binding[6].
> -
> -Required properties:
> - - reg : shall identify an existent SCMI Voltage Domain.
> -
> -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.
> -
> -Reset signal bindings for the reset domains based on SCMI Message Protocol
> -------------------------------------------------------------
> -
> -This binding for the SCMI reset domain providers uses the generic reset
> -signal binding[5].
> -
> -Required properties:
> - - #reset-cells : Should be 1. Contains the reset domain ID value used
> - by SCMI commands.
> -
> -[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.yaml
> -[3] Documentation/devicetree/bindings/thermal/thermal*.yaml
> -[4] Documentation/devicetree/bindings/sram/sram.yaml
> -[5] Documentation/devicetree/bindings/reset/reset.txt
> -[6] Documentation/devicetree/bindings/regulator/regulator.yaml
> -
> -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>;
> - };
> -
> - scmi_reset: protocol@16 {
> - reg = <0x16>;
> - #reset-cells = <1>;
> - };
> -
> - scmi_voltage: protocol@17 {
> - reg = <0x17>;
> -
> - regulators {
> - regulator_devX: regulator@0 {
> - reg = <0x0>;
> - regulator-max-microvolt = <3300000>;
> - };
> -
> - regulator_devY: regulator@9 {
> - reg = <0x9>;
> - regulator-min-microvolt = <500000>;
> - regulator-max-microvolt = <4200000>;
> - };
> -
> - ...
> - };
> - };
> - };
> -};
> -
> -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>;
> - resets = <&scmi_reset 10>;
> -};
> -
> -thermal-zones {
> - soc_thermal {
> - polling-delay-passive = <100>;
> - polling-delay = <1000>;
> - /* sensor ID */
> - thermal-sensors = <&scmi_sensors0 3>;
> - ...
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> new file mode 100644
> index 000000000000..0f5608d7e950
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -0,0 +1,474 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2021 ARM Ltd.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/arm,scmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: System Control and Management Interface (SCMI) Message Protocol bindings
> +
> +maintainers:
> + - Sudeep Holla <sudeep.holla@arm.com>
> +
> +description: |
> + 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 DEN 0056 ("ARM System Control
> + and Management Interface Platform Design Document")[0] provide for OSPM in
> + the device tree.
> +
> + [0] https://developer.arm.com/documentation/den0056/latest
> +
> +properties:
> + $nodename:
> + const: scmi
> +
> + compatible:
> + oneOf:
> + - description: SCMI compliant firmware with mailbox transport
> + items:
> + - const: arm,scmi
> + - description: SCMI compliant firmware with ARM SMC/HVC transport
> + items:
> + - const: arm,scmi-smc
> +
> + mbox-names:
> + description: |
> + Specifies the mailboxes used to communicate with SCMI compliant
> + firmware.
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + description: |
> + 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.
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + description: |
> + List of phandle pointing to the shared memory(SHM) area, for each
> + transport channel specified.
> + minItems: 1
> + maxItems: 2
> +
> + '#address-cells':
> + description: |
> + The address cells map to the protocol identifier for a given sub-node.
> + const: 1
> +
> + '#size-cells':
> + description: |
> + The size cells are not present as 'reg' property doesn't have any
> + size associated with it.
> + const: 0
> +
> + arm,smc-id:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + SMC id required when using smc or hvc transports
> +
> +additionalProperties:
> + type: object
This should be able to be 'false' as every child is covered by
'^protocol@[0-9a-f]+$', right?
> +
> +patternProperties:
> + '^protocol@[0-9a-f]+$':
> + type: object
> + description: |
> + Each sub-node represents a protocol supported. If the platform
> + supports a dedicated communication channel for a particular protocol,
> + then the corresponding transport properties must be present.
> +
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + required:
> + - reg
> +
> + '^protocol@11$':
Not a pattern, so move under 'properties'.
> + type: object
> + properties:
> + reg:
> + maxItems: 1
You can be more specific than that:
const: 0x11
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
No need to repeat all these. The '^protocol@[0-9a-f]+$' will also be
applied.
> +
> + '#power-domain-cells':
> + $ref: "/schemas/power/power-domain.yaml#"
Don't need this. Already has a type. Plus, you a applying a schema that
applies to DT nodes (objects), not a schema for a DT property. (It will
silently pass validation because the above schema doesn't have an
explicit 'type: object'.)
> + const: 1
> +
> + required:
> + - reg
Again, already covered.
> + - '#power-domain-cells'
> +
> + '^protocol@13$':
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + '#clock-cells':
> + const: 1
> +
> + required:
> + - reg
> + - '#clock-cells'
> +
> + '^protocol@14$':
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + '#clock-cells':
> + const: 1
> +
> + required:
> + - reg
> + - '#clock-cells'
> +
> + '^protocol@15$':
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + '#thermal-sensor-cells':
> + $ref: "/schemas/thermal/thermal-sensor.yaml#"
> + const: 1
> +
> + required:
> + - reg
> + - '#thermal-sensor-cells'
> +
> + '^protocol@16$':
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + '#reset-cells':
> + const: 1
> +
> + required:
> + - reg
> + - '#reset-cells'
> +
> + '^protocol@17$':
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
> + minItems: 1
> + maxItems: 2
> +
> + shmem:
> + minItems: 1
> + maxItems: 2
> +
> + regulators:
> + type: object
> + description: |
> + The list of all regulators provided by this SCMI controller.
> + patternProperties:
> + '^regulators@[0-9a-f]+$':
> + type: object
> + $ref: "../regulator/regulator.yaml#"
> + properties:
> + reg:
> + maxItems: 1
> + description: Identifier for the voltage regulator.
> + required:
> + - reg
> +
> + required:
> + - reg
> +
> +required:
> + - compatible
> + - shmem
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: arm,scmi
> + then:
> + required:
> + - mboxes
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: arm,scmi-smc
wouldn't 'else' work here?
> + then:
> + properties:
> + interrupts:
> + description: |
> + The interrupt that indicates message completion by the platform
> + rather than by the return of the smc call. This should not be used
> + except when the platform requires such behavior.
> +
> + interrupt-names:
> + const: a2p
> +
> + required:
> + - arm,smc-id
> +
> +examples:
> + - |
> + firmware {
> + scmi {
> + compatible = "arm,scmi";
> + mboxes = <&mhuB 0 0>,
> + <&mhuB 0 1>;
> + mbox-names = "tx", "rx";
> + shmem = <&cpu_scp_lpri0 &cpu_scp_lpri1>;
> +
> + #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>;
> +
> + mboxes = <&mhuB 1 0>,
> + <&mhuB 1 1>;
> + mbox-names = "tx", "rx";
> + shmem = <&cpu_scp_hpri0 &cpu_scp_hpri1>;
> + };
> +
> + scmi_clk: protocol@14 {
> + reg = <0x14>;
> + #clock-cells = <1>;
> + };
> +
> + scmi_sensors: protocol@15 {
> + reg = <0x15>;
> + #thermal-sensor-cells = <1>;
> + };
> +
> + scmi_reset: protocol@16 {
> + reg = <0x16>;
> + #reset-cells = <1>;
> + };
> +
> + scmi_voltage: protocol@17 {
> + reg = <0x17>;
> + regulators {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + regulator_devX: regulator@0 {
> + reg = <0x0>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + regulator_devY: regulator@9 {
> + reg = <0x9>;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <4200000>;
> + };
> + };
> + };
> + };
> + };
> +
> + soc {
You don't have to show every client connection. It's more to potentially
fix when we add or improve schemas and there's probably already
examples for them. I'd drop perhaps all but the mmio-sram which doesn't
have other examples.
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + sram@50000000 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x50000000 0x0 0x10000>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x50000000 0x10000>;
> +
> + cpu_scp_lpri0: scp-sram-section@0 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x0 0x80>;
> + };
> +
> + cpu_scp_lpri1: scp-sram-section@80 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x80 0x80>;
> + };
> +
> + cpu_scp_hpri0: scp-sram-section@100 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x100 0x80>;
> + };
> +
> + cpu_scp_hpri2: scp-sram-section@180 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x180 0x80>;
> + };
> + };
> +
> + mhuB: mailbox@2b2f0000 {
> + #mbox-cells = <2>;
> + compatible = "arm,mhu-doorbell", "arm,primecell";
> + reg = <0 0x2b2f0000 0 0x1000>;
> + interrupts = <0 36 4>, /* LP-NonSecure */
> + <0 35 4>, /* HP-NonSecure */
> + <0 37 4>; /* Secure */
> + clocks = <&clock 0 2 1>;
> + clock-names = "apb_pclk";
> + };
> +
> + gpu@ffe40000 {
> + compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
> + reg = <0x0 0xffe40000 0x0 0x10000>;
> + interrupts = <0 160 4>, <0 161 4>, <0 162 4>;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = <&scmi_clk 1>;
> + power-domains = <&scmi_devpd 8>;
> + resets = <&scmi_reset 0>, <&scmi_reset 1>;
> + };
> +
> + display@20930000 {
> + compatible = "intel,keembay-display";
> + reg = <0x0 0x20930000 0x0 0x3000>;
> + reg-names = "lcd";
> + interrupts = <0 33 4>;
> + clocks = <&scmi_clk 0x83>,
> + <&scmi_clk 0x0>;
> + clock-names = "clk_lcd", "clk_pll0";
> +
> + port {
> + disp_out: endpoint {
> + remote-endpoint = <&dsi_in>;
> + };
> + };
> + };
> +
> + thermal-zones {
> + soc-thermal {
> + polling-delay-passive = <100>;
> + polling-delay = <1000>;
> + thermal-sensors = <&scmi_sensors 3>;
> +
> + trips {
> + mpu0_crit: mpu0_crit {
> + temperature = <125000>; /* milliCelsius */
> + hysteresis = <2000>; /* milliCelsius */
> + type = "critical";
> + };
> + };
> + };
> + };
> + };
> +
> + cpus {
> + #size-cells = <0>;
> + #address-cells = <2>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57";
> + reg = <0x0 0x0>;
> + enable-method = "psci";
> + clocks = <&scmi_dvfs 0>;
> + };
> + };
> +
> +...
> --
> 2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 32+ messages in thread