Message-ID: <aK8EbcEHz3Yzpa1W@x1>
Date: Wed, 27 Aug 2025 09:13:17 -0400
From: Brian Masney <bmasney@...hat.com>
To: Peng Fan <peng.fan@....nxp.com>
Cc: Sudeep Holla <sudeep.holla@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>,
	Chen Wang <unicorn_wang@...look.com>,
	Inochi Amaoto <inochiama@...il.com>,
	Nicolas Ferre <nicolas.ferre@...rochip.com>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	Claudiu Beznea <claudiu.beznea@...on.dev>,
	Paul Cercueil <paul@...pouillou.net>,
	Keguang Zhang <keguang.zhang@...il.com>,
	Taichi Sugaya <sugaya.taichi@...ionext.com>,
	Takao Orito <orito.takao@...ionext.com>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Jacky Huang <ychuang3@...oton.com>,
	Shan-Chun Hung <schung@...oton.com>,
	Vladimir Zapolskiy <vz@...ia.com>,
	Piotr Wojtaszczyk <piotr.wojtaszczyk@...esys.com>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Samuel Holland <samuel.holland@...ive.com>,
	Yixun Lan <dlan@...too.org>,
	Steen Hegelund <Steen.Hegelund@...rochip.com>,
	Daniel Machon <daniel.machon@...rochip.com>,
	UNGLinuxDriver@...rochip.com, Orson Zhai <orsonzhai@...il.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Chunyan Zhang <zhang.lyra@...il.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Michal Simek <michal.simek@....com>,
	Maxime Ripard <mripard@...nel.org>,
	Andreas Färber <afaerber@...e.de>,
	Manivannan Sadhasivam <mani@...nel.org>,
	Sven Peter <sven@...nel.org>, Janne Grunau <j@...nau.net>,
	Alyssa Rosenzweig <alyssa@...enzweig.io>,
	Neal Gompa <neal@...pa.dev>,
	Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>,
	Ray Jui <rjui@...adcom.com>, Scott Branden <sbranden@...adcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	Max Filippov <jcmvbkbc@...il.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Daniel Palmer <daniel@...ngy.jp>,
	Romain Perier <romain.perier@...il.com>,
	Andrew Lunn <andrew@...n.ch>,
	Gregory Clement <gregory.clement@...tlin.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Bjorn Andersson <andersson@...nel.org>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Heiko Stuebner <heiko@...ech.de>,
	Andrea della Porta <andrea.porta@...e.com>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Alim Akhtar <alim.akhtar@...sung.com>,
	Qin Jian <qinjian@...lus1.com>, Viresh Kumar <vireshk@...nel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Alex Helms <alexander.helms.jy@...esas.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Liviu Dudau <liviu.dudau@....com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...hiba.co.jp>,
	linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
	arm-scmi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	sophgo@...ts.linux.dev, linux-mips@...r.kernel.org,
	imx@...ts.linux.dev, linux-riscv@...ts.infradead.org,
	spacemit@...ts.linux.dev, linux-stm32@...md-mailman.stormreply.com,
	patches@...nsource.cirrus.com, linux-actions@...ts.infradead.org,
	asahi@...ts.linux.dev, linux-mediatek@...ts.infradead.org,
	linux-arm-msm@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
	linux-rockchip@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org, soc@...ts.linux.dev
Subject: Re: [PATCH 112/114] clk: scmi: remove round_rate() in favor of
 determine_rate()

On Wed, Aug 27, 2025 at 03:09:33PM +0800, Peng Fan wrote:
> Hi Brian, Sudeep, Cristian
> 
> On Mon, Aug 11, 2025 at 11:19:44AM -0400, Brian Masney via B4 Relay wrote:
> >From: Brian Masney <bmasney@...hat.com>
> >
> >This driver implements both the determine_rate() and round_rate() clk
> >ops, and the round_rate() clk ops is deprecated. When both are defined,
> >clk_core_determine_round_nolock() from the clk core will only use the
> >determine_rate() clk ops, so let's remove the round_rate() clk ops since
> >it's unused.
> >
> >Signed-off-by: Brian Masney <bmasney@...hat.com>
> >---
> > drivers/clk/clk-scmi.c | 30 ------------------------------
> > 1 file changed, 30 deletions(-)
> >
> >diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
> >index d2408403283fc72f0cf902e65f4c08bcbc7b4b0b..6c6ddb92e7cf6a0cfac2c7e19c0f15f777bb8c51 100644
> >--- a/drivers/clk/clk-scmi.c
> >+++ b/drivers/clk/clk-scmi.c
> >@@ -54,35 +54,6 @@ static unsigned long scmi_clk_recalc_rate(struct clk_hw *hw,
> > 	return rate;
> > }
> > 
> >-static long scmi_clk_round_rate(struct clk_hw *hw, unsigned long rate,
> >-				unsigned long *parent_rate)
> >-{
> 
> I see the point of round_rate is not used if determine_rate is there.
> But reading the code of round_rate, It might be better to rename
> scmi_clk_round_rate to scmi_clk_determine_rate.
> 
> Anyway, need Sudeep and Cristian to comment.

In this case, yes the round_rate implementation is filled out, whereas
the determine_rate lets the firmware handle it, and
scmi_clk_recalc_rate() will later populate the rate the clock is running
at.

I can convert round_rate over to determine_rate in this case, however it
would be a change to what's there now, and risks a regression. Here's
the relevant code from drivers/clk/clk.c where the determine_rate and
round_rate ops are called:

    static int clk_core_determine_round_nolock(struct clk_core *core,
                                               struct clk_rate_request *req)
    {
    	...
            if (clk_core_rate_is_protected(core)) {
                    req->rate = core->rate;
            } else if (core->ops->determine_rate) {
                    return core->ops->determine_rate(core->hw, req);
            } else if (core->ops->round_rate) {
                    rate = core->ops->round_rate(core->hw, req->rate,
                                                 &req->best_parent_rate);
    	...

If Sudeep / Cristian want the round rate converted to determine rate in
this driver, then I can do that in a v2.

Brian

Powered by blists - more mailing lists