[PATCH] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies

[PATCH] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies

[Nicola Mazzucato]

Currently, there is an assumption that the performance domains as provided
by the SCMI protocol should be mirroring the exact implementation in
hardware, for example, the clock domains, which are a typical type of
performance domains.

By design, an SCMI performance domain defines the granularity of
performance controls, it does not describe any underlying hardware
dependencies (although they may match in many cases).

As a consequence, in platforms where hardware may have the ability to
control cpu performance at different granularity and choose to describe
fine-grained performance control through SCMI performance domains, there
is currently no way for OSPM to discover the actual cpu hardware
dependencies. Inevitably, software components that rely on this missing
description will cease to work.

Thus, there is a need for a new description of hardware dependencies where
the performance level is coordinated by hardware (or firmware) since these
dependency domains might be larger than the SCMI performance domains.

This new optional binding will provide visibility to OSPM on any hardware
or firmware coordination of performance requests and enable more
accurate assumptions about performance and performance side-effects of
requesting performance level changers. This is essential information for
OSPM thermal and energy management frameworks.

There are two main reasons to support this new addition:

1) Per-cpu control & SCMI performance domains

Same as explained above. Some platforms would like to make aggregation
decisions in firmware and want to describe themselves as having per-cpu
control. In order to continue to make sane decisions in the OSPM layer,
we need to know about the underlying connections.

With this optional binding, we provide performance dependencies
information to OSPM for sets of CPUs while the h/w coordinates the
performance level for each cpu.

2) ACPI

With respect to performance, ACPI describes two main types of coordination
that may take place in system when logical processors are required to
transition to a different power/performance state. These two types are
software coordination (SW) and hardware coordination (HW). In the first
one, OSPM is in charge of handling such transitions while preserving the
integrity of the entire system. In the latter case, the h/w is responsible
for ensuring correct operations.

In the HW coordination, OSPM can control each processor as if they were all
independent each other. However, platforms can use ACPI defined interfaces
to group CPUs to create so called "dependency domain". Such interface is
the _PSD method. Users in kernel that need to know dependencies among
cores, can retrieve such information via _PSD [1].

If the same system needs to work with dt + SCMI, we will have all the
controls, but we are missing the information performance level coordination
in hardware/firmware.
This new dt binding provides the missing bits.

[1]ACPI Specification, version 6.3 - 8.3 Power, Performance, and Throttling
State Dependencies

Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com>
---
 .../bindings/arm/cpu-perf-dependencies.yaml   | 45 +++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml

diff --git a/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml b/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml
new file mode 100644
index 000000000000..3b8cf7e29982
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpu-perf-dependencies.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: CPU Performance Dependencies
+
+maintainers:
+  - Nicola Mazzucato <nicola.mazzucato@arm.com>
+
+description: |+
+  This optional node provides information to OSPM of cpu performance
+  dependencies.
+  Each list represents a set of CPUs which have performance level
+  dependencies and can assumed to be roughly at the same performance
+  level coordinated by hardware and/or firmware.
+  Example: Describing CPUs in the same clock domain.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - arm,cpu-perf-dependencies
+
+  cpu-perf-affinity:
+    $ref: '/schemas/types.yaml#/definitions/phandle'
+    description: |
+      Specifies a list of phandles to CPU nodes corresponding to a set of CPUs
+      which have performance affinity.
+
+examples:
+  - |
+    cpu-performance-dependencies {
+        compatible = "arm,cpu-perf-dependencies";
+        cpu-perf-domain0 {
+            cpu-perf-affinity = <&CPU0>, <&CPU1>, <&CPU2>, <&CPU3>;
+        }
+        cpu-perf-domain1 {
+            cpu-perf-affinity = <&CPU4>, <&CPU5>, <&CPU6>;
+        }
+        cpu-perf-domain2 {
+            cpu-perf-affinity = <&CPU7>;
+        }
+    };
-- 
2.27.0

Re: [PATCH] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies

[Rob Herring]

On Tue, Sep 8, 2020 at 8:53 AM Nicola Mazzucato
<nicola.mazzucato@arm.com> wrote:
>

So while this resend fixes the problem of not getting into DT
patchwork, you've dropped everyone else. The correct thing to do is
follow what get_maintainers.pl outputs as a starting point. That's not
exact as often you may or may not want 'commit signers' though I think
this wouldn't apply here given it's a new file. For this one, it's Arm
related so LAKML should be Cc'ed. As well as, Sudeep for SCMI, Viresh,
Daniel and probably others for power management related knowledge.

Where's the kernel implementation? Not strictly needed for adding a
binding, but more people will pay attention if there's an
implementation.

> Currently, there is an assumption that the performance domains as provided
> by the SCMI protocol should be mirroring the exact implementation in
> hardware, for example, the clock domains, which are a typical type of
> performance domains.
>
> By design, an SCMI performance domain defines the granularity of
> performance controls, it does not describe any underlying hardware
> dependencies (although they may match in many cases).
>
> As a consequence, in platforms where hardware may have the ability to
> control cpu performance at different granularity and choose to describe
> fine-grained performance control through SCMI performance domains, there
> is currently no way for OSPM to discover the actual cpu hardware
> dependencies. Inevitably, software components that rely on this missing
> description will cease to work.
>
> Thus, there is a need for a new description of hardware dependencies where
> the performance level is coordinated by hardware (or firmware) since these
> dependency domains might be larger than the SCMI performance domains.

Wouldn't non-SCMI platforms need to describe the same dependencies? On
the flip side, why doesn't SCMI make itself discoverable rather than
putting this in DT?

How does this relate to OPPs? Wouldn't we have an OPP per 'performance domain'?

How does this relate to idle states? Aren't they going to have the
same dependencies at least for cluster level states?

I'd like to see a complete example with OPPs, idles states, etc. all included.

> This new optional binding will provide visibility to OSPM on any hardware
> or firmware coordination of performance requests and enable more
> accurate assumptions about performance and performance side-effects of
> requesting performance level changers. This is essential information for
> OSPM thermal and energy management frameworks.
>
> There are two main reasons to support this new addition:
>
> 1) Per-cpu control & SCMI performance domains
>
> Same as explained above. Some platforms would like to make aggregation
> decisions in firmware and want to describe themselves as having per-cpu
> control. In order to continue to make sane decisions in the OSPM layer,
> we need to know about the underlying connections.
>
> With this optional binding, we provide performance dependencies
> information to OSPM for sets of CPUs while the h/w coordinates the
> performance level for each cpu.
>
> 2) ACPI

ACPI is not really relevant to a DT binding patch.

> With respect to performance, ACPI describes two main types of coordination
> that may take place in system when logical processors are required to
> transition to a different power/performance state. These two types are
> software coordination (SW) and hardware coordination (HW). In the first
> one, OSPM is in charge of handling such transitions while preserving the
> integrity of the entire system. In the latter case, the h/w is responsible
> for ensuring correct operations.
>
> In the HW coordination, OSPM can control each processor as if they were all
> independent each other. However, platforms can use ACPI defined interfaces
> to group CPUs to create so called "dependency domain". Such interface is
> the _PSD method. Users in kernel that need to know dependencies among
> cores, can retrieve such information via _PSD [1].
>
> If the same system needs to work with dt + SCMI, we will have all the
> controls, but we are missing the information performance level coordination
> in hardware/firmware.
> This new dt binding provides the missing bits.
>
> [1]ACPI Specification, version 6.3 - 8.3 Power, Performance, and Throttling
> State Dependencies
>
> Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com>
> ---
>  .../bindings/arm/cpu-perf-dependencies.yaml   | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml b/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml
> new file mode 100644
> index 000000000000..3b8cf7e29982
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cpu-perf-dependencies.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: CPU Performance Dependencies
> +
> +maintainers:
> +  - Nicola Mazzucato <nicola.mazzucato@arm.com>
> +
> +description: |+
> +  This optional node provides information to OSPM of cpu performance
> +  dependencies.
> +  Each list represents a set of CPUs which have performance level
> +  dependencies and can assumed to be roughly at the same performance
> +  level coordinated by hardware and/or firmware.
> +  Example: Describing CPUs in the same clock domain.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - arm,cpu-perf-dependencies
> +
> +  cpu-perf-affinity:
> +    $ref: '/schemas/types.yaml#/definitions/phandle'
> +    description: |
> +      Specifies a list of phandles to CPU nodes corresponding to a set of CPUs
> +      which have performance affinity.
> +
> +examples:
> +  - |
> +    cpu-performance-dependencies {
> +        compatible = "arm,cpu-perf-dependencies";
> +        cpu-perf-domain0 {

What does 0 correspond to? Just making up indices or ???

> +            cpu-perf-affinity = <&CPU0>, <&CPU1>, <&CPU2>, <&CPU3>;
> +        }
> +        cpu-perf-domain1 {
> +            cpu-perf-affinity = <&CPU4>, <&CPU5>, <&CPU6>;
> +        }
> +        cpu-perf-domain2 {
> +            cpu-perf-affinity = <&CPU7>;
> +        }
> +    };
> --
> 2.27.0
>

