All of lore.kernel.org
 help / color / mirror / Atom feed
* [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
@ 2020-03-19 16:38 Ville Syrjala
  2020-03-19 16:38 ` [Intel-gfx] [PATCH 2/3] drm: Refactor intel_dp_compute_link_config_*() Ville Syrjala
                   ` (6 more replies)
  0 siblings, 7 replies; 14+ messages in thread
From: Ville Syrjala @ 2020-03-19 16:38 UTC (permalink / raw)
  To: intel-gfx
  Cc: Matteo Iervasi, Jani Nikula, Albert Astals Cid, Emanuele Panigati

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

Some new eDP panels don't like to operate at the max parameters, and
instead we need to go for an optimal confiugration. That unfortunately
doesn't work with older eDP panels which are generally only guaranteed
to work at the max parameters.

To solve these two conflicting requirements let's start with the optimal
setup, and if that fails we start again with the max parameters. The
downside is probably an extra modeset when we switch strategies but
I don't see a good way to avoid that.

For a bit of history we first tried to go for the fast+narrow in
commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
fast and narrow"). but that had to be reverted due to regression
on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
to max link rate and lane count on eDP"). So now we try to get
the best of both worlds by using both strategies.

v2: Deal with output_bpp and uapi vs. hw state split
    Reword some comments

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
References: https://gitlab.freedesktop.org/drm/intel/issues/272
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 .../drm/i915/display/intel_display_types.h    |  1 +
 drivers/gpu/drm/i915/display/intel_dp.c       | 74 ++++++++++++++++---
 2 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e00e611f077..ffde0d4af23c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1258,6 +1258,7 @@ struct intel_dp {
 	bool link_trained;
 	bool has_audio;
 	bool reset_link_params;
+	bool use_max_params;
 	u8 dpcd[DP_RECEIVER_CAP_SIZE];
 	u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
 	u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index ef2e06e292d5..85abcce492ca 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
 {
 	int index;
 
+	if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
+		DRM_DEBUG_KMS("Retrying Link training for eDP with max parameters\n");
+		intel_dp->use_max_params = true;
+		return 0;
+	}
+
 	index = intel_dp_rate_index(intel_dp->common_rates,
 				    intel_dp->num_common_rates,
 				    link_rate);
@@ -2046,6 +2052,44 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
 	return -EINVAL;
 }
 
+/* Optimize link config in order: max bpp, min lanes, min clock */
+static int
+intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
+				  struct intel_crtc_state *pipe_config,
+				  const struct link_config_limits *limits)
+{
+	const struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
+	int bpp, clock, lane_count;
+	int mode_rate, link_clock, link_avail;
+
+	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+		int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
+
+		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+						   output_bpp);
+
+		for (lane_count = limits->min_lane_count;
+		     lane_count <= limits->max_lane_count;
+		     lane_count <<= 1) {
+			for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
+				link_clock = intel_dp->common_rates[clock];
+				link_avail = intel_dp_max_data_rate(link_clock,
+								    lane_count);
+
+				if (mode_rate <= link_avail) {
+					pipe_config->lane_count = lane_count;
+					pipe_config->pipe_bpp = bpp;
+					pipe_config->port_clock = link_clock;
+
+					return 0;
+				}
+			}
+		}
+	}
+
+	return -EINVAL;
+}
+
 static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc)
 {
 	int i, num_bpc;
@@ -2261,13 +2305,14 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
 	limits.min_bpp = intel_dp_min_bpp(pipe_config);
 	limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
 
-	if (intel_dp_is_edp(intel_dp)) {
+	if (intel_dp->use_max_params) {
 		/*
 		 * Use the maximum clock and number of lanes the eDP panel
-		 * advertizes being capable of. The panels are generally
+		 * advertizes being capable of in case the initial fast
+		 * optimal params failed us. The panels are generally
 		 * designed to support only a single clock and lane
-		 * configuration, and typically these values correspond to the
-		 * native resolution of the panel.
+		 * configuration, and typically on older panels these
+		 * values correspond to the native resolution of the panel.
 		 */
 		limits.min_lane_count = limits.max_lane_count;
 		limits.min_clock = limits.max_clock;
@@ -2281,11 +2326,22 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
 		      intel_dp->common_rates[limits.max_clock],
 		      limits.max_bpp, adjusted_mode->crtc_clock);
 
-	/*
-	 * Optimize for slow and wide. This is the place to add alternative
-	 * optimization policy.
-	 */
-	ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits);
+	if (intel_dp_is_edp(intel_dp))
+		/*
+		 * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
+		 * section A.1: "It is recommended that the minimum number of
+		 * lanes be used, using the minimum link rate allowed for that
+		 * lane configuration."
+		 *
+		 * Note that we fall back to the max clock and lane count for eDP
+		 * panels that fail with the fast optimal settings (see
+		 * intel_dp->use_max_params), in which case the fast vs. wide
+		 * choice doesn't matter.
+		 */
+		ret = intel_dp_compute_link_config_fast(intel_dp, pipe_config, &limits);
+	else
+		/* Optimize for slow and wide. */
+		ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits);
 
 	/* enable compression if the mode doesn't fit available BW */
 	DRM_DEBUG_KMS("Force DSC en = %d\n", intel_dp->force_dsc_en);
-- 
2.24.1

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

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

* [Intel-gfx] [PATCH 2/3] drm: Refactor intel_dp_compute_link_config_*()
  2020-03-19 16:38 [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Ville Syrjala
@ 2020-03-19 16:38 ` Ville Syrjala
  2020-03-19 16:38 ` [Intel-gfx] [PATCH 3/3] drm: Constify adjusted_mode a bit Ville Syrjala
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: Ville Syrjala @ 2020-03-19 16:38 UTC (permalink / raw)
  To: intel-gfx

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

Pull the common parts of intel_dp_compute_link_config_wide()
and intel_dp_compute_link_config_fast() into a shared helper
to avoid duplicated code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_dp.c | 76 ++++++++++++++-----------
 1 file changed, 44 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 85abcce492ca..8491ce8b8c15 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2014,34 +2014,47 @@ static int intel_dp_output_bpp(const struct intel_crtc_state *crtc_state, int bp
 	return bpp;
 }
 
+static bool
+intel_dp_link_config_valid(const struct intel_crtc_state *crtc_state,
+			   int bpp, int link_clock, int lane_count)
+{
+	const struct drm_display_mode *adjusted_mode =
+		&crtc_state->hw.adjusted_mode;
+	int output_bpp = intel_dp_output_bpp(crtc_state, bpp);
+	int mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+					       output_bpp);
+	int link_avail = intel_dp_max_data_rate(link_clock, lane_count);
+
+	return mode_rate <= link_avail;
+}
+
 /* Optimize link config in order: max bpp, min clock, min lanes */
 static int
 intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
