public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 05/14] drm/i915: Rewrite vlv_find_best_dpll()
Date: Fri, 27 Sep 2013 16:01:18 +0300	[thread overview]
Message-ID: <20130927130118.GE14385@intel.com> (raw)
In-Reply-To: <87a9izd2hc.fsf@gaia.fi.intel.com>

On Thu, Sep 26, 2013 at 06:30:55PM +0300, Mika Kuoppala wrote:
> ville.syrjala@linux.intel.com writes:
> 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Rewrite vlv_find_best_dpll() to use intel_clock_t rather than
> > an army of local variables.
> >
> > Also extract the code to calculate the derived values into
> > vlv_clock().
> >
> > v2: Split up the earlier fixes, extract vlv_clock()
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 72 ++++++++++++++++--------------------
> >  1 file changed, 31 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index f646fea..c5f0794 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -438,6 +438,14 @@ static void i9xx_clock(int refclk, intel_clock_t *clock)
> >  	clock->dot = clock->vco / clock->p;
> >  }
> >  
> > +static void vlv_clock(int refclk, intel_clock_t *clock)
> > +{
> > +	clock->m = clock->m1 * clock->m2;
> > +	clock->p = clock->p1 * clock->p2;
> > +	clock->vco = refclk * clock->m / clock->n;
> > +	clock->dot = clock->vco / clock->p;
> > +}
> > +
> >  /**
> >   * Returns whether any output on the specified pipe is of the specified type
> >   */
> > @@ -670,66 +678,48 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct drm_crtc *crtc,
> >  		   int target, int refclk, intel_clock_t *match_clock,
> >  		   intel_clock_t *best_clock)
> >  {
> > -	u32 p1, p2, m1, m2, vco, bestn, bestm1, bestm2, bestp1, bestp2;
> > -	u32 m, n, fastclk;
> > -	u32 updrate, minupdate, p;
> > +	intel_clock_t clock;
> > +	u32 minupdate = 19200;
> >  	unsigned int bestppm = 1000000;
> > -	int dotclk, flag;
> >  
> > -	flag = 0;
> > -	dotclk = target * 1000;
> > -	fastclk = dotclk / (2*100);
> > -	updrate = 0;
> > -	minupdate = 19200;
> > -	n = p = p1 = p2 = m = m1 = m2 = vco = bestn = 0;
> > -	bestm1 = bestm2 = bestp1 = bestp2 = 0;
> > +	target *= 5; /* fast clock */
> >  
> >  	/* based on hardware requirement, prefer smaller n to precision */
> > -	for (n = limit->n.min; n <= ((refclk) / minupdate); n++) {
> > -		updrate = refclk / n;
> > -		for (p1 = limit->p1.max; p1 > limit->p1.min; p1--) {
> > -			for (p2 = limit->p2.p2_fast+1; p2 > 0; p2--) {
> > -				if (p2 > 10)
> > -					p2 = p2 - 1;
> > -				p = p1 * p2;
> > +	for (clock.n = limit->n.min; clock.n <= ((refclk) / minupdate); clock.n++) {
> > +		for (clock.p1 = limit->p1.max; clock.p1 > limit->p1.min; clock.p1--) {
> > +			for (clock.p2 = limit->p2.p2_fast+1; clock.p2 > 0; clock.p2--) {
> > +				if (clock.p2 > 10)
> > +					clock.p2--;
> > +				clock.p = clock.p1 * clock.p2;
> >  				/* based on hardware requirement, prefer bigger m1,m2 values */
> 
> Is this comment valid as we seem to start from m1.min?

We anyway try to find the closest m2 based on m1,n,p1 and p2, and since
we start w/ large p dividers, m1*m2 will come out as something big to
compensate. Though starting with small n does mean m2 doesn't come out
as large as it could be, but I guess having a small n is considered
more important than having a large m.

The bestppm comparison we do guarantees that we prefer an earlier result
unless the new ppm is at least 10 better, and since we start with small
n and large p, it should do what we want.

Then there's ppm<100 comparison which is a bit different. It means we
favor anything that is considered good enough (ppm < 100) as long as
the p divider increases, and hence the VCO frequency increases. That
would seem to be in line with the other stated goals of big m and small n.

> 
> > -				for (m1 = limit->m1.min; m1 <= limit->m1.max; m1++) {
> > +				for (clock.m1 = limit->m1.min; clock.m1 <= limit->m1.max; clock.m1++) {
> >  					unsigned int ppm, diff;
> >  
> > -					m2 = DIV_ROUND_CLOSEST(fastclk * p * n, refclk * m1);
> > -					m = m1 * m2;
> > -					vco = updrate * m;
> > +					clock.m2 = DIV_ROUND_CLOSEST(target * clock.p * clock.n,
> > +								     refclk * clock.m1);
> >  
> > -					if (vco < limit->vco.min || vco >= limit->vco.max)
> > +					vlv_clock(refclk, &clock);
> > +
> 
> > +					if (clock.vco < limit->vco.min ||
> > +					    clock.vco >= limit->vco.max)
> >  						continue;
> 
> Can intel_PLL_is_valid() used here instead of just checking the vco?

We'd need to modify intel_PLL_is_valid() a bit to skip the m1<=m2 check,
and we'd also need to skip the 'm' and 'p' divider check, or populate
the m and p min/max with something that makes sense.

It would do the clock.dot min/max check that we're currently missing
from this function, and I guess it would allow easier debugging since it
has the INTELPllInvalid() macro for that purpose. So it would seem to be
a good idea to use it.

> 
> >  
> > -					diff = abs(vco / p - fastclk);
> > -					ppm = div_u64(1000000ULL * diff, fastclk);
> > -					if (ppm < 100 && ((p1 * p2) > (bestp1 * bestp2))) {
> > +					diff = abs(clock.dot - target);
> > +					ppm = div_u64(1000000ULL * diff, target);
> > +
> > +					if (ppm < 100 && clock.p > best_clock->p) {
> >  						bestppm = 0;
> > -						flag = 1;
> > +						*best_clock = clock;
> >  					}
> > +
> >  					if (bestppm >= 10 && ppm < bestppm - 10) {
> >  						bestppm = ppm;
> > -						flag = 1;
> > -					}
> > -					if (flag) {
> > -						bestn = n;
> > -						bestm1 = m1;
> > -						bestm2 = m2;
> > -						bestp1 = p1;
> > -						bestp2 = p2;
> > -						flag = 0;
> > +						*best_clock = clock;
> >  					}
> >  				}
> >  			}
> >  		}
> >  	}
> > -	best_clock->n = bestn;
> > -	best_clock->m1 = bestm1;
> > -	best_clock->m2 = bestm2;
> > -	best_clock->p1 = bestp1;
> > -	best_clock->p2 = bestp2;
> >  
> >  	return true;
> >  }
> > -- 
> > 1.8.1.5
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2013-09-27 13:02 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-24 18:26 [PATCH 00/14] drm/i915: VLV DPLL calc fixes and cleanups ville.syrjala
2013-09-24 18:26 ` [PATCH 01/14] drm/i915: Eliminate one indent leel from vlv_find_best_dpll ville.syrjala
2013-09-26 10:04   ` Mika Kuoppala
2013-09-24 18:26 ` [PATCH 02/14] drm/i915: Use DIV_ROUND_CLOSEST() ville.syrjala
2013-09-26 10:09   ` Mika Kuoppala
2013-09-27 19:35     ` Daniel Vetter
2013-09-24 18:26 ` [PATCH 03/14] drm/i915: Make vlv_find_best_dpll() ppm calculation safe ville.syrjala
2013-09-24 18:26 ` [PATCH 04/14] drm/i915: Don't underflow bestppm ville.syrjala
2013-09-24 18:26 ` [PATCH v2 05/14] drm/i915: Rewrite vlv_find_best_dpll() ville.syrjala
2013-09-26 15:30   ` Mika Kuoppala
2013-09-27 13:01     ` Ville Syrjälä [this message]
2013-09-27 13:55     ` [PATCH 15/14] drm/i915: Use intel_PLL_is_valid() in vlv_find_best_dpll() ville.syrjala
2013-09-27 11:55   ` [PATCH v2 05/14] drm/i915: Rewrite vlv_find_best_dpll() Mika Kuoppala
2013-09-27 13:04     ` Ville Syrjälä
2013-09-27 13:54     ` [PATCH v3 " ville.syrjala
2013-09-24 18:26 ` [PATCH 06/14] drm/i915: De-magic the VLV p2 divider step size ville.syrjala
2013-09-24 18:26 ` [PATCH 07/14] drm/i915: Make sure we respect n.max on VLV ville.syrjala
2013-09-24 18:26 ` [PATCH 08/14] drm/i915: Clarify VLV PLL p1 limits ville.syrjala
2013-09-24 18:26 ` [PATCH 09/14] drm/i915: Allow p1 divider 2 on VLV ville.syrjala
2013-09-24 18:26 ` [PATCH 10/14] drm/i915: Respect p2 divider minimum limit " ville.syrjala
2013-09-24 18:26 ` [PATCH 11/14] drm/i915: Remove the unused p and m limits for VLV ville.syrjala
2013-09-24 18:26 ` [PATCH 12/14] drm/i915: Remove unused dot_limit from VLV PLL limits ville.syrjala
2013-09-24 18:26 ` [PATCH 13/14] drm/i915: intel_limits_vlv_dac and intel_limits_vlv_hdmi are the same ville.syrjala
2013-09-24 18:26 ` [PATCH 14/14] drm/i915: Don't lie about findind suitable PLL settings on VLV ville.syrjala
2013-09-24 19:15 ` [PATCH 00/14] drm/i915: VLV DPLL calc fixes and cleanups Daniel Vetter
2013-09-25  7:38   ` [PATCH] drm/i915: Fix 1.62 DP DPLL settings for VLV ville.syrjala
2013-09-30 15:06 ` [PATCH 00/14] drm/i915: VLV DPLL calc fixes and cleanups Mika Kuoppala
2013-10-04 13:34   ` Daniel Vetter

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=20130927130118.GE14385@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox