RFC Qualcomm RPM sleep states
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC 0/2] Qualcomm RPM sleep states
Quoted 16 lines · Mark Brown
Quoted 9 lines · Bjorn Andersson
Quoted 8 lines · Stephen Boyd
Quoted 2 lines · Mark Brown
I think I now have a reasonable picture of what's going on but wanted to confirm that what I'm saying above makes sense.
That's good. Is there any conclusion here? I'm still thinking that having multiple regulators for the same physical supply is the right thing to do.
I'm still not finding it easy to find this tasteful.
Quoted 2 lines
As I said, the only other idea I've come up with will not cut it for the regulators that need more than enable/disable support when going to sleep.
Quoted 9 lines
Quoted 4 lines
Even if we came up with some model of exposing something similar to the suspend state, we would still need to expose it in a way that we can specify which (active/sleep/both) state in the consumer. Hence in practice we end up with exposing multiple regulators in one way or another.
Now I'm confused again. I thought entry and exit was all done separately so it was just about saying what should happen if the device were to idle?
But how do you actually expose that control to the consumers?
Quoted 10 lines
Quoted 5 lines
I can't help thinking that this would be a problem with the static suspend settings as well; i.e. what is the static suspend state for a regulator that powers a WiFi chip? For me the answer would often be "it's enabled iff the WiFi consumer asks for it" - but maybe it's not supposed to be used for "dynamic" regulators.
That's what should happen, we just don't currently really support doing this configuration dynamically (practically speaking I suspect anyone who cares just doesn't have a suspend mode for affected regulators at the minute).
What would such configuration look like?
In the suspend case you could introduce an api for setting parameters of the suspend state, but that means that the individual drivers needs to be written with awareness of the system state. Our proposal is to use the same api, but with a different regulator*, but how should that acquired (and expressed in dt).
In our case, as most things change the both state (or active only if no 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?
Regards,
Bjorn