From: John Hubbard <jhubbard@nvidia.com>
To: Danilo Krummrich <dakr@kernel.org>,
Alexandre Courbot <acourbot@nvidia.com>
Cc: "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>,
"John Hubbard" <jhubbard@nvidia.com>
Subject: [PATCH v10 06/28] gpu: nova-core: move GFW boot wait into a GPU HAL
Date: Fri, 10 Apr 2026 19:49:31 -0700 [thread overview]
Message-ID: <20260411024953.473149-7-jhubbard@nvidia.com> (raw)
In-Reply-To: <20260411024953.473149-1-jhubbard@nvidia.com>
Introduce a GpuHal trait and per-family dispatch so GPU boot
behavior can vary by architecture. Move wait_gfw_boot_completion()
from the standalone gfw module into gpu/hal/tu102.rs as the first
GpuHal implementation. All architectures currently dispatch to this
implementation, preserving existing behavior.
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
drivers/gpu/nova-core/gfw.rs | 76 -----------------------
drivers/gpu/nova-core/gpu.rs | 5 +-
drivers/gpu/nova-core/gpu/hal.rs | 29 +++++++++
drivers/gpu/nova-core/gpu/hal/tu102.rs | 86 ++++++++++++++++++++++++++
drivers/gpu/nova-core/nova_core.rs | 1 -
5 files changed, 118 insertions(+), 79 deletions(-)
delete mode 100644 drivers/gpu/nova-core/gfw.rs
create mode 100644 drivers/gpu/nova-core/gpu/hal.rs
create mode 100644 drivers/gpu/nova-core/gpu/hal/tu102.rs
diff --git a/drivers/gpu/nova-core/gfw.rs b/drivers/gpu/nova-core/gfw.rs
deleted file mode 100644
index fb75dd10a172..000000000000
--- a/drivers/gpu/nova-core/gfw.rs
+++ /dev/null
@@ -1,76 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-//! GPU Firmware (`GFW`) support, a.k.a `devinit`.
-//!
-//! Upon reset, the GPU runs some firmware code from the BIOS to setup its core parameters. Most of
-//! the GPU is considered unusable until this step is completed, so we must wait on it before
-//! performing driver initialization.
-//!
-//! A clarification about devinit terminology: devinit is a sequence of register read/writes after
-//! reset that performs tasks such as:
-//! 1. Programming VRAM memory controller timings.
-//! 2. Power sequencing.
-//! 3. Clock and PLL configuration.
-//! 4. Thermal management.
-//!
-//! devinit itself is a 'script' which is interpreted by an interpreter program typically running
-//! on the PMU microcontroller.
-//!
-//! Note that the devinit sequence also needs to run during suspend/resume.
-
-use kernel::{
- io::{
- poll::read_poll_timeout,
- Io, //
- },
- prelude::*,
- time::Delta, //
-};
-
-use crate::{
- driver::Bar0,
- regs, //
-};
-
-/// Wait for the `GFW` (GPU firmware) boot completion signal (`GFW_BOOT`), or a 4 seconds timeout.
-///
-/// Upon GPU reset, several microcontrollers (such as PMU, SEC2, GSP etc) run some firmware code to
-/// setup its core parameters. Most of the GPU is considered unusable until this step is completed,
-/// so it must be waited on very early during driver initialization.
-///
-/// The `GFW` code includes several components that need to execute before the driver loads. These
-/// components are located in the VBIOS ROM and executed in a sequence on these different
-/// microcontrollers. The devinit sequence typically runs on the PMU, and the FWSEC runs on the
-/// GSP.
-///
-/// This function waits for a signal indicating that core initialization is complete. Before this
-/// signal is received, little can be done with the GPU. This signal is set by the FWSEC running on
-/// the GSP in Heavy-secured mode.
-pub(crate) fn wait_gfw_boot_completion(bar: &Bar0) -> Result {
- // Before accessing the completion status in `NV_PGC6_AON_SECURE_SCRATCH_GROUP_05`, we must
- // first check `NV_PGC6_AON_SECURE_SCRATCH_GROUP_05_PRIV_LEVEL_MASK`. This is because
- // `NV_PGC6_AON_SECURE_SCRATCH_GROUP_05` becomes accessible only after the secure firmware
- // (FWSEC) lowers the privilege level to allow CPU (LS/Light-secured) access. We can only
- // safely read the status register from CPU (LS/Light-secured) once the mask indicates
- // that the privilege level has been lowered.
- //
- // TIMEOUT: arbitrarily large value. GFW starts running immediately after the GPU is put out of
- // reset, and should complete in less time than that.
- read_poll_timeout(
- || {
- Ok(
- // Check that FWSEC has lowered its protection level before reading the GFW_BOOT
- // status.
- bar.read(regs::NV_PGC6_AON_SECURE_SCRATCH_GROUP_05_PRIV_LEVEL_MASK)
- .read_protection_level0()
- && bar
- .read(regs::NV_PGC6_AON_SECURE_SCRATCH_GROUP_05_0_GFW_BOOT)
- .completed(),
- )
- },
- |&gfw_booted| gfw_booted,
- Delta::from_millis(1),
- Delta::from_secs(4),
- )
- .map(|_| ())
-}
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 6db646a49519..0b3a62f6ad1b 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -24,11 +24,12 @@
Falcon, //
},
fb::SysmemFlush,
- gfw,
gsp::Gsp,
regs,
};
+mod hal;
+
macro_rules! define_chipset {
({ $($variant:ident = $value:expr),* $(,)* }) =>
{
@@ -291,7 +292,7 @@ pub(crate) fn new<'a>(
// still constructing it, so no concurrent DMA allocations can exist.
unsafe { pdev.dma_set_mask_and_coherent(spec.chipset.arch().dma_mask())? };
- gfw::wait_gfw_boot_completion(bar)
+ hal::gpu_hal(spec.chipset).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..a261c6af92be
--- /dev/null
+++ b/drivers/gpu/nova-core/gpu/hal.rs
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+
+use kernel::prelude::*;
+
+use crate::{
+ driver::Bar0,
+ gpu::{
+ Architecture,
+ Chipset, //
+ },
+};
+
+mod tu102;
+
+pub(crate) trait GpuHal {
+ /// Waits for GFW_BOOT completion if required by this hardware family.
+ fn wait_gfw_boot_completion(&self, bar: &Bar0) -> Result;
+}
+
+pub(super) fn gpu_hal(chipset: Chipset) -> &'static dyn GpuHal {
+ match chipset.arch() {
+ Architecture::Turing
+ | Architecture::Ampere
+ | Architecture::Ada
+ | Architecture::Hopper
+ | Architecture::BlackwellGB10x
+ | Architecture::BlackwellGB20x => tu102::TU102_HAL,
+ }
+}
diff --git a/drivers/gpu/nova-core/gpu/hal/tu102.rs b/drivers/gpu/nova-core/gpu/hal/tu102.rs
new file mode 100644
index 000000000000..08dd4434bd72
--- /dev/null
+++ b/drivers/gpu/nova-core/gpu/hal/tu102.rs
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! GPU Firmware (`GFW`) support, a.k.a `devinit`.
+//!
+//! Upon reset, the GPU runs some firmware code from the BIOS to setup its core parameters. Most of
+//! the GPU is considered unusable until this step is completed, so we must wait on it before
+//! performing driver initialization.
+//!
+//! A clarification about devinit terminology: devinit is a sequence of register read/writes after
+//! reset that performs tasks such as:
+//! 1. Programming VRAM memory controller timings.
+//! 2. Power sequencing.
+//! 3. Clock and PLL configuration.
+//! 4. Thermal management.
+//!
+//! devinit itself is a 'script' which is interpreted by an interpreter program typically running
+//! on the PMU microcontroller.
+//!
+//! Note that the devinit sequence also needs to run during suspend/resume.
+
+use kernel::{
+ io::{
+ poll::read_poll_timeout,
+ Io, //
+ },
+ prelude::*,
+ time::Delta, //
+};
+
+use crate::{
+ driver::Bar0,
+ regs, //
+};
+
+use super::GpuHal;
+
+struct Tu102;
+
+impl GpuHal for Tu102 {
+ /// Wait for the `GFW` (GPU firmware) boot completion signal (`GFW_BOOT`), or a 4 seconds
+ /// timeout.
+ ///
+ /// Upon GPU reset, several microcontrollers (such as PMU, SEC2, GSP etc) run some firmware
+ /// code to setup its core parameters. Most of the GPU is considered unusable until this step
+ /// is completed, so it must be waited on very early during driver initialization.
+ ///
+ /// The `GFW` code includes several components that need to execute before the driver loads.
+ /// These components are located in the VBIOS ROM and executed in a sequence on these different
+ /// microcontrollers. The devinit sequence typically runs on the PMU, and the FWSEC runs on the
+ /// GSP.
+ ///
+ /// This function waits for a signal indicating that core initialization is complete. Before
+ /// this signal is received, little can be done with the GPU. This signal is set by the FWSEC
+ /// running on the GSP in Heavy-secured mode.
+ fn wait_gfw_boot_completion(&self, bar: &Bar0) -> Result {
+ // Before accessing the completion status in `NV_PGC6_AON_SECURE_SCRATCH_GROUP_05`, we must
+ // first check `NV_PGC6_AON_SECURE_SCRATCH_GROUP_05_PRIV_LEVEL_MASK`. This is because
+ // `NV_PGC6_AON_SECURE_SCRATCH_GROUP_05` becomes accessible only after the secure firmware
+ // (FWSEC) lowers the privilege level to allow CPU (LS/Light-secured) access. We can only
+ // safely read the status register from CPU (LS/Light-secured) once the mask indicates
+ // that the privilege level has been lowered.
+ //
+ // TIMEOUT: arbitrarily large value. GFW starts running immediately after the GPU is put
+ // out of reset, and should complete in less time than that.
+ read_poll_timeout(
+ || {
+ Ok(
+ // Check that FWSEC has lowered its protection level before reading the
+ // GFW_BOOT status.
+ bar.read(regs::NV_PGC6_AON_SECURE_SCRATCH_GROUP_05_PRIV_LEVEL_MASK)
+ .read_protection_level0()
+ && bar
+ .read(regs::NV_PGC6_AON_SECURE_SCRATCH_GROUP_05_0_GFW_BOOT)
+ .completed(),
+ )
+ },
+ |&gfw_booted| gfw_booted,
+ Delta::from_millis(1),
+ Delta::from_secs(4),
+ )
+ .map(|_| ())
+ }
+}
+
+const TU102: Tu102 = Tu102;
+pub(super) const TU102_HAL: &dyn GpuHal = &TU102;
diff --git a/drivers/gpu/nova-core/nova_core.rs b/drivers/gpu/nova-core/nova_core.rs
index 04a1fa6b25f8..3a609f6937e4 100644
--- a/drivers/gpu/nova-core/nova_core.rs
+++ b/drivers/gpu/nova-core/nova_core.rs
@@ -17,7 +17,6 @@
mod falcon;
mod fb;
mod firmware;
-mod gfw;
mod gpu;
mod gsp;
#[macro_use]
--
2.53.0
next prev parent reply other threads:[~2026-04-11 2:50 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-11 2:49 [PATCH v10 00/28] gpu: nova-core: firmware: Hopper/Blackwell support John Hubbard
2026-04-11 2:49 ` [PATCH v10 01/28] gpu: nova-core: factor .fwsignature* selection into a new find_gsp_sigs_section() John Hubbard
2026-04-11 2:49 ` [PATCH v10 02/28] gpu: nova-core: use GPU Architecture to simplify HAL selections John Hubbard
2026-04-20 16:06 ` Gary Guo
2026-04-11 2:49 ` [PATCH v10 03/28] gpu: nova-core: Hopper/Blackwell: basic GPU identification John Hubbard
2026-04-11 3:58 ` Timur Tabi
2026-04-13 21:08 ` John Hubbard
2026-04-13 21:21 ` Timur Tabi
2026-04-13 21:29 ` John Hubbard
2026-04-17 7:27 ` Alexandre Courbot
2026-04-17 7:49 ` Alexandre Courbot
2026-04-20 16:08 ` Gary Guo
2026-04-11 2:49 ` [PATCH v10 04/28] gpu: nova-core: add Copy/Clone to Spec and Revision John Hubbard
2026-04-20 16:17 ` Gary Guo
2026-04-11 2:49 ` [PATCH v10 05/28] gpu: nova-core: set DMA mask width based on GPU architecture John Hubbard
2026-04-20 16:17 ` Gary Guo
2026-04-11 2:49 ` John Hubbard [this message]
2026-04-11 2:49 ` [PATCH v10 07/28] gpu: nova-core: Hopper/Blackwell: skip GFW boot waiting John Hubbard
2026-04-11 2:49 ` [PATCH v10 08/28] gpu: nova-core: Blackwell: calculate reserved FB heap size John Hubbard
2026-04-17 14:23 ` Alexandre Courbot
2026-04-18 1:42 ` John Hubbard
2026-04-20 16:20 ` Gary Guo
2026-04-11 2:49 ` [PATCH v10 09/28] gpu: nova-core: Hopper/Blackwell: new location for PCI config mirror John Hubbard
2026-04-17 14:23 ` Alexandre Courbot
2026-04-18 1:46 ` John Hubbard
2026-04-18 1:54 ` John Hubbard
2026-04-20 3:10 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 10/28] gpu: nova-core: refactor SEC2 booter loading into BooterFirmware::run() John Hubbard
2026-04-11 2:49 ` [PATCH v10 11/28] gpu: nova-core: Hopper/Blackwell: integrate FSP boot path into boot() John Hubbard
2026-04-17 14:24 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 12/28] gpu: nova-core: don't assume 64-bit firmware images John Hubbard
2026-04-11 2:49 ` [PATCH v10 13/28] gpu: nova-core: add support for 32-bit " John Hubbard
2026-04-11 2:49 ` [PATCH v10 14/28] gpu: nova-core: add auto-detection of 32-bit, 64-bit " John Hubbard
2026-04-11 2:49 ` [PATCH v10 15/28] gpu: nova-core: Hopper/Blackwell: add FSP falcon engine stub John Hubbard
2026-04-11 2:49 ` [PATCH v10 16/28] gpu: nova-core: Hopper/Blackwell: add FMC firmware image, in support of FSP John Hubbard
2026-04-11 2:49 ` [PATCH v10 17/28] gpu: nova-core: Hopper/Blackwell: add FSP secure boot completion waiting John Hubbard
2026-04-17 14:24 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 18/28] gpu: nova-core: Hopper/Blackwell: add FMC signature extraction John Hubbard
2026-04-17 14:24 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 19/28] gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operations John Hubbard
2026-04-11 2:49 ` [PATCH v10 20/28] gpu: nova-core: Hopper/Blackwell: add FSP message infrastructure John Hubbard
2026-04-11 2:49 ` [PATCH v10 21/28] gpu: nova-core: add MCTP/NVDM protocol types for firmware communication John Hubbard
2026-04-11 2:49 ` [PATCH v10 22/28] gpu: nova-core: Hopper/Blackwell: add FSP send/receive messaging John Hubbard
2026-04-11 2:49 ` [PATCH v10 23/28] gpu: nova-core: Hopper/Blackwell: add FspCotVersion type John Hubbard
2026-04-11 2:49 ` [PATCH v10 24/28] gpu: nova-core: Hopper/Blackwell: larger non-WPR heap John Hubbard
2026-04-20 2:52 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 25/28] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot John Hubbard
2026-04-11 2:49 ` [PATCH v10 26/28] gpu: nova-core: Blackwell: use correct sysmem flush registers John Hubbard
2026-04-20 14:02 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 27/28] gpu: nova-core: Hopper/Blackwell: larger WPR2 (GSP) heap John Hubbard
2026-04-20 7:02 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 28/28] gpu: nova-core: Hopper/Blackwell: add GSP lockdown release polling John Hubbard
2026-04-17 14:34 ` [PATCH v10 00/28] gpu: nova-core: firmware: Hopper/Blackwell support Alexandre Courbot
2026-04-30 1:42 ` Alexandre Courbot
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=20260411024953.473149-7-jhubbard@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--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=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 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.