[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFBinCBSjKzHZ_k+c70B+YsJHiOS4qbjAgtnWaEeQy11xg94cA@mail.gmail.com>
Date: Sat, 8 Nov 2025 22:04:07 +0100
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: chuan.liu@...ogic.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
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
Powered by blists - more mailing lists