All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: imre.deak@intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on LTTPR links
Date: Tue, 26 Apr 2022 17:23:57 +0300	[thread overview]
Message-ID: <87ilqvudmq.fsf@intel.com> (raw)
In-Reply-To: <YmfemiSW4j1Py5VQ@ideak-desk.fi.intel.com>

On Tue, 26 Apr 2022, Imre Deak <imre.deak@intel.com> wrote:
> On Tue, Apr 26, 2022 at 02:31:07PM +0300, Jani Nikula wrote:
>> On Tue, 26 Apr 2022, Imre Deak <imre.deak@intel.com> wrote:
>> > On Thu, Apr 14, 2022 at 01:49:54PM +0300, Jani Nikula wrote:
>> >> On Sat, 09 Apr 2022, Imre Deak <imre.deak@intel.com> wrote:
>> >> > Some ADLP DP link configuration at least with multiple LTTPRs expects
>> >> > the first DPCD access during the LTTPR/DPCD detection after hotplug to
>> >> > be a read from the LTTPR range starting with
>> >> > DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV. The side effect of
>> >> > this read is to put each LTTPR into the LTTPR transparent or LTTPR
>> >> > non-transparent mode.
>> >> >
>> >> > The lack of the above read may leave some of the LTTPRs in non-LTTPR
>> >> > mode, while other LTTPRs in LTTPR transparent or LTTPR non-transparent
>> >> > mode (for instance LTTPRs after system suspend/resume that kept their
>> >> > mode from before suspend). Due to the different AUX timeouts the
>> >> > different modes imply, the DPCD access from a non-LTTPR range will
>> >> > timeout and lead to an LTTPR generated hotplug towards the source (which
>> >> > the LTTPR firmware uses to account for buggy TypeC adapters with a long
>> >> > wake-up delay).
>> >> >
>> >> > To avoid the above AUX timeout and subsequent hotplug interrupt, make
>> >> > sure that the first DPCD access during detection is a read from an
>> >> > LTTPR register.
>> >> >
>> >> > VLK: SYSCROS-72939
>> >> >
>> >> > v2: Keep DPCD read-out working on non-LTTPR platforms.
>> >> >
>> >> > Signed-off-by: Imre Deak <imre.deak@intel.com>
>> >> 
>> >> I kinda dislike how complicated this looks for a diff so small. *shrug*.
>> >> Seems to do what it says on the box,
>> >
>> > I can have a better summary of what the patch does and why at the
>> > beginning of the commit message. Imo the details for the related LTTPR
>> > behavior are still useful for later reference; it's not too intuitive
>> > with the read side-effects for instance, neither it is well documented
>> > by the DP standard.
>> >
>> >> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>> >
>> > Thanks.
>> >
>> > I pushed the dependent
>> > d8bb92e70a43 ("drm/dp: Factor out a function to probe a DPCD address")
>> > patch to drm-misc-next. Could you help back merging it to
>> > drm-intel-next?
>> 
>> So this is going to need drm-misc-next -> drm-next pull request before I
>> can backmerge drm-next to drm-intel-next.
>
> Ok. AFAICS drm-next includes already the above commit.

Did the backmerge.

BR,
Jani.

