Re: [PATCH 0/4] Broadcom STB PM PSCI extensions

From: Florian Fainelli
Date: Thu Feb 03 2022 - 12:36:35 EST




On 2/3/2022 3:14 AM, Sudeep Holla wrote:
On Fri, Jan 21, 2022 at 07:54:17PM -0800, Florian Fainelli wrote:
Hi all,

This patch series contains the Broadcom STB PSCI extensions which adds
some additional functions on top of the existing standard PSCI interface
which is the reason for having the driver implement a custom
suspend_ops.

These platforms have traditionally supported a mode that is akin to
ACPI's S2 with the CPU in WFI and all of the chip being clock gated
which is entered with "echo standby > /sys/power/state". Additional a
true suspend to DRAM as defined in ACPI by S3 is implemented with "echo
mem > /sys/power/state".

How different is the above "standby" state compare to the standard "idle"
(a.k.a suspend-to-idle which is different from system-to-ram/S3) ?

There are a few differences:

- s2idle does not power gate the secondary CPUs

- s2idle requires the use of in-band interrupts for wake-up

The reasons for implementing "standby" are largely two fold:

- we need to achieve decent power savings (typically below 0.5W for the whole system while allowing Wake-on-WLAN, GPIO, RTC, infrared, etc.)

- we have a security subsystem that requires the CPUs to be either power gated or idle in order the hardware state machine that lets the system enter such a state and allows the out of band interrupts from being wake-up sources


Suspend to idle takes all the CPUs to lowest possible power state instead
of cpu-hotplug in S2R. Also I assume some userspace has to identify when
to enter "standby" vs "mem" right ? I am trying to see how addition of
"idle" changes that(if it does). Sorry for too many questions.


Right that user-space in our case is either custom (like RDK, or completely custom), or is Android. For Android it looks like we are carrying a patch that makes "mem" de-generate into "standby" but this is largely because we had historically problems with "mem" that are being addressed (completely orthogonal).

I did not consider it as a viable option at the time, but if we were to implement "standby" in drivers/firmware/psci/psci.c would that be somewhat acceptable?
--
Florian