From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.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>,
Lorenzo Pieralisi <lpieralisi@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>,
Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH 0/3] Allow specifying an S2RAM sleep on pre-SYSTEM_SUSPEND PSCI impls
Date: Tue, 12 Nov 2024 23:31:18 +0530 [thread overview]
Message-ID: <20241112180118.pcn7sf6r3mswwwxf@thinkpad> (raw)
In-Reply-To: <20241028-topic-cpu_suspend_s2ram-v1-0-9fdd9a04b75c@oss.qualcomm.com>
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.
I have a couple of ideas in mind that I will post to NVMe list itself.
- Mani
> [1] https://lore.kernel.org/linux-arm-kernel/20231227-topic-psci_fw_sus-v1-0-6910add70bf3@linaro.org/
> [2] https://lore.kernel.org/linux-nvme/20241024-topic-nvmequirk-v1-1-51249999d409@oss.qualcomm.com/
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> Konrad Dybcio (3):
> dt-bindings: arm,psci: Allow S2RAM power_state parameter description
> firmware/psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
> firmware/psci: Allow specifying an S2RAM state through CPU_SUSPEND
>
> Documentation/devicetree/bindings/arm/psci.yaml | 6 ++++
> drivers/firmware/psci/psci.c | 44 ++++++++++++++++++++++---
> 2 files changed, 46 insertions(+), 4 deletions(-)
> ---
> base-commit: a39230ecf6b3057f5897bc4744a790070cfbe7a8
> change-id: 20241028-topic-cpu_suspend_s2ram-28fc095d0aa4
>
> Best regards,
> --
> Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2024-11-12 18:09 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
2024-12-19 19:23 ` Konrad Dybcio
2024-11-12 18:01 ` Manivannan Sadhasivam [this message]
2024-11-12 18:32 ` [PATCH 0/3] Allow specifying an S2RAM sleep on pre-SYSTEM_SUSPEND PSCI impls 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=20241112180118.pcn7sf6r3mswwwxf@thinkpad \
--to=manivannan.sadhasivam@linaro.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=lpieralisi@kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=mark.rutland@arm.com \
--cc=robh@kernel.org \
--cc=sudeep.holla@arm.com \
/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