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.
Update the callers of drm_mode_dumb_create() to set
drm_mode_dumb_create.flags to appropriate defaults. Currently, flags can
be set to anything by userspace, but is unused within the kernel. Let's
force flags to zero (no kernel mapping) for userspace callers by default.
For in kernel clients, set DRM_MODE_DUMB_KERNEL_MAP by default. Drivers
can override this as needed.
Signed-off-by: Rob Herring <robh@kernel.org>
[wenst@chromium.org: Emit warning if args->flags is not zero]
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v1:
- Emit warning if args->flags is not zero
---
drivers/gpu/drm/drm_client.c | 1 +
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++++
include/uapi/drm/drm_mode.h | 2 ++
3 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 46c465bce98c..1a57e7eadc0f 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -404,6 +404,7 @@ drm_client_buffer_create_dumb(struct drm_client_dev *client, u32 width, u32 heig
dumb_args.width = width;
dumb_args.height = height;
dumb_args.bpp = drm_format_info_bpp(info, 0);
+ dumb_args.flags = DRM_MODE_DUMB_KERNEL_MAP;
ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
index e2b62e5fb891..ccdcc401d4dc 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -233,6 +233,10 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
struct drm_mode_create_dumb *args = data;
int err;
+ if (args->flags)
+ drm_warn(dev, "drm_mode_create_dumb.flags is not zero.\n");
+ args->flags = 0;
+
err = drm_mode_create_dumb(dev, args, file_priv);
if (err) {
args->handle = 0;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 3693d82b5279..7d5f50e4af70 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -1272,6 +1272,8 @@ struct drm_mode_create_dumb {
__u64 size;
};
+#define DRM_MODE_DUMB_KERNEL_MAP (1<<0) /* For internal kernel use */
+
/* set up for mmap of a dumb scanout buffer */
struct drm_mode_map_dumb {
/** Handle for the object being mapped. */
--
2.53.0.851.ga537e3e6e9-googHi
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.
>
> Update the callers of drm_mode_dumb_create() to set
> drm_mode_dumb_create.flags to appropriate defaults. Currently, flags can
> be set to anything by userspace, but is unused within the kernel. Let's
> force flags to zero (no kernel mapping) for userspace callers by default.
> For in kernel clients, set DRM_MODE_DUMB_KERNEL_MAP by default. Drivers
> can override this as needed.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> [wenst@chromium.org: Emit warning if args->flags is not zero]
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Changes since v1:
> - Emit warning if args->flags is not zero
> ---
> drivers/gpu/drm/drm_client.c | 1 +
> drivers/gpu/drm/drm_dumb_buffers.c | 4 ++++
> include/uapi/drm/drm_mode.h | 2 ++
> 3 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 46c465bce98c..1a57e7eadc0f 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -404,6 +404,7 @@ drm_client_buffer_create_dumb(struct drm_client_dev *client, u32 width, u32 heig
> dumb_args.width = width;
> dumb_args.height = height;
> dumb_args.bpp = drm_format_info_bpp(info, 0);
> + dumb_args.flags = DRM_MODE_DUMB_KERNEL_MAP;
> ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
> if (ret)
> return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
> index e2b62e5fb891..ccdcc401d4dc 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -233,6 +233,10 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> struct drm_mode_create_dumb *args = data;
> int err;
>
> + if (args->flags)
> + drm_warn(dev, "drm_mode_create_dumb.flags is not zero.\n");
At most use drm_warn_once() to not let this spam the kernel log.
> + args->flags = 0;
> +
> err = drm_mode_create_dumb(dev, args, file_priv);
> if (err) {
> args->handle = 0;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 3693d82b5279..7d5f50e4af70 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -1272,6 +1272,8 @@ struct drm_mode_create_dumb {
> __u64 size;
> };
>
> +#define DRM_MODE_DUMB_KERNEL_MAP (1<<0) /* For internal kernel use */
> +
If this is an internal flag, it should not live in the UAPI header.
include/drm/drm_dumb_buffers.h would be a good place.
Best regards
Thomas
> /* set up for mmap of a dumb scanout buffer */
> struct drm_mode_map_dumb {
> /** Handle for the object being mapped. */
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
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?
And could you provide an example?
> > Update the callers of drm_mode_dumb_create() to set
> > drm_mode_dumb_create.flags to appropriate defaults. Currently, flags can
> > be set to anything by userspace, but is unused within the kernel. Let's
> > force flags to zero (no kernel mapping) for userspace callers by default.
> > For in kernel clients, set DRM_MODE_DUMB_KERNEL_MAP by default. Drivers
> > can override this as needed.
> >
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > [wenst@chromium.org: Emit warning if args->flags is not zero]
> > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> > ---
> > Changes since v1:
> > - Emit warning if args->flags is not zero
> > ---
> > drivers/gpu/drm/drm_client.c | 1 +
> > drivers/gpu/drm/drm_dumb_buffers.c | 4 ++++
> > include/uapi/drm/drm_mode.h | 2 ++
> > 3 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> > index 46c465bce98c..1a57e7eadc0f 100644
> > --- a/drivers/gpu/drm/drm_client.c
> > +++ b/drivers/gpu/drm/drm_client.c
> > @@ -404,6 +404,7 @@ drm_client_buffer_create_dumb(struct drm_client_dev *client, u32 width, u32 heig
> > dumb_args.width = width;
> > dumb_args.height = height;
> > dumb_args.bpp = drm_format_info_bpp(info, 0);
> > + dumb_args.flags = DRM_MODE_DUMB_KERNEL_MAP;
> > ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
> > if (ret)
> > return ERR_PTR(ret);
> > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
> > index e2b62e5fb891..ccdcc401d4dc 100644
> > --- a/drivers/gpu/drm/drm_dumb_buffers.c
> > +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> > @@ -233,6 +233,10 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> > struct drm_mode_create_dumb *args = data;
> > int err;
> >
> > + if (args->flags)
> > + drm_warn(dev, "drm_mode_create_dumb.flags is not zero.\n");
>
> At most use drm_warn_once() to not let this spam the kernel log.
Sure.
> > + args->flags = 0;
> > +
> > err = drm_mode_create_dumb(dev, args, file_priv);
> > if (err) {
> > args->handle = 0;
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 3693d82b5279..7d5f50e4af70 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -1272,6 +1272,8 @@ struct drm_mode_create_dumb {
> > __u64 size;
> > };
> >
> > +#define DRM_MODE_DUMB_KERNEL_MAP (1<<0) /* For internal kernel use */
> > +
>
> If this is an internal flag, it should not live in the UAPI header.
> include/drm/drm_dumb_buffers.h would be a good place.
Makes sense.
Thanks
ChenYu
> Best regards
> Thomas
>
> > /* set up for mmap of a dumb scanout buffer */
> > struct drm_mode_map_dumb {
> > /** Handle for the object being mapped. */
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
>
>
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.
Best regards
Thomas
>
>>> Update the callers of drm_mode_dumb_create() to set
>>> drm_mode_dumb_create.flags to appropriate defaults. Currently, flags can
>>> be set to anything by userspace, but is unused within the kernel. Let's
>>> force flags to zero (no kernel mapping) for userspace callers by default.
>>> For in kernel clients, set DRM_MODE_DUMB_KERNEL_MAP by default. Drivers
>>> can override this as needed.
>>>
>>> Signed-off-by: Rob Herring <robh@kernel.org>
>>> [wenst@chromium.org: Emit warning if args->flags is not zero]
>>> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
>>> ---
>>> Changes since v1:
>>> - Emit warning if args->flags is not zero
>>> ---
>>> drivers/gpu/drm/drm_client.c | 1 +
>>> drivers/gpu/drm/drm_dumb_buffers.c | 4 ++++
>>> include/uapi/drm/drm_mode.h | 2 ++
>>> 3 files changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
>>> index 46c465bce98c..1a57e7eadc0f 100644
>>> --- a/drivers/gpu/drm/drm_client.c
>>> +++ b/drivers/gpu/drm/drm_client.c
>>> @@ -404,6 +404,7 @@ drm_client_buffer_create_dumb(struct drm_client_dev *client, u32 width, u32 heig
>>> dumb_args.width = width;
>>> dumb_args.height = height;
>>> dumb_args.bpp = drm_format_info_bpp(info, 0);
>>> + dumb_args.flags = DRM_MODE_DUMB_KERNEL_MAP;
>>> ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
>>> if (ret)
>>> return ERR_PTR(ret);
>>> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c
>>> index e2b62e5fb891..ccdcc401d4dc 100644
>>> --- a/drivers/gpu/drm/drm_dumb_buffers.c
>>> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
>>> @@ -233,6 +233,10 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
>>> struct drm_mode_create_dumb *args = data;
>>> int err;
>>>
>>> + if (args->flags)
>>> + drm_warn(dev, "drm_mode_create_dumb.flags is not zero.\n");
>> At most use drm_warn_once() to not let this spam the kernel log.
> Sure.
>
>>> + args->flags = 0;
>>> +
>>> err = drm_mode_create_dumb(dev, args, file_priv);
>>> if (err) {
>>> args->handle = 0;
>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>> index 3693d82b5279..7d5f50e4af70 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -1272,6 +1272,8 @@ struct drm_mode_create_dumb {
>>> __u64 size;
>>> };
>>>
>>> +#define DRM_MODE_DUMB_KERNEL_MAP (1<<0) /* For internal kernel use */
>>> +
>> If this is an internal flag, it should not live in the UAPI header.
>> include/drm/drm_dumb_buffers.h would be a good place.
> Makes sense.
>
>
> Thanks
> ChenYu
>
>> Best regards
>> Thomas
>>
>>> /* set up for mmap of a dumb scanout buffer */
>>> struct drm_mode_map_dumb {
>>> /** Handle for the object being mapped. */
>> --
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
>> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
>>
>>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
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
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
© 2016 - 2026 Red Hat, Inc.