-				  struct intel_crtc_state *pipe_config,
+				  struct intel_crtc_state *crtc_state,
 				  const struct link_config_limits *limits)
 {
-	struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
-	int bpp, clock, lane_count;
-	int mode_rate, link_clock, link_avail;
+	int bpp;
 
 	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
-		int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
+		int clock;
 
-		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
-						   output_bpp);
+		for (clock = limits->min_clock;
+		     clock <= limits->max_clock;
+		     clock++) {
+			int lane_count;
 
-		for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
 			for (lane_count = limits->min_lane_count;
 			     lane_count <= limits->max_lane_count;
 			     lane_count <<= 1) {
-				link_clock = intel_dp->common_rates[clock];
-				link_avail = intel_dp_max_data_rate(link_clock,
-								    lane_count);
+				int link_clock = intel_dp->common_rates[clock];
 
-				if (mode_rate <= link_avail) {
-					pipe_config->lane_count = lane_count;
-					pipe_config->pipe_bpp = bpp;
-					pipe_config->port_clock = link_clock;
+				if (intel_dp_link_config_valid(crtc_state, bpp,
+							       link_clock,
+							       lane_count)) {
+					crtc_state->pipe_bpp = bpp;
+					crtc_state->port_clock = link_clock;
+					crtc_state->lane_count = lane_count;
 
 					return 0;
 				}
@@ -2055,31 +2068,30 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
 /* Optimize link config in order: max bpp, min lanes, min clock */
 static int
 intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
-				  struct intel_crtc_state *pipe_config,
+				  struct intel_crtc_state *crtc_state,
 				  const struct link_config_limits *limits)
 {
-	const struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
-	int bpp, clock, lane_count;
-	int mode_rate, link_clock, link_avail;
+	int bpp;
 
 	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
-		int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
-
-		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
-						   output_bpp);
+		int lane_count;
 
 		for (lane_count = limits->min_lane_count;
 		     lane_count <= limits->max_lane_count;
 		     lane_count <<= 1) {
-			for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
-				link_clock = intel_dp->common_rates[clock];
-				link_avail = intel_dp_max_data_rate(link_clock,
-								    lane_count);
-
-				if (mode_rate <= link_avail) {
-					pipe_config->lane_count = lane_count;
-					pipe_config->pipe_bpp = bpp;
-					pipe_config->port_clock = link_clock;
+			int clock;
+
+			for (clock = limits->min_clock;
+			     clock <= limits->max_clock;
+			     clock++) {
+				int link_clock = intel_dp->common_rates[clock];
+
+				if (intel_dp_link_config_valid(crtc_state, bpp,
+							       link_clock,
+							       lane_count)) {
+					crtc_state->pipe_bpp = bpp;
+					crtc_state->port_clock = link_clock;
+					crtc_state->lane_count = lane_count;
 
 					return 0;
 				}
-- 
2.24.1

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

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

* [Intel-gfx] [PATCH 3/3] drm: Constify adjusted_mode a bit
  2020-03-19 16:38 [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Ville Syrjala
  2020-03-19 16:38 ` [Intel-gfx] [PATCH 2/3] drm: Refactor intel_dp_compute_link_config_*() Ville Syrjala
@ 2020-03-19 16:38 ` Ville Syrjala
  2020-03-20 18:33   ` Manasi Navare
  2020-03-19 16:53 ` [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Hans de Goede
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 14+ messages in thread
From: Ville Syrjala @ 2020-03-19 16:38 UTC (permalink / raw)
  To: intel-gfx

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

The DP link computation functions shouldn't modify the
adjusted_mode so make it const.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_dp.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 8491ce8b8c15..110d82ee4859 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2181,7 +2181,8 @@ static int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
 {
 	struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
 	struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
-	struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
+	const struct drm_display_mode *adjusted_mode =
+		&pipe_config->hw.adjusted_mode;
 	u8 dsc_max_bpc;
 	int pipe_bpp;
 	int ret;
@@ -2296,7 +2297,8 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
 			     struct intel_crtc_state *pipe_config,
 			     struct drm_connector_state *conn_state)
 {
-	struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
+	const struct drm_display_mode *adjusted_mode =
+		&pipe_config->hw.adjusted_mode;
 	struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 	struct link_config_limits limits;
 	int common_len;
-- 
2.24.1

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

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

* Re: [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
  2020-03-19 16:38 [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Ville Syrjala
  2020-03-19 16:38 ` [Intel-gfx] [PATCH 2/3] drm: Refactor intel_dp_compute_link_config_*() Ville Syrjala
  2020-03-19 16:38 ` [Intel-gfx] [PATCH 3/3] drm: Constify adjusted_mode a bit Ville Syrjala
@ 2020-03-19 16:53 ` Hans de Goede
  2020-03-19 17:06   ` Ville Syrjälä
  2020-03-19 17:46 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] " Patchwork
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 14+ messages in thread
From: Hans de Goede @ 2020-03-19 16:53 UTC (permalink / raw)
  To: Ville Syrjala, intel-gfx
  Cc: Jani Nikula, Albert Astals Cid, Matteo Iervasi, Emanuele Panigati

Hi,

On 3/19/20 5:38 PM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Some new eDP panels don't like to operate at the max parameters, and
> instead we need to go for an optimal confiugration. That unfortunately
> doesn't work with older eDP panels which are generally only guaranteed
> to work at the max parameters.
> 
> To solve these two conflicting requirements let's start with the optimal
> setup, and if that fails we start again with the max parameters. The
> downside is probably an extra modeset when we switch strategies but
> I don't see a good way to avoid that.
> 
> For a bit of history we first tried to go for the fast+narrow in
> commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> fast and narrow"). but that had to be reverted due to regression
> on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> to max link rate and lane count on eDP"). So now we try to get
> the best of both worlds by using both strategies.
> 
> v2: Deal with output_bpp and uapi vs. hw state split
>      Reword some comments

I'm wondering if, at least for the fastset case, but also
for later modesets I guess, it would not be better to
first check if the link is already setup (panel already on)
and then check if the existing parameters match our min/max
criteria and if they do continue with those settings?

Doing something like this would likely also fix:
https://gitlab.freedesktop.org/drm/intel/issues/1476

Regards,

Hans



> 
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
> Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
> Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
> Cc: Timo Aaltonen <tjaalton@ubuntu.com>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> References: https://gitlab.freedesktop.org/drm/intel/issues/272
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>   .../drm/i915/display/intel_display_types.h    |  1 +
>   drivers/gpu/drm/i915/display/intel_dp.c       | 74 ++++++++++++++++---
>   2 files changed, 66 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 5e00e611f077..ffde0d4af23c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1258,6 +1258,7 @@ struct intel_dp {
>   	bool link_trained;
>   	bool has_audio;
>   	bool reset_link_params;
> +	bool use_max_params;
>   	u8 dpcd[DP_RECEIVER_CAP_SIZE];
>   	u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
>   	u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index ef2e06e292d5..85abcce492ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
>   {
>   	int index;
>   
> +	if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> +		DRM_DEBUG_KMS("Retrying Link training for eDP with max parameters\n");
> +		intel_dp->use_max_params = true;
> +		return 0;
> +	}
> +
>   	index = intel_dp_rate_index(intel_dp->common_rates,
>   				    intel_dp->num_common_rates,
>   				    link_rate);
> @@ -2046,6 +2052,44 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
>   	return -EINVAL;
>   }
>   
> +/* Optimize link config in order: max bpp, min lanes, min clock */
> +static int
> +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> +				  struct intel_crtc_state *pipe_config,
> +				  const struct link_config_limits *limits)
> +{
> +	const struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
> +	int bpp, clock, lane_count;
> +	int mode_rate, link_clock, link_avail;
> +
> +	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> +		int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
> +
> +		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> +						   output_bpp);
> +
> +		for (lane_count = limits->min_lane_count;
> +		     lane_count <= limits->max_lane_count;
> +		     lane_count <<= 1) {
> +			for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
> +				link_clock = intel_dp->common_rates[clock];
> +				link_avail = intel_dp_max_data_rate(link_clock,
> +								    lane_count);
> +
> +				if (mode_rate <= link_avail) {
> +					pipe_config->lane_count = lane_count;
> +					pipe_config->pipe_bpp = bpp;
> +					pipe_config->port_clock = link_clock;
> +
> +					return 0;
> +				}
> +			}
> +		}
> +	}
> +
> +	return -EINVAL;
> +}
> +
>   static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc)
>   {
>   	int i, num_bpc;
> @@ -2261,13 +2305,14 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>   	limits.min_bpp = intel_dp_min_bpp(pipe_config);
>   	limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>   
> -	if (intel_dp_is_edp(intel_dp)) {
> +	if (intel_dp->use_max_params) {
>   		/*
>   		 * Use the maximum clock and number of lanes the eDP panel
> -		 * advertizes being capable of. The panels are generally
> +		 * advertizes being capable of in case the initial fast
> +		 * optimal params failed us. The panels are generally
>   		 * designed to support only a single clock and lane
> -		 * configuration, and typically these values correspond to the
> -		 * native resolution of the panel.
> +		 * configuration, and typically on older panels these
> +		 * values correspond to the native resolution of the panel.
>   		 */
>   		limits.min_lane_count = limits.max_lane_count;
>   		limits.min_clock = limits.max_clock;
> @@ -2281,11 +2326,22 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>   		      intel_dp->common_rates[limits.max_clock],
>   		      limits.max_bpp, adjusted_mode->crtc_clock);
>   
> -	/*
> -	 * Optimize for slow and wide. This is the place to add alternative
> -	 * optimization policy.
> -	 */
> -	ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits);
> +	if (intel_dp_is_edp(intel_dp))
> +		/*
> +		 * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
> +		 * section A.1: "It is recommended that the minimum number of
> +		 * lanes be used, using the minimum link rate allowed for that
> +		 * lane configuration."
> +		 *
> +		 * Note that we fall back to the max clock and lane count for eDP
> +		 * panels that fail with the fast optimal settings (see
> +		 * intel_dp->use_max_params), in which case the fast vs. wide
> +		 * choice doesn't matter.
> +		 */
> +		ret = intel_dp_compute_link_config_fast(intel_dp, pipe_config, &limits);
> +	else
> +		/* Optimize for slow and wide. */
> +		ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits);
>   
>   	/* enable compression if the mode doesn't fit available BW */
>   	DRM_DEBUG_KMS("Force DSC en = %d\n", intel_dp->force_dsc_en);
> 

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

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

* Re: [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
  2020-03-19 16:53 ` [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Hans de Goede
@ 2020-03-19 17:06   ` Ville Syrjälä
  0 siblings, 0 replies; 14+ messages in thread
From: Ville Syrjälä @ 2020-03-19 17:06 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Jani Nikula, Albert Astals Cid, intel-gfx, Matteo Iervasi,
	Emanuele Panigati

On Thu, Mar 19, 2020 at 05:53:08PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 3/19/20 5:38 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Some new eDP panels don't like to operate at the max parameters, and
> > instead we need to go for an optimal confiugration. That unfortunately
> > doesn't work with older eDP panels which are generally only guaranteed
> > to work at the max parameters.
> > 
> > To solve these two conflicting requirements let's start with the optimal
> > setup, and if that fails we start again with the max parameters. The
> > downside is probably an extra modeset when we switch strategies but
> > I don't see a good way to avoid that.
> > 
> > For a bit of history we first tried to go for the fast+narrow in
> > commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> > fast and narrow"). but that had to be reverted due to regression
> > on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> > to max link rate and lane count on eDP"). So now we try to get
> > the best of both worlds by using both strategies.
> > 
> > v2: Deal with output_bpp and uapi vs. hw state split
> >      Reword some comments
> 
> I'm wondering if, at least for the fastset case, but also
> for later modesets I guess, it would not be better to
> first check if the link is already setup (panel already on)
> and then check if the existing parameters match our min/max
> criteria and if they do continue with those settings?
> 
> Doing something like this would likely also fix:
> https://gitlab.freedesktop.org/drm/intel/issues/1476

Yeah, I've thought about doing that. It's a bit ugly though, and
probably requires some actual thought so that we don't end up
doing something stupid.

-- 
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] 14+ messages in thread

* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
  2020-03-19 16:38 [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Ville Syrjala
                   ` (2 preceding siblings ...)
  2020-03-19 16:53 ` [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Hans de Goede
@ 2020-03-19 17:46 ` Patchwork
  2020-03-19 19:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2020-03-19 17:46 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
URL   : https://patchwork.freedesktop.org/series/74879/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17025
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/index.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@i915_selftest@live@execlists:
    - fi-skl-lmem:        [PASS][1] -> [INCOMPLETE][2] ([i915#656])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-skl-lmem/igt@i915_selftest@live@execlists.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/fi-skl-lmem/igt@i915_selftest@live@execlists.html

  * igt@i915_selftest@live@gem_contexts:
    - fi-cml-s:           [PASS][3] -> [DMESG-FAIL][4] ([i915#877])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/fi-cml-s/igt@i915_selftest@live@gem_contexts.html

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

  
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877


Participating hosts (37 -> 40)
------------------------------

  Additional (6): fi-bsw-n3050 fi-byt-j1900 fi-cfl-8109u fi-skl-6600u fi-bsw-nick fi-skl-6700k2 
  Missing    (3): fi-byt-clapper fi-byt-squawks fi-bsw-cyan 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8160 -> Patchwork_17025

  CI-20190529: 20190529
  CI_DRM_8160: 6ba1729e5025761ab74914f6b8aa3288f493e9c7 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17025: 16f1ad9b88c54b0140a587b8953aaeadb5136843 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

16f1ad9b88c5 drm: Constify adjusted_mode a bit
09d9ab0a2195 drm: Refactor intel_dp_compute_link_config_*()
99d00f5603c3 drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure

== Logs ==

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

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

* [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
  2020-03-19 16:38 [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Ville Syrjala
                   ` (3 preceding siblings ...)
  2020-03-19 17:46 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] " Patchwork
@ 2020-03-19 19:52 ` Patchwork
  2020-03-19 22:20 ` [Intel-gfx] [PATCH 1/3] " Manasi Navare
  2020-07-02  9:21 ` Timo Aaltonen
  6 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2020-03-19 19:52 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
URL   : https://patchwork.freedesktop.org/series/74879/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8160_full -> Patchwork_17025_full
====================================================

Summary
-------

  **FAILURE**

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

  

Possible new issues
-------------------

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

### IGT changes ###

#### Possible regressions ####

  * igt@kms_hdr@static-toggle-dpms:
    - shard-tglb:         NOTRUN -> [SKIP][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-tglb5/igt@kms_hdr@static-toggle-dpms.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_persistence@close-replace-race:
    - shard-tglb:         [PASS][2] -> [INCOMPLETE][3] ([i915#1402])
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb5/igt@gem_ctx_persistence@close-replace-race.html
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-tglb7/igt@gem_ctx_persistence@close-replace-race.html
    - shard-kbl:          [PASS][4] -> [INCOMPLETE][5] ([i915#1402])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl7/igt@gem_ctx_persistence@close-replace-race.html
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-kbl6/igt@gem_ctx_persistence@close-replace-race.html

  * igt@gem_exec_parallel@vcs1-fds:
    - shard-iclb:         [PASS][6] -> [SKIP][7] ([fdo#112080]) +13 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_parallel@vcs1-fds.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb8/igt@gem_exec_parallel@vcs1-fds.html

  * igt@gem_exec_schedule@implicit-both-bsd:
    - shard-iclb:         [PASS][8] -> [SKIP][9] ([i915#677]) +1 similar issue
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb6/igt@gem_exec_schedule@implicit-both-bsd.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb2/igt@gem_exec_schedule@implicit-both-bsd.html

  * igt@gem_exec_schedule@out-order-bsd2:
    - shard-iclb:         [PASS][10] -> [SKIP][11] ([fdo#109276]) +9 similar issues
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_schedule@out-order-bsd2.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb8/igt@gem_exec_schedule@out-order-bsd2.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
    - shard-iclb:         [PASS][12] -> [SKIP][13] ([fdo#112146]) +4 similar issues
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb7/igt@gem_exec_schedule@preempt-other-chain-bsd.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb4/igt@gem_exec_schedule@preempt-other-chain-bsd.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
    - shard-kbl:          [PASS][14] -> [FAIL][15] ([i915#644])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl1/igt@gem_ppgtt@flink-and-close-vma-leak.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-kbl7/igt@gem_ppgtt@flink-and-close-vma-leak.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-apl:          [PASS][16] -> [DMESG-WARN][17] ([i915#180])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-apl8/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-apl1/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding:
    - shard-hsw:          [PASS][18] -> [INCOMPLETE][19] ([i915#61])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-hsw4/igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-hsw2/igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-kbl:          [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +4 similar issues
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl2/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-kbl4/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-render:
    - shard-skl:          [PASS][22] -> [FAIL][23] ([i915#49])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-skl1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-render.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-skl8/igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
    - shard-skl:          [PASS][24] -> [FAIL][25] ([fdo#108145]) +1 similar issue
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [PASS][26] -> [FAIL][27] ([fdo#108145] / [i915#265])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_plane_move:
    - shard-iclb:         [PASS][28] -> [SKIP][29] ([fdo#109441]) +1 similar issue
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb7/igt@kms_psr@psr2_cursor_plane_move.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@vcs1-nonpriv:
    - shard-iclb:         [SKIP][30] ([fdo#112080]) -> [PASS][31] +4 similar issues
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb6/igt@gem_ctx_isolation@vcs1-nonpriv.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv.html

  * igt@gem_ctx_persistence@engines-mixed-process@bcs0:
    - shard-iclb:         [FAIL][32] ([i915#679]) -> [PASS][33]
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb4/igt@gem_ctx_persistence@engines-mixed-process@bcs0.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb1/igt@gem_ctx_persistence@engines-mixed-process@bcs0.html

  * igt@gem_ctx_persistence@engines-mixed-process@vcs0:
    - shard-iclb:         [INCOMPLETE][34] ([i915#1239]) -> [PASS][35]
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb4/igt@gem_ctx_persistence@engines-mixed-process@vcs0.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb1/igt@gem_ctx_persistence@engines-mixed-process@vcs0.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt:
    - shard-tglb:         [FAIL][36] ([i915#679]) -> [PASS][37]
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb2/igt@gem_ctx_persistence@legacy-engines-mixed-process@blt.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-tglb8/igt@gem_ctx_persistence@legacy-engines-mixed-process@blt.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox:
    - shard-tglb:         [INCOMPLETE][38] ([i915#1239]) -> [PASS][39]
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb2/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-tglb8/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html

  * igt@gem_exec_schedule@implicit-write-read-bsd:
    - shard-iclb:         [SKIP][40] ([i915#677]) -> [PASS][41]
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb2/igt@gem_exec_schedule@implicit-write-read-bsd.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb6/igt@gem_exec_schedule@implicit-write-read-bsd.html

  * igt@gem_exec_schedule@independent-bsd2:
    - shard-iclb:         [SKIP][42] ([fdo#109276]) -> [PASS][43] +22 similar issues
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb7/igt@gem_exec_schedule@independent-bsd2.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb4/igt@gem_exec_schedule@independent-bsd2.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
    - shard-iclb:         [SKIP][44] ([fdo#112146]) -> [PASS][45] +2 similar issues
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb2/igt@gem_exec_schedule@preemptive-hang-bsd.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb7/igt@gem_exec_schedule@preemptive-hang-bsd.html

  * igt@gem_exec_suspend@basic-s3:
    - shard-kbl:          [DMESG-WARN][46] ([i915#180]) -> [PASS][47] +4 similar issues
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl4/igt@gem_exec_suspend@basic-s3.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-kbl7/igt@gem_exec_suspend@basic-s3.html

  * igt@gem_exec_whisper@basic-fds-forked:
    - shard-tglb:         [INCOMPLETE][48] ([i915#1318] / [i915#1401]) -> [PASS][49]
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb1/igt@gem_exec_whisper@basic-fds-forked.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-tglb5/igt@gem_exec_whisper@basic-fds-forked.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
    - shard-glk:          [FAIL][50] ([i915#644]) -> [PASS][51]
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-glk8/igt@gem_ppgtt@flink-and-close-vma-leak.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-glk3/igt@gem_ppgtt@flink-and-close-vma-leak.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
    - shard-skl:          [FAIL][52] ([i915#46]) -> [PASS][53]
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
    - shard-glk:          [FAIL][54] ([i915#34]) -> [PASS][55] +1 similar issue
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-glk4/igt@kms_flip@plain-flip-fb-recreate-interruptible.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-glk7/igt@kms_flip@plain-flip-fb-recreate-interruptible.html

  * igt@kms_hdr@bpc-switch-suspend:
    - shard-skl:          [FAIL][56] ([i915#1188]) -> [PASS][57]
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-skl7/igt@kms_hdr@bpc-switch-suspend.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-skl6/igt@kms_hdr@bpc-switch-suspend.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
    - shard-apl:          [DMESG-WARN][58] ([i915#180]) -> [PASS][59] +1 similar issue
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-skl:          [FAIL][60] ([fdo#108145] / [i915#265]) -> [PASS][61]
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-skl2/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-skl4/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-glk:          [FAIL][62] ([i915#899]) -> [PASS][63]
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-glk3/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-glk8/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr2_su@page_flip:
    - shard-iclb:         [SKIP][64] ([fdo#109642] / [fdo#111068]) -> [PASS][65]
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb8/igt@kms_psr2_su@page_flip.html
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb2/igt@kms_psr2_su@page_flip.html

  * igt@kms_psr@psr2_cursor_plane_onoff:
    - shard-iclb:         [SKIP][66] ([fdo#109441]) -> [PASS][67] +1 similar issue
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb6/igt@kms_psr@psr2_cursor_plane_onoff.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html

  * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
    - shard-skl:          [INCOMPLETE][68] ([i915#69]) -> [PASS][69]
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-skl9/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-skl9/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html

  
#### Warnings ####

  * igt@i915_pm_dc@dc6-dpms:
    - shard-tglb:         [FAIL][70] ([i915#454]) -> [SKIP][71] ([i915#468])
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb3/igt@i915_pm_dc@dc6-dpms.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-tglb2/igt@i915_pm_dc@dc6-dpms.html

  * igt@runner@aborted:
    - shard-kbl:          [FAIL][72] ([i915#92]) -> ([FAIL][73], [FAIL][74]) ([i915#1389] / [i915#1402] / [i915#92])
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl6/igt@runner@aborted.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-kbl1/igt@runner@aborted.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-kbl6/igt@runner@aborted.html
    - shard-tglb:         [FAIL][75] ([i915#1318]) -> [FAIL][76] ([i915#1389])
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb1/igt@runner@aborted.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-tglb7/igt@runner@aborted.html

  
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [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#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
  [fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
  [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
  [i915#1239]: https://gitlab.freedesktop.org/drm/intel/issues/1239
  [i915#1318]: https://gitlab.freedesktop.org/drm/intel/issues/1318
  [i915#1389]: https://gitlab.freedesktop.org/drm/intel/issues/1389
  [i915#1401]: https://gitlab.freedesktop.org/drm/intel/issues/1401
  [i915#1402]: https://gitlab.freedesktop.org/drm/intel/issues/1402
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#46]: https://gitlab.freedesktop.org/drm/intel/issues/46
  [i915#468]: https://gitlab.freedesktop.org/drm/intel/issues/468
  [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
  [i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
  [i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
  [i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
  [i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
  [i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
  [i915#899]: https://gitlab.freedesktop.org/drm/intel/issues/899
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8160 -> Patchwork_17025

  CI-20190529: 20190529
  CI_DRM_8160: 6ba1729e5025761ab74914f6b8aa3288f493e9c7 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17025: 16f1ad9b88c54b0140a587b8953aaeadb5136843 @ 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_17025/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
  2020-03-19 16:38 [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Ville Syrjala
                   ` (4 preceding siblings ...)
  2020-03-19 19:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
@ 2020-03-19 22:20 ` Manasi Navare
  2020-03-20 19:08   ` Ville Syrjälä
  2020-07-02  9:21 ` Timo Aaltonen
  6 siblings, 1 reply; 14+ messages in thread
From: Manasi Navare @ 2020-03-19 22:20 UTC (permalink / raw)
  To: Ville Syrjala
  Cc: Matteo Iervasi, Jani Nikula, Albert Astals Cid, intel-gfx,
	Emanuele Panigati

On Thu, Mar 19, 2020 at 06:38:42PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Some new eDP panels don't like to operate at the max parameters, and
> instead we need to go for an optimal confiugration. That unfortunately
> doesn't work with older eDP panels which are generally only guaranteed
> to work at the max parameters.
> 
> To solve these two conflicting requirements let's start with the optimal
> setup, and if that fails we start again with the max parameters. The
> downside is probably an extra modeset when we switch strategies but
> I don't see a good way to avoid that.
> 
> For a bit of history we first tried to go for the fast+narrow in
> commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> fast and narrow"). but that had to be reverted due to regression
> on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> to max link rate and lane count on eDP"). So now we try to get
> the best of both worlds by using both strategies.
> 
> v2: Deal with output_bpp and uapi vs. hw state split
>     Reword some comments
> 
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
> Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
> Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
> Cc: Timo Aaltonen <tjaalton@ubuntu.com>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> References: https://gitlab.freedesktop.org/drm/intel/issues/272
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

This approach looks good to me to fallback to max parameters if
it fails the first time.

> ---
>  .../drm/i915/display/intel_display_types.h    |  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c       | 74 ++++++++++++++++---
>  2 files changed, 66 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 5e00e611f077..ffde0d4af23c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1258,6 +1258,7 @@ struct intel_dp {
>  	bool link_trained;
>  	bool has_audio;
>  	bool reset_link_params;
> +	bool use_max_params;
>  	u8 dpcd[DP_RECEIVER_CAP_SIZE];
>  	u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
>  	u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index ef2e06e292d5..85abcce492ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
>  {
>  	int index;
>  
> +	if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> +		DRM_DEBUG_KMS("Retrying Link training for eDP with max parameters\n");
> +		intel_dp->use_max_params = true;
> +		return 0;
> +	}

We need to remove the current check for intel_dp_can_link_train_fallback_for_edp() right?

Manasi

> +
>  	index = intel_dp_rate_index(intel_dp->common_rates,
>  				    intel_dp->num_common_rates,
>  				    link_rate);
> @@ -2046,6 +2052,44 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
>  	return -EINVAL;
>  }
>  
> +/* Optimize link config in order: max bpp, min lanes, min clock */
> +static int
> +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> +				  struct intel_crtc_state *pipe_config,
> +				  const struct link_config_limits *limits)
> +{
> +	const struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
> +	int bpp, clock, lane_count;
> +	int mode_rate, link_clock, link_avail;
> +
> +	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> +		int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
> +
> +		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> +						   output_bpp);
> +
> +		for (lane_count = limits->min_lane_count;
> +		     lane_count <= limits->max_lane_count;
> +		     lane_count <<= 1) {
> +			for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
> +				link_clock = intel_dp->common_rates[clock];
> +				link_avail = intel_dp_max_data_rate(link_clock,
> +								    lane_count);
> +
> +				if (mode_rate <= link_avail) {
> +					pipe_config->lane_count = lane_count;
> +					pipe_config->pipe_bpp = bpp;
> +					pipe_config->port_clock = link_clock;
> +
> +					return 0;
> +				}
> +			}
> +		}
> +	}
> +
> +	return -EINVAL;
> +}
> +
>  static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc)
>  {
>  	int i, num_bpc;
> @@ -2261,13 +2305,14 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>  	limits.min_bpp = intel_dp_min_bpp(pipe_config);
>  	limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>  
> -	if (intel_dp_is_edp(intel_dp)) {
> +	if (intel_dp->use_max_params) {
>  		/*
>  		 * Use the maximum clock and number of lanes the eDP panel
> -		 * advertizes being capable of. The panels are generally
> +		 * advertizes being capable of in case the initial fast
> +		 * optimal params failed us. The panels are generally
>  		 * designed to support only a single clock and lane
> -		 * configuration, and typically these values correspond to the
> -		 * native resolution of the panel.
> +		 * configuration, and typically on older panels these
> +		 * values correspond to the native resolution of the panel.
>  		 */
>  		limits.min_lane_count = limits.max_lane_count;
>  		limits.min_clock = limits.max_clock;
> @@ -2281,11 +2326,22 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>  		      intel_dp->common_rates[limits.max_clock],
>  		      limits.max_bpp, adjusted_mode->crtc_clock);
>  
> -	/*
> -	 * Optimize for slow and wide. This is the place to add alternative
> -	 * optimization policy.
> -	 */
> -	ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits);
> +	if (intel_dp_is_edp(intel_dp))
> +		/*
> +		 * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
> +		 * section A.1: "It is recommended that the minimum number of
> +		 * lanes be used, using the minimum link rate allowed for that
> +		 * lane configuration."
> +		 *
> +		 * Note that we fall back to the max clock and lane count for eDP
> +		 * panels that fail with the fast optimal settings (see
> +		 * intel_dp->use_max_params), in which case the fast vs. wide
> +		 * choice doesn't matter.
> +		 */
> +		ret = intel_dp_compute_link_config_fast(intel_dp, pipe_config, &limits);
> +	else
> +		/* Optimize for slow and wide. */
> +		ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits);
>  
>  	/* enable compression if the mode doesn't fit available BW */
>  	DRM_DEBUG_KMS("Force DSC en = %d\n", intel_dp->force_dsc_en);
> -- 
> 2.24.1
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [Intel-gfx] [PATCH 3/3] drm: Constify adjusted_mode a bit
  2020-03-19 16:38 ` [Intel-gfx] [PATCH 3/3] drm: Constify adjusted_mode a bit Ville Syrjala
@ 2020-03-20 18:33   ` Manasi Navare
  0 siblings, 0 replies; 14+ messages in thread
From: Manasi Navare @ 2020-03-20 18:33 UTC (permalink / raw)
  To: Ville Syrjala; +Cc: intel-gfx

On Thu, Mar 19, 2020 at 06:38:44PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The DP link computation functions shouldn't modify the
> adjusted_mode so make it const.
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 8491ce8b8c15..110d82ee4859 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2181,7 +2181,8 @@ static int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
>  {
>  	struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>  	struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> -	struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
> +	const struct drm_display_mode *adjusted_mode =
> +		&pipe_config->hw.adjusted_mode;
>  	u8 dsc_max_bpc;
>  	int pipe_bpp;
>  	int ret;
> @@ -2296,7 +2297,8 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>  			     struct intel_crtc_state *pipe_config,
>  			     struct drm_connector_state *conn_state)
>  {
> -	struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
> +	const struct drm_display_mode *adjusted_mode =
> +		&pipe_config->hw.adjusted_mode;
>  	struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  	struct link_config_limits limits;
>  	int common_len;
> -- 
> 2.24.1
> 
> _______________________________________________
> 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

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

* Re: [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
  2020-03-19 22:20 ` [Intel-gfx] [PATCH 1/3] " Manasi Navare
@ 2020-03-20 19:08   ` Ville Syrjälä
  2020-03-20 23:17     ` Manasi Navare
  0 siblings, 1 reply; 14+ messages in thread
From: Ville Syrjälä @ 2020-03-20 19:08 UTC (permalink / raw)
  To: Manasi Navare
  Cc: Matteo Iervasi, Jani Nikula, Albert Astals Cid, intel-gfx,
	Emanuele Panigati

On Thu, Mar 19, 2020 at 03:20:50PM -0700, Manasi Navare wrote:
> On Thu, Mar 19, 2020 at 06:38:42PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Some new eDP panels don't like to operate at the max parameters, and
> > instead we need to go for an optimal confiugration. That unfortunately
> > doesn't work with older eDP panels which are generally only guaranteed
> > to work at the max parameters.
> > 
> > To solve these two conflicting requirements let's start with the optimal
> > setup, and if that fails we start again with the max parameters. The
> > downside is probably an extra modeset when we switch strategies but
> > I don't see a good way to avoid that.
> > 
> > For a bit of history we first tried to go for the fast+narrow in
> > commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> > fast and narrow"). but that had to be reverted due to regression
> > on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> > to max link rate and lane count on eDP"). So now we try to get
> > the best of both worlds by using both strategies.
> > 
> > v2: Deal with output_bpp and uapi vs. hw state split
> >     Reword some comments
> > 
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
> > Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
> > Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
> > Cc: Timo Aaltonen <tjaalton@ubuntu.com>
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> > References: https://gitlab.freedesktop.org/drm/intel/issues/272
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> This approach looks good to me to fallback to max parameters if
> it fails the first time.
> 
> > ---
> >  .../drm/i915/display/intel_display_types.h    |  1 +
> >  drivers/gpu/drm/i915/display/intel_dp.c       | 74 ++++++++++++++++---
> >  2 files changed, 66 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 5e00e611f077..ffde0d4af23c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1258,6 +1258,7 @@ struct intel_dp {
> >  	bool link_trained;
> >  	bool has_audio;
> >  	bool reset_link_params;
> > +	bool use_max_params;
> >  	u8 dpcd[DP_RECEIVER_CAP_SIZE];
> >  	u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
> >  	u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> > index ef2e06e292d5..85abcce492ca 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> >  {
> >  	int index;
> >  
> > +	if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> > +		DRM_DEBUG_KMS("Retrying Link training for eDP with max parameters\n");
> > +		intel_dp->use_max_params = true;
> > +		return 0;
> > +	}
> 
> We need to remove the current check for intel_dp_can_link_train_fallback_for_edp() right?

No. Why do you think it needs to be removed?

-- 
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] 14+ messages in thread

* Re: [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
  2020-03-20 19:08   ` Ville Syrjälä
@ 2020-03-20 23:17     ` Manasi Navare
  2020-03-27 15:40       ` Ville Syrjälä
  0 siblings, 1 reply; 14+ messages in thread
From: Manasi Navare @ 2020-03-20 23:17 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Matteo Iervasi, Jani Nikula, Albert Astals Cid, intel-gfx,
	Emanuele Panigati

On Fri, Mar 20, 2020 at 09:08:31PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 19, 2020 at 03:20:50PM -0700, Manasi Navare wrote:
> > On Thu, Mar 19, 2020 at 06:38:42PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > Some new eDP panels don't like to operate at the max parameters, and
> > > instead we need to go for an optimal confiugration. That unfortunately
> > > doesn't work with older eDP panels which are generally only guaranteed
> > > to work at the max parameters.
> > > 
> > > To solve these two conflicting requirements let's start with the optimal
> > > setup, and if that fails we start again with the max parameters. The
> > > downside is probably an extra modeset when we switch strategies but
> > > I don't see a good way to avoid that.
> > > 
> > > For a bit of history we first tried to go for the fast+narrow in
> > > commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> > > fast and narrow"). but that had to be reverted due to regression
> > > on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> > > to max link rate and lane count on eDP"). So now we try to get
> > > the best of both worlds by using both strategies.
> > > 
> > > v2: Deal with output_bpp and uapi vs. hw state split
> > >     Reword some comments
> > > 
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > > Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
> > > Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
> > > Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
> > > Cc: Timo Aaltonen <tjaalton@ubuntu.com>
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> > > References: https://gitlab.freedesktop.org/drm/intel/issues/272
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > This approach looks good to me to fallback to max parameters if
> > it fails the first time.
> > 
> > > ---
> > >  .../drm/i915/display/intel_display_types.h    |  1 +
> > >  drivers/gpu/drm/i915/display/intel_dp.c       | 74 ++++++++++++++++---
> > >  2 files changed, 66 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 5e00e611f077..ffde0d4af23c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -1258,6 +1258,7 @@ struct intel_dp {
> > >  	bool link_trained;
> > >  	bool has_audio;
> > >  	bool reset_link_params;
> > > +	bool use_max_params;
> > >  	u8 dpcd[DP_RECEIVER_CAP_SIZE];
> > >  	u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
> > >  	u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index ef2e06e292d5..85abcce492ca 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > >  {
> > >  	int index;
> > >  
> > > +	if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> > > +		DRM_DEBUG_KMS("Retrying Link training for eDP with max parameters\n");
> > > +		intel_dp->use_max_params = true;
> > > +		return 0;
> > > +	}
> > 
> > We need to remove the current check for intel_dp_can_link_train_fallback_for_edp() right?
> 
> No. Why do you think it needs to be removed?
>

Okay so if trying max params link training again fails on eDP, then it fallsback from max to lower values
and fallback link training continues until it can handle the fixed mode with the params or
the lowest params?

So if I understand it correctly we first try to use the optimum approach, if that fails then
we try with max params so in this iteration if it fails again then max params is still true
then it will fallback and call intel_dp_can_link_train_fallback_for_edp() and then
again keep retrying?

Manasi
 
> -- 
> 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] 14+ messages in thread

* Re: [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
  2020-03-20 23:17     ` Manasi Navare
@ 2020-03-27 15:40       ` Ville Syrjälä
  2020-03-27 18:09         ` Manasi Navare
  0 siblings, 1 reply; 14+ messages in thread
From: Ville Syrjälä @ 2020-03-27 15:40 UTC (permalink / raw)
  To: Manasi Navare
  Cc: Matteo Iervasi, Jani Nikula, Albert Astals Cid, intel-gfx,
	Emanuele Panigati

On Fri, Mar 20, 2020 at 04:17:27PM -0700, Manasi Navare wrote:
> On Fri, Mar 20, 2020 at 09:08:31PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 19, 2020 at 03:20:50PM -0700, Manasi Navare wrote:
> > > On Thu, Mar 19, 2020 at 06:38:42PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Some new eDP panels don't like to operate at the max parameters, and
> > > > instead we need to go for an optimal confiugration. That unfortunately
> > > > doesn't work with older eDP panels which are generally only guaranteed
> > > > to work at the max parameters.
> > > > 
> > > > To solve these two conflicting requirements let's start with the optimal
> > > > setup, and if that fails we start again with the max parameters. The
> > > > downside is probably an extra modeset when we switch strategies but
> > > > I don't see a good way to avoid that.
> > > > 
> > > > For a bit of history we first tried to go for the fast+narrow in
> > > > commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> > > > fast and narrow"). but that had to be reverted due to regression
> > > > on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> > > > to max link rate and lane count on eDP"). So now we try to get
> > > > the best of both worlds by using both strategies.
> > > > 
> > > > v2: Deal with output_bpp and uapi vs. hw state split
> > > >     Reword some comments
> > > > 
> > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > > > Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
> > > > Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
> > > > Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
> > > > Cc: Timo Aaltonen <tjaalton@ubuntu.com>
> > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> > > > References: https://gitlab.freedesktop.org/drm/intel/issues/272
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > This approach looks good to me to fallback to max parameters if
> > > it fails the first time.
> > > 
> > > > ---
> > > >  .../drm/i915/display/intel_display_types.h    |  1 +
> > > >  drivers/gpu/drm/i915/display/intel_dp.c       | 74 ++++++++++++++++---
> > > >  2 files changed, 66 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > index 5e00e611f077..ffde0d4af23c 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > @@ -1258,6 +1258,7 @@ struct intel_dp {
> > > >  	bool link_trained;
> > > >  	bool has_audio;
> > > >  	bool reset_link_params;
> > > > +	bool use_max_params;
> > > >  	u8 dpcd[DP_RECEIVER_CAP_SIZE];
> > > >  	u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
> > > >  	u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index ef2e06e292d5..85abcce492ca 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > > >  {
> > > >  	int index;
> > > >  
> > > > +	if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> > > > +		DRM_DEBUG_KMS("Retrying Link training for eDP with max parameters\n");
> > > > +		intel_dp->use_max_params = true;
> > > > +		return 0;
> > > > +	}
> > > 
> > > We need to remove the current check for intel_dp_can_link_train_fallback_for_edp() right?
> > 
> > No. Why do you think it needs to be removed?
> >
> 
> Okay so if trying max params link training again fails on eDP, then it fallsback from max to lower values
> and fallback link training continues until it can handle the fixed mode with the params or
> the lowest params?
> 
> So if I understand it correctly we first try to use the optimum approach, if that fails then
> we try with max params so in this iteration if it fails again then max params is still true
> then it will fallback and call intel_dp_can_link_train_fallback_for_edp() and then
> again keep retrying?

Yep.

-- 
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] 14+ messages in thread

* Re: [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
  2020-03-27 15:40       ` Ville Syrjälä
@ 2020-03-27 18:09         ` Manasi Navare
  0 siblings, 0 replies; 14+ messages in thread
From: Manasi Navare @ 2020-03-27 18:09 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Matteo Iervasi, Jani Nikula, Albert Astals Cid, intel-gfx,
	Emanuele Panigati

On Fri, Mar 27, 2020 at 05:40:41PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 20, 2020 at 04:17:27PM -0700, Manasi Navare wrote:
> > On Fri, Mar 20, 2020 at 09:08:31PM +0200, Ville Syrjälä wrote:
> > > On Thu, Mar 19, 2020 at 03:20:50PM -0700, Manasi Navare wrote:
> > > > On Thu, Mar 19, 2020 at 06:38:42PM +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > 
> > > > > Some new eDP panels don't like to operate at the max parameters, and
> > > > > instead we need to go for an optimal confiugration. That unfortunately
> > > > > doesn't work with older eDP panels which are generally only guaranteed
> > > > > to work at the max parameters.
> > > > > 
> > > > > To solve these two conflicting requirements let's start with the optimal
> > > > > setup, and if that fails we start again with the max parameters. The
> > > > > downside is probably an extra modeset when we switch strategies but
> > > > > I don't see a good way to avoid that.
> > > > > 
> > > > > For a bit of history we first tried to go for the fast+narrow in
> > > > > commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> > > > > fast and narrow"). but that had to be reverted due to regression
> > > > > on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> > > > > to max link rate and lane count on eDP"). So now we try to get
> > > > > the best of both worlds by using both strategies.
> > > > > 
> > > > > v2: Deal with output_bpp and uapi vs. hw state split
> > > > >     Reword some comments
> > > > > 
> > > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > > > > Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
> > > > > Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
> > > > > Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
> > > > > Cc: Timo Aaltonen <tjaalton@ubuntu.com>
> > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> > > > > References: https://gitlab.freedesktop.org/drm/intel/issues/272
> > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Ok then makes sense,

Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

Manasi

> > > > 
> > > > This approach looks good to me to fallback to max parameters if
> > > > it fails the first time.
> > > > 
> > > > > ---
> > > > >  .../drm/i915/display/intel_display_types.h    |  1 +
> > > > >  drivers/gpu/drm/i915/display/intel_dp.c       | 74 ++++++++++++++++---
> > > > >  2 files changed, 66 insertions(+), 9 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > index 5e00e611f077..ffde0d4af23c 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > @@ -1258,6 +1258,7 @@ struct intel_dp {
> > > > >  	bool link_trained;
> > > > >  	bool has_audio;
> > > > >  	bool reset_link_params;
> > > > > +	bool use_max_params;
> > > > >  	u8 dpcd[DP_RECEIVER_CAP_SIZE];
> > > > >  	u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
> > > > >  	u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > index ef2e06e292d5..85abcce492ca 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > @@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > > > >  {
> > > > >  	int index;
> > > > >  
> > > > > +	if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> > > > > +		DRM_DEBUG_KMS("Retrying Link training for eDP with max parameters\n");
> > > > > +		intel_dp->use_max_params = true;
> > > > > +		return 0;
> > > > > +	}
> > > > 
> > > > We need to remove the current check for intel_dp_can_link_train_fallback_for_edp() right?
> > > 
> > > No. Why do you think it needs to be removed?
> > >
> > 
> > Okay so if trying max params link training again fails on eDP, then it fallsback from max to lower values
> > and fallback link training continues until it can handle the fixed mode with the params or
> > the lowest params?
> > 
> > So if I understand it correctly we first try to use the optimum approach, if that fails then
> > we try with max params so in this iteration if it fails again then max params is still true
> > then it will fallback and call intel_dp_can_link_train_fallback_for_edp() and then
> > again keep retrying?
> 
> Yep.
> 
> -- 
> 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] 14+ messages in thread

* Re: [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
  2020-03-19 16:38 [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Ville Syrjala
                   ` (5 preceding siblings ...)
  2020-03-19 22:20 ` [Intel-gfx] [PATCH 1/3] " Manasi Navare
@ 2020-07-02  9:21 ` Timo Aaltonen
  6 siblings, 0 replies; 14+ messages in thread
From: Timo Aaltonen @ 2020-07-02  9:21 UTC (permalink / raw)
  To: Ville Syrjala, intel-gfx
  Cc: Matteo Iervasi, Jani Nikula, Albert Astals Cid,
	Emanuele Panigati, pocmatos


Hi, this seems to have been stuck on the list for a while now, how to
get it merged?

I've CC'd Paulo Matos who has tested it and found working. Paulo, you
might want to add a 'Tested-by' here.

On 19.3.2020 18.38, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Some new eDP panels don't like to operate at the max parameters, and
> instead we need to go for an optimal confiugration. That unfortunately
> doesn't work with older eDP panels which are generally only guaranteed
> to work at the max parameters.
> 
> To solve these two conflicting requirements let's start with the optimal
> setup, and if that fails we start again with the max parameters. The
> downside is probably an extra modeset when we switch strategies but
> I don't see a good way to avoid that.
> 
> For a bit of history we first tried to go for the fast+narrow in
> commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> fast and narrow"). but that had to be reverted due to regression
> on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> to max link rate and lane count on eDP"). So now we try to get
> the best of both worlds by using both strategies.
> 
> v2: Deal with output_bpp and uapi vs. hw state split
>     Reword some comments
> 
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport
> Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
> Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
> Cc: Timo Aaltonen <tjaalton@ubuntu.com>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> References: https://gitlab.freedesktop.org/drm/intel/issues/272
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  .../drm/i915/display/intel_display_types.h    |  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c       | 74 ++++++++++++++++---
>  2 files changed, 66 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 5e00e611f077..ffde0d4af23c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1258,6 +1258,7 @@ struct intel_dp {
>  	bool link_trained;
>  	bool has_audio;
>  	bool reset_link_params;
> +	bool use_max_params;
>  	u8 dpcd[DP_RECEIVER_CAP_SIZE];
>  	u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
>  	u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index ef2e06e292d5..85abcce492ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
>  {
>  	int index;
>  
> +	if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> +		DRM_DEBUG_KMS("Retrying Link training for eDP with max parameters\n");
> +		intel_dp->use_max_params = true;
> +		return 0;
> +	}
> +
>  	index = intel_dp_rate_index(intel_dp->common_rates,
>  				    intel_dp->num_common_rates,
>  				    link_rate);
> @@ -2046,6 +2052,44 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
>  	return -EINVAL;
>  }
>  
> +/* Optimize link config in order: max bpp, min lanes, min clock */
> +static int
> +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> +				  struct intel_crtc_state *pipe_config,
> +				  const struct link_config_limits *limits)
> +{
> +	const struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
> +	int bpp, clock, lane_count;
> +	int mode_rate, link_clock, link_avail;
> +
> +	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> +		int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
> +
> +		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> +						   output_bpp);
> +
> +		for (lane_count = limits->min_lane_count;
> +		     lane_count <= limits->max_lane_count;
> +		     lane_count <<= 1) {
> +			for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
> +				link_clock = intel_dp->common_rates[clock];
> +				link_avail = intel_dp_max_data_rate(link_clock,
> +								    lane_count);
> +
> +				if (mode_rate <= link_avail) {
> +					pipe_config->lane_count = lane_count;
> +					pipe_config->pipe_bpp = bpp;
> +					pipe_config->port_clock = link_clock;
> +
> +					return 0;
> +				}
> +			}
> +		}
> +	}
> +
> +	return -EINVAL;
> +}
> +
>  static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc)
>  {
>  	int i, num_bpc;
> @@ -2261,13 +2305,14 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>  	limits.min_bpp = intel_dp_min_bpp(pipe_config);
>  	limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>  
> -	if (intel_dp_is_edp(intel_dp)) {
> +	if (intel_dp->use_max_params) {
>  		/*
>  		 * Use the maximum clock and number of lanes the eDP panel
> -		 * advertizes being capable of. The panels are generally
> +		 * advertizes being capable of in case the initial fast
> +		 * optimal params failed us. The panels are generally
>  		 * designed to support only a single clock and lane
> -		 * configuration, and typically these values correspond to the
> -		 * native resolution of the panel.
> +		 * configuration, and typically on older panels these
> +		 * values correspond to the native resolution of the panel.
>  		 */
>  		limits.min_lane_count = limits.max_lane_count;
>  		limits.min_clock = limits.max_clock;
> @@ -2281,11 +2326,22 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>  		      intel_dp->common_rates[limits.max_clock],
>  		      limits.max_bpp, adjusted_mode->crtc_clock);
>  
> -	/*
> -	 * Optimize for slow and wide. This is the place to add alternative
> -	 * optimization policy.
> -	 */
> -	ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits);
> +	if (intel_dp_is_edp(intel_dp))
> +		/*
> +		 * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
> +		 * section A.1: "It is recommended that the minimum number of
> +		 * lanes be used, using the minimum link rate allowed for that
> +		 * lane configuration."
> +		 *
> +		 * Note that we fall back to the max clock and lane count for eDP
> +		 * panels that fail with the fast optimal settings (see
> +		 * intel_dp->use_max_params), in which case the fast vs. wide
> +		 * choice doesn't matter.
> +		 */
> +		ret = intel_dp_compute_link_config_fast(intel_dp, pipe_config, &limits);
> +	else
> +		/* Optimize for slow and wide. */
> +		ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits);
>  
>  	/* enable compression if the mode doesn't fit available BW */
>  	DRM_DEBUG_KMS("Force DSC en = %d\n", intel_dp->force_dsc_en);
> 


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

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

end of thread, other threads:[~2020-07-02  9:21 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-19 16:38 [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Ville Syrjala
2020-03-19 16:38 ` [Intel-gfx] [PATCH 2/3] drm: Refactor intel_dp_compute_link_config_*() Ville Syrjala
2020-03-19 16:38 ` [Intel-gfx] [PATCH 3/3] drm: Constify adjusted_mode a bit Ville Syrjala
2020-03-20 18:33   ` Manasi Navare
2020-03-19 16:53 ` [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Hans de Goede
2020-03-19 17:06   ` Ville Syrjälä
2020-03-19 17:46 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] " Patchwork
2020-03-19 19:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-03-19 22:20 ` [Intel-gfx] [PATCH 1/3] " Manasi Navare
2020-03-20 19:08   ` Ville Syrjälä
2020-03-20 23:17     ` Manasi Navare
2020-03-27 15:40       ` Ville Syrjälä
2020-03-27 18:09         ` Manasi Navare
2020-07-02  9:21 ` Timo Aaltonen

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.