[Bug 216516] New: s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[Bug 216516] New: s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

            Bug ID: 216516
           Summary: s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)
           Product: Drivers
           Version: 2.5
    Kernel Version: 6.0-rc6
          Hardware: AMD
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Video(DRI - non Intel)
          Assignee: drivers_video-dri@kernel-bugs.osdl.org
          Reporter: kolAflash@kolahilft.de
        Regression: No

Beginning with this commit (regression) s2ram freezes the screen and I have to
restart the XServer.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7123d39dc24dcd21ff23d75f46f926b15269b9da
git describe: 5.18-rc7-1-g7123d39dc24d
s2ram => systemctl start suspend.target

Before v5.18-rc7 the system sometimes stays awake instead of entering S3 sleep.
But in that case the system keeps running stable and the screen doesn't freeze.
And on the second try the system then successfully enters S3. You can see this
behaviour in the attached linux-v5.18-rc7.txt for 5.18.0-rc7-v5.18-rc7.
This "stays awake" behaviour is probably a bug on it's own.
(I may may open another bug report when this one is solved)

Later on in the attached linux-v5.18-rc7.txt you'll see how
5.18.0-rc7-v5.18-rc7-1-g7123d39dc24d behaves when the screen is getting frozen.


Reverting commit 7123d39dc on v5.19.10 or v6.0-rc7 makes the problem disappear.


= System =
Model: HP EliteBook 845 G8 (notebook)
CPU+GPU: Ryzen 5650U incl. Radeon GPU
OS: openSUSE-15.4

The HP EliteBook 845 G8 uses s0ix/s2idle by default. But I changed the ACPI
BIOS settings to enable classic S3 s2ram.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #1 from kolAflash (kolAflash@kolahilft.de) ---
Created attachment 301849
  --> https://bugzilla.kernel.org/attachment.cgi?id=301849&action=edit
kernel log: v5.18-rc7 and v5.18-rc7-1-g7123d39dc24d

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mario.limonciello@amd.com,
                   |                            |regressions@leemhuis.info

--- Comment #2 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) ---
Mario, what's your opinion on this? 

@kolAflash, FWIW, this in not my area of expertise, but this one AFAICS is
tricky, as 7123d39dc24d is a fix for a regression; one that iirc bothered a few
people. So we can't simply revert it, as that would cause a regressions for
other people. And I wonder if the real problem here is the firmware, maybe its
s2ram codepaths are the root of the problem here.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #3 from kolAflash (kolAflash@kolahilft.de) ---
@Thorsten
Sure I understand that simply reverting is not an option.
Is there anything I can do to track this down further?
Maybe enabling some debug log options to get more informative output?

Or is there a kernel/driver option I can set so workaround this behavior, so I
don't have to patch my kernel?


I'm using the firmware (/lib/firmware/amdgpu/) as provided by the openSUSE
Linux distro.
https://download.opensuse.org/update/leap/15.4/sle/noarch/kernel-firmware-amdgpu-20220509-150400.4.8.1.noarch.rpm

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #4 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> This "stays awake" behaviour is probably a bug on it's own.
> (I may may open another bug report when this one is solved)

This is actually the root of the problem I suspect. This might actually be
fixed by b8c824a869f220c6b46df724f85794349bafbf23.

> Mario, what's your opinion on this? 

So to further complicate things 7123d39dc24d went back to stable and is in
5.15.y and such.

I think we need to better understand the failure mode and actions associated. 
The workaround in daf8de0874ab5b specifically helped with "aborted suspends". 
7123d39dc24d fixed the behavior that regression that happened on more systems
as a result of that.

> Is there anything I can do to track this down further?

Here's a few things that would at least help me understand the situation:
1) Does this still exist in a fully unpatched 6.0-rc6? What's the behavior?
2) What bisect points did you use to conclude that this problem on that
particular commit?  By chance do you have the bisect log?
3) Why don't you just use s2idle instead in BIOS setup?  It's very mature on a
modern kernel. Most systems with AMD APUs shipped from OEMs don't offer a
toggle even, which is why I'm surprised you have one.

