kernel/linux.git/drivers/gpu/nova-core/falcon.rs, branch v6.18.22

gpu: nova-core: firmware: process Booter and patch its signature

2025-09-13T14:17:34+00:00

The Booter signed firmware is an essential part of bringing up the GSP on Turing and Ampere. It is loaded on the sec2 falcon core and is responsible for loading and running the RISC-V GSP bootloader into the GSP core. Add support for parsing the Booter firmware loaded from userspace, patch its signatures, and store it into a form that is ready to be loaded and executed on the sec2 falcon. Then, move the Booter instance from the `Firmware` struct to the `start_gsp` method since it doesn't need to be kept after the GSP is booted. We do not run Booter yet, as its own payload (the GSP bootloader and firmware image) still need to be prepared. Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-6-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: require `Send` on `FalconEngine` and `FalconHal`

2025-09-13T14:17:18+00:00

We want to store the GSP and SEC2 falcon instances inside the `Gpu` structure, but doing so require these types to implement `Send` for `pci::Driver` to remain implementable on `NovaCore`, which embeds `Gpu`. All implementors of `FalconEngine` and `FalconHal` satisfy the requirements of `Send`, and these traits also already required `Sync`, so this a minor tweak. Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-1-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot

rust: dma: add type alias for bindings::dma_addr_t

2025-09-04T21:33:50+00:00

Add a type alias for bindings::dma_addr_t (DmaAddress), such that we do not have to access bindings directly. Reviewed-by: Alice Ryhl Reviewed-by: Alexandre Courbot Reviewed-by: Daniel Almeida Reviewed-by: Lyude Paul Suggested-by: Alice Ryhl Link: https://lore.kernel.org/r/20250828133323.53311-3-dakr@kernel.org Signed-off-by: Danilo Krummrich

gpu: nova-core: falcon: align DMA transfers to 256 bytes

2025-08-22T00:47:43+00:00

Falcon DMA transfers are done in 256 bytes increments, and the method responsible for initiating the transfer checked that the required length was indeed a multiple of 256. While correct, this also requires callers to specifically account for this limitation of DMA transfers, and we had for instance the fwsec code performing a seemingly arbitrary (and potentially overflowing) upwards alignment of the DMEM load size to match this requirement. Let's move that alignment into the loading code itself instead: since it is working in terms of number of transfers, we can turn this upwards alignment into a non-overflowing operation, and check that the requested transfer remains into the limits of the DMA object. This also allows us to remove a DMA-specific constant in the fwsec code. Signed-off-by: Alexandre Courbot Link: https://lore.kernel.org/r/20250821-falcondma_256b-v2-1-83e8647a24b5@nvidia.com Signed-off-by: Danilo Krummrich

gpu: nova-core: Update ARef imports from sync::aref

2025-08-21T13:11:08+00:00

Update call sites in nova-core to import `ARef` from `sync::aref` instead of `types`. This aligns with the ongoing effort to move `ARef` and `AlwaysRefCounted` to sync. [acourbot@nvidia.com: use standard prefix for nova-core.] Suggested-by: Benno Lossin Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand Reviewed-by: Benno Lossin Link: https://lore.kernel.org/r/20250820112846.9665-1-shankari.ak0208@gmail.com Signed-off-by: Alexandre Courbot

gpu: nova-core: register: add support for relative array registers

2025-08-15T03:02:56+00:00

Add support for declaring arrays of registers available from a variable base. This is effectively a combination of the relative and array registers features. nova-core does not make much use of this yet, but it will become helpful to have for GSP boot. Reviewed-by: Lyude Paul Link: https://lore.kernel.org/r/20250718-nova-regs-v2-19-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: falcon: add distinct base address for PFALCON2

2025-08-15T03:02:56+00:00

Falcon engines have two distinct register bases: `PFALCON` and `PFALCON2`. So far we assumed that `PFALCON2` was located at `PFALCON + 0x1000` because that is the case of most engines, but there are exceptions (NVDEC uses `0x1c00`). Fix this shortcoming by leveraging the redesigned relative registers definitions to assign a distinct `PFalcon2Base` base address to each falcon engine. Reviewed-by: Lyude Paul Link: https://lore.kernel.org/r/20250718-nova-regs-v2-16-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: register: redesign relative registers

2025-08-15T03:02:56+00:00

The relative registers are currently very unsafe to use: callers can specify any constant as the base address for access, meaning they can effectively interpret any I/O address as any relative register. Ideally, valid base addresses for a family of registers should be explicitly defined in the code, and could only be used with the relevant registers This patch changes the relative register declaration from e.g.: register!(CPU_CTL @ +0x0000010, "CPU core control" { 0:0 start as bool, "Start the CPU core"; }); into: register!(CPU_CTL @ CpuCtlBase[0x10], "CPU core control" { 0:0 start as bool, "Start the CPU core"; }); Where `CpuCtlBase` is the name of a ZST used as a parameter of the `RegisterBase<>` trait to define a trait unique to a class of register. This specialized trait is then implemented for every type that provides a valid base address, enabling said types to be passed as the base address provider for the register's I/O accessor methods. This design thus makes it impossible to pass an unexpected base address to a relative register, and, since the valid bases are all known at compile-time, also guarantees that all I/O accesses are done within the valid bounds of the I/O range. [acourbot@nvidia.com: add example in the commit log.] Reviewed-by: Lyude Paul Link: https://lore.kernel.org/r/20250718-nova-regs-v2-15-7b6a762aa1cd@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: Clarify falcon code

2025-07-08T22:17:29+00:00

Add documentation strings, comments and AES mode for completeness to the Falcon signatures. Signed-off-by: Joel Fernandes Signed-off-by: Alexandre Courbot Link: https://lore.kernel.org/r/20250708-nova-docs-v4-3-9d188772c4c7@nvidia.com Signed-off-by: Danilo Krummrich

gpu: nova-core: replace `Duration` with `Delta`

2025-06-25T18:13:32+00:00

The kernel's `Delta` type was not available when the `wait_on` function was introduced. Now that it is, switch to it as it is more compact than `Duration` and cannot panic. Signed-off-by: Alexandre Courbot Link: https://lore.kernel.org/r/20250624-nova-delta-v1-1-b37d75a593ac@nvidia.com Signed-off-by: Danilo Krummrich