Claude review: drm/v3d: Flush MMU TLB and cache during runtime resume

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

Patch Review

**Purpose:** `v3d_mmu_set_page_table()` called `v3d_mmu_flush_all()`, which is gated by `pm_runtime_get_if_active()`. During runtime resume (`v3d_power_resume()`), the PM status is `RPM_RESUMING`, not `RPM_ACTIVE`, so the flush was silently skipped — leaving stale TLB entries across power cycles.

**Solution:** Extract the actual flush sequence into a static `v3d_mmu_flush_all_locked()` helper that does the writes unconditionally, and have `v3d_mmu_set_page_table()` call it directly instead of going through the PM-gated wrapper.

**Analysis of `v3d_mmu.c` changes:**

The refactoring is clean:

1. `v3d_mmu_flush_all_locked()` (lines 45-68) contains the bare flush logic — MMUC flush + TLB clear, with error reporting. No PM reference management.

2. `v3d_mmu_flush_all()` (lines 70-82) becomes a thin wrapper: PM guard, call locked helper, put PM reference. The `goto pm_put` is removed in favor of early return from the locked helper, which simplifies the control flow.

3. `v3d_mmu_set_page_table()` (line 101) now calls `v3d_mmu_flush_all_locked()` directly.

**Caller analysis:**
- `v3d_mmu_set_page_table()` is called from `v3d_power_resume()` and `v3d_reset()`. In both cases V3D is known reachable (resume has just re-enabled the clock; reset holds a PM ref). So the unconditional flush is correct in both paths.
- `v3d_mmu_insert_ptes()` and `v3d_mmu_remove_ptes()` still use the PM-gated `v3d_mmu_flush_all()`, which is correct — those are called from BO create/destroy paths where the device may or may not be active.
- `v3d_irq.c:79` also uses the PM-gated wrapper, which is fine since the IRQ handler runs while the device is active (and the PM-get confirms it).

**Verdict: This is the key fix in the series. The analysis is sound and the implementation is correct.**

---

---
Generated by Claude Code Patch Reviewer