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
next prev parent 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