linux-toradex.git/drivers/gpu/drm/nouveau/nvkm/subdev/gsp, branch master

Revert "nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)"

2026-05-28T20:49:53+00:00

This is probably too risky, see the discussion here:

  https://lists.freedesktop.org/archives/dri-devel/2026-May/570353.html

This reverts commit 6198977a78af8769d3f3108e830901325b97cf03.

Signed-off-by: Lyude Paul 
Reviewed-by: Timur Tabi 
Link: https://patch.msgid.link/20260528192847.4077458-4-lyude@redhat.com
Signed-off-by: Danilo Krummrich

Revert "nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation"

2026-05-28T20:49:52+00:00

This is probably too risky, see the discussion here:

  https://lists.freedesktop.org/archives/dri-devel/2026-May/570353.html

This reverts commit 67346c90ce275e835e93a4a13041afee47bd3f9e.

Signed-off-by: Lyude Paul 
Reviewed-by: Timur Tabi 
Link: https://patch.msgid.link/20260528192847.4077458-3-lyude@redhat.com
Signed-off-by: Danilo Krummrich

Revert "nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage"

2026-05-28T20:49:52+00:00

This reverts commit 1a80c009e27b42e8c202d4c5dbd9dad9e22af742.

Embarassingly, it seems that I completely missed a pretty big issue this
patch causes according to Danilo and Sashiko:

https://lists.freedesktop.org/archives/dri-devel/2026-May/570353.html

Where it seems this causes some machines to segfault during nouveau probe.

So, revert this for the time being.

Signed-off-by: Lyude Paul 
Reviewed-by: Timur Tabi 
Link: https://patch.msgid.link/20260528192847.4077458-2-lyude@redhat.com
Signed-off-by: Danilo Krummrich

drm/nouveau/gsp: require GSP-RM for GA100 support

2026-05-28T17:30:15+00:00

Nouveau supports Turing and Ampere GPUs with or without GSP-RM.
Support without GSP-RM is mostly academic, since GSP-RM is
needed to run the GPU at full clocks.  It is also the default
mode for these GPUs.

GA100 is a special case, however.  The current code has some support
for running GA100 without GSP-RM, but several features are missing.
More importantly, some required firmware images like ucode_ahesasc.bin
are not available and would need to be provided by Nvidia.

To prevent Nouveau from even trying to boot on GA100 without GSP-RM,
remove the non-GSP fallback option in the ga100_gsps[] array.

Signed-off-by: Timur Tabi 
Reviewed-by: Lyude Paul 
Link: https://patch.msgid.link/20260430223838.2530778-10-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich

drm/nouveau: GA100 has an FRTS region size of zero

2026-05-28T17:30:15+00:00

When booting with GSP-RM, the FRTS data region normally needs to be
allocated.  However, on GA100, this region is not used and so its
size needs to be set to zero.

The truth is that GA100 is just special, and the simplest way to
determine the proper FRTS data region size is to check for this
GPU specifically.

Signed-off-by: Timur Tabi 
Link: https://patch.msgid.link/20260430223838.2530778-7-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich

drm/nouveau: only boot FRTS if its region is allocated

2026-05-28T17:30:15+00:00

On some Nvidia GPUs (i.e. GA100), the FRTS region is not allocated
(its size is set to 0).  In such cases, FWSEC-FRTS should not be run.

Signed-off-by: Timur Tabi 
Link: https://patch.msgid.link/20260430223838.2530778-6-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich

drm/nouveau/gsp: read MMU_LOCK to fix WPR placement on GA100

2026-05-28T17:30:15+00:00

On GA100, the row remapper hardware reserves a small amount of DRAM at
the end of framebuffer for spare rows used to repair memory errors at
runtime.  When an uncorrectable ECC error is detected in a DRAM row,
the row remapper redirects accesses to a spare row, transparently
repairing the fault.

The LOCAL_MEMORY_RANGE register (0x100ce0) reports the GPU's FB address
range, but its encoding rounds to 1GB boundaries.  On GA100, VBIOS
originally rounded this value down, which could lose up to ~1GB of
usable FB.  As a workaround, newer VBIOS instead rounds up to the next
1GB boundary and programs MMU_LOCK (registers 0x1fa82c/0x1fa830) to
mark the gap between the actual usable FB and the rounded-up range as
reserved.

OpenRM's kgspCalculateFbLayout_TU102() handles this by reading the
MMU_LOCK registers and computing the WPR top boundary as:

    vbiosReservedOffset = min(mmuLockLo, vgaWorkspaceOffset)

Without this, the WPR region is placed at the top of LOCAL_MEMORY_RANGE,
which overlaps the reserved region.  The booter firmware detects this
and rejects the WPR layout.

Add ga100_gsp_mmu_lock_lo() to read the MMU_LOCK range and clamp
gsp->fb.bios.addr accordingly, mirroring OpenRM's behavior.

This is a GA100-only issue.  GA102 and later add the
NV_USABLE_FB_SIZE_IN_MB register which reports the correct usable FB
size directly, eliminating the need for the MMU_LOCK workaround.

Signed-off-by: Timur Tabi 
Link: https://patch.msgid.link/20260430223838.2530778-5-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich

drm/nouveau/gsp: use fb.bios.addr for gspFwWprEnd instead of vga_workspace.addr

2026-05-28T17:30:15+00:00

In OpenRM's kgspCalculateFbLayout_TU102(), gspFwWprEnd is derived from
vbiosReservedOffset, which is computed as:

    vbiosReservedOffset = min(mmuLockLo, vgaWorkspaceOffset)

The VGA workspace offset is one input into this calculation, not the
direct source of gspFwWprEnd.  vbiosReservedOffset is the effective
top boundary for WPR2 placement, and it may be lower than the VGA
workspace when VBIOS has locked a region via MMU_LOCK.

In Nouveau, gsp->fb.bios.addr is the equivalent of vbiosReservedOffset,
while gsp->fb.bios.vga_workspace.addr corresponds to the raw VGA
workspace location.  The original code assigned vga_workspace.addr to
gspFwWprEnd, which produced the correct result only because bios.addr
was always set equal to vga_workspace.addr and never adjusted.

Use gsp->fb.bios.addr for gspFwWprEnd to correctly mirror OpenRM's
layout logic, so that future adjustments to bios.addr (such as clamping
it to an MMU_LOCK boundary) are properly reflected in the WPR metadata
passed to the booter.

Signed-off-by: Timur Tabi 
Link: https://patch.msgid.link/20260430223838.2530778-4-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich

nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage

2026-05-28T16:49:57+00:00

Clean up the remaining IS_ERR_OR_NULL() checks in ctrl.c and rpc.c.
The underlying functions return error pointers, so IS_ERR() is
sufficient.

This affects:
- r535_gsp_rpc_ctrl() in ctrl.c
- r535_gsp_rpc_ctor() in rpc.c

Signed-off-by: Hongling Zeng 
Signed-off-by: Lyude Paul 
Link: https://patch.msgid.link/20260528062451.54107-6-zenghongling@kylinos.cn
Reviewed-by: Lyude Paul

nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)

2026-05-28T16:49:57+00:00

Replace WARN_ON(IS_ERR_OR_NULL()) with WARN_ON(IS_ERR()) in various
GSP-RM files. The underlying functions return error pointers, so
checking for NULL is redundant.

This affects:
- r535_bar_bar2_update_pde() in bar.c

Signed-off-by: Hongling Zeng 
Signed-off-by: Lyude Paul 
Link: https://patch.msgid.link/20260528062451.54107-5-zenghongling@kylinos.cn
Reviewed-by: Lyude Paul