06:27 <mwalle> robmur01: with your "iommu: Get DT/ACPI parsing into the proper probe path" I'm getting the following warning https://pastebin.com/raw/p3rPepQ9 do you have some idea what could be wrong there?

06:28 <mwalle> robmur01: https://oftc.catirclogs.org/etnaviv/2025-07-01 might be relevant

09:17 <robmur01> mwalle: what's wrong is that that is exactly the kind of sketchy thing that drivers should not be doing.

09:17 <robmur01> if the DT doesn't describe the DMA paths correctly, fix the DT. If the DT is correct, fix... whatever the heck the driver thinks it's trying to achieve there

09:29 <robmur01> For background: IOMMU configuration cannot depend on client drivers being present - the warning is a precursor to that late "replay" path going away entirely

09:56 <arnd> That "Black Sesame" SoC sounds fun: according to the discussion on the sdhci driver patch, RAM starts at address 0x800000000 (32GB) but the DMA master they use can only access the first 4GB.

10:09 <ukleinek> fsdo "fun"

10:43 <robmur01> Well, at least arm64 supports that since Marvell already did similar :)

10:44 <arnd> robmur01: how does arm64 support that? Do you mean just booting from an address above 4GB, or is there some trick that also makes DMA masters work without an IOMMU?

10:46 <robmur01> assuming a hard-wired DMA offset, we shift ZONE_DMA{32} to be relative to the start of RAM rather than the absolute physical address, if that's above 4GB

10:48 <robmur01> however I see neither iommus nor dma-ranges in that DT, so I guess it just can't do DMA?

10:52 <arnd> I don't think they have an offset, since they route the DMA through an SRAM in the low 4GB physical address space

10:54 <arnd> I suspect the 'dma-coherent' flag is also wrong or misleading, as the device is only coherent with the (uncached) sram but not with the RAM it cannot access.

10:55 <arnd> it's probably needed to skip the cache flushes on the SRAM, but I feel that makes the hack even worse

10:56 <robmur01> Either the device can snoop CPU caches or it can't, that's my notion of dma-coherent correctness

10:57 <robmur01> And indeed DMA-addressable SRAM could be used as a restricted-dma-pool to force SWIOTLB to map through it, but it would then be mapped cacheable by the CPUs

11:00 <robmur01> (we don't do non-cacheable SWIOTLB even for non-coherent devices - it's been tried and the performance is hideous compared to explicit cache maintenance)

11:06 <robmur01> ...urgh, now I see. I forgot the MMC layer still had its own bounce_buffer mechanism :(

12:42 <arnd> robmur01: yes, that confused me as well. AFAICT the MMC bounce buffer mechanism is only used on devices that lack scatter-gather transfers, and that is a reasonable optimization because writing noncontigous pages is common in many file systems but splitting up each transfer into single pages would destroy cheap SD cards very quickly through wear leveling

12:42 <arnd> using the bouce buffer to get around broken DMA support in the SDHCI is a completely different thing