Re: [PATCH v2 2/4] drm: Introduce DRM_MODE_DUMB_KERNEL_MAP flag

Chen-Yu Tsai
2026-03-18T04:57:16Z

On Tue, Mar 17, 2026 at 8:24 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 17.03.26 um 11:58 schrieb Chen-Yu Tsai:
> > On Tue, Mar 17, 2026 at 4:12 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >> Hi
> >>
> >> Am 17.03.26 um 07:40 schrieb Chen-Yu Tsai:
> >>> From: Rob Herring <robh@kernel.org>
> >>>
> >>> Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
> >>> drm_mode_create_dumb. This flag is for internal kernel use to indicate
> >>> if dumb buffer allocation needs a kernel mapping. This is needed only for
> >>> CMA where creating a kernel mapping or not has to be decided at allocation
> >>> time because creating a mapping on demand (with vmap()) is not guaranteed
> >>> to work. Several drivers are using CMA, but not the CMA helpers because
> >>> they distinguish between kernel and userspace allocations to create a
> >>> kernel mapping or not.
> >> Any dumb allocation might require vmap. This is not limited to internal
> >> buffers. Because if the dumb buffer is shared with another driver, that
> >> driver might require the vmap for displaying the buffer content. There
> >> are enough of such drivers.
> > By sharing, do you mean exported via PRIME then imported by another device?
> > Or just passing around GEM objects within the kernel?
>
> I mean PRIME/dma-buf sharing.
>
> >
> > And could you provide an example?
>
> Create a dumb GEM buffer on one of those CMA devices and mirror it to a
> display or udl device. These devices have no means of scanning out the
> provided buffer directly, so their drivers vmap the buffer and copy the
> pixel data into their internal memory (via a peripheral bus). The vmap
> call happens via the kernel's internal dma-buf interfaces. Hence any
> driver needs support for vmap if it wants to support this use case.

I see.

In that case would it make sense to limit not setting this new flag to
drivers that already specify DMA_ATTR_NO_KERNEL_MAPPING? Or rather
inverting it so the default without the flag is to have the kernel
mapping. It would be opt-in rather than opt-out.

This includes just exynos, rockchip, and previously mediatek. Having
this would allow moving them closer to fully utilizing the GEM DMA
helpers without changing their existing behavior.

The flag was removed from the mediatek driver during a previous
refactoring to move it to the GEM DMA helpers, but I think it was
a limitation of the helpers, not an intended change. Angelo might
be able to provide some context around that.

Or maybe I just keep the dma_*_attr() conversion patch to satisfy
the needs of the aforementioned drivers? What do you think?

Thanks
ChenYu