intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
@ 2017-08-09 21:21 Jim Bride
  2017-08-09 21:40 ` ✓ Fi.CI.BAT: success for " Patchwork
                   ` (9 more replies)
  0 siblings, 10 replies; 22+ messages in thread
From: Jim Bride @ 2017-08-09 21:21 UTC (permalink / raw)
  To: intel-gfx; +Cc: Paulo Zanoni, Jani Nikula, Rodrigo Vivi

This set of changes has some history to them.  There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec.  These changes were:

commit 5fa836a9d859 ("drm/i915: DP link training optimization")
commit 4e96c97742f4 ("drm/i915: eDP link training optimization")

which were eventually hand-reverted by:

commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
                     feature")

in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915.  There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation.  The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes.  This patch, largely
based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
puts the eDP portions of this patch back in place.  None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.

v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier
      reading. (Chris)
    * Rebase
v5: * Checkpatch cleanup
    * Rebase

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi D Navare <manasi.d.navare@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c               |  4 +++-
 drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
 drivers/gpu/drm/i915/intel_drv.h              |  2 ++
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 76c8a0b..4bd409c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
  * If a CPU or PCH DP output is attached to an eDP panel, this function
  * will return true, and false otherwise.
  */
-static bool is_edp(struct intel_dp *intel_dp)
+bool is_edp(struct intel_dp *intel_dp)
 {
 	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
 
@@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
 		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
 
 		intel_dp->reset_link_params = false;
+		intel_dp->train_set_valid = false;
 	}
 
 	intel_dp_print_rates(intel_dp);
@@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 	intel_dp_set_source_rates(intel_dp);
 
 	intel_dp->reset_link_params = true;
+	intel_dp->train_set_valid = false;
 	intel_dp->pps_pipe = INVALID_PIPE;
 	intel_dp->active_pipe = INVALID_PIPE;
 
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..67032cf 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
 intel_dp_reset_link_train(struct intel_dp *intel_dp,
 			uint8_t dp_train_pat)
 {
-	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+	if (!intel_dp->train_set_valid)
+		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
 	intel_dp_set_signal_levels(intel_dp);
 	return intel_dp_set_link_train(intel_dp, dp_train_pat);
 }
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 				       DP_TRAINING_PATTERN_1 |
 				       DP_LINK_SCRAMBLING_DISABLE)) {
 		DRM_ERROR("failed to enable link training\n");
+		intel_dp->train_set_valid = false;
 		return false;
 	}
 
+	/*
+	 * The initial set of link parameters are set by this point, so go
+	 * ahead and set intel_dp->train_set_valid to false in case any of
+	 * the succeeding steps fail.  It will be set back to true if we were
+	 * able to achieve clock recovery in the specified configuration.
+	 */
+	intel_dp->train_set_valid = false;
+
 	voltage_tries = 1;
 	max_vswing_tries = 0;
 	for (;;) {
@@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 
 		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
 			DRM_DEBUG_KMS("clock recovery OK\n");
+			intel_dp->train_set_valid = is_edp(intel_dp);
 			return true;
 		}
 
@@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
 				     training_pattern |
 				     DP_LINK_SCRAMBLING_DISABLE)) {
 		DRM_ERROR("failed to start channel equalization\n");
+		intel_dp->train_set_valid = false;
 		return false;
 	}
 
@@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
 	/* Try 5 times, else fail and try at lower BW */
 	if (tries == 5) {
 		intel_dp_dump_link_status(link_status);
+		intel_dp->train_set_valid = false;
 		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
 	}
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f91de9c..792bf547 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -994,6 +994,7 @@ struct intel_dp {
 	struct drm_dp_aux aux;
 	enum intel_display_power_domain aux_power_domain;
 	uint8_t train_set[4];
+	bool train_set_valid;
 	int panel_power_up_delay;
 	int panel_power_down_delay;
 	int panel_power_cycle_delay;
@@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
 }
 
 bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool is_edp(struct intel_dp *intel_dp);
 int intel_dp_link_required(int pixel_clock, int bpp);
 int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
 bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
-- 
2.7.4

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

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

* ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
@ 2017-08-09 21:40 ` Patchwork
  2017-08-16 22:13 ` [PATCH v5] " Manasi Navare
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-08-09 21:40 UTC (permalink / raw)
  To: Jim Bride; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/edp: Be less aggressive about changing link config on eDP
URL   : https://patchwork.freedesktop.org/series/28588/
State : success

== Summary ==

Series 28588v1 drm/i915/edp: Be less aggressive about changing link config on eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/1/mbox/

Test gem_exec_flush:
        Subgroup basic-batch-kernel-default-uc:
                fail       -> PASS       (fi-snb-2600) fdo#100007
Test kms_flip:
        Subgroup basic-flip-vs-modeset:
                pass       -> SKIP       (fi-skl-x1585l) fdo#101781
Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-b:
                dmesg-warn -> PASS       (fi-byt-n2820) fdo#101705

fdo#100007 https://bugs.freedesktop.org/show_bug.cgi?id=100007
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u     total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:439s
fi-bdw-gvtdvm    total:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  time:418s
fi-blb-e6850     total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  time:365s
fi-bsw-n3050     total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  time:495s
fi-bxt-j4205     total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:492s
fi-byt-j1900     total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  time:513s
fi-byt-n2820     total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  time:514s
fi-glk-2a        total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:586s
fi-hsw-4770      total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:429s
fi-hsw-4770r     total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:404s
fi-ilk-650       total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  time:419s
fi-ivb-3520m     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:504s
fi-ivb-3770      total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:477s
fi-kbl-7500u     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:460s
fi-kbl-7560u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:572s
fi-kbl-r         total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:581s
fi-pnv-d510      total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  time:524s
fi-skl-6260u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:446s
fi-skl-6700k     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:642s
fi-skl-6770hq    total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:465s
fi-skl-gvtdvm    total:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  time:424s
fi-skl-x1585l    total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:467s
fi-snb-2520m     total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  time:553s
fi-snb-2600      total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  time:403s

2d0288b5b28c0d67460f0258a41bb4f78b812f29 drm-tip: 2017y-08m-09d-18h-09m-54s UTC integration manifest
7aeadd39ed6c drm/i915/edp: Be less aggressive about changing link config on eDP

== Logs ==

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

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

* Re: [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
  2017-08-09 21:40 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2017-08-16 22:13 ` Manasi Navare
  2017-08-17 17:50   ` Jim Bride
  2017-08-21 21:03 ` [PATCH v6] " Jim Bride
                   ` (7 subsequent siblings)
  9 siblings, 1 reply; 22+ messages in thread
From: Manasi Navare @ 2017-08-16 22:13 UTC (permalink / raw)
  To: Jim Bride; +Cc: Paulo Zanoni, Jani Nikula, intel-gfx, Rodrigo Vivi

On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> This set of changes has some history to them.  There were several attempts
> to add what was called "fast link training" to i915, which actually wasn't
> fast link training as per the DP spec.  These changes were:
> 
> commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> 
> which were eventually hand-reverted by:
> 
> commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
>                      feature")
> 
> in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> very bad side-effects on PSR functionality on Skylake. The issue at
> hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> (depending on the original link configuration) in order to quickly get
> the source and sink back in synchronization across the link before handing
> control back to the i915.  There's an assumption that none of the link
> configuration information has changed (and thus it's still valid) since the
> last full link training operation.  The revert above was identified via a
> bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> puts the eDP portions of this patch back in place.  None of the flickering
> issues that spurred the revert have been seen, and I suspect the real
> culprits here were addressed by some of the recent link training changes
> that Manasi has implemented, and PSR on Skylake is definitely more happy
> with these changes in-place.
> 
> v2 and v3: Rebase
> v4: * Clean up accesses to train_set_valid a bit for easier
>       reading. (Chris)
>     * Rebase
> v5: * Checkpatch cleanup
>     * Rebase
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Manasi D Navare <manasi.d.navare@intel.com>
> Cc: Mika Kahola <mika.kahola@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c               |  4 +++-
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
>  drivers/gpu/drm/i915/intel_drv.h              |  2 ++
>  3 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 76c8a0b..4bd409c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
>   * If a CPU or PCH DP output is attached to an eDP panel, this function
>   * will return true, and false otherwise.
>   */
> -static bool is_edp(struct intel_dp *intel_dp)
> +bool is_edp(struct intel_dp *intel_dp)
>  {
>  	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>  
> @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
>  		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
>  
>  		intel_dp->reset_link_params = false;
> +		intel_dp->train_set_valid = false;
>  	}
>  
>  	intel_dp_print_rates(intel_dp);
> @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
>  	intel_dp_set_source_rates(intel_dp);
>  
>  	intel_dp->reset_link_params = true;
> +	intel_dp->train_set_valid = false;
>  	intel_dp->pps_pipe = INVALID_PIPE;
>  	intel_dp->active_pipe = INVALID_PIPE;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa..67032cf 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -94,7 +94,8 @@ static bool
>  intel_dp_reset_link_train(struct intel_dp *intel_dp,
>  			uint8_t dp_train_pat)
>  {
> -	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> +	if (!intel_dp->train_set_valid)
> +		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
>  	intel_dp_set_signal_levels(intel_dp);
>  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
>  }
> @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>  				       DP_TRAINING_PATTERN_1 |
>  				       DP_LINK_SCRAMBLING_DISABLE)) {
>  		DRM_ERROR("failed to enable link training\n");
> +		intel_dp->train_set_valid = false;
>  		return false;
>  	}
>  
> +	/*
> +	 * The initial set of link parameters are set by this point, so go
> +	 * ahead and set intel_dp->train_set_valid to false in case any of
> +	 * the succeeding steps fail.  It will be set back to true if we were
> +	 * able to achieve clock recovery in the specified configuration.
> +	 */
> +	intel_dp->train_set_valid = false;
> +
>  	voltage_tries = 1;
>  	max_vswing_tries = 0;
>  	for (;;) {
> @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>  
>  		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
>  			DRM_DEBUG_KMS("clock recovery OK\n");
> +			intel_dp->train_set_valid = is_edp(intel_dp);
>  			return true;
>  		}
>  
> @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
>  				     training_pattern |
>  				     DP_LINK_SCRAMBLING_DISABLE)) {
>  		DRM_ERROR("failed to start channel equalization\n");
> +		intel_dp->train_set_valid = false;
>  		return false;
>  	}
>  
> @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
>  	/* Try 5 times, else fail and try at lower BW */
>  	if (tries == 5) {
>  		intel_dp_dump_link_status(link_status);
> +		intel_dp->train_set_valid = false;
>  		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
>  	}

There are other cases in the channel equalization loop of 5 tries where if drm_dp_clock_recover_ok
is not true then it just breaks from the for loop. Same in case of failure to update link train or
failure to get link status. In this case we dont set train_set_valid to false sinec the tries is not 5 yet
In this case since the train_set_valid was true when it entered this function, it will
stay true without actually succeeding at ch eq.
Shouldnt we be setting train_set_valid to false in these cases?
Or is there something I am missing here?

Regards
Manasi

