Nouveau - Nov 2025 - [PATCH v3 2/2] gpu: nova-core: add boot42 support for next-gen GPUs

On Wed Oct 29, 2025 at 12:03 PM JST, John Hubbard wrote:
<snip>
> diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
> index 206dab2e1335..ed3a2c39edbc 100644
> --- a/drivers/gpu/nova-core/regs.rs
> +++ b/drivers/gpu/nova-core/regs.rs
> @@ -25,6 +25,18 @@
>  });
>  
>  impl NV_PMC_BOOT_0 {
> +    pub(crate) fn is_nv04(self) -> bool {
> +        // The very first supported GPU was NV04, and it is identified by
a specific bit pattern in
> +        // boot0. This provides a way to check for that, which in turn is
required in order to avoid
> +        // confusing future "next-gen" GPUs with NV04.
> +        self.architecture_0() == 0 && (self.0 & 0xff00fff0) ==
0x20004000
> +    }
> +
> +    pub(crate) fn is_next_gen(self) -> bool {
> +        // "next-gen" GPUs (some time after Blackwell) will set
`architecture_0` to 0, and put the
> +        // architecture details in boot42 instead.
> +        self.architecture_0() == 0 && !self.is_nv04()
> +    }
>      /// Combines `architecture_0` and `architecture_1` to obtain the
architecture of the chip.
>      pub(crate) fn architecture(self) -> Result<Architecture> {
>          Architecture::try_from(
> @@ -43,6 +55,21 @@ pub(crate) fn chipset(self) -> Result<Chipset>
{
>      }
>  }
>  
> +register!(NV_PMC_BOOT_42 @ 0x00000108, "Extended architecture
information" {
> +    7:0     implementation as u8, "Implementation version of the
architecture";
> +    15:8    architecture as u8, "Architecture value";
Here you can directly return the `Architecture` type and spare callers
the labor of doing the conversion themselves:

  15:8    architecture as u8 ?=> Architecture, "Architecture
value";

This allows the implementation of `NV_PMC_BOOT_42` to mirror that of
`NV_PMC_BOOT_0`:

  impl NV_PMC_BOOT_42 {
      pub(crate) fn chipset(self) -> Result<Chipset> {
          self.architecture()
              .map(|arch| {
                  ((arch as u32) << Self::IMPLEMENTATION_RANGE.len())
                      | u32::from(self.implementation())
              })
              .and_then(Chipset::try_from)
      }
  }

... but also requires `Architecture` to be `repr(u8)` and to implement
`Default` and `Into<u8>` so it can be used in the `register` macro:

  /// Enum representation of the GPU generation.
  #[derive(fmt::Debug, Default)]
  #[repr(u8)]
  pub(crate) enum Architecture {
      #[default]
      Turing = 0x16,
      Ampere = 0x17,
      Ada = 0x19,
  }

  impl From<Architecture> for u8 {
      fn from(value: Architecture) -> Self {
          // CAST: `Architecture` is `repr(u8)`, so this cast is always
lossless.
          value as u8
      }
  }

These implementations were not needed for `NV_PMC_BOOT_0` because its
`architecture` method is manually implemented as it depends on two
distinct fields.

On 10/29/25 7:05 AM, Alexandre Courbot wrote:
> On Wed Oct 29, 2025 at 12:03 PM JST, John Hubbard wrote:
> <snip>
> Here you can directly return the `Architecture` type and spare callers
> the labor of doing the conversion themselves:
Hi Alex,

I will attempt this, after updating my brain with a few missing macro-
related skills. haha :)


thanks,
-- 
John Hubbard

On 10/29/25 7:05 AM, Alexandre Courbot wrote:
> On Wed Oct 29, 2025 at 12:03 PM JST, John Hubbard wrote:
> <snip>
> This allows the implementation of `NV_PMC_BOOT_42` to mirror that of
> `NV_PMC_BOOT_0`:
> 
>   impl NV_PMC_BOOT_42 {
>       pub(crate) fn chipset(self) -> Result<Chipset> {
>           self.architecture()
>               .map(|arch| {
>                   ((arch as u32) << Self::IMPLEMENTATION_RANGE.len())
A quick note: _RANGE() and related functions are (I think?) deeply,
madly undocumented. Not only is bitfield a macro within a macro, but
bitfield itself leaves the user with only the following as
"documentation":

    ::kernel::macros::paste!(
    const [<$field:upper _RANGE>]: ::core::ops::RangeInclusive<u8> =
$lo..=$hi;

The net result is that those of us who did not author or carefully
review register!() and bitfield!() are going to have a rough time
using these facilities.

I'm not sure of the best way to add documentation here, but just
thought I'd better give an early warning about this.


thanks,
-- 
John Hubbard