From: sashiko-bot@kernel.org
To: "Austin Hu" <austin.hu@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v3 2/3] drm/i915/fbc: fbc_dirty_rect restrictions and logging
Date: Wed, 23 Sep 2026 17:44:43 +0000 [thread overview]
Message-ID: <20260923174444.6DEA21F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260923172803.1011636-3-austin.hu@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] drm/i915/fbc: invalid FBC dirty rect for 180-degree rotation when y_offset > 0
- [Medium] drm/i915/fbc: spurious debug log spam on 180-degree rotated planes
--
commit e741ad7c090c4e479fc0c403a1f27d2b43fe1e44
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 0f841e5b42826..e8583092de663 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
[ ... ]
> @@ -1580,11 +1583,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]
Does this math work correctly when y_offset is greater than 0?
Since damage coordinates are in absolute framebuffer space and bounded by
[y_offset, y_end], damage->y2 can be larger than height when y_offset > 0.
This would cause inv_y1 to become negative.
Adding this negative value to y_offset makes the result less than y_offset,
causing the clamp() to always collapse the dirty rect coordinate to y_offset.
Will this cause screen update failures for rotated planes with a source crop?
> + } 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)
[Severity: Medium]
Will this condition generate false positive log spam when the plane has
180-degree rotation?
For a rotated plane, y1 and y2 are computed as inverted coordinates, but
this check compares them directly against the original non-inverted damage
coordinates. Since inversion naturally changes the coordinate values,
won't this almost always evaluate to true and falsely log that clamping
occurred?
> + 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);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260923172803.1011636-1-austin.hu@intel.com?part=2
next prev parent reply other threads:[~2026-09-23 17:44 UTC|newest]
Thread overview: 24+ 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
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
2026-08-13 5:40 ` ✗ Xe.CI.FULL: " Patchwork
2026-08-25 16:56 ` [PATCH v2 0/2] drm/i915/fbc: Dirty rectangle bounding " Austin Hu
2026-08-25 16:56 ` [PATCH v2 1/2] drm/i915/fbc: fbc_dirty_rect restrictions and logging Austin Hu
2026-08-25 17:16 ` sashiko-bot
2026-08-25 16:56 ` [PATCH v2 2/2] drm/i915/fbc: nuke CFB if Plane setting (except for surf addr) changes Austin Hu
2026-08-25 17:13 ` sashiko-bot
2026-09-07 11:28 ` Jani Nikula
2026-09-23 17:28 ` [PATCH v3 0/3] drm/i915/fbc: Dirty rectangle bounding and CFB Austin Hu
2026-09-24 11:25 ` Jani Nikula
2026-09-25 21:59 ` Hu, Austin
2026-09-23 17:28 ` [PATCH v3 1/3] drm/i915/display/fbc: Move intel_fbc_can_flip_nuke() higher up Austin Hu
2026-09-23 17:28 ` [PATCH v3 2/3] drm/i915/fbc: fbc_dirty_rect restrictions and logging Austin Hu
2026-09-23 17:44 ` sashiko-bot [this message]
2026-09-23 17:28 ` [PATCH v3 3/3] drm/i915/fbc: nuke CFB if Plane setting (except for surf addr) changes Austin Hu
2026-09-23 17:45 ` sashiko-bot
2026-09-24 0:56 ` ✗ Fi.CI.BUILD: failure for drm/i915/fbc: Dirty rectangle bounds enforcement and CFB nuke handling 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=20260923174444.6DEA21F000FF@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.