All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] drm: Plumb modifiers through plane init
@ 2017-05-03  5:14 Ben Widawsky
  2017-05-03  5:14 ` [PATCH 2/3] drm: Create a format/modifier blob Ben Widawsky
                   ` (5 more replies)
  0 siblings, 6 replies; 37+ messages in thread
From: Ben Widawsky @ 2017-05-03  5:14 UTC (permalink / raw)
  To: DRI Development; +Cc: Intel GFX, Ben Widawsky, Daniel Stone

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(-)

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
-- 
2.12.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 37+ messages in thread
* [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03  5:14 [PATCH 1/3] drm: Plumb modifiers through plane init Ben Widawsky
@ 2017-05-03  5:14 ` Ben Widawsky
  2017-05-03 11:00   ` Brian Starkey
                     ` (5 more replies)
  2017-05-03  5:14 ` [PATCH 3/3] drm/i915: Add format modifiers for Intel Ben Widawsky
                   ` (4 subsequent siblings)
  5 siblings, 6 replies; 37+ messages in thread
From: Ben Widawsky @ 2017-05-03  5:14 UTC (permalink / raw)
  To: DRI Development
  Cc: Intel GFX, Kristian H . Kristensen, Ben Widawsky, Daniel Stone

Updated blob layout (Rob, Daniel, Kristian, xerpi)

Cc: Rob Clark <robdclark@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Kristian H. Kristensen <hoegsberg@gmail.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
 drivers/gpu/drm/drm_mode_config.c |   7 +++
 drivers/gpu/drm/drm_plane.c       | 119 ++++++++++++++++++++++++++++++++++++++
 include/drm/drm_mode_config.h     |   6 ++
 include/uapi/drm/drm_mode.h       |  26 +++++++++
 4 files changed, 158 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.gamma_lut_size_property = prop;
 
+	prop = drm_property_create(dev,
+				   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+				   "IN_FORMATS", 0);
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.modifiers = prop;
+
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 286e183891e5..2e89e0e73435 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
 	return num;
 }
 
+struct drm_format_modifier_blob {
+#define FORMAT_BLOB_CURRENT 1
+	/* Version of this blob format */
+	u32 version;
+
+	/* Flags */
+	u32 flags;
+
+	/* Number of fourcc formats supported */
+	u32 count_formats;
+
+	/* Where in this blob the formats exist (in bytes) */
+	u32 formats_offset;
+
+	/* Number of drm_format_modifiers */
+	u32 count_modifiers;
+
+	/* Where in this blob the modifiers exist (in bytes) */
+	u32 modifiers_offset;
+
+	/* u32 formats[] */
+	/* struct drm_format_modifier modifiers[] */
+} __packed;
+
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+	return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+	return (struct drm_format_modifier *)(((char *)blob) + blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane *plane,
+				 const struct drm_plane_funcs *funcs,
+				 const uint32_t *formats, unsigned int format_count,
+				 const uint64_t *format_modifiers)
+{
+	const struct drm_mode_config *config = &dev->mode_config;
+	const uint64_t *temp_modifiers = format_modifiers;
+	unsigned int format_modifier_count = 0;
+	struct drm_property_blob *blob = NULL;
+	struct drm_format_modifier *mod;
+	size_t blob_size = 0, formats_size, modifiers_size;
+	struct drm_format_modifier_blob *blob_data;
+	int i, j, ret = 0;
+
+	if (format_modifiers)
+		while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+			format_modifier_count++;
+
+	formats_size = sizeof(__u32) * format_count;
+	if (WARN_ON(!formats_size)) {
+		/* 0 formats are never expected */
+		return 0;
+	}
+
+	modifiers_size =
+		sizeof(struct drm_format_modifier) * format_modifier_count;
+
+	blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
+	blob_size += ALIGN(formats_size, 8);
+	blob_size += modifiers_size;
+
+	blob = drm_property_create_blob(dev, blob_size, NULL);
+	if (IS_ERR(blob))
+		return -1;
+
+	blob_data = (struct drm_format_modifier_blob *)blob->data;
+	blob_data->version = FORMAT_BLOB_CURRENT;
+	blob_data->count_formats = format_count;
+	blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+	blob_data->count_modifiers = format_modifier_count;
+
+	/* Modifiers offset is a pointer to a struct with a 64 bit field so it
+	 * should be naturally aligned to 8B.
+	 */
+	blob_data->modifiers_offset =
+		ALIGN(blob_data->formats_offset + formats_size, 8);
+
+	memcpy(formats_ptr(blob_data), formats, formats_size);
+
+	/* If we can't determine support, just bail */
+	if (!funcs->format_mod_supported)
+		goto done;
+
+	mod = modifiers_ptr(blob_data);
+	for (i = 0; i < format_modifier_count; i++) {
+		for (j = 0; j < format_count; j++) {
+			if (funcs->format_mod_supported(plane, formats[j],
+							format_modifiers[i])) {
+				mod->formats |= 1 << j;
+			}
+		}
+
+		mod->modifier = format_modifiers[i];
+		mod->offset = 0;
+		mod->pad = 0;
+		mod++;
+	}
+
+done:
+	drm_object_attach_property(&plane->base, config->modifiers,
+				   blob->base.id);
+
+	return ret;
+}
+
 /**
  * drm_universal_plane_init - Initialize a new universal plane object
  * @dev: DRM device
@@ -130,6 +241,10 @@ 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 (name) {
 		va_list ap;
 
@@ -177,6 +292,10 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
 		drm_object_attach_property(&plane->base, config->prop_src_h, 0);
 	}
 
+	if (config->allow_fb_modifiers)
+		create_in_format_blob(dev, plane, funcs, formats, format_count,
+				      format_modifiers);
+
 	return 0;
 }
 EXPORT_SYMBOL(drm_universal_plane_init);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 42981711189b..03776e659811 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -757,6 +757,12 @@ struct drm_mode_config {
 	 */
 	bool allow_fb_modifiers;
 
+	/**
+	 * @modifiers: Plane property to list support modifier/format
+	 * combination.
+	 */
+	struct drm_property *modifiers;
+
 	/* cursor size */
 	uint32_t cursor_width, cursor_height;
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 8c67fc03d53d..dcdd04c55792 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -665,6 +665,32 @@ struct drm_mode_atomic {
 	__u64 user_data;
 };
 
+struct drm_format_modifier {
+       /* Bitmask of formats in get_plane format list this info applies to. The
+	* offset allows a sliding window of which 64 formats (bits).
+	*
+	* Some examples:
+	* In today's world with < 65 formats, and formats 0, and 2 are
+	* supported
+	* 0x0000000000000005
+	*		  ^-offset = 0, formats = 5
+	*
+	* If the number formats grew to 128, and formats 98-102 are
+	* supported with the modifier:
+	*
+	* 0x0000003c00000000 0000000000000000
+	*		  ^
+	*		  |__offset = 64, formats = 0x3c00000000
+	*
+	*/
+       uint64_t formats;
+       uint32_t offset;
+       uint32_t pad;
+
+       /* This modifier can be used with the format for this plane. */
+       uint64_t modifier;
+} __packed;
+
 /**
  * Create a new 'blob' data property, copying length bytes from data pointer,
  * and returning new blob ID.
-- 
2.12.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 37+ messages in thread
* [PATCH 3/3] drm/i915: Add format modifiers for Intel
  2017-05-03  5:14 [PATCH 1/3] drm: Plumb modifiers through plane init Ben Widawsky
  2017-05-03  5:14 ` [PATCH 2/3] drm: Create a format/modifier blob Ben Widawsky
@ 2017-05-03  5:14 ` Ben Widawsky
  2017-05-03  5:30 ` ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Plumb modifiers through plane init Patchwork
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 37+ messages in thread
From: Ben Widawsky @ 2017-05-03  5:14 UTC (permalink / raw)
  To: DRI Development; +Cc: Intel GFX, Kristian H . Kristensen, Ben Widawsky

This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.

v2:
  - Add LINEAR and Yf modifiers to list (Ville)
  - Combine i8xx and i965 into one list of formats (Ville)
  - Allow 1010102 formats for Y/Yf tiled (Ville)

v3:
  - Handle cursor formats (Ville)
  - Put handling for LINEAR in the mod_support functions (Ville)

v4:
  - List each modifier explicitly in supported modifiers (Ville)
  - Handle the CURSOR plane (Ville)

v5:
  - Split out cursor and sprite handling (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Kristian H. Kristensen <hoegsberg@gmail.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
 drivers/gpu/drm/i915/intel_display.c | 131 +++++++++++++++++++++++++++++++++--
 drivers/gpu/drm/i915/intel_sprite.c  |  76 +++++++++++++++++++-
 2 files changed, 201 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index d52bd05a017d..18aac538d978 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
 	DRM_FORMAT_XBGR2101010,
 };
 
+static const uint64_t i9xx_format_modifiers[] = {
+	I915_FORMAT_MOD_X_TILED,
+	DRM_FORMAT_MOD_LINEAR,
+	DRM_FORMAT_MOD_INVALID
+};
+
 static const uint32_t skl_primary_formats[] = {
 	DRM_FORMAT_C8,
 	DRM_FORMAT_RGB565,
@@ -87,6 +93,14 @@ static const uint32_t skl_primary_formats[] = {
 	DRM_FORMAT_VYUY,
 };
 
+static const uint64_t skl_format_modifiers[] = {
+	I915_FORMAT_MOD_Yf_TILED,
+	I915_FORMAT_MOD_Y_TILED,
+	I915_FORMAT_MOD_X_TILED,
+	DRM_FORMAT_MOD_LINEAR,
+	DRM_FORMAT_MOD_INVALID
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
 	DRM_FORMAT_ARGB8888,
@@ -13381,6 +13395,103 @@ void intel_plane_destroy(struct drm_plane *plane)
 	kfree(to_intel_plane(plane));
 }
 
+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+	switch (format) {
+	case DRM_FORMAT_C8:
+	case DRM_FORMAT_RGB565:
+	case DRM_FORMAT_XRGB1555:
+	case DRM_FORMAT_XRGB8888:
+		return modifier == DRM_FORMAT_MOD_LINEAR ||
+			modifier == I915_FORMAT_MOD_X_TILED;
+	default:
+		return false;
+	}
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+	switch (format) {
+	case DRM_FORMAT_C8:
+	case DRM_FORMAT_RGB565:
+	case DRM_FORMAT_XRGB8888:
+	case DRM_FORMAT_XBGR8888:
+	case DRM_FORMAT_XRGB2101010:
+	case DRM_FORMAT_XBGR2101010:
+		return modifier == DRM_FORMAT_MOD_LINEAR ||
+			modifier == I915_FORMAT_MOD_X_TILED;
+	default:
+		return false;
+	}
+}
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+	switch (format) {
+	case DRM_FORMAT_C8:
+		switch (modifier) {
+		case DRM_FORMAT_MOD_LINEAR:
+		case I915_FORMAT_MOD_X_TILED:
+		case I915_FORMAT_MOD_Y_TILED:
+			return true;
+		default:
+			return false;
+		}
+	case DRM_FORMAT_RGB565:
+	case DRM_FORMAT_XRGB8888:
+	case DRM_FORMAT_XBGR8888:
+	case DRM_FORMAT_ARGB8888:
+	case DRM_FORMAT_ABGR8888:
+	case DRM_FORMAT_XRGB2101010:
+	case DRM_FORMAT_XBGR2101010:
+	case DRM_FORMAT_YUYV:
+	case DRM_FORMAT_YVYU:
+	case DRM_FORMAT_UYVY:
+	case DRM_FORMAT_VYUY:
+		/* All i915 modifiers are fine */
+		switch (modifier) {
+		case DRM_FORMAT_MOD_LINEAR:
+		case I915_FORMAT_MOD_X_TILED:
+		case I915_FORMAT_MOD_Y_TILED:
+		case I915_FORMAT_MOD_Yf_TILED:
+			return true;
+		default:
+			return false;
+		}
+	default:
+		return false;
+	}
+}
+
+static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
+						     uint32_t format,
+						     uint64_t modifier)
+{
+	struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+	if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+		return false;
+
+	if (INTEL_GEN(dev_priv) >= 9)
+		return skl_mod_supported(format, modifier);
+	else if (INTEL_GEN(dev_priv) >= 4)
+		return i965_mod_supported(format, modifier);
+	else
+		return i8xx_mod_supported(format, modifier);
+
+	return false;
+}
+
+static bool intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
+						    uint32_t format,
+						    uint64_t modifier)
+{
+	if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+		return false;
+
+	return modifier == DRM_FORMAT_MOD_LINEAR && format == DRM_FORMAT_ARGB8888;
+}
+
 const struct drm_plane_funcs intel_plane_funcs = {
 	.update_plane = drm_atomic_helper_update_plane,
 	.disable_plane = drm_atomic_helper_disable_plane,
@@ -13390,6 +13501,7 @@ const struct drm_plane_funcs intel_plane_funcs = {
 	.atomic_set_property = intel_plane_atomic_set_property,
 	.atomic_duplicate_state = intel_plane_duplicate_state,
 	.atomic_destroy_state = intel_plane_destroy_state,
+	.format_mod_supported = intel_primary_plane_format_mod_supported,
 };
 
 static int
@@ -13527,6 +13639,7 @@ static const struct drm_plane_funcs intel_cursor_plane_funcs = {
 	.atomic_set_property = intel_plane_atomic_set_property,
 	.atomic_duplicate_state = intel_plane_duplicate_state,
 	.atomic_destroy_state = intel_plane_destroy_state,
+	.format_mod_supported = intel_cursor_plane_format_mod_supported,
 };
 
 static struct intel_plane *
@@ -13537,6 +13650,7 @@ intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 	const uint32_t *intel_primary_formats;
 	unsigned int supported_rotations;
 	unsigned int num_formats;
+	const uint64_t *intel_format_modifiers;
 	int ret;
 
 	primary = kzalloc(sizeof(*primary), GFP_KERNEL);
@@ -13575,18 +13689,21 @@ intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 	if (INTEL_GEN(dev_priv) >= 9) {
 		intel_primary_formats = skl_primary_formats;
 		num_formats = ARRAY_SIZE(skl_primary_formats);
+		intel_format_modifiers = skl_format_modifiers;
 
 		primary->update_plane = skylake_update_primary_plane;
 		primary->disable_plane = skylake_disable_primary_plane;
 	} else if (INTEL_GEN(dev_priv) >= 4) {
 		intel_primary_formats = i965_primary_formats;
 		num_formats = ARRAY_SIZE(i965_primary_formats);
+		intel_format_modifiers = i9xx_format_modifiers;
 
 		primary->update_plane = i9xx_update_primary_plane;
 		primary->disable_plane = i9xx_disable_primary_plane;
 	} else {
 		intel_primary_formats = i8xx_primary_formats;
 		num_formats = ARRAY_SIZE(i8xx_primary_formats);
+		intel_format_modifiers = i9xx_format_modifiers;
 
 		primary->update_plane = i9xx_update_primary_plane;
 		primary->disable_plane = i9xx_disable_primary_plane;
@@ -13596,21 +13713,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,
+					       intel_format_modifiers,
 					       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,
+					       intel_format_modifiers,
 					       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,
+					       intel_format_modifiers,
 					       DRM_PLANE_TYPE_PRIMARY,
 					       "plane %c", plane_name(primary->plane));
 	if (ret)
@@ -13746,6 +13863,11 @@ intel_update_cursor_plane(struct drm_plane *plane,
 	intel_crtc_update_cursor(crtc, state);
 }
 
+static const uint64_t cursor_format_modifiers[] = {
+	DRM_FORMAT_MOD_LINEAR,
+	DRM_FORMAT_MOD_INVALID
+};
+
 static struct intel_plane *
 intel_cursor_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
@@ -13781,7 +13903,8 @@ 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),
-				       NULL, DRM_PLANE_TYPE_CURSOR,
+				       cursor_format_modifiers,
+				       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 053802dd08c1..e7c5c0a94bbd 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -30,6 +30,7 @@
  * support.
  */
 #include <drm/drmP.h>
