| 91645a52 | 05-Aug-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
rust: dma: rename dma_handle to dma_address
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
rust: dma: rename dma_handle to dma_address
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>
show more ...
|
| 7923d0bc | 31-Jul-2026 |
Timur Tabi <ttabi@nvidia.com> |
gpu: nova-core: update firmware module info for TLV images
Now that nova-core loads the TLV firmware images, update the firmware
module info to specify those files.
Also remove FIRMWARE_VERSION as
gpu: nova-core: update firmware module info for TLV images
Now that nova-core loads the TLV firmware images, update the firmware
module info to specify those files.
Also remove FIRMWARE_VERSION as it is no longer used.
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-9-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| ccdcefb7 | 31-Jul-2026 |
Timur Tabi <ttabi@nvidia.com> |
gpu: nova-core: transition gsp to TLV images
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 image
gpu: nova-core: transition gsp to TLV images
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>
show more ...
|
| ad515782 | 31-Jul-2026 |
Timur Tabi <ttabi@nvidia.com> |
gpu: nova-core: transition booter to TLV images
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
gpu: nova-core: transition booter to TLV images
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>
show more ...
|
| 528aef3a | 04-Aug-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
gpu: nova-core: pass WPR metadata ownership to FmcBootArgs
`FmcBootArgs` logically owns this, so pass ownership to it instead of
storing a reference.
Signed-off-by: Eliot Courtney <ecourtney@nvidia
gpu: nova-core: pass WPR metadata ownership to FmcBootArgs
`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>
show more ...
|
| 6e46097f | 04-Aug-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
gpu: nova-core: split FbLayout into FSP and non-FSP versions
`FbLayout` is currently used for both pre and post FSP architectures. It
contains ranges for each region of framebuffer, but on post FSP
gpu: nova-core: split FbLayout into FSP and non-FSP versions
`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>
show more ...
|
| 93b9511a | 23-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: fix packed registry table size
`PACKED_REGISTRY_TABLE::size` describes the entire table, including its
fixed-size header. `SetRegistry` currently initializes it with only the
variabl
gpu: nova-core: fix packed registry table size
`PACKED_REGISTRY_TABLE::size` describes the entire table, including its
fixed-size header. `SetRegistry` currently initializes it with only the
variable payload length, omitting the 8 bytes header.
Fix this by using `CommandToGsp::size` to obtain the actual command
size, including its header.
Fixes: 19b0a6e7c2be ("gpu: nova-core: gsp: Add SetRegistry command")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/r/20260722075253.B6DDB1F00A3D@smtp.kernel.org
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260723-nova-registry-size-fix-v1-1-8f471ba00ab4@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 6dcbb4b1 | 22-Jul-2026 |
Zhi Wang <zhiw@nvidia.com> |
gpu: nova-core: reserve vGPU WPR2 heap
GSP-RM needs a larger WPR2 heap when booting in vGPU mode. The heap size
is firmware-dependent, so it should come from the generated firmware
bindings instead
gpu: nova-core: reserve vGPU WPR2 heap
GSP-RM needs a larger WPR2 heap when booting in vGPU mode. The heap size
is firmware-dependent, so it should come from the generated firmware
bindings instead of being open-coded in nova-core.
Pass the detected vGPU state into the framebuffer layout calculation. Keep
baremetal boots on the existing heap sizing path, and use the 570.144
vGPU default heap binding only when vGPU is enabled. The same state match
also sets the VF partition count, so disabled and invalid 0/1-VF states do
not enter the vGPU heap path.
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-7-zhiw@nvidia.com
[ Use checked arithmetic to calculate wpr2_heap_addr. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 9c96c8c2 | 03-Jul-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
gpu: nova-core: gsp: ensure LibOS DMA allocation lives long enough
Currently, `GspSequencer` stores a raw DMA handle. Instead, store a
reference to `Coherent` to statically ensure that the allocatio
gpu: nova-core: gsp: ensure LibOS DMA allocation lives long enough
Currently, `GspSequencer` stores a raw DMA handle. Instead, store a
reference to `Coherent` to statically ensure that the allocation lives
long enough.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-4-8e3d8bc32bb9@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| d76956f7 | 03-Jul-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
gpu: nova-core: gsp: ensure lifetime for FMC boot DMA allocations
Currently, `FmcBootArgs` takes DMA handles directly, rather than
references to the `Coherent` for them. This is error prone, so inst
gpu: nova-core: gsp: ensure lifetime for FMC boot DMA allocations
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>
show more ...
|
| ce2d97f7 | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: store Fsp instance in Gpu
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
gpu: nova-core: store Fsp instance in Gpu
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>
show more ...
|
| 320608e5 | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: separate context and GPU lifetimes in GspBootContext
`Falcon` instances retain references tied to the lifetime of the bound
GPU. `GspBootContext` currently uses that same lifeti
gpu: nova-core: gsp: separate context and GPU lifetimes in GspBootContext
`Falcon` instances retain references tied to the lifetime of the bound
GPU. `GspBootContext` currently uses that same lifetime for its own
borrows of the `Falcon` instances and other references.
But these lifetimes are independent: the references captured by a
`Falcon` remain valid for the GPU lifetime, while the context only
borrows the `Falcon` for the duration of a boot or unload operation.
This distinction is hidden for shared references by covariance, but
cannot be ignored anymore if the context carries mutable references to
GPU subdevices, as will happen for the `Fsp` and the `Falcon`s.
Thus, give `GspBootContext` separate lifetimes for its subdevice borrows
and the GPU resources captured by those subdevices, and update its users
accordingly.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-12-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 43f890d8 | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: pass GspBootContext mutably
We want to move the `Fsp` instance into `Gpu`, which will require
passing it as a mutable reference in `GspBootContext`, since
`Fsp::boot_fmc` is a m
gpu: nova-core: gsp: pass GspBootContext mutably
We want to move the `Fsp` instance into `Gpu`, which will require
passing it as a mutable reference in `GspBootContext`, since
`Fsp::boot_fmc` is a mutable method. In order to use the mutable
references it contains, `GspBootContext` must also be mutable.
We will also follow up by making some methods of the `Falcon`s mutable,
which also requires passing them as mutable references.
Thus, make the `GspBootContext` passed to `Gsp::boot` and `Gsp::unload`
mutable, and pass mutable references to it to the GSP boot HAL methods.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-11-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 691f6bc8 | 09-Jul-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
gpu: nova-core: move GSP firmware files decision to GSP HAL
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
gpu: nova-core: move GSP firmware files decision to GSP HAL
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>
show more ...
|
| bb2d0073 | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: make use of FWSEC bootloader a property of the TU102 HAL
By being in the TU102 HAL, we already know that the GSP boot method is
the SEC2 Booter, so the only variable is whether
gpu: nova-core: gsp: make use of FWSEC bootloader a property of the TU102 HAL
By being in the TU102 HAL, we already know that the GSP boot method is
the SEC2 Booter, so the only variable is whether the FWSEC bootloader is
used or not. Since `Chipset` also includes the variants that boot FSP,
querying it for that information introduces a potential code path (a
chipset that boots via FSP) that the current code doesn't handle.
Turn the use of the FWSEC bootloader into a property of the `Tu102` HAL,
and give GA102+ chipsets their own instance with that property set to
`false`. This removes the invalid code path and the only use of
`Chipset` is now to load the correct firmware files.
This also removes some uses of the `Chipset::needs_fwsec_bootloader`
method and prepares the ground for removing it.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-8-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 7567e62b | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: turn FWSEC execution into HAL method
Turn the `run_fwsec_frts` function into a method of `Tu102`. A following
patch will turn the "use FWSEC bootloader" property into a flag of
gpu: nova-core: gsp: turn FWSEC execution into HAL method
Turn the `run_fwsec_frts` function into a method of `Tu102`. A following
patch will turn the "use FWSEC bootloader" property into a flag of the
TU102 HAL itself, and making this a method will allow the code to access
it instead of querying `Chipset`.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-7-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 436f3c4a | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: fold TU102 unload bundle construction into HAL method
The construction of the unload bundle is currently a bit convoluted and
could be done in one function instead of two.
Addi
gpu: nova-core: gsp: fold TU102 unload bundle construction into HAL method
The construction of the unload bundle is currently a bit convoluted and
could be done in one function instead of two.
Additionally, turn that function into a method of `Tu102`. A following
patch will turn the "use FWSEC bootloader" property into a flag of the
TU102 HAL itself, and making this a method will allow the code to access
it instead of querying `Chipset`.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-6-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|