[PATCH v2 0/6] Enable NV12 support

[PATCH v2 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

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 (1):
  drm/i915: Enable display workaround 827 for all planes, v2.

Vidya Srinivas (2):
  drm/i915: Enable Display WA 0528
  drm/i915: Do not do fb src adjustments for NV12

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

-- 
2.7.4

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

[PATCH v2 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 v2 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

Credits-to: Megha Aggarwal megha.aggarwal@intel.com
Tested-by: Clinton Taylor <clinton.a.taylor@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

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

[Kristian Høgsberg]

On Fri, Apr 13, 2018 at 5:17 AM Vidya Srinivas <vidya.srinivas@intel.com>
wrote:

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

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

Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>

> 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

> Credits-to: Megha Aggarwal megha.aggarwal@intel.com
> Tested-by: Clinton Taylor <clinton.a.taylor@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v2 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

Credits-to: Megha Aggarwal <megha.aggarwal@intel.com>
Credits-to: Kristian Høgsberg <hoegsberg@gmail.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

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

[Kristian Høgsberg]

On Fri, Apr 13, 2018 at 5:18 AM Vidya Srinivas <vidya.srinivas@intel.com>
wrote:

> 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

> Credits-to: Megha Aggarwal <megha.aggarwal@intel.com>
> Credits-to: Kristian Høgsberg <hoegsberg@gmail.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;

Thanks for adding the modifier support.

Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>

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

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

[Srinivas, Vidya]

Thank you so much. I had included your name also under credits-to
I will add your RB before merging.

Regards
Vidya

> -----Original Message-----
> From: Kristian Høgsberg [mailto:hoegsberg@gmail.com]
> Sent: Friday, April 13, 2018 9:44 PM
> To: Srinivas, Vidya <vidya.srinivas@intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> On Fri, Apr 13, 2018 at 5:18 AM Vidya Srinivas <vidya.srinivas@intel.com>
> wrote:
> 
> > 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
> 
> > Credits-to: Megha Aggarwal <megha.aggarwal@intel.com>
> > Credits-to: Kristian Høgsberg <hoegsberg@gmail.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;
> 
> Thanks for adding the modifier support.
> 
> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
> 
> >          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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v2 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

Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Clinton Taylor <clinton.a.taylor@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 | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1a0fae9..f64bef9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14261,6 +14261,14 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
 			goto err;
 		}
 		break;
+	case DRM_FORMAT_NV12:
+		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 +14281,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 v2 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

Credits-to: 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 f64bef9..bc83f10 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 v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Vidya Srinivas]

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

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index bc83f10..f64708f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct intel_plane *plane,
 	bool can_position = false;
 	int ret;
 	uint32_t pixel_format = 0;
+	struct drm_plane_state *plane_state = &state->base;
+	struct drm_rect *src = &plane_state->src;
+
+	*src = drm_plane_state_src(plane_state);
 
 	if (INTEL_GEN(dev_priv) >= 9) {
 		/* use scaler when colorkey is not required */
@@ -13001,6 +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
 	if (!state->base.fb)
 		return 0;
 
+	if (pixel_format == DRM_FORMAT_NV12) {
+		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
+		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
+		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
+		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
+	}
+
 	if (INTEL_GEN(dev_priv) >= 9) {
 		ret = skl_check_plane_surface(crtc_state, state);
 		if (ret)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index 8b7947d..c1dd85e 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1035,11 +1035,20 @@ intel_check_sprite_plane(struct intel_plane *plane,
 			return vscale;
 		}
 
+		if (fb->format->format == DRM_FORMAT_NV12) {
+			if (src->x2 >> 16 == 16)
+				src->x2 = 16 << 16;
+			if (src->y2 >> 16 == 16)
+				src->y2 = 16 << 16;
+			goto nv12_min_no_clip;
+		}
+
 		/* 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));
 
+nv12_min_no_clip:
 		drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
 				    state->base.rotation);
 
@@ -1105,6 +1114,12 @@ intel_check_sprite_plane(struct intel_plane *plane,
 		src->x2 = (src_x + src_w) << 16;
 		src->y1 = src_y << 16;
 		src->y2 = (src_y + src_h) << 16;
+		if (fb->format->format == DRM_FORMAT_NV12) {
+			src->x1 = (((src->x1 >> 16)/4)*4) << 16;
+			src->x2 = (((src->x2 >> 16)/4)*4) << 16;
+			src->y1 = (((src->y1 >> 16)/4)*4) << 16;
+			src->y2 = (((src->y2 >> 16)/4)*4) << 16;
+		}
 	}
 
 	dst->x1 = crtc_x;
-- 
2.7.4

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Mika Kahola]

On Fri, 2018-04-13 at 17:44 +0530, Vidya Srinivas wrote:
> 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
> 
> Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
>  drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bc83f10..f64708f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct intel_plane
> *plane,
>  	bool can_position = false;
>  	int ret;
>  	uint32_t pixel_format = 0;
> +	struct drm_plane_state *plane_state = &state->base;
> +	struct drm_rect *src = &plane_state->src;
This seems unnecessary. We could use the line below to get the src's.

> +
> +	*src = drm_plane_state_src(plane_state);
>  
>  	if (INTEL_GEN(dev_priv) >= 9) {
>  		/* use scaler when colorkey is not required */
> @@ -13001,6 +13005,13 @@ intel_check_primary_plane(struct intel_plane
> *plane,
>  	if (!state->base.fb)
>  		return 0;
>  
> +	if (pixel_format == DRM_FORMAT_NV12) {
> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> +	}
> +
>  	if (INTEL_GEN(dev_priv) >= 9) {
>  		ret = skl_check_plane_surface(crtc_state, state);
>  		if (ret)
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 8b7947d..c1dd85e 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1035,11 +1035,20 @@ intel_check_sprite_plane(struct intel_plane
> *plane,
>  			return vscale;
>  		}
>  
> +		if (fb->format->format == DRM_FORMAT_NV12) {
> +			if (src->x2 >> 16 == 16)
> +				src->x2 = 16 << 16;
> +			if (src->y2 >> 16 == 16)
> +				src->y2 = 16 << 16;
> +			goto nv12_min_no_clip;
> +		}
> +
>  		/* 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));
>  
> +nv12_min_no_clip:
>  		drm_rect_rotate_inv(src, fb->width << 16, fb->height 
> << 16,
>  				    state->base.rotation);
>  
> @@ -1105,6 +1114,12 @@ intel_check_sprite_plane(struct intel_plane
> *plane,
>  		src->x2 = (src_x + src_w) << 16;
>  		src->y1 = src_y << 16;
>  		src->y2 = (src_y + src_h) << 16;
> +		if (fb->format->format == DRM_FORMAT_NV12) {
> +			src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> +			src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> +			src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> +			src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> +		}
>  	}
>  
>  	dst->x1 = crtc_x;
-- 
Mika Kahola - Intel OTC

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Kahola, Mika
> Sent: Tuesday, April 17, 2018 2:49 PM
> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-
> gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Do not do fb src
> adjustments for NV12
> 
> On Fri, 2018-04-13 at 17:44 +0530, Vidya Srinivas wrote:
> > 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
> >
> > Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> >  drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
> >  2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index bc83f10..f64708f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> intel_plane
> > *plane,
> >  	bool can_position = false;
> >  	int ret;
> >  	uint32_t pixel_format = 0;
> > +	struct drm_plane_state *plane_state = &state->base;
> > +	struct drm_rect *src = &plane_state->src;
> This seems unnecessary. We could use the line below to get the src's.
Sure thank you, am moving all the handling code to skl_check_nv12_aux_surface as suggested
By Maarten. So this wont be necessary.

Regards
Vidya
> 
> > +
> > +	*src = drm_plane_state_src(plane_state);
> >
> >  	if (INTEL_GEN(dev_priv) >= 9) {
> >  		/* use scaler when colorkey is not required */ @@ -13001,6
> > +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
> >  	if (!state->base.fb)
> >  		return 0;
> >
> > +	if (pixel_format == DRM_FORMAT_NV12) {
> > +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > +	}
> > +
> >  	if (INTEL_GEN(dev_priv) >= 9) {
> >  		ret = skl_check_plane_surface(crtc_state, state);
> >  		if (ret)
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 8b7947d..c1dd85e 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1035,11 +1035,20 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> >  			return vscale;
> >  		}
> >
> > +		if (fb->format->format == DRM_FORMAT_NV12) {
> > +			if (src->x2 >> 16 == 16)
> > +				src->x2 = 16 << 16;
> > +			if (src->y2 >> 16 == 16)
> > +				src->y2 = 16 << 16;
> > +			goto nv12_min_no_clip;
> > +		}
> > +
> >  		/* 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));
> >
> > +nv12_min_no_clip:
> >  		drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
> >  				    state->base.rotation);
> >
> > @@ -1105,6 +1114,12 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> >  		src->x2 = (src_x + src_w) << 16;
> >  		src->y1 = src_y << 16;
> >  		src->y2 = (src_y + src_h) << 16;
> > +		if (fb->format->format == DRM_FORMAT_NV12) {
> > +			src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > +			src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > +			src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > +			src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > +		}
> >  	}
> >
> >  	dst->x1 = crtc_x;
> --
> Mika Kahola - Intel OTC

_______________________________________________
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

[Patchwork]

== Series Details ==

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

== Summary ==

$ dim checkpatch origin/drm-tip
d24b3eca473a 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
40fa95f31fce drm/i915: Add NV12 as supported format for primary plane
8a5b4eaabb39 drm/i915: Add NV12 as supported format for sprite plane
e82aedce2347 drm/i915: Add NV12 support to intel_framebuffer_init
124a184d1872 drm/i915: Enable Display WA 0528
ff50c03cffbe drm/i915: Do not do fb src adjustments for NV12
-:35: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#35: FILE: drivers/gpu/drm/i915/intel_display.c:13009:
+		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
 		                           ^

-:35: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#35: FILE: drivers/gpu/drm/i915/intel_display.c:13009:
+		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
 		                              ^

-:36: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#36: FILE: drivers/gpu/drm/i915/intel_display.c:13010:
+		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
 		                           ^

-:36: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#36: FILE: drivers/gpu/drm/i915/intel_display.c:13010:
+		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
 		                              ^

-:37: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#37: FILE: drivers/gpu/drm/i915/intel_display.c:13011:
+		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
 		                           ^

-:37: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#37: FILE: drivers/gpu/drm/i915/intel_display.c:13011:
+		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
 		                              ^

-:38: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#38: FILE: drivers/gpu/drm/i915/intel_display.c:13012:
+		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
 		                           ^

-:38: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#38: FILE: drivers/gpu/drm/i915/intel_display.c:13012:
+		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
 		                              ^

-:74: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#74: FILE: drivers/gpu/drm/i915/intel_sprite.c:1118:
+			src->x1 = (((src->x1 >> 16)/4)*4) << 16;
 			                           ^

-:74: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#74: FILE: drivers/gpu/drm/i915/intel_sprite.c:1118:
+			src->x1 = (((src->x1 >> 16)/4)*4) << 16;
 			                              ^

-:75: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#75: FILE: drivers/gpu/drm/i915/intel_sprite.c:1119:
+			src->x2 = (((src->x2 >> 16)/4)*4) << 16;
 			                           ^

-:75: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#75: FILE: drivers/gpu/drm/i915/intel_sprite.c:1119:
+			src->x2 = (((src->x2 >> 16)/4)*4) << 16;
 			                              ^

-:76: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#76: FILE: drivers/gpu/drm/i915/intel_sprite.c:1120:
+			src->y1 = (((src->y1 >> 16)/4)*4) << 16;
 			                           ^

-:76: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#76: FILE: drivers/gpu/drm/i915/intel_sprite.c:1120:
+			src->y1 = (((src->y1 >> 16)/4)*4) << 16;
 			                              ^

-:77: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#77: FILE: drivers/gpu/drm/i915/intel_sprite.c:1121:
+			src->y2 = (((src->y2 >> 16)/4)*4) << 16;
 			                           ^

-:77: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#77: FILE: drivers/gpu/drm/i915/intel_sprite.c:1121:
+			src->y2 = (((src->y2 >> 16)/4)*4) << 16;
 			                              ^

total: 0 errors, 0 warnings, 16 checks, 55 lines checked

_______________________________________________
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

[Patchwork]

== Series Details ==

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

== Summary ==

= CI Bug Log - changes from CI_DRM_4052 -> Patchwork_8686 =

== Summary - SUCCESS ==

  No regressions found.

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


== Changes ==

  No changes found


== Participating hosts (35 -> 32) ==

  Additional (1): fi-cnl-y3 
  Missing    (4): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq fi-snb-2520m 


== Build changes ==

    * Linux: CI_DRM_4052 -> Patchwork_8686

  CI_DRM_4052: ff6d5cf7b19871af5657774f4e8f5f91f6285e12 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4429: 80e4910581c7310258375a003a5de9a57ed24546 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8686: ff50c03cffbe8d8fbedbd51d5cab2b4ea6e0e2bb @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4429: 93b35926a150e318439d2505901288594b3548f5 @ git://anongit.freedesktop.org/piglit


== Linux commits ==

ff50c03cffbe drm/i915: Do not do fb src adjustments for NV12
124a184d1872 drm/i915: Enable Display WA 0528
e82aedce2347 drm/i915: Add NV12 support to intel_framebuffer_init
8a5b4eaabb39 drm/i915: Add NV12 as supported format for sprite plane
40fa95f31fce drm/i915: Add NV12 as supported format for primary plane
d24b3eca473a 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_8686/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

[Patchwork]

== Series Details ==

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

== Summary ==

= CI Bug Log - changes from CI_DRM_4052_full -> Patchwork_8686_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8686_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8686_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/1/mbox/

== Possible new issues ==

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

  === IGT changes ===

    ==== Warnings ====

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

    igt@gem_mocs_settings@mocs-rc6-render:
      shard-kbl:          SKIP -> PASS

    igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-cpu:
      shard-snb:          SKIP -> PASS +2

    
== Known issues ==

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

  === IGT changes ===

    ==== Issues hit ====

    igt@kms_flip@2x-dpms-vs-vblank-race:
      shard-hsw:          PASS -> FAIL (fdo#103060)

    igt@perf_pmu@rc6-runtime-pm-long:
      shard-kbl:          PASS -> FAIL (fdo#105010)

    
    ==== Possible fixes ====

    igt@kms_flip@2x-plain-flip-fb-recreate:
      shard-hsw:          FAIL (fdo#100368) -> PASS +1

    igt@kms_flip@flip-vs-expired-vblank-interruptible:
      shard-hsw:          FAIL (fdo#105189) -> PASS

    
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#105010 https://bugs.freedesktop.org/show_bug.cgi?id=105010
  fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189


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

  Missing    (2): shard-glk shard-glkb 


== Build changes ==

    * Linux: CI_DRM_4052 -> Patchwork_8686

  CI_DRM_4052: ff6d5cf7b19871af5657774f4e8f5f91f6285e12 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4429: 80e4910581c7310258375a003a5de9a57ed24546 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8686: ff50c03cffbe8d8fbedbd51d5cab2b4ea6e0e2bb @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4429: 93b35926a150e318439d2505901288594b3548f5 @ git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Saarinen, Jani]

Lets move this to intel-gfx to get more eyes on it. 

> -----Original Message-----
> From: Srinivas, Vidya
> Sent: tiistai 17. huhtikuuta 2018 5.47
> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; intel-gfx-
> trybot@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> <jani.saarinen@intel.com>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> 
> 
> 
> > -----Original Message-----
> > From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> > Sent: Monday, April 16, 2018 8:00 PM
> > To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
> > trybot@lists.freedesktop.org
> > Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> > <jani.saarinen@intel.com>
> > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> > NV12
> >
> > Hmm, more thought about src adjustments...
> >
> > Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> > > 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
> > >
> > > Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> > > drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
> > >  2 files changed, 26 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index bc83f10..f64708f 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> > intel_plane *plane,
> > >  	bool can_position = false;
> > >  	int ret;
> > >  	uint32_t pixel_format = 0;
> > > +	struct drm_plane_state *plane_state = &state->base;
> > > +	struct drm_rect *src = &plane_state->src;
> > > +
> > > +	*src = drm_plane_state_src(plane_state);
> > >
> > >  	if (INTEL_GEN(dev_priv) >= 9) {
> > >  		/* use scaler when colorkey is not required */ @@ -13001,6
> > > +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
> > >  	if (!state->base.fb)
> > >  		return 0;
> > >
> > > +	if (pixel_format == DRM_FORMAT_NV12) {
> > > +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > > +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > > +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > > +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > > +	}
> >
> > Lets reject non multiple of 4 coordinates for plane_state's src_x and
> > src_y, and before adjustment also reject non multiple of 4
> > src_w/src_h.fter that we can also reject clipping to the right/bottom
> > edge of the screen, if the pipe_src_w/h is not a multiple of 4. That
> > way an application trying to go beyond the screen.
> 
> kms_plane_scaling and some other tests during execution generate lots of
> non mult of 4 buffer width/height. All these tests will show fail in the IGT
> BAT.
> In some cases, even thought the width and height will be multiple of 4
> before the Adjustment (say our 16x16 buffer), this after adjustment
> becomes a 15 in intel_check_sprite_plane.
> This again would cause underrun. If we reject non multiple of 4s in our
> skl_update_scaler also, then even simple tests with 16x16 like rotation will
> fail due to it getting adjusted.
> 
> >
> > skl_check_plane_surface could do all the fixups and is allowed to
> > return an error code, so we could put all SKL specific NV12 handling in
> there.
> > It doesn't matter that we calculate potentially illegal values, if we
> > never program them and return -EINVAL there. If it turns out we've
> > been too paranoid we could relax the condition.
> >
> > This would mean unified handling for NV12 for primary and sprite. :)
> >
> > >  	if (INTEL_GEN(dev_priv) >= 9) {
> > >  		ret = skl_check_plane_surface(crtc_state, state);
> > >  		if (ret)
> > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > > b/drivers/gpu/drm/i915/intel_sprite.c
> > > index 8b7947d..c1dd85e 100644
> > > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > > @@ -1035,11 +1035,20 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> > >  			return vscale;
> > >  		}
> > >
> > > +		if (fb->format->format == DRM_FORMAT_NV12) {
> > > +			if (src->x2 >> 16 == 16)
> > > +				src->x2 = 16 << 16;
> > > +			if (src->y2 >> 16 == 16)
> > > +				src->y2 = 16 << 16;
> > This part doesn't look required, the magic below for the nv12 format
> > is similar.. Just conditionally call adjust_size for format != NV12.
> > :)
> > > +			goto nv12_min_no_clip;
> > > +		}
> > > +
> > >  		/* 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));
> > >
> > > +nv12_min_no_clip:
> > >  		drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
> > >  				    state->base.rotation);
> > >
> > > @@ -1105,6 +1114,12 @@ intel_check_sprite_plane(struct intel_plane
> > *plane,
> > >  		src->x2 = (src_x + src_w) << 16;
> > >  		src->y1 = src_y << 16;
> > >  		src->y2 = (src_y + src_h) << 16;
> > > +		if (fb->format->format == DRM_FORMAT_NV12) {
> > > +			src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > > +			src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > > +			src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > > +			src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > > +		}

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Maarten Lankhorst]

Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> Lets move this to intel-gfx to get more eyes on it. 
>
>> -----Original Message-----
>> From: Srinivas, Vidya
>> Sent: tiistai 17. huhtikuuta 2018 5.47
>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; intel-gfx-
>> trybot@lists.freedesktop.org
>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
>> <jani.saarinen@intel.com>
>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
>>
>>
>>
>>> -----Original Message-----
>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
>>> Sent: Monday, April 16, 2018 8:00 PM
>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
>>> trybot@lists.freedesktop.org
>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
>>> <jani.saarinen@intel.com>
>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>>> NV12
>>>
>>> Hmm, more thought about src adjustments...
>>>
>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
>>>> 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
>>>>
>>>> Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
>>>> ---
>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
>>>>  2 files changed, 26 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>> index bc83f10..f64708f 100644
>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
>>> intel_plane *plane,
>>>>  	bool can_position = false;
>>>>  	int ret;
>>>>  	uint32_t pixel_format = 0;
>>>> +	struct drm_plane_state *plane_state = &state->base;
>>>> +	struct drm_rect *src = &plane_state->src;
>>>> +
>>>> +	*src = drm_plane_state_src(plane_state);
>>>>
>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
>>>>  		/* use scaler when colorkey is not required */ @@ -13001,6
>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
>>>>  	if (!state->base.fb)
>>>>  		return 0;
>>>>
>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
>>>> +	}
>>> Lets reject non multiple of 4 coordinates for plane_state's src_x and
>>> src_y, and before adjustment also reject non multiple of 4
>>> src_w/src_h.fter that we can also reject clipping to the right/bottom
>>> edge of the screen, if the pipe_src_w/h is not a multiple of 4. That
>>> way an application trying to go beyond the screen.
>> kms_plane_scaling and some other tests during execution generate lots of
>> non mult of 4 buffer width/height. All these tests will show fail in the IGT
>> BAT.
>> In some cases, even thought the width and height will be multiple of 4
>> before the Adjustment (say our 16x16 buffer), this after adjustment
>> becomes a 15 in intel_check_sprite_plane.
>> This again would cause underrun. If we reject non multiple of 4s in our
>> skl_update_scaler also, then even simple tests with 16x16 like rotation will
>> fail due to it getting adjusted.

Correct. This is why we fix up to a multiple of 4 after adjustments, and
reject user passed coordinates before adjustment.. plane_state->src_x/y/w/h
is the property set by the user, while the plane_state->src rect is set and
fixed up in the kernel.

Rejecting clipping with positive coordinates if pipe_src w/h
is not a multiple of 4 will fix a border case that shouldn't affect most modes,
where the plane wouldn't extend to the crtc borders, which is what userspace wants there.


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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> Sent: Tuesday, April 17, 2018 12:55 PM
> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
> <vidya.srinivas@intel.com>; intel-gfx-trybot@lists.freedesktop.org; intel-
> gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > Lets move this to intel-gfx to get more eyes on it.
> >
> >> -----Original Message-----
> >> From: Srinivas, Vidya
> >> Sent: tiistai 17. huhtikuuta 2018 5.47
> >> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; intel-gfx-
> >> trybot@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >> <jani.saarinen@intel.com>
> >> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for NV12
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >>> Sent: Monday, April 16, 2018 8:00 PM
> >>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
> >>> trybot@lists.freedesktop.org
> >>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>> <jani.saarinen@intel.com>
> >>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>> for
> >>> NV12
> >>>
> >>> Hmm, more thought about src adjustments...
> >>>
> >>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>>> 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
> >>>>
> >>>> Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> >>>> ---
> >>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> >>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
> >>>>  2 files changed, 26 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>>> b/drivers/gpu/drm/i915/intel_display.c
> >>>> index bc83f10..f64708f 100644
> >>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> >>> intel_plane *plane,
> >>>>  	bool can_position = false;
> >>>>  	int ret;
> >>>>  	uint32_t pixel_format = 0;
> >>>> +	struct drm_plane_state *plane_state = &state->base;
> >>>> +	struct drm_rect *src = &plane_state->src;
> >>>> +
> >>>> +	*src = drm_plane_state_src(plane_state);
> >>>>
> >>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> >>>>  		/* use scaler when colorkey is not required */ @@ -13001,6
> >>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
> >>>>  	if (!state->base.fb)
> >>>>  		return 0;
> >>>>
> >>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> >>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> >>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> >>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> >>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> >>>> +	}
> >>> Lets reject non multiple of 4 coordinates for plane_state's src_x
> >>> and src_y, and before adjustment also reject non multiple of 4
> >>> src_w/src_h.fter that we can also reject clipping to the
> >>> right/bottom edge of the screen, if the pipe_src_w/h is not a
> >>> multiple of 4. That way an application trying to go beyond the screen.
> >> kms_plane_scaling and some other tests during execution generate lots
> >> of non mult of 4 buffer width/height. All these tests will show fail
> >> in the IGT BAT.
> >> In some cases, even thought the width and height will be multiple of
> >> 4 before the Adjustment (say our 16x16 buffer), this after adjustment
> >> becomes a 15 in intel_check_sprite_plane.
> >> This again would cause underrun. If we reject non multiple of 4s in
> >> our skl_update_scaler also, then even simple tests with 16x16 like
> >> rotation will fail due to it getting adjusted.
> 
> Correct. This is why we fix up to a multiple of 4 after adjustments, and reject
> user passed coordinates before adjustment.. plane_state->src_x/y/w/h is
> the property set by the user, while the plane_state->src rect is set and fixed
> up in the kernel.
> 
> Rejecting clipping with positive coordinates if pipe_src w/h is not a multiple
> of 4 will fix a border case that shouldn't affect most modes, where the plane
> wouldn't extend to the crtc borders, which is what userspace wants there.
> 