BTW - I wasn't aware that they offered a BIOS setting for s2ram on 845.  Are
you patching the BIOS somehow or just changing a setting?  If you change it
back to s2idle does all this go away?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #5 from kolAflash (kolAflash@kolahilft.de) ---
Created attachment 301854
  --> https://bugzilla.kernel.org/attachment.cgi?id=301854&action=edit
kernel log: v6.0-rc6 and v6.0-rc6 with 7123d39dc reverted

@Mario


(In reply to Mario Limonciello (AMD) from comment #4)
> [...]
> 1) Does this still exist in a fully unpatched 6.0-rc6? What's the behavior?

Yes.
That's why I've set the bugs kernel version to 6.0-rc6 ;-)

I've attached kernel logs for v6.0-rc6 and for v6.0-rc6 with 7123d39dc
reverted.
Reverting 7123d39dc on v6.0-rc6 makes the bug disappear.



> 2) What bisect points did you use to conclude that this problem on that
> particular commit?  By chance do you have the bisect log?

Sorry, no bisect log saved.
But I've explicitly tested 7123d39dc and it's predecessor 7123d39dc^, which is
v5.18-rc7.
And 7123d39dc is definitely broken and v5.18-rc7 is working fine.



> 3) Why don't you just use s2idle instead in BIOS setup?  It's very mature on
> a modern kernel. Most systems with AMD APUs shipped from OEMs don't offer a
> toggle even, which is why I'm surprised you have one.

Tested s2idle with the openSUSE-15.4 stock kernel v5.14 and it consumed
MASSIVELY more power than S3.
I may give s2idle it another try with linux-6.0.

QUESTION:
Is "echo s2idle > /sys/power/mem_sleep" equivalent to enabling s2idle via ACPI?
So I wouldn't need to reboot to change ACPI for testing s2idle.

I also thought about using s2disk. But my employer requires me to use a very
long LUKS password. So I prefer not to enter the LUKS password every time I
wake my notebook.



> BTW - I wasn't aware that they offered a BIOS setting for s2ram on 845.  Are
> you patching the BIOS somehow or just changing a setting?  If you change it
> back to s2idle does all this go away?

Actually S3 is very well hidden. I don't know a way to enable it directly in
the BIOS. But it's in the ACPI tables.

cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
iasl -d dsdt.dat
==========
[...]
    If (!MSCE)
    {
        Name (_S3, Package (0x04)  // _S3_: S3 System State
        {
            0x03, 
            0x03, 
            Zero, 
            Zero
        })
    }
[...]
==========
I changed that "if" statement, recompiled and put the ACPI table into the
initrd for the kernel to load. 
See here for details:
https://www.reddit.com/r/AMDLaptops/comments/lg0knl/comment/ikpwpb8/

Side note:
If you have an idea how to set that MSCE variable to false without recompiling
the kernel, I'd be quite happy :-)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #6 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> Tested s2idle with the openSUSE-15.4 stock kernel v5.14 and it consumed
> MASSIVELY more power than S3.

TONS and TONS of fixes have landed for s2idle since then.  5.15.y is the first
kernel that you should be confident to use it.

Please re-test with s2idle using 6.0-rc6.  If that doesn't work let's fix it.

> Is "echo s2idle > /sys/power/mem_sleep" equivalent to enabling s2idle via
> ACPI?
So I wouldn't need to reboot to change ACPI for testing s2idle.

No, on AMD systems there are Pre-OS changes that occur when you use modern
standby/s2idle.  If you use s2idle when the firmware is configured for S3 you
will never get into the proper power state.


> Actually S3 is very well hidden. I don't know a way to enable it directly in
> the BIOS. But it's in the ACPI tables.

As you're patching the firmware this is not a regression.  It takes more to
properly enable S3 in Pre-OS code than changing a variable evaluated by the
Linux kernel's ACPI interpreter..

Thorsten - this is not a regression, patching the BIOS like this is completely
off the beating path.  We can't possibly support S3 in Linux if the OEM doesn't
offer it in their BIOS.

