Re: [PATCH 2/5] gpu: nova-core: gsp: Move PBUS register definition

["Alexandre Courbot" <acourbot@nvidia.com>]

On Wed Jun 17, 2026 at 8:48 AM JST, Antonin Malzieu Ridolfi via B4 Relay wrote:
> From: Antonin Malzieu Ridolfi <dev@nanonej.com>
>
> Move PBUS register definition into gsp module and update registers
> visibility.
>
> Signed-off-by: Antonin Malzieu Ridolfi <dev@nanonej.com>

This one also didn't pass `rustfmtcheck` - please make sure to run the
checklist [1] (notably `rustfmt`) on each patch before submitting.

Some more comments below.

[1] https://rust-for-linux.com/contributing#submit-checklist-addendum

> ---
>  drivers/gpu/nova-core/gsp/hal/tu102.rs | 12 ++++++------
>  drivers/gpu/nova-core/gsp/regs.rs      | 11 +++++++++++
>  drivers/gpu/nova-core/regs.rs          | 11 -----------
>  3 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/gsp/hal/tu102.rs b/drivers/gpu/nova-core/gsp/hal/tu102.rs
> index eb7166148cc9..d46e8ec65785 100644
> --- a/drivers/gpu/nova-core/gsp/hal/tu102.rs
> +++ b/drivers/gpu/nova-core/gsp/hal/tu102.rs
> @@ -37,6 +37,7 @@
>              GspHal,
>              UnloadBundle, //
>          },
> +        regs,
>          sequencer::{
>              GspSequencer,
>              GspSequencerParams, //
> @@ -44,7 +45,6 @@
>          Gsp,
>          GspFwWprMeta, //
>      },
> -    regs,
>      vbios::Vbios, //
>  };
>  
> @@ -141,7 +141,7 @@ fn run(
>              .inspect_err(|e| dev_err!(dev, "FWSEC-SB failed to run: {:?}\n", e));
>  
>          // Remove WPR2 region if set.
> -        let wpr2_hi = bar.read(regs::NV_PFB_PRI_MMU_WPR2_ADDR_HI);
> +        let wpr2_hi = bar.read(crate::regs::NV_PFB_PRI_MMU_WPR2_ADDR_HI);

It would be nice if we could avoid re-scoping registers that don't move,
and I think we can achieve that as part of a slightly larger series.

Notice how we are accessing `PFB` registers (`WPR2_ADDR_HI` and
`WPR_ADDR_LO`) despite being in the `gsp` module. Let's start by fixing
that.

These two registers are only ever accessed by the GSP's TU102 HAL to
check whether a WPR2 region (a memory range going between `ADDR_LO` and
`ADDR_HI`) is set and what its range is. The TU102 code manipulates
these registers directly, but we could move them to the right place if
we did that as a FB service.

There could be a function in the `fb` module that reads the registers
and returns an `Option<Range<u64>>` - `None` if `is_wpr2_set` is
`false`, or the WPR2 range otherwise. Then the GSP TU102 HAL would just
use this function instead of poking the register as it currently does.

Doing so would move the WPR2 registers to the right place, and provide the
right abstraction for the WPR2 region.

A patch series doing this could look like this:

- Add the `fb` module function abstracting the WPR2 region registers and
  use it in the GSP's TU102 HAL.
- Move the `NV_PFB_PRI_MMU_WPR2_ADDR*` registers under the `fb` module.
- Move the `NV_PBUS_SW_SCRATCH_0E_FRTS_ERR` register under the `gsp`
  module, since it is clearly themed after `FRTS`, which is part of the
  GSP boot. But, without moving `NV_PBUS_SW_SCRATCH` (the actual
  register being aliased). I expect you will hit a bug of the `register`
  macro when doing this one - I'll try to address it, but the first two
  steps should be safe to do and correct.