On 11-08-21, 09:37, Quentin Perret wrote: > On Wednesday 11 Aug 2021 at 10:48:59 (+0530), Viresh Kumar wrote: > > I had to use the pm-opp version, since almost everyone was using that. > > > > On the other hand, there isn't a lot of OPP specific stuff in > > dev_pm_opp_of_register_em(). It just uses dev_pm_opp_get_opp_count(), > > that's all. This ended up in the OPP core, nothing else. Maybe we can > > now move it back to the EM core and name it differently ? > > Well it also uses dev_pm_opp_find_freq_ceil() and > dev_pm_opp_get_voltage(), so not sure how easy it will be to move, but > if it is possible no objection from me. What uses these routines ? dev_pm_opp_of_register_em() ? I am not able to see that at least :( > Right but the EM is a description of the hardware, so it seemed fair > to assume this wouldn't change across the lifetime of the OS, similar > to the DT which we can't reload at run-time. Yes it can be a little odd > if you load/unload your driver module, but note that you generally can't > load two completely different drivers on a single system. You'll just > load the same one again and the hardware hasn't changed in the meantime, > so the previously loaded EM will still be correct. Yeah, it will be the same driver but a different version of it, which may have updated the freq table. For me the EM is attached to the freq-table, and the freq-table is not available anymore after the driver is gone. Anyway, I will leave that for you guys to decide :) > I hear your argument > about cpufreq driver development, but the locking involved to allow > 'just' that is pretty involved, and nobody has complained about this > specific issue so far, so that didn't seem worth it. If we do have good > reasons to change the EM at runtime, then yes I think we should do it, > it just didn't seem like that was the case until now. -- viresh
