linux-toradex.git/drivers/gpu/nova-core/fsp.rs, branch master Linux kernel for Apalis and Colibri modules rust: dma: rename dma_handle to dma_address 2026-08-06T20:54:39+00:00 Alexandre Courbot acourbot@nvidia.com 2026-08-05T05:01:46+00:00 91645a52ebf2e22f0bd37c142b79238617d38758 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> 
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>
gpu: nova-core: transition fsp to TLV images 2026-08-05T23:54:12+00:00 Timur Tabi ttabi@nvidia.com 2026-07-31T20:10:16+00:00 08994a0f2936532f1e61a881fc0cc1b731773cf7 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> 
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>
gpu: nova-core: pass WPR metadata ownership to FmcBootArgs 2026-08-05T05:20:37+00:00 Eliot Courtney ecourtney@nvidia.com 2026-08-04T05:41:16+00:00 528aef3a4bdd85137de9ec76bd02eacdf8160bb5 `FmcBootArgs` logically owns this, so pass ownership to it instead of storing a reference. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-5-ac858b6a1935@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> 
`FmcBootArgs` logically owns this, so pass ownership to it instead of
storing a reference.

Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-5-ac858b6a1935@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
gpu: nova-core: split FbLayout into FSP and non-FSP versions 2026-08-05T05:20:37+00:00 Eliot Courtney ecourtney@nvidia.com 2026-08-04T05:41:15+00:00 6e46097f4d616a0f81083ae2c112efbb1473539e `FbLayout` is currently used for both pre and post FSP architectures. It contains ranges for each region of framebuffer, but on post FSP architectures, only the size is actually used. The region locations are decided by ACR, which runs as part of the GSP-FMC, not by the driver. The driver only provides the sizes. So, for post FSP architectures `FbLayout` contains essentially guesses for the offsets. Instead, make separate types so that we only store the information that's actually needed, rather than keeping around offsets that may not be correct. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-4-ac858b6a1935@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> 
`FbLayout` is currently used for both pre and post FSP architectures. It
contains ranges for each region of framebuffer, but on post FSP
architectures, only the size is actually used. The region locations are
decided by ACR, which runs as part of the GSP-FMC, not by the driver.
The driver only provides the sizes. So, for post FSP architectures
`FbLayout` contains essentially guesses for the offsets. Instead, make
separate types so that we only store the information that's actually
needed, rather than keeping around offsets that may not be correct.

Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-4-ac858b6a1935@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
gpu: nova-core: correct FRTS vidmem offset calculation 2026-08-05T05:20:36+00:00 Eliot Courtney ecourtney@nvidia.com 2026-08-04T05:41:12+00:00 5c9deba5578db5a3ea05be8a3e4a59ecb08ee76f Currently, the frts vidmem offset is calculated based on the non-wpr heap size and pmu reservation size, but this is not right. The layout actually looks like this: | non-wpr heap | WPR2 .. FRTS | PMU reserved | ... | VGA workspace | It's just by coincidence + generous alignment that the values happened to match. Instead, define a per-architecture reserved size at the end of the framebuffer and use this plus the PMU reserved size to calculate the frts vidmem offset. Fixes: d317e4585fa3 ("gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-1-ac858b6a1935@nvidia.com [acourbot: add comment clarifying reason for testing pmu_reserved_size.] [acourbot: make fb_end_reserved_size() return u64.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> 
Currently, the frts vidmem offset is calculated based on the non-wpr
heap size and pmu reservation size, but this is not right. The layout
actually looks like this:

| non-wpr heap | WPR2 .. FRTS | PMU reserved | ... | VGA workspace |

It's just by coincidence + generous alignment that the values happened
to match. Instead, define a per-architecture reserved size at the end of
the framebuffer and use this plus the PMU reserved size to calculate the
frts vidmem offset.

