[PATCH v4 0/6] Enable NV12 support

[PATCH v4 0/6] Enable NV12 support

[Vidya Srinivas]

Enabling NV12 support:
- Framebuffer creation
- Primary and Sprite plane support
Patch series depend on Enable display workaround 827 patch
mentioned below submitted by Maarten

Changes from prev version:
Included RB from Maarten for patches
Included RB from Kristian

Chandra Konduru (3):
  drm/i915: Add NV12 as supported format for primary plane
  drm/i915: Add NV12 as supported format for sprite plane
  drm/i915: Add NV12 support to intel_framebuffer_init

Maarten Lankhorst (2):
  drm/i915: Enable display workaround 827 for all planes, v2.
  drm/i915: Add skl_check_nv12_surface for NV12

Vidya Srinivas (1):
  drm/i915: Enable Display WA 0528

 drivers/gpu/drm/i915/intel_atomic_plane.c |   7 +-
 drivers/gpu/drm/i915/intel_display.c      | 169 ++++++++++++++++++++++++++----
 drivers/gpu/drm/i915/intel_drv.h          |   3 +
 drivers/gpu/drm/i915/intel_sprite.c       |  44 ++++++--
 4 files changed, 198 insertions(+), 25 deletions(-)

-- 
2.7.4

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

[PATCH v4 1/6] drm/i915: Enable display workaround 827 for all planes, v2.

[Vidya Srinivas]

From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

The workaround was applied only to the primary plane, but is required
on all planes. Iterate over all planes in the crtc atomic check to see
if the workaround is enabled, and only perform the actual toggling in
the pre/post plane update functions.

Changes since v1:
- Track active NV12 planes in a nv12_planes bitmask. (Ville)

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  7 +++++-
 drivers/gpu/drm/i915/intel_display.c      | 40 ++++++++++++++++++-------------
 drivers/gpu/drm/i915/intel_drv.h          |  1 +
 3 files changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7481ce8..6d06878 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -183,11 +183,16 @@ int intel_plane_atomic_check_with_state(const struct intel_crtc_state *old_crtc_
 	}
 
 	/* FIXME pre-g4x don't work like this */
-	if (intel_state->base.visible)
+	if (state->visible)
 		crtc_state->active_planes |= BIT(intel_plane->id);
 	else
 		crtc_state->active_planes &= ~BIT(intel_plane->id);
 
+	if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
+		crtc_state->nv12_planes |= BIT(intel_plane->id);
+	else
+		crtc_state->nv12_planes &= ~BIT(intel_plane->id);
+
 	return intel_plane_atomic_calc_changes(old_crtc_state,
 					       &crtc_state->base,
 					       old_plane_state,
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 020900e..22c8a7d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5138,6 +5138,19 @@ static bool hsw_post_update_enable_ips(const struct intel_crtc_state *old_crtc_s
 	return !old_crtc_state->ips_enabled;
 }
 
+static bool needs_nv12_wa(struct drm_i915_private *dev_priv,
+			  const struct intel_crtc_state *crtc_state)
+{
+	if (!crtc_state->nv12_planes)
+		return false;
+
+	if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
+	       IS_CANNONLAKE(dev_priv))
+		return true;
+
+	return false;
+}
+
 static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
 {
 	struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
@@ -5162,7 +5175,6 @@ static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
 	if (old_primary_state) {
 		struct drm_plane_state *new_primary_state =
 			drm_atomic_get_new_plane_state(old_state, primary);
-		struct drm_framebuffer *fb = new_primary_state->fb;
 
 		intel_fbc_post_update(crtc);
 
@@ -5170,15 +5182,12 @@ static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
 		    (needs_modeset(&pipe_config->base) ||
 		     !old_primary_state->visible))
 			intel_post_enable_primary(&crtc->base, pipe_config);
-
-		/* Display WA 827 */
-		if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
-		    IS_CANNONLAKE(dev_priv)) {
-			if (fb && fb->format->format == DRM_FORMAT_NV12)
-				skl_wa_clkgate(dev_priv, crtc->pipe, false);
-		}
-
 	}
+
+	/* Display WA 827 */
+	if (needs_nv12_wa(dev_priv, old_crtc_state) &&
+	    !needs_nv12_wa(dev_priv, pipe_config))
+		skl_wa_clkgate(dev_priv, crtc->pipe, false);
 }
 
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
@@ -5202,14 +5211,6 @@ static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
 		struct intel_plane_state *new_primary_state =
 			intel_atomic_get_new_plane_state(old_intel_state,
 							 to_intel_plane(primary));
-		struct drm_framebuffer *fb = new_primary_state->base.fb;
-
-		/* Display WA 827 */
-		if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
-		    IS_CANNONLAKE(dev_priv)) {
-			if (fb && fb->format->format == DRM_FORMAT_NV12)
-				skl_wa_clkgate(dev_priv, crtc->pipe, true);
-		}
 
 		intel_fbc_pre_update(crtc, pipe_config, new_primary_state);
 		/*
@@ -5221,6 +5222,11 @@ static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
 			intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, false);
 	}
 
+	/* Display WA 827 */
+	if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
+	    needs_nv12_wa(dev_priv, pipe_config))
+		skl_wa_clkgate(dev_priv, crtc->pipe, true);
+
 	/*
 	 * Vblank time updates from the shadow to live plane control register
 	 * are blocked if the memory self-refresh mode is active at that
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5bd2263..d8930676 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -882,6 +882,7 @@ struct intel_crtc_state {
 
 	/* bitmask of visible planes (enum plane_id) */
 	u8 active_planes;
+	u8 nv12_planes;
 
 	/* HDMI scrambling status */
 	bool hdmi_scrambling;
-- 
2.7.4

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

[PATCH v4 2/6] drm/i915: Add NV12 as supported format for primary plane

[Vidya Srinivas]

From: Chandra Konduru <chandra.konduru@intel.com>

This patch adds NV12 to list of supported formats for
primary plane

v2: Rebased (Chandra Konduru)

v3: Rebased (me)

v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats

v5: Rebased (me)

v6: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v7: Review comments by Ville addressed
	Restricting the NV12 for BXT and on PIPE A and B
Rebased (me)

v8: Rebased (me)
Modified restricting the NV12 support for both BXT and KBL.

v9: Rebased (me)

v10: Addressed review comments from Maarten.
	Adding NV12 inside skl_primary_formats itself.

v11: Adding Reviewed By tag from Shashank Sharma

v12: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v13: Addressed review comments from Ville
Added skl_pri_planar_formats to include NV12
and skl_plane_has_planar function to check for
NV12 support on plane. Added NV12 format to
skl_mod_supported. These were review comments
from Kristian Høgsberg <hoegsberg@gmail.com>

v14: Added reviewed by from Juha-Pekka Heikkila

v15: Rebased the series

v16: Added all tiling support under mod supported
for NV12. Credits to Megha Aggarwal

v17: Added RB by Maarten and Kristian

Credits-to: Megha Aggarwal megha.aggarwal@intel.com
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Kristian Høgsberg <hoegsberg@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 55 ++++++++++++++++++++++++++++++++++--
 drivers/gpu/drm/i915/intel_drv.h     |  2 ++
 2 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 22c8a7d..1a0fae9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,6 +88,22 @@ static const uint32_t skl_primary_formats[] = {
 	DRM_FORMAT_VYUY,
 };
 
+static const uint32_t skl_pri_planar_formats[] = {
+	DRM_FORMAT_C8,
+	DRM_FORMAT_RGB565,
+	DRM_FORMAT_XRGB8888,
+	DRM_FORMAT_XBGR8888,
+	DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_ABGR8888,
+	DRM_FORMAT_XRGB2101010,
+	DRM_FORMAT_XBGR2101010,
+	DRM_FORMAT_YUYV,
+	DRM_FORMAT_YVYU,
+	DRM_FORMAT_UYVY,
+	DRM_FORMAT_VYUY,
+	DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_format_modifiers_noccs[] = {
 	I915_FORMAT_MOD_Yf_TILED,
 	I915_FORMAT_MOD_Y_TILED,
@@ -13124,6 +13140,12 @@ static bool skl_mod_supported(uint32_t format, uint64_t modifier)
 		if (modifier == I915_FORMAT_MOD_Yf_TILED)
 			return true;
 		/* fall through */
+	case DRM_FORMAT_NV12:
+		if (modifier == DRM_FORMAT_MOD_LINEAR ||
+		    modifier == I915_FORMAT_MOD_X_TILED ||
+		    modifier == I915_FORMAT_MOD_Y_TILED ||
+		    modifier == I915_FORMAT_MOD_Yf_TILED)
+			return true;
 	case DRM_FORMAT_C8:
 		if (modifier == DRM_FORMAT_MOD_LINEAR ||
 		    modifier == I915_FORMAT_MOD_X_TILED ||
@@ -13328,6 +13350,30 @@ static bool skl_plane_has_fbc(struct drm_i915_private *dev_priv,
 	return pipe == PIPE_A && plane_id == PLANE_PRIMARY;
 }
 
+bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
+			  enum pipe pipe, enum plane_id plane_id)
+{
+	if (plane_id == PLANE_PRIMARY) {
+		if (IS_SKYLAKE(dev_priv))
+			return false;
+		else if ((INTEL_GEN(dev_priv) == 9 && pipe == PIPE_C) &&
+			 !IS_GEMINILAKE(dev_priv))
+			return false;
+	} else if (plane_id >= PLANE_SPRITE0) {
+		if (plane_id == PLANE_CURSOR)
+			return false;
+		if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) == 10) {
+			if (plane_id != PLANE_SPRITE0)
+				return false;
+		} else {
+			if (plane_id != PLANE_SPRITE0 || pipe == PIPE_C ||
+			    IS_SKYLAKE(dev_priv))
+				return false;
+		}
+	}
+	return true;
+}
+
 static struct intel_plane *
 intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
@@ -13388,8 +13434,13 @@ intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
 	primary->check_plane = intel_check_primary_plane;
 
 	if (INTEL_GEN(dev_priv) >= 9) {
-		intel_primary_formats = skl_primary_formats;
-		num_formats = ARRAY_SIZE(skl_primary_formats);
+		if (skl_plane_has_planar(dev_priv, pipe, PLANE_PRIMARY)) {
+			intel_primary_formats = skl_pri_planar_formats;
+			num_formats = ARRAY_SIZE(skl_pri_planar_formats);
+		} else {
+			intel_primary_formats = skl_primary_formats;
+			num_formats = ARRAY_SIZE(skl_primary_formats);
+		}
 
 		if (skl_plane_has_ccs(dev_priv, pipe, PLANE_PRIMARY))
 			modifiers = skl_format_modifiers_ccs;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d8930676..01352ef 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2063,6 +2063,8 @@ bool skl_plane_get_hw_state(struct intel_plane *plane);
 bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
 		       enum pipe pipe, enum plane_id plane_id);
 bool intel_format_is_yuv(uint32_t format);
+bool skl_plane_has_planar(struct drm_i915_private *dev_priv,
+			  enum pipe pipe, enum plane_id plane_id);
 
 /* intel_tv.c */
 void intel_tv_init(struct drm_i915_private *dev_priv);
-- 
2.7.4

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

[PATCH v4 3/6] drm/i915: Add NV12 as supported format for sprite plane

