From: Stephen Boyd <sboyd@kernel.org>
To: Jan Dakinevich <jan.dakinevich@salutedevices.com>,
Michael Turquette <mturquette@baylibre.com>,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: kernel@salutedevices.com,
Jan Dakinevich <jan.dakinevich@salutedevices.com>
Subject: Re: [PATCH] clk: allow to skip clk_core_req_round_rate_nolock()
Date: Thu, 22 Feb 2024 15:20:49 -0800 [thread overview]
Message-ID: <c79909e4e55badc8f094d2ff8c4d34ca.sboyd@kernel.org> (raw)
In-Reply-To: <20240126201433.1830600-1-jan.dakinevich@salutedevices.com>
Quoting Jan Dakinevich (2024-01-26 12:14:33)
> Calling of clk_core_req_round_rate_nolock() can be time-consuming in a
> case of deep hierarchy with multiple dividers/parents. But if the clock
> already has exactly the same rate as desired, there is no need to
> determine how it could be rounded.
What exactly are you trying to avoid? Is this an optimization or a bug
fix? TL;DR: I'm unlikely to apply this patch.
I could see some driver implementing round_rate()/determine_rate() in a
way that rounds the rate passed in, so that even if the rate is what the
clk is running at _right now_, it still wants to change it to something
else, or at least call down into the driver to call the set_rate clk_op.
Applying this patch will break that. The contract is that
clk_set_rate(rate) == clk_set_rate(clk_round_rate(rate)). It doesn't
look like anything needs to change.
next prev parent reply other threads:[~2024-02-22 23:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 20:14 [PATCH] clk: allow to skip clk_core_req_round_rate_nolock() Jan Dakinevich
2024-02-20 17:34 ` Jan Dakinevich
2024-02-22 23:20 ` Stephen Boyd [this message]
2024-02-23 21:47 ` Jan Dakinevich
2024-02-29 2:16 ` Stephen Boyd
2024-03-09 21:20 ` Jan Dakinevich
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=c79909e4e55badc8f094d2ff8c4d34ca.sboyd@kernel.org \
--to=sboyd@kernel.org \
--cc=jan.dakinevich@salutedevices.com \
--cc=kernel@salutedevices.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.