Thank you. Oh okay. Sorry. I thought we just reject and not do the fixing (mult of 4 later).
Sure, I will change the patch to also reject the coordinates before adjustment (if its not
Mult of 4). 


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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Maarten Lankhorst]

Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
>
>> -----Original Message-----
>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
>> Sent: Tuesday, April 17, 2018 12:55 PM
>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
>> <vidya.srinivas@intel.com>; intel-gfx-trybot@lists.freedesktop.org; intel-
>> gfx@lists.freedesktop.org
>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>> NV12
>>
>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
>>> Lets move this to intel-gfx to get more eyes on it.
>>>
>>>> -----Original Message-----
>>>> From: Srinivas, Vidya
>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; intel-gfx-
>>>> trybot@lists.freedesktop.org
>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
>>>> <jani.saarinen@intel.com>
>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
>>>> for NV12
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
>>>>> Sent: Monday, April 16, 2018 8:00 PM
>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
>>>>> trybot@lists.freedesktop.org
>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
>>>>> <jani.saarinen@intel.com>
>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
>>>>> for
>>>>> NV12
>>>>>
>>>>> Hmm, more thought about src adjustments...
>>>>>
>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
>>>>>> 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
>>>>>>
>>>>>> Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
>>>>>> ---
>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
>>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
>>>>>>  2 files changed, 26 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>>>> index bc83f10..f64708f 100644
>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
>>>>> intel_plane *plane,
>>>>>>  	bool can_position = false;
>>>>>>  	int ret;
>>>>>>  	uint32_t pixel_format = 0;
>>>>>> +	struct drm_plane_state *plane_state = &state->base;
>>>>>> +	struct drm_rect *src = &plane_state->src;
>>>>>> +
>>>>>> +	*src = drm_plane_state_src(plane_state);
>>>>>>
>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
>>>>>>  		/* use scaler when colorkey is not required */ @@ -13001,6
>>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
>>>>>>  	if (!state->base.fb)
>>>>>>  		return 0;
>>>>>>
>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
>>>>>> +	}
>>>>> Lets reject non multiple of 4 coordinates for plane_state's src_x
>>>>> and src_y, and before adjustment also reject non multiple of 4
>>>>> src_w/src_h.fter that we can also reject clipping to the
>>>>> right/bottom edge of the screen, if the pipe_src_w/h is not a
>>>>> multiple of 4. That way an application trying to go beyond the screen.
>>>> kms_plane_scaling and some other tests during execution generate lots
>>>> of non mult of 4 buffer width/height. All these tests will show fail
>>>> in the IGT BAT.
>>>> In some cases, even thought the width and height will be multiple of
>>>> 4 before the Adjustment (say our 16x16 buffer), this after adjustment
>>>> becomes a 15 in intel_check_sprite_plane.
>>>> This again would cause underrun. If we reject non multiple of 4s in
>>>> our skl_update_scaler also, then even simple tests with 16x16 like
>>>> rotation will fail due to it getting adjusted.
>> Correct. This is why we fix up to a multiple of 4 after adjustments, and reject
>> user passed coordinates before adjustment.. plane_state->src_x/y/w/h is
>> the property set by the user, while the plane_state->src rect is set and fixed
>> up in the kernel.
>>
>> Rejecting clipping with positive coordinates if pipe_src w/h is not a multiple
>> of 4 will fix a border case that shouldn't affect most modes, where the plane
>> wouldn't extend to the crtc borders, which is what userspace wants there.
>>
> Thank you. Oh okay. Sorry. I thought we just reject and not do the fixing (mult of 4 later).
> Sure, I will change the patch to also reject the coordinates before adjustment (if its not
> Mult of 4). 
>
>
This can be done in skl_check_plane_surface, plane_state->src_{x,y,w,h} contains the user requested values.

~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> Sent: Tuesday, April 17, 2018 1:21 PM
> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >
> >> -----Original Message-----
> >> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 12:55 PM
> >> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
> >> <vidya.srinivas@intel.com>; intel-gfx-trybot@lists.freedesktop.org;
> >> intel- gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>> Lets move this to intel-gfx to get more eyes on it.
> >>>
> >>>> -----Original Message-----
> >>>> From: Srinivas, Vidya
> >>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
> >>>> intel-gfx- trybot@lists.freedesktop.org
> >>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>>> <jani.saarinen@intel.com>
> >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>> for NV12
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >>>>> Sent: Monday, April 16, 2018 8:00 PM
> >>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
> >>>>> trybot@lists.freedesktop.org
> >>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>>>> <jani.saarinen@intel.com>
> >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>>> for
> >>>>> NV12
> >>>>>
> >>>>> Hmm, more thought about src adjustments...
> >>>>>
> >>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>>>>> 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
> >>>>>>
> >>>>>> Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> >>>>>> ---
> >>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> >>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
> >>>>>>  2 files changed, 26 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>>>>> b/drivers/gpu/drm/i915/intel_display.c
> >>>>>> index bc83f10..f64708f 100644
> >>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> >>>>> intel_plane *plane,
> >>>>>>  	bool can_position = false;
> >>>>>>  	int ret;
> >>>>>>  	uint32_t pixel_format = 0;
> >>>>>> +	struct drm_plane_state *plane_state = &state->base;
> >>>>>> +	struct drm_rect *src = &plane_state->src;
> >>>>>> +
> >>>>>> +	*src = drm_plane_state_src(plane_state);
> >>>>>>
> >>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> >>>>>>  		/* use scaler when colorkey is not required */ @@ -
> 13001,6
> >>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> *plane,
> >>>>>>  	if (!state->base.fb)
> >>>>>>  		return 0;
> >>>>>>
> >>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> >>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> >>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> >>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> >>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> >>>>>> +	}
> >>>>> Lets reject non multiple of 4 coordinates for plane_state's src_x
> >>>>> and src_y, and before adjustment also reject non multiple of 4
> >>>>> src_w/src_h.fter that we can also reject clipping to the
> >>>>> right/bottom edge of the screen, if the pipe_src_w/h is not a
> >>>>> multiple of 4. That way an application trying to go beyond the screen.
> >>>> kms_plane_scaling and some other tests during execution generate
> >>>> lots of non mult of 4 buffer width/height. All these tests will
> >>>> show fail in the IGT BAT.
> >>>> In some cases, even thought the width and height will be multiple
> >>>> of
> >>>> 4 before the Adjustment (say our 16x16 buffer), this after
> >>>> adjustment becomes a 15 in intel_check_sprite_plane.
> >>>> This again would cause underrun. If we reject non multiple of 4s in
> >>>> our skl_update_scaler also, then even simple tests with 16x16 like
> >>>> rotation will fail due to it getting adjusted.
> >> Correct. This is why we fix up to a multiple of 4 after adjustments,
> >> and reject user passed coordinates before adjustment..
> >> plane_state->src_x/y/w/h is the property set by the user, while the
> >> plane_state->src rect is set and fixed up in the kernel.
> >>
> >> Rejecting clipping with positive coordinates if pipe_src w/h is not a
> >> multiple of 4 will fix a border case that shouldn't affect most
> >> modes, where the plane wouldn't extend to the crtc borders, which is
> what userspace wants there.
> >>
> > Thank you. Oh okay. Sorry. I thought we just reject and not do the fixing
> (mult of 4 later).
> > Sure, I will change the patch to also reject the coordinates before
> > adjustment (if its not Mult of 4).
> >
> >
> This can be done in skl_check_plane_surface, plane_state->src_{x,y,w,h}
> contains the user requested values.

Apologies for asking again. The adjustments are done in check_plane (both primary and sprite)
And towards the end of check_plane we call the skl_check_plane_surface.
I got your point that we will reject the user requested values if they are not multiple of 4.
But before we reach skl_check_plane_surface, they would’ve been adjusted/clipped etc
They wont remain user requested as is when they enter skl_check_plane_surface.
Please correct me if I am wrong or I am missing in understanding something here :(

I can add the add conversion to multiple of 4 in skl_check_plane_surface but rejection should be done before the clipping/adjustment
Or else, I move the entire clipping/adjustment code to skl_check_plane_surface?

Regards
Vidya
> 
> ~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Srinivas, Vidya
> Sent: Tuesday, April 17, 2018 1:32 PM
> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>; Saarinen,
> Jani <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> 
> 
> > -----Original Message-----
> > From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> > Sent: Tuesday, April 17, 2018 1:21 PM
> > To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> > <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> > NV12
> >
> > Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> > >
> > >> -----Original Message-----
> > >> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> > >> Sent: Tuesday, April 17, 2018 12:55 PM
> > >> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
> > >> <vidya.srinivas@intel.com>; intel-gfx-trybot@lists.freedesktop.org;
> > >> intel- gfx@lists.freedesktop.org
> > >> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > >> for
> > >> NV12
> > >>
> > >> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > >>> Lets move this to intel-gfx to get more eyes on it.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Srinivas, Vidya
> > >>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> > >>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
> > >>>> intel-gfx- trybot@lists.freedesktop.org
> > >>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> > >>>> <jani.saarinen@intel.com>
> > >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > >>>> adjustments for NV12
> > >>>>
> > >>>>
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Maarten Lankhorst
> > >>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > >>>>> Sent: Monday, April 16, 2018 8:00 PM
> > >>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
> > >>>>> trybot@lists.freedesktop.org
> > >>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> > >>>>> <jani.saarinen@intel.com>
> > >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > >>>>> adjustments for
> > >>>>> NV12
> > >>>>>
> > >>>>> Hmm, more thought about src adjustments...
> > >>>>>
> > >>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> > >>>>>> 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
> > >>>>>>
> > >>>>>> Credits-to: Maarten Lankhorst
> > >>>>>> <maarten.lankhorst@linux.intel.com>
> > >>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> > >>>>>> ---
> > >>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> > >>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
> > >>>>>>  2 files changed, 26 insertions(+)
> > >>>>>>
> > >>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > >>>>>> b/drivers/gpu/drm/i915/intel_display.c
> > >>>>>> index bc83f10..f64708f 100644
> > >>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> > >>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> > >>>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> > >>>>> intel_plane *plane,
> > >>>>>>  	bool can_position = false;
> > >>>>>>  	int ret;
> > >>>>>>  	uint32_t pixel_format = 0;
> > >>>>>> +	struct drm_plane_state *plane_state = &state->base;
> > >>>>>> +	struct drm_rect *src = &plane_state->src;
> > >>>>>> +
> > >>>>>> +	*src = drm_plane_state_src(plane_state);
> > >>>>>>
> > >>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> > >>>>>>  		/* use scaler when colorkey is not required */ @@ -
> > 13001,6
> > >>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> > *plane,
> > >>>>>>  	if (!state->base.fb)
> > >>>>>>  		return 0;
> > >>>>>>
> > >>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> > >>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > >>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > >>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > >>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > >>>>>> +	}
> > >>>>> Lets reject non multiple of 4 coordinates for plane_state's
> > >>>>> src_x and src_y, and before adjustment also reject non multiple
> > >>>>> of 4 src_w/src_h.fter that we can also reject clipping to the
> > >>>>> right/bottom edge of the screen, if the pipe_src_w/h is not a
> > >>>>> multiple of 4. That way an application trying to go beyond the
> screen.
> > >>>> kms_plane_scaling and some other tests during execution generate
> > >>>> lots of non mult of 4 buffer width/height. All these tests will
> > >>>> show fail in the IGT BAT.
> > >>>> In some cases, even thought the width and height will be multiple
> > >>>> of
> > >>>> 4 before the Adjustment (say our 16x16 buffer), this after
> > >>>> adjustment becomes a 15 in intel_check_sprite_plane.
> > >>>> This again would cause underrun. If we reject non multiple of 4s
> > >>>> in our skl_update_scaler also, then even simple tests with 16x16
> > >>>> like rotation will fail due to it getting adjusted.
> > >> Correct. This is why we fix up to a multiple of 4 after
> > >> adjustments, and reject user passed coordinates before adjustment..
> > >> plane_state->src_x/y/w/h is the property set by the user, while the
> > >> plane_state->src rect is set and fixed up in the kernel.
> > >>
> > >> Rejecting clipping with positive coordinates if pipe_src w/h is not
> > >> a multiple of 4 will fix a border case that shouldn't affect most
> > >> modes, where the plane wouldn't extend to the crtc borders, which
> > >> is
> > what userspace wants there.
> > >>
> > > Thank you. Oh okay. Sorry. I thought we just reject and not do the
> > > fixing
> > (mult of 4 later).
> > > Sure, I will change the patch to also reject the coordinates before
> > > adjustment (if its not Mult of 4).
> > >
> > >
> > This can be done in skl_check_plane_surface,
> > plane_state->src_{x,y,w,h} contains the user requested values.
> 
> Apologies for asking again. The adjustments are done in check_plane (both
> primary and sprite) And towards the end of check_plane we call the
> skl_check_plane_surface.
> I got your point that we will reject the user requested values if they are not
> multiple of 4.
> But before we reach skl_check_plane_surface, they would’ve been
> adjusted/clipped etc They wont remain user requested as is when they enter
> skl_check_plane_surface.
> Please correct me if I am wrong or I am missing in understanding something
> here :(
> 
> I can add the add conversion to multiple of 4 in skl_check_plane_surface but
> rejection should be done before the clipping/adjustment Or else, I move the
> entire clipping/adjustment code to skl_check_plane_surface?
> 

Sorry, I got it. You said, we don’t do adjustments in case of NV12 in sprite and move
The handling to skl_check_plane_surface. I will do the change and submit. Sorry.
Thank you.

> Regards
> Vidya
> >
> > ~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Maarten Lankhorst]

Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
>
>> -----Original Message-----
>> From: Srinivas, Vidya
>> Sent: Tuesday, April 17, 2018 1:32 PM
>> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>; Saarinen,
>> Jani <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>> NV12
>>
>>
>>
>>> -----Original Message-----
>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
>>> Sent: Tuesday, April 17, 2018 1:21 PM
>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
>>> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>>> NV12
>>>
>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
>>>>> -----Original Message-----
>>>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
>>>>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
>>>>> <vidya.srinivas@intel.com>; intel-gfx-trybot@lists.freedesktop.org;
>>>>> intel- gfx@lists.freedesktop.org
>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
>>>>> for
>>>>> NV12
>>>>>
>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
>>>>>> Lets move this to intel-gfx to get more eyes on it.
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Srinivas, Vidya
>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
>>>>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
>>>>>>> intel-gfx- trybot@lists.freedesktop.org
>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
>>>>>>> <jani.saarinen@intel.com>
>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
>>>>>>> adjustments for NV12
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Maarten Lankhorst
>>>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
>>>>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
>>>>>>>> trybot@lists.freedesktop.org
>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
>>>>>>>> <jani.saarinen@intel.com>
>>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
>>>>>>>> adjustments for
>>>>>>>> NV12
>>>>>>>>
>>>>>>>> Hmm, more thought about src adjustments...
>>>>>>>>
>>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> Credits-to: Maarten Lankhorst
>>>>>>>>> <maarten.lankhorst@linux.intel.com>
>>>>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
>>>>>>>>> ---
>>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
>>>>>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
>>>>>>>>>  2 files changed, 26 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>>>>>>> index bc83f10..f64708f 100644
>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>>>>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
>>>>>>>> intel_plane *plane,
>>>>>>>>>  	bool can_position = false;
>>>>>>>>>  	int ret;
>>>>>>>>>  	uint32_t pixel_format = 0;
>>>>>>>>> +	struct drm_plane_state *plane_state = &state->base;
>>>>>>>>> +	struct drm_rect *src = &plane_state->src;
>>>>>>>>> +
>>>>>>>>> +	*src = drm_plane_state_src(plane_state);
>>>>>>>>>
>>>>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
>>>>>>>>>  		/* use scaler when colorkey is not required */ @@ -
>>> 13001,6
>>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
>>> *plane,
>>>>>>>>>  	if (!state->base.fb)
>>>>>>>>>  		return 0;
>>>>>>>>>
>>>>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
>>>>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
>>>>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
>>>>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
>>>>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
>>>>>>>>> +	}
>>>>>>>> Lets reject non multiple of 4 coordinates for plane_state's
>>>>>>>> src_x and src_y, and before adjustment also reject non multiple
>>>>>>>> of 4 src_w/src_h.fter that we can also reject clipping to the
>>>>>>>> right/bottom edge of the screen, if the pipe_src_w/h is not a
>>>>>>>> multiple of 4. That way an application trying to go beyond the
>> screen.
>>>>>>> kms_plane_scaling and some other tests during execution generate
>>>>>>> lots of non mult of 4 buffer width/height. All these tests will
>>>>>>> show fail in the IGT BAT.
>>>>>>> In some cases, even thought the width and height will be multiple
>>>>>>> of
>>>>>>> 4 before the Adjustment (say our 16x16 buffer), this after
>>>>>>> adjustment becomes a 15 in intel_check_sprite_plane.
>>>>>>> This again would cause underrun. If we reject non multiple of 4s
>>>>>>> in our skl_update_scaler also, then even simple tests with 16x16
>>>>>>> like rotation will fail due to it getting adjusted.
>>>>> Correct. This is why we fix up to a multiple of 4 after
>>>>> adjustments, and reject user passed coordinates before adjustment..
>>>>> plane_state->src_x/y/w/h is the property set by the user, while the
>>>>> plane_state->src rect is set and fixed up in the kernel.
>>>>>
>>>>> Rejecting clipping with positive coordinates if pipe_src w/h is not
>>>>> a multiple of 4 will fix a border case that shouldn't affect most
>>>>> modes, where the plane wouldn't extend to the crtc borders, which
>>>>> is
>>> what userspace wants there.
>>>> Thank you. Oh okay. Sorry. I thought we just reject and not do the
>>>> fixing
>>> (mult of 4 later).
>>>> Sure, I will change the patch to also reject the coordinates before
>>>> adjustment (if its not Mult of 4).
>>>>
>>>>
>>> This can be done in skl_check_plane_surface,
>>> plane_state->src_{x,y,w,h} contains the user requested values.
>> Apologies for asking again. The adjustments are done in check_plane (both
>> primary and sprite) And towards the end of check_plane we call the
>> skl_check_plane_surface.
>> I got your point that we will reject the user requested values if they are not
>> multiple of 4.
>> But before we reach skl_check_plane_surface, they would’ve been
>> adjusted/clipped etc They wont remain user requested as is when they enter
>> skl_check_plane_surface.
>> Please correct me if I am wrong or I am missing in understanding something
>> here :(
>>
>> I can add the add conversion to multiple of 4 in skl_check_plane_surface but
>> rejection should be done before the clipping/adjustment Or else, I move the
>> entire clipping/adjustment code to skl_check_plane_surface?
>>
> Sorry, I got it. You said, we don’t do adjustments in case of NV12 in sprite and move
> The handling to skl_check_plane_surface. I will do the change and submit. Sorry.
> Thank you.
>
Something like below? Untested..
We should probably also restrict NV12 fb creation to not allow CCS formats.

~Maarten

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 4b3735720fee..c5da30c7ad04 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3090,6 +3090,38 @@ 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;
+
+	/* Are the unadjusted coordinates passed in valid? */
+	if ((plane_state->base.src_x >> 16) % 4 ||
+	    (plane_state->base.src_y >> 16) % 4 ||
+	    (plane_state->base.src_w >> 16) % 4 ||
+	    (plane_state->base.src_h >> 16) % 4) {
+		DRM_DEBUG_KMS("Source coordinates must be a 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;
+	}
+
+	/* Make adjusted src coordinates a multiple of 4. */
+	plane_state->base.src.x1 = DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18;
+	plane_state->base.src.y1 = DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18;
+	plane_state->base.src.x2 = DIV_ROUND_CLOSEST(plane_state->base.src.x2, 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;
@@ -3162,6 +3194,12 @@ int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
 	if (!plane_state->base.visible)
 		return 0;
 
+	if (fb->format->format == DRM_FORMAT_NV12) {
+		ret = skl_check_nv12_surface(crtc_state, plane_state);
+		if (ret)
+			return ret;
+	}
+
 	/* Rotate src coordinates to match rotated GTT view */
 	if (drm_rotation_90_or_270(rotation))
 		drm_rect_rotate(&plane_state->base.src,

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:04 PM
> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> >
> >> -----Original Message-----
> >> From: Srinivas, Vidya
> >> Sent: Tuesday, April 17, 2018 1:32 PM
> >> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>;
> >> Saarinen, Jani <jani.saarinen@intel.com>;
> >> intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >>> Sent: Tuesday, April 17, 2018 1:21 PM
> >>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> >>> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> >>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>> for
> >>> NV12
> >>>
> >>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >>>>> -----Original Message-----
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> >>>>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
> >>>>> <vidya.srinivas@intel.com>;
> >>>>> intel-gfx-trybot@lists.freedesktop.org;
> >>>>> intel- gfx@lists.freedesktop.org
> >>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>>> for
> >>>>> NV12
> >>>>>
> >>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>>>>> Lets move this to intel-gfx to get more eyes on it.
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Srinivas, Vidya
> >>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>>>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
> >>>>>>> intel-gfx- trybot@lists.freedesktop.org
> >>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>>>>>> <jani.saarinen@intel.com>
> >>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>> adjustments for NV12
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Maarten Lankhorst
> >>>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> >>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> >>>>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
> >>>>>>>> trybot@lists.freedesktop.org
> >>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>>>>>>> <jani.saarinen@intel.com>
> >>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>> adjustments for
> >>>>>>>> NV12
> >>>>>>>>
> >>>>>>>> Hmm, more thought about src adjustments...
> >>>>>>>>
> >>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>> Credits-to: Maarten Lankhorst
> >>>>>>>>> <maarten.lankhorst@linux.intel.com>
> >>>>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> >>>>>>>>> ---
> >>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> >>>>>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
> >>>>>>>>>  2 files changed, 26 insertions(+)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>> index bc83f10..f64708f 100644
> >>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> >>>>>>>> intel_plane *plane,
> >>>>>>>>>  	bool can_position = false;
> >>>>>>>>>  	int ret;
> >>>>>>>>>  	uint32_t pixel_format = 0;
> >>>>>>>>> +	struct drm_plane_state *plane_state = &state->base;
> >>>>>>>>> +	struct drm_rect *src = &plane_state->src;
> >>>>>>>>> +
> >>>>>>>>> +	*src = drm_plane_state_src(plane_state);
> >>>>>>>>>
> >>>>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> >>>>>>>>>  		/* use scaler when colorkey is not required */ @@ -
> >>> 13001,6
> >>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> >>> *plane,
> >>>>>>>>>  	if (!state->base.fb)
> >>>>>>>>>  		return 0;
> >>>>>>>>>
> >>>>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> >>>>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> >>>>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> >>>>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> >>>>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> >>>>>>>>> +	}
> >>>>>>>> Lets reject non multiple of 4 coordinates for plane_state's
> >>>>>>>> src_x and src_y, and before adjustment also reject non multiple
> >>>>>>>> of 4 src_w/src_h.fter that we can also reject clipping to the
> >>>>>>>> right/bottom edge of the screen, if the pipe_src_w/h is not a
> >>>>>>>> multiple of 4. That way an application trying to go beyond the
> >> screen.
> >>>>>>> kms_plane_scaling and some other tests during execution generate
> >>>>>>> lots of non mult of 4 buffer width/height. All these tests will
> >>>>>>> show fail in the IGT BAT.
> >>>>>>> In some cases, even thought the width and height will be
> >>>>>>> multiple of
> >>>>>>> 4 before the Adjustment (say our 16x16 buffer), this after
> >>>>>>> adjustment becomes a 15 in intel_check_sprite_plane.
> >>>>>>> This again would cause underrun. If we reject non multiple of 4s
> >>>>>>> in our skl_update_scaler also, then even simple tests with 16x16
> >>>>>>> like rotation will fail due to it getting adjusted.
> >>>>> Correct. This is why we fix up to a multiple of 4 after
> >>>>> adjustments, and reject user passed coordinates before adjustment..
> >>>>> plane_state->src_x/y/w/h is the property set by the user, while
> >>>>> the plane_state->src rect is set and fixed up in the kernel.
> >>>>>
> >>>>> Rejecting clipping with positive coordinates if pipe_src w/h is
> >>>>> not a multiple of 4 will fix a border case that shouldn't affect
> >>>>> most modes, where the plane wouldn't extend to the crtc borders,
> >>>>> which is
> >>> what userspace wants there.
> >>>> Thank you. Oh okay. Sorry. I thought we just reject and not do the
> >>>> fixing
> >>> (mult of 4 later).
> >>>> Sure, I will change the patch to also reject the coordinates before
> >>>> adjustment (if its not Mult of 4).
> >>>>
> >>>>
> >>> This can be done in skl_check_plane_surface,
> >>> plane_state->src_{x,y,w,h} contains the user requested values.
> >> Apologies for asking again. The adjustments are done in check_plane
> >> (both primary and sprite) And towards the end of check_plane we call
> >> the skl_check_plane_surface.
> >> I got your point that we will reject the user requested values if
> >> they are not multiple of 4.
> >> But before we reach skl_check_plane_surface, they would’ve been
> >> adjusted/clipped etc They wont remain user requested as is when they
> >> enter skl_check_plane_surface.
> >> Please correct me if I am wrong or I am missing in understanding
> >> something here :(
> >>
> >> I can add the add conversion to multiple of 4 in
> >> skl_check_plane_surface but rejection should be done before the
> >> clipping/adjustment Or else, I move the entire clipping/adjustment code
> to skl_check_plane_surface?
> >>
> > Sorry, I got it. You said, we don’t do adjustments in case of NV12 in
> > sprite and move The handling to skl_check_plane_surface. I will do the
> change and submit. Sorry.
> > Thank you.
> >
> Something like below? Untested..
> We should probably also restrict NV12 fb creation to not allow CCS formats.
> 
> ~Maarten
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4b3735720fee..c5da30c7ad04 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3090,6 +3090,38 @@ 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;
> +
> +	/* Are the unadjusted coordinates passed in valid? */
> +	if ((plane_state->base.src_x >> 16) % 4 ||
> +	    (plane_state->base.src_y >> 16) % 4 ||
> +	    (plane_state->base.src_w >> 16) % 4 ||
> +	    (plane_state->base.src_h >> 16) % 4) {
> +		DRM_DEBUG_KMS("Source coordinates must be a 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;
> +	}
> +
> +	/* Make adjusted src coordinates a multiple of 4. */
> +	plane_state->base.src.x1 = DIV_ROUND_CLOSEST(plane_state-
> >base.src.x1, 1 << 18) << 18;
> +	plane_state->base.src.y1 = DIV_ROUND_CLOSEST(plane_state-
> >base.src.y1, 1 << 18) << 18;
> +	plane_state->base.src.x2 = DIV_ROUND_CLOSEST(plane_state-
> >base.src.x2, 1 << 18) << 18;
> +	plane_state->base.src.y2 = DIV_ROUND_CLOSEST(plane_state-
> >base.src.y2, 1 << 18) << 18;
> +	return 0;
> +}
> +

Thank you so much :) Only one problem. The primary plane clipping
happens inside the drm layer in drm_atomic_helper_check_plane_state
So, clipping-clamping test passes coordinates 0, 257, 0, 159 to check_plane.
And there before adjusting we reject. So for primary alone, can I retain 
the make multiple of 4 code in primary itself?


>  static int skl_check_nv12_aux_surface(struct intel_plane_state
> *plane_state)  {
>  	const struct drm_framebuffer *fb = plane_state->base.fb; @@ -
> 3162,6 +3194,12 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
>  	if (!plane_state->base.visible)
>  		return 0;
> 
> +	if (fb->format->format == DRM_FORMAT_NV12) {
> +		ret = skl_check_nv12_surface(crtc_state, plane_state);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	/* Rotate src coordinates to match rotated GTT view */
>  	if (drm_rotation_90_or_270(rotation))
>  		drm_rect_rotate(&plane_state->base.src,

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Maarten Lankhorst]

Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
>
>> -----Original Message-----
>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
>> Sent: Tuesday, April 17, 2018 3:04 PM
>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
>> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
>> NV12
>>
>> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
>>>> -----Original Message-----
>>>> From: Srinivas, Vidya
>>>> Sent: Tuesday, April 17, 2018 1:32 PM
>>>> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>;
>>>> Saarinen, Jani <jani.saarinen@intel.com>;
>>>> intel-gfx@lists.freedesktop.org
>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
>>>> for
>>>> NV12
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
>>>>> Sent: Tuesday, April 17, 2018 1:21 PM
>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
>>>>> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
>>>>> for
>>>>> NV12
>>>>>
>>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
>>>>>>> -----Original Message-----
>>>>>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
>>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
>>>>>>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
>>>>>>> <vidya.srinivas@intel.com>;
>>>>>>> intel-gfx-trybot@lists.freedesktop.org;
>>>>>>> intel- gfx@lists.freedesktop.org
>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
>>>>>>> for
>>>>>>> NV12
>>>>>>>
>>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
>>>>>>>> Lets move this to intel-gfx to get more eyes on it.
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Srinivas, Vidya
>>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
>>>>>>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
>>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
>>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
>>>>>>>>> <jani.saarinen@intel.com>
>>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
>>>>>>>>> adjustments for NV12
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Maarten Lankhorst
>>>>>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
>>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
>>>>>>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
>>>>>>>>>> trybot@lists.freedesktop.org
>>>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
>>>>>>>>>> <jani.saarinen@intel.com>
>>>>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
>>>>>>>>>> adjustments for
>>>>>>>>>> NV12
>>>>>>>>>>
>>>>>>>>>> Hmm, more thought about src adjustments...
>>>>>>>>>>
>>>>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> Credits-to: Maarten Lankhorst
>>>>>>>>>>> <maarten.lankhorst@linux.intel.com>
>>>>>>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
>>>>>>>>>>> ---
>>>>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
>>>>>>>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
>>>>>>>>>>>  2 files changed, 26 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>>>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
>>>>>>>>>>> index bc83f10..f64708f 100644
>>>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>>>>>>>>>> @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
>>>>>>>>>> intel_plane *plane,
>>>>>>>>>>>  	bool can_position = false;
>>>>>>>>>>>  	int ret;
>>>>>>>>>>>  	uint32_t pixel_format = 0;
>>>>>>>>>>> +	struct drm_plane_state *plane_state = &state->base;
>>>>>>>>>>> +	struct drm_rect *src = &plane_state->src;
>>>>>>>>>>> +
>>>>>>>>>>> +	*src = drm_plane_state_src(plane_state);
>>>>>>>>>>>
>>>>>>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
>>>>>>>>>>>  		/* use scaler when colorkey is not required */ @@ -
>>>>> 13001,6
>>>>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
>>>>> *plane,
>>>>>>>>>>>  	if (!state->base.fb)
>>>>>>>>>>>  		return 0;
>>>>>>>>>>>
>>>>>>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
>>>>>>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
>>>>>>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
>>>>>>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
>>>>>>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
>>>>>>>>>>> +	}
>>>>>>>>>> Lets reject non multiple of 4 coordinates for plane_state's
>>>>>>>>>> src_x and src_y, and before adjustment also reject non multiple
>>>>>>>>>> of 4 src_w/src_h.fter that we can also reject clipping to the
>>>>>>>>>> right/bottom edge of the screen, if the pipe_src_w/h is not a
>>>>>>>>>> multiple of 4. That way an application trying to go beyond the
>>>> screen.
>>>>>>>>> kms_plane_scaling and some other tests during execution generate
>>>>>>>>> lots of non mult of 4 buffer width/height. All these tests will
>>>>>>>>> show fail in the IGT BAT.
>>>>>>>>> In some cases, even thought the width and height will be
>>>>>>>>> multiple of
>>>>>>>>> 4 before the Adjustment (say our 16x16 buffer), this after
>>>>>>>>> adjustment becomes a 15 in intel_check_sprite_plane.
>>>>>>>>> This again would cause underrun. If we reject non multiple of 4s
>>>>>>>>> in our skl_update_scaler also, then even simple tests with 16x16
>>>>>>>>> like rotation will fail due to it getting adjusted.
>>>>>>> Correct. This is why we fix up to a multiple of 4 after
>>>>>>> adjustments, and reject user passed coordinates before adjustment..
>>>>>>> plane_state->src_x/y/w/h is the property set by the user, while
>>>>>>> the plane_state->src rect is set and fixed up in the kernel.
>>>>>>>
>>>>>>> Rejecting clipping with positive coordinates if pipe_src w/h is
>>>>>>> not a multiple of 4 will fix a border case that shouldn't affect
>>>>>>> most modes, where the plane wouldn't extend to the crtc borders,
>>>>>>> which is
>>>>> what userspace wants there.
>>>>>> Thank you. Oh okay. Sorry. I thought we just reject and not do the
>>>>>> fixing
>>>>> (mult of 4 later).
>>>>>> Sure, I will change the patch to also reject the coordinates before
>>>>>> adjustment (if its not Mult of 4).
>>>>>>
>>>>>>
>>>>> This can be done in skl_check_plane_surface,
>>>>> plane_state->src_{x,y,w,h} contains the user requested values.
>>>> Apologies for asking again. The adjustments are done in check_plane
>>>> (both primary and sprite) And towards the end of check_plane we call
>>>> the skl_check_plane_surface.
>>>> I got your point that we will reject the user requested values if
>>>> they are not multiple of 4.
>>>> But before we reach skl_check_plane_surface, they would’ve been
>>>> adjusted/clipped etc They wont remain user requested as is when they
>>>> enter skl_check_plane_surface.
>>>> Please correct me if I am wrong or I am missing in understanding
>>>> something here :(
>>>>
>>>> I can add the add conversion to multiple of 4 in
>>>> skl_check_plane_surface but rejection should be done before the
>>>> clipping/adjustment Or else, I move the entire clipping/adjustment code
>> to skl_check_plane_surface?
>>> Sorry, I got it. You said, we don’t do adjustments in case of NV12 in
>>> sprite and move The handling to skl_check_plane_surface. I will do the
>> change and submit. Sorry.
>>> Thank you.
>>>
>> Something like below? Untested..
>> We should probably also restrict NV12 fb creation to not allow CCS formats.
>>
>> ~Maarten
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 4b3735720fee..c5da30c7ad04 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3090,6 +3090,38 @@ 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;
>> +
>> +	/* Are the unadjusted coordinates passed in valid? */
>> +	if ((plane_state->base.src_x >> 16) % 4 ||
>> +	    (plane_state->base.src_y >> 16) % 4 ||
>> +	    (plane_state->base.src_w >> 16) % 4 ||
>> +	    (plane_state->base.src_h >> 16) % 4) {
>> +		DRM_DEBUG_KMS("Source coordinates must be a 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;
>> +	}
>> +
>> +	/* Make adjusted src coordinates a multiple of 4. */
>> +	plane_state->base.src.x1 = DIV_ROUND_CLOSEST(plane_state-
>>> base.src.x1, 1 << 18) << 18;
>> +	plane_state->base.src.y1 = DIV_ROUND_CLOSEST(plane_state-
>>> base.src.y1, 1 << 18) << 18;
>> +	plane_state->base.src.x2 = DIV_ROUND_CLOSEST(plane_state-
>>> base.src.x2, 1 << 18) << 18;
>> +	plane_state->base.src.y2 = DIV_ROUND_CLOSEST(plane_state-
>>> base.src.y2, 1 << 18) << 18;
>> +	return 0;
>> +}
>> +
> Thank you so much :) Only one problem. The primary plane clipping
> happens inside the drm layer in drm_atomic_helper_check_plane_state
> So, clipping-clamping test passes coordinates 0, 257, 0, 159 to check_plane.
> And there before adjusting we reject. So for primary alone, can I retain 
> the make multiple of 4 code in primary itself?

The clipping affects plane_state->src.{x1, y1, x2, y2}, not plane_state->src_{x,y,w,h}.
They're different. The last set of coordinates will not be rotated or anything, the
first set of coordinates are what we end up programming into the hardware. The patch
I put above should be correctly rounding to a multiple of 4. :)

~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:32 PM
> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> >
> >> -----Original Message-----
> >> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 3:04 PM
> >> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> >> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> >>>> -----Original Message-----
> >>>> From: Srinivas, Vidya
> >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> >>>> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>;
> >>>> Saarinen, Jani <jani.saarinen@intel.com>;
> >>>> intel-gfx@lists.freedesktop.org
> >>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>> for
> >>>> NV12
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> >>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> >>>>> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> >>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>>> for
> >>>>> NV12
> >>>>>
> >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >>>>>>> -----Original Message-----
> >>>>>>> From: Maarten Lankhorst
> >>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> >>>>>>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
> >>>>>>> <vidya.srinivas@intel.com>;
> >>>>>>> intel-gfx-trybot@lists.freedesktop.org;
> >>>>>>> intel- gfx@lists.freedesktop.org
> >>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>> adjustments for
> >>>>>>> NV12
> >>>>>>>
> >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>>>>>>> Lets move this to intel-gfx to get more eyes on it.
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Srinivas, Vidya
> >>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>>>>>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
> >>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
> >>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>>>>>>>> <jani.saarinen@intel.com>
> >>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>>> adjustments for NV12
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Maarten Lankhorst
> >>>>>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> >>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> >>>>>>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
> >>>>>>>>>> trybot@lists.freedesktop.org
> >>>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>>>>>>>>> <jani.saarinen@intel.com>
> >>>>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>>>> adjustments for
> >>>>>>>>>> NV12
> >>>>>>>>>>
> >>>>>>>>>> Hmm, more thought about src adjustments...
> >>>>>>>>>>
> >>>>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>> Credits-to: Maarten Lankhorst
> >>>>>>>>>>> <maarten.lankhorst@linux.intel.com>
> >>>>>>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> >>>>>>>>>>> ---
> >>>>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> >>>>>>>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
> >>>>>>>>>>>  2 files changed, 26 insertions(+)
> >>>>>>>>>>>
> >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> index bc83f10..f64708f 100644
> >>>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> @@ -12978,6 +12978,10 @@
> intel_check_primary_plane(struct
> >>>>>>>>>> intel_plane *plane,
> >>>>>>>>>>>  	bool can_position = false;
> >>>>>>>>>>>  	int ret;
> >>>>>>>>>>>  	uint32_t pixel_format = 0;
> >>>>>>>>>>> +	struct drm_plane_state *plane_state = &state->base;
> >>>>>>>>>>> +	struct drm_rect *src = &plane_state->src;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	*src = drm_plane_state_src(plane_state);
> >>>>>>>>>>>
> >>>>>>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> >>>>>>>>>>>  		/* use scaler when colorkey is not required */ @@ -
> >>>>> 13001,6
> >>>>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> >>>>> *plane,
> >>>>>>>>>>>  	if (!state->base.fb)
> >>>>>>>>>>>  		return 0;
> >>>>>>>>>>>
> >>>>>>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> >>>>>>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +	}
> >>>>>>>>>> Lets reject non multiple of 4 coordinates for plane_state's
> >>>>>>>>>> src_x and src_y, and before adjustment also reject non
> >>>>>>>>>> multiple of 4 src_w/src_h.fter that we can also reject
> >>>>>>>>>> clipping to the right/bottom edge of the screen, if the
> >>>>>>>>>> pipe_src_w/h is not a multiple of 4. That way an application
> >>>>>>>>>> trying to go beyond the
> >>>> screen.
> >>>>>>>>> kms_plane_scaling and some other tests during execution
> >>>>>>>>> generate lots of non mult of 4 buffer width/height. All these
> >>>>>>>>> tests will show fail in the IGT BAT.
> >>>>>>>>> In some cases, even thought the width and height will be
> >>>>>>>>> multiple of
> >>>>>>>>> 4 before the Adjustment (say our 16x16 buffer), this after
> >>>>>>>>> adjustment becomes a 15 in intel_check_sprite_plane.
> >>>>>>>>> This again would cause underrun. If we reject non multiple of
> >>>>>>>>> 4s in our skl_update_scaler also, then even simple tests with
> >>>>>>>>> 16x16 like rotation will fail due to it getting adjusted.
> >>>>>>> Correct. This is why we fix up to a multiple of 4 after
> >>>>>>> adjustments, and reject user passed coordinates before
> adjustment..
> >>>>>>> plane_state->src_x/y/w/h is the property set by the user, while
> >>>>>>> the plane_state->src rect is set and fixed up in the kernel.
> >>>>>>>
> >>>>>>> Rejecting clipping with positive coordinates if pipe_src w/h is
> >>>>>>> not a multiple of 4 will fix a border case that shouldn't affect
> >>>>>>> most modes, where the plane wouldn't extend to the crtc borders,
> >>>>>>> which is
> >>>>> what userspace wants there.
> >>>>>> Thank you. Oh okay. Sorry. I thought we just reject and not do
> >>>>>> the fixing
> >>>>> (mult of 4 later).
> >>>>>> Sure, I will change the patch to also reject the coordinates
> >>>>>> before adjustment (if its not Mult of 4).
> >>>>>>
> >>>>>>
> >>>>> This can be done in skl_check_plane_surface,
> >>>>> plane_state->src_{x,y,w,h} contains the user requested values.
> >>>> Apologies for asking again. The adjustments are done in check_plane
> >>>> (both primary and sprite) And towards the end of check_plane we
> >>>> call the skl_check_plane_surface.
> >>>> I got your point that we will reject the user requested values if
> >>>> they are not multiple of 4.
> >>>> But before we reach skl_check_plane_surface, they would’ve been
> >>>> adjusted/clipped etc They wont remain user requested as is when
> >>>> they enter skl_check_plane_surface.
> >>>> Please correct me if I am wrong or I am missing in understanding
> >>>> something here :(
> >>>>
> >>>> I can add the add conversion to multiple of 4 in
> >>>> skl_check_plane_surface but rejection should be done before the
> >>>> clipping/adjustment Or else, I move the entire clipping/adjustment
> >>>> code
> >> to skl_check_plane_surface?
> >>> Sorry, I got it. You said, we don’t do adjustments in case of NV12
> >>> in sprite and move The handling to skl_check_plane_surface. I will
> >>> do the
> >> change and submit. Sorry.
> >>> Thank you.
> >>>
> >> Something like below? Untested..
> >> We should probably also restrict NV12 fb creation to not allow CCS
> formats.
> >>
> >> ~Maarten
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 4b3735720fee..c5da30c7ad04 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -3090,6 +3090,38 @@ 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;
> >> +
> >> +	/* Are the unadjusted coordinates passed in valid? */
> >> +	if ((plane_state->base.src_x >> 16) % 4 ||
> >> +	    (plane_state->base.src_y >> 16) % 4 ||
> >> +	    (plane_state->base.src_w >> 16) % 4 ||
> >> +	    (plane_state->base.src_h >> 16) % 4) {
> >> +		DRM_DEBUG_KMS("Source coordinates must be a 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;
> >> +	}
> >> +
> >> +	/* Make adjusted src coordinates a multiple of 4. */
> >> +	plane_state->base.src.x1 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.x1, 1 << 18) << 18;
> >> +	plane_state->base.src.y1 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.y1, 1 << 18) << 18;
> >> +	plane_state->base.src.x2 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.x2, 1 << 18) << 18;
> >> +	plane_state->base.src.y2 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.y2, 1 << 18) << 18;
> >> +	return 0;
> >> +}
> >> +
> > Thank you so much :) Only one problem. The primary plane clipping
> > happens inside the drm layer in drm_atomic_helper_check_plane_state
> > So, clipping-clamping test passes coordinates 0, 257, 0, 159 to
> check_plane.
> > And there before adjusting we reject. So for primary alone, can I
> > retain the make multiple of 4 code in primary itself?
> 
> The clipping affects plane_state->src.{x1, y1, x2, y2}, not plane_state-
> >src_{x,y,w,h}.
> They're different. The last set of coordinates will not be rotated or anything,
> the first set of coordinates are what we end up programming into the
> hardware. The patch I put above should be correctly rounding to a multiple
> of 4. :)

