From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Joel Fernandes" <joelagnelf@nvidia.com>
Cc: linux-kernel@vger.kernel.org, "Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Dave Airlie" <airlied@redhat.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Koen Koning" <koen.koning@linux.intel.com>,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
rust-for-linux@vger.kernel.org,
"Nikola Djukic" <ndjukic@nvidia.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Simona Vetter" <simona@ffwll.ch>,
"Jonathan Corbet" <corbet@lwn.net>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Huang Rui" <ray.huang@amd.com>,
"Matthew Auld" <matthew.auld@intel.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Lucas De Marchi" <lucas.demarchi@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Helge Deller" <deller@gmx.de>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Andrea Righi" <arighi@nvidia.com>, "Zhi Wang" <zhiw@nvidia.com>,
"Philipp Stanner" <phasta@kernel.org>,
"Elle Rhumsaa" <elle@weathered-steel.dev>,
alexeyi@nvidia.com, "Eliot Courtney" <ecourtney@nvidia.com>,
joel@joelfernandes.org, linux-doc@vger.kernel.org,
amd-gfx@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
intel-xe@lists.freedesktop.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v8 11/25] gpu: nova-core: mm: Use usable VRAM region for buddy allocator
Date: Sun, 01 Mar 2026 21:56:30 +0900 [thread overview]
Message-ID: <DGRGNLACDJI2.1JFEXE1GL1ZVM@nvidia.com> (raw)
In-Reply-To: <20260224225323.3312204-12-joelagnelf@nvidia.com>
On Wed Feb 25, 2026 at 7:53 AM JST, Joel Fernandes wrote:
<snip>
> @@ -295,18 +309,42 @@ pub(crate) fn new<'a>(
>
> sec2_falcon: Falcon::new(pdev.as_ref(), spec.chipset)?,
>
> - // Create GPU memory manager owning memory management resources.
> - // This will be initialized with the usable VRAM region from GSP in a later
> - // patch. For now, we use a placeholder of 1MB.
> - mm <- GpuMm::new(devres_bar.clone(), GpuBuddyParams {
> - base_offset_bytes: 0,
> - physical_memory_size_bytes: SZ_1M as u64,
> - chunk_size_bytes: SZ_4K as u64,
> - })?,
> -
> gsp <- Gsp::new(pdev),
>
> - gsp_static_info: { gsp.boot(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)?.0 },
> + // Boot GSP and extract usable VRAM region for buddy allocator.
> + gsp_static_info: {
> + let (info, fb_layout) = gsp.boot(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)?;
> +
> + let usable_vram = fb_layout.usable_vram.as_ref().ok_or_else(|| {
> + dev_err!(pdev.as_ref(), "No usable FB regions found from GSP\n");
> + ENODEV
> + })?;
The chain through which we obtain `usable_vram` is very inefficient and
much more complex than it needs to be.
`fb_layout` is used as a transport for `usable_vram`, but `usable_vram`
is the only member of it that we ever use. In that case, why not return
`usable_vram` directly?
This is all the better as `usable_vram` is added as an `Option` in
`FbLayout`, not because `None` is a valid state but because `FbLayout`
is already constructed by the time we obtain `usable_vram`. So `None` is
just a value that tells the caller "please return an error". Now we can
remove the option altogether, drop patch 5, and have `boot` return the
error for us if `usable_vram` cannot be obtained.
But let's not stop here. `usable_vram` is first obtained as part of the
`GetGspStaticInfo` reply. It starts its life as `(u64, u64)` before
being morphed into a `Range<u64>` when stored in `FbLayout`. Since its
tuple state is never useful, let's store it as a `Range<u64>` in
`GetGspStaticInfoReply` to begin with and, since we cannot continue
without it anyway, let's make `commands::get_gsp_info()` fail if it
cannot build it. That way we don't even need to store it as an `Option`.
And now, since `boot` already returns the `GetGspStaticInfoReply`, we
can directly access it just by making `usable_vram` public - no need for
`boot` to return a tuple anymore.
Once you have that, something interesting happens: you don't need to
change the `gsp_static_info` arm at all in this patch. All the new code
can be moved to the `mm` arm, which is where it is actually useful
anyway.
The subsequent patches that make use of `boot_params` in other arms can
also access the exact same data using `gsp_static_info`:
- `bar1_pde_base` is also accessible from `gsp_static_info` (let's also
make it public instead of adding an accessor method),
- The other `boot_params` used to build the `GpuMM` can be reconstructed
from `usable_vram`.
Which means `boot_params` and `BootParams` can be removed (and the
`Cell` import), and we have something simpler and more direct that takes
~60 less LoCs.
In other words, this arm remains as it was:
gsp_static_info: gsp.boot(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)?,
> + // Create GPU memory manager owning memory management resources.
> + // Uses the usable VRAM region from GSP for buddy allocator.
> + mm <- {
this arm can now be:
let usable_vram = &gsp_static_info.usable_fb_region;
dev_info!(
pdev.as_ref(),
"Using FB region: {:#x}..{:#x}\n",
usable_vram.start,
usable_vram.end
);
GpuMm::new(devres_bar.clone(), GpuBuddyParams {
base_offset_bytes: usable_vram.start,
physical_memory_size_bytes: usable_vram.end - usable_vram.start,
chunk_size_bytes: SZ_4K.into_safe_cast(),
})?
> + let params = boot_params.get();
> + GpuMm::new(devres_bar.clone(), GpuBuddyParams {
> + base_offset_bytes: params.usable_vram_start,
> + physical_memory_size_bytes: params.usable_vram_size,
> + chunk_size_bytes: SZ_4K.into_safe_cast(),
> + })?
> + },
>
> bar: devres_bar,
> })
> diff --git a/drivers/gpu/nova-core/gsp/boot.rs b/drivers/gpu/nova-core/gsp/boot.rs
> index 7a4a0c759267..bc4446282613 100644
> --- a/drivers/gpu/nova-core/gsp/boot.rs
> +++ b/drivers/gpu/nova-core/gsp/boot.rs
> @@ -150,7 +150,7 @@ pub(crate) fn boot(
>
> let gsp_fw = KBox::pin_init(GspFirmware::new(dev, chipset, FIRMWARE_VERSION), GFP_KERNEL)?;
>
> - let fb_layout = FbLayout::new(chipset, bar, &gsp_fw)?;
> + let mut fb_layout = FbLayout::new(chipset, bar, &gsp_fw)?;
> dev_dbg!(dev, "{:#x?}\n", fb_layout);
>
> Self::run_fwsec_frts(dev, gsp_falcon, bar, &bios, &fb_layout)?;
> @@ -252,6 +252,11 @@ pub(crate) fn boot(
> Err(e) => dev_warn!(pdev.as_ref(), "GPU name unavailable: {:?}\n", e),
> }
>
> + // Populate usable VRAM from GSP response.
> + if let Some((base, size)) = info.usable_fb_region() {
> + fb_layout.set_usable_vram(base, size);
> + }
> +
And this change is not needed anymore.
next prev parent reply other threads:[~2026-03-02 13:48 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 22:52 [PATCH v8 00/25] gpu: nova-core: Add memory management support Joel Fernandes
2026-02-24 22:52 ` Joel Fernandes
2026-02-24 22:52 ` [PATCH v8 01/25] gpu: nova-core: Select GPU_BUDDY for VRAM allocation Joel Fernandes
2026-02-24 22:52 ` Joel Fernandes
2026-03-01 12:41 ` Alexandre Courbot
2026-02-24 22:53 ` [PATCH v8 02/25] gpu: nova-core: Kconfig: Sort select statements alphabetically Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-03-01 12:40 ` Alexandre Courbot
2026-02-24 22:53 ` [PATCH v8 03/25] gpu: nova-core: gsp: Return GspStaticInfo and FbLayout from boot() Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 04/25] gpu: nova-core: gsp: Extract usable FB region from GSP Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-03-01 12:43 ` Alexandre Courbot
2026-02-24 22:53 ` [PATCH v8 05/25] gpu: nova-core: fb: Add usable_vram field to FbLayout Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 06/25] gpu: nova-core: mm: Add support to use PRAMIN windows to write to VRAM Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-03-02 11:58 ` Alexandre Courbot
2026-03-03 19:44 ` Joel Fernandes
2026-03-02 12:23 ` Alexandre Courbot
2026-03-03 21:01 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 07/25] docs: gpu: nova-core: Document the PRAMIN aperture mechanism Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-03-02 12:02 ` Alexandre Courbot
2026-02-24 22:53 ` [PATCH v8 08/25] gpu: nova-core: mm: Add common memory management types Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 09/25] gpu: nova-core: mm: Add TLB flush support Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 10/25] gpu: nova-core: mm: Add GpuMm centralized memory manager Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 11/25] gpu: nova-core: mm: Use usable VRAM region for buddy allocator Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-03-01 12:56 ` Alexandre Courbot [this message]
2026-03-02 3:08 ` Alexandre Courbot
2026-03-03 23:54 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 12/25] gpu: nova-core: mm: Add common types for all page table formats Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 13/25] gpu: nova-core: mm: Add MMU v2 page table types Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 14/25] gpu: nova-core: mm: Add MMU v3 " Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 15/25] gpu: nova-core: mm: Add unified page table entry wrapper enums Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 16/25] gpu: nova-core: mm: Add page table walker for MMU v2/v3 Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-25 5:39 ` Gary Guo
2026-02-25 5:39 ` Gary Guo
2026-02-25 14:26 ` Joel Fernandes
2026-02-25 14:26 ` Joel Fernandes
2026-03-01 13:15 ` Gary Guo
2026-03-01 13:15 ` Gary Guo
2026-03-02 20:10 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 17/25] gpu: nova-core: mm: Add Virtual Memory Manager Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 18/25] gpu: nova-core: mm: Add virtual address range tracking to VMM Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 19/25] gpu: nova-core: mm: Add multi-page mapping API " Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 20/25] gpu: nova-core: Add BAR1 aperture type and size constant Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 21/25] gpu: nova-core: gsp: Add BAR1 PDE base accessors Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 22/25] gpu: nova-core: mm: Add BAR1 user interface Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 23/25] gpu: nova-core: mm: Add BarUser to struct Gpu and create at boot Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 24/25] gpu: nova-core: mm: Add BAR1 memory management self-tests Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-02-24 22:53 ` [PATCH v8 25/25] gpu: nova-core: mm: Add PRAMIN aperture self-tests Joel Fernandes
2026-02-24 22:53 ` Joel Fernandes
2026-03-02 12:04 ` Alexandre Courbot
2026-03-02 20:11 ` Joel Fernandes
2026-03-05 7:26 ` Alexandre Courbot
2026-03-05 7:26 ` Alexandre Courbot
2026-03-06 1:49 ` Joel Fernandes
2026-02-24 23:54 ` ✗ Fi.CI.BUILD: failure for gpu: nova-core: Add memory management support Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DGRGNLACDJI2.1JFEXE1GL1ZVM@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@redhat.com \
--cc=alex.gaynor@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=alexeyi@nvidia.com \
--cc=aliceryhl@google.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=apopple@nvidia.com \
--cc=arighi@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=boqun@kernel.org \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=ecourtney@nvidia.com \
--cc=elle@weathered-steel.dev \
--cc=gary@garyguo.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joel@joelfernandes.org \
--cc=joelagnelf@nvidia.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=koen.koning@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=ndjukic@nvidia.com \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=phasta@kernel.org \
--cc=ray.huang@amd.com \
--cc=rodrigo.vivi@intel.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tmgross@umich.edu \
--cc=tursulin@ursulin.net \
--cc=zhiw@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.