On 17/04/17 06:27, Viresh Kumar wrote: > On 13-04-17, 14:42, Sudeep Holla wrote: >> What I was referring is about power domain provider with multiple power >> domains(simply #power-domain-cells=<1> case as explained in the >> power-domain specification. > > I am not sure if we should be looking to target such a situation for now, as > that would be like this: > > Device controlled by Domain A. Domain A itself is controlled by Domain B and > Domain C. > No, may be I was not so clear. I am just referring a power controller that provides say 3 different power domains and are indexed 0 - 2. The consumer just passes the index along with the phandle for the power domain info. > Though we will end up converting the domain-performance-state property to an > array if that is required in near future. > OK, better to document that so that we know how to extend it. We have #power-domain-cells=<1> on Juno with SCPI. >> Yes. To simplify what not we just have power-domain for a device and >> change state of that domain to change the performance of that device. > > Consider this case to understand what I have in Mind. > > The power domain have its states as A, B, C, D. There can be multiple devices > regulated by that domain and one of the devices have its power states as: A1, > A2, A3, B1, B2, B3, C1, C2, C3, D1, D2, D3 and all these states have different > frequency/voltages. > > IOW, the devices can have regulators as well and may want to fine tune within > the domain performance-state. > Understood. I would incline towards reusing regulators we that's what is changed behind the scene. Calling this operating performance point is misleading and doesn't align well with existing specs/features. >> Then put this in the hierarchy. Some thing similar to what we already >> have with new domain-idle states. In that way, we can move any >> performance control to the domain and abstract the clocks and regulators >> from the devices as the first step and from the OSPM view if there's >> firmware support. >> >> If we are looking this power-domains with performance as just some >> *advanced regulators*, I don't like the complexity added. > > In the particular case I am trying to solve (Qcom), we have some sort of > regulators which are only programmed by a M3 core. The M3 core needs integer > numbers representing state we want the domain to be in and it will put the > regulators (or whatever) in a particular state. > Understood. We have exactly same thing with SCPI but it controls both frequency and voltage referred as operating points. In general, this OPP terminology is used in SCPI/ACPI/SCMI specifications as both frequency and voltage control. I am bit worried that this binding might introduce confusions on the definitions. But it can be reworded/renamed easily if required. -- Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
