On Fri Oct 9, 2026 at 2:53 PM CEST, Jason Gunthorpe wrote:
> 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?
Actually only the last line, I just "couldn't help myself" to also include
the "Couldn't update frequency transition information" part.
It can be unrelated. Or not. I lack the knowledge to make that determination.
>> [ 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]
IIUC this was meant to show the actual problem.
> 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.
I can't say anything useful wrt this, so I added the maintainers of
``drivers/gpu/drm/rockchip/rockchip_drm_gem.c`` to the recipient list.
> 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);
It may not matter, but I noticed the majority of that function is from 2016:
38f993b7c59e ("drm/rockchip: Do not use DMA mapping API if attached to IOMMU
domain")
1aa5ca6e3ec6 ("drm/rockchip: Use common IOMMU API to attach devices")
>From the first commit (38f993b7c59e):
The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.
This patch should not introduce any functional changes until the driver
is made to attach subdevices into an IOMMU domain with the generic IOMMU
API, which will happen in following patch. Based heavily on GEM
implementation of Tegra DRM driver.
And I assume "following patch" was 1aa5ca6e3ec6.
Cheers,
Diederik
