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

Chen-Yu Tsai
2026-03-18T06:51:41Z

On Wed, Mar 18, 2026 at 12:57 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> 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.

I guess this won't work since drm_client_buffer_create_dumb() calls
drm_mode_create_dumb(), and we need a way from the upper layer to
say we need the mapping.

> 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