[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DDONE8QZTV0X.29VK3OOYFGAHT@nvidia.com>
Date: Wed, 22 Oct 2025 15:47:30 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Joel Fernandes" <joelagnelf@...dia.com>,
<linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>,
<dri-devel@...ts.freedesktop.org>, <dakr@...nel.org>, <acourbot@...dia.com>
Cc: "Alistair Popple" <apopple@...dia.com>, "Miguel Ojeda"
<ojeda@...nel.org>, "Alex Gaynor" <alex.gaynor@...il.com>, "Boqun Feng"
<boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>,
<bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Andreas
Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>,
"Trevor Gross" <tmgross@...ch.edu>, "David Airlie" <airlied@...il.com>,
"Simona Vetter" <simona@...ll.ch>, "Maarten Lankhorst"
<maarten.lankhorst@...ux.intel.com>, "Maxime Ripard" <mripard@...nel.org>,
"Thomas Zimmermann" <tzimmermann@...e.de>, "John Hubbard"
<jhubbard@...dia.com>, "Timur Tabi" <ttabi@...dia.com>,
<joel@...lfernandes.org>, "Elle Rhumsaa" <elle@...thered-steel.dev>,
"Daniel Almeida" <daniel.almeida@...labora.com>,
<nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH 5/7] gpu: nova-core: Add support for managing GSP falcon
interrupts
On Tue Oct 21, 2025 at 3:55 AM JST, Joel Fernandes wrote:
> Add support for managing GSP falcon interrupts. These are required for
> GSP message queue interrupt handling.
>
> Also rename clear_swgen0_intr() to enable_msq_interrupt() for
> readability.
Let's make this "also" its own patch as it is a different thing.
>
> Signed-off-by: Joel Fernandes <joelagnelf@...dia.com>
> ---
> drivers/gpu/nova-core/falcon/gsp.rs | 26 +++++++++++++++++++++++---
> drivers/gpu/nova-core/gpu.rs | 2 +-
> drivers/gpu/nova-core/regs.rs | 10 ++++++++++
> 3 files changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/falcon/gsp.rs b/drivers/gpu/nova-core/falcon/gsp.rs
> index f17599cb49fa..6da63823996b 100644
> --- a/drivers/gpu/nova-core/falcon/gsp.rs
> +++ b/drivers/gpu/nova-core/falcon/gsp.rs
> @@ -22,11 +22,31 @@ impl FalconEngine for Gsp {
> }
>
> impl Falcon<Gsp> {
> - /// Clears the SWGEN0 bit in the Falcon's IRQ status clear register to
> - /// allow GSP to signal CPU for processing new messages in message queue.
> - pub(crate) fn clear_swgen0_intr(&self, bar: &Bar0) {
> + /// Enable the GSP Falcon message queue interrupt (SWGEN0 interrupt).
> + #[expect(dead_code)]
> + pub(crate) fn enable_msgq_interrupt(&self, bar: &Bar0) {
> + regs::NV_PFALCON_FALCON_IRQMASK::alter(bar, &Gsp::ID, |r| r.set_swgen0(true));
> + }
> +
> + /// Check if the message queue interrupt is pending.
> + #[expect(dead_code)]
> + pub(crate) fn has_msgq_interrupt(&self, bar: &Bar0) -> bool {
> + regs::NV_PFALCON_FALCON_IRQSTAT::read(bar, &Gsp::ID).swgen0()
> + }
> +
> + /// Clears the message queue interrupt to allow GSP to signal CPU
> + /// for processing new messages.
> + pub(crate) fn clear_msgq_interrupt(&self, bar: &Bar0) {
> regs::NV_PFALCON_FALCON_IRQSCLR::default()
> .set_swgen0(true)
> .write(bar, &Gsp::ID);
> }
> +
> + /// Acknowledge all pending GSP interrupts.
> + #[expect(dead_code)]
> + pub(crate) fn ack_all_interrupts(&self, bar: &Bar0) {
> + // Read status and write the raw value to IRQSCLR to clear all pending interrupts.
> + let status = regs::NV_PFALCON_FALCON_IRQSTAT::read(bar, &Gsp::ID);
> + regs::NV_PFALCON_FALCON_IRQSCLR::from(u32::from(status)).write(bar, &Gsp::ID);
> + }
I think this can be a bit more generic than that: all interrupts for all
falcons are handled the same way, so we shouldn't need to write
`enable`, `clear`, and other methods for each.
So the first step should probably be a generic `impl<E> Falcon<E>` block
that provides base methods for specialized blocks to reuse. It could
work with just the index of the bit corresponding to the interrupt to
enable/clear, but if we want to involve the type system we could also
define a `FalconInterrupt` trait with an associated type for the engine
on which this interrupt is valid, and its bit index as an associated
const.
But I suspect that the set of interrupts is going to be pretty standard,
so maybe we can use the standard nomenclature for the generic methods
(i.e. SWGEN0), and have dedicated methods for specialized units where
relevant.
Powered by blists - more mailing lists