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@xxxxxxx> > --- > .../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.
