linux-clk.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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;

  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).