Skip to contentSkip to conversation

drm/i915/edp: Be less aggressive about changing link config on eDP

PATCH Superseded Jim Bride 5 participants 22 messages Aug 9, 2017 – Sep 28, 2017

Subsystems (2)
lore
Share & tools
lore

Jim Bride

author
#0 lore raw

PATCH v5 1/1 drm/i915/edp: Be less aggressive about changing link config on eDP

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +3 -1
index 76c8a0b..4bd409c 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +14 -1
index 05907fa..67032cf 100644
@@ -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");
 	}
 
drivers/gpu/drm/i915/intel_drv.h +2 -0
index f91de9c..792bf547 100644
@@ -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,
Signature · 6 lines
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
#1 lore raw

✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP

== Series Details ==

== 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#2 lore raw
In reply to Jim Bride
Quoted 128 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +3 -1
index 76c8a0b..4bd409c 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +13 -1
index 05907fa..67032cf 100644
@@ -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;
 	}
 

drivers/gpu/drm/i915/intel_dp_link_training.c intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp) · line 313

Quoted 6 lines
drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
@@ -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

Quoted 24 lines
drivers/gpu/drm/i915/intel_drv.h +2 -0
index f91de9c..792bf547 100644
@@ -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,
Signature · 1 line
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#3 lore raw
Quoted 128 lines · Manasi Navare
Quoted 127 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +3 -1
index 76c8a0b..4bd409c 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +13 -1
index 05907fa..67032cf 100644
@@ -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;
 	}
 
Quoted 15 lines

drivers/gpu/drm/i915/intel_dp_link_training.c intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp) · line 313

Quoted 7 lines
drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
@@ -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

Quoted 19 lines

Regards
Manasi

Quoted 16 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
index f91de9c..792bf547 100644
@@ -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)
 }
 
Quoted 8 lines
Quoted 8 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
 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,
Signature · 1 line
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#4 lore raw
Quoted 145 lines · Jim Bride
Quoted 128 lines · Manasi Navare
Quoted 127 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +3 -1
index 76c8a0b..4bd409c 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +13 -1
index 05907fa..67032cf 100644
@@ -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;
 	}
 
Quoted 15 lines

drivers/gpu/drm/i915/intel_dp_link_training.c intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp) · line 313

Quoted 7 lines
drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
@@ -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?

Quoted 7 lines

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

Quoted 19 lines
Quoted 19 lines

Regards
Manasi

Quoted 16 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
index f91de9c..792bf547 100644
@@ -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)
 }
 
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
 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,
Signature · 1 line
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#5 lore raw
Quoted 52 lines · Manasi Navare
Quoted 51 lines · Jim Bride
Quoted 50 lines · Manasi Navare
Quoted 49 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines

drivers/gpu/drm/i915/intel_dp.c static const int default_rates[] = { 162000, 270000, 540000 }; · line 109

Quoted 10 lines
drivers/gpu/drm/i915/intel_dp.c +1 -1
index 76c8a0b..4bd409c 100644
@@ -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

Quoted 121 lines
Quoted 84 lines
Quoted 68 lines
Quoted 68 lines
drivers/gpu/drm/i915/intel_dp.c +2 -0
 {
 	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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +13 -1
index 05907fa..67032cf 100644
@@ -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;
 	}
 
Quoted 15 lines

drivers/gpu/drm/i915/intel_dp_link_training.c intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp) · line 313

Quoted 7 lines
drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
@@ -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?

Quoted 7 lines

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

Quoted 19 lines
Quoted 19 lines

Regards
Manasi

Quoted 16 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
index f91de9c..792bf547 100644
@@ -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)
 }
 
Quoted 12 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
 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,
Signature · 1 line
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#6 lore raw
In reply to Manasi Navare
Quoted 154 lines · Manasi Navare
Quoted 145 lines · Jim Bride
Quoted 128 lines · Manasi Navare
Quoted 127 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +3 -1
index 76c8a0b..4bd409c 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +13 -1
index 05907fa..67032cf 100644
@@ -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;
 	}
 