kolAflash - Let's focus on fixing s2idle for your system.  With 6.0-rc6 and an
"unpatched" BIOS let's see if you have any remaining problems with it.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #7 from The Linux kernel's regression tracker (Thorsten Leemhuis) (regressions@leemhuis.info) ---
(In reply to Mario Limonciello (AMD) from comment #6)
>
> Thorsten - this is not a regression, 

don't worry, I already had feared something like this might be the case; I for
a moment had even considered asking about the S3 support status myself in my
initial comment, but then settled on "stay out of this, Mario will known better
what to do" :-D

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #8 from kolAflash (kolAflash@kolahilft.de) ---
Created attachment 301855
  --> https://bugzilla.kernel.org/attachment.cgi?id=301855&action=edit
kernel log for s2idle: v6.0-rc6 and v6.0-rc6 with 7123d39dc reverted

@Mario

Sadly I've to report, that the problem stays the same with s2idle using
v6.0-rc6.
And reverting 7123d39dc also makes the bug disappear when using s2idle.
Find the logs attached.

As you said, I've reverted my ACPI modifications and /sys/power/mem_sleep now
only contains s2idle.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #9 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
You're missing CONFIG_AMD_PMC.

/var/log/messages:2022-09-23T20:19:35.187256+02:00 myhost kernel: [  
85.619055][ T3150] amdgpu 0000:05:00.0: amdgpu: Power consumption will be
higher as the kernel has not been compiled with CONFIG_AMD_PMC.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #10 from kolAflash (kolAflash@kolahilft.de) ---
Created attachment 301870
  --> https://bugzilla.kernel.org/attachment.cgi?id=301870&action=edit
kernel log for s2idle: v6.0-rc6 with CONFIG_AMD_PMC enabled

(In reply to Mario Limonciello (AMD) from comment #9)
> You're missing CONFIG_AMD_PMC.

Compiled with CONFIG_AMD_PMC.

Going to s2idle two times.
(first time just for a few seconds)


The good news:
With CONFIG_AMD_PMC in s2idle the screen doesn't freeze.

The bad news:
After less than 8 hours in s2idle the battery went from 60 % to 0 % !!!
That's why there's no second wakeup.
(system was down because battery was drained)

With S3 the battery will loose less than 5 % charge in the same time.
And the notebook is brand new. So there should be no battery degradation.


... just did another s2idle test and battery went from 67 % to 58 % in one
hour.



(In reply to Mario Limonciello (AMD) from comment #6)
> [...]
> As you're patching the firmware this is not a regression.  It takes more to
> properly enable S3 in Pre-OS code than changing a variable evaluated by the
> Linux kernel's ACPI interpreter..
> 
> Thorsten - this is not a regression, patching the BIOS like this is
> completely off the beating path.  We can't possibly support S3 in Linux if
> the OEM doesn't offer it in their BIOS.

I think you exaggerate a little.
I'm just enabling existing OEM code!

Also I wouldn't say this is patching the firmware, because it's just the ACPI
data, not the BIOS software.
Just changing the existing "if" statement.
See: comment #5
I'm pretty sure there's a way to enable this OEM code without recompiling the
ACPI data. Probably by setting the MSCE variable with a hidden BIOS option or
something else I haven't found yet.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #11 from kolAflash (kolAflash@kolahilft.de) ---
P.S.

I think using S3 is somehow intended by the OEM for the HP EliteBook 845 G8. I
consider the S3 option just being hidden. You just need to know how to change
that MSCE variable without changing the ACPI data.

In general I'd say that s2idle is absolutely fine. s2idle just should be more
energy efficient.
S3 is using less than 1 % battery per hour. So if there's a way to get s2idle
down to 2 % per hour that would be a good solution.

Until linux-5.18-rc7 S3 is working very well. So I thought this would be the
best solution for an energy efficient standby mode on this hardware.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #12 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> Compiled with CONFIG_AMD_PMC.
> Going to s2idle two times.
> (first time just for a few seconds)

It looks better to me now.

> After less than 8 hours in s2idle the battery went from 60 % to 0 % !!!
> That's why there's no second wakeup.
> (system was down because battery was drained)

I suspect one of two things happened:
1) A spurious event actually woke up the SOC the second time but it never
re-entered.
2) You entered back to back and didn't get into the deepest state due to a
timing issue.

I know of a potential patch I can offer you for this, but we need to confirm
the root cause before I write it up.

> With S3 the battery will loose less than 5 % charge in the same time.
> And the notebook is brand new. So there should be no battery degradation.
> ... just did another s2idle test and battery went from 67 % to 58 % in one
> hour.

It's up to the OEM's design how quickly it will lose battery over Modern
Standby/s2idle, it has a lot of factors involved.  I'll describe some
additional debugging tactics later in this response.

> I think you exaggerate a little.
> I'm just enabling existing OEM code!

> Also I wouldn't say this is patching the firmware, because it's just the ACPI 
> data, not the BIOS software.
> Just changing the existing "if" statement.
> See: comment #5
> I'm pretty sure there's a way to enable this OEM code without recompiling the 
> ACPI data. Probably by setting the MSCE variable with a hidden BIOS option or
> something else I haven't found yet.

What you're seeing in there is a remnant of AGESA reference code.  I see the
same thing in AMD's reference designs and in other OEM designs.

There is definitely OEM effort involved with enabling S3, and like I said there
are lots of other firmware components involved that are invisible to the OS. 

The other thing I want to point out - if they use Modern Standby in Windows,
this is the path that has gotten lots of validation.  A non-validated path is
likely to have unique bugs.

> s2idle just should be more energy efficient.
> S3 is using less than 1 % battery per hour. So if there's a way to get s2idle 
> down to 2 % per hour that would be a good solution.

For most mobile designs the power consumption is better for s2idle than S3.
I suspect you're hitting a bug with wakeups, or s2idle re-entries.

For the next step in debugging, please do all of the following:
0) 6.0-rc6 kernel
1) Add to your kernel command line:
acpi.dyndbg='file drivers/acpi/x86/s2idle.c +p' amd_pmc.dyndbg='+p'
2) set /sys/power/pm_print_times to 1.
3) set /sys/power/pm_debug_messages to 1 

