From: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Marijn Suijten <marijn.suijten@somainline.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Subject: Re: [PATCH 3/3] firmware/psci: Allow specifying an S2RAM state through CPU_SUSPEND
Date: Wed, 13 Nov 2024 13:57:23 +0100 [thread overview]
Message-ID: <ZzSiM6Pn6A9e1QUD@lpieralisi> (raw)
In-Reply-To: <20241028-topic-cpu_suspend_s2ram-v1-3-9fdd9a04b75c@oss.qualcomm.com>
On Mon, Oct 28, 2024 at 03:22:59PM +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.
>
> This works exactly like SYSTEM_SUSPEND. The PSCI spec describes that
> call as optional (and only introduced in PSCIv1.0), so not all
> platforms expose it.
>
> Marking a DT-described "domain-idle-state" as such isn't currently
> well accounted for in the PSCI idle topology infrastructure: the
> cpuidle and genpd framework are deeply intertwined, and trying to
> separate them would cause more havoc than good.
I don't understand what you mean here please elaborate.
The part of the story I understand is that you have a system (well,
firmware for an extended set of systems) that does not implement
SYSTEM_SUSPEND but can reach a S2R like system state through the
CPU_SUSPEND call. Firmware works in OS-initiated mode, idle-states
should allow you to define idle states that allow the system to
enter the S2R state through CPUidle.
Please explain to me what's missing.
> Instead, allow the specifying of a single CPU_SUSPEND sleep param
> under the /psci node that shall be treated exactly like SYSTEM_SUSPEND
> from Linux's POV. As a bonus, this way we also don't have to fight
> with the genpd idle governor to avoid taking the S3-like state into
> consideration.
That's not acceptable. I want to understand what's preventing this
system to enter that state through suspend2idle and the mainline code.
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> drivers/firmware/psci/psci.c | 36 +++++++++++++++++++++++++++++++-----
> 1 file changed, 31 insertions(+), 5 deletions(-)
NACK
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 0e622aa5ad58bbe69dfc3a71bced597618e73f15..20ae6a6d59a9f276db75260b6ca1a5827e443782 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -78,6 +78,7 @@ struct psci_0_1_function_ids get_psci_0_1_function_ids(void)
>
> static u32 psci_cpu_suspend_feature;
> static bool psci_system_reset2_supported;
> +static u32 psci_s2ram_suspend_param;
>
> static inline bool psci_has_ext_power_state(void)
> {
> @@ -519,10 +520,10 @@ static int psci_system_suspend_begin(suspend_state_t state)
> return 0;
> }
>
> -static const struct platform_suspend_ops psci_suspend_ops = {
> - .valid = suspend_valid_only_mem,
> - .enter = psci_system_suspend_enter,
> - .begin = psci_system_suspend_begin,
> +static const struct platform_suspend_ops psci_system_suspend_ops = {
> + .valid = suspend_valid_only_mem,
> + .enter = psci_system_suspend_enter,
> + .begin = psci_system_suspend_begin,
> };
>
> static void __init psci_init_system_reset2(void)
> @@ -545,7 +546,7 @@ static void __init psci_init_system_suspend(void)
> ret = psci_features(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND));
>
> if (ret != PSCI_RET_NOT_SUPPORTED)
> - suspend_set_ops(&psci_suspend_ops);
> + suspend_set_ops(&psci_system_suspend_ops);
> }
>
> static void __init psci_init_cpu_suspend(void)
> @@ -673,6 +674,17 @@ static int __init psci_probe(void)
>
> typedef int (*psci_initcall_t)(const struct device_node *);
>
> +static int psci_cpu_suspend_s2ram_enter(suspend_state_t state)
> +{
> + return psci_cpu_suspend_enter(psci_s2ram_suspend_param);
> +}
> +
> +static const struct platform_suspend_ops psci_cpu_suspend_s2ram_ops = {
> + .valid = suspend_valid_only_mem,
> + .enter = psci_cpu_suspend_s2ram_enter,
> + .begin = psci_system_suspend_begin,
> +};
> +
> /*
> * PSCI init function for PSCI versions >=0.2
> *
> @@ -686,6 +698,20 @@ static int __init psci_0_2_init(const struct device_node *np)
> if (err)
> return err;
>
> + /*
> + * Some firmwares expose S2RAM entry through a custom suspend param.
> + *
> + * If found, register a suspend handler instead of registering the
> + * idle state with cpuidle.
> + */
> + err = of_property_read_u32(np, "arm,psci-s2ram-param", &psci_s2ram_suspend_param);
> + if (!err) {
> + suspend_set_ops(&psci_cpu_suspend_s2ram_ops);
> + } else if (err != -EINVAL) {
> + pr_err("Couldn't read the S2RAM PSCI suspend param: %d\n",
> + psci_s2ram_suspend_param);
> + }
> +
> /*
> * Starting with v0.2, the PSCI specification introduced a call
> * (PSCI_VERSION) that allows probing the firmware version, so
>
> --
> 2.47.0
>
next prev parent reply other threads:[~2024-11-13 13:00 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 14:22 [PATCH 0/3] Allow specifying an S2RAM sleep on pre-SYSTEM_SUSPEND PSCI impls Konrad Dybcio
2024-10-28 14:22 ` [PATCH 1/3] dt-bindings: arm,psci: Allow S2RAM power_state parameter description Konrad Dybcio
2024-10-28 17:09 ` Rob Herring (Arm)
2024-11-13 12:43 ` Lorenzo Pieralisi
2024-12-05 20:08 ` Konrad Dybcio
2024-12-06 10:21 ` Sudeep Holla
2024-12-19 19:43 ` Konrad Dybcio
2024-12-20 11:27 ` Sudeep Holla
2024-12-20 12:54 ` Konrad Dybcio
2024-12-20 13:55 ` Sudeep Holla
2024-12-20 13:57 ` Konrad Dybcio
2024-12-20 14:04 ` Sudeep Holla
2024-12-20 14:21 ` Konrad Dybcio
2024-10-28 14:22 ` [PATCH 2/3] firmware/psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND Konrad Dybcio
2024-10-28 14:22 ` [PATCH 3/3] firmware/psci: Allow specifying an S2RAM state through CPU_SUSPEND Konrad Dybcio
2024-11-13 12:57 ` Lorenzo Pieralisi [this message]
2024-12-06 10:24 ` Sudeep Holla
2024-12-19 19:23 ` Konrad Dybcio
2024-11-12 18:01 ` [PATCH 0/3] Allow specifying an S2RAM sleep on pre-SYSTEM_SUSPEND PSCI impls Manivannan Sadhasivam
2024-11-12 18:32 ` Konrad Dybcio
2024-11-12 18:43 ` Manivannan Sadhasivam
2024-11-12 19:04 ` Konrad Dybcio
2024-11-13 8:05 ` Manivannan Sadhasivam
2024-12-19 19:20 ` Konrad Dybcio
2024-11-14 1:10 ` Elliot Berman
2024-12-19 19:26 ` Konrad Dybcio
2024-12-20 11:39 ` Sudeep Holla
2024-12-20 12:42 ` Konrad Dybcio
2024-12-20 13:58 ` Sudeep Holla
2024-12-20 14:20 ` Konrad Dybcio
2024-12-20 14:36 ` Sudeep Holla
2024-12-20 14:57 ` Konrad Dybcio
2024-11-14 15:30 ` Ulf Hansson
2024-12-05 20:34 ` Konrad Dybcio
2024-12-06 9:53 ` Ulf Hansson
2024-12-19 19:37 ` Konrad Dybcio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZzSiM6Pn6A9e1QUD@lpieralisi \
--to=lpieralisi@kernel.org \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=mark.rutland@arm.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).