Oh sorry. I will put this patch. Thanks so much.

> 
> ~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:32 PM
> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> >
> >> -----Original Message-----
> >> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 3:04 PM
> >> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> >> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> >>>> -----Original Message-----
> >>>> From: Srinivas, Vidya
> >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> >>>> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>;
> >>>> Saarinen, Jani <jani.saarinen@intel.com>;
> >>>> intel-gfx@lists.freedesktop.org
> >>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>> for
> >>>> NV12
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> >>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> >>>>> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> >>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>>> for
> >>>>> NV12
> >>>>>
> >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >>>>>>> -----Original Message-----
> >>>>>>> From: Maarten Lankhorst
> >>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> >>>>>>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
> >>>>>>> <vidya.srinivas@intel.com>;
> >>>>>>> intel-gfx-trybot@lists.freedesktop.org;
> >>>>>>> intel- gfx@lists.freedesktop.org
> >>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>> adjustments for
> >>>>>>> NV12
> >>>>>>>
> >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>>>>>>> Lets move this to intel-gfx to get more eyes on it.
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Srinivas, Vidya
> >>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>>>>>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
> >>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
> >>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>>>>>>>> <jani.saarinen@intel.com>
> >>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>>> adjustments for NV12
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Maarten Lankhorst
> >>>>>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> >>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> >>>>>>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
> >>>>>>>>>> trybot@lists.freedesktop.org
> >>>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>>>>>>>>> <jani.saarinen@intel.com>
> >>>>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>>>> adjustments for
> >>>>>>>>>> NV12
> >>>>>>>>>>
> >>>>>>>>>> Hmm, more thought about src adjustments...
> >>>>>>>>>>
> >>>>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>> Credits-to: Maarten Lankhorst
> >>>>>>>>>>> <maarten.lankhorst@linux.intel.com>
> >>>>>>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> >>>>>>>>>>> ---
> >>>>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> >>>>>>>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
> >>>>>>>>>>>  2 files changed, 26 insertions(+)
> >>>>>>>>>>>
> >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> index bc83f10..f64708f 100644
> >>>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> @@ -12978,6 +12978,10 @@
> intel_check_primary_plane(struct
> >>>>>>>>>> intel_plane *plane,
> >>>>>>>>>>>  	bool can_position = false;
> >>>>>>>>>>>  	int ret;
> >>>>>>>>>>>  	uint32_t pixel_format = 0;
> >>>>>>>>>>> +	struct drm_plane_state *plane_state = &state->base;
> >>>>>>>>>>> +	struct drm_rect *src = &plane_state->src;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	*src = drm_plane_state_src(plane_state);
> >>>>>>>>>>>
> >>>>>>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> >>>>>>>>>>>  		/* use scaler when colorkey is not required */ @@ -
> >>>>> 13001,6
> >>>>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> >>>>> *plane,
> >>>>>>>>>>>  	if (!state->base.fb)
> >>>>>>>>>>>  		return 0;
> >>>>>>>>>>>
> >>>>>>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> >>>>>>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +	}
> >>>>>>>>>> Lets reject non multiple of 4 coordinates for plane_state's
> >>>>>>>>>> src_x and src_y, and before adjustment also reject non
> >>>>>>>>>> multiple of 4 src_w/src_h.fter that we can also reject
> >>>>>>>>>> clipping to the right/bottom edge of the screen, if the
> >>>>>>>>>> pipe_src_w/h is not a multiple of 4. That way an application
> >>>>>>>>>> trying to go beyond the
> >>>> screen.
> >>>>>>>>> kms_plane_scaling and some other tests during execution
> >>>>>>>>> generate lots of non mult of 4 buffer width/height. All these
> >>>>>>>>> tests will show fail in the IGT BAT.
> >>>>>>>>> In some cases, even thought the width and height will be
> >>>>>>>>> multiple of
> >>>>>>>>> 4 before the Adjustment (say our 16x16 buffer), this after
> >>>>>>>>> adjustment becomes a 15 in intel_check_sprite_plane.
> >>>>>>>>> This again would cause underrun. If we reject non multiple of
> >>>>>>>>> 4s in our skl_update_scaler also, then even simple tests with
> >>>>>>>>> 16x16 like rotation will fail due to it getting adjusted.
> >>>>>>> Correct. This is why we fix up to a multiple of 4 after
> >>>>>>> adjustments, and reject user passed coordinates before
> adjustment..
> >>>>>>> plane_state->src_x/y/w/h is the property set by the user, while
> >>>>>>> the plane_state->src rect is set and fixed up in the kernel.
> >>>>>>>
> >>>>>>> Rejecting clipping with positive coordinates if pipe_src w/h is
> >>>>>>> not a multiple of 4 will fix a border case that shouldn't affect
> >>>>>>> most modes, where the plane wouldn't extend to the crtc borders,
> >>>>>>> which is
> >>>>> what userspace wants there.
> >>>>>> Thank you. Oh okay. Sorry. I thought we just reject and not do
> >>>>>> the fixing
> >>>>> (mult of 4 later).
> >>>>>> Sure, I will change the patch to also reject the coordinates
> >>>>>> before adjustment (if its not Mult of 4).
> >>>>>>
> >>>>>>
> >>>>> This can be done in skl_check_plane_surface,
> >>>>> plane_state->src_{x,y,w,h} contains the user requested values.
> >>>> Apologies for asking again. The adjustments are done in check_plane
> >>>> (both primary and sprite) And towards the end of check_plane we
> >>>> call the skl_check_plane_surface.
> >>>> I got your point that we will reject the user requested values if
> >>>> they are not multiple of 4.
> >>>> But before we reach skl_check_plane_surface, they would’ve been
> >>>> adjusted/clipped etc They wont remain user requested as is when
> >>>> they enter skl_check_plane_surface.
> >>>> Please correct me if I am wrong or I am missing in understanding
> >>>> something here :(
> >>>>
> >>>> I can add the add conversion to multiple of 4 in
> >>>> skl_check_plane_surface but rejection should be done before the
> >>>> clipping/adjustment Or else, I move the entire clipping/adjustment
> >>>> code
> >> to skl_check_plane_surface?
> >>> Sorry, I got it. You said, we don’t do adjustments in case of NV12
> >>> in sprite and move The handling to skl_check_plane_surface. I will
> >>> do the
> >> change and submit. Sorry.
> >>> Thank you.
> >>>
> >> Something like below? Untested..
> >> We should probably also restrict NV12 fb creation to not allow CCS
> formats.

Thank you so much. Have submitted the changes to trybot
https://patchwork.freedesktop.org/series/41532/
PS: fb creation to not allow CCS - not done in this series

Regards
Vidya

> >>
> >> ~Maarten
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 4b3735720fee..c5da30c7ad04 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -3090,6 +3090,38 @@ 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;
> >> +
> >> +	/* Are the unadjusted coordinates passed in valid? */
> >> +	if ((plane_state->base.src_x >> 16) % 4 ||
> >> +	    (plane_state->base.src_y >> 16) % 4 ||
> >> +	    (plane_state->base.src_w >> 16) % 4 ||
> >> +	    (plane_state->base.src_h >> 16) % 4) {
> >> +		DRM_DEBUG_KMS("Source coordinates must be a 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;
> >> +	}
> >> +
> >> +	/* Make adjusted src coordinates a multiple of 4. */
> >> +	plane_state->base.src.x1 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.x1, 1 << 18) << 18;
> >> +	plane_state->base.src.y1 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.y1, 1 << 18) << 18;
> >> +	plane_state->base.src.x2 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.x2, 1 << 18) << 18;
> >> +	plane_state->base.src.y2 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.y2, 1 << 18) << 18;
> >> +	return 0;
> >> +}
> >> +
> > Thank you so much :) Only one problem. The primary plane clipping
> > happens inside the drm layer in drm_atomic_helper_check_plane_state
> > So, clipping-clamping test passes coordinates 0, 257, 0, 159 to
> check_plane.
> > And there before adjusting we reject. So for primary alone, can I
> > retain the make multiple of 4 code in primary itself?
> 
> The clipping affects plane_state->src.{x1, y1, x2, y2}, not plane_state-
> >src_{x,y,w,h}.
> They're different. The last set of coordinates will not be rotated or anything,
> the first set of coordinates are what we end up programming into the
> hardware. The patch I put above should be correctly rounding to a multiple
> of 4. :)
> 
> ~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Saarinen, Jani]

HI, 
> -----Original Message-----
> From: Srinivas, Vidya
> Sent: tiistai 17. huhtikuuta 2018 13.49
> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; Saarinen, Jani
> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> 
> 
> 
> > -----Original Message-----
> > From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> > Sent: Tuesday, April 17, 2018 3:32 PM
> > To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> > <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> > NV12
> >
> > Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> > >
> > >> -----Original Message-----
> > >> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> > >> Sent: Tuesday, April 17, 2018 3:04 PM
> > >> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> > >> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > >> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > >> for
> > >> NV12
> > >>
> > >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> > >>>> -----Original Message-----
> > >>>> From: Srinivas, Vidya
> > >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> > >>>> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>;
> > >>>> Saarinen, Jani <jani.saarinen@intel.com>;
> > >>>> intel-gfx@lists.freedesktop.org
> > >>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > >>>> adjustments for
> > >>>> NV12
> > >>>>
> > >>>>
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Maarten Lankhorst
> > >>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> > >>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> > >>>>> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > >>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > >>>>> adjustments for
> > >>>>> NV12
> > >>>>>
> > >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: Maarten Lankhorst
> > >>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> > >>>>>>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
> > >>>>>>> <vidya.srinivas@intel.com>;
> > >>>>>>> intel-gfx-trybot@lists.freedesktop.org;
> > >>>>>>> intel- gfx@lists.freedesktop.org
> > >>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > >>>>>>> adjustments for
> > >>>>>>> NV12
> > >>>>>>>
> > >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > >>>>>>>> Lets move this to intel-gfx to get more eyes on it.
> > >>>>>>>>
> > >>>>>>>>> -----Original Message-----
> > >>>>>>>>> From: Srinivas, Vidya
> > >>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> > >>>>>>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
> > >>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
> > >>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> > >>>>>>>>> <jani.saarinen@intel.com>
> > >>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > >>>>>>>>> adjustments for NV12
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> -----Original Message-----
> > >>>>>>>>>> From: Maarten Lankhorst
> > >>>>>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > >>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> > >>>>>>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
> > >>>>>>>>>> trybot@lists.freedesktop.org
> > >>>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> > >>>>>>>>>> <jani.saarinen@intel.com>
> > >>>>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > >>>>>>>>>> adjustments for
> > >>>>>>>>>> NV12
> > >>>>>>>>>>
> > >>>>>>>>>> Hmm, more thought about src adjustments...
> > >>>>>>>>>>
> > >>>>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> > >>>>>>>>>>> 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
> > >>>>>>>>>>>
> > >>>>>>>>>>> Credits-to: Maarten Lankhorst
> > >>>>>>>>>>> <maarten.lankhorst@linux.intel.com>
> > >>>>>>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> > >>>>>>>>>>> ---
> > >>>>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> > >>>>>>>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15
> +++++++++++++++
> > >>>>>>>>>>>  2 files changed, 26 insertions(+)
> > >>>>>>>>>>>
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > >>>>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
> > >>>>>>>>>>> index bc83f10..f64708f 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> > >>>>>>>>>>> @@ -12978,6 +12978,10 @@
> > intel_check_primary_plane(struct
> > >>>>>>>>>> intel_plane *plane,
> > >>>>>>>>>>>  	bool can_position = false;
> > >>>>>>>>>>>  	int ret;
> > >>>>>>>>>>>  	uint32_t pixel_format = 0;
> > >>>>>>>>>>> +	struct drm_plane_state *plane_state = &state-
> >base;
> > >>>>>>>>>>> +	struct drm_rect *src = &plane_state->src;
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	*src = drm_plane_state_src(plane_state);
> > >>>>>>>>>>>
> > >>>>>>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> > >>>>>>>>>>>  		/* use scaler when colorkey is not required
> */ @@ -
> > >>>>> 13001,6
> > >>>>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct
> intel_plane
> > >>>>> *plane,
> > >>>>>>>>>>>  	if (!state->base.fb)
> > >>>>>>>>>>>  		return 0;
> > >>>>>>>>>>>
> > >>>>>>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> > >>>>>>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > >>>>>>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > >>>>>>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > >>>>>>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > >>>>>>>>>>> +	}
> > >>>>>>>>>> Lets reject non multiple of 4 coordinates for plane_state's
> > >>>>>>>>>> src_x and src_y, and before adjustment also reject non
> > >>>>>>>>>> multiple of 4 src_w/src_h.fter that we can also reject
> > >>>>>>>>>> clipping to the right/bottom edge of the screen, if the
> > >>>>>>>>>> pipe_src_w/h is not a multiple of 4. That way an
> > >>>>>>>>>> application trying to go beyond the
> > >>>> screen.
> > >>>>>>>>> kms_plane_scaling and some other tests during execution
> > >>>>>>>>> generate lots of non mult of 4 buffer width/height. All
> > >>>>>>>>> these tests will show fail in the IGT BAT.
> > >>>>>>>>> In some cases, even thought the width and height will be
> > >>>>>>>>> multiple of
> > >>>>>>>>> 4 before the Adjustment (say our 16x16 buffer), this after
> > >>>>>>>>> adjustment becomes a 15 in intel_check_sprite_plane.
> > >>>>>>>>> This again would cause underrun. If we reject non multiple
> > >>>>>>>>> of 4s in our skl_update_scaler also, then even simple tests
> > >>>>>>>>> with
> > >>>>>>>>> 16x16 like rotation will fail due to it getting adjusted.
> > >>>>>>> Correct. This is why we fix up to a multiple of 4 after
> > >>>>>>> adjustments, and reject user passed coordinates before
> > adjustment..
> > >>>>>>> plane_state->src_x/y/w/h is the property set by the user,
> > >>>>>>> while the plane_state->src rect is set and fixed up in the kernel.
> > >>>>>>>
> > >>>>>>> Rejecting clipping with positive coordinates if pipe_src w/h
> > >>>>>>> is not a multiple of 4 will fix a border case that shouldn't
> > >>>>>>> affect most modes, where the plane wouldn't extend to the crtc
> > >>>>>>> borders, which is
> > >>>>> what userspace wants there.
> > >>>>>> Thank you. Oh okay. Sorry. I thought we just reject and not do
> > >>>>>> the fixing
> > >>>>> (mult of 4 later).
> > >>>>>> Sure, I will change the patch to also reject the coordinates
> > >>>>>> before adjustment (if its not Mult of 4).
> > >>>>>>
> > >>>>>>
> > >>>>> This can be done in skl_check_plane_surface,
> > >>>>> plane_state->src_{x,y,w,h} contains the user requested values.
> > >>>> Apologies for asking again. The adjustments are done in
> > >>>> check_plane (both primary and sprite) And towards the end of
> > >>>> check_plane we call the skl_check_plane_surface.
> > >>>> I got your point that we will reject the user requested values if
> > >>>> they are not multiple of 4.
> > >>>> But before we reach skl_check_plane_surface, they would’ve been
> > >>>> adjusted/clipped etc They wont remain user requested as is when
> > >>>> they enter skl_check_plane_surface.
> > >>>> Please correct me if I am wrong or I am missing in understanding
> > >>>> something here :(
> > >>>>
> > >>>> I can add the add conversion to multiple of 4 in
> > >>>> skl_check_plane_surface but rejection should be done before the
> > >>>> clipping/adjustment Or else, I move the entire
> > >>>> clipping/adjustment code
> > >> to skl_check_plane_surface?
> > >>> Sorry, I got it. You said, we don’t do adjustments in case of NV12
> > >>> in sprite and move The handling to skl_check_plane_surface. I will
> > >>> do the
> > >> change and submit. Sorry.
> > >>> Thank you.
> > >>>
> > >> Something like below? Untested..
> > >> We should probably also restrict NV12 fb creation to not allow CCS
> > formats.
> 
> Thank you so much. Have submitted the changes to trybot
> https://patchwork.freedesktop.org/series/41532/
> PS: fb creation to not allow CCS - not done in this series
Why not directly to intel-gfx? 


> 
> Regards
> Vidya
> 
> > >>
> > >> ~Maarten
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > >> b/drivers/gpu/drm/i915/intel_display.c
> > >> index 4b3735720fee..c5da30c7ad04 100644
> > >> --- a/drivers/gpu/drm/i915/intel_display.c
> > >> +++ b/drivers/gpu/drm/i915/intel_display.c
> > >> @@ -3090,6 +3090,38 @@ 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;
> > >> +
> > >> +	/* Are the unadjusted coordinates passed in valid? */
> > >> +	if ((plane_state->base.src_x >> 16) % 4 ||
> > >> +	    (plane_state->base.src_y >> 16) % 4 ||
> > >> +	    (plane_state->base.src_w >> 16) % 4 ||
> > >> +	    (plane_state->base.src_h >> 16) % 4) {
> > >> +		DRM_DEBUG_KMS("Source coordinates must be a 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;
> > >> +	}
> > >> +
> > >> +	/* Make adjusted src coordinates a multiple of 4. */
> > >> +	plane_state->base.src.x1 = DIV_ROUND_CLOSEST(plane_state-
> > >>> base.src.x1, 1 << 18) << 18;
> > >> +	plane_state->base.src.y1 = DIV_ROUND_CLOSEST(plane_state-
> > >>> base.src.y1, 1 << 18) << 18;
> > >> +	plane_state->base.src.x2 = DIV_ROUND_CLOSEST(plane_state-
> > >>> base.src.x2, 1 << 18) << 18;
> > >> +	plane_state->base.src.y2 = DIV_ROUND_CLOSEST(plane_state-
> > >>> base.src.y2, 1 << 18) << 18;
> > >> +	return 0;
> > >> +}
> > >> +
> > > Thank you so much :) Only one problem. The primary plane clipping
> > > happens inside the drm layer in drm_atomic_helper_check_plane_state
> > > So, clipping-clamping test passes coordinates 0, 257, 0, 159 to
> > check_plane.
> > > And there before adjusting we reject. So for primary alone, can I
> > > retain the make multiple of 4 code in primary itself?
> >
> > The clipping affects plane_state->src.{x1, y1, x2, y2}, not
> > plane_state-
> > >src_{x,y,w,h}.
> > They're different. The last set of coordinates will not be rotated or
> > anything, the first set of coordinates are what we end up programming
> > into the hardware. The patch I put above should be correctly rounding
> > to a multiple of 4. :)
> >
> > ~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Saarinen, Jani
> Sent: Tuesday, April 17, 2018 4:23 PM
> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> HI,
> > -----Original Message-----
> > From: Srinivas, Vidya
> > Sent: tiistai 17. huhtikuuta 2018 13.49
> > To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; Saarinen,
> > Jani <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> > NV12
> >
> >
> >
> > > -----Original Message-----
> > > From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> > > Sent: Tuesday, April 17, 2018 3:32 PM
> > > To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> > > <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > > for
> > > NV12
> > >
> > > Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> > > >
> > > >> -----Original Message-----
> > > >> From: Maarten Lankhorst
> > > >> [mailto:maarten.lankhorst@linux.intel.com]
> > > >> Sent: Tuesday, April 17, 2018 3:04 PM
> > > >> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> > > >> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > > >> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > >> adjustments for
> > > >> NV12
> > > >>
> > > >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> > > >>>> -----Original Message-----
> > > >>>> From: Srinivas, Vidya
> > > >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> > > >>>> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>;
> > > >>>> Saarinen, Jani <jani.saarinen@intel.com>;
> > > >>>> intel-gfx@lists.freedesktop.org
> > > >>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > >>>> adjustments for
> > > >>>> NV12
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>> -----Original Message-----
> > > >>>>> From: Maarten Lankhorst
> > > >>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > > >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> > > >>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> > > >>>>> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > > >>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > >>>>> adjustments for
> > > >>>>> NV12
> > > >>>>>
> > > >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> > > >>>>>>> -----Original Message-----
> > > >>>>>>> From: Maarten Lankhorst
> > > >>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > > >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> > > >>>>>>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas,
> > > >>>>>>> Vidya <vidya.srinivas@intel.com>;
> > > >>>>>>> intel-gfx-trybot@lists.freedesktop.org;
> > > >>>>>>> intel- gfx@lists.freedesktop.org
> > > >>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > >>>>>>> adjustments for
> > > >>>>>>> NV12
> > > >>>>>>>
> > > >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > > >>>>>>>> Lets move this to intel-gfx to get more eyes on it.
> > > >>>>>>>>
> > > >>>>>>>>> -----Original Message-----
> > > >>>>>>>>> From: Srinivas, Vidya
> > > >>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> > > >>>>>>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
> > > >>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
> > > >>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> > > >>>>>>>>> <jani.saarinen@intel.com>
> > > >>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > >>>>>>>>> adjustments for NV12
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>> -----Original Message-----
> > > >>>>>>>>>> From: Maarten Lankhorst
> > > >>>>>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > > >>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> > > >>>>>>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>;
> > > >>>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
> > > >>>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen,
> > > >>>>>>>>>> Jani <jani.saarinen@intel.com>
> > > >>>>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > >>>>>>>>>> adjustments for
> > > >>>>>>>>>> NV12
> > > >>>>>>>>>>
> > > >>>>>>>>>> Hmm, more thought about src adjustments...
> > > >>>>>>>>>>
> > > >>>>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> > > >>>>>>>>>>> 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
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Credits-to: Maarten Lankhorst
> > > >>>>>>>>>>> <maarten.lankhorst@linux.intel.com>
> > > >>>>>>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> > > >>>>>>>>>>> ---
> > > >>>>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> > > >>>>>>>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15
> > +++++++++++++++
> > > >>>>>>>>>>>  2 files changed, 26 insertions(+)
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > >>>>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
> > > >>>>>>>>>>> index bc83f10..f64708f 100644
> > > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> > > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> > > >>>>>>>>>>> @@ -12978,6 +12978,10 @@
> > > intel_check_primary_plane(struct
> > > >>>>>>>>>> intel_plane *plane,
> > > >>>>>>>>>>>  	bool can_position = false;
> > > >>>>>>>>>>>  	int ret;
> > > >>>>>>>>>>>  	uint32_t pixel_format = 0;
> > > >>>>>>>>>>> +	struct drm_plane_state *plane_state = &state-
> > >base;
> > > >>>>>>>>>>> +	struct drm_rect *src = &plane_state->src;
> > > >>>>>>>>>>> +
> > > >>>>>>>>>>> +	*src = drm_plane_state_src(plane_state);
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> > > >>>>>>>>>>>  		/* use scaler when colorkey is not required
> > */ @@ -
> > > >>>>> 13001,6
> > > >>>>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct
> > intel_plane
> > > >>>>> *plane,
> > > >>>>>>>>>>>  	if (!state->base.fb)
> > > >>>>>>>>>>>  		return 0;
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> > > >>>>>>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > > >>>>>>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > > >>>>>>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > > >>>>>>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > > >>>>>>>>>>> +	}
> > > >>>>>>>>>> Lets reject non multiple of 4 coordinates for
> > > >>>>>>>>>> plane_state's src_x and src_y, and before adjustment also
> > > >>>>>>>>>> reject non multiple of 4 src_w/src_h.fter that we can
> > > >>>>>>>>>> also reject clipping to the right/bottom edge of the
> > > >>>>>>>>>> screen, if the pipe_src_w/h is not a multiple of 4. That
> > > >>>>>>>>>> way an application trying to go beyond the
> > > >>>> screen.
> > > >>>>>>>>> kms_plane_scaling and some other tests during execution
> > > >>>>>>>>> generate lots of non mult of 4 buffer width/height. All
> > > >>>>>>>>> these tests will show fail in the IGT BAT.
> > > >>>>>>>>> In some cases, even thought the width and height will be
> > > >>>>>>>>> multiple of
> > > >>>>>>>>> 4 before the Adjustment (say our 16x16 buffer), this after
> > > >>>>>>>>> adjustment becomes a 15 in intel_check_sprite_plane.
> > > >>>>>>>>> This again would cause underrun. If we reject non multiple
> > > >>>>>>>>> of 4s in our skl_update_scaler also, then even simple
> > > >>>>>>>>> tests with
> > > >>>>>>>>> 16x16 like rotation will fail due to it getting adjusted.
> > > >>>>>>> Correct. This is why we fix up to a multiple of 4 after
> > > >>>>>>> adjustments, and reject user passed coordinates before
> > > adjustment..
> > > >>>>>>> plane_state->src_x/y/w/h is the property set by the user,
> > > >>>>>>> while the plane_state->src rect is set and fixed up in the kernel.
> > > >>>>>>>
> > > >>>>>>> Rejecting clipping with positive coordinates if pipe_src w/h
> > > >>>>>>> is not a multiple of 4 will fix a border case that shouldn't
> > > >>>>>>> affect most modes, where the plane wouldn't extend to the
> > > >>>>>>> crtc borders, which is
> > > >>>>> what userspace wants there.
> > > >>>>>> Thank you. Oh okay. Sorry. I thought we just reject and not
> > > >>>>>> do the fixing
> > > >>>>> (mult of 4 later).
> > > >>>>>> Sure, I will change the patch to also reject the coordinates
> > > >>>>>> before adjustment (if its not Mult of 4).
> > > >>>>>>
> > > >>>>>>
> > > >>>>> This can be done in skl_check_plane_surface,
> > > >>>>> plane_state->src_{x,y,w,h} contains the user requested values.
> > > >>>> Apologies for asking again. The adjustments are done in
> > > >>>> check_plane (both primary and sprite) And towards the end of
> > > >>>> check_plane we call the skl_check_plane_surface.
> > > >>>> I got your point that we will reject the user requested values
> > > >>>> if they are not multiple of 4.
> > > >>>> But before we reach skl_check_plane_surface, they would’ve been
> > > >>>> adjusted/clipped etc They wont remain user requested as is when
> > > >>>> they enter skl_check_plane_surface.
> > > >>>> Please correct me if I am wrong or I am missing in
> > > >>>> understanding something here :(
> > > >>>>
> > > >>>> I can add the add conversion to multiple of 4 in
> > > >>>> skl_check_plane_surface but rejection should be done before the
> > > >>>> clipping/adjustment Or else, I move the entire
> > > >>>> clipping/adjustment code
> > > >> to skl_check_plane_surface?
> > > >>> Sorry, I got it. You said, we don’t do adjustments in case of
> > > >>> NV12 in sprite and move The handling to skl_check_plane_surface.
> > > >>> I will do the
> > > >> change and submit. Sorry.
> > > >>> Thank you.
> > > >>>
> > > >> Something like below? Untested..
> > > >> We should probably also restrict NV12 fb creation to not allow
> > > >> CCS
> > > formats.
> >
> > Thank you so much. Have submitted the changes to trybot
> > https://patchwork.freedesktop.org/series/41532/
> > PS: fb creation to not allow CCS - not done in this series
> Why not directly to intel-gfx?
Sure, I thought I had to send to trybot first. Will send it today.

Thanks
Vidya
> 
> 
> >
> > Regards
> > Vidya
> >
> > > >>
> > > >> ~Maarten
> > > >>
> > > >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > >> b/drivers/gpu/drm/i915/intel_display.c
> > > >> index 4b3735720fee..c5da30c7ad04 100644
> > > >> --- a/drivers/gpu/drm/i915/intel_display.c
> > > >> +++ b/drivers/gpu/drm/i915/intel_display.c
> > > >> @@ -3090,6 +3090,38 @@ 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;
> > > >> +
> > > >> +	/* Are the unadjusted coordinates passed in valid? */
> > > >> +	if ((plane_state->base.src_x >> 16) % 4 ||
> > > >> +	    (plane_state->base.src_y >> 16) % 4 ||
> > > >> +	    (plane_state->base.src_w >> 16) % 4 ||
> > > >> +	    (plane_state->base.src_h >> 16) % 4) {
> > > >> +		DRM_DEBUG_KMS("Source coordinates must be a
> 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;
> > > >> +	}
> > > >> +
> > > >> +	/* Make adjusted src coordinates a multiple of 4. */
> > > >> +	plane_state->base.src.x1 =
> DIV_ROUND_CLOSEST(plane_state-
> > > >>> base.src.x1, 1 << 18) << 18;
> > > >> +	plane_state->base.src.y1 =
> DIV_ROUND_CLOSEST(plane_state-
> > > >>> base.src.y1, 1 << 18) << 18;
> > > >> +	plane_state->base.src.x2 =
> DIV_ROUND_CLOSEST(plane_state-
> > > >>> base.src.x2, 1 << 18) << 18;
> > > >> +	plane_state->base.src.y2 =
> DIV_ROUND_CLOSEST(plane_state-
> > > >>> base.src.y2, 1 << 18) << 18;
> > > >> +	return 0;
> > > >> +}
> > > >> +
> > > > Thank you so much :) Only one problem. The primary plane clipping
> > > > happens inside the drm layer in
> > > > drm_atomic_helper_check_plane_state
> > > > So, clipping-clamping test passes coordinates 0, 257, 0, 159 to
> > > check_plane.
> > > > And there before adjusting we reject. So for primary alone, can I
> > > > retain the make multiple of 4 code in primary itself?
> > >
> > > The clipping affects plane_state->src.{x1, y1, x2, y2}, not
> > > plane_state-
> > > >src_{x,y,w,h}.
> > > They're different. The last set of coordinates will not be rotated
> > > or anything, the first set of coordinates are what we end up
> > > programming into the hardware. The patch I put above should be
> > > correctly rounding to a multiple of 4. :)
> > >
> > > ~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Saarinen, Jani]