>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index f91de9c..792bf547 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -994,6 +994,7 @@ struct intel_dp {
>  	struct drm_dp_aux aux;
>  	enum intel_display_power_domain aux_power_domain;
>  	uint8_t train_set[4];
> +	bool train_set_valid;
>  	int panel_power_up_delay;
>  	int panel_power_down_delay;
>  	int panel_power_cycle_delay;
> @@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
>  }
>  
>  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> +bool is_edp(struct intel_dp *intel_dp);
>  int intel_dp_link_required(int pixel_clock, int bpp);
>  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
>  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> -- 
> 2.7.4
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-16 22:13 ` [PATCH v5] " Manasi Navare
@ 2017-08-17 17:50   ` Jim Bride
  2017-08-17 19:20     ` Manasi Navare
  0 siblings, 1 reply; 22+ messages in thread
From: Jim Bride @ 2017-08-17 17:50 UTC (permalink / raw)
  To: Manasi Navare; +Cc: Paulo Zanoni, Jani Nikula, intel-gfx, Rodrigo Vivi

On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > This set of changes has some history to them.  There were several attempts
> > to add what was called "fast link training" to i915, which actually wasn't
> > fast link training as per the DP spec.  These changes were:
> > 
> > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > 
> > which were eventually hand-reverted by:
> > 
> > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> >                      feature")
> > 
> > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> > very bad side-effects on PSR functionality on Skylake. The issue at
> > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > (depending on the original link configuration) in order to quickly get
> > the source and sink back in synchronization across the link before handing
> > control back to the i915.  There's an assumption that none of the link
> > configuration information has changed (and thus it's still valid) since the
> > last full link training operation.  The revert above was identified via a
> > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > puts the eDP portions of this patch back in place.  None of the flickering
> > issues that spurred the revert have been seen, and I suspect the real
> > culprits here were addressed by some of the recent link training changes
> > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > with these changes in-place.
> > 
> > v2 and v3: Rebase
> > v4: * Clean up accesses to train_set_valid a bit for easier
> >       reading. (Chris)
> >     * Rebase
> > v5: * Checkpatch cleanup
> >     * Rebase
> > 
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > Cc: Mika Kahola <mika.kahola@intel.com>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c               |  4 +++-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> >  drivers/gpu/drm/i915/intel_drv.h              |  2 ++
> >  3 files changed, 19 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 76c8a0b..4bd409c 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
> >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> >   * will return true, and false otherwise.
> >   */
> > -static bool is_edp(struct intel_dp *intel_dp)
> > +bool is_edp(struct intel_dp *intel_dp)
> >  {
> >  	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> >  
> > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> >  		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> >  
> >  		intel_dp->reset_link_params = false;
> > +		intel_dp->train_set_valid = false;
> >  	}
> >  
> >  	intel_dp_print_rates(intel_dp);
> > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> >  	intel_dp_set_source_rates(intel_dp);
> >  
> >  	intel_dp->reset_link_params = true;
> > +	intel_dp->train_set_valid = false;
> >  	intel_dp->pps_pipe = INVALID_PIPE;
> >  	intel_dp->active_pipe = INVALID_PIPE;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..67032cf 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -94,7 +94,8 @@ static bool
> >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> >  			uint8_t dp_train_pat)
> >  {
> > -	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > +	if (!intel_dp->train_set_valid)
> > +		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> >  	intel_dp_set_signal_levels(intel_dp);
> >  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
> >  }
> > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >  				       DP_TRAINING_PATTERN_1 |
> >  				       DP_LINK_SCRAMBLING_DISABLE)) {
> >  		DRM_ERROR("failed to enable link training\n");
> > +		intel_dp->train_set_valid = false;
> >  		return false;
> >  	}
> >  
> > +	/*
> > +	 * The initial set of link parameters are set by this point, so go
> > +	 * ahead and set intel_dp->train_set_valid to false in case any of
> > +	 * the succeeding steps fail.  It will be set back to true if we were
> > +	 * able to achieve clock recovery in the specified configuration.
> > +	 */
> > +	intel_dp->train_set_valid = false;
> > +
> >  	voltage_tries = 1;
> >  	max_vswing_tries = 0;
> >  	for (;;) {
> > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >  
> >  		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> >  			DRM_DEBUG_KMS("clock recovery OK\n");
> > +			intel_dp->train_set_valid = is_edp(intel_dp);
> >  			return true;
> >  		}
> >  
> > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> >  				     training_pattern |
> >  				     DP_LINK_SCRAMBLING_DISABLE)) {
> >  		DRM_ERROR("failed to start channel equalization\n");
> > +		intel_dp->train_set_valid = false;
> >  		return false;
> >  	}
> >  
> > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> >  	/* Try 5 times, else fail and try at lower BW */
> >  	if (tries == 5) {
> >  		intel_dp_dump_link_status(link_status);
> > +		intel_dp->train_set_valid = false;
> >  		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> >  	}
> 
> There are other cases in the channel equalization loop of 5 tries where if drm_dp_clock_recover_ok
> is not true then it just breaks from the for loop. Same in case of failure to update link train or
> failure to get link status. In this case we dont set train_set_valid to false sinec the tries is not 5 yet
> In this case since the train_set_valid was true when it entered this function, it will
> stay true without actually succeeding at ch eq.
> Shouldnt we be setting train_set_valid to false in these cases?
> Or is there something I am missing here?

It's set to false before all of those, and then set back to true if the
retrain works and we're on eDP.  Making the change to do this was some
review feedback from Chris on an earlier version of the patch.

Jim


> Regards
> Manasi
> 
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index f91de9c..792bf547 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -994,6 +994,7 @@ struct intel_dp {
> >  	struct drm_dp_aux aux;
> >  	enum intel_display_power_domain aux_power_domain;
> >  	uint8_t train_set[4];
> > +	bool train_set_valid;
> >  	int panel_power_up_delay;
> >  	int panel_power_down_delay;
> >  	int panel_power_cycle_delay;
> > @@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> >  }
> >  
> >  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > +bool is_edp(struct intel_dp *intel_dp);
> >  int intel_dp_link_required(int pixel_clock, int bpp);
> >  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> > -- 
> > 2.7.4
> > 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-17 17:50   ` Jim Bride
@ 2017-08-17 19:20     ` Manasi Navare
  2017-08-17 19:52       ` Manasi Navare
  2017-08-17 19:54       ` Jim Bride
  0 siblings, 2 replies; 22+ messages in thread
From: Manasi Navare @ 2017-08-17 19:20 UTC (permalink / raw)
  To: Jim Bride; +Cc: Paulo Zanoni, Jani Nikula, intel-gfx, Rodrigo Vivi

On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote:
> On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > > This set of changes has some history to them.  There were several attempts
> > > to add what was called "fast link training" to i915, which actually wasn't
> > > fast link training as per the DP spec.  These changes were:
> > > 
> > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > 
> > > which were eventually hand-reverted by:
> > > 
> > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > >                      feature")
> > > 
> > > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > (depending on the original link configuration) in order to quickly get
> > > the source and sink back in synchronization across the link before handing
> > > control back to the i915.  There's an assumption that none of the link
> > > configuration information has changed (and thus it's still valid) since the
> > > last full link training operation.  The revert above was identified via a
> > > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > puts the eDP portions of this patch back in place.  None of the flickering
> > > issues that spurred the revert have been seen, and I suspect the real
> > > culprits here were addressed by some of the recent link training changes
> > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > with these changes in-place.
> > > 
> > > v2 and v3: Rebase
> > > v4: * Clean up accesses to train_set_valid a bit for easier
> > >       reading. (Chris)
> > >     * Rebase
> > > v5: * Checkpatch cleanup
> > >     * Rebase
> > > 
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c               |  4 +++-
> > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > >  drivers/gpu/drm/i915/intel_drv.h              |  2 ++
> > >  3 files changed, 19 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > index 76c8a0b..4bd409c 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
> > >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> > >   * will return true, and false otherwise.
> > >   */
> > > -static bool is_edp(struct intel_dp *intel_dp)
> > > +bool is_edp(struct intel_dp *intel_dp)
> > >  {
> > >  	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > >  
> > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > >  		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > >  
> > >  		intel_dp->reset_link_params = false;
> > > +		intel_dp->train_set_valid = false;
> > >  	}
> > >  
> > >  	intel_dp_print_rates(intel_dp);
> > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > >  	intel_dp_set_source_rates(intel_dp);
> > >  
> > >  	intel_dp->reset_link_params = true;
> > > +	intel_dp->train_set_valid = false;
> > >  	intel_dp->pps_pipe = INVALID_PIPE;
> > >  	intel_dp->active_pipe = INVALID_PIPE;
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > index 05907fa..67032cf 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > @@ -94,7 +94,8 @@ static bool
> > >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > >  			uint8_t dp_train_pat)
> > >  {
> > > -	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > +	if (!intel_dp->train_set_valid)
> > > +		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > >  	intel_dp_set_signal_levels(intel_dp);
> > >  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > >  }
> > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > >  				       DP_TRAINING_PATTERN_1 |
> > >  				       DP_LINK_SCRAMBLING_DISABLE)) {
> > >  		DRM_ERROR("failed to enable link training\n");
> > > +		intel_dp->train_set_valid = false;
> > >  		return false;
> > >  	}
> > >  
> > > +	/*
> > > +	 * The initial set of link parameters are set by this point, so go
> > > +	 * ahead and set intel_dp->train_set_valid to false in case any of
> > > +	 * the succeeding steps fail.  It will be set back to true if we were
> > > +	 * able to achieve clock recovery in the specified configuration.
> > > +	 */
> > > +	intel_dp->train_set_valid = false;
> > > +
> > >  	voltage_tries = 1;
> > >  	max_vswing_tries = 0;
> > >  	for (;;) {
> > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > >  
> > >  		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > >  			DRM_DEBUG_KMS("clock recovery OK\n");
> > > +			intel_dp->train_set_valid = is_edp(intel_dp);
> > >  			return true;
> > >  		}
> > >  
> > > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > >  				     training_pattern |
> > >  				     DP_LINK_SCRAMBLING_DISABLE)) {
> > >  		DRM_ERROR("failed to start channel equalization\n");
> > > +		intel_dp->train_set_valid = false;
> > >  		return false;
> > >  	}
> > >  
> > > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > >  	/* Try 5 times, else fail and try at lower BW */
> > >  	if (tries == 5) {
> > >  		intel_dp_dump_link_status(link_status);
> > > +		intel_dp->train_set_valid = false;
> > >  		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > >  	}
> > 
> > There are other cases in the channel equalization loop of 5 tries where if drm_dp_clock_recover_ok
> > is not true then it just breaks from the for loop. Same in case of failure to update link train or
> > failure to get link status. In this case we dont set train_set_valid to false sinec the tries is not 5 yet
> > In this case since the train_set_valid was true when it entered this function, it will
> > stay true without actually succeeding at ch eq.
> > Shouldnt we be setting train_set_valid to false in these cases?
> > Or is there something I am missing here?
> 
> It's set to false before all of those, and then set back to true if the
> retrain works and we're on eDP.  Making the change to do this was some
> review feedback from Chris on an earlier version of the patch.
> 
> Jim
> 
>

I see that it is set to false before starting the clock recovery but after clock recovery
succeeds, this is set to true and only then you will proceed with channel equalization.
And in channel equalization, it never gets set to false in case of the failures I mentioned above since
we just break there.
It then gets set to false only if the tries are 5 but it should also be set to false in case
of other failures that I mentioned else we will end up leaving it to true even when channel EQ never
succeeded.

Manasi
 
> > Regards
> > Manasi
> > 
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > index f91de9c..792bf547 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -994,6 +994,7 @@ struct intel_dp {
> > >  	struct drm_dp_aux aux;
> > >  	enum intel_display_power_domain aux_power_domain;
> > >  	uint8_t train_set[4];
> > > +	bool train_set_valid;
> > >  	int panel_power_up_delay;
> > >  	int panel_power_down_delay;
> > >  	int panel_power_cycle_delay;
> > > @@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> > >  }
> > >  
> > >  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > +bool is_edp(struct intel_dp *intel_dp);
> > >  int intel_dp_link_required(int pixel_clock, int bpp);
> > >  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > >  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> > > -- 
> > > 2.7.4
> > > 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-17 19:20     ` Manasi Navare
@ 2017-08-17 19:52       ` Manasi Navare
  2017-08-17 19:54       ` Jim Bride
  1 sibling, 0 replies; 22+ messages in thread
From: Manasi Navare @ 2017-08-17 19:52 UTC (permalink / raw)
  To: Jim Bride; +Cc: Jani Nikula, intel-gfx, Paulo Zanoni, Rodrigo Vivi

On Thu, Aug 17, 2017 at 12:20:03PM -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote:
> > On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> > > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > > > This set of changes has some history to them.  There were several attempts
> > > > to add what was called "fast link training" to i915, which actually wasn't
> > > > fast link training as per the DP spec.  These changes were:
> > > > 
> > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > > 
> > > > which were eventually hand-reverted by:
> > > > 
> > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > > >                      feature")
> > > > 
> > > > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> > > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > > (depending on the original link configuration) in order to quickly get
> > > > the source and sink back in synchronization across the link before handing
> > > > control back to the i915.  There's an assumption that none of the link
> > > > configuration information has changed (and thus it's still valid) since the
> > > > last full link training operation.  The revert above was identified via a
> > > > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > > puts the eDP portions of this patch back in place.  None of the flickering
> > > > issues that spurred the revert have been seen, and I suspect the real
> > > > culprits here were addressed by some of the recent link training changes
> > > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > > with these changes in-place.
> > > > 
> > > > v2 and v3: Rebase
> > > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > >       reading. (Chris)
> > > >     * Rebase
> > > > v5: * Checkpatch cleanup
> > > >     * Rebase
> > > > 
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c               |  4 +++-
> > > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > > >  drivers/gpu/drm/i915/intel_drv.h              |  2 ++
> > > >  3 files changed, 19 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 76c8a0b..4bd409c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
> > > >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> > > >   * will return true, and false otherwise.
> > > >   */
> > > > -static bool is_edp(struct intel_dp *intel_dp)
> > > > +bool is_edp(struct intel_dp *intel_dp)

I also need this function to be exposed to files outside of intel_dp.c
for the patch:
https://patchwork.freedesktop.org/series/28900/
But one of the review comments I got is to prefix the name of this function with intel_dp
when exposing it to outside of intel_dp.c which makes sense as per the naming conventions
of the other functions. But we already have a function intel_dp_is_edp() used to get VBT information.
Any suggestions for the name? And do you want to make this change as part of your series so
I can rebase my patch on top of this?

Regards
Manasi

> > > >  {
> > > >  	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > >  
> > > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > > >  		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > >  
> > > >  		intel_dp->reset_link_params = false;
> > > > +		intel_dp->train_set_valid = false;
> > > >  	}
> > > >  
> > > >  	intel_dp_print_rates(intel_dp);
> > > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > > >  	intel_dp_set_source_rates(intel_dp);
> > > >  
> > > >  	intel_dp->reset_link_params = true;
> > > > +	intel_dp->train_set_valid = false;
> > > >  	intel_dp->pps_pipe = INVALID_PIPE;
> > > >  	intel_dp->active_pipe = INVALID_PIPE;
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > index 05907fa..67032cf 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > @@ -94,7 +94,8 @@ static bool
> > > >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > > >  			uint8_t dp_train_pat)
> > > >  {
> > > > -	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > > +	if (!intel_dp->train_set_valid)
> > > > +		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > >  	intel_dp_set_signal_levels(intel_dp);
> > > >  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > > >  }
> > > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > >  				       DP_TRAINING_PATTERN_1 |
> > > >  				       DP_LINK_SCRAMBLING_DISABLE)) {
> > > >  		DRM_ERROR("failed to enable link training\n");
> > > > +		intel_dp->train_set_valid = false;
> > > >  		return false;
> > > >  	}
> > > >  
> > > > +	/*
> > > > +	 * The initial set of link parameters are set by this point, so go
> > > > +	 * ahead and set intel_dp->train_set_valid to false in case any of
> > > > +	 * the succeeding steps fail.  It will be set back to true if we were
> > > > +	 * able to achieve clock recovery in the specified configuration.
> > > > +	 */
> > > > +	intel_dp->train_set_valid = false;
> > > > +
> > > >  	voltage_tries = 1;
> > > >  	max_vswing_tries = 0;
> > > >  	for (;;) {
> > > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > >  
> > > >  		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > > >  			DRM_DEBUG_KMS("clock recovery OK\n");
> > > > +			intel_dp->train_set_valid = is_edp(intel_dp);
> > > >  			return true;
> > > >  		}
> > > >  
> > > > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > >  				     training_pattern |
> > > >  				     DP_LINK_SCRAMBLING_DISABLE)) {
> > > >  		DRM_ERROR("failed to start channel equalization\n");
> > > > +		intel_dp->train_set_valid = false;
> > > >  		return false;
> > > >  	}
> > > >  
> > > > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > >  	/* Try 5 times, else fail and try at lower BW */
> > > >  	if (tries == 5) {
> > > >  		intel_dp_dump_link_status(link_status);
> > > > +		intel_dp->train_set_valid = false;
> > > >  		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > > >  	}
> > > 
> > > There are other cases in the channel equalization loop of 5 tries where if drm_dp_clock_recover_ok
> > > is not true then it just breaks from the for loop. Same in case of failure to update link train or
> > > failure to get link status. In this case we dont set train_set_valid to false sinec the tries is not 5 yet
> > > In this case since the train_set_valid was true when it entered this function, it will
> > > stay true without actually succeeding at ch eq.
> > > Shouldnt we be setting train_set_valid to false in these cases?
> > > Or is there something I am missing here?
> > 
> > It's set to false before all of those, and then set back to true if the
> > retrain works and we're on eDP.  Making the change to do this was some
> > review feedback from Chris on an earlier version of the patch.
> > 
> > Jim
> > 
> >
> 
> I see that it is set to false before starting the clock recovery but after clock recovery
> succeeds, this is set to true and only then you will proceed with channel equalization.
> And in channel equalization, it never gets set to false in case of the failures I mentioned above since
> we just break there.
> It then gets set to false only if the tries are 5 but it should also be set to false in case
> of other failures that I mentioned else we will end up leaving it to true even when channel EQ never
> succeeded.
> 
> Manasi
>  
> > > Regards
> > > Manasi
> > > 
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > > index f91de9c..792bf547 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -994,6 +994,7 @@ struct intel_dp {
> > > >  	struct drm_dp_aux aux;
> > > >  	enum intel_display_power_domain aux_power_domain;
> > > >  	uint8_t train_set[4];
> > > > +	bool train_set_valid;
> > > >  	int panel_power_up_delay;
> > > >  	int panel_power_down_delay;
> > > >  	int panel_power_cycle_delay;
> > > > @@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> > > >  }
> > > >  
> > > >  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > > +bool is_edp(struct intel_dp *intel_dp);
> > > >  int intel_dp_link_required(int pixel_clock, int bpp);
> > > >  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > > >  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> > > > -- 
> > > > 2.7.4
> > > > 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-17 19:20     ` Manasi Navare
  2017-08-17 19:52       ` Manasi Navare
@ 2017-08-17 19:54       ` Jim Bride
  1 sibling, 0 replies; 22+ messages in thread
From: Jim Bride @ 2017-08-17 19:54 UTC (permalink / raw)
  To: Manasi Navare; +Cc: Paulo Zanoni, Jani Nikula, intel-gfx, Rodrigo Vivi

On Thu, Aug 17, 2017 at 12:20:03PM -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote:
> > On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> > > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > > > This set of changes has some history to them.  There were several attempts
> > > > to add what was called "fast link training" to i915, which actually wasn't
> > > > fast link training as per the DP spec.  These changes were:
> > > > 
> > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > > 
> > > > which were eventually hand-reverted by:
> > > > 
> > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > > >                      feature")
> > > > 
> > > > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> > > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > > (depending on the original link configuration) in order to quickly get
> > > > the source and sink back in synchronization across the link before handing
> > > > control back to the i915.  There's an assumption that none of the link
> > > > configuration information has changed (and thus it's still valid) since the
> > > > last full link training operation.  The revert above was identified via a
> > > > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > > puts the eDP portions of this patch back in place.  None of the flickering
> > > > issues that spurred the revert have been seen, and I suspect the real
> > > > culprits here were addressed by some of the recent link training changes
> > > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > > with these changes in-place.
> > > > 
> > > > v2 and v3: Rebase
> > > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > >       reading. (Chris)
> > > >     * Rebase
> > > > v5: * Checkpatch cleanup
> > > >     * Rebase
> > > > 
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c               |  4 +++-
> > > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > > >  drivers/gpu/drm/i915/intel_drv.h              |  2 ++
> > > >  3 files changed, 19 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 76c8a0b..4bd409c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
> > > >   * If a CPU or PCH DP output is attached to an eDP panel, this function
> > > >   * will return true, and false otherwise.
> > > >   */
> > > > -static bool is_edp(struct intel_dp *intel_dp)
> > > > +bool is_edp(struct intel_dp *intel_dp)
> > > >  {
> > > >  	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > >  
> > > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > > >  		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > >  
> > > >  		intel_dp->reset_link_params = false;
> > > > +		intel_dp->train_set_valid = false;
> > > >  	}
> > > >  
> > > >  	intel_dp_print_rates(intel_dp);
> > > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > > >  	intel_dp_set_source_rates(intel_dp);
> > > >  
> > > >  	intel_dp->reset_link_params = true;
> > > > +	intel_dp->train_set_valid = false;
> > > >  	intel_dp->pps_pipe = INVALID_PIPE;
> > > >  	intel_dp->active_pipe = INVALID_PIPE;
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > index 05907fa..67032cf 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > @@ -94,7 +94,8 @@ static bool
> > > >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > > >  			uint8_t dp_train_pat)
> > > >  {
> > > > -	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > > +	if (!intel_dp->train_set_valid)
> > > > +		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > >  	intel_dp_set_signal_levels(intel_dp);
> > > >  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > > >  }
> > > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > >  				       DP_TRAINING_PATTERN_1 |
> > > >  				       DP_LINK_SCRAMBLING_DISABLE)) {
> > > >  		DRM_ERROR("failed to enable link training\n");
> > > > +		intel_dp->train_set_valid = false;
> > > >  		return false;
> > > >  	}
> > > >  
> > > > +	/*
> > > > +	 * The initial set of link parameters are set by this point, so go
> > > > +	 * ahead and set intel_dp->train_set_valid to false in case any of
> > > > +	 * the succeeding steps fail.  It will be set back to true if we were
> > > > +	 * able to achieve clock recovery in the specified configuration.
> > > > +	 */
> > > > +	intel_dp->train_set_valid = false;
> > > > +
> > > >  	voltage_tries = 1;
> > > >  	max_vswing_tries = 0;
> > > >  	for (;;) {
> > > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > >  
> > > >  		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > > >  			DRM_DEBUG_KMS("clock recovery OK\n");
> > > > +			intel_dp->train_set_valid = is_edp(intel_dp);
> > > >  			return true;
> > > >  		}
> > > >  
> > > > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > >  				     training_pattern |
> > > >  				     DP_LINK_SCRAMBLING_DISABLE)) {
> > > >  		DRM_ERROR("failed to start channel equalization\n");
> > > > +		intel_dp->train_set_valid = false;
> > > >  		return false;
> > > >  	}
> > > >  
> > > > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > >  	/* Try 5 times, else fail and try at lower BW */
> > > >  	if (tries == 5) {
> > > >  		intel_dp_dump_link_status(link_status);
> > > > +		intel_dp->train_set_valid = false;
> > > >  		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > > >  	}
> > > 
> > > There are other cases in the channel equalization loop of 5 tries where if drm_dp_clock_recover_ok
> > > is not true then it just breaks from the for loop. Same in case of failure to update link train or
> > > failure to get link status. In this case we dont set train_set_valid to false sinec the tries is not 5 yet
> > > In this case since the train_set_valid was true when it entered this function, it will
> > > stay true without actually succeeding at ch eq.
> > > Shouldnt we be setting train_set_valid to false in these cases?
> > > Or is there something I am missing here?
> > 
> > It's set to false before all of those, and then set back to true if the
> > retrain works and we're on eDP.  Making the change to do this was some
> > review feedback from Chris on an earlier version of the patch.
> > 
> > Jim
> > 
> >
> 
> I see that it is set to false before starting the clock recovery but after clock recovery
> succeeds, this is set to true and only then you will proceed with channel equalization.
> And in channel equalization, it never gets set to false in case of the failures I mentioned above since
> we just break there.
> It then gets set to false only if the tries are 5 but it should also be set to false in case
> of other failures that I mentioned else we will end up leaving it to true even when channel EQ never
> succeeded.

I see where you're talking about now.  I honestly believe that the code
as written is broken.  All of those failing 'break' statements should be
'continue' statements (the break for success is fine.)  As the code is written,
we break out of the loop on the first failure, and if (tries == 5) will never
be true.  If we actually loop through five times before we give up, then
this patch as written is fine.

Jim


> Manasi
>  
> > > Regards
> > > Manasi
> > > 
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > > index f91de9c..792bf547 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -994,6 +994,7 @@ struct intel_dp {
> > > >  	struct drm_dp_aux aux;
> > > >  	enum intel_display_power_domain aux_power_domain;
> > > >  	uint8_t train_set[4];
> > > > +	bool train_set_valid;
> > > >  	int panel_power_up_delay;
> > > >  	int panel_power_down_delay;
> > > >  	int panel_power_cycle_delay;
> > > > @@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> > > >  }
> > > >  
> > > >  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > > +bool is_edp(struct intel_dp *intel_dp);
> > > >  int intel_dp_link_required(int pixel_clock, int bpp);
> > > >  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > > >  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> > > > -- 
> > > > 2.7.4
> > > > 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* [PATCH v6] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
  2017-08-09 21:40 ` ✓ Fi.CI.BAT: success for " Patchwork
  2017-08-16 22:13 ` [PATCH v5] " Manasi Navare
@ 2017-08-21 21:03 ` Jim Bride
  2017-08-21 23:27   ` Vivi, Rodrigo
  2017-08-21 21:24 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev2) Patchwork
                   ` (6 subsequent siblings)
  9 siblings, 1 reply; 22+ messages in thread
From: Jim Bride @ 2017-08-21 21:03 UTC (permalink / raw)
  To: intel-gfx; +Cc: Paulo Zanoni, Jani Nikula, Rodrigo Vivi

This set of changes has some history to them.  There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec.  These changes were:

commit 5fa836a9d859 ("drm/i915: DP link training optimization")
commit 4e96c97742f4 ("drm/i915: eDP link training optimization")

which were eventually hand-reverted by:

commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
                     feature")

in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915.  There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation.  The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes.  This patch, largely
based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
puts the eDP portions of this patch back in place.  None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.

v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier
      reading. (Chris)
    * Rebase
v5: * Checkpatch cleanup
    * Rebase
v6: * is_edp() => intel_dp_is_edp()
    * rebase

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi D Navare <manasi.d.navare@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c               |  2 ++
 drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
 drivers/gpu/drm/i915/intel_drv.h              |  2 ++
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e385658..38bc7e0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
 		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
 
 		intel_dp->reset_link_params = false;
+		intel_dp->train_set_valid = false;
 	}
 
 	intel_dp_print_rates(intel_dp);
