kernel/linux.git/drivers/gpu/nova-core/regs.rs, branch linux-7.0.y

gpu: nova-core: add NV_PFALCON_FALCON_ENGINE::reset_engine()

2026-01-23T23:45:13+00:00

Add a method for the NV_PFALCON_FALCON_ENGINE register that reset the Falcon, and update the reset_eng() HAL functions to use it. Signed-off-by: Timur Tabi Reviewed-by: Gary Guo Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260122222848.2555890-9-ttabi@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: Add basic Turing HAL

2026-01-23T23:45:13+00:00

Add the basic HAL for recognizing Turing GPUs. This isn't enough to support booting GSP-RM on Turing, but it's a start. Note that GA100, which boots using the same method as Turing, is not supported yet. Signed-off-by: Timur Tabi Reviewed-by: John Hubbard Reviewed-by: Gary Guo Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260122222848.2555890-8-ttabi@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: add NV_PFALCON_FALCON_DMATRFCMD::with_falcon_mem()

2026-01-23T23:45:13+00:00

The with_falcon_mem() method initializes the 'imem' and 'sec' fields of the NV_PFALCON_FALCON_DMATRFCMD register based on the value of the FalconMem type. Signed-off-by: Timur Tabi Reviewed-by: John Hubbard Reviewed-by: Gary Guo Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260122222848.2555890-6-ttabi@nvidia.com Signed-off-by: Alexandre Courbot

gpu: nova-core: provide a clear error report for unsupported GPUs

2025-11-15T14:11:28+00:00

Pass in a PCI device to Spec::new(), and provide a Display implementation for boot42, in order to provide a clear, concise report of what happened: the driver read NV_PMC_BOOT42, and found that the GPU is not supported. For very old GPUs (older than Fermi), the driver still returns ENODEV, but it does so without a driver-specific dmesg report. That is exactly appropriate, because if such a GPU is installed, it can only be supported by Nouveau. And if so, the user is not helped by additional error messages from Nova. Here's the full dmesg output for a Blackwell (not yet supported) GPU: NovaCore 0000:01:00.0: Probe Nova Core GPU driver. NovaCore 0000:01:00.0: Unsupported chipset: boot42 = 0x1b2a1000 (architecture 0x1b, implementation 0x2) NovaCore 0000:01:00.0: probe with driver NovaCore failed with error -524 Cc: Alexandre Courbot Cc: Danilo Krummrich Cc: Timur Tabi Cc: Joel Fernandes Signed-off-by: John Hubbard [acourbot@nvidia.com: fix commit log with ENODEV (not ENOTSUPP) error code for unsupported GPUs.] Signed-off-by: Alexandre Courbot Message-ID: <20251115010923.1192144-5-jhubbard@nvidia.com>

gpu: nova-core: add boot42 support for next-gen GPUs

2025-11-15T14:11:27+00:00

NVIDIA GPUs are moving away from using NV_PMC_BOOT_0 to contain architecture and revision details, and will instead use NV_PMC_BOOT_42 in the future. NV_PMC_BOOT_0 will contain a specific set of values that will mean "go read NV_PMC_BOOT_42 instead". Change the selection logic in Nova so that it will claim Turing and later GPUs. This will work for the foreseeable future, without any further code changes here, because all NVIDIA GPUs are considered, from the oldest supported on Linux (NV04), through the future GPUs. Add some comment documentation to explain, chronologically, how boot0 and boot42 change with the GPU eras, and how that affects the selection logic. Cc: Alexandre Courbot Cc: Danilo Krummrich Cc: Timur Tabi Reviewed-by: Joel Fernandes Signed-off-by: John Hubbard [acourbot@nvidia.com: remove unneeded `From for Revision` implementation.] Signed-off-by: Alexandre Courbot Message-ID: <20251115010923.1192144-4-jhubbard@nvidia.com>

gpu: nova-core: gsp: Add support for checking if GSP reloaded

2025-11-15T11:08:49+00:00

During the sequencer process, we need to check if GSP was successfully reloaded. Add functionality to check for the same. Reviewed-by: Lyude Paul Signed-off-by: Joel Fernandes Signed-off-by: Alexandre Courbot Message-ID: <20251114195552.739371-6-joelagnelf@nvidia.com>

gpu: nova-core: falcon: Add support to write firmware version

2025-11-14T11:25:57+00:00

This will be needed by both the GSP boot code as well as GSP resume code in the sequencer. Reviewed-by: Lyude Paul Signed-off-by: Joel Fernandes Signed-off-by: Alexandre Courbot Message-ID: <20251110-gsp_boot-v9-14-8ae4058e3c0e@nvidia.com>

gpu: nova-core: falcon: Add support to check if RISC-V is active

2025-11-14T11:25:57+00:00

Add definition for RISCV_CPUCTL register and use it in a new falcon API to check if the RISC-V core of a Falcon is active. It is required by the sequencer to know if the GSP's RISCV processor is active. Reviewed-by: Lyude Paul Signed-off-by: Joel Fernandes Signed-off-by: Alexandre Courbot Message-ID: <20251110-gsp_boot-v9-13-8ae4058e3c0e@nvidia.com>

gpu: nova-core: gsp: Add GSP command queue bindings and handling

2025-11-14T11:25:57+00:00

This commit introduces core infrastructure for handling GSP command and message queues in the nova-core driver. The command queue system enables bidirectional communication between the host driver and GSP firmware through a remote message passing interface. The interface is based on passing serialised data structures over a ring buffer with separate transmit and receive queues. Commands are sent by writing to the CPU transmit queue and waiting for completion via the receive queue. To ensure safety mutable or immutable (depending on whether it is a send or receive operation) references are taken on the command queue when allocating the message to write/read to. This ensures message memory remains valid and the command queue can't be mutated whilst an operation is in progress. Currently this is only used by the probe() routine and therefore can only used by a single thread of execution. Locking to enable safe access from multiple threads will be introduced in a future series when that becomes necessary. Signed-off-by: Alistair Popple Co-developed-by: Alexandre Courbot Signed-off-by: Alexandre Courbot Message-ID: <20251110-gsp_boot-v9-9-8ae4058e3c0e@nvidia.com>

gpu: nova-core: replace use of `as` with functions from `num`

2025-11-07T23:22:45+00:00

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 [acourbot@nvidia.com: fix merge conflicts after rebase.] Signed-off-by: Alexandre Courbot Message-ID: <20251029-nova-as-v3-5-6a30c7333ad9@nvidia.com>