From: sashiko-bot@kernel.org
To: "Austin Hu" <austin.hu@intel.com>
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915/fbc: fbc_dirty_rect restrictions and logging
Date: Wed, 12 Aug 2026 22:08:52 +0000 [thread overview]
Message-ID: <20260812220853.73EEF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812215350.3753102-2-austin.hu@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect coordinate space math in the 180-degree rotation branch causes the FBC dirty rectangle to collapse, breaking FBC tracking.
- [Medium] The 'FBC dirty rect out of range' debug warning will trigger spuriously on almost every frame when the plane is rotated 180 degrees.
--
--- Patch [1]: [PATCH 1/2] drm/i915/fbc: fbc_dirty_rect restrictions and logging ---
commit 234fb7237db4bb8e467458e88cc6ed3f6e850511
Author: Charlton Lin <charlton.lin@intel.com>
drm/i915/fbc: fbc_dirty_rect restrictions and logging
Clamp the FBC dirty rectangle coordinates to the valid frame buffer
range [y_offset, y_end] to prevent out-of-bounds coordinates, and
log a debug message when clamping occurs.
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> index f61b4a218d6ef..c0fed695af0da 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
[ ... ]
> @@ -1535,11 +1538,41 @@ __intel_fbc_prepare_dirty_rect(const struct intel_plane_state *plane_state,
> return;
> }
>
> - if (drm_rect_visible(damage))
> - *fbc_dirty_rect = *damage;
> - else
> + if (drm_rect_visible(damage)) {
> + int y1, y2;
> +
> + if (plane_state->hw.rotation & DRM_MODE_ROTATE_180) {
> + /* Under 180 degree rotation, coordinate system is inverted */
> + int inv_y1 = height - damage->y2;
> + int inv_y2 = height - damage->y1;
> +
> + y1 = clamp(y_offset + inv_y1, y_offset, y_end);
> + y2 = clamp(y_offset + inv_y2, y_offset, y_end);
[Severity: High]
Can this math result in collapsed dirty rectangles?
Because damage->y2 already includes the absolute y_offset, height - damage->y2
yields a large negative number. When y_offset is added back, the result falls
well below y_offset, causing both y1 and y2 to unconditionally clamp to
y_offset.
This collapses the FBC dirty rectangle to a 0-height region starting at
y_offset, entirely missing the actual damaged pixels.
> + } else {
> + y1 = clamp(damage->y1, y_offset, y_end);
> + y2 = clamp(damage->y2, y_offset, y_end);
> + }
> +
> + /*
> + * Clamp dirty rect to the valid FB range [y_offset, y_end].
> + * Per Bspec:
> + * start_line >= y_offset
> + * end_line <= y_offset + plane_height
> + */
> + if (y1 != damage->y1 || y2 != damage->y2)
> + drm_dbg_kms(display->drm,
> + "[PLANE:%d:%s] FBC dirty rect out of range: y1=%d y2=%d clamped to y1=%d y2=%d (y_offset=%d y_end=%d)\n",
> + plane->base.base.id, plane->base.name,
> + damage->y1, damage->y2, y1, y2, y_offset, y_end);
[Severity: Medium]
Will this warning trigger spuriously on almost every frame when the plane is
rotated 180 degrees?
For 180-degree planes, the code intentionally alters y1 and y2 to represent
inverted coordinates. The warning condition compares these new inverted
coordinates directly against the original, non-inverted coordinates.
Because an inverted coordinate will inherently mismatch a non-inverted one,
this condition evaluates to true on nearly every atomic update involving damage
for rotated planes.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260812215350.3753102-1-austin.hu@intel.com?part=1
next prev parent reply other threads:[~2026-08-12 22:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 21:53 [PATCH 0/2] drm/i915/fbc: Dirty rectangle bounds enforcement and CFB nuke handling Austin Hu
2026-08-12 21:53 ` [PATCH 1/2] drm/i915/fbc: fbc_dirty_rect restrictions and logging Austin Hu
2026-08-12 22:08 ` sashiko-bot [this message]
2026-08-12 21:53 ` [PATCH 2/2] drm/i915/fbc: nuke CFB if Plane setting (except for surf addr) changes Austin Hu
2026-08-12 22:10 ` sashiko-bot
2026-08-12 22:03 ` ✓ CI.KUnit: success for drm/i915/fbc: Dirty rectangle bounds enforcement and CFB nuke handling Patchwork
2026-08-12 22:44 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-12 22:57 ` ✗ i915.CI.BAT: failure " 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=20260812220853.73EEF1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=austin.hu@intel.com \
--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.