On 12/5/25 1:37 PM, Rafael J. Wysocki wrote:
On Fri, Dec 5, 2025 at 7:07 PM Mario Limonciello <[email protected]> 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)
<[email protected]> 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.
I feel if this state is to exist in the Linux state machine this should
be DRM core entering it when displays are off.
