From: Drew Fustini <fustini@kernel.org>
To: Yao Zi <ziyao@disroot.org>
Cc: Guo Ren <guoren@kernel.org>, Fu Wei <wefu@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>, Icenowy Zheng <uwu@icenowy.me>,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
Han Gao <rabenda.cn@gmail.com>, Han Gao <gaohan@iscas.ac.cn>
Subject: Re: [PATCH 2/7] clk: thead: th1520-ap: Poll for PLL lock and wait for stability
Date: Mon, 24 Nov 2025 14:08:00 -0800 [thread overview]
Message-ID: <aSTXQG5yIIGFjflG@x1> (raw)
In-Reply-To: <20251120131416.26236-3-ziyao@disroot.org>
On Thu, Nov 20, 2025 at 01:14:11PM +0000, Yao Zi wrote:
> All PLLs found on TH1520 SoC take 21250ns at maximum to lock, and their
> lock status is indicated by register PLL_STS (offset 0x80 inside AP
> clock controller). We should poll the register to ensure the PLL
> actually locks after enabling it.
>
> Furthermore, a 30us delay is added after enabling the PLL, after which
> the PLL could be considered stable as stated by vendor clock code.
>
> Fixes: 56a48c1833aa ("clk: thead: add support for enabling/disabling PLLs")
> Signed-off-by: Yao Zi <ziyao@disroot.org>
> ---
> drivers/clk/thead/clk-th1520-ap.c | 34 +++++++++++++++++++++++++++++--
> 1 file changed, 32 insertions(+), 2 deletions(-)
Thanks for working on this patch series.
[...]
> @@ -299,9 +310,21 @@ static void ccu_pll_disable(struct clk_hw *hw)
> static int ccu_pll_enable(struct clk_hw *hw)
> {
> struct ccu_pll *pll = hw_to_ccu_pll(hw);
> + u32 reg;
> + int ret;
>
> - return regmap_clear_bits(pll->common.map, pll->common.cfg1,
> - TH1520_PLL_VCO_RST);
> + regmap_clear_bits(pll->common.map, pll->common.cfg1,
> + TH1520_PLL_VCO_RST);
> +
> + ret = regmap_read_poll_timeout_atomic(pll->common.map, TH1520_PLL_STS,
> + reg, reg & pll->lock_sts_mask,
> + 5, TH1520_PLL_LOCK_TIMEOUT_US);
Is there a reason for the specific value of 5 uS polling delay?
> + if (ret)
> + return ret;
> +
> + udelay(TH1520_PLL_STABLE_DELAY_US);
Is it the case that the 30 uS delay after the lock bit is set is just so
that it has the same behavior as the vendor's code? Or did you notice
stability problems without this?
Thanks,
Drew
next prev parent reply other threads:[~2025-11-24 22:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 13:14 [PATCH 0/7] Implement CPU frequency scaling for TH1520 Yao Zi
2025-11-20 13:14 ` [PATCH 1/7] dt-bindings: clock: thead,th1520-clk-ap: Add ID for C910 bus clock Yao Zi
2025-11-20 18:01 ` Conor Dooley
2025-11-20 13:14 ` [PATCH 2/7] clk: thead: th1520-ap: Poll for PLL lock and wait for stability Yao Zi
2025-11-24 22:08 ` Drew Fustini [this message]
2025-11-25 3:19 ` Yao Zi
2025-11-26 14:39 ` Drew Fustini
2025-11-26 14:52 ` Drew Fustini
2025-11-26 15:16 ` Yao Zi
2025-11-20 13:14 ` [PATCH 3/7] clk: thead: th1520-ap: Add C910 bus clock Yao Zi
2025-11-26 15:46 ` Drew Fustini
2025-11-20 13:14 ` [PATCH 4/7] clk: thead: th1520-ap: Support setting PLL rates Yao Zi
2025-11-26 15:46 ` Drew Fustini
2025-11-20 13:14 ` [PATCH 5/7] clk: thead: th1520-ap: Add macro to define multiplexers with flags Yao Zi
2025-11-24 22:14 ` Drew Fustini
2025-11-25 3:25 ` Yao Zi
2025-11-26 15:47 ` Drew Fustini
2025-11-20 13:14 ` [PATCH 6/7] clk: thead: th1520-ap: Support CPU frequency scaling Yao Zi
2025-11-27 20:33 ` Drew Fustini
2025-11-20 13:14 ` [PATCH 7/7] [Not For Upstream] riscv: dts: thead: Add CPU clock and OPP table for TH1520 Yao Zi
2025-12-19 19:32 ` [PATCH 0/7] Implement CPU frequency scaling " Drew Fustini
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=aSTXQG5yIIGFjflG@x1 \
--to=fustini@kernel.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gaohan@iscas.ac.cn \
--cc=guoren@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rabenda.cn@gmail.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=uwu@icenowy.me \
--cc=wefu@redhat.com \
--cc=ziyao@disroot.org \
/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).