All of lore.kernel.org
 help / color / mirror / Atom feed
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 v3 3/3] drm/i915/fbc: nuke CFB if Plane setting (except for surf addr) changes
Date: Wed, 23 Sep 2026 17:45:09 +0000	[thread overview]
Message-ID: <20260923174510.2F0B31F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260923172803.1011636-4-austin.hu@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] drm/i915/fbc: redundant full dirty rect assignment is dead code
--

commit b3f8f671dc6c5ad11aa10ae1d17ed6ba529a91c9
Author: Austin Hu <austin.hu@intel.com>

    drm/i915/fbc: nuke CFB if Plane setting (except for surf addr) changes
    
    When FBC Dirty Rectangle mode is enabled, any non-PLANE_SURF register
    update requires fetching the full plane frame buffer from memory to
    re-compress and update the CFB in stolen memory. This commit checks
    plane state attributes during atomic commits and forces a full CFB nuke
    if any setting other than the surface address changes.

> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> index e8583092de663..1ab583eadfcb3 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c

[ ... ]

> @@ -1583,7 +1633,15 @@ __intel_fbc_prepare_dirty_rect(const struct intel_plane_state *plane_state,
>  		return;
>  	}
>  
> -	if (drm_rect_visible(damage)) {
> +	if (!intel_fbc_can_flip_nuke(state, crtc, plane)) {
> +		if (HAS_FBC_DIRTY_RECT(display))
> +			drm_dbg_kms(display->drm,
> +				    "[PLANE:%d:%s] Non surf addr changed for FBC DIRTY RECT\n",
> +				    plane->base.base.id, plane->base.name);
> +
> +		/* compress the entire region due to non PLANE_SURF updating. */
> +		*fbc_dirty_rect = DRM_RECT_INIT(0, y_offset, width, height);

[Severity: Low]
Is this fallback assignment to *fbc_dirty_rect dead code?

If intel_fbc_can_flip_nuke() returns false here, that same condition causes
__intel_fbc_pre_update() to unconditionally call intel_fbc_deactivate(),
disabling FBC in hardware.

When FBC is subsequently reactivated in __intel_fbc_post_update(), the
hardware naturally fetches the entire plane from scratch to build the initial
compressed framebuffer.

Doesn't this disable/enable cycle bypass the programmed XE3_FBC_DIRTY_RECT
register on the first frame, meaning this assignment never takes effect?

> +	} else if (drm_rect_visible(damage)) {
>  		int y1, y2;
>  
>  		if (plane_state->hw.rotation & DRM_MODE_ROTATE_180) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923172803.1011636-1-austin.hu@intel.com?part=3

  reply	other threads:[~2026-09-23 17:45 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
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 [this message]
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=20260923174510.2F0B31F000FF@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.