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

From: Dietmar Eggemann
Date: Fri Jun 08 2018 - 12:40:14 EST

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

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