[PATCH 04/13] clk: amlogic: Add basic clock driver

[Chuan Liu]

Hi Jerome,


On 4/9/2026 1:34 AM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
> 
> On mer. 08 avril 2026 at 22:32, Chuan Liu <chuan.liu at amlogic.com> wrote:
> 
>> Hi Krzysztof (& ALL),
>> Thanks for review.
>>
>> On 2/9/2026 9:17 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>> On 09/02/2026 06:48, Chuan Liu via B4 Relay wrote:
>>>> From: Chuan Liu <chuan.liu at amlogic.com>
>>>>
>>>> Implement core clock driver for Amlogic SoC platforms, supporting
>>> So how did all existing Amlogic SoC platforms work so far without basic
>>> clock driver? Really, how?
>>> You are suppose to grow existing code, not add your completely new
>>> "basic" driver just because you have it that way in downstream.
>>>
>>
>> Firstly, apologies for the delayed response. I had intended to consolidate
>> the V1 review feedback and come back with a clearer plan for V2 changes. In
>> the meantime, Martin has provided many detailed and valuable suggestions -
>> much appreciated.
>>
>> The original goal of optimizing the HW based on A9 and introducing a new
>> clock driver is to reduce unnecessary complexity in the driver. On A9, we
>> optimized the Clock/PLL controller HW to simplify driver performance,
>> complexity, memory footprint, and reusability. Improvements on the HW side
>> can also help drive corresponding enhancements in the driver:
>>     - Performance: Encapsulates sub-clock functions, reducing call paths
>>     - Complexity: Standardized register bits eliminate a large number of
>> bit definitions (~1/3 of original code is defined register bit [1])
>>     - Memory: Object-oriented design avoids copy/paste for repeated clocks
>>     - Reusability: Same controller works across SoCs without driver
>> changes (or with minimal changes)
>>
>> The old meson driver required compromises to unify legacy controller
>> characteristics and driver styles. On A9, we want a fresh start.
> 
> I thought I was clear on the cover letter, apparently not.
> 
> *This is not going to happen*
> 
> You've provided no technical justification for such "a fresh start".
> 
> There no reason for A9 HW to be supported by different drivers than the
> rest of the Amlogic SoC when it is quite clear it can fit with the
> current drivers.
> 
> At lot of work by a lot of different people has gone into stabilizing
> and maintaing the current driver. That's valuable too. If you are not
> happy with current level of "performance" then make your case with
> actual numbers and submit changes against the current drivers, making
> improvement available to all supported SoCs. That's how upstream works.

The new driver is intended to reduce unnecessary complexity, making it 
easier to support future SoC clock drivers while also lowering the 
review effort required for adding such support. It is important for us 
to have the foundational clock drivers supported upstream as soon as 
possible, so that other dependent drivers can proceed with their enablement.

In addition, the A9 clock driver abstracts clocks as fully functional 
"CCU" units. In previous SoCs, clocks were modeled as discrete 
components such as mux/divider/gate. Changing the abstraction model in 
existing drivers would likely require modifying clkids in the DT 
bindings, which introduces a risk of breaking the ABI.

I respect and truly appreciate your contributions to the Amlogic 
upstream ecosystem. Based on previous problems and current dilemmas, we 
hope the A9 approach can bring meaningful improvements.

> 
>>
>>> Best regards,
>>> Krzysztof
> 
> --
> Jerome

-- 
Best regards,
Chuan