Re: [PATCH 1/2] PM / Domains: Introduce domain-performance-state binding

[Viresh Kumar]

On 29-11-16, 17:08, Stephen Boyd wrote:
> Perhaps. One question is if we consider a shared regulator as a
> regulator in the kernel, or if we want to hide the regulator
> behind some other API that aggregates the users of the voltage. I
> don't see how to draw the line clearly between a regulator and a

Neither do I :)

> power domain that modifies a regulator underneath. It seems like
> everything that's using a regulator on the SoC could be using a
> power domain instead and then we could be aggregating the voltage
> requirements outside of the regulator APIs.

If I am not wrong the regulator API chooses an intersection instead of the max
requested voltage and so it may not fit very well in the use-case we are trying
to solve.

> The only other way I can think of doing it is by having the
> voltages in the OPP tables for each device. That gets sort of
> messy though because all the devices calling
> regulator_set_voltage() have to set the min voltage to be their
> required voltage and the max to be the global max voltage on the
> system. Otherwise a higher voltage may not be used while it may
> be required. Of course, we could encode that as the last value in
> the triplet and everything works.

Where will we get the performance levels in this case ?

> What do we do if the device is part of multiple domains? For
> example it may be part of two power domains for different pieces
> of the silicon within one device, and we may want to
> independently control those domains depending on the clock
> frequency.

I thought the best way to handle would be to add a virtual domain for such a
device. That domain shall be responsible for changing its parent based on the
performance level selected, and at that point only the recalculations for both
the parents should happen to select the new best performance level.

@Rob / Kevin: Do you have any inputs on the things we are discussing here? I
want to involve you guys as early as possible, or we will come back to this
again :(

-- 
viresh