Re: [PATCH 3/5] gpu: nova-core: falcon: Move PFALCON2 register

From: Alexandre Courbot

Date: Tue Jun 23 2026 - 02:22:26 EST


On Wed Jun 17, 2026 at 8:48 AM JST, Antonin Malzieu Ridolfi via B4 Relay wrote:
> From: Antonin Malzieu Ridolfi <dev@xxxxxxxxxxx>
>
> Move PFALCON2 register definition into falcon module and update registers
> visibility.
>
> Signed-off-by: Antonin Malzieu Ridolfi <dev@xxxxxxxxxxx>
> ---
> drivers/gpu/nova-core/falcon.rs | 71 ++++++++++++++++++-------------
> drivers/gpu/nova-core/falcon/hal/ga102.rs | 38 +++++++++--------
> drivers/gpu/nova-core/falcon/regs.rs | 30 +++++++++++++
> drivers/gpu/nova-core/regs.rs | 23 ----------
> 4 files changed, 92 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
> index 94c7696a6493..c2215ddd9e80 100644
> --- a/drivers/gpu/nova-core/falcon.rs
> +++ b/drivers/gpu/nova-core/falcon.rs
> @@ -37,12 +37,12 @@
> self,
> FromSafeCast, //
> },
> - regs,
> };
>
> pub(crate) mod fsp;
> pub(crate) mod gsp;
> mod hal;
> +mod regs;
> pub(crate) mod sec2;
>
> /// Alignment (in bytes) of falcon memory blocks.
> @@ -99,7 +99,7 @@ pub(crate) enum FalconSecurityModel with TryFrom<Bounded<u32, 2>> {
>
> bounded_enum! {
> /// Signing algorithm for a given firmware, used in the
> - /// [`crate::regs::NV_PFALCON2_FALCON_MOD_SEL`] register. It is passed to the Falcon Boot ROM
> + /// [`super::regs::NV_PFALCON2_FALCON_MOD_SEL`] register. It is passed to the Falcon Boot ROM
> /// (BROM) as a parameter.
> #[derive(Debug, Copy, Clone)]
> pub(crate) enum FalconModSelAlgo with TryFrom<Bounded<u32, 8>> {
> @@ -374,13 +374,13 @@ pub(crate) fn new(dev: &device::Device, chipset: Chipset) -> Result<Self> {
>
> /// Resets DMA-related registers.
> pub(crate) fn dma_reset(&self, bar: Bar0<'_>) {
> - bar.update(regs::NV_PFALCON_FBIF_CTL::of::<E>(), |v| {
> + bar.update(crate::regs::NV_PFALCON_FBIF_CTL::of::<E>(), |v| {

It's a bit of a bummer that we need to rescope all these registers
because a few have moved. I think we should try and take the same
approach as patch 2, i.e. make sure each register is only used in one
module by introducing the right abstractions, and move all the registers
of that module in one go.

The `falcon` module is definitely the most register-rich, so it's
probably a good idea to keep it for last, unless you have the patience
to check each of its registers one by one. (LSP can make the task easier
though :)).