Re: [PATCH] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies

[Rob Herring]

On Tue, 08 Sep 2020 15:17:14 +0100, Nicola Mazzucato wrote:
> Currently, there is an assumption that the performance domains as provided
> by the SCMI protocol should be mirroring the exact implementation in
> hardware, for example, the clock domains, which are a typical type of
> performance domains.
> 
> By design, an SCMI performance domain defines the granularity of
> performance controls, it does not describe any underlying hardware
> dependencies (although they may match in many cases).
> 
> As a consequence, in platforms where hardware may have the ability to
> control cpu performance at different granularity and choose to describe
> fine-grained performance control through SCMI performance domains, there
> is currently no way for OSPM to discover the actual cpu hardware
> dependencies. Inevitably, software components that rely on this missing
> description will cease to work.
> 
> Thus, there is a need for a new description of hardware dependencies where
> the performance level is coordinated by hardware (or firmware) since these
> dependency domains might be larger than the SCMI performance domains.
> 
> This new optional binding will provide visibility to OSPM on any hardware
> or firmware coordination of performance requests and enable more
> accurate assumptions about performance and performance side-effects of
> requesting performance level changers. This is essential information for
> OSPM thermal and energy management frameworks.
> 
> There are two main reasons to support this new addition:
> 
> 1) Per-cpu control & SCMI performance domains
> 
> Same as explained above. Some platforms would like to make aggregation
> decisions in firmware and want to describe themselves as having per-cpu
> control. In order to continue to make sane decisions in the OSPM layer,
> we need to know about the underlying connections.
> 
> With this optional binding, we provide performance dependencies
> information to OSPM for sets of CPUs while the h/w coordinates the
> performance level for each cpu.
> 
> 2) ACPI
> 
> With respect to performance, ACPI describes two main types of coordination
> that may take place in system when logical processors are required to
> transition to a different power/performance state. These two types are
> software coordination (SW) and hardware coordination (HW). In the first
> one, OSPM is in charge of handling such transitions while preserving the
> integrity of the entire system. In the latter case, the h/w is responsible
> for ensuring correct operations.
> 
> In the HW coordination, OSPM can control each processor as if they were all
> independent each other. However, platforms can use ACPI defined interfaces
> to group CPUs to create so called "dependency domain". Such interface is
> the _PSD method. Users in kernel that need to know dependencies among
> cores, can retrieve such information via _PSD [1].
> 
> If the same system needs to work with dt + SCMI, we will have all the
> controls, but we are missing the information performance level coordination
> in hardware/firmware.
> This new dt binding provides the missing bits.
> 
> [1]ACPI Specification, version 6.3 - 8.3 Power, Performance, and Throttling
> State Dependencies
> 
> Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com>
> ---
>  .../bindings/arm/cpu-perf-dependencies.yaml   | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

./Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml: $id: relative path/filename doesn't match actual path or filename
	expected: http://devicetree.org/schemas/arm/cpu-perf-dependencies.yaml#
Error: Documentation/devicetree/bindings/arm/cpu-perf-dependencies.example.dts:24.13-29 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:342: Documentation/devicetree/bindings/arm/cpu-perf-dependencies.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1366: dt_binding_check] Error 2


See https://patchwork.ozlabs.org/patch/1359759

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade

Please check and re-submit.