From: Yao Zi <me@ziyao.cc>
To: Charles Perry <charles.perry@microchip.com>, <u-boot@lists.denx.de>
Cc: Rahul Pathak <rahul@summations.net>,
Anup Patel <anup@brainfault.org>, Tom Rini <trini@konsulko.com>,
Lukasz Majewski <lukma@denx.de>,
Neil Armstrong <neil.armstrong@linaro.org>,
Simon Glass <sjg@chromium.org>,
Kory Maincent <kory.maincent@bootlin.com>,
Peng Fan <peng.fan@nxp.com>, Kuan-Wei Chiu <visitorckw@gmail.com>,
"Raymond Mao" <raymond.mao@riscstar.com>,
Quentin Schulz <quentin.schulz@cherry.de>,
Stefan Roese <stefan.roese@mailbox.org>,
Philip Molloy <philip.molloy@analog.com>,
Jerome Forissier <jerome.forissier@arm.com>,
Michal Simek <michal.simek@amd.com>,
Michael Trimarchi <michael@amarulasolutions.com>,
Peter Korsgaard <peter@korsgaard.com>, Yao Zi <me@ziyao.cc>
Subject: Re: [PATCH 4/7] drivers: clk: add support for RPMI clocks
Date: Sat, 27 Jun 2026 01:47:17 +0000 [thread overview]
Message-ID: <aj8rpdOireFjteeA@pie> (raw)
In-Reply-To: <20260626201613.1035208-5-charles.perry@microchip.com>
On Fri, Jun 26, 2026 at 01:15:45PM -0700, Charles Perry wrote:
> The RISC-V Platform Management Interface (RPMI) defines a service group
> for control and monitoring of clocks [1]. This can be exposed as a
> UCLASS_CLK driver.
>
> [1]: https://github.com/riscv-non-isa/riscv-rpmi (chapter 4.8)
>
> Signed-off-by: Charles Perry <charles.perry@microchip.com>
> ---
> MAINTAINERS | 1 +
> drivers/clk/Kconfig | 7 +
> drivers/clk/Makefile | 1 +
> drivers/clk/clk_rpmi.c | 346 +++++++++++++++++++++++++++++++++++++++++
> include/rpmi_proto.h | 39 +++++
> 5 files changed, 394 insertions(+)
> create mode 100644 drivers/clk/clk_rpmi.c
...
> diff --git a/drivers/clk/clk_rpmi.c b/drivers/clk/clk_rpmi.c
> new file mode 100644
> index 000000000000..d2efb057600b
> --- /dev/null
> +++ b/drivers/clk/clk_rpmi.c
> @@ -0,0 +1,346 @@
...
> +struct rpmi_clk_def {
> + u32 num_rates;
> + u32 transition_latency;
rpmi_clk_def.transition_latency only gets assigned in
rpmi_clk_get_attrs() and never used. Since U-Boot's clock infrastructure
doesn't care about it at all, maybe we could drop the field?
> + enum rpmi_clock_type type;
> + char name[RPMI_CLK_NAME_LEN + 1];
> +};
...
> +static int _rpmi_clk_enable_disable(struct rpmi_clk_priv *priv, u32 clkid,
> + bool ena)
> +{
> + struct rpmi_set_config_tx tx = {
> + .clkid = cpu_to_le32(clkid),
> + .config = cpu_to_le32(ena ? RPMI_CLK_STATE_ENABLED :
> + RPMI_CLK_STATE_DISABLED),
> + };
> + __le32 rx;
> + int ret, status;
> +
> + ret = rpmi_send_with_resp(&priv->chan, RPMI_CLK_SRV_SET_CONFIG, &tx,
> + sizeof(tx), &rx, sizeof(rx), NULL);
> + if (ret)
> + return ret;
> +
> + status = le32_to_cpu(rx);
> + if (status)
> + return rpmi_to_linux_error(status);
> +
> + return 0;
Please return rpmi_to_linux_error(status) and drop the if above.
> +}
> +
> +static ulong _rpmi_clk_get_rate(struct rpmi_clk_priv *priv, u32 clkid)
> +{
> + __le32 tx = cpu_to_le32(clkid);
> + struct rpmi_get_rate_rx rx;
> + int ret, status;
> +
> + ret = rpmi_send_with_resp(&priv->chan, RPMI_CLK_SRV_GET_RATE, &tx,
> + sizeof(tx), &rx, sizeof(rx), NULL);
> + if (ret)
> + return ret;
> +
> + status = le32_to_cpu(rx.status);
> + if (status)
> + return rpmi_to_linux_error(status);
> +
> + return (((u64)(le32_to_cpu(rx.hi)) << 32) | (u32)(le32_to_cpu(rx.lo)));
> +}
...
> +static int _rpmi_clk_set_rate(struct rpmi_clk_priv *priv, u32 clkid,
> + unsigned long rate)
This function is declared to return int, but...
> +{
> + struct rpmi_set_rate_tx tx = {
> + .clkid = cpu_to_le32(clkid),
> + .flags = 0,
> + .lo = cpu_to_le32(lower_32_bits(rate)),
> + .hi = cpu_to_le32(upper_32_bits(rate)),
> + };
> + __le32 rx;
> + int ret, status;
> +
> + ret = rpmi_send_with_resp(&priv->chan, RPMI_CLK_SRV_SET_RATE, &tx,
> + sizeof(tx), &rx, sizeof(rx), NULL);
> + if (ret)
> + return ret;
> +
> + status = le32_to_cpu(rx);
> + if (status)
> + return rpmi_to_linux_error(status);
> +
> + return _rpmi_clk_get_rate(priv, clkid);
_rpmi_clk_get_rate() returns ulong. This unnecessarily truncates the
rate on 64bit platform when it's above approximately 2.1GHz.
> +}
Regards,
Yao Zi
next prev parent reply other threads:[~2026-06-27 1:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 20:15 [PATCH 0/7] Add support for RPMI to U-Boot Charles Perry
2026-06-26 20:15 ` [PATCH 1/7] firmware: add support for RPMI Charles Perry
2026-06-27 1:09 ` Yao Zi
2026-06-26 20:15 ` [PATCH 2/7] firmware: rpmi: add support for the SBI MPXY transport Charles Perry
2026-06-27 1:30 ` Yao Zi
2026-06-26 20:15 ` [PATCH 3/7] firmware: rpmi: add support for shared memory transport Charles Perry
2026-06-26 20:15 ` [PATCH 4/7] drivers: clk: add support for RPMI clocks Charles Perry
2026-06-27 1:47 ` Yao Zi [this message]
2026-06-26 20:15 ` [PATCH 5/7] drivers: power: add support for RPMI power domains Charles Perry
2026-06-26 20:15 ` [PATCH 6/7] firmware: rpmi: add a test and a sandbox driver Charles Perry
2026-06-26 20:15 ` [PATCH 7/7] firmware: rpmi: add a test and sandbox for device power Charles Perry
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=aj8rpdOireFjteeA@pie \
--to=me@ziyao.cc \
--cc=anup@brainfault.org \
--cc=charles.perry@microchip.com \
--cc=jerome.forissier@arm.com \
--cc=kory.maincent@bootlin.com \
--cc=lukma@denx.de \
--cc=michael@amarulasolutions.com \
--cc=michal.simek@amd.com \
--cc=neil.armstrong@linaro.org \
--cc=peng.fan@nxp.com \
--cc=peter@korsgaard.com \
--cc=philip.molloy@analog.com \
--cc=quentin.schulz@cherry.de \
--cc=rahul@summations.net \
--cc=raymond.mao@riscstar.com \
--cc=sjg@chromium.org \
--cc=stefan.roese@mailbox.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=visitorckw@gmail.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