From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 07/11] drm/i915: Store the m2 divider as a whole in bxt_clk_div
Date: Mon, 7 Mar 2022 20:02:25 +0200 [thread overview]
Message-ID: <YiZIsUp4c92nLnfZ@intel.com> (raw)
In-Reply-To: <87sfry2blw.fsf@intel.com>
On Fri, Mar 04, 2022 at 01:36:27PM +0200, Jani Nikula wrote:
> On Tue, 01 Mar 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Get rid of the pointless m2 int vs. frac split in bxt_clk_div
> > and just store the whole divider as one.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 33 +++++++++++--------
> > 1 file changed, 19 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > index 899aa42a858f..4a82e630cbec 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > @@ -2085,8 +2085,7 @@ struct bxt_clk_div {
> > int clock;
> > u32 p1;
> > u32 p2;
> > - u32 m2_int;
> > - u32 m2_frac;
> > + u32 m2;
> > u32 n;
> >
> > int vco;
> > @@ -2094,13 +2093,20 @@ struct bxt_clk_div {
> >
> > /* pre-calculated values for DP linkrates */
> > static const struct bxt_clk_div bxt_dp_clk_val[] = {
> > - { .clock = 162000, .p1 = 4, .p2 = 2, .m2_int = 32, .m2_frac = 1677722, .n = 1, },
> > - { .clock = 270000, .p1 = 4, .p2 = 1, .m2_int = 27, .m2_frac = 0, .n = 1, },
> > - { .clock = 540000, .p1 = 2, .p2 = 1, .m2_int = 27, .m2_frac = 0, .n = 1, },
> > - { .clock = 216000, .p1 = 3, .p2 = 2, .m2_int = 32, .m2_frac = 1677722, .n = 1, },
> > - { .clock = 243000, .p1 = 4, .p2 = 1, .m2_int = 24, .m2_frac = 1258291, .n = 1, },
> > - { .clock = 324000, .p1 = 4, .p2 = 1, .m2_int = 32, .m2_frac = 1677722, .n = 1, },
> > - { .clock = 432000, .p1 = 3, .p2 = 1, .m2_int = 32, .m2_frac = 1677722, .n = 1, },
> > + { .clock = 162000, .p1 = 4, .p2 = 2, .n = 1,
> > + .m2 = 0x819999a /* .m2_int = 32, m2_frac = 1677722 */ },
> > + { .clock = 270000, .p1 = 4, .p2 = 1, .n = 1,
> > + .m2 = 0x6c00000 /* .m2_int = 27, m2_frac = 0 */ },
> > + { .clock = 540000, .p1 = 2, .p2 = 1, .n = 1,
> > + .m2 = 0x6c00000 /* .m2_int = 27, m2_frac = 0 */ },
> > + { .clock = 216000, .p1 = 3, .p2 = 2, .n = 1,
> > + .m2 = 0x819999a /* .m2_int = 32, m2_frac = 1677722 */ },
> > + { .clock = 243000, .p1 = 4, .p2 = 1, .n = 1,
> > + .m2 = 0x6133333 /* .m2_int = 24, m2_frac = 1258291 */ },
> > + { .clock = 324000, .p1 = 4, .p2 = 1, .n = 1,
> > + .m2 = 0x819999a /* .m2_int = 32, m2_frac = 1677722 */ },
> > + { .clock = 432000, .p1 = 3, .p2 = 1, .n = 1,
> > + .m2 = 0x819999a /* .m2_int = 32, m2_frac = 1677722 */ },
>
> Mmh, I guess here I would've added some macros to construct m2 from
> m2_int and m2_frac.
>
> #define M2_INT_SHIFT 22
> #define M2_FRAC_MASK 0x3fffff
>
> #define M2(int, frac) ((int) << M2_INT_SHIFT) | (frac))
I don't think this weird decimal representation of m2 is useful
for anything actually. I just copy-pasted it from the chv side
for consistency. Should just probably nuke it for both.
I guess the sensible thing would be to just write the full m2 in
decimal in the comment, eg. ".m2 = 0x819999a /* 32.4 */"
Hmm. Or we could even go a bit further and just do:
.m2 = 32.4 * (1 << 22) + .5
and hope the compiler evaluates it at compile time instead
of getting upset about the floats.
>
> And you get this:
>
> { .clock = 432000, .p1 = 3, .p2 = 1, .m2 = M2(32, 1677722), .n = 1, },
>
> No need to retain the int/frac in comments. Can also use
> REG_FIELD_PREP/GET if you want to over-engineer...
>
> > };
> >
> > static bool
> > @@ -2127,8 +2133,7 @@ bxt_ddi_hdmi_pll_dividers(struct intel_crtc_state *crtc_state,
> > clk_div->p2 = best_clock.p2;
> > drm_WARN_ON(&i915->drm, best_clock.m1 != 2);
> > clk_div->n = best_clock.n;
> > - clk_div->m2_int = best_clock.m2 >> 22;
> > - clk_div->m2_frac = best_clock.m2 & ((1 << 22) - 1);
> > + clk_div->m2 = best_clock.m2;
> >
> > clk_div->vco = best_clock.vco;
> >
> > @@ -2197,11 +2202,11 @@ static bool bxt_ddi_set_dpll_hw_state(struct intel_crtc_state *crtc_state,
> > lanestagger = 0x02;
> >
> > dpll_hw_state->ebb0 = PORT_PLL_P1(clk_div->p1) | PORT_PLL_P2(clk_div->p2);
> > - dpll_hw_state->pll0 = clk_div->m2_int;
> > + dpll_hw_state->pll0 = clk_div->m2 >> 22;
> > dpll_hw_state->pll1 = PORT_PLL_N(clk_div->n);
> > - dpll_hw_state->pll2 = clk_div->m2_frac;
> > + dpll_hw_state->pll2 = clk_div->m2 & 0x3fffff;
I should probably use the REG_FIELD_PREP() macros consistently here.
> >
> > - if (clk_div->m2_frac)
> > + if (clk_div->m2 & 0x3fffff)
> > dpll_hw_state->pll3 = PORT_PLL_M2_FRAC_ENABLE;
But here such usage would imply tht the reg value == m2
fractional part. That does happen to be the case here but
not sure I want to write the code in a way that assumes that.
>
> Also could reuse the shift and mask macros here.
>
> Other than that, the direction seems good.
>
> BR,
> Jani.
>
>
> >
> > dpll_hw_state->pll6 = prop_coef | PORT_PLL_INT_COEFF(int_coef);
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-03-07 18:02 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 ` [Intel-gfx] [PATCH 04/11] drm/i915: Store the /5 target clock in sturct dpll on vlv/chv Ville Syrjala
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ä [this message]
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=YiZIsUp4c92nLnfZ@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.