From: Joel Fernandes <joelagnelf@nvidia.com>

Add definition for RISCV_CPUCTL register and use it in a new falcon API
to check if the RISC-V core of a Falcon is active. It is required by
the sequencer to know if the GSP's RISCV processor is active.

Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
---
 drivers/gpu/nova-core/falcon.rs | 9 +++++++++
 drivers/gpu/nova-core/regs.rs   | 5 +++++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
index 37e6298195e4..c7907f16bcf4 100644
--- a/drivers/gpu/nova-core/falcon.rs
+++ b/drivers/gpu/nova-core/falcon.rs
@@ -610,4 +610,13 @@ pub(crate) fn signature_reg_fuse_version(
         self.hal
             .signature_reg_fuse_version(self, bar, engine_id_mask, ucode_id)
     }
+
+    /// Check if the RISC-V core is active.
+    ///
+    /// Returns `true` if the RISC-V core is active, `false` otherwise.
+    #[expect(unused)]
+    pub(crate) fn is_riscv_active(&self, bar: &Bar0) -> Result<bool> {
+        let cpuctl = regs::NV_PRISCV_RISCV_CPUCTL::read(bar, &E::ID);
+        Ok(cpuctl.active_stat())
+    }
 }
diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
index 0585699ae951..5df6a2bf42ad 100644
--- a/drivers/gpu/nova-core/regs.rs
+++ b/drivers/gpu/nova-core/regs.rs
@@ -324,6 +324,11 @@ pub(crate) fn mem_scrubbing_done(self) -> bool {
 
 // PRISCV
 
+register!(NV_PRISCV_RISCV_CPUCTL @ PFalconBase[0x00001388] {
+    7:7     active_stat as bool;
+    0:0     halted as bool;
+});
+
 register!(NV_PRISCV_RISCV_BCR_CTRL @ PFalconBase[0x00001668] {
     0:0     valid as bool;
     4:4     core_select as bool => PeregrineCoreSelect;
-- 
2.50.1

On Mon, 2025-09-22 at 21:30 +1000, Alistair Popple wrote:
> +
> +    /// Check if the RISC-V core is active.
> +    ///
> +    /// Returns `true` if the RISC-V core is active, `false` otherwise.
> +    #[expect(unused)]
> +    pub(crate) fn is_riscv_active(&self, bar: &Bar0) -> Result<bool> {
> +        let cpuctl = regs::NV_PRISCV_RISCV_CPUCTL::read(bar, &E::ID);
> +        Ok(cpuctl.active_stat())
> +    }

This should be part of the HAL, because a different register is used on Turing.

You can leave it here if you want, and I'll move into a HAL when I post Turing support.  Your
choice.

On 9/22/25 12:12 PM, Timur Tabi wrote:
> On Mon, 2025-09-22 at 21:30 +1000, Alistair Popple wrote:
>> +
>> +    /// Check if the RISC-V core is active.
>> +    ///
>> +    /// Returns `true` if the RISC-V core is active, `false` otherwise.
>> +    #[expect(unused)]
>> +    pub(crate) fn is_riscv_active(&self, bar: &Bar0) -> Result<bool> {
>> +        let cpuctl = regs::NV_PRISCV_RISCV_CPUCTL::read(bar, &E::ID);
>> +        Ok(cpuctl.active_stat())
>> +    }
> 
> This should be part of the HAL, because a different register is used on Turing.
> 
> You can leave it here if you want, and I'll move into a HAL when I post Turing support.  Your
> choice.

Yes, it's similar to the DMA mask patch in that regard (Hopper/Blackwell needs
a different value).

In the spirit of the current "soul" of patchsets, which is "get
GPU firmware running on Ampere/Ada"), I think let's defer the HALs
until the first patchset that needs them.

thanks,
-- 
John Hubbard

On 2025-09-23 at 11:07 +1000, John Hubbard <jhubbard@nvidia.com> wrote...
> On 9/22/25 12:12 PM, Timur Tabi wrote:
> > On Mon, 2025-09-22 at 21:30 +1000, Alistair Popple wrote:
> >> +
> >> +    /// Check if the RISC-V core is active.
> >> +    ///
> >> +    /// Returns `true` if the RISC-V core is active, `false` otherwise.
> >> +    #[expect(unused)]
> >> +    pub(crate) fn is_riscv_active(&self, bar: &Bar0) -> Result<bool> {
> >> +        let cpuctl = regs::NV_PRISCV_RISCV_CPUCTL::read(bar, &E::ID);
> >> +        Ok(cpuctl.active_stat())
> >> +    }
> > 
> > This should be part of the HAL, because a different register is used on Turing.
> > 
> > You can leave it here if you want, and I'll move into a HAL when I post Turing support.  Your
> > choice.
> 
> Yes, it's similar to the DMA mask patch in that regard (Hopper/Blackwell needs
> a different value).
> 
> In the spirit of the current "soul" of patchsets, which is "get
> GPU firmware running on Ampere/Ada"), I think let's defer the HALs
> until the first patchset that needs them.

Agreed, lets fix that when we add/need the HALs as that's outside the scope of
what this patch series is trying to achieve.

> thanks,
> -- 
> John Hubbard
> 

On Mon, 2025-09-22 at 18:07 -0700, John Hubbard wrote:
> In the spirit of the current "soul" of patchsets, which is "get
> GPU firmware running on Ampere/Ada"), I think let's defer the HALs
> until the first patchset that needs them.

Fair enough, but maybe this patchset should make it clear that it uses Ampere-specific
registers?  All of the patches have descriptions that imply that they support all GSP-capable
GPUs.