Fixes: d317e4585fa3 ("gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot")
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-1-ac858b6a1935@nvidia.com
[acourbot: add comment clarifying reason for testing pmu_reserved_size.]
[acourbot: make fb_end_reserved_size() return u64.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
gpu: nova-core: detect and store vGPU state 2026-07-23T23:15:52+00:00 Zhi Wang zhiw@nvidia.com 2026-07-22T07:39:11+00:00 c0ce158096d4c2e88d270777588bf5ea7cee5f5c GSP boot needs a stable view of vGPU state before it starts building the boot-time data structures that depend on SR-IOV and firmware policy. That state must be derived once from the PCI VF count and the FSP PRC vGPU mode knob before booting GSP. Add VgpuManager to detect and retain the vGPU state during GPU construction. Keep the manager separate from the detected state because later vGPU milestones will add vGPU resources and lifecycle state to it. Keep the vGPU capability gate local to the vGPU module with per-chip HAL modules. Treat failures to detect the optional vGPU state as disabled so they do not prevent a bare-metal probe, and log both the failure and the detected state where the manager is constructed. Cc: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260722073913.1807677-5-zhiw@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> 
GSP boot needs a stable view of vGPU state before it starts building the
boot-time data structures that depend on SR-IOV and firmware policy. That
state must be derived once from the PCI VF count and the FSP PRC vGPU mode
knob before booting GSP.

Add VgpuManager to detect and retain the vGPU state during GPU
construction. Keep the manager separate from the detected state because
later vGPU milestones will add vGPU resources and lifecycle state to it.

Keep the vGPU capability gate local to the vGPU module with per-chip HAL
modules. Treat failures to detect the optional vGPU state as disabled so
they do not prevent a bare-metal probe, and log both the failure and the
detected state where the manager is constructed.

Cc: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Zhi Wang <zhiw@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260722073913.1807677-5-zhiw@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
gpu: nova-core: read vGPU mode from FSP via PRC protocol 2026-07-23T23:15:43+00:00 Zhi Wang zhiw@nvidia.com 2026-07-22T07:39:10+00:00 29073113cf0044fd05dd0b4318421e91b8de8542 vGPU boot needs to know whether firmware reports vGPU mode as active. FSP's Management Partition exposes PRC (Product Reconfiguration Control) as an API for reading device configuration knobs without firmware updates. The vGPU mode knob is one such configuration value. Add typed PRC request and response payloads for the vGPU mode object, add the PRC NVDM type, and parse the returned knob value into VgpuMode. Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260722073913.1807677-4-zhiw@nvidia.com [ FspPrcMessage is small and short-lived; stack-allocate it instead of using KBox. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org> 
vGPU boot needs to know whether firmware reports vGPU mode as active.

FSP's Management Partition exposes PRC (Product Reconfiguration Control)
as an API for reading device configuration knobs without firmware
updates. The vGPU mode knob is one such configuration value.

Add typed PRC request and response payloads for the vGPU mode object,
add the PRC NVDM type, and parse the returned knob value into VgpuMode.

Signed-off-by: Zhi Wang <zhiw@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260722073913.1807677-4-zhiw@nvidia.com
[ FspPrcMessage is small and short-lived; stack-allocate it instead of
  using KBox. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
gpu: nova-core: gsp: ensure lifetime for FMC boot DMA allocations 2026-07-23T02:33:11+00:00 Eliot Courtney ecourtney@nvidia.com 2026-07-03T10:22:07+00:00 d76956f7b79531e6801fe293259e93d0df1b96a7 Currently, `FmcBootArgs` takes DMA handles directly, rather than references to the `Coherent` for them. This is error prone, so instead store lifetime'd references to the `Coherent` allocation. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-3-8e3d8bc32bb9@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> 
Currently, `FmcBootArgs` takes DMA handles directly, rather than
references to the `Coherent` for them. This is error prone, so instead
store lifetime'd references to the `Coherent` allocation.

Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-3-8e3d8bc32bb9@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
gpu: nova-core: store Fsp instance in Gpu 2026-07-15T23:00:53+00:00 Alexandre Courbot acourbot@nvidia.com 2026-07-09T06:53:06+00:00 ce2d97f714c8a37cac506a41e52da45b09555b81 The `Fsp` instance was only used in the Hopper+ boot path, and consequently built locally (and immediately dropped) in it. This worked well as a temporary measure, but the FSP is a GPU sub-device, so its lifetime should match the GPU rather than a single boot invocation. It will also be needed in other parts of the driver, for instance vGPU. Thus, create the `Fsp` instance in the `Gpu` constructor and store it there, passing it to the GSP boot as a mutable reference using `GspBootContext`. This makes the `Fsp` available even after the GSP is booted. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-13-520cbf8b9b50@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> 
The `Fsp` instance was only used in the Hopper+ boot path, and
consequently built locally (and immediately dropped) in it.

This worked well as a temporary measure, but the FSP is a GPU
sub-device, so its lifetime should match the GPU rather than a single
boot invocation.

It will also be needed in other parts of the driver, for instance vGPU.

Thus, create the `Fsp` instance in the `Gpu` constructor and store it
there, passing it to the GSP boot as a mutable reference using
`GspBootContext`. This makes the `Fsp` available even after the GSP is
booted.

Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-13-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
gpu: nova-core: fsp: rename FSP response header type 2026-07-08T12:40:07+00:00 Zhi Wang zhiw@nvidia.com 2026-07-01T06:26:17+00:00 2493c4416542ce1759d6dcd0a2b1f0ed18ab8c35 FSP message handling currently uses FspResponse for the common response prefix containing the MCTP header, NVDM header and command response payload. That name is too broad once other FSP response formats reuse the same prefix and append protocol-specific payloads. Rename it to FspResponseHeader so subsequent response structures can embed the common header without overloading the meaning of FspResponse. Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/all/DJMBI9CN2Z67.2T02SR8TAWEC5@nvidia.com/ Signed-off-by: Zhi Wang <zhiw@nvidia.com> Link: https://patch.msgid.link/20260701062622.3499033-4-zhiw@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> 
FSP message handling currently uses FspResponse for the common response
prefix containing the MCTP header, NVDM header and command response
payload.

That name is too broad once other FSP response formats reuse the same
prefix and append protocol-specific payloads. Rename it to
FspResponseHeader so subsequent response structures can embed the common
header without overloading the meaning of FspResponse.

Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/all/DJMBI9CN2Z67.2T02SR8TAWEC5@nvidia.com/
Signed-off-by: Zhi Wang <zhiw@nvidia.com>
Link: https://patch.msgid.link/20260701062622.3499033-4-zhiw@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>