+#include <drm/drm_atomic_helper.h>
 #include <drm/drm_crtc.h>
 #include <drm/drm_fourcc.h>
 #include <drm/drm_rect.h>
@@ -1032,6 +1033,12 @@ static const uint32_t ilk_plane_formats[] = {
 	DRM_FORMAT_VYUY,
 };
 
+static const uint64_t i9xx_plane_format_modifiers[] = {
+	I915_FORMAT_MOD_X_TILED,
+	DRM_FORMAT_MOD_LINEAR,
+	DRM_FORMAT_MOD_INVALID
+};
+
 static const uint32_t snb_plane_formats[] = {
 	DRM_FORMAT_XBGR8888,
 	DRM_FORMAT_XRGB8888,
@@ -1067,6 +1074,64 @@ static uint32_t skl_plane_formats[] = {
 	DRM_FORMAT_VYUY,
 };
 
+static const uint64_t skl_plane_format_modifiers[] = {
+	I915_FORMAT_MOD_Yf_TILED,
+	I915_FORMAT_MOD_Y_TILED,
+	I915_FORMAT_MOD_X_TILED,
+	DRM_FORMAT_MOD_LINEAR,
+	DRM_FORMAT_MOD_INVALID
+};
+
+static bool intel_sprite_plane_format_mod_supported(struct drm_plane *plane,
+                                                    uint32_t format,
+                                                    uint64_t modifier)
+{
+	struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+	if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+		return false;
+
+	BUG_ON(plane->base.type != DRM_PLANE_TYPE_OVERLAY);
+
+	switch (format) {
+		case DRM_FORMAT_XBGR2101010:
+		case DRM_FORMAT_ABGR2101010:
+			if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+				return true;
+			break;
+		case DRM_FORMAT_RGB565:
+		case DRM_FORMAT_ABGR8888:
+		case DRM_FORMAT_ARGB8888:
+			if (INTEL_GEN(dev_priv) >= 9 || IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+				return true;
+			break;
+		case DRM_FORMAT_XBGR8888:
+			if (INTEL_GEN(dev_priv) >= 6)
+				return true;
+			break;
+		case DRM_FORMAT_XRGB8888:
+		case DRM_FORMAT_YUYV:
+		case DRM_FORMAT_YVYU:
+		case DRM_FORMAT_UYVY:
+		case DRM_FORMAT_VYUY:
+			return true;
+	}
+
+	return false;
+}
+
+const struct drm_plane_funcs intel_sprite_plane_funcs = {
+        .update_plane = drm_atomic_helper_update_plane,
+        .disable_plane = drm_atomic_helper_disable_plane,
+        .destroy = intel_plane_destroy,
+        .set_property = drm_atomic_helper_plane_set_property,
+        .atomic_get_property = intel_plane_atomic_get_property,
+        .atomic_set_property = intel_plane_atomic_set_property,
+        .atomic_duplicate_state = intel_plane_duplicate_state,
+        .atomic_destroy_state = intel_plane_destroy_state,
+        .format_mod_supported = intel_sprite_plane_format_mod_supported,
+};
+
 struct intel_plane *
 intel_sprite_plane_create(struct drm_i915_private *dev_priv,
 			  enum pipe pipe, int plane)
@@ -1075,6 +1140,7 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv,
 	struct intel_plane_state *state = NULL;
 	unsigned long possible_crtcs;
 	const uint32_t *plane_formats;
+	const uint64_t *modifiers;
 	unsigned int supported_rotations;
 	int num_plane_formats;
 	int ret;
@@ -1101,6 +1167,7 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv,
 
 		plane_formats = skl_plane_formats;
 		num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+		modifiers = skl_plane_format_modifiers;
 	} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
 		intel_plane->can_scale = false;
 		intel_plane->max_downscale = 1;
@@ -1110,6 +1177,7 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv,
 
 		plane_formats = vlv_plane_formats;
 		num_plane_formats = ARRAY_SIZE(vlv_plane_formats);
+		modifiers = i9xx_plane_format_modifiers;
 	} else if (INTEL_GEN(dev_priv) >= 7) {
 		if (IS_IVYBRIDGE(dev_priv)) {
 			intel_plane->can_scale = true;
@@ -1124,6 +1192,7 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv,
 
 		plane_formats = snb_plane_formats;
 		num_plane_formats = ARRAY_SIZE(snb_plane_formats);
+		modifiers = i9xx_plane_format_modifiers;
 	} else {
 		intel_plane->can_scale = true;
 		intel_plane->max_downscale = 16;
@@ -1131,6 +1200,7 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv,
 		intel_plane->update_plane = ilk_update_plane;
 		intel_plane->disable_plane = ilk_disable_plane;
 
+		modifiers = i9xx_plane_format_modifiers;
 		if (IS_GEN6(dev_priv)) {
 			plane_formats = snb_plane_formats;
 			num_plane_formats = ARRAY_SIZE(snb_plane_formats);
@@ -1165,13 +1235,15 @@ 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,
-					       NULL, DRM_PLANE_TYPE_OVERLAY,
+					       modifiers,
+					       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,
-					       NULL, DRM_PLANE_TYPE_OVERLAY,
+					       modifiers,
+					       DRM_PLANE_TYPE_OVERLAY,
 					       "sprite %c", sprite_name(pipe, plane));
 	if (ret)
 		goto fail;
-- 
2.12.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 37+ messages in thread
* ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Plumb modifiers through plane init
  2017-05-03  5:14 [PATCH 1/3] drm: Plumb modifiers through plane init Ben Widawsky
  2017-05-03  5:14 ` [PATCH 2/3] drm: Create a format/modifier blob Ben Widawsky
  2017-05-03  5:14 ` [PATCH 3/3] drm/i915: Add format modifiers for Intel Ben Widawsky
@ 2017-05-03  5:30 ` Patchwork
  2017-05-03 10:34 ` [PATCH 1/3] " Liviu Dudau
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 37+ messages in thread
From: Patchwork @ 2017-05-03  5:30 UTC (permalink / raw)
  To: Ben Widawsky; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm: Plumb modifiers through plane init
URL   : https://patchwork.freedesktop.org/series/23862/
State : success

== Summary ==

Series 23862v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/23862/revisions/1/mbox/

Test drv_module_reload:
        Subgroup basic-reload-final:
                dmesg-warn -> PASS       (fi-skl-6770hq) fdo#100248

fdo#100248 https://bugs.freedesktop.org/show_bug.cgi?id=100248

fi-bdw-5557u     total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  time:433s
fi-bdw-gvtdvm    total:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  time:425s
fi-bsw-n3050     total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  time:576s
fi-bxt-j4205     total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  time:511s
fi-bxt-t5700     total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  time:549s
fi-byt-j1900     total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  time:486s
fi-byt-n2820     total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  time:481s
fi-hsw-4770      total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  time:410s
fi-hsw-4770r     total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  time:405s
fi-ilk-650       total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  time:417s
fi-ivb-3520m     total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  time:492s
fi-ivb-3770      total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  time:466s
fi-kbl-7500u     total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  time:461s
fi-kbl-7560u     total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  time:565s
fi-skl-6260u     total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  time:458s
fi-skl-6700hq    total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  time:568s
fi-skl-6700k     total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  time:460s
fi-skl-6770hq    total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  time:495s
fi-skl-gvtdvm    total:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  time:439s
fi-snb-2520m     total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  time:527s
fi-snb-2600      total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  time:400s

7f027554339633cb4e6a2d3974510aaef1a9e24c drm-tip: 2017y-05m-02d-18h-48m-28s UTC integration manifest
599b151 drm/i915: Add format modifiers for Intel
23f6b02 drm: Create a format/modifier blob
c32fe9d drm: Plumb modifiers through plane init

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4605/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03  5:14 [PATCH 1/3] drm: Plumb modifiers through plane init Ben Widawsky
                   ` (2 preceding siblings ...)
  2017-05-03  5:30 ` ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Plumb modifiers through plane init Patchwork
@ 2017-05-03 10:34 ` Liviu Dudau
  2017-05-03 13:45   ` [Intel-gfx] " Daniel Stone
  2017-05-03 18:28 ` kbuild test robot
  2017-05-03 18:48 ` kbuild test robot
  5 siblings, 1 reply; 37+ messages in thread
From: Liviu Dudau @ 2017-05-03 10:34 UTC (permalink / raw)
  To: Ben Widawsky; +Cc: Intel GFX, Daniel Stone, DRI Development

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

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03  5:14 ` [PATCH 2/3] drm: Create a format/modifier blob Ben Widawsky
@ 2017-05-03 11:00   ` Brian Starkey
  2017-05-03 11:47     ` Daniel Stone
  2017-05-03 12:51   ` Brian Starkey
                     ` (4 subsequent siblings)
  5 siblings, 1 reply; 37+ messages in thread
From: Brian Starkey @ 2017-05-03 11:00 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Intel GFX, Kristian H . Kristensen, Daniel Stone, DRI Development

Hi,

Having just caught up on IRC I'm sure I'm far too late for this party,
but...

Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
stored "pointers" to separate blobs for the format and modifier lists?

struct drm_format_modifier_blob {
#define FORMAT_BLOB_CURRENT 1
	/* Version of this blob format */
	u32 version;

	/* Flags */
	u32 flags;

	/* ID of a blob storing an array of FourCCs */
	u32 formats_blob_id;

	/* ID of a blob storing an array of drm_format_modifiers */
	u32 modifiers_blob_id;
} __packed;

I've used/written a few interfaces with offsets to
variable-length-arrays and IMO the code to handle them is always
hideous.

Added bonus: With smart enough helper code the FourCC and modifiers
blobs can be shared across planes.

-Brian

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>Updated blob layout (Rob, Daniel, Kristian, xerpi)
>
>Cc: Rob Clark <robdclark@gmail.com>
>Cc: Daniel Stone <daniels@collabora.com>
>Cc: Kristian H. Kristensen <hoegsberg@gmail.com>
>Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
>---
> drivers/gpu/drm/drm_mode_config.c |   7 +++
> drivers/gpu/drm/drm_plane.c       | 119 ++++++++++++++++++++++++++++++++++++++
> include/drm/drm_mode_config.h     |   6 ++
> include/uapi/drm/drm_mode.h       |  26 +++++++++
> 4 files changed, 158 insertions(+)
>
>diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
>index d9862259a2a7..6bfbc3839df5 100644
>--- a/drivers/gpu/drm/drm_mode_config.c
>+++ b/drivers/gpu/drm/drm_mode_config.c
>@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
> 		return -ENOMEM;
> 	dev->mode_config.gamma_lut_size_property = prop;
>
>+	prop = drm_property_create(dev,
>+				   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
>+				   "IN_FORMATS", 0);
>+	if (!prop)
>+		return -ENOMEM;
>+	dev->mode_config.modifiers = prop;
>+
> 	return 0;
> }
>
>diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>index 286e183891e5..2e89e0e73435 100644
>--- a/drivers/gpu/drm/drm_plane.c
>+++ b/drivers/gpu/drm/drm_plane.c
>@@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
> 	return num;
> }
>
>+struct drm_format_modifier_blob {
>+#define FORMAT_BLOB_CURRENT 1
>+	/* Version of this blob format */
>+	u32 version;
>+
>+	/* Flags */
>+	u32 flags;
>+
>+	/* Number of fourcc formats supported */
>+	u32 count_formats;
>+
>+	/* Where in this blob the formats exist (in bytes) */
>+	u32 formats_offset;
>+
>+	/* Number of drm_format_modifiers */
>+	u32 count_modifiers;
>+
>+	/* Where in this blob the modifiers exist (in bytes) */
>+	u32 modifiers_offset;
>+
>+	/* u32 formats[] */
>+	/* struct drm_format_modifier modifiers[] */
>+} __packed;
>+
>+static inline u32 *
>+formats_ptr(struct drm_format_modifier_blob *blob)
>+{
>+	return (u32 *)(((char *)blob) + blob->formats_offset);
>+}
>+
>+static inline struct drm_format_modifier *
>+modifiers_ptr(struct drm_format_modifier_blob *blob)
>+{
>+	return (struct drm_format_modifier *)(((char *)blob) + blob->modifiers_offset);
>+}
>+
>+static int create_in_format_blob(struct drm_device *dev, struct drm_plane *plane,
>+				 const struct drm_plane_funcs *funcs,
>+				 const uint32_t *formats, unsigned int format_count,
>+				 const uint64_t *format_modifiers)
>+{
>+	const struct drm_mode_config *config = &dev->mode_config;
>+	const uint64_t *temp_modifiers = format_modifiers;
>+	unsigned int format_modifier_count = 0;
>+	struct drm_property_blob *blob = NULL;
>+	struct drm_format_modifier *mod;
>+	size_t blob_size = 0, formats_size, modifiers_size;
>+	struct drm_format_modifier_blob *blob_data;
>+	int i, j, ret = 0;
>+
>+	if (format_modifiers)
>+		while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
>+			format_modifier_count++;
>+
>+	formats_size = sizeof(__u32) * format_count;
>+	if (WARN_ON(!formats_size)) {
>+		/* 0 formats are never expected */
>+		return 0;
>+	}
>+
>+	modifiers_size =
>+		sizeof(struct drm_format_modifier) * format_modifier_count;
>+
>+	blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
>+	blob_size += ALIGN(formats_size, 8);
>+	blob_size += modifiers_size;
>+
>+	blob = drm_property_create_blob(dev, blob_size, NULL);
>+	if (IS_ERR(blob))
>+		return -1;
>+
>+	blob_data = (struct drm_format_modifier_blob *)blob->data;
>+	blob_data->version = FORMAT_BLOB_CURRENT;
>+	blob_data->count_formats = format_count;
>+	blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
>+	blob_data->count_modifiers = format_modifier_count;
>+
>+	/* Modifiers offset is a pointer to a struct with a 64 bit field so it
>+	 * should be naturally aligned to 8B.
>+	 */
>+	blob_data->modifiers_offset =
>+		ALIGN(blob_data->formats_offset + formats_size, 8);
>+
>+	memcpy(formats_ptr(blob_data), formats, formats_size);
>+
>+	/* If we can't determine support, just bail */
>+	if (!funcs->format_mod_supported)
>+		goto done;
>+
>+	mod = modifiers_ptr(blob_data);
>+	for (i = 0; i < format_modifier_count; i++) {
>+		for (j = 0; j < format_count; j++) {
>+			if (funcs->format_mod_supported(plane, formats[j],
>+							format_modifiers[i])) {
>+				mod->formats |= 1 << j;
>+			}
>+		}
>+
>+		mod->modifier = format_modifiers[i];
>+		mod->offset = 0;
>+		mod->pad = 0;
>+		mod++;
>+	}
>+
>+done:
>+	drm_object_attach_property(&plane->base, config->modifiers,
>+				   blob->base.id);
>+
>+	return ret;
>+}
>+
> /**
>  * drm_universal_plane_init - Initialize a new universal plane object
>  * @dev: DRM device
>@@ -130,6 +241,10 @@ 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 (name) {
> 		va_list ap;
>
>@@ -177,6 +292,10 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
> 		drm_object_attach_property(&plane->base, config->prop_src_h, 0);
> 	}
>
>+	if (config->allow_fb_modifiers)
>+		create_in_format_blob(dev, plane, funcs, formats, format_count,
>+				      format_modifiers);
>+
> 	return 0;
> }
> EXPORT_SYMBOL(drm_universal_plane_init);
>diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>index 42981711189b..03776e659811 100644
>--- a/include/drm/drm_mode_config.h
>+++ b/include/drm/drm_mode_config.h
>@@ -757,6 +757,12 @@ struct drm_mode_config {
> 	 */
> 	bool allow_fb_modifiers;
>
>+	/**
>+	 * @modifiers: Plane property to list support modifier/format
>+	 * combination.
>+	 */
>+	struct drm_property *modifiers;
>+
> 	/* cursor size */
> 	uint32_t cursor_width, cursor_height;
>
>diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>index 8c67fc03d53d..dcdd04c55792 100644
>--- a/include/uapi/drm/drm_mode.h
>+++ b/include/uapi/drm/drm_mode.h
>@@ -665,6 +665,32 @@ struct drm_mode_atomic {
> 	__u64 user_data;
> };
>
>+struct drm_format_modifier {
>+       /* Bitmask of formats in get_plane format list this info applies to. The
>+	* offset allows a sliding window of which 64 formats (bits).
>+	*
>+	* Some examples:
>+	* In today's world with < 65 formats, and formats 0, and 2 are
>+	* supported
>+	* 0x0000000000000005
>+	*		  ^-offset = 0, formats = 5
>+	*
>+	* If the number formats grew to 128, and formats 98-102 are
>+	* supported with the modifier:
>+	*
>+	* 0x0000003c00000000 0000000000000000
>+	*		  ^
>+	*		  |__offset = 64, formats = 0x3c00000000
>+	*
>+	*/
>+       uint64_t formats;
>+       uint32_t offset;
>+       uint32_t pad;
>+
>+       /* This modifier can be used with the format for this plane. */
>+       uint64_t modifier;
>+} __packed;
>+
> /**
>  * Create a new 'blob' data property, copying length bytes from data pointer,
>  * and returning new blob ID.
>-- 
>2.12.2
>
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03 11:00   ` Brian Starkey
@ 2017-05-03 11:47     ` Daniel Stone
  2017-05-03 12:39       ` Brian Starkey
  0 siblings, 1 reply; 37+ messages in thread
From: Daniel Stone @ 2017-05-03 11:47 UTC (permalink / raw)
  To: Brian Starkey
  Cc: Ben Widawsky, Kristian H . Kristensen, Intel GFX,
	DRI Development, Daniel Stone

Hi Brian,

On 3 May 2017 at 12:00, Brian Starkey <brian.starkey@arm.com> wrote:
> Having just caught up on IRC I'm sure I'm far too late for this party,
> but...
>
> Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
> stored "pointers" to separate blobs for the format and modifier lists?
>
> I've used/written a few interfaces with offsets to
> variable-length-arrays and IMO the code to handle them is always
> hideous.

I don't agree ...

The idea is that the header can grow because the offsets allow it to;
adding a new member slots in between the end of static data and the
start of variable data, and since all the variable data is accessed by
an array, userspace doesn't have to be aware of the new members. The
code for that is very clean (modulo the casts for pointer maths), cf.
formats_ptr and modifiers_ptr; I'd expect userspace to copy and use
those with version guards:
    uint32_t *formats = formats_ptr(blob);
    struct drm_format_modifier *modifiers = modifiers_ptr(blob);
    struct drm_format_unifier *unifiiers = (blob->version >= 2) ?
unifiers_ptr(blob) : NULL;

That's shorter than fetching separate blobs, and doesn't have multiple
error paths either. What am I missing?

> Added bonus: With smart enough helper code the FourCC and modifiers
> blobs can be shared across planes.

I think this is a serious case of premature optimisation; the memory
savings might be outweighed by the additional number of objects to
track, and userspace would have to jump through serious hoops with a
blob ID cache - something which is a very bad idea regardless - to
take any advantage of it.

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03 11:47     ` Daniel Stone
@ 2017-05-03 12:39       ` Brian Starkey
  0 siblings, 0 replies; 37+ messages in thread
From: Brian Starkey @ 2017-05-03 12:39 UTC (permalink / raw)
  To: Daniel Stone
  Cc: Ben Widawsky, Kristian H . Kristensen, Intel GFX,
	DRI Development, Daniel Stone

Hi Daniel,

On Wed, May 03, 2017 at 12:47:18PM +0100, Daniel Stone wrote:
>Hi Brian,
>
>On 3 May 2017 at 12:00, Brian Starkey <brian.starkey@arm.com> wrote:
>> Having just caught up on IRC I'm sure I'm far too late for this party,
>> but...
>>
>> Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
>> stored "pointers" to separate blobs for the format and modifier lists?
>>
>> I've used/written a few interfaces with offsets to
>> variable-length-arrays and IMO the code to handle them is always
>> hideous.
>
>I don't agree ...
>
>The idea is that the header can grow because the offsets allow it to;
>adding a new member slots in between the end of static data and the
>start of variable data, and since all the variable data is accessed by
>an array, userspace doesn't have to be aware of the new members. 

This is the same in both approaches.

> The
>code for that is very clean (modulo the casts for pointer maths), cf.
>formats_ptr and modifiers_ptr; I'd expect userspace to copy and use
>those with version guards:
>    uint32_t *formats = formats_ptr(blob);
>    struct drm_format_modifier *modifiers = modifiers_ptr(blob);
>    struct drm_format_unifier *unifiiers = (blob->version >= 2) ?
>unifiers_ptr(blob) : NULL;

I concede the tricky code is all confined to the single implementation
in the kernel (encoding is far harder than decoding) - I just think
create_in_format_blob() is cumbersome, ugly and error-prone.

>
>That's shorter than fetching separate blobs, and doesn't have multiple
>error paths either. What am I missing?

Yes, this is a convincing argument.

>
>> Added bonus: With smart enough helper code the FourCC and modifiers
>> blobs can be shared across planes.
>
>I think this is a serious case of premature optimisation; the memory
>savings might be outweighed by the additional number of objects to
>track, and userspace would have to jump through serious hoops with a
>blob ID cache - something which is a very bad idea regardless - to
>take any advantage of it.

Hey I'm just saying it's an option - not that it should be implemented
in V1.

Where both the formats and the modifiers are the same, Ben's approach
lets the blob be shared anyway.

Thanks,
Brian

>
>Cheers, Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03  5:14 ` [PATCH 2/3] drm: Create a format/modifier blob Ben Widawsky
  2017-05-03 11:00   ` Brian Starkey
@ 2017-05-03 12:51   ` Brian Starkey
  2017-05-03 13:51     ` [Intel-gfx] " Daniel Stone
  2017-05-03 13:15   ` Liviu Dudau
                     ` (3 subsequent siblings)
  5 siblings, 1 reply; 37+ messages in thread
From: Brian Starkey @ 2017-05-03 12:51 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Intel GFX, Kristian H . Kristensen, Daniel Stone, DRI Development

Hi,

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>Updated blob layout (Rob, Daniel, Kristian, xerpi)
>
>Cc: Rob Clark <robdclark@gmail.com>
>Cc: Daniel Stone <daniels@collabora.com>
>Cc: Kristian H. Kristensen <hoegsberg@gmail.com>
>Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
>---
> drivers/gpu/drm/drm_mode_config.c |   7 +++
> drivers/gpu/drm/drm_plane.c       | 119 ++++++++++++++++++++++++++++++++++++++
> include/drm/drm_mode_config.h     |   6 ++
> include/uapi/drm/drm_mode.h       |  26 +++++++++
> 4 files changed, 158 insertions(+)
>
>diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
>index d9862259a2a7..6bfbc3839df5 100644
>--- a/drivers/gpu/drm/drm_mode_config.c
>+++ b/drivers/gpu/drm/drm_mode_config.c
>@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
> 		return -ENOMEM;
> 	dev->mode_config.gamma_lut_size_property = prop;
>
>+	prop = drm_property_create(dev,
>+				   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
>+				   "IN_FORMATS", 0);
>+	if (!prop)
>+		return -ENOMEM;
>+	dev->mode_config.modifiers = prop;
>+
> 	return 0;
> }
>
>diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>index 286e183891e5..2e89e0e73435 100644
>--- a/drivers/gpu/drm/drm_plane.c
>+++ b/drivers/gpu/drm/drm_plane.c
>@@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
> 	return num;
> }
>
>+struct drm_format_modifier_blob {
>+#define FORMAT_BLOB_CURRENT 1
>+	/* Version of this blob format */
>+	u32 version;
>+
>+	/* Flags */
>+	u32 flags;
>+
>+	/* Number of fourcc formats supported */
>+	u32 count_formats;
>+
>+	/* Where in this blob the formats exist (in bytes) */
>+	u32 formats_offset;
>+
>+	/* Number of drm_format_modifiers */
>+	u32 count_modifiers;
>+
>+	/* Where in this blob the modifiers exist (in bytes) */
>+	u32 modifiers_offset;
>+
>+	/* u32 formats[] */
>+	/* struct drm_format_modifier modifiers[] */
>+} __packed;
>+
>+static inline u32 *
>+formats_ptr(struct drm_format_modifier_blob *blob)
>+{
>+	return (u32 *)(((char *)blob) + blob->formats_offset);
>+}
>+
>+static inline struct drm_format_modifier *
>+modifiers_ptr(struct drm_format_modifier_blob *blob)
>+{
>+	return (struct drm_format_modifier *)(((char *)blob) + blob->modifiers_offset);
>+}
>+
>+static int create_in_format_blob(struct drm_device *dev, struct drm_plane *plane,
>+				 const struct drm_plane_funcs *funcs,
>+				 const uint32_t *formats, unsigned int format_count,
>+				 const uint64_t *format_modifiers)
>+{
>+	const struct drm_mode_config *config = &dev->mode_config;
>+	const uint64_t *temp_modifiers = format_modifiers;
>+	unsigned int format_modifier_count = 0;
>+	struct drm_property_blob *blob = NULL;
>+	struct drm_format_modifier *mod;
>+	size_t blob_size = 0, formats_size, modifiers_size;
>+	struct drm_format_modifier_blob *blob_data;
>+	int i, j, ret = 0;
>+
>+	if (format_modifiers)
>+		while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
>+			format_modifier_count++;
>+
>+	formats_size = sizeof(__u32) * format_count;
>+	if (WARN_ON(!formats_size)) {
>+		/* 0 formats are never expected */
>+		return 0;
>+	}
>+
>+	modifiers_size =
>+		sizeof(struct drm_format_modifier) * format_modifier_count;
>+
>+	blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
>+	blob_size += ALIGN(formats_size, 8);
>+	blob_size += modifiers_size;
>+
>+	blob = drm_property_create_blob(dev, blob_size, NULL);
>+	if (IS_ERR(blob))
>+		return -1;
>+
>+	blob_data = (struct drm_format_modifier_blob *)blob->data;
>+	blob_data->version = FORMAT_BLOB_CURRENT;
>+	blob_data->count_formats = format_count;
>+	blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);

This looks to be missing some alignment.

Definitely needs to be at least to 4 bytes, but given you aligned
it up to 8 for the initial "blob_size" I assume the intention was to
put the formats on the next 8-byte aligned address after the end of
the struct, e.g.:

	blob_data->formats_offset = ALIGN(sizeof(struct drm_format_modifier_blob), 8);

-Brian

>+	blob_data->count_modifiers = format_modifier_count;
>+
>+	/* Modifiers offset is a pointer to a struct with a 64 bit field so it
>+	 * should be naturally aligned to 8B.
>+	 */
>+	blob_data->modifiers_offset =
>+		ALIGN(blob_data->formats_offset + formats_size, 8);
>+
>+	memcpy(formats_ptr(blob_data), formats, formats_size);
>+
>+	/* If we can't determine support, just bail */
>+	if (!funcs->format_mod_supported)
>+		goto done;
>+
>+	mod = modifiers_ptr(blob_data);
>+	for (i = 0; i < format_modifier_count; i++) {
>+		for (j = 0; j < format_count; j++) {
>+			if (funcs->format_mod_supported(plane, formats[j],
>+							format_modifiers[i])) {
>+				mod->formats |= 1 << j;
>+			}
>+		}
>+
>+		mod->modifier = format_modifiers[i];
>+		mod->offset = 0;
>+		mod->pad = 0;
>+		mod++;
>+	}
>+
>+done:
>+	drm_object_attach_property(&plane->base, config->modifiers,
>+				   blob->base.id);
>+
>+	return ret;
>+}
>+
> /**
>  * drm_universal_plane_init - Initialize a new universal plane object
>  * @dev: DRM device
>@@ -130,6 +241,10 @@ 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 (name) {
> 		va_list ap;
>
>@@ -177,6 +292,10 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
> 		drm_object_attach_property(&plane->base, config->prop_src_h, 0);
> 	}
>
>+	if (config->allow_fb_modifiers)
>+		create_in_format_blob(dev, plane, funcs, formats, format_count,
>+				      format_modifiers);
>+
> 	return 0;
> }
> EXPORT_SYMBOL(drm_universal_plane_init);
>diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>index 42981711189b..03776e659811 100644
>--- a/include/drm/drm_mode_config.h
>+++ b/include/drm/drm_mode_config.h
>@@ -757,6 +757,12 @@ struct drm_mode_config {
> 	 */
> 	bool allow_fb_modifiers;
>
>+	/**
>+	 * @modifiers: Plane property to list support modifier/format
>+	 * combination.
>+	 */
>+	struct drm_property *modifiers;
>+
> 	/* cursor size */
> 	uint32_t cursor_width, cursor_height;
>
>diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>index 8c67fc03d53d..dcdd04c55792 100644
>--- a/include/uapi/drm/drm_mode.h
>+++ b/include/uapi/drm/drm_mode.h
>@@ -665,6 +665,32 @@ struct drm_mode_atomic {
> 	__u64 user_data;
> };
>
>+struct drm_format_modifier {
>+       /* Bitmask of formats in get_plane format list this info applies to. The
>+	* offset allows a sliding window of which 64 formats (bits).
>+	*
>+	* Some examples:
>+	* In today's world with < 65 formats, and formats 0, and 2 are
>+	* supported
>+	* 0x0000000000000005
>+	*		  ^-offset = 0, formats = 5
>+	*
>+	* If the number formats grew to 128, and formats 98-102 are
>+	* supported with the modifier:
>+	*
>+	* 0x0000003c00000000 0000000000000000
>+	*		  ^
>+	*		  |__offset = 64, formats = 0x3c00000000
>+	*
>+	*/
>+       uint64_t formats;
>+       uint32_t offset;
>+       uint32_t pad;
>+
>+       /* This modifier can be used with the format for this plane. */
>+       uint64_t modifier;
>+} __packed;
>+
> /**
>  * Create a new 'blob' data property, copying length bytes from data pointer,
>  * and returning new blob ID.
>-- 
>2.12.2
>
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03  5:14 ` [PATCH 2/3] drm: Create a format/modifier blob Ben Widawsky
  2017-05-03 11:00   ` Brian Starkey
  2017-05-03 12:51   ` Brian Starkey
@ 2017-05-03 13:15   ` Liviu Dudau
  2017-05-11 17:58     ` Ben Widawsky
  2017-05-03 13:32   ` Emil Velikov
                     ` (2 subsequent siblings)
  5 siblings, 1 reply; 37+ messages in thread
From: Liviu Dudau @ 2017-05-03 13:15 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Intel GFX, Kristian H . Kristensen, Daniel Stone, DRI Development

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
> 
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Daniel Stone <daniels@collabora.com>
> Cc: Kristian H. Kristensen <hoegsberg@gmail.com>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> ---
>  drivers/gpu/drm/drm_mode_config.c |   7 +++
>  drivers/gpu/drm/drm_plane.c       | 119 ++++++++++++++++++++++++++++++++++++++
>  include/drm/drm_mode_config.h     |   6 ++
>  include/uapi/drm/drm_mode.h       |  26 +++++++++
>  4 files changed, 158 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index d9862259a2a7..6bfbc3839df5 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
>  		return -ENOMEM;
>  	dev->mode_config.gamma_lut_size_property = prop;
>  
> +	prop = drm_property_create(dev,
> +				   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
> +				   "IN_FORMATS", 0);
> +	if (!prop)
> +		return -ENOMEM;
> +	dev->mode_config.modifiers = prop;
> +
>  	return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 286e183891e5..2e89e0e73435 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>  	return num;
>  }
>  
> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> +	/* Version of this blob format */
> +	u32 version;
> +
> +	/* Flags */
> +	u32 flags;
> +
> +	/* Number of fourcc formats supported */
> +	u32 count_formats;
> +
> +	/* Where in this blob the formats exist (in bytes) */
> +	u32 formats_offset;
> +
> +	/* Number of drm_format_modifiers */
> +	u32 count_modifiers;
> +
> +	/* Where in this blob the modifiers exist (in bytes) */
> +	u32 modifiers_offset;
> +
> +	/* u32 formats[] */
> +	/* struct drm_format_modifier modifiers[] */
> +} __packed;
> +
> +static inline u32 *
> +formats_ptr(struct drm_format_modifier_blob *blob)
> +{
> +	return (u32 *)(((char *)blob) + blob->formats_offset);
> +}
> +
> +static inline struct drm_format_modifier *
> +modifiers_ptr(struct drm_format_modifier_blob *blob)
> +{
> +	return (struct drm_format_modifier *)(((char *)blob) + blob->modifiers_offset);
> +}
> +
> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane *plane,
> +				 const struct drm_plane_funcs *funcs,
> +				 const uint32_t *formats, unsigned int format_count,
> +				 const uint64_t *format_modifiers)

