From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Nemesa Garg <nemesa.garg@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [RFC PATCH 1/2] drm/i915/cdclk: Avoid VCO-change glitches
Date: Mon, 8 Jun 2026 16:11:43 +0300 [thread overview]
Message-ID: <aia_jxWyNrCWEPEW@intel.com> (raw)
In-Reply-To: <20260608125009.979672-2-nemesa.garg@intel.com>
On Mon, Jun 08, 2026 at 06:20:08PM +0530, Nemesa Garg wrote:
> On platforms with both cdclk squash and crawl, bxt_modeset_calc_cdclk()
> can pick a target cdclk whose VCO differs from the current one. The
> resulting transition causes pipe FIFO underruns:
>
> - Up-crawl from VCO 614400: intermediate frequencies fall below
> min_cdclk.
Should not happen, and cdclk_compute_crawl_and_squash_midpoint() will
WARN if the mid cdclk comes out too low.
Since you've provided no logs of what you think is happening I can't
even speculate what might be going on.
> - Down-crawl from VCO 1382400: DBUF ratio changes mid-commit before
> watermarks for the new ratio are programmed.
>
> On a VCO-changing transition, prefer the lowest cdclk_table entry that
> satisfies min_cdclk at the current VCO (pure squash, no DBUF ratio
> change). If none exists, fall back to max_cdclk_freq on the up-crawl
> path and stay at the current cdclk on the down-crawl path.
>
> Assisted-by: Claude:claude-sonnet-4.6
> Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 47 ++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 189ae2d3cfc9..ead8e59e44a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1598,6 +1598,26 @@ static int bxt_calc_cdclk(struct intel_display *display, int min_cdclk)
> return display->cdclk.max_cdclk_freq;
> }
>
> +/*
> + * Lowest cdclk_table entry that satisfies min_cdclk AND keeps the
> + * supplied VCO. Returns 0 if no such entry exists.
> + */
> +static int bxt_calc_cdclk_for_vco(struct intel_display *display,
> + int min_cdclk, int vco)
> +{
> + const struct intel_cdclk_vals *table = display->cdclk.table;
> + int i;
> +
> + for (i = 0; table[i].refclk; i++) {
> + if (table[i].refclk == display->cdclk.hw.ref &&
> + table[i].cdclk >= min_cdclk &&
> + display->cdclk.hw.ref * table[i].ratio == vco)
> + return table[i].cdclk;
> + }
> +
> + return 0;
> +}
> +
> static int bxt_calc_cdclk_pll_vco(struct intel_display *display, int cdclk)
> {
> const struct intel_cdclk_vals *table = display->cdclk.table;
> @@ -3300,6 +3320,33 @@ static int bxt_modeset_calc_cdclk(struct intel_atomic_state *state)
> cdclk = bxt_calc_cdclk(display, min_cdclk);
> vco = bxt_calc_cdclk_pll_vco(display, cdclk);
>
> + /*
> + * Guard against VCO-changing CDCLK transitions that cause pipe FIFO
> + * underruns. When crawling up from VCO 614400 the intermediate
> + * frequencies are below min_cdclk; when crawling down from VCO
> + * 1382400 the DBUF ratio changes mid-modeset before watermarks are
> + * reprogrammed. Prefer a same-VCO cdclk_table entry (pure squash,
> + * no DBUF ratio change); only fall back to max_cdclk_freq when no
> + * such entry can satisfy min_cdclk.
> + */
> + if (HAS_CDCLK_SQUASH(display) && HAS_CDCLK_CRAWL(display) &&
> + display->cdclk.hw.vco > 0 && vco > 0 &&
> + display->cdclk.hw.vco != vco) {
> + if (cdclk > display->cdclk.hw.cdclk) {
> + int same_vco_cdclk;
> +
> + same_vco_cdclk = bxt_calc_cdclk_for_vco(display, min_cdclk,
> + display->cdclk.hw.vco);
> + if (same_vco_cdclk)
> + cdclk = same_vco_cdclk;
> + else
> + cdclk = display->cdclk.max_cdclk_freq;
> + } else {
> + cdclk = display->cdclk.hw.cdclk;
> + }
> + vco = bxt_calc_cdclk_pll_vco(display, cdclk);
> + }
> +
> cdclk_state->logical.vco = vco;
> cdclk_state->logical.cdclk = cdclk;
> cdclk_state->logical.voltage_level =
> --
> 2.25.1
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2026-06-08 13:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 12:50 [PATCH 0/2] Fix pipe fifo underruns during cdclk/DDB transitions Nemesa Garg
2026-06-08 12:50 ` [RFC PATCH 1/2] drm/i915/cdclk: Avoid VCO-change glitches Nemesa Garg
2026-06-08 13:11 ` Ville Syrjälä [this message]
2026-06-08 12:50 ` [RFC PATCH 2/2] drm/i915/wm: Wait a vblank before shrinking plane DDB Nemesa Garg
2026-06-08 13:14 ` Ville Syrjälä
2026-06-08 13:27 ` ✓ CI.KUnit: success for Fix pipe fifo underruns during cdclk/DDB transitions Patchwork
2026-06-08 17:27 ` ✓ i915.CI.BAT: " Patchwork
2026-06-08 21:38 ` ✗ i915.CI.Full: 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=aia_jxWyNrCWEPEW@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=nemesa.garg@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.