On Thu Dec 18, 2025 at 12:29 PM JST, Timur Tabi wrote: > Some GPUs do not support using DMA to transfer code/data from system > memory to Falcon memory, and instead must use programmed I/O (PIO). > Add a function to the Falcon HAL to indicate whether a given GPU's > Falcons support DMA for this purpose. > > Signed-off-by: Timur Tabi <[email protected]> > --- > drivers/gpu/nova-core/falcon.rs | 7 +++++++ > drivers/gpu/nova-core/falcon/hal.rs | 3 +++ > drivers/gpu/nova-core/falcon/hal/ga102.rs | 4 ++++ > drivers/gpu/nova-core/falcon/hal/tu102.rs | 4 ++++ > 4 files changed, 18 insertions(+) > > diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs > index 6b54c0ca458a..50c87dadf2ea 100644 > --- a/drivers/gpu/nova-core/falcon.rs > +++ b/drivers/gpu/nova-core/falcon.rs > @@ -630,6 +630,13 @@ pub(crate) fn is_riscv_active(&self, bar: &Bar0) -> bool > { > self.hal.is_riscv_active(bar) > } > > + /// Check if this Falcon supports DMA for loading firmware. > + /// > + /// Returns `true` if DMA is supported, `false` if PIO must be used > instead. > + pub(crate) fn supports_dma(&self) -> bool { > + self.hal.supports_dma() > + }
Rather than this, we should make the selection of the loading method transparent to the caller. Right now `boot.rs` needs to calls `supports_dma` itself and choose the right method, which leaves room for error. I'd suggest the following: - A `fn load(bar, fw) -> Result` method in the Falcon HAL that redirects to either `load_dma` or `load_pio`. - A similarly-named public function in `Falcon` for the boot code to call, - `load_dma` and `load_pio` becomes private - that way the HAL can call them, but not the user code. Now we have the problem that the generic bootloader argument is only useful for PIO, but the way it is handled is a bit too ad-hoc to my taste. I wonder if we could pass a different `FalconFirmware` structure when it is used so the same code can do the correct thing.