Why do you have to pass the format_modifiers again when you have plane->modifiers?
Or the reverse question: why do you need plane->modifiers when you are passing the
modifiers as parameters all the time?

> +{
> +	const struct drm_mode_config *config = &dev->mode_config;
> +	const uint64_t *temp_modifiers = format_modifiers;
> +	unsigned int format_modifier_count = 0;
> +	struct drm_property_blob *blob = NULL;
> +	struct drm_format_modifier *mod;
> +	size_t blob_size = 0, formats_size, modifiers_size;
> +	struct drm_format_modifier_blob *blob_data;
> +	int i, j, ret = 0;
> +
> +	if (format_modifiers)
> +		while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> +			format_modifier_count++;
> +
> +	formats_size = sizeof(__u32) * format_count;
> +	if (WARN_ON(!formats_size)) {
> +		/* 0 formats are never expected */
> +		return 0;
> +	}
> +
> +	modifiers_size =
> +		sizeof(struct drm_format_modifier) * format_modifier_count;
> +
> +	blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
> +	blob_size += ALIGN(formats_size, 8);
> +	blob_size += modifiers_size;
> +
> +	blob = drm_property_create_blob(dev, blob_size, NULL);
> +	if (IS_ERR(blob))
> +		return -1;
> +
> +	blob_data = (struct drm_format_modifier_blob *)blob->data;
> +	blob_data->version = FORMAT_BLOB_CURRENT;
> +	blob_data->count_formats = format_count;
> +	blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
> +	blob_data->count_modifiers = format_modifier_count;
> +
> +	/* Modifiers offset is a pointer to a struct with a 64 bit field so it
> +	 * should be naturally aligned to 8B.
> +	 */
> +	blob_data->modifiers_offset =
> +		ALIGN(blob_data->formats_offset + formats_size, 8);
> +
> +	memcpy(formats_ptr(blob_data), formats, formats_size);
> +
> +	/* If we can't determine support, just bail */
> +	if (!funcs->format_mod_supported)
> +		goto done;
> +
> +	mod = modifiers_ptr(blob_data);
> +	for (i = 0; i < format_modifier_count; i++) {
> +		for (j = 0; j < format_count; j++) {
> +			if (funcs->format_mod_supported(plane, formats[j],
> +							format_modifiers[i])) {
> +				mod->formats |= 1 << j;
> +			}
> +		}
> +
> +		mod->modifier = format_modifiers[i];
> +		mod->offset = 0;
> +		mod->pad = 0;
> +		mod++;
> +	}
> +
> +done:
> +	drm_object_attach_property(&plane->base, config->modifiers,
> +				   blob->base.id);
> +
> +	return ret;
> +}
> +
>  /**
>   * drm_universal_plane_init - Initialize a new universal plane object
>   * @dev: DRM device
> @@ -130,6 +241,10 @@ 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;
> +

Applying this patch makes the above check appear twice in drm_universal_plane_init() function.

>  	if (name) {
>  		va_list ap;
>  
> @@ -177,6 +292,10 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
>  		drm_object_attach_property(&plane->base, config->prop_src_h, 0);
>  	}
>  
> +	if (config->allow_fb_modifiers)
> +		create_in_format_blob(dev, plane, funcs, formats, format_count,
> +				      format_modifiers);
> +
>  	return 0;
>  }
>  EXPORT_SYMBOL(drm_universal_plane_init);
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 42981711189b..03776e659811 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -757,6 +757,12 @@ struct drm_mode_config {
>  	 */
>  	bool allow_fb_modifiers;
>  
> +	/**
> +	 * @modifiers: Plane property to list support modifier/format
> +	 * combination.

Comment says "Plane property" yet this is struct drm_mode_config.

> +	 */
> +	struct drm_property *modifiers;
> +
>  	/* cursor size */
>  	uint32_t cursor_width, cursor_height;
>  
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 8c67fc03d53d..dcdd04c55792 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -665,6 +665,32 @@ struct drm_mode_atomic {
>  	__u64 user_data;
>  };
>  
> +struct drm_format_modifier {
> +       /* Bitmask of formats in get_plane format list this info applies to. The

You have some unusual indent of the comment here. Also the file uses a different
style for multi-line comments.

> +	* offset allows a sliding window of which 64 formats (bits).
> +	*
> +	* Some examples:
> +	* In today's world with < 65 formats, and formats 0, and 2 are
> +	* supported
> +	* 0x0000000000000005
> +	*		  ^-offset = 0, formats = 5
> +	*
> +	* If the number formats grew to 128, and formats 98-102 are
> +	* supported with the modifier:
> +	*
> +	* 0x0000003c00000000 0000000000000000
> +	*		  ^
> +	*		  |__offset = 64, formats = 0x3c00000000
> +	*
> +	*/
> +       uint64_t formats;
> +       uint32_t offset;
> +       uint32_t pad;

s/pad/__pad/ or s/pad/__reserved/ ?

> +
> +       /* This modifier can be used with the format for this plane. */

I'm having trouble parsing the comment. How about: "The modifier that applies to the
get_plane format list bitmask." ?

Best regards,
Liviu

> +       uint64_t modifier;
> +} __packed;
> +
>  /**
>   * Create a new 'blob' data property, copying length bytes from data pointer,
>   * and returning new blob ID.
> -- 
> 2.12.2
> 
> _______________________________________________
> 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!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03  5:14 ` [PATCH 2/3] drm: Create a format/modifier blob Ben Widawsky
                     ` (2 preceding siblings ...)
  2017-05-03 13:15   ` Liviu Dudau
@ 2017-05-03 13:32   ` Emil Velikov
  2017-05-03 15:08   ` Daniel Vetter
  2017-05-04  9:28   ` Daniel Stone
  5 siblings, 0 replies; 37+ messages in thread
From: Emil Velikov @ 2017-05-03 13:32 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Intel GFX, Kristian H . Kristensen, Daniel Stone, DRI Development

Hi Ben,

On 3 May 2017 at 06:14, Ben Widawsky <ben@bwidawsk.net> wrote:

> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> +       /* Version of this blob format */
> +       u32 version;
> +
> +       /* Flags */
> +       u32 flags;
> +
> +       /* Number of fourcc formats supported */
> +       u32 count_formats;
> +
> +       /* Where in this blob the formats exist (in bytes) */
> +       u32 formats_offset;
> +
> +       /* Number of drm_format_modifiers */
> +       u32 count_modifiers;
> +
> +       /* Where in this blob the modifiers exist (in bytes) */
> +       u32 modifiers_offset;
> +
> +       /* u32 formats[] */
> +       /* struct drm_format_modifier modifiers[] */
> +} __packed;
> +
Why do we need packing here? Both layout and member offsets are
identical with and w/o it.
If there's something subtle to it, please add a comment.


> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane *plane,
> +                                const struct drm_plane_funcs *funcs,
> +                                const uint32_t *formats, unsigned int format_count,
> +                                const uint64_t *format_modifiers)
> +{

> +       blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
> +       blob_size += ALIGN(formats_size, 8);
The 8 is "sizeof(void *) isn't it? Shouldn't we use that instead since
it expands to 4 for 32bit systems?

> +       blob_size += modifiers_size;
> +
> +       blob = drm_property_create_blob(dev, blob_size, NULL);
> +       if (IS_ERR(blob))
> +               return -1;
> +
> +       blob_data = (struct drm_format_modifier_blob *)blob->data;
> +       blob_data->version = FORMAT_BLOB_CURRENT;
> +       blob_data->count_formats = format_count;

> +       blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
Shouldn't we reuse the ALIGN(...) from above?


> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 8c67fc03d53d..dcdd04c55792 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -665,6 +665,32 @@ struct drm_mode_atomic {
>         __u64 user_data;
>  };
>
> +struct drm_format_modifier {
> +       /* Bitmask of formats in get_plane format list this info applies to. The
> +       * offset allows a sliding window of which 64 formats (bits).
> +       *
> +       * Some examples:
> +       * In today's world with < 65 formats, and formats 0, and 2 are
> +       * supported
> +       * 0x0000000000000005
> +       *                 ^-offset = 0, formats = 5
> +       *
> +       * If the number formats grew to 128, and formats 98-102 are
> +       * supported with the modifier:
> +       *
> +       * 0x0000003c00000000 0000000000000000
> +       *                 ^
> +       *                 |__offset = 64, formats = 0x3c00000000
> +       *
> +       */
> +       uint64_t formats;
> +       uint32_t offset;
> +       uint32_t pad;
> +
> +       /* This modifier can be used with the format for this plane. */
> +       uint64_t modifier;
> +} __packed;
> +
As above - why __packed?

Regards,
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03 10:34 ` [PATCH 1/3] " Liviu Dudau
@ 2017-05-03 13:45   ` Daniel Stone
  2017-05-03 14:07     ` Liviu Dudau
  2017-05-10 16:33     ` Ben Widawsky
  0 siblings, 2 replies; 37+ messages in thread
From: Daniel Stone @ 2017-05-03 13:45 UTC (permalink / raw)
  To: Liviu Dudau; +Cc: Ben Widawsky, Intel GFX, DRI Development

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03 12:51   ` Brian Starkey
@ 2017-05-03 13:51     ` Daniel Stone
  2017-05-03 14:03       ` Brian Starkey
  0 siblings, 1 reply; 37+ messages in thread
From: Daniel Stone @ 2017-05-03 13:51 UTC (permalink / raw)
  To: Brian Starkey
  Cc: Emil Velikov, Ben Widawsky, Kristian H . Kristensen, Intel GFX,
	DRI Development

Hi Brian,

On 3 May 2017 at 13:51, Brian Starkey <brian.starkey@arm.com> wrote:
> On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>> +       modifiers_size =
>> +               sizeof(struct drm_format_modifier) *
>> format_modifier_count;
>> +
>> +       blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
>> +       blob_size += ALIGN(formats_size, 8);
>> +       blob_size += modifiers_size;
>> +
>> +       blob = drm_property_create_blob(dev, blob_size, NULL);
>> +       if (IS_ERR(blob))
>> +               return -1;
>> +
>> +       blob_data = (struct drm_format_modifier_blob *)blob->data;
>> +       blob_data->version = FORMAT_BLOB_CURRENT;
>> +       blob_data->count_formats = format_count;
>> +       blob_data->formats_offset = sizeof(struct
>> drm_format_modifier_blob);
>
> This looks to be missing some alignment.
>
> Definitely needs to be at least to 4 bytes, but given you aligned
> it up to 8 for the initial "blob_size" I assume the intention was to
> put the formats on the next 8-byte aligned address after the end of
> the struct, e.g.:
>
>         blob_data->formats_offset = ALIGN(sizeof(struct
> drm_format_modifier_blob), 8);

It's fairly subtle, but I think it's correct.

formats_offset is the end of the fixed-size element, which is
currently aligned to 32 bytes, and practically speaking would always
have to be anyway. As it is an array of uint32_t, this gives natural
alignment.

If we have an odd number of formats supported, the formats[] array
will end on a 4-byte rather than 8-byte boundary, so the ALIGN() on
formats_size guarantees that modifiers_offset will be aligned to an
8-byte quantity, which is required as it has 64-bit elements.

The size of a pointer is not relevant since we're not passing pointers
across the kernel/userspace boundary, just offsets within a struct.
The alignment of those offsets has to correspond to the types located
at those offsets, i.e. 4 bytes for formats (guaranteed by fixed header
layout), and 8 bytes for modifiers (guaranteed by explicit alignment).

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03 13:51     ` [Intel-gfx] " Daniel Stone
@ 2017-05-03 14:03       ` Brian Starkey
  2017-05-03 14:07         ` [Intel-gfx] " Daniel Stone
  0 siblings, 1 reply; 37+ messages in thread
From: Brian Starkey @ 2017-05-03 14:03 UTC (permalink / raw)
  To: Daniel Stone
  Cc: Ben Widawsky, Kristian H . Kristensen, Intel GFX, DRI Development

On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:
>Hi Brian,
>
>On 3 May 2017 at 13:51, Brian Starkey <brian.starkey@arm.com> wrote:
>> On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>>> +       modifiers_size =
>>> +               sizeof(struct drm_format_modifier) *
>>> format_modifier_count;
>>> +
>>> +       blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
>>> +       blob_size += ALIGN(formats_size, 8);
>>> +       blob_size += modifiers_size;
>>> +
>>> +       blob = drm_property_create_blob(dev, blob_size, NULL);
>>> +       if (IS_ERR(blob))
>>> +               return -1;
>>> +
>>> +       blob_data = (struct drm_format_modifier_blob *)blob->data;
>>> +       blob_data->version = FORMAT_BLOB_CURRENT;
>>> +       blob_data->count_formats = format_count;
>>> +       blob_data->formats_offset = sizeof(struct
>>> drm_format_modifier_blob);
>>
>> This looks to be missing some alignment.
>>
>> Definitely needs to be at least to 4 bytes, but given you aligned
>> it up to 8 for the initial "blob_size" I assume the intention was to
>> put the formats on the next 8-byte aligned address after the end of
>> the struct, e.g.:
>>
>>         blob_data->formats_offset = ALIGN(sizeof(struct
>> drm_format_modifier_blob), 8);
>
>It's fairly subtle, but I think it's correct.

It's the exact subtlety that I was concerned about.

>
>formats_offset is the end of the fixed-size element, which is
>currently aligned to 32 bytes, and practically speaking would always
>have to be anyway. As it is an array of uint32_t, this gives natural
>alignment.

Why must it always be? The __packed attribute means it'll have no
padding - so any u16 or u8 added to the end will break it - putting
the formats array on a non-aligned boundary.

If the assumption is that the struct will always be made of only
u32/u64 members (and the implementation will break otherwise) then
there had better be a really big comment saying so, and preferably a
compile-time assertion too.

I'm missing the reason for it being __packed in the first place -
perhaps that's just a left over and needs to be removed.

Either way, this line aligns to 8:

+       blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);

...and the rest of the blob_size calculation looks like it assumes the
formats array starts at that 8-byte boundary. So, for clarity and
consistency I reckon the blob_size code and the code that builds the
blob should do the same thing.

Cheers,
-Brian

>
>If we have an odd number of formats supported, the formats[] array
>will end on a 4-byte rather than 8-byte boundary, so the ALIGN() on
>formats_size guarantees that modifiers_offset will be aligned to an
>8-byte quantity, which is required as it has 64-bit elements.
>
>The size of a pointer is not relevant since we're not passing pointers
>across the kernel/userspace boundary, just offsets within a struct.
>The alignment of those offsets has to correspond to the types located
>at those offsets, i.e. 4 bytes for formats (guaranteed by fixed header
>layout), and 8 bytes for modifiers (guaranteed by explicit alignment).
>
>Cheers,
>Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03 13:45   ` [Intel-gfx] " Daniel Stone
@ 2017-05-03 14:07     ` Liviu Dudau
  2017-05-03 14:14       ` Daniel Stone
  2017-05-10 16:33     ` Ben Widawsky
  1 sibling, 1 reply; 37+ messages in thread
From: Liviu Dudau @ 2017-05-03 14:07 UTC (permalink / raw)
  To: Daniel Stone; +Cc: Ben Widawsky, Intel GFX, DRI Development

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

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03 14:03       ` Brian Starkey
@ 2017-05-03 14:07         ` Daniel Stone
  2017-05-03 14:17           ` Brian Starkey
  0 siblings, 1 reply; 37+ messages in thread
From: Daniel Stone @ 2017-05-03 14:07 UTC (permalink / raw)
  To: Brian Starkey
  Cc: Emil Velikov, Ben Widawsky, Kristian H . Kristensen, Intel GFX,
	DRI Development

Hi Brian,

On 3 May 2017 at 15:03, Brian Starkey <brian.starkey@arm.com> wrote:
> On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:
>> formats_offset is the end of the fixed-size element, which is
>> currently aligned to 32 bytes, and practically speaking would always
>> have to be anyway. As it is an array of uint32_t, this gives natural
>> alignment.
>
> Why must it always be? The __packed attribute means it'll have no
> padding - so any u16 or u8 added to the end will break it - putting
> the formats array on a non-aligned boundary.
>
> If the assumption is that the struct will always be made of only
> u32/u64 members (and the implementation will break otherwise) then
> there had better be a really big comment saying so, and preferably a
> compile-time assertion too.

Indeed that's the case, for most ioctls at least. A comment would
definitely be in order.

> I'm missing the reason for it being __packed in the first place -
> perhaps that's just a left over and needs to be removed.
>
> Either way, this line aligns to 8:
>
> +       blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
>
> ...and the rest of the blob_size calculation looks like it assumes the
> formats array starts at that 8-byte boundary. So, for clarity and
> consistency I reckon the blob_size code and the code that builds the
> blob should do the same thing.

All this is correct - the __packed declaration is unnecessary, and so
is the rounding up when calculating the size. And with that fixed, I
believe it should be correct, no?

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03 14:07     ` Liviu Dudau
@ 2017-05-03 14:14       ` Daniel Stone
  2017-05-03 14:52         ` Liviu Dudau
  0 siblings, 1 reply; 37+ messages in thread
From: Daniel Stone @ 2017-05-03 14:14 UTC (permalink / raw)
  To: Liviu Dudau; +Cc: Ben Widawsky, Intel GFX, DRI Development

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.)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03 14:07         ` [Intel-gfx] " Daniel Stone
@ 2017-05-03 14:17           ` Brian Starkey
  0 siblings, 0 replies; 37+ messages in thread
From: Brian Starkey @ 2017-05-03 14:17 UTC (permalink / raw)
  To: Daniel Stone
  Cc: Ben Widawsky, Kristian H . Kristensen, Intel GFX, DRI Development

Hi Daniel,

On Wed, May 03, 2017 at 03:07:40PM +0100, Daniel Stone wrote:
>Hi Brian,
>
>On 3 May 2017 at 15:03, Brian Starkey <brian.starkey@arm.com> wrote:
>> On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:
>>> formats_offset is the end of the fixed-size element, which is
>>> currently aligned to 32 bytes, and practically speaking would always
>>> have to be anyway. As it is an array of uint32_t, this gives natural
>>> alignment.
>>
>> Why must it always be? The __packed attribute means it'll have no
>> padding - so any u16 or u8 added to the end will break it - putting
>> the formats array on a non-aligned boundary.
>>
>> If the assumption is that the struct will always be made of only
>> u32/u64 members (and the implementation will break otherwise) then
>> there had better be a really big comment saying so, and preferably a
>> compile-time assertion too.
>
>Indeed that's the case, for most ioctls at least. A comment would
>definitely be in order.
>

No need for a comment if the code is fixed to do the right thing
irrespective of the value of sizeof(drm_formats_modifier_blob) - which
IMO is mandatory.

>> I'm missing the reason for it being __packed in the first place -
>> perhaps that's just a left over and needs to be removed.
>>
>> Either way, this line aligns to 8:
>>
>> +       blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
>>
>> ...and the rest of the blob_size calculation looks like it assumes the
>> formats array starts at that 8-byte boundary. So, for clarity and
>> consistency I reckon the blob_size code and the code that builds the
>> blob should do the same thing.
>
>All this is correct - the __packed declaration is unnecessary, and so
>is the rounding up when calculating the size. And with that fixed, I
>believe it should be correct, no?

Yes, with those problems fixed it looks correct to me.

Thanks,
-Brian

>
>Cheers,
>Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03 14:14       ` Daniel Stone
@ 2017-05-03 14:52         ` Liviu Dudau
  2017-05-03 16:45           ` Daniel Vetter
  0 siblings, 1 reply; 37+ messages in thread
From: Liviu Dudau @ 2017-05-03 14:52 UTC (permalink / raw)
  To: Daniel Stone; +Cc: Ben Widawsky, Intel GFX, DRI Development

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

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03  5:14 ` [PATCH 2/3] drm: Create a format/modifier blob Ben Widawsky
                     ` (3 preceding siblings ...)
  2017-05-03 13:32   ` Emil Velikov
