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 · Bjorn Andersson
Quoted 7 lines · Mark Brown
Quoted 5 lines · Bjorn Andersson
Quoted 2 lines
We already have a runtime API for specifying suspend state. It doesn't currently aggregate but that's a simple matter of programming.
Do you mean alter properties of a state or select between the predefined states? I've found some apis related to the latter, but not the first.
Quoted 7 lines
Quoted 3 lines
Hrm, indeed. Well, duplicating the existing APIs seems like a good way forwards - the logic is all the same, it's just that we don't want to apply the changes to the state used at runtime.
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?
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Because for the overall system the active state is the outlier here. But it probably doesn't matter for our conclusions.
I'd argue that for the purpose of running Linux it's the common state...
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?
Quoted 8 lines
Quoted 3 lines
It's not just the DT binding, it's also the regulator driver that needs to do the aggregation that's being discussed and is going to assume a particular arrangement of clients.
The downstream implementation sports 3 rdevs per regulator and their requests are aggregated into the two states. So the regulator implementation are not aware of the individual clients, it just aggregates the 3 rdev states and programs the hardware accordingly.
To me doing that aggregation requires some knowledge.
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
What I don't like with that solution is that we above have two different rdev and that we need to aggregate state between the various rdevs in the ldo12 grouping. (so that active only and both actually affect the active state).
Yes, that's a big part of the problem - there's things going on that the core should know about but doesn't.
The way that the aggregation of these properties works there's no problems doing it in stages. But it comes with code duplication and the need of the various rdevs to share common state.
To me both the sharing of state and the code duplication are problems.
-------------- 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/20141226/4b243377/attachment.sig>