From: Stephen Boyd <sboyd@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Rob Herring <robh@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, kernel@pengutronix.de,
"Alvin Šipraga" <alsi@bang-olufsen.dk>,
"Sascha Hauer" <s.hauer@pengutronix.de>
Subject: Re: [PATCH v4 1/3] clk: make determine_rate optional for non reparenting clocks
Date: Wed, 30 Apr 2025 15:15:38 -0700 [thread overview]
Message-ID: <40bf9ffc7ae98f6601122cd8850418f5@kernel.org> (raw)
In-Reply-To: <20250430-clk-cdce6214-v4-1-9f15e7126ac6@pengutronix.de>
Quoting Sascha Hauer (2025-04-30 02:01:34)
> With commit 326cc42f9fdc ("clk: Forbid to register a mux without
> determine_rate") it became mandatory to provide a determine_rate hook
> once a set_parent hook is provided. The determine_rate hook is only
> needed though when the clock reparents to set its rate. Clocks which do
> not reparent during set_rate do not need a determine_rate hook, so make
> the hook optional for clocks with the CLK_SET_RATE_NO_REPARENT flag.
Do you have a set_parent clk_op that you want use? But you set the flag
so that rate changes don't try to change the parent? Do you implement
a round_rate clk_op? I'm guessing round_rate isn't implemented.
We want to get rid of round_rate and move drivers to use determine_rate
everywhere because it passes a struct that we can extend in the future
to do coordinated rate changes, per-clk locking, etc.
We could change this to be something like:
if (core->ops->round_rate && core->ops->determine_rate)
return -EINVAL and pr_err("Pick one, not both");
if (core->ops->set_parent && core->ops->round_rate)
return -EINVAL and pr_err("must implement .set_parent & .determine_rate")
so that if you have a set_parent clk_op you better implement
determine_rate if you support changing the rate, regardless of the clk
flags. I worry that we have some driver that implements both round_rate
and determine_rate though. Indeed, the clk_divider_ops does that to
support being copied by other clk drivers so we'll need to make the
logic this:
if (core->ops->set_parent && clk_core_can_round(core) && !core->ops->determine_rate)
return -EINVAL and pr_err("must implement .set_parent & .determine_rate")
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 0565c87656cf5..07ae3652df6c1 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -3937,7 +3937,8 @@ static int __clk_core_init(struct clk_core *core)
> goto out;
> }
>
> - if (core->ops->set_parent && !core->ops->determine_rate) {
> + if (!(core->flags & CLK_SET_RATE_NO_REPARENT) &&
> + core->ops->set_parent && !core->ops->determine_rate) {
> pr_err("%s: %s must implement .set_parent & .determine_rate\n",
> __func__, core->name);
> ret = -EINVAL;
next prev parent reply other threads:[~2025-04-30 22:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-30 9:01 [PATCH v4 0/3] clk: add support for TI CDCE6214 Sascha Hauer
2025-04-30 9:01 ` [PATCH v4 1/3] clk: make determine_rate optional for non reparenting clocks Sascha Hauer
2025-04-30 22:15 ` Stephen Boyd [this message]
2025-04-30 9:01 ` [PATCH v4 2/3] dt-bindings: clock: add TI CDCE6214 binding Sascha Hauer
2025-05-01 11:54 ` Krzysztof Kozlowski
2025-05-05 17:50 ` Stephen Boyd
2025-05-07 8:05 ` Sascha Hauer
2025-05-07 20:11 ` Stephen Boyd
2025-05-08 7:22 ` Sascha Hauer
2025-06-16 10:02 ` Sascha Hauer
2025-04-30 9:01 ` [PATCH v4 3/3] clk: add TI CDCE6214 clock driver Sascha Hauer
2025-05-01 18:48 ` Stephen Boyd
2025-05-05 10:02 ` Sascha Hauer
2025-05-07 7:07 ` kernel test robot
2025-05-09 6:39 ` [PATCH v4 0/3] clk: add support for TI CDCE6214 Sascha Hauer
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=40bf9ffc7ae98f6601122cd8850418f5@kernel.org \
--to=sboyd@kernel.org \
--cc=alsi@bang-olufsen.dk \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).