linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Elliot Berman <quic_eberman@quicinc.com>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	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>
Subject: Re: [PATCH 0/3] Allow specifying an S2RAM sleep on pre-SYSTEM_SUSPEND PSCI impls
Date: Fri, 20 Dec 2024 14:36:02 +0000	[thread overview]
Message-ID: <Z2WA0o0QJS64ftVh@bogus> (raw)
In-Reply-To: <875342b7-3825-47bf-810a-effdbeacab46@oss.qualcomm.com>

On Fri, Dec 20, 2024 at 03:20:37PM +0100, Konrad Dybcio wrote:
>
> I would happen to think that, yes. Especially since the reference firmware
> implementation does *exactly this*:
>
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/psci/psci_main.c#L179-L221
>
> PSCI_SYSTEM_SUSPEND seems to be simply meant as a wrapper around a specific
> CPU_SUSPEND state (which may or may not be only callable from inside the
> firmware when SYSTEM_SUSPEND specifically is requested, for reasons),
> in a platform-agnostic way, so that the OS can enter suspend without
> providing that magic StateID on all supported platforms.

Exactly, that's how it can be OS and platform agnostic. Yet this platform
considered to optimise by not just providing it as a wrapper(if it was
that simple on your platform too) without running any tests and leaving
it to interested parties like you to mess around to get it working.
That practice needs to be fixed and this change won't help and once we
fix this, more such special treatment fixes are needed on newer platforms.
So lets stop and ensure things are fixed properly.

> But since it already requires more elbow grease on the peripheral IP side,
> I'm not really convinced it's that much useful.
>
> Plus, the optional bit of doing more work behind the scenes doesn't seem
> to be very wildly used across TF-A supported platforms.
>
> So please, stop making the argument that it's any different. The firmware
> I'm dealing with simply didn't expose the same thing twice, in perfect
> accordance with the spec.
>

So that it can continue to do so in the future ?
Thanks but no thanks. NACK with no arguments as requested.

--
Regards,
Sudeep


  reply	other threads:[~2024-12-20 15:40 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 ` [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 [this message]
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=Z2WA0o0QJS64ftVh@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=quic_eberman@quicinc.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).