[PATCH] drm/nouveau: expose VBIOS via debugfs on GSP-RM systems

[PATCH] drm/nouveau: expose VBIOS via debugfs on GSP-RM systems

[Timur Tabi]

When Nouveau boots with GSP-RM, it bypasses several traditional code
paths to allow GSP-RM to handle those features.  In particular,
some VBIOS parsing is skipped, and a side effect is that the VBIOS
is not exposed in the DRM debugfs entries.

Fix this by updating the drm BIOS struct (nvbios) with the VBIOS data
from the nvkm BIOS struct (nvkm_bios).  This happens normally in
NVInitVBIOS(), but that function is skipped when booting with GSP-RM.

Signed-off-by: Timur Tabi <ttabi@nvidia.com>
---
 drivers/gpu/drm/nouveau/nouveau_bios.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c
index c8335f5b49db..28bcf38cdddf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -2085,10 +2085,24 @@ nouveau_bios_init(struct drm_device *dev)
 	int ret;
 
 	/* only relevant for PCI devices */
-	if (!dev_is_pci(dev->dev) ||
-	    nvkm_gsp_rm(nvxx_device(drm)->gsp))
+	if (!dev_is_pci(dev->dev))
 		return 0;
 
+	if (nvkm_gsp_rm(nvxx_device(drm)->gsp)) {
+		struct nvkm_bios *nvkm_bios = nvxx_bios(drm);
+
+		/*
+		 * The VBIOS data was already read by the nvkm layer during
+		 * nvkm_bios_new(). Point the legacy DRM-level VBIOS structure
+		 * at the same buffer so that any remaining legacy code can
+		 * access it. This exposes the VBIOS via the DRM debugfs entries.
+		 */
+		bios->data = nvkm_bios->data;
+		bios->length = nvkm_bios->size;
+
+		return 0;
+	}
+
 	if (!NVInitVBIOS(dev))
 		return -ENODEV;
 
-- 
2.53.0

Re: [PATCH] drm/nouveau: expose VBIOS via debugfs on GSP-RM systems

[Danilo Krummrich]

On Tue Apr 7, 2026 at 8:53 PM CEST, Timur Tabi wrote:
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c
> index c8335f5b49db..28bcf38cdddf 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bios.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
> @@ -2085,10 +2085,24 @@ nouveau_bios_init(struct drm_device *dev)
>  	int ret;
>  
>  	/* only relevant for PCI devices */
> -	if (!dev_is_pci(dev->dev) ||
> -	    nvkm_gsp_rm(nvxx_device(drm)->gsp))
> +	if (!dev_is_pci(dev->dev))
>  		return 0;
>  
> +	if (nvkm_gsp_rm(nvxx_device(drm)->gsp)) {
> +		struct nvkm_bios *nvkm_bios = nvxx_bios(drm);

Can this pointer ever be NULL? Before we had a nvkm_gsp_rm() check and I think
that some GSP chipsets can have a nvxx_bios() return a NULL pointer.

> +
> +		/*
> +		 * The VBIOS data was already read by the nvkm layer during
> +		 * nvkm_bios_new(). Point the legacy DRM-level VBIOS structure
> +		 * at the same buffer so that any remaining legacy code can
> +		 * access it. This exposes the VBIOS via the DRM debugfs entries.
> +		 */
> +		bios->data = nvkm_bios->data;
> +		bios->length = nvkm_bios->size;
> +
> +		return 0;
> +	}
> +
>  	if (!NVInitVBIOS(dev))
>  		return -ENODEV;
>  
> -- 
> 2.53.0

Re: [PATCH] drm/nouveau: expose VBIOS via debugfs on GSP-RM systems

[Timur Tabi]

On Tue, 2026-04-28 at 17:53 +0200, Danilo Krummrich wrote:
> On Tue Apr 7, 2026 at 8:53 PM CEST, Timur Tabi wrote:
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c
> > index c8335f5b49db..28bcf38cdddf 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bios.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
> > @@ -2085,10 +2085,24 @@ nouveau_bios_init(struct drm_device *dev)
> >  	int ret;
> >  
> >  	/* only relevant for PCI devices */
> > -	if (!dev_is_pci(dev->dev) ||
> > -	    nvkm_gsp_rm(nvxx_device(drm)->gsp))
> > +	if (!dev_is_pci(dev->dev))
> >  		return 0;
> >  
> > +	if (nvkm_gsp_rm(nvxx_device(drm)->gsp)) {
> > +		struct nvkm_bios *nvkm_bios = nvxx_bios(drm);
> 
> Can this pointer ever be NULL? Before we had a nvkm_gsp_rm() check and I think
> that some GSP chipsets can have a nvxx_bios() return a NULL pointer.

Yes, you are correct, this can be NULL.  I will post a v2.

BTW, there's another debugfs patch that was posted months ago that you should consider:

https://lists.freedesktop.org/archives/nouveau/2025-August/051235.html

Looks like the author never followed-up to make sure it was reviewed.