Fix bug where `read_more_at_offset` would unnecessarily read more data.
This happens when the window to read has some part cached and some part
not. It would read `len` bytes instead of just the uncached portion,
which could read past `BIOS_MAX_SCAN_LEN`.
Fixes: 6fda04e7f0 ("gpu: nova-core: vbios: Add base support for VBIOS construction and iteration")
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260525-fix-vbios-v5-3-e5e455251537@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Update nova/Makefile and nova-core/Makefile so that nova-drm.ko and
nova-core.ko are produced, matching the module names set in patch 1.
Update drm::DriverInfo with the correct driver name and vendor
description. Fix Kconfig help text for both drivers and the debugfs
directory name in nova-core to match the new module names.
Closes: https://github.com/Rust-for-Linux/linux/issues/1228
Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
Link: https://patch.msgid.link/20260507185012.1527139-3-yphbchou0911@gmail.com
[ Change commit subject to "gpu: nova: Use module names consistently";
slightly adjust commit message. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
This provides a mechanism to create (or look up) VMBO instances, which
represent the mapping between GPUVM and GEM objects.
The GpuVmBoRegistered<T> type can be considered like ARef<GpuVm<T>>,
except that no way to increment the refcount is provided.
The GpuVmBoAlloc<T> type is more akin to a pre-allocated GpuVmBo<T>, so
it's not really a GpuVmBo<T> yet. Its destructor could call
drm_gpuvm_bo_destroy_not_in_lists(), but as the type is currently
private and never called anywhere, this perf optimization does not need
to happen now.
Pre-allocating and obtaining the gpuvm_bo object is exposed as a single
step. This could theoretically be a problem if one wanted to call
drm_gpuvm_bo_obtain_prealloc() during the fence signalling critical
path, but that's not a possibility because:
1. Adding the BO to the extobj list requires the resv lock, so it cannot
happen during the fence signalling critical path.
2. obtain() requires that the BO is not in the extobj list, so obtain()
must be called before adding the BO to the extobj list.
Thus, drm_gpuvm_bo_obtain_prealloc() cannot be called during the fence
signalling critical path. (For extobjs at least.)
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-2-b16e6ada7261@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add a GPUVM abstraction to be used by Rust GPU drivers.
GPUVM keeps track of a GPU's virtual address (VA) space and manages the
corresponding virtual mappings represented by "GPU VA" objects. It also
keeps track of the gem::Object<T> used to back the mappings through
GpuVmBo<T>.
This abstraction is only usable by drivers that wish to use GPUVM in
immediate mode. This allows us to build the locking scheme into the API
design. It means that the GEM mutex is used for the GEM gpuva list, and
that the resv lock is used for the extobj list. The evicted list is not
yet used in this version.
This abstraction provides a special handle called the UniqueRefGpuVm,
which is a wrapper around ARef<GpuVm> that provides access to the
interval tree. Generally, all changes to the address space requires
mutable access to this unique handle.
Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Co-developed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-1-b16e6ada7261@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tyr buffer objects are shmem-backed, so the driver should use
drm:💎:shmem::Object<BoData> as its GEM object type instead of the base
drm:💎:Object<BoData> type.
Switching to the shmem GEM object type matches how Tyr allocates and
manages its buffer objects, and uses the shmem-specific GEM abstraction
provided by the DRM Rust bindings.
Select RUST_DRM_GEM_SHMEM_HELPER to ensure the required helpers are
available when DRM_TYR is enabled.
Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260428-fw-boot-prerequisites-v1-3-c69af9abe1af@collabora.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Currently Tyr disables its clocks from TyrDrmDeviceData::drop(), which
causes them to be shut down before any other fields in TyrDrmDeviceData
are dropped. This prevents us from using the clocks when dropping the
other fields in TyrDrmDeviceData.
In order to better control when the clocks are dropped, move this cleanup
logic into a Drop implementation on the Clocks struct itself.
Since it serves no further purpose, remove the PinnedDrop implementation
for TyrDrmDeviceData.
Also, while here, remove the #[pin_data] annotation from both the struct
Clocks and struct Regulators since neither of these structs need this
macro to create structurally pinned fields.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260428-fw-boot-prerequisites-v1-1-c69af9abe1af@collabora.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Introduce a GpuHal trait and per-family dispatch so GPU boot
behavior can vary by architecture. Move wait_gfw_boot_completion()
from the standalone gfw module into gpu/hal/tu102.rs as the first
GpuHal implementation. All architectures currently dispatch to this
implementation, preserving existing behavior.
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260411024953.473149-7-jhubbard@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Make management_overhead() fail on multiplication or alignment
overflow instead of silently saturating. Propagate that failure through
wpr_heap_size() and the framebuffer layout code that consumes it.
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Link: https://patch.msgid.link/20260326013902.588242-27-jhubbard@nvidia.com
[acourbot: remove unrelated WPR2 mention from commit log.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
GA100 is a compute-only variant of GA102 that boots GSP-RM like a
Turing, although it also has its own unique requirements.
Now that all the pieces are in place, we can enable GA100 support.
Although architecturally like an Ampere, GA100 uses the same GSP-RM
firmware files as Turing, and therefore must boot it like Turing does.
However, as a compute-only part, GA100 has no display engine.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260417191359.1307434-7-ttabi@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
The GPU's ROM may begin with an Init-from-ROM (IFR) header that precedes
the PCI Expansion ROM images (VBIOS). When present, the PROM shadow
method must parse this header to determine the offset where the PCI ROM
images actually begin, and adjust all subsequent reads accordingly.
On most GPUs this is not needed because the IFR microcode has already
applied the ROM offset so that PROM reads transparently skip the header.
On GA100, for whatever reason, the IFR offset is not applied to PROM
reads. Therefore, the search for the PCI expansion must skip the IFR
header, if found.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260417191359.1307434-6-ttabi@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Introduce FbHal method frts_size() to return the size of the FRTS
window. GA100 is a special case in that although there is an
FRTS, its size must arbitrarily be set to 0.
Note that we cannot use supports_display() to determine the FRTS
size because there are other GPUs (e.g. GA102GL) that have display
disabled (and so supports_display() returns False), but the FRTS
window size still needs to be 1MB.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260417191359.1307434-5-ttabi@nvidia.com
[acourbot: apply requested fix to commit message.]
[acourbot: fix minor conflict.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Nvidia GPUs have some PCI expansion ROM sections that have an Nvidia-
specific signature instead of 0xAA55. Signature 0xBB77 is actually an
internal-only value that has been deprecated for over a decade.
Nova-core will never encounter a GPU with that signature, so don't look
for it.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260417191359.1307434-3-ttabi@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Init-from-ROM (IFR) is a special GPU feature used for power management
on some Nvidia GPUs. It references data in the VBIOS for its operation,
but for drivers the important piece is the header that precedes the
VBIOS PCI Expansion ROM. Parsing VBIOS is necessary to boot GSP-RM on
Turing, Ampere, and Ada GPUs.
Most such GPUs do not need to parse the IFR header in order to find the
VBIOS, but the Nvidia GA100 is the exception. GA100 lacks a display
engine, so the PRAMIN method (which reads the VBIOS from VRAM via
display hardware) is unavailable, forcing the driver to read the ROM
directly via PROM. On other similar GPUs, either PRAMIN succeeds before
PROM is tried, or the IFR hardware has already applied the ROM offset
so that PROM reads transparently skip the IFR header.
Note that GH100 also does not have a display engine, but it uses a
completely different method to boot GSP-RM.
This information is derived from NVIDIA's open-source GPU kernel module
driver (aka OpenRM), specifically the NV_PBUS_IFR_FMT_FIXEDx definitions
in dev_bus.h and the parsing logic in s_romImgFindPciHeader_TU102().
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Link: https://patch.msgid.link/20260408142132.3911466-1-ttabi@nvidia.com
[acourbot: fix TOTAL_DATA_SIZE definition.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Replace manual usize-to-u64 conversions of SZ_* constants with the
SizeConstants trait's associated constants on u64. With the
SizeConstants trait in scope, u64::SZ_1M replaces usize_as_u64(SZ_1M)
and similar.
This removes several now-unused imports: usize_as_u64, FromSafeCast,
and individual SZ_* type-level constants.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Acked-by: Gary Guo <gary@garyguo.net>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Link: https://patch.msgid.link/20260411024118.471294-2-jhubbard@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Define the MMU_CONTROL register block with the kernel's register! macro
and replace the existing hand-written MMU register definitions with typed
register and field accessors.
This adds typed definitions for the MMU IRQ registers and the per-address
space MMU_AS_CONTROL registers, including TRANSTAB, MEMATTR, LOCKADDR,
COMMAND, FAULTSTATUS, STATUS, and TRANSCFG. It also introduces typed
enums for MMU commands, fault types, access types, address space modes,
memory attributes, and related MMU configuration fields.
For logical 64-bit MMU registers that are exposed as split 32-bit MMIO
registers, define both the typed 64-bit view and explicit low/high 32-bit
registers so the register layout remains documented without relying on
native 64-bit MMIO accesses.
This reduces open-coded bit manipulation, keeps MMU register layout
knowledge in one place, and makes the definitions easier to read and
maintain.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-4-8abfff8a0204@collabora.com
[aliceryhl: reformat long comment]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Currently, Tyr prints just the upper 16 bits of the GPU_ID in the hex id
field, namely ARCH_MAJOR, ARCH_MINOR, ARCH_REV, and PRODUCT_MAJOR. The
VERSION_* fields are already printed separately as "major", "minor", and
"status".
Print the full 32-bit GPU_ID register instead of shifting it, so the hex
id reflects the complete register contents.
Before this change:
mali-g610 id 0xa867 major 0x0 minor 0x0 status 0x5
After this change:
mali-g610 GPU_ID 0xa8670005 major 0x0 minor 0x0 status 0x5
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260409-b4-tyr-use-register-macro-v5-v5-2-8abfff8a0204@collabora.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