[Vidya Srinivas]

From: Chandra Konduru <chandra.konduru@intel.com>

This patch adds NV12 to list of supported formats for sprite plane.

v2: Rebased (me)

v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats

v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.

v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B

v7: Rebased (me)

v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.

v11: Addressed review comments from Shashank Sharma

v12: Addressed review comments from Shashank Sharma
Made the condition in intel_sprite_plane_create
simple and easy to read as suggested.

v13: Adding reviewed by tag from Shashank Sharma
Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Ville
Added skl_planar_formats to include NV12
and a check skl_plane_has_planar in sprite create
Added NV12 format to skl_mod_supported. These were
review comments from Kristian Høgsberg <hoegsberg@gmail.com>

v15: Added reviewed by from Juha-Pekka Heikkila

v16: Rebased the series

v17: Added all tiling under mod supported for NV12
Credits to Megha Aggarwal

v18: Added RB by Maarten and Kristian

Credits-to: Megha Aggarwal <megha.aggarwal@intel.com>
Credits-to: Kristian Høgsberg <hoegsberg@gmail.com>
Reviewed-by: Kristian Høgsberg <hoegsberg@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
---
 drivers/gpu/drm/i915/intel_sprite.c | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index aa1dfaa..8b7947d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1253,6 +1253,19 @@ static uint32_t skl_plane_formats[] = {
 	DRM_FORMAT_VYUY,
 };
 
+static uint32_t skl_planar_formats[] = {
+	DRM_FORMAT_RGB565,
+	DRM_FORMAT_ABGR8888,
+	DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_XBGR8888,
+	DRM_FORMAT_XRGB8888,
+	DRM_FORMAT_YUYV,
+	DRM_FORMAT_YVYU,
+	DRM_FORMAT_UYVY,
+	DRM_FORMAT_VYUY,
+	DRM_FORMAT_NV12,
+};
+
 static const uint64_t skl_plane_format_modifiers_noccs[] = {
 	I915_FORMAT_MOD_Yf_TILED,
 	I915_FORMAT_MOD_Y_TILED,
@@ -1350,6 +1363,12 @@ static bool skl_mod_supported(uint32_t format, uint64_t modifier)
 		if (modifier == I915_FORMAT_MOD_Yf_TILED)
 			return true;
 		/* fall through */
+	case DRM_FORMAT_NV12:
+		if (modifier == DRM_FORMAT_MOD_LINEAR ||
+		    modifier == I915_FORMAT_MOD_X_TILED ||
+		    modifier == I915_FORMAT_MOD_Y_TILED ||
+		    modifier == I915_FORMAT_MOD_Yf_TILED)
+			return true;
 	case DRM_FORMAT_C8:
 		if (modifier == DRM_FORMAT_MOD_LINEAR ||
 		    modifier == I915_FORMAT_MOD_X_TILED ||
@@ -1446,8 +1465,14 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv,
 		intel_plane->disable_plane = skl_disable_plane;
 		intel_plane->get_hw_state = skl_plane_get_hw_state;
 
-		plane_formats = skl_plane_formats;
-		num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+		if (skl_plane_has_planar(dev_priv, pipe,
+					 PLANE_SPRITE0 + plane)) {
+			plane_formats = skl_planar_formats;
+			num_plane_formats = ARRAY_SIZE(skl_planar_formats);
+		} else {
+			plane_formats = skl_plane_formats;
+			num_plane_formats = ARRAY_SIZE(skl_plane_formats);
+		}
 
 		if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
 			modifiers = skl_plane_format_modifiers_ccs;
-- 
2.7.4

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

[PATCH v4 4/6] drm/i915: Add NV12 support to intel_framebuffer_init

[Vidya Srinivas]

From: Chandra Konduru <chandra.konduru@intel.com>

This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (Chandra Konduru)

v3: rebased (me)

v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case

v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.

v6: Rebased (me)

v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.

v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.

v9: Rebased (me)

v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable

v11: Addressed review comments from Shashank Sharma

v12: Adding Reviewed By from Shashank Sharma

v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"

v14: Addressed review comments from Maarten.
Add checks for fb width height for NV12 and fail the fb
creation if check fails. Added reviewed by from
Juha-Pekka Heikkila

v15: Rebased the series

v16: Setting the minimum value during fb creating to 16
as per Bspec for NV12. Earlier minimum was expected
to be > 16. Now changed it to >=16.

v17: Adding restriction to framebuffer_init - the fb
width and height should be a multiplier of 4

v18: Added RB from Maarten. Included Maarten's review comments
Dont allow CCS formats for fb creation of NV12

Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1a0fae9..b9ccf44 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14261,6 +14261,19 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 			goto err;
 		}
 		break;
+	case DRM_FORMAT_NV12:
+		if ((mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED_CCS) ||
+		    (mode_cmd->modifier[0] == I915_FORMAT_MOD_Yf_TILED_CCS)) {
+			DRM_DEBUG_KMS("RC not to be enabled with NV12\n");
+			goto err;
+		}
+		if (INTEL_GEN(dev_priv) < 9 || IS_SKYLAKE(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));
@@ -14273,6 +14286,14 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 
 	drm_helper_mode_fill_fb_struct(&dev_priv->drm, fb, mode_cmd);
 
+	if (fb->format->format == DRM_FORMAT_NV12 &&
+	    (fb->width < SKL_MIN_YUV_420_SRC_W ||
+	     fb->height < SKL_MIN_YUV_420_SRC_H ||
+	     (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
+		DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
+		return -EINVAL;
+	}
+
 	for (i = 0; i < fb->format->num_planes; i++) {
 		u32 stride_alignment;
 
-- 
2.7.4

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

[PATCH v4 5/6] drm/i915: Enable Display WA 0528

[Vidya Srinivas]

Possible hang with NV12 plane surface formats.
WA: When the plane source pixel format is NV12,
the CHICKEN_PIPESL_* register bit 22 must be set to 1
and the render decompression must not be enabled
on any of the planes in that pipe.

v2: removed unnecessary POSTING_READ

v3: Added RB from Maarten

Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index b9ccf44..925402e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -505,6 +505,18 @@ static const struct intel_limit intel_limits_bxt = {
 };
 
 static void
+skl_wa_528(struct drm_i915_private *dev_priv, int pipe, bool enable)
+{
+	if (IS_SKYLAKE(dev_priv))
+		return;
+
+	if (enable)
+		I915_WRITE(CHICKEN_PIPESL_1(pipe), HSW_FBCQ_DIS);
+	else
+		I915_WRITE(CHICKEN_PIPESL_1(pipe), 0);
+}
+
+static void
 skl_wa_clkgate(struct drm_i915_private *dev_priv, int pipe, bool enable)
 {
 	if (IS_SKYLAKE(dev_priv))
@@ -5202,8 +5214,10 @@ static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
 
 	/* Display WA 827 */
 	if (needs_nv12_wa(dev_priv, old_crtc_state) &&
-	    !needs_nv12_wa(dev_priv, pipe_config))
+	    !needs_nv12_wa(dev_priv, pipe_config)) {
 		skl_wa_clkgate(dev_priv, crtc->pipe, false);
+		skl_wa_528(dev_priv, crtc->pipe, false);
+	}
 }
 
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
@@ -5240,8 +5254,10 @@ static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
 
 	/* Display WA 827 */
 	if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
-	    needs_nv12_wa(dev_priv, pipe_config))
+	    needs_nv12_wa(dev_priv, pipe_config)) {
 		skl_wa_clkgate(dev_priv, crtc->pipe, true);
+		skl_wa_528(dev_priv, crtc->pipe, true);
+	}
 
 	/*
 	 * Vblank time updates from the shadow to live plane control register
-- 
2.7.4

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

[PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Vidya Srinivas]

From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

We skip src trunction/adjustments for
NV12 case and handle the sizes directly.
Without this, pipe fifo underruns are seen on APL/KBL.

v2: For NV12, making the src coordinates multiplier of 4

v3: Moving all the src coords handling code for NV12
to skl_check_nv12_surface

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 39 ++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
 2 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 925402e..b8dbaca 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
 	return 0;
 }
 
+static int
+skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
+		       struct intel_plane_state *plane_state)
+{
+	int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
+	int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
+
+	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
+	    ((plane_state->base.src_y >> 16) % 4) != 0 ||
+	    ((plane_state->base.src_w >> 16) % 4) != 0 ||
+	    ((plane_state->base.src_h >> 16) % 4) != 0) {
+		DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
+		return -EINVAL;
+	}
+
+	/* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
+	if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
+	    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
+		DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
+			      crtc_x2, crtc_y2,
+			      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
+		return -EINVAL;
+	}
+
+	plane_state->base.src.x1 =
+		DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
+	plane_state->base.src.x2 =
+		DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
+	plane_state->base.src.y1 =
+		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
+	plane_state->base.src.y2 =
+		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
+
+	return 0;
+}
+
 static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
 {
 	const struct drm_framebuffer *fb = plane_state->base.fb;
@@ -3201,6 +3237,9 @@ int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
 	 * the main surface setup depends on it.
 	 */
 	if (fb->format->format == DRM_FORMAT_NV12) {
+		ret = skl_check_nv12_surface(crtc_state, plane_state);
+		if (ret)
+			return ret;
 		ret = skl_check_nv12_aux_surface(plane_state);
 		if (ret)
 			return ret;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index 8b7947d..f9985fb 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane *plane,
 			return vscale;
 		}
 
-		/* Make the source viewport size an exact multiple of the scaling factors. */
-		drm_rect_adjust_size(src,
-				     drm_rect_width(dst) * hscale - drm_rect_width(src),
-				     drm_rect_height(dst) * vscale - drm_rect_height(src));
+		if (fb->format->format != DRM_FORMAT_NV12) {
+			/*
+			 * Make the source viewport size
+			 * an exact multiple of the scaling factors
+			 */
+			drm_rect_adjust_size(src,
+					     (drm_rect_width(dst) * hscale -
+					      drm_rect_width(src)),
+					     (drm_rect_height(dst) * vscale -
+					      drm_rect_height(src)));
+		}
 
 		drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
 				    state->base.rotation);
-- 
2.7.4

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Mika Kahola]

On Wed, 2018-04-18 at 09:38 +0530, Vidya Srinivas wrote:
> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> 
> We skip src trunction/adjustments for
> NV12 case and handle the sizes directly.
> Without this, pipe fifo underruns are seen on APL/KBL.
> 
> v2: For NV12, making the src coordinates multiplier of 4
> 
> v3: Moving all the src coords handling code for NV12
> to skl_check_nv12_surface
The patch looks good to me.

Reviewed-by: Mika Kahola <mika.kahola@intel.com>

