From: "Troy Mitchell" <troy.mitchell@linux.spacemit.com>
To: "Yao Zi" <me@ziyao.cc>,
"Michael Turquette" <mturquette@baylibre.com>,
"Stephen Boyd" <sboyd@kernel.org>,
"Brian Masney" <bmasney@redhat.com>,
"Yixun Lan" <dlan@kernel.org>,
"Inochi Amaoto" <inochiama@outlook.com>,
"Alex Elder" <elder@riscstar.com>,
"Haylen Chu" <heylenay@4d2.org>
Cc: <linux-clk@vger.kernel.org>, <linux-riscv@lists.infradead.org>,
<spacemit@lists.linux.dev>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] clk: spacemit: re-enable PLLs after init
Date: Mon, 10 Aug 2026 16:42:02 +0800 [thread overview]
Message-ID: <DKL4P0ONTLFP.3QG0CCUU76BUG@linux.spacemit.com> (raw)
In-Reply-To: <anGeZk0-YShccqwE@pie>
[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]
> I don't think this patch makes sense.
>
> If this PLL is essential for some components of the systems to work,
> there's no chance to re-program it safely after the kernel gets started,
> since all the PLLs in K1 and K3 are specified as CLK_SET_RATE_GATE.
>
> If the essential clocks could be re-parented glitchlessly, registering
> a notifier and re-parenting it before the PLL disables might be a
> solution. In this case, we need to delay the operation in
> ccu_pll*_init() until clock registration fully completes.
>
> Otherwise, re-enabling the PLL seems totally extra here, they could be
> enabled on the fly when it's going to be used.
You are right. In both hunks, ccu_pll*_disable() has already gated the
PLL before the newly added ccu_pll*_enable() can run:
> @@ -148,7 +148,7 @@ static int ccu_pll_init(struct clk_hw *hw)
> ccu_pll_disable(hw);
> ccu_pll_update_param(pll, &pll->config.rate_tbl[0]);
>
> - return 0;
> + return ccu_pll_enable(hw);
> }
> [...]
>
> @@ -252,7 +252,7 @@ static int ccu_plla_init(struct clk_hw *hw)
> ccu_plla_disable(hw);
> ccu_plla_update_param(pll, &pll->config.rate_tbl[0]);
>
> - return 0;
> + return ccu_plla_enable(hw);
> }
Re-enabling the PLL afterwards therefore does not make reprogramming
safe for a live consumer. I will drop this patch, "[PATCH 1/2]
clk: spacemit: re-enable PLLs after init", from v2.
To avoid delaying the 1.8 GHz rate-table update while this broader issue
is investigated, I will resend the current "[PATCH 2/2] clk: spacemit:
k3: add 1.8 GHz PLL5 and PLL8 rates" as a standalone patch. It only adds
the firmware-selected 1.8 GHz settings to the rate tables.
The existing problem of reprogramming an unmatched PLL from
ccu_pll*_init() needs a broader solution and is independent of the rate
table update. I will address this issue in a separate patch series.
- Troy
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 248 bytes --]
next prev parent reply other threads:[~2026-08-10 8:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 7:02 [PATCH 0/2] clk: spacemit: fix PLL init and add K3 1.8 GHz rates Troy Mitchell
2026-08-04 7:02 ` [PATCH 1/2] clk: spacemit: re-enable PLLs after init Troy Mitchell
2026-08-04 8:10 ` Yao Zi
2026-08-10 8:42 ` Troy Mitchell [this message]
2026-08-04 7:02 ` [PATCH 2/2] clk: spacemit: k3: add 1.8 GHz PLL5 and PLL8 rates Troy Mitchell
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=DKL4P0ONTLFP.3QG0CCUU76BUG@linux.spacemit.com \
--to=troy.mitchell@linux.spacemit.com \
--cc=bmasney@redhat.com \
--cc=dlan@kernel.org \
--cc=elder@riscstar.com \
--cc=heylenay@4d2.org \
--cc=inochiama@outlook.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=me@ziyao.cc \
--cc=mturquette@baylibre.com \
--cc=sboyd@kernel.org \
--cc=spacemit@lists.linux.dev \
/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