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

[Mario Limonciello <mario.limonciello@amd.com>]

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.

> On Sun, Apr 27, 2025 at 11:06 PM Mario Limonciello 
> <mario.limonciello@amd.com <mailto:mario.limonciello@amd.com>> 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@gmail.com
>     <mailto: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
>     <https://bugzilla.kernel.org/show_bug.cgi?id=218557>
>      >>>> Reported-by: Mark Pearson <mark.pearson@lenovo.com
>     <mailto:mark.pearson@lenovo.com>>
>      >>>> Signed-off-by: Marcus Bergo <marcusbergo@gmail.com
>     <mailto: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-
>     <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*