On Mon, Apr 28, 2025 at 8:23 PM Mario Limonciello <mario.limonciello@xxxxxxx> wrote: > > On 4/28/2025 4:51 AM, Marcus Bergo wrote: > > Yes, it does. > > > > OK thanks for confirming. Considering your finding with this patch > you've shared and knowing there is a timing dependency that delaying the > next s2idle cycle helps I do wonder if we should keep exploring. > > Rafael, do you have thoughts here? Specifically do you think it's worth > revisiting if b5539eb5ee70 was the correct move. Well, it was done for a reason that is explained in its changelog. I think that the problem addressed by it is genuine, isn't it? > > On Sun, Apr 27, 2025 at 11:06 PM Mario Limonciello > > <mario.limonciello@xxxxxxx <mailto:mario.limonciello@xxxxxxx>> wrote: > > > > 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 > > <mailto: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 > > <https://bugzilla.kernel.org/show_bug.cgi?id=218557> > > >>>> Reported-by: Mark Pearson <mark.pearson@xxxxxxxxxx > > <mailto:mark.pearson@xxxxxxxxxx>> > > >>>> Signed-off-by: Marcus Bergo <marcusbergo@xxxxxxxxx > > <mailto: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- > > <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? > > > > > > > > -- > > > > > > * > > * > > * > > Marcus Bergo* > >
