All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] drm: Add the optional .fb_modifier() hook
@ 2018-03-12 20:40 Ville Syrjala
  2018-03-12 20:40 ` [PATCH 2/3] drm: Make sure at least one plane supports the fb format Ville Syrjala
                   ` (5 more replies)
  0 siblings, 6 replies; 19+ messages in thread
From: Ville Syrjala @ 2018-03-12 20:40 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

To make it possible for the core to check the fb pixel format and
modifier, we need to first ask the driver to deduce the modifier
when the request does not explicitly specify one.

Add a new .fb_modifier() hook for that purpose and convert i915
and vc4 to make use if it. All other drivers seem to currently
assume linear when the request does not specify anything else,
hence we make the core use that as the fallback strategy when
the hook is not provided.

Since the two hooks are now separate it is of course possible
to race set_tiling against addfb. But since that's just userspace
intentially shooting itself in the foot I don't think we should
hve to worry about it. The addfb will simply fail in the
.fb_create() hook if the tiling has changed since
.fb_mofifier() was called. Well, that's the case for i915.
vc4 never did any cross checks between the tiling and modifier.

framebuffer_check() now checks the request against the deduced
modifier, and since we now know the final modifier we can
convert the request to one with modifiers. This means that a
driver will never even have to look at a request without
modifiers outside of the .fb_modifuer() hook, should it need
to provide one.

Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/drm_framebuffer.c    | 61 +++++++++++++++++++++--------
 drivers/gpu/drm/i915/intel_display.c | 74 ++++++++++++++++++++++++------------
 drivers/gpu/drm/i915/intel_drv.h     |  2 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |  2 +
 drivers/gpu/drm/vc4/vc4_kms.c        | 57 +++++++++++----------------
 include/drm/drm_mode_config.h        | 29 ++++++++++++++
 6 files changed, 150 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
index 7df025669067..21d3d51eb261 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -153,7 +153,8 @@ static int fb_plane_height(int height,
 }
 
 static int framebuffer_check(struct drm_device *dev,
-			     const struct drm_mode_fb_cmd2 *r)
+			     struct drm_mode_fb_cmd2 *r,
+			     u64 modifier)
 {
 	const struct drm_format_info *info;
 	int i;
@@ -210,14 +211,14 @@ static int framebuffer_check(struct drm_device *dev,
 		}
 
 		if (r->flags & DRM_MODE_FB_MODIFIERS &&
-		    r->modifier[i] != r->modifier[0]) {
+		    r->modifier[i] != modifier) {
 			DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
 				      r->modifier[i], i);
 			return -EINVAL;
 		}
 
 		/* modifier specific checks: */
-		switch (r->modifier[i]) {
+		switch (modifier) {
 		case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
 			/* NOTE: the pitch restriction may be lifted later if it turns
 			 * out that no hw has this restriction:
@@ -261,45 +262,73 @@ static int framebuffer_check(struct drm_device *dev,
 		}
 	}
 
+	/*
+	 * Finally convert the request into one with
+	 * modifiers to make life easier for drivers.
+	 */
+	if (dev->mode_config.allow_fb_modifiers) {
+		r->flags |= DRM_MODE_FB_MODIFIERS;
+
+		for (i = 0; i < info->num_planes; i++)
+			r->modifier[i] = modifier;
+	}
+
 	return 0;
 }
 
 struct drm_framebuffer *
 drm_internal_framebuffer_create(struct drm_device *dev,
-				const struct drm_mode_fb_cmd2 *r,
+				const struct drm_mode_fb_cmd2 *user_r,
 				struct drm_file *file_priv)
 {
 	struct drm_mode_config *config = &dev->mode_config;
+	struct drm_mode_fb_cmd2 r = *user_r;
 	struct drm_framebuffer *fb;
+	u64 modifier = 0;
 	int ret;
 
-	if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
-		DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
+	if (r.flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
+		DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r.flags);
 		return ERR_PTR(-EINVAL);
 	}
 
-	if ((config->min_width > r->width) || (r->width > config->max_width)) {
+	if (config->min_width > r.width || r.width > config->max_width) {
 		DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && <= %d\n",
-			  r->width, config->min_width, config->max_width);
+			  r.width, config->min_width, config->max_width);
 		return ERR_PTR(-EINVAL);
 	}
-	if ((config->min_height > r->height) || (r->height > config->max_height)) {
+	if (config->min_height > r.height || r.height > config->max_height) {
 		DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d && <= %d\n",
-			  r->height, config->min_height, config->max_height);
+			  r.height, config->min_height, config->max_height);
 		return ERR_PTR(-EINVAL);
 	}
 
-	if (r->flags & DRM_MODE_FB_MODIFIERS &&
-	    !dev->mode_config.allow_fb_modifiers) {
-		DRM_DEBUG_KMS("driver does not support fb modifiers\n");
-		return ERR_PTR(-EINVAL);
+	if (r.flags & DRM_MODE_FB_MODIFIERS) {
+		if (!dev->mode_config.allow_fb_modifiers) {
+			DRM_DEBUG_KMS("driver does not support fb modifiers\n");
+			return ERR_PTR(-EINVAL);
+		}
+
+		modifier = r.modifier[0];
+	} else {
+		if (dev->mode_config.funcs->fb_modifier) {
+			ret = dev->mode_config.funcs->fb_modifier(dev, file_priv,
+								  &r, &modifier);
+			if (ret) {
+				DRM_DEBUG_KMS("driver did not deduce the fb modifier\n");
+				return ERR_PTR(ret);
+			}
+		} else {
+			/* assume linear if the driver doesn't say otherwise */
+			modifier = DRM_FORMAT_MOD_LINEAR;
+		}
 	}
 
-	ret = framebuffer_check(dev, r);
+	ret = framebuffer_check(dev, &r, modifier);
 	if (ret)
 		return ERR_PTR(ret);
 
-	fb = dev->mode_config.funcs->fb_create(dev, file_priv, r);
+	fb = dev->mode_config.funcs->fb_create(dev, file_priv, &r);
 	if (IS_ERR(fb)) {
 		DRM_DEBUG_KMS("could not create framebuffer\n");
 		return fb;
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 2933ad38094f..51d8d0c40674 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -123,7 +123,7 @@ static void ironlake_pch_clock_get(struct intel_crtc *crtc,
 
 static int intel_framebuffer_init(struct intel_framebuffer *ifb,
 				  struct drm_i915_gem_object *obj,
-				  struct drm_mode_fb_cmd2 *mode_cmd);
+				  const struct drm_mode_fb_cmd2 *mode_cmd);
 static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc);
 static void intel_set_pipe_timings(struct intel_crtc *intel_crtc);
 static void intel_set_pipe_src_size(struct intel_crtc *intel_crtc);
@@ -9807,7 +9807,7 @@ static const struct drm_display_mode load_detect_mode = {
 
 struct drm_framebuffer *
 intel_framebuffer_create(struct drm_i915_gem_object *obj,
-			 struct drm_mode_fb_cmd2 *mode_cmd)
+			 const struct drm_mode_fb_cmd2 *mode_cmd)
 {
 	struct intel_framebuffer *intel_fb;
 	int ret;
@@ -13985,7 +13985,7 @@ u32 intel_fb_pitch_limit(struct drm_i915_private *dev_priv,
 
 static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 				  struct drm_i915_gem_object *obj,
-				  struct drm_mode_fb_cmd2 *mode_cmd)
+				  const struct drm_mode_fb_cmd2 *mode_cmd)
 {
 	struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
 	struct drm_framebuffer *fb = &intel_fb->base;
@@ -13995,29 +13995,23 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 	int ret = -EINVAL;
 	int i;
 
+	if (WARN_ON((mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0))
+		return -EINVAL;
+
 	i915_gem_object_lock(obj);
 	obj->framebuffer_references++;
 	tiling = i915_gem_object_get_tiling(obj);
 	stride = i915_gem_object_get_stride(obj);
 	i915_gem_object_unlock(obj);
 
-	if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
-		/*
-		 * If there's a fence, enforce that
-		 * the fb modifier and tiling mode match.
-		 */
-		if (tiling != I915_TILING_NONE &&
-		    tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
-			DRM_DEBUG_KMS("tiling_mode doesn't match fb modifier\n");
-			goto err;
-		}
-	} else {
-		if (tiling == I915_TILING_X) {
-			mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
-		} else if (tiling == I915_TILING_Y) {
-			DRM_DEBUG_KMS("No Y tiling for legacy addfb\n");
-			goto err;
-		}
+	/*
+	 * If there's a fence, enforce that
+	 * the fb modifier and tiling mode match.
+	 */
+	if (tiling != I915_TILING_NONE &&
+	    tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
+		DRM_DEBUG_KMS("tiling_mode doesn't match fb modifier\n");
+		goto err;
 	}
 
 	/* Passed in modifier sanity checking. */
@@ -14193,20 +14187,51 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 	return ret;
 }
 
+static int
+intel_user_framebuffer_modifier(struct drm_device *dev,
+				struct drm_file *filp,
+				const struct drm_mode_fb_cmd2 *mode_cmd,
+				u64 *modifier)
+{
+	struct drm_i915_gem_object *obj;
+	unsigned int tiling;
+
+	obj = i915_gem_object_lookup(filp, mode_cmd->handles[0]);
+	if (!obj)
+		return -ENOENT;
+
+	i915_gem_object_lock(obj);
+	tiling = i915_gem_object_get_tiling(obj);
+	i915_gem_object_unlock(obj);
+
+	i915_gem_object_put(obj);
+
+	if (tiling == I915_TILING_Y) {
+		DRM_DEBUG_KMS("No Y tiling for legacy addfb\n");
+		return -EINVAL;
+	}
+
+	if (tiling == I915_TILING_X)
+		*modifier = I915_FORMAT_MOD_X_TILED;
+	else
+		*modifier = DRM_FORMAT_MOD_LINEAR;
+
+	return 0;
+}
+
 static struct drm_framebuffer *
 intel_user_framebuffer_create(struct drm_device *dev,
 			      struct drm_file *filp,
-			      const struct drm_mode_fb_cmd2 *user_mode_cmd)
+			      const struct drm_mode_fb_cmd2 *mode_cmd)
 {
 	struct drm_framebuffer *fb;
 	struct drm_i915_gem_object *obj;
-	struct drm_mode_fb_cmd2 mode_cmd = *user_mode_cmd;
 
-	obj = i915_gem_object_lookup(filp, mode_cmd.handles[0]);
+	obj = i915_gem_object_lookup(filp, mode_cmd->handles[0]);
 	if (!obj)
 		return ERR_PTR(-ENOENT);
 
-	fb = intel_framebuffer_create(obj, &mode_cmd);
+	fb = intel_framebuffer_create(obj, mode_cmd);
 	if (IS_ERR(fb))
 		i915_gem_object_put(obj);
 
@@ -14251,6 +14276,7 @@ intel_mode_valid(struct drm_device *dev,
 }
 
 static const struct drm_mode_config_funcs intel_mode_funcs = {
+	.fb_modifier = intel_user_framebuffer_modifier,
 	.fb_create = intel_user_framebuffer_create,
 	.get_format_info = intel_get_format_info,
 	.output_poll_changed = intel_fbdev_output_poll_changed,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fce5d3072d97..678755297814 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1517,7 +1517,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
 void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags);
 struct drm_framebuffer *
 intel_framebuffer_create(struct drm_i915_gem_object *obj,
-			 struct drm_mode_fb_cmd2 *mode_cmd);
+			 const struct drm_mode_fb_cmd2 *mode_cmd);
 int intel_prepare_plane_fb(struct drm_plane *plane,
 			   struct drm_plane_state *new_state);
 void intel_cleanup_plane_fb(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index 6f12adc06365..777f5bfbe8ef 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -131,6 +131,8 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
 				    DIV_ROUND_UP(sizes->surface_bpp, 8), 64);
 	mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
 							  sizes->surface_depth);
