[v2,1/2] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies

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.

The example given here is referring specifically to SCMI in order to
provide a clear and direct example of a scenario. However, the proposed
binding is not SCMI specific. It allows DT to describe a generic hardware
property, CPU performance dependency, which may not be available through
other sources.

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 vs dt

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   | 48 +++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml

Hi guys,

On Thursday 24 Sep 2020 at 10:53:46 (+0100), Nicola Mazzucato wrote:
[..]
> 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..c7a577236cd6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cpu-perf-dependencies.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/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.

I'm continuing here a conversation started in v1 on the characteristics of
cpu-perf-dependencies and whether this binding actually describes the
hardware.

In the way I see this, the answer is clearly yes and it is information
that we need in the device tree, beyond the presence of SCMI as cpufreq
driver, and beyond the way it will be consumed by EAS/thermal/etc.

I link this to whether software will do the aggregation of per CPU
information in establishing the next frequency to be requested from the
driver/hardware for all dependent CPUs, or whether hardware is able to
receive the per CPU information on different channels and do the
aggregation itself.

This software aggregation is the typical way currently supported in
cpufreq, but hardware aggregation will be needed the more we see
hardware features for performance/power control.

But support for hardware aggregation involves having per-cpu channels
to convey the frequency request for that CPU. But currently the device
tree only gives us the ability to describe the information to be used
for sending frequency requests and as a result the kernel considers
CPUs as dependent only if they use the same controls for those CPUs.
So we currently can have hardware aggregation, but we lose all
information about what CPUs actually ended up having the same frequency,
because they are actually using the same clocks.

Therefore this new binding is needed for when hardware/firmware is better
equipped to make a decision about the clock rate for a group of CPUs, when
information is given about each CPU. The usefulness comes from informing
the software that some CPUs will have the same clock and therefore it
does describe a hardware characteristic of the system. In some cases
counters will help observe what was the frequency that was eventually
granted by hardware.

Knowing what CPUs actually use the same clock is very useful for the
scheduler (EAS, frequency invariance) and thermal.

Hope it helps,
Ionela.