From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/panthor: Process GPU events in IRQ context Date: Sat, 16 May 2026 13:32:47 +1000 Message-ID: In-Reply-To: <20260512-panthor-signal-from-irq-v2-11-95c614a739cb@collabora.com> References: <20260512-panthor-signal-from-irq-v2-0-95c614a739cb@collabora.com> <20260512-panthor-signal-from-irq-v2-11-95c614a739cb@collabora.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 Similar to patch 9, converts the GPU IRQ handler to a hard handler. The han= dler is even simpler than the JOB case: ```c static irqreturn_t panthor_gpu_irq_raw_handler(int irq, void *data) { struct panthor_irq *pirq =3D data; ... u32 status =3D gpu_read(gpu->irq.iomem, INT_STAT); if (!status) return IRQ_NONE; gpu_write(gpu->irq.iomem, INT_CLEAR, status); // ... process events ... return IRQ_HANDLED; } ``` **Note:** This handler bypasses the `panthor_irq` state machine entirely = =E2=80=94 it doesn't check/set `PROCESSING`/`ACTIVE` states. It reads `INT_= STAT`, clears, processes, and returns. The `panthor_irq_{suspend,resume}` f= unctions still manage the `INT_MASK` register, so suspending will mask inte= rrupts and no events will fire. This is acceptable because the GPU handler = doesn't need the threaded handler's mask-unmask dance; it just processes ev= ents directly. The handler body is the same as the old `panthor_gpu_irq_handler()` =E2=80= =94 it calls `gpu_write(INT_CLEAR)`, logs faults, and does `wake_up_all()` = under `reqs_lock` (now with `irqsave`). All of this is IRQ-safe. No concerns. --- ## Summary The series is well-organized with clean incremental steps. The main risk ar= ea is patch 6 (the `events_lock` introduction and fence signalling from IRQ= context), but the approach is correct. All lock conversions to `irqsave` a= ppear correct. The `dma_fence_signal_locked()` from hard IRQ context is per= missible and is exactly the pattern used by most other DRM drivers. I have no blocking objections. The series looks ready to merge after broade= r testing is completed. --- Generated by Claude Code Patch Reviewer