@@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 	intel_dp_set_source_rates(intel_dp);
 
 	intel_dp->reset_link_params = true;
+	intel_dp->train_set_valid = false;
 	intel_dp->pps_pipe = INVALID_PIPE;
 	intel_dp->active_pipe = INVALID_PIPE;
 
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..79fe369 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
 intel_dp_reset_link_train(struct intel_dp *intel_dp,
 			uint8_t dp_train_pat)
 {
-	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+	if (!intel_dp->train_set_valid)
+		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
 	intel_dp_set_signal_levels(intel_dp);
 	return intel_dp_set_link_train(intel_dp, dp_train_pat);
 }
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 				       DP_TRAINING_PATTERN_1 |
 				       DP_LINK_SCRAMBLING_DISABLE)) {
 		DRM_ERROR("failed to enable link training\n");
+		intel_dp->train_set_valid = false;
 		return false;
 	}
 
+	/*
+	 * The initial set of link parameters are set by this point, so go
+	 * ahead and set intel_dp->train_set_valid to false in case any of
+	 * the succeeding steps fail.  It will be set back to true if we were
+	 * able to achieve clock recovery in the specified configuration.
+	 */
+	intel_dp->train_set_valid = false;
+
 	voltage_tries = 1;
 	max_vswing_tries = 0;
 	for (;;) {
@@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 
 		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
 			DRM_DEBUG_KMS("clock recovery OK\n");
+			intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
 			return true;
 		}
 
@@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
 				     training_pattern |
 				     DP_LINK_SCRAMBLING_DISABLE)) {
 		DRM_ERROR("failed to start channel equalization\n");
+		intel_dp->train_set_valid = false;
 		return false;
 	}
 
@@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
 	/* Try 5 times, else fail and try at lower BW */
 	if (tries == 5) {
 		intel_dp_dump_link_status(link_status);
+		intel_dp->train_set_valid = false;
 		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
 	}
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2940d39..891c892 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -995,6 +995,7 @@ struct intel_dp {
 	struct drm_dp_aux aux;
 	enum intel_display_power_domain aux_power_domain;
 	uint8_t train_set[4];
+	bool train_set_valid;
 	int panel_power_up_delay;
 	int panel_power_down_delay;
 	int panel_power_cycle_delay;
@@ -1549,6 +1550,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
 }
 
 bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool is_edp(struct intel_dp *intel_dp);
 int intel_dp_link_required(int pixel_clock, int bpp);
 int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
 bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
-- 
2.7.4

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

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

* ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev2)
  2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
                   ` (2 preceding siblings ...)
  2017-08-21 21:03 ` [PATCH v6] " Jim Bride
@ 2017-08-21 21:24 ` Patchwork
  2017-08-22 16:34 ` [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-08-21 21:24 UTC (permalink / raw)
  To: Jim Bride; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/edp: Be less aggressive about changing link config on eDP (rev2)
URL   : https://patchwork.freedesktop.org/series/28588/
State : success

== Summary ==

Series 28588v2 drm/i915/edp: Be less aggressive about changing link config on eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/2/mbox/

Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-b:
                pass       -> DMESG-WARN (fi-byt-n2820) fdo#101705

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

fi-bdw-5557u     total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:458s
fi-bdw-gvtdvm    total:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  time:445s
fi-blb-e6850     total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  time:359s
fi-bsw-n3050     total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  time:554s
fi-bwr-2160      total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  time:251s
fi-bxt-j4205     total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:524s
fi-byt-j1900     total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  time:526s
fi-byt-n2820     total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  time:510s
fi-elk-e7500     total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  time:431s
fi-glk-2a        total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:611s
fi-hsw-4770      total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:444s
fi-hsw-4770r     total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:419s
fi-ilk-650       total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  time:423s
fi-ivb-3520m     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:507s
fi-ivb-3770      total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:476s
fi-kbl-7260u     total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  time:499s
fi-kbl-7500u     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:477s
fi-kbl-7560u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:598s
fi-kbl-r         total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:600s
fi-pnv-d510      total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  time:526s
fi-skl-6260u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:476s
fi-skl-6700k     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:480s
fi-skl-6770hq    total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:484s
fi-skl-gvtdvm    total:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  time:436s
fi-skl-x1585l    total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:500s
fi-snb-2520m     total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  time:557s
fi-snb-2600      total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  time:413s

dbfb2f62576e1c3550d10398b097589959356db3 drm-tip: 2017y-08m-21d-08h-13m-34s UTC integration manifest
b1365d9a97db drm/i915/edp: Be less aggressive about changing link config on eDP

== Logs ==

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

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

* Re: [PATCH v6] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-21 21:03 ` [PATCH v6] " Jim Bride
@ 2017-08-21 23:27   ` Vivi, Rodrigo
  2017-08-22 16:32     ` Jim Bride
  0 siblings, 1 reply; 22+ messages in thread
From: Vivi, Rodrigo @ 2017-08-21 23:27 UTC (permalink / raw)
  To: jim.bride@linux.intel.com
  Cc: Zanoni, Paulo R, Nikula, Jani, intel-gfx@lists.freedesktop.org

On Mon, 2017-08-21 at 14:03 -0700, Jim Bride wrote:
> This set of changes has some history to them.  There were several attempts
> to add what was called "fast link training" to i915, which actually wasn't
> fast link training as per the DP spec.  These changes were:
> 
> commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> 
> which were eventually hand-reverted by:
> 
> commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
>                      feature")
> 
> in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> very bad side-effects on PSR functionality on Skylake. The issue at
> hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> (depending on the original link configuration) in order to quickly get
> the source and sink back in synchronization across the link before handing
> control back to the i915.  There's an assumption that none of the link
> configuration information has changed (and thus it's still valid) since the
> last full link training operation.  The revert above was identified via a
> bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> puts the eDP portions of this patch back in place.  None of the flickering
> issues that spurred the revert have been seen, and I suspect the real
> culprits here were addressed by some of the recent link training changes
> that Manasi has implemented, and PSR on Skylake is definitely more happy
> with these changes in-place.
> 
> v2 and v3: Rebase
> v4: * Clean up accesses to train_set_valid a bit for easier
>       reading. (Chris)
>     * Rebase
> v5: * Checkpatch cleanup
>     * Rebase
> v6: * is_edp() => intel_dp_is_edp()
>     * rebase
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Manasi D Navare <manasi.d.navare@intel.com>
> Cc: Mika Kahola <mika.kahola@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c               |  2 ++
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
>  drivers/gpu/drm/i915/intel_drv.h              |  2 ++
>  3 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e385658..38bc7e0 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
>  		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
>  
>  		intel_dp->reset_link_params = false;
> +		intel_dp->train_set_valid = false;
>  	}
>  
>  	intel_dp_print_rates(intel_dp);
> @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
>  	intel_dp_set_source_rates(intel_dp);
>  
>  	intel_dp->reset_link_params = true;
> +	intel_dp->train_set_valid = false;
>  	intel_dp->pps_pipe = INVALID_PIPE;
>  	intel_dp->active_pipe = INVALID_PIPE;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa..79fe369 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -94,7 +94,8 @@ static bool
>  intel_dp_reset_link_train(struct intel_dp *intel_dp,
>  			uint8_t dp_train_pat)
>  {
> -	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> +	if (!intel_dp->train_set_valid)
> +		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
>  	intel_dp_set_signal_levels(intel_dp);
>  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
>  }
> @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>  				       DP_TRAINING_PATTERN_1 |
>  				       DP_LINK_SCRAMBLING_DISABLE)) {
>  		DRM_ERROR("failed to enable link training\n");
> +		intel_dp->train_set_valid = false;
>  		return false;
>  	}
>  
> +	/*
> +	 * The initial set of link parameters are set by this point, so go
> +	 * ahead and set intel_dp->train_set_valid to false in case any of
> +	 * the succeeding steps fail.  It will be set back to true if we were
> +	 * able to achieve clock recovery in the specified configuration.
> +	 */
> +	intel_dp->train_set_valid = false;
> +
>  	voltage_tries = 1;
>  	max_vswing_tries = 0;
>  	for (;;) {
> @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>  
>  		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
>  			DRM_DEBUG_KMS("clock recovery OK\n");
> +			intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);

Is this one really enough for this case?

I wonder if we should merge is_edp and intel_dp_is_edp somehow instead
of fighting with names and their meanings...

>  			return true;
>  		}
>  
> @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
>  				     training_pattern |
>  				     DP_LINK_SCRAMBLING_DISABLE)) {
>  		DRM_ERROR("failed to start channel equalization\n");
> +		intel_dp->train_set_valid = false;
>  		return false;
>  	}
>  
> @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
>  	/* Try 5 times, else fail and try at lower BW */
>  	if (tries == 5) {
>  		intel_dp_dump_link_status(link_status);
> +		intel_dp->train_set_valid = false;
>  		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
>  	}
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 2940d39..891c892 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -995,6 +995,7 @@ struct intel_dp {
>  	struct drm_dp_aux aux;
>  	enum intel_display_power_domain aux_power_domain;
>  	uint8_t train_set[4];
> +	bool train_set_valid;
>  	int panel_power_up_delay;
>  	int panel_power_down_delay;
>  	int panel_power_cycle_delay;
> @@ -1549,6 +1550,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
>  }
>  
>  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> +bool is_edp(struct intel_dp *intel_dp);

it seems you don't need this anymore...

>  int intel_dp_link_required(int pixel_clock, int bpp);
>  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
>  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,

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

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

* Re: [PATCH v6] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-21 23:27   ` Vivi, Rodrigo
@ 2017-08-22 16:32     ` Jim Bride
  0 siblings, 0 replies; 22+ messages in thread
From: Jim Bride @ 2017-08-22 16:32 UTC (permalink / raw)
  To: Vivi, Rodrigo
  Cc: Zanoni, Paulo R, Nikula, Jani, intel-gfx@lists.freedesktop.org

On Mon, Aug 21, 2017 at 11:27:37PM +0000, Vivi, Rodrigo wrote:
> On Mon, 2017-08-21 at 14:03 -0700, Jim Bride wrote:
> > This set of changes has some history to them.  There were several attempts
> > to add what was called "fast link training" to i915, which actually wasn't
> > fast link training as per the DP spec.  These changes were:
> > 
> > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > 
> > which were eventually hand-reverted by:
> > 
> > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> >                      feature")
> > 
> > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> > very bad side-effects on PSR functionality on Skylake. The issue at
> > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > (depending on the original link configuration) in order to quickly get
> > the source and sink back in synchronization across the link before handing
> > control back to the i915.  There's an assumption that none of the link
> > configuration information has changed (and thus it's still valid) since the
> > last full link training operation.  The revert above was identified via a
> > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > puts the eDP portions of this patch back in place.  None of the flickering
> > issues that spurred the revert have been seen, and I suspect the real
> > culprits here were addressed by some of the recent link training changes
> > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > with these changes in-place.
> > 
> > v2 and v3: Rebase
> > v4: * Clean up accesses to train_set_valid a bit for easier
> >       reading. (Chris)
> >     * Rebase
> > v5: * Checkpatch cleanup
> >     * Rebase
> > v6: * is_edp() => intel_dp_is_edp()
> >     * rebase
> > 
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > Cc: Mika Kahola <mika.kahola@intel.com>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c               |  2 ++
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> >  drivers/gpu/drm/i915/intel_drv.h              |  2 ++
> >  3 files changed, 18 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index e385658..38bc7e0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> >  		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> >  
> >  		intel_dp->reset_link_params = false;
> > +		intel_dp->train_set_valid = false;
> >  	}
> >  
> >  	intel_dp_print_rates(intel_dp);
> > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> >  	intel_dp_set_source_rates(intel_dp);
> >  
> >  	intel_dp->reset_link_params = true;
> > +	intel_dp->train_set_valid = false;
> >  	intel_dp->pps_pipe = INVALID_PIPE;
> >  	intel_dp->active_pipe = INVALID_PIPE;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..79fe369 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -94,7 +94,8 @@ static bool
> >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> >  			uint8_t dp_train_pat)
> >  {
> > -	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > +	if (!intel_dp->train_set_valid)
> > +		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> >  	intel_dp_set_signal_levels(intel_dp);
> >  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
> >  }
> > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >  				       DP_TRAINING_PATTERN_1 |
> >  				       DP_LINK_SCRAMBLING_DISABLE)) {
> >  		DRM_ERROR("failed to enable link training\n");
> > +		intel_dp->train_set_valid = false;
> >  		return false;
> >  	}
> >  
> > +	/*
> > +	 * The initial set of link parameters are set by this point, so go
> > +	 * ahead and set intel_dp->train_set_valid to false in case any of
> > +	 * the succeeding steps fail.  It will be set back to true if we were
> > +	 * able to achieve clock recovery in the specified configuration.
> > +	 */
> > +	intel_dp->train_set_valid = false;
> > +
> >  	voltage_tries = 1;
> >  	max_vswing_tries = 0;
> >  	for (;;) {
> > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >  
> >  		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> >  			DRM_DEBUG_KMS("clock recovery OK\n");
> > +			intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
> 
> Is this one really enough for this case?

Yep, it's the only success path.

> I wonder if we should merge is_edp and intel_dp_is_edp somehow instead
> of fighting with names and their meanings...

Jani patched the two functions while I was wrestling with how to
rename is_edp().  Even though it's potentially confusing, I do
think intel_dp_is_edp() is probably as good as it gets.

> >  			return true;
> >  		}
> >  
> > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> >  				     training_pattern |
> >  				     DP_LINK_SCRAMBLING_DISABLE)) {
> >  		DRM_ERROR("failed to start channel equalization\n");
> > +		intel_dp->train_set_valid = false;
> >  		return false;
> >  	}
> >  
> > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> >  	/* Try 5 times, else fail and try at lower BW */
> >  	if (tries == 5) {
> >  		intel_dp_dump_link_status(link_status);
> > +		intel_dp->train_set_valid = false;
> >  		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> >  	}
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index 2940d39..891c892 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -995,6 +995,7 @@ struct intel_dp {
> >  	struct drm_dp_aux aux;
> >  	enum intel_display_power_domain aux_power_domain;
> >  	uint8_t train_set[4];
> > +	bool train_set_valid;
> >  	int panel_power_up_delay;
> >  	int panel_power_down_delay;
> >  	int panel_power_cycle_delay;
> > @@ -1549,6 +1550,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> >  }
> >  
> >  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > +bool is_edp(struct intel_dp *intel_dp);

Whoops.  I'll fix this.

> it seems you don't need this anymore...
> 
> >  int intel_dp_link_required(int pixel_clock, int bpp);
> >  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
                   ` (3 preceding siblings ...)
  2017-08-21 21:24 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev2) Patchwork
