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

[Mario Limonciello <mario.limonciello@amd.com>]

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>
>> 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@lenovo.com>
>> Signed-off-by: Marcus Bergo <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-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?