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

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 <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260430223838.2530778-5-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>

0 files changed, 0 insertions, 0 deletions