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
On Mon, Dec 29, 2014 at 01:54:55PM -0800, Bjorn Andersson wrote:
Could you please fix your mailer to wrap sufficiently far before 80 characters to allow for some quoting?
Quoted 16 lines · Mark Brown
Quoted 7 lines · Bjorn Andersson
Quoted 4 lines
Are you suggesting that we introduce a shadow of the current API for the purpose of affecting a certain state? Can you elaborate on how that would look like and work?
Like the current APIs but specifying a state?
So then we have two choices:
1) We make the standard API affect both our states and use the special api to affect only the active state. Which doesn't seem completely unreasonable to implement as we only have one special consumer and the aggregation in the driver is trivial.
Quoted 4 lines
2) We make the "run queue empty" the special state and in e.g. the display driver (DSI) we have to pair every regulator api call with a call to the special version. So suddenly we have riddled drivers with "knowledge" about how cpuidle works on these platforms (but not all).
I think there's more options than that but whatever...
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
Does "running Linux" indicate that there's instructions flowing through the CPU pipeline or that the hardware overall is up and running?
I think that for most practical purposes with Android (which is the interesting thing here) those are very much the same?
While Android is not the single usecase that we have to consider it's an excellent example of the opposite.
Quoted 8 lines
Take e.g. a Nexus 5, hit the power button to "wake it up" sitting in lockscreen. You will now have
pm8941_ldo12requested enabled by the display core (DSI) and the CPU PLLs. When the run queue empties out the display will be kept on but the CPU no longer need ldo12. (And it might sit there for the next 15 seconds - or whatever timeout you have)So I don't know which one is statistically more common, but both are very common to be in.
So, a couple of things here. One is that unless the system leakages are
truly spectacular I'd expect nobody is going to notice a practical
impact from leaving the CPU PLL LDO on while the display is on given
that in an idle display state the display will tend to dominate the
system power consumption, making it all a bit academic. If you can run
the CPU without the PLL for low power but long term tasks that's more
interesting but a different problem. The other is that you're thinking
of the common state as being the one that is running most whereas I'm
thinking of it as being the one that we have to work with the most - I'd
expect that we're going to be making more changes to the state while
we're actively running than we will be adjusting the state we're going
to go into on idle.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141230/224da6da/attachment.sig>