All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Imre Deak <imre.deak@intel.com>,
	intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: stable@vger.kernel.org
Subject: Re: [PATCH 1/2] drm/i915/dp: Fix error handling during 128b/132b link training
Date: Tue, 18 Feb 2025 14:51:21 +0200	[thread overview]
Message-ID: <875xl7o1py.fsf@intel.com> (raw)
In-Reply-To: <20250217223828.1166093-2-imre.deak@intel.com>

On Tue, 18 Feb 2025, Imre Deak <imre.deak@intel.com> wrote:
> At the end of a 128b/132b link training sequence, the HW expects the
> transcoder training pattern to be set to TPS2 and from that to normal
> mode (disabling the training pattern). Transitioning from TPS1 directly
> to normal mode leaves the transcoder in a stuck state, resulting in
> page-flip timeouts later in the modeset sequence.
>
> Atm, in case of a failure during link training, the transcoder may be
> still set to output the TPS1 pattern. Later the transcoder is then set
> from TPS1 directly to normal mode in intel_dp_stop_link_train(), leading
> to modeset failures later as described above. Fix this by setting the
> training patter to TPS2, if the link training failed at any point.
>
> Cc: stable@vger.kernel.org # v5.18+
> Cc: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Imre Deak <imre.deak@intel.com>

No bspec link for this?

Acked-by: Jani Nikula <jani.nikula@intel.com>

> ---
>  .../gpu/drm/i915/display/intel_dp_link_training.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> 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 3cc06c916017d..11953b03bb6aa 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -1563,7 +1563,7 @@ intel_dp_128b132b_link_train(struct intel_dp *intel_dp,
>  
>  	if (wait_for(intel_dp_128b132b_intra_hop(intel_dp, crtc_state) == 0, 500)) {
>  		lt_err(intel_dp, DP_PHY_DPRX, "128b/132b intra-hop not clear\n");
> -		return false;
> +		goto out;
>  	}
>  
>  	if (intel_dp_128b132b_lane_eq(intel_dp, crtc_state) &&
> @@ -1575,6 +1575,19 @@ intel_dp_128b132b_link_train(struct intel_dp *intel_dp,
>  	       passed ? "passed" : "failed",
>  	       crtc_state->port_clock, crtc_state->lane_count);
>  
> +out:
> +	/*
> +	 * Ensure that the training pattern does get set to TPS2 even in case
> +	 * of a failure, as is the case at the end of a passing link training
> +	 * and what is expected by the transcoder. Leaving TPS1 set (and
> +	 * disabling the link train mode in DP_TP_CTL later from TPS1 directly)
> +	 * would result in a stuck transcoder HW state and flip-done timeouts
> +	 * later in the modeset sequence.
> +	 */
> +	if (!passed)
> +		intel_dp_program_link_training_pattern(intel_dp, crtc_state,
> +						       DP_PHY_DPRX, DP_TRAINING_PATTERN_2);
> +
>  	return passed;
>  }

-- 
Jani Nikula, Intel

  reply	other threads:[~2025-02-18 12:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-17 22:38 [PATCH 0/2] drm/i915/dp: Fix 128b/132b modeset issues Imre Deak
2025-02-17 22:38 ` [PATCH 1/2] drm/i915/dp: Fix error handling during 128b/132b link training Imre Deak
2025-02-18 12:51   ` Jani Nikula [this message]
2025-02-18 13:06     ` Imre Deak
2025-02-17 22:38 ` [PATCH 2/2] drm/i915/dp: Fix disabling the transcoder function in 128b/132b mode Imre Deak
2025-02-18 13:03   ` Jani Nikula
2025-02-18 13:15     ` Imre Deak
2025-02-17 22:43 ` ✓ CI.Patch_applied: success for drm/i915/dp: Fix 128b/132b modeset issues Patchwork
2025-02-17 22:43 ` ✗ CI.checkpatch: warning " Patchwork
2025-02-17 22:44 ` ✓ CI.KUnit: success " Patchwork
2025-02-17 23:01 ` ✓ CI.Build: " Patchwork
2025-02-17 23:01 ` ✗ Fi.CI.CHECKPATCH: warning " Patchwork
2025-02-17 23:01 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-02-17 23:03 ` ✓ CI.Hooks: success " Patchwork
2025-02-17 23:04 ` ✓ CI.checksparse: " Patchwork
2025-02-17 23:18 ` ✓ i915.CI.BAT: " Patchwork
2025-02-17 23:24 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-18  4:36 ` ✗ i915.CI.Full: failure " Patchwork
2025-02-19 13:21   ` Imre Deak
2025-02-19 16:27     ` Jani Nikula
2025-02-19 17:09       ` Rodrigo Vivi
2025-02-19 17:49         ` Imre Deak
2025-02-18 16:27 ` ✗ Xe.CI.Full: " 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=875xl7o1py.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=stable@vger.kernel.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.