rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Courbot <acourbot@nvidia.com>
To: "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>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>
Cc: John Hubbard <jhubbard@nvidia.com>,
	 Alistair Popple <apopple@nvidia.com>,
	 Joel Fernandes <joelagnelf@nvidia.com>,
	Timur Tabi <ttabi@nvidia.com>,
	 rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	 nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	 Alexandre Courbot <acourbot@nvidia.com>
Subject: [PATCH v3 02/11] gpu: nova-core: move GSP boot code out of `Gpu` constructor
Date: Tue, 02 Sep 2025 23:31:56 +0900	[thread overview]
Message-ID: <20250902-nova_firmware-v3-2-56854d9c5398@nvidia.com> (raw)
In-Reply-To: <20250902-nova_firmware-v3-0-56854d9c5398@nvidia.com>

Right now the GSP boot code is very incomplete and limited to running
FRTS, so having it in `Gpu::new` is not a big constraint.

However, this will change as we add more steps of the GSP boot process,
some of which are rather cumbersome to perform on a
partially-constructed GPU instance.

Relatedly, booting the GSP typically happens only once in the GPU reset
cycle. Most of the data created to complete this step (notably firmware
loaded from user-space) is needed only temporary and can be discarded
once the GSP is booted; it then makes all the more sense to store these
as local variables of a dedicated method, instead of inside the `Gpu`
structure where they as kept as long as the GPU is bound, using dozens
of megabytes of host memory.

Thus, introduce a `start_gsp` method on the `Gpu` struct, which is
called by `probe` after the GPU is instantiated and will return the
running GSP instance, once the code completing its boot is integrated.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 drivers/gpu/nova-core/driver.rs | 10 +++++++++-
 drivers/gpu/nova-core/gpu.rs    | 41 ++++++++++++++++++++++++++++++-----------
 2 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
