Re: [PATCH] ACPI: EC: Fix CPU frequency limitation on AMD platforms after suspend/resume

Rafael J. Wysocki
2025-04-28T19:02:17Z

On Mon, Apr 28, 2025 at 8:23 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
> On 4/28/2025 4:51 AM, Marcus Bergo wrote:
> > Yes, it does.
> >
>
> OK thanks for confirming. Considering your finding with this patch
> you've shared and knowing there is a timing dependency that delaying the
> next s2idle cycle helps I do wonder if we should keep exploring.
>
> Rafael, do you have thoughts here? Specifically do you think it's worth
> revisiting if b5539eb5ee70 was the correct move.

Well, it was done for a reason that is explained in its changelog. I
think that the problem addressed by it is genuine, isn't it?

> > On Sun, Apr 27, 2025 at 11:06 PM Mario Limonciello
> > <mario.limonciello@amd.com <mailto:mario.limonciello@amd.com>> wrote:
> >
> > On 4/27/2025 1:34 PM, M. Bergo wrote:
> > > It does make it work fine for me, I saw the clock/timing
> > interference
> > > and this sane this problem for Lenovo as well.
> >
> > Huh? I think you have a typo; but I don't know what you actually meant.
> >
> > So you're saying the timing patch helps your system as well?
> >
> > Thanks,
> >
> > >
> > > On 4/24/25 11:11 AM, Mario Limonciello wrote:
> > >> On 4/19/2025 1:03 PM, Mario Limonciello wrote:
> > >>> On 4/19/2025 4:28 AM, M. Bergo wrote:
> > >>>> From 881e57c87b9595c186c2ca7e6d35d0a52c1a10c2 Mon Sep 17
> > 00:00:00 2001
> > >>>> From: Marcus Bergo <marcusbergo@gmail.com
> > <mailto:marcusbergo@gmail.com>>
> > >>>> Date: Sat, 19 Apr 2025 05:19:05 -0300
> > >>>> Subject: [PATCH] ACPI: EC: Fix CPU frequency limitation on AMD
> > >>>> platforms after
> > >>>> suspend/resume
> > >>>>
> > >>>> Several AMD-based laptop models (Lenovo P15v Gen 3, P16v Gen
> > 1, HP
> > >>>> EliteBook 845 G10)
> > >>>> experience a CPU frequency limitation issue where the
> > processor gets
> > >>>> stuck at
> > >>>> approximately 544MHz after resuming from suspend when the
> > power cord
> > >>>> is unplugged
> > >>>> during sleep. This issue makes the systems practically unusable
> > >>>> until a full
> > >>>> power cycle is performed.
> > >>>>
> > >>>> The root cause was traced to commit b5539eb5ee70 ("ACPI: EC: Fix
> > >>>> acpi_ec_dispatch_gpe()") which restored the behavior of
> > clearing the
> > >>>> GPE
> > >>>> in acpi_ec_dispatch_gpe() function to prevent GPE storms.
> > While this
> > >>>> fix is
> > >>>> necessary for most platforms to prevent excessive power
> > consumption
> > >>>> during
> > >>>> suspend-to-idle, it causes problems on certain AMD platforms by
> > >>>> interfering
> > >>>> with the EC's ability to properly restore power management
> > settings
> > >>>> after resume.
> > >>>>
> > >>>> This patch implements a targeted workaround that:
> > >>>> 1. Adds DMI-based detection for affected AMD platforms
> > >>>> 2. Adds a function to check if we're in suspend-to-idle mode
> > >>>> 3. Modifies the acpi_ec_dispatch_gpe() function to handle AMD
> > >>>> platforms specially:
> > >>>> - For affected AMD platforms during suspend-to-idle, it
> > advances
> > >>>> the
> > >>>> transaction without clearing the GPE status bit
> > >>>> - For all other platforms, it maintains the existing
> > behavior of
> > >>>> clearing
> > >>>> the GPE status bit
> > >>>>
> > >>>> Testing was performed on a Lenovo P16v Gen 1 with AMD Ryzen 7 PRO
> > >>>> 7840HS and
> > >>>> confirmed that:
> > >>>> 1. Without the patch, the CPU frequency is limited to 544MHz
> > after the
> > >>>> suspend/unplug/resume sequence
> > >>>> 2. With the patch applied, the CPU properly scales up to its
> > maximum
> > >>>> frequency
> > >>>> (5.1GHz) after the same sequence
> > >>>> 3. No regressions were observed in other EC functionality
> > (battery
> > >>>> status,
> > >>>> keyboard backlight, etc.)
> > >>>> 4. Multiple suspend/resume cycles with different power states
> > were
> > >>>> tested
> > >>>> without issues
> > >>>>
> > >>>> The patch was also verified not to affect the behavior on Intel-
> > >>>> based systems,
> > >>>> ensuring that the GPE storm prevention remains effective where
> > needed.
> > >>>>
> > >>>> Fixes: b5539eb5ee70 ("ACPI: EC: Fix acpi_ec_dispatch_gpe()")
> > >>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218557
> > <https://bugzilla.kernel.org/show_bug.cgi?id=218557>
> > >>>> Reported-by: Mark Pearson <mark.pearson@lenovo.com
> > <mailto:mark.pearson@lenovo.com>>
> > >>>> Signed-off-by: Marcus Bergo <marcusbergo@gmail.com
> > <mailto:marcusbergo@gmail.com>>
> > >>>
> > >>> Great finding with this being a potential root cause of this
> > behavior
> > >>> (at least from a Linux perspective).
> > >>>
> > >>> Although this helps, I'm not really a fan of the tech debt
> > >>> accumulated by needing to quirk this on a system by system
> > basis as a
> > >>> bandage.
> > >>>
> > >>> At least for HP someone said that this commit happens to help them
> > >>> for the same issue you're describing:
> > >>>
> > >>> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-
> > <https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform->
> > >>> drivers- x86.git/commit/?
> > >>> h=fixes&id=9f5595d5f03fd4dc640607a71e89a1daa68fd19d
> > >>>
> > >>> That was surprising to me, but it must be changing the timing
> > of some
> > >>> of the code running in HP's EC. Since you happen to have a Lenovo
> > >>> system does it happen to help the Lenovo EC too?
> > >>>
> > >>> Mark, comments please?
> > >>>
> > >> Someone just reported that the timing delay patch helped their
> > Lenovo
> > >> system as well. Can you see if it helps you too?
> >
> >
> >
> > --
> >
> >
> > *
> > *
> > *
> > Marcus Bergo*
>
>