From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Maxime Ripard <mripard@redhat.com>
Cc: Abel Vesa <abelvesa@kernel.org>, Peng Fan <peng.fan@nxp.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
Ying Liu <victor.liu@nxp.com>, Marek Vasut <marex@denx.de>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-clk@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Abel Vesa <abel.vesa@linaro.org>,
Herve Codina <herve.codina@bootlin.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Ian Ray <ian.ray@ge.com>
Subject: Re: [PATCH 4/5] clk: Add flag to prevent frequency changes when walking subtrees
Date: Mon, 23 Dec 2024 19:43:13 +0100 [thread overview]
Message-ID: <87bjx2tf3y.fsf@bootlin.com> (raw)
In-Reply-To: <20241217-brown-wapiti-of-promotion-e3bec6@houat> (Maxime Ripard's message of "Tue, 17 Dec 2024 13:47:53 +0100")
Hi Maxime,
On 17/12/2024 at 13:47:53 +01, Maxime Ripard <mripard@redhat.com> wrote:
> On Thu, Nov 21, 2024 at 06:41:14PM +0100, Miquel Raynal wrote:
>> There are mainly two ways to change a clock frequency.
>
> There's much more than that :)
"mainly"
Or maybe I should have added "on purpose".
>
> Off the top of my head, setting/clearing a min/max rate and changing the
> parent might also result in a rate change.
>
> And then, the firmware might get involved too.
>
>> The active way requires calling ->set_rate() in order to ask "on
>> purpose" for a frequency change. Otherwise, a clock can passively see
>> its frequency being updated depending on upstream clock frequency
>> changes. In most cases it is fine to just accept the new upstream
>> frequency - which by definition will have an impact on downstream
>> frequencies if we do not recalculate internal divisors. But there are
>> cases where, upon an upstream frequency change, we would like to
>> maintain a specific rate.
>
> Why is clk_set_rate_exclusive not enough?
I am trying to protect these rate changes from subtree walks, I don't
see where setting an exclusive rate would have an effect? But I might be
overlooking something, definitely.
...
>> @@ -2272,7 +2271,13 @@ static void clk_calc_subtree(struct clk_core *core)
>> {
>> struct clk_core *child;
>>
>> - core->new_rate = clk_recalc(core, core->parent->new_rate);
>> + if (core->flags & CLK_NO_RATE_CHANGE_DURING_PROPAGATION) {
>> + core->new_rate = clk_determine(core, core->rate);
>> + if (!core->new_rate)
>> + core->new_rate = clk_recalc(core, core->parent->new_rate);
>> + } else {
>> + core->new_rate = clk_recalc(core, core->parent->new_rate);
>> + }
>
> Sorry, it's not clear to me how it works. How will the parent clocks
> will get notified to adjust their dividers in that scenario? Also, what
> if they can't?
The idea is: if the flag is set, instead of accepting the new upstream
rate and recalculate the downstream rate based on a previously set
divider value, we change our divider value to match the same frequency
as before. But if we cannot, then we just keep the old way.
Cheers,
Miquèl
next prev parent reply other threads:[~2024-12-23 18:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-21 17:41 [PATCH 0/5] clk: Fix simple video pipelines on i.MX8 Miquel Raynal
2024-11-21 17:41 ` [PATCH 1/5] clk: imx: clk-imx8mp: Allow LDB serializer clock reconfigure parent rate Miquel Raynal
2024-11-21 17:41 ` [PATCH 2/5] clk: Add a helper to determine a clock rate Miquel Raynal
2024-11-21 17:41 ` [PATCH 3/5] clk: Split clk_calc_subtree() Miquel Raynal
2024-11-21 17:41 ` [PATCH 4/5] clk: Add flag to prevent frequency changes when walking subtrees Miquel Raynal
2024-12-10 22:44 ` Stephen Boyd
2024-12-23 18:38 ` Miquel Raynal
2024-12-31 1:09 ` Stephen Boyd
2024-12-17 12:47 ` Maxime Ripard
2024-12-23 18:43 ` Miquel Raynal [this message]
2024-12-31 1:22 ` Stephen Boyd
2025-01-06 14:36 ` Maxime Ripard
2025-01-10 15:40 ` Miquel Raynal
2025-01-10 15:38 ` Miquel Raynal
2024-11-21 17:41 ` [PATCH 5/5] clk: imx: imx8mp: Prevent media clocks to be incompatibly changed Miquel Raynal
2024-11-22 6:01 ` [PATCH 0/5] clk: Fix simple video pipelines on i.MX8 Liu Ying
2024-11-22 9:54 ` Miquel Raynal
2024-11-26 6:49 ` Liu Ying
2024-11-26 11:03 ` Miquel Raynal
2024-11-27 7:24 ` Liu Ying
2024-12-17 12:54 ` Maxime Ripard
2024-12-23 18:59 ` Miquel Raynal
2025-01-06 14:45 ` 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=87bjx2tf3y.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=abel.vesa@linaro.org \
--cc=abelvesa@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=festevam@gmail.com \
--cc=herve.codina@bootlin.com \
--cc=ian.ray@ge.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=marex@denx.de \
--cc=mripard@redhat.com \
--cc=mturquette@baylibre.com \
--cc=peng.fan@nxp.com \
--cc=s.hauer@pengutronix.de \
--cc=sboyd@kernel.org \
--cc=shawnguo@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=victor.liu@nxp.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 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).