Re: [PATCH v5 1/5] PM / EM: add devices to Energy Model

[Lukasz Luba]

On 4/6/20 10:17 PM, Daniel Lezcano wrote:
> On 06/04/2020 18:07, Lukasz Luba wrote:
> > On 4/6/20 3:58 PM, Daniel Lezcano wrote:
> > > Hi Lukasz,
> > >
> > >
> > > On 06/04/2020 15:29, Lukasz Luba wrote:
> > > > Hi Daniel,
> > > >
> > > > Thank you for the review.
> > > >
> > > > On 4/3/20 5:05 PM, Daniel Lezcano wrote:
> > > > > Hi Lukasz,
> > > > >
> > > > >
> > > > > On 18/03/2020 12:45, Lukasz Luba wrote:
> > > > > > Add support of other devices into the Energy Model framework not only
> > > > > > the
> > > > > > CPUs. Change the interface to be more unified which can handle other
> > > > > > devices as well.
> > > > >
> > > > > thanks for taking care of that. Overall I like the changes in this
> > > > > patch
> > > > > but it hard to review in details because the patch is too big :/
> > > > >
> > > > > Could you split this patch into smaller ones?
> > > > >
> > > > > eg. (at your convenience)
> > > > >
> > > > >  ÂÂ - One patch renaming s/cap/perf/
> > > > >
> > > > >  ÂÂ - One patch adding a new function:
> > > > >
> > > > >  ÂÂÂÂÂ em_dev_register_perf_domain(struct device *dev,
> > > > >  ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ unsigned int nr_states,
> > > > >  ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ struct em_data_callback *cb);
> > > > >
> > > > >  ÂÂÂÂ (+ EXPORT_SYMBOL_GPL)
> > > > >
> > > > >  ÂÂÂÂÂ And em_register_perf_domain() using it.
> > > > >
> > > > >  ÂÂ - One converting the em_register_perf_domain() user to
> > > > >  ÂÂÂÂÂem_dev_register_perf_domain
> > > > >
> > > > >  ÂÂ - One adding the different new 'em' functions
> > > > >
> > > > >  ÂÂ - And finally one removing em_register_perf_domain().
> > > >
> > > > I agree and will do the split. I could also break the dependencies
> > > > for future easier merge.
> > > >
> > > > > > Acked-by: Quentin Perret <qperret@xxxxxxxxxx>
> > > > > > Signed-off-by: Lukasz Luba <lukasz.luba@xxxxxxx>
> > > > > > ---
> > > > >
> > > > > [ ... ]
> > > > >
> > > > > >  ÂÂ 2. Core APIs
> > > > > > @@ -70,14 +72,16 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM
> > > > > > framework.
> > > > > >  ÂÂ Drivers are expected to register performance domains into the EM
> > > > > > framework by
> > > > > >  ÂÂ calling the following API::
> > > > > >  ÂÂ -Â int em_register_perf_domain(cpumask_t *span, unsigned int
> > > > > > nr_states,
> > > > > > -ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ struct em_data_callback *cb);
> > > > > > +Â int em_register_perf_domain(struct device *dev, unsigned int
> > > > > > nr_states,
> > > > > > +ÂÂÂÂÂÂÂ struct em_data_callback *cb, cpumask_t *cpus);
> > > > >
> > > > > Isn't possible to get rid of this cpumask by using
> > > > > cpufreq_cpu_get() which returns the cpufreq's policy and from their get
> > > > > the related cpus ?
> > > >
> > > > We had similar thoughts with Quentin and I've checked this.
> > >
> > > Yeah, I suspected you already think about that :)
> > >
> > > > Unfortunately, if the policy is a 'new policy' [1] it gets
> > > > allocated and passed into cpufreq driver ->init(policy) [2].
> > > > Then that policy is set into per_cpu pointer for each related_cpu [3]:
> > > >
> > > > for_each_cpu(j, policy->related_cpus)
> > > >  ÂÂÂÂÂper_cpu(cpufreq_cpu_data, j) = policy;
> > > >
> > > >  Â Thus, any calls of functions (i.e. cpufreq_cpu_get()) which try to
> > > > take this ptr before [3] won't work.
> > > >
> > > > We are trying to register EM from cpufreq_driver->init(policy) and the
> > > > per_cpu policy is likely to be not populated at that phase.
> > >
> > > What is the problem of registering at the end of the cpufreq_online ?
> >
> > We want to enable driver developers to choose one of two options for the
> > registration of Energy Model:
> > 1. a simple one via dev_pm_opp_of_register_em(), which uses default
> >  ÂÂ callback function calculating power based on: voltage, freq
> >  ÂÂ and DT entry 'dynamic-power-coefficient' for each OPP
> > 2. a more sophisticated, when driver provides callback function, which
> >  Â will be called from EM for each OPP to ask for related power;
> >  Â This interface could also be used by devices which relay not only
> >  Â on one source of 'voltage', i.e. manipulate body bias or have
> >  Â other controlling voltage for gates in the new 3D transistors. They
> >  Â might provide custom callback function in their cpufreq driver.
> >  Â This is used i.e. in cpufreq drivers which use firmware to get power,
> >  Â like scmi-cpufreq.c;
> >
> > To meet this requirement the registration of EM is moved into cpufreq
> > drivers, not in the framework i.e cpufreq_online(). If we could limit
> > the support for only option 1. then we could move the registration
> > call into cpufreq framework and clean the cpufreq drivers.
>
> I'm not sure to get your point but I think a series setting the scene by
> moving the dev_pm_opp_of_register_em() to cpufreq_online() and remove
> the cpumask may make sense.

Some of the cpufreq drivers don't use dev_pm_opp_of_register_em() but 
instead em_register_perf_domain() with their em_data_callback [1].
It is because of point 2. described above. The dev_pm_opp_of_register_em
won't work for them, so it's not a good candidate to cover all use cases
in the framework.

> Can you send the split version of patch 1/5 as a series without the
> other changes ? So we can focus on first ?

Sure, I will only split patch 1/5 as you suggested and send v6.
Thank you for your time and help.

Regards,
Lukasz

[1] 
https://elixir.bootlin.com/linux/latest/source/drivers/cpufreq/scmi-cpufreq.c#L203