Message-ID: <CAJZ5v0jS+gdHqW3pB1awZ7LHHWsFBQMp86tNwPMVBzOfot-sZw@mail.gmail.com>
Date: Mon, 28 Apr 2025 21:02:05 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Mario Limonciello <mario.limonciello@....com>
Cc: Marcus Bergo <marcusbergo@...il.com>, "Rafael J. Wysocki" <rafael@...nel.org>, mark.pearson@...ovo.com, 
	linux-acpi@...r.kernel.org, platform-driver-x86@...r.kernel.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 Mon, Apr 28, 2025 at 8:23 PM Mario Limonciello
<mario.limonciello@....com> 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@....com <mailto:mario.limonciello@....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@...il.com
> >     <mailto: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
> >     <https://bugzilla.kernel.org/show_bug.cgi?id=218557>
> >      >>>> Reported-by: Mark Pearson <mark.pearson@...ovo.com
> >     <mailto:mark.pearson@...ovo.com>>
> >      >>>> Signed-off-by: Marcus Bergo <marcusbergo@...il.com
> >     <mailto: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-
> >     <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*
>
>

Powered by blists - more mailing lists