[PATCH 0/4] drm/v3d: Fix RPi 4 system hangs from stale cache and MMU state

[PATCH 0/4] drm/v3d: Fix RPi 4 system hangs from stale cache and MMU state

[Maíra Canal]

Some users have reported hard system hangs on the Raspberry Pi 4 (V3D 4.2)
under GPU load [1][2][3]. Investigation had traced these to V3D caches and
MMU being left in an inconsistent state across PM transitions. This series
addresses three distinct issues in the cache and MMU maintenance:

  1. PATCH 1: Addresses an issue on pre-V3D 7.1 hardware, in which
     starting a clean while an L2T flush is still pending can clobber bits
     in L2TCACTL and leave the caches inconsistent. This issue existed
     before the runtime PM series.

  2. PATCH 2: Fixes the MMU TLB/cache flush in v3d_mmu_set_page_table()
     being silently skipped during runtime resume. Directly addresses
     the system hangs reported by the users.

  3. PATCH 3: Cleans the V3D caches on runtime suspend, so all dirty lines
     are written back to memory before the power domain is shut down.
     Directly addresses the error `v3d fec00000.v3d: MMU error from
     client L2T (7) at 0xff877600, pte invalid` reported during the
     hangs.

Together these restore correct cache/MMU coherency around runtime PM,
addressing the reported hangs. Moreover, with this fixes, it was possible
to reduce the autosuspend delay, which was increased as the shorter delays
used to cause more frequent runtime suspend/resume cycles, which exposed
the cache and MMU coherency bugs as random GPU hangs. With those fixed,
we can reduce the autosuspend delay to a more reasonable value.

[1] https://github.com/raspberrypi/linux/issues/7381
[2] https://github.com/raspberrypi/linux/issues/7396
[3] https://github.com/raspberrypi/linux/issues/7397

Best regards,
- Maíra

---
Maíra Canal (4):
      drm/v3d: Wait for pending L2T flush before cleaning caches
      drm/v3d: Flush MMU TLB and cache during runtime resume
      drm/v3d: Clean caches before runtime suspend
      drm/v3d: Reduce PM runtime autosuspend delay

 drivers/gpu/drm/v3d/v3d_drv.c   |  2 +-
 drivers/gpu/drm/v3d/v3d_gem.c   |  8 ++++++++
 drivers/gpu/drm/v3d/v3d_mmu.c   | 31 ++++++++++++++++++++++---------
 drivers/gpu/drm/v3d/v3d_power.c |  2 ++
 4 files changed, 33 insertions(+), 10 deletions(-)
---
base-commit: 61de054a772a1feda6364931ab1baf9038abf1c8
change-id: 20260528-v3d-fix-rpi4-freezes-8bae519d04ce

[PATCH 1/4] drm/v3d: Wait for pending L2T flush before cleaning caches

[Maíra Canal]

v3d_clean_caches() starts the cache-clean sequence by writing
V3D_L2TCACTL_TMUWCF to V3D_CTL_L2TCACTL and then polling for that bit to
clear. It does not, however, check for an L2T flush (L2TFLS) that may
still be in flight from a previous operation.

On pre-V3D 7.1 hardware, kicking off the TMU write-combiner flush while an
L2T flush is still pending can clobber bits in L2TCACTL and cause cache
inconsistencies.

Poll for L2TFLS to clear before writing L2TCACTL on V3D < 7.1, ensuring
any pending flush has completed before a new clean is issued.

Cc: stable@vger.kernel.org
Fixes: d223f98f0209 ("drm/v3d: Add support for compute shader dispatch.")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
---
 drivers/gpu/drm/v3d/v3d_gem.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 1ee3c038d5f6..c43d9af41374 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -206,6 +206,14 @@ v3d_clean_caches(struct v3d_dev *v3d)
 
 	trace_v3d_cache_clean_begin(dev);
 