With all those debugging things put in place, run a sample where you put it to
sleep for a short period of time (say 10 minutes), and then wakeup and share
the log.  Please note how you woke up the system.  Hopefully based upon that
log it will be clearer what is causing your increased power consumption.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #13 from kolAflash (kolAflash@kolahilft.de) ---
Created attachment 301872
  --> https://bugzilla.kernel.org/attachment.cgi?id=301872&action=edit
kernel log for s2idle: v6.0-rc6 with debug options

@Mario

(In reply to Mario Limonciello (AMD) from comment #12)
> [...]
> For the next step in debugging, please do all of the following:
> 0) 6.0-rc6 kernel
> 1) Add to your kernel command line:
> acpi.dyndbg='file drivers/acpi/x86/s2idle.c +p' amd_pmc.dyndbg='+p'
> 2) set /sys/power/pm_print_times to 1.
> 3) set /sys/power/pm_debug_messages to 1
> [...]

Thanks!

Here's the requested log.


I woke the notebook by pressing the power button.

Before standby I'm always doing:
echo disabled > /sys/devices/platform/i8042/serio0/power/wakeup
echo disabled > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/power/wakeup
echo XHC1 > /proc/acpi/wakeup
Else the notebook wakes on every keyboard, mouse, lid open and even lid close
action.


Can you tell if the power consumption is completely up to the kernel?
Or should I have a look at the userspace too?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #14 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> Here's the requested log.

OK let me pull out a few pieces and explain what they mean.

