Message-ID: <106bd256-2c08-463f-8498-b68f2d5ccaca@amd.com>
Date: Thu, 24 Apr 2025 09:11:21 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: "M. Bergo" <marcusbergo@...il.com>, mark.pearson@...ovo.com
Cc: linux-acpi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
 rafael@...nel.org, lenb@...nel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ACPI: EC: Fix CPU frequency limitation on AMD platforms
 after suspend/resume

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

Powered by blists - more mailing lists