From: Imre Deak <imre.deak@intel.com>
To: ville.syrjala@linux.intel.com, intel-gfx@lists.freedesktop.org
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 4/6] drm/i915: Make the LPT iclkip 20MHz case more generic
Date: Fri, 19 Feb 2016 16:04:11 +0200 [thread overview]
Message-ID: <1455890651.2380.8.camel@intel.com> (raw)
In-Reply-To: <1455738073-14502-5-git-send-email-ville.syrjala@linux.intel.com>
On ke, 2016-02-17 at 21:41 +0200, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The reason for spcial casing 20MHz in the iclkip calculations is that
> it would overflow the 7 bit divisor value. Let's rewrite the special
> case to check for just that, and bump up auxdiv when needed. This
> makes
> the code work for freqeuencies close to but not exactly 20MHz. The
> real
> lower limit for auxdiv=0 is actually:
> 172800000/(0x7f+2)*64)=~20930 kHz, and below that we must resort to
> auxdiv=1.
>
> Actually this is all very theoretical since we limit the dotclock to
> min 25MHz with CRT on all platforms. 25Mhz is actually the documented
> limit in Bspec, so it seems we ought to never need to worry about the
> auxdiv=1 case. But no harm in having it.
>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Yep, fewer special casing is better. Btw, the spec could have just as
well describe how to calculate aux_div instead of providing special
cases and tables, I wonder why this is done at places. The patch looks
good:
Reviewed-by: Imre Deak <imre.deak@intel.com>
> ---
> drivers/gpu/drm/i915/intel_display.c | 40 +++++++++++++++++---------
> ----------
> 1 file changed, 19 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a3c959cd8b3b..5e7b22a31098 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3957,37 +3957,35 @@ static void lpt_disable_iclkip(struct
> drm_i915_private *dev_priv)
> /* Program iCLKIP clock to the desired frequency */
> static void lpt_program_iclkip(struct drm_crtc *crtc)
> {
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> int clock = to_intel_crtc(crtc)->config-
> >base.adjusted_mode.crtc_clock;
> u32 divsel, phaseinc, auxdiv, phasedir = 0;
> u32 temp;
>
> lpt_disable_iclkip(dev_priv);
>
> - /* 20MHz is a corner case which is out of range for the 7-
> bit divisor */
> - if (clock == 20000) {
> - auxdiv = 1;
> - divsel = 0x41;
> - phaseinc = 0x20;
> - } else {
> - /* The iCLK virtual clock root frequency is in MHz,
> - * but the adjusted_mode->crtc_clock in in KHz. To
> get the
> - * divisors, it is necessary to divide one by
> another, so we
> - * convert the virtual clock precision to KHz here
> for higher
> - * precision.
> - */
> + /* The iCLK virtual clock root frequency is in MHz,
> + * but the adjusted_mode->crtc_clock in in KHz. To get the
> + * divisors, it is necessary to divide one by another, so we
> + * convert the virtual clock precision to KHz here for
> higher
> + * precision.
> + */
> + for (auxdiv = 0; auxdiv < 2; auxdiv++) {
> u32 iclk_virtual_root_freq = 172800 * 1000;
> u32 iclk_pi_range = 64;
> - u32 desired_divisor, msb_divisor_value, pi_value;
> + u32 desired_divisor;
>
> - desired_divisor =
> DIV_ROUND_CLOSEST(iclk_virtual_root_freq, clock);
> - msb_divisor_value = desired_divisor / iclk_pi_range;
> - pi_value = desired_divisor % iclk_pi_range;
> + desired_divisor =
> DIV_ROUND_CLOSEST(iclk_virtual_root_freq,
> + clock <<
> auxdiv);
> + divsel = (desired_divisor / iclk_pi_range) - 2;
> + phaseinc = desired_divisor % iclk_pi_range;
>
> - auxdiv = 0;
> - divsel = msb_divisor_value - 2;
> - phaseinc = pi_value;
> + /*
> + * Near 20MHz is a corner case which is
> + * out of range for the 7-bit divisor
> + */
> + if (divsel <= 0x7f)
> + break;
> }
>
> /* This should not happen with any sane values */
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-02-19 14:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-17 19:41 [PATCH 0/6] drm/i915: Some FDI related dotclock stuff ville.syrjala
2016-02-17 19:41 ` [PATCH 1/6] drm/i915: Dump ddi_pll_sel in hex instead of decimal on HSW/BDW ville.syrjala
2016-02-18 13:19 ` Imre Deak
2016-02-17 19:41 ` [PATCH 2/6] drm/i915: Move the encoder vs. FDI dotclock check out from encoder .get_config() ville.syrjala
2016-02-18 18:18 ` Imre Deak
2016-02-17 19:41 ` [PATCH 3/6] drm/i915: Remove the SPLL==270Mhz assumption from intel_fdi_link_freq() ville.syrjala
2016-02-18 18:28 ` Imre Deak
2016-02-17 19:41 ` [PATCH 4/6] drm/i915: Make the LPT iclkip 20MHz case more generic ville.syrjala
2016-02-19 13:54 ` Zanoni, Paulo R
2016-02-19 14:04 ` Imre Deak [this message]
2016-02-17 19:41 ` [PATCH 5/6] drm/i915: Read out VGA dotclock properly on LPT ville.syrjala
2016-02-19 14:17 ` Imre Deak
2016-02-17 19:41 ` [PATCH 6/6] drm/i915: Try to fix CRT port clock limits ville.syrjala
2016-02-19 14:58 ` Imre Deak
2016-02-19 13:45 ` ✗ Fi.CI.BAT: failure for drm/i915: Some FDI related dotclock stuff Patchwork
2016-02-25 18:15 ` Ville Syrjälä
2016-03-01 11:13 ` [PATCH 0/6] " Ville Syrjälä
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=1455890651.2380.8.camel@intel.com \
--to=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).