> 
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 39
> ++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
>  2 files changed, 50 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 925402e..b8dbaca 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct
> intel_crtc_state *crtc_state,
>  	return 0;
>  }
>  
> +static int
> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> +		       struct intel_plane_state *plane_state)
> +{
> +	int crtc_x2 = plane_state->base.crtc_x + plane_state-
> >base.crtc_w;
> +	int crtc_y2 = plane_state->base.crtc_y + plane_state-
> >base.crtc_h;
> +
> +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> +	    ((plane_state->base.src_y >> 16) % 4) != 0 ||
> +	    ((plane_state->base.src_w >> 16) % 4) != 0 ||
> +	    ((plane_state->base.src_h >> 16) % 4) != 0) {
> +		DRM_DEBUG_KMS("src coords must be multiple of 4 for
> NV12\n");
> +		return -EINVAL;
> +	}
> +
> +	/* Clipping would cause a 1-3 pixel gap at the edge of the
> screen? */
> +	if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state-
> >pipe_src_w % 4) ||
> +	    (crtc_y2 > crtc_state->pipe_src_h && crtc_state-
> >pipe_src_h % 4)) {
> +		DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> %u,%u\n",
> +			      crtc_x2, crtc_y2,
> +			      crtc_state->pipe_src_w, crtc_state-
> >pipe_src_h);
> +		return -EINVAL;
> +	}
> +
> +	plane_state->base.src.x1 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18)
> << 18;
> +	plane_state->base.src.x2 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18)
> << 18;
> +	plane_state->base.src.y1 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18)
> << 18;
> +	plane_state->base.src.y2 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18)
> << 18;
> +
> +	return 0;
> +}
> +
>  static int skl_check_nv12_aux_surface(struct intel_plane_state
> *plane_state)
>  {
>  	const struct drm_framebuffer *fb = plane_state->base.fb;
> @@ -3201,6 +3237,9 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
>  	 * the main surface setup depends on it.
>  	 */
>  	if (fb->format->format == DRM_FORMAT_NV12) {
> +		ret = skl_check_nv12_surface(crtc_state,
> plane_state);
> +		if (ret)
> +			return ret;
>  		ret = skl_check_nv12_aux_surface(plane_state);
>  		if (ret)
>  			return ret;
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 8b7947d..f9985fb 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane
> *plane,
>  			return vscale;
>  		}
>  
> -		/* Make the source viewport size an exact multiple
> of the scaling factors. */
> -		drm_rect_adjust_size(src,
> -				     drm_rect_width(dst) * hscale -
> drm_rect_width(src),
> -				     drm_rect_height(dst) * vscale -
> drm_rect_height(src));
> +		if (fb->format->format != DRM_FORMAT_NV12) {
> +			/*
> +			 * Make the source viewport size
> +			 * an exact multiple of the scaling factors
> +			 */
> +			drm_rect_adjust_size(src,
> +					     (drm_rect_width(dst) *
> hscale -
> +					      drm_rect_width(src)),
> +					     (drm_rect_height(dst) *
> vscale -
> +					      drm_rect_height(src)))
> ;
> +		}
>  
>  		drm_rect_rotate_inv(src, fb->width << 16, fb->height 
> << 16,
>  				    state->base.rotation);
-- 
Mika Kahola - Intel OTC

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Kahola, Mika
> Sent: Wednesday, April 18, 2018 5:39 PM
> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-
> gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
> skl_check_nv12_surface for NV12
> 
> On Wed, 2018-04-18 at 09:38 +0530, Vidya Srinivas wrote:
> > From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >
> > We skip src trunction/adjustments for
> > NV12 case and handle the sizes directly.
> > Without this, pipe fifo underruns are seen on APL/KBL.
> >
> > v2: For NV12, making the src coordinates multiplier of 4
> >
> > v3: Moving all the src coords handling code for NV12 to
> > skl_check_nv12_surface
> The patch looks good to me.
> 
> Reviewed-by: Mika Kahola <mika.kahola@intel.com>

Thank you. Will add the RB in next push.

Regards
Vidya
> 
> >
> > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 39
> > ++++++++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
> >  2 files changed, 50 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 925402e..b8dbaca 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct
> > intel_crtc_state *crtc_state,
> >  	return 0;
> >  }
> >
> > +static int
> > +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> > +		       struct intel_plane_state *plane_state) {
> > +	int crtc_x2 = plane_state->base.crtc_x + plane_state-
> > >base.crtc_w;
> > +	int crtc_y2 = plane_state->base.crtc_y + plane_state-
> > >base.crtc_h;
> > +
> > +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> > +	    ((plane_state->base.src_y >> 16) % 4) != 0 ||
> > +	    ((plane_state->base.src_w >> 16) % 4) != 0 ||
> > +	    ((plane_state->base.src_h >> 16) % 4) != 0) {
> > +		DRM_DEBUG_KMS("src coords must be multiple of 4 for
> > NV12\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	/* Clipping would cause a 1-3 pixel gap at the edge of the
> > screen? */
> > +	if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state-
> > >pipe_src_w % 4) ||
> > +	    (crtc_y2 > crtc_state->pipe_src_h && crtc_state-
> > >pipe_src_h % 4)) {
> > +		DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> > %u,%u\n",
> > +			      crtc_x2, crtc_y2,
> > +			      crtc_state->pipe_src_w, crtc_state-
> > >pipe_src_h);
> > +		return -EINVAL;
> > +	}
> > +
> > +	plane_state->base.src.x1 =
> > +		DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18)
> > << 18;
> > +	plane_state->base.src.x2 =
> > +		DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18)
> > << 18;
> > +	plane_state->base.src.y1 =
> > +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18)
> > << 18;
> > +	plane_state->base.src.y2 =
> > +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18)
> > << 18;
> > +
> > +	return 0;
> > +}
> > +
> >  static int skl_check_nv12_aux_surface(struct intel_plane_state
> > *plane_state)
> >  {
> >  	const struct drm_framebuffer *fb = plane_state->base.fb; @@ -
> 3201,6
> > +3237,9 @@ int skl_check_plane_surface(const struct intel_crtc_state
> > *crtc_state,
> >  	 * the main surface setup depends on it.
> >  	 */
> >  	if (fb->format->format == DRM_FORMAT_NV12) {
> > +		ret = skl_check_nv12_surface(crtc_state,
> > plane_state);
> > +		if (ret)
> > +			return ret;
> >  		ret = skl_check_nv12_aux_surface(plane_state);
> >  		if (ret)
> >  			return ret;
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 8b7947d..f9985fb 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> >  			return vscale;
> >  		}
> >
> > -		/* Make the source viewport size an exact multiple
> > of the scaling factors. */
> > -		drm_rect_adjust_size(src,
> > -				     drm_rect_width(dst) * hscale -
> > drm_rect_width(src),
> > -				     drm_rect_height(dst) * vscale -
> > drm_rect_height(src));
> > +		if (fb->format->format != DRM_FORMAT_NV12) {
> > +			/*
> > +			 * Make the source viewport size
> > +			 * an exact multiple of the scaling factors
> > +			 */
> > +			drm_rect_adjust_size(src,
> > +					     (drm_rect_width(dst) *
> > hscale -
> > +					      drm_rect_width(src)),
> > +					     (drm_rect_height(dst) *
> > vscale -
> > +					      drm_rect_height(src)))
> > ;
> > +		}
> >
> >  		drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
> >  				    state->base.rotation);
> --
> Mika Kahola - Intel OTC

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Ville Syrjälä]

On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> 
> We skip src trunction/adjustments for
> NV12 case and handle the sizes directly.
> Without this, pipe fifo underruns are seen on APL/KBL.
> 
> v2: For NV12, making the src coordinates multiplier of 4
> 
> v3: Moving all the src coords handling code for NV12
> to skl_check_nv12_surface
> 
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 39 ++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
>  2 files changed, 50 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 925402e..b8dbaca 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
>  	return 0;
>  }
>  
> +static int
> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> +		       struct intel_plane_state *plane_state)
> +{
> +	int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> +	int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
> +
> +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> +	    ((plane_state->base.src_y >> 16) % 4) != 0 ||
> +	    ((plane_state->base.src_w >> 16) % 4) != 0 ||
> +	    ((plane_state->base.src_h >> 16) % 4) != 0) {
> +		DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
> +		return -EINVAL;
> +	}

I don't really see why we should check these. The clipped coordinates
are what matters.

> +
> +	/* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> +	if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
> +	    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
> +		DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
> +			      crtc_x2, crtc_y2,
> +			      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> +		return -EINVAL;
> +	}

Why should we care? The current code already plays it fast and loose
and allows the dst rectangle to shrink to accomodate the hw limits.
If we want to change that we should change it universally.

> +
> +	plane_state->base.src.x1 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
> +	plane_state->base.src.x2 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
> +	plane_state->base.src.y1 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
> +	plane_state->base.src.y2 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;

Since this can now increase the size of the source rectangle our
scaling factor checks are no longer 100% valid. We might end up with
a scaling factor that is too high.

I don't really like any of these "let's make NV12 behave special"
tricks. We should make the code behave the same way for all pixel
formats instead of adding format specific hacks.

> +
> +	return 0;
> +}
> +
>  static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
>  {
>  	const struct drm_framebuffer *fb = plane_state->base.fb;
> @@ -3201,6 +3237,9 @@ int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
>  	 * the main surface setup depends on it.
>  	 */
>  	if (fb->format->format == DRM_FORMAT_NV12) {
> +		ret = skl_check_nv12_surface(crtc_state, plane_state);
> +		if (ret)
> +			return ret;
>  		ret = skl_check_nv12_aux_surface(plane_state);
>  		if (ret)
>  			return ret;
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> index 8b7947d..f9985fb 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane *plane,
>  			return vscale;
>  		}
>  
> -		/* Make the source viewport size an exact multiple of the scaling factors. */
> -		drm_rect_adjust_size(src,
> -				     drm_rect_width(dst) * hscale - drm_rect_width(src),
> -				     drm_rect_height(dst) * vscale - drm_rect_height(src));
> +		if (fb->format->format != DRM_FORMAT_NV12) {
> +			/*
> +			 * Make the source viewport size
> +			 * an exact multiple of the scaling factors
> +			 */
> +			drm_rect_adjust_size(src,
> +					     (drm_rect_width(dst) * hscale -
> +					      drm_rect_width(src)),
> +					     (drm_rect_height(dst) * vscale -
> +					      drm_rect_height(src)));
> +		}
>  
>  		drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
>  				    state->base.rotation);
> -- 
> 2.7.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Maarten Lankhorst]

Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
>> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>
>> We skip src trunction/adjustments for
>> NV12 case and handle the sizes directly.
>> Without this, pipe fifo underruns are seen on APL/KBL.
>>
>> v2: For NV12, making the src coordinates multiplier of 4
>>
>> v3: Moving all the src coords handling code for NV12
>> to skl_check_nv12_surface
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 39 ++++++++++++++++++++++++++++++++++++
>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
>>  2 files changed, 50 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index 925402e..b8dbaca 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
>>  	return 0;
>>  }
>>  
>> +static int
>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>> +		       struct intel_plane_state *plane_state)
>> +{
>> +	int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
>> +	int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
>> +
>> +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>> +	    ((plane_state->base.src_y >> 16) % 4) != 0 ||
>> +	    ((plane_state->base.src_w >> 16) % 4) != 0 ||
>> +	    ((plane_state->base.src_h >> 16) % 4) != 0) {
>> +		DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
>> +		return -EINVAL;
>> +	}
> I don't really see why we should check these. The clipped coordinates
> are what matters.

To propagate our limits to the userspace. I think we should do it for all formats,
but NV12 is the first YUV format we have tests for. If we could we should do
something similar for the other YUV formats, but they have different requirements.

In case of NV12 we don't have existing userspace, there will be nothing that
breaks if we enforce limits from the start.

