[Intel-gfx] [PATCH 4/5] drm/i915: fix VLV limits and m/n/p calculations v2

Daniel Vetter daniel at ffwll.ch
Thu Apr 18 10:51:59 CEST 2013


On Thu, Apr 18, 2013 at 10:10:46AM +0200, Daniel Vetter wrote:
> On Wed, Apr 17, 2013 at 03:55:00PM -0700, Jesse Barnes wrote:
> > From: Pallavi G <pallavi.g at intel.com>
> > 
> > For high res modes m n p calculation is fixed for VLV platform.
> > 
> > v2: use 64 bit types and math (Ville)
> > 
> > Signed-off-by: Pallavi G <pallavi.g at intel.com>
> > Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman at intel.com>
> > Signed-off-by: Yogesh M <yogesh.mohan.marimuthu at intel.com>
> > Signed-off-by: Gajanan Bhat <gajanan.bhat at intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c |   25 +++++++++++++++----------
> >  1 file changed, 15 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 28b8fac..f3aa24f4 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -31,6 +31,7 @@
> >  #include <linux/kernel.h>
> >  #include <linux/slab.h>
> >  #include <linux/vgaarb.h>
> > +#include <linux/math64.h>
> >  #include <drm/drm_edid.h>
> >  #include <drm/drmP.h>
> >  #include "intel_drv.h"
> > @@ -396,21 +397,21 @@ static const intel_limit_t intel_limits_vlv_dac = {
> >  	.m1 = { .min = 2, .max = 3 },
> >  	.m2 = { .min = 11, .max = 156 },
> >  	.p = { .min = 10, .max = 30 },
> > -	.p1 = { .min = 2, .max = 3 },
> > +	.p1 = { .min = 1, .max = 3 },
> >  	.p2 = { .dot_limit = 270000,
> >  		.p2_slow = 2, .p2_fast = 20 },
> >  	.find_pll = intel_vlv_find_best_pll,
> >  };
> >  
> >  static const intel_limit_t intel_limits_vlv_hdmi = {
> > -	.dot = { .min = 20000, .max = 165000 },
> > -	.vco = { .min = 4000000, .max = 5994000},
> > -	.n = { .min = 1, .max = 7 },
> > +	.dot = { .min = 25000, .max = 180000 },
> > +	.vco = { .min = 4040000, .max = 5960000 },
> > +	.n = { .min = 1, .max = 5 },
> >  	.m = { .min = 60, .max = 300 }, /* guess */
> >  	.m1 = { .min = 2, .max = 3 },
> > -	.m2 = { .min = 11, .max = 156 },
> > +	.m2 = { .min = 15, .max = 149 },
> >  	.p = { .min = 10, .max = 30 },
> > -	.p1 = { .min = 2, .max = 3 },
> > +	.p1 = { .min = 1, .max = 3 },
> >  	.p2 = { .dot_limit = 270000,
> >  		.p2_slow = 2, .p2_fast = 20 },
> >  	.find_pll = intel_vlv_find_best_pll,
> > @@ -424,7 +425,7 @@ static const intel_limit_t intel_limits_vlv_dp = {
> >  	.m1 = { .min = 2, .max = 3 },
> >  	.m2 = { .min = 11, .max = 156 },
> >  	.p = { .min = 10, .max = 30 },
> > -	.p1 = { .min = 2, .max = 3 },
> > +	.p1 = { .min = 1, .max = 3 },
> >  	.p2 = { .dot_limit = 270000,
> >  		.p2_slow = 2, .p2_fast = 20 },
> >  	.find_pll = intel_vlv_find_best_pll,
> > @@ -821,10 +822,13 @@ intel_vlv_find_best_pll(const intel_limit_t *limit, struct drm_crtc *crtc,
> >  			int target, int refclk, intel_clock_t *match_clock,
> >  			intel_clock_t *best_clock)
> >  {
> > +#define LONG_OVERFLOW 0x7FFFFFFF
> > +#define DIFF_OVERFLOW (LONG_OVERFLOW/10000)
> 
> Unused?
> 
> > +
> >  	u32 p1, p2, m1, m2, vco, bestn, bestm1, bestm2, bestp1, bestp2;
> >  	u32 m, n, fastclk;
> >  	u32 updrate, minupdate, fracbits, p;
> > -	unsigned long bestppm, ppm, absppm;
> > +	s64 bestppm, ppm, absppm, ppmdiff;
> >  	int dotclk, flag;
> >  
> >  	flag = 0;
> > @@ -853,8 +857,9 @@ intel_vlv_find_best_pll(const intel_limit_t *limit, struct drm_crtc *crtc,
> >  					m = m1 * m2;
> >  					vco = updrate * m;
> >  					if (vco >= limit->vco.min && vco < limit->vco.max) {
> > -						ppm = 1000000 * ((vco / p) - fastclk) / fastclk;
> > -						absppm = (ppm > 0) ? ppm : (-ppm);
> > +						ppmdiff = div_s64((100*vco), p) - (100*fastclk);
> 
> I'm probably a bit dense, but I think C integer conversion rules say
> (100*vco) is still only a u32. So I think that div_s64 doesn't help a lot
> since the upcast to u64 will happen after the mutliplication.  Also,
> ppmdiff should be called pphundred_diff if you want to stick to this
> formula.

Maybe make a separate patch with all the pll limits fixes and we can yell
at the absppm diff computation here separately.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list