+	/* GFXH-1897: Ensure pending flushes complete before writing L2TCACTL */
+	if (v3d->ver < V3D_GEN_71) {
+		if (wait_for(!(V3D_CORE_READ(core, V3D_CTL_L2TCACTL) &
+			       V3D_L2TCACTL_L2TFLS), 100)) {
+			drm_err(dev, "Timeout waiting for L2T clean\n");
+		}
+	}
+
 	V3D_CORE_WRITE(core, V3D_CTL_L2TCACTL, V3D_L2TCACTL_TMUWCF);
 	if (wait_for(!(V3D_CORE_READ(core, V3D_CTL_L2TCACTL) &
 		       V3D_L2TCACTL_TMUWCF), 100)) {

-- 
2.54.0

Claude review: drm/v3d: Wait for pending L2T flush before cleaning caches

[Claude Code Review Bot]

Patch Review

**Purpose:** On pre-V3D 7.1 hardware, `v3d_clean_caches()` writes to `V3D_CTL_L2TCACTL` without first checking if a prior L2T flush (`V3D_L2TCACTL_L2TFLS`) is still in flight. This can clobber bits in the register and cause cache inconsistencies.

**Code added in `v3d_gem.c:209-215`:**
```c
/* GFXH-1897: Ensure pending flushes complete before writing L2TCACTL */
if (v3d->ver < V3D_GEN_71) {
    if (wait_for(!(V3D_CORE_READ(core, V3D_CTL_L2TCACTL) &
                   V3D_L2TCACTL_L2TFLS), 100)) {
        drm_err(dev, "Timeout waiting for L2T clean\n");
    }
}
```

**Analysis:**
- The GFXH-1897 workaround reference is good practice for hardware errata.
- The version guard (`v3d->ver < V3D_GEN_71`) is appropriate — the comment in `v3d_flush_l2t()` at line 179 already notes the L2TFLS busy-bit behavior, and this new wait ensures the previous flush has drained before a clean overwrites the register.
- The 100ms timeout is consistent with all other `wait_for` calls in this file.
- The placement before the `V3D_L2TCACTL_TMUWCF` write is correct — it protects the first write to L2TCACTL.
- The Fixes tag points to the original compute dispatch commit that introduced `v3d_clean_caches`, which is correct — this is a pre-existing bug independent of PM.
- The `Cc: stable@vger.kernel.org` is appropriate.

**Minor note:** The error message "Timeout waiting for L2T clean" could be confused with the identical message at line 231 (the later L2TFLS clean wait). Consider making this one distinct, e.g., "Timeout waiting for pending L2T flush" — but this is cosmetic and not blocking.

**Verdict: Looks correct.**

---

---
Generated by Claude Code Patch Reviewer

[PATCH 2/4] drm/v3d: Flush MMU TLB and cache during runtime resume

[Maíra Canal]

v3d_mmu_set_page_table() ends by calling v3d_mmu_flush_all() to flush the
MMU cache and clear the TLB after reprogramming V3D_MMU_PT_PA_BASE.
v3d_mmu_flush_all() is gated by pm_runtime_get_if_active(), which returns
0 unless runtime_status == RPM_ACTIVE.

v3d_mmu_set_page_table() is called from two paths that *know* V3D is
reachable, but where the runtime PM status might be wrong:

  1. v3d_power_resume(): the runtime resume callback itself, where
     runtime_status is RPM_RESUMING.

  2. v3d_reset(): called from the DRM scheduler timeout handler with the
     hung job's pm_runtime reference held, so RPM_ACTIVE, but here we
     don't need to take an extra reference for the duration of the flush
     either.

In the first case pm_runtime_get_if_active() returns 0, the flush is
silently skipped, and V3D resumes executing with whatever MMUC/TLB state
happened to survive the last reset. This can leave stale translations
live across runtime PM cycles, manifesting as random GPU hangs.

Split the actual flush sequence into a helper that does the writes
unconditionally, and have v3d_mmu_set_page_table() call it directly.

Fixes: 458f2a712ab4 ("drm/v3d: Introduce Runtime Power Management")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
---
 drivers/gpu/drm/v3d/v3d_mmu.c | 31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_mmu.c b/drivers/gpu/drm/v3d/v3d_mmu.c
index 630c64e51d2f..94f6676d5633 100644
--- a/drivers/gpu/drm/v3d/v3d_mmu.c
+++ b/drivers/gpu/drm/v3d/v3d_mmu.c
@@ -37,13 +37,14 @@ static bool v3d_mmu_is_aligned(u32 page, u32 page_address, size_t alignment)
 		IS_ALIGNED(page_address, alignment >> V3D_MMU_PAGE_SHIFT);
 }
 
-int v3d_mmu_flush_all(struct v3d_dev *v3d)
+/*
+ * Issue the MMUC flush and TLB clear unconditionally. The caller must
+ * already know that V3D is reachable. In particular, this is used from
+ * the runtime resume callback.
+ */
+static int v3d_mmu_flush_all_locked(struct v3d_dev *v3d)
 {
-	int ret = 0;
-
-	/* Flush the PTs only if we're already awake */
-	if (!pm_runtime_get_if_active(v3d->drm.dev))
-		return 0;
+	int ret;
 
 	V3D_WRITE(V3D_MMUC_CONTROL, V3D_MMUC_CONTROL_FLUSH |
 		  V3D_MMUC_CONTROL_ENABLE);
@@ -52,7 +53,7 @@ int v3d_mmu_flush_all(struct v3d_dev *v3d)
 			 V3D_MMUC_CONTROL_FLUSHING), 100);
 	if (ret) {
 		dev_err(v3d->drm.dev, "MMUC flush wait idle failed\n");
-		goto pm_put;
+		return ret;
 	}
 
 	V3D_WRITE(V3D_MMU_CTL, V3D_READ(V3D_MMU_CTL) |
@@ -63,7 +64,19 @@ int v3d_mmu_flush_all(struct v3d_dev *v3d)
 	if (ret)
 		dev_err(v3d->drm.dev, "MMU TLB clear wait idle failed\n");
 
-pm_put:
+	return ret;
+}
+
+int v3d_mmu_flush_all(struct v3d_dev *v3d)
+{
+	int ret;
+
+	/* Flush the PTs only if we're already awake */
+	if (!pm_runtime_get_if_active(v3d->drm.dev))
+		return 0;
+
+	ret = v3d_mmu_flush_all_locked(v3d);
+
 	v3d_pm_runtime_put(v3d);
 	return ret;
 }
@@ -85,7 +98,7 @@ int v3d_mmu_set_page_table(struct v3d_dev *v3d)
 		  V3D_MMU_ILLEGAL_ADDR_ENABLE);
 	V3D_WRITE(V3D_MMUC_CONTROL, V3D_MMUC_CONTROL_ENABLE);
 
-	return v3d_mmu_flush_all(v3d);
+	return v3d_mmu_flush_all_locked(v3d);
 }
 
 void v3d_mmu_insert_ptes(struct v3d_bo *bo)

-- 
2.54.0

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

[Claude Code Review Bot]

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

[PATCH 3/4] drm/v3d: Clean caches before runtime suspend

[Maíra Canal]

On runtime suspend, clean the V3D caches before suspending so all dirty
lines are written back to memory before the power domain is shut down.

Fixes several system hangs reported in [1][2][3].

Closes: https://github.com/raspberrypi/linux/issues/7381 [1]
Closes: https://github.com/raspberrypi/linux/issues/7396 [2]
Closes: https://github.com/raspberrypi/linux/issues/7397 [3]
Fixes: 458f2a712ab4 ("drm/v3d: Introduce Runtime Power Management")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
---
 drivers/gpu/drm/v3d/v3d_power.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/v3d/v3d_power.c b/drivers/gpu/drm/v3d/v3d_power.c
index 769e90032b04..f7df6393d38f 100644
--- a/drivers/gpu/drm/v3d/v3d_power.c
+++ b/drivers/gpu/drm/v3d/v3d_power.c
@@ -52,6 +52,8 @@ int v3d_power_suspend(struct device *dev)
 
 	v3d_irq_disable(v3d);
 
