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.
---
 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);
-			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);
 		}
 
 		ret = vsp1_du_map_sg(vsp->vsp, sgt);
-- 
2.53.0.851.ga537e3e6e9-goog

Hi Chen-Yu,

Thank you for the patch.

On Tue, Mar 17, 2026 at 02:40:43PM +0800, Chen-Yu Tsai wrote:
> 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.

> ---
>  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.

> -			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 ?

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

-- 
Regards,

Laurent Pinchart

On Thu, Mar 19, 2026 at 12:02 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Chen-Yu,
>
> Thank you for the patch.
>
> On Tue, Mar 17, 2026 at 02:40:43PM +0800, Chen-Yu Tsai wrote:
> > 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.

> > ---
> >  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.

> > -                     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'll just switch to dma_get_sgtable_attrs() and squash the change into
the other dma_*_attrs() conversion patch.


Thanks
ChenYu

> >               }
> >
> >               ret = vsp1_du_map_sg(vsp->vsp, sgt);
>
> --
> Regards,
>
> Laurent Pinchart

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:
> > On Tue, Mar 17, 2026 at 02:40:43PM +0800, Chen-Yu Tsai wrote:
> > > 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 :-)

> > > ---
> > >  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.
> 
> > > -                     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.

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

-- 
Regards,

Laurent Pinchart