Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs interface

[Mario Limonciello <superm1@kernel.org>]

On 12/5/25 1:37 PM, Rafael J. Wysocki wrote:
> On Fri, Dec 5, 2025 at 7:07 PM Mario Limonciello <superm1@kernel.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@kernel.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.

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