All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix modesetting in case of unexpected AUX timeouts
Date: Tue, 13 Apr 2021 20:12:37 +0300	[thread overview]
Message-ID: <YHXRBSsBkNXoPIFS@intel.com> (raw)
In-Reply-To: <20210412232413.2755054-1-imre.deak@intel.com>

On Tue, Apr 13, 2021 at 02:24:12AM +0300, Imre Deak wrote:
> In case AUX failures happen unexpectedly during a modeset, the driver
> should still complete the modeset. In particular the driver should
> perform the link training sequence steps even in case of an AUX failure,
> as this sequence also includes port initialization steps. Not doing that
> can leave the port/pipe in a broken state and lead for instance to a
> flip done timeout.
> 
> Fix this by continuing with link training (in a no-LTTPR mode) if the
> DPRX DPCD readout failed for some reason at the beginning of link
> training. After a successful connector detection we already have the
> DPCD read out and cached, so the failed repeated read for it should not
> cause a problem. Note that a partial AUX read could in theory partly
> overwrite the cached DPCD (and return error) but this overwrite should
> not happen if the returned values are corrupted (due to a timeout or
> some other IO error).
> 
> Kudos to Ville to root cause the problem.
> 
> Fixes: 7dffbdedb96a ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4")
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3308
> Cc: stable@vger.kernel.org # 5.11
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> ---
>  drivers/gpu/drm/i915/display/intel_dp_link_training.c | 3 ++-
>  1 file changed, 2 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 5e9c3c74310ca..cbcfb0c4c3708 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -882,7 +882,8 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp,
>  	int lttpr_count = intel_dp_init_lttpr_and_dprx_caps(intel_dp);
>  
>  	if (lttpr_count < 0)
> -		return;
> +		/* Still continue with enabling the port and link training. */
> +		lttpr_count = 0;
>  
>  	if (!intel_dp_link_train_all_phys(intel_dp, crtc_state, lttpr_count))
>  		intel_dp_schedule_fallback_link_training(intel_dp, crtc_state);
> -- 
> 2.27.0

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/2] drm/i915: Fix modesetting in case of unexpected AUX timeouts
Date: Tue, 13 Apr 2021 20:12:37 +0300	[thread overview]
Message-ID: <YHXRBSsBkNXoPIFS@intel.com> (raw)
In-Reply-To: <20210412232413.2755054-1-imre.deak@intel.com>

On Tue, Apr 13, 2021 at 02:24:12AM +0300, Imre Deak wrote:
> In case AUX failures happen unexpectedly during a modeset, the driver
> should still complete the modeset. In particular the driver should
> perform the link training sequence steps even in case of an AUX failure,
> as this sequence also includes port initialization steps. Not doing that
> can leave the port/pipe in a broken state and lead for instance to a
> flip done timeout.
> 
> Fix this by continuing with link training (in a no-LTTPR mode) if the
> DPRX DPCD readout failed for some reason at the beginning of link
> training. After a successful connector detection we already have the
> DPCD read out and cached, so the failed repeated read for it should not
> cause a problem. Note that a partial AUX read could in theory partly
> overwrite the cached DPCD (and return error) but this overwrite should
> not happen if the returned values are corrupted (due to a timeout or
> some other IO error).
> 
> Kudos to Ville to root cause the problem.
> 
> Fixes: 7dffbdedb96a ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4")
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3308
> Cc: stable@vger.kernel.org # 5.11
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Imre Deak <imre.deak@intel.com>

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> ---
>  drivers/gpu/drm/i915/display/intel_dp_link_training.c | 3 ++-
>  1 file changed, 2 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 5e9c3c74310ca..cbcfb0c4c3708 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -882,7 +882,8 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp,
>  	int lttpr_count = intel_dp_init_lttpr_and_dprx_caps(intel_dp);
>  
>  	if (lttpr_count < 0)
> -		return;
> +		/* Still continue with enabling the port and link training. */
> +		lttpr_count = 0;
>  
>  	if (!intel_dp_link_train_all_phys(intel_dp, crtc_state, lttpr_count))
>  		intel_dp_schedule_fallback_link_training(intel_dp, crtc_state);
> -- 
> 2.27.0

-- 
Ville Syrjälä
Intel

  parent reply	other threads:[~2021-04-13 17:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12 23:24 [Intel-gfx] [PATCH 1/2] drm/i915: Fix modesetting in case of unexpected AUX timeouts Imre Deak
2021-04-12 23:24 ` Imre Deak
2021-04-12 23:24 ` [Intel-gfx] [PATCH 2/2] drm/i915: Drop redundant address-of op before lttpr_common_caps array Imre Deak
2021-04-13 17:13   ` Ville Syrjälä
2021-04-12 23:48 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/2] drm/i915: Fix modesetting in case of unexpected AUX timeouts Patchwork
2021-04-13  0:11 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-04-13  1:29 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-04-13 17:12 ` Ville Syrjälä [this message]
2021-04-13 17:12   ` [PATCH 1/2] " Ville Syrjälä

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=YHXRBSsBkNXoPIFS@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@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.