From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 3/8] drm/i915/cdclk: Remove the assumption that cd2x div==2 when using squashing
Date: Tue, 5 Dec 2023 16:50:43 +0200 [thread overview]
Message-ID: <ZW84wy_FCG8s506B@intel.com> (raw)
In-Reply-To: <170172278840.19717.10772744295565186200@gjsousa-mobl2>
On Mon, Dec 04, 2023 at 05:46:28PM -0300, Gustavo Sousa wrote:
> Quoting Ville Syrjälä (2023-12-04 17:05:46-03:00)
> >On Fri, Dec 01, 2023 at 05:13:38PM -0300, Gustavo Sousa wrote:
> >> Quoting Ville Syrjala (2023-11-28 08:51:33-03:00)
> >> >From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >
> >> >Currently we have a hardcoded assumption that the cd2x divider
> >> >is always 2 when squahsing is used.
> >>
> >> It seems the code was actually making the assumption that the
> >> divider is always 1. With the current code, when squashing is used, we
> >> have that bxt_cdclk_cd2x_div_sel(dev_priv, clock, vco) is equivalent to
> >> bxt_cdclk_cd2x_div_sel(dev_priv, vco / 2, vco), meaning that the
> >> returned value will always be BXT_CDCLK_CD2X_DIV_SEL_1.
> >
> >The real cd2x divider is half of our 'divider' because we
> >specify the full vco->cdclk divider instead of the vco->cd2xclk
> >divider.
>
> Got it.
>
> >
> >Alternatively you can think of it as being the cd2x divider
> >specified in .1 binary fixed point format.
> >
> >But yeah, saying "cd2x divider is 2" probably isn't the best
> >way to put this.
>
> Yeah, maybe because of my little time with the driver code, but I had
> interpreted it as the one used right after the PLL output (I'm taking
> the diagram from MTL specs as reference).
>
> Did I miss some comment in the code explaning that? Should one be added?
Looks like we've at least attempted to document this:
struct intel_cdclk_vals {
u32 cdclk;
u16 refclk;
u16 waveform;
u8 divider; /* CD2X divider * 2 */
u8 ratio;
};
>
> >
> >>
> >> > While that is true for all
> >> >current platforms it might not hold in the future. So eliminate
> >>
> >> Not sure about the other platforms, but for MTL, I have checked the
> >> BSpec table and also did some calculations by hand, and it seems like
> >> the cd2x divider is actually always 1.
> >>
> >> Unless I'm missing something in my analysis above, I believe s/2/1/ in
> >> the commit message is necessary. With that,
> >>
> >> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
>
> Considering that the above understanding about the divider is the common
> sense, the r-b stands without the tweaks in the commit messages. Thanks
> for the clarification!
I can try to tweak it a bit anyway for extra clarity.
And thanks for the review.
>
> --
> Gustavo Sousa
>
> >>
> >> >the assumption and calculate the correct divider from the other
> >> >parameters.
> >> >
> >> >Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >---
> >> > drivers/gpu/drm/i915/display/intel_cdclk.c | 6 ++----
> >> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >> >
> >> >diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> >index 87d5e5b67c4e..d45071675629 100644
> >> >--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> >+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> >@@ -1899,10 +1899,8 @@ static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
> >> >
> >> > waveform = cdclk_squash_waveform(dev_priv, cdclk);
> >> >
> >> >- if (waveform)
> >> >- clock = vco / 2;
> >> >- else
> >> >- clock = cdclk;
> >> >+ clock = DIV_ROUND_CLOSEST(cdclk * cdclk_squash_len,
> >> >+ cdclk_squash_divider(waveform));
> >>
> >> Nit: maybe take the opportunity to rename "clock" to "unsquashed" for
> >> clarity?
> >>
> >> >
> >> > if (HAS_CDCLK_SQUASH(dev_priv))
> >> > dg2_cdclk_squash_program(dev_priv, waveform);
> >> >--
> >> >2.41.0
> >> >
> >
> >--
> >Ville Syrjälä
> >Intel
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2023-12-05 14:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-28 11:51 [Intel-gfx] [PATCH 0/8] drm/i915: cdclk/voltage_level cleanups and fixes Ville Syrjala
2023-11-28 11:51 ` [Intel-gfx] [PATCH 1/8] drm/i915/cdclk: s/-1/~0/ when dealing with unsigned values Ville Syrjala
2023-12-01 19:54 ` Gustavo Sousa
2023-11-28 11:51 ` [Intel-gfx] [PATCH 2/8] drm/i915/cdclk: Give the squash waveform length a name Ville Syrjala
2023-12-01 19:56 ` Gustavo Sousa
2023-11-28 11:51 ` [Intel-gfx] [PATCH 3/8] drm/i915/cdclk: Remove the assumption that cd2x div==2 when using squashing Ville Syrjala
2023-12-01 20:13 ` Gustavo Sousa
2023-12-04 20:05 ` Ville Syrjälä
2023-12-04 20:46 ` Gustavo Sousa
2023-12-05 14:50 ` Ville Syrjälä [this message]
2023-12-11 22:16 ` [PATCH v2 3/8] drm/i915/cdclk: Remove the assumption that cdclk divider==2 " Ville Syrjala
2023-11-28 11:51 ` [Intel-gfx] [PATCH 4/8] drm/i915/cdclk: Rewrite cdclk->voltage_level selection to use tables Ville Syrjala
2023-12-01 21:25 ` Gustavo Sousa
2023-12-11 22:17 ` [PATCH v2 " Ville Syrjala
2023-11-28 11:51 ` [Intel-gfx] [PATCH 5/8] drm/i915/mtl: Fix voltage_level for cdclk==480MHz Ville Syrjala
2023-12-01 21:29 ` Gustavo Sousa
2023-11-28 11:51 ` [Intel-gfx] [PATCH 6/8] drm/i915: Split intel_ddi_compute_min_voltage_level() into platform variants Ville Syrjala
2023-12-01 21:37 ` Gustavo Sousa
2023-11-28 11:51 ` [Intel-gfx] [PATCH 7/8] drm/i915/mtl: Calculate the correct voltage level from port_clock Ville Syrjala
2023-12-01 21:39 ` Gustavo Sousa
2023-11-28 11:51 ` [Intel-gfx] [PATCH 8/8] drm/i915: Simplify intel_ddi_compute_min_voltage_level() Ville Syrjala
2023-12-01 21:44 ` Gustavo Sousa
2023-11-29 0:52 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: cdclk/voltage_level cleanups and fixes Patchwork
2023-11-29 1:06 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-11-29 7:28 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-12-11 23:30 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: cdclk/voltage_level cleanups and fixes (rev3) Patchwork
2023-12-11 23:30 ` ✗ Fi.CI.SPARSE: " Patchwork
2023-12-11 23:37 ` ✓ Fi.CI.BAT: success " Patchwork
2023-12-12 0:36 ` ✗ 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=ZW84wy_FCG8s506B@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=gustavo.sousa@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;
as well as URLs for NNTP newsgroup(s).