Hi, 

> -----Original Message-----
> From: Srinivas, Vidya
> Sent: keskiviikko 18. huhtikuuta 2018 6.56
> To: Saarinen, Jani <jani.saarinen@intel.com>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> 
> 
> 
> > -----Original Message-----
> > From: Saarinen, Jani
> > Sent: Tuesday, April 17, 2018 4:23 PM
> > To: Srinivas, Vidya <vidya.srinivas@intel.com>; Maarten Lankhorst
> > <maarten.lankhorst@linux.intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> > NV12
> >
> > HI,
> > > -----Original Message-----
> > > From: Srinivas, Vidya
> > > Sent: tiistai 17. huhtikuuta 2018 13.49
> > > To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; Saarinen,
> > > Jani <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > > for
> > > NV12
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> > > > Sent: Tuesday, April 17, 2018 3:32 PM
> > > > To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> > > > <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > > > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > > > for
> > > > NV12
> > > >
> > > > Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Maarten Lankhorst
> > > > >> [mailto:maarten.lankhorst@linux.intel.com]
> > > > >> Sent: Tuesday, April 17, 2018 3:04 PM
> > > > >> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> > > > >> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > > > >> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > >> adjustments for
> > > > >> NV12
> > > > >>
> > > > >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> > > > >>>> -----Original Message-----
> > > > >>>> From: Srinivas, Vidya
> > > > >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> > > > >>>> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>;
> > > > >>>> Saarinen, Jani <jani.saarinen@intel.com>;
> > > > >>>> intel-gfx@lists.freedesktop.org
> > > > >>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > >>>> adjustments for
> > > > >>>> NV12
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>> -----Original Message-----
> > > > >>>>> From: Maarten Lankhorst
> > > > >>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > > > >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> > > > >>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen,
> > > > >>>>> Jani <jani.saarinen@intel.com>;
> > > > >>>>> intel-gfx@lists.freedesktop.org
> > > > >>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > >>>>> adjustments for
> > > > >>>>> NV12
> > > > >>>>>
> > > > >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> > > > >>>>>>> -----Original Message-----
> > > > >>>>>>> From: Maarten Lankhorst
> > > > >>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > > > >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> > > > >>>>>>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas,
> > > > >>>>>>> Vidya <vidya.srinivas@intel.com>;
> > > > >>>>>>> intel-gfx-trybot@lists.freedesktop.org;
> > > > >>>>>>> intel- gfx@lists.freedesktop.org
> > > > >>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > >>>>>>> adjustments for
> > > > >>>>>>> NV12
> > > > >>>>>>>
> > > > >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > > > >>>>>>>> Lets move this to intel-gfx to get more eyes on it.
> > > > >>>>>>>>
> > > > >>>>>>>>> -----Original Message-----
> > > > >>>>>>>>> From: Srinivas, Vidya
> > > > >>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> > > > >>>>>>>>> To: Maarten Lankhorst
> > > > >>>>>>>>> <maarten.lankhorst@linux.intel.com>;
> > > > >>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
> > > > >>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen,
> > > > >>>>>>>>> Jani <jani.saarinen@intel.com>
> > > > >>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > >>>>>>>>> adjustments for NV12
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>> -----Original Message-----
> > > > >>>>>>>>>> From: Maarten Lankhorst
> > > > >>>>>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > > > >>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> > > > >>>>>>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>;
> > > > >>>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
> > > > >>>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen,
> > > > >>>>>>>>>> Jani <jani.saarinen@intel.com>
> > > > >>>>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > >>>>>>>>>> adjustments for
> > > > >>>>>>>>>> NV12
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Hmm, more thought about src adjustments...
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> > > > >>>>>>>>>>> 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
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Credits-to: Maarten Lankhorst
> > > > >>>>>>>>>>> <maarten.lankhorst@linux.intel.com>
> > > > >>>>>>>>>>> Signed-off-by: Vidya Srinivas
> > > > >>>>>>>>>>> <vidya.srinivas@intel.com>
> > > > >>>>>>>>>>> ---
> > > > >>>>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> > > > >>>>>>>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15
> > > +++++++++++++++
> > > > >>>>>>>>>>>  2 files changed, 26 insertions(+)
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > >>>>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
> > > > >>>>>>>>>>> index bc83f10..f64708f 100644
> > > > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> > > > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > >>>>>>>>>>> @@ -12978,6 +12978,10 @@
> > > > intel_check_primary_plane(struct
> > > > >>>>>>>>>> intel_plane *plane,
> > > > >>>>>>>>>>>  	bool can_position = false;
> > > > >>>>>>>>>>>  	int ret;
> > > > >>>>>>>>>>>  	uint32_t pixel_format = 0;
> > > > >>>>>>>>>>> +	struct drm_plane_state *plane_state = &state-
> > > >base;
> > > > >>>>>>>>>>> +	struct drm_rect *src = &plane_state->src;
> > > > >>>>>>>>>>> +
> > > > >>>>>>>>>>> +	*src = drm_plane_state_src(plane_state);
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> > > > >>>>>>>>>>>  		/* use scaler when colorkey is not required
> > > */ @@ -
> > > > >>>>> 13001,6
> > > > >>>>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct
> > > intel_plane
> > > > >>>>> *plane,
> > > > >>>>>>>>>>>  	if (!state->base.fb)
> > > > >>>>>>>>>>>  		return 0;
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> > > > >>>>>>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > > > >>>>>>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > > > >>>>>>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > > > >>>>>>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > > > >>>>>>>>>>> +	}
> > > > >>>>>>>>>> Lets reject non multiple of 4 coordinates for
> > > > >>>>>>>>>> plane_state's src_x and src_y, and before adjustment
> > > > >>>>>>>>>> also reject non multiple of 4 src_w/src_h.fter that we
> > > > >>>>>>>>>> can also reject clipping to the right/bottom edge of
> > > > >>>>>>>>>> the screen, if the pipe_src_w/h is not a multiple of 4.
> > > > >>>>>>>>>> That way an application trying to go beyond the
> > > > >>>> screen.
> > > > >>>>>>>>> kms_plane_scaling and some other tests during execution
> > > > >>>>>>>>> generate lots of non mult of 4 buffer width/height. All
> > > > >>>>>>>>> these tests will show fail in the IGT BAT.
> > > > >>>>>>>>> In some cases, even thought the width and height will be
> > > > >>>>>>>>> multiple of
> > > > >>>>>>>>> 4 before the Adjustment (say our 16x16 buffer), this
> > > > >>>>>>>>> after adjustment becomes a 15 in
> intel_check_sprite_plane.
> > > > >>>>>>>>> This again would cause underrun. If we reject non
> > > > >>>>>>>>> multiple of 4s in our skl_update_scaler also, then even
> > > > >>>>>>>>> simple tests with
> > > > >>>>>>>>> 16x16 like rotation will fail due to it getting adjusted.
> > > > >>>>>>> Correct. This is why we fix up to a multiple of 4 after
> > > > >>>>>>> adjustments, and reject user passed coordinates before
> > > > adjustment..
> > > > >>>>>>> plane_state->src_x/y/w/h is the property set by the user,
> > > > >>>>>>> while the plane_state->src rect is set and fixed up in the
> kernel.
> > > > >>>>>>>
> > > > >>>>>>> Rejecting clipping with positive coordinates if pipe_src
> > > > >>>>>>> w/h is not a multiple of 4 will fix a border case that
> > > > >>>>>>> shouldn't affect most modes, where the plane wouldn't
> > > > >>>>>>> extend to the crtc borders, which is
> > > > >>>>> what userspace wants there.
> > > > >>>>>> Thank you. Oh okay. Sorry. I thought we just reject and not
> > > > >>>>>> do the fixing
> > > > >>>>> (mult of 4 later).
> > > > >>>>>> Sure, I will change the patch to also reject the
> > > > >>>>>> coordinates before adjustment (if its not Mult of 4).
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>> This can be done in skl_check_plane_surface,
> > > > >>>>> plane_state->src_{x,y,w,h} contains the user requested values.
> > > > >>>> Apologies for asking again. The adjustments are done in
> > > > >>>> check_plane (both primary and sprite) And towards the end of
> > > > >>>> check_plane we call the skl_check_plane_surface.
> > > > >>>> I got your point that we will reject the user requested
> > > > >>>> values if they are not multiple of 4.
> > > > >>>> But before we reach skl_check_plane_surface, they would’ve
> > > > >>>> been adjusted/clipped etc They wont remain user requested as
> > > > >>>> is when they enter skl_check_plane_surface.
> > > > >>>> Please correct me if I am wrong or I am missing in
> > > > >>>> understanding something here :(
> > > > >>>>
> > > > >>>> I can add the add conversion to multiple of 4 in
> > > > >>>> skl_check_plane_surface but rejection should be done before
> > > > >>>> the clipping/adjustment Or else, I move the entire
> > > > >>>> clipping/adjustment code
> > > > >> to skl_check_plane_surface?
> > > > >>> Sorry, I got it. You said, we don’t do adjustments in case of
> > > > >>> NV12 in sprite and move The handling to skl_check_plane_surface.
> > > > >>> I will do the
> > > > >> change and submit. Sorry.
> > > > >>> Thank you.
> > > > >>>
> > > > >> Something like below? Untested..
> > > > >> We should probably also restrict NV12 fb creation to not allow
> > > > >> CCS
> > > > formats.
> > >
> > > Thank you so much. Have submitted the changes to trybot
> > > https://patchwork.freedesktop.org/series/41532/
> > > PS: fb creation to not allow CCS - not done in this series
> > Why not directly to intel-gfx?
> Sure, I thought I had to send to trybot first. Will send it today.
I see trybot for patches as test for RFC to see if solution is even near satisfactory in the beginning but for patches that has sent several times no need to send to trybot. 



> 
> Thanks
> Vidya
> >
> >
> > >
> > > Regards
> > > Vidya
> > >
> > > > >>
> > > > >> ~Maarten
> > > > >>
> > > > >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > >> b/drivers/gpu/drm/i915/intel_display.c
> > > > >> index 4b3735720fee..c5da30c7ad04 100644
> > > > >> --- a/drivers/gpu/drm/i915/intel_display.c
> > > > >> +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > >> @@ -3090,6 +3090,38 @@ 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;
> > > > >> +
> > > > >> +	/* Are the unadjusted coordinates passed in valid? */
> > > > >> +	if ((plane_state->base.src_x >> 16) % 4 ||
> > > > >> +	    (plane_state->base.src_y >> 16) % 4 ||
> > > > >> +	    (plane_state->base.src_w >> 16) % 4 ||
> > > > >> +	    (plane_state->base.src_h >> 16) % 4) {
> > > > >> +		DRM_DEBUG_KMS("Source coordinates must be a
> > 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;
> > > > >> +	}
> > > > >> +
> > > > >> +	/* Make adjusted src coordinates a multiple of 4. */
> > > > >> +	plane_state->base.src.x1 =
> > DIV_ROUND_CLOSEST(plane_state-
> > > > >>> base.src.x1, 1 << 18) << 18;
> > > > >> +	plane_state->base.src.y1 =
> > DIV_ROUND_CLOSEST(plane_state-
> > > > >>> base.src.y1, 1 << 18) << 18;
> > > > >> +	plane_state->base.src.x2 =
> > DIV_ROUND_CLOSEST(plane_state-
> > > > >>> base.src.x2, 1 << 18) << 18;
> > > > >> +	plane_state->base.src.y2 =
> > DIV_ROUND_CLOSEST(plane_state-
> > > > >>> base.src.y2, 1 << 18) << 18;
> > > > >> +	return 0;
> > > > >> +}
> > > > >> +
> > > > > Thank you so much :) Only one problem. The primary plane
> > > > > clipping happens inside the drm layer in
> > > > > drm_atomic_helper_check_plane_state
> > > > > So, clipping-clamping test passes coordinates 0, 257, 0, 159 to
> > > > check_plane.
> > > > > And there before adjusting we reject. So for primary alone, can
> > > > > I retain the make multiple of 4 code in primary itself?
> > > >
> > > > The clipping affects plane_state->src.{x1, y1, x2, y2}, not
> > > > plane_state-
> > > > >src_{x,y,w,h}.
> > > > They're different. The last set of coordinates will not be rotated
> > > > or anything, the first set of coordinates are what we end up
> > > > programming into the hardware. The patch I put above should be
> > > > correctly rounding to a multiple of 4. :)
> > > >
> > > > ~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Saarinen, Jani
> Sent: Wednesday, April 18, 2018 11:07 AM
> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Hi,
> 
> > -----Original Message-----
> > From: Srinivas, Vidya
> > Sent: keskiviikko 18. huhtikuuta 2018 6.56
> > To: Saarinen, Jani <jani.saarinen@intel.com>; Maarten Lankhorst
> > <maarten.lankhorst@linux.intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> > NV12
> >
> >
> >
> > > -----Original Message-----
> > > From: Saarinen, Jani
> > > Sent: Tuesday, April 17, 2018 4:23 PM
> > > To: Srinivas, Vidya <vidya.srinivas@intel.com>; Maarten Lankhorst
> > > <maarten.lankhorst@linux.intel.com>; intel-gfx@lists.freedesktop.org
> > > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > > for
> > > NV12
> > >
> > > HI,
> > > > -----Original Message-----
> > > > From: Srinivas, Vidya
> > > > Sent: tiistai 17. huhtikuuta 2018 13.49
> > > > To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
> > > > Saarinen, Jani <jani.saarinen@intel.com>;
> > > > intel-gfx@lists.freedesktop.org
> > > > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> > > > for
> > > > NV12
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Maarten Lankhorst
> > > > > [mailto:maarten.lankhorst@linux.intel.com]
> > > > > Sent: Tuesday, April 17, 2018 3:32 PM
> > > > > To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> > > > > <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> > > > > Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > > adjustments for
> > > > > NV12
> > > > >
> > > > > Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: Maarten Lankhorst
> > > > > >> [mailto:maarten.lankhorst@linux.intel.com]
> > > > > >> Sent: Tuesday, April 17, 2018 3:04 PM
> > > > > >> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen,
> > > > > >> Jani <jani.saarinen@intel.com>;
> > > > > >> intel-gfx@lists.freedesktop.org
> > > > > >> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > > >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > > >> adjustments for
> > > > > >> NV12
> > > > > >>
> > > > > >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> > > > > >>>> -----Original Message-----
> > > > > >>>> From: Srinivas, Vidya
> > > > > >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> > > > > >>>> To: 'Maarten Lankhorst'
> > > > > >>>> <maarten.lankhorst@linux.intel.com>;
> > > > > >>>> Saarinen, Jani <jani.saarinen@intel.com>;
> > > > > >>>> intel-gfx@lists.freedesktop.org
> > > > > >>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > > >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > > >>>> adjustments for
> > > > > >>>> NV12
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>> -----Original Message-----
> > > > > >>>>> From: Maarten Lankhorst
> > > > > >>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > > > > >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> > > > > >>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen,
> > > > > >>>>> Jani <jani.saarinen@intel.com>;
> > > > > >>>>> intel-gfx@lists.freedesktop.org
> > > > > >>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > > >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > > >>>>> adjustments for
> > > > > >>>>> NV12
> > > > > >>>>>
> > > > > >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> > > > > >>>>>>> -----Original Message-----
> > > > > >>>>>>> From: Maarten Lankhorst
> > > > > >>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > > > > >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> > > > > >>>>>>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas,
> > > > > >>>>>>> Vidya <vidya.srinivas@intel.com>;
> > > > > >>>>>>> intel-gfx-trybot@lists.freedesktop.org;
> > > > > >>>>>>> intel- gfx@lists.freedesktop.org
> > > > > >>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> > > > > >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > > >>>>>>> adjustments for
> > > > > >>>>>>> NV12
> > > > > >>>>>>>
> > > > > >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> > > > > >>>>>>>> Lets move this to intel-gfx to get more eyes on it.
> > > > > >>>>>>>>
> > > > > >>>>>>>>> -----Original Message-----
> > > > > >>>>>>>>> From: Srinivas, Vidya
> > > > > >>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> > > > > >>>>>>>>> To: Maarten Lankhorst
> > > > > >>>>>>>>> <maarten.lankhorst@linux.intel.com>;
> > > > > >>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
> > > > > >>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen,
> > > > > >>>>>>>>> Jani <jani.saarinen@intel.com>
> > > > > >>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> > > > > >>>>>>>>> adjustments for NV12
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> -----Original Message-----
> > > > > >>>>>>>>>> From: Maarten Lankhorst
> > > > > >>>>>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> > > > > >>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> > > > > >>>>>>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>;
> > > > > >>>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
> > > > > >>>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen,
> > > > > >>>>>>>>>> Jani <jani.saarinen@intel.com>
> > > > > >>>>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb
> > > > > >>>>>>>>>> src adjustments for
> > > > > >>>>>>>>>> NV12
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> Hmm, more thought about src adjustments...
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> > > > > >>>>>>>>>>> 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
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Credits-to: Maarten Lankhorst
> > > > > >>>>>>>>>>> <maarten.lankhorst@linux.intel.com>
> > > > > >>>>>>>>>>> Signed-off-by: Vidya Srinivas
> > > > > >>>>>>>>>>> <vidya.srinivas@intel.com>
> > > > > >>>>>>>>>>> ---
> > > > > >>>>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11
> > > > > >>>>>>>>>>> +++++++++++ drivers/gpu/drm/i915/intel_sprite.c  |
> > > > > >>>>>>>>>>> 15
> > > > +++++++++++++++
> > > > > >>>>>>>>>>>  2 files changed, 26 insertions(+)
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > > >>>>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
> > > > > >>>>>>>>>>> index bc83f10..f64708f 100644
> > > > > >>>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > >>>>>>>>>>> @@ -12978,6 +12978,10 @@
> > > > > intel_check_primary_plane(struct
> > > > > >>>>>>>>>> intel_plane *plane,
> > > > > >>>>>>>>>>>  	bool can_position = false;
> > > > > >>>>>>>>>>>  	int ret;
> > > > > >>>>>>>>>>>  	uint32_t pixel_format = 0;
> > > > > >>>>>>>>>>> +	struct drm_plane_state *plane_state = &state-
> > > > >base;
> > > > > >>>>>>>>>>> +	struct drm_rect *src = &plane_state->src;
> > > > > >>>>>>>>>>> +
> > > > > >>>>>>>>>>> +	*src = drm_plane_state_src(plane_state);
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> > > > > >>>>>>>>>>>  		/* use scaler when colorkey is not required
> > > > */ @@ -
> > > > > >>>>> 13001,6
> > > > > >>>>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct
> > > > intel_plane
> > > > > >>>>> *plane,
> > > > > >>>>>>>>>>>  	if (!state->base.fb)
> > > > > >>>>>>>>>>>  		return 0;
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> > > > > >>>>>>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> > > > > >>>>>>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> > > > > >>>>>>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> > > > > >>>>>>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> > > > > >>>>>>>>>>> +	}
> > > > > >>>>>>>>>> Lets reject non multiple of 4 coordinates for
> > > > > >>>>>>>>>> plane_state's src_x and src_y, and before adjustment
> > > > > >>>>>>>>>> also reject non multiple of 4 src_w/src_h.fter that
> > > > > >>>>>>>>>> we can also reject clipping to the right/bottom edge
> > > > > >>>>>>>>>> of the screen, if the pipe_src_w/h is not a multiple of 4.
> > > > > >>>>>>>>>> That way an application trying to go beyond the
> > > > > >>>> screen.
> > > > > >>>>>>>>> kms_plane_scaling and some other tests during
> > > > > >>>>>>>>> execution generate lots of non mult of 4 buffer
> > > > > >>>>>>>>> width/height. All these tests will show fail in the IGT
> BAT.
> > > > > >>>>>>>>> In some cases, even thought the width and height will
> > > > > >>>>>>>>> be multiple of
> > > > > >>>>>>>>> 4 before the Adjustment (say our 16x16 buffer), this
> > > > > >>>>>>>>> after adjustment becomes a 15 in
> > intel_check_sprite_plane.
> > > > > >>>>>>>>> This again would cause underrun. If we reject non
> > > > > >>>>>>>>> multiple of 4s in our skl_update_scaler also, then
> > > > > >>>>>>>>> even simple tests with
> > > > > >>>>>>>>> 16x16 like rotation will fail due to it getting adjusted.
> > > > > >>>>>>> Correct. This is why we fix up to a multiple of 4 after
> > > > > >>>>>>> adjustments, and reject user passed coordinates before
> > > > > adjustment..
> > > > > >>>>>>> plane_state->src_x/y/w/h is the property set by the
> > > > > >>>>>>> user, while the plane_state->src rect is set and fixed
> > > > > >>>>>>> up in the
> > kernel.
> > > > > >>>>>>>
> > > > > >>>>>>> Rejecting clipping with positive coordinates if pipe_src
> > > > > >>>>>>> w/h is not a multiple of 4 will fix a border case that
> > > > > >>>>>>> shouldn't affect most modes, where the plane wouldn't
> > > > > >>>>>>> extend to the crtc borders, which is
> > > > > >>>>> what userspace wants there.
> > > > > >>>>>> Thank you. Oh okay. Sorry. I thought we just reject and
> > > > > >>>>>> not do the fixing
> > > > > >>>>> (mult of 4 later).
> > > > > >>>>>> Sure, I will change the patch to also reject the
> > > > > >>>>>> coordinates before adjustment (if its not Mult of 4).
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>> This can be done in skl_check_plane_surface,
> > > > > >>>>> plane_state->src_{x,y,w,h} contains the user requested values.
> > > > > >>>> Apologies for asking again. The adjustments are done in
> > > > > >>>> check_plane (both primary and sprite) And towards the end
> > > > > >>>> of check_plane we call the skl_check_plane_surface.
> > > > > >>>> I got your point that we will reject the user requested
> > > > > >>>> values if they are not multiple of 4.
> > > > > >>>> But before we reach skl_check_plane_surface, they would’ve
> > > > > >>>> been adjusted/clipped etc They wont remain user requested
> > > > > >>>> as is when they enter skl_check_plane_surface.
> > > > > >>>> Please correct me if I am wrong or I am missing in
> > > > > >>>> understanding something here :(
> > > > > >>>>
> > > > > >>>> I can add the add conversion to multiple of 4 in
> > > > > >>>> skl_check_plane_surface but rejection should be done before
> > > > > >>>> the clipping/adjustment Or else, I move the entire
> > > > > >>>> clipping/adjustment code
> > > > > >> to skl_check_plane_surface?
> > > > > >>> Sorry, I got it. You said, we don’t do adjustments in case
> > > > > >>> of
> > > > > >>> NV12 in sprite and move The handling to
> skl_check_plane_surface.
> > > > > >>> I will do the
> > > > > >> change and submit. Sorry.
> > > > > >>> Thank you.
> > > > > >>>
> > > > > >> Something like below? Untested..
> > > > > >> We should probably also restrict NV12 fb creation to not
> > > > > >> allow CCS
> > > > > formats.
> > > >
> > > > Thank you so much. Have submitted the changes to trybot
> > > > https://patchwork.freedesktop.org/series/41532/
> > > > PS: fb creation to not allow CCS - not done in this series
> > > Why not directly to intel-gfx?
> > Sure, I thought I had to send to trybot first. Will send it today.
> I see trybot for patches as test for RFC to see if solution is even near
> satisfactory in the beginning but for patches that has sent several times no
> need to send to trybot.

Oh okay. Sure, thank you so much.

Regards
Vidya
> 
> 
> 
> >
> > Thanks
> > Vidya
> > >
> > >
> > > >
> > > > Regards
> > > > Vidya
> > > >
> > > > > >>
> > > > > >> ~Maarten
> > > > > >>
> > > > > >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > > >> b/drivers/gpu/drm/i915/intel_display.c
> > > > > >> index 4b3735720fee..c5da30c7ad04 100644
> > > > > >> --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > >> +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > >> @@ -3090,6 +3090,38 @@ 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;
> > > > > >> +
> > > > > >> +	/* Are the unadjusted coordinates passed in valid? */
> > > > > >> +	if ((plane_state->base.src_x >> 16) % 4 ||
> > > > > >> +	    (plane_state->base.src_y >> 16) % 4 ||
> > > > > >> +	    (plane_state->base.src_w >> 16) % 4 ||
> > > > > >> +	    (plane_state->base.src_h >> 16) % 4) {
> > > > > >> +		DRM_DEBUG_KMS("Source coordinates must be a
> > > 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;
> > > > > >> +	}
> > > > > >> +
> > > > > >> +	/* Make adjusted src coordinates a multiple of 4. */
> > > > > >> +	plane_state->base.src.x1 =
> > > DIV_ROUND_CLOSEST(plane_state-
> > > > > >>> base.src.x1, 1 << 18) << 18;
> > > > > >> +	plane_state->base.src.y1 =
> > > DIV_ROUND_CLOSEST(plane_state-
> > > > > >>> base.src.y1, 1 << 18) << 18;
> > > > > >> +	plane_state->base.src.x2 =
> > > DIV_ROUND_CLOSEST(plane_state-
> > > > > >>> base.src.x2, 1 << 18) << 18;
> > > > > >> +	plane_state->base.src.y2 =
> > > DIV_ROUND_CLOSEST(plane_state-
> > > > > >>> base.src.y2, 1 << 18) << 18;
> > > > > >> +	return 0;
> > > > > >> +}
> > > > > >> +
> > > > > > Thank you so much :) Only one problem. The primary plane
> > > > > > clipping happens inside the drm layer in
> > > > > > drm_atomic_helper_check_plane_state
> > > > > > So, clipping-clamping test passes coordinates 0, 257, 0, 159
> > > > > > to
> > > > > check_plane.
> > > > > > And there before adjusting we reject. So for primary alone,
> > > > > > can I retain the make multiple of 4 code in primary itself?
> > > > >
> > > > > The clipping affects plane_state->src.{x1, y1, x2, y2}, not
> > > > > plane_state-
> > > > > >src_{x,y,w,h}.
> > > > > They're different. The last set of coordinates will not be
> > > > > rotated or anything, the first set of coordinates are what we
> > > > > end up programming into the hardware. The patch I put above
> > > > > should be correctly rounding to a multiple of 4. :)
> > > > >
> > > > > ~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Srinivas, Vidya]