@ 2017-05-03 15:08   ` Daniel Vetter
  2017-05-16 21:19     ` [Intel-gfx] " Ben Widawsky
  2017-05-04  9:28   ` Daniel Stone
  5 siblings, 1 reply; 37+ messages in thread
From: Daniel Vetter @ 2017-05-03 15:08 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Intel GFX, Kristian H . Kristensen, Daniel Stone, DRI Development

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
> 
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Daniel Stone <daniels@collabora.com>
> Cc: Kristian H. Kristensen <hoegsberg@gmail.com>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> ---
>  drivers/gpu/drm/drm_mode_config.c |   7 +++
>  drivers/gpu/drm/drm_plane.c       | 119 ++++++++++++++++++++++++++++++++++++++
>  include/drm/drm_mode_config.h     |   6 ++
>  include/uapi/drm/drm_mode.h       |  26 +++++++++
>  4 files changed, 158 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index d9862259a2a7..6bfbc3839df5 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
>  		return -ENOMEM;
>  	dev->mode_config.gamma_lut_size_property = prop;
>  
> +	prop = drm_property_create(dev,
> +				   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
> +				   "IN_FORMATS", 0);
> +	if (!prop)
> +		return -ENOMEM;
> +	dev->mode_config.modifiers = prop;
> +
>  	return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 286e183891e5..2e89e0e73435 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>  	return num;
>  }
>  
> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> +	/* Version of this blob format */
> +	u32 version;
> +
> +	/* Flags */
> +	u32 flags;
> +
> +	/* Number of fourcc formats supported */
> +	u32 count_formats;
> +
> +	/* Where in this blob the formats exist (in bytes) */
> +	u32 formats_offset;
> +
> +	/* Number of drm_format_modifiers */
> +	u32 count_modifiers;
> +
> +	/* Where in this blob the modifiers exist (in bytes) */
> +	u32 modifiers_offset;
> +
> +	/* u32 formats[] */
> +	/* struct drm_format_modifier modifiers[] */
> +} __packed;

The struct should be in the uapi header. Otherwise it won't show up in
libdrm headers when following the proper process.
-Daniel

> +
> +static inline u32 *
> +formats_ptr(struct drm_format_modifier_blob *blob)
> +{
> +	return (u32 *)(((char *)blob) + blob->formats_offset);
> +}
> +
> +static inline struct drm_format_modifier *
> +modifiers_ptr(struct drm_format_modifier_blob *blob)
> +{
> +	return (struct drm_format_modifier *)(((char *)blob) + blob->modifiers_offset);
> +}
> +
> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane *plane,
> +				 const struct drm_plane_funcs *funcs,
> +				 const uint32_t *formats, unsigned int format_count,
> +				 const uint64_t *format_modifiers)
> +{
> +	const struct drm_mode_config *config = &dev->mode_config;
> +	const uint64_t *temp_modifiers = format_modifiers;
> +	unsigned int format_modifier_count = 0;
> +	struct drm_property_blob *blob = NULL;
> +	struct drm_format_modifier *mod;
> +	size_t blob_size = 0, formats_size, modifiers_size;
> +	struct drm_format_modifier_blob *blob_data;
> +	int i, j, ret = 0;
> +
> +	if (format_modifiers)
> +		while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> +			format_modifier_count++;
> +
> +	formats_size = sizeof(__u32) * format_count;
> +	if (WARN_ON(!formats_size)) {
> +		/* 0 formats are never expected */
> +		return 0;
> +	}
> +
> +	modifiers_size =
> +		sizeof(struct drm_format_modifier) * format_modifier_count;
> +
> +	blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
> +	blob_size += ALIGN(formats_size, 8);
> +	blob_size += modifiers_size;
> +
> +	blob = drm_property_create_blob(dev, blob_size, NULL);
> +	if (IS_ERR(blob))
> +		return -1;
> +
> +	blob_data = (struct drm_format_modifier_blob *)blob->data;
> +	blob_data->version = FORMAT_BLOB_CURRENT;
> +	blob_data->count_formats = format_count;
> +	blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
> +	blob_data->count_modifiers = format_modifier_count;
> +
> +	/* Modifiers offset is a pointer to a struct with a 64 bit field so it
> +	 * should be naturally aligned to 8B.
> +	 */
> +	blob_data->modifiers_offset =
> +		ALIGN(blob_data->formats_offset + formats_size, 8);
> +
> +	memcpy(formats_ptr(blob_data), formats, formats_size);
> +
> +	/* If we can't determine support, just bail */
> +	if (!funcs->format_mod_supported)
> +		goto done;
> +
> +	mod = modifiers_ptr(blob_data);
> +	for (i = 0; i < format_modifier_count; i++) {
> +		for (j = 0; j < format_count; j++) {
> +			if (funcs->format_mod_supported(plane, formats[j],
> +							format_modifiers[i])) {
> +				mod->formats |= 1 << j;
> +			}
> +		}
> +
> +		mod->modifier = format_modifiers[i];
> +		mod->offset = 0;
> +		mod->pad = 0;
> +		mod++;
> +	}
> +
> +done:
> +	drm_object_attach_property(&plane->base, config->modifiers,
> +				   blob->base.id);
> +
> +	return ret;
> +}
> +
>  /**
>   * drm_universal_plane_init - Initialize a new universal plane object
>   * @dev: DRM device
> @@ -130,6 +241,10 @@ 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 (name) {
>  		va_list ap;
>  
> @@ -177,6 +292,10 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
>  		drm_object_attach_property(&plane->base, config->prop_src_h, 0);
>  	}
>  
> +	if (config->allow_fb_modifiers)
> +		create_in_format_blob(dev, plane, funcs, formats, format_count,
> +				      format_modifiers);
> +
>  	return 0;
>  }
>  EXPORT_SYMBOL(drm_universal_plane_init);
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 42981711189b..03776e659811 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -757,6 +757,12 @@ struct drm_mode_config {
>  	 */
>  	bool allow_fb_modifiers;
>  
> +	/**
> +	 * @modifiers: Plane property to list support modifier/format
> +	 * combination.
> +	 */
> +	struct drm_property *modifiers;
> +
>  	/* cursor size */
>  	uint32_t cursor_width, cursor_height;
>  
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 8c67fc03d53d..dcdd04c55792 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -665,6 +665,32 @@ struct drm_mode_atomic {
>  	__u64 user_data;
>  };
>  
> +struct drm_format_modifier {
> +       /* Bitmask of formats in get_plane format list this info applies to. The
> +	* offset allows a sliding window of which 64 formats (bits).
> +	*
> +	* Some examples:
> +	* In today's world with < 65 formats, and formats 0, and 2 are
> +	* supported
> +	* 0x0000000000000005
> +	*		  ^-offset = 0, formats = 5
> +	*
> +	* If the number formats grew to 128, and formats 98-102 are
> +	* supported with the modifier:
> +	*
> +	* 0x0000003c00000000 0000000000000000
> +	*		  ^
> +	*		  |__offset = 64, formats = 0x3c00000000
> +	*
> +	*/
> +       uint64_t formats;
> +       uint32_t offset;
> +       uint32_t pad;
> +
> +       /* This modifier can be used with the format for this plane. */
> +       uint64_t modifier;
> +} __packed;
> +
>  /**
>   * Create a new 'blob' data property, copying length bytes from data pointer,
>   * and returning new blob ID.
> -- 
> 2.12.2
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03 14:52         ` Liviu Dudau
@ 2017-05-03 16:45           ` Daniel Vetter
  2017-05-03 17:30             ` [Intel-gfx] " Liviu Dudau
  0 siblings, 1 reply; 37+ messages in thread
From: Daniel Vetter @ 2017-05-03 16:45 UTC (permalink / raw)
  To: Liviu Dudau; +Cc: DRI Development, Ben Widawsky, Intel GFX

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03 16:45           ` Daniel Vetter
@ 2017-05-03 17:30             ` Liviu Dudau
  2017-05-10 16:34               ` Ben Widawsky
  0 siblings, 1 reply; 37+ messages in thread
From: Liviu Dudau @ 2017-05-03 17:30 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: DRI Development, Ben Widawsky, Intel GFX

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

-- 
====================
| 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

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03  5:14 [PATCH 1/3] drm: Plumb modifiers through plane init Ben Widawsky
                   ` (3 preceding siblings ...)
  2017-05-03 10:34 ` [PATCH 1/3] " Liviu Dudau
@ 2017-05-03 18:28 ` kbuild test robot
  2017-05-03 18:48 ` kbuild test robot
  5 siblings, 0 replies; 37+ messages in thread
From: kbuild test robot @ 2017-05-03 18:28 UTC (permalink / raw)
  Cc: Intel GFX, Daniel Stone, kbuild-all, DRI Development, Ben Widawsky

[-- Attachment #1: Type: text/plain, Size: 19109 bytes --]

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

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6575 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03  5:14 [PATCH 1/3] drm: Plumb modifiers through plane init Ben Widawsky
                   ` (4 preceding siblings ...)
  2017-05-03 18:28 ` kbuild test robot
@ 2017-05-03 18:48 ` kbuild test robot
  5 siblings, 0 replies; 37+ messages in thread
From: kbuild test robot @ 2017-05-03 18:48 UTC (permalink / raw)
  Cc: Intel GFX, Daniel Stone, kbuild-all, DRI Development, Ben Widawsky

[-- Attachment #1: Type: text/plain, Size: 4058 bytes --]

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

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 49169 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03  5:14 ` [PATCH 2/3] drm: Create a format/modifier blob Ben Widawsky
                     ` (4 preceding siblings ...)
  2017-05-03 15:08   ` Daniel Vetter
@ 2017-05-04  9:28   ` Daniel Stone
  5 siblings, 0 replies; 37+ messages in thread
From: Daniel Stone @ 2017-05-04  9:28 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Intel GFX, xerpi.g.12, Kristian H . Kristensen, DRI Development

Hi,

On 3 May 2017 at 06:14, Ben Widawsky <ben@bwidawsk.net> wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)

In terms of the blob as uABI, we've got an implementation inside
Weston which works:
https://git.collabora.com/cgit/user/daniels/weston.git/commit/?h=wip/2017-04/atomic-v11-WIP&id=0a47cb63947e

That was authored by Sergi and reviewed by me. We both think it's
entirely acceptable and future-proof uABI, and it does exactly what we
want. We use it to both allocate with a suitable set of modifiers, as
well as a high-pass filter to avoid assigning FBs to planes which
won't accept the FB modifiers. So this gets my:
Acked-by: Daniel Stone <daniels@collabora.com>

And a future revision with the fixups found here would get my R-b.

Cheers,
Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03 13:45   ` [Intel-gfx] " Daniel Stone
  2017-05-03 14:07     ` Liviu Dudau
@ 2017-05-10 16:33     ` Ben Widawsky
  1 sibling, 0 replies; 37+ messages in thread
From: Ben Widawsky @ 2017-05-10 16:33 UTC (permalink / raw)
  To: Daniel Stone; +Cc: Intel GFX, Liviu Dudau, DRI Development

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.

-- 
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-03 17:30             ` [Intel-gfx] " Liviu Dudau
@ 2017-05-10 16:34               ` Ben Widawsky
  2017-05-10 17:24                 ` Liviu Dudau
  0 siblings, 1 reply; 37+ messages in thread
From: Ben Widawsky @ 2017-05-10 16:34 UTC (permalink / raw)
  To: Liviu Dudau; +Cc: DRI Development, Intel GFX

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.

-- 
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-10 16:34               ` Ben Widawsky
@ 2017-05-10 17:24                 ` Liviu Dudau
  2017-05-10 19:33                   ` [Intel-gfx] " Ben Widawsky
  0 siblings, 1 reply; 37+ messages in thread
From: Liviu Dudau @ 2017-05-10 17:24 UTC (permalink / raw)
  To: Ben Widawsky; +Cc: Intel GFX, DRI Development

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

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-10 17:24                 ` Liviu Dudau
@ 2017-05-10 19:33                   ` Ben Widawsky
  2017-05-10 20:21                     ` Liviu Dudau
  0 siblings, 1 reply; 37+ messages in thread
From: Ben Widawsky @ 2017-05-10 19:33 UTC (permalink / raw)
  To: Liviu Dudau; +Cc: Intel GFX, DRI Development

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!  /
>  ---------------
>    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init
  2017-05-10 19:33                   ` [Intel-gfx] " Ben Widawsky
@ 2017-05-10 20:21                     ` Liviu Dudau
  0 siblings, 0 replies; 37+ messages in thread
From: Liviu Dudau @ 2017-05-10 20:21 UTC (permalink / raw)
  To: Ben Widawsky; +Cc: Intel GFX, Liviu Dudau, DRI Development

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

-- 
   _
 _|_|_
 ('_')
 (⊃  )⊃
 |_|_|
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03 13:15   ` Liviu Dudau
@ 2017-05-11 17:58     ` Ben Widawsky
  0 siblings, 0 replies; 37+ messages in thread
From: Ben Widawsky @ 2017-05-11 17:58 UTC (permalink / raw)
  To: Liviu Dudau
  Cc: Intel GFX, Kristian H . Kristensen, Daniel Stone, DRI Development

On 17-05-03 14:15:15, Liviu Dudau wrote:
>On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>> Updated blob layout (Rob, Daniel, Kristian, xerpi)
>>
>> Cc: Rob Clark <robdclark@gmail.com>
>> Cc: Daniel Stone <daniels@collabora.com>
>> Cc: Kristian H. Kristensen <hoegsberg@gmail.com>
>> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
>> ---
>>  drivers/gpu/drm/drm_mode_config.c |   7 +++
>>  drivers/gpu/drm/drm_plane.c       | 119 ++++++++++++++++++++++++++++++++++++++
>>  include/drm/drm_mode_config.h     |   6 ++
>>  include/uapi/drm/drm_mode.h       |  26 +++++++++
>>  4 files changed, 158 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
>> index d9862259a2a7..6bfbc3839df5 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
>>  		return -ENOMEM;
>>  	dev->mode_config.gamma_lut_size_property = prop;
>>
>> +	prop = drm_property_create(dev,
>> +				   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
>> +				   "IN_FORMATS", 0);
>> +	if (!prop)
>> +		return -ENOMEM;
>> +	dev->mode_config.modifiers = prop;
>> +
>>  	return 0;
>>  }
>>
>> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>> index 286e183891e5..2e89e0e73435 100644
>> --- a/drivers/gpu/drm/drm_plane.c
>> +++ b/drivers/gpu/drm/drm_plane.c
>> @@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>>  	return num;
>>  }
>>
>> +struct drm_format_modifier_blob {
>> +#define FORMAT_BLOB_CURRENT 1
>> +	/* Version of this blob format */
>> +	u32 version;
>> +
>> +	/* Flags */
>> +	u32 flags;
>> +
>> +	/* Number of fourcc formats supported */
>> +	u32 count_formats;
>> +
>> +	/* Where in this blob the formats exist (in bytes) */
>> +	u32 formats_offset;
>> +
>> +	/* Number of drm_format_modifiers */
>> +	u32 count_modifiers;
>> +
>> +	/* Where in this blob the modifiers exist (in bytes) */
>> +	u32 modifiers_offset;
>> +
>> +	/* u32 formats[] */
>> +	/* struct drm_format_modifier modifiers[] */
>> +} __packed;
>> +
>> +static inline u32 *
>> +formats_ptr(struct drm_format_modifier_blob *blob)
>> +{
>> +	return (u32 *)(((char *)blob) + blob->formats_offset);
>> +}
>> +
>> +static inline struct drm_format_modifier *
>> +modifiers_ptr(struct drm_format_modifier_blob *blob)
>> +{
>> +	return (struct drm_format_modifier *)(((char *)blob) + blob->modifiers_offset);
>> +}
>> +
>> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane *plane,
>> +				 const struct drm_plane_funcs *funcs,
>> +				 const uint32_t *formats, unsigned int format_count,
>> +				 const uint64_t *format_modifiers)
>
>Why do you have to pass the format_modifiers again when you have plane->modifiers?
>Or the reverse question: why do you need plane->modifiers when you are passing the
>modifiers as parameters all the time?
>

I've dropped most of the parameters here and just used plane->*

