Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

[Dietmar Eggemann]

On 06/08/2018 03:11 PM, Quentin Perret wrote:
> On Friday 08 Jun 2018 at 14:39:33 (+0200), Dietmar Eggemann wrote:

[...]

> > > > Even though we would be forced to get cpufreq's related cpumask from
> > > > somewhere.
> > >
> > > That's the easy part. The difficult part is, where do you get power
> > > values from ? You have to let the lower layers register those values
> > > in a centralized location on a voluntary basis. And then it becomes easy
> > > for consumers to access that data, because they know where it is.
> >
> > The code in the arch could use the same struct em_data_callback em_cb = {
> > &dev_pm_opp_of_estimate_power } that the cpufreq driver is currently using?
>
> How do you know from the arch code if you should get power from DT
> with dev_pm_opp_of_estimate_power or use another callback that reads
> power from firmware (SCMI) ?

Ah, ok, cpufreq dt, scpi and arm_big_little are dt, cpufreq scmi can be 
different ...

> I don't think it is reasonable to assume a single source of information for
> an arch. It is is already an incorrect assumption even if just you look at
> the Arm world.

Ok, I see.

> > > Again, I don't think that's possible. You have to let the lower layers
> > > tell you where the power values come from, at the very least. You could
> > > let the archs do that aggregation I suppose, but I don't really see the
> > > benefit over one centralized framework with a generic interface ...
> > > What's your opinion ?
> >
> > Don't understand the '... let the lower layers tell you where the power
> > values come from ...' part. Where is the difference whether the arch or the
> > cpufreq driver uses em_data_callback?
>
> Because different CPUFreq drivers can be used for one arch. There are
> different CPUFreq drivers because there are different ways of getting
> information about the platform, even just for the Arm world (DT, SCPI,
> SCMI, ...). It's the same thing for power values, they don't necessarily
> come from DT.

scpi is dt ? At least scpi-cpufreq.c uses this 
dev_pm_opp_of_estimate_power too.

> The point of having a centralized EM framework with a standardized
> callback prototype is flexibility. You can implement a callback that
> estimates power from the DT. You can implement a callback that reads
> power from firmware. But you can also have a completely ad-hoc EM
> provider in a module if you like. All you have to do to provide data to
> the framework is respect the callback API.

IMHO, this idea is good, there should be also user of this outside 
arm/arm64 ...

[...]