aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJani Nikula <jani.nikula@intel.com>2017-03-27 07:33:25 -0400
committerJani Nikula <jani.nikula@intel.com>2017-03-28 11:18:23 -0400
commit9a86cda07af2c63649932f0a4fc757701ef54c42 (patch)
tree145941b8be77aed6c20226b3dcd5e53332d17c27
parent090e5fe3f0115ff0bcb299bb90cfd8cb82f5cbf8 (diff)
drm/i915/dp: reduce link M/N parameters
Several major vendor USB-C->HDMI converters, in particular the DA200, fail to recover a 5.4 GHz 1 lane signal if the link N is greater than 0x80000. The link M and N depend on the pixel clock and link clock ratio. With current code link N exceeds 0x80000 only when link clock >= 540000 kHz. Except for the eDP intermediate link clocks, at least the four least significant bits are always zero. Just one bit shift right would be enough to bring even the DP 1.4 810000 kHz link clock under 0x80000 link N. The pixel clock for modes that require a link clock >= 540000 kHz would also have several least significant bits zero. Unless the user provides a mode with an odd pixel clock value, we can reduce the numbers to reach the goal, with no loss in precision. The DP spec even mentions sources making choices that "allow for static and relatively small Mvid and Nvid values", thus reducing the link M/N regardless of the sink in question seems justified. Everything here is based on the work and information gathered by Clint Taylor <clinton.a.taylor@intel.com>. This is just an iteration to reduce the parameters regardless of lane count, link rate, or sink. Reference: http://patchwork.freedesktop.org/patch/msgid/1490225256-11667-1-git-send-email-clinton.a.taylor@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578 Tested-by: Mads <mads@ab3.no> Tested-by: PJ <foobar@pjmodos.net> Tested-by: François Guerraz <kubrick@fgv6.net> Tested-by: Lev Popov <leo@nabam.net> Tested-by: Igor Krivenko <igor.s.krivenko@gmail.com> Tested-by: Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by: Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1490614405-23337-1-git-send-email-jani.nikula@intel.com
-rw-r--r--drivers/gpu/drm/i915/intel_display.c11
1 files changed, 11 insertions, 0 deletions
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 20fb8dd13184..654b8a0c28ee 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6290,6 +6290,17 @@ intel_reduce_m_n_ratio(uint32_t *num, uint32_t *den)
6290static void compute_m_n(unsigned int m, unsigned int n, 6290static void compute_m_n(unsigned int m, unsigned int n,
6291 uint32_t *ret_m, uint32_t *ret_n) 6291 uint32_t *ret_m, uint32_t *ret_n)
6292{ 6292{
6293 /*
6294 * Reduce M/N as much as possible without loss in precision. Several DP
6295 * dongles in particular seem to be fussy about too large *link* M/N
6296 * values. The passed in values are more likely to have the least
6297 * significant bits zero than M after rounding below, so do this first.
6298 */
6299 while ((m & 1) == 0 && (n & 1) == 0) {
6300 m >>= 1;
6301 n >>= 1;
6302 }
6303
6293 *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX); 6304 *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
6294 *ret_m = div_u64((uint64_t) m * *ret_n, n); 6305 *ret_m = div_u64((uint64_t) m * *ret_n, n);
6295 intel_reduce_m_n_ratio(ret_m, ret_n); 6306 intel_reduce_m_n_ratio(ret_m, ret_n);