From: "Jernej Škrabec" <jernej.skrabec@gmail.com>
To: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Maxime Ripard <maxime@cerno.tech>
Cc: linux-clk@vger.kernel.org, Maxime Ripard <maxime@cerno.tech>,
Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Chen-Yu Tsai <wens@csie.org>,
Samuel Holland <samuel@sholland.org>,
linux-arm-kernel@lists.infradead.org, linux-rtc@vger.kernel.org,
linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v4 45/68] rtc: sun6i: Add a determine_rate hook
Date: Fri, 05 May 2023 20:46:12 +0200 [thread overview]
Message-ID: <1852119.tdWV9SEqCh@jernej-laptop> (raw)
In-Reply-To: <20221018-clk-range-checks-fixes-v4-45-971d5077e7d2@cerno.tech>
Dne petek, 05. maj 2023 ob 13:25:47 CEST je Maxime Ripard napisal(a):
> The Allwinner sun6i RTC clock implements a mux with a set_parent hook,
> but doesn't provide a determine_rate implementation.
>
> This is a bit odd, since set_parent() is there to, as its name implies,
> change the parent of a clock. However, the most likely candidates to
> trigger that parent change are either the assigned-clock-parents device
> tree property or a call to clk_set_rate(), with determine_rate()
> figuring out which parent is the best suited for a given rate.
>
> The other trigger would be a call to clk_set_parent(), but it's far less
> used, and it doesn't look like there's any obvious user for that clock.
>
> Similarly, it doesn't look like the device tree using that clock driver
> uses any of the assigned-clock properties on that clock.
>
> So, the set_parent hook is effectively unused, possibly because of an
> oversight. However, it could also be an explicit decision by the
> original author to avoid any reparenting but through an explicit call to
> clk_set_parent().
>
> The latter case would be equivalent to setting the determine_rate
> implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no
> determine_rate implementation is provided, clk_round_rate() (through
> clk_core_round_rate_nolock()) will call itself on the parent if
> CLK_SET_RATE_PARENT is set, and will not change the clock rate
> otherwise.
>
> And if it was an oversight, then we are at least explicit about our
> behavior now and it can be further refined down the line.
>
> Cc: Alessandro Zummo <a.zummo@towertech.it>
> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
> Cc: Samuel Holland <samuel@sholland.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-rtc@vger.kernel.org
> Cc: linux-sunxi@lists.linux.dev
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
> ---
> drivers/rtc/rtc-sun6i.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index dc76537f1b62..71548dd59a3a 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -214,6 +214,7 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw *hw,
> u8 index)
>
> static const struct clk_ops sun6i_rtc_osc_ops = {
> .recalc_rate = sun6i_rtc_osc_recalc_rate,
> + .determine_rate = clk_hw_determine_rate_no_reparent,
>
> .get_parent = sun6i_rtc_osc_get_parent,
> .set_parent = sun6i_rtc_osc_set_parent,
next prev parent reply other threads:[~2023-05-05 18:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-05 11:25 [PATCH v4 00/68] clk: Make determine_rate mandatory for muxes Maxime Ripard
2023-05-05 11:25 ` [PATCH v4 03/68] clk: Move no reparent case into a separate function Maxime Ripard
2023-06-13 11:15 ` Marek Szyprowski
2023-06-13 12:15 ` Marek Szyprowski
2023-06-13 12:29 ` Maxime Ripard
2023-05-05 11:25 ` [PATCH v4 04/68] clk: Introduce clk_hw_determine_rate_no_reparent() Maxime Ripard
2023-05-05 11:25 ` [PATCH v4 45/68] rtc: sun6i: Add a determine_rate hook Maxime Ripard
2023-05-05 18:46 ` Jernej Škrabec [this message]
2023-05-05 11:26 ` [PATCH v4 68/68] clk: Forbid to register a mux without determine_rate Maxime Ripard
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=1852119.tdWV9SEqCh@jernej-laptop \
--to=jernej.skrabec@gmail.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=maxime@cerno.tech \
--cc=mturquette@baylibre.com \
--cc=samuel@sholland.org \
--cc=sboyd@kernel.org \
--cc=wens@csie.org \
/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