All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Thomas Zimmermann" <tzimmermann@suse.de>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/display: Handle struct drm_plane_state.ignore_damage_clips
Date: Wed, 01 Jul 2026 13:23:59 +0000	[thread overview]
Message-ID: <20260701132359.BE4101F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701130929.234695-1-tzimmermann@suse.de>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm_atomic_helper_check_plane_damage() is placed too late in the atomic check pipeline and conditionally bypassed, breaking the damage clipping contract during modesets.
--

commit 5c79bcf5010895b431b3c2135c7b80a5163d8e9f
Author: Thomas Zimmermann <tzimmermann@suse.de>

drm/i915/display: Handle struct drm_plane_state.ignore_damage_clips

This commit introduces a call to drm_atomic_helper_check_plane_damage() in
intel_psr2_sel_fetch_update() to selectively ignore damage clipping in certain
framebuffer changes.

> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
> index 92af21d823a37..5a155f60110fb 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
[ ... ]
> @@ -2949,6 +2949,9 @@ int intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
>  		src = drm_plane_state_src(&new_plane_state->uapi);
>  		drm_rect_fp_to_int(&src, &src);
>  
> +		/* Prepare plane-damage state before using it */
> +		drm_atomic_helper_check_plane_damage(&state->base, &new_plane_state->uapi);
> +
>  		if (!drm_atomic_helper_damage_merged(&old_plane_state->uapi,

[Severity: High]
Is this call to drm_atomic_helper_check_plane_damage() placed too late in the
atomic check pipeline?

By placing it here in intel_psr2_sel_fetch_update() (which runs during the CRTC
check phase), intel_plane_atomic_check() has already run and called
intel_plane_copy_uapi_plane_damage(). That means new_plane_state->damage was
already calculated using the unsanitized fb_damage_clips before this check
could clear them during a full modeset.

Additionally, this loop selectively skips planes on non-PSR2 CRTCs or planes
with changed visibility (e.g. via the continue statements earlier in the loop).
Doesn't this mean the damage state is left unsanitized for those skipped
planes, potentially causing visual corruption when restricted clip rectangles
are used instead of updating the full plane?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701130929.234695-1-tzimmermann@suse.de?part=1

  reply	other threads:[~2026-07-01 13:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 13:07 [PATCH] drm/i915/display: Handle struct drm_plane_state.ignore_damage_clips Thomas Zimmermann
2026-07-01 13:23 ` sashiko-bot [this message]
2026-07-01 15:12   ` Thomas Zimmermann
2026-07-01 15:00 ` ✓ CI.KUnit: success for " Patchwork
2026-07-01 15:43 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-07-02  0:52 ` ✓ i915.CI.BAT: success " Patchwork
2026-07-02  9:38 ` ✓ Xe.CI.FULL: " Patchwork
2026-07-02 18:44 ` ✓ i915.CI.Full: " 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=20260701132359.BE4101F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tzimmermann@suse.de \
    /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.