From: "Almahallawy, Khaled" <khaled.almahallawy@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>,
"Deak, Imre" <imre.deak@intel.com>
Cc: "mail@bodograumann.de" <mail@bodograumann.de>,
"santiago.zarate@suse.com" <santiago.zarate@suse.com>,
"tiwai@suse.de" <tiwai@suse.de>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs
Date: Thu, 18 Mar 2021 22:04:54 +0000 [thread overview]
Message-ID: <e1e9f9ea76071af914b37352fc201d09f378a55b.camel@intel.com> (raw)
In-Reply-To: <20210318180645.GG4128033@ideak-desk.fi.intel.com>
On Thu, 2021-03-18 at 20:06 +0200, Imre Deak wrote:
> On Thu, Mar 18, 2021 at 07:49:13PM +0200, Imre Deak wrote:
> > On Thu, Mar 18, 2021 at 07:33:20PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 17, 2021 at 08:48:59PM +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).
> > >
> > > I'm pondering if we could reduce the timeout after having
> > > determined
> > > wherther LTTPRs are present or not? But maybe that wouldn't
> > > really speed
> > > up anything since we can't reduce the timeout until after
> > > detecting
> > > *something*. And once there is something there we shouldn't
> > > really get
> > > any more timeouts I guess. So probably a totally stupid idea.
> >
> > Right, if something is connected it would take anyway as much time
> > as it
> > takes for the sink to reply whether or not we decreased the
> > timeout.
> >
> > However if nothing is connected, we have the excessive timeout
> > Khaled
> > already noticed (160 * 4ms = 6.4 sec on ICL+). I think to improve
> > that
> > we could scale the total number of retries by making it
> > total_timeout/platform_specific_timeout (letting total_timeout=2sec
> > for
> > instance) or just changing the drm retry logic to be time based
> > instead
> > of the number of retries we use atm.
>
> Doh, reducing simply the HW timeouts would be enough to fix this.
What about Lyude's suggestion (
https://patchwork.freedesktop.org/patch/420369/#comment_756572)
to drop the retries in intel_dp_aux_xfer()
/* Must try at least 3 times according to DP spec */
for (try = 0; try < 5; try++) {
And use only the retries in drm_dpcd_access?
Thanks
Khaled
>
> > > Anyways, this seems about the only thing we can do given the
> > > limited
> > > hw capabilities.
> > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > > 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.
> > > >
> > > > v2: Add a comment about the g4x maximum timeout as well.
> > > > (Ville)
> > > >
> > > > Reported-by: Takashi Iwai <tiwai@suse.de>
> > > > Reported-and-tested-by: Santiago Zarate <
> > > > santiago.zarate@suse.com>
> > > > Reported-and-tested-by: Bodo Graumann <mail@bodograumann.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>
> > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++++++
> > > > .../gpu/drm/i915/display/intel_dp_link_training.c | 15
> > > > ++++++++++++---
> > > > 2 files changed, 19 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > > index eaebf123310a..10fe17b7280d 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 G4x-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..c0e25c75c105 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > @@ -82,6 +82,18 @@ static void
> > > > intel_dp_read_lttpr_phy_caps(struct intel_dp *intel_dp,
> > > >
> > > > static bool intel_dp_read_lttpr_common_caps(struct intel_dp
> > > > *intel_dp)
> > > > {
> > > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > +
> > > > + if (intel_dp_is_edp(intel_dp))
> > > > + return false;
> > > > +
> > > > + /*
> > > > + * 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 false;
> > > > +
> > > > if (drm_dp_read_lttpr_common_caps(&intel_dp->aux,
> > > > intel_dp-
> > > > >lttpr_common_caps) < 0) {
> > > > memset(intel_dp->lttpr_common_caps, 0,
> > > > @@ -127,9 +139,6 @@ int intel_dp_lttpr_init(struct intel_dp
> > > > *intel_dp)
> > > > bool ret;
> > > > int i;
> > > >
> > > > - if (intel_dp_is_edp(intel_dp))
> > > > - return 0;
> > > > -
> > > > ret = intel_dp_read_lttpr_common_caps(intel_dp);
> > > > if (!ret)
> > > > return 0;
> > > > --
> > > > 2.25.1
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-03-18 22:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 18:48 [Intel-gfx] [PATCH v2 0/3] drm/i915: Fix DP LTTPR link training mode initialization Imre Deak
2021-03-17 18:48 ` [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs Imre Deak
2021-03-18 17:33 ` Ville Syrjälä
2021-03-18 17:49 ` Imre Deak
2021-03-18 18:06 ` Imre Deak
2021-03-18 22:04 ` Almahallawy, Khaled [this message]
2021-03-18 23:17 ` Imre Deak
2021-03-19 17:25 ` Lyude Paul
2021-03-19 17:29 ` Imre Deak
2021-03-19 20:44 ` Lyude Paul
2021-03-19 21:07 ` Imre Deak
2021-03-20 7:15 ` Imre Deak
2021-03-20 7:40 ` Almahallawy, Khaled
2021-03-20 7:45 ` Imre Deak
2021-03-17 18:49 ` [Intel-gfx] [PATCH v2 2/3] drm/i915: Disable LTTPR support when the DPCD rev < 1.4 Imre Deak
2021-03-17 19:01 ` Imre Deak
2021-03-18 17:57 ` Ville Syrjälä
2021-03-18 18:05 ` Imre Deak
2021-03-17 18:49 ` [Intel-gfx] [PATCH v2 3/3] drm/i915: Disable LTTPR support when the LTTPR " Imre Deak
2021-03-18 18:00 ` Ville Syrjälä
2021-03-18 18:09 ` Imre Deak
2021-03-17 20:26 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix DP LTTPR link training mode initialization (rev2) Patchwork
2021-03-17 21:01 ` [Intel-gfx] drm/i915: Fix DP LTTPR link training mode initialization Zephaniah E. Loss-Cutler-Hull
2021-03-17 22:34 ` [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix DP LTTPR link training mode initialization (rev2) Patchwork
2021-03-19 11:16 ` Imre Deak
2021-03-22 8:34 ` [Intel-gfx] drm/i915: Fix DP LTTPR link training mode initialization Zephaniah E. Loss-Cutler-Hull
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e1e9f9ea76071af914b37352fc201d09f378a55b.camel@intel.com \
--to=khaled.almahallawy@intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mail@bodograumann.de \
--cc=santiago.zarate@suse.com \
--cc=stable@vger.kernel.org \
--cc=tiwai@suse.de \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox