All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ville Syrjala" <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 06/10] drm/i915: Wait for timing generator to start in intel_crtc_vblank_on() on HSW+
Date: Fri, 30 Oct 2026 17:32:47 +0000	[thread overview]
Message-ID: <sashiko-outbox-191348@kernel.org> (raw)
In-Reply-To: <20261030171327.29829-7-ville.syrjala@linux.intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/i915: intel_pipe_vblank_on() scanline wait times out on DSI
--

commit a024447aed84d4ab8f0e7bb2ee11d21475e5b408
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Wait for timing generator to start in intel_crtc_vblank_on() on HSW+

This commit waits for the pipe scanline counter to start moving inside
intel_pipe_vblank_on() on Haswell and newer platforms before enabling
vblank interrupts.

> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> index a28f4a088e587..209d5a18ee8d9 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -128,8 +128,21 @@ u32 intel_crtc_max_vblank_count(const struct intel_crtc_state *crtc_state)
>  
>  void intel_pipe_vblank_on(const struct intel_crtc_state *crtc_state)
>  {
> +	struct intel_display *display = to_intel_display(crtc_state);
>  	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
> +	/*
> +	 * Make sure the timing generator has really started so
> +	 * the sampled frame/scanline counter values don't jump
> +	 * erratically.
> +	 *
> +	 * TODO do this for older platforms as well after
> +	 * rearranging the modeset sequence a bit.
> +	 */
> +	if (DISPLAY_VER(display) >= 9 ||
> +	    display->platform.broadwell || display->platform.haswell)
> +		intel_wait_for_pipe_scanline_moving(crtc);

[Severity: Medium]
Will calling intel_wait_for_pipe_scanline_moving() unconditionally on
DISPLAY_VER(display) >= 9 time out for 100 ms and log a false error on
Broxton/Geminilake DSI and Gen11+ DSI command mode?

intel_wait_for_pipe_scanline_moving() calls wait_for_pipe_scanline_moving() ->
pipe_scanline_is_moving(), which directly polls PIPEDSL:

drivers/gpu/drm/i915/display/intel_vblank.c:pipe_scanline_is_moving() {
	intel_reg_t reg = PIPEDSL(display, pipe);
	u32 line1, line2;

	line1 = intel_de_read(display, reg) & PIPEDSL_LINE_MASK;
	msleep(5);
	line2 = intel_de_read(display, reg) & PIPEDSL_LINE_MASK;

	return line1 != line2;
}

On Broxton (DISPLAY_VER 9) and Geminilake (DISPLAY_VER 10) MIPI DSI, timings
are driven from the port rather than the CPU transcoder, and PIPEDSL does not
increment. Because of this, intel_dsi_compute_config() and
bxt_dsi_get_pipe_config() set I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP, and
__intel_get_crtc_scanline() skips reading PIPEDSL:

drivers/gpu/drm/i915/display/intel_vblank.c:__intel_get_crtc_scanline() {
	if (crtc->mode_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP)
		return __intel_get_crtc_scanline_from_timestamp(crtc);

	vtotal = intel_mode_vtotal(mode);

	position = intel_de_read_fw(display, PIPEDSL(display, pipe)) & PIPEDSL_LINE_MASK;
	...
}

When bxt_dsi_enable() -> intel_crtc_vblank_on() -> intel_pipe_vblank_on() runs
(or during intel_modeset_setup_hw_state()), polling PIPEDSL will see a static
value and time out.

Similarly, on Gen11+ DSI command mode (where I915_MODE_FLAG_DSI_USE_TE0 or
I915_MODE_FLAG_DSI_USE_TE1 is set in crtc_state->mode_flags),
gen11_dsi_configure_transcoder() configures the transcoder in CMD_MODE_TE_GATE
without periodic updates. When gen11_dsi_enable() calls intel_crtc_vblank_on()
during intel_enable_crtc(), no frame update has been requested yet because
icl_dsi_frame_update() is only called later in intel_update_crtc() ->
intel_pipe_update_end():

drivers/gpu/drm/i915/display/intel_crtc.c:intel_pipe_update_end() {
	...
	if (DISPLAY_VER(display) >= 11 &&
	    intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
		icl_dsi_frame_update(new_crtc_state);
	...
}

Should intel_pipe_vblank_on() skip intel_wait_for_pipe_scanline_moving() when
crtc_state->mode_flags has I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP or
I915_MODE_FLAG_DSI_USE_TE0 / I915_MODE_FLAG_DSI_USE_TE1 set?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261030171327.29829-1-ville.syrjala@linux.intel.com?part=6

  reply	other threads:[~2026-10-30 17:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-30 17:13 [PATCH 00/10] drm/i915: Enable vblanks after the timing generator has started Ville Syrjala
2026-10-30 17:13 ` [PATCH 01/10] drm/i915: Disable port sync if VRR is enabled Ville Syrjala
2026-10-30 17:13 ` [PATCH 02/10] drm/i915: Do intel_crtc_vblank_on() later on HSW+ Ville Syrjala
2026-10-30 17:13 ` [PATCH 03/10] drm/i915: Handle joined pipes inside intel_crtc_vblank_{on, off}() Ville Syrjala
2026-10-30 17:26   ` sashiko-bot
2026-10-30 17:49     ` Ville Syrjälä
2026-10-30 17:13 ` [PATCH 04/10] Revert "drm/i915/display: Avoid stale PIPE_SCANLINE values after crtc_enable" Ville Syrjala
2026-10-30 17:13 ` [PATCH 05/10] drm/i915: Fix intel_crtc_vblank_on() with port sync Ville Syrjala
2026-10-30 17:13 ` [PATCH 06/10] drm/i915: Wait for timing generator to start in intel_crtc_vblank_on() on HSW+ Ville Syrjala
2026-10-30 17:32   ` sashiko-bot [this message]
2026-10-30 18:07     ` Ville Syrjälä
2026-10-30 17:13 ` [PATCH 07/10] drm/i915: Reduce the sleep inside pipe_scanline_is_moving() Ville Syrjala
2026-10-30 17:13 ` [PATCH 08/10] drm/i915: Document timing generator start/stop behaviour on HSW+ Ville Syrjala
2026-10-30 17:13 ` [PATCH 09/10] drm/i915: Fix FEC wait with port sync on pre-LNL Ville Syrjala
2026-10-30 17:29   ` sashiko-bot
2026-10-30 17:13 ` [PATCH 10/10] drm/i915: Allow joiner with port sync Ville Syrjala
2026-10-30 17:38   ` sashiko-bot
2026-10-30 18:23     ` Ville Syrjälä
2026-10-30 17:20 ` ✗ CI.checkpatch: warning for drm/i915: Enable vblanks after the timing generator has started Patchwork
2026-10-30 17:23 ` ✓ CI.KUnit: success " Patchwork
2026-10-30 17:59 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-30 18:03 ` ✓ i915.CI.BAT: " 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=sashiko-outbox-191348@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --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 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.