From: Stephen Boyd <sboyd@kernel.org>
To: Michael Turquette <mturquette@baylibre.com>,
Yang Xiwen <forbidden405@outlook.com>,
Yang Xiwen via B4 Relay
<devnull+forbidden405.outlook.com@kernel.org>
Cc: linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND] clk: set initial best mux parent to current parent when determining rate
Date: Wed, 28 Feb 2024 18:25:18 -0800 [thread overview]
Message-ID: <f8bcec654f618f8639a882bf70273618.sboyd@kernel.org> (raw)
In-Reply-To: <SEZPR06MB69597E78EA08D5BDF66DBEBC965F2@SEZPR06MB6959.apcprd06.prod.outlook.com>
Quoting Yang Xiwen (2024-02-28 18:13:04)
> On 2/29/2024 9:58 AM, Stephen Boyd wrote:
> > Quoting Yang Xiwen via B4 Relay (2024-02-23 09:18:52)
> >> From: Yang Xiwen <forbidden405@outlook.com>
> >>
> >> Originally, the initial clock rate is hardcoded to 0, this can lead to
> >> some problem when setting a very small rate with CLK_MUX_ROUND_NEAREST.
> >
> > Did you mean CLK_MUX_ROUND_CLOSEST?
>
> You are right :).
>
> >
> >>
> >> For example, if the lowest possible rate privided by the mux is 1000Hz,
> >
> > s/privided/provided/
> >
> >> setting a rate below 500Hz will fail, because no clock can provide a
> >> better rate than the non-existant 0. But it should succeed with 1000Hz
> >> being set.
> >>
> >> Setting the initial best parent to current parent could solve this bug
> >> very well.
> >>
> >> Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
> >> ---
> >> This is actually a v2 of [1], but seems too simple to have a unittest.
> >> It's tested in a mmc host driver.
> >
> > It's not too simple for a unittest.
> >
> >>
> >> [1]: https://lore.kernel.org/linux-clk/20230421-clk-v3-1-9ff79e7e7fed@outlook.com/
> >
> > In that thread I asked you to please Cc Maxime. Please do that.
> >
> >> ---
> >> drivers/clk/clk.c | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> >> index 2253c154a824..d98cebd7ff03 100644
> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -649,6 +649,10 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw,
> >>
> >> /* find the parent that can provide the fastest rate <= rate */
> >> num_parents = core->num_parents;
> >> + if (core->parent) {
> >> + best_parent = core->parent;
> >> + best = clk_core_get_rate_nolock(best_parent);
> >> + }
> >
> > Is the problem that we're not using abs_diff()?
>
>
> No, i think. It has nothing to do with the code here. It's because of
> the initial best_parent/best_parent_rate.
Alright.
>
> >
> > ----8<----
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index a3bc7fb90d0f..91023345595f 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -542,7 +542,7 @@ static bool mux_is_better_rate(unsigned long rate, unsigned long now,
> > unsigned long best, unsigned long flags)
> > {
> > if (flags & CLK_MUX_ROUND_CLOSEST)
> > - return abs(now - rate) < abs(best - rate);
> > + return abs_diff(now, rate) < abs_diff(best, rate);
>
> Without this patch, the initial `best` rate would be always 0. This is
> wrong for most cases, 0Hz might (usually) be unavailable. We should use
> a valid rate(i.e. current rate) initially.
Ok. But you set best to the parent rate. So why not use 'core->rate'
directly as 'best'?
next prev parent reply other threads:[~2024-02-29 2:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 17:18 [PATCH RESEND] clk: set initial best mux parent to current parent when determining rate Yang Xiwen
2024-02-23 17:18 ` Yang Xiwen via B4 Relay
2024-02-29 1:58 ` Stephen Boyd
2024-02-29 2:13 ` Yang Xiwen
2024-02-29 2:25 ` Stephen Boyd [this message]
2024-02-29 2:33 ` Yang Xiwen
2024-03-01 1:42 ` Stephen Boyd
2024-03-01 1:58 ` Yang Xiwen
-- strict thread matches above, loose matches on Subject: below --
2024-02-19 19:59 Yang Xiwen
2024-02-19 19:59 ` Yang Xiwen via B4 Relay
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=f8bcec654f618f8639a882bf70273618.sboyd@kernel.org \
--to=sboyd@kernel.org \
--cc=devnull+forbidden405.outlook.com@kernel.org \
--cc=forbidden405@outlook.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.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.