All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: gregkh@linuxfoundation.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: Patch "drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips" has been added to the 6.18-stable tree
Date: Wed, 29 Jul 2026 11:29:39 +0000	[thread overview]
Message-ID: <20260729112940.618B61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <2026072928-caring-papaya-ed97@gregkh>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] In the MPO (Multi-Plane Overlay) path, setting `ignore_damage_clips` fails to trigger a full update if the framebuffer and bounding box haven't changed, resulting in a dropped display update.
--

--- Patch [1]: Patch "drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips" has been added to the 6.18-stable tree ---
commit e9e0d8ca6e7cebee70fe44f3b50f1d51b508e3bf
Author: gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>
Subject: drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips

This commit updates the DCN driver code to support the ignore_damage_clips
flag from drm_plane_state. By bypassing damage clip retrieval when this flag
is set, the driver is intended to perform a full display update instead of a
partial one.

> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 7fe40bbba2658..97e14e02bf8c0 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c

[ ... ]

> @@ -6229,8 +6229,10 @@ static void fill_dc_dirty_rects(struct drm_plane *plane,
>  	if (new_plane_state->rotation != DRM_MODE_ROTATE_0)
>  		goto ffu;
>  
> -	num_clips = drm_plane_get_damage_clips_count(new_plane_state);
> -	clips = drm_plane_get_damage_clips(new_plane_state);
> +	if (!new_plane_state->ignore_damage_clips) {
> +		num_clips = drm_plane_get_damage_clips_count(new_plane_state);
> +		clips = drm_plane_get_damage_clips(new_plane_state);
> +	}
>  

[Severity: High]
When ignore_damage_clips is true, num_clips remains 0. Does this cause an
issue for the MPO (Multi-Plane Overlay) path further down in this function?

Looking at the MPO path later in fill_dc_dirty_rects():

drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:fill_dc_dirty_rects() {
    ...
    fb_changed = old_plane_state->fb->base.id !=
                 new_plane_state->fb->base.id;
    bb_changed = (old_plane_state->crtc_x != new_plane_state->crtc_x ||
                  old_plane_state->crtc_y != new_plane_state->crtc_y ||
                  ...);
    ...
    if (num_clips) {
        for (; i < num_clips; clips++)
            ...
    } else if (fb_changed && !bb_changed) {
        fill_dc_dirty_rect(new_plane_state->plane, &dirty_rects[i],
            ...
    }

    flip_addrs->dirty_rect_count = i;
    return;
}

If dm_crtc_state->mpo_requested is true, and both fb_changed and bb_changed
are false, the code bypasses the goto ffu (Full Frame Update) logic used by
the non-MPO path.

Since num_clips is 0, the MPO logic will not add any dirty rects, resulting in
flip_addrs->dirty_rect_count being 0. 

Instead of forcing a full display update when ignore_damage_clips is set, 
could this silently drop the display update entirely?

>  	if (num_clips && (!amdgpu_damage_clips || (amdgpu_damage_clips < 0 &&
>  						   is_psr_su)))
>  		goto ffu;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/2026072928-caring-papaya-ed97@gregkh?part=1

      reply	other threads:[~2026-07-29 11:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 11:19 Patch "drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips" has been added to the 6.18-stable tree gregkh
2026-07-29 11:29 ` 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=20260729112940.618B61F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.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.