>> +{
>> +	const struct drm_mode_config *config = &dev->mode_config;
>> +	const uint64_t *temp_modifiers = format_modifiers;
>> +	unsigned int format_modifier_count = 0;
>> +	struct drm_property_blob *blob = NULL;
>> +	struct drm_format_modifier *mod;
>> +	size_t blob_size = 0, formats_size, modifiers_size;
>> +	struct drm_format_modifier_blob *blob_data;
>> +	int i, j, ret = 0;
>> +
>> +	if (format_modifiers)
>> +		while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
>> +			format_modifier_count++;
>> +
>> +	formats_size = sizeof(__u32) * format_count;
>> +	if (WARN_ON(!formats_size)) {
>> +		/* 0 formats are never expected */
>> +		return 0;
>> +	}
>> +
>> +	modifiers_size =
>> +		sizeof(struct drm_format_modifier) * format_modifier_count;
>> +
>> +	blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
>> +	blob_size += ALIGN(formats_size, 8);
>> +	blob_size += modifiers_size;
>> +
>> +	blob = drm_property_create_blob(dev, blob_size, NULL);
>> +	if (IS_ERR(blob))
>> +		return -1;
>> +
>> +	blob_data = (struct drm_format_modifier_blob *)blob->data;
>> +	blob_data->version = FORMAT_BLOB_CURRENT;
>> +	blob_data->count_formats = format_count;
>> +	blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
>> +	blob_data->count_modifiers = format_modifier_count;
>> +
>> +	/* Modifiers offset is a pointer to a struct with a 64 bit field so it
>> +	 * should be naturally aligned to 8B.
>> +	 */
>> +	blob_data->modifiers_offset =
>> +		ALIGN(blob_data->formats_offset + formats_size, 8);
>> +
>> +	memcpy(formats_ptr(blob_data), formats, formats_size);
>> +
>> +	/* If we can't determine support, just bail */
>> +	if (!funcs->format_mod_supported)
>> +		goto done;
>> +
>> +	mod = modifiers_ptr(blob_data);
>> +	for (i = 0; i < format_modifier_count; i++) {
>> +		for (j = 0; j < format_count; j++) {
>> +			if (funcs->format_mod_supported(plane, formats[j],
>> +							format_modifiers[i])) {
>> +				mod->formats |= 1 << j;
>> +			}
>> +		}
>> +
>> +		mod->modifier = format_modifiers[i];
>> +		mod->offset = 0;
>> +		mod->pad = 0;
>> +		mod++;
>> +	}
>> +
>> +done:
>> +	drm_object_attach_property(&plane->base, config->modifiers,
>> +				   blob->base.id);
>> +
>> +	return ret;
>> +}
>> +
>>  /**
>>   * drm_universal_plane_init - Initialize a new universal plane object
>>   * @dev: DRM device
>> @@ -130,6 +241,10 @@ 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;
>> +
>
>Applying this patch makes the above check appear twice in drm_universal_plane_init() function.
>

Fixed. Thanks.

>>  	if (name) {
>>  		va_list ap;
>>
>> @@ -177,6 +292,10 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
>>  		drm_object_attach_property(&plane->base, config->prop_src_h, 0);
>>  	}
>>
>> +	if (config->allow_fb_modifiers)
>> +		create_in_format_blob(dev, plane, funcs, formats, format_count,
>> +				      format_modifiers);
>> +
>>  	return 0;
>>  }
>>  EXPORT_SYMBOL(drm_universal_plane_init);
>> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>> index 42981711189b..03776e659811 100644
>> --- a/include/drm/drm_mode_config.h
>> +++ b/include/drm/drm_mode_config.h
>> @@ -757,6 +757,12 @@ struct drm_mode_config {
>>  	 */
>>  	bool allow_fb_modifiers;
>>
>> +	/**
>> +	 * @modifiers: Plane property to list support modifier/format
>> +	 * combination.
>
>Comment says "Plane property" yet this is struct drm_mode_config.
>

Yeah, it is a per plane property. It's just in the mode config for blob
creation. AFAICT, all props work this way. It's attached to the plane though:
drm_object_attach_property(&plane->base, config->modifiers, blob->base.id);

What would you like me to change here?


>> +	 */
>> +	struct drm_property *modifiers;
>> +
>>  	/* cursor size */
>>  	uint32_t cursor_width, cursor_height;
>>
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index 8c67fc03d53d..dcdd04c55792 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -665,6 +665,32 @@ struct drm_mode_atomic {
>>  	__u64 user_data;
>>  };
>>
>> +struct drm_format_modifier {
>> +       /* Bitmask of formats in get_plane format list this info applies to. The
>
>You have some unusual indent of the comment here. Also the file uses a different
>style for multi-line comments.
>

Fixed the indent issue. Thanks for spotting that, it was a copy-paste problem on
my end. The file is inconsistent in multiline comments, actually. Not changed
anything there.

>> +	* offset allows a sliding window of which 64 formats (bits).
>> +	*
>> +	* Some examples:
>> +	* In today's world with < 65 formats, and formats 0, and 2 are
>> +	* supported
>> +	* 0x0000000000000005
>> +	*		  ^-offset = 0, formats = 5
>> +	*
>> +	* If the number formats grew to 128, and formats 98-102 are
>> +	* supported with the modifier:
>> +	*
>> +	* 0x0000003c00000000 0000000000000000
>> +	*		  ^
>> +	*		  |__offset = 64, formats = 0x3c00000000
>> +	*
>> +	*/
>> +       uint64_t formats;
>> +       uint32_t offset;
>> +       uint32_t pad;
>
>s/pad/__pad/ or s/pad/__reserved/ ?
>

Every other structure in the file with a pad field is called "pad" however, you
made me realize my data types should be __u32 and __u64, those are fixed.

>> +
>> +       /* This modifier can be used with the format for this plane. */
>
>I'm having trouble parsing the comment. How about: "The modifier that applies to the
>get_plane format list bitmask." ?
>

Sure. Done.

>Best regards,
>Liviu
>
>> +       uint64_t modifier;
>> +} __packed;
>> +
>>  /**
>>   * Create a new 'blob' data property, copying length bytes from data pointer,
>>   * and returning new blob ID.
>> --
>> 2.12.2
>>
>> _______________________________________________
>> 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!  /
>  ---------------
>    ¯\_(ツ)_/¯

-- 
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-03 15:08   ` Daniel Vetter
@ 2017-05-16 21:19     ` Ben Widawsky
  2017-05-17 11:31       ` Daniel Vetter
  0 siblings, 1 reply; 37+ messages in thread
From: Ben Widawsky @ 2017-05-16 21:19 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Intel GFX, Kristian H . Kristensen, Daniel Stone, DRI Development

On 17-05-03 17:08:27, Daniel Vetter wrote:
>On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>> Updated blob layout (Rob, Daniel, Kristian, xerpi)
>>
>> Cc: Rob Clark <robdclark@gmail.com>
>> Cc: Daniel Stone <daniels@collabora.com>
>> Cc: Kristian H. Kristensen <hoegsberg@gmail.com>
>> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
>> ---
>>  drivers/gpu/drm/drm_mode_config.c |   7 +++
>>  drivers/gpu/drm/drm_plane.c       | 119 ++++++++++++++++++++++++++++++++++++++
>>  include/drm/drm_mode_config.h     |   6 ++
>>  include/uapi/drm/drm_mode.h       |  26 +++++++++
>>  4 files changed, 158 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
>> index d9862259a2a7..6bfbc3839df5 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
>>  		return -ENOMEM;
>>  	dev->mode_config.gamma_lut_size_property = prop;
>>
>> +	prop = drm_property_create(dev,
>> +				   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
>> +				   "IN_FORMATS", 0);
>> +	if (!prop)
>> +		return -ENOMEM;
>> +	dev->mode_config.modifiers = prop;
>> +
>>  	return 0;
>>  }
>>
>> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>> index 286e183891e5..2e89e0e73435 100644
>> --- a/drivers/gpu/drm/drm_plane.c
>> +++ b/drivers/gpu/drm/drm_plane.c
>> @@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>>  	return num;
>>  }
>>
>> +struct drm_format_modifier_blob {
>> +#define FORMAT_BLOB_CURRENT 1
>> +	/* Version of this blob format */
>> +	u32 version;
>> +
>> +	/* Flags */
>> +	u32 flags;
>> +
>> +	/* Number of fourcc formats supported */
>> +	u32 count_formats;
>> +
>> +	/* Where in this blob the formats exist (in bytes) */
>> +	u32 formats_offset;
>> +
>> +	/* Number of drm_format_modifiers */
>> +	u32 count_modifiers;
>> +
>> +	/* Where in this blob the modifiers exist (in bytes) */
>> +	u32 modifiers_offset;
>> +
>> +	/* u32 formats[] */
>> +	/* struct drm_format_modifier modifiers[] */
>> +} __packed;
>
>The struct should be in the uapi header. Otherwise it won't show up in
>libdrm headers when following the proper process.
>-Daniel
>

I don't agree that blobs are ever really part of the API, but it doesn't hurt to
move it... in other words, done.

>> +
>> +static inline u32 *
>> +formats_ptr(struct drm_format_modifier_blob *blob)
>> +{
>> +	return (u32 *)(((char *)blob) + blob->formats_offset);
>> +}
>> +
>> +static inline struct drm_format_modifier *
>> +modifiers_ptr(struct drm_format_modifier_blob *blob)
>> +{
>> +	return (struct drm_format_modifier *)(((char *)blob) + blob->modifiers_offset);
>> +}
>> +
>> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane *plane,
>> +				 const struct drm_plane_funcs *funcs,
>> +				 const uint32_t *formats, unsigned int format_count,
>> +				 const uint64_t *format_modifiers)
>> +{
>> +	const struct drm_mode_config *config = &dev->mode_config;
>> +	const uint64_t *temp_modifiers = format_modifiers;
>> +	unsigned int format_modifier_count = 0;
>> +	struct drm_property_blob *blob = NULL;
>> +	struct drm_format_modifier *mod;
>> +	size_t blob_size = 0, formats_size, modifiers_size;
>> +	struct drm_format_modifier_blob *blob_data;
>> +	int i, j, ret = 0;
>> +
>> +	if (format_modifiers)
>> +		while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
>> +			format_modifier_count++;
>> +
>> +	formats_size = sizeof(__u32) * format_count;
>> +	if (WARN_ON(!formats_size)) {
>> +		/* 0 formats are never expected */
>> +		return 0;
>> +	}
>> +
>> +	modifiers_size =
>> +		sizeof(struct drm_format_modifier) * format_modifier_count;
>> +
>> +	blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
>> +	blob_size += ALIGN(formats_size, 8);
>> +	blob_size += modifiers_size;
>> +
>> +	blob = drm_property_create_blob(dev, blob_size, NULL);
>> +	if (IS_ERR(blob))
>> +		return -1;
>> +
>> +	blob_data = (struct drm_format_modifier_blob *)blob->data;
>> +	blob_data->version = FORMAT_BLOB_CURRENT;
>> +	blob_data->count_formats = format_count;
>> +	blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
>> +	blob_data->count_modifiers = format_modifier_count;
>> +
>> +	/* Modifiers offset is a pointer to a struct with a 64 bit field so it
>> +	 * should be naturally aligned to 8B.
>> +	 */
>> +	blob_data->modifiers_offset =
>> +		ALIGN(blob_data->formats_offset + formats_size, 8);
>> +
>> +	memcpy(formats_ptr(blob_data), formats, formats_size);
>> +
>> +	/* If we can't determine support, just bail */
>> +	if (!funcs->format_mod_supported)
>> +		goto done;
>> +
>> +	mod = modifiers_ptr(blob_data);
>> +	for (i = 0; i < format_modifier_count; i++) {
>> +		for (j = 0; j < format_count; j++) {
>> +			if (funcs->format_mod_supported(plane, formats[j],
>> +							format_modifiers[i])) {
>> +				mod->formats |= 1 << j;
>> +			}
>> +		}
>> +
>> +		mod->modifier = format_modifiers[i];
>> +		mod->offset = 0;
>> +		mod->pad = 0;
>> +		mod++;
>> +	}
>> +
>> +done:
>> +	drm_object_attach_property(&plane->base, config->modifiers,
>> +				   blob->base.id);
>> +
>> +	return ret;
>> +}
>> +
>>  /**
>>   * drm_universal_plane_init - Initialize a new universal plane object
>>   * @dev: DRM device
>> @@ -130,6 +241,10 @@ 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 (name) {
>>  		va_list ap;
>>
>> @@ -177,6 +292,10 @@ int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
>>  		drm_object_attach_property(&plane->base, config->prop_src_h, 0);
>>  	}
>>
>> +	if (config->allow_fb_modifiers)
>> +		create_in_format_blob(dev, plane, funcs, formats, format_count,
>> +				      format_modifiers);
>> +
>>  	return 0;
>>  }
>>  EXPORT_SYMBOL(drm_universal_plane_init);
>> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>> index 42981711189b..03776e659811 100644
>> --- a/include/drm/drm_mode_config.h
>> +++ b/include/drm/drm_mode_config.h
>> @@ -757,6 +757,12 @@ struct drm_mode_config {
>>  	 */
>>  	bool allow_fb_modifiers;
>>
>> +	/**
>> +	 * @modifiers: Plane property to list support modifier/format
>> +	 * combination.
>> +	 */
>> +	struct drm_property *modifiers;
>> +
>>  	/* cursor size */
>>  	uint32_t cursor_width, cursor_height;
>>
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index 8c67fc03d53d..dcdd04c55792 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -665,6 +665,32 @@ struct drm_mode_atomic {
>>  	__u64 user_data;
>>  };
>>
>> +struct drm_format_modifier {
>> +       /* Bitmask of formats in get_plane format list this info applies to. The
>> +	* offset allows a sliding window of which 64 formats (bits).
>> +	*
>> +	* Some examples:
>> +	* In today's world with < 65 formats, and formats 0, and 2 are
>> +	* supported
>> +	* 0x0000000000000005
>> +	*		  ^-offset = 0, formats = 5
>> +	*
>> +	* If the number formats grew to 128, and formats 98-102 are
>> +	* supported with the modifier:
>> +	*
>> +	* 0x0000003c00000000 0000000000000000
>> +	*		  ^
>> +	*		  |__offset = 64, formats = 0x3c00000000
>> +	*
>> +	*/
>> +       uint64_t formats;
>> +       uint32_t offset;
>> +       uint32_t pad;
>> +
>> +       /* This modifier can be used with the format for this plane. */
>> +       uint64_t modifier;
>> +} __packed;
>> +
>>  /**
>>   * Create a new 'blob' data property, copying length bytes from data pointer,
>>   * and returning new blob ID.
>> --
>> 2.12.2
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>-- 
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-16 21:19     ` [Intel-gfx] " Ben Widawsky
@ 2017-05-17 11:31       ` Daniel Vetter
  2017-05-17 15:12         ` Daniel Vetter
  2017-05-18  0:00         ` Ben Widawsky
  0 siblings, 2 replies; 37+ messages in thread
From: Daniel Vetter @ 2017-05-17 11:31 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Intel GFX, Kristian H . Kristensen, DRI Development, Daniel Stone

On Tue, May 16, 2017 at 02:19:12PM -0700, Ben Widawsky wrote:
> On 17-05-03 17:08:27, Daniel Vetter wrote:
> > On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
> > > +struct drm_format_modifier_blob {
> > > +#define FORMAT_BLOB_CURRENT 1
> > > +	/* Version of this blob format */
> > > +	u32 version;
> > > +
> > > +	/* Flags */
> > > +	u32 flags;
> > > +
> > > +	/* Number of fourcc formats supported */
> > > +	u32 count_formats;
> > > +
> > > +	/* Where in this blob the formats exist (in bytes) */
> > > +	u32 formats_offset;
> > > +
> > > +	/* Number of drm_format_modifiers */
> > > +	u32 count_modifiers;
> > > +
> > > +	/* Where in this blob the modifiers exist (in bytes) */
> > > +	u32 modifiers_offset;
> > > +
> > > +	/* u32 formats[] */
> > > +	/* struct drm_format_modifier modifiers[] */
> > > +} __packed;
> > 
> > The struct should be in the uapi header. Otherwise it won't show up in
> > libdrm headers when following the proper process.
> > -Daniel
> > 
> 
> I don't agree that blobs are ever really part of the API, but it doesn't hurt to
> move it... in other words, done.

