On 8/10/21 10:27 AM, Viresh Kumar wrote:
On 10-08-21, 10:17, Lukasz Luba wrote:
Hi Viresh,
I like the idea, only small comments here in the cover letter.
On 8/10/21 8:36 AM, Viresh Kumar wrote:
Provide a cpufreq driver flag so drivers can ask the cpufreq core to register
with the EM core on their behalf. This allows us to get rid of duplicated code
in the drivers and fix the unregistration part as well, which none of the
drivers have done until now.
The EM is never freed for CPUs by design. The unregister function was
introduced for devfreq devices.
I see. So if a cpufreq driver unregisters and registers again, it will
be required to use the entries created by the registration itself,
right ? Technically speaking, it is better to unregister and free any
related resources and parse everything again.
Lets say, just for fun, I want to test two copies of a cpufreq driver
It's good that it's just for fun ;)
(providing different set of freq-tables). I build both of them as
modules, insert the first version, remove it, insert the second one.
Ideally, this should just work as expected. But I don't think it will
in this case as you never parse the EM stuff again.
The EM is directly used by scheduler in the hot-path, there are no
checks even if the EM if for CPUs. We are sure it's is for CPUs and
is always there for all CPUs.
I'm currently working on a EM v2 which would have stronger mechanisms
and do better job in this field. The patches are under internal review
and hopefully ready to post by the end of month.
Again, since the routine is there already, I think it is better/fine
to just use it.
True, it doesn't harm, so I commented it in the patch 1/8 that it
could stay.
This would also make the registration with EM core to happen only after policy
is fully initialized, and the EM core can do other stuff from in there, like
marking frequencies as inefficient (WIP). Though this patchset is useful without
that work being done and should be merged nevertheless.
This doesn't update scmi cpufreq driver for now as it is a special case and need
to be handled differently. Though we can make it work with this if required.
The scmi cpufreq driver uses direct EM API, which provides flexibility
and should stay as is.
Right, so I left it as is for now.
