Re: [PATCH v9 17/31] gpu: nova-core: Hopper/Blackwell: calculate reserved FB heap size

[Alexandre Courbot]

On Thu Mar 26, 2026 at 10:38 AM JST, John Hubbard wrote:
> Various "reserved" areas of FB (frame buffer: vidmem) have to be
> calculated, because the GSP booting process needs this information.
>
> PMU_RESERVED_SIZE is computed at compile time using const_align_up().
> The total reserved size is computed at runtime using Alignable::align_up
> because it depends on the heap layout.
>
> Signed-off-by: John Hubbard <jhubbard@xxxxxxxxxx>

Is this Blackwell-specific? Because it seems to be done unconditionally,
contrary to what the title says.

> ---
>  drivers/gpu/nova-core/fb.rs     | 8 ++++++++
>  drivers/gpu/nova-core/gsp/fw.rs | 6 +++++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
> index 6536d0035cb1..ffb996b918f8 100644
> --- a/drivers/gpu/nova-core/fb.rs
> +++ b/drivers/gpu/nova-core/fb.rs
> @@ -10,6 +10,7 @@
>      fmt,
>      prelude::*,
>      ptr::{
> +        const_align_up,
>          Alignable,
>          Alignment, //
>      },
> @@ -270,3 +271,10 @@ pub(crate) fn new(chipset: Chipset, bar: &Bar0, gsp_fw: &GspFirmware) -> Result<
>          })
>      }
>  }
> +
> +/// PMU reserved size, aligned to 128KB.
> +pub(crate) const PMU_RESERVED_SIZE: u32 =
> +    match const_align_up(SZ_8M + SZ_16M + SZ_4K, Alignment::new::<SZ_128K>()) {
> +        Some(v) => v as u32,
> +        None => panic!("PMU_RESERVED_SIZE: alignment overflow"),
> +    };

I had hoped we could use `unwrap()`, but it is only stable in a const
block from 1.83. Maybe we can revisit once is MSRV is bumped.

Meanwhile, we can replace  the `as u32` with `usize_into_u32` from
Nova's `num` module.