From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
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.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml
index cbb012e217ab80c1ca88e611e7acc06c6d56fad0..a6901878697c8e1ec1cbfed62298ae3bc58f2501 100644
--- a/Documentation/devicetree/bindings/arm/psci.yaml
+++ b/Documentation/devicetree/bindings/arm/psci.yaml
@@ -98,6 +98,12 @@ properties:
[1] Kernel documentation - ARM idle states bindings
Documentation/devicetree/bindings/cpu/idle-states.yaml
+ arm,psci-s2ram-param:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ power_state parameter denoting the S2RAM/S3-like system suspend state
+ maxItems: 1
+
patternProperties:
"^power-domain-":
$ref: /schemas/power/power-domain.yaml#
--
2.47.0On Mon, Oct 28, 2024 at 03:22:57PM +0100, Konrad Dybcio wrote: > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > > 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. > If so, can you elaborate why s2idle doesn't work as an alternative to what you are hacking up here. > 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. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > --- > Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml > index cbb012e217ab80c1ca88e611e7acc06c6d56fad0..a6901878697c8e1ec1cbfed62298ae3bc58f2501 100644 > --- a/Documentation/devicetree/bindings/arm/psci.yaml > +++ b/Documentation/devicetree/bindings/arm/psci.yaml > @@ -98,6 +98,12 @@ properties: > [1] Kernel documentation - ARM idle states bindings > Documentation/devicetree/bindings/cpu/idle-states.yaml > > + arm,psci-s2ram-param: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: > + power_state parameter denoting the S2RAM/S3-like system suspend state Yet another NACK as this corresponds to PSCI SYSTEM_SUSPEND and as per specification it takes no such parameter. This is just misleading. -- Regards, Sudeep
On 6.12.2024 11:21 AM, Sudeep Holla wrote: > On Mon, Oct 28, 2024 at 03:22:57PM +0100, Konrad Dybcio wrote: >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >> >> 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. >> > > If so, can you elaborate why s2idle doesn't work as an alternative to what > you are hacking up here. Please see other branches of this thread > >> 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. >> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >> --- >> Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml >> index cbb012e217ab80c1ca88e611e7acc06c6d56fad0..a6901878697c8e1ec1cbfed62298ae3bc58f2501 100644 >> --- a/Documentation/devicetree/bindings/arm/psci.yaml >> +++ b/Documentation/devicetree/bindings/arm/psci.yaml >> @@ -98,6 +98,12 @@ properties: >> [1] Kernel documentation - ARM idle states bindings >> Documentation/devicetree/bindings/cpu/idle-states.yaml >> >> + arm,psci-s2ram-param: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + power_state parameter denoting the S2RAM/S3-like system suspend state > > Yet another NACK as this corresponds to PSCI SYSTEM_SUSPEND and as per > specification it takes no such parameter. This is just misleading. > Yeah PSCI_SYSTEM_SUSPEND takes care of this on platforms that expose it. DEN0022F.b Section 6.5. recommends that CPU_SUSPEND StateID includes a field for system-level power down states. This binding change only adds a way for DT-based platforms to associate such state with S2RAM suspend. That may be a bit Linux-specific whereas bindings are supposed to be OS-agnostic, but since we effectively want one PSCI state for deep suspend regardless of the OS, I would think this kind of hint is fine. Konrad
On Thu, Dec 19, 2024 at 08:43:27PM +0100, Konrad Dybcio wrote: > On 6.12.2024 11:21 AM, Sudeep Holla wrote: > > On Mon, Oct 28, 2024 at 03:22:57PM +0100, Konrad Dybcio wrote: > >> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > >> > >> 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. > >> > > > > If so, can you elaborate why s2idle doesn't work as an alternative to what > > you are hacking up here. > > Please see other branches of this thread > > > > >> 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. > >> > >> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > >> --- > >> Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml > >> index cbb012e217ab80c1ca88e611e7acc06c6d56fad0..a6901878697c8e1ec1cbfed62298ae3bc58f2501 100644 > >> --- a/Documentation/devicetree/bindings/arm/psci.yaml > >> +++ b/Documentation/devicetree/bindings/arm/psci.yaml > >> @@ -98,6 +98,12 @@ properties: > >> [1] Kernel documentation - ARM idle states bindings > >> Documentation/devicetree/bindings/cpu/idle-states.yaml > >> > >> + arm,psci-s2ram-param: > >> + $ref: /schemas/types.yaml#/definitions/uint32 > >> + description: > >> + power_state parameter denoting the S2RAM/S3-like system suspend state > > > > Yet another NACK as this corresponds to PSCI SYSTEM_SUSPEND and as per > > specification it takes no such parameter. This is just misleading. > > > > Yeah PSCI_SYSTEM_SUSPEND takes care of this on platforms that expose it. > And those that don't advertise/expose don't get to use, simple. > DEN0022F.b Section 6.5. recommends that CPU_SUSPEND StateID includes > a field for system-level power down states. This binding change only > adds a way for DT-based platforms to associate such state with S2RAM > suspend. > Sure, just use the CPU_SUSPEND bindings that already exist. No need to define this as some special case if it is exposed as CPU_SUSPEND idle state. Not sure why you want to do it differently. I understand the need to handle it different in the kernel, but I don't understand to define the new bindings for that. Just use the existing bindings for the idle states. Again I see no exception for this case. > That may be a bit Linux-specific whereas bindings are supposed to be > OS-agnostic, but since we effectively want one PSCI state for deep > suspend regardless of the OS, I would think this kind of hint is fine. > Exactly, that's the reason for not changing this into special case and special binding for that special case created. -- Regards, Sudeep
On 20.12.2024 12:27 PM, Sudeep Holla wrote: > On Thu, Dec 19, 2024 at 08:43:27PM +0100, Konrad Dybcio wrote: >> On 6.12.2024 11:21 AM, Sudeep Holla wrote: >>> On Mon, Oct 28, 2024 at 03:22:57PM +0100, Konrad Dybcio wrote: >>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >>>> >>>> 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. >>>> >>> >>> If so, can you elaborate why s2idle doesn't work as an alternative to what >>> you are hacking up here. >> >> Please see other branches of this thread >> >>> >>>> 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. >>>> >>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >>>> --- >>>> Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml >>>> index cbb012e217ab80c1ca88e611e7acc06c6d56fad0..a6901878697c8e1ec1cbfed62298ae3bc58f2501 100644 >>>> --- a/Documentation/devicetree/bindings/arm/psci.yaml >>>> +++ b/Documentation/devicetree/bindings/arm/psci.yaml >>>> @@ -98,6 +98,12 @@ properties: >>>> [1] Kernel documentation - ARM idle states bindings >>>> Documentation/devicetree/bindings/cpu/idle-states.yaml >>>> >>>> + arm,psci-s2ram-param: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + description: >>>> + power_state parameter denoting the S2RAM/S3-like system suspend state >>> >>> Yet another NACK as this corresponds to PSCI SYSTEM_SUSPEND and as per >>> specification it takes no such parameter. This is just misleading. >>> >> >> Yeah PSCI_SYSTEM_SUSPEND takes care of this on platforms that expose it. >> > > And those that don't advertise/expose don't get to use, simple. The spec says: "The call is equivalent to using the CPU_SUSPEND call for the deepest possible platform powerdown state." so by that logic, I'd rather call implementing PSCI_SYSTEM_SUSPEND in Linux unnecessary bloat.. >> DEN0022F.b Section 6.5. recommends that CPU_SUSPEND StateID includes >> a field for system-level power down states. This binding change only >> adds a way for DT-based platforms to associate such state with S2RAM >> suspend. >> > > Sure, just use the CPU_SUSPEND bindings that already exist. No need to > define this as some special case if it is exposed as CPU_SUSPEND idle > state. Not sure why you want to do it differently. I understand the > need to handle it different in the kernel, but I don't understand to > define the new bindings for that. Just use the existing bindings for the > idle states. Again I see no exception for this case. The bindings exist for core/cluster idle states. This whole series tries to include a system-wide suspend state that has no business being described as a cpuidle one and depends on more than just the CPUs being powered down. >> That may be a bit Linux-specific whereas bindings are supposed to be >> OS-agnostic, but since we effectively want one PSCI state for deep >> suspend regardless of the OS, I would think this kind of hint is fine. >> > > Exactly, that's the reason for not changing this into special case and > special binding for that special case created. I simply don't think it's fitting to lie about system suspend states being just CPU idle states, see above. Konrad
On Fri, Dec 20, 2024 at 01:54:45PM +0100, Konrad Dybcio wrote: > On 20.12.2024 12:27 PM, Sudeep Holla wrote: > > On Thu, Dec 19, 2024 at 08:43:27PM +0100, Konrad Dybcio wrote: > >> On 6.12.2024 11:21 AM, Sudeep Holla wrote: > >>> On Mon, Oct 28, 2024 at 03:22:57PM +0100, Konrad Dybcio wrote: > >>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > >>>> > >>>> 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. > >>>> > >>> > >>> If so, can you elaborate why s2idle doesn't work as an alternative to what > >>> you are hacking up here. > >> > >> Please see other branches of this thread > >> > >>> > >>>> 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. > >>>> > >>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > >>>> --- > >>>> Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++++ > >>>> 1 file changed, 6 insertions(+) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml > >>>> index cbb012e217ab80c1ca88e611e7acc06c6d56fad0..a6901878697c8e1ec1cbfed62298ae3bc58f2501 100644 > >>>> --- a/Documentation/devicetree/bindings/arm/psci.yaml > >>>> +++ b/Documentation/devicetree/bindings/arm/psci.yaml > >>>> @@ -98,6 +98,12 @@ properties: > >>>> [1] Kernel documentation - ARM idle states bindings > >>>> Documentation/devicetree/bindings/cpu/idle-states.yaml > >>>> > >>>> + arm,psci-s2ram-param: > >>>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>>> + description: > >>>> + power_state parameter denoting the S2RAM/S3-like system suspend state > >>> > >>> Yet another NACK as this corresponds to PSCI SYSTEM_SUSPEND and as per > >>> specification it takes no such parameter. This is just misleading. > >>> > >> > >> Yeah PSCI_SYSTEM_SUSPEND takes care of this on platforms that expose it. > >> > > > > And those that don't advertise/expose don't get to use, simple. > > The spec says: > > "The call is equivalent to using the CPU_SUSPEND call for the > deepest possible platform powerdown state." > Please take a look at the preconditions for both the calls. They are different. -- Regards, Sudeep
On 20.12.2024 2:55 PM, Sudeep Holla wrote: > On Fri, Dec 20, 2024 at 01:54:45PM +0100, Konrad Dybcio wrote: >> On 20.12.2024 12:27 PM, Sudeep Holla wrote: >>> On Thu, Dec 19, 2024 at 08:43:27PM +0100, Konrad Dybcio wrote: >>>> On 6.12.2024 11:21 AM, Sudeep Holla wrote: >>>>> On Mon, Oct 28, 2024 at 03:22:57PM +0100, Konrad Dybcio wrote: >>>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >>>>>> >>>>>> 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. >>>>>> >>>>> >>>>> If so, can you elaborate why s2idle doesn't work as an alternative to what >>>>> you are hacking up here. >>>> >>>> Please see other branches of this thread >>>> >>>>> >>>>>> 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. >>>>>> >>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >>>>>> --- >>>>>> Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++++ >>>>>> 1 file changed, 6 insertions(+) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml >>>>>> index cbb012e217ab80c1ca88e611e7acc06c6d56fad0..a6901878697c8e1ec1cbfed62298ae3bc58f2501 100644 >>>>>> --- a/Documentation/devicetree/bindings/arm/psci.yaml >>>>>> +++ b/Documentation/devicetree/bindings/arm/psci.yaml >>>>>> @@ -98,6 +98,12 @@ properties: >>>>>> [1] Kernel documentation - ARM idle states bindings >>>>>> Documentation/devicetree/bindings/cpu/idle-states.yaml >>>>>> >>>>>> + arm,psci-s2ram-param: >>>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>>> + description: >>>>>> + power_state parameter denoting the S2RAM/S3-like system suspend state >>>>> >>>>> Yet another NACK as this corresponds to PSCI SYSTEM_SUSPEND and as per >>>>> specification it takes no such parameter. This is just misleading. >>>>> >>>> >>>> Yeah PSCI_SYSTEM_SUSPEND takes care of this on platforms that expose it. >>>> >>> >>> And those that don't advertise/expose don't get to use, simple. >> >> The spec says: >> >> "The call is equivalent to using the CPU_SUSPEND call for the >> deepest possible platform powerdown state." >> > > Please take a look at the preconditions for both the calls. They are > different. Which is *precisely* why I want to tell the OS that it's a S2RAM state, so that different actions can be taken in peripheral device drivers. Konrad
On Fri, Dec 20, 2024 at 02:57:34PM +0100, Konrad Dybcio wrote: > On 20.12.2024 2:55 PM, Sudeep Holla wrote: > > > > Please take a look at the preconditions for both the calls. They are > > different. > > Which is *precisely* why I want to tell the OS that it's a S2RAM state, > so that different actions can be taken in peripheral device drivers. Yes we do that for SYSTEM_SUSPEND. And CPU_SUSPEND is not SYSTEM_SUSPEND hence 2 different APIs. My NACK still stands. -- Regards, Sudeep
On 20.12.2024 3:04 PM, Sudeep Holla wrote: > On Fri, Dec 20, 2024 at 02:57:34PM +0100, Konrad Dybcio wrote: >> On 20.12.2024 2:55 PM, Sudeep Holla wrote: >>> >>> Please take a look at the preconditions for both the calls. They are >>> different. >> >> Which is *precisely* why I want to tell the OS that it's a S2RAM state, >> so that different actions can be taken in peripheral device drivers. > > Yes we do that for SYSTEM_SUSPEND. And CPU_SUSPEND is not SYSTEM_SUSPEND > hence 2 different APIs. My NACK still stands. I'll just paste it here one more time to reassure you they are indeed the same under the hood https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/psci_main.c#L179-L221 Konrad
On Mon, Oct 28, 2024 at 03:22:57PM +0100, Konrad Dybcio wrote: > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > > 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. > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > --- > Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml > index cbb012e217ab80c1ca88e611e7acc06c6d56fad0..a6901878697c8e1ec1cbfed62298ae3bc58f2501 100644 > --- a/Documentation/devicetree/bindings/arm/psci.yaml > +++ b/Documentation/devicetree/bindings/arm/psci.yaml > @@ -98,6 +98,12 @@ properties: > [1] Kernel documentation - ARM idle states bindings > Documentation/devicetree/bindings/cpu/idle-states.yaml > > + 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. > patternProperties: > "^power-domain-": > $ref: /schemas/power/power-domain.yaml# > > -- > 2.47.0 >
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@oss.qualcomm.com> >> >> 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
On Mon, 28 Oct 2024 15:22:57 +0100, Konrad Dybcio wrote: > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > > 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. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > --- > Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++++ > 1 file changed, 6 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/psci.yaml: properties:arm,psci-s2ram-param:maxItems: False schema does not allow 1 hint: Scalar properties should not have array keywords from schema $id: http://devicetree.org/meta-schemas/keywords.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241028-topic-cpu_suspend_s2ram-v1-1-9fdd9a04b75c@oss.qualcomm.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
© 2016 - 2026 Red Hat, Inc.