index 274989ea1fb4a5e3e6678a08920ddc76d2809ab2..1062014c0a488e959379f009c2e8029ffaa1e2f8 100644
--- a/drivers/gpu/nova-core/driver.rs
+++ b/drivers/gpu/nova-core/driver.rs
@@ -6,6 +6,8 @@
 
 #[pin_data]
 pub(crate) struct NovaCore {
+    // Placeholder for the real `Gsp` object once it is built.
+    pub(crate) gsp: (),
     #[pin]
     pub(crate) gpu: Gpu,
     _reg: auxiliary::Registration,
@@ -40,8 +42,14 @@ fn probe(pdev: &pci::Device<Core>, _info: &Self::IdInfo) -> Result<Pin<KBox<Self
         )?;
 
         let this = KBox::pin_init(
-            try_pin_init!(Self {
+            try_pin_init!(&this in Self {
                 gpu <- Gpu::new(pdev, bar)?,
+                gsp <- {
+                    // SAFETY: `this.gpu` is initialized to a valid value.
+                    let gpu = unsafe { &(*this.as_ptr()).gpu };
+
+                    gpu.start_gsp(pdev)?
+                },
                 _reg: auxiliary::Registration::new(
                     pdev.as_ref(),
                     c_str!("nova-drm"),
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 4d0f759610ec6eb8a716c039a2e67859410da17c..8343276e52e6a87a8ff1aff9fc484e00d4b57417 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -172,6 +172,8 @@ pub(crate) struct Gpu {
     /// System memory page required for flushing all pending GPU-side memory writes done through
     /// PCIE into system memory, via sysmembar (A GPU-initiated HW memory-barrier operation).
     sysmem_flush: SysmemFlush,
+    gsp_falcon: Falcon<Gsp>,
+    sec2_falcon: Falcon<Sec2>,
 }
 
 #[pinned_drop]
@@ -190,8 +192,8 @@ impl Gpu {
     /// TODO: this needs to be moved into a larger type responsible for booting the whole GSP
     /// (`GspBooter`?).
     fn run_fwsec_frts(
+        &self,
         dev: &device::Device<device::Bound>,
-        falcon: &Falcon<Gsp>,
         bar: &Bar0,
         bios: &Vbios,
         fb_layout: &FbLayout,
@@ -208,7 +210,7 @@ fn run_fwsec_frts(
 
         let fwsec_frts = FwsecFirmware::new(
             dev,
-            falcon,
+            &self.gsp_falcon,
             bar,
             bios,
             FwsecCommand::Frts {
@@ -218,7 +220,7 @@ fn run_fwsec_frts(
         )?;
 
         // Run FWSEC-FRTS to create the WPR2 region.
-        fwsec_frts.run(dev, falcon, bar)?;
+        fwsec_frts.run(dev, &self.gsp_falcon, bar)?;
 
         // SCRATCH_E contains the error code for FWSEC-FRTS.
         let frts_status = regs::NV_PBUS_SW_SCRATCH_0E_FRTS_ERR::read(bar).frts_err_code();
@@ -263,6 +265,28 @@ fn run_fwsec_frts(
         }
     }
 
+    /// Attempt to start the GSP.
+    ///
+    /// This is a GPU-dependent and complex procedure that involves loading firmware files from
+    /// user-space, patching them with signatures, and building firmware-specific intricate data
+    /// structures that the GSP will use at runtime.
+    ///
+    /// Upon return, the GSP is up and running, and its runtime object given as return value.
+    pub(crate) fn start_gsp(&self, pdev: &pci::Device<device::Bound>) -> Result<()> {
+        let dev = pdev.as_ref();
+
+        let bar = self.bar.access(dev)?;
+
+        let bios = Vbios::new(dev, bar)?;
+
+        let fb_layout = FbLayout::new(self.spec.chipset, bar)?;
+        dev_dbg!(dev, "{:#x?}\n", fb_layout);
+
+        self.run_fwsec_frts(dev, bar, &bios, &fb_layout)?;
+
+        Ok(())
+    }
+
     pub(crate) fn new(
         pdev: &pci::Device<device::Bound>,
         devres_bar: Arc<Devres<Bar0>>,
@@ -293,20 +317,15 @@ pub(crate) fn new(
         )?;
         gsp_falcon.clear_swgen0_intr(bar);
 
-        let _sec2_falcon = Falcon::<Sec2>::new(pdev.as_ref(), spec.chipset, bar, true)?;
-
-        let fb_layout = FbLayout::new(spec.chipset, bar)?;
-        dev_dbg!(pdev.as_ref(), "{:#x?}\n", fb_layout);
-
-        let bios = Vbios::new(pdev.as_ref(), bar)?;
-
-        Self::run_fwsec_frts(pdev.as_ref(), &gsp_falcon, bar, &bios, &fb_layout)?;
+        let sec2_falcon = Falcon::<Sec2>::new(pdev.as_ref(), spec.chipset, bar, true)?;
 
         Ok(pin_init!(Self {
             spec,
             bar: devres_bar,
             fw,
             sysmem_flush,
+            gsp_falcon,
+            sec2_falcon,
         }))
     }
 }

-- 
2.51.0


  parent reply	other threads:[~2025-09-02 14:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-02 14:31 [PATCH v3 00/11] gpu: nova-core: process and prepare more firmwares to boot GSP Alexandre Courbot
2025-09-02 14:31 ` [PATCH v3 01/11] gpu: nova-core: require `Send` on `FalconEngine` and `FalconHal` Alexandre Courbot
2025-09-02 14:31 ` Alexandre Courbot [this message]
2025-09-02 19:53   ` [PATCH v3 02/11] gpu: nova-core: move GSP boot code out of `Gpu` constructor Danilo Krummrich
2025-09-03  7:08     ` Alexandre Courbot
2025-09-03  7:21       ` Alexandre Courbot
2025-09-03  8:26       ` Danilo Krummrich
2025-09-03 10:44         ` Alexandre Courbot
2025-09-03 11:05           ` Danilo Krummrich
2025-09-03 12:29             ` Alexandre Courbot
2025-09-03 14:53               ` Danilo Krummrich
2025-09-04 15:28                 ` Joel Fernandes
2025-09-02 23:12   ` Danilo Krummrich
2025-09-03  7:10     ` Alexandre Courbot
2025-09-03  8:27       ` Danilo Krummrich
2025-09-02 14:31 ` [PATCH v3 03/11] gpu: nova-core: add Chipset::name() method Alexandre Courbot
2025-09-02 14:31 ` [PATCH v3 04/11] gpu: nova-core: firmware: move firmware request code into a function Alexandre Courbot
2025-09-02 14:31 ` [PATCH v3 05/11] gpu: nova-core: firmware: add support for common firmware header Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 06/11] gpu: nova-core: firmware: process Booter and patch its signature Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 07/11] gpu: nova-core: firmware: process and prepare the GSP firmware Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 08/11] gpu: nova-core: firmware: process the GSP bootloader Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 09/11] gpu: nova-core: firmware: use 570.144 firmware Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 10/11] gpu: nova-core: Add base files for r570.144 firmware bindings Alexandre Courbot
2025-09-02 14:32 ` [PATCH v3 11/11] gpu: nova-core: compute layout of more framebuffer regions required for GSP 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=20250902-nova_firmware-v3-2-56854d9c5398@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=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=tzimmermann@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).