Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms
From: Mario Limonciello
Date: Sat Mar 21 2026 - 14:44:30 EST
On 3/21/26 8:52 AM, Antheas Kapenekakis wrote:
On Sat, 21 Mar 2026 at 14:46, Antheas Kapenekakis <lkml@xxxxxxxxxxx> wrote:
On Fri, 20 Mar 2026 at 21:41, Mario Limonciello (AMD) (kernel.org)
<superm1@xxxxxxxxxx> wrote:
On 3/19/2026 7:35 AM, Antheas Kapenekakis wrote:
On Tue, 17 Mar 2026 at 16:13, Mario Limonciello
<mario.limonciello@xxxxxxx> wrote:
On 3/17/26 07:09, Rafael J. Wysocki wrote:
On Tue, Mar 17, 2026 at 12:57 PM Dmitry Osipenko
<dmitry.osipenko@xxxxxxxxxxxxx> wrote:
On 3/16/26 22:52, Antheas Kapenekakis wrote:
So in accordance with the above, /sys/power/standby is not a veryHm, most of the changes / implementation resides in the pm subsystem
fortunate choice of the name of this interface and I'm totally
unconvinced that it belongs to sys/power because its role is not
really power management (and it is ACPI-only for the time being).
and it is related to the s2idle suspend flow.
I assume that when it stops being ACPI only provided we reach a design
that allows for that, the related callbacks would also nest in pm ops.
Where could a more appropriate directory in sysfs be? I would still
tend towards /sys/power
Question is whether anyone outside of ACPI will ever need the generic
interface. Making it generic based on guesswork could be a wasted effort
that Rafael and others will have to maintain. The mode file could go
under /sys/firmware/acpi if interface is made ACPI-specific.
Well, experience shows that it may end up the other way around.
People once thought that the platform profile interface would be
ACPI-specific and we ended up having to extend it via
platform_profile_class.
I'm thinking that something similar may take place in this case.
Platforms that don't use ACPI may also want to define platform
triggers to somehow adjust platform settings and those may be
different from "inactive" or "snooze".
At which point you would almost wonder if this should be super general
like "foreground_workload_type".
Then this could be expanded for other uses later such as full screen
video playback or full screen gaming.
Mmm. This reminds me of AMD drm pp_power_profile_mode {BOOTUP_DEFAULT,
3D_FULL_SCREEN, POWER_SAVING, VIDEO, VR, COMPUTE, CUSTOM, WINDOW_3D,
CAPPED, UNCAPPED}. I'm not sure anyone used it. I'd rather avoid the
complexity.
There are certainly people using it, but it's more common in embedded
applications than traditional desktop distros.
It is not a perfect match to this concept, but definitely some parallels
can be drawn.
There are general things that might make sense if you know what the
foreground workload is or the display is off.
Hm, yeah I guess so. I could see this ABI being also useful for
embedded devices to control their appearance. There's precedent with
e.g., charging_behaviour having dozens of device specific values,
where standard and longevity are the only ones used in laptops.
There could be hooks for scheduler too in the future from this hint too
then.
Wouldn't it be better to defer to userspace? I'm not sure this would
have a meaningful difference in any case.
I don't know one way or the other. It would need to be prototyped to
see what it actually looked like. In the line of thinking Rafael
mentioned that platform profile was ACPI and grew to a class I would
generally just keep the design from pigeon holing too much on display
off. That's why I thought maybe foreground workload could potentially
work well.
To go back to Rafael's suggestion of not using transitions for the
ABI, it would be possible to push the transition logic down to the
s2idle code and introduce a generic handler for it. SInce arbitrary
transitions are possible under this spec, the top-level ABI
implementation need not consider it.
Since it is very similar to platform_profiles, it could also be
potentially added there as activity_hint to the current
platform_profiles implementation and mirror its conventions. This
would avoid introducing new scaffolding.
Then s2idle would register a platform profile handler without
profiles, and instead only implement activity hint. Existing x86
platform drivers could also trivially implement support for it as
well. Although for WMI, the existing hooks for s2idle for Windows
would handle most current drivers.
An implementation for this would consist of two stages. First, the
callbacks would be moved to the beginning so they can be tested
independently. Then, platform_profile would be extended to support
activity_hint with states {snooze, resuming, inactive, active}, and
finally, s2idle would implement the handler with transition logic to
make sure the callbacks get called correctly always, including when
userspace ignores the file, where the full transition would occur in
begin() and end().
The legacy /sys/firmware/acpi/{activity_hint, activity_hint_choices}
would mirror the current conventions, perhaps with a custom value as
well.
How does this approach sound?
Perhaps re-using platform_profiles is not wise, after all the
boilerplate would be small and bolting on new hooks would be around
the same amount of code. New implementation would be better. How would
that approach sound like.
Antheas
I really don't want our top level interface for this thing to end up in /sys/firmware/acpi. The concept of system posture, or foreground workload, or whatever we call it isn't an ACPI concept. It might have direct implications for an ACPI implementation (IE the calling of this _DSM) but there is no reason we can't have a non-ACPI implementation too with the right knobs.