From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/i915/reset: Move pending_fb_pin handling to i915
Date: Sun, 12 Apr 2026 12:04:47 +1000 [thread overview]
Message-ID: <review-patch3-20260408233458.22666-4-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20260408233458.22666-4-ville.syrjala@linux.intel.com>
Patch Review
This moves the `pending_fb_pin` atomic counter from `display->restore` to `i915->` (i915-specific) so it's not a display-layer concern. The pending_fb_pin check and wedging are moved from `intel_display_reset_prepare()` into the i915 `intel_gt_reset_global()` caller.
**Issue in `i915_overlay.c`:** The patch adds `atomic_inc(&i915->pending_fb_pin)` before the pin and `atomic_dec(&i915->pending_fb_pin)` after `i915_gem_ww_ctx_fini()`, but critically, the decrement happens **before** checking `if (ret) return ERR_PTR(ret)`:
```c
atomic_inc(&i915->pending_fb_pin);
i915_gem_ww_ctx_init(&ww, true);
retry:
...
i915_gem_ww_ctx_fini(&ww);
atomic_dec(&i915->pending_fb_pin);
if (ret)
return ERR_PTR(ret);
```
On the success path, the counter is decremented immediately after pinning, before the overlay is actually using the pinned buffer. This matches the stated intent ("just cover the actual pinning part") but means the `pending_fb_pin` counter no longer reflects that a framebuffer is actively pinned for display — only that a pin operation is in-flight. The commit message acknowledges this change: "For some reason the overlay code kept the pending_fb_pin counter elevated for longer than just for the pin, but from now on it'll just cover the actual pinning part." This seems intentional but narrows the window where wedging would trigger. Whether that's acceptable depends on the actual deadlock scenario.
**Minor concern in `intel_overlay.c` (display side):** The patch removes the `atomic_inc/dec` pair from the display overlay code (`intel_overlay_do_put_image`), which previously wrapped both the pin call AND the rest of the overlay update. The `out_pin_section` error label is removed. This is fine since the i915-specific `i915_overlay_pin_fb` now handles it internally.
The rest of the `i915_fb_pin.c` and `i915_dpt.c` changes are mechanical s/display->restore.pending_fb_pin/i915->pending_fb_pin/ and look correct.
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-04-12 2:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 23:34 [PATCH 0/6] drm/i915/reset: Solve display vs. GPU reset deadlock, again Ville Syrjala
2026-04-08 23:34 ` [PATCH 1/6] dma-buf: Remove old lies about dma_fence_wait_any_timeout() not accepting some fences Ville Syrjala
2026-04-09 8:09 ` Jani Nikula
2026-04-09 10:39 ` Christian König
2026-04-12 2:04 ` Claude review: " Claude Code Review Bot
2026-04-08 23:34 ` [PATCH 2/6] drm/i915/reset: Reorganize display reset code Ville Syrjala
2026-04-09 8:13 ` Jani Nikula
2026-04-12 2:04 ` Claude review: " Claude Code Review Bot
2026-04-08 23:34 ` [PATCH 3/6] drm/i915/reset: Move pending_fb_pin handling to i915 Ville Syrjala
2026-04-09 8:17 ` Jani Nikula
2026-04-12 2:04 ` Claude Code Review Bot [this message]
2026-04-08 23:34 ` [PATCH 4/6] drm/xe/display: Add init_clock_gating.h stubs Ville Syrjala
2026-04-09 8:19 ` Jani Nikula
2026-04-12 2:04 ` Claude review: " Claude Code Review Bot
2026-04-08 23:34 ` [PATCH 5/6] drm/i915/reset: Handle the display vs. GPU reset deadlock using a custom dma-fence Ville Syrjala
2026-04-09 10:37 ` Jani Nikula
2026-04-09 10:46 ` Christian König
2026-04-09 11:19 ` Ville Syrjälä
2026-04-09 12:17 ` Christian König
2026-04-12 2:04 ` Claude review: " Claude Code Review Bot
2026-04-08 23:34 ` [PATCH 6/6] drm/i915/display: Make fence timeout infinite Ville Syrjala
2026-04-09 10:51 ` Jani Nikula
2026-04-12 2:04 ` Claude review: " Claude Code Review Bot
2026-04-12 2:04 ` Claude review: drm/i915/reset: Solve display vs. GPU reset deadlock, again Claude Code Review Bot
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=review-patch3-20260408233458.22666-4-ville.syrjala@linux.intel.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox