From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: gpu: host1x: skip redundant HW state update
Date: Sat, 16 May 2026 11:02:37 +1000
Message-ID: <review-patch2-20260514103153.766343-3-tanmayp@nvidia.com>
In-Reply-To: <20260514103153.766343-3-tanmayp@nvidia.com>
References: <20260514103153.766343-1-tanmayp@nvidia.com> <20260514103153.766343-3-tanmayp@nvidia.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

**Summary:** In `host1x_intr_handle_interrupt()`, skip the call to `host1x_=
intr_update_hw_state()` when no fences remain, since the ISR has already di=
sabled and acknowledged the interrupt.

**Analysis:**

Looking at `process_32_syncpts()` in `intr_hw.c:14-26`:

```c
host1x_sync_writel(host, val, HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE(reg_off=
set));
host1x_sync_writel(host, val, HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(reg=
_offset));

for_each_set_bit(id, &val, 32)
    host1x_intr_handle_interrupt(host, reg_offset * 32 + id);
```

The ISR writes to `INT_DISABLE` and `INT_STATUS` before calling `host1x_int=
r_handle_interrupt()`. When the fence list is empty after processing, `host=
1x_intr_update_hw_state()` would call `host1x_intr_disable_syncpt_intr()` (=
`intr_hw.c:138-145`), which does exactly the same two writes:

```c
host1x_sync_writel(host, BIT(id % 32), HOST1X_SYNC_SYNCPT_THRESH_INT_DISABL=
E(id / 32));
host1x_sync_writel(host, BIT(id % 32), HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_S=
TATUS(id / 32));
```

So the optimization is correct: when the list is empty, `host1x_intr_update=
_hw_state` would just repeat the disable+ack that already happened. The pat=
ch skips this redundant work:

```c
if (!list_empty(&sp->fences.list))
    host1x_intr_update_hw_state(host, sp);
```

When fences remain, `host1x_intr_update_hw_state` re-programs the threshold=
 to the next fence's value and re-enables the interrupt =E2=80=94 this path=
 is still taken.

**One consideration:** If a new fence is added between the ISR's disable/ac=
k and the `list_empty` check, could we miss the re-enable? No =E2=80=94 `ho=
st1x_intr_add_fence_locked()` calls `host1x_intr_update_hw_state()` itself,=
 and it takes `sp->fences.lock`, which `host1x_intr_handle_interrupt` holds=
 during this check. So there's no race.

**Verdict: Clean, correct optimization. No issues.**

---
Generated by Claude Code Patch Reviewer