Re: [PATCH] gpu: nova-core: Extract FUSE registers definitions

[Alexandre Courbot]

On Tue Aug 18, 2026 at 5:04 AM JST, Antonin Malzieu Ridolfi via B4 Relay wrote:
> From: Antonin Malzieu Ridolfi <dev@xxxxxxxxxxx>
>
> Move FUSE register definitions from the root regs.rs file into the
> gpu module that own them, in the existing gpu/regs.rs file.
>
> This follows the same pattern established by previous commits for
> GSP, PDISP, PFB, PBUS and PMC registers: register definitions move to
> the module that owns them, visibility changes to pub(super), and
> cross-module access is provided via pub(crate) helper functions.
>
> Since gal102.rs (outside the gpu module) also reads fuse registers to
> infer fuse version, a pub(crate) helper function fuse_ucode_version()
> is added in gpu.rs to provide that information without exposing the
> register type directly.
>
> Suggested-by: Alexandre Courbot <acourbot@xxxxxxxxxx>
> Suggested-by: Danilo Krummrich <dakr@xxxxxxxxxx>
> Signed-off-by: Antonin Malzieu Ridolfi <dev@xxxxxxxxxxx>
> ---
> I got several doubts regarding this patch:
> - I didn't touch the comment in falcon/hal/ga102.rs:71 cause I didn't
>   know if this information should stay there
> - I'm not sure if the re-export of NV_FUSE_OPT_FPF_SIZE in gpu.rs is the
>   right way to keep the read in gal102.rs or if I should also make an
> helper to get its value
> - Then, as I'm not quite sure to understand the exact purpose of the
> code I'm not sure of the `fuse_ucode_version` naming and the comment
> explaining what it do

I am also a bit hesitant to apply this patch as-is. As defined, it only
adds an indirection through the `gpu` module for FUSE registers that are
only accessed by `falcon` (actually, the `ga102` HAL of `falcon`).

`fuse_ucode_version` does some falcon-specific processing (notably with
the engine ID mask), so it looks out-of-place in `gpu.rs`.

Also, the patch doesn't move all the FUSE registers -
NV_FUSE_STATUS_OPT_DISPLAY is still in the root's `regs.rs`. That's
probably because the destination chosen by this patch is not a good fit
to contain them all.

Now I am not quite sure there is a single, good destination for all
these registers. We could move these to `falcon` (and
NV_FUSE_STATUS_OPT_DISPLAY to `fb`), but this just happens to match what
we are doing right now and if another module needs to use them we carry
the risk that it will redefine them locally. Or we could have a
dedicated `fuse` module only to carry these registers, and some
functions to provide the services needed by other modules, including a
HAL to read the correct NV_FUSE_STATUS_OPT_DISPLAY register depending on
architecture. But that looks a bit overkill so I'd suggest wait-and-see
for now. :)

There is also a more insidious issue below.

<...>
> @@ -419,3 +424,27 @@ pub(crate) fn new(
>  pub(crate) fn boot_0_raw(bar: Bar0<'_>) -> u32 {
>      bar.read(regs::NV_PMC_BOOT_0).into_raw()
>  }
> +
> +/// Returns the fuse version matching `engine_id_mask`,
> +/// at the given `ucode_idx`.
> +/// Returns `None` if no engine matches `engine_id_mask`.
> +pub(crate) fn fuse_ucode_version(
> +    bar: Bar0<'_>,
> +    engine_id_mask: u16,
> +    ucode_idx: usize,
> +) -> Option<u16> {
> +    let version = if engine_id_mask & 0x0001 != 0 {
> +        bar.read(regs::NV_FUSE_OPT_FPF_SEC2_UCODE1_VERSION::at(ucode_idx))
> +            .data()
> +    } else if engine_id_mask & 0x0004 != 0 {
> +        bar.read(regs::NV_FUSE_OPT_FPF_NVDEC_UCODE1_VERSION::at(ucode_idx))
> +            .data()
> +    } else if engine_id_mask & 0x0400 != 0 {
> +        bar.read(regs::NV_FUSE_OPT_FPF_GSP_UCODE1_VERSION::at(ucode_idx))
> +            .data()
> +    } else {
> +        return None;
> +    };
> +
> +    Some(version)
> +}

This is moot due to the comments above, but this function should be
`#[inline(always)]`. The reason is that it uses `at`, which performs a
`build_assert!` using `ucode_idx`. If this function is not inlined into
its caller, then the range properties asserted by
`signature_reg_fuse_version_ga102` won't be visible to the compiler and
the `build_assert!` will fail.