Message-ID: <CAJZ5v0jqdQw57t7Moj4o2eWt54t1wBvn8_0N9L-orn_JzFGWyw@mail.gmail.com>
Date: Fri, 5 Dec 2025 21:06:03 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Mario Limonciello <superm1@...nel.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Antheas Kapenekakis <lkml@...heas.dev>, 
	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 Fri, Dec 5, 2025 at 8:42 PM Mario Limonciello <superm1@...nel.org> wrote:
>
> On 12/5/25 1:37 PM, Rafael J. Wysocki wrote:
> > On Fri, Dec 5, 2025 at 7:07 PM Mario Limonciello <superm1@...nel.org> wrote:
> >>
> >> On 12/5/25 11:22 AM, Rafael J. Wysocki wrote:
> >>> On Fri, Dec 5, 2025 at 5:47 PM Mario Limonciello (AMD) (kernel.org)
> >>> <superm1@...nel.org> wrote:
> >>>>
> >>>>> I would start with the graphics stacks and teach them to
> >>>>> runtime-suspend the HW when the displays go off.  No firmware
> >>>>> notifications are needed for this to work.
> >>>>
> >>>> Well the problem with this is there is a sizable latency to runtime
> >>>> suspend hardware when displays go off.  For example you would need to
> >>>> redo link training when you spin the hardware back up.
> >>>>
> >>>> What we do today (AMD *dGPU* centric) is runtime suspend the hardware
> >>>> when no displays are connected and nothing else is using the GPU (for
> >>>> offload purposes).
> >>>
> >>> The latency problem can be addressed by using autosuspend instead of
> >>> synchronous suspend.  Just set the autosuspend timer when displays go
> >>> off.
> >>
> >> Sorry I probably confused the problem by saying latency to suspend the
> >> hardware.  That doesn't matter.  It's a problem of latency when they
> >> *come back up*.  Let me give a hypothetical that will demonstrate.
> >>
> >> Let's say I have the following:
> >> * Desktop with a dGPU connected to it.
> >> * My DE has a setting for compositor to blank the monitor after 5 minutes.
> >> * My DE has a setting to starting system suspend after 10 minutes.
> >> * You set up auto-suspend on the dGPU for 15 seconds.
> >> * No non-display work running.
> >>
> >> You walk away for 6 minutes.  The dGPU will have entered runtime PM from
> >> the auto-suspend.  You come back to the machine and you wiggle the
> >> mouse.  Because the dGPU was auto-suspended you gotta wait for it to
> >> spin back up, you have to wait for link training again etc.
> >
> > Yes.
> >
> >> This is pretty much the same that would have happened if you walked away
> >> for 10 minutes now!  Your "5 minute blank monitor" turned into "5 minute
> >> turn off dGPU".
> >
> > Well, the wakeup latency is the cost of saving energy.
> >
> >>>
> >>>> On AMD APU we don't use runtime suspend.  If you ignore the latency I
> >>>> could see an argument for proxying the status of displays to indicate
> >>>> runtime suspended, but I don't know what it really buys you.
> >>>
> >>> Well, the lack of runtime PM is a problem and I don't see how it can
> >>> be overcome easily.
> >>>
> >>> The main issue is that when the system is resuming and there is no
> >>> runtime PM support, the device in question must be powered up during
> >>> the system resume flow.
> >>
> >> I don't think this is actually a problem.  The reason is in my below
> >> comment.
> >>
> >>>
> >>>>> Then, I would teach
> >>>>> graphics drivers to leave the devices in runtime-suspend if they are
> >>>>> runtime-suspended when system suspend starts and to leave them in
> >>>>> runtime-suspend throughout the system suspend and resume, so they are
> >>>>> still runtime-suspended whey system resume is complete.  I'm not sure
> >>>>> how far away graphics stacks are from this, but at least some of them
> >>>>> support runtime PM, so maybe the fruits don't hang very high.  With
> >>>>> that, you'd just need a way to trigger a system suspend after a period
> >>>>> of inactivity when the displays are off and you have your "dark mode".
> >>>>
> >>>> I think even without kernel changes this can be accomplished today with
> >>>> userspace.
> >>>>
> >>>> There will be change events when the displays are turned off and you can
> >>>> listen to and set a timer to enter system suspend based upon how long
> >>>> they are off.
> >>>
> >>> True, but that's just about suspending.  To avoid powering up devices
> >>> on the way back from system suspend, runtime PM support and
> >>> integration of it with system suspend-resume is necessary.
> >>
> >> Yes and no.  For most device types I would agree; but the compositor
> >> controls DPMS on each CRTC which impacts whether anything is displayed.
> >>
> >> If the compositor chooses to turn off the displays the GPU hardware will
> >> remain active but display IP will be off or in a low power state.  This
> >> will still have significant power savings by the displays being off.
> >
> > OK, so you basically want the GPU to avoid turning displays on during
> > resume from system suspend if they were off before the suspend
> > transition has started.  This still needs to be handled by the GPU
> > driver in the kernel IIUC.
>
> Yes.  To be clear (in case you didn't see from my comments in this
> thread) I'm not a fan of this being a userspace interface to the LPS0
> screen off.

So we agree here, good.

> I feel if this state is to exist in the Linux state machine this should
> be DRM core entering it when displays are off.

Something like that.

Powered by blists - more mailing lists