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

[ ... ]

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

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.

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.


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog