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

["M. Bergo" <marcusbergo@gmail.com>]

It does make it work fine for me, I saw the clock/timing interference 
and this sane this problem for Lenovo as well.

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>
>>> 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?