From: Sudeep Holla <sudeep.holla@arm.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Konrad Dybcio <konradybcio@kernel.org>,
Rob Herring <robh@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
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: Fri, 6 Dec 2024 10:24:19 +0000 [thread overview]
Message-ID: <Z1LQ0-3AVkVHgPaY@bogus> (raw)
In-Reply-To: <ZzSiM6Pn6A9e1QUD@lpieralisi>
On Wed, Nov 13, 2024 at 01:57:23PM +0100, Lorenzo Pieralisi wrote:
> 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
>
+1, will wait for the response here before adding any more questions that
may lead to more confusion or discussion churn.
--
Regards,
Sudeep
next prev parent reply other threads:[~2024-12-06 10:45 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
2024-12-06 10:24 ` Sudeep Holla [this message]
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=Z1LQ0-3AVkVHgPaY@bogus \
--to=sudeep.holla@arm.com \
--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=lpieralisi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.