linux-kernel - Re: [PATCH v3 0/4] clk: amlogic: optimize the PLL driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a43d769b-bc61-40df-aa96-c67eb30105d6@amlogic.com>
Date: Mon, 10 Nov 2025 10:49:49 +0800
From: Chuan Liu <chuan.liu@...ogic.com>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: Neil Armstrong <neil.armstrong@...aro.org>,
 Jerome Brunet <jbrunet@...libre.com>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Kevin Hilman <khilman@...libre.com>,
 linux-amlogic@...ts.infradead.org, linux-clk@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/4] clk: amlogic: optimize the PLL driver

Hi Martin,

Thank you for providing the test results. I previously found a
Meson8b board and wanted to try a stress test, but it threw errors
when running in the kernel (maybe because my bootloader version is
too old)... Anyway, thank you!

On 11/9/2025 5:04 AM, Martin Blumenstingl wrote:
> [ EXTERNAL EMAIL ]
> 
> On Fri, Oct 31, 2025 at 9:10 AM Chuan Liu via B4 Relay
> <devnull+chuan.liu.amlogic.com@...nel.org> wrote:
>>
>> This patch series consists of four topics involving the amlogic PLL
>> driver:
>> - Fix out-of-range PLL frequency setting.
>> - Improve the issue of PLL lock failures.
>> - Add handling for PLL lock failure.
>> - Optimize PLL enable timing.
>>
>> For easier review and management, these are submitted as a single
>> patch series.
>>
>> The PLL timing optimization changes were merged into our internal
>> repository quite some time ago and have been verified on a large
>> number of SoCs:
>> - Already supported upstream: G12A, G12B, SM1, S4, A1, C3.
>> - Planned for upstream support: T7, A5, A4, S7, S7D, S6, etc.
>>
>> Based on the upstream code base, I have performed functional testing
>> on G12A, A1, A5, A4, T7, S7, S7D, and S6, all of which passed.
> In the past I had most problems with Meson8/8b/8m2 CPU clock scaling
> (via sys_pll).
> So I tested this series locally using the following shell script on an
> Odroid-C1 (Meson8b):
> #!/bin/bash
> 
> CPUFREQ="/sys/bus/cpu/devices/cpu0/cpufreq"
> 
> echo "userspace" > "${CPUFREQ}/scaling_governor"
> 
> while read -ra LINE
> do
>      for (( i=0; i<${#LINE[*]}; i++ ))
>      do
>          for (( j=0; j<${#LINE[*]}; j++ ))
>          do
>              if [ $i != $j ]
>              then
>                  echo "${LINE[i]} -> ${LINE[j]}"
>                  echo "${LINE[i]}" > "${CPUFREQ}/scaling_setspeed"
>                  sleep 1s
>                  echo "${LINE[j]}" > "${CPUFREQ}/scaling_setspeed"
>                  sleep 1s
>              fi
>          done
>      done
> done < "${CPUFREQ}/scaling_available_frequencies"
> 
> This has been running in a loop for two hours (at an ambient
> temperature of ~13°C) and I haven't observed any problem.
> Since most patches are a no-op for my case I'll separately reply to
> patch #2 with my Tested-by (as that's what I've been effectively
> testing).
> 
> 
> Best regards,
> Martin