On 13.11.2024 1:43 PM, Lorenzo Pieralisi wrote: > On Mon, Oct 28, 2024 at 03:22:57PM +0100, Konrad Dybcio wrote: >> From: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> >> >> Certain firmware implementations (such as the ones found on Qualcomm >> SoCs between roughly 2015 and 2023) expose an S3-like S2RAM state >> through the CPU_SUSPEND call, as opposed to exposing PSCIv1.0's >> optional PSCI_SYSTEM_SUSPEND. >> >> This really doesn't work well with the model where we associate all >> calls to CPU_SUSPEND with cpuidle. Allow specifying a single special >> CPU_SUSPEND suspend parameter value that is to be treated just like >> SYSTEM_SUSPEND from the OS's point of view. > > For the records, the info above is not relevant. > > These are generic firmware bindings for PSCI specifications - how CPUidle > is implemented in Linux must play no role here. [...] >> + arm,psci-s2ram-param: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + power_state parameter denoting the S2RAM/S3-like system suspend state >> + maxItems: 1 > > NACK > > This is nothing that has ever been specified in the PSCI specifications, > see above. Thankfully, neither do dt-bindings have to be limited by any software specifications, nor is this a Linux specific problem. This is simply non-discoverable firmware interface description, and DT is the expected information provider here. The TZ exposes a way for the platform to enter S3, through a call that is usually not used to do this nowadays, but well allowed by the specification, even after PSCI1.x. This property lets the OS know what to pass to said firmware to request S2RAM entry. Section 6.5. of the PSCI design document recommends that within the StateID magic value, a section is dedicated to system-wide (not cluster or core) power states of "retention" or "powerdown". It also makes an appearance in Section 4.2. in a more general fashion. Konrad
