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

M. Bergo
2025-04-27T18:35:02Z

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?