> -----Original Message-----
> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> Sent: Tuesday, April 17, 2018 3:32 PM
> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> NV12
> 
> Op 17-04-18 om 11:42 schreef Srinivas, Vidya:
> >
> >> -----Original Message-----
> >> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >> Sent: Tuesday, April 17, 2018 3:04 PM
> >> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> >> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> >> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >> for
> >> NV12
> >>
> >> Op 17-04-18 om 10:09 schreef Srinivas, Vidya:
> >>>> -----Original Message-----
> >>>> From: Srinivas, Vidya
> >>>> Sent: Tuesday, April 17, 2018 1:32 PM
> >>>> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>;
> >>>> Saarinen, Jani <jani.saarinen@intel.com>;
> >>>> intel-gfx@lists.freedesktop.org
> >>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>> for
> >>>> NV12
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com]
> >>>>> Sent: Tuesday, April 17, 2018 1:21 PM
> >>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; Saarinen, Jani
> >>>>> <jani.saarinen@intel.com>; intel-gfx@lists.freedesktop.org
> >>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments
> >>>>> for
> >>>>> NV12
> >>>>>
> >>>>> Op 17-04-18 om 09:38 schreef Srinivas, Vidya:
> >>>>>>> -----Original Message-----
> >>>>>>> From: Maarten Lankhorst
> >>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> >>>>>>> Sent: Tuesday, April 17, 2018 12:55 PM
> >>>>>>> To: Saarinen, Jani <jani.saarinen@intel.com>; Srinivas, Vidya
> >>>>>>> <vidya.srinivas@intel.com>;
> >>>>>>> intel-gfx-trybot@lists.freedesktop.org;
> >>>>>>> intel- gfx@lists.freedesktop.org
> >>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>
> >>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>> adjustments for
> >>>>>>> NV12
> >>>>>>>
> >>>>>>> Op 17-04-18 om 08:03 schreef Saarinen, Jani:
> >>>>>>>> Lets move this to intel-gfx to get more eyes on it.
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Srinivas, Vidya
> >>>>>>>>> Sent: tiistai 17. huhtikuuta 2018 5.47
> >>>>>>>>> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>;
> >>>>>>>>> intel-gfx- trybot@lists.freedesktop.org
> >>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>>>>>>>> <jani.saarinen@intel.com>
> >>>>>>>>> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>>> adjustments for NV12
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Maarten Lankhorst
> >>>>>>>>>> [mailto:maarten.lankhorst@linux.intel.com]
> >>>>>>>>>> Sent: Monday, April 16, 2018 8:00 PM
> >>>>>>>>>> To: Srinivas, Vidya <vidya.srinivas@intel.com>; intel-gfx-
> >>>>>>>>>> trybot@lists.freedesktop.org
> >>>>>>>>>> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> >>>>>>>>>> <jani.saarinen@intel.com>
> >>>>>>>>>> Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src
> >>>>>>>>>> adjustments for
> >>>>>>>>>> NV12
> >>>>>>>>>>
> >>>>>>>>>> Hmm, more thought about src adjustments...
> >>>>>>>>>>
> >>>>>>>>>> Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> >>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>> Credits-to: Maarten Lankhorst
> >>>>>>>>>>> <maarten.lankhorst@linux.intel.com>
> >>>>>>>>>>> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
> >>>>>>>>>>> ---
> >>>>>>>>>>>  drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++
> >>>>>>>>>>> drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
> >>>>>>>>>>>  2 files changed, 26 insertions(+)
> >>>>>>>>>>>
> >>>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> b/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> index bc83f10..f64708f 100644
> >>>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>>>>>>>>>> @@ -12978,6 +12978,10 @@
> intel_check_primary_plane(struct
> >>>>>>>>>> intel_plane *plane,
> >>>>>>>>>>>  	bool can_position = false;
> >>>>>>>>>>>  	int ret;
> >>>>>>>>>>>  	uint32_t pixel_format = 0;
> >>>>>>>>>>> +	struct drm_plane_state *plane_state = &state->base;
> >>>>>>>>>>> +	struct drm_rect *src = &plane_state->src;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	*src = drm_plane_state_src(plane_state);
> >>>>>>>>>>>
> >>>>>>>>>>>  	if (INTEL_GEN(dev_priv) >= 9) {
> >>>>>>>>>>>  		/* use scaler when colorkey is not required */ @@ -
> >>>>> 13001,6
> >>>>>>>>>>> +13005,13 @@ intel_check_primary_plane(struct intel_plane
> >>>>> *plane,
> >>>>>>>>>>>  	if (!state->base.fb)
> >>>>>>>>>>>  		return 0;
> >>>>>>>>>>>
> >>>>>>>>>>> +	if (pixel_format == DRM_FORMAT_NV12) {
> >>>>>>>>>>> +		src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +		src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +		src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +		src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> >>>>>>>>>>> +	}
> >>>>>>>>>> Lets reject non multiple of 4 coordinates for plane_state's
> >>>>>>>>>> src_x and src_y, and before adjustment also reject non
> >>>>>>>>>> multiple of 4 src_w/src_h.fter that we can also reject
> >>>>>>>>>> clipping to the right/bottom edge of the screen, if the
> >>>>>>>>>> pipe_src_w/h is not a multiple of 4. That way an application
> >>>>>>>>>> trying to go beyond the
> >>>> screen.
> >>>>>>>>> kms_plane_scaling and some other tests during execution
> >>>>>>>>> generate lots of non mult of 4 buffer width/height. All these
> >>>>>>>>> tests will show fail in the IGT BAT.
> >>>>>>>>> In some cases, even thought the width and height will be
> >>>>>>>>> multiple of
> >>>>>>>>> 4 before the Adjustment (say our 16x16 buffer), this after
> >>>>>>>>> adjustment becomes a 15 in intel_check_sprite_plane.
> >>>>>>>>> This again would cause underrun. If we reject non multiple of
> >>>>>>>>> 4s in our skl_update_scaler also, then even simple tests with
> >>>>>>>>> 16x16 like rotation will fail due to it getting adjusted.
> >>>>>>> Correct. This is why we fix up to a multiple of 4 after
> >>>>>>> adjustments, and reject user passed coordinates before
> adjustment..
> >>>>>>> plane_state->src_x/y/w/h is the property set by the user, while
> >>>>>>> the plane_state->src rect is set and fixed up in the kernel.
> >>>>>>>
> >>>>>>> Rejecting clipping with positive coordinates if pipe_src w/h is
> >>>>>>> not a multiple of 4 will fix a border case that shouldn't affect
> >>>>>>> most modes, where the plane wouldn't extend to the crtc borders,
> >>>>>>> which is
> >>>>> what userspace wants there.
> >>>>>> Thank you. Oh okay. Sorry. I thought we just reject and not do
> >>>>>> the fixing
> >>>>> (mult of 4 later).
> >>>>>> Sure, I will change the patch to also reject the coordinates
> >>>>>> before adjustment (if its not Mult of 4).
> >>>>>>
> >>>>>>
> >>>>> This can be done in skl_check_plane_surface,
> >>>>> plane_state->src_{x,y,w,h} contains the user requested values.
> >>>> Apologies for asking again. The adjustments are done in check_plane
> >>>> (both primary and sprite) And towards the end of check_plane we
> >>>> call the skl_check_plane_surface.
> >>>> I got your point that we will reject the user requested values if
> >>>> they are not multiple of 4.
> >>>> But before we reach skl_check_plane_surface, they would’ve been
> >>>> adjusted/clipped etc They wont remain user requested as is when
> >>>> they enter skl_check_plane_surface.
> >>>> Please correct me if I am wrong or I am missing in understanding
> >>>> something here :(
> >>>>
> >>>> I can add the add conversion to multiple of 4 in
> >>>> skl_check_plane_surface but rejection should be done before the
> >>>> clipping/adjustment Or else, I move the entire clipping/adjustment
> >>>> code
> >> to skl_check_plane_surface?
> >>> Sorry, I got it. You said, we don’t do adjustments in case of NV12
> >>> in sprite and move The handling to skl_check_plane_surface. I will
> >>> do the
> >> change and submit. Sorry.
> >>> Thank you.
> >>>
> >> Something like below? Untested..
> >> We should probably also restrict NV12 fb creation to not allow CCS
> formats.

Thank you for all the help. Have floated the series with your RB.
Have also included the change you mentioned in framebuffer_init
Not to allow CCS formats. However, when I checked code in framebuffer_init
If the modifier is CCS, only RGB8888 related are allowed.
Please have a check. If you have any suggestion, I will change it.
https://patchwork.freedesktop.org/series/41674/ Rev2

Regards
Vidya

> >>
> >> ~Maarten
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 4b3735720fee..c5da30c7ad04 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -3090,6 +3090,38 @@ 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;
> >> +
> >> +	/* Are the unadjusted coordinates passed in valid? */
> >> +	if ((plane_state->base.src_x >> 16) % 4 ||
> >> +	    (plane_state->base.src_y >> 16) % 4 ||
> >> +	    (plane_state->base.src_w >> 16) % 4 ||
> >> +	    (plane_state->base.src_h >> 16) % 4) {
> >> +		DRM_DEBUG_KMS("Source coordinates must be a 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;
> >> +	}
> >> +
> >> +	/* Make adjusted src coordinates a multiple of 4. */
> >> +	plane_state->base.src.x1 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.x1, 1 << 18) << 18;
> >> +	plane_state->base.src.y1 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.y1, 1 << 18) << 18;
> >> +	plane_state->base.src.x2 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.x2, 1 << 18) << 18;
> >> +	plane_state->base.src.y2 = DIV_ROUND_CLOSEST(plane_state-
> >>> base.src.y2, 1 << 18) << 18;
> >> +	return 0;
> >> +}
> >> +
> > Thank you so much :) Only one problem. The primary plane clipping
> > happens inside the drm layer in drm_atomic_helper_check_plane_state
> > So, clipping-clamping test passes coordinates 0, 257, 0, 159 to
> check_plane.
> > And there before adjusting we reject. So for primary alone, can I
> > retain the make multiple of 4 code in primary itself?
> 
> The clipping affects plane_state->src.{x1, y1, x2, y2}, not plane_state-
> >src_{x,y,w,h}.
> They're different. The last set of coordinates will not be rotated or anything,
> the first set of coordinates are what we end up programming into the
> hardware. The patch I put above should be correctly rounding to a multiple
> of 4. :)
> 
> ~Maarten

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

Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12

