Re: [PATCH v2 1/4] drm/rcar-du: Use drm_gem_dma_get_sg_table() helper to get scatter gather table

On Thu, Mar 19, 2026 at 12:21:49AM +0800, Chen-Yu Tsai wrote:

On Thu, Mar 19, 2026 at 12:02 AM Laurent Pinchart wrote:

quoted

On Tue, Mar 17, 2026 at 02:40:43PM +0800, Chen-Yu Tsai wrote:

quoted

The rcar-du driver is directly calling dma_get_sgtable() on a
drm_gem_dma_object. Not passing the dma_attrs field in may cause
problems when DMA_ATTR_NO_KERNEL_MAPPING is added to the GEM DMA
helpers gain support later.

Instead, use the drm_gem_dma_get_sg_table() helper to get the scatter
gather table.

Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v1:
- new patch

Not sure if we should add a helper like drm_fb_dma_get_gem_addr(). This
seems to be the only driver that is using a scatter gather table to pass
DMA addresses.

The DU can't access memory directly (at least on Gen3 and newer), and
goes through a separate device called VSP that acts as an external DMA
engine (*) and compositor. This is why buffers need to be mapped
manually to the VSP, the GEM helpers would otherwise use the DU struct
device, which isn't correct. I can't use drm_device.dma_dev as the DMA
initiator can be different per CRTC.

I don't think a separate helper with a single user would be very useful
here, especially given that part of the logic in
drm_fb_dma_get_gem_addr() is in the separate vsp1 driver. Refactoring
may get messy, for little benefit.

* And in some cases the VSP further delegates memory access to the FCP,
which is yet another DMA initiator from an IOMMU point of view.

I see. That's probably the most complicated hardware I've seen so far.

I felt similar when I found out Gen3 dropped the DMA engines and
compositor previously part of the DU :-)

quoted

quoted

---
 drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c
index 94c22d2db197..6a62608ee3a9 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c

@@ -291,10 +291,16 @@ int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
                              dst = sg_next(dst);
                      }
              } else {
-                     ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr,
-                                           gem->dma_addr, gem->base.size);

Did you compile the patch ? The rcdu variable is now unused. Apart from
that, it compiles fine and seems to operate as expected.

I probably missed it in the logs. Thanks for catching it.

quoted

quoted

-                     if (ret)
+                     struct sg_table *ret_sgt;
+
+                     ret_sgt = drm_gem_dma_get_sg_table(gem);
+                     if (IS_ERR(ret_sgt)) {
+                             ret = PTR_ERR(ret_sgt);
                              goto fail;
+                     }
+
+                     memcpy(sgt, ret_sgt, sizeof(*sgt));
+                     kfree(ret_sgt);

It's a bit of a shame to kmalloc() a new sg_table and free it right
after :-/ Would it be that bad to switch to dma_get_sgtable_attrs()
here, and pass gem->dma_attrs to the function ?

That's another option. I was trying to isolate the DMA API calls to
just the GEM DMA helpers, but as you said, it's a bit wasteful.

I like the goal of avoiding direct DMA mapping API calls, but I'm
worried it will cause more harm than good in this case :-/

I'll just switch to dma_get_sgtable_attrs() and squash the change into
the other dma_*_attrs() conversion patch.

OK.

quoted

quoted

              }

              ret = vsp1_du_map_sg(vsp->vsp, sgt);

-- 
Regards,

Laurent Pinchart