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: drm/panfrost: Fix RPM so device suspends when no jobs are in flight
Date: Wed, 27 May 2026 15:22:50 +1000
Message-ID: <review-patch4-20260526-claude-fixes-v1-4-16e92eaa4949@collabora.com>
In-Reply-To: <20260526-claude-fixes-v1-4-16e92eaa4949@collabora.com>
References: <20260526-claude-fixes-v1-0-16e92eaa4949@collabora.com> <20260526-claude-fixes-v1-4-16e92eaa4949@collabora.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

**Status: Right direction, but has implementation issues that should be fixed.**

The core problem is well-identified: the old code uses `pm_runtime_set_active()` which tells the PM core the device is already active without actually going through the runtime-resume path. Since `panfrost_device_runtime_resume()` calls `panfrost_device_reset()` which calls `panfrost_mmu_reset()` (which enables MMU interrupts via `mmu_write(pfdev, MMU_INT_MASK, ~0)`), skipping the resume path means MMU interrupts are never enabled on first boot.

**Issue 1 -- Missing error check**: `pm_runtime_resume_and_get()` can fail and returns an int. The return value is not checked:
```c
pm_runtime_enable(pfdev->base.dev);
pm_runtime_resume_and_get(pfdev->base.dev);  // return value ignored
```
This should be:
```c
err = pm_runtime_resume_and_get(pfdev->base.dev);
if (err)
    goto err_out_pm;
```

**Issue 2 -- Double initialization**: `panfrost_device_init()` already calls `panfrost_gpu_init()`, `panfrost_mmu_init()`, `panfrost_jm_init()`, etc. Then `pm_runtime_resume_and_get()` triggers `panfrost_device_runtime_resume()` which calls `panfrost_device_reset()`, re-initializing the GPU, MMU, and job manager. The device gets set up twice. While this works, the real fix might be to ensure `panfrost_device_init()` enables MMU interrupts (matching what `panfrost_mmu_reset()` does), rather than relying on the side-effect of going through the runtime-resume path. The current approach is fragile because it depends on an ordering invariant that isn't documented.

**Issue 3 -- remove path `pm_runtime_put_sync`**: In the remove function:
```c
pm_runtime_get_sync(pfdev->base.dev);
panfrost_device_fini(pfdev);          // tears down GPU, MMU, perfcnt, etc.
pm_runtime_put_sync(pfdev->base.dev); // may trigger runtime_suspend callback!
pm_runtime_disable(pfdev->base.dev);
```
After `panfrost_device_fini()`, the hardware resources are torn down. `pm_runtime_put_sync()` (as opposed to `pm_runtime_put_noidle()`) will attempt to trigger the `panfrost_device_runtime_suspend` callback, which accesses `pfdev->comp->pm_features`, calls `panfrost_jm_is_idle()`, `panfrost_gpu_power_off()`, etc. -- all on finalized hardware. This should use `pm_runtime_put_noidle()` instead, or `pm_runtime_disable()` should be called before the put.

**Issue 4 -- Error path**: The error paths in probe (labels `err_out1`, `err_out2`) don't call `pm_runtime_put` to balance the `pm_runtime_resume_and_get`, so error exits would leak a PM reference:
```c
err_out2:
	drm_dev_unregister(&pfdev->base);
err_out1:
	pm_runtime_disable(pfdev->base.dev);    // no put to balance resume_and_get
	panfrost_device_fini(pfdev);
```

**Typo in commit message**: "polute" should be "pollute".

---
Generated by Claude Code Patch Reviewer