@ 2017-08-22 16:34 ` Jim Bride
  2017-09-15 18:19   ` Manasi Navare
  2017-08-22 17:36 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev3) Patchwork
                   ` (4 subsequent siblings)
  9 siblings, 1 reply; 22+ messages in thread
From: Jim Bride @ 2017-08-22 16:34 UTC (permalink / raw)
  To: intel-gfx; +Cc: Paulo Zanoni, Jani Nikula, Rodrigo Vivi

This set of changes has some history to them.  There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec.  These changes were:

commit 5fa836a9d859 ("drm/i915: DP link training optimization")
commit 4e96c97742f4 ("drm/i915: eDP link training optimization")

which were eventually hand-reverted by:

commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
                     feature")

in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915.  There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation.  The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes.  This patch, largely
based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
puts the eDP portions of this patch back in place.  None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.

v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier
      reading. (Chris)
    * Rebase
v5: * Checkpatch cleanup
    * Rebase
v6: * is_edp() => intel_dp_is_edp()
    * rebase
v7: * Remove extraneous is_edp() prototype (Rodrigo)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi D Navare <manasi.d.navare@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c               |  2 ++
 drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
 drivers/gpu/drm/i915/intel_drv.h              |  1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e385658..38bc7e0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
 		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
 
 		intel_dp->reset_link_params = false;
+		intel_dp->train_set_valid = false;
 	}
 
 	intel_dp_print_rates(intel_dp);
@@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 	intel_dp_set_source_rates(intel_dp);
 
 	intel_dp->reset_link_params = true;
+	intel_dp->train_set_valid = false;
 	intel_dp->pps_pipe = INVALID_PIPE;
 	intel_dp->active_pipe = INVALID_PIPE;
 
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..79fe369 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
 intel_dp_reset_link_train(struct intel_dp *intel_dp,
 			uint8_t dp_train_pat)
 {
-	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+	if (!intel_dp->train_set_valid)
+		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
 	intel_dp_set_signal_levels(intel_dp);
 	return intel_dp_set_link_train(intel_dp, dp_train_pat);
 }
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 				       DP_TRAINING_PATTERN_1 |
 				       DP_LINK_SCRAMBLING_DISABLE)) {
 		DRM_ERROR("failed to enable link training\n");
+		intel_dp->train_set_valid = false;
 		return false;
 	}
 
+	/*
+	 * The initial set of link parameters are set by this point, so go
+	 * ahead and set intel_dp->train_set_valid to false in case any of
+	 * the succeeding steps fail.  It will be set back to true if we were
+	 * able to achieve clock recovery in the specified configuration.
+	 */
+	intel_dp->train_set_valid = false;
+
 	voltage_tries = 1;
 	max_vswing_tries = 0;
 	for (;;) {
@@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 
 		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
 			DRM_DEBUG_KMS("clock recovery OK\n");
+			intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
 			return true;
 		}
 
@@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
 				     training_pattern |
 				     DP_LINK_SCRAMBLING_DISABLE)) {
 		DRM_ERROR("failed to start channel equalization\n");
+		intel_dp->train_set_valid = false;
 		return false;
 	}
 
@@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
 	/* Try 5 times, else fail and try at lower BW */
 	if (tries == 5) {
 		intel_dp_dump_link_status(link_status);
+		intel_dp->train_set_valid = false;
 		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
 	}
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2940d39..f4354ec 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -995,6 +995,7 @@ struct intel_dp {
 	struct drm_dp_aux aux;
 	enum intel_display_power_domain aux_power_domain;
 	uint8_t train_set[4];
+	bool train_set_valid;
 	int panel_power_up_delay;
 	int panel_power_down_delay;
 	int panel_power_cycle_delay;
-- 
2.7.4

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

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

* ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev3)
  2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
                   ` (4 preceding siblings ...)
  2017-08-22 16:34 ` [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
@ 2017-08-22 17:36 ` Patchwork
  2017-09-19 21:25 ` [PATCH v8] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-08-22 17:36 UTC (permalink / raw)
  To: Jim Bride; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/edp: Be less aggressive about changing link config on eDP (rev3)
URL   : https://patchwork.freedesktop.org/series/28588/
State : success

== Summary ==

Series 28588v3 drm/i915/edp: Be less aggressive about changing link config on eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/3/mbox/

Test gem_exec_flush:
        Subgroup basic-batch-kernel-default-uc:
                pass       -> FAIL       (fi-snb-2600) fdo#100007
Test kms_cursor_legacy:
        Subgroup basic-busy-flip-before-cursor-legacy:
                fail       -> PASS       (fi-snb-2600) fdo#100215
Test kms_flip:
        Subgroup basic-flip-vs-modeset:
                pass       -> SKIP       (fi-skl-x1585l) fdo#101781
Test drv_module_reload:
        Subgroup basic-reload-inject:
                pass       -> DMESG-WARN (fi-kbl-7260u) fdo#102295

fdo#100007 https://bugs.freedesktop.org/show_bug.cgi?id=100007
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fdo#102295 https://bugs.freedesktop.org/show_bug.cgi?id=102295

fi-bdw-5557u     total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:454s
fi-bdw-gvtdvm    total:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  time:435s
fi-blb-e6850     total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  time:363s
fi-bsw-n3050     total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  time:548s
fi-bwr-2160      total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  time:253s
fi-bxt-j4205     total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:523s
fi-byt-j1900     total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  time:522s
fi-byt-n2820     total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  time:519s
fi-elk-e7500     total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  time:437s
fi-glk-2a        total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:607s
fi-hsw-4770      total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:445s
fi-hsw-4770r     total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:420s
fi-ilk-650       total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  time:424s
fi-ivb-3520m     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:507s
fi-ivb-3770      total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:473s
fi-kbl-7260u     total:279  pass:267  dwarn:2   dfail:0   fail:0   skip:10  time:500s
fi-kbl-7500u     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:476s
fi-kbl-7560u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:587s
fi-kbl-r         total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:599s
fi-pnv-d510      total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  time:526s
fi-skl-6260u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:473s
fi-skl-6700k     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:478s
fi-skl-6770hq    total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:494s
fi-skl-gvtdvm    total:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  time:444s
fi-skl-x1585l    total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:482s
fi-snb-2520m     total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  time:544s
fi-snb-2600      total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  time:407s

017fec5c2e57672a8c2a350376070e6c6a5ae950 drm-tip: 2017y-08m-22d-16h-23m-11s UTC integration manifest
c688185ea6b2 drm/i915/edp: Be less aggressive about changing link config on eDP

== Logs ==

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

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

* Re: [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-22 16:34 ` [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
@ 2017-09-15 18:19   ` Manasi Navare
  2017-09-19 19:55     ` Rodrigo Vivi
  0 siblings, 1 reply; 22+ messages in thread
From: Manasi Navare @ 2017-09-15 18:19 UTC (permalink / raw)
  To: Jim Bride; +Cc: Paulo Zanoni, Jani Nikula, intel-gfx, Rodrigo Vivi

The patch looks good for eDP link training optimizations.

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

Manasi

On Tue, Aug 22, 2017 at 09:34:46AM -0700, Jim Bride wrote:
> This set of changes has some history to them.  There were several attempts
> to add what was called "fast link training" to i915, which actually wasn't
> fast link training as per the DP spec.  These changes were:
> 
> commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> 
> which were eventually hand-reverted by:
> 
> commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
>                      feature")
> 
> in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> very bad side-effects on PSR functionality on Skylake. The issue at
> hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> (depending on the original link configuration) in order to quickly get
> the source and sink back in synchronization across the link before handing
> control back to the i915.  There's an assumption that none of the link
> configuration information has changed (and thus it's still valid) since the
> last full link training operation.  The revert above was identified via a
> bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> puts the eDP portions of this patch back in place.  None of the flickering
> issues that spurred the revert have been seen, and I suspect the real
> culprits here were addressed by some of the recent link training changes
> that Manasi has implemented, and PSR on Skylake is definitely more happy
> with these changes in-place.
> 
> v2 and v3: Rebase
> v4: * Clean up accesses to train_set_valid a bit for easier
>       reading. (Chris)
>     * Rebase
> v5: * Checkpatch cleanup
>     * Rebase
> v6: * is_edp() => intel_dp_is_edp()
>     * rebase
> v7: * Remove extraneous is_edp() prototype (Rodrigo)
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Manasi D Navare <manasi.d.navare@intel.com>
> Cc: Mika Kahola <mika.kahola@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c               |  2 ++
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
>  drivers/gpu/drm/i915/intel_drv.h              |  1 +
>  3 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e385658..38bc7e0 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
>  		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
>  
>  		intel_dp->reset_link_params = false;
> +		intel_dp->train_set_valid = false;
>  	}
>  
>  	intel_dp_print_rates(intel_dp);
> @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
>  	intel_dp_set_source_rates(intel_dp);
>  
>  	intel_dp->reset_link_params = true;
> +	intel_dp->train_set_valid = false;
>  	intel_dp->pps_pipe = INVALID_PIPE;
>  	intel_dp->active_pipe = INVALID_PIPE;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa..79fe369 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -94,7 +94,8 @@ static bool
>  intel_dp_reset_link_train(struct intel_dp *intel_dp,
>  			uint8_t dp_train_pat)
>  {
> -	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> +	if (!intel_dp->train_set_valid)
> +		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
>  	intel_dp_set_signal_levels(intel_dp);
>  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
>  }
> @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>  				       DP_TRAINING_PATTERN_1 |
>  				       DP_LINK_SCRAMBLING_DISABLE)) {
>  		DRM_ERROR("failed to enable link training\n");
> +		intel_dp->train_set_valid = false;
>  		return false;
>  	}
>  
> +	/*
> +	 * The initial set of link parameters are set by this point, so go
> +	 * ahead and set intel_dp->train_set_valid to false in case any of
> +	 * the succeeding steps fail.  It will be set back to true if we were
> +	 * able to achieve clock recovery in the specified configuration.
> +	 */
> +	intel_dp->train_set_valid = false;
> +
>  	voltage_tries = 1;
>  	max_vswing_tries = 0;
>  	for (;;) {
> @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>  
>  		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
>  			DRM_DEBUG_KMS("clock recovery OK\n");
> +			intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
>  			return true;
>  		}
>  
> @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
>  				     training_pattern |
>  				     DP_LINK_SCRAMBLING_DISABLE)) {
>  		DRM_ERROR("failed to start channel equalization\n");
> +		intel_dp->train_set_valid = false;
>  		return false;
>  	}
>  
> @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
>  	/* Try 5 times, else fail and try at lower BW */
>  	if (tries == 5) {
>  		intel_dp_dump_link_status(link_status);
> +		intel_dp->train_set_valid = false;
>  		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
>  	}
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 2940d39..f4354ec 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -995,6 +995,7 @@ struct intel_dp {
>  	struct drm_dp_aux aux;
>  	enum intel_display_power_domain aux_power_domain;
>  	uint8_t train_set[4];
> +	bool train_set_valid;
>  	int panel_power_up_delay;
>  	int panel_power_down_delay;
>  	int panel_power_cycle_delay;
> -- 
> 2.7.4
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-09-15 18:19   ` Manasi Navare
@ 2017-09-19 19:55     ` Rodrigo Vivi
  2017-09-19 21:20       ` Jim Bride
  2017-09-27 12:23       ` Mika Kahola
  0 siblings, 2 replies; 22+ messages in thread
From: Rodrigo Vivi @ 2017-09-19 19:55 UTC (permalink / raw)
  To: Manasi Navare; +Cc: Jani Nikula, intel-gfx, Paulo Zanoni

On Fri, Sep 15, 2017 at 06:19:12PM +0000, Manasi Navare wrote:
> The patch looks good for eDP link training optimizations.
> 
> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

I haven't merged this patch yet because I'd like an Ack from Jani.

Also I'd like to hear from Mika if he believes it is safe or not.

On his revert commit he wrote:
"It has been found out that in some HW combination the DisplayPort
 fast link training feature caused screen flickering. Let's revert
 this feature for now until we can ensure that the feature works for
 all platforms."

I don't want to merge this patch to fix a feature that is disabled
by default with the risk of bringing flickerings back.

But even if we decide to go ahead and merge I believe we need to
resend the test and collect a full round of CI that now runs
all IGT tests.

Thanks,
Rodrigo.


> 
> Manasi
> 
> On Tue, Aug 22, 2017 at 09:34:46AM -0700, Jim Bride wrote:
> > This set of changes has some history to them.  There were several attempts
> > to add what was called "fast link training" to i915, which actually wasn't
> > fast link training as per the DP spec.  These changes were:
> > 
> > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > 
> > which were eventually hand-reverted by:
> > 
> > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> >                      feature")
> > 
> > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> > very bad side-effects on PSR functionality on Skylake. The issue at
> > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > (depending on the original link configuration) in order to quickly get
> > the source and sink back in synchronization across the link before handing
> > control back to the i915.  There's an assumption that none of the link
> > configuration information has changed (and thus it's still valid) since the
> > last full link training operation.  The revert above was identified via a
> > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > puts the eDP portions of this patch back in place.  None of the flickering
> > issues that spurred the revert have been seen, and I suspect the real
> > culprits here were addressed by some of the recent link training changes
> > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > with these changes in-place.
> > 
> > v2 and v3: Rebase
> > v4: * Clean up accesses to train_set_valid a bit for easier
> >       reading. (Chris)
> >     * Rebase
> > v5: * Checkpatch cleanup
> >     * Rebase
> > v6: * is_edp() => intel_dp_is_edp()
> >     * rebase
> > v7: * Remove extraneous is_edp() prototype (Rodrigo)
> > 
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > Cc: Mika Kahola <mika.kahola@intel.com>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c               |  2 ++
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> >  drivers/gpu/drm/i915/intel_drv.h              |  1 +
> >  3 files changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index e385658..38bc7e0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> >  		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> >  
> >  		intel_dp->reset_link_params = false;
> > +		intel_dp->train_set_valid = false;
> >  	}
> >  
> >  	intel_dp_print_rates(intel_dp);
> > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> >  	intel_dp_set_source_rates(intel_dp);
> >  
> >  	intel_dp->reset_link_params = true;
> > +	intel_dp->train_set_valid = false;
> >  	intel_dp->pps_pipe = INVALID_PIPE;
> >  	intel_dp->active_pipe = INVALID_PIPE;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..79fe369 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -94,7 +94,8 @@ static bool
> >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> >  			uint8_t dp_train_pat)
> >  {
> > -	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > +	if (!intel_dp->train_set_valid)
> > +		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> >  	intel_dp_set_signal_levels(intel_dp);
> >  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
> >  }
> > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >  				       DP_TRAINING_PATTERN_1 |
> >  				       DP_LINK_SCRAMBLING_DISABLE)) {
> >  		DRM_ERROR("failed to enable link training\n");
> > +		intel_dp->train_set_valid = false;
> >  		return false;
> >  	}
> >  
> > +	/*
> > +	 * The initial set of link parameters are set by this point, so go
> > +	 * ahead and set intel_dp->train_set_valid to false in case any of
> > +	 * the succeeding steps fail.  It will be set back to true if we were
> > +	 * able to achieve clock recovery in the specified configuration.
> > +	 */
> > +	intel_dp->train_set_valid = false;
> > +
> >  	voltage_tries = 1;
> >  	max_vswing_tries = 0;
> >  	for (;;) {
> > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >  
> >  		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> >  			DRM_DEBUG_KMS("clock recovery OK\n");
> > +			intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
> >  			return true;
> >  		}
> >  
> > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> >  				     training_pattern |
> >  				     DP_LINK_SCRAMBLING_DISABLE)) {
> >  		DRM_ERROR("failed to start channel equalization\n");
> > +		intel_dp->train_set_valid = false;
> >  		return false;
> >  	}
> >  
> > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> >  	/* Try 5 times, else fail and try at lower BW */
> >  	if (tries == 5) {
> >  		intel_dp_dump_link_status(link_status);
> > +		intel_dp->train_set_valid = false;
> >  		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> >  	}
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index 2940d39..f4354ec 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -995,6 +995,7 @@ struct intel_dp {
> >  	struct drm_dp_aux aux;
> >  	enum intel_display_power_domain aux_power_domain;
> >  	uint8_t train_set[4];
> > +	bool train_set_valid;
> >  	int panel_power_up_delay;
> >  	int panel_power_down_delay;
> >  	int panel_power_cycle_delay;
> > -- 
> > 2.7.4
> > 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-09-19 19:55     ` Rodrigo Vivi
@ 2017-09-19 21:20       ` Jim Bride
  2017-09-27 12:23       ` Mika Kahola
  1 sibling, 0 replies; 22+ messages in thread
From: Jim Bride @ 2017-09-19 21:20 UTC (permalink / raw)
  To: Rodrigo Vivi; +Cc: Jani Nikula, intel-gfx, Paulo Zanoni

On Tue, Sep 19, 2017 at 12:55:24PM -0700, Rodrigo Vivi wrote:
> On Fri, Sep 15, 2017 at 06:19:12PM +0000, Manasi Navare wrote:
> > The patch looks good for eDP link training optimizations.
> > 
> > Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
> 
> I haven't merged this patch yet because I'd like an Ack from Jani.
> 
> Also I'd like to hear from Mika if he believes it is safe or not.

Mika looked at it a few months ago and thought it would be ok.  It
can't hurt to have him look at it again, though.

> On his revert commit he wrote:
> "It has been found out that in some HW combination the DisplayPort
>  fast link training feature caused screen flickering. Let's revert
>  this feature for now until we can ensure that the feature works for
>  all platforms."
> 
> I don't want to merge this patch to fix a feature that is disabled
> by default with the risk of bringing flickerings back.
> 
> But even if we decide to go ahead and merge I believe we need to
> resend the test and collect a full round of CI that now runs
> all IGT tests.

I assume you mean resend the patch here.  I'll do that.

Jim

> Thanks,
> Rodrigo.
> 
> 
> > 
> > Manasi
> > 
> > On Tue, Aug 22, 2017 at 09:34:46AM -0700, Jim Bride wrote:
> > > This set of changes has some history to them.  There were several attempts
> > > to add what was called "fast link training" to i915, which actually wasn't
> > > fast link training as per the DP spec.  These changes were:
> > > 
> > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > 
> > > which were eventually hand-reverted by:
> > > 
> > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > >                      feature")
> > > 
> > > in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
> > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > (depending on the original link configuration) in order to quickly get
> > > the source and sink back in synchronization across the link before handing
> > > control back to the i915.  There's an assumption that none of the link
> > > configuration information has changed (and thus it's still valid) since the
> > > last full link training operation.  The revert above was identified via a
> > > bisect as the cause of some of Skylake's PSR woes.  This patch, largely
> > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > puts the eDP portions of this patch back in place.  None of the flickering
> > > issues that spurred the revert have been seen, and I suspect the real
> > > culprits here were addressed by some of the recent link training changes
> > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > with these changes in-place.
> > > 
> > > v2 and v3: Rebase
> > > v4: * Clean up accesses to train_set_valid a bit for easier
> > >       reading. (Chris)
> > >     * Rebase
> > > v5: * Checkpatch cleanup
> > >     * Rebase
> > > v6: * is_edp() => intel_dp_is_edp()
> > >     * rebase
> > > v7: * Remove extraneous is_edp() prototype (Rodrigo)
> > > 
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c               |  2 ++
> > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > >  drivers/gpu/drm/i915/intel_drv.h              |  1 +
> > >  3 files changed, 17 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > index e385658..38bc7e0 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > >  		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > >  
> > >  		intel_dp->reset_link_params = false;
> > > +		intel_dp->train_set_valid = false;
> > >  	}
> > >  
> > >  	intel_dp_print_rates(intel_dp);
> > > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > >  	intel_dp_set_source_rates(intel_dp);
> > >  
> > >  	intel_dp->reset_link_params = true;
> > > +	intel_dp->train_set_valid = false;
> > >  	intel_dp->pps_pipe = INVALID_PIPE;
> > >  	intel_dp->active_pipe = INVALID_PIPE;
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > index 05907fa..79fe369 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > @@ -94,7 +94,8 @@ static bool
> > >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > >  			uint8_t dp_train_pat)
> > >  {
> > > -	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > +	if (!intel_dp->train_set_valid)
> > > +		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > >  	intel_dp_set_signal_levels(intel_dp);
> > >  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > >  }
> > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > >  				       DP_TRAINING_PATTERN_1 |
> > >  				       DP_LINK_SCRAMBLING_DISABLE)) {
> > >  		DRM_ERROR("failed to enable link training\n");
> > > +		intel_dp->train_set_valid = false;
> > >  		return false;
> > >  	}
> > >  
> > > +	/*
> > > +	 * The initial set of link parameters are set by this point, so go
> > > +	 * ahead and set intel_dp->train_set_valid to false in case any of
> > > +	 * the succeeding steps fail.  It will be set back to true if we were
> > > +	 * able to achieve clock recovery in the specified configuration.
> > > +	 */
> > > +	intel_dp->train_set_valid = false;
> > > +
> > >  	voltage_tries = 1;
> > >  	max_vswing_tries = 0;
> > >  	for (;;) {
> > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > >  
> > >  		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > >  			DRM_DEBUG_KMS("clock recovery OK\n");
> > > +			intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
> > >  			return true;
> > >  		}
> > >  
> > > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > >  				     training_pattern |
> > >  				     DP_LINK_SCRAMBLING_DISABLE)) {
> > >  		DRM_ERROR("failed to start channel equalization\n");
> > > +		intel_dp->train_set_valid = false;
> > >  		return false;
> > >  	}
> > >  
> > > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > >  	/* Try 5 times, else fail and try at lower BW */
> > >  	if (tries == 5) {
> > >  		intel_dp_dump_link_status(link_status);
> > > +		intel_dp->train_set_valid = false;
> > >  		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > >  	}
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > index 2940d39..f4354ec 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -995,6 +995,7 @@ struct intel_dp {
> > >  	struct drm_dp_aux aux;
> > >  	enum intel_display_power_domain aux_power_domain;
> > >  	uint8_t train_set[4];
> > > +	bool train_set_valid;
> > >  	int panel_power_up_delay;
> > >  	int panel_power_down_delay;
> > >  	int panel_power_cycle_delay;
> > > -- 
> > > 2.7.4
> > > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* [PATCH v8] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
                   ` (5 preceding siblings ...)
  2017-08-22 17:36 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev3) Patchwork
