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

[Mario Limonciello]

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@xxxxxxxxx>
> > 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
> > Reported-by: Mark Pearson <mark.pearson@xxxxxxxxxx>
> > Signed-off-by: Marcus Bergo <marcusbergo@xxxxxxxxx>
>
> 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-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?