From: "Hogander, Jouni" <jouni.hogander@intel.com>
To: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"j@metarealtyinc.ca" <j@metarealtyinc.ca>
Cc: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>,
"Nikula, Jani" <jani.nikula@intel.com>,
"Manna, Animesh" <animesh.manna@intel.com>
Subject: Re: [PATCH] drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake
Date: Thu, 3 Sep 2026 04:11:32 +0000 [thread overview]
Message-ID: <ddb81e28fa7cee2b8bf4e7f7e2f679da2d36abb2.camel@intel.com> (raw)
In-Reply-To: <20260902162531.73598-1-j@metarealtyinc.ca>
On Wed, 2026-09-02 at 12:25 -0400, Jake Steinman wrote:
> On display version 20+ the extended fast wake time is programmed in
> ALPM_CTL and the IO buffer wake in PSR2_CTL.
> intel_alpm_compute_params()
> derives both from precharge + preamble + PHY wake + tFW exit latency
> (42 us here); the IO buffer wake only differs when
> io_buffer_wake_time
> is larger than the precharge, which is not the case on this panel. So
> both end up on the same number of scanlines, 11 on this mode.
>
> On the Dell XPS 16 DA16260 (Panther Lake, LG panel with sink OUI
> 00:22:b9, 3200x2000@120, 4 x 2.7 Gbps, DSC) equal values make every
> ALPM
> link wake fail: the sink sets the Link CRC error bit in
> DP_PSR_ERROR_STATUS within ~25 ms of it being cleared, on every wake,
> for
> as long as PSR2 is active. Changing the two fields at runtime shows
> that
> the relation between them matters, not the absolute time:
>
> fast wake 11 / IO wake 11 -> CRC error on every wake
> fast wake 12 / IO wake 11 -> clean
> fast wake 40 / IO wake 40 -> CRC error on every wake
> fast wake 40 / IO wake 20 -> clean
> fast wake 11 / IO wake 20 -> CRC error on every wake
>
> The fast wake sequence has to start strictly before the IO buffer
> wake.
> With the current values PSR2 on this panel only looked usable because
> the constant wake failures kept forcing the sink to resync.
>
> Make fast_wake_lines strictly greater than io_wake_lines on display
> 20+,
> or, when already at the maximum, put the IO buffer wake one line
> below
> it. Use the larger of the two in the vblank and guardband checks,
> which
> so far only looked at the IO buffer wake on display 20+.
Thank you for the patch. Have you tried increasing vblank/guardband
alone? Addition to vblank and guardband your change is also affecting
how PSR2/ALPM is configured.
>
> This is one of the two machines behind the eDP Panel Replay quirk in
> intel_quirks.c (Dell XPS 14 DA14260 / XPS 16 DA16260). The change
> does
> not make Panel Replay or PSR2 selective updates work there on its
> own:
> with the wake fixed the panel still never receives a selective update
> (sink 0x200a stays at PSR_STATE only) while the PSR2 engine sits in
> SU_STANDBY and consumes the TRANS_PUSH frame change events. That is
> reported separately on intel-gfx.
Your change is conflicting with the spec. It might be a trace to the
actual problem. Please note that io wake time can be >= fast_wake_time
and these formulas are directly taken from our hw spec.
io_wake_time = max(precharge, io_buffer_wake_time(crtc_state))
+ preamble + phy_wake + tfw_exit_latency;
fast_wake_time = precharge + preamble + phy_wake +
tfw_exit_latency;
Have you tried fiddling with the fast wake sync pulse count? See
driver/gpu/drm/i915/display/intel_dp_auc.c:intel_dp_aux_fw_sync_len.
We could consider using something like in this patch as a quirk if it
solves your problem.
BR,
Jouni Högander
>
> Link:
> https://lore.kernel.org/intel-gfx/20260902162150.58778-1-j@metarealtyinc.ca/
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7521
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7682
> Cc: Jouni Högander <jouni.hogander@intel.com>
> Cc: Animesh Manna <animesh.manna@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: intel-xe@lists.freedesktop.org
> Signed-off-by: Jake Steinman <j@metarealtyinc.ca>
> ---
> diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c
> b/drivers/gpu/drm/i915/display/intel_alpm.c
> index f138376..c244273 100644
> --- a/drivers/gpu/drm/i915/display/intel_alpm.c
> +++ b/drivers/gpu/drm/i915/display/intel_alpm.c
> @@ -238,8 +238,29 @@ bool intel_alpm_compute_params(struct intel_dp
> *intel_dp,
> io_wake_lines = fast_wake_lines = max_wake_lines;
>
> /* According to Bspec lower limit should be set as 7 lines.
> */
> - crtc_state->alpm_state.io_wake_lines = max(io_wake_lines,
> 7);
> - crtc_state->alpm_state.fast_wake_lines =
> max(fast_wake_lines, 7);
> + io_wake_lines = max(io_wake_lines, 7);
> + fast_wake_lines = max(fast_wake_lines, 7);
> +
> + /*
> + * On display 20+ the extended fast wake sequence programmed
> in
> + * ALPM_CTL has to start strictly before the IO buffer wake
> programmed
> + * in PSR2_CTL. Both are derived from the same precharge,
> preamble,
> + * PHY wake and tFW exit latency above, so they normally end
> up on the
> + * same number of lines. With equal values the
> + * LG panel (sink OUI 00:22:b9) in the Dell XPS 14/16
> DA14260/DA16260
> + * reports a Link CRC error on every link wake. One extra
> fast wake
> + * line is enough to fix it; when we are already at the
> maximum keep
> + * the IO buffer wake one line below the fast wake instead.
> + */
> + if (DISPLAY_VER(display) >= 20 && fast_wake_lines <=
> io_wake_lines) {
> + if (io_wake_lines < max_wake_lines)
> + fast_wake_lines = io_wake_lines + 1;
> + else
> + io_wake_lines = fast_wake_lines - 1;
> + }
> +
> + crtc_state->alpm_state.io_wake_lines = io_wake_lines;
> + crtc_state->alpm_state.fast_wake_lines = fast_wake_lines;
>
> return true;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index c0933dd..ec80a2e 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1443,7 +1443,8 @@ static bool wake_lines_fit_into_vblank(struct
> intel_dp *intel_dp,
> wake_lines = DISPLAY_VER(display) < 20 ?
> psr2_block_count_lines(crtc_state-
> >alpm_state.io_wake_lines,
> crtc_state-
> >alpm_state.fast_wake_lines) :
> - crtc_state->alpm_state.io_wake_lines;
> + max(crtc_state->alpm_state.io_wake_lines,
> + crtc_state->alpm_state.fast_wake_lines);
>
> /*
> * Guardband has not been computed yet, so we conservatively
> check if the
> @@ -4556,7 +4557,8 @@ void intel_psr_compute_config_late(struct
> intel_dp *intel_dp,
> wake_lines = DISPLAY_VER(display) < 20 ?
> psr2_block_count_lines(crtc_state-
> >alpm_state.io_wake_lines,
> crtc_state-
> >alpm_state.fast_wake_lines) :
> - crtc_state->alpm_state.io_wake_lines;
> + max(crtc_state-
> >alpm_state.io_wake_lines,
> + crtc_state-
> >alpm_state.fast_wake_lines);
> else
> wake_lines = 0;
>
> @@ -4612,7 +4614,8 @@ int intel_psr_min_guardband(struct
> intel_crtc_state *crtc_state)
> wake_lines = DISPLAY_VER(display) < 20 ?
> psr2_block_count_lines(crtc_state-
> >alpm_state.io_wake_lines,
> crtc_state-
> >alpm_state.fast_wake_lines) :
> - crtc_state->alpm_state.io_wake_lines;
> + max(crtc_state-
> >alpm_state.io_wake_lines,
> + crtc_state-
> >alpm_state.fast_wake_lines);
> else
> return 0;
>
next prev parent reply other threads:[~2026-09-03 4:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 16:25 [PATCH] drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake Jake Steinman
2026-09-03 4:11 ` Hogander, Jouni [this message]
2026-09-03 13:14 ` Jake Steinman
2026-09-03 13:17 ` [PATCH v2] drm/i915/alpm: Add a quirk to keep the " Jake Steinman
2026-09-03 16:14 ` sashiko-bot
[not found] ` <20260904004308.185788-1-j@metarealtyinc.ca>
2026-09-04 4:47 ` [PATCH v3] " Hogander, Jouni
[not found] ` <20260904114835.483057-1-j@metarealtyinc.ca>
2026-09-04 12:51 ` Hogander, Jouni
2026-09-03 16:09 ` ✗ LGCI.VerificationFailed: failure for drm/i915/alpm: Keep the extended fast wake ahead of the IO buffer wake (rev2) 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=ddb81e28fa7cee2b8bf4e7f7e2f679da2d36abb2.camel@intel.com \
--to=jouni.hogander@intel.com \
--cc=animesh.manna@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=j@metarealtyinc.ca \
--cc=jani.nikula@intel.com \
--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;
as well as URLs for NNTP newsgroup(s).