Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Store the /5 target clock in struct dpll on vlv/chv
Date: Wed, 09 Mar 2022 11:53:59 +0200	[thread overview]
Message-ID: <87mthzzc20.fsf@intel.com> (raw)
In-Reply-To: <20220307233940.4161-2-ville.syrjala@linux.intel.com>

On Tue, 08 Mar 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Unify vlv/chv with earlier platforms so that the sturct dpll::dot
> represents the /5 clock frequency (ie. DP symbol rate or HDMI
> TMDS rate) rather than the *5 fast clock (/2 of the bitrate).
> Makes life a little less confusing to get the same number back
> in .dot which we fed into the DPLL algorithm.
>
> v2: Actually just include the 5x in the final P divider
>     Do the same change to the hand rolled gvt code
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

For some reason it was really hard for me to convince myself that I'd
checked every code path for the right amount of *5 and /5 in the right
places... I'll just say I didn't spot anything obviously wrong
here. Fingers crossed.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>


> ---
>  drivers/gpu/drm/i915/display/intel_dpll.c | 19 ++++++++-----------
>  drivers/gpu/drm/i915/gvt/handlers.c       |  4 ++--
>  2 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c b/drivers/gpu/drm/i915/display/intel_dpll.c
> index 0ae37fdbf2a5..b3fd94538c44 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll.c
> @@ -254,12 +254,12 @@ static const struct intel_limit ilk_limits_dual_lvds_100m = {
>  
>  static const struct intel_limit intel_limits_vlv = {
>  	 /*
> -	  * These are the data rate limits (measured in fast clocks)
> +	  * These are based on the data rate limits (measured in fast clocks)
>  	  * since those are the strictest limits we have. The fast
>  	  * clock and actual rate limits are more relaxed, so checking
>  	  * them would make no difference.
>  	  */
> -	.dot = { .min = 25000 * 5, .max = 270000 * 5 },
> +	.dot = { .min = 25000, .max = 270000 },
>  	.vco = { .min = 4000000, .max = 6000000 },
>  	.n = { .min = 1, .max = 7 },
>  	.m1 = { .min = 2, .max = 3 },
> @@ -270,12 +270,12 @@ static const struct intel_limit intel_limits_vlv = {
>  
>  static const struct intel_limit intel_limits_chv = {
>  	/*
> -	 * These are the data rate limits (measured in fast clocks)
> +	 * These are based on the data rate limits (measured in fast clocks)
>  	 * since those are the strictest limits we have.  The fast
>  	 * clock and actual rate limits are more relaxed, so checking
>  	 * them would make no difference.
>  	 */
> -	.dot = { .min = 25000 * 5, .max = 540000 * 5},
> +	.dot = { .min = 25000, .max = 540000 },
>  	.vco = { .min = 4800000, .max = 6480000 },
>  	.n = { .min = 1, .max = 1 },
>  	.m1 = { .min = 2, .max = 2 },
> @@ -337,26 +337,26 @@ int i9xx_calc_dpll_params(int refclk, struct dpll *clock)
>  int vlv_calc_dpll_params(int refclk, struct dpll *clock)
>  {
>  	clock->m = clock->m1 * clock->m2;
> -	clock->p = clock->p1 * clock->p2;
> +	clock->p = clock->p1 * clock->p2 * 5;
>  	if (WARN_ON(clock->n == 0 || clock->p == 0))
>  		return 0;
>  	clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n);
>  	clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
>  
> -	return clock->dot / 5;
> +	return clock->dot;
>  }
>  
>  int chv_calc_dpll_params(int refclk, struct dpll *clock)
>  {
>  	clock->m = clock->m1 * clock->m2;
> -	clock->p = clock->p1 * clock->p2;
> +	clock->p = clock->p1 * clock->p2 * 5;
>  	if (WARN_ON(clock->n == 0 || clock->p == 0))
>  		return 0;
>  	clock->vco = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(refclk, clock->m),
>  					   clock->n << 22);
>  	clock->dot = DIV_ROUND_CLOSEST(clock->vco, clock->p);
>  
> -	return clock->dot / 5;
> +	return clock->dot;
>  }
>  
>  /*
> @@ -659,8 +659,6 @@ vlv_find_best_dpll(const struct intel_limit *limit,
>  	int max_n = min(limit->n.max, refclk / 19200);
>  	bool found = false;
>  
> -	target *= 5; /* fast clock */
> -
>  	memset(best_clock, 0, sizeof(*best_clock));
>  
>  	/* based on hardware requirement, prefer smaller n to precision */
> @@ -729,7 +727,6 @@ chv_find_best_dpll(const struct intel_limit *limit,
>  	 */
>  	clock.n = 1;
>  	clock.m1 = 2;
> -	target *= 5;	/* fast clock */
>  
>  	for (clock.p1 = limit->p1.max; clock.p1 >= limit->p1.min; clock.p1--) {
>  		for (clock.p2 = limit->p2.p2_fast;
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c b/drivers/gpu/drm/i915/gvt/handlers.c
> index 520a7e1942f3..efdd2f3f9d73 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -583,7 +583,7 @@ static u32 bxt_vgpu_get_dp_bitrate(struct intel_vgpu *vgpu, enum port port)
>  	clock.p1 = (vgpu_vreg_t(vgpu, BXT_PORT_PLL_EBB_0(phy, ch)) & PORT_PLL_P1_MASK) >> PORT_PLL_P1_SHIFT;
>  	clock.p2 = (vgpu_vreg_t(vgpu, BXT_PORT_PLL_EBB_0(phy, ch)) & PORT_PLL_P2_MASK) >> PORT_PLL_P2_SHIFT;
>  	clock.m = clock.m1 * clock.m2;
> -	clock.p = clock.p1 * clock.p2;
> +	clock.p = clock.p1 * clock.p2 * 5;
>  
>  	if (clock.n == 0 || clock.p == 0) {
>  		gvt_dbg_dpy("vgpu-%d PORT_%c PLL has invalid divider\n", vgpu->id, port_name(port));
> @@ -593,7 +593,7 @@ static u32 bxt_vgpu_get_dp_bitrate(struct intel_vgpu *vgpu, enum port port)
>  	clock.vco = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(refclk, clock.m), clock.n << 22);
>  	clock.dot = DIV_ROUND_CLOSEST(clock.vco, clock.p);
>  
> -	dp_br = clock.dot / 5;
> +	dp_br = clock.dot;
>  
>  out:
>  	return dp_br;

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-03-09  9:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 23:39 [Intel-gfx] [PATCH v2 0/8] drm/i915: Clean up some dpll stuff Ville Syrjala
2022-03-07 23:39 ` [Intel-gfx] [PATCH v2 1/8] drm/i915: Store the /5 target clock in struct dpll on vlv/chv Ville Syrjala
2022-03-09  9:53   ` Jani Nikula [this message]
2022-03-09 21:43   ` [Intel-gfx] [PATCH v3 " Ville Syrjala
2022-03-07 23:39 ` [Intel-gfx] [PATCH v2 2/8] drm/i915: Remove redundant/wrong comments Ville Syrjala
2022-03-09  9:50   ` Jani Nikula
2022-03-07 23:39 ` [Intel-gfx] [PATCH v2 3/8] drm/i915: Clean up bxt/glk PLL registers Ville Syrjala
2022-03-09  9:22   ` Jani Nikula
2022-03-07 23:39 ` [Intel-gfx] [PATCH v2 4/8] drm/i915: Store the m2 divider as a whole in bxt_clk_div Ville Syrjala
2022-03-09  9:27   ` Jani Nikula
2022-03-07 23:39 ` [Intel-gfx] [PATCH v2 5/8] drm/i915: Replace bxt_clk_div with struct dpll Ville Syrjala
2022-03-07 23:39 ` [Intel-gfx] [PATCH v2 6/8] drm/i915: Replace hand rolled bxt vco calculation with chv_calc_dpll_params() Ville Syrjala
2022-03-09  9:46   ` Jani Nikula
2022-03-07 23:39 ` [Intel-gfx] [PATCH v2 7/8] drm/i915: Populate bxt/glk DPLL clock limits a bit more Ville Syrjala
2022-03-09  9:30   ` Jani Nikula
2022-03-07 23:39 ` [Intel-gfx] [PATCH v2 8/8] drm/i915: Remove struct dp_link_dpll Ville Syrjala
2022-03-09  9:34   ` Jani Nikula
2022-03-07 23:50 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Clean up some dpll stuff (rev3) Patchwork
2022-03-08 13:31 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-03-09  2:48 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Clean up some dpll stuff (rev4) Patchwork
2022-03-09  3:22 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-03-09 18:23 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Clean up some dpll stuff (rev5) Patchwork
2022-03-09 18:59 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-03-09 22:02 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Clean up some dpll stuff (rev6) Patchwork
2022-03-09 22:35 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-10  7:29 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

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=87mthzzc20.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --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