As it turns out, Turing isn't the only architecture that needs this. On
this Dell Precision 7780 with an AD103 GPU, along with pretty much every
other laptop I tested, runtime PM is still somewhat unreliable. At first
glance it seems as if it's fixed, but lowering the autosuspend delay to
500ms and then doing a stress test of suspend/resume cycles on the GPU ends
up causing everything to start timing out.
After quite a lot of digging, I eventually landed back on this magic
timeout in r535_gsp_fini(). As it turns out, increasing the timeout ends up
fixing the runtime PM issues as far as I can tell, even during intense
stress testing.
Unfortunately after spending quite a bit of time trying to dig through
OpenRM to figure out what this magic sleep is actually doing, I've also
come up short with any reasonable explanation. In lieu of that, I'm going
to include the observations I did make while trying to figure this out in
hopes someone eventually does figure this out:
* The magic sleep has to occur after fbsr is initialized. Performing it at
any time before that doesn't appear to work.
* In situations where runtime PM starts getting flaky, some rather
interesting visual effects end up happening on occasion before the GPU
fully falls over. In particular, squares that look like the result of an
incomplete blitting operation to a tiled buffer end up showing up on
applications like vkcube. Interestingly enough, they remain in precisely
the same place between runtime PM cycles until the GPU falls over - even
when restarting vkcube multiple times, and even when vkcube is actively
updating the screen. Even more interestingly, they're not limited to a
specific framebuffer - you can see the squares changing as the cube
rotates around.
We cannot however, say that this is likely to be a incomplete fbsr
operation. The magic sleep happens before fbsr is actually saved (which
happens on the GSP unload), so it's something else.
* During a short bit of testing with a desktop that I have, the magic sleep
seemed to make no difference to whether or not suspend/resume works. It
seems to generally work almost always. So we can assume this is likely
exclusive to runtime PM, not S3.
As well, here's a list of the things I tried before settling on the magic
sleep:
* Hooking up NV2080_CTRL_CMD_INTERNAL_GCX_ENTRY_PREREQUISITE and then
blocking runtime PM until OpenRM signals that GC6/GCOFF is ready appears
to make no difference.
* Hooking up some (maybe not all, unsure about that part) bits of comptag
saving including:
* Fetching static memsys information from GSP
* Adding the size of the comptag storage to the fbsr data
* Adding a GA103+ workaround for disabling raw compression mode during
fbsr (it doesn't seem like it applies for any systems I tried it on
anyhow)
* Setting bPreserveVideoMemoryAllocations=1 in GspSystemInfo
So, until we can figure this out properly - just sleep for longer.
Signed-off-by: Lyude Paul <[email protected]>
Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144")
Cc: <[email protected]> # v6.16+
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c
index 4a3b771ded255..94925f1590ea4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c
@@ -1761,8 +1761,12 @@ r535_gsp_fini(struct nvkm_gsp *gsp, enum
nvkm_suspend_state suspend)
* TODO: Debug the GSP firmware / RPC handling to find out why
* without this Turing (but none of the other architectures)
* ends up resetting all channels after resume.
+ * Additionally, runtime suspend on other architectures quickly
+ * becomes unreliable without this sleep. If you're experiencing
+ * issues with runtime suspend, try bumping this delay up and
+ * sending a patch if it fixes your GPU.
*/
- msleep(50);
+ msleep(200);
}
ret = r535_gsp_rpc_unloading_guest_driver(gsp, suspend);
--
2.55.0
