Re: [PATCH 04/13] clk: amlogic: Add basic clock driver
From: Chuan Liu
Date: Wed Apr 15 2026 - 08:21:33 EST
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@xxxxxxxxxxx> 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@xxxxxxxxxxx>So how did all existing Amlogic SoC platforms work so far without basic
Implement core clock driver for Amlogic SoC platforms, supporting
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