| Message ID | 20170503051428.4734-1-ben@bwidawsk.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote: > v2: A minor addition from Daniel > > Cc: Daniel Stone <daniels@collabora.com> You are *really* pushing your luck by not Cc-ing *any* of the maintainers of the drivers you touch. You do want reviews, don't you? > Signed-off-by: Ben Widawsky <ben@bwidawsk.net> > --- > drivers/gpu/drm/arc/arcpgu_crtc.c | 1 + > drivers/gpu/drm/arm/hdlcd_crtc.c | 1 + > drivers/gpu/drm/arm/malidp_planes.c | 2 +- > drivers/gpu/drm/armada/armada_crtc.c | 1 + > drivers/gpu/drm/armada/armada_overlay.c | 1 + > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +++- > drivers/gpu/drm/drm_modeset_helper.c | 1 + > drivers/gpu/drm/drm_plane.c | 32 ++++++++++++++++++++++++- > drivers/gpu/drm/drm_simple_kms_helper.c | 3 +++ > drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +- > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 1 + > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- > drivers/gpu/drm/i915/intel_display.c | 7 +++++- > drivers/gpu/drm/i915/intel_sprite.c | 4 ++-- > drivers/gpu/drm/imx/ipuv3-plane.c | 4 ++-- > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +- > drivers/gpu/drm/meson/meson_plane.c | 1 + > drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 2 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 4 ++-- > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +- > drivers/gpu/drm/nouveau/nv50_display.c | 5 ++-- > drivers/gpu/drm/omapdrm/omap_plane.c | 3 ++- > drivers/gpu/drm/qxl/qxl_display.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 ++-- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 ++-- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++-- > drivers/gpu/drm/sti/sti_cursor.c | 2 +- > drivers/gpu/drm/sti/sti_gdp.c | 2 +- > drivers/gpu/drm/sti/sti_hqvdp.c | 2 +- > drivers/gpu/drm/sun4i/sun4i_layer.c | 2 +- > drivers/gpu/drm/tegra/dc.c | 12 +++++----- > drivers/gpu/drm/vc4/vc4_plane.c | 2 +- > drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 ++-- > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ++-- > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ++-- > drivers/gpu/drm/zte/zx_plane.c | 2 +- > include/drm/drm_plane.h | 21 +++++++++++++++- > include/drm/drm_simple_kms_helper.h | 1 + > include/uapi/drm/drm_fourcc.h | 11 +++++++++ > 41 files changed, 126 insertions(+), 46 deletions(-) I wish there was a way to sort the non-driver-specific changes out of this patch and put the at the beginning or at the end of the patchset. That way one does not have to hunt through the file for the relevant changes in the API. How about introducing a new function called drm_universal_plane_mod_init() that has the new parameter, a second patch that moves the relevant/all drivers to the new function and (if all drivers were converted) a third patch to rename drm_universal_plane_mod_init() back to drm_universal_plane_init()? I know it is more churn, but I'm struggling to figure out why all the drivers have to pass a NULL here. Either they care about modifiers or they don't, in which case a separate function would make things more obvious. Finally, the questions I should've started with: why the change? What are you trying to achieve? It is not very clear from the commit message at all. > > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c b/drivers/gpu/drm/arc/arcpgu_crtc.c > index ad9a95916f1f..cd8a24c7c67d 100644 > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c > @@ -218,6 +218,7 @@ static struct drm_plane *arc_pgu_plane_init(struct drm_device *drm) > > ret = drm_universal_plane_init(drm, plane, 0xff, &arc_pgu_plane_funcs, > formats, ARRAY_SIZE(formats), > + NULL, > DRM_PLANE_TYPE_PRIMARY, NULL); > if (ret) > return ERR_PTR(ret); > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c > index 798a3cc480a2..0caa03ae8708 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -303,6 +303,7 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device *drm) > > ret = drm_universal_plane_init(drm, plane, 0xff, &hdlcd_plane_funcs, > formats, ARRAY_SIZE(formats), > + NULL, > DRM_PLANE_TYPE_PRIMARY, NULL); > if (ret) { > devm_kfree(drm->dev, plane); > diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c > index 814fda23cead..b156610c68a5 100644 > --- a/drivers/gpu/drm/arm/malidp_planes.c > +++ b/drivers/gpu/drm/arm/malidp_planes.c > @@ -400,7 +400,7 @@ int malidp_de_planes_init(struct drm_device *drm) > DRM_PLANE_TYPE_OVERLAY; > ret = drm_universal_plane_init(drm, &plane->base, crtcs, > &malidp_de_plane_funcs, formats, > - n, plane_type, NULL); > + n, NULL, plane_type, NULL); It would be nice if you can be consistent with the change. Either add the NULL on a new line or keep updating the line where the new parameter would fit. Did you do this change manually or used coccinelle? > if (ret < 0) > goto cleanup; > > diff --git a/drivers/gpu/drm/armada/armada_crtc.c b/drivers/gpu/drm/armada/armada_crtc.c > index 4fe19fde84f9..ea48ef88f0e4 100644 > --- a/drivers/gpu/drm/armada/armada_crtc.c > +++ b/drivers/gpu/drm/armada/armada_crtc.c > @@ -1269,6 +1269,7 @@ static int armada_drm_crtc_create(struct drm_device *drm, struct device *dev, > &armada_primary_plane_funcs, > armada_primary_formats, > ARRAY_SIZE(armada_primary_formats), > + NULL, > DRM_PLANE_TYPE_PRIMARY, NULL); > if (ret) { > kfree(primary); > diff --git a/drivers/gpu/drm/armada/armada_overlay.c b/drivers/gpu/drm/armada/armada_overlay.c > index 424e465ff407..0054144287ae 100644 > --- a/drivers/gpu/drm/armada/armada_overlay.c > +++ b/drivers/gpu/drm/armada/armada_overlay.c > @@ -460,6 +460,7 @@ int armada_overlay_plane_create(struct drm_device *dev, unsigned long crtcs) > &armada_ovl_plane_funcs, > armada_ovl_formats, > ARRAY_SIZE(armada_ovl_formats), > + NULL, > DRM_PLANE_TYPE_OVERLAY, NULL); > if (ret) { > kfree(dplane); > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > index 29cc10d053eb..b5c6cf2d8c36 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > @@ -1058,7 +1058,9 @@ static int atmel_hlcdc_plane_create(struct drm_device *dev, > ret = drm_universal_plane_init(dev, &plane->base, 0, > &layer_plane_funcs, > desc->formats->formats, > - desc->formats->nformats, type, NULL); > + desc->formats->nformats, > + NULL, > + type, NULL); > if (ret) > return ret; > > diff --git a/drivers/gpu/drm/drm_modeset_helper.c b/drivers/gpu/drm/drm_modeset_helper.c > index 2b33825f2f93..9cb1eede0b4d 100644 > --- a/drivers/gpu/drm/drm_modeset_helper.c > +++ b/drivers/gpu/drm/drm_modeset_helper.c > @@ -124,6 +124,7 @@ static struct drm_plane *create_primary_plane(struct drm_device *dev) > &drm_primary_helper_funcs, > safe_modeset_formats, > ARRAY_SIZE(safe_modeset_formats), > + NULL, > DRM_PLANE_TYPE_PRIMARY, NULL); > if (ret) { > kfree(primary); > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > index fedd4d60d9cd..286e183891e5 100644 > --- a/drivers/gpu/drm/drm_plane.c > +++ b/drivers/gpu/drm/drm_plane.c > @@ -70,6 +70,7 @@ static unsigned int drm_num_planes(struct drm_device *dev) > * @funcs: callbacks for the new plane > * @formats: array of supported formats (DRM_FORMAT\_\*) > * @format_count: number of elements in @formats > + * @format_modifiers: array of struct drm_format modifiers terminated by INVALID You actually called the thing DRM_FORMAT_MOD_INVALID. Make sure the documentation correctly reflects that. > * @type: type of plane (overlay, primary, cursor) > * @name: printf style format string for the plane name, or NULL for default name > * > @@ -82,10 +83,12 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, > uint32_t possible_crtcs, > const struct drm_plane_funcs *funcs, > const uint32_t *formats, unsigned int format_count, > + const uint64_t *format_modifiers, > enum drm_plane_type type, > const char *name, ...) > { > struct drm_mode_config *config = &dev->mode_config; > + unsigned int format_modifier_count = 0; > int ret; > > ret = drm_mode_object_add(dev, &plane->base, DRM_MODE_OBJECT_PLANE); > @@ -105,6 +108,28 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, > return -ENOMEM; > } > > + /* First driver to need more than 64 formats needs to fix this */ > + if (WARN_ON(format_count > 64)) > + return -EINVAL; What is the link between format_count and format modifiers? Why are you introducing this artificial restriction on the format_count? Also, there doesn't seem to be any check if format_modifier_count == format_count. What happens when they don't match? > + > + if (format_modifiers) { > + const uint64_t *temp_modifiers = format_modifiers; > + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID) > + format_modifier_count++; > + } > + > + plane->modifier_count = format_modifier_count; Why do you need to remember this? It is not used anywhere else! > + plane->modifiers = kmalloc_array(format_modifier_count, > + sizeof(format_modifiers[0]), > + GFP_KERNEL); > + > + if (format_modifier_count && !plane->modifiers) { > + DRM_DEBUG_KMS("out of memory when allocating plane\n"); > + kfree(plane->format_types); > + drm_mode_object_unregister(dev, &plane->base); > + return -ENOMEM; > + } > + > if (name) { > va_list ap; > > @@ -117,12 +142,15 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, > } > if (!plane->name) { > kfree(plane->format_types); > + kfree(plane->modifiers); > drm_mode_object_unregister(dev, &plane->base); > return -ENOMEM; > } > > memcpy(plane->format_types, formats, format_count * sizeof(uint32_t)); > plane->format_count = format_count; > + memcpy(plane->modifiers, format_modifiers, > + format_modifier_count * sizeof(format_modifiers[0])); Don't you need to check that format_modifiers != NULL before memcpy? > plane->possible_crtcs = possible_crtcs; > plane->type = type; > > @@ -205,7 +233,8 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane *plane, > > type = is_primary ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY; > return drm_universal_plane_init(dev, plane, possible_crtcs, funcs, > - formats, format_count, type, NULL); > + formats, format_count, > + NULL, type, NULL); > } > EXPORT_SYMBOL(drm_plane_init); > > @@ -224,6 +253,7 @@ void drm_plane_cleanup(struct drm_plane *plane) > drm_modeset_lock_fini(&plane->mutex); > > kfree(plane->format_types); > + kfree(plane->modifiers); > drm_mode_object_unregister(dev, &plane->base); > > BUG_ON(list_empty(&plane->head)); > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c b/drivers/gpu/drm/drm_simple_kms_helper.c > index e084f9f8ca66..949f0ab0e267 100644 > --- a/drivers/gpu/drm/drm_simple_kms_helper.c > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c > @@ -193,6 +193,7 @@ EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge); > * @funcs: callbacks for the display pipe (optional) > * @formats: array of supported formats (DRM_FORMAT\_\*) > * @format_count: number of elements in @formats > + * @format_modifiers: array of formats modifiers > * @connector: connector to attach and register (optional) > * > * Sets up a display pipeline which consist of a really simple > @@ -213,6 +214,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev, > struct drm_simple_display_pipe *pipe, > const struct drm_simple_display_pipe_funcs *funcs, > const uint32_t *formats, unsigned int format_count, > + const uint64_t *format_modifiers, > struct drm_connector *connector) > { > struct drm_encoder *encoder = &pipe->encoder; > @@ -227,6 +229,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev, > ret = drm_universal_plane_init(dev, plane, 0, > &drm_simple_kms_plane_funcs, > formats, format_count, > + format_modifiers, > DRM_PLANE_TYPE_PRIMARY, NULL); > if (ret) > return ret; > diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c > index c2f17f30afab..75d4928dd196 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c > @@ -284,7 +284,7 @@ int exynos_plane_init(struct drm_device *dev, > &exynos_plane_funcs, > config->pixel_formats, > config->num_pixel_formats, > - config->type, NULL); > + NULL, config->type, NULL); > if (err) { > DRM_ERROR("failed to initialize plane\n"); > return err; > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c > index 0a20723aa6e1..9554b245746e 100644 > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c > @@ -224,7 +224,7 @@ struct drm_plane *fsl_dcu_drm_primary_create_plane(struct drm_device *dev) > &fsl_dcu_drm_plane_funcs, > fsl_dcu_drm_plane_formats, > ARRAY_SIZE(fsl_dcu_drm_plane_formats), > - DRM_PLANE_TYPE_PRIMARY, NULL); > + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); > if (ret) { > kfree(primary); > primary = NULL; > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c > index 59542bddc980..339e914cbaa3 100644 > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c > @@ -181,6 +181,7 @@ static struct drm_plane *hibmc_plane_init(struct hibmc_drm_private *priv) > ret = drm_universal_plane_init(dev, plane, 1, &hibmc_plane_funcs, > channel_formats1, > ARRAY_SIZE(channel_formats1), > + NULL, > DRM_PLANE_TYPE_PRIMARY, > NULL); > if (ret) { > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > index c96c228a9898..1acb8af12246 100644 > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > @@ -909,7 +909,7 @@ static int ade_plane_init(struct drm_device *dev, struct ade_plane *aplane, > return ret; > > ret = drm_universal_plane_init(dev, &aplane->base, 1, &ade_plane_funcs, > - fmts, fmts_cnt, type, NULL); > + fmts, fmts_cnt, NULL, type, NULL); > if (ret) { > DRM_ERROR("fail to init plane, ch=%d\n", aplane->ch); > return ret; > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index 3617927af269..d52bd05a017d 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -13516,6 +13516,8 @@ intel_legacy_cursor_update(struct drm_plane *plane, > src_x, src_y, src_w, src_h, ctx); > } > > + > + Extra blank lines not needed here. > static const struct drm_plane_funcs intel_cursor_plane_funcs = { > .update_plane = intel_legacy_cursor_update, > .disable_plane = drm_atomic_helper_disable_plane, > @@ -13594,18 +13596,21 @@ intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe) > ret = drm_universal_plane_init(&dev_priv->drm, &primary->base, > 0, &intel_plane_funcs, > intel_primary_formats, num_formats, > + NULL, > DRM_PLANE_TYPE_PRIMARY, > "plane 1%c", pipe_name(pipe)); > else if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv)) > ret = drm_universal_plane_init(&dev_priv->drm, &primary->base, > 0, &intel_plane_funcs, > intel_primary_formats, num_formats, > + NULL, > DRM_PLANE_TYPE_PRIMARY, > "primary %c", pipe_name(pipe)); > else > ret = drm_universal_plane_init(&dev_priv->drm, &primary->base, > 0, &intel_plane_funcs, > intel_primary_formats, num_formats, > + NULL, > DRM_PLANE_TYPE_PRIMARY, > "plane %c", plane_name(primary->plane)); > if (ret) > @@ -13776,7 +13781,7 @@ intel_cursor_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe) > 0, &intel_cursor_plane_funcs, > intel_cursor_formats, > ARRAY_SIZE(intel_cursor_formats), > - DRM_PLANE_TYPE_CURSOR, > + NULL, DRM_PLANE_TYPE_CURSOR, > "cursor %c", pipe_name(pipe)); > if (ret) > goto fail; > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c > index f7d431427115..053802dd08c1 100644 > --- a/drivers/gpu/drm/i915/intel_sprite.c > +++ b/drivers/gpu/drm/i915/intel_sprite.c > @@ -1165,13 +1165,13 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv, > ret = drm_universal_plane_init(&dev_priv->drm, &intel_plane->base, > possible_crtcs, &intel_plane_funcs, > plane_formats, num_plane_formats, > - DRM_PLANE_TYPE_OVERLAY, > + NULL, DRM_PLANE_TYPE_OVERLAY, > "plane %d%c", plane + 2, pipe_name(pipe)); > else > ret = drm_universal_plane_init(&dev_priv->drm, &intel_plane->base, > possible_crtcs, &intel_plane_funcs, > plane_formats, num_plane_formats, > - DRM_PLANE_TYPE_OVERLAY, > + NULL, DRM_PLANE_TYPE_OVERLAY, > "sprite %c", sprite_name(pipe, plane)); > if (ret) > goto fail; > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c > index d63e853a0300..6c708c3b1cdc 100644 > --- a/drivers/gpu/drm/imx/ipuv3-plane.c > +++ b/drivers/gpu/drm/imx/ipuv3-plane.c > @@ -718,8 +718,8 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev, struct ipu_soc *ipu, > > ret = drm_universal_plane_init(dev, &ipu_plane->base, possible_crtcs, > &ipu_plane_funcs, ipu_plane_formats, > - ARRAY_SIZE(ipu_plane_formats), type, > - NULL); > + ARRAY_SIZE(ipu_plane_formats), > + NULL, type, NULL); > if (ret) { > DRM_ERROR("failed to initialize plane\n"); > kfree(ipu_plane); > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c > index e405e89ed5e5..bec6d14dd070 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c > @@ -173,7 +173,7 @@ int mtk_plane_init(struct drm_device *dev, struct drm_plane *plane, > > err = drm_universal_plane_init(dev, plane, possible_crtcs, > &mtk_plane_funcs, formats, > - ARRAY_SIZE(formats), type, NULL); > + ARRAY_SIZE(formats), NULL, type, NULL); > if (err) { > DRM_ERROR("failed to initialize plane\n"); > return err; > diff --git a/drivers/gpu/drm/meson/meson_plane.c b/drivers/gpu/drm/meson/meson_plane.c > index a32d3b6e2e12..17e96fa47868 100644 > --- a/drivers/gpu/drm/meson/meson_plane.c > +++ b/drivers/gpu/drm/meson/meson_plane.c > @@ -223,6 +223,7 @@ int meson_plane_create(struct meson_drm *priv) > &meson_plane_funcs, > supported_drm_formats, > ARRAY_SIZE(supported_drm_formats), > + NULL, > DRM_PLANE_TYPE_PRIMARY, "meson_primary_plane"); > > drm_plane_helper_add(plane, &meson_plane_helper_funcs); > diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c > index 53619d07677e..8f3417e45d4e 100644 > --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c > +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c > @@ -398,7 +398,7 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev, > type = private_plane ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY; > ret = drm_universal_plane_init(dev, plane, 0xff, &mdp4_plane_funcs, > mdp4_plane->formats, mdp4_plane->nformats, > - type, NULL); > + NULL, type, NULL); > if (ret) > goto fail; > > diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c > index a38c5fe6cc19..a815bc0e78d1 100644 > --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c > +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c > @@ -1140,12 +1140,12 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev, > ret = drm_universal_plane_init(dev, plane, 0xff, > &mdp5_cursor_plane_funcs, > mdp5_plane->formats, mdp5_plane->nformats, > - type, NULL); > + NULL, type, NULL); > else > ret = drm_universal_plane_init(dev, plane, 0xff, > &mdp5_plane_funcs, > mdp5_plane->formats, mdp5_plane->nformats, > - type, NULL); > + NULL, type, NULL); > if (ret) > goto fail; > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > index d1b9c34c7c00..3ee3784a54f4 100644 > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > @@ -190,7 +190,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long flags) > } > > ret = drm_simple_display_pipe_init(drm, &mxsfb->pipe, &mxsfb_funcs, > - mxsfb_formats, ARRAY_SIZE(mxsfb_formats), > + mxsfb_formats, ARRAY_SIZE(mxsfb_formats), NULL, 0, > &mxsfb->connector); > if (ret < 0) { > dev_err(drm->dev, "Cannot setup simple display pipe\n"); > diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c > index 0e58537352fe..dde71be463f8 100644 > --- a/drivers/gpu/drm/nouveau/nv50_display.c > +++ b/drivers/gpu/drm/nouveau/nv50_display.c > @@ -1084,8 +1084,9 @@ nv50_wndw_ctor(const struct nv50_wndw_func *func, struct drm_device *dev, > wndw->func = func; > wndw->dmac = dmac; > > - ret = drm_universal_plane_init(dev, &wndw->plane, 0, &nv50_wndw, format, > - nformat, type, "%s-%d", name, index); > + ret = drm_universal_plane_init(dev, &wndw->plane, 0, &nv50_wndw, > + format, nformat, NULL, > + type, "%s-%d", name, index); > if (ret) > return ret; > > diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c > index 9168154d749e..9b8341d77468 100644 > --- a/drivers/gpu/drm/omapdrm/omap_plane.c > +++ b/drivers/gpu/drm/omapdrm/omap_plane.c > @@ -370,7 +370,8 @@ struct drm_plane *omap_plane_init(struct drm_device *dev, > > ret = drm_universal_plane_init(dev, plane, possible_crtcs, > &omap_plane_funcs, omap_plane->formats, > - omap_plane->nformats, type, NULL); > + omap_plane->nformats, > + NULL, type, NULL); > if (ret < 0) > goto error; > > diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c > index 058340a002c2..fcf1d2034449 100644 > --- a/drivers/gpu/drm/qxl/qxl_display.c > +++ b/drivers/gpu/drm/qxl/qxl_display.c > @@ -788,7 +788,7 @@ static struct drm_plane *qxl_create_plane(struct qxl_device *qdev, > > err = drm_universal_plane_init(&qdev->ddev, plane, possible_crtcs, > funcs, formats, num_formats, > - type, NULL); > + NULL, type, NULL); > if (err) > goto free_plane; > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c b/drivers/gpu/drm/rcar-du/rcar_du_plane.c > index dcde6288da6c..2b02eccbfb70 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c > @@ -743,8 +743,8 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp) > > ret = drm_universal_plane_init(rcdu->ddev, &plane->plane, crtcs, > &rcar_du_plane_funcs, formats, > - ARRAY_SIZE(formats), type, > - NULL); > + ARRAY_SIZE(formats), > + NULL, type, NULL); > if (ret < 0) > return ret; > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > index b0ff304ce3dc..e0c054f9b57a 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > @@ -368,8 +368,8 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp) > 1 << vsp->index, > &rcar_du_vsp_plane_funcs, > formats_kms, > - ARRAY_SIZE(formats_kms), type, > - NULL); > + ARRAY_SIZE(formats_kms), > + NULL, type, NULL); > if (ret < 0) > return ret; > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > index 3f7a82d1e095..d0cf57de9afc 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > @@ -1280,7 +1280,7 @@ static int vop_create_crtc(struct vop *vop) > 0, &vop_plane_funcs, > win_data->phy->data_formats, > win_data->phy->nformats, > - win_data->type, NULL); > + NULL, win_data->type, NULL); > if (ret) { > DRM_DEV_ERROR(vop->dev, "failed to init plane %d\n", > ret); > @@ -1319,7 +1319,7 @@ static int vop_create_crtc(struct vop *vop) > &vop_plane_funcs, > win_data->phy->data_formats, > win_data->phy->nformats, > - win_data->type, NULL); > + NULL, win_data->type, NULL); > if (ret) { > DRM_DEV_ERROR(vop->dev, "failed to init overlay %d\n", > ret); > diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c > index cca75bddb9ad..97c25e204bf4 100644 > --- a/drivers/gpu/drm/sti/sti_cursor.c > +++ b/drivers/gpu/drm/sti/sti_cursor.c > @@ -393,7 +393,7 @@ struct drm_plane *sti_cursor_create(struct drm_device *drm_dev, > &sti_cursor_plane_helpers_funcs, > cursor_supported_formats, > ARRAY_SIZE(cursor_supported_formats), > - DRM_PLANE_TYPE_CURSOR, NULL); > + NULL, DRM_PLANE_TYPE_CURSOR, NULL); > if (res) { > DRM_ERROR("Failed to initialize universal plane\n"); > goto err_plane; > diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c > index 88f16cdf6a4b..70391603c12d 100644 > --- a/drivers/gpu/drm/sti/sti_gdp.c > +++ b/drivers/gpu/drm/sti/sti_gdp.c > @@ -932,7 +932,7 @@ struct drm_plane *sti_gdp_create(struct drm_device *drm_dev, > &sti_gdp_plane_helpers_funcs, > gdp_supported_formats, > ARRAY_SIZE(gdp_supported_formats), > - type, NULL); > + NULL, type, NULL); > if (res) { > DRM_ERROR("Failed to initialize universal plane\n"); > goto err; > diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c > index 66f843148ef7..9a1ff352820d 100644 > --- a/drivers/gpu/drm/sti/sti_hqvdp.c > +++ b/drivers/gpu/drm/sti/sti_hqvdp.c > @@ -1296,7 +1296,7 @@ static struct drm_plane *sti_hqvdp_create(struct drm_device *drm_dev, > &sti_hqvdp_plane_helpers_funcs, > hqvdp_supported_formats, > ARRAY_SIZE(hqvdp_supported_formats), > - DRM_PLANE_TYPE_OVERLAY, NULL); > + NULL, DRM_PLANE_TYPE_OVERLAY, NULL); > if (res) { > DRM_ERROR("Failed to initialize universal plane\n"); > return NULL; > diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c > index f26bde5b9117..2d9f8d01ac2e 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_layer.c > +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c > @@ -115,7 +115,7 @@ static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm, > ret = drm_universal_plane_init(drm, &layer->plane, 0, > &sun4i_backend_layer_funcs, > plane->formats, plane->nformats, > - plane->type, NULL); > + NULL, plane->type, NULL); > if (ret) { > dev_err(drm->dev, "Couldn't initialize layer\n"); > return ERR_PTR(ret); > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c > index 95b373f739f2..0380edd054ac 100644 > --- a/drivers/gpu/drm/tegra/dc.c > +++ b/drivers/gpu/drm/tegra/dc.c > @@ -655,8 +655,8 @@ static struct drm_plane *tegra_dc_primary_plane_create(struct drm_device *drm, > > err = drm_universal_plane_init(drm, &plane->base, possible_crtcs, > &tegra_primary_plane_funcs, formats, > - num_formats, DRM_PLANE_TYPE_PRIMARY, > - NULL); > + num_formats, NULL, > + DRM_PLANE_TYPE_PRIMARY, NULL); > if (err < 0) { > kfree(plane); > return ERR_PTR(err); > @@ -821,8 +821,8 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm, > > err = drm_universal_plane_init(drm, &plane->base, 1 << dc->pipe, > &tegra_cursor_plane_funcs, formats, > - num_formats, DRM_PLANE_TYPE_CURSOR, > - NULL); > + num_formats, NULL, > + DRM_PLANE_TYPE_CURSOR, NULL); > if (err < 0) { > kfree(plane); > return ERR_PTR(err); > @@ -883,8 +883,8 @@ static struct drm_plane *tegra_dc_overlay_plane_create(struct drm_device *drm, > > err = drm_universal_plane_init(drm, &plane->base, 1 << dc->pipe, > &tegra_overlay_plane_funcs, formats, > - num_formats, DRM_PLANE_TYPE_OVERLAY, > - NULL); > + num_formats, NULL, > + DRM_PLANE_TYPE_OVERLAY, NULL); > if (err < 0) { > kfree(plane); > return ERR_PTR(err); > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c > index d34cd5393a9b..74b5e7afd6e9 100644 > --- a/drivers/gpu/drm/vc4/vc4_plane.c > +++ b/drivers/gpu/drm/vc4/vc4_plane.c > @@ -861,7 +861,7 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev, > ret = drm_universal_plane_init(dev, plane, 0, > &vc4_plane_funcs, > formats, num_formats, > - type, NULL); > + NULL, type, NULL); > > drm_plane_helper_add(plane, &vc4_plane_helper_funcs); > > diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c > index adcdbd0abef6..71ba455af915 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_plane.c > +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c > @@ -298,7 +298,7 @@ struct drm_plane *virtio_gpu_plane_init(struct virtio_gpu_device *vgdev, > ret = drm_universal_plane_init(dev, plane, 1 << index, > &virtio_gpu_plane_funcs, > formats, nformats, > - type, NULL); > + NULL, type, NULL); > if (ret) > goto err_plane_init; > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c > index d3987bcf53f8..6f0bf6f9c6f8 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c > @@ -439,7 +439,7 @@ static int vmw_ldu_init(struct vmw_private *dev_priv, unsigned unit) > 0, &vmw_ldu_plane_funcs, > vmw_primary_plane_formats, > ARRAY_SIZE(vmw_primary_plane_formats), > - DRM_PLANE_TYPE_PRIMARY, NULL); > + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); > if (ret) { > DRM_ERROR("Failed to initialize primary plane"); > goto err_free; > @@ -454,7 +454,7 @@ static int vmw_ldu_init(struct vmw_private *dev_priv, unsigned unit) > 0, &vmw_ldu_cursor_funcs, > vmw_cursor_plane_formats, > ARRAY_SIZE(vmw_cursor_plane_formats), > - DRM_PLANE_TYPE_CURSOR, NULL); > + NULL, DRM_PLANE_TYPE_CURSOR, NULL); > if (ret) { > DRM_ERROR("Failed to initialize cursor plane"); > drm_plane_cleanup(&ldu->base.primary); > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c > index 8d7dc9def7c2..42780c9cb90f 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c > @@ -622,7 +622,7 @@ static int vmw_sou_init(struct vmw_private *dev_priv, unsigned unit) > 0, &vmw_sou_plane_funcs, > vmw_primary_plane_formats, > ARRAY_SIZE(vmw_primary_plane_formats), > - DRM_PLANE_TYPE_PRIMARY, NULL); > + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); > if (ret) { > DRM_ERROR("Failed to initialize primary plane"); > goto err_free; > @@ -637,7 +637,7 @@ static int vmw_sou_init(struct vmw_private *dev_priv, unsigned unit) > 0, &vmw_sou_cursor_funcs, > vmw_cursor_plane_formats, > ARRAY_SIZE(vmw_cursor_plane_formats), > - DRM_PLANE_TYPE_CURSOR, NULL); > + NULL, DRM_PLANE_TYPE_CURSOR, NULL); > if (ret) { > DRM_ERROR("Failed to initialize cursor plane"); > drm_plane_cleanup(&sou->base.primary); > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c > index bad31bdf09b6..f18fb966ce9c 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c > @@ -1456,7 +1456,7 @@ static int vmw_stdu_init(struct vmw_private *dev_priv, unsigned unit) > 0, &vmw_stdu_plane_funcs, > vmw_primary_plane_formats, > ARRAY_SIZE(vmw_primary_plane_formats), > - DRM_PLANE_TYPE_PRIMARY, NULL); > + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); > if (ret) { > DRM_ERROR("Failed to initialize primary plane"); > goto err_free; > @@ -1471,7 +1471,7 @@ static int vmw_stdu_init(struct vmw_private *dev_priv, unsigned unit) > 0, &vmw_stdu_cursor_funcs, > vmw_cursor_plane_formats, > ARRAY_SIZE(vmw_cursor_plane_formats), > - DRM_PLANE_TYPE_CURSOR, NULL); > + NULL, DRM_PLANE_TYPE_CURSOR, NULL); > if (ret) { > DRM_ERROR("Failed to initialize cursor plane"); > drm_plane_cleanup(&stdu->base.primary); > diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c > index d646ac931663..ea29fee01f7d 100644 > --- a/drivers/gpu/drm/zte/zx_plane.c > +++ b/drivers/gpu/drm/zte/zx_plane.c > @@ -539,7 +539,7 @@ int zx_plane_init(struct drm_device *drm, struct zx_plane *zplane, > > ret = drm_universal_plane_init(drm, plane, VOU_CRTC_MASK, > &zx_plane_funcs, formats, format_count, > - type, NULL); > + NULL, type, NULL); > if (ret) { > DRM_DEV_ERROR(dev, "failed to init universal plane: %d\n", ret); > return ret; > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h > index 9ab3e7044812..4011d5527f40 100644 > --- a/include/drm/drm_plane.h > +++ b/include/drm/drm_plane.h > @@ -392,6 +392,20 @@ struct drm_plane_funcs { > */ > void (*atomic_print_state)(struct drm_printer *p, > const struct drm_plane_state *state); > + > + /** > + * @format_mod_supported: > + * > + * This optional hook is used for the DRM to determine if the given > + * format/modifier combination is valid for the plane. This allows the > + * DRM to generate the correct format bitmask (which formats apply to > + * which modifier). > + * > + * True if the given modifier is valid for that format on the plane. > + * False otherwise. > + */ > + bool (*format_mod_supported)(struct drm_plane *plane, uint32_t format, > + uint64_t modifier); This additional function is not used by anything in this patch. Why include it here? > }; > > /** > @@ -487,6 +501,10 @@ struct drm_plane { > unsigned int format_count; > bool format_default; > > + uint32_t *formats; Who's using formats in this patch? > + uint64_t *modifiers; > + unsigned int modifier_count; > + > struct drm_crtc *crtc; > struct drm_framebuffer *fb; > > @@ -527,13 +545,14 @@ struct drm_plane { > > #define obj_to_plane(x) container_of(x, struct drm_plane, base) > > -__printf(8, 9) > +__printf(9, 10) > int drm_universal_plane_init(struct drm_device *dev, > struct drm_plane *plane, > uint32_t possible_crtcs, > const struct drm_plane_funcs *funcs, > const uint32_t *formats, > unsigned int format_count, > + const uint64_t *format_modifiers, > enum drm_plane_type type, > const char *name, ...); > int drm_plane_init(struct drm_device *dev, > diff --git a/include/drm/drm_simple_kms_helper.h b/include/drm/drm_simple_kms_helper.h > index 2d36538e4a17..6d9adbb46293 100644 > --- a/include/drm/drm_simple_kms_helper.h > +++ b/include/drm/drm_simple_kms_helper.h > @@ -122,6 +122,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev, > struct drm_simple_display_pipe *pipe, > const struct drm_simple_display_pipe_funcs *funcs, > const uint32_t *formats, unsigned int format_count, > + const uint64_t *format_modifiers, > struct drm_connector *connector); > > #endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */ > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > index 995c8f9c692f..ddabbeeebdec 100644 > --- a/include/uapi/drm/drm_fourcc.h > +++ b/include/uapi/drm/drm_fourcc.h > @@ -184,6 +184,8 @@ extern "C" { > #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06 > /* add more to the end as needed */ > > +#define DRM_FORMAT_RESERVED ((1ULL << 56) - 1) > + > #define fourcc_mod_code(vendor, val) \ > ((((__u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 0x00ffffffffffffffULL)) > > @@ -196,6 +198,15 @@ extern "C" { > */ > > /* > + * Invalid Modifier > + * > + * This modifier can be used as a sentinel to terminate list, or to initialize a > + * variable with an invalid modifier. It might also be used to report an error > + * back to userspace for certain APIs. > + */ > +#define DRM_FORMAT_MOD_INVALID fourcc_mod_code(NONE, DRM_FORMAT_RESERVED) > + > +/* > * Linear Layout > * > * Just plain linear layout. Note that this is different from no specifying any > -- > 2.12.2 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel I understand you want to add support for modifiers into planes and it is something that I'm interested in, but I don't think this patch is doing it well enough. Best regards, Liviu
Hi Liviu, On 3 May 2017 at 11:34, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote: >> v2: A minor addition from Daniel > > You are *really* pushing your luck by not Cc-ing *any* of the maintainers of > the drivers you touch. You do want reviews, don't you? Ouch. I'm very sure Ben does want reviews, but he mainly works in Mesa where you can rely on the list rather than having to CC everyone individually. It was a mistake, so please be more gentle with him; your whole mail comes across as quite hostile to me. > Finally, the questions I should've started with: why the change? What are you trying to > achieve? It is not very clear from the commit message at all. It does deserve a much better commit message than what it has, but as he is on holiday for the rest of the week, I can answer. Currently, we advertise which formats each plane is capable of displaying. In order for userspace to be able to allocate tiled/compressed buffers for scanout, we want userspace to be able to discover which modifiers each plane supports as well. >> @@ -105,6 +108,28 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, >> return -ENOMEM; >> } >> >> + /* First driver to need more than 64 formats needs to fix this */ >> + if (WARN_ON(format_count > 64)) >> + return -EINVAL; > > What is the link between format_count and format modifiers? Why are you introducing > this artificial restriction on the format_count? Also, there doesn't seem to be any > check if format_modifier_count == format_count. What happens when they don't match? Inside the blob, each modifier carries a bitmask of formats (specified by index) that the modifier applies to, i.e. with: .formats = { ARGB8888, XRGB8888, RGB565 }, a modifier which applied only to the 32-bit formats would specify a bitmask of 0x3. The uABI supports this just fine, but the internal plumbing does not yet, because no-one supports more than 64 formats. >> + >> + if (format_modifiers) { >> + const uint64_t *temp_modifiers = format_modifiers; >> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID) >> + format_modifier_count++; >> + } >> + >> + plane->modifier_count = format_modifier_count; > > Why do you need to remember this? It is not used anywhere else! It is used to populate the blob in a later patch! Cheers, Daniel
On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote: > Hi Liviu, > > On 3 May 2017 at 11:34, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > > On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote: > >> v2: A minor addition from Daniel > > > > You are *really* pushing your luck by not Cc-ing *any* of the maintainers of > > the drivers you touch. You do want reviews, don't you? > > Ouch. I'm very sure Ben does want reviews, but he mainly works in Mesa > where you can rely on the list rather than having to CC everyone > individually. It was a mistake, so please be more gentle with him; > your whole mail comes across as quite hostile to me. Sorry, I'm not trying to be hostile. Try to read the bolded words with a long (southern USA) intonation as if to draw attention to them. You will see that it is just pointing to two facts: he does not warn anyone about the changes and he is not making the patchset that obviously critical by having a commit message that implies everyone should pay attention to it. So he is really hoping to be lucky to get reviews (or doesn't actively seek them). > > > Finally, the questions I should've started with: why the change? What are you trying to > > achieve? It is not very clear from the commit message at all. > > It does deserve a much better commit message than what it has, but as > he is on holiday for the rest of the week, I can answer. Currently, we > advertise which formats each plane is capable of displaying. In order > for userspace to be able to allocate tiled/compressed buffers for > scanout, we want userspace to be able to discover which modifiers each > plane supports as well. I get the overall goal. We need/want something similar for Mali DP and AFBC buffers. What I don't understand is the current aproach (but I've found from Brian that somehow I've missed the long discussion(s) around the subject). I was hoping to learn from the commit message why he thinks the introduction of this code is the right way of doing it. And the IRC logs seem to imply that he is mostly doing something that others have agreed upon and he doesn't really care about the approach as long as it ticks the "supported by intel driver" box. > > >> @@ -105,6 +108,28 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, > >> return -ENOMEM; > >> } > >> > >> + /* First driver to need more than 64 formats needs to fix this */ > >> + if (WARN_ON(format_count > 64)) > >> + return -EINVAL; > > > > What is the link between format_count and format modifiers? Why are you introducing > > this artificial restriction on the format_count? Also, there doesn't seem to be any > > check if format_modifier_count == format_count. What happens when they don't match? > > Inside the blob, each modifier carries a bitmask of formats (specified > by index) that the modifier applies to, i.e. with: > .formats = { ARGB8888, XRGB8888, RGB565 }, > > a modifier which applied only to the 32-bit formats would specify a > bitmask of 0x3. The uABI supports this just fine, but the internal > plumbing does not yet, because no-one supports more than 64 formats. Yeah, still doesn't answer the question. Maybe if the comment said something like: "When building format modifiers bitmap we only have space to map up to 64 formats. Check that the driver is not trying to exceed that." then it would've been more obvious why the check is needed and also why one doesn't care about format_modifier_count. To explain my mindset: the way the patch series was formatted and the way I've read it initially I did not realised that the idea is to build a bitmask. Nothing in this patch alludes to that so I assumed there was a 1:1 relationship between format modifiers and format. > > >> + > >> + if (format_modifiers) { > >> + const uint64_t *temp_modifiers = format_modifiers; > >> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID) > >> + format_modifier_count++; > >> + } > >> + > >> + plane->modifier_count = format_modifier_count; > > > > Why do you need to remember this? It is not used anywhere else! > > It is used to populate the blob in a later patch! I cannot find that patch. Nothing in the 3 patches uses that. Have a look! Best regards, Liviu > > Cheers, > Daniel
On 3 May 2017 at 15:07, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote: >> On 3 May 2017 at 11:34, Liviu Dudau <Liviu.Dudau@arm.com> wrote: >> > You are *really* pushing your luck by not Cc-ing *any* of the maintainers of >> > the drivers you touch. You do want reviews, don't you? >> >> Ouch. I'm very sure Ben does want reviews, but he mainly works in Mesa >> where you can rely on the list rather than having to CC everyone >> individually. It was a mistake, so please be more gentle with him; >> your whole mail comes across as quite hostile to me. > > Sorry, I'm not trying to be hostile. Try to read the bolded words with a long > (southern USA) intonation as if to draw attention to them. You will see that > it is just pointing to two facts: he does not warn anyone about the changes and > he is not making the patchset that obviously critical by having a commit message > that implies everyone should pay attention to it. So he is really hoping to be > lucky to get reviews (or doesn't actively seek them). You could achieve the same thing with absolutely no room for misinterpretation: 'Hi Ben. Not sure if you weren't aware or forgot, but when posting patches here, please use get_maintainers.pl to build a CC list. I only really saw this by luck, and other maintainers have probably missed this too.' >> It does deserve a much better commit message than what it has, but as >> he is on holiday for the rest of the week, I can answer. Currently, we >> advertise which formats each plane is capable of displaying. In order >> for userspace to be able to allocate tiled/compressed buffers for >> scanout, we want userspace to be able to discover which modifiers each >> plane supports as well. > > I get the overall goal. We need/want something similar for Mali DP and AFBC buffers. > What I don't understand is the current aproach (but I've found from Brian that somehow > I've missed the long discussion(s) around the subject). I was hoping to learn > from the commit message why he thinks the introduction of this code is the right > way of doing it. And the IRC logs seem to imply that he is mostly doing something > that others have agreed upon and he doesn't really care about the approach as long > as it ticks the "supported by intel driver" box. Or, with another interpretation, he thinks the various approaches of doing it are all equally good. He took guidance from a couple of userspace developers (Weston, ChromeOS), a Freedreno developer and also I believe an AFBC developer, to end up where he is now, which he still thinks is fine. In doing so, he's been through several iterations, always modifying the driver to suit. I think that's a pretty good way to do development of new uABI, if you ask me. (And again, I have trouble reading your last sentence as anything other than hostile.)
On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote: > On 3 May 2017 at 15:07, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote: > >> On 3 May 2017 at 11:34, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > >> > You are *really* pushing your luck by not Cc-ing *any* of the maintainers of > >> > the drivers you touch. You do want reviews, don't you? > >> > >> Ouch. I'm very sure Ben does want reviews, but he mainly works in Mesa > >> where you can rely on the list rather than having to CC everyone > >> individually. It was a mistake, so please be more gentle with him; > >> your whole mail comes across as quite hostile to me. > > > > Sorry, I'm not trying to be hostile. Try to read the bolded words with a long > > (southern USA) intonation as if to draw attention to them. You will see that > > it is just pointing to two facts: he does not warn anyone about the changes and > > he is not making the patchset that obviously critical by having a commit message > > that implies everyone should pay attention to it. So he is really hoping to be > > lucky to get reviews (or doesn't actively seek them). > > You could achieve the same thing with absolutely no room for > misinterpretation: 'Hi Ben. Not sure if you weren't aware or forgot, > but when posting patches here, please use get_maintainers.pl to build > a CC list. I only really saw this by luck, and other maintainers have > probably missed this too.' Agree, probably a better tone. Apologies to Ben for the initial form. I'm sure he will do the correct thing next time. > > >> It does deserve a much better commit message than what it has, but as > >> he is on holiday for the rest of the week, I can answer. Currently, we > >> advertise which formats each plane is capable of displaying. In order > >> for userspace to be able to allocate tiled/compressed buffers for > >> scanout, we want userspace to be able to discover which modifiers each > >> plane supports as well. > > > > I get the overall goal. We need/want something similar for Mali DP and AFBC buffers. > > What I don't understand is the current aproach (but I've found from Brian that somehow > > I've missed the long discussion(s) around the subject). I was hoping to learn > > from the commit message why he thinks the introduction of this code is the right > > way of doing it. And the IRC logs seem to imply that he is mostly doing something > > that others have agreed upon and he doesn't really care about the approach as long > > as it ticks the "supported by intel driver" box. > > Or, with another interpretation, he thinks the various approaches of > doing it are all equally good. He took guidance from a couple of > userspace developers (Weston, ChromeOS), a Freedreno developer and > also I believe an AFBC developer, to end up where he is now, which he > still thinks is fine. In doing so, he's been through several > iterations, always modifying the driver to suit. I think that's a > pretty good way to do development of new uABI, if you ask me. (And > again, I have trouble reading your last sentence as anything other > than hostile.) I am getting the message. You think I am too strong here, so I'm going to back off. Also look forward to see the next version where he takes into account the technical comments that I have sent. Best regards, Liviu
On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote: > On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote: > > On 3 May 2017 at 15:07, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote: > > >> It does deserve a much better commit message than what it has, but as > > >> he is on holiday for the rest of the week, I can answer. Currently, we > > >> advertise which formats each plane is capable of displaying. In order > > >> for userspace to be able to allocate tiled/compressed buffers for > > >> scanout, we want userspace to be able to discover which modifiers each > > >> plane supports as well. > > > > > > I get the overall goal. We need/want something similar for Mali DP and AFBC buffers. > > > What I don't understand is the current aproach (but I've found from Brian that somehow > > > I've missed the long discussion(s) around the subject). I was hoping to learn > > > from the commit message why he thinks the introduction of this code is the right > > > way of doing it. And the IRC logs seem to imply that he is mostly doing something > > > that others have agreed upon and he doesn't really care about the approach as long > > > as it ticks the "supported by intel driver" box. > > > > Or, with another interpretation, he thinks the various approaches of > > doing it are all equally good. He took guidance from a couple of > > userspace developers (Weston, ChromeOS), a Freedreno developer and > > also I believe an AFBC developer, to end up where he is now, which he > > still thinks is fine. In doing so, he's been through several > > iterations, always modifying the driver to suit. I think that's a > > pretty good way to do development of new uABI, if you ask me. (And > > again, I have trouble reading your last sentence as anything other > > than hostile.) > > I am getting the message. You think I am too strong here, so I'm going to back off. > Also look forward to see the next version where he takes into account the technical > comments that I have sent. Just to make it really clear: Google has an implementation for AFBC using exactly this scheme for cros. The only reasons it's not floating around here in upstream is that one of the critical pieces is missing (*hint*, *hint* you really want an open mail driver ...). But besides that, it works perfectly fine for arm render compression format too. -Daniel
On Wed, May 03, 2017 at 06:45:05PM +0200, Daniel Vetter wrote: > On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote: > > On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote: > > > On 3 May 2017 at 15:07, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > > > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote: > > > >> It does deserve a much better commit message than what it has, but as > > > >> he is on holiday for the rest of the week, I can answer. Currently, we > > > >> advertise which formats each plane is capable of displaying. In order > > > >> for userspace to be able to allocate tiled/compressed buffers for > > > >> scanout, we want userspace to be able to discover which modifiers each > > > >> plane supports as well. > > > > > > > > I get the overall goal. We need/want something similar for Mali DP and AFBC buffers. > > > > What I don't understand is the current aproach (but I've found from Brian that somehow > > > > I've missed the long discussion(s) around the subject). I was hoping to learn > > > > from the commit message why he thinks the introduction of this code is the right > > > > way of doing it. And the IRC logs seem to imply that he is mostly doing something > > > > that others have agreed upon and he doesn't really care about the approach as long > > > > as it ticks the "supported by intel driver" box. > > > > > > Or, with another interpretation, he thinks the various approaches of > > > doing it are all equally good. He took guidance from a couple of > > > userspace developers (Weston, ChromeOS), a Freedreno developer and > > > also I believe an AFBC developer, to end up where he is now, which he > > > still thinks is fine. In doing so, he's been through several > > > iterations, always modifying the driver to suit. I think that's a > > > pretty good way to do development of new uABI, if you ask me. (And > > > again, I have trouble reading your last sentence as anything other > > > than hostile.) > > > > I am getting the message. You think I am too strong here, so I'm going to back off. > > Also look forward to see the next version where he takes into account the technical > > comments that I have sent. > > Just to make it really clear: Google has an implementation for AFBC using > exactly this scheme for cros. The only reasons it's not floating around > here in upstream is that one of the critical pieces is missing (*hint*, > *hint* you really want an open mail driver ...). <tongue_in_cheek> Don't know about open _mail_ drivers but there are plenty of open mail apps that one can use </tongue_in_cheek> Joke aside, the Mali GPU *kernel* driver *is* open source. Just not in the mainline and not enough for what you want. But I'm not the right person to fix all that. And GPU is not the only IP capable of producing AFBC data, so there might be another driver in the making that will be open source. Best regards, Liviu > But besides that, it works > perfectly fine for arm render compression format too. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Hi Ben, [auto build test WARNING on drm/drm-next] [also build test WARNING on next-20170503] [cannot apply to v4.11] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170504-004955 base: git://people.freedesktop.org/~airlied/linux.git drm-next reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/init.h:1: warning: no structured comments found kernel/sched/core.c:2085: warning: No description found for parameter 'rf' kernel/sched/core.c:2085: warning: Excess function parameter 'cookie' description in 'try_to_wake_up_local' include/linux/kthread.h:26: warning: Excess function parameter '...' description in 'kthread_create' kernel/sys.c:1: warning: no structured comments found include/linux/device.h:969: warning: No description found for parameter 'dma_ops' drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found include/linux/iio/iio.h:597: warning: No description found for parameter 'trig_readonly' include/linux/iio/trigger.h:151: warning: No description found for parameter 'indio_dev' include/linux/iio/trigger.h:151: warning: No description found for parameter 'trig' include/linux/device.h:970: warning: No description found for parameter 'dma_ops' drivers/regulator/core.c:1467: warning: Excess function parameter 'ret' description in 'regulator_dev_lookup' include/drm/drm_drv.h:524: warning: No description found for parameter 'set_busid' include/drm/drm_drv.h:524: warning: No description found for parameter 'irq_handler' include/drm/drm_drv.h:524: warning: No description found for parameter 'irq_preinstall' include/drm/drm_drv.h:524: warning: No description found for parameter 'irq_postinstall' include/drm/drm_drv.h:524: warning: No description found for parameter 'irq_uninstall' include/drm/drm_drv.h:524: warning: No description found for parameter 'debugfs_init' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_open_object' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_close_object' include/drm/drm_drv.h:524: warning: No description found for parameter 'prime_handle_to_fd' include/drm/drm_drv.h:524: warning: No description found for parameter 'prime_fd_to_handle' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_prime_export' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_prime_import' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_prime_pin' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_prime_unpin' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_prime_res_obj' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_prime_get_sg_table' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_prime_import_sg_table' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_prime_vmap' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_prime_vunmap' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_prime_mmap' include/drm/drm_drv.h:524: warning: No description found for parameter 'gem_vm_ops' include/drm/drm_drv.h:524: warning: No description found for parameter 'major' include/drm/drm_drv.h:524: warning: No description found for parameter 'minor' include/drm/drm_drv.h:524: warning: No description found for parameter 'patchlevel' include/drm/drm_drv.h:524: warning: No description found for parameter 'name' include/drm/drm_drv.h:524: warning: No description found for parameter 'desc' include/drm/drm_drv.h:524: warning: No description found for parameter 'date' include/drm/drm_drv.h:524: warning: No description found for parameter 'driver_features' include/drm/drm_drv.h:524: warning: No description found for parameter 'ioctls' include/drm/drm_drv.h:524: warning: No description found for parameter 'num_ioctls' include/drm/drm_drv.h:524: warning: No description found for parameter 'fops' >> include/drm/drm_plane.h:545: warning: No description found for parameter 'formats' >> include/drm/drm_plane.h:545: warning: No description found for parameter 'modifiers' >> include/drm/drm_plane.h:545: warning: No description found for parameter 'modifier_count' include/drm/drm_color_mgmt.h:1: warning: no structured comments found drivers/gpu/drm/drm_plane_helper.c:403: warning: No description found for parameter 'ctx' drivers/gpu/drm/drm_plane_helper.c:404: warning: No description found for parameter 'ctx' drivers/gpu/drm/i915/intel_lpe_audio.c:350: warning: No description found for parameter 'dp_output' drivers/gpu/drm/i915/intel_lpe_audio.c:350: warning: No description found for parameter 'link_rate' drivers/gpu/drm/i915/intel_lpe_audio.c:351: warning: No description found for parameter 'dp_output' drivers/gpu/drm/i915/intel_lpe_audio.c:351: warning: No description found for parameter 'link_rate' drivers/media/dvb-core/dvb_frontend.h:677: warning: No description found for parameter 'refcount' Documentation/core-api/assoc_array.rst:13: WARNING: Enumerated list ends without a blank line; unexpected unindent. Documentation/doc-guide/sphinx.rst:126: ERROR: Unknown target name: "sphinx c domain". kernel/sched/fair.c:7616: WARNING: Inline emphasis start-string without end-string. kernel/time/timer.c:1200: ERROR: Unexpected indentation. kernel/time/timer.c:1202: ERROR: Unexpected indentation. kernel/time/timer.c:1203: WARNING: Block quote ends without a blank line; unexpected unindent. include/linux/wait.h:122: WARNING: Block quote ends without a blank line; unexpected unindent. include/linux/wait.h:125: ERROR: Unexpected indentation. include/linux/wait.h:127: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/time/hrtimer.c:990: WARNING: Block quote ends without a blank line; unexpected unindent. kernel/signal.c:322: WARNING: Inline literal start-string without end-string. include/linux/iio/iio.h:219: ERROR: Unexpected indentation. include/linux/iio/iio.h:220: WARNING: Block quote ends without a blank line; unexpected unindent. include/linux/iio/iio.h:226: WARNING: Definition list ends without a blank line; unexpected unindent. drivers/iio/industrialio-core.c:638: ERROR: Unknown target name: "iio_val". drivers/iio/industrialio-core.c:645: ERROR: Unknown target name: "iio_val". drivers/message/fusion/mptbase.c:5051: WARNING: Definition list ends without a blank line; unexpected unindent. drivers/tty/serial/serial_core.c:1898: WARNING: Definition list ends without a blank line; unexpected unindent. include/linux/regulator/driver.h:271: ERROR: Unknown target name: "regulator_regmap_x_voltage". include/linux/spi/spi.h:369: ERROR: Unexpected indentation. drivers/usb/core/message.c:478: ERROR: Unexpected indentation. drivers/usb/core/message.c:479: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/driver-api/usb.rst:623: ERROR: Unknown target name: "usb_type". Documentation/driver-api/usb.rst:623: ERROR: Unknown target name: "usb_dir". Documentation/driver-api/usb.rst:623: ERROR: Unknown target name: "usb_recip". Documentation/driver-api/usb.rst:689: ERROR: Unknown target name: "usbdevfs_urb_type". drivers/gpu/drm/drm_scdc_helper.c:203: ERROR: Unexpected indentation. drivers/gpu/drm/drm_scdc_helper.c:204: WARNING: Block quote ends without a blank line; unexpected unindent. drivers/gpu/drm/drm_ioctl.c:690: WARNING: Definition list ends without a blank line; unexpected unindent. Documentation/gpu/todo.rst:111: ERROR: Unknown target name: "drm_fb". sound/soc/soc-core.c:2670: ERROR: Unknown target name: "snd_soc_daifmt". sound/core/jack.c:312: ERROR: Unknown target name: "snd_jack_btn". Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected vim +/formats +545 include/drm/drm_plane.h c9e42b72 Daniel Vetter 2017-03-28 529 * c9e42b72 Daniel Vetter 2017-03-28 530 * Current atomic state for this plane. c9e42b72 Daniel Vetter 2017-03-28 531 * c9e42b72 Daniel Vetter 2017-03-28 532 * This is protected by @mutex. Note that nonblocking atomic commits c9e42b72 Daniel Vetter 2017-03-28 533 * access the current plane state without taking locks. Either by going c9e42b72 Daniel Vetter 2017-03-28 534 * through the &struct drm_atomic_state pointers, see c9e42b72 Daniel Vetter 2017-03-28 535 * for_each_plane_in_state(), for_each_oldnew_plane_in_state(), c9e42b72 Daniel Vetter 2017-03-28 536 * for_each_old_plane_in_state() and for_each_new_plane_in_state(). Or c9e42b72 Daniel Vetter 2017-03-28 537 * through careful ordering of atomic commit operations as implemented c9e42b72 Daniel Vetter 2017-03-28 538 * in the atomic helpers, see &struct drm_crtc_commit. c9e42b72 Daniel Vetter 2017-03-28 539 */ 43968d7b Daniel Vetter 2016-09-21 540 struct drm_plane_state *state; 43968d7b Daniel Vetter 2016-09-21 541 43968d7b Daniel Vetter 2016-09-21 542 struct drm_property *zpos_property; d138dd3c Ville Syrjälä 2016-09-26 543 struct drm_property *rotation_property; 43968d7b Daniel Vetter 2016-09-21 544 }; 43968d7b Daniel Vetter 2016-09-21 @545 43968d7b Daniel Vetter 2016-09-21 546 #define obj_to_plane(x) container_of(x, struct drm_plane, base) 43968d7b Daniel Vetter 2016-09-21 547 e934c6c4 Ben Widawsky 2017-05-02 548 __printf(9, 10) 43968d7b Daniel Vetter 2016-09-21 549 int drm_universal_plane_init(struct drm_device *dev, 43968d7b Daniel Vetter 2016-09-21 550 struct drm_plane *plane, 5cd57a46 Tomi Valkeinen 2016-12-02 551 uint32_t possible_crtcs, 43968d7b Daniel Vetter 2016-09-21 552 const struct drm_plane_funcs *funcs, 43968d7b Daniel Vetter 2016-09-21 553 const uint32_t *formats, :::::: The code at line 545 was first introduced by commit :::::: 43968d7b806d7a7e021261294c583a216fddf0e5 drm: Extract drm_plane.[hc] :::::: TO: Daniel Vetter <daniel.vetter@ffwll.ch> :::::: CC: Sean Paul <seanpaul@chromium.org> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi Ben,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170503]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170504-004955
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All warnings (new ones prefixed by >>):
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c: In function 'tinydrm_display_pipe_init':
>> drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c:227:8: warning: passing argument 6 of 'drm_simple_display_pipe_init' from incompatible pointer type
ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
^
In file included from include/drm/tinydrm/tinydrm.h:15:0,
from drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c:13:
include/drm/drm_simple_kms_helper.h:121:5: note: expected 'const uint64_t *' but argument is of type 'struct drm_connector *'
int drm_simple_display_pipe_init(struct drm_device *dev,
^
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c:227:8: error: too few arguments to function 'drm_simple_display_pipe_init'
ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
^
In file included from include/drm/tinydrm/tinydrm.h:15:0,
from drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c:13:
include/drm/drm_simple_kms_helper.h:121:5: note: declared here
int drm_simple_display_pipe_init(struct drm_device *dev,
^
vim +/drm_simple_display_pipe_init +227 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
fa201ac2 Noralf Trønnes 2017-01-22 211 *mode_copy = *mode;
fa201ac2 Noralf Trønnes 2017-01-22 212 ret = tinydrm_rotate_mode(mode_copy, rotation);
fa201ac2 Noralf Trønnes 2017-01-22 213 if (ret) {
fa201ac2 Noralf Trønnes 2017-01-22 214 DRM_ERROR("Illegal rotation value %u\n", rotation);
fa201ac2 Noralf Trønnes 2017-01-22 215 return -EINVAL;
fa201ac2 Noralf Trønnes 2017-01-22 216 }
fa201ac2 Noralf Trønnes 2017-01-22 217
fa201ac2 Noralf Trønnes 2017-01-22 218 drm->mode_config.min_width = mode_copy->hdisplay;
fa201ac2 Noralf Trønnes 2017-01-22 219 drm->mode_config.max_width = mode_copy->hdisplay;
fa201ac2 Noralf Trønnes 2017-01-22 220 drm->mode_config.min_height = mode_copy->vdisplay;
fa201ac2 Noralf Trønnes 2017-01-22 221 drm->mode_config.max_height = mode_copy->vdisplay;
fa201ac2 Noralf Trønnes 2017-01-22 222
fa201ac2 Noralf Trønnes 2017-01-22 223 connector = tinydrm_connector_create(drm, mode_copy, connector_type);
fa201ac2 Noralf Trønnes 2017-01-22 224 if (IS_ERR(connector))
fa201ac2 Noralf Trønnes 2017-01-22 225 return PTR_ERR(connector);
fa201ac2 Noralf Trønnes 2017-01-22 226
fa201ac2 Noralf Trønnes 2017-01-22 @227 ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
fa201ac2 Noralf Trønnes 2017-01-22 228 format_count, connector);
fa201ac2 Noralf Trønnes 2017-01-22 229 if (ret)
fa201ac2 Noralf Trønnes 2017-01-22 230 return ret;
fa201ac2 Noralf Trønnes 2017-01-22 231
fa201ac2 Noralf Trønnes 2017-01-22 232 return 0;
fa201ac2 Noralf Trønnes 2017-01-22 233 }
fa201ac2 Noralf Trønnes 2017-01-22 234 EXPORT_SYMBOL(tinydrm_display_pipe_init);
:::::: The code at line 227 was first introduced by commit
:::::: fa201ac2c61f51d9abdaffdf994d5780dcb51703 drm: Add DRM support for tiny LCD displays
:::::: TO: Noralf Trønnes <noralf@tronnes.org>
:::::: CC: Noralf Trønnes <noralf@tronnes.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On 17-05-03 14:45:26, Daniel Stone wrote: >Hi Liviu, > >On 3 May 2017 at 11:34, Liviu Dudau <Liviu.Dudau@arm.com> wrote: >> On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote: >>> v2: A minor addition from Daniel >> >> You are *really* pushing your luck by not Cc-ing *any* of the maintainers of >> the drivers you touch. You do want reviews, don't you? > >Ouch. I'm very sure Ben does want reviews, but he mainly works in Mesa >where you can rely on the list rather than having to CC everyone >individually. It was a mistake, so please be more gentle with him; >your whole mail comes across as quite hostile to me. > It was not a mistake. The whole point of a mailing list is so that people can participate without needing to Cc every individual. dri-devel has been the location, and while many hardware vendors have set up their own list, dri-devel is still the mailing list for patches like this. There are a ridiculous number of DRM driver maintainers. There isn't even an easy way to script extracting all the relevant people from MAINTAINERS (happy to be corrected on that) I don't believe anybody Cc's them all, ever - but normally there isn't such a globally invasive patch. I'm sorry Liviu you obviously felt slighted. I did Cc the Intel mailing list because my implementation for this was on Intel. >> Finally, the questions I should've started with: why the change? What are you trying to >> achieve? It is not very clear from the commit message at all. > >It does deserve a much better commit message than what it has, but as >he is on holiday for the rest of the week, I can answer. Currently, we >advertise which formats each plane is capable of displaying. In order >for userspace to be able to allocate tiled/compressed buffers for >scanout, we want userspace to be able to discover which modifiers each >plane supports as well. > >>> @@ -105,6 +108,28 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, >>> return -ENOMEM; >>> } >>> >>> + /* First driver to need more than 64 formats needs to fix this */ >>> + if (WARN_ON(format_count > 64)) >>> + return -EINVAL; >> >> What is the link between format_count and format modifiers? Why are you introducing >> this artificial restriction on the format_count? Also, there doesn't seem to be any >> check if format_modifier_count == format_count. What happens when they don't match? > >Inside the blob, each modifier carries a bitmask of formats (specified >by index) that the modifier applies to, i.e. with: > .formats = { ARGB8888, XRGB8888, RGB565 }, > >a modifier which applied only to the 32-bit formats would specify a >bitmask of 0x3. The uABI supports this just fine, but the internal >plumbing does not yet, because no-one supports more than 64 formats. > >>> + >>> + if (format_modifiers) { >>> + const uint64_t *temp_modifiers = format_modifiers; >>> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID) >>> + format_modifier_count++; >>> + } >>> + >>> + plane->modifier_count = format_modifier_count; >> >> Why do you need to remember this? It is not used anywhere else! > >It is used to populate the blob in a later patch! > >Cheers, >Daniel I'm back now. Thanks Daniel for summing it up for me.
On 17-05-03 18:30:07, Liviu Dudau wrote: >On Wed, May 03, 2017 at 06:45:05PM +0200, Daniel Vetter wrote: >> On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote: >> > On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote: >> > > On 3 May 2017 at 15:07, Liviu Dudau <Liviu.Dudau@arm.com> wrote: >> > > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote: >> > > >> It does deserve a much better commit message than what it has, but as >> > > >> he is on holiday for the rest of the week, I can answer. Currently, we >> > > >> advertise which formats each plane is capable of displaying. In order >> > > >> for userspace to be able to allocate tiled/compressed buffers for >> > > >> scanout, we want userspace to be able to discover which modifiers each >> > > >> plane supports as well. >> > > > >> > > > I get the overall goal. We need/want something similar for Mali DP and AFBC buffers. >> > > > What I don't understand is the current aproach (but I've found from Brian that somehow >> > > > I've missed the long discussion(s) around the subject). I was hoping to learn >> > > > from the commit message why he thinks the introduction of this code is the right >> > > > way of doing it. And the IRC logs seem to imply that he is mostly doing something >> > > > that others have agreed upon and he doesn't really care about the approach as long >> > > > as it ticks the "supported by intel driver" box. >> > > >> > > Or, with another interpretation, he thinks the various approaches of >> > > doing it are all equally good. He took guidance from a couple of >> > > userspace developers (Weston, ChromeOS), a Freedreno developer and >> > > also I believe an AFBC developer, to end up where he is now, which he >> > > still thinks is fine. In doing so, he's been through several >> > > iterations, always modifying the driver to suit. I think that's a >> > > pretty good way to do development of new uABI, if you ask me. (And >> > > again, I have trouble reading your last sentence as anything other >> > > than hostile.) >> > >> > I am getting the message. You think I am too strong here, so I'm going to back off. >> > Also look forward to see the next version where he takes into account the technical >> > comments that I have sent. >> >> Just to make it really clear: Google has an implementation for AFBC using >> exactly this scheme for cros. The only reasons it's not floating around >> here in upstream is that one of the critical pieces is missing (*hint*, >> *hint* you really want an open mail driver ...). > ><tongue_in_cheek> >Don't know about open _mail_ drivers but there are plenty of open mail apps that one can use ></tongue_in_cheek> > >Joke aside, the Mali GPU *kernel* driver *is* open source. Just not in the mainline and >not enough for what you want. But I'm not the right person to fix all that. > >And GPU is not the only IP capable of producing AFBC data, so there might be another driver >in the making that will be open source. > >Best regards, >Liviu > >> But besides that, it works >> perfectly fine for arm render compression format too. >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch > >-- So are we good with patch 1, sorry if I missed any real valid changes I need to make, but can we please capture that here.
On Wed, May 10, 2017 at 09:34:40AM -0700, Ben Widawsky wrote: > On 17-05-03 18:30:07, Liviu Dudau wrote: > > On Wed, May 03, 2017 at 06:45:05PM +0200, Daniel Vetter wrote: > > > On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote: > > > > On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote: > > > > > On 3 May 2017 at 15:07, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > > > > > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote: > > > > > >> It does deserve a much better commit message than what it has, but as > > > > > >> he is on holiday for the rest of the week, I can answer. Currently, we > > > > > >> advertise which formats each plane is capable of displaying. In order > > > > > >> for userspace to be able to allocate tiled/compressed buffers for > > > > > >> scanout, we want userspace to be able to discover which modifiers each > > > > > >> plane supports as well. > > > > > > > > > > > > I get the overall goal. We need/want something similar for Mali DP and AFBC buffers. > > > > > > What I don't understand is the current aproach (but I've found from Brian that somehow > > > > > > I've missed the long discussion(s) around the subject). I was hoping to learn > > > > > > from the commit message why he thinks the introduction of this code is the right > > > > > > way of doing it. And the IRC logs seem to imply that he is mostly doing something > > > > > > that others have agreed upon and he doesn't really care about the approach as long > > > > > > as it ticks the "supported by intel driver" box. > > > > > > > > > > Or, with another interpretation, he thinks the various approaches of > > > > > doing it are all equally good. He took guidance from a couple of > > > > > userspace developers (Weston, ChromeOS), a Freedreno developer and > > > > > also I believe an AFBC developer, to end up where he is now, which he > > > > > still thinks is fine. In doing so, he's been through several > > > > > iterations, always modifying the driver to suit. I think that's a > > > > > pretty good way to do development of new uABI, if you ask me. (And > > > > > again, I have trouble reading your last sentence as anything other > > > > > than hostile.) > > > > > > > > I am getting the message. You think I am too strong here, so I'm going to back off. > > > > Also look forward to see the next version where he takes into account the technical > > > > comments that I have sent. > > > > > > Just to make it really clear: Google has an implementation for AFBC using > > > exactly this scheme for cros. The only reasons it's not floating around > > > here in upstream is that one of the critical pieces is missing (*hint*, > > > *hint* you really want an open mail driver ...). > > > > <tongue_in_cheek> > > Don't know about open _mail_ drivers but there are plenty of open mail apps that one can use > > </tongue_in_cheek> > > > > Joke aside, the Mali GPU *kernel* driver *is* open source. Just not in the mainline and > > not enough for what you want. But I'm not the right person to fix all that. > > > > And GPU is not the only IP capable of producing AFBC data, so there might be another driver > > in the making that will be open source. > > > > Best regards, > > Liviu > > > > > But besides that, it works > > > perfectly fine for arm render compression format too. > > > -Daniel > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > > > -- > > So are we good with patch 1, sorry if I missed any real valid changes I need to > make, but can we please capture that here. Sure, - documentation needs to use the actual macro name: DRM_FORMAT_MOD_INVALID - drm_universal_plane_init comment about first driver with > 64 formats could do with some verbose explanation on why ("because we encode each format as a bit in the format_modifiers field and we have only reserved 64 bits for that") - most (all?) drivers are passing NULL as the format_modifier pointer to drm_universal_plane_init() which makes me wonder if it is not better to have a different function for drivers that want to pass a non-NULL format_modifier. - plane->modifier_count is never used - memcpy()-ing the format_modifiers in drm_universal_plane_init doesn't check for NULL even if that is what most drivers pass on when they call the function. - some extraneous empty lines could be trimmed - format_mod_supported function is not used in 1/3 patch, you can introduce it in the patch that actually uses it - drm_plane's formats field doesn't look used either. You can look in the first reply to your 1/3 patch if you want the details. Best regards, Liviu > > -- > Ben Widawsky, Intel Open Source Technology Center > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 17-05-10 18:24:52, Liviu Dudau wrote: >On Wed, May 10, 2017 at 09:34:40AM -0700, Ben Widawsky wrote: >> On 17-05-03 18:30:07, Liviu Dudau wrote: >> > On Wed, May 03, 2017 at 06:45:05PM +0200, Daniel Vetter wrote: >> > > On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote: >> > > > On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote: >> > > > > On 3 May 2017 at 15:07, Liviu Dudau <Liviu.Dudau@arm.com> wrote: >> > > > > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote: >> > > > > >> It does deserve a much better commit message than what it has, but as >> > > > > >> he is on holiday for the rest of the week, I can answer. Currently, we >> > > > > >> advertise which formats each plane is capable of displaying. In order >> > > > > >> for userspace to be able to allocate tiled/compressed buffers for >> > > > > >> scanout, we want userspace to be able to discover which modifiers each >> > > > > >> plane supports as well. >> > > > > > >> > > > > > I get the overall goal. We need/want something similar for Mali DP and AFBC buffers. >> > > > > > What I don't understand is the current aproach (but I've found from Brian that somehow >> > > > > > I've missed the long discussion(s) around the subject). I was hoping to learn >> > > > > > from the commit message why he thinks the introduction of this code is the right >> > > > > > way of doing it. And the IRC logs seem to imply that he is mostly doing something >> > > > > > that others have agreed upon and he doesn't really care about the approach as long >> > > > > > as it ticks the "supported by intel driver" box. >> > > > > >> > > > > Or, with another interpretation, he thinks the various approaches of >> > > > > doing it are all equally good. He took guidance from a couple of >> > > > > userspace developers (Weston, ChromeOS), a Freedreno developer and >> > > > > also I believe an AFBC developer, to end up where he is now, which he >> > > > > still thinks is fine. In doing so, he's been through several >> > > > > iterations, always modifying the driver to suit. I think that's a >> > > > > pretty good way to do development of new uABI, if you ask me. (And >> > > > > again, I have trouble reading your last sentence as anything other >> > > > > than hostile.) >> > > > >> > > > I am getting the message. You think I am too strong here, so I'm going to back off. >> > > > Also look forward to see the next version where he takes into account the technical >> > > > comments that I have sent. >> > > >> > > Just to make it really clear: Google has an implementation for AFBC using >> > > exactly this scheme for cros. The only reasons it's not floating around >> > > here in upstream is that one of the critical pieces is missing (*hint*, >> > > *hint* you really want an open mail driver ...). >> > >> > <tongue_in_cheek> >> > Don't know about open _mail_ drivers but there are plenty of open mail apps that one can use >> > </tongue_in_cheek> >> > >> > Joke aside, the Mali GPU *kernel* driver *is* open source. Just not in the mainline and >> > not enough for what you want. But I'm not the right person to fix all that. >> > >> > And GPU is not the only IP capable of producing AFBC data, so there might be another driver >> > in the making that will be open source. >> > >> > Best regards, >> > Liviu >> > >> > > But besides that, it works >> > > perfectly fine for arm render compression format too. >> > > -Daniel >> > > -- >> > > Daniel Vetter >> > > Software Engineer, Intel Corporation >> > > http://blog.ffwll.ch >> > >> > -- >> >> So are we good with patch 1, sorry if I missed any real valid changes I need to >> make, but can we please capture that here. > >Sure, > Thanks. Reordered your comments a bit... >- documentation needs to use the actual macro name: DRM_FORMAT_MOD_INVALID Okay. It originally wasn't this way because it forces the sentence to be two lines, but I've changed it. >- some extraneous empty lines could be trimmed I think I got them all.. >- drm_universal_plane_init comment about first driver with > 64 formats could do > with some verbose explanation on why ("because we encode each format as a bit > in the format_modifiers field and we have only reserved 64 bits for that") >- most (all?) drivers are passing NULL as the format_modifier pointer to > drm_universal_plane_init() which makes me wonder if it is not better to have a > different function for drivers that want to pass a non-NULL format_modifier. I can wrap this, that might be the best way and then I wouldn't need to touch the other drivers. Here is the relevant part of the diff: I'm fine with that if other people are. It only is the way it is because Kristian originally did this for GET_PLANE2. +__printf(9, 10) +int drm_universal_plane_init_with_modifiers(struct drm_device *dev, + struct drm_plane *plane, + uint32_t possible_crtcs, + const struct drm_plane_funcs *funcs, + const uint32_t *formats, + unsigned int format_count, + const uint64_t *format_modifiers, + enum drm_plane_type type, + const char *name, ...); __printf(8, 9) -int drm_universal_plane_init(struct drm_device *dev, - struct drm_plane *plane, - uint32_t possible_crtcs, - const struct drm_plane_funcs *funcs, - const uint32_t *formats, - unsigned int format_count, - enum drm_plane_type type, - const char *name, ...); +static inline int +drm_universal_plane_init(struct drm_device *dev, + struct drm_plane *plane, + uint32_t possible_crtcs, + const struct drm_plane_funcs *funcs, + const uint32_t *formats, + unsigned int format_count, + enum drm_plane_type type, + const char *name, ...) +{ + va_list ap; + int ret; + + va_start(ap, name); + ret = drm_universal_plane_init_with_modifiers(dev, plane, + possible_crtcs, funcs, + formats, format_count, + NULL, type, name, ap); + va_end(ap); + return ret; +} + >- plane->modifier_count is never used >- memcpy()-ing the format_modifiers in drm_universal_plane_init doesn't check for > NULL even if that is what most drivers pass on when they call the function. >- format_mod_supported function is not used in 1/3 patch, you can introduce it > in the patch that actually uses it >- drm_plane's formats field doesn't look used either. > Regarding the unused fields, they are used in later patches by the implementation. I specifically split out this so that we can deal with all the DRM hardware specific driver changes in one [supposed to be] trivial patch. Generally I agree that introducing fields without using them is not very useful to reviewers, but I consider this a special case. I see two primary reasons for this: 1. It made rebase easier (remember, this series is > 6 months old), and as new DRM drivers were added, it made a nice simple patch to change. 2. Easy to spot kbuild failures/resolutions. 3. Review should be trivial for all the other hardware people. If they don't care about modifiers, they can pretty much ignore the patch entire. >You can look in the first reply to your 1/3 patch if you want the details. > >Best regards, >Liviu > >> >> -- >> Ben Widawsky, Intel Open Source Technology Center >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >-- >==================== >| I would like to | >| fix the world, | >| but they're not | >| giving me the | > \ source code! / > --------------- > ¯\_(ツ)_/¯
On Wed, May 10, 2017 at 12:33:15PM -0700, Ben Widawsky wrote: > On 17-05-10 18:24:52, Liviu Dudau wrote: > >On Wed, May 10, 2017 at 09:34:40AM -0700, Ben Widawsky wrote: > >>On 17-05-03 18:30:07, Liviu Dudau wrote: > >>> On Wed, May 03, 2017 at 06:45:05PM +0200, Daniel Vetter wrote: > >>> > On Wed, May 03, 2017 at 03:52:23PM +0100, Liviu Dudau wrote: > >>> > > On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote: > >>> > > > On 3 May 2017 at 15:07, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > >>> > > > > On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote: > >>> > > > >> It does deserve a much better commit message than what it has, but as > >>> > > > >> he is on holiday for the rest of the week, I can answer. Currently, we > >>> > > > >> advertise which formats each plane is capable of displaying. In order > >>> > > > >> for userspace to be able to allocate tiled/compressed buffers for > >>> > > > >> scanout, we want userspace to be able to discover which modifiers each > >>> > > > >> plane supports as well. > >>> > > > > > >>> > > > > I get the overall goal. We need/want something similar for Mali DP and AFBC buffers. > >>> > > > > What I don't understand is the current aproach (but I've found from Brian that somehow > >>> > > > > I've missed the long discussion(s) around the subject). I was hoping to learn > >>> > > > > from the commit message why he thinks the introduction of this code is the right > >>> > > > > way of doing it. And the IRC logs seem to imply that he is mostly doing something > >>> > > > > that others have agreed upon and he doesn't really care about the approach as long > >>> > > > > as it ticks the "supported by intel driver" box. > >>> > > > > >>> > > > Or, with another interpretation, he thinks the various approaches of > >>> > > > doing it are all equally good. He took guidance from a couple of > >>> > > > userspace developers (Weston, ChromeOS), a Freedreno developer and > >>> > > > also I believe an AFBC developer, to end up where he is now, which he > >>> > > > still thinks is fine. In doing so, he's been through several > >>> > > > iterations, always modifying the driver to suit. I think that's a > >>> > > > pretty good way to do development of new uABI, if you ask me. (And > >>> > > > again, I have trouble reading your last sentence as anything other > >>> > > > than hostile.) > >>> > > > >>> > > I am getting the message. You think I am too strong here, so I'm going to back off. > >>> > > Also look forward to see the next version where he takes into account the technical > >>> > > comments that I have sent. > >>> > > >>> > Just to make it really clear: Google has an implementation for AFBC using > >>> > exactly this scheme for cros. The only reasons it's not floating around > >>> > here in upstream is that one of the critical pieces is missing (*hint*, > >>> > *hint* you really want an open mail driver ...). > >>> > >>> <tongue_in_cheek> > >>> Don't know about open _mail_ drivers but there are plenty of open mail apps that one can use > >>> </tongue_in_cheek> > >>> > >>> Joke aside, the Mali GPU *kernel* driver *is* open source. Just not in the mainline and > >>> not enough for what you want. But I'm not the right person to fix all that. > >>> > >>> And GPU is not the only IP capable of producing AFBC data, so there might be another driver > >>> in the making that will be open source. > >>> > >>> Best regards, > >>> Liviu > >>> > >>> > But besides that, it works > >>> > perfectly fine for arm render compression format too. > >>> > -Daniel > >>> > -- > >>> > Daniel Vetter > >>> > Software Engineer, Intel Corporation > >>> > http://blog.ffwll.ch > >>> > >>> -- > >> > >>So are we good with patch 1, sorry if I missed any real valid changes I need to > >>make, but can we please capture that here. > > > >Sure, > > > > Thanks. Reordered your comments a bit... > > >- documentation needs to use the actual macro name: DRM_FORMAT_MOD_INVALID > > Okay. It originally wasn't this way because it forces the sentence to be two > lines, but I've changed it. > > >- some extraneous empty lines could be trimmed > > I think I got them all.. > > >- drm_universal_plane_init comment about first driver with > 64 formats could do > > with some verbose explanation on why ("because we encode each format as a bit > > in the format_modifiers field and we have only reserved 64 bits for that") > > > >- most (all?) drivers are passing NULL as the format_modifier pointer to > > drm_universal_plane_init() which makes me wonder if it is not better to have a > > different function for drivers that want to pass a non-NULL format_modifier. > > I can wrap this, that might be the best way and then I wouldn't need to touch > the other drivers. Here is the relevant part of the diff: > > I'm fine with that if other people are. It only is the way it is because > Kristian originally did this for GET_PLANE2. > > +__printf(9, 10) > +int drm_universal_plane_init_with_modifiers(struct drm_device *dev, > + struct drm_plane *plane, > + uint32_t possible_crtcs, > + const struct drm_plane_funcs *funcs, > + const uint32_t *formats, > + unsigned int format_count, > + const uint64_t *format_modifiers, > + enum drm_plane_type type, > + const char *name, ...); > __printf(8, 9) > -int drm_universal_plane_init(struct drm_device *dev, > - struct drm_plane *plane, > - uint32_t possible_crtcs, > - const struct drm_plane_funcs *funcs, > - const uint32_t *formats, > - unsigned int format_count, > - enum drm_plane_type type, > - const char *name, ...); > +static inline int > +drm_universal_plane_init(struct drm_device *dev, > + struct drm_plane *plane, > + uint32_t possible_crtcs, > + const struct drm_plane_funcs *funcs, > + const uint32_t *formats, > + unsigned int format_count, > + enum drm_plane_type type, > + const char *name, ...) > +{ > + va_list ap; > + int ret; > + > + va_start(ap, name); > + ret = drm_universal_plane_init_with_modifiers(dev, plane, > + possible_crtcs, funcs, > + formats, format_count, > + NULL, type, name, ap); > + va_end(ap); > + return ret; > +} > + I guess the patchset's delta is going to go down significantly with this if i915 is the only driver that explicitly calls the new function. I'll wait until next revision to see, but I have a bias towards smaller patches. > > > >- plane->modifier_count is never used > >- memcpy()-ing the format_modifiers in drm_universal_plane_init doesn't check for > > NULL even if that is what most drivers pass on when they call the function. What about this one? > >- format_mod_supported function is not used in 1/3 patch, you can introduce it > > in the patch that actually uses it > >- drm_plane's formats field doesn't look used either. > > > > Regarding the unused fields, they are used in later patches by the > implementation. I specifically split out this so that we can deal with all the > DRM hardware specific driver changes in one [supposed to be] trivial patch. > Generally I agree that introducing fields without using them is not very useful > to reviewers, but I consider this a special case. OK, but plane->modifier_count is not used by any of your patches. OTOH, plane->modifiers is allocated, memcpy-ed once into from the drm_universal_plane_init() parameter and never used again until kfreed. There seems to be at least one place where you could use plane->modifiers without having to pass the format_modifiers again as parameter (in create_in_format_blob() in 2/3). Best regards, Liviu > > I see two primary reasons for this: > 1. It made rebase easier (remember, this series is > 6 months old), and as new > DRM drivers were added, it made a nice simple patch to change. > 2. Easy to spot kbuild failures/resolutions. > 3. Review should be trivial for all the other hardware people. If they don't > care about modifiers, they can pretty much ignore the patch entire. > > >You can look in the first reply to your 1/3 patch if you want the details. > > > >Best regards, > >Liviu > > > >> > >>-- > >>Ben Widawsky, Intel Open Source Technology Center > >>_______________________________________________ > >>dri-devel mailing list > >>dri-devel@lists.freedesktop.org > >>https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > >-- > >==================== > >| I would like to | > >| fix the world, | > >| but they're not | > >| giving me the | > >\ source code! / > > --------------- > > ¯\_(ツ)_/¯ > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c b/drivers/gpu/drm/arc/arcpgu_crtc.c index ad9a95916f1f..cd8a24c7c67d 100644 --- a/drivers/gpu/drm/arc/arcpgu_crtc.c +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c @@ -218,6 +218,7 @@ static struct drm_plane *arc_pgu_plane_init(struct drm_device *drm) ret = drm_universal_plane_init(drm, plane, 0xff, &arc_pgu_plane_funcs, formats, ARRAY_SIZE(formats), + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); if (ret) return ERR_PTR(ret); diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c index 798a3cc480a2..0caa03ae8708 100644 --- a/drivers/gpu/drm/arm/hdlcd_crtc.c +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c @@ -303,6 +303,7 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device *drm) ret = drm_universal_plane_init(drm, plane, 0xff, &hdlcd_plane_funcs, formats, ARRAY_SIZE(formats), + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); if (ret) { devm_kfree(drm->dev, plane); diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c index 814fda23cead..b156610c68a5 100644 --- a/drivers/gpu/drm/arm/malidp_planes.c +++ b/drivers/gpu/drm/arm/malidp_planes.c @@ -400,7 +400,7 @@ int malidp_de_planes_init(struct drm_device *drm) DRM_PLANE_TYPE_OVERLAY; ret = drm_universal_plane_init(drm, &plane->base, crtcs, &malidp_de_plane_funcs, formats, - n, plane_type, NULL); + n, NULL, plane_type, NULL); if (ret < 0) goto cleanup; diff --git a/drivers/gpu/drm/armada/armada_crtc.c b/drivers/gpu/drm/armada/armada_crtc.c index 4fe19fde84f9..ea48ef88f0e4 100644 --- a/drivers/gpu/drm/armada/armada_crtc.c +++ b/drivers/gpu/drm/armada/armada_crtc.c @@ -1269,6 +1269,7 @@ static int armada_drm_crtc_create(struct drm_device *drm, struct device *dev, &armada_primary_plane_funcs, armada_primary_formats, ARRAY_SIZE(armada_primary_formats), + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); if (ret) { kfree(primary); diff --git a/drivers/gpu/drm/armada/armada_overlay.c b/drivers/gpu/drm/armada/armada_overlay.c index 424e465ff407..0054144287ae 100644 --- a/drivers/gpu/drm/armada/armada_overlay.c +++ b/drivers/gpu/drm/armada/armada_overlay.c @@ -460,6 +460,7 @@ int armada_overlay_plane_create(struct drm_device *dev, unsigned long crtcs) &armada_ovl_plane_funcs, armada_ovl_formats, ARRAY_SIZE(armada_ovl_formats), + NULL, DRM_PLANE_TYPE_OVERLAY, NULL); if (ret) { kfree(dplane); diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c index 29cc10d053eb..b5c6cf2d8c36 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c @@ -1058,7 +1058,9 @@ static int atmel_hlcdc_plane_create(struct drm_device *dev, ret = drm_universal_plane_init(dev, &plane->base, 0, &layer_plane_funcs, desc->formats->formats, - desc->formats->nformats, type, NULL); + desc->formats->nformats, + NULL, + type, NULL); if (ret) return ret; diff --git a/drivers/gpu/drm/drm_modeset_helper.c b/drivers/gpu/drm/drm_modeset_helper.c index 2b33825f2f93..9cb1eede0b4d 100644 --- a/drivers/gpu/drm/drm_modeset_helper.c +++ b/drivers/gpu/drm/drm_modeset_helper.c @@ -124,6 +124,7 @@ static struct drm_plane *create_primary_plane(struct drm_device *dev) &drm_primary_helper_funcs, safe_modeset_formats, ARRAY_SIZE(safe_modeset_formats), + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); if (ret) { kfree(primary); diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index fedd4d60d9cd..286e183891e5 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -70,6 +70,7 @@ static unsigned int drm_num_planes(struct drm_device *dev) * @funcs: callbacks for the new plane * @formats: array of supported formats (DRM_FORMAT\_\*) * @format_count: number of elements in @formats + * @format_modifiers: array of struct drm_format modifiers terminated by INVALID * @type: type of plane (overlay, primary, cursor) * @name: printf style format string for the plane name, or NULL for default name * @@ -82,10 +83,12 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, uint32_t possible_crtcs, const struct drm_plane_funcs *funcs, const uint32_t *formats, unsigned int format_count, + const uint64_t *format_modifiers, enum drm_plane_type type, const char *name, ...) { struct drm_mode_config *config = &dev->mode_config; + unsigned int format_modifier_count = 0; int ret; ret = drm_mode_object_add(dev, &plane->base, DRM_MODE_OBJECT_PLANE); @@ -105,6 +108,28 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, return -ENOMEM; } + /* First driver to need more than 64 formats needs to fix this */ + if (WARN_ON(format_count > 64)) + return -EINVAL; + + if (format_modifiers) { + const uint64_t *temp_modifiers = format_modifiers; + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID) + format_modifier_count++; + } + + plane->modifier_count = format_modifier_count; + plane->modifiers = kmalloc_array(format_modifier_count, + sizeof(format_modifiers[0]), + GFP_KERNEL); + + if (format_modifier_count && !plane->modifiers) { + DRM_DEBUG_KMS("out of memory when allocating plane\n"); + kfree(plane->format_types); + drm_mode_object_unregister(dev, &plane->base); + return -ENOMEM; + } + if (name) { va_list ap; @@ -117,12 +142,15 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, } if (!plane->name) { kfree(plane->format_types); + kfree(plane->modifiers); drm_mode_object_unregister(dev, &plane->base); return -ENOMEM; } memcpy(plane->format_types, formats, format_count * sizeof(uint32_t)); plane->format_count = format_count; + memcpy(plane->modifiers, format_modifiers, + format_modifier_count * sizeof(format_modifiers[0])); plane->possible_crtcs = possible_crtcs; plane->type = type; @@ -205,7 +233,8 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane *plane, type = is_primary ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY; return drm_universal_plane_init(dev, plane, possible_crtcs, funcs, - formats, format_count, type, NULL); + formats, format_count, + NULL, type, NULL); } EXPORT_SYMBOL(drm_plane_init); @@ -224,6 +253,7 @@ void drm_plane_cleanup(struct drm_plane *plane) drm_modeset_lock_fini(&plane->mutex); kfree(plane->format_types); + kfree(plane->modifiers); drm_mode_object_unregister(dev, &plane->base); BUG_ON(list_empty(&plane->head)); diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c b/drivers/gpu/drm/drm_simple_kms_helper.c index e084f9f8ca66..949f0ab0e267 100644 --- a/drivers/gpu/drm/drm_simple_kms_helper.c +++ b/drivers/gpu/drm/drm_simple_kms_helper.c @@ -193,6 +193,7 @@ EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge); * @funcs: callbacks for the display pipe (optional) * @formats: array of supported formats (DRM_FORMAT\_\*) * @format_count: number of elements in @formats + * @format_modifiers: array of formats modifiers * @connector: connector to attach and register (optional) * * Sets up a display pipeline which consist of a really simple @@ -213,6 +214,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev, struct drm_simple_display_pipe *pipe, const struct drm_simple_display_pipe_funcs *funcs, const uint32_t *formats, unsigned int format_count, + const uint64_t *format_modifiers, struct drm_connector *connector) { struct drm_encoder *encoder = &pipe->encoder; @@ -227,6 +229,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev, ret = drm_universal_plane_init(dev, plane, 0, &drm_simple_kms_plane_funcs, formats, format_count, + format_modifiers, DRM_PLANE_TYPE_PRIMARY, NULL); if (ret) return ret; diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c index c2f17f30afab..75d4928dd196 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c @@ -284,7 +284,7 @@ int exynos_plane_init(struct drm_device *dev, &exynos_plane_funcs, config->pixel_formats, config->num_pixel_formats, - config->type, NULL); + NULL, config->type, NULL); if (err) { DRM_ERROR("failed to initialize plane\n"); return err; diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c index 0a20723aa6e1..9554b245746e 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c @@ -224,7 +224,7 @@ struct drm_plane *fsl_dcu_drm_primary_create_plane(struct drm_device *dev) &fsl_dcu_drm_plane_funcs, fsl_dcu_drm_plane_formats, ARRAY_SIZE(fsl_dcu_drm_plane_formats), - DRM_PLANE_TYPE_PRIMARY, NULL); + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); if (ret) { kfree(primary); primary = NULL; diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c index 59542bddc980..339e914cbaa3 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c @@ -181,6 +181,7 @@ static struct drm_plane *hibmc_plane_init(struct hibmc_drm_private *priv) ret = drm_universal_plane_init(dev, plane, 1, &hibmc_plane_funcs, channel_formats1, ARRAY_SIZE(channel_formats1), + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); if (ret) { diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index c96c228a9898..1acb8af12246 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -909,7 +909,7 @@ static int ade_plane_init(struct drm_device *dev, struct ade_plane *aplane, return ret; ret = drm_universal_plane_init(dev, &aplane->base, 1, &ade_plane_funcs, - fmts, fmts_cnt, type, NULL); + fmts, fmts_cnt, NULL, type, NULL); if (ret) { DRM_ERROR("fail to init plane, ch=%d\n", aplane->ch); return ret; diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3617927af269..d52bd05a017d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13516,6 +13516,8 @@ intel_legacy_cursor_update(struct drm_plane *plane, src_x, src_y, src_w, src_h, ctx); } + + static const struct drm_plane_funcs intel_cursor_plane_funcs = { .update_plane = intel_legacy_cursor_update, .disable_plane = drm_atomic_helper_disable_plane, @@ -13594,18 +13596,21 @@ intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe) ret = drm_universal_plane_init(&dev_priv->drm, &primary->base, 0, &intel_plane_funcs, intel_primary_formats, num_formats, + NULL, DRM_PLANE_TYPE_PRIMARY, "plane 1%c", pipe_name(pipe)); else if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv)) ret = drm_universal_plane_init(&dev_priv->drm, &primary->base, 0, &intel_plane_funcs, intel_primary_formats, num_formats, + NULL, DRM_PLANE_TYPE_PRIMARY, "primary %c", pipe_name(pipe)); else ret = drm_universal_plane_init(&dev_priv->drm, &primary->base, 0, &intel_plane_funcs, intel_primary_formats, num_formats, + NULL, DRM_PLANE_TYPE_PRIMARY, "plane %c", plane_name(primary->plane)); if (ret) @@ -13776,7 +13781,7 @@ intel_cursor_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe) 0, &intel_cursor_plane_funcs, intel_cursor_formats, ARRAY_SIZE(intel_cursor_formats), - DRM_PLANE_TYPE_CURSOR, + NULL, DRM_PLANE_TYPE_CURSOR, "cursor %c", pipe_name(pipe)); if (ret) goto fail; diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index f7d431427115..053802dd08c1 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1165,13 +1165,13 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv, ret = drm_universal_plane_init(&dev_priv->drm, &intel_plane->base, possible_crtcs, &intel_plane_funcs, plane_formats, num_plane_formats, - DRM_PLANE_TYPE_OVERLAY, + NULL, DRM_PLANE_TYPE_OVERLAY, "plane %d%c", plane + 2, pipe_name(pipe)); else ret = drm_universal_plane_init(&dev_priv->drm, &intel_plane->base, possible_crtcs, &intel_plane_funcs, plane_formats, num_plane_formats, - DRM_PLANE_TYPE_OVERLAY, + NULL, DRM_PLANE_TYPE_OVERLAY, "sprite %c", sprite_name(pipe, plane)); if (ret) goto fail; diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c index d63e853a0300..6c708c3b1cdc 100644 --- a/drivers/gpu/drm/imx/ipuv3-plane.c +++ b/drivers/gpu/drm/imx/ipuv3-plane.c @@ -718,8 +718,8 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev, struct ipu_soc *ipu, ret = drm_universal_plane_init(dev, &ipu_plane->base, possible_crtcs, &ipu_plane_funcs, ipu_plane_formats, - ARRAY_SIZE(ipu_plane_formats), type, - NULL); + ARRAY_SIZE(ipu_plane_formats), + NULL, type, NULL); if (ret) { DRM_ERROR("failed to initialize plane\n"); kfree(ipu_plane); diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c index e405e89ed5e5..bec6d14dd070 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c @@ -173,7 +173,7 @@ int mtk_plane_init(struct drm_device *dev, struct drm_plane *plane, err = drm_universal_plane_init(dev, plane, possible_crtcs, &mtk_plane_funcs, formats, - ARRAY_SIZE(formats), type, NULL); + ARRAY_SIZE(formats), NULL, type, NULL); if (err) { DRM_ERROR("failed to initialize plane\n"); return err; diff --git a/drivers/gpu/drm/meson/meson_plane.c b/drivers/gpu/drm/meson/meson_plane.c index a32d3b6e2e12..17e96fa47868 100644 --- a/drivers/gpu/drm/meson/meson_plane.c +++ b/drivers/gpu/drm/meson/meson_plane.c @@ -223,6 +223,7 @@ int meson_plane_create(struct meson_drm *priv) &meson_plane_funcs, supported_drm_formats, ARRAY_SIZE(supported_drm_formats), + NULL, DRM_PLANE_TYPE_PRIMARY, "meson_primary_plane"); drm_plane_helper_add(plane, &meson_plane_helper_funcs); diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c index 53619d07677e..8f3417e45d4e 100644 --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c @@ -398,7 +398,7 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev, type = private_plane ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY; ret = drm_universal_plane_init(dev, plane, 0xff, &mdp4_plane_funcs, mdp4_plane->formats, mdp4_plane->nformats, - type, NULL); + NULL, type, NULL); if (ret) goto fail; diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c index a38c5fe6cc19..a815bc0e78d1 100644 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c @@ -1140,12 +1140,12 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev, ret = drm_universal_plane_init(dev, plane, 0xff, &mdp5_cursor_plane_funcs, mdp5_plane->formats, mdp5_plane->nformats, - type, NULL); + NULL, type, NULL); else ret = drm_universal_plane_init(dev, plane, 0xff, &mdp5_plane_funcs, mdp5_plane->formats, mdp5_plane->nformats, - type, NULL); + NULL, type, NULL); if (ret) goto fail; diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index d1b9c34c7c00..3ee3784a54f4 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -190,7 +190,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long flags) } ret = drm_simple_display_pipe_init(drm, &mxsfb->pipe, &mxsfb_funcs, - mxsfb_formats, ARRAY_SIZE(mxsfb_formats), + mxsfb_formats, ARRAY_SIZE(mxsfb_formats), NULL, 0, &mxsfb->connector); if (ret < 0) { dev_err(drm->dev, "Cannot setup simple display pipe\n"); diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c index 0e58537352fe..dde71be463f8 100644 --- a/drivers/gpu/drm/nouveau/nv50_display.c +++ b/drivers/gpu/drm/nouveau/nv50_display.c @@ -1084,8 +1084,9 @@ nv50_wndw_ctor(const struct nv50_wndw_func *func, struct drm_device *dev, wndw->func = func; wndw->dmac = dmac; - ret = drm_universal_plane_init(dev, &wndw->plane, 0, &nv50_wndw, format, - nformat, type, "%s-%d", name, index); + ret = drm_universal_plane_init(dev, &wndw->plane, 0, &nv50_wndw, + format, nformat, NULL, + type, "%s-%d", name, index); if (ret) return ret; diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c index 9168154d749e..9b8341d77468 100644 --- a/drivers/gpu/drm/omapdrm/omap_plane.c +++ b/drivers/gpu/drm/omapdrm/omap_plane.c @@ -370,7 +370,8 @@ struct drm_plane *omap_plane_init(struct drm_device *dev, ret = drm_universal_plane_init(dev, plane, possible_crtcs, &omap_plane_funcs, omap_plane->formats, - omap_plane->nformats, type, NULL); + omap_plane->nformats, + NULL, type, NULL); if (ret < 0) goto error; diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index 058340a002c2..fcf1d2034449 100644 --- a/drivers/gpu/drm/qxl/qxl_display.c +++ b/drivers/gpu/drm/qxl/qxl_display.c @@ -788,7 +788,7 @@ static struct drm_plane *qxl_create_plane(struct qxl_device *qdev, err = drm_universal_plane_init(&qdev->ddev, plane, possible_crtcs, funcs, formats, num_formats, - type, NULL); + NULL, type, NULL); if (err) goto free_plane; diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c b/drivers/gpu/drm/rcar-du/rcar_du_plane.c index dcde6288da6c..2b02eccbfb70 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c @@ -743,8 +743,8 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp) ret = drm_universal_plane_init(rcdu->ddev, &plane->plane, crtcs, &rcar_du_plane_funcs, formats, - ARRAY_SIZE(formats), type, - NULL); + ARRAY_SIZE(formats), + NULL, type, NULL); if (ret < 0) return ret; diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index b0ff304ce3dc..e0c054f9b57a 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c @@ -368,8 +368,8 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp) 1 << vsp->index, &rcar_du_vsp_plane_funcs, formats_kms, - ARRAY_SIZE(formats_kms), type, - NULL); + ARRAY_SIZE(formats_kms), + NULL, type, NULL); if (ret < 0) return ret; diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index 3f7a82d1e095..d0cf57de9afc 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -1280,7 +1280,7 @@ static int vop_create_crtc(struct vop *vop) 0, &vop_plane_funcs, win_data->phy->data_formats, win_data->phy->nformats, - win_data->type, NULL); + NULL, win_data->type, NULL); if (ret) { DRM_DEV_ERROR(vop->dev, "failed to init plane %d\n", ret); @@ -1319,7 +1319,7 @@ static int vop_create_crtc(struct vop *vop) &vop_plane_funcs, win_data->phy->data_formats, win_data->phy->nformats, - win_data->type, NULL); + NULL, win_data->type, NULL); if (ret) { DRM_DEV_ERROR(vop->dev, "failed to init overlay %d\n", ret); diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c index cca75bddb9ad..97c25e204bf4 100644 --- a/drivers/gpu/drm/sti/sti_cursor.c +++ b/drivers/gpu/drm/sti/sti_cursor.c @@ -393,7 +393,7 @@ struct drm_plane *sti_cursor_create(struct drm_device *drm_dev, &sti_cursor_plane_helpers_funcs, cursor_supported_formats, ARRAY_SIZE(cursor_supported_formats), - DRM_PLANE_TYPE_CURSOR, NULL); + NULL, DRM_PLANE_TYPE_CURSOR, NULL); if (res) { DRM_ERROR("Failed to initialize universal plane\n"); goto err_plane; diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c index 88f16cdf6a4b..70391603c12d 100644 --- a/drivers/gpu/drm/sti/sti_gdp.c +++ b/drivers/gpu/drm/sti/sti_gdp.c @@ -932,7 +932,7 @@ struct drm_plane *sti_gdp_create(struct drm_device *drm_dev, &sti_gdp_plane_helpers_funcs, gdp_supported_formats, ARRAY_SIZE(gdp_supported_formats), - type, NULL); + NULL, type, NULL); if (res) { DRM_ERROR("Failed to initialize universal plane\n"); goto err; diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c index 66f843148ef7..9a1ff352820d 100644 --- a/drivers/gpu/drm/sti/sti_hqvdp.c +++ b/drivers/gpu/drm/sti/sti_hqvdp.c @@ -1296,7 +1296,7 @@ static struct drm_plane *sti_hqvdp_create(struct drm_device *drm_dev, &sti_hqvdp_plane_helpers_funcs, hqvdp_supported_formats, ARRAY_SIZE(hqvdp_supported_formats), - DRM_PLANE_TYPE_OVERLAY, NULL); + NULL, DRM_PLANE_TYPE_OVERLAY, NULL); if (res) { DRM_ERROR("Failed to initialize universal plane\n"); return NULL; diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c index f26bde5b9117..2d9f8d01ac2e 100644 --- a/drivers/gpu/drm/sun4i/sun4i_layer.c +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c @@ -115,7 +115,7 @@ static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm, ret = drm_universal_plane_init(drm, &layer->plane, 0, &sun4i_backend_layer_funcs, plane->formats, plane->nformats, - plane->type, NULL); + NULL, plane->type, NULL); if (ret) { dev_err(drm->dev, "Couldn't initialize layer\n"); return ERR_PTR(ret); diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 95b373f739f2..0380edd054ac 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -655,8 +655,8 @@ static struct drm_plane *tegra_dc_primary_plane_create(struct drm_device *drm, err = drm_universal_plane_init(drm, &plane->base, possible_crtcs, &tegra_primary_plane_funcs, formats, - num_formats, DRM_PLANE_TYPE_PRIMARY, - NULL); + num_formats, NULL, + DRM_PLANE_TYPE_PRIMARY, NULL); if (err < 0) { kfree(plane); return ERR_PTR(err); @@ -821,8 +821,8 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm, err = drm_universal_plane_init(drm, &plane->base, 1 << dc->pipe, &tegra_cursor_plane_funcs, formats, - num_formats, DRM_PLANE_TYPE_CURSOR, - NULL); + num_formats, NULL, + DRM_PLANE_TYPE_CURSOR, NULL); if (err < 0) { kfree(plane); return ERR_PTR(err); @@ -883,8 +883,8 @@ static struct drm_plane *tegra_dc_overlay_plane_create(struct drm_device *drm, err = drm_universal_plane_init(drm, &plane->base, 1 << dc->pipe, &tegra_overlay_plane_funcs, formats, - num_formats, DRM_PLANE_TYPE_OVERLAY, - NULL); + num_formats, NULL, + DRM_PLANE_TYPE_OVERLAY, NULL); if (err < 0) { kfree(plane); return ERR_PTR(err); diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index d34cd5393a9b..74b5e7afd6e9 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -861,7 +861,7 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev, ret = drm_universal_plane_init(dev, plane, 0, &vc4_plane_funcs, formats, num_formats, - type, NULL); + NULL, type, NULL); drm_plane_helper_add(plane, &vc4_plane_helper_funcs); diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c index adcdbd0abef6..71ba455af915 100644 --- a/drivers/gpu/drm/virtio/virtgpu_plane.c +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c @@ -298,7 +298,7 @@ struct drm_plane *virtio_gpu_plane_init(struct virtio_gpu_device *vgdev, ret = drm_universal_plane_init(dev, plane, 1 << index, &virtio_gpu_plane_funcs, formats, nformats, - type, NULL); + NULL, type, NULL); if (ret) goto err_plane_init; diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c index d3987bcf53f8..6f0bf6f9c6f8 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c @@ -439,7 +439,7 @@ static int vmw_ldu_init(struct vmw_private *dev_priv, unsigned unit) 0, &vmw_ldu_plane_funcs, vmw_primary_plane_formats, ARRAY_SIZE(vmw_primary_plane_formats), - DRM_PLANE_TYPE_PRIMARY, NULL); + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); if (ret) { DRM_ERROR("Failed to initialize primary plane"); goto err_free; @@ -454,7 +454,7 @@ static int vmw_ldu_init(struct vmw_private *dev_priv, unsigned unit) 0, &vmw_ldu_cursor_funcs, vmw_cursor_plane_formats, ARRAY_SIZE(vmw_cursor_plane_formats), - DRM_PLANE_TYPE_CURSOR, NULL); + NULL, DRM_PLANE_TYPE_CURSOR, NULL); if (ret) { DRM_ERROR("Failed to initialize cursor plane"); drm_plane_cleanup(&ldu->base.primary); diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c index 8d7dc9def7c2..42780c9cb90f 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c @@ -622,7 +622,7 @@ static int vmw_sou_init(struct vmw_private *dev_priv, unsigned unit) 0, &vmw_sou_plane_funcs, vmw_primary_plane_formats, ARRAY_SIZE(vmw_primary_plane_formats), - DRM_PLANE_TYPE_PRIMARY, NULL); + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); if (ret) { DRM_ERROR("Failed to initialize primary plane"); goto err_free; @@ -637,7 +637,7 @@ static int vmw_sou_init(struct vmw_private *dev_priv, unsigned unit) 0, &vmw_sou_cursor_funcs, vmw_cursor_plane_formats, ARRAY_SIZE(vmw_cursor_plane_formats), - DRM_PLANE_TYPE_CURSOR, NULL); + NULL, DRM_PLANE_TYPE_CURSOR, NULL); if (ret) { DRM_ERROR("Failed to initialize cursor plane"); drm_plane_cleanup(&sou->base.primary); diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c index bad31bdf09b6..f18fb966ce9c 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c @@ -1456,7 +1456,7 @@ static int vmw_stdu_init(struct vmw_private *dev_priv, unsigned unit) 0, &vmw_stdu_plane_funcs, vmw_primary_plane_formats, ARRAY_SIZE(vmw_primary_plane_formats), - DRM_PLANE_TYPE_PRIMARY, NULL); + NULL, DRM_PLANE_TYPE_PRIMARY, NULL); if (ret) { DRM_ERROR("Failed to initialize primary plane"); goto err_free; @@ -1471,7 +1471,7 @@ static int vmw_stdu_init(struct vmw_private *dev_priv, unsigned unit) 0, &vmw_stdu_cursor_funcs, vmw_cursor_plane_formats, ARRAY_SIZE(vmw_cursor_plane_formats), - DRM_PLANE_TYPE_CURSOR, NULL); + NULL, DRM_PLANE_TYPE_CURSOR, NULL); if (ret) { DRM_ERROR("Failed to initialize cursor plane"); drm_plane_cleanup(&stdu->base.primary); diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c index d646ac931663..ea29fee01f7d 100644 --- a/drivers/gpu/drm/zte/zx_plane.c +++ b/drivers/gpu/drm/zte/zx_plane.c @@ -539,7 +539,7 @@ int zx_plane_init(struct drm_device *drm, struct zx_plane *zplane, ret = drm_universal_plane_init(drm, plane, VOU_CRTC_MASK, &zx_plane_funcs, formats, format_count, - type, NULL); + NULL, type, NULL); if (ret) { DRM_DEV_ERROR(dev, "failed to init universal plane: %d\n", ret); return ret; diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index 9ab3e7044812..4011d5527f40 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -392,6 +392,20 @@ struct drm_plane_funcs { */ void (*atomic_print_state)(struct drm_printer *p, const struct drm_plane_state *state); + + /** + * @format_mod_supported: + * + * This optional hook is used for the DRM to determine if the given + * format/modifier combination is valid for the plane. This allows the + * DRM to generate the correct format bitmask (which formats apply to + * which modifier). + * + * True if the given modifier is valid for that format on the plane. + * False otherwise. + */ + bool (*format_mod_supported)(struct drm_plane *plane, uint32_t format, + uint64_t modifier); }; /** @@ -487,6 +501,10 @@ struct drm_plane { unsigned int format_count; bool format_default; + uint32_t *formats; + uint64_t *modifiers; + unsigned int modifier_count; + struct drm_crtc *crtc; struct drm_framebuffer *fb; @@ -527,13 +545,14 @@ struct drm_plane { #define obj_to_plane(x) container_of(x, struct drm_plane, base) -__printf(8, 9) +__printf(9, 10) int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane, uint32_t possible_crtcs, const struct drm_plane_funcs *funcs, const uint32_t *formats, unsigned int format_count, + const uint64_t *format_modifiers, enum drm_plane_type type, const char *name, ...); int drm_plane_init(struct drm_device *dev, diff --git a/include/drm/drm_simple_kms_helper.h b/include/drm/drm_simple_kms_helper.h index 2d36538e4a17..6d9adbb46293 100644 --- a/include/drm/drm_simple_kms_helper.h +++ b/include/drm/drm_simple_kms_helper.h @@ -122,6 +122,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev, struct drm_simple_display_pipe *pipe, const struct drm_simple_display_pipe_funcs *funcs, const uint32_t *formats, unsigned int format_count, + const uint64_t *format_modifiers, struct drm_connector *connector); #endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */ diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 995c8f9c692f..ddabbeeebdec 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -184,6 +184,8 @@ extern "C" { #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06 /* add more to the end as needed */ +#define DRM_FORMAT_RESERVED ((1ULL << 56) - 1) + #define fourcc_mod_code(vendor, val) \ ((((__u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 0x00ffffffffffffffULL)) @@ -196,6 +198,15 @@ extern "C" { */ /* + * Invalid Modifier + * + * This modifier can be used as a sentinel to terminate list, or to initialize a + * variable with an invalid modifier. It might also be used to report an error + * back to userspace for certain APIs. + */ +#define DRM_FORMAT_MOD_INVALID fourcc_mod_code(NONE, DRM_FORMAT_RESERVED) + +/* * Linear Layout * * Just plain linear layout. Note that this is different from no specifying any
v2: A minor addition from Daniel Cc: Daniel Stone <daniels@collabora.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> --- drivers/gpu/drm/arc/arcpgu_crtc.c | 1 + drivers/gpu/drm/arm/hdlcd_crtc.c | 1 + drivers/gpu/drm/arm/malidp_planes.c | 2 +- drivers/gpu/drm/armada/armada_crtc.c | 1 + drivers/gpu/drm/armada/armada_overlay.c | 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +++- drivers/gpu/drm/drm_modeset_helper.c | 1 + drivers/gpu/drm/drm_plane.c | 32 ++++++++++++++++++++++++- drivers/gpu/drm/drm_simple_kms_helper.c | 3 +++ drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 1 + drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 7 +++++- drivers/gpu/drm/i915/intel_sprite.c | 4 ++-- drivers/gpu/drm/imx/ipuv3-plane.c | 4 ++-- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +- drivers/gpu/drm/meson/meson_plane.c | 1 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 2 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 4 ++-- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +- drivers/gpu/drm/nouveau/nv50_display.c | 5 ++-- drivers/gpu/drm/omapdrm/omap_plane.c | 3 ++- drivers/gpu/drm/qxl/qxl_display.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 ++-- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++-- drivers/gpu/drm/sti/sti_cursor.c | 2 +- drivers/gpu/drm/sti/sti_gdp.c | 2 +- drivers/gpu/drm/sti/sti_hqvdp.c | 2 +- drivers/gpu/drm/sun4i/sun4i_layer.c | 2 +- drivers/gpu/drm/tegra/dc.c | 12 +++++----- drivers/gpu/drm/vc4/vc4_plane.c | 2 +- drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ++-- drivers/gpu/drm/zte/zx_plane.c | 2 +- include/drm/drm_plane.h | 21 +++++++++++++++- include/drm/drm_simple_kms_helper.h | 1 + include/uapi/drm/drm_fourcc.h | 11 +++++++++ 41 files changed, 126 insertions(+), 46 deletions(-)