devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:40:16 +0200	[thread overview]
Message-ID: <CAJZ5v0hV8fwRnADdjiiF=zapO3AE6=_W_PeOQ_WhUirCcFkgdA@mail.gmail.com> (raw)
In-Reply-To: <00ceec64-3273-bb4a-6f38-22de8d877ab5@linaro.org>

On Thu, Oct 15, 2020 at 12:22 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 15/10/2020 11:00, Lukasz Luba wrote:
>
> [ ... ]
>
> >> 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) ]
> >>
> >
> > Do you mean by SCMI - registration using em_dev_register_perf_domain() ?
>
> It was high level description, but yes, I guess it is the case.
>
> >> As it is not possible to know if they are scaled or real, there is no
> >> choice except making them mutually exclusive.
> >
> > So you propose a bit more restriction in registration EM, to not get
> > lost in the future. I also have these doubts. Let's consider it and
> > maybe agree.
> >
> > I've recommended Qcom to use em_dev_register_perf_domain() when they
> > have this obfuscated power values. Then any developer in the future
> > who wants to add EM for a new device on that platform, should use the
> > em_dev_register_perf_domain().
> >
> > In this case the flag in EM that you have proposed makes sense.
> > We probably need an argument 'bool abstract_scale' in the
> > em_dev_register_perf_domain(..., bool abstract_scale)
> > as a source of information.
>
> I was suggesting to add a flag to the em_perf_domain structure giving
> the source of the power numbers.
>
> So if the IPA is having the 'sustainable-power' set in DT but the
> em_perf_domain is flagged with power number coming from SCMI, then they
> will be incompatible, the thermal zone will fail to register.
>
>
> > We would allow to co-exist em_dev_register_perf_domain(..., false)
> > with dev_pm_opp_of_register_em() EM devices.
> >
> > Is it make sense?
>
> Well, it does not change my opinion. We should assume the energy model
> is always milliwatts. If the SoC vendors find a way to get around with
> bogoWatts, then good to them and up to them to deal with in the future.

That sounds fair enough, but it also means that any kernel patches
using power units different from milliwatts for the EM should be
rejected in the future, doesn't it?

And the existing code using different power units for the EM (if any)
should be updated/fixed accordingly, shouldn't it?

Otherwise I don't see now this can be regarded as a hard rule.

  reply	other threads:[~2020-10-15 13:40 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 [this message]
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
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='CAJZ5v0hV8fwRnADdjiiF=zapO3AE6=_W_PeOQ_WhUirCcFkgdA@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).