>> +
>> +	/* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
>> +	if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
>> +	    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
>> +		DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
>> +			      crtc_x2, crtc_y2,
>> +			      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
>> +		return -EINVAL;
>> +	}
> Why should we care? The current code already plays it fast and loose
> and allows the dst rectangle to shrink to accomodate the hw limits.
> If we want to change that we should change it universally.

Unfortunately for the other formats we already have an existing userspace
(X.org) that doesn't perform any validation. We can't change it for that,
but we can prevent future mistakes.

>> +
>> +	plane_state->base.src.x1 =
>> +		DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
>> +	plane_state->base.src.x2 =
>> +		DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
>> +	plane_state->base.src.y1 =
>> +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
>> +	plane_state->base.src.y2 =
>> +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
> Since this can now increase the size of the source rectangle our
> scaling factor checks are no longer 100% valid. We might end up with
> a scaling factor that is too high.
>
> I don't really like any of these "let's make NV12 behave special"
> tricks. We should make the code behave the same way for all pixel
> formats instead of adding format specific hacks.

This is not nivalid because we restrict the original src coordinates to be
a multiple of 4, you can only clip to something smaller, not to something
bigger. :)

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Ville Syrjälä]

On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
> >> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>
> >> We skip src trunction/adjustments for
> >> NV12 case and handle the sizes directly.
> >> Without this, pipe fifo underruns are seen on APL/KBL.
> >>
> >> v2: For NV12, making the src coordinates multiplier of 4
> >>
> >> v3: Moving all the src coords handling code for NV12
> >> to skl_check_nv12_surface
> >>
> >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/intel_display.c | 39 ++++++++++++++++++++++++++++++++++++
> >>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
> >>  2 files changed, 50 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >> index 925402e..b8dbaca 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
> >>  	return 0;
> >>  }
> >>  
> >> +static int
> >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> >> +		       struct intel_plane_state *plane_state)
> >> +{
> >> +	int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> >> +	int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
> >> +
> >> +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> >> +	    ((plane_state->base.src_y >> 16) % 4) != 0 ||
> >> +	    ((plane_state->base.src_w >> 16) % 4) != 0 ||
> >> +	    ((plane_state->base.src_h >> 16) % 4) != 0) {
> >> +		DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
> >> +		return -EINVAL;
> >> +	}
> > I don't really see why we should check these. The clipped coordinates
> > are what matters.
> 
> To propagate our limits to the userspace. I think we should do it for all formats,
> but NV12 is the first YUV format we have tests for. If we could we should do
> something similar for the other YUV formats, but they have different requirements.
> 
> In case of NV12 we don't have existing userspace, there will be nothing that
> breaks if we enforce limits from the start.

But what about sub-pixel coordinates? You're totally ignoring them here.
We need to come up with some proper rules for this stuff.

> 
> >> +
> >> +	/* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> >> +	if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
> >> +	    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
> >> +		DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
> >> +			      crtc_x2, crtc_y2,
> >> +			      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> >> +		return -EINVAL;
> >> +	}
> > Why should we care? The current code already plays it fast and loose
> > and allows the dst rectangle to shrink to accomodate the hw limits.
> > If we want to change that we should change it universally.
> 
> Unfortunately for the other formats we already have an existing userspace
> (X.org) that doesn't perform any validation. We can't change it for that,
> but we can prevent future mistakes.

We should do it uniformly. Not per-format. That will make the code
unmaintainable real quick.

> 
> >> +
> >> +	plane_state->base.src.x1 =
> >> +		DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
> >> +	plane_state->base.src.x2 =
> >> +		DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
> >> +	plane_state->base.src.y1 =
> >> +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
> >> +	plane_state->base.src.y2 =
> >> +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
> > Since this can now increase the size of the source rectangle our
> > scaling factor checks are no longer 100% valid. We might end up with
> > a scaling factor that is too high.
> >
> > I don't really like any of these "let's make NV12 behave special"
> > tricks. We should make the code behave the same way for all pixel
> > formats instead of adding format specific hacks.
> 
> This is not nivalid because we restrict the original src coordinates to be
> a multiple of 4, you can only clip to something smaller, not to something
> bigger. :)

The clipped coordinates can be whatever thanks to scaling/etc.

Also why are we trying to make everything a multiple of four? I don't
remember any hw restrictions like that.

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Srinivas, Vidya]

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





> -----Original Message-----

> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]

> Sent: Thursday, April 19, 2018 12:06 AM

> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

> Cc: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-

> gfx@lists.freedesktop.org

> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add

> skl_check_nv12_surface for NV12

>

> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:

> > Op 18-04-18 om 17:32 schreef Ville Syrjälä:

> > > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:

> > >> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>

> > >>

> > >> We skip src trunction/adjustments for

> > >> NV12 case and handle the sizes directly.

> > >> Without this, pipe fifo underruns are seen on APL/KBL.

> > >>

> > >> v2: For NV12, making the src coordinates multiplier of 4

> > >>

> > >> v3: Moving all the src coords handling code for NV12 to

> > >> skl_check_nv12_surface

> > >>

> > >> Signed-off-by: Maarten Lankhorst

> > >> <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>

> > >> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com<mailto:vidya.srinivas@intel.com>>

> > >> ---

> > >>  drivers/gpu/drm/i915/intel_display.c | 39

> > >> ++++++++++++++++++++++++++++++++++++

> > >>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----

> > >>  2 files changed, 50 insertions(+), 4 deletions(-)

> > >>

> > >> diff --git a/drivers/gpu/drm/i915/intel_display.c

> > >> b/drivers/gpu/drm/i915/intel_display.c

> > >> index 925402e..b8dbaca 100644

> > >> --- a/drivers/gpu/drm/i915/intel_display.c

> > >> +++ b/drivers/gpu/drm/i915/intel_display.c

> > >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const

> struct intel_crtc_state *crtc_state,

> > >>  return 0;

> > >>  }

> > >>

> > >> +static int

> > >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,

> > >> +                                       struct intel_plane_state *plane_state) {

> > >> +                int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;

> > >> +                int crtc_y2 = plane_state->base.crtc_y +

> > >> +plane_state->base.crtc_h;

> > >> +

> > >> +                if (((plane_state->base.src_x >> 16) % 4) != 0 ||

> > >> +                    ((plane_state->base.src_y >> 16) % 4) != 0 ||

> > >> +                    ((plane_state->base.src_w >> 16) % 4) != 0 ||

> > >> +                    ((plane_state->base.src_h >> 16) % 4) != 0) {

> > >> +                                DRM_DEBUG_KMS("src coords must be multiple of 4 for

> NV12\n");

> > >> +                                return -EINVAL;

> > >> +                }

> > > I don't really see why we should check these. The clipped

> > > coordinates are what matters.

> >

> > To propagate our limits to the userspace. I think we should do it for

> > all formats, but NV12 is the first YUV format we have tests for. If we

> > could we should do something similar for the other YUV formats, but they

> have different requirements.

> >

> > In case of NV12 we don't have existing userspace, there will be

> > nothing that breaks if we enforce limits from the start.

>

> But what about sub-pixel coordinates? You're totally ignoring them here.

> We need to come up with some proper rules for this stuff.

>

> >

> > >> +

> > >> +                /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */

> > >> +                if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %

> 4) ||

> > >> +                    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4))

> {

> > >> +                                DRM_DEBUG_KMS("It's not possible to clip %u,%u to

> %u,%u\n",

> > >> +                                                      crtc_x2, crtc_y2,

> > >> +                                                      crtc_state->pipe_src_w, crtc_state->pipe_src_h);

> > >> +                                return -EINVAL;

> > >> +                }

> > > Why should we care? The current code already plays it fast and loose

> > > and allows the dst rectangle to shrink to accomodate the hw limits.

> > > If we want to change that we should change it universally.

> >

> > Unfortunately for the other formats we already have an existing

> > userspace

> > (X.org) that doesn't perform any validation. We can't change it for

> > that, but we can prevent future mistakes.

>

> We should do it uniformly. Not per-format. That will make the code

> unmaintainable real quick.

>

> >

> > >> +

> > >> +                plane_state->base.src.x1 =

> > >> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) <<

> 18;

> > >> +                plane_state->base.src.x2 =

> > >> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) <<

> 18;

> > >> +                plane_state->base.src.y1 =

> > >> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) <<

> 18;

> > >> +                plane_state->base.src.y2 =

> > >> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) <<

> 18;

> > > Since this can now increase the size of the source rectangle our

> > > scaling factor checks are no longer 100% valid. We might end up with

> > > a scaling factor that is too high.

> > >

> > > I don't really like any of these "let's make NV12 behave special"

> > > tricks. We should make the code behave the same way for all pixel

> > > formats instead of adding format specific hacks.

> >

> > This is not nivalid because we restrict the original src coordinates

> > to be a multiple of 4, you can only clip to something smaller, not to

> > something bigger. :)

>

> The clipped coordinates can be whatever thanks to scaling/etc.

>

> Also why are we trying to make everything a multiple of four? I don't

> remember any hw restrictions like that.



Hi


As per WA1106, Display corruption/color shift observed when using NV12 with 270 rotation or 90 rotation + horizontal flip.

WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires the programmed plane height to be a multiple of 4.



As per experiments on APL and KBL, when we don't keep them multiple of 4, we see fifo underruns.



Regards

Vidya



>

> --

> Ville Syrjälä

> Intel

[-- Attachment #1.2: Type: text/html, Size: 18455 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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Ville Syrjälä]

On Thu, Apr 19, 2018 at 02:36:42AM +0000, Srinivas, Vidya wrote:
> 
> 
> 
> 
> > -----Original Message-----
> 
> > From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> 
> > Sent: Thursday, April 19, 2018 12:06 AM
> 
> > To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> 
> > Cc: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-
> 
> > gfx@lists.freedesktop.org
> 
> > Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
> 
> > skl_check_nv12_surface for NV12
> 
> >
> 
> > On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
> 
> > > Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> 
> > > > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
> 
> > > >> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>
> 
> > > >>
> 
> > > >> We skip src trunction/adjustments for
> 
> > > >> NV12 case and handle the sizes directly.
> 
> > > >> Without this, pipe fifo underruns are seen on APL/KBL.
> 
> > > >>
> 
> > > >> v2: For NV12, making the src coordinates multiplier of 4
> 
> > > >>
> 
> > > >> v3: Moving all the src coords handling code for NV12 to
> 
> > > >> skl_check_nv12_surface
> 
> > > >>
> 
> > > >> Signed-off-by: Maarten Lankhorst
> 
> > > >> <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>
> 
> > > >> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com<mailto:vidya.srinivas@intel.com>>
> 
> > > >> ---
> 
> > > >>  drivers/gpu/drm/i915/intel_display.c | 39
> 
> > > >> ++++++++++++++++++++++++++++++++++++
> 
> > > >>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
> 
> > > >>  2 files changed, 50 insertions(+), 4 deletions(-)
> 
> > > >>
> 
> > > >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> 
> > > >> b/drivers/gpu/drm/i915/intel_display.c
> 
> > > >> index 925402e..b8dbaca 100644
> 
> > > >> --- a/drivers/gpu/drm/i915/intel_display.c
> 
> > > >> +++ b/drivers/gpu/drm/i915/intel_display.c
> 
> > > >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const
> 
> > struct intel_crtc_state *crtc_state,
> 
> > > >>  return 0;
> 
> > > >>  }
> 
> > > >>
> 
> > > >> +static int
> 
> > > >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> 
> > > >> +                                       struct intel_plane_state *plane_state) {
> 
> > > >> +                int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> 
> > > >> +                int crtc_y2 = plane_state->base.crtc_y +
> 
> > > >> +plane_state->base.crtc_h;
> 
> > > >> +
> 
> > > >> +                if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> 
> > > >> +                    ((plane_state->base.src_y >> 16) % 4) != 0 ||
> 
> > > >> +                    ((plane_state->base.src_w >> 16) % 4) != 0 ||
> 
> > > >> +                    ((plane_state->base.src_h >> 16) % 4) != 0) {
> 
> > > >> +                                DRM_DEBUG_KMS("src coords must be multiple of 4 for
> 
> > NV12\n");
> 
> > > >> +                                return -EINVAL;
> 
> > > >> +                }
> 
> > > > I don't really see why we should check these. The clipped
> 
> > > > coordinates are what matters.
> 
> > >
> 
> > > To propagate our limits to the userspace. I think we should do it for
> 
> > > all formats, but NV12 is the first YUV format we have tests for. If we
> 
> > > could we should do something similar for the other YUV formats, but they
> 
> > have different requirements.
> 
> > >
> 
> > > In case of NV12 we don't have existing userspace, there will be
> 
> > > nothing that breaks if we enforce limits from the start.
> 
> >
> 
> > But what about sub-pixel coordinates? You're totally ignoring them here.
> 
> > We need to come up with some proper rules for this stuff.
> 
> >
> 
> > >
> 
> > > >> +
> 
> > > >> +                /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> 
> > > >> +                if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %
> 
> > 4) ||
> 
> > > >> +                    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4))
> 
> > {
> 
> > > >> +                                DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> 
> > %u,%u\n",
> 
> > > >> +                                                      crtc_x2, crtc_y2,
> 
> > > >> +                                                      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> 
> > > >> +                                return -EINVAL;
> 
> > > >> +                }
> 
> > > > Why should we care? The current code already plays it fast and loose
> 
> > > > and allows the dst rectangle to shrink to accomodate the hw limits.
> 
> > > > If we want to change that we should change it universally.
> 
> > >
> 
> > > Unfortunately for the other formats we already have an existing
> 
> > > userspace
> 
> > > (X.org) that doesn't perform any validation. We can't change it for
> 
> > > that, but we can prevent future mistakes.
> 
> >
> 
> > We should do it uniformly. Not per-format. That will make the code
> 
> > unmaintainable real quick.
> 
> >
> 
> > >
> 
> > > >> +
> 
> > > >> +                plane_state->base.src.x1 =
> 
> > > >> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) <<
> 
> > 18;
> 
> > > >> +                plane_state->base.src.x2 =
> 
> > > >> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) <<
> 
> > 18;
> 
> > > >> +                plane_state->base.src.y1 =
> 
> > > >> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) <<
> 
> > 18;
> 
> > > >> +                plane_state->base.src.y2 =
> 
> > > >> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) <<
> 
> > 18;
> 
> > > > Since this can now increase the size of the source rectangle our
> 
> > > > scaling factor checks are no longer 100% valid. We might end up with
> 
> > > > a scaling factor that is too high.
> 
> > > >
> 
> > > > I don't really like any of these "let's make NV12 behave special"
> 
> > > > tricks. We should make the code behave the same way for all pixel
> 
> > > > formats instead of adding format specific hacks.
> 
> > >
> 
> > > This is not nivalid because we restrict the original src coordinates
> 
> > > to be a multiple of 4, you can only clip to something smaller, not to
> 
> > > something bigger. :)
> 
> >
> 
> > The clipped coordinates can be whatever thanks to scaling/etc.
> 
> >
> 
> > Also why are we trying to make everything a multiple of four? I don't
> 
> > remember any hw restrictions like that.
> 
> 
> 
> Hi
> 
> 
> As per WA1106, Display corruption/color shift observed when using NV12 with 270 rotation or 90 rotation + horizontal flip.
> 
> WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires the programmed plane height to be a multiple of 4.

Does plane height here mean src height or dst height?

Either way I don't see why we aren't just checking for the right thing
instead of trying to mandate a four pixel alignment everywhere.

> 
> 
> 
> As per experiments on APL and KBL, when we don't keep them multiple of 4, we see fifo underruns.
> 
> 
> 
> Regards
> 
> Vidya
> 
> 
> 
> >
> 
> > --
> 
> > Ville Syrjälä
> 
> > Intel

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Maarten Lankhorst]

Op 19-04-18 om 13:22 schreef Ville Syrjälä:
> On Thu, Apr 19, 2018 at 02:36:42AM +0000, Srinivas, Vidya wrote:
>>
>>
>>
>>> -----Original Message-----
>>> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
>>> Sent: Thursday, April 19, 2018 12:06 AM
>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Cc: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-
>>> gfx@lists.freedesktop.org
>>> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
>>> skl_check_nv12_surface for NV12
>>> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
>>>> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
>>>>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
>>>>>> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>
>>>>>> We skip src trunction/adjustments for
>>>>>> NV12 case and handle the sizes directly.
>>>>>> Without this, pipe fifo underruns are seen on APL/KBL.
>>>>>> v2: For NV12, making the src coordinates multiplier of 4
>>>>>> v3: Moving all the src coords handling code for NV12 to
>>>>>> skl_check_nv12_surface
>>>>>> Signed-off-by: Maarten Lankhorst
>>>>>> <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>
>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com<mailto:vidya.srinivas@intel.com>>
>>>>>> ---
>>>>>>  drivers/gpu/drm/i915/intel_display.c | 39
>>>>>> ++++++++++++++++++++++++++++++++++++
>>>>>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
>>>>>>  2 files changed, 50 insertions(+), 4 deletions(-)
>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>>>> index 925402e..b8dbaca 100644
>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>>>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const
>>> struct intel_crtc_state *crtc_state,
>>>>>>  return 0;
>>>>>>  }
>>>>>> +static int
>>>>>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>>>>>> +                                       struct intel_plane_state *plane_state) {
>>>>>> +                int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
>>>>>> +                int crtc_y2 = plane_state->base.crtc_y +
>>>>>> +plane_state->base.crtc_h;
>>>>>> +
>>>>>> +                if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>>>>>> +                    ((plane_state->base.src_y >> 16) % 4) != 0 ||
>>>>>> +                    ((plane_state->base.src_w >> 16) % 4) != 0 ||
>>>>>> +                    ((plane_state->base.src_h >> 16) % 4) != 0) {
>>>>>> +                                DRM_DEBUG_KMS("src coords must be multiple of 4 for
>>> NV12\n");
>>>>>> +                                return -EINVAL;
>>>>>> +                }
>>>>> I don't really see why we should check these. The clipped
>>>>> coordinates are what matters.
>>>> To propagate our limits to the userspace. I think we should do it for
>>>> all formats, but NV12 is the first YUV format we have tests for. If we
>>>> could we should do something similar for the other YUV formats, but they
>>> have different requirements.
>>>> In case of NV12 we don't have existing userspace, there will be
>>>> nothing that breaks if we enforce limits from the start.
>>> But what about sub-pixel coordinates? You're totally ignoring them here.
>>> We need to come up with some proper rules for this stuff.
>>>>>> +
>>>>>> +                /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
>>>>>> +                if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %
>>> 4) ||
>>>>>> +                    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4))
>>> {
>>>>>> +                                DRM_DEBUG_KMS("It's not possible to clip %u,%u to
>>> %u,%u\n",
>>>>>> +                                                      crtc_x2, crtc_y2,
>>>>>> +                                                      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
>>>>>> +                                return -EINVAL;
>>>>>> +                }
>>>>> Why should we care? The current code already plays it fast and loose
>>>>> and allows the dst rectangle to shrink to accomodate the hw limits.
>>>>> If we want to change that we should change it universally.
>>>> Unfortunately for the other formats we already have an existing
>>>> userspace
>>>> (X.org) that doesn't perform any validation. We can't change it for
>>>> that, but we can prevent future mistakes.
>>> We should do it uniformly. Not per-format. That will make the code
>>> unmaintainable real quick.
>>>>>> +
>>>>>> +                plane_state->base.src.x1 =
>>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) <<
>>> 18;
>>>>>> +                plane_state->base.src.x2 =
>>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) <<
>>> 18;
>>>>>> +                plane_state->base.src.y1 =
>>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) <<
>>> 18;
>>>>>> +                plane_state->base.src.y2 =
>>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) <<
>>> 18;
>>>>> Since this can now increase the size of the source rectangle our
>>>>> scaling factor checks are no longer 100% valid. We might end up with
>>>>> a scaling factor that is too high.
>>>>> I don't really like any of these "let's make NV12 behave special"
>>>>> tricks. We should make the code behave the same way for all pixel
>>>>> formats instead of adding format specific hacks.
>>>> This is not nivalid because we restrict the original src coordinates
>>>> to be a multiple of 4, you can only clip to something smaller, not to
>>>> something bigger. :)
>>> The clipped coordinates can be whatever thanks to scaling/etc.
>>> Also why are we trying to make everything a multiple of four? I don't
>>> remember any hw restrictions like that.
>>
>>
>> Hi
>>
>>
>> As per WA1106, Display corruption/color shift observed when using NV12 with 270 rotation or 90 rotation + horizontal flip.
>>
>> WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires the programmed plane height to be a multiple of 4.
> Does plane height here mean src height or dst height?
>
> Either way I don't see why we aren't just checking for the right thing
> instead of trying to mandate a four pixel alignment everywhere.
>
Agreed, what about the below diff, would this be acceptable to you? I deliberately ignore the last 16 bits as that is what we currently do anyway for all formats.

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 4b3735720fee..3ff7b5491446 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3090,6 +3090,31 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
 	return 0;
 }
 
+static int
+skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
+		       struct intel_plane_state *plane_state)
+{
+	/* Display WA #1106 */
+	if (plane_state->base.rotation != (DRM_MODE_REFLECT_X | DRM_MODE_ROTATE_90) &&
+	    plane_state->base.rotation != DRM_MODE_ROTATE_270)
+		return 0;
+
+	/* Because x/y are src coordinates will be rotated, we look at x/width here. */
+	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
+	    ((plane_state->base.src_w >> 16) % 4) != 0) {
+		DRM_DEBUG_KMS("src x/w must be multiple of 4 for rotated NV12\n");
+		return -EINVAL;
+	}
+
+	/* And round y here */
+	plane_state->base.src.y1 =
+		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
+	plane_state->base.src.y2 =
+		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
+
+	return 0;
+}
+
 static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
 {
 	const struct drm_framebuffer *fb = plane_state->base.fb;
@@ -3173,6 +3198,9 @@ int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
 	 * the main surface setup depends on it.
 	 */
 	if (fb->format->format == DRM_FORMAT_NV12) {
+		ret = skl_check_nv12_surface(crtc_state, plane_state);
+		if (ret)
+			return ret;
 		ret = skl_check_nv12_aux_surface(plane_state);
 		if (ret)
 			return ret;

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Ville Syrjälä]

On Thu, Apr 19, 2018 at 01:30:32PM +0200, Maarten Lankhorst wrote:
> Op 19-04-18 om 13:22 schreef Ville Syrjälä:
> > On Thu, Apr 19, 2018 at 02:36:42AM +0000, Srinivas, Vidya wrote:
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> >>> Sent: Thursday, April 19, 2018 12:06 AM
> >>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>> Cc: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-
> >>> gfx@lists.freedesktop.org
> >>> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
> >>> skl_check_nv12_surface for NV12
> >>> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
> >>>> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> >>>>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
> >>>>>> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>
> >>>>>> We skip src trunction/adjustments for
> >>>>>> NV12 case and handle the sizes directly.
> >>>>>> Without this, pipe fifo underruns are seen on APL/KBL.
> >>>>>> v2: For NV12, making the src coordinates multiplier of 4
> >>>>>> v3: Moving all the src coords handling code for NV12 to
> >>>>>> skl_check_nv12_surface
> >>>>>> Signed-off-by: Maarten Lankhorst
> >>>>>> <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>
> >>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com<mailto:vidya.srinivas@intel.com>>
> >>>>>> ---
> >>>>>>  drivers/gpu/drm/i915/intel_display.c | 39
> >>>>>> ++++++++++++++++++++++++++++++++++++
> >>>>>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
> >>>>>>  2 files changed, 50 insertions(+), 4 deletions(-)
> >>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>>>>> b/drivers/gpu/drm/i915/intel_display.c
> >>>>>> index 925402e..b8dbaca 100644
> >>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>>>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const
> >>> struct intel_crtc_state *crtc_state,
> >>>>>>  return 0;
> >>>>>>  }
> >>>>>> +static int
> >>>>>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> >>>>>> +                                       struct intel_plane_state *plane_state) {
> >>>>>> +                int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> >>>>>> +                int crtc_y2 = plane_state->base.crtc_y +
> >>>>>> +plane_state->base.crtc_h;
> >>>>>> +
> >>>>>> +                if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> >>>>>> +                    ((plane_state->base.src_y >> 16) % 4) != 0 ||
> >>>>>> +                    ((plane_state->base.src_w >> 16) % 4) != 0 ||
> >>>>>> +                    ((plane_state->base.src_h >> 16) % 4) != 0) {
> >>>>>> +                                DRM_DEBUG_KMS("src coords must be multiple of 4 for
> >>> NV12\n");
> >>>>>> +                                return -EINVAL;
> >>>>>> +                }
> >>>>> I don't really see why we should check these. The clipped
> >>>>> coordinates are what matters.
> >>>> To propagate our limits to the userspace. I think we should do it for
> >>>> all formats, but NV12 is the first YUV format we have tests for. If we
> >>>> could we should do something similar for the other YUV formats, but they
> >>> have different requirements.
> >>>> In case of NV12 we don't have existing userspace, there will be
> >>>> nothing that breaks if we enforce limits from the start.
> >>> But what about sub-pixel coordinates? You're totally ignoring them here.
> >>> We need to come up with some proper rules for this stuff.
> >>>>>> +
> >>>>>> +                /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> >>>>>> +                if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %
> >>> 4) ||
> >>>>>> +                    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4))
> >>> {
> >>>>>> +                                DRM_DEBUG_KMS("It's not possible to clip %u,%u to
> >>> %u,%u\n",
> >>>>>> +                                                      crtc_x2, crtc_y2,
> >>>>>> +                                                      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> >>>>>> +                                return -EINVAL;
> >>>>>> +                }
> >>>>> Why should we care? The current code already plays it fast and loose
> >>>>> and allows the dst rectangle to shrink to accomodate the hw limits.
> >>>>> If we want to change that we should change it universally.
> >>>> Unfortunately for the other formats we already have an existing
> >>>> userspace
> >>>> (X.org) that doesn't perform any validation. We can't change it for
> >>>> that, but we can prevent future mistakes.
> >>> We should do it uniformly. Not per-format. That will make the code
> >>> unmaintainable real quick.
> >>>>>> +
> >>>>>> +                plane_state->base.src.x1 =
> >>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) <<
> >>> 18;
> >>>>>> +                plane_state->base.src.x2 =
> >>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) <<
> >>> 18;
> >>>>>> +                plane_state->base.src.y1 =
> >>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) <<
> >>> 18;
> >>>>>> +                plane_state->base.src.y2 =
> >>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) <<
> >>> 18;
> >>>>> Since this can now increase the size of the source rectangle our
> >>>>> scaling factor checks are no longer 100% valid. We might end up with
> >>>>> a scaling factor that is too high.
> >>>>> I don't really like any of these "let's make NV12 behave special"
> >>>>> tricks. We should make the code behave the same way for all pixel
> >>>>> formats instead of adding format specific hacks.
> >>>> This is not nivalid because we restrict the original src coordinates
> >>>> to be a multiple of 4, you can only clip to something smaller, not to
> >>>> something bigger. :)
> >>> The clipped coordinates can be whatever thanks to scaling/etc.
> >>> Also why are we trying to make everything a multiple of four? I don't
> >>> remember any hw restrictions like that.
> >>
> >>
> >> Hi
> >>
> >>
> >> As per WA1106, Display corruption/color shift observed when using NV12 with 270 rotation or 90 rotation + horizontal flip.
> >>
> >> WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires the programmed plane height to be a multiple of 4.
> > Does plane height here mean src height or dst height?
> >
> > Either way I don't see why we aren't just checking for the right thing
> > instead of trying to mandate a four pixel alignment everywhere.
> >
> Agreed, what about the below diff, would this be acceptable to you? I deliberately ignore the last 16 bits as that is what we currently do anyway for all formats.
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 4b3735720fee..3ff7b5491446 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3090,6 +3090,31 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
>  	return 0;
>  }
>  
> +static int
> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> +		       struct intel_plane_state *plane_state)
> +{
> +	/* Display WA #1106 */
> +	if (plane_state->base.rotation != (DRM_MODE_REFLECT_X | DRM_MODE_ROTATE_90) &&
> +	    plane_state->base.rotation != DRM_MODE_ROTATE_270)
> +		return 0;

Hmm. I wonder if that's what the spec actually means. The HSDs only
talk about 270 degree rotation. So I guess this interpretation could
be correct.

> +
> +	/* Because x/y are src coordinates will be rotated, we look at x/width here. */
> +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> +	    ((plane_state->base.src_w >> 16) % 4) != 0) {
> +		DRM_DEBUG_KMS("src x/w must be multiple of 4 for rotated NV12\n");
> +		return -EINVAL;
> +	}
> +
> +	/* And round y here */
> +	plane_state->base.src.y1 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
> +	plane_state->base.src.y2 =
> +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;

Why not just a simple

if (drm_rect_height(src) >> 16 % 4 != 0)
	return -EINVAL;

?

> +
> +	return 0;
> +}
> +
>  static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
>  {
>  	const struct drm_framebuffer *fb = plane_state->base.fb;
> @@ -3173,6 +3198,9 @@ int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
>  	 * the main surface setup depends on it.
>  	 */
>  	if (fb->format->format == DRM_FORMAT_NV12) {
> +		ret = skl_check_nv12_surface(crtc_state, plane_state);
> +		if (ret)
> +			return ret;
>  		ret = skl_check_nv12_aux_surface(plane_state);
>  		if (ret)
>  			return ret;

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Maarten Lankhorst]

Op 19-04-18 om 13:50 schreef Ville Syrjälä:
> On Thu, Apr 19, 2018 at 01:30:32PM +0200, Maarten Lankhorst wrote:
>> Op 19-04-18 om 13:22 schreef Ville Syrjälä:
>>> On Thu, Apr 19, 2018 at 02:36:42AM +0000, Srinivas, Vidya wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
>>>>> Sent: Thursday, April 19, 2018 12:06 AM
>>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>> Cc: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-
>>>>> gfx@lists.freedesktop.org
>>>>> Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add
>>>>> skl_check_nv12_surface for NV12
>>>>> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
>>>>>> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
>>>>>>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
>>>>>>>> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>
>>>>>>>> We skip src trunction/adjustments for
>>>>>>>> NV12 case and handle the sizes directly.
>>>>>>>> Without this, pipe fifo underruns are seen on APL/KBL.
>>>>>>>> v2: For NV12, making the src coordinates multiplier of 4
>>>>>>>> v3: Moving all the src coords handling code for NV12 to
>>>>>>>> skl_check_nv12_surface
>>>>>>>> Signed-off-by: Maarten Lankhorst
>>>>>>>> <maarten.lankhorst@linux.intel.com<mailto:maarten.lankhorst@linux.intel.com>>
>>>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com<mailto:vidya.srinivas@intel.com>>
>>>>>>>> ---
>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 39
>>>>>>>> ++++++++++++++++++++++++++++++++++++
>>>>>>>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
>>>>>>>>  2 files changed, 50 insertions(+), 4 deletions(-)
>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>>>>>> index 925402e..b8dbaca 100644
>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>>>>>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const
>>>>> struct intel_crtc_state *crtc_state,
>>>>>>>>  return 0;
>>>>>>>>  }
>>>>>>>> +static int
>>>>>>>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>>>>>>>> +                                       struct intel_plane_state *plane_state) {
>>>>>>>> +                int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
>>>>>>>> +                int crtc_y2 = plane_state->base.crtc_y +
>>>>>>>> +plane_state->base.crtc_h;
>>>>>>>> +
>>>>>>>> +                if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>>>>>>>> +                    ((plane_state->base.src_y >> 16) % 4) != 0 ||
>>>>>>>> +                    ((plane_state->base.src_w >> 16) % 4) != 0 ||
>>>>>>>> +                    ((plane_state->base.src_h >> 16) % 4) != 0) {
>>>>>>>> +                                DRM_DEBUG_KMS("src coords must be multiple of 4 for
>>>>> NV12\n");
>>>>>>>> +                                return -EINVAL;
>>>>>>>> +                }
>>>>>>> I don't really see why we should check these. The clipped
>>>>>>> coordinates are what matters.
>>>>>> To propagate our limits to the userspace. I think we should do it for
>>>>>> all formats, but NV12 is the first YUV format we have tests for. If we
>>>>>> could we should do something similar for the other YUV formats, but they
>>>>> have different requirements.
>>>>>> In case of NV12 we don't have existing userspace, there will be
>>>>>> nothing that breaks if we enforce limits from the start.
>>>>> But what about sub-pixel coordinates? You're totally ignoring them here.
>>>>> We need to come up with some proper rules for this stuff.
>>>>>>>> +
>>>>>>>> +                /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
>>>>>>>> +                if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w %
>>>>> 4) ||
>>>>>>>> +                    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4))
>>>>> {
>>>>>>>> +                                DRM_DEBUG_KMS("It's not possible to clip %u,%u to
>>>>> %u,%u\n",
>>>>>>>> +                                                      crtc_x2, crtc_y2,
>>>>>>>> +                                                      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
>>>>>>>> +                                return -EINVAL;
>>>>>>>> +                }
>>>>>>> Why should we care? The current code already plays it fast and loose
>>>>>>> and allows the dst rectangle to shrink to accomodate the hw limits.
>>>>>>> If we want to change that we should change it universally.
>>>>>> Unfortunately for the other formats we already have an existing
>>>>>> userspace
>>>>>> (X.org) that doesn't perform any validation. We can't change it for
>>>>>> that, but we can prevent future mistakes.
>>>>> We should do it uniformly. Not per-format. That will make the code
>>>>> unmaintainable real quick.
>>>>>>>> +
>>>>>>>> +                plane_state->base.src.x1 =
>>>>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) <<
>>>>> 18;
>>>>>>>> +                plane_state->base.src.x2 =
>>>>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) <<
>>>>> 18;
>>>>>>>> +                plane_state->base.src.y1 =
>>>>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) <<
>>>>> 18;
>>>>>>>> +                plane_state->base.src.y2 =
>>>>>>>> +                                DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) <<
>>>>> 18;
>>>>>>> Since this can now increase the size of the source rectangle our
>>>>>>> scaling factor checks are no longer 100% valid. We might end up with
>>>>>>> a scaling factor that is too high.
>>>>>>> I don't really like any of these "let's make NV12 behave special"
>>>>>>> tricks. We should make the code behave the same way for all pixel
>>>>>>> formats instead of adding format specific hacks.
>>>>>> This is not nivalid because we restrict the original src coordinates
>>>>>> to be a multiple of 4, you can only clip to something smaller, not to
>>>>>> something bigger. :)
>>>>> The clipped coordinates can be whatever thanks to scaling/etc.
>>>>> Also why are we trying to make everything a multiple of four? I don't
>>>>> remember any hw restrictions like that.
>>>>
>>>> Hi
>>>>
>>>>
>>>> As per WA1106, Display corruption/color shift observed when using NV12 with 270 rotation or 90 rotation + horizontal flip.
>>>>
>>>> WA: NV12 with 270 rotation or 90 rotation + horizontal flip requires the programmed plane height to be a multiple of 4.
>>> Does plane height here mean src height or dst height?
>>>
>>> Either way I don't see why we aren't just checking for the right thing
>>> instead of trying to mandate a four pixel alignment everywhere.
>>>
>> Agreed, what about the below diff, would this be acceptable to you? I deliberately ignore the last 16 bits as that is what we currently do anyway for all formats.
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index 4b3735720fee..3ff7b5491446 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3090,6 +3090,31 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
>>  	return 0;
>>  }
>>  
>> +static int
>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>> +		       struct intel_plane_state *plane_state)
>> +{
>> +	/* Display WA #1106 */
>> +	if (plane_state->base.rotation != (DRM_MODE_REFLECT_X | DRM_MODE_ROTATE_90) &&
>> +	    plane_state->base.rotation != DRM_MODE_ROTATE_270)
>> +		return 0;
> Hmm. I wonder if that's what the spec actually means. The HSDs only
> talk about 270 degree rotation. So I guess this interpretation could
> be correct.
>
>> +
>> +	/* Because x/y are src coordinates will be rotated, we look at x/width here. */
>> +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>> +	    ((plane_state->base.src_w >> 16) % 4) != 0) {
>> +		DRM_DEBUG_KMS("src x/w must be multiple of 4 for rotated NV12\n");
>> +		return -EINVAL;
>> +	}
>> +
>> +	/* And round y here */
>> +	plane_state->base.src.y1 =
>> +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
>> +	plane_state->base.src.y2 =
>> +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
> Why not just a simple
>
> if (drm_rect_height(src) >> 16 % 4 != 0)
> 	return -EINVAL;
>
So lets do that, but we have to fix the rounding errors in i915 to make it useful:

upscaling 16x16 to 2560x1440:
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "SRC_W" to 0x100000/1048576
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "SRC_H" to 0x100000/1048576
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_X" to 0x0/0
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_Y" to 0x0/0
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_W" to 0xa00/2560
(kms_plane_scaling:1172) igt_kms-DEBUG: plane A.1: Setting property "CRTC_H" to 0x5a0/1440

[  290.766555] [drm:drm_ioctl [drm]] pid=1172, dev=0xe200, auth=1, DRM_IOCTL_MODE_ATOMIC
...
[  290.767276] [drm:skl_update_scaler [i915]] NV12: src dimensions not met: 15 < 16
[  290.767284] [drm:drm_atomic_helper_check_planes [drm_kms_helper]] [PLANE:33:plane 2A] atomic driver check failed
[  290.767422] [drm:drm_ioctl [drm]] pid=1172, ret = -22

If we want to go with that patch, I'll commit it but let the tests fail since rounding is not a NV12 specific error.

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Maarten Lankhorst]

Op 18-04-18 om 20:35 schreef Ville Syrjälä:
> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
>> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
>>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
>>>> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>
>>>> We skip src trunction/adjustments for
>>>> NV12 case and handle the sizes directly.
>>>> Without this, pipe fifo underruns are seen on APL/KBL.
>>>>
>>>> v2: For NV12, making the src coordinates multiplier of 4
>>>>
>>>> v3: Moving all the src coords handling code for NV12
>>>> to skl_check_nv12_surface
>>>>
>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
>>>> ---
>>>>  drivers/gpu/drm/i915/intel_display.c | 39 ++++++++++++++++++++++++++++++++++++
>>>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
>>>>  2 files changed, 50 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>>> index 925402e..b8dbaca 100644
>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
>>>>  	return 0;
>>>>  }
>>>>  
>>>> +static int
>>>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>>>> +		       struct intel_plane_state *plane_state)
>>>> +{
>>>> +	int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
>>>> +	int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
>>>> +
>>>> +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>>>> +	    ((plane_state->base.src_y >> 16) % 4) != 0 ||
>>>> +	    ((plane_state->base.src_w >> 16) % 4) != 0 ||
>>>> +	    ((plane_state->base.src_h >> 16) % 4) != 0) {
>>>> +		DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
>>>> +		return -EINVAL;
>>>> +	}
>>> I don't really see why we should check these. The clipped coordinates
>>> are what matters.
>> To propagate our limits to the userspace. I think we should do it for all formats,
>> but NV12 is the first YUV format we have tests for. If we could we should do
>> something similar for the other YUV formats, but they have different requirements.
>>
>> In case of NV12 we don't have existing userspace, there will be nothing that
>> breaks if we enforce limits from the start.
> But what about sub-pixel coordinates? You're totally ignoring them here.
> We need to come up with some proper rules for this stuff.

Would we break anything if we disallow sub-pixel coordinates for i915 globally? It's not like we supported them before,
but I'm not sure that change would break anything.