Quoted 15 lines

drivers/gpu/drm/i915/intel_dp_link_training.c intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp) · line 313

Quoted 7 lines
drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
@@ -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?

Quoted 7 lines

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

Quoted 7 lines

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

Quoted 21 lines

Manasi

Quoted 19 lines
Quoted 19 lines

Regards
Manasi

Quoted 16 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
index f91de9c..792bf547 100644
@@ -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)
 }
 
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
 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,
Signature · 1 line
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#7 lore raw

PATCH v6 1/1 drm/i915/edp: Be less aggressive about changing link config on eDP

In reply to Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +2 -0
index e385658..38bc7e0 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +14 -1
index 05907fa..79fe369 100644
@@ -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");
 	}
 
drivers/gpu/drm/i915/intel_drv.h +2 -0
index 2940d39..891c892 100644
@@ -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,
Signature · 6 lines
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
maintainer
#8 lore raw
Quoted 105 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +2 -0
index e385658..38bc7e0 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +11 -1
index 05907fa..79fe369 100644
@@ -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 (;;) {

drivers/gpu/drm/i915/intel_dp_link_training.c intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp) · line 192

Quoted 4 lines
drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
@@ -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...

Quoted 32 lines
drivers/gpu/drm/i915/intel_dp_link_training.c +2 -0
 			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");
 	}
 
drivers/gpu/drm/i915/intel_drv.h +1 -0
index 2940d39..891c892 100644
@@ -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;

drivers/gpu/drm/i915/intel_drv.h static inline unsigned int intel_dp_unused_lane_mask(int lane_count) · line 1553

Quoted 4 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
@@ -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...

drivers/gpu/drm/i915/intel_drv.h static inline unsigned int intel_dp_unused_lane_mask(int lane_count) · line 1556

Quoted 3 lines
drivers/gpu/drm/i915/intel_drv.h +0 -0
 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#9 lore raw
Quoted 107 lines · Rodrigo
Quoted 106 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +2 -0
index e385658..38bc7e0 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +11 -1
index 05907fa..79fe369 100644
@@ -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)
 
Quoted 5 lines

drivers/gpu/drm/i915/intel_dp_link_training.c intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp) · line 192

Quoted 3 lines
drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
 		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.

Quoted 2 lines

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.

Quoted 34 lines
Quoted 34 lines
drivers/gpu/drm/i915/intel_dp_link_training.c +2 -0
 			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");
 	}
 
drivers/gpu/drm/i915/intel_drv.h +1 -0
index 2940d39..891c892 100644
@@ -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)
 }
 
Quoted 2 lines

drivers/gpu/drm/i915/intel_drv.h static inline unsigned int intel_dp_unused_lane_mask(int lane_count) · line 1553

Quoted 2 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
 bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool is_edp(struct intel_dp *intel_dp);

Whoops. I'll fix this.

Quoted 6 lines

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

Quoted 3 lines
drivers/gpu/drm/i915/intel_drv.h +0 -0
 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#10 lore raw

✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev2)

In reply to Jim Bride
== Series Details ==

== 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#11 lore raw

PATCH v7 1/1 drm/i915/edp: Be less aggressive about changing link config on eDP

In reply to Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +2 -0
index e385658..38bc7e0 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +14 -1
index 05907fa..79fe369 100644
@@ -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");
 	}
 
drivers/gpu/drm/i915/intel_drv.h +1 -0
index 2940d39..f4354ec 100644
@@ -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;
Signature · 6 lines
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by on v7 1/1
#12 lore raw

The patch looks good for eDP link training optimizations.

Manasi

Quoted 144 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +2 -0
index e385658..38bc7e0 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +14 -1
index 05907fa..79fe369 100644
@@ -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");
 	}
 
drivers/gpu/drm/i915/intel_drv.h +1 -0
index 2940d39..f4354ec 100644
@@ -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;
Signature · 1 line
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

