devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.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: Fri, 16 Oct 2020 13:48:33 +0200	[thread overview]
Message-ID: <e321191c-61d2-a15d-47c2-653b277984ca@linaro.org> (raw)
In-Reply-To: <CAJZ5v0hV8fwRnADdjiiF=zapO3AE6=_W_PeOQ_WhUirCcFkgdA@mail.gmail.com>

On 15/10/2020 15:40, Rafael J. Wysocki wrote:
> On Thu, Oct 15, 2020 at 12:22 PM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:

[ ... ]

>>> 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?

Actually there are two things: the units and the numbers.

The energy model is expressed in mW.

All the frameworks (EAS, IPA, hopefully DTPM) using the energy model
should stick to the same unit, which I believe makes sense.

The numbers are provided by the SoC vendor or any contributors [1][2].

The different frameworks depends on those numbers.

If we specify in the documentation we support abstract numbers for the
EM, then that will imply any framework using it will have to comply with
that.

My point is we use milliwatts as a reference.

If we want to support abstract values, then the code should be changed
by *explicitly* use with these values, so if the other frameworks are
expecting real watts, they can detect they are not available and take
another action, like the scmi scaled power numbers and the
sustainable-power of the thermal which are incompatible.

If the consistency across the frameworks is guarantee by identifying the
kind of values (abstract or real), then we can put in the documentation
we support abstract value.

Unfortunately, IIUC, scmi does not tell us if the power numbers are real
or abstract ... :/

I don't see how we can ensure a consistency across the framework without
enforcing a strong policy.

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

Currently, the power units are expressed in mwatts for the energy model
and the frameworks using it.  AFAICT, no change is needed if we keep mW.

If we use scaled numbers, the EAS will work correctly (but the energy
values will be incorrect), but other frameworks won't.

The power numbers are provided by the DT (as supposed real), or by SCMI
(real or abstract).

If the SCMI is returning abstract numbers, the thermal IPA governor will
use these numbers as a reference to mitigate the temperature at the
specified sustainable power which is expressed in mW in the DT. So it
does not work and we can not detect such conflict.

That is why I'm advocating to keep mW for the energy model and make the
SCMI and DT power numbers incompatible.

  -- Daniel


[1]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1500974575-2244-1-git-send-email-wxt@rock-chips.com/

[2]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20190604165802.7338-2-daniel.lezcano@linaro.org/#22686211

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

  parent reply	other threads:[~2020-10-16 11:48 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 [this message]
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=e321191c-61d2-a15d-47c2-653b277984ca@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=amitk@kernel.org \
    --cc=corbet@lwn.net \
    --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=rafael@kernel.org \
    --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).