(Cc: John) On Wed Jul 1, 2026 at 8:17 PM CEST, Lyude Paul wrote: > It turns out that the only reason our previous fixes looked like they > worked for this was because we would occasionally set the Gcoff state to 0 > in the normal S3 path, which fixed suspend/resume on desktops - but not on > machines using runtime suspend. > > The proper fix is to just never set this flag. Our current guess for the > reasoning behind this is that Gcoff likely coincides with GC6, and not > literally power off.
I don't think GcOff coincides with GC6, it should actually be a power off. >From a quick glance in OpenRM, it seems that with bEnteringGcoffState = 1 it also saves off buffers flagged as MEMDESC_FLAGS_LOST_ON_SUSPEND. My guess would be that with bEnteringGcoffState = 1, GSP's resume path expects certain kernel-driver-allocated buffers to still be in place that nouveau didn't save off, or rather never had in the first place. John, do you have some details about this? > 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/r570/fbsr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/fbsr.c > b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/fbsr.c > index 2945d5b4e5707..af5aa5065c3dd 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/fbsr.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/fbsr.c > @@ -81,7 +81,7 @@ r570_fbsr_init(struct nvkm_gsp *gsp, struct sg_table *sgt, > u64 size) > ctrl->hClient = gsp->internal.client.object.handle; > ctrl->hSysMem = memlist.handle; > ctrl->sysmemAddrOfSuspendResumeData = gsp->sr.meta.addr; > - ctrl->bEnteringGcoffState = 1; > + ctrl->bEnteringGcoffState = 0; > > ret = nvkm_gsp_rm_ctrl_wr(&gsp->internal.device.subdevice, ctrl); > if (ret) > -- > 2.54.0
