Claude review: drm/panthor: Process GPU events in IRQ context

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

Similar to patch 9, converts the GPU IRQ handler to a hard handler. The handler is even simpler than the JOB case:

```c
static irqreturn_t panthor_gpu_irq_raw_handler(int irq, void *data)
{
    struct panthor_irq *pirq = data;
    ...
    u32 status = 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 — it doesn't check/set `PROCESSING`/`ACTIVE` states. It reads `INT_STAT`, clears, processes, and returns. The `panthor_irq_{suspend,resume}` functions still manage the `INT_MASK` register, so suspending will mask interrupts 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 events directly.

The handler body is the same as the old `panthor_gpu_irq_handler()` — 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 area is patch 6 (the `events_lock` introduction and fence signalling from IRQ context), but the approach is correct. All lock conversions to `irqsave` appear correct. The `dma_fence_signal_locked()` from hard IRQ context is permissible and is exactly the pattern used by most other DRM drivers.

I have no blocking objections. The series looks ready to merge after broader testing is completed.

---
Generated by Claude Code Patch Reviewer