@ 2017-09-19 21:25 ` Jim Bride
  2017-09-19 22:02 ` ✗ Fi.CI.BAT: failure for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4) Patchwork
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 22+ messages in thread
From: Jim Bride @ 2017-09-19 21:25 UTC (permalink / raw)
  To: intel-gfx; +Cc: Paulo Zanoni, Jani Nikula, Rodrigo Vivi

This set of changes has some history to them.  There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec.  These changes were:

commit 5fa836a9d859 ("drm/i915: DP link training optimization")
commit 4e96c97742f4 ("drm/i915: eDP link training optimization")

which were eventually hand-reverted by:

commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
                     feature")

in kernel 4.7-rc4.  The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915.  There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation.  The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes.  This patch, largely
based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
puts the eDP portions of this patch back in place.  None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.

v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier
      reading. (Chris)
    * Rebase
v5: * Checkpatch cleanup
    * Rebase
v6: * is_edp() => intel_dp_is_edp()
    * rebase
v7: * Remove extraneous is_edp() prototype (Rodrigo)
v8: Rebase

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi D Navare <manasi.d.navare@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c               |  2 ++
 drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
 drivers/gpu/drm/i915/intel_drv.h              |  1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8db6b11..aee7e9b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4748,6 +4748,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
 		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
 
 		intel_dp->reset_link_params = false;
+		intel_dp->train_set_valid = false;
 	}
 
 	intel_dp_print_rates(intel_dp);
