public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/v3d: Introduce Runtime Power Management
Date: Wed, 01 Apr 2026 07:45:10 +1000	[thread overview]
Message-ID: <review-patch3-20260331-v3d-power-management-v9-3-f52ff87bfd36@igalia.com> (raw)
In-Reply-To: <20260331-v3d-power-management-v9-3-f52ff87bfd36@igalia.com>

Patch Review

**Status: Mostly good, a few concerns.**

This is the main patch. It introduces `v3d_power.c` with suspend/resume callbacks, wraps HW register accesses throughout the driver with `v3d_pm_runtime_get()`/`v3d_pm_runtime_put()`, and holds a PM reference for the duration of GPU jobs.

**Positive aspects:**
- Clean separation into `v3d_power.c`
- The `v3d_pm_runtime_get()`/`v3d_pm_runtime_put()` inline wrappers in the header are a good pattern
- Using `pm_runtime_get_if_active()` for `v3d_mmu_flush_all()` (skip flush if device is suspended — PTs will be reloaded on resume) is correct
- Using `pm_runtime_get_if_active()` for `v3d_perfmon_start()`/`v3d_perfmon_stop()` is reasonable since these are called from scheduler context where the device should already be active
- `has_pm_ref` flag on jobs to track whether a PM reference was taken, with automatic put in `v3d_job_free()`, is a clean design
- CPU jobs correctly skip taking a PM reference (`queue != V3D_CPU`)
- The `!IS_ENABLED(CONFIG_PM)` fallbacks are proper

**Concerns:**

1. **`v3d_perfmon_start()` silently returns on PM failure**: 

```c
+	if (!pm_runtime_get_if_active(v3d->drm.dev))
+		return;
+
 	ncounters = perfmon->ncounters;
```

If `pm_runtime_get_if_active()` returns 0 (device suspended), `v3d_perfmon_start()` returns without setting `v3d->active_perfmon`. The scheduler calls `v3d_perfmon_start()` right before running a job, but by that point the job should already hold a PM ref (via `has_pm_ref`). So the device should always be active here. The `pm_runtime_get_if_active()` acts as a safety net. However, if it *did* fire, the perfmon would silently not start, which could be confusing. A `WARN_ON` or `drm_warn` might be more appropriate than a silent return, since this would indicate a logic error.

2. **`v3d_perfmon_stop()` — asymmetric get/put with `out_clear` label**:

```c
+	if (!pm_runtime_get_if_active(v3d->drm.dev))
+		goto out_clear;
...
+	v3d_pm_runtime_put(v3d);
+
+out_clear:
 	v3d->active_perfmon = NULL;
+out:
 	mutex_unlock(&perfmon->lock);
```

When `pm_runtime_get_if_active()` returns 0, it jumps to `out_clear` which sets `active_perfmon = NULL` without capturing counter values or disabling the counters. This is correct for the suspend case (counters are already dead), but it means `active_perfmon` tracking stays consistent. This looks fine.

3. **`v3d_power_suspend()` error recovery**: If `v3d_suspend_sms()` fails, it re-enables IRQs:

```c
+	v3d_irq_disable(v3d);
+
+	ret = v3d_suspend_sms(v3d);
+	if (ret) {
+		v3d_irq_enable(v3d);
+		return ret;
+	}
```

This is good error recovery. However, `v3d_suspend_sms()` already wrote `V3D_SMS_POWER_OFF` to the SMS register before the timeout. On failure, the SMS may be in an inconsistent state. Re-enabling IRQs without attempting to recover SMS state could be problematic. That said, if the SMS is failing to power off, the HW is likely in a bad state already, so there may not be much that can be done. A comment explaining this would be helpful.

4. **Probe path — `pm_runtime_put_sync_suspend()` in error cleanup**:

```c
+runtime_pm_put:
+	pm_runtime_put_sync_suspend(dev);
```

After `pm_runtime_resume_and_get()` succeeds in probe, if a later step fails, this drops the reference and synchronously suspends. Since `devm_pm_runtime_enable()` was already called, the runtime PM core will handle disabling on driver detach. This is correct.

5. **`v3d_measure_clock()` holds PM ref across `msleep(1000)`**: 

```c
+	ret = v3d_pm_runtime_get(v3d);
+	if (ret)
+		return ret;
...
 	msleep(measure_ms);
...
+	v3d_pm_runtime_put(v3d);
```

This keeps the GPU powered for a full second during the debugfs clock measurement. This is by design (measuring the clock requires it), but it's worth noting that reading this debugfs file will prevent autosuspend for 1 second. Acceptable for a debug interface.

6. **`v3d_get_param_ioctl()` takes PM ref for register reads**: This is correct — the device needs to be powered to read HW registers.

7. **Copyright line**: `Copyright (C) 2026 Raspberry Pi` — the author is from Igalia, not Raspberry Pi. Might want `Copyright (C) 2026 Igalia, S.L.` instead, or whatever is appropriate. Minor.

Overall, this is a solid series at v9 and ready to merge with the minor points noted above.

---
Generated by Claude Code Patch Reviewer

  parent reply	other threads:[~2026-03-31 21:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-31 12:35 [PATCH v9 0/3] Power Management for Raspberry Pi V3D GPU Maíra Canal
2026-03-31 12:35 ` [PATCH v9 1/3] drm/v3d: Use devm_reset_control_get_optional_exclusive() Maíra Canal
2026-03-31 21:45   ` Claude review: " Claude Code Review Bot
2026-03-31 12:35 ` [PATCH v9 2/3] drm/v3d: Allocate all resources before enabling the clock Maíra Canal
2026-03-31 21:45   ` Claude review: " Claude Code Review Bot
2026-03-31 12:35 ` [PATCH v9 3/3] drm/v3d: Introduce Runtime Power Management Maíra Canal
2026-03-31 15:33   ` Florian Fainelli
2026-03-31 21:45   ` Claude Code Review Bot [this message]
2026-03-31 21:45 ` Claude review: Power Management for Raspberry Pi V3D GPU Claude Code Review Bot
  -- strict thread matches above, loose matches on Subject: below --
2026-03-28 18:52 [PATCH v8 0/3] " Maíra Canal
2026-03-28 18:52 ` [PATCH v8 3/3] drm/v3d: Introduce Runtime Power Management Maíra Canal
2026-03-31  7:53   ` Claude review: " Claude Code Review Bot
2026-03-12 21:34 [PATCH v7 0/5] Power Management for Raspberry Pi V3D GPU Maíra Canal
2026-03-12 21:34 ` [PATCH v7 5/5] drm/v3d: Introduce Runtime Power Management Maíra Canal
2026-03-13  3:47   ` Claude review: " Claude Code Review Bot
2026-02-13 18:52 [PATCH v5 0/7] Power Management for Raspberry Pi V3D GPU Maíra Canal
2026-02-13 18:53 ` [PATCH v5 7/7] drm/v3d: Introduce Runtime Power Management Maíra Canal
2026-02-13 21:21   ` Claude review: " Claude Code Review Bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=review-patch3-20260331-v3d-power-management-v9-3-f52ff87bfd36@igalia.com \
    --to=claude-review@example.com \
    --cc=dri-devel-reviews@example.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox