From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Benno Lossin" <lossin@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>, <nova-gpu@lists.linux.dev>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
<rust-for-linux@vger.kernel.org>,
"dri-devel" <dri-devel-bounces@lists.freedesktop.org>
Subject: Re: [PATCH v2 10/10] gpu: nova-core: wait for RISC-V HALTED on FSP unload
Date: Thu, 23 Jul 2026 12:59:23 +0900 [thread overview]
Message-ID: <DK5NESIUCJZH.CXHNE27Q0OE9@nvidia.com> (raw)
In-Reply-To: <DK5MRB6JWL34.3IRXDQ8KWWAT7@nvidia.com>
On Thu Jul 23, 2026 at 12:28 PM JST, Alexandre Courbot wrote:
> On Fri Jul 3, 2026 at 3:22 AM PDT, Eliot Courtney wrote:
>> Currently the code waits for "not active" but this is not the same as
>> halted as there are more than two states. Match openrm here and wait for
>> halted instead.
>>
>> Fixes: c7fea1f70944 ("gpu: nova-core: add non-sec2 unload path")
>> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
>> ---
>> drivers/gpu/nova-core/falcon.rs | 11 +++++++++++
>> drivers/gpu/nova-core/falcon/hal.rs | 5 +++++
>> drivers/gpu/nova-core/falcon/hal/ga102.rs | 7 +++++++
>> drivers/gpu/nova-core/falcon/hal/tu102.rs | 4 ++++
>> drivers/gpu/nova-core/gsp/hal/gh100.rs | 11 +++++++++--
>> 5 files changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
>> index 78948cc8bff3..ec286017535f 100644
>> --- a/drivers/gpu/nova-core/falcon.rs
>> +++ b/drivers/gpu/nova-core/falcon.rs
>> @@ -749,11 +749,22 @@ pub(crate) fn signature_reg_fuse_version(
>>
>> /// Check if the RISC-V core is active.
>> ///
>> + /// Note that this does not imply that the RISC-V core is halted if it returns `false`.
>
> I would say "guarantee" instead of "imply" here, wdyt?
Yes I think "guarantee" is better here since otherwise you need the
mathematical reading of "imply" to not think it's an if-and-only-if.
>
>> + ///
>> /// Returns `true` if the RISC-V core is active, `false` otherwise.
>> pub(crate) fn is_riscv_active(&self) -> bool {
>> self.hal.is_riscv_active(self)
>> }
>>
>> + /// Checks whether the RISC-V core is halted.
>> + ///
>> + /// Note that this does not imply that the RISC-V core is active if it returns `false`.
>
> Same here.
>
>> + ///
>> + /// Returns [`ENOTSUPP`] if the status is not available.
>> + pub(crate) fn is_riscv_halted(&self) -> Result<bool> {
>> + self.hal.is_riscv_halted(self)
>> + }
>> +
>> /// Load a firmware image into Falcon memory, using the preferred method for the current
>> /// chipset.
>> pub(crate) fn load<F: FalconFirmware<Target = E> + FalconDmaLoadable>(&self, fw: &F) -> Result {
>> diff --git a/drivers/gpu/nova-core/falcon/hal.rs b/drivers/gpu/nova-core/falcon/hal.rs
>> index ee4a017f3a4c..7e532889a1f4 100644
>> --- a/drivers/gpu/nova-core/falcon/hal.rs
>> +++ b/drivers/gpu/nova-core/falcon/hal.rs
>> @@ -53,6 +53,11 @@ fn signature_reg_fuse_version(
>> /// Returns `true` if the RISC-V core is active, `false` otherwise.
>> fn is_riscv_active(&self, falcon: &Falcon<'_, E>) -> bool;
>>
>> + /// Checks whether the RISC-V core is halted.
>> + ///
>> + /// Returns [`ENOTSUPP`] if the chipset does not expose RISC-V halt status.
>> + fn is_riscv_halted(&self, falcon: &Falcon<'_, E>) -> Result<bool>;
>
> It's a bit unfortunate that we add a runtime error check for something
> that is essentially known to never fail (the GSP's GH100 HAL being the
> sole caller of this method). I cannot think of a better design at
> the moment, but this hints that our HAL could be improved as I think we
> already have several instances of the same pattern elsewhere.
>
> Not a big deal anyway - if you can confirm my wording nit above, this
> one should be good to merge as well.
Yeah, I couldn't think of a good way to do this either and I was unhappy
about it. Wording nit sgtm. Thanks!
next prev parent reply other threads:[~2026-07-23 3:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 10:22 [PATCH v2 00/10] gpu: nova-core: blackwell follow-ups and fixes Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 01/10] gpu: nova-core: fsp: limit FSP receive message allocation size Eliot Courtney
2026-07-23 2:55 ` Alexandre Courbot
2026-07-03 10:22 ` [PATCH v2 02/10] gpu: nova-core: fsp: catch bogus queue pointer issues Eliot Courtney
2026-07-23 2:55 ` Alexandre Courbot
2026-07-03 10:22 ` [PATCH v2 03/10] gpu: nova-core: gsp: ensure lifetime for FMC boot DMA allocations Eliot Courtney
2026-07-23 2:56 ` Alexandre Courbot
2026-07-03 10:22 ` [PATCH v2 04/10] gpu: nova-core: gsp: ensure LibOS DMA allocation lives long enough Eliot Courtney
2026-07-23 2:56 ` Alexandre Courbot
2026-07-03 10:22 ` [PATCH v2 05/10] gpu: nova-core: split FbLayout into FSP and non-FSP versions Eliot Courtney
2026-07-23 5:02 ` Alexandre Courbot
2026-07-23 6:34 ` Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 06/10] gpu: nova-core: correct FRTS vidmem offset calculation Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 07/10] gpu: nova-core: rename heap size field Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 08/10] gpu: nova-core: return non-WPR heap size as u64 from HALs Eliot Courtney
2026-07-03 10:22 ` [PATCH v2 09/10] gpu: nova-core: correct RISC-V HALTED field Eliot Courtney
2026-07-23 2:56 ` Alexandre Courbot
2026-07-03 10:22 ` [PATCH v2 10/10] gpu: nova-core: wait for RISC-V HALTED on FSP unload Eliot Courtney
2026-07-23 3:28 ` Alexandre Courbot
2026-07-23 3:59 ` Eliot Courtney [this message]
2026-07-23 4:29 ` 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=DK5NESIUCJZH.CXHNE27Q0OE9@nvidia.com \
--to=ecourtney@nvidia.com \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel-bounces@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=ttabi@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