maintainer
#13 lore raw
Quoted 3 lines · Manasi Navare

The patch looks good for eDP link training optimizations.

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.

Quoted 144 lines

Manasi

Quoted 140 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +2 -0
index e385658..38bc7e0 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +14 -1
index 05907fa..79fe369 100644
@@ -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");
 	}
 
drivers/gpu/drm/i915/intel_drv.h +1 -0
index 2940d39..f4354ec 100644
@@ -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;
Quoted 8 lines
Quoted 4 lines
drivers/gpu/drm/i915/intel_drv.h +0 -0
 	int panel_power_cycle_delay;
Signature · 1 line
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#14 lore raw
Quoted 8 lines · Rodrigo Vivi
Quoted 3 lines · Manasi Navare

The patch looks good for eDP link training optimizations.

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.

Quoted 6 lines · 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."

Quoted 6 lines

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

Quoted 156 lines

Thanks,
Rodrigo.

Quoted 152 lines

Manasi

Quoted 144 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +2 -0
index e385658..38bc7e0 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +14 -1
index 05907fa..79fe369 100644
@@ -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");
 	}
 
drivers/gpu/drm/i915/intel_drv.h +1 -0
index 2940d39..f4354ec 100644
@@ -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;
Signature · 1 line
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#15 lore raw
In reply to Rodrigo Vivi
Quoted 7 lines · Rodrigo Vivi
Quoted 4 lines · Manasi Navare

The patch looks good for eDP link training optimizations.

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

Quoted 7 lines

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.

Quoted 202 lines

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.

Quoted 190 lines

Manasi

Quoted 185 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link

training feature")

---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +0 -0
index e385658..38bc7e0 100644
@@ -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;

drivers/gpu/drm/i915/intel_dp.c +1 -0
+		intel_dp->train_set_valid = false;

  }

  intel_dp_print_rates(intel_dp);

drivers/gpu/drm/i915/intel_dp.c +0 -0
@@ -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;

drivers/gpu/drm/i915/intel_dp.c +1 -0
+	intel_dp->train_set_valid = false;

  intel_dp->pps_pipe = INVALID_PIPE;
  intel_dp->active_pipe = INVALID_PIPE;

drivers/gpu/drm/i915/intel_dp_link_training.c +2 -1
index 05907fa..79fe369 100644
@@ -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); }

drivers/gpu/drm/i915/intel_dp_link_training.c +0 -0
@@ -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");

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+		intel_dp->train_set_valid = false;

  return false;
  }

drivers/gpu/drm/i915/intel_dp_link_training.c +2 -0
+	/*
+	 * The initial set of link parameters are set by this

point, so go

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+	 * ahead and set intel_dp->train_set_valid to false in

case any of

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+	 * the succeeding steps fail.  It will be set back to

true if we were

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+	 * able to achieve clock recovery in the specified

configuration.

drivers/gpu/drm/i915/intel_dp_link_training.c +3 -0
+	 */
+	intel_dp->train_set_valid = false;
+

  voltage_tries = 1;
  max_vswing_tries = 0;
  for (;;) {

drivers/gpu/drm/i915/intel_dp_link_training.c +0 -0
@@ -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");

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+			intel_dp->train_set_valid =

intel_dp_is_edp(intel_dp);
  return true;
  }

drivers/gpu/drm/i915/intel_dp_link_training.c +0 -0
@@ -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");

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+		intel_dp->train_set_valid = false;

  return false;
  }

drivers/gpu/drm/i915/intel_dp_link_training.c +0 -0
@@ -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);

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+		intel_dp->train_set_valid = false;

  DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
  }

drivers/gpu/drm/i915/intel_drv.h +1 -0
index 2940d39..f4354ec 100644
@@ -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;
Signature · 6 lines
Mika Kahola - Intel OTC

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
maintainer
#16 lore raw
Quoted 15 lines · Mika Kahola
Quoted 7 lines · Rodrigo Vivi
Quoted 4 lines · Manasi Navare

