Re: [PATCH v2 01/10] gpu: nova-core: Set correct DMA mask

["Danilo Krummrich" <dakr@kernel.org>]

On Tue Sep 23, 2025 at 6:29 AM CEST, Alistair Popple wrote:
> On 2025-09-23 at 12:16 +1000, John Hubbard <jhubbard@nvidia.com> wrote...
>> On 9/22/25 9:08 AM, Danilo Krummrich wrote:
>> > On 9/22/25 1:30 PM, Alistair Popple wrote:
>> >> +        // SAFETY: No DMA allocations have been made yet
>> > 
>> > It's not really about DMA allocations that have been made previously, there is
>> > no unsafe behavior in that.
>> > 
>> > It's about the method must not be called concurrently with any DMA allocation or
>> > mapping primitives.
>> > 
>> > Can you please adjust the comment correspondingly?
>
> Sure.
>
>> >> +        unsafe { pdev.dma_set_mask_and_coherent(DmaMask::new::<47>())? };
>> > 
>> > As Boqun mentioned, we shouldn't have a magic number for this. I don't know if
>> > it will change for future chips, but maybe we should move this to gpu::Spec to
>> 
>> It changes to 52 bits for GH100+ (Hopper/Blackwell+). When I post those
>> patches, I'll use a HAL to select the value.
>> 
>> > be safe.
>> > 
>> > At least, create a constant for it (also in gpu::Spec?); in Nouveau I named this
>> > NOUVEAU_VA_SPACE_BITS back then. Not a great name, if you have a better idea,
>> > please go for it. :)
>
> Well it's certainly not the VA_SPACE width ... that's a different address space :-)

I mean, sure. But isn't the limitation of 47 bits coming from the MMU and hence
defines the VA space width and the DMA bit width we can support?

> I thought from the context that the magic number was pretty obviously the
> supported DMA address width in bits, especially given the extra decoration
> of the DmaMask type. Certainly that's been the accepted practice for the rest
> of the kernel where pretty much all drivers just use something of the form
> dma_set_mask(drm_dev->dev, DMA_BIT_MASK(44)) or whatever DMA address widths
> they support.
>
>> GPU_DMA_BIT_WIDTH, for now?
>
> Works for me.
>
>> thanks,
>> -- 
>> John Hubbard
>>