@@ -6017,6 +6018,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 	intel_dp_set_source_rates(intel_dp);
 
 	intel_dp->reset_link_params = true;
+	intel_dp->train_set_valid = false;
 	intel_dp->pps_pipe = INVALID_PIPE;
 	intel_dp->active_pipe = INVALID_PIPE;
 
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..79fe369 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
 intel_dp_reset_link_train(struct intel_dp *intel_dp,
 			uint8_t dp_train_pat)
 {
-	memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+	if (!intel_dp->train_set_valid)
+		memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
 	intel_dp_set_signal_levels(intel_dp);
 	return intel_dp_set_link_train(intel_dp, dp_train_pat);
 }
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 				       DP_TRAINING_PATTERN_1 |
 				       DP_LINK_SCRAMBLING_DISABLE)) {
 		DRM_ERROR("failed to enable link training\n");
+		intel_dp->train_set_valid = false;
 		return false;
 	}
 
+	/*
+	 * The initial set of link parameters are set by this point, so go
+	 * ahead and set intel_dp->train_set_valid to false in case any of
+	 * the succeeding steps fail.  It will be set back to true if we were
+	 * able to achieve clock recovery in the specified configuration.
+	 */
+	intel_dp->train_set_valid = false;
+
 	voltage_tries = 1;
 	max_vswing_tries = 0;
 	for (;;) {
@@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 
 		if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
 			DRM_DEBUG_KMS("clock recovery OK\n");
+			intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
 			return true;
 		}
 
@@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
 				     training_pattern |
 				     DP_LINK_SCRAMBLING_DISABLE)) {
 		DRM_ERROR("failed to start channel equalization\n");
+		intel_dp->train_set_valid = false;
 		return false;
 	}
 
