On 10/30/20 8:29 AM, Viresh Kumar wrote:
On 29-10-20, 09:56, Lukasz Luba wrote:
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.
Why so ? (I am sorry, can't dig into such long threads without knowing
which message I am looking for :( ). Lets assume if that same property
can be used for bogoWatts, will that be sufficient for you ? Or you
will still need this patch set ?
I had a patch for that, but I know Rob's opinion on this one [1] (which
is below in that thread).
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.
Then maybe we should ahve sustainable-power in those cases too instead
of adding a meaningless (IMHO) binding.
How about dropping the DT binding, but just adding this new field into
dev_pm_opp? There will be no DT parsing code, just the get/set
functions, which will be used in SCMI patch 4/4 and in IPA?
That would not require to change any DT bindings.
Honestly speaking, as Nishanth said, there is nothing like a
sustainable OPP in reality. Moreover, the DT needs to describe the
hardware as it is (and in some cases the behavior of the firmware).
And what you are trying to add here is none of them and so it should
not go in DT as such. There are too many factors which play a part
here, ambient temperature is one of the biggest ones, and the software
needs to find the sustainable OPP by itself based on the current
situation.
So I don't really see a good reason why such a property should be
added here.
I see. Just for your information SCMI supports 'Sustained Performance'
expressed in kHz.
Coming to properties like suspend-opp, it made sense for some of the
platforms as the last configured frequency of the CPU plays a part in
deciding the power consumed by the SoC even when the system is
suspended. And finding an optimal OPP (normally the lowest) there
would make sense and so was that property added.
I also found that suspend-opp (83f8ca45afbf041e312909).
I hope you wouldn't mind if I add this new field into dev_pm_opp (no DT
support, just FW).
[1] https://lore.kernel.org/lkml/20201002114426.31277-4-lukasz.luba@xxxxxxx/