[Saarinen, Jani]

+wider-list. 

> -----Original Message-----
> From: Srinivas, Vidya
> Sent: tiistai 17. huhtikuuta 2018 7.59
> To: 'Maarten Lankhorst' <maarten.lankhorst@linux.intel.com>; 'intel-gfx-
> trybot@lists.freedesktop.org' <intel-gfx-trybot@lists.freedesktop.org>
> Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> <jani.saarinen@intel.com>
> Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for NV12
> 
> 
> 
> 
> 
> > -----Original Message-----
> 
> > From: Srinivas, Vidya
> 
> > Sent: Tuesday, April 17, 2018 8:17 AM
> 
> > To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; intel-gfx-
> 
> > trybot@lists.freedesktop.org
> 
> > Cc: Kamath, Sunil <sunil.kamath@intel.com>; Saarinen, Jani
> 
> > <jani.saarinen@intel.com>
> 
> > Subject: RE: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> 
> > NV12
> 
> >
> 
> >
> 
> >
> 
> > > -----Original Message-----
> 
> > > From: Maarten Lankhorst [mailto:maarten.lankhorst@linux.intel.com
> <mailto:maarten.lankhorst@linux.intel.com> ]
> 
> > > Sent: Monday, April 16, 2018 8:00 PM
> 
> > > To: Srinivas, Vidya <vidya.srinivas@intel.com
> <mailto:vidya.srinivas@intel.com> >; intel-gfx-
> 
> > > trybot@lists.freedesktop.org <mailto:trybot@lists.freedesktop.org>
> 
> > > Cc: Kamath, Sunil <sunil.kamath@intel.com
> <mailto:sunil.kamath@intel.com> >; Saarinen, Jani
> 
> > > <jani.saarinen@intel.com <mailto:jani.saarinen@intel.com> >
> 
> > > Subject: Re: [PATCH v2 6/6] drm/i915: Do not do fb src adjustments for
> 
> > > NV12
> 
> > >
> 
> > > Hmm, more thought about src adjustments...
> 
> > >
> 
> > > Op 13-04-18 om 07:22 schreef Vidya Srinivas:
> 
> > > > 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
> 
> > > >
> 
> > > > Credits-to: 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 | 11 +++++++++++
> 
> > > > drivers/gpu/drm/i915/intel_sprite.c  | 15 +++++++++++++++
> 
> > > >  2 files changed, 26 insertions(+)
> 
> > > >
> 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> 
> > > > b/drivers/gpu/drm/i915/intel_display.c
> 
> > > > index bc83f10..f64708f 100644
> 
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> 
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> 
> > > > @@ -12978,6 +12978,10 @@ intel_check_primary_plane(struct
> 
> > > intel_plane *plane,
> 
> > > >      bool can_position = false;
> 
> > > >      int ret;
> 
> > > >      uint32_t pixel_format = 0;
> 
> > > > +  struct drm_plane_state *plane_state = &state->base;
> 
> > > > +  struct drm_rect *src = &plane_state->src;
> 
> > > > +
> 
> > > > +  *src = drm_plane_state_src(plane_state);
> 
> > > >
> 
> > > >      if (INTEL_GEN(dev_priv) >= 9) {
> 
> > > >                      /* use scaler when colorkey is not required */ @@ -13001,6
> 
> > > > +13005,13 @@ intel_check_primary_plane(struct intel_plane *plane,
> 
> > > >      if (!state->base.fb)
> 
> > > >                      return 0;
> 
> > > >
> 
> > > > +  if (pixel_format == DRM_FORMAT_NV12) {
> 
> > > > +                  src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> 
> > > > +                  src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> 
> > > > +                  src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> 
> > > > +                  src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> 
> > > > +  }
> 
> > >
> 
> > > Lets reject non multiple of 4 coordinates for plane_state's src_x and
> 
> > > src_y, and before adjustment also reject non multiple of 4
> 
> > > src_w/src_h.fter that we can also reject clipping to the right/bottom
> 
> > > edge of the screen, if the pipe_src_w/h is not a multiple of 4. That
> 
> > > way an application trying to go beyond the screen.
> 
> >
> 
> > kms_plane_scaling and some other tests during execution generate lots of
> 
> > non mult of 4 buffer width/height. All these tests will show fail in the IGT
> 
> > BAT.
> 
> > In some cases, even thought the width and height will be multiple of 4
> 
> > before the Adjustment (say our 16x16 buffer), this after adjustment
> 
> > becomes a 15 in intel_check_sprite_plane.
> 
> > This again would cause underrun. If we reject non multiple of 4s in our
> 
> > skl_update_scaler also, then even simple tests with 16x16 like rotation will
> 
> > fail due to it getting adjusted.
> 
> 
> 
> Example:
> 
> During kms_plane_scaling-with-rotation execution - print cooridinates here:
> src->x1, src->x2, src->y1, src->y2
> 
> 
> 
> [   43.542044] [drm:intel_check_sprite_plane] *ERROR* Before adjust: 1040:
> 0 16 0 16
> 
> [   43.542054] [drm:intel_check_sprite_plane] *ERROR* After adjust: 1054: 0
> 15 0 15
> 
> [   43.542058] [drm:intel_check_sprite_plane] *ERROR* Before check plane
> surface: 1135: 0 15 0 15
> 
> [   43.570827] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU
> pipe A FIFO underrun
> 
> 
> 
> 16x16 becomes 15x15 after rect adjustment in check_sprite_plane
> 
> 
> 
> During kms_plane_scaling-with-clipping-clamping – print coordinates here
> src->x1, src->x2, src->y1, src->y2
> 
> 
> 
> [  125.432029] [drm:intel_check_primary_plane] *ERROR* Before check
> plane state: 12998: 0 300 0 300
> 
> [  125.432041] [drm:intel_check_primary_plane] *ERROR* After check plane
> state: 13004: 0 257 0 159
> 
> [  128.057081] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU
> pipe A FIFO underrun
> 
> 
> 
> 300x300 after primary plane clipping becomes 257 in check_primary_plane
> 
> 
> 
> All these generate fifo underruns. In the first example here, 16x16, before
> adjustment we check if it is multiplier
> 
> of 4, and since it is, we allow. But after rect_adjust it becomes 15x15
> 
> In example 2, clipping clamping, 300x300 is the value before clipping in
> primary plane, since it is a multiple of 4, we allow
> 
> But after clipping it becomes 257x159.
> 
> 
> 
> 
> 
> >
> 
> > >
> 
> > > skl_check_plane_surface could do all the fixups and is allowed to
> 
> > > return an error code, so we could put all SKL specific NV12 handling in
> 
> > there.
> 
> > > It doesn't matter that we calculate potentially illegal values, if we
> 
> > > never program them and return -EINVAL there. If it turns out we've
> 
> > > been too paranoid we could relax the condition.
> 
> > >
> 
> > > This would mean unified handling for NV12 for primary and sprite. :)
> 
> > >
> 
> > > >      if (INTEL_GEN(dev_priv) >= 9) {
> 
> > > >                      ret = skl_check_plane_surface(crtc_state, state);
> 
> > > >                      if (ret)
> 
> > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> 
> > > > b/drivers/gpu/drm/i915/intel_sprite.c
> 
> > > > index 8b7947d..c1dd85e 100644
> 
> > > > --- a/drivers/gpu/drm/i915/intel_sprite.c
> 
> > > > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> 
> > > > @@ -1035,11 +1035,20 @@ intel_check_sprite_plane(struct intel_plane
> 
> > > *plane,
> 
> > > >                                      return vscale;
> 
> > > >                      }
> 
> > > >
> 
> > > > +                  if (fb->format->format == DRM_FORMAT_NV12) {
> 
> > > > +                                  if (src->x2 >> 16 == 16)
> 
> > > > +                                                  src->x2 = 16 << 16;
> 
> > > > +                                  if (src->y2 >> 16 == 16)
> 
> > > > +                                                  src->y2 = 16 << 16;
> 
> > > This part doesn't look required, the magic below for the nv12 format
> 
> > > is similar.. Just conditionally call adjust_size for format != NV12.
> 
> 
> 
> This part is required only if we retain 16x16 buffer, Because after adjust_size
> it becomes
> 
> 15x15 as I have mentioned above. Then our minimum criteria for NV12 fails
> and our igt buffer
> 
> As of now is 16x16. To get a IGT pass I had added this work around.
> 
> 
> 
> > > :)
> 
> > > > +                                  goto nv12_min_no_clip;
> 
> > > > +                  }
> 
> > > > +
> 
> > > >                      /* 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));
> 
> > > >
> 
> > > > +nv12_min_no_clip:
> 
> > > >                      drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
> 
> > > >                                                          state->base.rotation);
> 
> > > >
> 
> > > > @@ -1105,6 +1114,12 @@ intel_check_sprite_plane(struct intel_plane
> 
> > > *plane,
> 
> > > >                      src->x2 = (src_x + src_w) << 16;
> 
> > > >                      src->y1 = src_y << 16;
> 
> > > >                      src->y2 = (src_y + src_h) << 16;
> 
> > > > +                  if (fb->format->format == DRM_FORMAT_NV12) {
> 
> > > > +                                  src->x1 = (((src->x1 >> 16)/4)*4) << 16;
> 
> > > > +                                  src->x2 = (((src->x2 >> 16)/4)*4) << 16;
> 
> > > > +                                  src->y1 = (((src->y1 >> 16)/4)*4) << 16;
> 
> > > > +                                  src->y2 = (((src->y2 >> 16)/4)*4) << 16;
> 
> > > > +                  }
> 
> 

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