>
>> BR,
>> Jani.
>> 
>> 
>> 
>> >
>> >> > ---
>> >> >  .../drm/i915/display/intel_dp_link_training.c | 33 ++++++++++---------
>> >> >  1 file changed, 17 insertions(+), 16 deletions(-)
>> >> >
>> >> > 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 26f9e2b748e40..9feaf1a589f38 100644
>> >> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> >> > @@ -82,19 +82,8 @@ static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp,
>> >> >  					    const u8 dpcd[DP_RECEIVER_CAP_SIZE])
>> >> >  {
>> >> >  	struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
>> >> > -	struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>> >> >  	int ret;
>> >> >  
>> >> > -	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 (DISPLAY_VER(i915) < 10 || IS_GEMINILAKE(i915))
>> >> > -		return false;
>> >> > -
>> >> >  	ret = drm_dp_read_lttpr_common_caps(&intel_dp->aux, dpcd,
>> >> >  					    intel_dp->lttpr_common_caps);
>> >> >  	if (ret < 0)
>> >> > @@ -197,13 +186,25 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp, const u8 dpcd[DP_RECEI
>> >> >   */
>> >> >  int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
>> >> >  {
>> >> > -	u8 dpcd[DP_RECEIVER_CAP_SIZE];
>> >> > -	int lttpr_count;
>> >> > +	struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> >> > +	int lttpr_count = 0;
>> >> >  
>> >> > -	if (drm_dp_read_dpcd_caps(&intel_dp->aux, dpcd))
>> >> > -		return -EIO;
>> >> > +	/*
>> >> > +	 * 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_dp_is_edp(intel_dp) &&
>> >> > +	    (DISPLAY_VER(i915) >= 10 && !IS_GEMINILAKE(i915))) {
>> >> > +		u8 dpcd[DP_RECEIVER_CAP_SIZE];
>> >> >  
>> >> > -	lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
>> >> > +		if (drm_dp_dpcd_probe(&intel_dp->aux, DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV))
>> >> > +			return -EIO;
>> >> > +
>> >> > +		if (drm_dp_read_dpcd_caps(&intel_dp->aux, dpcd))
>> >> > +			return -EIO;
>> >> > +
>> >> > +		lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
>> >> > +	}
>> >> >  
>> >> >  	/*
>> >> >  	 * The DPTX shall read the DPRX caps after LTTPR detection, so re-read
>> >> 
>> >> -- 
>> >> Jani Nikula, Intel Open Source Graphics Center
>> 
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-04-26 14:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08 17:21 [Intel-gfx] [PATCH v2 1/2] drm/dp: Factor out a function to probe a DPCD address Imre Deak
2022-04-08 17:21 ` Imre Deak
2022-04-08 17:21 ` [Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Add workaround for spurious AUX timeouts/hotplugs on LTTPR links Imre Deak
2022-04-08 22:46   ` [Intel-gfx] [PATCH v3 " Imre Deak
2022-04-14 10:49     ` Jani Nikula
2022-04-26  9:49       ` Imre Deak
2022-04-26 11:31         ` Jani Nikula
2022-04-26 11:59           ` Imre Deak
2022-04-26 14:23             ` Jani Nikula [this message]
2022-04-08 21:12 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/dp: Factor out a function to probe a DPCD address Patchwork
2022-04-08 21:43 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-04-08 22:47 ` [Intel-gfx] [v2, 1/2] " Almahallawy, Khaled
2022-04-08 22:47   ` [v2,1/2] " Almahallawy, Khaled
2022-04-08 23:02   ` [Intel-gfx] [v2, 1/2] " Imre Deak
2022-04-08 23:02     ` [v2,1/2] " Imre Deak
2022-04-08 23:22 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/dp: Factor out a function to probe a DPCD address (rev2) Patchwork
2022-04-08 23:24 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-04-08 23:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-09  1:17 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-04-11 13:25 ` [Intel-gfx] [PATCH v3 1/2] drm/dp: Factor out a function to probe a DPCD address Imre Deak
2022-04-11 13:25   ` Imre Deak
2022-04-14 10:30   ` [Intel-gfx] " Jani Nikula
2022-04-14 10:30     ` Jani Nikula
2022-04-11 17:02 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/2] drm/dp: Factor out a function to probe a DPCD address (rev3) Patchwork
2022-04-11 17:02 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-04-11 17:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-11 20:18 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-04-14 18:32   ` Imre Deak
2022-04-14 21:18     ` Vudum, Lakshminarayana
2022-04-14 20:13 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork

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=87ilqvudmq.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.