From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
Date: Fri, 13 Mar 2026 13:47:07 +1000 [thread overview]
Message-ID: <review-patch1-20260312-v3d-power-management-v7-1-9f006a1d4c55@igalia.com> (raw)
In-Reply-To: <20260312-v3d-power-management-v7-1-9f006a1d4c55@igalia.com>
Patch Review
This patch moves V3D clock rate management into the clock framework's prepare/unprepare callbacks, so the clock rate is set to minimum on unprepare (achieving actual power savings despite firmware limitations) and restored to maximum on prepare for clocks marked with `maximize`.
The approach is well-justified with good comments explaining the firmware workaround. Two observations:
1. In `raspberrypi_fw_unprepare()`, the return value of `raspberrypi_fw_set_rate()` is ignored:
```c
raspberrypi_fw_set_rate(hw, min_rate, 0);
```
This is acceptable since unprepare is a void function and the clock is being disabled anyway, but it might be worth a comment or at least a `WARN_ON` for debugging.
2. In `raspberrypi_fw_prepare()`, the error from `raspberrypi_fw_set_rate()` is propagated through `ret`, but if the clock was already successfully enabled, a failed rate set will return an error without undoing the clock enable. This could leave the clock enabled but at the wrong rate, with the caller thinking prepare failed. Consider either undoing the clock enable on rate-set failure, or treating a rate-set failure as non-fatal.
The removal of `variant->min_rate = max_rate` in `raspberrypi_clk_register()` cleanly shifts this responsibility to the prepare callback.
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-03-13 3:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
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 1/5] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks Maíra Canal
2026-03-13 3:47 ` Claude Code Review Bot [this message]
2026-03-12 21:34 ` [PATCH v7 2/5] pmdomain: bcm: bcm2835-power: Increase ASB control timeout Maíra Canal
2026-03-13 3:47 ` Claude review: " Claude Code Review Bot
2026-03-12 21:34 ` [PATCH v7 3/5] drm/v3d: Use devm_reset_control_get_optional_exclusive() Maíra Canal
2026-03-13 3:47 ` Claude review: " Claude Code Review Bot
2026-03-12 21:34 ` [PATCH v7 4/5] drm/v3d: Allocate all resources before enabling the clock Maíra Canal
2026-03-13 3:47 ` Claude review: " Claude Code Review Bot
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-03-13 3:47 ` Claude review: Power Management for Raspberry Pi V3D GPU 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-patch1-20260312-v3d-power-management-v7-1-9f006a1d4c55@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