+	mode_cmd.modifier[0] = DRM_FORMAT_MOD_LINEAR;
+	mode_cmd.flags = DRM_MODE_FB_MODIFIERS;
 
 	size = mode_cmd.pitches[0] * mode_cmd.height;
 	size = PAGE_ALIGN(size);
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ba60153dddb5..a8aed12db578 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -148,50 +148,39 @@ static int vc4_atomic_commit(struct drm_device *dev,
 	return 0;
 }
 
-static struct drm_framebuffer *vc4_fb_create(struct drm_device *dev,
-					     struct drm_file *file_priv,
-					     const struct drm_mode_fb_cmd2 *mode_cmd)
+static int vc4_fb_modifier(struct drm_device *dev,
+			   struct drm_file *file_priv,
+			   const struct drm_mode_fb_cmd2 *mode_cmd,
+			   u64 *modifier)
 {
-	struct drm_mode_fb_cmd2 mode_cmd_local;
-
-	/* If the user didn't specify a modifier, use the
-	 * vc4_set_tiling_ioctl() state for the BO.
-	 */
-	if (!(mode_cmd->flags & DRM_MODE_FB_MODIFIERS)) {
-		struct drm_gem_object *gem_obj;
-		struct vc4_bo *bo;
-
-		gem_obj = drm_gem_object_lookup(file_priv,
-						mode_cmd->handles[0]);
-		if (!gem_obj) {
-			DRM_DEBUG("Failed to look up GEM BO %d\n",
-				  mode_cmd->handles[0]);
-			return ERR_PTR(-ENOENT);
-		}
-		bo = to_vc4_bo(gem_obj);
-
-		mode_cmd_local = *mode_cmd;
-
-		if (bo->t_format) {
-			mode_cmd_local.modifier[0] =
-				DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED;
-		} else {
-			mode_cmd_local.modifier[0] = DRM_FORMAT_MOD_NONE;
-		}
+	struct drm_gem_object *gem_obj;
+	struct vc4_bo *bo;
+
+	gem_obj = drm_gem_object_lookup(file_priv,
+					mode_cmd->handles[0]);
+	if (!gem_obj) {
+		DRM_DEBUG("Failed to look up GEM BO %d\n",
+			  mode_cmd->handles[0]);
+		return -ENOENT;
+	}
+	bo = to_vc4_bo(gem_obj);
 
-		drm_gem_object_put_unlocked(gem_obj);
+	if (bo->t_format)
+		*modifier = DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED;
+	else
+		*modifier = DRM_FORMAT_MOD_LINEAR;
 
-		mode_cmd = &mode_cmd_local;
-	}
+	drm_gem_object_put_unlocked(gem_obj);
 
-	return drm_gem_fb_create(dev, file_priv, mode_cmd);
+	return 0;
 }
 
 static const struct drm_mode_config_funcs vc4_mode_funcs = {
 	.output_poll_changed = drm_fb_helper_output_poll_changed,
 	.atomic_check = drm_atomic_helper_check,
 	.atomic_commit = vc4_atomic_commit,
-	.fb_create = vc4_fb_create,
+	.fb_modifier = vc4_fb_modifier,
+	.fb_create = drm_gem_fb_create,
 };
 
 int vc4_kms_load(struct drm_device *dev)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7569f22ffef6..c74aed292b58 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -45,6 +45,30 @@ struct drm_display_mode;
  * involve drivers.
  */
 struct drm_mode_config_funcs {
+	/**
+	 * @fb_modifier:
+	 *
+	 * Deduce the format modifier using a driver specific method. This
+	 * gets called when the request does not explicitly state the
+	 * modifier, ie. (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0.
+	 * The deduced modifier is returned via @modifier.
+	 *
+	 * Once the modifier is known several sanity checks will be performed
+	 * and if all is deemed valid @fb_create() will be called to have
+	 * the driver to actually create the framebuffer.
+	 *
+	 * This hook is optional. The core will assume DRM_FORMAT_MOD_LINEAR
+	 * if the hook is not provided by the driver.
+	 *
+	 * RETURNS:
+	 *
+	 * Zero on success, negative error code on failure.
+	 */
+	int (*fb_modifier)(struct drm_device *dev,
+			   struct drm_file *file_priv,
+			   const struct drm_mode_fb_cmd2 *mode_cmd,
+			   u64 *modifier);
+
 	/**
 	 * @fb_create:
 	 *
@@ -52,6 +76,11 @@ struct drm_mode_config_funcs {
 	 * requested metadata, but most of that is left to the driver. See
 	 * &struct drm_mode_fb_cmd2 for details.
 	 *
+	 * Note that for drivers that support modifiers, the core will convert
+	 * all requests to one with modifiers. So the driver does not need to
+	 * worry about requests without modifiers (apart from having to provide
+	 * the @fb_modifier() hook if necessary).
+	 *
 	 * If the parameters are deemed valid and the backing storage objects in
 	 * the underlying memory manager all exist, then the driver allocates
 	 * a new &drm_framebuffer structure, subclassed to contain
-- 
2.16.1

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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [PATCH 2/3] drm: Make sure at least one plane supports the fb format
  2018-03-12 20:40 [PATCH 1/3] drm: Add the optional .fb_modifier() hook Ville Syrjala
@ 2018-03-12 20:40 ` Ville Syrjala
  2018-03-15 17:42   ` Eric Anholt
  2018-03-12 20:40 ` [PATCH 3/3] drm/i915: Eliminate the horrendous format check code Ville Syrjala
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 19+ messages in thread
From: Ville Syrjala @ 2018-03-12 20:40 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

To make life easier for drivers, let's have the core check that the
requested pixel format is supported by at least one plane when creating
a new framebuffer.

This eases the burden on drivers by making sure they'll never get
requests to create fbs with unsupported pixel formats. Thanks to the
new .fb_modifier() hook this check can now be done whether the request
specifies the modifier directly or driver has to deduce it from the
gem bo tiling (or via any other method really).

v0: Accept anyformat if the driver doesn't do planes (Eric)
    s/planes_have_format/any_plane_has_format/ (Eric)
    Check the modifier as well since we already have a function
    that does both
v3: Don't do the check in the core since we may not know the
    modifier yet, instead export the function and let drivers
    call it themselves
v4: Unexport the functiona and put the format_default check back
    since this will again be called by the core, ie. undo v3 ;)

Cc: Eric Anholt <eric@anholt.net>
Testcase: igt/kms_addfb_basic/expected-formats
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/drm_framebuffer.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
index 21d3d51eb261..e618a6b728d4 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -152,6 +152,26 @@ static int fb_plane_height(int height,
 	return DIV_ROUND_UP(height, format->vsub);
 }
 
+static bool any_plane_has_format(struct drm_device *dev,
+				 u32 format, u64 modifier)
+{
+	struct drm_plane *plane;
+
+	drm_for_each_plane(plane, dev) {
+		/*
+		 * In case the driver doesn't really do
+		 * planes we have to accept any format here.
+		 */
+		if (plane->format_default)
+			return true;
+
+		if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
+			return true;
+	}
+
+	return false;
+}
+
 static int framebuffer_check(struct drm_device *dev,
 			     struct drm_mode_fb_cmd2 *r,
 			     u64 modifier)
@@ -183,6 +203,16 @@ static int framebuffer_check(struct drm_device *dev,
 		return -EINVAL;
 	}
 
+	if (!any_plane_has_format(dev, r->pixel_format, modifier)) {
+		struct drm_format_name_buf format_name;
+
+		DRM_DEBUG_KMS("unsupported pixel format %s / modifier 0x%llx\n",
+			      drm_get_format_name(r->pixel_format,
+						  &format_name),
+			      modifier);
+		return -EINVAL;
+	}
+
 	for (i = 0; i < info->num_planes; i++) {
 		unsigned int width = fb_plane_width(r->width, info, i);
 		unsigned int height = fb_plane_height(r->height, info, i);
-- 
2.16.1

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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [PATCH 3/3] drm/i915: Eliminate the horrendous format check code
  2018-03-12 20:40 [PATCH 1/3] drm: Add the optional .fb_modifier() hook Ville Syrjala
  2018-03-12 20:40 ` [PATCH 2/3] drm: Make sure at least one plane supports the fb format Ville Syrjala
@ 2018-03-12 20:40 ` Ville Syrjala
  2018-03-12 21:44 ` ✗ Fi.CI.BAT: failure for series starting with [1/3] drm: Add the optional .fb_modifier() hook Patchwork
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 19+ messages in thread
From: Ville Syrjala @ 2018-03-12 20:40 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Now that the core makes sure that the pixel format is supported
by at least one plane, we can eliminate the hand rolled code for the
same thing in i915. The way we were doing was extremely inconvenient
because not only did you have to add the format to the plane's format
list, but you also had to come up with the correct platform checks
for this code.

v2: Nuke the modifier checks as well since the core does that too now
v3: Call drm_any_plane_has_format() from the driver code
v4: Go back to letting the core do everything

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 86 ------------------------------------
 1 file changed, 86 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 51d8d0c40674..028a791889c6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13989,7 +13989,6 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 {
 	struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
 	struct drm_framebuffer *fb = &intel_fb->base;
-	struct drm_format_name_buf format_name;
 	u32 pitch_limit;
 	unsigned int tiling, stride;
 	int ret = -EINVAL;
@@ -14014,37 +14013,6 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 		goto err;
 	}
 
-	/* Passed in modifier sanity checking. */
-	switch (mode_cmd->modifier[0]) {
-	case I915_FORMAT_MOD_Y_TILED_CCS:
-	case I915_FORMAT_MOD_Yf_TILED_CCS:
-		switch (mode_cmd->pixel_format) {
-		case DRM_FORMAT_XBGR8888:
-		case DRM_FORMAT_ABGR8888:
-		case DRM_FORMAT_XRGB8888:
-		case DRM_FORMAT_ARGB8888:
-			break;
-		default:
-			DRM_DEBUG_KMS("RC supported only with RGB8888 formats\n");
-			goto err;
-		}
-		/* fall through */
-	case I915_FORMAT_MOD_Y_TILED:
-	case I915_FORMAT_MOD_Yf_TILED:
-		if (INTEL_GEN(dev_priv) < 9) {
-			DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
-				      mode_cmd->modifier[0]);
-			goto err;
-		}
-	case DRM_FORMAT_MOD_LINEAR:
-	case I915_FORMAT_MOD_X_TILED:
-		break;
-	default:
-		DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
-			      mode_cmd->modifier[0]);
-		goto err;
-	}
-
 	/*
 	 * gen2/3 display engine uses the fence if present,
 	 * so the tiling mode must match the fb modifier exactly.
@@ -14075,60 +14043,6 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 		goto err;
 	}
 
-	/* Reject formats not supported by any plane early. */
-	switch (mode_cmd->pixel_format) {
-	case DRM_FORMAT_C8:
-	case DRM_FORMAT_RGB565:
-	case DRM_FORMAT_XRGB8888:
-	case DRM_FORMAT_ARGB8888:
-		break;
-	case DRM_FORMAT_XRGB1555:
-		if (INTEL_GEN(dev_priv) > 3) {
-			DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-				      drm_get_format_name(mode_cmd->pixel_format, &format_name));
-			goto err;
-		}
-		break;
-	case DRM_FORMAT_ABGR8888:
-		if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
-		    INTEL_GEN(dev_priv) < 9) {
-			DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-				      drm_get_format_name(mode_cmd->pixel_format, &format_name));
-			goto err;
-		}
-		break;
-	case DRM_FORMAT_XBGR8888:
-	case DRM_FORMAT_XRGB2101010:
-	case DRM_FORMAT_XBGR2101010:
-		if (INTEL_GEN(dev_priv) < 4) {
-			DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-				      drm_get_format_name(mode_cmd->pixel_format, &format_name));
-			goto err;
-		}
-		break;
-	case DRM_FORMAT_ABGR2101010:
-		if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
-			DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-				      drm_get_format_name(mode_cmd->pixel_format, &format_name));
-			goto err;
-		}
-		break;
-	case DRM_FORMAT_YUYV:
-	case DRM_FORMAT_UYVY:
-	case DRM_FORMAT_YVYU:
-	case DRM_FORMAT_VYUY:
-		if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
-			DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-				      drm_get_format_name(mode_cmd->pixel_format, &format_name));
-			goto err;
-		}
-		break;
-	default:
-		DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-			      drm_get_format_name(mode_cmd->pixel_format, &format_name));
-		goto err;
-	}
-
 	/* FIXME need to adjust LINOFF/TILEOFF accordingly. */
 	if (mode_cmd->offsets[0] != 0)
 		goto err;
-- 
2.16.1

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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* ✗ Fi.CI.BAT: failure for series starting with [1/3] drm: Add the optional .fb_modifier() hook
  2018-03-12 20:40 [PATCH 1/3] drm: Add the optional .fb_modifier() hook Ville Syrjala
  2018-03-12 20:40 ` [PATCH 2/3] drm: Make sure at least one plane supports the fb format Ville Syrjala
  2018-03-12 20:40 ` [PATCH 3/3] drm/i915: Eliminate the horrendous format check code Ville Syrjala
@ 2018-03-12 21:44 ` Patchwork
  2018-03-13 14:28 ` [PATCH v2 1/3] " Ville Syrjala
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 19+ messages in thread
From: Patchwork @ 2018-03-12 21:44 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm: Add the optional .fb_modifier() hook
URL   : https://patchwork.freedesktop.org/series/39813/
State : failure

== Summary ==

Series 39813v1 series starting with [1/3] drm: Add the optional .fb_modifier() hook
https://patchwork.freedesktop.org/api/1.0/series/39813/revisions/1/mbox/

---- Possible new issues:

Test kms_addfb_basic:
        Subgroup no-handle:
                pass       -> FAIL       (fi-bdw-5557u)
                pass       -> FAIL       (fi-bdw-gvtdvm)
                pass       -> FAIL       (fi-blb-e6850)
                pass       -> FAIL       (fi-bsw-n3050)
                pass       -> FAIL       (fi-bwr-2160)
                pass       -> FAIL       (fi-bxt-dsi)
                pass       -> FAIL       (fi-bxt-j4205)
                pass       -> FAIL       (fi-byt-j1900)
                pass       -> FAIL       (fi-byt-n2820)
                pass       -> FAIL       (fi-cfl-8700k)
                pass       -> FAIL       (fi-cfl-s2)
                pass       -> FAIL       (fi-elk-e7500)
                pass       -> FAIL       (fi-gdg-551)
                pass       -> FAIL       (fi-glk-1)
                pass       -> FAIL       (fi-hsw-4770)
                pass       -> FAIL       (fi-ilk-650)
                pass       -> FAIL       (fi-ivb-3520m)
                pass       -> FAIL       (fi-ivb-3770)
                pass       -> FAIL       (fi-kbl-7500u)
                pass       -> FAIL       (fi-kbl-7567u)
                pass       -> FAIL       (fi-kbl-r)
                pass       -> FAIL       (fi-pnv-d510)
                pass       -> FAIL       (fi-skl-6260u)
                pass       -> FAIL       (fi-skl-6600u)
                pass       -> FAIL       (fi-skl-6700hq)
                pass       -> FAIL       (fi-skl-6700k2)
                pass       -> FAIL       (fi-skl-6770hq)
                pass       -> FAIL       (fi-skl-guc)
                pass       -> FAIL       (fi-skl-gvtdvm)
                pass       -> FAIL       (fi-snb-2520m)
                pass       -> FAIL       (fi-snb-2600)

---- Known issues:

Test gem_mmap_gtt:
        Subgroup basic-small-bo-tiledx:
                fail       -> PASS       (fi-gdg-551) fdo#102575
Test kms_chamelium:
        Subgroup hdmi-hpd-fast:
                skip       -> FAIL       (fi-kbl-7500u) fdo#102672

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

fi-bdw-5557u     total:288  pass:266  dwarn:0   dfail:0   fail:1   skip:21  time:429s
fi-bdw-gvtdvm    total:288  pass:263  dwarn:0   dfail:0   fail:1   skip:24  time:433s
fi-blb-e6850     total:288  pass:222  dwarn:1   dfail:0   fail:1   skip:64  time:382s
fi-bsw-n3050     total:288  pass:241  dwarn:0   dfail:0   fail:1   skip:46  time:536s
fi-bwr-2160      total:288  pass:182  dwarn:0   dfail:0   fail:1   skip:105 time:300s
fi-bxt-dsi       total:288  pass:257  dwarn:0   dfail:0   fail:1   skip:30  time:507s
fi-bxt-j4205     total:288  pass:258  dwarn:0   dfail:0   fail:1   skip:29  time:510s
fi-byt-j1900     total:288  pass:252  dwarn:0   dfail:0   fail:1   skip:35  time:509s
fi-byt-n2820     total:288  pass:248  dwarn:0   dfail:0   fail:1   skip:39  time:499s
fi-cfl-8700k     total:288  pass:259  dwarn:0   dfail:0   fail:1   skip:28  time:412s
fi-cfl-s2        total:288  pass:261  dwarn:0   dfail:0   fail:1   skip:26  time:584s
fi-elk-e7500     total:288  pass:228  dwarn:0   dfail:0   fail:1   skip:59  time:427s
fi-gdg-551       total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 time:314s
fi-glk-1         total:288  pass:259  dwarn:0   dfail:0   fail:1   skip:28  time:531s
fi-hsw-4770      total:288  pass:260  dwarn:0   dfail:0   fail:1   skip:27  time:408s
fi-ilk-650       total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  time:423s
fi-ivb-3520m     total:288  pass:258  dwarn:0   dfail:0   fail:1   skip:29  time:486s
fi-ivb-3770      total:288  pass:254  dwarn:0   dfail:0   fail:1   skip:33  time:428s
fi-kbl-7500u     total:288  pass:262  dwarn:1   dfail:0   fail:2   skip:23  time:478s
fi-kbl-7567u     total:288  pass:267  dwarn:0   dfail:0   fail:1   skip:20  time:471s
fi-kbl-r         total:288  pass:260  dwarn:0   dfail:0   fail:1   skip:27  time:520s
fi-pnv-d510      total:288  pass:221  dwarn:1   dfail:0   fail:1   skip:65  time:645s
fi-skl-6260u     total:288  pass:267  dwarn:0   dfail:0   fail:1   skip:20  time:439s
fi-skl-6600u     total:288  pass:260  dwarn:0   dfail:0   fail:1   skip:27  time:529s
fi-skl-6700hq    total:288  pass:261  dwarn:0   dfail:0   fail:1   skip:26  time:539s
fi-skl-6700k2    total:288  pass:263  dwarn:0   dfail:0   fail:1   skip:24  time:507s
fi-skl-6770hq    total:288  pass:267  dwarn:0   dfail:0   fail:1   skip:20  time:492s
fi-skl-guc       total:288  pass:259  dwarn:0   dfail:0   fail:1   skip:28  time:424s
fi-skl-gvtdvm    total:288  pass:264  dwarn:0   dfail:0   fail:1   skip:23  time:440s
fi-snb-2520m     total:288  pass:247  dwarn:0   dfail:0   fail:1   skip:40  time:540s
fi-snb-2600      total:288  pass:247  dwarn:0   dfail:0   fail:1   skip:40  time:399s
Blacklisted hosts:
fi-cfl-u         total:288  pass:261  dwarn:0   dfail:0   fail:1   skip:26  time:509s
fi-cnl-drrs      total:288  pass:256  dwarn:3   dfail:0   fail:1   skip:28  time:518s
fi-glk-j5005 failed to collect. IGT log at Patchwork_8313/fi-glk-j5005/run0.log

1b5fa1f85d1cc65aec1229aeef67835af5d15864 drm-tip: 2018y-03m-12d-20h-30m-34s UTC integration manifest
e080c4bc0a11 drm/i915: Eliminate the horrendous format check code
0ce29dba9e89 drm: Make sure at least one plane supports the fb format
5f2580c91b7f drm: Add the optional .fb_modifier() hook

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8313/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook
  2018-03-12 20:40 [PATCH 1/3] drm: Add the optional .fb_modifier() hook Ville Syrjala
                   ` (2 preceding siblings ...)
  2018-03-12 21:44 ` ✗ Fi.CI.BAT: failure for series starting with [1/3] drm: Add the optional .fb_modifier() hook Patchwork
@ 2018-03-13 14:28 ` Ville Syrjala
  2018-03-13 14:38   ` Michel Dänzer
  2018-03-13 16:06 ` ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2) Patchwork
  2018-03-13 16:56 ` ✗ Fi.CI.IGT: failure " Patchwork
  5 siblings, 1 reply; 19+ messages in thread
From: Ville Syrjala @ 2018-03-13 14:28 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

To make it possible for the core to check the fb pixel format and
modifier, we need to first ask the driver to deduce the modifier
when the request does not explicitly specify one.

Add a new .fb_modifier() hook for that purpose and convert i915
and vc4 to make use if it. All other drivers seem to currently
assume linear when the request does not specify anything else,
hence we make the core use that as the fallback strategy when
the hook is not provided.

Since the two hooks are now separate it is of course possible
to race set_tiling against addfb. But since that's just userspace
intentially shooting itself in the foot I don't think we should
hve to worry about it. The addfb will simply fail in the
.fb_create() hook if the tiling has changed since
.fb_mofifier() was called. Well, that's the case for i915.
vc4 never did any cross checks between the tiling and modifier.

framebuffer_check() now checks the request against the deduced
modifier, and since we now know the final modifier we can
convert the request to one with modifiers. This means that a
driver will never even have to look at a request without
modifiers outside of the .fb_modifuer() hook, should it need
to provide one.

v2: return -EINVAL for handles[0]==0 from i915/vc4 .fb_modifier() hook
    to keep igt/kms_addfb_basic/no-handle happy

Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/drm_framebuffer.c    | 61 ++++++++++++++++++++--------
 drivers/gpu/drm/i915/intel_display.c | 79 +++++++++++++++++++++++++-----------
 drivers/gpu/drm/i915/intel_drv.h     |  2 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |  2 +
 drivers/gpu/drm/vc4/vc4_kms.c        | 58 ++++++++++++--------------
 include/drm/drm_mode_config.h        | 29 +++++++++++++
 6 files changed, 158 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
index 7df025669067..21d3d51eb261 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -153,7 +153,8 @@ static int fb_plane_height(int height,
 }
 
 static int framebuffer_check(struct drm_device *dev,
-			     const struct drm_mode_fb_cmd2 *r)
+			     struct drm_mode_fb_cmd2 *r,
+			     u64 modifier)
 {
 	const struct drm_format_info *info;
 	int i;
@@ -210,14 +211,14 @@ static int framebuffer_check(struct drm_device *dev,
 		}
 
 		if (r->flags & DRM_MODE_FB_MODIFIERS &&
-		    r->modifier[i] != r->modifier[0]) {
+		    r->modifier[i] != modifier) {
 			DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
 				      r->modifier[i], i);
 			return -EINVAL;
 		}
 
 		/* modifier specific checks: */
-		switch (r->modifier[i]) {
+		switch (modifier) {
 		case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
 			/* NOTE: the pitch restriction may be lifted later if it turns
 			 * out that no hw has this restriction:
@@ -261,45 +262,73 @@ static int framebuffer_check(struct drm_device *dev,
 		}
 	}
 
+	/*
+	 * Finally convert the request into one with
+	 * modifiers to make life easier for drivers.
+	 */
+	if (dev->mode_config.allow_fb_modifiers) {
+		r->flags |= DRM_MODE_FB_MODIFIERS;
+
+		for (i = 0; i < info->num_planes; i++)
+			r->modifier[i] = modifier;
+	}
+
 	return 0;
 }
 
 struct drm_framebuffer *
 drm_internal_framebuffer_create(struct drm_device *dev,
-				const struct drm_mode_fb_cmd2 *r,
+				const struct drm_mode_fb_cmd2 *user_r,
 				struct drm_file *file_priv)
 {
 	struct drm_mode_config *config = &dev->mode_config;
+	struct drm_mode_fb_cmd2 r = *user_r;
 	struct drm_framebuffer *fb;
+	u64 modifier = 0;
 	int ret;
 
-	if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
-		DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
+	if (r.flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
+		DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r.flags);
 		return ERR_PTR(-EINVAL);
 	}
 
-	if ((config->min_width > r->width) || (r->width > config->max_width)) {
+	if (config->min_width > r.width || r.width > config->max_width) {
 		DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && <= %d\n",
-			  r->width, config->min_width, config->max_width);
+			  r.width, config->min_width, config->max_width);
 		return ERR_PTR(-EINVAL);
 	}
-	if ((config->min_height > r->height) || (r->height > config->max_height)) {
+	if (config->min_height > r.height || r.height > config->max_height) {
 		DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d && <= %d\n",
-			  r->height, config->min_height, config->max_height);
+			  r.height, config->min_height, config->max_height);
 		return ERR_PTR(-EINVAL);
 	}
 
-	if (r->flags & DRM_MODE_FB_MODIFIERS &&
-	    !dev->mode_config.allow_fb_modifiers) {
-		DRM_DEBUG_KMS("driver does not support fb modifiers\n");
-		return ERR_PTR(-EINVAL);
+	if (r.flags & DRM_MODE_FB_MODIFIERS) {
+		if (!dev->mode_config.allow_fb_modifiers) {
+			DRM_DEBUG_KMS("driver does not support fb modifiers\n");
+			return ERR_PTR(-EINVAL);
+		}
+
+		modifier = r.modifier[0];
+	} else {
+		if (dev->mode_config.funcs->fb_modifier) {
+			ret = dev->mode_config.funcs->fb_modifier(dev, file_priv,
+								  &r, &modifier);
+			if (ret) {
+				DRM_DEBUG_KMS("driver did not deduce the fb modifier\n");
+				return ERR_PTR(ret);
+			}
+		} else {
+			/* assume linear if the driver doesn't say otherwise */
+			modifier = DRM_FORMAT_MOD_LINEAR;
+		}
 	}
 
-	ret = framebuffer_check(dev, r);
+	ret = framebuffer_check(dev, &r, modifier);
 	if (ret)
 		return ERR_PTR(ret);
 
-	fb = dev->mode_config.funcs->fb_create(dev, file_priv, r);
+	fb = dev->mode_config.funcs->fb_create(dev, file_priv, &r);
 	if (IS_ERR(fb)) {
 		DRM_DEBUG_KMS("could not create framebuffer\n");
 		return fb;
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 2933ad38094f..7ffe425b26ac 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -123,7 +123,7 @@ static void ironlake_pch_clock_get(struct intel_crtc *crtc,
 
 static int intel_framebuffer_init(struct intel_framebuffer *ifb,
 				  struct drm_i915_gem_object *obj,
-				  struct drm_mode_fb_cmd2 *mode_cmd);
+				  const struct drm_mode_fb_cmd2 *mode_cmd);
 static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc);
 static void intel_set_pipe_timings(struct intel_crtc *intel_crtc);
 static void intel_set_pipe_src_size(struct intel_crtc *intel_crtc);
@@ -9807,7 +9807,7 @@ static const struct drm_display_mode load_detect_mode = {
 
 struct drm_framebuffer *
 intel_framebuffer_create(struct drm_i915_gem_object *obj,
-			 struct drm_mode_fb_cmd2 *mode_cmd)
+			 const struct drm_mode_fb_cmd2 *mode_cmd)
 {
 	struct intel_framebuffer *intel_fb;
 	int ret;
@@ -13985,7 +13985,7 @@ u32 intel_fb_pitch_limit(struct drm_i915_private *dev_priv,
 
 static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 				  struct drm_i915_gem_object *obj,
-				  struct drm_mode_fb_cmd2 *mode_cmd)
+				  const struct drm_mode_fb_cmd2 *mode_cmd)
 {
 	struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
 	struct drm_framebuffer *fb = &intel_fb->base;
@@ -13995,29 +13995,23 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 	int ret = -EINVAL;
 	int i;
 
+	if (WARN_ON((mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0))
+		return -EINVAL;
+
 	i915_gem_object_lock(obj);
 	obj->framebuffer_references++;
 	tiling = i915_gem_object_get_tiling(obj);
 	stride = i915_gem_object_get_stride(obj);
 	i915_gem_object_unlock(obj);
 
-	if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
-		/*
-		 * If there's a fence, enforce that
-		 * the fb modifier and tiling mode match.
-		 */
-		if (tiling != I915_TILING_NONE &&
-		    tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
-			DRM_DEBUG_KMS("tiling_mode doesn't match fb modifier\n");
-			goto err;
-		}
-	} else {
-		if (tiling == I915_TILING_X) {
-			mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
-		} else if (tiling == I915_TILING_Y) {
-			DRM_DEBUG_KMS("No Y tiling for legacy addfb\n");
-			goto err;
-		}
+	/*
+	 * If there's a fence, enforce that
+	 * the fb modifier and tiling mode match.
+	 */
+	if (tiling != I915_TILING_NONE &&
+	    tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
+		DRM_DEBUG_KMS("tiling_mode doesn't match fb modifier\n");
+		goto err;
 	}
 
 	/* Passed in modifier sanity checking. */
@@ -14193,20 +14187,56 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 	return ret;
 }
 
+static int
+intel_user_framebuffer_modifier(struct drm_device *dev,
+				struct drm_file *filp,
+				const struct drm_mode_fb_cmd2 *mode_cmd,
+				u64 *modifier)
+{
+	struct drm_i915_gem_object *obj;
+	unsigned int tiling;
+
+	if (!mode_cmd->handles[0]) {
+		DRM_DEBUG_KMS("no buffer object handle for plane 0\n");
+		return -EINVAL;
+	}
+
+	obj = i915_gem_object_lookup(filp, mode_cmd->handles[0]);
+	if (!obj)
+		return -ENOENT;
+
+	i915_gem_object_lock(obj);
+	tiling = i915_gem_object_get_tiling(obj);
+	i915_gem_object_unlock(obj);
+
+	i915_gem_object_put(obj);
+
+	if (tiling == I915_TILING_Y) {
+		DRM_DEBUG_KMS("No Y tiling for legacy addfb\n");
+		return -EINVAL;
+	}
+
+	if (tiling == I915_TILING_X)
+		*modifier = I915_FORMAT_MOD_X_TILED;
+	else
+		*modifier = DRM_FORMAT_MOD_LINEAR;
+
+	return 0;
+}
+
 static struct drm_framebuffer *
 intel_user_framebuffer_create(struct drm_device *dev,
 			      struct drm_file *filp,
-			      const struct drm_mode_fb_cmd2 *user_mode_cmd)
+			      const struct drm_mode_fb_cmd2 *mode_cmd)
 {
 	struct drm_framebuffer *fb;
 	struct drm_i915_gem_object *obj;
-	struct drm_mode_fb_cmd2 mode_cmd = *user_mode_cmd;
 
-	obj = i915_gem_object_lookup(filp, mode_cmd.handles[0]);
+	obj = i915_gem_object_lookup(filp, mode_cmd->handles[0]);
 	if (!obj)
 		return ERR_PTR(-ENOENT);
 
-	fb = intel_framebuffer_create(obj, &mode_cmd);
+	fb = intel_framebuffer_create(obj, mode_cmd);
 	if (IS_ERR(fb))
 		i915_gem_object_put(obj);
 
@@ -14251,6 +14281,7 @@ intel_mode_valid(struct drm_device *dev,
 }
 
 static const struct drm_mode_config_funcs intel_mode_funcs = {
+	.fb_modifier = intel_user_framebuffer_modifier,
 	.fb_create = intel_user_framebuffer_create,
 	.get_format_info = intel_get_format_info,
 	.output_poll_changed = intel_fbdev_output_poll_changed,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fce5d3072d97..678755297814 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1517,7 +1517,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
 void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags);
 struct drm_framebuffer *
 intel_framebuffer_create(struct drm_i915_gem_object *obj,
-			 struct drm_mode_fb_cmd2 *mode_cmd);
+			 const struct drm_mode_fb_cmd2 *mode_cmd);
 int intel_prepare_plane_fb(struct drm_plane *plane,
 			   struct drm_plane_state *new_state);
 void intel_cleanup_plane_fb(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index 6f12adc06365..777f5bfbe8ef 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -131,6 +131,8 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
 				    DIV_ROUND_UP(sizes->surface_bpp, 8), 64);
 	mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
 							  sizes->surface_depth);
+	mode_cmd.modifier[0] = DRM_FORMAT_MOD_LINEAR;
+	mode_cmd.flags = DRM_MODE_FB_MODIFIERS;
 
 	size = mode_cmd.pitches[0] * mode_cmd.height;
 	size = PAGE_ALIGN(size);
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ba60153dddb5..25a2dd6acc61 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -148,50 +148,44 @@ static int vc4_atomic_commit(struct drm_device *dev,
 	return 0;
 }
 
-static struct drm_framebuffer *vc4_fb_create(struct drm_device *dev,
-					     struct drm_file *file_priv,
-					     const struct drm_mode_fb_cmd2 *mode_cmd)
+static int vc4_fb_modifier(struct drm_device *dev,
+			   struct drm_file *file_priv,
+			   const struct drm_mode_fb_cmd2 *mode_cmd,
+			   u64 *modifier)
 {
-	struct drm_mode_fb_cmd2 mode_cmd_local;
+	struct drm_gem_object *gem_obj;
+	struct vc4_bo *bo;
 
-	/* If the user didn't specify a modifier, use the
-	 * vc4_set_tiling_ioctl() state for the BO.
-	 */
-	if (!(mode_cmd->flags & DRM_MODE_FB_MODIFIERS)) {
-		struct drm_gem_object *gem_obj;
-		struct vc4_bo *bo;
-
-		gem_obj = drm_gem_object_lookup(file_priv,
-						mode_cmd->handles[0]);
-		if (!gem_obj) {
-			DRM_DEBUG("Failed to look up GEM BO %d\n",
-				  mode_cmd->handles[0]);
-			return ERR_PTR(-ENOENT);
-		}
-		bo = to_vc4_bo(gem_obj);
-
-		mode_cmd_local = *mode_cmd;
+	if (!mode_cmd->handles[0]) {
+		DRM_DEBUG_KMS("no buffer object handle for plane 0\n");
+		return -EINVAL;
+	}
 
-		if (bo->t_format) {
-			mode_cmd_local.modifier[0] =
-				DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED;
-		} else {
-			mode_cmd_local.modifier[0] = DRM_FORMAT_MOD_NONE;
-		}
+	gem_obj = drm_gem_object_lookup(file_priv,
+					mode_cmd->handles[0]);
+	if (!gem_obj) {
+		DRM_DEBUG("Failed to look up GEM BO %d\n",
+			  mode_cmd->handles[0]);
+		return -ENOENT;
+	}
+	bo = to_vc4_bo(gem_obj);
 
-		drm_gem_object_put_unlocked(gem_obj);
+	if (bo->t_format)
+		*modifier = DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED;
+	else
+		*modifier = DRM_FORMAT_MOD_LINEAR;
 
-		mode_cmd = &mode_cmd_local;
-	}
+	drm_gem_object_put_unlocked(gem_obj);
 
-	return drm_gem_fb_create(dev, file_priv, mode_cmd);
+	return 0;
 }
 
 static const struct drm_mode_config_funcs vc4_mode_funcs = {
 	.output_poll_changed = drm_fb_helper_output_poll_changed,
 	.atomic_check = drm_atomic_helper_check,
 	.atomic_commit = vc4_atomic_commit,
-	.fb_create = vc4_fb_create,
+	.fb_modifier = vc4_fb_modifier,
+	.fb_create = drm_gem_fb_create,
 };
 
 int vc4_kms_load(struct drm_device *dev)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7569f22ffef6..c74aed292b58 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -45,6 +45,30 @@ struct drm_display_mode;
  * involve drivers.
  */
 struct drm_mode_config_funcs {
+	/**
+	 * @fb_modifier:
+	 *
+	 * Deduce the format modifier using a driver specific method. This
+	 * gets called when the request does not explicitly state the
+	 * modifier, ie. (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0.
+	 * The deduced modifier is returned via @modifier.
+	 *
+	 * Once the modifier is known several sanity checks will be performed
+	 * and if all is deemed valid @fb_create() will be called to have
+	 * the driver to actually create the framebuffer.
+	 *
+	 * This hook is optional. The core will assume DRM_FORMAT_MOD_LINEAR
+	 * if the hook is not provided by the driver.
+	 *
+	 * RETURNS:
+	 *
+	 * Zero on success, negative error code on failure.
+	 */
+	int (*fb_modifier)(struct drm_device *dev,
+			   struct drm_file *file_priv,
+			   const struct drm_mode_fb_cmd2 *mode_cmd,
+			   u64 *modifier);
+
 	/**
 	 * @fb_create:
 	 *
@@ -52,6 +76,11 @@ struct drm_mode_config_funcs {
 	 * requested metadata, but most of that is left to the driver. See
 	 * &struct drm_mode_fb_cmd2 for details.
 	 *
+	 * Note that for drivers that support modifiers, the core will convert
+	 * all requests to one with modifiers. So the driver does not need to
+	 * worry about requests without modifiers (apart from having to provide
+	 * the @fb_modifier() hook if necessary).
+	 *
 	 * If the parameters are deemed valid and the backing storage objects in
 	 * the underlying memory manager all exist, then the driver allocates
 	 * a new &drm_framebuffer structure, subclassed to contain
-- 
2.16.1

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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook
  2018-03-13 14:28 ` [PATCH v2 1/3] " Ville Syrjala
@ 2018-03-13 14:38   ` Michel Dänzer
  2018-03-13 15:12     ` Ville Syrjälä
  2018-03-13 15:20     ` Daniel Vetter
  0 siblings, 2 replies; 19+ messages in thread
From: Michel Dänzer @ 2018-03-13 14:38 UTC (permalink / raw)
  To: Ville Syrjala; +Cc: intel-gfx, dri-devel

On 2018-03-13 03:28 PM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> To make it possible for the core to check the fb pixel format and
> modifier, we need to first ask the driver to deduce the modifier
> when the request does not explicitly specify one.
> 
> Add a new .fb_modifier() hook for that purpose and convert i915
> and vc4 to make use if it. All other drivers seem to currently
> assume linear when the request does not specify anything else,
> [...]

That's not true at least for the amdgpu and radeon drivers. The tiling
mode is communicated via BO metadata.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook
  2018-03-13 14:38   ` Michel Dänzer
@ 2018-03-13 15:12     ` Ville Syrjälä
  2018-03-13 15:18       ` Michel Dänzer
  2018-03-13 15:20     ` Daniel Vetter
  1 sibling, 1 reply; 19+ messages in thread
From: Ville Syrjälä @ 2018-03-13 15:12 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: intel-gfx, Harry Wentland, dri-devel

On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > To make it possible for the core to check the fb pixel format and
> > modifier, we need to first ask the driver to deduce the modifier
> > when the request does not explicitly specify one.
> > 
> > Add a new .fb_modifier() hook for that purpose and convert i915
> > and vc4 to make use if it. All other drivers seem to currently
> > assume linear when the request does not specify anything else,
> > [...]
> 
> That's not true at least for the amdgpu and radeon drivers. The tiling
> mode is communicated via BO metadata.

Well, at least those driver don't do any bo tiling->modifier conversion.
Radeon doesn't do modifiers I suppose, so that part is probably OK.
amggpu might just be broken, not sure.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook
  2018-03-13 15:12     ` Ville Syrjälä
