From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Luke Jones <luke@ljones.dev>
Cc: Hans de Goede <hdegoede@redhat.com>,
corentin.chary@gmail.com, platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 8/9] platform/x86: asus-wmi: Add support for MCU powersave
Date: Wed, 3 Apr 2024 11:31:14 +0300 (EEST) [thread overview]
Message-ID: <42f09e54-5669-2242-28db-240405e7c4bc@linux.intel.com> (raw)
In-Reply-To: <24071185.4csPzL39Zc@fedora>
[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]
On Wed, 3 Apr 2024, Luke Jones wrote:
> On Wednesday, 3 April 2024 12:01:15 AM NZDT Ilpo Järvinen wrote:
> > On Tue, 2 Apr 2024, Luke D. Jones wrote:
> > > Add support for an MCU powersave WMI call. This is intended to set the
> > > MCU in to a low-power mode when sleeping. This mode can cut sleep power
> > > use by around half.
> > >
> > > Signed-off-by: Luke D. Jones <luke@ljones.dev>
> >
> > Hi,
> >
> > I fail to follow the logic of the patch here. This patch makes it
> > configurable which is not bad in itself but what is the reason why a user
> > would not always want to cut sleep power usage down? So this sounds like a
> > feature that the user wants always enabled if available.
> >
> > So what are the downsides of enabling it if it's supported?
>
> Honestly, I'm not sure. Previously it was a source of issues but with recent
> bios and more work in the various gaming-handheld distros it's much less of a
> problem. The issue before was that the MCU would appear every second suspend
> due to the suspend sequence being more parallel compared to windows being
> sequential - the acpi calls related to this would "unplug" the USB devices
> that are related to the n-key (keyboard, same internal dev as laptops) and not
> complete it before suspend. And then on resume it was unreliable.
>
> I worked around this by calling the unplug very early, and trying to "plug"
> super early also so that subsystems wouldn't notice the absence of the device
> and create new devices + paths on add. Most of the requirement for that came
> from some userspace programs unable to handle the unplug/plug part, but also
> bad device state occurring.
>
> But now with the forced wait for the device to finish its task, and then the
> forced wait before letting it add itself back everything is fine - although it
> does mean everything sees a device properly unplugged and plugged.
>
> All of the above is to say that the "powersave" function was also part of the
> issue as delayed things further and we couldn't add the device back before
> subsystems noticed.
>
> Distros like bazzite and chimeraOS are now using this patch, and I'd like to
> leave it to them to set a default for now. If it turns out everything is
> indeed safe as houses then we can adjust the kernel default.
>
> A side-note I think is that because there is a forced wait time due to unable
> to use the right acpi path, the old excuse of "but users might want the device
> to wake faster by turning off powersave" doesn't really apply now.
>
> I will discuss with the main stakeholders, but for now can we accept as is? If
> changes are required we'll get them done before the merge window.
Yes, I think it is okay to make it configurable first and then look
separately into making it default on.
--
i.
next prev parent reply other threads:[~2024-04-03 8:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-02 2:25 [PATCH v2 0/9] asus-wmi: add new features, clean up, fixes Luke D. Jones
2024-04-02 2:25 ` [PATCH v2 1/9] platform/x86: asus-wmi: add support for 2024 ROG Mini-LED Luke D. Jones
2024-04-02 10:43 ` Ilpo Järvinen
2024-04-02 23:59 ` Luke Jones
2024-04-02 2:26 ` [PATCH v2 2/9] platform/x86: asus-wmi: add support for Vivobook GPU MUX Luke D. Jones
2024-04-02 10:44 ` Ilpo Järvinen
2024-04-02 2:26 ` [PATCH v2 3/9] platform/x86: asus-wmi: add support variant of TUF RGB Luke D. Jones
2024-04-02 10:45 ` Ilpo Järvinen
2024-04-02 2:26 ` [PATCH v2 4/9] platform/x86: asus-wmi: support toggling POST sound Luke D. Jones
2024-04-02 10:47 ` Ilpo Järvinen
2024-04-03 0:06 ` Luke Jones
2024-04-02 2:26 ` [PATCH v2 5/9] platform/x86: asus-wmi: store a min default for ppt options Luke D. Jones
2024-04-02 10:49 ` Ilpo Järvinen
2024-04-03 0:09 ` Luke Jones
2024-04-03 8:21 ` Ilpo Järvinen
2024-04-02 2:26 ` [PATCH v2 6/9] platform/x86: asus-wmi: adjust formatting of ppt-<name>() functions Luke D. Jones
2024-04-02 10:51 ` Ilpo Järvinen
2024-04-02 2:26 ` [PATCH v2 7/9] platform/x86: asus-wmi: ROG Ally increase wait time, allow MCU powersave Luke D. Jones
2024-04-02 2:26 ` [PATCH v2 8/9] platform/x86: asus-wmi: Add support for " Luke D. Jones
2024-04-02 11:01 ` Ilpo Järvinen
2024-04-02 23:30 ` Luke Jones
2024-04-03 8:31 ` Ilpo Järvinen [this message]
2024-04-02 2:26 ` [PATCH v2 9/9] platform/x86: asus-wmi: cleanup main struct to avoid some holes Luke D. Jones
2024-04-02 11:02 ` Ilpo Järvinen
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=42f09e54-5669-2242-28db-240405e7c4bc@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=corentin.chary@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luke@ljones.dev \
--cc=platform-driver-x86@vger.kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).