On 26/03/2024 21:32, Lukasz Luba wrote: > > > On 3/26/24 10:09, Dietmar Eggemann wrote: >> On 22/03/2024 12:08, Lukasz Luba wrote: [...] >>> + return em_recalc_and_update(dev, pd, em_table); >>> +} >>> +EXPORT_SYMBOL_GPL(em_dev_update_chip_binning); >> >> In the previous version of 'chip-binning' you were using the new EM >> interface em_dev_compute_costs() (1) which is now replaced by >> em_recalc_and_update() -> em_compute_costs(). >> >> https://lkml.kernel.org/r/20231220110339.1065505-2-lukasz.luba@xxxxxxx >> >> Which leaves (1) still unused. >> >> That was why my concern back then that we shouldn't introduce EM >> interfaces without a user: >> >> https://lkml.kernel.org/r/8fc499cf-fca1-4465-bff7-a93dfd36f3c8@xxxxxxx >> >> What happens now with em_dev_compute_costs()? >> > > For now it's not used, but modules which will create new EMs > with custom power values will use it. When such a module have > e.g. 5 EMs for one PD and only switches on one of them, then > this em_dev_compute_costs() will be used at setup for those > 5 EMs. Later it won't be used. > I don't wanted to combine the registration of new EM with > the compute cost, because that will create overhead in the > switching to new EM code path. Now we have only ~3us, which > was the main goal. > > When our scmi-cpufreq get the support for EM update this > compute cost will be used there. OK, I see. I checked the reloadable EM test module and em_dev_compute_costs() is used there like you described it.