+	v3d_clean_caches(v3d);
+
 	ret = v3d_suspend_sms(v3d);
 	if (ret) {
 		v3d_irq_enable(v3d);

-- 
2.54.0

Claude review: drm/v3d: Clean caches before runtime suspend

[Claude Code Review Bot]

Patch Review

**Purpose:** Ensure all dirty cache lines are written back to memory before the power domain is shut down, preventing "MMU error from client L2T... pte invalid" on resume.

**Code added in `v3d_power.c:55`:**
```c
v3d_clean_caches(v3d);
```

This is placed after `v3d_irq_disable(v3d)` and before `v3d_suspend_sms(v3d)`.

**Analysis:**
- The placement is correct: IRQs are disabled (no new work can arrive), so the clean is serialized. The clean happens before SMS suspend/clock disable, so the hardware is still accessible.
- `v3d_clean_caches()` takes `v3d->cache_clean_lock`, which serializes against any in-flight flush from `v3d_flush_l2t()`. Since IRQs are disabled and the scheduler should have drained, there shouldn't be contention, but the lock provides safety.
- The Fixes tag correctly points to the runtime PM introduction commit.

**One observation:** The commit message says this directly addresses the "pte invalid" MMU errors. The `Closes:` tags on all three GitHub issues are applied to this patch specifically. But the cover letter says patch 2 "directly addresses the system hangs" and patch 3 "directly addresses the error." Having all three `Closes:` on patch 3 alone seems slightly off — arguably patch 2 is equally important for the fix. However, since patches 2 and 3 work together and will be applied as a series, this is a nit about attribution rather than correctness.

**Verdict: Correct and straightforward.**

---

---
Generated by Claude Code Patch Reviewer

[PATCH 4/4] drm/v3d: Reduce PM runtime autosuspend delay

[Maíra Canal]

The 100ms autosuspend delay was only ever a workaround: shorter delays
caused more frequent runtime suspend/resume cycles on the BCM2711
(Raspberry Pi 4), which exposed the cache and MMU coherency bugs as
random GPU hangs.

With those hangs resolved, the inflated delay is no longer necessary.
Reduce it from 100ms to 50ms so the GPU power domain can be released
sooner once the GPU goes idle.

Signed-off-by: Maíra Canal <mcanal@igalia.com>
---
 drivers/gpu/drm/v3d/v3d_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index fc81dd1247e3..805d84435ee0 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -420,7 +420,7 @@ static int v3d_platform_drm_probe(struct platform_device *pdev)
 	ident3 = V3D_READ(V3D_HUB_IDENT3);
 	v3d->rev = V3D_GET_FIELD(ident3, V3D_HUB_IDENT3_IPREV);
 
-	pm_runtime_set_autosuspend_delay(dev, 100);
+	pm_runtime_set_autosuspend_delay(dev, 50);
 	pm_runtime_use_autosuspend(dev);
 
 	ret = drm_dev_register(drm, 0);

-- 
2.54.0

Claude review: drm/v3d: Reduce PM runtime autosuspend delay

[Claude Code Review Bot]

Patch Review

**Purpose:** With the cache/MMU bugs fixed, the inflated 100ms autosuspend delay is no longer needed. Reduce to 50ms.

**Code change in `v3d_drv.c:423`:**
```c
pm_runtime_set_autosuspend_delay(dev, 50);
```

**Analysis:**
- The rationale is well explained in the commit message: 100ms was a workaround for the bugs fixed in patches 1-3.
- This patch has no `Fixes:` tag, which is correct — it's a tuning change, not a bugfix.
- No `Cc: stable@` either, which is correct — this should not be backported independently of the series.

**Question:** Is 50ms the right value? The commit message says "a more reasonable value" but doesn't cite benchmarks or power measurements. For a desktop/embedded system like RPi4, the difference between 50ms and 100ms is unlikely to matter for power savings but could theoretically increase suspend/resume cycle frequency. This is a judgment call for the maintainers — the value seems reasonable, but some data or a reference to what other GPU drivers use would strengthen the justification. Not a blocker.

**Verdict: Fine as-is; the maintainers can adjust the value at merge time if they prefer a different number.**

---
Generated by Claude Code Patch Reviewer

Claude review: drm/v3d: Fix RPi 4 system hangs from stale cache and MMU state

[Claude Code Review Bot]

Overall Series Review

Subject: drm/v3d: Fix RPi 4 system hangs from stale cache and MMU state
Author: =?utf-8?q?Ma=C3=ADra_Canal?= <mcanal@igalia.com>
Patches: 5
Reviewed: 2026-06-04T15:23:14.775724

---

This is a well-structured, well-motivated bugfix series from Maíra Canal (Igalia) addressing hard system hangs on Raspberry Pi 4 (V3D 4.2) during GPU load. The series identifies three distinct cache/MMU coherency issues exposed by runtime PM transitions, fixes them in order of root-cause depth, and then follows up with a justified reduction of the autosuspend delay that was previously inflated as a workaround.

The patches are logically ordered: patch 1 fixes a pre-existing cache race (GFXH-1897), patch 2 fixes the critical flush-skipped-during-resume bug, patch 3 ensures dirty caches are written back before power-off, and patch 4 harvests the benefit. The commit messages are clear, the code changes are minimal and targeted, and each patch addresses exactly one problem.

**Verdict: Series looks correct and ready to merge.** I have one minor observation on patch 3 and a question about patch 4 that are worth considering but neither is a blocker.

---
Generated by Claude Code Patch Reviewer