On 10/29/26 8:51 PM, Alexandre Courbot wrote: > On Mon Oct 26, 2026 at 1:24 PM JST, Dave Airlie via B4 Relay wrote: >> From: Dave Airlie <[email protected]> ... >> pub(crate) struct GpuMm<'gpu> { >> - buddy: GpuBuddy, >> - pramin: pramin::Pramin<'gpu>, >> + buddy: Option<GpuBuddy>, >> + pramin: Option<pramin::Pramin<'gpu>>, >> tlb: Pin<KBox<Tlb<'gpu>>>, >> } >> >> @@ -85,28 +85,28 @@ impl<'gpu> GpuMm<'gpu> { >> pub(crate) fn new( >> bar: Bar0<'gpu>, >> chipset: Chipset, >> - buddy_params: GpuBuddyParams, >> - total_fb_end: VramAddress, >> + buddy_params: Option<GpuBuddyParams>, >> + total_fb_end: Option<VramAddress>, > > This is related to the comment made by Sashiko, but in which cases are > we expecting `total_fb_end` to be `None` here? Is this the same set of > systems for which `buddy_params` will be `None`? If so both arguments > should be merged into a new type to remove the ability to represent > invalid state where one is `Some` and the other is `None`.
Neither, because the decision has to happen before GSP boot: on a zero-FB chip the kernel-side RM sends GSP-RM a system-memory heap in the boot arguments. The static info comes back after that. Open RM makes it a per-chip HAL constant. See "bGpuArchIsZeroFb". thanks, -- John Hubbard
