All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
@ 2019-09-25 12:17 Stanislav Lisovskiy
  2019-09-25 14:28 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev3) Patchwork
                   ` (3 more replies)
  0 siblings, 4 replies; 10+ messages in thread
From: Stanislav Lisovskiy @ 2019-09-25 12:17 UTC (permalink / raw)
  To: intel-gfx; +Cc: ville.syrjala, martin.peres

According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.

Currently we are just comparing against all of
those and take minimum(worst case).

v2: Fixed wrong PCode reply mask, removed hardcoded
    values.

v3: Forbid simultaneous legacy SAGV PCode requests and
    restricting qgv points. Put the actual restriction
    to commit function, added serialization(thanks to Ville)
    to prevent commit being applied out of order in case of
    nonblocking and/or nomodeset commits.

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
---
 drivers/gpu/drm/i915/display/intel_atomic.c   | 16 ++++
 drivers/gpu/drm/i915/display/intel_atomic.h   |  3 +
 drivers/gpu/drm/i915/display/intel_bw.c       | 79 +++++++++++++------
 drivers/gpu/drm/i915/display/intel_bw.h       |  2 +
 drivers/gpu/drm/i915/display/intel_display.c  | 78 +++++++++++++++++-
 .../drm/i915/display/intel_display_types.h    |  3 +
 drivers/gpu/drm/i915/i915_drv.h               |  2 +
 drivers/gpu/drm/i915/i915_reg.h               |  3 +
 8 files changed, 160 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c b/drivers/gpu/drm/i915/display/intel_atomic.c
index 698802da07b7..903537c4fb0f 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -208,6 +208,22 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
 	return &crtc_state->base;
 }
 
+int intel_atomic_serialize_global_state(struct intel_atomic_state *state)
+{
+	struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+	struct intel_crtc *crtc;
+
+	for_each_intel_crtc(&dev_priv->drm, crtc) {
+		struct intel_crtc_state *crtc_state;
+
+		crtc_state = intel_atomic_get_crtc_state(&state->base, crtc);
+		if (IS_ERR(crtc_state))
+			return PTR_ERR(crtc_state);
+	}
+
+	return 0;
+}
+
 /**
  * intel_crtc_destroy_state - destroy crtc state
  * @crtc: drm crtc
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h b/drivers/gpu/drm/i915/display/intel_atomic.h
index 58065d3161a3..fd17b3ca257f 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -7,6 +7,7 @@
 #define __INTEL_ATOMIC_H__
 
 #include <linux/types.h>
+#include "intel_display_types.h"
 
 struct drm_atomic_state;
 struct drm_connector;
@@ -38,6 +39,8 @@ void intel_crtc_destroy_state(struct drm_crtc *crtc,
 struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
 void intel_atomic_state_clear(struct drm_atomic_state *state);
 
+int intel_atomic_serialize_global_state(struct intel_atomic_state *state);
+
 struct intel_crtc_state *
 intel_atomic_get_crtc_state(struct drm_atomic_state *state,
 			    struct intel_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
index cd58e47ab7b2..81e3468306fa 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -8,6 +8,7 @@
 #include "intel_bw.h"
 #include "intel_display_types.h"
 #include "intel_sideband.h"
+#include "intel_atomic.h"
 
 /* Parameters for Qclk Geyserville (QGV) */
 struct intel_qgv_point {
@@ -90,6 +91,27 @@ static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv,
 	return 0;
 }
 
+int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
+				  u32 points_mask)
+{
+	int ret;
+
+	/* bspec says to keep retrying for at least 1 ms */
+	ret = skl_pcode_request(dev_priv, ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
+				points_mask,
+				GEN11_PCODE_POINTS_RESTRICTED_MASK,
+				GEN11_PCODE_POINTS_RESTRICTED,
+				1);
+
+	if (ret < 0) {
+		DRM_ERROR("Failed to disable qgv points (%d)\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+
 static int icl_get_qgv_points(struct drm_i915_private *dev_priv,
 			      struct intel_qgv_info *qi)
 {
@@ -247,22 +269,6 @@ void intel_bw_init_hw(struct drm_i915_private *dev_priv)
 		icl_get_bw_info(dev_priv, &icl_sa_info);
 }
 
-static unsigned int intel_max_data_rate(struct drm_i915_private *dev_priv,
-					int num_planes)
-{
-	if (INTEL_GEN(dev_priv) >= 11)
-		/*
-		 * FIXME with SAGV disabled maybe we can assume
-		 * point 1 will always be used? Seems to match
-		 * the behaviour observed in the wild.
-		 */
-		return min3(icl_max_bw(dev_priv, num_planes, 0),
-			    icl_max_bw(dev_priv, num_planes, 1),
-			    icl_max_bw(dev_priv, num_planes, 2));
-	else
-		return UINT_MAX;
-}
-
 static unsigned int intel_bw_crtc_num_active_planes(const struct intel_crtc_state *crtc_state)
 {
 	/*
@@ -354,7 +360,9 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
 	unsigned int data_rate, max_data_rate;
 	unsigned int num_active_planes;
 	struct intel_crtc *crtc;
-	int i;
+	int i, ret;
+	struct intel_qgv_info qi = {};
+	u32 allowed_points = 0;
 
 	/* FIXME earlier gens need some checks too */
 	if (INTEL_GEN(dev_priv) < 11)
@@ -398,16 +406,43 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
 	data_rate = intel_bw_data_rate(dev_priv, bw_state);
 	num_active_planes = intel_bw_num_active_planes(dev_priv, bw_state);
 
-	max_data_rate = intel_max_data_rate(dev_priv, num_active_planes);
-
 	data_rate = DIV_ROUND_UP(data_rate, 1000);
 
-	if (data_rate > max_data_rate) {
-		DRM_DEBUG_KMS("Bandwidth %u MB/s exceeds max available %d MB/s (%d active planes)\n",
-			      data_rate, max_data_rate, num_active_planes);
+	ret = icl_get_qgv_points(dev_priv, &qi);
+	if (ret < 0)
+		return 0;
+
+	for (i = 0; i < qi.num_points; i++) {
+		max_data_rate = icl_max_bw(dev_priv, num_active_planes, i);
+		if (max_data_rate < data_rate)
+			DRM_DEBUG_KMS("QGV point %d: max bw %d required %d\n",
+				      i, max_data_rate, data_rate);
+		else {
+			DRM_DEBUG_KMS("QGV point %d: max bw %d required %d\n",
+				      i, max_data_rate, data_rate);
+			allowed_points |= 1 << i;
+		}
+	}
+
+	if (allowed_points == 0) {
+		DRM_DEBUG_KMS("Could not find any suitable QGV points\n");
 		return -EINVAL;
 	}
 
+	state->qgv_points_mask = (~allowed_points) & ((1 << qi.num_points) - 1);
+
+	/*
+	 * If the actual mask had changed we need to make sure that
+	 * the commits are serialized(in case this is a nomodeset, nonblocking)
+	 */
+	if (state->qgv_points_mask != dev_priv->qgv_points_mask) {
+		ret = intel_atomic_serialize_global_state(state);
+		if (ret) {
+			DRM_DEBUG_KMS("Could not serialize global state\n");
+			return ret;
+		}
+	}
+
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h
index 9db10af012f4..66bf9bc10b73 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -28,5 +28,7 @@ int intel_bw_init(struct drm_i915_private *dev_priv);
 int intel_bw_atomic_check(struct intel_atomic_state *state);
 void intel_bw_crtc_update(struct intel_bw_state *bw_state,
 			  const struct intel_crtc_state *crtc_state);
+int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
+				  u32 points_mask);
 
 #endif /* __INTEL_BW_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 5ecf54270181..c3196d0e4be3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13960,6 +13960,68 @@ static void intel_atomic_cleanup_work(struct work_struct *work)
 	intel_atomic_helper_free_state(i915);
 }
 
+static void intel_qgv_point_pre_update(struct intel_atomic_state *state)
+{
+	struct drm_device *dev = state->base.dev;
+	struct drm_i915_private *dev_priv = to_i915(dev);
+	int i, ret;
+
+	/*
+	 * Restrict required qgv points before updating the configuration.
+	 * According to BPsec we can't mask and unmask qgv points at the same
+	 * time. Also masking should be done before updating the configuration
+	 * and unmasking afterwards.
+	 */
+	u32 new_qgv_points_mask = dev_priv->qgv_points_mask;
+	int num_points = dev_priv->max_bw[0].num_qgv_points;
+
+	for (i = num_points; i > 0; i--) {
+		int new_mask_bit = state->qgv_points_mask & (1 << num_points);
+		int old_mask_bit = new_qgv_points_mask & (1 << num_points);
+
+		if (old_mask_bit != new_mask_bit)
+			if (new_mask_bit != 0)
+				new_qgv_points_mask |= new_mask_bit;
+	}
+
+	ret = icl_pcode_restrict_qgv_points(dev_priv, new_qgv_points_mask);
+	if (ret < 0)
+		DRM_DEBUG_KMS("Could not restrict required gqv points(%d)\n", ret);
+	else
+		dev_priv->qgv_points_mask = new_qgv_points_mask;
+}
+
+static void intel_qgv_point_post_update(struct intel_atomic_state *state)
+{
+	struct drm_device *dev = state->base.dev;
+	struct drm_i915_private *dev_priv = to_i915(dev);
+	int i, ret;
+
+	/*
+	 * Restrict required qgv points before updating the configuration.
+	 * According to BPsec we can't mask and unmask qgv points at the same
+	 * time. Also masking should be done before updating the configuration
+	 * and unmasking afterwards.
+	 */
+	u32 new_qgv_points_mask = dev_priv->qgv_points_mask;
+	int num_points = dev_priv->max_bw[0].num_qgv_points;
+
+	for (i = num_points; i > 0; i--) {
+		int new_mask_bit = state->qgv_points_mask & (1 << num_points);
+		int old_mask_bit = new_qgv_points_mask & (1 << num_points);
+
+		if (old_mask_bit != new_mask_bit)
+			if (new_mask_bit == 0)
+				new_qgv_points_mask &= ~old_mask_bit;
+	}
+
+	ret = icl_pcode_restrict_qgv_points(dev_priv, new_qgv_points_mask);
+	if (ret < 0)
+		DRM_DEBUG_KMS("Could not restrict required gqv points(%d)\n", ret);
+	else
+		dev_priv->qgv_points_mask = new_qgv_points_mask;
+}
+
 static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 {
 	struct drm_device *dev = state->base.dev;
@@ -13987,6 +14049,9 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 		}
 	}
 
+	if ((INTEL_GEN(dev_priv) >= 11))
+		intel_qgv_point_pre_update(state);
+
 	intel_commit_modeset_disables(state);
 
 	/* FIXME: Eventually get rid of our crtc->config pointer */
@@ -14005,8 +14070,9 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 		 * SKL workaround: bspec recommends we disable the SAGV when we
 		 * have more then one pipe enabled
 		 */
-		if (!intel_can_enable_sagv(state))
-			intel_disable_sagv(dev_priv);
+		if (INTEL_GEN(dev_priv) < 11)
+			if (!intel_can_enable_sagv(state))
+				intel_disable_sagv(dev_priv);
 
 		intel_modeset_verify_disabled(dev_priv, state);
 	}
@@ -14084,8 +14150,12 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 	if (state->modeset)
 		intel_verify_planes(state);
 
-	if (state->modeset && intel_can_enable_sagv(state))
-		intel_enable_sagv(dev_priv);
+	if (INTEL_GEN(dev_priv) < 11)
+		if (state->modeset && intel_can_enable_sagv(state))
+			intel_enable_sagv(dev_priv);
+
+	if ((INTEL_GEN(dev_priv) >= 11) && intel_can_enable_sagv(state))
+		intel_qgv_point_post_update(state);
 
 	drm_atomic_helper_commit_hw_done(&state->base);
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
index 6b0a646f0170..82f8df65347e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -512,6 +512,9 @@ struct intel_atomic_state {
 	struct i915_sw_fence commit_ready;
 
 	struct llist_node freed;
+
+	/* Gen11+ only */
+	u32 qgv_points_mask;
 };
 
 struct intel_plane_state {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fcf7423075ef..383de77a7b73 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1652,6 +1652,8 @@ struct drm_i915_private {
 		u8 num_planes;
 	} max_bw[6];
 
+	u32 qgv_points_mask;
+
 	struct drm_private_obj bw_obj;
 
 	struct intel_runtime_pm runtime_pm;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e752de9470bd..c78ee180c1aa 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8854,6 +8854,7 @@ enum {
 #define   ICL_PCODE_MEM_SUBSYSYSTEM_INFO	0xd
 #define     ICL_PCODE_MEM_SS_READ_GLOBAL_INFO	(0x0 << 8)
 #define     ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)	(((point) << 16) | (0x1 << 8))
+#define   ICL_PCODE_SAGV_DE_MEM_SS_CONFIG	0xe
 #define   GEN6_PCODE_READ_D_COMP		0x10
 #define   GEN6_PCODE_WRITE_D_COMP		0x11
 #define   HSW_PCODE_DE_WRITE_FREQ_REQ		0x17
@@ -8865,6 +8866,8 @@ enum {
 #define     GEN9_SAGV_DISABLE			0x0
 #define     GEN9_SAGV_IS_DISABLED		0x1
 #define     GEN9_SAGV_ENABLE			0x3
+#define GEN11_PCODE_POINTS_RESTRICTED		0x0
+#define GEN11_PCODE_POINTS_RESTRICTED_MASK	0x1
 #define GEN6_PCODE_DATA				_MMIO(0x138128)
 #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT	8
 #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT	16
-- 
2.17.1

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

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

* ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev3)
  2019-09-25 12:17 [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth Stanislav Lisovskiy
@ 2019-09-25 14:28 ` Patchwork
  2019-09-25 15:01 ` ✓ Fi.CI.BAT: success " Patchwork
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2019-09-25 14:28 UTC (permalink / raw)
  To: Stanislav Lisovskiy; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Restrict qgv points which don't have enough bandwidth. (rev3)
URL   : https://patchwork.freedesktop.org/series/66993/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
04ff25dfcc58 drm/i915: Restrict qgv points which don't have enough bandwidth.
-:114: CHECK:LINE_SPACING: Please don't use multiple blank lines
#114: FILE: drivers/gpu/drm/i915/display/intel_bw.c:114:
+
+

-:172: CHECK:BRACES: Unbalanced braces around else statement
#172: FILE: drivers/gpu/drm/i915/display/intel_bw.c:420:
+		else {

total: 0 errors, 0 warnings, 2 checks, 292 lines checked

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

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

* ✓ Fi.CI.BAT: success for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev3)
  2019-09-25 12:17 [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth Stanislav Lisovskiy
  2019-09-25 14:28 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev3) Patchwork
@ 2019-09-25 15:01 ` Patchwork
  2019-09-26  6:02 ` ✓ Fi.CI.IGT: " Patchwork
  2019-10-11 23:49 ` [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth James Ausmus
  3 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2019-09-25 15:01 UTC (permalink / raw)
  To: Stanislav Lisovskiy; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Restrict qgv points which don't have enough bandwidth. (rev3)
URL   : https://patchwork.freedesktop.org/series/66993/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6956 -> Patchwork_14528
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/

Known issues
------------

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

### IGT changes ###

#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s4-devices:
    - fi-blb-e6850:       [INCOMPLETE][1] ([fdo#107718]) -> [PASS][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/fi-blb-e6850/igt@gem_exec_suspend@basic-s4-devices.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/fi-blb-e6850/igt@gem_exec_suspend@basic-s4-devices.html

  * igt@kms_chamelium@hdmi-crc-fast:
    - fi-kbl-7500u:       [FAIL][3] ([fdo#109635 ]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/fi-kbl-7500u/igt@kms_chamelium@hdmi-crc-fast.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/fi-kbl-7500u/igt@kms_chamelium@hdmi-crc-fast.html

  
#### Warnings ####

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][5] ([fdo#111168 ]) -> [FAIL][6] ([fdo#111407])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 
  [fdo#111168 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111168 
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407


Participating hosts (51 -> 44)
------------------------------

  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6956 -> Patchwork_14528

  CI-20190529: 20190529
  CI_DRM_6956: e514b64998c2845943242b1d4dc2e568b01fddcb @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5202: 3499c5eb17054e2abd88023fe962768140d24302 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14528: 04ff25dfcc58ad4cbc704fa0191487417e493734 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

04ff25dfcc58 drm/i915: Restrict qgv points which don't have enough bandwidth.

== Logs ==

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

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

* ✓ Fi.CI.IGT: success for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev3)
  2019-09-25 12:17 [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth Stanislav Lisovskiy
  2019-09-25 14:28 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev3) Patchwork
  2019-09-25 15:01 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2019-09-26  6:02 ` Patchwork
  2019-10-11 23:49 ` [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth James Ausmus
  3 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2019-09-26  6:02 UTC (permalink / raw)
  To: Stanislav Lisovskiy; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Restrict qgv points which don't have enough bandwidth. (rev3)
URL   : https://patchwork.freedesktop.org/series/66993/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6956_full -> Patchwork_14528_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

New tests
---------

  New tests have been introduced between CI_DRM_6956_full and Patchwork_14528_full:

### New Piglit tests (7) ###

  * spec@arb_gpu_shader5@texturegather@vs-rg-0-int-cubearray:
    - Statuses : 1 incomplete(s)
    - Exec time: [0.0] s

  * spec@arb_gpu_shader5@texturegatheroffset@vs-rg-0-int-2darray:
    - Statuses : 1 incomplete(s)
    - Exec time: [0.0] s

  * spec@arb_gpu_shader5@texturegatheroffset@vs-rg-0-int-2darray-const:
    - Statuses : 1 incomplete(s)
    - Exec time: [0.0] s

  * spec@arb_gpu_shader5@texturegatheroffset@vs-rg-1-int-2darray:
    - Statuses : 1 incomplete(s)
    - Exec time: [0.0] s

  * spec@arb_gpu_shader5@texturegatheroffset@vs-rg-1-int-2darray-const:
    - Statuses : 1 incomplete(s)
    - Exec time: [0.0] s

  * spec@arb_gpu_shader5@texturegatheroffsets@vs-rg-0-int-2darray:
    - Statuses : 1 incomplete(s)
    - Exec time: [0.0] s

  * spec@arb_gpu_shader5@texturegatheroffsets@vs-rg-1-int-2darray:
    - Statuses : 1 incomplete(s)
    - Exec time: [0.0] s

  

Known issues
------------

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
    - shard-iclb:         [PASS][1] -> [SKIP][2] ([fdo#110841])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb5/igt@gem_ctx_shared@exec-single-timeline-bsd.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb4/igt@gem_ctx_shared@exec-single-timeline-bsd.html

  * igt@gem_ctx_switch@queue-heavy:
    - shard-iclb:         [PASS][3] -> [INCOMPLETE][4] ([fdo#107713]) +1 similar issue
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb6/igt@gem_ctx_switch@queue-heavy.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb1/igt@gem_ctx_switch@queue-heavy.html

  * igt@gem_exec_schedule@pi-ringfull-bsd:
    - shard-iclb:         [PASS][5] -> [SKIP][6] ([fdo#111325]) +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb7/igt@gem_exec_schedule@pi-ringfull-bsd.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb2/igt@gem_exec_schedule@pi-ringfull-bsd.html

  * igt@gem_tiled_swapping@non-threaded:
    - shard-glk:          [PASS][7] -> [DMESG-WARN][8] ([fdo#108686])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-glk4/igt@gem_tiled_swapping@non-threaded.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-glk1/igt@gem_tiled_swapping@non-threaded.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
    - shard-apl:          [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +2 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-apl5/igt@kms_cursor_crc@pipe-b-cursor-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
    - shard-apl:          [PASS][11] -> [FAIL][12] ([fdo#105363])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl5/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-apl8/igt@kms_flip@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@plain-flip-ts-check-interruptible:
    - shard-skl:          [PASS][13] -> [FAIL][14] ([fdo#100368])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl6/igt@kms_flip@plain-flip-ts-check-interruptible.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-skl9/igt@kms_flip@plain-flip-ts-check-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
    - shard-iclb:         [PASS][15] -> [FAIL][16] ([fdo#103167]) +5 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb6/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb4/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [PASS][17] -> [SKIP][18] ([fdo#109642] / [fdo#111068]) +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb1/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@no_drrs:
    - shard-iclb:         [PASS][19] -> [FAIL][20] ([fdo#108341])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb6/igt@kms_psr@no_drrs.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb1/igt@kms_psr@no_drrs.html

  * igt@kms_psr@psr2_primary_page_flip:
    - shard-iclb:         [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb8/igt@kms_psr@psr2_primary_page_flip.html

  * igt@prime_busy@after-bsd2:
    - shard-iclb:         [PASS][23] -> [SKIP][24] ([fdo#109276]) +6 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb1/igt@prime_busy@after-bsd2.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb3/igt@prime_busy@after-bsd2.html

  
#### Possible fixes ####

  * igt@gem_eio@unwedge-stress:
    - shard-snb:          [FAIL][25] ([fdo#109661]) -> [PASS][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-snb6/igt@gem_eio@unwedge-stress.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-snb7/igt@gem_eio@unwedge-stress.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [SKIP][27] ([fdo#110854]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb7/igt@gem_exec_balancer@smoke.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb2/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_schedule@preempt-queue-bsd:
    - shard-iclb:         [SKIP][29] ([fdo#111325]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb1/igt@gem_exec_schedule@preempt-queue-bsd.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb3/igt@gem_exec_schedule@preempt-queue-bsd.html

  * igt@gem_softpin@noreloc-s3:
    - shard-apl:          [DMESG-WARN][31] ([fdo#108566]) -> [PASS][32] +2 similar issues
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl7/igt@gem_softpin@noreloc-s3.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-apl8/igt@gem_softpin@noreloc-s3.html

  * igt@kms_cursor_crc@pipe-a-cursor-size-change:
    - shard-skl:          [FAIL][33] ([fdo#103232]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl5/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-skl5/igt@kms_cursor_crc@pipe-a-cursor-size-change.html

  * igt@kms_cursor_crc@pipe-c-cursor-256x85-onscreen:
    - shard-iclb:         [INCOMPLETE][35] ([fdo#107713]) -> [PASS][36] +1 similar issue
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb7/igt@kms_cursor_crc@pipe-c-cursor-256x85-onscreen.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb8/igt@kms_cursor_crc@pipe-c-cursor-256x85-onscreen.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
    - shard-skl:          [FAIL][37] ([fdo#100368]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl4/igt@kms_flip@plain-flip-fb-recreate-interruptible.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-skl3/igt@kms_flip@plain-flip-fb-recreate-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-iclb:         [FAIL][39] ([fdo#103167]) -> [PASS][40] +5 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
    - shard-apl:          [INCOMPLETE][41] ([fdo#103927]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl1/igt@kms_plane@pixel-format-pipe-a-planes-source-clamping.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-apl6/igt@kms_plane@pixel-format-pipe-a-planes-source-clamping.html

  * igt@kms_plane_lowres@pipe-a-tiling-y:
    - shard-iclb:         [FAIL][43] ([fdo#103166]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-y.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb6/igt@kms_plane_lowres@pipe-a-tiling-y.html

  * igt@kms_psr@psr2_primary_blt:
    - shard-iclb:         [SKIP][45] ([fdo#109441]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb7/igt@kms_psr@psr2_primary_blt.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb2/igt@kms_psr@psr2_primary_blt.html

  * igt@kms_sequence@queue-idle:
    - shard-hsw:          [DMESG-WARN][47] ([fdo#102614]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-hsw5/igt@kms_sequence@queue-idle.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-hsw1/igt@kms_sequence@queue-idle.html

  * igt@perf@blocking:
    - shard-skl:          [FAIL][49] ([fdo#110728]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl1/igt@perf@blocking.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-skl7/igt@perf@blocking.html

  * igt@prime_vgem@fence-wait-bsd2:
    - shard-iclb:         [SKIP][51] ([fdo#109276]) -> [PASS][52] +12 similar issues
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb6/igt@prime_vgem@fence-wait-bsd2.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb1/igt@prime_vgem@fence-wait-bsd2.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs1-nonpriv:
    - shard-iclb:         [SKIP][53] ([fdo#109276]) -> [FAIL][54] ([fdo#111329])
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb6/igt@gem_ctx_isolation@vcs1-nonpriv.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14528/shard-iclb1/igt@gem_ctx_isolation@vcs1-nonpriv.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#108341]: https://bugs.freedesktop.org/show_bug.cgi?id=108341
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#109661]: https://bugs.freedesktop.org/show_bug.cgi?id=109661
  [fdo#110548]: https://bugs.freedesktop.org/show_bug.cgi?id=110548
  [fdo#110728]: https://bugs.freedesktop.org/show_bug.cgi?id=110728
  [fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
  [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111325]: https://bugs.freedesktop.org/show_bug.cgi?id=111325
  [fdo#111329]: https://bugs.freedesktop.org/show_bug.cgi?id=111329


Participating hosts (15 -> 9)
------------------------------

  Missing    (6): shard-tglb1 shard-tglb2 shard-tglb3 shard-tglb4 shard-tglb5 shard-tglb6 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6956 -> Patchwork_14528

  CI-20190529: 20190529
  CI_DRM_6956: e514b64998c2845943242b1d4dc2e568b01fddcb @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5202: 3499c5eb17054e2abd88023fe962768140d24302 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14528: 04ff25dfcc58ad4cbc704fa0191487417e493734 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

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

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

* Re: [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
  2019-09-25 12:17 [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth Stanislav Lisovskiy
                   ` (2 preceding siblings ...)
  2019-09-26  6:02 ` ✓ Fi.CI.IGT: " Patchwork
@ 2019-10-11 23:49 ` James Ausmus
  2019-10-14 11:13   ` Lisovskiy, Stanislav
  3 siblings, 1 reply; 10+ messages in thread
From: James Ausmus @ 2019-10-11 23:49 UTC (permalink / raw)
  To: Stanislav Lisovskiy; +Cc: intel-gfx, ville.syrjala, martin.peres

On Wed, Sep 25, 2019 at 03:17:37PM +0300, Stanislav Lisovskiy wrote:
> According to BSpec 53998, we should try to
> restrict qgv points, which can't provide
> enough bandwidth for desired display configuration.
> 
> Currently we are just comparing against all of
> those and take minimum(worst case).
> 
> v2: Fixed wrong PCode reply mask, removed hardcoded
>     values.
> 
> v3: Forbid simultaneous legacy SAGV PCode requests and
>     restricting qgv points. Put the actual restriction
>     to commit function, added serialization(thanks to Ville)
>     to prevent commit being applied out of order in case of
>     nonblocking and/or nomodeset commits.
> 
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@intel.com>
> Cc: James Ausmus <james.ausmus@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_atomic.c   | 16 ++++
>  drivers/gpu/drm/i915/display/intel_atomic.h   |  3 +
>  drivers/gpu/drm/i915/display/intel_bw.c       | 79 +++++++++++++------
>  drivers/gpu/drm/i915/display/intel_bw.h       |  2 +
>  drivers/gpu/drm/i915/display/intel_display.c  | 78 +++++++++++++++++-
>  .../drm/i915/display/intel_display_types.h    |  3 +
>  drivers/gpu/drm/i915/i915_drv.h               |  2 +
>  drivers/gpu/drm/i915/i915_reg.h               |  3 +
>  8 files changed, 160 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 698802da07b7..903537c4fb0f 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -208,6 +208,22 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>  	return &crtc_state->base;
>  }
>  
> +int intel_atomic_serialize_global_state(struct intel_atomic_state *state)
> +{
> +	struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> +	struct intel_crtc *crtc;
> +
> +	for_each_intel_crtc(&dev_priv->drm, crtc) {
> +		struct intel_crtc_state *crtc_state;
> +
> +		crtc_state = intel_atomic_get_crtc_state(&state->base, crtc);
> +		if (IS_ERR(crtc_state))
> +			return PTR_ERR(crtc_state);
> +	}
> +
> +	return 0;
> +}
> +

I'll leave reviewing the atomic serialization bits to Ville and I'll
just review the rest, as I don't have a good head for atomic at this
point...


>  /**
>   * intel_crtc_destroy_state - destroy crtc state
>   * @crtc: drm crtc
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h b/drivers/gpu/drm/i915/display/intel_atomic.h
> index 58065d3161a3..fd17b3ca257f 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.h
> @@ -7,6 +7,7 @@
>  #define __INTEL_ATOMIC_H__
>  
>  #include <linux/types.h>
> +#include "intel_display_types.h"
>  
>  struct drm_atomic_state;
>  struct drm_connector;
> @@ -38,6 +39,8 @@ void intel_crtc_destroy_state(struct drm_crtc *crtc,
>  struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
>  void intel_atomic_state_clear(struct drm_atomic_state *state);
>  
> +int intel_atomic_serialize_global_state(struct intel_atomic_state *state);
> +
>  struct intel_crtc_state *
>  intel_atomic_get_crtc_state(struct drm_atomic_state *state,
>  			    struct intel_crtc *crtc);
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
> index cd58e47ab7b2..81e3468306fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -8,6 +8,7 @@
>  #include "intel_bw.h"
>  #include "intel_display_types.h"
>  #include "intel_sideband.h"
> +#include "intel_atomic.h"
>  
>  /* Parameters for Qclk Geyserville (QGV) */
>  struct intel_qgv_point {
> @@ -90,6 +91,27 @@ static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv,
>  	return 0;
>  }
>  
> +int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> +				  u32 points_mask)
> +{
> +	int ret;
> +
> +	/* bspec says to keep retrying for at least 1 ms */
> +	ret = skl_pcode_request(dev_priv, ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
> +				points_mask,
> +				GEN11_PCODE_POINTS_RESTRICTED_MASK,
> +				GEN11_PCODE_POINTS_RESTRICTED,
> +				1);
> +
> +	if (ret < 0) {
> +		DRM_ERROR("Failed to disable qgv points (%d)\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +
>  static int icl_get_qgv_points(struct drm_i915_private *dev_priv,
>  			      struct intel_qgv_info *qi)
>  {
> @@ -247,22 +269,6 @@ void intel_bw_init_hw(struct drm_i915_private *dev_priv)
>  		icl_get_bw_info(dev_priv, &icl_sa_info);
>  }
>  
> -static unsigned int intel_max_data_rate(struct drm_i915_private *dev_priv,
> -					int num_planes)
> -{
> -	if (INTEL_GEN(dev_priv) >= 11)
> -		/*
> -		 * FIXME with SAGV disabled maybe we can assume
> -		 * point 1 will always be used? Seems to match
> -		 * the behaviour observed in the wild.
> -		 */
> -		return min3(icl_max_bw(dev_priv, num_planes, 0),
> -			    icl_max_bw(dev_priv, num_planes, 1),
> -			    icl_max_bw(dev_priv, num_planes, 2));
> -	else
> -		return UINT_MAX;
> -}
> -
>  static unsigned int intel_bw_crtc_num_active_planes(const struct intel_crtc_state *crtc_state)
>  {
>  	/*
> @@ -354,7 +360,9 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
>  	unsigned int data_rate, max_data_rate;
>  	unsigned int num_active_planes;
>  	struct intel_crtc *crtc;
> -	int i;
> +	int i, ret;
> +	struct intel_qgv_info qi = {};
> +	u32 allowed_points = 0;
>  
>  	/* FIXME earlier gens need some checks too */
>  	if (INTEL_GEN(dev_priv) < 11)
> @@ -398,16 +406,43 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
>  	data_rate = intel_bw_data_rate(dev_priv, bw_state);
>  	num_active_planes = intel_bw_num_active_planes(dev_priv, bw_state);
>  
> -	max_data_rate = intel_max_data_rate(dev_priv, num_active_planes);
> -
>  	data_rate = DIV_ROUND_UP(data_rate, 1000);
>  
> -	if (data_rate > max_data_rate) {
> -		DRM_DEBUG_KMS("Bandwidth %u MB/s exceeds max available %d MB/s (%d active planes)\n",
> -			      data_rate, max_data_rate, num_active_planes);
> +	ret = icl_get_qgv_points(dev_priv, &qi);
> +	if (ret < 0)
> +		return 0;
> +
> +	for (i = 0; i < qi.num_points; i++) {
> +		max_data_rate = icl_max_bw(dev_priv, num_active_planes, i);
> +		if (max_data_rate < data_rate)
> +			DRM_DEBUG_KMS("QGV point %d: max bw %d required %d\n",
> +				      i, max_data_rate, data_rate);
> +		else {
> +			DRM_DEBUG_KMS("QGV point %d: max bw %d required %d\n",
> +				      i, max_data_rate, data_rate);

You're doing the same debug print either way - move it out of the if, and then
that simplifies your blocks:

if (max_data_rate >= data_rate)
	allowed_points |= 1 << i;
DRM_DEBUG_KMS...

> +			allowed_points |= 1 << i;
> +		}

According to the BSpec page, we also need to save off the QGV point that has
the most available bandwidth:

"At least one GV point must always remain unmasked. The point providing the
highest bandwidth for display must always remain unmasked."

We should stash that point separately, and ensure it always remains unmasked.

> +	}
> +
> +	if (allowed_points == 0) {
> +		DRM_DEBUG_KMS("Could not find any suitable QGV points\n");
>  		return -EINVAL;
>  	}
>  
> +	state->qgv_points_mask = (~allowed_points) & ((1 << qi.num_points) - 1);
> +
> +	/*
> +	 * If the actual mask had changed we need to make sure that
> +	 * the commits are serialized(in case this is a nomodeset, nonblocking)
> +	 */
> +	if (state->qgv_points_mask != dev_priv->qgv_points_mask) {
> +		ret = intel_atomic_serialize_global_state(state);
> +		if (ret) {
> +			DRM_DEBUG_KMS("Could not serialize global state\n");
> +			return ret;
> +		}
> +	}
> +
>  	return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h
> index 9db10af012f4..66bf9bc10b73 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -28,5 +28,7 @@ int intel_bw_init(struct drm_i915_private *dev_priv);
>  int intel_bw_atomic_check(struct intel_atomic_state *state);
>  void intel_bw_crtc_update(struct intel_bw_state *bw_state,
>  			  const struct intel_crtc_state *crtc_state);
> +int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> +				  u32 points_mask);
>  
>  #endif /* __INTEL_BW_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 5ecf54270181..c3196d0e4be3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13960,6 +13960,68 @@ static void intel_atomic_cleanup_work(struct work_struct *work)
>  	intel_atomic_helper_free_state(i915);
>  }
>  
> +static void intel_qgv_point_pre_update(struct intel_atomic_state *state)

It would be nice to name this either "mask" or "unmask", so it's easier
at first glance to see which function is turning on masked bits vs
toggling them off.

> +{
> +	struct drm_device *dev = state->base.dev;
> +	struct drm_i915_private *dev_priv = to_i915(dev);
> +	int i, ret;
> +
> +	/*
> +	 * Restrict required qgv points before updating the configuration.
> +	 * According to BPsec we can't mask and unmask qgv points at the same

s/BPsec/BSpec/

> +	 * time. Also masking should be done before updating the configuration
> +	 * and unmasking afterwards.
> +	 */
> +	u32 new_qgv_points_mask = dev_priv->qgv_points_mask;
> +	int num_points = dev_priv->max_bw[0].num_qgv_points;
> +
> +	for (i = num_points; i > 0; i--) {
> +		int new_mask_bit = state->qgv_points_mask & (1 << num_points);
> +		int old_mask_bit = new_qgv_points_mask & (1 << num_points);

The naming here is spinning my head a bit, as we're getting the
"old_mask_bit" from the "new_qgv_points_mask".

> +
> +		if (old_mask_bit != new_mask_bit)
> +			if (new_mask_bit != 0)

Can't this just be

if (new_mask_bit)
        new_qgv_points_mask |= new_mask_bit;

?

Since the only way that (old_mask_bit != new_mask_bit) is when we're
going from a 0 to a 1, and it's ok to go from a 1 to a 1, so the only
thing that matters here is new_mask_bit, right? If that's the case,
can't you just drop the old_mask_bit parts entirely? Or am I confusing
myself with the naming? :)


Actually, wouldn't the whole function at that point just be:

ret = icl_pcode_restrict_qgv_points(dev_priv, dev_priv->qgv_points_mask | state->qgv_points_mask);


Since you're just wanting to "turn on" masking points in the _pre, and
leave the "turn off" of masking points to the _post?

> +				new_qgv_points_mask |= new_mask_bit;
> +	}
> +
> +	ret = icl_pcode_restrict_qgv_points(dev_priv, new_qgv_points_mask);
> +	if (ret < 0)
> +		DRM_DEBUG_KMS("Could not restrict required gqv points(%d)\n", ret);

s/gqv/qgv/


Also, if we fail masking off the qgv points that can't support our BW
req, shouldn't we handle that failure somehow - maybe just disable SAGV
entirely?  Better we lose power than have flickering screens...

> +	else
> +		dev_priv->qgv_points_mask = new_qgv_points_mask;
> +}
> +
> +static void intel_qgv_point_post_update(struct intel_atomic_state *state)

Same comment on the naming

> +{
> +	struct drm_device *dev = state->base.dev;
> +	struct drm_i915_private *dev_priv = to_i915(dev);
> +	int i, ret;
> +
> +	/*
> +	 * Restrict required qgv points before updating the configuration.
> +	 * According to BPsec we can't mask and unmask qgv points at the same

s/BPsec/BSpec/

> +	 * time. Also masking should be done before updating the configuration
> +	 * and unmasking afterwards.
> +	 */
> +	u32 new_qgv_points_mask = dev_priv->qgv_points_mask;
> +	int num_points = dev_priv->max_bw[0].num_qgv_points;
> +
> +	for (i = num_points; i > 0; i--) {
> +		int new_mask_bit = state->qgv_points_mask & (1 << num_points);
> +		int old_mask_bit = new_qgv_points_mask & (1 << num_points);
> +
> +		if (old_mask_bit != new_mask_bit)
> +			if (new_mask_bit == 0)
> +				new_qgv_points_mask &= ~old_mask_bit;
> +	}

Same comment here - can't this really be simplified to:

ret = icl_pcode_restrict_qgv_points(dev_priv, dev_priv->qgv_points_mask & state->qgv_points_mask);

Since here we're just wnating to "turn off" the mask for points that the
new state allows, and we should have already "turned on" all the points
in _pre?

> +
> +	ret = icl_pcode_restrict_qgv_points(dev_priv, new_qgv_points_mask);
> +	if (ret < 0)
> +		DRM_DEBUG_KMS("Could not restrict required gqv points(%d)\n", ret);

Maybe change the error message to something like "Could not enable
required qgv points", so it's more easily differentiated?

Same here about error handling - if we fail to enable qgv points that
may be required, we might just want to entirely disable SAGV, as we
might not have a point that works for our BW reqs, and it's better to
lose power than flicker.

> +	else
> +		dev_priv->qgv_points_mask = new_qgv_points_mask;
> +}
> +
>  static void intel_atomic_commit_tail(struct intel_atomic_state *state)
>  {
>  	struct drm_device *dev = state->base.dev;
> @@ -13987,6 +14049,9 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
>  		}
>  	}
>  
> +	if ((INTEL_GEN(dev_priv) >= 11))
> +		intel_qgv_point_pre_update(state);
> +
>  	intel_commit_modeset_disables(state);
>  
>  	/* FIXME: Eventually get rid of our crtc->config pointer */
> @@ -14005,8 +14070,9 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
>  		 * SKL workaround: bspec recommends we disable the SAGV when we
>  		 * have more then one pipe enabled
>  		 */
> -		if (!intel_can_enable_sagv(state))
> -			intel_disable_sagv(dev_priv);
> +		if (INTEL_GEN(dev_priv) < 11)
> +			if (!intel_can_enable_sagv(state))
> +				intel_disable_sagv(dev_priv);
>  
>  		intel_modeset_verify_disabled(dev_priv, state);
>  	}
> @@ -14084,8 +14150,12 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
>  	if (state->modeset)
>  		intel_verify_planes(state);
>  
> -	if (state->modeset && intel_can_enable_sagv(state))
> -		intel_enable_sagv(dev_priv);
> +	if (INTEL_GEN(dev_priv) < 11)
> +		if (state->modeset && intel_can_enable_sagv(state))
> +			intel_enable_sagv(dev_priv);
> +
> +	if ((INTEL_GEN(dev_priv) >= 11) && intel_can_enable_sagv(state))
> +		intel_qgv_point_post_update(state);

I keep going back and forth in my mind about the above block - what do you
think of doing it this way?

if (intel_can_enable_sagv(state)) {
        if (INTEL_GEN(dev_priv) >= 11)
                intel_qgv_point_post_update(state);
        else if (state->modeset)
                intel_enable_sagv(dev_priv);
}


Feels a little cleaner, I think, and lets us keep our standard New Gen -> Old
Gen if ladder style - but I'm not 100% sold on it myself :)


Thanks!

-James

>  
>  	drm_atomic_helper_commit_hw_done(&state->base);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 6b0a646f0170..82f8df65347e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -512,6 +512,9 @@ struct intel_atomic_state {
>  	struct i915_sw_fence commit_ready;
>  
>  	struct llist_node freed;
> +
> +	/* Gen11+ only */
> +	u32 qgv_points_mask;
>  };
>  
>  struct intel_plane_state {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fcf7423075ef..383de77a7b73 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1652,6 +1652,8 @@ struct drm_i915_private {
>  		u8 num_planes;
>  	} max_bw[6];
>  
> +	u32 qgv_points_mask;
> +
>  	struct drm_private_obj bw_obj;
>  
>  	struct intel_runtime_pm runtime_pm;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e752de9470bd..c78ee180c1aa 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8854,6 +8854,7 @@ enum {
>  #define   ICL_PCODE_MEM_SUBSYSYSTEM_INFO	0xd
>  #define     ICL_PCODE_MEM_SS_READ_GLOBAL_INFO	(0x0 << 8)
>  #define     ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)	(((point) << 16) | (0x1 << 8))
> +#define   ICL_PCODE_SAGV_DE_MEM_SS_CONFIG	0xe
>  #define   GEN6_PCODE_READ_D_COMP		0x10
>  #define   GEN6_PCODE_WRITE_D_COMP		0x11
>  #define   HSW_PCODE_DE_WRITE_FREQ_REQ		0x17
> @@ -8865,6 +8866,8 @@ enum {
>  #define     GEN9_SAGV_DISABLE			0x0
>  #define     GEN9_SAGV_IS_DISABLED		0x1
>  #define     GEN9_SAGV_ENABLE			0x3
> +#define GEN11_PCODE_POINTS_RESTRICTED		0x0
> +#define GEN11_PCODE_POINTS_RESTRICTED_MASK	0x1
>  #define GEN6_PCODE_DATA				_MMIO(0x138128)
>  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT	8
>  #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT	16
> -- 
> 2.17.1
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
  2019-10-11 23:49 ` [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth James Ausmus
@ 2019-10-14 11:13   ` Lisovskiy, Stanislav
  2019-10-14 14:50     ` Ville Syrjälä
  2019-10-14 16:32     ` James Ausmus
  0 siblings, 2 replies; 10+ messages in thread
From: Lisovskiy, Stanislav @ 2019-10-14 11:13 UTC (permalink / raw)
  To: Ausmus, James; +Cc: intel-gfx, Syrjala, Ville, Peres, Martin

On Fri, 2019-10-11 at 16:49 -0700, James Ausmus wrote:
> On Wed, Sep 25, 2019 at 03:17:37PM +0300, Stanislav Lisovskiy wrote:
> > According to BSpec 53998, we should try to
> > restrict qgv points, which can't provide
> > enough bandwidth for desired display configuration.
> > 
> > Currently we are just comparing against all of
> > those and take minimum(worst case).
> > 
> > v2: Fixed wrong PCode reply mask, removed hardcoded
> >     values.
> > 
> > v3: Forbid simultaneous legacy SAGV PCode requests and
> >     restricting qgv points. Put the actual restriction
> >     to commit function, added serialization(thanks to Ville)
> >     to prevent commit being applied out of order in case of
> >     nonblocking and/or nomodeset commits.

Hi James,

Thank you for great review! 

While many of your comments are definitely
good findings, still will leave reply to a few,
just to keep things clear.


> > 
> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@intel.com>
> > Cc: James Ausmus <james.ausmus@intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_atomic.c   | 16 ++++
> >  drivers/gpu/drm/i915/display/intel_atomic.h   |  3 +
> >  drivers/gpu/drm/i915/display/intel_bw.c       | 79 +++++++++++++
> > ------
> >  drivers/gpu/drm/i915/display/intel_bw.h       |  2 +
> >  drivers/gpu/drm/i915/display/intel_display.c  | 78
> > +++++++++++++++++-
> >  .../drm/i915/display/intel_display_types.h    |  3 +
> >  drivers/gpu/drm/i915/i915_drv.h               |  2 +
> >  drivers/gpu/drm/i915/i915_reg.h               |  3 +
> >  8 files changed, 160 insertions(+), 26 deletions(-)

> if (max_data_rate >= data_rate)
> 	allowed_points |= 1 << i;
> DRM_DEBUG_KMS...
> 
> > +			allowed_points |= 1 << i;
> > +		}
> 
> According to the BSpec page, we also need to save off the QGV point
> that has
> the most available bandwidth:
> 
> "At least one GV point must always remain unmasked. The point
> providing the
> highest bandwidth for display must always remain unmasked."
> 
> We should stash that point separately, and ensure it always remains
> unmasked.
> 
> > +	}
> > +
> > +	if (allowed_points == 0) {
> > +		DRM_DEBUG_KMS("Could not find any suitable QGV
> > points\n");
> >  		return -EINVAL;
> >  	}

This actually guarantees that, I think - we will never allow a 
config which will require us to mask all of the points to work.

> >  
> > +	state->qgv_points_mask = (~allowed_points) & ((1 <<
> > qi.num_points) - 1);
> > +
> > +	/*
> > +	 * If the actual mask had changed we need to make sure that
> > +	 * the commits are serialized(in case this is a nomodeset,
> > nonblocking)
> > +	 */
> > +	if (state->qgv_points_mask != dev_priv->qgv_points_mask) {
> > +		ret = intel_atomic_serialize_global_state(state);
> > +		if (ret) {
> > +			DRM_DEBUG_KMS("Could not serialize global
> > state\n");
> > +			return ret;
> > +		}
> > +	}
> > +
> >  	return 0;
> >  }
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > b/drivers/gpu/drm/i915/display/intel_bw.h
> > index 9db10af012f4..66bf9bc10b73 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > @@ -28,5 +28,7 @@ int intel_bw_init(struct drm_i915_private
> > *dev_priv);
> >  int intel_bw_atomic_check(struct intel_atomic_state *state);
> >  void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> >  			  const struct intel_crtc_state *crtc_state);
> > +int icl_pcode_restrict_qgv_points(struct drm_i915_private
> > *dev_priv,
> > +				  u32 points_mask);
> >  
> >  #endif /* __INTEL_BW_H__ */
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 5ecf54270181..c3196d0e4be3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -13960,6 +13960,68 @@ static void
> > intel_atomic_cleanup_work(struct work_struct *work)
> >  	intel_atomic_helper_free_state(i915);
> >  }
> >  
> > +static void intel_qgv_point_pre_update(struct intel_atomic_state
> > *state)
> 
> It would be nice to name this either "mask" or "unmask", so it's
> easier
> at first glance to see which function is turning on masked bits vs
> toggling them off.
> 
> > +{
> > +	struct drm_device *dev = state->base.dev;
> > +	struct drm_i915_private *dev_priv = to_i915(dev);
> > +	int i, ret;
> > +
> > +	/*
> > +	 * Restrict required qgv points before updating the
> > configuration.
> > +	 * According to BPsec we can't mask and unmask qgv points at
> > the same
> 
> s/BPsec/BSpec/
> 
> > +	 * time. Also masking should be done before updating the
> > configuration
> > +	 * and unmasking afterwards.
> > +	 */
> > +	u32 new_qgv_points_mask = dev_priv->qgv_points_mask;
> > +	int num_points = dev_priv->max_bw[0].num_qgv_points;
> > +
> > +	for (i = num_points; i > 0; i--) {
> > +		int new_mask_bit = state->qgv_points_mask & (1 <<
> > num_points);
> > +		int old_mask_bit = new_qgv_points_mask & (1 <<
> > num_points);
> 
> The naming here is spinning my head a bit, as we're getting the
> "old_mask_bit" from the "new_qgv_points_mask".
> 
> > +
> > +		if (old_mask_bit != new_mask_bit)
> > +			if (new_mask_bit != 0)
> 
> Can't this just be
> 
> if (new_mask_bit)
>         new_qgv_points_mask |= new_mask_bit;
> 
> ?
> 
> Since the only way that (old_mask_bit != new_mask_bit) is when we're
> going from a 0 to a 1, and it's ok to go from a 1 to a 1, so the only
> thing that matters here is new_mask_bit, right? If that's the case,
> can't you just drop the old_mask_bit parts entirely? Or am I
> confusing
> myself with the naming? :)
> 
> 
> Actually, wouldn't the whole function at that point just be:
> 
> ret = icl_pcode_restrict_qgv_points(dev_priv, dev_priv-
> >qgv_points_mask | state->qgv_points_mask);

Sure it could be, however for some reason I thought that you can 
mask/unmask only one point per request. However now can't find that in
BSpec - just states that you can only mask or unmask points(was it my
mistake or did somebody edit it?), but not both, so if I won't find any
contradiction here, that is definitely way to go :)

> 
> 
> Since you're just wanting to "turn on" masking points in the _pre,
> and
> leave the "turn off" of masking points to the _post?
> 
> > +				new_qgv_points_mask |= new_mask_bit;
> > +	}
> > +
> > +	ret = icl_pcode_restrict_qgv_points(dev_priv,
> > new_qgv_points_mask);
> > +	if (ret < 0)
> > +		DRM_DEBUG_KMS("Could not restrict required gqv
> > points(%d)\n", ret);
> 
> s/gqv/qgv/
> 
> 
> Also, if we fail masking off the qgv points that can't support our BW
> req, shouldn't we handle that failure somehow - maybe just disable
> SAGV
> entirely?  Better we lose power than have flickering screens...

Sounds reasonable, need to discuss that with Ville. However I would 
may be still stick to simply rejecting that config and assume that
at least currently we are ok, otherwise if we can't even succeed with 
sending a PCode request to restrict points, means that something is so 
weird that we might not succeed with disabling it as well.

> 
> > +	else
> > +		dev_priv->qgv_points_mask = new_qgv_points_mask;
> > +}
> > +
> > +static void intel_qgv_point_post_update(struct intel_atomic_state
> > *state)
> 
> Same comment on the naming
> 
> > +{
> > +	struct drm_device *dev = state->base.dev;
> > +	struct drm_i915_private *dev_priv = to_i915(dev);
> > +	int i, ret;
> > +
> > +	/*
> > +	 * Restrict required qgv points before updating the
> > configuration.
> > +	 * According to BPsec we can't mask and unmask qgv points at
> > the same
> 
> s/BPsec/BSpec/
> 
> > +	 * time. Also masking should be done before updating the
> > configuration
> > +	 * and unmasking afterwards.
> > +	 */
> > +	u32 new_qgv_points_mask = dev_priv->qgv_points_mask;
> > +	int num_points = dev_priv->max_bw[0].num_qgv_points;
> > +
> > +	for (i = num_points; i > 0; i--) {
> > +		int new_mask_bit = state->qgv_points_mask & (1 <<
> > num_points);
> > +		int old_mask_bit = new_qgv_points_mask & (1 <<
> > num_points);
> > +
> > +		if (old_mask_bit != new_mask_bit)
> > +			if (new_mask_bit == 0)
> > +				new_qgv_points_mask &= ~old_mask_bit;
> > +	}
> 
> Same comment here - can't this really be simplified to:
> 
> ret = icl_pcode_restrict_qgv_points(dev_priv, dev_priv-
> >qgv_points_mask & state->qgv_points_mask);
> 
> Since here we're just wnating to "turn off" the mask for points that
> the
> new state allows, and we should have already "turned on" all the
> points
> in _pre?
> 
> > +
> > +	ret = icl_pcode_restrict_qgv_points(dev_priv,
> > new_qgv_points_mask);
> > +	if (ret < 0)
> > +		DRM_DEBUG_KMS("Could not restrict required gqv
> > points(%d)\n", ret);
> 
> Maybe change the error message to something like "Could not enable
> required qgv points", so it's more easily differentiated?
> 
> Same here about error handling - if we fail to enable qgv points that
> may be required, we might just want to entirely disable SAGV, as we
> might not have a point that works for our BW reqs, and it's better to
> lose power than flicker.

In addition to what I said above I also know remembered a concern
regarding that we probably shouldn't combine intel_enable/disable_sagv
and this new Pcode request, so for sake of simplicity may be just
reject that config? We really need to discuss this.

> 
> > +	else
> > +		dev_priv->qgv_points_mask = new_qgv_points_mask;
> > +}
> > +
> >  static void intel_atomic_commit_tail(struct intel_atomic_state
> > *state)
> >  {
> >  	struct drm_device *dev = state->base.dev;
> > @@ -13987,6 +14049,9 @@ static void intel_atomic_commit_tail(struct
> > intel_atomic_state *state)
> >  		}
> >  	}
> >  
> > +	if ((INTEL_GEN(dev_priv) >= 11))
> > +		intel_qgv_point_pre_update(state);
> > +
> >  	intel_commit_modeset_disables(state);
> >  
> >  	/* FIXME: Eventually get rid of our crtc->config pointer */
> > @@ -14005,8 +14070,9 @@ static void intel_atomic_commit_tail(struct
> > intel_atomic_state *state)
> >  		 * SKL workaround: bspec recommends we disable the SAGV
> > when we
> >  		 * have more then one pipe enabled
> >  		 */
> > -		if (!intel_can_enable_sagv(state))
> > -			intel_disable_sagv(dev_priv);
> > +		if (INTEL_GEN(dev_priv) < 11)
> > +			if (!intel_can_enable_sagv(state))
> > +				intel_disable_sagv(dev_priv);
> >  
> >  		intel_modeset_verify_disabled(dev_priv, state);
> >  	}
> > @@ -14084,8 +14150,12 @@ static void
> > intel_atomic_commit_tail(struct intel_atomic_state *state)
> >  	if (state->modeset)
> >  		intel_verify_planes(state);
> >  
> > -	if (state->modeset && intel_can_enable_sagv(state))
> > -		intel_enable_sagv(dev_priv);
> > +	if (INTEL_GEN(dev_priv) < 11)
> > +		if (state->modeset && intel_can_enable_sagv(state))
> > +			intel_enable_sagv(dev_priv);
> > +
> > +	if ((INTEL_GEN(dev_priv) >= 11) &&
> > intel_can_enable_sagv(state))
> > +		intel_qgv_point_post_update(state);
> 
> I keep going back and forth in my mind about the above block - what
> do you
> think of doing it this way?
> 
> if (intel_can_enable_sagv(state)) {
>         if (INTEL_GEN(dev_priv) >= 11)
>                 intel_qgv_point_post_update(state);
>         else if (state->modeset)
>                 intel_enable_sagv(dev_priv);
> }
> 
> 
> Feels a little cleaner, I think, and lets us keep our standard New
> Gen -> Old
> Gen if ladder style - but I'm not 100% sold on it myself :)
> 
> 
> Thanks!
> 
> -James
> 
> >  
> >  	drm_atomic_helper_commit_hw_done(&state->base);
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 6b0a646f0170..82f8df65347e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -512,6 +512,9 @@ struct intel_atomic_state {
> >  	struct i915_sw_fence commit_ready;
> >  
> >  	struct llist_node freed;
> > +
> > +	/* Gen11+ only */
> > +	u32 qgv_points_mask;
> >  };
> >  
> >  struct intel_plane_state {
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index fcf7423075ef..383de77a7b73 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1652,6 +1652,8 @@ struct drm_i915_private {
> >  		u8 num_planes;
> >  	} max_bw[6];
> >  
> > +	u32 qgv_points_mask;
> > +
> >  	struct drm_private_obj bw_obj;
> >  
> >  	struct intel_runtime_pm runtime_pm;
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index e752de9470bd..c78ee180c1aa 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -8854,6 +8854,7 @@ enum {
> >  #define   ICL_PCODE_MEM_SUBSYSYSTEM_INFO	0xd
> >  #define     ICL_PCODE_MEM_SS_READ_GLOBAL_INFO	(0x0 << 8)
> >  #define     ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)	(((poin
> > t) << 16) | (0x1 << 8))
> > +#define   ICL_PCODE_SAGV_DE_MEM_SS_CONFIG	0xe
> >  #define   GEN6_PCODE_READ_D_COMP		0x10
> >  #define   GEN6_PCODE_WRITE_D_COMP		0x11
> >  #define   HSW_PCODE_DE_WRITE_FREQ_REQ		0x17
> > @@ -8865,6 +8866,8 @@ enum {
> >  #define     GEN9_SAGV_DISABLE			0x0
> >  #define     GEN9_SAGV_IS_DISABLED		0x1
> >  #define     GEN9_SAGV_ENABLE			0x3
> > +#define GEN11_PCODE_POINTS_RESTRICTED		0x0
> > +#define GEN11_PCODE_POINTS_RESTRICTED_MASK	0x1
> >  #define GEN6_PCODE_DATA				_MMIO(0x138128)
> >  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT	8
> >  #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT	16
> > -- 
> > 2.17.1
> > 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
  2019-10-14 11:13   ` Lisovskiy, Stanislav
@ 2019-10-14 14:50     ` Ville Syrjälä
  2019-10-14 16:33       ` James Ausmus
  2019-10-14 16:32     ` James Ausmus
  1 sibling, 1 reply; 10+ messages in thread
From: Ville Syrjälä @ 2019-10-14 14:50 UTC (permalink / raw)
  To: Lisovskiy, Stanislav; +Cc: intel-gfx, Peres, Martin

On Mon, Oct 14, 2019 at 02:13:31PM +0300, Lisovskiy, Stanislav wrote:
> On Fri, 2019-10-11 at 16:49 -0700, James Ausmus wrote:
> > > +				new_qgv_points_mask |= new_mask_bit;
> > > +	}
> > > +
> > > +	ret = icl_pcode_restrict_qgv_points(dev_priv,
> > > new_qgv_points_mask);
> > > +	if (ret < 0)
> > > +		DRM_DEBUG_KMS("Could not restrict required gqv
> > > points(%d)\n", ret);
> > 
> > s/gqv/qgv/
> > 
> > 
> > Also, if we fail masking off the qgv points that can't support our BW
> > req, shouldn't we handle that failure somehow - maybe just disable
> > SAGV
> > entirely?  Better we lose power than have flickering screens...

Sounds like dead code to me. My approach is: don't deal with hw/firmware
failures until they are proven to exist.

The debug msg should be an error so that we get a bug report if this
ever happens.

-- 
Ville Syrjälä
Intel
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

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

* Re: [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
  2019-10-14 11:13   ` Lisovskiy, Stanislav
  2019-10-14 14:50     ` Ville Syrjälä
@ 2019-10-14 16:32     ` James Ausmus
  1 sibling, 0 replies; 10+ messages in thread
From: James Ausmus @ 2019-10-14 16:32 UTC (permalink / raw)
  To: Lisovskiy, Stanislav; +Cc: intel-gfx, Syrjala, Ville, Peres, Martin

On Mon, Oct 14, 2019 at 04:13:31AM -0700, Lisovskiy, Stanislav wrote:
> On Fri, 2019-10-11 at 16:49 -0700, James Ausmus wrote:
> > On Wed, Sep 25, 2019 at 03:17:37PM +0300, Stanislav Lisovskiy wrote:
> > > According to BSpec 53998, we should try to
> > > restrict qgv points, which can't provide
> > > enough bandwidth for desired display configuration.
> > > 
> > > Currently we are just comparing against all of
> > > those and take minimum(worst case).
> > > 
> > > v2: Fixed wrong PCode reply mask, removed hardcoded
> > >     values.
> > > 
> > > v3: Forbid simultaneous legacy SAGV PCode requests and
> > >     restricting qgv points. Put the actual restriction
> > >     to commit function, added serialization(thanks to Ville)
> > >     to prevent commit being applied out of order in case of
> > >     nonblocking and/or nomodeset commits.
> 
> Hi James,
> 
> Thank you for great review! 
> 
> While many of your comments are definitely
> good findings, still will leave reply to a few,
> just to keep things clear.
> 
> 
> > > 
> > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@intel.com>
> > > Cc: James Ausmus <james.ausmus@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_atomic.c   | 16 ++++
> > >  drivers/gpu/drm/i915/display/intel_atomic.h   |  3 +
> > >  drivers/gpu/drm/i915/display/intel_bw.c       | 79 +++++++++++++
> > > ------
> > >  drivers/gpu/drm/i915/display/intel_bw.h       |  2 +
> > >  drivers/gpu/drm/i915/display/intel_display.c  | 78
> > > +++++++++++++++++-
> > >  .../drm/i915/display/intel_display_types.h    |  3 +
> > >  drivers/gpu/drm/i915/i915_drv.h               |  2 +
> > >  drivers/gpu/drm/i915/i915_reg.h               |  3 +
> > >  8 files changed, 160 insertions(+), 26 deletions(-)
> 
> > if (max_data_rate >= data_rate)
> > 	allowed_points |= 1 << i;
> > DRM_DEBUG_KMS...
> > 
> > > +			allowed_points |= 1 << i;
> > > +		}
> > 
> > According to the BSpec page, we also need to save off the QGV point
> > that has
> > the most available bandwidth:
> > 
> > "At least one GV point must always remain unmasked. The point
> > providing the
> > highest bandwidth for display must always remain unmasked."
> > 
> > We should stash that point separately, and ensure it always remains
> > unmasked.
> > 
> > > +	}
> > > +
> > > +	if (allowed_points == 0) {
> > > +		DRM_DEBUG_KMS("Could not find any suitable QGV
> > > points\n");
> > >  		return -EINVAL;
> > >  	}
> 
> This actually guarantees that, I think - we will never allow a 
> config which will require us to mask all of the points to work.

Yeah, fair enough - if *any* points allow a high enough bandwidth, then
it's certain that the *highest* BW point will be unmasked. If *no*
points allow enough BW, then it doesn't matter anyway because we're
going to fail out and not allow that config...

Thanks!

-James

> 
> > >  
> > > +	state->qgv_points_mask = (~allowed_points) & ((1 <<
> > > qi.num_points) - 1);
> > > +
> > > +	/*
> > > +	 * If the actual mask had changed we need to make sure that
> > > +	 * the commits are serialized(in case this is a nomodeset,
> > > nonblocking)
> > > +	 */
> > > +	if (state->qgv_points_mask != dev_priv->qgv_points_mask) {
> > > +		ret = intel_atomic_serialize_global_state(state);
> > > +		if (ret) {
> > > +			DRM_DEBUG_KMS("Could not serialize global
> > > state\n");
> > > +			return ret;
> > > +		}
> > > +	}
> > > +
> > >  	return 0;
> > >  }
> > >  
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > index 9db10af012f4..66bf9bc10b73 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > @@ -28,5 +28,7 @@ int intel_bw_init(struct drm_i915_private
> > > *dev_priv);
> > >  int intel_bw_atomic_check(struct intel_atomic_state *state);
> > >  void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> > >  			  const struct intel_crtc_state *crtc_state);
> > > +int icl_pcode_restrict_qgv_points(struct drm_i915_private
> > > *dev_priv,
> > > +				  u32 points_mask);
> > >  
> > >  #endif /* __INTEL_BW_H__ */
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 5ecf54270181..c3196d0e4be3 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -13960,6 +13960,68 @@ static void
> > > intel_atomic_cleanup_work(struct work_struct *work)
> > >  	intel_atomic_helper_free_state(i915);
> > >  }
> > >  
> > > +static void intel_qgv_point_pre_update(struct intel_atomic_state
> > > *state)
> > 
> > It would be nice to name this either "mask" or "unmask", so it's
> > easier
> > at first glance to see which function is turning on masked bits vs
> > toggling them off.
> > 
> > > +{
> > > +	struct drm_device *dev = state->base.dev;
> > > +	struct drm_i915_private *dev_priv = to_i915(dev);
> > > +	int i, ret;
> > > +
> > > +	/*
> > > +	 * Restrict required qgv points before updating the
> > > configuration.
> > > +	 * According to BPsec we can't mask and unmask qgv points at
> > > the same
> > 
> > s/BPsec/BSpec/
> > 
> > > +	 * time. Also masking should be done before updating the
> > > configuration
> > > +	 * and unmasking afterwards.
> > > +	 */
> > > +	u32 new_qgv_points_mask = dev_priv->qgv_points_mask;
> > > +	int num_points = dev_priv->max_bw[0].num_qgv_points;
> > > +
> > > +	for (i = num_points; i > 0; i--) {
> > > +		int new_mask_bit = state->qgv_points_mask & (1 <<
> > > num_points);
> > > +		int old_mask_bit = new_qgv_points_mask & (1 <<
> > > num_points);
> > 
> > The naming here is spinning my head a bit, as we're getting the
> > "old_mask_bit" from the "new_qgv_points_mask".
> > 
> > > +
> > > +		if (old_mask_bit != new_mask_bit)
> > > +			if (new_mask_bit != 0)
> > 
> > Can't this just be
> > 
> > if (new_mask_bit)
> >         new_qgv_points_mask |= new_mask_bit;
> > 
> > ?
> > 
> > Since the only way that (old_mask_bit != new_mask_bit) is when we're
> > going from a 0 to a 1, and it's ok to go from a 1 to a 1, so the only
> > thing that matters here is new_mask_bit, right? If that's the case,
> > can't you just drop the old_mask_bit parts entirely? Or am I
> > confusing
> > myself with the naming? :)
> > 
> > 
> > Actually, wouldn't the whole function at that point just be:
> > 
> > ret = icl_pcode_restrict_qgv_points(dev_priv, dev_priv-
> > >qgv_points_mask | state->qgv_points_mask);
> 
> Sure it could be, however for some reason I thought that you can 
> mask/unmask only one point per request. However now can't find that in
> BSpec - just states that you can only mask or unmask points(was it my
> mistake or did somebody edit it?), but not both, so if I won't find any
> contradiction here, that is definitely way to go :)
> 
> > 
> > 
> > Since you're just wanting to "turn on" masking points in the _pre,
> > and
> > leave the "turn off" of masking points to the _post?
> > 
> > > +				new_qgv_points_mask |= new_mask_bit;
> > > +	}
> > > +
> > > +	ret = icl_pcode_restrict_qgv_points(dev_priv,
> > > new_qgv_points_mask);
> > > +	if (ret < 0)
> > > +		DRM_DEBUG_KMS("Could not restrict required gqv
> > > points(%d)\n", ret);
> > 
> > s/gqv/qgv/
> > 
> > 
> > Also, if we fail masking off the qgv points that can't support our BW
> > req, shouldn't we handle that failure somehow - maybe just disable
> > SAGV
> > entirely?  Better we lose power than have flickering screens...
> 
> Sounds reasonable, need to discuss that with Ville. However I would 
> may be still stick to simply rejecting that config and assume that
> at least currently we are ok, otherwise if we can't even succeed with 
> sending a PCode request to restrict points, means that something is so 
> weird that we might not succeed with disabling it as well.
> 
> > 
> > > +	else
> > > +		dev_priv->qgv_points_mask = new_qgv_points_mask;
> > > +}
> > > +
> > > +static void intel_qgv_point_post_update(struct intel_atomic_state
> > > *state)
> > 
> > Same comment on the naming
> > 
> > > +{
> > > +	struct drm_device *dev = state->base.dev;
> > > +	struct drm_i915_private *dev_priv = to_i915(dev);
> > > +	int i, ret;
> > > +
> > > +	/*
> > > +	 * Restrict required qgv points before updating the
> > > configuration.
> > > +	 * According to BPsec we can't mask and unmask qgv points at
> > > the same
> > 
> > s/BPsec/BSpec/
> > 
> > > +	 * time. Also masking should be done before updating the
> > > configuration
> > > +	 * and unmasking afterwards.
> > > +	 */
> > > +	u32 new_qgv_points_mask = dev_priv->qgv_points_mask;
> > > +	int num_points = dev_priv->max_bw[0].num_qgv_points;
> > > +
> > > +	for (i = num_points; i > 0; i--) {
> > > +		int new_mask_bit = state->qgv_points_mask & (1 <<
> > > num_points);
> > > +		int old_mask_bit = new_qgv_points_mask & (1 <<
> > > num_points);
> > > +
> > > +		if (old_mask_bit != new_mask_bit)
> > > +			if (new_mask_bit == 0)
> > > +				new_qgv_points_mask &= ~old_mask_bit;
> > > +	}
> > 
> > Same comment here - can't this really be simplified to:
> > 
> > ret = icl_pcode_restrict_qgv_points(dev_priv, dev_priv-
> > >qgv_points_mask & state->qgv_points_mask);
> > 
> > Since here we're just wnating to "turn off" the mask for points that
> > the
> > new state allows, and we should have already "turned on" all the
> > points
> > in _pre?
> > 
> > > +
> > > +	ret = icl_pcode_restrict_qgv_points(dev_priv,
> > > new_qgv_points_mask);
> > > +	if (ret < 0)
> > > +		DRM_DEBUG_KMS("Could not restrict required gqv
> > > points(%d)\n", ret);
> > 
> > Maybe change the error message to something like "Could not enable
> > required qgv points", so it's more easily differentiated?
> > 
> > Same here about error handling - if we fail to enable qgv points that
> > may be required, we might just want to entirely disable SAGV, as we
> > might not have a point that works for our BW reqs, and it's better to
> > lose power than flicker.
> 
> In addition to what I said above I also know remembered a concern
> regarding that we probably shouldn't combine intel_enable/disable_sagv
> and this new Pcode request, so for sake of simplicity may be just
> reject that config? We really need to discuss this.
> 
> > 
> > > +	else
> > > +		dev_priv->qgv_points_mask = new_qgv_points_mask;
> > > +}
> > > +
> > >  static void intel_atomic_commit_tail(struct intel_atomic_state
> > > *state)
> > >  {
> > >  	struct drm_device *dev = state->base.dev;
> > > @@ -13987,6 +14049,9 @@ static void intel_atomic_commit_tail(struct
> > > intel_atomic_state *state)
> > >  		}
> > >  	}
> > >  
> > > +	if ((INTEL_GEN(dev_priv) >= 11))
> > > +		intel_qgv_point_pre_update(state);
> > > +
> > >  	intel_commit_modeset_disables(state);
> > >  
> > >  	/* FIXME: Eventually get rid of our crtc->config pointer */
> > > @@ -14005,8 +14070,9 @@ static void intel_atomic_commit_tail(struct
> > > intel_atomic_state *state)
> > >  		 * SKL workaround: bspec recommends we disable the SAGV
> > > when we
> > >  		 * have more then one pipe enabled
> > >  		 */
> > > -		if (!intel_can_enable_sagv(state))
> > > -			intel_disable_sagv(dev_priv);
> > > +		if (INTEL_GEN(dev_priv) < 11)
> > > +			if (!intel_can_enable_sagv(state))
> > > +				intel_disable_sagv(dev_priv);
> > >  
> > >  		intel_modeset_verify_disabled(dev_priv, state);
> > >  	}
> > > @@ -14084,8 +14150,12 @@ static void
> > > intel_atomic_commit_tail(struct intel_atomic_state *state)
> > >  	if (state->modeset)
> > >  		intel_verify_planes(state);
> > >  
> > > -	if (state->modeset && intel_can_enable_sagv(state))
> > > -		intel_enable_sagv(dev_priv);
> > > +	if (INTEL_GEN(dev_priv) < 11)
> > > +		if (state->modeset && intel_can_enable_sagv(state))
> > > +			intel_enable_sagv(dev_priv);
> > > +
> > > +	if ((INTEL_GEN(dev_priv) >= 11) &&
> > > intel_can_enable_sagv(state))
> > > +		intel_qgv_point_post_update(state);
> > 
> > I keep going back and forth in my mind about the above block - what
> > do you
> > think of doing it this way?
> > 
> > if (intel_can_enable_sagv(state)) {
> >         if (INTEL_GEN(dev_priv) >= 11)
> >                 intel_qgv_point_post_update(state);
> >         else if (state->modeset)
> >                 intel_enable_sagv(dev_priv);
> > }
> > 
> > 
> > Feels a little cleaner, I think, and lets us keep our standard New
> > Gen -> Old
> > Gen if ladder style - but I'm not 100% sold on it myself :)
> > 
> > 
> > Thanks!
> > 
> > -James
> > 
> > >  
> > >  	drm_atomic_helper_commit_hw_done(&state->base);
> > >  
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 6b0a646f0170..82f8df65347e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -512,6 +512,9 @@ struct intel_atomic_state {
> > >  	struct i915_sw_fence commit_ready;
> > >  
> > >  	struct llist_node freed;
> > > +
> > > +	/* Gen11+ only */
> > > +	u32 qgv_points_mask;
> > >  };
> > >  
> > >  struct intel_plane_state {
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index fcf7423075ef..383de77a7b73 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1652,6 +1652,8 @@ struct drm_i915_private {
> > >  		u8 num_planes;
> > >  	} max_bw[6];
> > >  
> > > +	u32 qgv_points_mask;
> > > +
> > >  	struct drm_private_obj bw_obj;
> > >  
> > >  	struct intel_runtime_pm runtime_pm;
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index e752de9470bd..c78ee180c1aa 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -8854,6 +8854,7 @@ enum {
> > >  #define   ICL_PCODE_MEM_SUBSYSYSTEM_INFO	0xd
> > >  #define     ICL_PCODE_MEM_SS_READ_GLOBAL_INFO	(0x0 << 8)
> > >  #define     ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)	(((poin
> > > t) << 16) | (0x1 << 8))
> > > +#define   ICL_PCODE_SAGV_DE_MEM_SS_CONFIG	0xe
> > >  #define   GEN6_PCODE_READ_D_COMP		0x10
> > >  #define   GEN6_PCODE_WRITE_D_COMP		0x11
> > >  #define   HSW_PCODE_DE_WRITE_FREQ_REQ		0x17
> > > @@ -8865,6 +8866,8 @@ enum {
> > >  #define     GEN9_SAGV_DISABLE			0x0
> > >  #define     GEN9_SAGV_IS_DISABLED		0x1
> > >  #define     GEN9_SAGV_ENABLE			0x3
> > > +#define GEN11_PCODE_POINTS_RESTRICTED		0x0
> > > +#define GEN11_PCODE_POINTS_RESTRICTED_MASK	0x1
> > >  #define GEN6_PCODE_DATA				_MMIO(0x138128)
> > >  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT	8
> > >  #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT	16
> > > -- 
> > > 2.17.1
> > > 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
  2019-10-14 14:50     ` Ville Syrjälä
@ 2019-10-14 16:33       ` James Ausmus
  2019-10-14 16:46         ` Ville Syrjälä
  0 siblings, 1 reply; 10+ messages in thread
From: James Ausmus @ 2019-10-14 16:33 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx, Peres, Martin

On Mon, Oct 14, 2019 at 05:50:18PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 14, 2019 at 02:13:31PM +0300, Lisovskiy, Stanislav wrote:
> > On Fri, 2019-10-11 at 16:49 -0700, James Ausmus wrote:
> > > > +				new_qgv_points_mask |= new_mask_bit;
> > > > +	}
> > > > +
> > > > +	ret = icl_pcode_restrict_qgv_points(dev_priv,
> > > > new_qgv_points_mask);
> > > > +	if (ret < 0)
> > > > +		DRM_DEBUG_KMS("Could not restrict required gqv
> > > > points(%d)\n", ret);
> > > 
> > > s/gqv/qgv/
> > > 
> > > 
> > > Also, if we fail masking off the qgv points that can't support our BW
> > > req, shouldn't we handle that failure somehow - maybe just disable
> > > SAGV
> > > entirely?  Better we lose power than have flickering screens...
> 
> Sounds like dead code to me. My approach is: don't deal with hw/firmware
> failures until they are proven to exist.
> 
> The debug msg should be an error so that we get a bug report if this
> ever happens.

That works - however, I think we should return the error rather than
continuing.

-James

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

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

* Re: [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
  2019-10-14 16:33       ` James Ausmus
@ 2019-10-14 16:46         ` Ville Syrjälä
  0 siblings, 0 replies; 10+ messages in thread
From: Ville Syrjälä @ 2019-10-14 16:46 UTC (permalink / raw)
  To: James Ausmus; +Cc: intel-gfx, Ville Syrjälä, Peres, Martin

On Mon, Oct 14, 2019 at 09:33:32AM -0700, James Ausmus wrote:
> On Mon, Oct 14, 2019 at 05:50:18PM +0300, Ville Syrjälä wrote:
> > On Mon, Oct 14, 2019 at 02:13:31PM +0300, Lisovskiy, Stanislav wrote:
> > > On Fri, 2019-10-11 at 16:49 -0700, James Ausmus wrote:
> > > > > +				new_qgv_points_mask |= new_mask_bit;
> > > > > +	}
> > > > > +
> > > > > +	ret = icl_pcode_restrict_qgv_points(dev_priv,
> > > > > new_qgv_points_mask);
> > > > > +	if (ret < 0)
> > > > > +		DRM_DEBUG_KMS("Could not restrict required gqv
> > > > > points(%d)\n", ret);
> > > > 
> > > > s/gqv/qgv/
> > > > 
> > > > 
> > > > Also, if we fail masking off the qgv points that can't support our BW
> > > > req, shouldn't we handle that failure somehow - maybe just disable
> > > > SAGV
> > > > entirely?  Better we lose power than have flickering screens...
> > 
> > Sounds like dead code to me. My approach is: don't deal with hw/firmware
> > failures until they are proven to exist.
> > 
> > The debug msg should be an error so that we get a bug report if this
> > ever happens.
> 
> That works - however, I think we should return the error rather than
> continuing.

No. We're way past the point of no return.

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

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

end of thread, other threads:[~2019-10-14 16:46 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-25 12:17 [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth Stanislav Lisovskiy
2019-09-25 14:28 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Restrict qgv points which don't have enough bandwidth. (rev3) Patchwork
2019-09-25 15:01 ` ✓ Fi.CI.BAT: success " Patchwork
2019-09-26  6:02 ` ✓ Fi.CI.IGT: " Patchwork
2019-10-11 23:49 ` [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth James Ausmus
2019-10-14 11:13   ` Lisovskiy, Stanislav
2019-10-14 14:50     ` Ville Syrjälä
2019-10-14 16:33       ` James Ausmus
2019-10-14 16:46         ` Ville Syrjälä
2019-10-14 16:32     ` James Ausmus

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