On 4/27/2025 1:34 PM, M. Bergo wrote:
It does make it work fine for me, I saw the clock/timing interference
and this sane this problem for Lenovo as well.
Huh? I think you have a typo; but I don't know what you actually meant.
So you're saying the timing patch helps your system as well?
Thanks,
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@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?