@@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
 	/* Try 5 times, else fail and try at lower BW */
 	if (tries == 5) {
 		intel_dp_dump_link_status(link_status);
+		intel_dp->train_set_valid = false;
 		DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
 	}
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3078076..40e98ed 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -987,6 +987,7 @@ struct intel_dp {
 	struct drm_dp_aux aux;
 	enum intel_display_power_domain aux_power_domain;
 	uint8_t train_set[4];
+	bool train_set_valid;
 	int panel_power_up_delay;
 	int panel_power_down_delay;
 	int panel_power_cycle_delay;
-- 
2.7.4

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

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

* ✗ Fi.CI.BAT: failure for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
  2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
                   ` (6 preceding siblings ...)
  2017-09-19 21:25 ` [PATCH v8] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
@ 2017-09-19 22:02 ` Patchwork
  2017-09-25 23:12 ` ✓ Fi.CI.BAT: success " Patchwork
  2017-09-26  4:12 ` ✓ Fi.CI.IGT: " Patchwork
  9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-09-19 22:02 UTC (permalink / raw)
  To: Jim Bride; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
URL   : https://patchwork.freedesktop.org/series/28588/
State : failure

== Summary ==

Series 28588v4 drm/i915/edp: Be less aggressive about changing link config on eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/4/mbox/

Test gem_exec_reloc:
        Subgroup basic-gtt-cpu-active:
                pass       -> INCOMPLETE (fi-byt-j1900)
Test kms_cursor_legacy:
        Subgroup basic-busy-flip-before-cursor-atomic:
                pass       -> FAIL       (fi-snb-2600) fdo#100215
Test kms_frontbuffer_tracking:
        Subgroup basic:
                dmesg-warn -> PASS       (fi-kbl-7500u)
Test kms_pipe_crc_basic:
        Subgroup hang-read-crc-pipe-b:
                incomplete -> DMESG-WARN (fi-cfl-s) fdo#102294
        Subgroup suspend-read-crc-pipe-a:
                incomplete -> PASS       (fi-kbl-7500u)
Test drv_module_reload:
        Subgroup basic-reload:
                pass       -> DMESG-WARN (fi-glk-1) fdo#102777

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294
fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777

fi-bdw-5557u     total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:439s
fi-bdw-gvtdvm    total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:470s
fi-blb-e6850     total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  time:415s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:514s
fi-bwr-2160      total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 time:278s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:514s
fi-byt-j1900     total:102  pass:83   dwarn:0   dfail:0   fail:0   skip:18 
fi-byt-n2820     total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  time:479s
fi-cfl-s         total:289  pass:222  dwarn:35  dfail:0   fail:0   skip:32  time:542s
fi-elk-e7500     total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  time:416s
fi-glk-1         total:289  pass:259  dwarn:1   dfail:0   fail:0   skip:29  time:564s
fi-hsw-4770      total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:426s
fi-hsw-4770r     total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:403s
fi-ilk-650       total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:427s
fi-ivb-3520m     total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:484s
fi-ivb-3770      total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:458s
fi-kbl-7500u     total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  time:472s
fi-kbl-7560u     total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  time:573s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:586s
fi-pnv-d510      total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:542s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:448s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:750s
fi-skl-6770hq    total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:487s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:476s
fi-snb-2520m     total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  time:568s
fi-snb-2600      total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  time:414s

bf6ecf6d25c1c45e576643b7d7a65e8b1e6b4f01 drm-tip: 2017y-09m-19d-17h-23m-04s UTC integration manifest
d200ddf98baa drm/i915/edp: Be less aggressive about changing link config on eDP

== Logs ==

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

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

* ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
  2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
                   ` (7 preceding siblings ...)
  2017-09-19 22:02 ` ✗ Fi.CI.BAT: failure for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4) Patchwork
@ 2017-09-25 23:12 ` Patchwork
  2017-09-26  4:12 ` ✓ Fi.CI.IGT: " Patchwork
  9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-09-25 23:12 UTC (permalink / raw)
  To: Jim Bride; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
URL   : https://patchwork.freedesktop.org/series/28588/
State : success

== Summary ==

Series 28588v4 drm/i915/edp: Be less aggressive about changing link config on eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/4/mbox/

Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-c:
                incomplete -> PASS       (fi-kbl-r)
Test pm_rpm:
        Subgroup basic-rte:
                pass       -> DMESG-WARN (fi-cfl-s) fdo#102294
Test drv_module_reload:
        Subgroup basic-reload-inject:
                dmesg-warn -> PASS       (fi-glk-1) fdo#102777

fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294
fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777

fi-bdw-5557u     total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:438s
fi-bdw-gvtdvm    total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:465s
fi-blb-e6850     total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  time:421s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:513s
fi-bwr-2160      total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 time:277s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:496s
fi-byt-j1900     total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  time:490s
fi-byt-n2820     total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  time:495s
fi-cfl-s         total:289  pass:222  dwarn:35  dfail:0   fail:0   skip:32  time:537s
fi-cnl-y         total:289  pass:257  dwarn:0   dfail:0   fail:5   skip:27  time:639s
fi-elk-e7500     total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  time:412s
fi-glk-1         total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:566s
fi-hsw-4770      total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:425s
fi-hsw-4770r     total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:402s
fi-ilk-650       total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:432s
fi-ivb-3520m     total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:487s
fi-ivb-3770      total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:458s
fi-kbl-7500u     total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  time:474s
fi-kbl-7560u     total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  time:577s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:592s
fi-pnv-d510      total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:539s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:450s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:748s
fi-skl-6770hq    total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:490s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:475s
fi-snb-2520m     total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  time:570s
fi-snb-2600      total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:421s

f4eb3c100b0bd3e63af7f2083e3d4b1e0cd4fa7d drm-tip: 2017y-09m-25d-19h-36m-33s UTC integration manifest
e930c660773d drm/i915/edp: Be less aggressive about changing link config on eDP

== Logs ==

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

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

* ✓ Fi.CI.IGT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
  2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
                   ` (8 preceding siblings ...)
  2017-09-25 23:12 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2017-09-26  4:12 ` Patchwork
  9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-09-26  4:12 UTC (permalink / raw)
  To: Jim Bride; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
URL   : https://patchwork.freedesktop.org/series/28588/
State : success

== Summary ==

Test kms_setmode:
        Subgroup basic:
                fail       -> PASS       (shard-hsw) fdo#99912
Test perf:
        Subgroup blocking:
                fail       -> PASS       (shard-hsw) fdo#102252 +1

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hsw        total:2429 pass:1325 dwarn:5   dfail:0   fail:16  skip:1083 time:9901s

== Logs ==

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

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

* Re: [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-09-19 19:55     ` Rodrigo Vivi
  2017-09-19 21:20       ` Jim Bride
@ 2017-09-27 12:23       ` Mika Kahola
  2017-09-28  0:25         ` Rodrigo Vivi
  1 sibling, 1 reply; 22+ messages in thread
From: Mika Kahola @ 2017-09-27 12:23 UTC (permalink / raw)
  To: Rodrigo Vivi, Manasi Navare; +Cc: Jani Nikula, intel-gfx, Paulo Zanoni

On Tue, 2017-09-19 at 12:55 -0700, Rodrigo Vivi wrote:
> On Fri, Sep 15, 2017 at 06:19:12PM +0000, Manasi Navare wrote:
> > 
> > The patch looks good for eDP link training optimizations.
> > 
> > Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
> I haven't merged this patch yet because I'd like an Ack from Jani.
> 
> Also I'd like to hear from Mika if he believes it is safe or not.
> 
> On his revert commit he wrote:
> "It has been found out that in some HW combination the DisplayPort
>  fast link training feature caused screen flickering. Let's revert
>  this feature for now until we can ensure that the feature works for
>  all platforms."
At the time of this revert there were quite a few bug reports of
flickering. The community felt that this "fast link training" was to
blame for flickering issues and therefore we decided to revert that.
However, it turned out later on that this revert didn't solve the
flickering issues. Flickering was gone once watermark work landed.

Therefore, I feel that this feature is safe to re-enable.

> 
> I don't want to merge this patch to fix a feature that is disabled
> by default with the risk of bringing flickerings back.
> 
> But even if we decide to go ahead and merge I believe we need to
> resend the test and collect a full round of CI that now runs
> all IGT tests.
> 
> Thanks,
> Rodrigo.
> 
> 
> > 
> > 
> > Manasi
> > 
> > On Tue, Aug 22, 2017 at 09:34:46AM -0700, Jim Bride wrote:
> > > 
> > > This set of changes has some history to them.  There were several
> > > attempts
> > > to add what was called "fast link training" to i915, which
> > > actually wasn't
> > > fast link training as per the DP spec.  These changes were:
> > > 
> > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > 
> > > which were eventually hand-reverted by:
> > > 
> > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link
> > > training
> > >                      feature")
> > > 
> > > in kernel 4.7-rc4.  The eDP pieces of the above revert, however,
> > > had some
> > > very bad side-effects on PSR functionality on Skylake. The issue
> > > at
> > > hand is that when PSR exits i915 briefly emits TP1 followed by
> > > TP2/3
> > > (depending on the original link configuration) in order to
> > > quickly get
> > > the source and sink back in synchronization across the link
> > > before handing
> > > control back to the i915.  There's an assumption that none of the
> > > link
> > > configuration information has changed (and thus it's still valid)
> > > since the
> > > last full link training operation.  The revert above was
> > > identified via a
> > > bisect as the cause of some of Skylake's PSR woes.  This patch,
> > > largely
> > > based on commit 4e96c97742f4 ("drm/i915: eDP link training
> > > optimization")
> > > puts the eDP portions of this patch back in place.  None of the
> > > flickering
> > > issues that spurred the revert have been seen, and I suspect the
> > > real
> > > culprits here were addressed by some of the recent link training
> > > changes
> > > that Manasi has implemented, and PSR on Skylake is definitely
> > > more happy
> > > with these changes in-place.
> > > 
> > > v2 and v3: Rebase
> > > v4: * Clean up accesses to train_set_valid a bit for easier
> > >       reading. (Chris)
> > >     * Rebase
> > > v5: * Checkpatch cleanup
> > >     * Rebase
> > > v6: * is_edp() => intel_dp_is_edp()
> > >     * rebase
> > > v7: * Remove extraneous is_edp() prototype (Rodrigo)
> > > 
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link
> > > training feature")
> > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c               |  2 ++
> > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15
> > > ++++++++++++++-
> > >  drivers/gpu/drm/i915/intel_drv.h              |  1 +
> > >  3 files changed, 17 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index e385658..38bc7e0 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector
> > > *intel_connector)
> > >  		intel_dp->max_link_rate =
> > > intel_dp_max_common_rate(intel_dp);
> > >  
> > >  		intel_dp->reset_link_params = false;
> > > +		intel_dp->train_set_valid = false;
> > >  	}
> > >  
> > >  	intel_dp_print_rates(intel_dp);
> > > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct
> > > intel_digital_port *intel_dig_port,
> > >  	intel_dp_set_source_rates(intel_dp);
> > >  
> > >  	intel_dp->reset_link_params = true;
> > > +	intel_dp->train_set_valid = false;
> > >  	intel_dp->pps_pipe = INVALID_PIPE;
> > >  	intel_dp->active_pipe = INVALID_PIPE;
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > index 05907fa..79fe369 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > @@ -94,7 +94,8 @@ static bool
> > >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > >  			uint8_t dp_train_pat)
> > >  {
> > > -	memset(intel_dp->train_set, 0, sizeof(intel_dp-
> > > >train_set));
> > > +	if (!intel_dp->train_set_valid)
> > > +		memset(intel_dp->train_set, 0, sizeof(intel_dp-
> > > >train_set));
> > >  	intel_dp_set_signal_levels(intel_dp);
> > >  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > >  }
> > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct
> > > intel_dp *intel_dp)
> > >  				       DP_TRAINING_PATTERN_1 |
> > >  				       DP_LINK_SCRAMBLING_DISABL
> > > E)) {
> > >  		DRM_ERROR("failed to enable link training\n");
> > > +		intel_dp->train_set_valid = false;
> > >  		return false;
> > >  	}
> > >  
> > > +	/*
> > > +	 * The initial set of link parameters are set by this
> > > point, so go
> > > +	 * ahead and set intel_dp->train_set_valid to false in
> > > case any of
> > > +	 * the succeeding steps fail.  It will be set back to
> > > true if we were
> > > +	 * able to achieve clock recovery in the specified
> > > configuration.
> > > +	 */
> > > +	intel_dp->train_set_valid = false;
> > > +
> > >  	voltage_tries = 1;
> > >  	max_vswing_tries = 0;
> > >  	for (;;) {
> > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct
> > > intel_dp *intel_dp)
> > >  
> > >  		if (drm_dp_clock_recovery_ok(link_status,
> > > intel_dp->lane_count)) {
> > >  			DRM_DEBUG_KMS("clock recovery OK\n");
> > > +			intel_dp->train_set_valid =
> > > intel_dp_is_edp(intel_dp);
> > >  			return true;
> > >  		}
> > >  
> > > @@ -256,6 +267,7 @@
> > > intel_dp_link_training_channel_equalization(struct intel_dp
> > > *intel_dp)
> > >  				     training_pattern |
> > >  				     DP_LINK_SCRAMBLING_DISABLE)
> > > ) {
> > >  		DRM_ERROR("failed to start channel
> > > equalization\n");
> > > +		intel_dp->train_set_valid = false;
> > >  		return false;
> > >  	}
> > >  
> > > @@ -296,6 +308,7 @@
> > > intel_dp_link_training_channel_equalization(struct intel_dp
> > > *intel_dp)
> > >  	/* Try 5 times, else fail and try at lower BW */
> > >  	if (tries == 5) {
> > >  		intel_dp_dump_link_status(link_status);
> > > +		intel_dp->train_set_valid = false;
> > >  		DRM_DEBUG_KMS("Channel equalization failed 5
> > > times\n");
> > >  	}
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 2940d39..f4354ec 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -995,6 +995,7 @@ struct intel_dp {
> > >  	struct drm_dp_aux aux;
> > >  	enum intel_display_power_domain aux_power_domain;
> > >  	uint8_t train_set[4];
> > > +	bool train_set_valid;
> > >  	int panel_power_up_delay;
> > >  	int panel_power_down_delay;
> > >  	int panel_power_cycle_delay;
-- 
Mika Kahola - Intel OTC

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

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

* Re: [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
  2017-09-27 12:23       ` Mika Kahola
@ 2017-09-28  0:25         ` Rodrigo Vivi
  0 siblings, 0 replies; 22+ messages in thread
From: Rodrigo Vivi @ 2017-09-28  0:25 UTC (permalink / raw)
  To: Mika Kahola; +Cc: Jani Nikula, intel-gfx, Paulo Zanoni

On Wed, Sep 27, 2017 at 12:23:32PM +0000, Mika Kahola wrote:
> On Tue, 2017-09-19 at 12:55 -0700, Rodrigo Vivi wrote:
> > On Fri, Sep 15, 2017 at 06:19:12PM +0000, Manasi Navare wrote:
> > > 
> > > The patch looks good for eDP link training optimizations.
> > > 
> > > Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
> > I haven't merged this patch yet because I'd like an Ack from Jani.
> > 
> > Also I'd like to hear from Mika if he believes it is safe or not.
> > 
> > On his revert commit he wrote:
> > "It has been found out that in some HW combination the DisplayPort
> >  fast link training feature caused screen flickering. Let's revert
> >  this feature for now until we can ensure that the feature works for
> >  all platforms."
> At the time of this revert there were quite a few bug reports of
> flickering. The community felt that this "fast link training" was to
> blame for flickering issues and therefore we decided to revert that.
> However, it turned out later on that this revert didn't solve the
> flickering issues. Flickering was gone once watermark work landed.

I know this feeling... like PSR blamed for VGA flickers hehe

> 
> Therefore, I feel that this feature is safe to re-enable.

Jani, Ack?

> 
> > 
> > I don't want to merge this patch to fix a feature that is disabled
> > by default with the risk of bringing flickerings back.
> > 
> > But even if we decide to go ahead and merge I believe we need to
> > resend the test and collect a full round of CI that now runs
> > all IGT tests.
> > 
> > Thanks,
> > Rodrigo.
> > 
> > 
> > > 
> > > 
> > > Manasi
> > > 
> > > On Tue, Aug 22, 2017 at 09:34:46AM -0700, Jim Bride wrote:
> > > > 
> > > > This set of changes has some history to them.  There were several
> > > > attempts
> > > > to add what was called "fast link training" to i915, which
> > > > actually wasn't
> > > > fast link training as per the DP spec.  These changes were:
> > > > 
> > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > > 
> > > > which were eventually hand-reverted by:
> > > > 
> > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link
> > > > training
> > > >                      feature")
> > > > 
> > > > in kernel 4.7-rc4.  The eDP pieces of the above revert, however,
> > > > had some
> > > > very bad side-effects on PSR functionality on Skylake. The issue
> > > > at
> > > > hand is that when PSR exits i915 briefly emits TP1 followed by
> > > > TP2/3
> > > > (depending on the original link configuration) in order to
> > > > quickly get
> > > > the source and sink back in synchronization across the link
> > > > before handing
> > > > control back to the i915.  There's an assumption that none of the
> > > > link
> > > > configuration information has changed (and thus it's still valid)
> > > > since the
> > > > last full link training operation.  The revert above was
> > > > identified via a
> > > > bisect as the cause of some of Skylake's PSR woes.  This patch,
> > > > largely
> > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training
> > > > optimization")
> > > > puts the eDP portions of this patch back in place.  None of the
> > > > flickering
> > > > issues that spurred the revert have been seen, and I suspect the
> > > > real
> > > > culprits here were addressed by some of the recent link training
> > > > changes
> > > > that Manasi has implemented, and PSR on Skylake is definitely
> > > > more happy
> > > > with these changes in-place.
> > > > 
> > > > v2 and v3: Rebase
> > > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > >       reading. (Chris)
> > > >     * Rebase
> > > > v5: * Checkpatch cleanup
> > > >     * Rebase
> > > > v6: * is_edp() => intel_dp_is_edp()
> > > >     * rebase
> > > > v7: * Remove extraneous is_edp() prototype (Rodrigo)
> > > > 
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link
> > > > training feature")
> > > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c               |  2 ++
> > > >  drivers/gpu/drm/i915/intel_dp_link_training.c | 15
> > > > ++++++++++++++-
> > > >  drivers/gpu/drm/i915/intel_drv.h              |  1 +
> > > >  3 files changed, 17 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index e385658..38bc7e0 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector
> > > > *intel_connector)
> > > >  		intel_dp->max_link_rate =
> > > > intel_dp_max_common_rate(intel_dp);
> > > >  
> > > >  		intel_dp->reset_link_params = false;
> > > > +		intel_dp->train_set_valid = false;
> > > >  	}
> > > >  
> > > >  	intel_dp_print_rates(intel_dp);
> > > > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct
> > > > intel_digital_port *intel_dig_port,
> > > >  	intel_dp_set_source_rates(intel_dp);
> > > >  
> > > >  	intel_dp->reset_link_params = true;
> > > > +	intel_dp->train_set_valid = false;
> > > >  	intel_dp->pps_pipe = INVALID_PIPE;
> > > >  	intel_dp->active_pipe = INVALID_PIPE;
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > index 05907fa..79fe369 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > @@ -94,7 +94,8 @@ static bool
> > > >  intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > > >  			uint8_t dp_train_pat)
> > > >  {
> > > > -	memset(intel_dp->train_set, 0, sizeof(intel_dp-
> > > > >train_set));
> > > > +	if (!intel_dp->train_set_valid)
> > > > +		memset(intel_dp->train_set, 0, sizeof(intel_dp-
> > > > >train_set));
> > > >  	intel_dp_set_signal_levels(intel_dp);
> > > >  	return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > > >  }
> > > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct
> > > > intel_dp *intel_dp)
> > > >  				       DP_TRAINING_PATTERN_1 |
> > > >  				       DP_LINK_SCRAMBLING_DISABL
> > > > E)) {
> > > >  		DRM_ERROR("failed to enable link training\n");
> > > > +		intel_dp->train_set_valid = false;
> > > >  		return false;
> > > >  	}
> > > >  
> > > > +	/*
> > > > +	 * The initial set of link parameters are set by this
> > > > point, so go
> > > > +	 * ahead and set intel_dp->train_set_valid to false in
> > > > case any of
> > > > +	 * the succeeding steps fail.  It will be set back to
> > > > true if we were
> > > > +	 * able to achieve clock recovery in the specified
> > > > configuration.
> > > > +	 */
> > > > +	intel_dp->train_set_valid = false;
> > > > +
> > > >  	voltage_tries = 1;
> > > >  	max_vswing_tries = 0;
> > > >  	for (;;) {
> > > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct
> > > > intel_dp *intel_dp)
> > > >  
> > > >  		if (drm_dp_clock_recovery_ok(link_status,
> > > > intel_dp->lane_count)) {
> > > >  			DRM_DEBUG_KMS("clock recovery OK\n");
> > > > +			intel_dp->train_set_valid =
> > > > intel_dp_is_edp(intel_dp);
> > > >  			return true;
> > > >  		}
> > > >  
> > > > @@ -256,6 +267,7 @@
> > > > intel_dp_link_training_channel_equalization(struct intel_dp
> > > > *intel_dp)
> > > >  				     training_pattern |
> > > >  				     DP_LINK_SCRAMBLING_DISABLE)
> > > > ) {
> > > >  		DRM_ERROR("failed to start channel
> > > > equalization\n");
> > > > +		intel_dp->train_set_valid = false;
> > > >  		return false;
> > > >  	}
> > > >  
> > > > @@ -296,6 +308,7 @@
> > > > intel_dp_link_training_channel_equalization(struct intel_dp
> > > > *intel_dp)
> > > >  	/* Try 5 times, else fail and try at lower BW */
> > > >  	if (tries == 5) {
> > > >  		intel_dp_dump_link_status(link_status);
> > > > +		intel_dp->train_set_valid = false;
> > > >  		DRM_DEBUG_KMS("Channel equalization failed 5
> > > > times\n");
> > > >  	}
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index 2940d39..f4354ec 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -995,6 +995,7 @@ struct intel_dp {
> > > >  	struct drm_dp_aux aux;
> > > >  	enum intel_display_power_domain aux_power_domain;
> > > >  	uint8_t train_set[4];
> > > > +	bool train_set_valid;
> > > >  	int panel_power_up_delay;
> > > >  	int panel_power_down_delay;
> > > >  	int panel_power_cycle_delay;
> -- 
> Mika Kahola - Intel OTC
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

end of thread, other threads:[~2017-09-28  0:25 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
2017-08-09 21:40 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-08-16 22:13 ` [PATCH v5] " Manasi Navare
2017-08-17 17:50   ` Jim Bride
2017-08-17 19:20     ` Manasi Navare
2017-08-17 19:52       ` Manasi Navare
2017-08-17 19:54       ` Jim Bride
2017-08-21 21:03 ` [PATCH v6] " Jim Bride
2017-08-21 23:27   ` Vivi, Rodrigo
2017-08-22 16:32     ` Jim Bride
2017-08-21 21:24 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev2) Patchwork
2017-08-22 16:34 ` [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
2017-09-15 18:19   ` Manasi Navare
2017-09-19 19:55     ` Rodrigo Vivi
2017-09-19 21:20       ` Jim Bride
2017-09-27 12:23       ` Mika Kahola
2017-09-28  0:25         ` Rodrigo Vivi
2017-08-22 17:36 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev3) Patchwork
2017-09-19 21:25 ` [PATCH v8] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
2017-09-19 22:02 ` ✗ Fi.CI.BAT: failure for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4) Patchwork
2017-09-25 23:12 ` ✓ Fi.CI.BAT: success " Patchwork
2017-09-26  4:12 ` ✓ Fi.CI.IGT: " Patchwork

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).