> 2022-09-26T19:01:47.104247+02:00 myhost kernel: [ 2218.148069][    T0]
> Timekeeping suspended for 341.998 seconds
> 2022-09-26T19:01:47.104247+02:00 myhost kernel: [ 2218.148164][ T5798] ACPI:
> EC: ACPI EC GPE status set
> 2022-09-26T19:01:47.104247+02:00 myhost kernel: [ 2218.148190][ T5798] ACPI:
> EC: ACPI EC GPE dispatched
> 2022-09-26T19:01:47.104248+02:00 myhost kernel: [ 2218.148541][ T5798] ACPI:
> EC: ACPI EC work flushed
> 2022-09-26T19:01:47.104248+02:00 myhost kernel: [ 2218.149018][ T5798] ACPI:
> PM: Rearming ACPI SCI for wakeup
> 2022-09-26T19:01:47.104249+02:00 myhost kernel: [ 2568.100347][    T0]
> Timekeeping suspended for 349.998 seconds
> 2022-09-26T19:01:47.104249+02:00 myhost kernel: [ 2568.100442][ T5798] ACPI:
> EC: ACPI EC GPE status set
> 2022-09-26T19:01:47.104250+02:00 myhost kernel: [ 2568.100468][ T5798] ACPI:
> EC: ACPI EC GPE dispatched
> 2022-09-26T19:01:47.104250+02:00 myhost kernel: [ 2568.100817][ T5798] ACPI:
> EC: ACPI EC work flushed
> 2022-09-26T19:01:47.104251+02:00 myhost kernel: [ 2568.101326][ T5798] ACPI:
> PM: Rearming ACPI SCI for wakeup

The SOC was asleep for some number of seconds, and then it got woken up from
the EC GPE.  It may or may not have gone back to the deepest state during each
of these attempts (it's unclear with the way logging works in the kernel).

During the duration of these attempts you can see this happened a LOT of times.

As an educated guess; it might have been that the EC was trying to update new
battery life values or it can be illustrative of another bug.  The easiest way
to determine the cause of these GPEs do the following.

1) Collect the output of 
# grep -v foo /sys/firmware/acpi/interrupts/*
2) Run your suspend
3) Capture again the output of 
# grep -v foo /sys/firmware/acpi/interrupts/*
4) Compare the two to see which incremented

> 2022-09-26T19:01:47.104625+02:00 myhost kernel: [ 4600.944320][ T5798]
> amd_pmc AMDI0005:00: Last suspend in deepest state for 16419799us

This means the SOC was only in the deepest state for a total of 16 seconds of
your last s2idle run.  

> echo disabled > /sys/devices/platform/i8042/serio0/power/wakeup
> echo disabled > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/power/wakeup
> echo XHC1 > /proc/acpi/wakeup

At least for experimentations sake, can you avoid making these changes in your
next attempt?  Would like to confirm they weren't /part/ of this problem.

> Can you tell if the power consumption is completely up to the kernel?

From the logs you've shared, this is entirely influence by the kernel and
firmware code for your case.  I would not be worried about userspace at all.

If the issue persists even without those wakeup sources then I'll look through
your GPEs.

The next debugging step will be applying the following patches to 6.0-rc:

https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=review-hans&id=811d59fdf56a17c66742578fe8be8a6a841af448

https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=review-hans&id=e24faabf5f368c031ad50f0d915a01e1b591f536

https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=review-hans&id=90bec2855c566b6d07cc3e2bb47befb6266cf1ec

https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=review-hans&id=db55fb8a06f241e168a4f275970f2701d52040c6

Then add this patch:

diff --git a/drivers/platform/x86/amd/pmc.c b/drivers/platform/x86/amd/pmc.c
index e47e54b095af..d3a3e0df6e77 100644
--- a/drivers/platform/x86/amd/pmc.c
+++ b/drivers/platform/x86/amd/pmc.c
@@ -750,6 +750,8 @@ static void amd_pmc_s2idle_check(void)
        struct amd_pmc_dev *pdev = &pmc;
        int rc;

+       usleep_range(10000, 20000);
+
        rc = amd_pmc_write_stb(pdev, AMD_PMC_STB_S2IDLE_CHECK);
        if (rc)
                dev_err(pdev->dev, "error writing to STB: %d\n", rc);

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216516

Mario Limonciello (AMD) (mario.limonciello@amd.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Video(DRI - non Intel)      |Platform_x86
           Assignee|drivers_video-dri@kernel-bu |drivers_platform_x86@kernel
                   |gs.osdl.org                 |-bugs.osdl.org

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.