On Wed, Oct 07, 2026 at 02:02:31PM +0200, Diederik de Haas wrote:
[ 1091.981354] rc rc3: two consecutive events of type space [ 1104.670513] input: EDIFIER e235 (AVRCP) as /devices/virtual/input/input12 [ 1172.090231] devfreq fb000000.gpu: Couldn't update frequency transition information. [ 1189.403278] devfreq fb000000.gpu: Couldn't update frequency transition information. [ 1206.309295] input: EDIFIER e235 (AVRCP) as /devices/virtual/input/input13 [ 1268.968696] DMA-BUF: importer used the CPU side of an exporter's sg_table
This is a nice stack trace, is that the point of this series?
[ 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.
static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj) { [..] ret = iommu_map_sgtable(private->domain, rk_obj->dma_addr, rk_obj->sgt, prot);
Jason