All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, Jani Nikula <jani.nikula@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix DP clock recovery "voltage_tries" handling
Date: Fri, 1 Oct 2021 20:17:04 +0300	[thread overview]
Message-ID: <20211001171704.GA2577530@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <20211001160826.17080-1-ville.syrjala@linux.intel.com>

On Fri, Oct 01, 2021 at 07:08:26PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The DP spec says:
> "If the receiver keeps the same value in the ADJUST_REQUEST_LANEx_y
>  register(s) while the LANEx_CR_DONE bits remain unset, the transmitter
>  must loop four times with the same voltage swing. On the fifth time,
>  the transmitter must down-shift to the lower bit rate and must repeat
>  the CR-lock training sequence as described below."
> 
> Lets fix the code to follow that instead of terminating after five
> times of transmitting the same signal levels. The text in spec feels
> a little bit ambiguous still, but this is my best guess at its meaning.
> 
> As a bonus this also gets rid of the train_set[0] stuff which
> would not work for per-lane drive settings anyway.
> 
> Cc: Imre Deak <imre.deak@intel.com>
> CC: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Reviewed-by: Imre Deak <imre.deak@intel.com>

It's likely that the receiver is still trying new settings and didn't
abort yet, if it changes anything in the request.

> ---
>  .../drm/i915/display/intel_dp_link_training.c | 29 +++++++++++++++----
>  1 file changed, 24 insertions(+), 5 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 053ed9302cda..73a823f1ec22 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -511,6 +511,25 @@ static void intel_dp_link_training_clock_recovery_delay(struct intel_dp *intel_d
>  		drm_dp_lttpr_link_train_clock_recovery_delay();
>  }
>  
> +static bool intel_dp_adjust_request_changed(int lane_count,
> +					    const u8 old_link_status[DP_LINK_STATUS_SIZE],
> +					    const u8 new_link_status[DP_LINK_STATUS_SIZE])
> +{
> +	int lane;
> +
> +	for (lane = 0; lane < lane_count; lane++) {
> +		u8 old = drm_dp_get_adjust_request_voltage(old_link_status, lane) |
> +			drm_dp_get_adjust_request_pre_emphasis(old_link_status, lane);
> +		u8 new = drm_dp_get_adjust_request_voltage(new_link_status, lane) |
> +			drm_dp_get_adjust_request_pre_emphasis(new_link_status, lane);
> +
> +		if (old != new)
> +			return true;
> +	}
> +
> +	return false;
> +}
> +
>  /*
>   * Perform the link training clock recovery phase on the given DP PHY using
>   * training pattern 1.
> @@ -521,7 +540,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp,
>  				      enum drm_dp_phy dp_phy)
>  {
>  	struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> -	u8 voltage;
> +	u8 old_link_status[DP_LINK_STATUS_SIZE] = {};
>  	int voltage_tries, cr_tries, max_cr_tries;
>  	bool max_vswing_reached = false;
>  
> @@ -574,8 +593,6 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp,
>  			return false;
>  		}
>  
> -		voltage = intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
> -
>  		/* Update training set as requested by target */
>  		intel_dp_get_adjust_train(intel_dp, crtc_state, dp_phy,
>  					  link_status);
> @@ -585,12 +602,14 @@ intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp,
>  			return false;
>  		}
>  
> -		if ((intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) ==
> -		    voltage)
> +		if (!intel_dp_adjust_request_changed(crtc_state->lane_count,
> +						     old_link_status, link_status))
>  			++voltage_tries;
>  		else
>  			voltage_tries = 1;
>  
> +		memcpy(old_link_status, link_status, sizeof(link_status));
> +
>  		if (intel_dp_link_max_vswing_reached(intel_dp, crtc_state))
>  			max_vswing_reached = true;
>  
> -- 
> 2.32.0
> 

  reply	other threads:[~2021-10-01 17:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-01 16:08 [Intel-gfx] [PATCH] drm/i915: Fix DP clock recovery "voltage_tries" handling Ville Syrjala
2021-10-01 17:17 ` Imre Deak [this message]
2021-10-01 22:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2021-10-02  5:27 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=20211001171704.GA2577530@ideak-desk.fi.intel.com \
    --to=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --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 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.