Message-ID: 
 <CAGwozwHUvxSY+qMVzid+0a6CoUZ96Pw1xeKMAem+1o=N23xbqg@mail.gmail.com>
Date: Sun, 7 Dec 2025 11:34:36 +0100
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Mario Limonciello <superm1@...nel.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
 Dmitry Osipenko <dmitry.osipenko@...labora.com>,
	Robert Beckett <bob.beckett@...labora.com>, linux-acpi@...r.kernel.org,
	kernel@...labora.com, linux-kernel@...r.kernel.org,
	Sebastian Reichel <sebastian.reichel@...labora.com>,
 Xaver Hugl <xaver.hugl@...il.com>,
	Richard Hughes <richard@...hsie.com>, William Jon McCann <mccann@....edu>,
	"Jaap A . Haitsma" <jaap@...tsma.org>, Benjamin Canou <bookeldor@...il.com>,
	Bastien Nocera <hadess@...ess.net>, systemd-devel@...ts.freedesktop.org,
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs
 interface

On Sun, 7 Dec 2025 at 01:31, Mario Limonciello <superm1@...nel.org> wrote:
>
>
>
> On 12/6/25 5:35 PM, Antheas Kapenekakis wrote:
> > On Sat, 6 Dec 2025 at 21:50, Mario Limonciello <superm1@...nel.org> wrote:
> >>
> >>>> I will reply to the earlier reply from Rafael with more context, but
> >>>> runtime suspend of the GPU is not part of or related to these
> >>>> notifications.
> >>>
> >>> Of course it isn't.
> >>>
> >>> What we were talking about was how to get from the "displays off, no
> >>> GUI activity" user space smoothly into system suspend and back.
> >>>
> >>> You are saying that this has been done already on AMD, so I'm not sure
> >>> why you want more.
> >>>
> >>
> >> I'm not aware this existing in any unique way for AMD.  The decision of
> >> displays off; start a timer and enter suspend would be the same for any
> >> vendor.
> >
> > AMD retains CRTC DPMS state from userspace to s0ix currently, and you
> > fixed hibernation recently too. Intel sometimes doesn't, the screen
> > will sometimes flash while entering suspend.
>
> I was talking about what Rafael said.  "What we were talking about was
> how to get from the displays off no guid activity user space smoothly
> into system suspend and back".

CRPC DPMS state is the most important user-perceptible factor in that
and it works at least.

> >
> > There is also runtime suspend on most components. Is there a case for
> > powering off the iGPU completely to improve energy use?
> >
>
> I don't really *think& there will be much of a difference.  We already
> go into GFXOFF when GC is idle, and SDMA, VCN, JPEG and VPE will be
> clock gated when not in use.
>
> Someone would have to do power profiling to see if it's significant
> enough difference to justify it.  The easiest way to check would be:
> 1) Turn off all displays
> 2) Connect over SSH
> 3) Collect a RAPL power measurement for the package.
> 4) Unbind the PCI device from amdgpu
> 5) Collect a RAPL power measurement for the package.
> 6) Compare 3 and 5.

Yes. Seems it would add complexity without much benefit from first glance.

