All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Erwin Springer" <aot.lerwin@gmail.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/display: Ignore disabled planes in async flip checks
Date: Sun, 15 Nov 2026 14:47:42 +0000	[thread overview]
Message-ID: <sashiko-outbox-215590@kernel.org> (raw)
In-Reply-To: <20261115-i915-async-planes-v1-1-d13498d0b6be@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] drm/i915/display: reachable drm_WARN_ON() in
  intel_async_flip_check_hw() with NV12 Y-plane
--

commit b042ec62b54473b2633218f68a54b0d394afbc1e
Author: Erwin Springer <aot.lerwin@gmail.com>

drm/i915/display: Ignore disabled planes in async flip checks

This commit skips planes that have neither an old nor a new framebuffer
in intel_async_flip_check_uapi() and intel_async_flip_check_hw() so that
unchanged disabled planes included in an atomic commit do not cause async
flips to be rejected.

> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index f79caeb5a82ec..defa55da52a74 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6173,6 +6173,14 @@ static int intel_async_flip_check_uapi(struct intel_atomic_state *state,
>  		if (plane->pipe != crtc->pipe)
>  			continue;
>  
> +		/*
> +		 * Userspace may add planes it doesn't change to the commit.
> +		 * A plane that is disabled and stays disabled takes no part
> +		 * in the async flip.
> +		 */
> +		if (!old_plane_state->uapi.fb && !new_plane_state->uapi.fb)
> +			continue;
> +
>  		/*
>  		 * TODO: Async flip is only supported through the page flip IOCTL
>  		 * as of now. So support currently added for primary plane only.
> @@ -6238,6 +6246,10 @@ static int intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
>  		if (plane->pipe != crtc->pipe)
>  			continue;
>  
> +		/* Disabled planes that stay disabled take no part in the flip. */
> +		if (!old_plane_state->hw.fb && !new_plane_state->hw.fb)
> +			continue;
> +
>  		/*
>  		 * Only async flip capable planes should be in the state
>  		 * if we're really about to ask the hardware to perform

[Severity: Medium]
Can this trigger drm_WARN_ON(display->drm, new_crtc_state->do_async_flip
&& !plane->async_flip) in intel_async_flip_check_hw() when a non-primary
plane is scanning out a planar YUV framebuffer (such as NV12 on ICL+)?

When a plane scans out a planar format, icl_check_nv12_planes() links it
to an unused SDR Y-plane via link_nv12_planes().  That Y-plane remains
disabled in UAPI (uapi.fb is NULL), but has a non-NULL hw.fb and
planar_linked_plane set.

If userspace submits atomic async flips on the primary plane while
including all UAPI-disabled planes on the pipe,
intel_async_flip_check_uapi() now skips the Y-plane because its old and
new uapi.fb are NULL.  Later in intel_atomic_check_planes(),
intel_joiner_add_affected_planes() sees the Y-plane's planar_linked_plane
and pulls the UV plane into the atomic state, and icl_check_nv12_planes()
re-links them with non-NULL hw.fb.  Once new_crtc_state->do_async_flip is
set on the following async flip, both planes bypass the !hw.fb check in
intel_async_flip_check_hw() and hit the drm_WARN_ON() because
plane->async_flip is NULL.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261115-i915-async-planes-v1-1-d13498d0b6be@gmail.com?part=1

      reply	other threads:[~2026-11-15 14:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-15 14:17 [PATCH] drm/i915/display: Ignore disabled planes in async flip checks Erwin Springer via B4 Relay
2026-11-15 14:17 ` Erwin Springer
2026-11-15 14:47 ` sashiko-bot [this message]

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-215590@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=aot.lerwin@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.