Userspace writes them, the kernel reads them (or maybe even the other way
round). How exactly is a specific blob and its layout not part of uapi?
Can you explain your reasoning here pls?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-17 11:31       ` Daniel Vetter
@ 2017-05-17 15:12         ` Daniel Vetter
  2017-05-18  0:00         ` Ben Widawsky
  1 sibling, 0 replies; 37+ messages in thread
From: Daniel Vetter @ 2017-05-17 15:12 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: Intel GFX, Kristian H . Kristensen, DRI Development, Daniel Stone

On Wed, May 17, 2017 at 1:31 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, May 16, 2017 at 02:19:12PM -0700, Ben Widawsky wrote:
>> On 17-05-03 17:08:27, Daniel Vetter wrote:
>> > On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>> > > +struct drm_format_modifier_blob {
>> > > +#define FORMAT_BLOB_CURRENT 1
>> > > + /* Version of this blob format */
>> > > + u32 version;
>> > > +
>> > > + /* Flags */
>> > > + u32 flags;
>> > > +
>> > > + /* Number of fourcc formats supported */
>> > > + u32 count_formats;
>> > > +
>> > > + /* Where in this blob the formats exist (in bytes) */
>> > > + u32 formats_offset;
>> > > +
>> > > + /* Number of drm_format_modifiers */
>> > > + u32 count_modifiers;
>> > > +
>> > > + /* Where in this blob the modifiers exist (in bytes) */
>> > > + u32 modifiers_offset;
>> > > +
>> > > + /* u32 formats[] */
>> > > + /* struct drm_format_modifier modifiers[] */
>> > > +} __packed;
>> >
>> > The struct should be in the uapi header. Otherwise it won't show up in
>> > libdrm headers when following the proper process.
>> > -Daniel
>> >
>>
>> I don't agree that blobs are ever really part of the API, but it doesn't hurt to
>> move it... in other words, done.
>
> Userspace writes them, the kernel reads them (or maybe even the other way
> round). How exactly is a specific blob and its layout not part of uapi?
> Can you explain your reasoning here pls?

Ok, this is the other way round, kernel writes this, userspace reads
it. Question still stands.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-17 11:31       ` Daniel Vetter
  2017-05-17 15:12         ` Daniel Vetter
@ 2017-05-18  0:00         ` Ben Widawsky
  2017-05-18  0:38           ` Rob Clark
  1 sibling, 1 reply; 37+ messages in thread
From: Ben Widawsky @ 2017-05-18  0:00 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Intel GFX, Kristian H . Kristensen, Daniel Stone, DRI Development

On 17-05-17 13:31:44, Daniel Vetter wrote:
>On Tue, May 16, 2017 at 02:19:12PM -0700, Ben Widawsky wrote:
>> On 17-05-03 17:08:27, Daniel Vetter wrote:
>> > On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>> > > +struct drm_format_modifier_blob {
>> > > +#define FORMAT_BLOB_CURRENT 1
>> > > +	/* Version of this blob format */
>> > > +	u32 version;
>> > > +
>> > > +	/* Flags */
>> > > +	u32 flags;
>> > > +
>> > > +	/* Number of fourcc formats supported */
>> > > +	u32 count_formats;
>> > > +
>> > > +	/* Where in this blob the formats exist (in bytes) */
>> > > +	u32 formats_offset;
>> > > +
>> > > +	/* Number of drm_format_modifiers */
>> > > +	u32 count_modifiers;
>> > > +
>> > > +	/* Where in this blob the modifiers exist (in bytes) */
>> > > +	u32 modifiers_offset;
>> > > +
>> > > +	/* u32 formats[] */
>> > > +	/* struct drm_format_modifier modifiers[] */
>> > > +} __packed;
>> >
>> > The struct should be in the uapi header. Otherwise it won't show up in
>> > libdrm headers when following the proper process.
>> > -Daniel
>> >
>>
>> I don't agree that blobs are ever really part of the API, but it doesn't hurt to
>> move it... in other words, done.
>
>Userspace writes them, the kernel reads them (or maybe even the other way
>round). How exactly is a specific blob and its layout not part of uapi?
>Can you explain your reasoning here pls?
>-Daniel

The API says there is a blob. If we wanted the fields in the blob to be explicit
we'd make an API that has the exact structure.

-- 
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-18  0:00         ` Ben Widawsky
@ 2017-05-18  0:38           ` Rob Clark
  2017-05-18  0:42             ` [Intel-gfx] " Rob Clark
  0 siblings, 1 reply; 37+ messages in thread
From: Rob Clark @ 2017-05-18  0:38 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: DRI Development, Intel GFX, Kristian H . Kristensen, Daniel Stone

On Wed, May 17, 2017 at 8:00 PM, Ben Widawsky <ben@bwidawsk.net> wrote:
> On 17-05-17 13:31:44, Daniel Vetter wrote:
>>
>> On Tue, May 16, 2017 at 02:19:12PM -0700, Ben Widawsky wrote:
>>>
>>> On 17-05-03 17:08:27, Daniel Vetter wrote:
>>> > On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>>> > > +struct drm_format_modifier_blob {
>>> > > +#define FORMAT_BLOB_CURRENT 1
>>> > > +   /* Version of this blob format */
>>> > > +   u32 version;
>>> > > +
>>> > > +   /* Flags */
>>> > > +   u32 flags;
>>> > > +
>>> > > +   /* Number of fourcc formats supported */
>>> > > +   u32 count_formats;
>>> > > +
>>> > > +   /* Where in this blob the formats exist (in bytes) */
>>> > > +   u32 formats_offset;
>>> > > +
>>> > > +   /* Number of drm_format_modifiers */
>>> > > +   u32 count_modifiers;
>>> > > +
>>> > > +   /* Where in this blob the modifiers exist (in bytes) */
>>> > > +   u32 modifiers_offset;
>>> > > +
>>> > > +   /* u32 formats[] */
>>> > > +   /* struct drm_format_modifier modifiers[] */
>>> > > +} __packed;
>>> >
>>> > The struct should be in the uapi header. Otherwise it won't show up in
>>> > libdrm headers when following the proper process.
>>> > -Daniel
>>> >
>>>
>>> I don't agree that blobs are ever really part of the API, but it doesn't
>>> hurt to
>>> move it... in other words, done.
>>
>>
>> Userspace writes them, the kernel reads them (or maybe even the other way
>> round). How exactly is a specific blob and its layout not part of uapi?
>> Can you explain your reasoning here pls?
>> -Daniel
>
>
> The API says there is a blob. If we wanted the fields in the blob to be
> explicit
> we'd make an API that has the exact structure.
>

well, maybe don't confuse uabi and what can be represented in a 'C' struct..

we've designed the blob layout w/ uabi in mind (ie. w/ offsets to the
different sections, etc).. doesn't necessarily mean it is something
representable as a 'C' struct.. but it's still a form of uabi..

BR,
-R
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob
  2017-05-18  0:38           ` Rob Clark
@ 2017-05-18  0:42             ` Rob Clark
  0 siblings, 0 replies; 37+ messages in thread
From: Rob Clark @ 2017-05-18  0:42 UTC (permalink / raw)
  To: Ben Widawsky
  Cc: DRI Development, Intel GFX, Kristian H . Kristensen, Daniel Stone

On Wed, May 17, 2017 at 8:38 PM, Rob Clark <robdclark@gmail.com> wrote:
> On Wed, May 17, 2017 at 8:00 PM, Ben Widawsky <ben@bwidawsk.net> wrote:
>> On 17-05-17 13:31:44, Daniel Vetter wrote:
>>>
>>> On Tue, May 16, 2017 at 02:19:12PM -0700, Ben Widawsky wrote:
>>>>
>>>> On 17-05-03 17:08:27, Daniel Vetter wrote:
>>>> > On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>>>> > > +struct drm_format_modifier_blob {
>>>> > > +#define FORMAT_BLOB_CURRENT 1
>>>> > > +   /* Version of this blob format */
>>>> > > +   u32 version;
>>>> > > +
>>>> > > +   /* Flags */
>>>> > > +   u32 flags;
>>>> > > +
>>>> > > +   /* Number of fourcc formats supported */
>>>> > > +   u32 count_formats;
>>>> > > +
>>>> > > +   /* Where in this blob the formats exist (in bytes) */
>>>> > > +   u32 formats_offset;
>>>> > > +
>>>> > > +   /* Number of drm_format_modifiers */
>>>> > > +   u32 count_modifiers;
>>>> > > +
>>>> > > +   /* Where in this blob the modifiers exist (in bytes) */
>>>> > > +   u32 modifiers_offset;
>>>> > > +
>>>> > > +   /* u32 formats[] */
>>>> > > +   /* struct drm_format_modifier modifiers[] */
>>>> > > +} __packed;
>>>> >
>>>> > The struct should be in the uapi header. Otherwise it won't show up in
>>>> > libdrm headers when following the proper process.
>>>> > -Daniel
>>>> >
>>>>
>>>> I don't agree that blobs are ever really part of the API, but it doesn't
>>>> hurt to
>>>> move it... in other words, done.
>>>
>>>
>>> Userspace writes them, the kernel reads them (or maybe even the other way
>>> round). How exactly is a specific blob and its layout not part of uapi?
>>> Can you explain your reasoning here pls?
>>> -Daniel
>>
>>
>> The API says there is a blob. If we wanted the fields in the blob to be
>> explicit
>> we'd make an API that has the exact structure.
>>
>
> well, maybe don't confuse uabi and what can be represented in a 'C' struct..
>
> we've designed the blob layout w/ uabi in mind (ie. w/ offsets to the
> different sections, etc).. doesn't necessarily mean it is something
> representable as a 'C' struct.. but it's still a form of uabi..
>

and by "we've" I really mean Ben plus irc and/or list bikeshedding
from daniels and myself and various others..

BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 37+ messages in thread
end of thread, other threads:[~2017-05-18  0:42 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-03  5:14 [PATCH 1/3] drm: Plumb modifiers through plane init Ben Widawsky
2017-05-03  5:14 ` [PATCH 2/3] drm: Create a format/modifier blob Ben Widawsky
2017-05-03 11:00   ` Brian Starkey
2017-05-03 11:47     ` Daniel Stone
2017-05-03 12:39       ` Brian Starkey
2017-05-03 12:51   ` Brian Starkey
2017-05-03 13:51     ` [Intel-gfx] " Daniel Stone
2017-05-03 14:03       ` Brian Starkey
2017-05-03 14:07         ` [Intel-gfx] " Daniel Stone
2017-05-03 14:17           ` Brian Starkey
2017-05-03 13:15   ` Liviu Dudau
2017-05-11 17:58     ` Ben Widawsky
2017-05-03 13:32   ` Emil Velikov
2017-05-03 15:08   ` Daniel Vetter
2017-05-16 21:19     ` [Intel-gfx] " Ben Widawsky
2017-05-17 11:31       ` Daniel Vetter
2017-05-17 15:12         ` Daniel Vetter
2017-05-18  0:00         ` Ben Widawsky
2017-05-18  0:38           ` Rob Clark
2017-05-18  0:42             ` [Intel-gfx] " Rob Clark
2017-05-04  9:28   ` Daniel Stone
2017-05-03  5:14 ` [PATCH 3/3] drm/i915: Add format modifiers for Intel Ben Widawsky
2017-05-03  5:30 ` ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Plumb modifiers through plane init Patchwork
2017-05-03 10:34 ` [PATCH 1/3] " Liviu Dudau
2017-05-03 13:45   ` [Intel-gfx] " Daniel Stone
2017-05-03 14:07     ` Liviu Dudau
2017-05-03 14:14       ` Daniel Stone
2017-05-03 14:52         ` Liviu Dudau
2017-05-03 16:45           ` Daniel Vetter
2017-05-03 17:30             ` [Intel-gfx] " Liviu Dudau
2017-05-10 16:34               ` Ben Widawsky
2017-05-10 17:24                 ` Liviu Dudau
2017-05-10 19:33                   ` [Intel-gfx] " Ben Widawsky
2017-05-10 20:21                     ` Liviu Dudau
2017-05-10 16:33     ` Ben Widawsky
2017-05-03 18:28 ` kbuild test robot
2017-05-03 18:48 ` kbuild test robot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.