The patch looks good for eDP link training optimizations.

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

Quoted 7 lines

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."

Quoted 5 lines

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

Quoted 2 lines

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

Jani, Ack?

Quoted 195 lines
Quoted 195 lines

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.

Quoted 182 lines

Manasi

Quoted 177 lines · Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link

training feature")

---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +0 -0
index e385658..38bc7e0 100644
@@ -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;

drivers/gpu/drm/i915/intel_dp.c +1 -0
+		intel_dp->train_set_valid = false;

  }

  intel_dp_print_rates(intel_dp);

drivers/gpu/drm/i915/intel_dp.c +0 -0
@@ -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;

drivers/gpu/drm/i915/intel_dp.c +1 -0
+	intel_dp->train_set_valid = false;

  intel_dp->pps_pipe = INVALID_PIPE;
  intel_dp->active_pipe = INVALID_PIPE;

drivers/gpu/drm/i915/intel_dp_link_training.c +2 -1
index 05907fa..79fe369 100644
@@ -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); }

drivers/gpu/drm/i915/intel_dp_link_training.c +0 -0
@@ -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");

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+		intel_dp->train_set_valid = false;

  return false;
  }

drivers/gpu/drm/i915/intel_dp_link_training.c +2 -0
+	/*
+	 * The initial set of link parameters are set by this

point, so go

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+	 * ahead and set intel_dp->train_set_valid to false in

case any of

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+	 * the succeeding steps fail.  It will be set back to

true if we were

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+	 * able to achieve clock recovery in the specified

configuration.

drivers/gpu/drm/i915/intel_dp_link_training.c +3 -0
+	 */
+	intel_dp->train_set_valid = false;
+

  voltage_tries = 1;
  max_vswing_tries = 0;
  for (;;) {

drivers/gpu/drm/i915/intel_dp_link_training.c +0 -0
@@ -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");

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+			intel_dp->train_set_valid =

intel_dp_is_edp(intel_dp);
  return true;
  }

drivers/gpu/drm/i915/intel_dp_link_training.c +0 -0
@@ -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");

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+		intel_dp->train_set_valid = false;

  return false;
  }

drivers/gpu/drm/i915/intel_dp_link_training.c +0 -0
@@ -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);

drivers/gpu/drm/i915/intel_dp_link_training.c +1 -0
+		intel_dp->train_set_valid = false;

  DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
  }

drivers/gpu/drm/i915/intel_drv.h +0 -0
index 2940d39..f4354ec 100644
Quoted 11 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
drivers/gpu/drm/i915/intel_drv.h +1 -0
@@ -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;
Signature · 1 line
Mika Kahola - Intel OTC

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#17 lore raw

✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev3)

In reply to Jim Bride
== Series Details ==

== 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#18 lore raw

PATCH v8 1/1 drm/i915/edp: Be less aggressive about changing link config on eDP

In reply to Jim Bride

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 <[email protected]>
Cc Rodrigo Vivi <[email protected]>
Cc Paulo Zanoni <[email protected]>
Cc Manasi D Navare <[email protected]>
Cc Mika Kahola <[email protected]>
Cc Jani Nikula <[email protected]>
Fixes 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
---
 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(-)
drivers/gpu/drm/i915/intel_dp.c +2 -0
index 8db6b11..aee7e9b 100644
@@ -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;
 
drivers/gpu/drm/i915/intel_dp_link_training.c +14 -1
index 05907fa..79fe369 100644
@@ -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");
 	}
 
drivers/gpu/drm/i915/intel_drv.h +1 -0
index 3078076..40e98ed 100644
@@ -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;
Signature · 6 lines
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
#19 lore raw

✗ Fi.CI.BAT: failure for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)

In reply to Jim Bride
== Series Details ==

== 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#20 lore raw

✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)

In reply to Jim Bride
== Series Details ==

== 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#21 lore raw

✓ Fi.CI.IGT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)

In reply to Jim Bride
== Series Details ==

== 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx