On Fri, Oct 09, 2026 at 03:21:47PM +0200, Christian König wrote:
[ 1268.968710] CPU: 6 UID: 1000 PID: 29025 Comm: sway Not tainted 7.3-rc6+unreleased-arm64-cknow #1 PREEMPTLAZY Debian 7.3~rc6-3 [ 1268.968715] Hardware name: FriendlyElec NanoPC-T6 Plus (DT) [ 1268.968717] Call trace: [ 1268.968719] show_stack+0x20/0x38 (C) [ 1268.968726] dump_stack_lvl+0x60/0x80 [ 1268.968730] sg_dmabuf_cpu_access_warn.part.0+0x24/0x30 [ 1268.968734] sg_dmabuf_cpu_access_warn+0x34/0x38 [ 1268.968739] iommu_map_sg+0xc8/0x1e0 [ 1268.968745] rockchip_gem_iommu_map+0x8c/0x128 [rockchipdrm] [ 1268.968757] rockchip_gem_prime_import_sg_table+0x58/0x160 [rockchipdrm] [ 1268.968761] drm_gem_prime_import_dev+0xa8/0x1d0 [drm] [ 1268.968776] drm_gem_prime_fd_to_handle+0x1a4/0x280 [drm]
So.. This is the exact same thing I need for iommufd.
rockchip is managing its own iommu domain and you cannot map to an iommu domain without using a physical address.
Of course it is *completely* illegal to call iommu_map_sgtable() in the importer side of a dmabuf.
Yeah we are deprecating this for the last ~5 years now. This bubbled up because I change to DMA-buf debug code to be enabled by default on DEBUG_KERNEL.
Rob is now working on a solution right now for MSM which should be used for rockchip as well.
So is Rob's plan is to remove the iommu_domains, somehow? Lately we've been NAK'ing alot of the DT hacking that people have been doing in other devices along those lines, so I wonder what that will look like.
It is probably easier to just fix things so the importer can get things into an iommu_domain..
Jason