From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Alexander Stein <alexander.stein@ew.tq-group.com>,
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 17:31:35 +0100 [thread overview]
Message-ID: <4040610.5fSG56mABF@workhorse> (raw)
In-Reply-To: <9ed19fb1-258f-44c4-b816-73c0d7d28a6e@sirena.org.uk>
On Wednesday, 28 January 2026 16:21:47 Central European Standard Time Mark Brown wrote:
> On Wed, Jan 28, 2026 at 03:55:54PM +0100, Alexander Stein wrote:
>
> > This is for TQMa8MPxL/MBa8MPxL:
>
> > [ 1.452788] __clk_core_init: enabling parent audio_pll1_out for clkout1_sel
> > [ 1.457677] __clk_core_init: disabling parent audio_pll1_out for clkout1_sel
> > [ 1.464270] __clk_core_init: enabling parent audio_pll1_out for clkout2_sel
> > [ 1.471760] __clk_core_init: disabling parent audio_pll1_out for clkout2_sel
> > [ 1.478360] __clk_core_init: enabling parent sys_pll2_500m for arm_a53_div
> > [ 1.485259] __clk_core_init: disabling parent sys_pll2_500m for arm_a53_div
>
> As expected same result on i.MX8MP-EVK.
>
This one puzzles me a little. arm_a53_div is neither marked critical
nor is its parent. If arm_a53_div is required for the system to function,
then I'd have expected at least it to be marked as critical, allowing us
to do the workaround in init I proposed as an alternate solution for the
stm32mp1 in my other reply.
Also, after reading the code some more, I think that alternate solution
has a simpler implementation: move the parent disable to after the
if (core->flags & CLK_IS_CRITICAL) {
check in __clk_core_init.
One explanation is that some other critical clock hangs off sys_pll2_500m,
but we're spoiled for choice here. I can't think of a simple fix right now
that I feel confident in.
Every IMX8MP composite clock that isn't critical seems to set
IMX_COMPOSITE_CLK_FLAGS_DEFAULT, which includes CLK_OPS_PARENT_ENABLE,
which seems like a pretty weird choice to make when you then rely on
the parent not getting touched during __clk_core_init.
I will try to get an RFC fix out tonight (CET). I think STM32MP1 is
falling over because I messed up, and i.MX8MP is falling over due to
a combination of me messing up and its clock driver messing up.
Kind regards,
Nicolas Frattaroli
next prev parent reply other threads:[~2026-01-28 16:32 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
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 [this message]
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=4040610.5fSG56mABF@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=aisheng.dong@nxp.com \
--cc=alexander.stein@ew.tq-group.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.