Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms

[Antheas Kapenekakis]

On Sat, 21 Mar 2026 at 19:43, Mario Limonciello <superm1@xxxxxxxxxx> wrote:
>
>
>
> 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 very
> >>>>>>>>> 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).
> >>>>>>>> Hm, most of the changes / implementation resides in the pm subsystem
> >>>>>>>> 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.

I wouldn't call platform_profile ACPI either, but it just kind of
ended up there. Where would be a better position for it?

Antheas