From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>, "Gary Guo" <gary@garyguo.net>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>
Cc: <nova-gpu@lists.linux.dev>, <dri-devel@lists.freedesktop.org>,
<linux-kernel@vger.kernel.org>, <rust-for-linux@vger.kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>
Subject: Re: [PATCH v6 00/13] gpu: nova-core: consolidate and streamline GSP boot process
Date: Thu, 16 Jul 2026 07:41:27 -0700 [thread overview]
Message-ID: <DK02OL2V85GC.3RA06XWW10NL5@nvidia.com> (raw)
In-Reply-To: <20260709-nova-bootcontext-v6-0-520cbf8b9b50@nvidia.com>
On Wed Jul 8, 2026 at 11:52 PM PDT, Alexandre Courbot wrote:
> The recently introduced `GspBootContext` is useful in at least two
> other places:
>
> - As a replacement for the sequencer's `GspSequencerParams`,
> - As the main parameter of `Gsp::unload`, for symmetry with `Gsp::boot`.
>
> This symmetry can be further exploited to make `Gsp::boot` and
> `Gsp::unload` generic over the exact boot context required for the
> current chip. Doing so requires some more preliminary work that goes
> beyond this series, but this groundwork is needed regardless.
>
> Another cleanup that can be performed as a consequence is the removal of
> the `BootUnloadGuard`. This type is cumbersome as it holds extra
> references to the boot context, making it difficult to make some of
> these references mutable (as we want to do with the `Falcon`s that
> should require exclusive access to load and run firmware). Furthermore,
> it is only needed a single time in `Gsp::boot`, and is inadequate for
> handling errors occurring in HALs.
>
> Based on Eliot's feedback on v4, the series then removes the last
> remnants of the boot procedure leaking outside of the HALs, and
> consolidates everything within the GSP and FSP HALs.
>
> This series applies on the latest `drm-rust-next`.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Pushed to drm-rust-next! Thanks all.
prev parent reply other threads:[~2026-07-16 14:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 6:52 [PATCH v6 00/13] gpu: nova-core: consolidate and streamline GSP boot process Alexandre Courbot
2026-07-09 6:52 ` [PATCH v6 01/13] gpu: nova-core: gsp: sequencer: use GspBootContext Alexandre Courbot
2026-07-09 6:52 ` [PATCH v6 02/13] gpu: nova-core: gsp: sequencer: do not store sequence into GspSequencer Alexandre Courbot
2026-07-09 6:52 ` [PATCH v6 03/13] gpu: nova-core: gsp: replace BootUnloadGuard with local handlers Alexandre Courbot
2026-07-09 6:52 ` [PATCH v6 04/13] gpu: nova-core: gsp: pass GspBootContext to unload methods Alexandre Courbot
2026-07-09 6:52 ` [PATCH v6 05/13] gpu: nova-core: gsp: centralize missing unload bundle warnings Alexandre Courbot
2026-07-09 6:52 ` [PATCH v6 06/13] gpu: nova-core: gsp: fold TU102 unload bundle construction into HAL method Alexandre Courbot
2026-07-09 6:53 ` [PATCH v6 07/13] gpu: nova-core: gsp: turn FWSEC execution " Alexandre Courbot
2026-07-09 6:53 ` [PATCH v6 08/13] gpu: nova-core: gsp: make use of FWSEC bootloader a property of the TU102 HAL Alexandre Courbot
2026-07-09 6:53 ` [PATCH v6 09/13] gpu: nova-core: move GSP firmware files decision to GSP HAL Alexandre Courbot
2026-07-09 6:53 ` [PATCH v6 10/13] gpu: nova-core: avoid repeated calls to pci::Device::as_ref Alexandre Courbot
2026-07-09 6:53 ` [PATCH v6 11/13] gpu: nova-core: gsp: pass GspBootContext mutably Alexandre Courbot
2026-07-09 6:53 ` [PATCH v6 12/13] gpu: nova-core: gsp: separate context and GPU lifetimes in GspBootContext Alexandre Courbot
2026-07-09 6:53 ` [PATCH v6 13/13] gpu: nova-core: store Fsp instance in Gpu Alexandre Courbot
2026-07-16 14:41 ` Alexandre Courbot [this message]
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=DK02OL2V85GC.3RA06XWW10NL5@nvidia.com \
--to=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--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.