From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "John Hubbard" <jhubbard@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"Shashank Sharma" <shashanks@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>, "David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"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>,
rust-for-linux@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v9 06/31] gpu: nova-core: Hopper/Blackwell: skip GFW boot waiting
Date: Mon, 30 Mar 2026 23:52:45 +0900 [thread overview]
Message-ID: <DHG7AEASTW6E.2QTXB1D0GA0UF@nvidia.com> (raw)
In-Reply-To: <20260326013902.588242-7-jhubbard@nvidia.com>
On Thu Mar 26, 2026 at 10:38 AM JST, John Hubbard wrote:
> Hopper and Blackwell GPUs use FSP-based secure boot and do not
> require waiting for GFW_BOOT completion. Move the GFW_BOOT wait
> into a GPU HAL so the decision and the wait both live in the HAL.
>
> Pre-Hopper families (Tu102 HAL) wait for GFW_BOOT completion.
> Hopper and later (Gh100 HAL) skip it and boot via FSP instead.
>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> drivers/gpu/nova-core/gpu.rs | 6 +++--
> drivers/gpu/nova-core/gpu/hal.rs | 41 ++++++++++++++++++++++++++++++++
> 2 files changed, 45 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/nova-core/gpu/hal.rs
>
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index f70bfbda1614..8332ad67c0af 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
> @@ -21,11 +21,12 @@
> Falcon, //
> },
> fb::SysmemFlush,
> - gfw,
> gsp::Gsp,
> regs,
> };
>
> +mod hal;
> +
> macro_rules! define_chipset {
> ({ $($variant:ident = $value:expr),* $(,)* }) =>
> {
> @@ -311,6 +312,7 @@ pub(crate) fn new<'a>(
> spec: Spec,
> ) -> impl PinInit<Self, Error> + 'a {
> let dma_mask = spec.chipset().arch().dma_mask();
> + let hal = hal::gpu_hal(spec.chipset());
>
> try_pin_init!(Self {
> // We must wait for GFW_BOOT completion before doing any significant setup on the GPU.
> @@ -319,7 +321,7 @@ pub(crate) fn new<'a>(
> // still constructing it, so no concurrent DMA allocations can exist.
> unsafe { pdev.dma_set_mask_and_coherent(dma_mask)? };
>
> - gfw::wait_gfw_boot_completion(bar)
> + hal.wait_gfw_boot_completion(bar)
> .inspect_err(|_| dev_err!(pdev, "GFW boot did not complete\n"))?;
> },
>
> diff --git a/drivers/gpu/nova-core/gpu/hal.rs b/drivers/gpu/nova-core/gpu/hal.rs
> new file mode 100644
> index 000000000000..164410992659
> --- /dev/null
> +++ b/drivers/gpu/nova-core/gpu/hal.rs
> @@ -0,0 +1,41 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +use kernel::prelude::*;
> +
> +use crate::{
> + driver::Bar0,
> + gfw,
> + gpu::{
> + Architecture,
> + Chipset, //
> + },
> +};
> +
> +pub(crate) trait GpuHal {
> + /// Waits for GFW_BOOT completion if required by this hardware family.
> + fn wait_gfw_boot_completion(&self, bar: &Bar0) -> Result;
> +}
> +
> +struct Tu102;
> +struct Gh100;
> +
> +impl GpuHal for Tu102 {
> + fn wait_gfw_boot_completion(&self, bar: &Bar0) -> Result {
> + gfw::wait_gfw_boot_completion(bar)
> + }
> +}
> +
> +impl GpuHal for Gh100 {
> + fn wait_gfw_boot_completion(&self, _bar: &Bar0) -> Result {
> + Ok(())
> + }
> +}
Please take a look at how other HALs are implemented: each HAL instance
is in its own module. That's not just a cosmetic choice; it allows us to
keep the chipset's specific HAL struct and its helpers completely
private and forces us to make code-sharing explicit. Furthermore, this
particular HAL is bound to grow, so let's split it properly from the
start.
If you do that it also makes more sense to use constants (contrary to
Gary's feedback on v8), if only to align with the rest of the driver.
Once this is done, making `gpu::hal::tu102` absorb the `gfw` module is
trivial, so let's do that while we are at it - having `gfw` as being
driver-wide makes little sense since it has a very limited role for a
specific subset of the chips we support.
next prev parent reply other threads:[~2026-03-30 14:52 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 1:38 [PATCH v9 00/31] gpu: nova-core: firmware: Hopper/Blackwell support John Hubbard
2026-03-26 1:38 ` [PATCH v9 01/31] gpu: nova-core: Hopper/Blackwell: basic GPU identification John Hubbard
2026-03-26 1:38 ` [PATCH v9 02/31] gpu: nova-core: factor .fwsignature* selection into a new find_gsp_sigs_section() John Hubbard
2026-03-30 14:29 ` Alexandre Courbot
2026-03-30 17:51 ` John Hubbard
2026-03-26 1:38 ` [PATCH v9 03/31] gpu: nova-core: use GPU Architecture to simplify HAL selections John Hubbard
2026-03-26 1:38 ` [PATCH v9 04/31] gpu: nova-core: add Copy/Clone to Spec and Revision, add chipset() accessor John Hubbard
2026-03-26 1:38 ` [PATCH v9 05/31] gpu: nova-core: set DMA mask width based on GPU architecture John Hubbard
2026-03-30 14:32 ` Alexandre Courbot
2026-03-30 21:31 ` John Hubbard
2026-03-26 1:38 ` [PATCH v9 06/31] gpu: nova-core: Hopper/Blackwell: skip GFW boot waiting John Hubbard
2026-03-30 14:52 ` Alexandre Courbot [this message]
2026-03-30 15:20 ` Gary Guo
2026-03-30 18:33 ` Joel Fernandes
2026-03-30 19:15 ` John Hubbard
2026-03-31 0:18 ` Alexandre Courbot
2026-03-31 16:17 ` Joel Fernandes
2026-03-26 1:38 ` [PATCH v9 07/31] gpu: nova-core: move firmware image parsing code to firmware.rs John Hubbard
2026-03-26 1:38 ` [PATCH v9 08/31] gpu: nova-core: factor out an elf_str() function John Hubbard
2026-03-26 1:38 ` [PATCH v9 09/31] gpu: nova-core: don't assume 64-bit firmware images John Hubbard
2026-03-26 1:38 ` [PATCH v9 10/31] gpu: nova-core: add support for 32-bit " John Hubbard
2026-03-26 1:38 ` [PATCH v9 11/31] gpu: nova-core: add auto-detection of 32-bit, 64-bit " John Hubbard
2026-03-26 1:38 ` [PATCH v9 12/31] gpu: nova-core: Hopper/Blackwell: add FMC firmware image, in support of FSP John Hubbard
2026-03-26 1:38 ` [PATCH v9 13/31] gpu: nova-core: Hopper/Blackwell: add FSP falcon engine stub John Hubbard
2026-03-26 1:38 ` [PATCH v9 14/31] gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operations John Hubbard
2026-03-26 1:38 ` [PATCH v9 15/31] gpu: nova-core: Hopper/Blackwell: add FSP message infrastructure John Hubbard
2026-03-26 1:38 ` [PATCH v9 16/31] rust: ptr: add const_align_up() John Hubbard
2026-03-27 9:33 ` Miguel Ojeda
2026-03-30 21:41 ` John Hubbard
2026-03-31 0:03 ` Miguel Ojeda
2026-03-31 2:23 ` Alexandre Courbot
2026-03-31 10:26 ` Miguel Ojeda
2026-03-31 2:21 ` Alexandre Courbot
2026-03-31 2:36 ` John Hubbard
2026-03-31 10:24 ` Miguel Ojeda
2026-03-31 11:53 ` Danilo Krummrich
2026-04-03 10:01 ` Miguel Ojeda
2026-04-03 10:02 ` Miguel Ojeda
2026-03-26 1:38 ` [PATCH v9 17/31] gpu: nova-core: Hopper/Blackwell: calculate reserved FB heap size John Hubbard
2026-03-26 1:38 ` [PATCH v9 18/31] gpu: nova-core: add MCTP/NVDM protocol types for firmware communication John Hubbard
2026-03-26 1:38 ` [PATCH v9 19/31] gpu: nova-core: Hopper/Blackwell: add FSP secure boot completion waiting John Hubbard
2026-03-26 1:38 ` [PATCH v9 20/31] gpu: nova-core: Hopper/Blackwell: add FMC signature extraction John Hubbard
2026-03-26 1:38 ` [PATCH v9 21/31] gpu: nova-core: Hopper/Blackwell: add FSP send/receive messaging John Hubbard
2026-03-26 1:38 ` [PATCH v9 22/31] gpu: nova-core: Hopper/Blackwell: add FspCotVersion type John Hubbard
2026-03-26 1:38 ` [PATCH v9 23/31] gpu: nova-core: Hopper/Blackwell: larger non-WPR heap John Hubbard
2026-03-26 1:38 ` [PATCH v9 24/31] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot John Hubbard
2026-03-30 15:11 ` Alexandre Courbot
2026-03-30 22:54 ` John Hubbard
2026-03-26 1:38 ` [PATCH v9 25/31] gpu: nova-core: Blackwell: use correct sysmem flush registers John Hubbard
2026-03-26 1:38 ` [PATCH v9 26/31] gpu: nova-core: make WPR heap sizing fallible John Hubbard
2026-03-26 1:38 ` [PATCH v9 27/31] gpu: nova-core: Hopper/Blackwell: larger WPR2 (GSP) heap John Hubbard
2026-03-26 1:38 ` [PATCH v9 28/31] gpu: nova-core: refactor SEC2 booter loading into BooterFirmware::run() John Hubbard
2026-03-26 1:39 ` [PATCH v9 29/31] gpu: nova-core: Hopper/Blackwell: add GSP lockdown release polling John Hubbard
2026-03-26 1:39 ` [PATCH v9 30/31] gpu: nova-core: Hopper/Blackwell: new location for PCI config mirror John Hubbard
2026-03-26 1:39 ` [PATCH v9 31/31] gpu: nova-core: Hopper/Blackwell: integrate FSP boot path into boot() John Hubbard
2026-03-30 5:10 ` [PATCH v9 00/31] gpu: nova-core: firmware: Hopper/Blackwell support Alexandre Courbot
2026-03-30 22:47 ` John Hubbard
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=DHG7AEASTW6E.2QTXB1D0GA0UF@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=shashanks@nvidia.com \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox