From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Lukasz Luba <lukasz.luba@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Amit Kucheria <amitk@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Dietmar Eggemann <Dietmar.Eggemann@arm.com>,
Quentin Perret <qperret@google.com>,
Doug Anderson <dianders@chromium.org>,
Matthias Kaehlcke <mka@chromium.org>,
"Nayak, Rajendra" <rnayak@codeaurora.org>
Subject: Re: [PATCH v2 0/3] Clarify abstract scale usage for power values in Energy Model, EAS and IPA
Date: Thu, 15 Oct 2020 15:33:36 +0200 [thread overview]
Message-ID: <CAJZ5v0jmTYtMyujxxTBezmiO-j3iW_RjRKOkCpqU4gtRe+OJ2Q@mail.gmail.com> (raw)
In-Reply-To: <d04019bd-9e85-5f3e-2a1b-66780b8df3dc@linaro.org>
On Wed, Oct 14, 2020 at 7:10 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 14/10/2020 17:24, Lukasz Luba wrote:
>
> [ ... ]
>
> > We have to update the EM doc about allowed abstract scale, which
> > implies EAS, IPA doc update with some information to the community that
> > these components can handle it.
> >
> > The script will just make developers life easier, but the current
> > documentation does not say anything about abstract scale.
>
> ... yes, because there is no consistency across the source of power
> numbers and no tools to ensure DT power numbers consistency, yet.
>
> >> In any case, if the DT is specifying real numbers, and SCMI abstract
> >> numbers or the opposite, obviously there is a conflict if we are using
> >> both.
> >
> > True, DT only allows real numbers (I have Rob's opinion regarding
> > patch 3/3).
> >
> > It's not that there is only SCMI which might use abstract scale. Qcom
> > already has it and other vendors will follow (not exposing real
> > numbers). They would register bogoWatts to EM because they know that EAS
> > can deal with both.
>
> So vendors are using bogoWatts, despite the documentation.
>
> By updating the documentation saying it supports the abstract values,
> that means every new framework, device with power values, will have to
> comply with that. How is it possible to add a device with power numbers
> if the existing ones are obfuscated ?
>
> With two subsystems using the energy model, evolving independently we
> can see there are conflicts. With more subsystems, that may become a
> source of confusion, especially with different contributors.
>
> I think the energy model should stick to milliwatts and keep the
> documentation unchanged regarding this. And vendors should take the
> responsibility of not sticking to the documentation.
>
> >> I suggest to fix the conflict first and provide the features to make the
> >> numbers more easy to share (like the script described above and/or the
> >> firmware file).
> >>
> >> Then with the right tools, everything can be documented.
> >>
> >
> > We cannot block one way of registration to EM when the other was used.
> > They might have correct and consistent numbers.
>
> What is the rational of using two firmware power information ?
>
> > It's up to the platform developers to choose the path:
> > - go with bogoWatts - if they are not allowed to expose sensitive
> > information, use em_dev_register_perf_domain() in drivers, not DT;
> > make sure everything that is needed works; check the doc, which
> > sub-systems can handle it or needs some tuning (patches 1/3 and 2/3
> > try to help here);
> > - use milliWatts - easier; DT is allowed; help from the community in
> > reviews, possible results comparisons; both EM registration ways
> > might be used;
> >
> > We cannot force vendors/OEM engineers to store milliWatts in the
> > Energy Model if these values are protected by some NDA.
>
> If I am able to measure one real power value, (and I'm pretty sure it is
> quite possible), whatever which one, it is possible to deduce all the
> numbers with the linear scale. IMO that is a false debate. Anyway ...
>
> > Your proposed
> > way of providing data into EM from user-space firmware.bin IMHO also
> > falls into the same bucket. That information would be accessible in EM
> > debugfs and they would avoid it.
>
> I think you misunderstood my point.
>
> There is the SCMI and the DT. Because there are two sources where it is
> impossible to know if they are using the same units, we are stuck to
> ensure a consistency for the kernel.
>
> The platform should use:
> - the SCMI only (scaled or real)
> - the DT only (real)
> [ - the firmware file only (scaled or real) ]
>
>
> As it is not possible to know if they are scaled or real, there is no
> choice except making them mutually exclusive.
>
> From my POV, it is not adequate to let SCMI power information co-exists
> with the DT power information if we know they can be with different units.
>
> I've just expressed my opinions:
>
> - vendors take responsibility of putting different units for the EM
>
> - Power numbers should come from the same source
>
>
> Up to Rafael to decide what to do with this documentation update.
Well, I was hoping that you both would reach some kind of agreement.
I don't feel like the decision is mine here to be honest.
next prev parent reply other threads:[~2020-10-15 13:33 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 11:44 [PATCH v2 0/3] Clarify abstract scale usage for power values in Energy Model, EAS and IPA Lukasz Luba
2020-10-02 11:44 ` [PATCH v2 1/3] docs: Clarify abstract scale usage for power values in Energy Model Lukasz Luba
2020-10-02 11:44 ` [PATCH v2 2/3] PM / EM: update the comments related to power scale Lukasz Luba
2020-10-02 11:44 ` [PATCH v2 3/3] dt-bindings: thermal: update sustainable-power with abstract scale Lukasz Luba
2020-10-02 14:31 ` Doug Anderson
2020-10-02 15:12 ` Lukasz Luba
2020-10-02 15:47 ` Doug Anderson
2020-10-02 16:40 ` Lukasz Luba
2020-10-02 17:39 ` Doug Anderson
2020-10-06 22:24 ` Rob Herring
2020-10-07 1:17 ` Doug Anderson
2020-10-07 13:26 ` Rob Herring
2020-10-07 21:40 ` Doug Anderson
2020-10-08 14:20 ` Lukasz Luba
2020-10-08 16:41 ` Doug Anderson
2020-10-07 9:03 ` Lukasz Luba
2020-10-05 13:58 ` Rob Herring
2020-10-05 16:14 ` Lukasz Luba
2020-10-09 9:16 ` [PATCH v2 0/3] Clarify abstract scale usage for power values in Energy Model, EAS and IPA Lukasz Luba
2020-10-14 8:22 ` Daniel Lezcano
2020-10-14 9:08 ` Lukasz Luba
2020-10-14 11:23 ` Daniel Lezcano
2020-10-14 15:24 ` Lukasz Luba
2020-10-14 17:10 ` Daniel Lezcano
2020-10-15 9:00 ` Lukasz Luba
2020-10-15 10:21 ` Daniel Lezcano
2020-10-15 13:40 ` Rafael J. Wysocki
2020-10-15 15:04 ` Quentin Perret
2020-10-16 11:48 ` Daniel Lezcano
2020-10-16 12:18 ` Quentin Perret
2020-10-16 12:50 ` Daniel Lezcano
2020-10-16 13:09 ` Quentin Perret
2020-10-16 14:36 ` Doug Anderson
2020-10-16 15:55 ` Quentin Perret
2020-10-16 14:42 ` Lukasz Luba
2020-10-16 16:02 ` Quentin Perret
2020-10-19 10:35 ` Lukasz Luba
2020-10-15 13:33 ` Rafael J. Wysocki [this message]
2020-10-15 13:39 ` Daniel Lezcano
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=CAJZ5v0jmTYtMyujxxTBezmiO-j3iW_RjRKOkCpqU4gtRe+OJ2Q@mail.gmail.com \
--to=rafael@kernel.org \
--cc=Dietmar.Eggemann@arm.com \
--cc=amitk@kernel.org \
--cc=corbet@lwn.net \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mka@chromium.org \
--cc=qperret@google.com \
--cc=rjw@rjwysocki.net \
--cc=rnayak@codeaurora.org \
--cc=robh+dt@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).