When drivers pass non-empty lists of modifiers for initializing their
planes, we can infer that they allow framebuffer modifiers and set the
driver's allow_fb_modifiers mode config element.
In case the allow_fb_modifiers element was not set (some drivers tend
to set them after registering planes), the modifiers will still be
registered but won't be available to userspace unless the flag is set
later. However in that case, the IN_FORMATS blob won't be created.
In order to avoid this case and generally reduce the trouble associated
with the flag, always set allow_fb_modifiers when a non-empty list of
format modifiers is passed at plane init.
Signed-off-by: Paul Kocialkowski <[email protected]>
---
drivers/gpu/drm/drm_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 5f650d8fc66b..4cfb56893b7f 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -220,6 +220,9 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
format_modifier_count++;
}
+ if (format_modifier_count)
+ config->allow_fb_modifiers = true;
+
plane->modifier_count = format_modifier_count;
plane->modifiers = kmalloc_array(format_modifier_count,
sizeof(format_modifiers[0]),
--
2.20.1
On Fri, Jan 04, 2019 at 09:56:10AM +0100, Paul Kocialkowski wrote:
> When drivers pass non-empty lists of modifiers for initializing their
> planes, we can infer that they allow framebuffer modifiers and set the
> driver's allow_fb_modifiers mode config element.
>
> In case the allow_fb_modifiers element was not set (some drivers tend
> to set them after registering planes), the modifiers will still be
> registered but won't be available to userspace unless the flag is set
> later. However in that case, the IN_FORMATS blob won't be created.
>
> In order to avoid this case and generally reduce the trouble associated
> with the flag, always set allow_fb_modifiers when a non-empty list of
> format modifiers is passed at plane init.
>
> Signed-off-by: Paul Kocialkowski <[email protected]>
The automatic primary plane drm_crtc_init() creates doesn't set this, so
looks correct in all cases.
Reviewed-by: Daniel Vetter <[email protected]>
(boolin.com has a bunch of drm-misc committers, so I'll leave pushing to
them).
-Daniel
> ---
> drivers/gpu/drm/drm_plane.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 5f650d8fc66b..4cfb56893b7f 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -220,6 +220,9 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
> format_modifier_count++;
> }
>
> + if (format_modifier_count)
> + config->allow_fb_modifiers = true;
> +
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> sizeof(format_modifiers[0]),
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Jan 07, 2019 at 11:49:16AM +0100, Daniel Vetter wrote:
> On Fri, Jan 04, 2019 at 09:56:10AM +0100, Paul Kocialkowski wrote:
> > When drivers pass non-empty lists of modifiers for initializing their
> > planes, we can infer that they allow framebuffer modifiers and set the
> > driver's allow_fb_modifiers mode config element.
> >
> > In case the allow_fb_modifiers element was not set (some drivers tend
> > to set them after registering planes), the modifiers will still be
> > registered but won't be available to userspace unless the flag is set
> > later. However in that case, the IN_FORMATS blob won't be created.
> >
> > In order to avoid this case and generally reduce the trouble associated
> > with the flag, always set allow_fb_modifiers when a non-empty list of
> > format modifiers is passed at plane init.
> >
> > Signed-off-by: Paul Kocialkowski <[email protected]>
>
> The automatic primary plane drm_crtc_init() creates doesn't set this, so
> looks correct in all cases.
>
> Reviewed-by: Daniel Vetter <[email protected]>
>
> (boolin.com has a bunch of drm-misc committers, so I'll leave pushing to
> them).
Applied,
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com