From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Mark Brown <broonie@kernel.org>
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: Wed, 28 Jan 2026 15:09:46 +0100 [thread overview]
Message-ID: <6678782.DvuYhMxLoT@workhorse> (raw)
In-Reply-To: <1cbf0f37-13de-46a5-a3c0-0509048c519e@sirena.org.uk>
On Wednesday, 28 January 2026 00:14:29 Central European Standard Time Mark Brown wrote:
> On Tue, Jan 27, 2026 at 07:18:02PM +0100, Nicolas Frattaroli wrote:
>
> > Can someone let me know which clocks (with which parent) in those
> > affected devices is causing this? I'm wondering if this change
> > unmasked some undeclared dependency that it's now stumbling over
> > because it's enabling the parent earlier than ever.
>
> Do you have a debugging patch we could run which would say which clocks
> are impacted? I guess it's more of an issue for the platforms that give
> no output but for at least Avenger96 I was getting earlycon output.
Try this one
---
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 1b0f9d567f48..fa1443517768 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1921,13 +1921,21 @@ 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)
+ if (core->flags & CLK_OPS_PARENT_ENABLE) {
+ pr_info("%s: enabling parent %s for %s\n", __func__,
+ core->parent ? core->parent->name : "(null)",
+ core->name);
clk_core_prepare_enable(core->parent);
+ }
rate = core->ops->recalc_rate(core->hw, parent_rate);
- if (core->flags & CLK_OPS_PARENT_ENABLE)
+ if (core->flags & CLK_OPS_PARENT_ENABLE) {
+ pr_info("%s: disabling parent %s for %s\n", __func__,
+ core->parent ? core->parent->name : "(null)",
+ core->name);
clk_core_disable_unprepare(core->parent);
+ }
clk_pm_runtime_put(core);
}
@@ -4038,8 +4046,12 @@ static int __clk_core_init(struct clk_core *core)
*/
clk_core_update_duty_cycle_nolock(core);
- if (core->flags & CLK_OPS_PARENT_ENABLE)
+ if (core->flags & CLK_OPS_PARENT_ENABLE) {
+ pr_info("%s: enabling parent %s for %s\n", __func__,
+ core->parent ? core->parent->name : "(null)",
+ core->name);
clk_core_prepare_enable(core->parent);
+ }
/*
* Set clk's rate. The preferred method is to use .recalc_rate. For
@@ -4056,8 +4068,12 @@ static int __clk_core_init(struct clk_core *core)
rate = 0;
core->rate = core->req_rate = rate;
- if (core->flags & CLK_OPS_PARENT_ENABLE)
+ if (core->flags & CLK_OPS_PARENT_ENABLE) {
+ pr_info("%s: disabling parent %s for %s\n", __func__,
+ core->parent ? core->parent->name : "(null)",
+ core->name);
clk_core_disable_unprepare(core->parent);
+ }
/*
* Enable CLK_IS_CRITICAL clocks so newly added critical clocks
---
I don't remember if printk buffers are flushed after each invocation and
couldn't quickly find a kernel parameter to control this, but from
experience I think these prints should show up if it then hangs the SoC
on the very next line.
> > To not have me break everyone's -next for days on end, feel free
> > to drop this patch. MT8196, which this was added for, doesn't boot
> > with mainline yet anyway.
>
> Please, this is making my test lab miserable.
>
The good news is that the rest of the series can stay without doing
any harm if this single patch gets dropped, and I can re-attempt
this in the next cycle.
Kind regards,
Nicolas Frattaroli
next prev parent reply other threads:[~2026-01-28 14:10 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
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 [this message]
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=6678782.DvuYhMxLoT@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=aisheng.dong@nxp.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=broonie@kernel.org \
--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=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.