From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 04/11] drm/i915: Store the /5 target clock in sturct dpll on vlv/chv
Date: Tue, 1 Mar 2022 19:31:21 +0200 [thread overview]
Message-ID: <20220301173128.6988-5-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20220301173128.6988-1-ville.syrjala@linux.intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_dpll.c | 23 ++++++++++-------------
1 file 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 14f5ffe27d05..693e07a6db80 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -253,12 +253,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 },
@@ -269,12 +269,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 },
@@ -340,9 +340,9 @@ int vlv_calc_dpll_params(int refclk, struct dpll *clock)
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);
+ clock->dot = DIV_ROUND_CLOSEST(clock->vco, 5 * clock->p);
- return clock->dot / 5;
+ return clock->dot;
}
int chv_calc_dpll_params(int refclk, struct dpll *clock)
@@ -353,9 +353,9 @@ int chv_calc_dpll_params(int refclk, struct dpll *clock)
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);
+ clock->dot = DIV_ROUND_CLOSEST(clock->vco, 5 * clock->p);
- return clock->dot / 5;
+ return clock->dot;
}
/*
@@ -658,8 +658,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 */
@@ -672,7 +670,7 @@ vlv_find_best_dpll(const struct intel_limit *limit,
for (clock.m1 = limit->m1.min; clock.m1 <= limit->m1.max; clock.m1++) {
unsigned int ppm;
- clock.m2 = DIV_ROUND_CLOSEST(target * clock.p * clock.n,
+ clock.m2 = DIV_ROUND_CLOSEST(target * 5 * clock.p * clock.n,
refclk * clock.m1);
vlv_calc_dpll_params(refclk, &clock);
@@ -728,7 +726,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;
@@ -738,7 +735,7 @@ chv_find_best_dpll(const struct intel_limit *limit,
clock.p = clock.p1 * clock.p2;
- m2 = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(target, clock.p * clock.n) << 22,
+ m2 = DIV_ROUND_CLOSEST_ULL(mul_u32_u32(target, 5 * clock.p * clock.n) << 22,
refclk * clock.m1);
if (m2 > INT_MAX/clock.m1)
--
2.34.1
next prev parent reply other threads:[~2022-03-01 17:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 17:31 [Intel-gfx] [PATCH 00/11] drm/i915: Clean up some dpll stuff Ville Syrjala
2022-03-01 17:31 ` [Intel-gfx] [PATCH 01/11] drm/i915: Nuke skl_wrpll_context_init() Ville Syrjala
2022-03-04 11:10 ` Jani Nikula
2022-03-01 17:31 ` [Intel-gfx] [PATCH 02/11] drm/i915: Move a bunch of stuff into rodata from the stack Ville Syrjala
2022-03-04 11:13 ` Jani Nikula
2022-03-01 17:31 ` [Intel-gfx] [PATCH 03/11] drm/i915: Clean up some struct/array initializers Ville Syrjala
2022-03-04 11:14 ` Jani Nikula
2022-03-01 17:31 ` Ville Syrjala [this message]
2022-03-01 17:31 ` [Intel-gfx] [PATCH 05/11] drm/i915: Remove bxt m2_frac_en Ville Syrjala
2022-03-04 11:19 ` Jani Nikula
2022-03-01 17:31 ` [Intel-gfx] [PATCH 06/11] drm/i915: Use designated initializers for bxt_dp_clk_val[] Ville Syrjala
2022-03-04 11:20 ` Jani Nikula
2022-03-01 17:31 ` [Intel-gfx] [PATCH 07/11] drm/i915: Store the m2 divider as a whole in bxt_clk_div Ville Syrjala
2022-03-04 11:36 ` Jani Nikula
2022-03-07 18:02 ` Ville Syrjälä
2022-03-01 17:31 ` [Intel-gfx] [PATCH 08/11] drm/i915: Replace bxt_clk_div with struct dpll Ville Syrjala
2022-03-04 11:41 ` Jani Nikula
2022-03-01 17:31 ` [Intel-gfx] [PATCH 09/11] drm/i915: Replace hand rolled bxt vco calculation with chv_calc_dpll_params() Ville Syrjala
2022-03-01 17:44 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2022-03-01 17:31 ` [Intel-gfx] [PATCH 10/11] drm/i915: Populate bxt/glk DPLL clock limits a bit more Ville Syrjala
2022-03-01 17:31 ` [Intel-gfx] [PATCH 11/11] drm/i915: Remove struct dp_link_dpll Ville Syrjala
2022-03-01 23:01 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Clean up some dpll stuff (rev2) Patchwork
2022-03-02 3:33 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=20220301173128.6988-5-ville.syrjala@linux.intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/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