@ 2018-03-13 15:18       ` Michel Dänzer
  0 siblings, 0 replies; 19+ messages in thread
From: Michel Dänzer @ 2018-03-13 15:18 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx, dri-devel

On 2018-03-13 04:12 PM, Ville Syrjälä wrote:
> On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
>> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> To make it possible for the core to check the fb pixel format and
>>> modifier, we need to first ask the driver to deduce the modifier
>>> when the request does not explicitly specify one.
>>>
>>> Add a new .fb_modifier() hook for that purpose and convert i915
>>> and vc4 to make use if it. All other drivers seem to currently
>>> assume linear when the request does not specify anything else,
>>> [...]
>>
>> That's not true at least for the amdgpu and radeon drivers. The tiling
>> mode is communicated via BO metadata.
> 
> Well, at least those driver don't do any bo tiling->modifier conversion.
> Radeon doesn't do modifiers I suppose, so that part is probably OK.
> amggpu might just be broken, not sure.

amdgpu certainly wasn't broken before modifiers came along. If something
broke with those, I'd say it's more accurate to say that's broken and
needs to be fixed, rather than adding more incorrect assumptions based
on it.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook
  2018-03-13 14:38   ` Michel Dänzer
  2018-03-13 15:12     ` Ville Syrjälä
@ 2018-03-13 15:20     ` Daniel Vetter
  2018-03-13 15:35       ` Michel Dänzer
  1 sibling, 1 reply; 19+ messages in thread
From: Daniel Vetter @ 2018-03-13 15:20 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: intel-gfx, dri-devel

On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > To make it possible for the core to check the fb pixel format and
> > modifier, we need to first ask the driver to deduce the modifier
> > when the request does not explicitly specify one.
> > 
> > Add a new .fb_modifier() hook for that purpose and convert i915
> > and vc4 to make use if it. All other drivers seem to currently
> > assume linear when the request does not specify anything else,
> > [...]
> 
> That's not true at least for the amdgpu and radeon drivers. The tiling
> mode is communicated via BO metadata.

But atm amdgpu and radeon also don't support explicit modifiers in the
kernel driver, so it again all checks out. Or should at least.

Once you add modifier support, you need to wire up all the bits and the
rigth default selection, and it should again pan out.
-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] 19+ messages in thread

* Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook
  2018-03-13 15:20     ` Daniel Vetter
@ 2018-03-13 15:35       ` Michel Dänzer
  2018-03-13 15:46         ` Ville Syrjälä
  0 siblings, 1 reply; 19+ messages in thread
From: Michel Dänzer @ 2018-03-13 15:35 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx, dri-devel

On 2018-03-13 04:20 PM, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
>> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> To make it possible for the core to check the fb pixel format and
>>> modifier, we need to first ask the driver to deduce the modifier
>>> when the request does not explicitly specify one.
>>>
>>> Add a new .fb_modifier() hook for that purpose and convert i915
>>> and vc4 to make use if it. All other drivers seem to currently
>>> assume linear when the request does not specify anything else,
>>> [...]
>>
>> That's not true at least for the amdgpu and radeon drivers. The tiling
>> mode is communicated via BO metadata.
> 
> But atm amdgpu and radeon also don't support explicit modifiers in the
> kernel driver, so it again all checks out. Or should at least.

Sounds like I misunderstood that this is trying to guess modifiers for
all drivers. So far, so good if so.


> Once you add modifier support, you need to wire up all the bits and the
> rigth default selection, and it should again pan out.

Well, this change allows a driver not to wire up the fb_modifier hook,
and just assumes linear in that case. Seems like an accident waiting to
happen, but I'll leave it to you guys.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook
  2018-03-13 15:35       ` Michel Dänzer
@ 2018-03-13 15:46         ` Ville Syrjälä
  0 siblings, 0 replies; 19+ messages in thread
From: Ville Syrjälä @ 2018-03-13 15:46 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: intel-gfx, dri-devel

