Set the correct DMA mask. Without this DMA will fail on some setups.

Signed-off-by: Alistair Popple <apopple@nvidia.com>

---

Changes for v2:

 - Update DMA mask to correct value for Ampere/Turing (47 bits)
---
 drivers/gpu/nova-core/driver.rs | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
index 1380b47617f7..ccc97340206e 100644
--- a/drivers/gpu/nova-core/driver.rs
+++ b/drivers/gpu/nova-core/driver.rs
@@ -1,6 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 
-use kernel::{auxiliary, bindings, c_str, device::Core, pci, prelude::*, sizes::SZ_16M, sync::Arc};
+use kernel::{
+    auxiliary, bindings, c_str, device::Core, dma::Device, dma::DmaMask, pci, prelude::*,
+    sizes::SZ_16M, sync::Arc,
+};
 
 use crate::gpu::Gpu;
 
@@ -34,6 +37,9 @@ fn probe(pdev: &pci::Device<Core>, _info: &Self::IdInfo) -> Result<Pin<KBox<Self
         pdev.enable_device_mem()?;
         pdev.set_master();
 
+        // SAFETY: No DMA allocations have been made yet
+        unsafe { pdev.dma_set_mask_and_coherent(DmaMask::new::<47>())? };
+
         let devres_bar = Arc::pin_init(
             pdev.iomap_region_sized::<BAR0_SIZE>(0, c_str!("nova-core/bar0")),
             GFP_KERNEL,
-- 
2.50.1

On 9/30/25 3:16 PM, Alistair Popple wrote:
> +        // SAFETY: No DMA allocations have been made yet
> +        unsafe { pdev.dma_set_mask_and_coherent(DmaMask::new::<47>())? };

I think you forgot to derive the value from the relevant sources, i.e. physical
bus, DMA controller and MMU capabilities.

I assume not all GPU architectures / generations have the exact same capabilities?

On 2025-09-30 at 23:29 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On 9/30/25 3:16 PM, Alistair Popple wrote:
> > +        // SAFETY: No DMA allocations have been made yet
> > +        unsafe { pdev.dma_set_mask_and_coherent(DmaMask::new::<47>())? };
> 
> I think you forgot to derive the value from the relevant sources, i.e. physical
> bus, DMA controller and MMU capabilities.
> 
> I assume not all GPU architectures / generations have the exact same capabilities?

Right. Long term we need a HAL for this, and I believe John was going to look
at that. In the short term everything we care about supports the same 47-bit
address width. And when I say "everything" I mean Turing and Ampere, although
I'm pretty sure 47-bits goes back to at least Pascal.

Newer GPU architectures (Hopper+) support greater widths (52-bits), but there's
no real impact to constraining these for now until a proper HAL is in place.

And that sounds like an excellent addition that I should make to the commit
logs and/or the comment on the constant definition, which fell off my radar when
reworking the rest of this series but will fix for v4.

On 9/30/25 6:42 PM, Alistair Popple wrote:
> On 2025-09-30 at 23:29 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
>> On 9/30/25 3:16 PM, Alistair Popple wrote:
>>> +        // SAFETY: No DMA allocations have been made yet
>>> +        unsafe { pdev.dma_set_mask_and_coherent(DmaMask::new::<47>())? };
>>
>> I think you forgot to derive the value from the relevant sources, i.e. physical
>> bus, DMA controller and MMU capabilities.
>>
>> I assume not all GPU architectures / generations have the exact same capabilities?
> 
> Right. Long term we need a HAL for this, and I believe John was going to look
> at that. In the short term everything we care about supports the same 47-bit

Yes. This will arrive with the Hopper/Blackwell support patchset.

> address width. And when I say "everything" I mean Turing and Ampere, although
> I'm pretty sure 47-bits goes back to at least Pascal.
> 
> Newer GPU architectures (Hopper+) support greater widths (52-bits), but there's
> no real impact to constraining these for now until a proper HAL is in place.

Yes. The "soul" of these various patchsets so far is, "get GSP responsive
for Ampere/Ada". To that end, it's OK to temporarily act as if the only
thing that matters in this driver is Ampere/Ada. :)

> 
> And that sounds like an excellent addition that I should make to the commit
> logs and/or the comment on the constant definition, which fell off my radar when
> reworking the rest of this series but will fix for v4.

thanks,
-- 
John Hubbard