> > The most expensive component in this process is unfreezing, then
> > runtime pm freezing the GPU IP blocks after s0ix exit, then unfreezing
> > it two seconds later to perform runtime checks and freezing it again.
> > So for multiple exits from suspend where the IP is inactive this will
> > keep repeating.
>
> I think we would set the auto-suspend delay appropriately if we did this
> and use DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME in this case.
>
> >
> >> But GPUs aren't only used for display.  If you're actively running a
> >> different workload (for example an LLM) using the GPU and happen to turn
> >> off all the displays you wouldn't want it to suspend.
> >>
> >> What you would want is to key off:
> >>
> >> 1) All displays are off.
> >> 2) All GPUs are unsused.
> >> 3) Some time has passed.
> >>
> >> I feel that if userspace is going to adopt a policy like this kernel
> >> drivers need to use runtime PM when displays are off and the GPUs aren't
> >> being used for anything else.
> >>
> >> At least for AMD this doesn't happen today and would require driver
> >> work.  But the same kind of work would be needed by any GPU driver.
> >>
> >
> > You could potentially do that, first you'd need to show that there is
> > a latency benefit to powering off the GPU over entering s0ix (as
> > userspace will be frozen in both cases for the GPU to suspend). Then,
> > you'd need to show that there is an energy benefit over just staying
> > unsuspended with userspace frozen and the GPU being in runtime
> > suspend. WIth both of these, a case could be made for powering off the
> > GPU completely for a marginal latency/energy benefit.
> >
> > These notifications do not affect runtime pm though so this discussion
> > is a bit tangential.
> >
>
> I'm not worried about the latency.  We can change the policy for the
> autosuspend delay if latency is a problem.
>
> If we added runtime suspend support to integrated GPUs this sounds like
> a really good thing to key off for that "display off notification" that
> started this whole thread.
>
> Some infrastructure could be added so DRM core could monitor runtime
> status for all GPUs on the system.  If they're all in runtime PM it
> could use an exported symbol to send LPS0 screen off and when any one of
> them exits then send LPS0 screen on.
>

But that notification is mostly used for the keyboard backlight.
Hooking it to DRM core will just cause unpredictable behavior with the
keyboard backlight (such as it turning off when reconfiguring the
displays). It is very easy to just have a little inactivity ABI for
userspace for it and avoid all of the complexity of that. Such an ABI
is backward compatible, as not using the ABI would produce the same
behavior the kernel has currently.

If not for energy efficiency, I would see a benefit in configuring
DPM_FLAG_* for certain common devices to reduce the latency of the
sleep script for resuming. That would make "dark resume" wake-ups have
less total time-span and power use.

For reducing resume latency, an important factor is for the kernel to
know that a wake-up source will "turn on the displays" where "turn on
the displays" equates to "the user initiated the wake-up and is ready
to interact with the device" and not something obscure related to DRM.
In the same way, the display on/off notifications are not related to
DRM but to whether the user is currently interacting with the device.

This is for two reasons: first, the DPMS delay for turning on a
monitor is 500ms-1s. Second, modern standby provides a firmware
notification to boost the thermal envelope of the device for user
interaction. Currently, if userspace initiates DPMS before suspend,
then the kernel will unsuspend with DPMS applied, leaving it up to
userspace to turn on the monitors. This means that the 500ms-1s delay
of resuming the monitors begins at the point userspace is unfrozen,
where it could begin when amdgpu resumes ~300ms earlier. Then, the
"intent for display to turn on" notification (which is rare-I do not
have a device with it) could marginally speed up kernel resume if it
is applied in lps0 exit, instead of e.g., a "dark resume" userspace
script 300ms later.

So there could be a potential 100ms savings there. But for that to
happen there would need to be some refactorings to classify wake-up
sources in-kernel-a substantial effort. In addition, kernel resume is
pretty light, most CPU use comes from unfreezing the fs and userspace.
Since the bulk of userspace unfreeze is now initiated by systemd, and
prior to initiating it, systemd could trigger the "intent to turn
displays on" notification/DPMS* itself, this would yield most of the
benefit.

I should note that while the "lps0 exit"->"sleep exit"->"display on"
notifications are squished together prior to resume beginning**, the
"intent to turn display on" notification which is meant to fire before
"sleep exit" so that the device looks like it is asleep while having a
boosted thermal envelope is irrelevant. "sleep exit"->"display on"
would first have to be pushed to userspace, so that userspace can wake
up in the "sleep" state, classify the wake-up source as e.g. a wake
rtc or the user interacting with the device, and only if the user is
interacting with it, fire the "intent to turn on display"
notification, unfreeze the rest of userspace, then fire "sleep exit",
"display on" together.

* For systemd to initiate DPMS, the compositor would need to be part
of the initial unfreeze and notified to resume early.

** This squishing together and firing before the kernel resumes is
a source of numerous obscure bugs in MS devices

Antheas

Powered by blists - more mailing lists