On Wed, Mar 18, 2026 at 12:57 PM Chen-Yu Tsai <[email protected]> wrote: > > On Tue, Mar 17, 2026 at 8:24 PM Thomas Zimmermann <[email protected]> wrote: > > > > Hi > > > > Am 17.03.26 um 11:58 schrieb Chen-Yu Tsai: > > > On Tue, Mar 17, 2026 at 4:12 PM Thomas Zimmermann <[email protected]> > > > wrote: > > >> Hi > > >> > > >> Am 17.03.26 um 07:40 schrieb Chen-Yu Tsai: > > >>> From: Rob Herring <[email protected]> > > >>> > > >>> 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
