On Tue, Apr 22, 2025 at 11:25:40AM -0500, Arnd Bergmann wrote: > On Tue, Apr 22, 2025, at 10:56, Ben Collins wrote: > > On Tue, Apr 22, 2025 at 09:59:42AM -0500, Arnd Bergmann wrote: > >> > >> Right, but this could just mean that they end up using SWIOTLB > >> to bounce the high DMA pages or use an IOMMU rather than actually > >> translating the physical address to a dma address. > > > > There's a few things going on. The Local Address Window can shift > > anywhere in the 64-bit address space and be as wide as the physical > > address (40-bit on T4240, 36-bit on P4080). I think this is mainly for > > IO to PCIe and RapidIO, though. > > There are usually two sets of registers, not sure which one the Local > Address Window refers to: > > - Translation of MMIO addresses (PCI BAR and device registers) when > accessed from CPU and possibly from P2P DMA, these are represented > by the 'ranges' property in DT. > > - Translation of physical memory when accessed from a DMA bus master, > represented by the 'dma-ranges' property. > > The latter is what the dma-mapping API needs. This code has changed > a lot over the years, but in the current version the idea is that > the limit enforced by the driver through dma_set_mask() is independent > of the limit enforced by the platform bus based on the dma-ranges > property.
LAWs translate physical addresses to IOVA (PCIe/RapidIO/SoC resources) and are used for all master level translations (CPU, DMA, PCIe, DDR, RapidIO). This is at the interconnect level. I believe LAWs cover both of these cases. > >> > I'll check on this, but I think it's a seperate issue. The main thing is > >> > just to configure the dma hw correctly. > >> > >> I think it's still important to check this before changing the > >> driver: if the larger mask doesn't actually have any effect now > >> because the DT caps the DMA at 4GB, then it might break later > >> when someone adds the correct dma-ranges properties. > > > > I'm adding dma-ranges to my dt for testing. > > Ok. The other thing you can try is to printk() the dev->bus_dma_limit > to see if it even tries to use >32bit addressing. Did that. Every combination of IOMMU on/off and dma-ranges in my dt always showed bus_dma_limit as 0x0. As an aside, if you could give this a quick check, I can send the revised patch. Appreciate the feedback. https://github.com/benmcollins/linux/commit/2f2946b33294ebff2fdaae6d1eadc976147470d6 -- Ben Collins https://libjwt.io https://github.com/benmcollins -- 3EC9 7598 1672 961A 1139 173A 5D5A 57C7 242B 22CF
signature.asc
Description: PGP signature
