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 2 lines · Stephen Boyd
Quoted 1 line · Mark Brown
On Thu, Nov 27, 2014 at 11:42:41AM -0800, Bjorn Andersson wrote:
[..]
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
The exposure of multiple regulators moves the problem to the devicetree, making sure to map the consumers to the right state/regulator. But it should only be the cpu (in its various forms) that ever consume the active only regulator.
He said hopefully... :)
:)
Quoted 8 lines
Quoted 3 lines
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.
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.
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.
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.
Nontheless, we have reached conclusions regarding my RFC. So I'll move on and finish up a multi-regulator implementation and we can continue the discussion based on that.
Regards,
Bjorn