Message-ID: <62540312-65a2-b6d9-86ce-b4deaaa913c1@codeaurora.org>
Date:   Wed, 30 Sep 2020 16:25:30 +0530
From:   Rajendra Nayak <rnayak@...eaurora.org>
To:     Lukasz Luba <lukasz.luba@....com>,
        Doug Anderson <dianders@...omium.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>, linux-doc@...r.kernel.org,
        Jonathan Corbet <corbet@....net>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Dietmar.Eggemann@....com, Quentin Perret <qperret@...gle.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH 1/2] docs: Clarify abstract scale usage for power values
 in Energy Model


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@....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@....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@...omium.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

Powered by blists - more mailing lists