[PATCH v3 2/4] clk: amlogic: Improve the issue of PLL lock failures

[Chuan Liu]

Hi John,
   Thanks for your testing and feedback.

On 10/21/2026 1:59 PM, John O'Callaghan wrote:
> [你通常不会收到来自 johnocallaghan at 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 at 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