Re: [PATCH 0/4] Add sustainable OPP concept
From: Lukasz Luba
Date: Thu Oct 29 2020 - 05:56:14 EST
On 10/29/20 7:53 AM, Viresh Kumar wrote:
On 29-10-20, 13:10, Viresh Kumar wrote:
On 28-10-20, 14:08, Lukasz Luba wrote:
Hi all,
This patch set introduces a concept of sustainable OPP, which then can be used
by kernel frameworks or governors for estimating system sustainable system
state. This kind of estimation is done e.g. in thermal governor Intelligent
Power Allocation (IPA), which calculates sustainable power of the whole system
and then derives some coefficients for internal algorithm.
The patch set introduces a new DT bindings 'opp-sustainable', with parsing
code. It also adds a function (in patch 3/4) which allows device drivers to set
directly the sustainable OPP. This is helpful when the device drivers populate
the OPP table by themself (example in patch 4/4).
Can we please have some more information about this ? What does the
sustainable OPP mean ? How will platform guys know or learn about this
? How we are going to use it finally ? What does it have to do with
temperature of the SoC or the thermal affects, etc.
There were discussions about Energy Model (EM), scale of values (mW or
abstract scale) and relation to EAS and IPA. You can find quite long
discussion below v2 [1] (there is also v3 send after agreement [2]).
We have in thermal DT binding: 'sustainable-power' expressed in mW,
which is used by IPA, but it would not support bogoWatts.
The sustainable power is used for estimation of internal coefficients
(also for power budget), which I am trying to change to work with
'abstract scale' [3][4].
This would allow to estimate sustainable power of the system based on
CPUs, GPU opp-sustainable points, where we don't have
'sustainable-power' or devices using bogoWatts.
And that we need a real user of this first if it is ever going to be
merged.
IPA would be the first user of this in combination with scmi-cpufreq.c,
which can feed 'abstract scale' in to EM.
Currently IPA takes lowest allowed OPPs into account for this estimation
which is not optimal. This marked OPPs would make estimation a lot
better.
Regards,
Lukasz
[1] https://lore.kernel.org/lkml/20201002114426.31277-1-lukasz.luba@xxxxxxx/
[2] https://lore.kernel.org/lkml/20201019140601.3047-1-lukasz.luba@xxxxxxx/
[3]
https://lore.kernel.org/linux-pm/5f682bbb-b250-49e6-dbb7-aea522a58595@xxxxxxx/
[4] https://lore.kernel.org/lkml/20201009135850.14727-1-lukasz.luba@xxxxxxx/