Re: [PATCH 4/4] cpufreq: add an Amlogic speed-bin driver
From: neil . armstrong
Date: Mon Nov 09 2026 - 03:59:18 EST
On 11/8/26 22:45, Martin Blumenstingl wrote:
On Tue, Nov 3, 2026 at 10:46 AM Chuan Liu <chuan.liu@xxxxxxxxxxx> wrote:
That's great news, indeed!
Hi Martin,
Thank you for joining this discussion. :)
I have re-examined the capabilities provided by pm_opp and cpufreq-dt,
and it seems that we may also be able to adapt A9 fairly well based on
the amlogic-cpufreq.c here. So we have no objections to the driver
implementation in amlogic-cpufreq.c here.
I was most worried about before was that cpufreq-dt might not fully
handle the complicated clock and supply adjustment logic between
multiple clusters, which would have required adding a separate
cpufreq_driver. But it now looks like this can be solved by adding the
corresponding config_clks() and config_regulators() callbacks in
dev_pm_opp_set_config().
[...]
Common clock framework maintainers don't want muxes to be programmed- Meson8/8b/8m2 (32-bit ARM Cortex-A5/A9) where we need to reparent
the CPU clock to XTAL for stable operating during clock changes (which
should go into a cpufreq driver that implements target_intermediate).
There's no secure monitor or firmware involved for CPU clocks.
BTW, could we put the CPU clock handling logic in the clock driver like
G12A does (though, of course, handling it in the cpufreq driver might
minimize the coupling between the clock and cpufreq drivers)? That way
we could fully reuse the existing cpufreq-dt?
magically in clock notifiers (which is what G12A and Meson8* do).
So there's a chance that for new drivers they would just NACK that approach.
I don't recall the exact reason anymore - but from my perspective
using a cpufreq driver for this is the cleanest approach (although a
few lines of code extra).
It would move the soc-specific logic from a soc-specific clk driver
to soc specific cpufreq tree handling clock muxing. I kind of
disagree on this approach. If some logic is needed to handled clock
parking while switching clock sub-trees and notifiers is not
accepted them the CCF should evolve to handle that, not moving
this logic elsewhere and have a proliferation of clk mux related
code in cpufreq.
Additionally: I believe the udelay(100) in the G12A and Meson8*
implementation is not even clock related but a delay to wait for the
regulator to become stable.
It's highly probable
That makes things simple, indeed: each cluster follows the same logic- GXBB/GXL/GXM use SCPI firmware CPU clock control so to my knowledge
we're good with what we have (meaning: no custom cpufreq driver
needed)
- G12A single cluster, no DSU: needs a cpufreq driver that implements
target_intermediate (currently it's managed on clock driver side in
kernel space, no firmware involved)
- G12B multi cluster, no DSU: needs a cpufreq driver that implements
target_intermediate (currently it's managed on clock driver side in
kernel space, no firmware involved)
The cpufreq-related resources on the SoCs mentioned above are relatively
clean: each cluster has only one independent clock and supply of its
own, and these SoCs also do not support voltage selection based on chip
binning.
using it's own resources.
I think so far mainline is not touching the DSU clock at all.- SM1 single cluster and DSU: needs a cpufreq driver that implements
target_intermediate (currently it's managed on clock driver side in
kernel space, no firmware involved)
Compared with the SoCs above, the difference for SM1 is that it needs to
additionally manage a DSU clock. In this case, the clock-related
handling can be added in dev_pm_opp_set_config() in amlogic-cpufreq.c
(by implementing clk_names and config_clks in struct dev_pm_opp_config).
[...]
All in all, it looks like we can currently support all Amlogic SoCs in aGreat, let's look at some code rather than discussing theory on how to
single amlogic-cpufreq.c? Then, for the specific characteristics of
different SoCs, we can differentiate them through the "compatible"
property and add the corresponding drvdata for each.
I'll also try to support S7/A9 with representative differences based on
this patch.
write code :-)
There's one last detail that we have to manage in case we also want to
include the Meson8* code into the same file:
config MESON_SM depends on ARM64_4K_PAGES
32-bit kernel builds can't satisfy this (meaning: we end up with
linker errors). I think a simple way to get around this is to add stub
functions to include/linux/firmware/meson/meson_sm.h.
I'll take care of that once I can submit Meson8 support patches for
your upcoming amlogic-cpufreq.c!
Best regards,
Martin