* [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
@ 2017-08-09 21:21 Jim Bride
2017-08-09 21:40 ` ✓ Fi.CI.BAT: success for " Patchwork
` (9 more replies)
0 siblings, 10 replies; 22+ messages in thread
From: Jim Bride @ 2017-08-09 21:21 UTC (permalink / raw)
To: intel-gfx; +Cc: Paulo Zanoni, Jani Nikula, Rodrigo Vivi
This set of changes has some history to them. There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec. These changes were:
commit 5fa836a9d859 ("drm/i915: DP link training optimization")
commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
which were eventually hand-reverted by:
commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
feature")
in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915. There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation. The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes. This patch, largely
based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
puts the eDP portions of this patch back in place. None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.
v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier
reading. (Chris)
* Rebase
v5: * Checkpatch cleanup
* Rebase
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi D Navare <manasi.d.navare@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 4 +++-
drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 76c8a0b..4bd409c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
* If a CPU or PCH DP output is attached to an eDP panel, this function
* will return true, and false otherwise.
*/
-static bool is_edp(struct intel_dp *intel_dp)
+bool is_edp(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
intel_dp->reset_link_params = false;
+ intel_dp->train_set_valid = false;
}
intel_dp_print_rates(intel_dp);
@@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
intel_dp_set_source_rates(intel_dp);
intel_dp->reset_link_params = true;
+ intel_dp->train_set_valid = false;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..67032cf 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
{
- memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+ if (!intel_dp->train_set_valid)
+ memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
return intel_dp_set_link_train(intel_dp, dp_train_pat);
}
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
+ intel_dp->train_set_valid = false;
return false;
}
+ /*
+ * The initial set of link parameters are set by this point, so go
+ * ahead and set intel_dp->train_set_valid to false in case any of
+ * the succeeding steps fail. It will be set back to true if we were
+ * able to achieve clock recovery in the specified configuration.
+ */
+ intel_dp->train_set_valid = false;
+
voltage_tries = 1;
max_vswing_tries = 0;
for (;;) {
@@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("clock recovery OK\n");
+ intel_dp->train_set_valid = is_edp(intel_dp);
return true;
}
@@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
training_pattern |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to start channel equalization\n");
+ intel_dp->train_set_valid = false;
return false;
}
@@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
/* Try 5 times, else fail and try at lower BW */
if (tries == 5) {
intel_dp_dump_link_status(link_status);
+ intel_dp->train_set_valid = false;
DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f91de9c..792bf547 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -994,6 +994,7 @@ struct intel_dp {
struct drm_dp_aux aux;
enum intel_display_power_domain aux_power_domain;
uint8_t train_set[4];
+ bool train_set_valid;
int panel_power_up_delay;
int panel_power_down_delay;
int panel_power_cycle_delay;
@@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
}
bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool is_edp(struct intel_dp *intel_dp);
int intel_dp_link_required(int pixel_clock, int bpp);
int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 22+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
@ 2017-08-09 21:40 ` Patchwork
2017-08-16 22:13 ` [PATCH v5] " Manasi Navare
` (8 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-08-09 21:40 UTC (permalink / raw)
To: Jim Bride; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/edp: Be less aggressive about changing link config on eDP
URL : https://patchwork.freedesktop.org/series/28588/
State : success
== Summary ==
Series 28588v1 drm/i915/edp: Be less aggressive about changing link config on eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/1/mbox/
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail -> PASS (fi-snb-2600) fdo#100007
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass -> SKIP (fi-skl-x1585l) fdo#101781
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS (fi-byt-n2820) fdo#101705
fdo#100007 https://bugs.freedesktop.org/show_bug.cgi?id=100007
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705
fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:439s
fi-bdw-gvtdvm total:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:418s
fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:365s
fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:495s
fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:492s
fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:513s
fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:514s
fi-glk-2a total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:586s
fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:429s
fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:404s
fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:419s
fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:504s
fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s
fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:460s
fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:572s
fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:581s
fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:524s
fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:446s
fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:642s
fi-skl-6770hq total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:465s
fi-skl-gvtdvm total:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:424s
fi-skl-x1585l total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:467s
fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:553s
fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:403s
2d0288b5b28c0d67460f0258a41bb4f78b812f29 drm-tip: 2017y-08m-09d-18h-09m-54s UTC integration manifest
7aeadd39ed6c drm/i915/edp: Be less aggressive about changing link config on eDP
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5360/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
2017-08-09 21:40 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2017-08-16 22:13 ` Manasi Navare
2017-08-17 17:50 ` Jim Bride
2017-08-21 21:03 ` [PATCH v6] " Jim Bride
` (7 subsequent siblings)
9 siblings, 1 reply; 22+ messages in thread
From: Manasi Navare @ 2017-08-16 22:13 UTC (permalink / raw)
To: Jim Bride; +Cc: Paulo Zanoni, Jani Nikula, intel-gfx, Rodrigo Vivi
On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> This set of changes has some history to them. There were several attempts
> to add what was called "fast link training" to i915, which actually wasn't
> fast link training as per the DP spec. These changes were:
>
> commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
>
> which were eventually hand-reverted by:
>
> commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> feature")
>
> in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
> very bad side-effects on PSR functionality on Skylake. The issue at
> hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> (depending on the original link configuration) in order to quickly get
> the source and sink back in synchronization across the link before handing
> control back to the i915. There's an assumption that none of the link
> configuration information has changed (and thus it's still valid) since the
> last full link training operation. The revert above was identified via a
> bisect as the cause of some of Skylake's PSR woes. This patch, largely
> based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> puts the eDP portions of this patch back in place. None of the flickering
> issues that spurred the revert have been seen, and I suspect the real
> culprits here were addressed by some of the recent link training changes
> that Manasi has implemented, and PSR on Skylake is definitely more happy
> with these changes in-place.
>
> v2 and v3: Rebase
> v4: * Clean up accesses to train_set_valid a bit for easier
> reading. (Chris)
> * Rebase
> v5: * Checkpatch cleanup
> * Rebase
>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Manasi D Navare <manasi.d.navare@intel.com>
> Cc: Mika Kahola <mika.kahola@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> 3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 76c8a0b..4bd409c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
> * If a CPU or PCH DP output is attached to an eDP panel, this function
> * will return true, and false otherwise.
> */
> -static bool is_edp(struct intel_dp *intel_dp)
> +bool is_edp(struct intel_dp *intel_dp)
> {
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>
> @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
>
> intel_dp->reset_link_params = false;
> + intel_dp->train_set_valid = false;
> }
>
> intel_dp_print_rates(intel_dp);
> @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> intel_dp_set_source_rates(intel_dp);
>
> intel_dp->reset_link_params = true;
> + intel_dp->train_set_valid = false;
> intel_dp->pps_pipe = INVALID_PIPE;
> intel_dp->active_pipe = INVALID_PIPE;
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa..67032cf 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -94,7 +94,8 @@ static bool
> intel_dp_reset_link_train(struct intel_dp *intel_dp,
> uint8_t dp_train_pat)
> {
> - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> + if (!intel_dp->train_set_valid)
> + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> intel_dp_set_signal_levels(intel_dp);
> return intel_dp_set_link_train(intel_dp, dp_train_pat);
> }
> @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> DP_TRAINING_PATTERN_1 |
> DP_LINK_SCRAMBLING_DISABLE)) {
> DRM_ERROR("failed to enable link training\n");
> + intel_dp->train_set_valid = false;
> return false;
> }
>
> + /*
> + * The initial set of link parameters are set by this point, so go
> + * ahead and set intel_dp->train_set_valid to false in case any of
> + * the succeeding steps fail. It will be set back to true if we were
> + * able to achieve clock recovery in the specified configuration.
> + */
> + intel_dp->train_set_valid = false;
> +
> voltage_tries = 1;
> max_vswing_tries = 0;
> for (;;) {
> @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>
> if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> DRM_DEBUG_KMS("clock recovery OK\n");
> + intel_dp->train_set_valid = is_edp(intel_dp);
> return true;
> }
>
> @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> training_pattern |
> DP_LINK_SCRAMBLING_DISABLE)) {
> DRM_ERROR("failed to start channel equalization\n");
> + intel_dp->train_set_valid = false;
> return false;
> }
>
> @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> /* Try 5 times, else fail and try at lower BW */
> if (tries == 5) {
> intel_dp_dump_link_status(link_status);
> + intel_dp->train_set_valid = false;
> DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> }
There are other cases in the channel equalization loop of 5 tries where if drm_dp_clock_recover_ok
is not true then it just breaks from the for loop. Same in case of failure to update link train or
failure to get link status. In this case we dont set train_set_valid to false sinec the tries is not 5 yet
In this case since the train_set_valid was true when it entered this function, it will
stay true without actually succeeding at ch eq.
Shouldnt we be setting train_set_valid to false in these cases?
Or is there something I am missing here?
Regards
Manasi
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index f91de9c..792bf547 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -994,6 +994,7 @@ struct intel_dp {
> struct drm_dp_aux aux;
> enum intel_display_power_domain aux_power_domain;
> uint8_t train_set[4];
> + bool train_set_valid;
> int panel_power_up_delay;
> int panel_power_down_delay;
> int panel_power_cycle_delay;
> @@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> }
>
> bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> +bool is_edp(struct intel_dp *intel_dp);
> int intel_dp_link_required(int pixel_clock, int bpp);
> int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> --
> 2.7.4
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-16 22:13 ` [PATCH v5] " Manasi Navare
@ 2017-08-17 17:50 ` Jim Bride
2017-08-17 19:20 ` Manasi Navare
0 siblings, 1 reply; 22+ messages in thread
From: Jim Bride @ 2017-08-17 17:50 UTC (permalink / raw)
To: Manasi Navare; +Cc: Paulo Zanoni, Jani Nikula, intel-gfx, Rodrigo Vivi
On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > This set of changes has some history to them. There were several attempts
> > to add what was called "fast link training" to i915, which actually wasn't
> > fast link training as per the DP spec. These changes were:
> >
> > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> >
> > which were eventually hand-reverted by:
> >
> > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > feature")
> >
> > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
> > very bad side-effects on PSR functionality on Skylake. The issue at
> > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > (depending on the original link configuration) in order to quickly get
> > the source and sink back in synchronization across the link before handing
> > control back to the i915. There's an assumption that none of the link
> > configuration information has changed (and thus it's still valid) since the
> > last full link training operation. The revert above was identified via a
> > bisect as the cause of some of Skylake's PSR woes. This patch, largely
> > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > puts the eDP portions of this patch back in place. None of the flickering
> > issues that spurred the revert have been seen, and I suspect the real
> > culprits here were addressed by some of the recent link training changes
> > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > with these changes in-place.
> >
> > v2 and v3: Rebase
> > v4: * Clean up accesses to train_set_valid a bit for easier
> > reading. (Chris)
> > * Rebase
> > v5: * Checkpatch cleanup
> > * Rebase
> >
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > Cc: Mika Kahola <mika.kahola@intel.com>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > 3 files changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 76c8a0b..4bd409c 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
> > * If a CPU or PCH DP output is attached to an eDP panel, this function
> > * will return true, and false otherwise.
> > */
> > -static bool is_edp(struct intel_dp *intel_dp)
> > +bool is_edp(struct intel_dp *intel_dp)
> > {
> > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> >
> > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> >
> > intel_dp->reset_link_params = false;
> > + intel_dp->train_set_valid = false;
> > }
> >
> > intel_dp_print_rates(intel_dp);
> > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > intel_dp_set_source_rates(intel_dp);
> >
> > intel_dp->reset_link_params = true;
> > + intel_dp->train_set_valid = false;
> > intel_dp->pps_pipe = INVALID_PIPE;
> > intel_dp->active_pipe = INVALID_PIPE;
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..67032cf 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -94,7 +94,8 @@ static bool
> > intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > uint8_t dp_train_pat)
> > {
> > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > + if (!intel_dp->train_set_valid)
> > + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > intel_dp_set_signal_levels(intel_dp);
> > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > }
> > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > DP_TRAINING_PATTERN_1 |
> > DP_LINK_SCRAMBLING_DISABLE)) {
> > DRM_ERROR("failed to enable link training\n");
> > + intel_dp->train_set_valid = false;
> > return false;
> > }
> >
> > + /*
> > + * The initial set of link parameters are set by this point, so go
> > + * ahead and set intel_dp->train_set_valid to false in case any of
> > + * the succeeding steps fail. It will be set back to true if we were
> > + * able to achieve clock recovery in the specified configuration.
> > + */
> > + intel_dp->train_set_valid = false;
> > +
> > voltage_tries = 1;
> > max_vswing_tries = 0;
> > for (;;) {
> > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >
> > if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > DRM_DEBUG_KMS("clock recovery OK\n");
> > + intel_dp->train_set_valid = is_edp(intel_dp);
> > return true;
> > }
> >
> > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > training_pattern |
> > DP_LINK_SCRAMBLING_DISABLE)) {
> > DRM_ERROR("failed to start channel equalization\n");
> > + intel_dp->train_set_valid = false;
> > return false;
> > }
> >
> > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > /* Try 5 times, else fail and try at lower BW */
> > if (tries == 5) {
> > intel_dp_dump_link_status(link_status);
> > + intel_dp->train_set_valid = false;
> > DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > }
>
> There are other cases in the channel equalization loop of 5 tries where if drm_dp_clock_recover_ok
> is not true then it just breaks from the for loop. Same in case of failure to update link train or
> failure to get link status. In this case we dont set train_set_valid to false sinec the tries is not 5 yet
> In this case since the train_set_valid was true when it entered this function, it will
> stay true without actually succeeding at ch eq.
> Shouldnt we be setting train_set_valid to false in these cases?
> Or is there something I am missing here?
It's set to false before all of those, and then set back to true if the
retrain works and we're on eDP. Making the change to do this was some
review feedback from Chris on an earlier version of the patch.
Jim
> Regards
> Manasi
>
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index f91de9c..792bf547 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -994,6 +994,7 @@ struct intel_dp {
> > struct drm_dp_aux aux;
> > enum intel_display_power_domain aux_power_domain;
> > uint8_t train_set[4];
> > + bool train_set_valid;
> > int panel_power_up_delay;
> > int panel_power_down_delay;
> > int panel_power_cycle_delay;
> > @@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> > }
> >
> > bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > +bool is_edp(struct intel_dp *intel_dp);
> > int intel_dp_link_required(int pixel_clock, int bpp);
> > int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> > --
> > 2.7.4
> >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-17 17:50 ` Jim Bride
@ 2017-08-17 19:20 ` Manasi Navare
2017-08-17 19:52 ` Manasi Navare
2017-08-17 19:54 ` Jim Bride
0 siblings, 2 replies; 22+ messages in thread
From: Manasi Navare @ 2017-08-17 19:20 UTC (permalink / raw)
To: Jim Bride; +Cc: Paulo Zanoni, Jani Nikula, intel-gfx, Rodrigo Vivi
On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote:
> On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > > This set of changes has some history to them. There were several attempts
> > > to add what was called "fast link training" to i915, which actually wasn't
> > > fast link training as per the DP spec. These changes were:
> > >
> > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > >
> > > which were eventually hand-reverted by:
> > >
> > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > > feature")
> > >
> > > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
> > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > (depending on the original link configuration) in order to quickly get
> > > the source and sink back in synchronization across the link before handing
> > > control back to the i915. There's an assumption that none of the link
> > > configuration information has changed (and thus it's still valid) since the
> > > last full link training operation. The revert above was identified via a
> > > bisect as the cause of some of Skylake's PSR woes. This patch, largely
> > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > puts the eDP portions of this patch back in place. None of the flickering
> > > issues that spurred the revert have been seen, and I suspect the real
> > > culprits here were addressed by some of the recent link training changes
> > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > with these changes in-place.
> > >
> > > v2 and v3: Rebase
> > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > reading. (Chris)
> > > * Rebase
> > > v5: * Checkpatch cleanup
> > > * Rebase
> > >
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> > > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > > 3 files changed, 19 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > index 76c8a0b..4bd409c 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
> > > * If a CPU or PCH DP output is attached to an eDP panel, this function
> > > * will return true, and false otherwise.
> > > */
> > > -static bool is_edp(struct intel_dp *intel_dp)
> > > +bool is_edp(struct intel_dp *intel_dp)
> > > {
> > > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > >
> > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > >
> > > intel_dp->reset_link_params = false;
> > > + intel_dp->train_set_valid = false;
> > > }
> > >
> > > intel_dp_print_rates(intel_dp);
> > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > > intel_dp_set_source_rates(intel_dp);
> > >
> > > intel_dp->reset_link_params = true;
> > > + intel_dp->train_set_valid = false;
> > > intel_dp->pps_pipe = INVALID_PIPE;
> > > intel_dp->active_pipe = INVALID_PIPE;
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > index 05907fa..67032cf 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > @@ -94,7 +94,8 @@ static bool
> > > intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > > uint8_t dp_train_pat)
> > > {
> > > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > + if (!intel_dp->train_set_valid)
> > > + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > intel_dp_set_signal_levels(intel_dp);
> > > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > > }
> > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > DP_TRAINING_PATTERN_1 |
> > > DP_LINK_SCRAMBLING_DISABLE)) {
> > > DRM_ERROR("failed to enable link training\n");
> > > + intel_dp->train_set_valid = false;
> > > return false;
> > > }
> > >
> > > + /*
> > > + * The initial set of link parameters are set by this point, so go
> > > + * ahead and set intel_dp->train_set_valid to false in case any of
> > > + * the succeeding steps fail. It will be set back to true if we were
> > > + * able to achieve clock recovery in the specified configuration.
> > > + */
> > > + intel_dp->train_set_valid = false;
> > > +
> > > voltage_tries = 1;
> > > max_vswing_tries = 0;
> > > for (;;) {
> > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > >
> > > if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > > DRM_DEBUG_KMS("clock recovery OK\n");
> > > + intel_dp->train_set_valid = is_edp(intel_dp);
> > > return true;
> > > }
> > >
> > > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > training_pattern |
> > > DP_LINK_SCRAMBLING_DISABLE)) {
> > > DRM_ERROR("failed to start channel equalization\n");
> > > + intel_dp->train_set_valid = false;
> > > return false;
> > > }
> > >
> > > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > /* Try 5 times, else fail and try at lower BW */
> > > if (tries == 5) {
> > > intel_dp_dump_link_status(link_status);
> > > + intel_dp->train_set_valid = false;
> > > DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > > }
> >
> > There are other cases in the channel equalization loop of 5 tries where if drm_dp_clock_recover_ok
> > is not true then it just breaks from the for loop. Same in case of failure to update link train or
> > failure to get link status. In this case we dont set train_set_valid to false sinec the tries is not 5 yet
> > In this case since the train_set_valid was true when it entered this function, it will
> > stay true without actually succeeding at ch eq.
> > Shouldnt we be setting train_set_valid to false in these cases?
> > Or is there something I am missing here?
>
> It's set to false before all of those, and then set back to true if the
> retrain works and we're on eDP. Making the change to do this was some
> review feedback from Chris on an earlier version of the patch.
>
> Jim
>
>
I see that it is set to false before starting the clock recovery but after clock recovery
succeeds, this is set to true and only then you will proceed with channel equalization.
And in channel equalization, it never gets set to false in case of the failures I mentioned above since
we just break there.
It then gets set to false only if the tries are 5 but it should also be set to false in case
of other failures that I mentioned else we will end up leaving it to true even when channel EQ never
succeeded.
Manasi
> > Regards
> > Manasi
> >
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > index f91de9c..792bf547 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -994,6 +994,7 @@ struct intel_dp {
> > > struct drm_dp_aux aux;
> > > enum intel_display_power_domain aux_power_domain;
> > > uint8_t train_set[4];
> > > + bool train_set_valid;
> > > int panel_power_up_delay;
> > > int panel_power_down_delay;
> > > int panel_power_cycle_delay;
> > > @@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> > > }
> > >
> > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > +bool is_edp(struct intel_dp *intel_dp);
> > > int intel_dp_link_required(int pixel_clock, int bpp);
> > > int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > > bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> > > --
> > > 2.7.4
> > >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-17 19:20 ` Manasi Navare
@ 2017-08-17 19:52 ` Manasi Navare
2017-08-17 19:54 ` Jim Bride
1 sibling, 0 replies; 22+ messages in thread
From: Manasi Navare @ 2017-08-17 19:52 UTC (permalink / raw)
To: Jim Bride; +Cc: Jani Nikula, intel-gfx, Paulo Zanoni, Rodrigo Vivi
On Thu, Aug 17, 2017 at 12:20:03PM -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote:
> > On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> > > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > > > This set of changes has some history to them. There were several attempts
> > > > to add what was called "fast link training" to i915, which actually wasn't
> > > > fast link training as per the DP spec. These changes were:
> > > >
> > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > >
> > > > which were eventually hand-reverted by:
> > > >
> > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > > > feature")
> > > >
> > > > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
> > > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > > (depending on the original link configuration) in order to quickly get
> > > > the source and sink back in synchronization across the link before handing
> > > > control back to the i915. There's an assumption that none of the link
> > > > configuration information has changed (and thus it's still valid) since the
> > > > last full link training operation. The revert above was identified via a
> > > > bisect as the cause of some of Skylake's PSR woes. This patch, largely
> > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > > puts the eDP portions of this patch back in place. None of the flickering
> > > > issues that spurred the revert have been seen, and I suspect the real
> > > > culprits here were addressed by some of the recent link training changes
> > > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > > with these changes in-place.
> > > >
> > > > v2 and v3: Rebase
> > > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > > reading. (Chris)
> > > > * Rebase
> > > > v5: * Checkpatch cleanup
> > > > * Rebase
> > > >
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > > > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > > > 3 files changed, 19 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 76c8a0b..4bd409c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
> > > > * If a CPU or PCH DP output is attached to an eDP panel, this function
> > > > * will return true, and false otherwise.
> > > > */
> > > > -static bool is_edp(struct intel_dp *intel_dp)
> > > > +bool is_edp(struct intel_dp *intel_dp)
I also need this function to be exposed to files outside of intel_dp.c
for the patch:
https://patchwork.freedesktop.org/series/28900/
But one of the review comments I got is to prefix the name of this function with intel_dp
when exposing it to outside of intel_dp.c which makes sense as per the naming conventions
of the other functions. But we already have a function intel_dp_is_edp() used to get VBT information.
Any suggestions for the name? And do you want to make this change as part of your series so
I can rebase my patch on top of this?
Regards
Manasi
> > > > {
> > > > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > >
> > > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > > > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > >
> > > > intel_dp->reset_link_params = false;
> > > > + intel_dp->train_set_valid = false;
> > > > }
> > > >
> > > > intel_dp_print_rates(intel_dp);
> > > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > > > intel_dp_set_source_rates(intel_dp);
> > > >
> > > > intel_dp->reset_link_params = true;
> > > > + intel_dp->train_set_valid = false;
> > > > intel_dp->pps_pipe = INVALID_PIPE;
> > > > intel_dp->active_pipe = INVALID_PIPE;
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > index 05907fa..67032cf 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > @@ -94,7 +94,8 @@ static bool
> > > > intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > > > uint8_t dp_train_pat)
> > > > {
> > > > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > > + if (!intel_dp->train_set_valid)
> > > > + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > > intel_dp_set_signal_levels(intel_dp);
> > > > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > > > }
> > > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > > DP_TRAINING_PATTERN_1 |
> > > > DP_LINK_SCRAMBLING_DISABLE)) {
> > > > DRM_ERROR("failed to enable link training\n");
> > > > + intel_dp->train_set_valid = false;
> > > > return false;
> > > > }
> > > >
> > > > + /*
> > > > + * The initial set of link parameters are set by this point, so go
> > > > + * ahead and set intel_dp->train_set_valid to false in case any of
> > > > + * the succeeding steps fail. It will be set back to true if we were
> > > > + * able to achieve clock recovery in the specified configuration.
> > > > + */
> > > > + intel_dp->train_set_valid = false;
> > > > +
> > > > voltage_tries = 1;
> > > > max_vswing_tries = 0;
> > > > for (;;) {
> > > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > >
> > > > if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > > > DRM_DEBUG_KMS("clock recovery OK\n");
> > > > + intel_dp->train_set_valid = is_edp(intel_dp);
> > > > return true;
> > > > }
> > > >
> > > > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > > training_pattern |
> > > > DP_LINK_SCRAMBLING_DISABLE)) {
> > > > DRM_ERROR("failed to start channel equalization\n");
> > > > + intel_dp->train_set_valid = false;
> > > > return false;
> > > > }
> > > >
> > > > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > > /* Try 5 times, else fail and try at lower BW */
> > > > if (tries == 5) {
> > > > intel_dp_dump_link_status(link_status);
> > > > + intel_dp->train_set_valid = false;
> > > > DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > > > }
> > >
> > > There are other cases in the channel equalization loop of 5 tries where if drm_dp_clock_recover_ok
> > > is not true then it just breaks from the for loop. Same in case of failure to update link train or
> > > failure to get link status. In this case we dont set train_set_valid to false sinec the tries is not 5 yet
> > > In this case since the train_set_valid was true when it entered this function, it will
> > > stay true without actually succeeding at ch eq.
> > > Shouldnt we be setting train_set_valid to false in these cases?
> > > Or is there something I am missing here?
> >
> > It's set to false before all of those, and then set back to true if the
> > retrain works and we're on eDP. Making the change to do this was some
> > review feedback from Chris on an earlier version of the patch.
> >
> > Jim
> >
> >
>
> I see that it is set to false before starting the clock recovery but after clock recovery
> succeeds, this is set to true and only then you will proceed with channel equalization.
> And in channel equalization, it never gets set to false in case of the failures I mentioned above since
> we just break there.
> It then gets set to false only if the tries are 5 but it should also be set to false in case
> of other failures that I mentioned else we will end up leaving it to true even when channel EQ never
> succeeded.
>
> Manasi
>
> > > Regards
> > > Manasi
> > >
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > > index f91de9c..792bf547 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -994,6 +994,7 @@ struct intel_dp {
> > > > struct drm_dp_aux aux;
> > > > enum intel_display_power_domain aux_power_domain;
> > > > uint8_t train_set[4];
> > > > + bool train_set_valid;
> > > > int panel_power_up_delay;
> > > > int panel_power_down_delay;
> > > > int panel_power_cycle_delay;
> > > > @@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> > > > }
> > > >
> > > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > > +bool is_edp(struct intel_dp *intel_dp);
> > > > int intel_dp_link_required(int pixel_clock, int bpp);
> > > > int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > > > bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> > > > --
> > > > 2.7.4
> > > >
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-17 19:20 ` Manasi Navare
2017-08-17 19:52 ` Manasi Navare
@ 2017-08-17 19:54 ` Jim Bride
1 sibling, 0 replies; 22+ messages in thread
From: Jim Bride @ 2017-08-17 19:54 UTC (permalink / raw)
To: Manasi Navare; +Cc: Paulo Zanoni, Jani Nikula, intel-gfx, Rodrigo Vivi
On Thu, Aug 17, 2017 at 12:20:03PM -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 10:50:04AM -0700, Jim Bride wrote:
> > On Wed, Aug 16, 2017 at 03:13:06PM -0700, Manasi Navare wrote:
> > > On Wed, Aug 09, 2017 at 02:21:07PM -0700, Jim Bride wrote:
> > > > This set of changes has some history to them. There were several attempts
> > > > to add what was called "fast link training" to i915, which actually wasn't
> > > > fast link training as per the DP spec. These changes were:
> > > >
> > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > >
> > > > which were eventually hand-reverted by:
> > > >
> > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > > > feature")
> > > >
> > > > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
> > > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > > (depending on the original link configuration) in order to quickly get
> > > > the source and sink back in synchronization across the link before handing
> > > > control back to the i915. There's an assumption that none of the link
> > > > configuration information has changed (and thus it's still valid) since the
> > > > last full link training operation. The revert above was identified via a
> > > > bisect as the cause of some of Skylake's PSR woes. This patch, largely
> > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > > puts the eDP portions of this patch back in place. None of the flickering
> > > > issues that spurred the revert have been seen, and I suspect the real
> > > > culprits here were addressed by some of the recent link training changes
> > > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > > with these changes in-place.
> > > >
> > > > v2 and v3: Rebase
> > > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > > reading. (Chris)
> > > > * Rebase
> > > > v5: * Checkpatch cleanup
> > > > * Rebase
> > > >
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > > > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > > > 3 files changed, 19 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 76c8a0b..4bd409c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 270000, 540000 };
> > > > * If a CPU or PCH DP output is attached to an eDP panel, this function
> > > > * will return true, and false otherwise.
> > > > */
> > > > -static bool is_edp(struct intel_dp *intel_dp)
> > > > +bool is_edp(struct intel_dp *intel_dp)
> > > > {
> > > > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > >
> > > > @@ -4711,6 +4711,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > > > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > >
> > > > intel_dp->reset_link_params = false;
> > > > + intel_dp->train_set_valid = false;
> > > > }
> > > >
> > > > intel_dp_print_rates(intel_dp);
> > > > @@ -5979,6 +5980,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > > > intel_dp_set_source_rates(intel_dp);
> > > >
> > > > intel_dp->reset_link_params = true;
> > > > + intel_dp->train_set_valid = false;
> > > > intel_dp->pps_pipe = INVALID_PIPE;
> > > > intel_dp->active_pipe = INVALID_PIPE;
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > index 05907fa..67032cf 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > @@ -94,7 +94,8 @@ static bool
> > > > intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > > > uint8_t dp_train_pat)
> > > > {
> > > > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > > + if (!intel_dp->train_set_valid)
> > > > + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > > intel_dp_set_signal_levels(intel_dp);
> > > > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > > > }
> > > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > > DP_TRAINING_PATTERN_1 |
> > > > DP_LINK_SCRAMBLING_DISABLE)) {
> > > > DRM_ERROR("failed to enable link training\n");
> > > > + intel_dp->train_set_valid = false;
> > > > return false;
> > > > }
> > > >
> > > > + /*
> > > > + * The initial set of link parameters are set by this point, so go
> > > > + * ahead and set intel_dp->train_set_valid to false in case any of
> > > > + * the succeeding steps fail. It will be set back to true if we were
> > > > + * able to achieve clock recovery in the specified configuration.
> > > > + */
> > > > + intel_dp->train_set_valid = false;
> > > > +
> > > > voltage_tries = 1;
> > > > max_vswing_tries = 0;
> > > > for (;;) {
> > > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > >
> > > > if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > > > DRM_DEBUG_KMS("clock recovery OK\n");
> > > > + intel_dp->train_set_valid = is_edp(intel_dp);
> > > > return true;
> > > > }
> > > >
> > > > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > > training_pattern |
> > > > DP_LINK_SCRAMBLING_DISABLE)) {
> > > > DRM_ERROR("failed to start channel equalization\n");
> > > > + intel_dp->train_set_valid = false;
> > > > return false;
> > > > }
> > > >
> > > > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > > /* Try 5 times, else fail and try at lower BW */
> > > > if (tries == 5) {
> > > > intel_dp_dump_link_status(link_status);
> > > > + intel_dp->train_set_valid = false;
> > > > DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > > > }
> > >
> > > There are other cases in the channel equalization loop of 5 tries where if drm_dp_clock_recover_ok
> > > is not true then it just breaks from the for loop. Same in case of failure to update link train or
> > > failure to get link status. In this case we dont set train_set_valid to false sinec the tries is not 5 yet
> > > In this case since the train_set_valid was true when it entered this function, it will
> > > stay true without actually succeeding at ch eq.
> > > Shouldnt we be setting train_set_valid to false in these cases?
> > > Or is there something I am missing here?
> >
> > It's set to false before all of those, and then set back to true if the
> > retrain works and we're on eDP. Making the change to do this was some
> > review feedback from Chris on an earlier version of the patch.
> >
> > Jim
> >
> >
>
> I see that it is set to false before starting the clock recovery but after clock recovery
> succeeds, this is set to true and only then you will proceed with channel equalization.
> And in channel equalization, it never gets set to false in case of the failures I mentioned above since
> we just break there.
> It then gets set to false only if the tries are 5 but it should also be set to false in case
> of other failures that I mentioned else we will end up leaving it to true even when channel EQ never
> succeeded.
I see where you're talking about now. I honestly believe that the code
as written is broken. All of those failing 'break' statements should be
'continue' statements (the break for success is fine.) As the code is written,
we break out of the loop on the first failure, and if (tries == 5) will never
be true. If we actually loop through five times before we give up, then
this patch as written is fine.
Jim
> Manasi
>
> > > Regards
> > > Manasi
> > >
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > > index f91de9c..792bf547 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -994,6 +994,7 @@ struct intel_dp {
> > > > struct drm_dp_aux aux;
> > > > enum intel_display_power_domain aux_power_domain;
> > > > uint8_t train_set[4];
> > > > + bool train_set_valid;
> > > > int panel_power_up_delay;
> > > > int panel_power_down_delay;
> > > > int panel_power_cycle_delay;
> > > > @@ -1548,6 +1549,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> > > > }
> > > >
> > > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > > +bool is_edp(struct intel_dp *intel_dp);
> > > > int intel_dp_link_required(int pixel_clock, int bpp);
> > > > int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > > > bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> > > > --
> > > > 2.7.4
> > > >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH v6] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
2017-08-09 21:40 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-08-16 22:13 ` [PATCH v5] " Manasi Navare
@ 2017-08-21 21:03 ` Jim Bride
2017-08-21 23:27 ` Vivi, Rodrigo
2017-08-21 21:24 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev2) Patchwork
` (6 subsequent siblings)
9 siblings, 1 reply; 22+ messages in thread
From: Jim Bride @ 2017-08-21 21:03 UTC (permalink / raw)
To: intel-gfx; +Cc: Paulo Zanoni, Jani Nikula, Rodrigo Vivi
This set of changes has some history to them. There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec. These changes were:
commit 5fa836a9d859 ("drm/i915: DP link training optimization")
commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
which were eventually hand-reverted by:
commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
feature")
in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915. There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation. The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes. This patch, largely
based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
puts the eDP portions of this patch back in place. None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.
v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier
reading. (Chris)
* Rebase
v5: * Checkpatch cleanup
* Rebase
v6: * is_edp() => intel_dp_is_edp()
* rebase
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi D Navare <manasi.d.navare@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 2 ++
drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e385658..38bc7e0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
intel_dp->reset_link_params = false;
+ intel_dp->train_set_valid = false;
}
intel_dp_print_rates(intel_dp);
@@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
intel_dp_set_source_rates(intel_dp);
intel_dp->reset_link_params = true;
+ intel_dp->train_set_valid = false;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..79fe369 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
{
- memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+ if (!intel_dp->train_set_valid)
+ memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
return intel_dp_set_link_train(intel_dp, dp_train_pat);
}
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
+ intel_dp->train_set_valid = false;
return false;
}
+ /*
+ * The initial set of link parameters are set by this point, so go
+ * ahead and set intel_dp->train_set_valid to false in case any of
+ * the succeeding steps fail. It will be set back to true if we were
+ * able to achieve clock recovery in the specified configuration.
+ */
+ intel_dp->train_set_valid = false;
+
voltage_tries = 1;
max_vswing_tries = 0;
for (;;) {
@@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("clock recovery OK\n");
+ intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
return true;
}
@@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
training_pattern |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to start channel equalization\n");
+ intel_dp->train_set_valid = false;
return false;
}
@@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
/* Try 5 times, else fail and try at lower BW */
if (tries == 5) {
intel_dp_dump_link_status(link_status);
+ intel_dp->train_set_valid = false;
DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2940d39..891c892 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -995,6 +995,7 @@ struct intel_dp {
struct drm_dp_aux aux;
enum intel_display_power_domain aux_power_domain;
uint8_t train_set[4];
+ bool train_set_valid;
int panel_power_up_delay;
int panel_power_down_delay;
int panel_power_cycle_delay;
@@ -1549,6 +1550,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
}
bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool is_edp(struct intel_dp *intel_dp);
int intel_dp_link_required(int pixel_clock, int bpp);
int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 22+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev2)
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
` (2 preceding siblings ...)
2017-08-21 21:03 ` [PATCH v6] " Jim Bride
@ 2017-08-21 21:24 ` Patchwork
2017-08-22 16:34 ` [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
` (5 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-08-21 21:24 UTC (permalink / raw)
To: Jim Bride; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/edp: Be less aggressive about changing link config on eDP (rev2)
URL : https://patchwork.freedesktop.org/series/28588/
State : success
== Summary ==
Series 28588v2 drm/i915/edp: Be less aggressive about changing link config on eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/2/mbox/
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass -> DMESG-WARN (fi-byt-n2820) fdo#101705
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705
fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:458s
fi-bdw-gvtdvm total:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:445s
fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:359s
fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:554s
fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:251s
fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:524s
fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:526s
fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:510s
fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:431s
fi-glk-2a total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:611s
fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:444s
fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:419s
fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:423s
fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:507s
fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s
fi-kbl-7260u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:499s
fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s
fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:598s
fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:600s
fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:526s
fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:476s
fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:480s
fi-skl-6770hq total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:484s
fi-skl-gvtdvm total:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:436s
fi-skl-x1585l total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:500s
fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:557s
fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:413s
dbfb2f62576e1c3550d10398b097589959356db3 drm-tip: 2017y-08m-21d-08h-13m-34s UTC integration manifest
b1365d9a97db drm/i915/edp: Be less aggressive about changing link config on eDP
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5453/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v6] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-21 21:03 ` [PATCH v6] " Jim Bride
@ 2017-08-21 23:27 ` Vivi, Rodrigo
2017-08-22 16:32 ` Jim Bride
0 siblings, 1 reply; 22+ messages in thread
From: Vivi, Rodrigo @ 2017-08-21 23:27 UTC (permalink / raw)
To: jim.bride@linux.intel.com
Cc: Zanoni, Paulo R, Nikula, Jani, intel-gfx@lists.freedesktop.org
On Mon, 2017-08-21 at 14:03 -0700, Jim Bride wrote:
> This set of changes has some history to them. There were several attempts
> to add what was called "fast link training" to i915, which actually wasn't
> fast link training as per the DP spec. These changes were:
>
> commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
>
> which were eventually hand-reverted by:
>
> commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> feature")
>
> in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
> very bad side-effects on PSR functionality on Skylake. The issue at
> hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> (depending on the original link configuration) in order to quickly get
> the source and sink back in synchronization across the link before handing
> control back to the i915. There's an assumption that none of the link
> configuration information has changed (and thus it's still valid) since the
> last full link training operation. The revert above was identified via a
> bisect as the cause of some of Skylake's PSR woes. This patch, largely
> based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> puts the eDP portions of this patch back in place. None of the flickering
> issues that spurred the revert have been seen, and I suspect the real
> culprits here were addressed by some of the recent link training changes
> that Manasi has implemented, and PSR on Skylake is definitely more happy
> with these changes in-place.
>
> v2 and v3: Rebase
> v4: * Clean up accesses to train_set_valid a bit for easier
> reading. (Chris)
> * Rebase
> v5: * Checkpatch cleanup
> * Rebase
> v6: * is_edp() => intel_dp_is_edp()
> * rebase
>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Manasi D Navare <manasi.d.navare@intel.com>
> Cc: Mika Kahola <mika.kahola@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 ++
> drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> 3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e385658..38bc7e0 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
>
> intel_dp->reset_link_params = false;
> + intel_dp->train_set_valid = false;
> }
>
> intel_dp_print_rates(intel_dp);
> @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> intel_dp_set_source_rates(intel_dp);
>
> intel_dp->reset_link_params = true;
> + intel_dp->train_set_valid = false;
> intel_dp->pps_pipe = INVALID_PIPE;
> intel_dp->active_pipe = INVALID_PIPE;
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa..79fe369 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -94,7 +94,8 @@ static bool
> intel_dp_reset_link_train(struct intel_dp *intel_dp,
> uint8_t dp_train_pat)
> {
> - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> + if (!intel_dp->train_set_valid)
> + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> intel_dp_set_signal_levels(intel_dp);
> return intel_dp_set_link_train(intel_dp, dp_train_pat);
> }
> @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> DP_TRAINING_PATTERN_1 |
> DP_LINK_SCRAMBLING_DISABLE)) {
> DRM_ERROR("failed to enable link training\n");
> + intel_dp->train_set_valid = false;
> return false;
> }
>
> + /*
> + * The initial set of link parameters are set by this point, so go
> + * ahead and set intel_dp->train_set_valid to false in case any of
> + * the succeeding steps fail. It will be set back to true if we were
> + * able to achieve clock recovery in the specified configuration.
> + */
> + intel_dp->train_set_valid = false;
> +
> voltage_tries = 1;
> max_vswing_tries = 0;
> for (;;) {
> @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>
> if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> DRM_DEBUG_KMS("clock recovery OK\n");
> + intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
Is this one really enough for this case?
I wonder if we should merge is_edp and intel_dp_is_edp somehow instead
of fighting with names and their meanings...
> return true;
> }
>
> @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> training_pattern |
> DP_LINK_SCRAMBLING_DISABLE)) {
> DRM_ERROR("failed to start channel equalization\n");
> + intel_dp->train_set_valid = false;
> return false;
> }
>
> @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> /* Try 5 times, else fail and try at lower BW */
> if (tries == 5) {
> intel_dp_dump_link_status(link_status);
> + intel_dp->train_set_valid = false;
> DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 2940d39..891c892 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -995,6 +995,7 @@ struct intel_dp {
> struct drm_dp_aux aux;
> enum intel_display_power_domain aux_power_domain;
> uint8_t train_set[4];
> + bool train_set_valid;
> int panel_power_up_delay;
> int panel_power_down_delay;
> int panel_power_cycle_delay;
> @@ -1549,6 +1550,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> }
>
> bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> +bool is_edp(struct intel_dp *intel_dp);
it seems you don't need this anymore...
> int intel_dp_link_required(int pixel_clock, int bpp);
> int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v6] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-21 23:27 ` Vivi, Rodrigo
@ 2017-08-22 16:32 ` Jim Bride
0 siblings, 0 replies; 22+ messages in thread
From: Jim Bride @ 2017-08-22 16:32 UTC (permalink / raw)
To: Vivi, Rodrigo
Cc: Zanoni, Paulo R, Nikula, Jani, intel-gfx@lists.freedesktop.org
On Mon, Aug 21, 2017 at 11:27:37PM +0000, Vivi, Rodrigo wrote:
> On Mon, 2017-08-21 at 14:03 -0700, Jim Bride wrote:
> > This set of changes has some history to them. There were several attempts
> > to add what was called "fast link training" to i915, which actually wasn't
> > fast link training as per the DP spec. These changes were:
> >
> > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> >
> > which were eventually hand-reverted by:
> >
> > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > feature")
> >
> > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
> > very bad side-effects on PSR functionality on Skylake. The issue at
> > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > (depending on the original link configuration) in order to quickly get
> > the source and sink back in synchronization across the link before handing
> > control back to the i915. There's an assumption that none of the link
> > configuration information has changed (and thus it's still valid) since the
> > last full link training operation. The revert above was identified via a
> > bisect as the cause of some of Skylake's PSR woes. This patch, largely
> > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > puts the eDP portions of this patch back in place. None of the flickering
> > issues that spurred the revert have been seen, and I suspect the real
> > culprits here were addressed by some of the recent link training changes
> > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > with these changes in-place.
> >
> > v2 and v3: Rebase
> > v4: * Clean up accesses to train_set_valid a bit for easier
> > reading. (Chris)
> > * Rebase
> > v5: * Checkpatch cleanup
> > * Rebase
> > v6: * is_edp() => intel_dp_is_edp()
> > * rebase
> >
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > Cc: Mika Kahola <mika.kahola@intel.com>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 2 ++
> > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > 3 files changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index e385658..38bc7e0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> >
> > intel_dp->reset_link_params = false;
> > + intel_dp->train_set_valid = false;
> > }
> >
> > intel_dp_print_rates(intel_dp);
> > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > intel_dp_set_source_rates(intel_dp);
> >
> > intel_dp->reset_link_params = true;
> > + intel_dp->train_set_valid = false;
> > intel_dp->pps_pipe = INVALID_PIPE;
> > intel_dp->active_pipe = INVALID_PIPE;
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..79fe369 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -94,7 +94,8 @@ static bool
> > intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > uint8_t dp_train_pat)
> > {
> > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > + if (!intel_dp->train_set_valid)
> > + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > intel_dp_set_signal_levels(intel_dp);
> > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > }
> > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > DP_TRAINING_PATTERN_1 |
> > DP_LINK_SCRAMBLING_DISABLE)) {
> > DRM_ERROR("failed to enable link training\n");
> > + intel_dp->train_set_valid = false;
> > return false;
> > }
> >
> > + /*
> > + * The initial set of link parameters are set by this point, so go
> > + * ahead and set intel_dp->train_set_valid to false in case any of
> > + * the succeeding steps fail. It will be set back to true if we were
> > + * able to achieve clock recovery in the specified configuration.
> > + */
> > + intel_dp->train_set_valid = false;
> > +
> > voltage_tries = 1;
> > max_vswing_tries = 0;
> > for (;;) {
> > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >
> > if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > DRM_DEBUG_KMS("clock recovery OK\n");
> > + intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
>
> Is this one really enough for this case?
Yep, it's the only success path.
> I wonder if we should merge is_edp and intel_dp_is_edp somehow instead
> of fighting with names and their meanings...
Jani patched the two functions while I was wrestling with how to
rename is_edp(). Even though it's potentially confusing, I do
think intel_dp_is_edp() is probably as good as it gets.
> > return true;
> > }
> >
> > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > training_pattern |
> > DP_LINK_SCRAMBLING_DISABLE)) {
> > DRM_ERROR("failed to start channel equalization\n");
> > + intel_dp->train_set_valid = false;
> > return false;
> > }
> >
> > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > /* Try 5 times, else fail and try at lower BW */
> > if (tries == 5) {
> > intel_dp_dump_link_status(link_status);
> > + intel_dp->train_set_valid = false;
> > DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index 2940d39..891c892 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -995,6 +995,7 @@ struct intel_dp {
> > struct drm_dp_aux aux;
> > enum intel_display_power_domain aux_power_domain;
> > uint8_t train_set[4];
> > + bool train_set_valid;
> > int panel_power_up_delay;
> > int panel_power_down_delay;
> > int panel_power_cycle_delay;
> > @@ -1549,6 +1550,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> > }
> >
> > bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > +bool is_edp(struct intel_dp *intel_dp);
Whoops. I'll fix this.
> it seems you don't need this anymore...
>
> > int intel_dp_link_required(int pixel_clock, int bpp);
> > int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
` (3 preceding siblings ...)
2017-08-21 21:24 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev2) Patchwork
@ 2017-08-22 16:34 ` Jim Bride
2017-09-15 18:19 ` Manasi Navare
2017-08-22 17:36 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev3) Patchwork
` (4 subsequent siblings)
9 siblings, 1 reply; 22+ messages in thread
From: Jim Bride @ 2017-08-22 16:34 UTC (permalink / raw)
To: intel-gfx; +Cc: Paulo Zanoni, Jani Nikula, Rodrigo Vivi
This set of changes has some history to them. There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec. These changes were:
commit 5fa836a9d859 ("drm/i915: DP link training optimization")
commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
which were eventually hand-reverted by:
commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
feature")
in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915. There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation. The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes. This patch, largely
based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
puts the eDP portions of this patch back in place. None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.
v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier
reading. (Chris)
* Rebase
v5: * Checkpatch cleanup
* Rebase
v6: * is_edp() => intel_dp_is_edp()
* rebase
v7: * Remove extraneous is_edp() prototype (Rodrigo)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi D Navare <manasi.d.navare@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 2 ++
drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e385658..38bc7e0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
intel_dp->reset_link_params = false;
+ intel_dp->train_set_valid = false;
}
intel_dp_print_rates(intel_dp);
@@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
intel_dp_set_source_rates(intel_dp);
intel_dp->reset_link_params = true;
+ intel_dp->train_set_valid = false;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..79fe369 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
{
- memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+ if (!intel_dp->train_set_valid)
+ memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
return intel_dp_set_link_train(intel_dp, dp_train_pat);
}
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
+ intel_dp->train_set_valid = false;
return false;
}
+ /*
+ * The initial set of link parameters are set by this point, so go
+ * ahead and set intel_dp->train_set_valid to false in case any of
+ * the succeeding steps fail. It will be set back to true if we were
+ * able to achieve clock recovery in the specified configuration.
+ */
+ intel_dp->train_set_valid = false;
+
voltage_tries = 1;
max_vswing_tries = 0;
for (;;) {
@@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("clock recovery OK\n");
+ intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
return true;
}
@@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
training_pattern |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to start channel equalization\n");
+ intel_dp->train_set_valid = false;
return false;
}
@@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
/* Try 5 times, else fail and try at lower BW */
if (tries == 5) {
intel_dp_dump_link_status(link_status);
+ intel_dp->train_set_valid = false;
DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2940d39..f4354ec 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -995,6 +995,7 @@ struct intel_dp {
struct drm_dp_aux aux;
enum intel_display_power_domain aux_power_domain;
uint8_t train_set[4];
+ bool train_set_valid;
int panel_power_up_delay;
int panel_power_down_delay;
int panel_power_cycle_delay;
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 22+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev3)
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
` (4 preceding siblings ...)
2017-08-22 16:34 ` [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
@ 2017-08-22 17:36 ` Patchwork
2017-09-19 21:25 ` [PATCH v8] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
` (3 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-08-22 17:36 UTC (permalink / raw)
To: Jim Bride; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/edp: Be less aggressive about changing link config on eDP (rev3)
URL : https://patchwork.freedesktop.org/series/28588/
State : success
== Summary ==
Series 28588v3 drm/i915/edp: Be less aggressive about changing link config on eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/3/mbox/
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass -> FAIL (fi-snb-2600) fdo#100007
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail -> PASS (fi-snb-2600) fdo#100215
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass -> SKIP (fi-skl-x1585l) fdo#101781
Test drv_module_reload:
Subgroup basic-reload-inject:
pass -> DMESG-WARN (fi-kbl-7260u) fdo#102295
fdo#100007 https://bugs.freedesktop.org/show_bug.cgi?id=100007
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fdo#102295 https://bugs.freedesktop.org/show_bug.cgi?id=102295
fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:454s
fi-bdw-gvtdvm total:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:435s
fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:363s
fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:548s
fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:253s
fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:523s
fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:522s
fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:519s
fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:437s
fi-glk-2a total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:607s
fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:445s
fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:420s
fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:424s
fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:507s
fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:473s
fi-kbl-7260u total:279 pass:267 dwarn:2 dfail:0 fail:0 skip:10 time:500s
fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s
fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:587s
fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:599s
fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:526s
fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:473s
fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s
fi-skl-6770hq total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:494s
fi-skl-gvtdvm total:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:444s
fi-skl-x1585l total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:482s
fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:544s
fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:407s
017fec5c2e57672a8c2a350376070e6c6a5ae950 drm-tip: 2017y-08m-22d-16h-23m-11s UTC integration manifest
c688185ea6b2 drm/i915/edp: Be less aggressive about changing link config on eDP
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5464/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-22 16:34 ` [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
@ 2017-09-15 18:19 ` Manasi Navare
2017-09-19 19:55 ` Rodrigo Vivi
0 siblings, 1 reply; 22+ messages in thread
From: Manasi Navare @ 2017-09-15 18:19 UTC (permalink / raw)
To: Jim Bride; +Cc: Paulo Zanoni, Jani Nikula, intel-gfx, Rodrigo Vivi
The patch looks good for eDP link training optimizations.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Manasi
On Tue, Aug 22, 2017 at 09:34:46AM -0700, Jim Bride wrote:
> This set of changes has some history to them. There were several attempts
> to add what was called "fast link training" to i915, which actually wasn't
> fast link training as per the DP spec. These changes were:
>
> commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
>
> which were eventually hand-reverted by:
>
> commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> feature")
>
> in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
> very bad side-effects on PSR functionality on Skylake. The issue at
> hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> (depending on the original link configuration) in order to quickly get
> the source and sink back in synchronization across the link before handing
> control back to the i915. There's an assumption that none of the link
> configuration information has changed (and thus it's still valid) since the
> last full link training operation. The revert above was identified via a
> bisect as the cause of some of Skylake's PSR woes. This patch, largely
> based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> puts the eDP portions of this patch back in place. None of the flickering
> issues that spurred the revert have been seen, and I suspect the real
> culprits here were addressed by some of the recent link training changes
> that Manasi has implemented, and PSR on Skylake is definitely more happy
> with these changes in-place.
>
> v2 and v3: Rebase
> v4: * Clean up accesses to train_set_valid a bit for easier
> reading. (Chris)
> * Rebase
> v5: * Checkpatch cleanup
> * Rebase
> v6: * is_edp() => intel_dp_is_edp()
> * rebase
> v7: * Remove extraneous is_edp() prototype (Rodrigo)
>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Manasi D Navare <manasi.d.navare@intel.com>
> Cc: Mika Kahola <mika.kahola@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 ++
> drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e385658..38bc7e0 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
>
> intel_dp->reset_link_params = false;
> + intel_dp->train_set_valid = false;
> }
>
> intel_dp_print_rates(intel_dp);
> @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> intel_dp_set_source_rates(intel_dp);
>
> intel_dp->reset_link_params = true;
> + intel_dp->train_set_valid = false;
> intel_dp->pps_pipe = INVALID_PIPE;
> intel_dp->active_pipe = INVALID_PIPE;
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa..79fe369 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -94,7 +94,8 @@ static bool
> intel_dp_reset_link_train(struct intel_dp *intel_dp,
> uint8_t dp_train_pat)
> {
> - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> + if (!intel_dp->train_set_valid)
> + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> intel_dp_set_signal_levels(intel_dp);
> return intel_dp_set_link_train(intel_dp, dp_train_pat);
> }
> @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> DP_TRAINING_PATTERN_1 |
> DP_LINK_SCRAMBLING_DISABLE)) {
> DRM_ERROR("failed to enable link training\n");
> + intel_dp->train_set_valid = false;
> return false;
> }
>
> + /*
> + * The initial set of link parameters are set by this point, so go
> + * ahead and set intel_dp->train_set_valid to false in case any of
> + * the succeeding steps fail. It will be set back to true if we were
> + * able to achieve clock recovery in the specified configuration.
> + */
> + intel_dp->train_set_valid = false;
> +
> voltage_tries = 1;
> max_vswing_tries = 0;
> for (;;) {
> @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>
> if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> DRM_DEBUG_KMS("clock recovery OK\n");
> + intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
> return true;
> }
>
> @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> training_pattern |
> DP_LINK_SCRAMBLING_DISABLE)) {
> DRM_ERROR("failed to start channel equalization\n");
> + intel_dp->train_set_valid = false;
> return false;
> }
>
> @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> /* Try 5 times, else fail and try at lower BW */
> if (tries == 5) {
> intel_dp_dump_link_status(link_status);
> + intel_dp->train_set_valid = false;
> DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 2940d39..f4354ec 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -995,6 +995,7 @@ struct intel_dp {
> struct drm_dp_aux aux;
> enum intel_display_power_domain aux_power_domain;
> uint8_t train_set[4];
> + bool train_set_valid;
> int panel_power_up_delay;
> int panel_power_down_delay;
> int panel_power_cycle_delay;
> --
> 2.7.4
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-09-15 18:19 ` Manasi Navare
@ 2017-09-19 19:55 ` Rodrigo Vivi
2017-09-19 21:20 ` Jim Bride
2017-09-27 12:23 ` Mika Kahola
0 siblings, 2 replies; 22+ messages in thread
From: Rodrigo Vivi @ 2017-09-19 19:55 UTC (permalink / raw)
To: Manasi Navare; +Cc: Jani Nikula, intel-gfx, Paulo Zanoni
On Fri, Sep 15, 2017 at 06:19:12PM +0000, Manasi Navare wrote:
> The patch looks good for eDP link training optimizations.
>
> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
I haven't merged this patch yet because I'd like an Ack from Jani.
Also I'd like to hear from Mika if he believes it is safe or not.
On his revert commit he wrote:
"It has been found out that in some HW combination the DisplayPort
fast link training feature caused screen flickering. Let's revert
this feature for now until we can ensure that the feature works for
all platforms."
I don't want to merge this patch to fix a feature that is disabled
by default with the risk of bringing flickerings back.
But even if we decide to go ahead and merge I believe we need to
resend the test and collect a full round of CI that now runs
all IGT tests.
Thanks,
Rodrigo.
>
> Manasi
>
> On Tue, Aug 22, 2017 at 09:34:46AM -0700, Jim Bride wrote:
> > This set of changes has some history to them. There were several attempts
> > to add what was called "fast link training" to i915, which actually wasn't
> > fast link training as per the DP spec. These changes were:
> >
> > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> >
> > which were eventually hand-reverted by:
> >
> > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > feature")
> >
> > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
> > very bad side-effects on PSR functionality on Skylake. The issue at
> > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > (depending on the original link configuration) in order to quickly get
> > the source and sink back in synchronization across the link before handing
> > control back to the i915. There's an assumption that none of the link
> > configuration information has changed (and thus it's still valid) since the
> > last full link training operation. The revert above was identified via a
> > bisect as the cause of some of Skylake's PSR woes. This patch, largely
> > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > puts the eDP portions of this patch back in place. None of the flickering
> > issues that spurred the revert have been seen, and I suspect the real
> > culprits here were addressed by some of the recent link training changes
> > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > with these changes in-place.
> >
> > v2 and v3: Rebase
> > v4: * Clean up accesses to train_set_valid a bit for easier
> > reading. (Chris)
> > * Rebase
> > v5: * Checkpatch cleanup
> > * Rebase
> > v6: * is_edp() => intel_dp_is_edp()
> > * rebase
> > v7: * Remove extraneous is_edp() prototype (Rodrigo)
> >
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > Cc: Mika Kahola <mika.kahola@intel.com>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 2 ++
> > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > 3 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index e385658..38bc7e0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> >
> > intel_dp->reset_link_params = false;
> > + intel_dp->train_set_valid = false;
> > }
> >
> > intel_dp_print_rates(intel_dp);
> > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > intel_dp_set_source_rates(intel_dp);
> >
> > intel_dp->reset_link_params = true;
> > + intel_dp->train_set_valid = false;
> > intel_dp->pps_pipe = INVALID_PIPE;
> > intel_dp->active_pipe = INVALID_PIPE;
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..79fe369 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -94,7 +94,8 @@ static bool
> > intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > uint8_t dp_train_pat)
> > {
> > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > + if (!intel_dp->train_set_valid)
> > + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > intel_dp_set_signal_levels(intel_dp);
> > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > }
> > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > DP_TRAINING_PATTERN_1 |
> > DP_LINK_SCRAMBLING_DISABLE)) {
> > DRM_ERROR("failed to enable link training\n");
> > + intel_dp->train_set_valid = false;
> > return false;
> > }
> >
> > + /*
> > + * The initial set of link parameters are set by this point, so go
> > + * ahead and set intel_dp->train_set_valid to false in case any of
> > + * the succeeding steps fail. It will be set back to true if we were
> > + * able to achieve clock recovery in the specified configuration.
> > + */
> > + intel_dp->train_set_valid = false;
> > +
> > voltage_tries = 1;
> > max_vswing_tries = 0;
> > for (;;) {
> > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >
> > if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > DRM_DEBUG_KMS("clock recovery OK\n");
> > + intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
> > return true;
> > }
> >
> > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > training_pattern |
> > DP_LINK_SCRAMBLING_DISABLE)) {
> > DRM_ERROR("failed to start channel equalization\n");
> > + intel_dp->train_set_valid = false;
> > return false;
> > }
> >
> > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > /* Try 5 times, else fail and try at lower BW */
> > if (tries == 5) {
> > intel_dp_dump_link_status(link_status);
> > + intel_dp->train_set_valid = false;
> > DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index 2940d39..f4354ec 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -995,6 +995,7 @@ struct intel_dp {
> > struct drm_dp_aux aux;
> > enum intel_display_power_domain aux_power_domain;
> > uint8_t train_set[4];
> > + bool train_set_valid;
> > int panel_power_up_delay;
> > int panel_power_down_delay;
> > int panel_power_cycle_delay;
> > --
> > 2.7.4
> >
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-09-19 19:55 ` Rodrigo Vivi
@ 2017-09-19 21:20 ` Jim Bride
2017-09-27 12:23 ` Mika Kahola
1 sibling, 0 replies; 22+ messages in thread
From: Jim Bride @ 2017-09-19 21:20 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: Jani Nikula, intel-gfx, Paulo Zanoni
On Tue, Sep 19, 2017 at 12:55:24PM -0700, Rodrigo Vivi wrote:
> On Fri, Sep 15, 2017 at 06:19:12PM +0000, Manasi Navare wrote:
> > The patch looks good for eDP link training optimizations.
> >
> > Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
>
> I haven't merged this patch yet because I'd like an Ack from Jani.
>
> Also I'd like to hear from Mika if he believes it is safe or not.
Mika looked at it a few months ago and thought it would be ok. It
can't hurt to have him look at it again, though.
> On his revert commit he wrote:
> "It has been found out that in some HW combination the DisplayPort
> fast link training feature caused screen flickering. Let's revert
> this feature for now until we can ensure that the feature works for
> all platforms."
>
> I don't want to merge this patch to fix a feature that is disabled
> by default with the risk of bringing flickerings back.
>
> But even if we decide to go ahead and merge I believe we need to
> resend the test and collect a full round of CI that now runs
> all IGT tests.
I assume you mean resend the patch here. I'll do that.
Jim
> Thanks,
> Rodrigo.
>
>
> >
> > Manasi
> >
> > On Tue, Aug 22, 2017 at 09:34:46AM -0700, Jim Bride wrote:
> > > This set of changes has some history to them. There were several attempts
> > > to add what was called "fast link training" to i915, which actually wasn't
> > > fast link training as per the DP spec. These changes were:
> > >
> > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > >
> > > which were eventually hand-reverted by:
> > >
> > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
> > > feature")
> > >
> > > in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
> > > very bad side-effects on PSR functionality on Skylake. The issue at
> > > hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
> > > (depending on the original link configuration) in order to quickly get
> > > the source and sink back in synchronization across the link before handing
> > > control back to the i915. There's an assumption that none of the link
> > > configuration information has changed (and thus it's still valid) since the
> > > last full link training operation. The revert above was identified via a
> > > bisect as the cause of some of Skylake's PSR woes. This patch, largely
> > > based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > puts the eDP portions of this patch back in place. None of the flickering
> > > issues that spurred the revert have been seen, and I suspect the real
> > > culprits here were addressed by some of the recent link training changes
> > > that Manasi has implemented, and PSR on Skylake is definitely more happy
> > > with these changes in-place.
> > >
> > > v2 and v3: Rebase
> > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > reading. (Chris)
> > > * Rebase
> > > v5: * Checkpatch cleanup
> > > * Rebase
> > > v6: * is_edp() => intel_dp_is_edp()
> > > * rebase
> > > v7: * Remove extraneous is_edp() prototype (Rodrigo)
> > >
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
> > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 2 ++
> > > drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
> > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > 3 files changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > index e385658..38bc7e0 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
> > > intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > >
> > > intel_dp->reset_link_params = false;
> > > + intel_dp->train_set_valid = false;
> > > }
> > >
> > > intel_dp_print_rates(intel_dp);
> > > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > > intel_dp_set_source_rates(intel_dp);
> > >
> > > intel_dp->reset_link_params = true;
> > > + intel_dp->train_set_valid = false;
> > > intel_dp->pps_pipe = INVALID_PIPE;
> > > intel_dp->active_pipe = INVALID_PIPE;
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > index 05907fa..79fe369 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > @@ -94,7 +94,8 @@ static bool
> > > intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > > uint8_t dp_train_pat)
> > > {
> > > - memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > + if (!intel_dp->train_set_valid)
> > > + memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > > intel_dp_set_signal_levels(intel_dp);
> > > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > > }
> > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > DP_TRAINING_PATTERN_1 |
> > > DP_LINK_SCRAMBLING_DISABLE)) {
> > > DRM_ERROR("failed to enable link training\n");
> > > + intel_dp->train_set_valid = false;
> > > return false;
> > > }
> > >
> > > + /*
> > > + * The initial set of link parameters are set by this point, so go
> > > + * ahead and set intel_dp->train_set_valid to false in case any of
> > > + * the succeeding steps fail. It will be set back to true if we were
> > > + * able to achieve clock recovery in the specified configuration.
> > > + */
> > > + intel_dp->train_set_valid = false;
> > > +
> > > voltage_tries = 1;
> > > max_vswing_tries = 0;
> > > for (;;) {
> > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > >
> > > if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
> > > DRM_DEBUG_KMS("clock recovery OK\n");
> > > + intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
> > > return true;
> > > }
> > >
> > > @@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > training_pattern |
> > > DP_LINK_SCRAMBLING_DISABLE)) {
> > > DRM_ERROR("failed to start channel equalization\n");
> > > + intel_dp->train_set_valid = false;
> > > return false;
> > > }
> > >
> > > @@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > /* Try 5 times, else fail and try at lower BW */
> > > if (tries == 5) {
> > > intel_dp_dump_link_status(link_status);
> > > + intel_dp->train_set_valid = false;
> > > DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > > index 2940d39..f4354ec 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -995,6 +995,7 @@ struct intel_dp {
> > > struct drm_dp_aux aux;
> > > enum intel_display_power_domain aux_power_domain;
> > > uint8_t train_set[4];
> > > + bool train_set_valid;
> > > int panel_power_up_delay;
> > > int panel_power_down_delay;
> > > int panel_power_cycle_delay;
> > > --
> > > 2.7.4
> > >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH v8] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
` (5 preceding siblings ...)
2017-08-22 17:36 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev3) Patchwork
@ 2017-09-19 21:25 ` Jim Bride
2017-09-19 22:02 ` ✗ Fi.CI.BAT: failure for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4) Patchwork
` (2 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Jim Bride @ 2017-09-19 21:25 UTC (permalink / raw)
To: intel-gfx; +Cc: Paulo Zanoni, Jani Nikula, Rodrigo Vivi
This set of changes has some history to them. There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec. These changes were:
commit 5fa836a9d859 ("drm/i915: DP link training optimization")
commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
which were eventually hand-reverted by:
commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link training
feature")
in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915. There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation. The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes. This patch, largely
based on commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
puts the eDP portions of this patch back in place. None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.
v2 and v3: Rebase
v4: * Clean up accesses to train_set_valid a bit for easier
reading. (Chris)
* Rebase
v5: * Checkpatch cleanup
* Rebase
v6: * is_edp() => intel_dp_is_edp()
* rebase
v7: * Remove extraneous is_edp() prototype (Rodrigo)
v8: Rebase
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi D Navare <manasi.d.navare@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 2 ++
drivers/gpu/drm/i915/intel_dp_link_training.c | 15 ++++++++++++++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8db6b11..aee7e9b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4748,6 +4748,7 @@ intel_dp_long_pulse(struct intel_connector *intel_connector)
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
intel_dp->reset_link_params = false;
+ intel_dp->train_set_valid = false;
}
intel_dp_print_rates(intel_dp);
@@ -6017,6 +6018,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
intel_dp_set_source_rates(intel_dp);
intel_dp->reset_link_params = true;
+ intel_dp->train_set_valid = false;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..79fe369 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
{
- memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+ if (!intel_dp->train_set_valid)
+ memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
return intel_dp_set_link_train(intel_dp, dp_train_pat);
}
@@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
+ intel_dp->train_set_valid = false;
return false;
}
+ /*
+ * The initial set of link parameters are set by this point, so go
+ * ahead and set intel_dp->train_set_valid to false in case any of
+ * the succeeding steps fail. It will be set back to true if we were
+ * able to achieve clock recovery in the specified configuration.
+ */
+ intel_dp->train_set_valid = false;
+
voltage_tries = 1;
max_vswing_tries = 0;
for (;;) {
@@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
if (drm_dp_clock_recovery_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("clock recovery OK\n");
+ intel_dp->train_set_valid = intel_dp_is_edp(intel_dp);
return true;
}
@@ -256,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
training_pattern |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to start channel equalization\n");
+ intel_dp->train_set_valid = false;
return false;
}
@@ -296,6 +308,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
/* Try 5 times, else fail and try at lower BW */
if (tries == 5) {
intel_dp_dump_link_status(link_status);
+ intel_dp->train_set_valid = false;
DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3078076..40e98ed 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -987,6 +987,7 @@ struct intel_dp {
struct drm_dp_aux aux;
enum intel_display_power_domain aux_power_domain;
uint8_t train_set[4];
+ bool train_set_valid;
int panel_power_up_delay;
int panel_power_down_delay;
int panel_power_cycle_delay;
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 22+ messages in thread
* ✗ Fi.CI.BAT: failure for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
` (6 preceding siblings ...)
2017-09-19 21:25 ` [PATCH v8] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
@ 2017-09-19 22:02 ` Patchwork
2017-09-25 23:12 ` ✓ Fi.CI.BAT: success " Patchwork
2017-09-26 4:12 ` ✓ Fi.CI.IGT: " Patchwork
9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-09-19 22:02 UTC (permalink / raw)
To: Jim Bride; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
URL : https://patchwork.freedesktop.org/series/28588/
State : failure
== Summary ==
Series 28588v4 drm/i915/edp: Be less aggressive about changing link config on eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/4/mbox/
Test gem_exec_reloc:
Subgroup basic-gtt-cpu-active:
pass -> INCOMPLETE (fi-byt-j1900)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass -> FAIL (fi-snb-2600) fdo#100215
Test kms_frontbuffer_tracking:
Subgroup basic:
dmesg-warn -> PASS (fi-kbl-7500u)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
incomplete -> DMESG-WARN (fi-cfl-s) fdo#102294
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS (fi-kbl-7500u)
Test drv_module_reload:
Subgroup basic-reload:
pass -> DMESG-WARN (fi-glk-1) fdo#102777
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294
fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777
fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:439s
fi-bdw-gvtdvm total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:470s
fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:415s
fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:514s
fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:278s
fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:514s
fi-byt-j1900 total:102 pass:83 dwarn:0 dfail:0 fail:0 skip:18
fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:479s
fi-cfl-s total:289 pass:222 dwarn:35 dfail:0 fail:0 skip:32 time:542s
fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:416s
fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29 time:564s
fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:426s
fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:403s
fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:427s
fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:484s
fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:458s
fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:472s
fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:573s
fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:586s
fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:542s
fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:448s
fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:750s
fi-skl-6770hq total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:487s
fi-skl-gvtdvm total:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:476s
fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:568s
fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:1 skip:39 time:414s
bf6ecf6d25c1c45e576643b7d7a65e8b1e6b4f01 drm-tip: 2017y-09m-19d-17h-23m-04s UTC integration manifest
d200ddf98baa drm/i915/edp: Be less aggressive about changing link config on eDP
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5758/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
` (7 preceding siblings ...)
2017-09-19 22:02 ` ✗ Fi.CI.BAT: failure for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4) Patchwork
@ 2017-09-25 23:12 ` Patchwork
2017-09-26 4:12 ` ✓ Fi.CI.IGT: " Patchwork
9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-09-25 23:12 UTC (permalink / raw)
To: Jim Bride; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
URL : https://patchwork.freedesktop.org/series/28588/
State : success
== Summary ==
Series 28588v4 drm/i915/edp: Be less aggressive about changing link config on eDP
https://patchwork.freedesktop.org/api/1.0/series/28588/revisions/4/mbox/
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS (fi-kbl-r)
Test pm_rpm:
Subgroup basic-rte:
pass -> DMESG-WARN (fi-cfl-s) fdo#102294
Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS (fi-glk-1) fdo#102777
fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294
fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777
fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:438s
fi-bdw-gvtdvm total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:465s
fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:421s
fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:513s
fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:277s
fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:496s
fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:490s
fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:495s
fi-cfl-s total:289 pass:222 dwarn:35 dfail:0 fail:0 skip:32 time:537s
fi-cnl-y total:289 pass:257 dwarn:0 dfail:0 fail:5 skip:27 time:639s
fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:412s
fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:566s
fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:425s
fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:402s
fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:432s
fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:487s
fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:458s
fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:474s
fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:577s
fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:592s
fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:539s
fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:450s
fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:748s
fi-skl-6770hq total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:490s
fi-skl-gvtdvm total:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:475s
fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:570s
fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:421s
f4eb3c100b0bd3e63af7f2083e3d4b1e0cd4fa7d drm-tip: 2017y-09m-25d-19h-36m-33s UTC integration manifest
e930c660773d drm/i915/edp: Be less aggressive about changing link config on eDP
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5810/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* ✓ Fi.CI.IGT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
` (8 preceding siblings ...)
2017-09-25 23:12 ` ✓ Fi.CI.BAT: success " Patchwork
@ 2017-09-26 4:12 ` Patchwork
9 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-09-26 4:12 UTC (permalink / raw)
To: Jim Bride; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/edp: Be less aggressive about changing link config on eDP (rev4)
URL : https://patchwork.freedesktop.org/series/28588/
State : success
== Summary ==
Test kms_setmode:
Subgroup basic:
fail -> PASS (shard-hsw) fdo#99912
Test perf:
Subgroup blocking:
fail -> PASS (shard-hsw) fdo#102252 +1
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
shard-hsw total:2429 pass:1325 dwarn:5 dfail:0 fail:16 skip:1083 time:9901s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5810/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-09-19 19:55 ` Rodrigo Vivi
2017-09-19 21:20 ` Jim Bride
@ 2017-09-27 12:23 ` Mika Kahola
2017-09-28 0:25 ` Rodrigo Vivi
1 sibling, 1 reply; 22+ messages in thread
From: Mika Kahola @ 2017-09-27 12:23 UTC (permalink / raw)
To: Rodrigo Vivi, Manasi Navare; +Cc: Jani Nikula, intel-gfx, Paulo Zanoni
On Tue, 2017-09-19 at 12:55 -0700, Rodrigo Vivi wrote:
> On Fri, Sep 15, 2017 at 06:19:12PM +0000, Manasi Navare wrote:
> >
> > The patch looks good for eDP link training optimizations.
> >
> > Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
> I haven't merged this patch yet because I'd like an Ack from Jani.
>
> Also I'd like to hear from Mika if he believes it is safe or not.
>
> On his revert commit he wrote:
> "It has been found out that in some HW combination the DisplayPort
> fast link training feature caused screen flickering. Let's revert
> this feature for now until we can ensure that the feature works for
> all platforms."
At the time of this revert there were quite a few bug reports of
flickering. The community felt that this "fast link training" was to
blame for flickering issues and therefore we decided to revert that.
However, it turned out later on that this revert didn't solve the
flickering issues. Flickering was gone once watermark work landed.
Therefore, I feel that this feature is safe to re-enable.
>
> I don't want to merge this patch to fix a feature that is disabled
> by default with the risk of bringing flickerings back.
>
> But even if we decide to go ahead and merge I believe we need to
> resend the test and collect a full round of CI that now runs
> all IGT tests.
>
> Thanks,
> Rodrigo.
>
>
> >
> >
> > Manasi
> >
> > On Tue, Aug 22, 2017 at 09:34:46AM -0700, Jim Bride wrote:
> > >
> > > This set of changes has some history to them. There were several
> > > attempts
> > > to add what was called "fast link training" to i915, which
> > > actually wasn't
> > > fast link training as per the DP spec. These changes were:
> > >
> > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > >
> > > which were eventually hand-reverted by:
> > >
> > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link
> > > training
> > > feature")
> > >
> > > in kernel 4.7-rc4. The eDP pieces of the above revert, however,
> > > had some
> > > very bad side-effects on PSR functionality on Skylake. The issue
> > > at
> > > hand is that when PSR exits i915 briefly emits TP1 followed by
> > > TP2/3
> > > (depending on the original link configuration) in order to
> > > quickly get
> > > the source and sink back in synchronization across the link
> > > before handing
> > > control back to the i915. There's an assumption that none of the
> > > link
> > > configuration information has changed (and thus it's still valid)
> > > since the
> > > last full link training operation. The revert above was
> > > identified via a
> > > bisect as the cause of some of Skylake's PSR woes. This patch,
> > > largely
> > > based on commit 4e96c97742f4 ("drm/i915: eDP link training
> > > optimization")
> > > puts the eDP portions of this patch back in place. None of the
> > > flickering
> > > issues that spurred the revert have been seen, and I suspect the
> > > real
> > > culprits here were addressed by some of the recent link training
> > > changes
> > > that Manasi has implemented, and PSR on Skylake is definitely
> > > more happy
> > > with these changes in-place.
> > >
> > > v2 and v3: Rebase
> > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > reading. (Chris)
> > > * Rebase
> > > v5: * Checkpatch cleanup
> > > * Rebase
> > > v6: * is_edp() => intel_dp_is_edp()
> > > * rebase
> > > v7: * Remove extraneous is_edp() prototype (Rodrigo)
> > >
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link
> > > training feature")
> > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 2 ++
> > > drivers/gpu/drm/i915/intel_dp_link_training.c | 15
> > > ++++++++++++++-
> > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > 3 files changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index e385658..38bc7e0 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector
> > > *intel_connector)
> > > intel_dp->max_link_rate =
> > > intel_dp_max_common_rate(intel_dp);
> > >
> > > intel_dp->reset_link_params = false;
> > > + intel_dp->train_set_valid = false;
> > > }
> > >
> > > intel_dp_print_rates(intel_dp);
> > > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct
> > > intel_digital_port *intel_dig_port,
> > > intel_dp_set_source_rates(intel_dp);
> > >
> > > intel_dp->reset_link_params = true;
> > > + intel_dp->train_set_valid = false;
> > > intel_dp->pps_pipe = INVALID_PIPE;
> > > intel_dp->active_pipe = INVALID_PIPE;
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > index 05907fa..79fe369 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > @@ -94,7 +94,8 @@ static bool
> > > intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > > uint8_t dp_train_pat)
> > > {
> > > - memset(intel_dp->train_set, 0, sizeof(intel_dp-
> > > >train_set));
> > > + if (!intel_dp->train_set_valid)
> > > + memset(intel_dp->train_set, 0, sizeof(intel_dp-
> > > >train_set));
> > > intel_dp_set_signal_levels(intel_dp);
> > > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > > }
> > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct
> > > intel_dp *intel_dp)
> > > DP_TRAINING_PATTERN_1 |
> > > DP_LINK_SCRAMBLING_DISABL
> > > E)) {
> > > DRM_ERROR("failed to enable link training\n");
> > > + intel_dp->train_set_valid = false;
> > > return false;
> > > }
> > >
> > > + /*
> > > + * The initial set of link parameters are set by this
> > > point, so go
> > > + * ahead and set intel_dp->train_set_valid to false in
> > > case any of
> > > + * the succeeding steps fail. It will be set back to
> > > true if we were
> > > + * able to achieve clock recovery in the specified
> > > configuration.
> > > + */
> > > + intel_dp->train_set_valid = false;
> > > +
> > > voltage_tries = 1;
> > > max_vswing_tries = 0;
> > > for (;;) {
> > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct
> > > intel_dp *intel_dp)
> > >
> > > if (drm_dp_clock_recovery_ok(link_status,
> > > intel_dp->lane_count)) {
> > > DRM_DEBUG_KMS("clock recovery OK\n");
> > > + intel_dp->train_set_valid =
> > > intel_dp_is_edp(intel_dp);
> > > return true;
> > > }
> > >
> > > @@ -256,6 +267,7 @@
> > > intel_dp_link_training_channel_equalization(struct intel_dp
> > > *intel_dp)
> > > training_pattern |
> > > DP_LINK_SCRAMBLING_DISABLE)
> > > ) {
> > > DRM_ERROR("failed to start channel
> > > equalization\n");
> > > + intel_dp->train_set_valid = false;
> > > return false;
> > > }
> > >
> > > @@ -296,6 +308,7 @@
> > > intel_dp_link_training_channel_equalization(struct intel_dp
> > > *intel_dp)
> > > /* Try 5 times, else fail and try at lower BW */
> > > if (tries == 5) {
> > > intel_dp_dump_link_status(link_status);
> > > + intel_dp->train_set_valid = false;
> > > DRM_DEBUG_KMS("Channel equalization failed 5
> > > times\n");
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 2940d39..f4354ec 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -995,6 +995,7 @@ struct intel_dp {
> > > struct drm_dp_aux aux;
> > > enum intel_display_power_domain aux_power_domain;
> > > uint8_t train_set[4];
> > > + bool train_set_valid;
> > > int panel_power_up_delay;
> > > int panel_power_down_delay;
> > > int panel_power_cycle_delay;
--
Mika Kahola - Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP
2017-09-27 12:23 ` Mika Kahola
@ 2017-09-28 0:25 ` Rodrigo Vivi
0 siblings, 0 replies; 22+ messages in thread
From: Rodrigo Vivi @ 2017-09-28 0:25 UTC (permalink / raw)
To: Mika Kahola; +Cc: Jani Nikula, intel-gfx, Paulo Zanoni
On Wed, Sep 27, 2017 at 12:23:32PM +0000, Mika Kahola wrote:
> On Tue, 2017-09-19 at 12:55 -0700, Rodrigo Vivi wrote:
> > On Fri, Sep 15, 2017 at 06:19:12PM +0000, Manasi Navare wrote:
> > >
> > > The patch looks good for eDP link training optimizations.
> > >
> > > Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
> > I haven't merged this patch yet because I'd like an Ack from Jani.
> >
> > Also I'd like to hear from Mika if he believes it is safe or not.
> >
> > On his revert commit he wrote:
> > "It has been found out that in some HW combination the DisplayPort
> > fast link training feature caused screen flickering. Let's revert
> > this feature for now until we can ensure that the feature works for
> > all platforms."
> At the time of this revert there were quite a few bug reports of
> flickering. The community felt that this "fast link training" was to
> blame for flickering issues and therefore we decided to revert that.
> However, it turned out later on that this revert didn't solve the
> flickering issues. Flickering was gone once watermark work landed.
I know this feeling... like PSR blamed for VGA flickers hehe
>
> Therefore, I feel that this feature is safe to re-enable.
Jani, Ack?
>
> >
> > I don't want to merge this patch to fix a feature that is disabled
> > by default with the risk of bringing flickerings back.
> >
> > But even if we decide to go ahead and merge I believe we need to
> > resend the test and collect a full round of CI that now runs
> > all IGT tests.
> >
> > Thanks,
> > Rodrigo.
> >
> >
> > >
> > >
> > > Manasi
> > >
> > > On Tue, Aug 22, 2017 at 09:34:46AM -0700, Jim Bride wrote:
> > > >
> > > > This set of changes has some history to them. There were several
> > > > attempts
> > > > to add what was called "fast link training" to i915, which
> > > > actually wasn't
> > > > fast link training as per the DP spec. These changes were:
> > > >
> > > > commit 5fa836a9d859 ("drm/i915: DP link training optimization")
> > > > commit 4e96c97742f4 ("drm/i915: eDP link training optimization")
> > > >
> > > > which were eventually hand-reverted by:
> > > >
> > > > commit 34511dce4b35 ("drm/i915: Revert DisplayPort fast link
> > > > training
> > > > feature")
> > > >
> > > > in kernel 4.7-rc4. The eDP pieces of the above revert, however,
> > > > had some
> > > > very bad side-effects on PSR functionality on Skylake. The issue
> > > > at
> > > > hand is that when PSR exits i915 briefly emits TP1 followed by
> > > > TP2/3
> > > > (depending on the original link configuration) in order to
> > > > quickly get
> > > > the source and sink back in synchronization across the link
> > > > before handing
> > > > control back to the i915. There's an assumption that none of the
> > > > link
> > > > configuration information has changed (and thus it's still valid)
> > > > since the
> > > > last full link training operation. The revert above was
> > > > identified via a
> > > > bisect as the cause of some of Skylake's PSR woes. This patch,
> > > > largely
> > > > based on commit 4e96c97742f4 ("drm/i915: eDP link training
> > > > optimization")
> > > > puts the eDP portions of this patch back in place. None of the
> > > > flickering
> > > > issues that spurred the revert have been seen, and I suspect the
> > > > real
> > > > culprits here were addressed by some of the recent link training
> > > > changes
> > > > that Manasi has implemented, and PSR on Skylake is definitely
> > > > more happy
> > > > with these changes in-place.
> > > >
> > > > v2 and v3: Rebase
> > > > v4: * Clean up accesses to train_set_valid a bit for easier
> > > > reading. (Chris)
> > > > * Rebase
> > > > v5: * Checkpatch cleanup
> > > > * Rebase
> > > > v6: * is_edp() => intel_dp_is_edp()
> > > > * rebase
> > > > v7: * Remove extraneous is_edp() prototype (Rodrigo)
> > > >
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > > Cc: Manasi D Navare <manasi.d.navare@intel.com>
> > > > Cc: Mika Kahola <mika.kahola@intel.com>
> > > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > > Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link
> > > > training feature")
> > > > Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 2 ++
> > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 15
> > > > ++++++++++++++-
> > > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > > 3 files changed, 17 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index e385658..38bc7e0 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -4750,6 +4750,7 @@ intel_dp_long_pulse(struct intel_connector
> > > > *intel_connector)
> > > > intel_dp->max_link_rate =
> > > > intel_dp_max_common_rate(intel_dp);
> > > >
> > > > intel_dp->reset_link_params = false;
> > > > + intel_dp->train_set_valid = false;
> > > > }
> > > >
> > > > intel_dp_print_rates(intel_dp);
> > > > @@ -6019,6 +6020,7 @@ intel_dp_init_connector(struct
> > > > intel_digital_port *intel_dig_port,
> > > > intel_dp_set_source_rates(intel_dp);
> > > >
> > > > intel_dp->reset_link_params = true;
> > > > + intel_dp->train_set_valid = false;
> > > > intel_dp->pps_pipe = INVALID_PIPE;
> > > > intel_dp->active_pipe = INVALID_PIPE;
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > index 05907fa..79fe369 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > @@ -94,7 +94,8 @@ static bool
> > > > intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > > > uint8_t dp_train_pat)
> > > > {
> > > > - memset(intel_dp->train_set, 0, sizeof(intel_dp-
> > > > >train_set));
> > > > + if (!intel_dp->train_set_valid)
> > > > + memset(intel_dp->train_set, 0, sizeof(intel_dp-
> > > > >train_set));
> > > > intel_dp_set_signal_levels(intel_dp);
> > > > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > > > }
> > > > @@ -162,9 +163,18 @@ intel_dp_link_training_clock_recovery(struct
> > > > intel_dp *intel_dp)
> > > > DP_TRAINING_PATTERN_1 |
> > > > DP_LINK_SCRAMBLING_DISABL
> > > > E)) {
> > > > DRM_ERROR("failed to enable link training\n");
> > > > + intel_dp->train_set_valid = false;
> > > > return false;
> > > > }
> > > >
> > > > + /*
> > > > + * The initial set of link parameters are set by this
> > > > point, so go
> > > > + * ahead and set intel_dp->train_set_valid to false in
> > > > case any of
> > > > + * the succeeding steps fail. It will be set back to
> > > > true if we were
> > > > + * able to achieve clock recovery in the specified
> > > > configuration.
> > > > + */
> > > > + intel_dp->train_set_valid = false;
> > > > +
> > > > voltage_tries = 1;
> > > > max_vswing_tries = 0;
> > > > for (;;) {
> > > > @@ -179,6 +189,7 @@ intel_dp_link_training_clock_recovery(struct
> > > > intel_dp *intel_dp)
> > > >
> > > > if (drm_dp_clock_recovery_ok(link_status,
> > > > intel_dp->lane_count)) {
> > > > DRM_DEBUG_KMS("clock recovery OK\n");
> > > > + intel_dp->train_set_valid =
> > > > intel_dp_is_edp(intel_dp);
> > > > return true;
> > > > }
> > > >
> > > > @@ -256,6 +267,7 @@
> > > > intel_dp_link_training_channel_equalization(struct intel_dp
> > > > *intel_dp)
> > > > training_pattern |
> > > > DP_LINK_SCRAMBLING_DISABLE)
> > > > ) {
> > > > DRM_ERROR("failed to start channel
> > > > equalization\n");
> > > > + intel_dp->train_set_valid = false;
> > > > return false;
> > > > }
> > > >
> > > > @@ -296,6 +308,7 @@
> > > > intel_dp_link_training_channel_equalization(struct intel_dp
> > > > *intel_dp)
> > > > /* Try 5 times, else fail and try at lower BW */
> > > > if (tries == 5) {
> > > > intel_dp_dump_link_status(link_status);
> > > > + intel_dp->train_set_valid = false;
> > > > DRM_DEBUG_KMS("Channel equalization failed 5
> > > > times\n");
> > > > }
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index 2940d39..f4354ec 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -995,6 +995,7 @@ struct intel_dp {
> > > > struct drm_dp_aux aux;
> > > > enum intel_display_power_domain aux_power_domain;
> > > > uint8_t train_set[4];
> > > > + bool train_set_valid;
> > > > int panel_power_up_delay;
> > > > int panel_power_down_delay;
> > > > int panel_power_cycle_delay;
> --
> Mika Kahola - Intel OTC
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2017-09-28 0:25 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-09 21:21 [PATCH v5] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
2017-08-09 21:40 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-08-16 22:13 ` [PATCH v5] " Manasi Navare
2017-08-17 17:50 ` Jim Bride
2017-08-17 19:20 ` Manasi Navare
2017-08-17 19:52 ` Manasi Navare
2017-08-17 19:54 ` Jim Bride
2017-08-21 21:03 ` [PATCH v6] " Jim Bride
2017-08-21 23:27 ` Vivi, Rodrigo
2017-08-22 16:32 ` Jim Bride
2017-08-21 21:24 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev2) Patchwork
2017-08-22 16:34 ` [PATCH v7] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
2017-09-15 18:19 ` Manasi Navare
2017-09-19 19:55 ` Rodrigo Vivi
2017-09-19 21:20 ` Jim Bride
2017-09-27 12:23 ` Mika Kahola
2017-09-28 0:25 ` Rodrigo Vivi
2017-08-22 17:36 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Be less aggressive about changing link config on eDP (rev3) Patchwork
2017-09-19 21:25 ` [PATCH v8] drm/i915/edp: Be less aggressive about changing link config on eDP Jim Bride
2017-09-19 22:02 ` ✗ Fi.CI.BAT: failure for drm/i915/edp: Be less aggressive about changing link config on eDP (rev4) Patchwork
2017-09-25 23:12 ` ✓ Fi.CI.BAT: success " Patchwork
2017-09-26 4:12 ` ✓ Fi.CI.IGT: " Patchwork
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).