All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Masney <bmasney@redhat.com>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: "AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Dong Aisheng" <aisheng.dong@nxp.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Yassine Oudjana" <y.oudjana@protonmail.com>,
	"Laura Nao" <laura.nao@collabora.com>,
	"Nícolas F. R. A. Prado" <nfraprado@collabora.com>,
	"Chia-I Wu" <olvaffe@gmail.com>,
	"Chen-Yu Tsai" <wenst@chromium.org>,
	kernel@collabora.com, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc
Date: Thu, 16 Oct 2025 16:52:30 -0400	[thread overview]
Message-ID: <aPFbDl_JKyDay1S5@redhat.com> (raw)
In-Reply-To: <20251010-mtk-pll-rpm-v3-1-fb1bd15d734a@collabora.com>

Hi Nicolas,

On Fri, Oct 10, 2025 at 10:47:09PM +0200, Nicolas Frattaroli wrote:
> When CLK_OPS_PARENT_ENABLE was introduced, it guarded various clock
> operations, such as setting the rate or switching parents. However,
> another operation that can and often does touch actual hardware state is
> recalc_rate, which may also be affected by such a dependency.
> 
> Add parent enables/disables where the recalc_rate op is called directly.
> 
> Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
> Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)")
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
>  drivers/clk/clk.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 85d2f2481acf360f0618a4a382fb51250e9c2fc4..1b0f9d567f48e003497afc98df0c0d2ad244eb90 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1921,7 +1921,14 @@ static unsigned long clk_recalc(struct clk_core *core,
>  	unsigned long rate = parent_rate;
>  
>  	if (core->ops->recalc_rate && !clk_pm_runtime_get(core)) {
> +		if (core->flags & CLK_OPS_PARENT_ENABLE)
> +			clk_core_prepare_enable(core->parent);
> +
>  		rate = core->ops->recalc_rate(core->hw, parent_rate);
> +
> +		if (core->flags & CLK_OPS_PARENT_ENABLE)
> +			clk_core_disable_unprepare(core->parent);
> +
>  		clk_pm_runtime_put(core);
>  	}
>  	return rate;

clk_change_rate() has the following code:


        if (core->flags & CLK_OPS_PARENT_ENABLE)
                clk_core_prepare_enable(parent);

	...

        core->rate = clk_recalc(core, best_parent_rate);

	...

        if (core->flags & CLK_OPS_PARENT_ENABLE)
                clk_core_disable_unprepare(parent);

clk_change_rate() ultimately is called by various clk_set_rate
functions. Will that be a problem for the double calls to
clk_core_prepare_enable()?

Fanning this out to the edge further is going to make the code even
more complicated. What do you think about moving this to
clk_core_enable_lock()? I know the set_parent operation has a special
case that would need to be worked around.

Brian



  reply	other threads:[~2025-10-16 20:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-10 20:47 [PATCH v3 0/5] MediaTek PLL Refactors and Fixes Nicolas Frattaroli
2025-10-10 20:47 ` [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc Nicolas Frattaroli
2025-10-16 20:52   ` Brian Masney [this message]
2025-10-17 12:21     ` Nicolas Frattaroli
2025-10-20 19:36       ` Brian Masney
2026-01-27 17:01   ` Mark Brown
2026-01-27 17:25     ` Mark Brown
2026-01-27 18:18       ` Nicolas Frattaroli
2026-01-27 23:14         ` Mark Brown
2026-01-28 14:09           ` Nicolas Frattaroli
2026-01-28 14:47             ` Mark Brown
2026-01-28 14:55               ` Alexander Stein
2026-01-28 15:21                 ` Mark Brown
2026-01-28 16:31                   ` Nicolas Frattaroli
2026-01-28 17:08                     ` Mark Brown
2026-01-28 16:04               ` Nicolas Frattaroli
2026-01-28 19:01                 ` Stephen Boyd
2026-01-28 19:59                   ` Nicolas Frattaroli
2026-02-02 16:54                   ` Mark Brown
2025-10-10 20:47 ` [PATCH v3 2/5] clk: mediatek: Refactor pll registration to pass device Nicolas Frattaroli
2025-10-10 20:47 ` [PATCH v3 3/5] clk: mediatek: Pass device to clk_hw_register for PLLs Nicolas Frattaroli
2025-10-10 20:47 ` [PATCH v3 4/5] clk: mediatek: Refactor pllfh registration to pass device Nicolas Frattaroli
2025-10-10 20:47 ` [PATCH v3 5/5] clk: mediatek: Add mfg_eb as parent to mt8196 mfgpll clocks Nicolas Frattaroli

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=aPFbDl_JKyDay1S5@redhat.com \
    --to=bmasney@redhat.com \
    --cc=aisheng.dong@nxp.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=kernel@collabora.com \
    --cc=laura.nao@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=nfraprado@collabora.com \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=olvaffe@gmail.com \
    --cc=sboyd@kernel.org \
    --cc=wenst@chromium.org \
    --cc=y.oudjana@protonmail.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.