The spec requires to use at least 3.2ms for the AUX timeout period if there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming spec update makes this more specific, by requiring a 3.2ms minimum timeout period for the LTTPR detection reading the 0xF0000-0xF0007 range (3.6.5.1).
Accordingly disable LTTPR detection until GLK, where the maximum timeout we can set is only 1.6ms.
Link training in the non-transparent mode is known to fail at least on some SKL systems with a WD19 dock on the link, which exposes an LTTPR (see the References below). While this could have different reasons besides the too short AUX timeout used, not detecting LTTPRs (and so not using the non-transparent LT mode) fixes link training on these systems.
While at it add a code comment about the platform specific maximum timeout values.
Reported-by: Takashi Iwai tiwai@suse.de References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166 Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: stable@vger.kernel.org # v5.11 Cc: Takashi Iwai tiwai@suse.de Signed-off-by: Imre Deak imre.deak@intel.com --- drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++++++ drivers/gpu/drm/i915/display/intel_dp_link_training.c | 8 ++++++++ 2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c b/drivers/gpu/drm/i915/display/intel_dp_aux.c index eaebf123310a..b581e8acce07 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp *intel_dp, else precharge = 5;
+ /* Max timeout value on ILK-BDW: 1.6ms */ if (IS_BROADWELL(dev_priv)) timeout = DP_AUX_CH_CTL_TIME_OUT_600us; else @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct intel_dp *intel_dp, enum phy phy = intel_port_to_phy(i915, dig_port->base.port); u32 ret;
+ /* + * Max timeout values: + * SKL-GLK: 1.6ms + * CNL: 3.2ms + * ICL+: 4ms + */ ret = DP_AUX_CH_CTL_SEND_BUSY | DP_AUX_CH_CTL_DONE | DP_AUX_CH_CTL_INTERRUPT | diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 19ba7c7cbaab..de6d70a29b47 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -123,10 +123,18 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp *intel_dp, bool enable) */ int intel_dp_lttpr_init(struct intel_dp *intel_dp) { + struct drm_i915_private *i915 = dp_to_i915(intel_dp); int lttpr_count; bool ret; int i;
+ /* + * Detecting LTTPRs must be avoided on platforms with an AUX timeout + * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1). + */ + if (INTEL_GEN(i915) < 10) + return 0; + if (intel_dp_is_edp(intel_dp)) return 0;
On Tue, 16 Mar 2021 17:54:26 +0100, Imre Deak wrote:
The spec requires to use at least 3.2ms for the AUX timeout period if there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming spec update makes this more specific, by requiring a 3.2ms minimum timeout period for the LTTPR detection reading the 0xF0000-0xF0007 range (3.6.5.1).
Accordingly disable LTTPR detection until GLK, where the maximum timeout we can set is only 1.6ms.
Link training in the non-transparent mode is known to fail at least on some SKL systems with a WD19 dock on the link, which exposes an LTTPR (see the References below). While this could have different reasons besides the too short AUX timeout used, not detecting LTTPRs (and so not using the non-transparent LT mode) fixes link training on these systems.
While at it add a code comment about the platform specific maximum timeout values.
Reported-by: Takashi Iwai tiwai@suse.de References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166 Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: stable@vger.kernel.org # v5.11 Cc: Takashi Iwai tiwai@suse.de Signed-off-by: Imre Deak imre.deak@intel.com
Thanks! I'm now building a test kernel and ask people testing it. https://apibugzilla.suse.com/show_bug.cgi?id=1183294
BTW, the patch isn't applicable cleanly to 5.11.x kernel as is. The file intel_dp_aux.c needs to be changed to intel_dp.c. Hopefully Greg can manage the file rename.
Takashi
drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++++++ drivers/gpu/drm/i915/display/intel_dp_link_training.c | 8 ++++++++ 2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c b/drivers/gpu/drm/i915/display/intel_dp_aux.c index eaebf123310a..b581e8acce07 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp *intel_dp, else precharge = 5;
- /* Max timeout value on ILK-BDW: 1.6ms */ if (IS_BROADWELL(dev_priv)) timeout = DP_AUX_CH_CTL_TIME_OUT_600us; else
@@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct intel_dp *intel_dp, enum phy phy = intel_port_to_phy(i915, dig_port->base.port); u32 ret;
- /*
* Max timeout values:* SKL-GLK: 1.6ms* CNL: 3.2ms* ICL+: 4ms*/diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 19ba7c7cbaab..de6d70a29b47 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -123,10 +123,18 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp *intel_dp, bool enable) */ int intel_dp_lttpr_init(struct intel_dp *intel_dp) {
- struct drm_i915_private *i915 = dp_to_i915(intel_dp); int lttpr_count; bool ret; int i;
- /*
* Detecting LTTPRs must be avoided on platforms with an AUX timeout* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).*/- if (INTEL_GEN(i915) < 10)
return 0;- if (intel_dp_is_edp(intel_dp)) return 0;
2.25.1
Tested-By: Santiago Zarate santiago.zarate@suse.com
Tested with kernel built in obs, see https://apibugzilla.suse.com/show_bug.cgi?id=1183294#c19 for more details
Regards,
Santiago
On Tue, 2021-03-16 at 18:54 +0200, Imre Deak wrote:
The spec requires to use at least 3.2ms for the AUX timeout period if there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming spec update makes this more specific, by requiring a 3.2ms minimum timeout period for the LTTPR detection reading the 0xF0000-0xF0007 range (3.6.5.1).
Accordingly disable LTTPR detection until GLK, where the maximum timeout we can set is only 1.6ms.
Link training in the non-transparent mode is known to fail at least on some SKL systems with a WD19 dock on the link, which exposes an LTTPR (see the References below). While this could have different reasons besides the too short AUX timeout used, not detecting LTTPRs (and so not using the non-transparent LT mode) fixes link training on these systems.
While at it add a code comment about the platform specific maximum timeout values.
Reported-by: Takashi Iwai tiwai@suse.de References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166 Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: stable@vger.kernel.org # v5.11 Cc: Takashi Iwai tiwai@suse.de Signed-off-by: Imre Deak imre.deak@intel.com
drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++++++ drivers/gpu/drm/i915/display/intel_dp_link_training.c | 8 ++++++++ 2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c b/drivers/gpu/drm/i915/display/intel_dp_aux.c index eaebf123310a..b581e8acce07 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp *intel_dp, else precharge = 5; + /* Max timeout value on ILK-BDW: 1.6ms */ if (IS_BROADWELL(dev_priv)) timeout = DP_AUX_CH_CTL_TIME_OUT_600us; else @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct intel_dp *intel_dp, enum phy phy = intel_port_to_phy(i915, dig_port->base.port); u32 ret; + /* + * Max timeout values: + * SKL-GLK: 1.6ms + * CNL: 3.2ms + * ICL+: 4ms + */ ret = DP_AUX_CH_CTL_SEND_BUSY | DP_AUX_CH_CTL_DONE | DP_AUX_CH_CTL_INTERRUPT | diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 19ba7c7cbaab..de6d70a29b47 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -123,10 +123,18 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp *intel_dp, bool enable) */ int intel_dp_lttpr_init(struct intel_dp *intel_dp) { + struct drm_i915_private *i915 = dp_to_i915(intel_dp); int lttpr_count; bool ret; int i; + /* + * Detecting LTTPRs must be avoided on platforms with an AUX timeout + * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1). + */ + if (INTEL_GEN(i915) < 10) + return 0;
if (intel_dp_is_edp(intel_dp)) return 0;
On Tue, Mar 16, 2021 at 06:54:26PM +0200, Imre Deak wrote:
The spec requires to use at least 3.2ms for the AUX timeout period if there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming spec update makes this more specific, by requiring a 3.2ms minimum timeout period for the LTTPR detection reading the 0xF0000-0xF0007 range (3.6.5.1).
Accordingly disable LTTPR detection until GLK, where the maximum timeout we can set is only 1.6ms.
Link training in the non-transparent mode is known to fail at least on some SKL systems with a WD19 dock on the link, which exposes an LTTPR (see the References below). While this could have different reasons besides the too short AUX timeout used, not detecting LTTPRs (and so not using the non-transparent LT mode) fixes link training on these systems.
While at it add a code comment about the platform specific maximum timeout values.
Reported-by: Takashi Iwai tiwai@suse.de References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166 Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: stable@vger.kernel.org # v5.11 Cc: Takashi Iwai tiwai@suse.de Signed-off-by: Imre Deak imre.deak@intel.com
drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++++++ drivers/gpu/drm/i915/display/intel_dp_link_training.c | 8 ++++++++ 2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c b/drivers/gpu/drm/i915/display/intel_dp_aux.c index eaebf123310a..b581e8acce07 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp *intel_dp, else precharge = 5;
- /* Max timeout value on ILK-BDW: 1.6ms */
also g4x
if (IS_BROADWELL(dev_priv)) timeout = DP_AUX_CH_CTL_TIME_OUT_600us; else @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct intel_dp *intel_dp, enum phy phy = intel_port_to_phy(i915, dig_port->base.port); u32 ret;
- /*
* Max timeout values:* SKL-GLK: 1.6ms* CNL: 3.2ms* ICL+: 4ms*/diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 19ba7c7cbaab..de6d70a29b47 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -123,10 +123,18 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp *intel_dp, bool enable) */ int intel_dp_lttpr_init(struct intel_dp *intel_dp) {
- struct drm_i915_private *i915 = dp_to_i915(intel_dp); int lttpr_count; bool ret; int i;
- /*
* Detecting LTTPRs must be avoided on platforms with an AUX timeout* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).*/- if (INTEL_GEN(i915) < 10)
return 0;
I don't understand how detecting the LTTPR affects this? The LTTPRs will still snoop stuff and do their hidden magic even if we don't know they're there. How does leaving them in transparent mode speed up whatever they do?
Also, maybe we should just bump the timeout to the max on all platforms?
- if (intel_dp_is_edp(intel_dp)) return 0;
2.25.1
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Mar 17, 2021 at 04:06:07PM +0200, Ville Syrjälä wrote:
On Tue, Mar 16, 2021 at 06:54:26PM +0200, Imre Deak wrote:
The spec requires to use at least 3.2ms for the AUX timeout period if there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming spec update makes this more specific, by requiring a 3.2ms minimum timeout period for the LTTPR detection reading the 0xF0000-0xF0007 range (3.6.5.1).
Accordingly disable LTTPR detection until GLK, where the maximum timeout we can set is only 1.6ms.
Link training in the non-transparent mode is known to fail at least on some SKL systems with a WD19 dock on the link, which exposes an LTTPR (see the References below). While this could have different reasons besides the too short AUX timeout used, not detecting LTTPRs (and so not using the non-transparent LT mode) fixes link training on these systems.
While at it add a code comment about the platform specific maximum timeout values.
Reported-by: Takashi Iwai tiwai@suse.de References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166 Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: stable@vger.kernel.org # v5.11 Cc: Takashi Iwai tiwai@suse.de Signed-off-by: Imre Deak imre.deak@intel.com
drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++++++ drivers/gpu/drm/i915/display/intel_dp_link_training.c | 8 ++++++++ 2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c b/drivers/gpu/drm/i915/display/intel_dp_aux.c index eaebf123310a..b581e8acce07 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp *intel_dp, else precharge = 5;
- /* Max timeout value on ILK-BDW: 1.6ms */
also g4x
Ok, will add it.
if (IS_BROADWELL(dev_priv)) timeout = DP_AUX_CH_CTL_TIME_OUT_600us; else @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct intel_dp *intel_dp, enum phy phy = intel_port_to_phy(i915, dig_port->base.port); u32 ret;
- /*
* Max timeout values:* SKL-GLK: 1.6ms* CNL: 3.2ms* ICL+: 4ms*/diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 19ba7c7cbaab..de6d70a29b47 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -123,10 +123,18 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp *intel_dp, bool enable) */ int intel_dp_lttpr_init(struct intel_dp *intel_dp) {
- struct drm_i915_private *i915 = dp_to_i915(intel_dp); int lttpr_count; bool ret; int i;
- /*
* Detecting LTTPRs must be avoided on platforms with an AUX timeout* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).*/- if (INTEL_GEN(i915) < 10)
return 0;I don't understand how detecting the LTTPR affects this? The LTTPRs will still snoop stuff and do their hidden magic even if we don't know they're there. How does leaving them in transparent mode speed up whatever they do?
After an LTTPR detection, the DPTX reading the 0xF0000-0xF0007 range, LTTPRs will be either in transparent or non-transparent mode. In these modes the spec requires the LTTPRs not to send DEFERs and use a 3.2ms timeout scheme. I'm not sure about the exact details for the rational on this (afaiu it's to avoid a retransmission loop or corruption of transmit/reply packets), but the point is that LTTPRs will switch to this mode.
W/o DEFERs and a timeout less than 3.2ms the DPTX can corrupt reply packets and so miss the ACK (or just simply miss reply because stopping to listen too early).
Without doing an LTTPR detection, the LTTPRs will remain in no-LTTPR mode (so there are 3 different modes), where the LTTPRs will send DEFERs to their closest DPTX PHY and use the original 400us timeout scheme. This avoids the above transmit/reply packet clash.
Also, maybe we should just bump the timeout to the max on all platforms?
Yes, I suppose we could do this as a follow-up.
- if (intel_dp_is_edp(intel_dp)) return 0;
2.25.1
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- Ville Syrjälä Intel
linux-stable-mirror@lists.linaro.org
-
Imre Deak -
Santiago Zarate -
Takashi Iwai -
Ville Syrjälä