+Ulf Hansson and +Jens Wiklander, who are able to help with testing.

Hi Sudeep and Jacky,

I wanted to clarify our use case for suspend-to-idle. For mobile and other battery-powered devices, the key capability we need isn't just the ability to enter s2idle, but also reaching equivalent power savings in s2idle compared to suspend-to-RAM. Essentially, if all CPU cores are idle, we want to be able to drop into the deepest low-power state that is just as energy-efficient as suspend-to-RAM, but without hot-unplugging and plugging the CPUs, which means they need to be able to resume in their idle loops. To achieve this, we're planning to leverage the hierarchical power domain representation in the device tree [1], which is currently limited to be used in OS-initiated mode by the PSCI CPUIdle driver [2].

Thanks!
Wing

[1] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/arm/psci.yaml#L192
[2] https://elixir.bootlin.com/linux/latest/source/drivers/cpuidle/cpuidle-psci.c#L231

On Mon, Nov 21, 2022 at 2:50 AM Jacky Bai <ping.bai@nxp.com> wrote:

suspend-to-idle normally means linux ‘freeze’ mode. For this mode, nothing related to PSCI OSI support.

BR
Jacky Bai
From: Sudeep Holla via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 2022年11月21日 18:38
To: Wing Li <wingers@google.com>
Cc: Dan Handley <Dan.Handley@arm.com>; Okash Khawaja <okash@google.com>; tf-a@lists.trustedfirmware.org; tf-a-tests@lists.trustedfirmware.org; Sudeep Holla <sudeep.holla@arm.com>
Subject: [TF-A] Re: PSCI OS-initiated mode

On Mon, Nov 21, 2022 at 2:51 AM Wing Li via TF-A <tf-a@lists.trustedfirmware.org> wrote:
Hi Dan and Varun,

Our motivation for adding OS-initiated mode is because it's required by the Linux PSCI CPUIdle driver to enable support for suspend-to-idle [1].

That is not correct. If anything is broken or not working, it needs to be fixed. Adding platform support for
OSI just to support suspend-to-idle is a completely wrong approach. Can you let me know what is not
working or how is it broken ?