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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.