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 7 lines · Mark Brown
Quoted 6 lines · Bjorn Andersson
Quoted 5 lines · Mark Brown
Quoted 2 lines
* we don't want to waste the time of making sending out the request
* we have hardware support for this and we want to use it(?)I'm still hazy on what that actually means. I thought the CPU case was one of the big ones where you *did* want to act on the configuration changes?
Quoted 7 lines
Quoted 3 lines
By utilising the hardware support for switching between active and sleep state (and having the cpu only affecting the active state) we can do this asynchronously, while being in wfi.
Hrm, right. This is starting to make sense. So what we're saying here is roughly that you want to use a separate suspend-like mode (the extra set of registers for the low power mode mode) but are entering it without actually suspending the whole system?
For the idle path, yes. We also want to do the same sort of thing on the system suspend path.
Quoted 13 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
In the case of us having other active consumers (e.g. GPU, display or some peripherals) the voltage range or operating mode specified by the cpufreq driver might be suboptimal when we remove the cpu.
I don't understand. Why is the other consumer asking for something it doesn't need itself?
Quoted 7 lines
I don't have the actual numbers, but we have a situation that looks like this:
gpu driver doesregulator_set_voltage(.5V, 1V);
cpufreq driver doesregulator_set_voltage(1V,1V);
The regulator framework will make the regulator tick at 1V
Upon going to sleep the cpuidle driver will, through the hardware support, make the regulator tick at .5V. Before returning the cpu from idle the hardware will make the regulator tick at 1V again.
Quoted 3 lines
So the regulator framework should be fine if the CPU regulator constraint was disabled while the CPU consumer was disabled (modulo the performance issue)?
The CPU regulator consumer won't be disabled through any software mechanism. It will stay enabled in software and when we execute wfi the hardware will drop that consumers request because it was only requesting in the active set.
Quoted 13 lines
Quoted 9 lines
Quoted 3 lines
If you're hiding it in the driver make sure it's *hidden* in the driver
- exporting duplicate regulators doesn't sound like hiding to me.This is the problem at hand, we have not found any way to actually hide this in the driver as the two modes depend on the consumer and not the aggregated values we get out of the regulator framework. Or rather, my proposal would do that, but that will not be able to handle the case when there's different voltages in the two states. It would only take care of the enable/disable case.
So, I think something along the lines of suspend mode ought to be able to handle this. What we need is a way of accelerating the entry and exit, right?
Quoted 8 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... :)
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.
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project