[PATCH v1] drm/rockchip: Set VOP for the DRM DMA device

[PATCH v1] drm/rockchip: Set VOP for the DRM DMA device

[Dmitry Osipenko]

Use VOP for DMA operations performed by DRM core. Rockchip DRM driver
is backed by a virtual device that isn't IOMMU-capable, while VOP is the
actual display controller device backed by IOMMU. Fixes "swiotlb buffer
is full" warning messages originated from GEM prime code paths.

Note, that backporting is non-trivial as this depends on 143ec8d3f9396
("drm/prime: Support dedicated DMA device for dma-buf imports"), which
landed in v6.16 and 421be3ee36a4 ("drm/rockchip: Refactor IOMMU
initialisation"), which landed in v5.19.

Reported-by: Daniel Stone <daniels@collabora.com>
Fixes: 2048e3286f34 ("drm: rockchip: Add basic drm driver")
Cc: stable@vger.kernel.org # v6.16+
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index eb77bde9f628..e693160e9b7f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -96,6 +96,9 @@ void rockchip_drm_dma_init_device(struct drm_device *drm_dev,
 		private->iommu_dev = ERR_PTR(-ENODEV);
 	else if (!private->iommu_dev)
 		private->iommu_dev = dev;
+
+	if (!IS_ERR(private->iommu_dev))
+		drm_dev_set_dma_dev(drm_dev, private->iommu_dev);
 }
 
 static int rockchip_drm_init_iommu(struct drm_device *drm_dev)
-- 
2.51.0

Re: [PATCH v1] drm/rockchip: Set VOP for the DRM DMA device

[Heiko Stuebner]

Hi Dmitry,

Am Mittwoch, 22. Oktober 2025, 18:19:48 Mitteleuropäische Sommerzeit schrieb Dmitry Osipenko:
> Use VOP for DMA operations performed by DRM core. Rockchip DRM driver
> is backed by a virtual device that isn't IOMMU-capable, while VOP is the
> actual display controller device backed by IOMMU. Fixes "swiotlb buffer
> is full" warning messages originated from GEM prime code paths.
> 
> Note, that backporting is non-trivial as this depends on 143ec8d3f9396
> ("drm/prime: Support dedicated DMA device for dma-buf imports"), which
> landed in v6.16 and 421be3ee36a4 ("drm/rockchip: Refactor IOMMU
> initialisation"), which landed in v5.19.
> 
> Reported-by: Daniel Stone <daniels@collabora.com>
> Fixes: 2048e3286f34 ("drm: rockchip: Add basic drm driver")
> Cc: stable@vger.kernel.org # v6.16+
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>

just a process remark for now. This v1 so it definitly shouldn't come
with any Reviewed-by-s pre-applied, because this should happen in public.

It's not a huge issue here, because I do trust the people involved (you,
Sebastian, Daniel) and the change is small enough, but please for future
changes, let Review happen on the list, not on private channels.


Will look at the change itself when back home.


Thanks
Heiko

Re: [PATCH v1] drm/rockchip: Set VOP for the DRM DMA device

[Dmitry Osipenko]

On 10/23/25 09:56, Heiko Stuebner wrote:
> Hi Dmitry,
> 
> Am Mittwoch, 22. Oktober 2025, 18:19:48 Mitteleuropäische Sommerzeit schrieb Dmitry Osipenko:
>> Use VOP for DMA operations performed by DRM core. Rockchip DRM driver
>> is backed by a virtual device that isn't IOMMU-capable, while VOP is the
>> actual display controller device backed by IOMMU. Fixes "swiotlb buffer
>> is full" warning messages originated from GEM prime code paths.
>>
>> Note, that backporting is non-trivial as this depends on 143ec8d3f9396
>> ("drm/prime: Support dedicated DMA device for dma-buf imports"), which
>> landed in v6.16 and 421be3ee36a4 ("drm/rockchip: Refactor IOMMU
>> initialisation"), which landed in v5.19.
>>
>> Reported-by: Daniel Stone <daniels@collabora.com>
>> Fixes: 2048e3286f34 ("drm: rockchip: Add basic drm driver")
>> Cc: stable@vger.kernel.org # v6.16+
>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> 
> just a process remark for now. This v1 so it definitly shouldn't come
> with any Reviewed-by-s pre-applied, because this should happen in public.
> 
> It's not a huge issue here, because I do trust the people involved (you,
> Sebastian, Daniel) and the change is small enough, but please for future
> changes, let Review happen on the list, not on private channels.
> 
> 
> Will look at the change itself when back home.

Thanks. I also felt uncomfortable adding r-b to v1. There was no much
discussion on the change that you can find on [1] and the change is
indeed small, so I just added the r-b. Should've linked it the patch.

[1]
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/issues/50

-- 
Best regards,
Dmitry

Re: [PATCH v1] drm/rockchip: Set VOP for the DRM DMA device

[Cristian Ciocaltea]

On 10/22/25 7:19 PM, Dmitry Osipenko wrote:
> Use VOP for DMA operations performed by DRM core. Rockchip DRM driver
> is backed by a virtual device that isn't IOMMU-capable, while VOP is the
> actual display controller device backed by IOMMU. Fixes "swiotlb buffer
> is full" warning messages originated from GEM prime code paths.
> 
> Note, that backporting is non-trivial as this depends on 143ec8d3f9396
> ("drm/prime: Support dedicated DMA device for dma-buf imports"), which
> landed in v6.16 and 421be3ee36a4 ("drm/rockchip: Refactor IOMMU
> initialisation"), which landed in v5.19.
> 
> Reported-by: Daniel Stone <daniels@collabora.com>
> Fixes: 2048e3286f34 ("drm: rockchip: Add basic drm driver")
> Cc: stable@vger.kernel.org # v6.16+
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> ---

With the patch applied I'm not able to fire those warnings anymore - tested on
my ROCK 5B (RK3588) and ROCK 4D (RK3576) boards.  Hence you may add:

Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Re: [PATCH v1] drm/rockchip: Set VOP for the DRM DMA device

[Dmitry Osipenko]

On 10/23/25 11:42, Cristian Ciocaltea wrote:
> On 10/22/25 7:19 PM, Dmitry Osipenko wrote:
>> Use VOP for DMA operations performed by DRM core. Rockchip DRM driver
>> is backed by a virtual device that isn't IOMMU-capable, while VOP is the
>> actual display controller device backed by IOMMU. Fixes "swiotlb buffer
>> is full" warning messages originated from GEM prime code paths.
>>
>> Note, that backporting is non-trivial as this depends on 143ec8d3f9396
>> ("drm/prime: Support dedicated DMA device for dma-buf imports"), which
>> landed in v6.16 and 421be3ee36a4 ("drm/rockchip: Refactor IOMMU
>> initialisation"), which landed in v5.19.
>>
>> Reported-by: Daniel Stone <daniels@collabora.com>
>> Fixes: 2048e3286f34 ("drm: rockchip: Add basic drm driver")
>> Cc: stable@vger.kernel.org # v6.16+
>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>> ---
> 
> With the patch applied I'm not able to fire those warnings anymore - tested on
> my ROCK 5B (RK3588) and ROCK 4D (RK3576) boards.  Hence you may add:
> 
> Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

More testing is good, thanks.

Forgot to mention I'm myself tested on 5b/3588 and 4c/3399.

-- 
Best regards,
Dmitry

Re: [PATCH v1] drm/rockchip: Set VOP for the DRM DMA device

[Heiko Stuebner]

On Wed, 22 Oct 2025 19:19:48 +0300, Dmitry Osipenko wrote:
> Use VOP for DMA operations performed by DRM core. Rockchip DRM driver
> is backed by a virtual device that isn't IOMMU-capable, while VOP is the
> actual display controller device backed by IOMMU. Fixes "swiotlb buffer
> is full" warning messages originated from GEM prime code paths.
> 
> Note, that backporting is non-trivial as this depends on 143ec8d3f9396
> ("drm/prime: Support dedicated DMA device for dma-buf imports"), which
> landed in v6.16 and 421be3ee36a4 ("drm/rockchip: Refactor IOMMU
> initialisation"), which landed in v5.19.
> 
> [...]

Applied, thanks!

[1/1] drm/rockchip: Set VOP for the DRM DMA device
      commit: 7d7bb790aced3b1b8550b74e02fdfc001d044bee

Best regards,
-- 
Heiko Stuebner <heiko@sntech.de>