On Thu, 5 Nov 2020 at 12:13, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > On 05-11-20, 11:56, Ulf Hansson wrote: > > On Thu, 5 Nov 2020 at 11:40, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > > Btw, how do we identify if it is a power domain or a regulator ? > > To be honest, I was a bit afraid and embarrassed to ask this question, > and was hoping people to make fun of me in return :) > > > Good question. It's not a crystal clear line in between them, I think. > > And I was relieved after reading this :) > > > A power domain to me, means that some part of a silicon (a group of > > controllers or just a single piece, for example) needs some kind of > > resource (typically a power rail) to be enabled to be functional, to > > start with. > > Isn't this what a part of regulator does as well ? i.e. > enabling/disabling of the regulator or power to a group of > controllers. It could, but it shouldn't. > > Over that the regulator does voltage/current scaling as well, which > normally the power domains don't do (though we did that in > performance-state case). > > > If there are operating points involved, that's also a > > clear indication to me, that it's not a regular regulator. > > Is there any example of that? I hope by OPP you meant both freq and > voltage here. I am not sure if I know of a case where a power domain > handles both of them. It may be both voltage and frequency - but in some cases only voltage. >From HW point of view, many ARM legacy platforms have power domains that work like this. As you know, the DVFS case has in many years not been solved in a generic way, but mostly via platform specific hacks. The worst ones are probably those hacking clock drivers (which myself also have contributed to). Have a look at clk_prcmu_opp_prepare(), for example, which is used by the UX500 platform. Another option has been to use the devfreq framework, but it has limitations in regards to this too. That said, I am hoping that people start moving towards the deploying/implementing DVFS through the power-domain approach, together with the OPPs. Maybe there are still some pieces missing from an infrastructure point of view, but that should become more evident as more starts using it. > > > Maybe we should try to specify this more exactly in some > > documentation, somewhere. > > I think yes, it is very much required. And in absence of that I think, > many (or most) of the platforms that also need to scale the voltage > would have modeled their hardware as a regulator and not a PM domain. > > What I always thought was: > > - Module that can just enable/disable power to a block of SoC is a > power domain. > > - Module that can enable/disable as well as scale voltage is a > regulator. > > And so I thought that this patchset has done the right thing. This > changed a bit with the qcom stuff where the IP to be configured was in > control of RPM and not Linux and so we couldn't add it as a regulator. > If it was controlled by Linux, it would have been a regulator in > kernel for sure :) In my view, DT bindings have consistently been pushed back during the year, if they have tried to model power domains as regulator supplies from consumer device nodes. Hence, people have tried other things, as I mentioned above. I definitely agree that we need to update some documentations, explaining things more exactly. Additionally, it seems like a talk at some conferences should make sense, as a way to spread the word. Kind regards Uffe _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
