summaryrefslogtreecommitdiff
path: root/drivers/gpu/nova-core/firmware
AgeCommit message (Collapse)Author
2026-08-06rust: dma: rename dma_handle to dma_addressAlexandre Courbot
The `dma_handle` naming is inherited from the C API, but what this really describes is the device DMA address; everything named `dma_handle` is actually a `dma_addr_t`. This naming introduces some confusion on the Rust API side, as handles are supposed to be opaque tokens, yet we were doing address computation on values returned by `dma_handle`. Rename `dma_handle` to `dma_address` while nova-core is still its only user. Suggested-by: John Hubbard <jhubbard@nvidia.com> Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/all/DK75LUA4NLGI.3P29AIZQE20V2@kernel.org/ Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://patch.msgid.link/20260805-falcon-dma-projections-v2-2-4cc9f3f13ee9@nvidia.com [ Rebase and fix up build failures due to newly introduced dma_handle() calls. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-08-06gpu: nova-core: transition fsp to TLV imagesTimur Tabi
Switch the FSP firmware loaders from the legacy ELF32 format to the new TLV format. This change requires the new TLV versions of the r570.144 firmware images. Because we are no longer loading ELF images, we can also delete the ELF parser. Also remove function request_firmware() as this was the last user. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260731201017.2580713-8-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-08-06gpu: nova-core: transition gen_bootloader to TLV imagesTimur Tabi
Switch the generic bootloader firmware loader from the legacy binary format to the TLV format. This change requires the new TLV versions of the r570.144 firmware images. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260731201017.2580713-7-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-08-06gpu: nova-core: transition gsp to TLV imagesTimur Tabi
Switch the GSP firmware loader from the legacy binary format to the TLV format. This change requires the new TLV versions of the r570.144 firmware images. Unlike the other TLV firmware images, gsp.tlv contains a pointer to the actual GSP firmware file instead of its contents. This allows each small gsp.tlv file to contain the distinct metadata for each GPU while still allowing the very large gsp.bin to be shared by all GPUs. One key piece of metadata is the signature. The legacy GSP firmware image is an ELF file that contains multiple sections that needed to be parsed, and the driver needed to determine which section is relevant for the GPU. Instead, gsp.tlv contains the pre-processed metadata, so all the driver needs to do is to extract it. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260731201017.2580713-6-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-08-06gpu: nova-core: transition booter to TLV imagesTimur Tabi
Switch the booter firmware loader from the legacy binary format to the TLV format. This change requires the new TLV versions of the r570.144 firmware images. The new TLV format has all of the metadata needed by Nova encoded as separate tags, eliminating the need to parse legacy firmware headers such as HsHeaderV2 and HsSignatureParams. All of the structs and code for parsing those headers is therefore deleted. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260731201017.2580713-5-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-08-06gpu: nova-core: add TLV parser for firmware filesTimur Tabi
TLV (type, length, value) files are the new image format used by Nova to encapsulate firmware images and their metadata. Unlike the firmware files for previous versions of the firmware, TLV filenames are not versioned, and they have a .tlv suffix. Add function request_tlv() to load TLV firmware images. Add the Tlv struct and supporting types for parsing TLV firmware images. TLV files begin with a 4-byte magic header, which must be "NVFW" for Nvidia firmware files. This is followed by a sequence of blocks each containing a 4-byte ASCII tag, a 4-byte little-endian length, and a payload padded to a 4-byte boundary. Tlv::new() validates the entire image up front, so that the iterator can subsequently yield blocks without fallible parsing. Also add accessor methods for the various encoded types that will be used by the driver. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260731201017.2580713-4-ttabi@nvidia.com [ Drop unnecessary payload.is_empty() check in Tlv::new(), use EINVAL instead of ENODATA in Tlv::get_bytes() and add a corresponding TODO comment. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-15gpu: nova-core: move GSP firmware files decision to GSP HALEliot Courtney
The files to give the `ModInfoBuilder` depend on the chipset; this is HAL information, so move it there. Doing so lets us remove the `uses_fsp` and `needs_fwsec_bootloader` ad-hoc methods of `Chipset`. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-9-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-29gpu: nova-core: falcon: store bar and dev in falconTim Kovalenko
Store the bound device and `BAR0` mapping in `Falcon` instead of passing them through every `Falcon` operation. This simplifies the `Falcon` API and removes repeated `dev`/`bar` plumbing from reset, load, boot, mailbox, DMA, and GSP/FSP-specific Falcon helpers. `FalconHal` now receives a reference to a `Falcon` and uses its methods and members instead of passing them individually. Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/509436-Nova/topic/Storing.20driver-bound.20references.20into.20sub-devices/near/599137882 Signed-off-by: Tim Kovalenko <tim.kovalenko@proton.me> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260625-drm-bar-refactor-v2-1-9db6b890d92e@proton.me Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-10gpu: nova-core: remove imports available from preludeGary Guo
No functional changes intended. Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260610135716.1013688-1-gary@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-03gpu: nova-core: move lifetime to `Bar0`Gary Guo
Currently Nova code uses `&'a Bar0` a lot. This is `&'a Mmio`, where `Mmio` represents an owned MMIO region; this type only exists as a target for `Deref` so `Bar` and `IoMem` can share code and should be avoided to be named directly. The upcoming I/O projection series would make `Io` trait much simpler to implement, and thus the owned MMIO type would be removed in favour of direct `Io` implementation on `Bar` and `IoMem`. Add lifetime parameter to `Bar0<'a>` and change it to be alias of `&'a pci::Bar<'a, ..>`. This also prepares Nova core so that when I/O projection series land, this could be changed to using a MMIO view type directly which avoids double indirection. Signed-off-by: Gary Guo <gary@garyguo.net> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602170416.2268531-1-gary@kernel.org [ Rebase onto latest drm-rust-next (Blackwell enablement). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-03gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust bootJohn Hubbard
Build and send the Chain of Trust message to FSP, bundling the DMA-coherent boot parameters that FSP reads at boot time. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260603-b4-blackwell-v13-6-d9f3a06939e0@nvidia.com [acourbot: rename `frts_offset` to `frts_vidmem_offset`.] [acourbot: add note about frts_sysmem_* CoT members.] Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: Hopper/Blackwell: add FMC signature extractionJohn Hubbard
Extract the SHA-384 hash, RSA public key, and RSA signature from the FMC ELF32 firmware sections. FSP Chain of Trust verification needs these to validate the FMC image during boot. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-14-jhubbard@nvidia.com [acourbot: derive `Zeroable` on `FmcSignature` for in-place initialization] Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: Hopper/Blackwell: add FMC firmware imageJohn Hubbard
FSP is the Falcon that runs FMC firmware on Hopper and Blackwell. Load the FMC ELF in two forms: the image section that FSP boots from, and the full Firmware object for later signature extraction during Chain of Trust verification. Declare the FMC image in the module's firmware table so it is bundled for FSP-based chipsets. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-12-jhubbard@nvidia.com Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-02gpu: nova-core: add auto-detection of 32-bit, 64-bit firmware imagesJohn Hubbard
A firmware image may be either a 32-bit or a 64-bit ELF, and callers should not have to know which. Detect the ELF class from the image header at parse time and dispatch to the matching parser, so a single entry point handles both layouts. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260602032111.224790-10-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-05-30gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbindingAlexandre Courbot
When probing the driver, the FWSEC-FRTS firmware creates a WPR2 secure memory region to store the GSP firmware, and the Booter Loader loads and starts that firmware into the GSP, making it run in RISC-V mode. These operations need to be reverted upon unloading, particularly the WPR2 secure region creation, as its presence prevents the driver from subsequently probing. Thus, prepare the Booter Unloader and FWSEC-SB firmware images when booting the GSP, so they can be executed at unbind time to put the GPU into a state where it can be probed again. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Co-developed-by: Eliot Courtney <ecourtney@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260529-nova-unload-v7-3-678f39209e00@nvidia.com [acourbot: `Result<()>` -> `Result`] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-05-29gpu: nova-core: refactor SEC2 booter loading into BooterFirmware::run()John Hubbard
Move the SEC2 reset/load/boot sequence into a BooterFirmware::run() method. This is mostly refactoring, with no significant behavior change, done in preparation for adding an alternative FSP boot path. Suggested-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260521-nova-unload-v6-4-65f581c812c9@nvidia.com [acourbot: fix typo in commit message.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-04-30gpu: nova-core: Hopper/Blackwell: basic GPU identificationJohn Hubbard
Hopper (GH100) and Blackwell identification, including ELF .fwsignature_* items. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260411024953.473149-4-jhubbard@nvidia.com [acourbot: add separators for both Blackwell architectures in Chipset definition.] [acourbot: make Gsp::boot() return `ENOTSUPP` on new architectures.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-04-30gpu: nova-core: factor .fwsignature* selection into a new ↵John Hubbard
find_gsp_sigs_section() Keep Gsp::new() from getting too cluttered, by factoring out the selection of .fwsignature* items. This will continue to grow as we add GPUs. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260411024953.473149-2-jhubbard@nvidia.com [acourbot: fix minor conflict.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-04-29gpu: nova-core: use correct fwsignature for GA100Timur Tabi
Although GA100 uses the same GSP-RM firmware as Turing, it has a different signature specifically for it. Fixes: 121ea04cd9f2 ("gpu: nova-core: add support for Turing/GA100 fwsignature") 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-2-ttabi@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-30gpu: nova-core: firmware: move firmware image parsing code to firmware.rsJohn Hubbard
Up until now, only the GSP required parsing of its firmware headers. However, upcoming support for Hopper/Blackwell+ adds another firmware image (FMC), along with another format (ELF32). Therefore, the current ELF64 section parsing support needs to be moved up a level, so that both of the above can use it. There are no functional changes. This is pure code movement. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260326013902.588242-8-jhubbard@nvidia.com [acourbot: use fuller prefix in commit message.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28gpu: nova-core: firmware: gsp: use dma::Coherent for level0 tableAlexandre Courbot
Replace the nova-core local `DmaObject` with a `CoherentBox` that can fulfill the same role. Since `CoherentBox` is more flexible than `DmaObject`, we can use the native `u64` type for page table entries instead of messing with bytes. The `dma` module becomes unused with that change, so remove it as well. Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-7-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28gpu: nova-core: firmware: gsp: use dma::Coherent for signaturesAlexandre Courbot
Replace the nova-core local `DmaObject` with a `Coherent` that can fulfill the same role. Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-6-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28gpu: nova-core: firmware: fwsec: use dma::CoherentAlexandre Courbot
Replace the nova-core local `DmaObject` with a `Coherent` that can fulfill the same role. Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-3-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28gpu: nova-core: firmware: riscv: use dma::CoherentAlexandre Courbot
Replace the nova-core local `DmaObject` with a `Coherent` that can fulfill the same role. Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-2-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-26gpu: nova-core: convert falcon registers to kernel register macroAlexandre Courbot
Convert all PFALCON, PFALCON2 and PRISCV registers to use the kernel's register macro and update the code accordingly. Because they rely on the same types to implement relative registers, they need to be updated in lockstep. nova-core's local register macro is now unused, so remove it. Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260325-b4-nova-register-v4-8-bdf172f0f6ca@nvidia.com [acourbot@nvidia.com: remove unused import.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09gpu: nova-core: use the Generic Bootloader to boot FWSEC on TuringTimur Tabi
On Turing and GA100, a new firmware image called the Generic Bootloader (gen_bootloader) must be used to load FWSEC into Falcon memory. The driver loads the generic bootloader into Falcon IMEM, passes a descriptor that points to FWSEC using DMEM, and then boots the generic bootloader. The bootloader will then load FWSEC into IMEM and boot it. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260306-turing_prep-v11-12-8f0042c5d026@nvidia.com
2026-03-09gpu: nova-core: move brom_params and boot_addr to FalconFirmwareAlexandre Courbot
These methods are relevant no matter the loading method used, thus move them to the common `FalconFirmware` trait. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260306-turing_prep-v11-5-8f0042c5d026@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09gpu: nova-core: falcon: rename load parameters to reflect DMA dependencyAlexandre Courbot
The current `FalconLoadParams` and `FalconLoadTarget` types are fit for DMA loading, but not so much for PIO loading which will require its own types. Start by renaming them to something that indicates that they are indeed DMA-related. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260306-turing_prep-v11-3-8f0042c5d026@nvidia.com [acourbot@nvidia.com: fixup order of import items.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09gpu: nova-core: create falcon firmware DMA objects lazilyAlexandre Courbot
When DMA was the only loading option for falcon firmwares, we decided to store them in DMA objects as soon as they were loaded from disk and patch them in-place to avoid having to do an extra copy. This decision complicates the PIO loading patch considerably, and actually does not even stand on its own when put into perspective with the fact that it requires 8 unsafe statements in the code that wouldn't exist if we stored the firmware into a `KVVec` and copied it into a DMA object at the last minute. The cost of the copy is, as can be expected, imperceptible at runtime. Thus, switch to a lazy DMA object creation model and simplify our code a bit. This will also have the nice side-effect of being more fit for PIO loading. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260306-turing_prep-v11-1-8f0042c5d026@nvidia.com [acourbot@nvidia.com: add TODO item to switch back to a coherent allocation when it becomes convenient to do so.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-02-25gpu: nova-core: use checked arithmetic in RISC-V firmware parsingJoel Fernandes
Use checked_add() when computing offsets from firmware-provided values in the RISC-V firmware parsing code. These values come from the BinHdr structure parsed from the firmware file header. Reviewed-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260126202305.2526618-6-joelagnelf@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-02-25gpu: nova-core: use checked arithmetic in frombytes_at helperJoel Fernandes
Use checked_add() when computing the end offset in the frombytes_at() helper function. This function is called with firmware-provided offsets. Reviewed-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260126202305.2526618-4-joelagnelf@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-02-25gpu: nova-core: use checked arithmetic in Booter signature parsingJoel Fernandes
Use checked_add() when computing signature offsets from firmware- provided values in signatures_iter(). Without checked arithmetic, overflow could wrap to a small plausible offset that points to entirely wrong data. Reviewed-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260126202305.2526618-3-joelagnelf@nvidia.com [acourbot@nvidia.com: remove obvious computation comments.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-02-25gpu: nova-core: use checked arithmetic in FWSEC firmware parsingJoel Fernandes
Use checked_add() and checked_mul() when computing offsets from firmware-provided values in new_fwsec(). Without checked arithmetic, corrupt firmware could cause integer overflow. The danger is not just wrapping to a huge value, but potentially wrapping to a small plausible offset that passes validation yet accesses entirely wrong data, causing silent corruption or security issues. Reviewed-by: Zhi Wang <zhiw@nvidia.com> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260126202305.2526618-2-joelagnelf@nvidia.com [acourbot@nvidia.com: rewrap commit message to make checkpatch happy.] [acourbot@nvidia.com: add missing empty lines after new code blocks.] [acourbot@nvidia.com: move SAFETY comments to the unsafe statement they describe.] [acourbot@nvidia.com: remove obvious computation comments and use `CALC:` for the remaining ones.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-02-11Merge tag 'drm-next-2026-02-11' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm updates from Dave Airlie: "Highlights: - amdgpu support for lots of new IP blocks which means newer GPUs - xe has a lot of SR-IOV and SVM improvements - lots of intel display refactoring across i915/xe - msm has more support for gen8 platforms - Given up on kgdb/kms integration, it's too hard on modern hw core: - drop kgdb support - replace system workqueue with percpu - account for property blobs in memcg - MAINTAINERS updates for xe + buddy rust: - Fix documentation for Registration constructors - Use pin_init::zeroed() for fops initialization - Annotate DRM helpers with __rust_helper - Improve safety documentation for gem::Object::new() - Update AlwaysRefCounted imports - mm: Prevent integer overflow in page_align() atomic: - add drm_device pointer to drm_private_obj - introduce gamma/degamma LUT size check buddy: - fix free_trees memory leak - prevent BUG_ON bridge: - introduce drm_bridge_unplug/enter/exit - add connector argument to .hpd_notify - lots of recounting conversions - convert rockchip inno hdmi to bridge - lontium-lt9611uxc: switch to HDMI audio helpers - dw-hdmi-qp: add support for HPD-less setups - Algoltek AG6311 support panels: - edp: CSW MNE007QB3-1, AUO B140HAN06.4, AUO B140QAX01.H - st75751: add SPI support - Sitronix ST7920, Samsung LTL106HL02 - LG LH546WF1-ED01, HannStar HSD156J - BOE NV130WUM-T08 - Innolux G150XGE-L05 - Anbernic RG-DS dma-buf: - improve sg_table debugging - add tracepoints - call clear_page instead of memset - start to introduce cgroup memory accounting in heaps - remove sysfs stats dma-fence: - add new helpers dp: - mst: avoid oob access with vcpi=0 hdmi: - limit infoframes exposure to userspace gem: - reduce page table overhead with THP - fix leak in drm_gem_get_unmapped_area gpuvm: - API sanitation for rust bindings sched: - introduce new helpers panic: - report invalid panic modes - add kunit tests i915/xe display: - Expose sharpness only if num_scalers is >= 2 - Add initial Xe3P_LPD for NVL - BMG FBC support - Add MTL+ platforms to support dpll framework _ fix DIMM_S DRM decoding on ICL - Return to using AUX interrupts - PSR/Panel replay refactoring - use consolidation HDMI tables - Xe3_LPD CD2X dividier changes xe: - vfio: add vfio_pci for intel GPU - multi queue support - dynamic pagemaps and multi-device SVM - expose temp attribs in hwmon - NO_COMPRESSION bo flag - expose MERT OA unit - sysfs survivability refactor - SRIOV PF: add MERT support - enable SR-IOV VF migration - Enable I2C/NVM on Crescent Island - Xe3p page reclaimation support - introduce SRIOV scheduler groups - add SoC remappt support in system controller - insert compiler barriers in GuC code - define NVL GuC firmware - handle GT resume failure - fix drm scheduler layering violations - enable GSC loading and PXP for PTL - disable GuC Power DCC strategy on PTL - unregister drm device on probe error i915: - move to kernel standard fault injection - bump recommended GuC version for DG2 and MTL amdgpu: - SMUIO 15.x, PSP 15.x support - IH 6.1.1/7.1 support - MMHUB 3.4/4.2 support - GC 11.5.4/12.1 support - SDMA 6.1.4/7.1/7.11.4 support - JPEG 5.3 support - UserQ updates - GC 9 gfx queue reset support - TTM memory ops parallelization - convert legacy logging to new helpers - DC analog fixes amdkfd: - GC 11.5.4/12.1 suppport - SDMA 6.1.4/7.1 support - per context support - increase kfd process hash table - Reserved SDMA rework radeon: - convert legacy logging to new helpers - use devm for i2c adapters msm: - GPU - Document a612/RGMU dt bindings - UBWC 6.0 support (for A840 / Kaanapali) - a225 support - DPU: - Switch to use virtual planes by default - Fix DSI CMD panels on DPU 3.x - Rewrite format handling to remove intermediate representation - Fix watchdog on DPU 8.x+ - Fix TE / Vsync source setting on DPU 8.x+ - Add 3D_Mux on SC7280 - Kaanapali platform support - Fix UBWC register programming - Make RM reserve DSPP-enabled mixers for CRTCs with LMs - Gamma correction support - DP: - Enable support for eDP 1.4+ link rate tables - Fix MDSS1 DP indices on SA8775P, making them to work - Fix msm_dp_ctrl_config_msa() to work with LLVM 20 - DSI: - Document QCS8300 as compatible with SA8775P - Kaanapali platform support - DSI PHY: - switch to divider_determine_rate() - MDP5: - Drop support for MSM8998, SDM660 and SDM630 (switch over to DPU) - MDSS: - Kaanapali platform support - Fixed UBWC register programming nova-core: - Prepare for Turing support. This includes parsing and handling Turing-specific firmware headers and sections as well as a Turing Falcon HAL implementation - Get rid of the Result<impl PinInit<T, E>> anti-pattern - Relocate initializer-specific code into the appropriate initializer - Use CStr::from_bytes_until_nul() to remove custom helpers - Improve handling of unexpected firmware values - Clean up redundant debug prints - Replace c_str!() with native Rust C-string literals - Update nova-core task list nova: - Align GEM object size to system page size tyr: - Use generated uAPI bindings for GpuInfo - Replace manual sleeps with read_poll_timeout() - Replace c_str!() with native Rust C-string literals - Suppress warnings for unread fields - Fix incorrect register name in print statement nouveau: - fix big page table support races in PTE management - improve reclocking on tegra 186+ amdxdna: - fix suspend race conditions - improve handling of zero tail pointers - fix cu_idx overwritten during command setup - enable hardware context priority - remove NPU2 support - update message buffer allocation requirements - update firmware version check ast: - support imported cursor buffers - big endian fixes etnaviv: - add PPU flop reset support imagination: - add AM62P support - introduce hw version checks ivpu: - implement warm boot flow panfrost: - add bo sync ioctl - add GPU_PM_RT support for RZ/G3E SoC panthor: - add bo sync ioctl - enable timestamp propagation - scheduler robustness improvements - VM termination fixes - huge page support rockchip: - RK3368 HDMI Support - get rid of atomic_check fixups - RK3506 support - RK3576/RK3588 improved HPD handling rz-du: - RZ/V2H(P) MIPI-DSI Support v3d: - fix DMA segment size - convert to new logging helpers mediatek: - move DP training to hotplug thread - convert logging to new helpers - add support for HS speed DSI - Genio 510/700/1200-EVK, Radxa NIO-12L HDMI support atmel-hlcdc: - switch to drmm resource - support nomodeset - use newer helpers hisilicon: - fix various DP bugs renesas: - fix kernel panic on reboot exynos: - fix vidi_connection_ioctl using wrong device - fix vidi_connection deref user ptr - fix concurrency regression with vidi_context vkms: - add configfs support for display configuration * tag 'drm-next-2026-02-11' of https://gitlab.freedesktop.org/drm/kernel: (1610 commits) drm/xe/pm: Disable D3Cold for BMG only on specific platforms drm/xe: Fix kerneldoc for xe_tlb_inval_job_alloc_dep drm/xe: Fix kerneldoc for xe_gt_tlb_inval_init_early drm/xe: Fix kerneldoc for xe_migrate_exec_queue drm/xe/query: Fix topology query pointer advance drm/xe/guc: Fix kernel-doc warning in GuC scheduler ABI header drm/xe/guc: Fix CFI violation in debugfs access. accel/amdxdna: Move RPM resume into job run function accel/amdxdna: Fix incorrect DPM level after suspend/resume nouveau/vmm: start tracking if the LPT PTE is valid. (v6) nouveau/vmm: increase size of vmm pte tracker struct to u32 (v2) nouveau/vmm: rewrite pte tracker using a struct and bitfields. accel/amdxdna: Fix incorrect error code returned for failed chain command accel/amdxdna: Remove hardware context status drm/bridge: imx8qxp-pixel-combiner: Fix bailout for imx8qxp_pc_bridge_probe() drm/panel: ilitek-ili9882t: Remove duplicate initializers in tianma_il79900a_dsc drm/i915/display: fix the pixel normalization handling for xe3p_lpd drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free drm/exynos: vidi: fix to avoid directly dereferencing user pointer drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl() ...
2026-01-30gpu: nova-core: remove imports available via preludeGary Guo
These imports are already in scope by importing `kernel::prelude::*` and does not need to be imported separately. Signed-off-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260123172007.136873-2-gary@garyguo.net Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-24gpu: nova-core: add FalconUCodeDescV2 supportTimur Tabi
The FRTS firmware in Turing and GA100 VBIOS has an older header format (v2 instead of v3). To support both v2 and v3 at runtime, add the FalconUCodeDescV2 struct, and update code that references the FalconUCodeDescV3 directly with a FalconUCodeDesc enum that encapsulates both. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260122222848.2555890-11-ttabi@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-01-24gpu: nova-core: add Falcon HAL method load_method()Timur Tabi
Some GPUs do not support using DMA to transfer code/data from system memory to Falcon memory, and instead must use programmed I/O (PIO). Add a function to the Falcon HAL to indicate whether a given GPU's Falcons support DMA for this purpose. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260122222848.2555890-10-ttabi@nvidia.com [acourbot@nvidia.com: add short code to call into the HAL.] [acourbot@nvidia.com: make `dma_load` private as per feedback.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-01-24gpu: nova-core: add support for Turing/GA100 fwsignatureTimur Tabi
Turing and GA100 share the same GSP-RM firmware binary, but the signature ELF section is labeled either ".fwsignature_tu10x" or ".fwsignature_tu11x". Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260122222848.2555890-5-ttabi@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-01-24gpu: nova-core: support header parsing on Turing/GA100Timur Tabi
The Turing/GA100 version of Booter is slightly different from the GA102+ version. The headers are the same, but different fields of the headers are used to identify the IMEM section. In addition, there is an NMEM section on Turing/GA100. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260122222848.2555890-4-ttabi@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-01-24gpu: nova-core: add ImemNonSecure section infrastructureTimur Tabi
The GSP booter firmware in Turing and GA100 includes a third memory section called ImemNonSecure, which is non-secure IMEM. This section must be loaded separately from DMEM and secure IMEM, but only if it actually exists. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260122222848.2555890-3-ttabi@nvidia.com [acourbot@nvidia.com: add `debug_assert`.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-01-24gpu: nova-core: rename Imem to ImemSecureTimur Tabi
Rename FalconMem::Imem to ImemSecure to indicate that it references Secure Instruction Memory. This change has no functional impact. On Falcon cores, pages in instruction memory can be tagged as Secure or Non-Secure. For GA102 and later, only Secure is used, which is why FalconMem::Imem seems appropriate. However, Turing firmware images can also contain non-secure sections, and so FalconMem needs to support that. By renaming Imem to ImemSec now, future patches for Turing support will be simpler. Nouveau uses the term "IMEM" to refer both to the Instruction Memory block on Falcon cores as well as to the images of secure firmware uploaded to part of IMEM. OpenRM uses the terms "ImemSec" and "ImemNs" instead, and uses "IMEM" just to refer to the physical memory device. Renaming these terms allows us to align with OpenRM, avoid confusion between IMEM and ImemSec, and makes future patches simpler. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260122222848.2555890-2-ttabi@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-01-07gpu: nova-core: use CStr::from_bytes_until_nul() in elf64_section()John Hubbard
Instead of open-coding the steps for extracting a null-terminated string, use the newly available CStr::from_bytes_until_nul(). Suggested-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260106035226.48853-3-jhubbard@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-29gpu: nova-core: fw: move appropriate code into pin initializerDanilo Krummrich
Relocate the code that technically fits in the pin initializer into the initializer itself. While, thanks to pin_init_scope(), it is also possible to keep it as is, moving appropriate code into the initializer has the advantage that it structures the dependencies of fields naturally. For instance, intermediate data that is only needed for a single field goes into the initializer block of this field, making it obvious that it is not needed by anything else. On the other hand, intermediate data that is needed for multiple fields to initialize remains above the initializer, naturally indicating that it is needed my multiple fields. Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://patch.msgid.link/20251218155239.25243-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-12-29gpu: nova-core: fw: get rid of redundant Result in GspFirmware::new()Danilo Krummrich
In GspFirmware::new(), utilize pin_init_scope() to get rid of the Result in the returned Result<impl PinInit<T, Error>> which is unnecessarily redundant. Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://patch.msgid.link/20251218155239.25243-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-11-14gpu: nova-core: gsp: Boot GSPAlistair Popple
Boot the GSP to the RISC-V active state. Completing the boot requires running the CPU sequencer which will be added in a future commit. Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alistair Popple <apopple@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-15-8ae4058e3c0e@nvidia.com>
2025-11-14gpu: nova-core: gsp: Create wpr metadataAlistair Popple
The GSP requires some pieces of metadata to boot. These are passed in a struct which the GSP transfers via DMA. Create this struct and get a handle to it for future use when booting the GSP. Signed-off-by: Alistair Popple <apopple@nvidia.com> Co-developed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-5-8ae4058e3c0e@nvidia.com>
2025-11-14gpu: nova-core: compute layout of more framebuffer regions required for GSPAlexandre Courbot
Compute more of the required FB layout information to boot the GSP firmware. This information is dependent on the firmware itself, so first we need to import and abstract the required firmware bindings in the `nvfw` module. Then, a new FB HAL method is introduced in `fb::hal` that uses these bindings and hardware information to compute the correct layout information. This information is then used in `fb` and the result made visible in `FbLayout`. These 3 things are grouped into the same patch to avoid lots of unused warnings that would be tedious to work around. As they happen in different files, they should not be too difficult to track separately. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251110-gsp_boot-v9-1-8ae4058e3c0e@nvidia.com>
2025-11-08gpu: nova-core: replace use of `as` with functions from `num`Alexandre Courbot
Use the newly-introduced `num` module to replace the use of `as` wherever it is safe to do. This ensures that a given conversion cannot lose data if its source or destination type ever changes. Acked-by: Danilo Krummrich <dakr@kernel.org> [acourbot@nvidia.com: fix merge conflicts after rebase.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251029-nova-as-v3-5-6a30c7333ad9@nvidia.com>
2025-11-07gpu: nova-core: Fix capitalization of some commentsDaniel del Castillo
Some comments that already existed didn't start with a capital letter, this patch fixes that. Signed-off-by: Daniel del Castillo <delcastillodelarosadaniel@gmail.com> [acourbot@nvidia.com: set prefix to "gpu: nova-core:".] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251104193756.57726-2-delcastillodelarosadaniel@gmail.com>
2025-11-07gpu: nova-core: Simplify `transmute` and `transmute_mut` in fwsec.rsDaniel del Castillo
This patch solves one of the existing mentions of COHA, a task in the Nova task list about improving the `CoherentAllocation` API. It uses the new `from_bytes` method from the `FromBytes` trait as well as the `as_slice` and `as_slice_mut` methods from `CoherentAllocation`. Signed-off-by: Daniel del Castillo <delcastillodelarosadaniel@gmail.com> [acourbot@nvidia.com: set prefix to "gpu: nova-core:".] [acourbot@nvidia.com: fix merge conflict after imports refactor.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251104193756.57726-1-delcastillodelarosadaniel@gmail.com>