On Fri, Dec 5, 2025 at 8:42 PM Mario Limonciello <[email protected]> wrote: > > 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.
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.
