On Thursday 15 Oct 2020 at 15:40:16 (+0200), Rafael J. Wysocki wrote:

On Thu, Oct 15, 2020 at 12:22 PM Daniel Lezcano
[off-list ref] wrote:

quoted

On 15/10/2020 11:00, Lukasz Luba wrote:

[ ... ]

quoted

quoted

There is the SCMI and the DT. Because there are two sources where it is
impossible to know if they are using the same units, we are stuck to
ensure a consistency for the kernel.

The platform should use:
  - the SCMI only (scaled or real)
  - the DT only (real)
  [ - the firmware file only (scaled or real) ]

Do you mean by SCMI - registration using em_dev_register_perf_domain() ?

It was high level description, but yes, I guess it is the case.

quoted

quoted

As it is not possible to know if they are scaled or real, there is no
choice except making them mutually exclusive.

So you propose a bit more restriction in registration EM, to not get
lost in the future. I also have these doubts. Let's consider it and
maybe agree.

I've recommended Qcom to use em_dev_register_perf_domain() when they
have this obfuscated power values. Then any developer in the future
who wants to add EM for a new device on that platform, should use the
em_dev_register_perf_domain().

In this case the flag in EM that you have proposed makes sense.
We probably need an argument 'bool abstract_scale' in the
em_dev_register_perf_domain(..., bool abstract_scale)
as a source of information.

I was suggesting to add a flag to the em_perf_domain structure giving
the source of the power numbers.

So if the IPA is having the 'sustainable-power' set in DT but the
em_perf_domain is flagged with power number coming from SCMI, then they
will be incompatible, the thermal zone will fail to register.

quoted

We would allow to co-exist em_dev_register_perf_domain(..., false)
with dev_pm_opp_of_register_em() EM devices.

Is it make sense?

Well, it does not change my opinion. We should assume the energy model
is always milliwatts. If the SoC vendors find a way to get around with
bogoWatts, then good to them and up to them to deal with in the future.

That sounds fair enough, but it also means that any kernel patches
using power units different from milliwatts for the EM should be
rejected in the future, doesn't it?

And the existing code using different power units for the EM (if any)
should be updated/fixed accordingly, shouldn't it?

Otherwise I don't see now this can be regarded as a hard rule.

Sorry, jumping late in the discussion :)

To add a bit of background to this, it's been the plan from the very
beginning to make PM_EM use an abstract scale. The only reason it was
not merged like that is because the first version only worked for CPUs,
and IPA was using a totally different source for other devices. So we
had no choice but to specify PM_EM in mW to keep things compatible and
allow to transition IPA. But that is no longer true, so I'm in favor of
evolving PM_EM where it was supposed to be to begin with.

IMO, the only thing the kernel cares about is consistency across power
numbers, but not about the exact unit. And I agree with Rafael, we have
code paths in the kernel that feed data in PM_EM but _cannot_ guarantee
mW, SCMI being a prime example, so I don't think it is reasonable to
mandate that.

Having that properly documented + an 'abstract_scale' parameter in
dev_pm_opp_of_register_em() (or even a unit, which could be bogo-watts)
should work IMO. What is the concern with this approach?

Thanks,
Quentin