linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rajendra Nayak <rnayak@codeaurora.org>
To: Lukasz Luba <lukasz.luba@arm.com>, Doug Anderson <dianders@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	linux-doc@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Dietmar.Eggemann@arm.com, Quentin Perret <qperret@google.com>,
	Matthias Kaehlcke <mka@chromium.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH 1/2] docs: Clarify abstract scale usage for power values in Energy Model
Date: Wed, 30 Sep 2020 16:25:30 +0530	[thread overview]
Message-ID: <62540312-65a2-b6d9-86ce-b4deaaa913c1@codeaurora.org> (raw)
In-Reply-To: <a1d1fe2a-485f-a21e-2f91-9b609223aa5a@arm.com>


On 9/30/2020 1:55 PM, Lukasz Luba wrote:
> Hi Douglas,
> 
> On 9/30/20 12:53 AM, Doug Anderson wrote:
>> Hi,
>>
>> On Tue, Sep 29, 2020 at 5:16 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>>
>>> The Energy Model (EM) can store power values in milli-Watts or in abstract
>>> scale. This might cause issues in the subsystems which use the EM for
>>> estimating the device power, such as:
>>> - mixing of different scales in a subsystem which uses multiple
>>>    (cooling) devices (e.g. thermal Intelligent Power Allocation (IPA))
>>> - assuming that energy [milli-Joules] can be derived from the EM power
>>>    values which might not be possible since the power scale doesn't have to
>>>    be in milli-Watts
>>>
>>> To avoid misconfiguration add the needed documentation to the EM and
>>> related subsystems: EAS and IPA.
>>>
>>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>>> ---
>>>   .../driver-api/thermal/power_allocator.rst          |  8 ++++++++
>>>   Documentation/power/energy-model.rst                | 13 +++++++++++++
>>>   Documentation/scheduler/sched-energy.rst            |  5 +++++
>>>   3 files changed, 26 insertions(+)
>>
>> I haven't read through these files in massive detail, but the quick
>> skim makes me believe that your additions seem sane.  In general, I'm
>> happy with documenting reality, thus:
>>
>> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> 
> Thank you for the review.
> 
>>
>> I will note: you haven't actually updated the device tree bindings.
>> Thus, presumably, anyone who is specifying these numbers in the device
>> tree is still supposed to specify them in a way that mW can be
>> recovered, right?  Said another way: nothing about your patches makes
>> it OK to specify numbers in device trees using an "abstract scale",
>> right?
> 
> For completeness, we are talking here about the binding from:
> Documentation/devicetree/bindings/arm/cpus.yaml
> which is 'dynamic-power-coefficient'. Yes, it stays untouched, also the
> unit (uW/MHz/V^2) which then allows to have mW in the power
> values in the EM.

So for platforms where 'dynamic-power-coefficient' is specified in device tree,
its always expected to be derived from 'real' power numbers on these platforms in
'real' mW?

Atleast on Qualcomm platforms we have these numbers scaled, so in essence it
can't be used to derive 'real' mW values. That said we also do not have any of
the 'platform might face potential issue of mixing devices in one thermal zone
of two scales' problem.

So the question is, can such platforms still use 'dynamic-power-coefficient'
in device tree and create an abstract scale? The other way of doing this would
be to *not* specify this value in device tree and have these values stored in the
cpufreq driver and register a custom callback to do the math.

It just feels like jumping through hoops just to deal with the fact that the
device tree bindings say its expected to be in mW and can't be abstract.

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

  reply	other threads:[~2020-09-30 10:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29 12:16 [PATCH 1/2] docs: Clarify abstract scale usage for power values in Energy Model Lukasz Luba
2020-09-29 12:16 ` [PATCH 2/2] PM / EM: update the comments related to power scale Lukasz Luba
2020-09-29 23:53 ` [PATCH 1/2] docs: Clarify abstract scale usage for power values in Energy Model Doug Anderson
2020-09-30  8:25   ` Lukasz Luba
2020-09-30 10:55     ` Rajendra Nayak [this message]
2020-09-30 14:04       ` Lukasz Luba
2020-09-30 15:48         ` Rajendra Nayak
2020-09-30 17:24           ` Doug Anderson
2020-10-01 14:09             ` Lukasz Luba

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=62540312-65a2-b6d9-86ce-b4deaaa913c1@codeaurora.org \
    --to=rnayak@codeaurora.org \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=corbet@lwn.net \
    --cc=daniel.lezcano@linaro.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 \
    /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).