From nobody Mon Sep 28 23:55:24 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 679183B2D00 for ; Fri, 14 Aug 2026 19:46:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786736765; cv=none; b=B9xGt7Q2o2Myog8Nqmlxe9uLObJrFCiPqas91YDXjGJ0svkZk772KKvdFVHFVmLZ3fpUJTi4RRXDtAr78s83+H0oeMD04/VtjBP7zZjP99C118oNVhP9yEjyS26SFE/nMHhQ9kdYjqYCCaYpQ88S5P10R8SfsSIJ0kjfI9G0tUU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786736765; c=relaxed/simple; bh=yyM4H8Qo8zg143UrT2joE79qhFNxtcSQFaIdxwm2RZo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NHRpy/B7TNoyVtrysoxkUWcRZfz7pRKjUbxzfybqEBtxeDqSHS17c5WbyHZKqyTssJ8jY5IJCbMd696v9Eh8jTyKKLsbQqzQZU1xjnWp0Abz0YWC0xANdKiJYIv5MMEpCj1CwAOWnLidDWEZfTHW8AlUAhntlLTNSu3jAFrg19U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=HHvO2cgr; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HHvO2cgr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786736762; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2CZ60NVHpqwN9DuqhR09Jg1IdibJV1yJ+DJMquDywq4=; b=HHvO2cgrwNDRPvgZloXGSe20n6/WNHLStszFtOzYaDRM/Pg96ItMQBfV9PB18AvdeTdJXt E2bKsYxwhE0WEGNQd5YB+l2c1wnfGRjvwtKAyoFVWhCBMtFSwz5aa9viJkFBnWy6rUgurd tpNOrIZX4pBC2kdHMJP1Cw+DWIeyUSs= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-679-_VTmw3ItOaqWLCJVtUgoqQ-1; Fri, 14 Aug 2026 15:45:59 -0400 X-MC-Unique: _VTmw3ItOaqWLCJVtUgoqQ-1 X-Mimecast-MFC-AGG-ID: _VTmw3ItOaqWLCJVtUgoqQ_1786736757 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id EF6CC1956095; Fri, 14 Aug 2026 19:45:56 +0000 (UTC) Received: from GoldenWind.lan (unknown [10.22.64.233]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 733D53000239; Fri, 14 Aug 2026 19:45:54 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org, "Timur Tabi" , "Dave Airlie" , "Andy Shevchenko" , "Maarten Lankhorst" , "Ben Skeggs" , "Kees Cook" , "Simona Vetter" , "David Airlie" , "Thomas Zimmermann" , "Maxime Ripard" , "Mel Henning" , "Danilo Krummrich" , "Lyude Paul" Subject: [PATCH v5 1/4] Revert "nouveau/gsp: fix suspend/resume regression on r570 firmware" Date: Fri, 14 Aug 2026 15:43:48 -0400 Message-ID: <20260814194542.781955-2-lyude@redhat.com> In-Reply-To: <20260814194542.781955-1-lyude@redhat.com> References: <20260814194542.781955-1-lyude@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" This reverts commit 8302d0afeaec0bc57d951dd085e0cffe997d4d18. It turns out this looked like the right fix on some systems, but it's not - as this causes runtime PM to actually fail on many a laptop. Fixes: 8302d0afeaec ("nouveau/gsp: fix suspend/resume regression on r570 fi= rmware") Cc: # v6.19+ Signed-off-by: Lyude Paul Reviewed-by: Dave Airlie --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/fbsr.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/fbsr.c | 8 ++++---- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/fbsr.c b/drive= rs/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/fbsr.c index f128330f30d7b..40bf83ea33ac0 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/fbsr.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/fbsr.c @@ -208,7 +208,7 @@ r535_fbsr_resume(struct nvkm_gsp *gsp) } =20 static int -r535_fbsr_suspend(struct nvkm_gsp *gsp, bool runtime) +r535_fbsr_suspend(struct nvkm_gsp *gsp) { struct nvkm_subdev *subdev =3D &gsp->subdev; struct nvkm_device *device =3D subdev->device; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c b/driver= s/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c index f544afa12b6bb..4a3b771ded255 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 @@ -1749,7 +1749,7 @@ r535_gsp_fini(struct nvkm_gsp *gsp, enum nvkm_suspend= _state suspend) sr->sysmemAddrOfSuspendResumeData =3D gsp->sr.radix3.lvl0.addr; sr->sizeOfSuspendResumeData =3D len; =20 - ret =3D rm->api->fbsr->suspend(gsp, suspend =3D=3D NVKM_RUNTIME_SUSPEND); + ret =3D rm->api->fbsr->suspend(gsp); if (ret) { nvkm_gsp_mem_dtor(&gsp->sr.meta); nvkm_gsp_radix3_dtor(gsp, &gsp->sr.radix3); diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/fbsr.c b/drive= rs/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/fbsr.c index 8ef8b4f655883..2945d5b4e5707 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 @@ -62,7 +62,7 @@ r570_fbsr_resume(struct nvkm_gsp *gsp) } =20 static int -r570_fbsr_init(struct nvkm_gsp *gsp, struct sg_table *sgt, u64 size, bool = runtime) +r570_fbsr_init(struct nvkm_gsp *gsp, struct sg_table *sgt, u64 size) { NV2080_CTRL_INTERNAL_FBSR_INIT_PARAMS *ctrl; struct nvkm_gsp_object memlist; @@ -81,7 +81,7 @@ r570_fbsr_init(struct nvkm_gsp *gsp, struct sg_table *sgt= , u64 size, bool runtim ctrl->hClient =3D gsp->internal.client.object.handle; ctrl->hSysMem =3D memlist.handle; ctrl->sysmemAddrOfSuspendResumeData =3D gsp->sr.meta.addr; - ctrl->bEnteringGcoffState =3D runtime ? 1 : 0; + ctrl->bEnteringGcoffState =3D 1; =20 ret =3D nvkm_gsp_rm_ctrl_wr(&gsp->internal.device.subdevice, ctrl); if (ret) @@ -92,7 +92,7 @@ r570_fbsr_init(struct nvkm_gsp *gsp, struct sg_table *sgt= , u64 size, bool runtim } =20 static int -r570_fbsr_suspend(struct nvkm_gsp *gsp, bool runtime) +r570_fbsr_suspend(struct nvkm_gsp *gsp) { struct nvkm_subdev *subdev =3D &gsp->subdev; struct nvkm_device *device =3D subdev->device; @@ -133,7 +133,7 @@ r570_fbsr_suspend(struct nvkm_gsp *gsp, bool runtime) return ret; =20 /* Initialise FBSR on RM. */ - ret =3D r570_fbsr_init(gsp, &gsp->sr.fbsr, size, runtime); + ret =3D r570_fbsr_init(gsp, &gsp->sr.fbsr, size); if (ret) { nvkm_gsp_sg_free(device, &gsp->sr.fbsr); return ret; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h b/drivers/gpu/= drm/nouveau/nvkm/subdev/gsp/rm/rm.h index a9af94adf9efc..0fb0e67406c67 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h @@ -78,7 +78,7 @@ struct nvkm_rm_api { } *device; =20 const struct nvkm_rm_api_fbsr { - int (*suspend)(struct nvkm_gsp *, bool runtime); + int (*suspend)(struct nvkm_gsp *); void (*resume)(struct nvkm_gsp *); } *fbsr; =20 --=20 2.55.0 From nobody Mon Sep 28 23:55:24 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 163043CBE79 for ; Fri, 14 Aug 2026 19:46:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786736780; cv=none; b=DkXKgxT6Njge8e4XGw2xsAio5oCkFMB+fPL4eaSLpIz0vMd4IIv2qn8EE9lilxC1oCmx8Iz8pBEwOBU4PqOXUhu0DeszE5DcnaTgSH/e8Qfdo+T1mQM30p0hpZlb2SS5O+YPRqyeQuEy4e/yPXF67e4uAQ9u+/ZAGFygkcG3CqU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786736780; c=relaxed/simple; bh=vgs/PLkhkluvCf/TBNJjSBsD0RimV3X4K+3rCi00pM4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d2rKH/pwZfIwnXIsEcLq1h8gs4lG5ykto2w2pa2WyVs8/xydx+qHoFJrwCDnKa1DCss1OJMgPZwErMasK1AIjD+iBTLA4cnnUmwMGxxiykAG+BXoEA0COvhKnqwcwesqLWlKc8DaVHb6TVYRu/wakUsUh2D/7lqQbrRMt9cNS3E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=bkXltAaf; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="bkXltAaf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786736778; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kUl4OiIK4x+8eiq0MCPzDAWyD8Ge8fli2WbAll1g3Fc=; b=bkXltAafomvfFI6aEZwFm5S0FNWGQWmEbQNE1SV+h93kwJwT48Ry22r1UAfNFjfh6h59hP xKUldNEbZ0LUY2F4TNJAFOjpkae9a0vWNVtBUVy/agg/saPZfOd2TEm0PfuSWEE1DY0gZi rApn5v4sn/NTua/vaLIdjCU8OaRMeNs= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-25-X4ulqH2_Oc-JPGz7V3G1sA-1; Fri, 14 Aug 2026 15:46:06 -0400 X-MC-Unique: X4ulqH2_Oc-JPGz7V3G1sA-1 X-Mimecast-MFC-AGG-ID: X4ulqH2_Oc-JPGz7V3G1sA_1786736764 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 20A721956089; Fri, 14 Aug 2026 19:46:04 +0000 (UTC) Received: from GoldenWind.lan (unknown [10.22.64.233]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 9981030001A2; Fri, 14 Aug 2026 19:46:01 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org, "Timur Tabi" , "Dave Airlie" , "Andy Shevchenko" , "Maarten Lankhorst" , "Ben Skeggs" , "Kees Cook" , "Simona Vetter" , "David Airlie" , "Thomas Zimmermann" , "Maxime Ripard" , "Mel Henning" , "Danilo Krummrich" , "Lyude Paul" Subject: [PATCH v5 2/4] drm/nouveau/gsp/r570: Set GcOff = 0 in fbsr Date: Fri, 14 Aug 2026 15:43:49 -0400 Message-ID: <20260814194542.781955-3-lyude@redhat.com> In-Reply-To: <20260814194542.781955-1-lyude@redhat.com> References: <20260814194542.781955-1-lyude@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" Previously, it looked as if we were able to fix suspend/resume on some desktops by setting Gcoff based on whether or not we were entering runtime PM. This was a mistake though - the only time suspend/resume would end up actually working was if Gcoff =3D 0. It seems like it's likely the main reason for this is the FBSR GcOff argument actually controls GSP's behavior with regards to which buffers it decides to save across suspend/resume. When GcOff =3D 1, RM reserved regions are saved unless they are marked as LOST_ON_SUSPEND, and RM channel-context and kernel-client buffers are also saved -including- when they are LOST_ON_SUSPEND. This means with GcOff =3D 1, we end up having GSP save and restore buffers that actually need to be reinitialized on resume - causing the failures we're setting. Thanks to John Hubbard from Nvidia for providing some background on what these options do in the GSP firmware do! Signed-off-by: Lyude Paul Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144") Cc: # v6.16+ Reviewed-by: Dave Airlie --- V5: * Fix commit title, GcOff should be 0 not 1 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/drive= rs/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 =3D gsp->internal.client.object.handle; ctrl->hSysMem =3D memlist.handle; ctrl->sysmemAddrOfSuspendResumeData =3D gsp->sr.meta.addr; - ctrl->bEnteringGcoffState =3D 1; + ctrl->bEnteringGcoffState =3D 0; =20 ret =3D nvkm_gsp_rm_ctrl_wr(&gsp->internal.device.subdevice, ctrl); if (ret) --=20 2.55.0 From nobody Mon Sep 28 23:55:24 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E4973233E8 for ; Fri, 14 Aug 2026 19:46:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786736781; cv=none; b=VjeBkdEIwYLnSbljx3qqAYlFz2AFL78jW1hazs6txMSU1FaU6MwM9Ua+ARQ825SOzIcd3wFkGC1d0LcjkrC5+y4x165hHilES3XE7TIpUto+Dhi+Lupr+T9uNcVv/LgtOSp3hLoXePlS23z27Wd+XBoncWr86jDuCoZNjDbQ0hE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786736781; c=relaxed/simple; bh=KMjiMwJxEcFoImBP2CGGJqvjXnv+idGDvqtvlRLb0GI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nnDbrck7MOEvZNcf4nGkbz+qJogJ1TsUMgvyxjbBPWaHKThv1YRJVdgIs9ec9sl075FFdsOdhN6ITAcO5Wlm9NwhYUpfIf6/jEQ0+3iHz45/ov77OQPJcQHmpSIWSsoG5Kdrr0d1dltOBcJs4VvXfQNgGaBsgh0JDe9rxicJCIc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=XDwRUf1J; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XDwRUf1J" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786736779; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sXRw5HgFBqtMjibe0Tg/q0W0/UG6cgg62YzMlj2W/cQ=; b=XDwRUf1Jh9kg1sq51gUq1ZKUTCTFzHgZAql5zHYmGashcOhb7WICUXFF3v+cqUbaHDQAzR rku+UK743Q3yYWfPIbWscdVyPFm6A9VwNNiIM/ejXrIEKGlbZ9m5BnHptYUkVU17ixTIgY n4SFrmC0m2YO5JbLHWX1YJsboIMZJdY= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-168-vaXtKV4FOU-vVFxX8yzNtg-1; Fri, 14 Aug 2026 15:46:15 -0400 X-MC-Unique: vaXtKV4FOU-vVFxX8yzNtg-1 X-Mimecast-MFC-AGG-ID: vaXtKV4FOU-vVFxX8yzNtg_1786736771 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 360F518001DE; Fri, 14 Aug 2026 19:46:11 +0000 (UTC) Received: from GoldenWind.lan (unknown [10.22.64.233]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0C11430001A2; Fri, 14 Aug 2026 19:46:08 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org, "Timur Tabi" , "Dave Airlie" , "Andy Shevchenko" , "Maarten Lankhorst" , "Ben Skeggs" , "Kees Cook" , "Simona Vetter" , "David Airlie" , "Thomas Zimmermann" , "Maxime Ripard" , "Mel Henning" , "Danilo Krummrich" , "Lyude Paul" Subject: [PATCH v5 3/4] drm/nouveau/gsp/r570: Enable S/R Display workaround in GSP Date: Fri, 14 Aug 2026 15:43:50 -0400 Message-ID: <20260814194542.781955-4-lyude@redhat.com> In-Reply-To: <20260814194542.781955-1-lyude@redhat.com> References: <20260814194542.781955-1-lyude@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" There's two flags that we've never been setting when asking GSP to suspend the GPU, which OpenRM does set: GPU_STATE_FLAGS_PRESERVING GPU_STATE_FLAGS_PM_TRANSITION These flags aren't -supposed- to do much in GSP, they're mostly used by OpenRM itself for state tracking. The only thing they do from GSP's side is control whether or not a single display related workaround is applied during suspend. But as it turns out, that single workaround is actually quite crucial for getting runtime PM working with nouveau - and without it set we end up seeing a lot more failures with runtime PM resume. So, let's start setting it. Signed-off-by: Lyude Paul Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144") Cc: # v6.16+ Reviewed-by: Dave Airlie --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c | 3 ++- .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/nvrm/gsp.h | 8 ++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c b/driver= s/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c index 996941c668ba9..3e391646d8f7d 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c @@ -198,7 +198,8 @@ r570_gsp_set_rmargs(struct nvkm_gsp *gsp, bool resume) args->srInitArguments.bInPMTransition =3D 0; } else { args->srInitArguments.oldLevel =3D NV2080_CTRL_GPU_SET_POWER_STATE_GPU_L= EVEL_3; - args->srInitArguments.flags =3D 0; + args->srInitArguments.flags =3D + GPU_STATE_FLAGS_PRESERVING | GPU_STATE_FLAGS_PM_TRANSITION; args->srInitArguments.bInPMTransition =3D 1; } =20 diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/nvrm/gsp.h b/d= rivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/nvrm/gsp.h index b6075021e74f5..c458569af9d72 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/nvrm/gsp.h +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/nvrm/gsp.h @@ -523,6 +523,14 @@ typedef struct =20 #define NV2080_CTRL_GPU_SET_POWER_STATE_GPU_LEVEL_3 (0x00000003= U) =20 +#define GPU_STATE_FLAGS_PRESERVING BIT(0) // GPU state is preserv= ed +#define GPU_STATE_FLAGS_VGA_TRANSITION BIT(1) // To be used with GPU= _STATE_FLAGS_PRESERVING. +#define GPU_STATE_FLAGS_PM_TRANSITION BIT(2) // To be used with GPU= _STATE_FLAGS_PRESERVING. +#define GPU_STATE_FLAGS_PM_SUSPEND BIT(3) +#define GPU_STATE_FLAGS_PM_HIBERNATE BIT(4) +#define GPU_STATE_FLAGS_GC6_TRANSITION BIT(5) // To be used with GPU_= STATE_FLAGS_PRESERVING. +#define GPU_STATE_FLAGS_FAST_UNLOAD BIT(6) // Used during windows = restart, skips stateDestroy steps + typedef struct { // Magic for verification by secure ucode --=20 2.55.0 From nobody Mon Sep 28 23:55:24 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 607F72BEFE8 for ; Fri, 14 Aug 2026 19:46:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786736798; cv=none; b=FnuuTP9wvKmYWSnVcH8U/MlX68OOv2lyIhOIechs+nZxOuzamnfByG3NvRx4rMH/XBCf1ByN9+84Ey6AQCVnkGzISrNP11IqTlSIUpOPQFVn/p8xC1Fbvlt1PrlajyOcI4W003P8mDIU6XbPuR9zVy/8EENlo/l0NjMkY01vDng= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786736798; c=relaxed/simple; bh=5S7vfs5PRPttb90RKTLuThmDKuwMxYHwna2aEFa2CVk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LPgRo3k/Et3rwb6VMToNdgWvByDazW0s4gYS+OjB14doI2MtfyMmRhNb8jssO37jjdaTVcUzBb9IoJ+q1FlUTXCDPj6n795Z1RABPqZfesD1ibC0kez4v7wfSWknbv41cf08+zgGLJdAeWyIFL/ifLM3hWtlPGYKctCBhz9lX6o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=AlOV9Yhc; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="AlOV9Yhc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786736796; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gnaYVu/GD97GKQMIMPl79VFubCmSwD4Rwvc2jI8c6no=; b=AlOV9YhcfSzU0mbZBvTm2U3mcPqIYYPdqwqocKlYHPrwVtngT016+why70FD30XZRUepvp XJ1HxALQLE8q2Ezg4Hn+cvaRwPmd0GVjjNPFqj6VLoLeFZHDTbdOFfgPTOAa2DCbh3n/Ml U+HNPdzra6SfKhNnjrlosu2bmRJkBeo= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-468-0Z7WCyE8MCeAVuvuwP9HsA-1; Fri, 14 Aug 2026 15:46:21 -0400 X-MC-Unique: 0Z7WCyE8MCeAVuvuwP9HsA-1 X-Mimecast-MFC-AGG-ID: 0Z7WCyE8MCeAVuvuwP9HsA_1786736779 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4E5671956094; Fri, 14 Aug 2026 19:46:19 +0000 (UTC) Received: from GoldenWind.lan (unknown [10.22.64.233]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id EDA1930001A2; Fri, 14 Aug 2026 19:46:15 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org, "Timur Tabi" , "Dave Airlie" , "Andy Shevchenko" , "Maarten Lankhorst" , "Ben Skeggs" , "Kees Cook" , "Simona Vetter" , "David Airlie" , "Thomas Zimmermann" , "Maxime Ripard" , "Mel Henning" , "Danilo Krummrich" , "Lyude Paul" Subject: [PATCH v5 4/4] drm/nouveau/gsp: Increase delay for magic sleep in r535_gsp_fini() Date: Fri, 14 Aug 2026 15:43:51 -0400 Message-ID: <20260814194542.781955-5-lyude@redhat.com> In-Reply-To: <20260814194542.781955-1-lyude@redhat.com> References: <20260814194542.781955-1-lyude@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" 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=3D1 in GspSystemInfo So, until we can figure this out properly - just sleep for longer. Signed-off-by: Lyude Paul Fixes: 53dac0623853 ("drm/nouveau/gsp: add support for 570.144") Cc: # v6.16+ Reviewed-by: Dave Airlie --- 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/driver= s/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_suspen= d_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); } =20 ret =3D r535_gsp_rpc_unloading_guest_driver(gsp, suspend); --=20 2.55.0