On Tue, 19 Oct 2021 at 09:24, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > On 15-10-21, 11:17, Ulf Hansson wrote: > > As far as I understand, the "performance domains" DT bindings that > > $subject patch introduces, allows us to group devices into domains, to > > let them be "performance controlled" together. Right? > > This and it also provides a reg space where we can get/set the > performance state. Right. So that can be done for power-domains too. > > > Unless I am missing something, it looks like power domains DT bindings > > already offer this for us. Yes, certainly, the DT doc [1] needs an > > updated description to better explain this, but other than that we > > should be fine, don't you think? > > I think yes we can make it work through that as well, but I am not > sure if we will be able to use required-opp n stuff here as the DT > doesn't have the OPP table for the CPUs. > > The CPU's freq table is generated at runtime, see > drivers/cpufreq/mediatek-cpufreq-hw.c for example. To me, this looks doable from a genpd provider too. Of course, we may need to extend the genpd interface a bit to make it fit well for this new use case, of course. And I am happy to help, if that is needed. One thing though; how is the aggregation of the OPP votes expected to be done? Is that entirely managed by FW - or is it expected that the cpufreq driver, in this case, keeps track of the aggregated votes too? Don't get me wrong, I am not pushing for these DT bindings to be deprecated (at least not yet :-)), but I would certainly like to understand more about them. In the end, we haven't walked this far, by extending genpd and inventing new DT bindings to enable it to support "performance management" - then just to just forget about them again. :-) Kind regards Uffe
