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 9 lines · Mark Brown
Quoted 8 lines · Stephen Boyd
Quoted 5 lines · Mark Brown
I can't help but think that this all sounds like the RPM isn't mapping very well onto practical systems and needs revisiting in future versions... for example with what I'm parsing out of the above an active+sleep set command or otherwise having the two modes tied together for some regulators would make the whole problem go away.
Quoted 5 lines
Quoted 2 lines
We create the 'active only' regulators for consumers that actually need them. From the set of regulators on a board only a couple need this
That's what I don't think is making any sense. Creating two regulators for the same thing seems like bad news, at best it's going to make reuse harder.
What reuse is harder?
Quoted 7 lines
Quoted 5 lines
treatment. I don't see how tying the two states together via an active+sleep set command would make this problem go away for the cases I already described before, i.e. CPU wants some voltage and other IO devices want another voltage and the CPU doesn't care what the voltage is when the CPU is
Not paying attention to requests from a disabled consumer seems like something we should be able to do in general.
Sounds good.
Quoted 8 lines
Quoted 8 lines
in idle or suspend. Having a combination active + sleep set command would be nice. The RPM already sort of supports this by allowing you to only modify the active set. If you never modify the sleep set, then the RPM just applies whatever is in the active set to the sleep set. We can probably go through and figure out what resources could get away with only using the active set so we can cut down on sleep set requests that are always the same between active and sleep set.
Quoted 6 lines
This version is starting to sound a lot like the consumers need to be able to do an idle to sleep transition and change their settings when they enter their sleep mode. It seems a lot like what many devices do now when they enter and exit runtime PM but with deferred application depending on other users (for regulators I'm assuming the active set would actually be a subset of the sleep set of valid voltages).
Yes, one key point is that we want the transition to be handled by the RPM co-processor. The reason being that usually we want to change settings after the last CPU transitions into their sleep mode. There's no way to do this without relying on some external co-processor to go and change the settings for us.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
I think any duplication that's going on sounds like a consequence of the way this is currently implemented. I think based on what I *think* you're saying the RPM driver probably ought to be hiding this and adding a property which makes the active and sleep sets track each other with normal suspend mode control otherwise. That could potentially be done in the core, though the tracking would be substantial surgery.
Quoted 6 lines
Quoted 3 lines
Sorry I don't follow this part. It's about more than suspend, we also care about idle. I agree that pushing the concept of active vs. sleep into the framework is substantial.
That's not what it seemed like people had been talking about up until this most recent e-mail, you'd been talking about suspend mode. The starting point was mapping onto the suspend support the regulator has.
Hm? I've been saying "idle and suspend" each time. Perhaps the initial discussion about regulator suspend support threw things off.
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project