Re: [RFC v1 0/8] acpi/x86: s2idle: Introduce and implement runtime standby ABI for ACPI s0ix platforms

[Dmitry Osipenko <dmitry.osipenko@collabora.com>]

Hi, Antheas

On 3/17/26 14:04, Dmitry Osipenko wrote:
> On 3/16/26 22:36, Antheas Kapenekakis wrote:
>> On Mon, 16 Mar 2026 at 20:33, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>>>
>>> On Mon, 16 Mar 2026 at 20:03, Dmitry Osipenko
>>> <dmitry.osipenko@collabora.com> wrote:
>>>>
>>>> Hi Antheas,
>>>>
>>>> On 1/15/26 10:49, Antheas Kapenekakis wrote:
>>>>> On Thu, 15 Jan 2026 at 01:07, Dmitry Osipenko
>>>>> <dmitry.osipenko@collabora.com> wrote:
>>>>>>
>>>>>> On 1/13/26 13:11, Antheas Kapenekakis wrote:
>>>>>>> <snip>
>>>>>
>>>>> Hi Dmitry,
>>>>> let me go inline.
>>>>>
>>>>>> The primary goal is to support screen-off DSM for a power-efficient
>>>>>> background games downloading [1] and further resume-to-dark on Steam
>>>>>> Deck and other handhelds. There is no strict timeline, usual "sooner the
>>>>>> better". Downstreams will use customized WIP solution till upstream will
>>>>>> get necessary generic interfaces.
>>>>>>
>>>>>> [1] https://store.steampowered.com/news/app/1675200/view/771930569635267984
>>>>>
>>>>> Ok, this makes things clearer. I had done some testing to see the
>>>>> viability of such approach.
>>>>>
>>>>> One big problem [1] had was that the compression algorithm that Steam
>>>>> used was very CPU intensive. However, it was announced that that
>>>>> changed, which makes low power downloads more viable.
>>>>>
>>>>> However, even so, I do not think the sleep DSM is designed for
>>>>> prolonged background use and certain devices might overheat.
>>>>> Specifically, I think the Go S disables its fan while in that DSM.
>>>>> Looking back to what Windows does, it only uses the Sleep state to do
>>>>> periodic polling, and if there are updates it transitions to display
>>>>> off.
>>>>>
>>>>> This is a fair approach for [1]. For example, device wakes up every
>>>>> two hours while connected to a charger, stays on sleep state, checks
>>>>> for updates, and if there are any and conditions are met, transitions
>>>>> to display off and starts downloading.
>>>>>
>>>>> However, this means you do not get a smaller tdp limit. Given you
>>>>> control the unfrozen userspace in that state though, such a limit does
>>>>> not help either. The device will use what it needs to for downloads.
>>>>> This makes the SD 5W low power mode puzzling, as it means downloads
>>>>> will potentially take longer and I would be punished as a user for
>>>>> using that mode. Instead, Steam should be optimized to use less than
>>>>> 5W or perhaps 10W when downloading from gigabit in some way.
>>>>>
>>>>> Two more considerations in this case are that a lot of devices will
>>>>> turn off their controllers when entering display off. And the rest
>>>>> when entering sleep. This is good because when you are in dark resume,
>>>>> the RGB of the device has turned off. But for [1] it is problematic
>>>>> because it assumes the controller works and is what is used to wake
>>>>> the device so the mode is broken. For Legion, Sleep is used to turn
>>>>> off the controller, and for other devices Sleep Entry/Exit. New in ROG
>>>>> Xbox Ally devices is that the controller no longer turns off, but it
>>>>> is muted.
>>>>>
>>>>> The other consideration is that three additional patches are needed
>>>>> for ROG Ally devices to work correctly with this series, 2 cleanup
>>>>> commits and 1 small delay. But after that it should be drop in. I
>>>>> cannot comment on the new hid drivers for Asus and Legion that are
>>>>> currently being developed. Particularly, hid-legion-go(?) has a
>>>>> reset_resume() cb where it should have used resume? Or not anything?
>>>>> The legion controllers save os mode until they disconnect, which they
>>>>> do with this series, so the driver would always re-initialize on
>>>>> wake-up.
>>>>
>>>> My rough understanding that a firmware/BIOS update may be needed for
>>>> some devices to leverage DSM in regards to power consumption
>>>> improvement. Could be true that practically it may not improve much,
>>>> will see. Even if not all current devices will benefit from the
>>>> screen-off DSM, it may differ for a later generations.
>>>
>>> Hi Dmitry,
>>> sorry, I have been busy the past few days. I read through Rafael's
>>> comments, I will respond to them in the next 2-3 days.
>>>
>>> Your understanding is correct. You will see 0 performance difference
>>> with the screen off DSM. It is not supposed to affect the thermal
>>> envelope. Turning off the screens of your laptop due to inactivity is
>>> not supposed to affect the thermal envelope.
>>>
>>> For devices that use the DSM to turn off their controller (~60%),
>>> there might be a marginal <.5W improvement. The rest use the sleep
>>> DSMs for that. Those do affect the thermal envelope. However, they are
>>> not designed for prolonged CPU intensive tasks such as a SteamOS
>>> download mode. This is the bigger concern. From my experience, I
>>> expect the Go S to overheat.
>>>
>>> The improvement because of turning off the controllers / RGB is
>>> something that is needed for download mode in any case. And as my
>>> previous comment suggests, lowering the thermal limit may not be
>>> required / advantageous.
>>
>> Here, the sleep dsms are also important, because of their broad
>> effects to power light / thermal envelope. As they can be used for
>> brief wake / update checks. For battery powered devices, perhaps these
>> are not important (excl. hibernation checks), but for desktop consoles
>> it is expected functionality.
>>
>>>>>> A common approach for upstreaming is to divide problem into smaller
>>>>>> manageable parts. That's what I'm planning to focus on now to see if we
>>>>>> can start easy with a minimal changes.
>>>>>
>>>>> Sure. One potential approach for this is this series, where the first
>>>>> part does the plumbing and the second part the exposing. They can be
>>>>> merged independently.
>>>>>
>>>>> I also made sure to address Rafael's comments, so the ABI of this
>>>>> series is completely independent of ACPI, S0ix or whether the device
>>>>> has a display. I also removed all references to Intel, AMD specific
>>>>> power envelope terminology. Moreover, most of the logic now resides in
>>>>> suspend.c and the hooks are in platform_ calls, so it can be
>>>>> implemented for other platforms easily.
>>>>>
>>>>> However, the first part of this series does some refactorings which
>>>>> assume a favorable outcome. If we do not want to assume that, a
>>>>> simpler initial series would just move the MS/display on/off DSMs to
>>>>> .begin() in s2idle.c. If you think that would be easier to merge, you
>>>>> are welcome to start with that. Then this series would be refactored
>>>>> on top and merged as a single unit. Keep in mind the ROG Ally conflict
>>>>> would also arise in this case as well.
>>>>>
>>>>>> Please don't worry about the credit. You did a significant ground work
>>>>>> that is well recognized by now. Thanks a lot for your efforts and help.
>>>>>> Starting from scratch of course won't be a good approach with all the
>>>>>> broad testing you've done.
>>>>>
>>>>> Great. Sounds good to me.
>>>>
>>>> I'm taking latest version of your patches and will update them in
>>>> accordance to the review from Rafael.
>>>
>>> Rafael raised some good questions I need to respond to. Specifically,
>>> the ABI is not yet decided, so the comments are not ready to address
>>> yet.
>>>
>>> Nonetheless, this series is ready to test with the current ABI.
>>>
>>> Moreover, Rafael suggests for upstreaming to follow essentially what I
>>> outlined. An initial series should move the DSMs to the beginning of
>>> the suspend sequence, and the follow-up would implement the ABI.
>>>
>>> I was planning to work on the first sub-series as a non-RFC after
>>> responding to Rafael's comments. Let me know how you plan to proceed.
> 
> Please go on and make a v2. This version works well with my testing. Thanks!

Do you have updates on v2? For now I don't have good suggestion on where
to put and how to define standby knobs in sysfs in a more generic
manner. Pick what feels better or keep current /sys/power variant with
the rest of review comments addressed.

Please let me know if help needed,

-- 
Best regards,
Dmitry