Re: [PATCH] fsldma: Support 40 bit DMA addresses where capable

[Ben Collins <bcollins@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2629 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]