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 4 lines · Stephen Boyd
This sleep set/active set stuff has to do with more than just regulators. It applies to any resource that the RPM provides, but regulators are a primary use case so you're on Cc and it would be great if you fully understood the regulator aspect here.
Step back: what is the RPM? Some kind of power management coprocessor from the sounds of it?
Correct, it's a coprocessor that does the actual poking of the PMIC.
To each processor in the SoC it exposes a set of resources, e.g. regulators. Each resource is represented by two set of properties, the active and the sleep state sets. The selection between the two state sets are basically controlled by the CPU being in WFI (wait-for-interrupt) or not.
The qcom_rpm-regulator.c (and rfc for qcom_smd-regulator.c) that we have in the tree only pokes the active state and we end up leaving certain regulators as always-on; due to the fact that we're clocked off PLLs powered by them.
To further complicate matters these regulators are also used to power peripherals, so enable is not 1:1 with WFI, but rather depends on other consumers.
My proposal was to flag these regulators so that we write the active/sleep states in a way that they will be turned off on WFI, iff the regulator isn't enabled. But as Stephen pointed out, this might not be enough.
Regards,
Bjorn