<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 5/16/2023 11:43 PM, Lazar, Lijo
wrote:<br>
</div>
<blockquote type="cite" cite="mid:89d0c8be-d118-1b02-0406-835557d712b1@amd.com">
<br>
<br>
On 5/17/2023 5:04 AM, Mario Limonciello wrote:
<br>
<blockquote type="cite">DCN 3.1.4 s2idle entry will hang
<br>
occasionally on s2idle entry, but only if running Wayland and
only
<br>
when using `systemctl suspend`, not `echo mem | tee
/sys/power/state`.
<br>
<br>
This happens because using `systemctl suspend` will cause the
screen
<br>
to lock right before writing mem into /sys/power/state.
<br>
<br>
</blockquote>
<br>
A couple of things on this since this mentions systemctl suspend -
<br>
<br>
1) If in s2idle, it's supposed to immediately signal and not
schedule delayed work
<br>
<br>
3964b0c2e843334858da99db881859faa4df241d drm/amdgpu: complete
gfxoff allow signal during suspend without delay
<br>
</blockquote>
<p>It looks like dead code to me now actually.</p>
<p>amdgpu_device_set_pg_state() skips GFX, so gfxoff control never
gets called as part of suspend path.<br>
</p>
<blockquote type="cite" cite="mid:89d0c8be-d118-1b02-0406-835557d712b1@amd.com">
<br>
2) RLC is never stopped on GFX 10 or greater.
<br>
<br>
</blockquote>
<p>System was hanging before this series.</p>
<p>Patch 3 "alone" matches this behavior as described above to skip
RLC suspend but two problems happen:</p>
<p>1) GFXOFF workqueue doesn't get flushed and so driver's request
for GFXOFF can happen at wrong time.</p>
<p>2) If suspend entry happens before GFXOFF is really asserted lots
of errors on resume. IE:<br>
</p>
<p><span><span class="ui-provider cfr cfs c d e f g h i j k l m n o
p q r s t cft cfu w x y z ab ac ae af ag ah ai aj ak" dir="ltr">[ 63.095227] [drm] Fence fallback timer expired on
ring sdma0<br>
[ 63.098360] [drm] ring gfx_32772.1.1 was added<br>
[ 63.099439] [drm] ring compute_32772.2.2 was added<br>
[ 63.100460] [drm] ring sdma_32772.3.3 was added<br>
[ 63.100504] [drm] ring gfx_32772.1.1 test pass<br>
[ 63.607166] [drm] Fence fallback timer expired on ring
gfx_32772.1.1<br>
[ 63.607234] [drm] ring gfx_32772.1.1 ib test pass<br>
[ 63.608964] [drm] ring compute_32772.2.2 test pass<br>
[ 64.119173] [drm] Fence fallback timer expired on ring
compute_32772.2.2<br>
[ 64.119219] [drm] ring compute_32772.2.2 ib test pass<br>
[ 64.121364] [drm] ring sdma_32772.3.3 test pass<br>
[ 64.631422] [drm] Fence fallback timer expired on ring
sdma_32772.3.3<br>
[ 64.631465] [drm] ring sdma_32772.3.3 ib test pass<br>
[ 65.143184] [drm] Fence fallback timer expired on ring
sdma0</span></span></p>
<blockquote type="cite" cite="mid:89d0c8be-d118-1b02-0406-835557d712b1@amd.com">Wondering
if the code hides something else because of the timing.
<br>
</blockquote>
<blockquote type="cite" cite="mid:89d0c8be-d118-1b02-0406-835557d712b1@amd.com">Thanks,
<br>
Lijo
<br>
<br>
<blockquote type="cite">This causes a delayed GFXOFF entry to be
scheduled right before s2idle
<br>
entry. If the workqueue doesn't get processed before the RLC is
turned
<br>
off the system is hung. Even if the workqueue *does* get
processed, there
<br>
is a race between the APU microcontrollers and driver for
whether GFX
<br>
is actually powered off when RLC is turned off.
<br>
<br>
To avoid this issue, flush the workqueue on s2idle entry and
ensure that
<br>
GFX is really in GFXOFF before any sensitive register accesses
occur.
<br>
<br>
Mario Limonciello (3):
<br>
drm/amd: Flush any delayed gfxoff on suspend entry
<br>
drm/amd: Poll for GFX core to be off
<br>
drm/amd: Skip RLC suspend for s0ix on PSP 13.0.4 and 13.0.11
<br>
<br>
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 25
++++++++++++++++++++++
<br>
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 18
++++++++++++++++
<br>
drivers/gpu/drm/amd/include/amd_shared.h | 1 +
<br>
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 4 ++--
<br>
4 files changed, 46 insertions(+), 2 deletions(-)
<br>
<br>
</blockquote>
</blockquote>
</body>
</html>