On Tue, Mar 13, 2018 at 04:35:02PM +0100, Michel Dänzer wrote:
> On 2018-03-13 04:20 PM, Daniel Vetter wrote:
> > On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
> >> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> To make it possible for the core to check the fb pixel format and
> >>> modifier, we need to first ask the driver to deduce the modifier
> >>> when the request does not explicitly specify one.
> >>>
> >>> Add a new .fb_modifier() hook for that purpose and convert i915
> >>> and vc4 to make use if it. All other drivers seem to currently
> >>> assume linear when the request does not specify anything else,
> >>> [...]
> >>
> >> That's not true at least for the amdgpu and radeon drivers. The tiling
> >> mode is communicated via BO metadata.
> > 
> > But atm amdgpu and radeon also don't support explicit modifiers in the
> > kernel driver, so it again all checks out. Or should at least.
> 
> Sounds like I misunderstood that this is trying to guess modifiers for
> all drivers. So far, so good if so.

Somehow I convinced myself that amdgpu already had some modifier
support. But looks like I was mistaken.

> > Once you add modifier support, you need to wire up all the bits and the
> > rigth default selection, and it should again pan out.
> 
> Well, this change allows a driver not to wire up the fb_modifier hook,
> and just assumes linear in that case. Seems like an accident waiting to
> happen, but I'll leave it to you guys.

That's already the case with the current code. mode_cmd->modifier[0]
will be 0 when when DRM_MODE_FB_MODIFIERS isn't specified, which is the
same thing as DRM_FORMAT_MOD_LINEAR. So if the driver doesn't change
it before calling drm_helper_mode_fill_fb_struct() you end up with
fb->modifier == DRM_FORMAT_MOD_LINEAR.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 19+ messages in thread

* ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2)
  2018-03-12 20:40 [PATCH 1/3] drm: Add the optional .fb_modifier() hook Ville Syrjala
                   ` (3 preceding siblings ...)
  2018-03-13 14:28 ` [PATCH v2 1/3] " Ville Syrjala
@ 2018-03-13 16:06 ` Patchwork
  2018-03-13 16:56 ` ✗ Fi.CI.IGT: failure " Patchwork
  5 siblings, 0 replies; 19+ messages in thread
From: Patchwork @ 2018-03-13 16:06 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

== Series Details ==

Series: series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2)
URL   : https://patchwork.freedesktop.org/series/39813/
State : success

== Summary ==

Series 39813v2 series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook
https://patchwork.freedesktop.org/api/1.0/series/39813/revisions/2/mbox/

---- Known issues:

Test kms_chamelium:
        Subgroup dp-crc-fast:
                fail       -> PASS       (fi-kbl-7500u) fdo#103841
Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-c:
                pass       -> INCOMPLETE (fi-skl-6700k2) fdo#104108

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

fi-bdw-5557u     total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  time:428s
fi-bdw-gvtdvm    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:432s
fi-blb-e6850     total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  time:382s
fi-bsw-n3050     total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  time:538s
fi-bwr-2160      total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 time:298s
fi-bxt-dsi       total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  time:508s
fi-bxt-j4205     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:505s
fi-byt-j1900     total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  time:507s
fi-byt-n2820     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:499s
fi-cfl-8700k     total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:408s
fi-cfl-s2        total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:579s
fi-cnl-y3        total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:582s
fi-elk-e7500     total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  time:425s
fi-gdg-551       total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 time:313s
fi-glk-1         total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:530s
fi-hsw-4770      total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:404s
fi-ilk-650       total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  time:415s
fi-ivb-3520m     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:474s
fi-kbl-7500u     total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  time:471s
fi-kbl-7567u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:467s
fi-kbl-r         total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:517s
fi-pnv-d510      total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  time:644s
fi-skl-6260u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:438s
fi-skl-6600u     total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:524s
fi-skl-6700hq    total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:538s
fi-skl-6700k2    total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6770hq    total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:493s
fi-skl-guc       total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:429s
fi-skl-gvtdvm    total:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  time:432s
fi-snb-2520m     total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:547s
fi-snb-2600      total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:399s
Blacklisted hosts:
fi-cfl-u         total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:508s
fi-cnl-drrs      total:288  pass:257  dwarn:3   dfail:0   fail:0   skip:28  time:533s

874b86a759851707e26286c22062f6ccc526e46f drm-tip: 2018y-03m-13d-12h-36m-17s UTC integration manifest
fc4f4d11665c drm/i915: Eliminate the horrendous format check code
5caf98a38622 drm: Make sure at least one plane supports the fb format
9b1e973a1ddb drm: Add the optional .fb_modifier() hook

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8329/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2)
  2018-03-12 20:40 [PATCH 1/3] drm: Add the optional .fb_modifier() hook Ville Syrjala
                   ` (4 preceding siblings ...)
  2018-03-13 16:06 ` ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2) Patchwork
@ 2018-03-13 16:56 ` Patchwork
  2018-03-13 17:03   ` Ville Syrjälä
  5 siblings, 1 reply; 19+ messages in thread
From: Patchwork @ 2018-03-13 16:56 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

== Series Details ==

Series: series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2)
URL   : https://patchwork.freedesktop.org/series/39813/
State : failure

== Summary ==

---- Possible new issues:

Test kms_cursor_crc:
        Subgroup cursor-64x64-suspend:
                skip       -> PASS       (shard-snb)
Test kms_frontbuffer_tracking:
        Subgroup fbc-rgb565-draw-mmap-gtt:
                pass       -> FAIL       (shard-apl)
Test kms_properties:
        Subgroup crtc-properties-legacy:
                skip       -> PASS       (shard-snb)

---- Known issues:

Test gem_eio:
        Subgroup in-flight-external:
                pass       -> INCOMPLETE (shard-hsw) fdo#105341 +1
Test kms_flip:
        Subgroup 2x-plain-flip-fb-recreate-interruptible:
                pass       -> FAIL       (shard-hsw) fdo#100368 +2
        Subgroup flip-vs-expired-vblank:
                pass       -> FAIL       (shard-hsw) fdo#102887
Test kms_frontbuffer_tracking:
        Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
                pass       -> DMESG-FAIL (shard-apl) fdo#101623 +2
        Subgroup fbc-1p-pri-indfb-multidraw:
                pass       -> FAIL       (shard-apl) fdo#103167
        Subgroup fbc-1p-primscrn-shrfb-msflip-blt:
                pass       -> FAIL       (shard-apl) fdo#104727
Test kms_rotation_crc:
        Subgroup cursor-rotation-180:
                pass       -> FAIL       (shard-snb) fdo#105185
Test perf:
        Subgroup polling:
                pass       -> FAIL       (shard-hsw) fdo#102252

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#104727 https://bugs.freedesktop.org/show_bug.cgi?id=104727
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apl        total:3371 pass:1770 dwarn:1   dfail:1   fail:12  skip:1585 time:12277s
shard-hsw        total:3381 pass:1727 dwarn:1   dfail:0   fail:5   skip:1646 time:11578s
shard-snb        total:3444 pass:1358 dwarn:1   dfail:0   fail:4   skip:2081 time:7143s
Blacklisted hosts:
shard-kbl        total:3371 pass:1817 dwarn:14  dfail:0   fail:8   skip:1531 time:8622s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8329/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2)
  2018-03-13 16:56 ` ✗ Fi.CI.IGT: failure " Patchwork
@ 2018-03-13 17:03   ` Ville Syrjälä
  0 siblings, 0 replies; 19+ messages in thread
From: Ville Syrjälä @ 2018-03-13 17:03 UTC (permalink / raw)
  To: intel-gfx

On Tue, Mar 13, 2018 at 04:56:52PM -0000, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2)
> URL   : https://patchwork.freedesktop.org/series/39813/
> State : failure
> 
> == Summary ==
> 
> ---- Possible new issues:
> 
> Test kms_cursor_crc:
>         Subgroup cursor-64x64-suspend:
>                 skip       -> PASS       (shard-snb)
> Test kms_frontbuffer_tracking:
>         Subgroup fbc-rgb565-draw-mmap-gtt:
>                 pass       -> FAIL       (shard-apl)

Unrelated.

(kms_frontbuffer_tracking:1620) WARNING: fbc_is_enabled()?
FBC disabled: underrun detected
(kms_frontbuffer_tracking:1620) CRITICAL: Test assertion failure function do_status_assertions, file ../tests/kms_frontbuffer_tracking.c:1733:
(kms_frontbuffer_tracking:1620) CRITICAL: Failed assertion: fbc_is_enabled(IGT_LOG_WARN)
(kms_frontbuffer_tracking:1620) CRITICAL: FBC disabled

> Test kms_properties:
>         Subgroup crtc-properties-legacy:
>                 skip       -> PASS       (shard-snb)
> 
> ---- Known issues:
> 
> Test gem_eio:
>         Subgroup in-flight-external:
>                 pass       -> INCOMPLETE (shard-hsw) fdo#105341 +1
> Test kms_flip:
>         Subgroup 2x-plain-flip-fb-recreate-interruptible:
>                 pass       -> FAIL       (shard-hsw) fdo#100368 +2
>         Subgroup flip-vs-expired-vblank:
>                 pass       -> FAIL       (shard-hsw) fdo#102887
> Test kms_frontbuffer_tracking:
>         Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
>                 pass       -> DMESG-FAIL (shard-apl) fdo#101623 +2
>         Subgroup fbc-1p-pri-indfb-multidraw:
>                 pass       -> FAIL       (shard-apl) fdo#103167
>         Subgroup fbc-1p-primscrn-shrfb-msflip-blt:
>                 pass       -> FAIL       (shard-apl) fdo#104727
> Test kms_rotation_crc:
>         Subgroup cursor-rotation-180:
>                 pass       -> FAIL       (shard-snb) fdo#105185
> Test perf:
>         Subgroup polling:
>                 pass       -> FAIL       (shard-hsw) fdo#102252
> 
> fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
> fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
> fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
> fdo#104727 https://bugs.freedesktop.org/show_bug.cgi?id=104727
> fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
> fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
> 
> shard-apl        total:3371 pass:1770 dwarn:1   dfail:1   fail:12  skip:1585 time:12277s
> shard-hsw        total:3381 pass:1727 dwarn:1   dfail:0   fail:5   skip:1646 time:11578s
> shard-snb        total:3444 pass:1358 dwarn:1   dfail:0   fail:4   skip:2081 time:7143s
> Blacklisted hosts:
> shard-kbl        total:3371 pass:1817 dwarn:14  dfail:0   fail:8   skip:1531 time:8622s
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8329/shards.html

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/3] drm: Make sure at least one plane supports the fb format
  2018-03-12 20:40 ` [PATCH 2/3] drm: Make sure at least one plane supports the fb format Ville Syrjala
@ 2018-03-15 17:42   ` Eric Anholt
  2018-03-15 17:48     ` Ville Syrjälä
  0 siblings, 1 reply; 19+ messages in thread
From: Eric Anholt @ 2018-03-15 17:42 UTC (permalink / raw)
  To: Ville Syrjala, dri-devel; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 2524 bytes --]

Ville Syrjala <ville.syrjala@linux.intel.com> writes:

> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> To make life easier for drivers, let's have the core check that the
> requested pixel format is supported by at least one plane when creating
> a new framebuffer.
>
> This eases the burden on drivers by making sure they'll never get
> requests to create fbs with unsupported pixel formats. Thanks to the
> new .fb_modifier() hook this check can now be done whether the request
> specifies the modifier directly or driver has to deduce it from the
> gem bo tiling (or via any other method really).
>
> v0: Accept anyformat if the driver doesn't do planes (Eric)
>     s/planes_have_format/any_plane_has_format/ (Eric)
>     Check the modifier as well since we already have a function
>     that does both
> v3: Don't do the check in the core since we may not know the
>     modifier yet, instead export the function and let drivers
>     call it themselves
> v4: Unexport the functiona and put the format_default check back
>     since this will again be called by the core, ie. undo v3 ;)
>
> Cc: Eric Anholt <eric@anholt.net>
> Testcase: igt/kms_addfb_basic/expected-formats
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_framebuffer.c | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> index 21d3d51eb261..e618a6b728d4 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
>  	return DIV_ROUND_UP(height, format->vsub);
>  }
>  
> +static bool any_plane_has_format(struct drm_device *dev,
> +				 u32 format, u64 modifier)
> +{
> +	struct drm_plane *plane;
> +
> +	drm_for_each_plane(plane, dev) {
> +		/*
> +		 * In case the driver doesn't really do
> +		 * planes we have to accept any format here.
> +		 */
> +		if (plane->format_default)
> +			return true;
> +
> +		if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
> +			return true;
> +	}
> +
> +	return false;
> +}

This drm_plane_check_pixel_format() will always fail for VC4's SAND
modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
as a bit of metadata (like how we have horizontal stride passed outside
of the modifier) and you can't list all of the possible values in an
array on the plane.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/3] drm: Make sure at least one plane supports the fb format
  2018-03-15 17:42   ` Eric Anholt
@ 2018-03-15 17:48     ` Ville Syrjälä
  2018-03-15 18:03       ` Ville Syrjälä
  0 siblings, 1 reply; 19+ messages in thread
From: Ville Syrjälä @ 2018-03-15 17:48 UTC (permalink / raw)
  To: Eric Anholt; +Cc: intel-gfx, dri-devel

On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
> 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > To make life easier for drivers, let's have the core check that the
> > requested pixel format is supported by at least one plane when creating
> > a new framebuffer.
> >
> > This eases the burden on drivers by making sure they'll never get
> > requests to create fbs with unsupported pixel formats. Thanks to the
> > new .fb_modifier() hook this check can now be done whether the request
> > specifies the modifier directly or driver has to deduce it from the
> > gem bo tiling (or via any other method really).
> >
> > v0: Accept anyformat if the driver doesn't do planes (Eric)
> >     s/planes_have_format/any_plane_has_format/ (Eric)
> >     Check the modifier as well since we already have a function
> >     that does both
> > v3: Don't do the check in the core since we may not know the
> >     modifier yet, instead export the function and let drivers
> >     call it themselves
> > v4: Unexport the functiona and put the format_default check back
> >     since this will again be called by the core, ie. undo v3 ;)
> >
> > Cc: Eric Anholt <eric@anholt.net>
> > Testcase: igt/kms_addfb_basic/expected-formats
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/drm_framebuffer.c | 30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> > index 21d3d51eb261..e618a6b728d4 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
> >  	return DIV_ROUND_UP(height, format->vsub);
> >  }
> >  
> > +static bool any_plane_has_format(struct drm_device *dev,
> > +				 u32 format, u64 modifier)
> > +{
> > +	struct drm_plane *plane;
> > +
> > +	drm_for_each_plane(plane, dev) {
> > +		/*
> > +		 * In case the driver doesn't really do
> > +		 * planes we have to accept any format here.
> > +		 */
> > +		if (plane->format_default)
> > +			return true;
> > +
> > +		if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
> > +			return true;
> > +	}
> > +
> > +	return false;
> > +}
> 
> This drm_plane_check_pixel_format() will always fail for VC4's SAND
> modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
> as a bit of metadata (like how we have horizontal stride passed outside
> of the modifier) and you can't list all of the possible values in an
> array on the plane.

Hmm. drm_atomic_plane_check() etc. call this thing as well. How does
that manage to work currently?

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/3] drm: Make sure at least one plane supports the fb format
  2018-03-15 17:48     ` Ville Syrjälä
@ 2018-03-15 18:03       ` Ville Syrjälä
  2018-03-15 18:48         ` Ville Syrjälä
  0 siblings, 1 reply; 19+ messages in thread
From: Ville Syrjälä @ 2018-03-15 18:03 UTC (permalink / raw)
  To: Eric Anholt; +Cc: intel-gfx, dri-devel

On Thu, Mar 15, 2018 at 07:48:02PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
> > Ville Syrjala <ville.syrjala@linux.intel.com> writes:
> > 
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > To make life easier for drivers, let's have the core check that the
> > > requested pixel format is supported by at least one plane when creating
> > > a new framebuffer.
> > >
> > > This eases the burden on drivers by making sure they'll never get
> > > requests to create fbs with unsupported pixel formats. Thanks to the
> > > new .fb_modifier() hook this check can now be done whether the request
> > > specifies the modifier directly or driver has to deduce it from the
> > > gem bo tiling (or via any other method really).
> > >
> > > v0: Accept anyformat if the driver doesn't do planes (Eric)
> > >     s/planes_have_format/any_plane_has_format/ (Eric)
> > >     Check the modifier as well since we already have a function
> > >     that does both
> > > v3: Don't do the check in the core since we may not know the
> > >     modifier yet, instead export the function and let drivers
> > >     call it themselves
> > > v4: Unexport the functiona and put the format_default check back
> > >     since this will again be called by the core, ie. undo v3 ;)
> > >
> > > Cc: Eric Anholt <eric@anholt.net>
> > > Testcase: igt/kms_addfb_basic/expected-formats
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/drm_framebuffer.c | 30 ++++++++++++++++++++++++++++++
> > >  1 file changed, 30 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> > > index 21d3d51eb261..e618a6b728d4 100644
> > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
> > >  	return DIV_ROUND_UP(height, format->vsub);
> > >  }
> > >  
> > > +static bool any_plane_has_format(struct drm_device *dev,
> > > +				 u32 format, u64 modifier)
> > > +{
> > > +	struct drm_plane *plane;
> > > +
> > > +	drm_for_each_plane(plane, dev) {
> > > +		/*
> > > +		 * In case the driver doesn't really do
> > > +		 * planes we have to accept any format here.
> > > +		 */
> > > +		if (plane->format_default)
> > > +			return true;
> > > +
> > > +		if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
> > > +			return true;
> > > +	}
> > > +
> > > +	return false;
> > > +}
> > 
> > This drm_plane_check_pixel_format() will always fail for VC4's SAND
> > modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
> > as a bit of metadata (like how we have horizontal stride passed outside
> > of the modifier) and you can't list all of the possible values in an
> > array on the plane.
> 
> Hmm. drm_atomic_plane_check() etc. call this thing as well. How does
> that manage to work currently?

Maybe it doesn't. I added the modifier checks in

commit 23163a7d4b032489d375099d56571371c0456980
Author:     Ville Syrjälä <ville.syrjala@linux.intel.com>
AuthorDate: Fri Dec 22 21:22:30 2017 +0200
Commit:     Ville Syrjälä <ville.syrjala@linux.intel.com>
CommitDate: Mon Feb 26 16:29:47 2018 +0200

    drm: Check that the plane supports the request format+modifier combo

Maybe that broke vc4?

Hmm. So either we need to stop checking against the modifiers array and
rely purely or .format_mod_supported(), or we need to somehow get the
driver to reduce the modifier to its base form. I guess we could make
.fb_modifier() do that and call it also for addfb with modifiers. And
I'd need to undo some of the modifier[0] vs. deduced modifier changes
I did to framebuffer_check(), and we'd need to preserve the original
modifier in the request for .fb_create(). Oh, but that wouldn't allow
returning a non-base modifier from .fb_modifuer() for the !modifiers
case. This is turning slightly more tricky than I had hoped...

I guess relying on .format_mod_supported() might be what we need to 
do. Unfortunately it does mean that the .format_mod_supported()
implementations must be prepared for modifiers that were not
registered with the plane. Which does feel quite a bit more
fragile.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/3] drm: Make sure at least one plane supports the fb format
  2018-03-15 18:03       ` Ville Syrjälä
@ 2018-03-15 18:48         ` Ville Syrjälä
  2018-03-16 22:07           ` Eric Anholt
  0 siblings, 1 reply; 19+ messages in thread
From: Ville Syrjälä @ 2018-03-15 18:48 UTC (permalink / raw)
  To: Eric Anholt; +Cc: intel-gfx, dri-devel

On Thu, Mar 15, 2018 at 08:03:44PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 15, 2018 at 07:48:02PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
> > > Ville Syrjala <ville.syrjala@linux.intel.com> writes:
> > > 
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > >
> > > > To make life easier for drivers, let's have the core check that the
> > > > requested pixel format is supported by at least one plane when creating
> > > > a new framebuffer.
> > > >
> > > > This eases the burden on drivers by making sure they'll never get
> > > > requests to create fbs with unsupported pixel formats. Thanks to the
> > > > new .fb_modifier() hook this check can now be done whether the request
> > > > specifies the modifier directly or driver has to deduce it from the
> > > > gem bo tiling (or via any other method really).
> > > >
> > > > v0: Accept anyformat if the driver doesn't do planes (Eric)
> > > >     s/planes_have_format/any_plane_has_format/ (Eric)
> > > >     Check the modifier as well since we already have a function
> > > >     that does both
> > > > v3: Don't do the check in the core since we may not know the
> > > >     modifier yet, instead export the function and let drivers
> > > >     call it themselves
> > > > v4: Unexport the functiona and put the format_default check back
> > > >     since this will again be called by the core, ie. undo v3 ;)
> > > >
> > > > Cc: Eric Anholt <eric@anholt.net>
> > > > Testcase: igt/kms_addfb_basic/expected-formats
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > ---
> > > >  drivers/gpu/drm/drm_framebuffer.c | 30 ++++++++++++++++++++++++++++++
> > > >  1 file changed, 30 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> > > > index 21d3d51eb261..e618a6b728d4 100644
> > > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > > @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
> > > >  	return DIV_ROUND_UP(height, format->vsub);
> > > >  }
> > > >  
> > > > +static bool any_plane_has_format(struct drm_device *dev,
> > > > +				 u32 format, u64 modifier)
> > > > +{
> > > > +	struct drm_plane *plane;
> > > > +
> > > > +	drm_for_each_plane(plane, dev) {
> > > > +		/*
> > > > +		 * In case the driver doesn't really do
> > > > +		 * planes we have to accept any format here.
> > > > +		 */
> > > > +		if (plane->format_default)
> > > > +			return true;
> > > > +
> > > > +		if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
> > > > +			return true;
> > > > +	}
> > > > +
> > > > +	return false;
> > > > +}
> > > 
> > > This drm_plane_check_pixel_format() will always fail for VC4's SAND
> > > modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
> > > as a bit of metadata (like how we have horizontal stride passed outside
> > > of the modifier) and you can't list all of the possible values in an
> > > array on the plane.
> > 
> > Hmm. drm_atomic_plane_check() etc. call this thing as well. How does
> > that manage to work currently?
> 
> Maybe it doesn't. I added the modifier checks in
> 
> commit 23163a7d4b032489d375099d56571371c0456980
> Author:     Ville Syrjälä <ville.syrjala@linux.intel.com>
> AuthorDate: Fri Dec 22 21:22:30 2017 +0200
> Commit:     Ville Syrjälä <ville.syrjala@linux.intel.com>
> CommitDate: Mon Feb 26 16:29:47 2018 +0200
> 
>     drm: Check that the plane supports the request format+modifier combo
> 
> Maybe that broke vc4?
> 
> Hmm. So either we need to stop checking against the modifiers array and
> rely purely or .format_mod_supported(), or we need to somehow get the
> driver to reduce the modifier to its base form. I guess we could make
> .fb_modifier() do that and call it also for addfb with modifiers. And
> I'd need to undo some of the modifier[0] vs. deduced modifier changes
> I did to framebuffer_check(), and we'd need to preserve the original
> modifier in the request for .fb_create(). Oh, but that wouldn't allow
> returning a non-base modifier from .fb_modifuer() for the !modifiers
> case. This is turning slightly more tricky than I had hoped...
> 
> I guess relying on .format_mod_supported() might be what we need to 
> do. Unfortunately it does mean that the .format_mod_supported()
> implementations must be prepared for modifiers that were not
> registered with the plane. Which does feel quite a bit more
> fragile.

