On Mon, Oct 28, 2024 at 03:22:56PM +0100, Konrad Dybcio wrote:
Certain firmwares expose exactly what PSCI_SYSTEM_SUSPEND does through
CPU_SUSPEND instead. Inform Linux about that.
Please see the commit messages for a more detailed explanation.
It is still not PSCI_SYSTEM_SUSPEND though...
This is effectively a more educated follow-up to [1].
The ultimate goal is to stop making Linux think that certain states
only concern cores/clusters, and consequently setting
pm_set_suspend/resume_via_firmware(), so that client drivers (such as
NVMe, see related discussion over at [2]) can make informed decisions
about assuming the power state of the device they govern.
If this series gets green light, I'll push a follow-up one that wires
up said sleep state on Qualcomm SoCs across the board.
Sorry. I don't think PSCI is the right place for this. Qcom SoCs have a common
firmware across all segments (mostly),
so there is no S2R involved and only S2Idle.
If you use PSCI to implement suspend_via_firmware(), then all the SoCs
making use of the PSCI implementation will have the same behavior. I don't think
we would want that.
For instance, if a Qcom SoC is used in an android tablet with the same firmware,
then this would allow the NVMe device to be turned off during system suspend all
the time when user presses the lock button. And this will cause NVMe device to
wear out faster. The said approach will work fine for non-android usecases
though.