Re: [PATCH 4/4] cpufreq: add an Amlogic speed-bin driver

[Christian Hewitt]

> On 27 Oct 2026, at 1:26 pm, Chuan Liu <chuan.liu686@xxxxxxxxx> wrote:
> 
> Hi Viresh, Christian,
>    Could you please hold off for now on the patches adding cpufreq driver support on S4? There are still two issues that need to be resolved first:
>  - The clock driver currently does not support setting the CPU clock.
>  - The CPU regulator needs some time to stabilize after the voltage is changed. Without a proper delay, the CPU clock frequency may be raised before the regulator voltage has actually reached the target value, which can hang the system. The S4 CPU regulator handling currently lacks the logic to wait for the regulator voltage to settle, so this part needs to be completed first.
> 
> We are currently working on submitting our own cpufreq driver. We are considering how to address the issues above, taking into account the hardware characteristics of previous SoCs and evaluating factors such as the transition latency. S4 will be covered by that work (as well as SoCs from S4 onward, such as C3, T7, ..., A9). So please give us some time.

Please don’t top-post, keep inline threading!

FWIW, the recent bindings/clock/driver work I’ve done for S4 is here:

https://github.com/chewitt/linux/commits/amlogic-7.3.y

My speed-bin driver is based on earlier work from Martin Blumenstingl:

https://github.com/chewitt/linux/commit/77e12d4d584d6a8bbd93304bbd4e9bbbb6ee159a

Setting a ramp-delay was the key to opp transition stability:

https://github.com/chewitt/linux/commit/ca7a99e86e23677c7b5af887e6f3b3c8ce3470d2

CH.
also a Christian, to confuse people :)

> On 10/26/2026 4:59 PM, Viresh Kumar wrote:
>> On 26-10-26, 09:57, Jerome Brunet wrote:
>>> On lun. 26 oct. 2026 at 11:00, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
>>> 
>>>> On 25-10-26, 20:22, christian.koever-draxl@xxxxxxxxxxxxxxxxxx wrote:
>>>>> From: Christian Stefan Kövér-Draxl <ckoever@xxxxxxxxxx>
>>>>> 
>>>>> Every S4 speed bin runs the same CPU frequencies but needs its own
>>>>> voltage curve, and the bin can only be read through the secure monitor.
>>>>> 
>>>>> Read the bin from the firmware, select the matching
>>>>> "opp-microvolt-speed<bin>" property for all CPUs, then register
>>>>> cpufreq-dt. Bins outside the known range fall back to bin 0, which
>>>>> has the highest voltages. Like sun50i-cpufreq-nvmem, the driver binds
>>>>> on the SoC compatible and needs no node of its own, and S4 is added to
>>>>> the cpufreq-dt-platdev blocklist so cpufreq-dt is only created after
>>>>> the bin has been applied.
>>>>> 
>>>>> Signed-off-by: Christian Stefan Kövér-Draxl <ckoever@xxxxxxxxxx>
>>>>> ---
>>>>>  MAINTAINERS                          |   1 +
>>>>>  drivers/cpufreq/Kconfig.arm          |  14 ++
>>>>>  drivers/cpufreq/Makefile             |   1 +
>>>>>  drivers/cpufreq/amlogic-cpufreq.c    | 184 +++++++++++++++++++++++++++
>>>>>  drivers/cpufreq/cpufreq-dt-platdev.c |   2 +
>>>>>  5 files changed, 202 insertions(+)
>>>>>  create mode 100644 drivers/cpufreq/amlogic-cpufreq.c
>>>> 
>>>> Is it safe to apply just this one ? I can take this via the PM tree then.
>>> 
>>> I would advise to wait a little for Amlogic to chime in.
>> Sure, I wasn't going to wait for the maintainers to respond anyway.
> 
> -- 
> Best regards,
> Chuan
> 
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-amlogic