Diederik reported failed video-buffer imports on RK3588 with DMABUF_DEBUG. The proposed warn-only mode [1] confirmed CPU-side attachment access in rockchip_gem_iommu_map() during Sway video resizing.
This RFC keeps Rockchip's private scanout domain. Patch 1 copies live iommu-dma mappings into another domain. Patch 2 uses it for PRIME imports. Unsupported inputs keep the old page-based path, which remains unfixed under strict DMABUF_DEBUG. Rob's MSM approach assumes direct DMA [2]. Rockchip's attachment instead provides IOVAs from the VOP's default domain, which cannot be mapped unchanged into the private domain. Each import retains both mappings and adds one reverse lookup per 4 KiB. Christian rejected reverse translation in the earlier MSM proposal [3]. Robin NAKed exporting iommu_get_dma_domain() [4]. Keeping the helper in dma-iommu.c does not resolve the physical-address objection. Sharing the first VOP's default DMA domain, as Exynos does, would avoid the translation but also change native-buffer mapping. Is retaining the private domain and reverse-translating the DMA mappings an acceptable direction? If so, I'll address the remaining limitations before posting a non-RFC version. Base: mainline 602042bf29f6. The warn-only RFC is not a prerequisite. No stable backport requested. Strict-by-default DMABUF_DEBUG took effect in v7.3-rc4. Testing (builds and QEMU only): - W=1 object and stub builds passed on arm64, ARM32 with/without LPAE, x86-64 GCC/Clang, i386, s390, RISC-V and UML, including dynamic SWIOTLB. - Rockchip strict/warn A/B reproduced the control failure and warning. Treatments checked every page and byte in 83 imports each. Primary buffers had 1/127/507 DMA segments under the default 64 KiB limit. - SMMUv3 strict/lazy tests, missing-source, bounds and rollback tests passed. Real bounced attachments exercised alignment and pool rejection with no target mapping or DMA. - Invalid forced-SWIOTLB Rockchip provider runs are excluded. Expected segment-limit and unsupported-fallback diagnostics remain. The rig uses a custom Rockchip IOMMU model and the real GEM callback in a test module, not VOP2, Sway or a real exporter. RK3588 hardware, two-VOP and 32-bit ARM runtime testing are outstanding. Hardware testing is welcome, particularly with Diederik's Sway resize workload. Compare control and both patches on the same base/config, first with strict DMABUF_DEBUG, then with the warn-only RFC on both. Please report full dmesg, config, exporter and visible display problems. Keep a known-good boot kernel. DMABUF_DEBUG=n testing is welcome too. Developed and tested with LLM assistance. [1] https://lore.kernel.org/r/[email protected]/ [2] https://lore.kernel.org/r/[email protected]/ [3] https://lore.kernel.org/r/[email protected]/ [4] https://lore.kernel.org/r/[email protected]/ Reports: https://lore.kernel.org/r/[email protected]/ https://lore.kernel.org/r/[email protected]/ Karl Mehltretter (2): iommu: Add iommu_map_sgtable_dma() drm/rockchip: Map imported buffers from DMA addresses drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19 ++- drivers/iommu/dma-iommu.c | 131 ++++++++++++++++++++ include/linux/iommu.h | 12 ++ 3 files changed, 157 insertions(+), 5 deletions(-) base-commit: 602042bf29f6efde39cfb5fdd9289bf4854bc0c5 -- 2.53.0