>>>> +
>>>> +	/* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
>>>> +	if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
>>>> +	    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
>>>> +		DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
>>>> +			      crtc_x2, crtc_y2,
>>>> +			      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
>>>> +		return -EINVAL;
>>>> +	}
>>> Why should we care? The current code already plays it fast and loose
>>> and allows the dst rectangle to shrink to accomodate the hw limits.
>>> If we want to change that we should change it universally.
>> Unfortunately for the other formats we already have an existing userspace
>> (X.org) that doesn't perform any validation. We can't change it for that,
>> but we can prevent future mistakes.
> We should do it uniformly. Not per-format. That will make the code
> unmaintainable real quick.
>>>> +
>>>> +	plane_state->base.src.x1 =
>>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
>>>> +	plane_state->base.src.x2 =
>>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
>>>> +	plane_state->base.src.y1 =
>>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
>>>> +	plane_state->base.src.y2 =
>>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
>>> Since this can now increase the size of the source rectangle our
>>> scaling factor checks are no longer 100% valid. We might end up with
>>> a scaling factor that is too high.
>>>
>>> I don't really like any of these "let's make NV12 behave special"
>>> tricks. We should make the code behave the same way for all pixel
>>> formats instead of adding format specific hacks.
>> This is not nivalid because we restrict the original src coordinates to be
>> a multiple of 4, you can only clip to something smaller, not to something
>> bigger. :)
> The clipped coordinates can be whatever thanks to scaling/etc.

Yes, but it will always be smaller than the original rectangle, so rounding to 4 when
the original set of coordinates were a multiple of 4 would never go outside the original
boundary.

> Also why are we trying to make everything a multiple of four? I don't
> remember any hw restrictions like that.

Well Vidya already replied, it sucks but it's what we have to live with for now. :(

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Ville Syrjälä]

On Thu, Apr 19, 2018 at 10:12:56AM +0200, Maarten Lankhorst wrote:
> Op 18-04-18 om 20:35 schreef Ville Syrjälä:
> > On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
> >> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
> >>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
> >>>> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>>
> >>>> We skip src trunction/adjustments for
> >>>> NV12 case and handle the sizes directly.
> >>>> Without this, pipe fifo underruns are seen on APL/KBL.
> >>>>
> >>>> v2: For NV12, making the src coordinates multiplier of 4
> >>>>
> >>>> v3: Moving all the src coords handling code for NV12
> >>>> to skl_check_nv12_surface
> >>>>
> >>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> >>>> ---
> >>>>  drivers/gpu/drm/i915/intel_display.c | 39 ++++++++++++++++++++++++++++++++++++
> >>>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
> >>>>  2 files changed, 50 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >>>> index 925402e..b8dbaca 100644
> >>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
> >>>>  	return 0;
> >>>>  }
> >>>>  
> >>>> +static int
> >>>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
> >>>> +		       struct intel_plane_state *plane_state)
> >>>> +{
> >>>> +	int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
> >>>> +	int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
> >>>> +
> >>>> +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
> >>>> +	    ((plane_state->base.src_y >> 16) % 4) != 0 ||
> >>>> +	    ((plane_state->base.src_w >> 16) % 4) != 0 ||
> >>>> +	    ((plane_state->base.src_h >> 16) % 4) != 0) {
> >>>> +		DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
> >>>> +		return -EINVAL;
> >>>> +	}
> >>> I don't really see why we should check these. The clipped coordinates
> >>> are what matters.
> >> To propagate our limits to the userspace. I think we should do it for all formats,
> >> but NV12 is the first YUV format we have tests for. If we could we should do
> >> something similar for the other YUV formats, but they have different requirements.
> >>
> >> In case of NV12 we don't have existing userspace, there will be nothing that
> >> breaks if we enforce limits from the start.
> > But what about sub-pixel coordinates? You're totally ignoring them here.
> > We need to come up with some proper rules for this stuff.
> 
> Would we break anything if we disallow sub-pixel coordinates for i915 globally? It's not like we supported them before,
> but I'm not sure that change would break anything.

Not really I suppose. IIRC the hw did reintroduce partial sub-pixel
coordinate support for NV12 specifically. I do wish they'd done it
fully for all formats.

> 
> >>>> +
> >>>> +	/* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
> >>>> +	if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
> >>>> +	    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
> >>>> +		DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
> >>>> +			      crtc_x2, crtc_y2,
> >>>> +			      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
> >>>> +		return -EINVAL;
> >>>> +	}
> >>> Why should we care? The current code already plays it fast and loose
> >>> and allows the dst rectangle to shrink to accomodate the hw limits.
> >>> If we want to change that we should change it universally.
> >> Unfortunately for the other formats we already have an existing userspace
> >> (X.org) that doesn't perform any validation. We can't change it for that,
> >> but we can prevent future mistakes.
> > We should do it uniformly. Not per-format. That will make the code
> > unmaintainable real quick.
> >>>> +
> >>>> +	plane_state->base.src.x1 =
> >>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
> >>>> +	plane_state->base.src.x2 =
> >>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
> >>>> +	plane_state->base.src.y1 =
> >>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
> >>>> +	plane_state->base.src.y2 =
> >>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
> >>> Since this can now increase the size of the source rectangle our
> >>> scaling factor checks are no longer 100% valid. We might end up with
> >>> a scaling factor that is too high.
> >>>
> >>> I don't really like any of these "let's make NV12 behave special"
> >>> tricks. We should make the code behave the same way for all pixel
> >>> formats instead of adding format specific hacks.
> >> This is not nivalid because we restrict the original src coordinates to be
> >> a multiple of 4, you can only clip to something smaller, not to something
> >> bigger. :)
> > The clipped coordinates can be whatever thanks to scaling/etc.
> 
> Yes, but it will always be smaller than the original rectangle, so rounding to 4 when
> the original set of coordinates were a multiple of 4 would never go outside the original
> boundary.

I was talking about the scaling factor increasing, and potentially
exceeding the hardware maximum.

> 
> > Also why are we trying to make everything a multiple of four? I don't
> > remember any hw restrictions like that.
> 
> Well Vidya already replied, it sucks but it's what we have to live with for now. :(

That was just about the plane height. Nothing seems to require making
everything a multiple of four.

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

Re: [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12

[Maarten Lankhorst]

Op 19-04-18 om 13:32 schreef Ville Syrjälä:
> On Thu, Apr 19, 2018 at 10:12:56AM +0200, Maarten Lankhorst wrote:
>> Op 18-04-18 om 20:35 schreef Ville Syrjälä:
>>> On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote:
>>>> Op 18-04-18 om 17:32 schreef Ville Syrjälä:
>>>>> On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote:
>>>>>> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>>
>>>>>> We skip src trunction/adjustments for
>>>>>> NV12 case and handle the sizes directly.
>>>>>> Without this, pipe fifo underruns are seen on APL/KBL.
>>>>>>
>>>>>> v2: For NV12, making the src coordinates multiplier of 4
>>>>>>
>>>>>> v3: Moving all the src coords handling code for NV12
>>>>>> to skl_check_nv12_surface
>>>>>>
>>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
>>>>>> ---
>>>>>>  drivers/gpu/drm/i915/intel_display.c | 39 ++++++++++++++++++++++++++++++++++++
>>>>>>  drivers/gpu/drm/i915/intel_sprite.c  | 15 ++++++++++----
>>>>>>  2 files changed, 50 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>>>>>> index 925402e..b8dbaca 100644
>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>>>> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
>>>>>>  	return 0;
>>>>>>  }
>>>>>>  
>>>>>> +static int
>>>>>> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
>>>>>> +		       struct intel_plane_state *plane_state)
>>>>>> +{
>>>>>> +	int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w;
>>>>>> +	int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h;
>>>>>> +
>>>>>> +	if (((plane_state->base.src_x >> 16) % 4) != 0 ||
>>>>>> +	    ((plane_state->base.src_y >> 16) % 4) != 0 ||
>>>>>> +	    ((plane_state->base.src_w >> 16) % 4) != 0 ||
>>>>>> +	    ((plane_state->base.src_h >> 16) % 4) != 0) {
>>>>>> +		DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n");
>>>>>> +		return -EINVAL;
>>>>>> +	}
>>>>> I don't really see why we should check these. The clipped coordinates
>>>>> are what matters.
>>>> To propagate our limits to the userspace. I think we should do it for all formats,
>>>> but NV12 is the first YUV format we have tests for. If we could we should do
>>>> something similar for the other YUV formats, but they have different requirements.
>>>>
>>>> In case of NV12 we don't have existing userspace, there will be nothing that
>>>> breaks if we enforce limits from the start.
>>> But what about sub-pixel coordinates? You're totally ignoring them here.
>>> We need to come up with some proper rules for this stuff.
>> Would we break anything if we disallow sub-pixel coordinates for i915 globally? It's not like we supported them before,
>> but I'm not sure that change would break anything.
> Not really I suppose. IIRC the hw did reintroduce partial sub-pixel
> coordinate support for NV12 specifically. I do wish they'd done it
> fully for all formats.
>
>>>>>> +
>>>>>> +	/* Clipping would cause a 1-3 pixel gap at the edge of the screen? */
>>>>>> +	if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) ||
>>>>>> +	    (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) {
>>>>>> +		DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n",
>>>>>> +			      crtc_x2, crtc_y2,
>>>>>> +			      crtc_state->pipe_src_w, crtc_state->pipe_src_h);
>>>>>> +		return -EINVAL;
>>>>>> +	}
>>>>> Why should we care? The current code already plays it fast and loose
>>>>> and allows the dst rectangle to shrink to accomodate the hw limits.
>>>>> If we want to change that we should change it universally.
>>>> Unfortunately for the other formats we already have an existing userspace
>>>> (X.org) that doesn't perform any validation. We can't change it for that,
>>>> but we can prevent future mistakes.
>>> We should do it uniformly. Not per-format. That will make the code
>>> unmaintainable real quick.
>>>>>> +
>>>>>> +	plane_state->base.src.x1 =
>>>>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
>>>>>> +	plane_state->base.src.x2 =
>>>>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18;
>>>>>> +	plane_state->base.src.y1 =
>>>>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
>>>>>> +	plane_state->base.src.y2 =
>>>>>> +		DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18;
>>>>> Since this can now increase the size of the source rectangle our
>>>>> scaling factor checks are no longer 100% valid. We might end up with
>>>>> a scaling factor that is too high.
>>>>>
>>>>> I don't really like any of these "let's make NV12 behave special"
>>>>> tricks. We should make the code behave the same way for all pixel
>>>>> formats instead of adding format specific hacks.
>>>> This is not nivalid because we restrict the original src coordinates to be
>>>> a multiple of 4, you can only clip to something smaller, not to something
>>>> bigger. :)
>>> The clipped coordinates can be whatever thanks to scaling/etc.
>> Yes, but it will always be smaller than the original rectangle, so rounding to 4 when
>> the original set of coordinates were a multiple of 4 would never go outside the original
>> boundary.
> I was talking about the scaling factor increasing, and potentially
> exceeding the hardware maximum.
>
>>> Also why are we trying to make everything a multiple of four? I don't
>>> remember any hw restrictions like that.
>> Well Vidya already replied, it sucks but it's what we have to live with for now. :(
> That was just about the plane height. Nothing seems to require making
> everything a multiple of four.
>
This was to get rid of FIFO underruns, but the new solution appears to be not enable it on BXT. I can live with that. :)

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

✗ Fi.CI.CHECKPATCH: warning for Enable NV12 support (rev2)

[Patchwork]

== Series Details ==

Series: Enable NV12 support (rev2)
URL   : https://patchwork.freedesktop.org/series/41674/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e7aa87c8fdf6 drm/i915: Enable display workaround 827 for all planes, v2.
-:58: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#58: FILE: drivers/gpu/drm/i915/intel_display.c:5148:
+	if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv)) ||
+	       IS_CANNONLAKE(dev_priv))

total: 0 errors, 0 warnings, 1 checks, 95 lines checked
75716cad6db9 drm/i915: Add NV12 as supported format for primary plane
c5d7ac7c4cc8 drm/i915: Add NV12 as supported format for sprite plane
a8ee79b84f5d drm/i915: Add NV12 support to intel_framebuffer_init
-:85: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED_CCS'
#85: FILE: drivers/gpu/drm/i915/intel_display.c:14265:
+		if ((mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED_CCS) ||
+		    (mode_cmd->modifier[0] == I915_FORMAT_MOD_Yf_TILED_CCS)) {

-:85: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'mode_cmd->modifier[0] == I915_FORMAT_MOD_Yf_TILED_CCS'
#85: FILE: drivers/gpu/drm/i915/intel_display.c:14265:
+		if ((mode_cmd->modifier[0] == I915_FORMAT_MOD_Y_TILED_CCS) ||
+		    (mode_cmd->modifier[0] == I915_FORMAT_MOD_Yf_TILED_CCS)) {

total: 0 errors, 0 warnings, 2 checks, 33 lines checked
7cd11441e10a drm/i915: Enable Display WA 0528
3276d4f570d8 drm/i915: Add skl_check_nv12_surface for NV12

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

✓ Fi.CI.BAT: success for Enable NV12 support (rev2)

[Patchwork]

== Series Details ==

Series: Enable NV12 support (rev2)
URL   : https://patchwork.freedesktop.org/series/41674/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4060 -> Patchwork_8717 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8717 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8717, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/41674/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8717:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_exec_gttfill@basic:
      fi-pnv-d510:        SKIP -> PASS

    
== Known issues ==

  Here are the changes found in Patchwork_8717 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@gvt_basic@invalid-placeholder-test:
      fi-glk-1:           NOTRUN -> INCOMPLETE (fdo#103359, k.org#198133)

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
      fi-ivb-3520m:       PASS -> DMESG-WARN (fdo#106084)

    
    ==== Possible fixes ====

    igt@kms_pipe_crc_basic@read-crc-pipe-b:
      fi-glk-j4005:       DMESG-WARN (fdo#106097) -> PASS

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
      fi-snb-2520m:       INCOMPLETE (fdo#103713) -> PASS
      fi-bxt-dsi:         INCOMPLETE (fdo#103927) -> PASS

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
      fi-ivb-3520m:       DMESG-WARN (fdo#106084) -> PASS +1

    
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (34 -> 33) ==

  Additional (1): fi-glk-1 
  Missing    (2): fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

    * Linux: CI_DRM_4060 -> Patchwork_8717

  CI_DRM_4060: 17148956c3830de3194c17693be76f85f05f692f @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8717: 3276d4f570d86e2ac858d4b6b8469a4b875729b1 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit


== Linux commits ==

3276d4f570d8 drm/i915: Add skl_check_nv12_surface for NV12
7cd11441e10a drm/i915: Enable Display WA 0528
a8ee79b84f5d drm/i915: Add NV12 support to intel_framebuffer_init
c5d7ac7c4cc8 drm/i915: Add NV12 as supported format for sprite plane
75716cad6db9 drm/i915: Add NV12 as supported format for primary plane
e7aa87c8fdf6 drm/i915: Enable display workaround 827 for all planes, v2.

== Logs ==

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

✓ Fi.CI.IGT: success for Enable NV12 support (rev2)

[Patchwork]

== Series Details ==

Series: Enable NV12 support (rev2)
URL   : https://patchwork.freedesktop.org/series/41674/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4060_full -> Patchwork_8717_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8717_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8717_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/41674/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8717_full:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_exec_schedule@deep-bsd1:
      shard-kbl:          SKIP -> PASS +1

    igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render:
      shard-kbl:          PASS -> SKIP +2

    
== Known issues ==

  Here are the changes found in Patchwork_8717_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@kms_sysfs_edid_timing:
      shard-apl:          PASS -> WARN (fdo#100047)

    
    ==== Possible fixes ====

    igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
      shard-hsw:          FAIL (fdo#104873) -> PASS

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


== Participating hosts (6 -> 4) ==

  Missing    (2): shard-glk shard-glkb 


== Build changes ==

    * Linux: CI_DRM_4060 -> Patchwork_8717

  CI_DRM_4060: 17148956c3830de3194c17693be76f85f05f692f @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8717: 3276d4f570d86e2ac858d4b6b8469a4b875729b1 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit

== Logs ==

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