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

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

On 4/28/2025 2:45 PM, Rafael J. Wysocki wrote:
> On Mon, Apr 28, 2025 at 9:11 PM Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>>
>> On 4/28/2025 2:02 PM, Rafael J. Wysocki wrote:
>>> On Mon, Apr 28, 2025 at 8:23 PM Mario Limonciello
>>> <mario.limonciello@amd.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?
>>>
>> I mean yes - of course.  My inquiry was whether this should be the
>> default behavior or if it should have been a quirked behavior.
> 
> I believe that it should be the default behavior because the EC GPE
> needs to be cleared after handling an EC event which effectively is
> what the suspend-to-idle code does.
> 
>> I don't have a good sense for the rest of the ecosystem what the impacts
>> would really be at flipping it.  Would it be worth adding a module
>> parameter debug knob and survey what happens on a wide variety of machines?
> 
> Maybe, if you suspect that this might be a widespread issue.

Marcus,

Before going down this path I have an important confirmation I need from 
you.

With just /your/ patch in place did you see a message like this in your 
kernel log?

amd_pmc AMDI000A:00: Last suspend didn't reach deepest state

If so; your patch just papered over the real issue and blocked the 
system from getting into a deep state.