From: Rob Herring <robh@kernel.org>
To: Nicola Mazzucato <nicola.mazzucato@arm.com>
Cc: devicetree@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies
Date: Tue, 8 Sep 2020 14:26:14 -0600 [thread overview]
Message-ID: <20200908202614.GA851007@bogus> (raw)
In-Reply-To: <20200908141714.7194-1-nicola.mazzucato@arm.com>
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.
prev parent reply other threads:[~2020-09-08 20:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-08 14:17 [PATCH] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies Nicola Mazzucato
2020-09-08 19:26 ` Rob Herring
2020-09-08 20:26 ` Rob Herring [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200908202614.GA851007@bogus \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=nicola.mazzucato@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox