From: Chuan Liu <chuan.liu@amlogic.com>
To: John O'Callaghan <johnocallaghan@gmail.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Jerome Brunet <jbrunet@baylibre.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Kevin Hilman <khilman@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/4] clk: amlogic: Improve the issue of PLL lock failures
Date: Wed, 21 Oct 2026 16:24:20 +0800 [thread overview]
Message-ID: <55844de7-efa2-42b1-8d5e-94e826ee27fb@amlogic.com> (raw)
In-Reply-To: <20261021060005.2947837-1-johnocallaghan@gmail.com>
Hi John,
Thanks for your testing and feedback.
On 10/21/2026 1:59 PM, John O'Callaghan wrote:
> [你通常不会收到来自 johnocallaghan@gmail.com 的电子邮件。请访问 https://aka.ms/LearnAboutSenderIdentification,以了解这一点为什么很重要]
>
> [ EXTERNAL EMAIL ]
>
> Hi Chuan,
>
> Jerome asked what was tested; here is a G12A data point.
>
> On a Radxa Zero (S905Y2, G12A) running v7.3, sys_pll_dco occasionally
> fails to lock on cpufreq transitions, at room temperature:
>
> meson_clk_pll_set_rate: pll sys_pll_dco didn't lock, trying to set old rate 6000000000
>
> It happens with all the sys_pll OPPs (old DCO rates 3216, 3408, 3600,
> 4800, 5592 and 6000 MHz) but, here, only while the video decoder is
> busy.
I understand there should be no direct connection between the video
decoder and sys_pll lock failure. Perhaps it's due to increased power
consumption when the video decoder is active, causing higher power
supply ripple? Have you conducted comparative tests on the ripple
conditions of various power rails after enabling the video decoder,
especially VDDAO_1V8 (which supplies power to the PLL)?
The operation of the video decoder may also cause more frequent load
changes, leading the sys_pll to re-lock frequently and thus increasing
the probability of PLL lock failure.
Reproducer: the userspace governor, random writes of the
> 1200-1800 MHz OPPs to scaling_setspeed (~700 transitions/s), with a
> GStreamer v4l2 decode loop (meson vdec, H.264 + VP9 1080p) running
> alongside. 46 C SoC temperature.
Previously, we encountered similar PLL lock failure issues during
low-temperature burn-in testing (at -10°C to -15°C) with G12A, and we
had previously pushed a mandatory patch to customers. This patch
significantly improves PLL lock failure scenarios, you can first apply
it locally.
>
> transitions lock failures
> v7.3 500290 33
> v7.3, no decoder running 250056 0
> v7.3 + this series (1-4) 500089 0
> v7.3 + patch 2/4 only 500066 0
>
> So on G12A it is the 20 us delays of this patch that make the
> difference.
>
> Tested-by: John O'Callaghan <johnocallaghan@gmail.com> # Radxa Zero (G12A)
Thanks!
>
> The testing was scripted with the help of an LLM coding assistant; I
> ran it on my board and checked the results.
>
> Thanks,
> John
--
Best regards,
Chuan
next prev parent reply other threads:[~2026-10-21 8:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 8:10 [PATCH v3 0/4] clk: amlogic: optimize the PLL driver Chuan Liu via B4 Relay
2025-10-31 8:10 ` [PATCH v3 1/4] clk: amlogic: Fix out-of-range PLL frequency setting Chuan Liu via B4 Relay
2025-10-31 8:10 ` [PATCH v3 2/4] clk: amlogic: Improve the issue of PLL lock failures Chuan Liu via B4 Relay
2025-11-08 21:04 ` Martin Blumenstingl
2026-10-21 5:59 ` John O'Callaghan
2026-10-21 8:24 ` Chuan Liu [this message]
2025-10-31 8:10 ` [PATCH v3 3/4] clk: amlogic: Add handling for PLL lock failure Chuan Liu via B4 Relay
2025-10-31 8:10 ` [PATCH v3 4/4] clk: amlogic: Optimize PLL enable timing Chuan Liu via B4 Relay
2025-10-31 9:04 ` [PATCH v3 0/4] clk: amlogic: optimize the PLL driver Jerome Brunet
2025-10-31 15:09 ` Chuan Liu
2025-10-31 16:27 ` Jerome Brunet
2025-11-04 5:28 ` Chuan Liu
2025-11-08 21:04 ` Martin Blumenstingl
2025-11-10 2:49 ` Chuan Liu
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=55844de7-efa2-42b1-8d5e-94e826ee27fb@amlogic.com \
--to=chuan.liu@amlogic.com \
--cc=jbrunet@baylibre.com \
--cc=johnocallaghan@gmail.com \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=mturquette@baylibre.com \
--cc=neil.armstrong@linaro.org \
--cc=sboyd@kernel.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
all inboxes | Powered by JetHome®