[Intel-gfx] [PATCH] drm/i915: Reduce Data Link N value for 1 lane DP->hdmi converters

Ville Syrjälä ville.syrjala at linux.intel.com
Thu Mar 23 11:43:48 UTC 2017


On Wed, Mar 22, 2017 at 04:27:36PM -0700, clinton.a.taylor at intel.com wrote:
> From: Clint Taylor <clinton.a.taylor at intel.com>
> 
> Several major vendor USB-C->HDMI converters fail to recover a 5.4 GHz 1 lane
> signal if the Data Link N is greater than 0x80000.
> Patch detects when 1 lane 5.4 GHz signal is being used and makes the maximum
> value 20 bit instead of the maximum specification supported 24 bit value.
> 
> Cc: Jani Nikula <jani.nikula at intel.com>
> Cc: Anusha Srivatsa <anusha.srivatsa at intel.com>
> 
> Signed-off-by: Clint Taylor <clinton.a.taylor at intel.com>
> ---
>  drivers/gpu/drm/i915/i915_reg.h      |    2 ++
>  drivers/gpu/drm/i915/intel_display.c |   15 +++++++++++----
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 04c8f69..838d8d5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4869,6 +4869,8 @@ enum {
>  
>  #define  DATA_LINK_M_N_MASK	(0xffffff)
>  #define  DATA_LINK_N_MAX	(0x800000)
> +/* Maximum N value useable on some DP->HDMI converters */
> +#define  DATA_LINK_REDUCED_N_MAX (0x80000)
>  
>  #define _PIPEA_DATA_N_G4X	0x70054
>  #define _PIPEB_DATA_N_G4X	0x71054
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 010e5dd..6e1fdd2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6315,9 +6315,10 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc,
>  }
>  
>  static void compute_m_n(unsigned int m, unsigned int n,
> -			uint32_t *ret_m, uint32_t *ret_n)
> +			uint32_t *ret_m, uint32_t *ret_n,
> +			uint32_t max_link_n)
>  {
> -	*ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
> +	*ret_n = min_t(unsigned int, roundup_pow_of_two(n), max_link_n);
>  	*ret_m = div_u64((uint64_t) m * *ret_n, n);
>  	intel_reduce_m_n_ratio(ret_m, ret_n);
>  }
> @@ -6327,14 +6328,20 @@ static void compute_m_n(unsigned int m, unsigned int n,
>  		       int pixel_clock, int link_clock,
>  		       struct intel_link_m_n *m_n)
>  {
> +	uint32_t max_link_n = DATA_LINK_N_MAX;
>  	m_n->tu = 64;
>  
> +	if ((nlanes==1) && (link_clock >= 540000))
> +		max_link_n = DATA_LINK_REDUCED_N_MAX;

This could use a good comment explaining what's going on. I'd also like
to see a list of affected dongles as part of the comment. Historically
we've had far too many magic quirks for some unspecified piece of
hardware which makes it really difficult to change the code later as
there's no clue how one could even test it.

> +
>  	compute_m_n(bits_per_pixel * pixel_clock,
>  		    link_clock * nlanes * 8,
> -		    &m_n->gmch_m, &m_n->gmch_n);
> +		    &m_n->gmch_m, &m_n->gmch_n,
> +		    max_link_n);
>  
>  	compute_m_n(pixel_clock, link_clock,
> -		    &m_n->link_m, &m_n->link_n);
> +		    &m_n->link_m, &m_n->link_n,
> +		    max_link_n);
>  }
>  
>  static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
> -- 
> 1.7.9.5
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC


More information about the Intel-gfx mailing list