On Thu, 5 Nov 2020 at 11:40, Viresh Kumar viresh.kumar@linaro.org wrote:
On 05-11-20, 11:34, Ulf Hansson wrote:
I am not objecting about scaling the voltage through a regulator, that's fine to me. However, encoding a power domain as a regulator (even if it may seem like a regulator) isn't. Well, unless Mark Brown has changed his mind about this.
In this case, it seems like the regulator supply belongs in the description of the power domain provider.
Okay, I wasn't sure if it is a power domain or a regulator here. Btw, how do we identify if it is a power domain or a regulator ?
Good question. It's not a crystal clear line in between them, I think.
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. If there are operating points involved, that's also a clear indication to me, that it's not a regular regulator.
Maybe we should try to specify this more exactly in some documentation, somewhere.
In case of Qcom earlier (when we added the performance-state stuff), the eventual hardware was out of kernel's control and we didn't wanted (allowed) to model it as a virtual regulator just to pass the votes to the RPM. And so we did what we did.
But if the hardware (where the voltage is required to be changed) is indeed a regulator and is modeled as one, then what Dmitry has done looks okay. i.e. add a supply in the device's node and microvolt property in the DT entries.
I guess I haven't paid enough attention how power domain regulators are being described then. I was under the impression that the CPUfreq case was a bit specific - and we had legacy bindings to stick with.
Can you point me to some other existing examples of where power domain regulators are specified as a regulator in each device's node?
No, I thought it is a regulator here and not a power domain.
Okay, thanks!
Kind regards Uffe