On 4/28/2025 2:45 PM, Rafael J. Wysocki wrote:
On Mon, Apr 28, 2025 at 9:11 PM Mario Limonciello
<mario.limonciello@xxxxxxx> 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@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?
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.
