RFC Qualcomm RPM sleep states

At the point then the consumer decides that it does not need the regulator it's in atomic context. So the regulator core and driver would need to handle this. Further more the regulator driver uses a packet-based protocol over a shared memory channel, so this entire path would have to be invoked in atomic context.

We have to put the consumer into a state where we can "release" the regulator, then we need to tell the RPM to update the state of the regulator and we have to wait for the ack to come back before we can actually go idle.

Quoted 5 lines

What this is *now* sounding like is that we need a way to say that this one consumer is magic and we want to essentially tell the hardware about settings with and without that consumer then the hardware will magically switch between the two when the consumer is enabled and disabled. Does that sound about right?

I think it sounds spot on.

Quoted 2 lines

We already have a runtime API for specifying suspend state. It doesn't currently aggregate but that's a simple matter of programming.

Do you mean alter properties of a state or select between the predefined states? I've found some apis related to the latter, but not the first.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

both/sleep), the standard regulator api would have to affect the both state. Would we then have a separate api to modify the active state?

Why would we need to introduce a new API for the active state?

Quoted 4 lines

Quoted 2 lines

It's just that I, possibly incorrectly, considered that to be the outlier and the one that would be the easiest to model separately.

I'm sorry, I'm just not getting this at all.

Because for the overall system the active state is the outlier here. But it probably doesn't matter for our conclusions.

Quoted 5 lines

I really do fear that the bodge you're using at the minute with multiple regulators has poor abstraction and is hence too fragile - it seems like there's too much knowledge of the system spread around different drivers and it's all vulnerable to changes in system integration which could potentially be made per board.

Just to make sure we're on the same page here, the way this is expressed in downstream is like the following:

ldo12 {
	l12: l12 {

	l12_active: l12-active {

All the consumers uses the standard regulator accessor functions to operate on their respective regulator *. Further more it's only the clock driver for the core (krait) that references the active only regulators.

So the knowledge spread out would be contained to the dt bindings things together.

What I don't like with that solution is that we above have two different rdev and that we need to aggregate state between the various rdevs in the ldo12 grouping. (so that active only and both actually affect the active state).