From: "Mario Limonciello (AMD) (kernel.org)" <superm1@kernel.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
Antheas Kapenekakis <lkml@antheas.dev>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
Robert Beckett <bob.beckett@collabora.com>,
linux-acpi@vger.kernel.org, kernel@collabora.com,
linux-kernel@vger.kernel.org,
Sebastian Reichel <sebastian.reichel@collabora.com>,
Xaver Hugl <xaver.hugl@gmail.com>,
Richard Hughes <richard@hughsie.com>,
William Jon McCann <mccann@jhu.edu>,
"Jaap A . Haitsma" <jaap@haitsma.org>,
Benjamin Canou <bookeldor@gmail.com>,
Bastien Nocera <hadess@hadess.net>,
systemd-devel@lists.freedesktop.org,
Lennart Poettering <lennart@poettering.net>
Subject: Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs interface
Date: Fri, 5 Dec 2025 10:46:59 -0600 [thread overview]
Message-ID: <a0d91fa6-bf95-4bbb-a4f9-9d8cceae5543@kernel.org> (raw)
In-Reply-To: <CAJZ5v0i63EwNxaYU8S9W5a3jpzQtCNxTH+0hsjO_xLf_wXd1Qw@mail.gmail.com>
> 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).
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.
> 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.
next prev parent reply other threads:[~2025-12-05 16:47 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-02 4:34 [RFC PATCH v1 0/1] ACPI: s2idle: Add /sys/power/lps0_screen_off Dmitry Osipenko
2025-12-02 4:34 ` [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs interface Dmitry Osipenko
2025-12-02 4:43 ` Mario Limonciello (AMD) (kernel.org)
2025-12-02 5:26 ` Dmitry Osipenko
2025-12-02 9:32 ` Antheas Kapenekakis
2025-12-02 14:23 ` Mario Limonciello
2025-12-02 15:17 ` Antheas Kapenekakis
2025-12-02 21:25 ` Mario Limonciello (AMD) (kernel.org)
2025-12-02 22:35 ` Dmitry Osipenko
2025-12-03 2:12 ` Mario Limonciello (AMD) (kernel.org)
2025-12-03 6:46 ` Dmitry Osipenko
2025-12-03 10:12 ` Antheas Kapenekakis
2025-12-03 14:34 ` Mario Limonciello
2025-12-03 14:46 ` Antheas Kapenekakis
2025-12-02 21:59 ` Dmitry Osipenko
2025-12-03 14:58 ` Rafael J. Wysocki
2025-12-04 15:03 ` Dmitry Osipenko
2025-12-04 16:41 ` Rafael J. Wysocki
2025-12-04 18:31 ` Antheas Kapenekakis
2025-12-05 16:32 ` Rafael J. Wysocki
2025-12-05 16:46 ` Mario Limonciello (AMD) (kernel.org) [this message]
2025-12-05 17:22 ` Rafael J. Wysocki
2025-12-05 18:07 ` Mario Limonciello
2025-12-05 19:37 ` Rafael J. Wysocki
2025-12-05 19:42 ` Mario Limonciello
2025-12-05 20:06 ` Rafael J. Wysocki
2025-12-05 21:52 ` Antheas Kapenekakis
2025-12-06 14:34 ` Rafael J. Wysocki
2025-12-06 20:50 ` Mario Limonciello
2025-12-06 23:35 ` Antheas Kapenekakis
2025-12-07 0:31 ` Mario Limonciello
2025-12-07 10:34 ` Antheas Kapenekakis
2025-12-05 22:51 ` Antheas Kapenekakis
2025-12-07 11:06 ` Rafael J. Wysocki
2025-12-07 11:19 ` Rafael J. Wysocki
2025-12-07 11:50 ` Antheas Kapenekakis
2025-12-09 22:13 ` Dmitry Osipenko
2025-12-09 22:22 ` Antheas Kapenekakis
2025-12-09 22:23 ` Rafael J. Wysocki
2025-12-07 11:42 ` Antheas Kapenekakis
2025-12-05 13:34 ` [RFC PATCH v1 0/1] ACPI: s2idle: Add /sys/power/lps0_screen_off Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a0d91fa6-bf95-4bbb-a4f9-9d8cceae5543@kernel.org \
--to=superm1@kernel.org \
--cc=bob.beckett@collabora.com \
--cc=bookeldor@gmail.com \
--cc=dmitry.osipenko@collabora.com \
--cc=hadess@hadess.net \
--cc=jaap@haitsma.org \
--cc=kernel@collabora.com \
--cc=lennart@poettering.net \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@antheas.dev \
--cc=mccann@jhu.edu \
--cc=rafael@kernel.org \
--cc=richard@hughsie.com \
--cc=sebastian.reichel@collabora.com \
--cc=systemd-devel@lists.freedesktop.org \
--cc=xaver.hugl@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox