On Tue Sep 23, 2025 at 6:29 AM CEST, Alistair Popple wrote: > On 2025-09-23 at 12:16 +1000, John Hubbard <[email protected]> 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 >>
