From: Maíra Canal <mcanal@igalia.com>
To: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Nicolas Saenz Julienne <nsaenz@kernel.org>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Stefan Wahren <wahrenst@gmx.net>,
Maxime Ripard <mripard@kernel.org>, Melissa Wen <mwen@igalia.com>,
Iago Toral Quiroga <itoral@igalia.com>,
Chema Casanova <jmcasanova@igalia.com>,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-clk@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
kernel-dev@igalia.com, Maíra Canal <mcanal@igalia.com>
Subject: [PATCH v7 1/5] clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks
Date: Thu, 12 Mar 2026 18:34:23 -0300 [thread overview]
Message-ID: <20260312-v3d-power-management-v7-1-9f006a1d4c55@igalia.com> (raw)
In-Reply-To: <20260312-v3d-power-management-v7-0-9f006a1d4c55@igalia.com>
On current firmware versions, RPI_FIRMWARE_SET_CLOCK_STATE doesn't
actually power off the clock. To achieve meaningful power savings, the
clock rate must be set to the minimum before disabling. This might be
fixed in future firmware releases.
Rather than pushing rate management to clock consumers, handle it
directly in the clock framework's prepare/unprepare callbacks. In
unprepare, set the rate to the minimum before disabling the clock.
In prepare, for clocks marked with `maximize` (currently v3d),
restore the rate to the maximum after enabling.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
---
drivers/clk/bcm/clk-raspberrypi.c | 38 ++++++++++++++++++++++++++++++++++----
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 1a9162f0ae31e330c46f6eafdd00350599b0eede..df2d246eb6efd0c9a9c508eb7a43a6a70e1c3810 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -289,16 +289,31 @@ static int raspberrypi_fw_dumb_determine_rate(struct clk_hw *hw,
static int raspberrypi_fw_prepare(struct clk_hw *hw)
{
const struct raspberrypi_clk_data *data = clk_hw_to_data(hw);
+ struct raspberrypi_clk_variant *variant = data->variant;
struct raspberrypi_clk *rpi = data->rpi;
u32 state = RPI_FIRMWARE_STATE_ENABLE_BIT;
int ret;
ret = raspberrypi_clock_property(rpi->firmware, data,
RPI_FIRMWARE_SET_CLOCK_STATE, &state);
- if (ret)
+ if (ret) {
dev_err_ratelimited(rpi->dev,
"Failed to set clock %s state to on: %d\n",
clk_hw_get_name(hw), ret);
+ return ret;
+ }
+
+ /*
+ * For clocks marked with 'maximize', restore the rate to the
+ * maximum after enabling. This compensates for the rate being
+ * set to minimum during unprepare (see raspberrypi_fw_unprepare).
+ */
+ if (variant->maximize) {
+ unsigned long min_rate, max_rate;
+
+ clk_hw_get_rate_range(hw, &min_rate, &max_rate);
+ ret = raspberrypi_fw_set_rate(hw, max_rate, 0);
+ }
return ret;
}
@@ -307,9 +322,27 @@ static void raspberrypi_fw_unprepare(struct clk_hw *hw)
{
const struct raspberrypi_clk_data *data = clk_hw_to_data(hw);
struct raspberrypi_clk *rpi = data->rpi;
+ unsigned long min_rate, max_rate;
u32 state = 0;
int ret;
+ clk_hw_get_rate_range(hw, &min_rate, &max_rate);
+
+ /*
+ * Setting the rate in unprepare is a deviation from the usual CCF
+ * behavior, where unprepare only gates the clock. However, this is
+ * needed, as RPI_FIRMWARE_SET_CLOCK_STATE doesn't actually power off
+ * the clock on current firmware versions. Setting the rate to minimum
+ * before disabling the clock is the only way to achieve meaningful
+ * power savings.
+ *
+ * This is safe because no consumer should rely on the rate of an
+ * unprepared clock. Any consumer must call clk_prepare() before use,
+ * at which point the rate is either restored to maximum (for clocks
+ * with the 'maximize' flag) or re-established by the consumer.
+ */
+ raspberrypi_fw_set_rate(hw, min_rate, 0);
+
ret = raspberrypi_clock_property(rpi->firmware, data,
RPI_FIRMWARE_SET_CLOCK_STATE, &state);
if (ret)
@@ -387,9 +420,6 @@ static struct clk_hw *raspberrypi_clk_register(struct raspberrypi_clk *rpi,
}
}
- if (variant->maximize)
- variant->min_rate = max_rate;
-
if (variant->min_rate) {
unsigned long rate;
--
2.53.0
next prev parent reply other threads:[~2026-03-12 21:35 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 ` Maíra Canal [this message]
2026-03-13 3:47 ` Claude review: clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks Claude Code Review Bot
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=20260312-v3d-power-management-v7-1-9f006a1d4c55@igalia.com \
--to=mcanal@igalia.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=florian.fainelli@broadcom.com \
--cc=itoral@igalia.com \
--cc=jmcasanova@igalia.com \
--cc=kernel-dev@igalia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=mripard@kernel.org \
--cc=mturquette@baylibre.com \
--cc=mwen@igalia.com \
--cc=nsaenz@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=sboyd@kernel.org \
--cc=wahrenst@gmx.net \
/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