intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
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;
>  


  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).