And that last apporach would be annoying for i915. So I think the other
apporach is better.

Fortunately it seems your SAND modifiers aren't upstream yet so I didn't
break them :) I had a quick look at your github and it looks like the
first apporach would work.

Something like this is what I had in mind. Loosk like you could plug in
fourcc_mod_broadcom_mod() almost directly into .base_modifier().

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a5d1fc7e8a37..250f66d51c2c 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -552,6 +552,8 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
 int drm_plane_check_pixel_format(struct drm_plane *plane,
 				 u32 format, u64 modifier)
 {
+	struct drm_device *dev = plane->dev;
+	u64 base_modifier;
 	unsigned int i;
 
 	for (i = 0; i < plane->format_count; i++) {
@@ -564,8 +566,13 @@ int drm_plane_check_pixel_format(struct drm_plane *plane,
 	if (!plane->modifier_count)
 		return 0;
 
+	if (dev->mode_config.funcs->base_modifier)
+		base_modifier = dev->mode_config.funcs->base_modifier(dev, modifier);
+	else
+		base_modifier = modifier;
+
 	for (i = 0; i < plane->modifier_count; i++) {
-		if (modifier == plane->modifiers[i])
+		if (base_modifier == plane->modifiers[i])
 			break;
 	}
 	if (i == plane->modifier_count)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index c74aed292b58..2ff2438263ef 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -45,6 +45,19 @@ struct drm_display_mode;
  * involve drivers.
  */
 struct drm_mode_config_funcs {
+	/**
+	 * @base_modifier:
+	 *
+	 * Reduce the passed in modifier to its base form. This optional
+	 * hook needs to be provided by any driver that embeds extra
+	 * metadata within the format modifier.
+	 *
+	 * RETURNS:
+	 * The base form of the modifier with any extra metadata
+	 * cleared out.
+	 */
+	u64 (*base_modifier)(struct drm_device *dev, u64 modifier);
+
 	/**
 	 * @fb_modifier:
 	 *
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index f7bf4a48b1c3..5e26d2a5f6ab 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -489,8 +489,6 @@ enum drm_plane_type {
  * @format_types: array of formats supported by this plane
  * @format_count: number of formats supported
  * @format_default: driver hasn't supplied supported formats for the plane
- * @modifiers: array of modifiers supported by this plane
- * @modifier_count: number of modifiers supported
  * @old_fb: Temporary tracking of the old fb while a modeset is ongoing. Used by
  * 	drm_mode_set_config_internal() to implement correct refcounting.
  * @funcs: helper functions
@@ -524,7 +522,15 @@ struct drm_plane {
 	unsigned int format_count;
 	bool format_default;
 
+	/**
+	 * @modifiers: Array of modifiers supported by this plane. If
+	 * the driver embeds any extra metadata within modifiers these
+	 * modifiers must be in their base form.
+	 */
 	uint64_t *modifiers;
+	/**
+	 * @modifier_count: number of modifiers supported
+	 */
 	unsigned int modifier_count;
 
 	/**
-- 
2.16.1

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/3] drm: Make sure at least one plane supports the fb format
  2018-03-15 18:48         ` Ville Syrjälä
@ 2018-03-16 22:07           ` Eric Anholt
  0 siblings, 0 replies; 19+ messages in thread
From: Eric Anholt @ 2018-03-16 22:07 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx, dri-devel


[-- Attachment #1.1: Type: text/plain, Size: 5293 bytes --]

Ville Syrjälä <ville.syrjala@linux.intel.com> writes:

> On Thu, Mar 15, 2018 at 08:03:44PM +0200, Ville Syrjälä wrote:
>> On Thu, Mar 15, 2018 at 07:48:02PM +0200, Ville Syrjälä wrote:
>> > On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
>> > > Ville Syrjala <ville.syrjala@linux.intel.com> writes:
>> > > 
>> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > > >
>> > > > To make life easier for drivers, let's have the core check that the
>> > > > requested pixel format is supported by at least one plane when creating
>> > > > a new framebuffer.
>> > > >
>> > > > This eases the burden on drivers by making sure they'll never get
>> > > > requests to create fbs with unsupported pixel formats. Thanks to the
>> > > > new .fb_modifier() hook this check can now be done whether the request
>> > > > specifies the modifier directly or driver has to deduce it from the
>> > > > gem bo tiling (or via any other method really).
>> > > >
>> > > > v0: Accept anyformat if the driver doesn't do planes (Eric)
>> > > >     s/planes_have_format/any_plane_has_format/ (Eric)
>> > > >     Check the modifier as well since we already have a function
>> > > >     that does both
>> > > > v3: Don't do the check in the core since we may not know the
>> > > >     modifier yet, instead export the function and let drivers
>> > > >     call it themselves
>> > > > v4: Unexport the functiona and put the format_default check back
>> > > >     since this will again be called by the core, ie. undo v3 ;)
>> > > >
>> > > > Cc: Eric Anholt <eric@anholt.net>
>> > > > Testcase: igt/kms_addfb_basic/expected-formats
>> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > > > ---
>> > > >  drivers/gpu/drm/drm_framebuffer.c | 30 ++++++++++++++++++++++++++++++
>> > > >  1 file changed, 30 insertions(+)
>> > > >
>> > > > diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
>> > > > index 21d3d51eb261..e618a6b728d4 100644
>> > > > --- a/drivers/gpu/drm/drm_framebuffer.c
>> > > > +++ b/drivers/gpu/drm/drm_framebuffer.c
>> > > > @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
>> > > >  	return DIV_ROUND_UP(height, format->vsub);
>> > > >  }
>> > > >  
>> > > > +static bool any_plane_has_format(struct drm_device *dev,
>> > > > +				 u32 format, u64 modifier)
>> > > > +{
>> > > > +	struct drm_plane *plane;
>> > > > +
>> > > > +	drm_for_each_plane(plane, dev) {
>> > > > +		/*
>> > > > +		 * In case the driver doesn't really do
>> > > > +		 * planes we have to accept any format here.
>> > > > +		 */
>> > > > +		if (plane->format_default)
>> > > > +			return true;
>> > > > +
>> > > > +		if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
>> > > > +			return true;
>> > > > +	}
>> > > > +
>> > > > +	return false;
>> > > > +}
>> > > 
>> > > This drm_plane_check_pixel_format() will always fail for VC4's SAND
>> > > modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
>> > > as a bit of metadata (like how we have horizontal stride passed outside
>> > > of the modifier) and you can't list all of the possible values in an
>> > > array on the plane.
>> > 
>> > Hmm. drm_atomic_plane_check() etc. call this thing as well. How does
>> > that manage to work currently?
>> 
>> Maybe it doesn't. I added the modifier checks in
>> 
>> commit 23163a7d4b032489d375099d56571371c0456980
>> Author:     Ville Syrjälä <ville.syrjala@linux.intel.com>
>> AuthorDate: Fri Dec 22 21:22:30 2017 +0200
>> Commit:     Ville Syrjälä <ville.syrjala@linux.intel.com>
>> CommitDate: Mon Feb 26 16:29:47 2018 +0200
>> 
>>     drm: Check that the plane supports the request format+modifier combo
>> 
>> Maybe that broke vc4?
>> 
>> Hmm. So either we need to stop checking against the modifiers array and
>> rely purely or .format_mod_supported(), or we need to somehow get the
>> driver to reduce the modifier to its base form. I guess we could make
>> .fb_modifier() do that and call it also for addfb with modifiers. And
>> I'd need to undo some of the modifier[0] vs. deduced modifier changes
>> I did to framebuffer_check(), and we'd need to preserve the original
>> modifier in the request for .fb_create(). Oh, but that wouldn't allow
>> returning a non-base modifier from .fb_modifuer() for the !modifiers
>> case. This is turning slightly more tricky than I had hoped...
>> 
>> I guess relying on .format_mod_supported() might be what we need to 
>> do. Unfortunately it does mean that the .format_mod_supported()
>> implementations must be prepared for modifiers that were not
>> registered with the plane. Which does feel quite a bit more
>> fragile.
>
> And that last apporach would be annoying for i915. So I think the other
> apporach is better.
>
> Fortunately it seems your SAND modifiers aren't upstream yet so I didn't
> break them :) I had a quick look at your github and it looks like the
> first apporach would work.
>
> Something like this is what I had in mind. Loosk like you could plug in
> fourcc_mod_broadcom_mod() almost directly into .base_modifier().

I think just trusting format_mod_supported's result makes more sense.
See the patch series I just sent.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: 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] 19+ messages in thread

end of thread, other threads:[~2018-03-16 22:07 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-12 20:40 [PATCH 1/3] drm: Add the optional .fb_modifier() hook Ville Syrjala
2018-03-12 20:40 ` [PATCH 2/3] drm: Make sure at least one plane supports the fb format Ville Syrjala
2018-03-15 17:42   ` Eric Anholt
2018-03-15 17:48     ` Ville Syrjälä
2018-03-15 18:03       ` Ville Syrjälä
2018-03-15 18:48         ` Ville Syrjälä
2018-03-16 22:07           ` Eric Anholt
2018-03-12 20:40 ` [PATCH 3/3] drm/i915: Eliminate the horrendous format check code Ville Syrjala
2018-03-12 21:44 ` ✗ Fi.CI.BAT: failure for series starting with [1/3] drm: Add the optional .fb_modifier() hook Patchwork
2018-03-13 14:28 ` [PATCH v2 1/3] " Ville Syrjala
2018-03-13 14:38   ` Michel Dänzer
2018-03-13 15:12     ` Ville Syrjälä
2018-03-13 15:18       ` Michel Dänzer
2018-03-13 15:20     ` Daniel Vetter
2018-03-13 15:35       ` Michel Dänzer
2018-03-13 15:46         ` Ville Syrjälä
2018-03-13 16:06 ` ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2) Patchwork
2018-03-13 16:56 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-03-13 17:03   ` Ville Syrjälä

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.